Zero-Shot 프롬프팅 완벽 마스터 가이드

LLM에게 예시 없이 작업을 수행시키는 Zero-Shot 프롬프팅의 개념부터 실전 테크닉까지, 초급 개발자도 쉽게 따라할 수 있는 완벽 가이드입니다. 명확한 지시문 작성, 출력 형식 지정, 제약 조건 명시 등 실무에서 바로 쓸 수 있는 노하우를 담았습니다.

---

목차

1. Zero-Shot의 개념과 한계
2. 명확한 Instruction 작성법
3. 핵심 키워드를 추출하세요 (최대 3개)
4. 출력 형식 지정 (JSON, Markdown, 구조화)
5. 제약 조건 명시하기
6. 형식: 완전한 문장 2-3개로 구성
7. 실습: Zero-Shot 분류기 만들기
8. 실습: Zero-Shot 요약기 구현
9. 형식: 각 문장은 완전한 문장으로 끝맺음

---

1. Zero-Shot의 개념과 한계

어느 날 김개발 씨가 ChatGPT를 처음 사용해보며 신기해했습니다. "예시도 안 줬는데 어떻게 알아서 번역을 하지?" 선배 박시니어 씨가 웃으며 말했습니다.

"그게 바로 Zero-Shot 프롬프팅이에요."

Zero-Shot 프롬프팅은 한마디로 LLM에게 예시를 전혀 주지 않고 작업을 지시하는 방법입니다. 마치 처음 만난 사람에게 설명만으로 일을 시키는 것과 같습니다.

이것을 제대로 이해하면 LLM을 더 효율적으로 활용할 수 있고, 언제 예시가 필요한지도 판단할 수 있습니다.

다음 코드를 살펴봅시다.

# Zero-Shot 프롬프팅 기본 예제
import anthropic

client = anthropic.Anthropic(api_key="your-api-key")

# 예시 없이 바로 작업 지시
prompt = "다음 문장을 영어로 번역해주세요: 오늘 날씨가 정말 좋네요."

message = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": prompt}
    ]
)

# 결과: "The weather is really nice today."
print(message.content[0].text)

김개발 씨는 입사 2개월 차 주니어 개발자입니다. 요즘 회사에서 AI를 활용한 자동화 프로젝트를 진행하게 되었습니다.

팀장님이 "GPT API를 써서 고객 문의를 자동으로 분류해봐요"라고 지시했습니다. 김개발 씨는 일단 간단하게 시작해보기로 했습니다.

"문의 유형을 분류해주세요"라고만 입력했더니 놀랍게도 결과가 나왔습니다. 어떻게 이게 가능한 걸까요?

그렇다면 Zero-Shot 프롬프팅이란 정확히 무엇일까요? 쉽게 비유하자면, Zero-Shot은 마치 새로 온 인턴에게 업무 매뉴얼 없이 말로만 설명해서 일을 시키는 것과 같습니다.

"이 서류를 정리해주세요"라고만 말하면, 인턴은 자신의 상식과 이해력으로 어떻게든 해내려고 노력할 것입니다. 이처럼 Zero-Shot도 LLM의 사전 학습된 지식만으로 작업을 수행하는 방식입니다.

Zero-Shot이 없던 시절에는 어땠을까요? 전통적인 머신러닝에서는 모델에게 새로운 작업을 시키려면 반드시 많은 예제 데이터를 학습시켜야 했습니다.

스팸 메일 분류기를 만들려면 수천 개의 스팸과 정상 메일 샘플이 필요했습니다. 더 큰 문제는 새로운 유형의 작업이 생길 때마다 처음부터 다시 학습해야 한다는 점이었습니다.

시간도 오래 걸리고, 비용도 많이 들었습니다. 바로 이런 문제를 해결하기 위해 대규모 언어 모델의 Zero-Shot 능력이 주목받게 되었습니다.

Zero-Shot 프롬프팅을 사용하면 즉각적인 작업 수행이 가능해집니다. 별도의 학습 과정 없이 바로 결과를 얻을 수 있습니다.

또한 다양한 작업에 유연하게 적용할 수 있다는 장점도 있습니다. 무엇보다 개발 시간과 비용을 크게 절약할 수 있다는 큰 이점이 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 Anthropic 클라이언트를 초기화합니다.

이 부분이 API와 통신하는 기본 설정입니다. 다음으로 prompt 변수에 작업 지시문을 작성합니다.

여기서는 번역 작업을 요청하고 있습니다. messages.create()로 실제 API 호출이 일어나고, model과 max_tokens 같은 파라미터를 지정합니다.

마지막으로 응답에서 텍스트를 추출하여 결과를 출력합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 고객 지원 시스템을 개발한다고 가정해봅시다. 매일 수백 건의 문의가 들어오는데, 이를 "제품 문의", "배송 문의", "환불 문의" 등으로 자동 분류해야 합니다.

Zero-Shot 프롬프팅을 활용하면 별도의 분류 모델 학습 없이도 즉시 분류 시스템을 구축할 수 있습니다. 스타트업에서 빠른 프로토타입 개발이 필요할 때 이런 접근법을 적극적으로 사용하고 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 모든 작업에 Zero-Shot만 사용하려는 것입니다.

