목차18개 항목
출처와 참고
web.dev의 「Learn AI」 강좌 중 예측형 AI·생성형 AI 모듈을 바탕으로 재구성한 노트다.
두 방식의 차이
예측형 AI(predictive, analytical AI)는 기존 데이터를 이해하고 다음에 일어날 일을 예측한다. 생성형 AI(generative AI)는 텍스트·이미지·코드·UI처럼 새로운 것을 만든다.
수학적으로는 멀지 않다. 둘 다 데이터에서 패턴을 배우고, 생성형 모델도 "다음 단어(픽셀, 음표)"를 예측한다. 차이는 규모와 출력 공간이다. 예측형의 출력은 "이탈/유지" 같은 몇 개의 라벨이고, 생성형의 출력은 수십만 개 선택지의 조합이다. 수십억 개 예시로 학습하면 예측 장치가 처음 보는 출력을 만드는 엔진이 된다. 원리는 LLM은 무엇을 하고 왜 작동하나에 있다.
| 항목 | 예측형 AI | 생성형 AI |
|---|---|---|
| 출력 | 라벨·숫자·순위 (좁고 닫힘) | 텍스트·이미지·코드 (사실상 무한) |
| 모델 | 대개 직접 학습한 작은 모델 | 사전 학습된 큰 기반 모델을 고쳐 씀 |
| 맞춤 방법 | 데이터·특징·하이퍼파라미터 | 프롬프트·컨텍스트·파라미터, 필요하면 파인튜닝 |
| 정답 | 라벨이 정답(ground truth) | 정답이 하나가 아니다 |
| 평가 | 정밀도·재현율·F1 | 정확성·유용성·어조·수정량 등 직접 정의 |
| 위험 면적 | 오분류 | 환각·유해 콘텐츠·조작·과신 |
| 잘 맞는 곳 | 측정 가능하고 잘 정의된 문제 | 정밀함보다 창의성·적응력이 중요한 곳 |
대표 과제
| 예측형 | 예 |
|---|---|
| 분류 | 방문자를 조사·구매·반품 의도로 나눈다 |
| 회귀 | 참여율, 세션 시간, 전환 확률 |
| 추천 | "비슷한 사용자가 본 상품" |
| 예측·이상 탐지 | 트래픽 급증 예측, 결제 사기 탐지 |
| 생성형 | 예 |
|---|---|
| 콘텐츠 작성 | 초안 작성, 문장 다듬기 |
| 요약 | 긴 문서·회의·웹 페이지를 짧게 |
| 코드 생성 | 작성·리팩터링 |
| 이미지·에셋 | 배너, 썸네일 |
예측형 AI는 제품 전체가 되기도 하고(음악 발견 서비스), 결정적 경험을 거들기도 하고(스트리밍 추천), 제품·사용자 데이터를 분석하는 내부 도구가 되기도 한다.
예측형 AI 루프
flowchart LR U["유스케이스 정의"] --> D["데이터 준비"] D --> L["학습"] L --> E["평가"] E --> M["배포·유지"] M -->|"다시 정의"| U
구독형 생산성 앱의 이탈 예측을 예로 든다.
1. 유스케이스 정의
먼저 데이터로 답할 수 있는 질문인지 확인한다. 고객 성공·그로스 팀 같은 도메인 전문가와 함께 정한다.
| 항목 | 이탈 예측의 값 |
|---|---|
| 목표 | 선제 연락으로 이탈을 줄인다 |
| 입력 | 사용 패턴, 요금제, 문의 이력 |
| 출력 | 사용자별 이탈 확률 |
| 사용자 | 고객 성공 매니저 |
| 성공 기준 | 유지율 |
이걸 처음에 정해 두면 "기술적으로는 훌륭한데 아무도 안 쓰는 모델"을 피한다.
2. 데이터 준비
- 과거 데이터에 정답 라벨(
churned0/1)을 붙인다. - 자동 수집 데이터는 잡음이 적다. CRM처럼 사람이 입력한 데이터는 빈칸·표기 불일치·오타가 많아 정제·정규화가 먼저다.
- 도메인 팀과 관련 특징만 고르고 나머지는 버린다. 이름·이메일 같은 개인 식별 정보는 지우고 집계된 행동만 남긴다.
- 범주형 값은 숫자 ID로 바꾼다.
- 학습(보통 70~80%) / 검증(하이퍼파라미터 조정, 과적합 방지) / 테스트(처음 보는 데이터로 최종 평가)로 나눈다.
user_id | plan_type | avg_session_time | logins_last_30d | features_used | support_tickets | churned
00124 | trial | 5.8 | 3 | 1 | 2 | 13. 학습
예측 과제는 제품과 사용자에 특화되어 있어 직접 학습이 기본이다. scikit-learn(파이썬), AutoML(노코드), TensorFlow.js(자바스크립트)가 수학을 감춰 준다. 이탈 예측은 로지스틱 회귀나 신경망 같은 지도 학습 분류기로 풀고, 여러 알고리즘을 시험해 데이터에 맞는 것을 고른다. 성능은 하이퍼파라미터뿐 아니라 데이터셋을 겨냥해 고쳐서도 오른다. 학습의 뼈대는 머신 러닝 기초에 있다.
4. 평가
라벨이 정답이므로 정밀도·재현율·F1로 잰다(정의는 분류 모델 성능 평가 지표). 거짓 양성이 많으면 유지 활동이 낭비되고, 거짓 음성이 많으면 고객을 잃는다. 어느 쪽을 더 참을지는 비즈니스가 정한다.
5. 배포와 유지 (MLOps)
API나 대시보드에 붙는 가벼운 클라이언트 서비스로 배포하고, 매일 점수를 갱신한다.
| 습관 | 예 |
|---|---|
| 데이터 드리프트 감시 | UI 개편 뒤 사용 패턴이 바뀌어 예측이 틀어진다 |
| 오답에서 배우기 | 문의를 많이 하는 파워 유저를 이탈로 오판 → "문제 해결"과 "이탈 징후"를 가르는 특징 추가 |
| 정기 재학습 | 연간 요금제 도입처럼 가격 구조가 바뀌면 재학습 |
MLflow, Weights & Biases 같은 도구로 모델 버전·정확도·사용 도구를 기록하고 성능을 계속 추적한다.
생성형 AI 루프
flowchart LR U["유스케이스 정의"] --> F["기반 모델 선택"] F --> P["프롬프트·컨텍스트"] P --> I["추론·후처리"] I --> E["평가·피드백"] E --> R["(반복)"]
블로그 CMS의 제목·소개문 생성 도우미를 예로 든다.
1. 유스케이스 정의
입력·출력 모달리티(텍스트·이미지·오디오), 입력 방식(업로드, 자유 입력, 반구조 입력), 사용자의 전문성을 적고, 품질 기준(짧고, 훑어 읽기 좋고, 키워드가 들어가고, 매체 어조에 맞는)을 정한다.
2. 기반 모델 선택
생성형 모델은 크고 복잡해서 직접 만들지 않고 사전 학습 모델 위에 짓는다. 모델 선택은 기능·비용·맞춤 가능성·프라이버시 경계를 정하고, 어느 플랫폼에서 돌릴지와 맞물린다(웹 AI 플랫폼 고르기).
3. 프롬프트와 컨텍스트 엔지니어링
프롬프트에는 전체 행동을 정하는 시스템 프롬프트, 이번 작업의 입력 컨텍스트, 대화형이면 사용자 지시가 들어간다. 컨텍스트 엔지니어링(context engineering)은 요청마다 가장 관련 있는 정보(토큰)를 골라 넣어 좋은 결과가 나올 확률을 높이는 일이다. 구성 요소와 기법은 프롬프트 작성법 치트시트와 시스템 프롬프트 설계 패턴에 있다.
4. 추론과 후처리
온도(창의성)와 최대 토큰 수(길이) 같은 파라미터로 응답을 조절한다. 생성 뒤에는 규칙과 가드레일로 다듬는다. 성별 편향 표현 바꾸기, 어조 조절, 금칙어 걸러 내기 같은 것이다. 작은 보조 모델로 결과를 분류·요약해 "관련 글 12편으로 작성. 신뢰도: 높음" 같은 표시를 붙이면 사용자가 신뢰를 조절할 수 있다.
5. 평가와 피드백
정답이 하나가 아니므로 MMLU 같은 공개 벤치마크는 일반 능력만 보여 준다. 제품에서는 정확성, 유용성, 가독성·어조, 사람의 수정량, 도메인 이해를 직접 정하고, 사용자 평점·LLM 심판(LLM-as-a-judge)·정기 내부 검토를 섞는다. 이 과정은 평가 주도 개발에서 자세히 다룬다.
실사용 로그는 다음 개선 방향을 알려 준다.
| 신호 | 뜻 |
|---|---|
| 예상 밖 입력 | 엉뚱한 문제를 풀고 있는지 의심한다 |
| 반복되는 도메인 요청 | 큰 범용 LLM에서 작은 파인튜닝 모델로 바꿀 근거 |
| 잦은 환각 | 프롬프트에 구체적 컨텍스트가 부족하다 |
| 많은 수정 | 사용자는 당연히 아는 정보를 모델이 모른다 |
흔한 함정과 대응
예측형
| 함정 | 대응 |
|---|---|
| 저품질 데이터 | 학습 전에 시각화·검증, 결측치 처리, 운영 중 품질 감시 |
| 과적합 | 교차 검증, 정규화, 홀드아웃 데이터 |
| 데이터 드리프트 | 재학습 일정, 정확도 하락 감시 |
| 잘못된 지표 | 실수의 비용을 반영한다. 사기 탐지에서는 놓치는 것(거짓 음성)이 오탐보다 훨씬 비싸다 |
대부분 치명적이지 않다. 점진적으로 출시하고, 모델 버전·정확도·성능 추이를 기록하는 관측 가능성(observability)으로 사용자가 알아채기 전에 잡는다.
생성형
열린 입력과 출력 때문에 위험 면적이 훨씬 넓다. 틀린 답을 넘어 유해·편향·오도하는 콘텐츠를 만들거나 의도치 않게 사용자를 조작할 수 있어, 지속적인 위험 관리가 필요하다.
| 함정 | 대응 |
|---|---|
| 환각 | RAG(검색 증강 생성)로 사실 근거를 붙인다 |
| 과신 | 자동 게시 대신 검토·수정 흐름 |
| 들쭉날쭉한 출력 | 프롬프트 템플릿, 온도 조절, 퓨샷 예시 |
| 유해 콘텐츠 | 표시 전 모더레이션 필터·독성 분류기, 실제 프롬프트로 계속 시험 |
| 지연과 비용 | 캐싱, 배치, 짧은 작업엔 작은 모델 |
정리
- 예측형은 데이터로 표현되는 잘 정의된 문제에, 생성형은 창의성·적응력이 정밀함보다 중요한 곳에 쓴다.
- 예측형은 직접 학습하고 라벨로 평가한다. 생성형은 기반 모델 위에 프롬프트·컨텍스트를 얹고 평가 기준을 직접 만든다.
- 두 루프 모두 출시가 끝이 아니다. 드리프트 감시, 로그 기반 개선, 재학습·프롬프트 수정으로 계속 돈다.
관련 노트: AI 기능 기획, 분류 모델 성능 평가 지표, 머신 러닝 기초, LLM은 무엇을 하고 왜 작동하나, 평가 주도 개발