AI 자동화 RACI 책임분장표, 장애·승인·변경의 최종 책임자를 정하는 기준
AI Agent와 업무자동화 운영에서 실행 담당, 최종 책임, 협의, 공유 대상을 RACI로 나눠 책임 공백을 줄이는 실무 체크리스트입니다.
AI Agent가 메일을 보내고 CRM을 수정하며 보고서를 만드는 데 성공해도 운영 책임자가 모호하면 자동화는 오래가지 못합니다. 오류가 나면 개발자는 업무 규칙을 모르고, 현업은 시스템을 멈출 권한이 없으며, 보안팀은 뒤늦게 상황을 알게 됩니다.
책임분장표는 ‘누가 참여하는가’를 적는 조직도가 아닙니다. 업무 범위, 권한 승인, 배포, 장애, 비용, 종료처럼 실제 결정을 누가 실행하고 최종 책임지는지 정하는 운영 장치입니다. RACI를 AI 자동화에 맞게 적용하는 방법을 정리했습니다.
핵심 요약
- 업무 전체에 책임자 한 명을 붙이지 말고, 승인·장애·변경·종료처럼 의사결정 상황별로 RACI를 나눕니다.
- R(실행)과 A(최종 책임)를 구분하고, 각 상황의 A는 원칙적으로 한 명 또는 한 역할로 정합니다.
- C(협의)는 결정 전에 의견을 주는 사람, I(공유)는 결정 후 상태를 알아야 하는 사람으로 구분합니다.
- 문서에 적힌 책임과 실제 시스템 권한, 승인 버튼, 알림 채널, 감사 로그가 서로 일치해야 합니다.
- 담당자 이름뿐 아니라 역할, 대리자, 응답시간, 검토 주기까지 남겨야 조직이 바뀌어도 작동합니다.
자동화가 스스로 실행할수록 책임이 사라지는 것이 아니라, 사람이 책임질 지점을 더 선명하게 정해야 합니다.
왜 AI 자동화는 기존 업무보다 책임 공백이 잘 생길까
일반적인 업무 시스템은 한 부서 안에서 입력과 승인이 끝나는 경우가 많습니다. 반면 AI Agent는 메일, 문서함, CRM, ERP, 메신저처럼 여러 시스템을 가로지르고, 결과를 만든 뒤 다음 작업까지 이어서 실행할 수 있습니다.
여기에 모델의 불확실성, 외부 API 장애, 재시도, 권한 만료가 겹치면 ‘누가 고칠 것인가’만으로는 부족합니다. 누가 멈추고, 누가 범위를 바꾸며, 누가 고객이나 경영진에게 설명할지까지 정해야 실제 운영이 가능합니다.
NIST AI RMF Playbook의 GOVERN 2는 AI 위험을 다루는 적절한 팀과 개인이 권한을 부여받고 책임을 지며 훈련되어야 한다고 설명합니다. Microsoft도 AI 시스템에 대한 사람의 책임과, 거버넌스에서 참여 팀의 역할·책임을 명확히 정의하는 것을 강조합니다.
RACI 네 글자를 AI 자동화 운영 언어로 바꾸기
RACI는 Responsible, Accountable, Consulted, Informed의 약자입니다. 글자보다 각 역할에 실제 권한과 행동 기준을 연결하는 일이 더 중요합니다.
R — 실행 담당자
설정, 모니터링, 예외 처리, 데이터 정리처럼 실제 작업을 수행합니다. 한 상황에 여러 명이 R이 될 수 있지만, 누가 먼저 받고 어디까지 처리한 뒤 넘기는지는 분명해야 합니다.
A — 최종 책임자
업무 범위, 운영 시작·중지, 예산, 롤백처럼 결과에 최종 답하는 역할입니다. 직급이 가장 높은 사람이 아니라 결과를 바꿀 권한과 책임을 함께 가진 사람이 맡아야 하며, 한 행의 A가 여러 명이면 결정이 늦어집니다.
C — 사전 협의 대상
결정 전에 전문 의견을 제공하는 현업, 보안, 개인정보, 법무, 데이터 담당자입니다. 모든 사람을 C로 넣으면 승인 회의가 늘어나므로, 해당 결정에 꼭 필요한 전문성만 남기는 편이 좋습니다.
I — 사후 공유 대상
결정이나 상태 변경을 알아야 하는 사용자, 고객지원, 경영진, 연관 부서입니다. I는 단순 참조가 아니라 언제 어떤 수준의 정보를 받을지 정하는 커뮤니케이션 책임입니다.
책임분장표에 반드시 넣을 7가지 운영 상황
한 장의 표를 만들 때는 부서명을 가로축에 놓기보다 실제로 판단이 필요한 상황을 세로축에 놓는 것이 좋습니다. 다음 일곱 가지부터 시작하면 운영 공백을 빠르게 찾을 수 있습니다.
1. 업무 범위와 성공 기준
자동화가 처리할 입력, 완료 조건, 제외 대상, 사람에게 넘길 조건을 정하는 단계입니다. 범위가 모호하면 개발은 끝났는데 현업은 쓸 수 없는 상태가 됩니다.
- R: 현업 분석 담당이 현재 흐름, 입력자료, 성공 조건, 예외 사례를 문서화합니다.
- A: 프로세스 오너가 자동화할 범위와 운영 전환 여부를 최종 승인합니다. 개발팀은 구현자가 될 수 있지만 업무 결과의 A를 대신하지 않습니다.
2. 데이터와 접근권한
서비스 계정, API 키, 문서함, 고객정보 접근 범위를 정합니다. 권한은 편의를 위해 넓게 주는 것이 아니라 업무 수행에 필요한 최소 범위로 설계해야 합니다.
- R: 시스템 관리자가 서비스 계정과 권한을 발급하고 만료일, 소유자, 사용처를 기록합니다.
- A: 데이터 또는 시스템 오너가 접근 범위를 승인하고, 보안·개인정보 담당자는 필요한 경우 C로 참여합니다.
3. 자동 실행과 사람 승인
초안 작성과 실제 발송, 조회와 수정, 추천과 결제처럼 위험도가 다른 행동을 구분합니다. 자동화 수준을 기술팀이 임의로 정하지 않도록 해야 합니다.
- R: 운영 담당자가 임계값, 승인 큐, 시간 제한, 자동 중지 조건을 설정합니다.
- A: 프로세스 오너가 자동 실행·사전 승인·사후 검토의 경계를 결정하고, 영향받는 사용자는 I로 지정합니다.
4. 장애·오답·예외 처리
오답, 중복 실행, 외부 API 장애, 권한 오류가 발생했을 때 최초 대응과 최종 의사결정을 나눕니다. 심각도별 대응시간과 전달 경로도 함께 적습니다.
- R: 온콜 또는 운영 담당자가 실행을 멈추고 재현 정보와 로그를 모아 예외 큐로 넘깁니다.
- A: 서비스 오너가 롤백, 재처리, 외부 안내 여부를 결정합니다. 중대한 보안 사고는 보안 책임자를 C가 아니라 별도 사고 체계의 A로 바꿀 수 있습니다.
5. 프롬프트·모델·연결도구 변경
작은 프롬프트 수정도 분류, 요약, 승인 판단을 바꿀 수 있습니다. 무엇을 바꿨는지와 어떤 회귀 테스트를 통과했는지 기록해야 합니다.
- R: 제작 담당자가 변경 이유, 버전, 테스트 결과, 롤백 방법을 준비합니다.
- A: 변경 책임자가 배포 여부를 승인하고, 현업·보안·데이터 담당자는 영향에 따라 C로 참여합니다.
6. 비용·사용량·성과 검토
토큰 비용, 외부 API 호출, 자동화 성공률, 사람 재작업 시간을 함께 봅니다. 비용만 줄이거나 실행 횟수만 늘리면 업무 성과와 멀어질 수 있습니다.
- R: 운영 담당자가 사용량, 실패, 예외, 재작업, 비용 지표를 정기적으로 정리합니다.
- A: 서비스 오너나 스폰서가 예산과 자동화 범위를 조정하며, 재무·현업 담당자는 필요한 판단 자료를 제공하는 C가 됩니다.
7. 서비스 종료와 권한 회수
프로젝트가 끝나거나 도구를 교체할 때 API 키, 스케줄, 웹훅, 서비스 계정이 남지 않도록 종료 책임도 미리 지정합니다.
- R: 시스템 관리자가 키와 계정을 회수하고 예약 작업을 중지하며, 보존 정책에 따라 로그와 결과물을 정리합니다.
- A: 시스템 또는 프로세스 오너가 종료 완료를 확인하고, 데이터·개인정보 담당자는 보존과 삭제 기준에 관해 C로 참여합니다.
한 장짜리 책임분장표를 만드는 순서
- 조직도보다 먼저 ‘범위 승인, 권한 발급, 배포, 장애, 비용 초과, 종료’처럼 실제 결정과 사고 상황을 적습니다.
- 각 상황을 한 행으로 두고, 실행 담당 R과 최종 책임 A를 먼저 정합니다. A는 가능하면 한 역할만 둡니다.
- 결정 전에 반드시 의견을 들어야 하는 C와, 결정 후 상태를 받아야 하는 I를 최소한으로 추가합니다.
- 이름 옆에 역할, 대리자, 응답시간, 승인 위치, 로그·문서 링크를 붙여 실제 행동으로 이어지게 만듭니다.
- 가상의 장애와 담당자 부재 상황을 놓고 표대로 연락·중지·복구가 되는지 시험한 뒤, 조직과 시스템이 바뀔 때 갱신합니다.
책임분장표가 작동하지 않는 흔한 이유
A가 여러 명이라 모두의 동의가 필요하다
공동 책임은 실제 상황에서 책임 공백이 되기 쉽습니다. 의견이 필요한 사람은 C로 옮기고, 최종 결정권을 가진 A를 한 역할로 정합니다.
조직도를 그대로 복사한다
부서가 참여한다는 사실만으로는 장애 때 누가 중지 버튼을 누르는지 알 수 없습니다. 부서명이 아니라 구체적인 결정과 행동을 기준으로 행을 나눕니다.
담당자 이름만 있고 대리자가 없다
휴가, 퇴사, 조직개편이 생기면 표가 바로 무효가 됩니다. 개인 이름과 함께 역할명, 대리 역할, 연락 채널, 인수인계 기준을 남깁니다.
문서와 실제 시스템 권한이 다르다
A로 적힌 사람이 승인 버튼이나 중지 권한을 갖고 있지 않다면 책임분장은 선언에 그칩니다. 시스템 권한, 알림, 승인 로그를 표와 함께 점검해야 합니다.
AI 자동화 RACI 실무 체크리스트
- 자동화 범위와 운영 전환을 최종 승인하는 A가 한 역할로 정해져 있다.
- 데이터·시스템 접근권한의 발급 담당과 승인 책임이 분리되어 있다.
- 자동 실행, 사전 승인, 사후 검토의 경계를 누가 결정하는지 적혀 있다.
- 오답·중복 실행·외부 API 장애 때 최초 대응 R과 최종 결정 A가 다르게 표시되어 있다.
- 프롬프트·모델·연결도구 변경에 테스트, 승인, 롤백 책임이 있다.
- 비용 초과와 성과 저하 때 자동화 범위를 조정할 책임자가 있다.
- 서비스 종료 시 키, 계정, 웹훅, 스케줄, 데이터 정리 책임이 있다.
- 모든 핵심 역할에 대리자와 응답시간, 연락 채널이 있다.
- RACI 문서와 실제 권한·승인 화면·알림·감사 로그가 일치한다.
- 조직개편, 시스템 변경, 중대한 사고 후 책임분장표를 다시 검토한다.
자주 묻는 질문
Q. 작은 팀도 RACI가 필요한가요?
필요합니다. 한 사람이 여러 역할을 맡아도 괜찮지만, 지금 어떤 모자로 결정하는지는 구분해야 합니다. 최소한 범위 승인, 권한, 장애, 변경, 종료의 A만 정해도 책임 공백이 크게 줄어듭니다.
Q. 승인 매트릭스가 있으면 RACI는 없어도 되나요?
서로 역할이 다릅니다. 승인 매트릭스는 어떤 업무를 자동 실행·사전 승인·사후 검토로 나눌지 정하고, RACI는 그 기준을 누가 만들고 실행하며 바꿀지 배정합니다. 두 문서는 연결되어야 합니다.
Q. 외부 개발사나 솔루션사가 A를 맡아도 되나요?
구현과 기술 장애 대응의 R은 외부 파트너가 맡을 수 있습니다. 다만 업무 결과, 고객 데이터, 예산, 운영 지속 여부에 대한 A는 보통 조직 내부의 프로세스·시스템 오너에게 남겨야 합니다. 계약에는 대응시간과 전달 경로를 구체적으로 적습니다.
Q. 책임분장표는 얼마나 자주 검토해야 하나요?
정해진 주기만 기다리기보다 조직개편, 담당자 변경, 신규 시스템 연결, 권한 확대, 중대한 장애가 생길 때 바로 검토합니다. 별도 변화가 없더라도 분기 단위로 연락처와 실제 권한이 맞는지 가볍게 확인하는 방식이 실무적입니다.
HeyRatty로 책임 있는 자동화 운영을 시작하려면
HeyRatty는 자동화 대상 업무를 정리할 때 RACI만 따로 만들지 않습니다. 실제 권한, 사람 승인, 예외 큐, 변경 이력, 운영 로그까지 연결해 누가 언제 무엇을 결정할지 한 흐름으로 설계합니다.
전사 표부터 만들 필요는 없습니다. 고객 메일, 문서 승인, CRM 업데이트처럼 영향이 큰 자동화 한 가지를 골라 책임분장표와 장애 시나리오를 먼저 점검해보세요. 현재 업무 흐름이 복잡하다면 HeyRatty가 작은 파일럿 범위부터 함께 정리할 수 있습니다.
참고 및 이미지 출처
- NIST AI RMF Playbook — GOVERN
- Microsoft Responsible AI — Principles and approach
- 이미지 원본: Wikimedia Commons 「Collaborative Design and Integration Studio.jpg」 · 저작자 Mwooten86 · CC BY-SA 4.0 · Commons API가 제공한 1920px JPEG 썸네일 URL을 직접 사용했습니다. 로컬 생성 이미지 0장.