결론: 코드의 시대에서 판단의 시대로
개발의 병목이 코딩에서 판단으로 이동했다. 코드를 쓰는 능력보다 “무엇을 만들어야 하는가”, “어디에 적용해야 하는가”, “어떻게 검증해야 하는가"를 판단하는 능력이 결정적으로 중요해졌다.
바이브 코딩은 그 전환의 가장 극단적인 형태다 — 코드의 존재를 잊되, 제품의 존재는 결코 잊지 않는 것. 단, 아무 곳에나 적용하는 것이 아니라, 리프 노드에서 시작하고, 검증 가능한 추상화를 설계하고, 클로드의 PM으로서의 역할을 진지하게 받아들이는 것이다.
이 글은 Anthropic의 Erik Schulthz가 Code w/ Claude(2025.07)에서 발표한 “Vibe Coding in Prod"를 정리한 것이다.
바이브 코딩이란 무엇인가
“바이브 코딩"이라는 말을 들으면 많은 사람이 “AI에게 코드를 많이 맡기는 것” 정도로 이해한다. 하지만 Erik Schulthz는 이것이 바이브 코딩의 정의가 아니라고 단호하게 선을 긋는다.
바이브 코딩의 진짜 정의는 Andrej Karpathy가 내린 것이다: “코드가 존재한다는 사실 자체를 잊는 것.” AI가 쓴 코드를 사람이 한 줄 한 줄 확인하는 것은 AI 보조 코딩이지, 바이브 코딩이 아니다.
이 구분이 중요한 이유는 바이브 코딩이 비개발자를 포함한 훨씬 넓은 대중에게 “나도 앱을 만들 수 있다"는 가능성을 열었기 때문이다. 커서와 코파일럿이 개발자의 생산성을 높인 도구였다면, 바이브 코딩은 개발의 진입 장벽 자체를 허문 패러다임 전환이었다.
위험하다, 하지만 멈출 수 없다
당연히 위험하다. 처음 코딩하는 사람이 프로덕션 시스템을 바이브 코딩하면 API 키가 노출되고, 결제가 우회되고, 데이터베이스에 알 수 없는 데이터가 쌓인다. Addy Osmani는 바이브 코딩이 “빛나는 데모를 만들지만 유지보수 가능한 소프트웨어를 만들지는 못한다"고 경고했다.
Schulthz는 이 비판을 정면으로 받아들인다. 그리고 반전을 만든다.
AI가 자율적으로 수행할 수 있는 작업의 길이가 7개월마다 2배로 늘어나고 있다. 지금은 약 1시간 분량의 작업을 맡길 수 있다. 하지만 내년에는 하루치, 내후년에는 일주일치 코드가 한 번에 생성된다. 그 시점에 코드를 한 줄씩 리뷰하겠다는 접근은 물리적으로 불가능해진다.
이것은 마치 컴파일러 초기 시대와 같다. 초기 개발자들은 컴파일러가 생성한 어셈블리를 직접 읽어서 확인했을 것이다. 하지만 시스템이 커지면서 어셈블리를 직접 읽는 것은 불가능해졌고, 우리는 컴파일러를 신뢰하는 법을 배웠다. 물론 이 비유에는 한계가 있다 — 컴파일러는 결정론적이고 형식 검증이 된 도구였지만, LLM은 확률적이고 예측 불가능한 순간이 있다. 그래서 Schulthz의 프레임워크가 “전부 맡겨라"가 아니라 “어디에 맡길지 선택하라"인 것이다.
구현을 모르고 검증하는 것은 새로운 문제가 아니다
Schulthz는 여기서 아주 날카로운 통찰을 던진다: “구현을 이해하지 못하는 상태에서 결과물을 관리하는 것은 문명만큼 오래된 문제다.”
- CTO는 자기가 전문가가 아닌 도메인의 전문가를 어떻게 관리하는가? → 인수 테스트를 쓴다.
- PM은 자기가 코드를 읽지 못하는 기능을 어떻게 검증하는가? → 직접 제품을 써본다.
- CEO는 자기가 회계 전문가가 아닌데 회계사의 작업을 어떻게 확인하는가? → 핵심 수치를 스팟 체크한다.
공통되는 것은, “구현 전체를 이해하는 것"이 아니라 “올바른 질문을 던지는 것"으로 검증을 수행한다는 점이다. 소프트웨어 엔지니어만이 “구현의 모든 줄을 이해해야 한다"는 전제에 익숙할 뿐, 세상의 모든 관리자는 이미 “구현을 모른 채 결과를 검증하는 일"을 하고 있다.
리프 노드 전략: 어디에 바이브 코딩을 적용할 것인가
기술 부채가 남아있는 문제다. 코드를 읽지 않고는 기술 부채를 측정하거나 검증할 좋은 방법이 없다.
Schulthz의 해법은 코드베이스를 트리로 시각화하고, **리프 노드(leaf node)**에만 바이브 코딩을 집중하는 것이다.
- 리프 노드: 다른 것이 의존하지 않는 말단 기능. 변경될 가능성이 낮고, 위에 더 쌓을 것이 없는 부분. 여기에 기술 부채가 생겨도 피해가 격리된다.
- 줄기와 가지: 핵심 아키텍처. 다른 모든 것이 위에 구축되는 기반. 여기는 엔지니어가 깊이 이해하고 보호해야 한다.
이 전략이 날카로운 이유는, 바이브 코딩의 위험성을 인정하면서도 완전히 포기하지 않는 현실적인 타협점을 제시하기 때문이다. “바이브 코딩은 위험하니까 하지 마라"도 아니고, “AI를 믿고 다 맡겨라"도 아니다.
클로드의 PM이 되어라
바이브 코딩에서 사람의 역할은 “코드를 쓰는 사람"에서 “클로드의 프로덕트 매니저"로 바뀐다.
“Ask not what Claude can do for you, but what you can do for Claude.”
Schulthz는 기능 작업 전에 15~20분을 들여 클로드를 위한 컨텍스트를 수집한다. 이 시간에 하는 것은 프롬프트를 손으로 쓰는 게 아니라, 별도의 대화에서 클로드와 함께 코드베이스를 탐색하고, 관련 파일을 찾고, 계획을 세우는 것이다. 요구사항, 변경해야 할 파일, 따라야 할 패턴을 하나의 아티팩트로 정리한 다음, 그것을 새 컨텍스트에 넘긴다.
이 접근은 이미 알고 있는 원칙과 공명한다: 스펙이 레버리지다. 사람의 암묵지를 명문화된 스펙으로 전환하는 데 투자하면, AI 에이전트의 성공률이 극적으로 올라간다. 프롬프트에 15분을 투자하는 것은 주니어 개발자에게 충분한 온보딩을 제공하는 것과 다르지 않다.
다만 Schulthz는 한 가지 경고를 덧붙인다: 완전히 비기술적인 사람이 바이브 코딩으로 사업을 구축하는 것은 위험하다. “올바른 질문을 할 수 있는 능력"이 있어야 클로드의 효과적인 PM이 될 수 있기 때문이다.
22,000줄 사례: 이론이 아닌 실전
Schulthz는 Anthropic 내부의 강화학습 프로덕션 코드베이스에 22,000줄짜리 PR을 머지한 경험을 공유한다.
이 변경을 책임감 있게 머지할 수 있었던 방법:
- 클로드의 PM 역할 수행 — 단일 프롬프트가 아니라 며칠에 걸친 요구사항 정의와 가이딩
- 리프 노드 집중 — 변경의 대부분이 다른 코드가 의존하지 않는 말단 영역에 집중
- 핵심 영역은 사람이 리뷰 — 확장 가능해야 하는 중요한 부분은 사람이 깊이 리뷰
- 스트레스 테스트 — 안정성 검증을 위한 스트레스 테스트를 설계하고 장시간 실행
- 검증 가능한 I/O — 코드를 읽지 않고도 정확성을 확인할 수 있는 체크포인트 설계
가장 흥미로운 부분은 이 경험이 만든 사고방식의 전환이다. 2주 걸릴 일이 하루 만에 가능해지니, 이전에는 “비용 대비 가치가 낮다"고 넘겼던 대규모 개선 작업을 실행에 옮기게 되었다. 소프트웨어의 한계비용이 낮아지면서, 만들 수 있는 것의 범위 자체가 확장된 것이다.
실전에서의 검증 전략
테스트로 검증하되, 테스트의 종류가 다르다. 클로드가 구현 세부사항에 종속된 테스트를 양산하는 것을 방지하기 위해, 3개의 간결한 E2E 테스트만 작성하게 한다. 정상 동작 하나, 에러 케이스 둘. “내가 제일 먼저 읽는 코드는 테스트이고, 테스트에 동의할 수 있고 그것이 통과하면 꽤 안심이 된다.”
맥락 관리도 검증 전략의 일부다. AI와의 대화가 길어지면 맥락이 너무 커져서 성능이 떨어진다. Schulthz의 답: “사람이 점심 먹으러 갈 타이밍에.” 클로드에게 파일을 찾고 계획을 세우게 하고, 그 계획을 문서에 적고, 그 다음 컴팩션 — 10만 토큰이 수천 토큰으로 줄어든다.
그래서
컴파일러 시대에 어셈블리를 손으로 쓰는 것을 포기한 것처럼, 우리도 코드를 한 줄 한 줄 직접 쓰고 읽는 것을 점차 내려놓게 될 것이다.
소프트웨어 엔지니어의 가치가 “코드를 쓸 수 있는 능력"에서 “무엇을 만들어야 하는지 판단할 수 있는 능력"으로 이동한다. 그리고 후자는 도메인 지식, 사용자 이해, 시스템 사고에 의존한다 — 역설적이게도, 이것은 AI가 대체하기 가장 어려운 영역이기도 하다.
코드를 내려놓을수록, 오히려 인간만이 할 수 있는 일이 더 선명하게 드러난다.
원본 영상: Vibe Coding in Prod | Code w/ Claude · Anthropic, 2025.07