AI 에이전트가 작성한 코드와 리뷰
AI 에이전트 덕분에 코드 작성 속도와 전체적인 생산성은 상상할 수 없을 정도로 빨라졌어요. 하지만 쏟아져 나오는 코드와 산출물의 양은 사람이 검토하며 따라가기에 너무나 버거운 상황이죠. 특히 완성도를 위해 더해지는 방어적인 코드들과 중간 과정에서 정리되지 않은 찌꺼기 코드들이 그대로 쌓이면서, 이를 리뷰해야 하는 개발자에게 리뷰에 대한 피로감을 주고 있어요.
에이전트 결과가 장황해지는 이유
AI 에이전트는 지시사항을 안전하고 확실하게 수행하기 위해 코드와 산출물을 과도하게 작성하는 경향이 있어요. 최근 LLM 모델이 고도화되고 추론 능력이 비약적으로 향상되면서, 복잡한 예외 처리와 부가적인 요소를 더 촘촘하게 고려하려다 보니 이러한 현상이 더욱 심해지는 것 같아요.
- 과도한 방어적 프로그래밍 (KISS, YAGNI 위배): 불필요한 예외 처리나 null 체크, 그리고 아직 필요하지 않은 확장성까지 고려한 코드가 도처에 추가되면서 단순함을 유지하는 KISS(Keep It Simple, Stupid) 원칙과 현재 필요한 기능만 개발하는 YAGNI(You Aren't Gonna Need It) 원칙을 위배하고 핵심 비즈니스 로직을 가려요.
- 컨텍스트 전달의 한계 (DRY 위배): 기존 프로젝트의 압축적인 유틸리티 함수나 도메인 패턴을 활용하기보다, 매번 모든 로직을 풀어서(inlined) 새로 작성하려 하여 중복을 지양하는 DRY(Don't Repeat Yourself) 원칙을 지키지 못해요.
- 설명조의 불필요한 주석 생성: 자신이 왜 코드를 이렇게 구현했는지에 대한 생각이나 추정, 그리고 사용자가 나눈 대화나 요청 사항 자체를 코드 내에 주석으로 고스란히 남겨두려 해요. 이로 인해 코드의 본질보다 부가 설명이 더 많아져 가독성을 떨어뜨려요.
- 중간 과정과 최종 결과의 괴리: 작업 도중 시도했다가 더 이상 사용하지 않게 된 미사용(유실된) 더미 코드나 불필요한 시험용 로직들을 말끔히 정리하지 못하고 코드베이스에 그대로 흘려보내요. 게다가 에이전트는 최종 산출물의 표면적인 일부분만 작동하는 것을 보고 모든 기능이 완벽히 구현되었다고 스스로 속단하기 쉬워요.
리뷰에 대한 피로감이 심해요
애디 오스마니(Addy Osmani)가 에이전틱 코드 리뷰라는 글에서 이야기하듯이, 코드 작성 생산성은 비약적으로 향상된 반면 그 코드를 사람이 읽고 제대로 검증하는 데 필요한 물리적인 시간은 예전과 다름없이 그대로예요. 도구의 발전으로 생성 속도가 빨라진 것에 비례해 검토 시간은 단축되지 않아 불균형이 발생하고, 이로 인해 개발자의 피로감과 인지 부하가 가중되고 있어요.
- 리뷰어의 피로감과 리뷰 생략: 코드의 양과 에이전트의 결과물이 업무 시간 내에 감당하기 힘들 정도로 많아지다 보니, 동료 개발자가 이를 꼼꼼히 확인하기 어려워져요. 그 결과 제대로 된 검증 없이 대충 넘어가거나 아예 리뷰를 생략한 채 합쳐버리는 케이스가 점점 더 늘어나고 있어요. 특히 에이전트가 만든 코드는 언뜻 완벽해 보이기 때문에 이런 맹점에 빠지기 더욱 쉽지요.
- 보안과 품질의 맹점: AI 에이전트가 작성한 코드에 잠재적인 보안 위협이 숨어 있을 가능성을 배제할 수 없어요. 이에 대한 체계적인 검증은 security-review나 애디 오스마니의 code-review-and-quality 글에서 강조하듯, 여전히 리뷰어의 중요한 몫으로 남아 있어요.
간결한 리뷰가 필요해
실제로 AI 에이전트가 만들어내는 작업에 대한 피드백 산출물을 극단적으로 줄이려는 시도로 인해 caveman-review나 ponytail-review 같은 구체적인 스킬들이 공유되고 활용되기 시작했어요. 이러한 전략들은 결국 전통적인 소프트웨어 개발 원칙인 KISS, DRY, YAGNI를 에이전트 협업 환경에서 어떻게 다시 바로 세울 것인가와 직결됩니다.
이러한 도구들은 장황한 피드백으로 인한 인지 과부하를 줄이기 위해, 구구절절 설명하는 대신 yagni나 nit 같은 명확한 prefix를 사용하여 리뷰 결과를 극단적으로 압축해요. 하지만 피드백을 한 줄 형태로 지나치게 압축하다 보니 오히려 맥락이 유실되어 가독성이 떨어지는 문제가 생기기도 해요. 결국 노이즈를 줄이는 것과 명확한 의도를 전달하는 것 사이에서 적절한 절충점을 찾는 고민이 필요해요.
요즘 자주 하게 돼요
에이전트가 제공하는 압도적인 작성 생산성을 누리게 되었지만, 업무 시간에 중요하면서도 불필요하게 자주 반복하게 되는 일이 생겼어요. 바로 최소한의 변경만 허용하는 보이 스카웃 규칙을 신경 쓰고, 에이전트에게 결과를 다듬어 달라고 계속해서 요청하는 작업이에요.
- 보이 스카웃 규칙(Boy Scout Rule) 고려: 에이전트가 코드를 작성하거나 수정할 때 기존 코드 베이스를 과도하게 변경하거나 불필요한 기능(더미 코드 등)을 추가하지 못하도록 제어해요. 에이전트의 코드 수정을 최소한으로 제한하여 프로젝트가 원래 가지고 있던 깨끗한 상태를 유지하려고 노력합니다. 캠프장을 처음 왔을 때보다 더 깨끗하게 만들고 떠나는 보이 스카웃 규칙처럼, 변경의 폭을 좁혀 변경 지점을 명확히 유지하는 것이 핵심이에요.
- 한 줄 요약 및 메시지 다듬기 요청: 에이전트가 작업 내역을 장황하게 나열하지 못하도록 요약을 강제하는 프롬프트를 덧붙여요. 특히 하루 종일 AI 에이전트와 협업하며 깃허브 이슈나 풀 리퀘스트(PR) 댓글을 작성하려 할 때, 조금이라도 동료나 자신이 읽기 편하게끔 에이전트에게 "읽기 편하게 간소화해줘" 혹은 "다듬어줘"라는 다듬기 피드백을 습관처럼 계속해서 전달하게 돼요.
에이전트 리뷰에 도움이 되는 스킬
참고로 이 스킬들의 역할을 매번 개별적으로 지시하기보다는, 에이전트에게 "이 스킬들을 모두 조합해서 하나의 통합 리뷰 스킬로 만들고 이를 바탕으로 코드를 검토해줘"라고 요청하여 사용하는 것이 훨씬 효율적이에요. 예를 들어, 여러 스킬의 관점을 순차적으로 실행하도록 설계된 review 스킬을 커스텀 명령어로 구성하여 /review 명령 한 번으로 전체적인 코드 검수를 마칠 수 있도록 프로세스를 빌드하는 식이에요.