왜 모델이 필요한가¶

이 챕터에서 배우는 것

규칙(if-else) 로 풀 문제와 모델로 풀 문제를 구분하는 직관
AI Assistant 프로젝트를 시작하기 전 반드시 통과해야 하는 3가지 판단 기준 (OpenAI 권장)
같은 문제를 룰 / 모델로 풀어보며 어디서 룰이 깨지는지 손으로 확인

1. 시작 — 작은 실험¶

아래 사용자 메시지 5개를 읽어보세요. 목표는 "환불 요청인가 아닌가" 를 판별하는 거예요.

#	사용자 메시지	환불 요청?
1	"환불해주세요"	✅
2	"돈 돌려줘"	✅
3	"이거 생각했던 거랑 너무 달라요. 어떻게 해야 하나요?"	✅ (암묵적)
4	"환불 정책이 어떻게 되나요?"	❌ (정보 요청)
5	"친구가 환불받았다고 하던데"	❌ (상황 공유)

질문: if "환불" in message 같은 룰 한 줄로 이 5개를 맞게 분류할 수 있나요?

1, 2, 4, 5는 어떻게든 가능. 3번은 불가능 — "환불"이라는 단어 자체가 없으니까요.
규칙을 더 추가해서 4, 5를 제외하려 하면 규칙이 수십 줄로 늘어나고, 새로운 표현이 나올 때마다 또 늘어납니다.

이게 "모델이 필요한 순간" 의 신호입니다.

2. 규칙 vs 모델 — 근본적인 차이¶

두 가지 접근

위: 작성자가 모든 경우를 미리 나열해야 함. 아래: 모델이 본 적 없는 표현도 추론.

표로 정리¶

	규칙 (코드)	모델 (LLM)
사고방식	"이 조건이면 이 결과"	"이 문맥에서 가장 그럴듯한 결과"
장점	예측 가능 · 무료 · 빠름 · 감사 용이	비정형 입력 처리 · 학습 없이도 새 표현 이해
단점	새 표현·예외마다 규칙 추가 · 유지 비용↑	확률적 · 비용 · 지연 · 검증 어려움
실패 방식	안 잡힘 (silent miss)	그럴듯한 오답 (hallucination)
디버깅	스택 추적, 로그	프롬프트·예시·평가셋

3. 판단 기준 — 3가지 조건 (OpenAI 권장)¶

Anthropic/OpenAI 엔지니어링 가이드가 공통으로 권하는 기준입니다. 아래 셋 중 하나라도 해당되면 모델을 쓸 가치가 있습니다. 셋 다 아니면 그냥 코드로 푸세요.

복잡한 판단¶

규칙으로 다 커버 안 되는 미묘한 결정 · 예외 · 문맥 민감한 판단.

예: 고객 서비스 환불 승인, 보험 청구 심사, 이상 거래 판별.

유지하기 힘든 규칙¶

규칙셋이 방대·복잡해 업데이트 비용이 비싸거나 오류가 잦은 시스템.

예: 벤더 보안 심사 체크리스트 수백 줄, 수십 개의 엣지 케이스.

비정형 데이터 의존¶

자연어 해석 · 문서에서 의미 추출 · 대화형 상호작용이 본질인 업무.

예: 주택보험 청구 처리, 사내 지식 검색, 고객 문의 요약.

통과 조건

세 조건 중 하나만이라도 명확히 해당되면 Go. 전부 애매하면 Stop — 모델을 넣으면 규칙보다 더 나쁜 결과가 나올 수 있습니다.

4. AI Assistant가 필요한 대표 시나리오¶

판단 기준을 실제 업무에 대입해봅시다.

시나리오	판단 포인트	매칭된 조건
사용자 의도 분류 (환불 요청 vs 정책 질문 vs 기타)	표현이 수십 가지	③ 비정형
문서 기반 QA ("보안 정책 A4 몇 페이지에 있나요")	문서 이해 필요	③ 비정형 + ② 규칙 방대
업무 요약 (회의록 → 액션 아이템)	문맥 판단	① 복잡 결정 + ③ 비정형
응답 초안 생성 (CS 이메일 답장 초안)	톤·상황 이해	① + ③
티켓 라우팅 (내용에 따라 담당 팀 분배)	애매한 케이스	① + ②

이 책의 전체 길은 어느 지점부터 시작하는가¶

기술 선택의 계단

왼쪽에서 오른쪽으로 갈수록 비용·복잡도↑, 대응 가능 범위↑. "바로 Agent부터"는 거의 항상 오버엔지니어링.

5. 최소 예제 — 룰이 깨지는 순간 직접 보기¶

아무 라이브러리 설치 없이 파이썬만 있으면 됩니다.

rule_vs_intent.py
messages = [
    "환불해주세요",
    "돈 돌려줘",
    "이거 생각했던 거랑 너무 달라요. 어떻게 해야 하나요?",  # (1)!
    "환불 정책이 어떻게 되나요?",
    "친구가 환불받았다고 하던데",
]

KEYWORDS = ["환불", "돌려", "취소"]

def is_refund_request_by_rule(msg: str) -> bool:
    return any(k in msg for k in KEYWORDS)

