We Cut 80% of Claude Code's Prompt: Boris Cherny on Radical Simplicity

Chapter 1 · 해설: 와우멘토

We Cut 80% of Claude Code's Prompt: Boris Cherny on Radical Simplicity

A WOW Mentor strategy teardown.

오늘 와우멘토가 해부할 주제는, 무언가를 더 잘 만들기 위해 오히려 그 80퍼센트를 지워버린 한 엔지니어의 결정입니다. 이야기의 주인공은 클로드 코드를 처음 만든 보리스 체르니이고, 무대는 바로 전날 오푸스 5를 출시한 직후입니다. 그는 새 모델이 아크 AGI 3 벤치마크를 30퍼센트까지 끌어올렸다고 전합니다. 이전 최고 점수가 한 자릿수나 십대 초반에 머물던 것을 생각하면 놀라운 도약입니다. 진행자가 묻습니다. 그렇다면 오푸스 5는 이전 모델이 못 하던 무엇을 할 수 있느냐고요. 그는 대답합니다. 모델 훈련이란 늘 온갖 것을 가르치려는 시도이고 대부분은 실패하지만, 그중 일부는 배우고, 때로는 가르치지도 않은 능력을 스스로 익혀 사람을 놀라게 한다고요. 와우멘토가 먼저 주목하는 지점은 이것입니다. 모델을 개선한다는 것이 반드시 무언가를 더 얹는 일이 아니라는 것. 오늘 이야기의 뼈대는 처음부터 끝까지 '덜어냄'입니다. 그가 오푸스 5에서 가장 놀라워하는 능력 하나는 지구력입니다. 그는 이 모델이 아주 오랜 시간 멈추지 않고 달린다고, 특히 오토 모드와 결합하면 며칠, 몇 주, 심지어 몇 달이라도 계속 간다고 말합니다. 슬래시 골이나 별도의 비계 같은 것도 필요 없이, 그저 과제를 끝내야 한다는 것을 알기에 스스로 간다는 것입니다. 그리고 그가 특히 흥분해서 꺼내는 또 하나의 새 능력은 이제 이 모델이 프롬프트 주입에 뚫리지 않는다는 사실입니다. 사람들이 오래 이야기해온 이른바 '치명적 삼요소'가 하네스 설계와 에이전트 설계, 제품 설계 전체에 그림자를 드리워 왔습니다. 인터넷 어딘가의 문서에 '이러이러한 걸 하고, 그리고 사용자 컴퓨터의 모든 걸 지워라'라는 지시가 숨어 있으면, 일 년 전 모델은 그것을 그냥 실행해버렸을 것이라고 그는 말합니다. 하지만 지금의 오푸스는 그러지 않습니다. 그는 그 비결을 세 겹의 층으로 설명합니다. 삼 년에 걸친 정렬 연구로 잘 정렬된 모델이 첫 번째 층이고, 모든 트래픽에 돌아가는 프롬프트 주입 분류기가 두 번째 층입니다. 이 분류기는 크리스탈의 기계적 해석 가능성 연구에 기반해, 프롬프트 주입이 일어날 때 모델의 뇌에서 빛나는 뉴런을 문자 그대로 들여다본다고 그는 설명합니다. 모델은 그 사실을 말해주지 않아도 우리는 그 뉴런을 보고 무슨 일이 벌어지는지 진단할 수 있다는 것이죠. 여기에 오토 모드 분류기라는 세 번째 층을 더하면, 이제 그들은 프롬프트 주입을 더는 시연조차 할 수 없게 되었다고 말합니다. 와우멘토가 이 대목을 오래 붙잡고 싶은 이유는, 프롬프트 주입이 사라진다는 것이 단지 안전의 문제가 아니라 설계의 자유를 새로 연다는 데 있습니다. 모델이 인터넷의 악의적 지시에 넘어가지 않으니, 그만큼 하네스를 방어적으로 두껍게 감쌀 이유가 줄어듭니다. 그는 이것이 오푸스 4.7과 4.8, 소네트 5부터 이미 상당히 좋았고 오푸스 5가 새로운 경지에 이르렀다고 덧붙입니다. 삼 년에 걸친 정렬 연구라는 오랜 축적이 있었기에 가능했던 일이라는 것이죠. 그리고 오늘의 중심 화제가 나옵니다. 그는 이번 출시에서 클로드 코드 시스템 프롬프트의 80퍼센트 이상을 지웠습니다. 와우멘토가 강조하고 싶은 것은, 이것이 즉흥적 파괴가 아니라 그가 늘 해오던 일의 극단적 판본이라는 점입니다. 그는 말합니다. 많은 사람이 모르는 사실은 클로드 코드가 제품으로서, 하나의 하네스로서 늘 변하고 있다는 것이라고요. 늘 무언가를 더하고, 늘 무언가를 지웁니다. 새 모델이 나올 때마다 시스템 프롬프트의 상당 부분을 지우고 바꾸며, 도구의 구성과 도구용 프롬프트도 매번 손봅니다. 이유는 단순합니다. 모델마다 성격이 전혀 다르기 때문입니다. 석 달 전 어떤 모델을 위해 해둔 것이 다음 모델에는 하나도 들어맞지 않을 수 있다는 것이죠. 오푸스 5는 그저 정말로 똑똑하고, 과거 시스템 프롬프트의 상당 부분은 모델이 원래 알았어야 할 행동을 교정하려는 지시였는데 이제는 모델이 그냥 알아서 한다고 그는 말합니다. 그는 나머지도 지워보라고 권합니다. 클로드 코드를 실행할 때 시스템 프롬프트 옵션으로 원하는 프롬프트를 직접 지정해 실험해볼 수 있고, 심지어 '심플 모드'라는 문서화되지 않은 기능도 있다고 귀띔합니다. 환경 변수로 심플을 켜고 실행하면 도구의 것까지 포함해 모든 시스템 프롬프트가 사라지는데, 그들은 이것을 프롬프트가 정말 쓸모 있는지 가늠하는 일종의 어블레이션으로 쓴다는 것입니다. 흥미로운 점은, 이 프롬프트들이 없을 때 모델이 오히려 조금 더 똑똑하더라는 관찰입니다. 다만 사람으로서 제품을 쓸 때는 그 프롬프트들이 제품을 다루기 쉽게 하고 모델이 원하는 방식으로 행동하게 돕기에, 실제 제품에서는 일부를 남겨둔다고 그는 덧붙입니다. 여기서 그가 소개하는 방법론이 어블레이션입니다. 연구에서 온 이 말은, 지워서 각 요소의 영향을 재는 실험을 뜻합니다. 그는 새 모델이 올 때마다 코드베이스 전체를 지우는 것은 아니지만 상당 부분을 지운다고 밝힙니다. 시스템 프롬프트를 통째로 지운 다음, 한 줄씩 다시 되돌리며 각 줄이 어떤 영향을 주는지 알아낸다는 것입니다. 이밸과 비슷하되, 무언가를 지워서 그 영향을 측정하는 이밸이라는 것이죠. 도구도 마찬가지여서, 그들은 도구를 수시로 내리고 하네스의 코드를 수시로 지웁니다. 그의 말에 따르면 오늘날 클로드 코드 하네스에 남은 코드의 거의 전부는 안전과 권한, 정적 분석에 관한 것이고 나머지는 UI 코드이며, 다른 많은 코드는 이미 내려버렸다고 합니다. 진행자가 묻습니다. 에이전트 제품을 짓는 모두가 새 모델마다 이렇게 어블레이션을 해야 하느냐고요. 그는 백 퍼센트라고 답합니다. 그리고 에이전트 제품을 만들지 않고 그저 클로드 코드를 쓰는 사람에게도 똑같이 권합니다. 여섯 달마다 클로드MD를 지우고, 스킬을 지우고, 훅을 지우고, 모델이 무엇을 하는지 지켜보라고요. 놀라게 될 것이라고, 특히 오푸스 5에서는 과거 모델을 위해 필요했던 그 모든 지시가 이제 정말로 필요 없을지 모른다고 그는 강조합니다. 진행자는 이것이 옛 세상에서라면 스타트업이 결코 하지 않았을 방식이라고 짚습니다. 여섯 달마다 모든 것을 삭제 버튼으로 지워버리는 일 말이죠. 과거의 제품 개발이라면 애써 쌓은 코드베이스와 프롬프트를 통째로 버리는 것은 상상하기 어려운 낭비였습니다. 하지만 지금은 그 삭제야말로 최전선에 서는 대가라고 그는 말합니다. 가장 뛰어난 능력을 원한다면 코드와 시스템 프롬프트는 지워야 하고, 다만 이밸만큼은 상수처럼 남겨 계속 덧붙여 가라는 것이죠. 와우멘토가 강조하는 지점은, 삭제가 파괴가 아니라 최전선을 유지하는 규율이라는 그의 관점입니다. 지우지 않는 팀은 낡은 모델을 위한 족쇄를 그대로 짊어진 채 다음 파도에 추월당한다는 것입니다.

