예시로 가르치는 법

예시는 말보다 빠른 업무 교육이다

프롬프트를 잘 쓰는 사람은 길게 설명하는 사람이 아니라, AI가 따라 할 수 있는 좋은 예시를 보여 주는 사람이다. 사람에게 일을 가르칠 때도 마찬가지다. "고객 문의를 잘 분류해 주세요"라고 말하는 것보다, 실제 문의 세 개를 꺼내 놓고 "이건 결제 문제, 이건 계정 문제, 이건 배송 문제야"라고 보여 주면 훨씬 빨리 배운다.

AI에게도 예시는 일종의 업무 샘플이다. 물론 여기서 "배운다"는 말은 모델 자체가 새로 훈련된다는 뜻이 아니다. 대화창 안에서 사용자가 보여 준 패턴을 보고, 그 대화의 남은 부분에서 비슷한 방식으로 답하려는 것이다. 그래서 예시는 작은 업무 매뉴얼처럼 작동한다. 출력 형식, 판단 기준, 문체, 세부 표현을 한꺼번에 전달한다.

지난 장에서 프롬프트의 기본 문법을 목표, 맥락, 제약, 출력 형식, 성공 기준으로 나누어 보았다. 이번 장에서는 그 문법을 한 단계 더 강하게 만드는 방법을 다룬다. 바로 zero-shot, one-shot, few-shot이다. 이름은 낯설지만 원리는 단순하다. 예시 없이 시키느냐, 예시 하나를 보여 주느냐, 예시 여러 개를 보여 주느냐의 차이다.

중요한 것은 예시를 많이 넣는 것이 항상 정답은 아니라는 점이다. 예시는 강력한 만큼 위험하다. 잘 만든 예시는 AI의 답변을 안정시킨다. 반대로 나쁜 예시는 AI를 좁은 틀에 가두거나, 잘못된 판단 기준을 학습시킨 듯한 효과를 낸다. 예시는 약이 될 수도 있고, 독이 될 수도 있다.

zero-shot, one-shot, few-shot의 차이

먼저 세 용어를 간단히 정리해 보자. 여기서 shot은 "문제와 답의 예시 한 묶음" 정도로 이해하면 된다.

세 방식은 우열 관계가 아니다. 쉬운 업무라면 zero-shot이 가장 빠르고 충분하다. 내부 양식이나 문체가 중요한 업무라면 one-shot만으로도 품질이 크게 좋아진다. 판단 기준이 미묘하거나 출력 형식이 반드시 일정해야 하는 업무라면 few-shot이 유리하다.

예를 들어 "다음 문장을 존댓말로 바꿔 줘"는 zero-shot으로도 잘된다. 그러나 "한국 대기업 임원 보고용 문체로 바꾸되, 과장된 수식어는 줄이고, 리스크와 다음 행동이 보이게 정리해 줘"라면 예시가 있는 편이 훨씬 낫다. '임원 보고용'이라는 말은 조직마다 다르게 쓰이기 때문이다. 어떤 회사에서는 건조한 개조식 문장을 뜻하고, 어떤 회사에서는 배경과 판단 근거가 포함된 정중한 문단을 뜻한다. 이럴 때 예시는 단어의 뜻을 고정해 주는 닻이 된다.

고객 문의 분류로 보는 세 방식의 차이

가장 먼저 고객 문의 분류 작업을 보자. 고객센터나 CX 팀에서 자주 하는 일이다. 문의 내용을 보고 주제를 나누고, 감정 강도와 우선순위를 정한 뒤, 담당자에게 넘겨야 한다.

zero-shot: 지시만 주기

다음 고객 문의를 분류하라.

문의:
"환불 신청한 지 일주일이 지났는데 아직 입금이 안 됐어요. 상담원마다 말이 달라서 너무 답답합니다."

이렇게만 입력해도 AI는 대체로 쓸 만한 답을 준다. 예를 들면 "환불 지연", "불만", "긴급" 같은 분류가 나올 수 있다. 문제는 출력 형식이 매번 달라질 수 있다는 점이다. 어떤 때는 문장으로 설명하고, 어떤 때는 표로 만들고, 어떤 때는 감정 분석까지 붙인다. 사람이 한 번 읽고 끝낼 작업이라면 괜찮지만, 여러 건을 모아 시스템에 넣거나 팀원이 같은 기준으로 처리해야 한다면 불안정하다.

조금 더 나은 zero-shot 프롬프트는 출력 형식을 지정한다.

다음 고객 문의를 분류하라.

출력 형식:
- 분류:
- 감정 강도: 낮음/보통/높음
- 우선순위: 낮음/보통/긴급
- 권장 응대 방향:

문의:
"환불 신청한 지 일주일이 지났는데 아직 입금이 안 됐어요. 상담원마다 말이 달라서 너무 답답합니다."

이제 답은 훨씬 정돈된다. 그러나 여전히 "긴급"의 기준이 무엇인지, "분류"에 어떤 내부 용어를 써야 하는지는 애매하다.

one-shot: 예시 하나로 형식 보여 주기

작업: 고객 문의를 분류하고 응대 방향을 제안하라.

예시
입력: "결제가 두 번 됐어요. 빨리 취소해 주세요."
출력:
- 분류: 결제/중복청구
- 감정 강도: 높음
- 우선순위: 긴급
- 권장 응대 방향: 먼저 불편에 공감하고, 결제 내역 확인 및 환불 예상 일정을 안내한다.

