생산성이라는 이름의 비용 떠넘기기

AI가 만든 수백, 수천 줄의 코드가 한꺼번에 올라옵니다. 작성자는 빠르게 만들었다고 말하지만 리뷰어는 그제야 코드의 의도와 위험을 처음부터 파악해야 합니다.

제가 불편하게 느끼는 것은 AI가 코드를 쓰는 일 자체가 아닙니다. 그 뒤에 따라오는 두 가지 태도입니다.

• 자신도 충분히 읽고 검증하지 않은 코드를 올린 뒤 첫 검증까지 리뷰어에게 떠넘기는 태도.
• 리뷰하기 싫다는 개인의 편의를 ‘혁신’이나 ‘AI 시대의 일하는 방식’으로 포장해 대안 없이 조직의 검증 절차를 없애려는 태도.

둘 다 생산성이라는 이름으로 등장합니다. 첫 번째는 작성자가 치러야 할 비용을 동료에게 넘기고 두 번째는 개인의 편의를 위해 조직의 검증 방식을 망가뜨립니다.

저는 구현과 조사, 테스트와 문서화에 AI를 적극적으로 씁니다. 코드 리뷰를 모든 변경이 반드시 통과해야 하는 성역으로 남겨두자는 생각도 없습니다. AI가 코드 생성의 속도와 규모를 바꾸었다면 리뷰와 테스트, 배포 방식도 달라져야 합니다.

두 태도의 공통점은 책임의 공백을 만든다는 데 있습니다. 작성자가 첫 검증을 넘기거나 조직이 대안 없이 검증 절차를 걷어내면 실패 비용은 사라지지 않습니다. 누군가에게, 대개는 더 비싼 자리로 이동합니다.

자신이 제출한 코드를 책임지지 않는 것

AI는 코드의 생성 비용을 크게 낮췄습니다. 설명 몇 줄이면 그럴듯한 구현이 나오고, 이전보다 훨씬 큰 변경도 짧은 시간 안에 만들 수 있습니다. 여기까지는 분명한 이점입니다.

문제는 그다음입니다. 코드를 만드는 데 걸린 시간이 줄었다고 해서 그 코드가 맞는지 확인하는 시간까지 함께 줄어드는 것은 아닙니다. Addy Osmani가 2024년 비개발자의 AI 코딩에서 관찰한 ‘70% 문제’처럼 프로토타입은 빠르게 만들 수 있어도 유지보수 가능하고 견고한 제품으로 완성하는 마지막 구간에는 엔지니어링 판단이 필요합니다.

그 일을 작성자가 하지 않으면 사라지는 게 아닙니다. 리뷰어에게 넘어갑니다.

여기서 생산성의 단위를 개인이 아니라 팀으로 바꿔야 합니다. 작성 시간만 줄고 검토와 재작업, 장애 대응 시간이 늘었다면 생산성이 오른 것이 아닙니다. 비용의 발생 시점과 담당자가 달라졌을 뿐입니다. 팀의 생산성은 생성한 코드의 양보다 검증과 전달을 마친 결과와 그 과정에 든 총비용으로 판단해야 합니다.

이것은 단순히 리뷰어가 피곤해진다는 이야기도 아닙니다. Google의 코드 리뷰 지침은 작은 변경이 더 빠르고 철저하게 검토되며, 큰 변경은 이해하기 어려워 버그가 생기거나 중요한 지적이 놓치기 쉽다고 설명합니다. AI로 수백 줄을 빠르게 만들었더라도 그것을 한꺼번에 넘기는 순간 개인의 처리량은 늘고 팀이 실제로 검증할 수 있는 범위는 줄어들 수 있습니다.

Simon Willison은 검토하지 않은 AI 코드를 동료에게 보내는 일을 협업의 안티패턴으로 꼽습니다. 수백 줄의 변경을 직접 확인하지 않고 올리는 것은 리뷰를 요청하는 일이 아니라 실제 작업을 다른 사람에게 위임하는 것에 가깝다는 것입니다.

여기에는 이런 반론이 있을 수 있습니다. AI가 만든 코드를 사람이 다시 전부 읽어야 한다면 무엇이 생산적이냐는 것입니다. 맞는 말입니다. 모든 줄을 같은 깊이로 읽을 필요는 없습니다. 테스트와 타입, 정적 분석으로 사람이 확인할 범위를 줄일 수 있습니다.

