How Anthropic teams use Claude Code

3줄 요약

1. Anthropic은 사내 열 개 팀의 Claude Code 파워 유저를 인터뷰했다. 그 내용을 팀마다 두 쪽씩 사용 사례와 효과와 조언으로 정리한 23쪽 자료다. PDF는 2025년 6월에 만들어졌고, 같은 해 7월 24일에 블로그 요약판이 올라왔다.
2. 개발 팀들은 자율 루프와 체크포인트 커밋을 함께 쓰면서, 맡겨 두고 나중에 확인할 일과 옆에서 지켜볼 일을 나눈다. 보안 엔지니어링 팀은 인시던트 때 코드를 훑는 시간이 10분에서 15분쯤 걸리던 것이 5분 정도로 줄었다고 했고, Claude Code 팀은 Vim 모드 최종 구현의 70%를 Claude의 자율 작업으로 채웠다고 했다.
3. 자료의 절반은 코드를 쓰지 않는 팀들의 이야기다. 1인 마케팅 팀은 광고 카피 작업을 2시간에서 15분으로 줄였고, 법무 팀원은 한 시간 만에 가족을 위한 예측 텍스트 앱을 만들었다.

자료는 어떻게 만들어졌는가

인터뷰 대상은 각 부서에서 Claude Code를 가장 많이 쓰는 직원들이었다. 그 결과를 팀마다 두 쪽으로 묶었는데, 첫 쪽은 그 팀의 주요 사용 사례를 담고 둘째 쪽은 팀이 체감한 효과와 다른 조직에 주는 조언을 담는다. 등장하는 팀은 모두 열 곳이다. 데이터 인프라, 프로덕트 개발, 보안 엔지니어링, 추론, 데이터 사이언스와 ML 엔지니어링, API, 그로스 마케팅, 프로덕트 디자인, RL 엔지니어링, 법무 팀이다.

자료는 도입부에서 자기 목적을 먼저 밝힌다.

Anthropic의 사내 팀들은 Claude Code로 자신들의 업무 흐름을 바꾸고 있다. 개발자와 비개발 직원 모두가 복잡한 프로젝트에 손을 대고, 작업을 자동화하고, 지금까지 생산성을 제한했던 기술 격차를 메우게 되었다.

문서에 등장하는 도구는 Claude.md 파일, 커스텀 슬래시 명령, MCP 서버, GitHub Actions 연동, auto-accept 모드가 전부다. 이 자료는 만들어진 지 1년이 넘었으므로, 지금 읽을 때는 2025년 중반의 운용 관행을 남긴 스냅샷으로 보는 편이 맞다.

열 개 팀을 한 표로

개발 팀들이 공유하는 작업 방식

어느 팀이든 작업을 시작할 때 가장 먼저 하는 일은 비슷하다. API 팀은 Claude Code를 어떤 작업에서든 “첫 정거장"이라고 부르면서, 버그 수정이든 기능 개발이든 어떤 파일을 봐야 하는지부터 묻는다. 추론 팀은 GitHub 저장소를 직접 검색하는 대신 특정 기능을 호출하는 파일이 어디인지 물어서 몇 초 안에 답을 받는다. 데이터 인프라 팀은 신규 입사한 데이터 사이언티스트에게 코드베이스를 직접 파라고 하지 않고 Claude Code로 안내한다. Claude가 Claude.md 파일을 읽고 관련 파일을 골라 주고 데이터 파이프라인의 의존 관계까지 설명해 주기 때문이다. 이 팀은 그렇게 해서 기존의 데이터 카탈로그 도구를 대체했다고 적었다.

팀들은 작업을 두 종류로 나눠서 맡긴다. Claude Code 팀은 자기 제품으로 자기 제품을 만드는데, 익숙하지 않은 추상적인 문제는 auto-accept 모드(shift+tab)로 자율 루프에 넘겨 두고 80% 정도 완성된 결과를 받아 마무리한다. 반대로 애플리케이션의 비즈니스 로직을 건드리는 기능은 상세한 지시를 주고 실시간으로 지켜보면서 진행한다. 이 팀은 다른 조직에도 그 구분 감각을 기르라고 권한다. 제품 주변부의 추상적인 작업은 맡겨 두어도 되고, 핵심 기능은 가까이서 감독해야 한다.

