바이브코딩 기술부채, 리뷰 반복 대신 리팩토링해야 하는 이유

리뷰를 반복해도 같은 자리에서 계속 터지는 이유

클코단에서 나온 질문은 구체적이었다. 서버 데몬이 데이터를 변환하는 중 계속 실패하고, 적대적 리뷰(리뷰어 역할의 AI 에이전트가 코드를 공격적으로 검증하는 방식)를 몇 차례 돌렸는데도 문제가 반복된다는 것이었다. 설계가 처음부터 잘못됐다면 리뷰만 반복해선 개선되지 않는다는 진단이 방에서 먼저 나왔다.

이 진단은 코드 리뷰 연구와도 맞아떨어진다. 리뷰어가 의도된 아키텍처를 알고 있어야 구조적 문제를 짚어낼 수 있는데, 대부분의 리뷰는 그 맥락 없이 디프(diff) 단위로만 진행된다는 지적이 있다. 리뷰가 문법과 스타일에 집중할수록 아키텍처·보안·의도 같은 더 깊은 문제는 놓치기 쉽다.

AI 에이전트를 여러 개 띄워 서로 검증하게 하는 멀티 에이전트 리뷰도 마찬가지다. 에이전트 수를 늘려도 저장소 규모의 과제에서는 얻는 게 갈수록 줄어든다는 연구 결과가 나왔다. 최근 흐름은 여러 에이전트가 독립적으로 토론하는 방식 대신, 메인 에이전트가 서브에이전트를 도구처럼 쓰는 쪽으로 옮겨가고 있다.

리뷰는 증상을 고치는 데는 능하지만 원인을 찾는 데는 그렇지 않다. 반복 실패하는 데몬은 프롬프트를 한 번 더 넣는다고 해결되지 않는, 구조 자체의 문제일 가능성이 크다.

바이브코딩이 쌓아 올리는 기술부채, 수치로 확인되는 추세

방에서는 바이브코딩으로 빠르게 만들다 보니 기술부채가 쌓였다는 진단이 나왔는데, 이 흐름은 대규모 코드 분석에서도 확인된다. 코드 리뷰 분석 업체 깃클리어(GitClear)가 2억 1100만 줄 규모의 코드 변경을 분석한 보고서에 따르면, 2024년 한 해 동안 중복 코드 블록 발생 빈도가 여덟 배로 늘었다. 커밋 안에서 코드를 복사해 붙여넣는 비중이 기존 코드를 옮겨 재사용하는 비중을 넘어선 것도 2024년이 처음이었다.

코드 처지(커밋 2주 안에 다시 고치거나 지우는 코드 비율)는 2020년 3.1%에서 2024년 5.7%로 늘었고, 전체 변경 중 리팩토링이 차지하는 비중은 2021년 25%에서 2024년 10% 아래로 줄었다. AI가 코드를 만들어내는 속도를 리팩토링이 따라가지 못한다.

스택오버플로의 2025년 개발자 설문에서도 비슷한 신호가 잡혔다. 응답자의 84%가 AI 도구를 쓴다고 답했지만, AI의 정확성을 신뢰한다는 응답은 33%로 1년 전보다 낮아졌다. AI가 내놓은 답이 거의 맞지만 완전히는 아니라는 점을 가장 큰 불만으로 꼽은 비율이 66%였고, 45%는 AI가 만든 코드를 디버깅하는 데 예상보다 시간이 더 든다고 답했다.

리뷰보다 리뷰 결과를 판단하는 능력이 더 중요한 이유

방에서 나온 또 다른 지적은, 리뷰 자체보다 리뷰 결과가 맞는지 판단해 방향을 잡아주는 능력이 더 중요하다는 것이었다. 이 지적은 위의 설문 결과와 이어진다. AI가 내놓는 답이 거의 맞다면, 그 답을 그대로 받아들일지 의심할지 판단하는 몫은 사람에게 남는다.

관련 연구에서는 AI가 짠 코드에 대한 회의적 태도가 오히려 리뷰의 깊이와 효과를 높인다는 결과도 나왔다. 리뷰어가 겉보기에 그럴듯한 코드를 곧이곧대로 믿지 않을 때, 리뷰가 더 꼼꼼해지고 부담은 줄어든다. 적대적 리뷰를 도입한 이유도 이 회의적 시선을 구조화하려는 시도에 가깝다.

