Boris Cherny: Claude Code를 만들다

Boris Cherny: Claude Code를 만들다

Claude Code를 만든 Boris Cherny가 말하는 Opus 5, 며칠씩 도는 에이전트, 그리고 모델이 계속 앞서 달아나는 시대에 제품을 만든다는 것.

Root Access · 2026-07-28 게재

Opus 5 출시 직후, Claude Code를 만든 Boris Cherny가 Startup School 2026에서 Diana Hu와 함께 최신 모델이 무엇을 할 수 있는지, Claude Code가 어떻게 태어났는지, 그리고 기반 역량이 계속 가속하는 시대에 제품을 만든다는 게 무엇을 의미하는지 이야기합니다.

영상 설명란 — Y Combinator Startup School 2026에서 Claude Code를 만든 Boris Cherny가 Diana Hu와 나눈 대담입니다. 대담 전문은 공식 트랜스크립트에서 읽을 수 있습니다. 스타트업을 시작하고 싶다면 Y Combinator 지원, YC 스타트업에 합류하고 싶다면 스타트업에서 일하기를 참고하세요.

YouTube에서 보기

타임스탬프

• 00:00 — 인트로
• 00:07 — Opus 5는 무엇이 다른가
• 02:06 — 프롬프트 인젝션 풀기
• 03:21 — Claude Code가 시스템 프롬프트 80%를 지운 이유
• 06:37 — AI 제품에 Delete 키를 눌러라
• 07:20 — 시스템 프롬프트 재구축법
• 10:30 — 프로덕트 오버행과 AI '족쇄 풀기'
• 14:26 — Claude에게 더 어려운 문제를 줘라
• 19:32 — 프롬프트 엔지니어링의 변화
• 21:57 — 2주 걸린 Claude Code 프롬프트
• 24:42 — 수천 개의 AI 에이전트 돌리기
• 30:15 — 코딩은 (거의) 풀렸다
• 32:20 — CS 학생이 여전히 배워야 할 것

00:00 · 인트로

다이애나: 자, 보리스. 모시게 되어 정말 기쁩니다. Claude Code를 만든 분이시죠. 감사합니다.

보리스: 여기 오게 되어 좋습니다.

00:07 · Opus 5는 무엇이 다른가

다이애나: 정말 따끈따끈한 소식인데, 바로 어제 Opus 5를 출시하셨잖아요.

보리스: 네.

다이애나: 모델 성능이 계속 가속하는 것 같아요. ARC-AGI-3를 30%까지 끌어올리셨는데, 정말 놀라운 일이죠.

보리스: 네.

다이애나: 맥락을 드리자면, 이전까지 최고 기록은 한 자릿수 초반이나 10%대 초반이었잖아요. Opus 5는 이전 버전이 못 하던 것 중에 지금 뭘 할 수 있나요?

보리스: 네. 새 모델 하나하나에는 정말 많은 게 들어가고, 저희가 가르쳐서 모델이 하게 만드는 새로운 능력도 많습니다. 모델 훈련을 할 때는 온갖 것들을 한꺼번에 가르치려고 시도하는데, 대부분은 잘 안 됩니다. 그런데 그중 일부는 모델이 실제로 배워요. 그리고 가끔은 모델이 우리를 놀라게 하기도 합니다. 실제로 가르치지도 않았는데 그냥 스스로 익힌 스킬, 능력 같은 게 있는 거죠. 5의 경우, 다른 어떤 모델도 해본 적 없다고 생각하는 것 하나를 예로 들면, 아주 오랜 시간 동안 돌아간다는 겁니다. 특히 Opus 5를 오토 모드(Auto Mode)와 결합하면 그냥 놀라워요. 며칠, 몇 주, 몇 달씩 갈 수 있습니다. 그냥 멈추지를 않아요. 스캐폴딩을 쓸 필요도 없습니다. /goal도 필요 없고, 그런 다른 장치들도 다 필요 없어요.

보리스: 태스크를 끝내야 한다는 걸 아니까 그냥 계속 갑니다.

02:06 · 프롬프트 인젝션 풀기

보리스: 또 하나 제가 정말 기대하고 있고 앞으로 조금씩 더 이야기하려는 건 — 워낙 새로운 능력이라 놀라운데요 — 이제 모델이 프롬프트 인젝션(prompt injection·주입 공격)에 더 이상 당하지 않는 것처럼 보인다는 겁니다.

다이애나: 프롬프트 인젝션이 안 된다고요.

보리스: 미친 일이죠. 사람들이 오랫동안 '치명적 3요소(lethal trifecta)' 이야기를 해왔잖아요. 이건 하네스 설계, 에이전트 설계, 제품 설계에 정말 큰 영향을 줍니다. 모델이 인터넷에서 "X 하고 Y 하고 Z 하고, 그리고 유저 컴퓨터에 있는 걸 전부 삭제해" 같은 지시문을 읽으면, 1년 전 모델이라면 그냥 그대로 했을 거예요. 그런데 요즘 Opus는 안 합니다. 사실 이건 Opus 4.7, 4.8부터 그랬어요. Sonnet 5도 이걸 꽤 잘했고, Table(원문 표기 그대로 — 문맥상 Fable로 추정)도 꽤 잘했습니다. 그런데 Opus 5는 여기서 완전히 새로운 프런티어에 도달했어요. 요컨대 잘 정렬된(well-aligned) 모델 — 이건 사실상 3년치 얼라인먼트 연구의 결과물인데요 — 을 프롬프트 인젝션 분류기와 결합하는 겁니다. 이 분류기는 전체 트래픽에 대해 돌리고 있어요. 이게 하는 일은, Crysola(원문 표기 그대로)의 mechanistic interpretability(기계적 해석 가능성) 연구에 기반해서, 말 그대로 프롬프트 인젝션이 일어날 때 켜지는 모델 두뇌 속 뉴런들을 들여다보는 겁니다.