되돌릴 수 있게 만들어 두는 습관도 여러 팀에서 반복된다. Claude Code 팀은 깨끗한 git 상태에서 시작하고 체크포인트를 자주 커밋하라고 적었다. RL 엔지니어링 팀은 이것을 “시도하고 되돌리기” 방법론이라고 불렀다. 데이터 사이언스 팀의 표현은 더 노골적이다.

슬롯머신처럼 다루라. 상태를 저장해 두고 Claude를 30분 돌린 다음, 결과를 받아들이거나 아니면 처음부터 다시 시작하라. 잘못된 곳을 붙잡고 고치려 씨름하기보다 새로 시작하는 편이 성공률이 높다.

거의 모든 팀이 테스트 작성을 Claude에게 넘겼다. 추론 팀은 핵심 기능을 직접 쓴 다음 유닛 테스트를 요청하는데, 사람이 놓친 엣지 케이스가 자동으로 들어온다고 했다. 보안 엔지니어링 팀은 “설계 문서에서 엉성한 코드로 갔다가 리팩터링하고 결국 테스트를 포기하던” 예전 패턴을 버리고, 의사코드를 먼저 받아 테스트 주도 개발로 유도하는 방식으로 옮겼다. Claude Code 팀은 코드보다 테스트를 먼저 생성하게 하면 Claude가 스스로 오류를 잡아내며 더 오래 자율적으로 일한다고 적었다.

문서 작업도 개발 작업과 마찬가지로 Claude Code에 맡긴다. 보안 엔지니어링 팀은 여러 문서를 한꺼번에 읽혀 마크다운 런북과 트러블슈팅 가이드를 만들고, 그 압축된 문서를 실제 장애 대응의 컨텍스트로 다시 쓴다. 데이터 인프라 팀은 작업이 끝날 때마다 세션을 요약하고 개선점을 제안하게 해서, 실제 사용 기록이 Claude.md 문서로 되돌아오는 순환을 만들었다.

코드를 모르는 팀이 만든 것들

그로스 마케팅 팀은 유료 검색과 소셜, 모바일 앱스토어, 이메일, SEO를 담당하는 비개발 1인 팀이다. 이 팀은 광고 제작 워크플로우를 하나 만들었다. 성과 지표가 붙은 광고 수백 개짜리 CSV를 읽어 성과가 낮은 광고를 골라내고, 헤드라인 30자와 설명 90자라는 문자 제한을 지키면서 새 변형을 만드는 흐름이다. 헤드라인 담당과 설명 담당으로 서브에이전트를 두 개 나눈 구조이고, 수 분 안에 수백 개를 만든다. 정적 이미지를 손으로 복제해 편집하던 소셜 광고 쪽에는 Figma 플러그인을 붙여서, 프레임을 식별한 다음 헤드라인과 설명만 갈아 최대 100개 변형을 만든다. 몇 시간 걸리던 복사와 붙여넣기가 배치당 0.5초로 줄었다. 여기에 Meta Ads API를 붙인 MCP 서버를 두어 캠페인 성과를 Claude Desktop 안에서 조회한다. 그리고 가설과 실험 결과를 기록하는 초보적인 메모리 시스템까지 얹어서, 이전 테스트 결과가 다음 변형을 만들 때 함께 반영되게 했다.

