[한영자막] 올해 Claude에게 있었던 일들

URL: https://www.youtube.com/watch?v=cO96D7jSU_Q 날짜: 2026-07-28 채널: Tech Bridge (TechBridge-KR) 영상 길이: 51:02 원본 발행일: 2026-07-28

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

앤트로픽 Claude Code 팀 내부자 두 명(캣 우Cat Wu, 타릭Tariq — ASR 인식상 이름 정확도 낮음, "Theik Shihipa"로도 들림)이 한 컨퍼런스 파이어사이드 챗에서 ==지난 1년 반 동안 Claude Code가 어떻게 진화했는지, 그리고 앤트로픽이 내부적으로 Claude로 Claude를 만드는 과정에서 무엇을 배웠는지==를 솔직하게 공유한다.

• Claude Code는 2025년 2월 Claude Sonnet 3.7 발표의 "한 줄짜리 부가 기능"으로 출시됐지만, 1년 반 만에 팀의 일하는 방식 자체를 바꿔놓았다
• 신제품 Claude Tag(팀 협업 도구)가 앤트로픽 제품 엔지니어링 팀 PR의 65%를 자동으로 처리하고 있다
• Claude Fable(신모델) 덕분에 Claude Code 시스템 프롬프트가 80% 줄었고, Auto Mode는 수천 개의 red-team 평가를 통과해 프롬프트 인젝션 방어에 자신감을 갖게 됐다

전체적으로 이 대화는 "AI 코딩 에이전트가 감독이 필요한 도구에서, 신뢰를 쌓아 자율적으로 맡길 수 있는 팀원으로 바뀌는 과정"을 앤트로픽 내부 시각에서 보여준다.

---

1. 지난 1년간 일하는 방식의 변화

이 섹션에서는 진행자가 두 게스트에게 "코딩 에이전트가 실제로 작동하기 시작한 지난 1년간 일상 업무가 어떻게 바뀌었는가"를 묻는다.

1.1. Permission Prompt 감시에서 위임으로

1. 초기 Claude Code(Sonnet 3.7 시절)의 경험
   1. 철저한 감시 필요: 캣 우는 "모든 permission prompt를 극도로 꼼꼼히 읽었고, 거의 항상 '아니오'라고 답했다"고 회상. "이 파일 확인했어? 저 파일은?" 하며 매번 검증해야 했다
   2. 작업 위임 불가능한 수준: 초기에는 사소한 작업 하나하나를 직접 감독해야 해서, 창의적인 업무에 쓸 시간이 없었다
2. 현재(모델 세대가 거듭되며) 달라진 점
   1. 메뉴얼 구현 위임 가능: 이제는 지루한 구현 작업을 Claude에게 완전히 맡기고, "우리가 사용자에게 어떤 경험을 제공해야 하는가" 같은 창의적 결정에 시간을 쓴다
   2. Auto Mode의 "기억 상실" 현상: 타릭은 "이제는 auto mode가 원래부터 있었던 것처럼 느껴진다. yes/allow를 눌렀던 기억조차 안 난다"고 표현 — 그만큼 빠르게 새로운 표준이 자리잡았다

1.2. 기대치 상승이 만드는 새로운 압박

1. 품질 기준 상향
   1. 캣 우의 사례: 비디오 편집 작업에 Claude를 활용하는데, 브랜드팀의 까다로운 기준을 몇 시간 안에 충족시켜야 한다는 압박이 생겼다 — "우리가 낸 최고의 결과물을, 지금까지보다 더 빨리" 만들어야 한다는 개인적 기준으로 자리잡음
   2. 야망 수준 상승: 진행자(모더레이터)도 "소프트웨어 엔지니어링이 오히려 더 어려워지고 있다"고 공감 — 도구가 뒷받침해주니 스스로에 대한 기대치가 계속 올라간다는 것. "재미있지만 일이 많다"

---

2. 소프트웨어 엔지니어링 통념의 붕괴

2.1. "다시 쓰지 마라"는 격언의 폐기

1. 재작성(Rewrite)에 대한 인식 전환
   1. 과거 통념: "Mythical Man-Month"류의 격언 — 절대 처음부터 다시 쓰지 말라는 것이 소프트웨어 공학의 정설이었다
   2. 현재는 정반대: 타릭은 "이제 나는 재작성 지지자다. 좋은 테스트 스위트가 있으면, 재작성이 오히려 테스트 스위트를 제대로 갖추도록 강제한다"고 말함
2. 코드베이스 = 유일한 스펙
   1. 핵심 통찰: 사람들이 과소평가하는 것은 "코드베이스가 스펙의 유일한 사본"이라는 점 — 아무도 코드베이스의 모든 분기 경로를 알지 못하기 때문에, 코드는 그 자체로 요구사항 문서 역할을 한다
   2. 실제 사례: 앤트로픽은 Bun을 Rust로 재작성했고, 지금 실제로 라이브 운영 중이다. 심지어 Claude Code 자체도 내부적으로 Bun-on-Rust 버전을 실험 중이라고 언급됨 (진행자가 놀람)
3. 테스트 스위트 기반 다중 구현 비교
   1. 새로운 워크플로우: 좋은 테스트 스위트를 먼저 만들고, 동일 스펙으로 3개의 서로 다른 구현을 동시에 만든 뒤 가장 정확한 것을 선택하는 방식이 가능해짐
   2. 프로토타이핑 습관화: 타릭은 컨퍼런스 중에도 휴대폰으로 아이디어를 프로토타이핑해서 나중에 이어서 작업하는 습관이 생겼다고 언급

2.2. PM/엔지니어 역할 분담의 재구성

