LangGraph 도입 2026 — 프레임워크 선택·비용·외주 범위 7단계
LangGraph 도입에서 결정해야 하는 것은 사용법이 아니라 경계입니다. 프레임워크가 필요한 문제인지, 요청당 모델 호출 횟수로 본 실제 비용, 상태 저장과 사람 승인 설계, 평가셋 합격 기준으로 하자 범위를 닫는 법을 발주처 기준으로 정리했습니다.
LangGraph는 LLM 애플리케이션의 실행 흐름을 그래프로 짜는 프레임워크다. 노드가 작업 단위이고 엣지가 다음에 무엇을 할지 정한다. 조건 분기와 되돌아가기가 되기 때문에, 한 번 묻고 한 번 답하는 구조를 넘어선 흐름을 만들 때 쓴다.
이 글은 LangGraph 사용법을 가르치지 않는다. 그건 공식 문서와 튜토리얼에 충분히 있다. 여기서 다루는 것은 LangGraph로 무언가를 만들기로 결정하는 쪽이 판단해야 하는 것들이다. 이게 필요한 문제인지, 비용이 어디서 나오는지, 외주를 준다면 범위를 어떻게 닫는지, 인도받은 뒤 누가 고칠 수 있는지.
먼저 판단할 것 — LangGraph가 필요한 문제인가
프레임워크를 고르기 전에 문제의 형태를 본다. 과하게 고르면 유지보수 비용만 늘어난다.
| 만들려는 것 | 적정 수준 |
| 문서를 찾아 답하는 챗봇 | 단순 RAG. 프레임워크 없이도 된다 |
| 질문 유형에 따라 다른 처리 | 분기 몇 개. 직접 코드로 충분 |
| 여러 단계를 거치고 중간에 되돌아감 | ✅ LangGraph |
| 사람 승인을 중간에 끼워야 함 | ✅ LangGraph |
| 실패 시 다른 경로로 재시도 | ✅ LangGraph |
| 여러 에이전트가 역할을 나눠 협업 | ✅ LangGraph |
| 정해진 순서로 SaaS를 연결만 함 | 워크플로우 도구가 낫다 |
마지막 줄이 중요하다. 단순 연결이면 n8n 같은 워크플로우 도구가 더 싸고 빠르다. LangGraph는 코드로 짜는 프레임워크라 만드는 데도 고치는 데도 개발자가 필요하다. 흐름이 조건 분기 몇 개로 끝난다면 도입 이유가 약하다.
반대로 되돌아가기가 필요하면 워크플로우 도구로는 안 된다. 검색 결과가 부족해 다시 질의를 만들거나, 검증에 실패해 앞 단계로 돌아가는 구조는 그래프가 있어야 표현된다.
LangChain·LangGraph·에이전트 프레임워크의 관계
이름이 비슷해 혼동이 잦다.
| 무엇인가 | 언제 쓰나 |
| LangChain | LLM 호출·문서 처리 유틸 모음 | 부품이 필요할 때 |
| LangGraph | 실행 흐름을 그래프로 정의 | 흐름에 분기·순환이 있을 때 |
| LangSmith | 실행 추적·평가 도구 | 운영 중 문제를 볼 때 |
| CrewAI | 역할 기반 에이전트 협업 | 역할 분담이 곧 설계일 때 |
LangGraph는 LangChain을 반드시 요구하지 않는다. 흐름 정의만 가져다 쓰고 나머지는 직접 구현해도 된다. 발주 문서에 "LangChain 기반"이라고만 적으면 무엇을 쓰는지 불명확해지므로, 어느 계층을 쓰는지 구분해 적는 편이 낫다.
여러 에이전트를 어떻게 나눌지는 멀티 에이전트 시스템 구축 가이드에서 다룬다.
비용은 어디서 나오는가
프레임워크 자체는 오픈소스라 라이선스 비용이 없다. 실제 비용은 네 갈래다.
| 항목 | 성격 | 주의 |
| LLM API | 사용량 비례 | 그래프는 한 요청에 모델을 여러 번 부른다 |
| 벡터 DB·검색 | 사용량 또는 서버 | 문서량과 갱신 빈도로 결정 |
| 서버 | 고정 | 상태 저장이 필요하면 DB도 |
| 구축·운영 인건비 | 1회성 + 지속 | 프롬프트와 흐름은 계속 바뀐다 |
첫 줄이 가장 자주 빗나간다. 그래프는 한 번의 사용자 요청에 모델을 여러 번 호출한다. 의도 분류 한 번, 검색 질의 생성 한 번, 답변 생성 한 번, 검증 한 번이면 이미 네 번이다. 여기에 재시도가 붙으면 더 늘어난다. 단순 챗봇 기준으로 비용을 잡아 두면 실제 청구서가 몇 배로 나온다.
토큰 길이도 같이 본다. 검색한 문서를 통째로 넣는 구성이면 호출 한 번의 입력이 수천 토큰이 되고, 그게 요청마다 네 번 반복된다. 값싼 모델로 분류와 검증을 돌리고 답변 생성만 상위 모델에 맡기는 식으로 나누면 같은 흐름에서 비용이 크게 내려간다. 이 구분은 설계 단계에서 해야 하고, 나중에 바꾸면 프롬프트를 전부 다시 맞춰야 한다.
견적을 받기 전에 이 세 가지를 숫자로 정해 두면 비교가 성립한다.
- 요청당 예상 모델 호출 횟수 — 흐름도를 그려 노드를 세면 나온다
- 월 예상 요청 수 — 사용자 수 × 1인당 사용 빈도
- 문서량과 갱신 주기 — 벡터 DB 비용과 재색인 부담이 여기서 나온다
상태를 어디에 저장할 것인가
LangGraph는 실행 상태를 저장한다. 이 선택이 운영 성격을 결정한다.
| 저장 위치 | 되는 것 | 한계 |
| 메모리 | 가장 간단 | 프로세스가 죽으면 소실, 서버 여러 대면 불가 |
| DB(Postgres 등) | 재시작 후 이어가기, 다중 서버 | DB 운영 부담 |
| 관리형 서비스 | 운영 부담 없음 | 데이터가 외부로 나감 |
대화가 여러 번에 걸치거나 사람 승인을 기다리는 구조라면 메모리로는 안 된다. 승인을 기다리는 동안 서버가 재시작되면 그 건은 사라진다. 이 요건을 발주 단계에서 정하지 않으면 착수 후에 구조를 바꾸게 된다.
데이터가 외부로 나가도 되는지는 AI 도입 데이터 거버넌스·개인정보 체크리스트의 기준으로 판단한다.
사람 승인을 어디에 넣을 것인가
LangGraph를 고르는 큰 이유 중 하나가 중간에 사람을 끼울 수 있다는 점이다. 어디에 넣을지는 업무가 정한다.
| 승인이 필요한 경우 | 예 |
| 되돌릴 수 없는 작업 | 메일 발송, 결제, 외부 시스템 쓰기 |
| 금액이 걸린 판단 | 견적 확정, 할인 적용 |
| 대외 문서 | 고객에게 나가는 답변, 공문 |
| 규정 해석 | 법령·사내 규정 적용 결과 |
승인 단계를 넣으면 그 지점에서 흐름이 멈추고 기다린다. 그래서 앞 절의 상태 저장이 필요해진다. 승인 대기 건을 누가 어디서 보는지(관리 화면인지 슬랙인지), 며칠 지나면 어떻게 할지도 같이 정한다.
반대로 승인을 너무 많이 넣으면 자동화한 의미가 없어진다. 판단 기준은 틀렸을 때 되돌릴 수 있는가다. 되돌릴 수 있는 작업은 통과시키고 사후에 확인하는 편이 빠르다. 내부 조회나 초안 작성처럼 결과를 사람이 어차피 한 번 더 보는 단계에 승인을 또 넣으면 대기만 쌓인다.
검증하지 않으면 운영에서 무너진다
LLM 애플리케이션은 코드가 그대로여도 결과가 달라진다. 배포 전에 아래를 정해 둔다.
| 항목 | 정할 것 |
| 평가셋 | 실제 질문 몇 건을 정답과 함께 고정 |
| 합격 기준 | 정확도 몇 %, 어떤 오류는 허용 안 됨 |
| 회귀 확인 | 프롬프트를 고쳤을 때 이전 건이 안 깨지는지 |
| 추적 | 어떤 경로로 그 답이 나왔는지 볼 수 있는지 |
| 비용 관측 | 요청당 호출 수와 토큰이 기록되는지 |
첫 줄이 없으면 나머지가 성립하지 않는다. 평가셋 없이 "좋아졌다"를 말할 수 없다. 프롬프트를 고치면 어떤 질문은 나아지고 어떤 질문은 나빠지는데, 고정된 평가셋이 없으면 그 교환을 볼 방법이 없다. 눈에 띄는 몇 건만 보고 판단하면 고칠 때마다 다른 곳이 깨지는 상태가 이어진다.
건수는 많을 필요가 없다. 실제로 들어올 질문 유형별로 두세 건씩, 합쳐 30~50건이면 회귀는 잡힌다. 중요한 것은 정답을 사람이 미리 적어 두는 것이다. 결과를 보고 정답을 정하면 평가가 아니라 사후 합리화가 된다.
발주 시 산출물에 평가셋과 평가 결과를 포함시키면 인수 기준이 명확해진다. 검수 기준을 문서로 닫는 방법은 테스트 케이스 작성법에 정리했다.
외주 발주서에 적을 것
LangGraph 기반 개발을 맡길 때 범위를 닫는 항목들이다.
| 항목 | 적는 법 |
| 흐름 정의 | 노드 개수 또는 처리 시나리오 수. 「AI 에이전트 구축」은 경계가 없다 |
| 연동 대상 | 시스템 이름과 API 문서 유무 |
| 상태 저장 | 메모리/DB/관리형 중 무엇인지, 서버는 누가 |
| 사람 승인 | 어느 단계에 넣는지, 대기 건을 어디서 보는지 |
| 모델 | 어느 모델을 쓰는지, 비용은 누가 부담하는지(개발 중/운영 중 구분) |
| 평가셋 | 몇 건, 합격 기준 몇 % |
| 산출물 | 소스코드, 흐름도, 프롬프트 원문, 평가 결과 |
| 인수인계 | 프롬프트 수정 방법 교육 몇 시간 |
| 하자 범위 | 「흐름이 안 도는 것」과 「답변 품질이 마음에 안 드는 것」의 경계 |
마지막 줄이 이 분야 특유의 분쟁 지점이다. 답변이 틀렸다는 것과 시스템이 고장 났다는 것은 다르다. 평가셋 합격 기준을 계약에 적어 두면 이 경계가 숫자로 닫힌다. 그게 없으면 인도 후 모든 품질 불만이 하자보수 요구로 들어온다. 하자와 추가 개발을 나누는 방법은 소스코드 에스크로·하자보수 계약에, 산출물 목록을 문서로 닫는 방법은 과업지시서 작성법에 있다.
인도받은 뒤 누가 고치나
LangGraph 프로젝트에서 가장 자주 나오는 문제다. 업무가 바뀌면 프롬프트와 분기가 바뀌는데, 그때마다 외주를 부르면 비용이 계속 붙는다.
| 바뀌는 것 | 난이도 | 사내에서 가능한가 |
| 프롬프트 문구 | 낮음 | ✅ 파일만 고치면 된다 |
| 분기 조건 값 | 낮음 | ✅ 설정으로 빼 두면 |
| 노드 추가·삭제 | 중간 | 개발자 필요 |
| 상태 구조 변경 | 높음 | 개발자 필요 |
앞의 두 줄을 코드 밖으로 빼 달라고 발주 단계에서 요구하면 운영 비용이 크게 줄어든다. 프롬프트를 소스 안에 하드코딩해 두면 문구 한 줄 바꾸는 데도 배포가 필요하다. 설정 파일이나 DB로 분리하는 것은 구축 시점에 하면 비용이 거의 안 들지만, 나중에 하면 구조 변경이 된다.
도입 7단계
| 단계 | 할 일 | 산출 |
| 1 | 처리할 시나리오를 목록으로 | 시나리오 목록 |
| 2 | 사람 승인이 필요한 지점 표시 | 승인 지점 |
| 3 | 흐름도를 그려 노드를 센다 | 흐름도 · 호출 횟수 추정 |
| 4 | 평가셋 작성(정답 포함) | 평가셋 |
| 5 | 시나리오 1개로 시범 구축 | 파일럿 · 실측 비용 |
| 6 | 나머지 확장 + 평가 반복 | 전체 흐름 |
| 7 | 프롬프트 분리 + 수정 교육 | 인수인계 |
4번을 5번보다 먼저 두는 것이 핵심이다. 만들고 나서 평가셋을 짜면 만든 것에 맞춰 기준이 생긴다. 순서를 바꾸면 그 시스템이 실제로 쓸 만한지 판정할 수 없다.
흔한 실수 다섯 가지
| 실수 | 결과 | 대응 |
| 단순 분기에 프레임워크 도입 | 유지보수 비용만 증가 | 되돌아가기가 필요한지부터 확인 |
| 모델 호출 횟수 미산정 | 운영비가 견적의 몇 배 | 흐름도 노드 수 × 월 요청 수 |
| 상태를 메모리에만 저장 | 재시작 시 대기 건 소실 | 승인 대기가 있으면 DB 필수 |
| 평가셋 없이 인수 | 품질 분쟁이 하자 요구로 | 합격 기준을 계약에 숫자로 |
| 프롬프트 하드코딩 | 문구 한 줄에 배포 필요 | 설정으로 분리 요구 |
트리숲이 LangGraph 프로젝트를 다루는 방식
트리숲은 LangGraph 문의를 받으면 먼저 이게 프레임워크가 필요한 문제인지부터 확인한다. 가져오시는 요구의 상당수는 조건 분기 두세 개로 끝나고, 그런 경우 직접 코드로 짜는 편이 만들기도 고치기도 쉽다. 프레임워크는 흐름에 순환이 있을 때 값을 한다.
비용은 흐름도를 먼저 그려 노드 수로 역산한다. 요청 하나에 모델을 몇 번 부르는지가 운영비를 결정하는데, 이건 설계가 끝나야 나오는 숫자다. 그래서 파일럿 한 건을 먼저 만들어 실측한 뒤 전체 규모를 잡는다.
인수인계는 프롬프트와 분기 값을 코드 밖으로 빼는 것을 기본으로 한다. 업무가 바뀌면 문구가 바뀌는데, 그때마다 배포가 필요하면 발주처가 아무것도 못 고치는 상태가 된다. 견적 산정 근거를 맞추는 방법은 기능점수(FP) 기반 비용 산정에 정리해 두었다.
자주 묻는 질문
LangGraph 없이도 만들 수 있나요?
가능하다. 조건 분기 몇 개로 끝나는 흐름이면 직접 코드로 짜는 편이 낫다. 프레임워크가 값을 하는 것은 되돌아가기, 사람 승인 대기, 실패 시 다른 경로 같은 구조가 필요할 때다.
LangChain을 꼭 같이 써야 하나요?
아니다. LangGraph는 흐름 정의 부분이고 나머지는 직접 구현해도 된다. 발주 문서에는 어느 계층을 쓰는지 구분해 적는 편이 낫다.
비용이 얼마나 나오나요?
요청당 모델 호출 횟수 × 월 요청 수로 추정한다. 그래프는 한 요청에 모델을 여러 번 부르므로 단순 챗봇 기준으로 잡으면 크게 빗나간다. 흐름도를 그려 노드를 세는 것이 가장 정확하다.
만든 뒤 사내에서 고칠 수 있나요?
프롬프트 문구와 분기 조건은 설정으로 빼 두면 가능하다. 노드를 추가하거나 상태 구조를 바꾸는 것은 개발자가 필요하다. 앞의 두 가지를 분리해 달라고 발주 단계에서 요구하는 것이 좋다.
품질이 기대와 다르면 하자보수인가요?
평가셋 합격 기준을 계약에 적어 두었다면 그 기준 미달이 하자다. 기준이 없으면 「답변이 마음에 안 든다」와 「시스템이 고장 났다」가 구분되지 않아 분쟁이 된다.
정리
LangGraph 도입에서 실제로 결정해야 하는 것은 사용법이 아니라 경계다. 프레임워크가 필요한 문제인지, 상태를 어디에 저장할지, 사람 승인을 어디에 끼울지, 하자와 품질 불만을 무엇으로 가를지.
발주 전에 세 가지를 숫자로 정해 두면 견적이 흔들리지 않는다. 요청당 모델 호출 횟수, 월 예상 요청 수, 평가셋 건수와 합격 기준이다. 여기에 프롬프트를 코드 밖으로 빼는 것을 산출물에 넣으면 인도 후 운영 비용이 크게 줄어든다.
RAG 기반 챗봇을 만들 때의 구성은 RAG 챗봇 개발 가이드에서 다룬다.