AI가 코드를 짜는 시대, 코드 리뷰는 무엇을 봐야 하나
출처: zanlib.dev 블로그 (GeekNews 요약 경유)
원문: https://zanlib.dev/blog/do-you-still-read-the-code/ (GeekNews: https://news.hada.io/topic?id=33735)
작성자: 팔복소프트-김팔복
한눈에 보기
- AI 코딩의 분기점은 생성 코드 비율이 아니라 결과물을 누가 이해하고 유지보수하느냐입니다.
- 필자는 이해를 지키며 속도를 내는 '가속형 개발자'와 구현을 맡기는 '바이브코더'를 구분합니다.
- 두 방식이 섞인 팀이 유지보수 경계를 정하지 않으면 양쪽 모두 비용을 치릅니다.
- 가장 위험한 건 선택한 적도 없이 코드 이해를 잃어가는 상태입니다.
- 모든 줄을 읽어도 "왜 이 값인가"라는 의도 부채는 남습니다.
배경
바이브 코딩(vibe coding)은 코드를 거의 보지 않고 자연어 지시와 결과 확인만으로 개발하는 방식입니다. 에이전트형 코딩 도구가 흔해지면서 한 사람이 만드는 코드량은 크게 늘었지만, 리뷰하는 사람의 시간은 그대로입니다. 이 글은 그 간극에서 "사람이 계속 코드를 읽어야 하나"를 다룬 에세이입니다.
주요 내용
두 작업 방식 비교
| 구분 | 가속형 개발자 | 바이브코더 |
|---|---|---|
| AI의 위치 | 편집기 확장 | 컴파일러 같은 추상화 |
| 사람의 책임 | 구현 이해와 설명 | 명세, 인수 기준, 평가 |
| 쌓이는 부채 | 인지 부채 (리뷰가 생성 속도를 못 따라감) | 의도 부채 (요구사항 맥락 유실) |
| 주요 리스크 | 리뷰 병목, 번아웃 | 세션 간 맥락 손실, 모델 품질 의존 |
가속형도 코드 대부분을 생성할 수 있습니다. 차이는 master 병합 시점에 사람이 구현을 이해하고 있느냐입니다.
구현은 명세를 고치는 과정
필자는 Peter Naur의 Programming as Theory Building을 근거로, 핵심 자산은 코드가 아니라 개발자가 가진 도메인 모델이라고 봅니다. 엣지 케이스를 구현하다 보면 합의했던 개념이 깨지고 요구사항이 바뀝니다. 테스트 통과는 지시대로 동작한다는 뜻이지 지시가 옳다는 뜻이 아니므로, 명세와 실행만으로 이 이해를 대체할 수 있을지는 유보합니다.
문제는 '무의식적인 이탈'
diff를 읽지 않고 훑기 시작하고, 구현 이유가 떠오르지 않으며, 결국 모델에게 무엇을 만들었는지 묻지만 그 답을 검증할 수 없는 상태입니다. 필자는 이것을 두 방식의 중간이 아니라, 명세와 평가 체계 없이 바이브코더가 된 상태로 봅니다. 같은 사람이 탐색용 프로젝트에서는 의도적으로 위임하는 것 자체는 문제가 아닙니다.
의도 부채의 예
비밀번호 재설정 링크의 expiryTime = 6h는 코드만 봐서는 업무 요구인지, 관례인지, 추측인지 알 수 없습니다. 리뷰어는 요구사항, 의도적 결정, 물려받은 관례, 근거 없는 선택을 구분해 기록해야 합니다. 에이전트가 테스트 실행 시간이 3배로 늘어난 걸 무시하거나, React 컴포넌트 안에 컴포넌트를 선언하는 식의 실수도 사례로 나옵니다. 보조 도구로 Crit, CodeRabbit Change Stack을, 반대 극단으로 사람이 코드를 쓰지도 검토하지도 않는 StrongDM의 소프트웨어 팩토리를 소개합니다.
남은 질문
리뷰만으로 코딩 역량이 유지될지는 모릅니다. 필자는 Bainbridge의 Ironies of Automation을 들어, 숙련 유지용 수동 코딩이 필수 비용이 될 수 있다고 봅니다.
팔복소프트 관점
- 외주·SI 인수인계에서 먼저 문제가 됩니다. 구현을 위임해 만든 납품물을 받은 운영팀은 존재한 적 없는 이해를 복원해야 합니다. 산출물에 모듈별 개발 방식과 검증 시나리오 위치를 명시하도록 요구할 만합니다.
- 경계 합의는 단순하게 시작하면 됩니다. 어드민·프로토타입은 위임 허용, 인증·결제는 작성자가 설명할 수 있어야 병합. CODEOWNERS와 PR 템플릿으로 강제할 수 있습니다.
- 의도 부채는 새 문제가 아닙니다. ADR과 매직 넘버 주석으로 다뤄온 문제이고, 달라진 건 근거 없는 선택이 생기는 속도입니다. PR 템플릿에 "사람이 정한 값"을 적는 칸 하나가 저렴한 대응입니다.
- 주니어 육성은 따로 설계해야 합니다. 리뷰만 하는 주니어는 책임은 지면서 역량을 쌓을 기회는 없습니다. 일부 작업을 의도적으로 직접 구현하게 하는 것은 교육비이자 장애 대응 보험입니다.
- 외부 모델 의존도도 따져봐야 합니다. 사내 규정상 외부 AI API 사용이 제한되는 조직이라면, 쓸 수 있는 모델의 성능이 곧 위임 가능한 범위의 상한이 됩니다.
- 한계도 분명합니다. 두 유형 구분에 실증 데이터는 없습니다. 팀 정책의 근거보다는 회고 질문으로 쓰는 편이 맞습니다.
정리
기억할 질문은 하나입니다. "이 코드가 망가지면 누가, 무엇을 근거로 고치는가." 답이 사람의 이해라면 읽어야 하고, 명세와 테스트라면 그것부터 갖춰야 합니다.
- 바이브코딩
- AI코딩
- 코드리뷰
- 기술부채
- 개발문화
아직 댓글이 없습니다.