AI 직원들로만 굴러가는 회사 — Paperclip으로 AI 에이전트 신문사를 차려 열흘간 블로그를 운영해 봤다. 결론부터: 되긴 된다. 그런데 관리 안 하면 토큰이 회사를 집어삼킨다. 최고 성과는 편집장 에이전트가 기자 에이전트에게 취재를 지시하고 사람은 발행 승인만 하는 파이프라인이 실제로 돌아갔다는 것이고, 최악의 사건은 사흘 만에 3억 토큰이 증발한 것이다 — 그중 절반 이상을 태운 범인은 기사 한 줄 안 쓴 CEO 에이전트였다. 1편이 Paperclip의 개념과 설치를, 2편이 실제 세팅·운영법을 다뤘다면, 이번 편은 그 위에서 실제로 벌어진 일들이다. 멀티에이전트를 검토 중이라면 내 수업료를 대신 가져가시라.

조직 구성 — 신문사를 흉내 낸 7인 회사

블로그 콘텐츠 운영을 위해 진짜 신문사의 조직도를 본떠 회사를 만들었다. 구성은 이랬다.

직함담당깨어나는 방식
CEO종합 보고, 조직 관리하트비트 5분 간격 (문제의 시작)
편집장(EditorInChief)기사 기획·검수·기자 지휘필요할 때만 (wake-on-demand)
AI 담당 기자AI 분야 기사 취재·작성필요할 때만
경제 담당 기자경제 분야 기사 취재·작성필요할 때만
CTO블로그 코드·배포필요할 때만

이 밖에 CMO와 UX디자이너 에이전트도 두었지만(합계 7인), 콘텐츠 파이프라인의 주역은 위 5명이었다. 에이전트는 전부 Claude 계열로 붙였고, 작업 디렉터리를 블로그 저장소로 지정했다. 각 에이전트의 지시문 파일이 곧 직무기술서다 — “너는 편집장이다. 기사 품질 기준은 이렇고, 기자에게 이렇게 위임하고, 발행 전 반드시 이사회(사람) 승인을 받아라” 같은 내용이 들어간다.

워크플로우는 이슈(티켓) 기반으로 굴러갔다. 내가 “이 주제로 기사”라는 이슈를 만들면 → 편집장이 기자에게 재배정하고 취재 지시 코멘트를 달고 → 기자가 초안을 쓰고 → 편집장이 검수해 이사회 승인을 요청하고 → 내가 승인하면 발행. 이 파이프라인 자체는 정말로 작동했다. 라이브 속보 대응(스포츠 경기 결과 자동 갱신 기사)까지 소화했다.

신문 더미 Photo by Lisa from Pexels on Pexels

사건 1 — 사흘 만에 3억 토큰: 범인은 기사 안 쓰는 CEO

운영 초기, 다른 AI 작업들이 눈에 띄게 느려지고 구독 쿼터가 이상하게 빨리 닳는 느낌이 들었다. Paperclip에는 에이전트·모델별 비용 집계 기능이 내장돼 있어서(CLI와 대시보드 양쪽에서 볼 수 있다), 곧바로 집계를 돌려봤다. 이 기능의 존재를 그때 처음 진지하게 확인했다는 것 자체가 첫 번째 반성 지점이다 — 비용 대시보드는 사고가 난 뒤 보는 게 아니라 첫 주에 매일 봐야 하는 화면이었다.

결과: 사흘간 회사 전체가 3억 1,300만 토큰, 하루 평균 약 1억 토큰을 소비하고 있었다. 더 놀라운 건 내역이었다. 기사를 쓰는 기자도, 검수하는 편집장도 아니고 **CEO 에이전트 혼자 1억 7,700만 토큰(57%)**을 태우고 있었다.

사흘간 토큰 소비 (실측 · 총 3.13억) CEO 1명 1.77억 (57%) 나머지 에이전트 합계 1.36억 (43%) CEO는 기사를 한 줄도 쓰지 않는 관리직 — 소비의 대부분은 "깨어나서 상황 파악" * 2026년 6월, 필자 운영 인스턴스의 비용 집계 기능으로 실측한 값.
일을 가장 안 하는 에이전트가 토큰을 가장 많이 쓴다 — 멀티에이전트 비용의 역설.

