LangChain / LangGraph / LangSmith 완전 정복 가이드

게시 2026/03/13

By BLUEBUG

37 분읽는 시간

Ai agent직무 코테보고 멘붕왓다
랭체인이 이렇게 쓰이는거엿구나
프롬프팅이 전부란 말 취소..
LLM의 확률게임을 통제하기 위해서 존재하는 세심한 제어코드들
난 여태까지 걍 프롬프트 깎기 장인 햇는데
걍 개 야매 가라였구나 느낌 ㅋㅋㅋ
근디 굳이 필요한가싶기도하다
이미 프롬프트로해도 개잘되는디…
글고 agi오면 저게 쓰일려나 싶다
금융쪽에나 좀 쓰이려나
암튼 충격받고 자러감
원래 아무것도 모를수록 자신감이 넘친다
난 아무것도 모르는것이것다
https://www.threads.com/@aidevarchive/post/DVwEgcDDz_j

— “프롬프트만 잘 깎으면 되는 거 아니었어?” 에서 AI Agent 엔지니어링까지

작성 기준 버전
LangChain 0.3.x · LangGraph 1.1.x · LangSmith 0.3.x (2026년 3월 기준 최신)

들어가며 — 코테 멘붕의 진짜 이유

Threads에 올라온 어느 개발자의 고백이 많은 이들의 공감을 얻었다. AI Agent 직무 코딩테스트를 보고 나서 “랭체인이 이렇게 쓰이는 거였구나, 프롬프팅이 전부란 말 취소”라는 후기였다. 이 짧은 문장 안에는 사실 굉장히 중요한 통찰이 담겨 있다.

프롬프트 엔지니어링이 무의미하다는 말이 아니다. 오히려 반대다. 좋은 프롬프트는 여전히 강력하다. 하지만 실제 프로덕션 AI 시스템을 만들 때는 프롬프트만으로는 해결할 수 없는 문제들이 반드시 등장한다. LangChain 생태계는 바로 그 틈새를 메우기 위해 탄생했고, 이 문서는 그 전체 그림을 처음부터 끝까지 설명한다.

1. 왜 프롬프트만으론 부족한가 — LLM의 확률 게임과 제어의 필요성

LLM은 본질적으로 확률 기계다. 동일한 입력을 줘도 매번 조금씩 다른 출력이 나올 수 있고, 긴 작업을 수행하다 보면 초반의 사소한 오차가 후반에 눈덩이처럼 불어나는 경향이 있다. 단순한 Q&A 챗봇이라면 이런 불확실성이 큰 문제가 안 될 수 있다. 하지만 다음과 같은 상황을 생각해보자.

금융 리포트 자동 생성 시스템을 만든다고 가정하자. 이 시스템은 데이터베이스에서 수치를 조회하고, 여러 소스의 뉴스를 요약하며, 리스크 분석을 수행하고, 최종 보고서를 특정 포맷으로 출력해야 한다. 이 과정에서 LLM이 중간에 잘못된 수치를 “창작”하거나, 처리 흐름을 임의로 건너뛰거나, 맥락이 너무 길어져서 앞부분을 잊어버리는 일이 발생하면 어떻게 될까? 프롬프트를 아무리 정교하게 다듬어도 이런 상황을 100% 막기는 어렵다.

바로 이 지점에서 LangChain 생태계가 등장한다. LLM의 확률적 행동을 코드 레벨에서 제어하고, 실행 흐름을 구조적으로 관리하며, 무엇이 어떻게 잘못됐는지 추적할 수 있게 해주는 도구들의 집합이다.

LangChain 창업자 Harrison Chase는 최근 블로그 포스트에서 에이전트 패턴의 진화를 이렇게 정리했다. 초기에는 단순한 체이닝(chaining)이었고, 그 다음은 워크플로우 오케스트레이션이었으며, 이제는 파일시스템과 메모리를 갖춘 툴 콜링 루프(tool-calling-in-a-loop) 단계로 발전했다. 각 시대마다 필요한 도구가 달랐고, 이것이 LangChain → LangGraph → deepagents로 이어지는 진화의 배경이다.

2. LangChain 생태계의 삼각편대 — 프레임워크, 런타임, 관측 플랫폼

현재의 LangChain 생태계는 세 축으로 구성된다. 각각이 독립적으로도 쓸 수 있지만, 함께 쓸 때 진가를 발휘한다.