복잡하거나 도메인 특화된 작업에서는 정확도가 떨어질 수 있습니다. 예를 들어 의료 진단이나 법률 문서 분석처럼 높은 정확도가 요구되는 작업에서는 Few-Shot이나 Fine-tuning을 고려해야 합니다.

따라서 작업의 복잡도와 요구 정확도를 먼저 판단하고 적절한 방법을 선택해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 간단한 작업은 Zero-Shot으로 시작하고, 정확도가 부족하면 예시를 추가하는 거군요!" Zero-Shot 프롬프팅을 제대로 이해하면 LLM의 강점과 한계를 파악하여 적재적소에 활용할 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 간단하고 일반적인 작업(번역, 요약, 감정 분석)은 Zero-Shot으로 시작하세요

• 정확도가 70% 이하로 떨어지면 Few-Shot이나 Fine-tuning을 고려하세요
• 프로토타입 개발 단계에서는 Zero-Shot으로 빠르게 검증하는 것이 효율적입니다

---

2. 명확한 Instruction 작성법

김개발 씨가 Zero-Shot 프롬프팅을 시도했지만 결과가 매번 달랐습니다. "왜 똑같은 질문인데 답변이 다를까요?" 박시니어 씨가 프롬프트를 보더니 말했습니다.

"지시문이 애매해서 그래요. 더 명확하게 작성해야 해요."

명확한 Instruction은 LLM에게 정확히 무엇을, 어떻게 해야 하는지 구체적으로 알려주는 것입니다. 마치 레시피처럼 단계와 조건을 명시하면 일관된 결과를 얻을 수 있습니다.

좋은 지시문은 작업의 목적, 입력 형식, 처리 방법, 출력 형식을 모두 포함합니다.

다음 코드를 살펴봅시다.

# 나쁜 예: 애매한 지시문
bad_prompt = "이 텍스트를 분석해주세요: 제품이 불량이네요"

