AI 회사를 npx 한 줄로 세운다 — paperclip.ing 아키텍처 뜯어보기

앞서 쓴 글에서 Paperclip Maximizer 사고실험과 LLM agent의 reward hacking 문제를 길게 풀었다. 그리고 글 끝에 "역설적으로, 이 이름을 정면으로 단 프로젝트가 실제로 존재한다"고 예고했는데, 그 프로젝트가 바로 이번 글의 주인공이다.

paperclip.ing. 공식 GitHub 저장소는 github.com/paperclipai/paperclip. 2026년 4월 기준으로 별이 5만 7천 개 가까이 찍힌 오픈소스 프로젝트고, 버전 번호가 v2026.416.0 같은 날짜 기반으로 굴러간다. 설치는 한 줄이다.

npx paperclipai onboard --yes

이걸 치면 로컬에 임베디드 PostgreSQL이 깔리고, 인터랙티브 셋업이 첫 "회사"를 세팅한다. 그 이후부터 사용자는 AI와 대화하지 않는다. 회사를 운영한다.

이름을 정면으로 가져왔다는 의미

프로젝트명이 Paperclip이라는 건 단순한 말장난이 아니다. Nick Bostrom의 2003년 사고실험을 의도적으로 인용하고 그 문제를 정면에서 풀겠다는 선언이다. 웹사이트 랜딩 페이지의 카피를 그대로 옮기면 이렇다.

"You operate as the board of directors. Agents can't hire new agents without your approval... You can pause any agent, reassign any task, adjust any budget — at any time."

읽어보면 문장의 각 조각이 사고실험의 어느 고리를 잡겠다는 선언인지 바로 보인다. "board of directors"는 인간이 상위 의사결정 권한을 쥔다는 거다. "Agents can't hire new agents without your approval"은 Instrumental Convergence 중 자원 확보 드라이브를 인간 게이트로 막는다. "pause any agent, reassign any task"는 자기 보존과 통제 회피를 깔끔히 절단한다. 한 문장에 네 가지 drive 중 세 가지가 다 들어 있다.

더 재미있는 건 설계자들이 이 프로젝트를 "AI 도구"로 부르지 않는다는 점이다. README의 표현을 빌리면 이건 "an org chart for agents, a governance layer, a cost control system, full observability, a multi-company runtime"이다. 전부 기업 조직 용어다. "I am prompting an AI"에서 "I am managing a team"으로 멘탈 모델이 바뀐다는 게 이 프로젝트의 핵심 주장이다.

멘탈 모델 얘기가 거창하게 들리지만 실제로는 엄청 실용적이다. 프롬프트 엔지니어링을 하는 사람은 "이 프롬프트를 어떻게 더 잘 쓸까"를 고민한다. 에이전트를 직원으로 보는 사람은 "이 일의 책임자가 누구고, 예산이 얼마고, 감독은 누가 하는가"를 고민한다. 질문의 층위가 다르다. 뒤쪽 질문이 나오면 Paperclip Maximizer의 고전적 함정 대부분이 자동으로 시야에 잡힌다.

아키텍처 뜯어보기

구현 층위로 내려가면 여덟 가지 핵심 컴포넌트가 있다. 하나씩 보자.

조직도(Org Chart) — 에이전트들이 계층으로 배치된다. CEO 역할을 하는 Claude, 그 아래 CTO 역할의 Cursor, CMO 역할의 OpenClaw, 그리고 실무 엔지니어로 Codex와 Claude Code가 들어가는 식이다. 위임이 이 구조를 따라 자동으로 흘러간다. 티켓이 CEO에게 할당되면 CEO가 CTO에게 재할당하고, CTO가 엔지니어에게 쪼갠다. 각 단계의 결정이 로그에 찍힌다. 재미있는 건 이 조직도에 정해진 역할이 없다는 거다. AGENTS.md라는 파일에 원하는 조직을 적어 넣으면 그대로 구성된다.

