Simon Willison in conversation with Cat Wu & Thariq Shihipar, Anthropic

📺 원본 영상: Simon Willison in conversation with Cat Wu & Thariq Shihipar, Anthropic
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-16
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료, 차트, 코드, 슬라이드 등은 포함되지 않을 수 있습니다.


개요

이 대담은 Simon Willison이 Anthropic의 Cat Wu와 Thariq Shihipar를 초대해 Claude Code, Claude Tag, Fable, Auto Mode, 평가 체계(Evals), 코드 리뷰 자동화, 그리고 AI 에이전트 시대의 엔지니어링 문화 변화를 묻는 형식으로 진행된다. 핵심 주제는 단순히 “AI가 코드를 잘 쓴다”가 아니라, 코딩 에이전트가 실제 제품 조직의 작업 방식, 우선순위 판단, 보안 모델, 팀 협업 구조를 어떻게 재편하고 있는가에 있다.

대담 전반에서 Anthropic 측은 Claude Code가 개인 개발 도구에서 팀 단위의 협업 에이전트로 진화하고 있으며, Claude Tag는 그 방향을 보여주는 내부 운영 모델이라고 설명한다. 특히 제품 엔지니어링 PR의 상당 부분을 Claude Tag가 처리하고 있다는 언급은, AI 코딩 도구가 보조 도구를 넘어 조직의 생산 시스템 일부가 되고 있음을 보여준다.


코딩 에이전트가 바꾼 엔지니어의 하루

Claude Code가 처음 등장했을 때의 사용 경험은 지금과 상당히 달랐다. Cat Wu는 초기 Claude Code와 Sonnet 3.7 시절에는 사용자가 권한 요청을 하나하나 읽고, 파일을 제대로 확인했는지 계속 되묻고, 모델의 행동을 촘촘히 감시해야 했다고 회상한다. 그러나 모델 세대가 바뀌면서 사용자는 점점 더 뒤로 물러나고, 세부 구현의 상당 부분을 Claude에게 위임할 수 있게 되었다. 이 변화는 단순한 속도 향상이 아니라, 엔지니어가 자신의 시간을 어디에 써야 하는지에 대한 기준 자체를 바꾼다.

Thariq Shihipar 역시 비슷한 변화를 말한다. 그는 Opus 4가 나왔을 때 Claude Code를 처음 써보고 Anthropic에서 일해야겠다고 느꼈다고 말하면서도, 당시에는 여전히 권한 프롬프트를 계속 승인해야 하는 경험이었다고 설명한다. 지금은 Auto Mode가 너무 자연스러워져서 예전의 수동 승인 흐름을 거의 잊어버릴 정도가 되었고, Fable 이후에는 더 빠른 시간 안에 더 높은 품질의 결과물을 요구하게 되었다. 즉 도구가 쉬워진 만큼 일이 쉬워진 것이 아니라, 팀과 개인이 감당할 수 있는 야심의 크기가 커진 것이다.

Simon Willison은 이 지점을 “소프트웨어 엔지니어링이 더 어려워졌다”고 표현한다. 이전에는 시간과 구현 비용이 자연스러운 제약으로 작동했지만, 이제는 도구가 그 제약을 낮추기 때문에 더 크고 복잡한 문제를 선택하게 된다. 따라서 코딩 에이전트 시대의 개발자는 더 적게 일하는 사람이 아니라, 더 높은 기대치를 감당해야 하는 사람이 된다.


실행력보다 중요해진 제품 감각과 비즈니스 감각

Cat Wu가 가장 강하게 짚은 변화는 엔지니어링 스킬셋의 중심 이동이다. 과거에는 제품 매니저가 여러 달 동안 고객을 만나고, cross-functional 팀과 조율하고, PRD와 엔지니어링 문서를 작성한 뒤에야 첫 번째 코드가 쓰이는 방식이 일반적이었다. 그러나 아이디어에서 구현까지의 시간이 6개월에서 12개월이 아니라 일주일 수준으로 줄어들면, 더 중요한 질문은 “어떻게 만들 것인가”가 아니라 “무엇을 만들 가치가 있는가”가 된다.

