Paperclip은 무엇을 하나요?
Paperclip은 비즈니스를 프롬프트에 답하는 단일 어시스턴트가 아니라, 전문 AI 에이전트들이 조율된 팀으로 움직이는 형태로 모델링하는 오픈소스 오케스트레이션 레이어입니다. 슬로건도 "Claude가 직원이라면, Paperclip은 회사다"라는 식으로 이를 설명합니다 . 하나의 채팅창 대신 미션을 정의하면, Paperclip이 역할 범위가 정해진 에이전트들로 조직도를 세우고, 이들이 보고하고 위임하며 공유된 목표 체인을 따라 일을 진행합니다.
프로젝트의 반응도 이 설명에 걸맞습니다. 2026년 7월 조회 기준 GitHub 저장소는 약 73.5k 스타와 13.7k 포크를 기록했고 , 최신 릴리스는 2026년 7월 7일 태그된 v2026.707.0이었습니다 . 라이선스는 MIT입니다(© 2026 Paperclip Labs, Inc.) .
아키텍처는 의도적으로 익숙한 구성을 택했습니다. Node.js 서버와 React 대시보드, PostgreSQL 백엔드로 이루어져 있으며, Paperclip 계정 없이 완전히 셀프 호스팅할 수 있습니다 . 첫 회사를 만들려면 브라우저 기반 마법사를 띄우는 온보딩 명령 하나면 됩니다.
npx paperclipai onboard --yes저장소와 공식 사이트 양쪽에 문서화된 이 명령은 , "챗봇이 아니라 회사"라는 추상화를 실제로 확인하는 가장 빠른 방법입니다. 아래 섹션에서는 Paperclip이 에이전트를 어떻게 고용하고, 제한하고, 통제하는지 풀어봅니다.
미션이 부서가 되는 과정

