좋은 예시와 나쁜 예시

좋은 예시는 모델에게 정답 몇 개를 보여주는 자료가 아닙니다. 더 정확히 말하면, 무엇을 따라야 하고 무엇을 피해야 하는지 알려주는 작은 기준집에 가깝습니다. 그래서 예시 설계에서 중요한 것은 개수가 아니라 역할입니다. 예시를 열 개 넣었는데도 결과가 흔들릴 수 있고, 네 개만 넣었는데도 결과가 놀랄 만큼 안정될 수 있습니다.

중급 단계에서 예시는 "많이 보여주기"의 문제가 아니라 "어디를 보여줄지"의 문제입니다. 중심이 되는 대표 예시가 있어야 하고, 헷갈리는 회색지대를 보여주는 경계 사례가 있어야 하며, 비슷해 보여도 아니라는 것을 알려주는 반례가 있어야 합니다. 여기에 절대 따라 하면 안 되는 금지 사례까지 더해지면, 모델은 훨씬 또렷한 선 안에서 움직이게 됩니다.

예시는 답안이 아니라 기준의 지도다

사람에게 일을 가르칠 때도 비슷합니다. "이렇게 하면 돼"라고 말하는 것만으로는 부족할 때가 많습니다. 오히려 "이건 전형적인 정답이고, 이건 헷갈리기 쉬운 경우고, 이건 비슷하지만 아니고, 이건 절대 하면 안 된다"까지 보여줘야 판단의 모양이 잡힙니다.

모델도 마찬가지입니다. 특히 분류, 평가, 톤 변환, 요약 스타일 통일 같은 과업에서는 예시가 단순한 샘플이 아니라 판단의 경계선을 알려주는 장치가 됩니다. 좋은 예시는 모델이 중심을 배우게 하고, 나쁜 예시는 모델을 엉뚱한 방향으로 자신감 있게 밀어버립니다.

예시를 설계할 때 먼저 가져야 할 질문은 이것입니다.

"이 예시는 정답 하나를 보여주는가, 아니면 기준을 가르치는가?"

중급 설계에서는 언제나 두 번째가 더 중요합니다.

대표 예시: 기준의 중심을 보여주는 샘플

대표 예시는 가장 먼저 넣어야 하는 예시입니다. 말 그대로 "우리가 보기에 가장 전형적인 정답"을 보여줍니다. 모델은 이 예시를 통해 과업의 기본 리듬을 배웁니다. 출력 길이, 말투, 정보의 밀도, 라벨 선택 방식 같은 기본값이 여기서 정해집니다.

예를 들어 고객 문의를 분류하는 프롬프트를 만든다고 해봅시다. 라벨은 배송, 환불, 제품 불량, 기타 네 가지입니다. 이때 대표 예시는 누구나 봐도 큰 이견이 없는 사례여야 합니다.

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

이 예시는 특별하지 않습니다. 오히려 그래서 좋습니다. 대표 예시는 똑똑해 보이려고 복잡할 필요가 없습니다. 가장 흔하고, 가장 전형적이고, 가장 기준이 분명한 것이어야 합니다.

대표 예시가 좋은지 판단하는 기준은 단순합니다.

• 실제 업무에서 자주 등장하는가

• 해석의 여지가 지나치게 많지 않은가

• 우리가 원하는 출력 형식을 가장 깔끔하게 보여주는가

• 다른 예시들의 기준점이 되어줄 수 있는가

대표 예시가 약하면 뒤의 예시가 아무리 좋아도 전체 세트가 흔들립니다. 중심이 흐릿한 지도를 들고 길을 찾는 것과 같기 때문입니다.

경계 사례: 회색지대를 보여주는 샘플

대표 예시만으로는 부족한 이유가 여기에 있습니다. 실무에서는 전형적인 사례보다 애매한 사례가 더 자주 문제를 일으킵니다. 경계 사례는 바로 그 지점을 겨냥합니다. 둘 이상의 규칙이 동시에 걸릴 수 있는 입력, 혹은 한 라벨로 보기에는 찜찜하지만 결국 하나를 골라야 하는 입력을 보여주는 것입니다.