이제 아래 문의를 같은 형식으로 처리하라.

입력: "환불 신청한 지 일주일이 지났는데 아직 입금이 안 됐어요. 상담원마다 말이 달라서 너무 답답합니다."

one-shot의 장점은 즉각적이다. AI는 예시의 라벨 구조를 따라 "분류: 환불/처리지연"처럼 답할 가능성이 높아진다. 감정 강도와 우선순위도 예시의 기준을 참고한다. 형식이 고정되고, 응대 방향의 문체도 비슷해진다.

다만 예시가 하나뿐이면 위험도 있다. 예시가 결제 문제였기 때문에, AI가 환불 지연도 무조건 "결제" 범주로 묶을 수 있다. 또는 예시에서 "빨리"라는 표현 때문에 긴급으로 판단했는데, 새 문의에서는 "일주일"이라는 시간 지연과 상담 불일치를 더 중요하게 봐야 한다. one-shot은 빠르지만, 기준을 충분히 보여 주지는 못한다.

few-shot: 여러 예시로 판단 기준까지 보여 주기

작업: 고객 문의를 분류하고 응대 방향을 제안하라.

분류 라벨은 다음 중 하나를 사용하라.
- 결제/중복청구
- 환불/처리지연
- 계정/로그인
- 배송/수령
- 제품/사용법
- 기타

예시 1
입력: "결제가 두 번 됐어요. 빨리 취소해 주세요."
출력:
- 분류: 결제/중복청구
- 감정 강도: 높음
- 우선순위: 긴급
- 권장 응대 방향: 불편에 공감한 뒤 중복 결제 확인 절차와 환불 예상 일정을 안내한다.

예시 2
입력: "환불 접수했다고 들었는데 아직 입금이 안 됐습니다. 언제 처리되나요?"
출력:
- 분류: 환불/처리지연
- 감정 강도: 보통
- 우선순위: 보통
- 권장 응대 방향: 접수 상태를 확인하고, 처리 단계와 예상 소요 시간을 명확히 안내한다.

예시 3
입력: "비밀번호 재설정 메일이 안 와요. 로그인을 못 하고 있습니다."
출력:
- 분류: 계정/로그인
- 감정 강도: 보통
- 우선순위: 보통
- 권장 응대 방향: 메일 수신함 확인, 재전송, 본인 확인 절차를 단계별로 안내한다.

이제 아래 문의를 같은 기준과 형식으로 처리하라.

입력: "환불 신청한 지 일주일이 지났는데 아직 입금이 안 됐어요. 상담원마다 말이 달라서 너무 답답합니다."

few-shot은 단순히 형식을 맞추는 데서 끝나지 않는다. 예시 1과 예시 2가 함께 있으면 "결제 오류"와 "환불 지연"을 구분하는 기준이 생긴다. 예시 2와 새 입력을 비교하면, 새 문의는 환불 지연이면서 감정 강도가 더 높다는 점도 드러난다. 예시 3은 계정 문제를 따로 분리해 라벨 범위를 넓힌다.

결국 few-shot은 AI에게 이렇게 말하는 것과 같다. "우리가 쓰는 분류 체계는 이것이고, 감정 강도는 이런 식으로 판단하며, 답변은 이 길이와 톤으로 작성해." 말로 길게 설명할 수도 있지만, 예시 세 개가 더 빠르고 선명할 때가 많다.

요약 작업: 무엇을 중요하게 볼지 가르치기

요약은 쉬워 보이지만 실제로는 어려운 작업이다. "짧게 줄여 줘"라고 하면 AI는 대체로 문장을 압축한다. 그러나 실무 요약은 단순 압축이 아니다. 무엇을 남기고 무엇을 버릴지 판단해야 한다. 특히 한국어 보고서에서는 배경, 쟁점, 리스크, 다음 행동의 비중이 중요하다.

다음은 보고서 요약을 zero-shot으로 요청하는 예다.

아래 내용을 임원 보고용으로 요약해 줘.

[보고서 원문]

이 프롬프트는 편하지만 결과가 흔들릴 수 있다. 어떤 답은 너무 친절하게 배경을 길게 설명하고, 어떤 답은 숫자만 나열한다. 어떤 답은 근거 없는 결론을 만들어 붙인다. "임원 보고용"이라는 말이 충분히 구체적이지 않기 때문이다.

one-shot을 넣으면 상황이 달라진다.

작업: 긴 업무 보고를 임원 보고용 1페이지 요약으로 바꿔라.

예시
입력 요지:
신규 멤버십 캠페인은 가입자 수가 목표 대비 112%를 기록했으나, 유료 전환율은 목표보다 낮았다. 광고비는 예상보다 18% 초과 집행되었다. 고객 설문에서는 혜택 이해도가 낮다는 의견이 많았다.

출력:
- 핵심 결론: 가입자 확보는 목표를 초과했으나, 유료 전환과 비용 효율은 개선이 필요함.
- 주요 근거: 가입자 수 목표 대비 112%, 광고비 18% 초과, 혜택 이해도 관련 부정 의견 증가.
- 리스크: 캠페인 구조를 유지할 경우 비용 대비 전환 효율이 낮아질 가능성.
- 다음 행동: 혜택 메시지를 단순화하고, 전환율 기준으로 광고 채널 예산을 재배분할 것.

