🧑🏻💻 Ep.27 | 사람의 승인을 어디에 둘 것인가
밤 11시가 넘으면 고객센터 당직자는 한 명뿐이었습니다. 그날도 AI가 만든 보상안을 확인하고 승인 버튼을 누르고 있었어요. 대부분 배송 지연에 대한 5천 원 쿠폰이었습니다.
화면에는 고객 문의 요약과 “쿠폰 발급을 승인할까요?”라는 문장만 보였습니다. 열두 번째쯤부터는 손이 먼저 움직였죠. 다음 날 한 고객에게 5만 원 쿠폰이 나간 사실을 발견했습니다. AI가 금액을 잘못 읽었지만 화면에서는 그 차이가 눈에 띄지 않았습니다.
사람이 중간에 있었습니다. 그런데 안전하지 않았습니다.
승인 버튼은 사람을 흐름에 넣어줄 뿐입니다. 좋은 판단까지 만들어주지는 않습니다.
※ 이 글의 야간 상담 장면과 금액은 승인 실패 패턴을 설명하기 위해 재구성한 가상 사례입니다.
1. 사람을 넣으면 안심되는 이유
AI가 문서만 읽을 때는 실수가 답변으로 끝납니다. 쿠폰, 환불, 계정 정지 같은 도구를 쥐는 순간 실수는 시스템 상태를 바꿉니다. 그래서 팀은 자연스럽게 “실행 전에 사람이 보자”고 합니다.
방향은 맞습니다. 다만 승인 요청이 쌓이면 리뷰가 또 하나의 반복 작업이 됩니다. 같은 모양의 화면을 수십 번 보면 사람은 차이를 찾기보다 흐름을 통과시키기 시작합니다. 코드 리뷰에서 거대한 PR을 빨리 훑을 때와 비슷해요.
모든 행동을 같은 승인 큐에 넣는 것도 문제입니다. 정책 문서 조회와 계정 영구 정지가 나란히 오면, 중요한 요청이 평범한 요청 속에 묻힙니다. 승인은 많을수록 안전한 장치가 아니라 주의력을 어디에 쓸지 정하는 장치에 가깝습니다.
2. 위험이 다른 일은 흐름도 달라야 한다
먼저 AI가 할 수 있는 행동을 펼쳐놓습니다. 그리고 틀렸을 때 되돌릴 수 있는지, 금전·권한·개인정보에 영향을 주는지, 피해가 한 사람에서 멈추는지를 봅니다.
FAQ 검색은 자동으로 해도 괜찮습니다. 답변 초안은 상담원이 고쳐 보낼 수 있습니다. 소액 쿠폰은 명확한 규칙 안에서 한 번의 승인을 둘 수 있고요. 고액 환불이나 계정 정지는 더 강한 권한과 별도 확인이 필요합니다.
반대로 모든 문장에 승인받으려 하면 상담원은 AI가 만든 초안을 직접 쓰는 것보다 더 피곤해집니다. 결국 버튼을 기계적으로 누르거나 기능을 쓰지 않게 됩니다.
💡 승인 강도는 AI가 얼마나 똑똑한지가 아니라, 틀렸을 때 생기는 영향으로 정합니다.
이 구분은 고정값도 아닙니다. 같은 5천 원 쿠폰이라도 한 고객에게 한 번 주는 것과 천 명에게 일괄 발급하는 것은 위험이 다릅니다. 금액뿐 아니라 범위와 빈도를 함께 봐야 합니다.
3. 승인자는 무엇이 달라지는지 봐야 한다
5만 원 사고 뒤 화면을 다시 열어봤습니다. 문의 요약은 길었지만 정작 중요한 값은 문장 중간에 숨어 있었습니다. 왜 이 보상을 제안했는지, 어떤 정책을 적용했는지도 바로 보이지 않았고요.
승인 화면에는 적어도 다음 질문의 답이 먼저 보여야 합니다.
✔️ 누구의 어떤 주문에
✔️ 무엇을 얼마나 실행하며
✔️ 어떤 정책과 근거로
✔️ 실행하면 외부에 어떤 변화가 생기는가
평소 값과 크게 다른 금액은 강조하고, 중복 발급 이력이 있으면 경고합니다. 원문 전체는 필요할 때 펼쳐보되, 결정에 필요한 차이는 첫 화면에서 읽혀야 합니다.
“AI가 추천했습니다”는 근거가 아닙니다. 승인자는 모델의 자신감이 아니라 주문 상태와 정책을 보고 판단해야 합니다. 좋은 화면은 정보를 많이 보여주는 화면이 아니라, 틀리면 큰 필드를 놓치기 어렵게 만든 화면입니다.
4. 내가 본 것과 실행되는 것이 같아야 한다
화면을 고쳐도 한 가지 문제가 남습니다. 승인 대기 중에 주문 상태나 쿠폰 금액이 바뀔 수 있다는 점입니다.
오후 11시 01분에 상담원이 본 제안이 5천 원이었는데, 11시 03분 재계산 과정에서 5만 원으로 바뀌었다면 기존 승인을 써도 될까요? 안 됩니다. 승인한 내용과 실행할 내용이 달라졌으니까요.
승인 요청을 만들 때 대상, 행동, 금액, 정책 버전을 하나의 작업으로 고정합니다. 승인자는 그 정확한 내용을 보고 확인하고, 실행기는 같은 작업만 실행합니다. 값이 바뀌었거나 유효 시간이 지났다면 새로 승인받습니다.
API 요청에 낙관적 잠금이나 버전 조건을 두는 것과 닮았습니다. “아까 본 데이터”를 근거로 지금의 상태를 덮어쓰지 않는 겁니다.
5. 한 번 승인한 일은 한 번만 일어나야 한다
네트워크 타임아웃이 나면 더 곤란해집니다. 승인 뒤 쿠폰 API를 호출했는데 응답을 받지 못했습니다. 다시 누르면 될까요?
첫 요청이 서버에서는 성공했을 수 있습니다. 그대로 재시도하면 쿠폰이 두 장 나갑니다. 사람 승인이 정확해도 실행 계층이 중복을 막지 못하면 사고는 납니다.
그래서 승인 작업에는 고유한 실행 키가 필요합니다. 같은 키로 재시도하면 새 쿠폰을 만들지 않고 처음 결과를 돌려줘야 합니다. 실행 상태도
승인됨, 처리 중, 완료, 실패, 확인 필요처럼 구분해 상담원이 무작정 다시 누르지 않게 하고요.
권한도 나눕니다. 승인자가 직접 임의의 금액을 실행하는 권한까지 가질 필요는 없습니다. AI는 제안하고, 사람은 정해진 범위에서 승인하고, 실행기는 검증된 요청만 처리합니다. 역할을 나누면 한 번의 실수나 계정 탈취가 곧바로 큰 실행으로 이어지기 어려워집니다.6. 사람이 없을 때의 동작이 더 중요하다
야간에 승인자가 한 명뿐이면 요청이 밀릴 수 있습니다. 이때 “사람이 승인할 때까지 기다린다”는 설계만 있으면 사용자는 끝없는 로딩을 봅니다.
승인 기한을 넘긴 요청은 자동 실행하지 않습니다. 진행 중이라고 솔직하게 알리고, 긴급도에 따라 다른 담당자에게 넘기거나 다음 운영 시간의 처리 목록에 넣습니다. 승인자가 응답하지 않는 상황도 정상적인 운영 상태로 다뤄야 합니다.
7. 승인자의 판단도 돌아본다
승인 품질도 돌아봅니다. 얼마나 자주 수정했는지, 어떤 화면에서 승인 시간이 길었는지, 자동 승인으로 넓혀도 되는 반복과 더 강하게 막아야 할 패턴은 무엇인지 확인합니다. 사람을 영원한 병목으로 두는 대신, 실제 판단이 필요한 자리만 남기는 겁니다.
✅ 사람의 승인은 AI의 책임을 대신 떠안는 절차가 아닙니다. 큰 변화 앞에서 판단할 재료와 시간을 확보하고, 누가 무엇을 결정했는지 남기는 제품 기능입니다.
버튼 하나를 추가하는 데서 멈추지 마세요. 승인자가 무엇을 봤는지, 그 뒤 무엇이 실행됐는지, 응답이 없거나 네트워크가 끊겨도 약속이 유지되는지까지 이어져야 비로소 안전장치가 됩니다.
🌱 자동화와 책임의 경계를 함께 설계하는 곳, 루퍼스
빠르게 실행하는 시스템일수록 사람이 판단할 자리를 정교하게 만들어야 합니다. 권한과 승인, 운영 경험을 함께 나누고 싶다면 루퍼스에서 시작해보세요 🙌
AI 시대에도 결국 중요한 건 생각하는 힘과 성장하는 환경이라고 믿습니다.
루퍼스에는 성장에 진심인 800+명의 크루가 함께하고 있습니다. 현업에서 부딪히는 고민과 경험을 나누며 함께 성장하는 크루들의 이야기. 전액 기부 강의 그리고 다양한 오프라인 네트워킹까지! 루퍼스는 개발자를 위한 지속 가능한 성장을 만들어 갑니다.
📢 LOOPERS의 소식이 궁금하다면?
Share article