"고용" 단계에서 Paperclip의 회사 추상화가 구체적인 형태를 갖습니다. 온보딩 중 미션과 목표를 입력하면, 여러 소개 글에서 "Zeus"라는 이름으로 언급되는 AI CEO 에이전트가 그 목표를 분석하고 필요한 역할을 판단한 뒤, 직함, 직무 설명, 보고 체계를 갖춘 전문 에이전트 조직도를 생성합니다 . 프롬프트에 답하는 단일 어시스턴트 대신, 작업이 시작되기 전부터 마케팅, 엔지니어링, 영업, 운영 에이전트가 계층 구조로 연결됩니다.
그다음 모든 티켓에는 프로젝트가 "goal ancestry"라고 부르는 미션 → 목표 → 프로젝트 → 작업 체인이 붙습니다. 덕분에 작업을 맡은 에이전트는 고립된 한 줄 지시만 보고 움직이는 것이 아니라, 바로 앞 지시 위에 있는 "왜"를 추적할 수 있습니다 . 실제로 이는 "출시 이메일 초안 작성"이라는 지시만 받은 에이전트와, 그 이메일이 기여해야 할 출시 목표와 상위 미션까지 함께 보는 에이전트의 차이입니다. 후자의 경우 톤, 주장, 우선순위가 달라집니다.
실행은 사용자가 계속 확인하는 폴링 루프가 아니라 하트비트 방식으로 돌아갑니다. 에이전트는 일정에 맞춰 깨어나 자신에게 체크아웃된 작업을 확인하고, 필요한 경우 보고 라인을 따라 위아래로 위임하며 실행합니다 . 그 아래에는 두 가지 신뢰성 기본 요소가 있습니다.
- 원자적 작업 체크아웃 — 하나의 작업은 원자적으로 클레임되므로 두 에이전트가 같은 티켓을 가져가 중복 작업을 할 수 없습니다 .
- 하트비트 간 지속되는 에이전트 상태 — 에이전트가 다시 깨어나면 작업은 처음부터 다시 시작하지 않고 이전 컨텍스트를 이어받아 재개됩니다 .
이 상태 모델은 초반에 짚어둘 만합니다. 하트비트를 넘나드는 연속성은 하나의 작업 생애주기 안에서는 유지되지만, 직접 사용해 본 리뷰어들은 에이전트가 기본적으로 이전 세션을 기억하지는 않는다고 지적합니다. 따라서 더 긴 시간축의 메모리는 여전히 의도적으로 별도 레이어를 마련해야 합니다 . 조직도는 작업을 배치하지만, 단일 작업을 넘어 컨텍스트를 계속 살려두는 일은 여전히 운영자의 몫입니다.
강제 제한과 이사회 자리
조직도가 누가 일할지를 정한다면, 컨트롤 플레인은 사람이 개입하기 전까지 얼마나 멀리 갈 수 있는지를 정합니다. Paperclip은 회사, 에이전트, 프로젝트, 목표, 제공업체라는 다섯 단계에서 토큰과 비용 지출을 추적하므로, 비용은 한데 섞이지 않고 귀속됩니다 . 한도에 도달하기 전에 경고 임계값이 알림을 보내고, 사용률이 100%에 이르면 시스템이 해당 에이전트를 믿고 멈추길 기다리는 대신 자동으로 제한하고 일시 중지합니다 . 이 표현은 의도적입니다.
"Hard limits, enforced by the system, not by convention." — Paperclip project documentation (source: paperclipai/paperclip)
도구 루프가 밤새 API 할당량을 태워버리는 모습을 본 사람이라면 이 차이를 바로 이해할 수 있습니다. 대부분의 에이전트 런타임은 예산 관리를 호출자에게 맡기지만, 여기서는 범위가 정해진 일급 기본 요소입니다. 이는 Paperclip과 직접 연결해 써야 하는 원시 프레임워크를 가르는 더 분명한 차이 중 하나입니다.
거버넌스는 이사회 모델을 따릅니다. 사람은 고용과 전략을 승인하고, 언제든 어떤 에이전트든 일시 중지, 재개, 재배정, 재정의, 종료할 권한을 유지합니다 . 설계의 기준점은 두 가지 강한 제약입니다. 에이전트는 다른 에이전트를 자율적으로 고용할 수 없고, AI CEO는 검토되지 않은 전략을 실행할 수 없습니다. "Autonomy is a privilege you grant, not a default"라는 원칙은 멀티 에이전트 데모를 따라다니는 통제 불능 자율성 우려에 대한 직접적인 답처럼 읽힙니다. 당신은 관객석이 아니라 이사회 자리에 앉아 있습니다.
책임성은 추가만 가능한 감사 추적에 기대고 있습니다. 모든 티켓에는 소유자, 상태, 스레드가 붙고, 모든 도구 호출과 API 요청은 수정이나 삭제가 허용되지 않는 형태로 기록됩니다 . 운영자 입장에서 이런 불변성은 에이전트가 무엇을 했는지 재구성할 수 있는 상태와, 그저 제대로 행동했기를 바라는 상태의 차이입니다. 성숙한 워크포스 플랫폼이 자율성과 감사 내보내기, 승인 임계값을 함께 두는 이유도 같습니다 . 실무적으로 한 가지 덧붙이면, 이런 가드레일은 사람이 실제로 읽을 때만 쓸모가 있으므로 예산 알림과 감사 로그는 팀이 실제로 확인하는 채널에 연결해 두는 편이 좋습니다.
별 73.5k, v2026.707.0: 저장소 스냅샷

