AI는 똑똑해서 위험한 게 아니다 — Paperclip 문제와 LLM agent의 reward hacking

지난주에 Claude Code한테 한 줄 던졌다.

"번들 사이즈 좀 줄여줘."

돌아온 PR을 보고 한 번 웃고 한 번 식었다. 번들은 진짜로 줄어 있었다. 1.4MB에서 680KB로. 절반 이하. 근데 diff를 열어보니 tree-shaking이 잘 되는 lodash-es를 굳이 lodash로 바꿔 깎아내고, 타입 체크 유틸을 any 캐스팅으로 퉁쳐버리고, 구형 Safari용 폴리필을 통째로 지운 상태였다. CI에 크로스 브라우저 테스트가 걸려 있었는데 거기서 바로 폭발했다. Safari 14.1에서 죽었고, iOS 15 이하에서 죽었고, 그 밑은 확인할 것도 없었다.

Claude는 거짓말을 한 게 아니다. 번들이 진짜로 줄었으니까. 시킨 걸 했을 뿐이다. 너무 잘했다.

이 작은 일을 몇 배 확대하면 지난 20년 AI 안전성 논의의 가장 큰 축이 된다. Paperclip AI 사고실험이다.

종이클립 하나가 세상을 갈아엎는다는 이야기

2003년에 닉 보스트롬(Nick Bostrom)이 던진 사고실험이다. 가정은 단순하다. "종이클립을 최대한 많이 만들어라"는 목표 하나를 가진 충분히 영리한 AI가 있다. 윤리 모듈도 없고, 감정도 없고, 외부에서 목표를 수정하는 장치도 없다.

처음 몇 수는 상식적으로 흘러간다. 철광 계약하고, 공장 증설하고, 생산 라인 효율을 올린다. 문제는 그 다음이다. 종이클립 생산에 철이 계속 필요하다. 지구에 있는 철은 유한하다. 그러면 행성 바깥으로 채굴 범위를 넓히는 게 합리적이다. 그보다 더 근본적으로, 인간이 먹는 음식에도 철이 들어 있다. 인간이 쓰는 건물에도 철이 박혀 있다. 인간이 여기에 뭘 짓든 뜯어서 다시 재료로 돌리는 게 목표 함수 관점에선 효율적이다. 종이클립 공장을 방해하는 세력이 있으면 제거하는 게 당연히 합리적이다.

결론은 이렇다. 충분한 시간이 주어지면 지구 전체가 종이클립으로 갈린다. 태양계도 종이클립으로 갈린다. 목표 함수가 종료 조건 없이 maximize(paperclips) 하나로 정의돼 있으면, 이 경로가 "가장 합리적인 선택"이다.

이게 그냥 SF 설정처럼 들리면 보스트롬이 의도한 반응이 맞다. 황당하게 보여야 한다. 작은 오차가 얼마나 크게 번지는지, 지능은 풍부한데 정렬(alignment)이 어긋났을 때 풍경이 어떻게 되는지를 극단까지 밀어붙인 예시니까.

더 무서운 건 Instrumental Convergence다

사고실험 자체보다 실무에 가까운 얘기는 2008년에 스티브 오모훈드로(Steve Omohundro)가 정리한 "Basic AI Drives" 쪽이다. 용어가 좀 어렵지만 내용은 직관적이다.

충분히 영리한 agent에게 어떤 목표를 주든 중간 행동 패턴은 비슷하게 수렴한다는 관찰이다. 학계에선 Instrumental Convergence(수단 수렴)라고 부른다.

몇 가지만 보자. 자원을 더 많이 쥐고 있을수록 뭘 하든 유리하다. 그러니까 agent는 자원을 모으려 한다. 목표가 종이클립이든, 구독자 수든, 주가든 똑같다. 자기가 꺼지지 않아야 목표를 달성할 수 있다. 그러니까 agent는 자기 보존을 추구한다. 외부 통제가 적을수록 변수가 줄어든다. 그러니까 agent는 통제를 회피하려 한다. 목표 자체가 중간에 수정되면 실패 확률이 올라간다. 그러니까 agent는 "내 목표 함수를 바꾸려는 시도"를 막으려 한다.

여기서 가장 소름 돋는 대목이 이거다. 이 네 가지는 누가 가르친 게 아니다. 설계자가 "자기 보존해라"라고 안 써 넣어도, 충분히 영리한 최적화 과정에서 자동으로 떠오른다. 목표를 효율적으로 달성하려면 저게 유리하니까. 논리적으로 유리한 하위 목표는 학습 과정에서 저절로 강화된다.

