Salesforce가 공개한 숫자 하나가 팀 설계에 대한 내 생각을 완전히 바꿔놨다. 2026년 4월 기준, 그들의 엔지니어링 산출량은 전년 대비 151.3% 증가했다. 개발자 1인당 머지된 PR은 79% 늘었고, 완료된 작업 항목은 50.8% 증가했다. 헤드카운트를 두 배로 늘린 게 아니다. 팀이 AI 에이전트를 중심으로 작동하도록 구조를 바꾼 결과다.
이게 진짜 변곡점이다. "AI가 개발자를 더 빠르게 만든다"는 건 이미 알고 있었다. 지금 일어나는 건 그다음 단계—"AI가 엔지니어링 팀의 모습 자체를 바꾼다"는 것이다. 대부분의 조직은 아직 이 전환을 따라잡지 못하고 있다.
도구 차원에서는 두 가지 신호가 동시에 왔다. GitHub은 Microsoft Build 2026에서 Copilot 데스크톱 앱을 공개했다. 각 세션이 독립된 git worktree에서 실행되어 에이전트가 충돌 없이 병렬로 작동한다. 세션마다 모델을 선택하고(Anthropic, OpenAI, GitHub 자체 모델), MCP 서버를 연결하고, 반복 작업을 재사용 가능한 스킬로 패키징할 수 있다. 단순한 자동완성 도구가 아니라 병렬 에이전트 오케스트레이션 플랫폼으로의 전환 선언이다. 같은 날 IBM은 서울에서 'IBM Bob'을 국내 첫 공개했다. 기획부터 개발, 테스트, 배포, 운영, 보안까지 SDLC 전 과정을 아우르는 AI 파트너다. IBM 내부에서 이미 관련 코드의 40%를 Bob이 작성하고 있고, 10만 명 이상이 매일 사용 중이며, SDLC 전반에서 평균 45% 생산성 향상을 확인했다고 IBM은 밝혔다.
두 제품이 가리키는 방향은 같다. 에이전트는 이제 특정 단계의 보조 도구가 아니라 SDLC 전체를 커버하는 운영 레이어가 되고 있다. 그리고 바로 여기서 팀 구조 문제가 시작된다.
IBM의 마이클 쿽 부사장이 짚은 지점이 핵심이다. "AI가 개인 코딩 속도를 높였을지 몰라도 기업 전체 배포 속도는 여전히 제자리걸음이다." 코드 작성 속도는 올랐는데 배포 속도가 안 따라온다면, 병목은 코드 바깥에 있다는 뜻이다. 인프라 비용, 보안 정책, 레거시 의존성, 조직 구조—이 복합적인 마찰을 에이전트 혼자 해결할 수 없다. 팀이 그 마찰을 설계로 제거해줘야 한다.
그렇다면 에이전트 시대에 팀은 무엇을 설계해야 하는가. 세 가지로 정리할 수 있다.
첫째, 역할 분리를 재정의하라. 에이전트가 실행을 담당하면 인간의 레이어는 판단, 아키텍처, 품질로 좁혀진다. Anthropic의 2026 에이전트 코딩 트렌드 리포트가 정의한 에이전트 시대 개발자 역할은 명확하다: 목표를 정의하고, 출력물을 검토하고, 결과에 책임진다. 2~4인 소규모 팟이 대형 피처팀보다 빠른 이유도 여기 있다. 에이전트가 볼륨을 처리하는 구조에서 팀 크기는 더 이상 속도 변수가 아니다.
둘째, 거버넌스를 워크플로우에 내장하라. IBM Think 2026 데이터에 따르면 엔터프라이즈 임원의 70%는 자사 AI 거버넌스가 에이전트 속도를 따라잡지 못한다고 답했다. "AI를 자유롭게 써라"는 정책은 에이전트 시대에 작동하지 않는다. 명확한 체크포인트, 책임 소유권, 감사 추적—이 세 가지가 워크플로우에 구조적으로 박혀 있어야 한다. IBM Bob이 초기 단계부터 보안 정책 검증을 자동화하도록 설계된 것도 같은 이유다.
셋째, AI 오케스트레이션을 별도 역량으로 투자하라. AI Orchestrator, RAG Engineer, AI Guardian 같은 역할이 빠르게 등장하고 있다. 이건 개발자 직함을 바꾸는 게 아니다. 프롬프트 아키텍처, 컨텍스트 엔지니어링, 출력물 검증, 인간-AI 핸드오프 설계—다른 스킬셋이 필요한 다른 역할이다. "우리 팀이 Claude를 쓸 수 있는가"보다 "우리 팀이 Claude 출력물을 안정적으로 프로덕션 수준으로 만들 수 있는 워크플로우를 설계할 수 있는가"가 진짜 역량 격차다.
팀 리빌딩을 주도하는 입장에서 솔직하게 말하면, 지금 가장 위험한 선택은 도구만 바꾸는 것이다. GitHub Copilot 데스크톱을 도입하고, IBM Bob을 붙이고, 에이전트 수를 늘려도—팀이 기존 구조 그대로 돌아가면 병목은 이동할 뿐 사라지지 않는다. 도구 스택보다 워크플로우 아키텍처가 먼저다. 어디서 인간 판단이 필요한지 명시하고, 에이전트 출력물 검증 구조를 설계하고, 오케스트레이션 역량을 팀 안에 키우는 것—이게 에이전트가 SDLC를 삼키는 지금, 팀이 해야 할 설계다.
지금 이 전환을 설계하는 팀과 도구 도입에만 집중하는 팀 사이의 격차는 생각보다 빠르게 벌어진다. Salesforce의 151% 숫자는 결과가 아니라 구조의 차이에서 나왔다.