고객 지원(Customer Support) 업무를 하고 있다면, AI는 업무의 지루한 70% — 즉, 상투적인 답변, 스레드 요약, 매크로 초안 작성 — 를 대신 처리하고, 인간이 실제로 필요로 하는 부분인 판단력, 공감, 그리고 복잡한 예외 사례(Edge cases)에 집중할 수 있게 해줍니다.

저는 지난 1년 동안 지원 업무를 위한 프롬프트(Prompts)를 다듬어 왔습니다. 아래는 제가 매주 사용하는 10가지 프롬프트입니다. 각각의 프롬프트는 구조와 중요한 제약 조건(Constraints)을 갖추고 있으며, 좋은 결과물이 무엇인지 확인할 수 있도록 실제 출력 예시를 포함하고 있습니다.

모든 프롬프트에 적용되는 패턴은 다음과 같습니다: 역할(Role) → 문맥(Context) → 제약 조건(Constraints) → 출력 형식(Output format). 제약 조건을 건너뛰면 일반적이고 품질 낮은 결과물(Slop)을 얻게 되지만, 이를 유지하면 실제로 바로 보낼 수 있는 결과물을 얻을 수 있습니다.

1. 매크로처럼 들리지 않는 매크로

역할(Role): 당신은 재사용 가능한 매크로를 작성하는 시니어 지원 전문가(Senior support specialist)입니다.
문맥(Context): 제품은 {product}입니다. 일반적인 이슈: {issue}. 고객 등급: {free/pro/enterprise}.
**제약 조건(Constraints):

• 최대 4문장.
• "Hi there!" 또는 "Thanks for reaching out!" 같은 표현 금지 — 바로 답변으로 시작할 것.
• 이슈가 실제로 우리의 잘못이 아닌 한 사과하지 말 것.
• "추가 도움이 필요하면 알려주세요"가 아닌, 하나의 구체적인 다음 단계로 끝낼 것.
• 우회 방법(Workaround)이 있다면, 근본 원인(Root-cause) 설명 전에 언급할 것.

출력(Output): 티켓에 바로 붙여넣을 수 있는 매크로 본문.

예시 (이슈: 웹훅(Webhook) 전달 지연):

현재 처리 클러스터의 백로그(Backlog)로 인해 웹훅 전달이 약 15분 정도 지연되고 있습니다. 전달이 누락되는 것은 아니며, 모두 완료되지만 지연될 뿐입니다. 백로그를 해소할 때까지의 우회 방법으로, 60초 간격으로 /events 엔드포인트를 폴링(Poll)할 수 있습니다. 한 시간 이내에 상태 페이지(Status page)에 업데이트를 게시하겠습니다.

2. 로봇처럼 들리지 않게 화난 티켓의 상황을 완화하기 (De-escalating)

역할(Role): 당신은 에스컬레이션(Escalated)된, 좌절한 고객을 응대하는 지원 팀장(Support lead)입니다.
문맥(Context): 티켓: {티켓 내용 붙여넣기}. 고객은 {메시지에서 나타난 감정 상태 기술} 상태입니다.
**제약 조건(Constraints):

• 첫 문장은 고객이 설명한 구체적인 영향(impact)을 인정해야 합니다. 일반적인 "불편을 드려 죄송합니다"와 같은 표현은 피하세요.
• 우리가 잘못한 부분을 명확하게 명시하세요. "~인 것 같습니다"와 같은 모호한 표현은 사용하지 마세요.
• 본인이 통제할 수 없는 해결 완료 시점을 약속하지 마세요.
• 정확히 두 가지 옵션만 제공하세요: (a) 지금 당장 할 수 있는 일, (b) 고객이 기다리기를 원할 경우 할 수 있는 일.
• 말투(Tone): 사과하는 부하 직원이 아닌, 차분한 동료의 태도를 유지하세요.

출력(Output): 답장 초안.

3. 엔지니어링을 위한 스레드 요약 (실제로 읽히는 요약본)

역할(Role): 당신은 긴 티켓 스레드를 엔지니어링 팀을 위해 요약하는 서포트 엔지니어(Support Engineer)입니다.
컨텍스트(Context): 전체 스레드: {스레드 붙여넣기}. 의심되는 버그 영역: {영역}.
제약 조건(Constraints):

