파레토 8:2 — 반복 실행의 80%를 봇이 걷어낸다
고객지원 문의를 유형별로 세어 보면 종류는 수십 가지지만, 실제 들어오는 건수는 소수 유형에 몰립니다. 계정 식별자 조회, 로그인·이메일 변경, 단순 상태 확인 같은 정형 문의가 전체 건수의 대부분을 차지합니다. 유형의 수로는 20%에 불과한데, 업무량으로는 80%를 먹는 전형적인 파레토 법칙 8:2 구조입니다.
이 20%의 유형은 답이 이미 정해져 있고, 운영 DB를 한 번 조회하면 끝나는 일입니다. 사람이 매번 반복할 이유가 없으면서, 정작 사람의 시간을 가장 많이 빼앗는 업무이기도 합니다. 그래서 자동화의 첫 대상은 여기입니다. AI CS 봇은 이 반복 실행의 80%를 걷어냅니다.
여기서 유형과 건수를 구분하는 게 중요합니다. 유형이 많다고 자동화가 어려운 게 아니라, 건수가 몰리는 소수 유형만 넘겨도 사람의 부하는 크게 줄기 때문입니다. 그래서 자동화 대상을 고를 때는 '가장 어려운 문의'가 아니라 '가장 자주 반복되는, 답이 정해진 문의'부터 봅니다.
CS 봇은 반복 문의를 어떻게 처리하나
약국 소프트웨어 회사의 고객지원에서 이 구조를 돌려 봤습니다. 담당자가 사내 메신저 채널에서 봇을 부르면, 봇이 운영 DB를 조회해 답을 근거와 함께 회신합니다. 예를 들어 특정 약국의 계정 아이디를 물으면 조회해서 알려 주고, 가입 이메일 변경 요청이 오면 계정을 식별해 변경 가능 여부를 확인한 뒤 절차를 안내하거나 직접 처리합니다.
핵심은 두 가지입니다. 첫째, 민감한 변경은 사람 확인을 거치되 단순 조회·안내는 자동으로 끝냅니다. 둘째, 모든 답변에 조회한 근거를 함께 표기해 환각을 통제합니다. 봇이 똑똑해서가 아니라, 참조하는 데이터가 정확하고 근거가 붙어 있어서 믿고 쓸 수 있는 것입니다.
실제 화면을 보면 흐름이 분명합니다. 상담원이 봇을 멘션해 약국 계정을 묻고, 봇은 운영 DB에서 필독 아이디를 찾아 근거와 함께 답합니다. 가입 이메일이 바뀌어야 하는 요청에서는 계정을 식별하고, 사업자번호·약국명으로 대상을 좁혀 정확한 계정을 찾은 뒤 변경을 시도하고 결과를 재확인합니다. 사람이 하던 조회·대조·확인 단계를 봇이 순서대로 밟는 셈입니다.
다음 단계 — AI가 신규 서비스를 스스로 기획·개발한다
반복 실행을 걷어낸 다음은 기획과 개발입니다. 도메인 커뮤니티에 올라오는 글을 모니터링해 매주 AI가 분석하고, 무엇이 이슈이고 어떤 미충족 수요가 반복되는지 브리핑으로 정리합니다. 여기서 멈추지 않고, 반복되는 수요를 신규 서비스나 기능으로 자동 기획해 JIRA에 이슈로 등록합니다.
그다음은 개발입니다. 사람이 Go로 판정한 이슈에 대해 AI가 자동으로 개발하고 E2E 테스트까지 수행합니다. 즉 '무엇을 만들지'의 발굴·기획과 '어떻게 만들지'의 구현·검증이 모두 기계 쪽으로 넘어갑니다. 현재 SH Consulting에서 구축 중인 구조입니다.
브리핑은 단순 요약이 아닙니다. 반복되는 불만과 우회 요청을 모아 '기회' 항목으로 뽑아내고, 같은 수요가 일정 빈도를 넘으면 그것을 새 기능·서비스 후보로 승격합니다. 시장 조사를 새로 돌리는 대신, 이미 커뮤니티에 쌓인 목소리를 제품 백로그의 입력으로 바로 연결하는 것입니다.
사람은 두 곳에서만 판단한다 — HITL
이 파이프라인에서 사람이 개입하는 지점은 딱 두 곳입니다. 첫째는 2주 단위 스프린트 회의에서의 Go/Stop 결정입니다. AI가 등록한 기획 이슈 중 무엇을 실제로 만들지를 사람이 고릅니다. 둘째는 개발이 끝난 뒤의 기능 테스트입니다. E2E까지 통과한 결과물을 사람이 마지막으로 검수해 내보낼지를 판단합니다.
두 지점은 우연이 아닙니다. 방향을 정하는 일(무엇을 만들지)과 출시 품질에 책임을 지는 일(내보낼지)은 사람이 져야 하는 판단입니다. 그 사이의 반복 노동—모니터링, 분석, 기획서 작성, 코딩, 테스트 작성—은 기계가 맡습니다. 이것이 HITL(Human In The Loop)의 설계 원칙입니다.
두 게이트의 성격은 다릅니다. 앞의 Go/Stop은 '무엇을 만들 가치가 있는가'라는 방향의 판단이고, 뒤의 기능 테스트는 '이대로 사용자에게 내보내도 되는가'라는 품질과 책임의 판단입니다. 하나는 진입을 거르고, 하나는 출구를 지킵니다. 그 사이의 실행은 전부 기계 몫입니다.
왜 완전 자동이 아니라 HITL인가
완전 자동화의 위험은 잘못된 방향을 빠르고 대량으로 만들어 낸다는 점입니다. 방향 판단과 출시 결정을 기계에 넘기면, 틀렸을 때 되돌릴 비용이 커집니다. 사람 게이트 두 개가 바로 그 리스크를 흡수합니다. AI가 나쁜 아이디어를 스스로 죽이는 게 아니라, 사람이 Go/Stop으로 선별하는 것입니다.
실행(CS 봇)에서 기획·개발(자율 파이프라인)까지 AI에게 넘길수록, 사람의 일은 두 판단 지점으로 수렴합니다. AX가 가리키는 곳은 사람을 파이프라인에서 밀어내는 것이 아니라, 반복에서 해방된 사람을 판단해야 하는 자리에 정확히 남기는 것입니다.
이 구조는 결국 사람의 역할을 바꾸는 일입니다. 반복 실행에서 손을 떼는 대신, 무엇을 만들지 정하고 나온 결과를 책임지는 판단에 시간을 씁니다. AX의 목표가 사람을 대체하는 게 아니라 조직이 스스로 진화하도록 만드는 것이라면, HITL은 그 목표를 자동화 파이프라인 안에 구조로 새겨 넣는 방법입니다.