AI 에이전트 역할 분담을 정한 기록

혼자 여러 사업을 운영하면 결정은 누구에게 쌓이나

여러 사업을 혼자 운영하다 보면 전략 판단이든 사소한 승인이든 전부 대표 한 사람 앞으로 모입니다. 문제는 결정 자체가 아니라, 그 결정들이 어디에 쌓여 있는지 기록하는 자리가 없었다는 점이었습니다. 무엇을 결정해야 하는지는 대표 머릿속에만 있었고, 다음 사업으로 넘어가면 그 기억은 같이 넘어가지 않았습니다.

이미 돌고 있는 자동화도 있었습니다. 정해진 시각마다 실행되는 예약 작업 11개와, 그 작업을 돌리는 스크립트 12개였습니다. 그런데 이 자동화 묶음 중 무엇이 누구 책임인지 적어 둔 자리가 없었습니다. 문제가 생기면 그때마다 누가 고칠지부터 다시 정해야 했고, 같은 종류의 결정이 반복될 때마다 매번 처음부터 판단해야 했습니다.

예를 들어 콘텐츠 발행 승인처럼 반복되는 결정도 매번 대표가 새로 판단해야 했습니다. 어제 승인한 기준과 오늘 판단이 같은지조차 확인할 자리가 없었기 때문입니다. 판단 자체는 몇 초면 끝나지만, 그 판단을 어디에도 남기지 않아 다음번에도 똑같은 몇 초를 다시 써야 했습니다.

역할을 나눠 이 문제를 풀어보자는 결정을 내리기 전, 다섯 개 최상위 자리(전략·운영·기술·제품 각 담당과 대표 본인)와 제품 담당 아래 세 자리(디자이너·품질검증·마케팅)를 후보로 올렸습니다. 합쳐서 여덟 자리였습니다.

역할 이름을 정하는 일 자체는 어렵지 않았습니다. 어려운 지점은 그 여덟 자리 사이에서 누가 무엇을 스스로 결정하고, 무엇을 대표에게 확인받아야 하는지를 규칙으로 못 박는 일이었습니다. 이름만 붙이고 끝내면 지금까지와 똑같이 결정이 대표 앞에만 쌓일 자리였습니다.

역할 수조차 정확하지 않았다는 점도 문제를 키웠습니다. 이전까지 참고하던 상위 지침 문서 제목에는 역할 규모가 '5개 이상'이라고만 적혀 있었습니다. 다섯 자리는 확실하고 그 아래 몇 자리가 더 있는지는 문서 제목만으로는 알 수 없었다는 뜻입니다. 정확한 개수를 세는 일부터가 이번 작업의 출발점이었습니다.

처음 잰 숫자 — 632줄짜리 문서와 결정 15건

표를 그리기 전에 지금 상태부터 재 두었습니다. 이미 있던 상위 지침 문서는 632줄이었고, 그 문서 안에 흩어져 있던 결정 후보는 15건이었습니다. 자동화 예약 작업은 11개, 그 작업을 돌리는 스크립트는 12개였습니다.

숫자 넷 중 셋(632줄·15건·11개)은 이미 있던 것을 세기만 하면 나오는 값이었습니다. 남은 문제는 이 넷을 어떻게 정리해야 결정이 대표 한 사람에게만 계속 쌓이지 않는가였습니다. 넷 다 코드 계측이 아니라 문서와 자산 목록을 직접 세어 나온 값이고, 뒤에 나오는 재측정 값도 같은 방식으로 다시 셌습니다.

632줄 문서에서 뽑아낸 역할 여덟 개도 이 시점에 한 줄 정체까지 확정했습니다. 이름만 있고 역할이 모호하면 또 같은 문제가 반복되기 때문입니다.

표를 그려 보면 대표 아래 전략·운영·기술 세 갈래가 나뉘고, 운영 아래에 다시 제품이, 제품 아래에 디자이너·품질검증·마케팅이 달리는 모양이었습니다. 재무 담당은 아직 조건이 오지 않아 점선으로만 비워 뒀습니다 — 매출이 생기거나 누적 고정비가 일정 액수를 넘는 시점 중 먼저 오는 쪽이 그 점선을 실선으로 바꾸는 신호입니다.

