두 번 재고 한 번 자르기: Claude 위에 기획 레이어를 구축한 CodeRabbit의 비결

해당 블로그는 CodeRabbit의 원저자의 글 'Measure twice, cut once: How CodeRabbit built a planning layer on Claude'을 번역한 것입니다. 더 나은 이해를 위해서 약간의 의역이 반영되었습니다.

CodeRabbit 유저 그룹 카카오톡 오픈채팅방이 있습니다. 관심 있으신분들은 오셔서 함께 소통하면 좋을 것 같습니다.

CodeRabbit VP of AI David Loker는 주말 사이드 프로젝트를 하나 진행하고 있었습니다. 메모리 엔진에 보안 인프라를 씌우고 채팅 인터페이스를 얹어서 테스트해보려는 것이었죠. 개발자라면 누구나 해봤을 법한 일입니다.

구상은 명확했습니다. 전부 로그인 뒤에 잠그고, 사용자 인증을 넣고, 세션을 계정에 묶을 것. 처음부터 보안을 잡아야 했죠.

Claude Code를 돌리고 원하는 걸 설명했습니다. 수정하고, 토큰이 흘러가는 걸 지켜봤습니다. 몇 시간 동안 시스템이 빌드하고, 컴파일하고, 앞으로 나아갔습니다. 드디어 "완료"라고 떴을 때, Loker는 직접 써보려고 했습니다.

로그인 방법을 물었습니다.

시스템은 사용자 토큰을 쓰라고 했습니다.

토큰은 어디서 받냐고 물었습니다.

답이 없었습니다. 로그인 페이지 자체가 없었거든요. 사용자를 만드는 방법도, 그 어떤 인증 플로우도 없었습니다. '사용자'라는 개념을 중심으로 꼼꼼하고, 성실하고, 정확하게 만들어진 애플리케이션이었지만 — 정작 사용자를 만드는 방법은 아무도 알려주지 않았던 거죠.

"제가 놓친 거였어요." 최근 Anthropic과 함께 진행한 웨비나에서 Loker는 이렇게 말했습니다. "그걸 구체적으로 명시해야 한다는 걸 깨닫지 못했죠."

몇 시간을 돌렸고, 기능적으로는 정교한 애플리케이션이 나왔습니다. 그런데 로그인할 수가 없었습니다.

아무도 말하지 않는 AI의 품질 비용

CodeRabbit은 전 세계 엔지니어링 팀의 PR 워크플로우 한가운데에 있습니다. 수천만 건의 코드 리뷰를 처리하면서 AI 기반 개발이 실제로 어떻게 돌아가는지 안에서 지켜보고 있죠. 다만 속도와 양이 이야기의 전부는 아닙니다. 말하기 불편한 이면이 있습니다.

맞습니다, AI 코딩 도구 덕분에 개발자는 확실히 빨라졌습니다. 개발자당 PR이 20% 늘었고, 기능은 더 빨리 나가고, 백로그는 줄었습니다. 생산성 향상은 진짜입니다.

그런데 이면의 비용도 진짜입니다. 장애는 23.5% 늘었고, AI가 만든 코드는 사람이 짠 코드보다 이슈가 1.7배 많습니다. 가독성 문제는 3배나 뛰었죠.

Loker는 이걸 'AI의 숨겨진 품질 비용'이라고 부릅니다. Anthropic Applied AI 엔지니어 Ethan Dixon, Anthropic AE Brittney Tong과 함께 진행한 웨비나에서 그가 짚은 핵심은, 대부분이 원인을 잘못 짚고 있다는 것이었습니다.

"모델 탓만은 아니라는 게 제 생각입니다." Loker가 청중에게 한 말입니다. "사실 도구를 쓰는 방식 의 문제예요."

모델이 문제가 아닙니다. 워크플로우가 문제죠.

아무도 모르게 만들어지는 전제들

