CodeRabbit이 Claude로 에이전트 오케스트레이션 시스템을 구축한 방법

연재 시리즈 스타트업의 Claude 활용법에서는 AI로 업계를 변화시키고 있는 스타트업들을 소개합니다. 이번 글에서는 CodeRabbit이 AI가 코드를 생성하기 전, 구조화된 계획 단계를 먼저 실행하는 에이전트 오케스트레이션 레이어를 어떻게 구축했는지 살펴봅니다.

AI 코딩 도구의 등장으로 아이디어에서 작동하는 프로토타입까지 걸리는 시간이 크게 줄었다. AI 코드 리뷰 플랫폼인 CodeRabbit은 이러한 생산성 향상과 함께 다른 흐름도 감지했다. 바로 코드가 컴파일되고 테스트도 통과하지만, 팀이 실제로 만들고자 했던 것과는 다른 결과물이 나오는 현상이다.

CodeRabbit의 AI 부문 VP David Loker는 그 원인이 모델 이전 단계에 있다고 본다. 경험 많은 개발자일수록 코딩 에이전트가 자신과 동일한 맥락을 이해하고 있다고 가정하기 쉽다. 그러다 보니 자신에게 당연해 보이는 요구사항은 굳이 적어두지 않는다. 결국 코딩 에이전트는 그 빈자리를 그럴듯해 보이는 내용으로 채워넣게 된다.

CodeRabbit은 이 문제를 해결하기 위해 Claude를 활용해 에이전트 오케스트레이션 시스템을 설계하고 구축했다. 코드 생성 전에 구조화된 계획 단계를 먼저 실행하는 방식이다. 팀의 핵심 가설은 이렇다. 계획의 품질이 결과물의 품질을 결정한다. 코드 생성 비용이 낮아질수록 잘못된 방향으로 나아가는 데 따르는 대가는 오히려 커진다.

AI 코딩에서 내재된 지식 공백 문제

CodeRabbit 팀이 고객사의 AI 생성 풀 리퀘스트(PR)를 분석했을 때, 가장 빈번한 실패 패턴은 공통적이었다. 컴파일도 되고 테스트도 통과하지만, 정작 해결해야 할 문제를 풀지 못한 코드였다.

"개발자는 경험이 쌓이면서 수많은 지식을 내면화합니다," Loker의 말이다. "그 모든 것이 머릿속에 있다 보니, 다른 개발자도 당연히 알겠거니 하고 넘어가게 되죠. AI 시스템에 대해서도 같은 가정을 하는 겁니다. 암묵적으로 이해하고 있을 거라고. 그런 가정을 하고 있다는 사실조차 인식하지 못한 채로요."

모호한 프롬프트는 시스템이 그럴듯해 보이는 내용으로 빈자리를 채우도록 만든다. 그 결과는 개발자가 의도했던 것과 다른 방향으로 흘러가기 마련이다.

Loker는 직접 겪은 사례를 들었다. 사이드 프로젝트에서 메모리 시스템을 구축할 때의 일이다. 코딩 에이전트와 수 시간 동안 반복 작업을 거친 끝에 모든 것이 작동하게 됐다. 그런데 에이전트에게 사용 방법을 물어보니, 사용자 토큰을 전달하라는 안내가 돌아왔다. 로그인 페이지는 없었다. 사용자가 필요하다고만 명시했을 뿐, 로그인 방법까지는 언급하지 않았던 것이다. 에이전트는 그 공백을 채웠고, 수 시간의 작업 결과물은 정작 입구가 없는 제품이 되어버렸다.

"그 위에 무언가를 계속 쌓아 올리다가, 한참 뒤에야 문제가 있다는 걸 발견하게 됩니다," Loker가 말했다. "AI 워크플로에서 뒤늦은 검증은 대가가 큽니다."

AI 코딩 앞단에 놓인 오케스트레이션 레이어

CodeRabbit은 코드 생성 앞단에 계획 시스템을 삽입하는 방식으로 이 문제에 대응했다. 여러 Claude 모델을 조율해 요구사항을 분석하고 숨겨진 가정을 드러낸 뒤, 무엇을 만들어야 하는지와 충족해야 할 제약 조건을 정의한 구조화된 실행 계획을 만들어낸다.

