팀 워크플로우의 변화

에이전틱 코딩 도구를 개인이 사용하는 것과 팀 전체가 사용하는 것은 차원이 다른 문제입니다. 코드 소유권, PR 리뷰 기준, 분업 방식, 커뮤니케이션 프로토콜까지 팀 워크플로우 전체가 흔들리기 시작합니다.

이 장에서는 에이전틱 전환을 겪은 팀들에서 공통적으로 관찰되는 변화를 정리하고, 그 변화가 팀 문화와 역할에 어떤 파장을 일으키는지 살펴봅니다.

기존 팀 워크플로우의 가정

전통적인 소프트웨어 개발 팀의 워크플로우는 순차적이고 예측 가능한 구조를 전제합니다.

이 흐름이 잘 작동하려면 몇 가지 가정이 성립해야 합니다. 구현에 며칠이 걸리므로 스프린트 단위로 계획할 수 있고, 한 사람이 한 태스크를 맡기 때문에 코드 소유권이 자연스럽게 정해지며, 리뷰어는 작성자의 의도를 코드에서 읽어낼 수 있고, 설계와 구현은 분리된 단계로 존재합니다.

AI가 팀에 합류하면 이 가정들이 동시에 흔들립니다. 프로토타입이 수시간 내에 완성되면서 스프린트 단위 계획의 의미가 희석되고, AI와 사람이 함께 작업하면서 소유권이 모호해지며, AI가 생성한 코드에서 의도를 추론하기가 어려워집니다.

AI 시대에 관찰되는 워크플로우 변화

에이전틱 코딩을 도입한 팀에서 공통적으로 나타나는 변화를 정리하면 다음과 같습니다.

핵심적인 변화는 코드 작성에서 검증과 판단으로의 무게중심 이동입니다. 이 전환이 어려운 이유는 기술적 난이도보다 심리적 전환에 있는 경우가 많습니다. 코드를 작성하는 행위에서 정체성을 느끼던 개발자일수록 이 변화가 불편하게 다가오는 경향이 있습니다.

전환 과정에서 관찰되는 패턴

B2B SaaS 백엔드 팀(테크리드 1, 시니어 2, 주니어 2) 규모의 팀이 에이전틱 전환을 시도할 때, 대략 3개월에 걸쳐 비슷한 궤적을 그리는 경향이 있습니다.

흥미로운 점은 전환 초기에 성과가 일시적으로 하락하는 현상이 자주 나타난다는 것입니다. 아래 표는 그 전환 곡선을 운영 관점에서 읽기 쉽게 재구성한 예시입니다.

시간 배분의 변화

전환 전후로 개발자의 시간 배분이 어떻게 달라지는지도 주목할 만합니다.

코드 작성에 쓰던 시간의 대부분이 설계, 의도 정의, 검증으로 재배분됩니다. 직접 코딩은 10% 수준으로 줄어들지만, 그 10%는 AI가 다루기 어려운 핵심 로직이나 미세 조정에 집중되는 경향이 있습니다.

역할이 재정의되는 방식

AI가 구현을 담당하면 팀원의 역할이 근본적으로 달라집니다. 하지만 역할의 본질 자체가 바뀌는 것은 아닙니다.

주니어 개발자의 경우가 특히 흥미롭습니다. "코드 작성에서 코드 평가로"라는 전환이 이루어지는데, 이것이 성장을 방해하는지 촉진하는지는 아직 결론이 나지 않았습니다. 다만 분명한 것은, AI 출력을 비판적으로 평가하려면 직접 코드를 작성하는 경험이 충분히 뒷받침되어야 한다는 점입니다. 기초 체력 없이 전략만으로는 경기에서 이길 수 없는 것과 비슷합니다.

코드 소유권이라는 난제

AI가 코드를 생성하면 "누가 이 코드의 주인인가?"라는 질문이 생깁니다. 팀마다 다른 접근을 취하는데, 크게 네 가지 모델이 관찰됩니다.

실제로 잘 작동하는 사례를 보면, 영역별로 다른 소유권 모델을 적용하는 혼합 모델이 많습니다. 보안 영역은 리뷰어 소유로 엄격하게 관리하고, 비즈니스 로직은 지시자 소유로, 유틸리티는 팀 공동 소유로 운영하는 식입니다.

