요즘 AI를 붙인 제품은 많습니다. 그런데 “대화는 그럴듯한데, 실제로 일은 안 끝나는” 경우도 흔합니다. 반대로 “일은 끝나는데, 사고 나면 누가 책임지지?”라는 질문도 따라옵니다.
이 둘을 동시에 만족시키는 구조가 점점 표준처럼 자리 잡는 분위기입니다.
보편 패턴: 대화(Assistant) → 실행(Agent) → 승인(Gate/Confirm)
제가 보는 가장 보편적인 구조는 이렇습니다.
- Assistant(대화 흐름): 사용자의 의도/맥락/제약을 정리해서 “무엇을 할지”를 확정합니다.
- Agent(실행 흐름): 툴 호출, 워크플로우 오케스트레이션, 재시도/오류 처리로 “어떻게 끝낼지”를 수행합니다.
- Gate(승인/정책): 돈·권한·대외 발신·개인정보·운영 변경 같은 고위험 구간에서 Confirm(확인 창) 또는 승인 단계를 둡니다.
겉으로는 “대화형 어시스턴트”인데, 속으로는 “업무 실행 엔진(에이전트)”이 돌고, 중요한 순간에는 “사람의 도장(게이트)”이 찍히는 구조입니다.
왜 이 조합이 강한가
- UX: 사람은 말로 목표를 던지는 게 쉽고, 시스템은 워크플로우로 실행하는 게 안전합니다.
- 운영: 재시도/분기/예외 처리를 대화로만 풀면 길어지기 쉽고, 품질 관리가 어려워집니다.
- 조직: 사고 비용이 큰 순간에는 “승인 로그”가 있어야 살아남습니다. (AI가 아니라 사람이요)
단점도 분명합니다
- 게이트가 많아지면 자동화 체감이 떨어집니다. “AI가 해준다”가 아니라 “AI가 물어본다”가 됩니다.
- 게이트가 없으면 언젠가 한 번 터질 확률이 높습니다. 그리고 그 ‘한 번’은 보통 제일 바쁠 때 옵니다. (법칙입니다)
(사례) 실제 구축한 하이브리드 챗봇
제가 운영한 하이브리드 챗봇은 한 줄로 말하면 이런 형태였습니다.
CS 실시간 처리(정형) + AI 게임 가이드(비정형) 를 한 경험 안에서 연결한 구조
그리고 이 구조를 굴리면서 “대화–실행–승인”을 분리해 설계하는 것이 운영 안정성과 확장성에 꽤 크게 기여했습니다.
- 2025년 기준, 연간 약 55만 명 이상 사용
- CS 티켓 중 챗봇 자동 처리율 약 41%
- 응답 품질: Good 87% 이상, 속도: p50 1초 미만(대략)
– (참고) ‘Good’은 내부 기준의 Human Evaluation 라벨 기반 지표로 응답 일치를 뜻함
1) Assistant(대화) — “질문을 실행 가능한 형태로 압축”
유저는 보통 이렇게 들어옵니다.
- “결제했는데 아이템이 안 들어왔어요.”
- “퀘스트가 막혔어요. 어디로 가야 해요?”
- “접속이 안 돼요. 보안 문제 같아요.”
Assistant는 여기서 정답을 장황하게 설명하기보다, 실행에 필요한 최소 정보만 수집합니다.
- 결제/지급: 서버/캐릭터/대략 시간/상품명
- 진행 막힘: 현재 퀘스트 단계/지역/진행 맥락
- 보안: 로그인 방식/오류 메시지/최근 접속 변화
핵심은 하나입니다.
질문을 길게 받지 말고, 실행 가능한 형태로 “압축”해서 넘기기
(사용자는 상담원이 아니라 플레이어니까요.)
2) Agent(실행) — “툴과 룰로 일을 끝내기”
Agent는 그 다음을 담당합니다.
- 로그/상태 조회(결제·지급·계정 등)
- 정책/조건 매칭(가능/불가/예외)
- 자동 처리(가능하면 즉시 해결)
- 자동 티켓 생성(불가하거나 예외면 담당자에게 넘김)
- 결과 메시지/ETA 생성(유저에게 안내)
여기서 중요한 포인트는 “LLM이 알아서 다 한다”가 아니라,
LLM은 의도 파악·요약·정책/문서 탐색에 강하고,
실제 실행은 결국 워크플로우(툴/룰/권한)로 굴러가야 안정적인 점 입니다.
3) Gate(승인) — “통제”가 아니라 “신뢰(Trust) 장치”
사례에서도 Gate는 빠질 수 없습니다. 다만 Gate를 “승인 단계”라고만 보면 흔한 이야기입니다. 현장에서 더 중요한 관점은 Gate가 신뢰를 만드는 장치라는 점입니다.
- Transparency(투명성): “왜 이 선택을 했는지”를 짧게 보여주기
- 근거/정책 매칭 결과, 영향 범위(대상·수량·금액), 대안(있다면)
- Safety(안전): 고위험 액션은 Confirm(확인 창)과 승인 정책으로 제한하기
- 2FA/2인 승인/쿨다운/롤백(Undo) 같은 제어 장치 포함
- Transparency(투명성): “왜 이 선택을 했는지”를 짧게 보여주기
장문의 설명은 읽히지 않습니다. 3줄 요약이 더 강합니다.
Gate 정책 + Confirm UX
위 원칙을 실제 제품에서 굴리려면, 결국 “정책(레벨)”과 “화면(Confirm)”이 필요합니다.
아래는 하이브리드 챗봇에서 바로 쓰기 좋은 실무형 템플릿입니다.
1) 리스크 레벨(정책)
- Low: 자동 실행 + 로그 기록 + 결과만 안내
- 예: 가이드/FAQ 응답, 경량 조회, 문서 요약
- Mid: 실행 요약 제시 → 1회 Confirm → 실행
- 예: 티켓 생성, 소액/소량 보상 발급, 되돌리기 가능한 설정 변경
- High: 2FA/2인 승인(필요 시) + 영향 범위 표시 + 롤백/Undo 강제
- 예: 환불, 대량 지급, 계정 제재/복구, 개인정보 내보내기, 프로덕션 설정 변경
- Low: 자동 실행 + 로그 기록 + 결과만 안내
한 줄 원칙: 되돌릴 수 있으면 자동화, 되돌릴 수 없으면 Gate 강화
2) Confirm(확인 창)에는 3가지만 넣기
Confirm 화면에서 가장 흔한 실패는 “설명 장문”입니다. 아래 3가지만 있으면 됩니다.
- 무엇이 바뀌나(변경 요약 1~2줄)
- 영향 범위(대상/수량·금액/리스크 포인트)
- 되돌리기/복구(가능 여부 + 방법)
3) 컨펌 문구 템플릿(대표 1개)
- “아래 작업을 실행합니다. 대상: {대상} / 변화: {변경} / 영향: {범위} / 되돌리기: {가능/불가}. 진행할까요?”
예상되는 대표 워크플로우 4가지
“Assistant → Agent → Gate”가 보편 패턴이라면, 실제 제품에서는 아래 변형들이 함께 공존할 가능성이 큽니다(= 패턴 카탈로그). 여기서 중요한 건, 각 패턴은 장점만큼 비용(지연/운영 복잡도/비용)도 동반한다는 점입니다.
1) Auto + Undo 패턴 (저위험·고빈도)
자동 실행 → 되돌리기(Undo) 제공
- 장점: 마찰이 적고 “AI가 일한다” 체감이 큽니다.
- 단점: Undo가 설계/권한/로그까지 포함해 안전하지 않으면 “자동화”가 아니라 “자동사고”가 됩니다.
2) Plan-First 패턴 (실행 전 계획 제출)
계획 제출 → 승인 → 실행
- 예: 대량 발송, 운영정책 변경, 이벤트성 보상 배포
- 장점: 승인자가 “무엇을 할지”를 이해하고 책임질 수 있습니다.
- 단점: 계획서가 길어지면 아무도 안 읽습니다.
- 현실적으로는 3줄 요약 + 영향 범위 + 롤백이 가장 효율적입니다.
3) Agent-in-the-Loop 패턴 (부분 자동화)
중요 단계만 사람 참여(예외 처리/최종 결정)
- 예: 가능한 옵션은 자동 제시, 최종 보상안/예외 승인은 상담원이 선택
- 장점: 생산성과 품질을 동시에 노릴 수 있습니다.
- 단점: 역할 경계가 애매하면 “AI도 사람도 서로 떠넘기는 상태”가 됩니다. (가장 흔한 실패)
4) Multi-Agent 패턴 (분업형 협업)
리서치/실행/검수/감사를 에이전트로 분리
- 장점: 복잡한 업무에서 안정성이 올라갑니다.
- 단점: 비용과 지연이 증가합니다. 에이전트끼리 회의하다가 퇴근할 수 있습니다. (사람이 아니라 에이전트가요)
정리: AI 제품은 ‘말 잘하는 챗봇’이 아니라 ‘업무 시스템’이 됩니다
앞으로는 “AI가 답변을 잘한다”보다,
“AI가 업무를 끝내고, 그 과정이 통제 가능한가?”가 더 중요해질 것입니다.
그래서 저는 워크플로우를 이렇게 정리합니다.
대화(Assistant) → 실행(Agent) → 승인(Gate/Confirm)
그리고 상황에 따라 Auto+Undo, Plan-First, Agent-in-the-Loop, Multi-Agent 같은 변형 패턴이 공존합니다. 결국 차이를 만드는 건, Gate를 통해 신뢰를 설계할 수 있느냐입니다.
