채용 · July 21, 2026 · 10분 읽기

고객 지원을 위한 프롬프트 엔지니어링

고객 지원에서 프롬프트 엔지니어링이란 사실상 편집이다. AI 초안을 정책에 근거하게 하고, 어조를 다듬고, 과도한 약속이 고객에게 전달되기 전에 잘라내는 일이다.

← 채용의 다섯 가지 기둥: 평가가 실제로 측정하는 것의 일부

지원 팀을 운영한다면 이 글은 당신을 위한 것입니다. 지원 업무는 AI가 실제 업무 산출물, 즉 고객이 읽는 답변을 초안으로 작성하기 시작한 첫 번째 직무 중 하나였기 때문입니다. 고객 지원에서 프롬프트 엔지니어링은 'AI에게 답변을 작성하게 할 수 있는가'가 아닙니다. '이미 화가 난 고객이 읽기 전에 AI가 잘못한 부분을 잡아낼 수 있는가'입니다. 위험은 즉각적입니다. 과도한 약속 하나 혹은 잘못된 정책 세부사항 하나가 수신함에 들어가면 환불 분쟁, 부정적 리뷰, 또는 고객 이탈로 이어집니다. 이 글은 직무별 프롬프트 엔지니어링 시리즈의 고객 지원 편이며, AI Sandbox가 가장 명확하게 드러내는 신호 중 하나입니다.

프롬프트는 일의 절반이고, 편집이 나머지 절반이다

강력한 지원 프롬프트는 두 가지를 합니다. 관련 정책을 모델에 전달해 답변이 추측이 아닌 사실에 근거하게 하고, 어조를 지정해 — 따뜻하고, 직접적이며, 실수를 인정하는 — 답변이 로봇처럼 읽히지 않게 합니다. 하지만 잘 작성된 초안조차도 편집자가 필요합니다. 모델은 동의하려는 경향이 있어서, 정책이 뒷받침하지 않는 과도한 약속('바로 환불해 드리겠습니다')이 답변에 슬며시 들어갑니다. 그것을 잡아내는 것이 지원 직무에서의 AI 유창성이며, 어떤 템플릿도 자동화할 수 없는 부분입니다.

성숙한 지원 상담원의 특징은 멋진 프롬프트가 아닙니다. 그것은 첫 번째 초안을 최종본으로 취급하지 않는다는 것입니다. 그들은 생성된 모든 답변을, 실제로 화가 난 사람이 곧 받을 것처럼 읽습니다 — 실제로 그렇기 때문에. 그 습관은 이력서에 드러나지 않고 면접에서 가장하기도 어렵습니다. 그래서 실제 워크플로우를 반영한 과제에서 관찰해야 합니다. 또한 이는 복리 효과를 냅니다. 신중하게 편집하는 상담원은 제품 정책과 모델의 본능이 어디서 갈리는지를 학습하고, 그 간극을 프롬프트 단계에서 선제적으로 메워 시간이 지날수록 초안 수정 필요성이 줄어듭니다.

실전 예제: 분노한 고객의 청구 문의

고객이 예상치 못한 청구에 화가 나 있습니다. 미흡한 접근법은 AI에게 '사과문을 작성하라'고 요청한 뒤 나오는 대로 보냅니다. 강력한 접근법은 모델에게 요금제, 환불 정책, 어조를 제공하고, 정책이 허용하지 않는 것은 무엇도 약속하지 못하도록 명시적으로 금지합니다. 그런 다음 상담원이 초안을 읽고, 무례하게 들리는 문장을 부드럽게 다듬고, 모델이 스스로 추가한 환불 약속을 제거합니다. 같은 도구, 같은 고객, 전혀 다른 결과 — 그 차이는 마지막에 있는 인간의 단계입니다.

## TASK
Draft a reply to the customer message below.

## CONTEXT
- Plan: Pro (monthly). Refund policy: pro-rated, within 14 days only.
- Tone: warm, direct, no corporate filler. Own the mistake.

## RULES
- Promise nothing the policy above doesn't allow
- If their case isn't covered, say so plainly and offer the next step