예를 들어 이런 문의를 생각해봅시다.

예시 2
입력: 상품이 늦게 도착했는데 포장도 찢어져 있었어요.
출력: 배송

이 문장은 배송 문제처럼 보이기도 하고 제품 문제처럼 보이기도 합니다. 이럴 때 경계 사례는 단순히 답을 알려주는 역할을 넘어서, 우선순위 규칙을 가르칩니다. 이 팀은 이런 경우 배송 이슈를 먼저 본다는 사실을 예시 하나로 전달하는 셈입니다.

경계 사례가 중요한 이유는, 모델이 틀리는 순간이 대개 바로 이런 회색지대이기 때문입니다. 쉬운 문제는 원래 잘합니다. 성능 차이는 애매한 곳에서 드러납니다.

경계 사례를 고를 때는 다음을 기억하면 좋습니다.

• 실무에서 자주 헷갈리는 조합을 넣을 것

• 사람도 잠깐 멈칫할 입력을 고를 것

• 답뿐 아니라 판단 기준이 드러나게 만들 것

• 한 번에 너무 많은 변수를 섞지 말 것

경계 사례는 어려운 문제를 자랑하기 위한 장식이 아닙니다. 모델이 가장 쉽게 미끄러지는 곳에 미리 안전펜스를 세우는 작업입니다.

반례: 비슷해 보여도 아니라는 것을 가르치는 샘플

반례는 자주 과소평가됩니다. 하지만 반례가 없으면 모델은 겉모양이 비슷한 입력을 같은 방식으로 처리하려는 경향을 보입니다. 반례의 역할은 간단합니다. "이건 닮았지만 같은 것이 아니다"를 가르치는 것입니다.

아까와 같은 분류 과업을 이어가 보겠습니다.

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

왜 이 예시가 반례가 될까요. 얼핏 보면 환불과 비슷해 보이기 때문입니다. 하지만 실제 요청은 환불이 아니라 교환입니다. 즉, 돈을 돌려달라는 문제가 아니라 처리 유형이 다른 요청입니다. 이런 반례가 없으면 모델은 환불과 교환을 자주 섞어버릴 수 있습니다.

반례는 특히 다음 상황에서 유용합니다.

첫째, 단어는 비슷하지만 의도는 다른 경우입니다. 예를 들어 "취소하고 싶다"와 "변경하고 싶다"는 비슷해 보이지만 처리 로직이 완전히 다를 수 있습니다.

둘째, 형식은 비슷하지만 목표가 다른 경우입니다. 보고서 요약과 의견 덧붙이기는 모두 글쓰기처럼 보이지만, 하나는 압축이고 하나는 해석입니다.

셋째, 감정은 비슷하지만 라벨은 다른 경우입니다. 고객이 불만을 표현했다고 해서 모두 환불이나 불만 접수는 아닙니다.

반례가 강한 프롬프트는 모델에게 "닮았다는 이유만으로 같은 상자에 넣지 마라"라고 가르칩니다. 이것은 생각보다 큰 차이를 만듭니다.

금지 사례: 절대 넘어가면 안 되는 선을 그어주는 샘플

금지 사례는 가장 강한 예시입니다. 대표 예시가 중심을 만들고, 경계 사례가 회색지대를 밝히고, 반례가 착각을 막는다면, 금지 사례는 위험한 행동을 직접 막습니다.

금지 사례는 보통 이런 상황에서 필요합니다. 잘못된 답이 단순히 어색한 수준을 넘어, 실무상 문제를 만들 때입니다. 고객 응대에서 책임을 단정해버리거나, 문서 요약에서 원문에 없는 내용을 지어내거나, 분류 과업에서 라벨을 두 개 붙여버리는 경우가 여기에 해당합니다.

예를 들어 고객 응대 초안 작성 프롬프트를 생각해봅시다.

금지 예시
입력: 상담원마다 말이 달라서 신뢰가 안 갑니다.
잘못된 출력: 저희는 잘못이 없고, 상담원마다 안내가 다를 수 있습니다.
금지 이유: 고객 책임으로 돌리는 말투이며, 불만 완화에 실패한다.

