AI 코딩 도구의 성능이 빠르게 올라가면서 팀 리드들 사이에서 자주 듣는 질문이 있다. "이제 우리 팀원들이 뭘 잘해야 하나요?" 좋은 질문이다. 그런데 이 질문에 답하려면 먼저 AI가 실제로 무엇을 '대신'하고 무엇을 '증폭'하는지를 구분해야 한다. 2025~2026년 현장에서 나온 두 가지 사례가 그 답을 꽤 직접적으로 보여준다.
AI는 무엇을 증폭하는가—JSONata 재작성의 교훈
Reco의 수석 데이터 엔지니어 Nir Barak은 2026년 3월, 주말 하루 7시간 동안 JSONata 평가 엔진을 JavaScript에서 Go로 재작성했다. API 비용 400달러, 절감 효과 연간 50만 달러. 숫자만 보면 AI의 마법처럼 읽힌다. 하지만 dev.to에 소개된 원문을 보면 이야기가 달라진다.
Barak이 AI와 앉기 전에 이미 갖고 있던 것들을 보자. jsonata-js 공식 테스트 스위트에서 포팅한 1,778개 테스트 케이스, RPC 경계의 직렬화 비용을 수년간 관찰하며 쌓은 파이프라인 도메인 지식, 그리고 수개월 전 다른 최적화 작업을 위해 이미 구축해 둔 섀도 평가 인프라가 있었다. AI의 실제 역할은 이 모든 것을 재료로 받아 '테스트를 통과하는 코드'를 빠르게 생성하는 것이었다. 2티어 평가 전략(단순 표현식 제로-얼로케이션 패스트패스 + 복잡 표현식 풀 파서)이나 배치 평가 아키텍처는 AI가 제안한 게 아니다. Barak이 수년간 시스템을 관찰하며 쌓은 아키텍처 판단에서 나왔다.
16개 에이전트, C 컴파일러, 그리고 '환경 설계자'의 역할
같은 맥락에서 Anthropic 연구원 Nicholas Carlini의 C 컴파일러 프로젝트를 봐야 한다. 16개의 병렬 Claude 에이전트, 2주, 약 2만 달러의 API 비용으로 Rust 기반 C 컴파일러를 만들었다. GCC 토처 테스트 스위트의 99%를 통과하고 Linux 6.9, PostgreSQL, Redis, FFmpeg를 빌드한다.
Carlini 본인이 시간을 쏟은 곳은 코드 작성이 아니었다. 에이전트용 테스트 스위트 설계(콘솔 출력 최소화, 에이전트별 다른 1% 결정론적 샘플링), 16개 에이전트가 동일한 버그에 수렴해 서로의 픽스를 덮어쓰는 상황을 막기 위한 GCC 오라클 분해 전략, 새 기능 추가 시 기존 기능이 깨지는 현상을 막는 외부 CI 회귀 가드레일, 그리고 에이전트 역할 분리 설계였다. 이 구조 없이 16개 에이전트를 루프에 넣었다면 결과물은 컴파일러가 아니라 혼돈이었을 것이다.
무인 코딩이 가능해진 지금, 인프라 레이어가 더 중요해졌다
Anthropicが 최근 공개한 Claude Code Routines는 이 흐름을 한 단계 더 밀어붙인다. 예약·반복 작업을 로컬 기기 없이 웹 인프라에서 자동 실행하는 기능이다. PC가 꺼져 있어도 GitHub 루틴이 돌아간다. 무인 코딩이 실제로 가능해진 것이다. 팀·엔터프라이즈 플랜 기준 하루 25회 실행 한도가 지금은 제약처럼 보이지만, 이 숫자는 곧 올라갈 것이다.
문제는 자동화 범위가 넓어질수록 '무엇을 자동화하고 있는지'를 팀이 구조적으로 파악할 수 있어야 한다는 점이다. 여기서 팀 단위 MCP 서버 중앙화 사례가 직접적인 힌트를 준다. dev.to에서 소개된 한 엔지니어의 사례를 보면, 6개 MCP 서버와 10명의 동료가 생기는 순간 "로컬에서 npx 실행"은 작동을 멈춘다. 매니저는 Docker가 없고, 프로덕션 토큰은 노트북에 흩어지고, CI/CD는 원격에서 MCP에 접근해야 한다.
해결책은 MCP 서버를 팀 인프라로 올리는 것이다. Kubernetes + 범용 Helm 차트 + Envoy JWT 인증 구조를 통해 동료들은 로컬 의존성 없이 동일한 MCP 엔드포인트에 연결하고, 자동화도 같은 경로를 쓴다. 지금 미해결로 남은 과제—사용자별 인가, 감사 로그, 인증 표준의 부재—가 오히려 팀이 지금 당장 설계해야 할 역량이 무엇인지를 역설적으로 드러낸다.
AI-First 팀에 실제로 남아야 할 역량
세 현장을 겹쳐 보면 패턴이 뚜렷하다. AI가 코드를 더 많이 짤수록 팀에 남아야 할 역량은 줄어드는 게 아니라 더 선명하게 분리된다.
첫째, 테스트 인프라 설계 능력. AI는 테스트를 통과하는 코드를 만든다. 테스트가 없으면 AI는 방향을 잃는다. 1,778개 테스트 케이스와 섀도 모드 파이프라인이 없었다면 gnata는 프로덕션에 들어갈 수 없었다. 테스트를 쓰는 능력보다 '어떤 테스트를 설계할 것인가'에 대한 판단이 핵심 역량으로 올라선다.
둘째, 도메인 전문성과 아키텍처 판단. AI는 주어진 문제를 잘 푼다. 문제의 경계를 정의하고 아키텍처 비전을 세우는 건 여전히 인간의 몫이다. Barak의 2티어 전략과 Carlini의 GCC 오라클 분해는 모두 수년의 관찰과 실패에서 나온 것이다.
셋째, 에이전트/도구 운영 인프라 설계. Claude Code Routines가 돌아가고, MCP 서버가 Kubernetes에 올라가고, 16개 에이전트가 병렬로 실행되는 환경에서 필요한 건 코드를 쓰는 능력이 아니라 이 전체를 거버넌스할 수 있는 인프라 설계 역량이다. 인증, 감사, 역할 분리, 회귀 방어—이것들은 AI가 대신해주지 않는다.
전망: '프롬프트 잘 쓰는 팀'은 충분하지 않다
앞으로 AI 코딩 도구는 더 빠르고, 더 자율적이고, 더 오래 혼자 돌아갈 것이다. 그 속도에 비례해서 팀이 미리 깔아두지 않은 것들의 부재가 더 빠르게 표면화된다. $400짜리 토큰으로 $500K를 절감한 이야기의 진짜 교훈은 AI의 효율이 아니다. 수년간 쌓아온 도메인 이해, 테스트 인프라, 검증 파이프라인이 있었기에 AI가 그것을 증폭할 수 있었다는 것이다.
AI-First 팀 리빌딩을 고민하는 리더라면 지금 이 질문을 던져야 한다. "우리 팀은 AI가 증폭할 수 있는 것들을 이미 갖고 있는가?" 테스트 커버리지, 도메인 문서화, 섀도 배포 인프라, 에이전트 역할 분리 설계—이것들이 없는 상태에서 AI 도구를 도입하면 속도는 빨라지지만 방향은 없어진다. AI 증폭의 전제 조건을 팀 역량으로 키우는 것, 그게 지금 테크 리드가 해야 할 일이다.