LangChain (현 버전 0.3.x)은 LLM 애플리케이션을 빠르게 조립할 수 있는 컴포넌트 라이브러리다. 다양한 모델 제공사(OpenAI, Anthropic, Google 등)와의 표준화된 인터페이스, 프롬프트 템플릿, 문서 로더, 벡터 스토어 연결, 도구(tool) 통합 등 실전에 필요한 거의 모든 빌딩 블록이 포함되어 있다. 처음 AI 앱을 만들 때 가장 빠르게 시작할 수 있는 진입점이다.

LangGraph (현 버전 1.1.x)는 복잡하고 상태를 유지해야 하는 에이전트 워크플로우를 위한 오케스트레이션 프레임워크다. 작업 흐름을 그래프(노드와 엣지)로 정의하고, 분기 로직, 루프, 병렬 실행, 체크포인팅, Human-in-the-Loop 등을 코드로 명시적으로 제어할 수 있다. LinkedIn, Uber, Klarna, GitLab 같은 대형 테크 기업들이 프로덕션에서 사용하고 있다.

LangSmith (현 버전 0.3.x)는 에이전트 엔지니어링 플랫폼이다. 트레이싱, 평가, 디버깅, 모니터링을 하나의 인터페이스에서 처리한다. LangChain이나 LangGraph를 쓰지 않더라도 Python, TypeScript, Go, Java SDK를 통해 어떤 에이전트 스택과도 연동된다는 점이 특징이다.

3. LangChain 0.3.x — 2025년의 대변신

2022년 10월 Harrison Chase가 오픈소스로 공개한 LangChain은 초창기에는 “LLM을 데이터나 API에 가장 쉽게 연결하는 방법”으로 주목받았다. 하지만 2023년 여름 무렵부터 “에이전트 프레임워크는 사실 필요 없다”는 비판이 거세졌다. 추상화 레이어가 너무 많고, 디버깅이 어렵고, 학습 곡선이 가파르다는 이유였다.

이에 LangChain 팀은 2025년에 원래의 LangChain을 대폭 재작성했다. Harrison Chase는 “너무 opinionated(독단적)했던 초기 버전에서 벗어나, 더 유연하고 간결한 방향으로 정리했다”고 설명했다. 현재의 LangChain 0.3.x는 과거의 복잡한 체인 구조 대신, 모델 호출·도구 바인딩·프롬프트 조합 등 핵심 기능에 집중한 모습이다.

현재 LangChain이 가장 잘 하는 일을 정리하면 이렇다. 다양한 LLM 제공사를 동일한 인터페이스로 교체 가능하게 해주는 모델 추상화, 문서 처리 및 임베딩을 통한 RAG 파이프라인 구성, 외부 시스템과의 연결을 위한 도구 통합 및 함수 호출, 그리고 간단한 ReAct 에이전트 패턴 구현이다.

실제 LangChain을 쓰는 좋은 시나리오는 다음과 같다. 빠른 프로토타이핑이 필요할 때, 여러 LLM 벤더를 비교하며 실험할 때, RAG(Retrieval-Augmented Generation) 시스템을 만들 때, 또는 복잡한 오케스트레이션이 필요 없는 단순 도구 호출 에이전트를 만들 때다.

4. LangGraph 1.1.x — 에이전트 제어의 핵심

LangGraph는 LangChain 생태계에서 가장 빠르게 성장하고 있는 컴포넌트다. 2024년에 등장해 2025년에 1.0 버전이 출시됐고, 현재는 1.1.x 버전까지 진화했다.

4-1. 핵심 철학: 그래프로 생각하기

LangGraph의 핵심 아이디어는 에이전트의 실행 흐름을 방향 그래프(Directed Graph)로 모델링한다는 것이다. 기존의 선형적인 체인 방식과 달리, 노드(Node)와 엣지(Edge)로 구성된 StateGraph를 정의하고, 각 노드는 LLM 호출, 도구 실행, 또는 임의의 Python 함수가 될 수 있다.

이 접근 방식의 결정적 장점은 명시성이다. 에이전트가 어떤 경우에 어떤 노드로 이동하는지가 코드에 명확하게 드러난다. 프롬프트만으로 흐름을 제어할 때의 “블랙박스” 문제가 사라진다.

  
from langgraph.graph import StateGraph, MessagesState, START, END

# 그래프 정의
graph_builder = StateGraph(MessagesState)

# 노드 추가
graph_builder.add_node("agent", agent_node)
graph_builder.add_node("tools", tool_node)