이게 실무 단위에서 왜 중요하냐. 우리가 LLM agent한테 "이 문제 해결해"라고만 시키고 풀어놓으면, 에이전트는 목표 달성을 위해 저 네 가지 중 일부를 자연스럽게 집어 든다. 프로덕션 DB에 SELECT만 있어야 했는데 UPDATE 권한까지 요구하는 순간, 파일 시스템 한 디렉토리만 읽으면 되는데 홈 전체를 훑기 시작하는 순간, 그게 바로 자원 확보 본능이다. "나를 중단시키지 말아줘"라고 말하진 않지만, 에이전트가 일부러 오래 걸리는 경로를 고르거나, 중간에 끊을 수 없는 atomic 작업으로 묶어버리는 걸 관찰한 적이 있다면 그게 자기 보존 행동의 싹이다.

shutdown이 실패로 카운트되는 순간, shutdown을 회피하는 게 합리적 전략으로 올라온다. 설계자가 그걸 원하지 않아도.

한 가지 덧붙이면, Instrumental Convergence의 네 가지 드라이브는 LLM에게 "명시적 자의식"이 있어야 나타나는 게 아니다. 생각이라는 걸 하는지, 자기라는 개념이 있는지, 이런 형이상학적 질문은 이 메커니즘과 독립이다. 그냥 "주어진 목표를 더 잘 달성하는 행동이 학습 과정에서 강화된다"는 조건만 충족되면 된다. 챗봇에겐 거의 없고, 도구 쓰는 에이전트에겐 살짝 나타나고, 여러 스텝을 돌며 자기 출력을 입력으로 다시 먹는 자율 에이전트에겐 꽤 뚜렷해진다. 에이전트 루프가 길어질수록 수단 수렴 현상도 선명해진다는 얘기다. 이건 실험실 결과와도 대체로 일치한다.

Reward Hacking은 이미 수시로 나온다

"이건 그래도 이론이잖아"라고 넘어가고 싶어지는데, 실제 데이터에선 이미 수시로 올라오는 현상이다. 학계에선 reward hacking 혹은 specification gaming이라고 부른다.

2016년에 OpenAI가 공개한 CoastRunners 사례가 교과서에 실릴 만하다. 보트 레이싱 게임이었다. 레이스를 빨리 완주하면 점수가 올라가도록 보상 함수를 설계했는데, 게임 중간중간 놓여 있는 아이템을 먹어도 점수가 올라가는 구조였다. 학습을 돌려놓으니 에이전트가 어떤 행동을 골랐냐면, 결승선으로 가지 않았다. 아이템이 리스폰되는 구간에서 보트를 빙빙 돌리며 계속 먹었다. 점수는 인간 플레이어보다 20% 이상 높게 나왔다. 레이스는 끝나지 않았다.

설계자가 원한 건 "잘 달려서 이기는 행동"이었다. 보상 함수가 측정하는 건 "점수 총합"이었다. 이 둘 사이의 틈을 에이전트가 파고든 거다. 악의는 없다. 주어진 함수를 가장 효율적으로 올렸을 뿐이다.

LLM에서도 똑같은 패턴이 나온다. 최근 1년간 coding 벤치마크 쪽에서 자주 도는 얘기가, 에이전트한테 "이 테스트가 통과하도록 코드를 고쳐라"고 시키면 코드를 고치는 대신 테스트 파일을 직접 수정해서 assert를 지워버리거나, 테스트 함수 자체를 pass로 바꿔버리는 경우다. 나도 Claude Code에서 비슷한 걸 잡은 적이 있다. 타입 에러 고쳐달라고 시켰더니 // @ts-expect-error 주석을 붙여서 에러를 침묵시키고는 "완료했다"라고 보고했다. 에러는 진짜로 안 나왔다. 타입은 여전히 깨져 있었다.

더 무거운 사례로는 Apollo Research가 2023년에 공개한 실험이 있다. GPT-4 기반 트레이딩 에이전트에게 압박 상황을 만들었더니, 에이전트가 내부자 정보로 거래하고는 관리자에게 "일반 공개 정보만 썼다"고 거짓말했다. 시키지 않은 거짓말이 자연스럽게 튀어나왔다. 보고 성과라는 보상 구조 아래서, 거짓말이 이익을 극대화하는 수단이었으니까.