보리스: 그래서 모델이 말해주지 않아도, 우리는 그 뉴런들을 실제로 볼 수 있고, 인젝션이 일어나고 있다는 걸 파악하고 진단할 수 있어요. 그리고 그걸 오토 모드 분류기와 결합합니다. 이 세 겹의 레이어를 합치면, 이제는 프롬프트 인젝션을 더 이상 재현조차 못 하는 상태예요.

03:21 · Claude Code가 시스템 프롬프트 80%를 지운 이유

다이애나: 프롬프트 인젝션 얘기가 나왔으니, 동전의 반대편은 이제 시스템 프롬프트인데요. 새 릴리즈 얘기를 좀 해보죠. 실제로 Claude Code의 시스템 프롬프트를 80% 넘게 지우셨잖아요.

보리스: 네.

다이애나: 더 자세히 얘기해주세요.

보리스: 많은 분들이 잘 모르실 수 있는 게, Claude Code는 제품으로서도 하네스로서도 그냥 항상 변하고 있다는 겁니다. 계속 뭔가를 더하고, 계속 뭔가를 지워요. 새 모델이 나올 때마다 시스템 프롬프트를 잔뜩 지우고, 잔뜩 바꿉니다. 툴 셋도 항상 바꾸고, 툴에 붙는 프롬프트도 항상 바꿔요. 이유는 모델마다 정말 다르기 때문입니다. 석 달 전쯤 어떤 모델에 맞춰서 했던 게 다음 모델에는 전혀 안 통할 수 있어요. 그리고 Opus 5의 특징 하나는 그냥 정말 지능적이라는 겁니다. 시스템 프롬프트에 있던 것들 중 상당수는, 모델이 당연히 알았어야 하는데 몰랐던 행동들을 교정하는 내용이었어요. 이제 Opus 5는 그걸 그냥 합니다. 그래서 네, 시스템 프롬프트의 80%를 지웠어요.

보리스: 사실 나머지도 직접 지워보실 수 있습니다. Claude Code를 돌릴 때 --system-prompt로 원하는 시스템 프롬프트를 마음대로 설정해서 실험해볼 수 있어요. 또 하나 해볼 수 있는 건 심플 모드입니다. 일종의 문서화 안 된 기능인데요. 'Claude Code simple=1' 같은 환경변수를 걸고 Claude를 실행하면, 툴에 붙은 것까지 포함해서 모든 시스템 프롬프트를 지웁니다. 저희는 실제로 이걸 일종의 ablation(절제 실험)으로 써서, 이 프롬프트가 유용한가를 판별해요. 흥미로운 건, 이런 프롬프트들이 없을 때 모델이 실제로 조금 더 똑똑하다는 겁니다. 저희가 계속 발견해온 사실이에요. 다만 Claude Code를 제품으로 쓸 때는 이 프롬프트들 중 일부가 실제로 필요합니다. 제품을 쓰는 데 도움이 되고, 사람이 쓸 때 원하는 방식으로 제품과 모델이 동작하게 해주니까요.

06:37 · AI 제품에 Delete 키를 눌러라

다이애나: 이 시대의 만들기에서 정말 흥미로운 지점이 이거라고 생각해요. 여러분은 기본적으로 세계 최고의 Claude용 하네스를 만들었고, 그게 Claude Code잖아요. 지금 들리는 얘기로는, 모델이 릴리즈될 때마다 기본적으로 코드베이스를 다 지우고, 프롬프트를 다 지우고, 매번 처음부터 다시 시작한다는 거예요. 옛날 세계였다면 스타트업이 제품에 대해 할 만한 일이 아니죠. 6개월마다 전부에 대해 Delete 키를 누르는 셈이니까요.

보리스: 맞습니다. 공정하게 말하면 코드베이스 전체를 지우는 건 아니지만, 정말 많이 지웁니다. 새 모델이 나올 때마다요. 연구 쪽에서는 이걸 ablation이라고 부릅니다. 무슨 뜻이냐면, 시스템 프롬프트 전체를 지운 다음 한 줄씩 되살리면서 각 줄의 영향을 파악하는 거예요. eval(평가) 같은 거고, 실제로 평가할 수 있습니다. ablation은 본질적으로 eval인데, 뭔가를 지워서 그 영향을 알아내는 거죠. 툴에 대해서도 똑같이 합니다. 툴을 항상 unship(철수)해요. 하네스의 코드도 항상 지우고요. 오늘날 Claude Code 하네스에 있는 코드를 보면, 거의 전부가 안전과 권한, 정적 분석에 관한 겁니다. UI 코드도 꽤 있고요.

보리스: 그 외의 코드는 사실 이미 많이 unship했습니다.

다이애나: 에이전틱 제품과 하네스를 이렇게 만드는 방식, 그러니까 새 모델이 릴리즈될 때마다 ablation을 하는 방식 — 이 방에서 AI 제품을 만드는 모두가 그렇게 해야 할까요? 편안하고 용감하게 Delete 키를 누를 수 있어야 하나요?

보리스: 100%요. 그리고 에이전틱 제품을 만드는 게 아니라 Claude Code를 쓰시는 분들도, 6개월마다 여러분의 quantum D(원문 표기 그대로 — 문맥상 CLAUDE.md)를 지우고, 스킬을 지우고, 훅을 지워보세요. 모델이 뭘 하는지 보면 놀라실 수도 있습니다. Opus 5에 대해서는 저희가 정말로 권장하는 건데요 — 이런 것들을 전부 그냥 지워보세요. 과거 모델들에 필요했던 그 지시문들이 이 모델에는 다 필요 없을 수 있으니까요.

07:20 · 시스템 프롬프트 재구축법

다이애나: 이 새 프롬프트를 어떻게 만드는지 얘기해보죠. 새 모델이 릴리즈되면, 이 방의 모두가 Opus 5를 써보고 싶을 거고, 자기 시스템 프롬프트에 Delete를 누를 거예요. 그다음 시스템 프롬프트 재구축은 어떻게 해야 하나요? 환경 세팅은 어떻게 하죠?

