지난달 초 저는 AI Engineer World’s Fair에서 Anthropic Claude Code 팀의 Cat Wu와 Thariq Shihipar와 함께 파이어사이드 챗 세션을 진행했습니다. Claude Code, Claude Tag, Fable, 코딩 에이전트 보안, 평가(evals), 도구 설계, 그리고 Anthropic이 이러한 도구들을 내부에서 어떻게 활용하는지에 대해 이야기를 나눴습니다.

세션 전체 영상은 YouTube에서 시청할 수 있습니다. 아래는 대화 내용을 편집한 기록으로, 참고 링크를 추가하고 제가 중요하다고 생각한 부분은 굵게 표시했습니다.

영상이나 전체 대화록을 볼 시간이 없다면 핵심 요약은 다음과 같습니다:

• Claude Tag(Claude의 새로운 협업형 Slack 연동)는 현재 Claude Code 팀의 제품 엔지니어링 PR 중 65%를 직접 처리(land)하고 있습니다.
• Claude Code는 기능을 먼저 Anthropic 직원들에게 배포하고, 해당 그룹에서 사용자 유지율이 입증된 기능만 외부에 출시합니다
• Claude Code의 핵심 변경 사항은 여전히 사람이 직접 리뷰하지만, 제품의 바깥쪽 레이어에 해당하는 변경은 점점 더 자동화된 코드 리뷰에 의존하고 있습니다.
• Fable 5나 Opus 4.8 같은 모델에서는 시스템 프롬프트에 예시를 추가하는 것이 더 이상 모범 사례가 아닙니다. 최근 Claude Code의 시스템 프롬프트는 크기가 80%나 줄었습니다.
• 마찬가지로 “X 하지 마, Y 하지 마” 식의 금지 목록도 최신 모델의 결과 품질을 떨어뜨릴 수 있습니다.
• Anthropic 내부에서는 도그푸딩을 “앤트 푸딩(ant fooding)”이라고 부릅니다.
• Anthropic은 auto mode를 강하게 신뢰하며, 이를 Claude Tag를 가능하게 하는 핵심 기술로 보고 있습니다.
• Thariq는 코딩 에이전트가 불러오는 Deep Blue 현상을 “더 야심차게 임하는 것”으로 상쇄하라고 조언합니다.
• Fable은 영상 편집에도 능숙하며, Thariq는 직접 Fable의 출시 영상 자체를 Fable로 편집했습니다.
• Anthropic의 (사내) 공개적인 업무 문화는 성공의 핵심이며, 이는 Claude Tag를 공개 Slack 채널에서 활용하는 방식에서도 잘 드러납니다.

지난 1년 동안 일상적인 업무 방식은 어떻게 바뀌었나요?

1:05

Simon: Claude Code는 작년 2월에 출시됐습니다. 아직 나온 지 1년 반도 안 됐고, 처음에는 Claude Sonnet 3.7 출시 소식에 한 줄로 언급된 정도였죠. 실제로 일을 해주는 코딩 에이전트가 생긴 지금, 지난 1년 동안 여러분의 일상 업무는 어떻게 달라졌나요?

Cat: Claude Code와 Sonnet 3.7을 처음 출시했을 때만 해도 작업을 시키고 나면 에이전트가 하는 모든 행동을 일일이 지켜봐야 했습니다. 권한 요청 창을 아주 꼼꼼히 읽었고, “아니오”를 수없이 눌렀죠. “이 파일 확인했어? 저 파일은?” 하고 계속 물었습니다. 그런데 모델이 세대를 거듭할수록 정말 놀라운 변화가 있었습니다. 이제는 반복적이고 사소한 구현 작업을 Claude에 훨씬 더 많이 위임하고 한 발짝 물러설 수 있게 됐습니다. 덕분에 더 창의적인 고민에 시간을 쓸 수 있게 됐죠. 사용자에게 어떤 경험을 제공해야 할지 같은 것들이요. Claude Code가 상당 부분을 구현할 수 있다는 걸 알게 됐으니까요. 그리고 이제 Fable이 나오면서는 또 한 단계 완전히 다른 도약이 있었습니다. 많은 사용 사례에서 이제 Fable로는 원샷으로 수많은 기능을 바로 만들어낼 수 있다는 걸 체감하고 있습니다.

Thariq: Claude Code에 대해 처음 문자를 받았던 때가 기억납니다. 절친 중 한 명이 “Claude Code 꼭 써봐야 해”라고 하더군요. Opus 4가 나왔을 무렵이었는데, 써보고는 “이런, 당장 Anthropic에서 일해야겠다”고 생각했습니다. 그때가 Opus 4였는데도 훌륭한 모델이었지만 권한 요청을 계속 확인해야 했죠. 얼마나 빨리 망각하는지 신기할 정도예요. 이제는 auto mode가 원래부터 있었던 것처럼 느껴져서 “허용” 버튼을 눌렀던 기억조차 잘 안 납니다. 제가 요즘 스스로에게 강조하는 건 우리는 그 어느 때보다 더 높은 품질의 일을 해야 한다는 겁니다. 결과물의 품질이 엄청나게 높아졌거든요. 저는 영상 편집에 자주 활용하고 있는데, 브랜드 팀의 까다로운 기준을 몇 시간 안에 충족해야 하고, 그렇지 않으면 그냥 불가능한 일이죠. Fable과 함께 제가 추구하려는 방향은 우리가 해본 중 최고의 결과물을, 우리가 해본 중 가장 빠른 속도로 만드는 것입니다.

예전에는 당연했던 소프트웨어 엔지니어링 상식 중 이제는 통하지 않는 것은 무엇인가요?

3:39

Simon: 1년 전에는 당연했던 소프트웨어 엔지니어링 상식 중, 이제는 이 새로운 시대에 더 이상 들어맞지 않는다고 생각하는 것이 있다면 무엇인가요?

Cat: 엔지니어의 역량에서 가장 큰 변화 중 하나는 다음과 같습니다. 2년 전만 해도 제품 매니저가 여러 고객을 만나고, 6개월에 걸쳐 유관 부서와 협의해 PRD를 만들고, 첫 코드가 작성되기 전에 구현 방식을 세세하게 정의하는 게 일반적이었습니다. 이제는 완전히 반대가 됐습니다. 현장에 계신 많은 분께 드리고 싶은 조언은 무엇을 만들지에 대한 비즈니스 감각과 제품 감각을 더 키우라는 것입니다. 아이디어를 떠올리고 실제로 구현하기까지 걸리는 시간이 6~12개월에서 어쩌면 일주일 정도로 크게 단축됐기 때문입니다. 이는 우리 모두가 무엇이 만들 가치가 있는지, 무엇이 실제 비즈니스를 성장시킬지를 가려내는 안목을 더 키워야 한다는 뜻입니다. 즉, 제품에 대한 안목과 비즈니스 감각의 가치는 높아졌고, 대부분의 제품 영역에서는 실행 자체의 비중은 다소 낮아졌다고 볼 수 있습니다. 물론 인프라 영역에서는 여전히 모든 세부 사항을 정확히 하는 것이 매우 중요합니다.

Thariq: 제게는 이제 다시 쓰는(rewriting) 게 좋다는 겁니다.

Simon: 예전에는 최악의 선택으로 여겨지던 것이 이제는 오히려 괜찮은 선택이 된 거네요!

Thariq: 맞습니다. “절대 다시 쓰지 마라”는 Mythical Man-Month의 격언 같은 것들, 이제는 저는 다시 쓰기를 찬성합니다. 좋은 테스트 스위트가 있다면 말이죠. 다시 쓰기가 오히려 좋은 테스트 스위트를 갖췄는지 확인하게 만든다고 생각합니다 — 하지만 사람들이 간과하는 것 중 하나는 코드베이스 자체가 명세(spec)이며, 어쩌면 그게 유일한 명세일 수도 있다는 점입니다. 아무도 코드베이스의 모든 분기 로직을 다 알지 못하니까요. 그 결과물을 가져와 정제하거나 다른 버전을 만들 수 있습니다. 저희는 Bun을 Rust로 다시 썼고 지금 제 환경에서 잘 돌아가고 있습니다.