# 좋은 예: 명확한 지시문
good_prompt = """
다음 고객 리뷰를 감정 분석해주세요.

작업 내용:

---

3. 핵심 키워드를 추출하세요 (최대 3개)

김개발 씨는 고객 리뷰 감정 분석 기능을 개발하고 있었습니다. 처음에는 "이 리뷰를 분석해주세요"라고만 입력했더니, 어떤 때는 긍정/부정만 답하고, 어떤 때는 장황한 설명을 늘어놓았습니다.

일관성이 없어서 시스템에 통합할 수가 없었습니다. 고민하던 김개발 씨에게 박시니어 씨가 다가왔습니다.

"프롬프트를 보여주세요." 코드를 본 박시니어 씨는 바로 문제를 짚어냈습니다. "지시문이 너무 애매해요.

LLM이 뭘 해야 할지 혼란스러워하고 있어요." 그렇다면 명확한 Instruction이란 정확히 무엇일까요? 쉽게 비유하자면, 명확한 지시문은 마치 요리 레시피와 같습니다.

"맛있는 파스타를 만들어주세요"라고만 하면 사람마다 다른 파스타를 만들 것입니다. 하지만 "면 100g을 7분간 삶고, 올리브유 2큰술에 마늘을 볶은 후, 토마토 소스 200ml를 넣어 3분간 끓이세요"라고 하면 누구나 비슷한 결과를 만들 수 있습니다.

이처럼 명확한 지시문도 구체적인 단계와 조건을 제시하여 일관된 결과를 보장합니다. 명확한 지시문이 없으면 어떤 문제가 생길까요?

LLM은 애매한 지시를 받으면 자신의 방식대로 해석합니다. 같은 입력에도 매번 다른 형식으로 답변하거나, 필요 없는 정보를 추가하거나, 중요한 정보를 빠뜨릴 수 있습니다.

실제 프로덕션 환경에서는 이런 불일치가 심각한 버그로 이어집니다. 후처리 코드가 예상하지 못한 형식을 받아 에러가 나거나, 잘못된 데이터가 데이터베이스에 저장될 수 있습니다.

바로 이런 문제를 해결하기 위해 명확한 Instruction 작성법이 중요합니다. 명확한 지시문을 작성하면 일관된 출력 형식을 보장할 수 있습니다.

LLM의 응답을 예측 가능하게 만들어 파싱과 후처리가 쉬워집니다. 또한 디버깅 시간을 크게 줄일 수 있습니다.

무엇보다 다른 개발자가 코드를 보더라도 의도를 쉽게 이해할 수 있다는 큰 이점이 있습니다. 위의 코드를 비교해서 살펴보겠습니다.

나쁜 예시는 "분석해주세요"라는 애매한 표현만 사용했습니다. 무엇을 어떻게 분석할지 명시되지 않았습니다.

반면 좋은 예시는 작업을 세 가지 단계로 명확히 나눴습니다. 감정 분류, 강도 평가, 키워드 추출이 구체적으로 지시되었습니다.

또한 출력 형식까지 정확히 명시하여 파싱이 쉽도록 만들었습니다. 명확한 지시문의 4가지 핵심 요소를 알아봅시다.

첫째, 작업의 목적을 명시합니다. "고객 리뷰를 감정 분석"처럼 무엇을 하는지 분명히 밝힙니다.

둘째, 입력 데이터를 설명합니다. 어떤 형식의 데이터가 들어오는지 알려줍니다.

셋째, 처리 방법을 단계별로 나열합니다. 1, 2, 3처럼 순서를 매기면 더 명확합니다.

넷째, 출력 형식을 정확히 지정합니다. 키-값 쌍, JSON, 표 등 원하는 형식을 구체적으로 제시합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 이커머스 플랫폼에서 상품 설명을 자동 생성하는 기능을 만든다고 가정해봅시다.

"상품명: 무선 이어폰, 가격: 89,000원, 특징: 노이즈캔슬링, 30시간 배터리"라는 정보를 받아서 마케팅 문구를 생성해야 합니다. 명확한 지시문에는 "100자 이내로 작성", "감탄사 포함", "가격 정보는 마지막에 배치" 같은 구체적인 규칙을 포함시킵니다.

쿠팡, 네이버 쇼핑 같은 대형 플랫폼에서 이런 방식으로 수천 개의 상품 설명을 자동 생성하고 있습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 지시문을 너무 길게 작성하는 것입니다. 한 페이지가 넘는 지시문은 오히려 LLM을 혼란스럽게 만듭니다.

핵심만 간결하게, 하지만 명확하게 작성해야 합니다. 또 다른 실수는 애매한 표현을 사용하는 것입니다.

"적절하게", "알아서", "잘" 같은 단어는 피하고, "3개 이내로", "긍정/부정/중립 중 하나로" 처럼 구체적으로 표현해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 조언대로 지시문을 수정한 김개발 씨는 놀라운 결과를 얻었습니다. "와, 이제 매번 똑같은 형식으로 나오네요!" 명확한 Instruction 작성법을 제대로 이해하면 LLM을 더 신뢰할 수 있는 도구로 만들 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 지시문은 작업 목적, 입력, 처리 방법, 출력 형식 4가지를 반드시 포함하세요

• "적절하게", "잘" 같은 애매한 표현 대신 "3개 이내로", "100자 이하로" 같은 구체적인 수치를 사용하세요
• 복잡한 작업은 번호를 매겨 단계별로 나누면 LLM이 더 잘 이해합니다

---

3. 출력 형식 지정 (JSON, Markdown, 구조화)

김개발 씨가 LLM의 응답을 데이터베이스에 저장하려는데 매번 파싱 에러가 났습니다. "형식이 계속 바뀌어서 정규식으로 잡을 수가 없어요." 박시니어 씨가 웃으며 말했습니다.

"JSON 형식으로 출력하라고 명시하면 되죠."

출력 형식 지정은 LLM의 응답을 JSON, Markdown, CSV 같은 구조화된 형태로 받는 기법입니다. 마치 택배 상자에 규격을 정해두면 쌓기 쉬운 것처럼, 정해진 형식으로 받으면 프로그래밍적으로 처리하기 쉽습니다.

이를 통해 후처리 코드가 단순해지고 에러가 줄어듭니다.

다음 코드를 살펴봅시다.

import anthropic
import json

client = anthropic.Anthropic(api_key="your-api-key")

# JSON 형식으로 출력 요청
prompt = """
다음 상품 정보를 분석하여 JSON 형식으로 출력해주세요.

입력: "삼성 갤럭시 버즈 2 Pro - 노이즈캔슬링, 8시간 재생, 89,000원"

