모델이 질문을 해석하고 필요한 도구까지 고를 수 있는데, LangChain·LangGraph·LangSmith를 더 배워야 할까요? 이름도 비슷해서 AI 앱을 만들려면 세 가지부터 갖춰야 하는 것처럼 느껴집니다.
저는 그런 출발 순서에는 동의하지 않습니다. 문서를 찾아 답하거나 내용을 요약하는 기능은 모델 공급자의 SDK와 일반 함수로 만들 수 있습니다. SDK는 해당 서비스의 API를 호출하기 쉽게 묶은 라이브러리입니다. 먼저 기능을 작게 구현하고, 도구 연결·실행 복구·품질 확인 중 실제로 반복되는 문제가 무엇인지 보는 편이 낫다고 생각합니다.
영화 제작으로 비유하면 배우와 소품을 연결하는 일, 촬영 순서와 재촬영을 관리하는 일, 촬영본을 확인하는 일은 다릅니다. LangChain은 에이전트 구성, LangGraph는 상태와 실행 흐름 제어, LangSmith는 추적과 평가를 중심으로 맡습니다. LangSmith에는 배포 기능도 있습니다. 이 역할이 지금 필요한지가 도입의 출발점입니다.
배우, 촬영 진행, 감독의 모니터
영화 비유에서 배우는 LLM, 배우가 쓰는 소품은 도구에 해당합니다. LangChain 자체가 배우인 것은 아닙니다. 모델에 요청을 전달하고 도구 호출 결과를 돌려주도록 연결하는 제작 키트에 더 가깝습니다. 주문 조회 도구를 배우 손에 쥐여 줘야 배우가 상상한 주문이 아니라 실제 주문을 확인할 수 있습니다.
LangGraph는 장면 순서와 재촬영, 대기 중인 승인, 중단 뒤 진행 상태를 다루는 촬영 진행 체계로 비유할 수 있습니다. 스토리보드라는 비유도 좋지만, 그림만 보관하는 것이 아니라 실제 실행과 상태를 관리한다는 점을 더해야 합니다.
LangSmith는 촬영본을 확인하는 모니터와 편집·평가실입니다. 어느 장면에서 소품을 떨어뜨렸는지 되짚고, 다시 찍은 결과가 나아졌는지 같은 기준으로 비교합니다. 이 모니터가 배우를 대신 연기시키거나 좋은 대본을 자동으로 보장하는 것은 아닙니다.
제품 분류로 돌아오면 LangChain과 LangGraph는 오픈소스 프레임워크이고, LangGraph는 실행 런타임의 역할도 합니다. LangSmith는 관측·평가·프롬프트 관리·배포 등을 제공하는 플랫폼입니다. 공식 LangGraph 개요도 이 역할을 구분하고 있습니다. ‘세 프레임워크 비교’라는 검색어로 접근하더라도 실제로는 서로 다른 계층을 비교하고 있는 셈입니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| LangChain | 에이전트 구성 | 모델·도구·프롬프트와 실행 중 개입 규칙을 조합합니다. | 정책 검색과 주문 조회를 쓰는 상담 에이전트 |
| LangGraph | 상태와 실행 경로 제어 | 작업 순서·분기·반복과 중단·재개를 설계합니다. | 조건 확인 → 담당자 승인 대기 → 처리 재개 |
| LangSmith | 관측·평가·운영 | 실행 경로를 추적하고 버전별 결과를 평가합니다. 배포 기능도 제공합니다. | 오답이 검색·도구·생성 중 어디서 시작됐는지 조사 |
똑똑한 배우가 촬영 진행표까지 대신할까요
모델이 좋아져 요청을 한 번에 이해하고 필요한 도구를 정확하게 선택한다면, 단순한 작업을 여러 전문 에이전트로 나눌 이유는 줄어들 수 있습니다. 도구 이름이 많거나 그래프가 복잡하다는 이유로 앱이 더 좋아지는 것은 아닙니다. LangChain의 최근 설계 설명도 모델이 발전하면서 기본 에이전트 루프를 공통 구성으로 정리하고, 더 세밀한 제어가 필요할 때 직접 그래프를 구성하는 역할을 구분합니다.
그런데 배우가 대사를 잘 외워도 “승인 전에는 이 장면을 촬영하지 않는다”는 제작 규칙과 중단된 촬영 기록은 별도로 남겨야 합니다. 앱에서도 모델의 판단 능력과 누가 어떤 주문을 바꿀 수 있는지, 재시작 뒤 어디서 이어 가는지, 같은 처리를 두 번 하지 않는지는 다른 문제입니다. 이 차이가 상태를 관리하는 실행기의 이유가 됩니다.
따라서 “좋은 모델이면 프레임워크가 필요 없다”와 “운영하려면 무조건 필요하다”는 말 모두 조건이 빠져 있습니다. 모델 호출을 감싸는 기능의 이익은 작아질 수 있지만, 오래 기다리고 다시 이어 가는 작업의 책임까지 사라지는 것은 아닙니다. 이 책임을 직접 구현할지 기존 도구를 사용할지 선택하는 것입니다.
LangChain: 모델에게 쓸 수 있는 도구를 연결합니다
쇼핑몰 고객이 “어제 받은 신발이 작아요. 교환할 수 있나요?”라고 물었다고 가정해 보겠습니다. 모델의 일반 지식만으로는 이 쇼핑몰의 교환 정책이나 해당 주문 상태를 알 수 없습니다. 정책을 검색하고 주문을 조회한 뒤 답해야 합니다.
LangChain은 이런 앱에서 모델과 도구를 조합하는 공통 틀을 제공합니다. 공식 개요는 create_agent를 중심으로 모델·도구·프롬프트·미들웨어를 구성하는 방식을 안내합니다. 미들웨어는 모델이나 도구 호출 전후에 규칙을 넣는 장치입니다. 예를 들어 호출 조건을 제한하거나 실패 처리 방식을 추가할 때 사용합니다.
이 사례에서는 ‘교환 정책 검색’과 ‘주문 조회’를 도구로 제공할 수 있습니다. 에이전트는 필요에 따라 도구를 호출하고, 결과를 보고 추가 정보가 필요한지 판단한 뒤 답합니다. 도구 호출을 선언하는 것은 모델이지만 실제 조회를 실행하는 것은 앱의 코드입니다. 도구 설명이 친절하다고 고객 인증이나 주문 접근 권한까지 해결되는 것은 아닙니다.
여기서 자주 생기는 오해가 있습니다. LangChain은 한 방향으로만 이어지는 체인이고 반복은 LangGraph에서만 가능하다는 설명입니다. 이름 때문에 떠올리기 쉽지만, LangChain의 에이전트는 모델과 도구를 오가는 루프를 지원합니다. LangChain 에이전트 자체가 LangGraph 위에서 구현됩니다. LangGraph를 직접 다루지 않아도 그 기반 위의 에이전트를 쓸 수 있습니다.
LangChain을 검토할 이유는 모델·도구 연결과 공통 처리 규칙을 반복해서 작성하고 있을 때입니다. 여러 공급자의 모델 인터페이스를 통일하는 데도 도움이 됩니다. 다만 호출 인터페이스를 바꿀 수 있다는 것과 결과가 동일하다는 것은 다릅니다. 모델을 교체하면 도구 선택, 출력 형식, 응답 품질은 다시 검증해야 합니다.
반대로 정해진 문서 하나를 요약하거나, 이미 찾은 문맥을 모델에 한 번 전달하는 기능이라면 공급자 SDK와 일반 함수만으로 충분할 수 있습니다. RAG도 검색한 근거를 붙여 답하는 방식이지 특정 프레임워크의 이름이 아닙니다. 항상 ‘검색 → 생성’으로 끝나는 앱에 자율적인 도구 선택을 꼭 넣을 이유는 없습니다.
LangChain을 선택하지 않아도 도구 호출은 구현할 수 있습니다. 모델이 요청한 도구를 앱에서 실행하고 결과를 다시 전달하면 됩니다. 다만 여러 도구의 오류 처리, 실행 기록, 호출 제한 같은 공통 코드가 반복되면 직접 만든 구현을 계속 유지할지 프레임워크의 규칙을 사용할지 비교할 이유가 생깁니다. 모델 API 호출 한 번을 감싸는 편의와 여러 실행의 공통 정책을 관리하는 편의는 구분해야 합니다.
LangGraph: 승인과 재시작이 생기면 흐름을 드러냅니다
상담 앱에 요구사항이 하나 더 붙었다고 해 보겠습니다. “정책상 애매한 주문은 담당자가 승인한 뒤 교환을 접수해야 한다.” 담당자는 몇 시간 뒤에 답할 수 있고, 그 사이 서버가 재시작될 수도 있습니다. 이제 대화를 잘하는 것 외에 어디서 멈췄으며 무엇을 기다리는지가 중요해집니다.
LangGraph는 이런 상태가 있는 실행을 구성하는 저수준 도구입니다. Graph API에서는 상태를 읽고 갱신하는 노드와 다음 실행을 결정하는 엣지를 연결합니다. 노드마다 AI가 들어갈 필요는 없습니다. 주문 날짜 비교와 승인 여부 확인은 일반 코드로 처리하고, 고객의 모호한 표현 해석은 모델에 맡기는 식으로 섞을 수 있습니다.
교환 사례의 상태에는 문의 ID, 주문 조회 결과, 적용한 정책의 버전, 추가 질문, 승인 상태, 처리 결과 식별자가 들어갈 수 있습니다. 정보가 부족하면 고객에게 묻고, 예외라면 담당자에게 넘기며, 승인되면 접수를 진행합니다. 그래프의 가치는 화살표가 많다는 데 있지 않습니다. 어떤 조건에서 어느 작업이 허용되는지가 코드와 상태에 드러난다는 데 있습니다.
LangGraph는 LangChain 없이도 사용할 수 있습니다. 이미 공급자 SDK와 자체 함수가 있다면 이를 노드 안에서 호출할 수 있습니다. 또한 그래프 데이터베이스나 지식 검색 엔진을 뜻하지 않습니다. 여기서 그래프는 주로 실행을 조직하는 구조입니다. 단일 에이전트의 흐름을 제어하는 데도 쓸 수 있으므로, 반드시 멀티에이전트 앱이어야 하는 것은 아닙니다.
단순한 도구 호출 루프에서 고정된 승인 순서·여러 분기·병렬 작업·복구 요구로 넘어갈 때 직접 그래프를 다룰 이유가 커집니다. 반대로 LangChain의 기본 에이전트와 미들웨어로 요구사항을 표현할 수 있다면, 낮은 수준의 그래프를 직접 작성할 필요가 없을 수 있습니다.
메모리는 대화 기록 하나로 끝나지 않습니다
영화 촬영에서 “이 장면은 승인을 기다린다”는 진행표와 “이 배우는 특정 소품을 사용할 수 없다”는 인물 자료는 쓰임이 다릅니다. 에이전트에서도 현재 작업의 상태와 여러 작업에서 공유할 정보는 나눠 생각해야 합니다.
LangGraph의 체크포인터는 특정 실행 맥락인 스레드의 상태 스냅샷을 저장합니다. 교환 문의 한 건이 승인 대기 중이었다면 그 상태를 이어 가는 데 필요합니다. 스토어는 여러 스레드에 걸쳐 사용할 정보를 저장하는 별도 수단입니다. 공식 영속성 문서는 두 가지를 구분합니다.
파란 진행표와 초록 진행표를 합쳐 버리면 어느 장면이 어디까지 끝났는지 헷갈립니다. 그래서 문의마다 진행 상태를 따로 둡니다. 반면 여러 장면에서 참고할 인물 자료는 공통 자료함에 둘 수 있습니다. 마지막 장면처럼 기록 속 소품과 실제 선반이 다를 수 있으므로, 잘 기억하는 기능과 최신 사실을 확인하는 기능도 구분해야 합니다.
메모리에 넣었다고 모두 최신 진실이 되는 것은 아닙니다. 예전 문의에서 가져온 주문 상태는 지금 바뀌었을 수 있습니다. 접수 직전에는 업무 시스템을 다시 조회하고, 고객별 접근 권한을 확인하도록 앱을 설계해야 합니다. 저장한 대화를 전부 모델 입력에 넣으면 비용과 문맥 부담도 커지므로 필요한 상태만 전달하는 정책이 필요합니다.
복구하려면 실제 영속 저장소도 필요합니다. 메모리 안에만 저장하는 체크포인터는 프로세스가 종료되면 상태를 잃습니다. 그리고 저장과 재개가 외부 업무의 ‘정확히 한 번 처리’를 보장하지는 않습니다. 교환 접수 API가 성공한 직후 연결이 끊겼다면 같은 요청을 재실행할 때 중복 접수를 막아야 합니다.
사람 승인도 같은 주의가 필요합니다. interrupt 문서에 따르면 중단한 노드는 재개 과정에서 처음부터 다시 실행될 수 있습니다. 승인을 기다리기 전에 결제를 취소하거나 접수 레코드를 만들면 반복될 위험이 있습니다. 승인과 외부 변경 단계를 구분하고, 업무 API에 중복 방지 식별자를 적용하는 설계가 필요합니다. 승인은 ‘잠깐 멈추기’뿐 아니라 어떤 변경을 허용했는지를 남기는 일입니다.
LangSmith: 오답을 발견한 다음부터 필요해집니다
앱이 “교환 가능합니다”라고 답했는데 실제 정책은 달랐다고 해 보겠습니다. 마지막 답변만 저장해 두었다면 원인을 알기 어렵습니다. 엉뚱한 정책을 검색했는지, 주문 조회가 실패했는지, 맞는 근거를 받아 놓고 모델이 잘못 해석했는지 구분해야 합니다.
LangSmith의 추적은 요청 안에서 일어난 모델·도구 등의 실행을 연결해서 볼 수 있게 합니다. 하나의 전체 작업 경로를 트레이스라고 하고, 그 안의 개별 작업을 런이라고 이해하면 됩니다. 고객의 이어지는 대화를 묶어 보는 스레드와는 단위가 다릅니다. 관측 개념 문서에서 이 관계를 설명합니다.
위 사례라면 정책 검색의 입력과 반환 문서, 주문 조회의 결과, 최종 모델 입력을 순서대로 살핍니다. 오래된 문서가 검색됐다면 모델 프롬프트만 바꾸는 것은 해결책이 아닐 수 있습니다. 올바른 문서를 읽고도 예외 조건을 놓쳤다면 생성 단계의 지시나 검증을 바꿀 이유가 생깁니다. 이 구분은 트레이스를 바탕으로 개발자가 내리는 진단입니다.
LangSmith는 LangChain 전용 모니터가 아닙니다. 공식 관측 안내는 여러 프레임워크와 공급자의 연동을 제공합니다. 자체 SDK로 만든 앱에 필요한 추적을 계측해 사용할 수도 있습니다. 반대로 LangChain이나 LangGraph를 쓴다고 LangSmith 가입이 필수는 아닙니다. 기존 관측 도구로 필요한 정보를 충분히 얻고 있다면 도입의 추가 가치를 비교하면 됩니다.
관측은 “무슨 일이 있었나”, 평가는 “더 나아졌나”
실패한 촬영본을 찾았다고 다음 촬영이 좋아졌다는 뜻은 아닙니다. 정책 검색을 고친 뒤에도 기존에 잘 답하던 질문이 망가졌는지 확인해야 합니다. 이때 평가용 데이터셋이 필요합니다.
첫 두 장면에서는 “어디서 잘못됐지?”를 묻습니다. 뒤의 두 장면에서는 “바꾼 뒤에도 같은 조건에서 잘되나? 다른 장면은 망가지지 않았나?”를 묻습니다. 교환 상담에 대입하면, 잘못 가져온 정책을 찾아내는 것이 진단이고 같은 문의 묶음으로 수정 전후를 비교하는 것이 평가입니다.
교환 문의라면 일반 교환, 예외 승인, 주문 정보 부족, 정책에 답이 없는 질문을 함께 넣을 수 있습니다. 문장이 그럴듯한지만 보지 않고, 필요한 경우 조회 도구를 사용했는지, 모르는 조건을 고객에게 물었는지, 승인 전에 접수를 실행하지 않았는지를 따로 봅니다. 이는 이 사례에 맞춰 설계한 평가 기준입니다.
LangSmith 평가 기능은 준비한 데이터로 버전을 비교하는 오프라인 평가와 실제 운영 상호작용을 살피는 온라인 평가를 지원합니다. 여기서 오프라인은 인터넷 연결 여부가 아니라 운영 트래픽과 분리한 평가를 뜻합니다. 평가자는 코드 규칙·사람·LLM 기반 채점 등으로 구성할 수 있습니다.
- 추적잘못된 답변에서 검색 문서와 도구 결과를 거슬러 올라갑니다.
- 사례화민감 정보를 정리하고 기대 행동을 적어 평가 데이터에 넣습니다.
- 동일 조건 비교기존 버전과 수정 버전을 같은 사례들로 평가합니다.
- 운영 확인회귀 여부를 검토한 뒤 실제 문의에서도 같은 실패가 줄었는지 관찰합니다.
평가 플랫폼이 정답의 기준을 대신 정해 주지는 않습니다. ‘정중한 답변’ 점수만 높게 잡으면 정책을 틀리게 안내한 친절한 답변이 통과할 수 있습니다. LLM 채점 역시 오판할 수 있으므로, 승인 순서나 중복 접수처럼 프로그램으로 확인할 수 있는 조건은 별도 규칙으로 검증하는 편이 좋습니다.
도입 비용에는 호출료 밖의 일도 들어갑니다
LangChain과 LangGraph를 사용한다고 모델 호출료가 없어지는 것은 아닙니다. 에이전트가 도구를 여러 번 선택하면 지연과 호출 비용이 누적됩니다. 그래프를 세밀하게 나누면 제어하기 쉬워질 수 있지만 상태 스키마와 저장소, 오류 복구를 관리하는 일도 생깁니다. 추상화의 이익과 디버깅 부담을 함께 판단해야 합니다.
LangSmith도 필요한 기록량과 평가 실행량을 정해야 합니다. 모든 운영 사례에 LLM 채점을 붙이면 평가 자체의 모델 비용이 발생할 수 있습니다. 구체적인 과금 단가는 변하므로 도입 시점의 요금·보존 기간·배포 방식에 맞춰 계산해야 합니다. 이 글의 선택 기준은 특정 무료 제공량을 전제로 하지 않습니다.
상담 내용과 주문 결과가 트레이스에 들어가면 기록 범위도 설계 대상이 됩니다. LangSmith의 민감 정보 처리 문서는 입력·출력 로깅을 숨기거나 마스킹하는 방법을 안내합니다. 주문 원문을 전부 남기는 대신 진단에 필요한 상태와 식별 정보의 범위를 정하고, 누가 기록에 접근하는지 검토해야 합니다. 관측 가능성을 높이려다 불필요한 고객 정보까지 복제할 이유는 없습니다.
다른 도구로 옮길 가능성도 고려할 만합니다. 정책 판정과 주문 처리 같은 업무 로직을 프레임워크 밖의 함수로 유지하고, 평가 사례를 별도 데이터로 관리하면 이동할 때 다시 만들어야 할 범위를 줄일 수 있습니다. 한편 체크포인트나 복잡한 그래프 실행 방식에 깊이 의존할수록 교체 작업은 커집니다. 이는 기능 결함보다 선택한 추상화에 따른 설계 비용입니다.
쓸모없다는 비판과 유용하다는 경험 사이
단순한 모델 호출을 여러 추상화로 감싸면 프롬프트와 응답을 찾기 어려워지고, 의존성과 버전 변경을 관리하는 부담이 생깁니다. 이런 운영 복잡성에 대한 비판은 실제 선택에서 검토할 만합니다. 기능이 작고 팀이 공급자 SDK에 익숙하다면, 추가 개념을 배우는 비용이 편의보다 클 수 있습니다.
반면 같은 논의에는 높은 수준의 래퍼는 줄이되 LangGraph의 상태 저장·체크포인트·스트리밍은 남겼다는 경험도 있습니다. 실행을 조율하는 부분만 얇게 사용하고 업무 로직과 검증은 직접 유지하는 방식도 가능합니다. 전부 채택하거나 전부 버리는 선택만 있는 것은 아닙니다. 이러한 경험담은 팀별 판단 사례이며 모든 환경에서의 효과를 입증하지는 않습니다.
과거 버전에서 겪은 API 변경과 현재 버전의 기능도 구분해야 합니다. 예를 들어 LangChain은 단순 체인만 지원한다는 설명은 현재 에이전트 구조와 맞지 않습니다. 반대로 라이브러리를 설치하면 무관한 패키지가 언제나 함께 들어온다고 단정할 수도 없습니다. 실제로 설치할 패키지와 통합 모듈, 버전을 확인해야 합니다. 비판의 강도보다 우리 앱에서도 같은 유지보수 문제가 생기는지가 중요합니다.
직접 만든 작은 구현도 영구히 가볍지는 않습니다. 처음에는 함수 몇 개였어도 재시도, 저장, 승인과 추적이 계속 붙으면 팀이 자체 실행기를 유지하는 일이 됩니다. 이미 그 기능을 잘 갖춘 팀이라면 외부 프레임워크의 이익이 작을 수 있고, 반복해서 새로 만드는 팀이라면 재사용의 이익이 커질 수 있습니다. 자체 코드와 프레임워크 양쪽의 유지비를 같은 기준으로 비교해야 합니다.
실제 도입 사례에서 볼 것은 회사 이름보다 문제입니다
LangChain이 공개한 Replit Agent 개발 사례는 단순 질의응답보다 긴 코드 작성과 도구 실행을 다룹니다. 이 사례에는 주요 단계의 변경을 되돌릴 수 있게 남기고, 사용자가 중간에 개입하며, 긴 실행 기록에서 문제 지점을 찾는 요구가 등장합니다. LangGraph와 LangSmith를 함께 사용한 맥락은 “더 좋은 문장을 만들기”보다 길게 이어지는 작업을 수정하고 진단하기에 가깝습니다.
이 사례를 Replit의 현재 모든 내부 구조에 대한 설명이나 프레임워크의 성능 비교로 읽으면 범위를 벗어납니다. 공급자가 공개한 고객 사례에는 선택한 도구의 장점이 강조됩니다. 제가 가져올 판단 기준은 큰 회사가 쓴다는 사실보다, 우리 앱에도 되돌리기·중간 개입·긴 실행의 진단이 필요한가입니다.
LangGraph 개발팀의 런타임 설계 설명도 긴 작업을 처음부터 다시 실행하는 비용, 병렬 처리, 체크포인트와 사람의 개입을 주요 문제로 제시합니다. 짧은 단일 호출에는 프레임워크가 필요하지 않을 수 있다고 함께 설명합니다. 활용 사례가 있다는 것과 모든 프로젝트가 같은 구조를 써야 한다는 것은 다릅니다.
어떤 프로젝트에서 어느 부분이 필요할까요
교환 문의 앱을 세 단계로 나눠 보면 선택이 선명해집니다. 정책 문서를 검색해 답하는 기능이라면 검색 함수와 모델 호출로 시작할 수 있습니다. 주문 조회 등 여러 도구를 상황에 따라 사용하고 공통 실행 정책을 관리해야 한다면 LangChain이 후보입니다. 예외 주문을 담당자가 승인할 때까지 기다렸다가 재개해야 하고 경로가 복잡해지면 LangGraph를 직접 다룰 이유가 커집니다.
이때 LangChain의 기본 에이전트와 미들웨어만으로 승인이나 호출 제한을 표현할 수 있다면 그것으로 충분할 수 있습니다. 승인 한 단계가 있다고 무조건 저수준 그래프부터 작성할 필요는 없습니다. 필요한 제어 수준이 기존 구성으로 표현되지 않을 때 내려가는 선택입니다.
긴 보고서를 만드는 서비스도 후보가 될 수 있습니다. 여러 자료를 독립적으로 수집하고, 근거가 부족한 부분만 추가 조사하고, 결과를 모아 승인 뒤 저장한다면 분기·합류·재개가 의미를 갖습니다. 다만 항상 ‘수집 → 추출 → 저장’으로 끝나는 정해진 배치 작업이라면 기존 작업 큐나 워크플로 실행기에 모델 호출을 넣는 방식도 검토할 수 있습니다. AI가 포함됐다는 이유로 운영 구조까지 전부 바꿀 필요는 없습니다.
LangSmith는 이 순서의 마지막 학습 단계가 아닙니다. 작은 문서 답변 앱도 검색과 생성 중 어디에서 오답이 생겼는지 모르겠다면 추적이 필요할 수 있습니다. 이미 쓰는 로그·관측 도구와 자체 평가 데이터로 충분히 진단한다면 그것을 유지할 수 있습니다. LangSmith라는 제품과 실행을 관찰하고 품질을 평가해야 한다는 요구도 나눠 생각해야 합니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 문서 요약·검색 답변 | SDK와 일반 함수부터 | 실행이 짧고 경로가 정해져 있다면 간단하게 구성할 수 있습니다. | 문서 검색 → 근거 전달 → 답변 생성과 결과 기록 |
| 여러 도구와 공통 규칙 | LangChain 검토 | 모델·도구 연결과 호출 전후 정책을 반복해서 작성하는 부담을 비교합니다. | 정책 검색·주문 조회 도구와 호출 제한·오류 처리 구성 |
| 긴 대기·복잡한 분기 | LangGraph 검토 | 상태 저장과 합류·승인·재개를 더 세밀하게 제어해야 합니다. | 예외 주문 승인 대기 → 상태 확인 → 중복 없이 처리 재개 |
| 오답 진단·변경 비교 | LangSmith 등 관측·평가 | 앱 크기와 관계없이 실패 경로와 수정 효과를 확인해야 합니다. | 잘못 검색된 정책을 추적하고 같은 문의 묶음으로 전후 평가 |
| 이미 운영 중인 배치 | 기존 워크플로도 후보 | 큐·재시도·저장이 있다면 필요한 단계에 모델 호출을 더할 수 있습니다. | 정해진 문서 추출·형식 검사·저장 작업에 AI 일부만 사용 |
최적화는 같은 작업으로 비교해야 합니다
빠른 응답이 목표라면 서로 독립적인 조회를 병렬로 실행하거나 불필요한 모델 호출을 없애는 방법을 비교합니다. 비용이 목표라면 실패한 단계만 다시 실행해 재작업을 줄일 수 있는지 봅니다. LangGraph가 자동으로 모델을 빠르거나 싸게 만드는 것은 아닙니다. 구조를 바꿔 줄일 수 있는 대기·재시도·개발 작업이 있는가가 핵심입니다.
교환 앱이라면 같은 문의 묶음으로 간단한 구현과 도입 후보를 비교할 수 있습니다. 정책 판정과 도구 선택의 품질, 승인 전 실행 여부, 중단 뒤 재개, 중복 접수 여부를 확인하고, 완료된 문의 한 건의 지연과 호출 비용·검토 시간을 함께 기록합니다. 이는 도입을 판단하기 위한 비교 설계입니다. 이 글에서 실제 성능 우열을 측정한 결과는 아닙니다.
품질이 비슷하고 유지보수만 늘었다면 도입 이유는 약합니다. 반대로 기존 구현에서 복구와 승인 코드를 계속 새로 만들고 있었다면, 런타임을 사용해 그 부담을 줄일 여지가 있습니다. 기준을 같은 데이터로 남겨 두면 모델이 더 좋아졌을 때 구조를 다시 단순화할지도 판단할 수 있습니다.
저라면 작은 기능에 세 가지를 한꺼번에 들이지 않겠습니다. 모델과 일반 함수로 해결되는 범위를 먼저 확인하고, 공통 구성이 반복되면 LangChain, 더 세밀한 상태와 실행 제어가 필요하면 LangGraph, 실패 원인과 변경 효과가 보이지 않으면 LangSmith 같은 도구를 검토하겠습니다. 추적과 평가는 앱의 문제에 따라 일찍 시작할 수 있습니다.
영화를 한 장면 찍는데 거대한 스튜디오부터 지을 필요는 없습니다. 하지만 대기 장면과 재촬영이 쌓이면 진행표가 필요하고, 결과가 나쁜 이유를 모르면 촬영본을 되짚어야 합니다. 모델이 좋아질수록 불필요한 구조를 줄여 볼 이유는 커집니다. 그때도 남는 승인·복구·검증 문제를 해결하는 도구는 여전히 쓸 자리가 있습니다.
VIEW—
