에이전트 시대를 여는 Salesforce 엔지니어링의 대전환

https://www.salesforce.com/news/stories/how-engineering-became-agentic/

핵심 요약

이제 자율형 도구들이 소프트웨어 개발 생애주기 전반에서 코드를 작성하고, PR(풀 리퀘스트)을 리뷰하며, 배포를 주도하고 있습니다.

Claude Code로 표준을 통일하고 토큰 제한을 없애자 산출량과 품질이 동시에 향상되었습니다. 더 많이 배포하면서도 사고와 버그는 줄었습니다.

에이전트 워크플로우 덕분에 한 제품 팀은 231 인일이 걸릴 작업을 13일 만에 마쳤고, 이는 18배 빠른 속도입니다.

엔지니어링, 제품, 디자인 각 역할이 어떻게 달라질지에 대해서는 아직 초기 단계이며, 계속 재정의되는 중입니다.

몇 달 전, 저는 수천 명의 엔지니어가 정말로 AI를 쓰게 만드는 일이 얼마나 어렵고 중요한지에 대해 쓴 적이 있습니다. 단지 이름만 도입하는 것이 아니라, 실제 업무 방식에 깊이 녹여내는 일이 목표였죠. 이를 위해 우리는 거버넌스 골격을 세우고, 측정 인프라를 구축하고, 워크플로우를 설계해 모두 현실화했습니다. 그리고 엔지니어의 90% 이상이 AI를 사용하게 만들었습니다. 그때는 분명 하나의 이정표처럼 느껴졌습니다.

알고 보니, 그건 시작에 불과했습니다.

지금 Salesforce 엔지니어링 조직은 AI 위에서 돌아가고 있습니다. 우리는 AI가 유용한 ‘코파일럿’이던 시기를 넘어, 에이전트형 도구가 소프트웨어 개발 생애주기(SDLC) 자체를 주도하는 단계로 넘어왔습니다. 코드 작성, PR 리뷰, 테스트 생성, 문서 갱신, 배포 관리, 그리고 과거에는 사람 간의 인수인계가 필수였던 일을 점점 더 많이 조율하고 있습니다. 제가 커리어에서 경험한 변화 중 가장 가파르고 빠른 전환입니다.

지금부터 그 전환이 실제로 어떤 모습인지, 무엇이 이를 이끌었는지, 그리고 우리가 무엇을 배우고 있는지 공유하려 합니다.

Claude Code로의 전사 차원 온보딩

가장 큰 전환점은 조직 전체가 의도적으로 Claude Code를 핵심 AI 에이전트 도구로 삼기로 한 결정이었습니다. 우리는 이를 모든 엔지니어에게 배포했습니다. 그리고 그보다 더 분명한 신호를 하나 보냈습니다. 토큰 제한을 전부 없앤 것입니다. 우리의 최우선 지침은, 엔지니어와 그들을 더 빠르고 더 유능하게 만들어 줄 도구 사이에 있는 모든 마찰을 제거하는 것이었습니다.

결과는 데이터로 드러나고 있습니다. 2026년 4월 기준, 개발자 1인당 완료한 작업 항목 수는 2025년 4월 대비 50.8% 증가했습니다. 개발자 1인당 머지된 PR 수는 79% 늘었습니다. 그리고 가장 중요한 지표, 단순 코드 양이 아니라 실제 전달된 코드의 가치를 기계 학습 기반 효과적 산출 점수(Effective Output score) 로 측정해 보면, 연간 기준 151.3% 증가를 확인했습니다.

에이전트 전환이 실제로 의미하는 것

숫자는 이야기의 일부만 말해 줍니다. 우리 제품 팀 사례 하나가 이 변화를 더 잘 보여줍니다.

한 제품 팀은 33개 API 엔드포인트를 새로운 클라우드 네이티브 아키텍처로 마이그레이션해야 했습니다. 전통적인 방식으로라면 약 231 인일, 즉 엔드포인트 하나당 7일 정도가 드는 작업입니다. 스키마 매핑, 테스트, 문서화까지 모두 수작업으로 진행하면 마찰이 엄청나게 커지고, 모멘텀은 떨어지며, 엔지니어링 팀 전체가 수개월 동안 낮은 레버리지의 반복 업무에 묶이게 됩니다.

이 팀은 이 작업을 13일 만에 끝냈습니다. 무려18배 빨랐습니다.

