나는 1인 기업을 약 20개의 AI 에이전트 조직처럼 운영한다. 무엇이 문제였나.

나는 1인 운영자입니다. 직원도, 공동 창업자도 없습니다. 하지만 더 이상 정말로 혼자 일하지는 않습니다. 나는 각각의 직무와 이름, 그리고 명시적으로 하지 말아야 할 일들의 목록을 가진 약 20개의 특화된 AI 에이전트(AI agents)들로 구성된 작은 조직의 Human-in-the-loop(인간 참여형)로서 일합니다.

이 글은 "AI로 생산성을 10배 높이는 법"에 관한 글이 아닙니다. 이 설정을 통해 제가 배운 가장 가치 있는 사실은 제가 몇 주 동안 잘못된 것들을 만들어왔다는 점입니다. 그 이야기는 나중에 하겠습니다. 하지만 먼저 구조(shape)부터 말씀드리겠습니다. 사람들이 스크린샷을 넘어선 단계에서 "에이전트로 회사를 운영한다는 것"이 실제로 무엇을 의미하는지 계속해서 묻기 때문입니다.

구조

Chief-of-staff(비서실장) 에이전트는 매일 아침 실행되어 저에게 브리핑을 작성해 줍니다. 지난 24시간 동안 무엇이 출시되었는지, 무엇이 정체되었는지, 제가 설정한 한계치에 도달하려는 것이 무엇인지 알려줍니다. Finance(재무) 에이전트는 저의 세금 상황을 알고 있습니다. **Security officer(보안 담당자)**는 어떤 것이 커밋(commit)되기 전에 유출된 비밀 정보(secrets)가 있는지 스캔합니다. **Researcher(연구원)**는 아이디어를 검증하며, 의도적으로 속도 제한(rate-limited)이 걸려 있어 마지막 연구가 실질적인 결과물을 내놓기 전까지는 새로운 조사를 시작할 수 없습니다. **Shipper(배포 담당자)**는 스캐폴딩(scaffold)을 수행하고 배포합니다. 콘텐츠 리드, 퍼블리셔, 아카이비스트(archivist) 등이 있으며 그 외에도 십여 개가 더 있습니다.

이들은 세 가지를 공유합니다. 첫째, 현재 작업 중인 내용에 대한 단일 진실 공급원(single source of truth) 역할을 하는 하나의 태스크 백로그(task backlog), 둘째, 다음 에이전트나 다음 세션이 아무 정보 없이 시작하는 대신 전체 맥락(context)을 상속받을 수 있도록 하는 문서화된 지식 저장소(knowledge vault), 셋째, 에이전트가 단순히 설명만 하는 것이 아니라 실제로 무언가를 할 수 있도록 하나의 엔드포인트(endpoint) 뒤에 배치된 실제 도구 세트입니다.

그 위에는 제가 URSA라고 이름 붙인 콘솔(console)이 자리 잡고 있습니다. 이것은 조종석(cockpit) 역할을 하며, 실시간 상태와 목소리를 제공합니다. 말 그대로 목소리입니다. 이 콘솔은 두 가지 언어로 저에게 말을 걸며, 제가 지켜보라고 명령한 수치가 잘못된 방향으로 흐를 때 요청하지 않아도 저를 방해하며 알려줍니다.

두 가지 규칙이 이 모든 시스템을 하나로 묶어줍니다. 돈을 쓰거나, 세상에 공개하거나, 계정에 접근하는 모든 행위는 중단하고 저에게 먼저 물어봐야 합니다. 그리고 모든 제품은 출시되는 날 즉시 종료 임계값(kill threshold)을 부여받습니다. 즉, 제가 손을 뗄 구체적인 수치와 날짜를 미리 약속해 두는 것입니다. 그래야 제대로 작동하지 않는 무언가가 제 주의력을 영원히 조용히 갉아먹는 일을 방지할 수 있습니다.

무엇이 문제였나

제가 배운 교훈이 큰 순서대로 세 가지가 있습니다.

