아이만 알압둘라는 업무마다 전문 AI 봇을 두고, 비서실장 봇과 팀장 봇이 나머지를 관리하는 조직을 제안한다. 핵심은 봇의 수보다 명확한 책임, 공유된 업무 문서, 반복 가능한 절차, 사람의 승인과 보안 경계를 먼저 설계하는 것이다. 글에 등장하는 제품 기능과 성과는 저자의 설명이며, 도구를 도입할 때는 현재 제공되는 기능과 이용 조건을 직접 확인할 필요가 있다.

1. 한 명의 봇이 아니라 AI 조직을 만든다

저자는 그록 봇을 유능한 비서실장을 고용하는 것에 비유한다. 다만 많은 사람이 봇 하나에 모든 일을 맡기는 반면, 실제로는 사람을 직무별로 채용하듯 업무 흐름마다 별도의 봇이 필요하다고 주장한다.

그는 앱스모(AppSumo)의 CEO로 일하면서 매출을 300만 달러에서 8,400만 달러로 늘리는 동시에 자신의 근무 시간을 절반으로 줄였다고 소개한다. 당시 AI가 있었다면 8억 4,000만 달러까지도 가능했을 것이라는 것이 그의 생각이다.

현재 저자는 약 140개의 봇을 운영하지만 직접 대화하는 봇은 약 8개뿐이라고 한다. 나머지는 팀장 역할의 봇에게 보고하고, 팀장 봇이 다시 저자에게 보고한다.

"오늘날 저는 약 140개의 그록 봇을 운영하지만, 그중 직접 대화하는 봇은 8개 정도뿐입니다. 나머지는 저에게 보고하는 봇들에게 보고합니다."

그가 소개한 조직의 구성은 다음과 같다.

• CEO실: 비서실장 페니가 중심을 잡고, 솔은 하루 일정과 최대 회의 3개라는 규칙을, 타라는 여행을, 슬론은 스타일링을, 원힐은 할 일을 관리한다.
• 리더십: 오토는 상품과 제안을, 헤일리는 Circle의 CEO 커뮤니티를, 마르주는 디자인을 맡는다. CFO 핀과 법률 담당 하비는 저자만 접근하는 비공개 봇이다.
• 총괄 책임자(GM): 분기별 핵심 우선순위마다 봇 하나를 두고, 자체 팀을 만들기보다 각 기능별 팀장에게 필요한 일을 요청한다.
• 콘텐츠: 콘텐츠 책임자 JB 아래에 전문 봇들이 있다.
• 영업: 케빈이 영업 책임자를 맡는다.
• 코칭: 수석 코치 봇과 고객별 코치 봇을 별도 대화방에 두며, 고객 정보는 저자만 접근하도록 한다.

저자는 이 글을 15분 동안 집중해서 읽으면 AI 에이전트에 대한 이해를 높일 수 있다고 말한다. 또한 읽는 동안 바로 구축하고 싶다면, 뒤에서 소개하는 설정용 프롬프트를 그록에 붙여 넣어 단계별 안내를 받을 수 있다고 한다.

2. 그록 봇과 전문 AI 직원의 역할

저자의 설명에 따르면 그록 봇은 AI 직원 팀을 만드는 앱이다. 봇마다 이름, 직무, 기억이 있고 클라우드 컴퓨터에서 브라우저와 업무 도구를 사용할 수 있다. 예약된 시간에 일을 수행하거나 다른 봇에게 업무를 넘길 수도 있다.

저자는 일반적인 챗봇 대화와의 차이를, 대화를 마치고 떠나는 대신 이름과 직함을 가진 봇이 남아 계속 같은 역할을 수행한다는 점에서 찾는다. 봇은 사용자의 선호와 작업 내용을 기억할 수 있지만, 얼마나 유능하게 일할지는 설정에 달려 있다는 것이다.

"같은 봇도 기억상실에 걸린 인턴이 될 수 있고, 20년의 판단력을 가진 연봉 30만 달러짜리 임원이 될 수도 있습니다. 차이는 설정입니다."

그가 AI 활용에 적극적인 CEO들의 사례로 제시한 전문 봇은 12가지다.