방법은 이랬습니다. 팀은 Claude를 활용해 규칙 기반 프레임워크를 만들었습니다. 마크다운 파일과 레퍼런스 구현을 결합해, AI가 자동화하는 마이그레이션 절차를 표준화했습니다. 매번 PR에서 나온 피드백은 모두 규칙 세트에 다시 반영해 정확도를 지속적으로 높였고, 결과물은 거의 프로덕션 수준에 가까운 상태로 도착했습니다. LLM이 스스로 돌 수 있는 빌드–수정–검증 루프를 자율적으로 돌게 두고, 격리된 여러 환경에 걸쳐 마이그레이션을 병렬로 수행해 동시에 여러 PR을 만들어 냈습니다. 33개 엔드포인트, 5개의 PR. 이 중 가장 큰 하나의 PR은 21개 엔드포인트를 담고 있었고, 테스트 커버리지는 100%였습니다.

이건 기존과는 완전히 다른 방식의 소프트웨어 빌드입니다.

생산성 향상과 품질 향상을 동시에 달성하다

AI를 이 정도로 전면에 내세우면, 회의적인 사람들은 이렇게 묻습니다. “그래서 어디가 깨졌나요?”

수백 개 시스템에서 보안, 가용성, 품질, 개발자 생산성을 추적해 하나로 모으는 플랫폼인 [Engineering 360]의 답은 명확합니다. 품질은 올라갔습니다. PR 수가 이렇게 늘었는데도, 전체 인시던트는 5% 감소했습니다.

이는 매우 중요한 지점입니다. 생산성과 품질은 종종 서로 맞바꾸는 관계로 인식되기 때문입니다. 우리는 그런 트레이드오프를 보고 있지 않습니다. 우리의 최우선 가치는 ‘신뢰’이며, 엔지니어들은 AI라는 초능력을 품질과 비기능 요구사항의 최고 기준을 충족하는 데 쓰고 있습니다. 예를 들어, 우리는 에이전트 워크플로우 구조 속에 보안 가드레일과 품질 기준을 아예 내장했습니다. 에이전트 도구를 올바르게 적용하면, 속도 때문에 품질이 희생되는 것이 아니라, 오히려 품질이 향상됩니다.

SDLC를 다시 설계하다

4개월 전만 해도, 우리는 엔지니어들이 AI를 받아들이도록 하려면 기존 워크플로우 안에 AI를 맞춰 넣어야 한다는 교훈을 얻었습니다. 이제 엔지니어들이 AI를 완전히 받아들인 뒤에는, 같은 엔지니어들이 AI를 사용해 그 워크플로우 자체를 완전히 허물고 다시 짜고 있습니다.

우리 엔지니어들은 SDLC를 수행하는 방식을 근본적으로 다시 생각하고 있습니다. 어떤 프로세스는 아예 제거할 수 있을까? 어떤 인수인계는 사실 필요 없었을까? 어디에서 여전히 사람이 하고 있는 일을 에이전트에게 완전히 맡길 수 있을까? 이런 질문들이야말로 진짜 생산성, 즉 주변부 개선이 아닌 근본적 생산성을 끌어올리는 열쇠입니다. 그리고 이 모습은, 예전처럼 기존 프로세스에 AI를 덧대 붙이는 형태와는 전혀 다릅니다.

스킬, 서브에이전트, 그리고 새로 정의되는 엔지니어링 장인정신

가장 흥미로운 변화 중 하나는, 엔지니어들이 단순히 도구 사용자를 넘어, 각자 에이전트 워크플로우의 빌더가 되어 가는 모습입니다. 팀의 컨텍스트, 네이밍 관례, 워크플로우 패턴을 코드화한 Claude Code 스킬은 새로운 형태의 엔지니어링 산출물이 되었습니다. 팀들은 이러한 스킬을 만들고, 서로 공유하며, 서로의 작업 위에 쌓아 올리고 있습니다.

우리는 또 AI Expert Suite와 Salesforce Foundation Plugins를 구축했습니다. 이는 Salesforce 엔지니어링 워크플로우에 특화된 AI 스킬을 엄선해 제도화한 라이브러리로, 모든 개발자가 처음부터 새로 시작하는 대신 검증된 공통 기반 위에서 작업을 쌓아 올릴 수 있게 해 줍니다. 내부 벤치마크 결과에 따르면, 이러한 큐레이션된 스킬들은 Salesforce 특유의 코딩 작업에서 정확성과 신뢰성을 높이는 동시에 불필요한 비용을 줄여 주는 것으로 나타났습니다.

