코드 리뷰가 서서히 무너지고 있습니다. 어떻게 대응하시나요?

AI 요약

코딩 에이전트는 팀의 개발 속도를 높였지만, 코드 리뷰를 생략하면서 작성자가 코드와 설계를 충분히 이해하지 못하는 문제가 생겼습니다. 글쓴이는 그 결과로 임시방편이 좋은 구현의 본보기처럼 복제되고, 성능 저하와 경쟁 상태(race condition), 에이전트의 혼란이 빠르게 늘어날 수 있다고 설명합니다. 사람이 리뷰하던 과거의 기준을 그대로 적용하기 어렵더라도, 코드 품질을 신경 쓰지 않아도 된다는 뜻은 아니라고 말합니다.

리뷰가 줄어든 다섯 달

팀은 새 제품을 만드는 동안 출시 압박이 적다는 이유로 코드 리뷰를 선택 사항으로 바꿨습니다. 처음에는 대부분 PR을 검토했지만, 리뷰를 기다리지 않고 몇 분 만에 배포하는 속도에 익숙해지면서 리뷰 수가 줄었습니다. 작성자가 에이전트가 만든 코드를 직접 읽고 이해하도록 했고, 서로 다른 지시를 받은 에이전트 세 개가 검토하는 단계도 넣었습니다. 하지만 사람과 에이전트의 검토도 병목으로 느껴지자, 폐기할 가능성이 높은 UI나 온보딩 같은 ‘검증(Validation)’ 작업은 대충 확인하고, 전환 뒤에도 남길 인프라 작업만 꼼꼼히 보는 방식으로 바꿨습니다.

그마저 오래가지 않았습니다. PR 리뷰는 작성자가 코드와 에이전트의 선택을 이해하게 만드는 강제 장치였는데, 리뷰가 선택 사항이 되자 코드 이해 수준도 함께 낮아졌습니다. 글쓴이의 팀은 하루 PR 수가 4건에서 8월에는 28건으로 늘었고, 코드 리뷰 비율은 100%에서 해당 월 2%까지 떨어졌다고 밝힙니다. 산출량은 약 8배 늘었습니다. 글쓴이는 코딩 에이전트를 쓰는 조직에서 최근 2년간 PR 수가 3배 늘었다는 수치도 인용합니다.

깨진 창문이 빠르게 복제됩니다

글쓴이는 깨진 창문 이론을 코드베이스에 빗댑니다. 방치된 창문이 더 큰 훼손을 부르듯, 대충 만든 코드가 남아 있으면 다음 에이전트가 이를 기존의 표준으로 받아들이고 비슷한 코드를 반복해서 만듭니다. 사람 손으로 쌓이는 코드 부채는 수년에 걸쳐 드러날 수 있지만, 에이전트가 코드를 대량 생성하면 그 과정이 몇 달, 며칠로 짧아질 수 있다는 주장입니다.

근거로 해커톤 경험도 소개합니다. Lovable로 만든 서비스는 첫날 프로젝트의 90%를 마친 듯했지만, 마지막 날에는 사소한 개선 작업 뒤에 버그와 성능 문제가 잇따랐습니다. 하나를 고치면 다른 문제가 나타나는 상황을 ‘에이전트 두더지 잡기’에 비유합니다. 완성도 높은 코드베이스에서도 급한 수정이 리뷰 없이 들어가면, 그 임시방편을 에이전트가 따라 하면서 나쁜 패턴이 퍼질 수 있다고 설명합니다.

리뷰를 없애기보다 방식을 조정합니다

글쓴이는 과거 코드베이스도 대체로 지저분했고 버그가 많았다는 점을 인정합니다. 코드의 아름다움만을 위한 품질을 주장하는 게 아니라, 에이전트가 만든 기능이 제대로 작동한다면 예전보다 훨씬 빠른 개발이 더 나은 결과일 수도 있다고 질문합니다. 다만 리뷰에는 버그를 찾는 일 외에도 팀이 구현 방식과 설계 기준을 공유하는 역할이 있습니다. 그 기준이 있어야 다음 기능을 더 빠르게 만들 수 있다고 봅니다.

사람이 모든 코드를 직접 검토하기는 어렵지만, 아무것도 검토하지 않는 방식도 문제라고 말합니다. 글쓴이가 제안하는 방안은 PR의 약 5%라도 선택적으로 리뷰하고, 에이전트가 작성한 세부 계획을 다른 엔지니어가 검토하는 ‘계획 리뷰’를 늘리는 것입니다. 다만 계획 리뷰는 아직 직접 실험하지 않았으며, 더 나은 방법을 찾고 싶다고 덧붙입니다.

