AI 시대의 개발 협업: Plan Review

PR의 재정의: Pull Request에서 Plan Review로

앞 장에서 우리는 회의실에서 AI와 실시간으로 협업하며 창조하는 방식을 살펴봤다. 이번 장에서는 프로덕트 개발 과정에서의 AI 협업, 특히 개발자와 PM/디자이너 출신 Product Engineer들이 함께 AI로 개발하는 환경에서 필수적인 새로운 협업 방식을 다룬다.

AI 도입 후 우리 팀의 개발 속도는 비약적으로 빨라졌다. Claude Code나 Replit 같은 AI 코딩 도구를 사용하면, 예전에 며칠 걸리던 작업을 몇 시간 만에 끝낼 수 있다. 단, 한계도 나타났다. Product Engineer가 AI와 함께 빠르게 코드를 생성할 수 있지만, 시니어 개발자라면 작성하지 않았을 만족스럽지 않은 코드들이 쌓이기 시작했다. Product Engineer는 AI가 권장하는 방식대로 백엔드를 구현하다 버그의 늪에 빠지고, 어느 순간 백엔드 리팩토링이 필요한 상황에 처했다.

그렇다고 기존 방식에서 이 문제가 없던 것은 아니다. 엔지니어들끼리 협업할 때도 방향이 어긋나는 일은 있었다. 다만 그때는 속도가 느렸다. 하루 종일 작업해봐야 PR 하나 정도였다. 그런데 AI와 함께하면 하루에 PR을 열 개씩 만들어낸다. 데이터 구조도 바꾸고, 백엔드 로직도 뒤집고, 온갖 것을 건드린다. 문제가 생겼을 때 역시 빠르게 수습을 할 수는 있지만, Product Engineer가 하루 동안 쌓은 작업이 통째로 날아가는 것이다. 개발자와 Product Engineer 둘이서 작업할 때도 이런데, 세 명, 다섯 명이 되면 문제는 기하급수적으로 커진다. 처음엔 코드 리뷰를 해야 하나 고민했다. 하지만 AI가 쏟아내는 그 많은 코드를 사람이 어떻게 다 리뷰하겠는가. 이걸 직접 하는 것은 시니어 엔지니어의 리소스 낭비다.

그래서 AI를 활용한 코딩의 빠른 속도를 유지하면서도 코드 퀄리티를 높일 수 있는 방식을 고민했다. 그러다 개발 프로세스의 필수 협업 코스인 PR을 새롭게 정의했다. 기존의 PR은 Pull Request, 즉 완성된 코드를 검토하는 과정이었다. 우리는 이것을 Plan Review로 재정의했다. 코드를 작성한 후가 아니라, 코드를 작성하기 전에 계획을 검토하는 것이다.

Code Review와 Plan Review의 차이

전통적인 Code Review와 Plan Review의 차이를 이해하면 이 전환의 의미가 명확해진다. Code Review는 코드가 완성된 후에 진행된다. 개발자가 며칠 동안 코드를 작성하고, 완성된 결과물을 동료에게 보여주며 검토를 요청한다. 리뷰어는 완성된 코드 전체를 읽어야 하고, 문제가 발견되면 이미 작성된 코드를 수정해야 한다. 수정 비용이 크다. 방향 자체가 잘못되었다면 처음부터 다시 작성해야 할 수도 있다.

Plan Review는 완전히 다르다. AI 코딩 직전, 즉 코드를 작성하기 전에 진행된다. 리뷰 대상은 완성된 코드가 아니라 계획이다. 어떤 방향으로 구현할 것인지, 어떤 아키텍처를 선택할 것인지, 어떤 파일들을 수정할 것인지를 미리 검토한다. 개발자뿐 아니라 기획자도 참여한다. 기획 의도와 기술적 구현 방향이 일치하는지 확인하기 위해서다. 수정 비용은 0에 가깝다. 아직 코드가 작성되지 않았으니, 방향을 바꾸는 것은 문서 몇 줄을 수정하는 것뿐이다.

실행 시간도 극적으로 달라진다. Code Review에서는 개발자가 며칠 동안 코드를 작성한 후에야 리뷰가 시작된다. Plan Review에서는 계획 수립에 30분, 리뷰에 30분에서 1시간, 그리고 AI 코딩 실행에 1시간 정도가 소요된다. 전체 사이클이 반나절 안에 완료된다. AI가 코드를 작성하는 속도가 빠르기 때문에, 계획만 확정되면 실행은 금방이다.

Plan Review가 해결하는 문제와 워크플로우

