전부 최고 모델로 짜다가 실행만 경량으로 내렸다 — 안 돌아가는 이유

2026-07-07 · Ascendy Engineering

TL;DR

같은 파트 사람들과 얘기해 보니, “모델을 섞어 쓰면 결과가 낫다”엔 다 동의하는데 plan·implement·review에 어떤 모델을 앉히느냐는 사람마다 완전히 달랐다.
세 배치가 사실 “제일 좋은 모델을 어디에 쓸 것인가”에 대한 서로 다른 베팅이다. 그런데 그 베팅을 정하는 건 취향이 아니라 제약(예산·레이트리밋·병렬 개수)이었다.
나는 전부 최고 모델(3번)로 시작했다가 토큰 한도에 부딪혀, 실행만 경량으로 내렸다. 그리고 안 돌아간다 — 최고 모델이 짜도 어차피 리뷰에서 고칠 게 나오니, 실행 품질보다 루프를 빨리 도는 것이 이겼기 때문이다.
그러니 남의 배치를 베끼지 마라. 네 제약이 네 배치를 정한다.

이 글에 대하여. 인터뷰로 끌어낸 1인칭 기록이다. “실행에 최고 모델은 과잉”이라는 건 내 베팅이지 정답이 아니다(그래서 강한 문장은 내 견해로 밝혀 둔다). 등장하는 모델명은 벤치마크가 아니라 내 실제 세팅이고, 2026년 중반 기준이라 금방 낡는다. 같은 결의 멀티에이전트가 무조건 정답은 아니다, 토큰 소모량은 생산성이 아니다와 이어진다.

다들 모델을 섞는데, 배치가 다르더라

최근 같은 파트 사람들과 흥미로운 얘기를 나눴다. 요즘 다들 에이전트에게 일을 시키는데, 한 모델로만 돌리는 사람은 없었다. “여러 모델을 섞어 쓰면 결과가 더 좋다”는 명제엔 이견 없이 동의했다. 그런데 실제로 섞는 모습이 사람마다 너무 달라서 재미있었다.

크게 세 갈래였다. 에이전트 작업을 계획(plan) → 구현(implement) → 리뷰(review) 세 단계로 본다고 할 때:

계획·구현은 경량 모델, 리뷰만 좋은 모델. (예: 계획·구현을 Gemini 3.5 Flash로, 리뷰를 Claude Opus로.)
계획은 좋은 모델, 구현은 경량, 리뷰는 또 다른 좋은 모델. — 내 경우다. Claude Opus로 계획하고, Gemini 3.5 Flash로 구현하고, GPT-5.5로 리뷰한다.
계획·구현·리뷰 전부 최고 모델. 대신 리뷰만 다른 계열로.

셋 다 “모델을 섞는다”는 같은 원칙을 따르지만, 제일 좋은 모델을 어디에 몰아주느냐가 정반대다. 1번은 “리뷰가 제일 중요”에 걸었고, 3번은 “다 좋은 걸로, 대신 리뷰만 갈라라”에 걸었다. 그럼 나(2번)는 왜 하필 계획에 최고 모델을 앉히고, 구현은 일부러 싸게 내렸을까?

세 배치는 사실 “품질을 어디에 넣을까” 베팅이다

각 배치는 각자의 믿음을 인코딩하고 있다. “한정된 예산으로 좋은 모델을 딱 한 군데만 쓸 수 있다면, 어디에 쓰겠는가?”에 대한 답이다.

계획에 걸면 — “방향이 틀리면 전부 틀린다. 품질은 위(계획)에 넣어야 한다.”
구현에 걸면 — “결국 코드를 잘 짜는 게 중요하다.”
리뷰에 걸면 — “어차피 실수는 나온다. 마지막에 잘 걸러내는 게 중요하다.”

그럴듯한 논리가 다 있다. 그런데 정작 내가 이 배치를 고른 진짜 이유는 논리가 아니었다. 제약이었다. 그 사실을 나는 내 경험으로 배웠다.

