AI 자동화를 팀에 붙이기 전, 먼저 정해야 할 4가지

먼저, 이런 도구가 무엇인지부터

OpenClaw는 반복되는 일을 사람 대신 처리하도록 설정하는 AI 에이전트 도구다. 메일함을 훑어 정리하거나, 자료를 모아 초안을 만들거나, 정해진 시각마다 상태를 점검하는 식의 일을 맡긴다. 설정 문서에는 접근 권한과 노출 범위를 다루는 Security, 명령을 실행하기 전에 사람 확인을 받는 Approvals, 정해진 주기로 작업을 돌리는 Heartbeat 같은 항목이 있다.

여기서 가장 흔한 오해는 도구를 먼저 붙이면 운영 방식도 따라 정리될 것이라는 기대다. 실제로는 반대다. 신뢰 경계와 승인 구조를 먼저 적어두지 않으면, 잘 돌아가는 자동화일수록 팀을 더 불안하게 만든다. 고객 명단, 거래처 견적, 미공개 예산, 대외로 나가는 공식 문서처럼 다루기 조심스러운 자료가 업무에 섞여 있다면 더 그렇다. 그래서 이 도구를 개인 보조 수준으로 쓸지, 팀 운영 구조 안으로 들일지부터 구분해야 한다.

참고로 공식 Approvals 문서가 다루는 것은 주로 컴퓨터에서 명령을 실행할 때 사람 확인을 받는 방식이다. 삭제·발송·결제까지 승인 대상으로 넓히는 것은 문서가 요구하는 규칙은 아니다. 아래 네 가지도 공식 요구사항이 아니라 운영 권고로 읽으면 된다. 기능 설명이 아니라 운영 설계다.

1. 개인 보조와 팀 운영의 경계를 나눠라

개인 노트 정리, 초안 작성, 회의 준비처럼 담당자 한 명의 보조로 쓰는 경우와, 팀 채널에서 여러 사람이 같은 결과를 보는 경우는 책임 구조가 다르다. 전자는 실험에 가깝지만, 후자는 조직 운영이다.

후자라면 세 가지를 먼저 정해야 한다. 누가 소유하는가, 누가 마지막 검토자인가, 문제가 생기면 누가 중단시키는가. 여러 사람이 함께 쓰는 공용 메일함, 대표 문의 계정, 팀 공식 채널은 특히 주의해야 한다. 겉으로는 편해 보이지만, 책임자 없는 자동화가 가장 쉽게 사고를 만든다.

개인 보조는 개인 계정과 개인 맥락 안에 두고, 팀 운영은 공용 채널이라 하더라도 승인자와 점검자를 함께 둔다.

2. 승인 정책은 액션별로 적어야 한다

"중요한 건 사람이 확인한다"는 문장은 원칙처럼 들리지만 실무에서는 너무 모호하다. 사람마다 무엇이 중요한지가 다르기 때문이다. 액션별로 나눠 적어야 팀이 같은 판단을 한다.

초안 작성: 자동 허용
내부 요약: 자동 허용
외부 게시물 초안 생성: 허용
외부 발송: 승인 필요
삭제, 결제: 승인 필수

삭제·발송·게시·결제처럼 되돌리기 어렵거나 외부 신뢰에 영향을 주는 작업은 승인 필수 쪽에 두는 편이 맞다. 속도가 조금 느려져도 괜찮다. 자동화 운영에서 가장 위험한 순간은 처음엔 편하려고 자동화했는데 어느 순간 누가 마지막 책임자인지 모르게 되는 때다.

3. 팀 채널과 개인 알림 채널은 분리해야 한다

승인 요청, 실패 로그, 정기 점검 결과, 단순 진행 알림을 전부 하나의 팀 채널에 보내면 처음 며칠은 활발해 보여도 금방 피로가 쌓인다. 중요한 신호가 묻히고, 담당자가 봐야 할 메시지를 모두가 흘려보내기 시작한다.