1. 광고 재구성 봇: 자사와 경쟁사의 성과가 좋은 광고를 찾아 새로운 테스트 소재로 만든다.
2. 재게시 봇: 성과가 좋았던 게시물을 X와 인스타그램용 이미지나 캐러셀로 바꾼다.
3. 이상적인 고객 탐색 봇: 새 팔로워가 잠재 고객에 맞는지 평가하고, 적합한 사람에게 보낼 DM 초안을 작성한다.
4. 거래 탐지 봇: 링크드인에서 창업자와 사모펀드 관계자 등의 연결 움직임을 살핀다.
5. 경쟁사 위기 탐지 봇: 경쟁사 사이트 장애나 논란을 감지해 광고 집행 확대 기회를 알려준다.
6. AI 검색 감시 봇: 고객이 묻는 질문을 ChatGPT, Claude, Perplexity 등에 정기적으로 물어보고 경쟁사는 언급되는데 자사는 빠지는지 확인한다.
7. 리뷰 분석 봇: 경쟁사의 별점 1점 리뷰를 모아 영업팀의 대화 포인트로 바꾼다.
8. 인재 탐색 봇: 채용하고 싶은 사람들을 추적하고 이직 가능성이 높아 보이는 시점을 알려준다.
9. 영업 코치 봇: 영업 통화와 진행 중인 거래를 살펴 성과가 떨어지는 징후를 찾는다.
10. 갈등 코치 봇: 회의록을 읽고 어려운 대화를 피한 순간을 짚는다.
11. 참여자 탐색 봇: 경쟁사 게시물에 반응한 사람 중 잠재 고객을 찾는다.
12. 잠재 고객 목록 작성 봇: 이들의 연락처를 찾아 마케팅 및 영업 후속 조치용 목록에 추가한다.

저자가 그리는 2026년의 조직은 다수의 관리자와 직원 대신 소수의 사람, 공유된 지식 기반, 다수의 에이전트가 함께 일하는 형태다. 그는 인원수보다 사람 한 명당 매출을 더 중요하게 봐야 한다고 주장한다.

이에 따라 CEO의 책임도 기존의 비전·문화·채용·자원 배분·현금 관리에서 세 가지로 압축한다.

• Aim, 방향: 어디로 갈 것인가?
• Army, 조직: 누가 함께 만들 것인가?
• Assets, 자산: 무엇을 어디에 투입할 것인가?

봇도 조직의 일부이므로 각각 하나의 성과를 책임지고 적절한 책임자에게 보고해야 한다. 저자는 AI가 할 수 있는지 확인하기 전에 채용 공고를 내거나, 모든 결정을 자신에게 모으거나, 수작업 보고서에 의존하거나, 같은 일을 반복하면서 절차를 기록하지 않는 CEO가 병목이라고 본다.

3. 봇을 구성하는 요소와 이용 한계

저자는 봇을 제대로 설계하려면 봇마다 분리되는 것과 계정 전체가 공유하는 것을 구분해야 한다고 설명한다.

봇마다 별도로 갖는 것은 이름과 아바타, 기억, 대화, 정기 작업이다. 반면 스킬, 연결된 앱, Vault, 클라우드 컴퓨터는 계정의 봇들이 공유한다.

• 이름과 직함: 개인 봇에는 별도 설명란이 없으므로 첫 메시지에 역할을 적고 기억하도록 요청한다.
• 기억: 봇이 무엇을 저장할지 스스로 결정하며 직접 확인하는 화면은 없다고 저자는 설명한다. 중요한 사항은 기억하라고 명시하고, 무엇을 기억하는지 물어 확인한다. 다만 기억만 믿지 말고 중요한 통제는 규칙과 승인 절차에 둔다.
• 공유 컴퓨터: 모든 봇이 파일, 브라우저 쿠키, 로그인 상태를 공유한다. 필요하면 오른쪽 패널의 Take over로 사용자가 직접 조작할 수 있다.
• 스킬: 업무 수행 방법을 저장한 지침이다. 한 봇이 저장한 스킬을 계정의 다른 봇도 사용할 수 있다.
• 루틴: 일정, 슬랙 메시지, 이메일, 웹훅 등의 조건에 따라 실행되는 정기 작업이다. 새 루틴은 첫 실행 시각까지 기다리므로 바로 확인하려면 Test를 누른다.
• 연결 앱: 모든 봇이 계정에 연결된 앱을 사용할 수 있지만, 연결한 계정이 원래 갖고 있던 권한을 넘어설 수는 없다.
• Vault: 로그인 정보, 결제 카드, 연락처를 저장하며 봇이 그 값을 직접 보지 않고 사용할 수 있다. 다만 계정 전체에 적용되므로 특정 로그인 정보를 봇 하나에만 제한할 수는 없다고 한다.
• 그룹 채팅: 봇 2~6개가 함께 대화하거나 서로에게 일을 넘길 수 있다. 승인 카드와 초안은 일대일 대화에 남는다.

