랭스미스·랭체인·랭그래프: 개발자가 LLM 앱을 “제품”으로 만드는 3단계 도구

LLM으로 챗봇을 만들면 처음엔 금방 됩니다. 그런데 며칠만 지나도 이런 문제가 터져요. 프롬프트가 여기저기 흩어지고, 대화 흐름이 꼬이고, 어느 단계에서 왜 답이 이상해졌는지 추적이 안 됩니다.

한 줄 요약: 역할 분담이 핵심

• 랭체인: LLM 앱의 *부품(체인/도구/프롬프트)*을 빠르게 조립하는 프레임워크
• 랭그래프: 상태와 분기를 가진 대화/에이전트 흐름을 그래프로 설계
• 랭스미스: 실행 기록을 기반으로 디버깅, 테스트, 품질 점검을 돕는 도구

랭체인: “조립 가능한” LLM 개발 기본기

랭체인은 개발자가 자주 쓰는 패턴—프롬프트 템플릿, 출력 파서, 도구 호출, 검색 기반 질의(RAG) 같은—을 모듈화해둔 느낌입니다. 특히 “한 번 만든 흐름을 코드로 재사용”하기가 쉬워요.

언제 유용할까?

• 사내 문서 검색 기반 Q&A(RAG) 프로토타입
• 규칙이 있는 요약/분류 파이프라인
• 함수 호출(툴 호출)과 LLM 응답을 엮는 작업

미니 예시: 문서 기반 Q&A 뼈대(개념 코드)

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

llm = ChatOpenAI(model="gpt-4o-mini")

prompt = ChatPromptTemplate.from_messages([
    ("system", "너는 개발 문서 도우미야. 근거가 없으면 모른다고 말해."),
    ("user", "질문: {q}\n\n참고문서:\n{context}")
])

chain = prompt | llm | StrOutputParser()

answer = chain.invoke({
    "q": "랭그래프는 왜 필요해?",
    "context": "- 랭그래프는 상태/분기/루프를 그래프로 표현...\n- 복잡한 에이전트 흐름..."
})
print(answer)

핵심은 프롬프트 → 모델 → 파싱이 파이프로 이어지고, 각 단계가 교체 가능하다는 점입니다.

랭그래프: 에이전트를 “상태 머신”처럼 다루기

랭체인만으로도 많은 걸 만들 수 있지만, 에이전트가 복잡해지면 이런 요구가 생깁니다.

• 사용자의 의도를 분류해서 분기하고 싶다
• 도구 호출이 실패하면 재시도하고 싶다
• 특정 조건이면 루프를 돌며 추가 질문을 하고 싶다
• 대화 상태(메모리/중간 결과)를 명시적으로 관리하고 싶다 이때 랭그래프는 대화 흐름을 노드(node)와 엣지(edge)로 구성해 그래프 기반 실행을 가능하게 합니다. “그때그때 프롬프트로 땜질”이 아니라, 흐름 자체를 설계하는 느낌이 강해요.

예시 시나리오: 개발 Q&A 에이전트

1. 질문 분류(일반/버그/아키텍처)
2. 버그면: 재현 정보 질문 → 로그 요약 → 원인 후보 도출
3. 아키텍처면: 제약조건 수집 → 대안 비교 → 결론 이런 흐름을 그래프로 만들면, 어디서 어떤 상태로 넘어갔는지가 분명해지고 유지보수가 쉬워집니다.

랭스미스: “왜 이런 답이 나왔지?”를 끝까지 추적

LLM 앱을 운영하다 보면 가장 힘든 게 이거예요.

• 같은 질문인데 답이 매번 달라요(비결정성)
• 어느 단계에서 프롬프트/도구 입력이 잘못됐는지 감이 없어요
• 개선했는데 실제로 나아졌는지 기준이 없어요 랭스미스는 실행을 트레이싱 형태로 기록해, 각 단계 입력/출력, 지연 시간, 실패 지점을 확인하는 데 도움을 줍니다. 그리고 케이스를 모아 회귀 테스트처럼 비교해볼 수도 있어요. 개발자 입장에서는 “감”이 아니라 기록 기반으로 수정할 수 있다는 게 가장 큽니다.

세 도구를 같이 쓰는 추천 흐름

1) 랭체인으로 빠르게 기능을 묶는다

• 프롬프트 템플릿 정리
• 도구(검색, DB, 사내 API) 연결
• 출력 형태(JSON 등) 강제

2) 랭그래프로 서비스 로직을 구조화한다

• 의도 분기, 실패 재시도, 사용자 추가 질문 같은 흐름을 그래프로 고정
• 상태를 명시적으로 설계(예: user_intent, context_docs, final_answer)

3) 랭스미스로 품질을 꾸준히 관리한다

• “나쁜 답변” 케이스를 저장해 재현
• 변경 전/후 결과를 비교하며 개선

개발 관점 체크리스트(실무용)

• 출력 계약: 최종 응답을 JSON 스키마로 고정할 것인가?
• 도구 실패 전략: 타임아웃/재시도/대체 경로가 있는가?
• 상태 설계: 어떤 값을 상태로 남기고, 언제 폐기할 것인가?
• 평가 기준: “좋은 답”의 조건을 문장으로라도 정의했는가?

마무리: “잘 대답하는 모델”보다 “관리되는 시스템”

랭체인·랭그래프·랭스미스를 한 문장으로 정리하면 만들고(랭체인), 흐름을 세우고(랭그래프), 검증하고 고친다(랭스미스)입니다. LLM 앱은 데모는 빠르지만, 제품은 다릅니다. 세 도구를 적절히 섞으면 우연히 잘 되는 챗봇이 아니라 개발 가능한 서비스로 한 단계 올라갈 수 있어요.