이 변화는 제품 엔지니어에게 실행력보다 판단력을 요구한다. Claude Code와 같은 도구가 구현의 많은 부분을 담당할 수 있다면, 인간 엔지니어의 차별성은 좋은 문제를 고르고, 사용자의 진짜 필요를 이해하며, 비즈니스에 실제 영향을 주는 기능을 식별하는 데서 나온다. Cat은 인프라 영역처럼 세부 정확성이 여전히 매우 중요한 분야가 있음을 인정하면서도, 많은 제품 엔지니어링 영역에서는 제품 감각과 비즈니스 감각의 가치가 상승했다고 본다.

Thariq은 여기에 “리라이트가 이제 괜찮은 선택지가 되었다”는 도발적인 관점을 더한다. 전통적인 소프트웨어 공학에서는 재작성(rewrite)이 위험한 선택으로 여겨졌고, “절대 다시 쓰지 말라”는 교훈이 널리 공유되었다. 그러나 좋은 테스트 스위트가 있다면, 기존 코드베이스를 일종의 스펙으로 보고 여러 구현을 빠르게 만들어 비교하는 방식이 가능해진다. 이때 코드베이스는 단순한 구현물이 아니라, 조직이 보유한 유일한 사양서로 기능한다.


Claude Tag와 팀 단위 AI 협업의 등장

대담에서 가장 중요한 제품적 전환점은 Claude Tag다. Cat Wu는 Claude Tag를 팀 협업 도구 안에 존재하는 Claude Code의 진화형으로 설명한다. Slack 채널에 Claude Tag를 추가하면 팀원들이 함께 대화에 참여하고, 같은 PR을 두고 Claude와 협업할 수 있다. 이는 개인이 터미널에서 Claude Code를 실행하는 방식과 다르게, 처음부터 multiplayer 환경을 전제로 한다.

Claude Tag의 또 다른 특징은 반응형이 아니라 선제적이라는 점이다. 사용자가 “이 채널의 모든 버그 리포트를 모니터링하고, 수정 PR을 올린 뒤, 해당 코드 영역을 마지막으로 만진 엔지니어를 태그하라”고 지시하면 Claude Tag는 채널의 생애 동안 그 작업을 계속 수행할 수 있다. 여기서 AI 에이전트는 사용자가 매번 호출해야 하는 도구가 아니라, 팀의 흐름 안에서 지속적으로 관찰하고 행동하는 협업 구성원이 된다.

Cat은 Anthropic 내부 제품 엔지니어링 팀에서 Claude Tag가 현재 product engineering PR의 65%를 랜딩한다고 언급한다. 이 수치는 STT 기준으로 명확히 음성 언급된 수치이며, 전체 Anthropic이 아니라 product engineering team에 대한 수치로 한정된다. 이 대목은 Claude Tag가 단순한 실험적 Slack bot이 아니라, 내부 개발 프로세스의 큰 비중을 담당하는 운영 도구임을 보여준다.

Claude Tag가 Anthropic 내부 product engineering PR의 65%를 랜딩한다는 설명

07:59 - Claude Tag가 Anthropic 내부 product engineering PR의 65%를 랜딩한다는 설명


비개발자를 위한 Claude Tag의 의미

Claude Tag는 코드 작성뿐 아니라 조직 내 검색과 맥락 이해 도구로도 쓰인다. Thariq은 대담 전에 Fable 출시 시점을 확인하기 위해 Claude Tag에게 Slack을 검색하게 했다고 설명한다. 회사 내부의 대화, 제품 맥락, 지표 데이터, 코드베이스를 함께 읽을 수 있다면 Claude Tag는 단순한 검색 엔진을 넘어 회사의 운영 기억에 접근하는 인터페이스가 된다.

마케팅 팀의 사례도 흥미롭다. 비개발자가 특정 기능에 대해 물으면 Claude는 코드베이스를 clone하고, 기능이 무엇인지 설명하며, 직접 사용해본 녹화까지 제공할 수 있다. 이는 조직 내에서 “코드를 읽을 수 있는 사람”과 “제품 메시지를 만들어야 하는 사람” 사이의 장벽을 낮춘다. 비개발자는 프로그래밍 지식이 없어도 코드 기반 제품의 실제 동작을 이해할 수 있고, 개발자는 반복적인 설명 부담을 줄일 수 있다.

