손이 부러져 2개월 동안 깁스를 해야 하지만 일을 멈출 수는 없다면, 프로그래머는 어떻게 해야 할까요? 에릭 슐런츠(Erik Schluntz), 연구원 인류학 그리고 다음 저서의 공동 저자 효과적인 에이전트 구축, 다음과 같이 답합니다: 모든 것을 클로드.
오늘날 AI가 소프트웨어 산업의 판도를 급격히 바꾸고 있는 가운데, 생산성을 획기적으로 높이고자 하는 기업들에게 ‘Vibe Coding’은 더 이상 피할 수 없는 과제가 되었습니다.
몇 달 전, 슐런츠는 “완전 자동화된 업무”에 강제로 투입되었던 자신의 특이한 경험을 공개하며, 프로덕션 환경에서 ‘바이브 코딩’을 책임감 있게 실천하는 방법에 대해 논의했는데, 이는 다소 논란의 여지가 있는 주제였다.
이 강연은 실용적인 통찰력이 가득하며, 최근 X에서 다시 화제가 되고 있습니다. Movez라는 사용자는 이 강연이 유료 강좌 100개보다 낫다고 칭찬하기도 했습니다.
‘Vibe Coding’의 정신에 따라, 우리는 Schluntz의 강연을 구성하는 데에도 AI를 활용했습니다.
이 훌륭한 강연을 시청하고 싶으시다면, 여기를 클릭하시면 해당 페이지로 이동할 수 있습니다.
바이브 코딩이란 무엇인가
많은 사람들이 Cursor나 Copilot 같은 AI 도구를 코드 생성에 과도하게 사용하는 것을 “바이브 코딩’과 동일시합니다. 하지만 이는 정확하지 않습니다. 개발자가 모델과 긴밀한 피드백 루프를 유지하며—코드를 한 줄 한 줄 검토하고 수정하는—한에서는, 이를 진정한 ”바이브’라고 할 수 없습니다.”
앙드레 카르파티는 이에 대해 더 정확한 정의를 내렸다. “그 분위기에 완전히 몰입하고, 기술의 기하급수적인 성장을 받아들이며, 코드가 존재한다는 사실조차 완전히 잊어버리는 것.”
이러한 작업 방식은 개발 진입 장벽을 크게 낮춰, 엔지니어링 배경이 없는 사람들도 독립적으로 완성도 높은 애플리케이션을 구축할 수 있게 해줍니다. 하지만 과거에는 이 접근 방식의 성공 사례가 대부분 개인용 게임이나 위험 부담이 적은 프로젝트로 국한되어 있었습니다. 비전문가들이 이 접근 방식을 실제 운영 환경에 적용하면, API 할당량 소진, 구독 유효성 검사 우회, 데이터베이스 임의 수정 등과 같은 통제 불능 상황이 자주 발생하게 됩니다.
바이브 코딩이 중요한 이유: 기하급수적 성장의 논리
고위험 비즈니스 환경에 통제할 수 없는 요인들이 존재한다면, 왜 우리는 여전히 이 기술을 추진해야 할까요? 그 핵심 동력은 바로 AI 역량의 “기하급수적인 성장”에 있습니다.
현재 AI가 독자적으로 처리할 수 있는 작업의 분량은 약 7개월마다 두 배로 증가하고 있습니다. 오늘날 AI는 약 1시간이 소요되는 코딩 작업을 안정적으로 완료할 수 있으며, 개발자들은 여전히 그 코드를 한 줄 한 줄 검토할 여력이 있습니다. 하지만 내년이든 내후년이든, AI가 인간의 1일 또는 심지어 1주일에 해당하는 분량의 코드를 한 번에 생성할 수 있게 되었을 때, 우리가 여전히 기존의 동기식 검토 및 수정 방식을 고집한다면, 인간 엔지니어들은 폭발적으로 증가하는 컴퓨팅 성능 속에서 필연적으로 병목 현상이 될 것입니다.
컴파일러의 역사를 살펴볼 수 있습니다. 초기 개발자들은 컴파일러를 신뢰하지 않았고, 여전히 그 밑바탕에 있는 어셈블리 코드를 직접 확인하곤 했습니다. 시스템 규모가 커짐에 따라 개발자들은 더 높은 수준의 추상화를 신뢰하는 법을 배워야만 했습니다. 앞으로 소프트웨어 공학 분야 전체는 대규모 모델이 직접 생성한 시스템을 운영 환경에서 어떻게 안전하고 책임감 있게 수용할지 미리 고려해야 합니다.
프로덕션 환경에서 Vibe 코딩을 적용하는 방법
실전 환경에서 ‘바이브 코딩’을 실천할 때의 핵심 원칙은 다음과 같습니다. 코드의 존재는 잊되, 항상 제품의 존재에 집중하십시오.
현대 기업 경영에서 CTO는 수락 테스트를 통해 기술 전문가를 관리하고, 제품 관리자는 제품을 직접 체험하며 기능을 검증하며, CEO는 핵심 데이터를 분석하여 재무 모델을 검토합니다. 이들 중 누구도 가장 세부적인 실행 단계까지 깊이 파고들지는 않습니다. 소프트웨어 엔지니어 역시 기본 코드를 읽지 않고도 검증할 수 있는 이와 유사한 추상화 계층을 구축해야 합니다.
핵심은 검증할 수 있는 추상화 계층을 찾아내는 것입니다.
그러나 현재의 AI 코딩에는 ‘기술적 부채’라는 까다로운 기술적 장애물이 존재한다. 현재로서는 소스 코드 전체를 읽어보는 것 외에는, 체계적인 방법을 통해 기술적 부채를 측정하거나 검증하기가 극히 어렵다.
이를 바탕으로 에릭 슐런츠(Erik Schluntz)는 코드베이스 내의 “리프 노드(leaf nodes)”에 집중할 것을 제안합니다. 이 노드들은 다른 어떤 모듈에서도 의존하지 않는 종단 함수나 보조 구성 요소를 의미합니다. 이러한 영역에서는 기술적 부채가 다소 발생하더라도, 변경 빈도가 낮고 향후 모듈 구축을 방해하지 않기 때문에 용인될 수 있습니다.
반면, 시스템의 핵심 트렁크와 기반 아키텍처에 대해서는 엔지니어들이 여전히 확장성을 깊이 이해하고 철저히 보호해야 합니다.
주목할 점은 모델의 성능이 향상됨에 따라, AI가 처리할 수 있다고 신뢰할 수 있는 코드의 수준이 점점 더 낮은 단계로 확대되고 있다는 사실입니다. 최근 Anthropic에서 실시한 내부 테스트에 따르면, AI가 고품질의 아키텍처를 생성하는 성공률이 높아지고 있으며, 이러한 경계는 지속적으로 변화하고 있습니다.
바이브 코딩의 핵심 역량: 제품 매니저처럼 생각하기
AI가 고품질의 엔지니어링 코드를 생성하도록 하려면, 개발자들은 사고방식을 전환하여 스스로를 [ ]의 제품 매니저로 여겨야 합니다. 클로드. 클로드가 당신을 위해 무엇을 해줄 수 있는지 묻지 말고, 당신이 클오드를 위해 무엇을 해줄 수 있는지 물어보십시오.
복잡한 개발 과제에 직면했을 때, 개발자들은 마치 신입 사원을 첫 출근 날에 교육하듯이 AI를 지도해야 합니다. 단순히 “이 기능을 구현해라”와 같은 지시만 내리는 것은 실패로 이어질 수밖에 없습니다. 개발자들은 코드베이스 탐색 방법을 상세히 안내하고, 요구 사항과 제약 조건을 명확히 정의해야 합니다.
클로드가 실제로 코드를 작성하기 전에, 슐런츠는 대개 15~20분 정도 시간을 들여 AI와 상호작용을 합니다. 여기에는 AI가 코드베이스를 탐색하고, 관련 파일을 찾아내며, 명확한 실행 계획을 공동으로 수립하는 과정이 포함됩니다. 그런 다음, 이렇게 체계적으로 정리된 모든 맥락과 사양은 실행 전에 하나의 프롬프트로 통합됩니다.
이 과정을 통해 모델의 과제 성공률이 기하급수적으로 증가합니다.
실제 사례: 하루 만에 22,000줄의 코드를 병합
슐런츠는 앤트로픽 내부에서 발생한 극단적인 실제 사례를 공개했다. 그의 팀은 최대 22,000줄에 달하는 코드 변경 사항을 운영 중인 강화 학습 코드베이스에 성공적으로 병합했는데, 이 코드의 대부분은 클로드.
이 병합 작업을 책임감 있게 완료하기 위해 팀은 다음 네 가지 전략을 채택했습니다:
- 제품 관리자의 관점에서 이루어지는 철저한 사전 계획
- 리프 노드에 대한 변경을 엄격히 제한
- 핵심 시스템 로직에 대한 수동 검토
- 검증 가능한 점검 항목 및 부하 테스트 설계
이러한 접근 방식을 통해, 원래는 2주간의 인력 투입이 필요했던 작업이 단 하루로 단축되었습니다.
개발 비용이 급격히 감소하면, 엔지니어들은 자원 제약으로 인해 이전에는 불가능했던 대규모 리팩토링과 기능 반복 개선을 수행할 수 있게 됩니다.
고급 바이브 코딩 기법과 실제 사례 Q&A
슐런츠는 또한 학습 방법부터 도구 활용에 이르기까지 다양한 측면에 걸쳐 실용적인 통찰력을 공유했다.
학습에 관하여: 프로그래머들은 더 이상 저수준 세부 사항에 발목 잡히지 않을 수 있지만, AI는 학습 속도를 크게 높여줍니다. 개발자들은 AI에게 익숙하지 않은 라이브러리나 의사 결정에 대해 설명해 달라고 요청할 수 있으며, 이를 통해 AI는 언제든지 이용할 수 있는 페어 프로그래머 역할을 하게 됩니다.
경험 축적에 관하여: AI는 시행착오 과정을 가속화합니다. 예전에는 검증하는 데 수년이 걸리던 의사결정을 이제 몇 달 안에 테스트할 수 있게 되어, 엔지니어들은 같은 기간 동안 몇 배나 더 많은 경험을 쌓을 수 있게 되었습니다.
참고: 세부 사항의 정도는 구현을 얼마나 중요하게 여기는지에 따라 달라집니다. 하지만 모델에 지나친 제약을 가하면 성능이 저하되는 경우가 많습니다. 딱딱한 템플릿을 강요하기보다는, 마치 신입 엔지니어와 소통하는 것처럼 접근하세요.
보안에 관하여: Vibe Coding은 위험을 제대로 이해하는 사람의 지도를 받을 때만 안전합니다. 기술 지식이 없는 사용자가 적절한 인식 없이 시스템을 구축할 때 대개 문제가 발생합니다.
제품 디자인에 관하여: 미래의 도구는 민감한 백엔드 로직이 잠겨 있고, 사용자가 통제된 환경에서 안전하게 실험할 수 있는 “증명 가능한 정확성”을 갖춘 시스템을 제공할 수 있을 것입니다.
테스트에 관하여: 테스트 주도 개발은 매우 유용합니다. 복잡한 테스트 대신 간단한 종단 간 테스트를 의무화하세요. 즉, 정상 경로 하나와 오류 사례 두 가지를 포함하는 테스트입니다. 최소한의 테스트만으로도 신뢰성과 가독성을 높일 수 있습니다.
워크플로우에 관하여: Claude Code와 Cursor를 함께 사용하는 것이 일반적입니다. Claude는 생성 작업을 담당하고, 개발자는 생성된 결과를 검토하거나 다듬습니다. 맥락이 흐트러지는 것을 방지하기 위해 주기적으로 맥락을 압축해야 합니다.
익숙하지 않은 코드베이스의 경우: 기능을 구현하기 전에 AI를 활용해 시스템을 탐색하세요. 핵심 모듈을 찾아내고, 유사한 구현 사례를 파악하며, 실행에 앞서 머릿속에서 시스템의 구조를 파악해 두세요.
마무리 생각: “기하급수적 성장을 수용한다”는 것이 진정으로 의미하는 바는 무엇인가
지수적 성장의 본질은 단순히 지속적인 개선에 그치는 것이 아니라, 우리가 예상하는 것보다 훨씬 더 빠른 속도로 개선이 이루어지는 데 있습니다.
천천히 시작되었다가 갑자기 치솟는 곡선처럼, AI의 성능은 단순히 두 배로 늘어나는 데 그치지 않고, 수십 배에서 수백 배로 증가할 수도 있습니다.
컴퓨팅의 역사를 되돌아보면, 1990년대의 킬로바이트급 메모리에서 오늘날의 테라바이트급 메모리에 이르기까지, 그 발전 폭은 2배가 아니라 수백만 배에 달합니다.
따라서 진짜 질문은 “모델의 성능이 두 배로 좋아지면 어떻게 될까”가 아니라, “모델의 성능이 백만 배나 더 좋아지면 어떻게 될까”라는 것입니다.”
이것이 바로 ‘바이브 코딩’의 진정한 의미이며, 이를 간과할 수 없는 이유이기도 합니다.
