왜 복합 요청 분해가 필요한가 — 한 문장에 일이 세 개다

한 줄 요약

19장에서 만든 라우터는 문의마다 하나의 처리 경로를 선택합니다. 하지만 고객은 한 번에 여러 가지를 요청하기도 합니다. 예를 들어 "반품 배송비가 얼마인지, 검정 270 사이즈는 재고가 있는지 알려 주세요"라는 문의에는 주문 정보와 반품 정책, 상품 재고를 각각 확인해야 합니다. 이번 장에서는 복합 문의를 여러 작업으로 나누어 처리한 뒤, 각 결과를 하나의 답변으로 정리하는 방법을 배웁니다.

1. 이 문의를 19장의 라우터에 넣으면

한 문장에 여러 가지 일이 든 문의입니다.

"지난주에 산 운동화가 작아서 반품하고 싶은데 배송비 얼마인지, 그리고 검정 270 재고 있으면 그걸로 교환 가능한지 알려주세요."

짐작해 보세요. 19장의 그래프는 이 문의를 어느 노드로 보낼까요? 그 노드는 무엇을 답하고 무엇을 답하지 못할까요?

19장의 그래프에 그대로 넣어 본 결과입니다. (문장은 실행할 때마다 달라집니다)

고객: 지난주에 산 운동화가 작아서 반품하고 싶은데 배송비 얼마인지, 그리고 검정 270 재고 있으면 그걸로 교환 가능한지 알려주세요.
  경로: 분류 → 환불교환 → 정책 RAG 노드 처리
하루: 단순 변심 교환의 왕복 배송비는 6,000원이며 고객이 부담합니다(근거: 제4조 ②). 다만, 원하는 옵션의 재고가 없는 경우 교환은 불가하며, 반품 후 환불로 처리됩니다(근거: 제4조 ③). 재고 유무의 경우 제공된 정책 발췌 내용만으로는 확인 불가합니다.

분류는 환불교환, 간 곳은 정책 노드입니다. 분류도 길 안내도 표대로입니다. 정책 노드는 자기가 볼 수 있는 정책 문서 안에서 배송비를 조항과 함께 답했고, 재고는 정책 문서에 없으므로 확인할 수 없다고 했습니다.

문의에 든 일	답이 있는 곳	정책 노드가 볼 수 있나
지난주에 산 운동화가 어떤 주문인지	주문 데이터	볼 수 없다
반품·교환 배송비가 얼마인지	정책 문서	볼 수 있다 → 답함
검정 270 재고가 있는지	상품 데이터	볼 수 없다

이 문의는 세 곳을 봐야 하는데 라우터는 길을 하나만 고릅니다. 이번 장에서는 문의를 먼저 나눠서 세 곳을 모두 보게 만듭니다.

2. 문의 하나에 일이 여러 개인 것 — 복합 요청

이렇게 한 문의 안에 서로 다른 처리가 여럿 들어 있는 것을 복합 요청이라고 부르겠습니다. 위 문의를 사람이 쪼개면 세 가지 일이 나옵니다.

주문 확인 — 지난주에 산 운동화 주문을 찾는다 (주문 도구)
정책 확인 — 반품·교환 배송비 규정을 찾는다 (정책 문서 검색)
재고 확인 — 검정 270의 재고를 본다 (상품 도구)

필요한 구조는 이렇습니다. 먼저 문의를 일의 목록으로 쪼개고, 일마다 알맞은 담당에게 맡기고, 결과를 하나의 답으로 합칩니다.

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

한 문장에 여러 가지를 묻는 문의를 어떤 구조에 맡겨야 하는지 고르지 못합니다.
복합 문의의 답을 고치고 싶을 때 쪼개기, 담당, 합치기 가운데 어디를 볼지 알지 못합니다.
문의 하나에 LLM을 몇 번 부르게 되는지, 그 비용이 어디서 나오는지 알지 못합니다.

4. 이번 장에서 만드는 것

단계	하는 일	누가
계획	문의를 작업 목록으로 쪼갠다	모델 (Planner)
실행	작업마다 담당 함수가 처리한다	우리 코드가 순서대로 부르고, 각 담당 안에서 모델이 일한다 (Worker)
취합	결과들을 하나의 답으로 합친다	모델

이 구조를 흔히 Planner-Worker 패턴이라고 부릅니다. 이번 장의 코드는 LangGraph를 쓰지 않습니다. 반복문 하나로 충분하기 때문입니다. 구조가 먼저이고, 도구는 필요할 때 고릅니다.

핵심 정리

라우터는 문의 하나를 길 하나로 보냅니다. 19장의 정책 노드는 복합 문의에서 자기가 볼 수 있는 배송비를 답했습니다.
이 문의는 주문 데이터, 정책 문서, 상품 데이터 세 곳을 봐야 합니다.
한 문의에 서로 다른 처리가 여럿 든 것이 복합 요청입니다.
해법은 쪼개고(계획), 맡기고(실행), 합치는(취합) 구조입니다.