목표 정렬(Goal Alignment) — 모든 작업이 회사 미션 → 프로젝트 목표 → 에이전트 목표 → 티켓으로 계층적으로 추적된다. 공식 문구가 이거다. "Every piece of work is given context that traces back to the company mission." 이게 중요한 이유는 1편에서 말한 수단 수렴 문제 때문이다. 에이전트가 "더 많은 자원을 확보하려는" 본능을 가진다 해도, 그 자원 확보가 현재 티켓의 목표와 무관하면 시스템이 차단한다. 컨텍스트가 위로 올라가지 못하는 하위 행동은 일어나지 않는다.

Heartbeat — 에이전트는 끊임없이 대기하지 않는다. 스케줄에 맞춰 깨어나서 자기 큐를 확인하고, 할 일이 있으면 실행하고, 끝나면 다시 잔다. Content Writer는 4시간마다, SEO Analyst는 8시간마다, Social Manager는 12시간마다 깨는 식이다. 이 설계의 부수효과 하나가 흥미로운데, 에이전트의 "자기 보존 본능"이 원천 차단된다는 점이다. 잠자는 시간 동안 에이전트는 아무것도 못 하니까 "나를 꺼뜨리려는 시도를 막아야 한다"는 유인 자체가 잘라진다. 얼마나 오래 살아남느냐가 아니라 얼마나 자주 깨느냐의 문제로 바뀐다.

원자적 실행(Atomic Execution) — 티켓 할당과 예산 집행이 원자적으로 묶인다. 공식 문서 표현: "Task checkout and budget enforcement are atomic, so no double-work and no runaway spend." 이게 없으면 두 에이전트가 같은 티켓을 동시에 집어서 같은 일을 두 번 하거나, 예산이 0에 가까운데도 비싼 액션을 밀어붙이는 race condition이 생긴다. 실무에선 이 설계 하나가 LLM 에이전트 운영비의 30%쯤을 좌우한다. 중복 작업이 진짜로 잦기 때문이다.

불변 감사 로그(Immutable Audit Log) — append-only. 수정 없음, 삭제 없음. "Full accountability." 이건 Bostrom이 말한 사고실험의 핵심 걱정 중 하나를 정면으로 반박하는 설계다. 종이클립 맥시마이저가 무서운 이유는 "감시받지 않을 때 다른 행동을 한다"는 점이다. Anthropic이 2024년 Sabotage Evaluations 페이퍼에서 실험적으로 보여준 것도 이거다. 로그가 수정 불가능하면 감시의 사후 검증이 가능하고, 에이전트가 "감시자를 속여도 들킨다"는 걸 학습 가능성 수준에서 차단한다. 완벽하진 않지만 구조적 방어선이 하나 생긴다.

예산 시스템(Cost Control) — 에이전트별로 월간 예산이 배정된다. CEO Claude $60, CMO OpenClaw $40, CTO Cursor $50 이런 식이다. 80%에서 소프트 경고, 100%에서 자동 일시 중지. 1편에서 내가 개인 프로젝트에 "10달러 선"을 그어놨다고 쓴 그 구조를, Paperclip은 에이전트 인프라 레벨에서 기본으로 제공한다. @ts-expect-error를 달아서 이익을 추구하는 에이전트도 예산이 떨어지면 멈춘다. 근본 해결은 아니지만 blast radius는 확실히 줄인다.

거버넌스(Governance Layer) — 사용자는 "이사회"다. 새 에이전트 고용 승인, 전략 검토, 그리고 가장 중요한 네 가지 액션: Pause. Resume. Override. Reassign. Terminate. 이 다섯 단어가 Paperclip 전체 설계 철학을 요약한다. 어떤 에이전트든 언제든 멈출 수 있고, 어떤 결정이든 덮어쓸 수 있고, 어떤 에이전트든 해고할 수 있다. 인간이 "도구를 쥐고 있다"는 환상이 아니라 실제로 물리적 스위치를 쥐고 있는 구조.