Simon: 아직 Claude Code를 Bun-in-Rust 버전으로 배포하고 있지는 않죠?

Thariq: 내부적으로는 이미 쓰고 있습니다.

(실제로 Anthropic은 6월 17일에 모든 사용자를 대상으로 Bun-in-Rust 기반 Claude Code 배포를 시작한 것으로 보입니다.)

비엔지니어들은 Claude Tag로 어떤 일을 하고 있나요?

6:36

Simon: 최근 또 다른 큰 출시는 Claude Tag였죠. 일반에 공개된 지 이제 일주일 정도 됐습니다. Anthropic 내부에서는 비엔지니어들도 많이 쓰고 있다고 들었습니다. 비엔지니어들은 Claude Tag로 어떤 일을 하고 있나요?

Cat: Claude Tag는 팀 협업 도구에 상주하는 Claude입니다. 지난주 Slack용으로 출시했습니다. Claude Tag가 다른 점은 기본적으로 멀티플레이어라는 것입니다. Slack 채널에 Claude Tag를 추가하면 내가 끼어들 수도 있고, 팀원이 끼어들 수도 있으며, 함께 PR을 두고 협업할 수 있습니다. 또 다른 큰 차이는 반응형이 아니라 능동형(proactive)이라는 점입니다. Claude Tag에게 “이 채널의 모든 버그 리포트를 모니터링하고, 수정 PR을 올린 뒤 이 코드 영역을 마지막으로 건드린 엔지니어를 태그해줘”라고 말해두면, 일일이 호출하지 않아도 채널이 살아있는 동안 계속 그렇게 동작합니다. 그리고 세 번째 큰 변화는 팀 메모리(team memory)를 추가했다는 점입니다. 채널에서 Claude Tag에게 선호 사항을 말해주면, 그 이후의 모든 포스트에 대해 기억합니다. 예를 들어 장애(outage)는 디버깅하되 경고(warning)는 디버깅하지 말라고 자연어로 말해주면, 나와 팀 전체를 위해 그걸 기억해 둡니다.

내부적으로 우리는 Claude Tag를 Claude Code의 진화 형태로 보고 있습니다. 이는 우리가 일하는 방식의 큰 전환입니다. Claude Tag는 현재 우리 제품 엔지니어링 PR의 65%를 처리(land)하고 있습니다.

Simon: Anthropic 전체인가요, 아니면 Claude Code 팀만인가요?

Cat: 저희 제품 엔지니어링 팀 기준입니다. 내부 버전의 Claude Tag가 현재 제품 PR의 65%를 처리하고 있습니다. 이는 50%가 넘는 큰 변화입니다. Claude Code와 Claude Tag 사이의 역할 분담은 이렇게 보고 있습니다. Claude Code는 여전히 에이전트와 대화하며 반복적으로 다듬어야 하는 가장 복잡한 작업에 가장 적합합니다. 반면 Claude Tag는 나를 대신해 능동적으로 일하게 하는 데 탁월합니다. 그래서 내가 작업 중인 기능에서 발생하는 모든 버그 리포트에 대해 일일이 Claude Code를 실행할 필요가 없어졌습니다.

Thariq: 비코딩 사례로는, 예를 들어 이번 대담 전에 Claude Tag에게 “Fable 출시일이 언제지?”라고 물었습니다. 발표 일정에 맞춰야 했거든요. Claude Tag는 Slack을 검색해 누가 무슨 말을 했는지 살펴봅니다. 회사 전체를 위한 검색 엔진으로서 정말 유용합니다. 제품에 대한 모든 맥락을 갖고 있기 때문에 지표 관련 질문을 할 수도 있습니다. 결정을 내릴 때 지표를 참고하고 싶을 때가 많은데, 이벤트 저장소(event store)에 연결해 두면 됩니다. 마케팅 팀이 “이 기능에 대해 알려줘”라고 하는 경우도 봤습니다. 그들은 프로그래머가 아니지만 Claude는 프로그래머니까, 코드베이스를 클론해서 “이게 이 기능이고, 이렇게 생겼으며, 이건 제가 직접 사용해 본 녹화본입니다”라고 보여줄 수 있습니다. 정말 다양한 활용이 가능하고, 아직 초기 단계라고 생각합니다.

팀 협업 레이어로서의 Claude Tag

10:06

Simon: 제가 코딩 에이전트를 쓰면서 겪은 문제 중 하나는 개인으로서는 어떻게 쓰는지 알겠는데, 팀 환경에서는 어떻게 써야 할지 잘 모르겠다는 점이었습니다. Claude Tag가 바로 그 팀 협업 레이어에 대한 답인 것 같네요.

Cat: 맞습니다. 그리고 실제로 지금 세션의 상당수가 멀티플레이어로 진행되고 있습니다. 예를 들어 제가 “Cowork에 이 새 기능을 구현해보자”고 하며 Claude Tag를 태그해 초안을 만들게 할 수 있습니다. 그다음 Claude Tag에게 “최종 구현을 녹화해서 공유해줘”라고 하고 디자이너를 태그해 검토를 부탁합니다. 디자이너가 살짝 손보고, 다시 엔지니어에게 넘겨 마무리한 뒤 프로덕션에 배포하는 식이죠. 정말 유연한 경험이었습니다. 같은 세션을 함께 조율하는 사회적 역학이 어떤 모습이어야 할지는 아직 다듬는 중이지만, 사람들이 다른 사람이 Claude를 쓰는 모습을 보고 그 사회적 규범을 따라가는 방식이 꽤 직관적으로 자리 잡았습니다.

Thariq: 다른 사람들이 함께 Claude를 쓰는 모습을 모두가 볼 수 있다는 점이 사람들을 가르치는 데도 좋고, 쓸데없는 결과물(slop)을 줄이는 데도 좋습니다. 모두가 함께 쓰는 걸 보니까 Claude를 더 잘 쓰게 되거든요.

이 이야기는 Midjourney가 Discord 채널에서 프롬프트를 공개적으로 쓰게 강제함으로써 고급 이미지 프롬프팅을 가르치는 난제를 해결한 방식이 떠올랐습니다.

만드는 비용이 훨씬 저렴해진 지금, 어떤 기능을 만들지 어떻게 결정하나요?

11:41

기능을 만드는 비용이 워낙 낮아진 지금, 어떤 기능이 출시할 가치가 있는지 판단하는 것이 저 자신도 정말 어렵다고 느낍니다.

Simon: 모든 엔지니어링에서 가장 어려운 문제인 우선순위 결정에 대해 이야기해 보죠. 기능을 만드는 비용이 훨씬 저렴해진 지금, 어떤 기능을 만들고 출시할지 어떻게 결정하나요?

Cat: 어렵습니다. 저희는 몇 가지 방식으로 접근합니다. 하나는 매일 제품을 직접 써보는(dogfooding) 것입니다. 제품에서 하고 싶은 일이 있는데 그게 안 되면 다른 해결책을 찾지 않고 제품을 고쳐서 그걸 지원할 수 있게 만듭니다. 내부에 아주 강한 도그푸딩 문화가 있습니다. 제품을 세상에 공개하기 전에 먼저 Anthropic 내부 전 직원, 그리고 아주 솔직한 피드백을 주는 일부 초기 고객에게 공개합니다. 가혹하면 가혹할수록 좋죠. 그리고 사람들이 정말 좋아할 때까지 반복합니다. 저희는 기능이 세상에 나가기 전에 충족해야 하는 활성 사용자 수와 리텐션에 대한 내부 기준을 가지고 있습니다. 이 기준이 명확하기 때문에 모든 엔지니어가 무엇을 달성해야 하는지 압니다. 이게 완성도를 높이는 데도 도움이 된다고 생각합니다. 기능이 매끄럽지 않으면 사람들이 이탈할 테고, 그러면 그 기능은 출시하면 안 되니까요.

