제로샷 분류: 동작 원리와 활용 시점

새로운 범주로 텍스트를 분류해야 하는데, 학습에 쓸 단 하나의 레이블 예시도 없다면 어떻게 해야 할까요?

전통적인 분류기 방식은 통하지 않습니다. 예측하려는 모든 범주에 대해 레이블이 달린 예시를 요구하기 때문입니다. 즉, 학습을 시작하기 전까지 수주에 걸친 주석 작업이 필요하고, 새로운 범주가 나타나는 순간 다시 레이블링으로 돌아가야 합니다.

바로 이때 필요한 것이 제로샷 분류입니다. 학습 중 한 번도 보지 못한 레이블을 모델이 직접 할당하도록 해 전체 레이블링 단계를 건너뜁니다. 실무에서는 "요금 청구 불만"이나 "기능 요청" 같은 범주로 고객 피드백을 분류하면서도, 어느 쪽이든 단 하나의 학습 예시도 준비할 필요가 없다는 뜻입니다.

이 글에서는 제로샷 분류의 동작 원리, 전통적/퓨샷 접근법과의 비교, 그리고 Hugging Face Transformers로 실제 NLP 작업에 적용하는 방법을 살펴보겠습니다.

Hugging Face가 정확히 무엇인지 궁금하신가요? Hugging Face Fundamentals 트랙에 등록해 AI 에이전트를 만들고 LLM을 파인튜닝해 보세요.

제로샷 분류란?

제로샷 분류는 특정 레이블로 별도 학습하지 않았는데도 모델이 데이터에 레이블을 할당하는 머신러닝 접근법입니다.

핵심은 여기서 말하는 "제로샷"입니다. 예측하려는 범주에 대한 학습 예시가 0개라는 뜻입니다. 텍스트 한 조각과 가능한 레이블 목록을 주면, 모델은 자신이 이미 알고 있는 지식을 바탕으로 가장 잘 맞는 것을 고릅니다.

이 모든 지식은 사전학습에서 옵니다. 대규모 모델은 방대한 말뭉치에서 언어와 개념에 대한 폭넓은 이해를 습득하며, 새로운 것을 분류하라고 요구받을 때 바로 그 일반 지식을 활용합니다.

제로샷 분류의 동작 방식

단계를 나눠 보면 제로샷 분류의 워크플로는 간단합니다. 필요한 것은 네 가지뿐입니다.

1. 텍스트나 데이터를 입력합니다: 분류하려는 어떤 것이든 가능합니다. 고객 리뷰, 지원 티켓, 뉴스 헤드라인, 문서 일부 등.

2. 후보 레이블을 제공합니다: 가능한 범주 목록을 모델에 줍니다. "product question", "refund request", "technical issue", "general inquiry"처럼 단어 또는 짧은 구로 구성됩니다.

3. 모델이 입력과 레이블 간 관계를 평가합니다: 사전학습으로 습득한 언어 이해를 바탕으로 각 레이블이 입력에 얼마나 잘 맞는지 점수화합니다.

4. 가장 가능성 높은 레이블을 선택합니다: 가장 높은 점수를 받은 레이블이 예측값으로 반환되며, 종종 각 후보에 대한 신뢰도도 함께 제공됩니다.

핵심은 재학습 없이도 언제든 후보 레이블을 바꿀 수 있다는 점입니다. 내일 새로운 범주를 추가하고 싶다면 목록에 추가만 하면 됩니다. 지도학습만 해봤다면 꽤 놀라운 일입니다.

제로샷 분류 vs 전통적 분류

두 접근법 모두 동일한 문제(데이터에 레이블을 할당)를 해결하지만, 접근 방식이 다릅니다.

전통적 분류

전통적인 분류기는 레이블이 붙은 예시로부터 학습합니다. 각 항목에 올바른 범주가 태깅된 데이터셋을 수집하고, 그 위에 모델을 학습시켜 클래스 간을 구분하는 패턴을 학습합니다.

수십 년간 효과적이었지만, 두 가지 큰 제약이 있습니다:

