AI 코딩 90만 줄, 그런데도 내가 여전히 코드 주인인 이유

바이브 코딩 90만 줄, 그런데도 개발자가 코드 주인일 수 있는 이유 🧭

요즘엔 개발자 커뮤니티에서 바이브 코딩 이야기가 안 나오는 날이 없더라구요. 저도 처음엔 반신반의했는데, 실제 사례를 보면 생각이 많이 바뀝니다.

PR 리뷰에 코멘트가 없으면 오히려 불안한 이유

미국의 한 스타트업 창업자 조시 앤더슨 이야기부터 해볼게요. 깃허브 코파일럿이 자신의 PR을 검토했는데 코멘트를 0개 남겼습니다. 보통은 좋아할 상황인데, 그는 오히려 리뷰가 제대로 돌아갔는지부터 의심했다고 해요. 결국 직접 검증을 다시 돌려봤습니다.

저도 이 마음 알 것 같아요. AI가 완벽해 보일수록 오히려 본능적으로 의심부터 하게 되는 거죠. 이게 요즘 개발자들의 솔직한 심리인 것 같습니다.

바이브 코딩이 정확히 뭔지 짚고 갈게요

바이브 코딩은 사람이 직접 타이핑하지 않고, AI에게 요구사항만 설명하면 AI가 코드 대부분을 작성하는 방식을 말해요. 앤더슨은 이 방식으로 지금 90만 줄에 가까운 코드베이스를 운영 중인 제품을 만들고 있습니다. 대부분 클로드 코드가 작성했고, 그는 방향만 지시했어요.

그런데 흥미로운 건 그가 1년 전에는 정반대의 실패를 겪었다는 점이에요. 3개월 동안 손코딩 없이 AI로만 제품을 만들었다가, 코드 7만 줄쯤에서 작은 수정 하나조차 자신 없어지는 상황을 겪었습니다. 25년 경력의 베테랑 개발자가 자기 제품 앞에서 승객처럼 느껴진 거예요.

많은 사람이 하는 오해, AI에게 맡기면 편할 거라는 생각

AI 도구를 쓰면 무조건 편해지고 실력도 자연스럽게 는다고 생각하는 분들 많으실 거예요. 그런데 최근 앤트로픽이 발표한 실험 결과는 다른 이야기를 합니다.

파이썬을 1년 이상 써온 개발자 52명을 대상으로 한 실험에서, AI 도움을 받은 그룹은 과제를 2분 정도 빨리 끝냈지만 이후 퀴즈 점수는 100점 만점에 50점으로, 손코딩 그룹(67점)보다 17점이나 낮았어요. 거의 두 등급 차이입니다. 특히 디버깅 문제에서 격차가 가장 컸다고 해요.

업레벨이라는 조사기관이 개발자 800명을 3개월간 추적한 연구에서도, AI 코딩 도구를 쓸 때 오히려 버그가 41% 더 많이 발생했다는 결과가 나왔습니다. 그리고 2025년 7월 METR의 무작위 대조 실험에서는 숙련된 오픈소스 개발자들이 AI 코딩 도구를 썼을 때 오히려 19% 느려졌다는 결과도 있었어요. 재밌는 건 개발자들 스스로는 24% 빨라질 거라 예측했고, 실험 후에도 20% 빨라졌다고 믿었다는 점입니다. 체감 생산성과 실제 생산성이 이렇게 다를 수 있더라구요.

핵심은 속도가 아니라 누가 설계를 주도하느냐예요

앤더슨이 90만 줄까지 갈 수 있었던 진짜 이유는 도구가 좋아져서만이 아니었습니다. 이번 제품에서는 아키텍처를 자신이 직접 짰거든요. 패턴을 조사하고, 여러 옵션을 검증하고, 스스로 확신이 드는 구조를 먼저 완성한 다음에야 AI를 투입했습니다.

이전 실패작에서는 AI가 그때그때 구조를 결정했고, 그는 나중에 남의 선택을 감사하는 입장이었어요. 그가 던진 질문은 이거였습니다. "이 제품의 주인은 누구인가, 나인가 AI인가." 답은 명확했죠. 코드는 AI가 썼지만, 설계는 전부 자신이 소유하고 있다는 것.

숫자로 보는 AI 코딩의 명암

전미경제연구소(NBER)가 개발자 10만 명 이상의 데이터를 분석한 연구에 따르면, 자율형 AI 코딩 에이전트를 쓰는 팀은 코드 작성량이 최대 180%까지 늘었어요. 그런데 실제 배포 단계까지 이어지는 비율은 30% 수준에 그쳤습니다. 100개 작업 중 코드는 180개만큼 쏟아지는데, 실제로 세상에 나가는 건 30개뿐이라는 뜻이에요.

