Anthropic이 세일즈포스의 Claude Code 도입기를 16분짜리 대담으로 공개했습니다. 세일즈포스 사장 겸 CTO 무랄리다르 크리슈나프라사드(Muralidhar Krishnaprasad)와 Distinguished Architect 리처드 팩(Richard Pack)이 나왔습니다. 엔지니어 수천 명에게 Claude Code를 퍼뜨린 방법과, 그걸 어떻게 쟀는지가 중심입니다.
근거: Anthropic 영상 How Salesforce uses Claude Code(2026.11.06, 16분 17초)의 영어 자막, claude.com/office-hours의 세일즈포스 소개. 2026년 11월 7일에 보고 읽었습니다. 괄호 안 시각은 영상 위치입니다.
1년짜리 헤드리스 작업을 몇 달에
세일즈포스는 수십 년 된 회사라 모든 기능에 API가 있지는 않았습니다. 설정 화면을 하나하나 뒤져 빈 API를 메우는 일은 “반년에서 1년짜리 프로젝트”로 봤습니다. Claude Code로 이 일을 몇 주에서 몇 달 사이에 끝냈고, 지금 전체 클라우드의 API 커버리지는 8090%라고 합니다. 팀 사이 회의 없이 했다는 점을 따로 짚었습니다(0:351:08). Claudeforce도 이 헤드리스 전환 덕에 나올 수 있었다고 합니다.
코드 줄 수 대신 유효 산출
성과를 코드 줄 수로 재면 주석만 늘려도 올라갑니다. 그래서 스탠퍼드 연구진과 함께 유효 산출(effective output)이라는 점수를 만들었습니다. 주석이나 단순한 수정은 낮게, 로직을 바꾸거나 새로 만든 코드는 높게 칩니다. 들인 돈 대비 이 점수가 두 배가 됐다고 합니다(1:45~2:31). 지금은 다른 부서에도 맞는 지표를 찾는 중이고, 도입 전후와 토큰 사용량을 함께 봅니다. 차이가 없으면 잘못 쓰고 있는지, 맞지 않는 도구인지 따집니다.
에이전트 성숙도 네 단계
열심히 퍼뜨린 뒤에도 사람들은 자잘한 일에만 Claude Code를 썼습니다. 그래서 Anthropic과 함께 에이전트 성숙도 단계를 만들었습니다(3:35). 대담에서 설명한 순서는 이렇습니다(4:21~5:27).
- 그냥 시키기. 누구나 여기서 시작합니다. 좋은 결과가 뭔지 말하지 않아서, 긴 작업에서는 기대만큼 안 나옵니다.
- 좋은 결과를 적고 계획 세우기. 좋은 것과 나쁜 것을 프롬프트에 적고, 전체 계획을 세웁니다.
- 서브에이전트·워크트리로 나란히. 하네스가 일을 쪼개 나란히 돌리게 합니다.
- 자율 실행. CI에서 테스트가 깨지면 에이전트가 고치고, 다른 에이전트가 코드 리뷰를 하고 합칩니다.
한두 달 만에 많은 엔지니어가 3·4단계로 올라갔고, 산출이 두 배가 되면서 품질도 높아졌다고 합니다. 지금은 수천 명이 자율 모드로 일합니다.
퍼뜨린 방법
설명보다 보여 주기였습니다. 각자 “나는 이렇게 일한다”며 문제를 라이브로 푸는 데모를 많이 했고, 클라우드마다 몇 달 걸릴 일을 몇 주에 만든 사례가 드림포스에서 발표하는 실제 제품으로 나왔습니다(5:57~6:21). 한 아키텍트는 남의 코드를 이해하려고 서너 팀과 회의하던 며칠이 없어졌다고 했습니다.
장애 대응 에이전트는 이제 팀마다 하나씩 있습니다. 바깥 서비스로 호출이 왔는데 원인은 안쪽 서비스였던 날, 에이전트가 원인과 담당 팀을 찾아 그 팀을 호출하고 담당자까지 알려 줬습니다. 아홉 팀이 잠에서 깰 뻔했다고 합니다(7:01~7:25).
스킬 마켓플레이스와 평가
잘 만든 스킬은 사내 마켓플레이스에 모읍니다. 스킬을 쓴 세션과 안 쓴 세션을 다시 돌려 비교하는 평가를 붙이고, Claude가 토큰을 덜 쓰거나 더 빨리 결론에 닿도록 스킬 개선안을 내게도 합니다. 결과가 나아진다는 게 보이는 스킬만 퍼집니다(7:36~8:12). 저장소가 수천 개라, 처음 보는 코드베이스에서 버그를 고치고 좋은 PR을 내는 작업 흐름도 스킬로 나눠 둡니다.
코드는 두 배, 버그는 덜
최근 몇 달 사이 코드 양이 거의 두 배가 됐습니다. 버그와 장애도 두 배가 될까 걱정했지만, 평균으로 보면 코드당 버그는 오히려 줄었다고 합니다(9:34~10:04). 기존 검토 장치와 새 장치를 그대로 지킨 덕이라고 설명했습니다.
새 모델이 나오면 일관되게 라벨이 붙은 지난 티켓과 PR로 만든 벤치마크를 다시 돌려 비용과 품질을 봅니다. 모델들이 늘 실패하던 긴 작업(fail to fail) 목록도 따로 두고, 그게 통과되면 새 모델로 갈아탈 이유로 봅니다(10:29~11:35).
검증 없는 자율은 자신감 연극
리처드 팩의 말입니다. “Autonomy without validation is confidence theater.”(11:37) 에이전트에게 스스로 검토하라고 하는 대신, 좋은 결과와 나쁜 결과의 기준을 먼저 정합니다. 예를 들어 새 스키마를 만들라고 했는데 기존 엔티티에 필드를 더하지 않았는지, 다른 걸 망가뜨리지 않았는지 같은 부정 조건입니다. 그리고 찾은 특징과 실패 징후의 증거를 표로 보여 달라고 합니다.
작업은 잘게 쪼개 주지 않습니다. 스토리 포인트가 큰 덩어리로 맡기고, 쪼개는 일은 모델과 하네스에 넘깁니다. 몇 분이면 끝날 일만 대화로 바로 처리합니다. 앞단의 계획이 좋을수록 결과도 좋다고 합니다(12:47~13:48).
가장 큰 실수는 모델 고르기
지난 1년 동안 가장 크게 틀린 건 작업에 맞는 모델을 고르지 않은 것이었습니다. 간단한 파일을 만드는 데도 무거운 모델을 쓰고 있었다고 합니다. 기준은 작업의 길이와 복잡도입니다(13:56~14:14).
반대 사례도 나왔습니다. 몇 번 조사해도 원인을 못 찾던 버그에 Opus를 붙여 코드를 고치고 빌드하며 디버그하게 했더니, 24시간 뒤 원인을 찾아 수정안까지 냈습니다. 고객의 재무에 닿는 업무 소프트웨어라 이 경우에도 검증이 가장 중요했다고 덧붙였습니다(14:23~15:05).
조언
리처드 팩은 엔지니어에게 “대담하게(Be bold)“라고 했습니다. 크리슈나프라사드 CTO는 위에서 내려오는 방식만으로는 안 되고, 아래에서 올라오는 혁신을 알맞은 안전장치와 함께 열어 두라고 했습니다. office-hours 페이지에 실린 그의 말은 “사람들에게 마음껏 쓰게 하고, 그다음 알맞은 안전장치를 두라”입니다.
오늘 할 일
다음 프롬프트에 두 줄을 더해 보세요. 좋은 결과의 기준 한 줄, 건드리면 안 되는 것 한 줄. 세일즈포스가 성숙도 2단계로 꼽은 습관이고, 리처드 팩이 말한 검증의 출발점입니다.