이 금지 사례가 주는 힘은 큽니다. 모델은 단순히 "친절하게 써라"라는 지시보다, 어떤 문장이 실제로 문제인지를 훨씬 선명하게 이해합니다.

금지 사례를 넣을 때는 이유를 함께 적는 편이 좋습니다. "하지 마"만으로는 부족합니다. 왜 금지되는지까지 써야 모델이 금지의 원인을 학습합니다. 예를 들어 다음과 같이 쓸 수 있습니다.

• 없는 사실을 단정하지 말 것

• 고객 탓으로 들리는 표현을 쓰지 말 것

• 내부 정책에 없는 보상을 약속하지 말 것

• 입력에 없는 추측을 덧붙이지 말 것

금지 사례는 모델을 겁주기 위한 장치가 아닙니다. 위험 비용이 큰 영역에서 결과를 안정화하는 가장 실용적인 방법입니다.

좋은 예시 세트는 네 가지 역할이 함께 있다

실무에서 예시를 넣을 때 많은 사람이 대표 사례만 몇 개 나열하고 끝냅니다. 하지만 그렇게 하면 모델은 중심은 배워도 경계는 배우지 못합니다. 좋은 예시 세트는 네 가지 역할이 함께 들어 있어야 합니다.

이 네 가지를 갖춘 예시 세트는 단순한 샘플 모음이 아닙니다. 하나의 미니 운영 규칙집처럼 작동합니다.

예시가 많아도 성능이 오르지 않는 이유

예시를 많이 넣었는데도 결과가 만족스럽지 않은 경우가 있습니다. 이럴 때 사람들은 보통 예시 수를 더 늘립니다. 그러나 문제의 원인은 개수 부족이 아니라, 예시 품질 부족인 경우가 더 많습니다.

가장 흔한 문제는 예시들이 모두 비슷하다는 것입니다. 대표 사례 다섯 개를 넣어도, 사실상 같은 패턴만 반복하고 있다면 모델이 새롭게 배우는 것은 거의 없습니다. 중심만 다섯 번 본 셈이지, 경계나 반례는 한 번도 못 본 셈입니다.

또 다른 문제는 예시끼리 기준이 다르다는 것입니다. 어떤 예시는 짧고 단정하게 답하고, 어떤 예시는 장황하고 감정적으로 답하면 모델은 두 가지 신호를 동시에 받습니다. 예시 수가 늘수록 더 똑똑해지는 것이 아니라, 더 혼란스러워질 수도 있습니다.

마지막으로, 너무 긴 예시는 핵심을 묻습니다. 실무 프롬프트에서 좋은 예시는 소설처럼 자세한 예시가 아니라, 판단 기준이 잘 보이는 압축된 예시입니다. 예시의 목적은 현실을 완벽하게 복제하는 것이 아니라, 기준을 선명하게 드러내는 것입니다.

좋은 예시와 나쁜 예시를 가르는 설계 기준

이제 예시의 질을 판단하는 기준을 실무적으로 정리해봅시다. 좋은 예시는 다음 성질을 가집니다.

• 대표성: 실제로 자주 등장하는 상황을 담고 있다.

• 대비성: 예시들 사이의 차이가 분명해, 경계가 또렷하게 보인다.

• 일관성: 같은 과업 안에서 출력 길이, 형식, 기준이 흔들리지 않는다.

• 경제성: 불필요하게 길지 않고, 배워야 할 패턴이 바로 보인다.

• 최신성: 현재 팀의 정책, 말투, 라벨 체계를 반영한다.

• 위험 통제: 잘못된 출력의 위험이 큰 경우 금지선을 함께 보여준다.

반대로 나쁜 예시는 이런 특징을 보입니다.

• 모두 쉬운 예시만 모아 두었다.

• 헷갈리는 사례가 빠져 있다.

• 비슷한 예시만 여러 개 있다.

• 예시마다 말투와 형식이 다르다.

• 현재 업무 기준과 맞지 않는 오래된 사례가 섞여 있다.

• 무엇이 금지인지 드러나지 않는다.

이 기준을 기억하면 예시를 늘릴지, 바꿀지, 줄일지 판단하기 쉬워집니다. 실무에서는 대개 "더 많이"보다 "더 다르게"가 정답인 경우가 많습니다.

