엔지니어링 팀의 오랜 상식은 '만들기 전에 계획하라'였다. 기능을 설명하는 RFC를 쓰고, 이를 작은 이슈로 쪼갠 뒤, 각 이슈를 순서대로 구현한다. 코드가 한 줄도 존재하기 전에 작업의 구조가 확정된다. 이 방식은 코드 리뷰를 감당 가능한 크기로 유지하고 한꺼번에 몰아치는 대형 병합을 피하게 해준다. 합리적이다. 다만 한 가지 대가가 있다. 문제에 대해 가장 적게 아는 시점에, 가장 중요한 구조적 결정을 내리도록 강요한다는 점이다.
Adapt의 한 프로덕트 엔지니어는 블로그 글 'Build Wide, Ship Narrow'에서 이 전제를 다시 따져본다. 아직 아무것도 만들지 않았을 때 우리는 결국 추측한다. 어떤 부분이 분리 가능한지, 각각이 얼마나 복잡할지, 3단계가 1단계를 다시 짜게 만들지. 맞을 때도 있지만 틀릴 때가 더 많고, 그러면 1단계는 버려진다. 뭔가 배우긴 했지만, 전체를 먼저 만들었다면 그 배움을 더 빨리 얻었을 것이다. 그럼에도 경계를 미리 정한 이유는 분명했다. 완성된 작업을 손으로 풀어헤치는 것보다 미리 계획하는 편이 나았기 때문이다. 경계를 앞당겨 정하는 일은 빌드를 쉽게 하려는 게 아니라, 리뷰를 가능하게 만드는 유일하게 감당할 만한 방법이었다.
무엇이 싸졌고 무엇이 그대로인가
필자는 세 가지가 극적으로 저렴해졌다고 말한다. 첫째는 구현이다. AI 어시스턴트가 명확한 문제를 몇 시간, 때로는 몇 분 만에 동작하는 코드로 바꾼다. 둘째는 설계다. 계획을 대화 속도로 심문하고 다시 빚을 수 있다. 그리고 가장 핵심은 셋째, 완성된 브랜치를 잘게 나누는 일이다. 일주일치 뒤엉킨 작업을 작은 PR들로 분리하는 것은 예전에는 가장 지루한 작업이었고, 그래서 다들 피했다. 지금은 그것이 프롬프트 한 줄이 됐다.
반대로 두 가지는 싸지지 않았다. 하나는 코드 리뷰의 판단 영역이다. 에이전트는 일관성이나 사소한 버그 같은 기계적인 절반을 거의 공짜로 만들었지만, 이 변경이 여기에 속하는 게 맞는지, 이 엔드포인트 형태가 반년 뒤에 발목을 잡지 않을지 같은 미묘한 정합성은 해결해주지 못한다. 봇이 PR을 승인하는 것과 당신이 코드를 이해하는 것은 다르며, 직접 타이핑하지 않은 코드라면 읽는 행위가 곧 그 코드를 자기 것으로 만드는 과정이다. 좁은 PR은 그 읽기를 가능하게 한다. 다른 하나는 제품 검증이다. 실제로 돌려보고 이게 만들 가치가 있는 물건인지 판단하는 일은 여전히 느리다.
넓게 짓고 나중에 자른다
오해하지 말아야 할 것은, 이것이 '계획을 건너뛰고 코딩부터 하라'는 말이 아니라는 점이다. 필자는 에디터를 열기 전에 계획을 세우고, 모든 기능을 심문에서 시작한다. grill-me라는 스킬로 아이디어를 적대적으로 여러 라운드 인터뷰하며 'API 호출이 실패하면 대안은 무엇인가' 같은 실제 결정을 끄집어낸다. 설계가 새로운 것이면 계획은 코드 이전에 커밋되는 명세가 된다. 실제로 어떤 프로젝트에서는 첫 PR이 구현 며칠 전에 병합된 문서 한 장, 즉 기능이 무엇이고 어떻게 동작하며 신뢰 경계가 어디에 있는지를 담은 스펙이었다. 절대 커밋하지 않는 것은 단 하나, PR 분해 계획이다. 무엇을 만들지는 만들기 전에 정하되, 어떻게 자를지는 만든 뒤에 정한다.
설계가 정해지면 필자는 단계적으로 작업하되 각 단계마다 멈춰 PR을 열고 리뷰를 기다리지 않는다. 모든 것이 끝에서 끝까지 동작할 때까지 한 브랜치에 남는다. 그 사이의 커밋은 남에게 보여줄 이정표가 아니라 저장 지점이다. 개념이 증명됐거나 위험한 시도를 앞두고 되돌아올 밧줄을 걸어두는 용도다. 최근 리팩터링은 하루에 수십 개 파일을 건드리며 열두 개 넘는 커밋을 남겼지만, 이 히스토리는 결코 공식 기록이 되지 않는다. 최종 PR은 main에서 새로 잘라내고, 빌드 브랜치는 버리는 스크래치 종이다. 작업이 좋은 상태에 이르면 코드 리뷰가 아니라 Slack의 짧은 영상이나 프리뷰 배포로 먼저 보여준다. 동작하는 소프트웨어에 대한 피드백을 리뷰가 시작되기 전에 받는 것이다.
자르는 규칙과 그 대가
분할에는 반복을 통해 얻은 두 규칙이 있다. 첫째, 의존성이 실제일 때만 스택을 쌓는다. 프런트엔드 뷰 PR은 그 데이터를 주는 백엔드 엔드포인트 PR 위에 올라가지만, 나머지는 모두 main에서 분기한다. 편의를 위해 스택을 쌓으면 맨 아래 PR에 피드백이 오는 순간 후회할 리베이스 체인이 생긴다. 둘째, 정리는 마지막에 배포한다. 교체되는 옛 코드의 삭제는 새 경로가 살아난 뒤 별도 PR로 죽는다. 삭제와 생성을 섞으면 리뷰어를 혼란스럽게 하고 롤백을 모호하게 만든다. 필자가 든 리팩터링 사례는 다섯 개 PR로 나왔다. main에서 형제로 갈라진 백엔드 엔드포인트 둘, 각자 필요한 데이터를 주는 백엔드 위에 얹힌 프런트엔드 뷰 둘, 그리고 옛 경로를 순수하게 삭제하는 마지막 PR 하나였다. 삭제 PR은 기능 전체가 추가한 것보다 수백 줄을 더 지웠다.
대가도 분명하다. 리베이스가 그중 하나다. 다른 PR이 얹힌 PR에 리뷰어가 변경을 요구하면 그 위의 모든 브랜치를 다시 리베이스해야 한다. 분할을 만들어낸 대화 세션을 열어두면 손으로 하는 대신 다시 프롬프트해 갱신할 수 있다. 또 하나는 '분할은 배포가 아니다'라는 점이다. 글을 쓰는 시점에 그 리팩터링의 다섯 PR은 모두 열려 있었다. 좋은 분할은 각 PR을 리뷰하기 쉽고 단독 병합할 가치가 있게 만들지만, 무엇을 언제 병합할지는 여전히 사람의 판단이다. 이 방식은 백엔드와 프런트엔드를 넘나드는 다면적 기능, 끝까지 만들어봐야 최종 형태를 아는 리팩터링에 잘 맞는다. 반대로 프로덕션에서 순서를 지켜야 하는 마이그레이션이나 스키마 변경, 자를 곳이 하나로 뻔한 작업에는 어울리지 않는다. 구조적 결정 자체가 사라지는 것은 아니다. 코드를 눈앞에 두고 내릴 때 훨씬 싸질 뿐이다.