분류·평가·작성 과업별 예시 설계

few-shot 예시는 만능 양념처럼 보이지만, 실제로는 과업마다 쓰임새가 꽤 다릅니다. 같은 입력-출력 예시라도 분류 과업에서는 경계선을 가르치는 장치가 되고, 평가 과업에서는 점수 기준을 맞추는 장치가 되며, 작성 과업에서는 문체와 정보 보존 범위를 맞추는 장치가 됩니다.

그래서 중급 단계에서는 이렇게 생각해야 합니다. 예시를 넣을지 말지가 아니라, 지금 내가 맡기려는 일이 어떤 종류의 판단인가를 먼저 구분해야 합니다. 상자에 넣는 일인지, 점수를 매기는 일인지, 문장을 다시 만드는 일인지에 따라 예시의 모양이 달라져야 하기 때문입니다.

이번 장에서는 분류, 평가, 작성이라는 세 가지 과업을 나누어 보고, 같은 few-shot이라도 어디를 설계 포인트로 잡아야 하는지 업무 사례로 익혀 보겠습니다.

같은 예시 기법이 과업마다 달라지는 이유

겉으로 보면 세 과업 모두 비슷해 보입니다. 입력을 주고, 원하는 출력 예시를 몇 개 붙인 뒤, 마지막 입력에 대한 답을 요청하는 방식이기 때문입니다. 하지만 모델이 실제로 배워야 하는 것은 전혀 다릅니다.

이 표를 머릿속에 넣어두면 실무에서 훨씬 판단이 쉬워집니다. 예시를 잘못 설계하는 가장 흔한 이유는 예시의 수가 부족해서가 아니라, 과업에 맞지 않는 예시를 붙였기 때문입니다.

예를 들어 분류 과업인데 작성 예시처럼 길고 감정적인 문장을 붙이면 라벨 경계가 흐려집니다. 반대로 작성 과업인데 분류 예시처럼 짧은 결과만 보여주면, 모델은 어떤 톤과 구조로 써야 하는지 배우지 못합니다. 결국 같은 few-shot이라도, 무엇을 학습시켜야 하는지부터 달라야 합니다.

분류 과업: 라벨 이름보다 경계가 중요하다

분류 과업은 겉보기보다 까다롭습니다. 출력이 짧아서 쉬워 보이지만, 실제로는 어디까지를 같은 범주로 보고 어디서부터 다른 범주로 볼지가 핵심이기 때문입니다. 즉, 분류 예시는 정답을 보여주는 것보다 구분 기준을 압축해서 보여주는 것에 가깝습니다.

고객 문의 분류를 예로 들어 봅시다. 라벨이 배송, 환불, 제품 불량, 기타라고 해도, 실제 문의는 그렇게 깔끔하지 않습니다. 고객은 한 문장에 배송 불만과 제품 상태 불만을 같이 넣고, 교환과 환불을 섞어 말하고, 감정 표현을 덧붙입니다. 이때 예시는 라벨 이름을 설명하는 사전이 아니라, 헷갈릴 때 무엇을 우선으로 볼지 알려주는 업무 규칙집이 되어야 합니다.

고객 문의 분류 예시를 설계하는 법

좋은 분류 예시는 세 가지를 분명히 보여줘야 합니다.

• 각 라벨의 전형적인 사례

• 둘 이상으로 읽힐 수 있는 경계 사례

• 비슷한 단어가 나오지만 다른 라벨로 가야 하는 반례

예를 들어 아래처럼 설계할 수 있습니다.

역할: 고객 문의를 하나의 대표 라벨로 분류한다.
라벨:
- 배송: 배송 지연, 배송 조회 불가, 오배송
- 환불: 환불 요청, 결제 취소 요청
- 제품 불량: 파손, 기능 이상, 구성품 누락
- 기타: 위 세 가지에 명확히 속하지 않는 요청

규칙:
- 반드시 라벨 하나만 출력한다.
- 가장 주된 문제를 기준으로 판단한다.
- 추측하지 않는다.

예시 1
입력: 주문한 상품이 아직 도착하지 않았고 배송 조회도 되지 않습니다.
출력: 배송