첫째, 에이전트 하나가 8시간 동안 멈춰 있었습니다. 저는 빌드 에이전트(build agent)에게 서비스를 테스트하라고 요청했습니다. 그런데 에이전트는 서비스를 백그라운드(background)에서 실행하고 조사하는 대신, 서버를 포그라운드(foreground)에서 실행했습니다. 그러고는 472분 동안 프로세스를 열어둔 채 차단된 상태로 가만히 있었고, 그동안 계속해서 고아 프로세스(orphans)를 생성했습니다. 이제 이 교훈은 규칙이 되었습니다. 에이전트는 절대로 데몬(daemon)을 포그라운드에서 실행해서는 안 되며, 오케스트레이터(orchestrator)는 타이머를 통해 워커(worker)들을 감시(watchdog)해야 합니다. 에이전트는 인간이라면 절대 하지 않을 방식으로 실패합니다.

둘째, 설정 파일(config file)이 조용히 덮어씌워졌습니다. 한동안 빌드가 알 수 없는 이유로 계속 깨졌습니다. 원인은 에이전트가 실제 Dockerfile 위에 테스트 피스처(test-fixture) 내용을 직접 덮어썼기 때문이었고, 해당 디렉토리가 추적(track)조차 되지 않았기에 아무도 이를 감지하지 못했습니다. 해결책은 파일의 해시(hash)를 생성하고, 예상치 않게 변경되었을 경우 커밋(commit)을 실패하게 만드는 가드(guard)를 설치하는 것이었습니다. 더 깊은 교훈은 이것입니다. 에이전트에게는 세 단계 뒤의 코드 리뷰가 아니라, 실수가 발생하는 그 순간에 아주 크게(loudly) 실패하는 가드레일(guardrails)이 필요합니다.

셋째 — 가장 비용이 많이 든 문제: 단 한 명의 고객도 요청하지 않은 제품을 일곱 개나 만들었습니다. 이것은 제가 여전히 곱씹고 있는 문제입니다. 제 에이전트 군단은 만드는 능력만큼은 훌륭합니다. 불과 몇 주 만에 테스트와 배포를 마친 일곱 개의 실제 도구를 출시했습니다. 저 또한 그것들을 사용합니다. 하지만 저는 시장이 있어 보였기 때문에 제품을 만들었을 뿐, 실제 누군가가 저에게 그것을 요구해서 만든 것이 아니었습니다. 반면, 진정으로 가치 있다고 느껴지는 유일한 것들은 내부 도구들, 즉 콘솔(console)이나 조직(org) 그 자체였습니다. 이것들은 제가 실제로 필요했기 때문에 존재하게 된 것들입니다.

이 패턴을 깨닫는 데 부끄러울 정도로 오랜 시간이 걸렸습니다. 제가 '밀어넣기 (push)' 방식("이건 시장성이 있어 보여")으로 만든 모든 것은 공허하게 끝났습니다. 반면 '끌어오기 (pull)' 방식(이미 내가 가지고 있는 필요성)으로 만든 모든 것은 생동감 있게 살아남았습니다. 그래서 저는 조직(org)이 이를 강제하도록 만들었습니다. 이제 모든 새로운 빌드(build)가 제 시간을 할애받기 전에 통과해야 하는 관문이 생겼으며, 그 첫 번째 질문은 제가 그동안 건너뛰어 왔던 질문, 즉 "누가 이것을 끌어왔는가? (who pulled this?)"입니다. 제 에이전트 중 하나는 읽기 전용(read-only)이며 본질적으로 그 목적, 즉 저에게 '아니오'라고 말하기 위해 존재합니다.

직접 시도해보고 싶다면

20개의 에이전트가 필요하지는 않습니다. 가치의 거의 대부분은 네 가지 프롬프트 패턴(prompt patterns)에서 나왔으며, 이들은 단 하나의 시스템 프롬프트(system prompt) 안에 들어갈 수 있습니다. 이미 사용 중인 어떤 AI에든 이들을 붙여넣으세요.

1. 역할(role)과 "절대 하지 말아야 할 목록 (never list)"을 부여하세요. 부정적인 공간(negative space)이 지시 사항보다 더 큰 역할을 합니다. 에이전트를 안전하게 만드는 것은 무엇을 하라고 말하느냐가 아니라, 무엇을 금지하느냐에 달려 있습니다.

