Topic과 Intent는 다른 것이다

0. 같은 것처럼 보이는 이유

챗봇이나 NLU 시스템을 처음 설계할 때 가장 흔히 마주치는 혼란이 있다. Topic과 Intent를 같은 것으로 취급하거나, 어느 것을 써야 할지 모른 채 두 단어를 번갈아 사용하는 것이다.

실제로 이런 레이블 목록을 보는 일이 드물지 않다.

분류 카테고리:
- 결제 문의
- 배송 문의
- 환불 요청
- 비밀번호 변경
- 계정 잠김

앞의 두 개(결제 문의, 배송 문의)와 뒤의 세 개(환불 요청, 비밀번호 변경, 계정 잠김)는 근본적으로 다른 종류다. 전자는 Topic이고 후자는 Intent다. 같은 목록에 섞여 있으면 시스템이 일관되게 작동하지 않는다.

이 글은 두 개념이 기술적으로 어떻게 다른지, 왜 섞이면 안 되는지를 설명한다.

1. 질문이 다르다

두 개념의 차이는 각각이 답하려는 질문에서 시작된다.

Topic: "이 발화는 무엇에 관한 이야기인가?" Intent: "이 사용자는 무엇을 하려는가?"

같은 발화에 두 질문을 동시에 던져볼 수 있다.

발화	Topic (관한)	Intent (하려는)
"지난달 요금 왜 이렇게 나왔어요?"	`billing`	`dispute_charge`
"비밀번호 바꾸고 싶어요"	`account`	`reset_password`
"주문한 상품 어디쯤 왔어요?"	`shipping`	`track_order`

Topic은 내용 영역(domain)을 가리킨다. Intent는 사용자의 구체적인 목표 행동을 가리킨다. 두 개념은 같은 발화를 서로 다른 축에서 분석한 결과다.

2. 모델이 다르다

두 개념이 다르다는 것은 모델링 방식도 다르다는 뜻이다.

Topic 모델: 생성 모델 또는 임베딩 클러스터링

Topic Modeling은 레이블 없이도 작동한다. 대표적인 두 방법을 보자.

LDA (Latent Dirichlet Allocation)

문서를 복수의 주제가 섞인 확률적 혼합으로 모델링한다. 각 주제는 단어들의 분포로 표현된다.

문서 = [주제A × 0.6] + [주제B × 0.3] + [주제C × 0.1]
주제A = {결제: 0.3, 요금: 0.2, 청구: 0.15, ...}

데이터에 레이블이 없어도 단어의 공출현 패턴만으로 주제를 발견한다. 해석 가능성이 높지만 짧은 텍스트(발화 수준)에서는 성능이 떨어진다.

BERTopic

SBERT로 문서를 임베딩한 뒤, UMAP으로 차원을 줄이고 HDBSCAN으로 클러스터링한다. 마지막으로 c-TF-IDF로 클러스터를 대표하는 단어를 추출한다. 짧은 텍스트와 현대적인 코퍼스에 적합하다.

공통점은 **비지도(unsupervised)**라는 것이다. 레이블을 미리 정의하지 않아도 데이터에서 주제 구조를 발견한다.

Intent 분류: 판별 모델

Intent Classification은 지도 학습이 기본이다. 사전에 Intent를 정의하고 레이블링된 데이터로 모델을 훈련한다.

BERT 기반 방식이 현재 표준이다. [CLS] 토큰의 표현을 classification head에 넘겨 Intent를 예측한다. 실무에서는 Intent 분류와 Slot(Entity) 추출을 동시에 수행하는 Joint 모델을 많이 사용한다.

입력: "서울에서 내일 부산 가는 기차 예약해줘"
    ↓ Joint BERT
Intent: book_train
Slots: {출발지: 서울, 목적지: 부산, 날짜: 내일}

Slot이 없으면 Intent만으로는 시스템이 할 일을 완전히 결정할 수 없다. Intent는 항상 Slot과 함께 설계해야 한다.

두 모델의 근본 차이

항목	Topic 모델	Intent 분류
학습 방식	비지도 가능	지도 학습 필수
레이블	사후 발견	사전 정의
출력	주제 분포 또는 주제 레이블	Intent 레이블 + Slots
처리 단위	문서 / 긴 텍스트	발화 / 단일 쿼리
다중 할당	자연스러움	제한적

