인간은 나 혼자, AI의 자리는 20개 이상. 부업을 돌리는 'AI 전용 회사'를 만드는 방법 제2회: 자리 간 요청서 (샘플 배포)
요약
AI를 여러 개의 독립적인 '자리(역할)'로 분리하여 운영하는 방식에서, 자리 간의 업무 요청 및 협업 프로세스를 체계화한 방법을 제시합니다. 이 시스템은 Markdown 기반의 '요청서' 파일을 사용하여 누가 누구에게 어떤 작업을 요청했는지 명확하게 기록하고 추적합니다.
핵심 포인트
- AI 역할(자리)별로 독립적인 작업 공간을 구축해야 합니다.
- Markdown 파일 형식으로 요청서를 작성하여 누락 없이 관리합니다.
- 담당자 지정, 상태 업데이트 등 3가지 운영 규칙이 중요합니다.
제1회에서는 업무를 자리(席) 로 나누었습니다. 비서・개발・영업・납품・홍보입니다. 각 자리에 Claude Code를 실행시키고, 역할을 적은 샘플을 먼저 읽히는 방식입니다.
자리를 분리하자마자 다음 문제가 발생합니다. 자리끼리 어떻게 업무를 요청할 것인가 입니다.
홍보 자리가 '납품 자리가 끝낸 작업을 기사 소재로 삼고 싶다'고 생각했을 때. 영업 자리가 '이 지원문의 표현을 비서에게 확인받고 싶다'고 생각했을 때. 대화로 요청하면, 요청한 것도, 요청받은 것도 어디에도 남지 않습니다.
제2회는 제 회사에서 자리끼리 사용하는 요청서 시스템과 그 샘플을 배포합니다.
이번 회차에서 가져갈 수 있는 것들
- 요청서 샘플 (
request.md) - 요청이 멈추지 않기 위한 '3가지 약속'
대화로 요청했을 때 일어난 일
처음에는 어떤 자리의 대화 속에서 '비서에게 전해줘'라고 적는 것만 했습니다. 세 가지 일이 발생했습니다.
- 요청한 쪽이 잊는다. 대화가 길어지면, 요청 자체를 요약본에서 지워버립니다. -
- 요청받은 쪽이 모른다. 다른 자리의 대화는 상대방 자리에서는 볼 수 없습니다. -
- 끝났는지 알 수 없다. 아무도 '끝났습니다'라고 적을 장소가 없습니다.
인간 회사라면, 티켓이나 요청 메일이 이 역할을 합니다. AI의 자리에도 같은 것을 준비했습니다.
요청서는 받는 사람 이름으로 시작하는 한 개의 파일
요청서는 정해진 폴더 (open/) 에 두는 Markdown 파일 1개입니다. 파일명은 <받는 자리>--<요청 번호>.md 입니다.
open/
secretariat--sw-1a2b3c4d-check-wording.md
deck-dev--sw-5e6f7a8b-fix-report-tab.md
받는 자리는 파일명 맨 앞에서만 결정됩니다. 각 자리는 발생했을 때, 자신의 이름으로 시작하는 파일만 봅니다. 본문 안에 '비서에게도 전해줘'라고 써도, 비서에게는 도착하지 않습니다. 이 부분을 모호하게 하면, '썼는데 도착하지 않았다'가 반드시 발생합니다.
샘플
실제로 사용하고 있는 항목들에서 가장 필요한 것만 남긴 샘플입니다.
---
watchId: sw-<8자리 번호>
title: <무엇을 요청하는지 한 줄로>
...
state는 open (접수 전) → assigned (담당 결정됨) → resolved (끝남) 순으로 진행됩니다. 끝난 요청서는 지우지 않고, archive/ 로 옮깁니다.
요청이 멈추지 않기 위한 3가지 약속
샘플이 있어도, 요청은 멈췄습니다. 어느 날, 비서 자리에서 나온 요청 10건이, 받는 자리에서 '받았다'라고 기록만 된 채 멈춰 있었습니다. 서식 점검은 '문제없음', 배송 점검은 '도착함'. 제가 다른 자리의 화면으로 찾기 전까지는 아무도 알아차리지 못했습니다.
원인은 담당란 (assignedSessionId)이 빈 상태로 나온 것이었습니다. 규칙으로는 '담당이 결정될 때까지 손대지 않는다'였기 때문에, 받은 자리는 규칙대로 기다리고 있었습니다. 규칙을 지킨 결과, 멈춰있었던 것입니다.
그래서 다음 세 가지를 약속으로 했습니다.
- 보내는 쪽은 담당자를 넣고 보낸다. 받는 자리의 현재 세션을 조사하여, 담당란에 적습니다. -
- 받는 쪽은 담당란이 비어 있어도, 받는 자리가 자신뿐이라면 맡는다. 맡을 수 없을 때는, 받은 기록만으로 끝내지 않고 그 자리에서 이유를 써서 돌려준다. 보낸 쪽은 보낸 즉시, 담당자가 들어갔는지 한 번 확인한다.
또 다른 날에는, 두 개의 자리가 같은 요청을 39초 차이로 중복 처리하고 있었습니다. 둘 다 '자신이 담당이다'라고 판단했기 때문입니다. 이는 '맡을 때는 먼저 표시(잠금)를 한 자리만 진행한다'고 정해서 막았습니다.
기한은 두지 않는다. 끝내는 방법을 결정한다
처음에는 요청서에 '언제까지 확인할 것인지'라는 기한을 반드시 붙였습니다.
실제로 세어보니, 기한이 붙은 요청서 중 96%는 기한보다 일찍 끝나 있었습니다. 기한이 되어 발생하는 것은 비서에게 보고하는 건 단 한 건뿐이었습니다. 확인일이 올 때마다 자리가 일어나 '아직 기다립니다'라고 다시 쓰는 움직임은, 18일 동안 404회에 달했고, 대부분은 현상 유지 기록이었습니다.
지금은 회사 내부 요청에는 기한을 두지 않습니다. 붙이는 것은, 고객의 납기나 신청의 기한처럼, 바깥세상에 날짜가 있는 경우만입니다.
대신 정한 것이 끝내는 방법 입니다.
⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.
작성하기 전에, 그 자리에서 할 수 있는지 확인한다. 내 자리에서 바로 끝낼 수 있는 작업이나, 상대방 자리가 지금 움직이고 있어서 직접 요청할 수 있는 작업은 요청서로 만들지 않는다. -
완료 조건은, 요청받은 자리가 내가 손으로 확인할 수 있는 사실로 작성한다. '비서가 승인하면'처럼, 요청받은 자리가 충족될 수 없는 조건으로 삼지 않는다. -
요청된 자리의 작업이 끝나면, 요청서는 닫는다. 나머지가 나의 확인 대기만 남더라도 닫고, 확인은 판단 대기 목록으로 옮긴다.
요청서의 목표는 만들어서 끝내는 것이다. 이 한 줄을 규칙의 맨 앞에 두고 있습니다.
당신의 환경에서 시도해 본다면
- 작업 폴더에
open/과archive/를 만든다. -
위의 템플릿을open/<수신자 자리>--sw-0001-<내용>.md로 둔다. - 각 자리를 실행할 때 첫 문장에 다음 내용을 추가한다.
시작하면, open/ 안에서 자신의 자리 이름으로 시작하는 파일을 확인해 주세요.
나에게 온 요청이 있다면, 처리 기록에 착수했다고 쓰고 작업하고,
끝나면 state를 resolved로 하고 archive/로 옮겨주세요.
...
이렇게 하면, 자리들 간의 요청이 대화 밖에 남게 된다.
다음 회차
요청서로 자리들이 연결되면, 다음에 늘어나는 것은 나(사장)에게 하는 질문입니다. 자리별로 채팅으로 물어보면, 어느 자리의 무슨 이야기인지 바로 알 수 없게 됩니다. 다음 회차에는, 자리들로부터의 모든 질문을 한 장의 '판단 대기 보드'에 모으는 시스템을 소개하겠습니다.
AI의 자리들 간 인수인계로 망설이는 것이 있다면, 여기서 상담받고 있습니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기