예시 2
입력: 박스가 찢어진 상태로 늦게 도착했습니다.
출력: 배송

예시 3
입력: 색상이 생각한 것과 달라 교환하고 싶습니다.
출력: 기타

이제 분류할 입력:
입력: 전원을 켜도 화면이 들어오지 않습니다.
출력:

이 예시 세트의 핵심은 화려한 설명이 아닙니다. 박스가 찢어졌다는 정보가 있어도 팀 기준상 배송을 우선한다는 점, 교환은 환불과 다르다는 점을 가르치는 데 있습니다. 분류 과업에서 예시가 잘 작동하려면 이렇게 라벨 정의보다 실제 충돌 상황을 보여줘야 합니다.

분류 예시에서 자주 하는 실수

분류 과업에서 가장 흔한 실수는 예시가 너무 쉬운 사례로만 이루어지는 것입니다. 배송 문의는 배송, 환불 요청은 환불처럼 누구나 맞힐 수 있는 예시만 모아 두면, 실제 운영에서는 별 도움이 되지 않습니다. 모델이 틀리는 지점은 늘 애매한 입력이기 때문입니다.

또 다른 실수는 출력 형식이 흔들리는 것입니다. 어떤 예시는 라벨만 내고, 어떤 예시는 라벨과 이유를 같이 내면 모델도 일관성을 잃기 쉽습니다. 분류 과업에서는 출력 형식을 가능한 한 단단하게 고정하는 편이 좋습니다. 예를 들어 처음부터 라벨만 출력인지, 라벨 + 한 줄 이유인지 정해야 합니다.

마지막 실수는 라벨 수가 많아졌는데도 예시 수를 거의 늘리지 않는 것입니다. 라벨이 늘어나면 각 범주의 중심 예시도 필요하고, 특히 자주 헷갈리는 쌍을 따로 보여줘야 합니다. 환불과 교환, 배송 지연과 제품 파손처럼 실무에서 자주 엇갈리는 조합이 좋은 재료입니다.

평가 과업: 점수보다 기준을 맞춰야 한다

평가 과업은 분류보다 한 단계 더 미묘합니다. 겉보기에는 1점부터 5점까지 고르면 되는 일 같지만, 실제로는 모델이 기준을 적용하는 방식을 배워야 하기 때문입니다. 그래서 평가 예시는 정답 숫자만 보여주는 것으로는 부족합니다. 왜 그 점수인지가 함께 드러나야 점수대가 안정됩니다.

여기서 중요한 차이가 하나 있습니다. 분류 과업은 주로 어느 상자인가를 묻지만, 평가 과업은 얼마나 가까운가를 묻습니다. 그래서 평가 예시는 인접 점수 간 차이를 또렷하게 보여줘야 합니다. 2점과 3점, 3점과 4점이 어떻게 다른지 흐리면 모델은 점수를 중간값으로 대충 몰아넣기 쉽습니다.

리뷰 감성 분석을 평가형으로 설계하기

긍정/중립/부정처럼 세 라벨로 끝내면 이 과업은 분류에 가깝습니다. 하지만 실무에서는 종종 감정의 세기까지 보고 싶습니다. 예를 들어 1점은 강한 부정, 3점은 혼합 또는 중립, 5점은 강한 긍정처럼 설계하면 이때부터는 평가 과업의 성격이 강해집니다.

좋은 예시는 단순히 점수만 주지 않고, 어떤 표현이 점수에 영향을 주는지 짚어 줍니다.

역할: 리뷰의 감성 강도를 1~5점으로 평가한다.
기준:
- 1점: 매우 부정적이며 강한 불만 또는 사용 불가 수준
- 2점: 부정적이지만 일부 사용 가능, 불만이 중심
- 3점: 긍정과 부정이 섞였거나 판단이 유보됨
- 4점: 대체로 만족하지만 약한 아쉬움이 있음
- 5점: 매우 만족, 강한 추천 또는 재구매 의사 표현

출력 형식:
점수: [1~5]
근거: [리뷰 표현을 바탕으로 한 한 줄 설명]