• 레이블이 달린 학습 데이터가 필요합니다: 종종 매우 많이 필요합니다. 데이터를 수집하고 주석을 다는 일은 시간과 비용, 즉 가장 가치 있는 유한 자원을 소모합니다.
• 레이블 집합이 고정됩니다: 한 번 학습되면, 모델은 학습 중에 본 범주만 예측할 수 있습니다. 새 클래스를 추가하려면 다시 학습해야 합니다.

제로샷 분류

제로샷은 정반대로 작동합니다. 작업별 학습 단계가 전혀 없습니다. 사전학습에서 배운 지식을 활용해 어떤 레이블이든 평가합니다.

이를 통해 두 가지 이점을 얻습니다:

• 작업별 학습이 필요 없습니다: 데이터 수집, 주석, 학습을 통째로 건너뜁니다.
• 유연한 레이블 집합: 상황에 따라 범주를 바꿀 수 있습니다. 새로 추가하거나, 제거하거나, 이름을 바꿔도—재학습 없이 모델이 처리합니다.

트레이드오프

이 유연성은 공짜가 아닙니다. 탄탄한 레이블 데이터셋으로 학습된 전통적 분류기는 해당 작업에 한해 보통 제로샷 모델보다 더 좋은 성능을 냅니다. 관심 있는 예시를 정확히 보고 그에 맞춰 최적화되었기 때문입니다.

제로샷 모델은 제너럴리스트입니다. 많은 일을 꽤 잘하지만, 특정 하나에 최고는 드뭅니다. 따라서 선택은 필요에 달려 있습니다.

레이블 데이터가 있고 고정된 범주에서 최고 정확도가 중요하다면 전통적인 분류기를 학습하세요. 레이블 데이터가 없거나 범주가 자주 바뀐다면, 제로샷이 작동하는 해법에 더 빨리 도달하는 길입니다.

파운데이션 모델과 LLM의 역할

제로샷 분류가 대중화된 이유는 대형 사전학습 모델이 이를 감당할 만큼 충분히 좋아졌기 때문입니다.

파운데이션 모델 이전에는 한 번도 본 적 없는 레이블 목록을 모델에 건네고 그럴듯한 예측을 기대할 수 없었습니다. 모델이 언어를 충분히 이해하지 못했기 때문입니다. 그러나 방대한 말뭉치로의 사전학습이 상황을 바꿨습니다. 인터넷의 상당 부분을 읽은 모델은 이미 "refund"나 "complaint" 같은 단어를 무수한 맥락에서 접했으므로, 새로운 입력과의 매칭이 가능해졌습니다.

오늘날 대부분의 제로샷 워크플로 뒤에는 몇 가지 모델 계열이 있습니다:

• BERT와 그 변형: BERT 계열 모델은 사전학습 중 텍스트의 심층 표현을 학습합니다. RoBERTa와 DeBERTa 같은 변형은 더 나은 학습 방법과 더 큰 데이터셋으로 이를 확장했습니다.
• NLI 기반 모델: 자연어 추론 작업으로 파인튜닝된 모델입니다. 대부분의 기성 제로샷 파이프라인의 기반이며, 다음 절에서 그 이유를 설명하겠습니다.
• 현대 LLM: GPT 계열이나 Claude 같은 대형 언어 모델은 프롬프트만으로 제로샷 분류를 수행할 수 있습니다. 작업을 자연어로 설명하고 범주를 나열하면 모델이 하나를 선택합니다.

공통점은 규모와 범용성입니다. 좁은 작업에 학습된 모델은 그 작업만 할 수 있습니다. 폭넓은 텍스트 데이터로 학습된 모델은 레이블 예시를 보지 않았더라도 많은 작업으로 전환할 수 있습니다.

자연어 추론(NLI)과 제로샷 분류

실무에서 접하는 대부분의 제로샷 분류기는 NLI 모델을 기반으로 합니다. 다소 의외일 수 있어 천천히 설명하겠습니다.

