요약
기존 개발 방식은 구현 전에 RFC를 쓰고 작업을 작은 이슈와 PR로 나눴지만, 이는 가장 정보가 부족한 시점에 구조적 경계까지 미리 결정해야 한다는 문제가 있음
AI가 구현과 설계 뿐만 아니라 완성된 작업을 여러 PR로 다시 나누는 비용까지 낮추면서, 이제는 무엇을 만들지는 먼저 결정하되 어떻게 나눠 배포할지는 구현 뒤에 결정할 수 있게됨
이 방식의 핵심은 하나의 작업 브랜치에서 기능을 처음부터 끝까지 넓게 구현하고 실제 동작을 먼저 데모해 제품 피드백을 받은 뒤, 완성된 코드가 보여주는 자연스러운 경계에 띠리 작은 PR 단위로 나눠 배포 하는 것임
AI가 코드 리뷰의 단순한 검사 작업을 싸게 만들었어도 미묘한 정확성, 아미텍처 판단과 제품 검증은 여전히 사람의 몫이며, 작은 PR은 사람이 AI가 만든 코드를 읽고 이해하며 소유할 수 있게 해줌
모든 작업에 적합한 방식은 아니며, 구현 전에는 경계를 알기 어려운 기능과 리팩터링에 특히 잘 맞고, 운영 순서가 중요한 마이그레이션이나 독립적으로 배포할 수 없는 변경에서는 얻을 수 있는 이점이 제한됨
=> 일단 만들고 전체적인 기능 동작을 본다
=> 그 다음 PR을 작게 만들어서 사람이 리뷰하는 시간을 효율적으로 만들자 (stacked PR (연속 PR)을 활용)
Reference
https://news.hada.io/topic?id=32507
넓게 만들고, 좁게 배포하라 | GeekNews
기존 개발 방식은 구현 전에 RFC를 쓰고 작업을 작은 이슈와 PR로 나눴지만, 이는 가장 정보가 부족한 시점에 구조적 경계까지 미리 결정해야 한다는 문제가 있음 AI가 구현과 설계뿐 아니라 완성
news.hada.io
'개발 > Development' 카테고리의 다른 글
| Go 언어가 AI 기반 소프트웨어 엔지니어링에 이상적인 이유 (0) | 2026.10.03 |
|---|---|
| 앱스토어, 플레이스토어 스크린샷 이미지 만들 때 목업 폰 모양 이미지 만들어주는 사이트 (0) | 2026.08.10 |
| 프리랜서 개발자에게 필요한 비개발 스킬 Top 10 (1) | 2026.07.10 |
| 개발자가 글을 잘 쓴다고 판단할 수 있는 기준 (0) | 2026.07.10 |
| 플랫폼 엔지니어링의 모든 것 (0) | 2026.07.10 |