“체인(chain)이 에이전트를 만든다”는 말이 2년 전엔 맞았습니다.

지금은 틀렸습니다.

LangChain 창업자 Harrison Chase(@hwchase17)가 LangSmith를 다시 정의했습니다. 단순 체인 로깅 도구에서 에이전트 실행 인프라 플랫폼으로. 샌드박스·배포·트레이싱·반복 개선을 묶어 하나의 제품으로 만들었습니다. 같은 시기, context-mode MCP 서버는 에이전트 컨텍스트 비용을 98% 줄이는 오픈소스를 50일 연속 업데이트했고, deepagents는 GitHub에서 25,000 stars를 넘었습니다.

이 세 신호가 같은 방향을 가리킵니다. 에이전트 경쟁의 전선이 체인 설계에서 실행 인프라로 이동했다는 신호입니다.

체인은 로직이고, 실행은 다른 층이다

에이전트를 처음 만들 때 보통 이 순서를 거칩니다.

  1. 프롬프트 설계
  2. 체인 구조 설계 (어떤 도구를 언제 호출할 것인가)
  3. 배포 및 운영

그런데 실제 프로덕션에서 실패하는 지점은 거의 항상 3번입니다. 체인은 로컬에서 잘 돌아갑니다. 배포하면 달라집니다.

deepagents가 오픈소스로 공개한 구조를 보면 명확합니다:

# deepagents — 실행 인프라가 어떻게 에이전트를 감싸는가
agent = create_agent(
    model="claude-opus-4-8",
    tools=[web_search, code_interpreter],
    sandbox=DockerSandbox(),        # 격리 실행
    tracer=LangSmithTracer(),       # 트레이싱
    memory=FileMemory("./state/")   # 지속 상태
)

세 줄이 핵심입니다. sandbox, tracer, memory. 체인 로직이 아닙니다. 실행 인프라입니다.

이 구조가 25,000 stars를 받은 이유는 기능이 많아서가 아닙니다. 에이전트를 프로덕션에 올릴 때 실제로 부딪히는 문제를 정면으로 다루기 때문입니다.

컨텍스트 비용이 새 경쟁 축이 된 이유

실행 인프라 경쟁이 뜨거워진 배경에는 비용 압력이 있습니다.

에이전트는 멀티스텝으로 실행됩니다. 각 스텝마다 컨텍스트를 전달합니다. 컨텍스트가 커질수록 토큰 비용이 폭발적으로 늘어납니다. context-mode MCP가 98% 절감에 성공한 이유는 프롬프트를 잘 짜서가 아닙니다. 컨텍스트 전달 구조 자체를 재설계했기 때문입니다.

숫자로 보면 이렇습니다. 에이전트가 10스텝을 실행할 때, 매 스텝마다 전체 컨텍스트를 그대로 넘기면 비용이 선형으로 쌓입니다. 하지만 구조화된 컨텍스트 압축을 적용하면 실제 필요한 정보만 전달하므로 비용이 1/10 이하로 줄어들 수 있습니다.

이것이 LangSmith가 “컨텍스트 경제(context economy)“를 전면에 내세우는 배경입니다. 체인이 얼마나 잘 설계됐느냐보다, 각 실행 스텝이 얼마나 효율적으로 컨텍스트를 관리하느냐가 제품 경쟁력을 결정하게 됐습니다.

PM이 지금 투자해야 할 세 가지

에이전트 제품을 만들고 있다면, 체인 로직 최적화보다 앞서 결정해야 할 것들이 있습니다.

첫째, 샌드박스: 에이전트가 무엇을 어디서 실행하는가

격리되지 않은 에이전트는 프로덕션에 올라갈 수 없습니다. Docker 기반 샌드박스, 클라우드 함수(Lambda/Cloud Run), WebAssembly 기반 격리 중 무엇을 쓸 것인지가 비용 구조와 보안 경계를 함께 결정합니다. 이 결정을 체인 설계보다 나중에 하는 팀이 많은데, 순서가 거꾸로입니다.

둘째, 트레이싱: 실패를 어디서 볼 것인가

에이전트가 프로덕션에서 실패할 때, “어느 스텝에서 왜 실패했는가”를 알 수 없으면 개선이 불가능합니다. OpenAI의 세무 에이전트 팀이 6주 만에 정확도 25%→86%에 도달한 핵심은 eval 루프 설계였습니다. 그리고 eval 루프의 전제는 트레이싱입니다. 트레이싱 없는 에이전트는 블랙박스이고, 블랙박스는 개선할 수 없습니다.

셋째, 반복 개선 파이프라인: 실패가 어떻게 학습으로 돌아오는가

hwchase17의 Alpha Eval 패턴이 이것을 명시적으로 정의했습니다. “에이전트가 다른 에이전트를 위한 평가 지표를 만든다. 프로덕션 실행 로그가 다음 이터레이션의 학습 데이터가 된다.” 체인을 개선하는 것이 아니라, 실행 데이터를 피드백 루프로 연결하는 구조가 에이전트 제품의 지속 경쟁력입니다.

설계 순서를 바꿔야 한다

에이전트 제품을 처음 설계할 때 권하는 질문 순서입니다:

  1. 어느 환경에서 안전하게 실행할 것인가? (샌드박스)
  2. 어떻게 추적하고 관찰할 것인가? (트레이싱·관측성)
  3. 실패 케이스를 어떻게 자동으로 수집해 개선에 돌릴 것인가? (eval 파이프라인)
  4. 그다음에야 — 어떤 체인 구조로 작업을 분해할 것인가?

hwchase17이 LangSmith로 이 순서를 제품으로 정의했습니다. 체인은 에이전트의 로직입니다. 실행 인프라는 에이전트의 운영입니다. 지금 경쟁은 로직이 아니라 운영에서 납니다.

Lyft가 LangGraph + LangSmith로 고객지원 자기서브 플랫폼을 만든 사례, 데이터독이 Bits AI로 보안 에이전트를 98% MTTR 개선한 사례, AWS가 오케스트레이션을 기본 탑재한 에이전트 플랫폼을 강화한 방향 — 전부 같은 결론입니다. 승부는 체인 레이어가 아니라 실행 레이어에서 나고 있습니다.

당신의 에이전트 시스템에서 실행 인프라가 가장 취약한 레이어는 어디입니까?