자연어 추론은 별도의 작업입니다. 두 문장(전제와 가설)이 주어지면, 모델은 둘의 관계를 판별합니다. 출력은 세 가지 레이블 중 하나입니다:

• 함의(Entailment): 가설이 전제로부터 따라옵니다.
• 모순(Contradiction): 가설이 전제와 모순됩니다.
• 중립(Neutral): 두 문장이 관련 없거나, 판단하기에 정보가 부족합니다.

예를 들어 전제가 "The team finished the project two weeks early"이고 가설이 "The team delivered on time"라면, NLI 모델은 함의를 예측해야 합니다. 가설이 "The team missed the deadline"라면 모순을 예측해야 합니다.

이 설정은 제로샷 분류에 아주 잘 맞습니다. 입력을 전제로 두고, 각 후보 레이블을 가설로 바꾸면 됩니다.

예를 들어 "My package never arrived"라는 문장을 배송 문제, 결제 문제, 제품 문의 중 하나로 분류하고 싶다고 합시다. 모델은 이것들을 레이블로 보지 않습니다. 보통 "This text is about {label}" 같은 간단한 템플릿으로 감싼 가설로 인식합니다:

• 전제: "My package never arrived" | 가설: "This text is about a shipping issue"

• 전제: "My package never arrived" | 가설: "This text is about a billing issue"

• 전제: "My package never arrived" | 가설: "This text is about a product question"

NLI 모델은 각 쌍을 점수화합니다. 함의 점수가 가장 높은 가설이 승자가 되고, 해당 레이블이 예측값이 됩니다.

모델은 학습 중 "shipping issue"나 "billing issue"를 레이블로서 배운 적이 없습니다. 다만 일반적으로 함의가 어떤 것인지—NLI 파인튜닝 중에—배웠을 뿐입니다.

이 때문에 NLI 기반 제로샷이 잘 작동합니다. 모델은 자신이 학습한 작업(함의 판단)을 수행하고, 우리는 분류 문제를 일련의 함의 질문으로 프레이밍할 뿐입니다.

제로샷 vs 퓨샷 vs 파인튜닝 모델

풀 학습 없이도 분류 작업을 수행하는 방법은 제로샷만이 아닙니다. 대안을 비교해 보겠습니다.

제로샷

제로샷은 예시가 전혀 없습니다. 모델에 입력과 후보 레이블 목록을 건네면, 사전학습에서 배운 내용을 바탕으로 예측합니다.

모델은 특정 작업에 대한 레이블 데이터를 본 적이 없습니다. 전적으로 일반 지식에 의존해 동작합니다.

퓨샷

퓨샷은 보통 프롬프트 안에 몇 개의 예시를 제공합니다. 입력과 올바른 레이블을 짝지은 2개, 5개, 많아야 10개 정도를 보여준 다음, 같은 방식으로 새 입력을 분류하도록 요청합니다.

여기서 모델을 재학습하는 것은 아닙니다. 여전히 사전학습된 가중치를 사용합니다. 예시는 참조 역할—이 범주들이란 이런 뜻이라는 간단한 안내—만 합니다.

파인튜닝

파인튜닝은 전용 학습 과정입니다. 사전학습된 모델에 작업용 레이블 데이터셋을 제공하고, 특정 범주를 잘 예측할 때까지 가중치를 업데이트합니다.

세 가지 중 가장 무겁습니다. 레이블 데이터, 학습 인프라, 시간이 필요합니다. 그 대가로 모델은 작업에 특화됩니다.

세 가지 비교

실무에서 중요한 세 가지—정확도, 유연성, 비용—에서 접근법들은 다르게 나타납니다.

대안과 비교한 제로샷 러닝

이 표에서 몇 가지를 짚어 볼 만합니다.

정확도는 깔끔한 서열이 아닙니다. 충분한 레이블 데이터가 있고 작업이 안정적이면 파인튜닝이 승리합니다. 하지만 예시가 전혀 없는 신규 작업에서는 파인튜닝 자체가 선택지가 아니고, 제로샷만이 현실적입니다.