다만 줄을 덜 읽는 것과 결과를 덜 책임지는 것은 같은 말이 아닙니다. 책임의 기준은 모든 줄을 직접 읽었는지가 아니라 결과를 신뢰할 근거를 제시할 수 있는지에 있습니다. 작성자는 적어도 무엇을 만들었는지, 어떤 근거로 안전하다고 판단했는지, 무엇이 아직 불확실한지 설명할 수 있어야 합니다.

리뷰어는 코드만 읽지 않습니다. 작성자가 확인했어야 할 동작을 다시 확인하고, 설명되지 않은 선택의 이유를 추측하고, 빠진 위험까지 찾아야 합니다. 작성자의 작업은 빨라졌지만 팀 전체로 보면 비용이 옆자리로 이동했을 뿐일 수 있습니다.

생성 비용이 싸졌다고 해서 검증 비용까지 사라지는 것은 아닙니다.

망가진 리뷰는 검증을 버릴 면죄부가 아니다

“어차피 리뷰도 제대로 안 하는데 그냥 없애자”는 말은 브레이크가 잘 듣지 않는다고 아예 떼어내자는 말과 같습니다. 제대로 작동하지 않는 상태와 아예 없는 상태를 같은 것으로 놓고, 리뷰의 실패에서 검증의 불필요를 끌어내는 논리적 비약입니다. 그렇게 얻은 속도는 사고가 나기 전까지만 유지됩니다.

형식적인 승인, 사소한 취향 논쟁, 며칠씩 이어지는 대기는 분명 실패한 리뷰입니다. 그렇다면 실패 원인을 고치거나 더 나은 검증으로 바꿔야 합니다. 리뷰의 낮은 품질은 검증 자체를 폐기할 근거가 되지 않습니다.

다만 PR에 승인 하나를 남기는 절차와 리뷰가 수행하던 기능은 구분해야 합니다. Google의 코드 리뷰 지침은 설계와 동작, 복잡도, 테스트, 문서, 시스템 전체의 맥락까지 확인하도록 합니다. 리뷰어에게 모든 것을 맡기라는 뜻이 아닙니다. 작성자가 충분히 테스트한 변경을 가져온다는 전제에서 리뷰어는 경계 조건과 잘못된 가정, 장기적인 코드 건강을 한 번 더 살핍니다.

리뷰가 하던 일은 결함 찾기만도 아니었습니다. Microsoft 여러 팀에서 진행된 2013년 코드 리뷰 연구는 리뷰의 실제 결과로 지식 이전, 팀의 변경 인식, 다른 해결책의 발견을 함께 확인했습니다. 코드 리뷰는 품질 게이트인 동시에 한 사람의 머릿속에 있던 변경 이유와 위험을 팀의 맥락으로 옮기는 자리였습니다.

그래서 “리뷰를 하지 않는다”는 말만으로는 무엇이 달라지는지 알 수 없습니다. 없애려는 것이 취향 논쟁인지, 독립적인 검증인지, 설계 합의인지, 지식 공유인지부터 분해해야 합니다. 이 구분 없이 리뷰를 통째로 낡은 관습이라 부르면 절차와 함께 필요한 기능도 버립니다.

리뷰를 없애려면 먼저 그 일을 옮겨야 한다

리뷰가 맡던 기능은 각각 더 적합한 방식으로 옮길 수 있습니다.

• 포맷과 명명 규칙, 금지된 패턴은 포매터와 린트, 정적 분석과 정책 검사로 옮깁니다.
• 타입과 계약, 알려진 회귀는 타입 검사와 단위·통합·계약 테스트로 확인합니다.
• 설계 방향과 제품 의도는 구현 전 명세와 RFC·ADR, 도메인 소유자와의 설계 검토에서 맞춥니다.
• 변경 이유와 팀의 맥락은 작은 PR과 검증 근거가 담긴 설명, 페어링과 담당 순환으로 공유합니다.
• 운영 중 드러나는 실패는 기능 플래그와 점진 배포, 관측 가능성과 빠른 롤백으로 다룹니다.

이 중 아무것도 만들지 않은 채 리뷰만 없애면 리뷰의 기능은 그대로 비어 있습니다. 독립적인 확인 절차도 사라져 오류의 발견 시점만 운영 환경까지 늦어집니다.

반면 테스트가 통과했다는 사실만으로 제품 의도가 맞았다고 증명되지는 않습니다. 테스트도 코드이고 잘못 이해한 요구사항을 충실하게 검사할 수 있습니다. 특히 같은 AI가 구현과 테스트, PR 설명까지 한꺼번에 만들면 하나의 오해가 세 군데에 일관되게 복제될 수 있습니다. 초록색 체크가 많아졌는데 독립적인 근거는 하나도 늘지 않는 상황입니다.

