2026년 4월 10일, 새 앱을 만들 때마다 기획 단계에서 가장 오래 멈추던 나는 vibewithaisy/app-plan-skill을 보고 출발점을 찾았다. 인터뷰로 앱 기획을 구체화하고 문서 구조를 잡아 주는 Claude Code 스킬이었다. 하지만 기획만으로는 손이 움직이지 않는다는 내 기준이 남아 있었다. 그래서 원본을 fork해 경쟁사 조사부터 KPI와 리스크까지 담은 20섹션 PRD 방향으로 바꿨다.
원본 스킬과 내가 바꾼 스킬은 무엇이 달랐나?
원본은 기획을 구체화하는 출발점이었고, 나는 필요성·차별화까지 답해야 다음 단계로 움직일 수 있었다.
“기획만으로는 안 움직였다. 나는 ‘왜 이 앱이 필요한가’, ‘남들과 뭐가 다른가’까지 답이 나와야 손이 움직이는 사람이었다.”
| 항목 | 출발점 | 내가 덧붙인 방향 |
|---|---|---|
| 기획 | 인터뷰와 문서 구조 | 필요성과 차별화의 답 |
| 조사 | 기획 구체화 | 경쟁사 조사 |
| 문서 | 기획 문서 | 20섹션 PRD |
| 범위 | 앱의 출발점 | DB·API·마일스톤·KPI·리스크 |
이 표는 어느 한쪽이 더 낫다는 뜻이 아니다. 내게 부족했던 2%가 무엇이었는지 구분하기 위한 표다. 원본이 없었다면 무엇을 더해야 하는지도 선명하지 않았을 것이다. 나는 원본이 잡아 준 인터뷰와 문서 구조 위에, 조사와 전략을 이어 붙이는 쪽을 택했다.
왜 경쟁사 조사와 차별화 전략을 붙였나?
내가 실제로 만들기 시작하려면 문제의 필요성과 다른 선택지와의 차이가 기획 문서 안에서 먼저 보여야 했다.
새 앱의 아이디어는 제목만으로는 움직임으로 이어지지 않았다. 그래서 나는 web_search와 web_fetch를 이용한 경쟁사 조사를 붙이고, 차별화 전략을 문서의 한 부분으로 넣었다. 이 선택은 다른 앱이 부족하다는 판정을 내려는 것이 아니라, 내가 왜 이 앱을 만들려 하는지를 적어 두기 위한 장치였다.
경쟁사 조사는 질문을 바꾸는 데도 도움이 된다. ‘무엇을 만들까’에서 멈추지 않고, ‘이미 있는 선택지와 비교해 무엇을 다르게 할까’로 넘어갈 수 있다. 이 글에서 말하는 변화는 조사 결과의 숫자가 아니라, 기획을 시작하는 순서의 변화다. 실제 사실과 가정을 구분해 문서에 남기는 것도 이 단계에서 중요하다.
20섹션 PRD에는 어떤 범위를 넣었나?
내가 만든 PRD는 문제 정의에서 시작해 DB 스키마, API 설계, 마일스톤, KPI, 리스크까지 20개 섹션을 담도록 했다.
- 문제 정의
- 경쟁사 조사
- 차별화 전략
- DB 스키마
- API 설계
- 마일스톤
- KPI
- 리스크
목록의 순서는 완성된 제품을 약속하는 목록이 아니다. 기획에서 빠지기 쉬운 질문을 한 문서 안에 모아 둔 것이다. 예를 들어 문제 정의와 차별화 전략은 왜 만들지를 다루고, DB 스키마와 API 설계는 구현을 생각하게 만든다. 마일스톤과 KPI, 리스크는 출시 전후에 무엇을 볼지를 기록하게 한다.
20섹션이라는 숫자도 체크리스트를 위한 숫자다. 항목을 많이 채우는 것이 목적은 아니다. 다만 앱을 시작할 때마다 같은 질문을 처음부터 떠올리는 대신, 이미 필요한 질문을 문서 구조로 꺼내 볼 수 있다는 점에서 내게는 의미가 있었다.
fork는 왜 내 작업 방식과 맞았나?
fork는 남의 도구를 그대로 받아 쓰는 대신, 내게 실제로 필요한 질문과 문서 구조를 추가할 수 있는 출발점이었다.
나는 원본을 그대로 쓰지 않고 내 손에 맞게 고쳤다. 원본은 vibewithaisy/app-plan-skill이고, 내가 만든 fork는 Tygb99/app-builder-skill이다. 두 링크는 이 글의 출발점과 수정 방향을 직접 확인할 수 있는 곳이다.
이 경험에서 중요한 것은 모든 도구를 새로 만든 일이 아니다. 이미 잘 작동하는 출발점을 보고, 내 작업이 멈추는 정확한 지점을 찾아 필요한 부분만 더한 일이다. 기획 문서가 손을 움직이게 하려면, 나에게는 필요성·차별화·실행 범위가 한 번에 보이는 구조가 필요했다.
기획이 실행으로 이어지게 하려면?
내 경우에는 아이디어의 이름보다 문제, 차별화, 구현 범위, 다음 확인 지점을 한 문서에 적는 방식이 도움이 됐다.
- 인터뷰로 앱의 기본 기획을 구체화한다.
- 왜 필요한지와 다른 선택지의 차이를 적는다.
- 문제 정의부터 리스크까지 PRD 항목을 채운다.
- 문서에서 다음에 검증할 항목을 골라 작업으로 옮긴다.
이 순서는 모든 앱에 정답이라는 뜻이 아니다. 내가 기획 단계에서 멈추던 지점을 통과하기 위해 만든 순서다. 기획만으로 움직이지 않았던 사람에게, 20개 섹션은 더 많은 문서 작업이 아니라 실행 전 질문을 놓치지 않는 방법이 됐다.
기획 도구를 고치며 남은 이야기
좋은 출발점은 그대로 복사하는 대상이 아니라, 내 문제와 작업 방식에 맞게 질문을 더할 수 있는 기반이 될 수 있다.
원본 스킬은 무엇을 해 주나?
내가 본 원본은 인터뷰로 앱 기획을 구체화하고 문서 구조를 잡아 주는 Claude Code 스킬이었다.
내가 추가한 핵심 요소는 무엇인가?
경쟁사 조사, 차별화 전략, 그리고 문제 정의부터 KPI와 리스크까지 포함한 20섹션 PRD다.
왜 기획만으로는 부족했나?
나는 왜 필요한지와 남들과 무엇이 다른지까지 답이 나와야 실제로 손을 움직일 수 있었기 때문이다.
fork의 의미는 무엇이었나?
남의 도구를 버리는 것이 아니라, 내 작업을 막는 지점에 맞춰 필요한 구조를 덧붙이는 선택이었다.
이 글은 제가 2026-04-10에 스레드에 올리고 직접 겪은 일을, 빠졌던 맥락과 확인 방법까지 더해 다시 쓴 글입니다. 원문은 여기서 볼 수 있습니다 → 원본 스레드 글