웨비나 중간에 "AI 프로젝트가 어디서 틀어지나요?"라는 실시간 투표를 했는데, 결과는 압도적이었습니다. '중요한 요구사항을 명시하지 않고 당연하다고 여겼다'가 1등이었죠.

얼핏 단순한 문제 같지만 뿌리가 깊습니다. 개발자가 AI에게 기능을 설명할 때, 머릿속에는 코드베이스 구조, 팀 컨벤션, 회사 인프라에 대한 수년치 맥락이 담겨 있습니다. 너무 자연스러워서 그게 '전제'라는 자각조차 없는 것들이죠. 그런데 AI는 그런 배경을 전혀 모릅니다. 신입도 마찬가지고요. AI는 비어있는 부분을 알아서 메꾸고 그냥 진행해버립니다.

"우리도 원래 몰랐는데 누군가한테 배워서 알게 된 게 많잖아요. 그런데 한번 알고 나면 다들 당연히 안다고 생각하게 돼요. AI한테도 똑같은 짓을 하는 거죠." 투표 결과를 보며 Loker가 한 말입니다.

로그인 페이지가 빠진 건 AI가 못해서가 아닙니다. Loker가 — AI 코딩 도구를 써본 거의 모든 개발자가 그렇듯 — 자기 머릿속 모델이 완전하다고 느꼈을 뿐, 실제로는 빠진 게 있었기 때문입니다.

테스트 통과만으로는 부족할 때

이 실패 패턴이 특히 무서운 건, 거의 끝까지 안 보인다는 점입니다. 코드는 컴파일되고, 테스트는 통과하고, 빌드도 잘 돌아갑니다. 기존 지표로만 보면 다 괜찮아요. 그런데 막상 로그인하려고 하면 — 아무것도 없습니다.

"테스트가 통과한다고 해서 문제가 해결됐다는 뜻은 아닙니다." Loker의 말입니다. "진짜 문제는 코드 컴파일 단계에 있는 게 아닐 때가 있어요."

완전히 새로운 실패는 아닙니다. 개발자도 원래 가끔 엉뚱한 걸 만들었으니까요. 의도와 결과물 사이의 어긋남은 소프트웨어만큼이나 오래된 문제죠.

달라진 건 이 문제가 쌓이는 속도 입니다. AI 이전에는 기능 하나 만드는 데 시간이 꽤 걸렸기 때문에 문제가 도중에 자연스럽게 드러났습니다. 다음 단계를 생각하면서 잠깐 멈추기도 하고, 동료한테 지금 뭘 하고 있는지 설명하기도 했죠. 작업 과정 자체가 돌아볼 틈을 만들어줬습니다. AI는 그 마찰을 거의 다 없앱니다. 목적 자체가 그거고, 대체로 좋은 일이긴 합니다.

다만 이제는 누가 안 막으면 잘못된 방향으로 아주 멀리까지 가버립니다. 예전에는 며칠 걸리면서 자연스럽게 생기던 피드백 루프를, 이제는 일부러 설계해서 넣어야 합니다.

"코드 만드는 건 꽤 빠릅니다. 그런데 잘못된 길로 너무 멀리 간 다음에 뒤늦게 알아차리면, 되돌아오는 비용이 큽니다." Loker의 지적입니다.

아버지에게 배운 교훈

캐나다에서 자란 Loker는 아버지와 함께 울타리, 데크, 지하실 같은 것들을 만들며 자랐습니다. 아버지의 입버릇이 있었죠. 틀린 말이 아니라서 오히려 더 짜증나는 그런 류의 잔소리. "두 번 재고, 한 번에 잘라라(measure twice, cut once)."

"나무를 한번 자르면 끝이에요. 맞게 잘랐거나, 아니면 새 나무를 가져와서 처음부터 다시 하거나." Loker의 설명입니다. "어린 마음에 항상 느리게 한다는 게 짜증났는데, 결국 신중하게 하는 게 전체로 보면 더 빠르다는 걸 알게 됐어요."

