LangChain Interrupt: 에이전트가 런타임(Runtime)으로 이동하다

올해의 인터럽트(Interrupt)는 다르게 느껴졌습니다.

모델을 숭배하는 태도는 줄어들었고, 런타임(Runtime)에 대한 논의는 늘어났습니다.

또 다른 모델 숭배의 반복 대신, 컨퍼런스에서의 더 유용한 대화들은 더 실용적인 방향으로 흘러갔습니다. 에이전트(Agents)는 워크플로(Workflow)가 처음부터 에이전트 방식(Agentically)으로 구축될 때 가장 잘 작동합니다. 하지만 현실적인 상황을 보면, 많은 기존 기업 프로세스들은 단순히 모델을 감싸고 있을 뿐이며, 버튼을 누르고, 양식을 채우고, 모델의 출력을 다른 필드나 애플리케이션에 복사하여 붙여넣는 식입니다. 이는 데모 단계가 지나면 무너지고 맙니다.

에이전트를 워크플로에 투입하는 더 나은 방법은 처음부터 워크플로를 에이전트 방식으로 구축하는 것입니다. 결정론적(Deterministic)이어야 하는 부분들은 소프트웨어로 둘러싸여야 합니다. 그러면 LLM(Large Language Model)은 판단, 합성(Synthesis), 계획(Planning), 모호성 처리, 우선순위 설정 등을 위해 사용될 수 있습니다. 그리고 하네스(Harness)와 정적 코드(Static code)는 계약(Contracts)이 있는 도구들을 갖추어야 합니다. 하네스와 정적 코드는 상태(State)를 갖추어야 합니다. 하네스와 정적 코드는 에이전트가 실패로부터 복구할 수 있는 방법을 갖추어야 합니다. 그리고 하네스와 정적 코드는 에이전트가 이상한 행동을 할 때 누군가가 실제로 디버깅(Debug)할 수 있도록 에이전트에게 충분한 가시성(Visibility)을 제공해야 합니다.

제가 계속해서 다시 보게 된 릴리스는 LangSmith Engine이었습니다.

이것은 사람들이 시간이 지남에 따라 에이전트를 개선하기 위해 설명하려고 노력해 온 루프(Loop)입니다. 새로운 트레이스 엔진(Trace engine)은 에이전트의 실행 트레이스(Traces of execution)를 모니터링합니다. 실패 사례들을 함께 클러스터링(Cluster)하여 이슈(Issue)로 전환합니다. 하네스의 프로덕션 코드(Production code)를 분석하여 문제의 근본 원인을 진단합니다. 수정을 위한 PR(Pull Request)을 작성합니다. 온라인 평가기(Online evaluators)를 제안합니다. 프로덕션 실행 중 실패한 트레이스를 추가 개선을 위한 오프라인 평가 세트(Offline eval sets)로 이동시킵니다.

프로덕션 동작이 증거(Evidence)가 됩니다. 그 증거는 시스템이 해결해야 할 이슈가 됩니다. 그 수정 사항은 실패가 다시 발생하는지 감시하는 평가기(Evaluator)가 됩니다.

정말 멋진 일입니다.

이것은 관찰성 (Observability)을 변화시킵니다. 애플리케이션 실행의 트레이스 (Trace)를 단순히 애플리케이션 작업의 영수증으로만 보던 기존의 관점은 점차 구식이 되어가고 있습니다. 에이전트 시스템 내의 트레이스는 하네스 튜닝 (Harness tuning), 업데이트된 프롬프트 (Prompts), 추가적인 컨텍스트 (Context), 대안 모델 (Alternative models), 새로운 평가기 (Evaluators)의 생성, 또는 워크플로우 (Workflows)의 수리에 이르기까지, 다음 개선 주기를 위한 새로운 증거의 원천이 되고 있기 때문입니다.

SmithDB에서 보여주듯, 스토리지 (Storage) 측면에서도 유사한 논점이 존재합니다. 에이전트 트레이스는 팀들이 웹 애플리케이션을 통해 추적하는 데 익숙한 트레이스와 근본적으로 다른 형태를 가집니다. 에이전트 시스템에서 트레이스는 이벤트 밀도 (Event density)가 다르며, 개별 스팬 (Span)이 웹 트레이스의 경우보다 실행되는 데 더 오랜 시간이 걸리고, 매우 가변적인 타이밍 특성을 가진 깊고 넓은 스팬 트리 (Span trees)를 형성합니다. 어떤 경우에는 에이전트의 개별 실행에 도구 호출 (Tool calls), 에이전트 실행 중에 검색된 컨텍스트 (Context), 모델 또는 평가기 출력, 실행 중 열거나 작성한 파일, 사용자가 제공한 피드백, 또는 드물게는 전체 연구 프로젝트까지 포함될 수 있습니다.

에이전트 트레이스는 애플리케이션 트레이스와 다릅니다. 애플리케이션 트레이스가 왜 애플리케이션이 느리거나 실패하는지 디버깅하는 것을 돕는다면, 에이전트 트레이스는 에이전트가 왜 처음에 특정 행동을 하기로 결정했는지를 이해하는 데 도움을 줍니다.

그것은 다른 데이터 문제입니다.

동일한 테마가 Deep Agents v0.6에서도 나타납니다. 흥미로운 부분들은 화려하지 않습니다: 코드 인터프리터 (Code interpreter), 프로그래밍 방식의 도구 호출 (Programmatic tool calling), 타입화된 스트리밍 (Typed streaming), DeltaChannel 체크포인트 스토리지 (Checkpoint storage), 그리고 다양한 모델을 위한 하네스 프로필 (Harness profiles)입니다.