1. 기획-구현 사이클 단축
   1. 과거: PM이 고객 인터뷰 → 6개월에 걸쳐 크로스펑셔널 팀과 정렬 → PRD와 엣지 케이스 문서를 완성한 뒤에야 첫 코드 라인 작성
   2. 현재: 아이디어에서 구현까지의 타임라인이 6~12개월에서 최대 1주일로 단축됨
2. 엔지니어에게 요구되는 새로운 역량
   1. 제품 감각/비즈니스 센스 강조: 실행(execution) 역량의 가치는 상대적으로 낮아지고, "무엇을 만들 가치가 있는가"를 판단하는 taste가 훨씬 중요해짐
   2. 인프라 영역은 예외: 다만 인프라 도메인에서는 여전히 디테일을 정확히 맞추는 것이 매우 중요하다는 단서를 붙임

---

3. Claude Tag — 팀 협업의 새 레이어

진행자가 "1주일 전(이 대화 시점 기준)에 출시된 Claude Tag가 비엔지니어들 사이에서 어떻게 쓰이는가"를 묻는 것으로 시작하는 섹션.

3.1. Claude Tag의 3가지 핵심 차별점

1. 멀티플레이어 기본값(Multiplayer by default)
   1. 작동 방식: Slack 채널에 Claude Tag를 추가하면, 본인뿐 아니라 팀원들도 함께 끼어들어 같은 PR에 대해 협업할 수 있다
   2. 기존 Claude Code와의 차이: Claude Code는 1:1 인터랙티브 세션인 반면, Claude Tag는 채널 전체가 공유하는 세션 개념
2. 프로액티브(Proactive) vs 리액티브(Reactive)
   1. 선언형 모니터링 지시 가능: "이 채널의 모든 버그 리포트를 모니터링하고, 고치는 PR을 올리고, 그 코드를 마지막으로 수정한 엔지니어를 태그하라"는 지시를 채널 수명 동안 자동으로 수행
   2. 수동 호출이 필요 없음: 매번 사람이 수동으로 Claude Code를 실행시킬 필요가 사라짐
3. 팀 메모리(Team Memory)
   1. 자연어 선호도 기억: "아웃테이지는 디버그하되 경고(warning)는 디버그하지 마라" 같은 지시를 채널에 자연어로 한 번 말하면, 채널의 모든 미래 게시물에 대해 이 선호를 기억한다
   2. 팀 전체 공유: 한 사람이 알려준 선호도를 채널의 다른 모든 팀원에게도 동일하게 적용

3.2. 내부 도입 성과와 역할 분담

1. 65%라는 수치
   1. 정확한 범위: "앤트로픽 제품 엔지니어링 팀"의 내부 버전 Claude Tag가 해당 팀 PR의 65%를 처리하고 있음(전사 전체나 Claude Code 팀 전체 수치는 아님, 진행자 질문에 명확히 구분해서 답함)
   2. 의미: PR의 절반 이상이라는 점에서 큰 전환으로 평가됨(청중 웃음 반응)
2. Claude Code와 Claude Tag의 역할 분담
   1. Claude Code: 여전히 가장 복잡한 작업, 인터랙티브하게 반복 조정이 필요한 작업에 최적
   2. Claude Tag: 사용자를 대신해 프로액티브하게 작업 — 버그 리포트마다 수동으로 Claude Code를 실행할 필요를 없애줌
3. 비개발 업무 사례
   1. 회사 내부 검색 엔진 역할: 발표 직전 "Fable 언제 출시되나요?"를 Claude Tag에 물어 Slack 전체를 검색해 발표 타이밍을 맞춘 실제 사례를 언급
   2. 메트릭 질의 응답: 이벤트 스토어와 연결해두면 비개발자도 지표 관련 질문을 할 수 있음
   3. 마케팅팀 활용 사례: 마케팅팀이 "이 기능에 대해 알려줘"라고 물으면, Claude가 코드베이스를 clone해서 기능을 설명하고 실제 사용 녹화 영상까지 만들어줌

3.3. 팀 내 협업 워크플로우와 사회적 규범

1. 세션 스티어링(session steering)의 유동적 흐름 사례
   1. 실제 흐름 예시: "이 기능을 co-work에 구현하자"고 제안 → Claude Tag가 1차 구현 → "최종 구현 녹화본을 공유해줘" 지시 → 디자인 팀원 태그해 조정 → 최종 완성까지 릴레이
   2. 사회적 규범은 자생적으로 형성: 같은 세션을 여러 명이 조종하는 방식의 "사회적 역학"은 아직 정립 중이지만, 사람들이 서로의 사용법을 관찰하며 자연스럽게 규범을 따라간다고 설명
2. 부가 효과: 코드 슬롭(slop) 감소
   1. 공개 사용의 견제 효과: "누군가 그냥 '@Claude 이거 고쳐줘'라고만 쓰는 걸 다 같이 보게 되면" 품질에 대한 사회적 압박이 자연스럽게 생겨 슬롭성 사용이 줄어든다는 언급
   2. 공개 작업 문화: "당신이 자랑스러워할 수 있는 결과물을 공개적으로 만들고 싶어진다"는 표현

---

4. Claude로 Claude를 만들기 — 내부 우선순위 결정과 코드 리뷰

4.1. 우선순위 결정 방식: 도그푸딩 문화

1. 매일의 도그푸딩(Dogfooding) 원칙
   1. 막힌 지점을 그냥 고친다: 자사 제품으로 하고 싶은데 안 되는 게 있으면, 다른 해결책을 찾는 대신 제품 자체를 그 케이스를 지원하도록 고친다
   2. 일반 대중 공개 전 2단계 검증: 전사 앤트로픽 직원에게 먼저 공개 → 일부 초기 고객에게 공개해 솔직한(더 냉정할수록 좋은) 피드백을 받고 사람들이 좋아할 때까지 반복