예시 1
입력: 배송은 빨랐지만 제품 마감이 너무 아쉽네요. 다시 사지는 않을 것 같아요.
출력:
점수: 2
근거: 배송에 대한 긍정 표현이 있으나 전체적으로 불만과 비재구매 의사가 중심이다.

예시 2
입력: 디자인은 마음에 들지만 배터리가 빨리 닳아서 애매합니다.
출력:
점수: 3
근거: 장점과 단점이 함께 있으며 만족 또는 불만 어느 한쪽으로 기울지 않는다.

예시 3
입력: 사용하기 편하고 가격도 괜찮아요. 포장이 조금 아쉬웠지만 전반적으로 만족합니다.
출력:
점수: 4
근거: 사소한 불만이 있으나 전체 평가는 만족 쪽으로 분명히 기운다.

이제 평가할 입력:
입력: 켜지지도 않고 고객센터 연결도 너무 어렵네요. 정말 실망입니다.
출력:

이런 식의 예시는 모델에게 단지 2, 3, 4를 외우게 하지 않습니다. 점수의 결을 가르칩니다. 특히 평가 과업에서는 가운데 점수 주변이 가장 흔들리므로, 극단값만 넣지 말고 붙어 있는 점수대의 차이를 예시로 자주 보여주는 것이 좋습니다.

평가 과업에서 꼭 넣어야 할 것

평가 예시를 설계할 때는 다음 요소가 들어가야 안정성이 높아집니다.

• 점수 또는 등급의 정의

• 인접한 점수대의 비교 예시

• 점수의 이유를 설명하는 짧은 근거 문장

이 세 가지가 빠지면 모델은 숫자를 맞히는 척하면서 사실상 감으로 점수를 던지게 됩니다. 반대로 기준표와 근거가 함께 있으면, 출력이 틀리더라도 어디서 흔들렸는지 나중에 점검하기 쉬워집니다.

작성 과업: 무엇을 바꾸고 무엇을 지킬지 보여줘야 한다

작성 과업은 분류나 평가보다 더 넓고 자유로워 보입니다. 그래서 오히려 예시의 설계가 더 중요합니다. 작성 예시는 단순히 결과 문장을 보여주는 것이 아니라, 변환의 방향을 가르쳐야 합니다. 즉, 무엇은 유지하고 무엇은 바꾸는지 예시 안에서 드러나야 합니다.

작성 과업을 설계할 때는 두 가지 질문이 늘 따라붙습니다. 첫째, 원문의 정보는 얼마나 보존해야 하는가. 둘째, 톤과 형식은 어디까지 바꿔도 되는가. 이 질문에 대한 답이 예시에 담겨 있지 않으면, 모델은 지나치게 자유롭게 써 버리거나 반대로 너무 원문을 베껴 버립니다.

이메일 톤 변환: 내용은 유지하고 말투만 바꾸기

이메일 톤 변환은 작성 과업의 대표적인 예입니다. 겉으로는 간단해 보이지만, 실제로는 말투만 바꾸기가 꽤 어렵습니다. 모델이 자주 저지르는 실수는 두 가지입니다. 원문에 없는 내용을 덧붙이거나, 핵심 요청을 빼먹는 것입니다.

따라서 이 과업의 few-shot 예시는 보존해야 할 정보와 바꿔야 할 톤을 동시에 보여줘야 합니다.

역할: 거친 초안을 정중한 비즈니스 이메일 문장으로 바꾼다.
규칙:
- 핵심 요청 내용은 유지한다.
- 원문에 없는 약속이나 사실을 추가하지 않는다.
- 지나치게 굽히지 않고 차분하고 명확하게 쓴다.

예시 1
입력: 자료 아직 안 왔습니다. 오늘 안에 꼭 보내주세요.
출력: 안녕하세요. 요청드린 자료가 아직 전달되지 않아 확인 부탁드립니다. 가능하시다면 오늘 중으로 보내주시면 업무 진행에 큰 도움이 되겠습니다.

예시 2
입력: 지난번이랑 또 다르게 말씀하시면 저희가 너무 헷갈립니다.
출력: 안녕하세요. 이전 안내와 이번 안내 내용이 달라 업무 진행에 혼선이 있습니다. 기준을 한 번 더 정리해 주시면 동일한 방식으로 반영하겠습니다.

