Using Opus 5.5 solo VS orchestrator
Opus 5.5를 단독으로 쓸지, 아니면 하위 에이전트를 활용한 오케스트레이터 방식을 쓸지에 대한 토론입니다.
Opus 3.5 하나만 써서 다 시키는 게 나을지, 아니면 Opus를 오케스트레이터로 두고 작업 난이도에 맞춰 Sonnet이나 Haiku 같은 서브 에이전트를 부리는 게 토큰 효율이나 개발 측면에서 더 나을지 고민 중이야. 다들 어떻게 쓰고 있어?
사용자들은 작업 규모에 따라 오케스트레이터 방식의 효율성을 긍정하면서도, 코드 리뷰의 독립성이나 모델별 성능 차이에 대해서는 다양한 의견을 보임.
그냥 개발이나 해, 걱정하지 말고. 사용량 제한에 문제없으면 그냥 Opus 써.
grep, docs, 테스트 실행을 위해 Sonnet이나 Haiku 하위 에이전트를 사용하는 Opus 오케스트레이터 방식은 쿼터를 엄청나게 아껴줌. 원본 파일 덤프가 Opus 컨텍스트 윈도우에 들어가지 않기 때문임. 핵심은 하위 에이전트가 파일 경로, 라인 범위, 짧은 요약만 반환하게 해서 Opus가 세션 전체에서 30k 토큰 미만을 유지하게 하는 거임.
CLAUDE.md 파일 예시 좀 보여줄 수 있음?
맞음, 어떻게 하는 거임?
개념 증명(POC)을 해봤음. 처음엔 Opus만 썼고, 그다음엔 Claude 에이전트가 생성한 코드 리뷰어가 있는 Sonnet으로 바꿨음.
POC는 기존 상업용 부동산 애플리케이션(약 37만 줄)의 문제를 찾기 위해 내 하네스(harness)와 Claude를 비교하는 거였음.
두 경우 모두 Claude는 10개의 문제를 반환했고, 내 하네스는 33개를 찾았는데 6개는 공통이었음.
이걸 통해 알게 된 건, 다른 모델을 쓰더라도 회사 에이전트는 여전히 같은 사각지대를 가진다는 거임. 그리고 다른 회사의 리뷰어를 생성하더라도 사실상 리뷰어가 뭘 해야 할지 통제하고 있으니 진정한 독립적 검토는 아님.
리뷰어는 메인 에이전트와 아무런 연결 없이 독립적으로 실행되어야 함.
교훈: 코더가 리뷰하게 하지 마라.
소프트웨어 회사들이 개발자와 독립된 QA 부서를 두는 이유가 바로 이거임.
난 Opus만 씀. Sonnet이나 Haiku는 필요 없음.
단일 인스턴스/프롬프트보다는 하위 에이전트가 있는 오케스트레이터를 선호함. 각 에이전트에 다른 모델을 할당하는 게 편리하고 다른 고차원 작업들을 위해 토큰을 아낄 수 있음.
최근 경험상 Opus는 작업이 자기 수준보다 낮다고 느끼면(예: 타사 API 통합 방법 조사) 자동으로 작업을 하청함. 페이지 요약 작업을 Haiku한테 넘겼는데, Haiku가 왜인지 페이지 일부만 요약하고 버벅거렸음. 내가 시키지도 않았는데 점점 더 자주 그러는 게 보임.
전반적으로 오케스트레이션이 가끔은 수준 이하의 결과를 낸다고 생각함. 특정 직무(개발자, QA, PM, 마케터 등)를 가진 여러 Sonnet과 Opus 에이전트가 필요할 때 소통하게 하는 실험을 해봤음. 토큰 사용량이 문제라 최적화 방법을 찾는 중이지만, 결과물은 훨씬 더 좋고 신뢰할 만함. 난 이렇게 생각함: Opus는 관리자나 시니어, Sonnet은 주니어, Haiku는 인턴. Fable은 프린시펄/스태프 같은 느낌이라 내가 만드는 것들에는 대부분 필요 없었음.
도움이 되길.
Opus한테 언제 작업을 넘길지 알려주는 에이전트 사다리를 쓰고 있음. 모델이 출시될 때마다 업데이트해야 하지만 현재 상태로는 꽤 만족함. 질문에 구체적으로 답하자면, 며칠 전에 medium 관련 작업을 하다가 계획(Fable이 작성한 계획이라고 생각함)의 한 부분에 도달했는데, 명확한 목표와 검증 지점이 있는 독립적인 섹션이었음. Opus가 모든 작업을 수행할 또 다른 Opus medium 하위 에이전트를 만들었고, 내가 이유를 물어봤음. 그 에이전트는 그런 잡무를 하청으로 돌리면, 같은 수준의 에이전트에게 맡기더라도 메인 세션의 캐시 읽기를 방지해 토큰을 아낄 수 있고 계획을 더 저렴하게 계속 진행할 수 있다고 했음.
내 에이전트 사다리는 이거임. https://github.com/dtiger1889-ops/agent-ladder
작은 기능 하나를 두고 같은 인수 테스트를 돌려서 두 방식을 비교해볼 거임. 토큰 사용량과 함께 재시도 횟수, 검토 시간을 세어볼 거임. Opus로 다시 해야 한다면 더 싼 첫 시도는 별로 절약이 안 됨.
실험을 좀 해봤고 이게 내 결론임. 더 복잡한 시스템도 있지만 나한테는 이게 좋은 균형이었음 https://abmccullough.github.io/ai-orchestrated-build-playbook/
마이크로매니징할 가치는 없을 듯. 아직 문제 되지도 않은 걸 미리 최적화하지 마.
작업 규모에 따라 다름. 작은 작업에는 하위 에이전트를 만드는 오버헤드가 가치가 없음. 긴 작업의 경우, 메인 세션의 컨텍스트를 채우지 않기 때문에 또 다른 Opus 에이전트를 만드는 것도 의미가 있음.
난 그냥 Opus가 오케스트레이터로서 결정하게 둠.
"오케스트레이션" 소리 듣는 거 이제 지긋지긋함... 그냥 에이전트 하나한테 다 맡겨. https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop
100% 동감. 단순하게 가자고. Codex나 Claude를 적대적으로 작업하게 시켜봐, 얼마나 많은 일을 끝낼 수 있는지 놀랄걸. 복잡한 오케스트레이션 필요 없음. 에이전트한테 "이거 Claude/Codex랑 적대적으로 작업해"라고 말만 하면 99.9%는 해결됨.
AI 에이전트 의존으로 코드베이스가 비대해지고 유지보수가 불가능해지자, 경영진이 다시 직접 코딩을 요구하기 시작함.
AI 에이전트 의존으로 코드베이스가 비대해지고 유지보수가 불가능해지자, 경영진이 다시 직접 코딩을 요구하기 시작함.
개인 프로젝트 디버깅 중 Claude의 가드레일이 이를 리버스 엔지니어링으로 오인해 차단하는 문제가 발생했습니다.
개인 프로젝트 디버깅 중 Claude의 가드레일이 이를 리버스 엔지니어링으로 오인해 차단하는 문제가 발생했습니다.
ChatGPT에 무작위 프롬프트를 반복 입력한 실험을 두고 AI를 대하는 윤리적 태도와 기술 활용의 가치에 대한 논쟁이 벌어졌습니다.
ChatGPT에 무작위 프롬프트를 반복 입력한 실험을 두고 AI를 대하는 윤리적 태도와 기술 활용의 가치에 대한 논쟁이 벌어졌습니다.