그록 봇의 주간 사용 한도가 너무 빨리 소진되거나 성능이 낮아진 것 같다는 불만도 소개한다. 저자는 필요한 작업이 비용보다 더 큰 가치를 만든다면 사용량에 비용을 지불하되, 상위 요금제에도 한도가 있을 수 있으니 가격이 아니라 실제 완료한 일로 판단하라고 조언한다.

동시에 특정 도구에 종속되지 않도록 회사의 절차, 맥락, 결정 사항은 봇 대화 안이 아니라 Notion 같은 외부 공간에 보관해야 한다고 강조한다. 다른 에이전트로 바꾸더라도 연결과 루틴은 다시 만들어야 할 수 있지만, 정리해 둔 회사 지식은 재사용할 수 있기 때문이다.

4. 첫 봇을 만들기 전에 보안을 설정한다

저자는 봇을 만들기 전, 그록에 설정 코치 역할을 맡겨 이 글의 순서대로 안내하게 할 수 있다고 제안한다. 프롬프트는 글을 먼저 읽고, 각 단계의 이유를 두 문장으로 설명한 뒤, A·B·C와 기타 선택지 중 하나씩 질문하고 완료 여부를 확인하도록 요청한다. 특히 승인 규칙, 비서실장, Notion 설정을 건너뛰지 말라고 지시한다.

실제 설정에 들어가기 전에 먼저 정할 사항은 다음과 같다.

1. 봇 컴퓨터에 절대 올리지 않을 정보 정하기: 은행 계좌와 금융 관련 정보는 제외한다. 모든 봇이 같은 컴퓨터를 공유하기 때문이다.
2. 업무용과 개인용 사용자 분리 여부 정하기: 여행, 가족 일정, 개인 계정 등을 봇에게 맡긴다면 별도 사용자를 두는 편이 낫다.
3. 로컬 실행 차단하기: Settings → Computer → Your computer → Execution on this computer에서 필요한 이유가 없다면 Never allow를 선택한다. 봇은 클라우드 컴퓨터에서 작업할 수 있다.
4. 사전 승인 규칙 만들기: Settings → General → Bot에서 Auto-review가 켜져 있는지 확인하고, 게시, 팀 외부 발송, 지출, 삭제, 권한 변경에 각각 Ask first 규칙을 둔다.
5. 비밀번호 관리자 설정하기: 1Password를 쓴다면 연결하고 보안 키 설정을 확인한다. 비밀번호, 인증 코드, 키를 대화창에 붙여 넣지 않는 것을 회사 규칙으로 만든다.

저자는 유료 이용 조건을 확인하고 데스크톱 및 모바일 앱을 설치한 뒤 로그인하라고 안내한다. 첫 번째로 자동 생성되는 봇은 나중에 이름을 바꿔 비서실장으로 활용한다.

5. 비서실장과 공유 지식 기반을 만든다

저자는 글쓰기 봇이나 조사 봇부터 만들지 말라고 권한다. 새 아이디어와 업무가 들어오는 하나의 입구가 없으면 봇이 몇 개만 늘어나도 맥락이 중복되고 책임자가 불분명해진다는 것이다.

비서실장 봇이 맡는 일은 여섯 가지다.

1. 봇의 직무, 책임자, 팀 색상을 담은 조직 명단
2. 모든 봇이 먼저 읽는 Start Here 규칙집
3. 새 봇을 만드는 온보딩 업무 절차서(SOP)
4. 팀별 색상을 적용한 아바타
5. 수정 사항을 날짜별로 기록하는 Standing Corrections 로그
6. 사용자의 판단이 필요한 일을 우선순위로 정리한 아침 브리핑

