원문: If you are good at code review, you will be good at using AI agents
AI 에이전트를 올바르게 사용하는 일은 코드 리뷰 과정과 닮아 있습니다. 코드 리뷰에 익숙하다면 Claude Code, Codex, Copilot 같은 코딩 에이전트 도구도 더 잘 활용할 수 있을 것입니다.
왜 그럴까요? 대규모 언어 모델은 많은 양의 코드를 생성하는 데는 뛰어나지만, 숙련된 소프트웨어 엔지니어가 내리는 깊이 있는 판단까지는 아직 충분히 갖추지 못했습니다. 감독 없이 맡겨두면 잘못된 설계 결정을 따라가느라 많은 시간을 허비하게 됩니다.
AI 에이전트와 나쁜 설계
지난주 저는 VicFlora Offline을 만들었습니다. (식물 분류 키를 사용할 수 있도록 VicFlora 데이터 일부를 호스팅하는 오프라인 친화적인 PWA입니다.) 인터넷 수신이 나쁜 야외 환경에서도 키를 계속 사용할 수 있도록 하기 위해서입니다. Codex는 이분법적 키를 위한 VicFlora 프런트엔드 코드를 리버스 엔지니어링하는 데 많은 노력을 기울였습니다. 솔직히 지켜보는 것만으로도 꽤 인상적이었습니다. 다만 저는 원시 데이터에 접근하는 더 쉬운 방법이 있을 거라고 생각했는데, 실제로 그게 맞았습니다.
AI 코딩 에이전트를 사용할 때마다 비슷한 일이 반복됩니다. 한 시간에 한 번쯤 에이전트가 수상한 방향으로 가는 걸 발견하고, 조금만 자세히 살펴보면 올바른 방향으로 돌려놓음으로써 수 시간의 낭비를 막을 수 있었습니다.
또한 저는 AI로 학습을 돕는 앱도 개발 중입니다. ‘무한히 자동 조정되는 간격 반복 학습 피드’라고 생각하시면 됩니다. 병렬 작업을 수행할 때(예: 백그라운드에서 학습 계획 생성), Codex와 Claude Code는 모두 작업 엔티티, 결과 폴링 등 완전한 백그라운드 작업 인프라를 구축하려고 합니다. 백그라운드 작업 자체는 유용하지만, 평범한 단기 병렬 작업에는 명백히 과잉 설계입니다. 프런트엔드에서 비차단 요청만 보내도 충분하니까요. 단순함을 꾸준히 지키지 않았다면 제 코드베이스는 훨씬 복잡해졌고, 이해하기도 어려웠을 겁니다.
덧붙여 말하자면, 저는 이것이 순수한 ‘바이브 코딩’만으로 유용한 앱이 폭발적으로 늘어나지 못한 이유라고 생각합니다. LLM이 잘못된 방향으로 가고 있다는 신호를 감지할 기술적 능력이 없다면 금방 막히게 됩니다. 잘못 설계된 솔루션을 억지로 작동시키려 하면 시간과 토큰, 그리고 코드베이스 복잡성을 소모하게 됩니다. 이 모든 요소가 에이전트의 실제 문제 해결 능력을 갉아먹습니다. 두세 가지 문제가 쌓이기 시작하면 앱은 더 이상 에이전트가 처리할 수 있는 수준을 벗어나고, 결국 모든 것이 멈춰 버립니다.
코드 리뷰
이런 사례는 열정 넘치는 신입들과 엔지니어링 팀에서 충분히 일해본 사람이라면 익숙할 겁니다. 초기 아이디어에 곧바로 뛰어들어 순수한 노력만으로 어떻게든 작동시키려 하는 건 매우 흔한 실수입니다. 이런 상황을 제어하는 것이 나머지 팀원들의 역할이죠. AI 에이전트와 일하는 경험은, 시간이 지나도 실제 인간이 갖게 되는 판단력을 발달시키지 못하는 열정 넘치는 신입과 함께 일하는 것과 비슷합니다. [1]
[1]: 이 주장을 볼 때마다 궁금해집니다. 저는 2022년 초에 Copilot 같은 AI 코딩 도구를 사용하기 시작했는데, 2025년이 된 지금도 최첨단 AI 도구를 사용하고 있습니다. 이 흐름을 보면 도구가 인간과 비슷한 속도로 성장한 것 같은 느낌이 들지 않나요? 초기 Copilot을 신입 엔지니어로, 현재 Claude Code(또는 유사 도구)를 경력 3년 차 엔지니어로 비유한다면 너무 과장일까요? 앞으로 3년 후에는 AI 도구와 협업하는 일이 경력 6년 차 엔지니어와 일하는 것에 가까워질까요?
여기서 저는, 엔지니어들이 코드 리뷰에서 저지르는 가장 큰 실수 하나를 이야기해볼 좋은 기회라고 생각합니다. 작성된 코드만 보고, 작성될 수도 있었던 코드는 보지 않는 것입니다. 경험 많은 엔지니어조차도 변경 사항을 꼼꼼히 훑으면서도, “이 코드가 과연 여기에 있어야 하는가?” 같은 질문은 거의 하지 않는 장면을 종종 봤습니다.
제가 보기에 가장 효과적인 코드 리뷰는 구조적입니다. 즉, diff에 직접 등장하지 않는 코드베이스의 다른 부분에서 맥락을 끌어와 판단합니다. 이상적으로는 그 맥락이 diff를 더 짧고 우아하게 만들기도 합니다. 예를 들어, 작업 X를 위해 새로운 시스템을 만드는 대신 이미 존재하는 시스템을 재사용할 수 있습니다. 프런트엔드 SPA 코드에서 이분법적 키 ID를 추출하는 취약한 스크래핑 파이프라인을 만드는 대신, 이분법적 키가 명시적으로 제공되는 다른 곳에서 그냥 다운로드하면 됩니다. 전체 백그라운드 작업 시스템을 구축하는 대신, 웹사이트가 동시에 두 가지 작업을 수행하기 위해 이미 갖추고 있는 메커니즘을 활용해 클라이언트 측 병렬 작업으로 끝낼 수도 있습니다.
반대로, 지나치게 디테일에 매달리는 코드 리뷰어는 AI 도구를 효과적으로 활용하기 어려울 수 있습니다. 개별 코드 줄을 끝없이 수정하고, .map().filter() 대신 .reduce()를 요구하며, 함수 이름을 두고 불필요한 논쟁을 벌이는 식으로 시간을 쓰게 됩니다. 그러는 사이 AI가 아키텍처의 막다른 골목으로 빠지지 않도록 안내할 기회를 놓치게 됩니다.
마찬가지로, 무조건 승인하는 코드 리뷰어는 AI 도구에 지나치게 의존하게 됩니다. 이 접근은 유능한 동료들과는 어느 정도 통할 수 있지만, 신입 엔지니어를 교육할 때는 효과적이지 않고, AI 코딩 에이전트와 협업할 때도 잘 작동하지 않습니다.
마지막 생각
그렇다면 “AI를 잘한다”는 건 무엇을 의미할까요? 예를 들어 git 같은 도구는 기준이 비교적 명확합니다. 저장소의 기본 트리 구조를 이해하고, 대부분의 git 작업을 익혔다면 git을 잘 다룬다고 말할 수 있죠. 하지만 AI의 기본 구조는 헤아릴 수 없는 모델 가중치의 집합이고, 수행할 수 있는 “작업”은 “컴퓨터로 할 수 있는 거의 모든 것”입니다. 이와 비슷한 소프트웨어 공학 도구는 존재하지 않습니다.
가장 낙관적인 AI 지지자들은 “AI를 잘 활용한다”는 것이 삶의 모든 측면에 AI 도구를 최대한 도입하는 것이라고 말합니다. 그들의 관점에서 AI는 제프 베조스의 직원들과 비슷한 역할을 합니다. 막대한 자원과 뛰어난 역량을 가진 직원을 활용하는 데는 특별한 기술이 필요하지 않습니다. 원하는 것을 요청하기만 하면, 수많은 사람들의 노력이 그것을 제공하기 위해 투입될 테니까요. 하지만 오늘날 제가 갑자기 그의 자리에 텔레포트된다 해도, 저는 분명 베조스보다 훨씬 덜 효과적으로 스태프를 활용할 겁니다. 제가 원하는 것의 절반도 요청하지 않을 테니까요. 예를 들어, 개인 전용기에서 내릴 때 뜨거운 루네 크루아상이 기다리고 있을 거라는 생각 자체를 떠올리지 못할 겁니다. 비록 실제로는 꽤 즐겼을지라도 말입니다.
AI 신봉자들은 AI 도구도 이와 비슷하다고 봅니다. 개인 AI 비서에게 원하는 프로그램을 코드로 만들어 달라고 하거나, 어떤 양의 데이터든 분류해 달라고 하거나, 모든 이메일의 초안을 작성해 달라고 요청할 수 있다는 사실을 진정으로 내면화하면, AI를 훨씬 더 자주 활용하게 되고 그만큼 이익을 볼 거라는 주장입니다.
하지만 아직은 그 단계까지 오지 않은 것 같습니다. 저는 에이전트형 코딩 도구를 많이 사용합니다. 업무에서는 GitHub Copilot을, 개인 프로젝트[2]에서는 Codex와 Claude Code를 모두 사용합니다. 이 도구들은 놀라울 정도로 많은 작업을 스스로 수행하지만, 상당히 세심한 감독이 필요합니다. 현재 주류 프로그래밍 모델은 숙련된 인간과 컴퓨터 보조자가 협력하는 ‘켄타우로스 체스’와 유사합니다. 코드 리뷰 능력, 즉 특정 소프트웨어 접근법이 타당한지 평가하는 능력이 뛰어날수록 에이전트형 AI 도구를 활용하는 데도 더 능숙해질 것입니다.
[2]: Codex와 Claude Code를 사용한다고 해서 Copilot보다 더 낫다고 생각하는 것은 아닙니다. 제 생각에 다양한 AI 도구를 활용하는 것은 제 업무의 일부입니다.
편집: 이 글이 Hacker News에서 주목을 받았습니다. 대부분의 댓글은 “AI 에이전트가 실제로 작동하는가”라는 질문을 되풀이했는데, 이는 제게 그다지 흥미롭지 않습니다(제 견해는 “물론 일부 코드베이스에서는 유용하지만, 완전히 쓸모없는 코드베이스도 존재할 수 있다는 것”입니다). 저는 훌륭한 코드 리뷰를 통해서 AI 에이전트가 리눅스 커널에 실질적으로 기여할 수 있게 해줄 거라고는 생각하지 않습니다. 몇몇 댓글에서는 “코드 스멜과 함수 명명” 스타일의 코드 리뷰를 옹호하며, 코드 리뷰에서 설계를 논의한다면 사전에 기능을 충분히 계획하지 못한 것이라고 주장했습니다. 저는 그 견해에 상당히 강하게 반대하며, 언젠가 이에 관한 글도 따로 쓰려고 합니다.
'개발 > 번역' 카테고리의 다른 글
| [번역] 장애허용성 (1) | 2026.02.09 |
|---|---|
| [번역] 모든 것을 배열로 바꾸는 것을 그만두세요 (대신 일을 덜 하세요) (1) | 2026.01.24 |
| [번역] HTTP 범위 요청(Range Requests)을 통한 동영상 제공하기 (1) | 2025.12.31 |
| [번역] 왜 타입스크립트는 당신을 구해주지 못하는가 (1) | 2025.12.03 |
| [번역] 상태 기반 렌더링 vs 시그널 기반 렌더링 (2) | 2025.11.06 |