아버지의 또 다른 말도 있었습니다. 급한 아이한테 역시나 짜증나는 말이었죠. "급할수록 돌아가라(less haste, more speed)."

"이제야 이해가 돼요." Loker가 말했습니다. "Claude Code로 엄청 빨리 갈 수 있거든요. 그런데 결국 잘못된 걸 만들고 있었다는 걸 일찍 알아차리는 게, 몇 시간 반복한 끝에 원하던 게 아니었다는 걸 깨닫는 것보다 백배 낫습니다."

수백 년 된 엔지니어링 원칙입니다. 소프트웨어보다 훨씬 오래된 것들이죠. 그런데 AI가 판을 바꾸면서 다시 절실해졌습니다. 에이전트가 몇 분이면 수천 줄을 뽑아내는 세상에서, 방향을 잘못 잡는 비용은 역대 최고입니다.

프롬프트만으로는 부족하다

요즘 AI 코딩 도구의 기본 패턴은 Loker 표현으로 '프롬프트 원샷 워크플로우'입니다. 설명을 프롬프트에 넣고, 에이전트가 실행하고, 코드가 나옵니다. 빠르고 직관적이지만, 가정이 숨는 곳도 바로 여기입니다.

"그 과정에서 제 가정을 놓치더라고요. 직접 파고들고, 생각하고, 검토하는 과정이 없으니까. 그냥 의식의 흐름대로 하고 있는 거예요." Loker의 말입니다.

혼자만의 문제로도 비용이 크지만, 팀으로 가면 구조적 문제가 됩니다.

팀에서 한 개발자가 혼자 에이전트한테 프롬프트를 넣으면, 그 사람의 가정과 맥락, 요구사항 해석은 다른 누구한테도 안 보입니다. 안 보이는 걸 잡아낼 수는 없죠. 시니어가 "우리 Redis 구성이랑 안 맞는데?"라고 지적할 수도 없고, PM이 "원래 스펙이랑 다른데?"라고 발견할 수도 없습니다. 가정은 흩어지고, 아무 소리 없이 쌓여갑니다.

엔지니어링 규율로서의 계획

Dixon은 계획이 왜 중요한지를 프로세스가 아닌 기술적 관점에서 풀었습니다. Anthropic 내부에서는 컨텍스트 엔지니어링 을 깊이 고민합니다. AI 모델의 어텐션 윈도우에 어떤 정보를 언제 넣을지 관리하는 방법론이죠.

Dixon에 따르면 컨텍스트는 유한한 자원입니다. 프롬프트에 토큰 하나를 더 넣을 때마다, 다른 토큰과 모델의 어텐션을 두고 경쟁이 벌어집니다. 너무 많이 넣거나, 엉뚱한 걸 넣거나, 타이밍이 안 맞으면, 긴 작업에서 모델이 산만해집니다.

Dixon은 Opus 4.6이 needle-in-a-haystack 같은 테스트 리더보드를 오르며 긴 컨텍스트 일관성이 확실히 좋아졌다고 언급하면서도 "컨텍스트 엔지니어링이 풀린 문제라고 보긴 어렵습니다" 라고 덧붙였습니다.

실행하다가 뒤늦게 쫓아다니는 대신, 계획 단계에서 미리 잡아야 한다는 게 그의 주장입니다.

"계획을 능동적인 컨텍스트 엔지니어링 수단으로 쓰면 좋은 게, 사전 작업이 전부 미리 로드된다는 거예요. 탐색하고, 발견 작업을 하고, 정말 일관된 계획을 세우면 — 장기적으로 에이전트가 훨씬 효과적으로 움직입니다." Dixon의 설명입니다.

이런 사전 투자 없이 에이전트를 돌리면, 비싼 컴퓨팅으로 파일을 다시 읽고, 예상 못 한 버그에 걸려 되돌아가고, 처음부터 갖고 있었어야 할 맥락을 다시 만드느라 시간을 날립니다. 이렇게 보면 계획은 단순히 좋은 프로젝트 관리가 아닙니다. 좋은 시스템 아키텍처입니다.