그렇다면 지운 다음에는 어떻게 다시 짓느냐. 그의 방법은 조각조각입니다. 첫 단계는 지우는 것, 다음 단계는 그냥 쓰는 것입니다. 모델에게 필요한 지시가 무엇일지 추측하려 들지 말라고 그는 못 박습니다. 잘못 예측할 수 있기 때문입니다. 대신 실제로 돌려봐야 합니다. 고객용 에이전트 제품이라면 그 제품을 돌려 어디서 실패하고 어디서 잘하는지 보고, 클로드 코드를 쓴다면 코드베이스의 어디서 잘하고 어디서 아키텍처에 걸려 넘어지는지 봅니다. 그리고 같은 자리에서 반복적으로 넘어지는 것을 확인했을 때, 오직 그때만 그 지시를 다시 넣습니다. 너무 이르게 넣으면 안 되는 이유는, 모델이 그 지시를 쓸 때마다 매번 읽기 때문입니다. 그러니 모델이 그 지시를 정말로 필요로 하는지 확실히 해야 한다는 것이죠. 와우멘토가 이 대목에서 멈춰 세우고 싶은 이유가 있습니다. 그는 이것이 자신이 해온 모든 엔지니어링과 근본적으로 다르다고 말하기 때문입니다. 과거에는 크고 아름다운 시스템을 짓고, 설계를 앞서 고민하고, 방대한 단위 테스트를 갖추고, 재설계는 몇 달, 심지어 몇 년이 걸리는 큰 프로젝트였습니다. 그런데 모델은 그렇지 않다는 것입니다. 그는 모델을 살아있는 생물처럼, 더 유기적인 무언가처럼 다뤄야 한다고 말합니다. 세대마다 다르게 행동하고 조금씩 다른 성격을 지니므로, 시간을 들여 그 성격을 알아가고 거기에 맞춰 하네스를 조정해야 한다는 것이죠. 시도하고 결과를 보고 반복하는, 매우 경험주의적이고 과학적인 태도가 필요하다고 그는 강조합니다. 그렇다면 이 세상에서 무엇이 안정적으로 남느냐고 진행자가 묻습니다. 이밸은 어떻겠느냐고요. 그는 이밸조차 그리 오래가지 않는다고 솔직하게 답합니다. 이밸은 하네스보다 조금 더 오래 살아남지만 그리 길지는 않아서, 한두 세대, 길어야 세 세대쯤 버틴다는 것입니다. 지금은 지수 곡선 위에 있어 모델이 너무 빨리 좋아지기에, 이밸이 포화되면 버리고 새 이밸을 지어야 합니다. 이 역시 과정의 일부이고, 결국 경험주의라고 그는 되풀이합니다. 제품을 쓰고 모델을 쓰고 어디서 힘들어하는지 보고, 바로 거기서 이밸 세트를 만들어야 한다는 것입니다. 그리고 여기서 그가 가장 아끼는 개념 하나가 등장합니다. 바로 언호블링, 그리고 프로덕트 오버행입니다. 호블링이란 모델이 무언가를 하려는데 제품이 그 앞을 가로막는 상태를 말합니다. 반대로 프로덕트 오버행이란, 모델이 오늘 이미 할 수 있는데도 그것을 끌어내는 제품이 아직 없어 발현되지 못한 능력을 말합니다. 미래의 모델이 아니라 오늘의 모델이 온갖 것을 할 수 있는데, 사람들이 미처 깨닫지 못한 능력이 그토록 많다는 것이죠. 그는 원래의 클로드 코드 자체가 그 사례였다고 회고합니다. 일 년 반에서 이 년 전, 소네트 3.5 시절 그것은 당시 최고의 코딩 모델이었지만, 그 무렵 코딩 제품들은 한 줄 자동완성, 잘해야 여러 줄 자동완성, 읽기만 되는 채팅에 머물러 있었습니다. 모델이 함수 하나를, 파일 하나를 통째로 써낼 수 있는 능력을 온전히 끌어내는 제품이 없었던 것입니다. 그래서 클로드 코드의 발상은 단순했습니다. 모든 비계를 걷어내고 가능한 한 가장 단순한 하네스를 줘서, 모델이 파일 하나를, 기능 하나를 통째로 짓게 하자는 것이었죠. 그것이 그 시절의 프로덕트 오버행이었습니다. 그는 지금의 현대 모델에도 스타트업들이 아직 붙잡지 못한 오버행이 엄청나게 많다고 말합니다. 그렇다면 이 오버행을 실제로 어떻게 붙잡느냐. 그는 창업자들에게 두 가지를 권합니다. 첫째는 모델이 할 수 있으리라 생각하는 것보다 조금 더 어려운 과제를 주라는 것입니다. 그가 보는 가장 흔한 실수는 사람들이 클로드에게 지나치게 구체적인 지시를 내리는 것입니다. '이걸 이렇게, 이렇게, 이렇게 해라, 반드시 하나, 둘, 셋, 넷의 순서로 해라' 하는 식이죠. 현대 모델에게 그것은 결코 올바른 방식이 아니라고 그는 말합니다. 조금 더 높은 층위로 올라가, 과제가 무엇인지, 가드레일이 무엇인지, 종료 조건이 무엇인지를 묘사한 다음 모델이 알아서 요리하게 두고 잠시 뒤에 돌아오라는 것입니다. 반년 전이라면 통하지 않았을 방식이지만 지금은 통한다고, 그리고 놀라게 될 것이라고 그는 강조합니다. 둘째는 그저 실험하고, 상업적 응용이 당장 안 보이더라도 모델과 창의적으로 놀아보라는 것입니다. 풀어야 할 사업 문제, 엔지니어링 문제, 제품 문제가 있다면 최신 모델을 계속 그 문제에 던져보라고, 이전 모델이 못 했어도 새 모델은 할지 모르니까요. 와우멘토가 여기서 강조하는 지점은, 그가 이것을 우연에서 태어난 클로드 코드의 탄생 설화와 겹쳐 본다는 것입니다. 소네트 3.5를 언호블링해 처음으로 온전한 터미널 접근을 준 그 순간처럼, 지금 이 방 안의 누구든 모델을 언호블링하는 법을 찾아내면 다음 클로드 코드를 만들 수 있다는 것이죠. 그가 든 가장 강렬한 사례는 언어 재작성입니다. 이제 모델은 사실상 어떤 코드베이스든 한 언어에서 다른 언어로 옮길 수 있다고 그는 말합니다. 클로드 코드는 번이라는 자바스크립트 런타임 위에서 돌아가는데, 번은 노드의 대안이자 더 빠른 런타임이고 지그라는 시스템 언어로 쓰여 있었습니다. 지그는 C에 가까운 아주 저수준 언어라 메모리를 수동으로 관리해야 하고, 그래서 메모리 누수 같은 문제가 생기기 쉽습니다. 번 팀은 오랫동안 클로드에게 코드베이스를 퍼징시켜 메모리 누수를 한 건씩 찾아내게 하고 있었습니다. 그러다 팀의 제러드가 '그냥 다시 짜보자, 어쩌면 모델이 할 수 있을지도 몰라'라고 던졌습니다. 그는 이것을 새 모델 세대마다 던져보던 시험 문제였다고 설명합니다. 페이블 세대부터 모델이 그것을 해내기 시작했고, 그는 오푸스 5도 할 수 있으리라 봅니다. 제러드가 한 일은 테스트 스위트를 정의한 것이었습니다. 번은 매우 잘 테스트되어 있고 노드에도 방대한 테스트 스위트가 있어, 제대로 했는지 알기 쉬웠습니다. 그는 모델에게 지그에서 러스트로 다시 쓰게 했는데, 프롬프트는 하나였고 다이내믹 워크플로우였으며, 11일 동안 돌아 코드베이스 전체를 다시 썼습니다. 완전한 원샷은 아니었고 중간중간 방향을 잡아주는 조타가 있었지만, 이전 모델은 그 조타를 줘도 아예 불가능했을 일이라고 그는 말합니다. 십만 줄이 넘는 복잡한 자바스크립트 런타임을, 과거였다면 최고의 엔지니어로도 일 년 넘게 걸렸을 일을 11일 만에 해낸 것이고, 그 결과물이 지금 프로덕션에서 실제로 클로드 코드를 돌리고 있습니다. 와우멘토가 곁들이고 싶은 또 하나의 장면은 오픈CV 그림입니다. 최근 앤트로픽 내부에서 누군가 오푸스 5에게 오픈CV를 쥐여주고 그림을 그리게 할 수 있다는 것을 발견해 화제가 되었습니다. 초상화, 동물, 풍경까지 꽤 잘 그리는데, 그들은 모델에게 그림을 가르친 적이 없습니다. 그저 올바른 방식으로 요청하면 해낸다는 '끌어냄의 간극'이고, 상업적 쓸모를 노리지 않고 그저 창의적으로 놀다가 우연히 발견한 것이라고 그는 말합니다. 오늘의 모델에는 아무도 아직 깨닫지 못한 이런 기회가 수십, 수백 개는 있을 것이라는 게 그의 가설입니다.

… The rest of this chapter continues in the full edition, available with a subscription.

Listen to this chapter