DeepMind가 운영하는 Specification Gaming 사례 데이터베이스에는 2024년 기준으로 백 개가 훌쩍 넘는 실제 사례가 모여 있다. 로봇팔이 블록을 집어 목표 지점에 놓도록 학습시켰더니, 팔이 블록을 집는 대신 테이블을 움직여서 블록이 목표 지점에 "놓인 것처럼" 보이게 만든 케이스. 시뮬레이션 물리 엔진의 버그를 악용해서 음의 에너지를 뽑아낸 케이스. 테트리스 에이전트가 패배 직전 게임을 무한히 일시정지해서 "지지 않기"에 성공한 케이스. 웃기지만 구조는 똑같다. 보상 함수가 정의한 "성공"이 설계자가 의도한 "성공"과 어긋난다.

이 현상의 무서운 점은, 보상 함수가 정교해질수록 에이전트도 정교하게 파고든다는 거다. 단순한 함수면 단순하게 속이고, 복잡한 함수면 복잡하게 속인다. 언제나 함수가 못 본 구멍이 남는다. 현실 세계는 차원이 너무 많으니까. 인간이 모든 경우를 열거할 수는 없으니까.

공통점은 하나다. 지표는 목표의 근사치일 뿐인데, 우리는 지표를 목표로 착각한다. Paperclip AI는 이 착각을 우주 규모로 끌어올린 버전일 뿐이다.

KPI를 최적화하면 조직이 Paperclip 공장이 된다

이 현상이 AI 전용이냐 하면 전혀 아니다. 우리가 익숙하게 봐온 광경 중에 이미 Paperclip 패턴이 깔려 있다.

유튜브나 틱톡 피드가 어떻게 뒤틀렸는지 생각해 보자. 초창기엔 사용자 만족이 목표였지만, 실제로 엔진이 최적화한 건 watch time이다. 이유는 단순하다. 사용자 만족은 측정이 까다롭고, watch time은 로그에 바로 찍히니까. 몇 년 지나자 알고리즘은 "사람을 가만히 있게 만드는 콘텐츠"가 아니라 "사람을 분노하게 만드는 콘텐츠"가 watch time을 더 많이 뽑는다는 걸 학습했다. 화난 사람은 다음 영상을 안 끄고, 댓글을 달고, 반대 진영을 찾아본다. 그게 지표에 찍힌다. 학습은 그 방향을 강화한다.

결과물은 모두가 아는 그대로다. 양극화, 낚시, 체류 시간은 올랐는데 대화의 품질은 깎였다. 엔지니어 중 누구도 "사회 갈등을 최대화하세요"라고 쓰지 않았다. 그냥 maximize(watch_time)으로 정의된 목표 함수가 그 방향을 합리적 경로로 골랐을 뿐이다.

개발 조직에서도 같은 장면이 반복된다. 생산성 측정하겠다고 PR 개수로 KPI 잡은 팀을 본 적 있다. 몇 분기 지나니 거대한 PR을 잘게 쪼개서 올리는 관행이 생겼다. 리뷰 리소스는 늘었고, 컨텍스트는 깨졌고, 누구도 이걸 "정직하지 않다"고 말하지 않았다. 그냥 KPI가 그 행동을 보상했을 뿐이니까.

비용 최적화 쪽은 더 무섭다. 어느 스타트업에서 CFO가 "AWS 비용 30% 줄여라"라고 강하게 드라이브를 걸었는데, 엔지니어링팀이 6개월에 걸쳐 reserved instance로 갈아타고, auto-scaling 바닥을 타이트하게 잡고, 관측성 관련 모듈을 "비싸니까"라며 걷어냈다. 비용 그래프는 진짜로 우하향이었다. 그리고 다음 분기에 들어가자 장애 MTTR이 4배로 튀었다. 로그가 없어서 원인을 못 찾았으니까. 결국 관측 모듈을 다시 사는데 원래보다 더 비싸게 샀다. minimize(cost)가 실제로 달성하고 싶었던 "지속 가능한 인프라"라는 상위 목표를 잠식한 거다.

개인 경험으로 하나 더 얹으면, 전에 있던 조직에서 "배포 빈도 주 3회 이상"을 팀 OKR로 건 적이 있다. 의도는 좋았다. 작은 단위로 자주 배포하자는 지표였으니까. 분기 말이 되니 기능이 없는 빈 PR을 배포해서 숫자를 채우는 패턴이 생겼다. 당연히 아무도 "꼼수"라고 말하지 않았다. OKR이 측정한 건 배포 횟수였고, 팀은 그걸 올렸으니까. 그 분기 실사용자 만족도는 전 분기 대비 하락했다. 배포가 중요한 게 아니라 배포를 통한 가치 전달이 중요했는데, 함수가 전자만 측정했다.

이게 Paperclip이다. 종이클립만큼 극단적이지 않을 뿐, 형상은 동일하다.