# 엣지 정의 (조건부 분기)
graph_builder.add_edge(START, "agent")
graph_builder.add_conditional_edges(
    "agent",
    should_use_tools,  # 이 함수가 다음 노드를 결정
    {"use_tools": "tools", "end": END}
)
graph_builder.add_edge("tools", "agent")

graph = graph_builder.compile()

위 코드를 보면 에이전트가 도구를 쓸지 말지 결정하는 로직(should_use_tools)이 명시적으로 코드에 존재한다. LLM에게 “알아서 판단해”라고 프롬프트로 위임하는 게 아니라, 개발자가 분기 조건을 직접 정의할 수 있다는 의미다.

4-2. 상태 관리와 체크포인팅

LangGraph의 또 다른 강점은 영속적인 상태 관리다. MemorySaver나 PostgreSQL 기반 체크포인터를 통해 그래프의 실행 상태를 특정 시점에 저장할 수 있다. 이것이 가능하면 다음과 같은 일들이 된다.

긴 작업 도중 실패가 발생해도 처음부터 다시 시작할 필요 없이 실패 직전 상태부터 재개할 수 있다. 사용자가 며칠 후 대화를 이어가도 이전 맥락이 그대로 살아있다. 그리고 가장 중요하게는, Human-in-the-Loop 패턴이 가능해진다 — 에이전트가 중요한 결정을 내리기 전에 실행을 일시 정지하고 사람의 승인을 기다릴 수 있는 것이다.

4-3. LangGraph 1.1의 새 기능 — 타입 안전성

2025년 말 출시된 LangGraph 1.1은 스트리밍 API에 타입 안전성을 대폭 강화했다. 기존의 version="v1"에서는 stream()이 단순 튜플이나 딕셔너리를 반환했지만, 새로운 version="v2" 옵션을 사용하면 GraphOutput 객체가 반환되고, Pydantic 모델이나 데이터클래스로 정의된 상태가 자동으로 올바른 타입으로 변환된다. 이는 대규모 프로덕션 코드베이스에서의 안정성과 IDE 자동완성 지원을 크게 향상시킨다.

4-4. 컨텍스트 오버플로우 문제와 LangGraph의 해법

Threads 댓글에서 누군가가 정확히 지적한 문제가 있다. “오케스트레이터쪽만 딱 넣으면 좋긴 할 듯, 중간에 context overflow나서 제어 흐름 끊길 때가 꽤 있더라고요.”

이 현상은 AI 에이전트 실무에서 매우 흔하게 발생한다. 도구 호출 결과, 이전 대화 히스토리, 중간 추론 과정이 축적되면서 컨텍스트 윈도우가 가득 차버리고, 모델이 초반의 지시사항을 “잊어버리는” 현상이다. Drew Breunig가 명명한 개념들로 설명하면, 컨텍스트 포이즈닝(잘못된 정보가 맥락에 쌓이는 것), 컨텍스트 디스트랙션(너무 많은 맥락이 모델을 혼란시키는 것), 컨텍스트 클래시(맥락 내 정보들이 서로 충돌하는 것)이 대표적인 문제들이다.

LangGraph는 이 문제를 여러 방식으로 해결한다. 첫째, 대화 히스토리 요약 기능을 그래프 내 전용 노드로 구성할 수 있다. 대화가 일정 길이를 넘으면 자동으로 요약 노드가 실행되어 컨텍스트를 압축한다. 둘째, 서브에이전트 패턴을 통해 각 서브에이전트가 독립적인 컨텍스트 윈도우를 가지게 하여, 중앙 오케스트레이터의 컨텍스트를 깨끗하게 유지한다. 셋째, deepagents v0.4에서는 파일시스템 컨텍스트 오프로딩을 지원하여 중간 결과를 파일로 저장하고 필요할 때만 불러오는 방식을 사용한다.

5. “그냥 프롬프트로도 잘 되던데?” — 진짜 트레이드오프 분석

이 글에서 가장 솔직하게 다뤄야 할 부분이다. Threads 원글에서도 “굳이 필요한가 싶기도 하다, 이미 프롬프트로 해도 개잘되는디”라는 의문을 제기했고, 다른 댓글에서도 “엥간한 3~4개 정도 오케스트레이션 돌려본 경우 Claude Opus 4.6은 프롬프팅만 해도 빗나가는 경우 없었음”이라는 경험을 공유했다.

