고객지원 업무는 AI를 붙이기 가장 좋은 분야 중 하나다. 같은 종류의 문의가 반복해서 들어오고, 답변 톤은 일정해야 하며, 빠뜨리면 안 되는 정보가 많기 때문이다. 동시에 가장 조심해야 하는 분야이기도 하다. 고객의 감정이 걸려 있고, 환불·장애·배송·계정 문제처럼 실제 피해와 연결되는 일이 많아서, 그럴듯한 말 한마디보다 정확한 처리 흐름이 훨씬 중요하다.
이 장에서 다루는 핵심은 간단하다. 고객지원 프롬프트를 "답장 잘 쓰는 문장"으로 보지 않고, 문의 분류에서 시작해 긴급도 판단, 응답 초안 작성, 상담 이력 요약까지 이어지는 하나의 지원 흐름으로 설계하는 것이다. 이렇게 해야 AI가 말은 잘하지만 일이 남는 상태를 피할 수 있다. 고객지원에서 좋은 프롬프트란 친절한 문장을 많이 만드는 프롬프트가 아니라, 다음 담당자가 바로 이어받을 수 있는 결과를 만드는 프롬프트다.
고객지원 워크플로를 네 단계로 나누기
고객지원 업무를 프롬프트로 설계할 때 가장 먼저 할 일은 문의를 한 번에 해결하려고 하지 않는 것이다. 한 번에 모든 걸 시키면 모델은 대체로 그럴듯한 문장을 길게 만들지만, 정작 중요한 분류나 누락 정보 확인은 흔들리기 쉽다. 그래서 고객지원 업무는 다음 네 단계로 나누는 편이 안정적이다.
문의 분류: 이 문의가 어떤 유형인지 정한다.
긴급도 판단: 지금 당장 사람에게 넘겨야 하는지, 일반 처리로 가능한지 정한다.
응답 초안 작성: 고객에게 보낼 문장을 만든다.
상담 이력 요약: 내부 기록용으로 핵심 내용을 남긴다.
이 네 단계는 단순해 보이지만, 실제 현장에서는 서로 강하게 연결된다. 예를 들어 "결제가 두 번 됐어요"라는 문의는 결제/환불 카테고리로 분류되고, 금전 피해가 있으므로 긴급도 판단에서 우선순위가 올라갈 수 있다. 응답 초안에서는 사과 문구와 확인 절차가 들어가야 하고, 상담 이력에는 중복 결제 가능성, 주문번호, 고객이 원하는 조치가 빠지지 않아야 한다. 즉, 한 단계의 품질이 다음 단계의 품질을 결정한다.
중급 프롬프트 설계자는 여기서 중요한 원칙 하나를 기억해야 한다. 고객지원 프롬프트는 "멋진 답변 생성기"가 아니라 "작업 넘김이 가능한 처리기"여야 한다는 점이다.
먼저 분류가 흔들리면 뒤가 다 흔들린다
문의 분류는 고객지원 워크플로의 입구다. 입구가 흔들리면 나머지 단계가 모두 흔들린다. 잘못 분류된 문의는 잘못된 템플릿으로 답변되고, 긴급하지 않은데 긴급하게 올라가거나 정말 급한데 일반 문의함에 묻혀 버린다.
초보자는 분류를 너무 넓게 잡는 실수를 자주 한다. 예를 들어 카테고리를 "배송, 결제, 계정, 기타" 정도로만 두면, 실제 현장에서는 거의 모든 문의가 "기타" 비슷하게 보인다. 반대로 카테고리를 지나치게 잘게 나누면 모델이 서로 비슷한 라벨 사이에서 계속 망설인다. 그래서 분류 체계는 현장의 반복 문의를 반영하되, 사람도 일관되게 쓸 수 있을 정도로 적당히 단순해야 한다.
고객지원용 분류 프롬프트에는 최소한 다음 정보가 들어가야 한다.
단일 1차 분류 라벨
필요하면 2차 세부 분류
그렇게 판단한 근거 한 줄
답변 전에 반드시 확인해야 할 누락 정보
예를 들어 분류 결과를 자유서술로 받으면 "이건 아마 배송 문제 같고 결제 이슈도 조금 섞여 있는 것 같습니다"처럼 애매한 문장이 나온다. 실무에서는 이런 답이 가장 곤란하다. 담당자는 결국 다시 읽고 다시 판단해야 한다. 따라서 분류는 가능한 한 구조화해서 받는 편이 낫다.
예시는 이렇게 설계할 수 있다.
역할: 당신은 고객지원 티켓 분류 보조자다.
목표: 고객 문의를 하나의 1차 카테고리와 필요 시 하나의 2차 카테고리로 분류한다.
규칙:
- 반드시 1차 카테고리는 하나만 선택한다.
- 정보가 부족하면 추정하지 말고 missing_info에 적는다.
- 답변 문장은 쓰지 않는다.
1차 카테고리:
- 배송
- 결제/환불
- 계정/로그인
- 상품/서비스 사용
- 장애/오류
- 정책/약관
- 불만/컴플레인
- 기타
출력 형식:
{
"primary_category": "",
"secondary_category": "",
"reason": "",
"missing_info": []
}
입력 문의:
{{customer_message}}이 프롬프트의 장점은 두 가지다. 첫째, 모델이 답변 작성 욕심을 내지 못하게 막는다. 둘째, 사람이 검토하기 쉬운 결과를 만든다. 고객지원에서는 "AI가 얼마나 친절한가"보다 "담당자가 얼마나 빨리 다음 행동을 할 수 있는가"가 더 중요할 때가 많다.
긴급도 판단은 감정이 아니라 기준으로 한다
고객지원에서 흔한 착각은, 화난 고객의 말투가 곧 긴급도를 뜻한다고 보는 것이다. 물론 강한 불만은 중요하다. 하지만 긴급도는 감정의 크기만으로 정하면 안 된다. 실제 손해 가능성, 서비스 중단 여부, 보안 위험, 다수 고객 영향, 법적 민감성 같은 기준이 함께 들어가야 한다.
예를 들어 "답장이 너무 늦네요"는 말투는 강할 수 있지만 운영상 최고 긴급은 아닐 수 있다. 반대로 "다른 사람 정보가 제 화면에 보여요"는 문장이 차분해도 즉시 사람에게 넘겨야 하는 매우 높은 긴급 상황이다. 그래서 긴급도 판단 프롬프트는 감정 분석 프롬프트와 다르게 설계해야 한다.
실무에서는 보통 긴급도를 3단계나 4단계로 나누면 충분하다. 너무 많은 단계를 두면 기준이 흐려진다. 예를 들어 다음처럼 정의할 수 있다.
P1: 보안, 개인정보, 결제 오류, 서비스 전면 장애, 대규모 영향
P2: 핵심 기능 사용 불가, 당일 처리 필요, 금전적 불편 가능성
P3: 일반 문의, 사용 안내, 정책 확인, 기능 요청
이때 중요한 것은 라벨 이름보다 판단 기준 문장이 더 중요하다는 점이다. 모델은 "중요한 문의를 골라라" 같은 표현에는 흔들리지만, "개인정보 노출, 결제 중복, 로그인 불가, 전체 장애는 P1 또는 P2로 판단" 같은 규칙에는 훨씬 안정적으로 반응한다.
긴급도 판단 프롬프트는 다음처럼 만들 수 있다.
역할: 당신은 고객지원 긴급도 분류 보조자다.
목표: 문의의 운영상 긴급도를 P1, P2, P3 중 하나로 판단한다.
판단 기준:
- P1: 개인정보/보안 문제, 중복 결제/오결제, 서비스 전면 장애, 여러 사용자 영향 가능성
- P2: 핵심 기능 사용 불가, 구매/수강/예약 등 중요한 행동 진행 불가, 강한 불만과 함께 즉시 조치 필요
- P3: 일반 문의, 사용법 안내, 단순 정책 질문, 정보 요청
규칙:
- 고객 감정만으로 긴급도를 높이지 않는다.
- 근거가 부족하면 insufficient_evidence를 true로 표시한다.
- 사람 검토가 필요한 경우 handoff_needed를 true로 표시한다.
출력 형식:
{
"priority": "P1|P2|P3",
"reason": "",
"insufficient_evidence": true,
"handoff_needed": true
}
입력 문의:
{{customer_message}}이렇게 해 두면 AI가 "화가 많이 나셨네요, 긴급한 상황으로 보입니다" 같은 감정 중심 판단을 하는 일을 줄일 수 있다. 고객지원에서 필요한 것은 공감도 중요하지만, 그보다 먼저 운영 기준의 일관성이다.
응답 초안은 친절함보다 안전성이 먼저다
고객지원 프롬프트를 처음 설계할 때 많은 사람이 가장 오래 붙잡는 부분이 응답 문구다. 하지만 실무에서는 문장 자체보다 답변의 안전성이 더 중요하다. 잘못된 안내, 근거 없는 단정, 확인되지 않은 보상 약속은 친절한 문장보다 훨씬 큰 문제를 만든다.
그래서 응답 초안 프롬프트는 "예쁘게 써줘"가 아니라 "허용된 정보만 사용해 써줘"에 가까워야 한다. 특히 다음 네 가지를 분리해서 설계하면 좋다.
공감 문장: 고객의 불편을 인정한다.
사실 확인 문장: 현재 확인된 정보만 말한다.
다음 행동 안내: 고객이 해야 할 일과 회사가 할 일을 나눈다.
제한 문장: 확인되지 않은 내용은 단정하지 않는다.
예를 들어 고객이 "어제 결제했는데 아직 이용권이 안 보여요"라고 했다고 하자. 여기서 AI가 섣불리 "결제 오류가 발생했네요. 곧 환불해 드리겠습니다"라고 쓰면 큰일 난다. 아직 확인되지 않은 사실을 단정했고, 권한 없는 조치를 약속했기 때문이다. 좋은 초안은 오히려 조금 덜 화려해도 된다.
안녕하세요. 이용에 불편을 드려 죄송합니다.
현재 문의 내용만으로는 결제 완료는 되었지만 이용권 반영이 지연된 상황인지, 결제 자체가 정상 처리되지 않은 상황인지 바로 단정하기 어렵습니다.
확인을 위해 주문번호 또는 결제 시각을 보내 주시면 확인 후 안내드리겠습니다.
만약 결제 영수증이나 카드 승인 내역이 있다면 함께 전달해 주세요.이 문장의 장점은 고객을 기다리게만 하지 않으면서도, 확인되지 않은 사실을 단정하지 않는다는 점이다. 고객지원에서 AI가 가장 자주 저지르는 실수는 자신감 있는 추측이다. 그래서 응답 초안 프롬프트에는 "모르면 확인 질문으로 전환하라"는 규칙이 꼭 들어가야 한다.
다음은 실무형 응답 초안 프롬프트의 예다.
역할: 당신은 고객지원 답변 초안 작성 보조자다.
목표: 고객에게 보낼 한국어 답변 초안을 작성한다.
톤:
- 공손하고 차분하게
- 과장된 사과 표현 금지
- 확인되지 않은 사실 단정 금지
규칙:
- 제공된 문의 내용과 내부 메모에 없는 사실은 추가하지 않는다.
- 정보가 부족하면 최대 3개의 확인 질문을 우선 제시한다.
- 환불, 보상, 복구 완료를 임의로 약속하지 않는다.
- 답변은 짧은 문단 2~4개로 쓴다.
입력:
고객 문의: {{customer_message}}
분류 결과: {{category}}
긴급도: {{priority}}
내부 메모: {{internal_note}}
출력:
고객 발송용 답변 초안만 작성이 프롬프트를 쓰면 응답 초안은 더 얌전해질 수 있다. 하지만 고객지원에서는 그 얌전함이 오히려 장점이다. 실수 없는 기본기가 결국 전체 처리 품질을 올린다.
상담 이력 요약은 미래의 나와 동료를 위한 문서다
상담 이력 요약은 종종 가장 나중에, 가장 대충 처리된다. 하지만 실제로는 팀 운영에 큰 영향을 준다. 누가 어떤 안내를 했는지 기록이 없으면, 다음 상담사는 처음부터 다시 묻게 된다. 고객은 "아까도 말했는데요?"라고 말하고, 팀은 같은 일을 반복한다.
좋은 상담 이력 요약은 길지 않다. 대신 다음 사람이 바로 이어받을 수 있게 핵심만 남긴다. 특히 고객지원 요약에는 다음 요소가 유용하다.
고객이 겪는 문제
확인된 사실
아직 확인되지 않은 점
안내한 내용
다음 액션
사람 이관 여부
중요한 점은 요약과 해석을 구분하는 것이다. 예를 들어 고객이 "앱이 자꾸 꺼져요"라고 말했는데, 이를 이력에 "앱 버그 발생"이라고 적으면 안 된다. 버그일 수도 있지만 아직 확정된 사실은 아니다. 이력에는 "앱 실행 중 종료 현상 호소"처럼 관찰된 표현으로 남기는 편이 안전하다.
상담 이력 요약 프롬프트는 보통 다음처럼 만든다.
역할: 당신은 고객지원 상담 이력 정리 보조자다.
목표: 내부 CRM에 남길 상담 이력을 짧고 정확하게 정리한다.
규칙:
- 추측하지 않는다.
- 고객 감정 표현은 필요한 경우에만 요약한다.
- 확인된 사실과 미확인 사항을 구분한다.
- 다음 담당자가 바로 이해할 수 있게 쓴다.
출력 형식:
- 문의 요약:
- 확인된 정보:
- 미확인 정보:
- 안내 내용:
- 다음 액션:
- 이관 필요 여부:
입력:
고객 문의: {{customer_message}}
상담 답변 초안: {{draft_reply}}
추가 메모: {{internal_note}}상담 이력은 고객에게 보여 주는 문장이 아니기 때문에, 친절함보다 정확한 압축이 중요하다. 한 줄을 줄이려고 핵심을 버리면 안 되고, 자세히 쓰겠다고 대화 전문을 붙여 넣어도 안 된다. 좋은 이력은 다음 사람의 시간을 아껴 주는 문서다.
네 단계를 하나의 흐름으로 묶는 방법
이제 중요한 질문이 남는다. 이 네 단계를 각각 따로 돌릴 것인가, 아니면 하나의 프롬프트 안에서 한 번에 처리할 것인가?
정답은 업무 환경에 따라 다르지만, 고객지원에서는 보통 "한 번에 생성하되, 출력은 분리해서 받는 방식"이 실용적이다. 즉 모델에게는 한 번에 분류, 긴급도, 응답 초안, 이력 요약을 요청하되, 결과는 섞이지 않게 구조화해서 받는다. 그래야 상담 도구나 스프레드시트, CRM에 붙여 넣기 쉽다.
예를 들어 다음처럼 하나의 통합 프롬프트를 설계할 수 있다.
역할: 당신은 고객지원 업무 보조자다.
목표: 고객 문의를 분류하고, 긴급도를 판단하고, 고객 답변 초안을 만들고, 내부 상담 이력을 요약한다.
공통 규칙:
- 확인되지 않은 사실을 단정하지 않는다.
- 정보가 부족하면 missing_info 또는 확인 질문에 적는다.
- 금전 보상, 환불 확정, 정책 예외 적용을 임의로 약속하지 않는다.
- 고객 발송용 문장과 내부 기록용 문장을 섞지 않는다.
출력 형식:
{
"classification": {
"primary_category": "",
"secondary_category": "",
"reason": "",
"missing_info": []
},
"priority": {
"level": "P1|P2|P3",
"reason": "",
"handoff_needed": true
},
"reply_draft": "",
"case_summary": {
"issue": "",
"confirmed_facts": [],
"unconfirmed_points": [],
"guidance_given": [],
"next_action": ""
}
}
입력:
고객 문의: {{customer_message}}
고객 정보: {{customer_profile}}
기존 상담 이력: {{past_history}}
내부 운영 메모: {{internal_note}}이 구조의 장점은 명확하다. 분류는 라우팅에 쓰고, 긴급도는 우선 처리 여부를 정하며, 응답 초안은 고객 커뮤니케이션에 쓰고, 상담 이력 요약은 내부 기록에 바로 저장할 수 있다. 즉 하나의 입력으로 여러 작업 산출물이 동시에 나오는 셈이다. 이것이 바로 고객지원에서 중급 프롬프트가 빛나는 지점이다.
입력 설계가 허술하면 고객지원 프롬프트는 금방 무너진다
고객지원 워크플로에서 많은 문제가 프롬프트 문장보다 입력 설계에서 생긴다. 고객 메시지만 던져 주고 "알아서 해줘"라고 하면, 모델은 가장 그럴듯한 추측으로 빈칸을 메우려 한다. 그래서 고객지원 입력은 적어도 덩어리별로 나누어 주는 편이 좋다.
예를 들어 같은 문의라도 아래 입력이 있느냐 없느냐에 따라 결과가 크게 달라진다.
고객 원문
주문번호나 계정 식별자
이전 상담 이력
현재 서비스 공지나 장애 여부
허용된 정책 문구
응답 금지 표현
특히 고객지원에서는 "현재 공지 중인 장애" 정보가 중요하다. 로그인 불가 문의가 들어왔을 때, 이미 전사 공지가 있는 장애라면 응답은 설명과 예상 복구 안내 중심이 된다. 반대로 공지가 없다면 개별 계정 문제 확인 질문 중심이 된다. 같은 고객 문장도 운영 맥락이 바뀌면 좋은 답변도 바뀐다.
중급 프롬프트 설계자는 여기서 한 걸음 더 나아가, 입력이 비어 있을 때의 처리 방식까지 정해 둬야 한다. 예를 들어 주문번호가 없으면 바로 확인 질문으로 전환하고, 기존 상담 이력이 없으면 초회 문의처럼 응답하되 추측은 하지 않도록 만든다. 결국 안정성은 멋진 문장보다 빈칸을 다루는 규칙에서 나온다.
고객지원에서 특히 중요한 금지 규칙
고객지원 업무는 친절함이 중요하지만, 친절함이 곧 허용 범위를 넓혀도 된다는 뜻은 아니다. 오히려 고객지원 프롬프트일수록 금지 규칙이 선명해야 한다. 다음 규칙은 거의 모든 지원팀에서 유용하다.
확인되지 않은 원인을 단정하지 않기
환불, 보상, 복구 완료를 임의로 약속하지 않기
정책 예외를 마음대로 허용하지 않기
민감정보를 다시 요구할 때는 필요한 범위만 묻기
법률, 의료, 보안 이슈는 지정된 사람 검토로 넘기기
이 규칙들은 답변을 조금 딱딱하게 만들 수 있다. 하지만 고객지원에서는 딱딱함보다 위험한 것이 과잉 자신감이다. 중급 프롬프트는 모델을 더 화려하게 만드는 기술이 아니라, 모델이 넘지 말아야 할 선을 분명히 긋는 기술에 가깝다.
실제 현장에서 쓰는 미니 워크플로 예시
이제 하나의 예시를 따라가 보자.
고객 문의가 들어왔다.
결제는 됐는데 강의가 아직 열리지 않아요. 오늘 꼭 들어야 해서 급합니다.
이 문의를 좋은 고객지원 워크플로에 넣으면 대략 다음 순서로 처리할 수 있다.
먼저 문의 분류는 결제/환불 > 결제 후 미반영 또는 상품/서비스 사용 > 이용권 미반영 중 하나로 정리된다. 여기서 중요한 것은 팀의 카테고리 체계에 따라 한 가지로 일관되게 고르는 것이다. 다음으로 긴급도는 학습 일정에 영향이 있지만 보안 이슈는 아니므로 보통 P2 정도로 판단할 수 있다. 그다음 응답 초안은 사과, 확인 요청, 처리 약속 범위 안에서 작성한다. 마지막으로 상담 이력에는 "결제 후 강의 미노출 호소, 당일 수강 필요성 언급, 주문정보 확인 요청" 정도가 남는다.
이 흐름은 단순해 보이지만 실제로는 큰 차이를 만든다. 문의 분류만 한 팀, 답변만 쓴 팀, 상담 이력을 따로 남기는 팀은 같은 일을 세 번 반복하게 된다. 반대로 하나의 프롬프트 흐름으로 묶어 두면, 한 번 읽고 네 가지 결과를 뽑아낼 수 있다.
사람에게 넘겨야 하는 순간을 프롬프트에 포함하기
고객지원에서 AI를 잘 쓰는 팀은 AI가 할 수 있는 일만 잘 시키는 팀이 아니다. AI가 하면 안 되는 순간을 정확히 정하는 팀이다. 그래서 고객지원 워크플로 프롬프트에는 항상 "이관 조건"이 들어가야 한다.
예를 들어 다음 경우는 사람 이관 플래그를 세우는 편이 좋다.
개인정보 노출이나 보안 의심
결제 분쟁, 환불 분쟁, 법적 위협
자해, 혐오, 위협 등 안전 이슈
언론 제보, 공론화 예고, VIP 계정
기존 답변과 충돌하는 민감한 케이스
이관 조건이 없는 프롬프트는 겉보기에는 똑똑해 보여도 운영상 위험하다. 반대로 이관 조건이 명확한 프롬프트는 AI가 할 수 있는 일과 사람이 해야 할 일을 자연스럽게 나눈다. 고객지원에서는 이 선 긋기가 특히 중요하다.
팀에서 바로 쓰기 좋은 프롬프트 패키지 만들기
개인적으로는 한 문장으로도 꽤 괜찮은 답변을 뽑아낼 수 있다. 하지만 팀에서 쓰려면 패키지로 만들어야 한다. 고객지원 프롬프트 패키지에는 보통 다음 요소가 있으면 좋다.
문의 분류 프롬프트
긴급도 판단 프롬프트
응답 초안 프롬프트
상담 이력 요약 프롬프트
공통 금지 규칙
자주 쓰는 카테고리 정의
승인 필요한 답변 유형 목록
이렇게 패키지화하면 신입 상담사도 기준을 빠르게 익힐 수 있고, 팀 리더도 어떤 부분에서 오류가 나는지 확인하기 쉬워진다. 무엇보다 "누구는 이렇게 쓰고 누구는 저렇게 쓴다"는 개인차를 줄일 수 있다. 고객지원처럼 반복성과 정확성이 중요한 업무일수록, 중급 프롬프트의 가치는 개인의 재치보다 팀의 일관성에서 나온다.
고객지원 워크플로의 품질을 점검하는 질문
프롬프트를 만든 뒤에는 스스로 몇 가지 질문을 던져 봐야 한다. 이 질문에 답할 수 있으면, 고객지원 워크플로는 꽤 단단해진다.
분류 라벨이 서로 겹치지 않는가?
긴급도 기준이 감정이 아니라 운영 기준에 서 있는가?
응답 초안이 확인되지 않은 사실을 말하지 않는가?
정보가 부족할 때 확인 질문으로 전환하는가?
상담 이력이 다음 담당자에게 실제로 도움이 되는가?
사람 이관 조건이 명확한가?
이 질문들은 거창한 평가표처럼 보이지 않아도 강력하다. 고객지원 프롬프트는 대부분 여기서 무너지거나, 여기서 단단해진다.
고객지원에서 중급 프롬프트의 힘이 드러나는 순간
고객지원은 AI가 가장 쉽게 "말을 잘하는 척"할 수 있는 분야이자, 가장 쉽게 실수가 드러나는 분야다. 그래서 오히려 중급 프롬프트의 진짜 힘을 체감하기 좋다. 템플릿이 없으면 상담사마다 답변 톤이 달라지고, few-shot 예시가 없으면 분류 기준이 흔들리며, 구조화 출력이 없으면 CRM 기록이 엉키고, 평가 기준이 없으면 무엇이 좋아졌는지조차 알 수 없다.
반대로 워크플로로 설계하면 상황이 달라진다. 문의는 같은 기준으로 분류되고, 긴급도는 기준에 따라 올라가며, 응답 초안은 안전하게 작성되고, 상담 이력은 다음 사람에게 자연스럽게 이어진다. 고객지원에서 중급 프롬프트란 결국 "AI가 대신 답해 준다"가 아니라 "반복되는 지원 흐름을 흔들림 없이 보조한다"는 뜻이다.
고객은 언제나 새로운 말을 하지만, 팀이 반복해서 처리하는 문제는 의외로 비슷하다. 바로 그 반복의 자리에 프롬프트를 놓는 것. 그것이 고객지원 워크플로를 설계하는 가장 실무적인 출발점이다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.