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인 개발자의 사이드 프로젝트에는 과한 구조입니다. YC CEO가 60일에 60만 줄을 혼자 짤 때 쓴 스택을 보면 거버넌스 레이어 없이 슬래시 커맨드 스물몇 개로 절차를 고정하는 쪽입니다. 에이전트가 하나면 조직도가 들어갈 자리에 절차서가 들어갑니다.

클라우드 배포가 아직 로드맵. 현재는 로컬 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을 얹어서 조직도로 구성해 보는 쪽이 유력합니다. 결과가 어떻게 나오든 그 자체가 다음 글의 재료가 될 것 같습니다.

덧붙여 두자면, 이후 몇 달간 사주 앱부터 로봇까지 사이드 프로젝트 네 개를 AI와 굴리면서 매번 같은 자리로 되돌아온 회고를 따로 적게 됐는데, 거기서 걸린 자리는 조직도나 예산 상한보다 훨씬 아래층인 컨텍스트 쪽이었습니다. 거버넌스 레이어를 얹기 전에 그 층부터 확인하는 게 순섭니다.