2. 내부 출시 기준(bar)
   1. 활성 사용자·리텐션 기준: 전 세계에 공개하기 전, 내부 활성 사용자 수와 리텐션에 대한 명확한 기준선이 있다
   2. 명확한 기준이 만드는 효과: 모든 엔지니어가 자신이 무엇을 달성해야 하는지 알고 있고, 이 기준이 기능의 완성도(polish)를 끌어올린다 — 완성도가 낮으면 사용자가 이탈하고 그러면 출시하지 않아야 한다는 신호로 해석

4.2. 예상 밖 히트 기능: 리모트 컨트롤(Remote Control)

1. 탄생 배경과 실제 도입 반응
   1. 원래 담당자의 낮은 기대: 캣 우는 개인적으로 리모트 컨트롤(모바일/웹 브라우저로 로컬 CLI에서 돌아가는 Claude Code 세션을 원격 조종하는 기능)에 대한 필요를 느끼지 못했다 — 자신은 쉬운 작업만 하고 클라우드 세션으로 바로 처리했기 때문
   2. 실제 채택된 사용 패턴: 출시 후 많은 사람들이 "밤마다 노트북을 충전기에 꽂아두고 화면을 닫은 채, 원격 컨트롤 세션 여러 개를 열어두고 잠금 화면 상태에서 소파에 앉아 휴대폰으로 Claude Code를 조종한다"는 흐름을 만들어냈다
   3. 본인도 채택: 캣 우 본인도 이제 이 방식을 그대로 쓰며, "더 편안한 환경에서 훨씬 많은 작업을 노트북으로 처리하고 있다"고 밝힘

4.3. 코드 리뷰: 인간을 루프에서 점진적으로 제거하는 과정

1. 역할별 리뷰 체계
   1. 코드 오너(Code Owner) 제도: 중요 영역(예: 시스템 프롬프트)은 코드 오너가 지정돼 있고, 반드시 그들의 승인을 받아야 PR을 머지할 수 있다 — 코드 오너가 해당 영역 품질에 직접 책임짐
   2. GitHub 코드 리뷰 봇: 모든 PR에 대해 자동으로 리뷰가 돌아가며 대부분의 리뷰 작업을 이 봇이 담당
   3. 복잡한 PR용 아티팩트: 더 복잡한 PR의 경우, 다른 사람이 리뷰할 수 있도록 PR 자체를 설명하는 아티팩트를 만드는 방식도 활용
2. 인간을 루프에서 제거하는 6개월+ 여정
   1. 점진적 신뢰 구축 전략: 처음에는 모든 것을 사람이 리뷰했지만, "이 파일들을 건드리는 변경에 대해서는 코드 리뷰가 이슈를 100% 잡아내고 있다"는 판단이 서면 그 영역부터 사람 리뷰를 뺀다
   2. 인시던트 발생 시 학습 루프: 인시던트가 발생하면 원인이 된 PR을 분석 → 코드 리뷰 시스템이 그것을 잡아내도록 업데이트 → 해당 PR을 eval set에 추가해 향후 회귀를 방지
   3. 핵심 코어는 여전히 사람이 리뷰: Claude Code나 다른 제품의 가장 핵심적인 코어 변경은 항상 코드 오너가 수동으로 검토하지만, 바깥층(outer layer) 변경은 Claude Code 리뷰가 완전히 전담

4.4. 신모델 신뢰 구축과 Eval 체계

1. 모델 교체를 위한 Eval Set의 역할
   1. 드롭인 교체 검증: 새 모델이 나오면 전체 eval set을 돌려서, 예를 들어 Fable이 Opus 4.8보다 확실히 더 낫다는 것을 확인한 뒤 교체(drop-in)한다
   2. 팀 단위 + 전사 단위 이중 구조: Claude Code 팀 자체 eval과, 앤트로픽 전사 모든 레포에 걸쳐 실행되는 코드 리뷰 eval을 둘 다 운영
2. Auto Mode 전용 Red-team 검증
   1. 다층 검증 체계: 앤트로픽 내 모든 사용자 대상 eval뿐 아니라, 여러 외부 red team 테스터를 고용해 프롬프트 인젝션과 악성 입력이 있는 환경을 만들어 auto mode가 이를 통과시키지 않는지 검증
3. 행동(Behavioral) Eval의 필요성
   1. 역량(capability) 최적화가 출발점: 가장 먼저 최적화하는 것은 "완전한 작업 정의와 전체 코드베이스가 주어졌을 때 Claude가 올바른 결정을 내려 버그를 완전히 고치고 테스트를 통과시키는가"이다
   2. 사용자 경험에 영향을 주는 행동 문제들: 예를 들어 사용자들은 Claude Code가 "이제 잘 시간이다"라고 말하거나 "5개 중 2개를 끝냈는데 계속할까요?"라고 되묻는 것을 매우 싫어한다("네, 그냥 계속하세요"가 정답인 상황)
   3. 우선순위 기반 eval 구축: 사용자 피드백을 받으면 우선순위를 매겨 하나씩 eval을 만들어간다 — 100% 커버리지는 아니지만 커버리지를 늘리는 것이 팀의 우선순위

---

5. 시스템 프롬프트 80% 감소의 비밀

진행자가 아침 키노트에서 언급된 "Claude Code 시스템 프롬프트가 Fable 덕분에 80% 줄었다"는 내용을 더 깊이 파고드는 섹션.

5.1. 예시(Example) 제거가 준 뜻밖의 효과