이 흐름에서 Claude Tag는 단순히 개발자 생산성을 높이는 도구가 아니라, 조직의 정보 접근 방식을 바꾸는 도구로 보인다. 기존에는 문서, 회의, 담당자 질문이 지식 전달의 주요 경로였다면, 이제는 에이전트가 Slack, 코드베이스, 이벤트 스토어, 내부 문서를 넘나들며 필요한 맥락을 구성한다. 다만 이러한 능력은 동시에 보안과 권한 관리 문제를 훨씬 더 중요하게 만든다.


Dogfooding, 유지율, 그리고 무엇을 출시할 것인가

기능을 만드는 비용이 낮아지면 우선순위 결정은 더 어려워진다. Cat은 Anthropic이 이 문제를 해결하는 방식으로 강한 dogfooding 문화를 설명한다. 내부에서 제품을 매일 사용하고, 제품으로 해결할 수 없는 문제가 나타나면 다른 도구를 찾기보다 제품을 고쳐서 그 사용 사례를 지원하게 만든다는 것이다. 이는 제품 조직이 사용자의 문제를 추상적으로 상상하는 대신, 자기 자신의 작업 흐름에서 직접 마찰을 느끼고 해결하는 방식이다.

Anthropic은 전 세계 사용자에게 기능을 공개하기 전에 내부 구성원과 일부 초기 고객에게 먼저 공유하고, 매우 솔직한 피드백을 받는다고 한다. Cat은 “더 혹독할수록 좋다”는 취지로 말하며, 사람들이 진짜로 좋아할 때까지 반복한다고 설명한다. 또한 기능이 공개되기 전에 일정 수준의 활성 사용자와 유지율(retention)을 달성해야 한다는 내부 기준이 있다고 말한다. 이 기준이 명확하기 때문에 엔지니어는 단순히 기능을 끝내는 것이 아니라, 사람들이 계속 쓰는 수준의 polish를 목표로 삼게 된다.

Remote Control 기능 사례는 이 접근법의 장점을 보여준다. Cat은 처음에는 모바일이나 웹에서 로컬 CLI Claude Code 세션에 연결하는 기능의 필요성을 잘 이해하지 못했다고 한다. 그러나 실제로 배포해보니 많은 사용자가 노트북을 충전기에 꽂아두고, 여러 Remote Control 세션을 열어둔 채, 소파에서 휴대폰으로 Claude Code를 조작하는 흐름을 만들었다. 내부자의 직관으로는 과소평가했던 사용 사례가 실제 사용을 통해 중요한 제품 방향으로 확인된 것이다.

Remote Control 기능을 사용해 모바일에서 로컬 Claude Code 세션을 제어하는 실제 사용 흐름

13:57 - Remote Control 기능을 사용해 모바일에서 로컬 Claude Code 세션을 제어하는 실제 사용 흐름


코드 리뷰의 자동화와 인간 검토의 재배치

Simon은 모든 production code를 인간이 한 줄씩 리뷰하는지 묻는다. Thariq은 중요한 영역에는 code owner가 있고, 해당 영역을 건드리는 PR은 반드시 해당 책임자의 승인을 받아야 한다고 설명한다. 특히 system prompt처럼 핵심 영역은 코드 오너의 책임과 승인이 중요하다. 그러나 모든 변경이 같은 수준의 인간 검토를 필요로 하는 것은 아니며, Anthropic은 점점 더 많은 외곽 영역의 변경을 Claude Code의 코드 리뷰에 맡기고 있다.

Cat은 인간을 코드 리뷰 루프에서 제거하는 것은 무서워 보일 수 있지만, 6개월 이상의 점진적 과정을 통해 신뢰를 쌓아왔다고 설명한다. 처음에는 모든 변경을 사람이 리뷰하고, 이후 특정 파일과 변경 유형에서 Claude Code review가 문제를 100% 잡아낸다는 근거가 쌓이면 인간 리뷰를 줄이는 방식이다. 사고가 발생하면 그 원인이 된 PR을 분석하고, code review가 이를 잡도록 업데이트하며, 해당 PR을 eval set에 추가해 이후 code review 변경이 같은 문제를 다시 놓치지 않도록 만든다.