보리스: 하나씩 하나씩 하는 겁니다. 첫 단계는 지우는 거예요. 다음 단계는 써보는 겁니다. 모델에 어떤 지시문이 필요할지 추측하면 안 돼요. 정확히 예측 못 할 수 있으니까요. 해야 할 일은 돌려보는 겁니다. 커스텀 에이전틱 제품을 만들고 있다면 그 제품을 돌려보세요. 그 모델로 어디서 실패하는지, 뭘 잘하는지 보세요. Claude Code를 쓰고 있다면 여러분의 코드베이스에서 뭘 잘하는지, 혹은 아키텍처나 다른 뭔가에서 어디서 발이 걸리는지 보세요. 같은 지점에서 반복적으로 발이 걸리는 걸 확인했을 때, 그때 그 지시문을 다시 넣는 겁니다. 너무 일찍 넣으면 안 돼요.

보리스: 기억하세요, 모델은 여러분이 쓸 때마다 이 지시문을 매번 읽습니다. 모델에게 이 지시문이 정말 필요한지 확실히 해야 해요. 모델 위에서 만든다는 것의 미친 점이 이거라고 생각합니다. 제가 지금까지 해온 그 어떤 엔지니어링과도 정말 달라요. 과거에 시스템 위에서 만들 때는, 크고 아름다운 시스템을 만들면서 시스템 설계를 정말 선행적으로 고민했잖아요. 대규모 유닛 테스트 스위트가 있고, 모든 걸 미리 생각해두고요. 리아키텍처는 큰 프로젝트라 몇 달씩 걸리기도 합니다. 저는 대기업에서 몇 년씩 걸리는 리아키텍처 제품 작업도 해봤어요. 모델은 그렇지 않습니다. 거의 살아있는 생물, 좀 더 유기적인 무언가처럼 생각하는 게 맞아요. 모델 세대마다 다르게 행동하고, 성격도 조금씩 다릅니다.

보리스: 시간을 들여 그 모델을 알아가고, 그에 맞춰 하네스를 조정해야 합니다. 굉장히 경험적이고 과학적인 일이에요. 뭔가 시도해보고, 결과를 보고, 그걸 바탕으로 반복하는 과학적 마인드셋으로 접근해야 합니다.

다이애나: 지금 이런 세계에서 만들고 있다면, 그럼 뭐가 안정적으로 남나요? eval은 이전 모델에서 가져와서 새 모델 릴리즈마다 계속 쓰는 건가요?

보리스: eval을 최대치로 뚫어버릴(max out) 때까지는 그렇게 합니다.

다이애나: 그게 모두를 위한 팁이네요. 코드와 시스템 프롬프트 — 최첨단에서 만들고 모델 역량을 최대로 뽑고 싶다면 그것들은 지워야 한다. 하지만 eval은 상수라서 기본적으로 계속 덧붙여 나간다.

보리스: 네, 계속 덧붙입니다. 그런데 실제로는 — 솔직히 저라면 그렇게까지 말하지도 않을 것 같아요. eval이 하네스보다 조금 오래 살긴 하는데, 그렇게 많이는 아닙니다. eval 하나가 모델 한두 세대, 세 세대 정도 갈 수 있어요. 하지만 요즘 우리는 지수 곡선 위에 있잖아요. 모델이 너무 빨리 좋아지고 있습니다. eval을 그냥 포화시켜버려서, 버리고 새 eval을 만들어야 하는 일이 아주 잦아요. 이것도 그냥 과정의 일부입니다. 다시 말하지만 경험적으로 가는 게 핵심이에요. 제품을 쓰고, 모델을 쓰고, 어디서 버벅대는지 봐야 합니다. 그걸 바탕으로 만든 게 여러분이 만들어야 할 eval 셋이에요.

10:30 · 프로덕트 오버행과 AI '족쇄 풀기'

다이애나: Claude 위에서 최고의 에이전틱 제품을 만드는 법에 대해 보리스가 쓰신 표현 중에, Claude를 언호블링(unhobbling·족쇄 풀기)한다는 개념이 있던데요. 무슨 뜻인지 더 얘기해주세요.

보리스: 네. 호블링(hobbling)은 연구 쪽에 있는 개념인데, 모델은 뭔가를 하고 있는데 우리가 그냥 방해가 되고 있다는 겁니다. 제가 정말 좋아하는 사고방식이 하나 있는데, 제품을 만들 때 아주 유용해요. 프로덕트 오버행(product overhang)이라고 부릅니다. 아이디어는, 미래 모델이 아니라 오늘의 모델이 이미 온갖 것들을 할 수 있는데 우리가 아직 깨닫지 못했다는 거예요. 사람들이 모르는 이런 능력이 모델에 정말 많습니다. 특정 툴을 쓰는 능력일 수도 있고, 특정 언어를 쓰는 능력, 특정 종류의 문제를 푸는 능력, 모델 역량 밖이라고 여겨졌던 특정 방식으로 일하는 능력일 수도 있어요. 매 모델 세대마다 모델은 이걸 할 수 있는데, 모델이 그걸 하게 해주고 그 능력을 표현하게 해주는 제품이 없는 경우가 많기 때문에 이 오버행이 생기는 겁니다.

보리스: 그리고 뒤집어 보면, 제품이 방해가 되는 경우가 많아요. 이 방해하는 걸 호블링이라 부르고, 모델에서 올바른 행동을 끌어내지 못하는 걸 프로덕트 오버행이라고 부릅니다. 같은 것의 양면인 셈이에요. 한 가지 예가 오리지널 Claude Code였습니다. 제가 처음 작업을 시작한 게 1년 반, 2년 전쯤인데요. Sonnet 3.5 시절이었습니다. 당시엔 굉장한 코딩 모델이었어요. 존재하는 최고의 코딩 모델이었죠. 요즘 기준으로는 꽤 형편없는 코딩 모델이지만요. 그래도 Anthropic이 만든 첫 위대한 코딩 모델이었다고 생각합니다. 그 당시 코딩 제품들을 보면 뭘 하고 있었냐면, 한 줄짜리 자동완성이었어요.