출력 형식 (반드시 아래 JSON 구조를 따르세요):
{
  "brand": "브랜드명",
  "product": "제품명",
  "features": ["특징1", "특징2"],
  "price": 가격(숫자)
}
"""

message = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    messages=[{"role": "user", "content": prompt}]
)

# JSON 파싱
result = json.loads(message.content[0].text)
print(f"브랜드: {result['brand']}, 가격: {result['price']}원")

김개발 씨는 상품 정보 추출 API를 만들고 있었습니다. LLM이 상품명, 가격, 특징을 잘 추출하긴 하는데 문제는 형식이었습니다.

어떤 때는 "브랜드: 삼성", 어떤 때는 "브랜드는 삼성입니다", 또 어떤 때는 "삼성 제품"이라고만 나왔습니다. 매번 다른 형식 때문에 정규식이 점점 복잡해졌습니다.

"이거 어떻게 해야 하죠?" 김개발 씨가 한숨을 쉬자, 박시니어 씨가 모니터를 들여다봤습니다. "아, 출력 형식을 지정 안 하셨네요.

JSON으로 받으면 json.loads() 한 번으로 끝나요." 그렇다면 출력 형식 지정이란 정확히 무엇일까요? 쉽게 비유하자면, 출력 형식 지정은 마치 설문조사 양식과 같습니다.

빈 종이에 "의견을 자유롭게 써주세요"라고 하면 사람마다 다르게 씁니다. 어떤 사람은 문장으로, 어떤 사람은 키워드만, 어떤 사람은 그림까지 그립니다.

하지만 "1. 이름: [___] 2.

나이: [] 3. 의견: []" 같은 양식을 주면 모두가 똑같은 구조로 답변합니다.

이처럼 출력 형식 지정도 LLM에게 미리 틀을 제시하여 일관된 구조의 응답을 받는 것입니다. 출력 형식을 지정하지 않으면 어떤 문제가 생길까요?

자유 형식 텍스트는 파싱하기 매우 어렵습니다. "브랜드는 삼성이고요, 가격은 8만 9천원이에요"라는 응답을 프로그래밍적으로 처리하려면 복잡한 정규식이나 추가 파싱 로직이 필요합니다.

더 큰 문제는 예외 상황입니다. LLM이 갑자기 "죄송하지만 가격 정보가 불명확합니다"라고 답하면 기존 파싱 코드가 완전히 깨집니다.

프로덕션 환경에서는 이런 불확실성이 치명적입니다. 바로 이런 문제를 해결하기 위해 구조화된 출력 형식이 필수입니다.

출력 형식 지정을 사용하면 파싱 코드가 단순해집니다. JSON이라면 json.loads() 한 줄이면 충분합니다.

또한 타입 안정성이 보장됩니다. result['price']가 항상 숫자임을 신뢰할 수 있습니다.

무엇보다 에러 핸들링이 쉬워집니다. 형식이 잘못됐다면 JSON 파싱 단계에서 바로 에러가 발생하므로 문제를 조기에 발견할 수 있습니다.

위의 코드를 단계별로 살펴보겠습니다. 프롬프트에서 "출력 형식 (반드시 아래 JSON 구조를 따르세요)"라고 명시했습니다.

이 부분이 핵심입니다. 그다음 중괄호를 포함한 완전한 JSON 스키마를 예시로 제시했습니다.

LLM은 이 구조를 그대로 따라 응답합니다. 응답을 받은 후에는 json.loads()로 파싱합니다.

Python 딕셔너리로 변환되므로 result['brand'], result['price'] 같은 방식으로 쉽게 접근할 수 있습니다. 다양한 출력 형식을 알아봅시다.

첫째, JSON 형식은 가장 많이 사용됩니다. 프로그래밍 언어 대부분이 JSON 파싱을 기본 지원하므로 통합이 쉽습니다.

특히 REST API나 데이터베이스 저장에 적합합니다. 둘째, Markdown 형식은 문서 생성에 유용합니다.

블로그 포스트, 기술 문서, README 파일 등을 자동 생성할 때 사용합니다. 셋째, CSV 형식은 표 형태 데이터에 적합합니다.

엑셀로 바로 열어볼 수 있어 데이터 분석팀과 협업할 때 편리합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 뉴스 기사 요약 서비스를 만든다고 가정해봅시다. 수백 개의 기사를 자동으로 요약하고, 제목, 요약문, 핵심 키워드를 추출해야 합니다.

JSON 형식으로 출력을 요청하면 {"title": "...", "summary": "...", "keywords": [...]} 같은 구조로 일관되게 받을 수 있습니다. 이를 바로 MongoDB나 PostgreSQL에 저장하고, 프론트엔드에서 렌더링할 수 있습니다.

네이버 뉴스, 카카오 등에서 이런 방식으로 대량의 콘텐츠를 자동 처리하고 있습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 형식 예시를 불완전하게 제공하는 것입니다. {"brand": "..."} 처럼 값 부분을 생략하면 LLM이 말줄임표를 그대로 출력할 수 있습니다.

정확한 예시값을 포함한 완전한 스키마를 제시해야 합니다. 또 다른 실수는 너무 복잡한 중첩 구조를 요구하는 것입니다.

JSON이 5단계 이상 중첩되면 LLM이 구조를 잘못 만들 확률이 높아집니다. 가능하면 평평한 구조로 설계하세요.

다시 김개발 씨의 이야기로 돌아가 봅시다. JSON 형식을 지정한 후 김개발 씨의 코드는 놀라울 정도로 간단해졌습니다.

"정규식 50줄이 json.loads() 한 줄로 줄었어요!" 출력 형식 지정을 제대로 이해하면 LLM을 실제 프로덕션 시스템에 안정적으로 통합할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - JSON 형식을 요청할 때는 완전한 스키마 예시를 제공하세요 (키와 값 모두 포함)

• Markdown은 헤딩(#, ##)과 리스트(-, *) 같은 구체적인 요소까지 명시하세요
• 파싱 실패에 대비해 try-except로 에러 핸들링을 추가하세요

---

4. 제약 조건 명시하기

김개발 씨가 만든 상품 설명 자동 생성 기능에서 문제가 생겼습니다. 어떤 설명은 300자가 넘어 UI가 깨지고, 어떤 건 10자밖에 안 돼서 너무 짧았습니다.

"길이 제한을 어떻게 거나요?" 박시니어 씨가 답했습니다. "제약 조건을 명시하면 됩니다."

제약 조건 명시는 LLM에게 지켜야 할 규칙과 한계를 구체적으로 알려주는 기법입니다. 마치 건축할 때 층수 제한, 면적 제한을 정하는 것처럼, 글자 수, 형식, 금지어 등을 미리 정해두면 원하는 범위 내의 결과를 얻을 수 있습니다.

다음 코드를 살펴봅시다.

import anthropic

client = anthropic.Anthropic(api_key="your-api-key")

# 제약 조건을 명확히 명시한 프롬프트
prompt = """
다음 상품의 마케팅 문구를 작성해주세요.