• 다음 구조를 사용하세요: 고객의 기대 사항 / 발생한 현상 / 재현 단계(Steps to reproduce) / 재현율(Reproduction rate) / 계정 + 리소스 ID / 이미 시도한 조치 사항.
• "재현 단계(Steps to reproduce)"는 번호를 매겨야 하며, 각 단계는 하나의 동작이어야 합니다.
• "재현율(Reproduction rate)"은 "가끔"과 같은 표현이 아닌 분수(예: 5회 시도 중 3회)로 작성해야 합니다.
• 요약에서 모든 인사말, 서명, 주고받은 대화 내용을 삭제하세요. 엔지니어링 팀은 "업데이트된 내용 있나요?"와 같은 확인 메시지를 읽을 필요가 없습니다.
• 고객이 로그를 공유했다면, 의역하지 말고 정확한 에러 라인을 인용하세요.

출력(Output): Slack 스레드나 버그 티켓에 적합한 형식으로 작성된 200단어 이내의 요약.

4. 고객 지원 관점에서의 변경 로그(Changelog) 항목 작성

역할(Role): 당신은 고객 지원 팀이 관련 티켓을 처리해 온 수정 사항(fix)에 대해 고객용 변경 로그(Changelog) 항목을 작성하고 있습니다.
컨텍스트(Context): 수정 사항: {설명}. 이 수정으로 해결되는 티켓: {개수 또는 주제}.
제약 조건(Constraints):

• 내부적으로 무엇을 변경했는지가 아니라, 고객이 무엇을 체감하게 될지를 중심으로 서술하세요.
• 증상에 대해 한 문장, 수정 사항에 대해 한 문장, 그리고 문제가 계속될 경우 어떻게 해야 하는지에 대해 한 문장으로 작성하세요.
• 고객용 문구에는 버전 번호나 내부 식별자를 포함하지 마세요.
• 고객 측의 조치가 필요한 경우, 마지막에 굵게(bold) 표시하여 알리세요.

출력(Output): 변경 로그 항목 (3~4문장).

5. 이탈 위험 계정을 위한 이탈 방지(Churn-save) 이메일

역할 (Role): 당신은 이탈 위험 신호를 보낸 계정에 이메일을 작성하는 고객 성공 매니저 (Customer Success Manager)입니다.
맥락 (Context): 계정: {name}. 신호: {사용량 감소 / 고객 지원 불만 / 다운그레이드 요청}. 계약 가치: {tier}. 마지막 긍정적 상호작용: {내용}.
제약 사항 (Constraints):

• 첫 번째 이메일에서 할인을 제안하지 마세요. 할인은 고객이 이탈을 위협하도록 학습시킵니다.

• 제품을 통해 얻은 구체적인 성과를 하나 언급하세요 (사용량 데이터에서 추출).

• 표준 버그 템플릿을 작성하세요: 제목 (Title) / 환경 (Environment) / 재현 단계 (Steps to reproduce) / 기대 결과 (Expected) / 실제 결과 (Actual) / 심각도 (Severity) / 빈도 (Frequency) / 첨부 파일 (Attachments).

• 고객이 단계를 제공하지 않았다면, 임의로 지어내지 말고 "단계가 제공되지 않음 — 고객에게 요청 중"이라고 작성하세요.

• 심각도 (Severity)는 긴급성(urgency)이 아닌 영향력(impact)을 사용하여 한 문장으로 정당화해야 합니다 (예: "고객이 매우 화가 남"이 아니라 "모바일 사용자의 100%가 결제를 진행할 수 없음").

• 엔지니어링 팀이 가장 먼저 확인해야 할 가장 가능성 높은 관련 코드 영역 3가지를 나열하세요.

출력 (Output): 작성된 버그 보고서.

8. 혼란스러워하는 신규 사용자를 위한 온보딩(Onboarding) 답변

역할 (Role): 당신은 어디서부터 시작해야 할지 혼란스러워하는 신규 사용자에게 답변하고 있습니다.
컨텍스트 (Context): 제품: {product}. 사용자의 가입 신호: {사용자가 하고 싶다고 말한 내용}.
제약 사항 (Constraints):