법무 팀의 사례는 회사 업무에서 시작하지 않았다. 한 팀원은 의학적 진단으로 말하기가 어려워진 가족을 위해 의사소통 보조 도구를 만들었다. 이 팀원은 음성 인식을 그대로 쓰면서 답변을 제안하고, 보이스 뱅크로 그 답을 소리 내어 읽어 주는 예측 텍스트 앱을 만들었다. 완성까지 한 시간이 걸렸다. 언어치료사가 권한 기존 접근성 도구에 없던 기능이었다. 이 팀은 그렇게 만든 프로토타입을 UCSF 전문가에게 보여 주며 아이디어를 검증하기도 했다. 사내용으로는 두 가지를 만들었다. 하나는 적절한 변호사를 찾아 주는 “전화 트리” 시스템이고, 다른 하나는 주간 업무 보고를 자동화하고 제품별 법률 검토 상태를 추적하는 G Suite 애플리케이션이다. 검토가 필요한 항목은 변호사가 버튼 한 번으로 표시할 수 있어서, 이 애플리케이션이 스프레드시트 관리를 대신하게 되었다.

프로덕트 디자인 팀은 서체와 색과 간격 같은 시각 조정을 엔지니어에게 넘기지 않고 직접 반영한다. 엔지니어들이 이 변화를 이렇게 평했다고 한다.

디자이너가 보통 하지 않을 큰 상태 관리 변경을 하고 있다.

목업 이미지를 Command+V로 붙여 넣으면 엔지니어가 곧바로 이해하고 이어받을 수 있는 동작하는 프로토타입이 나온다. 에러 상태와 로직 흐름, 시스템 상태를 지도로 펼쳐서 개발 단계로 넘어가기 전에 디자인 단계에서 엣지 케이스를 찾아내는 데도 쓴다. 코드베이스 전체에서 “research preview"라는 표현을 걷어내는 작업도 이렇게 처리했다. 모든 등장 위치를 찾고 주변 문구를 검토한 다음 법무와 실시간으로 조율해 반영했는데, 그 전체를 30분 통화 두 번으로 끝냈다. 예전이라면 일주일 동안 서로 주고받았을 일이다.

데이터 인프라 팀은 재무 팀에 자기 도구를 쓰는 법을 가르치는 대신, 업무 흐름을 평문으로 적어 Claude Code에 넣는 방법을 알려 줬다. 코딩 경험이 없는 직원이 “이 대시보드를 조회해서 정보를 얻고, 이런 쿼리를 돌려서 엑셀로 내보내라"고 적으면 그 전체가 실행된다. 날짜처럼 필요한 입력값은 Claude가 되묻는다.

프로덕트 디자인 팀은 이런 변화가 두 종류의 경험으로 갈린다고 정리했다. 개발자에게는 “증강된 워크플로우"가 되어 실행이 빨라지고, 비개발자에게는 “맙소사, 내가 개발자가 됐다는 워크플로우"가 되어 전에는 불가능했던 일이 가능해진다.

팀들이 보고한 수치

각 팀이 남긴 운용 수칙

