AI 연재 9/9 — 한 건의 보상 신청을 끝까지: 상태 머신으로 엮는 종합 설계
마지막 편이다. 이번 글은 새 사실을 소개하기보다 지금까지의 조각을 하나로 엮는다. 그래서 대부분이 내 설계 제안이다. 출처가 있는 부분은 따로 표시하고, 나머지는 "이렇게 설계해 볼 수 있다"로 읽어 주면 좋겠다. 가상의 일반화된 시나리오이고 실제 서비스의 구현이 아니다. 운영해 본 적 없는 설계라서 틀린 부분이 있을 수 있다.
전체 그림
고객이 채팅으로 보상 신청을 시작하고, 서류를 올리고, AI가 1차 판단을 하고, 사람이 검토하고, 결과를 안내받는다. 이 흐름을 서버의 상태 머신으로 둔다.
수집중 → 서류검증 → 자동판단 → 검토대기 → 승인 / 반려 → 안내완료
↑___________| (서류 부족 시 수집중으로 복귀)원칙은 하나다. LLM은 전이를 제안하고, 전이를 허용할지는 코드가 결정한다. 상태를 LLM 출력으로 추정하면(예: 대화 내용을 보고 지금 어디쯤인지 짐작) 새로고침 한 번에 진행 상황이 사라진다. 서버가 상태의 원본을 갖고, UI는 그 뷰다. 8편에서 본 OpenAI 문서의 권고(권위 있는 데이터는 서버)와 같은 맥락이다.
단계별로 어디에 무엇을 쓰나
수집중. 7편의 결론대로 입력은 구조화된 위젯이다. 서류 체크리스트 카드로 진행률을 보여 주고, 업로드와 추출값 확인 카드를 둔다. 자유 텍스트는 예외 설명에만 쓴다. 이 단계의 도구 호출 결과가 곧 8편의 컴포넌트 매핑이다.
서류검증. 1편의 파이프라인이다. 추출, 필드 검증 게이트, 필수 서류 확인. 대부분 코드가 판단하고 LLM은 추출에만 쓴다. 모델이 읽은 금액은 사용자가 확인 카드로 확정한다(7편의 오류 복구 원칙).
자동판단. 약관과 기준 문서를 5편의 RAG로 검색하고, 1편의 구조화 출력으로 decision, reasons, evidence_refs를 받는다. 3편의 신뢰 신호(규칙 검증, 반복 실행 일치도)로 구간을 나눈다. 여기서 에이전트가 필요한가? 4편의 기준대로라면 대부분 워크플로우로 충분하다. 에이전트는 "서류가 모호해서 무엇을 추가로 물어볼지 판단하는" 정도의 좁은 구간에만 쓴다고 본다.
검토대기. 사람 검토는 interrupt 구조로 모델링한다. 6편에서 본 LangGraph의 interrupt와 Command(resume=...), 8편의 AG-UI interrupt가 같은 구조다. 중요한 점은 검토자가 몇 시간 뒤에 응답해도 되도록 상태가 영속 저장돼야 한다는 것이다. 인메모리 체크포인터로는 안 된다. 그리고 interrupt 앞의 코드가 재개 시 다시 실행되는 점 때문에 알림 발송 같은 부수 효과는 멱등 키(1편)로 보호한다.
승인/반려와 안내. 고객에게 보이는 카드는 결정, 근거, 다음 단계를 구조화해서 보여 준다. 설명 문장은 LLM이 쓰되 금액과 날짜는 서버 데이터로 채운다. 불확실성을 숨기지 않는다는 NN/g의 권고(7편)에 맞춰, 자동 판단이 확정이 아니라 검토 대기 중이라는 점도 명확히 알린다.
접근성과 비채팅 경로
- 상태 변화는
role="status", 오류는role="alert"로 알린다(WCAG 2.2 SC 4.1.3, 레벨 AA). 확인한 근거는 W3C 문서다 - 동적으로 삽입되는 컴포넌트가 포커스를 가로채지 않게 한다. 반대로 승인 다이얼로그처럼 맥락이 바뀔 때는 포커스를 의도적으로 옮긴다
- 토큰 스트리밍 전체를 스크린리더가 읽게 하지 말고 완료 시점이나 요약만 알린다. 이 부분은 실측하지 않은 내 판단이다
- 채팅이 막히면 일반 폼이나 상담원으로 빠지는 길을 항상 둔다
평가와 감사는 처음부터
이 설계에서 가장 값비싼 실수는 평가와 로그를 나중에 붙이는 것이다. 단계마다 중간 산출물을 저장하고, 상태 전이마다 입력, 모델 출력, 프롬프트·모델·스키마 버전, 사람의 개입을 기록한다(3편). 단계별로 평가셋을 두고(2편), RAG는 검색과 생성을 분리해 평가한다(5편). 사람이 AI를 번복한 사례는 평가셋으로 들어간다.
| 편 | 이 시나리오에서의 역할 |
|---|---|
| 1 | 단계 분해, 구조화 출력, 재시도·멱등 |
| 2 | 평가셋, 판정자 보정, 트레이싱 |
| 3 | 임계값, 사람 검토, 감사 로그 |
| 4~6 | 워크플로우 중심, 좁은 에이전트, RAG, 보안 |
| 7~8 | 하이브리드 UX, 서버 주도 동적 UI |
아직 풀리지 않은 것들
연재를 마치며 솔직하게 남는 질문들을 적는다.
- LLM의 확신 신호를 어떻게 믿을 만하게 만들 것인가. 형식이 정리된 과제에서는 잘 보정된다는 연구가 있지만(3편), 자유 형식 대화에서는 확인하지 못했다
- 사람 검토의 자동화 편향을 설계로 얼마나 줄일 수 있는가. 규제 문서는 문제를 지적하지만 해법은 현장이 찾아야 한다
- 동적 UI 프로토콜 중 무엇에 걸어야 하는가. 대부분 아직 0.x이거나 막 안정화된 단계다
- MCP 2026-07-28 개정에 각 SDK가 얼마나 빨리 맞출지는 모른다
이 연재에서 가장 마음에 남은 문장은 "필요에 맞는 올바른 시스템"이다. 화려한 에이전트나 최신 프로토콜보다, 어디서 틀릴 수 있고 그때 누가 알아채는지를 설계에 넣는 쪽이 더 오래 간다고 생각한다. 이건 이 연재를 쓰며 굳어진 내 의견이다.
글에서 인용한 수치와 날짜는 작성일(2026-10-04)에 공식 문서와 저장소를 열어 확인한 것이다. 다만 일부는 요약 도구를 거쳤으니, 실제로 쓰기 전에는 원문을 한 번 더 확인해 주길 바란다.
보강 글: "보상"이라는 말이 가리킬 수 있는 여러 관점을 따로 정리했다. 관점 지도부터 보면 된다.
연재 목차: 1편 · 2편 · 3편 · 4편 · 5편 · 6편 · 7편 · 8편 · 9편(현재)
참고자료
- Anthropic, Building effective agents (2024-12)
- LangChain 문서, Interrupts
- W3C, Understanding SC 4.1.3: Status Messages
- Nielsen Norman Group, AI Hallucinations: What Designers Need to Know (2025-02)