Claude API 비용이나 그 어떤 LLM 비용이라도 줄이려 한다면, 다른 모델을 벤치마킹하기 전에 에이전트 턴(agent turns) 수를 줄이는 것부터 시작하세요.

너무 단순하게 들릴 수도 있습니다.

하지만 이는 대부분의 모델 교체보다 더 많은 고장 난 에이전트 워크플로우(agent workflows)를 해결해 줍니다.

저는 계속해서 동일한 패턴을 목격하고 있습니다:

• 에이전트가 횡설수설하기 시작함
• 두 개의 서브 에이전트(sub-agents)가 계속해서 작업을 서로 주고받음
• 도구 호출(tool calls)이 증폭됨
• 누군가가 GPT vs Claude vs Grok 비교 스프레드시트를 만들기 시작함

때로는 모델 자체가 문제일 수도 있습니다.

하지만 대부분의 경우, 에이전트가 계속해서 말을 할 수 있는 자유가 너무 많아서 발생하는 문제입니다.

만약 당신의 스택이 OpenAI Agents SDK, LangGraph, OpenClaw, n8n, Make, Zapier 또는 커스텀 워크플로우(custom workflow)라면, 그 자유는 빠르게 비용 부담으로 이어집니다.

문제는 대개 지능이 아닙니다. 턴 예산(turn budget)입니다.

많은 "나쁜 모델 동작"은 사실 다음과 같습니다:

• 명확한 중단 조건(hard stop condition)이 없음
• 너무 많은 핸드오프(handoffs)
• 작업 간에 누출되는 공유 메모리(shared memory)
• 그래프 사이클(graph cycles)
• 에이전트가 스스로 작업 완료 여부를 결정함

마지막 항목이 바로 돈이 낭비되는 지점입니다.

만약 에이전트가 5턴이면 끝날 작업을 완료하는 데 30턴이 걸린다면, Claude Opus 4.6에서 GPT-5.4로 교체하는 것은 에이전트가 더 유창하게 당신의 예산을 낭비하면서 더 똑똑하게 들리게 만들 뿐일 수도 있습니다.

이 사실을 깨닫게 해준 OpenClaw 사례

저는 r/openclaw에서 누군가가 공유 메모리(shared memory)와 지속적인 정체성(persistent identities)을 가진 일종의 "하인 의회(council of minions)" 설정을 설명한 스레드를 발견했습니다.

그러자 에이전트들이 서로 대화를 나누기 시작했고, 스스로 아키텍처 문서(architecture document)를 생성해 냈습니다.

멋진 데모였습니다.

하지만 멀티 에이전트 시스템(multi-agent systems)이 어떻게 대화의 확산(conversational sprawl)으로 흘러가는지를 보여주는 완벽한 사례이기도 했습니다.

한 댓글 작성자가 정확히 짚어냈습니다. 에이전트들이 어떤 마법 같은 가짜 사회를 발명한 것이 아니었습니다. 설계(wiring)가 그러한 동작을 가능하게 만든 것이었습니다. 공유 메모리, 라우팅(routing), 정체성(identity), 그리고 지속성(persistence)은 주고받는 대화의 기회를 더 많이 만들어냅니다.

그것이 진짜 문제입니다.

추가적인 턴을 허용하는 시스템을 구축하고 나면, 가장 먼저 직면하는 문제는 모델의 문제가 아닙니다.

제어(control)의 문제입니다.

문서들은 실제로 이 점에 대해 꽤 명확하게 설명하고 있습니다

이 지점에서 주관적인 견해를 갖는 것이 좋은 이유는 공식 프레임워크 문서들이 대부분 이에 동의하기 때문입니다.

OpenAI Agents SDK: 루프 제한 (cap the loop)

OpenAI의 Agents SDK는 하나의 턴(turn)을 한 번의 AI 호출(invocation)로 취급합니다. 도구 호출(Tool calls)은 해당 턴 내부에서 발생할 수 있습니다.

만약 제한을 초과하면 MaxTurnsExceeded 오류를 발생시킵니다.

이는 통제 불능의 에이전트(runaway agents)에 대한 공식적인 해답이 "더 나은 모델을 선택하라"가 아니라, "루프를 중단하라"는 것을 의미합니다.

from agents import Runner

