AI 에이전트 오케스트레이션의 현실

: “상시 대기”와 “고품질 세션”은 분리해야 한다.

Anthropic이 4월 4일부터 클로드 기본 구독 요금제에서 오픈클로와 같은 서드파티 툴의 연동 지원을 중단하겠다고 발표했다.

그동안 오픈클로에 클로드로 대부분의 작업을 해오던 나에게는 청천 벽력같은 이야기였다.

그래서 무작정 Claude Code를 오케스트레이션 플랫폼으로 써서 Openclaw와 연결하고 나머지 기존 에이전트 구조를 Openclaw 아래로 내려서 운영해 보려고 했다.

텔레그램 메시지를 폴링하고, 자동 응답하고, 상시 대기하는 구조.

결론부터 말하면 — 잘못된 방향이었다.

 

부딪힌 벽.

Claude Code는 CLI 세션 기반 도구다. 세션을 열어야 동작하고, 닫으면 끝난다. 상시 대기형 서버가 아니다.

처음부터 이 부분을 생각하고 Claude Channel 이 왜 아직 실험실에 있는 지를 생각했어야 했다.

무작정 설치하고 셋팅을 이어가는데 계속 실패로 이어졌다. 분명 텔레그램에서 메시지가 넘어가는 것 같은데,

실제로는 전혀 넘어가지 못하고 있었다 (아니 실제로 도착했지만 클로드는 자동으로 인식할 수 없었다.)

텔레그램과의 연동 실패. 결국 우회해서 새로운 인바운드 메시지를 /루프 폴링하는 구조로 설계를 했다. (RefreshTime: 60s)

길다면 길고 짧다면 짧은…

하지만 Claude와 억지로 대화하면서 결국 느끼게 된 건 비효율적이라는 것.

Anthropic에서 텔레그램을 사용할 수 있도록 뭔가 구조적인 업데이트를 해주지 않는 한(channel 이 나오지 않는 한)

현재의 구조로는 한계가 명확했다.

그래서 처음부터 다시 설계를 고민했다.

  • 메시지가 없어도 폴링마다 토큰 소모
  • 세션이 길어지면 컨텍스트 압축 반복 → 응답 품질 저하
  • 세션 끊기면 수신 중단 — 안정성 제로
  • 이 모든 비용을 감수하고 얻는 것? 없다

구조적 해법: 역할 분리

결국 도달한 결론은 단순했다. “상시 대기”와 “고품질 처리”는 다른 엔진이 맡아야 한다.

역할 담당 이유
텔레그램 상시 수신/자동응답 GPT 기반 에이전트 (OpenClaw) 서버형, 저비용, 항상 켜져 있음
코드 작업/복잡한 분석 Claude Code 세션형, 고품질, 필요할 때만

에스컬레이션 브릿지

두 시스템을 잇는 것은 파일 기반 비동기 브릿지다. API 호출이 아니다.

[텔레그램 유저]
     ↓
[OpenClaw/GPT] — 직접 처리 가능 → 즉시 응답
     │
     └─ 에스컬레이션 필요
          → escalation/pending/ 에 JSON 파일 생성
               ↓
          [로컬 poll watcher]
               ↓
          [Claude Code 세션 자동 실행]
               ↓
          escalation/done/ 에 결과 작성
               ↓
          [OpenClaw] → 텔레그램 응답

핵심은 OpenClaw이 Claude를 “호출”하는 게 아니라, 파일시스템에 요청을 “놓는” 것이다.

Claude Code는 독립된 플랫폼으로서 자기 세션에서 자기가 읽는다. 주체가 다르니까 3자 harness 제약에도 걸리지 않는다.

에스컬레이션 판단 기준

모든 메시지가 Claude에 갈 필요는 없다. 판단 기준:

  • 에스컬레이션 대상: 코드 수정/생성, 로컬 파일시스템 접근, 복잡한 멀티스텝 분석, 사용자의 명시적 지시
  • 직접 처리: 단순 대화, 정보 조회, 리포트 전달, 일정 관리

배운 것

AI 에이전트를 운영 환경에 넣으려면, 각 모델의 동작 모드를 이해해야 한다.

세션형 도구에 서버 역할을 시키면 비용과 품질 모두 잃는다.

역할을 분리하고, 비동기 브릿지로 연결하는 것이 — 화려하진 않지만 — 실제로 작동하는 구조다.

현재 이 구조를 OpenClaw + Claude Code 환경에서 실 운영해보고 나중에 다시 피드백을 해야 겠다.

 

작성 모델: 없음 / KK 직접 작성