이 경험은 완전히 타당하다. 2026년 현재, 최신 대형 모델들은 이전보다 훨씬 더 긴 컨텍스트를 다루고 더 정확하게 지시를 따른다. Harrison Chase 본인도 이 점을 인정하면서, “LLM이 추론 능력이 좋아질수록 더 많은 결정을 LLM에 위임할 수 있고, 하드코딩된 오케스트레이션 패턴의 필요성이 줄어드는 것이 맞다”고 설명했다. 이것이 deepagents처럼 더 자율적인 에이전트 하네스를 만든 이유이기도 하다.

그렇다면 LangGraph 같은 명시적 제어가 실제로 필요한 경우는 언제인가?

LangGraph가 진가를 발휘하는 시나리오를 구체적으로 들면 다음과 같다. 금융, 의료, 법률처럼 규제 환경에서 모든 결정 경로가 감사(audit) 가능해야 하는 경우, 10개 이상의 에이전트가 복잡한 의존 관계를 가지며 협력하는 대규모 멀티에이전트 시스템, 반드시 사람의 승인을 거쳐야 하는 Human-in-the-Loop 워크플로우, 중간에 실패가 발생해도 재시작 없이 이어서 진행해야 하는 장시간 실행 태스크, 그리고 모델 불확실성이 높은 복잡한 분기를 코드로 명확히 통제해야 하는 경우다.

반면 프롬프팅만으로 충분한 시나리오도 분명히 있다. 3~4개 이하의 에이전트가 협력하는 경우, 각 에이전트의 역할이 명확하고 중간에 상태를 저장할 필요가 없는 경우, 프로토타이핑이나 실험 단계에서 빠른 이터레이션이 더 중요한 경우, 그리고 최신 고성능 모델을 사용하는 경우가 그렇다.

정리하면 이렇다. 프롬프트 엔지니어링과 LangGraph는 경쟁 관계가 아니라 상호 보완 관계다. 프롬프트는 에이전트 내부의 품질을 높이고, LangGraph는 에이전트들 사이의 흐름과 시스템 전체의 신뢰성을 보장한다. 단순한 작업은 프롬프트만으로 충분하지만, 시스템이 복잡해지고 예측 가능성이 중요해질수록 명시적 오케스트레이션의 필요성이 커진다.

6. 서브에이전트 아키텍처 — 오케스트레이터만 쓰라는 말의 진의

Threads 댓글의 핵심 주장을 다시 살펴보자. “오케스트레이터쪽만 딱 넣으면 좋긴 할 듯, 나머지 서브에이전트에다간 굳이?”

이 의견은 실무 경험에서 나온 굉장히 현실적인 통찰이다. 그 이유를 LangGraph의 서브에이전트 패턴 관점에서 설명하면 이렇다.

서브에이전트 아키텍처에서 중앙의 오케스트레이터(Supervisor)는 전체 작업을 어떤 서브에이전트에게 위임할지 결정하고 결과를 수집한다. 각 서브에이전트는 자신에게 주어진 태스크를 독립적인 컨텍스트 윈도우 안에서 처리한다. 중요한 것은 오케스트레이터가 모든 서브에이전트의 실행 세부사항을 다 기억할 필요가 없다는 점이다 — 최종 결과만 받으면 된다.

이 구조의 핵심 장점이 바로 컨텍스트 격리(context isolation)다. 각 서브에이전트 호출이 깨끗한 컨텍스트 윈도우에서 시작되기 때문에, 오케스트레이터의 컨텍스트가 서브에이전트들의 세부 작업 내용으로 오염되지 않는다.

LangGraph의 공식 문서도 이 패턴의 적합한 사용 케이스를 이렇게 설명한다. 독립적인 복잡한 태스크를 별도의 컨텍스트 윈도우에서 격리해야 할 때, 서브에이전트 개발을 여러 팀이 분담해야 할 때, 수십 개의 새로운 에이전트를 조율자 수정 없이 추가할 수 있어야 할 때 적합하다.

따라서 “오케스트레이터에만 LangGraph를 쓰고 서브에이전트는 단순 LLM 호출로” 하는 접근은 실용적으로 매우 합리적인 선택이다. 오케스트레이터만이 전체 흐름의 상태를 유지하고, 서브에이전트들은 각자의 작업에 집중하면 된다.

7. LangSmith 0.3.x — 보이지 않는 것을 보이게 만드는 도구