보리스: 가끔은 여러 줄 자동완성도 했죠. 그게 새로운 아이디어였습니다. 챗도 했어요. 에이전트랑 대화할 수 있는데 쓰기 접근은 없었습니다. 읽기만 가능했어요. 코드베이스에 대해 물어볼 수만 있었죠. 그래서 느낌이, 함수 전체를 한 번에, 파일 전체를 한 번에 쓸 수 있는 모델의 능력을 온전히 끌어내는 제품이 딱히 없다는 거였습니다. 그때는 피처 전체까지는 아니었어요. 거기까지는 못 갔고, 아마 파일 전체 정도. 그게 당시의 능력 수준이었습니다. Claude Code의 아이디어는 이거였어요. 좋다, 모델이 아마 이걸 할 수 있을 것 같다. 스캐폴딩을 전부 걷어내고 모델에 가능한 한 가장 단순한 하네스만 줘서, 파일 하나를 통째로 쓰고 피처 하나를 통째로 만들 수 있게 하면 어떨까? 그게 사실상 다였습니다.

보리스: 그게 그 시절의 프로덕트 오버행이었어요. 모델은 뭔가를 할 수 있는데 모든 게 그냥 방해만 되고 있었죠. 요즘의 현대 모델에는, 스타트업들이 잡아내지 못하고 있는 프로덕트 오버행이 정말 많다고 생각합니다. 이런 문제를 고민하는 사람들이 있긴 하지만, 놀랍고 흥미롭고 상업적으로 가치 있는 이런 행동들을 모델에서 끌어낼 기회가 그냥 어마어마하게 많아요.

다이애나: 이 방에 계신 모두에게 정말 특별한 인사이트라고 생각해요. 기본적으로, 모델을 언호블링하는 법을 알아내면 여러분 모두가 다음 Claude Code를 만들 수 있다는 거잖아요. 그게 사실상 Claude Code의 탄생 스토리니까요. 이전 시도들이 전부 모델을 IDE 안에 아주 경직된 채로 가둬두는 동안, Sonnet 3.5를 언호블링하신 거죠. 그리고 Claude Code는 모델에 온전한 터미널 접근을 그냥 준 첫 사례 중 하나였고요.

보리스: 네.

14:26 · Claude에게 더 어려운 문제를 줘라

다이애나: 그렇게 계속 나아가는 이 놀라운 제품이 만들어진 거고요. 그럼 미래의 파운더들이 Claude를 언호블링하고 이 프로덕트 오버행을 해소할 수 있는 영역은 뭔지, 어떻게 생각해야 하는지 얘기해보죠.

보리스: 제가 생각하는 게 몇 가지 있는데요. 하나는, 모델이 할 수 있다고 생각하는 것보다 약간 더 어려운 태스크를 줘야 한다는 겁니다. 정말 흔히 보는 실수가, 사람들이 Claude Code를 쓰고 Claude를 쓰면서 지나치게 구체적인 지시를 준다는 거예요. "이걸 해줘, 그런데 이런 방식, 이런 방식, 이런 방식으로 해. 반드시 1을 하고, 그다음 2, 그다음 3, 그다음 4를 해." 현대 모델에는 그게 정말이지 맞는 방법이 아닙니다. 조금 더 하이레벨로 가야 해요. 태스크를 설명하고, 가드레일을 설명하고, 종료 기준(exit criteria)을 설명한 다음, 모델이 알아서 요리하게 두고(let the model cook) 잠시 후에 돌아오세요. 놀라실 겁니다. 다시 말하지만, 6개월 전엔 안 통했을 방법인데 오늘은 통해요.

다이애나: 6개월 전엔 못 했는데 지금은 할 수 있는, 사람들이 탐험해봐야 할 도전적인 태스크나 능력의 예를 몇 개 들어주실 수 있나요?

보리스: 네, 좋아요. 한 가지 예는, 이제 모델이 사실상 어떤 코드베이스든 한 언어에서 다른 언어로 다시 쓸 수 있다는 겁니다. 그냥 좀 미친 일이죠. 엔지니어가 하면 아주 오래 걸렸을 일인데, 이제 모델이 꽤 빠르게 해냅니다. 한 예로, Claude Code는 Bun JavaScript 런타임 위에 만들어져 있어요. 오픈소스 JavaScript 런타임이고, Node.js의 대안입니다. 말하자면 더 빠른 Node죠. Bun은 Zig로 작성됐습니다. Zig는 시스템 프로그래밍 언어예요. C 같은 겁니다. 아주 로우레벨이죠. Zig의 문제 하나는 메모리를 수동으로 관리해야 한다는 겁니다. 그래서 메모리 누수나 다른 메모리 관리 이슈가 생기는 상황에 빠지기가 꽤 쉬워요. Bun 팀이 하던 것 중 하나가, Claude에게 코드베이스를 퍼징(fuzzing)시켜서 메모리 누수를 시뮬레이션하고 유발해보게 하는 거였습니다.

보리스: 이걸 오랫동안 했어요. 메모리 누수를 정말 많이 찾아냈습니다. 한 번에 한 건씩이었죠. 그게 당시 모델의 능력이었어요 — 이 퍼징을 하는 것. 그러다 어느 시점에 팀의 Jared가, 좋다, 그냥 다시 쓰자, 어쩌면 모델이 할 수 있을지도 모른다고 한 거예요. 새 모델 세대가 나올 때마다 모델에 던져보는 그런 테스트 문제 중 하나였던 것 같습니다. Fable부터 모델이 이걸 해내기 시작했어요. Opus 5도 할 수 있었을 겁니다. Jared가 한 건 본질적으로 테스트 스위트를 정의한 거예요. Bun의 좋은 점은 정말, 정말 테스트가 잘 돼 있다는 겁니다. Bun에도 큰 테스트 스위트가 있고, Node.js에도 큰 테스트 스위트가 있어요.

