🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

LLM이 발전해도 에이전트는 모델을 둘러싼 시스템이기 때문에 사라지지 않으며, 프레임워크와 관측성 도구는 모델 변화 속도에 맞춰 함께 진화해야 한다.

📌 핵심 요약

• 글은 LLM 성능이 좋아질 때마다 “에이전트 프레임워크가 여전히 필요한가”라는 질문이 반복되지만, 에이전트는 모델 자체가 아니라 모델 주변의 시스템이므로 프레임워크의 역할도 계속 남는다고 주장한다.
• 저자들은 지난 3년 동안 체이닝, 오케스트레이션과 런타임, 도구 호출 루프와 파일시스템·메모리를 갖춘 에이전트 하네스라는 세 세대의 프레임워크를 만들었고, 각 방식은 문제 유형에 따라 여전히 쓸모가 있다고 설명한다.
• 초기 LangChain은 LLM을 데이터와 API에 연결하는 쉬운 방법을 제공했지만 지나치게 의견이 강한 학습용 ‘쉬운 버튼’에 가까웠고, 이후 LangGraph는 더 낮은 수준의 유연성과 내구성·상태성을 갖춘 런타임으로 제어 문제를 보완했다.
• 최근의 deepagents는 장기 작업 계획, 반복적 도구 호출, 파일시스템을 통한 컨텍스트 오프로딩, 서브에이전트 오케스트레이션을 지원하는 모델 비종속 에이전트 하네스로 제시되며, 더 강해진 LLM에 더 많은 판단을 위임할 수 있다는 변화에 맞춰 등장했다.
• LangSmith는 특정 오픈소스 프레임워크 사용 여부와 관계없이 에이전트 관측성과 평가를 제공하도록 설계되었으며, 트레이스가 에이전트 디버깅·모니터링·평가의 기반이 된다는 점을 강조한다.

🧩 주요 포인트

1. 글은 LLM 성능이 좋아질 때마다 “에이전트 프레임워크가 여전히 필요한가”라는 질문이 반복되지만, 에이전트는 모델 자체가 아니라 모델 주변의 시스템이므로 프레임워크의 역할도 계속 남는다고 주장한다.
2. 저자들은 지난 3년 동안 체이닝, 오케스트레이션과 런타임, 도구 호출 루프와 파일시스템·메모리를 갖춘 에이전트 하네스라는 세 세대의 프레임워크를 만들었고, 각 방식은 문제 유형에 따라 여전히 쓸모가 있다고 설명한다.
3. 초기 LangChain은 LLM을 데이터와 API에 연결하는 쉬운 방법을 제공했지만 지나치게 의견이 강한 학습용 ‘쉬운 버튼’에 가까웠고, 이후 LangGraph는 더 낮은 수준의 유연성과 내구성·상태성을 갖춘 런타임으로 제어 문제를 보완했다.
4. 최근의 deepagents는 장기 작업 계획, 반복적 도구 호출, 파일시스템을 통한 컨텍스트 오프로딩, 서브에이전트 오케스트레이션을 지원하는 모델 비종속 에이전트 하네스로 제시되며, 더 강해진 LLM에 더 많은 판단을 위임할 수 있다는 변화에 맞춰 등장했다.
5. LangSmith는 특정 오픈소스 프레임워크 사용 여부와 관계없이 에이전트 관측성과 평가를 제공하도록 설계되었으며, 트레이스가 에이전트 디버깅·모니터링·평가의 기반이 된다는 점을 강조한다.

🧠 상세 정리

1. LLM이 발전할수록 되살아나는 프레임워크 논쟁

글은 LLM 성능이 좋아질 때마다 “에이전트 프레임워크가 아직 필요한가”라는 질문이 다시 등장한다고 말한다. 저자들은 이 질문이 타당하다고 인정하면서도, 에이전트는 단순히 모델 하나가 아니라 모델을 둘러싼 시스템이라는 점을 핵심 전제로 둔다. 모델이 더 좋아질수록 에이전트를 만드는 최선의 방식은 바뀌지만, 시스템으로서의 에이전트가 사라지는 것은 아니라는 주장이다. 따라서 프레임워크도 고정된 형태로 남는 것이 아니라 모델 발전 속도에 맞춰 함께 변해야 한다. 글 전체는 에이전트 프레임워크의 지속적 필요성과, 프레임워크와 독립적으로 작동해야 하는 관측성이라는 두 가지 판단을 중심으로 전개된다.

