팀 워크플로우의 변화

에이전틱 코딩 도구를 개인이 쓰는 것과 팀 전체가 쓰는 것은 차원이 다른 문제입니다. 코드 소유권, 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/