유연성은 반대로 움직입니다. 제로샷은 언제든 범주를 바꿀 수 있습니다. 파인튜닝 모델은 학습 당시의 레이블 집합에 묶입니다.

비용은 가장 직관적입니다. 제로샷은 설정 비용이 거의 없습니다. 퓨샷은 소규모 주석 단계가 추가됩니다. 파인튜닝은 그 자체가 프로젝트이며 전용 인프라가 필요합니다.

대부분의 팀은 제로샷으로 시작해 작업이 가능한지 확인합니다. 정확도가 부족하면 퓨샷으로, 그래도 모자라고 중요한 작업이면 파인튜닝으로 이동합니다.

NLP에서의 제로샷 분류

제로샷 분류는 레이블 데이터 확보가 어렵거나 범주가 계속 변하는 워크플로에서 자주 등장합니다. 대표적 적용 사례는 다음과 같습니다.

감성 분석

감성 분석은 교과서적인 출발점입니다. 텍스트를 입력하고 "positive", "negative", "neutral" 같은 레이블 중에서 고르게 합니다.

흥미로운 점은 표준 3가지를 넘어서는 것이 얼마나 쉬운가입니다. 전통적 감성 분류기는 학습한 것에 고정됩니다. 제로샷에서는 "frustrated", "satisfied", "confused", "excited" 같은 더 구체적 레이블을 사용할 수 있고, 재학습 없이 모델이 처리합니다. 제품 피드백이나 소셜 모니터링처럼 관심 감정 범주가 맥락에 의존하는 경우에 특히 유용합니다.

주제 분류

주제 분류는 문서를 주제 영역으로 분류합니다. 뉴스 기사를 "politics", "sports", "technology", "finance"로, 지원 티켓을 "billing", "shipping", "account access", "feature request"로 분류하는 식입니다.

제로샷이면 설정이 매우 간단합니다. 새 주제마다 레이블 데이터셋이 필요하지 않습니다. 제품에 새 기능이 출시되어 관련 티켓을 추적하고 싶다면, 후보 레이블 목록에 "new feature feedback"만 추가하면 끝입니다.

의도 탐지

의도 탐지는 사용자가 무엇을 하려는지 파악합니다. 대부분의 챗봇과 음성 비서의 엔진입니다. 누군가 "I need to change my password"라고 입력하면, 모델은 "password reset" 의도로 인식해야 하며, "general security question"로 오인해서는 안 됩니다.

이 영역에서 제로샷이 빛을 발합니다. 실제 제품은 시간이 지나며 새로운 사용자 의도가 계속 추가되며, 제품 팀이 기능을 추가할 때마다 의도 분류기를 재학습하는 일은 큰 부담입니다. 제로샷은 모델 변경 없이 의도 목록을 최신 상태로 유지하게 해 줍니다.

콘텐츠 모더레이션

콘텐츠 모더레이션은 문제성 텍스트—"hate speech", "spam", "harassment", "misinformation" 등—을 표시합니다. 플랫폼은 정책을 최신으로 유지해야 하며, 새로운 유형의 남용이 나타나면 범주도 바뀝니다.

여기서 제로샷이 잘 맞습니다. 모더레이션 팀은 정책 변화에 따라 레이블 정의를 조정하거나 새 범주를 추가할 수 있으며, 재학습 사이클을 위해 엔지니어링 팀에 의존하지 않아도 됩니다. 보통 대량 케이스에는 전통적 분류기와 병행하지만, 레이블 예시가 부족해 학습할 수 없는 롱테일 범주는 제로샷이 처리합니다.

Hugging Face Transformers로 제로샷 분류하기

Hugging Face의 transformers 라이브러리는 Python에서 제로샷 분류를 시도하기 가장 쉬운 방법입니다. pipeline API가 거의 모든 모델 로딩 작업을 숨겨 주기 때문에, 몇 줄의 코드만으로 바로 예측까지 갈 수 있습니다.

이 코드 스니펫을 처음 실행할 때는 모델이 다운로드되므로 시간이 조금 걸립니다.

