Qwen3.8 27B로 Claude를 지휘하면 Haiku, Sonnet, Opus에서도 거의 비슷하게 좋은 답변을 끌어낼 수 있음. 직접 작업할 때는 Fable 외에는 만족스러운 결과를 얻기 어려웠지만, Qwen에 관리·조율·간단한 조사를 맡기고 다른 모델에 요청하게 하면 훨씬 저렴하게 좋은 결과를 얻을 수 있었음. Qwen이 내 의도를 이해하면 다른 모델에 필요한 세부 정보를 충분히 채워 주기 때문이라고 추측함.
Qwen 5개로 구성한 팀이 Fable에 근접했다는 HN 글을 보고, 내 실행 도구인 https://github.com/alainnothere/privibe에 조율 도구를 추가함. 이후 Claude와 Qwen에 모델을 바꿔 가며 약 3회 실험하게 했는데, 두 모델 모두 조율 도구를 거친 응답들의 품질이 매우 비슷하다고 평가함. 다만 Opus와 Fable은 “내 생각에는 이렇게 하는 편이 좋겠음” 같은 제안을 더 많이 했고, 이는 내가 두 모델을 더 좋게 평가하는 이유와도 맞아떨어짐.
Copilot 모델도 직접 쓰면 만족스럽지 않지만, 내 의도를 이해한 Qwen이 Copilot CLI를 실행해 작업시키면 훌륭한 결과를 얻을 수 있음. Copilot CLI는 AIC 기준 요청 비용도 더 저렴한 듯해 구독 사용량을 더 오래 쓸 수 있어 보임.
나는 반대로 Opus 5.5를 조율·계획 전담으로 두고, Qwen3.8-27B를 하위 에이전트로 사용함. Opus에는 구현을 맡기지 않으며, 이렇게 Claude가 Qwen을 지휘하면 토큰 사용량이 크게 줄어듦. 반대 방향은 생각하지 못했는데 곧 시험해 보겠음.
작은 모델 → 큰 모델과 그 반대 방향의 하위 작업 위임을 많이 실험하고 있음. 지금까지는 문제 분야별 특성을 파악하는 감각이 중요하며, 토큰 비용 효율까지 고려하면 하나의 정답은 없어 보임.
가장 똑똑한 에이전트가 진전을 내려면 이미 시도한 방법과 내가 접근 방식에 준 영향까지 맥락 전체를 알아야 할까? 아니면 명확한 문제 정의와 충분한 컨텍스트 여유를 주는 편이 나을까?
사용 중인 모델에 빠진 정보를 직접 채우라고 하는 것과 무엇이 다를까? 중간 단계의 결과를 사람이 검토하지 않는다면, 모델을 하나 더 거치는 과정이 어떻게 사용자에 대한 이해를 높여 주는 걸까?
Anthropic에는 이를 위한 기본 기능인 /advisor 가 있음. Sonnet을 쓰면서 Opus를 자문 모델로 지정하거나, Haiku에 Sonnet 또는 Opus를 붙이면 약한 모델이 필요하다고 판단할 때 자동으로 자문을 요청함. https://code.claude.com/docs/en/advisor
더 강한 모델을 호출할 시점은 자동으로 판단한다고 하는데, 프롬프트나 AGENTS.md의 지침으로 얼마나 조절할 수 있는지는 모르겠음.
흥미로운 결과지만, 동일 개체 식별(identity resolution) 이라는 매우 구체적인 실험 과제의 벤치마크임. 제목과 달리, 본문은 일반적인 사용이나 코딩 에이전트 전반의 성능 향상을 주장하거나 입증하지 않음.
다만 이 패턴이 도움이 될 작업은 여러 종류일 듯하며, 실제 효과는 작업마다 달라질 수 있음.
이런 접근을 보면 단순한 AGENTS.md 파일을 넘어, 의사결정 모델이 맥락을 관리하고 우선순위를 정하는 방식이 컨텍스트 관리의 미래라고 생각하게 됨. 새로운 문제마다 맥락을 자동으로 선별·갱신·압축할 수 있는데, 굳이 에이전트에 모든 맥락을 넘길 이유가 있을까?
Jev는 직접 써 보지 않아도 효과를 알아볼 수 있는 전형적인 과학적 발견에 해당함. AGI·ASI 열풍이 만들어 낸 엄청난 잡음 때문에 이런 발견을 놓치고 있었을 뿐임.
보안 엔지니어링 작업에서 같은 혼합형 접근을 많이 쓰고 있으며, 초기 조정을 거친 뒤에는 잘 작동함. 자체 실행 도구의 자동 모드도 이런 방식으로 다시 만들어 도구 호출과 의도를 판단하게 함.
나도 같은 생각으로 opencode-warden을 확장해 로컬 의사결정 모델이 도구 입출력을 검증하도록 했는데, 그럭저럭 작동하는 듯함. d1은 오래된 1080 GTX에서도 충분히 빠르게 실행되지만, 여기에 의존하라고 권할 수 있을지는 모르겠음.
이상적으로 시스템 1 지능은 빠르게 반응하는 능력뿐 아니라, 언제 멈추고 시스템 2를 기다려야 하는지도 잘 알아야 함. Jev에서는 실제로 이런 방식이 작동함. 평소 추상적이고 감탄을 유도하는 마케팅 문구에 흥분하지는 않지만, 이 유사성은 인상적임.
우리는 이 방식을 한동안 써 왔으며, 의사결정 모델 미세 조정도 큰 도움이 됨. 여전히 신뢰도 임계값을 10% 정도로 상당히 낮게 잡아야 하지만, 자체 벤치마크에서는 품질 손실 없이 작업량을 70% 줄이는 경우가 많음.
대부분의 기업, 어쩌면 모든 기업에서 AI를 가장 즉각적이고 실용적으로 활용할 수 있는 분야 중 하나는 CRM 데이터 보강임.
새로운 접근법을 이해하려는 중인데, Jev/Luna의 실제 구현 코드 예제가 있으면 좋겠음.
여러 모델을 결합해 성능을 크게 높인다는 Anthropic의 미공개 새 접근법도 이런 방식일지 궁금함. 의사결정 모델을 최대한 활용해 속도와 토큰 효율을 높이는 것은 합리적으로 보임.
OpenAI와 Anthropic 모두 비슷한 라우팅 방식을 꽤 오래 사용해 온 것으로 알고 있음. 큰 모델이 준비되는 동안 작은 모델이 처음 몇 토큰을 먼저 출력해 즉각 반응하게 한 것도 OpenAI가 선도하지 않았을까? Grok도 한동안 내부적으로 Opus에 요청을 보내 온 것으로 생각함.