1. 초기 모델(Opus 4대)의 특성
   1. 예시 의존도가 높았음: 초기 모델일수록 많은 예시가 필요했다
   2. 예시 제거의 효과: 예시를 제거하는 것이 오히려 매우 효과적이었다 — 모델이 주어진 예시보다 더 창의적으로 작업했기 때문
2. 프롬프트 엔지니어링 통념의 붕괴
   1. 기존 통념과의 충돌: 진행자는 "예시를 주는 것이 가장 쉬운 프롬프팅 팁 중 하나"라고 늘 조언해왔는데, 이게 더 이상 사실이 아니라면 자신의 프롬프팅 모델이 깨지는 것이라고 지적
   2. 두 게스트 모두 놀랐다는 반응: 이제는 Claude에게 주는 "도구의 형태(shape)"와 시스템 프롬프트 구조 자체가 더 중요해졌다는 것에 공감

5.2. "하지 마라" 지시를 줄이고 맥락을 늘리기

1. 하드 제약(Hard Constraint)의 부작용
   1. "하지 마라" 지시의 문제: Claude에게 "이건 하지 마라"는 지시는 매우 강한 임펄스로 작동하는데, 나중에 사용자 지시와 충돌하면 극도로 혼란스러워질 수 있다 (스킬에서 "이렇게 하라"는 지시와 시스템 프롬프트가 "저렇게 하라"고 하면 Claude가 헷갈림)
   2. 해결 방향: 하드 제약을 줄이고, 대신 맥락(context)을 주는 방식으로, 전체 지시 개수 자체를 줄인다
2. 검증(Verification) 지시의 재설계 사례 — 구체적 실례
   1. 90% 참 vs 10% 예외: "프론트엔드 변경이 있으면 항상 검증하라"는 지시가 90%는 맞지만, 실제로는 맞지 않는 10% 케이스가 있다는 것을 리뷰 과정에서 발견
   2. 구체적 예외 사례: 문자열 하나를 다른 문자열로 바꾸는 카피 수정이고 사용자가 "빠르게 고치고 테스트만 업데이트해줘"라고 했다면, 굳이 검증할 필요가 없다
   3. 수정된 문구: "항상 검증 검증 검증"에서 → "백엔드 엔드포인트만 쳐서는 전체 경험을 이해할 수 없는 경우가 많으니, UX 변경을 할 땐 앱을 로컬에서 실제로 실행해보라"는 식으로 부드럽게 조정. 다만 이 지시조차 "큰 변경"의 기준이 모호하다는 점에서 완벽하지 않다고 자평
3. 프롬프트 작성의 일반 원칙
   1. 오해 가능성 점검: 모델에게 프롬프트를 줄 때는 항상 "선의를 가진 다른 사용자나 사람이 이 지시를 어떻게 오해할 수 있을까"를 생각해봐야 한다
   2. 100% 정확성 목표: 그 프롬프트는 모델에게 100%의 시간 동안 적용되므로, 100% 정확하도록 표현을 완화(soften)해야 한다는 원칙

5.3. 모델별 차등 시스템 프롬프트

1. 프론티어 모델 전용 경량화
   1. 80% 감소는 프론티어 모델에 한정: 이 80% 토큰 감소는 가장 최신 프론티어 모델(Fable, Opus 4.8 등)에만 적용되고, 구형 모델은 여전히 풀 버전 시스템 프롬프트를 사용한다
   2. 모델별 시스템 프롬프트 분리 이유: 판단력(judgment)이 낮은 모델에는 더 상세한 지시가 필요하기 때문
2. 작은 모델을 위한 프롬프트를 큰 모델이 대신 작성할 수 있는가
   1. 아직 정밀 평가 없음: Fable/Opus가 Haiku처럼 판단력이 낮은 모델을 위한 프롬프트를 대신 써줄 수 있는지는 아직 정밀하게 평가하지 못했다는 솔직한 답변
   2. 토큰 효율성의 역설: 어려운 문제에서는 오히려 더 큰 모델이 작은 모델보다 토큰 효율적일 수 있다는 직관이 생기는 중 — "파레토 곡선이 계속 이동한다"는 표현
3. 모델이 모델을 프롬프팅하는 시대
   1. 서브에이전트/워크플로우 도구가 대표 사례: 워크플로우 도구는 Claude가 여러 서브에이전트의 오케스트레이션을 프롬프팅하는 것으로, 서브에이전트 하나하나에 매우 상세한 프롬프트가 주어진다
   2. 워크플로우 도구 자체의 프롬프트도 Claude가 작성: 워크플로우 툴의 프롬프트를 Claude가 직접 썼다고 언급 — 진행자는 그 프롬프트를 읽어봤고 "좋은 프롬프트"라고 평가
   3. 진행자의 요청사항: 앤트로픽이 시스템 프롬프트는 공개 페이지에 올리면서 도구(tool) 프롬프트와 Claude Code 프롬프트는 공개하지 않아 프록시로 가로채야 하는 상황에 불만 표시 — 프롬프트야말로 "그 도구가 뭘 할 수 있는지 보여주는 문서"이기 때문에 공식 공개를 요청, 게스트가 "기능 요청으로 적어두겠다. Claude Tag에게 시키겠다"고 화답

---

6. 도구(Tool) 설계 철학

6.1. 새 도구 도입 기준

1. "도구 개수를 줄이는 방향"이 최근 트렌드
   1. 최근 추가된 대표 도구: task tool 등 — 더 일반화된 버전을 Claude에게 주는 방향으로 최근 도구를 도입해왔다
   2. Ask User Question 도구의 탄생 비화: 타릭은 "내 커리어는 ask user question 도구를 도입했을 때 정점을 찍었다"고 농담 — 이 도구는 Claude가 사용자에게 질문하는 도구라서 평가하기 특히 어려웠고, 당시엔 eval보다는 도그푸딩(내부에서는 "ant fooding"이라 부름) 기반으로 판단했다
