Claude 에이전트 워크플로우에 실행 시간 제한(Runtime Limits) 추가하기

자율 워크플로우(autonomous workflows)가 프로덕션 환경에서 불안정해지는 가장 빠른 방법 중 하나는 모델의 품질 때문이 아닙니다.

바로 제약 없는 실행(unconstrained execution) 때문입니다.

Claude 기반의 워크플로우는 정상적으로 시작됩니다:

• 컨텍스트 검색 (retrieve context)
• 도구 호출 (call tools)
• 추론 (reason)
• 재시도 (retry)

그러다 갑자기:

• 재시도가 누적되고
• 컨텍스트가 확장되며
• 도구 사용이 급증하고
• 지연 시간(latency)이 치솟으며
• 실행이 무한히 표류합니다.

기술적으로 워크플로우는 "살아있는" 상태로 유지됩니다.

운영 측면에서는:
이미 오래전에 의미 있는 진전을 멈춘 상태입니다.

이 글에서는 TypeScript를 사용하여 Claude 에이전트 워크플로우에 실행 시간 제한(runtime limits)을 추가하는 간단한 방법을 소개합니다.

복잡한 오케스트레이션(orchestration)은 필요하지 않습니다.

실행 시간 제한이 중요한 이유

대부분의 AI 워크플로우는 대부분의 시간 동안 정상적으로 동작합니다.

문제는 다음과 같은 예외 케이스(edge cases)에서 발생합니다:

• 재귀적 재시도 (recursive retries)
• 폭주하는 도구 체인 (runaway tool chains)
• 불안정한 복구 동작 (unstable recovery behavior)
• 수렴하지 않는 추론 루프 (non-converging reasoning loops)
• 급증하는 컨텍스트 윈도우 (escalating context windows)

불안정한 실행의 아주 작은 비율만으로도 다음과 같은 자원을 불균형적으로 소비할 수 있습니다:

• 추론 비용 (inference cost)
• 지연 시간 (latency)
• 컴퓨팅 자원 (compute)
• 운영 주의력 (operational attention)

특히 다음과 같은 경우에 더욱 그렇습니다:

• 자율 워크플로우 (autonomous workflows)
• 장기 실행 에이전트 (long-running agents)
• 다단계 오케스트레이션 시스템 (multi-step orchestration systems)

이것이 바로 실행 시간 제한(runtime limits)이 중요해지는 지점입니다.

목표

우리는 다음과 같은 가벼운 운영 경계(operational boundaries)를 원합니다:

{
maxRuntimeMs: 30000,
maxSteps: 15,
maxToolCalls: 10
}

실행이 이러한 경계를 초과하면:

...

bounded execution for autonomous systems

1단계 — 실행 상태(Runtime State) 추적하기

...

초기화하기:

const state: ExecutionState = {
  startedAt: Date.now(),
  steps: 0,
...

2단계 — 실행 시간 제한 정의하기

이제 간단한 운영 제약 조건(operational constraints)을 정의합니다:

const LIMITS = {  
maxRuntimeMs: 30_000,  
maxSteps: 15,  
maxToolCalls: 10  
};

이 값들이 처음부터 완벽할 필요는 없습니다.

...

실행이 제한됩니다 (execution becomes bounded)

3단계 — 실행 가드(Runtime Guard) 생성하기

...

이것이 여러분의 다음과 같은 역할을 하게 됩니다:

실행 거버넌스 계층 (runtime governance layer).

---

4단계 — 워크플로우 실행 래핑(Wrap Workflow Execution)

이제 실행 중에 제한 사항을 강제합니다:

while (true) {
  enforceRuntimeLimits(state);

...

이것으로 끝입니다.

이제 여러분의 워크플로우에는 다음이 갖춰졌습니다:

• 제한된 실행 시간 (bounded runtime)
• 제한된 실행 깊이 (bounded execution depth)
• 제한된 도구 사용 (bounded tool usage)

단순한 제한이 놀라울 정도로 잘 작동하는 이유

많은 팀이 처음에는 다음과 같은 것들이 필요하다고 가정합니다:

• 고급 이상 탐지 (advanced anomaly detection)
• 강화학습 (reinforcement learning)
• 정교한 텔레메트리 파이프라인 (sophisticated telemetry pipelines)

하지만 단순한 운영 제약 조건 (operational constraints)만으로도 이미 많은 비용이 발생하는 실패 모드들을 제거할 수 있습니다.

특히 다음과 같은 경우들입니다:

• 재시도 폭풍 (retry storms)
• 재귀 루프 (recursive loops)
• 불안정한 도구 변동 (unstable tool churn)
• 수렴하지 않는 실행 (non-converging execution)

처음부터 완벽한 지능이 필요한 것은 아닙니다.

여러분에게 필요한 것은 다음과 같습니다:

운영 경계 (operational boundaries).

프로덕션 개선 사항

위의 최소한의 예시는 놀라울 정도로 잘 작동하지만, 프로덕션 시스템에서는 보통 다음과 같은 것들을 추가합니다:

• 토큰 속도 모니터링 (token velocity monitoring)
• 재귀 탐지 (recursion detection)
• 의미론적 재시도 분석 (semantic retry analysis)
• 적응형 임계값 (adaptive thresholds)
• 테넌트별 예산 (tenant-specific budgets)
• 에스컬레이션 정책 (escalation policies)
• 실행 트레이싱 (execution tracing)

예를 들어:

search  
→ retry  
→ search  
→ retry  
→ retry

은 다음과 같은 경우보다 운영 측면에서 종종 더 위험합니다:

search
→ summarize
→ respond

두 경우 모두 기술적으로는 "작동"하더라도 말입니다.

...

실행 거버넌스 (Runtime governance)는 다음 질문에 답합니다:

“무엇이 계속 일어나도록 허용되어야 하는가?”

이 구분은 엄청나게 중요합니다.

제어되지 않는 실행(runaway execution)이 대시보드에 나타날 때쯤에는 이미 다음과 같은 상황이 벌어졌을 수 있기 때문입니다:

• 컴퓨팅 자원이 이미 소진되었을 수 있음
• 지연 시간(latency)으로 인해 이미 사용자 경험(UX)이 저하되었을 수 있음
• 재시도가 이미 연쇄적으로 발생했을 수 있음

개입이 없는 가시성(visibility)은 결국 불완전해질 뿐입니다.

마치며

현재의 AI 생태계는 다음 사항들에 크게 집중하고 있습니다:

• 더 똑똑한 모델 (smarter models)
• 더 큰 컨텍스트 윈도우 (larger context windows)
• 더 나은 추론 (better reasoning)
• 더 자율적인 에이전트 (more autonomous agents)

하지만 장기적인 프로덕션 시스템 (production systems)은 다음과 같은 요소들에도 똑같이 의존하게 될 것입니다:

• 제한된 실행 (bounded execution)
• 실행 시간 거버넌스 (runtime governance)
• 운영 예측 가능성 (operational predictability)
• 제약된 실패 동작 (constrained failure behavior)

결국:
자율적인 워크플로우 (autonomous workflows)를 구축하는 것 자체가 과제는 아니기 때문입니다.

진정한 과제는 통제 가능한 (governable) 자율적 워크플로우를 구축하는 것입니다.