Claude Code 팀의 Cat 및 Thariq과 함께한 Fireside Chat

2026년 7월 21일

이달 초, 저는 AI Engineer World’s Fair에서 Anthropic의 Claude Code 팀 소속인 Cat Wu 및 Thariq Shihipar와 함께 fireside chat (난로가 옆에서 나누는 대화) 세션을 진행했습니다. 우리는 Claude Code, Claude Tag, Fable, 코딩 에이전트 보안 (coding agent security), 평가 (evals), 도구 설계 (tool design), 그리고 Anthropic이 이러한 도구들을 어떻게 직접 사용하는지에 대해 이야기했습니다.

세션의 전체 영상은 현재 YouTube에서 시청할 수 있습니다. 아래는 추가 링크와 제가 굵게 표시한 강조 사항이 포함된 편집된 녹취록 사본입니다.

영상을 시청하거나 전체 녹취록을 읽고 싶지 않은 분들을 위한 몇 가지 주요 요약 사항입니다:

• Claude Tag (Claude의 새로운 협업용 Slack 연동 기능)가 출시되었습니다.
• Claude Code 팀을 위한 **제품 엔지니어링 PR (Pull Requests)의 65%**를 처리합니다.
• Claude Code는 Anthropic 직원들에게 기능을 먼저 출시하며, 해당 집단에서 사용자 유지율 (user retention)을 입증한 기능만을 출시합니다.
• Claude Code의 중요한 변경 사항은 여전히 수동으로 검토되지만, 팀은 제품의 "외부 계층 (outer layers)"에 대해 자동 코드 리뷰 (automated code review)에 점점 더 의존하고 있습니다.
• 시스템 프롬프트 (system prompt)에 예시를 추가하는 것은 Fable 5나 심지어 Opus 4.8과 같은 모델들에게는 더 이상 권장되는 모범 사례 (best practice)가 아닙니다. Claude Code의 시스템 프롬프트는 최근 크기가 80% 감소했습니다.
• 마찬가지로, "X를 하지 말고 Y도 하지 마시오"와 같은 목록은 최신 모델의 결과 품질을 저하시킬 수 있습니다.
• Anthropic 내부에서의 도그푸딩 (Dogfooding, 자사 제품 직접 사용)은 "ant fooding"이라고 불립니다.
• Anthropic은 자사의 오토 모드 (auto mode)를 진심으로 신뢰하며, 이를 Claude Tag를 가능하게 하는 핵심 기술로 보고 있습니다.
• Thariq는 코딩 에이전트로 인해 유발되는 Deep Blue (인지적 무기력)를 상쇄하기 위해, 맡은 업무에 대해 "더 야심차게 임할 것"을 조언합니다.
• Fable은 비디오 편집에 능숙하며, Thariq는 이를 사용하여 Fable의 출시 영상을 직접 편집했습니다.
• Anthropic이 공개 Slack 채널에서 Claude Tag를 사용하는 방식에서 볼 수 있듯이, (내부적으로) 공개적으로 작업하는 Anthropic의 문화가 그들의 성공의 핵심입니다.

지난 1년 동안 여러분의 일상적인 업무는 어떻게 변했나요?

Simon: Claude Code는 작년 2월에 출시되었습니다. 출시된 지 채 1년 반도 되지 않았고, 원래는 Claude Sonnet 3.7 출시 당시의 단순한 불렛 포인트(bullet point) 중 하나였을 뿐이었죠. 실제로 우리를 위해 작동하는 이러한 코딩 에이전트(coding agents)들이 생겨난 지금, 지난 1년 동안 여러분의 일상적인 업무는 어떻게 변했나요?

