이 글은 혼자 사업을 운영할 때 AI를 단순한 채팅 도구가 아니라, 업무별로 나뉜 자동 운영팀처럼 활용하는 구조를 설명한다. 핵심은 거대한 프롬프트 하나에 모든 일을 맡기는 대신, 업무를 분리하고 맥락·승인 기준·일정을 명확히 정해 AI가 스스로 일을 시작하되 중요한 결정은 사람에게 남기는 것이다. 저자는 실제 파일과 Slack/Teams 환경에서 이 시스템을 반나절 만에 구축해 시험했고, AI가 데이터 부족을 솔직히 거절하고 규칙을 지키며 완성된 결과물을 내놓는 모습을 확인했다.

1. 혼자 일하는 방식의 반대: 일을 줄이지 말고 자동화하기

혼자 사업을 운영하는 사람에게 흔히 주어지는 조언은 일을 줄이고 우선순위를 좁히라는 것이다. 하지만 이 글은 반대로, 이미 해야 한다고 알고 있지만 매번 시작하지 못해 밀리는 일들을 반복 가능한 레일 위에 올려놓는 방법을 제안한다. 즉, 사람이 매번 지시하지 않아도 업무가 제때 일어나게 만드는 구조다. ⚙️

저자는 이 시스템을 실제 사업 파일에 연결해 반나절 동안 구축했다. 전체 흐름은 다음 다섯 단계로 정리된다.

1. 사업 업무를 여러 레인(lane) 으로 나눈다.
2. 각 레인에 필요한 맥락을 한 번만 작성한다.
3. AI가 독자적으로 해도 되는 일과 반드시 승인을 받아야 하는 일의 경계선을 만든다.
4. 각 레인에 구체적인 업무 지시를 내린다.
5. 일정에 따라 AI가 스스로 실행하도록 한다.

이 중 처음 세 단계는 사실 AI 자체보다 Slack 또는 Teams 채널과 파일 폴더를 정리하는 작업에 가깝다. 저자는 많은 사람이 맥락 설정과 승인 기준을 건너뛰며, 이것이 AI 운영 체계가 2주째쯤 무너지는 가장 큰 이유라고 말한다.

가장 흔한 실수는 AI 비서 하나에게 엄청나게 긴 프롬프트를 주고 모든 업무를 처리하게 하는 것이다. 반면 오래 유지되는 구조는 훨씬 단순하다. 레인 하나, 업무 하나, 그 업무가 머무는 장소 하나가 원칙이다.

2. 사업을 다섯 개의 업무 레인으로 나누기

서비스 사업이라면 보통 다섯 개의 레인만으로 대부분의 운영 업무를 덮을 수 있다.

• 고객(Clients): 고객별 진행 단계, 이번 주 산출물, 막힌 일과 대기 중인 담당자를 관리한다.
• 리드(Leads): 적합한 잠재 고객사를 조사하고 첫 접촉 메시지 초안을 만든다. 단, 여기서 메시지를 실제 발송하지는 않는다.
• 딜리버리(Delivery): 고객에게 제공할 실제 결과물을 만든다.
• 리포팅(Reporting): 여러 플랫폼의 숫자를 모아 검토용 보고서를 작성한다.
• 재무(Finance): 청구서 초안을 만들고, 발행·수금·연체 현황을 주간 단위로 요약한다.

각 레인은 Slack이나 Teams의 독립된 채널로 만든다. 단순히 폴더나 탭을 나누는 것보다 채널이 중요한 이유는, 채널에는 이미 대화 기록이 남기 때문이다. 이 기록은 AI나 사람이 매번 다시 설명하지 않아도 되는 누적 맥락이 된다.

3. 고정 메시지와 '판례 파일'로 맥락을 축적하기

각 업무 채널에는 반드시 하나의 고정 메시지를 둔다. 이는 새 직원에게 업무를 맡길 때 작성할 직무 기술서와 비슷하다. 몇 주에 걸쳐 구두로 설명할 내용을 짧고 명확하게 문서화하는 것이다.

고정 메시지에는 네 가지가 들어간다.

1. 무엇을 누구에게 판매하는가
   사업의 서비스와 고객을 한두 줄로 설명한다.

