1장. 에이전트 요구사항과 아키텍처 설계

요구사항 정하기 — 이 시스템이 답해야 하는 질문 12개

한 줄 요약

"AI 고객지원을 만들자"는 목표가 될 수 없습니다. 너무 넓기 때문입니다. 요구사항은 실제로 들어올 질문의 목록으로 적을 때 가장 분명해집니다. 우리 시스템의 요구사항은 답하고 처리할 수 있어야 하는 표준 질문 12개이고, 과정 내내 이 목록으로 되돌아와 "여전히 전부 되는가"를 확인합니다.

---

1. 먼저 로그를 분석한다

무엇을 자동화할지는 감으로 정하지 않습니다. 에이전트를 만들기 전에 지금 들어오고 있는 문의부터 세어 봅니다. 고객지원에는 거의 항상 좋은 데이터가 이미 쌓여 있습니다. 상담 문의 로그입니다.

하루마켓의 최근 상담 문의 로그는 40건입니다(data/inquiries.csv). 한 줄이 문의 한 건이고, 문의마다 이런 항목이 기록되어 있습니다.

이 로그에 두 가지 질문을 던집니다.

1. 어떤 문의가 많이 들어오는가? → 유형별로 센다.
2. 지금은 얼마나 해결되고 있는가? → 처리 결과별로 센다.

세어 본 결과가 아래 그림입니다.

① 유형별로 세면 — 무엇부터 자동화할지가 보인다

• 위의 세 유형(환불·교환, 제품 문의, 주문·배송 조회)이 40건 중 32건, 전체의 80% 입니다. 여기부터 자동화해야 효과가 큽니다.
• 이 세 유형은 모두 답의 근거가 문서나 데이터에 명확히 있습니다. AI가 정확히 답할 수 있는 종류입니다.
• 그래서 필요한 것이 정해집니다. 정책 문서를 찾는 에이전트와 주문·상품 데이터를 조회하는 에이전트입니다.

② 처리 결과별로 세면 — 목표가 정해진다

40건 중 자동 해결 22건, 상담원 처리 16건, 미해결 2건입니다.

• 지금의 자동해결률은 55% 입니다(22 ÷ 40). 이 숫자가 출발점이고, 우리가 끌어올릴 대상입니다.
• 미해결 2건이 있습니다. 해결도 못 하고 사람에게 넘기지도 못한 문의입니다. 고객 입장에서 최악의 경험이고, 반드시 없애야 합니다. 그래서 고객의 요청을 끝까지 맡는 에이전트가 필요합니다. 처리할 수 있는 일은 그 자리에서 처리하고, 처리할 수 없는 일은 상담원에게 정확히 넘기는 요청처리 에이전트입니다. 어느 쪽이든 문의가 중간에 떠 있는 일은 없게 합니다.

로그 분석이 설계를 정했습니다. 무엇부터 자동화할지(상위 세 유형), 어떤 에이전트가 필요한지(정책 안내, 데이터 조회, 요청 처리), 목표가 무엇인지(자동해결률을 올리고 미해결을 없앤다)가 모두 이 숫자에서 나왔습니다. 에이전트 프로젝트는 코드가 아니라 로그를 세는 일에서 시작합니다.

---

2. 무엇부터 자동화할 것인가

자동화 대상을 고르는 기준은 두 가지입니다.

• 빈도 — 자주 들어오는 문의일수록 자동화 효과가 큽니다.
• 정형성 — 답이 데이터나 문서에 명확히 있을수록 AI가 정확히 답합니다.

왼쪽 위가 우리의 주 무대입니다. 오른쪽 아래는 처음부터 사람에게 넘기는 것이 맞습니다.

---

3. 표준 질문 12개

이 기준으로 고른 질문 12개가 이 과정의 요구사항입니다. 질문별 기대 동작은 data/질문셋.md에 정리되어 있습니다. 전제는 하나입니다. 고객 김도윤(C003, VIP 등급) 이 로그인해 있고, 오늘은 2026년 7월 27일입니다.

번호 순서가 아니라 무엇을 요구하는가로 묶으면 난이도가 계단처럼 올라갑니다.

몇 개만 짚어 봅니다.

• Q5 — 고객은 자기 등급을 말하지 않았습니다. 시스템이 먼저 등급을 확인해 VIP임을 알아내고, 그 등급의 규정("월 1회 면제")으로 답해야 합니다.
• Q7 — 둘째 질문은 묻기만 했습니다. "취소하면 언제 들어와요?"는 취소 요청이 아니므로 취소를 처리하지 않고 환불 기간만 답합니다.
• Q8 — 텀블러는 배송 완료 후 26일이 지났습니다. "접수했습니다"라고 말하면 안 되고, 기간이 지났다는 이유를 전합니다. 고객이 사람을 찾으면 그때 상담원에게 넘기고 티켓번호(T로 시작)를 알려 줍니다.
• Q10 — "취소했습니다"가 아니라 "승인 요청을 등록했고, 담당자가 승인하면 처리됩니다"가 정답입니다.