이제 아래 원문을 같은 형식으로 요약하라.

[보고서 원문]

이 예시는 단순한 양식이 아니다. 판단 기준을 포함한다. "목표 초과"라는 좋은 소식과 "전환율 미달"이라는 나쁜 소식을 동시에 살리고, 결론을 한 문장으로 균형 있게 정리한다. 숫자는 근거로 배치하고, 리스크와 다음 행동을 분리한다. AI는 이 패턴을 따라 원문에서 중요한 요소를 고르려 한다.

few-shot으로 발전시키려면 서로 다른 상황의 예시를 넣는 것이 좋다. 성공 사례 하나, 실패 사례 하나, 정보 부족 사례 하나를 함께 보여 주면 요약의 기준이 더 튼튼해진다.

작업: 업무 보고 원문을 임원 보고용 요약으로 바꿔라.

공통 규칙:
- 원문에 없는 수치는 만들지 않는다.
- 정보가 부족한 항목은 "추가 확인 필요"라고 쓴다.
- 결론은 성과와 리스크를 함께 담아 한 문장으로 쓴다.

예시 1: 성과는 좋지만 비용 리스크가 있는 경우
입력 요지: 가입자 수는 목표 초과, 광고비는 초과 집행, 전환율은 낮음.
출력:
- 핵심 결론: 외형 성과는 확보했으나 비용 효율과 유료 전환 개선이 필요함.
- 주요 근거: 가입자 수 목표 초과, 광고비 초과, 전환율 미달.
- 리스크: 비용 증가가 지속될 경우 캠페인 수익성이 낮아질 수 있음.
- 다음 행동: 채널별 전환율을 기준으로 예산을 재배분.

예시 2: 성과 판단에 정보가 부족한 경우
입력 요지: 고객 만족도가 개선되었다고 보고되었으나 조사 표본 수와 비교 기준이 없음.
출력:
- 핵심 결론: 만족도 개선 가능성은 있으나, 표본과 비교 기준이 없어 성과 판단은 보류가 필요함.
- 주요 근거: 만족도 개선 언급 있음, 표본 수 미제시, 전월 또는 전년 대비 기준 없음.
- 리스크: 불충분한 근거로 성과를 확정할 경우 의사결정 오류 가능성.
- 다음 행동: 표본 수, 조사 방식, 비교 기준을 추가 확인.

예시 3: 실행 지연이 핵심인 경우
입력 요지: 시스템 개편 일정이 협력사 이슈로 2주 지연되었고, 내부 테스트 일정도 밀릴 가능성이 있음.
출력:
- 핵심 결론: 외부 협력사 이슈로 일정 지연이 발생했으며 내부 테스트 일정까지 영향을 받을 수 있음.
- 주요 근거: 개편 일정 2주 지연, 협력사 이슈 발생, 내부 테스트 일정 연쇄 지연 가능성.
- 리스크: 출시 일정 지연 및 고객 공지 일정 변경 가능성.
- 다음 행동: 협력사 복구 일정 확인 후 내부 테스트 계획을 재조정.

이제 아래 원문을 같은 기준으로 요약하라.

[보고서 원문]

이 정도가 되면 AI는 "좋은 요약"을 단지 짧은 요약으로 이해하지 않는다. 근거가 부족할 때 억지로 결론을 내리지 않는 태도까지 따라 하게 된다. 실무에서 중요한 것은 바로 이 지점이다. 좋은 few-shot은 답의 모양뿐 아니라 판단의 습관을 보여 준다.

문체 변환: 한국어에서는 예시 하나가 설명 열 줄보다 강하다

한국어 업무에서 예시의 힘이 가장 크게 드러나는 곳은 문체 변환이다. 한국어에는 높임말, 완곡한 표현, 개조식 보고 문장, 공문서식 표현, 고객 응대 톤, 사내 메신저 톤이 섞여 있다. "정중하게"라는 말만으로는 부족하다. 정중하되 너무 굽히지 않아야 할 때도 있고, 단호하되 차갑지 않아야 할 때도 있다.

예를 들어 다음 요청은 그럴듯하지만 애매하다.

아래 문장을 고객에게 보내기 좋은 정중한 문장으로 바꿔 줘.

원문:
"환불은 안 됩니다. 규정상 불가능합니다."

AI는 이렇게 쓸 수 있다.

죄송하지만 규정상 환불은 어려운 점 양해 부탁드립니다.

나쁘지 않다. 그러나 회사의 응대 기준에 따라서는 부족할 수 있다. 왜 안 되는지, 대신 무엇을 도와줄 수 있는지, 고객 감정을 어떻게 완충할지가 빠져 있기 때문이다. one-shot 예시를 넣어 보자.

작업: 단호하지만 무례하지 않은 고객 안내문으로 바꿔라.

예시
원문: "교환 기간 지났으니 교환 안 됩니다."
변환: "확인해 주셔서 감사합니다. 해당 상품은 교환 가능 기간이 지나 교환 처리는 어려운 점 안내드립니다. 다만 사용 중 불편 사항이 있으시면 확인 후 가능한 지원 방법을 안내드리겠습니다."

이제 아래 문장을 같은 톤으로 바꿔라.

원문: "환불은 안 됩니다. 규정상 불가능합니다."