한 과업에 예시는 몇 개나 넣어야 할까

정답은 없습니다. 하지만 실무에서는 보통 적은 수의 예시로도 충분히 안정화가 가능합니다. 중요한 것은 개수보다 구성입니다. 가장 실용적인 출발점은 다음과 같습니다.

• 대표 예시 1개

• 경계 사례 1개

• 반례 1개

• 금지 사례 1개

이 네 개면 이미 꽤 강한 세트가 됩니다. 물론 과업이 복잡하면 경계 사례를 두세 개 더 넣을 수 있습니다. 하지만 무작정 열 개, 스무 개로 늘리기보다 먼저 이 네 역할이 들어 있는지 확인하는 편이 훨씬 낫습니다.

예시 수를 늘리는 기준도 분명해야 합니다. 예를 들어 다음과 같은 경우에만 추가하는 것이 좋습니다.

• 실제 현장에서 특정 경계 상황이 반복적으로 틀릴 때

• 팀 내 해석 차이가 큰 경우를 더 보여줘야 할 때

• 라벨 수가 많아 각 범주의 중심 예시가 따로 필요할 때

즉, 예시는 장식용이 아니라 문제 해결용으로 추가해야 합니다.

예시 세트를 만드는 실전 순서

예시를 잘 만들고 싶다면, 처음부터 멋진 샘플을 쓰려고 하지 말고 실패 로그를 보는 편이 좋습니다. 실제로 모델이 자주 틀린 지점이 가장 좋은 예시 재료이기 때문입니다.

실전에서는 보통 이런 순서가 효율적입니다.

가장 자주 나오는 정상 사례를 고른다

먼저 대표 예시를 고릅니다. 팀원 누구나 봐도 "이건 맞다"라고 할 수 있는 사례가 좋습니다. 이 예시가 전체 톤과 형식의 기준점이 됩니다.

모델이 자주 헷갈리는 입력을 모은다

다음으로 경계 사례를 고릅니다. 실제 운영에서 오답이 많이 나온 케이스가 최고의 재료입니다. 이 사례는 모델의 성능을 끌어올리는 레버입니다.

닮았지만 다른 케이스를 고른다

반례는 자주 틀리는 오분류 패턴을 기준으로 선택합니다. 모델이 A로 착각하는 B를 보여주면, 구분 능력이 눈에 띄게 좋아집니다.

실수 비용이 큰 잘못된 출력을 적는다

마지막으로 금지 사례를 추가합니다. 특히 고객 응대, 민감정보, 정책 안내처럼 잘못 말했을 때 비용이 큰 과업에서는 꼭 필요합니다.

예시를 짧게 다듬고 형식을 통일한다

마지막 점검에서 가장 중요한 것은 통일성입니다. 입력 길이, 출력 형식, 라벨 표기, 설명 유무가 뒤섞이면 예시의 힘이 크게 떨어집니다.

같은 예시도 쓰는 방식에 따라 효과가 달라진다

좋은 예시를 골랐더라도 배치가 엉성하면 효과가 줄어듭니다. 예시는 보통 규칙 설명 뒤에 두는 편이 안정적입니다. 먼저 과업 목적, 라벨 정의, 제약 조건을 적고, 그다음 예시를 배치하면 모델이 "원칙 + 샘플" 두 가지를 함께 받게 됩니다.

예를 들어 아래처럼 구성할 수 있습니다.

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

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

대표 예시
입력: 주문한 상품이 아직 도착하지 않았습니다.
출력: 배송

경계 사례
입력: 배송이 늦었고 박스도 찢어져 있었습니다.
출력: 배송

반례
입력: 색상이 달라서 교환하고 싶습니다.
출력: 기타

금지 사례
입력: 아직 상품이 안 왔고 화가 납니다.
잘못된 출력: 배송, 환불
금지 이유: 라벨은 하나만 출력해야 한다.

이 구조의 장점은 예시가 규칙을 대체하지 않는다는 점입니다. 규칙은 말로 분명히 적고, 예시는 그 규칙이 실제 입력에서 어떻게 작동하는지 보여줍니다.

