에이전트가 팀원이 되면, 무엇이 바뀌나
지금 많은 팀이 AI 도구를 '빠른 타이핑 보조'로 쓰고 있다. 하지만 현장에서 나오는 신호들은 그보다 훨씬 근본적인 변화를 가리키고 있다. dev.to에 올라온 세 편의 글—서브에이전트 병렬 실행 실험, 시니어 엔지니어의 AI 워크플로우 설계, AI 워크스트림이 만드는 팀 구조 병목—은 각기 다른 각도에서 같은 질문을 던진다. 에이전트를 팀 워크플로우에 어떻게 녹일 것인가.
결론부터 말하면, 이 질문에 제대로 답하려면 도구 선택보다 팀 구조와 역할 설계를 먼저 건드려야 한다. 도구는 준비됐다. 팀이 아직 준비되지 않았다.
서브에이전트 병렬 실행: 맥락 격리가 핵심이다
Nicolas Fränkel은 Copilot CLI로 코드베이스를 분석하고, 남은 이슈 네 건을 서브에이전트에 동시에 위임하는 실험을 공유했다. 각 에이전트는 git worktree로 독립된 디렉토리에서 브랜치를 만들고, 구현하고, 테스트를 통과시킨 뒤 PR을 올린다. 병렬 처리 덕분에 속도는 확실히 올라간다.
그런데 그가 진짜 이점으로 꼽은 건 속도가 아니라 컨텍스트 격리다. 각 서브에이전트는 깨끗한 컨텍스트에서 시작한다. 메인 컨텍스트에 무관한 데이터가 쌓이지 않는다. 토큰은 유한하고, 오염된 컨텍스트는 에이전트를 엉뚱한 방향으로 몬다. 이 문제는 프롬프트를 잘 써서 해결하는 게 아니라, 에이전트 단위를 잘게 쪼개고 각각에 충분한 선행 정보를 주는 설계로 해결해야 한다.
여기서 놓치기 쉬운 전제가 있다. 서브에이전트에 일을 넘기기 전, 트리아지(triage) 단계에서 이미 충분한 맥락을 쌓아야 한다. 에이전트는 질문하지 않는다. 불명확한 지시는 그냥 잘못된 방향으로 구현된다. 위임의 품질은 사전 설계의 품질과 정비례한다.
시니어의 역할: 더 빠른 코딩이 아니라 더 나은 결정
"AI 도입으로 주니어와 시니어의 격차가 줄었다"는 말이 많다. 절반은 맞다. 구현 산출물만 놓고 보면 격차가 좁혀진 건 사실이다. 하지만 나머지 절반이 더 중요하다. dev.to의 또 다른 글은 이렇게 지적한다. AI 툴링으로 주니어의 코딩 처리량이 올라가는 동안, 시니어는 다섯 명, 열 명 몫의 결정 시스템을 혼자 돌릴 수 있게 됐다.
그 이유는 AI가 코드를 빠르게 생성해서가 아니다. AI가 구현 속도를 높이는 순간, 병목은 다시 결정으로 이동한다. 무엇을 만들 것인가. 어떤 경계를 그을 것인가. 요구사항이 바뀌면 어떻게 되는가. 이 질문들은 타이핑 속도가 빨라진다고 쉬워지지 않는다. 생각할 시간이 생겨야 쉬워진다. AI가 시니어에게 돌려준 건 코딩 속도가 아니라, 원래 해야 했지만 항상 밀렸던 아키텍처 작업을 할 런웨이다.
이 글이 소개하는 워크플로우는 다섯 단계로 고정된다: preflight → plan → implement → verify → review. 어느 단계도 건너뛸 수 없다. preflight에서는 코드를 한 줄도 생성하지 않는다. CLAUDE.md에 아키텍처 제약을 명문화하고, 에이전트가 매 세션마다 그 제약을 재발견하는 낭비를 없앤다. 명문화된 제약이 없으면 워크플로우는 프롬프팅 패턴에 불과하다. 시스템이 되려면 기준이 코드처럼 버전 관리돼야 한다.
팀 구조 병목: 스프린트 분리가 아니라 팀 분리
AI 워크스트림을 기존 팀에 얹으면 두 가지가 동시에 망가진다. AI 기능 트랙을 다루는 글에서 공유한 실제 사례가 명확하다. 백엔드 엔지니어 세 명을 AI 에이전트 트랙에 투입했더니, 6주 만에 AI 기능은 프롬프트 버저닝 없이 하드코딩된 모델 설정으로 출시됐고, 코어 제품 리팩터링은 두 번 연기됐다.
문제의 본질은 두 트랙의 엔지니어링 리듬이 근본적으로 다르다는 것이다. 코어 제품은 예측 가능성을 최적화한다. 스키마, 배포 주기, SLA. 변경 비용이 높다. AI 기능 트랙은 실험을 최적화한다. 프롬프트는 매일 바뀌고, 평가 파이프라인이 유닛 테스트를 대체한다. 같은 사람이 두 모드를 동시에 전환하면, DORA 연구가 일관되게 보여주듯 배포 빈도는 절반으로 떨어진다.
해법은 스프린트 분리가 아니라 팀 소유권 분리다. AI 워크스트림 스쿼드는 별도 서비스, 별도 CI 파이프라인, 별도 평가 게이트를 갖는다. 코어 제품 팀은 AI 스쿼드가 통합하는 계약(API 스키마, 이벤트 토픽)을 정의한다. AI 스쿼드는 공유 코드베이스를 직접 건드리지 않는다. 이 분리의 부산물로 인터페이스 명확성이 강제된다. 나중에 정리하자고 미뤘던 아키텍처 부채가 구조적 압력에 의해 해소된다.
시사점: AI-First 팀 리빌딩의 실행 순서
세 편의 글이 교차하는 지점에서 실행 순서가 보인다.
첫째, 역할을 재정의하기 전에 워크플로우를 먼저 고정하라. 에이전트에게 일을 위임하는 순간, 위임 전 사전 설계의 비중이 극적으로 올라간다. preflight 없이 에이전트를 실행하면 빠른 속도로 잘못된 곳에 도달한다.
둘째, 시니어의 역할을 '더 빠른 구현자'가 아니라 '결정 시스템 설계자'로 재정의하라. AI가 구현 속도를 높일수록, 잘못된 방향으로의 속도도 같이 높아진다. 방향을 잡는 판단력의 가치는 내려가지 않았다. 올라갔다.
셋째, AI 워크스트림을 추가할 때는 팀 토폴로지를 먼저 바꿔라. 스프린트 레벨의 할당은 문제를 숨길 뿐이다. 두 트랙의 리듬 차이를 구조로 수용해야 두 트랙 모두 제 속도를 낸다.
그리고 한 가지 불편한 이야기. Fränkel은 글 말미에 이렇게 썼다. "우리는 이제 주니어 개발자 팀이 아니라 에이전트 팀을 관리한다. 주니어를 훈련시키지 않는 건 단기적으로 합리적으로 보인다. 하지만 시니어는 어디서 나오는가." 이 질문은 기술 선택이 아니라 산업 전체의 인재 파이프라인에 관한 것이다. AI-First로 팀을 리빌딩하면서 이 질문을 회피하는 팀은, 몇 년 후 시니어 부족과 벤더 의존도 심화라는 두 가지 문제를 동시에 만나게 될 것이다.
전망: 에이전트 시대의 팀 설계는 아직 초기다
지금 우리가 보고 있는 건 실험의 첫 사이클이다. git worktree로 에이전트 충돌을 피하는 방법, CLAUDE.md로 제약을 버전 관리하는 방법, 스쿼드를 분리해 컨텍스트 스위칭을 없애는 방법—이 패턴들은 아직 표준화되지 않았다. 팀마다 다르게 실험하고 있고, 잘 되는 조합이 무엇인지 현장 데이터가 쌓이는 중이다.
확실한 건 하나다. AI-First 팀 리빌딩은 '어떤 도구를 쓸 것인가'로 시작하는 게 아니다. '누가 어떤 결정을 소유하는가'를 다시 설계하는 것에서 시작한다. 에이전트는 결정을 실행한다. 결정을 설계하는 건 아직 사람의 몫이다.