서브에이전트와 에이전트 팀 — 즉, 더 큰 작업 안에서 병렬 워크스트림을 담당하는 범위가 명확히 정의된 AI 에이전트들 — 은 복잡한 작업을 쪼개는 방식을 바꾸고 있습니다. 이제 엔지니어가 하나의 태스크를 진행하기 위해 5개의 시스템 사이를 끊임없이 오가며 컨텍스트 스위칭을 할 필요가 없습니다. 원하는 결과를 설명하면, 조율된 에이전트 집합이 필요한 단계를 스스로 찾아냅니다.

이것은 완전히 새로운 형태의 엔지니어링 장인정신입니다. 오늘날 가장 중요한 역량은, 문제를 에이전트 시스템이 잘 받아들일 수 있게 구조화하는 법, 언제 업무를 에이전트에 위임하고 언제 직접 개입해야 하는지 판단하는 법, 그리고 팀이 함께 쌓아 갈 수 있는 재사용 가능한 패턴을 만드는 법을 아는 것입니다.

아직 풀어야 할 과제들

여전히 쉽지 않은 부분도 적지 않습니다.

긴 에이전트 세션과 복잡한 에이전트 흐름에서 컨텍스트를 관리하는 일은, 지금도 엔지니어들이 몸으로 익혀 가는 일종의 기술입니다. 코드베이스, 관례, 제약을 Claude에 설명해 주는 지속적 컨텍스트 설정 파일인 CLAUDE.md의 품질은 팀마다 큰 차이를 보이고, 이 차이가 결과물 품질에도 상당한 영향을 줍니다.

에이전트가 실제로 시스템에 행동까지 취할 수 있는 세계에서는, 보안 모델 역시 근본적으로 달라져야 합니다. 이제 에이전트는 단순히 제안만 하는 것이 아니라, 직접 작업을 수행할 수 있습니다. 잘못 구성된 도구 하나가 줄 수 있는 피해 범위가 훨씬 커진 것입니다. 우리는 에이전트 기반 SDLC 전 구간을 대상으로 보안을 강화하는 데 집중적으로 투자하고 있습니다.

역할의 진화 역시 실제로 진행 중이며, 매우 심각하게 고민할 만한 주제입니다. 에이전트가 실행 계층의 더 많은 부분을 맡게 되면, 입문 수준의 업무 상당 부분을 AI가 흡수하는 상황에서 주니어 엔지니어는 어떻게 시니어로 성장해야 할까요? 디자이너와 제품 매니저의 역할은 어떻게 바뀔까요? 우리의 기본 실행 단위는 오랫동안 스크럼 팀이었습니다. 이 단위는 어떻게 달라질까요? 보안 계층 같은 인프라 레이어와 제품 레이어 역시 같은 방식으로 변할까요? 우리는 한 명짜리 또는 세 명짜리 팀을 단위로 삼는 여러 실험을 진행 중이지만, 아직 명확한 정답은 없습니다. 다만, 이 문제들을 선제적으로 고민하는 팀이 결국 더 앞서 나가리라는 점은 분명합니다.

방향은 이미 명확하다

제가 앞선 글에서 말했듯, 우리의 초기 목표는 기반을 구축하는 것이었습니다. 우리는 그 기반을 세웠습니다. 그리고 지금은 그 위에, 매우 빠른 속도로 새로운 것을 쌓아 올리고 있습니다.

미래의 엔지니어링 조직은, 오늘날 조직의 위에 AI를 얹어 붙인 모습과는 닮지 않을 것입니다. 완전히 다른 형태일 것입니다. 앞서 소개한 제품 팀은 단지 속도를 높인 것에 그치지 않았습니다. 그들은 무엇이 경제적으로 가능한지의 경계를 바꾸었습니다. 지금 우리 조직 전체가 바로 그 변화를 확장해 나가는 중입니다.

우리의 목표는 업계에서 가장 자동화되고, 가장 에이전트 중심적인 SDLC를 구축하는 것입니다. 이 글은 그 여정에서 우리가 어디까지 와 있는지에 대한 하나의 중간 보고입니다. 여러분 각자가 실무자이자 운영자로서 어떤 여정을 걸어가고 있는지, 경험을 나눠 주시면 좋겠습니다.

더 깊이 살펴보기

우리가 어떻게 엔지니어들이 AI를 쓰도록 만들었는지— 그리고 그 과정에서 아무것도 망가지지 않게 했는지
Agentic Enterprise를 위한 여덟 가지 설계 원칙