AI 에이전트(AI agents)는 그 어떤 인간 개발자보다 훨씬 빠르게 코드를 작성할 수 있으며, 단 한 번의 프롬프트(prompt) 결과로 수백, 수천 줄의 코드를 얻을 수 있기 때문에 세심한 코드 리뷰(code review)의 필요성은 그 어느 때보다 커졌습니다. 코드 리뷰는 코드가 엔지니어링 가이드라인과 아키텍처 원칙(architectural principles)을 따르고 있는지 확인하는 동시에, 장기적인 유지보수성(maintainability)과 확장성(extensibility)을 보장하는 핵심적인 메커니즘으로 남아 있습니다.

vibe coding traps and delusions에 관한 이전 포스트 중 하나에서, 저는 왜 그리고 어떻게 인지 부하(cognitive load)가 코드 생성(code generation)에서 코드 리뷰(code review)로 이동하는지, 그리고 왜 이것이 동료 개발자들로부터 점점 더 많은 관심을 받아야 하는 주제라고 생각하는지에 대한 제 생각을 공유한 바 있습니다. 이 글에서는 코딩 에이전트(coding agents)와 1년 이상 활발하게 작업하며 제가 바라보는 코드 리뷰에 대한 접근 방식을 설명합니다.

작성자에 의한 능동적 코드 리뷰

동료 리뷰(peer review)를 요청하기 전에, 작성자는 마치 타인의 작업물을 검토하는 것처럼 생성된 코드에 대해 능동적인 리뷰를 수행해야 합니다. AI 이전에는 개발자들이 코드 작성에 직접 참여했기 때문에 보통 모든 줄을 이해하고 있었습니다. 오늘날 개발자들은 모든 세부 사항을 직접 작성하기보다는 구현을 가이드하는 경우가 많습니다. 그렇기 때문에, 에이전트가 의도한 대로 생성했는지 확인하기 위해 명시적인 셀프 리뷰(self-review)를 수행하는 것이 훨씬 더 중요해졌습니다.

이는 논리적인 단계로 이해될 수 있지만, 에이전트가 포괄적인 구현(implementation)을 작성하고 생성된 코드의 구문(syntax)이 매우 설득력 있게 보이기 때문에, 에이전트로부터 나오는 모든 출력이 정확하다고 믿어버리고 세부 사항에 충분한 주의를 기울이지 않기 쉽습니다. 가장 먼저 확인해야 할 사항은 생성된 코드가 제품의 아키텍처 원칙(architecture principles)과 일치하는지, 그리고 코드가 올바른 문제를 해결하고 있는지 아니면 새로운 문제를 만들어내고 있는지 여부입니다.

또 다른 단계는 가능한 한 적은 코드로 동일한 기능을 구현하려고 시도하는 것입니다. LLM(Large Language Models)은 기본적으로 원래 그래야 하는 것보다 더 많고 때로는 더 복잡한 코드를 생성하기 때문에, 그 모든 코드가 정말 필요한지 확인해야 합니다. 대부분의 경우 코드는 단순화될 수 있으며, 우리는 가능한 한 이를 고수해야 합니다. 물론 처음에는 원하는 출력이 나올 때까지 프롬프트(prompt)를 주고받아야 하는 상황에 처하겠지만, 이 또한 당신의 필요에 맞게 에이전트를 조종(steer)하는 방법을 배울 수 있는 과정입니다.

이 과정에서 당신은 자신의 워크플로우(workflow)에 적합한 몇 가지 패턴을 발견하게 될 것이며, 이를 통해 에이전트를 위한 스킬(skills)을 정의할 수 있습니다. 그렇게 하면 다음에 반복적인 작업이 필요할 때 에이전트를 위한 사전 정의된 입력을 이미 갖추게 됩니다. 스킬과 규칙(rules) 모두 코드 생성 프로세스를 효율화하는 데 사용될 수 있습니다. 하지만 스킬이나 규칙 모두 세심한 코드 리뷰의 필요성을 없애주지는 않습니다. 결국, 제출된 모든 코드 라인에 대한 책임은 작성자에게 남아 있습니다.

자동화된 리뷰 (Automated Review)