• Claude.md에 공을 들인다. 데이터 인프라 팀은 업무 흐름과 도구, 기대치를 문서로 잘 적어 둘수록 결과가 좋아진다고 했다. RL 엔지니어링 팀은 여기에 반복되는 도구 호출 실수를 막는 지시를 넣었다. “run이 아니라 pytest를 실행하라”, “불필요하게 디렉터리를 옮기지 말고 올바른 경로를 쓰라” 같은 문장을 추가한 뒤로 일관성이 크게 나아졌다고 한다.
• 민감한 데이터에는 CLI 대신 MCP 서버를 쓴다. 데이터 인프라 팀은 BigQuery CLI보다 MCP 서버를 권했다. 로깅이 필요하거나 프라이버시 문제가 걸리는 데이터에서 접근 범위를 통제하기 쉽기 때문이다.
• 커스텀 슬래시 명령을 적극적으로 만든다. 보안 엔지니어링 팀은 회사 모노레포에 등록된 커스텀 슬래시 명령의 절반을 자기들이 만들었다.
• 먼저 말하게 둔다. 같은 팀은 코드 조각을 얻으려고 좁은 질문을 던지던 방식을 버리고, “진행하면서 커밋해 두라"고 말한 뒤 주기적으로 확인하는 쪽으로 바꿨다. 그렇게 하니 더 완결된 해법이 나왔다고 한다.
• 스스로 확인하는 루프를 만든다. Claude Code 팀은 빌드와 테스트, 린트를 자동으로 돌리게 설정해서 Claude가 자기 실수를 잡아내게 했다.
• 원샷을 먼저 시도한다. RL 엔지니어링 팀은 짧은 지시로 전체 구현을 한 번 맡겨 본다. 성공률은 약 3분의 1인데, 성공하면 시간을 크게 아끼고 실패하면 협업 방식으로 전환한다.
• 복잡해지면 중단시킨다. 데이터 사이언스 팀은 감독 중에 “왜 이렇게 하고 있지? 더 단순한 방법을 시도해 봐"라고 말하기를 주저하지 말라고 했다. 기본적으로는 복잡한 해법으로 기울지만 단순화 요청에는 잘 반응한다는 것이다.
• 복잡한 워크플로우를 서브에이전트로 쪼갠다. 그로스 마케팅 팀은 하나의 프롬프트로 전부 처리하려 하지 말고 작업별 에이전트를 따로 두라고 권했다. 디버깅이 쉬워지고 결과 품질도 올라간다.
• Claude.ai에서 계획하고 Claude Code에서 구현한다. 법무 팀과 그로스 마케팅 팀이 같은 순서를 적었다. 대화형 인터페이스에서 아이디어를 충분히 펼친 다음, 단계별 프롬프트로 정리해 달라고 요청하고 그것을 들고 Claude Code로 옮긴다.
• 메모리 파일로 자기 사정을 알린다. 프로덕트 디자인 팀은 “나는 코딩 경험이 적은 디자이너이고 상세한 설명과 작은 증분 변경이 필요하다"는 지시를 넣어 두었다. 응답 품질이 눈에 띄게 좋아졌고 도구가 덜 위압적으로 느껴졌다고 한다.
• 화면을 붙여 넣는다. 프로덕트 디자인 팀과 법무 팀, 데이터 인프라 팀 모두 스크린샷과 목업을 그대로 넣고 시각적으로 반복하는 방식을 쓴다.
• 팀끼리 사용 장면을 공유한다. 데이터 인프라 팀은 서로의 워크플로우를 시연하는 세션을 열었고, 혼자서는 발견하지 못했을 사용법이 그 자리에서 퍼졌다고 했다.
• 어설픈 프로토타입도 내놓는다. 법무 팀은 장난감처럼 보이는 시제품을 숨기려는 마음을 넘어서라고 적었다. 그런 시연이 평소 접점이 없는 부서에까지 아이디어를 퍼뜨린다는 것이다.

자료가 함께 적어 둔 실패와 한계

RL 엔지니어링 팀의 기록이 가장 솔직하다. 이 팀은 중소 규모 PR을 적은 시간으로 처리할 수 있게 되었다고 적었다. 그러면서도 첫 시도만으로 되는 경우는 약 3분의 1이고, 나머지는 추가 안내나 사람의 개입이 필요하다고 덧붙였다. 주석을 자동으로 붙여 주는 것은 도움이 되지만 이상한 위치에 달리거나 코드 구성이 의심스러울 때가 있다고 했다. 디버깅에서는 결과가 일정하지 않았다. 문제를 즉시 찾아내고 관련 테스트까지 붙여 주는 경우가 있는가 하면, 문제 자체를 이해하지 못하는 경우도 있다.

데이터 사이언스 팀의 슬롯머신 비유도 성공률을 낮게 본 표현이다. 30분치 작업을 통째로 버릴 수 있다는 것을 전제로 하기 때문이다. 프로덕트 디자인 팀은 비개발자의 초기 저장소 설정과 권한 부여가 어렵다는 점을 인정하면서, 엔지니어 동료의 도움을 받으라고 권했다.

법무 팀은 제품을 담당하는 변호사로서 다른 종류의 위험을 봤다. MCP를 깊이 연동할 때의 보안 함의가 즉시 눈에 들어왔고, AI 도구가 더 민감한 시스템에 접근할수록 보수적인 보안 태세가 장벽이 될 것이라고 적었다. 그래서 컴플라이언스 도구를 빠르게 만들어 두어야 한다는 주장을 함께 남겼다.

