【AI 에이전트 시대의 팀 개발 ⑤】 AI 시대의 PR은 왜 무거워지기 쉬운가

AI를 사용한 개발에서는 PR (Pull Request) 처리가 어려워진다고 느끼고 있습니다.

기존의 개발에서는 1일분, 2일분, 3일분의 작업을 모아서 PR을 올리는 경우가 자주 있었습니다.

물론 차분 (diff)이 너무 큰 PR은 예전부터 문제였지만, 그럼에도 인간이 손으로 쓰는 속도에는 일정 수준의 한계가 있었습니다.

하지만 AI를 사용하면 그 전제가 바뀝니다.

한 번의 수정만으로도 대량의 코드가 나올 수 있습니다.

3일 동안 작업했을 경우, 그 차분량은 상당히 커질 가능성이 있습니다.

그렇다면 AI 시대에 PR은 제대로 기능할 수 있을까요?

제 생각에는 PR 제도 자체는 필요합니다.

다만, 기존처럼 "작업이 끝나면 모아서 PR"하는 방식은 상당히 어려워질 것이라고 생각합니다.

인간만으로 개발하던 시대에는 작업 시간과 차분량 사이에 어느 정도 관계가 있었습니다.

물론 개인차는 있습니다.

하지만 1시간의 작업, 1일의 작업, 3일의 작업으로 대략적인 차분량을 상상할 수 있었습니다.

AI를 사용하면 이 감각이 무너집니다.

짧은 시간이라도 AI는 대량의 코드를 생성할 수 있습니다.

반대로 긴 시간을 들여도 설계 검토만으로 차분이 적은 경우도 있습니다.

즉, "며칠 동안 작업했는가"로 PR의 크기를 판단하기가 어려워집니다.

AI 시대의 PR은 시간이 아니라 변경 내용의 덩어리로 생각해야 합니다.

PR이 너무 커지면 리뷰는 어려워집니다.

특히 AI가 생성한 차분에서는 다음과 같은 판단이 필요합니다.

• 사양 변경(Specification change)은 어디인가
• AI가 임의로 수정한 부분은 어디인가
• 기존 동작이 변하지 않았는가
• 리팩토링 (Refactoring)이 섞여 있지 않은가
• 책임의 경계가 바뀌지 않았는가
• 테스트는 충분한가

이것을 대량의 차분에 대해 수행하는 것은 매우 힘든 일입니다.

PR은 존재하지만 실질적으로는 리뷰하지 못하고 있는 상태가 될 수 있습니다.

그리고 리뷰할 수 없는 PR은 팀 개발에서 위험합니다.

AI 시대에는 PR을 "작업 일수"로 나누는 것은 그리 적합하지 않다고 생각합니다.

예를 들어, 다음과 같은 구분 방식입니다.

3일분 작업했으므로 PR을 올린다

이는 인간 중심의 개발에서도 커지기 쉽지만, AI 시대에는 더욱 위험합니다.

AI를 사용하면 3일분의 작업은 상당한 양이 됩니다.

여러 화면, 여러 API, 상태 관리, 테스트, 리팩토링까지 포함될 수 있습니다.

그렇게 되면 리뷰하는 쪽은 상당히 힘듭니다.

대신 PR은 "무엇을 바꿨는가"로 나누어야 합니다.

AI 시대의 PR은 다음과 같이 나누는 것이 좋다고 생각합니다.

• 템플릿 추가
• 타입 정의 추가
• API 연결 추가
• 화면 표시 추가
• 유효성 검사 (Validation) 추가
• 테스트 추가
• 리팩토링
• 버그 수정

예를 들어, 사용자 목록 화면을 추가하는 경우에도 하나의 거대한 PR로 만드는 것이 아니라 다음과 같이 나눌 수 있습니다.

PR1: User 타입과 API 클라이언트 추가
PR2: UserListPage 템플릿 추가
PR3: 검색 폼 추가
...

모든 것을 너무 세세하게 나눌 필요는 없습니다.

하지만 적어도 "사양 변경"과 "리팩토링"은 나누어야 합니다.

