에이전트 프레임워크와 에이전트 관측 가능성에 대하여

LLM(Large Language Models)이 발전할 때마다 똑같은 질문이 돌아옵니다: "여전히 에이전트 프레임워크가 필요한가요?" 이는 타당한 질문입니다. 모델의 성능이 향상되고 진화함에 따라 에이전트를 구축하는 최선의 방법은 변하지만, 근본적으로 에이전트는 모델 '주변'의 시스템이므로 사라지지 않을 것입니다. 다만 에이전트 또한 진화해야 할 뿐입니다. 우리는 현재 세 세대의 에이전트 프레임워크를 구축해 왔으며, 각 세대는 이전 세대와 다른 모습을 보였습니다. 그래서 우리는 다음과 같이 믿고 있습니다:

• 에이전트 프레임워크는 여전히 유용하지만, 모델만큼 빠르게 진화할 때만 그렇습니다.
• 에이전트 관측 가능성(Agent observability)은 어떤 방식으로 구축하든 상관없이 작동해야 합니다. 이것이 우리가 제공하는 오픈 소스(LangChain 또는 LangGraph)를 사용하지 않더라도 LangSmith가 작동하는 이유입니다.

이 포스트는 이 두 가지 가설에 관한 것입니다.

2026년에도 에이전트 프레임워크가 여전히 유효한 이유

에이전트 패턴은 체이닝(Chaining)에서 워크플로 오케스트레이션(Workflow orchestration)을 거쳐, 파일 시스템 및 메모리를 활용한 루프 내 도구 호출(Tool-calling-in-a-loop)로 이동했습니다. 우리는 이 모든 패턴을 위한 프레임워크를 구축해 왔으며, 각 패턴이 사용 사례에 따라 제 자리가 있다고 믿습니다. 그 진화 과정은 다음과 같습니다:

체이닝 (Chaining)

초기 langchain은 2023년에 큰 인기를 끌었는데, 당시에는 LLM을 실질적으로 활용하는 방법을 아는 사람이 거의 없었기 때문입니다. 이 프레임워크는 일련의 통합(Integrations)과 핵심 추상화(Core abstractions)를 통해 파운데이션 모델(Foundation models)을 데이터나 API에 연결하는 가장 쉬운 방법 중 하나를 제공했습니다. 시작 단계에서는 다소 독단적(Opinionated)이었을 수도 있습니다. 즉, 프로덕션(Production)에 바로 투입할 수 있는 도구라기보다는 프롬프팅(Prompting)과 RAG(Retrieval-Augmented Generation)를 배우기 위한 "이지 버튼(Easy button)"에 더 가까웠습니다. 그해 여름 생성형 AI의 첫 번째 물결이 안정되기 시작하면서, 에이전트 프레임워크가 무용지물이라는 비판의 목소리가 커졌습니다.

우리는 그 비판을 들었지만, 실제 사용 사례에서 목격하고 있는 현상과 조화시키기는 어려웠습니다. LLM 앱을 구축하는 대다수의 팀은 완전히 혼자서 진행하는 것보다 더 빠르게 움직일 수 있는 방법이 필요했습니다. 좋은 프레임워크는 다음과 같은 역할을 합니다:

• 프레임워크 자체에 베스트 프랙티스(Best practices)를 인코딩함
• 보일러플레이트 코드(Boilerplate code)를 줄임
• 더 높은 수준의 품질에 도달하는 것을 더 쉽게 만듦
• 대규모 팀 전체에 걸쳐 표준과 가독성을 생성함
• 프로덕션으로 가는 더 깔끔한 경로를 마련함

그래서 우리는 다른 프레임워크에 집중했습니다.

오케스트레이션 (Orchestration) 및 런타임 (run-time)

langgraph는 더 낮은 수준(lower level)이면서 더 유연했습니다. 여기에는 내구성(durability)과 상태 유지(statefulness)를 지원하는 런타임(runtime)이 포함되어 있었는데, 이는 인간-에이전트(human-agent) 및 에이전트-에이전트(agent-agent) 협업에 있어 중요한 것으로 밝혀졌습니다. 또한 langchain에 대해 사람들이 제기했던 많은 제어 관련 우려 사항들을 해결했습니다. 우리는 결국 2025년에 기존의 langchain을 더 간소화하여 다시 작성했지만, 서로 다른 문제에는 서로 다른 도구가 필요하다는 점 또한 인식했습니다.

하네스 (Harness)

보다 최근에는 더 높은 성능과 유연성을 갖춘, 모든 기능이 포함된(batteries-included) 에이전트 하네스(agent harness)인 deepagents를 구축했습니다. 이는 장기적 과제(long-horizon tasks)를 위한 계획 수립, 루프 내 도구 호출(tool-calling-in-a-loop), 파일 시스템으로의 컨텍스트 오프로딩(context offloading), 그리고 하위 에이전트 오케스트레이션(subagent orchestration)을 지원합니다. 에이전트 하네스가 현재 작동할 수 있는 이유는 LLM의 추론(reasoning) 능력이 향상되고 있으며, 많은 오케스트레이션 패턴을 하드 코딩(hard coding)하는 대신 더 많은 결정을 LLM에 위임할 수 있기 때문입니다. 개념적으로는 Claude Agent SDK와 가장 유사하지만, 모델 불가지론적(model-agnostic)입니다. 저희가 알기로는, 특정 LLM이나 애플리케이션 스택에 종속되지 않은 유일한 에이전트 하네스입니다.