표 하나만 그리면 끝날 것이라는 가설

처음 세운 가설은 단순했습니다. 여덟 자리를 그린 조직표 한 장과, 각 자리의 역할을 한 줄로 적은 표만 있으면 충분하다고 봤습니다. 새로운 자동화를 더 만들 필요 없이, 지금 흩어져 있는 632줄 문서를 표 형태로 압축하기만 하면 15건의 결정도 자연스럽게 각 역할 앞으로 정리될 것이라는 가설이었습니다.

이 가설이 맞다면 할 일은 문서 압축뿐이었습니다. 어느 역할이 무엇을 스스로 결정하고 어느 선에서 대표에게 확인받아야 하는지도 그 표 안에 한 칸씩 적어 넣으면 끝나는 일이었습니다. 자동화 11개나 스크립트 12개를 손댈 이유는 없어 보였습니다.

역할별 한 줄 정체까지 이미 정리해 둔 상태였으니 근거도 충분해 보였습니다. 운영 담당의 학습 루프가 5개 층으로 나뉜다는 것까지 적어 뒀는데, 그 위에 결정 권한 한 줄만 더 얹으면 표가 곧 규칙이 될 것이라고 판단했습니다.

결정 15건 중 6건은 왜 그 자리에서 다시 고쳐졌나

표를 그려 놓고 실제 결정 15건에 하나씩 대입해 보니, 그 자리에서 안이 바뀐 항목이 여섯 건 나왔습니다. 15건 가운데 6건, 40%였습니다. 표만 그려서 끝날 일이 아니었다는 뜻이었습니다.

• 보고선 — 운영 담당이 대표 직속인 줄 알았는데, 전략 담당이 대표 직속이어야 한다는 쪽으로 고쳐졌습니다.
• 재무 담당을 부르는 조건 — 매출이 생기는 시점과 누적 고정비가 일정 액수를 넘는 시점 중 어느 쪽이 먼저인지를 다시 정했습니다.
• 자동화 담당자 지정 — 콘텐츠·발송·광고·응답은 마케팅 담당, 버그 처리는 품질검증 담당, 약관은 전략 담당으로 한 사람씩 못 박는 쪽으로 고쳤습니다.
• 실행 방식 — 새 메신저 봇을 따로 만들지 않고, 이미 쓰던 봇에 명령 두 개만 얹는 쪽으로 방향을 바꿨습니다.
• 권한 분류 — 스스로 결정하는 범위를 처음보다 넓게 잡고, 4주 뒤에 다시 조정하기로 했습니다.
• 전략 보고 방식 — 정기 보고문을 별도 문서로 빼고, 보내는 빈도에 상한을 두는 쪽으로 바꿨습니다.

재무 담당을 부르는 조건을 고친 이유도 비슷했습니다. 처음에는 두 조건 중 아무거나 먼저 걸리면 그대로 적을 생각이었는데, 실제로 적어 보니 '두 조건 중 먼저 오는 쪽'이라는 단어를 안 넣으면 둘이 동시에 다가올 때 기준이 사라진다는 점이 드러났습니다.

실행 방식을 고친 이유는 더 단순했습니다. 새 봇을 따로 만들면 그 봇을 배포하고 권한을 새로 여는 작업까지 통째로 늘어나는데, 이미 쓰던 봇에 명령 두 개만 얹으면 그 작업 전체가 필요 없었습니다.

여섯 건 모두 같은 자리, 같은 날 안에서 바뀌었습니다. 처음 적어 낸 안이 전부 틀렸다는 뜻은 아니지만, 표에 이름과 역할만 적어서는 실제 결정 앞에서 절반 가까이가 버티지 못했다는 뜻이었습니다.

진짜 빠져 있던 것은 역할표가 아니라 목록이었다

여섯 건을 하나씩 다시 보니 원인은 한 곳으로 모였습니다. 역할 이름이 없어서가 아니라, 결정 하나가 나왔을 때 그걸 어디에 적어 두고 누구에게 넘길지 정하는 자리가 없었다는 점이었습니다.