상품: 무선 블루투스 이어폰

제약 조건 (반드시 지켜주세요):

---

5. 형식: 완전한 문장 2-3개로 구성

김개발 씨는 쇼핑몰의 상품 설명 자동 생성 기능을 만들었습니다. 처음에는 잘 작동하는 것 같았는데, QA 팀에서 문제를 발견했습니다.

"이 상품 설명은 너무 길어서 UI 레이아웃이 깨져요. 저 상품은 반대로 너무 짧아서 공간이 남아요." 김개발 씨가 생성된 텍스트를 확인해보니 정말 문제가 심각했습니다.

어떤 건 500자가 넘었고, 어떤 건 "좋은 이어폰입니다" 같은 한 문장만 나왔습니다. "이걸 어떻게 제어하죠?" 박시니어 씨가 화면을 보더니 바로 해결책을 제시했습니다.

"제약 조건을 명시해야죠." 그렇다면 제약 조건 명시란 정확히 무엇일까요? 쉽게 비유하자면, 제약 조건은 마치 울타리와 같습니다.

놀이터에 울타리가 없으면 아이들이 어디로든 뛰어나갈 수 있습니다. 하지만 울타리를 세워두면 안전한 범위 내에서 자유롭게 놀 수 있습니다.

이처럼 제약 조건도 LLM이 자유롭게 생성하되, 정해진 규칙 안에서 움직이도록 경계를 만드는 것입니다. 창의성은 유지하면서도 품질과 일관성을 보장할 수 있습니다.

제약 조건 없이 프롬프트를 작성하면 어떤 문제가 생길까요? LLM은 매우 창의적이지만, 그 창의성이 때로는 문제가 됩니다.

길이 제한 없이 글을 쓰라고 하면 어떤 때는 소설처럼 길게, 어떤 때는 트윗처럼 짧게 씁니다. 톤앤매너 지정 없이 작성하면 격식 있는 문체와 캐주얼한 문체가 섞입니다.

금지어 지정 없이 생성하면 부적절한 표현이나 과장 광고가 나올 수 있습니다. 실제 프로덕션에서는 이런 불일치가 브랜드 이미지를 해치고 법적 문제까지 야기할 수 있습니다.

바로 이런 문제를 해결하기 위해 제약 조건 명시가 필수입니다. 제약 조건을 명시하면 일관된 품질을 유지할 수 있습니다.

모든 상품 설명이 비슷한 길이와 톤으로 작성되어 UI가 깨지지 않습니다. 또한 리스크를 줄일 수 있습니다.

금지어를 미리 차단하여 부적절한 표현이 서비스에 노출되는 것을 막습니다. 무엇보다 후처리 비용이 감소합니다.

사람이 일일이 검토하고 수정할 필요가 줄어듭니다. 위의 코드를 단계별로 살펴보겠습니다.

제약 조건을 5가지로 명확히 나열했습니다. 첫째는 길이 제한으로 50자 이상 100자 이하를 지정했습니다.

UI 레이아웃에 맞는 범위입니다. 둘째는 톤앤매너로 "전문적이고 신뢰감 있는"이라는 구체적인 표현을 사용했습니다.

셋째는 금지 단어 리스트로 과장 광고를 방지합니다. 넷째는 필수 포함 요소로 핵심 특징을 반드시 언급하도록 했습니다.

다섯째는 형식으로 완전한 문장 2-3개를 요구했습니다. 제약 조건의 종류를 알아봅시다.

첫째, 길이 제약입니다. "N자 이상 M자 이하", "N 단어 이내", "N 문장으로 구성" 같은 방식으로 명시합니다.

UI 레이아웃이나 API 응답 크기 제한을 고려해야 합니다. 둘째, 형식 제약입니다.

"bullet point로 작성", "제목 + 본문 구조", "질문-답변 형식" 등을 지정합니다. 셋째, 내용 제약입니다.

"금지어 리스트", "필수 포함 키워드", "언급 금지 주제" 같은 규칙을 둡니다. 넷째, 톤앤매너 제약입니다.

"격식체/반말체", "전문적/캐주얼", "친근한/권위적" 같은 스타일을 정합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 금융 서비스 챗봇을 개발한다고 가정해봅시다. 고객 문의에 답변을 생성할 때 제약 조건이 매우 중요합니다.

"금지어: 확실합니다, 보장합니다" 같은 규칙으로 법적 리스크를 줄입니다. "톤앤매너: 정중하고 전문적인 격식체"로 브랜드 이미지를 유지합니다.

"필수 포함: 고객센터 연락처"로 추가 문의 경로를 안내합니다. 실제로 카카오뱅크, 토스 같은 핀테크 기업들이 이런 제약 조건을 엄격하게 관리하며 챗봇을 운영하고 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 제약 조건을 너무 많이 두는 것입니다.

10개 이상의 규칙을 나열하면 LLM이 일부를 무시하거나 혼란스러워합니다. 핵심적인 3-5개 정도로 제한하는 것이 효과적입니다.

