🧑🏻💻 Ep.24 | AI 데모를 제품으로 바꾸는 계약
한 팀이 회의실에서 주문 변경 AI를 시연합니다. “내일 받을 생수를 모레로 미뤄줘”라고 말하자 주문을 찾고, 새 날짜를 확인하고, 변경 완료 안내까지 매끄럽게 해냅니다. “이 정도면 다음 주에 열어도 되겠네요.”
그때 운영 담당자가 물었습니다.
“이미 출고 지시가 내려간 주문이면요?”
AI는 똑같이 자신 있게 “변경했습니다”라고 답했습니다. 실제 주문은 바뀌지 않았고요. 데모에서 보지 않았던 단 한 줄의 상태값이 제품과 사고를 갈랐습니다.
데모는 가능한 장면을 보여줍니다. 제품은 불가능한 장면에서 무엇을 할지도 약속해야 합니다.
※ Ep.24–Ep.33의 운영 장면은 여러 현업 패턴을 한 팀의 흐름으로 재구성한 가상 시나리오입니다. 인물과 수치는 설명을 위한 예시입니다.
1. 데모가 틀린 건 아니었다
회의실에서 거짓말을 한 사람은 없었습니다. 준비한 테스트 주문은 출고 전이었고, 연결한 변경 API도 정상 동작했습니다. 그 장면만 놓고 보면 데모는 성공이었어요.
문제는 우리가 그 성공을 너무 크게 해석했다는 데 있었습니다.
“출고 전 일반 주문의 배송일을 바꿀 수 있다”가 확인된 사실인데, 어느새 “배송일 변경을 AI가 처리한다”로 문장이 넓어졌습니다. 정기 배송인지, 묶음 배송인지, 냉장 상품인지, 이미 물류 센터에 넘어갔는지는 빠졌고요.
백엔드 API라면 입력과 상태 전이를 먼저 따졌을 겁니다. AI가 자연스럽게 대화하니 그 기본 질문을 잠시 잊은 셈입니다. 말이 부드럽다고 기능의 경계까지 부드러워져도 되는 건 아니었습니다.
2. 사용자가 기대하는 끝을 먼저 본다
“배송일 변경 AI”를 만든다고 하면 팀의 시선은 금방 모델과 프롬프트로 갑니다. 그런데 사용자가 원하는 끝은 좋은 문장이 아닙니다.
💡 사용자는 변경 안내를 받고 싶은 게 아니라, 실제 주문이 원하는 날짜에 오기를 바랍니다.
이렇게 끝을 바꿔 적으면 확인할 것이 달라집니다.
✔️ 변경 가능한 주문 상태인가
✔️ 물류 시스템이 새 날짜를 받아들였는가
✔️ 결제나 쿠폰 조건이 달라지지는 않는가
✔️ 실패했다면 사용자는 지금 무엇을 해야 하는가
AI의 답변은 이 흐름 중 마지막 화면일 뿐입니다. 앞단의 상태 조회가 오래됐거나 변경 API가 실패했는데 “처리됐습니다”라고 말하면, 문장 품질이 아무리 좋아도 제품은 실패한 겁니다.
그래서 첫 문서는 기능 목록보다 사용자가 얻게 될 결과로 시작하는 편이 좋습니다. “자연어로 배송일을 바꾼다”가 아니라 “변경 가능한 주문은 실제 날짜를 바꾸고, 불가능한 주문은 이유와 다음 선택지를 알려준다”처럼요.
3. 가장 싫은 실패를 골라본다
모든 예외를 출시 전에 찾을 수는 없습니다. 그렇다고 “엣지 케이스가 많다”는 말로 끝낼 수도 없고요. 이럴 때는 팀에 한 가지를 물어볼 수 있습니다.
“이 기능이 틀렸을 때, 사용자가 가장 억울해지는 장면은 무엇일까?”
배송일 변경에서는 이런 장면이 나왔습니다.
✔️ 바뀌었다는 안내를 믿었는데 원래 날짜에 도착한다
✔️ 같은 요청이 두 번 실행돼 주문이 예상보다 늦어진다
✔️ 다른 가족 구성원의 주문을 잘못 바꾼다
✔️ 변경할 수 없는 냉장 상품을 가능하다고 안내한다
목록이 생기자 우선순위도 보였습니다. 말투가 조금 어색한 실패보다, 실행되지 않은 일을 실행됐다고 알리는 실패가 훨씬 컸습니다. 전자는 개선할 품질 문제지만 후자는 출시를 막아야 할 문제였어요.
이 구분이 있어야 테스트도 선명해집니다. “답변이 자연스러운가”와 “성공 응답이 실제 상태 변경 뒤에만 나가는가”를 같은 점수로 평균 내면 안 됩니다. 치명적인 한 건이 자연스러운 아흔아홉 건 속에 숨어버리니까요.
4. 못 하는 일을 제품 안에 넣는다
처음에는 지원하지 않는 경우를 도움말에 적으면 된다고 생각했습니다. 실제 대화에서는 잘 안 통했습니다. 사용자는 도움말을 다 읽고 질문하지 않으니까요. 이미 출고된 주문에도 “모레로 미뤄줘”라고 말합니다.
따라서 미지원 상태에도 동작이 필요합니다.
출고 지시 전이라면 변경을 실행합니다. 물류 센터에 넘어갔다면 실행하지 않고 현재 상태를 보여줍니다. 냉장 상품처럼 별도 확인이 필요하면 고객센터 연결과 준비할 정보를 알려줍니다. 주문을 특정할 수 없다면 추측해서 고르지 않고 다시 묻습니다.
여기서 중요한 건 “죄송합니다. 처리할 수 없습니다”로 끝내지 않는 겁니다. 안전하게 멈추면서도 사용자가 다음으로 갈 수 있어야 합니다.
☑️ 모른다고 말하는 것, 다시 묻는 것, 사람에게 넘기는 것도 모두 제품 동작입니다.
잘되는 길만 UI에 있고 실패는 에러 메시지로 빠져 있다면, 아직 데모의 구조에 가깝습니다.
5. 그제야 ‘계약’이라는 말이 쓸모 있어진다
이제 팀이 합의한 내용을 짧게 묶을 수 있습니다.
✔️ 어떤 사용자와 주문 상태를 지원하는가
✔️ 성공은 실제로 어떤 상태가 된 것을 뜻하는가
✔️ 절대 통과시키지 않을 실패는 무엇인가
✔️ 정보가 부족하거나 시스템이 실패하면 어디로 물러나는가
✔️ 잘못 실행됐을 때 누가 확인하고 되돌리는가
이 묶음을 이 글에서는 제품 계약이라고 부르겠습니다. 거창한 새 문서 형식은 아닙니다. 기획서의 사용자 결과, API의 전제 조건, 테스트의 금지 조건, 운영팀의 복구 절차를 같은 문장으로 맞추는 일에 가깝습니다.
계약이 있으면 대화도 달라집니다. “모델이 꽤 똑똑한데요?” 대신 “출고 지시가 늦게 도착한 경우도 성공으로 보나요?”를 묻게 됩니다. 취향이 아니라 상태와 책임을 두고 이야기할 수 있고요.
이 계약은 한 번 쓰고 닫는 문서도 아닙니다. 실제 사용자가 우리가 예상하지 못한 방식으로 묻고, 물류 정책이 바뀌고, 새로운 실패가 발견되면 함께 바뀌어야 합니다. 운영에서 발견한 한 건을 다음 배포의 기준으로 돌려보내는 것이 핵심입니다.
6. 다음 시연에서 바꿀 한 가지
다음 데모에서는 가장 잘되는 질문만 준비하지 않아도 좋겠습니다. 오히려 팀에서 가장 걱정하는 질문 하나를 끼워 넣어보세요.
“이미 출고됐다면?”, “두 번 눌렀다면?”, “주문을 찾지 못했다면?”
그 질문에 AI가 멋진 답을 하는지보다, 제품이 약속한 경계 안에서 움직이는지를 보는 겁니다. 성공하면 실제 상태를 확인하고, 실패하면 더 큰 피해 없이 멈추며, 사용자가 다음 행동을 알 수 있는지까지요.
✅ 데모를 제품으로 바꾸는 순간은 AI가 더 많은 질문에 답할 때가 아닙니다. 팀이 어디까지 책임질지 같은 문장으로 말할 수 있을 때입니다.
그 문장이 생기면 다음 질문도 자연스럽게 따라옵니다. 이 약속이 다음 프롬프트와 다음 모델에서도 지켜지는지는 어떻게 확인할까. 다음 글에서는 바로 그 평가의 문제를 다뤄보겠습니다.
🌱 제품의 경계를 함께 고민하는 개발자들이 모인 곳, 루퍼스
잘되는 기능을 만드는 것과 오래 운영할 수 있는 제품을 만드는 것은 다릅니다. 경계와 실패, 복구까지 함께 설계하는 감각을 나누고 싶다면 루퍼스에서 그 여정을 시작해보세요 🙌
AI 시대에도 결국 중요한 건 생각하는 힘과 성장하는 환경이라고 믿습니다.
루퍼스에는 성장에 진심인 800+명의 크루가 함께하고 있습니다. 현업에서 부딪히는 고민과 경험을 나누며 함께 성장하는 크루들의 이야기. 전액 기부 강의 그리고 다양한 오프라인 네트워킹까지! 루퍼스는 개발자를 위한 지속 가능한 성장을 만들어 갑니다.
📢 LOOPERS의 소식이 궁금하다면?
Share article