Generative AI와 Traditional Machine Learning의 차이: 문제 정의, 파이프라인, 평가 기준

생성형 AI와 기존 머신러닝의 차이는 “새 모델이 옛 모델을 대체했는가”보다 “어떤 문제를 어떻게 정의하는가”로 보는 편이 정확하다.

전통적인 머신러닝 프로젝트는 보통 아래 질문으로 시작한다.

입력 X가 있을 때 예측해야 하는 y는 무엇인가?

생성형 AI 프로젝트는 자주 아래 질문으로 시작한다.

사용자 입력과 문맥이 있을 때 어떤 결과물을 생성해야 하는가?

둘 다 AI지만, 데이터 구조, 모델 사용 방식, 평가 방법, 운영 리스크가 다르다.

1. 전통 ML은 예측 문제로 정의된다

지도학습 기준으로 보면 전통 ML의 기본 구조는 명확하다.

training data = (X, y)
model.fit(X_train, y_train)
y_pred = model.predict(X_valid)
metric(y_valid, y_pred)

예를 들어 고객 이탈 예측이라면:

• X: 가입 기간, 최근 접속 횟수, 구매 금액, 문의 횟수
• y: 이탈 여부
• 출력: 0 또는 1
• 평가: accuracy, precision, recall, F1, ROC-AUC 등

회귀 문제라면:

• X: 면적, 위치, 방 개수
• y: 주택 가격
• 출력: 연속 숫자
• 평가: MAE, RMSE, R2 등

즉 기존 ML은 예측 대상과 평가 기준을 먼저 고정한다. 이 점이 강점이다. 반복 업무, 정형 데이터, 명확한 라벨, 수치 평가가 있는 문제에서는 여전히 강력하다.

2. 전통 ML 텍스트 분류 파이프라인

텍스트 작업도 LLM 이전부터 가능했다. 예를 들어 리뷰 감성 분류는 아래처럼 구성할 수 있다.

간단한 scikit-learn 파이프라인은 이런 형태다.

from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.linear_model import LogisticRegression
from sklearn.pipeline import Pipeline
from sklearn.metrics import classification_report

train_texts = [
    "배송이 빠르고 품질이 좋았습니다",
    "환불이 너무 늦고 상담이 불친절했습니다",
    "가격 대비 만족합니다",
    "제품이 파손되어 도착했습니다",
]
train_labels = ["positive", "negative", "positive", "negative"]

clf = Pipeline([
    ("tfidf", TfidfVectorizer()),
    ("model", LogisticRegression()),
])

clf.fit(train_texts, train_labels)

valid_texts = [
    "상담은 느렸지만 제품은 괜찮았습니다",
    "배송 지연 때문에 불만입니다",
]
valid_labels = ["positive", "negative"]

pred = clf.predict(valid_texts)
print(classification_report(valid_labels, pred))

이 접근의 장점은 명확하다.

• 빠르다.
• 비용이 낮다.
• 재현성이 좋다.
• 평가 지표가 명확하다.
• 특정 라벨 분류 작업에 적합하다.

하지만 한계도 있다.

• 새로운 표현, 은어, 복합 의도에 약할 수 있다.
• “왜 그렇게 판단했는지”를 자연어로 설명하려면 별도 로직이 필요하다.
• 요약, 답변 초안, 보고서 작성처럼 자유형 생성에는 맞지 않는다.

3. Generative AI는 생성 문제로 정의된다

LLM 기반 생성형 AI는 이미 대규모 텍스트로 사전학습된 모델을 사용한다. 실무자는 매번 모델을 처음부터 학습시키기보다, 프롬프트와 문맥을 설계해 모델을 호출한다.

prompt + context
  -> LLM
  -> generated output
  -> validation / review / post-processing

예를 들어 고객 문의를 처리한다면 출력은 단순 라벨 하나가 아닐 수 있다.