보고선이 틀렸던 이유도 같은 결입니다. 운영 담당을 대표 직속으로 두면, 전략에서 나온 제안이 운영을 한 번 거친 뒤에야 대표에게 닿습니다. 중간에서 내용이 옅어지거나 늦어질 자리가 하나 더 생기는 구조였습니다.

자동화 담당자를 못 박지 못했던 이유도 마찬가지였습니다. 예약 작업 11개 중 어떤 것이 콘텐츠 쪽이고 어떤 것이 버그 처리 쪽인지 나눈 적이 없었을 뿐, 역할 이름을 새로 만든다고 그 구분이 저절로 생기지는 않았습니다.

그러니까 필요했던 건 조직표가 아니라, 결정 하나마다 번호를 붙이고 받는 사람을 적어 두는 목록 하나, 그리고 이미 있는 예약 작업 11개 각각에 담당자 이름 하나씩을 붙이는 일이었습니다.

그 목록이 실제로 어떻게 도는지도 이번에 일곱 단계로 적어 뒀습니다. 표에는 없던 부분이라, 결정 하나가 태어나서 처리되기까지의 경로를 처음으로 글로 남긴 셈입니다.

• 1단계 — 바깥에서 신호가 들어온다(메시지 회신, 매출 변화, 발송 회신 등).
• 2단계 — 운영 담당이 먼저 받아 어느 역할이 처리할지 분류한다.
• 3단계 — 해당 결정을 번호와 받는 사람을 붙여 목록에 적는다. 즉시 처리 가능하면 그 자리에서 바로 처리한다.
• 4단계 — 담당 역할이 처리한 결과를 운영 담당의 보고문에 반영한다.
• 5단계 — 매일 정해진 시각에 대표에게 보고문을 보낸다.
• 6단계 — 대표가 확인이 필요한 항목만 승인·반려로 답한다.
• 7단계 — 운영 담당이 위임한 결과를 추적해 다음 보고문에 다시 반영한다.

이 일곱 단계 중 3단계('번호와 받는 사람을 붙여 목록에 적는다')가 이전까지 통째로 빠져 있던 자리였습니다. 나머지 여섯 단계는 사람이 머릿속으로 대략 하고는 있었지만, 3단계가 없으니 같은 결정이 두 번 올라오거나 아예 잊히는 경우가 생겼습니다.

역할·목록·보고선을 같은 날 함께 고쳤다

그래서 이번 주기에 바로 처리한 항목과, 다음 단계로 미룬 항목을 나눴습니다.

• 마케팅을 전담하는 역할 1개를 새로 만들었습니다 — 콘텐츠·발송·광고·브랜드 문구를 한 사람 몫으로 묶었습니다.
• 결정 하나마다 번호와 받는 사람을 적는 목록을 새로 만들었습니다.
• 이미 쓰던 메신저 봇에 결정 목록을 확인하고 승인·반려로 답하는 명령 두 개를 추가했습니다.
• 보고선을 정정해, 전략 담당이 운영 담당을 거치지 않고 대표에게 바로 보고하도록 바꿨습니다.
• 매출 추적 문서에 사업별 손익 자리를 미리 만들어 뒀습니다.
• 재무 담당을 부르는 조건을 매출 발생 또는 누적 고정비 50달러 중 먼저 오는 쪽으로 확정했습니다.

미룬 항목도 그대로 적어 둡니다. 전략 담당의 새 주간 점검 예약, 전략 보고문의 별도 발송 방식, 마케팅 발송 승인 절차, 대표 보고문을 다섯 역할별로 나누는 작업까지 네 건은 이번 주기가 아니라 이후 단계로 넘겼습니다. 15건 중 4건이 이번 주기가 아니라 이후 단계로 넘어갔습니다.