또 다른 실수는 상충되는 제약을 주는 것입니다. "50자 이하로 작성하되 3개 문단으로 구성"처럼 모순된 지시는 LLM을 곤란하게 만듭니다.

제약 조건 간의 일관성을 확인해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

제약 조건을 추가한 후 김개발 씨는 안정적인 결과를 얻었습니다. "이제 모든 설명이 80자 전후로 나오고, 톤도 일관되네요!" 제약 조건 명시를 제대로 이해하면 LLM을 통제 가능한 도구로 만들어 프로덕션 환경에서 안전하게 사용할 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 제약 조건은 3-5개 정도가 적당합니다 (너무 많으면 LLM이 일부를 무시함)

• 길이 제한은 정확한 숫자로 명시하세요 ("짧게" 대신 "50자 이하로")
• 금지어 리스트는 구체적으로 나열하세요 ("과장 금지" 대신 "대박, 혜자, 꿀템 사용 금지")

---

5. 실습: Zero-Shot 분류기 만들기

김개발 씨가 드디어 실전 프로젝트를 맡았습니다. "고객 문의를 자동으로 분류하는 시스템을 만들어보세요." 팀장님의 지시였습니다.

"예시 데이터가 부족한데 어떻게 하죠?" 박시니어 씨가 웃으며 답했습니다. "Zero-Shot 분류기로 시작하면 돼요."

Zero-Shot 분류기는 예시 학습 데이터 없이 텍스트를 카테고리로 분류하는 시스템입니다. 명확한 카테고리 정의와 판단 기준만 제시하면 LLM이 알아서 분류합니다.

프로토타입 단계나 라벨링 데이터가 부족할 때 매우 유용합니다.

다음 코드를 살펴봅시다.

import anthropic
import json

client = anthropic.Anthropic(api_key="your-api-key")

def classify_customer_inquiry(text):
    prompt = f"""
다음 고객 문의를 카테고리로 분류해주세요.

카테고리 정의:
- product: 제품 기능, 사양, 사용법에 대한 질문
- shipping: 배송, 배송 조회, 배송 지연 관련
- refund: 환불, 반품, 교환 요청
- account: 회원가입, 로그인, 비밀번호 찾기
- other: 위 카테고리에 해당하지 않는 기타 문의

고객 문의: "{text}"

출력 형식 (JSON):
{{
  "category": "카테고리명",
  "confidence": "high/medium/low",
  "reason": "분류 근거"
}}
"""

    message = client.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}]
    )

    return json.loads(message.content[0].text)

# 테스트
result = classify_customer_inquiry("배송이 3일째 안 오는데 어떻게 된 건가요?")
print(f"카테고리: {result['category']}, 확신도: {result['confidence']}")

김개발 씨는 고객 지원 시스템 개발 프로젝트를 시작했습니다. 매일 수백 건의 문의가 들어오는데, 이를 담당 부서별로 자동 분류해야 했습니다.

문제는 라벨링된 학습 데이터가 없다는 것이었습니다. 기존 시스템에는 분류 정보가 없었고, 수작업으로 라벨링하려면 몇 주가 걸릴 것 같았습니다.

"어떻게 시작하죠?" 김개발 씨가 고민하자, 박시니어 씨가 조언했습니다. "일단 Zero-Shot 분류기로 프로토타입을 만들어보세요.

정확도가 부족하면 나중에 Few-Shot으로 개선하면 돼요." 그렇다면 Zero-Shot 분류기란 정확히 무엇일까요? 쉽게 비유하자면, Zero-Shot 분류기는 마치 경험 없는 신입 상담원과 같습니다.

고객 문의 유형을 한 번도 처리해본 적은 없지만, 명확한 업무 매뉴얼만 있으면 대부분의 문의를 올바른 부서로 연결할 수 있습니다. "배송 관련은 물류팀", "환불 관련은 CS팀" 같은 규칙만 알려주면 됩니다.

이처럼 Zero-Shot 분류기도 사전 학습된 지식과 명확한 카테고리 정의만으로 텍스트를 분류합니다. 전통적인 분류 모델은 어떤 문제가 있었을까요?

기존 머신러닝 분류기는 수천 개의 라벨링된 데이터가 필요했습니다. "이 문의는 배송", "저 문의는 환불" 같은 정답을 일일이 달아야 했습니다.

시간도 오래 걸리고, 비용도 많이 들었습니다. 더 큰 문제는 새로운 카테고리가 생기면 다시 학습해야 한다는 점이었습니다.

"결제 오류" 카테고리를 추가하려면 수백 개의 새 샘플을 모으고 재학습해야 했습니다. 바로 이런 문제를 해결하기 위해 Zero-Shot 분류기가 효과적입니다.

Zero-Shot 분류기를 사용하면 즉시 시작할 수 있습니다. 라벨링 작업 없이 바로 프로토타입을 만들어 테스트할 수 있습니다.

또한 유연하게 확장 가능합니다. 새 카테고리를 추가하려면 정의만 한 줄 추가하면 됩니다.

무엇보다 초기 개발 속도가 매우 빠릅니다. 아이디어를 당일에 검증할 수 있습니다.