# team-ownership.yml - 코드 소유권 정책
ownership_policy:
  # 보안 영역: 리뷰어 소유 모델
  security:
    model: reviewer_owned
    required_reviewers: 2
    ai_allowed: false  # AI 단독 작성 불가
    areas:
      - auth/
      - crypto/
      - middleware/security/

  # 비즈니스 로직: 지시자 소유 모델
  business:
    model: instructor_owned
    required_reviewers: 1
    ai_allowed: true
    areas:
      - services/
      - domain/

  # 유틸리티: 팀 공동 소유 모델
  utilities:
    model: team_owned
    required_reviewers: 1
    ai_allowed: true
    areas:
      - utils/
      - helpers/
      - tests/

어떤 모델을 선택하든, 한 가지 원칙은 공통적으로 유지되는 것이 좋습니다. AI에게 지시한 사람이 1차 소유자이되, 팀 전체가 해당 영역의 코드를 이해하고 수정할 수 있는 수준을 유지하는 것. "AI가 만들었으니 나는 모른다"는 태도가 팀 안에서 허용되기 시작하면, 코드베이스의 특정 영역이 블랙박스가 되어 버리는 경향이 있습니다.

팀 운영에 바로 쓰는 최소 정책

개념이 아니라 운영 규칙으로 옮기려면, 팀이 합의해야 할 최소 단위가 필요합니다.

## AI 협업 PR 템플릿

### 변경 의도
- 어떤 문제를 해결하려는가

### AI 활용 범위
- 초안 작성 / 테스트 생성 / 리팩터링 / 조사

### 사람이 직접 검증한 항목
- 비즈니스 규칙
- 보안/권한
- 테스트 결과

### 리뷰어가 우선 확인할 포인트
- 과잉 구현 여부
- 빠진 엣지 케이스

PR 리뷰의 관점 변화

AI가 생성한 코드에 대한 PR 리뷰는 기존과 다른 관점이 필요합니다. 전통적 리뷰가 "이 로직이 맞는가?"에 집중했다면, AI 시대 리뷰는 "이 코드가 원래 의도와 일치하는가?"와 "AI가 과잉 구현한 부분은 없는가?"라는 질문이 추가됩니다.

AI가 생성한 코드를 리뷰할 때 특히 주의 깊게 살펴볼 영역들이 있습니다. 의도 정합성(PR 설명의 의도와 코드가 일치하는지), 과잉 구현(요청 이상으로 구현한 부분이 없는지), 보안 취약점, 불필요한 의존성 추가, 테스트의 의미성(실제 동작을 검증하는지), 그리고 하드코딩된 경로나 환경 분기 같은 컨텍스트 누수 문제입니다.

스프린트 세레모니에 나타나는 변화

에이전틱 전환에 따라 스프린트 세레모니의 성격도 달라지는 경향이 있습니다.

스탠드업에서 가장 두드러지는 변화는 질문의 초점입니다. "어제 무엇을 구현했나"가 "어제 어떤 결정을 내렸나"로, "오늘 무엇을 구현할 것인가"가 "오늘 어떤 문제를 정의할 것인가"로 바뀌는 경향이 있습니다. 그리고 "AI에서 발견한 흥미로운 패턴 공유"가 자연스럽게 추가됩니다. 시간 자체는 15분으로 변화가 없는 경우가 대부분입니다.

스프린트 플래닝도 미묘하게 달라집니다. 스토리 포인트의 기준이 구현 난이도에서 검증 난이도로 이동하고, 태스크 분해가 기능 단위에서 의도 단위로 바뀌며, 배정 기준이 기술 역량에서 도메인 이해도로 옮겨가는 경향이 나타납니다.

회고에서는 AI 활용 자체가 중요한 주제로 등장합니다. 이번 스프린트에서 AI가 가장 효과적이었던 순간은 무엇이었는지, 실패하거나 비효율적이었던 순간은 무엇이었는지, 다음에 시도할 새로운 활용 패턴은 무엇인지 등이 자연스러운 논의 대상이 됩니다. CLAUDE.md에 추가해야 할 내용을 회고에서 정리하는 팀도 있습니다.

페어 프롬프팅이라는 새로운 협업 형태

페어 프로그래밍이 페어 프롬프팅으로 진화하는 현상이 관찰됩니다. 둘이 한 화면을 보고 타이핑하는 대신, 둘이 한 AI 세션을 두고 역할을 나누는 형태입니다.