두 버전이 어떤 결과를 내는지 보세요. 미흡한 프롬프트는 '귀하의 불편을 충분히 이해합니다'로 시작하는 유창한 사과문을 반환하고, 모델이 긴장을 해소하려다 '이 건을 해결해 드리기 위해 전액 환불해 드리겠습니다'라고 약속합니다. 아름답게 읽힙니다. 하지만 두 가지 면에서 잘못됐습니다. 환불은 비례 계산으로 적용되고 전액이 아니며, 청구일은 14일 기간 밖입니다. 그대로 보내면 팀이 손해를 감수하며 이행하거나 철회해야 할 약속을 만들어낸 것입니다. 강력한 프롬프트는 실제 정책에 근거한 초안을 반환하며, 상담원은 여전히 마지막 조각을 담당합니다 — 딱딱한 시작 부분을 다듬고, 청구 충격을 인정하는 인간적인 문장을 추가하며, 답변이 정책이 허용하는 것만을 말하고 그 이상은 말하지 않음을 확인합니다. 강한 버전이 하지 않는 것에 주목하세요. 정책 뒤에 숨지 않습니다. 온기 없는 경계는 기술적으로 정확하더라도 여전히 나쁜 답변입니다. 숙련된 상담원은 한 호흡에 경계와 공감을 동시에 전달합니다 — 모델이 내릴 수 없는 판단입니다. 이 고객이 얼마나 많은 신뢰를 쌓아왔는지 모델은 알지 못하기 때문입니다.

• 강한 접근법: 정책과 어조를 제공하고, 정책에 대조해 정확성을 검증하고, 진정한 공감으로 다듬으며, 모델이 슬며시 넣은 과도한 약속을 잘라냅니다.
• 미흡한 접근법: 정책상 잘못되거나, 어조가 맞지 않거나, 혹은 둘 다인 일반적인 AI 사과문을 보내고, 고객이 회신할 때야 문제를 발견합니다.

두 번째 시나리오: 회색지대 데이터 삭제 요청

청구 문의는 정책이 명확한 규칙이므로 채점하기 쉽습니다. 훌륭한 채용과 뛰어난 채용을 가르는 시나리오는 정책이 요청을 명확하게 포괄하지 않는 회색지대입니다. 해지 후 '내 데이터를 전부 지금 당장 삭제해 달라'는 고객을 예로 들어보세요. 정책은 계정 삭제를 허용하지만 법적 의무 기간 동안 청구 기록을 보유하며, 일부 데이터는 더 느린 주기로 제3자 처리업체에 있습니다. 미흡한 상담원은 모델에게 삭제를 확인해 달라 요청하고, '귀하의 데이터가 완전히 영구적으로 삭제되었습니다'라는 자신감 있는 답변을 받아 보냅니다 — 이는 단순히 사실이 아니며, 일부 관할권에서는 법적 구속력이 있는 주장입니다. 더 강력한 상담원은 모델의 깔끔한 확신보다 정직한 답변이 더 복잡하다는 것을 인식하고, 지금 삭제되는 것, 보유되는 것과 기간, 그리고 다음 단계를 명시하도록 초안을 편집합니다. 이것은 같은 기술의 고차원적 버전입니다 — 지어낸 환불이 아닌 지어낸 확실성을 잡아내는 것입니다.

회색지대 문의는 모델의 적극성이 가장 위험한 곳입니다. 가장 안심할 수 있는 방향으로 모호함을 해소하려 하기 때문입니다. 사실인 방향이 아니라. 상담원의 일은 고객이 마땅히 받아야 할 모호함을 유지하는 것이지, 그것을 덮어버리는 것이 아닙니다. 그것은 압박 하에서의 정직에 대한 판단이며, 현실적인 평가 시나리오가 드러내도록 설계된 바로 그 행동입니다 — 정책이 깔끔한 답을 주는 문의에서는 볼 수 없습니다. 과제를 설계할 때, 깔끔한 답변과 진실된 답변이 서로 갈라지는 프롬프트를 적어도 하나 포함하고, 지원자가 깔끔한 쪽을 선택하는지 관찰하세요.

연차별 기준 조정

같은 과제도 수준에 따라 다르게 읽히며, 연차를 무시한 루브릭은 초급 직원을 걸러내거나 시니어를 과대평가하게 됩니다. 입문 수준 상담원의 기준은 초안을 초안으로 취급하는 것입니다 — 정책에 대조해 읽고, 명백한 과도한 약속을 잡아내고, 모델이 처음 생성한 것을 그대로 보내지 않는 것입니다. 직관을 채용하는 것이지, 아직 세련됨은 아닙니다. 중급 상담원의 경우, 어조 편집과 공감 문장이 프롬프트 없이도 자연스럽게 나와야 하고, 거의 맞는 정책 의역에서 더 미묘한 문제도 눈치채야 합니다. 시니어 상담원이나 팀 리더의 경우, 기준이 다시 올라갑니다. 회색지대 문의를 깔끔하게 처리하고, 단순히 수정하는 것이 아니라 모델이 왜 잘못됐는지를 설명하며, 오류 재발을 방지하는 맥락으로 프롬프트를 미리 구성합니다. 실제로 채용하는 수준에 맞춰 이력을 평가하세요.

