일일 평균 15.8건의 PR 생성을 실현한 AI 주도 개발 방식
요약
본 기사는 1인 개발자가 AI 주도(AI-driven) 병렬 개발 방식을 통해 LINE 미니 앱을 성공적으로 출시한 경험을 공유한다. 핵심은 PRD, 설계 문서, 구현 계획 등 모든 문서를 코드와 동일한 리포지토리에 관리하여 AI가 문서와 코드를 원활하게 참조하도록 하는 것이다. 이를 바탕으로 Agent Teams를 활용해 병렬 개발하고, AI 리뷰 시스템을 통해 전체 공정을 자동화함으로써 높은 효율성을 달성했다.
핵심 포인트
- PRD부터 구현까지의 전 과정을 AI 주도 플로우로 구축하여 병렬 개발을 극대화함.
- 문서(PRD/설계)와 코드를 동일 리포지토리에 관리하여 AI가 문맥적 참조를 원활하게 하도록 함.
- Agent Teams를 활용해 여러 에이전트가 독립적으로 협업하며 대량의 PR을 병렬로 작성함 (1회 지시당 5~15건).
- AI Review 시스템을 구축하여 모든 영역(PRD, 설계, 코드 등)에서 정합성을 검증하고 머지까지 자동화함.
안녕하세요! akifumi입니다.
최근 LINE 미니 앱인 「KAUCHE FARM MINI」를 AI 주도(AI-driven)를 전제로 한 병렬 개발을 통해 혼자서 2개월 만에 출시했습니다.
본 기사에서는 KAUCHE FARM MINI에서 도전했던 개발 기법을 공유하고자 합니다.
전체상
이번에는 1인 팀의 신규 개발이었기 때문에, AI 주도를 전제로 한 개발 기법의 검증을 포함하여 개발을 진행했습니다. 실제로 진행한 개발 플로우는 다음과 같습니다.
-
PRD를 리포지토리에 배치
-
코드와 동일한 리포지토리에서 관리
-
PRD로부터 구현 계획을 생성
-
후술할
/impl-plan-from-prd스킬을 활용하여, PRD로부터 구현 계획을 자동 생성 - 구현 계획도 동일한 리포지토리에서 관리 -
구현 계획을 바탕으로 Agent Teams에서 병렬 개발
-
각 에이전트가 독립된 환경에서 협조하며, 동시 병행으로 개발 및 PR 작성
-
1회의 지시로 5 ~ 15건 정도의 PR을 작성
-
PR마다 AI가 CI 상에서 리뷰를 실시
-
PRD / 구현 계획 / Backend / Frontend 등, 모든 영역에서 AI Review 실시
-
1인 개발이므로, 기본적으로 AI Review만으로 머지(Merge)
-
PR을 머지
-
3번으로 돌아가 후속 작업 진행
PRD·설계(DesignDoc)·구현 계획·구현·리뷰까지의 일련의 공정을 AI 주도 플로우로 구축함으로써, 병렬 개발을 극한까지 높일 수 있었습니다. 고안한 점에 대해 차례로 소개하겠습니다.
고안한 점
고안 1: PRD·설계·구현 계획 등 모든 문서를 코드와 동일한 리포지토리에서 관리하기
KAUCHE의 개발에서는 PRD나 설계 문서를 Notion으로 관리하는 경우가 많습니다.
하지만 이번에는 AI 개발을 전제로 한 병렬 개발을 최대화하기 위해 **「문서를 코드 근처에 두는 것이 가장 효율적이지 않을까」**라는 가설 아래, PRD·설계·구현 계획을 코드와 동일한 리포지토리에서 관리하기로 했습니다.
KAUCHE FARM MINI에서는 코드와 동일한 리포지토리의 docs/web/farm-line/ 하위에 모든 문서를 배치했습니다.
├── docs/web/farm-line/ # LINE 미니 앱의 문서
│ ├── 01-prd/
│ │ ├── 1-0-prd-line-mini-app-mvp.md # 전체상
...
문서와 코드를 동일한 리포지토리에서 관리함으로써 다음과 같은 이점을 얻을 수 있었습니다.
-
문서로부터 설계·구현 계획·구현으로 이어지는 흐름이 원활해짐
- MCP 등을 통해 외부 도구에 연결할 필요 없이, Claude Code에서 직접 문서를 참조할 수 있음
- 더욱 간편하고 빈번하게 문서를 업데이트할 수 있음
- 문서도 코드와 마찬가지로 git으로 버전 관리 가능
-
AI가 문서와 코드를 횡단하며 참조하면서 작업을 진행
- 설계나 구현 과정에서 AI가 문서를 참조하여 정합성을 확인하며 작업을 진행할 수 있음
- 조기에 궤도 수정을 하면서 개발을 진행
-
문서의 변경에도 개발 워크플로우를 적용
- 문서 수정도 코드와 마찬가지로 CI 상에서 AI Review를 발생시킴
- 고려 사항이 누락되지 않았는지, 구현이 가능한 상태인지, 병렬 개발하기 쉬운 구조인지 등을 PR Review 시점에서 검지 및 피드백 가능
- AI Review 결과로부터 PR 작성 시점에서 수정 가능
/impl-plan-from-prd 스킬 생성
고안 2: PRD로부터 구현 계획을 생성하기
PRD로부터 설계·구현 계획을 작성하는 것도 AI로 자동화했습니다. PRD가 추가·업데이트될 때마다 설계·구현 계획을 업데이트하는 작업을 반복했기 때문에, /impl-plan-from-prd로 스킬화했습니다.
이 스킬은 PRD를 병렬로 읽어 들여, 구현 계획서(PR 분할 전략·의존 관계·병렬화 전략)를 일괄 생성합니다.
다음 명령어를 실행하여 구현 계획을 업데이트합니다.
/impl-plan-from-prd \
--prd_files "docs/web/farm-line/01-prd/" \
--impl_plan_path "docs/web/farm-line/04-frontend-implementation-plans/" \
...
스킬 내부에서는 다음과 같은 5가지 페이즈를 Subagent로 병렬 실행하고 있습니다.
- PRD 분석 (PRD Analysis) — PRD별로 Subagent를 기동하여 유스케이스(Use Case)・API・에러(Error)・로깅(Logging)을 추출
- 기존 계획 분석 (Existing Plan Analysis) — 기존의 구현 계획서를 Explore Agent로 분석
- 최적화 전략 수립 (Optimization Strategy Planning) — Plan Agent가 PR 분할・의존 관계(Dependency)・크리티컬 패스(Critical Path)를 설계
- 계획서 생성 (Plan Generation) — 기능별 계획서 생성
- 일관성 검증 (Consistency Verification) — 섹션 번호・용어・의존 관계의 정합성을 문서 전체에 걸쳐 체크
위의 스킬로 구현 계획을 작성할 때 가장 의식한 점은 병렬화의 극대화입니다. 스킬이 PR의 의존 관계 그래프를 만들고, 어떤 PR을 병렬로 진행할 수 있는지, 최속으로 구현하기 위해 어떤 순서로 착수해야 하는지 등을 사고하여 구현 계획을 작성합니다. 이것이 다음 단계인 Agent Teams를 통한 병렬 구현으로 이어집니다.
노하우 3: Agent Teams를 통한 복수 기능의 병렬 구현
다음은 구현 계획으로부터의 병렬 구현입니다. Agent Teams를 활용하여 메인 에이전트(팀 리더) 산하에 복수의 구현 에이전트를 병렬로 배치하여 개발을 진행했습니다.
Subagent로 단순히 병렬 구현하는 것이 아니라, Agent Teams를 활용함으로써 구현 에이전트끼리 서로 리뷰(Review)를 주고받도록 했습니다. 이를 통해 에이전트 간에 작업 내용이 중복되는 것을 방지하고, 생성되는 코드의 품질도 향상시킬 수 있었습니다.
개발 중에는 다음과 같은 프롬프트(Prompt)를 실행하여 여러 기능을 한꺼번에 개발했습니다. 카우셰 팜 미니(Kaushé Farm Mini)에서의 개발에서는 1회의 지시로 5~15건 정도의 PR이 생성되었습니다.
당신은 카우셰(Kaushé)의 엔지니어 스페셜리스트 집단 팀 리더입니다.
`docs/web/farm-line/`의 구현 계획에 기반하여, 후속으로 구현 가능한 부분의 구현을 진행해 주세요.
병렬화 및 효율화를 위해 agent teams를 활용하여 실시해 주세요.
...
개발 중에는 스킬화하지 못했지만, 향후 스킬화할 계획입니다.
노하우 4: AI Review의 철저한 시행
당연한 이야기지만, 1인 개발에서는 코드 리뷰(Code Review)가 과제가 됩니다. 리뷰어가 되어줄 사람이 없기 때문에 AI Review를 철저히 시행했습니다.
PR의 대상 파일에 따라 각각의 리뷰 관점에 특화된 AI Review를 실행하는 워크플로우(Workflow)를 구축했습니다.
| Workflow | 트리거 (Trigger) | 리뷰 관점 |
|---|---|---|
ai-review-prd.yaml | PRD 파일 변경 시 | 사양의 망라성, 일관성, 유스케이스 정의 |
ai-review-impl-plan.yaml | 구현 계획 변경 시 | PR 분할의 타당성, 의존 관계 |
ai-review-backend.yaml | Backend 코드 변경 시 | Go 구현, proto 정의 정합성, 에러 설계 |
ai-review-web-farm-line.yaml | Frontend 코드 변경 시 | 컴포넌트 설계, 컴포넌트 공통화, TypeScript 구현, LIFF 특유의 동작 |
ai-review-ai-codes.yaml | .ai/ 하위 변경 시 | AI Rules・프롬프트・스킬 정의의 정합성 |
리뷰 관점을 영역별로 전문화함으로써, 각 영역에서 깊이 있고 적절한 피드백을 얻을 수 있습니다.
나아가, AI Review가 스스로 학습하여 정밀도를 높여가는 자기 개선 메커니즘도 포함되어 있습니다. 다음의 세 가지가 연동되어 리뷰가 자동으로 개선됩니다.
web-farm-line-learned-rules.md
-
과거 리뷰에서 인간이 수정한 내용을 축적하는 학습 규칙 파일
-
각 워크플로우에서 참조함으로써 동일한 지적 누락을 방지
ai-review-web-farm-line-merge-insight.yaml
-
PR이 머지(Merge)될 때마다, 해당 PR에서 "어떤 지적이 있었고 어떻게 수정되었는지"를 축적
-
후속 작업에서 유사한 지적을 반복하지 않음
ai-review-self-improve-web-farm-improve.yaml
- 추출된 인사이트(Insight)를 집약하여 학습 규칙을 지속적으로 업데이트
이를 통해 개발할 때마다 AI Review가 스스로 진화해 나가는 메커니즘을 구축하고 있습니다.
아래 기사에서 자세히 설명하고 있으니, 함께 읽어주시면 감사하겠습니다.
결과
성과: 1일 평균 PR 생성 수 15.8건, 1인이 2개월 만에 출시
앞서 언급한 노력 덕분에, 개발 피크였던 2026년 4월의 1일 평균 PR (Pull Request) 생성 수는 15.8건이었습니다. 하루 최대 PR 생성 수가 39건에 달한 날도 있었습니다.
구현해야 할 기능이 결코 적지는 않았지만, 결과적으로 LINE 미니 앱 「카우셰 팜 미니(Kaushe Farm Mini)」를 1인이 2개월 만에 어떻게든 출시할 수 있었습니다.
AI를 전제로 한 개발 방법론, 그리고 병렬 개발 (Parallel Development)을 극한까지 높이는 노력을 통해 소수 인원 및 단기간 개발을 실현할 수 있었습니다.
요약
LINE 미니 앱 「카우셰 팜 미니」 개발에서 도전했던, AI 전제 개발 방법론과 병렬 개발을 최대화하는 노력을 소개했습니다.
간략하게 요약하면 다음과 같습니다.
PRD(제품 요구 사항 문서)·설계·구현 계획 등 모든 문서를 코드와 동일한 리포지토리(Repository)에서 관리
-
AI가 문서와 코드를 횡단하여 참조할 수 있으며, CI (지속적 통합) 상에서 AI Review (AI 리뷰)에도 적용 가능
/impl-plan-from-prd 스킬화
-
PRD로부터 병렬화를 최대화한 구현 계획을 자동 생성
Agent Teams (에이전트 팀)를 통한 병렬 구현
-
메인 에이전트를 팀 리더로 하여, 그 아래에 여러 명의 구현 에이전트를 배치해 병렬 구현
-
에이전트끼리 상호 리뷰를 수행함으로써 작업 중복을 방지하고, 생성된 코드의 품질도 향상
AI Review (AI 리뷰)의 철저한 수행
- 소수 인원(1인 팀)이기에 AI Review를 철저히 진행
- 리뷰 관점을 영역별로 전문화하여 심도 있는 리뷰 실시
learned-rules/merge-insight/self-improve를 통한 자기 개선 루프(Self-improvement loop)로, 개발이 진행됨에 따라 AI Review가 향상되는 메커니즘을 구축
이러한 노력들을 통해 개발 피크였던 2026년 4월에는 1일 평균 PR 생성 수 15.8건을 달성하였고, LINE 미니 앱 「카우셰 팜 미니」를 1인이 2개월 만에 출시하는 성과로 이어졌습니다.
AI를 전제로 한 개발, 병렬 개발의 최대화, 소수 인원 개발 촉진에 힘쓰고 계신 분들께 조금이나마 참고가 되기를 바랍니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기