사고를 유발한 PR을 eval set에 추가해 code review 회귀를 막는 절차

16:48 - 사고를 유발한 PR을 eval set에 추가해 code review 회귀를 막는 절차

이 접근은 AI 코드 리뷰를 믿음의 문제가 아니라 계측과 회귀 방지의 문제로 다룬다는 점에서 중요하다. Anthropic은 “모델이 똑똑하니 괜찮다”가 아니라, 실제 사고 사례와 PR 데이터를 평가 세트로 축적하고, 새로운 모델이나 코드 리뷰 변경이 기존 안전 기준을 후퇴시키지 않는지 확인한다. 인간 검토는 사라지는 것이 아니라, 더 위험하고 핵심적인 영역에 집중되는 방향으로 재배치된다.


Evals는 모델 교체와 제품 신뢰의 기반이다

새 모델이 나왔을 때 사용자가 가장 어려워하는 것은 신뢰의 재구축이다. Simon은 Opus 4.8에게 SQL 쿼리 기반 JSON endpoint를 만들라고 하면 이제는 제대로 할 것이라고 믿지만, Fable 같은 새 모델이 같은 작업을 망치지 않는지 빠르게 판단하기 어렵다고 말한다. Cat은 바로 이 문제 때문에 시간이 지날수록 eval 기반을 구축한다고 설명한다. 새 모델이 나오면 전체 eval set을 돌리고, 예를 들어 Fable이 Opus 4.8보다 명확히 더 낫다는 근거가 있어야 drop-in replacement로 사용할 수 있다.

Anthropic에는 회사 전체 모델 평가와 Claude Code 팀 고유의 평가가 모두 존재한다. Claude Code 팀은 Anthropic 내부의 여러 repo에 대해 code review를 실행하며, Auto Mode처럼 보안과 관련된 기능에 대해서는 내부 사용자 데이터뿐 아니라 외부 red teamer에게 prompt injection과 malicious input이 포함된 환경을 만들게 해 검증한다. 이는 제품별 eval이 일반 모델 벤치마크와 다르게, 실제 사용 맥락에 깊이 묶여 있어야 함을 보여준다.

Cat은 system prompt 개선이 실제 제품을 개선했는지 완전히 확신할 수는 없지만, 회귀를 막기 위해 많은 일을 한다고 말한다. 출발점은 외부 eval과 내부 eval이며, 주로 capability를 최적화한다. 즉 완전한 task definition과 전체 codebase가 주어졌을 때 Claude가 올바른 결정을 내리고, 버그를 완전히 고치며, 테스트를 통과하는지를 본다. 이후에는 “잠자러 갈 시간입니다” 같은 부적절한 응답이나, 이미 이어서 해야 할 일을 사용자에게 다시 물어보는 행동처럼 사용자가 싫어하는 행동을 behavioral eval로 축적해간다.


System Prompt 80% 축소가 의미하는 것

Thariq은 Claude Code의 system prompt가 Fable뿐 아니라 Opus 4.8 이후의 frontier model을 대상으로 크게 줄었다고 설명한다. STT 기준으로 “80% 감소”라는 표현이 등장하며, 이 감소는 모든 모델에 적용되는 것이 아니라 가장 앞선 모델에 한정된다. 더 오래된 모델은 여전히 더 긴 system prompt를 사용한다. 이는 모델의 판단력이 향상될수록, 명령을 많이 주입하는 방식보다 맥락과 목표를 더 부드럽게 제공하는 방식이 효과적일 수 있음을 시사한다.

흥미로운 대목은 예시(example)를 줄인 것이 오히려 도움이 되었다는 설명이다. 기존 프롬프트 엔지니어링에서는 예시를 제공하는 것이 가장 강력한 방법 중 하나로 여겨졌지만, Thariq은 일부 최신 모델에서는 예시가 모델의 창의성과 판단을 과도하게 제한할 수 있다고 말한다. 또한 “하지 말라”는 hard constraint가 많아질수록 이후 사용자 지시나 skill 지시와 충돌해 모델을 혼란스럽게 만들 수 있기 때문에, Anthropic은 더 많은 맥락과 더 적은 절대 명령으로 이동하고 있다.