내부 사용자 리텐션을 기능 출시 여부 판단 기준으로 삼는 방식은 제게도 매우 합리적으로 들립니다.

예상을 뛰어넘은 기능 사례가 있나요?

12:54

Simon: 예상을 뛰어넘은 기능 사례가 있나요? 출시했는데 참여도가 폭발적이었던, 출시될 것 같지 않았지만 실제 제품으로 자리 잡은 기능 같은 것 말입니다.

Cat: 하나 있습니다. 팀원 중 많은 분이 remote control을 정말 좋아합니다. remote control을 이용하면 모바일 기기나 웹 브라우저의 Claude를 CLI에서 실행 중인 로컬 Claude Code 세션에 연결할 수 있습니다. 저는 이 기능이 필요 없었어요. 로컬 환경을 쓰지 않고 모바일에서 바로 작업을 시작해 클라우드 세션에서 실행하면 되니까요. 제가 하는 코딩 작업이 비교적 간단해서 그런 것 같습니다. 처음에는 “그냥 원격 개발 환경을 설정하면 되지 않을까”라고 생각하며 잘 이해하지 못했습니다. 하지만 실제로 remote control을 출시하고 나니, 많은 분이 매일 밤 노트북을 충전기에 꽂아 두고, 여러 개의 remote control 세션을 열어 둔 뒤, 화면을 잠그고 소파에 앉아 휴대폰으로 Claude Code를 제어한다고 하더군요. 그래서 처음에는 이해하지 못했던 이 흐름을 이제는 적극 지원하고 있습니다.

Claude Code의 프로덕션 코드 한 줄 한 줄을 사람이 리뷰하나요?

14:20

이번 컨퍼런스의 전반적인 주제 중 하나는 리뷰였습니다. 코딩 에이전트가 작성한 코드를 사람들이 얼마나 주의 깊게 검토하는가 하는 문제였죠. Claude Code 팀의 생각이 정말 궁금했습니다!

Simon: 코드 리뷰는 어떻게 진행되나요? Claude Code에 들어가는 프로덕션 코드 한 줄 한 줄을 사람이 리뷰하나요? 그렇지 않다면 품질은 어떻게 유지하나요?

Thariq: 작업에 따라 많이 다릅니다. 중요한 영역에는 코드 오너(code owner)가 있습니다. 시스템 프롬프트가 대표적인 예인데, 반드시 해당 오너의 승인을 받아야 합니다.

Simon: 즉 코드 오너가 그 영역 코드의 품질에 직접 책임을 지는 거군요.

Thariq: 맞습니다.

Cat: 그리고 그 영역을 건드리는 모든 PR은 승인이 필요합니다.

Thariq: 저희는 코드 리뷰 GitHub 봇이 모든 것을 리뷰합니다. 모든 PR에 붙고, 종종 리뷰의 대부분을 담당합니다. 팀에서 본 것 중 하나는 더 복잡한 PR의 경우 PR을 설명하는 아티팩트를 만들기도 한다는 점입니다. 그러면 다른 사람들이 리뷰할 수 있죠. 그리고 검증, CI/CD 등에 많이 투자해서 어떤 문제가 발생하든 테스트가 있도록 합니다. Claude가 Claude Code를 제어하고 테스트할 수 있는 아주 견고한 환경도 갖추고 있습니다. 그래서 코드 리뷰에 다각도로 접근하고 있습니다.

Cat: 전반적으로 우리는 사람이 루프에 있을 필요가 없는 세상으로 가려고 합니다. Claude Code의 핵심과 다른 제품들의 핵심에 대한 가장 중요한 변경 사항에는 항상 코드 오너가 있고, 그들이 모든 변경을 직접 리뷰합니다. 하지만 점점 더 바깥쪽 레이어의 변경에 대해서는 실제로 Claude code review가 전체 리뷰를 담당하게 하고 있습니다. 꽤 무섭게 들릴 수 있지만, 여기까지 오는 데 6개월 이상의 과정이 있었습니다. 코드 리뷰를 신뢰할 수 있게 되기까지는 단계별로 차근차근 밟아야 합니다. 처음에는 모든 것을 사람이 리뷰했고, 점차 “이 파일들을 건드리는 코드 변경에 대해서는 code review가 100% 문제를 잡아내고 있으니 사람이 직접 리뷰할 필요가 없다”고 판단하게 됐습니다. 그리고 장애 리뷰(incident review)를 할 때는 장애를 일으킨 PR을 살펴보면서 “code review를 어떻게 업데이트하면 이걸 잡아낼 수 있을까?”를 고민하고, 해당 PR들을 평가 세트(eval set)에 추가해 향후 code review 변경이 그 지표를 회귀시키지 않도록 합니다. 사람이 코드 리뷰 루프에서 빠지는 것은 큰 진전입니다. 무섭게 들릴 수 있고 하룻밤 사이에 할 수 있는 일은 아니지만, code review가 내가 중요하게 생각하는 모든 것을 잡아내고 있다는 확신을 줄 수 있는 인프라에 수개월을 투자하면 가능한 일입니다.

핵심은 자동화된 리뷰 시스템 자체를 끊임없이 개선하며 신뢰를 쌓아가는 것인 듯합니다.

새 모델이 등장하면 그 모델이 무엇을 할 수 있고 없는지에 대한 직관은 어떻게 달라지나요?

17:20

평가(evals)에 대해 깊이 이야기를 나눴습니다. 컨퍼런스 내내 뜨거운 주제이기도 했습니다.

Simon: Opus 4.8에 JSON 엔드포인트를 만들어 SQL 쿼리를 실행하고 JSON을 출력하라고 하면 그냥 잘 해낼 거라는 걸 압니다. 그런 건 꼼꼼히 리뷰할 필요가 없죠. 그런데 새 모델이 나오면 Fable이 Opus가 실수하지 않던 부분에서 실수하지 않을지 빠르게 신뢰를 쌓는 방법을 모르겠습니다. 새 모델은 여러분이 무엇을 할 수 있고 없는지에 대한 직관에 어떤 영향을 미치나요?

Cat: 시간이 지남에 따라 평가 기반(eval base)을 쌓는 가장 큰 이유는 새 모델을 드롭인 교체(drop-in replacement)할 수 있게 하기 위해서입니다. 새 모델이 나오면 전체 평가 세트를 돌려서, 예를 들어 Fable이 Opus 4.8보다 엄격히 더 낫다는 것을 확인하고, 그 확신을 가지고 교체합니다.

Simon: 그 모델 평가는 Anthropic 전체 공용인가요, 아니면 Claude Code 팀 전용인가요?

Cat: 둘 다 있습니다. 팀 차원의 평가도 있고, Anthropic 내 모든 저장소에 대해 code review를 실행하므로 그에 대한 평가도 있습니다. 그리고 auto mode 같은 기능은 Anthropic 내부 모든 사용자에 대한 평가는 물론, 여러 외부 테스터에게 의뢰해 프롬프트 인젝션이나 악성 입력이 있는 환경을 만들고 auto mode가 그 어떤 것도 통과시키지 않는지 레드팀 테스트도 진행했습니다.

시스템 프롬프트를 수정했을 때 결과가 더 좋아졌다는 확신은 어떻게 얻나요?

18:41

Simon: 시스템 프롬프트를 개선했을 때 실제로 제품이 좋아졌는지 알고 싶습니다. 가장 기본적인 제품 특화 평가인데, 아직 어떻게 해야 할지 감이 잘 안 옵니다. 시스템 프롬프트에 대한 수정이 더 나은 결과로 이어졌다는 확신을 가질 수 있을 만큼 그런 평가를 하고 계신가요?