이는 Kimi와 같은 저비용 모델이 요약(Summarization), 검색(Search), 추출(Extraction) 등과 같은 일상적인 도구 작업(Tool work)을 처리할 수 있음을 의미합니다. 이러한 유형의 작업에 프런티어 토큰(Frontier tokens)을 낭비해서는 안 됩니다. 반면, 프런티어 모델(Frontier models)은 작업의 더 어려운 추론(Reasoning) 부분을 담당하게 되며, 이때 해당 모델의 한계치가 궁극적인 결정 요인이 됩니다. 따라서 팀은 여기에는 Kimi를, 저기에는 Qwen을, 다른 곳에는 DeepSeek를 사용하고, 실제 작업이 필요할 때만 Opus나 GPT를 예약하여 사용할 수 있습니다.

어떤 기능이 관리형 플랫폼(Managed platform)에 있고 모델이 내장되어 있다고 해서, 모델을 변경하는 것이 비용이 들지 않는다는 뜻은 아닙니다. 모델 변경은 프롬프트(Prompts)와 팀의 프롬프트 작성 방식, 도구 호출(Tool calls) 및 시스템의 프로그래밍 방식에 따른 도구 호출, 타입 지정 스트리밍(Typed streaming), 그리고 DeltaChannel 체크포인팅(Checkpointing)의 동작 방식에 수많은 연쇄 효과(Cascading effects)를 일으킬 수 있습니다. 시스템의 완전히 새로운 부분에서 실패 모드(Failure modes)가 도입되기도 합니다. 또한 비용(Cost)과 지연 시간(Latency)은 완전히 다른 트레이드오프 공간(Trade spaces)을 가집니다. 만약 팀이 에이전트(Agent)를 개선하기 위해 하네스(Harness)나 정적 코드(Static code)를 미세 조정(Tweaking)하고 있다면, 팀은 하네스나 정적 코드의 다양한 미세 조정이 모델의 변화와 어떻게 상관관계가 있는지 알고 싶어 할 것입니다.

이번 컨퍼런스 전반에 걸쳐 반복되는 질문은 이것입니다: 모델에는 무엇을 넣을 것인가, 하네스에는 무엇을 넣을 것인가, 정적 코드에는 무엇을 넣을 것인가, 그리고 런타임(Runtime)에는 무엇을 넣을 것인가?

그렇기에 Managed Deep Agents, Context Hub, 그리고 Sandboxes와 같은 플랫폼들은 이러한 지속 가능한 스레드(Durable threads) 및 기타 중요한 런타임 구조를 관리할 수 있는 방법들을 제공합니다. 파일, 기술(Skills), 하위 에이전트(Subagents), 그리고 버전 관리된 컨텍스트(Versioned context). 안전한 코드 실행(Safe code execution)과 인간 승인 흐름(Human approval flows). 트레이싱(Tracing)과 체크포인트(Checkpoints). 그리고 물론, 시스템과 상호작용하는 사람의 직관(Vibes) 이외의 어딘가에 존재하는 메모리(Memory)까지 말입니다.

MCP는 에이전트(Agents)를 조직 자체의 스택(Stack) 내에 있는 도구(Tools)들과 연결할 것입니다. 이는 에이전트가 다른 에이전트와 상호작용하는 A2A(Agent-to-Agent)와는 다릅니다. 이들 중 일부는 사용자 에이전트(User agents)가 될 것이고, 다른 일부는 고유한 권한(Permissions), 예산(Budgets), 정책 경계(Policy boundaries), 그리고 감사 추적(Audit trails)을 가진 디지털 직원(Digital employees)이 될 것입니다. 이는 현재의 방식과는 다른 인증 모델(Auth models)을 필요로 할 것이며, 많은 경우 기존의 에이전트들은 현재 형태로는 본질적으로 쓸모가 없거나, 더 나쁘게는 무서울 정도로 강력하기까지 합니다.

LLM Gateway의 경우: 지출 한도(Spend limits), 개인정보(PII) 삭제(Redaction), 정책 이벤트 추적(지출 한도가 설정되었는지, 그 값은 무엇인지, 누가 업데이트했는지 등), 추적 연속성(Trace continuity, 즉 추적이 외부 도구로 전송된 후에도 원래의 추적과 외부 도구에서 생성된 추적을 동일한 뷰에서 함께 볼 수 있는 기능), 그리고 궁극적으로 MCP와 동일한 유형의 외부 도구 제어 기능, 즉 도구 게이트웨이 제어(Tool gateway controls)가 필요합니다.

Interrupt를 통해 얻은 저의 결론은 에이전트 대화(Agent conversation)가 더욱 정직해지고 있다는 것입니다.

물론, 이것이 어려운 부분입니다. LLM을 판단을 내릴 적절한 위치에 배치하고, 추적 가능성(Traceability), 제한(Limits), 평가(Eval), 그리고 개선(Improvement)을 가능하게 하는 코드로 LLM을 둘러싸는 일 말입니다.

그것이 바로 Interrupt가 중요하게 느껴지게 만든 지점입니다.

생태계는 LLM 기반 에이전트가 마법 같은 직원이 아니라, 실제 소프트웨어 시스템 내에서 런타임 참여자(Runtime participants)로서 움직이는 방향으로 나아가고 있습니다.

좋습니다. 바로 그곳에 우리가 해야 할 일이 있습니다.