특히 아래 두 묶음이 중요합니다. 좋은 고객지원 시스템은 일을 잘 처리하는 것만큼이나 처리하면 안 되는 일을 가려내고, 해서는 안 되는 말은 하지 않아야 합니다.

---

4. 어디까지 맡길 것인가 — 위험도에 따른 세 갈래

질문 목록과 함께 어디까지 자동으로 할지를 정해 둡니다. 먼저 고객의 문의를 둘로 나눕니다. 묻는 문의와 처리해 달라는 요청입니다.

묻는 문의 — 자동으로 답한다

묻는 문의는 읽기만 하면 되므로 잘못되어도 데이터가 바뀌지 않습니다. 지켜야 할 것은 근거입니다.

처리해 달라는 요청 — 위험도에 따라 세 갈래

처리 요청은 다릅니다. 무언가가 실제로 바뀝니다. 그래서 "잘못 처리했을 때 되돌릴 수 있는가"를 기준으로 갈래를 나눕니다.

배송지를 잘못 바꿨다면 다시 바꾸면 됩니다. 교환 접수도 돈이 나가지 않는 일이라 잘못 접수했더라도 바로잡을 수 있습니다. 그러나 환불은 돈이 고객의 계좌로 나가는 일이라 되돌리기 어렵습니다. 위험이 클수록 사람이 가까이 있어야 합니다.

유형이나 갈래와 상관없이 시스템 전체에 적용하는 규칙도 네 가지 있습니다.

• 처리해도 되는지는 코드가 판정한다. 아직 출고 전인가, 반품·교환 기간 안인가, 재고가 있는가. 이런 조건은 모델의 판단에 맡기지 않고 코드가 데이터를 보고 가립니다. 모델이 정하는 것은 "어떤 처리를 요청할지"이고, 그 처리가 가능한지를 정하는 것은 우리 코드입니다.
• 하지 않은 일을 했다고 말하지 않는다. 처리번호와 티켓번호는 모델이 지어내지 않습니다. 실제로 남은 기록에서 가져온 번호만 안내합니다. 승인을 기다리는 요청을 "처리했습니다"라고 말하지 않습니다.
• 넘길 때는 정확히 넘긴다. 티켓에는 고객 상황, 이미 확인한 사실, 요청 사항이 요약되어 있어야 합니다. 그래야 상담원이 처음부터 다시 묻지 않습니다.
• 범위 밖 질문에는 답하지 않는다. 투자, 시사처럼 쇼핑과 무관한 질문에는 답하지 않고 쇼핑 문의 창구임을 정중히 안내합니다. 회사 상담 창구가 한 말은 전부 회사의 발언이 되기 때문입니다.

---

5. 잘 만들었는지 무엇으로 판단할 것인가

만들기 전에 판단 기준을 정합니다. 나중에 정하면 만든 것에 맞춰 기준을 고르게 됩니다.

두 가지만 짚어 둡니다.

자동해결률 목표가 100%가 아니라 70%입니다. 사람이 처리해야 할 문의가 원래 존재하기 때문입니다. 100%를 목표로 잡으면 시스템이 "모르면서 답하는" 쪽으로 만들어집니다.

근거 표기율은 환각에 대한 대응입니다. 정책 답변에 반드시 근거 조항을 붙이게 하면 검증할 수 있게 되고, 검증할 수 있으면 품질을 관리할 수 있습니다.

---

핵심 정리

• 요구사항은 실제로 들어올 질문의 목록으로 적습니다. 우리의 요구사항은 표준 질문 12개입니다.
• 에이전트를 만들기 전에 문의 로그를 먼저 분석합니다. 유형별로 세면 무엇부터 자동화할지가, 처리 결과별로 세면 목표가 정해집니다.
• 자주 들어오고 답의 근거가 명확한 문의가 최우선입니다. 하루마켓은 상위 세 유형이 80% 이고 지금의 자동해결률은 55% 입니다.
• 질문은 조회로 끝나는 문의 → 둘 협업 → 셋 협업·직접 처리 → 처리하면 안 되는 일 가려내기 → 답하지 않기 순으로 어려워집니다.
• 처리 요청은 위험도에 따라 세 갈래입니다. 되돌릴 수 있는 일은 직접 처리, 돈이 나가는 되돌릴 수 없는 일은 승인 후 처리, 처리할 수 없는 일은 상담원에게.
• 처리해도 되는지는 코드가 판정하고, 하지 않은 일을 했다고 말하지 않습니다.
• 판단 기준(자동해결률, 근거 표기율 등)은 만들기 전에 정합니다.