Reddit 반응

댓글에서는 코드 줄 단위 검토보다 테스트, 설계 검토, 위험도 분류를 강화하자는 의견이 나왔습니다. 반면 사람이 직접 검토하지 않으면 도메인 지식과 의도에 어긋나는 결정을 놓친다는 반론도 있습니다. 코드 리뷰가 팀과 업계 전반에서 언제부터 보편화됐는지를 두고도 이견이 오갔습니다.

• @u/maverick_soul_143747 — 요즘은 코딩을 덜 하는 대신 리뷰, 평가, 테스트를 더 합니다.
  • @u/zaidesanton — 구체적인 방법이 있나요?
  • @u/maverick_soul_143747 — 저는 먼저 논의하고 설계 명세를 만든 뒤 구현합니다. 테스트를 실행하고 필요하면 새 테스트를 추가합니다. Fable로 두세 차례 검토하고 발견 사항을 기록합니다. 마지막으로 직접 테스트하고 검토해 모두 제대로 됐는지 확인합니다. AI가 해준다고 한 시간 만에 내놓는 방식은 좋아하지 않습니다. 결국 책임은 제게 있습니다.
  • @u/enkideridu — PR 리뷰어는 원래 QA를 대신하는 역할이 아니었습니다. 테스트가 없는 기능은 실패할 거라고 봐야 하니 테스트 커버리지를 높이세요. 에이전트가 실패를 스스로 진단하도록 추적 정보와 스크린샷도 쉽게 접근하게 해야 합니다. 앱만 테스트하지 말고, CLAUDE.md나 훅, 규칙이 필요한 조건에서 컨텍스트에 들어가는지도 확인하세요. 리뷰 에이전트 하나에 모든 걸 맡기지 말고 정확성, 성능, 보안, 백엔드, 프런트엔드, 데이터베이스처럼 영역을 나누세요. 목표는 ‘사람 코드 리뷰’가 아니라 신뢰성입니다. 실패 사례를 모아 회고하고, 시스템의 어느 부분이 왜 실패했는지 살핀 뒤 가드레일과 테스트를 보강하세요.
• @u/Saltysalad — AI는 줄 단위 리뷰를 더 잘합니다. 더 많은 버그와 성능 문제를 찾습니다. 여러 리뷰 지침을 담은 팀 공용 리뷰 스킬을 만들고, 문제가 빠져나가면 지침을 갱신한 뒤 과거 변경에도 다시 적용하세요. 사람은 설계자가 더 낫습니다. 복잡한 구조와 중복, 나중에 후회할 선택을 알아차리기 때문입니다. 그래서 개발자가 리뷰 스킬을 실행해 문제가 없어질 때까지 고친 다음, 다른 사람이 줄별 검토보다 설계 관점에서 리뷰합니다.
• @u/bedroompurgatory — 코드 리뷰가 50년 동안 이어졌다는 설명은 과장입니다. 깃허브와 PR이 나오면서 의무 리뷰가 보편화된 시기는 15년 정도 전입니다. 25년간 기술 업계에서 일했지만 초반 직장에서는 리뷰가 없었습니다. 리뷰 품질도 들쭉날쭉했습니다. 꼼꼼한 줄별 검토보다 LGTM 승인만 하는 경우가 더 많았습니다. 꼼꼼한 검토가 개인 취향을 강요하는 일도 있었습니다. 저는 복잡한 SQL 쿼리 효율을 비교할 때 AI가 저보다 낫습니다. 보안은 직접 확인하고 기능은 테스트와 인수 테스트로 확인합니다. 성능 기준을 검증하는 벤치마크 테스트도 필요하지만, AI가 그쪽에서 큰 실수를 저지른 적은 없습니다.
  • @u/zaidesanton — 50년이라는 표현은 과장된 것 같습니다. 동의합니다. 사소한 취향을 강요하는 리뷰는 도움이 안 되지만, 리뷰의 가장 큰 장점은 작성자가 자기 코드를 더 잘 이해하도록 만든다는 점이라고 봅니다.
  • @u/bedroompurgatory — 작성자요? AI 이전에는 의도치 않은 결함을 만든 예외적인 경우가 아니라면 그게 문제라고 생각하지 않았습니다. 리뷰의 주된 이점은 실수를 찾고 리뷰어가 코드 영역을 이해하는 데 있다고 봅니다. 테스트가 더 잘 잡기도 합니다.
  • @u/zaidesanton — 저도 그게 주된 이점이라고 생각했습니다. 리뷰를 선택 사항으로 바꾸기 전까지는요. 다른 사람이 코드를 읽는다는 걸 알면 작성자는 코드가 이해되도록 더 노력합니다.