result = Runner.run(
...

저 max_turns=8이라는 한 줄은 많은 팀이 깨닫는 것보다 훨씬 더 많은 신뢰성(reliability) 확보 작업을 수행하고 있습니다.

LangGraph: 모델을 탓하기 전에 그래프를 점검하세요

LangGraph는 훨씬 더 직설적입니다.

재귀(recursion) 또는 단계(step) 제한에 도달하면, 문서는 그래프 로직과 사이클(cycles)을 확인하도록 안내합니다.

전형적인 실패 모드는 매우 단순합니다:

• 노드 a가 노드 b로 라우팅됨
• 노드 b가 다시 노드 a로 라우팅됨
• 이제 당신의 에이전트는 영원히 "추론(reasoning)"을 수행합니다.

설치/업데이트:

pip install -U langgraph

그러면 다음과 같은 코드를 볼 수 있을 것입니다:

graph.invoke(payload, {"recursion_limit": 1000})

복잡한 워크플로우(workflow)의 경우 더 높은 제한 값이 정답일 수 있습니다.

하지만 예상치 못하게 그 한계치에 도달했다면, 첫 번째 질문은 "이번 주에 Claude가 GPT보다 성능이 떨어지는가?"가 되어서는 안 됩니다.

그것은 "당신의 그래프에 사이클이 있거나 중단 조건(stop condition)이 누락되었는가?"가 되어야 합니다.

Anthropic의 가이드는 대부분의 에이전트 빌더보다 더 보수적입니다

에이전트에 대한 Anthropic의 엔지니어링 가이드는 가능한 한 가장 단순한 시스템으로 시작하고, 필요할 때만 에이전트적 복잡성(agentic complexity)을 추가하라고 말합니다.

이것은 매우 중요합니다.

그들은 기본적으로 다음과 같이 말하고 있는 것입니다:

• 기본적으로 에이전트들의 작은 의회(parliament)를 구축하지 마세요.
• 먼저 잘 구조화된 하나의 LLM 호출을 시도하세요.
• 에이전트 시스템은 유연성(flexibility)을 위해 비용과 지연 시간(latency)을 희생한다는 점을 받아들이세요.

이것은 에이전트 반대론이 아닙니다.

불필요한 에이전트 반대론입니다.

그리고 솔직히 말해서, 더 많은 팀이 이 이야기를 들어야 합니다.

모델 라우팅(Model routing)은 유용합니다. 치료법으로서의 모델 교체는 그렇지 않습니다.

저는 실질적인 목적이 있는 멀티 모델 오케스트레이션(multi-model orchestration)을 선호합니다.

예시:

• 코딩 작업은 GPT-5.4로 라우팅 (route)
• 긴 컨텍스트 합성 (long-context synthesis)은 Claude Opus 4.6으로 라우팅
• 저렴한 분류 (classification) 작업은 더 작은 오픈 모델 (open model)로 라우팅
• 분류 (triage)에는 빠른 모델을 사용하고, 최종 답변 생성 (final answer generation)에는 더 강력한 모델을 사용

이것이 전략입니다.

하지만 많은 팀이 모델 교체 (model rotation)를 마치 향을 피우듯 남용합니다.

워크플로에 유령이 나타난 것 같으니, 또 다른 모델을 휘둘러 쫓아내려 하는 식입니다.

대개 그 유령의 정체는 그저 잘못된 오케스트레이션 (orchestration)일 뿐입니다.

이러한 프레임워크들이 보통 무너지는 지점

무엇이 빠져 있는지 확인해 보세요.

이 프레임워크들 중 그 어느 것도 첫 번째 해결책이 Claude에서 GPT로 바꾸는 것이라고 말하지 않습니다.

그들은 모두 구조적 제어 (structural controls)를 제공합니다.

그것이 바로 당신이 가장 먼저 어디를 살펴봐야 하는지를 알려줍니다.

에이전트 혼란을 판별하는 빠른 냄새 테스트 (smell test)

만약 당신의 에이전트가 다음 중 하나라도 수행한다면, 무죄가 입증될 때까지 오케스트레이션의 잘못이라고 가정하십시오:

• 거의 비슷한 단어로 동일한 추론 (reasoning)을 반복함
• 이미 가지고 있는 데이터에 대해 도구 (tool)에 다시 요청함
• 불확실성을 줄이지 않은 채 에이전트 간에 작업을 넘김 (hands work)
• 출력이 이미 충분히 좋은 상태임에도 계속 논쟁함
• 현재 작업과 아무런 관련이 없는 공유 메모리 (shared memory)를 읽음
• 프롬프트 (prompt)를 개선할 때가 아니라, 에이전트를 더 추가할 때만 실패함

그것은 "창발적 지능 (emergent intelligence)"이 아닙니다.

그것은 브랜드 이름만 붙인 루프 (loop)일 뿐입니다.

모델 선택을 건드리기 전에 제가 수정할 것들

여기에 실제 플레이북 (playbook)이 있습니다.

1. 엄격한 턴 예산 (turn budget) 설정

편안하게 느껴지는 것보다 더 낮게 시작하세요.

만약 워크플로가 6~8턴 안에 끝나지 않는다면, 그것은 유용한 정보입니다.

result = Runner.run(
    starting_agent,
    input=user_request,
...

만약 당신의 유스케이스 (use case)에 8턴이 너무 낮다면, 의도적으로 늘리십시오.

사실상 무제한 (unbounded)인 상태로 두지 마십시오.

2. 중단 조건 (stop conditions)을 명시적으로 만들기

"완료 (Done)"가 "모델이 완료되었다고 느끼는 것"을 의미해서는 안 됩니다.

그것은 결정론적인 (deterministic) 무언가가 발생했음을 의미해야 합니다.

예시:

• JSON 필드가 채워짐
• 도구 (tool)가 유효한 결과를 반환함
• 검증기 (validator)를 통과함
• SQL 쿼리가 성공적으로 실행됨
• 사람의 승인 플래그 (human approval flag)가 설정됨

의사 코드 (Pseudo-code):

if result.status == "complete" and result.payload.get("summary"):
    return result
else:
...

3. 핸드오프 (handoffs) 줄이기

모든 핸드오프는 혼란이 발생할 수 있는 또 다른 기회입니다.

만약 두 개의 에이전트를 다음과 같은 것들로 대체할 수 있다면:

• 더 강력한 프롬프트 (prompt) 하나
• 도구 호출 (tool call) 하나
• 검증기 (validator) 하나

그렇게 하십시오.

많은 멀티 에이전트 (multi-agent) 설계들은 사실 트렌치코트를 입고 있는 싱글 에이전트 (single-agent) 작업일 뿐입니다.

4. 작업별로 메모리 분리하기

공유 메모리 (shared memory)는 어제의 디버깅 세션 내용이 오늘의 인보이스 파서 (invoice parser)로 유출되기 전까지는 똑똑해 보입니다.

세션 경계 (session boundaries)를 사용하십시오.

범위가 지정된 메모리 (scoped memory)를 사용하십시오.

관련 없는 컨텍스트 (context)는 공격적으로 삭제하십시오.

더 큰 컨텍스트 윈도우 (context windows)가 유용하긴 하지만, 그것이 허술한 메모리 설계를 용서해주지는 않습니다.

5. 모델 주변에 결정론적인 (deterministic) 코드 배치하기

다음과 같은 용도로 코드를 사용하십시오:

• 라우팅 (routing)
• 검증 (validation)
• 중복 제거 (deduplication)
• 재시도 (retries)
• 종료 (termination)
• 예산 집행 (budget enforcement)

판단이 실제로 필요한 경우에는 GPT-5.4 또는 Claude Opus 4.6을 사용하여 판단을 내리십시오.

루프 (loop) 자체가 존재해야 하는지 여부를 모델에게 결정하도록 요청하지 마십시오.

최소한의 Before/After 예시

제가 흔히 보는 사례를 단순화한 버전입니다.

나쁜 버전 (Bad version)

while True:
    response = agent.run(task)

...

문제점:

• 최대 반복 횟수 (max iteration count) 없음
• 결정론적인 성공 기준 (deterministic success criteria) 없음
• 핸드오프 (handoffs)가 무한히 튕길 수 있음
• 모든 단계가 드리프트 (drift)가 발생할 수 있는 표면적을 더 넓힘

더 나은 버전 (Better version)

MAX_STEPS = 8

for step in range(MAX_STEPS):
...

여전히 완벽하지는 않습니다.

하지만 이제 워크플로 (workflow)에 경계가 생겼습니다.

그것이 보통 비용과 신뢰성을 동시에 해결하는 방법입니다.

모델이 정말로 문제인 경우

공정하게 말하자면, 때로는 모델 자체가 병목 (bottleneck)인 경우도 있습니다.

만약 다음과 같은 것들이 필요하다면 모델을 교체해야 할 수도 있습니다:

• 더 나은 지시 이행 (instruction following)
• 더 강력한 도구 사용 (tool use)
• 더 나은 코딩 능력
• 더 긴 컨텍스트 추론 (longer-context reasoning)
• 더 신뢰할 수 있는 구조화된 출력 (structured output)

GPT-5.4가 Claude Opus 4.6을 압도하는 워크로드(workload)가 있는가 하면, Claude가 승리하는 워크로드도 분명히 존재합니다.

Grok 4.20이나 적절한 역할에 배치된 더 작은 오픈 모델(open models)의 경우도 마찬가지입니다.

하지만 만약 당신의 워크플로(workflow)가 중복 작업을 수행하거나, 루프(looping)에 빠지거나, 끝없는 대화를 생성하고 있다면, 더 뛰어난 모델을 사용하는 것은 대부분 더 비싼 비용을 치르며 실패하게 만들 뿐입니다.

아무도 말하지 않는 숨겨진 비용

사람들은 모델 가격(model pricing)에 집착하느라 행동 비용(behavioral pricing)은 무시합니다.

행동 비용은 다음과 같은 상황에서 발생합니다:

• 4턴(turn)이면 끝날 작업이 40턴이 걸릴 때
• 메모리 집약적인 에이전트(memory-heavy agent)가 오래된 컨텍스트(context)를 계속 끌고 갈 때
• 그래프(graph)가 새로운 정보 없이 동일한 경로를 재시도할 때
• 멀티 에이전트(multi-agent) 간의 잡담이 출력 품질 개선 없이 비용만 발생시킬 때

이러한 숨겨진 비용 때문에 팀들은 끝없는 AI 모델 전환 비용 분석(model switching cost analysis)의 늪에 빠지게 됩니다.

진짜 버그는 '정지 표지판'이 없는 것인데, 그들은 2주 동안 벤더(vendor)를 비교하는 데 시간을 허비합니다.

토큰당 비용을 지불한다면 이 문제는 더욱 중요합니다

전통적인 토큰당 과금(per-token billing) 방식을 사용하고 있다면, 모든 추가 턴은 두 배로 타격을 줍니다:

• 지연 시간(latency)이 증가합니다.
• 비용이 증가합니다.

이것이 바로 에이전트 팀들이 토큰 불안(token anxiety)을 겪게 되는 이유입니다.

워크플로를 개선하는 대신 사용량을 모니터링하기 시작하게 됩니다.

n8n, Make, Zapier, OpenClaw 또는 커스텀 자동화(custom automations)에서 에이전트를 24시간 내내 실행하는 팀들에게 이는 금방 지치는 문제가 됩니다.

고정 비용(flat-cost) 설정은 트레이드오프(tradeoff)를 약간 변화시킵니다. 개별 토큰의 급증에 신경을 덜 쓰는 대신 오케스트레이션(orchestration) 품질에 더 집중할 수 있기 때문입니다.

이것이 에이전트 중심의 워크로드에 Standard Compute가 흥미로운 이유 중 하나입니다. 이는 월정액으로 무제한 컴퓨팅을 제공하는 OpenAI 호환 API(drop-in OpenAI-compatible API)이므로, 비용 대시보드에 매몰되지 않고도 GPT-5.4, Claude Opus 4.6, Grok 4.20과 같은 모델들 사이를 자유롭게 라우팅(route)할 수 있습니다.

그렇다고 해서 좋은 에이전트 설계(agent design)의 필요성이 사라지는 것은 아닙니다.

단지 잘못된 턴 관리(turn discipline)로 인해 문제를 수정하는 동안 거대한 청구서가 날아와 깜짝 놀랄 일은 없다는 뜻입니다.

나의 현재 기본 원칙

에이전트가 이상하게 동작할 때, 나는 모델에 대해 무엇인가를 묻기 전에 먼저 이것을 스스로에게 묻습니다:

왜 계속 말을 하도록 허용했는가?

이 질문 하나가 GPT 대 Claude의 또 다른 논쟁보다 더 많은 버그를 잡아냅니다.

만약 당신의 에이전트가 횡설수설하거나, 작업을 중복하거나, 스스로와 논쟁하고 있다면, 여기서부터 시작하세요:

1. 턴(turns) 제한
2. 명시적인 중단 조건(stop conditions) 추가
3. 핸드오프(handoffs) 감소
...

이것은 화려하지 않습니다.

하지만 더 저렴합니다.

그리고 실제로, 이것이 대개 진짜 해결책입니다.