내 여정: 전부 최고로 → 벽 → 실행만 경량으로

솔직히 나도 처음엔 3번이었다. 계획도, 구현도, 리뷰도 전부 최고 모델로 돌렸다. 품질만 보면 그게 당연해 보였으니까.

문제는 속도와 비용이었다. 전부 최고 모델로 돌리니 작업 하나가 너무 오래 걸렸고, 토큰 소모가 커서 몇 개 작업만 하면 한도에 걸렸다. 나는 지금 여섯 개 남짓한 영역에서 에이전트를 병렬로 굴리고 있어서, 이 한도는 매번 아프게 다가왔다. 최악은 Claude 주간 한도를 다 써버려서 하루 이틀 동안 아무 일도 못 하는 것이었다.

그래서 AI들에게 물었다 — 다른 고민(제약)을 같이 던지면서. “토큰이 늘 부족하다. 예산이 한정돼 있으니, 최대한 토큰 효율적이면서도 결과도 좋은 조합을 찾아 달라.” Gemini, Claude, GPT 모두 지금의 2번 구조가 낫다고 만장일치였다.

웃긴 건, 나는 이걸 AI들에게 투표를 시켜서 다수결로 정한 셈이다(이견이 있었으면 아마 토론을 붙였을 거다). 하지만 정직하게 말하면 — 그 만장일치는 합의라서 믿을 만한 신호였다기보다, 예산 조건을 딱 걸면 누구나 내놓는 당연한 산수에 가까웠다. 제일 토큰을 많이 태우는 단계에 제일 싼 모델을 꽂는 것. 그게 다다. 나는 그걸 믿어서 쓴 게 아니라, 벽에 부딪힌 뒤 해결책으로 적용해 봤다가 만족해서 계속 쓰는 거다.

실제로 구현은 보통 토큰을 가장 많이 태우는 단계다. 코드를 길게 쏟아내고, 고치고, 반복하니까. 예산이 빡빡하면 거기에 경량 모델을 꽂는 게 절약 레버리지가 제일 크다. 계획은 토큰이 적고 레버리지는 높으니 좋은 모델, 리뷰는 실패를 잡아야 하니 좋은 모델. 남는 구현에 싼 모델. — 이게 내 2번의 정체다.

심지어 구현에 뭘 쓰느냐도 품질이 아니라 예산 주머니로 갈린다. 개인 프로젝트에선 Claude Sonnet으로 구현하고, 회사에선 Gemini 3.5 Flash(구글이 에이전트·코딩용으로 더 빠르고 저렴함을 내세우는 모델이다)로 구현한다. 어느 게 더 좋아서가 아니라, 어느 예산으로 굴리느냐의 차이일 뿐이다.

안 돌아가는 이유 — 최고 모델도 어차피 리뷰에서 걸린다

여기서 중요한 질문. “내일 토큰이 무제한이 되면, 3번(전부 최고)으로 돌아갈 거냐?”

내 답은 안 돌아간다이다. 이유는 이렇다.

Claude Opus 4.8이 코드를 짜도, Codex 리뷰에서 꼭 고칠 부분이 나온다. 이건 Fable 5 같은 최상급 모델이 짜도 똑같았다. 한 번에 완벽한 결과가 나오는 건 어차피 불가능하다. 그렇다면 승부는 실행 모델의 품질이 아니라, 빨리 결과를 내고 → 빨리 피드백을 받아 → 이 과정을 빨리 돌리는 것에 있다고 나는 판단했다.

즉 구현 단계는 이렇게 정리된다:

“계획을 제대로 구현할 수 있는 최소선”만 넘으면 된다. 그 위의 품질은 어차피 리뷰가 걷어내니 과잉이다.
단, 바닥은 있다. 속도만 보면 Haiku가 맞겠지만, Haiku는 아예 계획대로 구현하는 것 자체를 잘 못했다. 그 최소선을 못 넘는 거다. Sonnet과 Gemini 3.5 Flash는 넘는다.