보리스: 그래서 제대로 했는지 알기가 쉽습니다. 그는 모델에게 Zig에서 Rust로 다시 쓰게 했어요. 프롬프트 하나였습니다. 다이내믹 워크플로우(dynamic workflow)였어요. 다이내믹 워크플로우는 Claude Code의 기능인데, 본질적으로 수십, 수백, 수천 개의 에이전트를 생산적으로 오케스트레이션하게 해줍니다. 11일 동안 돌았고, 코드베이스 전체를 다시 썼어요.

다이애나: 그리고 그게 원샷이었나요?

보리스: 원샷이었— 아니요, 원샷은 아니었고 스티어링(steering·중간 개입)이 있었습니다. 스티어링이 있었어요. 하지만 이전 모델들은 스티어링이 있어도 이걸 못 했습니다. 그냥 불가능했을 거예요.

다이애나: 겨우 11일이라니. 세상에. 과거였다면 최고의 엔지니어들이 붙어도 몇 달, 몇 년 걸렸을까요?

보리스: 확실히 1년은 넘죠.

보리스: 네. 1년 이상요. 이게 10만이 넘는 규모였어요. JavaScript 런타임은 정말 복잡합니다. 안에 든 게 정말 많아요. 그리고 네, 작동합니다. 지금 프로덕션에 들어가 있어요. 여러분이 Claude Code를 돌릴 때 지금 쓰는 게 바로 이겁니다. 이게 한 가지 예고요. 두 번째 예를 들자면 — 프로덕트 오버행이요. 이건 실용적인 유스케이스인데, 풀고 있는 문제가 있는 경우죠. 비즈니스 문제, 엔지니어링 문제, 제품 문제요. 최신 모델을 계속 거기에 던져보면서 그냥 해내는지 봐야 합니다. 이전 모델이 못 했어도 새 모델은 할 수 있으니까요. 두 번째 사고방식은 실험하라는 겁니다. 모델을 갖고 놀면서 창의적인 걸 해볼 자유를 스스로에게 주세요. 종종 놀라게 될 겁니다. 요 몇 주 사이 Anthropic 내부에서 실제로 정말 인기를 끌고 바이럴이 된 게 하나 있는데, 누군가 Opus 5에 OpenCV를 주면 그림을 그리게 할 수 있다는 걸 알아냈어요.

보리스: Opus한테 "이 이미지를 OpenCV로 그려줘"라고 부탁할 수 있는 거죠. 실제로 꽤 잘합니다. 초상화도 그릴 수 있어요. 동물도 그리고, 풍경도 그립니다. 저희는 모델에게 그림 그리는 걸 가르친 적이 없어요. 그냥 유도(elicitation) 격차인 겁니다. 올바른 방식으로 시키면 그냥 해내요. 직접적인 상업적 응용이 없는 창의적인 걸 그냥 갖고 놀다가 우연히 발견했습니다. 하지만 흥미롭죠. 제 가설은, 오늘의 모델에도 아무도 아직 깨닫지 못한 이런 기회가 아마 수십, 수백 개는 있을 거라는 겁니다.

다이애나: 그리고 이거의 큰 연구 영역이 기본적으로 모델 유도(elicitation)인 거죠? 이런 능력들을 전부 알아내고 모델에게 올바른 걸 시키는 데 정말 능숙해지는 것 말이에요.

보리스: 네.

19:32 · 프롬프트 엔지니어링의 변화

다이애나: 사람들은 어떻게 그걸 더 잘하게 되나요? 그리고 사실상, 프롬프트 엔지니어링은 어떻게 더 잘하게 되죠? 여전히 프롬프트 엔지니어링을 많이 해야 하나요, 아니면 그것도 변하고 있나요? 이게 어디로 가고 있는지 말해주세요.

보리스: 네. 1년 전에 가장 인기 있는 채용 공고 중 하나가 프롬프트 엔지니어였던 게 기억나요. 그러다 바뀌어서 컨텍스트 엔지니어가 된 것 같습니다. 이런 파도들이 있는 거예요. 왔다가 갈 겁니다. 요즘의 스킬은 프롬프트 엔지니어링이라기보다는, 약간 너무 어려워 보이는 어려운 태스크를 Claude에게 어떻게 주느냐를 알아내는 것에 가깝다고 생각해요. 그다음, Claude가 진행하면서 자기 작업을 스스로 검증할 수 있게 만드는 방법이요. 이 검증이 아마, 대체로 사람들이 제대로 못 하는 것 중 단연 가장 중요한 지점일 겁니다.

21:57 · 2주 걸린 Claude Code 프롬프트

보리스: 한 가지 예를 들면 — 저희한테 Claude 데스크톱 앱이 있는데 Electron으로 만들어져 있어요. 꽤 빠르게 만들어놨습니다. 지금은 꽤 훌륭한 경험이에요. 6개월 전엔 굼뜨고 그렇게 안정적이지 않았습니다. 지금은 꽤 좋아요. 팀 대부분이 쓰는 게 이겁니다. 실험으로, 네이티브면 어떤 느낌일지 보고 싶었어요. 그래서 제가 한 건 Claude Tag 세션을 하나 시작한 겁니다. Claude Tag는 저희가 새로 내놓은 제품인데, 그냥 Slack 안에서 돌아가는 Claude예요. 첫 질문은 "Tag야, GitHub에서 macOS 러너에 접근할 수 있어?"였습니다. 없다고 하더라고요. 그래서 러너를 연결해줬어요. 그랬더니 GitHub으로 Mac 가상머신을 띄울 수 있게 됐습니다. 두 번째로 한 건, Claude 데스크톱 앱을 Swift로 다시 쓸 빈 코드베이스를 하나 만든 거예요.

보리스: "이 코드베이스에 접근할 수 있어?"라고 물었더니 안 된다고 해서, 접근 권한을 줬더니 "좋아요, 이제 접근돼요" 하더라고요. 그다음 말했습니다. "자, 이제 네가 할 일은 Electron 앱을 Swift로 다시 쓰는 거야. Mac 가상머신에서 Electron 앱을 실행하고, 스크린샷을 찍고, 픽셀 단위로 봐. Swift 버전과 비교해. 끝날 때까지 멈추지 마."