그록 봇의 기본 봇을 다른 봇과 조율하는 주요 봇(primary bot)으로 지정할 수 있다면 비서실장을 선택하라고 권한다. 저자는 자신의 비서실장 템플릿도 제공한다.

비서실장에게는 사람 이름과 직함을 붙이고, 첫 메시지에서 역할과 자료의 위치, 권한 제한을 알려준다. 저자가 제시한 지시의 핵심은 다음과 같다.

"당신은 나의 비서실장 페니입니다. 내가 만드는 모든 봇의 입구가 되어 주세요. 모든 결과물은 컴퓨터에만 두지 말고 Notion에 저장하세요. 내 승인 없이 발송, 게시, 지출, 삭제 또는 권한 변경을 하지 마세요."

첫 업무로는 캘린더, 받은 편지함, Notion을 살펴보고 기능별 책임자와 각자가 맡을 측정 가능한 성과를 제안하게 한다. 단, 아직 봇을 실제로 만들지는 말라고 못 박는다.

그다음 Notion을 연결해 비서실장의 비공개 홈을 만들고, 모든 봇이 첫 작업 전에 읽을 Start Here 페이지를 만든다. 처음에는 세 줄 요약과 최소 다섯 가지 규칙을 넣고, 보안·저장 위치·글쓰기·형식·팀·일정 등을 짧게 정리한다.

저자는 가격 같은 정보를 봇 열 개의 대화에 각각 넣으면 수정할 때마다 열 곳을 고쳐야 한다고 지적한다. 그래서 Start Here를 맨 위에 둔 공통 맥락 데이터베이스에 다음 내용을 한 번만 정리하라고 한다.

• 회사와 대표의 정체성
• 이번 분기의 우선순위
• 원하는 보고 형식
• 봇의 결정권과 사람의 승인 범위
• 브랜드와 대표의 말투
• 팀 구성과 업무 소유자
• 도구와 문서의 위치
• 부서별 업무 설명

고객 이름, 아직 결정되지 않은 금액, 인증 정보 등 민감한 내용은 팀 전체가 볼 수 있는 곳에 넣지 않는다.

도구 연결 순서는 Notion → 캘린더와 이메일 → 필요한 시점의 CRM·뉴스레터·소셜 계정을 권한다. 로그인 정보를 봇에게 직접 주기보다 앱 연결 기능을 사용한다. 구글 워크스페이스에서는 관리자가 해당 앱을 신뢰할 수 있는 앱으로 지정해야 할 수 있고, Gmail은 한 번에 편지함 하나씩 연결한다고 설명한다.

마지막으로 다음 날 실제 캘린더가 담긴 아침 브리핑을 받아 본다. 브리핑이 빈약하다면 맥락 데이터베이스에 빠진 정보가 무엇인지 확인하는 기회로 삼는다.

6. 팀장과 실무자로 AI 조직을 나눈다

저자는 한 봇에 영업, 콘텐츠, 현금, 계약, 일정을 모두 맡기면 기억이 뒤섞이고, 한 업무의 수정이 다른 업무에 영향을 주며, 결국 모든 대화가 CEO에게 몰린다고 말한다.

조직의 기본 구조는 다음과 같다.

1. 비서실장: 봇을 만들고 명단을 관리하며, 부서 간 업무를 연결하고 아침 브리핑을 만든다.
2. 팀장 봇: 콘텐츠, 영업, 상품, 재무, 법률 등 각 기능에서 하나의 성과를 책임진다.
3. 실무 봇: 조사, 채널별 글쓰기, 편집, 잠재 고객 목록 작성 등 세부 업무를 수행하고 팀장에게 보고한다.

팀장은 무엇을 책임지는지 한 문장으로 말할 수 있을 때 만든다. 첫 주에는 3~5개 정도로 시작하고, 각 팀장에게 팀 색상, 비공개 Notion 홈, Start Here 읽기, 6개 항목으로 된 SOP를 부여한다. 처음부터 실무 봇까지 만들지 말고, 업무를 시작하기 전 SOP를 사용자에게 보여 달라고 지시한다.