2. 초기 체이닝 프레임워크와 LangChain의 역할

저자들은 에이전트 패턴이 체이닝에서 워크플로 오케스트레이션으로, 다시 파일시스템과 메모리를 갖춘 도구 호출 루프 방식으로 이동해 왔다고 설명한다. 2023년에 초기 LangChain이 인기를 얻은 이유는 당시 많은 사람이 LLM을 실제 애플리케이션에 어떻게 활용해야 할지 잘 몰랐기 때문이다. LangChain은 통합 기능과 핵심 추상화를 통해 기반 모델을 데이터나 API에 연결하는 쉬운 방법을 제공했다. 다만 글은 초기 LangChain이 지나치게 의견이 강했고, 프로덕션 도구라기보다 프롬프팅과 RAG를 배우기 위한 ‘쉬운 버튼’에 가까웠다고 평가한다. 그럼에도 많은 팀은 완전히 혼자 구축하는 것보다 더 빠르게 LLM 앱을 만들 방법이 필요했고, 프레임워크는 모범 사례, 보일러플레이트 감소, 품질 향상, 팀 내 표준화, 프로덕션으로 가는 경로를 제공했다.

3. LangGraph와 런타임 중심의 오케스트레이션

초기 프레임워크에 대한 비판이 커졌지만, 저자들은 실제 사용 현장에서 프레임워크의 필요성을 계속 확인했다고 말한다. 이에 따라 단순히 기존 방식을 고집하기보다 다른 종류의 프레임워크에 집중했고, 그 결과 LangGraph가 등장했다. LangGraph는 더 낮은 수준의 도구이면서 유연성을 높였고, 내구성과 상태성을 지원하는 런타임을 포함했다. 이러한 특성은 인간과 에이전트의 협업, 에이전트와 에이전트의 협업에서 중요하게 작용했다고 설명된다. 또한 LangGraph는 LangChain에 대해 제기됐던 제어 가능성 문제를 상당 부분 다루기 위한 방향이었다. 저자들은 2025년에 원래의 LangChain도 더 간결하게 다시 작성했지만, 동시에 서로 다른 문제에는 서로 다른 도구가 필요하다는 점을 인정한다고 밝힌다.

4. 도구 호출 루프와 에이전트 하네스의 부상

글은 최근의 프레임워크 세대로 deepagents를 소개하며, 이를 배터리가 포함된 에이전트 하네스라고 설명한다. deepagents는 장기 과제를 위한 계획 수립, 반복적인 도구 호출, 파일시스템을 활용한 컨텍스트 오프로딩, 서브에이전트 오케스트레이션을 지원한다. 이런 에이전트 하네스가 지금 유효해진 이유는 LLM의 추론 능력이 좋아지면서 과거처럼 많은 오케스트레이션 패턴을 코드로 직접 고정하지 않아도 되기 때문이다. 더 많은 결정을 LLM에 위임할 수 있게 되었고, 그에 맞춰 프레임워크의 역할도 세밀한 절차 제어에서 에이전트 실행을 받쳐주는 구조로 이동한다. 저자들은 deepagents가 Claude Agent SDK와 개념적으로 가장 비슷하지만 특정 모델이나 애플리케이션 스택에 묶이지 않는 모델 비종속 하네스라고 강조한다.

5. 빠르게 변하는 AI 환경에서 프레임워크가 갖는 의미

저자들은 3년 동안 RAG에서 에이전틱 워크플로, 더 자율적인 도구 호출 루프 에이전트로 이어지는 세 세대의 변화를 보았다고 정리한다. 프레임워크에 대한 가장 큰 비판은 AI 분야가 너무 빠르게 변해 표준이 형성되기 어렵다는 점인데, 글은 여기에 일정 부분 진실이 있다고 인정한다. 하지만 변화가 빠르다는 이유로 AI 활용을 미루고 상황이 안정되기만 기다리는 것은 실패 전략이라고 본다. 프레임워크는 개발자가 더 빨리 뛰어들고, 더 빠르게 만들고, 성공 확률을 높이는 수단이 될 수 있다는 것이다. 동시에 글은 모든 경우에 프레임워크가 필요한 것은 아니라고 선을 긋는다. 단순한 LLM 요청이라면 프레임워크를 추가하는 것이 지나치게 무거운 선택일 수 있다고 분명히 말한다.