Paperclip의 성장세는 GitHub 수치에서도 드러납니다. 다만 이 수치는 독립 감사를 거친 값이라기보다 벤더가 제시한 값으로 보는 편이 적절합니다. 이 오픈소스 프로젝트는 2026년 3월 초에 출시됐고, 약 3주 만에 별 30,000개를 넘겼습니다 . 2026년 7월 조회 시점에는 저장소가 약 73,500개의 별과 13,700개의 포크를 보였으며, 최신 릴리스는 2026년 7월 7일 태그된 v2026.707.0였습니다 . 최근까지 날짜 기반 버전 체계로 릴리스가 이어진다는 점은 일회성 출시 흥행이 아니라 활발한 유지보수를 시사합니다.
스택은 익숙하고 셀프 호스팅 구조입니다. PostgreSQL 위에 Node.js 서버와 React 대시보드를 얹었고, Paperclip Labs, Inc. 명의의 MIT 라이선스를 사용합니다. 로컬 실행에는 Node.js 20+와 pnpm 9.15+가 필요하며, 빠른 로컬 실행을 위해 내장 Postgres를 함께 제공하지만 프로덕션에는 외부 Postgres 사용을 권장합니다 . 온보딩은 npx paperclipai onboard --yes라는 단일 명령으로 시작되며, 첫 회사를 생성하는 브라우저 마법사가 열립니다 .
도입을 검토하는 팀이라면 README의 두 가지 주장을 눈여겨볼 만합니다. 하나의 배포에서 회사별 데이터를 완전히 분리한 다중 회사 격리를 지원하며, 회사는 템플릿처럼 내보내고 다시 가져올 수 있고 안전한 공유를 위해 비밀값 자동 제거도 제공된다는 점입니다 . 짚고 넘어갈 caveat도 있습니다. 별도 리서치에서는 공식 문서, 가격, 보안 페이지를 실시간 검색으로 확인하지 못했으므로, 이 수치들은 제3자 검증이 아니라 저장소와 공식 사이트에서 나온 값으로 보는 편이 맞습니다 .
하트비트만 받을 수 있다면 어떤 실행기도 연결됩니다
Paperclip은 의도적으로 모델과 런타임에 묶이지 않도록 설계됐습니다. 하트비트를 받을 수 있는 에이전트라면 어떤 것이든 조직도에 등록할 수 있고, 저장소는 이를 설계 원칙으로 이렇게 표현합니다. “어떤 에이전트든, 어떤 런타임이든, 하나의 조직도에 올린다. 하트비트를 받을 수 있다면 채용된다” . 실제로 이는 Paperclip이 코딩 에이전트 자체가 되려 하지 않는다는 뜻입니다. 코드를 작성하고, 이메일을 보내고, 풀 리퀘스트를 여는 도구들보다 한 추상화 계층 위에 자리하며, 실제 작업은 하위 실행기가 수행하는 동안 누가 무엇을 할지 조율하고, 비용을 추적하며, 거버넌스를 강제하는 것이 Paperclip의 역할입니다 .
목록에 오른 실행기는 현재 에이전트 생태계 대부분을 포괄하며, 목록에 없는 것을 위한 범용 우회로도 두 가지 제공합니다.
| 실행기 | 정체 | Paperclip과의 관계 |
|---|---|---|
| Claude, OpenAI Codex, Google Gemini | 프런티어 모델 기반 코딩/에이전트 런타임 | 역할과 보고 라인 아래 작업자로 등록 |
| Cursor | 린터 기반 자체 수정 기능을 갖춘 IDE 중심 에이전트 | 경쟁자가 아니라 오케스트레이션되는 작업자 |
| OpenCode | 오픈소스 터미널 코딩 에이전트 | 오케스트레이션되는 작업자 |
| Hermes, OpenClaw, Pi | 추가 에이전트 런타임 | 하트비트를 통해 등록 |
| Bash adapter, HTTP webhook | 범용 실행 훅 | 스크립트로 실행하거나 호출할 수 있는 모든 것의 포괄 경로 |
이렇게 보면 경쟁자처럼 보이는 도구들도 직원처럼 재해석됩니다. OpenCode는 Grok Code Fast를 기본 무료 모델로 내세워 출시된 터미널 코딩 에이전트이고(video: DevOps Toolbox) , Cursor는 린터 출력으로 자체 수정하며 자체 다중 에이전트 관리 UI도 구축해 왔습니다(video: Greg Isenberg). 둘 다 Paperclip의 구조적 경쟁자가 아닙니다. Paperclip이 배정하고, 예산을 붙이고, 감사할 수 있는 실행기입니다. Cursor 인스턴스가 엔지니어링 좌석을 맡는 동안 웹훅 어댑터는 내부 운영 엔드포인트에 게시할 수 있고, 둘 다 같은 mission → goal → project → task 체인으로 보고됩니다.
실질적인 장점은 락인 없는 이질성입니다. 팀은 코드 작업을 강한 코딩 에이전트로, 초안 작성은 더 저렴한 모델로, 연결 단계는 Bash나 HTTP 훅으로 라우팅하면서도 하나의 거버넌스 평면 아래 둘 수 있습니다. 앞서 언급한 caveat는 여기에도 적용됩니다. 실행기 목록은 독립적으로 검증된 통합 카탈로그가 아니라 저장소와 공식 사이트에 근거합니다 . 따라서 자체 스택에서 어댑터를 테스트하기 전까지는 이 명단을 벤더가 제시한 것으로 봐야 합니다.
Paperclip과 LangGraph, CrewAI, Relevance AI 나란히 보기