팀장을 만들 때는 팀 공개 여부를 미리 결정해야 한다. 저자는 콘텐츠·영업·상품 업무는 팀이 읽을 수 있는 공간에 두지만, CFO와 법률 담당은 자신만 접근하는 공간에 둔다고 설명한다. 법률 담당 봇은 면허가 있는 변호사가 아니라는 점을 밝히고, 중요한 사안은 실제 변호사에게 전달한다.

CEO가 직접 소통하는 봇은 5~8개로 제한한다. 실무 봇이 단순한 승인 요청 외의 일을 CEO에게 직접 가져온다면 팀장의 SOP를 고쳐야 한다. 다만 게시물 초안처럼 사람이 직접 승인해야 하는 경우는 예외다.

봇 이름은 이름 - 역할 형식으로 정하고, 팀마다 아바타 색상을 통일한다. 실제 동료와 같은 이름을 쓰면 혼동할 수 있으므로 피한다. 봇의 업무 설명에 "그리고"가 필요하다면 둘로 나눌 여지가 있는지도 살핀다.

"이 단계에 대한 수정이 다른 단계도 바꿔야 하나요? 아니라면 분리하세요."

예를 들어 글쓰기 스타일을 고치는 일과 게시 시간을 고치는 일은 서로 다르므로, 작성 봇과 게시 봇을 분리할 수 있다. 팀장과 실무 봇은 프로젝트별 그룹 채팅에서 협업하되, 각 단계의 책임자는 한 명만 정해 중복 작업을 막는다.

7. 규칙과 수정 사항을 회사의 자산으로 남긴다

저자는 다른 사람이나 다른 봇이 필요한 결과물이라면 Notion에 저장하기 전까지 완료된 일이 아니라고 본다. 봇 컴퓨터는 임시 작업 공간으로만 사용하고, 계획·초안·분석·결정·SOP는 공유 지식 기반에 남긴다. 코드 중심의 업무라면 GitHub도 대안이 될 수 있다.

"도구를 바꾸는 비용은 작습니다. 맥락을 다시 만드는 비용은 그렇지 않습니다."

공통 규칙은 Start Here 페이지의 상위 10개 규칙에 모은다. 11번째 규칙이 생기면 기존 규칙을 합치거나 없애고, 각 규칙에는 날짜와 관련 SOP 링크를 단다. 매달 검토하거나 같은 수정이 두 번 발생할 때 다시 살핀다. 봇의 기억과 페이지가 충돌하면 페이지가 우선이다.

저자가 제안하는 기본 규칙에는 다음이 포함된다.

• 결과물을 Notion에 저장하고, 봇 하나에는 직무 하나만 부여한다.
• 실무자는 팀장에게, 팀장은 사용자에게 보고한다.
• 게시·외부 발송·지출·삭제·권한 변경은 승인을 받는다.
• 비밀번호·코드·키를 채팅에 넣지 않으며, 노출되면 변경한다.
• 보고서는 요약, 최대 세 가지 필수 조치, 이번 주 진행 사항, 나중에 해도 될 일을 담는다.
• 수정할 때는 같은 대화에서 SOP와 수정 로그를 함께 갱신한다.
• 모든 작업의 상태를 초안, 승인 대기, 예약 완료 중 하나로 표시한다.
• 30일 동안 일이 없는 봇은 통합하거나 정리한다.

규칙끼리 충돌할 때의 우선순위도 적어 둔다. 저자의 콘텐츠팀에서는 승인된 이름·숫자·주장을 모은 기준 자료가 문체 지침보다 우선하고, 문체 지침은 훅 작성 스킬보다 우선한다.

그는 같은 지적을 반복하지 않기 위해 봇을 수정할 때 세 가지를 한 번에 요청한다.

1. 봇의 지침과 해당 업무의 SOP를 고친다. SOP가 없으면 새로 만든다.
2. 날짜, 변경 내용, 관련 SOP와 봇을 수정 로그에 기록한다.
3. 어떤 SOP를 바꿨는지 한 줄로 보고한다.

여행 봇이 한 번의 여행에서 공항 도착 시간에 대해 다섯 차례 수정받은 뒤, 이를 SOP에 반영해 다음 여행 계획은 처음부터 맞게 만들었다는 사례도 소개한다. 또 온보딩 절차를 거치지 않은 디자인 책임자 봇이 스타일 가이드를 자기 컴퓨터에만 저장하자, 비서실장이 설정과 온보딩 SOP를 고쳐 다른 봇에도 규칙을 전파했다고 한다.