CodeRabbit의 해답: 에이전트 위의 레이어

CodeRabbit의 답은 CodeRabbit Plan입니다. 코딩 에이전트 위에 올라가는 오케스트레이션 레이어로, 에이전트를 대체하는 게 아니라 방향을 잡아주는 역할입니다.

이 구분이 Loker한테는 중요합니다. "Claude Code의 계획 시스템을 없애려는 게 아닙니다. 한 단계 위에서 정확한 방향으로 좁혀주는 오케스트레이션이고, 협업할 수 있게 만들어서 명시해야 할 것들이 전부 명시되도록 하는 거예요."

시작점은 이슈 트래커입니다. Jira, Linear, GitHub Issues, GitLab에서 티켓이 들어오면 플래너가 움직입니다. Claude Opus를 메인 브레인으로 코드베이스를 탐색하고, 과거 PR에서 관련 맥락을 끌어오고, 숨어있는 가정들을 끄집어내서, 단계별로 검토할 수 있는 코딩 계획을 만듭니다. 핵심은 이 계획이 팀 전체의 산출물이라는 점입니다. 코드 한 줄 쓰기 전에 이미 보이고, 고칠 수 있고, 버전이 관리됩니다.

"계획 자체가 품질 게이트예요. 그걸 정말 잘 만들 수 있다면... 그 뒤로 나오는 코드가 확연히 달라집니다." Loker의 말입니다.

세 개 모델, 하나의 플래너

CodeRabbit Plan은 모델 하나로 돌아가지 않습니다. Claude Opus, Sonnet, Haiku 세 개를 씁니다. Loker 표현대로, 작업 복잡도에 맞게 모델을 골라 배치합니다.

중심은 Opus입니다. Loker는 이걸 "메인 브레인이자 오케스트레이션 루프"라고 불렀습니다. 시스템에서 가장 높은 수준의 추론을 맡습니다. "전략적 결정을 내리고, 뭘 이해해야 하는지, 이 문제에 대해 뭘 모르는지 파악하고, 그 정보를 체계적으로 찾아가는 전략을 세우는 역할이에요."

Sonnet은 "좀 더 구체적이고 범위가 잡힌 작업"을 맡습니다. 잘 정의돼 있지만 분량이 꽤 되는 구조화된 작업들이죠.

Haiku는 가장 가벼운 작업, 복잡도 낮은 일과 컨텍스트 추출을 담당합니다. Loker가 예를 들었습니다: "큰 파일이 있는데 여기서 함수 하나를 뽑아야 해요. 뭘 하는 함수인지만 알면 되고 코드 전체는 필요 없어요." 이런 추출 작업에 Haiku를 쓰면, 굳이 필요 없는 곳에 비싼 Opus나 Sonnet 토큰을 태우지 않습니다. "Haiku는 토큰 비용이 저렴하고 빨라요. 그리고 이런 작업은 엄청 자주 일어나거든요. 비용과 시간을 많이 아낄 수 있습니다."

Dixon의 Haiku 평가: "대부분은 Sonnet-light로 봅니다." 다만 부하가 걸리면 얘기가 달라진다고 했습니다. "여러 파일을 돌아다녔거나, 복잡한 계획 중간쯤에서는 Sonnet 대비 Haiku의 품질 차이가 느껴지기 시작해요."

Loker가 정리한 티어링의 원칙은 단순합니다: "핵심 브레인은 필요한 곳에만 쓰고, 전부 다에 쓰지는 않는 것."

평가 시스템 구축하기

플래너를 만들려면 CodeRabbit이 아직 갖고 있지 않던 걸 새로 만들어야 했습니다. 코드 품질이 아니라 계획 품질 을 평가하는 시스템이었는데, 예상보다 훨씬 어려웠다고 Loker는 인정했습니다.

"처음에는 사람이 직접 튜닝해야 해요. 수동 검사를 많이 하고, 계획의 특정 부분을 평가할 수 있는 LLM 심사 시스템을 천천히 쌓아 올려야 합니다."

