넓게 만들고, 좁게 출시하기

AI가 구현과 브랜치 분해 비용을 낮추면서, 작업 경계를 처음부터 확정하는 대신 전체 기능을 먼저 구현하고 실제 코드에 드러난 경계에 따라 작은 PR로 나눌 수 있게 됨 설계를 생략하는 방식은 아니며, 계획을 충분히 검증하고 새로운 설계라면 명세를 코드보다 먼저 커밋하되 PR 분할 방식은 구현 이후에 결정함 하나의 작업 브랜치에서 종단 간 기능을 완성한 뒤, 코드 리뷰 전에 영상이나 미리보기 배포로 제품을 먼저 검증해 잘못된 UI나 API 형태를 일찍 수정함 완성된 작업은 독립적으로 병합 가능한 최소 PR로 다시 나누며, 실제 의존성이 있을 때만 쌓고 기존 코드 삭제는 마지막 별도 PR로 출시함 작은 PR은 리뷰·에이전트 피드백·롤백을 쉽게 하지만 리베이스 비용이 생기며, 모든 PR을 한꺼번에 병합하면 점진적 제공 효과를 얻지 못함 구현 전에 경계를 나누는 방식의 한계 전통적인 개발 흐름은 RFC를 작성하고 기능을 작은 이슈로 나눈 뒤, 선행 이슈가 끝나야 다음 이슈를 진행하는 방식이었음 코드 리뷰를 관리 가능한 크기로 유지하고 대규모 일괄 병합을 피할 수 있지만, 문제를 가장 적게 이해하는 시점에 핵심 구조와 경계를 결정해야 함 구현 전에는 각 부분을 분리할 수 있는지, 복잡도가 어느 정도인지, 이후 단계가 앞선 결정을 뒤집을지 추측할 수밖에 없음 과거에는 일주일 동안 얽힌 작업을 수동으로 해체하는 비용이 컸기 때문에, 구현 편의보다 리뷰 가능성을 확보하려고 경계를 미리 정해야 했음 AI가 낮춘 비용과 여전히 비싼 판단 세 가지 작업의 비용이 크게 낮아짐 구현: AI 어시스턴트가 명확한 문제를 몇 시간, 때로는 몇 분 안에 작동하는 코드로 바꿀 수 있음 설계: 대화 속도로 계획을 질문하고 재구성할 수 있음 완성된 브랜치 분해: 일주일 분량의 얽힌 작업을 작은 PR의 연속으로 나누는 일이 프롬프트로 가능해짐 반면 코드 리뷰에 필요한 판단은 여전히 저렴해지지 않았음 에이전트는 일관성, 사소한 문제, 명백한 버그 같은 기계적 검사를 자동화함 미묘한 정확성, 코드가 놓일 적절한 위치, 6개월 뒤 API 형태가 일으킬 문제까지 결정하지는 못함 직접 작성하지 않은 코드를 소유하려면 읽고 이해해야 하며, 좁은 PR이 이를 가능하게 함 제품 검증에도 여전히 시간이 필요함 실제로 실행해 올바른 제품인지 판단해야 함 달라진 점은 코드를 읽기 전에 다른 사람에게 전체 기능을 보여줄 만큼 구현이 빨라졌다는 데 있음 전체 개발 흐름...