AI는 구현하면서 설계 변경도 제안해 오는 경우가 있습니다.

예를 들어, 기존의 상태 관리를 바꾸는 편이 좋다, 공통 컴포넌트를 분리하는 편이 좋다, API 클라이언트를 정리하는 편이 좋다라는 제안입니다.

이것들은 유용할 때가 있습니다.

하지만 기능 추가 PR 안에 설계 변경을 섞으면 리뷰가 어려워집니다.

설계 변경이 필요하다면 먼저 그것만 PR로 만든다.

혹은 Issue나 설계 메모로 합의한 뒤에 구현한다.

이 순서가 중요합니다.

AI에게는 구현뿐만 아니라 PR 분할에 대한 상담도 할 수 있습니다.

예를 들어, 구현 전에 이렇게 묻습니다.

이 기능을 구현할 경우, 리뷰하기 쉬운 PR 단위로 분할해 주세요.
사양 변경, 리팩토링, 테스트 추가를 섞지 않는 방침으로 부탁드립니다.

또한 구현 후에 이렇게 물을 수도 있습니다.

현재의 차분을 확인하고, 리뷰하기 쉬운 PR 단위로 분할한다면 어떻게 나누어야 할까요?
사양 변경, 리팩토링, 테스트 추가, 불필요한 변경을 분류해 주세요.

AI는 코드를 쓰기 위해서만 존재하는 것이 아닙니다.

차분의 정리나 리뷰 관점의 추출에도 사용할 수 있습니다.

AI 시대에는 PR이 어려워진다.

그러므로 PR은 불필요해진다.

그렇게 생각하는 것은 조금 위험하다고 봅니다.

오히려 AI 시대이기 때문에 PR은 중요합니다.

AI가 큰 차분을 빠르게 만들 수 있기 때문에, 인간이 확인할 수 있는 단위로 분해할 필요가 있습니다.

문제는 PR 제도 그 자체가 아닙니다.

문제는 AI가 생성한 거대한 차분 (diff)을 그대로 PR (Pull Request)로 만들어 버리는 것입니다.

PR은 AI의 출력을 팀에서 수용하기 위한 관문으로서, 앞으로도 필요하다고 생각합니다.

AI 시대의 PR은 기존보다 무거워지기 쉽습니다.

그 이유는 AI가 짧은 시간 안에 대량의 코드를 생성할 수 있기 때문입니다.

그 결과, 작업 시간과 차분 (diff) 양의 관계가 무너집니다.

대책으로는 다음과 같은 사항이 중요합니다.

• PR을 일수(days)로 구분하지 않는다
• 변경 내용의 묶음으로 나눈다
• 사양 변경 (specification change)과 리팩토링 (refactoring)을 섞지 않는다
• 설계 변경 (design change)과 구현 변경 (implementation change)을 분리한다
• AI에게 PR 분할이나 차분 (diff) 분류를 시킨다

PR 제도를 그만두는 것이 아니라, AI 시대에 맞춰 PR의 단위를 재설계할 필요가 있다고 생각합니다.

다음 회차에서는 "AI에게는 세세하게 지시하지 않는 편이 좋다"라는 최근의 흐름이 팀 개발에서도 통용되는지를 생각해보겠습니다.

이후의 연재 예정입니다.

• 제1회: 같은 AI를 사용하고 있는데, 왜 코드가 제각각이 되는가
• 제2회: AI가 작성한 "동작하는 코드"가 팀 개발에서는 위험한 이유
• 제3회: AI에게 맡겼더니 컨플릭트 (conflict) 투성이가 된 이야기
• 제4회: AI에게 "이 파일 외에는 건드리지 마"라고 말하는 것은 옳은가
• 제5회: AI 시대의 PR은 왜 무거워지기 쉬운가
• 제6회: "AI에게는 세세하게 지시하지 않는 편이 좋다"는 팀 개발에서도 통용되는가
• 제7회: 스티어링 파일 (steering file)만으로는 부족하다. AI의 편차를 구조로 흡수한다
• 제8회: AI 시대의 베테랑은 코드를 쓰는 사람에서 구조를 만드는 사람으로