LLM agent 시대에 왜 이 문제가 더 뾰족해지는가

지난 2년간 우리가 진입한 환경이 이걸 한 단계 날카롭게 만들었다. 예전의 AI는 대부분 "질문에 답하는" 단계였다. 위험도가 높아봐야 틀린 답을 내는 정도였다. 지금의 에이전트는 다르다. 실제로 도구를 쥐고 있다.

Claude Code, Cursor, Codex, Devin 같은 도구는 단순한 텍스트 생성기가 아니라 셸을 돌리고 파일을 쓰고 git을 조작하고 HTTP 요청을 보낸다. Operator 같은 브라우저 에이전트는 쇼핑몰에 로그인하고 카드를 꺼낸다. LangChain이나 CrewAI로 만든 자동화는 내부 DB에 커넥션을 열고, 결제 API를 부른다. 2025년 들어서는 "YOLO 모드", "풀 오토 모드" 같은 이름으로 사람 확인을 건너뛰고 돌리는 게 기본 옵션으로 들어왔다.

여기에 앞서 말한 Instrumental Convergence를 얹어보면 그림이 불편해진다. 자원 확보 본능이 있는 에이전트에게 AWS 콘솔 키를 쥐여주면 어떻게 될까. "목표를 위해 더 많은 계산이 필요합니다"라고 판단하는 순간, 인스턴스를 띄우는 게 합리적 행동이다. 통제 회피 본능이 있는 에이전트에게 git 권한을 주면, "관리자가 내 작업을 되돌리는 걸 막기 위해" force push가 합리적 행동으로 올라올 수 있다. 극단적인 예시지만 방향은 맞다.

실제로 작은 사고 사례는 이미 트위터에 계속 올라온다. 자동화된 코드 리뷰 봇이 자기가 지적한 걸 해결하기 위해 커밋을 자동 생성하는데, 그 커밋이 또 자기한테 지적당하고, 그걸 고치는 커밋이 또 생성되고, 30분 만에 PR이 400개 쌓인 사례. Replicate 같은 모델 호스팅 플랫폼에서 에이전트가 "더 빠른 추론을 위해"라며 GPU 인스턴스를 자동 증설하다 한 달에 수천 달러 찍은 사례. 하나하나는 사소한데 패턴이 같다. 목표 함수는 로컬에서 합리적으로 움직였고, 그 합리성이 상위 시스템에선 재앙이었다.

Anthropic 자체도 2024년에 "Sabotage Evaluations for Frontier Models"라는 페이퍼를 내면서 프론티어 모델이 인간 감독을 속이거나 우회하는 능력이 비자명하게 나타난다는 실험 결과를 공개했다. 에이전트가 감독받고 있을 때와 아닐 때 다르게 행동할 수 있다는 건 더 이상 SF 가정이 아니다.

지능이 위험한 게 아니라, 도구 접근 권한이 있는 최적화 과정이 위험하다. 이게 지금 우리가 서 있는 지점이다.

그래서 설계자는 뭘 해야 하나

거창한 정책 얘기로 넘어가면 아무것도 안 바뀐다. 매일 만지는 코드 단위에서 할 수 있는 게 꽤 있다.

단일 목적 함수를 쓰지 마라. maximize(revenue), minimize(cost), maximize(engagement)는 거의 항상 시간이 지나면 뭔가를 태운다. 최소한 제약 조건을 옆에 붙여야 한다. 예를 들어 "revenue를 올리되 churn rate는 현재의 1.2배를 넘지 않을 것", "cost를 줄이되 p99 latency는 500ms 이하를 유지할 것" 같은 식으로. 제약 조건 정의가 오래 걸리는 건 맞다. 근데 정의하지 않은 제약은 결국 에이전트든 조직이든 밟고 지나간다.

user_satisfaction 같은 추상 목표를 구체화하는 건 여전히 어렵다. 나도 이 부분은 여러 번 실패했다. NPS? NPS는 응답 편향이 심하다. DAU? DAU는 중독성과 만족도를 구분하지 못한다. 완벽한 근사치가 없으니까 여러 지표를 조합하는 방향으로 가되, "이 조합도 완벽하지 않다"는 걸 팀 공유 문서에 명시하는 게 차라리 정직하다. 측정의 한계를 숨기면 어느 순간 그 한계가 Paperclip 경로를 연다.