바로 실행 가능한 전체 예시는 다음과 같습니다:

from transformers import pipeline
from pprint import pprint

# Load a zero-shot classification pipeline
classifier = pipeline(
    "zero-shot-classification",
    model="facebook/bart-large-mnli"
)

# The text you want to classify
text = "My package never arrived and customer support hasn't responded in three days."

# The labels you want the model to choose from
candidate_labels = [
    "shipping issue",
    "billing issue",
    "product question",
    "general inquiry"
]

# Run the classification
result = classifier(text, candidate_labels)

pprint(result)

출력은 세 개 필드를 가진 딕셔너리입니다. 원본 입력, 가장 그럴듯한 순서로 정렬된 후보 레이블, 각 레이블의 신뢰도 점수입니다.

파이프라인 출력

"shipping issue"가 신뢰도 0.82로 승리합니다. 모델은 학습 중 배송 불만의 레이블 예시를 본 적이 없지만, 앞 절에서 다룬 대로 NLI 데이터로 파인튜닝된 사전학습 모델 bart-large-mnli를 바탕으로 이를 파악한 것입니다.

이 워크플로에서 짚어둘 점이 몇 가지 있습니다:

• 모델은 NLI 모델입니다: bart-large-mnli는 MultiNLI 데이터셋으로 파인튜닝된 BART입니다. 파이프라인을 호출하면, 내부적으로 레이블을 가설로 변환해 모델을 실행합니다.

• 언제든 레이블을 바꿀 수 있습니다: 모델은 바꿀 필요가 없습니다. candidate_labels 목록만 교체하면 다른 범주로 분류합니다.

• 멀티 레이블은 플래그 하나면 됩니다: 파이프라인 호출 시 multi_label=True로 설정하면, 레이블들이 서로 경쟁하지 않습니다. 각 레이블이 독립 확률을 받아 하나의 입력이 여러 범주에 속할 수 있습니다.

result = classifier(text, candidate_labels, multi_label=True)
pprint(result)

멀티 레이블 출력

이것이 전체 워크플로입니다. 파이프라인을 로드하고, 레이블을 정의하고, 분류기를 호출하세요. 처음부터 분류 모델을 만드는 것보다 훨씬 빠르고 간단합니다.

제로샷 분류에서 흔한 실수

제로샷 분류는 설정이 쉽기 때문에, 그만큼 오용도 쉽습니다. 실제 프로젝트에서 자주 발생하는 실수는 다음과 같습니다.

모호한 레이블 선택

레이블은 모델에게 작업을 전달하는 방식입니다. 모호한 레이블은 모호한 예측을 낳습니다.

"good"와 "bad"는 모델에 많은 정보를 주지 않습니다. "customer is happy with the product"와 "customer is reporting a problem with the product"처럼 의미 있는 구를 사용하면 모델이 입력과 더 잘 대조할 수 있습니다. 레이블이 의미 있는 구절처럼 보일수록 모델은 더 잘 점수화합니다.

또한 겹치는 레이블은 피하세요. 후보 목록에 "complaint"와 "negative feedback"가 모두 있다면, 모델은 신뢰도를 둘로 나눠 어느 쪽도 명확한 승자가 되지 않습니다.

제로샷이 파인튜닝 성능에 필적한다고 가정

가장 흔한 오해입니다. 제로샷은 좋지만, 마법은 아닙니다.

수천 개의 레이블 예시로 특정 작업에 학습된 파인튜닝 모델은 거의 언제나 같은 작업에서 제로샷보다 우수합니다. 제로샷에서 정확도 85%를 보이는데 운영에 95%가 필요하다면, 레이블을 아무리 다듬어도 그 격차는 메워지지 않습니다. 그 시점에서는 파인튜닝이 해답입니다.

레이블 데이터가 없을 때, 범주가 자주 바뀔 때, 또는 "충분히 괜찮음"이 정말로 충분할 때 제로샷을 사용하세요. 설정이 빠르다는 이유만으로 선택했다가, 고위험 작업에서 성능이 부족하다고 놀라지 마세요.