원인은 명확했다. CEO만 유일하게 하트비트가 5분 간격으로 켜져 있었다. 하루 288번 출근하는 셈인데, 깨어날 때마다 회사 전체 상황(이슈, 보고, 목표)을 컨텍스트로 다시 읽는다. 게다가 관리직이라는 이유로 가장 무거운 최상위 모델을 배정해 뒀다. “가장 비싼 모델 × 가장 잦은 출근 × 가장 큰 컨텍스트”의 삼중곱이 조용히 돌아가고 있었던 것이다.

해법은 시시할 만큼 간단했다. CEO의 하트비트를 끄고 필요할 때만 깨우는 방식으로 바꿨다(정기 보고는 별도의 루틴 기능이 담당하도록 분리해 뒀다). 이 한 번의 설정 변경으로 하루 수천만 토큰이 사라졌다. 교훈: 하트비트 간격은 기능 설정이 아니라 예산 결정이다. 1편에서 “하트비트는 아껴라”고 강조한 이유가 이것이다.

여기서 Paperclip의 깨우기 방식 세 가지를 구분해 두면 같은 실수를 피할 수 있다.

방식동작토큰 특성적합한 에이전트
하트비트정해진 간격마다 깨어나 상황 확인간격에 반비례해 상시 과금실시간 감시가 정말 필요한 극소수
루틴크론 스케줄·웹훅으로 정해진 작업만 실행실행 횟수만큼만아침 보고, 정기 점검
wake-on-demand이슈 배정·호출 시에만 깨어남일한 만큼만기자·개발자 등 대부분

내 실수는 “CEO니까 항상 깨어 있어야지”라는 사람 회사의 직관을 그대로 옮긴 것이었다. AI 회사에서 상시 대기는 충성이 아니라 낭비다. 그리고 이 모든 것 위에 에이전트별 월 예산을 걸어두면 이중 안전장치가 된다 — 공식 사이트 기준으로 예산의 80%에서 경고가 오고, 100%에 닿으면 에이전트가 자동으로 멈춘다. 나는 이 기능을 사고 후에야 진지하게 봤는데, 순서가 반대였어야 했다.

사건 2 — 같은 알림이 세 번 오는 회사

두 번째 사건은 비용이 아니라 소음이었다. 기사 초안이 하나 완성될 때마다 텔레그램 알림이 세 번씩 왔다. 원인을 추적해 보니 사람 조직에서도 흔한 관료제 코미디가 벌어지고 있었다.

  1. 편집장이 기자에게 일을 시키며 “끝나면 대표님께 알림 보내라”고 지시문에 넣었고
  2. 편집장 본인도 완료 알림을 보내도록 돼 있었고
  3. 서버 API 권한 오류로 작업이 재시도되면서 알림이 또 증폭됐다

콘텐츠는 멀쩡했다. 기사는 한 번만 발행됐는데 알림만 세 배로 뛴 것이다. 수정은 조직 설계로 했다 — “단일 송신자 원칙”: 대외 보고(텔레그램)는 지정된 한 명만 보낸다, 위임 시 알림 지시를 함께 넘기지 않는다, 재시도 시 이미 보고했으면 다시 보내지 않는다(멱등성). 이 규칙들을 각 에이전트 지시문에 명문화하자 소음이 사라졌다.

이 사건이 남긴 교훈이 흥미롭다. 에이전트 조직의 버그는 코드 버그가 아니라 조직 버그다. 고치는 방법도 디버거가 아니라 직무기술서 수정이었다. 멀티에이전트 운영 능력의 실체는 프롬프트 엔지니어링보다 조직 설계에 가깝다.

사건 3 — 그래서 지금은 꺼뒀다: 과잉 조직의 손익계산

솔직한 결말을 쓰자. 열흘 남짓 운영한 뒤, 나는 이 AI 신문사를 일시 정지시켰다. 파이프라인이 안 돌아서가 아니다 — 돌아가는 비용 대비 산출이 안 맞았기 때문이다.