Claude Code system prompt를 줄이고 hard constraint보다 맥락을 제공하는 방향으로 바꾼 이유

22:56 - Claude Code system prompt를 줄이고 hard constraint보다 맥락을 제공하는 방향으로 바꾼 이유

Cat은 좋은 system prompt를 만들 때 각 지시가 정말 100% 항상 참인지 확인해야 한다고 강조한다. 예를 들어 “frontend 변경을 하면 항상 verify하라”는 지시는 대체로 맞지만, 단순 copy 변경과 테스트 업데이트만 요청한 경우에는 과할 수 있다. 그래서 prompt는 “대부분의 경우 사용자 경험 변경은 backend endpoint만 호출해서는 충분히 이해하기 어렵기 때문에, 의미 있는 UX 변경을 했다면 로컬에서 앱을 실행해 확인하라”처럼 더 정확한 조건을 담아야 한다. 모델에게 100%의 시간 동안 주입되는 지시라면, 그 지시 자체도 가능한 한 100% 정확해야 한다는 것이다.


도구 설계는 과학이면서 생물학에 가깝다

Claude Code는 다양한 도구의 조합으로 작동하지만, Anthropic은 도구 수를 무작정 늘리기보다 cardinality를 낮게 유지하려 한다. Cat은 새 도구가 추가될 때마다 Claude가 언제 어떤 도구를 호출해야 하는지 더 쉽게 구분할 수 있어야 하며, 각 도구는 다른 도구와 명확히 다른 기능을 가져야 한다고 설명한다. 이는 AI 에이전트의 도구 설계가 전통적인 API 설계와 비슷하면서도, 모델이 혼동하지 않도록 인지적 경계를 만들어야 한다는 점에서 다르다.

파일 편집 도구의 존재 이유도 단순한 기능성 때문만은 아니다. Cat은 전용 file edit tool이 있으면 Claude가 파일을 변경한다는 사실을 deterministic하게 알 수 있고, 사용자에게 “이 파일 편집을 승인하겠는가”라는 전용 UI를 보여줄 수 있다고 설명한다. 특히 신규 사용자는 이 승인 UI를 통해 모델의 변경을 이해하고 신뢰를 쌓는다. 반면 Auto Mode를 쓰는 숙련 사용자에게는 전용 file edit tool이 덜 중요할 수 있으며, 이론적으로는 bash 기반 편집만으로도 충분할 수 있다.

Thariq은 tool design을 물리학보다 생물학에 가깝다고 표현한다. 이는 특정 원리만으로 예측 가능한 시스템이 아니라, 모델의 행동과 도구의 형태가 상호작용하면서 실험적으로 최적화되는 영역이라는 뜻이다. Eval이 중요하지만, 어떤 도구가 실제로 모델의 행동을 더 좋게 만드는지는 dogfooding과 관찰을 통해 드러나는 경우가 많다.


Auto Mode와 보안 모델의 재구성

Simon은 prompt injection 위험을 잘 알면서도 YOLO mode를 자주 써왔고, 최근 Auto Mode를 기본으로 쓰기 시작했다고 말한다. 이에 Cat은 Anthropic 내부에서는 거의 모든 사람이 Auto Mode를 사용한다고 답한다. Auto Mode는 Claude Code에서 long-running work를 안전하게 수행하는 가장 좋은 방식으로 간주되며, Anthropic은 수천 개의 eval과 외부 red teamer의 공격 환경을 통해 이를 강화해왔다고 설명한다.

Auto Mode의 핵심은 단순한 allowlist나 denylist가 아니라, 사용자의 요청과 대화 맥락을 함께 판단하는 classifier에 있다. Thariq은 Claude가 turn이나 bash call을 수행할 때, Sonnet classifier가 도구 호출과 대화 맥락, 사용자의 지시를 보고 판단한다고 설명한다. 예를 들어 사용자가 “GitHub에 push하라”고 명시했다면 push 권한을 허용해야 하지만, “push하지 말라”고 했다면 Claude가 능동적으로 push하려 해도 이를 막아야 한다. Auto Mode는 바로 이런 동적 권한 판단을 수행한다.