실제로 차이를 만드는 모범 사례

• 정책에 근거하세요. 관련 정책을 프롬프트에 붙여넣어 초안이 모델의 추측이 아닌 사실에서 출발하게 합니다.
• 어조를 명시적으로 지정하세요. '따뜻하고, 직접적이며, 실수를 인정하는'은 지침 없는 것과 매우 다른 답변을 만들어냅니다 — 그리고 어조는 고객이 기억하는 것입니다.
• 과도한 약속을 미리 금지하되, 여전히 확인하세요. 적극적인 모델은 정책이 허용하지 않는 호의를 발명하며, 지시 하나만으로는 보장이 되지 않습니다.
• 항상 보내기 전에 편집하세요. 초안은 출발점이며, 정확성과 공감에 대한 인간의 판단이 최종 산출물입니다.
• 가벼운 감사 기록을 유지하세요. 무엇을 왜 변경했는지 메모하면 팀 전체의 개인화 역량을 키우고 코칭을 구체적으로 만듭니다.

역량 수준의 평가 루브릭

기술은 편집에 있으므로, 프롬프트만 단독으로 채점해서는 평가할 수 없습니다. 실제 형태의 문의 앞에서 초안을 가지고 지원자가 무엇을 하는지 관찰하고, 4D 프레임워크 — 위임(Delegation), 설명(Description), 식별(Discernment), 성실(Diligence) — 에 매핑되는 네 가지 역량에 대조해 그 행동을 읽어야 합니다. 각 역량에는 관찰 가능한 바닥과 관찰 가능한 천장이 있으며, 그 사이의 간극이 채용 신호가 위치하는 곳입니다.

• 위임(Delegation) — 모델에 무엇을 맡길지 아는 것. 바닥: 아무 맥락 없이 문의 전체를 붙여넣거나, 도구를 전혀 사용하지 않음. 천장: 초안 작성은 위임하되, 정확성과 공감 결정은 확실히 인간이 담당.
• 설명(Description) — 모델을 어떻게 세팅하는지. 바닥: '사과문을 작성하라'. 천장: 구체적인 정책, 어조, 그리고 정책이 허용하지 않는 것은 무엇도 약속하지 말라는 명시적인 금지를 제공.
• 식별(Discernment) — 초안의 잘못된 부분을 발견하는 것. 바닥: 오타만 확인. 천장: 지어낸 환불, 잘못된 정책 기간, 이미 짜증난 사람에게 무시하는 것처럼 읽히는 문장을 잡아냄.
• 성실(Diligence) — 끝까지 마무리하는 것. 바닥: 문제를 알아채지만 시간 압박 속에 그냥 보냄. 천장: 모든 문제를 수정하고, 정책에 대조해 주장을 검증한 다음에야 발송.

역량을 기준으로 루브릭을 설정하는 것의 가치는 도구가 바뀌어도 살아남는다는 점입니다. 어떤 어시스턴트가 모델 뒤에 있든, 식별과 성실 면에서 최고 점수를 받는 지원자는 다음 분기에도 과도한 약속을 보내지 않을 사람입니다. 그것이 지속 가능한 신호이며, '올바른' 프롬프트 템플릿이 사용됐는지를 세는 것이 아니라 행동을 관찰하는 이유입니다.

흔한 실패 유형

• 초안 그대로 발송: 정책상 잘못됐지만 유창한 답변을 신뢰하는 것.
• 어조 지침 없음: 이미 화가 난 사람에게 차갑거나 무시하는 느낌의 기술적으로 올바른 답변.
• 모델이 추가한 과도한 약속 놓치기 — 가장 비용이 많이 드는 지원 실수. 이제 이행하거나 철회해야 할 약속이 되기 때문.
• 과도한 편집: AI가 아무런 레버리지를 추가하지 않을 정도로 무겁게 재작성하는 것. 이는 대량 처리 시 그 자체로 비효율.
• 자신감 있는 정책 요약에 대한 맹목적 신뢰: 모델이 약관을 살짝 잘못 의역하고, 상담원이 원본을 확인하지 않아 미묘한 오류가 사실로 발송됨.