드라이버는 AI에게 프롬프트를 작성하고 컨텍스트를 보충하며, 네비게이터는 AI 출력의 문제점을 지적하고 전체 아키텍처 관점에서 평가합니다. 흥미로운 점은 네비게이터 역할이 전통적 페어 프로그래밍보다 더 적극적이라는 것입니다. AI 출력을 실시간으로 평가해야 하기 때문에, 네비게이터의 집중도와 도메인 이해가 더 많이 요구됩니다.

이 방식이 잘 작동하는 팀에서는 대략 25분마다 역할을 교대하고, 네비게이터는 키보드를 만지지 않고 평가와 방향 제시에만 집중하며, 세션에서 발견한 효과적인 패턴을 기록해서 팀 지식으로 축적하는 모습이 관찰됩니다. 특히 시니어와 주니어가 페어를 이루면, 시니어의 판단력과 주니어의 새로운 시각이 결합되어 흥미로운 결과를 만들어내는 경우가 있습니다.

팀 전환 시 흔히 발생하는 갈등

팀 단위 전환에서는 개인 전환에서 볼 수 없는 갈등 패턴이 나타납니다.

이 중에서 "주니어 성장 우려"는 가장 깊은 논의가 필요한 주제입니다. "코드를 못 짜게 된다"는 우려가 있지만, 현실에서는 읽기 능력이 여전히 필수이고 AI 출력 평가에도 CS 기본기가 반드시 필요합니다. 프롬프트 작성 자체도 문제 해결의 한 형태이며, 페어 프롬프팅은 새로운 멘토링 방식이 될 수 있습니다.

다만 이런 논리가 "그러니까 주니어도 처음부터 AI만 쓰면 된다"는 결론으로 이어져서는 곤란합니다. 비판적 평가 능력은 직접 경험에서 나오는 법이고, 코드를 직접 작성해본 적이 없는 개발자가 AI의 코드를 제대로 평가하기는 어렵습니다. 주니어가 직접 코드를 작성하는 시간을 의도적으로 확보하는 팀이 장기적으로 더 건강한 팀 역량을 유지하는 경향이 있습니다.

커뮤니케이션 패턴의 변화

AI가 구현 속도를 높이면 팀 내 커뮤니케이션의 초점도 이동합니다.

이 변화들의 공통점은 "무엇을 했는가"에서 "무엇을 결정했는가"로의 초점 이동입니다. 구현이 빨라진 만큼 결정의 빈도와 중요성이 높아지고, 그 결정을 팀과 공유하는 것이 워크플로우의 핵심이 됩니다.

에이전트를 팀 인프라로 관리하기 — JetBrains Central (2026)

2026년 3월, JetBrains는 에이전트를 개인 도구가 아닌 팀 관리 인프라로 다루는 방향을 제시했습니다. JetBrains Central은 팀 차원에서 AI 에이전트의 행동 규칙, 접근 권한, 사용 패턴을 중앙에서 관리하는 구조를 지향합니다.

이 접근이 중요한 이유는, 에이전트가 "개인의 생산성 도구"에 머무르면 팀 차원의 일관성과 품질 관리가 불가능하기 때문입니다.

이 변화는 이 챕터 앞부분에서 다룬 코드 소유권 모델, 최소 운영 정책, PR 리뷰 기준과 자연스럽게 연결됩니다. 에이전트가 팀 인프라가 되면, 에이전트의 행동 규칙도 팀 규칙의 일부로 관리되어야 하고, 에이전트가 만든 코드의 소유권도 팀 차원에서 명확히 정의되어야 합니다.

결국 AI 시대의 팀 워크플로우는 "누가 무엇을 구현하는가"에서 "누가 무엇을 결정하는가"로 초점이 이동합니다. 코드 소유권, PR 리뷰, 커뮤니케이션 프로토콜 모두 의사결정 품질 중심으로 재구성되는 경향이 있습니다. 이 전환은 도구의 변화가 아니라 팀 문화의 변화이기 때문에, 도구를 도입하는 것보다 팀이 함께 논의하고 합의하는 과정 자체가 더 중요할 수 있습니다.

이 챕터의 핵심

다음 장 미리보기

팀 운영 방식이 바뀌더라도, 모든 것을 언러닝해야 하는 것은 아닙니다. 다음 장에서는 AI 시대에도 절대 버리면 안 되는 개발자 기본기를 정리합니다.

참고 자료

• Google. "DORA - DevOps Research and Assessment." https://dora.dev/
• JetBrains (2026). "JetBrains Central: Agent Governance for Teams." https://blog.jetbrains.com/blog/2026/03/24/jetbrains-central/