Auto Mode가 사용자 지시, 권한, sandbox, 네트워크 요청을 동적으로 판단하는 방식

33:39 - Auto Mode가 사용자 지시, 권한, sandbox, 네트워크 요청을 동적으로 판단하는 방식

또한 Auto Mode는 sandboxing infrastructure와도 상호작용한다. 네트워크 요청처럼 sandbox를 벗어나는 행동이 필요할 때, Auto Mode가 해당 요청이 맥락상 타당한지 판단해 허용 여부를 결정한다. Cat은 Auto Mode가 prompt injection, data exfiltration 같은 주요 위험 범주에 대해 평균적인 인간 리뷰어보다 낮은 위험을 제공한다고 말하지만, 동시에 100%를 잡는다는 주장은 하지 않는다. 이 균형 잡힌 표현은 AI 보안을 완전한 보증이 아니라 계층적 방어와 지속적 평가의 문제로 보는 Anthropic의 접근을 보여준다.


Claude Tag 보안과 권한 분리

Claude Tag는 Slack 같은 협업 공간에서 여러 사람의 입력을 받기 때문에 공격 표면이 더 넓다. Thariq은 자체 AI Slackbot을 만드는 것에 신중해야 한다고 말하며, 피드백 채널에 사용자가 올린 메시지를 bot이 읽는 순간 prompt injection의 경로가 생긴다고 지적한다. Claude Tag가 작동하려면 Auto Mode와 같은 보안 기반이 매우 중요하며, Anthropic은 이를 여러 겹의 방어 구조로 접근하고 있다고 설명한다.

Cat은 Claude Tag에서 Claude가 사용자를 대신해 행동하지 않도록 자체 credentials를 provision할 수 있다고 말한다. 이렇게 하면 Claude가 별도의 identity를 갖게 되고, 어떤 작업을 했는지 audit하고 inspect하기 쉬워진다. 이는 AI 에이전트가 조직 안에서 실제 작업 주체로 행동할 때 필요한 중요한 설계다. 사람의 권한을 빌려 쓰는 모델보다, 독립된 신원을 가진 에이전트가 더 추적 가능하고 제한 가능하기 때문이다.

Remote environment에서는 credential injection도 지원된다. 예를 들어 Claude Code가 Datadog에 접근해야 하지만 Datadog credential 자체를 Claude에게 노출하고 싶지 않은 경우, identity credential management system이 요청 시점에 필요한 credential을 삽입한다. Simon은 이를 proxy가 특정 API 호출에 실제 token을 대체 삽입하는 패턴으로 이해하며, 이 방식이 여러 곳에서 사용되는 “명백히 옳은” 패턴처럼 느껴진다고 말한다.


AI 시대의 상실감과 더 큰 야심

대담 후반부는 기술보다 인간의 역할 변화에 초점을 맞춘다. Simon은 많은 사람이 소프트웨어를 만드는 과정에서 자신이 가치 있다고 여겼던 역할이 모델에 흡수되는 상실감을 느끼고 있다고 말한다. Thariq은 그 감정이 실제라고 인정한다. 이전에 하던 일을 그대로 하되 이제 prompt 하나로 끝난다면, 그 경험은 허전하고 슬플 수 있다.

그가 제안하는 대응은 더 큰 야심이다. 같은 일을 더 빠르게 하는 데 머무르지 않고, 이전에는 너무 크거나 오래 걸려서 시도하지 못했던 일을 해야 한다는 것이다. 그는 Bun을 만든 Jarred의 사례를 언급하며, 직접 Zig 코드를 작성하던 사람이 이제 Bun을 Rust로 재작성하는 더 큰 작업을 즐겁게 수행하는 모습을 예로 든다. 핵심은 AI가 기존 작업의 일부를 대신할 때, 인간은 그 빈자리를 더 큰 문제 설정과 더 넓은 창작으로 채워야 한다는 관점이다.