Plan Review가 필요한 이유를 이해하려면, 먼저 비개발자나 주니어 엔지니어가 AI 코딩 도구를 사용할 때 조심해야 할 세 가지 함정을 알아야 한다. 첫째, 근시안적 해결책이다. AI는 전체 구조보다 당장의 에러 해결에만 집중하는 경향이 있다. 눈앞의 버그는 잡지만, 시스템 전체의 일관성을 해치는 방향으로 코드를 수정하기도 한다. 둘째, 누더기식 코드 수정이다. 기존 코드를 정리하지 않고 계속 덧붙이는 Patchwork가 발생할 수 있다. 처음엔 동작하지만, 시간이 지나면 아무도 건드릴 수 없는 레거시가 된다. 셋째, 전문적 판단의 부재다. 일단 돌아가니까 괜찮다고 넘어가면 나중에는 유지보수가 불가능한 괴물이 탄생한다. 시니어 개발자의 판단 없이는 기술 부채가 쌓여간다.

Plan Review는 이 세 가지 함정을 사전에 차단하는 프로세스다. 세 단계로 진행된다. 첫 번째 단계는 Logic Design 개입이다. AI가 코드를 작성하기 전에, 사람이 로직 설계에 개입한다. 구현 방향을 미리 정하고, AI에게 명확한 가이드를 제공한다. 이 단계에서 기획자와 개발자가 함께 참여하여 요구사항과 기술적 제약을 모두 고려한 설계를 만든다.

두 번째 단계는 Bad Pattern 사전 차단이다. 흔히 발생하는 나쁜 패턴들을 미리 정의하고, AI가 그런 방향으로 가지 않도록 막는다. 이런 원칙들을 CLAUDE.md 파일에 명시해두면, AI는 그 원칙을 따라 코드를 작성한다.

세 번째 단계는 기획과 구현의 동기화다. 기획자가 원하는 것과 개발자가 이해한 것이 다르면 문제가 생긴다. Plan Review에서 이 간극을 미리 발견하고 조정한다. 계획이 확정되면 AI가 코드를 작성하고, 사람은 결과물을 검토한다.

CLAUDE.md에 쌓아가는 AI 개발 원칙

개발자와 비개발자가 바이브 코딩으로 효과적으로 협업하려면 조직 차원의 개발 원칙이 필요하다. 우리는 이것을 CLAUDE.md 파일로 관리한다. 이 파일에는 AI가 코드를 작성할 때 따라야 할 원칙들이 명시되어 있다. Claude Code는 프로젝트 루트에 있는 CLAUDE.md 파일을 자동으로 읽고, 그 원칙에 따라 코드를 생성한다.

우리가 적용한 원칙 중 하나는 Fallback 금지다. Claude Code가 Fallback 방식을 제안했을 때 추가한 것이다. 에러가 발생하면 원인을 찾아 근본적으로 해결해야 하는데, 쉽게 말해 Fallback은 임시방편을 이용해 당장은 동작하는 것처럼 보이지만 나중에 더 큰 문제가 될 수 있는 구현 방식이다. 이런 개발 원칙을 Plan Review 과정에서 발견해 CLAUDE.md에 넣는 것이다.

CLAUDE.md에 넣은 또 다른 원칙은 Communication Protocol이다. AI가 문제를 발견하면 반드시 사람에게 먼저 물어봐야 한다. 혼자 판단해서 해결하지 않는다. 특히 기존 로직을 변경해야 할 때, 성능과 정확도 사이의 트레이드오프가 있을 때, 여러 해결 방법 중 선택이 필요할 때는 반드시 사람의 판단을 구하고, 조직 내에서 편하게 이를 공유할 수 있도록 개발 전 계획 공유, 완료 시 변경 목록 템플릿(변경된 파일, 주요 변경사항, 테스트 필요 사항 등)을 추가했다. 이를 통해 협업 투명성을 확보할 수 있다.

CLAUDE.md는 개인의 프롬프트 스킬에 의존하지 않고, 조직 전체의 개발 품질을 균일하게 유지하는 역할을 한다. 신입 개발자도 시니어 개발자와 같은 원칙 아래에서 AI를 활용할 수 있다.

실제 케이스 스터디

Plan Review가 실제로 어떻게 작동하는지 구체적인 사례를 살펴보자. 첫 번째 사례는 버그 분석과 해결 전략 합의다. 우리 서비스에서 채팅 답변 후 전략이 생성되지 않는 버그가 발생했다. PM이 문제 상황을 정의하고, Claude Code에게 원인 분석을 요청했다.

