AI 에이전트를 제대로 쓰는 핵심은 ‘코드를 리뷰’하는 과정이다. 구조적 코드 리뷰로 잘못된 설계를 초기에 바로잡을 수 있을 때 에이전트의 생산성이 극대화된다.
AI 에이전트를 올바르게 사용하는 일은 _코드를 리뷰하는 것_의 과정이다. 코드 리뷰를 잘한다면 Claude Code, Codex, Copilot 코딩 에이전트 같은 도구도 잘 다룰 수 있다.
왜 그럴까? 대형 언어 모델은 많은 코드를 만들어내는 데 능하지만, 아직 유능한 소프트웨어 엔지니어가 가진 깊은 판단력은 부족하다. 감독하지 않으면 나쁜 설계 결정을 밀어붙이느라 많은 시간을 쓸 것이다.
지난주 나는 VicFlora Offline을 만들었다. 오프라인에서도 잘 동작하는 PWA로, 식물 동정(이분법 검색표)을 위해 VicFlora 데이터 일부를 호스팅한다. 현장에서 인터넷이 잘 안 될 때도 검색표를 쓸 수 있도록 하려는 것이다. Codex는 이분법 검색표를 위해 VicFlora 프런트엔드 코드를 리버스 엔지니어링하려고 엄청난 노력을 기울였다. 솔직히 보는 내내 꽤 인상적이었다! 하지만 원시 데이터에 접근하는 더 쉬운 방법이 있을 거라고 생각했고, 역시 그게 맞았다. AI 코딩 에이전트를 쓰다 보면 이런 일이 계속 반복된다. 대략 한 시간에 한 번꼴로 에이전트가 수상한 일을 하고 있다는 느낌이 들고, 더 깊이 파고들어 보면 올바른 방향으로 바로잡아 시간 낭비를 수시간씩 아낄 수 있다.
AI로 학습을 돕는 앱도 만들고 있다. 무한히 흐르고 자동으로 조정되는 간격 반복(spaced repetition) 피드라고 생각하면 된다. 병렬로 일을 처리하고 싶을 때(예: 백그라운드에서 학습 계획 생성), Codex와 Claude Code는 꼭 백그라운드 잡 인프라 전체를 만들고 싶어 한다. 잡 엔티티, 결과 폴링 등등 말이다. 나도 백그라운드 잡을 좋아하지만, 보통의 짧게 끝나는 병렬 작업에는 너무 과하다. 프런트엔드에서 논블로킹 요청만 하면 된다! 내가 일관되게 단순함을 밀어붙이지 않았다면, 내 코드베이스는 훨씬 복잡해져서 이해하기 어려웠을 것이다.
덧붙이자면, 그래서 나는 순수한 “vibe coding”만으로는 유용한 앱이 폭발적으로 나오지 않는다고 본다. LLM이 엉뚱한 길로 가고 있을 때 그걸 포착하는 기술적 역량이 없으면 금방 막다른 길에 몰린다. 잘못 설계된 해법을 어떻게든 작동시키려 들면 시간, 토큰, 코드베이스 복잡도를 갉아먹는다. 이 모든 것이 에이전트가 실제로 문제를 푸는 능력을 잠식한다. 둘 셋만 겹쳐도, 그 앱은 더는 에이전트가 다룰 수 없는 문제가 되어 전체가 멈춰 버린다.
이런 예시는 열정적인 주니어와 함께 충분한 시간을 보낸 엔지니어라면 익숙할 것이다. 초기 아이디어에 곧바로 뛰어들어 순전히 노력으로 밀어붙이는 건 매우 흔한 실수다. 그걸 제어하는 게 팀의 역할이다. AI 에이전트와 일하는 건, 시간이 지나도 인간처럼 판단력이 성장하지 않는 열정적인 주니어와 일하는 것과 비슷하다1.
이건 내가 생각하는, 엔지니어들이 코드 리뷰에서 가장 많이 저지르는 실수에 대해 이야기할 좋은 기회이기도 하다. 바로 작성된 코드만 생각하고, 작성될 수도 있었던 코드는 생각하지 않는 것이다. 숙련된 엔지니어조차도 디프(diff)를 낱낱이 훑는 리뷰는 잘하지만, 정작 이 코드가 이 위치에 있는 게 맞는지 묻는 데는 0초를 쓰는 모습을 많이 봤다.
내가 보기에 가장 좋은 코드 리뷰는 _구조적_이다. 디프에 언급되지 않은 코드베이스의 다른 부분에서 맥락을 끌어온다. 이상적으로는 그 맥락 덕분에 디프가 더 짧고 우아해진다. 예를 들어, 연산 X를 위한 새 시스템을 만드는 대신 이미 있는 시스템을 재사용할 수 있다. 프런트엔드 SPA 코드에서 이분법 검색표 ID를 긁어오는 취약한 스크레이핑 파이프라인을 만드는 대신, 명시적으로 공개된 다른 위치에서 이분법 검색표를 그냥 내려받자. 전체 백그라운드 잡 시스템을 만드는 대신, 웹사이트가 동시에 두 가지를 수행하기 위해 이미 갖고 있는 기존 장치를 활용해 클라이언트에서 병렬 작업을 처리하자.
사소한 부분만 집요하게 파고드는 리뷰어라면, AI 도구를 효과적으로 쓰는 데 애를 먹을 것이다. 개별 코드 줄을 끝없이 만지작거리며 .map.filter 대신 .reduce를 쓰자고 하거나, 함수 이름을 잡아늘이며 논쟁하는 데 시간을 쓰게 된다. 그러면서 동시에, AI가 아키텍처적 막다른 길로 가지 않게 이끌 기회를 놓치게 된다.
반대로, ‘고무도장(rubber-stamp)’ 리뷰어라면 AI 도구를 지나치게 신뢰하게 될 가능성이 높다. 그 접근은 유능한 동료와는 잘 맞지만, 주니어를 온보딩할 때에는 잘 맞지 않고, AI 코딩 에이전트와 일할 때도 마찬가지다.
“AI를 잘한다”는 건 무슨 뜻일까? git 같은 보통의 도구를 잘 쓰는 건 비교적 단순하다. git 저장소의 기본 트리 구조를 이해하고, 주요 git 명령 대부분에 익숙하면 git을 잘 쓰는 것이다. 하지만 AI의 기본 구조는 난해한 모델 가중치 덩어리이고, 그가 수행할 수 있는 “연산”은 “컴퓨터로 할 수 있는 건 웬만하면 전부”다. 이와 같은 소프트웨어 공학 도구는 없다.
가장 낙관적인 AI 지지자들은 “AI를 잘한다”는 것이 삶의 모든 영역에 AI 도구를 최대한 채택하는 것이라고 생각한다. 그 논지는 AI가 제프 베이조스의 스태프와 비슷한 역할을 한다는 것이다. 막강한 자원과 역량을 가진 스태프를 쓰는 데는 많은 _기술_이 필요하지 않는다. 원하는 것을 말하면, 엄청난 양의 다른 사람들의 노력이 그걸 제공하는 데 투입될 뿐이다. 하지만 오늘 내가 베이조스의 자리로 순간이동한다면, 베이조스만큼 스태프를 효율적으로 쓰지는 못할 것이다. 나는 원하는 것의 절반도 요구할 생각을 못 할 테니까 — 예를 들어 전용기에서 내리자마자 뜨거운 룬 크루아상이 기다리고 있게 해달라고까지는 떠올리지 못할 것이다. 정말로 좋아하더라도 말이다. AI 신봉자들은 AI 도구가 이와 비슷하다고 본다. 그들에 따르면, 개인 AI 비서에게 원하는 어떤 프로그램이든 ‘바이브 코딩’하게 하거나, 어떤 양의 데이터든 정리하게 하거나, 모든 이메일 초안을 쓰게 할 수 있다는 사실을 진정으로 내면화하면, 훨씬 더 자주 AI를 쓰게 되고 그만큼 이익을 얻을 것이라고 한다.
나는 아직 거기까지 왔다고 보지 않는다. 나는 에이전트형 코딩 도구를 많이 쓴다. 업무에서는 GitHub Copilot을, 개인 프로젝트에는 Codex와 Claude Code 둘 다를 쓴다2. 이 도구들은 놀랄 만큼 많은 일을 스스로 해내지만, 꽤 면밀한 감독이 필요하다. 지배적인 프로그래밍 모델은 “켄타우로스 체스” 같은 형태다. 숙련된 인간이 컴퓨터 보조자와 짝을 이룬다. 특정 소프트웨어 접근이 합리적인지 평가하는, 즉 코드 리뷰를 잘할수록 에이전트형 AI 도구를 더 잘 쓰게 된다.
edit: 이 글이 Hacker News에서 약간 주목을 받았다. 대부분의 댓글은 “AI 에이전트가 효과가 있느냐”는 질문을 반복하고 있는데, 내겐 별로 흥미롭지 않다(내 생각은 “물론 어떤 코드베이스에서는 효과가 있지만, 다른 코드베이스에서는 완전히 쓸모없을 것”이다). 예를 들어, 훌륭한 코드 리뷰가 어떻게든 AI 에이전트가 리눅스 커널에 실질적인 기여를 하게 만들 수 있다고는 생각하지 않는다. “코드 스멜과 함수 네이밍” 중심의 코드 리뷰를 옹호하며, 코드 리뷰에서 설계를 논하고 있다면 사전에 기능을 충분히 계획하지 못한 증거라고 하는 댓글 몇 개도 있었다. 나는 그 견해에 꽤 강하게 반대하며, 언젠가 그에 대해 따로 글을 쓸 생각이다.
↩ 2. Codex와 Claude Code를 쓴다고 해서 그들이 Copilot보다 낫다고 생각한다는 뜻은 아니다. 내 역할의 일부는 다양한 AI 도구를 써보는 것이라고 본다.
이 글이 마음에 드셨다면, 새 글 소식을 이메일로 받아보는 구독을 고려하거나, Hacker News에 공유해 주세요.
2025년 9월 20일│ 태그: ai