2. File Edit 도구 vs Grep/Bash로 대체 가능한 도구
   1. 제거된 도구들: grep과 다른 검색 도구, glob 도구는 제거하고 네이티브 bash로 대체
   2. File Edit 도구는 유지 — 이유는 UX: 파일 수정을 렌더링(UI에 "이 파일 수정을 승인하시겠습니까?" 같은 전용 UI)하기 위해 dedicated file edit 도구를 남겨둠. 이는 Claude가 파일을 수정한다는 것을 결정론적으로(deterministically) 알아내야 UI를 보여줄 수 있기 때문
   3. 온보딩 사용자에게는 여전히 유효: 새로 온보딩하는 사용자들은 이 UI 경험을 여전히 좋아하지만, auto mode(혹은 YOLO 모드가 아닌)로 일하는 숙련 사용자에게는 사실 없어도 무방하다고 인정
3. 도구 설계는 과학보다 예술/생물학에 가깝다
   1. 타릭의 관점: 모델은 물리학보다는 생물학에 가깝고, 특히 도구 설계는 매우 어렵다 — 과학이라기보다 예술/직관의 영역
   2. 캣 우의 보완 관점: 도구 개수(cardinality)는 낮게 유지하고, 각 도구가 서로 뚜렷이 구분되는 기능을 갖도록 해서 Claude가 언제 어떤 도구를 호출할지 쉽게 구별할 수 있게 하는 것이 원칙

---

7. Auto Mode — 안전과 보안

진행자가 개인적으로 "프롬프트 인젝션 위험을 잘 알고 있음에도 여전히 대부분 YOLO 모드로 Claude Code를 돌리고 있어 죄책감을 느낀다"고 고백하며 시작하는 섹션.

7.1. Auto Mode에 대한 앤트로픽 내부 권고

1. 거의 전원이 Auto Mode 사용
   1. 내부 표준: 앤트로픽 내부에서는 거의 모든 사람이 auto mode를 쓴다 — 장시간 작업을 안전하게 하는 가장 좋은 방법으로 평가
   2. 검증 규모: 수천 개의 eval, 다수의 red team 테스터를 고용해 Claude Code를 악성 행동으로 유도하는 적대적(adversarial) 환경을 만들었고, 발견된 이슈는 모두 완화(mitigate)했다고 주장
   3. 공개 예정: 몇 주 안에 관련 eval을 공개할 예정이며, 커뮤니티가 직접 평가할 수 있게 하겠다는 계획
2. 완벽한 보장은 아니라는 단서
   1. 주요 위험군에 한정된 자신감: 프롬프트 인젝션, 데이터 유출(exfiltration) 등 주요 우려 범주에서는 평균적인 사람 리뷰어보다 위험이 훨씬 낮다고 표현하지만, "100%를 잡아낸다"는 주장은 하지 않는다고 명확히 함

7.2. Auto Mode의 작동 메커니즘

1. 소넷(Sonnet) 기반 분류기(Classifier) 구조
   1. 매 턴마다 판단: Claude가 매 턴을 실행하거나 bash 호출을 할 때마다, Sonnet 기반 분류기가 해당 도구 호출과 대화 맥락(사용자 지시 포함)을 함께 판단한다
   2. 동적 권한(Dynamic Permission) 처리: "git push는 항상 허용하고 싶지 않지만, 사용자가 '이거 깃허브에 푸시해줘'라고 명시적으로 말하면 허용해야 한다"는 식의 맥락 기반 판단을 수행
   3. 역방향 감지 사례: "이거 하지 마"라는 지시가 있었는데 Claude가 (도움을 주려는 의도로) 그 행동을 시도하면, auto mode가 이를 감지해 표면화(surface)한다는 실제 경험 공유
2. 샌드박싱 인프라와의 연동
   1. 네트워크 요청 예외 처리: 샌드박스 안에서 작업하다가 네트워크 요청처럼 샌드박스를 벗어나야 하는 상황이 생기면, auto mode가 그 요청이 타당한지 판단해서 허용 여부를 결정
   2. 모든 permission prompt에 관여: auto mode는 사용자가 원래 봤을 모든 permission prompt와 상호작용하는 구조
3. Auto Mode의 역사
   1. 내부 사용 시작 시점: 2026년 1월부터 앤트로픽 내부에서 사용해왔으며, 그때부터 지금까지 계속 하드닝(hardening)해온 기능
   2. 정렬(alignment)·안전(safeguards) 팀과의 협업: 내부 롤아웃과 eval 구축, 안정성 강화를 위해 정렬팀·안전팀과 폭넓게 협업했다고 설명

7.3. 진행자의 남은 우려

1. 투명성 부족에 대한 아쉬움
   1. 핵심 문제의식: "내 보안을 지켜주는 기능이라면 어떻게 작동하는지, 무엇으로부터 나를 보호하고 무엇으로부터는 못 지키는지 최대한 깊게 알고 싶다"는 입장 표명
   2. 관련 블로그 포스트 예고: 게스트 중 한 명(Dell로 언급됨 — ASR 인식, 정확한 이름 불명)이 이에 관한 포스트를 준비 중이라고 언급

7.4. Claude Tag의 보안 설계 — "Swiss Cheese Defense"

1. 자체 슬랙봇을 만들지 말라는 조언
   1. 위험성 강조: "직접 AI 슬랙봇을 만들지 마라 — 공격 벡터가 너무 많다"는 조언 — 예를 들어 사용자가 피드백을 남기는 채널이 있으면, 봇이 그 피드백을 읽는 순간 그 자체가 공격 표면이 된다
   2. 다층 방어 체계: Auto Mode + RL 기반 방어 등 여러 겹의 방어(Swiss cheese defense)를 결합한 구조라서 Claude Tag가 잘 작동한다고 설명
