AI 시대의 개발 흐름, 기능은 넓게 만들고 PR은 좁게 나눠요

AI 시대의 개발 흐름, 기능은 넓게 만들고 PR은 좁게 나눠요

AI 뉴스 썸네일

AI 코딩 도구가 구현 속도를 높이면서 작업을 나누는 시점도 달라지고 있어요. 기능 전체를 먼저 동작하게 만든 뒤, 실제 코드에서 드러난 경계에 맞춰 작은 PR로 나누자는 개발 방식이 나왔어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
설계	기능의 목적과 신뢰 경계는 구현 전에 정해요	계획 없이 코딩하는 방식과 구분할 수 있어요
구현	하나의 작업 브랜치에서 기능을 끝까지 연결해 봐요	백엔드와 프론트엔드 사이의 실제 의존성을 일찍 확인할 수 있어요
검토	코드 리뷰 전에 동작하는 화면이나 미리보기로 제품 피드백을 받아요	잘못 만든 기능을 세세하게 리뷰하는 낭비를 줄여요
PR	완성된 변경을 독립적으로 읽고 병합할 수 있는 작은 단위로 다시 나눠요	리뷰어가 AI 작성 코드를 이해하고 소유하기 쉬워져요

1. PR 경계는 코드를 만든 뒤 더 선명해져요

전통적인 개발 흐름에서는 RFC를 쓰고 기능을 작은 이슈와 PR로 나눈 다음 순서대로 구현해요. 큰 변경을 한꺼번에 리뷰하지 않아도 된다는 장점이 있어요. 다만 코드가 없는 시점에는 어느 부분이 독립적인지, 각 단계가 얼마나 복잡한지 추측해야 해요. 뒤에서 발견한 제약 때문에 앞서 정한 구조를 다시 고치는 일도 생겨요.

728x90

Adapt의 프로덕트 엔지니어 브루노 콰레스마는 이 비용 구조가 AI 코딩 도구 때문에 달라졌다고 설명해요. 구현과 설계 검토가 빨라졌고, 얽힌 작업 브랜치를 여러 개의 작은 PR로 재구성하는 수고도 줄었어요. 그래서 기능의 목적은 먼저 결정하되 PR 경계는 동작하는 코드를 본 뒤 정할 수 있다는 제안이에요. 2

이 흐름은 설계를 생략하지 않아요. 새로운 구조라면 기능의 동작 방식과 신뢰 경계를 문서로 먼저 합의해요. 구현 전에 정하지 않는 것은 최종 PR 목록이에요. 코드가 보여 주는 의존성과 분리 지점을 확인한 다음 리뷰 단위를 만들어요.

전체 기능을 먼저 연결해 봐요

설계가 정리되면 하나의 브랜치에서 기능을 처음부터 끝까지 구현해요. 백엔드 엔드포인트와 프론트엔드 화면을 함께 만져야 해도 단계마다 리뷰를 기다리지 않아요. 중간 커밋은 최종 기록을 꾸미기 위한 이력이 아니라 위험한 시도 전으로 돌아갈 수 있는 저장 지점으로 써요.

이 방식의 장점은 실제 동작에서 설계의 빈틈을 빨리 찾는 데 있어요. API 모양이 화면에서 쓰기 불편한지, 예상했던 모듈 경계가 실제 의존성과 맞는지 확인할 수 있어요. 구현 순서와 리뷰 순서를 따로 설계할 여지도 생겨요.

코드보다 동작을 먼저 확인해요

기능이 동작하면 짧은 영상이나 미리보기 환경으로 제품 피드백을 먼저 받아요. 사용자가 헷갈리는 화면이나 제품 요구와 어긋난 동작을 코드 리뷰 전에 찾기 위해서예요. 이 단계에서 문제가 보이면 리뷰어가 수백 줄의 변경을 읽기 전에 방향을 고칠 수 있어요.

AI가 스타일 검사와 반복적인 오류 탐지를 맡아도 제품 판단은 사람에게 남아요. 기능이 필요한 문제를 풀었는지, 인터페이스가 앞으로의 변경을 견딜지, 팀이 해당 코드를 이해하고 책임질 수 있는지는 사람이 확인해야 해요. 작은 PR은 이 판단에 쓸 집중 시간을 확보해 줘요.

완성된 코드를 작은 PR로 다시 나눠요

전체 기능이 확인되면 변경을 독립적으로 리뷰할 수 있는 최소 단위로 나눠요. 각 PR은 가능하면 단독으로 병합해도 안전해야 해요. 실제 의존성이 있는 변경만 쌓고, 서로 독립적인 변경은 기본 브랜치에서 각각 분기해요.

원문에 나온 리팩터링 사례는 5개 PR로 나뉘었어요. 독립적인 백엔드 엔드포인트 2개가 먼저 분리됐고, 각 엔드포인트를 쓰는 프론트엔드 화면 2개가 그 위에 놓였어요. 기존 코드를 지우는 작업은 마지막 PR로 빠졌어요. 새 경로와 삭제를 섞지 않으면 리뷰 범위와 되돌릴 대상을 구분하기 쉬워요. 2

잘 맞는 작업과 주의할 작업이 달라요

백엔드와 프론트엔드를 함께 바꾸는 기능, 완성하기 전에는 최종 모양을 알기 어려운 리팩터링에 잘 맞아요. 초기에 이슈 경계를 추측해야 하는 작업에서도 도움이 돼요.

운영 순서를 지켜야 하는 데이터베이스 마이그레이션이나 스키마 변경은 미리 단계를 정해야 해요. 모든 조각을 같은 시점에 넣어야만 동작하는 기능도 늦게 나누는 효과가 작아요. 이 경우 작은 PR은 리뷰를 편하게 해도 점진적인 배포까지 보장하지 못해요.

브랜치를 여러 개로 나눈 뒤 아래쪽 PR이 바뀌면 위쪽 브랜치를 다시 맞춰야 하는 비용도 있어요. 작은 PR을 만들었다는 사실만으로 배포가 빨라지지는 않아요. 각 변경이 따로 병합할 가치가 있는지까지 팀이 판단해야 해요.

왜 중요한가요

AI 코딩 도구가 만든 코드는 빠르게 늘지만, 팀이 읽지 않은 코드는 유지보수 부담으로 남아요. 기능 전체를 먼저 검증하고 리뷰 단위를 작게 다시 만들면 제품 피드백과 코드 이해를 서로 다른 단계에서 다룰 수 있어요. 리뷰어는 아키텍처 위험이 큰 PR에 시간을 더 쓰고, 단순한 화면 변경은 짧게 확인할 수 있어요. 2

이 접근을 적용하려면 세 가지를 확인해 볼 만해요. 구현 전에 기능의 목적과 신뢰 경계를 합의했는지, 동작하는 결과를 코드 리뷰 전에 보여 줬는지, 각 PR이 혼자서도 안전하게 병합될 수 있는지예요. 이 조건이 맞지 않으면 큰 브랜치를 뒤늦게 잘게 나누는 작업만 늘어날 수 있어요.

참고 자료

1. 넓게 만들고, 좁게 배포하라 — GeekNews
2. Build Wide, Ship Narrow — Adapt