"이 계획 시스템은 Claude Code의 Plan Mode를 대체하려는 게 아닙니다," Loker의 설명이다. "Claude Code가 실행되기 전 단계에서 이루어지는 더 높은 수준의 오케스트레이션입니다. 명시되어야 할 모든 것이 명시되고, 모든 가정이 수면 위로 드러난 상태에서 정확히 올바른 방향을 잡아주는 역할을 합니다."

결과물은 협업 기반의 제품 요구사항 문서(PRD)다. 충분한 맥락을 바탕으로 작성되고, 구현에 앞서 팀 전체의 검토와 합의를 거친 계획이다. Claude Code는 이 계획을 토대로 세밀한 구현 계획을 수립한다. 이 계획 문서는 무엇을 어떤 이유로 결정했는지 기록하는 공유 산출물이 된다. 덕분에 팀은 재작업을 줄이고 나중에 결과물이 원래 의도와 일치하는지 검증할 수 있을 뿐 아니라, 신규 엔지니어 온보딩에도 활용할 수 있다.

Claude 모델 패밀리 간 라우팅

CodeRabbit은 비용과 레이턴시를 최적화하기 위해 각 모델 티어를 작업 복잡도에 맞게 배분한다. Opus는 오케스트레이션 루프와 문제를 이해하고 전체 방향을 설정하는 고수준의 전략적 작업을 담당한다. Sonnet은 그 결과를 받아 구조화된 계획 단계로 순서화하는 역할을 맡는다. Haiku는 컨텍스트 압축이나 특정 도구 호출처럼 범위가 명확히 한정된 작업을 처리한다. 질문이 충분히 구체적이라면 소형 모델로도 충분히 답할 수 있는 작업들이다.

"특정 작업에서 Haiku가 Sonnet만큼 잘한다면 Haiku를 씁니다," Loker가 말했다. "평가 하네스(evaluation harness)가 Opus에 더 많은 여지를 줄 때 계획 품질이 높아진다고 알려주면, 그렇게 합니다. 추측으로 결정하지 않습니다."

계획 품질을 위한 평가 하네스 구축

CodeRabbit은 코드 리뷰 평가 시스템은 이미 성숙한 수준으로 갖추고 있었지만, 계획 결과물을 평가하는 시스템은 없었다. 그 인프라를 구축하는 것 자체가 별도의 프로젝트가 됐다.

시스템은 수작업으로 조정한 예시와 직접 검수하는 방식으로 시작됐다. 팀은 계획 품질의 특정 차원을 점수화하는 LLM 심사자(judge) 라이브러리를 개발했다. 계획은 결국 코드를 생성하기 때문에, 생성된 코드가 실제로 작동하는지, 의도하지 않은 범위가 포함됐는지, 그 과정에서 토큰이 얼마나 소모됐는지도 함께 측정할 수 있었다. 동일한 작업을 계획 단계 포함 여부에 따라 비교 실행함으로써 계획 자체의 가치를 독립적으로 측정하는 방법도 마련됐다.

"계획에 적절한 세부 수준이 어느 정도인지 처음에는 알 수 없었습니다," Loker의 말이다. 너무 세밀한 계획은 코드베이스가 바뀌는 순간 곧바로 낡은 것이 됐다. 너무 추상적인 계획은 에이전트가 가정을 채워넣을 여지를 남겼고, 이는 계획 레이어가 처음부터 해결하려 했던 바로 그 문제였다. 작동하는 추상화 수준을 찾는 데는 반복 실험이 필요했고, 이를 가능하게 한 것이 바로 평가 하네스였다.

코드 작성 전에 오류를 잡다

AI 네이티브 코딩 워크플로에서는 기존에 코드 리뷰 단계에서 드러나던 많은 결정들이 이제 더 앞선 계획 단계에서 이루어진다. 코드 생성이 시작되기 전에 팀이 검토하고 합의할 수 있는 계획을 만드는 것이 초기 단계에서 실수를 잡아내는 핵심이다.

"Claude 생태계를 활용해 저희가 만든 것은 팀 전체를 아우르는 계획 시스템입니다," Loker의 말이다. "계획 자체가 품질 관문이 됩니다. 초기에 계획의 품질을 확실히 높여두면, 그 후속 효과는 매우 뚜렷하게 나타납니다. 최종적으로 훨씬 나은 코드를 얻게 됩니다."

스타트업을 Claude Platform으로 구축하세요.