이들 각각은 뚜렷한 근본 원인을 가지고 있으며, 이는 코칭에 중요합니다. 초안 그대로 발송은 성실 결여이고, 어조 지침 없음은 설명 결여이며, 과도한 편집은 대개 위임 결여로 상담원이 모델이 잘하는 부분은 믿는 법을 아직 배우지 못한 것입니다. '더 주의하세요'와 같은 모호한 말 대신 구체적인 결여를 명시하는 것이 실패한 편집을 가르칠 수 있는 순간으로 바꾸며, 평가가 사용하는 것과 동일한 분류법이므로 평가와 현장 코칭이 하나의 언어를 공유합니다.

지원 채용에서 이 기술의 위치

프롬프트 편집 기술은 여러 신호 중 하나입니다. 지원 분야의 후보자 평가는 정책 이해력, 압박 하의 상황 판단, 폭언하는 고객 앞에서도 상담원을 침착하게 유지시키는 행동 특성도 함께 고려해야 합니다. 이를 다섯 기둥으로 프레임하며, AI 유창성은 그 중 가장 새로운 것입니다 — 대부분의 채용 프로세스가 아직 측정 방법을 찾지 못한 기둥. 다른 기둥을 대체하지 않습니다. 지원자는 초안을 완벽하게 편집하면서도 실제 적대적인 발신자 앞에서 무너질 수 있고, 정책을 완벽하게 읽으면서도 회색지대 사례에서 멈출 수 있습니다. 다섯 기둥의 관점을 갖는 요점은 하나의 기술에 지나치게 치중하는 대신 트레이드오프를 명확하게 볼 수 있다는 것입니다. 더 넓은 스코어카드를 구축한다면, 고객 지원 담당자 채용 방법이 전체 그림을 제시하고, 채용의 다섯 기둥은 각 부분이 어떻게 맞물리는지 설명합니다.

평가 방법

객관식 퀴즈로는 누가 과도한 약속을 잡아내는지 알 수 없고, AI를 금지하면 더 이상 존재하지 않는 워크플로우를 테스트하는 셈입니다. 지원자에게 실제로 사용할 도구가 있는 현실적인 지원 시나리오를 제시하고, 편집을 관찰합니다 — AI Sandbox 평가가 하는 것이 바로 그것입니다. 평가는 자기 신고가 아닌 업무 샘플이므로, 신호는 실제 형태의 과제에서 나타나는 지원자의 실제 행동입니다. 붙여넣은 정책, 잘라낸 과도한 약속, 부드럽게 다듬은 무례한 문장, 발송 전에 검증한 주장. 기술을 대리 지표로 추론하는 것이 아니라, 그것이 일어나는 것을 직접 관찰합니다. 이것이 정직한 테스트인 이유는 AI 네이티브 채용에서 확인하거나, 직무에 맞춰 구성되는 평가를 관찰해 보세요.

이력은 읽는 사람이 무엇을 찾아야 하는지 알 때만 유용하므로, 면접관들이 이력을 열기 전에 간략히 설명해 주세요. AI Sandbox 과제를 처음 읽는 채용 관리자의 본능은 유창한 최종 답변에 감탄하는 것입니다 — 바로 채점해서는 안 되는 것입니다. 매끄러운 답변은 모델이 작동한다는 것을 증명하지, 지원자가 그렇다는 것을 증명하지 않습니다. 면접관들에게 초안과 발송 버전의 차이를 보게 하고, 모든 이력에 대해 세 가지 구체적인 질문을 하게 하세요. 모델이 무엇을 잘못했는지, 지원자가 그것을 잡아냈는지, 어조를 깨뜨리지 않고 수정했는지. AI를 많이 사용하는 것은 위험 신호가 아니고, 적게 사용하는 것이 미덕도 아닙니다. 신호는 그 위에 얹히는 인간 판단의 질입니다. 패널에게 루브릭이 사용하는 것과 동일한 4D 어휘를 제공해 메모가 개인적인 인상이 아니라 지원자 간에 비교 가능하게 합니다.

지원 업무에서 AI는 하루에 수백 개의 답변을 작성할 수 있습니다. 채용하고 싶은 사람은 각각을 읽고 '내가 고객이라면 이 답변이 잘 전달될까?'라고 묻는 사람입니다 — 그리고 답이 '아니오'일 때 수정하는 사람입니다.