AI가 틀린 답을 내놓았을 때 — 서비스에 넣기 전 정해둘 3가지
AI 기능을 붙일 때 정확도만 보고 결정하면 운영에서 막혀요. 틀린 답이 나왔을 때 사용자에게 무엇을 보여줄지, 사람이 어느 지점에서 개입할지, 그 사례를 어떻게 모을지를 먼저 정해야 해요. 자체 SaaS를 운영하며 정리한 세 가지 기준을 정리했어요.
핵심 요약 — AI 기능을 서비스에 넣을 때 검토가 정확도 이야기에서 끝나는 경우가 많아요. 그런데 운영에서 문제가 되는 건 “얼마나 맞히나”보다 “틀렸을 때 어떻게 되나”예요. 틀린 답이 사용자에게 그대로 전달되는지, 사람이 중간에 볼 기회가 있는지, 그리고 틀린 사례가 기록으로 남는지에 따라 같은 모델을 써도 서비스 완성도가 달라져요. 발주 단계에서 정해두면 좋은 세 가지를 정리했어요.
AI 기능을 검토할 때 대화는 보통 이렇게 흘러요. “정확도가 어느 정도 나오나요?” “테스트해보니 꽤 잘 맞히던데요.”
그런데 서비스를 열고 나면 질문이 바뀌어요. “어제 고객이 받은 답이 틀렸는데, 이거 어디서 확인하죠?”
AI 기능은 틀릴 수 있다는 걸 전제로 설계해야 해요. 정확도를 높이는 것과 별개로, 틀렸을 때의 흐름을 미리 만들어두는 일이에요. 저희가 자체 서비스를 운영하고 여러 도입 프로젝트를 진행하면서 정리한 세 가지를 공유할게요.
1. 틀렸을 때 사용자가 무엇을 보게 되나요
가장 먼저 정할 건 결과를 어떻게 보여줄지예요. 선택지는 대체로 세 가지예요.
그대로 보여준다. 답변만 나오고 별다른 표시가 없어요. 사용자는 그게 AI가 만든 것인지, 얼마나 믿을 만한지 알기 어려워요. 틀린 답도 맞는 답처럼 보여요.
확신도를 함께 보여준다. “이 결과는 참고용이에요” 같은 안내나, 근거가 된 자료를 함께 보여주는 방식이에요. 사용자가 직접 확인할 수 있는 경로가 생겨요.
확실하지 않으면 내보내지 않는다. 기준에 못 미치면 결과 대신 다른 안내를 보여줘요. 잘못된 정보가 나갈 위험은 줄지만, 기능이 자주 비어 보일 수 있어요.
어느 쪽이 맞는지는 틀렸을 때의 영향으로 갈려요. 문구를 제안하는 기능이라면 사용자가 고쳐 쓰면 되니 그대로 보여줘도 괜찮아요. 반면 금액이나 일정처럼 그대로 실행되는 정보라면 근거를 함께 보여주거나 확인 단계를 두는 편이 안전해요.
여기서 중요한 건 사용자가 결과를 수정할 수 있게 만드는 것이에요. 수정 경로가 있으면 틀린 답이 사고로 이어지지 않고, 수정 기록이 남아 나중에 개선 자료가 돼요.
2. 사람이 어느 지점에서 보나요
두 번째는 사람이 개입하는 지점이에요. “AI를 넣으면 사람 손이 필요 없다”는 기대와 “그럼 전부 검토해야 하는 것 아니냐”는 걱정 사이에서 결정이 미뤄지곤 해요.
실무에서 쓰는 방식은 그 중간이에요. 전부 검토하는 대신 조건을 정해 일부만 사람에게 보내요.
- AI가 확신이 낮다고 표시한 건
- 금액이나 수량이 일정 기준을 넘는 건
- 특정 유형(환불, 계약, 개인정보 관련 등)에 해당하는 건
- 사용자가 “이상해요”라고 표시한 건
이 조건에 걸리지 않는 나머지는 그대로 통과시켜요. 그러면 대부분은 자동으로 처리되고, 위험이 큰 구간만 사람이 봐요.
설계할 때 정해야 할 건 조건 자체보다 그 조건을 나중에 바꿀 수 있는가 예요. 운영을 시작하면 기준은 반드시 조정돼요. 기준값이 코드 안에 고정돼 있으면 조정할 때마다 개발자가 손대야 해요. 관리 화면에서 바꿀 수 있게 열어두면 운영팀이 직접 조절할 수 있어요.
AI 도입을 어느 범위부터 시작할지에 대한 이야기는 AI 도입 비용, 얼마부터 시작하고 어디에 돈이 들까요에 정리해뒀어요.
3. 틀린 사례가 기록으로 남나요
세 번째가 가장 자주 빠지는 항목이에요. 틀린 답이 나왔다는 사실이 어디에도 남지 않는 경우가 많거든요.
기록이 없으면 개선을 시작할 수가 없어요. “가끔 이상한 답이 나온다”는 인상은 남는데, 어떤 상황에서 그런지 알 수 없으니까요. 그래서 처음 만들 때 다음 중 하나는 넣어두는 게 좋아요.
- 수정 이력 — 사용자가 AI 결과를 고쳤다면 원래 값과 고친 값을 함께 남겨요. 가장 정확한 신호예요. 사용자가 굳이 고쳤다는 건 그 결과가 맞지 않았다는 뜻이니까요.
- 피드백 버튼 — “도움이 됐나요” 같은 간단한 표시예요. 부담이 적지만 눌러주는 비율이 낮아요.
- 검토 결과 — 2번에서 사람이 검토한 건의 판단 결과를 남겨요. 이미 사람이 보는 구간이라 추가 부담이 적어요.
셋 다 넣을 필요는 없어요. 다만 하나도 없는 상태로 출시하면 개선할 근거가 없어요. 기록을 남기는 건 개발 비중이 크지 않은데, 나중에 붙이려면 데이터가 그동안 쌓이지 않아 처음부터 다시 모아야 해요.
모은 사례로 무엇을 하느냐도 미리 생각해두면 좋아요. 자주 틀리는 유형이 몇 가지로 좁혀지면, 그 유형만 다른 방식으로 처리하거나 안내 문구를 바꾸는 것으로 상당 부분 해결되는 경우가 있어요.
4. 세 가지를 요구사항에 어떻게 적을까요
발주 문서에 “AI 추천 기능”이라고만 적으면 위 세 가지가 빠진 채 견적이 나와요. 아래 정도만 덧붙여도 범위가 분명해져요.
| 항목 | 요구사항에 적을 내용 |
|---|---|
| 결과 표시 | 확신도·근거를 함께 보여주는가, 사용자가 결과를 수정할 수 있는가 |
| 사람 개입 | 어떤 조건일 때 검토 대상으로 넘기는가, 그 조건을 관리 화면에서 바꿀 수 있는가 |
| 기록 | 수정 이력·피드백·검토 결과 중 무엇을 남기는가, 어디서 확인하는가 |
세 줄이지만 이 항목이 있느냐 없느냐로 견적서의 범위가 달라져요. 그리고 운영을 시작한 뒤 손대는 비용과 비교하면 처음에 넣는 편이 훨씬 적게 들어요.
작게 시작해서 검증하는 방법은 AI PoC, 어디까지 해보고 결정할까요에서 다뤘어요.
마무리
AI 기능은 정확도를 올리는 일과 틀렸을 때를 준비하는 일이 함께 가야 해요. 앞의 것은 모델과 데이터의 문제이고, 뒤의 것은 서비스 설계의 문제예요. 그런데 발주 단계에서는 앞의 이야기만 오가는 경우가 많아요.
저희는 자체 SaaS 4종을 직접 운영하면서 “틀렸을 때의 흐름”을 미리 만들어두지 않으면 운영 부담이 어디로 몰리는지 겪었어요. 10년 이상 개발을 맡아오며 쌓인 경험도 같은 곳을 가리켜요. 그래서 AI 기능을 설계할 때 이 세 가지를 요구사항에 먼저 적어두시길 권해요.
AI 기능을 어느 범위로 시작할지 정리 중이시라면 프로젝트 상담에서 편하게 이야기 나눠요. 지금 서비스에 맞는 시작 지점을 함께 잡아볼게요.