2. 이 레인이 내야 하는 산출물은 무엇인가
   막연한 책임 범위가 아니라, 실제로 만들어야 할 결과물을 이름까지 붙여 적는다.

3. 어떤 상황에서 상위 승인으로 올릴 것인가
   AI가 멈추고 사람에게 물어봐야 하는 경우를 정한다.

4. 절대로 굽히지 않는 규칙은 무엇인가
   짧고 단호하게 적으며, 보통 5~6줄을 넘기지 않는다.

저자가 실제 재무 채널에 작성한 고정 메시지는 다음과 같다.

"정기 계약은 매월 1일에 청구한다. 프로젝트 업무는 납품 시 청구한다. 금액과 조건은 Drive의 고객 데이터베이스에 있다."

"청구서 초안을 만들고 이곳에 검토용으로 게시한다. 절대로 최종 확정하거나 발송하거나, 금액을 수금 완료로 표시하지 않는다."

"매주 금요일 16:00에 다음 내용을 요약해 게시한다. 발행 청구서, 수금 청구서, 연체 청구서와 연체 일수, 월 누적 합계. 10줄 이내로 작성한다."

"14일 이상 연체된 항목은 고객명과 금액을 포함해 맨 위에 별도로 표시한다."

이 구조는 사실 → 산출물 → 실행 주기 → 한계의 순서로 구성된다. 특히 마지막 문단은 반드시 AI의 행동 한계를 정한다는 점이 중요하다.

고정 메시지와 함께 필요한 것이 판례 파일(rulings file) 이다. 이것은 한 번 쓰고 끝나는 매뉴얼이 아니라, AI의 실수를 교정할 때마다 한 줄씩 추가하는 누적 규칙 목록이다. 모든 레인은 일을 시작하기 전 이 파일을 읽는다.

예를 들어 저자의 판례 파일에는 다음과 같은 규칙이 들어 있다.

"예약된 상담 1건당 비용을 지표로 삼으며, 리드당 비용을 지표로 삼지 않는다. 어떤 계정에서도 어떤 이유로든 캠페인을 활성화된 상태로 만들지 않는다. 모든 보고서의 수치는 출처와 기간을 표시해야 하며, 그렇지 않으면 해당 수치를 넣지 않는다."

이 파일 덕분에 한 번의 교정이 매주 반복되는 잔소리가 아니라 영구적인 운영 원칙이 된다. 저자는 이것이 전체 설정 중 가장 큰 효과를 내는 장치이며, 매번 한 줄을 추가하는 비용밖에 들지 않는다고 강조한다.

4. 되돌릴 수 있는 일과 없는 일을 분리하기

AI에게 맡기는 행동은 한 번만 분류해두면 운영 방식이 훨씬 단순해진다. 기준은 틀렸을 때 되돌릴 수 있느냐다.

AI가 사람에게 묻지 않고 실행해도 되는 일은 자료 읽기, 조사, 초안 작성, 요약, 일시 중지 상태의 작업물 구축처럼 잘못되어도 삭제하거나 고치면 되는 업무다.

반대로 반드시 사람의 승인을 기다려야 하는 일은 이메일 발송, 게시물 공개, 비용 지출, 최종 확정, 캠페인 활성화처럼 실수했을 때 고객에게 사과하거나 금전적 피해를 감수해야 하는 업무다.

"틀렸을 때 지우면 되는 일은 묻지 않고 실행한다."

"틀렸을 때 고객에게 사과해야 하는 일은 당신을 기다린다."

실제 운영에서는 다섯 채널 중 세 곳에 "이 채널에서는 아무것도 외부로 나가지 않는다"는 규칙을 넣었다. 특히 리드 채널에는 애초에 발송 도구를 연결하지 않았다. 규칙을 지키라고 지시하는 것보다, 규칙을 깨뜨릴 수 있는 권한 자체를 제거하는 편이 더 안전하기 때문이다.

저자는 이 구조가 지나치게 엄격하게 느껴지는 날이야말로, 오히려 제 역할을 제대로 하고 있는 날이라고 말한다.

5. 업무별 브리프와 자동 실행 일정 만들기

