AI 기능 요구사항을 검토하는 회의에서는 대개 “무엇을 자동화할 수 있는가”가 먼저 나온다. 그러나 제품이 출시된 뒤 더 큰 문제를 만드는 질문은 다른 곳에 있다. AI가 틀린 결과를 냈을 때, 사용자가 그 오류를 알아차리고 멈출 수 있는가. 멈추지 못했다면 누가 수정하고 책임질 수 있는가.
이 질문에 답하지 않은 자동화는 기능처럼 보이지만, 운영 단계에서는 승인 없는 의사결정 통로가 되기 쉽습니다. 특히 법률, 금융, 의료처럼 결과가 사람의 권리·건강·재산에 영향을 주는 영역만의 문제가 아닙니다. 채용 후보를 걸러내는 도구, 거래처에 발송할 견적을 만드는 기능, 고객 계정을 제한하는 운영 자동화도 잘못된 판단이 누적되면 되돌리기 어렵습니다.
AI 도입의 핵심은 사람이 하던 일을 많이 없애는 데 있지 않습니다. 오류를 허용할 수 없는 판단, 조직이 책임져야 하는 결정, 사용자가 충분한 근거를 보고 선택해야 하는 지점을 먼저 분리하는 데 있습니다.
실패는 AI의 오답보다 승인 없는 확신에서 시작된다
AI 기능은 틀릴 수 있습니다. 문제는 오류 자체보다 그 오류가 제품 안에서 어떤 지위로 유통되는가에 있습니다.
첫째, 사용자는 문장이 자연스럽고 단정적일수록 결과를 검토 대상이 아니라 결론으로 받아들일 수 있습니다. AI가 문서를 요약했을 뿐인데 사용자는 원문을 읽지 않고 계약 조건을 승인할 수 있습니다. 지원자 정보를 분류했을 뿐인데 담당자는 그 결과를 탈락 판단으로 사용할 수 있습니다. 이때 실패를 만드는 것은 모델의 답변 한 줄보다, 제품이 그 답변에 부여한 권위입니다.
둘째, 자동화가 다음 행동까지 연결될 때 오류 비용이 급격히 커집니다. 추천 결과를 보여주는 것과 계정을 정지시키는 것, 초안을 만드는 것과 외부에 발송하는 것은 다른 기능입니다. 후자는 금전·권한·평판·기회에 영향을 주므로, 결과를 생성한 시스템과 실행을 승인한 사람이 분리돼야 합니다.
셋째, 책임자가 불명확하면 검토가 형식으로 바뀝니다. “사람이 최종 확인한다”는 문구만으로는 충분하지 않습니다. 누가 어떤 기준으로 확인하는지, 확인하지 않으면 어떤 상태에서 멈추는지, 오류가 발견되면 누가 되돌리는지까지 요구사항에 있어야 합니다.
AI 기능 실패는 종종 모델의 성능 문제로 보고됩니다. 하지만 제품 관점에서는 책임 경로가 설계되지 않은 문제일 수 있습니다. 정답률을 높이는 일과 별개로, 잘못된 결과가 중요한 결정으로 넘어가지 않게 만드는 장치가 필요합니다.
업무를 자동화·검토·승인으로 나누는 기준
요구사항 단계에서 모든 업무를 세 구역으로 나눠보면 논의가 구체화됩니다. 이 구분은 특정 산업의 규제가 아니라, 오류 비용과 복구 가능성을 기준으로 한 제품 설계 도구입니다.
| 구역 | 맡길 수 있는 업무의 성격 | 제품이 갖춰야 할 장치 |
|---|---|---|
| 자동화 영역 | 반복적이고, 결과가 틀려도 쉽게 수정할 수 있으며, 사람의 권리나 자산을 직접 바꾸지 않는 업무 | 결과 저장, 수정 기능, 오류 신고 경로 |
| 사람 검토 영역 | AI가 초안·분류·요약을 만들 수 있지만, 맥락 판단이 필요한 업무 | 근거 표시, 원문 또는 입력값 확인, 수정 이력 |
| 사람 승인·책임 영역 | 결과가 되돌리기 어렵거나 개인·고객·조직에 직접 불이익을 주는 결정 | 명시적 승인, 권한 분리, 감사 로그, 예외 처리와 취소 절차 |
예를 들어 회의록 정리, 문서 초안 작성, 내부 지식 검색 결과 정리는 자동화 영역에 둘 수 있습니다. 다만 AI가 만든 요약을 근거로 계약을 확정하거나 인사 조치를 결정하는 순간, 그 업무는 사람 검토 또는 승인 영역으로 이동합니다.
분류 자체보다 중요한 것은 질문의 순서입니다. “AI가 할 수 있는가”보다 아래 네 가지를 먼저 묻는 편이 안전합니다.
- 이 결과가 틀렸을 때 사용자는 오류를 알아차릴 수 있는가.
- 잘못된 조치가 실행된 뒤 원상 복구할 수 있는가.
- 결과를 믿은 사람이 금전, 건강, 권리, 고용 기회처럼 큰 손실을 입을 수 있는가.
- 문제가 생겼을 때 승인자와 책임자가 기록으로 남는가.
네 질문 중 하나라도 답하기 어렵다면, 완전 자동화보다 검토 또는 승인 단계가 맞을 가능성이 큽니다. 이는 AI를 덜 쓰자는 주장이라기보다, AI가 맡을 역할을 더 좁고 명확하게 만들자는 제안입니다.
위험한 요구사항은 출시 전부터 신호를 보낸다
승인 경로의 빈틈은 운영 장애가 나기 전에 요구사항 문서와 화면 설계에서 드러나는 경우가 많습니다.
가장 흔한 조기 신호는 결과의 근거가 보이지 않는 경우입니다. AI가 “고위험”, “우선 처리”, “추천”, “부적합”이라고 표시하는데 입력 데이터, 적용 기준, 불확실성이 함께 나오지 않으면 검토자는 결과를 반박하기 어렵습니다. 이 기능은 사람이 확인하는 화면을 갖췄더라도 실질적으로는 자동 승인처럼 작동할 수 있습니다.
두 번째 신호는 행동 버튼이 결과와 너무 가깝게 붙어 있는 경우입니다. AI의 제안 바로 옆에 발송, 차단, 승인, 삭제 버튼이 있고 중간 확인 단계가 없다면 사용자는 판단보다 흐름을 따르게 됩니다. 특히 처리량이 많은 운영 화면에서는 이 문제가 더 커질 수 있습니다.
세 번째 신호는 실패 시나리오가 “재생성”으로 끝나는 경우입니다. 답변을 다시 만들 수 있다는 것과 이미 전송된 안내를 회수하거나, 잘못 제한된 계정을 복구하거나, 부정확한 판단을 받은 사람에게 설명할 수 있다는 것은 다릅니다. 제품 요구사항에는 생성 실패뿐 아니라 실행 후 복구 절차도 포함돼야 합니다.
네 번째 신호는 AI 결과를 누가 언제 봤는지 기록하지 않는 경우입니다. 규제 대응을 위해서만 로그가 필요한 것은 아닙니다. 오류 원인을 찾고, 검토 규칙을 고치고, 반복되는 예외를 발견하려면 결정 과정이 남아야 합니다.
요구사항에는 모델 설명보다 결정 흐름을 먼저 적는다
AI 기능 명세를 작성할 때 “입력값, 프롬프트, 출력 형식”만 정하면 제품의 절반만 정의한 셈입니다. 나머지 절반은 출력 이후의 처리 흐름입니다. 다음 항목을 기능 요구사항으로 명시해 두는 편이 좋습니다.
- AI의 역할: 생성, 추출, 분류, 우선순위 제안, 근거 탐색 중 어디까지 수행하는가
- 금지된 결론: 결과를 단정하거나 예측해서는 안 되는 판단은 무엇인가
- 검토자: 결과를 확인할 직무와 권한은 누구에게 있는가
- 승인 조건: 어떤 유형의 결과에서 사람의 명시적 승인이 필요한가
- 근거 화면: 검토자가 원문, 입력값, 적용 기준, 불확실성을 어디서 확인하는가
- 실행 통제: 외부 발송, 결제, 권한 변경, 삭제 같은 행동을 AI가 직접 실행할 수 있는가
- 예외 처리: 데이터가 부족하거나 결과가 충돌할 때 시스템은 무엇을 멈추고 누구에게 넘기는가
- 복구와 기록: 취소·정정·재검토는 어떻게 요청하며, 누가 어떤 결정을 했는지 무엇을 남기는가
이 항목은 개발팀만을 위한 목록이 아닙니다. 제품 책임자, 운영 담당자, 보안 담당자, 법무 또는 도메인 전문가가 각자 책임질 범위를 합의하는 문서가 됩니다.
외부 개발사나 AI 솔루션 사업자와 논의할 때도 같은 질문을 던질 수 있습니다. “정확도가 얼마인가”만 묻지 말고, 불확실한 결과를 어떻게 표시하는지, 승인 전에는 무엇을 실행하지 못하게 하는지, 검토 이력과 권한 설정을 어떤 방식으로 제공하는지 확인해야 합니다. 모델 성능 비교표만으로는 운영 위험을 판단하기 어렵습니다.
사람을 마지막 단계에 배치한다고 안전해지지는 않는다
사람 검토를 넣었다고 해서 곧바로 안전한 제품이 되는 것은 아닙니다. 검토자가 너무 많은 결과를 받아보거나, 판단 근거가 복잡하거나, 승인해도 책임 범위가 불명확하면 사람은 승인 버튼을 누르는 역할로 축소됩니다.
그래서 검토 단계는 사람에게 일을 떠넘기는 방식이 아니라, 사람이 더 나은 판단을 할 수 있게 만드는 방식으로 설계해야 합니다. AI는 관련 자료를 모으고, 쟁점을 정리하고, 누락 가능성을 표시할 수 있습니다. 반면 개인에게 불이익을 주는 조치, 중요한 거래의 확정, 진단이나 법률적 결론처럼 전문적 책임이 따르는 판단은 담당자가 근거를 검토한 뒤 내려야 합니다.
이 경계는 고정된 선도 아닙니다. 오류가 적고 복구가 쉬운 업무는 검토 단계를 줄여볼 수 있습니다. 반대로 민감한 데이터가 새로 들어오거나, AI 결과가 외부 행동으로 연결되거나, 사용자가 결과를 과신하는 패턴이 보이면 승인 단계를 강화해야 합니다.
다음 요구사항 회의에서는 자동화 후보 목록부터 만들기보다, 되돌릴 수 없는 결정 목록을 먼저 적어보십시오. 그 목록에 있는 업무는 AI의 출력이 아니라 사람의 승인 흐름부터 설계해야 합니다. 제품의 신뢰는 AI가 많은 답을 내놓을 때보다, 답을 내도 스스로 결정하지 못하게 만든 지점에서 더 분명해집니다.