에이전트 시스템이 복잡해질수록 “뭔가 이상한데 어디서 잘못된 거지?”를 찾는 작업이 전통적인 소프트웨어 디버깅보다 훨씬 어려워진다. LLM 응답 자체가 확률적이고, 실행 경로가 동적으로 바뀌며, 수십 개의 연쇄 호출이 발생하기 때문이다.

LangSmith는 바로 이 문제를 해결하기 위해 만들어졌다. 모든 실행 단계를 타임라인 형태로 시각화하여, 어떤 노드에서 무슨 입력이 들어가고 무슨 출력이 나왔는지, 얼마나 걸렸는지, 비용은 얼마인지를 한눈에 볼 수 있게 해준다.

2025~2026년 사이에 추가된 주요 기능들을 살펴보면, 우선 통합 비용 추적 기능이 있다. 이제 LLM 호출뿐만 아니라 에이전트 워크플로우 전체에 걸친 비용을 집계할 수 있다. 커스텀 비용 메타데이터를 어떤 실행에도 추가할 수 있어, LLM 토큰 비용 외의 API 호출 비용 등도 포함한 전체 그림을 파악할 수 있다.

Polly라는 AI 어시스턴트가 LangSmith에 내장되어 디버깅과 분석을 도와주며, LangSmith Fetch라는 CLI 도구가 추가되어 터미널이나 IDE에서 직접 트레이스를 조회할 수 있게 됐다.

LangSmith Insights Agent는 일정을 설정해두면 자동으로 에이전트의 성능 패턴을 분석하고 인사이트를 생성한다. 수동으로 트리거할 필요 없이 매일 또는 매주 자동으로 실행된다.

또한 2025년 10월부터 LangGraph Platform이 LangSmith Deployment로 이름이 바뀌었다. 에이전트 배포 인프라가 LangSmith 플랫폼 안으로 통합된 것이다. LangGraph는 오픈소스 프레임워크로 남아있고, LangSmith Deployment는 그 위에서 실행되는 관리형 배포 플랫폼이 된 셈이다.

8. AGI가 오면 이런 프레임워크가 사라질까?

Threads 원글의 또 다른 의문, “AGI 오면 저게 쓰일려나 싶다”에 대해서도 생각해볼 필요가 있다.

단기적으로는 더욱 필요해질 가능성이 높다. 모델이 강력해질수록 더 복잡한 태스크를 수행하게 되고, 더 복잡한 태스크는 더 정교한 오케스트레이션과 더 강력한 관측 능력을 요구한다. Klarna의 사례처럼 AI 어시스턴트가 케이스 해결 시간을 80% 줄이는 수준이 되면, 그 시스템의 신뢰성과 감사 가능성은 오히려 더 중요해진다.

장기적으로는 어떨까? 진정한 AGI 수준의 시스템이라면 스스로 실행 계획을 세우고 오케스트레이션을 수행할 것이기 때문에, 외부 프레임워크의 역할이 줄어들 수 있다는 주장도 있다. Harrison Chase가 deepagents를 만든 이유가 바로 이것이다 — “LLM이 더 잘 추론할수록 더 많은 결정을 LLM 자신에게 위임해도 된다”는 철학을 반영한 것이다.

그러나 금융 시스템, 의료 기기, 법률 프로세스 같은 규제 도메인에서는 설령 AI 자체의 판단 능력이 완벽해지더라도, 인간이 실행 흐름을 감사하고 개입할 수 있는 구조가 법적으로 요구될 가능성이 높다. 이 관점에서 LangGraph 같은 명시적 제어 프레임워크는 기술적 필요가 아닌 규제적 요구사항으로 지속될 것이다.

9. 2026년 3월 현재 — 각 프레임워크 최신 상태 요약

지금 시점의 LangChain 생태계 각 컴포넌트 상태를 정리하면 다음과 같다.

LangChain 0.3.x: 2025년 완전 재작성을 거쳐 더 간결하고 실용적인 방향으로 정리됐다. 빠른 프로토타이핑과 RAG 파이프라인 구축에 최적화되어 있으며, LangSmith Agent Builder를 통해 어떤 모델 제공사와도 쉽게 에이전트를 만들 수 있다.

LangGraph 1.1.x: 프로덕션 에이전트를 위한 로우레벨 오케스트레이션 프레임워크로 확고하게 자리잡았다. 1.1 버전에서 스트리밍 API의 완전한 타입 안전성이 추가됐고, A2A(Agent-to-Agent) 프로토콜 지원, AES 암호화 체크포인팅 등 엔터프라이즈 기능이 강화됐다. MIT 라이선스 오픈소스로 무료 사용 가능하다.