Cat: 완벽한 확신까지는 아니지만, 성능이 회귀하지 않도록 많은 노력을 하고 있습니다. 출발점은 우리가 신뢰하는 외부 평가 스위트이고, 여기에 더 큰 내부 평가 스위트를 보완해 둡니다. 일단 저희는 주로 역량(capability)에 최적화합니다: 작업에 대한 완전한 정의와 전체 코드베이스가 주어졌을 때 Claude가 올바른 결정을 내리고, 버그를 완전히 수정하며, 모든 테스트를 통과하는지 보는 것이죠. 그게 출발점이자 가장 직접적으로 사용자가 원하는 것이기 때문에 최적화 대상입니다. 하지만 Claude Code와 함께 일할 때 사용자가 느끼는 감정에 영향을 주는 행동들도 많습니다. 예를 들어, 사람들은 Claude Code가 “이제 잘 시간이다”라고 말하는 걸 정말 싫어합니다. 또는 “5개 중 2개를 끝냈는데 계속할까요?”라고 묻는 것도 싫어하죠. 당연히 계속해야죠. 그래서 우리는 이런 것들을 잡아내기 위한 행동 평가(behavioral evals) 세트를 구축하고 있습니다. 그리고 사용자 피드백이 들어오면 — 여러분의 피드백을 크게 들려주시면 좋겠습니다 — 우선순위가 높은 이슈부터 하나씩 평가를 만들어 나가고 있습니다. 100% 커버리지는 아니지만, 커버리지를 높이는 것이 저희의 우선순위입니다.

Claude Code 팀과 모델 학습 팀 사이에는 얼마나 많은 교류가 있나요?

20:21

Simon: Claude Code 팀과 Anthropic에서 실제로 모델을 학습시키는 팀 사이에는 얼마나 많은 교류가 있나요? 꽤 긴밀하게 협업하나요?

Cat: Anthropic 전반에서 모두 꽤 긴밀하게 함께 일합니다. 다음 세대 모델이 무엇을 할 수 있을지에 대해 자주 만나 이야기합니다. 저희 연구팀은 이를 공개적으로 보여주는 데도 훌륭했습니다. 블로그 포스트에서 점점 더 긴 호흡(longer-horizon)의 작업을 목표로 하고 Claude 자체를 정직하고, 해롭지 않으며, 도움이 되도록 훈련시키는 방법에 대해 자주 이야기합니다. 여러분의 의도가 모호하게 표현되더라도 그 의도에 부합하도록 맞추는 데도 많은 노력을 기울입니다. 물론 Claude에게 모든 맥락을 주기 위해 최대한 구체적으로 말해주는 것이 좋지만, 구체적이지 않더라도 Claude가 좋은 가정을 하도록 가르칩니다. 생산적인 협업이었습니다.

시스템 프롬프트가 80%나 줄었다는데, 어떤 것들을 빼낼 수 있었나요?

21:24

이 섹션에는 정말 유용한 프롬프팅 팁이 많이 담겨 있습니다!

Simon: Thariq, 오늘 아침에 Claude Code의 시스템 프롬프트가 Claude Fable 덕분에 80%나 줄었다고 언급하셨죠. 좀 더 자세히 설명해 주실 수 있을까요? 어떤 종류의 것들을 빼낼 수 있었나요?

Thariq: Fable 때문만은 아니었습니다. Opus 4.8도 그랬고, 앞으로 나올 모델들도 마찬가지입니다. 이제 모델마다 다른 시스템 프롬프트를 쓰고 있습니다. 저희가 본 패턴 중 하나는 Claude를 과도하게 제약하고 있었다는 점입니다. 초기, 아마 Opus 4 정도까지의 모델들은 예시를 많이 원했는데, 예시를 제거하는 것이 매우 도움이 됐습니다. 저희가 준 예시보다 Claude가 훨씬 더 창의적이었거든요.

Simon: 정말 흥미롭네요. 제가 사람들에게 주는 최고의 프롬프팅 팁 중 하나가 예시를 주라는 것이었는데, 그게 더 이상 통하지 않는다면 제 프롬프팅 모델이 좀 깨지는 느낌이네요.

Thariq: 저도 놀랐습니다. 이제는 Claude에게 주는 것의 형태가 더 중요하다고 생각합니다. Claude에게 주는 도구, 시스템 프롬프트 같은 것들이요. 또 다른 변화는 더 많은 맥락을 주고 “이렇게 하지 마” 식의 지시를 줄인 것입니다. Claude에게는 그런 지시가 매우 강하게 작용하고, 특히 나중에 사용자의 지시와 충돌하면 Claude를 극도로 혼란스럽게 할 수 있기 때문입니다. “스킬에서는 이렇게 하라는데 시스템 프롬프트에서는 저렇게 하라네” 같은 상황이 생기죠. 그래서 단단한 제약을 줄이고, 맥락을 더 많이 주며, 전반적으로 지시 자체를 줄이려고 합니다. 확실히 과학적인 과정이었습니다. 많은 평가를 통해 만들었죠.

Cat: 일반적으로 이런 모델에 프롬프트를 줄 때는 항상 “내가 주는 이 지시에 엣지 케이스가 있을까?”를 생각해야 합니다. Claude Code 시스템 프롬프트의 모든 지시를 다시 검토했을 때, “이 문장은 90%는 맞지만 10%에서는 맞지 않는 경우가 분명히 있다”는 사례들을 몇 가지 발견했습니다. 모델을 제약하거나, 항상 그렇게 해야 한다고 혼란스럽게 만들고 싶지 않았습니다. 좋은 예가 검증(verification)입니다. 모두 Claude가 작업을 검증하길 원하고, 저희도 프롬프트에 프론트엔드 변경을 하면 항상 검증하라는 지시를 넣어뒀었습니다. 하지만 거기에는 한계가 있습니다. 사용자가 “그냥 빨리 수정하고 테스트만 업데이트해줘”라고 하면서 문자열 하나를 다른 문자열로 바꾸는 경우라면 굳이 검증하지 않아도 될 수도 있습니다. 그래서 저희는 “항상 검증하라, 검증하라, 검증하라”는 식의 표현을 “프론트엔드 작업을 할 때 대부분 백엔드 엔드포인트를 호출하는 것만으로는 경험을 완전히 이해할 수 없으니, 사용자 경험에 더 큰 변경을 할 때는 앱을 로컬에서 실행해 달라”는 정도로 조정했습니다. 사실 그 지시도 완벽하지 않을 수 있습니다. “큰 변경”이 무엇인지 모호하니까요. 어쩌면 작은 변경도 테스트해야 할 수도 있죠. 일반적으로 모델에 프롬프트를 줄 때는 선의의 사람이 오해할 수 있는 방식을 생각해보면, 모델이 어떻게 해석할지 더 잘 이해할 수 있고, 그래서 프롬프트를 실제로 100% 정확하도록 부드럽게 다듬을 수 있습니다. 이 프롬프트는 모델에게 100% 항상 주어지니까요.

Simon: 흥미로운 점은 여러분이 모델의 판단을 신뢰하고 있다는 것입니다. 그건 Opus나 Fable급에서나 가능한 일이죠. 1년 전 모델들은 변경을 테스트할지 말지를 판단할 만한 판단력이 없었습니다. 하지만 저렴한 작업을 위해 더 저렴한 모델을 쓰려고 하면서 넓은 범위의 모델을 지원해야 한다면 이 방식은 무너지지 않나요?

Cat: 바로 그 이유 때문에 이제 모델마다 다른 시스템 프롬프트를 쓰고 있습니다. 토큰이 80% 감소한 건 가장 프론티어 모델에만 해당하고, 구형 모델들은 여전히 전체 시스템 프롬프트를 쓰고 있습니다.

