Salesforce가 Claude Code를 개발 전 과정에 활용한 방법

Salesforce 엔지니어링 팀이 Claude Code를 SDLC 전반에 도입한 경험을 소개합니다. 헤드리스 아키텍처 전환을 몇 주 만에 끝낸 사례, 효과적인 출력이라는 생산성 지표, 단순 작업에서 자율 에이전트 워크플로로 넘어가는 단계별 성숙도, 버그 증가 없이 코드량을 늘린 품질 관리 방식을 정리합니다.

⏱ 00:00발표는 Salesforce가 Claude Code 덕분에 가능했던 사례부터 시작합니다. 수십 년간 헤드리스 아키텍처를 써 왔지만 모든 애플리케이션에 API가 제공된 것은 아니어서, 페이지 하나하나를 점검해 API 부족분을 찾는 작업이 필요했습니다.

이 작업은 원래 6개월에서 1년 걸릴 것으로 예상됐지만, Claude Code를 활용해 몇 주에서 몇 달 사이에 끝낼 수 있었습니다. 팀 간 회의 없이도 여러 클라우드 플랫폼의 API 커버리지를 80에서 90퍼센트까지 끌어올렸다고 합니다.

⏱ 01:31진행자는 ROI를 프로젝트 속도, 인력 감소, 팀 생산성 등으로 어떻게 정의하는지 묻습니다. 발표자는 코드 줄 수나 주석 수만으로는 가치를 판단할 수 없다고 지적합니다.

그래서 스탠퍼드 연구진과 함께 '효과적인 출력(effective output)'이라는 개념을 만들었습니다. 간단한 수정이나 주석 추가는 낮은 점수를, 로직 변경이나 새 기능 추가는 높은 점수를 주는 방식으로, 이를 통해 AI 도입 효과와 결과물당 비용을 측정할 수 있었다고 설명합니다.

이 지표 덕분에 팀 성장률을 측정 가능한 방식으로 확인했고, 다른 기능에도 맞는 측정 지표를 설정해 도입 전후를 비교하는 중이라고 말합니다.

⏱ 03:18Salesforce는 거의 모든 SDLC 단계에 Claude Code를 쓰고 있습니다. 초기에는 직원들이 작업을 직접 처리했지만, 점차 체계적인 구조를 도입했습니다. 많은 사람이 여전히 기본적인 작업에만 Claude Code를 쓰는 것을 확인하고, 에이전트 기반 성숙도 곡선을 만들었습니다.

그 결과 한두 달 만에 많은 엔지니어가 기본 작업 단계에서 상위 단계인 P3, P4로 올라갔습니다. 발표자는 모든 기술 스택에서 출력량이 두 배로 늘고 품질도 높아졌으며, 버그나 이슈가 두 배로 늘지는 않았다고 강조합니다.

⏱ 05:31각 단계는 간단한 명령을 주는 것에서 시작합니다. 하지만 좋은 결과의 기준을 명확히 정의하지 않으면 장기 계획이나 큰 작업에서는 쓸만한 결과가 나오지 않습니다. 그래서 무엇을 알아야 하고 무엇을 고려해야 하는지 정리하는 단계가 필요합니다.

다음 단계에서는 팀과 하위 에이전트를 조율하고, 작업 트리를 관리하며 병렬 작업을 최대화하는 도구를 씁니다. 마지막 단계에서는 여러 에이전트를 직접 관리하며 SDLC 전체 워크플로를 운영합니다. 예를 들어 CI/CD에서 테스트가 실패하면 에이전트가 원인을 찾아 수정하고, 다른 에이전트가 코드 리뷰와 병합을 수행합니다. 현재 수천 명의 사용자가 이런 자율 모드로 일하고 있다고 합니다.

가장 큰 과제는 역량 강화였습니다. 상위 단계 도달이 제로섬 게임이 아니라는 점을 설명하고, 직원들이 자신의 작업 방식을 시연하며 서로 배우는 개방적인 분위기를 만들었습니다.

⏱ 09:07사례로 소개된 것은 슬랙 스레드에서 인시던트를 처리한 일입니다. 외부 서비스 호출이 있었지만 실제 원인은 내부 서비스에 있었고, 담당자가 원인과 해결 팀을 정리해 이관하면서 POC를 공유했습니다. 이 과정에서 여러 팀이 동시에 알림을 받기도 했지만, 자동화된 흐름이 빠르게 정리되는 모습을 보여 주었습니다.

팀은 전문가 스위트에서 시작해 각 기술을 마켓플레이스 형태로 공유하는 구조를 만들었습니다. 기술의 효과를 평가하고, 세션을 다시 보며 토큰 효율을 개선하는 방향을 제안하도록 했습니다. 이 과정에서 우버 스킬 마켓플레이스가 만들어졌다고 설명합니다.

수천 개의 리포지토리를 가진 조직에서는 버그 수정을 누구나 할 수 있게 만들기 위해, 낯선 코드베이스에서도 품질 높은 PR을 만들 워크플로를 구성했습니다. 혁신이 아래에서 위로 일어나고, 효과가 확인되면 확장을 지원하는 방식입니다.

⏱ 11:37발표자는 품질을 가장 중요한 안전 장치로 꼽습니다. 다양한 맥락에서 기능과 유용성을 과학적으로 평가하고, 사용자가 달성하려는 목표와 가치 제안이 실제로 실현되는지 확인합니다.

코드량이 거의 두 배로 늘었기 때문에 버그도 두 배로 늘지 않았는지가 항상 우려였습니다. 추적 결과 실제 발생 건수는 훨씬 적었고, 코드 한 줄당 버그 수는 평균적으로 줄었습니다. 가이드라인과 기존 및 새로운 검증 메커니즘이 함께 작동한 결과라고 설명합니다.

또한 티켓 시스템과 PR이 연결된 잘 정리된 데이터셋을 바탕으로 벤치마크를 만들었습니다. 새 모델을 도입할 때 비용과 성능, 장기 작업에서의 실패 패턴을 시뮬레이션해 ROI를 판단할 수 있게 되었습니다.

⏱ 13:52에이전트를 신뢰하기 전에는 객관적인 기준을 세워 결과를 측정합니다. 예를 들어 다른 부분을 손상시키지 않았는지, 새 스키마를 만들라고 했는데 기존 엔티티에 필드를 추가하지 않았는지를 확인합니다. 자기 평가를 맡기기보다, 품질과 실패를 보여 주는 근거를 제시하도록 요구하고 결과를 매트릭스로 정리하게 합니다.

작업 크기는 몇 분 안에 끝나는 작업은 빠른 상호작용 세션으로, 나머지는 큰 덩어리로 묶는 방식이 제안됩니다. 에이전트 팀이 큰 기능을 작은 독립 작업으로 나누고 실행하면, 사람이 직접 분해하는 부담을 줄일 수 있습니다. 사전 계획을 잘 세울수록 결과가 좋아진다고 합니다.

모델 선택에서는 작업의 길이와 복잡성을 기준으로 삼아야 합니다. 단순한 파일 생성에 고성능 모델이 필요하지 않은 경우가 많았습니다. 반면 원인을 찾기 어려운 버그는 Opus가 여러 차례 디버깅과 수정을 거쳐 24시간 만에 해결책을 찾았고, 중요한 비즈니스 소프트웨어인 만큼 검증 과정을 거쳤다고 설명합니다.