이 예시는 톤을 정확히 보여 준다. 첫 문장에서는 고객의 문의를 인정하고, 두 번째 문장에서는 불가 사유를 단호하게 말하며, 세 번째 문장에서는 대안을 열어 둔다. "정중하게"라는 추상어보다 훨씬 선명하다.

보고서 문체도 마찬가지다. 다음 두 문장은 모두 한국어지만 조직에서 주는 인상은 다르다.

일반 문장:
이번 캠페인은 생각보다 반응이 좋았지만, 돈이 좀 많이 들어서 다음에는 조정이 필요할 것 같습니다.

임원 보고 문장:
캠페인 반응은 목표 대비 양호하나, 집행 비용이 예상보다 높아 차기 집행 시 채널별 효율 기준의 예산 재조정이 필요합니다.

문체 변환 few-shot을 만들 때는 같은 의미가 서로 다른 톤으로 어떻게 바뀌는지 보여 주면 좋다. 특히 한국어에서는 문장 끝맺음, 주어 생략, 한자어 사용 정도, 책임 표현의 강도가 결과 품질을 좌우한다.

작업: 사내 메신저 문장을 임원 보고 문체로 바꿔라.

규칙:
- 감정 표현은 줄이고 사실과 판단을 분리한다.
- "좀", "많이", "괜찮은 것 같습니다" 같은 구어체 표현은 쓰지 않는다.
- 필요한 경우 "추가 확인 필요"를 표시한다.

예시 1
입력: "고객 반응은 꽤 좋은데 문의가 좀 많이 들어와요."
출력: "고객 반응은 긍정적이나, 관련 문의 증가로 운영 부담이 확대되고 있습니다."

예시 2
입력: "개발 일정이 살짝 밀릴 것 같아요. 외주 쪽 답이 늦습니다."
출력: "외부 협력사 회신 지연으로 개발 일정 지연 가능성이 있습니다. 정확한 지연 기간은 추가 확인 필요합니다."

예시 3
입력: "광고비를 많이 쓴 것치고 구매가 별로 안 나왔습니다."
출력: "광고비 집행 규모 대비 구매 전환 성과가 낮아 채널별 효율 점검이 필요합니다."

이제 아래 문장을 같은 방식으로 변환하라.

입력: [변환할 문장]

이 프롬프트는 한국어 조직 문서에서 매우 유용하다. 단순히 예쁜 문장으로 바꾸는 것이 아니라, 말의 책임 수준을 조정한다. 실무자는 이렇게 변환된 문장을 그대로 쓰기보다, 숫자와 근거를 추가해 최종 문서로 다듬으면 된다.

few-shot이 안정화하는 세 가지

few-shot이 특히 강한 이유는 세 가지를 동시에 안정화하기 때문이다.

첫째, 출력 형식을 안정화한다. "표로 정리해 줘"라고 말하는 것보다 실제 표 예시를 보여 주는 편이 더 확실하다. 열 이름, 값의 길이, 빈칸 처리 방식까지 자연스럽게 전달된다.

둘째, 판단 기준을 안정화한다. 분류 작업에서 라벨 이름만 주면 AI가 비슷한 라벨을 헷갈릴 수 있다. 예시를 주면 "이런 경우는 긴급, 이런 경우는 보통"이라는 기준이 생긴다.

셋째, 문체와 톤을 안정화한다. "친절하게", "전문적으로", "간결하게" 같은 말은 사람마다 해석이 다르다. 예시는 그 단어의 해석 범위를 좁힌다.

이 세 가지가 합쳐지면 업무 결과가 팀 안에서 재사용 가능해진다. 한 사람이 프롬프트를 만들어 두면 다른 사람도 비슷한 품질의 결과를 얻을 수 있다. 그래서 few-shot은 개인의 요령이 아니라 팀의 표준으로 발전할 수 있다.

좋은 예시를 고르는 법

좋은 few-shot은 예시를 많이 넣은 프롬프트가 아니다. 대표성이 있는 예시를 적절히 고른 프롬프트다. 예시가 너무 많으면 입력할 실제 문서가 들어갈 공간이 줄어들고, AI가 핵심 지시보다 예시의 표면적 특징에 끌릴 수 있다.

좋은 예시를 고를 때는 다음 기준을 적용하자.

• 대표 사례를 넣는다. 가장 자주 발생하는 유형을 먼저 보여 준다.

• 경계 사례를 넣는다. 라벨이 헷갈리거나 판단이 어려운 사례를 포함한다.

• 실패 방지 사례를 넣는다. 근거 부족, 정보 누락, 민감정보 포함처럼 조심해야 할 상황을 보여 준다.

• 출력 길이를 맞춘다. 예시 답변이 너무 길면 실제 답변도 길어질 가능성이 높다.

• 라벨과 용어를 통일한다. 같은 뜻을 "긴급", "높음", "우선"처럼 섞어 쓰면 결과도 흔들린다.

예를 들어 고객 문의 분류에서 "배송이 늦어요"와 "언제 오나요?"만 예시로 넣으면 배송 문제에는 강해지지만 결제, 계정, 환불 문의에는 약해진다. 반대로 모든 가능한 유형을 30개씩 넣으면 프롬프트가 비대해지고, 실제 처리할 입력보다 예시가 더 중요한 것처럼 보일 수 있다. 보통은 핵심 유형 3~5개, 경계 사례 1~2개 정도로 시작해 결과를 보며 조정하는 편이 좋다.