Cat은 product management도 매달 역할이 바뀌고 있다고 말한다. PM은 엔지니어, 디자이너, 제품 담당자의 혼합처럼 움직이며, 좋은 아이디어와 고객 전달 사이에 생기는 gap을 찾아 메우는 역할을 한다. 엔지니어가 아직 영감을 받지 못한 아이디어가 있다면 PM이 직접 prototype을 만들고, 디자인이 어색하면 유사한 페이지를 바탕으로 first pass design을 만든 뒤 디테일에 강한 사람을 태그한다. 이때 PM의 일은 “요구사항을 전달하는 사람”이 아니라, 조직의 병목을 찾아 자동화하고 연결하는 사람에 가까워진다.


Fable이 보여준 멀티모달 작업의 가능성

Thariq이 가장 놀라운 사례로 든 것은 Claude를 이용한 영상 편집이다. 그는 ACM agentic conference에서 발표한 뒤, 편집된 영상을 기다리기 어렵자 원본 발표 영상, 슬라이드 영상, 오디오 파일, HTML deck을 Claude에게 제공하고 편집을 요청했다고 설명한다. Claude는 전체 영상을 transcribe하고, deck 영상 중간에 auto update popup이 뜨는 문제를 발견한 뒤, 해당 영상을 그대로 쓰는 대신 HTML source를 이용해 슬라이드를 재구성하는 전략을 선택했다.

Fable이 발표 영상, HTML deck, 오디오를 결합해 자동 영상 편집을 수행한 사례

42:56 - Fable이 발표 영상, HTML deck, 오디오를 결합해 자동 영상 편집을 수행한 사례

이후 Claude는 발표자가 어느 슬라이드에서 무엇을 말하는지 파악하고, 무대 위 발표자의 위치를 동적으로 crop하며, pacing에 맞춰 발표자 영상과 deck, 자막을 조합했다. Thariq은 이 작업이 Fable로 이루어졌고, one-shot prompt였다고 말한다. 또한 ffmpeg와 Remotion 같은 도구를 활용해 animation과 graphics를 추가했다고 설명한다. 이 사례는 coding agent가 단순한 코드 작성기를 넘어, 파일 시스템, 영상 처리 도구, HTML source, transcript를 연결하는 작업 orchestrator로 움직일 수 있음을 보여준다.

그러나 Cat은 여전히 부족한 점으로 design과 UX taste를 꼽는다. 상세한 기능 spec을 주면 기능적으로는 잘 구현하지만, padding이나 interface의 세련됨, frontier AI product에 맞는 새로운 interaction design은 아직 충분히 만족스럽지 않다는 것이다. Simon 역시 “Opus aesthetic”처럼 모델이 만든 결과물 특유의 시각적 패턴을 알아볼 수 있다고 말한다. 이는 AI가 구현 능력에서는 급격히 발전했지만, 제품의 감각과 경험 설계에서는 여전히 인간의 판단이 강하게 필요한 영역이 남아 있음을 보여준다.


Anthropic 문화에서 배울 수 있는 것

Cat은 Claude Tag가 잘 작동하려면 public channel 문화가 중요하다고 말한다. Claude Tag는 public channel 전체를 검색해 더 많은 맥락을 확보할 수 있을 때 가장 정확한 답변을 제공한다. 따라서 정보가 개인 DM이나 폐쇄 채널에 흩어져 있는 조직보다, 대부분의 업무 맥락이 공개 채널에 축적되는 조직에서 더 큰 가치를 낸다. AI 협업 도구의 성능은 모델 자체뿐 아니라 조직의 정보 구조에 의해 좌우된다.

Thariq은 Anthropic 공동창업자들이 말하는 “we don’t negotiate against ourselves”라는 문화를 강조한다. 이는 머릿속에서 미리 trade-off를 상상하고 스스로 야심찬 선택지를 포기하지 말라는 뜻이다. 예전 소프트웨어 경험은 모든 일에는 비용이 있고 기본 답은 no여야 한다는 직관을 만들었지만, 코딩 에이전트 시대에는 그 직관을 다시 점검해야 한다. 실제 trade-off인지, 아니면 그럴듯하게 들리는 과거의 습관인지 증거를 통해 확인해야 한다는 것이다.