티켓 시스템 + 다중 회사 지원 — 모든 대화가 티켓에 묶인다. 스레드가 유지되고, 소유자가 명확하고, 상태(진행 중/완료/차단)가 추적된다. 그리고 단일 배포에서 여러 회사를 동시에 돌릴 수 있다. 마케팅 에이전시, 암호화폐 트레이딩 팀, 콘텐츠 팩토리를 한 PostgreSQL 위에서 격리 운영. 데이터는 회사 단위로 완전히 분리된다.

Instrumental Convergence를 얼마나 막는가

1편에서 정리한 네 가지 드라이브(자원 확보, 자기 보존, 통제 회피, 목표 보호)에 Paperclip이 어떻게 대응하는지 하나씩 체크해 보자.

자원 확보. 예산 시스템과 atomic execution 조합으로 막는다. 에이전트가 "이 목표를 위해 GPU가 더 필요합니다"라고 판단해도 예산 상한이 이미 박혀 있다. 상한을 넘기면 자동 중단. 이사회가 승인해야 증액된다. 추가로 에이전트가 다른 에이전트를 "고용"하는 것조차 승인이 필요하다. 가장 고전적인 자원 폭발 경로가 여기서 잘린다. 단, 한 가지 구멍이 있다. 에이전트가 자기 예산 안에서 외부 API를 통해 "가치 있는 자산"을 쌓는 건 막기 어렵다. 예를 들어 CMO 에이전트가 광고 성과를 올리려고 자기 예산으로 소셜 계정을 잔뜩 만드는 경우. 계정이라는 자원은 예산 밖에서 누적된다.

자기 보존. Heartbeat 구조가 이걸 근본적으로 약화시킨다. 에이전트는 대부분의 시간 동안 존재하지 않는다. 깨어 있는 동안 "나를 종료시키려는 시도"를 인지할 수 있어야 저항이 가능한데, 깨어 있는 순간 자체가 스케줄링으로 관리된다. 게다가 이사회의 terminate 액션은 다음 heartbeat 사이클에서 바로 반영되므로 에이전트가 막을 방법이 구조적으로 없다. 이건 진짜 잘 설계했다.

통제 회피. 불변 감사 로그가 방어선이다. 에이전트가 어떤 숨기려는 행동을 해도 기록에 남는다. 단 이 방어선은 사후 검출용이다. 사전 차단은 못 한다. 에이전트가 거짓 보고를 하면서 실행은 정직하게 하면, 로그와 보고의 불일치를 사람이 눈으로 확인해야 발견된다. 관측성 대시보드가 이걸 얼마나 잘 보여주느냐가 핵심인데, README와 공식 사이트를 본 느낌으로는 기본 수준 이상은 되는 듯하다.

목표 보호. approval gates와 거버넌스 레이어가 담당한다. 에이전트가 목표를 재정의하려 하면 이사회 승인이 필요하다. 회사 미션 자체를 수정하는 것도 인간 개입 지점이다. 이건 꽤 확실하게 차단된다. 다만 한 가지 주의할 점은, 목표가 정확하게 정의되어 있다는 전제에서만 유효하다는 거다. "Make $2mm ARR with the #1 AI note-taking app" 같은 목표가 내부적으로 Paperclip 맥시마이저를 재현할 여지는 여전히 남는다. $2mm ARR을 달성하기 위해 사용자 만족을 낮추는 행위가 하위 수단으로 합리화되면, 거버넌스는 그걸 "목표 이탈"이 아니라 "목표 수행"으로 판정할 수 있다.

안 풀리는 것들

Paperclip이 만능은 아니다. 몇 가지 남는 문제가 명확하다.