또 하나의 요령은 예시의 순서다. 가장 표준적인 예시를 먼저 두고, 예외나 경계 사례는 뒤에 두는 것이 안전하다. 첫 예시가 너무 특이하면 AI가 그 특이한 패턴을 기본값으로 착각할 수 있다.

나쁜 예시는 어떻게 AI를 망가뜨리는가

예시는 강력하기 때문에 잘못된 예시는 문제를 크게 만든다. 나쁜 예시가 들어간 few-shot은 차라리 예시 없는 zero-shot보다 못할 수 있다.

가장 흔한 문제는 편향이다. 예를 들어 고객 감정 분석 예시에서 반말을 쓰는 고객은 모두 "악성"으로 분류하고, 존댓말을 쓰는 고객은 모두 "정상"으로 분류해 두면 AI도 말투만 보고 고객을 판단할 수 있다. 실제로는 반말을 썼더라도 정당한 불만일 수 있고, 존댓말을 쓰더라도 심각한 법적 리스크가 담긴 문의일 수 있다.

두 번째 문제는 과적합이다. 과적합은 원래 기계학습에서 특정 예시에 지나치게 맞춰져 새로운 상황에 약해지는 현상을 말한다. 프롬프트에서도 비슷한 일이 생긴다. 예시가 모두 세 문장짜리 입력이라면, AI는 긴 문서가 들어와도 억지로 세 문장처럼 처리하려 할 수 있다. 예시가 모두 마케팅 문서라면, 재무 보고서를 넣었을 때도 마케팅식 표현으로 바꿔 버릴 수 있다.

세 번째 문제는 잘못된 일반화다. 예시 하나에서 "환불"이라는 단어가 나오면 긴급으로 분류했기 때문에, AI가 모든 환불 문의를 긴급으로 볼 수 있다. 그러나 환불 문의에도 단순 일정 확인이 있고, 중복 청구처럼 즉시 처리해야 하는 문제가 있다. 라벨은 단어 하나가 아니라 맥락으로 판단해야 한다.

나쁜 예시의 또 다른 형태는 출력이 서로 충돌하는 경우다. 예시 1에서는 "감정 강도: 높음"이라고 쓰고, 예시 2에서는 같은 수준의 표현을 "감정 강도: 보통"이라고 쓰면 AI는 기준을 잡기 어렵다. 사람도 서로 다른 선배가 다른 방식으로 가르치면 헷갈린다. AI도 마찬가지다.

따라서 few-shot을 만들 때는 예시를 넣기 전에 스스로 물어봐야 한다. "이 예시는 우리 팀의 기준을 제대로 보여 주는가?" "우연히 들어간 표현을 AI가 규칙으로 착각하지 않을까?" "예시끼리 서로 같은 기준을 쓰고 있는가?" 이 질문에 답하지 못하면 예시는 늘릴수록 위험해진다.

한국어 업무에 바로 쓰는 예시 패턴

이제 한국어 업무에서 자주 쓰는 few-shot 패턴을 네 가지로 정리해 보자. 그대로 복사해 쓰기보다, 자신의 조직 라벨과 문체에 맞게 바꾸는 것이 좋다.

패턴 1: 고객 문의 분류

이 패턴은 고객센터, 영업지원, 커뮤니티 운영, 앱 리뷰 분석에 모두 쓸 수 있다. 핵심은 라벨을 먼저 고정하고, 예시로 감정 강도와 우선순위 기준을 보여 주는 것이다.

작업: 고객 문의를 내부 처리용으로 분류하라.

라벨:
- 결제/환불
- 계정/로그인
- 배송/수령
- 제품/사용법
- 불만/클레임
- 제휴/기타

출력 형식:
- 라벨:
- 감정 강도: 낮음/보통/높음
- 우선순위: 낮음/보통/긴급
- 담당 부서:
- 첫 응대 문장:
- 주의할 점:

예시 1
입력: "결제가 두 번 됐습니다. 오늘 안에 취소해 주세요."
출력:
- 라벨: 결제/환불
- 감정 강도: 높음
- 우선순위: 긴급
- 담당 부서: 결제 운영
- 첫 응대 문장: "중복 결제로 불편을 드려 죄송합니다. 결제 내역을 우선 확인한 뒤 취소 가능 여부와 예상 처리 시간을 안내드리겠습니다."
- 주의할 점: 결제 정보 확인 전 환불 완료를 단정하지 않는다.

예시 2
입력: "로그인하려고 하는데 인증 메일이 오지 않습니다."
출력:
- 라벨: 계정/로그인
- 감정 강도: 보통
- 우선순위: 보통
- 담당 부서: 계정 지원
- 첫 응대 문장: "로그인에 불편을 겪고 계신 점 확인했습니다. 인증 메일 수신 상태와 재발송 방법을 순서대로 안내드리겠습니다."
- 주의할 점: 본인 확인 전 계정 정보를 노출하지 않는다.

예시 3
입력: "제품 설명에는 된다고 되어 있는데 실제로는 작동하지 않습니다. 허위 광고 아닌가요?"
출력:
- 라벨: 불만/클레임
- 감정 강도: 높음
- 우선순위: 긴급
- 담당 부서: 고객 품질 대응
- 첫 응대 문장: "안내 내용과 실제 사용 경험이 달라 불편을 느끼신 점 확인했습니다. 제품 정보와 사용 환경을 확인해 정확한 조치 방향을 안내드리겠습니다."
- 주의할 점: 법적 판단을 단정하지 말고 사실 확인을 우선한다.