for m in messages:
    print(f"[{is_refund_request_by_rule(m)}]  {m}")

이 문장이 규칙의 무덤. "환불" · "돌려" · "취소" 어떤 키워드도 없지만 의미는 환불 요청.

실행 결과¶

#	결과	메시지	판정
1	`True`	환불해주세요	✅
2	`True`	돈 돌려줘	✅
3	`False`	이거 생각했던 거랑 너무 달라요. 어떻게 해야 하나요?	❌ 놓침 (miss)
4	`True`	환불 정책이 어떻게 되나요?	❌ 오탐 (false positive)
5	`True`	친구가 환불받았다고 하던데	❌ 오탐

3번 놓침 + 4·5번 오탐. 이 정확도로는 운영 불가능.

LLM으로 풀면 (Part 2에서 실제 돌려봅니다)¶

intent_by_llm.py
from anthropic import Anthropic
client = Anthropic()

SYSTEM = """사용자 메시지가 '환불 요청'인지 판별하세요.
답: 'YES' 또는 'NO' 한 단어로만."""

for m in messages:
    r = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=5,
        system=SYSTEM,
        messages=[{"role": "user", "content": m}],
    )
    print(f"[{r.content[0].text.strip()}]  {m}")

기대 결과 (대략):

#	결과	메시지	비고
1	`YES`	환불해주세요
2	`YES`	돈 돌려줘
3	`YES`	이거 생각했던 거랑 너무 달라요…	암묵적 의도 감지
4	`NO`	환불 정책이 어떻게 되나요?	정보 요청 구분
5	`NO`	친구가 환불받았다고 하던데	상황 공유 구분

차이가 핵심입니다 — 새 표현을 규칙에 추가하지 않아도 의도를 잡아냅니다.

6. 실전 튜토리얼 — "내 업무에 모델이 필요한가" 진단¶

30분짜리 간단한 진단:

문제를 한 문장으로 정의: "___에서 ___을 ___한다"
같은 입력/출력 예시 30건 적어보기. 고르게 분포되게 (정상·엣지·애매 섞어서)
가장 단순한 규칙을 작성 — 키워드 매칭·정규식·룩업 테이블
30건 중 몇 건이 맞았나? 정확도 분포를 본다
틀린 건을 분류:
A. "규칙을 하나 더 추가하면 되는" 것 → 코드
B. "패턴이 수없이 다양해서 규칙으로 못 잡는" 것 → 모델 후보
C. "사람도 애매한" 것 → 정의 자체를 다시 볼 것
B가 전체의 30% 이상 이면 모델 투입할 가치 있음

출력물

이 진단의 결과물이 곧 평가셋의 씨앗입니다. Part 4에서 다시 씁니다.

7. 자주 깨지는 포인트¶

실수 1. 모델부터 꽂아놓고 시작

"AI 써서 똑똑해 보이게" 하려고 모델 먼저 쓰면, 룰이면 5줄이었을 기능이 200줄 시스템이 됩니다. 3조건 중 하나도 해당 안 되면 모델 금지.

실수 2. '모델이면 다 풀어줄 것'이라는 기대

모델은 확률적 추론이라 같은 입력에 다른 출력이 나올 수 있습니다. 결정론적 보장이 필요한 기능(가격 계산·권한 체크)은 절대 모델로 하지 마세요.

실수 3. 평가 없이 배포

"프롬프트 좋아 보여요" ≠ "운영에서 잘 작동해요". Part 4의 평가셋이 없으면 체감 품질만 가지고 논쟁하게 됩니다.

실수 4. 규칙과 모델을 섞는 걸 두려워함

많은 실전 시스템은 규칙 + 모델 하이브리드. 명확한 부분은 규칙으로 걸러내고, 애매한 부분만 모델로 보내세요. 훨씬 싸고 안정적입니다.

8. 운영 시 체크할 점¶

"코드로 풀 문제를 모델로 풀고 있진 않은가" 월 1회 리뷰
반대로 "모델이 꼭 필요한데 여전히 규칙으로 버티는" 부분도 리뷰
하이브리드 비율 기록 — 입력의 몇 %가 규칙에서 처리되고 몇 %가 모델로 가는가
모델 비용 · 지연 · 정확도 셋을 분기별 대시보드로
새 유즈케이스 제안 시 3조건 체크리스트 필수 통과

9. 확인 문제¶

지금 맡고 있는 업무에서 규칙으로 풀리지 않는 것 3가지를 뽑고, 각각에 3조건 중 무엇이 해당하는지 표시
§5 코드를 실제로 돌려 규칙의 miss/false positive 수를 기록
규칙에 예외 10개를 추가하며 정확도가 얼마나 오르는지 측정 — 어디서 한계가 오는가
"모델이 아예 필요 없는 기능" 하나, "규칙보다 확실히 나은 기능" 하나를 자기 프로젝트에서 뽑아 한 문단씩 설명

10. 한눈 요약¶

결정 흐름

다음 챕터 → LLM이란 무엇인가
모델을 쓰기로 판단했다면, 그 "모델"이 어떻게 작동하는지 최소한은 알아야 합니다.