역할끼리 결정이 부딪힐 때 누구 말을 따를지도 이번에 같이 정했습니다. 먼저 운영 담당이 문제를 위로 올리고, 그다음 전략 담당이 세워 둔 틀을 적용해 보고, 그래도 안 풀리면 대표가 직접 정합니다. 이 순서를 정해 두지 않았다면 여섯 건의 정정 중 일부는 또 누구 의견이 맞는지부터 다시 다투는 자리가 됐을 것입니다.

앞서 예로 든 콘텐츠 발행 승인도 같은 목록으로 옮겼습니다. 이제는 마케팅 담당이 정한 기준대로 반복 승인이 스스로 처리되고, 그 기준을 벗어난 건만 목록을 거쳐 대표에게 올라갑니다. 매번 같은 몇 초를 다시 쓰던 자리가 이번 조치로 없어졌습니다.

다시 세어 보니 자동화는 11개에서 13개로 늘어 있었다

역할·목록·보고선을 고친 다음, 처음 쟀던 네 숫자를 다시 세었습니다. 자동화 예약 작업은 11개에서 13개로 늘었고, 스크립트는 12개 그대로였습니다.

632줄짜리 문서 안에 흩어져 있던 결정 15건은 이제 여덟 개 역할과 목록 하나가 나눠 맡습니다. 자동화가 2개 늘었다는 사실 자체가 목표는 아니었습니다 — 그 2개가 결정 하나마다 담당자를 붙이는 일과 목록을 확인하는 일에서 나왔다는 점이, 이번 조치가 문서 위에서만 끝나지 않았다는 증거였습니다.

이번 조치로 새로 재게 된 것도 있습니다. 아홉 개 원칙 각각에 담당 역할과 확인할 지표를 하나씩 붙였습니다. 원칙만 있고 누가 무엇으로 그 원칙을 지키는지 안 정해져 있으면, 원칙은 표에서 다시 대표 혼자 챙기는 항목으로 돌아갈 자리였습니다.

• 쉬핑 우선 원칙 — 제품·품질검증 담당의 출하 소요 시간
• 공개 우선 원칙 — 마케팅 담당의 일일 콘텐츠 발행 1건 이상
• 반복 수익 우선 원칙 — 제품 담당의 사업별 월 손익
• 지렛대 우선 원칙 — 운영·기술 담당의 자동화 회전율
• 복리 우선 원칙 — 전략 담당의 분기 점검과 월간 review
• 느낌보다 측정 원칙 — 여덟 역할 전원의 지표 의무화
• AI 네이티브 원칙 — 이 규칙 문서 자체
• 공장 우선 원칙 — 기술 담당의 재사용 자산 점검
• 다수 시도 원칙 — 전략 담당의 여러 시도와 신호 시 집중

아홉 항목 중 여덟 항목은 이번 주기에 담당과 지표까지 같이 정했고, 나머지 하나(전략 담당의 분기 점검)는 앞서 미룬 네 건과 같은 이유로 다음 단계로 넘어갔습니다.

이 사이클에서 실제로 바뀐 것은 자동화 개수보다 결정이 움직이는 경로였습니다. 처음에는 결정이 대표 한 사람의 기억에서 출발해 대표 한 사람에게 되돌아왔습니다. 지금은 신호가 들어오면 운영 담당이 받아 분류하고, 목록에 번호를 남기고, 해당 역할이 처리한 뒤 다시 보고문으로 올라옵니다. 같은 결정도 이제는 최소 세 자리(운영·해당 역할·목록)를 거쳐야 사라지지 않습니다.

아직 못 채운 4건과 남겨 둔 물음

이번 조치로 다 끝나지는 않았습니다. 15건 가운데 4건은 다음 단계로 미뤄 둔 채입니다 — 전략 담당 주간 점검 예약, 전략 보고문 발송 방식, 마케팅 발송 승인 절차, 대표 보고문의 역할별 구성입니다.

권한 분류도 확정이 아니라 임시안입니다. 스스로 결정하는 범위를 넓게 잡아 둔 대신 4주 뒤에 다시 조정하기로 했는데, 이 기록을 쓰는 시점까지 그 재조정은 아직 하지 않았습니다.

