Anthropic은 프로젝트 코디네이터로 Fable 사용을 권장하지 않음

그 조언은 애초에 나쁜 조언이었기 때문임. 코디네이션은 읽고 쓰는 작업이 엄청나게 많고, 생각하는 과정은 거의 없음. 그런데 생각하는 데 특화된 모델을 읽고 쓰는 작업에 쓰는 건 10배나 더 비싸니까 완전히 거꾸로 된 방식이지.

많은 사람이 코디네이션을 아키텍처나 시스템 엔지니어링이랑 착각함. Fable을 시스템 엔지니어/아키텍트로 쓰는 건 좋은 생각임. 하지만 다른 하위 에이전트들과 계속 소통하고 그들의 작업물을 전부 읽어야 하는 코디네이터로 쓰는 건 그냥 낭비일 뿐임.

사실 전혀 낭비가 아님. "코디네이션은 읽고 쓰는 작업이 엄청나게 많고, 생각하는 과정은 거의 없음"이라고 했는데, 사실 바로 그 지점이 프로젝트 맥락을 제대로 이해하고 구현을 지시하는 측면에서 강력한 모델이 필요한 이유임.

기본적으로 강력한 모델은 항상 이점이 있음. 코디네이션과 구현에 더 싼 모델을 쓰면 하위/API 비용은 아낄 수 있을지 몰라도, 더 강력한 모델이라면 절대 하지 않았을 이상한 구현 결정이나 버그가 발생할 확률이 높아짐.

지금 현실 세계에 있는 우리 대부분은 토큰 비용 때문에 제약이 많음. 우리 모두 Fable을 항상 쓰고 싶지만 그럴 수가 없음. 그래서 그 점을 고려하면, Fable이 계획을 짜게 하고, 코디네이터로는 Opus 같은 고성능 에이전트를 돌리면서, 주기적으로 Fable을 호출해 계획을 수정하게 하는 게 훨씬 효율적임. 내 에이전트 사다리 구조에서는 Opus 에이전트가 컨텍스트 윈도우를 다 채우지 않기 위해 같은 수준의 다른 Opus 에이전트를 호출해서 작업을 시키기도 함.

프로젝트 코디네이터는 오케스트레이터가 아님.

프로젝트 코디네이터는 네 메시지를 거의 그대로 새로운 스레드로 전달할 뿐임. 그 스레드 모델이 당면한 작업의 오케스트레이터인 거지.

대부분의 경우 코디네이터는 Haiku여도 충분함. 그냥 네 요청을 프로젝트의 해당 부분을 처리하는 적절한 채팅 스레드로 라우팅해 주는 거니까.

오케스트레이터는 하위 에이전트를 생성하고, 코드를 검토하고, 검색하고, 도구를 호출하는 등의 작업을 함. 코디네이터는 스스로 그런 작업을 전혀 하지 않음.

Anthropic이 우리 이미 알고 있던 사실을 재발견했네 : 관리자가 되기 위해 똑똑할 필요는 없다는 거.