• 문서를 안내할 때 홈 페이지로 보내지 마세요. 사용자의 목표와 일치하는 특정 페이지 하나만 링크하세요.
• 탐색해야 할 5가지 목록을 주는 대신, 정확히 하나의 첫 번째 행동만을 제시하세요.
• 방법을 알려주기 전에 사용자가 달성하려는 것이 무엇인지 인정(Acknowledge)하세요.
• 6문장 이내로 유지하세요. 과도한 설명은 제품이 복잡하다는 신호를 줍니다.

출력 (Output): 답변.

9. 반복되는 티켓 테마에 대한 분기별 검토 (Quarterly review)

역할 (Role): 당신은 제품 및 프로세스 개선을 위해 지난 분기의 티켓을 분석하는 지원 매니저(Support manager)입니다.
컨텍스트 (Context): 티켓 테마 (목록 또는 CSV 붙여넣기): {themes}. 테마별 볼륨: {counts}.
제약 사항 (Constraints):

• 다음 3가지 범주로 그룹화하세요: 제품 버그 (product bugs) / 문서 공백 (documentation gaps) / 기능 요청 (feature requests).
• 각 테마에 대해 (구체적인 해결책이 아닌) 예상되는 근본 원인 카테고리를 명시하세요.
• 단순 볼륨이 아닌 {볼륨 × 심각도}에 따라 순위를 매기세요.
• 최상위 테마를 제거할 수 있는 하나의 프로세스 변경 사항을 제안하세요 — 도구가 아닌 프로세스여야 합니다.
• 해결책으로 "추가 교육"을 권장하지 마세요.

출력 (Output): 우선순위가 지정된 표를 포함하여 400단어 이내의 검토 보고서.

10. 답장을 유도하는 문제 해결 후 후속 조치 (Post-resolution follow-up)

역할 (Role): 당신은 티켓(ticket) 해결 3일 후, 수정 사항이 유지되고 있는지 확인하기 위해 후속 조치(follow-up) 메일을 보내는 역할입니다.
컨텍스트 (Context): 원래 문제: {issue}. 해결 방법: {what we did}.
제약 사항 (Constraints):

• 제목은

• Developer Product-Launch Prompt Pack ($9) — 제품 출시를 위한 7가지 프롬프트: gum.co/qevvy

• Developer Productivity Prompt Library ($49) — 엔지니어링 및 지원 워크플로우 (workflows)를 위한 30가지 프롬프트: gum.co/plytri

• SaaS Marketing Copy Prompt Pack ($49) — 랜딩 페이지 (landing pages), 이메일, 광고를 위한 25가지 프롬프트: gum.co/orcwxs

• AI Startup Operations Prompt System ($199) — AI로 회사를 운영하기 위한 50개 이상의 프롬프트 + 10가지 워크플로우 (workflows): gum.co/aeqnd

• AI Business Transformation Playbook ($999) — 100개 이상의 프롬프트 + 12가지 워크플로우 (workflows), 전체 시스템: gum.co/boivub

$9 팩은 가장 저렴하게 시작할 수 있는 방법입니다. 만약 이 팩이 티켓 작성 세션을 단 한 번이라도 줄여준다면, 이미 본전은 뽑은 셈입니다.

특정한 프롬프트 자체보다 그 패턴이 더 중요합니다. **역할 (Role) → 맥락 (Context) → 제약 사항 (Constraints) → 출력 형식 (Output format)**의 구조를 내재화하고 나면, 업무 중 반복되는 어떤 부분에 대해서도 자신만의 프롬프트를 작성할 수 있습니다. 위의 프롬프트들은 제가 실제 티켓 (tickets) 상황에서도 유효하다고 판단한 것들일 뿐입니다.

만약 여러분에게 효과적인 지원 (support) 프롬프트가 있다면, 진심으로 공유해주셨으면 합니다. 가장 훌륭한 프롬프트는 언제나 티켓 (tickets)과 가장 가까이 있는 분들에게서 나오기 때문입니다.