이제 변환할 입력:
입력: 회의 시간 자꾸 바뀌면 준비하기 어렵습니다. 확정되면 한 번에 알려주세요.
출력:

좋은 톤 변환 예시는 결과 문장만 공손하면 되는 것이 아닙니다. 원문의 불만, 요청, 맥락이 어떻게 정리되어 전달되는지 보여줘야 합니다. 다시 말해 작성 과업의 예시는 문장을 꾸미는 샘플이 아니라, 변형 규칙이 보이는 전후 비교표여야 합니다.

보고서 요약: 압축은 하되 해석은 넘지 않기

보고서 요약도 작성 과업이지만, 이메일 톤 변환과는 결이 다릅니다. 이 과업에서는 멋진 문장을 만드는 능력보다 핵심만 남기고 덜어내는 능력이 중요합니다. 따라서 예시는 길이와 톤보다도, 어떤 정보를 남기고 어떤 정보를 버리는지에 초점을 맞춰야 합니다.

보고서 요약 예시를 만들 때는 원문과 요약 결과를 나란히 두고, 요약이 따라야 할 규칙을 먼저 분명히 적는 것이 좋습니다.

역할: 내부 보고서 초안을 3문장 요약으로 압축한다.
규칙:
- 핵심 사실과 결론만 남긴다.
- 원문에 없는 해석이나 의견을 추가하지 않는다.
- 숫자와 일정처럼 중요한 정보는 가능한 한 유지한다.

예시 1
입력: 1분기 캠페인 결과, 신규 가입자는 전분기 대비 12% 증가했다. 다만 전환율은 기대치보다 낮았고, 랜딩 페이지 이탈률이 높았다. 마케팅팀은 2분기에는 메시지보다 랜딩 구조 개선을 우선 과제로 제안했다.
출력: 1분기 캠페인으로 신규 가입자는 전분기 대비 12% 증가했다. 그러나 전환율은 기대에 못 미쳤고 랜딩 페이지 이탈률이 높게 나타났다. 2분기 우선 과제로는 메시지 수정보다 랜딩 구조 개선이 제안되었다.

예시 2
입력: 고객 인터뷰 15건을 진행한 결과, 가격 자체보다 결제 과정의 복잡함이 구매 포기를 유발하는 경우가 많았다. 특히 모바일 환경에서 주소 입력과 쿠폰 적용 단계가 불편하다는 의견이 반복되었다. 이에 따라 제품팀은 결제 단계 축소와 모바일 입력 개선안을 다음 스프린트에 포함하기로 했다.
출력: 고객 인터뷰 15건에서 구매 포기의 주요 원인은 가격보다 복잡한 결제 과정으로 나타났다. 특히 모바일에서 주소 입력과 쿠폰 적용 단계의 불편이 반복적으로 지적되었다. 제품팀은 다음 스프린트에 결제 단계 축소와 모바일 입력 개선안을 반영하기로 했다.

이제 요약할 입력:
입력: [보고서 본문]
출력:

이 예시의 포인트는 요약이 원문보다 짧아졌다는 사실 자체가 아닙니다. 핵심 지표, 문제, 다음 행동처럼 어떤 정보 구조를 남기는지 보여주는 데 있습니다. 요약 과업에서는 이런 구조적 일관성이 중요합니다.

같은 입력도 과업이 바뀌면 예시가 달라진다

few-shot 설계가 과업 의존적이라는 사실은, 같은 입력을 놓고 보면 더 선명하게 드러납니다. 예를 들어 이런 리뷰가 있다고 해봅시다.

배송은 빨랐지만 제품 소음이 커서 실망했습니다.

이 문장은 과업에 따라 전혀 다른 예시가 필요합니다. 분류 과업이라면 배송과 제품 불량 중 어디로 보낼지를 가르쳐야 합니다. 평가 과업이라면 부정 감정의 강도를 몇 점으로 볼지와 그 이유를 보여줘야 합니다. 작성 과업이라면 이 리뷰를 고객센터 전달용 요약 문장으로 바꾸거나, 내부 회의용 이슈 문장으로 정리하는 예시가 필요합니다.

