AI 에이전트로 6개월간 1인 기업을 운영하며 얻은 10단계 프레임워크 (그리고 실패했던 지점들)

4. 감각을 부여하라: 야간 스카우트, 인텔리전스 디제스터, 인바운드 모니터, 시그널 파밍

사람들이 제일 많이 빼먹는 부분인데, 이게 마법의 핵심이다. 회사는 몇 가지 상시 흐름을 통해 세상을 인식한다:

  inboxes ----\
  CRM --------\
  rankings ----> SCOUT (nightly) --> one brief: what moved, what needs you
  competitors-/
  feeds ------/

  HN / Instagram / X / a FB community --> digesters --> scored signal + ideas
  LinkedIn + FB inbox --> hourly monitors --> new reply? --> queue + phone ping
  buyer-relevant posts --> signal farming (read + like only, 3x/day) --> lead pool

        all of it --> STRATEGIST --> the day's few highest-leverage moves

Scout는 밤새 모든 걸 훑어보고 짧은 보고서 하나를 써내지(가역적인 CRM 동기화만 수행하고, 절대 직접 전송은 안 함). Digesters는 내가 일일이 스크롤 할 엄두도 안 나는 Hacker News, Instagram 릴스, X, 그리고 Facebook 커뮤니티에서 알짜 정보를 캐내. Hourly monitors는 내 LinkedIn이랑 Facebook 받은 편지함을 감시하다가 새 답장이 오면 바로 내 폰으로 쏴주지. Signal-farming 루프는 구매자랑 관련 있는 게시물을 하루에 세 번씩 읽고 좋아요를 누르면서, 반응하는 사람들을 따로 모아. 잘된 점. 어둠 속에서 일어나는 일은 없어. 나는 텅 빈 피드 대신, 이미 요약된 세상을 마주하며 하루를 시작해. 망한 점. Signal-farming의 한계인데, 이건 좀 뼈아팠어. 비즈니스 콘텐츠에 공개적으로 반응하는 놈들은 구매자가 아니라 죄다 판매자더라고. 파이프라인을 깨끗하게 정리해도 실제 구매자는 거의 0에 수렴했어. 결국 내가 파는 거랑 똑같은 거 파는 놈들만 모아놓은 꼴이었거든. 풀(pool)을 읽되, 리드(lead) 숫자는 믿지 마.

5. 자동 조종이 아니라 부조종사: 승인 대기열 하나, 그 뒤에 대기 중인 제안자들

에이전트가 만든 건 그 어떤 것도 지 혼자 나가는 법이 없어. 제안자들(아웃리치, 육성, 백링크, SEO, 콘텐츠 재활용, 커뮤니티 답글)이 하나의 대기열에 초안을 넣으면, 내가 데스크톱이나 폰으로 검토해. 명확하게 '적용' 버튼을 눌러야만 전송되는 구조야.

  proposers  (outreach / nurture / backlinks / SEO / repurpose / community ...)
                      |   draft, never send
                      v
              APPROVAL QUEUE   (one Postgres table)
                      |
        cockpit on desktop   +   your phone
                      |   approve / edit / reject
                      v
              apply step  -->  actually sends / posts / commits
                      |
        writes the event back to the CRM   (full attribution)

잘된 점. 이게 레버리지 효과가 제일 커. 에이전트가 물량을 처리하고, 나는 판단만 해. 승인은 5초면 끝나는 탭 한 번이고, 적용된 모든 작업은 기록에 남으니까 깜깜이로 처리되는 일이 없지. 망한 점. 처음에 설계를 허술하게 해서 몇몇 작업이 대기열을 우회하게 뒀어. 그게 전부 다 구멍이 됐는데, 공교롭게도 바로 다음 두 포인트가 그 내용이야.

6. 초안은 발송이 아니다, 모든 대기열에는 실시간 소비자가 필요하다