Simon: Fable이나 Opus가 Haiku에 더 자세한 프롬프트를 쓰도록 할 수 있을 만큼 똑똑하다고 생각하시나요? Haiku는 판단력이나 안목이 덜하다는 걸 이해하고 있으니까요?

Cat: 아직 평가해보지 못했습니다. 명확한 데이터는 없습니다.

Thariq: 작은 모델에는 어려운 점이 있습니다. 때로는 어려운 문제에서는 큰 모델이 작은 모델보다 토큰 효율이 더 좋을 때도 있거든요. 그래서 직관을 길러야 하는 부분이 있습니다. 때로는 거의 항상 프론티어급 지능이 필요할 때도 있습니다. 파레토 곡선이 이동하고, 그 지점을 찾기가 어렵습니다.

Simon: 1년 전만 해도 모델이 프롬프트를 쓰도록 신뢰하지 않았습니다. 지금은 좋은 모델들이 프롬프팅을 정말 잘합니다. 제 프롬프트 중 상당수는 모델이 쓴 것인데, absurd하게 느껴지지만 정말 잘 작동합니다. 제가 그걸 받아들이게 된 계기는 서브에이전트(subagent)였습니다. 서브에이전트는 결국 Claude 모델이 다른 Claude 모델을 위한 프롬프트를 설정하는 것이니까요.

Thariq: 워크플로우(Workflows)가 실제로 좋은 예입니다. 단일 서브에이전트에 프롬프트를 주는 것을 넘어 여러 서브에이전트의 오케스트레이션을 프롬프트하는 것이기 때문입니다. 각각이 매우 자세한 프롬프트를 받죠. 단순히 서브에이전트를 생성하는 것보다 한 단계 위라고 할 수 있습니다. 저는 개인 머신에서도 Gemini API를 건네주며 “여기서 이미지를 생성해봐”라고 시켜봅니다. 이미지 모델에 프롬프트를 넣는 데 있어 Claude가 저보다 훨씬 덜 게으르거든요. 그냥 Claude가 Claude에게 프롬프트를 주는 게 계속 이어지는 셈입니다.

Cat: 워크플로우 도구 자체의 프롬프트도 Claude가 썼다고 생각합니다.

Simon: 그 프롬프트를 읽어봤습니다. 좋은 프롬프트더군요. 사실 Anthropic에 대해 아쉬운 점 중 하나가 있습니다. Claude Chat용 프롬프트는 공개하면서, 도구 프롬프트나 Claude Code 프롬프트는 공개하지 않는다는 점입니다. 저는 아직도 프록시를 실행해 가로채서 봐야 합니다. Claude Code 프롬프트가 의도적으로 공개되면 좋겠습니다. 그게 바로 문서니까요. 도구가 무엇을 할 수 있고 어떻게 동작하는지 알 수 있는 방법입니다.

Cat: 그 기능 요청은 메모해 두겠습니다. Claude Tag에게 시켜야겠네요.

OpenAI의 GPT-5.6용 프롬프팅 모범 사례에도 최신 모델에 대해 유사한 조언이 포함되어 있다는 점이 흥미롭습니다:

더 간결한 프롬프트를 선호하라

반복되는 지시와 예시를 제거하고 도구 설명을 단순화하면 작업 성능과 토큰 효율을 개선할 수 있다. 내부 코딩 에이전트 평가 실행 샘플에서, 더 간결한 시스템 프롬프트를 적용한 구성은 총 토큰을 41~66%, 비용을 33~67% 줄이면서 평가 점수를 약 10~15% 향상시켰다.

새로운 도구를 도입하는 기준은 무엇인가요?

28:06

Simon: Claude Code는 본질적으로 도구의 집합입니다. 새로운 도구를 도입하는 기준은 무엇인가요? 그 수준에서 추가 엔지니어링을 할 가치가 있다고 판단하는 기준이 궁금합니다.

Cat: 말씀해 주실래요? 최고의 도구 중 하나를 도입하셨잖아요.

Thariq: 제 커리어는 ask user question 도구를 도입했을 때 정점을 찍었습니다. 정말 어렵습니다. 특히 ask user question처럼 Claude가 사용자에게 질문하는 도구 같은 경우는 평가하기도 어렵고, 때로는 사용자 선호도의 문제이기도 합니다. 그때는 평가가 지금보다 적었기 때문에 도그푸딩, 그러니까 저희 식으로 “앤트 푸딩”에 많이 의존했습니다. 하지만 전반적으로 저희는 더 적은 도구를 지향하려고 노력해 왔습니다. 마지막으로 도입한 도구 세트는 아마 task 도구였던 것 같습니다. Claude에게 일을 시키기 위해 더 범용적인 버전을 주려고 노력하고 있습니다.

파일 편집 도구의 최신 진화는 어떤 모습인가요?

29:03

저는 파일 편집 도구에 오랫동안 매료되어 왔습니다. 예전 Aider 코드 편집 리더보드의 주제이기도 했고, 서로 다른 코딩 에이전트에서 검색-치환 기반에서 줄 번호 기반으로, 더 복잡한 패턴으로 진화하는 과정을 흥미롭게 지켜봤습니다.

Claude API 문서에는 텍스트 편집 도구가 API를 이용해 개발할 때 권장되는 방식으로 설명되어 있지만, Claude Code는 여기서 약간 다른 접근 방식을 쓰는 것으로 보입니다.

Simon: 가장 흥미로운 도구 중 하나는 파일 편집 도구입니다. 파일 편집을 도구로 제공할 수도 있고, sed와 grep을 쓰도록 시킬 수도 있죠. 파일 편집 도구의 최신 진화는 어떤 모습인가요?

Thariq: 아직 하나 가지고 있지만, 예를 들어 grep이나 기타 검색 도구, glob 도구들은 제거하고 네이티브 bash를 쓰는 쪽으로 바꿨습니다. 앞서 강연에서도 말씀드렸지만 모델은 물리학이라기보다 생물학에 가깝고, 특히 도구 설계는 매우 어렵습니다. Cat은 평가의 과학이라고 생각해서 제 의견에 동의하지 않을 수도 있지만, 저는 도구 설계가 예술에 가깝다고, 어쩌면 생물학이라고 생각합니다.

Cat: 대체로 동의합니다. 하지만 일반적으로 도구를 추가할 때는 전체 개수를 적게 유지하고, 각 도구가 다른 도구와 명확히 구분되는 기능을 갖도록 해서 Claude가 각 도구를 언제 호출해야 할지 아주 쉽게 구분할 수 있게 하려고 합니다. 파일 편집(file edit) 도구를 유지하는 이유는 렌더링할 수 있기 때문입니다. Claude가 파일 변경을 할 때 사람들에게 보여주고, “이 파일에 대한 이 편집을 승인하시겠습니까?”라는 멋진 전용 UI를 표시합니다. 전용 파일 편집 도구를 두었던 이유는 Claude가 파일 변경을 하고 있다는 걸 결정적으로 알 수 있게 하기 위해서였습니다. 그래야 사람들에게 이 예쁜 UI를 보여줄 수 있으니까요. 새로 온보딩하는 많은 사용자가 여전히 이 경험을 정말 좋아해서 유지하고 있습니다. 하지만 지금 auto mode를 쓰고 있는 저희 같은 사용자들 — 부디 YOLO 모드는 아니길 바랍니다 — 에게는 사실 큰 상관이 없고, 파일 편집 도구를 그냥 제거해도 완전히 괜찮을 것 같습니다.

Anthropic 내부에서 Claude Code를 안전하게 실행하라는 조언은 무엇인가요?

30:58

바로 프롬프트 인젝션 질문입니다! Claude Code 인스턴스가 프롬프트 인젝션 공격으로 인해 제멋대로 동작할 위험을 Anthropic 직원만큼 잘 설명해 줄 사람이 있을까요?

