AI 코드 리뷰 에이전트 만드는 법: Greptile의 Daksh Gupta가 말하는 교훈

Gupta는 자신을 Greptile의 공동창업자로 소개하고, 회사가 전체 코드베이스의 맥락을 가지고 풀 리퀘스트를 리뷰하고 테스트하는 에이전트를 만든다고 설명한다. 그는 이런 리뷰와 테스트를 통해 에이전트가 특히 AI가 생성한 코드에서 버그, 논리 오류, 코드 품질 문제를 찾아낸다고 말한다.

그는 수많은 기업이 Greptile을 매일 사용하고 있으며, 다양한 종류의 코드베이스에 걸쳐 GitHub의 풀 리퀘스트 약 1%가 이 도구를 거친다고 말한다. 가끔은 요구사항이 너무 특수해서 Greptile이 맞지 않는 기업을 만나기도 하는데, 그런 경우 Greptile은 두 가지 이유로 기업이 자체 에이전트를 무상으로 만들도록 돕는 편이라고 밝힌다. 이 분야의 전문 지식을 가지고 있다는 점, 그리고 앞으로 비슷한 고객을 더 잘 섬기는 방법을 배운다는 점이다.

강연의 나머지 부분은 Greptile이 그런 기업에 이야기하는 내용이라고 그는 말한다.

Gupta는 고객이 Greptile에서 좋아하는 점이 세 가지라고 말하며, 각각을 어떻게 구현하는지 설명하겠다고 한다. 첫째는 코드베이스 맥락이다. 고객은 이 도구가 자신들의 코드를 이해한다고 느낀다. 그는 Greptile이 2023년부터 매우 큰 코드베이스를 이해하도록 언어 모델을 가르치는 코드베이스 맥락 회사로 시작했고, 그 덕분에 코드 인덱싱에 강하다고 설명한다.

둘째는 Greptile이 코드를 실제로 실행한다는 점이다. 의존성이 풍부하게 갖춰진 완전한 샌드박스에서 스택을 띄우고, 컴퓨터 사용 기능으로 화면을 클릭하며 테스트하며, API 엔드포인트에 대한 스트레스 테스트도 수행한다.

셋째는 추론 자원의 효율적 배분이다. Greptile은 리뷰와 검증 과정의 각 하위 작업에 맞는 모델과 적절한 추론 예산을 고른다. 그는 이것이 내부 도구나 경쟁사가 달성할 수 있는 수준보다 달러당 성능을 상당히 높여 준다고 말한다.

그는 이 강연이 두 부류의 청중을 위한 것이라고 말한다. 자체 리뷰 에이전트를 만들려는 팀, 그리고 리뷰 또는 테스트 에이전트를 고르면서 좋은 것과 훌륭한 것의 차이를 이해하고 싶은 팀이다.

Gupta는 회사의 리뷰 에이전트를 만드는 임무를 맡은 플랫폼 팀이나 AI에 열정적인 엔지니어 한 명을 상상해 보라고 한다. 엔지니어뿐 아니라 마케팅 직원까지 바이브 코딩으로 만든 코드를 포함해 회사는 엄청난 양의 코드를 작성하고 있으므로, 병목은 이제 리뷰와 검증으로 옮겨 갔다고 그는 말한다.

그가 권하는 첫 단계는 샌드박스를 확보하는 것이다. 많은 벤더가 샌드박스를 판매하고 있고, 팀은 Firecracker를 사용할 수도 있다. 샌드박스 안에 에이전트를 넣는다. 그는 개인적으로 모델에 독립적인 하네스를 추천하며, 그 이유는 곧 설명하겠다고 말한다. 오픈소스인 Open Code나 Pi 같은 것이다. 그다음 팀은 GitHub 또는 GitLab을 연결하고, 새로 열린 풀 리퀘스트의 내용을 에이전트에 보내는 PR 웹훅을 설정하며, 코드를 리뷰하고 피드백을 돌려주라는 프롬프트를 에이전트에 준다. 피드백은 GitHub 리뷰 API를 통해 다시 연결된다.