위의 코드를 단계별로 살펴보겠습니다. 먼저 카테고리 정의 부분이 핵심입니다.

각 카테고리가 무엇을 의미하는지 명확히 설명했습니다. "product: 제품 기능, 사양, 사용법"처럼 구체적으로 범위를 정의했습니다.

다음으로 출력 형식을 JSON으로 지정했습니다. category뿐만 아니라 confidence(확신도)와 reason(근거)도 함께 받습니다.

이렇게 하면 분류 결과를 신뢰할 수 있는지 판단할 수 있습니다. 마지막으로 함수로 감싸서 재사용 가능하게 만들었습니다.

분류기의 정확도를 높이는 방법을 알아봅시다. 첫째, 카테고리 정의를 구체적으로 작성합니다.

"제품"이라고만 하지 말고 "제품 기능, 사양, 사용법에 대한 질문"처럼 예시를 포함합니다. 둘째, 경계 케이스를 명시합니다.

"배송 조회는 shipping, 배송비 계산은 product"처럼 헷갈리기 쉬운 경우를 미리 정의합니다. 셋째, 확신도를 활용합니다.

confidence가 low인 경우는 사람이 재검토하도록 플래그를 세웁니다. 넷째, 이유를 분석합니다.

reason 필드를 로깅하여 잘못 분류된 케이스를 찾아 개선합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 스타트업에서 고객 지원 자동화를 시작한다고 가정해봅시다. 처음에는 문의량이 적어서 라벨링 데이터를 모으기 어렵습니다.

Zero-Shot 분류기로 시작하면 첫날부터 자동 분류가 가능합니다. 정확도가 70-80% 정도 나오면 우선 배포하고, 잘못 분류된 케이스를 수집합니다.

몇 주 후 충분한 데이터가 모이면 Few-Shot이나 Fine-tuning으로 업그레이드합니다. 토스, 당근마켓 같은 스타트업들이 이런 방식으로 빠르게 MVP를 출시하고 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 카테고리를 너무 많이 만드는 것입니다.

10개 이상의 카테고리는 Zero-Shot으로 정확히 분류하기 어렵습니다. 처음에는 4-5개 정도의 주요 카테고리로 시작하고, 점차 세분화하는 것이 좋습니다.

또 다른 실수는 애매한 카테고리 정의입니다. "기타", "일반 문의" 같은 모호한 카테고리는 LLM을 혼란스럽게 만듭니다.

명확한 기준이 있는 카테고리만 사용해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

Zero-Shot 분류기를 만든 김개발 씨는 테스트 데이터로 검증해봤습니다. "와, 정확도가 75%나 나오네요!

라벨링 데이터 하나도 안 썼는데!" Zero-Shot 분류기를 제대로 이해하면 빠르게 프로토타입을 만들고 아이디어를 검증할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 카테고리는 처음에 4-5개로 시작하세요 (너무 많으면 정확도 하락)

• 각 카테고리에 구체적인 예시를 2-3개씩 포함하면 정확도가 올라갑니다
• confidence 필드로 확신도가 낮은 케이스를 필터링하여 사람이 재검토하세요

---

6. 실습: Zero-Shot 요약기 구현

김개발 씨의 다음 미션은 뉴스 기사 요약 기능이었습니다. "긴 기사를 3줄로 요약해주는 API를 만들어보세요." 팀장님이 말했습니다.

"요약 모델을 직접 학습시켜야 하나요?" 박시니어 씨가 고개를 저었습니다. "Zero-Shot 프롬프팅으로 충분해요."

Zero-Shot 요약기는 별도 학습 없이 긴 텍스트를 짧게 압축하는 시스템입니다. 요약 길이, 스타일, 포함 정보를 명시하면 LLM이 핵심만 추출합니다.

뉴스, 리포트, 회의록 등 다양한 문서에 활용할 수 있습니다.

다음 코드를 살펴봅시다.

import anthropic

client = anthropic.Anthropic(api_key="your-api-key")