{
  "category": "환불/교환",
  "sentiment": "negative",
  "summary": "고객은 반품 접수 후 환불 일정이 지연된 점에 불만을 제기했다.",
  "reply_draft": "불편을 드려 죄송합니다. 주문번호를 확인해 환불 진행 상태를 안내드리겠습니다."
}

이런 출력은 전통 ML의 단일 분류 모델보다 더 풍부하다. 대신 평가와 통제가 더 어려워진다.

4. LLM 호출 파이프라인 예시

서비스 코드에서는 보통 prompt, model, parser를 분리한다.

from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import JsonOutputParser
from langchain_openai import ChatOpenAI

prompt = ChatPromptTemplate.from_template("""
너는 고객 문의를 분류하고 답변 초안을 작성하는 상담 지원 시스템이다.

아래 문의를 분석해서 JSON으로 출력하라.

출력 스키마:
- category: 배송, 환불/교환, 가격/쿠폰, 상품품질, 계정/기타 중 하나
- sentiment: positive, neutral, negative 중 하나
- summary: 한 문장 요약
- reply_draft: 상담원이 검토할 답변 초안

문의:
{inquiry}
""")

llm = ChatOpenAI(model="your-model")
parser = JsonOutputParser()

chain = prompt | llm | parser

result = chain.invoke({
    "inquiry": "반품 접수한 지 일주일이 지났는데 아직 환불이 안 됐습니다."
})

핵심은 model.fit()이 아니라 prompt -> model -> parser -> validation 흐름이다. 전통 ML에서 학습 데이터와 평가 지표가 중심이었다면, LLM 애플리케이션에서는 입력 문맥, 출력 스키마, 검증 기준, 운영 로그가 중요해진다.

5. 모델이 학습되는 방식도 다르다

전통 ML 프로젝트에서는 프로젝트 데이터로 모델을 직접 학습시키는 경우가 많다.

업무 데이터 수집
-> 전처리
-> feature engineering
-> train/valid/test split
-> model training
-> metric evaluation
-> deployment

LLM 프로젝트에서는 보통 이미 학습된 모델을 가져다 쓴다.

pretrained LLM
-> prompt engineering
-> retrieval context or tool connection
-> output parsing
-> human review / automated checks
-> monitoring

물론 LLM도 fine-tuning을 할 수 있다. 하지만 많은 업무에서는 fine-tuning보다 prompt, RAG, output schema, workflow 설계가 먼저다.

교육에서 이 차이를 놓치면 “LLM도 우리 데이터로 학습시켜야 하나요?”라는 질문이 매번 나온다. 실제로는 다음 순서로 판단하는 편이 좋다.

1. prompt만으로 충분한가?
2. 사내 문서 근거가 필요해 RAG가 필요한가?
3. 출력 형식과 기준만 고정하면 되는가?
4. 그래도 도메인 문체나 작업 패턴이 안 맞으면 fine-tuning이 필요한가?

6. 평가 방식의 차이

전통 ML 분류 모델은 평가 구조가 명확하다.

예를 들어 이탈 예측이라면:

• 실제 이탈 고객을 얼마나 잡았는가: recall
• 이탈이라고 예측한 고객 중 실제 이탈은 얼마나 되는가: precision
• 전체적으로 얼마나 맞혔는가: accuracy
• 클래스 불균형이 있는가: confusion matrix

반면 생성형 AI는 출력이 자유형이다.

질문: 이 계약서에서 고객에게 불리한 조항을 찾아줘.
출력: 조항 요약 + 위험도 + 근거 + 수정 제안

이 결과를 단순히 정답/오답으로만 보기는 어렵다.

LLM 평가에서는 보통 다음을 함께 본다.

• factual correctness: 사실이 맞는가?
• faithfulness: 제공된 근거와 일치하는가?
• completeness: 중요한 내용을 빠뜨리지 않았는가?
• format validity: JSON, 표, 문장 수 등 형식을 지켰는가?
• safety/compliance: 금지된 답변이나 정책 위반이 없는가?
• human usefulness: 실제 업무 담당자에게 도움이 되는가?