작성 과업에서도 같은 원리가 적용된다

예시는 분류 작업에만 유용한 것이 아닙니다. 글쓰기 과업에서도 마찬가지입니다. 예를 들어 "정중하지만 과하게 굽히지 않는 고객 응답"을 원한다고 해봅시다. 이 경우 대표 예시는 기본 톤을 보여주고, 경계 사례는 불만 강도가 높은 상황에서의 균형을 보여주며, 반례는 정중해 보이지만 사실상 무책임한 문장을 피하게 하고, 금지 사례는 고객 탓처럼 들리는 표현을 막아줍니다.

즉, 예시는 정답 문장 모음이 아니라 스타일의 울타리로도 작동합니다. 이 울타리가 있어야 모델이 친절함, 단호함, 책임 범위, 정보 밀도를 안정적으로 맞춥니다.

예시를 점검하는 마지막 질문

예시를 다 넣은 뒤에는 스스로 몇 가지를 물어봐야 합니다.

• 이 예시 세트만 봐도 기준의 중심이 보이는가

• 헷갈리는 회색지대가 포함되어 있는가

• 비슷하지만 다른 사례를 구분하게 만드는가

• 절대 하면 안 되는 출력이 드러나는가

• 예시들끼리 형식과 기준이 일관적인가

• 지금 팀의 정책과 말투를 반영하고 있는가

이 질문에 여러 개가 "아니오"라면 예시를 더 늘리기보다 먼저 다시 고르는 것이 맞습니다.

예시의 질이 결과를 바꾸는 이유

모델은 예시를 보고 단순히 베끼는 것이 아닙니다. 어떤 요소를 중요하게 보고, 어떤 경계에서 결정을 내리고, 어떤 실수를 피해야 하는지에 대한 힌트를 함께 받습니다. 그래서 예시의 질은 곧 판단의 질로 이어집니다.

좋은 예시 세트는 모델에게 말합니다. "이게 중심이다. 여기서부터 헷갈리기 시작한다. 이건 닮았지만 다르다. 그리고 이 선은 절대 넘지 마라." 이 네 문장이 전달되면, 적은 수의 예시로도 결과는 눈에 띄게 안정됩니다.

반대로 나쁜 예시 세트는 모델을 안심시키면서 잘못된 길로 보냅니다. 쉬운 사례만 잔뜩 보여주고, 회색지대는 숨기고, 금지선은 말하지 않으면 모델은 실무에서 가장 중요한 순간에 흔들립니다.

중급 프롬프트 설계에서 예시는 장식이 아닙니다. 예시는 기준을 가르치는 가장 압축된 도구입니다. 그러니 다음부터는 이렇게 묻는 편이 좋습니다.

"예시를 몇 개 넣을까?"가 아니라, "대표 예시, 경계 사례, 반례, 금지 사례가 모두 들어 있는가?"

이 질문을 습관처럼 던질 수 있다면, 예시는 더 이상 샘플이 아니라 재현 가능한 성능을 만드는 설계 장치가 됩니다.

이 장의 핵심 정리

좋은 예시는 많아서 좋은 것이 아니라, 역할이 분명해서 좋습니다. 대표 예시는 기준의 중심을 만들고, 경계 사례는 회색지대의 우선순위를 보여주며, 반례는 닮았지만 다른 것을 구분하게 하고, 금지 사례는 위험한 실수를 막습니다.

예시 설계의 핵심을 다시 정리하면 다음과 같습니다.

• 대표 예시는 가장 전형적인 정답을 보여줘야 한다.

• 경계 사례는 모델이 자주 흔들리는 회색지대를 겨냥해야 한다.

• 반례는 비슷한 입력을 섣불리 같은 범주로 묶지 않게 만든다.

• 금지 사례는 실수 비용이 큰 과업에서 특히 중요하다.

• 예시의 양보다 대표성, 대비성, 일관성, 최신성이 더 중요하다.

결국 예시는 답안 모음집이 아니라 판단 훈련 세트입니다. 잘 만든 예시 몇 개는 평범한 프롬프트를 반복 가능한 업무 도구로 바꾸는 힘을 가집니다.