나는 소비자 제품 회사를 혼자서 운영합니다. 실물 재고, 두 개의 오프라인 매장, 여러 마켓플레이스, 구독 결제, 장부 정리, 세금 신고, 정부 서류 작업, 두 가지 언어로 된 콘텐츠, 그리고 대부분의 주마다 프로덕션(production)에 배포되는 코드베이스까지 관리합니다. 인원수: 1명. "가상 비서 한 명을 포함한 1명"이 아닙니다. 딱 1명입니다.

3년 전에는 이것이 불가능했습니다. 또한 오늘날에도 단순히 채팅창을 열어두고 질문을 던지는 방식으로는 불가능합니다. 변화한 핵심은 모델이 추상적으로 더 똑똑해졌다는 것이 아닙니다. 변화한 핵심은 에이전트(agent)가 이제 직원과 같은 방식으로 소프트웨어를 조작할 수 있게 되었다는 점입니다. 관리자 대시보드(admin dashboards)를 클릭하고, 정부 양식을 채우고, 이메일을 읽고, 코드를 작성 및 배포하며, 지난 화요일에 무슨 일이 있었는지 기억하고, 요청받지 않아도 정해진 일정에 따라 실행합니다.

이것이 가능해지면, 소규모 회사의 직원이 하는 일의 대부분은 매일 수행하는 대신 글로 적어 에이전트에게 전달하고 매주 감사(audit)할 수 있는 워크플로(workflow)가 됩니다.

내가 운영하는 모든 것은 5가지 프리미티브(primitives) 위에 구축되어 있습니다. 도구의 이름은 6개월마다 바뀔 수 있지만, 이것들은 바뀌지 않을 것입니다.

1. 브라우저 조작 에이전트 (A browser-operating agent)

나의 실제 로그인 정보(판매자 대시보드, 뱅킹 포털, 정부 사이트, 광고 플랫폼, 이메일 등)를 사용하여 실제 브라우저 세션을 구동하는 에이전트입니다.

이것은 가장 레버리지(leverage)가 높은 프리미티브이며, 대부분의 사람들이 건너뛰는 부분입니다. 그 이유는 불편합니다. 소규모 비즈니스 운영의 약 90%는 사용 가능한 API가 없는 로그인 장벽 뒤에 존재하기 때문입니다. 귀하의 마켓플레이스 판매자 콘솔, 결제 제공업체의 가맹점 대시보드, 해당 국가의 세무 포털, 그리고 여전히 신청 양식을 첨부 파일로 보내는 보조금 프로그램 등이 이에 해당합니다.

만약 귀하의 자동화 전략이 모든 것에 대해 공식 API를 필요로 한다면, 귀하는 이미 API가 존재하는 10%만 자동화하게 될 것이며, 나머지 90%는 여전히 밤 11시에 수동으로 처리하고 있을 것입니다.

브라우저 에이전트는 나의 '손'입니다. 로그인을 하고, 탐색하며, 화면에 있는 내용을 읽고, 양식을 채우고, 문서를 다운로드하며, 찾은 내용을 보고합니다.

2. 코딩 에이전트 (A coding agent)

나의 리포지토리(repositories)를 읽고, 변경 사항을 작성하며, 리뷰 단계(review pass)를 열고, 배포(deploy)하는 에이전트입니다.

저는 이를 커밋 권한(commit access)을 가진 계약직 직원처럼 대하며, 끝이 없는 수습 기간을 적용합니다. 이 에이전트는 스토어프런트(storefront), 내부 대시보드(internal dashboards), 스크래퍼(scrapers), 그리고 모든 글루 스크립트(glue scripts)를 구축했습니다. 제 역할은 코드를 작성하는 것이 아닙니다. 제 역할은 "이것은 체크아웃 페이지를 변경하며 그 외에는 아무것도 변경하지 않는다"라는 수준에서 디프(diff)를 읽고, 그 주장이 거짓일 때 이를 알아차리는 것입니다.

이 차이는 들리는 것보다 훨씬 더 중요합니다. 기능을 직접 작성할 수 있을 필요는 없습니다. 변경 사항이 범위 내에 국한되어 있는지(contained)를 판단할 수 있어야 합니다.