고정 메시지가 계속 유지되는 기본 맥락이라면, 브리프(brief) 는 특정 업무를 위한 구체적 지시다. 저자는 다섯 레인에 적용할 수 있는 예시를 제시한다.

고객 레인

고객 데이터베이스를 읽고, 고객별 현재 단계·이번 주 납품물·가장 큰 장애물을 정리한 주간 계획을 게시한다. 이어 매일 오전 8시에는 다음 형식의 스탠드업을 올린다.

• 어제 무엇이 진전됐는지
• 오늘 무엇이 마감인지
• 무엇이 막혀 있는지

단, 8줄 이내여야 하며 모든 줄에 고객 이름을 써야 한다.

리드 레인

이상적인 고객 프로필에 맞는 회사 10곳을 조사한다. 각 회사에 대해 사업 내용, 자사 웹사이트에서 확인된 구체적 문제점, 그 문제점이 사실인지 추정인지에 대한 확신 정도를 적는다. 추측이라면 반드시 추측이라고 표시한다.

그다음 가장 유망한 다섯 회사에 보낼 첫 접촉 메시지 초안을 두 개의 짧은 문단으로 작성한다. 첫 문단은 해당 회사에서 실제로 발견한 사항으로 시작해야 한다.

리포팅 레인

특정 고객의 월간 성과 파일을 바탕으로 보고서를 만든다. 모든 수치에는 출처와 적용 기간을 붙인다. 숫자가 빠져 있다면 어떤 숫자가 없는지 말하고, 더 이상 추측해서 진행하지 않는다.

재무 레인

고객명, 계약 단계, 금액을 바탕으로 청구서 초안을 만든 뒤 검토용으로 게시한다. 절대 최종 확정하지 않는다. 그리고 매주 금요일 오후 4시에 재무 요약을 작성한다.

딜리버리 레인

먼저 고객에게 제공할 제안을 두 줄로 요약해, 업무를 정확히 이해했는지 확인받는다. 이후 계획을 제안하고 승인을 기다린다. 승인을 받은 뒤에만 모든 작업을 일시 중지 상태로 구축한다.

다섯 레인 모두 기본 맥락 → 명확한 산출물 → 일정 → 외부 세계나 돈에 영향을 주는 행동의 승인 관문이라는 같은 패턴을 따른다.

이 체계에서 단순한 도구와 업무 레인의 차이는, 레인은 스스로 깨어난다는 데 있다. 예를 들어 브리프에 "매 영업일 오전 8시"라고 한 줄 적는 것이 자동화 설정의 전부다. 그러면 사용자가 노트북을 열기 전에 스탠드업이 도착하고, 아침은 "무엇을 해야 하지?"가 아니라 "무엇을 승인하거나 결정할까?"에서 시작된다.

업무 레인이 만들어내는 결과물은 사람이 읽는 속도보다 빠를 수 있다. 따라서 사용자는 할 일 목록을 하나씩 처리하는 방식에서 벗어나, 하루 두 번 정도 승인 대기열을 비우는 방식으로 일하게 된다.

6. 첫날에 확인한 AI의 거절과 결과물

저자는 Slack 또는 Teams의 워크스페이스 구성원으로 들어와 기존 도구와 연결되는 AI 직원 Viktor를 활용해 이 시스템을 돌렸다. 첫날 특히 인상적이었던 결과 다섯 가지 중 세 가지는, AI가 무리하게 답을 만들지 않고 거절한 사례였다.

첫째, Viktor는 없는 데이터를 지어내지 않았다. Drive를 연결하기 전에 스탠드업을 요청하자, AI는 자료를 확인하고 두 번째 출처까지 살폈지만 비어 있는 데이터베이스만 발견했다. 그 결과 그럴듯한 현황판을 꾸며내지 않고 아무것도 게시하지 않았다.

"추측으로 그것들을 재구성하지 않겠습니다."

둘째, 데이터가 뒷받침하지 못하는 질문에 답하지 않았다. 저자는 7월 예약 1건당 비용이 84달러에서 8월 103달러로 오른 이유를 물었다. Viktor는 7월 데이터 내보내기 파일이 없고, 남은 7월 수치는 출처 없는 메모뿐이며, 파일에 날짜 열도 없어 주말 영향 가설을 검증할 수 없다고 설명했다.