이제 아래 문의를 같은 기준으로 처리하라.

입력: [고객 문의]

이 패턴의 장점은 응대 문장까지 함께 만든다는 것이다. 단순 분류만 하면 후속 작업이 남지만, 첫 응대 문장을 만들면 상담원이 바로 검토하고 수정할 수 있다. 단, 결제 정보, 계정 정보, 주민등록번호 같은 민감정보가 들어온 경우에는 반드시 비식별화와 내부 정책을 우선해야 한다.

패턴 2: 보고서 요약

보고서 요약 패턴은 단순 요약보다 "의사결정 보조"에 가깝다. 핵심은 결론, 근거, 리스크, 다음 행동을 분리하는 것이다.

작업: 아래 원문을 한국어 비즈니스 보고용 요약으로 정리하라.

규칙:
- 원문에 없는 수치나 사실을 만들지 않는다.
- 불확실한 내용은 "추가 확인 필요"라고 쓴다.
- 문체는 간결한 보고체로 작성한다.

출력 형식:
| 항목 | 내용 |
|---|---|
| 한 줄 결론 |  |
| 핵심 근거 |  |
| 리스크 |  |
| 다음 행동 |  |
| 추가 확인 필요 |  |

예시 1
입력 요지: 신규 프로모션으로 방문자는 증가했지만 구매 전환율은 하락했다. 광고비는 계획 대비 15% 초과했다.
출력:
| 항목 | 내용 |
|---|---|
| 한 줄 결론 | 방문자 확대 성과는 있었으나 구매 전환율과 비용 효율 개선이 필요함. |
| 핵심 근거 | 방문자 증가, 구매 전환율 하락, 광고비 계획 대비 15% 초과. |
| 리스크 | 현 구조를 유지할 경우 비용 증가 대비 매출 기여가 제한될 수 있음. |
| 다음 행동 | 채널별 전환율을 비교해 저효율 광고비를 조정. |
| 추가 확인 필요 | 채널별 광고비, 구매 전환율 기준 기간. |

예시 2
입력 요지: 고객 만족도가 개선되었다는 언급은 있으나 조사 대상, 표본 수, 비교 기준이 없다.
출력:
| 항목 | 내용 |
|---|---|
| 한 줄 결론 | 만족도 개선 가능성은 있으나 근거 정보가 부족해 성과 확정은 어려움. |
| 핵심 근거 | 만족도 개선 언급은 있으나 조사 대상, 표본 수, 비교 기준이 미제시됨. |
| 리스크 | 불충분한 근거로 성과를 확정할 경우 후속 의사결정 오류 가능성. |
| 다음 행동 | 조사 설계와 비교 기준을 확인한 뒤 성과 판단. |
| 추가 확인 필요 | 표본 수, 조사 기간, 전월 또는 전년 대비 수치. |

이제 아래 원문을 같은 형식으로 요약하라.

원문:
[보고서 원문]

표 형식은 팀 협업에 특히 좋다. 여러 사람이 같은 항목을 채우면 비교가 쉽고, 나중에 데이터베이스나 문서 템플릿으로 옮기기도 편하다. 다만 표가 너무 복잡하면 AI가 칸을 빠뜨릴 수 있으므로 처음에는 5개 안팎의 열이나 행으로 시작하는 편이 안전하다.

패턴 3: 회의록 정리

회의록은 AI가 잘하는 작업처럼 보이지만, 실제로는 위험한 작업이기도 하다. 회의에서 결정되지 않은 내용을 결정된 것처럼 쓰거나, 발언자의 의도를 과하게 정리할 수 있기 때문이다. 그래서 예시에서 "결정 사항"과 "논의 사항"을 엄격히 구분해야 한다.

작업: 회의 메모를 실행 가능한 회의록으로 정리하라.

규칙:
- 결정된 내용과 논의만 된 내용을 구분한다.
- 담당자와 기한이 없는 일은 "미정"으로 표시한다.
- 발언 내용을 과장하거나 합의된 것처럼 쓰지 않는다.

출력 형식:
1. 회의 요약
2. 결정 사항
3. 할 일
4. 쟁점 및 미결 사항
5. 다음 회의 전 확인할 내용

예시
입력 메모:
"마케팅 랜딩페이지 개편 이야기함. 디자인은 A안이 낫다는 의견 많았음. 개발팀은 다음 주 수요일까지 가능할지 확인 필요. 예산은 아직 확정 안 됨. 대표님은 전환율 지표 꼭 넣으라고 함."

출력:
1. 회의 요약
마케팅 랜딩페이지 개편 방향을 논의했으며, 디자인 A안에 대한 선호 의견이 많았다. 개발 일정과 예산은 추가 확인이 필요하다.

2. 결정 사항
- 전환율 지표를 랜딩페이지 성과 기준에 포함한다.

3. 할 일
| 할 일 | 담당자 | 기한 |
|---|---|---|
| 개발 가능 일정 확인 | 개발팀 | 다음 주 수요일 |
| 예산 확정 가능 여부 확인 | 미정 | 미정 |

4. 쟁점 및 미결 사항
- 디자인 A안 채택 여부는 의견이 많았으나 최종 결정 여부가 명확하지 않음.
- 개편 예산이 확정되지 않음.

5. 다음 회의 전 확인할 내용
- 개발팀 일정 가능 여부
- 예산 범위
- 디자인 A안 최종 승인 여부