Cat: Claude Code와 Sonnet 3.7이 처음 나왔을 때가 기억나네요. 당시에는 작업을 하나 주면 모델이 시도하는 아주 작은 부분 하나하나를 밀착 모니터링해야 했습니다. 모든 권한 요청 프롬프트(permission prompt)를 극도로 주의 깊게 읽어야 했죠. 저는 자주 안 된다고 말하곤 했습니다. "아니, 아니, 아니, 이 파일 확인했어? 저 파일은 확인했어?"라고 말이죠. 하지만 이제는 모델 세대(model generation)가 거듭될수록 놀라운 변화를 느끼고 있습니다. 우리 모두가 한 걸음 뒤로 물러나, 훨씬 더 많은 단순 구현(menial implementation) 작업을 Claude에게 위임할 기회를 얻었다고 느낍니다. 덕분에 Claude Code가 많은 부분을 구현할 수 있다는 것을 알게 된 지금, "우리가 사용자에게 제공해야 할 올바른 경험은 무엇인가?"와 같은 더 창의적인 업무를 생각할 수 있는 시간을 많이 확보할 수 있었습니다. 그리고 이제 Fable과 함께하면서 완전히 다른 차원의 비약적인 향상을 이루었습니다. 우리의 많은 유스케이스(use cases)를 보면, 이제 Fable을 통해 수많은 기능을 실제로 원샷(one-shot)으로 구현할 수 있다는 것을 알 수 있습니다.

Thariq: Claude Code에 대해 처음 들었던 메시지가 기억납니다. 제 가장 친한 친구 중 한 명이 "너 Claude Code 꼭 써봐야 해"라고 말했죠. Opus 4가 출시되었을 때쯤이었는데, 직접 써보고는 "와, 대박. 나 이제 Anthropic에서 일해야겠어"라고 생각했습니다. 그때가 Opus 4 시절이었죠. 훌륭한 모델이었지만, 당시에는 권한 승인 프롬프트(permission prompts)를 일일이 읽어야 했습니다. 우리가 얼마나 건망증이 심한지 참 신기할 정도예요. 저는 마치 '자동 모드(auto mode)는 항상 여기에 있었던 거 아니야?'라고 생각하거든요. '예(yes)'를 누르고 '허용(allow)'을 했던 기억조차 나지 않습니다. 제가 스스로를 몰아붙이려고 노력하는 큰 부분은, 우리가 이전보다 훨씬 더 높은 품질의 작업을 수행해야 한다는 점입니다. 출력물(outputs)의 품질이 믿기지 않을 정도로 높습니다. 저는 이것을 사용해 영상을 편집하는 데 많이 활용하고 있는데, '좋아, 몇 시간 안에 우리 브랜드 팀의 매우 까다로운 요구 사항을 충족해야 해. 그렇지 않으면 우리는 해낼 수 없어'라고 생각하게 됩니다. 그것이 제가 Fable을 통해 변화시키고자 하는 방향입니다. 우리가 이전에 했던 것 중 가장 뛰어난 작업을, 이전보다 더 빠르게 해내는 것이죠.

기존의 소프트웨어 엔지니어링 중 더 이상 유효하지 않은 부분은 무엇인가요?

Simon: 1년 전에는 사실이었지만, 이 새로운 세상에서는 더 이상 유효하지 않다고 생각하는 기존의 소프트웨어 엔지니어링(conventional software engineering) 요소는 무엇인가요?

Cat: 우리가 엔지니어링 기술 세트(eng skill set)에서 목격하고 있는 가장 큰 변화 중 하나는 이렇습니다. 2년 전만 해도 프로덕트 매니저(PM)가 수많은 고객을 만나고, 6개월에 걸쳐 교차 기능 팀(cross-functional teams)과 협력하여 제품 요구 사항 문서(PRD)를 조율하며, 첫 번째 코드 한 줄을 쓰기 전에 이를 어떻게 구현할지에 대한 철저한 사양(spec)을 작성하는 것이 꽤 전형적이었습니다. 하지만 이제는 상황이 완전히 반대로 바뀌었습니다. 많은 엔지니어에게 제가 이 자리에 계신 분들께 드리고 싶은 조언은, 우리가 무엇을 만들어야 하는지에 대한 비즈니스 감각(business sense)과 프로덕트 감각(product sense)을 더 발전시키라는 것입니다. 아이디어를 내는 시점부터 이를 구축하기까지의 타임라인이 훨씬 짧아졌기 때문입니다. 기존 6~12개월에서 이제는 일주일 정도로 단축될 수도 있습니다. 이는 우리 모두가 무엇을 만들 가치가 있는지, 무엇이 우리가 일하는 비즈니스에 실제로 변곡점(inflect)을 만들어낼지에 대해 더 나은 안목(taste)을 가져야 함을 의미합니다. 즉, 대부분의 프로덕트 도메인에서는 프로덕트 안목과 비즈니스 감각의 가치는 높아진 반면, 실행(execution)의 가치는 다소 낮아졌습니다. 물론 인프라(infra) 분야에서는 여전히 모든 세부 사항이 정확한지 확인하는 것에 매우 큰 비중을 둡니다.