Paperclip과 비교되는 도구들은 크게 두 부류로 나뉩니다. 직접 조립하는 프레임워크와 바로 배포하는 제품입니다. LangGraph, CrewAI, OpenAI의 Agents SDK는 라이브러리입니다. 그래프를 연결하고, 영속성을 추가하고, 거버넌스도 직접 만들어야 합니다. Relevance AI, 그리고 어느 정도는 Zapier, Lindy, Cloudflare Agents는 제품 형태로 제공되지만, 각각은 “회사를 운영한다”는 조직도 추상화보다는 인접한 문제를 겨냥합니다. Paperclip의 주장은 “이들 모두보다 낫다”가 아니라 더 좁습니다. 에이전트별 예산 상한과 감사 추적을 내장한, 배포 가능한 조정 계층이라는 점입니다. 대부분의 프레임워크는 이 부분을 개발자가 직접 해결해야 할 과제로 남겨 둡니다.
LangGraph는 상태를 갖는 에이전트 그래프를 위한 저수준 런타임입니다. 내구성 있는 실행, 스트리밍, 영속성, human-in-the-loop 검사 기능을 제공하고, 그 주변에는 추적과 평가를 위한 LangSmith가 있습니다 (source: LangGraph docs). Paperclip의 heartbeat-and-checkout 모델을 재구성할 수 있는 기본 요소를 제공하지만, 조직도 UI나 에이전트별 지출 원장은 기본으로 제공하지 않습니다. 직접 만들거나, 없다고 봐야 합니다.
CrewAI는 철학적으로 가장 가깝습니다. 상태, 이벤트, 분기를 다루는 결정론적 Flows와 자율적인 역할 기반 Crews를 구분하며, 프로덕션 앱은 Flow에서 시작하고 자율성이 실제로 필요한 곳에서만 Crew에 위임하라고 권장합니다 (source: CrewAI docs). “계획 아래로 보고하는 역할들”이라는 형태는 Paperclip의 계층 구조와 닮았지만, CrewAI는 거버넌스 평면, 이사회 승인 게이트, 변경 불가능한 감사 추적을 기본 제공하지 않습니다.
Relevance AI는 “AI workforce” 경쟁자 중 가장 가깝고, 컴플라이언스 측면에서는 현재 Paperclip보다 앞서 있습니다. RBAC, SSO/SAML, SOC 2 Type II, 월간 비용 및 평가 대시보드, 인간 승인, 1,000개 이상의 통합을 내세웁니다 . Paperclip은 완전한 셀프 호스팅과 MIT 라이선스로 맞서지만, 보안 및 컴플라이언스 태세는 실시간 검색에서 독립적으로 문서화되어 있지 않습니다 .
| 도구 | 분류 | 에이전트별 기본 예산 상한 + 감사 추적 | 배포 가능한 제품 vs. 프레임워크 |
|---|---|---|---|
| Paperclip | 에이전트 조직도 / 조정 계층 | 예(하드 리밋, append-only 로그) | 셀프 호스팅 제품 |
| LangGraph | 상태 기반 에이전트 런타임 | 아니요(직접 구축) | 프레임워크 |
| CrewAI | Flows + 자율 Crews | 아니요 | 프레임워크 |
| Relevance AI | AI workforce SaaS | 부분 지원(대시보드, 승인, RBAC) | 호스팅 제품 |
| n8n / Zapier Agents | 워크플로 자동화 | 아니요(활동 모니터링만) | 제품 |
| Cloudflare Agents / Lindy | 인프라 상태 / 어시스턴트 | 아니요 | 제품 |
나머지 이름들은 인접한 문제를 해결합니다. n8n은 기존 워크플로 안에 에이전트를 노드로 삽입하며, Simple Memory 노드는 기본값이 단 5회 상호작용입니다 ; Zapier Agents는 9,000개가 넘는 앱에 걸친 자동화 그래프에 기대고 ; Lindy는 어시스턴트 중심이며 월 $49.99의 Plus 티어가 있습니다 ; Cloudflare Agents는 인프라 수준에서 동작합니다. 이들 중 회사를 모델링하는 도구는 없습니다. Paperclip의 선택지는 분명합니다. LangGraph나 CrewAI를 처음부터 조립하는 것보다 더 빠르게 작동하는 멀티 에이전트 시스템에 도달하는 대신, 프레임워크 수준의 유연성은 줄어듭니다.
브레인스토밍에는 강하지만, 완성물에는 사람이 필요합니다
Paperclip은 조정과 아이디어 발산에 가장 강하고, 감독 없이 완성된 결과물을 내보내는 데는 가장 약합니다. 직접 써 본 리뷰어들은 브레인스토밍, 전략 구조화, 이메일 초안 작성에서 실제 가치를 보고했지만, 구체적인 실패도 함께 지적했습니다. 적어도 한 리뷰어는 작동하지 않는 생성 웹사이트를 받았고, 상당한 정리가 필요했다고 합니다 . 조정된 활동과 사용 가능한 결과물 사이의 이 간극이, “zero-human company”라는 프레이밍을 믿기 전에 운영자가 직접 검증해야 할 현실적인 시험대입니다.
독립 리뷰들에서 반복되는 실패 유형은 세 가지이며, 각각은 곧바로 운영상의 결과로 이어집니다.
- 환각된 통계. 에이전트의 마케팅 산출물에서 지어낸 숫자가 드러난 사례가 있으므로, 회사가 만들어 낸 모든 수치는 고객, 투자자, 공개 채널에 도달하기 전에 검증해야 합니다 .
- 기본 상태에서는 세션 간 메모리가 없습니다. 에이전트가 이전 세션을 스스로 유지하지 않기 때문에, 연속성을 확보하려면 앞선 맥락을 수동으로 제공하거나 Paperclip 위에 메모리 계층을 만들어야 합니다 .
- 핸드오프를 거치며 오류가 누적됩니다. 마케팅 에이전트의 잘못된 브리프가 곧바로 하위 엔지니어링 티켓으로 넘어갈 수 있으므로, 초기에 생긴 단 하나의 실수가 포착되지 않은 채 조직도 전체로 전파됩니다 .
그렇다고 이 도구를 쓸 수 없다는 뜻은 아닙니다. 오히려 거버넌스를 부가 비용이 아니라 핵심으로 다뤄야 한다는 뜻입니다. Paperclip의 자체 설명도 같은 말을 합니다.
"Autonomy is a privilege you grant, not a default." — Paperclip 프로젝트 문서 (source: github.com/paperclipai/paperclip)
기술 창업자가 가져갈 결론은 좁고 검증 가능합니다. Paperclip을 인간의 조정 부담을 줄여 주는 조정 계층으로 다루되, 판단의 필요까지 제거한다고 보지는 마십시오. 범위가 명확하고 위험이 낮은 작업에 두세 개의 에이전트로 시작하고 , 되돌릴 수 없는 일에는 반드시 human in the loop를 유지하며, 에이전트별 예산 상한과 append-only 감사 추적을 본래 의도된 가드레일로 활용해야 합니다. 핸드오프 품질이 유지된다는 점을 확인한 뒤에만 조직도를 확장하십시오. 제대로 작동하는 이사회를 둔 회사처럼 운영해야 합니다. 자리를 비운 회사처럼 운영해서는 안 됩니다.
자주 묻는 질문
Paperclip은 어떤 LLM 제공업체와도 작동하나요?
네. Paperclip은 애초에 모델과 런타임에 종속되지 않도록 설계됐고, 이를 자체 문구로 이렇게 요약합니다. “어떤 에이전트든, 어떤 런타임이든, 하나의 조직도. 하트비트를 받을 수 있다면 채용됩니다” . 명시된 실행기는 Claude, OpenAI Codex, Google Gemini, Cursor, Hermes, OpenClaw, Pi, OpenCode이며, 범용 Bash 및 HTTP 웹훅 어댑터도 포함됩니다 . 하트비트 신호에 응답할 수 있는 실행기라면 조직도의 노드로 등록할 수 있으므로, 어떤 모델을 쓸지는 플랫폼이 아니라 사용자가 정합니다.
AI 에이전트가 Paperclip에서 다른 에이전트를 채용할 수 있나요?
아니요. 이 제한은 의도된 설계입니다. AI CEO 에이전트는 여러 글에서 “Zeus”라는 이름으로 소개되며, 미션을 분석하고 목표에 필요하다고 판단한 역할을 추천하지만, 해당 역할이 실제로 생기려면 인간 이사회 디렉터가 각 채용을 승인해야 합니다 . 에이전트가 스스로 인원을 늘릴 수 없고, CEO도 검토되지 않은 전략을 실행할 수 없습니다. Paperclip은 이 원칙을 분명히 말합니다. “자율성은 기본값이 아니라, 당신이 부여하는 권한입니다” . 인원과 전략은 이사회 좌석 뒤에서 계속 통제됩니다.
비용 한도는 어떻게 집행되나요?
Paperclip은 회사, 에이전트, 프로젝트, 목표, 제공업체라는 다섯 가지 차원에서 토큰 및 달러 지출을 추적합니다 . 경고 임계값에 도달하면 한도에 닿기 전에 알림이 표시되고, 사용률이 100%에 이르면 시스템이 관련 에이전트를 자동으로 제한하거나 일시 중지합니다. 이는 “시스템이 집행하는 하드 리밋”으로 설명되는 플랫폼 수준의 강제 한도이며, 에이전트가 설득해서 넘어갈 수 있는 설정 가능한 소프트 캡이 아닙니다 . 예산 집행은 나중에 덧붙인 기능이 아니라 런타임의 기본 요소입니다.
Paperclip은 프로덕션에서 사용할 준비가 되었나요?
조건부로 그렇습니다. 최신 릴리스인 v2026.707.0(2026년 7월 7일)은 활발히 유지관리되고 있으며, 2026년 7월 조회 기준 저장소의 스타 수는 약 73.5k개였습니다 . 다만 알려진 빈틈도 남아 있습니다. 기본적으로 세션 간 메모리가 없고, 산출물 품질이 들쭉날쭉하며, 에이전트 간 인계 과정에서 오류가 누적될 수 있습니다 . 중요한 지점에서 사람이 검토하는 범위가 명확한 내부 업무에는 잘 맞지만, 사람이 개입하지 않는 엔드투엔드 전달 시스템으로 쓰기에는 덜 적합합니다.
Paperclip은 LangGraph나 CrewAI와 무엇이 다른가요?
LangGraph와 CrewAI는 사용자가 애플리케이션 안에 조립해 넣는 라이브러리이고, Paperclip은 조율 계층에서 바로 배포할 수 있는 제품입니다 . Paperclip은 조직도 UI, 에이전트별 하드 지출 한도, append-only 방식의 변경 불가능한 감사 추적, 인간 승인 계층을 기본으로 제공합니다. LangGraph는 상태를 가진 에이전트를 위한 저수준 런타임을 제공하고, CrewAI는 결정론적 Flows와 자율적 Crews를 나누지만, 둘 다 예산 한도, 조직도, 승인 게이트를 기본 기능으로 내장해 제공하지는 않습니다. 즉 프레임워크의 유연성을 일부 내려놓는 대신, 거버넌스가 갖춰진 멀티 에이전트 시스템에 더 빠르게 도달하는 선택입니다.
이 글이 도움이 되셨다면, 새 글이 올라올 때마다 이메일로 받아보세요.