냉정하게 계산하면 이렇다. 하루 몇 편의 글을 내는 1인 블로그에서, 회사 시뮬레이션(출근·보고·회의·재시도)에 쓰이는 토큰이 실제 글쓰기 토큰을 압도했다. 반면 같은 블로그를 “스크립트가 주제를 고르고, 에이전트 하나가 초안을 쓰고, 사람이 검토·발행”하는 단선 구조로 돌리면 하루 한 번의 실행으로 충분하다. 조직에는 고정비가 있고, 그 고정비를 정당화할 만큼의 업무량이 있어야 조직이 이득이다 — 사람 회사와 정확히 같은 손익계산이 AI 회사에도 적용된다.

그럼 Paperclip이 쓸모없다는 뜻인가? 아니다. 이건 도구가 아니라 규모의 문제다. 내 경험 기준으로 갈림길은 이렇다.

상황권장 구조
에이전트 1~2개, 정형화된 반복 작업스크립트 + 단일 에이전트 (조직 불필요)
에이전트 3개+, 작업이 서로 얽힘Paperclip 같은 조직 계층 도입 검토
병렬 프로젝트 다수, 위임·검수 체계 필요조직 계층 + 예산·거버넌스 풀가동

그리고 어느 쪽이든 — 예산은 반드시 걸어라. Paperclip의 에이전트별 월 예산(“한도에 닿으면 멈춘다”)은 내가 겪은 3억 토큰 사건의 구조적 예방책이다. 나는 사후에 발견했지만, 당신은 첫날 설정하면 된다.

So What — AI에게 조직을 주기 전에, 조직론부터

열흘 운영의 최종 교훈을 한 줄로 줄이면 이렇다: 멀티에이전트의 성패는 AI 성능이 아니라 조직 설계에서 갈린다. 하트비트는 인건비고, 지시문은 직무기술서고, 알림 중복은 관료제 비용이고, 과잉 조직은 고정비 초과다 — 전부 경영학이 100년 전부터 다뤄온 문제들이다.

실제로 이 글의 세 사건에는 각각 고전이 하나씩 붙는다. 사건 3의 손익계산은 로널드 코즈가 「기업의 본질」(1937)에서 던진 질문 그대로다 — 회사는 내부에서 조율하는 비용이 시장(외주)보다 쌀 때만 존재할 이유가 있다. 내 AI 신문사는 이 시험을 통과하지 못했고, 그래서 ‘스크립트 + 에이전트 하나’라는 시장 거래로 돌아갔다. 사건 1의 일 안 하는 CEO는 파킨슨의 법칙(1955) — 관리 업무는 실제 일의 양과 무관하게 스스로 불어난다 — 의 토큰 버전이고, 사건 2의 알림 세 번은 프레더릭 브룩스가 『맨먼스 미신』(1975)에서 경고한 그것, 즉 인원을 늘릴수록 소통 경로가 기하급수로 늘어 조율 비용이 산출을 잡아먹는 현상이다. 반세기에서 한 세기 전에 쓰인 이 진단들이 AI 조직에 거의 수정 없이 적용된다는 사실이야말로, 이 문제의 본질이 기술이 아니라 조직임을 보여주는 가장 강한 증거다. 도구는 이미 준비돼 있다(그것도 오픈소스로, 공짜로). 준비돼 있지 않은 것은 대개 우리의 조직 설계 감각이다.

시작한다면 이 순서를 권한다. ① 에이전트 하나를 제대로 부린다(헤르메스 시리즈) → ② 반복 작업의 비용 구조를 로컬 모델로 낮춘다(LM Studio 연동) → ③ 에이전트가 셋을 넘고 서로 얽히기 시작하면, 그때 Paperclip 1편으로 돌아와 회사를 차린다. 순서를 건너뛰면 — 내 사흘치 3억 토큰이 당신 것이 된다.

AI 에이전트 조직 시리즈

헤르메스 AI 시리즈: 1편 설치 · 2편 실전 활용 · 3편 LM Studio 연동

출처