AI 자동화는 모델을 고르기 전에 업무 입력의 범위, 접근 권한, 사람의 판단 경계, 변경 기록을 정리해야 합니다. 첫 파일럿은 모든 데이터를 연결하는 일이 아니라, 한 가지 반복 업무에서 필요한 정보만 안전하게 흐르게 만드는 일입니다.
먼저 결론
도입 준비가 된 업무는 세 가지 질문에 짧게 답할 수 있습니다.
1. 무엇이 들어오나? 허용된 문서·필드·형식과 누락 시 처리 경로가 정해져 있습니다. 2. 누가 무엇을 보나? AI, 실행 담당자, 승인자의 접근 범위가 업무 목적에 맞게 나뉘어 있습니다. 3. 무엇이 바뀌었나? 입력, 규칙, 결과, 사람의 수정·승인과 예외 처리를 나중에 다시 확인할 수 있습니다.
이 세 가지가 빠진 자동화는 처음에는 작동해도, 문서 형식이 바뀌거나 예외가 몰릴 때 원인을 찾기 어렵습니다. NIST AI RMF는 사용 맥락과 한계, 사람의 감독 방식을 문서화하고 데이터의 출처·변환·제약을 남기는 것을 위험 관리의 한 부분으로 제시합니다.[s1][s2]
1. 업무 흐름부터 한 장으로 그린다
첫 문서는 시스템 설계서가 아니라 한 장짜리 업무 흐름도면 충분합니다. 접수부터 실제 완료까지, 사람이 하는 일과 자동화가 하는 일을 나눠 적으세요.
| 구간 | 확인할 질문 | 예시 결정 |
|---|---|---|
| 접수 | 어떤 건이 자동화 대상인가? | 정해진 양식의 문의만 대상 |
| 입력 | 어떤 필드·문서가 필요한가? | 고객명, 요청 유형, 첨부 문서 |
| 처리 | AI가 제안만 하나, 실행도 하나? | 분류·초안만 생성 |
| 검토 | 누가 어떤 기준으로 승인하나? | 담당자가 필수 필드와 정책을 확인 |
| 완료 | 업무 완료는 언제인가? | 승인된 결과가 CRM에 반영된 시점 |
| 예외 | 어떤 경우에 멈추고 넘기나? | 누락, 민감정보, 낮은 신뢰도는 수기 대기열 |
여기서 핵심은 “AI가 할 수 있는 일”이 아니라 업무상 완료로 인정할 수 있는 범위입니다. NIST는 의도된 용도, 사용 환경, 가정과 한계, 사람의 감독 방식을 함께 이해하고 기록하도록 권합니다.[s1]
2. 입력을 ‘문서 더미’가 아니라 계약으로 바꾼다
업무 입력이 이메일, PDF, 스프레드시트, 채팅처럼 제각각이면 모델 성능을 논하기 전에 경계를 정해야 합니다. 파일럿에서는 아래 네 항목만 합의해도 충분합니다.
| 항목 | 정할 내용 | 안전한 시작 |
|---|---|---|
| 허용 형식 | 어떤 파일과 채널을 받을지 | 이미 쓰는 한두 형식으로 제한 |
| 필수 정보 | 없으면 처리할 수 없는 값 | 누락은 자동 추측 대신 보류 |
| 민감도 | 접근·마스킹이 필요한 정보 | 업무에 불필요한 값은 제외 |
| 신선도 | 언제 기준의 정보인지 | 최신 확인 시점과 담당자 기록 |
“나중에 AI가 알아서 읽을 것”은 입력 규칙이 아닙니다. 문서가 흐릿하거나 필수 항목이 비어 있으면, 결과를 만들기보다 원래 담당자에게 돌려보내는 경로가 더 안전합니다. 데이터 최소화와 목적에 맞는 접근 범위는 정보 보호 검토에서도 중요한 출발점입니다.[s3]
예시: 견적 문의 분류 자동화라면
견적 문의가 메일함으로 들어오는 중소기업을 생각해 보세요. 목표는 모든 메일에 자동 답장하는 것이 아니라, 담당자가 빨리 판단하도록 문의를 정리하고 필요한 정보가 빠졌을 때 재요청 초안을 만드는 일입니다.
| 단계 | 자동화가 하는 일 | 사람이 하는 일 | 예외로 보내는 경우 |
|---|---|---|---|
| 접수 | 제목·본문·첨부 여부를 읽음 | 없음 | 첨부가 손상되었거나 접근 권한이 없음 |
| 정리 | 제품·수량·납기·연락처 누락 표시 | 분류 확인 | 정보가 서로 충돌함 |
| 초안 | 추가 정보를 묻는 회신 초안 작성 | 문구 확인·발송 | 가격·계약 조건을 언급해야 함 |
| 기록 | CRM에 초안 태그 저장 | 담당자 배정·상태 확정 | 기존 고객 이력과 다름 |
이 사례에서 가격 산정, 할인 약속, 계약 확정은 자동화 범위 밖입니다. 자동화가 할 수 있는 일과 하지 않는 일을 먼저 나누면, 잘못된 발송과 책임 불명확성을 줄이면서도 담당자의 정리 시간을 줄일 수 있습니다.
3. 권한은 사람의 직무를 그대로 복사하지 않는다
기존 담당자가 여러 시스템을 볼 수 있다고 해서 자동화도 같은 권한을 가질 필요는 없습니다. 자동화에는 그 업무 한 건을 처리하는 데 필요한 최소 범위만 줍니다.
권한 표에는 다음을 나눠 적으세요.
- 읽기: 어떤 데이터 원본을 읽는가
- 쓰기: 어떤 시스템에 초안·확정 결과를 남기는가
- 실행: 고객 연락, 상태 변경, 결제 같은 외부 행동을 할 수 있는가
- 승인: 누가 결과를 확정하거나 되돌릴 수 있는가
- 감사: 누가 기록을 보고 문제를 조사할 수 있는가
특히 읽기 권한과 실행 권한은 별도로 보세요. 처음 파일럿은 읽기와 초안 생성으로 시작하고, 외부 실행은 사람이 승인한 뒤에만 하도록 두는 편이 운영 부담을 줄입니다. 역할과 책임, 사람-AI 감독 구성을 분명히 두라는 NIST의 권고도 이 원칙과 맞닿아 있습니다.[s2]
업무별 권한 설계는 이렇게 시작한다
권한을 설계할 때 “이 담당자가 원래 할 수 있는가”보다 “이 자동화 단계가 반드시 해야 하는가”를 먼저 묻습니다. 예를 들어 고객 문의를 분류하는 흐름이라면 이메일 제목과 본문을 읽고 CRM에 분류 초안을 남기는 권한까지로 충분할 수 있습니다. 고객에게 답장을 보내거나 담당자를 변경하는 권한은 별도 단계로 남깁니다.
| 업무 단계 | 자동화에 허용할 행동 | 사람에게 남길 행동 | 처음부터 막을 행동 |
|---|---|---|---|
| 문의 분류 | 읽기, 태그 제안, 초안 저장 | 우선순위 확정, 담당자 배정 | 고객 통지, 계정 변경 |
| 문서 추출 | 필드 추출, 누락 표시 | 값 확인, 원문 대조 | 금액 확정, 계약 변경 |
| 회신 초안 | 근거 기반 초안 작성 | 표현·정책 검토, 발송 | 승인 없는 발송 |
| 내부 보고 | 요약과 출처 연결 | 해석, 의사결정 | 외부 공유 |
이 표는 기술 권한 목록이 아니라 운영 책임표입니다. 한 줄이라도 “자동화가 해도 되는지” 의견이 갈리면, 파일럿에서는 사람에게 남기는 쪽을 선택하세요. 범위를 다시 넓히는 일은 쉽지만, 과도한 권한을 회수한 뒤 신뢰를 복구하는 일은 어렵습니다.
4. 사람 검토가 ‘확인 버튼’이 되지 않게 만든다
승인자가 결과를 볼 수 있어도, 무엇을 확인해야 하는지 모르거나 시간이 없으면 실질적인 검토가 되기 어렵습니다. 검토 화면이나 체크리스트에는 적어도 다음이 필요합니다.
1. AI가 사용한 입력의 출처와 누락 여부 2. 제안 결과와 사람이 판단해야 하는 항목 3. 승인·수정·반려 중 하나를 고르는 기준 4. 수정 또는 반려 사유 5. 문제가 반복될 때 자동화를 멈추는 경로
ICO의 AI 검토 지침은 검토자가 결과에 이의를 제기할 권한과 역량을 가져야 하며, 사람이 변경하거나 뒤집은 결정과 사유를 남기고 대체·수기 경로를 준비할 것을 권합니다.[s4] 이는 한국 법률 자문이 아니라, 승인 과정을 실제 통제로 만들기 위한 운영 원칙으로 참고할 수 있습니다.
승인 화면에 반드시 보여야 할 것
승인자는 완성된 문장만 보고 판단하면 안 됩니다. 어떤 입력을 바탕으로 했는지, 빠진 정보가 있는지, 어디까지 자동화가 처리했는지를 한 화면 또는 한 묶음에서 확인할 수 있어야 합니다. 검토가 길어지는 원인은 AI 결과의 품질만이 아니라, 원문을 다시 찾고 맥락을 복원하는 데 드는 시간인 경우가 많습니다.
| 검토 항목 | 승인자가 답할 질문 | 기록할 결과 |
|---|---|---|
| 입력 완전성 | 필수 정보가 모두 있는가? | 누락·재요청 사유 |
| 결과 정확성 | 원문과 제안이 일치하는가? | 수정한 항목 |
| 정책 적합성 | 이 업무 기준을 충족하는가? | 승인·반려 근거 |
| 영향 범위 | 외부에 나가도 되는가? | 추가 승인 필요 여부 |
| 복구 가능성 | 틀리면 어떻게 되돌리는가? | 되돌림 절차·담당자 |
검토자가 반복해서 같은 수정만 한다면, 그 수정은 개인의 노하우로 남기지 말고 입력 규칙, 템플릿 또는 체크리스트에 반영해야 합니다. 반대로 수정 사유가 매번 다르면 자동화 범위가 너무 넓거나 업무 규칙 자체가 아직 안정되지 않았을 수 있습니다.
5. 변경 이력은 디버깅용이 아니라 운영용이다
업무 자동화는 시간이 지나며 입력 양식, 업무 정책, 프롬프트, 연결 시스템이 바뀝니다. 어떤 변경 뒤에 오류나 수정이 늘었다면 그 시점을 되짚을 수 있어야 합니다.
파일럿에서는 복잡한 관측 플랫폼보다 아래 로그로 시작하세요.
| 기록 | 최소 내용 |
|---|---|
| 업무 건 | 고유 ID, 접수·완료 시각, 상태 |
| 입력 | 출처, 형식, 누락 여부, 민감정보 처리 여부 |
| 자동화 | 사용한 흐름·규칙 버전, 실행 시각, 결과 상태 |
| 사람 검토 | 승인·수정·반려, 사유, 담당자 역할 |
| 예외 | 원인, 수기 전환 시각, 해결 상태 |
| 변경 | 무엇을 왜 바꿨는지, 적용 시점 |
로그에는 원문 전체나 불필요한 개인정보를 무조건 복제하지 마세요. 조사에 필요한 식별자와 상태를 남기고, 원본 접근은 별도의 권한 체계로 관리하는 편이 낫습니다. NIST의 문서화 항목도 데이터 출처뿐 아니라 변환, 제약, 메타데이터를 고려하도록 제시합니다.[s2]
바꿀 때는 한 번에 하나씩 바꾼다
입력 양식, 프롬프트, 모델, 승인 기준을 같은 날 바꾸면 결과가 좋아지거나 나빠졌을 때 이유를 알 수 없습니다. 파일럿에서는 변경 하나마다 적용 시점과 이유를 남기고, 가능하면 변경 전후의 건을 따로 봅니다. 안전 문제를 즉시 고쳐야 할 때는 예외지만, 그때도 무엇을 긴급 수정했는지는 기록합니다.
다음 신호는 변경을 검토할 이유가 됩니다.
- 특정 입력 형식에서만 누락·반려가 반복된다.
- 특정 승인자에게만 검토 대기가 길게 쌓인다.
- 같은 수정 사유가 전체 검토의 상당 부분을 차지한다.
- 예외는 줄었지만 승인 후 재작업이 늘었다.
- 자동화의 처리시간은 줄었는데 전체 완료시간은 줄지 않는다.
마지막 경우에는 모델을 더 빠르게 바꾸기 전에 승인 대기, 시스템 입력, 예외 복귀 중 어디가 병목인지 확인해야 합니다. 처리 속도와 업무 완료 속도는 다른 지표입니다.
6. 예외를 먼저 설계하면 자동화 범위가 선명해진다
좋은 첫 자동화는 모든 건을 처리하려 하지 않습니다. 다음은 처음부터 수기 경로로 보내는 편이 좋은 대표 사례입니다.
- 필수 정보가 빠졌거나 서로 충돌하는 경우
- 권한 밖의 데이터나 민감한 첨부물이 있는 경우
- 새 정책·새 상품처럼 기준이 정리되지 않은 경우
- 결과가 고객·금액·계약 상태를 바꿔 추가 확인이 필요한 경우
- 연결 시스템이 실패하거나 로그를 남길 수 없는 경우
예외는 실패 횟수로만 보지 말고, 어떤 규칙을 바꾸면 줄일 수 있는지 분류하세요. 반복되는 입력 누락은 접수 양식을 고칠 문제일 수 있고, 승인 반려가 많은 경우는 모델보다 업무 기준을 먼저 고쳐야 할 수 있습니다.
예외별로 다음 행동을 정한다
예외 대기열은 “사람이 나중에 본다”는 뜻만으로는 충분하지 않습니다. 누가, 언제까지, 어떤 자료를 보고, 어느 상태로 되돌릴지 정해야 업무가 멈추지 않습니다.
| 예외 유형 | 즉시 행동 | 담당자 | 재발 방지 질문 |
|---|---|---|---|
| 필수 정보 누락 | 재요청 또는 수기 보완 | 접수 담당자 | 양식에서 미리 막을 수 있는가? |
| 낮은 신뢰도 | 자동 실행 중지, 원문 대조 | 업무 담당자 | 입력 범위가 너무 넓은가? |
| 정책 충돌 | 승인 보류, 정책 확인 | 업무 책임자 | 규칙을 명문화할 수 있는가? |
| 외부 시스템 실패 | 원래 방식으로 복귀 | 운영 담당자 | 재시도·중복 방지는 있는가? |
| 민감정보·권한 문제 | 접근 차단, 지정자에게 전달 | 권한 책임자 | 불필요한 입력을 제거할 수 있는가? |
예외율을 0으로 만드는 것은 목표가 아닙니다. 위험하거나 불완전한 건을 자동 경로에서 빠르게 분리하고, 반복되는 예외만 줄이는 것이 현실적인 목표입니다. 예외를 숨기면 파일럿의 성공률은 좋아 보일 수 있지만 실제 운영 비용은 오히려 커집니다.
7. 첫 2주에는 범위를 넓히지 않는다
초기 파일럿에서 바로 여러 팀·여러 데이터 원본을 붙이면 무엇이 개선되고 무엇이 깨졌는지 알기 어렵습니다. 첫 2주는 한 업무, 한 입력 채널, 한 승인자를 기준으로 관찰하세요.
| 기간 | 할 일 | 판단 기준 |
|---|---|---|
| 1주차 | 실제 입력을 모으고 예외를 분류 | 대상·제외 규칙이 현실과 맞는가 |
| 2주차 | 초안 생성과 사람 검토를 운영 | 수정·반려 사유가 반복되는가 |
| 3주차 | 입력 규칙·권한·체크리스트를 한 번 수정 | 변경 전후를 구분해 볼 수 있는가 |
| 4주차 | 계속·수정·중단을 결정 | 품질·안전·운영 부담을 함께 감당 가능한가 |
이 과정은 범용 인증이나 보편적 성공 공식이 아닙니다. 조직의 위험 허용 범위와 업무 책임자가 기준을 정해야 합니다. NIST Playbook도 제안 사항을 상황에 맞게 선택하는 자발적 참고자료로 설명합니다.[s5]
계속·수정·중단은 무엇으로 결정하나
파일럿을 끝낼 때는 “AI가 신기했는가”가 아니라 업무 결과와 통제가 나아졌는지로 판단합니다. 파일럿 전에 아래 세 갈래의 기준을 합의해 두면, 결과를 본 뒤에 유리한 기준만 고르는 일을 줄일 수 있습니다.
| 결정 | 볼 신호 | 다음 행동 |
|---|---|---|
| 계속 | 품질 가드레일을 지키며 담당자 부담이 줄어듦 | 같은 범위로 관찰 기간 연장 |
| 수정 | 특정 입력·승인·예외에서 병목이 반복됨 | 한 가지 원인을 고쳐 재측정 |
| 중단 | 회복하기 어려운 오류, 통제 실패, 감당 못 할 검토 부담 | 원래 방식으로 복귀하고 원인 기록 |
공통적인 성공률이나 시간 절감률을 목표로 삼지 마세요. 업무마다 오류 비용, 검토 난이도, 처리량, 고객 영향이 다릅니다. 대신 자동화 전 기준선과 비교할 수 있는 자체 지표를 남기고, 품질·안전에서 넘으면 안 되는 한계를 업무 책임자가 정해야 합니다.
도입 준비 체크리스트
- [ ] 자동화 대상과 제외 대상을 한 문장으로 설명할 수 있다.
- [ ] 허용 입력 형식, 필수 필드, 누락 시 경로가 정해져 있다.
- [ ] 자동화에 필요한 최소 읽기·쓰기·실행 권한을 분리했다.
- [ ] 사람 승인자가 결과를 고치거나 되돌릴 기준과 권한을 갖는다.
- [ ] 입력·결과·승인·예외·변경 시점을 업무 건별로 되짚을 수 있다.
- [ ] 예외가 발생하면 안전한 수기 경로로 넘길 수 있다.
- [ ] 확대 전에 1개 업무에서 수정·반려·예외를 검토했다.
다음 행동: 한 업무의 ‘운영 계약’을 작성하세요
파일럿을 시작하기 전 아래 빈칸을 팀과 함께 채워 보세요.
업무 이름:
자동화 대상 / 제외 대상:
허용 입력과 필수 정보:
AI가 하는 일 / 하지 않는 일:
읽기·쓰기·실행 권한:
승인자와 승인 기준:
예외와 수기 복귀 방법:
남길 기록과 보존 책임자:
첫 4주 뒤 계속·수정·중단 기준:Morrow의 4주 승인 기반 파일럿은 위 항목을 한 가지 반복 업무에 맞춰 점검합니다. 자동화 범위를 넓히기 전에 입력·출력·승인·복구 경계를 먼저 문서화하세요.
자주 묻는 질문
파일럿 전에 모든 데이터를 정리해야 하나요?
아닙니다. 첫 파일럿의 목적은 전사 데이터를 정비하는 것이 아니라 한 업무에 필요한 최소 입력과 예외를 확인하는 것입니다. 이미 신뢰할 수 있는 입력 채널 하나를 고르고, 그 밖의 자료는 수기 경로로 남겨 두세요. 범위를 줄이면 누락·권한·오류의 원인을 더 빨리 찾을 수 있습니다.
PDF나 이메일처럼 형식이 제각각이면 어떻게 하나요?
형식이 다른 자료를 모두 허용하지 말고, 업무 결과에 꼭 필요한 정보가 무엇인지 먼저 정합니다. 그 정보를 안정적으로 읽을 수 있는 형식만 자동 경로에 넣고, 나머지는 재제출 요청이나 수기 검토로 보냅니다. 파일 형식의 다양성은 모델 기능의 문제가 아니라 입력 계약과 예외 처리의 문제인 경우가 많습니다.
사람이 최종 승인하면 자동화 권한은 넓게 줘도 되나요?
그렇지 않습니다. 최종 승인이 있더라도, 자동화가 읽거나 기록할 수 있는 정보와 외부 시스템에서 실행할 수 있는 행동은 최소화해야 합니다. 특히 고객 통지, 금액, 권한, 계약 상태를 바꾸는 행동은 별도 승인과 되돌리기 방법을 함께 두는 편이 안전합니다.
검토자가 바쁜데 사람 검토가 실제로 가능할까요?
검토가 감당되지 않는다면 자동화 범위가 너무 넓거나 결과에 필요한 근거가 부족한 신호일 수 있습니다. 전 건 검토가 필요한 초기 단계에서는 대상 건수를 제한하고, 검토자가 확인할 항목을 짧은 체크리스트로 고정하세요. 검토 대기시간도 파일럿의 성과 지표로 기록해야 합니다.
로그에는 결과 원문을 전부 남겨야 하나요?
아닙니다. 추적에 필요한 업무 ID, 상태, 버전, 승인·수정·예외 사유와 시점부터 남기세요. 원문이나 개인정보를 복제해야 할 특별한 이유가 있다면 접근권한, 보존 기간, 마스킹 방식을 함께 정해야 합니다. 로그는 많이 쌓는 것보다 필요한 사람이 필요한 때 이해할 수 있는 것이 중요합니다.
언제 자동화를 넓혀도 되나요?
한 업무에서 입력 누락, 승인 반려, 예외, 복구의 반복 원인을 설명할 수 있고, 변경 전후의 결과를 분리해 볼 수 있을 때입니다. 처리량만 늘었다는 이유로 범위를 넓히지 말고, 업무 책임자가 품질·안전·운영 부담을 함께 검토해 결정하세요.
다음에 읽을 글
- 중소기업 AI 에이전트 도입, 무엇부터 자동화해야 할까? — 첫 후보 업무를 고르는 기준
- RPA와 AI 에이전트의 차이: 어떤 업무에 무엇을 선택해야 할까? — 기술 선택과 혼합 구조
- 중소기업 AI 자동화, 사람 승인과 실패 복구는 어떻게 설계해야 할까 — 승인·복구 경계 설계
- AI 업무 자동화 파일럿 KPI는 어떻게 정할까? — 파일럿 결과 측정
출처
- [s1] NIST AI Resource Center, 「AI RMF Playbook — Map」. https://airc.nist.gov/airmf-resources/playbook/map/ (접근일: 2026-07-29)
- [s2] NIST AI Resource Center, 「AI RMF Playbook — Govern」. https://airc.nist.gov/airmf-resources/playbook/govern/ (접근일: 2026-07-29)
- [s3] Information Commissioner's Office, 「About this guidance: Guidance on AI and data protection」. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/about-this-guidance/ (접근일: 2026-07-29)
- [s4] Information Commissioner's Office, 「Human review」. https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/artificial-intelligence/human-review/ (접근일: 2026-07-29)
- [s5] NIST AI Resource Center, 「AI RMF Playbook FAQ」. https://airc.nist.gov/airmf-resources/playbook/faq/ (접근일: 2026-07-29)
출처 사용 범위와 한계
이 글은 NIST·ICO의 위험 관리와 사람 검토 원칙을 한국 B2B 업무 자동화의 파일럿 준비에 적용한 Morrow의 실무 제안입니다. 법률·개인정보·보안 자문이나 보편적 인증 기준이 아니며, 각 조직은 적용 법령과 계약, 업무 위험을 별도로 검토해야 합니다.