Thariq: 저에게는, 이제 재작성(rewrites)이 좋다는 점입니다.

Simon: 최악의 선택이었던 것이 이제는 실제로 괜찮아졌다는 거군요!

Thariq: 정확합니다. '절대 재작성하지 마라'와 같은 《맨먼스 신화(Mythical Man-Month)》의 모든 내용들 말이죠. 저는 이제 재작성을 찬성합니다. 좋은 테스트 스위트(test suite)를 갖추고 있다면 말입니다. 사실 재작성을 하면 좋은 테스트 스위트를 갖추도록 강제되는 측면도 있다고 생각합니다. 하지만 사람들이 과소평가하는 것은 코드베이스(codebase)가 곧 사양(spec)이라는 점입니다. 코드베이스의 모든 분기되는 부분을 아는 사람은 아무도 없기 때문에, 어쩌면 그것이 여러분이 가진 유일한 사양 복사본일지도 모릅니다. 여러분은 이것을 하나의 산출물(artifact)로 취급하여 정제하거나 다른 버전으로 만들 수 있습니다. 저희는 Bun을 Rust로 재작성했고 아주 잘 작동합니다. 현재 저에게는 라이브 상태입니다.

Simon: 아직 Claude Code를 Bun-in-Rust로 출시(shipping)한 건 아니죠?

Thariq: 내부적으로는 했습니다.

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

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

Simon: 최근의 또 다른 큰 출시는 Claude Tag였습니다. 적어도 우리에게는 출시된 지 일주일 정도 되었죠. Anthropic 내부의 비엔지니어들이 Claude Tag를 굉장히 많이 사용하고 있다고 알고 있습니다. 비엔지니어들은 Claude Tag로 어떤 일들을 하고 있나요?

Cat: Claude Tag는 팀의 협업 도구 내에 상주하는 Claude입니다. 저희는 지난주에 Slack 내에서 이를 출시했습니다. Claude Tag가 다른 점은 기본적으로 멀티플레이어 (multiplayer) 방식이라는 것입니다. Slack 채널에 Claude Tag를 추가하면, 당신이 의견을 낼 수 있고 팀원들도 의견을 낼 수 있으며, 함께 PR (Pull Request)에 대해 협업할 수 있습니다. 또 다른 큰 차이점은 반응형 (reactive)이 아닌 주도형 (proactive)이라는 점입니다. Claude Tag에게 "이 채널의 모든 버그 리포트를 모니터링하고, 이를 수정하기 위한 PR을 생성한 뒤, 코드베이스의 이 부분을 마지막으로 수정했던 엔지니어를 태그해줘"라고 말하면, 사용자가 수동으로 태그할 필요 없이 채널이 유지되는 동안 이를 수행합니다. 세 번째 큰 변화는 여기에 팀 메모리 (team memory)를 추가했다는 것입니다. 만약 채널에서 Claude Tag에게 당신의 선호도를 말해주면, Claude Tag는 향후 모든 포스트에 대해 이를 기억할 것입니다. 예를 들어, 장애 (outage) 상황은 항상 디버깅하되 경고 (warning) 상황은 디버깅하지 않기를 원한다면, 채널에서 자연어 (natural language)로 그렇게 말하기만 하면 됩니다. 그러면 Claude Tag는 당신과 팀의 다른 모든 구성원을 위해 이를 기억할 것입니다.

