저는 Claude를 사용한 30회 이상의 Opus ultra code 세션을 분석하여 동적 워크플로우 (dynamic workflow)가 어떻게 실행되는지, 토큰이 어디에서 소비되는지, 그리고 절약할 수 있는 범위가 어디인지 파악했습니다.

Ultra code 모드에서 Claude는 결정론적인 JavaScript를 작성하고, 각 단계마다 서브 에이전트 (subagents)를 호출하며, 중간 결과물을 채팅창 대신 스크립트 변수에 저장함으로써 작업을 수행합니다. 별도의 검증 에이전트 (verifier agents)가 출력을 확인하므로, 동일한 에이전트가 자신의 작업을 스스로 검토하지 않습니다.

토큰 소모는 다음과 같은 여러 요인으로 인해 발생했습니다:

• 작은 작업들이 거대한 워크플로우로 확장됨
• 아주 작은 개입만으로도 너무 많은 서브 에이전트가 트리거됨
• 동일한 파일들이 여러 에이전트에 의해 반복적으로 읽힘
• 자신의 작업에 대한 지속적인 자기 성찰 (introspection)
• 비용이 저렴한 Sonnet 또는 Haiku 모델로 작업을 위임할 수 있는 상황에서도 이를 고려하지 않음
• 검증 과정이 확인, 수정, 재확인의 개방 루프 (open loop)가 됨

Opus가 워크플로우를 어떻게 실행해야 하는지 구체적으로 오케스트레이션 (orchestrate) 하도록 프롬프트를 변경하자 큰 차이가 나타나기 시작했습니다.

프롬프트 구조는 작업 정의, 결과 목표 정의, 각 서브 에이전트의 작업 출력에 대한 검증 및 승인 프로세스, 저렴한 모델로의 사전 위임 계획, 검증 에이전트가 판단을 담당하게 함으로써 자기 성찰 감소, 그리고 서브 에이전트 수 제한 등을 정의합니다.
또한 이 프롬프트 구조는 Claude가 당면한 작업을 분해하고, 독립적인 작업 단위에 맞춰 조정된 서브 에이전트 수를 제안하도록 만듭니다. 저는 최종 실행 전에 이를 승인하거나 수정합니다.

저는 이를 단순한 프롬프트를 Ultra-code 모드에서의 동적 워크플로우 오케스트레이션 및 실행을 지시하는 워크플로우 적합 프롬프트로 재작성해 주는 스킬 명령 (skill command)으로 구축했습니다.
다른 분들도 사용하고 싶다면 여기에 스킬을 공유해 두었습니다 - 여기를 클릭하세요

그럼에도 불구하고 이것이 완벽한 것은 아니지만, Claude를 그냥 풀어놓아 스스로 결정하게 하는 것보다는 훨씬 낫습니다. Ultra-code 모드에서 오케스트레이션용 JavaScript 자체가 Claude가 가장 먼저 생성하는 것이기 때문에 프롬프트를 준수할 확률이 매우 높지만, 여전히 확률적인 (probabilistic) 특성을 가지고 있기 때문입니다.

이 내용이 유용하기를 바랍니다.
제출자: /u/coolreddy
[link] [comments]