에이전트가 '개발팀 바깥'으로 나갔다
지금까지 AI 코딩 도구 도입 논의는 대부분 개발팀 내부에서 끝났다. 코드 생성, 리뷰 자동화, CI/CD 최적화—모두 엔지니어가 주어인 이야기였다. 그런데 최근 세 가지 신호가 동시에 나타나면서 이 경계가 빠르게 허물어지고 있다.
앤트로픽은 Claude Cowork를 전 유료 요금제로 전면 확대하면서 흥미로운 숫자를 공개했다. Cowork 사용의 대부분이 엔지니어링 외 부서에서 발생하고 있다는 것이다. 운영, 마케팅, 재무, 법무 팀이 AI 협업 도구의 실질적 주 사용자가 됐다. 이건 단순한 기능 확장이 아니다. AI가 조직 전체의 워크플로우 인프라로 자리잡는다는 신호다.
같은 시점에 AWS는 금융권 대상 'AI-DLC(AI 주도 개발 라이프사이클)' 실증 행사를 열었다. NH농협은행, KB국민은행, 신한은행, 하나은행 등 24개 금융사 팀이 참여해 Amazon Q Developer와 Kiro를 활용, 요구사항 정의부터 설계·개발·테스트·운영까지 전 주기를 AI로 수행하는 경험을 실전 검증했다. KB증권은 6개월 동안 6개의 AI 에이전트를 출시했고, 카카오페이증권은 'AI가 직원처럼 업무를 지원하는 구조'를 이미 운영 중이다. 보수적인 금융 IT에서 이 속도가 나온다면, 일반 테크 팀에서 AI 확산을 늦출 이유는 사실상 없다.
'AI-First 팀'이 실제로 의미하는 것
이 흐름을 팀 리빌딩 관점에서 냉정하게 해석하면 세 가지 구조 변화로 요약된다.
첫째, AI 도구의 주권이 개발팀에서 조직 전체로 이동한다. Claude Cowork의 RBAC(역할 기반 접근 제어), 그룹별 예산 한도, OpenTelemetry 기반 감사 로그는 IT 부서가 아닌 경영진과 관리자가 AI를 직접 제어하겠다는 설계다. 개발팀이 AI 도구의 게이트키퍼 역할을 잃는다는 뜻이기도 하다. 이걸 위협으로 볼 것인가, 기회로 볼 것인가는 팀 리드의 포지셔닝 전략에 달려 있다.
둘째, AI-DLC는 역할 경계를 다시 그린다. AWS가 제시한 AI-DLC 방법론—요구사항 정의부터 설계·개발·테스트·운영까지 AI가 주도하고 사람은 의사결정에 집중—은 이미 Claude Code의 실전 활용 패턴에서도 확인된다. Claude Code는 코드베이스를 읽고, 파일을 편집하고, 명령을 실행하고, 개발 도구와 통합하는 에이전트 코딩 도구다. CLAUDE.md로 프로젝트 컨벤션을 주입하고, 서브에이전트로 병렬 작업을 분산하고, Hooks로 ESLint 자동 실행까지 연결하면—이미 주니어 수준의 반복 작업 상당수가 에이전트 레이어로 내려간다. 이때 시니어 엔지니어의 역할은 코드 작성자에서 에이전트 오케스트레이터로 바뀐다.
셋째, 비개발 부서의 AI 활용이 개발팀의 병목을 만든다. 마케팅이 Cowork로 캠페인 자동화를 돌리고, 법무가 계약서 분석을 AI에 맡기기 시작하면, 개발팀에 API 연동·데이터 파이프라인·보안 검토 요청이 폭증한다. 이 병목을 미리 설계하지 않으면 AI 확산이 오히려 개발팀 부하로 돌아온다. Cowork의 Zoom 연동, Slack·Jira 커넥터가 '비개발 부서 자립'을 지원하는 것처럼, 개발팀도 비개발 팀이 스스로 AI를 운용할 수 있는 인프라를 먼저 깔아야 한다.
팀 리빌딩 실전: 지금 당장 설계해야 할 세 가지
1. AI 확산 거버넌스 먼저. Claude Cowork의 RBAC과 예산 한도, OpenTelemetry 감사 로그는 단순한 관리 기능이 아니다. 조직 전체로 AI가 번지기 전에 '누가 무엇을 얼마나 쓸 수 있는지'를 설계하지 않으면, 비용 폭주와 보안 공백이 동시에 터진다. AWS의 금융권 사례에서도 폐쇄망 환경에서 리스크 없이 검증할 수 있는 샌드박스 설계가 먼저였다. 팀 리드라면 AI 도구 도입 전에 거버넌스 레이어를 스펙으로 정의해야 한다.
2. AI 활용 온보딩을 부서별로 다르게 설계하라. 개발팀과 비개발 팀의 AI 학습 곡선은 다르다. Claude Code는 터미널과 IDE에 익숙한 엔지니어 중심 도구고, Cowork는 비개발 직군이 슬랙·줌 워크플로우 위에서 바로 쓸 수 있는 도구다. 같은 온보딩 프로세스를 전사에 적용하면 둘 다 실패한다. AI-First 팀 리빌딩에서 온보딩은 '도구 사용법 교육'이 아니라 부서별 워크플로우 재설계다.
3. 사용량 데이터를 ROI 측정 기준으로 삼아라. Cowork의 사용량 분석 기능—팀별 활용 현황, 활성 사용자 수, 효과적으로 적용된 업무 영역—은 AI 투자 정당화를 위한 데이터 인프라다. KB증권이 6개월에 6개 에이전트를 출시하며 생산성과 사용자 만족도를 동시에 끌어올렸다고 발표할 수 있는 것도 측정 기준이 있었기 때문이다. 감이 아니라 데이터로 AI ROI를 증명하지 못하면, 조직 내 AI 예산은 언제든 삭감 대상이 된다.
지금이 팀 구조를 바꿀 마지막 선제 타이밍이다
에이전트가 개발 라이프사이클 전체를 덮고, 비개발 부서까지 AI 협업 도구가 정식 인프라로 자리잡는 지금—팀 리빌딩의 적기는 '준비가 됐을 때'가 아니라 '확산이 시작된 바로 지금'이다. 금융권처럼 보수적인 환경에서도 AI-DLC가 현장 실증을 통과했다면, 일반 테크 팀에서 '아직은 시기상조'라는 말은 더 이상 방어 논리가 되지 않는다.
다만 낙관론에 브레이크 하나는 달아두자. Cowork 사용의 대부분이 엔지니어링 외 부서에서 발생한다는 사실은, 비개발 팀이 AI를 잘 쓴다는 뜻이 아니라 개발팀이 아직 AI를 충분히 못 쓰고 있다는 뜻일 수도 있다. 에이전트 확산의 주도권을 비개발 부서에 넘길 것인가, 개발팀이 조직 전체의 AI 인프라를 설계하는 역할로 올라설 것인가—그 선택이 팀 리빌딩의 방향을 결정한다.