내부적으로 저희는 Claude Tag를 Claude Code의 진화로 보고 있습니다. 저희는 이를 내부 업무 방식의 큰 변화로 보고 있습니다. 현재 Claude Tag는 저희 제품 엔지니어링 PR의 65%를 처리하고 있습니다.

Simon: Anthropic 전체에 해당되는 이야기인가요, 아니면 Claude Code에만 해당되는 이야기인가요?

Cat: 이것은 저희 제품 엔지니어링 팀에만 해당되는 이야기입니다. 저희 내부 버전인 Claude Tag는 현재 제품 PR (Pull Request)의 65%를 처리하고 있습니다. 이는 엄청난 변화입니다. 저희 PR의 50%가 넘는 수치니까요. 저희가 보는 Claude Code와 Claude Tag 사이의 작업 분담 방식은 이렇습니다. Claude Code는 에이전트(Agent)와 상호작용하며 반복적으로 작업할 때, 즉 가장 복잡한 작업을 수행하기에 여전히 최적의 장소입니다. 하지만 Claude Tag는 사용자를 대신해 선제적으로(proactively) 작업하는 데 매우 유용합니다. 따라서 여러분이 작업 중인 기능에 대해 발생하는 모든 버그 리포트에 대해 더 이상 Claude Code를 수동으로 실행할 필요가 없습니다.

Thariq: 그리고 코딩 이외의 사례를 말씀드리자면, 예를 들어 이 대화 전에도 저희는 Claude Tag에게 "이봐, Fable은 언제 출시해?"라고 물어본 적이 있습니다. 저희는 발표 일정과 맞추고 싶었거든요. Claude Tag는 저희 Slack을 검색하여 누가 무엇을 말하고 있는지 확인했습니다. 기업을 위한 검색 엔진으로서 정말 가치가 높습니다. 제품에 대한 모든 컨텍스트 (Context)를 가지고 있기 때문에 지표(metrics) 관련 질문을 던질 수도 있습니다. 의사결정을 내릴 때 지표에 근거한 정보를 얻고 싶을 때가 많은데, 이때 Claude Tag를 이벤트 스토어 (event store)에 연결하면 됩니다. 저희 마케팅 팀이 "이 기능에 대해 알려줘"라고 요청하는 것을 본 적이 있습니다. 그들은 프로그래머가 아니지만, Claude는 프로그래머입니다. Claude는 코드베이스 (codebase)를 클론 (clone)하여 "이것이 해당 기능이고, 모습은 이렇습니다, 그리고 제가 이 기능을 사용하는 녹화 영상입니다"라고 말할 수 있습니다. 이는 매우 다양한 가능성을 열어주며, 저희는 아직 그 가능성을 파악해 나가는 초기 단계에 있다고 생각합니다.

팀 협업 레이어로서의 Claude Tag

Simon: 제가 코딩 에이전트(coding agents)를 사용하며 느꼈던 문제 중 하나는, 개인으로서 어떻게 사용하는지는 알겠지만 팀 환경에서 어떻게 활용해야 할지는 명확하지 않다는 점이었습니다. Claude Tag가 바로 이러한 팀 협업 레이어 (team collaborative layer)에 대한 현재의 해답인 것처럼 들리네요.

