Anthropic의 Claude Code 팀에서 일하는 Thariq Shihipar가 South Park Commons에 돌아와 한 시간 동안 대화하고 청중 질문을 받았습니다. 그는 5년간 VC 투자를 받은 게임 스타트업을 운영하다 2024년에 접었고, 2025년 3월 Claude Code를 써보고 완전히 빠져 Anthropic에 합류했습니다. 이 대화를 관통하는 한 가지 생각은 capability overhang입니다. 모델은 이미 우리가 끌어내 쓰는 것보다 훨씬 똑똑하고, 지금 해야 할 진짜 일은 그 격차를 좁히는 것입니다.
진짜 병목은 모델이 아니라 하네스다
capability overhang은 모델의 지능이 하네스나 사용자와의 상호작용이 표현하게 해주는 수준보다 앞서 있는 상태를 말합니다. Thariq는 이게 모델의 영원한 숙제라고 봅니다. 지금 당장 모델 개발을 멈춰도, 앞으로 6개월에서 12개월은 새로운 overhang을 발견하며 보낼 겁니다.
모델은 세대마다 똑똑해지지만, 뾰족하고 비직관적인 방식으로 똑똑해집니다. 2024년의 흔한 생각은 컨텍스트 창이 아주 커지면 코드베이스를 통째로 넣어 문제를 푼다는 것이었습니다. 1억 토큰짜리 창을 상상했습니다. 그런데 Claude Code는 다른 답을 보여줬습니다. 모델이 스스로 컨텍스트를 만들 수 있다면 거대한 창을 기다릴 필요가 없습니다. 이 깨달음이 없으면 그저 1억 토큰 창을 기다리기만 했을 겁니다.
Deep Dive: 2024년의 지배적 생각은 "창을 키워 코드베이스를 통째로 넣자"였고, 그러면 큰 창이 나올 때까지 기다리는 것 말고 할 게 없었습니다. Claude Code의 다른 답은 모델이 개발자처럼 직접 움직이는 겁니다. grep으로 찾고, 관련 파일만 그때그때 열어 읽고, 다 읽으면 버리고 다음 단서를 따라갑니다. 한 번에 다 볼 필요가 없으니 큰 창을 기다릴 필요도 없고, 코드베이스가 어떤 창보다 커도 확장됩니다. 뒤의 "RAG는 안티패턴, grep을 써라"도 같은 이야기의 다른 얼굴입니다. RAG는 미리 다 색인해 두는 "창에 밀어넣기"의 변형이고, grep은 그때그때 가져오기니까요.
plan mode가 좋은 예입니다. 처음 나왔을 때는 모델이 스스로 실행하기엔 똑똑하지 않아서, 미리 계획을 세우게 하는 기능이었습니다.
이제 팀의 많은 사람이 plan mode를 쓰지 않습니다. 모델이 알아서 올바르게 생각하기 때문입니다.
Deep Dive: plan mode는 실행 전에 계획을 글로 써서 승인받는 모드입니다. 약한 모델을 위한 보조 장치였습니다. 예전 모델은 그냥 시키면 성급히 엉뚱한 걸 만들어서, "먼저 계획부터"라는 단계를 밖에서 강제로 끼워야 제대로 된 결과가 나왔습니다. 모델이 알아서 올바르게 생각하게 되자 그 장치는 도움이 아니라 군더더기가 됐습니다. 이는 capability overhang이 닫히는 순간이자, 뒤의 "스캐폴딩은 지우는 게 중요하다"의 실제 사례입니다(RAG를 grep으로 바꾸는 것과 같은 동작). 단, 계획이 사라진 게 아니라 모델 안으로 들어간 것이고, 크고 애매한 작업엔 여전히 명시적 계획이 낫습니다.
이 발표와 같은 날 공개된 workflows 기능도 overhang을 활용하는 방법입니다. workflows는 즉석에서 맞춤 하네스를 만들어냅니다. 예를 들어 deep research는 검색을 백 번쯤 해야 하는 일입니다. 예전에는 그런 하네스를 손으로 짰습니다. 이제는 Claude가 그 하네스를 즉석에서 만들어 실행합니다. 그냥 "이 주제를 오래 고민해봐"라고 프롬프트했다면 컨텍스트 창 안에서 해내지 못했을 일을, 맞춤 하네스로는 해냅니다.
모델을 키우는 것만큼 사람을 가르치는 게 중요하다
Thariq가 Claude Code 팀에서 처음 만든 기능 중 하나가 ask user questions입니다. 계획 단계에서 Claude가 멈춰 "무엇을 하려는 건지 분명히 하자"고 되묻습니다. 예전에는 사용자가 원하는 것을 세세하게 설명해야 했고, 모르는 것조차 미리 알아야 했습니다. 이 기능은 사람이 에이전트와 상호작용하는 방식을 바꿨습니다.
그런데 그는 시간이 지날수록 에이전트 UX를 개선하는 것보다 사람을 가르치는 게 더 중요할 때가 있다고 느꼈습니다. 모델이 똑똑해질수록 할 수 있는 일이 훨씬 많아지기 때문입니다. Claude를 어떻게 프롬프트할지에 대한 멘탈 모델을 쌓는 것이, 제품을 더 만드는 것보다 더 가치 있을 수 있습니다.
Deep Dive: 모델이 이미 대부분의 사용자보다 앞서 있어서, 병목이 도구에서 사람으로 옮겨갔습니다. 그래서 지금 막는 건 "모델이 못 해서"가 아니라 "사람이 어떻게 시킬 줄 몰라서"인 경우가 많습니다. 프롬프트 감각을 한 단계 올리면 그걸로 하는 모든 일이 나아지고(레버리지), 모델이 좋아질수록 그 값어치가 커집니다(복리). 기능 하나를 더 만드는 건 한 가지 일만 나아지게 하고요. 뒤의 7배 격차가 이 차이가 제품이 아니라 사용자의 멘탈 모델에서 온다는 증거입니다. 제품을 만들지 말라는 게 아니라, 사람들이 프롬프트 실력 쌓기를 체계적으로 과소평가한다는 지적입니다.
한 청중이 파워 유저가 평범한 사용자보다 최신 모델에서 최대 7배의 추론 능력을 끌어낸다는 연구를 언급했습니다. Thariq는 두 방향 다 필요하다고 답했습니다. 에이전트 UX도 개선해야 하고, 사람을 가르치는 것도 가치가 큽니다. 이상적으로는 Claude가 얼마나 나설지 스스로 가늠해서 먼저 움직여줘야 합니다. 다만 이건 어려운 문제입니다. 모델과 하네스만의 문제가 아니라, 모델과 하네스와 사용자와 세계가 얽힌 문제이기 때문입니다. 같은 요청도 코드베이스를 속속들이 아는 사람과 모르는 사람에게 다르게 작동합니다.
프롬프트는 아는 것과 모르는 것을 나눠서 접근한다
Thariq는 프롬프트할 때 문제를 네 칸으로 나눕니다. 아는 것을 아는 경우, 안다는 것을 스스로는 모르는 경우(눈으로 보면 알아채지만 미리 설명하진 못함), 가능한지조차 모르는 경우, 모른다는 사실 자체는 분명히 아는 경우입니다. 모든 문제를 이 축으로 뜯어보면 어떻게 프롬프트할지가 보입니다.
프롬프트가 귀찮을 때 그가 쓰는 방법은 모델에게 거꾸로 물어보게 하는 것입니다. "내 아이디어는 이건데, ask user question 도구로 나를 인터뷰해줘. 내가 답할게." 디자인처럼 보면 알 것 같은 경우에는 여러 탐색을 시키고 그중에서 고릅니다. "이 디자인을 탐색해서 HTML mockup을 여러 개 만들어 보여줘."
여기서 핵심은 아직 확신이 없다면 싸게 탐색하라는 것입니다. UI는 HTML로 만드는 게 쌉니다. 진짜 앱 안에서 버튼 하나를 추가하면 새 라우트와 reducer 같은 배선이 딸려오지만, HTML에서는 그냥 버튼입니다. 백엔드 엔드포인트나 테스트도 마찬가지입니다. 이게 내가 원하는 것인지 가장 싸게 확인할 방법을 찾는 겁니다.
하네스 엔지니어링은 짓기보다 유지가 어렵다
하네스를 다루는 기술은 지금 아주 희소합니다. 하네스일 수도, skills일 수도, 프롬프트하는 방식일 수도 있습니다. 자기가 잘하는지조차 알기 어렵습니다. 대체로 사람의 감각에 기대는 일이고, Anthropic 안에서도 이걸 재귀적으로 메타 에이전트에게 맡길지에 대한 의견이 갈립니다.
더 어려운 건 유지입니다. 스타트업이 특정 능력에 맞춰 v1을 만들면, 그걸 v2로 끌고 갈 사람을 못 뽑는 경우가 많습니다. 하네스 엔지니어링이 워낙 희소해서입니다. 그래서 memory 시스템이 Opus 4 시절에 만든 그대로 멈춰 있곤 합니다. Thariq는 스캐폴딩을 짓는 것도 좋지만 지우는 게 정말 중요하다고 말합니다. 모델이 어떤 일을 잘하게 되면 그에 맞춰 손수 만든 스캐폴딩을 걷어내야 합니다. Opus 4.7과 4.8은 파일로 memory를 읽고 쓰는 데 능해서, 이제 memory를 그렇게 다룰 거라 기대합니다. 컨텍스트 검색을 위한 RAG는 이제 안티패턴에 가깝고, 대신 grep을 쓰는 게 낫습니다. 다만 2024년에 RAG 인덱싱을 만든 스타트업도 많았습니다.
이 기술을 측정하는 도구가 eval입니다. Thariq는 하네스 엔지니어링 전체는 예술이지만 eval은 좀 더 과학에 가깝다고 봅니다. 언덕을 오르듯 점수를 놓고 개선할 수 있기 때문입니다. 다만 eval은 zero-to-one을 위한 도구가 아닙니다. 새 기능을 만들 때는 긴 호흡의 eval을 먼저 짜고 시작하지 않습니다. workflows도 그렇게 만들지 않았습니다. 많은 스타트업은 eval을 만들기보다 빠르게 반복하며 감을 쌓아야 합니다. eval에 투자할 때는 기능이 자리 잡아 유지하고 개선해야 할 때입니다.
Deep Dive: eval은 "무엇이 좋은 답인가"를 못 박아야 만들 수 있는데, 발견(zero-to-one) 단계엔 그 정답이 아직 없습니다. 그래서 새 기능은 eval 먼저 짜지 말고 써보며 감으로 판단합니다(workflows가 그랬습니다). 요리를 처음 개발할 때 채점 기준표부터 만들지 않고 맛으로 조정하는 것과 같습니다. eval이 빛나는 건 기능이 자리 잡은 뒤입니다. 후퇴를 막고, 언덕 오르듯 개선하고, 여럿이 같은 목표를 볼 수 있게 해줍니다. 주의: eval을 갖췄다는 것과 실제로 더 좋게 만드는 것은 다릅니다(측정 ≠ 성과).
좋은 eval을 만드는 건 아주 어렵습니다. 트위터에서 화제가 된 일본인 사례가 있습니다. 3년 동안 수백만 장의 이미지에 사람의 눈과 입, 골격의 경계 상자를 아주 정밀하게 그린 사람입니다. 그의 결과물은 어떤 얼굴·골격 인식 시스템보다 낫지만, 그 일은 지독하게 지루하고 기술 수준도 높아 외주를 주기도 어렵습니다. 그래서 eval은 사실상 사기도 힘듭니다. Thariq는 AI로 뭔가 해보고 싶다는 사람에게 오히려 이런 지위 낮고 지루한 일을 고르라고 권합니다.
동시에 eval은 매우 가치 있습니다. Jared가 강력한 테스트 스위트를 주고 Bun을 Rust로 다시 짠 것이나, Karpathy의 auto research(손실을 줄이라는 목표를 주면 될 때까지 반복하는 하네스)가 그 예입니다. 하지만 모든 문제에 eval을 둘 수는 없습니다. 사람들이 "Claude Code가 멍청해진 것 같다"고 할 때, 그건 대개 SWE-bench 점수가 아니라 "Claude가 너무 일찍 멈춘다"는 뜻입니다. 그러면 stop-early eval이 필요한데, 문제를 직접 보기 전에는 그런 eval이 필요한지조차 알 수 없습니다.
AI 시대 조직은 생산성이 아니라 매출로 설계한다
Thariq는 Claude Code 팀이 조직 설계의 모범은 아니라고 선을 긋습니다. 제품을 만들려고 그 제품을 쓰는 dogfooding 조직이라, 피드백 루프가 다른 조직과 다르기 때문입니다.
그가 던지는 핵심 질문은 생산성을 어떻게 매출로 바꾸느냐입니다. PR을 두 배로 늘려도 매출은 거의 그대로일 수 있습니다. 조직이 하는 일의 많은 부분이 buy-in을 얻고, 무엇을 할지 정하고, 시장이 원하는지 판단하는 일이기 때문입니다. 대부분의 시도는 실패하고, 더 빨리 실패한다고 돈을 더 버는 건 아닙니다.
그는 1995년 자동차 딜러와 이메일 비유를 듭니다. 이메일이 나왔을 때 접수 직원에게 이메일을 줘서 더 빨리 소통하게 할 수 있습니다. 하지만 그렇다고 차를 더 팔지는 미지수입니다. 아니면 이메일과 웹으로 차를 주문받게 할 수도 있습니다. 이쪽이 매출을 늘립니다. 내 문제에 맞는 이런 비유를 찾는 게 한 방법입니다.
만드는 게 싸지면서 오히려 무엇을 우선할지가 더 어려워졌습니다. 다 병렬로 띄울 수 있으니 예전처럼 티셔츠 사이즈로 규모를 재는 게 의미 없어 보입니다. 그래도 Thariq는 무언가를 만드는 데 드는 끈기는 거의 줄지 않았다고 말합니다. 만드는 건 싸졌지만, 이제 buy-in을 얻고 스스로 믿어야 합니다. 탐색 단계는 늘어나야 하지만, 결국 "이거다"라고 방향을 정하는 건 사람입니다. Anthropic의 Claude Design을 이끄는 Nate를 처음 만났을 때 Thariq는 "이 사람은 해낼 사람"이라고 느꼈다고 합니다.
여기엔 Dario에게 배운 태도가 겹칩니다. 보통은 "좋고, 빠르고, 싼 것 중 둘을 고르라"는 트레이드오프가 합리적으로 들립니다. 하지만 Dario는 "셋 다 하면 안 되나"라고 되묻습니다. 합리적인 제품 감각으로 우선순위를 정하는 게 맞을 때도 있지만, 틀릴 수도 있습니다. 현실이 진짜 트레이드오프를 보여주게 밀어붙이는 편이 낫습니다. 때로는 다소 무리해서 "안전한 AI를 만들면서 매출도 크게 내고 세상에 가치도 준다"고 밀고 나가는 편이 낫습니다.
파운더에게: 불확실성에 흥분하고 모델 랩에 상보적으로 붙어라
AI는 모두에게 예측하기 어렵습니다. Anthropic조차 몇 년 뒤 필요한 컴퓨트를 미리 사둬야 하고, 수십억 달러어치를 사놓고 그만큼 매출이 나기를 바라는 위험을 집니다. Thariq는 지금을 탐험의 시대로 봅니다. 프런티어 랩까지 포함해 모두가 무엇이 가능한지 알아가는 중입니다.
스타트업을 한다고 하면 "왜 하냐, 어차피 Anthropic이나 OpenAI가 하지 않겠냐"는 말을 듣습니다. 그는 이제 스타트업이 안전하거나 지위 높은 선택이 아니라고 인정합니다. 그래서 탐색과 불확실성에 흥분할 수 있어야 하고, "그래도 나는 할 수 있다"는 내적 확신이 가장 중요합니다.
방향에 대해서는 모델 랩에 상보적으로 붙으라고 조언합니다. 지금 세상의 많은 부분은 에이전트를 위해 만들어지지 않았습니다. 에이전트는 건강 데이터나 은행 계좌에 접근하지 못합니다. 이렇게 잠긴 데이터를 에이전트가 쓸 수 있게 만드는 일은 아주 가치 있습니다. 규제가 있는 틈새에 AI를 밀어 넣는 것도 마찬가지입니다.
또 하나는 "바다를 끓이는" 발상입니다. 제품에 AI를 얹는 대신, AI의 능력으로 전에는 너무 야심 차서 못 하던 일을 하는 겁니다. React 팀에서 일하던 Chang이 브라우저 텍스트 렌더링 문제에 시달리다 pretext라는 맞춤 렌더링 라이브러리를 만든 게 그런 예입니다. 예전엔 못 했을 일을 이제는 그냥 해냅니다. 2천만 줄, 5억 줄이 필요했던 문제를 이제 풀 수 있다면 어떨까요.
이 관점은 모든 제품이 능력이 어디로 갈지에 대한 베팅이라는 생각으로 이어집니다. 그는 Conductor를 예로 듭니다. Conductor는 모델이 상품처럼 흔해지고 S커브에서 완만해진다는 데 건 좋은 베팅입니다. 예전 같으면 "괜찮은 dev tool이고 사람들이 좋아하니 쫓아가서 큰 사업으로 키우자"고 봤을 겁니다. 지금도 사람들이 사랑하는 것을 만들면 좋은 결과가 따라옵니다. 전략적으로 옳은지 과하게 고민할 필요는 없습니다. 어느 베팅이 이길지는 분명하지 않지만, 그래도 베팅은 해야 합니다.
https://youtu.be/O-1VXHRlH54