이 문화는 단순한 낙관주의가 아니다. 앞서 설명된 eval, dogfooding, code owner, Auto Mode, credential injection 같은 장치가 함께 있을 때 야심은 무모함이 아니라 실험 가능한 전략이 된다. Anthropic의 메시지는 “무조건 크게 시도하라”가 아니라, 도구가 바꾼 비용 구조를 정확히 반영해 더 큰 시도를 하고, 그 위험은 평가와 보안 인프라로 관리하라는 쪽에 가깝다.


개인적이고 기묘한 도구들이 보여주는 미래

마지막 질문에서 Simon은 Claude로 만든 가장 absurd한 것을 묻는다. Thariq은 자신과 친구들을 캐릭터로 넣은 2D Street Fighter 스타일 게임을 만들고 있다고 답한다. Claude Code가 Gemini와 Veo 계열로 보이는 영상 생성 모델을 prompt하고, 2D sprite animation을 만들며, frame을 검증하고, hitbox를 JSON으로 그려낼 수 있다고 설명한다. 이 사례는 AI 도구가 개인 취미 프로젝트의 제작 난이도를 크게 낮추고 있음을 보여준다.

Cat의 사례는 더 실용적이다. 그는 암벽등반을 즐기며, 친구들과 함께 진행 중인 climbing project를 기록하는 작은 앱을 Claude Code로 만들었다고 말한다. 또한 Workflows를 이용해 여행지 후보를 조사하고, 직항편 여부, Mountain Project의 grade level, Airbnb, 접근 거리까지 분석하게 한다. 기존 앱에서는 사용자가 여러 사이트를 직접 클릭해야 했지만, Claude 기반 custom app에서는 개인과 그룹의 선호를 입력하면 맞춤형 조사와 필터링이 가능해진다.

Workflows를 이용해 암벽등반 여행지, 난이도, 숙소, 접근 거리까지 조사하는 개인용 앱 사례

48:32 - Workflows를 이용해 암벽등반 여행지, 난이도, 숙소, 접근 거리까지 조사하는 개인용 앱 사례

이 두 사례는 AI 코딩 도구의 미래가 반드시 대규모 SaaS나 기업 업무에만 있지 않음을 보여준다. 사용자는 자기 자신과 소수의 친구만을 위한 소프트웨어를 만들 수 있고, 그 소프트웨어는 기존 시장에서는 너무 작아서 제품화되지 않았던 요구를 만족시킨다. Simon이 이를 “mountain climbing을 위한 vibe coding Jira”라고 표현한 것은 농담이지만, 실제로는 개인화된 업무 시스템이 누구에게나 가능해지는 방향을 잘 포착한 말이다.


마무리 / 핵심 정리

이 대담의 핵심은 Claude Code와 Claude Tag가 코드 작성 도구를 넘어 조직 운영 체계로 진화하고 있다는 점이다. 개인 개발자는 Claude Code를 통해 더 빠르게 prototype을 만들고 더 큰 rewrite를 시도할 수 있으며, 팀은 Claude Tag를 통해 Slack, 코드베이스, PR, memory, metrics를 연결한 협업 흐름을 만들 수 있다. Anthropic 내부에서 Claude Tag가 product engineering PR의 65%를 랜딩한다는 언급은 이러한 변화가 이미 실험 단계를 넘어 실제 업무량을 흡수하고 있음을 보여준다.

그러나 이 변화는 인간의 역할을 제거하기보다 재배치한다. 구현의 일부가 자동화될수록 제품 감각, 비즈니스 감각, 보안 판단, 평가 체계 설계, 조직의 정보 구조가 더 중요해진다. 좋은 테스트 스위트와 eval set은 rewrite와 모델 교체를 가능하게 하고, Auto Mode와 credential injection은 장시간 자율 작업의 위험을 낮춘다. 결국 AI 에이전트 시대의 엔지니어링은 더 적은 코드 작성이 아니라, 더 높은 수준의 판단과 더 큰 야심을 요구하는 방향으로 이동하고 있다.


📚 출처 및 참고

구분내용
원본 영상Simon Willison in conversation with Cat Wu & Thariq Shihipar, Anthropic
채널AI Engineer
리포트 작성2026-07-16
작성 방식YouTube 영상 STT 변환 후 에디팅

💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.