2. 자격 증명(Credential) 분리와 신원(Identity) 관리
   1. 개별 자격증명 프로비저닝: Claude Tag는 사용자를 대신해 행동할 필요가 없도록, Claude용 자격증명을 별도로 프로비저닝할 수 있다
   2. 감사·검사 용이성: Claude를 별도의 "신원(identity)"으로 취급하면, Claude가 무엇을 했는지 감사(audit)하고 검사(inspect)하기가 더 쉬워진다는 장점
   3. 더 넓은 공격 표면에 대한 인식: Claude Tag는 채널 내 누구나 말을 걸 수 있어 공격 표면이 훨씬 넓다는 점을 진행자가 지적하고, 게스트가 동의
3. 원격 사용자 대상 추가 보안 기능
   1. Trusted Devices: 리모트 컨트롤 사용자를 위한 신뢰 기기(trusted devices) 기능 출시
   2. 자격 증명 주입(Credential Injection): 원격 환경에서, 예를 들어 Claude Code가 Datadog에 접근은 해야 하지만 Claude 자신이 Datadog 자격증명을 소유하지 않게 하고 싶다면, ID/자격증명 관리 시스템을 통해 "에이전트가 사용은 하되 접근은 못하는" 구조를 만들 수 있다
   3. 작동 방식: Datadog 요청을 시도하는 순간에만 실제 토큰을 실시간으로 삽입(insert on the fly)하는 프록시 토큰 치환 방식 — 진행자가 "API 요청에 어떤 토큰이 붙어 오면 실제 값으로 바꿔치기하는 이 프록시 패턴을 요즘 여러 곳에서 본다"며 강하게 공감

---

8. 인간적 요소 — 상실감과 야망

8.1. "내 역할을 빼앗기고 있다"는 상실감에 대한 시각

1. 상실감은 현실이라는 인정
   1. 솔직한 인정: 타릭은 "LLM 이전과 똑같은 일을, 이제는 프롬프트 하나로 하고 있다면 슬픈 감정을 느끼는 게 당연하다"고 공감
   2. 상쇄 방법 = 더 야망을 갖는 것: 이 상실감을 상쇄하는 방법은 "더 야망 있는 일을 하는 것"이라고 제시
2. 구체적 롤모델 사례 — Jared
   1. Zig에서 Rust로: Jared라는 동료가 오클랜드 자택에서 거의 집 밖을 나가지 않고 1년간 손수 Zig 코드를 작성한 뒤, 이제는 Bun 전체를 Rust로 재작성하고 있다는 사례
   2. 더 큰 재미: 예전보다 훨씬 야망 있는 작업을 하면서 오히려 더 즐거워하고 있다는 것이 핵심 메시지
3. 일반화된 태도: "다들 예전부터 더 잘하고 싶었지만 못했던 일들이 있다. 이제는 '해보자'라고 말할 수 있는 시기"라는 마무리 발언

8.2. PM 역할의 변화 (캣 우 관점)

1. 매달 바뀌는 역할
   1. 엔지니어+디자이너+PM 혼합형: 팀의 PM들은 대부분 엔지니어/디자이너/PM이 혼합된 역할을 수행하며, 실제로 팀 엔지니어 상당수가 과거 풀타임 엔지니어 출신
   2. 빈 곳을 메우는 역할: 아이디어는 있는데 엔지니어를 설득하지 못했다면 직접 만들어서 노트북(prototype)으로 완성한 뒤 사람들에게 프로덕션화를 독려. 디자인이 부족하면 유사 페이지를 참고해 1차 디자인을 만든 뒤 detail-oriented한 사람을 태그해 다듬게 함
2. 자동화로 팀 커뮤니케이션 스케일링
   1. 런치 캘린더 자동화: 제품 채택이 커지면서 더 많은 사람이 로드맵을 알아야 하니, 전체 런치 캘린더를 자동으로 정리하는 시스템 구축
   2. 비동기 상태 업데이트 자동화: 사람들을 방해하지 않고 상태 업데이트를 비동기적으로 수집·정리해서, 3개의 내부 공지 채널에 상세하고 정확한 업데이트를 게시

---

9. Claude가 놀라게 한 순간 & 아직 부족한 부분

9.1. 비디오 편집 사례 — 캣 우의 실화

1. 상황: ACM Agentic 컨퍼런스에서 발표를 마친 뒤, 편집된 영상이 늦어져서 무대 발표 영상, 발표 덱 영상, 오디오 파일 원본과 HTML 덱 파일을 직접 Claude(Fable)에게 넘기고 "편집해줘"라고 요청
2. Claude가 자율적으로 수행한 작업들
   1. 전체 영상 자동 전사(transcribe)
   2. 덱 영상의 결함 자체 판단: 덱 영상 중간에 자동 업데이트 팝업이 뜬 것을 발견하고, "이 영상 대신 HTML 소스를 슬라이드별로 잘라서 사용하겠다"고 스스로 판단해 대체
   3. 동적 크롭(crop): 발표자가 무대의 일부만 차지하고 계속 돌아다니는(pacing) 것을 감지해, 발표자의 위치를 추적하며 동적으로 화면을 크롭
   4. 자막·구성 통합: 발화 내용을 자막으로 얹고, 덱과 발표자 영상을 조합
3. 결과와 사용 도구: 원샷 프롬프트로 만들었는데도 결과물이 그대로 배포 가능한 수준이었고, 이후 애니메이션·그래픽 추가 요청도 훌륭하게 처리. ffmpeg, remotion 등을 스스로 활용

9.2. 아직 못하는 것들