오늘날 우리는 다양한 사용 사례에 따라 이러한 서로 다른 프레임워크들을 권장합니다. langchain과 deepagents는 장기 실행(long running execution)을 위해 langgraph의 런타임을 기반으로 구축되었습니다.

극적으로 들리겠지만, 우리는 3년 동안 세 세대의 에이전트를 목격했습니다. RAG로 시작된 것이 에이전트 워크플로(agentic workflows)가 되었고, 이는 다시 더 자율적인 루프 내 도구 호출(tool-calling-in-a-loop) 에이전트로 진화했습니다.

프레임워크에 대한 가장 큰 비판은 AI 분야가 너무 빠르게 진화하여 표준이 형성되기 어렵다는 점입니다. 그 말에는 일리가 있습니다. 하지만 우리는 상황이 안정되기를 기다리며 AI 게임에서 빠져 있는 것이 패배하는 전략이라고 믿습니다. 프레임워크는 여러분이 뛰어들고, 더 빠르게 구축하며, 성공 확률을 높일 수 있도록 도와줍니다. 이를 알고 있더라도 도구는 계속해서 변할 것입니다. 또한 모든 것에 프레임워크가 필요한 것은 아닙니다. 단순한 LLM 요청이라면, 프레임워크를 추가하는 것이 너무 과할(heavy handed) 수 있습니다.

LangSmith가 LangChain 오픈 소스와 독립적인 이유

초기에 우리는 품질이 에이전트(Agent)를 실제 서비스(Production)에 도입하는 데 있어 가장 큰 장벽이라는 점을 인식했습니다. 우리는 에이전트 관측 가능성(Observability)과 평가(Evals)를 위해 특화된 도구가 툴킷의 필수적인 부분이라고 믿었으며, 지금도 그렇게 믿고 있습니다.

우리는 이를 LangSmith라고 불렀는데, 이는 에이전트 프레임워크가 단 하나만 존재하지는 않을 것이라는 직관이 있었기 때문입니다. 설령 지배적인 프레임워크가 하나 있더라도, 초기 버전과는 알아볼 수 없을 정도로 빠르게 진화할 것이라고 생각했습니다. 우리는 모든 사람이 우리의 프레임워크를 사용하지는 않겠지만, 그럼에도 이 플랫폼을 사용할 수 있기를 원했습니다.

따라서 우리는 사용자가 langchain을 사용하든, 우리의 다른 프레임워크를 사용하든, 혹은 아무것도 사용하지 않든 상관없이 작동하도록 LangSmith를 구축했습니다. 당시에는 이것이 당연한 결정은 아니었습니다. 우리는 자체적인 Next.js 외에도 많은 프론트엔드 프레임워크를 지원하는 Vercel과 같은 기업들로부터 영감을 얻었습니다.

오늘날 LangSmith는 AutoGen, Claude Agent SDK, CrewAI, Mastra, OpenAI Agents, PydanticAI, Vercel AI SDK 등 다양한 프레임워크와 즉시(out of the box) 통합됩니다. 또한 OpenTelemetry 기반의 트레이싱(Tracing)을 지원하므로, OTEL 사양을 방출하는 모든 것은 LangSmith에 의해 수집될 수 있습니다. 그리고 프레임워크를 전혀 사용하지 않고 구축된 에이전트와도 작동합니다. Clay, Harvey, Vanta를 포함한 많은 LangSmith 고객들은 우리의 오픈 소스 프레임워크를 사용하지 않지만, 관측 가능성과 평가를 위해 LangSmith에 의존하고 있습니다.

에이전트 엔지니어링에서 구축과 테스트의 수렴

사용 중인 에이전트 프레임워크와 관계없이, 트레이스(Traces)는 에이전트의 동작을 이해하는 데 매우 중요합니다. 우리는 에이전트 트레이스가 에이전트 디버깅(Debugging), 모니터링(Monitoring), 평가(Evals) 등의 기초가 되기 때문에 얼마나 중요한지에 대해 계속해서 글을 써왔습니다. 에이전트의 경우, 앱 로직은 코드가 아닌 트레이스에 기록됩니다. 에이전트를 구축하는 것은 첫 번째 단계일 뿐입니다. 에이전트는 비결정론적(Non-deterministic) 시스템이므로, 제품을 출시하기 전까지는 어떤 입력이나 출력을 기대할 수 있는지 알 수 없습니다. 이것이 바로 디버깅, 테스트, 모니터링이 에이전트 엔지니어링과 구축 과정 그 자체에서 매우 중요한 부분인 이유입니다.

따라서 만약 여러분이 우리의 오픈 소스 (OSS) 프레임워크를 사용하지 않고 있다면, 그 이유를 저희에게 알려주세요! 하지만 그것이 LangSmith를 통해 여러분의 에이전트가 왜, 그리고 어떻게 실패하고 있는지 파악하는 과정을 멈추게 해서는 안 됩니다.