놀랍게도 그들은 auto mode를 정말 신뢰하고 있었고, 이를 Claude Tag를 가능하게 한 기능으로 보고 있었습니다.

Simon: 안전과 보안에 대해 이야기해 보죠. 저는 프롬프트 인젝션의 위험을 깊이 인식하고 있고, 다른 사람이 제 Claude Code에게 지시를 내리면 정말 안 좋은 일들이 많이 생길 수 있다는 것도 알고 있습니다. 그래도 저는 여전히 대부분 YOLO 모드로 Claude Code를 실행하고, 그에 대해 엄청난 죄책감을 느낍니다. Anthropic 내부에서 Claude Code를 안전하게 실행하라는 조언은 무엇인가요?

Cat: 왜 auto mode를 쓰지 않으시나요?

Simon: 이제 auto mode를 쓰기 시작했지만, 얼마나 안전한지 잘 이해하지 못해서 그렇습니다. 아마 3주 전부터 auto mode를 기본값으로 쓰고 있습니다.

Cat: Anthropic 내부에서는 거의 모든 사람이 auto mode를 씁니다. Claude Code에서 오랫동안 안전하게 작업하는 가장 좋은 방법입니다. 저희는 광범위한 배싱(bashing)을 했습니다. 수천 개의 평가가 있고, 많은 레드팀을 고용해 Claude Code가 나쁜 행동을 하도록 속이는 적대적 환경을 만들게 한 뒤, 그들이 찾아낸 모든 문제를 완화했습니다. 앞으로 몇 주 안에 평가 결과를 공개할 예정이지만, 거의 모든 공격을 완화했습니다.

Simon: 정말 대담한 주장이네요.

Cat: 평가 결과를 공유해서 여러분이 판단할 수 있게 할 예정이지만, Claude가 실수할 수 있는 모든 방법을 파악하고 auto mode를 업데이트해 대응하는 데 극도로 diligently하게 임했습니다. 100%를 잡아낸다는 건 너무 강한 주장이라 그렇게 말하지는 않겠습니다. 하지만 저희가 우려하는 주요 위험 범주, 이를테면 프롬프트 인젝션이나 데이터 유출에 대해서는 일반 사람의 리뷰보다 위험이 훨씬 낮습니다.

그들의 평가와 auto mode 검증 접근 방식에 대해 더 많이 배우게 되길 매우 기대하고 있습니다.

Thariq: auto mode가 어떻게 동작하는지 조금 설명드리면 이해에 도움이 될 것 같습니다. Claude가 턴을 진행하거나 bash 호출을 할 때마다, Sonnet 분류기(classifier)가 도구 호출과 대화 맥락, 즉 여러분의 지시를 판단합니다. 권한과 관련해 요청에 따라 달라지는 것들이 있습니다. 항상 git push 권한을 줄 필요는 없지만, “이걸 GitHub에 푸시해줘”라고 하면 그렇게 하길 원하고, “푸시하지 마”라고 하면 거부하길 원하죠. auto mode는 그렇게 동작합니다. 그런 일이 제게도 자주 일어나는데, Claude가 매우 도움이 되고 능동적이어서 뭔가를 하려고 할 때 auto mode가 “하지 마”라는 지시를 보고 이를 드러내 줍니다. 그래서 여러분이 프롬프트 안에서 직접 준 동적 권한(dynamic permissions)을 잘 처리합니다. 정말 중요하다고 생각합니다. 또한 샌드박싱 인프라와도 잘 연동되는데, 샌드박싱은 결정적으로 처리하기 어려운 엣지 케이스가 워낙 많기 때문입니다. 저희는 샌드박스를 가지고 있고, 무언가가 샌드박스를 벗어나야 할 때, 예를 들어 네트워크 요청 같은 경우에 auto mode가 그 요청을 보고 “이게 말이 되는가?”를 판단해 허용할 수 있습니다.

Simon: auto mode가 네트워킹 샌드박스와도 연동되는 줄은 몰랐네요.

Cat: 사용자가 otherwise 보게 될 모든 권한 프롬프트와 연동됩니다.

Simon: auto mode는 얼마나 됐나요? 제가 접근할 수 있는 기능으로서는 아마 나온 지 두 달 정도 됐죠?

(3월 24일에 일반에 처음 공개되었습니다.)

Cat: Anthropic 내부에서는 1월부터 써왔습니다. 그래서 꽤 오랫동안 단단하게 다져왔습니다. Anthropic은 안전과 보안에 극도로 집중하고 있고, 내부적으로 rollout을 가능하게 하고, 이러한 평가들을 구축하며, 세상에 공개하기 전에 auto mode를 더욱 견고하게 만들기 위해 alignment 및 세이프가드 팀과 폭넓게 협력해 왔습니다.

Thariq: 이것이 바로 Claude Tag가 그토록 좋은 이유이기도 합니다. Claude Tag는 auto mode를 사용합니다. Slackbot을 직접 만들지 살지(build-versus-buy)에 대한 질문을 많이 들었는데, 저는 아마 직접 AI Slackbot을 만들지 않는 게 좋다고 말씀드리고 싶습니다. 공격 벡터가 너무나 많습니다. 사용자가 피드백을 남길 수 있는 피드백 채널이 있고, 이제 봇이 그걸 읽고 있습니다. 저희가 auto mode에 들인 노력, 그리고 일반적인 스위스 치즈 방어(Swiss cheese defense)도 있고, 이에 대해 RL도 하고 있습니다. 이게 바로 Claude Tag를 작동하게 하는 핵심이라고 생각합니다. 여러분의 권한과 매끄럽게 연동되고, Slack에서 프롬프트 인젝션을 당하고 싶지는 않을 테니까요.

auto mode를 넘어서는 더 많은 보안 장치가 계획되어 있나요?

35:54

Simon: auto mode를 넘어서는 더 많은 보안 관련 계획이 있나요?

Thariq: 저희는 매우 안전하다고 생각합니다. Claude Tag에서는 Claude를 위해 직접 자격 증명을 프로비저닝할 수 있어서 Claude가 여러분을 대신해 행동할 필요가 없습니다. Claude를 하나의 정체성(identity)으로 둘 수 있고, 그러면 Claude가 하는 일을 감사하고 검사하기도 더 쉬워집니다.

Simon: Claude Tag는 말을 걸 수 있는 누구나 영향을 줄 수 있기 때문에, 지시를 내리는 사람의 범위가 훨씬 넓어졌기 때문이군요.

Thariq: 맞습니다. 그리고 물론 Fable과 함께 프로브(probe)도 있습니다. 이는 저희 안전 및 연구 작업의 하류 효과이기도 합니다. 지금이 바로 Anthropic이 AI 안전 회사로서의 가치가 제대로 발휘되는 순간이라고 생각합니다. Claude가 오랜 기간 동안 정렬된 방식으로 실행될 수 있기를 정말 원하고, 그러려면 auto mode가 사실상 완벽해야 합니다 — 이 모든 것이 저희가 AI 안전 회사라는 점에서 비롯된 것입니다.

Cat: 원격 제어를 더 안전하게 쓰고 싶어 하는 분들을 위해 신뢰할 수 있는 기기(trusted devices) 기능도 출시했습니다. 그리고 모든 원격 환경에 대해서는 자격 증명 주입(credential injection)을 지원합니다. Claude Code가 Datadog에 접근할 수 있게 하고 싶지만 Claude Code 자체가 Datadog 자격 증명을 보유하게 하고 싶지 않다면, 에이전트는 접근할 수 없지만 에이전트가 Datadog 요청을 시도할 때 저희가 즉석에서 삽입해 주는 방식으로 신원 및 자격 증명 관리 시스템을 설정할 수 있습니다.