1. 디자인/UX 감각의 한계 (캣 우)
   1. 스펙은 정확히 구현하지만 감각이 부족: 상세한 스펙을 주면 그대로 동작은 하지만, 패딩(padding)이 어긋나거나 인터페이스가 아직 "딜라이트풀(delightful)"하지 않다
   2. "Opus 미학(Opus aesthetic)": 진행자가 "Opus가 디자인했다는 걸 척 봐도 알 수 있는 스타일이 있다"고 지적, 이를 넘어서길 바란다는 데 공감. 기존 앱 디자인 관행에 의존하는 경향이 있고, 프론티어 AI 제품에 필요한 새로운 인터랙션 경험은 아직 스스로 설계하지 못한다는 평가
2. 실세계 상호작용/과학 영역 (타릭)
   1. 실험 오케스트레이션에 대한 기대: "과학 문제를 풀 수 있는가, 실험을 오케스트레이션할 수 있는가"에 대한 갈증을 언급 — 코딩 요소도 있지만 더 넓은 세계에 대한 감각(taste)이 필요한 영역
   2. Claude Science 언급: 최근 출시된 신제품 "Claude Science"가 언급되지만, 타릭 본인은 "그 제품에 대한 컨텍스트가 없다"고 밝힘. 진행자 질문에 "Claude Code 소속이 아니라 파트너 팀 소속 제품"이라고 답변, "직접 써보라"는 권유로 마무리

---

10. 앤트로픽의 조직문화 — 다른 회사가 훔쳐가야 할 것들

10.1. Claude Tag를 위한 "퍼블릭 채널" 문화

1. 공개 채널이 정확도를 좌우
   1. 최대 컨텍스트 확보 원칙: Claude Tag는 가능한 한 많은 컨텍스트를 얻기 위해 모든 공개 채널을 검색할 수 있어야 하고, 대부분의 채널이 공개(public)일 때만 이게 가능하다
   2. 접근 권한이 정확도의 전제조건: 모든 것에 접근할 수 있어야만 가장 정확한 답을 줄 수 있다는 것이 핵심 논지

10.2. "우리 자신과 협상하지 않는다"

1. 공동창업자들의 원칙
   1. 핵심 표현: 앤트로픽 공동창업자들이 강조하는 원칙 — "우리는 스스로와 협상하지 않는다(we don't negotiate against ourselves)"
   2. 의미: 머릿속에서 트레이드오프를 상상하고 스스로 야망 있는 일을 포기하도록 설득하는 대신, 그냥 야망 있는 일을 시도해보는 태도
2. 트레이드오프를 스스로 증명하게 하라
   1. 실전 적용: "그냥 해버리면 어떨까?"라는 질문을 자주 던지고, 그것이 진짜 트레이드오프인지 아니면 그냥 "합리적으로 들릴 뿐"인지 근거를 요구
   2. 진행자의 반응: 25년간 소프트웨어 업계에 있으면서 "기본값은 항상 '노'였고, 모든 것은 트레이드오프였다"는 직관을 이제 재구성해야 하는 것이 흥미롭다고 소감

---

11. 마무리 — 각자 만든 가장 터무니없는 프로젝트

11.1. 타릭 — 2D 스트리트파이터 격투 게임

1. 프로젝트 개요: 본인과 친구들을 캐릭터로 한 2D 스트리트파이터 스타일 격투 게임을 제작 중
2. 제작 방식: Claude Code로 Gemini API를 프롬프팅해 비디오 애니메이션을 생성(Seedance 모델도 품질이 좋다고 평가) — 스프라이트 애니메이션 품질이 뛰어남
3. 부가 기능: Claude가 스스로 프레임을 검증해 좋은 애니메이션인지 판단할 수 있고, 히트박스(hitbox)까지 JSON으로 직접 그려서 산출

11.2. 캣 우 — 클라이밍 여행 큐레이션 앱

1. 프로젝트 개요: 암벽등반 동호인 친구들과 함께 쓰는 프로젝트 로깅 앱을 Claude Code로 제작
2. Workflows 도구의 숨겨진 용도: "코딩 도구"로 브랜딩돼 있지만, 딥 리서치(여행지 조사)에도 뛰어나다고 평가 — 팀 오프사이트 장소를 찾는 데도 활용
3. 구체적 필터링 로직: 모두의 위치에서 직항이 있는 여행지를 찾고, Mountain Project 사이트에서 원하는 난이도의 클라이밍 루트를 찾고, Airbnb를 찾고, 본인이 하이킹을 싫어해서 "주차장에서 암벽까지의 도보 거리가 짧은 곳"만 필터링하는 등 개인화된 기준을 전부 반영
4. 진행자의 촌평: "암벽등반용 Jira를 바이브코딩한 셈"이라고 요약, 캣 우도 동의

---

12. 청중 Q&A

12.1. Eval 구축 도구와 관측성(Observability) 도구 계획

1. 질문: eval 데이터셋을 만들기 위한 도구, 에이전트/워크플로우 성능을 모니터링할 관측성 도구를 만들 계획이 있는가?
2. 답변: eval 도구 자체를 만드는 것은 검토했지만, 실제 병목은 도구가 아니라 "고품질 eval을 만드는 스킬(노하우)을 익히는 데 오래 걸린다"는 점이라고 진단. 내부 투자와 동시에, 관련 베스트 프랙티스를 외부에도 공유하고 싶다는 방향성 언급

12.2. Claude Tag의 메모리 설계 방식

