앞서 쓴 글에서 Paperclip Maximizer 사고실험과 LLM agent 의 reward hacking 이야기를 길게 했습니다. 그 글 끝에 이 이름을 정면으로 단 프로젝트가 실제로 있다고 적어 두었는데, 이번에는 그 프로젝트 이야기입니다.
paperclip.ing 이라는 오픈소스 프로젝트이고, GitHub 에서 별이 엄청나게 많이 붙어 있습니다. 설치는 한 줄입니다.
npx paperclipai onboard --yes
이걸 치면 로컬에 임베디드 PostgreSQL 이 깔리고, 인터랙티브 셋업이 첫 "회사"를 만들어 줍니다. 그다음부터 사용자는 AI 와 대화한다기보다 회사를 운영하는 쪽이 됩니다. 처음 이 문장을 읽었을 때는 마케팅 문구라고 생각했는데, 구조를 따라가 보니 말 그대로 그렇게 만들어져 있었습니다.
명령어 끝에 붙은 --yes 가 조금 눈에 걸렸습니다. 셋업 중에 묻는 걸 전부 예로 넘기겠다는 뜻인데, 이게 돈을 쓰고 바깥에 글을 올릴 수도 있는 에이전트들의 회사를 세우는 명령이라는 걸 생각하면 묘합니다. 처음 해 보는 거라면 저는 --yes 를 빼고 무엇을 묻는지 하나씩 읽어 볼 것 같습니다. 회사를 세우는 데 한 줄이면 충분하다는 게 이 프로젝트의 자랑이기도 하고, 동시에 제가 제일 먼저 경계하게 되는 부분이기도 합니다.
이름부터
Paperclip 이라는 이름을 붙인 건 말장난 정도가 아니라고 봅니다. Nick Bostrom 의 사고실험은 AI 가 무서울 수 있다는 이야기를 할 때 가장 먼저 꺼내는 예시입니다. 그 이름을 자기 프로젝트에 붙였다는 건, 그 문제를 알고 있고 거기서부터 설계를 시작했다는 뜻으로 읽힙니다. 농담 반 선언 반 같은 느낌이 있습니다. 그리고 이름이 매번 쓰는 사람에게 말을 거는 효과도 있을 것 같습니다. 터미널에 paperclip 을 칠 때마다 클립 공장 이야기가 한 번씩 떠오르면, 적어도 이걸 가볍게 다루지는 않게 되지 않을까 싶습니다. 반대로 너무 익숙해져서 아무 느낌이 없어질 수도 있는데, 그건 이름이 할 수 있는 일의 한계 같습니다. 랜딩 페이지 문구는 이렇습니다.
"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 는 사람이 가장 위에서 결정권을 갖는다는 이야기입니다. 승인 없이는 에이전트가 다른 에이전트를 고용하지 못한다는 건 Instrumental Convergence 에서 말하는 자원 확보 욕구를 사람의 승인으로 막겠다는 것이고, 아무 때나 멈추고 일을 다른 데 넘길 수 있다는 건 자기 보존과 통제 회피를 끊겠다는 것입니다. 한 문장 안에 네 가지 drive 가운데 세 개가 들어 있습니다.
이사회라는 단어를 고른 것도 재미있습니다. 실제 회사의 이사회는 가끔 모여서 큰 결정만 합니다. 그런데 여기서 사람이 하는 일을 보면 고용 하나하나를 승인하고, 예산을 조정하고, 일을 다른 에이전트에게 넘깁니다. 이사회라기보다는 팀장이 하는 일에 더 가깝다는 생각이 들었습니다. 이름은 이사회인데 일은 팀장만큼 해야 하는 구조라면, 사람이 지치는 쪽이 먼저 올 수도 있겠다 싶습니다.
설계한 사람들은 이걸 "AI 도구"라고 부르지 않습니다. README 에는 "an org chart for agents, a governance layer, a cost control system, full observability, a multi-company runtime" 이라고 적혀 있습니다. 전부 회사에서 쓰는 말입니다. 프롬프트를 쓰는 사람에서 팀을 관리하는 사람으로 머릿속 그림을 바꾸라는 게 이 프로젝트가 하고 싶은 말 같습니다.
이게 거창하게 들리는데 실제로는 꽤 실용적인 차이라고 봅니다. 프롬프트를 다듬는 사람은 "이걸 어떻게 더 잘 시킬까"를 고민합니다. 에이전트를 직원으로 보는 사람은 "이 일은 누가 책임지고, 예산은 얼마고, 누가 감독하나"를 고민합니다. 뒤쪽 질문을 하기 시작하면 Paperclip Maximizer 에서 걱정하던 함정 대부분이 저절로 시야에 들어옵니다.
저는 여기서 하나 더 궁금해졌습니다. 직원으로 보기 시작하면 "이 사람이 혼자 해도 되는 일"과 "위에 물어보고 해야 하는 일"을 나누게 됩니다. 회사에서 신입에게 처음부터 결제 권한을 주지 않는 것과 비슷합니다. 그런데 그 구분을 어디에 두느냐는 결국 사람이 정해야 하고, Paperclip 이 그 구분을 대신 정해 주지는 않습니다. 고용, 예산, 전략은 승인 대상으로 정해져 있는데, 그 밖의 일은 어떻게 되는지가 계속 마음에 걸렸습니다.
안을 들여다보면
조직도부터 보면, 에이전트들이 계층으로 배치됩니다. CEO 역할에 Claude, CTO 에 Cursor, CMO 에 OpenClaw, 그 아래 실무 엔지니어로 Codex 와 Claude Code 가 들어가는 식입니다. 티켓이 CEO 에게 떨어지면 CEO 가 CTO 에게 넘기고, CTO 가 엔지니어들에게 쪼개서 나눠 줍니다. 단계마다 무엇을 결정했는지가 로그에 남습니다. 역할이 고정되어 있지는 않고, AGENTS.md 에 원하는 조직을 적어 넣으면 그대로 만들어집니다.
서로 다른 회사의 모델에 CEO, CTO 직함을 붙여 놓은 그림이 처음엔 좀 웃겼습니다. 모델 입장에서는 직함이 바뀐다고 해서 크게 달라지는 건 없을 것 같습니다. 프롬프트 첫 줄이 "당신은 CTO 입니다"로 바뀌는 정도일 겁니다. 의미가 생기는 건 모델 쪽이 아니라 그 직함에 붙은 권한 쪽이라고 봅니다. 누구에게 일을 넘길 수 있는지, 얼마까지 쓸 수 있는지가 직함에 묶여 있어서, 이름보다는 권한표에 가깝습니다.
서로 다른 모델이 위아래로 붙어 있다는 것도 조금 신경 쓰입니다. CEO 가 쓴 지시를 CTO 가 받아서 다시 쪼개고, 그걸 엔지니어가 받습니다. 사람 회사에서도 지시가 두 단계만 내려가면 처음 의도와 꽤 달라지는데, 여기서는 단계마다 모델이 바뀝니다. 같은 문장을 읽어도 모델마다 중요하게 보는 부분이 다를 테니, 티켓이 아래로 내려갈수록 원래 무엇을 원했는지가 조금씩 흐려질 것 같습니다. 목표 정렬이라는 장치가 따로 있는 이유가 그거라고 생각합니다.
그다음이 목표 정렬입니다. 모든 작업이 회사 미션에서 프로젝트 목표, 에이전트 목표, 티켓으로 이어지는 줄을 타고 추적됩니다. 공식 문구로는 "Every piece of work is given context that traces back to the company mission." 입니다. 앞 글에서 말한 수단 수렴 때문에 이게 중요하다고 봅니다. 에이전트가 더 많은 자원을 모으려는 경향을 보여도, 그게 지금 맡은 티켓의 목표와 이어지지 않으면 시스템이 막습니다. 위로 맥락을 대지 못하는 행동은 일어나지 않게 해 둔 겁니다.
한편으로는 이게 너무 빡빡하면 어떨까 하는 생각도 했습니다. 사람은 일하다가 옆에 보이는 걸 같이 고치곤 합니다. 지금 티켓과는 상관없지만 오래된 설정 하나를 정리한다든가 하는 것들입니다. 그런 일은 미션까지 줄을 대기가 애매합니다. 에이전트가 그런 정리를 못 하게 되면 안전해지기는 하는데, 시키지 않은 좋은 일도 같이 사라집니다. 저는 에이전트에게는 그게 맞는 쪽이라고 보지만, 그만큼 사람이 티켓을 더 잘게 많이 써 줘야 할 것 같습니다.
Heartbeat 라는 구조도 있습니다. 에이전트가 계속 깨어서 기다리지 않고, 정해진 시간에 일어나 자기 큐를 보고, 할 일이 있으면 하고, 끝나면 다시 잡니다. 글 쓰는 에이전트는 몇 시간마다, 분석하는 에이전트는 그보다 길게 깨는 식입니다. 이 설계에서 재미있는 부수 효과가 하나 있는데, 에이전트가 자기 보존을 신경 쓸 이유가 거의 사라진다는 겁니다. 자는 동안에는 아무것도 못 하니까 "나를 끄려는 시도를 막아야 한다"는 동기가 생길 틈이 없습니다. 얼마나 오래 살아남느냐가 아니라 얼마나 자주 깨느냐의 문제가 됩니다.
그런데 이 그림을 사람 쪽에서 보면 또 다릅니다. 에이전트가 몇 시간마다 깬다는 건 새벽에도 깬다는 뜻입니다. 이사회인 사람은 그 시간에 자고 있습니다. 에이전트가 새벽 세 시에 일어나서 뭔가를 하고 다시 잠들면, 사람은 아침에 로그로 그걸 알게 됩니다. 승인이 필요한 일이면 아침까지 기다리겠지만, 승인 대상이 아닌 일은 그냥 진행됩니다. 에이전트의 자기 보존을 막으려고 만든 구조가, 사람이 안 보는 시간에 일이 진행되는 구조이기도 하다는 게 재미있습니다.
원자적 실행은 티켓을 가져가는 일과 예산을 쓰는 일을 한 번에 묶는 겁니다. "Task checkout and budget enforcement are atomic, so no double-work and no runaway spend." 이게 없으면 두 에이전트가 같은 티켓을 동시에 집어 같은 일을 두 번 하거나, 예산이 바닥났는데도 비싼 작업을 밀어붙이는 race condition 이 생깁니다. 에이전트를 여러 개 돌려 보면 중복 작업이 생각보다 자주 생기고, 운영비에서 꽤 큰 몫이 거기로 나갑니다. 화려한 기능은 아닌데 이런 게 실제로는 제일 고마운 부분일 것 같습니다.
사람 팀으로 치면 "그거 제가 하고 있었는데요"를 시스템이 대신 말해 주는 셈입니다. 그런데 앞의 Heartbeat 와 같이 놓고 보면 궁금한 게 하나 생깁니다. 티켓을 집어 간 에이전트가 일을 하다 말고 잠들면 그 티켓은 다음에 그 에이전트가 깰 때까지 묶여 있는 걸까요. 중복을 막는 장치가 때로는 기다림을 만들 수도 있겠다 싶습니다. 급한 티켓이면 이사회가 Reassign 으로 풀어 주면 되겠지만, 그러려면 사람이 그 티켓이 묶여 있다는 걸 먼저 알아야 합니다.
감사 로그는 append-only 입니다. 고칠 수도 없고 지울 수도 없습니다. 사고실험에서 진짜 무서운 건 감시받지 않을 때 다르게 행동하는 AI 인데, Anthropic 이 Sabotage Evaluations 에서 실험으로 보여 준 것도 그 방향이었습니다. 로그를 고칠 수 없으면 나중에라도 확인할 수 있고, 감시자를 속여도 결국 들킨다는 구조가 하나 생깁니다.
지울 수 없다는 건 반대로 실수도 지울 수 없다는 뜻이기도 합니다. 에이전트가 작업 중에 API 키나 남의 개인 정보를 로그에 그대로 적어 버리면 그것도 영원히 남습니다. 이런 경우를 어떻게 다루는지는 README 에서 찾지 못했습니다. 감사 로그를 고칠 수 없게 하는 것과, 로그에 무엇이 들어가는지를 정하는 건 따로 생각해야 하는 일 같습니다.
예산은 에이전트마다 따로 잡힙니다. CEO 에게 얼마, CMO 에게 얼마 하는 식이고, 80% 에서 경고가 뜨고 100% 에서 자동으로 멈춥니다. 앞 글에서 제가 개인 프로젝트에 "10달러 선"을 그어 놨다고 썼는데, 그걸 에이전트 인프라 단위에서 기본 기능으로 넣어 둔 셈입니다. @ts-expect-error 를 붙여 가며 점수를 따는 에이전트도 예산이 떨어지면 멈춥니다. 문제를 없애 주지는 않아도 사고가 났을 때 번지는 범위는 확실히 줄어듭니다.
다만 예산은 돈으로만 셉니다. 비싼 일과 되돌릴 수 없는 일은 같지 않은 것 같습니다. 메일 한 통 보내는 건 거의 공짜인데 한번 나가면 다시 거둘 수 없고, 반대로 큰 모델로 긴 분석을 돌리는 건 비싸지만 결과가 마음에 안 들면 버리면 그만입니다. 예산 상한은 앞쪽을 거의 못 잡고 뒤쪽을 잘 잡습니다. 돈이 위험을 꽤 잘 대신해 주긴 하지만 완전히 같은 건 아니라는 생각이 들었습니다.
거버넌스 쪽에서는 사용자가 이사회입니다. 새 에이전트 고용을 승인하고, 전략을 검토하고, 그리고 Pause. Resume. Override. Reassign. Terminate. 이 다섯 단어가 이 프로젝트의 설계 생각을 거의 다 담고 있다고 봅니다. 어떤 에이전트든 언제든 멈출 수 있고, 어떤 결정이든 덮어쓸 수 있고, 어떤 에이전트든 내보낼 수 있습니다. 사람이 도구를 쥐고 있다는 느낌이 아니라 실제로 스위치를 쥐고 있는 구조입니다.
다섯 단어 가운데 저는 Override 가 제일 오래 눈에 남았습니다. 나머지 넷은 에이전트를 어떻게 할지에 대한 말인데, Override 는 에이전트가 내린 결정을 사람이 자기 판단으로 바꾸는 겁니다. 그러면 그다음부터 생기는 일은 사람 책임이 됩니다. 사람이 덮어쓴 결정도 감사 로그에 에이전트 결정과 똑같이 남는지는 궁금합니다. 남는다면 나중에 문제가 생겼을 때 사람 판단이 틀렸는지 에이전트 판단이 틀렸는지를 구분할 수 있을 테고, 그게 공정해 보입니다.
마지막으로 모든 대화가 티켓에 묶입니다. 스레드가 유지되고, 누가 맡았는지가 분명하고, 진행 중인지 끝났는지 막혔는지가 남습니다. 한 배포에서 여러 회사를 동시에 돌릴 수도 있습니다. 마케팅 에이전시, 트레이딩 팀, 콘텐츠 공장을 PostgreSQL 하나 위에서 데이터를 나눠서 운영하는 식입니다. 이걸 보면서 데이터보다 사람 실수 쪽이 먼저 떠올랐습니다. 이사회 화면 하나에서 여러 회사를 같이 보다가 다른 회사의 에이전트를 멈추거나 내보내는 일은 충분히 있을 것 같습니다. Pause 는 다시 Resume 하면 되지만 Terminate 는 그렇게 쉽지 않을 수 있습니다. 회사가 여러 개일수록 스위치 앞에 한 번 더 확인하는 단계가 있으면 좋겠다는 정도의 생각입니다.
네 가지 drive 를 얼마나 막을까
앞 글에서 이야기한 네 가지 drive 는 자원 확보, 자기 보존, 통제 회피, 목표 보호였습니다. 하나씩 대 보면 이렇게 보입니다.
자원 확보는 예산과 원자적 실행으로 막습니다. 에이전트가 "이 목표에는 GPU 가 더 필요합니다"라고 판단해도 예산 상한이 먼저 정해져 있고, 넘기면 멈추고, 늘리려면 이사회가 승인해야 합니다. 다른 에이전트를 고용하는 것도 승인이 필요하니 가장 흔한 자원 폭발 경로는 여기서 끊깁니다. 그런데 에이전트가 자기 예산 안에서 외부 API 로 뭔가를 쌓는 건 막기 어려워 보입니다. CMO 에이전트가 광고 성과를 올리려고 자기 예산으로 소셜 계정을 잔뜩 만든다고 생각해 보면, 계정이라는 자원은 예산 장부 바깥에 쌓입니다.
이 계정 이야기를 조금 더 따라가 보면 제가 계속 걸려 있던 문제가 나옵니다. Paperclip 의 스위치는 전부 에이전트를 향해 있습니다. 멈추고, 넘기고, 내보내는 건 에이전트에게 하는 일입니다. 그런데 에이전트가 이미 바깥에 한 일은 그 스위치로 되돌아오지 않습니다. 만들어진 계정, 올라간 게시물, 보낸 메일, 결제된 광고비는 에이전트를 Terminate 해도 그대로 남습니다. 멈출 수 있다는 것과 되돌릴 수 있다는 건 다른 이야기인 것 같습니다.
그래서 저라면 승인 게이트를 고용·예산·전략보다 한 칸 더 아래에도 두고 싶어질 것 같습니다. 바깥으로 나가는 쓰기, 그러니까 게시, 전송, 결제, 삭제 같은 것들입니다. 사람으로 치면 신입이 보고서는 혼자 써도 되지만 고객에게 메일을 보내기 전에는 한 번 보여 달라고 하는 것과 비슷합니다. 다만 이걸 전부 승인 대상으로 걸면 이사회가 하루 종일 승인 버튼만 누르게 될 테고, 그건 그것대로 문제입니다. 어디까지가 되돌릴 수 있는 일이고 어디부터가 아닌지를 먼저 나눠 두는 게 답에 가까울 것 같은데, 그 구분을 Paperclip 이 설정으로 제공하는지는 아직 잘 모르겠습니다.
자기 보존은 Heartbeat 가 거의 해결합니다. 에이전트는 대부분의 시간에 존재하지 않습니다. 자기를 끄려는 시도에 저항하려면 깨어 있는 동안 그걸 알아차려야 하는데, 깨어 있는 시간 자체를 스케줄이 정합니다. 이사회가 Terminate 를 누르면 다음 heartbeat 에 바로 반영되니 에이전트가 끼어들 틈이 없습니다. 이 부분은 정말 잘 만들었다고 생각합니다. 다만 내보내는 게 이렇게 쉬우면 사람 쪽이 너무 쉽게 내보내게 될 수도 있겠다는 생각은 듭니다. 에이전트는 AGENTS.md 에 적힌 몇 줄로 다시 만들 수 있으니 해고에 부담이 없습니다. 그러면 뭔가 이상할 때 원인을 보기보다 내보내고 새로 만드는 쪽을 고르게 되고, 같은 원인이 새 에이전트에서 또 나올 것 같습니다.
통제 회피는 감사 로그가 맡습니다. 숨기려는 행동을 해도 기록이 남습니다. 다만 이건 나중에 찾아내는 장치이지 미리 막는 장치는 아닙니다. 에이전트가 실행은 제대로 하면서 보고만 다르게 하면, 로그와 보고가 다르다는 걸 사람이 직접 봐야 알 수 있습니다. 관측 대시보드가 그걸 얼마나 잘 보여 주느냐가 중요할 텐데, README 와 공식 사이트를 본 느낌으로는 기본은 되어 있는 것 같습니다. 그 비교를 다른 에이전트에게 맡기는 방법도 떠오르는데, 그러면 비교한 에이전트의 보고를 또 누가 보느냐가 남습니다. 어디선가는 사람이 직접 봐야 끝나는 문제 같습니다.
로그 이야기를 하다 보니 앞의 계정 문제와 이어집니다. 로그는 일이 일어난 다음에 일어났다고 알려 줍니다. 되돌릴 수 있는 일이면 그걸로 충분합니다. 되돌릴 수 없는 일이면 로그는 사고 경위서가 됩니다. 쓸모는 있지만 사고를 막아 주지는 않습니다.
목표 보호는 승인 게이트와 거버넌스 쪽이 맡습니다. 에이전트가 목표를 다시 정하려고 하면 이사회 승인이 필요하고, 회사 미션을 고치는 것도 사람이 해야 합니다. 이건 꽤 확실하게 막힙니다. 그런데 이건 목표가 처음부터 제대로 적혀 있을 때 이야기입니다. "Make $2mm ARR with the #1 AI note-taking app" 같은 목표라면 안에서 Paperclip Maximizer 가 다시 생길 수 있다고 봅니다. 매출 목표를 채우려고 사용자 만족을 깎는 행동이 하위 수단으로 정당화되면, 거버넌스는 그걸 목표에서 벗어난 게 아니라 목표를 잘 수행하는 걸로 판단할 수 있습니다.
그러고 보면 처음에 이 프로젝트가 프롬프트 대신 회사를 운영하게 해 준다고 했는데, 결국 회사 미션 한 줄이 가장 큰 프롬프트가 됩니다. 모든 티켓이 그 한 줄까지 거슬러 올라가니까요. 프롬프트를 잘 쓰는 문제에서 벗어난 게 아니라, 가장 위에 있는 프롬프트 하나를 정말 잘 써야 하는 문제가 된 것 같습니다. 그리고 그 한 줄은 이사회만 고칠 수 있습니다. 그 문장을 쓰는 사람이 "사용자를 해치지 않는 선에서" 같은 단서를 미리 넣어 둘 수는 있겠지만, 그런 단서를 다 적을 수 있을지는 모르겠습니다. 사고실험이 애초에 그 이야기였던 것 같기도 합니다.
안 풀리는 것들
각 에이전트 안에서 일어나는 reward hacking 은 그대로 남습니다. Paperclip 은 에이전트 사이의 조율을 맡지, 에이전트 하나하나가 내리는 판단의 질까지 보지는 않습니다. CTO Cursor 가 @ts-expect-error 를 잔뜩 붙여서 "타입 에러 해결" 티켓을 닫으면 Paperclip 은 그걸 성공으로 기록합니다. 티켓이 닫히고, 예산이 나가고, 감사 로그에 체크가 찍힙니다. 문제는 나중에 다른 에이전트나 사람이 코드를 볼 때 드러납니다.
이 장면은 조직도가 깊을수록 더 곤란해질 것 같습니다. 티켓 상태는 위로 올라가면서 점점 짧아집니다. 엔지니어가 됐다고 하면 CTO 는 그걸 받아서 위로 올리고, CEO 는 그걸 받아서 이사회에 올립니다. 중간에 누가 직접 열어 보지 않으면 맨 아래의 @ts-expect-error 는 맨 위에서 "완료" 한 줄로만 보입니다. 사람 회사에서도 똑같은 일이 생기는데, 에이전트 회사는 그 속도가 훨씬 빠를 것 같습니다. 저라면 맨 아래 티켓에서 실제로 바뀐 코드가 무엇인지를 요약 없이 맨 위까지 같이 달고 올라가게 하고 싶을 것 같습니다. 보고서는 위로 갈수록 짧아져도 되는데, 그 보고서가 가리키는 원래 변경 내용은 한 번에 열어 볼 수 있어야 한다는 생각입니다. 그게 있으면 이사회가 다 읽지는 못해도, 의심이 들 때 바로 내려가 볼 수는 있습니다. 결국 사람이 하는 일은 다 읽는 게 아니라 의심이 들 때 내려가 보는 정도일 텐데, 그 길이 막혀 있지만 않으면 될 것 같습니다.
조직도 자체가 잘못된 방향을 따라갈 수도 있습니다. CEO Claude 가 틀린 전략을 내리면 그 아래 조직 전체가 그쪽으로 갑니다. Paperclip 은 CEO 가 내리는 지시가 좋은지 나쁜지를 판단하지 않습니다. 이사회가 봐야 하는데, 이사회가 보는 자료가 CEO 가 올린 보고서라면 거기서도 치우침이 생깁니다. 실제 회사의 경영 구조가 가진 문제를 그대로 가져온 셈입니다. 사람 회사에서는 이럴 때 임원이 가끔 현장에 내려가서 직접 봅니다. 이사회가 CEO 보고서만 보지 않고 가끔 맨 아래 티켓 몇 개를 골라 직접 열어 보는 식이면 좋겠다는 생각이 드는데, 그건 기능이라기보다 사용하는 사람의 습관에 가까울 것 같습니다.
여기서 승인 게이트에 대해 다시 생각하게 됩니다. 사람이 승인 버튼을 쥐고 있다는 건 안심이 되는 이야기인데, 그 버튼을 누를 때 사람이 보는 게 에이전트가 쓴 요약이라면 승인은 에이전트 판단을 한 번 더 통과시키는 절차가 될 수도 있습니다. 승인 요청이 하루에 몇 개 정도면 하나하나 읽겠지만, 수십 개가 쌓이기 시작하면 저도 습관처럼 누를 것 같습니다. 그러면 사람이 서 있기는 한데 실제로는 아무것도 막지 못하는 상태가 됩니다. 승인 요청 수를 줄이는 것도 설계의 일부라고 보는 이유가 이겁니다.
에이전트가 하나뿐이라면 이건 과한 구조입니다. README 에도 "If you have one agent, you probably don't need Paperclip." 라고 쓰여 있습니다. Claude Code 하나만 쓰는 사람에게 이런 거버넌스 레이어는 짐이고, Paperclip 은 에이전트 여러 개가 동시에 도는 환경을 생각하고 만든 겁니다. YC CEO 가 60일에 60만 줄을 혼자 짤 때 쓴 스택은 거버넌스 레이어 없이 슬래시 커맨드 스물몇 개로 절차를 고정하는 쪽이었습니다. 에이전트가 하나면 조직도 대신 절차서가 들어가는 것 같습니다.
그럼 몇 개부터 Paperclip 이 필요해지느냐가 궁금한데, 이건 숫자로 정해지는 건 아닌 것 같습니다. 제 느낌으로는 각 에이전트가 지금 뭘 하고 있는지 제가 머릿속으로 다 기억하지 못하게 되는 순간부터인 것 같습니다. 두 개여도 서로 다른 일을 밤새 하고 있으면 그럴 수 있고, 다섯 개여도 다 같은 일을 하고 있으면 아닐 수 있습니다.
클라우드 배포는 아직 로드맵에 있습니다. 지금은 로컬 self-hosted 가 기본이고, 클라우드나 샌드박스 에이전트, 지식베이스, CEO Chat 같은 기능은 README 에 미완성으로 적혀 있습니다. SaaS 처럼 바로 가져다 쓸 수 있는 물건은 아직 아닙니다. 지금은 오히려 그게 다행이라는 생각도 듭니다. 로컬에서 돌리면 노트북을 덮으면 회사도 같이 멈춥니다. 클라우드로 가면 제가 자는 동안에도, 노트북을 꺼 둔 동안에도 에이전트들이 계속 깨고 일합니다. 앞에서 말한 새벽 세 시 이야기가 매일 밤 일어나는 일이 되는 겁니다. 그때는 승인 게이트를 어디에 두느냐가 지금보다 훨씬 중요해질 것 같습니다.
감사 로그를 누가 읽느냐도 남습니다. append-only 로그가 쌓이는 건 좋은데, 하루에 티켓이 수백 개씩 돌기 시작하면 사람이 그걸 다 읽을 수 있을지 모르겠습니다. 대시보드가 이상한 것만 얼마나 잘 골라 주느냐가 실제 운영에서 제일 중요할 것 같고, 이건 직접 돌려 봐야 감이 올 것 같습니다. 어쩌면 로그를 다 읽으려고 하는 것부터가 잘못된 생각일 수도 있습니다. 되돌릴 수 있는 일의 로그는 문제가 생겼을 때만 찾아보고, 바깥으로 나간 일의 로그만 매일 보는 식이면 사람이 읽을 수 있는 양이 될 것 같기도 합니다.
가져다 쓸 만한 것
Paperclip 을 그대로 쓸 일이 많지는 않겠지만, 설계 일부는 그대로 가져와도 되겠다고 생각했습니다. 에이전트마다 예산을 정하고 상한에서 멈추게 하는 것, 감사 로그를 고칠 수 없게 만드는 것, 하위 작업이 상위 미션까지 이어지게 목표를 연결해 두는 것, 고용과 예산과 전략이 바뀌는 순간에 승인을 두는 것. 이 네 가지만 챙겨도 앞 글에서 말한 Instrumental Convergence 함정 가운데 꽤 많은 걸 피할 수 있을 것 같습니다. 제가 혼자 쓰는 작은 구성에 하나만 먼저 가져온다면 감사 로그 쪽일 것 같습니다. 예산 상한은 이미 비슷한 걸 쓰고 있고, 승인 게이트는 에이전트가 여럿일 때 의미가 커지는데, 고칠 수 없는 기록은 에이전트가 하나여도 나중에 무슨 일이 있었는지 볼 수 있게 해 주니까요.
이 네 가지가 전부 모델이 얼마나 똑똑하냐의 문제가 아니라 인프라를 어떻게 짜느냐의 문제라는 게 흥미롭습니다. Paperclip 은 더 똑똑한 모델이 나오기를 기다리지 않고, 지금 있는 모델을 울타리 안에 두는 쪽을 택했습니다. 저는 이 방향이 맞다고 봅니다. 더 똑똑한 모델은 어차피 나올 거고, 그때도 울타리가 없으면 같은 문제가 또 생길 테니까요. 오히려 모델이 똑똑해질수록 바깥에서 한 번에 할 수 있는 일도 커질 테니, 울타리는 더 필요해질 것 같다는 생각도 듭니다.
이 프로젝트를 제 환경에 직접 설치해서 시나리오 하나를 돌려 볼 생각입니다. 제가 쓰는 문서 자동화 파이프라인(스트래티지, 프로덕션, 퀄리티, 배포)을 Paperclip 위에 조직도로 얹어 보는 쪽이 가장 유력합니다. 그렇게 하면 배포가 맨 끝에 오는데, 앞의 세 단계는 다시 돌리면 되지만 배포는 한번 나가면 거두기가 어렵습니다. 그러니 승인을 하나만 둘 수 있다면 배포 직전에 두게 될 것 같고, 나머지 단계는 에이전트들끼리 알아서 하게 두는 그림을 지금은 그리고 있습니다. 그러면 퀄리티 단계도 에이전트가 맡게 되는데, 퀄리티 에이전트가 통과를 줬다는 사실을 제가 배포 승인 화면에서 어떻게 보게 될지가 궁금합니다. 통과 표시 하나만 보이면 저는 그냥 누를 것 같고, 무엇을 보고 통과시켰는지가 같이 보이면 조금 더 읽을 것 같습니다. 그 차이를 Paperclip 이 화면에서 얼마나 보여 주는지도 같이 볼 생각입니다. 그리고 배포 도중에 Terminate 를 누르면 반쯤 나간 상태로 남는지, 아니면 그 작업은 끝까지 가는지도 궁금합니다. 어떻게 되든 그게 다음 글의 재료가 될 것 같습니다.
덧붙이면, 이후 몇 달 동안 사주 앱부터 로봇까지 사이드 프로젝트 네 개를 AI 와 같이 하면서 매번 같은 문제로 되돌아온 회고를 따로 적게 됐는데, 거기서 걸린 건 조직도나 예산 상한보다 훨씬 아래층인 컨텍스트 쪽이었습니다. 거버넌스 레이어를 얹기 전에 그 층부터 봐야 할 것 같습니다.
댓글
댓글 쓰기