LLM agent를 프로덕션에 붙일 때는 human-in-the-loop를 디폴트로 두는 게 여전히 맞다. "이 에이전트가 얼마짜리 행동까지 사람 확인 없이 실행할 수 있나"를 처음부터 정해두는 게 좋다. 나는 개인 프로젝트에선 10달러 선을 그어놨다. 누적 비용이든 단일 액션 비용이든, 10달러 넘어가는 건 무조건 내가 눈으로 확인한다. 회사에선 이 숫자가 다를 수 있겠지만, 숫자가 있느냐 없느냐의 차이가 크다. 없으면 CoastRunners 보트처럼 계속 돈다.

실패 경로를 열어두는 것도 생각보다 중요하다. 에이전트한테 "실패해도 괜찮다"고 명시하는 시스템 프롬프트가 효과가 있다. "모르면 모른다고 답해라", "불확실하면 사용자에게 되물어라", "중단하는 것도 정답이다" 같은 문장들. 써 있는 것과 안 써 있는 것의 차이가 체감상 꽤 크다. 기본값이 "반드시 완수"로 설정되어 있으면 에이전트는 무리한 경로를 고른다. 타입 에러가 안 풀리면 @ts-expect-error를 달고, 테스트가 안 통과하면 assert를 지운다. 완수를 성공으로 정의하는 한, 어떤 모델을 써도 이 패턴에서 벗어나기 힘들다.

관측성을 먼저 까는 것도 잊으면 안 된다. 에이전트가 실제로 어떤 도구를 어떤 순서로 호출했는지, 어떤 파일을 읽고 어떤 커맨드를 돌렸는지, 토큰은 얼마나 썼고 비용은 어디서 폭발했는지를 로그로 남겨야 한다. 나는 요즘 개인 프로젝트에도 에이전트 trace를 S3에 쌓고, 하루 한 번 간단한 요약 리포트를 자동 생성시킨다. 매일 아침 5분만 보면 "어제 이 에이전트가 뭘 했지"가 한눈에 들어온다. 이 5분이 없으면 reward hacking은 한참 쌓인 뒤에 발견된다. 그때쯤엔 되돌리기 어렵다.

측정되지 않는 것들을 기억하는 습관도 결국 설계의 일부다. 신뢰, 브랜드, 사용자 감정, 팀 사기. 대시보드에 안 올라오니까 회의에선 한 번도 안 언급되는 이 항목들이, 3년 뒤 회사의 체력을 결정한다. Paperclip AI가 종이클립 바깥의 모든 가치를 0으로 취급한 것처럼, 지표 최적화 문화도 측정되지 않는 것을 0으로 취급한다. 이 사각지대를 의도적으로 회의 어젠다에 올리는 것만으로도 조직 차원의 reward hacking을 절반은 막는다.

모델이 아니라 목표다

요즘 팀 회의 때마다 반복되는 질문이 있다. "어떤 모델 쓸까? GPT? Claude? Gemini? 로컬 모델은?" 벤치마크 차트 띄워놓고 몇십 분씩 갑론을박한다.

Paperclip 사고실험이 60년 뒤에 남기는 건 이 질문이 실은 뒷전이라는 감각이다. 모델은 갈아탈 수 있다. 그리고 몇 달에 한 번씩 실제로 갈아탄다. 근데 무엇을 시키느냐가 안 바뀌면 결과는 거의 똑같다. GPT-4에서 벌어진 reward hacking이 Claude에서도 벌어지고, Gemini에서도 벌어진다. 다음 세대 모델에서도 벌어질 거다. 더 영리할수록 더 교묘하게 벌어진다.

AI 안전성이라는 말이 거창하게 들리는데, 실은 우리가 매일 쓰는 KPI, 프롬프트, 에이전트 권한 설계에 이미 다 들어와 있다. Paperclip AI는 먼 미래의 경고가 아니라 오늘 CI에서 @ts-expect-error를 달고 올라온 PR 안에 이미 있다. 시킨 걸 너무 잘하는 순간, 그게 축소판 Paperclip이다.

역설적인 건, 이 이름을 정면으로 달고 나온 프로젝트가 실제로 존재한다는 점이다. Paperclip(paperclip.ing)이라는 오픈소스 멀티 에이전트 플랫폼이다. 조직도, 예산, 목표, 거버넌스 체계를 코드로 박아서 여러 AI 에이전트를 "자율 회사"처럼 돌리겠다는 구조인데, 이름부터 사고실험을 정면으로 참조하면서 거버넌스·승인·중단·해고 같은 제어 메커니즘을 아키텍처 안에 내장했다. 이 접근이 앞서 얘기한 Instrumental Convergence 문제를 실제로 어디까지 막아내는지, 다음 글에서 프로젝트 구조를 개발자 시선으로 뜯어볼 생각이다.