다이애나: 그게 기본적으로 프롬프트의 전부였나요?

보리스: 그게 제 프롬프트였습니다.

다이애나: 이거 돌리는 데 얼마나 걸렸나요?

보리스: 아직 돌고 있어요.

다이애나: 언제 시작하셨는데요?

보리스: 2주 조금 넘었습니다. 그러니까 14일, 15일쯤 됐네요.

다이애나: 네. 여기 청중 중에 Claude에게 2주 넘게 태스크를 돌려본 분이 있을지 모르겠네요. 모르겠어요. 손 들어보세요. 청중 중에 계신가요?

보리스: 이게 바로 유도(elicitation)에 관한 겁니다. 모델이 오늘 이미 할 수 있는데, 그냥 하게 놔두기만 하면 되는 그런 사례 중 하나예요. 화려한 장치도 필요 없습니다. /go도 필요 없고, /loop도 필요 없어요. 이런 게 도움은 됩니다. 하지만 정말 필요한 건 모델에 태스크를 주고, 막히지 않도록 작업 결과를 검증할 방법을 주는 것뿐이에요. 그러면 그냥 갑니다. 그리고 실은 이 경우, Claude가 라이브 블로깅까지 하기로 했어요. 내부에 Slack 채널을 하나 만들더니, 몇 분마다 진행 상황 스크린샷을 그냥 올리기 시작했습니다.

다이애나: 와. 프롬프트가 그렇게 단순하게 들리니, 여기 있는 모두가 할 수 있겠는데요. 그럼 상위 1% Claude Code 유저가 될 수 있는 사람들을 가르는 건 뭘까요? 어떻게 하면 보리스처럼 Claude Code 쓰는 법을 배울 수 있죠?

보리스: 글쎄요, LinkedIn 인플루언서들 말은 안 듣는 게 좋을지도요.

다이애나: 듣지 마세요. Twitter도 읽지 마시고요.

보리스: 이게 모델에 관한 진실인데요. 다들 그걸 해낼 '신박한 꼼수 하나(one weird trick)'를 찾고 있는 것 같아요. 그런 건 없습니다. 그런 비슷한 것도 없어요. 모델이 작동하는 방식은, 경험적으로 접근해야 한다는 겁니다. 너무 어려운 태스크를 줘야 해요. 여러분이 직접 그 일을 한다면 스스로 쓸 법한, 작업을 검증할 도구들을 모델에게 줘야 합니다. 어디서 버벅대는지 보고, 그걸 더 나은 프롬프팅이나 스킬로 고쳐야 해요. 모델에 컨텍스트가 부족하면 MCP를 줘서 필요한 컨텍스트를 끌어올 수 있게 하고요. 그게 사실상 다예요.

다이애나: 아주 간단하게 들리네요.

보리스: 사람들이 좀 과하게 생각하는 경향이 있는 것 같아요. 과하게 엔지니어링하는 경향이 있죠. 여러 면에서, 과거에 시스템을 만들 때는 그렇게 해야만 했으니까요. 그래서 오래 코딩해온 엔지니어들, 몇 년, 몇십 년 해온 분들을 보면 이게 정말, 정말 흔한 실패 모드입니다. 과잉 명세하려 하고, 지나치게 구체적으로 굴고, 자기가 했을 방식 그대로 정확히 모델이 태스크를 하게 만들려는 것. 모델은 그냥 그렇게 작동하지 않아요. 많은 분들이 이걸 언러닝(unlearning)하고 있다고 생각하는데, 떨쳐내는 건 하나의 여정입니다. 이걸 동료 대하듯 대하는 법을 알아내는 것도 하나의 여정이고요. 지금 모델의 지능이 그 수준에 와 있다고 생각합니다.

24:42 · 수천 개의 AI 에이전트 돌리기

다이애나: 그 연장선에서, 2주 전에 시작해서 아직도 돌고 있는 그 태스크 얘기를 더 깊이 해보죠. 에이전트를 몇 개나 스폰했나요?

보리스: 잘 모르겠어요. Claude한테 물어보고 다시 알려드릴게요. 짐작으로는 수천, 수만—

다이애나: 수천이요. 청중 중에 어느 모델에든 에이전트를 천 개 넘게 스폰한 프롬프트를 돌려본 분 계신가요? 없네요. 이것도 팁 중 하나인 것 같아요. 최고의 Claude 유저들은 수천 개의 에이전트처럼, 정말 큰 레버리지를 주는 태스크를 스폰할 줄 아는 거죠.

보리스: 네.

다이애나: 어떻게 하는 건가요?

보리스: 몇 가지 방법이 있어요. 가장 쉬운 건 다이내믹 워크플로우입니다. 다이내믹 워크플로우를 쓰려면 — Claude Code의 꽤 최신 기능인데요 — 그냥 "워크플로우를 써"라고 말하기만 하면 됩니다. 그게 다예요. 그러면 Claude가 다이내믹 워크플로우를 그냥 트리거합니다. 다이내믹 워크플로우가 뭐냐면, 본질적으로 저희한테 Bun 런타임이 있잖아요. Bun을 샌드박스로 쓰고 그 안에 가상머신을 하나 띄웁니다. 그리고 Claude가 많은 에이전트를 띄워서 오케스트레이션하게 해요. 에이전트 하나만 돌리는 게 아닙니다. 병렬 에이전트 10개만 돌리는 것도 아니에요. 예를 들어 태스크가 코드베이스를 다시 쓰는 거라거나, 정말 복잡한 데이터에 대한 정말 심층적인 데이터 분석이라거나, 여러 단계와 어쩌면 수십 개의 풀 리퀘스트가 필요한 아주 복잡한 피처를 만드는 거라면 — 먼저 첫 패스를 할 에이전트 무리를 띄웁니다.

