모델 셋을 한 팀으로 엮는 법 — jinn 데몬과 3-tier 에이전트 분업
3-tier 에이전트 분업의 묘미
혼자 북 치고 장구 치게 뒀더니 토큰만 잔뜩 태우고 뻗어버리는 에이전트한테 진절머리가 났다면 이 글을 봐야 한다.
단일 모델 하나한테 아키텍처 설계부터 코딩, 버그 검증까지 몽땅 떠맡기던 시대가 저물고 있다. r/ClaudeCode에 한 개발자가 Fable 5, Opus 4.8, GPT 5.6 Sol 세 모델을 3단 분업 파이프라인으로 엮고 jinn이라는 오픈소스 데몬으로 무려 60시간 동안 사람 개입 없이 풀오토로 돌려버린 사례를 공개했다.
데모 수준의 장난질이 아니라, 자율 실행에서 가장 흔하게 터지는 고질병—무한 검증 루프—을 엔지니어링으로 어떻게 틀어막았는지에 대한 실전 팁이 가득하다.
세 모델, 세 가지 역할
구조는 아주 깔끔하다. Fable 5가 오케스트레이터, Opus 4.8이 구현자, GPT 5.6 Sol이 리뷰어다.
Fable은 전체 흐름을 설계하고 각 단계에서 다음 에이전트에게 넘겨줄 컨텍스트를 정리한다. “무엇을 만들 것인가”를 판단하는 PM 역할. Opus는 그 설계를 받아 실제 코드를 작성한다. 그리고 Sol이 그 코드를 검사한다. 버그를 찾고, 엣지 케이스를 지적하고, 놓친 부분을 짚어낸다.
역할 분담 자체는 흔한 아이디어다. 진짜 난제는 그다음이다.
무한 리뷰 루프를 어떻게 끊을 것인가
멀티에이전트 시스템이 스스로 무너지는 1순위 원인은 ‘검증 지옥’이다. Sol이 버그를 지적하면 Opus가 고치고, 고친 코드를 Sol이 다시 트집 잡고, Opus가 또 수정하다가 엉뚱한 곳을 깨뜨리고… 이 사이클이 무한 뺑뺑이를 돌며 토큰을 게걸스럽게 처먹는다.
jinn은 이 지옥을 세 가지 철칙으로 끊어냈다:
첫째, 자기 작업에 서명하지 않는다. 에이전트가 “내가 짠 코드”라는 메타데이터를 남기지 않는다. 누가 짰든 동일한 제3자의 눈으로 냉정하게 평가하여 자기 코드를 방어하려는 기제를 차단한다.
둘째, 리뷰 횟수는 최대 2회로 하드 캡. Sol의 리뷰는 딱 2번까지만 허용한다. 세 번째 턴으로 넘어가려 하면 태스크를 즉시 멈추고 사람에게 알람을 쏜다. 이 강제 종료 장치 덕에 시스템이 한 태스크에 영원히 갇히지 않는다.
셋째, 명확한 기계적 중지 조건. “버그가 안 보일 때까지” 같은 모호한 문장 대신, “유닛 테스트 100% 통과”, “커버리지 N% 이상” 같은 명확한 종료 조건을 박아둔다. 조건이 충족되면 리뷰어가 더 딴지를 걸고 싶어도 파이프라인은 다음 스테이지로 강제 진행된다.
60시간 무인 실행의 의미
이 세팅으로 60시간 동안 무인 실행을 돌렸는데, 주간 API 쿼터의 절반도 안 썼다고 한다. 모델 셋을 돌렸는데 단일 모델로 혼자 끙끙댈 때보다 토큰 효율이 훨씬 좋았다.
비결은 각자 잘하는 일만 시켜서 컨텍스트 윈도우가 뚱뚱해지는 걸 막은 덕분이다. 모델 하나가 다 하려 들면 대화가 길어져 토큰 비용이 기하급수적으로 폭증하는데, 셋이서 짧은 호흡으로 치고 빠지니 오히려 단일 모델보다 비용이 싸게 먹힌다.
Sol이 Fable이 미처 생각지 못한 엣지 케이스를 뒤에서 낚아채 주는 상호 보완 효과도 톡톡히 봤다. 혼자서는 절대 자기가 판 함정에서 빠져나오지 못하는데, 바깥의 다른 모델이 객관적으로 들여다보니 즉시 해결되는 거다.
왜 주목해야 할까
AI 코딩의 방향성이 “더 똑똑한 단일 모델 찾기”에서 “적당한 모델들을 어떻게 조율할 것인가”로 넘어가고 있다. 코드 리뷰, 페어 프로그래밍, CI/CD 등 인간 소프트웨어 공학이 수십 년간 다듬어온 분업의 지혜가 AI 에이전트 파이프라인에 그대로 이식되는 중이다.
앞으로 코딩 에이전트의 경쟁력은 모델 깡스펙이 아니라, 모델들을 어떻게 오케스트레이션하고 조율하느냐의 아키텍처 싸움이 될 공산이 크다.
정리
jinn의 3-tier 구조는 모델별 특화, 무한 루프 차단 캡, 그리고 비용 절감이라는 세 마리 토끼를 영리하게 잡았다.
단일 모델의 원맨쇼에 의존하는 시대는 저물고 있다. 커뮤니티의 발 빠른 개발자들은 이미 에이전트 팀을 꾸려 일시키는 다음 단계로 성큼 넘어가고 있다.