코드 리뷰, 테스트, 보안 점검처럼 사람이 여전히 담당해야 하는 단계가 병목이 되기 때문이라고 하는데요, 연구진은 이 현상을 '약한 고리 가설'이라고 불렀습니다. 전체 파이프라인의 속도는 가장 느린 단계, 즉 사람이 개입하는 구간이 결정한다는 거죠.

실제로 국내 데이터도 비슷한 그림을 보여줘요. GitClear가 최근 배포된 2억 줄 이상의 코드를 분석한 결과, AI 도입 이후 복붙 코드가 8배나 늘었고 리팩토링 비율은 25%에서 10% 미만으로 뚝 떨어졌다고 합니다. 그리고 CodeRabbit이 GitHub에서 470개 PR을 분석한 결과, AI가 공동 작성한 코드는 사람만 작성한 코드보다 주요 이슈가 1.7배 많았고 XSS 취약점은 2.74배 높았다고 해요.

더 흥미로운 건 개발자들의 심리 변화예요. AI 도구를 신뢰한다는 응답은 18개월 사이 43%에서 29%로 급락했는데, 사용률은 오히려 92%까지 치솟았다고 합니다. 믿지 않으면서도 쓸 수밖에 없는 도구가 되어버린 셈이죠.

반면 클로드 코드는 2025년 11월 옵스 4.5 출시 이후 30분짜리 자율 코딩 작업에서도 안정적인 성능을 보이기 시작했고, SWE-bench에서 80%를 넘긴 첫 모델이 됐습니다. 긴 작업 중 맥락을 잃던 문제도 이 시점부터 크게 개선됐어요.

표준이 움직이지 않으면 결국 무너집니다

앤더슨의 워크플로에서 눈여겨볼 대목이 하나 더 있어요. 그는 프로젝트 전체에 거대한 규칙 파일 하나를 두는 대신, API 폴더에는 API 규칙을, DB 폴더에는 DB 규칙을 각각 따로 배치했습니다. 규칙이 일하는 자리 바로 옆에 있어야 AI가 실제로 지킨다는 걸 경험으로 배운 거예요.

또한 PR 리뷰에서 지적이 나올 때마다 그냥 고치는 데 그치지 않고, "이 지적을 계기로 우리 표준 자체를 바꿀지"까지 매번 판단한다고 해요. 그래야 규칙이 화석처럼 굳지 않고 계속 살아 움직인다는 겁니다.

앞으로는 어떻게 바뀔까요

이 사례가 주는 메시지는 단순해요. AI 코딩에 대한 결론에는 유통기한이 있다는 것. 6개월 전에 "AI 코딩은 별로다"라고 판단했던 팀도, "AI에 다 맡기면 된다"라고 판단했던 팀도, 지금은 둘 다 낡은 데이터로 움직이고 있을 가능성이 큽니다.

실제로 국내 업계 흐름을 보면 스펙 주도 개발이라는 방식이 자리를 잡아가고 있어요. 바이브 코딩의 속도를 유지하면서 명세로 품질을 보장하는 접근인데요, AWS 부사장 딥락 싱이 언급한 것처럼 복잡한 문제에서는 결국 명세를 작성하게 된다는 흐름과도 맞닿아 있습니다.

도구는 한 달 만에도 바뀝니다. 실험은 주기적으로 다시 돌려야 해요. 그리고 살아남는 건 워크플로의 디테일이 아니라 패턴이에요. 사람이 설계를 먼저 쥐고, 규칙이 일하는 자리에 있고, 그 규칙이 계속 업데이트되는 구조. 이 세 가지만 지키면 도구가 좋아질수록 나의 경쟁력도 함께 복리로 쌓입니다. 반대로 이 세 가지 없이 도구만 좋아지면, 그저 내 실수를 더 빠른 속도로 만들어낼 뿐이에요.

마무리

AI가 코드 90만 줄을 대신 써준 이야기는 결국 기술 이야기가 아니라 오너십 이야기입니다. 클로드 코드 같은 도구가 아무리 좋아져도, 아키텍처를 이해하고 설계를 소유한 사람이 현장에 남아 있어야 그 코드는 무너지지 않아요. AI가 시공을 맡아도, 청사진을 읽을 줄 아는 사람이 자리를 지켜야 건물이 섭니다.

지금 AI 코딩 도구를 쓰고 계시다면, 속도보다 먼저 "이 설계를 내가 정말 이해하고 있는가"를 스스로에게 물어보시길 권해드려요. AI는 코드를 대신 써줄 수는 있어도, 그 코드를 책임질 수는 없으니까요.