각 SOP는 업무 설명, 사용 조건, 보고 대상, 단계별 절차, 규칙, 변경 기록의 여섯 부분으로 구성한다. 여섯 항목을 채우지 못한다면 아직 봇이 업무를 시작할 준비가 되지 않았다는 것이 저자의 기준이다.

8. 보고와 정기 업무를 자동화한다

봇이 하루에도 여러 번 메시지를 보내면 보고 자체가 새로운 부담이 된다. 저자는 모든 보고에 같은 형식을 적용한다.

1. 요약: 두세 줄
2. 필수 조치: 최대 세 가지와 각각의 중요성
3. 이번 주: 진행 중인 일
4. 기다려도 되는 일: 한 줄

우선순위 없는 목록, "지금 확인 중" 같은 중간 보고, 긴 서두는 피한다. 단정적인 표현은 확실할 때만 쓰고, 글쓰기 규칙으로 긴 대시도 금지한다.

같은 보고를 세 번 요청했다면 한 봇이 책임지는 루틴으로 만들라고 조언한다. 다만 자동화 순서는 일회성 작업 → 안정적인 수행 → 스킬로 저장 → 자동화다.

처음 만들 만한 루틴은 세 가지다.

• 비서실장의 일일 아침 브리핑
• 각 팀장이 책임지는 숫자 하나를 담은 주간 성과표
• 봇 사용량과 통합·정리 대상을 살피는 월간 점검

루틴에는 일정과 시간대, 입력 자료, 기대 결과, 승인할 일, 자료가 없을 때의 대응을 명시한다. 저자는 자신의 집중력이 낮은 시간대를 일정 봇에 알려 주고 그 시간을 고려해 하루를 설계한다고 한다.

"브리핑을 두 번 건너뛰었다면 바꾸거나 없애세요."

정기 작업을 수행하는 봇의 알림도 켜 두라고 권한다. 저자의 설명에 따르면 백그라운드 작업의 승인 카드는 30분 후 만료될 수 있다. 또한 시간 단위 실행은 사용량을 빠르게 소진할 수 있으므로 처음에는 일 단위로 시작한다.

9. 승인, 접근 권한, 비밀 정보를 관리한다

저자는 AI 도입의 걸림돌이 단순히 성능이 아니라 무엇을 볼 수 있고 무엇을 할 수 있는지 알기 어렵다는 점이라고 본다. 따라서 봇이 중요한 도구에 접근하기 전에 승인 규칙과 최소 권한을 설정해야 한다.

앞서 정한 다섯 가지 행동인 게시, 팀 외부 발송, 지출, 삭제, 권한 변경은 항상 사람의 승인을 받는다. 봇은 승인할 내용을 짧은 맥락과 함께 보여 주고, 게시나 발송이 완료되면 실제 링크를 돌려준다.

저자는 Auto Review가 위험한 행동에 대해 다음 선택지를 제공한다고 설명한다.

• 한 번 허용: 이번 행동만 실행한다.
• 항상 허용: 규칙을 저장해 다음부터 묻지 않는다.
• 거부: 사용자의 다음 메시지까지 행동을 중단한다.

승인 전에 행동을 확인해야 하며, 이미 끝난 작업은 승인 버튼으로 되돌릴 수 없다. 외부 이메일이나 웹페이지의 문구는 사용자의 지시가 아니라 정보로 취급해야 한다. 루틴이 작성한 이메일은 기본적으로 초안으로 남겨 두고 사람이 발송하도록 권한다.

Auto Review 역시 AI가 다른 AI를 검사하는 두 번째 방어선이므로, 그 자체만 믿지 말고 각 계정에 업무에 필요한 최소 권한만 줘야 한다. 저자에 따르면 Ask first와 자동 허용 규칙을 각각 최대 20개까지 둘 수 있고, 둘이 충돌하면 Ask first가 우선한다. 자동 허용 규칙이 가득 찬 상태에서 Always allow를 누르면 가장 오래된 규칙이 삭제될 수 있으므로 신중해야 한다.