판별 기준은 하나면 충분하다. 결정이 필요한가. 결정이 필요하면 팀 채널, 먼저 상태를 확인하면 되는 일은 개인 알림 채널.

팀 채널: 승인 요청, 장애 공지, 운영 상태 공유, 팀 전체가 알아야 할 경고
개인 알림 채널: 정기 점검 결과, 실패 로그, 재시도 알림, 검토 대기 알림

승인 요청과 정기 점검 결과는 둘 다 자동으로 생성되기 때문에 비슷해 보이지만 성격이 완전히 다르다. 승인 요청은 누군가가 보고 예 또는 아니오를 정해야 하는 신호이고, 점검 결과는 상태 관찰에 가깝다. 이 둘을 같은 채널에 놓으면 승인 요청이 로그에 묻히거나, 반대로 작은 상태 변화가 팀 전체를 계속 방해한다.

텔레그램처럼 담당자 개인이 빠르게 확인하는 채널은 조용하지만 즉시 봐야 하는 신호에 잘 맞는다. 채널을 나누는 목적은 보기 좋게 정리하려는 것이 아니라 책임 경계를 분명히 하는 것이다.

4. 정기 실행은 범위를 넓히는 도구가 아니라 좁히는 기준이다

Heartbeat로 정기 점검과 상태 확인을 구조화할 수 있다. 하지만 이것이 정기적으로 하던 모든 일을 자동으로 돌려도 된다는 뜻은 아니다. 오히려 어떤 업무를 정기 실행 아래 두고 어떤 업무는 두지 않을지 결정하는 기준으로 쓰는 편이 낫다.

정기 실행에 잘 맞는 일: 데이터 수집 상태 점검, 대기열 적체 확인, 실패 로그 알림, 누락 항목 점검.

빼는 편이 안전한 일: 고객 대상 발송, 외부 게시물 자동 업로드, 개인정보가 든 자료의 재처리.

정기 실행은 편리하다. 편리할수록 "정기적으로 돌아가니까 괜찮다"는 착시가 생기고, 그래서 승인 구조가 더 중요해진다.

참고 사례: 뉴스 큐레이션을 혼자 돌리는 팀

한 사람이 하루 18종 안팎의 입력을 받아 뉴스와 공고를 정리하는 팀이 있다. 이 구조가 무너지지 않는 이유는 자동화 범위가 넓어서가 아니라, 수집·초안·검토·발행을 분리해 뒀기 때문이다.

입력은 넓게, 발행은 좁게. 들어오는 경로는 여럿이지만 바로 게시하지 않고 초안과 후보 대기열을 먼저 만든다. "수집 성공"과 "발행 가능"을 같은 일로 보는 순간 자동화는 무너진다. 입력이 많아질수록 필요한 능력은 많이 모으는 쪽이 아니라 버릴 것을 빨리 버리는 쪽이다.

보는 숫자는 토큰이 아니라 처리량과 검토 시간. 이 팀이 확인하는 지표는 하루 처리한 입력 건수, 검토에 걸리는 평균 시간, 발행 후보로 남는 비율, 사람이 다시 손본 건수다. "하루 18종"은 출발점일 뿐이고, 그중 몇 건이 검토할 가치가 있었는지와 사람이 직접 찾는 시간이 얼마나 줄었는지가 실제 판단 근거가 된다.

팀 문서에 적을 메모 네 줄

작은 팀이라면 긴 매뉴얼보다 네 줄이면 충분하다.

이 자동화는 누구를 돕는가
무엇을 읽고 무엇을 출력하는가
어느 단계에서 사람 승인이 필요한가
문제가 생기면 어디서 멈추는가

여기에 한 줄만 더 붙이면 좋다. 실패 로그를 먼저 볼 사람이 정해져 있는가. 자동화 운영에서는 성공 메시지보다 실패 로그와 예외 처리가 더 중요하다. 이 역할이 비어 있으면 자동화 건수는 늘어도 신뢰는 떨어진다.

설치는 하루면 끝난다. 승인 구조와 채널 설계는 그 팀의 일하는 방식을 그대로 드러낸다.