Gupta는 많은 사람이 이것만 하면 된다고 생각한다고 말한다. 기본적인 의미에서는 실제로 작동한다. 풀 리퀘스트가 올라오고, 내용이 에이전트에 전달되며, 약 5분 뒤 피드백이 나타난다. 하지만 잘못되는 것들도 여러 가지 있다고 그는 열거한다. 에이전트는 버그를 놓치며, 버그는 그의 표현대로 프랙탈처럼 끝이 없어서 같은 PR에서도 계속 새로운 버그를 찾아낸다. 맥락도 놓쳐서 코드베이스의 일부나 라이브러리가 어떻게 동작하는지 잘못 이해한다. 그는 2010년대 마이크로서비스 난립에서 회복하지 못한 기업들이 수천 개의 저장소를 가지고 있는데, 에이전트가 그것들을 모두 이해해야 한다고 농담한다.

마지막으로 비용이 매우 많이 든다는 점이 있는데, 사람들이 이것을 놀라워한다고 그는 말한다.

Gupta는 이런 방식으로 코딩 에이전트를 써서 코드를 리뷰해 본 사람들이 풀 리퀘스트당 $3에서 많게는 $25까지 든다고 보고한다고 말한다. 그는 이런 토큰 비용이 아주 빠르게 쌓일 수 있고, 청구서가 커질 때까지 조용히 불어난다고 지적한다.

Gupta에 따르면 네 번째 문제는 사소한 지적이다. 그는 기술적으로는 맞지만 지나치게 세세한 댓글을 사소한 지적이라고 정의한다. 이것은 두 가지 종류의 문제를 일으킨다. 사람이 읽는 입장에서는 매우 짜증스럽다. 늑대가 나타났다고 거짓말을 반복하는 소년처럼, 리뷰어는 쏟아지는 댓글을 읽으면서 어떤 것이 사소한 스타일 지적이고 어떤 것이 치명적인 문제인지 가려내야 한다.

두 번째 문제는 사소한 지적이 코드베이스를 망가뜨릴 수 있다는 점이다. 리뷰 에이전트는 보통 GitHub에 댓글을 남기고, 코딩 에이전트가 그 댓글을 가져다 해결한다. 코딩 에이전트는 분별력이 없다고 그는 말한다. 모든 댓글을 처리하려 들고, 그 결과 극도로 방어적이고 고통스러울 만큼 과잉된 코드가 나온다. 그리고 그는 그런 코드를 코딩 에이전트가 특히 잘 쓴다고 말한다.

Gupta는 가장 쉽게 딸 수 있는 열매가 프롬프트 최적화라고 말한다. 팀은 보통 매우 단순한 프롬프트, 예컨대 PR을 리뷰하고 댓글을 GitHub API 스키마 형식으로 출력하라는 프롬프트로 시작한다. 프롬프트는 두 가지 주제를 중심으로 짜야 한다고 그는 말한다. 특정 버그 유형을 찾을 것, 그리고 사소한 지적은 건너뛸 것이다.

특정 버그 유형을 찾으려면 팀이 코드베이스에서 기존 장애와 인시던트를 대상으로 내부 데이터 분석을 해 볼 수 있다. 어떤 종류의 버그를 가장 자주 만드는지 알아내는 것이다. 그런 유형을 목록으로 정리하고 프롬프트에 찾으라고 지시할 수 있다. 사소한 지적에 대해서는 프롬프트에 사소한 지적이 무엇인지 명확히 쓰고, 그런 것은 찾지 말라고 지시해야 한다. 그는 예시로, 왜 세 겹의 방어 계층이 없느냐고 묻거나 오류 처리가 약간 엉성하다고 지적하는 것을 든다.

그는 프롬프트의 작은 변화가 에이전트가 쓰는 댓글 수에 이상할 만큼 큰 영향을 줄 수 있다고 경고한다. 이것은 무섭다고 그는 말하는데, 반사실을 볼 수 없으므로 지금 버그를 놓치고 있는지 알 수 없기 때문이다.

Gupta는 리뷰 에이전트도 다른 모든 리뷰어나 테스터와 마찬가지로 버그가 있다는 것은 알려줄 수 있지만 버그가 없다는 것은 말해 줄 수 없다고 설명한다. 이것은 형식 자체의 한계다. 가장 심각한 버그는 극도로 드물고 점점 더 드물어지고 있어서 문제가 더 어려워진다. 그가 말하기로 Greptile의 데이터 과학에 따르면 일반적으로 치명적인 버그는 천 개의 풀 리퀘스트 중 약 한 개, 혹은 천 줄의 코드 중 한 줄에만 있다. 이렇게 드문 버그 때문에 팀은 아주 좋다고 믿는 에이전트를 출시했다가, 그것이 치명적인 버그를 몰래 놓치고 있다는 사실을 한참 뒤에야 알게 될 수 있다.