의외로 어려웠던 건 계획의 디테일 수준을 잡는 것이었습니다. 너무 세세하면 코드가 조금만 바뀌어도 계획이 금방 낡아버리거든요. "그 균형점 찾는 게 힘들었어요. 반복을 정말 많이 했습니다."

나중에 또 하나 깨달은 게 있었습니다. 탐색 단계에서 소비한 토큰 수를 측정해서, 계획 단계가 실제로 이후 효율을 높여주는지 판단하는 신호로 쓰는 것이었습니다. 최종 산출물이 코드이니까, 계획을 거친 코드와 계획 없이 바로 뽑은 코드를 비교해볼 수 있는 거죠.

Dixon은 이런 평가 방법론이 다른 곳에도 적용된다고 했습니다. "이런 기술 위에 제품을 만드는 팀이라면, 자기 도메인에서 적절한 디테일 수준이 어디인지 고민하는 것만으로도 큰 도움이 됩니다."

작업의 기록

협업 계획에는 당장의 산출물 말고도 숨은 가치가 있습니다. Loker가 웨비나에서 시간을 들여 설명한 부분이기도 합니다. 팀이 같이 계획을 세우고, 가정을 꺼내놓고, 범위를 놓고 토론하고, 성공 기준에 합의하면 — 뭘 왜 결정했는지에 대한 기록이 남습니다.

"새로 온 사람이 이걸 어떻게 만들었는지, 왜 만들었는지 궁금할 때 — 이제 기록이 있어요. 날아가지 않습니다." Loker의 말입니다.

이 기록은 검증 도구이기도 합니다. 코드가 나오면 원래 계획과 대조해볼 수 있거든요. 테스트 통과 여부만이 아니라, 의도에 맞는지도요. 우리가 하겠다고 한 걸 했나? 합의한 성공 기준을 충족했나?

다시 절실해진 오래된 지혜

Dixon이 AI 코딩의 새 국면을 이렇게 정리했습니다. "계획 품질이라는 게, LLM 기반 지식 작업에서 새롭게 중요해진 변곡점입니다."

새로운 아이디어가 아닙니다. 엔지니어라면 다 알고 있었죠. 뭘 만드는지 제대로 이해하고 시작하는 것과 대충 감 잡고 덤비는 것의 차이가, 순조롭게 나가는 프로젝트와 아무도 틀렸다고 인정 안 하면서 세 번씩 다시 만드는 프로젝트를 가른다는 걸요.

달라진 건 경제학입니다. AI가 '생각'에서 '실행'까지의 시간을 극단적으로 줄여버려서, 방향이 틀렸을 때의 비용이 비대칭적으로 커졌습니다. 몇 주 걸리던 걸 몇 시간이면 만들 수 있다는 건, 역사상 가장 빠르게, 가장 큰 규모로 틀릴 수 있다는 뜻이기도 합니다.

로그인 페이지 이야기는 돌이켜보면 웃기긴 합니다. 토큰을 몇 시간이나 태워서 정교한 애플리케이션을 만들었는데 정작 로그인을 할 수가 없으니까요. 하지만 이건 단순한 해프닝이 아니라, 병목이 옮겨갔다는 걸 아직 체감 못 한 업계 전체를 위한 비유이기도 합니다. 예전에는 코드 짜는 게 병목이었습니다. AI가 그걸 치워버렸죠. 이제 병목은 뭘 짤지 아는 것, 그리고 첫 줄이 생성되기 전에 다 같이 합의하는 것입니다.

결국 Loker의 아버지 말이 맞았습니다. 두 번 재고, 한 번에 자르기. 급할수록 돌아가라.

다만 AI 코딩 에이전트와 빠진 로그인 페이지를 직접 겪고 나서야 그 교훈이 제대로 와닿았을 뿐이죠.

CodeRabbit Plan을 지금 사용할 수 있습니다. 여기에서 시작하세요.