재무 담당을 부르는 조건(매출 발생 또는 누적 고정비 50달러)도 자동으로 감지하는 장치가 없습니다. 지금은 운영 담당이 수동으로 확인하는 방식에 의존하고 있고, 이 확인을 자동화하는 일도 남겨 둔 과제입니다.

미뤄 둔 네 건 뒤에도 이후 단계가 이미 예정돼 있습니다. 다음 두 주에는 전략 담당을 실제로 투입하고 콘텐츠·발송·광고·응답 자동화의 담당자 라벨을 완전히 옮기며, 그다음 두 주에는 제품·품질검증·디자이너 역할을 투입하고, 마지막 두 주에는 운영 전체를 통합해 지표로 확인하는 단계까지 이미 순서가 잡혀 있습니다. 순서는 정해 뒀지만 아직 실행 전이라는 뜻입니다.

그다음 두 주에 넣기로 예정된 자동화 중 하나는 기술 담당이 매주 일요일 10시마다 바깥 동향을 훑어보는 예약 작업입니다. 지금 자동화가 11개에서 13개로 늘어난 것과 같은 방식으로, 이 작업이 실제로 들어가면 같은 숫자가 한 번 더 움직일 자리입니다.

이 규칙 자체도 시간이 지나면 낡습니다. 632줄짜리 원본 문서가 먼저 바뀌고 이 압축본이 그 뒤를 못 따라가면, 둘 사이에 다시 같은 종류의 간극이 생깁니다. 원본이 바뀌면 압축본도 다시 정리한다는 원칙만 남겨 뒀을 뿐, 그 간극을 자동으로 감지하는 장치는 아직 없습니다.

돌이켜 보면 이번 사례에서 진짜 틀렸던 지점은 '표만 그리면 충분하다'는 전제였습니다. 역할 이름과 한 줄 정체는 이미 정리돼 있었는데도 15건 중 6건이 정정된 이유는, 표가 결정 하나하나가 지나가는 경로까지는 보여 주지 않았기 때문입니다. 무엇을 나눌지보다, 나눈 역할 사이로 결정이 실제로 어떻게 흘러가는지를 먼저 그렸어야 했습니다.

이 기록을 남기는 이유도 같습니다. 6건의 정정과 4건의 유예를 감추고 '역할을 나눴다'고만 적으면, 다음에 아홉 번째 역할이나 새 자동화를 추가할 때 같은 실수—표만 그리고 목록은 잊는 실수—를 반복하게 됩니다.

결정을 나누는 일은 한 번에 끝나는 작업이 아니라는 점도 이번에 다시 확인했습니다. 15건을 처음 적어 낸 뒤 6건을 고치고, 그중 하나(전략 담당의 분기 점검)는 또 다음 단계로 넘겼습니다. 처음 적은 안이 최종안이 아니라는 전제를 갖고 있어야, 정정을 실패가 아니라 정상적인 절차로 받아들일 수 있습니다.

자동화가 정확히 왜 2개 늘었는지, 어떤 예약 작업 두 개가 새로 붙었는지는 이번 측정 한 줄만으로는 알 수 없습니다. 이번 주기에 함께 처리한 항목(마케팅 역할 신설, 목록 신설, 봇 명령 추가) 가운데 무엇이 예약 작업으로 잡혔는지 구분하는 계측은 아직 없습니다. 숨기지 않고 그대로 남겨 둡니다.

고정비도 지켜봐야 할 숫자입니다. 지금까지 늘어난 월 고정비는 15달러 안팎인데, 다음 단계에서 검토 중인 항목을 더하면 40달러까지 늘어날 수 있다는 계산이 이미 나와 있습니다. 아직 그 단계에 들어가지 않았을 뿐, 넘지 않는다는 보장은 아닙니다.

혼자 여러 사업을 동시에 운영하면서 AI 에이전트 역할 분담을 문서 한 장으로 끝내려다가 같은 자리에서 다시 고친 경험이 있다면, 상담에서 무엇부터 고쳤는지 구체적으로 나눌 수 있습니다. 비슷한 결정 구조를 다른 자동화에도 적용한 기록은 AI 에이전트 승인 게이트를 4개로 줄인 기록에 있습니다.