그래서 두 번째 개선은 과거 PR의 데이터셋이다. 모든 인시던트를 목록으로 관리하는 기업에는 이것이 비교적 쉽다. 과거에 장애를 일으킨 풀 리퀘스트 목록이 이미 있기 때문이다. 팀은 리뷰 에이전트를 그 PR들에 돌려 얼마나 자주 그 버그를 잡아내는지 측정할 수 있다. 이를 통해 프롬프트를 더 자신 있게 조정할 수 있다.

하지만 버그는 시간이 지나면서 바뀐다. 세상이 변함에 따라 버그의 구조와 분류도 바뀌므로 데이터셋도 실시간으로 갱신해야 한다. 그는 이것이 까다롭다고 말한다. 팀이 수백만 개의 풀 리퀘스트를 가지고 있지 않다면 새로운 종류의 버그를 예측하기 어렵기 때문이다. Greptile은 여기서 이점이 있는데, 여러 기업의 코드를 가지고 있어서 매우 큰 풀 리퀘스트 말뭉치에 걸쳐 테스트할 수 있고, 그 덕분에 자신 있게 에이전트를 개선하고 내부 에이전트는 얻을 수 없는 작은 성능 격차를 얻는다. 그래도 팀은 자체 내부 데이터로 꽤 멀리 갈 수 있다고 그는 말한다.

다음 개선은 모델 인버전이라고 Gupta는 말한다. 그는 샌프란시스코에서 열린 AI Engineer 행사의 앞선 강연에서 코딩 에이전트가 실패하는 방식을 이야기했는데, 그때 Claude 모델과 Codex 모델이 만들어 내는 버그 유형이 상당히 다르다는 것을 확인했다고 말한다. 예를 들어 Claude 모델은 GPT 모델보다 일회성 오류를 대략 세 배 더 만들기 쉽고, GPT 모델은 Claude 모델보다 인증 우회를 훨씬 더 많이 만든다고 한다. 그는 이런 차이가 사후 학습의 산물이라고 이해한다.

그 결과를 막으려면, 같은 모델이 쓴 코드를 같은 모델로 리뷰하면 버그를 상대적으로 적게 잡아낸다고 그는 말한다. 리뷰할 때도 모델이 생성할 때와 같은 방식으로 실패하기 때문이다. 해결책은 모델을 뒤집는 것이다. Claude Code가 코드를 작성했다면 GPT 모델로 리뷰하고, 그 반대도 마찬가지다.

그는 이것이 약 80%의 경우에는 간단하지만 나머지 20%는 꽤 까다롭다고 말한다. 코딩 에이전트는 흔적을 남기는 경우가 많다. 예를 들어 Codex는 브랜치 이름을 codex/브랜치명 형식으로 짓고, Claude는 PR 설명과 커밋 메시지에 co-authored-by 줄을 추가한다. 약 80%의 경우 이것으로 모델을 식별할 수 있다. 나머지 경우, 예를 들어 사람이 직접 만든 브랜치 이름이라면 훨씬 어려워서, 팀은 휴리스틱을 개발하거나 엔지니어가 쓰는 에이전트 목록을 내부적으로 관리하거나 개발자 PC의 텔레메트리에 의존해야 한다.

Gupta는 Greptile이 모델을 뒤집었을 때 적발률이 10% 높아진다는 것을 확인했다고 말한다. 이것은 작게 들릴 수 있지만, 인시던트와 장애의 관점에서 보면 10%는 꽤 크다고 그는 말한다. 달리 말하면 모델 인버전이 없으면 무언가 잘못될 확률이 10% 더 높고, 그것은 치명적일 수 있다. 그는 프로세스에 어떤 형태로든 모델 인버전을 쓰는 것을 강력히 권한다.

세 번째 개선은 코드베이스 맥락이며, Gupta는 이것을 매우 중요하게 여긴다고 말한다. Greptile은 코드 검증을 하기 전에 코드베이스 맥락에 관한 작업을 했고, 매우 큰 코드베이스에서 검색을 더 잘하는 방법을 찾고 있었다. 많은 사람이 여전히 grep이 코드베이스 맥락 문제를 사실상 해결했다고 생각하지만, 그는 두 가지 이유로 동의하지 않는다. grep은 극도로 부정확하고, 매우 비싸기 때문이다.

