AI 코딩 에이전트 시대의 코드 리뷰 — 무엇이 바뀌었나

AI 코딩 에이전트가 코드를 쏟아내기 시작하면서, 정작 조용히 뒤집힌 건 코드 리뷰다. 예전엔 사람이 쓴 코드를 사람이 봤다. 지금은 에이전트가 쓴 코드를 사람이 본다. 코드를 짜는 시간은 줄었는데, 읽고 검증하는 부담은 오히려 늘었다. 개발자의 하루에서 무게중심이 작성에서 판독으로 옮겨간 것이다.

이건 단순히 "리뷰할 코드가 많아졌다"는 양의 문제가 아니다. 리뷰에서 무엇을 봐야 하는가가 바뀌었다. 사람이 짠 코드의 실수와 에이전트가 짠 코드의 실수는 성격이 다르기 때문이다. 이 차이를 모르면, 예전 방식대로 리뷰하다가 엉뚱한 걸 놓친다.

에이전트 코드가 틀리는 방식

사람은 오타를 내고, 세미콜론을 빠뜨리고, 명백한 실수를 한다. 이런 건 컴파일러나 린터가 잡는다. 에이전트는 이런 실수를 거의 안 한다. 대신 다르게 틀린다. 문법은 완벽한데 요구사항을 미묘하게 오해한다. 존재하지 않는 함수를 그럴듯하게 지어 부르고, 경계 조건을 슬쩍 놓치고, 겉보기엔 맞지만 엣지 케이스에서 무너지는 코드를 낸다. 무엇보다 확신에 차 있다. 주석까지 깔끔하게 달아놔서, 코드가 자기가 맞다고 주장하는 느낌이 든다.

나는 에이전트가 만든 함수가 너무 깔끔해서 그냥 통과시켰다가, 나중에 그 함수가 특정 입력에서 조용히 잘못된 값을 반환하는 걸 발견한 적이 있다. 사람이 짰으면 어딘가 어설퍼서 의심했을 텐데, 매끈하니까 방심했다. 이게 에이전트 코드 리뷰의 함정이다.

리뷰의 초점이 바뀐다

그래서 봐야 할 것이 달라진다. 스타일이나 문법은 어차피 깔끔하니 거기 시간을 쓸 이유가 없다. 대신 이런 걸 본다.

• 의도 일치 — 이 코드가 내가 원한 것을 하는가. 그럴듯한 다른 걸 하는 게 아니라.
• 존재 검증 — 부르는 함수·API가 실제로 존재하고 그렇게 동작하는가.
• 경계와 예외 — 빈 입력, 실패, 동시성 같은 엣지에서 무너지지 않는가.
• 맥락 적합성 — 우리 코드베이스의 규칙·패턴과 맞는가. 일반론으로 짜서 겉도는 건 아닌가.

작은 단위로 받기

실무에서 통한 방법 하나. 에이전트에게 거대한 변경을 한 번에 시키지 않는다. 수백 줄이 한꺼번에 오면 사람이 제대로 못 읽고 결국 대충 넘긴다. 작은 단위로 쪼개 받으면, 각 조각을 실제로 이해하고 검증할 수 있다. 리뷰의 병목은 이제 사람의 이해 대역폭이라서, 그 대역폭에 맞게 변경 크기를 조절하는 게 핵심이 됐다.

책임은 여전히 사람에게

바뀌지 않은 것도 있다. 코드를 병합하고 배포하는 순간, 그 코드의 책임은 에이전트가 아니라 사람에게 있다. "AI가 짰다"는 변명은 프로덕션에서 통하지 않는다. 그래서 이해하지 못한 코드는 병합하지 않는다는 원칙이 더 중요해졌다. 에이전트는 초안을 놀랍도록 빨리 만들어주지만, 그걸 이해하고 책임지는 건 끝까지 사람의 몫이다. 코딩이 빨라진 만큼, 판단은 더 또렷해져야 한다.

자주 묻는 질문

에이전트 코드는 왜 리뷰가 더 어렵나요?

겉이 매끄럽기 때문이다. 문법·스타일·주석이 깔끔해서 신뢰가 가지만, 정작 요구사항을 미묘하게 오해하거나 엣지 케이스에서 무너지는 논리적 결함이 숨어 있을 수 있다. 사람이 짠 어설픈 코드는 의심하게 되는데, 매끈한 코드는 방심하게 된다. 그래서 표면이 아니라 의도와 논리를 파고드는 리뷰가 필요하다.

무엇을 중점적으로 봐야 하나요?

스타일보다 "이 코드가 내가 원한 걸 정확히 하는가"다. 부르는 함수·API가 실제로 존재하는지, 빈 입력·실패·경계값에서 잘 버티는지, 우리 코드베이스의 규칙과 맞는지를 본다. 린터가 잡는 것에 시간을 쓰지 말고, 사람만이 판단할 수 있는 의도 일치와 논리적 타당성에 집중하는 게 효율적이다.

변경을 작게 받는 게 왜 중요한가요?

리뷰의 병목이 사람의 이해 대역폭으로 옮겨갔기 때문이다. 한 번에 수백 줄이 오면 제대로 읽지 못하고 대충 승인하게 되어, 결함이 그대로 들어간다. 작은 단위로 쪼개 받으면 각 조각을 실제로 이해하고 검증할 수 있다. 에이전트는 큰 변경도 순식간에 만들지만, 그걸 소화하는 사람의 속도에 맞춰 크기를 통제하는 편이 안전하다.