그래서 비용 제약은 나에게 타협을 강요한 게 아니었다. 오히려 “실행에 최고 모델을 쓰는 건 낭비였다”는 걸 가르쳐 줬다. 빨리 도는 루프 안에서는, 구현이 조금 더 똑똑해서 얻는 이득보다 한 바퀴를 빨리 도는 이득이 더 컸다.

그래서 — 남의 배치를 베끼지 마라

이 이야기의 결론은 “2번이 최고다”가 아니다. 오히려 반대다.

동료들이 1번·3번을 고른 이유까지 내가 단정할 수는 없다. 다만 내 경험이 분명히 보여주는 건 — 배치가 의견보다 제약에 크게 좌우된다는 것이다. 병렬로 굴리는 에이전트 수가 적어 한도에 안 걸리거나, 예산이 넉넉하거나, 작업이 애매해서 구현에도 판단이 많이 필요하다면 — 최적의 배치는 얼마든지 달라진다. 그러니 남의 배치가 나와 다르다면, 의견 차이로 단정하기 전에 제약이 다른 건 아닌지부터 물어야 한다.

그러니 누가 “이 조합이 정답”이라고 하면, 되물어야 한다. “어떤 제약 아래에서?” plan·implement·review에 뭘 앉힐지는 벤치마크 표가 정해 주지 않는다. 네 예산, 네 레이트리밋, 네 병렬 개수, 네 작업 모양이 정한다. 나조차 무제한이 되어도 3번으로 안 돌아가는데, 하물며 네 상황은 내 상황과 다르다.

코다: 마비된 이틀이 준 것

한 가지 더. Claude 주간 한도를 다 써서 하루 이틀 아무것도 못 하는 그 시간이, 답답하기만 한 건 아니었다.

오히려 나는 그때 잠깐 멈춰서 생각한다. 정신없이 구현만 밀어붙일 때는 못 보던 부분이, 손이 묶여 있을 때 보이곤 한다. 어디로 가고 있었는지, 이게 맞는 방향인지. 강제된 멈춤이, 뜻밖의 리뷰가 되는 셈이다.

토큰 한도는 분명 제약이다. 그런데 그 제약이 내 배치를 더 낫게 만들었고, 가끔은 나를 멈춰 세워 방향을 다시 보게 했다. 제약은 늘 적(敵)인 것만은 아니었다.

가져갈 것

다들 모델을 섞지만, 배치는 제각각이다. 그 차이는 취향이 아니라 제약(예산·레이트리밋·병렬 개수·작업 모양)이 만든다.
나는 전부 최고 → 실행만 경량으로 왔고, 안 돌아간다. 최고 모델도 리뷰에서 걸리니, 완벽 원샷이 불가능하면 루프를 빨리 도는 것이 이긴다.
실행엔 “계획을 구현할 수 있는 최소선”만. 그 위는 리뷰가 걷어내니 과잉. 단 Haiku처럼 바닥을 못 넘는 모델은 안 된다.
남의 배치를 베끼지 마라. “어떤 제약 아래에서?”를 먼저 물어라. 네 제약이 네 배치를 정한다.

솔직히 이 글도 정답이 아니라 내 베팅이다. 다만 “제일 좋은 모델을 어디에 넣을까”를 고민하기 전에, “나는 지금 어떤 제약 아래 있나”를 먼저 묻는 것 — 그게 내가 벽에 부딪혀 배운 가장 실용적인 순서다.

저작·인용: 이 글은 Ascendy Engineering이 작성했으며 출처 표기 시 재인용 가능합니다. 잘못된 정보를 발견하면 GitHub 이슈로 알려주세요.

Tags: ai, agents, llm, cost, workflow, opinion