• @u/_lumb3rj4ck_ — 저는 코드 리뷰보다 명세(spec) 리뷰를 도입하기 시작했습니다. 사람이 읽고 이해할 수 있는 명세에는 기능을 왜 만들고, 무엇을 만들며, 어떻게 만들지 담깁니다. 결정 사항, 데이터 모델, 작업 목록, 체크리스트도 검토 대상입니다. 프레임워크는 계속 고르는 중이지만, 원칙을 따르는 한 어떤 도구를 쓰는지는 중요하지 않습니다. AI가 만든 방대한 코드를 읽느라 시간을 쓰기보다 사용 사례와 사업상 이유에 집중하고 싶습니다.
  • @u/who_am_i_to_say_so — 행동 테스트도 좋은 방법입니다. 학습과 벤치마킹에서도 구현 세부사항이 아니라 행동을 평가합니다. 구현 방식에 얽매이지 않는 유연성이 있습니다. 명세 중심 개발은 구현에 초점을 맞추고, 이 방식은 최종 결과에 초점을 맞춥니다. 둘은 함께 잘 작동합니다.
• @u/anor_wondo — 팀이 자기 코드를 이해하지 못하는 인지 부채(cognitive debt)는 어떤 방식으로든 생깁니다. 빠르고 안전하게 만드는 방법은 없습니다.
  • @u/Mindless-Tomorrow-93 — 코드베이스가 어느 정도 규모와 복잡성에 이르고 시간이 지나면 한 사람이 전부 이해할 수 없습니다. 새로운 현상은 아닙니다.
  • @u/anor_wondo — 분명 새로운 현상입니다. 그린필드 프로젝트를 처음부터 시작한 사람이 새로 온 사람만큼 아무것도 모르는 일은 예전엔 없었습니다.
  • @u/Mindless-Tomorrow-93 — 안타깝지만, 그런 일은 예전에도 있었습니다.
• @u/sebseo — 작성자가 코드를 이해하도록 강제했던 게 리뷰였다면, 이제는 줄을 읽어주는 것보다 무엇이 이해를 강제할지 물어야 합니다. 서로 다른 회사의 모델 두세 개가 따로 리뷰하게 하고, 작성자는 의견이 다른 부분만 읽는 방법이 효과 있었습니다. 이견을 해결하려면 그 코드가 왜 그렇게 됐는지 이해해야 합니다. 변경마다 사람이 확인할 부분도 몇 군데로 줄어듭니다. 작성 세션과 다른 세션의 리뷰가 놓친 가정을 찾는 데 도움이 됩니다.
• @u/usually_guilty99 — 모든 PR에 예전과 비슷한 검토 절차를 적용한다고 생각하는 게 실패 원인이라고 봅니다. 에이전트가 변경량을 늘리면 확장되지 않습니다. 어떤 의존성을 건드리는지, 영향 범위와 중요도는 어떤지, 변경 이력과 롤백 가능성은 어떤지에 따라 변경 위험도를 매겨야 합니다. 위험이 낮은 변경은 더 많이 자동으로 진행하고, 위험이 높은 변경에 사람의 주의를 써야 합니다. 앞으로의 리뷰는 코드를 더 빨리 읽는 일이 아니라 무엇을 검토할지 결정하는 일일 수 있습니다.
• @u/DasHaifisch — 사람의 코드 리뷰를 중단하면 코드 품질이 떨어진다는 건 당연하다고 봅니다. AI 리뷰가 충분히 좋다고 믿지 않으며 사람의 검토 없이 배포하는 게 놀랍습니다. 저희는 테스트, SonarQube, 변이 테스트, 커버리지, 연결 누수 검사, 여러 에이전트로 구성한 리뷰 서비스를 사용합니다. 개발자는 결과와 의견을 확인하고 문제를 고칩니다. 게이트가 통과하면 리뷰 단계로 넘깁니다. 리뷰어는 에이전트와 기존 리뷰 결과를 확인하고 PR의 모든 줄을 직접 읽습니다. 제가 주로 잡는 건 코드가 아니라 결정의 오류입니다. 도메인 지식은 제가 갖고 있기 때문입니다. 완벽하지 않고 느려지지만, 코드 품질을 유지하는 데 도움이 됩니다.

원문: Manager.dev / 번역·요약: Trawling