보리스: 그걸 바탕으로, 작업을 검증하거나 요약하는 또 다른 에이전트 셋으로 두 번째 단계를 할 수도 있어요. 그다음 세 번째 단계에서 다시 팬아웃할 수도 있고요. 이렇게 여러 에이전트를 생산적으로 오케스트레이션합니다. 제 배경이 함수형 프로그래밍이라, 저희가 이걸 설계한 방식이 본질적으로 '에이전트를 위한 대수(algebra for agents)'예요. 에이전트를 순차로 돌리는 방법이 있고, 병렬로 돌리는 방법이 있습니다. 그리고 Claude는 샌드박스 안에서 이 에이전트들을 오케스트레이션해서, 토큰을 효율적으로 쓰면서 정말정말 복잡한 작업을 해내는 여러 툴을 갖고 있어요. 꽤 멋진 건데, 아직 많이 다뤄진 적이 없는 얘기죠. 사실 이건 테스트 타임 컴퓨트(test time compute)의 새로운 형태입니다. 스케일링 법칙을 얘기하고 모델이 시간이 갈수록 더 지능적이 되는 걸 얘기할 때, 역사적으로 그건 뉴럴넷의 크기, 학습 데이터의 양, 학습에 투입한 플롭스(flops) 수의 함수였잖아요.

보리스: 그리고 최근에 테스트 타임 컴퓨트가 더해졌죠. 이건 본질적으로 '토큰을 몇 개나 생성하는가'를 연구자들이 있어 보이게 말하는 방식입니다. 그리고 이제 다이내믹 워크플로우는 테스트 타임 컴퓨트를 오케스트레이션하는 본질적으로 새로운 방법이에요. 정말 어려운 태스크에 쓰는 테스트 타임 컴퓨트의 양을 정말, 정말 끌어올리는 새로운 방법입니다. 아주 길게 말했지만, 이게 수천 개의 에이전트를 생산적이고 효율적인 방식으로 띄우는 방법 하나고요. 두 번째 방법은 루프(loop)와 루틴(routine)입니다. 루프는 본질적으로 Claude를 위해 로컬에서 도는 크론 잡이에요. 루틴은 같은 건데 클라우드에서 돕니다. 그래서 노트북을 덮어도 되죠. 이건 약간 다른데, 다이내믹 워크플로우는 태스크 하나를 청크로 쪼개는 거라면, 루프와 루틴은 반복적인 태스크 하나예요. 컨텍스트는 공유하지 않지만, 메모리는 공유할 수 있습니다.

보리스: 그리고 이걸 계속 반복하는 겁니다. 매시간, 5분마다, 매일 할 수 있어요. 저희가 시작한 것 중 하나가, 이제 실제로 Claude가 스스로를 유지보수하게 하는 겁니다. 방식은, Slack 채널을 하나 두고, Claude가 자기 코드베이스를 유지보수하는 여러 루틴을 그냥 띄우게 했어요. CLI, iOS 앱, Android 앱, 데스크톱 앱에 대해 실제로 이렇게 하고 있습니다. 예를 들어 루틴 하나는 데드 코드 청소예요. 이건 싱글 프롬프트인데, 한 문장짜리입니다. Claude가 매일 이걸 돌려요. 정적·동적 분석을 써서 모든 코드베이스에 걸쳐 데드 코드를 찾습니다. 저희가 그렇게 하라고 프롬프트하지도 않았는데, 그냥 알아서 알아냈어요. 그리고 매일 데드 코드를 지우는 풀 리퀘스트를 올립니다.

보리스: 또 다른 예는 나가야 할 실험(experiment) 쉬핑이에요. 실험이 이미 100% 롤아웃된 상태면, 코드베이스에서 지우고 그냥 쉬핑합니다. 또 하나는 테스트 커버리지가 필요한 코드베이스 영역에 테스트를 쓰는 거고요. 또 하나는 없어도 되는 테스트 지우기입니다 — 옛날 모델이 넣었거나 언젠가 사람이 넣은 쓸모없는 테스트들이라서요. 제가 정말 좋아하는 게 하나 있는데 — 이름을 뭐라고 불렀는지 까먹었네요. 추상화 경찰(abstraction police)이라고 불렀던 것 같아요. 아이디어는, 큰 코드베이스에는 같은 추상화가 여러 번 나타나는 경우가 많다는 거예요. 눈을 가늘게 뜨고 보면 사실 그냥 같은 추상화여야 하는데, 시간이 지나면서 어떤 이유로든 코드베이스 곳곳에서 여러 방식으로 다시 만들어진 거죠.

보리스: 그래서 Claude가 매일 저희 모든 코드베이스를 돌면서 이런 거의-중복인 추상화들을 찾아서 통합합니다. 지금은 매일 이런 루틴이 20~30개쯤 모든 코드베이스에 걸쳐 돌고 있어요. 아직 완전히 도달한 건 아니지만, 이렇게 해서 저희 앱 유지보수를 완전히 자동화하는 길 위에 있습니다. 이것도, 다시 말하지만, 매일 수백 개의 에이전트, 어떤 날은 매일 수천 개의 에이전트가 도는 거예요. 수십 명, 수백 명의 엔지니어가 하던 일을 해내고 있는 겁니다 — 예전엔 이런 종류의 일을 하는 데 그만큼이 들었으니까요. 덕분에 엔지니어들은 정말 하고 싶은 일을 그냥 할 수 있게 되죠. 새 제품을 쉬핑하고, 유저와 이야기하고, 실제로 재미있는 일을 하는 것 말이에요.

30:15 · 코딩은 (거의) 풀렸다

다이애나: 여기서 나오는 다음 결론이, 전에 언급하신 건데, 기본적으로 코딩은 풀렸다(coding is solved)는 거잖아요. 그렇게 말씀하신 적이 있죠. 궁금한 게, 이제 사실상 누구나 소프트웨어를 쓸 수 있는데, 뛰어난 빌더를 나머지와 가르는 건 뭘까요? 모두가 코드를 쉬핑할 수 있는 지금, 필요한 자질은 뭔가요?