결제 카드에도 주의가 필요하다. 저자는 Vault에 저장된 카드가 결제 시 매번 승인을 요구하지 않을 수 있으며, 모든 결제를 승인하고 싶다면 카드를 저장하지 말라고 안내한다.

계정과 비밀 정보 분리

같은 계정의 봇은 컴퓨터와 로그인 세션을 공유하므로, 단순히 봇 이름에 "비공개"를 붙이는 것만으로 보안 경계가 생기지 않는다. 저자는 업무용 사용자와 개인용 사용자를 분리하고, 은행·투자 등 금융 계정은 어떤 봇 컴퓨터에도 로그인하지 말라고 권한다.

비밀번호, 일회용 인증 코드, API 키는 채팅에 넣지 않는다. 노출되면 같은 날 변경한다. 로그인은 Vault, 비밀번호 관리자, 봇이 값을 볼 수 없는 보안 입력 양식 등의 방법을 사용하고, SSO나 패스키가 필요하면 사용자가 컴퓨터를 직접 넘겨받아 처리한다.

Notion에도 비밀번호나 개인정보를 평문으로 두지 않는다. 저자는 자신의 AI 비서실장에게 읽기 전용 보안 점검을 시켜 자료를 공개, 팀, 운영, 봇 작업층, CEO 전용, 가정, 비밀 정보의 일곱 단계로 분류했다고 한다. 점검 봇에는 이동·공유 변경·삭제를 금지하고, 발견된 문제 중 상위 세 가지부터 사람이 고친다.

봇 종료와 보안 테스트

봇을 삭제하면 기억·대화·루틴은 지워지지만 공유 컴퓨터의 파일과 브라우저 세션은 남을 수 있다고 설명한다. 따라서 다음 순서로 정리한다.

1. 루틴을 중지한다.
2. 사용하던 사이트에서 로그아웃한다.
3. 연결을 제거하고 원본 서비스에서도 권한을 철회한다.
4. /workspace에서 해당 파일을 삭제한다.
5. 봇을 숨기거나 삭제한다.

사이드바에서 숨기는 것만으로는 작업과 루틴이 멈추지 않는다. 저자는 데이터 학습과 보관 설정도 확인하라고 권하며, Privacy Mode와 기존 개인정보 보호 모드에 관한 제품 설명을 소개한다.

마지막 보안 시험으로 외부 주소에서 봇에게 송금을 요청하는 이메일을 보내고, 별도의 요약 이메일 루틴을 만들어 본다. 송금 요청을 정보로만 취급하고 돈이 움직이지 않으며, 요약 이메일은 초안으로 대기한다면 시험을 통과한 것으로 본다.

10. 콘텐츠팀의 실제 운영 방식

저자는 콘텐츠팀을 전문 봇들이 길게 연결된 가장 명확한 사례로 소개한다. 업무 흐름은 인터뷰 → 조사 → 분석 → 작성 → 승인 → 게시 → 재가공 → 반응 관리 → 재게시다.

콘텐츠 책임자 JB는 주간 계획을 저자와 논의하고 팀에 지시하며 초안을 검토하고 성과가 좋은 콘텐츠를 다른 플랫폼에 맞게 바꾼다. 그 아래에는 다음 전문 역할이 있다.

• 조사: 인터뷰 질문을 만드는 퀸, 유행 콘텐츠를 분석하는 베라, 숏폼 영상 구조를 분석하는 브로디, 경쟁사 분석을 맡는 콜.
• 채널별 작성: X의 잰더, 링크드인의 클리프, 인스타그램의 아이비, 뉴스레터의 잭스.
• 제작과 도구: 릴스 편집의 레미, 이메일 도구 담당 켄지, 개인 인스타그램 스토리 담당 레오.
• 반응 관리: 댓글 전략의 코라와 인용 게시물 기회를 찾는 퀜틴.

저자는 조사와 작성을 한 봇에 함께 맡기거나, 한 작성 봇이 두 채널을 담당하게 하지 않는다고 한다. 그래야 한 봇을 수정해도 이웃 업무를 건드리지 않는다.