이제 아래 회의 메모를 같은 기준으로 정리하라.

입력 메모:
[회의 메모]

이 패턴에서 가장 중요한 문장은 "담당자와 기한이 없는 일은 미정으로 표시한다"이다. 회의록 자동화의 실패는 대개 AI가 빈칸을 그럴듯하게 채울 때 발생한다. 좋은 회의록 프롬프트는 멋진 문장을 만드는 것보다 빈칸을 빈칸으로 남기는 능력이 중요하다.

패턴 4: 표 생성

표 생성은 few-shot의 효과가 매우 큰 작업이다. 열 이름, 값의 단위, 문장 길이, 누락 정보 표시 방식을 예시로 보여 주면 결과가 안정된다.

작업: 아래 문장을 업무 관리용 표로 변환하라.

규칙:
- 담당자가 명시되지 않으면 "미정"이라고 쓴다.
- 날짜가 없으면 "미정"이라고 쓴다.
- 상태는 "대기", "진행 중", "완료", "확인 필요" 중 하나만 사용한다.

예시 1
입력: "지윤 님이 금요일까지 고객 설문 문항을 정리하고, 민수 님은 결과 대시보드 초안을 다음 주 월요일까지 만들기로 했습니다."
출력:
| 업무 | 담당자 | 기한 | 상태 |
|---|---|---|---|
| 고객 설문 문항 정리 | 지윤 | 금요일 | 진행 중 |
| 결과 대시보드 초안 작성 | 민수 | 다음 주 월요일 | 진행 중 |

예시 2
입력: "보안 검토는 해야 하는데 담당자는 아직 정하지 않았습니다."
출력:
| 업무 | 담당자 | 기한 | 상태 |
|---|---|---|---|
| 보안 검토 | 미정 | 미정 | 확인 필요 |

이제 아래 문장을 같은 형식의 표로 변환하라.

입력:
[업무 메모]

표 생성에서 자주 생기는 문제는 AI가 상태 값을 마음대로 만드는 것이다. "진행 예정", "보류", "검토 중"처럼 비슷하지만 다른 값을 쓰면 후속 자동화가 어려워진다. 그래서 상태 값 후보를 미리 정하고, 예시에서도 정확히 같은 값을 써야 한다.

예시를 쓰지 않는 편이 나은 경우

예시는 유용하지만 모든 작업에 필요한 것은 아니다. 오히려 예시가 방해가 되는 경우도 있다.

먼저, 작업이 아주 단순하면 예시가 불필요하다. "이 문장을 3문장으로 요약해 줘" 정도라면 출력 형식만 지정해도 충분하다. 예시를 넣느라 시간이 더 들 수 있다.

둘째, 창의적 발상이 필요한 초안 단계에서는 예시가 결과를 좁힐 수 있다. 특정 광고 카피 예시를 여러 개 넣으면 AI가 그 톤에 갇혀 비슷한 표현만 반복할 수 있다. 이때는 먼저 zero-shot으로 다양한 아이디어를 넓게 받은 뒤, 마음에 드는 방향을 골라 one-shot이나 few-shot으로 다듬는 편이 좋다.

셋째, 예시에 민감정보나 내부 기밀이 포함된다면 사용하지 않는 것이 원칙이다. 실제 고객 문의, 계약서, 의료 정보, 인사 평가 문장 등을 예시로 넣을 때는 반드시 비식별화해야 한다. 예시는 재사용되기 쉽기 때문에 한 번 잘못 만든 템플릿이 팀 전체로 퍼질 수 있다.

넷째, 구조화 출력이 매우 엄격해야 한다면 예시만 믿지 말고 스키마나 검증 절차를 함께 써야 한다. 예시는 "이렇게 생겼다"를 보여 주지만, 기계적으로 오류를 막아 주지는 않는다. JSON 필드가 반드시 필요하거나 내부 시스템에 바로 넣어야 하는 데이터라면 다음 장들에서 다룰 구조화 출력과 검증 루프가 필요하다.

예시 프롬프트를 만드는 기본 공식

실무에서 바로 쓸 수 있는 기본 공식은 다음과 같다.

작업: [무엇을 할지 한 문장으로 설명]

맥락: [누가, 어떤 목적으로, 어디에 쓸 결과인지 설명]

규칙:
- [반드시 지킬 조건 1]
- [반드시 지킬 조건 2]
- [모르면 어떻게 할지]

출력 형식:
[원하는 표, 목록, JSON, 문단 구조]

예시 1
입력: [대표 사례]
출력: [좋은 답변]

예시 2
입력: [다른 유형 또는 경계 사례]
출력: [좋은 답변]

예시 3
입력: [정보 부족 또는 주의 사례]
출력: [좋은 답변]

이제 아래 입력을 같은 기준으로 처리하라.

입력:
[실제 처리할 내용]

이 공식에서 가장 중요한 부분은 마지막 문장이다. "같은 기준으로 처리하라." 이 문장은 AI에게 예시를 단순 참고 자료가 아니라 현재 작업의 판단 기준으로 사용하라고 알려 준다. 반대로 예시와 다른 형식으로 답해도 된다면 "예시는 참고만 하고, 입력의 성격에 맞게 더 적절한 형식을 선택하라"고 써야 한다.

실습: 나쁜 프롬프트를 few-shot으로 고치기