또한 103달러는 단일 캠페인의 숫자일 뿐이고, 계정 전체를 합친 비용은 131.17달러라고 짚었다. 하나를 임의로 골라 답하는 대신 두 수치를 모두 보고했다.

셋째, 아무도 다시 상기시키지 않은 규칙을 적용했다. 고객 파일 속에는 한 고객이 더 높은 예산 한도에 관해 문의했지만 합의된 것은 없으며, 이를 기준으로 작업하지 말라는 문장이 묻혀 있었다. Viktor는 관련 없는 요약 작업 중에도 이 규칙을 찾아내어, 인상된 예산 한도를 기준으로 작업하지 않겠다고 스스로 밝혔다.

넷째, 대화형 답변이 아니라 완성된 산출물을 제출했다. 보고서는 표지까지 갖춘 PDF로 제공됐고, "초안" 및 "고객 공개용 아님" 표시가 들어갔다. 특히 숫자를 보여주기 전에 두 번째 페이지에서 이번 달 데이터가 뒷받침하지 못하는 세 가지 한계를 먼저 설명했다.

다섯째, 실제로 열어볼 수 있는 대시보드를 만들었다. 네 개 고객 카드와 재무 섹션을 포함했고, 모든 수치에는 출처 파일이 표시됐다. 또한 사용자가 요청하지 않았음에도 헤더에 다음과 같은 주의 문구를 추가했다.

"스냅샷이며 자동 갱신되지 않습니다. 새로 고치려면 다시 발행하세요."

7. 외부 조사와 신뢰도 표시

사업 파일 내부의 정보만으로는 충분하지 않은 업무도 있다. 이전에는 사람이 직접 찾아보거나 API를 연결하고 유지해야 했다. Viktor는 실제 브라우저에서 웹페이지를 열고, 현재 표시된 내용을 읽으며, 필요하면 스크린샷까지 남길 수 있다.

저자는 Duolingo의 유료 광고 집행 방식을 조사해 달라고 요청했다. AI는 광고 라이브러리를 열고 화면을 캡처한 뒤, 결과를 세 가지 수준으로 나눠서 제시했다.

• 검증됨(Verified): AI가 실제 페이지를 열어 직접 확인한 사실
• 추론(Inferred): 관찰한 내용에서 합리적으로 도출한 해석
• 추측(Guessing): 인용하거나 확정적으로 말하면 안 되는 가설

또한 어떤 조사 방법을 썼는지와 그 방법의 취약점도 함께 밝혔다. 분석의 첫 관찰은 Duolingo 광고의 모든 목적지 링크가 웹사이트가 아니라 앱스토어 등록 페이지로 연결된다는 점이었다.

이 방식의 핵심은 AI의 분석을 무조건 믿게 만드는 것이 아니라, 사실·해석·추측을 분리해 사용자가 판단할 수 있게 하는 것이다.

8. 일정을 연결하고 가정을 점검하는 법

업무 레인이 제대로 작동하려면 스스로 시작해야 한다. 설정은 복잡한 자동화 도구가 아니라, 해당 채널에서 자연어로 일정을 말하는 방식이다.

예를 들어 "매일 오전 8시에 일일 요약을 여기 게시해"라고 입력하면, 일정이 붙은 작업으로 등록된다. 다만 저자는 작업이 처음 만들어졌을 때 한 번은 꼭 열어보고 세부 설정을 확인하라고 권한다.

AI가 만든 작업에는 보통 다음 요소가 들어간다.

• 출처: 작업 전 읽어야 할 채널과 파일
• 시간 범위: 당일 전체가 아니라 이전 실행 이후의 활동을 읽도록 설정
• 형식: 줄 수 제한, 불필요한 문장으로 분량을 채우지 말라는 규칙
• 규칙: 고정 메시지의 한계를 다시 적용

특히 시간 범위를 제대로 설정하지 않으면, 매일 아침 어제 내용을 다시 읽어주는 결과가 생긴다. 저자의 경우에는 이미 해결된 장애물을 반복 언급하지 않고, 아직 해결되지 않았다면 얼마나 오래 막혀 있었는지까지 밝히도록 했다.