3. 스케줄된 루틴 (Scheduled routines)

반복되는 작업들입니다. "매일 아침 7시에 이 5개의 보조금 포털을 스캔하고 새로운 내용이 있으면 보고해줘." "매일 포스트 2개와 답글 3개를 초안으로 작성해서 내 승인을 받아줘."와 같은 것입니다.

여기서 얻는 해제(unlock)는 기술적인 측면만큼이나 심리적인 측면에서도 중요합니다. 1인 운영자(solo operator)에게 가장 희소한 자원은 시간이 아니라, 바로 오픈 루프 (open loops) — 즉, 당신이 잊어버리면 아무도 기억해주지 않기 때문에 머릿속에 계속 담아두고 있는 것들입니다. 당신이 실행에 옮기든 그렇지 않든, 당신이 붙들고 있는 모든 루프는 주의력(attention)을 소모합니다.

스케줄에 따라 실행되는 것들은 당신의 머릿속을 차지하는 것을 멈춥니다. 그것이 진정한 결과물(product)입니다.

제가 고생하며 배운 한 가지 규칙은 다음과 같습니다: 스케줄된 작업은 반드시 "변경 사항 없음"을 명시적으로 보고해야 합니다. 만약 침묵이 "새로운 소식이 없음"을 의미할 수도 있고, "작업이 9일 동안 고장 난 상태"를 의미할 수도 있다면, 당신은 결국 후자임을 깨닫게 될 것입니다. 제 에이전트들은 아무것도 찾지 못했다고 보고합니다. 그러면 침묵은 언제나 고장을 의미합니다.

4. 지속적 메모리 (Persistent memory)

제 에이전트들이 읽고 쓰는 구조화된 노트입니다: 사이트별 노트 ("이 회계 도구의 내보내기 버튼은 설정(Settings) → 데이터(Data) 아래에 있음"), 프로젝트별 노트 ("결제 제공업체 B의 검토가 대기 중임, 마지막 확인일은 23일"), 그리고 결정별 노트 ("구독은 카드 결제로만 유지함; 구독에 지갑 결제를 다시 추가하지 말 것").

메모리가 없다면, 모든 세션은 제로(zero)에서 시작하여 과거의 실수를 반복합니다. 당신은 비즈니스를 다시 설명해야 하고, 에이전트는 내보내기 버튼이 이동했다는 사실을 다시 발견해야 하며, 당신이 3월에 거절했던 사항을 다시 제안하게 됩니다.

메모리 (Memory)가 있다면, 당신의 직원들은 재직 기간 (Tenure)을 갖게 됩니다. 이는 오늘 아침에 시작한 인턴과 당신과 함께 1년을 보낸 인턴의 차이와 같습니다.

함정은 모든 것을 하나의 거대한 노트에 쏟아붓는 것입니다. 그렇게 되면 데이터가 커질수록 검색 (Retrieval) 성능은 악화되며, 에이전트는 단 하나의 대시보드에 관한 질문에 답하기 위해 3,000단어에 달하는 이력을 읽어야 합니다. 나누십시오. 사이트당 하나의 파일, 프로젝트당 하나의 파일, 그리고 지속적인 결정 (Durable decision) 하나당 하나의 파일로 나누어야 합니다.

5. 승인 게이트 (Approval gates)

위의 모든 사항을 실제 돈이 오가는 비즈니스에서 실행할 수 있을 만큼 안전하게 만드는 규칙은 다음과 같습니다:

에이전트가 초안을 작성합니다. 내가 승인합니다. 에이전트가 실행합니다.

되돌릴 수 없는 모든 작업은 명시적인 인간의 체크포인트 (Human checkpoint)를 거칩니다. 돈을 송금하는 것, 정부 신청서를 제출하는 것, 공개적으로 게시하는 것, 고객에게 이메일을 보내는 것, 프로덕션 (Production)에 배포하는 것 등이 이에 해당합니다.

