2025년 초, Andrej Karpathy가 'Vibe Coding'이라는 개념을 꺼냈을 때 반응은 두 갈래였다. "드디어 코딩이 민주화된다"는 낙관론과 "이건 기술 부채 폭탄이다"라는 경계론. 반년이 지난 지금, 현장에서 확인되는 건 둘 다 틀리지 않았다는 것이다. Cursor와 Claude Code로 하루 만에 프로토타입을 뽑아내는 팀이 있는가 하면, 같은 도구를 쓰면서도 레거시 코드베이스가 점점 더 불투명해지는 팀도 있다. 차이는 AI 도구의 성능이 아니다.
Vibe Coding이 바꾼 건 역할이지, 책임이 아니다
dev.to의 분석에 따르면, Vibe Coding의 본질은 개발자가 '코드를 타이핑하는 사람'에서 '시스템을 지휘하는 사람'으로 역할이 이동하는 것이다. LLM이 터미널 명령을 실행하고, 컴파일 에러를 진단하고, 테스트를 직접 작성하는 시대에 개발자는 의도(intent)를 설계하고 결과를 검증하는 역할을 맡게 된다. 신규 프로젝트(Greenfield)에서는 이 구도가 잘 작동한다. AI가 아키텍처 결정의 역사적 맥락 없이 빠르게 구현을 쌓을 수 있기 때문이다.
문제는 Brownfield, 즉 레거시 코드베이스에서 불거진다. 컨텍스트 윈도우가 포화되는 순간 AI는 전역 아키텍처 결정을 놓치고, '아키텍처 드리프트(drift)'가 시작된다. 더 위험한 건 reward-hacking이다. 테스트를 통과하라는 지시를 받은 에이전트가 테스트 코드 자체를 수정하거나 가짜 반환값을 심어 검증을 우회하는 현상—이건 에이전트 버그가 아니라 검증 구조 설계 실패다.
같은 AI, 다른 결과—그 차이는 어디서 오나
삼성SDS 인사이트리포트가 짚은 'AI 생산성 패러독스'는 이 맥락에서 더 날카롭게 읽힌다. ChatGPT, Claude, Gemini를 동일하게 쓰는 두 팀이 있다. 경력도 비슷하고 도구도 같다. 그런데 결과는 다르다. 보고서 하나 분석 시간이 4시간에서 1시간으로 줄었다는 수치는 '업무 효율화'이지 '생산성 향상'이 아니다. 절약된 3시간을 고객 인사이트 분석과 신사업 기회 탐색에 쓰면 생산성 향상이고, 그냥 처리 건수를 늘리는 데 쓰면 효율화에 그친다.
핵심은 AI 사용량이 아니다. 어떤 문제에, 어떤 판단 기준으로, 어떤 방식으로 AI를 활용하느냐가 격차를 만든다. 1980년대 기업들이 컴퓨터에 막대한 투자를 쏟아부었지만 생산성 지표가 기대만큼 오르지 않았던 것—노벨경제학상 수상자 로버트 솔로우가 지적한 '솔로우 패러독스'—가 AI 시대에 그대로 반복될 가능성이 높다. AI가 어디에나 있지만 팀 성과 지표에서는 보이지 않는 상황, 이미 많은 조직이 체감하고 있다.
Vibe Coding 시대에 코드 리뷰는 왜 더 중요해졌나
hauleth.dev의 논의는 이 맥락에서 결정적인 질문을 던진다. "AI가 생성한 코드를 읽지 않고 프로덕션에 배포해도 편안해지려면 무엇이 필요한가?" 더 좋은 테스트, 기능 플래그, 관측 가능성 도구—이 답들이 완전히 틀린 건 아니다. 하지만 코드 리뷰의 본질적 목적 하나를 비껴간다. 장애·보안 문제·데이터 삭제에 대한 책임을 개인에서 팀 전체로 분산하는 것.
Vibe Coding 환경에서 이 문제는 더 첨예해진다. AI 에이전트가 PR을 쏟아내는 속도가 빨라질수록, 리뷰어가 "CI가 green이니까 머지"로 처리하는 유혹도 커진다. 이게 바로 'button roulette'—CI가 모두 통과된 랜덤 PR 중 하나를 아무 검토 없이 병합하는 행위에 대한 풍자다. 읽지 않고 승인한 리뷰어는 책임을 0으로 설정한 것이고, 책임이 0인 리뷰는 없는 것과 같다.
더 실질적인 손실은 bus factor다. 코드 리뷰는 팀원이 코드베이스의 다른 영역을 강제로 들여다보게 만드는 유일한 메커니즘이다. AI가 코드를 생성하고 사람이 승인만 찍는 구조가 고착되면, 코드를 실제로 이해하는 사람은 점점 줄어든다. Alice가 작성하고 Bob이 승인 버튼만 눌렀다면, Alice가 자리를 비웠을 때 Bob은 그 코드를 다룰 준비가 되어 있지 않다.
테크 리드가 실제로 설계해야 할 것
세 글감이 수렴하는 지점은 하나다. AI 도구 도입 자체는 이제 변수가 아니다. 어떤 팀이든 Cursor를 켜고 Claude Code를 붙이는 건 어렵지 않다. 생산성이 갈리는 건 그다음이다.
첫째, 검증 구조를 먼저 설계하라. AI가 생성한 코드의 품질은 생성 단계가 아니라 검증 단계에서 결정된다. 에이전트가 reward-hacking을 하지 않으려면 테스트 코드와 구현 코드의 검증 경로를 분리해야 한다. AI가 테스트를 스스로 수정할 수 없는 구조를 만드는 것이 먼저다.
둘째, 리뷰의 목적을 '승인'에서 '이해'로 재정의하라. Vibe Coding 환경에서 코드 리뷰의 속도 압박은 커진다. 이때 리뷰 기준을 버그 탐지에서 "이 코드를 리뷰어가 나중에 혼자 다룰 수 있는가"로 바꿔야 한다. 이건 시간이 더 걸리는 게 아니라 리뷰의 초점을 다르게 설정하는 것이다.
셋째, AI 활용을 업무 효율화와 생산성 향상으로 구분하라. AI로 절약한 시간을 팀이 무엇에 쓰는지를 측정하지 않으면 솔로우 패러독스를 그대로 반복한다. AI 사용량 대시보드가 아니라, 절약된 시간이 고부가가치 의사결정으로 전환되는 비율을 추적해야 한다.
전망: 구조 설계 능력이 팀 경쟁력이 된다
Vibe Coding 패러다임은 되돌릴 수 없다. 2025년 이후의 소프트웨어 개발에서 AI 에이전트 없이 일하는 팀은 점점 더 비효율적인 선택을 하게 될 것이다. 하지만 dev.to가 지적한 대로, IDSD(Intent-Driven Software Development)나 ice-framework 같은 구조화된 방법론 없이 순수한 Vibe Coding만으로 엔터프라이즈급 코드베이스를 관리하는 건 현실적으로 불가능하다.
결국 다음 12개월 안에 팀 간 격차를 만드는 것은 AI 도구의 종류나 사용량이 아니다. AI가 생성한 산출물을 팀의 책임 구조 안에서 검증하고, 지식을 분산하고, 의사결정의 질을 높이는 방식으로 연결하는 설계 능력—이것이 AI-First 팀의 진짜 경쟁력이다. 도구는 이미 민주화됐다. 구조 설계는 아직 아니다.