Claude Code가 프록시를 통해 API에 접근하고, 그 프록시가 요청을 감사하면서 관련 API 키를 주입해 주는 — 그래서 Claude는 API 자격 증명 자체에 접근하지 않고도 인증된 엔드포인트에 접근할 수 있는 — 이 자격 증명 주입 패턴이 저는 정말 마음에 듭니다.

지난 1년 반이 여러분 자신의 기술(craft)에 대한 생각에 어떤 변화를 주었나요?

37:53

Thariq는 오전 기조연설에서 Fable급 모델이 가져온 일종의 슬픔(grief)에 대해 이야기했고, 저희는 그에 대해 더 깊이 대화를 나눴습니다. 저는 이를 Deep Blue라고 부르고 있습니다.

Simon: 인간적인 요소에 대해 조금 이야기해 보죠. 많은 분이 자신이 소프트웨어를 만드는 데 있어 맡고 있던 역할의 상당 부분이 모델에 의해 대체되면서 상실감을 느끼고 있습니다. 어떻게 생각하시나요? 지난 1년 반이 여러분 자신의 기술과 여러분이 더하는 가치에 대한 생각에 어떤 변화를 주었나요?

Thariq: Cat과 Boris는 우리가 더 야심차야 한다는 걸 끊임없이 일깨워주는 존재입니다. 그들은 항상 “우리는 너무 빠르게 성장하고 있고, 최전선에 있어야 하며, 할 수 있는 최고의 일을 해야 한다”고 말합니다. 그건 제게 끊임없는 리마인더입니다. 뭔가 느리다고 느껴질 때마다 “더 빨리 할 수 있을까? 더 야심차게 할 수 있을까?”라고 생각하게 되죠. 그리고 종종 그 답은 Claude입니다. Claude는 계속 좋아지고 있으니까요. 지난번에 시도했을 때는 이전 모델이었으니까요. 상실감에 대해서는, 그건 실제라고 생각합니다. LLM 이전에 하던 일만 그대로 하려 하는데 이제 그게 하나의 프롬프트로 가능해졌다면, 꽤 슬픈 느낌이 들 수 있습니다. 그리고 그것을 상쇄하는 방법은 더 야심차게 되는 것입니다. Jared가 좋은 예라고 생각합니다. 그는 오클랜드 아파트에서 약 1년 동안 Zig 코드를 손수 작성하며 거의 집을 떠나지 않고 정말 즐겁게 작업했습니다. 이제 그가 Bun 전체를 Rust로 다시 쓰는 걸 보는데, 정말 즐겁게 하고 있습니다 — 훨씬 더 야심차고, 그렇게 상쇄하는 거죠. 일반적으로는 “어떻게 더 큰 일을 할 수 있을까”라고 묻고 더 많이 하는 것, 성공은 재미있다고 생각합니다. 야망을 바꾸는 것입니다.

“그것을 상쇄하는 방법은 더 야심차게 되는 것이다”라는 말은 저 스스로도 이 문제에 대해 도달한 결론을 깔끔하게 포착합니다.

Simon: Cat, 제품 관리 관점에서는 어떤가요?

Cat: 제품 역할은 매달 계속 바뀐다고 느낍니다. 저희 팀의 모든 PM은 엔지니어, 디자이너, PM이 섞인 형태입니다 — 대부분 원래 풀타임 엔지니어였습니다. 저희에게 그것은 어디에 공백이 있든 메우는 것을 의미합니다. 아이디어가 있는데 어떤 엔지니어에게도 영감을 주지 못했다면, 그냥 우리가 직접 만들어 노트북에 넣고 사람들이 프로덕션으로 가져가도록 영감을 주면 됩니다. 디자인이 좀 어색해 보이면, 비슷한 페이지를 가져와 1차 디자인을 하고 디테일에 강한 사람에게 태그해 빈틈을 채우도록 합니다. 또는 팀과 제품 채택이 회사 내에서 커지고 더 많은 사람들이 Claude Code, Claude Tag, Cowork에 대해 앞으로 나올 것들을 알아야 한다면, 전체 출시 캘린더 파악을 자동화하고, 사람들을 귀찮게 하지 않으면서 비동기로 상태 업데이트를 받는 걸 자동화하며, 내부 공지 채널의 업데이트가 완전히 상세하고 요점에 맞도록 합니다. 저희에게는 훌륭한 아이디어와 그것을 고객에게 전달하는 것 사이에 현재 어떤 간극이 있는지, 그리고 그것을 어떻게 최대한 자동화할 수 있는지를 이해하는 것이 핵심입니다.

제가 느낀 점도 반영합니다. 코드를 훨씬 더 빠르게 만들 수 있게 되면, 다른 사람의 결정을 기다리며 막혀 있는 시간이 훨씬 더 두드러진 병목이 됩니다. 제품 결정을 내릴 수 있는 엔지니어는 훨씬 더 빠르게 움직일 수 있고, 그런 결정 중 하나를 잘못 내리는 비용도 훨씬 덜 부담스럽습니다.

Claude가 여러분을 놀라게 한 순간은 언제인가요?

41:50

Simon: Claude가 여러분을 놀라게 한 순간은 언제인가요? 모델이 할 수 없을 거라고 생각했는데 해낸 일이 있다면요?

Thariq: Claude의 영상 편집에 대해 많이 게시했지만, 가장 최근에는 ACM Agentic 컨퍼런스에서 발표를 하고 나서 “편집된 영상 있나요? 커뮤니케이션 팀과 공유하고 싶다”고 물었습니다. “작업에 시간이 오래 걸린다”고 하더군요. 그래서 원본 파일을 달라고 했습니다. 무대에서 제가 말하는 영상, 덱(deck) 영상, 그리고 오디오 파일을 보내주며 “행운을 빈다”고 하더군요. 저는 이걸 Claude에게 제 HTML 덱과 함께 건네며 “이걸 그냥 편집해 줄 수 있을까?”라고 했습니다. 그리고 Claude가 한 일은 정말 믿을 수 없을 정도로 훌륭했습니다. 바로 배포할 수 있을 정도였죠. 전체 영상을 전사(transcribe)합니다. 덱 영상이 가끔 이상하다는 걸 알아채기도 합니다. 중간에 자동 업데이트 팝업이 떠 있거든요. 그러면 “아, 덱 영상을 쓰지 말고, 잘라서 내가 어느 슬라이드에 있는지 파악한 뒤 HTML 소스를 대신 쓰겠다”고 합니다. 그래서 HTML 소스를 표시합니다. 그리고 무대 영상이 있는데, 제가 무대의 작은 부분만 차지하고 있으니 제가 있는 위치에 맞춰 동적으로 크롭(cropping)합니다 — 저는 왔다 갔다 하고 있으니 제가 움직이는 대로 추적하죠. 그리고 제가 말하는 내용을 전사합니다.

Simon: 이건 Fable이었죠?

Thariq: 네, Fable이었습니다. 좋은 프롬프트였지만 원샷 프롬프트였습니다. 그다음 흥미로운 애니메이션과 그래픽을 추가해 달라고 했는데, 정말 놀랐습니다. ffmpeg도 하고, Remotion도 합니다.

여기에 Thariq가 Fable로 Fable 자체의 출시 영상을 편집한 방법에 대한 영상이 있으며, 여기에 그 출시 영상이 있습니다.

아직 하지 못하는 것은 무엇인가요?

43:36

Fable 5나 GPT-5.6 같은 프론티어 모델이 해내지 못하는 작업을 찾는 것이 꽤 어렵다는 걸 인정하지 않을 수 없습니다.

Cat은 여전히 UX 디자인 역량을 높게 평가하지 않습니다:

Simon: 하지 못하는 것은 무엇인가요? 여전히 아쉽다고 느끼는 부분, Claude Fable 6이 해결해주길 기다리는 것이 있다면 무엇인가요?