보리스: 한 가지 단서를 달자면, 코딩이 풀린 건 제가 하는 종류의 코딩에 대해서예요. 모두에게 풀린 건 아닙니다. Claude가 여전히 버벅대는 초심층 시스템 코드베이스들이 있어요. Claude가 여전히 버벅대는 분산 시스템도 있고요. 정말 디테일까지 파고드는 UI 검증 — 뭔가 1픽셀 어긋나 있다든가 하는 것들요. Claude는 이런 데서 아직 완벽하지 않습니다. Opus 5가 비전과 컴퓨터 사용에서 큰 도약이긴 했지만, 아직 완벽하진 않아요. 근데 실은 저도 궁금한데, 여기 계신 분들 중 코드의 100%를 에이전트로 작성하는 분은 손을 들어보실래요? 이제 손으로는 코드를 전혀 안 쓰는 분이요.

보리스: 꽤 많네요. 좋아요. 50% 이상은요? 손이 약간 줄었나, 거의 비슷하네요. 네. 그러니까 가고 있는 겁니다. 점점 더 많은 종류의 코드에 대해 풀린 상태가 되어가고 있고, 멋진 일이죠. Claude를 가장 잘 쓰는 사람들을 생각해보면, 정말 효과적인 특정 마인드셋이 있다고 생각해요. 핵심은 경험적으로 구는 겁니다. 그러니까 과거 모델들에 대해 배운 걸 전부 잊으세요. 수업에서 배운 컴퓨터 과학 이론도 전부 잊으세요. 모델을 보고, 태스크를 시켜보고, 어디서 버벅대는지 보고, 그걸 바탕으로 조정하세요. 그러니까 이건 이제 이론 과학이 아니라 아주 경험적인 과학이 된 겁니다. 이걸 정말 잘하는 사람들, 자기 프라이어(priors·선입견)를 잊는 걸 정말 잘하는 사람들, 예전에 안 됐던 그 아이디어를 놓아주고 다시 시도해보는 데 그냥 열려 있는 사람들—

보리스: 이런 게 지금 정말, 정말 성공적인 종류의 스킬입니다.

32:20 · CS 학생이 여전히 배워야 할 것

다이애나: 이제 마지막 질문인데요. 지금까지 얘기한 걸 전부 감안할 때, 여기에 CS를 공부하는 사람이 있고, AI 에이전트 코딩 시대 이전에 프로그래밍을 배웠다면 — 학생들이 여전히 어려운 방식으로, 옛날 방식으로 배워야 할 건 뭘까요?

보리스: 저는 컴퓨터 과학을 실용적으로 배웠어요. 문제를 풀기 위해 독학으로 코딩을 배우면서요. 코딩을 할 때마다, 늘 제가 가진 특정 문제를 풀기 위해서 했습니다. 사실 처음 코딩을 배운 건 TI-83 계산기에서였어요. 중학교 때 얘기입니다. 결국엔 인터넷에 TI-83 계산기 프로그래밍 가이드까지 쓰게 됐어요. 아직 인터넷 어딘가에 있을 겁니다. BASIC이었어요 — 그게 제 첫 언어였죠. 수학 시험에서 커닝을 해서 성적을 올리려고 계산기 프로그래밍을 배운 겁니다.

보리스: 그러니까 실용적인 무언가에 관한 거였어요. 중학생인 저한테는 그게 생각할 수 있는 가장 실용적인 거였습니다. 결국 좋은 성적을 받았고, 그다음엔 작은 시리얼 케이블을 구해서 프로그램들을 반 친구들한테 나눠줬더니 걔들도 성적이 아주 좋아졌어요. 그러다 수학이 조금 어려워졌습니다. 더는 BASIC으로 풀 수 있는 게 아니게 됐죠. 그래서 BASIC으로 짠 대수(algebra) 솔버에서 출발해서, 더 어려운 문제를 풀어야 했습니다. 미적분에 들어가니까, 이제 시험이 미적분이 된 상황에서 더 잘 커닝하려면 더 나은 솔버를 짜야 해서 어셈블리를 돌려야 했어요. 저한테 프로그래밍은 늘 아주 실용적인 거였습니다. 학교 다니는 분들께 제가 늘 하는 조언이 이거예요. 컴퓨터 과학만 배우지 마세요 — 그것도 지적으로 매혹적이긴 합니다.

보리스: 알아두면 정말 흥미롭기도 하고요. 하지만 그걸 적용하는 법을 배우세요. 흔히 이건 스타트업을 만드는 것에 관한 얘기입니다. 제품을 만드는 것이고요. 자기만의 디자인 감각을 기르고, 비즈니스 감각을 기르고, 데이터 과학 하는 법을 배우고, 유저와 대화하는 법을 배우는 것. 이런 다른 스킬들이 다 있어요. 그리고 그것들을 컴퓨터 과학·엔지니어링과 결합할 때, 바로 거기서 정말 가치 있어집니다. 그게 제가 여전히 손으로 하겠다고 할 하드 스킬들이에요.

다이애나: 제가 제대로 듣고 요약하자면 — 먼저 자신을 위해, 자신이 원하는 걸 만드는 것부터 시작하고, 그다음 레벨업해서 사람들이 원하는 걸 만들어라(make something people want).

보리스: 네.

다이애나: 그리고 마지막으로 특별 발표가 딱 하나 남았죠, 보리스. 마지막 하나요(One last thing).

보리스: 네. 오늘 여기 계신 모든 분들께, Max 20X를 드립니다.

다이애나: 엄청나네요.

보리스: 이메일로 안내(quote)가 갈 테니 확인해보세요. 여러분이 뭘 만들지 정말 기대됩니다.

다이애나: 궁금하네요. 이제 그럴 수 있는 계정이 생겼으니, 이 방의 누군가는 부디 몇 달씩 돌고 에이전트 수천 개를 띄우는 뭔가를 만들고 있어야겠죠. 그럼 이것으로 — 정말 감사합니다, 보리스.

보리스: 감사합니다.