규모를 보여 주기 위해 그는 지난해 GDP 성장의 한 자릿수 퍼센트포인트가 추론에서 나왔고, 그 추론의 상당 부분이 코딩 에이전트에 쓰였다고 말한다. 코딩 에이전트의 추적 기록을 들여다보면 토큰의 대부분이 grep, 파일 읽기, 파일 내용의 캐시 쓰기라는 몇 가지 동일한 작업에 몰려 있다고 그는 말한다. 따라서 GDP 성장의 적지 않은 부분이 grep, 파일 읽기, 캐시 쓰기에 쓰인다고 주장한다. 그는 토큰 단위로 과금받는 회사들이 토큰을 더 태울 방법을 찾으려는 나쁜 유인을 가질 수 있다고도 제안한다.

대안은 어디를 읽을지 결정하는 더 정밀한 방법이다. Greptile은 내부 지식 베이스를 만드는데, 여기서는 전체 코드베이스를 점검하고 각 부분을 분류해 색인한다. 예를 들어 어떤 영역이 인증이고, 어떻게 동작하며, 어떤 흐름이 관여하고, 그 흐름의 다이어그램이 무엇이며, 관련된 파일이 무엇인지 정리하는 식이다.

코드베이스 맥락은 인증 우회 같은 것을 탐지하는 데 중요하다고 Gupta는 말한다. 인증 우회가 일어났는지 판단하는 것은 매우 어렵다. 코드베이스의 그 부분에 있을 때 인증된 환경에 있는지 구체적으로 이해해야 하기 때문이다.

Gupta는 지금까지 버그에 집중했지만, 코드는 버그가 없어도 매우 나쁠 수 있다고 말한다. 품질이 끔찍할 수 있고, 작성자가 표현한 의도를 충족하지 못할 수도 있다.

그는 최근 사람들이 점점 Slack을 IDE처럼 쓴다는 글을 봤다고 말한다. 그는 그것이 조금 재미있다고 생각하지만, Slack 메시지는 드러난 의도가 거의 없다고 지적한다. 무언가를 고쳐 달라고 에이전트에 요청하는 데 한두 문장, 많아야 그 정도를 쓰게 되고, 그 결과 모호함이 많이 남는다. 그러면 코딩 에이전트는 지시를 잘못 해석하거나, 너무 모호해서 정확히 무엇을 해야 할지 알 수 없다고 판단할 수 있다. 맞아 보이는 코드도 여전히 아주 틀릴 수 있다.

Greptile은 에이전트에 더 많은 맥락을 주는 방식으로 이에 대응한다. Gupta는 가장 중요한 맥락이 두 가지라고 말한다. 문서와 티켓, 그리고 인덱서나 지식 베이스가 제공하는 코드베이스다. 팀은 에이전트에게 Jira나 Linear, 그리고 Confluence, Notion 등 문서가 있는 곳에 대한 접근 권한을 주는 것만으로도 놀랍도록 멀리 갈 수 있다고 그는 말한다. 많은 암묵적 지식이 엔지니어가 더 나은 코드를 쓰도록 무의식적으로 돕는데, 에이전트에 그 지식이 없으면 무슨 일이 일어나는지 모르는 것처럼 보인다고 그는 설명한다. 사람들이 자기 자신이 가진 지식의 양을 과소평가하기 때문이라는 것이다.

Greptile의 접근법은 이 모든 맥락 출처를 살아 있는 위키 하나로 모으는 것이라고 Gupta는 말한다. 그는 이것을 회사가 어떻게 돌아가는지에 대한 세계 모델이라고 묘사한다. 시스템이 코드베이스에 대해 아는 모든 것, 프로덕션 텔레메트리와 로그를 통해 애플리케이션에 대해 아는 모든 것, 그리고 문서와 Linear 티켓을 통해 로드맵에 대해 아는 모든 것이 여기에 담긴다.

에이전트는 이 위키를 써서 맥락을 제공하고, 그 덕분에 더 맥락을 잘 인식한다. 또한 코드 검색이 훨씬 정밀해지는데, 필요하지 않은 파일은 절대 읽지 않기 때문이다.

다음 단계는 자율 테스트다. Gupta는 UI 변경을 예로 든다. 에이전트가 변경된 React 파일들을 읽고 문제가 없다고 결론 내릴 수 있지만, 페이지를 렌더링하면 예를 들어 아이폰에서 숨겨져 있을 수 있다는 것이다.