Claude Code는 코드베이스를 분석한 뒤 원인과 해결 방안을 정리해서 팀 메신저로 공유할 수 있는 형태로 요약해줬다.

이 분석 결과를 바탕으로 Plan Review를 진행했다. 개발자가 제안된 해결 방안의 기술적 타당성을 검토하고, PM이 사용자 경험 관점에서 추가 요구사항을 제시했다. 합의된 방향으로 AI가 코드를 작성했고, 버그는 해결되었다. 이 과정에서 발견된 패턴은 CLAUDE.md에 반영되어, 앞으로 비슷한 API 연동 시 응답 스키마를 명시하도록 원칙으로 정립되었다.

여기서 주목할 점이 있다. AI가 해결 방안을 제시할 때 종종 "방안 1 권장"이라고 표시하지만, 이것이 항상 정답은 아니다. 실제로 우리 팀에서도 AI가 권장한 방식이 기존 코드베이스의 패턴과 맞지 않거나, 장기적으로 유지보수가 어려운 구조인 경우가 있었다. 시니어 개발자가 보기에는 방안 2가 더 적절한 상황이었던 것이다. 이것이 바로 Plan Review가 필요한 이유다. AI가 제시한 옵션들 중에서 어떤 것이 우리 상황에 맞는지 판단하는 것이 시니어 엔지니어, 엔지니어링 매니저의 전문성이다.

요즘 우리는 신규 기능 제안 문서도 기획-개발을 한 번에 리뷰한다. PM/PE가 Claude Code와 대화하며 기획 방향을 정리하는 과정에서 목업을 확인하고 원하는 방향을 명확히 한다. 여기서 끝이 아니라, 개발자용 기획안을 생성해달라고 요청한다. 결과물에는 비개발자도 이해할 수 있는 기획 설명과 함께, 실제 코드 구현 방향까지 상세히 정리된다. 데이터 변경 내용, 신규 컴포넌트 구조, 코드 구조까지 모두 들어있다.

이렇게 하면 PM과 개발자가 같은 언어로 대화할 수 있다. 개발자 입장에서는 코드 관련 내용까지 문서에 있으니 바로 검토하고 의사결정할 수 있다. 기존에는 기획 문서를 받고 개발자가 따로 기술 검토를 해야 했지만, 이제는 한 문서에서 모든 것을 확인할 수 있다.

Plan Review의 핵심 가치

Plan Review 도입 후 가장 큰 변화는 시니어 개발자의 코드 퀄리티 만족도 상승이다. AI라는 강력한 엔진을 달고 달리는 자동차에, 안전하고 정교한 핸들을 다는 과정이라고 생각하면 된다. 두 가지 핵심 효과가 있다.

첫째, 코딩 후 수습하는 비용이 크게 절감되었다. 설계 단계에서 방향을 합의하니, 완성 후 대대적인 수정이 필요한 상황 자체가 사라졌다. 예전에는 코드를 다 작성하고 나서 방향이 틀렸다는 피드백을 받으면 처음부터 다시 해야 했다. 이제는 그런 일이 없다.

둘째, Governance가 확립되었다. 개인기가 아닌 시스템으로 일하는 방식이 정착되었다. AI 도구로 일할 때 프롬프트 레벨에 따라 결과가 달라지는 문제를, 조직 Governance 확립을 통해 전체적인 레벨을 올려갈 수 있다. 누가 작업하든 일정 수준 이상의 품질이 보장된다.

Plan Review는 기존의 기획 리뷰와도, 기존의 Code Review와도 다르다. 기존 기획 리뷰는 기획 의도만 검토했고 기술적 실현 가능성은 별도로 확인해야 했다. 기존 Code Review는 완성된 코드를 검토했기 때문에 수정 비용이 컸다. Plan Review는 기획 의도와 엔지니어링 정보가 함께 들어가고, AI 코딩 직전에 최소한의 계획만 검토하기 때문에 효율적이다.

앞 장에서 살펴본 회의가 곧 실행이 되는 조직이 회의실에서의 실시간 AI 협업이었다면, Plan Review는 개발 워크플로우에서의 AI 협업 방식이다. 둘 다 논의가 곧 실행으로 연결되는 구조라는 공통점을 가진다. 우리는 코드 리뷰를 하지 않는다. 대신, 코딩을 시작하기 전 코드 방향을 리뷰한다. 이것이 AI 시대, 속도와 품질을 모두 잡는 방법이다.