제품팀이 “이 업무를 AI에게 맡기자”라고 결정한 뒤 가장 자주 부딪히는 문제는 모델 성능이 아니다. 업무가 끝났다는 말의 기준이 모호하고, 틀린 결과가 어디로 흘러갔는지 추적할 수 없으며, 누가 최종 책임을 지는지도 정하지 않은 상태에서 자동 실행부터 시작하는 데 있다.
요구사항 단계에서 먼저 정할 것은 AI가 잘할 법한 일이 아니라 틀려도 멈추고, 확인하고, 되돌릴 수 있는 일이다. 같은 업무 안에도 규칙으로 처리할 부분, AI가 초안을 만들 부분, 사람이 승인해야 할 부분이 섞여 있다. 이 경계를 분리하면 자동화 범위가 작아 보일 수 있지만, 이후 확장할 수 있는 신뢰 기반은 오히려 빨리 만들어진다.
업무를 기능이 아니라 결정 단위로 쪼갠다
“고객 문의를 자동 처리한다”나 “정산 검토를 AI로 바꾼다”는 요구사항은 너무 넓다. 구현 전에 업무를 입력, 판단, 실행, 기록의 네 단계로 나눠야 한다.
예를 들어 고객 문의 처리 업무에는 문의 접수 여부 확인, 고객 정보 조회, 문의 유형 분류, 답변 초안 작성, 환불 승인, CRM 기록 저장이 함께 들어갈 수 있다. 이들을 하나의 AI 에이전트 작업으로 묶으면, 오류가 발생했을 때 어느 판단이 틀렸는지 찾기 어렵다.
요구사항 문서에는 각 결정 단위마다 다음을 남긴다.
- 입력: 어떤 데이터와 문서가 판단 근거인가
- 출력: 시스템이 만들 결과는 무엇이며, 완료 상태는 어떻게 판정하는가
- 오류 비용: 잘못 처리했을 때 금전, 고객 관계, 운영 일정, 법적 책임 중 무엇이 영향을 받는가
- 복구 경로: 취소, 수정, 재처리, 사람 검토 중 어떤 방식으로 되돌릴 수 있는가
- 책임자: 결과를 확인하고 예외를 결정할 사람 또는 팀은 누구인가
이 목록은 모델 선정표가 아니다. 자동화 권한을 어디까지 줄지 결정하는 작업지시서에 가깝다.
정답이 고정된 구간은 규칙 자동화로 먼저 고정한다
입력이 같으면 같은 결과가 나와야 하는 일은 AI 판단보다 규칙 기반 자동화에 맞는다. 필수 항목 누락 확인, 파일 형식 검사, 날짜 계산, 권한 확인, 정해진 상태값 전환, 계약된 데이터 형식에 따른 코드 생성이 여기에 속한다.
가령 OpenAPI 명세는 API 요청과 응답 형식을 정의한 계약 문서다. 이처럼 입력 형식과 변환 규칙이 정해진 경우에는 명세를 따라 타입이 지정된 클라이언트 코드를 생성하는 도구를 사용할 수 있다. Orval도 유효한 OpenAPI 또는 Swagger 명세에서 TypeScript 클라이언트를 생성하는 방식이다. 이런 구간에서 필요한 것은 그때그때의 해석이 아니라, 같은 명세를 같은 결과로 옮기는 재현성이다.
규칙 자동화 요구사항에는 자연어 지시 대신 아래 항목을 명확히 적는다.
| 확인 항목 | 요구사항에 적을 내용 |
|---|---|
| 판정 규칙 | 어떤 조건을 만족하면 통과·반려·보류하는가 |
| 예외 처리 | 조건을 판정할 수 없을 때 어디로 보내는가 |
| 입력 품질 | 누락, 중복, 형식 오류를 어떻게 처리하는가 |
| 실행 권한 | 조회만 가능한지, 상태 변경까지 가능한지 |
| 증적 | 어떤 입력과 규칙 버전, 결과를 남길 것인가 |
규칙이 아직 완성되지 않았다고 해서 곧바로 AI 판단으로 대체할 필요는 없다. AI에게 과거 사례와 문서를 읽게 해 규칙 후보를 찾거나, 예외 유형을 묶어 보게 할 수는 있다. 다만 운영에서 통과·반려를 결정하는 기준은 테스트 가능한 규칙으로 고정하는 편이 검증과 변경 관리에 유리하다.
AI는 판단을 대체하기보다 초안과 분류를 맡긴다
정답이 하나로 고정되지 않고 문맥 해석이 필요한 구간에서는 AI가 유용할 수 있다. 긴 문서에서 쟁점을 정리하거나, 문의 의도를 분류하거나, 여러 자료를 바탕으로 담당자 검토용 초안을 만드는 일이 대표적이다.
여기서 중요한 요구사항은 “AI가 답을 낸다”가 아니라 “AI가 무엇을 근거로 어떤 형식의 초안을 낸다”로 바꾸는 것이다. AI 출력에 다음 항목을 요구하면 검토자가 결과를 더 빨리 확인할 수 있다.
- 판단에 사용한 입력 문서와 데이터 범위
- 사실로 확인된 내용과 추정 또는 해석을 구분한 표시
- 답변 또는 권고의 근거가 된 원문 위치
- 확신이 낮거나 정보가 부족한 항목의 별도 표시
- 사람이 선택할 수 있는 다음 조치 후보
AI가 만든 요약을 CRM에 저장하거나, 추천을 업무 시스템에 반영하는 경우도 원문이나 입력 데이터로 돌아갈 수 있어야 한다. 검토자가 “왜 이런 결과가 나왔는지” 확인할 수 없다면, 그 출력은 실행 지시가 아니라 참고 메모로 취급하는 편이 안전하다.
되돌릴 수 없는 실행은 사람의 승인 단계로 남긴다
AI의 오류 비용은 결과가 어색한 정도로 끝나지 않을 수 있다. 가격 변경, 지급 승인, 채용·평가 판단, 고객 자격 결정, 실제 사용자 데이터 수정, 대외 발송, 서비스 배포처럼 한 번 실행한 뒤 회복이 어렵거나 책임이 큰 행위는 별도로 분류해야 한다.
이 단계에서 사람 승인은 형식적인 버튼 클릭이 되어서는 안 된다. 승인자가 판단할 수 있는 자료와 권한을 함께 설계해야 한다. 승인 화면 또는 운영 절차에는 최소한 다음이 필요하다.
- AI가 제안한 조치와 영향 대상
- 적용 전후에 달라지는 값 또는 메시지
- 판단 근거와 누락된 정보
- 취소 또는 보류할 수 있는 선택지
- 승인자와 승인 시각, 이후 변경 이력
사람이 승인한다고 해서 모든 위험이 사라지는 것은 아니다. 승인자가 검토할 시간도, 근거도 없이 대량 요청을 처리한다면 사람은 책임만 떠안게 된다. 따라서 승인 대기 건수, 보류 사유, 재검토 빈도도 운영 지표로 보아야 한다.
첫 구현은 작은 업무에서 검증 가능한 실패를 만든다
초기 대상은 “가장 많은 시간을 절약하는 업무” 하나만으로 고르지 않는다. 반복 빈도와 소요 시간에 더해, 오류가 났을 때 영향 범위를 좁힐 수 있는지, 결과를 정답 또는 원문과 대조할 수 있는지, 다른 팀에도 재사용할 가능성이 있는지를 함께 본다.
권장하는 실행 순서는 다음과 같다.
1단계, 업무 목록화
팀이 반복하는 업무를 모으고, 각 업무를 결정 단위로 분해한다. 산출물은 업무 흐름도와 입력·출력 목록이다.
2단계, 책임 경계 결정
각 단위를 규칙 자동화, AI 보조, 사람 최종 판단으로 나눈다. 산출물은 권한 매트릭스와 예외 처리 표다.
3단계, 읽기 전용 검증
처음에는 운영 데이터를 조회하고 초안을 만드는 범위에서 결과를 비교한다. 산출물은 샘플 결과, 오류 유형 목록, 검토 기준이다.
4단계, 제한된 실행 권한 부여
검증 기준을 통과한 좁은 업무에만 상태 변경이나 등록 권한을 준다. 취소와 재처리 경로를 함께 만든다. 산출물은 실행 로그와 복구 절차다.
5단계, 운영 검토
정확도만 보지 말고 보류되는 건, 사람이 되돌린 건, 규칙이 자주 바뀌는 건을 검토한다. 산출물은 변경 요청 목록과 다음 자동화 후보 목록이다.
초기 운영에서 사람이 되돌린 결과가 계속 나온다면 모델을 더 강하게 바꾸기 전에 원인을 분류해야 한다. 입력 데이터가 부족했는지, 규칙 예외를 빼먹었는지, AI가 판단하면 안 되는 권한을 받았는지에 따라 해결 방법이 달라진다.
요구사항 검토 회의에서 던질 질문
프로덕트 매니저는 자동화 제안을 받을 때 “AI가 가능한가”보다 아래 질문으로 회의를 이끌 수 있다.
- 이 업무에서 같은 입력이면 항상 같은 결과가 나와야 하는 부분은 어디인가?
- 시스템이 모르는 정보가 있을 때 자동 실행 대신 어디에서 멈춰야 하는가?
- 결과가 틀렸다는 사실을 누가, 언제, 어떤 원문과 비교해 확인하는가?
- 실행 후 취소할 수 없는 행위는 무엇이며, 그 직전 승인자는 누구인가?
- 오류를 수정한 뒤 같은 오류가 반복되지 않게 규칙, 프롬프트, 데이터 중 무엇을 바꿀 것인가?
- AI가 사용할 수 있는 데이터와 실제로 변경할 수 있는 시스템 권한은 분리되어 있는가?
좋은 AI 자동화 요구사항은 “사람을 없애는 범위”를 넓게 선언하지 않는다. 시스템이 확실하게 처리할 일을 먼저 고정하고, AI는 불확실한 정보를 정리하게 하며, 되돌릴 수 없는 선택은 책임자가 확인하도록 설계한다. 다음 자동화 후보를 고를 때는 가장 화려한 업무보다, 이 경계를 문서로 설명할 수 있는 업무부터 꺼내 보는 편이 좋다.