def summarize_article(article_text, num_sentences=3):
    prompt = f"""
다음 기사를 요약해주세요.

제약 조건:

---

5. 형식: 각 문장은 완전한 문장으로 끝맺음

김개발 씨는 뉴스 애그리게이터 서비스를 개발하고 있었습니다. 하루에 수천 개의 기사가 수집되는데, 사용자에게 전체 기사를 보여주기에는 너무 길었습니다.

모바일 화면에 맞게 3줄 요약을 제공해야 했습니다. "요약 모델을 직접 만들어야 하나요?" 김개발 씨가 걱정스럽게 물었습니다.

요약 모델 학습에는 수만 개의 기사-요약 쌍이 필요하다는 것을 알고 있었습니다. 박시니어 씨가 안심시켰습니다.

"Zero-Shot으로 충분히 가능해요. 제약 조건만 잘 주면 됩니다." 그렇다면 Zero-Shot 요약기란 정확히 무엇일까요?

쉽게 비유하자면, Zero-Shot 요약기는 마치 숙련된 편집자와 같습니다. 처음 보는 글이라도 핵심을 파악하고 중요한 내용만 추려낼 수 있습니다.

"이 부분이 핵심이고, 이건 부가 설명이니 빼도 되겠네"라고 판단하는 능력이 있습니다. 이처럼 Zero-Shot 요약기도 사전 학습된 언어 이해 능력으로 중요도를 판단하고 핵심만 추출합니다.

전통적인 요약 모델은 어떤 문제가 있었을까요? 기존 요약 모델은 도메인별로 따로 학습이 필요했습니다.

뉴스 요약 모델은 뉴스만 잘하고, 논문 요약은 못했습니다. 새로운 분야의 문서를 요약하려면 처음부터 다시 학습해야 했습니다.

또한 학습 데이터 수집이 매우 어려웠습니다. 각 기사마다 사람이 직접 요약문을 작성해야 했는데, 품질 좋은 요약을 만들려면 전문 에디터가 필요했습니다.

바로 이런 문제를 해결하기 위해 Zero-Shot 요약기가 강력합니다. Zero-Shot 요약기를 사용하면 다양한 도메인에 바로 적용할 수 있습니다.

뉴스, 블로그, 논문, 보고서 등 어떤 텍스트든 동일한 시스템으로 요약 가능합니다. 또한 요구사항 변경이 쉽습니다.

"3줄 요약"에서 "5줄 요약"으로 바꾸려면 프롬프트의 숫자만 수정하면 됩니다. 무엇보다 즉시 배포 가능합니다.

모델 학습 없이 당일에 서비스를 시작할 수 있습니다. 위의 코드를 단계별로 살펴보겠습니다.

제약 조건 부분이 핵심입니다. "정확히 N개 문장"이라고 명시하여 길이를 통제했습니다.

"객관적이고 사실 중심"이라는 스타일 가이드로 의견이 섞이는 것을 방지했습니다. "핵심 사실(누가, 무엇을, 언제, 어디서, 왜)"를 필수 포함 요소로 지정하여 정보 누락을 막았습니다.

num_sentences 파라미터로 요약 길이를 유연하게 조절할 수 있게 만들었습니다. 요약기의 품질을 높이는 방법을 알아봅시다.

첫째, 5W1H를 명시합니다. 누가(Who), 무엇을(What), 언제(When), 어디서(Where), 왜(Why), 어떻게(How) 중 중요한 요소를 포함하라고 지시합니다.

뉴스는 5W가 중요하고, 기술 문서는 What과 How가 중요합니다. 둘째, 제외 항목을 명확히합니다.

"개인 의견 제외", "배경 설명 제외" 같은 규칙으로 불필요한 내용을 걸러냅니다. 셋째, 길이를 구체적으로 제한합니다.

"짧게"보다는 "3개 문장", "100자 이내"처럼 정확한 수치를 사용합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 기업 내부 지식 관리 시스템을 만든다고 가정해봅시다. 직원들이 작성한 긴 보고서, 회의록, 제안서를 자동으로 요약하여 대시보드에 표시해야 합니다.

Zero-Shot 요약기를 사용하면 문서 유형에 관계없이 일관된 요약을 생성할 수 있습니다. "1줄 제목 + 3줄 본문" 형식으로 통일하여 UI에 맞춥니다.

직원들은 요약만 보고 필요한 문서를 빠르게 찾을 수 있습니다. 네이버, 카카오 같은 대기업 내부에서 이런 시스템을 활용하고 있습니다.

다양한 요약 스타일을 활용할 수도 있습니다. 추출형 요약은 원문의 중요한 문장을 그대로 뽑습니다.

"원문에서 가장 중요한 3개 문장을 선택하세요"라고 지시합니다. 생성형 요약은 새로운 문장으로 재작성합니다.

"핵심 내용을 당신의 표현으로 3줄로 작성하세요"라고 요청합니다. 키워드 기반 요약은 핵심 키워드를 중심으로 정리합니다.

"주요 키워드 5개를 추출하고, 각 키워드를 한 문장으로 설명하세요"라고 합니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 너무 긴 텍스트를 요약하려는 것입니다. 10,000자가 넘는 문서는 컨텍스트 윈도우를 초과하거나 핵심을 놓칠 수 있습니다.

이런 경우 문서를 섹션별로 나눠 요약한 후, 요약들을 다시 요약하는 2단계 접근법을 사용해야 합니다. 또 다른 실수는 요약 품질을 검증하지 않는 것입니다.

중요한 정보가 빠졌는지, 사실이 왜곡됐는지 샘플링하여 확인해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

Zero-Shot 요약기를 구현한 김개발 씨는 뉴스 기사 100개로 테스트했습니다. "대부분 핵심을 잘 잡아내네요!

이 정도면 바로 서비스에 적용할 수 있겠어요!" Zero-Shot 요약기를 제대로 이해하면 다양한 문서 처리 작업을 빠르게 자동화할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 긴 문서(5000자 이상)는 섹션별로 나눠 요약한 후, 요약들을 다시 요약하세요

• 요약 품질 검증을 위해 샘플 20-30개를 사람이 직접 평가해보세요
• 5W1H 중 해당 도메인에서 중요한 요소를 우선순위로 지정하세요 (뉴스: Who/What/When, 기술 문서: What/How)

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!