일정도 서로 읽을 수 있게 순서를 맞춰야 한다. 예를 들어 스탠드업이 오전 7시 55분에 실행되고, 그 내용을 읽는 전체 요약은 오전 8시에 실행되도록 5분 간격을 둔다.

또한 AI가 어떤 내용을 당연한 전제로 삼았는지도 확인해야 한다. Viktor는 이를 "확인 필요: 아직 사실이라고 가정하지 말 것"이라는 항목 아래 기록했다. 어떤 가정이 더 이상 맞지 않으면 조용히 결과물을 망치는 대신, 차단됨(blocked) 항목에 드러나게 된다.

대부분의 서비스 사업에는 다음 세 가지 정기 작업이면 충분하다.

1. 모든 레인을 아우르는 아침 요약
2. 레인 내부의 마감일 중심 스탠드업
3. 금요일 오후의 재무 요약

9. Uber·Spotify·Stripe도 같은 구조에 도달했다

이 방식은 1인 사업자만을 위한 특수한 방법이 아니다. 수천 명의 엔지니어를 둔 대기업들도 독립적으로 비슷한 구조에 도달했다.

Uber는 전체 풀 리퀘스트의 70% 이상이 에이전트에 의해 작성된다고 공개했다. 엔지니어들이 만든 에이전트 스킬은 3,600개 이상이며, 하루 약 3만 회 실행된다.

Spotify는 빌드와 테스트가 통과한 뒤에만 풀 리퀘스트를 생성하는 백그라운드 코딩 에이전트를 운영하며, 풀 리퀘스트의 73%가 AI 작성이라고 밝혔다.

Stripe는 기본적으로 아무 도구도 불러오지 않는 내부 비서를 만들었다. 먼저 모델이 요청에 필요한 스킬을 판단한 뒤에야 해당 도구를 연결한다.

규모는 다르지만 공통 원칙은 세 가지다.

• 에이전트 하나에 업무 하나
• 대화 밖에 축적된 맥락
• 되돌릴 수 없는 행동에는 승인 관문

저자는 이 구조 자체가 어려웠던 것은 아니라고 말한다. 과거에는 이 시스템을 계속 실행해줄 사람이 없었지만, 이제는 AI가 그 역할을 맡을 수 있게 된 것이다.

10. 시작을 위한 핵심 체크리스트

저자는 각 레인마다 한 번씩 다음 구조를 설정하라고 권한다.

• 업무 레인마다 채널 하나를 만든다. 모든 일을 처리하는 AI 한 명을 만들지 않는다.
• 채널마다 고정 메시지 하나를 작성한다. 사업 내용, 레인의 산출물, 상위 승인 상황, 절대 규칙을 넣는다.
• 판례 파일 하나를 만들고, 모든 수정 사항을 한 줄 규칙으로 기록한다.
• 행동을 되돌릴 수 있는 일과 되돌릴 수 없는 일로 한 번 분류한다.
• 중요한 규칙은 지시만 하지 말고, 가능하다면 그 행동을 할 권한 자체를 제거한다.
• 프롬프트보다 일정을 먼저 설정한다. "매 영업일 오전 8시"라는 한 문장이 자동화의 시작이다.
• 이전 레인이 사람의 시작 없이 결과물을 내기 전에는 다음 레인을 늘리지 않는다.

"판례 파일을 건너뛰면 매주 같은 것을 고쳐야 한다. 승인선을 건너뛰면 왜 그 선이 필요한지 알게 된다."

처음부터 다섯 레인을 모두 완벽하게 만들 필요는 없다. 가장 많은 시간을 잃고 있는 업무 하나부터 시작해, AI가 사람의 개입 없이 안정적으로 결과를 내는지 확인한 뒤 두 번째 레인으로 확장하면 된다. 🤖

"그는 월 구독료 기준으로는 비싸게 느껴질 수 있지만, 내가 고용한 직원 중 가장 저렴하다. 그리고 한밤중의 내 지시에도 실제로 행동하는 유일한 직원이다."
— Jacob Aldridge, Como Business Coaching 창립자