r/ClaudeAI•약 6시간 전•18•13

Opus 5.5로 Sonnet 에이전트 오케스트레이션하기

Opus 5.5 orchestrating sonnet agents

핵심 요약

Opus 5.5를 오케스트레이터로 활용해 Sonnet 에이전트의 작업 효율과 비용을 최적화하는 전략에 대한 논의입니다.

작업 효율 최적화 — 에이전트의 작업 난이도에 따라 모델과 노력 수준을 명시적으로 설정함
리뷰 전략 개선 — 구현 모델과 리뷰 모델을 분리하여 사각지대를 방지함
Haiku 활용 — 단순 작업이나 테스트에 Haiku 5.5를 도입해 비용 효율을 높임
비용 관리 — 단순히 모델 등급만 볼 것이 아니라 실제 토큰 사용량과 재작업 빈도를 고려함

안녕,

내 메인 모델(Opus 5.5 High)이 코딩용 Sonnet 5.5 에이전트들을 지휘하게 하려고 커스텀 스킬을 쓰고 있었거든. 근데 방금 들었는데 Sonnet 5.5 High가 Opus 5.5 Medium보다 비용이 더 많이 나간다네?

내 오케스트레이터가 Sonnet의 작업 강도를 어떻게 설정하는지 잘 모르겠는데, 다들 스킬 내에서 서브 에이전트들한테 작업 강도 제한하라고 명시적으로 지시함? Opus 5.5 Medium이 더 효율적인데 굳이 Sonnet 5.5 High를 쓸 이유가 있나? Sonnet 5.5를 Medium으로 제한해야 할까? 아니면 작은 작업들은 Low로 돌리는 게 나을까?

원문

커뮤니티 목록

r/ClaudeAI•약 6시간 전•18•13

Opus 5.5로 Sonnet 에이전트 오케스트레이션하기

Opus 5.5 orchestrating sonnet agents

핵심 요약

Opus 5.5를 오케스트레이터로 활용해 Sonnet 에이전트의 작업 효율과 비용을 최적화하는 전략에 대한 논의입니다.

작업 효율 최적화 — 에이전트의 작업 난이도에 따라 모델과 노력 수준을 명시적으로 설정함
리뷰 전략 개선 — 구현 모델과 리뷰 모델을 분리하여 사각지대를 방지함
Haiku 활용 — 단순 작업이나 테스트에 Haiku 5.5를 도입해 비용 효율을 높임
비용 관리 — 단순히 모델 등급만 볼 것이 아니라 실제 토큰 사용량과 재작업 빈도를 고려함

안녕,

주요 댓글

r/claudeai

오케스트레이터에게 전적으로 맡기기보다 작업 유형별로 노력 수준을 명시적으로 설정하고, 모델 간의 역할 분담과 테스트를 통해 효율을 최적화해야 한다는 의견이 주를 이룹니다.

내 스킬은 어떤 상황에서 어떤 모델을 어떤 노력 수준으로 써야 할지에 대한 대략적인 가이드를 제공함

나는 반대로 했음: Claude가 첫 구현을 하고, 그 이후의 리뷰와 모든 수정 단계는 Codex가 담당하게 함. 같은 모델이 자기 코드를 리뷰하게 하니까 똑같은 사각지대를 계속 놓치더라고. 그래서 두 엔진으로 역할을 나누니까 훨씬 더 많이 잡아낼 수 있었음. 너는 리뷰를 어떻게 처리해? Opus가 Sonnet 결과물을 직접 확인하는 방식이야?

맞아, 나도 계획을 짠 모델이 그대로 구현까지 하게 하는 게 가장 큰 결함이라고 생각함. 자기가 빼먹은 걸 계속 숨기거든. 요즘 '그 간극(the gaps)'에 대해 자주 읽는데, 내 경험상 메인 계획 작성자가 다른 에이전트에게 전달할 브리핑을 쓸 때, 미리 명확하게 지시하지 않으면 특정 가정이나 기본값을 건너뛰는 게 사실임. 계획 작성자와 구현 에이전트를 분리하면, 같은 모델이라도 다른 에이전트와 새로운 맥락에서 질문을 던지기 때문에 검토에 도움이 됨. 그래도 다른 LLM을 완전히 따로 쓰는 걸 100% 추천함. 나는 무료 모델들도 곁에 두는데, 걔네가 쓴 기본 브리핑이나 조사가 좋은 출발점이 되기도 하고, 자기가 직접 쓴 게 아닌 걸 검토하는 리뷰어로서도 좋은 관점을 제공하거든. 이미 흐름에 무료 모델을 넣지 않고 있다면, 얼마나 통합할 의지가 있느냐의 문제지.