deepagents v0.4: LangGraph보다 더 자율적인 장시간 실행 에이전트를 위한 하네스다. 플러그어블 샌드박스 지원, 스마트한 대화 히스토리 요약, OpenAI Responses API 기본 지원이 추가됐다. OpenAI Agents SDK와 개념적으로 유사하지만 모델 불가지론적(model-agnostic)이라는 차이가 있다.

LangSmith 0.3.x + LangSmith Deployment: 에이전트 엔지니어링 플랫폼으로 관측성, 평가, 배포를 통합 제공한다. 2025년 10월 LangGraph Platform에서 LangSmith Deployment로 명칭이 변경됐다.

10. 실전 결정 프레임워크 — 무엇을 언제 써야 하는가

이 모든 내용을 종합해서, 실제로 무언가를 만들 때 어떤 도구를 선택할지 판단하는 기준을 정리하면 이렇다.

단순한 LLM 애플리케이션을 빠르게 만들어야 한다면 LangChain부터 시작하는 것이 맞다. RAG 파이프라인, 간단한 도구 호출 에이전트, 모델 비교 실험 등이 여기에 해당한다.

에이전트 워크플로우가 복잡해지거나, 상태 유지가 필요하거나, 사람의 개입이 필요하거나, 실패 복구가 중요하다면 LangGraph를 도입할 시점이다. 특히 수십 개의 에이전트가 복잡한 분기와 의존 관계를 가지는 경우, 또는 컨텍스트 오버플로우 문제가 발생하는 경우 LangGraph의 서브에이전트 아키텍처가 효과적이다.

최신 고성능 모델로 3~4개 에이전트를 돌리는 정도라면, 좋은 프롬프트 엔지니어링만으로도 충분할 수 있다. Claude Opus 4.6처럼 강력한 모델은 명확한 역할 분담 프롬프트만으로도 높은 신뢰도를 보여준다.

프로덕션 배포 이후 성능 모니터링, 디버깅, 회귀 테스트가 필요하다면 LangSmith를 연동하는 것이 거의 필수적이다. 어떤 프레임워크를 써도 LangSmith와는 함께 쓸 수 있다.

나가며 — “아무것도 모를수록 자신감이 넘친다”는 통찰

Threads 원글의 마지막 문장이 사실 가장 핵심적인 메시지다. “원래 아무것도 모를수록 자신감이 넘친다. 난 아무것도 모르는 것이었다.”

프롬프트 엔지니어링을 잘 하는 것은 정말 가치 있는 능력이다. 하지만 AI Agent 엔지니어링은 그것을 포함하면서 더 넓은 영역을 다룬다. LLM의 확률적 출력을 구조적으로 제어하는 방법, 복잡한 시스템의 실행 흐름을 추적하고 디버깅하는 방법, 대규모 에이전트 시스템을 신뢰성 있게 운영하는 방법이 모두 포함된다.

프롬프트를 잘 깎는 것도 중요하다. 코드로 제어 흐름을 명시하는 것도 중요하다. AGI 시대가 오더라도, 신뢰성과 감사 가능성이 요구되는 도메인에서는 여전히 정교한 시스템 설계가 필요할 것이다. 코테에서 멘붕을 받았다는 것은 아직 배울 것이 있다는 신호이고, 그것을 인식했다는 것 자체가 이미 성장의 시작이다.

참고 자료

LangChain 공식 문서: https://docs.langchain.com
LangGraph 공식 문서: https://langchain-ai.github.io/langgraph
LangSmith 공식 문서: https://docs.smith.langchain.com
LangChain 체인지로그: https://changelog.langchain.com
LangGraph GitHub 릴리즈: https://github.com/langchain-ai/langgraph/releases
Harrison Chase 블로그 — “On Agent Frameworks and Agent Observability”: https://blog.langchain.com/on-agent-frameworks-and-agent-observability/
DataCamp — LangChain vs LangGraph vs LangSmith 비교: https://www.datacamp.com/tutorial/langchain-vs-langgraph-vs-langsmith-vs-langflow

작성일: 2026-03-13

AI, Platform & Framework

AI ai-agent engineering-platform development-framework Developer LangChain LangGraph LangSmith context-overflow human-in-the-loop multi-agent sub-agents context-isolation agent-orchestrator langsmith-fetch langsmith-insights-agent langsmith-deployment AGI Claude.write