즉 기존 ML은 metric 중심이고, 생성형 AI는 rubric, sample review, automated judge, 로그 분석을 함께 써야 한다.

7. BERT/GPT 관점에서 보는 차이

생성형 AI를 이해할 때 Encoder/Decoder 구분도 도움이 된다.

아주 단순화하면:

• BERT 계열: 문장을 이해하고 분류/추출하는 작업에 많이 활용
• GPT 계열: 앞 문맥을 바탕으로 다음 토큰을 이어가며 생성하는 작업에 적합

물론 현대 모델은 더 복잡하게 발전했지만, 교육용 직관으로는 충분히 쓸 만하다.

전통 ML과 LLM의 차이를 아키텍처 이름으로만 외우면 오래 가지 않는다. 더 중요한 것은 출력 타입이다.

전통 ML:
  fixed input -> fixed output
  예: 고객 정보 -> 이탈 확률

LLM/GenAI:
  instruction + context -> generated output
  예: 문의 내용 + 정책 문서 -> 답변 초안

8. 언제 전통 ML을 선택할까

다음 조건이면 전통 ML이 좋은 선택일 가능성이 높다.

• 정형 데이터가 많다.
• 예측 대상 y가 명확하다.
• 반복적으로 같은 결정을 내려야 한다.
• 평가 지표를 숫자로 관리해야 한다.
• latency와 비용을 낮게 유지해야 한다.
• 설명 가능한 변수 영향도가 중요하다.

예:

• 이탈 예측
• 수요 예측
• 이상 거래 탐지
• 품질 불량 예측
• 고객 세그먼트 군집화
• 추천 랭킹의 일부 스코어링

9. 언제 생성형 AI를 선택할까

다음 조건이면 생성형 AI가 좋은 선택일 가능성이 높다.

• 비정형 텍스트가 많다.
• 문맥 이해가 중요하다.
• 자유형 답변이나 초안이 필요하다.
• 사용자의 질문이 매번 다르다.
• 사람이 검토할 1차 결과물을 빠르게 만들어야 한다.
• 외부 도구나 사내 문서를 연결해야 한다.

예:

• 회의록 요약
• 고객 답변 초안 생성
• 보고서 초안 작성
• 코드 생성
• 사내문서 Q&A
• 긴 문서 검토 보조
• 리뷰/문의의 이유 설명

10. 같이 쓰는 경우가 많다

실무에서는 둘 중 하나만 쓰는 경우보다 같이 쓰는 경우가 많다.

고객 문의 시스템을 예로 들면:

전통 ML:
  문의량 예측
  우선순위 스코어링
  이탈 가능성 예측

LLM:
  문의 요약
  답변 초안 생성
  정책 문서 기반 Q&A
  상담 이력에서 핵심 이슈 추출

Rule / Workflow:
  금지어 검사
  개인정보 마스킹
  상담원 승인
  티켓 시스템 업데이트

생성형 AI가 전통 ML을 대체한다기보다, AI 시스템에서 담당하는 층이 늘어난 것으로 보는 편이 낫다.

정리

전통 ML과 생성형 AI의 차이는 다음처럼 정리할 수 있다.

구분	전통 머신러닝	생성형 AI
문제 정의	X로 y 예측	instruction과 context로 결과 생성
주 데이터	정형 데이터, 라벨 데이터	비정형 텍스트, 문서, 대화
출력	라벨, 숫자, 점수	문장, 요약, 코드, 답변, JSON
핵심 설계	feature, label, metric	prompt, context, schema, validation
평가	accuracy, F1, RMSE 등	사실성, 근거성, 형식 준수, 유용성
강점	반복 예측, 수치 평가, 비용 효율	문맥 이해, 초안 생성, 자연어 인터페이스

개발자가 봐야 할 핵심은 “어떤 모델이 더 최신인가”가 아니다.

정답 라벨이 있고 반복 예측이 필요한가?
문맥을 읽고 새로운 결과물을 생성해야 하는가?
결과를 어떤 기준으로 검증할 것인가?

이 세 질문이 모델 선택의 출발점이다.