ㅋㅋㅋ '그 간극'이 딱 그거임. 나한테 가장 효과적이었던 건, 계획 작성자한테 프로젝트를 전혀 모르는 사람한테 넘겨준다는 생각으로 브리핑을 쓰게 하는 거였음. 그리고 리뷰어가 계속 똑같은 걸 지적하면, 건건이 수정하는 대신 앞으로 나갈 모든 브리핑에 규칙 하나를 추가해버림. 무료 모델을 리뷰어로 써본 적은 없는데, 너는 어떤 게 괜찮았어?

Haiku를 섞어봐. 먼저 테스트를 시켜서 뭘 할 수 있는지 확인하고, 마크다운을 읽게 해서 코드 문제를 수정하게 해봐. 얘가 처리할 수 있는 수준에 놀랄걸.

특히 지금은 Haiku 5.5가 있으니까 더 그렇지. Haiku 4.5는 GPT Luna나 Gemini 3.8 Flash에 비해 너무 뒤처졌었는데, Haiku 5.5는 드디어 따라잡았고 아주 든든한 일꾼 모델이 됐음. 대부분은 얘가 얼마나 유능한지 아직 모름. 더 높은 등급의 모델로 계획을 짜서 Haiku(나 다른 저사양 모델)에게 지시하고, 더 좋은 모델을 오케스트레이터와 리뷰어로 쓰면 아주 합리적인 가격으로 엄청난 양의 작업을 해낼 수 있음. 여기에 효과적인 테스트 주도 개발(TDD)까지 섞어서 안전망을 만들면 Haiku 같은 걸로도 정말 인상적인 결과물을 낼 수 있어.

내 생각엔 에이전트들이 다른 에이전트의 작업에 어느 정도의 노력이 필요한지 판단하는 건 불가능함. 이건 네가 직접 관리하고 규칙을 유지해야 하는 부분이라고 봐. 예를 들어 웹 검색만 하는 연구 작업, 아니면 계획 에이전트, 코딩 에이전트, 리뷰 에이전트처럼 말이야. 시간을 좀 들여서, 만약 다른 에이전트에게 최적의 방식을 찾게 할 거라면, 메인 모델과 함께 평가 방식을 고민해봐. 똑같은 작업들을 다 시켜보고 어떤 결과물과 품질을 선호하는지 확인해보는 거지.

맞아, 오케스트레이터가 결정하게 두기보다는 스킬에 명시적으로 설정하는 게 나을 거야. 오케스트레이터는 모든 하위 작업에 똑같은 노력 수준을 할당하는 경향이 있고, 누가 시도해보기도 전에 작업이 얼마나 어려운지 판단하는 걸 잘 못하거든.

내가 할 방식은 스킬에 짧은 표를 넣는 거야: 기계적인 작업(이름 변경, 알려진 수정 사항 적용, 테스트 실행 및 보고)은 낮게, 일반적인 기능 구현은 중간, 디버깅이나 설계 결정처럼 이미 한 번 실패한 작업에만 높게 설정하는 거지. 오케스트레이터 자체가 높은 노력을 들일 가치가 있는 곳이야. 왜냐면 나쁜 계획은 그 뒤에 오는 모든 하위 에이전트의 실행을 낭비하게 만드니까.

비용에 대해서는 'Sonnet High가 Opus Medium보다 비싸다'는 말을 무조건 믿지는 마. 높은 노력 수준은 주로 생각하는 토큰이 많아진다는 뜻이니까 작업에 따라 많이 달라져. 똑같은 작업을 두세 번씩 양쪽 방식으로 실행해보고 토큰 사용량과 재작업이 필요한지 비교해봐. 두 번째 패스가 필요한 저렴한 실행은 결코 저렴한 게 아니니까.

하위 에이전트를 써서 토큰을 아끼려는 거라면, 사실 별로 효과가 없어. 하위 에이전트는 메인 AI 에이전트와 병렬로 작업하거나(프로세서의 멀티스레딩을 생각하면 됨), 메인 에이전트에게 너무 많은 맥락이 쏠리는 걸 방지하는 용도에 가까워.

토큰을 아낄 수 있는 시나리오가 몇 개 있긴 한데, 작업이 너무 장황할 때 정도야. 근데 그 정도면 그냥 같은 프로젝트 내에서 새로운 작업을 만드는 게 나아. 적어도 게임 개발에 AI를 써본 내 경험은 그래.

원문r/ClaudeAI