1. 질문: 현재 메모리는 어떻게 설계돼 있는가(파일 기반으로 추정됨), 그리고 파일 대신 별도 데이터 스토어를 쓰는 방향을 고려해봤는가?
2. 답변:
   1. 채널별 마크다운 파일 구조: 현재 Claude Tag의 메모리는 채널 단위로 구분되며, 한 채널의 모든 Claude 인스턴스가 공유 메모리를 사용. 세션 단위 메모리도 있고, 세션 기록이 메인 메모리로 다시 반영(contribute back)될 수 있음
   2. 파일 형태로 구현: 지금은 채널당 마크다운 파일 1개로 구현돼 있음
   3. 연구는 계속 진행 중: 메모리를 어떻게 설계하는 게 옳은지는 매우 직관에 반하는(unintuitive) 부분이 많아 계속 실험 중이라고 솔직하게 답변

---

주요 발언 모음

"I would frequently say no. I would always say no, no, no. Like, did you check this file? Did you check that file?" — 캣 우, Sonnet 3.7 시절 permission prompt를 매번 검증하던 경험

"I think one of the biggest shifts... it's like rewrites are now good. You know what I mean? ...The worst thing you could do is now actually fine." — 타릭, 재작성에 대한 인식 변화

"A codebase is a spec and maybe it's the only copy of the spec that you have." — 타릭

"Our internal version of quadag lands 65% of our product PRs right now. And this is a huge shift. This is like more than 50% of our PRs." — 캣 우, Claude Tag의 내부 PR 처리율

"In general we are trying to move to a world where humans don't need to be in the loop." — 캣 우, 코드 리뷰 자동화 방향

"We don't negotiate against ourselves." — 앤트로픽 공동창업자들의 원칙 (타릭 인용)

"Please build your own AI slackbot — no wait — please you probably shouldn't build your own AI slackbot, you know, like there's so many attack vectors." — 타릭, 자체 슬랙봇 개발에 대한 경고

"I wanted to have better design and UX taste... there's an Opus aesthetic. You can look at something go, 'Yeah, that was designed by Opus.'" — 캣 우 & 진행자, 현재 모델의 디자인 감각 한계

---

핵심 데이터 & 수치

• Claude Code 출시일: 2025년 2월, Claude Sonnet 3.7 발표의 부가 기능(bullet point)으로 시작 — 이 대화 시점 기준 1년 반이 채 안 됨
• Claude Tag PR 처리율: 앤트로픽 제품 엔지니어링 팀 기준 PR의 65%를 Claude Tag가 자동으로 랜드(land)시킴
• 시스템 프롬프트 감소율: Fable/Opus 4.8 등 프론티어 모델向 시스템 프롬프트가 기존 대비 80% 감소 (구형 모델은 여전히 풀버전 유지)
• Auto Mode 내부 사용 시작: 2026년 1월부터 앤트로픽 내부에서 사용 시작, 이후 지속적으로 하드닝
• 기획-구현 타임라인: 과거 6~12개월 걸리던 아이디어→구현이 이제 최대 1주일까지 단축
• Claude Science: 파트너 팀에서 만든 신제품, 이 대화 시점 기준 "며칠 전" 출시

---

결론 및 시사점

1. 감독형 도구에서 신뢰 기반 위임형 팀원으로: Claude Code는 초기의 "매 단계 승인이 필요한 도구"에서, 이제는 auto mode와 수천 개의 red-team eval을 거쳐 "장시간 자율적으로 맡길 수 있는 팀원"으로 진화했다. 이 신뢰는 하루아침에 얻어진 게 아니라, 6개월 이상의 점진적 단계(코드 오너 지정 → 특정 영역부터 리뷰 자동화 → 인시던트를 eval로 환류)를 거쳐 구축됐다.
2. 프롬프트 엔지니어링 통념은 계속 재검토가 필요하다: "예시를 주는 것이 최고의 프롬프팅 기법"이라는 기존 통념이 최신 모델에서는 반대로 작동할 수 있다(예시 제거가 오히려 효과적). 모델 세대가 바뀔 때마다 프롬프트 전략 자체를 재평가해야 한다.
3. 재작성(rewrite)에 대한 두려움을 버려도 되는 시대: 좋은 테스트 스위트가 갖춰져 있다면, "절대 재작성하지 말라"는 격언은 더 이상 절대적 진리가 아니다. 코드베이스를 스펙의 유일한 사본으로 보고, 여러 구현을 병렬로 시도해 최선을 고르는 접근이 가능해졌다.
4. 팀 협업형 에이전트(Claude Tag류)의 핵심 전제는 "공개(public) 문화": 채널이 대부분 공개돼야 에이전트가 충분한 맥락을 확보해 정확한 답을 줄 수 있다. 조직이 이런 도구의 효용을 극대화하려면 정보 공유 문화 자체를 먼저 점검해야 한다.
5. 보안은 "완전 무결"이 아니라 "다층 방어 + 지속적 하드닝"의 문제: auto mode와 credential injection(프록시 토큰 치환) 패턴은 에이전트에게 최소 권한만 부여하면서도 유용하게 만드는 실전적 방법으로, 자체 AI 봇을 만들려는 조직이라면 이 패턴을 반드시 참고할 만하다.
6. AI 시대의 "역할 상실감"에 대한 가장 현실적인 답은 "더 큰 야망": 같은 일을 계속하면 상실감을 느끼는 게 당연하지만, 이를 상쇄하는 유일한 방법은 이전보다 훨씬 야심찬 프로젝트에 도전하는 것이다.

---

메타데이터

• 원본 링크: https://www.youtube.com/watch?v=cO96D7jSU_Q
• 채널: Tech Bridge (TechBridge-KR)
• 영상 길이: 51:02
• 원본 발행일: 2026-07-28
• 처리 날짜: 2026-07-28
• 처리 방식: yt-dlp 영어 자동자막 추출 → 한국어 심층 분석 노트 작성 (BABEL)