아래와 같은 프롬프트를 자주 볼 수 있다.

고객 리뷰를 분석해서 정리해 줘.

리뷰:
[리뷰 모음]

이 프롬프트는 너무 넓다. 분석이 감정 분석인지, 불만 요인 추출인지, 제품 개선 아이디어인지 알 수 없다. 출력 형식도 없다. 이제 few-shot을 적용해 보자.

작업: 고객 리뷰를 제품 개선 회의용으로 정리하라.

목표:
리뷰에서 반복되는 불만 요인과 개선 기회를 찾는다.

규칙:
- 리뷰에 없는 내용을 추측하지 않는다.
- 개별 고객을 식별할 수 있는 정보는 요약에서 제외한다.
- 감정 표현은 완화하되, 문제의 심각성은 숨기지 않는다.

출력 형식:
| 주제 | 고객 반응 | 근거 표현 | 심각도 | 개선 제안 |
|---|---|---|---|---|

예시 1
입력: "앱이 자꾸 튕겨서 주문을 못 했어요. 세 번이나 다시 했습니다."
출력:
| 주제 | 고객 반응 | 근거 표현 | 심각도 | 개선 제안 |
|---|---|---|---|---|
| 앱 안정성 | 주문 과정에서 반복 오류로 불편을 겪음 | "자꾸 튕겨서", "세 번이나" | 높음 | 주문 단계 오류 로그를 확인하고 앱 안정성 개선 우선순위를 높임 |

예시 2
입력: "배송은 빨랐는데 포장이 찌그러져 왔어요. 선물용이라 난감했습니다."
출력:
| 주제 | 고객 반응 | 근거 표현 | 심각도 | 개선 제안 |
|---|---|---|---|---|
| 포장 품질 | 빠른 배송에도 포장 훼손으로 만족도가 낮아짐 | "포장이 찌그러져", "선물용이라 난감" | 보통 | 선물용 상품의 포장 검수 기준을 강화함 |

예시 3
입력: "가격은 괜찮은데 설명서가 너무 어려워요. 부모님은 못 보실 것 같아요."
출력:
| 주제 | 고객 반응 | 근거 표현 | 심각도 | 개선 제안 |
|---|---|---|---|---|
| 사용 설명 | 설명서 난도가 높아 일부 고객층의 사용 장벽이 있음 | "설명서가 너무 어려워요", "부모님은 못 보실 것" | 보통 | 쉬운 용어 중심의 빠른 시작 가이드를 추가함 |

이제 아래 리뷰 모음을 같은 기준으로 분석하라.

리뷰:
[리뷰 모음]

바뀐 프롬프트는 훨씬 강하다. 목표가 제품 개선 회의로 좁혀졌고, 개인정보와 추측 금지 규칙이 들어갔다. 예시는 심각도 판단과 개선 제안의 수준을 보여 준다. 이제 결과는 단순한 감상 요약이 아니라 회의에서 바로 쓸 수 있는 재료가 된다.

예시를 관리하는 팀의 습관

개인 사용자는 좋은 예시를 대화창에 넣고 끝낼 수 있다. 하지만 팀에서 AI를 쓰려면 예시를 자산으로 관리해야 한다. 잘 만든 few-shot은 업무 노하우가 압축된 문서이기 때문이다.

팀에서 예시를 관리할 때는 최소한 세 가지를 정해 두는 것이 좋다.

• 예시의 출처와 버전을 남긴다. 언제, 어떤 업무 기준으로 만든 예시인지 기록한다.

• 라벨과 용어 사전을 함께 관리한다. 분류명이 바뀌면 예시도 같이 고쳐야 한다.

• 실패 사례를 반영한다. AI가 자주 틀리는 입력을 발견하면 경계 사례로 추가한다.

예를 들어 고객 문의 분류 라벨이 "결제/환불"에서 "결제", "환불", "정산"으로 나뉘었다면 기존 few-shot은 더 이상 안전하지 않다. 예시가 낡으면 AI도 낡은 기준으로 답한다. 그래서 예시 프롬프트는 한 번 만들고 끝나는 문서가 아니라, 실제 업무와 함께 업데이트되는 운영 문서에 가깝다.

한 문장으로 정리하기

zero-shot은 빠르다. one-shot은 형식과 톤을 잡아 준다. few-shot은 판단 기준까지 안정화한다. 한국어 업무에서는 특히 문체, 보고 관행, 조직 라벨, 고객 응대 톤이 중요하므로 예시의 효과가 크다.

하지만 예시는 만능이 아니다. 좋은 예시는 AI에게 일을 가르치지만, 나쁜 예시는 AI에게 잘못된 습관을 심어 준다. 예시를 넣기 전에 먼저 생각해야 한다. "이 예시는 우리가 원하는 기준을 정확히 보여 주는가?" 그 질문에 답할 수 있다면, 프롬프트는 단순한 요청문을 넘어 작은 업무 매뉴얼이 된다.

다음 장에서는 이 매뉴얼을 더 단단하게 만드는 방법을 다룬다. 예시가 AI에게 "이렇게 해"를 보여 주는 장치라면, 역할 설계와 지시의 계층은 "누가 어떤 책임으로 어디까지 해야 하는가"를 정하는 장치다. 좋은 예시와 명확한 역할이 만날 때, 프롬프트는 비로소 개인의 요령을 넘어 반복 가능한 업무 시스템이 된다.