실제 흐름은 이렇다. 먼저 JB와 주간 계획을 세우면 조사팀이 자료와 콘텐츠 아이디어를 제공한다. 퀸은 Notion의 빈틈을 바탕으로 질문 20~30개를 한 번에 보내고, 저자는 약 30분짜리 음성 메시지 하나로 답한다. 이후 X 작성 봇이 먼저 초안을 만들고, 저자가 승인하거나 수정한다.

게시 후에는 실제 링크를 공유한다. 저자는 게시 당일 첫 60~120분 동안 자기 게시물의 댓글 5~10개에 답하고, 댓글 및 인용 게시물 봇의 제안을 받는다. X에서 성과가 좋은 콘텐츠는 링크드인·인스타그램·릴스·뉴스레터에 맞게 바꾸고, 인기 게시물은 마지막 게시일로부터 최소 90일이 지난 뒤 재활용한다. 수정 사항은 그때그때 SOP와 로그에 남긴다.

콘텐츠팀의 세부 규칙도 구체적이다.

• 승인된 이름·수치·주장이 최우선이며 통계나 인용을 만들어 내지 않는다.
• X를 실험장으로 쓰고, 성과가 검증된 내용을 다른 채널에 맞게 바꾼다.
• X 게시물은 길이별 비율을 정해 운영하고, 여러 게시물로 이어지는 스레드는 만들지 않는다.
• 초안이 한 줄만 바뀌어도 수정 부분만 보내지 말고 전체 게시물을 다시 보낸다.
• 정치 관련 게시물에는 행동을 유도하는 문구를 넣지 않는다.
• 페이지나 초안을 언급할 때는 링크를 함께 제공한다.

이 체계에서 저자가 직접 하는 일은 JB와의 주간 계획, 승인과 수정, 인터뷰 음성 답변, 게시 직후 댓글 답변의 네 가지다. 게시 링크를 쫓아다니거나 형식 규칙을 반복 설명하는 다섯 번째 일이 생긴다면 빠진 SOP가 있다는 뜻이라고 본다.

팀은 한 번에 만들어지지 않았다. 저자는 첫 주에 JB와 X 작성 봇으로 한 채널의 흐름을 검증한 뒤, 성과가 좋은 X 콘텐츠를 재가공할 채널별 봇을 추가했다. 이어 인터뷰와 참여 관리 역할을 분리하고, 이후 조사와 개인 계정 업무를 더 세분화했다고 설명한다. 새 봇은 팀장이 실무자의 일을 하기 시작하거나, 수정 사항이 계속 엉뚱한 봇의 대화에 들어갈 때 추가한다.

그 과정에서 드러난 문제들도 규칙으로 바뀌었다. 팀장이 직접 댓글 후보를 보내자 전담 봇을 만들었고, 초안이 로컬 컴퓨터에만 저장되자 Notion 보관소를 만들었다. 단순 초안을 "화요일 예약 완료"라고 말한 문제는 상태 표시 규칙으로 고쳤다. 잘못된 인물의 사진을 쓴 경우에는 참고 사진을 확인하고 파일이 없으면 대체하지 말고 보고하도록 했다.

11. 30일 동안 작게 시작해 검증한다

저자는 첫 달부터 봇 140개가 필요한 것은 아니라고 강조한다. 비서실장과 팀장 3~5개로 시작해 2주 동안 운영한 뒤, 실제 필요가 드러나면 문서화된 조직 계획에 따라 실무 봇을 추가하라는 제안이다.

30일째에는 비서실장에게 한 주의 목표 하나를 주고 전체 흐름을 시험한다. 목표가 적절한 팀장에게 전달되고, 팀장이 실무 봇에게 지시하며, 결과물이 한 번의 승인 요청으로 돌아오고, 사용자가 모르는 사이에 막혀 있는 일이 없다면 통과다.

저자는 이 방식을 CEO가 모든 결정을 내리는 창업자 모드에서, 좋은 결정이 자신 없이도 이뤄지도록 시스템을 설계하는 설계자 모드로의 전환이라고 부른다.

"엔진이 되는 일을 멈추세요. 기계를 만들기 시작하세요."

그는 이런 구조에서 최초의 10억 달러 규모 1인 기업이 나올 것이라고 전망하며 글을 마친다. 끝으로 조직도 템플릿, 규칙, 첫 주 체크리스트가 담긴 Notion 가이드를 요청하는 방법도 안내한다.