관심 있는 잠재 고객이 긍정적인 반응을 보였어. 시스템이 35분 만에 꽤 괜찮은 답장 초안을 써놨는데, 파이프라인 어디에도 Gmail 초안을 읽어가는 놈이 없어서 3일 동안 그대로 방치됐지. 또 다른 내부 대기열(내가 에이전트한테 작업을 던지는 역방향 대기열)은 승인된 작업 31개가 일주일 동안 아무것도 실행되지 않은 채 쌓여 있었어. 잘된 점. 모든 아웃바운드는 하나의 대기열을 거치게 하고, 대기열을 만들 때는 반드시 그 대기열을 소비하는 놈, 깊이를 확인할 수 있는 방법, 그리고 백로그 알람까지 한 세트로 묶어서 배포해. 망한 점. 대시보드에는 "초안 작성됨"이나 "어딘가로 라우팅됨"이나 둘 다 "완료"로 떴거든. 실행 중인 소비자가 없는 대기열은 아예 없는 것보다 못해. 작동하고 있는 것처럼 보이니까 더 위험하지.

7. 지켜볼 수 있는 일정으로 돌려라: 러너 루프

자율성이란 건 그냥 예의 바른 스케줄러일 뿐이야. 로컬 루프 하나가 몇 분마다 깨어나서, 예정된 제안자들을 실행하고, 대기열을 비우고, 하트비트(작동 신호)를 찍어.

   tick --> fire the due proposers --> drain the queues --> stamp a heartbeat
     ^                                                            |
     |_________________ job ledger  +  health surface ___________|

잘된 점. 하트비트 파일, 작업별 원장, 그리고 루프가 죽거나 작업이 계속 실패하면 빨간불이 들어오는 상태 체크 기능. 제안자가 먹통이 되면 나는 러너부터 확인해. 망한 점. 여기서 발생한 모든 실패는 조용히 묻혔는데, 이게 제일 최악이야. 러너가 죽어도 며칠 동안 아무도 몰랐거든. 매주 실행되는 작업이 특정 조건에서 계속 실패했는데, 알림도 없이 매번 재시도만 반복하다가 하루에 에이전트 세션을 100개 넘게 날려 먹었어. 실패 마커를 남기거나 재시도를 멈추는 로직이 없었으니까. 작동하는 걸 직접 눈으로 확인하지 않은 안전장치는 안전장치가 아니라 그냥 추측일 뿐이야.

8. 가역성의 원칙: 되돌릴 수 없는 작업은 막고, 일방통행 래칫은 제거하라

두 번의 삽질, 원인은 똑같았음. 첫 번째는 레포지토리의 구버전 체크아웃 상태에서 돌아가던 봇이 충돌을 일으키더니, 강제로 deploy 브랜치를 이전 상태로 되돌려버린 거임. 이미 제대로 된 수정 사항이 실제 결제까지 처리한 지 37분이나 지났는데, 라이브 가격 정보가 롤백되면서 메인 결제창이 박살 났지. 두 번째는 콘텐츠 품질만 따지고 정작 내 고객인지 아닌지는 신경 안 쓰는 자동 팔로우 기능이었음. 이게 몇 달 동안 돌아가면서 계정 481개를 팔로우했는데, 그중 330개는 내 고객도 아니었음. 덕분에 내 피드는 관련성 0%인 게시물로 도배됐지. 잘 버틴 것들. 에이전트는 제안만 하고, 결정은 확정적 게이트(deterministic gates)가 내림. 사람이 직접 승인 안 하면 되돌릴 수 없는 작업은 절대 배포 안 함. 봇은 작업하기 전에 무조건 pull부터 하고, 메인 브랜치에 강제 푸시(force-push)는 절대 금지. 자동 추가(팔로우, 구독, 등록, 태그) 기능은 무조건 품질 검사, 주기적인 정리, 그리고 블랙리스트가 있어야 함. 그래야 정리가 자동으로 원상복구 되는 꼴을 안 보지. 박살 난 것들. 위험은 나쁜 코드에서 오는 게 아님. 세상 돌아가는 꼴도 모르는 에이전트가 나대거나, 정리 기능 없이 추가만 하는 자동화가 문제지. 푸시가 거절됐다는 건 네가 뒤처졌다는 뜻이지, 더 세게 밀어붙이라는 뜻이 아님.

9. 취향 루프를 닫아라: 이게 진짜 성장을 만드는 핵심이다

모든 작업에 두 가지 규칙을 둠. 작업하면서 바로 문서화할 것(작업이 뭔가를 만들거나 바꾸거나 망가뜨리면, 끝나기 전에 해당 플레이북을 업데이트할 것). 모든 거절 사례를 기록할 것(내가 초안을 거절하거나 수정하면, 그 이유를 해당 초안을 만든 플레이북에 다시 적어둘 것).

  you reject or edit a draft
             |
     the reason is written back into the playbook that made it
             |
     the next draft of that kind starts from your last correction
             |
     edits-per-draft fall week over week
             |
     near-zero categories earn more autonomy