그는 이것이 기술적으로 가장 어려운 문제 중 하나라고 말한다. Greptile은 완전히 설정 가능한 가상 머신인 의존성이 풍부한 샌드박스를 만들고, 고객과 함께 그 안에 스택을 띄운다. 그런 다음 Greptile의 에이전트가 컴퓨터 비전을 사용해 애플리케이션을 엔드투엔드로 테스트한다. Gupta는 최근 GPT와 Opus 세대에서 컴퓨터 비전이 크게 좋아졌고, 처음으로 엔드투엔드 QA가 거의 해결되었다고 생각한다고 말한다.

그가 말하기로 두 가지가 필요하다. 팀은 애플리케이션의 모든 흐름을 문서화해야 하고, 에이전트가 환경에서 스택을 띄울 수 있도록 충분히 단순한 빌드 스크립트를 가져야 한다. Greptile에는 고객을 돕는 포워드 디플로이드 엔지니어가 있는데, 회사가 이미 매우 좋은 개발용 박스를 갖추고 있지 않다면 이것이 더 까다로운 부분 중 하나라고 그는 말한다.

그는 이어서 이 구성에 필요한 것을 설명한다. 개발용 박스, 앱이 실행되는 PR 브랜치 의존성, 그리고 예를 들어 인증 코드와 가입 흐름을 기술하는 흐름 지도다. 이것이 있으면 에이전트는 코드를 엔드투엔드로 테스트하고, 비전 모델을 써서 문제를 관찰할 수 있다. 예를 들어 기술적으로는 보이지만 아이폰에서는 숨겨진 버튼이나, 아이폰 Duo에서 첫 번째 폴드 바깥에 있는 버튼 같은 문제다.

이 모든 것을 갖춰도 비용은 여전히 꽤 높다고 Gupta는 말한다. 풀 리퀘스트 하나의 리뷰는 약 $3에서 $15, 많게는 $20까지 들 수 있다. 다음으로 풀어야 할 과제는 일부 작업에 저렴한 모델을 쓰는 것이다. 그는 프런티어 모델이 여전히 오픈소스 모델보다 대체로 더 유능하지만 그 격차는 좁아지고 있다고 말한다.

Greptile의 배분은 토큰의 약 20%를 가장 중요한 작업을 위한 프런티어 모델에 주는 것이다. 탐색적 파일 읽기처럼 토큰의 긴 꼬리는 다양한 소형 모델로 보낸다. 예시로 그는 Greptile이 맥락을 찾는 데는 소형 모델을, 사용자 흐름을 테스트하는 데는 매우 가벼운 컴퓨터 사용 모델을, 버그 분석, 리뷰 과정 적용, 최초 제출에는 프런티어 모델을 쓴다고 말한다. 실제로는 각각 특정 모델 집합을 가진 약 20개의 하위 작업이 있으며, 작은 연구 팀이 어떤 작업에 어떤 모델을 쓸지 끊임없이 반복 조정한다고 한다.

그는 팀이 매우 단순한 작업을 매우 단순한 모델로 바꾸는 것만으로도 아마 70에서 80%까지는 갈 수 있다고 말한다.

Gupta는 여기서도 대규모 데이터셋이 도움이 된다고 말한다. 좋은 데이터셋이 없으면 팀은 많은 하위 에이전트를 더 작고 빠른 모델로 기꺼이 바꾸면서도, 에이전트가 버그를 잡아내는 능력이 꽤 떨어졌다는 사실을 알아채지 못할 수 있다. 놓친 버그가 장애나 인시던트를 일으킬 때에야 알게 된다는 것이다.

과도한 파일 읽기는 저렴한 모델로 막을 수 있다고 Gupta는 말한다. 모든 맥락 조각을 훑어보고 어떤 것을 포함할지 결정하는 모델이다. 이론적으로는 Java나 결정 API로 만든 것 같은 결정 모델이 여러 항목을 다시 순위 매기고, 무엇을 프런티어 모델의 캐시에 올리고 무엇을 올리지 않을지 결정할 수 있다. 그는 이 캐시를 가장 비싸고 희소한 자원 중 하나라고 부른다.

그는 이 모든 것을 하는 팀이라면 자체 리뷰 에이전트를 만드는 데 꽤 멀리 갈 수 있을 것이라고 말하며 마무리한다. 직접 만들어 보는 팀은 이메일로 연락해 달라고 청하고, 직접 만들지 않기로 한 팀은 Greptile의 제품을 쓸 수 있다고 말한다. 그것은 이에 비해 무료라고 설명한다.