AI Assistant 시스템 개요¶
이 챕터에서 배우는 것
- 프로덕션 AI Assistant를 이루는 8개의 블록 — 입력·이해·검색·생성·검증·저장·모니터링·휴먼 핸드오프
- 각 블록이 코드·모델·RAG·외부시스템 중 무엇으로 구현되는지 구분하기
- 자기 프로젝트의 Assistant 아키텍처를 한 장의 다이어그램으로 그리는 연습
1. "Assistant = 프롬프트 하나" 가 아닙니다¶
많은 입문자가 이렇게 생각합니다.
데모나 PoC는 가능. 운영에서는 거의 모든 케이스에서 실패.
실전 Assistant는 여러 블록이 협력합니다. 각 블록은 목적·책임이 다르고, 어떤 건 코드·어떤 건 모델·어떤 건 외부 시스템입니다.
2. 8개의 블록 — 전체 파이프라인¶
선형처럼 보이지만 실제는 분기·순환이 많습니다. 5️⃣ 검증이 실패하면 4️⃣ 생성으로 재시도, 2️⃣ 이해 단계에서 자신 없으면 바로 8️⃣ 휴먼 핸드오프로 이관. 저장된 대화 로그는 모니터링·피드백 루프로 다시 흘러 자기 개선의 연료가 됩니다 (캡스톤에서 다룸).
3. 각 블록 — 무엇이 들어있나¶
1️⃣ 입력 (Intake)¶
| 항목 | 내용 | 구현 |
|---|---|---|
| 메시지 수신 | 텍스트·음성·이미지 | 코드 (API 엔드포인트) |
| 첨부 처리 | PDF·이미지·파일 | 코드 + 파싱 라이브러리 |
| 세션 식별 | 사용자·대화 ID | 코드 (세션 저장소) |
| 레이트 리밋 | 호출 빈도 제한 | 코드 (Redis·미들웨어) |
| 입력 정제 | 길이 제한·인코딩·사전 검증 | 코드 |
핵심: 이 블록은 거의 100% 코드. 여기를 모델로 만들면 안 됨.
2️⃣ 이해 (Understand)¶
| 항목 | 내용 | 구현 |
|---|---|---|
| 의도 분류 | "환불 문의인가 · 정책 질문인가" | LLM (Part 2) |
| 엔티티 추출 | 날짜·주문번호·금액 | LLM 구조화 출력 |
| 언어 감지 | 응답 언어 결정 | 규칙 또는 모델 |
| 민감도 분류 | 차단 키워드·톤 | 규칙 + 모더레이션 API |
핵심: 의도·엔티티는 LLM의 강점. 단, 잘못 분류되면 이후 전부 틀어지니 평가셋(Part 4) 필수.
3️⃣ 검색 (Retrieve)¶
| 항목 | 내용 | 구현 |
|---|---|---|
| 문서 검색 | 매뉴얼·FAQ·정책 | RAG (Part 3) |
| DB 조회 | 사용자·주문·로그 | 코드 + SQL |
| 외부 API 호출 | 날씨·환율·재고 | 코드 (tool calling) |
| 하이브리드 검색 | BM25 + dense | Part 3 |
핵심: 답변 품질의 70%가 여기서 결정됨. 검색 실패는 생성으로 보완 불가.
4️⃣ 생성 (Generate)¶
| 항목 | 내용 | 구현 |
|---|---|---|
| 답변 작성 | 검색 결과 + 질문으로 | LLM |
| 구조화 출력 | JSON·Markdown·카드 | Part 2 구조화 출력 |
| 인용 표기 | "정책 A4의 3.2절에 따르면..." | Part 3 citation |
| 스트리밍 | 토큰 단위 실시간 출력 | Part 2 스트리밍 |
5️⃣ 검증 (Validate) — 가드레일¶
| 항목 | 내용 | 구현 |
|---|---|---|
| 관련성 | 질문과 답변의 연결 | LLM-as-Judge (Part 4) |
| 안전성 | 탈옥·혐오·개인정보 | 모더레이션 + LLM |
| 정책 준수 | 브랜드·규정 | 규칙 + LLM |
| 출력 형식 | 스키마 일치 | 코드 (Pydantic) |
핵심: 7종 가드레일 표 (Part 6 Ch 28) — 반드시 계층형 방어 (한 겹만으로는 부족).
6️⃣ 저장 (Persist)¶
| 항목 | 내용 | 구현 |
|---|---|---|
| 대화 로그 | 질문·답변·메타 | DB + 버전 |
| 사용자 피드백 | 👍👎·코멘트 | DB |
| 프롬프트 버전 | 어느 프롬프트로 생성됐나 | Git + registry |
| 데이터셋 | 실패 케이스 자동 수집 | 파이프라인 |
핵심: 이 블록이 없으면 자기 개선 루프(캡스톤) 가 불가능.
7️⃣ 모니터링 (Observe)¶
| 지표 | 의미 | 도구 |
|---|---|---|
| Latency | p50·p95·p99 응답 시간 | Langfuse·LangSmith·Datadog |
| Cost | 입력·출력 토큰·모델별 | 내부 대시보드 |
| Quality | 좋아요 비율·평가셋 점수 | Part 4 |
| Safety | 가드레일 trip 빈도 | 알람 |
8️⃣ 휴먼 핸드오프 (Escalate)¶
| 트리거 | 액션 |
|---|---|
| 실패 임계치 초과 (N회 재시도 실패) | 사람 담당자에게 이관 |
| 고위험 액션 (환불 · 결제 · 삭제) | 승인 요청 큐 |
| 안전성 경고 | 사전 차단 + 알람 |
| 사용자의 직접 요청 ("상담원 연결") | 즉시 이관 |
핵심: 자율성은 기본값이 아님. 신뢰가 쌓일 때까지 사람이 고리에 있어야.
4. 코드 vs 모델 vs RAG vs 외부시스템 — 라벨링¶
앞의 8 블록을 기술 선택 라벨로 다시 보면:
CODE: 결정론적 로직 · MODEL: LLM 호출 · RAG: 임베딩+벡터검색 · EXT: DB·API·메시징 등
- 코드 — 결정론적이어야 하는 모든 것 (레이트리밋·권한·스키마 검증)
- 모델 — "가능한 표현이 수없이 다양한" 입력을 다룰 때
- RAG — "모델이 학습 못 한 우리 회사 지식"을 붙일 때
- 외부 시스템 — 실제 데이터·액션이 있는 곳 (DB·ERP·Slack)
5. 간단한 예시 — 고객 문의 어시스턴트¶
"환불 관련 문의"를 처리하는 Assistant의 구체 흐름:
사용자: "지난주에 산 이어폰 환불하고 싶은데 어떻게 해요?"
1) 입력 : POST /chat {user: 1234, msg: ...} → 레이트리밋 통과
2) 이해 : 의도 = "환불 요청" · 엔티티 = "이어폰", "지난주"
3) 검색 : RAG → 환불 정책 문서 · DB → 사용자 1234의 최근 주문
4) 생성 : "주문번호 X는 7일 이내이므로 환불 가능합니다..." + 절차 설명
5) 검증 : 개인정보 필터 통과 · 금액은 정책 상한 내
6) 저장 : 대화 ID 저장 · 피드백 대기 상태
7) 모니터링 : latency 1.8s · 토큰 1200 · cost $0.003 기록
8) 핸드오프 : 고객이 "상담원" 요청 시 즉시 이관 준비
이 흐름에서 어느 한 블록이 빠져도 운영 시스템이 아닙니다.
6. 실전 튜토리얼 — 자기 Assistant 구조도 그리기¶
지금 만들고 싶은 Assistant 하나를 정하고, 아래 순서로 1장짜리 설계도를 그립니다.
단계 1. 유즈케이스 정의¶
- 이름: ___
- 사용자: ___
- 입력 예시 3개
- 기대 출력 예시 3개
단계 2. 8개 블록 중 사용할 것 선택¶
처음엔 입력·이해·생성·저장 넷만으로도 시작 가능. 그 외 블록은 필요할 때 추가.
단계 3. 각 블록에 라벨 붙이기¶
CODE · MODEL · RAG · EXT 중 무엇으로 구현할지 명시.
단계 4. 다이어그램으로 그리기¶
노트·화이트보드에 손으로 박스·화살표로 그려보세요. 최소 형태:
혹은 Figma·Excalidraw·draw.io 등 좋아하는 도구로. 중요한 건 한 장에 담기.
단계 5. 실패 시나리오 10개 쓰기¶
각 블록이 실패했을 때 어떻게 될지. 예: - 이해 블록이 의도를 잘못 분류하면? → 엉뚱한 검색 → 관련 없는 답변 - 검색이 빈 결과를 반환하면? → "죄송합니다" 가 아니라 "정보를 찾을 수 없어 사람 담당자에게 연결"
이 10개 실패가 평가셋의 출발점입니다 (Part 4).
7. 자주 깨지는 포인트¶
실수 1. 8블록을 전부 LLM 한 번에 하게 만들기
"LLM이 똑똑하니까 다 알아서 할 거야" — 하지 않습니다. 블록마다 책임을 쪼개야 디버깅도 평가도 가능.
실수 2. 검증(가드레일) 블록을 나중으로 미룸
"일단 돌아가는 것부터 만들고 나중에 가드레일 붙이자" — 이 순간 기술 부채 시작. 검증이 없는 PoC를 사용자에게 보여주면 되돌릴 수 없는 신뢰 손실.
실수 3. 저장 블록이 없어서 피드백 버림
"일단 대답만 잘하면 돼" — 사용자 피드백·실패 로그를 안 저장하면 개선 데이터가 없음. Part 4·캡스톤이 불가능.
실수 4. 휴먼 핸드오프 경로를 설계 안 함
"AI니까 사람 안 필요해" — 고위험·예외 케이스는 반드시 사람에게 갈 길이 필요. 없으면 안전사고의 소지.
8. 운영 시 체크할 점¶
- 8블록 각각에 담당자가 지정되어 있는가 (팀 관점)
- 각 블록의 SLO (목표 지연·정확도·비용) 가 문서화되어 있는가
- 한 블록 장애 시 다른 블록이 계속 동작하는가 (circuit breaker)
- 핸드오프 경로가 실제로 테스트되었는가
- 저장된 로그가 개인정보 정책을 지키는가
9. 확인 문제¶
- 지금 만들고 싶은 Assistant를 8블록 다이어그램으로 1장 그리기
- 그 중 "없어도 되는 블록" 과 "반드시 있어야 하는 블록" 을 구분하고 이유 한 줄씩
- 각 블록에
CODE / MODEL / RAG / EXT라벨 붙이기 - 실패 시나리오 10개 와 그 때 어느 블록이 책임지는지 매핑
- 휴먼 핸드오프 경로를 한 문단으로 설계 (언제·누구에게·어떻게)
10. Part 1을 마치며¶
지금까지 배운 것:
| Ch | 배운 것 | 다음 Part에서 |
|---|---|---|
| 1 | 모델이 필요한 문제 판별 | 전체 모든 챕터 |
| 2 | LLM이 어떻게 "생각"하는가 | Part 2에서 API로 실전 |
| 3 | Assistant의 8블록 구조 | Part 2~7이 각 블록을 깊이 |
Part 2부터는 코드로 손을 댑니다. 첫 LLM 호출부터 시작해, 구조화 출력·툴 콜링·스트리밍까지.