3. 계층이 있다

두 개념이 대칭적인 것은 아니다. Topic이 상위 계층, Intent가 하위 계층이다.

Topic: billing (청구)
  ├── Intent: request_refund      (환불 요청)
  ├── Intent: check_invoice       (청구서 확인)
  └── Intent: dispute_charge      (요금 이의 제기)

Topic: account (계정)
  ├── Intent: reset_password      (비밀번호 재설정)
  ├── Intent: update_email        (이메일 변경)
  └── Intent: unlock_account      (계정 잠금 해제)

하나의 Topic 아래 여러 Intent가 존재한다. 이 관계는 설계 원칙이기도 하고, 연구에서도 확인된 구조다. Intent Discovery 연구에서는 Topic Modeling 결과를 상위 프레임으로 삼아 세밀한 Intent를 세분화하는 파이프라인을 사용한다.

이 계층 구조가 중요한 이유는 두 가지다. 첫째, Topic은 "어떤 영역의 문제인가"를 빠르게 파악하는 필터로 쓸 수 있다. 둘째, Intent는 그 영역 안에서 "구체적으로 무엇을 해야 하는가"를 결정하는 트리거로 쓸 수 있다. 둘을 분리하면 라우팅과 처리 로직이 명확히 분리된다.

4. 섞으면 어떤 일이 생기는가

Topic과 Intent를 혼용하면 세 가지 문제가 발생한다.

문제 1: 자동화 응답 불가

billing을 Intent로 정의하면 시스템은 "청구 영역이군" 하는 것만 알 뿐, 무엇을 해야 하는지 알 수 없다. request_refund라는 Intent가 있어야 환불 처리 플로우가 트리거된다.

Topic 레이블을 Intent 자리에 두면 분류 모델이 작동해도 시스템이 멈춘다.

문제 2: Taxonomy 붕괴

같은 수준에 Topic과 Intent가 섞이면 경계가 모호해진다. account(Topic)와 reset_password(Intent)가 동급 레이블로 있으면, reset_password가 account 아래 있어야 하는지 독립 레이블인지 어노테이터마다 다르게 판단한다. 레이블 간 일치도가 낮아지고 데이터 품질이 떨어진다.

문제 3: 모델 선택 혼란

Topic 모델(LDA, BERTopic)과 Intent 분류 모델(BERT, Joint BERT)은 아키텍처가 완전히 다르다. 무엇을 분류하는지가 명확하지 않으면 어떤 모델을 써야 하는지도 결정할 수 없다.

5. 구분하는 실용적 원칙

두 개념을 실무에서 구분하는 가장 쉬운 원칙이 있다.

Topic은 명사형 영역이다. Intent는 동사형 행동이다.

Topic  (명사형): billing / shipping / account / product
Intent (동사형): request_refund / track_order / reset_password / add_to_cart

레이블을 정의할 때 이 원칙으로 먼저 검사한다. 명사형으로 끝나면 Topic, 동사형(동사+목적어) 형태면 Intent다.

두 번째 검사는 시스템 행동 트리거 여부다. 이 레이블이 결정되면 시스템이 구체적인 행동을 수행할 수 있는가? 그렇다면 Intent다. 어떤 영역인지만 알 수 있다면 Topic이다.

6. 정리

Topic과 Intent가 자주 혼동되는 이유는 같은 발화에서 동시에 추출할 수 있기 때문이다. 그러나 두 개념이 답하는 질문이 다르고, 사용하는 모델이 다르고, 계층이 있다.

Topic: "관한" 것. 비지도 가능. 명사형 영역. 상위 계층.
Intent: "하려는" 것. 지도 학습. 동사형 행동. 하위 계층. Slot과 함께.

두 개념을 같은 레이블 목록에 섞으면 Taxonomy가 붕괴하고, 자동화 응답이 멈추고, 데이터 품질이 떨어진다.

레이블을 설계할 때 먼저 이 질문을 던지는 것으로 충분하다. "이것은 무엇에 관한가, 아니면 무엇을 하려는가?"

Evidence: [[evidence/topic-vs-intent/evidence__topic-vs-intent]]
Ontology: TI1(NLP Topic) · TI2(NLP Intent) · TI3(Topic-Intent 계층) — graph-ontology.yaml