이번 달 초, AI 엔지니어 월드 페어에서 Anthropic Claude Code 팀의 Cat Wu, Thariq Shihipar와 파이어사이드 챗을 진행했습니다. Claude Code, Claude Tag, Fable, 코딩 에이전트 보안, 평가(evals), 툴 설계, 그리고 Anthropic이 이 도구들을 내부에서 어떻게 활용하는지까지 폭넓게 이야기를 나눴습니다.
세션 전체 영상은 현재 유튜브에서 시청할 수 있습니다. 아래는 편집된 트랜스크립트로, 관련 링크와 제가 직접 굵게 표시한 하이라이트를 함께 담았습니다.
영상을 보거나 트랜스크립트 전체를 읽기 어려운 분들을 위해 주요 내용을 먼저 정리했습니다.
Simon: Claude Code는 작년 2월에 출시됐는데, 이제 막 1년 반이 된 셈이고 원래는 Claude Sonnet 3.7 출시 발표의 작은 항목 하나였습니다. 실제로 우리를 위해 동작하는 코딩 에이전트가 생긴 지금, 지난 1년 동안 일상적인 업무 방식이 어떻게 달라졌나요?
Cat: Claude Code와 Sonnet 3.7이 처음 나왔을 때가 기억나요. 당시에는 작업을 맡기면 Claude가 하려는 모든 사소한 행동을 일일이 지켜봐야 했어요. 권한 요청 메시지를 하나하나 꼼꼼히 읽었고, "아니오"를 누르는 일도 잦았죠. "이 파일 확인했어? 저 파일은?" 하면서요. 그런데 모델 세대가 거듭될수록 정말 놀라운 변화가 있었어요. 이제는 한발 물러서서 단순 구현 작업의 상당 부분을 Claude에게 위임할 수 있게 됐습니다. 덕분에 더 창의적인 고민에 시간을 쓸 수 있게 됐어요. Claude Code가 상당 부분을 구현해줄 수 있다는 걸 아는 지금, 사용자에게 어떤 경험을 제공해야 하는가 같은 질문이죠. 그리고 이제 Fable이 나오면서 또 한 번 완전히 다른 차원의 도약이 이뤄졌습니다. Fable로는 많은 사용 사례에서 기능 하나를 원샷으로 만들어낼 수 있다는 걸 실감하고 있어요.
Thariq: Claude Code에 대해 처음 받은 문자가 기억나요. 절친한 친구가 "Claude Code 지금 당장 써봐"라고 했거든요. Opus 4가 나오던 무렵이었는데, 직접 써보고 "아, 진짜다. Anthropic에 가야겠다"라고 생각했어요. 그게 Opus 4였는데, 훌륭한 모델이긴 했지만 그때도 권한 요청 메시지를 직접 읽어야 했죠. 지금은 오토 모드가 원래부터 있었던 것 같은 느낌인데, 허용 버튼을 눌렀던 기억조차 가물가물하니 좀 신기하긴 해요. 제가 스스로에게 가장 강하게 요구하는 건 지금까지 해온 것보다 더 높은 품질의 결과물을 내야 한다는 겁니다. 산출물의 품질이 정말 놀라울 정도거든요. 요즘 영상 편집에도 많이 활용하고 있는데, 몇 시간 안에 우리 브랜드 팀의 까다로운 기준을 충족하지 못하면 그냥 포기해야 할 정도예요. Fable로 방향을 잡는 방식이 바로 그것입니다. 지금까지 해온 것 중 최고의 결과물을, 지금까지 가장 빠른 속도로 만들어내는 것이죠.
Simon: 1년 전까지는 맞는 말이었지만, 지금 이 새로운 환경에서는 더 이상 유효하지 않은 소프트웨어 엔지니어링 통념이 있다면 무엇인가요?
Cat: 엔지니어링 역량의 핵심에서 가장 큰 변화가 일어나고 있어요. 2년 전만 해도 PM이 고객 인터뷰를 잔뜩 하고, 6개월에 걸쳐 여러 팀과 조율해 PRD를 만들고, 첫 줄의 코드가 작성되기 전에 꼼꼼한 스펙 문서를 완성하는 게 일반적이었죠. 지금은 완전히 반대가 됐어요. 여기 계신 엔지니어분들께 드리고 싶은 조언은, 무엇을 만들어야 하는지에 대한 비즈니스 감각과 프로덕트 감각을 더 키우라는 겁니다. 아이디어가 생긴 시점부터 구현 완료까지 걸리는 시간이 6~12개월에서 어쩌면 1주일로 줄어들었거든요. 그 말은 곧, 우리 모두가 무엇을 만들 가치가 있는지, 무엇이 실제로 비즈니스에 영향을 줄 수 있는지에 대해 더 날카로운 안목을 가져야 한다는 뜻이에요. 그래서 프로덕트 감각과 비즈니스 센스의 가치는 올라가고, 대부분의 프로덕트 도메인에서 실행력의 가치는 상대적으로 낮아졌습니다. 물론 인프라는 여전히 세세한 디테일을 챙기는 것이 매우 중요하지만요.
Thariq: 저는 리라이트(rewrite)가 이제 좋은 선택지가 됐다는 거라고 생각해요.
Simon: 예전에 최악의 선택이었던 게 이제는 괜찮아졌다는 거군요!
Thariq: 맞아요. "리라이트는 절대 하지 말라"는 『맨먼스 미신(The Mythical Man-Month)』의 가르침도 이제 저는 리라이트 찬성파가 됐습니다. 좋은 테스트 스위트가 있다면 — 리라이트 자체가 테스트 스위트를 제대로 갖추도록 강제하는 효과도 있다고 봐요 — 그런데 사람들이 간과하는 게 있어요. 코드베이스는 그 자체가 스펙이고, 어떤 경우엔 유일하게 남아 있는 스펙이기도 하다는 점이에요. 코드베이스의 모든 분기를 아는 사람은 아무도 없으니까요. 그 코드베이스를 하나의 아티팩트로 가져다가 정제하거나 다른 버전으로 만들어낼 수 있죠. 저희는 Bun을 Rust로 리라이트했는데 아주 잘 작동하고, 지금 제 환경에서도 실제로 돌아가고 있어요.
Simon: 아직 Bun-in-Rust로 Claude Code를 배포하는 건 아니죠?
Thariq: 내부적으로는 그렇게 하고 있어요.
(실제로 Anthropic은 6월 17일부터 Bun-in-Rust 기반의 Claude Code를 모든 사용자에게 배포하기 시작한 것으로 보입니다.)
Simon: 최근 또 다른 큰 출시가 있었죠. Claude Tag인데, 출시된 지 이제 일주일쯤 됐네요, 저 같은 외부 사용자 기준으로는요. 내부에서는 엔지니어가 아닌 직원들도 많이 쓰고 있다고 들었는데요. 비엔지니어들은 Claude Tag로 어떤 일들을 하고 있나요?
Cat: Claude Tag는 팀의 협업 도구 안에서 살아가는 Claude입니다. 지난주에 Slack에서 출시했어요. Claude Tag가 다른 점은 기본적으로 멀티플레이어라는 것입니다. Slack 채널에 Claude Tag를 추가하면, 나도 참여하고, 동료들도 참여해서 PR을 함께 만들어갈 수 있어요. 또 다른 차이점은 반응형이 아니라 능동형이라는 것입니다. Claude Tag에게 "이 채널에서 버그 리포트가 올라올 때마다 PR을 올리고, 해당 코드베이스를 마지막으로 수정한 엔지니어를 태그해줘"라고 설정해두면, 매번 직접 호출하지 않아도 채널이 유지되는 동안 계속 그 일을 해줍니다. 세 번째 변화는 여기에 팀 메모리를 추가했다는 점입니다. 채널에서 Claude Tag에게 선호 방식을 알려주면, 이후 모든 게시물에 그 내용을 반영해요. 예를 들어 장애 상황에서만 디버깅을 원하고 경고(warning)는 무시하고 싶다면, 채널에서 자연어로 그냥 말해주면 됩니다. 그럼 해당 팀원 전체에게 적용되어 기억해줍니다.
내부적으로 저희는 Claude Tag를 Claude Code의 진화된 형태로 보고 있습니다. 내부 업무 방식에 큰 전환점이 된다고 봐요. 현재 Claude Tag는 제품 엔지니어링 PR의 65%를 처리하고 있습니다.
Simon: Anthropic 전체를 말씀하시는 건가요, 아니면 Claude Code 팀만요?
Cat: 저희 제품 엔지니어링 팀 기준입니다. 현재 내부 버전의 Claude Tag가 저희 제품 PR의 65%를 처리하고 있어요. 이건 PR의 절반을 넘는 엄청난 변화예요. Claude Code와 Claude Tag의 역할 분담을 보면, Claude Code는 에이전트와 인터랙티브하게 반복 작업할 때, 가장 복잡한 태스크에 적합한 도구입니다. Claude Tag는 사용자 대신 능동적으로 일을 처리하는 데 강점이 있어요. 작업 중인 기능에서 버그 리포트가 올라올 때마다 Claude Code를 직접 실행할 필요가 없어지는 거죠.
Thariq: 비코딩 사례도 있어요. 예를 들어 이 발표 전에 저희가 Claude Tag에게 "Fable 출시일이 언제야?"라고 물어봤거든요. 공지 타이밍을 맞추고 싶었거든요. Claude Tag가 Slack 전체를 뒤져서 누가 어떤 말을 했는지 파악해주더라고요. 회사 내부 검색 엔진으로서 정말 유용합니다. 제품에 대한 전체 맥락을 갖고 있어서 지표 관련 질문도 할 수 있는데, 의사결정을 할 때 지표 데이터가 필요하면 이벤트 스토어에 연결해두면 돼요. 우리 마케팅 팀이 "이 기능에 대해 설명해줘"라고 요청하는 것도 봤는데, 그분들은 개발자가 아니지만 Claude는 개발자니까 코드베이스를 직접 클론해서 "이게 그 기능이고, 이렇게 생겼고, 내가 직접 써본 화면 녹화도 여기 있어"라고 알려주더라고요. 가능한 범위가 정말 넓고, 아직 초기 단계라고 생각해요.
Simon: 코딩 에이전트를 개인적으로 활용하는 방법은 알겠는데, 팀 환경에서 어떻게 써야 하는지는 아직 잘 모르겠어요. Claude Tag가 그 팀 협업 레이어에 대한 현재 답인 것 같은데요.
Cat: 맞아요. 실제로 저희 세션 중 상당 부분이 지금 멀티플레이어 방식으로 진행되고 있어요. 예를 들어 제가 "Cowork에 이 새 기능을 구현하면 어떨까?"라고 하면, Claude Tag에 1차 작업을 맡기는 거죠. 그런 다음 Claude Tag에게 "최종 구현 화면 녹화본을 공유해줘"라고 하고 디자인 팀을 태그해서 검토를 요청해요. 그쪽에서 방향을 잡아주면, 다시 엔지니어링 팀에 넘겨서 마무리하고 프로덕션에 배포하는 식이에요. 아주 유연한 경험이 되고 있어요. 같은 세션을 함께 조율할 때의 소셜 다이나믹스는 아직 다듬어가는 중이지만, 사람들이 서로 사용하는 모습을 보면서 자연스럽게 따라가더라고요. Claude Tag를 팀에 통합하는 게 꽤 직관적이었어요.
Thariq: 사람들을 가르치는 데도 좋고, 슬롭(slop)을 줄이는 데도 좋아요. 다들 함께 Claude를 쓰는 모습을 보게 되면서, 서로 쓰는 수준도 자연스럽게 올라가거든요.
이 대목에서 Midjourney가 Discord 채널에서 퍼블릭 프롬프팅을 강제하는 방식으로 사용자들에게 고급 이미지 프롬프팅을 가르쳤던 것이 떠올랐습니다.
실제 기능을 만드는 비용이 이렇게 급격히 낮아진 지금, 어떤 기능을 지금 출시할 가치가 있는지 판단하는 게 저도 개인적으로 정말 어렵게 느껴지는 문제입니다.
Simon: 엔지니어링에서 가장 어려운 문제인 우선순위 결정을 어떻게 하고 있나요? 기능을 만드는 비용이 이렇게 낮아진 지금, 어떤 기능이 만들 가치가 있는지 어떻게 판단하시나요?
Cat: 정말 어려운 문제예요. 몇 가지 방식으로 접근하는데요. 하나는 매일 직접 자사 제품을 dogfooding하는 것입니다. 제품에서 하고 싶은 게 안 되면, 다른 방법을 찾는 대신 제품 자체가 그 케이스를 지원하도록 고칩니다. 내부적으로 dogfooding 문화가 정말 강해요. 세상에 내보내기 전에 먼저 Anthropic 전 직원과 솔직한 피드백을 주는 얼리 커스터머들에게 공유하는데, 피드백이 가혹할수록 좋습니다. 사람들이 진심으로 좋아할 때까지 반복합니다. 기능을 외부에 출시하기 전에 내부에서 달성해야 할 활성 사용자 수와 리텐션 기준이 있습니다. 이 기준이 명확하기 때문에 모든 엔지니어가 무엇을 목표로 해야 하는지 알고 있어요. 폴리시도 자연스럽게 올라가는 것 같아요. 기능이 정교하지 않으면 사용자가 이탈하고, 그러면 출시해선 안 된다는 신호가 되니까요.
내부 유저 리텐션을 기능 출시 여부의 기준으로 삼는 방식은 정말 합리적이라는 생각이 듭니다.
Simon: 예상 밖으로 반응이 좋았던 기능이 있나요? 출시했더니 인게이지먼트가 폭발적이었던, 출시하지 않을 수도 있었는데 진짜 제품의 일부가 된 기능이요.
Cat: 있어요. 팀 내 많은 사람들이 원격 제어(remote control)를 정말 좋아하더라고요. 원격 제어는 모바일 기기나 웹 브라우저의 Claude를 통해 CLI에서 실행 중인 로컬 Claude Code 세션에 연결하는 기능이에요. 저는 개인적으로 이 기능이 필요하지 않았어요. 모바일에서 바로 작업을 시작하면 로컬 환경 없이 클라우드 세션에서 돌아가거든요. 아마 제가 비교적 단순한 코딩 작업을 하기 때문인 것 같아요. 솔직히 처음에는 잘 이해가 안 됐어요. "그냥 원격 개발 환경을 세팅하면 되지 않나?"라고 생각했거든요. 근데 막상 원격 제어를 출시했더니, 주변 사람들이 매일 밤 노트북을 충전기에 꽂아두고 원격 제어 세션을 여러 개 열어둔 다음 화면을 잠그고, 소파에서 휴대폰으로 Claude Code를 제어한다고 얘기하더라고요. 처음에는 몰랐지만 이제는 이해가 되는, 우리가 지금 적극적으로 밀고 있는 흐름이 된 거죠.
이번 컨퍼런스의 전반적인 주제 중 하나가 바로 리뷰였습니다. 코딩 에이전트가 작성한 코드를 사람들이 얼마나 꼼꼼하게 검토하는지에 관한 이야기죠. Claude Code 팀의 생각이 정말 궁금했습니다!
Simon: 코드 리뷰는 어떻게 진행되나요? Claude Code에 들어가는 프로덕션 코드를 모두 사람이 직접 리뷰하나요? 그렇지 않다면 어떻게 품질을 유지하나요?
Thariq: 작업에 따라 달라요. 중요한 영역에는 코드 오너(code owner)가 있습니다. 시스템 프롬프트가 좋은 예인데, 코드 오너의 승인이 반드시 필요해요.
Simon: 코드 오너가 그 영역 코드의 품질에 직접 책임을 지는 거군요.
Thariq: 맞아요.
Cat: 해당 영역을 건드리는 PR은 반드시 코드 오너의 승인을 받아야 합니다.
Thariq: 저희 코드 리뷰 GitHub 봇이 모든 PR을 검토하는데, 실질적인 리뷰의 상당 부분을 담당합니다. 팀에서 보면 복잡한 PR의 경우 리뷰어들이 맥락을 파악하기 쉽도록 설명 아티팩트를 만들기도 하고요. 검증에도 많이 투자하는데, CI/CD 등을 활용해서 어떤 것이든 실패가 발생하면 반드시 테스트가 존재하도록 합니다. Claude가 Claude Code를 제어하고 테스트할 수 있는 견고한 환경도 갖추고 있어요. 그래서 코드 리뷰는 여러 접근 방식을 복합적으로 활용합니다.
Cat: 큰 방향은 사람이 루프 안에 있지 않아도 되는 세계로 가는 것입니다. Claude Code의 핵심과 다른 제품들의 핵심에 해당하는 가장 중요한 변경사항은 항상 코드 오너가 있고, 그들이 모든 변경사항을 수동으로 리뷰합니다. 하지만 점점 더 외부 레이어의 변경사항은 Claude 코드 리뷰가 완전히 담당하고 있어요. 겁나는 얘기처럼 들리겠지만, 저희는 6개월 이상의 과정을 거쳐 여기까지 왔고, 코드 리뷰에 대한 신뢰를 쌓아가는 데는 단계적인 접근이 필요합니다. 처음에는 모든 것을 사람이 리뷰했고, 그러다 점점 "이 파일들을 건드리는 코드 변경사항은 코드 리뷰가 100% 이슈를 잡아내고 있으니, 사람이 수동으로 리뷰하지 않아도 되겠다"라는 판단을 내리기 시작했습니다. 인시던트 리뷰를 할 때는 해당 인시던트를 유발한 PR들을 살펴보고 코드 리뷰가 그걸 어떻게 잡아낼 수 있도록 업데이트할지 논의하죠. 그리고 그 PR들을 평가 세트에 추가해 코드 리뷰를 미래에 바꾸더라도 그 지표가 퇴행하지 않도록 합니다. 코드 리뷰 루프에서 사람을 빼는 것은 큰 도약이에요. 겁이 날 수 있고, 하룻밤 사이에 가능한 일도 아닙니다. 하지만 인프라에 수개월간 꾸준히 투자하면 코드 리뷰가 중요한 부분을 모두 잡아낸다는 확신을 가질 수 있게 됩니다.
핵심은 자동화된 리뷰 시스템 자체를 꾸준히 개선하면서 그에 대한 신뢰를 시간을 두고 쌓아가는 것이라는 점이 흥미롭습니다.
평가에 대해 심층적으로 깊이 파고들었습니다. 이번 컨퍼런스 전반에서 뜨거운 주제였죠.
Simon: Opus 4.8에게 SQL 쿼리를 실행하고 JSON을 반환하는 엔드포인트를 만들어달라고 하면 그냥 잘 만든다는 걸 알기 때문에 굳이 꼼꼼히 리뷰하지 않아요. 근데 새 모델이 나오면, Opus가 잘하던 것을 Fable이 망치진 않을까 하는 신뢰를 어떻게 빠르게 쌓아야 할지 모르겠더라고요. 새 모델이 나왔을 때 할 수 있는 것과 없는 것에 대한 직관을 어떻게 업데이트하나요?
Cat: 저희가 평가 기반을 꾸준히 쌓아오는 주된 이유가 바로 새 모델을 바로 대체 투입할 수 있게 하기 위해서예요. 새 모델이 나오면 전체 평가 세트를 돌려서, 예를 들어 Fable이 Opus 4.8보다 모든 면에서 낫다는 걸 확인하고, 그 확신을 바탕으로 교체합니다.
Simon: 그 모델 평가는 Anthropic 전체 차원인가요, Claude Code 팀 자체적으로 하는 건가요?
Cat: 둘 다 있어요. 팀 자체 평가도 있고, Anthropic 전체 레포에 코드 리뷰를 돌리기 때문에 그에 대한 평가도 있습니다. 오토 모드 같은 경우는 Anthropic 내부 전 사용자를 대상으로 평가하는 것은 물론이고, 외부 레드팀을 여럿 고용해서 프롬프트 인젝션이나 악성 입력이 포함된 적대적 환경을 구성하게 하고, 오토 모드가 이런 공격을 통과시키지 않는지 확인합니다.
Simon: 내가 수정한 시스템 프롬프트가 실제로 제품을 개선했는지 알고 싶은데, 이게 제품 특화 평가의 가장 기본적인 형태인데도 아직 잘 모르겠거든요. 시스템 프롬프트를 수정했을 때 실제로 결과물이 더 좋아졌다는 완전한 확신을 얻는 방법이 있나요?
Cat: 완전한 확신을 얻지는 못하지만, 성능이 퇴행하지 않도록 많은 노력을 기울이고 있어요. 출발점은 신뢰할 수 있는 외부 평가 모음이고, 그보다 훨씬 큰 내부 평가 모음으로 보완합니다. 처음에는 주로 역량을 최적화합니다. 태스크의 완전한 정의와 전체 코드베이스가 주어졌을 때, Claude가 올바른 판단을 내리고, 버그를 완전히 수정하고, 모든 테스트를 통과하는지 여부죠. 그게 사용자가 가장 원하는 것이기 때문에, 그게 출발점이자 최적화 대상입니다. 하지만 사용자가 Claude Code를 쓸 때의 느낌에 영향을 주는 행동 방식도 많아요. 예를 들어 Claude Code가 "이제 쉬러 가야 할 것 같아요"라고 하면 사람들이 정말 싫어해요. 또는 "다섯 가지 중 두 가지를 완료했는데 계속할까요?"라고 물어보는 것도요. 그냥 계속하면 되잖아요. 그래서 이런 행동들을 잡아내는 행동 평가 세트를 만들어가고 있어요. 사용자 피드백이 들어오면 — 솔직한 피드백을 많이 주세요 — 우선순위 이슈들을 하나씩 해결하면서 각각에 대한 평가를 만들어나갑니다. 100% 커버리지는 아니지만, 커버리지를 높이는 것이 저희 우선과제입니다.
Simon: Claude Code 팀과 실제로 모델을 학습시키는 Anthropic 팀 사이의 협업은 얼마나 긴밀한가요? 꽤 가깝게 협력하고 있나요?
Cat: Anthropic 전체적으로 모두 꽤 긴밀하게 협력하고 있어요. 다음 세대 모델이 어떤 능력을 갖출지에 대해 자주 이야기를 나눕니다. 리서치 팀도 이걸 공개적으로 잘 보여주고 있는데, 블로그 포스트에서 점점 더 긴 호라이즌의 작업을 목표로 하고 있다는 것과 Claude가 정직하고, 무해하고, 도움이 되도록 학습하는 방식을 자주 다루고 있습니다. 사용자의 의도가 다소 불명확하게 표현되더라도 그에 맞게 정렬되도록 하는 데도 많은 노력을 기울이죠. 물론 Claude에게 원하는 것을 최대한 구체적으로 말하는 게 좋지만, 그렇지 않더라도 Claude가 합리적인 가정을 하도록 가르치고 있어요. 생산적인 파트너십이 이어지고 있습니다.
이 섹션에 정말 유용한 프롬프팅 팁이 가득합니다!
Simon: Thariq, 오늘 아침 발표에서 언급하셨는데, Claude Fable 덕분에 Claude Code 시스템 프롬프트가 80% 줄었다고요. 좀 더 자세히 이야기해주실 수 있을까요? 어떤 내용들을 뺄 수 있었나요?
Thariq: Fable만의 이야기가 아니라 Opus 4.8도 포함되고, 앞으로 나올 모델들도 마찬가지예요. 이제 모델별로 다른 시스템 프롬프트를 씁니다. 저희가 발견한 패턴 중 하나는 Claude를 지나치게 제약하고 있었다는 거예요. 초기 Opus 4 즈음의 모델들은 예시를 많이 필요로 했는데, 예시를 제거하는 것이 굉장히 효과적이었어요. 모델이 저희가 준 예시보다 더 창의적이었거든요.
Simon: 흥미롭네요. 제가 늘 드리는 프롬프팅 팁 중 하나가 "예시를 줘라"였거든요. 그게 더 이상 맞지 않는 말이라면, 제 프롬프팅 모델이 좀 흔들리는 느낌이 드네요.
Thariq: 저도 그 얘기 듣고 놀랐어요. 이제는 무엇을 주느냐의 형태가 더 중요한 것 같아요. Claude에게 주는 툴, 시스템 프롬프트 같은 것들이요. 그리고 저희가 또 시도한 게 더 많은 맥락을 주되 "이렇게 하지 마라"는 지시를 줄이는 것이었어요. Claude에게 이런 지시는 굉장히 강한 신호로 작용하는데, 특히 나중에 들어오는 사용자 지시와 충돌하면 Claude에게 엄청나게 혼란스러운 상황을 만들거든요. "이 스킬에는 이렇게 하라고 하고, 시스템 프롬프트에는 이렇게 하라고 나와 있다"라는 식으로요. 그래서 하드 제약은 줄이고, 맥락을 늘리고, 전체 지시 사항은 최소화하는 방향으로 가고 있어요. 분명히 일종의 과학인데, 평가를 많이 돌려서 만들어낸 결과예요.
Cat: 일반적으로 이 모델들에 프롬프트를 줄 때는 항상 이런 생각을 해야 해요. 내가 주는 이 지시에 예외적인 경우가 있지 않을까? Claude Code 시스템 프롬프트의 모든 지시를 다시 검토했을 때, 맞는 말이긴 한데 10%의 경우에는 실제로 틀린 문장들이 몇 개 있었어요. 모델을 제약하거나, 항상 그렇게 해야 한다고 혼동시키고 싶지 않았죠. 좋은 예가 검증(verification)이에요. 누구나 Claude가 자신의 작업을 검증하길 원하고, 저희도 프롬프트에 "프론트엔드 변경을 하면 항상 검증하라"는 지시를 넣었었어요. 그런데 여기에도 한계가 있어요. 문자열 하나를 다른 문자열로 바꾸는 수정이고, 사용자가 "빠르게 고치고 테스트만 업데이트해줘"라고 했다면, 굳이 검증이 필요하지 않을 수도 있으니까요. 그래서 저희는 "항상 검증하라"는 문구를 "프론트엔드 작업의 경우 백엔드 엔드포인트만 호출해서는 전체 경험을 이해하기 어려우므로, 사용자 경험에 큰 변화를 줄 때는 앱을 로컬에서 실행해 보세요" 정도로 조정했습니다. 사실 이 지시도 완벽하지 않아요. "큰 변화"가 뭔지 기준이 없으니까요. 작은 변화도 테스트해야 할 수도 있고요. 결국 프롬프트를 줄 때는 항상, 의도가 좋은 사람이 이걸 어떻게 오해할 수 있는지 생각해보면 모델이 어떻게 해석할지를 더 잘 이해할 수 있어요. 그리고 프롬프트를 완화해서 100%의 경우에 실제로 맞는 말이 되도록 해야 합니다. 이 프롬프트는 100%의 경우에 모델에게 전달되니까요.
Simon: 흥미로운 점은, 모델의 판단에 의존하는 것인데요. Opus나 Fable 수준에서나 가능한 이야기겠죠. 1년 전 모델들은 테스트 여부를 스스로 판단할 수준이 아니었으니까요. 다만 저렴한 모델로 저렴한 작업을 처리하는 다양한 모델 환경을 구축하는 경우에는 이게 무너질 수 있겠죠.
Cat: 바로 그 이유로 저희가 모델별로 다른 시스템 프롬프트를 쓰고 있어요. 이 80% 토큰 감축은 최신 프런티어 모델에만 해당되고, 구형 모델은 여전히 전체 시스템 프롬프트를 씁니다.
Simon: Fable과 Opus가 Haiku에게 더 상세한 프롬프트를 주도록, 즉 Haiku는 판단력과 감각이 부족하다는 걸 이해해서 알아서 조정할 정도로 똑똑할까요?
Cat: 아직 평가해보지 않아서 확실한 데이터는 없어요.
Thariq: 소형 모델을 쓸 때 까다로운 점이 있는데, 어려운 문제에서는 오히려 대형 모델이 소형 모델보다 토큰 효율이 높을 때도 있어요. 그래서 직관을 좀 키워야 하는 부분인데, 프런티어 수준의 지능이 거의 항상 필요한 경우도 있거든요. 파레토 곡선이 달라지는데, 그 지점을 찾기가 쉽지 않아요.
Simon: 1년 전만 해도 모델이 프롬프트를 직접 작성하는 걸 믿지 못했는데, 이제 좋은 모델들은 프롬프팅을 정말 잘해요. 제 프롬프트 중 많은 부분을 모델이 직접 쓰는데, 황당하게 들리지만 실제로 잘 돌아가요. 이걸 납득하게 된 계기가 서브에이전트를 생각하면서였어요. 서브에이전트는 본질적으로 Claude 모델이 다른 Claude 모델을 위한 프롬프트를 설정하는 것이니까요.
Thariq: 워크플로우가 정말 좋은 예예요. Claude가 단순히 서브에이전트 하나에 프롬프트를 주는 게 아니라, 여러 서브에이전트의 오케스트레이션에 프롬프팅을 하고 각 에이전트마다 매우 상세한 프롬프트를 주니까요. 서브에이전트 하나를 띄우는 것보다 한 단계 위 수준이에요. 저도 개인 컴퓨터에서 써봤는데, Gemini API를 주고 이미지를 생성하라고 시켜봤거든요. 이미지 모델에 프롬프트를 주는 데 있어서 저보다 훨씬 덜 게을러요. 결국 Claude가 Claude를 계속 프롬프팅하는 구조인 거죠.
Cat: 그 워크플로우 툴의 프롬프트도 Claude가 직접 쓴 것 같아요.
Simon: 저도 그 프롬프트 읽어봤는데 잘 만든 프롬프트더라고요. 사실 Anthropic에 대해 한 가지 아쉬운 게 있는데, Claude Chat 프롬프트는 공개하면서 툴 프롬프트와 Claude Code 프롬프트는 공개하지 않잖아요. 여전히 프록시를 실행해서 가로채야 하는데요. Claude Code 프롬프트를 의도적으로 공개해주면 좋겠어요. 그게 곧 문서이고, 툴이 무엇을 할 수 있고 어떻게 동작하는지 알 수 있는 방법이니까요.
Cat: 피처 리퀘스트로 적어둘게요. Claude Tag한테 시켜볼게요.
재미있는 점은 OpenAI의 GPT-5.6 프롬프팅 모범 사례에도 최신 모델에 대한 비슷한 조언이 담겨 있다는 것입니다.
프롬프트는 더 간결하게
반복 지시와 예시를 제거하고 툴 설명을 단순화하면 태스크 성능과 토큰 효율이 향상될 수 있습니다. 내부 코딩 에이전트 평가 실행 샘플에서, 프롬프트를 간결하게 구성한 설정이 평가 점수를 약 10~15% 향상시키면서 총 토큰을 41~66% 줄이고 비용을 33~67% 절감했습니다. 결과는 워크로드에 따라 달라지므로, 이 수치는 방향성 참고용으로만 활용하고 실제 애플리케이션의 대표적인 태스크로 검증해보시기 바랍니다.
Simon: Claude Code는 사실상 툴의 집합체죠. 새 툴을 추가할 때의 기준은 무엇인가요? 그 수준에서 추가 엔지니어링을 할 가치가 있는지 어떻게 판단하나요?
Cat: 당신이 얘기해줄래요? 저희가 가진 툴 중 가장 좋은 것 하나를 당신이 만들었으니까요.
Thariq: ask user question 툴을 만든 게 제 커리어 최고의 순간이에요. 정말 어려운 일이에요. 특히 일부 툴은 — ask user question은 Claude가 사용자에게 되묻는 툴이거든요 — 평가하기도 어렵고, 어떤 면에서는 사용자 선호도의 문제이기도 해요. 당시에는 평가가 지금보다 훨씬 적었기 때문에 dogfooding, 즉 저희 식으로는 "ant fooding"에 많이 의존했어요. 전체적으로는 툴 수를 줄이는 방향으로 가고 있어요. 마지막으로 추가한 건 task 툴인데, Claude에게 더 범용적인 방식을 주려고 노력하고 있어요.
파일 편집 툴은 제가 오랫동안 관심을 가져온 주제입니다. 예전 Aider 코드 편집 리더보드의 주제이기도 했고, 다양한 코딩 에이전트에서 검색-치환 방식에서 행 번호 기반으로, 또 더 복잡한 패턴으로 진화하는 과정을 지켜봐왔습니다.
Claude API 문서에는 API를 사용할 때 권장되는 텍스트 편집 툴이 나와 있는데, Claude Code는 약간 다른 방식을 쓰는 것 같습니다.
Simon: 흥미로운 툴 중 하나가 파일 편집 툴이에요. 파일 편집을 툴로 갖거나, sed와 grep을 쓰도록 할 수도 있죠. 파일 편집 툴은 지금 어떻게 진화했나요?
Thariq: 여전히 있긴 한데, 예를 들어 grep이나 다른 검색 툴, glob 툴 같은 건 네이티브 bash로 대체하면서 없앴어요. 아까 제 발표에서도 말했지만, 모델은 물리학보다는 생물학에 가깝고, 툴 설계는 특히 더 어려워요. Cat이 평가 측면에서 과학적으로 접근할 수 있다고 생각할 수도 있는데, 저는 툴 설계가 예술에 가깝다고 보기도 해요. 아니면 생물학이거나요.
Cat: 대체로 동의해요. 다만 전체적으로 툴을 추가할 때 가짓수를 적게 유지하면서 각 툴이 다른 툴과 뚜렷하게 구분되는 기능을 하도록 해야 Claude가 언제 어떤 툴을 호출할지 쉽게 구별할 수 있어요. 파일 편집 툴을 유지하는 이유는 사실 렌더링 때문이에요. Claude가 파일을 변경할 때 그걸 보여줄 수 있거든요. "이 파일을 이렇게 수정하는 것에 동의하시나요?"라고 묻는 전용 UI가 있어요. 전용 파일 편집 툴을 둔 이유는 Claude가 파일을 변경하고 있다는 것을 결정론적으로 알 수 있어야 그 좋은 UI를 보여줄 수 있기 때문이에요. 새로 온보딩하는 사용자들이 이 경험을 아직도 좋아해서 남겨두고 있지만, 지금 오토 모드를 쓰는 분들 — YOLO 모드는 아니시길 바라지만 — 입장에서는 사실 별 의미가 없고, 파일 편집 툴을 없애도 아무 문제 없을 것 같아요.
드디어 프롬프트 인젝션(prompt injection) 이야기입니다! Anthropic 직원들보다 Claude Code 인스턴스가 오작동할 위험에 대해 Anthropic이 어떻게 생각하는지 설명해줄 적임자가 어디 있겠어요?
그들은 오토 모드를 정말 신뢰하고 있었고, 이를 Claude Tag를 가능하게 한 기술로 바라보고 있었습니다.
Simon: 안전과 보안 이야기를 해봅시다. 저는 프롬프트 인젝션의 위험성을 잘 알고 있는데, 누군가가 제 Claude Code에 다른 명령을 내릴 수 있다면 정말 끔찍한 일이 벌어질 수 있죠. 그래서 아직도 저는 대부분 Claude Code를 YOLO 모드로 실행하고 있고 엄청난 죄책감을 느끼고 있어요. Anthropic 내부에서는 Claude Code를 안전하게 실행하기 위해 어떤 조언을 하나요?
Cat: 오토 모드는 왜 안 쓰세요?
Simon: 오토 모드를 쓰기 시작하긴 했는데, 얼마나 안전한지 아직 잘 모르겠어요. 한 3주 전부터 기본적으로 오토 모드를 쓰고 있어요.
Cat: Anthropic 전체적으로 거의 모든 사람이 오토 모드를 씁니다. Claude Code로 장시간 작업하면서도 안전하게 할 수 있는 최선의 방법이에요. 저희는 엄청난 양의 테스트를 진행했어요. 수천 개의 평가도 돌렸고, Claude Code를 속여서 잘못된 행동을 하도록 적대적 환경을 만드는 레드팀도 여럿 고용했는데, 발견된 모든 문제를 해결했습니다. 앞으로 몇 주 안에 평가 결과를 공개할 예정인데, 거의 모든 공격을 막아냈어요.
Simon: 꽤 강한 주장이네요.
Cat: 평가 결과를 공유해서 직접 판단해볼 수 있게 할 거예요. Claude가 잘못될 수 있는 모든 경우를 찾아내고 오토 모드를 업데이트해서 대응하는 데 정말 철저하게 임해왔어요. 100%를 잡아낸다고는 말 못하지만 — 그건 너무 강한 주장이 될 테니까요 — 저희가 주목하는 주요 위험 카테고리인 프롬프트 인젝션과 데이터 유출에 대해서는 평균적인 사람의 리뷰보다 위험도가 훨씬 낮아요.
오토 모드를 검증하는 방법과 그에 대한 더 자세한 내용을 빨리 확인해보고 싶습니다.
Thariq: 오토 모드가 어떻게 작동하는지 조금 설명해드릴게요. 멘탈 모델을 세우는 데 도움이 될 거예요. Claude가 한 번의 턴을 처리하거나 bash를 호출할 때마다, Sonnet 분류기가 해당 툴 호출과 대화 맥락, 그리고 사용자의 지시를 함께 판단합니다. 권한과 관련해서 사용자의 요청에 따라 달라지는 부분이 있어요. 항상 git push 권한을 주고 싶진 않겠지만, "GitHub에 푸시해줘"라고 하면 해야 하고, "푸시하지 마"라고 하면 막아야 하죠. 오토 모드가 그걸 처리해줍니다. 저도 자주 겪는 상황인데, Claude가 굉장히 적극적이고 도움이 되고 싶어서 뭔가를 하려고 했는데, 오토 모드가 "이건 하면 안 돼"라고 감지해서 알려주는 거죠. 그래서 동적 권한 관리에 효과적입니다. 사용자가 프롬프트 안에서 직접 주는 권한 설정이 굉장히 중요하다고 생각하거든요. 저희 샌드박싱 인프라와도 잘 맞는데, 샌드박싱은 엣지 케이스가 너무 많아서 결정론적으로 따르기 어렵거든요. 샌드박스가 있고, 네트워크 요청처럼 샌드박스를 벗어나는 동작이 생기면, 오토 모드가 그 요청을 보고 "이게 합리적인 요청인가?"를 판단한 다음 허용합니다.
Simon: 오토 모드가 네트워킹 샌드박스와도 연동된다는 건 몰랐네요.
Cat: 사용자가 원래 봤을 모든 권한 요청 메시지와 연동됩니다.
Simon: 오토 모드가 도입된 지 얼마나 됐죠? 제가 쓸 수 있게 된 건 불과 몇 달 전이잖아요.
(일반 사용자에게는 3월 24일에 처음 제공됐습니다.)
Cat: Anthropic 내부에서는 1월부터 써왔기 때문에 꽤 오랫동안 강화해온 거예요. Anthropic은 안전과 보안에 극도로 집중하는 회사이고, 정렬팀과 세이프가드팀과 폭넓게 협력해서 내부 롤아웃을 가능하게 하고, 평가를 구축하고, 세상에 공개하기 전에 오토 모드를 더욱 견고하게 만들어왔어요.
Thariq: 이것이 Claude Tag가 잘 작동하는 이유이기도 해요. Claude Tag는 오토 모드를 사용하거든요. AI Slackbot을 자체 구축할지 물어보시는 분들을 많이 봤는데, 직접 만들지 않는 편이 나을 거예요. 공격 벡터가 너무 많거든요. 사용자들이 피드백을 올리는 채널이 있는데, 이제 봇이 그 내용을 읽습니다. 저희가 오토 모드에 쏟은 노력 — 보안을 위한 스위스 치즈 방어 전략을 쓰고, RL로도 이런 부분을 강화하는데 — 바로 이것이 Claude Tag를 실제로 작동하게 만드는 핵심이라고 생각합니다. 권한과 자연스럽게 맞물려 작동하고, Slack에서 프롬프트 인젝션을 당하고 싶지 않잖아요.
Simon: 오토 모드 이후로 보안 측면에서 더 준비하고 있는 것들이 있나요?
Thariq: 이미 꽤 견고하다고 봐요. Claude Tag에서는 Claude에 직접 자격 증명(credentials)을 부여할 수 있어요. 사용자를 대신해서 행동할 필요 없이 Claude 자체가 하나의 아이덴티티를 가질 수 있고, 그러면 Claude가 무엇을 하고 있는지 감사(audit)하고 검사하기도 쉬워지죠.
Simon: Claude Tag는 채팅할 수 있는 모든 사람의 영향을 받으니까요. 명령을 내릴 수 있는 사람의 범위가 훨씬 넓어지잖아요.
Thariq: 맞아요. 물론 Fable을 통한 프로브도 있는데, 이건 저희 안전 및 리서치 작업의 파생 효과예요. 이게 바로 Anthropic이 AI 안전 회사임이 빛을 발하는 순간이라고 생각해요. 오랜 시간 동안 Claude가 정렬된 방식으로 실행될 수 있기를 진심으로 원하고, 오토 모드가 이를 위해 사실상 흠잡을 데 없어야 합니다. 이 모든 것이 AI 안전 회사라는 정체성에서 나오는 거예요.
Cat: 더 안전하게 쓰고 싶은 원격 제어 사용자들을 위해 신뢰할 수 있는 기기(trusted devices) 기능도 출시했어요. 그리고 모든 원격 환경에서 자격 증명 주입(credential injection)을 지원합니다. Claude Code가 Datadog에 접근해야 하지만, Claude Code 자체가 Datadog 자격 증명을 보유하는 건 원하지 않는다면, 아이덴티티 및 자격 증명 관리 시스템을 설정해서 Datadog 자격 증명이 에이전트에 의해서만 사용되고 에이전트가 직접 접근할 수는 없도록 만들 수 있어요. 에이전트가 Datadog 요청을 할 때 즉석에서 삽입하는 방식이에요.
이 자격 증명 주입 패턴이 정말 마음에 드네요. Claude Code가 프록시를 통해 API에 접근하고, 그 프록시가 요청을 감사(audit)하는 동시에 해당 API 키를 주입해주는 방식이죠. 덕분에 Claude는 인증된 엔드포인트에 접근하면서도 API 자격 증명 자체는 알 수 없습니다.
Thariq은 오전 기조연설에서 Fable급 모델이 불러온 상실감에 대해 이야기했는데, 대화에서 더 깊이 들어갔습니다. 저는 이를 딥 블루 현상이라고 부르고 있습니다.
Simon: 사람에 관한 이야기를 해볼게요. 소프트웨어를 만드는 데 있어 자신의 역할이라고 생각했던 것들이 모델에게 흡수되면서 상실감을 느끼는 사람들이 많습니다. 어떻게 생각하세요? 지난 1년 반 동안 자신의 일에 대한 생각과 자신이 더하는 가치에 대한 시각이 어떻게 바뀌었나요?
Thariq: Cat과 Boris는 항상 더 야심차게 생각하라는 걸 일깨워줘요. 항상 빠르게 성장하고, 최전선에 있고, 최선의 결과물을 내야 한다고 하거든요. 저에게는 늘 상기시켜주는 존재예요. 뭔가 느리게 진행될 때마다 스스로에게 물어요. 더 빠르게 할 수 있을까? 여기서 더 야심찬 목표를 세울 수 있을까? 그 답이 종종 Claude인데, 지난번 시도와 달리 모델이 계속 나아지고 있으니까요. 상실감에 대해서: 이건 실재하는 감정이에요. LLM이 나오기 전에 하던 일을 똑같이 하려는데 이제 그게 프롬프트로 대체된다면, 어떤 면에서는 씁쓸하게 느껴질 수 있어요. 그걸 상쇄하는 방법은 더 야심차게 생각하는 것입니다. Jared가 정말 좋은 예인데, 오클랜드 아파트에서 약 1년 동안 Zig 코드를 손으로 직접 짰고, 집 밖을 거의 나가지 않으면서 정말 즐거워했거든요. 지금 그가 Bun 전체를 Rust로 리라이트하는 걸 보면 너무 즐거워하고 있어요. 훨씬 더 야심찬 프로젝트이고, 그게 그 상실감을 상쇄하는 방식이에요. 결국 핵심은 어떻게 하면 더 큰 것을 할 수 있을까를 고민하고 더 많이 해내는 것인데, 성공 자체가 즐거움이라고 생각해요. 목표 자체를 바꾸는 거죠.
"더 야심차게 생각하라"는 말이 저도 이 문제에 대해 도달한 결론을 깔끔하게 담아낸 것 같습니다.
Simon: Cat은 프로덕트 매니지먼트 관점에서 어떻게 보이나요?
Cat: 프로덕트 역할 자체가 매달 바뀌는 것 같아요. 저희 팀 PM들은 엔지니어, 디자이너, PM의 역할을 동시에 소화하는 하이브리드형이에요. 실제로 대부분이 풀타임 엔지니어 출신이기도 하고요. 저에게 그 의미는 어떤 빈자리든 들어가 채우는 것이에요. 어떤 아이디어가 생겼는데 엔지니어를 설득하지 못했다면, 직접 만들어서 노트북에 올려두고 사람들이 프로덕션까지 가져가도록 영감을 줘야죠. 디자인이 조금 어색해 보이면, 비슷한 페이지를 참고해서 1차 디자인을 먼저 잡고 디테일에 강한 사람을 불러서 나머지를 채워달라고 하면 돼요. 아니면 팀 내 제품 도입이 늘어나고 Claude Code, Claude Tag, Cowork의 다음 행보를 더 많은 사람이 알아야 할 때는, 전체 런치 캘린더를 자동화하고, 사람들을 귀찮게 하지 않고 비동기적으로 상태 업데이트를 자동화해서 내부 공지 채널이 항상 자세하고 핵심을 담도록 하는 거예요. 결국 저에게는 좋은 아이디어와 고객에게 닿는 것 사이의 빈자리가 무엇인지 파악하는 것, 그리고 그것을 최대한 자동화하는 것이 핵심이에요.
코드를 훨씬 빠르게 만들 수 있게 됐을 때, 누군가의 결정을 기다리며 멈춰 있는 시간이 훨씬 더 두드러지는 병목이 된다는 걸 저도 느끼고 있습니다. 제품 결정을 스스로 내릴 수 있는 엔지니어는 훨씬 빠르게 움직일 수 있고, 그 결정 하나가 잘못됐을 때의 비용도 훨씬 낮아졌습니다.
Simon: Claude가 가장 놀랍게 느껴졌던 순간은 언제인가요? 모델이 할 수 없을 거라고 생각했는데 해낸 경험이요.
Thariq: Claude의 영상 편집 능력에 대해 많이 올렸는데, 가장 최근 얘기를 하면, ACM 에이전틱 컨퍼런스에서 발표를 하고 나서 "편집된 영상 있나요? 홍보팀과 공유하고 싶어서요"라고 물었더니 "시간이 너무 걸려요"라고 하더라고요. 그래서 원본 파일을 달라고 했어요. 제가 발표하는 영상, 슬라이드 영상, 그리고 오디오 파일을 보내면서 "행운을 빌어요"라고 했죠. 저는 이걸 HTML 덱과 함께 Claude에게 주고 "그냥 편집해서 붙여줘"라고 했어요. 결과가 정말 놀라웠는데, 그냥 출시해도 되겠다 싶었어요. 전체 영상을 트랜스크립트해주더라고요. 슬라이드 영상이 중간에 자동 업데이트 팝업이 뜨는 것도 발견하더니 "슬라이드 영상은 쓰면 안 되겠어. 대신 영상을 잘라서 어떤 슬라이드인지 파악하고, HTML 소스를 쓸게"라고 스스로 판단하더라고요. 그래서 HTML 소스를 보여줬어요. 그런데 제가 찍힌 영상에서 제가 무대 한쪽에 작게 나와 있으니까 동적으로 제가 있는 위치를 크롭하는데, 제가 왔다 갔다 하는 걸 따라다니면서요. 동시에 제가 말하는 내용도 트랜스크라이브하고 있었죠.
Simon: Fable로 한 거죠?
Thariq: 네, Fable이에요. 프롬프트를 잘 썼지만 원샷 프롬프트였어요. 그 다음엔 흥미로운 애니메이션과 그래픽을 추가해달라고 했는데, 정말 감탄했어요. ffmpeg도 쓰고, Remotion도 썼어요.
Thariq이 Fable을 활용해 Fable 자체의 런치 영상을 편집한 방법에 대한 영상이 있고, 그 런치 영상도 여기에서 볼 수 있습니다.
부끄럽지만, 요즘은 Fable 5나 GPT-5.6 같은 프런티어 모델이 해내지 못하는 작업을 떠올리는 것 자체가 꽤 어려워졌습니다.
Cat은 여전히 UI 디자인 실력에는 아직 아쉬움이 있다고 합니다.
Simon: 아직 못하는 것은 무엇인가요? Claude Fable 6를 기다리고 있는 부분, 아직 실망스러운 부분이요.
Cat: 디자인과 UX 감각이 더 좋아졌으면 해요. 이제 기능 동작 방식을 상세하게 스펙으로 적어서 프롬프트를 주면 대부분 그대로 구현해내는 수준이 됐어요. 근데 패딩이 어긋나 있거나, 인터페이스가 아직 매력적이지 않은 경우가 있어요. 기존 앱 디자인 모범 사례에 기대는 경향이 있는데, 프런티어 AI 제품에서는 아직 누구도 설계해보지 않은 새로운 인터랙션 경험들이 너무 많거든요.
Simon: "Opus 미학"이라는 게 있잖아요. 보면 바로 "아, 이거 Opus가 디자인한 거구나" 알 수 있는데, 거기서 벗어났으면 좋겠어요.
Cat: 맞아요. 앞으로 나올 모델이 인터랙션 디자인의 파트너가 되길 정말 기대하고 있어요.
Thariq: 못하는 것이라면, 저는 실제 세계와 더 많이 상호작용하는 걸 보고 싶어요. 과학 문제를 해결할 수 있을까요? 실험을 오케스트레이션할 수 있을까요? 코딩적인 요소도 있지만, 더 넓은 세계에 대한 감각도 필요한 부분이거든요.
마무리 질문으로 딱이라고 생각했습니다.
Simon: Anthropic의 회사 문화 중에서 이 도구들을 생산적으로 활용하는 데 특히 도움이 되는 부분이 있다면 무엇인가요? 다른 회사들이 가져가야 할 문화적 노하우가 있다면요?
Cat: Claude Tag에 관한 것을 하나 말씀드릴게요. Claude Tag는 공개 채널에 두고, 채널 대부분을 공개로 운영할 때 가장 효과적입니다. Claude Tag는 모든 공개 채널을 검색해서 최대한 많은 맥락을 확보하고 가장 정확한 답변을 드릴 수 있는데, 그러려면 모든 것에 접근할 수 있어야 해요.
Thariq: 기조연설에서도 말했지만 저에겐 정말 중요한 내용이라 다시 한번 강조하고 싶어요. 공동 창업자들이 "우리는 스스로를 향해 협상하지 않는다"고 말하는데, 이게 정말 중요하다고 생각해요. 머릿속에서 트레이드오프를 상상하며 야심찬 시도를 포기할 수도 있지만, 그냥 야심찬 도전을 해보는 방법도 있어요. 저희는 자주 묻거든요. "그냥 해버리면 어떨까? 이게 진짜 트레이드오프인가, 아닌가? 그렇다면 왜 — 이게 실제 트레이드오프라는 증거가 어디 있나, 그냥 그럴듯하게 들리는 것은 아닌가?" 트레이드오프가 있다면 직접 드러나게 하세요. 최대한 야심차게 도전하세요.
이 질문도 빠트릴 수 없었습니다.
Simon: Claude로 만들 수 있으니까 만들어본 가장 엉뚱한 것 하나씩 얘기해주실 수 있나요?
Thariq: 지금 저 자신을 캐릭터로 한 2D 스트리트 파이터 격투 게임을 만들고 있어요. 친구들도 캐릭터로 넣고요. Claude Code를 써서 Gemini에 프롬프트를 보내는 방식인데, Seedance 모델이 꽤 좋더라고요. 동영상 애니메이션을 만들거든요. 정말 잘 돼요. 프롬프팅을 기가 막히게 잘하고, 애니메이션이 괜찮은지 프레임을 직접 확인해주기도 해요.
Simon: 스트리트 파이터 2 수준의 2D 스프라이트를 생성하는 건가요?
Thariq: 맞아요, 2D 스프라이트예요. 애니메이션도 정말 멋져요. 히트박스도 잡을 수 있는데, "주먹이 여기 있으니까 JSON 히트박스를 이렇게 그릴게요"라고 하더라고요. 정말 놀랍습니다.
Cat: 제 건 훨씬 단순한데요. 저는 암벽등반을 좋아하고 친구들도 많이 타서, Claude Code로 모두가 작업 중인 프로젝트를 기록하는 작은 앱을 만들었어요. 야외 등반도 자주 같이 가는데, Claude에 워크플로우로 리서치를 다 시킵니다. 워크플로우가 정말 대단한 게, 저희는 코딩 도구로 포지셔닝하지만 여행 리서치에도 놀라울 정도로 잘 맞아요. 팀 오프사이트 기획도 하는데, 팀원 전체가 들어갈 수 있는 장소를 찾는 데도 잘 써요. 워크플로우로 우리가 가고 싶은 등반지를 리서치하고, 우리가 있는 곳에서 직항으로 갈 수 있는 곳도 찾아줘요. Mountain Project에서 우리 수준에 맞는 루트도 다 찾고, Airbnb도 찾아줘요. 저는 하이킹을 별로 좋아하지 않아서 주차장에서 암벽까지 거리가 짧아야 하거든요. 차를 세우고 나서 실제 암벽까지 걸어가는 거리 기준으로 필터링을 해줘요. 기존 앱은 Mountain Project를 일일이 클릭해야 하는데, 이 앱은 저희 모든 선호 조건을 넣으면 우리만을 위한 맞춤 앱이 되는 거예요.
Simon: 암벽등반을 위한 Jira를 바이브 코딩하는 거군요.
Cat: 딱 맞는 표현이에요.
마지막 몇 분은 청중 질문을 받았습니다.
청중: 평가 데이터셋을 구축하기 위한 평가 도구와, 에이전트 및 워크플로우 성능을 모니터링하기 위한 옵저버빌리티 도구를 가까운 시일 내에 만들 계획이 있나요?
Cat: 평가 도구를 만드는 것도 고려했지만, 실제 제약은 고품질 평가를 만드는 데 고객들이 많은 시간을 써야 한다는 것입니다. 그래서 툴링보다는 좋은 평가를 어떻게 만드는지에 대한 역량이 더 중요한 제약이라고 봐요. 내부적으로도 투자하고, 외부적으로도 모범 사례를 공유하는 방향으로 가고 싶은 영역입니다.
청중(Sai): 메모리와 멀티플레이어에 관심이 있는데요. 메모리는 현재 어떻게 설계되어 있나요? 파일 기반인 것 같은데요. 그리고 확장성을 높이기 위해 파일이 아닌 데이터 스토어로 메모리를 관리하는 방향도 고려하고 있나요?
Thariq: 현재 Claude Tag의 메모리는 채널 단위입니다. 해당 채널의 모든 Claude 인스턴스가 공유 메모리를 갖고, 각 인스턴스는 세션을 갖는데 세션이 메인 메모리에 기여하는 구조예요. 메모리 리서치를 많이 하고 있는데, 어떤 방식이 맞는 메모리 방식인지 꽤 직관에 반하는 부분이 있어요. 항상 메모리 실험을 진행 중이에요. 현재 Claude Tag에서는 채널별 마크다운 파일 하나로 메모리를 관리합니다.
이 블로그의 장문 아티클만 보고 계신 분들을 위해 안내드립니다. 모든 포스트를 받아보시려면 /atom/everything/을 구독하거나, 다른 구독 옵션을 확인해보세요.