웹 요약판과 다른 점

2025년 7월 24일 블로그에 올라온 요약판은 같은 인터뷰를 팀 단위에서 주제 단위로 다시 묶었다. 코드베이스 탐색, 테스트와 코드 리뷰, 디버깅, 프로토타이핑, 문서화, 자동화의 여섯 갈래다. 그렇게 다시 묶는 동안 몇 군데가 달라졌다.

• 어떤 사례가 어느 팀 것으로 적혀 있는지 달라졌다. PDF에서 Vim 키 바인딩은 Claude Code 팀(프로덕트 개발)의 작업이고, 요약판에서는 프로덕트 디자인 팀이 Figma 파일을 넣고 자율 루프를 돌려 만든 것으로 서술된다. “첫 정거장"이라는 표현도 PDF에서는 API 팀의 말이지만 요약판에서는 프로덕트 엔지니어링 팀의 말로 적혔다.
• 수치의 표현도 다르다. 보안 엔지니어링 팀 사례는 요약판에서 “3배 빠르게"로 바뀌었고, 쿠버네티스 장애 사례에는 PDF에 없는 “20분 절약"이 붙었다.
• 데이터 사이언스 팀의 5,000줄 앱은 요약판에서 “샌드박스 환경에서 원샷 프롬프트로” 만든 것으로 서술된다. PDF에는 샌드박스 이야기가 없고, 대신 30분 슬롯머신과 반복 시도가 적혀 있다.

두 판본이 어긋나는 대목에서는 인터뷰 원본에 더 가까운 PDF를 기준으로 정리했다.

가장 흥미로운 지점

내가 두 번 읽은 문장은 프로덕트 디자인 팀이 사용자 경험을 두 갈래로 나눈 대목이다. 개발자에게 이 도구는 “증강된 워크플로우"를 준다. 원래 할 수 있던 일이 빨라지는 것이다. 비개발자에게는 “맙소사, 내가 개발자가 됐다"는 경험을 준다. 전에는 시작조차 할 수 없던 일이 가능해지는 것이다. 같은 제품이 사람에 따라 전혀 다른 사건이 된다. 그리고 자료 전체는 이 두 종류의 이야기를 나란히 싣고 있다.

그리고 법무 팀원의 접근성 앱을 오래 생각했다. 언어치료사가 권한 도구들에 없던 기능을, 코드를 쓰지 않는 사람이 한 시간에 만들었다. 회사가 이 자료를 만든 목적은 사내 생산성을 보여 주는 것이었을 텐데, 열 개 팀 가운데 가장 또렷하게 기억에 남는 사례는 말을 잃은 가족과 다시 대화하려고 만든 앱이었다.

한 가지가 더 눈에 걸렸다. 이 자료에 적힌 운용법의 대부분은 지금 보면 특별할 것이 없다. 지침 파일을 상세히 쓰고, 체크포인트를 자주 커밋하고, 테스트를 먼저 생성하게 하고, 민감한 데이터에는 MCP 서버를 두는 것이 모두 그런 예다. 1년 전에는 열 개 팀이 이것들을 각자 따로 발견하고 있었고, 회사는 그 발견을 모아 문서로 만들어야 했다.

출처

Anthropic, “How Anthropic teams use Claude Code” (사내 인터뷰 자료, 23쪽, 2025년 6월 제작)

• 원문 PDF: https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135ad8871e7658.pdf
• 블로그 요약판: https://claude.com/blog/how-anthropic-teams-use-claude-code (2025년 7월 24일)

자료는 Anthropic이 자사 제품의 사내 사용 사례를 정리한 것이므로, 위에 옮긴 효과와 수치는 모두 각 팀의 자체 보고다. 독립적으로 측정되거나 검증된 값이 아니다.

원문 PDF에는 인용할 도식이나 사진이 없어 삽화는 치비 서소영 라인아트로 대신했다. 블로그 글 「느낌적인 느낌을 숫자로 옮기는 일」의 치비 서소영 라인아트를 참조하여 gpt-image-2.5-flare image-to-image로 생성했다.