넓게 만들고, 좁게 출시하기 — AI 시대의 점진적 개발 워크플로우 가이드

도입: AI가 바꿔놓은 PR 분할의 경제학

전통적인 개발 흐름은 RFC를 쓰고 기능을 작은 이슈로 쪼갠 뒤, 선행 이슈가 끝나야 다음 이슈를 진행하는 방식이었습니다. 리뷰 가능한 크기로 유지하고 대규모 일괄 병합을 피할 수 있지만, 문제를 가장 적게 이해하는 시점에 핵심 구조와 경계를 결정해야 하는 부담이 있었습니다.

adapt.com의 글 넓게 만들고, 좁게 출시하기는 AI가 구현과 브랜치 분해 비용을 낮추면서 달라진 점을 짚습니다. 작업 경계를 처음부터 확정하는 대신 전체 기능을 먼저 구현하고, 실제 코드에 드러난 경계에 따라 작은 PR로 나눌 수 있게 됐다는 겁니다.

구현 전에 경계를 나누는 방식의 한계

구현 전에 경계를 나누는 방식은 본질적으로 추측에 의존합니다. 각 부분을 분리할 수 있는지, 복잡도가 어느 정도인지, 이후 단계가 앞선 결정을 뒤집을지는 미리 알 수 없습니다. 과거에는 일주일 동안 얽힌 작업을 수동으로 해체하는 비용이 컸기 때문에 구현 편의보다 리뷰 가능성을 확보하려고 경계를 미리 정해야 했습니다.

AI는 이 비용 구조를 바꿉니다. 작업자가 만든 임시 코드베이스 위에서 에이전트가 분할을 다시 시도해 볼 수 있고, 잘못된 가정은 미리보기 배포를 통해 검증한 뒤 결과물은 버리고 AI가 임시 작업을 바탕으로 다시 계획하게 할 수 있습니다. 뒤엉킨 코드는 원래 그런 용도의 임시 공간에 남기며 비용도 거의 들지 않습니다.

하나의 브랜치에서 넓게 구현하기

설계가 정리되면 여러 파일과 영역을 가로질러 기능이 종단 간으로 작동할 때까지 하나의 브랜치에서 개발합니다. 단계별로 작업하더라도 각 단계마다 PR을 열고 리뷰를 기다리지는 않습니다. 중간 커밋은 리뷰어를 위한 이력이 아니라 작업자를 위한 저장점입니다. 개념이 검증됐거나 위험한 시도 전에 되돌아갈 지점을 만들 때 커밋합니다.

한 리팩터링은 하루 동안 수십 개 파일과 12개 이상의 운영용 메시지 커밋으로 진행됐다는 사례가 글에 등장합니다. 작업 브랜치의 이력은 최종 기록으로 남지 않습니다. 최종 PR은 main에서 새로 분기합니다. 구현 브랜치는 버리는 초안처럼 사용하고, 작업자와 리뷰어라는 서로 다른 대상을 분리해 각각에 맞게 최적화합니다.

코드 리뷰 전에 제품 검증하기

구현이 충분히 진행되면 PR 대신 Slack의 짧은 영상이나 직접 클릭할 수 있는 미리보기 배포로 먼저 공유합니다. 실제 사용자가 작동하는 소프트웨어에 피드백하도록 하며, 이 과정은 코드 리뷰보다 앞섭니다. 자동화하기 어려운 판단이 남으면서 리뷰 비용은 상대적으로 커졌습니다. 혼란스러운 UI 패턴이나 프런트엔드 사용 방식과 맞지 않는 엔드포인트를 리뷰 단계에서 발견하면 개발자와 리뷰어의 시간을 함께 소모합니다.

데모는 변경 비용이 낮을 때 이런 문제를 찾아냅니다. 피드백 때문에 재설계가 필요하면 즉각 반영합니다. AI가 임시 작업을 바탕으로 다시 계획하게 할 수 있는 것도 같은 이유입니다.

작은 PR로 다시 나누기

완성된 작업은 독립적으로 병합 가능한 최소 PR로 다시 나눕니다. 실제 의존성이 있을 때만 쌓고, 기존 코드 삭제는 마지막 별도 PR로 출시합니다. 작은 PR은 리뷰·에이전트 피드백·롤백을 쉽게 하지만 리베이스 비용이 생기며, 모든 PR을 한꺼번에 병합하면 점진적 제공 효과를 얻지 못합니다.

