두세 명이 운영하는 팀에 메일, 문의, 알림과 문서가 기계 속도로 들어오면 가장 먼저 무너지는 일은 처리보다 분류입니다. 무엇을 먼저 보고 무엇을 미룰지 정하는 데 사람의 하루가 소진됩니다.
2~5인 팀이 기계 속도의 업무를 감당하려면 모든 건을 사람이 승인하는 방식을 버리고, 되돌릴 수 있는 일은 미리 정한 규칙으로 처리해야 합니다. 사람은 위험한 예외와 복구가 어려운 결정에 집중하고 자동화 계정도 직원처럼 관리해야 합니다.
이 문제는 대학 보안팀 사례에서 선명하게 보입니다. CDW의 Field CISO인 Aaron McCray는 EdTech Magazine 기고에서 지역 공립대의 보안팀이 흔히 2~5명이며, 각종 보안 도구가 보내는 신호를 전부 수동 분류할 수 없다고 설명했습니다. 글은 보안 업계 공급자 관점의 조언이지만, 작은 팀의 분류 병목을 이해하는 데는 유용합니다.
작은 팀의 병목은 ‘앞쪽만 보는 습관’이다
업무량이 사람의 속도로 늘 때는 중요한 일부터 보는 방식이 버틸 수 있습니다. 유입이 자동화되면 상황이 달라집니다. 앞의 10%만 보는 동안 뒤쪽 더미도 기계가 계속 늘립니다. 사람이 보지 못한 구간에 어떤 일이 있었는지조차 알 수 없습니다.
보안 경보를 일반 업무로 옮기면 익숙한 장면이 나옵니다.
| 유입 경로 | 사람이 하던 분류 | 양이 급증했을 때 생기는 문제 |
|---|---|---|
| 고객 문의 | 받은 순서와 제목으로 우선순위 판단 | 이탈 가능성이 큰 문의가 단순 질문 사이에 묻힘 |
| 영업 리드 | 담당자가 회사를 검색해 적합도 판정 | 답변이 늦어지고 선별 기준이 사람마다 달라짐 |
| 채용 지원서 | 앞에서부터 읽고 후보 표시 | 지원 순서가 사실상 평가 기준이 됨 |
| 운영 알림 | 심각해 보이는 항목부터 확인 | 반복 오탐 때문에 실제 이상도 함께 무시됨 |
자동화의 첫 대상은 최종 업무가 아니라 이 분류 과정입니다. 입력을 모으고 필요한 맥락을 붙이며, 명확한 규칙으로 낮은 위험의 항목을 정리하면 사람이 읽어야 할 양이 줄어듭니다.
사람의 판단을 건마다 받지 않는다
McCray가 소개한 보안 운영 방식은 저위험 경보를 자동으로 종결하거나 뒤로 보내고, 과거 티켓과 데이터를 붙여 맥락을 보강하며, 위험한 대응은 사람이 결정하는 구조입니다. 에이전트가 대응 플레이북을 작성해도 선임 책임자가 저위험·고효용 규칙을 먼저 승인합니다.
작은 팀에 필요한 변화는 사람을 빼는 것이 아니라 사람의 판단 시점을 옮기는 것입니다.
| 처리 단계 | AI가 하는 일 | 사람이 개입하는 지점 |
|---|---|---|
| 자동 분류 | 태그, 중복 제거, 낮은 위험 항목 정리 | 기준을 만들고 정기적으로 표본 점검 |
| 맥락 보강 | 과거 기록과 관련 자료를 찾아 한곳에 제시 | 건별 결론을 사람이 판단 |
| 사전 승인 실행 | 승인된 조건 안에서 정해진 행동 수행 | 규칙을 만들 때 한 번 승인 |
| 위험한 예외 | 영향도와 선택지를 정리 | 건마다 직접 승인하거나 중단 |
하루 1,000건을 승인하는 것은 불가능해도 30개의 처리 규칙은 검토할 수 있습니다. 규칙에는 입력 조건, 허용 행동, 결과 확인 방법과 멈추는 조건이 들어가야 합니다. ‘AI가 알아서 처리’는 규칙이 아닙니다.
자동화 기준은 중요도가 아니라 가역성으로 잡는다
모든 부서는 자기 업무가 중요하다고 말합니다. 그래서 중요도만으로 자동화 범위를 정하면 합의가 나지 않습니다. 되돌릴 수 있는지를 기준으로 삼으면 경계가 구체적으로 보입니다.
- 즉시 되돌릴 수 있음: 태그 지정, 분류, 요약, 초안 생성은 자동 처리 후보
- 되돌릴 수 있지만 비용이 큼: 일정 확정, 고객 상태 변경, 외부 발송은 사전 승인 규칙 적용
- 되돌리기 어려움: 결제, 삭제, 계약 해지, 운영 시스템 재시작은 사람의 건별 승인 유지
메일을 잘못 분류하면 태그를 바꾸면 됩니다. 고객에게 잘못된 계약 조건을 발송한 뒤에는 취소 메일만으로 원상복구되지 않습니다. 기술적으로 자동화할 수 있는지보다 잘못됐을 때 얼마나 복구하기 어려운지가 먼저입니다.
AI 에이전트 비상 브레이크에서 설명한 권한 회수 절차도 이 구분 위에서 만들어집니다. 자동화가 멈춰야 할 조건을 정하려면 어떤 행동이 조직 밖에 흔적을 남기는지 알아야 합니다.
문서가 아니라 화요일 오후의 행동을 바꾼다
McCray는 많은 대학이 정책을 쓰는 ‘거버넌스 모드’에 머물러 있다고 지적했습니다. 정책은 필요하지만 실제 업무 흐름과 연결되지 않으면 바쁜 날 건너뛰게 됩니다.
NIST AI 위험관리 프레임워크는 AI 시스템 목록, 명확한 역할과 책임, 구체적인 사용 범위, 사람의 감독 방식과 운영 중 모니터링을 문서화하도록 제안합니다. 작은 조직에서는 이를 거대한 위원회로 시작할 필요가 없습니다. 업무 하나에 대해 다음 여섯 칸을 채우면 됩니다.
- 어떤 입력이 들어오는가
- AI가 어디까지 분류하거나 실행하는가
- 사람에게 보내는 예외는 무엇인가
- 외부에 영향을 주기 전 누가 승인하는가
- 오류가 났을 때 어떤 권한을 끊는가
- 누가 정상화를 확인하고 다시 켜는가
이 문서가 실제 처리 화면과 연결돼야 합니다. 예를 들어 외부 발송이 필요한 항목은 승인함으로 자동 이동하고, 승인 전에는 발송 버튼을 호출할 수 없게 만드는 식입니다.
비인간 계정도 입사와 퇴사를 관리한다
자동화를 하나 추가할 때마다 API 키, 서비스 계정이나 봇 계정이 생깁니다. 사람 계정에는 입사일과 퇴사일이 있지만 자동화 계정은 프로젝트가 끝난 뒤에도 남기 쉽습니다.
CDW의 2026년 보안 조사는 950명 이상의 IT·보안 리더를 조사했고, 복잡한 IT·클라우드 환경이 위험을 수량화하기 어렵게 만드는 가장 큰 장애라고 답한 비율이 46%였습니다. 이 수치를 소규모 팀에 그대로 적용할 수는 없지만, 연결과 계정이 늘수록 무엇이 어디에 접근하는지 파악하기 어려워진다는 문제는 같습니다.
최소한 다음 항목을 한 표에 모아야 합니다.
- 계정 이름과 담당자
- 사용하는 업무와 접근 시스템
- 읽기·쓰기·삭제 권한
- 발급일과 마지막 사용일
- 점검일과 폐기 조건
이 명부가 없으면 담당자가 떠나거나 도구를 바꿔도 권한이 남습니다. 승인되지 않은 자동화가 회사 업무에 스며드는 섀도우 오퍼레이션도 이런 빈틈에서 시작됩니다.
2~5인 팀은 큰 조직처럼 모든 건을 사람이 검토할 수 없습니다. 대신 규칙을 적게 만들고, 되돌릴 수 있는 일에만 자동 실행을 허용하며, 예외를 한곳으로 모을 수 있습니다. 이번 주에 할 첫 작업은 자동화 도구를 추가하는 일이 아닙니다. 아무도 전체를 보지 않는 입력함 하나를 고르고, 사람이 반드시 봐야 할 예외 세 가지를 적는 일입니다.