Cat: 디자인과 UX 감각이 더 좋아졌으면 합니다. 이제는 원하는 기능의 동작 방식을 상세한 스펙으로 프롬프트에 적어내면 대부분 그대로 동작하게 만들 수 있는 단계에 와 있습니다. 하지만 패딩이 어긋나 있거나 인터페이스가 아직 매력적이지 않습니다. 앱이 디자인되는 기존의 모범 사례에 많이 의존하는데, 프론티어 AI 제품에서는 우리가 아직 디자인하지 않은 새로운 상호작용 경험이 너무나 많습니다.

Simon: Opus 특유의 미학이라는 게 있죠. 무언가를 보고 “아, 이건 Opus가 디자인했구나” 하는 느낌이 듭니다. 그걸 넘어설 수 있으면 좋겠네요.

Cat: 맞아요. 앞으로 모델이 인터랙션 디자인 사고 파트너가 되길 정말 기대하고 있습니다.

Thariq: 하지 못하는 것은 무엇인가요? 현실 세계와 더 많이 상호작용하는 모습을 보고 싶습니다. 과학을 해결할 수 있을까? 실험을 조율할 수 있을까? 거기에는 코딩도 어느 정도 들어가지만, 더 넓은 세상에 대한 또 다른 감각이 필요합니다.

Anthropic의 문화 중 다른 회사들이 훔쳐야 할 부분은 무엇인가요?

45:11

마무리 질문으로 좋을 것 같아 물어봤습니다:

Simon: Anthropic의 기업 문화 중 이러한 도구들을 활용해 생산적으로 일하는 데 독특하게 도움이 된다고 생각하는 부분, 다른 회사들이 훔쳐야 할 문화적 해법이 있다면 무엇인가요?

Cat: Claude Tag에 관한 것을 하나 공유하겠습니다. Claude Tag는 공개 채널에 있을 때 가장 잘 동작하고, 대부분의 채널이 공개되어 있을 때 가장 효과적입니다. Claude Tag는 모든 공개 채널을 검색해 가능한 한 많은 맥락을 확보해 가장 정확한 답변을 줄 수 있습니다. 그리고 이건 모든 것에 접근할 수 있을 때만 가능합니다.

Thariq: 기조연설에서도 언급했지만 제게 너무 중요해서 다시 강조하고 싶습니다. 공동 창업자들은 “우리는 스스로와 협상하지 않는다”고 말합니다. 정말 중요하다고 생각합니다. 머릿속으로 트레이드오프를 상상하며 야심찬 일을 스스로 포기할 수도 있지만, 그냥 야심찬 일을 시도해 볼 수도 있습니다. 저희는 항상 “그냥 하면 어떨까? 이게 진짜 트레이드오프일까, 아니면 아닐까?”라고 묻습니다. 그리고 만약 그렇다면 왜 그런지, 그게 진짜 트레이드오프라는 증거는 어디에 있으며, 그냥 그럴듯하게 들리는 말은 아닌지 따져봅니다. 트레이드오프가 스스로 드러나게 하세요. 할 수 있는 한 가장 야심차게 하세요.

Claude로 만들었고 그저 만들 수 있어서 만들었다는 것 중 가장 absurd한 것은 무엇인가요?

46:46

이 질문도 빼놓을 수 없어 넣어봤습니다.

Simon: Claude로 만들었고 그저 만들 수 있어서 만들었다는 것 중 가장 absurd하게 재미있는 것은 무엇인가요?

Thariq: 저는 저 자신을 캐릭터로 한 2D 스트리트 파이터 격투 게임을 만들고 있습니다 — 친구들도 캐릭터로 넣고요. Claude Code를 이용해 Gemini에 프롬프트를 주고, 솔직히 Seedance 모델도 꽤 좋습니다. 비디오 애니메이션을 만드는 거죠. 정말 잘 동작합니다. 프롬프팅을 아주 잘하고, 애니메이션이 좋았는지 프레임을 검증할 수도 있습니다.

Simon: 스트리트 파이터 2 수준의 2D 스프라이트를 생성하는 건가요?

Thariq: 네, 정확히 2D 스프라이트입니다. 애니메이션이 정말 놀랍습니다. 그리고 히트박스도 파악할 수 있습니다. “아, 주먹이 여기 있으니 JSON 히트박스를 그리겠다”는 식으로요. 정말 놀랍습니다.

Cat: 제 건 훨씬 단순합니다. 저는 클라이밍을 정말 좋아하고 친구들도 많이 해서, Claude Code로 우리가 진행 중인 프로젝트들을 기록하는 작은 앱을 만들었습니다. 또 함께 야외로 자주 가기 때문에 워크플로우(workflows)로 여행에 대한 심층 리서치를 많이 합니다. Workflows는 코딩 도구로 브랜딩하지만 여행 리서치에는 정말 훌륭합니다. 팀 오프사이트도 제가 계획하는데, 저희 모두를 수용할 수 있는 장소를 찾는 데도 유용합니다. 워크플로우를 이용해 우리가 가고 싶은 모든 클라이밍 목적지를 리서치하고, 우리 모두가 있는 곳에서 직항편이 있는 곳을 찾습니다. Mountain Project에 들어가 우리 난이도에 맞는 모든 클라임을 찾고, 에어비앤비를 찾습니다. 그리고 저는 하이킹을 좋아하지 않기 때문에 차를 주차한 곳에서 실제 바위까지의 접근 거리(approach)가 매우 짧은 것을 중요하게 생각하는데, 그걸로 필터링합니다. 기존 앱으로는 Mountain Project를 일일이 클릭해 봐야 하지만, 이건 모든 선호도를 입력하면 우리를 위한 맞춤형 앱이 되는 셈입니다.

Simon: 그러니까 본질적으로 클라이밍용 Jira를 바이브 코딩한 셈이네요.

Cat: 맞습니다.

청중: 평가 구축 도구나 에이전트 가시성 도구에 대한 계획이 있나요?

49:23

마지막에 청중 질문을 받을 시간이 몇 분 있었습니다.

청중: 가까운 시일 내에 평가 데이터셋을 구축하기 위한 평가 도구나 에이전트와 워크플로우의 성능을 모니터링하기 위한 가시성 도구를 더 만들 계획이 있나요?

Cat: 평가 도구를 만드는 것도 고려했지만, 사실 제한 요인은 고객이 정말 고품질 평가를 만드는 데 오랜 시간이 걸린다는 점이라고 생각합니다. 그래서 도구 자체보다는 훌륭한 평가를 만드는 스킬셋이 더 큰 제약이라고 봅니다. 저희 내부적으로도 투자하고, 외부에도 모범 사례를 공유할 수 있기를 기대하는 영역입니다.

청중: 메모리는 현재 어떻게 설계되어 있으며, 파일 대신 데이터 저장소로 옮길 계획이 있나요?

50:08

청중 (Sai): 메모리와 멀티플레이어에 관심이 있습니다. 메모리는 현재 어떻게 설계되어 있나요? 아마 파일 기반일 것 같은데요. 두 번째로, 메모리를 더 잘 확장하기 위해 파일 대신 실제로 데이터 저장소가 필요한 직교적인 방향에 대해 고민해 본 적이 있나요?

Thariq: 현재 Claude Tag의 메모리는 채널별입니다. 해당 채널의 모든 Claude가 공유 메모리를 가지고 있고, 인스턴스는 세션을 가지고 있지만 그 세션이 메인 메모리에 다시 기여할 수 있습니다. 저희는 메모리 연구를 많이 하고 있고, 메모리를 다루는 올바른 방법이 무엇인지는 다소 직관에 반할 수 있습니다. 항상 메모리 실험을 실행하고 있습니다. 현재 Claude Tag에서 메모리가 동작하는 방식은 채널당 하나의 마크다운 파일입니다.