Cat: 정확합니다. 그리고 현재 저희 세션의 상당 부분은 실제로 멀티플레이어 (multiplayer) 방식으로 이루어지고 있습니다. 예를 들어, 제가 "이봐, Cowork에 이 새로운 기능을 구현해야 할 것 같아"라고 말하면, Claude Tag를 태그하여 첫 번째 초안 작업을 수행하게 합니다. 그런 다음 Claude Tag에게 "최종 구현 결과에 대한 녹화본을 공유해줘"라고 말하고, 디자인 팀을 태그하여 검토하게 합니다. 디자인 팀이 이를 수정(nudge)한 다음, 엔지니어링 (eng) 팀에 전달하여 마무리하고 프로덕션 (prod)에 배포하도록 합니다. 매우 유동적인 경험이었습니다. 동일한 세션을 조종하기 위한 사회적 역학 (social dynamics)이 무엇인지 여전히 다듬어가는 중이지만, 사람들이 다른 이들이 사용하는 방식을 관찰하고 그 사회적 규범 (social norms)을 따르는 것을 발견했습니다. 저희 팀에 Claude Tag를 통합하는 과정은 꽤 직관적이었습니다.

Thariq: 이는 사람들을 교육하는 데도 훌륭하고, 또한 슬롭 (slop, 저품질 결과물)을 줄이는 데도 좋습니다. 왜냐하면 모두가 당신이 Claude를 사용하는 것을 함께 지켜본다는 사실이 당신의 Claude 활용 능력 또한 상향 평준화(level up)시키기 때문입니다.

이는 Midjourney가 Discord 채널에서 공개적으로 프롬프팅 (prompting)을 강제함으로써, 사람들이 고급 이미지 프롬프팅을 배우는 과제를 해결했던 방식이 떠오르게 합니다.

구축 비용이 훨씬 저렴해진 상황에서, 어떤 기능을 만들 가치가 있는지 어떻게 결정하나요?

제가 스스로 정말 어렵다고 느낀 점은, 기능을 실제로 구축하는 비용이 매우 낮아진 지금, 어떤 기능이 출시할 가치가 있는지 판단하는 것입니다.

Simon: 엔지니어링의 모든 문제 중 가장 어려운 문제인 우선순위 지정 (prioritization)을 어떻게 다루시나요? 기능을 구축하는 비용이 이제 훨씬 더 저렴해졌을 때, 어떤 기능을 구축하고 출시할 가치가 있는지 어떻게 결정하시나요?

Cat: 이것이 어려운 부분입니다. 저희는 몇 가지 방식으로 이 문제에 접근합니다. 하나는 매일 저희 제품을 직접 사용하는 '도그푸딩 (Dogfooding)'을 한다는 것입니다. 저희 제품에서 하고 싶은데 할 수 없는 기능이 생길 때마다, 다른 해결책을 찾는 대신 그 케이스를 지원할 수 있도록 제품을 직접 수정합니다. 저희 내부에는 매우 강력한 도그푸딩 (Dogfooding) 문화가 있습니다. 제품을 전 세계 사람들과 공유하기 전에, 먼저 Anthropic 내부의 모든 사람과 매우 솔직한 피드백을 주는 초기 고객들에게 공유합니다. 피드백은 더 가혹할수록 좋습니다. 그리고 사람들이 그 기능을 좋아할 때까지 반복 (Iterate)합니다. 저희는 제품을 세상에 공개하기 전에, 기능이 갖춰야 할 활성 사용자 수와 리텐션 (Retention, 유지율)에 대한 내부 기준을 가지고 있습니다. 이 기준이 매우 명확하기 때문에, 모든 엔지니어는 자신이 무엇을 달성해야 하는지 알고 있습니다. 저는 이것이 제품의 완성도 (Polish)를 높여준다고 생각합니다. 기능이 정교하지 않으면 사람들이 이탈 (Churn)할 것이고, 그렇다면 그 기능을 출시해서는 안 되기 때문입니다.

내부 사용자 리텐션 (Retention)을 사용하여 기능 출시 여부를 결정하는 것은 저에게 매우 합리적으로 느껴집니다.

당신을 놀라게 했던 기능의 사례가 있나요?

Simon: 당신을 놀라게 했던 기능의 사례가 있나요? 기능을 출시했는데 참여도 (Engagement)가 엄청나게 높았다거나, 출시될 가능성이 낮았는데 실제 제품의 핵심 요소가 된 사례 같은 것 말입니다.