글에 등장한 핵심 워크플로우는 의사코드로 다음과 같이 정리할 수 있습니다.

# Build wide, ship narrow 워크플로우 의사코드

def deliver_feature(spec):
    # 1) 설계 단계: 명세를 먼저 커밋 (코드보다 앞)
    design_doc = write_design_doc(spec)
    merge_to_main(design_doc)        # 팀이 먼저 이의 제기

    # 2) 구현 단계: 한 브랜치에서 end-to-end로 넓게 구현
    work_branch = create_branch('wide/' + spec.name)
    commit_checkpoints(work_branch)  # 작업자용 저장점
    ship_preview(work_branch)        # Slack 영상 / 미리보기 배포
    collect_user_feedback()          # 코드 리뷰보다 앞섬

    # 3) PR 분할: 실제 코드 경계에 따라 작은 PR로 분해
    prs = split_by_actual_boundaries(work_branch)
    for pr in prs:
        if pr.removes_old_code:
            ship_last(pr)            # 기존 코드 삭제는 마지막 PR
        else:
            ship(pr)                 # 실제 의존성 있을 때만 쌓음

    # 4) 구현 브랜치는 버림 (메인은 새 분기에서 출발)
    discard(work_branch)

이 의사코드에서 보듯 PR 분할 구조는 구현 후에 결정합니다. 무엇을 만들지는 구현 전에 정하지만, 어떻게 쪼갤지는 실제 코드 경계가 드러난 뒤에 정합니다. 새로운 설계라면 계획을 명세 문서로 만들어 코드보다 먼저 커밋합니다. 한 프로젝트에서는 기능의 목적, 작동 방식, 신뢰 경계를 담은 문서가 첫 PR이었고, 구현 며칠 전에 문서를 병합해 팀이 먼저 이의를 제기할 수 있게 했습니다.

AI의 힘은 자잘한 수정이 아니라 실험 브랜치를 쏟아내는 능력

AI의 힘은 자잘한 수정이 아니라 PR이나 검토를 걱정하지 않고 실험 브랜치를 쏟아내는 능력에 있습니다. 해법을 충분히 탐색하고 나면 경로가 명확해져 계획대로 깔끔하게 구현할 수 있습니다. 다만 이 방식이 주로 제공하는 것은 빠른 코딩과 테스트임을 분명히 해야 합니다. 전문적인 제품을 만들기 위한 설계, 제약 관리, 필수 개발 절차에 필요한 정신적 노력은 여전히 남습니다.

전망: AI 시대에도 남아 있는 정신적 비용

엔터프라이즈 환경에서는 AI가 작성한 초안을 그대로 외부에 게시할 때의 품질 문제가 추가로 발생합니다. 저자가 자기 이름을 붙이는 데 동의하는 이유를 이해하기 어렵다는 비판이 글에 인용됩니다. 내용을 깊이 고민했더라도 마지막 문장 작성을 AI에 맡기면 결과물의 가치가 크게 떨어집니다.

채용 목적의 기업 블로그라면 이런 저품질 AI 글은 우수 인재에게 큰 감점 요소가 될 가능성이 큽니다. 반면 성숙한 코드베이스에서 엔트로피에 굴복하지 않고 대규모 변경을 깔끔하게 배포하려는 사람에게는 여전히 유용한 조언이 많으며, 소프트웨어 공학의 기본을 잘 정리한 글로 읽힙니다.

요약

• 전통적 RFC + 작은 이슈 방식은 구현 전에 경계를 추측해야 하는 한계가 있다.
• AI는 분해 비용을 낮춰 한 브랜치에서 end-to-end로 넓게 구현하고 마지막에 작은 PR로 나눌 여지를 만든다.
• 중간 커밋은 작업자용 저장점이며, 최종 PR은 main에서 새로 분기한다.
• 코드 리뷰 전에 Slack 영상 / 미리보기 배포로 사용자 피드백을 먼저 받는다.
• 기존 코드 삭제는 마지막 PR로 분리하고, 명세 문서는 첫 PR로 별도 커밋한다.
• AI의 진짜 가치는 자잘한 수정이 아니라 실험 브랜치를 쏟아내는 데 있다.

---

📰 원본 출처 · https://news.hada.io/topic?id=32507 (#N=32507)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.