사람들은 이것을 자동화에 대한 타협으로 읽습니다 — 마치 게이트가 내가 아직 자동화하지 못한 부분인 것처럼 말이죠. 하지만 정반대입니다. 게이트가 바로 자동화 전략입니다. 게이트는 100시간의 실행 업무를 1시간의 검토 업무로 전환하며, 검토는 한 사람이 실제로 맡을 수 있는 직무입니다.

또한 이는 실패 비용 (Cost of failure)을 변화시키며, 바로 이 점이 전체 시스템을 가능하게 만듭니다. 잘못된 보조금 신청서 초안을 작성하는 에이전트는 저에게 5분의 검토 시간만을 소모하게 합니다. 하지만 잘못된 보조금 신청서를 제출해 버리는 에이전트는 5분보다 훨씬 더 많은 비용을 치르게 합니다. 따라서 제 에이전트는 그럴 수 없습니다.

솔직히 이것이 실제로 가져다주는 것

보수적인 관점에서, 이런 방식으로 운영해 온 지난 기간을 종합해 보면:

• 이는 정규직 직원 2~4명의 루틴 업무량(운영 보조원, 회계 장부 보조원, 주니어 마케터, 주니어 개발자)을 커버합니다.
• 도구 사용에 월 몇백 달러가 소요됩니다. 직원의 하루 미만입니다.
• 판단력은 대체하지 못합니다. 저는 여전히 가격 책정, 브랜드, 제품, 법적 전략을 결정합니다. 에이전트는 그 결정을 실행하기 쉽게 만들 뿐, 내리는 것이 불필요한 것은 아닙니다.
• 규칙적으로 실패합니다. 잘못된 구독 할인 등급을 배포하는 경우. 결제 게이트웨이가 실제로 차단했던 환불이 '완료'로 보고되는 경우. 스크래퍼가 9일 동안 불평 없이 오래된 경쟁사 데이터를 반환한 경우. 이 모든 것이 체크리스트 항목이 되었습니다.

마지막 지점이 제가 밑줄을 그을 부분입니다. 실패는 에이전트의 신뢰성 때문이 아니라, 게이트(gates) 덕분에 생존할 수 있는 것입니다. 에이전트가 실패하지 않는 버전을 판매하는 사람은 다른 것을 파는 것입니다.

혼자서 시작해야 할 곳

다섯 가지를 한 번에 설치하지 마세요. 효과적이었던 순서는 다음과 같습니다:

1. 일주일 중 가장 많은 시간을 낭비하는 단일 워크플로우를 고르세요. 스케줄링하기 전에 에이전트와 함께 수동으로 두 번 실행해 보세요. 당신은 모델이 아니라 자신의 프로세스 설명을 디버깅하고 있는 것입니다.
2. 메모 노트를 작성하세요. 비즈니스를 계속해서 재설명하는 것을 멈추는 순간, 다른 모든 것이 더 저렴해집니다.
3. 자동화하기 전에 돈이 흐르는 경로에 게이트를 먼저 설치하세요, 나중에가 아닙니다.
4. 그 후에 스케줄링하세요. 이미 수동으로 두 번 작동한 것들만요.

제가 가장 자주 보는 실패 모드는 그 반대입니다: 먼저 스케줄링하고, 워크플로우 자체가 잘못되었다는 것을 나중에 발견하며, 매일 아침 7시에 자신감 넘치는 쓰레기를 생산하는 크론 작업(cron job)으로 끝나는 것입니다.

이것은 더 긴 글의 서론입니다. 제가 실제로 운영하는 모든 30가지 워크플로우를 기록해 두었습니다. 각각에는 번호가 매겨진 플레이북, 복사-붙여넣기 프롬프트, 저에게 피해를 준 함정(pitfalls), 그리고 솔직한 시간 및 비용 범위가 포함되어 있습니다.

원문은 제 사이트에 게시되었습니다: https://methezone.github.io/solo-operator-playbook/five-primitives.html

저는 복사-붙여넣기 프롬프트와 실패 사례를 포함하여 총 30개의 워크플로우 (workflows)를 기록했습니다. 그중 5개는 이메일 수집 없이 완전히 무료로 제공됩니다: 무료 샘플러 (the free sampler).