다만 멀티 에이전트 리뷰의 비용 대비 효과를 의심하는 반응도 있다. 리뷰 도구에 적잖은 비용을 쓰고도 하루 30분 아끼는 데 그쳤다는 계산이 맞지 않는다는 목소리가 실사용자들 사이에서 나온 적도 있다. 리뷰를 무한정 반복하기보다 인증·결제·마이그레이션처럼 실패 비용이 큰 지점에 선택적으로 쓰라는 조언이 이런 맥락에서 나온다.

설계에 며칠을 투자하면 실제로 달라지나

방에서는 설계 단계에 며칠을 투자한 뒤 결과물 품질이 확실히 좋아졌다는 공감 사례도 공유됐다. 이 경험은 최근 부상한 스펙 주도 개발 논의와 겹친다. 요구사항과 제약, 예외 상황을 코드를 쓰기 전에 먼저 정의해두면 이후 반복 수정에 드는 시간이 줄어든다.

앤스로픽이 클로드 코드에 넣은 플랜 모드도 같은 문제의식에서 나왔다. 플랜 모드에서는 클로드가 파일을 읽기만 할 뿐 쓰거나 실행하지 못하고, 무엇을 건드릴지와 위험 요소를 먼저 정리해 승인을 받은 뒤에야 코드를 바꾼다. 코드부터 쓰고 나중에 검증하는 순서를, 검증부터 하고 코드를 쓰는 순서로 뒤집은 셈이다.

기술부채라는 개념을 처음 제안한 워드 커닝엄의 정의를 보면 이 접근이 왜 통하는지 짐작할 수 있다. 그는 기술부채를 개발자가 도메인을 이해한 정도와 실제 시스템이 반영하는 이해 사이의 거리라고 설명했다. 설계에 시간을 쓰는 일은 그 거리를 코드를 쓰기 전에 좁히는 작업에 가깝다.

리팩토링으로 넘어갈 신호와 다시 설계해야 할 신호

문제는 언제 리뷰를 접고 리팩토링으로, 나아가 재설계로 넘어가야 하느냐다. 업계에서 통용되는 기준은 비교적 단순하다. 코드 품질은 나쁘지만 그 코드가 구현하는 비즈니스 로직 자체는 타당하다면 리팩토링으로 충분하다. 로직 자체가 잘못됐거나 구조가 매 변경마다 저항한다면 다시 설계하는 쪽이 낫다.

같은 자리에서 반복해서 실패하는 서버 데몬은 후자에 가까운 신호다. 적대적 리뷰가 매번 다른 증상을 잡아내는데도 실패가 재발한다면, 그 증상들이 공통으로 가리키는 구조적 원인이 따로 있을 가능성이 크다. 방에서 나온 문제 발생 시 아예 리팩토링하라는 조언은 이 신호를 놓치지 말라는 뜻으로 읽힌다.

다만 전면 재작성은 신중해야 한다. 실패율이 60~80%에 이른다는 업계 추정도 있고, 예상 비용을 최소 두 배로 잡아야 안전하다는 조언도 있다. 리팩토링과 재설계 사이에서, 데몬이 실패하는 지점이 코드 몇 줄이 아니라 데이터가 흐르는 경로 자체인지부터 확인하는 편이 순서에 맞는다.

개인 개발자와 소규모 팀이 지금 바꿀 수 있는 것

이 흐름이 1인 개발자나 소규모 팀에 갖는 의미는 구체적이다. 적대적 리뷰를 모든 커밋에 걸 필요는 없다. 인증·결제·데이터 마이그레이션처럼 실패 비용이 큰 경로에만 선택적으로 적용해야 비용 대비 효과가 맞는다는 조언과도 통한다.

같은 리뷰 도구가 같은 파일에서 세 번 이상 비슷한 지적을 반복한다면 그 자체를 신호로 삼을 만하다. 프롬프트를 더 정교하게 다듬기보다 그 파일이 속한 모듈의 설계를 다시 열어보는 편이 비용이 덜 든다. 방에서 공유된 경험도 이 판단과 같은 방향을 가리켰다.

새 기능을 바이브코딩으로 빠르게 붙이기 전에 플랜 모드든 별도 스펙 문서든, 코드를 쓰기 전 단계를 하나 끼워 넣는 편이 낫다. 인력이 적을수록 쌓인 기술부채를 나중에 되짚어 이해할 사람도 적다는 점에서, 초기 설계 투자의 효과는 팀 규모가 작을수록 오히려 크다.

적대적 리뷰를 세 라운드째 돌리고도 같은 데몬이 같은 자리에서 죽는다면, 네 번째 리뷰보다 설계 문서를 다시 펴보는 쪽이 더 짧은 경로였다는 게 이번 사례가 남긴 판단이다.