즉, 입력 문장이 아니라 출력에서 요구하는 판단 방식이 예시를 결정합니다. 이 감각이 잡히면 예시 설계가 훨씬 쉬워집니다. 실무에서는 같은 자료를 두고도 분류, 평가, 작성이 섞여 나오기 때문에, 먼저 과업 타입을 분리하는 습관이 중요합니다.

과업별 최소 예시 세트 만들기

실무에서는 언제나 시간이 부족합니다. 그래서 거대한 예시 세트를 만들기보다, 과업별로 최소한의 안정성을 주는 기본 세트를 먼저 만드는 편이 효율적입니다.

분류 과업이라면 각 라벨의 중심 사례와 자주 헷갈리는 경계 사례가 먼저 필요합니다. 평가 과업이라면 점수 정의와 인접 점수 비교 예시가 우선입니다. 작성 과업이라면 전후 변환 예시와 함께 무엇을 유지할지를 보여주는 예시가 핵심입니다.

정리하면 출발점은 보통 이 정도면 충분합니다.

• 분류: 대표 예시 2개와 경계 사례 1~2개

• 평가: 점수대 앵커 예시 3개 이상과 근거 문장

• 작성: 전후 변환 예시 2~3개와 금지 규칙

이후에 예시를 늘릴지는 실제 실패 로그를 보고 결정하면 됩니다. 자주 틀리는 입력이 나타날 때 그 케이스를 추가하는 방식이 가장 실용적입니다. 중급 설계에서는 예시를 처음부터 완벽하게 만드는 것보다, 실패를 수집해 예시 세트를 점점 똑똑하게 만드는 태도가 더 중요합니다.

실무에서 바로 쓰는 점검 질문

예시 세트를 만든 뒤에는 반드시 마지막 점검을 해야 합니다. 이 단계가 빠지면 예시는 있어도 성능은 흔들립니다.

분류 과업이라면 이렇게 물어보면 됩니다. 각 라벨의 중심이 보이는가, 헷갈리는 쌍이 들어 있는가, 라벨 출력 형식이 한 번도 흔들리지 않는가. 평가 과업이라면 점수 기준이 문장으로 정의되어 있는가, 붙어 있는 점수 차이가 예시로 드러나는가, 근거가 함께 제시되는가를 확인해야 합니다. 작성 과업이라면 원문에서 유지해야 할 요소가 예시에서 보이는가, 바꾸면 안 되는 정보가 새로 생기지 않는가, 톤과 길이의 기준이 일관적인가를 봐야 합니다.

이 질문에 선뜻 답하기 어렵다면, 예시 수를 늘리기 전에 먼저 과업 정의를 다시 다듬는 편이 낫습니다. few-shot은 프롬프트의 빈칸을 마법처럼 메워 주는 장치가 아니라, 이미 정리된 기준을 선명하게 보여주는 도구이기 때문입니다.

이 장의 핵심 정리

few-shot 예시는 과업마다 같은 방식으로 쓰이지 않습니다. 분류 과업에서는 라벨의 경계와 우선순위를 가르쳐야 하고, 평가 과업에서는 점수 기준과 인접 점수의 차이를 보여줘야 하며, 작성 과업에서는 무엇을 바꾸고 무엇을 유지할지 전후 비교로 드러내야 합니다.

중요한 것은 예시의 개수보다 예시의 역할입니다. 분류는 어느 상자에 넣을지, 평가는 어떤 기준으로 몇 점을 줄지, 작성은 어떻게 바꾸되 무엇은 지킬지를 가르쳐야 합니다. 이 차이를 이해하면, 예시는 더 이상 단순한 샘플 모음이 아니라 실무형 성능을 안정화하는 설계 도구가 됩니다.

다음 장에서는 이렇게 설계한 기준을 바탕으로, 사람이 읽기 좋을 뿐 아니라 다음 작업에도 바로 연결되는 표, 목록, 체크리스트 형태의 구조화 출력을 만드는 법을 살펴보겠습니다.