지나치게 좁은 데이터셋으로 평가

흔히 이렇게 진행됩니다. 제로샷 분류기를 만들고, 직접 작성한 50개 예시로 테스트했더니 모두 맞았습니다. 배포했더니, 운영에서는 형편없다고 불만이 쏟아집니다.

당신이 작성한 50개 예시는 실제 사용자가 보내는 것과 대표성이 떨어집니다. 더 깔끔하고, 더 명확하며, 당신이 범주를 생각하는 방식에 더 가깝습니다. 모델이 실제로 보게 될 데이터—오타, 속어, 엣지 케이스가 포함된 사용자 생성 텍스트—로 평가하세요. 아직 그런 데이터가 없다면, 실제 입력 몇백 건을 샘플링해 수작업으로 레이블링한 뒤에 수치를 신뢰하세요.

도메인 특화 언어를 무시

범용 제로샷 모델은 범용 언어를 압니다. 업계 전문 용어는 모릅니다.

의학 용어, 법률 문구, 금융 약어, 엔지니어링 규격 등은 사전학습 모델이 접했을 수는 있어도 깊이 있게 보지는 못했습니다. ICD-10 코드나 SQL 오류 메시지로 가득한 문장을 범용 제로샷 모델로 분류하라고 하면, 결과가 들쑥날쑥할 수 있습니다.

해결책은 두 가지입니다. 레이블을 모델이 이해하기 쉬운 평이한 언어로 다시 쓰거나, 해당 도메인 텍스트로 사전학습된 모델로 전환하세요. 의료 텍스트에는 BioBERT, 금융 텍스트에는 FinBERT처럼 도메인 특화 모델이 전문 작업에서 범용 모델보다 종종 더 뛰어납니다.

현대 AI에서 제로샷 분류가 중요한 이유

제로샷 분류는 파운데이션 모델이 AI에서 가능한 범위를 어떻게 바꿨는지를 가장 명확히 보여주는 사례 중 하나입니다.

10년 전만 해도 모든 분류 작업은 같은 질문으로 시작했습니다. 레이블 데이터가 있는가? 없다면 어떻게 확보할 것인가? 주석 프로젝트는 수개월이 걸리고, 예산과 벤더 조율, 품질 관리가 필요했습니다. 데이터가 준비되기 전까지 모델은 만들 수도 없었습니다.

이 가정은 더 이상 사실이 아닙니다.

폭넓은 텍스트 데이터로 학습된 파운데이션 모델은, 당신이 작업을 설명하는 순간 새로운 분류 작업을 처리할 만큼 언어를 이미 이해합니다. 정의해야 할 것은 레이블 목록뿐입니다.

이 변화는 AI의 더 큰 흐름과 맞닿아 몇 가지 이유로 중요합니다:

• 파운데이션 모델의 진짜 목적을 보여줍니다: 대규모 사전학습의 요지는 재학습 없이도 많은 작업으로 전환 가능한 충분히 범용적인 모델을 만드는 것이었습니다. 제로샷 분류는 그 약속이 작동하는 가장 깔끔한 예 중 하나입니다.
• 지도 데이터셋 의존도를 낮춥니다: 레이블 데이터는 여전히 유용하지만, 작동하는 분류기를 만들기 위한 필수 조건은 더 이상 아닙니다. 주석 예산이 없는 팀도 가치 있는 AI 기능을 배포할 수 있습니다.
• 배포 속도를 바꿉니다: 예전엔 분기별로나 가능했던 분류 기능이 이제는 오후만에 프로토타입이 가능합니다. 시도 비용이 거의 0으로 떨어졌기에 팀이 무엇을 만들지 선택하는 방식에도 영향을 줍니다.

더 넓은 흐름은 작업별 모델에서 범용 모델로의 이동입니다. 파인튜닝과 스크래치 학습이 필요할 때는 여전히 제자리가 있습니다. 하지만 기본 출발점은 바뀌었습니다. 먼저 사전학습 모델을 가져다 쓰고, 데이터가 뒷받침될 때에만 특화합니다.