검증에는 적어도 하나의 독립된 축이 필요합니다. 구현 전에 합의한 계약, 기존 운영 동작을 기록한 특성화 테스트(characterization test), 제품 지표와 불변식, 해당 맥락을 아는 다른 사람의 판단 같은 것입니다. AI를 한 번 더 호출하는 것도 보조 수단은 되지만 같은 입력과 가정을 공유한다면 독립적인 검증이라고 보기 어렵습니다.

Charity Majors는 코드 줄을 사람의 유일한 검토 대상으로 붙들기보다 테스트와 평가, 관측 가능성으로 엄격함을 옮겨야 한다고 주장합니다. 이 방향에 동의합니다. 이를 뒷받침할 관측 가능성과 점진 배포, 롤백 능력 없이 프로덕션으로 보내면 검증을 장애에 외주 주게 됩니다.

‘리뷰 없음’은 출발점이 아니라 결과다

리뷰 없는 개발 방식은 선언한다고 생기지 않습니다. 변경을 작게 만들고 실패를 기계적으로 검출하며 문제가 생겨도 피해를 제한할 수 있게 만든 팀이 얻는 결과입니다. AI가 코드의 양을 늘렸다는 사실은 검증을 줄일 근거가 아니라 기존 통제가 그 속도를 감당하는지 드러내는 압력 테스트에 가깝습니다.

모든 변경에 같은 리뷰를 요구하면 생성 속도를 감당하지 못합니다. 그러나 모든 변경에서 리뷰를 빼면 위험의 차이까지 지워집니다. 검증 경로는 변경의 실패 비용을 따라 나뉘어야 합니다.

• 포맷 변경, 신뢰하는 코드모드(codemod), 생성 파일처럼 결과를 기계적으로 재현하고 비교할 수 있는 변경은 자동 게이트로 처리합니다.
• 범위가 좁은 기능 변경은 작성자의 검증 근거와 테스트를 먼저 요구하고, 사람은 제품 의도와 경계 조건처럼 자동화가 놓치기 쉬운 부분에 집중합니다.
• 인증과 결제, 권한, 데이터 마이그레이션처럼 실패 비용이 큰 변경은 작성자와 독립된 관점의 검토, 점진 배포와 롤백 계획까지 요구합니다.

여기서 사람의 리뷰가 꼭 코드 한 줄씩을 읽는 형태일 필요는 없습니다. 명세와 아키텍처, 테스트의 기대 결과, 배포 계획을 먼저 검토하고 생성된 구현은 강한 자동 검증에 맡길 수도 있습니다. 사람이 봐야 할 대상을 코드에서 의도와 위험으로 옮기는 것입니다.

Martin Fowler는 사람이 코드를 보지 않는 바이브 코딩(Vibe Coding)과 사람이 결과를 감독하고 책임지는 에이전틱 프로그래밍(Agentic Programming)을 구분합니다. 이 구분은 키보드의 주인보다 검증 근거와 책임의 주체를 묻습니다.

따라서 리뷰를 없애자고 주장하는 쪽에 입증 책임이 있습니다. 기존 리뷰가 확인하던 위험과 공유하던 맥락이 무엇이었는지, 그것을 이제 어느 장치가 맡는지, 그 장치가 놓친 실패를 어떻게 발견하고 복구할지 설명해야 합니다.

이 질문에 답하지 못하면서 “어차피 리뷰어도 제대로 안 본다”고 말하는 것은 개인의 태도 문제를 조직의 정책으로 확대하는 일입니다.

같은 원칙은 리뷰를 요청할 때도 적용됩니다. 작성자는 무엇을 의도했고 어떻게 검증했으며 무엇이 아직 불확실한지 설명할 수 있어야 합니다. AI가 작성했다는 사실은 이 책임을 줄여주는 사유가 아닙니다.

리뷰어는 작성자의 첫 번째 검증자가 아니라, 작성자의 검증을 한 번 더 확인하는 사람이어야 합니다.

도구로 아낀 시간을 동료의 검증 시간으로 지불하면서 그것을 생산성이라고 부를 수는 없습니다. 리뷰어마저 없앤 뒤 사용자의 신고와 운영 장애로 검증한다면 비용이 사라진 것도 아닙니다. 가장 비싼 자리로 옮겨갔을 뿐입니다.