개발자가 풀 리퀘스트(pull request)를 열 준비가 되면, CI 파이프라인(CI pipeline)의 일부로 또 다른 단계가 자동으로 실행되는 경우가 많습니다. 여기서 AI 에이전트는 게시된 코드에 대해 자동화된 리뷰를 수행하며, 매우 흥미로운 엣지 케이스(edge cases), 잠재적인 보안 리스크 또는 누락된 널 체크(null checks)를 찾아낼 수 있습니다. 동시에, 에이전트는 여전히 프로젝트의 전체적인 비즈니스 맥락과 이력(historical context)이 부족합니다. 따라서 기술적으로는 타당하지만 제품이나 기존 아키텍처에는 부적절한 변경 사항을 권장할 수도 있습니다.

여기서 개발자는 자동화된 리뷰어(automated reviewer)의 피드백이 타당한지, 그리고 구현할 가치가 있는지 확인하기 위해 다시 한번 온전히 주의를 기울여야 합니다. 이번에도 Pull Request (PR)의 크기에 따라 수많은 제안이 쏟아질 수 있습니다. AI가 생성한 대규모 Pull Request는 종종 상당한 수의 자동화된 리뷰 코멘트를 유발합니다. 이는 변경 사항을 주의 깊게 검토할 수 있도록 가능한 한 작고 집중된 단위로 유지해야 하는 또 다른 이유이기도 합니다.

동료에 의한 코드 리뷰 (Code Review By Peer)

이전의 모든 단계가 올바르게 수행되었다면, 이 단계는 그리 많은 시간을 소모하지 않아야 합니다. 왜냐하면 많은 신뢰가 이미 작성자 본인의 리뷰와 자동화된 리뷰로부터 확보되었어야 하기 때문입니다. 이 단계는 기본적으로 AI 이전의 전통적인 코드 리뷰 (code review)와 유사합니다. 이에 대한 깊이 있는 통찰은 코드 리뷰에 관한 저의 이전 포스트 중 하나에서 찾아볼 수 있으니, 아직 확인하지 않으셨다면 지금이 확인해 보기 좋은 시기일 것입니다.

하지만 이전 단계들, 특히 첫 번째 단계가 제대로 수행되지 않았다면 코드 리뷰어는 감사하지 못한 상황에 놓이게 됩니다. 코드 품질에 대한 모든 책임이 이제 리뷰어에게 전가되기 때문입니다. 여기서 발생하는 첫 번째 문제는 Pull Request를 올린 개발자가 아마도 자신이 작성한 코드를 이해하지 못하고 있을 가능성이 높다는 것이며, 이는 예상치 못한 예외(exception)나 유지보수 측면에서 더 많은 문제를 일으킬 수 있습니다. 커밋(commit)에는 작성자의 이름이 붙어 있지만, 정작 그들은 구현의 특정 부분이 왜 존재하는지 또는 어떻게 작동하는지를 자신 있게 설명하지 못할 수 있습니다.

지난 몇 년간의 전체적인 AI 흐름을 살펴보면, 이를 올바르게 다루지 않을 경우 한 가지 우려스러운 현상이 보입니다. 팀들이 이전보다 훨씬 빠르게 코드를 생산하는 방향으로 가고 있지만, 동시에 시니어 엔지니어들은 직접 새로운 구현을 작성하기보다 AI가 생성한 변경 사항을 검토하고 검증하는 데 점점 더 많은 시간을 소비하고 있습니다. 이 경우, AI는 소프트웨어 전달(software delivery)을 반드시 가속화하지는 못한 채 코드 생성만을 가속화하게 됩니다.

핵심 요약 및 결론

AI는 엔지니어링 노력이 투입되는 지점을 확실히 변화시켰습니다. 코드를 작성하는 일은 점점 더 자동화되고 있지만, 동일한 코드를 이해하고, 검증하며, 유지보수하는 일은 여전히 인간의 책임으로 남아 있습니다. 이러한 변화를 인식하고 그에 따라 리뷰 프로세스를 조정하는 팀은, 단순히 코드를 더 빠르게 생성하는 데에만 집중하는 팀보다 AI로부터 훨씬 더 많은 이득을 얻을 수 있습니다. 그렇지 않으면 시간이 흐를수록 해당 코드는 유지보수가 어려워지거나 심지어 불가능해질 것입니다.

제가 배운 가장 중요한 교훈은 풀 리퀘스트 (Pull Request)당 코드 양을 가능한 한 작게 유지하는 것입니다. 그래야 개발자가 리뷰하기에도, 동료가 살펴보는 데에도 더 쉽기 때문입니다. 거대한 풀 리퀘스트 (Pull Request)는 작성자에게도, 리뷰어에게도 도움이 되지 않습니다. 그것은 단지 불확실성을 높이고 인도된 제품에 대한 신뢰도를 떨어뜨릴 뿐입니다.