잘 버틴 것들. 카테고리별로 초안당 수정 횟수를 측정하는데, 이게 매주 줄어들고 있음. 이 수치가 떨어지는 게 바로 "자동화 툴 좀 쓴다"는 수준과 "내가 없어도 회사가 매주 조금씩 더 날카로워진다"는 수준의 차이임. 박살 난 것들. 쓰기만 하고 아무도 안 읽는 신호는 아무짝에도 쓸모없음. 내 댓글 에이전트가 일주일 동안 따뜻한 답글을 4개나 받았는데도 후속 조치를 하나도 안 하더라고. 왜냐? 참여 로그를 읽어주는 놈이 없었거든. 모든 신호는 소비자가 있어야 함. 안 그러면 그냥 헛수고만 더 들어가는 쓰레기 데이터일 뿐임.

10. 진짜 병목은 구축이 아니라 결정하고 배포하는 거다

이건 진짜 쪽팔린 부분임. 시스템이 구축을 너무 편하게 만들어주니까 배포를 안 하게 되더라. 최악일 땐 초안이 54개인데 배포는 1개였음. 전체적으로 보면 콘텐츠 슬롯 294개를 계획했는데 배포는 31개뿐이었지. 우선순위를 눈에 보이게 하려고 레이어까지 따로 만들었는데, 추적하던 목표 9개는 시스템이 돌아가는 내내 한 번도 안 움직였음. 잘 버틴 것들. 배포 안 된 것들이 선을 넘으면 시스템을 배포 모드로 전환할 것. 그리고 일일 루프의 단위를 내 아이디어가 아니라 진짜 희소 자원인 '내 클릭(taps)'으로 계산할 것. 스카우트(Scout)와 전략가(Strategist)는 나한테 더 읽을 거리를 주는 게 아니라, 결정할 짧은 리스트를 주려고 존재하는 거임. 박살 난 것들. 원치 않는 일을 더 크게 만들려고 기계만 구축한 꼴이지. 우선순위 레이어가 목표를 하나도 못 움직인 건, 인지 문제가 아니라 그냥 내가 원하지 않았기 때문임. 그래서 다 지워버렸음. 뭔가를 눈에 보이게 하려고 소프트웨어를 만들기 전에, 그게 진짜 안 보이는 건지 아니면 그냥 하기 싫은 건지부터 확인해라. 소프트웨어로 해결할 수 있는 건 둘 중 하나뿐임.

지금 내 위치, 그리고 너한테 바라는 것

6개월 차 프레임워크는 이 정도임. 첫 유료 고객도 딱 이 세팅으로 잡았음. 구독 서비스 10개 정도를 해지하고 내가 직접 소유한 툴로 바꿨고, 사용량 기반의 배관(plumbing)만 남겨둠. 모든 성공은 9번, 취향 루프에서 나옴. 모든 삽질은 배포 경로가 없는 작업이나, 세상 돌아가는 꼴도 모르는 에이전트가 저지른 짓에서 나옴.

스스로 성장하는 회사는 기계가 물량을 처리하고, 네가 취향을 결정하고, 그 취향을 기록해서 기계가 매주 너를 조금씩 덜 필요하게 만드는 곳임. 그냥 굴러가기만 하는 회사는 타이핑만 자동화해놓고, 모든 결정과 모든 조용한 실패를 다 끌어안은 채 그걸 '레버리지'라고 부르는 곳이고.

내가 제일 확신이 안 서는 부분은 두 가지임. 1인 기업을 넘어설 때도 이 '단일 제너럴리스트 모델(2)'이 먹힐지, 그리고 취향 루프(9)가 진짜 수렴하는지 아니면 쉬운 수정 사항이 다 떨어지면 정체될지.

그러니까 찔러봐라. 너도 실제 비즈니스에 에이전트 돌리고 있다면, 이 10가지 중에 뭐가 틀렸고 내가 놓치고 있는 11번째는 뭔지 말이야.

추신: 다이어그램을 ASCII로 만든 건 의도적인 거임. 브랜드 로고 떡칠한 "AI 아키텍처" 뭉텅이 같은 거 또 보게 만들 생각 없었거든.