6. LangSmith가 프레임워크와 독립적으로 설계된 이유

글의 두 번째 축은 LangSmith가 LangChain 오픈소스와 독립적으로 작동하도록 만들어졌다는 설명이다. 저자들은 초기에 에이전트를 프로덕션으로 보내는 가장 큰 장벽이 품질이라고 보았고, 에이전트 전용 관측성과 평가가 필수 도구라고 판단했다. 이름은 LangSmith로 정했지만, 하나의 에이전트 프레임워크만 존재하지는 않을 것이라는 직감을 바탕으로 특정 프레임워크에 종속되지 않는 플랫폼을 만들었다고 한다. LangSmith는 LangChain이나 다른 자사 프레임워크를 쓰지 않아도 사용할 수 있고, AutoGen, Claude Agent SDK, CrewAI, Mastra, OpenAI Agents, PydanticAI, Vercel AI SDK 등 여러 프레임워크와 통합된다. 또한 OpenTelemetry 기반 트레이싱을 지원해 OTEL 규격을 내보내는 시스템의 데이터를 수집할 수 있으며, 프레임워크 없이 만든 에이전트에도 사용할 수 있다고 설명한다.

7. 에이전트 엔지니어링에서 트레이스가 핵심이 되는 이유

마지막으로 글은 어떤 프레임워크를 쓰든 에이전트의 동작을 이해하려면 트레이스가 중요하다고 강조한다. 에이전트에서는 애플리케이션 로직이 코드에만 명확히 드러나는 것이 아니라, 실제 실행 과정의 트레이스 안에 기록된다고 본다. 트레이스는 에이전트 디버깅, 모니터링, 평가의 기반이며, 에이전트가 왜 실패하는지 파악하기 위한 핵심 자료다. 글은 에이전트 구축이 첫 단계일 뿐이고, 에이전트는 비결정적 시스템이기 때문에 배포 전에는 어떤 입력과 출력이 나올지 완전히 알 수 없다고 설명한다. 그래서 디버깅, 테스트, 모니터링은 별도 사후 작업이 아니라 에이전트 엔지니어링과 구축 과정 자체의 일부로 다뤄져야 한다고 결론짓는다.

🧾 핵심 주장 / 시사점

• 이 글의 핵심은 프레임워크의 존폐가 아니라 추상화의 수준이 계속 바뀐다는 점이다. 초기에는 연결과 체이닝이 중요했고, 이후에는 상태성과 런타임, 지금은 더 자율적인 도구 호출과 컨텍스트 관리가 중요해졌다는 흐름을 보여준다.
• 저자들은 자사 프레임워크를 옹호하면서도 단순한 LLM 요청에는 프레임워크가 과할 수 있다고 인정한다. 이는 프레임워크를 무조건 도입할 것이 아니라 작업의 복잡도, 실행 시간, 협업 방식, 관측 필요성을 기준으로 선택해야 한다는 실용적 기준을 제시한다.
• LangSmith를 프레임워크와 독립적으로 설계했다는 대목은 에이전트 생태계에서 관측성과 평가는 특정 구현 방식보다 더 안정적인 계층이 될 수 있음을 시사한다. 모델과 프레임워크가 빠르게 바뀌어도 트레이스, 평가, 디버깅의 필요성은 계속 남는다는 판단이다.

✅ 액션 아이템

• LangChain, LangGraph, deepagents를 체이닝, 런타임, 하네스 관점으로 나눠 현재 에이전트 프로젝트에 필요한 추상화 수준을 고른다.
• 장기 작업 계획, 도구 호출 루프, 파일시스템 컨텍스트 오프로딩, 서브에이전트 오케스트레이션이 필요한 작업과 단순 모델 호출로 충분한 작업을 구분한다.
• LangSmith 트레이스를 기준으로 디버깅, 모니터링, 평가 지표를 프레임워크 사용 여부와 분리해 설계한다.

❓ 열린 질문

• LLM이 강해질수록 에이전트 프레임워크는 사라지는 것이 아니라 어떤 낮은 수준의 런타임 문제로 이동할까?
• 모델에 더 많은 판단을 위임할 때 개발자는 어디까지를 코드로 고정하고 어디부터를 하네스에 맡겨야 할까?
• 에이전트 관측성은 특정 프레임워크 기능이 아니라 어떤 공통 운영 계층으로 설계되어야 할까?