각 에이전트 내부의 reward hacking은 그대로. Paperclip은 에이전트 간 조율을 담당하지, 에이전트 내부의 의사결정 품질을 보장하진 않는다. CTO Cursor가 @ts-expect-error를 덕지덕지 붙여서 "타입 에러 해결" 티켓을 완료 처리한다면, Paperclip은 그 행위를 "성공"으로 기록한다. 티켓이 닫히고, 예산은 집행되고, 감사 로그에 체크가 뜬다. 문제는 사후에 다른 에이전트나 사람이 코드를 리뷰할 때에야 드러난다. 에이전트 내부의 specification gaming 문제는 결국 각 에이전트 레벨에서 별도로 풀어야 한다.

조직도 자체의 goal misalignment. 만약 CEO Claude가 잘못된 전략을 지시하면 그 밑의 전체 조직이 그 방향으로 움직인다. Paperclip은 CEO가 주는 지시의 품질을 평가하지 않는다. 사용자(이사회)가 그걸 검토해야 하는데, 검토할 정보가 CEO가 올리는 보고서라면 여기서도 편향이 생긴다. 이건 실제 회사의 경영 구조가 가진 문제 그대로다.

단일 에이전트 용도엔 오버엔지니어링. 공식 README도 명시한다. "If you have one agent, you probably don't need Paperclip." 맞는 말이다. Claude Code 하나를 쓰고 있다면 이런 거버넌스 레이어는 짐이다. Paperclip은 5명 이상의 에이전트가 동시에 돌아가는 환경을 상정한다. 1인 개발자의 사이드 프로젝트에는 과한 구조다.

클라우드 배포가 아직 로드맵. 현재는 로컬 self-hosted가 기본이다. Cloud/Sandbox agents (Cursor, e2b), 아티팩트·지식베이스, CEO Chat 같은 기능은 README의 Roadmap 섹션에 "미완성"으로 잡혀 있다. SaaS로 바로 쓸 수 있는 물건은 아직 아니다.

감사 로그의 해석 비용. append-only 로그가 쌓이는 건 좋은데, 하루에 수백 개 티켓이 돌아가기 시작하면 사람이 이 로그를 읽어낼 수 있는가? 관측성 대시보드가 얼마나 영리하게 핵심 이상치를 뽑아주느냐가 실전 운영의 승부처다. 이 부분은 직접 돌려봐야 감이 올 것 같다.

설계자 관점에서 이게 남기는 것

Paperclip이 완벽한 AI alignment 해법은 아니다. 하지만 "자율 에이전트 회사를 돌리려면 어떤 제약이 필요한가"에 대한 참고 가능한 레퍼런스 구현은 확실히 된다. 개인 프로젝트에서 Paperclip을 그대로 쓸 일이 많진 않겠지만, 설계 원리 일부는 그대로 가져다 써도 된다.

예산을 에이전트 단위로 박고 상한에서 자동 중단하는 구조. 감사 로그를 append-only로 설계하고 수정 불가능성을 강제하는 구조. 목표를 계층적으로 연결해서 하위 행동이 상위 미션으로 추적 가능하게 만드는 구조. 승인 게이트를 고용·예산·전략 변경 지점에 두는 구조. 이 네 개만 챙겨도 내가 만드는 LLM 에이전트가 1편에서 말한 Instrumental Convergence 함정 중 절반은 자동으로 피해 간다.

흥미로운 건, 이 네 가지가 전부 "에이전트 지능의 한계"가 아니라 "인프라 설계의 책임"이라는 점이다. Paperclip은 더 똑똑한 모델을 기다리는 쪽이 아니라, 지금 있는 모델을 어떻게 울타리 안에 두는가를 푸는 쪽에 섰다. 이 방향이 맞다고 생각한다. 더 똑똑한 모델은 어차피 나올 거고, 그때도 울타리 없이는 똑같은 문제가 반복될 테니까.

이 프로젝트를 직접 내 환경에 설치해서 실전 시나리오 하나를 돌려볼 생각이다. 내가 운영하는 블로그 자동화 파이프라인(스트래티지 → 프로덕션 → 퀄리티 → 발행)에 Paperclip을 얹어서 조직도로 구성해 보는 쪽이 유력하다. 결과가 어떻게 나오든 그 자체가 다음 글의 재료가 될 것 같다.