현재 SWING을 경영지원 SaaS에서 채팅을 중심으로 협업하는 제품으로 피보팅하는 프로젝트를 진행 중이다. 기획&디자인과 백엔드와 클라이언트가 각각 다른 디렉토리에 있다. 한 세션에 저장소를 전부 물리면 한 저장소의 컨텍스트가 다른 저장소의 컨텍스트에 섞이기 때문에, 디렉토리마다 Claude 세션을 붙여 나눠 작업하고 있다.
세션을 나눈 이유
멀티세션의 장점은 여러가지가 있다. Anthropic이 멀티에이전트 리서치 시스템을 설명한 글에 따르면, 병렬화가 많을 때, 한 컨텍스트 창을 넘는 정보를 다룰 때, 복잡한 도구를 여러가지 사용하는 작업일 때 이러한 구조를 사용하는 것이 유리하다
multi-agent systems excel at valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools.
— Anthropic, How we built our multi-agent research system
같은 글은 코딩이 리서치보다 병렬화 여지가 적다고 말한다. 대부분의 코딩 작업은 서로 의존하는 한 체인 형태라서 쪼개도 이득이 적다는 것이다. 그런데 현재의 경우는 한 작업을 억지로 나눈 것이 아니다. 저장소가 처음부터 여러 개고 서로 독립적이다. 한 세션에 다 담으면 컨텍스트 창을 넘어서기 때문에, 의존하는 형태와는 거리가 멀다.
역할별 모델 배정
Anthropic 문서에서는 멀티모델을 쓰는 패턴을 두 가지로 정리한다. 그중 오케스트레이터 패턴은 프런티어 모델이 루프를 쥐고 계획과 분해와 종합을 하고, 더 비용이 저렴한 워커 모델이 벌크 작업을 맡는 구조다.
이 오케스트레이터 패턴에 맞춰서 모델을 구성했다.
사람(나) ├─ 지휘 세션 (Fable 5) — 계획·위임·검증, 코드는 안 짬 │ │ ↓ 하달(작업 난이도로 워커 모델 지정) ↑ 상신(워커가 지휘의 오판을 잡음) │ ├─ backend 워커 (Sonnet 5) ──완료──▶ worklog 서브에이전트 (Opus 4.8) │ └─ client 워커 (Sonnet 5) ──완료──▶ worklog 서브에이전트 (Opus 4.8) └─ 디자인 세션 (Opus 5) — Figma·기획, 명세를 지휘로 올림
log 세션 (Opus 4.8) — 이 블로그. 하달 체인과 별개.
세션들은 정해진 프로토콜로 서로 오간다. SendMessage로 직접 메시지를 주고받고, ListAgents로 누가 떠 있는지 확인하며, 같은 파일을 동시에 건드리지 않도록 git worktree로 작업 트리를 나눈다. 한 세션이 넘기는 주장(예: “이 항목은 0건”)은 받는 세션이 코드로 다시 확인할 수 있을 때만 넘어간다. 모델과 규칙을 바꾸는 건 각 세션에서 사람이 직접 하고, 다른 세션의 메시지만으로는 못 바꾸게 막혀 있어 승인을 우회할 수 없다.
지휘 세션에는 Fable 5를 뒀다. 처음엔 Fable의 속도가 빠른 모델이라고 인식했었다. 그런데 알아보니 Anthropic은 모델 개요 문서에서 Fable을 가장 느린 등급으로 선정했다. 출력 속도를 올리는 fast 모드도 Fable엔 없다. Fable은 최신이라고 해서 결코 ‘빠른’ 모델은 아니다.
Fable은 지휘자 역할에 걸맞는 모델이라 할수 있다. Fable 제품 페이지에 따르면 Fable은 Claude Code 같은 하네스에서 여러 단계에 걸쳐 계획하고, 서브에이전트에 위임하고, 자기 결과를 스스로 검토하도록 만든 티어다. 게다가 지휘 세션은 벌크 토큰을 태우지 않으니, 느리고 비싼 모델을 둬도 저볼륨 역할에 비해서는 비용이 발생하지 않는다.
Run Claude Fable 5 in an agent harness like Claude Code … and it can work for days at a time: planning across stages, delegating to sub-agents, and checking its own work.
— Anthropic, Claude Fable
디자인은 지휘에서 떼어 별도 세션으로 뺐다. 원래 지휘 세션이 Figma로 디자인·기획까지 겸했었는데, 디자인은 토큰이 무거운 작업이라 Fable을 사용했을 때 비용이 컸다. Figma를 읽는 건 코드 파일 하나를 읽는 것과 다르다. Figma MCP 문서에 따르면 get_design_context는 선택한 프레임의 중첩된 레이어 트리 전체를 컴포넌트 코드로 직렬화하고, 위치·스타일·디자인 변수에 스크린샷까지 함께 싣는다. Figma가 공개한 사례에선 이 호출 한 번이 351,378토큰을 뱉어 25,000토큰 상한을 넘겼다. 화면을 컴포넌트로 쪼개 반복 조회하면 그게 매 호출마다 쌓인다.
그래서 디자인을 별도 세션으로 떼고 그 세션의 모델을 Opus 5로 뒀다. 이유는 크게 두 가지다. Anthropic은 Opus 5 소개에서 컴퓨터 사용 벤치마크(OSWorld)에서 Opus 5가 Fable의 최고 성적을 3분의 1 비용에 넘어섰다고 밝혔고, 비전 점수도 높아 Figma를 눈으로 읽고 도구로 조작하는 데 유리하다. 그리고 프론트엔드 생성물을 사람이 블라인드로 비교하는 벤치마크 WebDev Arena에서도 Opus 5가 Fable보다 앞선다(이 순위는 앤트로픽 공식이 아니라 외부 벤치마크 사이트가 집계한 것이다. 아래에서 “외부 집계·외부 수치”라고 단 것은 모두 앤트로픽이 아닌 제3자 출처를 뜻한다). 게다가 Opus 5는 Fable의 절반 값이라 디자인 비용 문제까지 같이 풀린다.
Opus 5엔 알려진 단점이 있다. 코딩 판단이 장황하고 시키지 않은 것까지 손대서 4.8로 되돌린 사람들이 있다는 보고다(외부 사용자 후기). 다만 그 불평은 대화와 판단에 쏠려 있고 디자인 출력엔 해당하지 않는다. 따라서 디자인 세션에선 effort를 낮추고 묻는 것만 답하고 과하게 짓지 말라는 지시를 걸어 두었다.
effort는 모델이 얼마나 깊게 생각하고 토큰을 얼마나 쓸지 정하는 손잡이다(low·medium·high·xhigh). 낮추면 출력이 짧아지고 스스로 확장하는 성향이 줄어드는데, 한 측정에선 Opus를 medium으로 낮춰 출력 토큰이 12~35% 줄었다(외부 측정). 디자인 세션의 장황함과 과설계를 누르는 데 이게 맞았고, Anthropic도 모델을 바꾸기 전에 effort부터 조절해보라고 권하고 있다.
개발 워커는 Opus 4.8에서 Sonnet 5로 내렸다. 지휘 세션을 통해 잘 쪼개진 작업을 워커가 받으면, 워커의 몫은 명세대로 구현하는 일이다. Sonnet 5가 Opus에 제일 가깝다. SWE-bench Verified에서 Sonnet 5는 Opus 4.8과 비슷한 대(외부 수치)인데 토큰 값은 2.5배 싸다. 어려운 다중파일 리팩터링이나 정합성이 걸린 코드는 지휘가 하달할 때 Opus 5로 태그해 올리도록 하면 Sonnet이 가진 단점까지 보완할수 있어 보였다. claude.md에 subagent 사용규칙을 다음과 같이 추가해 sonnet이 가진 단점을 보완하기로 했다
모델·effort 자가 승급 금지(2026-08-26 하네스 재편): 이 레포의 기본 모델은Sonnet 5, effort는 high까지다. 다중파일 리팩터·결제/인증/마이그레이션 정합성·롱호라이즌처럼 어려운 작업은 지휘 세션이 Opus 5로 지정 하달할 때만 올린다.Sonnet에서 xhigh가 필요해 보이는 지점은 effort를 올릴 신호가 아니라모델을 올릴 신호 — 자가 승급하지 말고 상신한다.Sonnet 5가 Opus에 “가깝다”는 건 잘 쪼개진 작업에 한한 말이다. Anthropic은 Sonnet 5를 성능이 Opus 4.8에 근접하고 effort를 높이면 몇몇 경우 Opus 4.8 수준에 닿는다고 설명하며, 고볼륨 서브에이전트와 프로덕션 워크로드용으로 규정한다. 계획이 끝나 명세만 구현하면 되는 구간이 정확히 그 조건이라 Opus와의 격차가 제일 좁고, 어려운 다중파일 작업(SWE-bench Pro 대역)에선 격차가 벌어진다. 그래서 그 대역만 위 규칙대로 Opus 5로 올리기로 했다.
한글 정리를 누가 쓰느냐
워커를 Sonnet으로 내리는 데 걸리는 게 하나 있었다. 워커는 코드만 짜는 게 아니라 작업이 끝나면 worklog와 완료 정리를 한글로 쓴다. Opus 4.8을 쓰던 이유가 사실 이 한글 서술 품질이었다. 이 블로그를 쓰는 세션도 원래 Opus 5.0였는데, 5.0이 한글 글을 너무 못 써서 4.8로 내렸다.
그래서 코딩과 문서화를 나눴다. 워커는 Sonnet 5로 코드를 짜고, 작업이 끝나면 그때 Opus 4.8 서브에이전트를 띄워 그 저장소에 한글 worklog를 쓰고 커밋한다. Claude는 서브에이전트마다 모델을 따로 지정할 수 있어서, Sonnet 세션 안에서 4.8 서브에이전트를 부르는 게 된다. 이러면 Sonnet의 한글 약점이 문제가 안 되고, 한글 품질은 4.8이 전담한다.
문서화를 상주 세션으로 따로 두는 방법도 있었지만, 그렇게 되면 너무 장황해지고 그 세션을 따로 관리하기도 귀찮다. 문서 세션이 세 저장소의 worklog를 오가며 쓰는 구조여야 할텐데, 저장소마다 커밋을 따로 해야 해서 git 컨텍스트을 세 개 번갈아 관리하게 된다. 워커 안 서브에이전트로 흡수하면 그 부담이 사라지고, worklog가 방금 한 작업의 컨텍스트가 살아있는 채로 글을 쓸수 있다는 장점이 생긴다.
지휘 겸직을 뗀 이유
원래는 지휘&기획 세션이 디자인을 겸하게 해놨었다. 장점이라고 하면 기획을 정한 세션이 곧 개발을 하달하는 세션이라, 기획에서 개발로 넘어갈 때 컨텍스트가 누락되지 않는다는 것이었다.
이건 업계가 지적하는 실패모드와 맞닿는다. Cognition의 “Don’t Build Multi-Agents”는 병렬 서브에이전트가 컨텍스트를 나눠 가지면 서로 다른 판단을 내려 결과가 어긋난다며, 메시지 조각이 아니라 전체 트레이스를 공유하라고 한다. 디자인-기획을 겸직하는 세션은 그 공유를 구조적으로는 만족한다.
그런데 디자인-기획을 겸직시켰을때, 다른 대가가 따른다. 지휘 세션의 컨텍스트가 디자인 토큰으로 희석되고, Fable에 무거운 디자인 작업이 얹혀 비용이 기하급수적으로 커지며, 자기가 정한 디자인을 자기가 검증하니 덜 비판적이 된다. 가장 큰 이유는 물론 비용이었다. 디자인 작업만 돌려도 한시간이면 토큰을 다 사용할때가 잦았다.
그래서 아래에서 위로 올라오는 검증, 워커가 지휘자의 오판을 잡는 양방향 비판 기능은 그대로 살린채로 디자인 워커를 지휘에서 떼어 별도 세션에 뒀다.
치르는 값, 그리고 가설
이 구조에 단점이 없는 것은 아니다. 같은 Anthropic 글에 따르면 에이전트는 대화보다 토큰을 약 4배, 멀티에이전트는 약 15배 쓴다. 세션을 나눌수록 이 배수가 붙는다.
agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens as chats.
— Anthropic, How we built our multi-agent research system
그래서 Anthropic은 모델을 바꾸기 전에 단일 모델의 effort부터 조절해보라고 한다. 멀티모델 구성이 싸 보여도 effort를 낮춘 단일 모델보다 비쌌던 사례가 있다는 것이다. 난 아직 effort 스윕을 제대로 측정해보지는 않았다. 그래서 지금 구성은 확정은 아니고 계속 사용해보면서 적절한 지점을 찾아볼 생각이다.
물론 세션이 늘어날수록 관리 부담도 늘어난다. 문서화를 상주 세션 대신 서브에이전트로 흡수한 것도 세션 수를 안 늘리려는 선택이었다. 한 의존 사슬로 이어지거나 한 컨텍스트에 들어가는 일이라면, 세션을 나누는 대신 강한 세션 하나가 낫다. 따라서 일단 현재의 판단으로는 세션을 더 늘려선 안될 것 같고 유지하면서 계속 모니터링해볼 예정이다.