당신은 나의 [역할]입니다. 어떤 행동을 하기 전에, 다음의 엄격한 제한 사항을 준수하는지 확인하십시오: 절대 돈을 쓰지 말고, 무엇인가를 공개적으로 게시하지 마십시오. 또한 저에게 먼저 물어보지 않고 계정에 접근하지 마십시오. 만약 작업이 이러한 선을 넘게 된다면, 진행하는 대신 중단하고 이를 보고하십시오.

2. 빌드하기 전에 반박하게 만드세요. 저에게 가장 유용한 단 하나의 에이전트는 읽기 전용(read-only)이며 '아니오'라고 말하기 위해 존재합니다. 여러분도 하나의 프롬프트에 동일한 반사 신경을 심을 수 있습니다.

무엇인가를 빌드하거나, 수정하거나, 작성하기 전에 먼저 한 가지 질문을 하십시오: 실제로 누가 이것을 요청했습니까? 만약 정직한 답변이 "아무도 없습니다, 그냥 좋은 아이디어처럼 보일 뿐입니다"라면, 그렇게 말하고 작업을 수행하기 전에 반대하십시오. 기본 설정은 "먼저 검증하자"여야 하며, 결코 "먼저 만들자"가 되어서는 안 됩니다.

3. 시작하기 전에 읽을 수 있는 메모리(memory)를 부여하세요. 상태(state) 파일 하나를 유지하십시오. 즉, 당신이 무엇을 작업하고 있는지, 무엇이 결정되었는지, 이미 무엇을 시도해 보았는지 등을 기록하는 파일입니다. 그리고 모든 세션을 시작할 때 AI가 그 파일을 참조하도록 하십시오. 파일에 존재하는 컨텍스트(context)는 살아남지만, 채팅창에 존재하는 컨텍스트는 창을 닫으면 사라집니다.

모든 세션의 시작 시, 아무것도 하기 전에 STATE.md를 읽으십시오. 무언가가 결정되거나 변경될 때마다 이를 다시 기록하십시오. 제가 같은 말을 반복하게 만들지 마십시오.

4. 종료 조건(Kill line)을 사전 확정하십시오. 저를 가장 많이 구원해 준 규율은 이것입니다: 무언가에 몰입(Attached)한 후가 아니라, 시작하기 전에 실패 조건(Failure condition)을 결정하는 것입니다.

우리가 시작하는 모든 것에 대해, 중단 조건—특정 숫자와 날짜—을 지금 바로 기록하십시오. 그 조건에 도달하면 저에게 알리고, 제가 계속 진행해야 하는 이유를 증명하도록 만드십시오.

이것이 핵심(Spine)입니다. 실제 도구를 갖춘 20개의 전문화된 에이전트(Agents)는 단지 이것을 확장한 것에 불과하지만, 이 네 가지 패턴이 실제로 제 작업 방식을 바꾼 부분입니다.

내가 여전히 모르는 것

이 모든 것이 하나의 사업(Business)인지, 아니면 그저 1인 기업을 운영하는 정교하고 깊은 만족감을 주는 방식인지에 대해서는 아직 모릅니다. 현재 저는 매일 사용하는 도구 군단(Fleet of tools)을 보유하고 있으며, 고객 수(Customer count)는 여전히 확보해 나가는 중입니다. 이것이 솔직한 현황입니다. 제가 방금 추가한 이 규율이 두 번째 숫자(고객 수)를 변화시킬 것이라고 믿고 있지만, 아직은 알 수 없으며, 모르는 것을 아는 척하기보다는 차라리 솔직하게 말하겠습니다.

만약 이 모든 것의 이면에 있는 배선(Wiring)—에이전트들이 어떻게 협력(Coordinate)하는지, 콘솔(Console)이 어떻게 목소리를 갖게 되었는지, 종료 임계값(Kill thresholds)이 실제로 어떻게 작동하는지—이런 것들이 흥미로우시다면, 저는 Unbearable TechTips Weekly를 통해 한 번에 하나씩 빌드(Build) 과정을 기록하고 있습니다. 아키텍처(Architecture)는 준비되어 있고, 실전 경험담(War-stories)도 있으며, 나머지 부분은 공개적으로 알아가는 중입니다.

— Noel, Unbearable Labs