왜 조건 분기가 필요한가 — 문의마다 가야 할 길이 다르다

한 줄 요약

18장에서 만든 그래프는 하나의 경로로만 동작했습니다. 모든 문의가 분류 → 응답 → 기록의 같은 순서를 거쳤습니다. 하지만 주문 문의에는 주문 데이터 조회가, 환불 문의에는 정책 확인이, 상담원 연결 요청에는 접수가 필요합니다. 이번 장에서는 문의 유형에 따라 처리 경로가 달라지도록 그래프에 조건 분기를 추가합니다.

1. 18장의 그래프를 다시 보면

18장에서 만든 그래프는 이렇게 생겼습니다.

시작 → classify(분류) → answer(응답) → log(기록) → 끝

classify 노드가 문의 유형을 알아내긴 했습니다. 그런데 그 결과를 쓰는 곳이 없었습니다. 유형이 무엇이든 다음 노드는 언제나 answer 하나였고, answer 노드가 가진 근거는 코드에 직접 적어 둔 정책 발췌 두 줄이 전부였습니다. 주문 데이터도, 정책 문서 전체도 보지 않았습니다.

분류를 해 놓고 모든 문의를 같은 창구로 보낸 셈입니다.

2. 유형마다 올바른 처리가 다르다

1장에서 정리한 문의 유형을 다시 꺼내 보면, 유형마다 답이 있는 곳이 다릅니다.

문의	답이 있는 곳	필요한 처리
"제 최근 주문 지금 어디예요?"	주문 데이터	주문 조회 도구 호출 (6~8장)
"단순 변심 반품이면 배송비 얼마예요?"	정책 문서	문서 검색 후 근거를 달아 답변 (12~15장)
"사람이랑 통화하고 싶어요."	없음	답변이 아니라 티켓 접수
"텀블러 식기세척기 돌려도 되나요?"	상품 데이터	상품 검색 도구 호출

네 문의를 한 노드가 전부 처리하게 만들 수도 있습니다. 도구를 전부 주고 규칙을 전부 적으면 됩니다. 그러나 7장에서 봤듯이 도구가 늘면 매 호출의 입력 토큰이 늘고, 엉뚱한 도구를 고를 여지도 커집니다.

필요한 것은 분류 결과에 따라 서로 다른 노드로 보내는 구조입니다.

3. 이걸 모르면 무엇을 판단하지 못하는가

답이 틀렸을 때 분류가 틀린 것인지, 길을 잘못 보낸 것인지, 도착한 노드가 틀리게 답한 것인지 가려내지 못합니다. 세 가지는 고치는 곳이 전부 다릅니다.
"계정 문의는 이제 사람에게 보내지 말고 자동으로 처리하자"는 요구가 왔을 때 어디를 고치면 되는지 알지 못합니다.
문의가 어느 길로 갔는지 기록으로 확인하는 방법을 모릅니다.

4. 이번 장에서 만드는 것

분류 노드 뒤에 갈림길을 두고, 네 갈래의 전담 노드를 붙입니다.

                 ┌→ order   (주문 도구)   ─┐
시작 → classify ─┼→ policy  (정책 검색)   ─┼→ 끝
                 ├→ human   (티켓 접수)   ─┤
                 └→ general (상품 도구)   ─┘

새로 배우는 LangGraph 문법은 조건부 엣지 하나입니다. 나머지 부품은 전부 앞 장에서 만든 것을 가져다 씁니다.

부품	어디서 만들었나
문의 분류기 `classify`	4장
주문·상품·티켓 도구	6~8장 (`haru_tools.py`)
정책 문서 검색	13~14장 (`chroma_db/`)
상태·노드·엣지	18장

핵심 정리

18장의 그래프는 분류를 해 놓고도 모든 문의를 같은 노드로 보냈습니다.
문의 유형마다 답이 있는 곳(주문 데이터, 정책 문서, 상품 데이터, 사람)이 다릅니다.
분류 결과에 따라 길을 나누면, 틀렸을 때 분류·길 안내·처리 중 어디가 문제인지 가려낼 수 있습니다.
이번 장에서 새로 배우는 문법은 조건부 엣지 하나입니다.