# 앱 기획서 작성법: 한 페이지 템플릿

> 내 iOS 앱 범위를 정하고 AI를 이끄는 한 페이지 기획서예요. 질문 10개, 복사용 템플릿, 넣지 말아야 할 것까지 정리했어요.

원본 페이지: [앱 기획서 작성법: 한 페이지 템플릿](https://devoria.fr/ko/blog/mobile-app-spec-one-page-template)
작성자: [Mehdi Azizi](https://devoria.fr/ko/mehdi-azizi)
게시일: 2026-08-31
최종 내용 수정: 2026-10-09


## 모바일 앱 기획서: 짧은 답

내 앱을 직접 만들 때 좋은 모바일 앱 기획서는 한 페이지면 충분해요. 열 가지 질문에 답하면 돼요. 누구를 위한 앱인지, 어떤 문제를 푸는지, 핵심 기능은 무엇인지, 어떻게 돈을 버는지, 계정 없이 무엇을 할 수 있는지, 어떤 데이터가 유지되어야 하는지, 어떤 플랫폼인지, 첫 버전에서 빠지는 건 무엇인지, 잘 되고 있는지 어떻게 알 수 있는지, 어떤 제약이 있는지예요. 복사해서 쓸 템플릿은 아래에 있어요. [템플릿과 검증 표(.md)를 다운로드](https://devoria.fr/ressources/cahier-des-charges-app-ios.md)할 수도 있어요. 가입은 필요 없어요.

인터넷에서 찾을 수 있는 40페이지짜리 템플릿은 용도가 달라요. 외주 업체에 앱을 맡기는 클라이언트가 계약 문서로 쓰려고 만든 거예요. 여러분은 결정하는 사람이면서 직접 만드는 사람이고, AI의 도움을 받는 경우도 많죠. 여러분의 기획서는 두 가지 역할을 해요. 코딩 전에 결정을 내리는 것, 그리고 Claude, ChatGPT, Cursor가 올바른 앱을 만들 수 있도록 명확한 맥락을 주는 것이에요.

저는 제 iOS 앱을 직접 출시하고 있어요. 미니게임 알람 앱 Solys와 트레이딩 시뮬레이터 TradaZen은 App Store에 올라가 있어요. Nolera와 Clic은 Apple에서 리젝을 받은 뒤 수정했어요. 이 글에서 소개하는 방법은 제가 모든 앱에 적용하는 방법이에요.

## 내 앱의 범위를 정하는 데 한 페이지면 충분한 이유

긴 문서는 일이 진행된 듯한 느낌을 줘요. 하지만 실제로는 한 번 쓰고 거의 다시 읽지 않고, 프로젝트는 처음 몇 주 만에 문서에서 멀어져요. 반대로 한 페이지는 작업을 시작하기 전마다 2분이면 다시 읽을 수 있어요.

공간의 제약에는 쓸모 있는 효과도 있어요. 결정을 강제한다는 거예요. 답이 두 문장을 넘어간다면 아직 결정을 못 내린 경우가 많아요. 3주 뒤 코드에서 발견하는 것보다 종이 위에서 발견하는 게 훨씬 나아요.

마지막으로 한 페이지는 AI에게 딱 맞는 크기예요. 대화에 통째로 붙여 넣거나 프로젝트의 컨텍스트 파일에 넣어 둘 수 있어요. 짧은 문서는 다시 읽기 쉽고 서로 모순되는 지시를 줄여 줘요. 그렇다고 AI가 지시를 따른다는 보장은 없어요. AI의 제안을 이 기준과 비교해 확인하세요.

## 모바일 앱 기획서에는 무엇이 들어가야 할까요?

각 질문에 한두 문장으로 답하세요.

1. **누가, 어떤 상황에서 앱을 쓰나요?** "18~35세"가 아니에요. 하루 중 특정한 순간에 있는 구체적인 한 사람이에요.
2. **앱이 해결하는 문제를 한 문장으로 말하면요?** "그리고 또"가 필요하다면 앱 두 개를 설명하고 있는 거예요.
3. **첫 버전의 핵심 기능 단 하나는 무엇인가요?** 딱 하나예요. 나머지는 숫자가 나올 때까지 기다려요. 고르는 방법은 [iOS 앱 MVP](https://devoria.fr/ko/expertise/ios-app-mvp) 페이지에서 설명해요.
4. **앱은 어떻게 돈을 버나요?** 구독, 일회성 구매, 무료 중 하나예요. 이 답은 첫 화면부터 앱을 바꿔요. 고민된다면 [iOS 앱, 구독일까 일회성 구매일까](https://devoria.fr/ko/blog/ios-app-subscription-vs-one-time-purchase)를 읽어 보세요.
5. **계정 없이 무엇을 할 수 있나요?** 가입 없이 쓸 수 있는 범위를 일찍 정하면 온보딩 흐름 전체를 다시 만들 일이 없어요.
6. **휴대폰을 바꿔도 유지되어야 하는 데이터는 무엇인가요?** Supabase 같은 백엔드가 필요한지, 아니면 모든 걸 기기에 둘 수 있는지를 결정하는 질문이에요.
7. **iOS만인가요, iOS와 Android 둘 다인가요?** 처음이라면 제 조언은 iOS 먼저예요. 이유는 [iOS와 Android 앱 동시 개발](https://devoria.fr/ko/blog/ios-vs-android-app-which-first)에서 자세히 설명해요.
8. **첫 버전에서 명시적으로 제외하는 것은 무엇인가요?** 문서에서 가장 쓸모 있는 부분이에요. 자기 자신과도, AI와도 논쟁이 생기기 전에 끝내 줘요.
9. **잘 되고 있는지 어떻게 알 수 있나요?** 출시 후 몇 주 안에 측정할 수 있는 신호 하나예요. 시작된 무료 체험, 구독자, 다시 돌아오는 사용자 같은 거요.
10. **실제 제약은 무엇인가요?** 매주 쓸 수 있는 시간, 장비, 그리고 [연 99달러](https://developer.apple.com/programs/enroll/)인 [Apple Developer 계정](https://devoria.fr/ko/blog/apple-developer-account-price-free-vs-99)이요. Mac이 없나요? 문제 되지 않아요. [Mac 없이 iOS 앱 출시하기](https://devoria.fr/ko/blog/publish-ios-app-without-mac-expo-eas)에서 설명해요.

## 복사해서 쓰는 기획서 템플릿

이 템플릿을 메모나 프로젝트 루트의 텍스트 파일에 복사한 뒤 한 줄씩 채우세요.

- **앱 가제:** …
- **대상:** …하는 사람, …하는 순간에
- **해결하는 문제(한 문장):** …
- **버전 1의 핵심 기능:** …
- **앱을 처음 열었을 때 사용자가 보는 것:** …
- **수익 모델:** 구독 / 일회성 구매 / 무료, 유료인 부분: …
- **계정 없이 할 수 있는 것:** …
- **휴대폰을 바꿔도 유지할 데이터:** 없음 / …
- **플랫폼:** iOS 먼저 (숫자가 따라오면 나중에 Android)
- **버전 1 제외:** …, …, …
- **성공 신호:** …
- **스택:** React Native, Expo, 계정이 필요하면 Supabase, 구독은 RevenueCat
- **제약:** 주당 …시간, Apple Developer 계정 개설 여부, Mac 유무
- **경험이 좋다고 생각하는 앱과 그 이유:** …

마음에 드는 앱의 스크린샷 3~5장을 좋은 점에 대한 짧은 메모와 함께 추가하세요. 여러분에게도 AI에게도 디자인 가이드보다 훨씬 와닿아요.

> 기획서는 희망 사항 목록이 아니에요. 내린 결정의 목록이에요.

## 예시: 가상의 앱으로 채운 페이지

어느 정도로 구체적으로 써야 하는지 보여 드리기 위해, 예시로 만든 공부 타이머 앱으로 템플릿을 채워 봤어요.

- **대상:** 저녁에 혼자 공부하다 10분이면 집중이 끊기는 학생.
- **문제:** 휴대폰을 만지지 않고 공부 세션을 버티지 못해요.
- **핵심 기능:** 시간을 재는 세션을 시작하고, 연속으로 지킨 날 수를 확인해요.
- **첫 화면:** 세션을 시작하는 버튼 하나.
- **수익 모델:** 상세 통계는 구독, 기본 세션은 무료.
- **계정 없이:** 휴대폰 간 백업을 제외한 전부.
- **버전 1 제외:** 그룹 모드, 친구 랭킹, 위젯, Android 버전.
- **성공 신호:** 며칠 연속으로 다시 돌아오는 사용자.

일부러 빠진 것에 주목하세요. 20개 화면 목록도, 정해진 색상도, 아키텍처도 없어요. 이런 선택은 만들면서 정해지고, 이 페이지는 그 선택들이 핵심 기능에 도움이 되는지 확인하는 데 쓰여요.

## 기획서로 AI를 이끄는 방법

여기서 이 페이지가 가장 큰 효과를 내요. 맥락 없이 코딩하는 AI는 추측을 하고, 여러분의 앱이 아닌 다른 앱을 추측하는 일이 많아요.

**페이지를 프로젝트의 상시 컨텍스트에 넣으세요.** Claude Code는 루트의 `CLAUDE.md` 파일을 읽고, Cursor에는 자체 규칙 파일이 있어요. 여기에 기획서와 스택을 붙여 넣으세요. 그러면 모든 요청이 같은 기반에서 출발해요.

**AI가 너무 많이 하려 할 때는 "버전 1 제외" 항목을 인용하세요.** AI 어시스턴트는 다크 모드, 공유, 알림 같은 추가 기능을 쉽게 제안해요. 제외 목록이 있으면 답은 정해져 있어요. 지금은 아니라고요.

**페이지를 지키는 계획을 요청하세요.** 큰 작업 전에 이렇게 쓰세요. "이게 내 기획서야. 핵심 기능을 위한 계획을 제안해 줘. 아직 코드는 쓰지 마." 계획이 결정한 내용에서 벗어나면 바로 알아챌 수 있어요.

**코드뿐 아니라 페이지도 검토하게 하세요.** "이 기획서에서 모호하거나 모순되는 질문은 뭐야?"라고 물어보세요. 과소평가된 AI 활용법이고, 엉뚱한 방향으로 몇 주를 낭비하는 일을 막아 줘요.

더 깊이 알고 싶다면 [AI로 iOS 앱 만들기](https://devoria.fr/ko/blog/ai-ios-app-pitfalls-verification)에서 함정과 확인 사항을 자세히 정리했어요.

## 결정을 검증 기준으로 바꾸기

핵심 기능에는 관찰 가능한 결과가 있어야 해요. 이 예시의 가상 타이머에서 "타이머가 작동한다"는 너무 모호해요. 대신 이렇게 쓰세요. "세션을 시작하면 남은 시간이 표시되고, 멈출 수 있으며, 앱을 다시 열어도 마지막으로 끝낸 세션을 볼 수 있다." 화면이 잠긴 상태에서도 타이머가 계속 돌아야 하는지는 따로 정하세요. 이 선택에 따라 기술 작업이 달라질 수 있어요.

기능마다 **동작**, **기대 결과**, **증거** 세 줄을 추가하세요. 증거는 계산이라면 자동화 테스트, 사용 흐름이라면 기기에서의 확인이 될 수 있어요. 테스트하지 않은 것도 적어 두세요. 이 작은 표가 있으면 완성된 화면과 실제로 쓸 수 있는 기능을 혼동하지 않아요.

가상 타이머로 채운 표예요. 이미 통과한 테스트가 아니라 확인해야 할 기준이에요.

| 기획 결정                            | 테스트할 것                           | 기대 결과                                        |
| ------------------------------------ | ------------------------------------- | ------------------------------------------------ |
| 기본 세션은 계정 없이 이용 가능      | 앱을 설치하고 가입 없이 세션 시작     | 가입 양식이 시작을 막지 않음                     |
| 중단한 세션은 연속 기록에 포함 안 됨 | 세션을 끝나기 전에 멈추고 기록 열기   | 완료된 세션이 추가되지 않음                      |
| 기록은 기기에 저장                   | 세션을 끝내고 앱을 닫았다가 다시 열기 | 세션이 올바른 시간으로 한 번만 표시됨            |
| 기본 타이머는 네트워크 없이 작동     | 비행기 모드를 켜고 세션 끝내기        | 타이머와 로컬 저장이 계속 사용 가능              |
| 상세 통계는 유료                     | 구독 없이 통계 열기                   | 구독 안내가 표시되고, 기본 세션은 계속 이용 가능 |

아직 모호한 부분은 내려야 할 결정이 돼요. 예를 들어 세션 도중 사용자가 화면을 잠그거나 휴대폰 시간을 바꾸면 어떻게 할까요? 에이전트가 조용히 정하게 두지 마세요. 원하는 동작을 적고, 그 경우를 표에 추가하세요. 실제 설치 환경에서 이런 검수를 진행하려면 [TestFlight로 iPhone 앱 테스트하기](https://devoria.fr/ko/blog/testflight-iphone-app-beta-testing) 가이드를 참고하세요.

### 첫 버전이 넘칠 때 무엇을 뺄지 정하기

기능마다 이렇게 물어보세요. "이 기능이 없어도 사용자가 약속된 결과를 얻을 수 있을까?" 우리 타이머라면 친구 랭킹은 기다려도 돼요. 연속 기록을 약속한다면 끝낸 세션을 다시 볼 수 있어야 해요. 구독 화면은 이 버전에서 실제로 통계를 판매할 때만 필요해요.

결정과 그 이유를 [다운로드용 템플릿의 기록란](https://devoria.fr/ressources/cahier-des-charges-app-ios.md)에 적어 두세요. 테스트 후에 이 선택을 다시 검토하더라도 처음 범위를 정한 이유를 잃지 않아요. 이어서 [Claude Code로 앱 만들기](https://devoria.fr/ko/blog/claude-code-iphone-app-tutorial) 튜토리얼에서 이 기획을 범위가 정해지고 검증 가능한 요청으로 바꾸는 방법을 보여 줘요.

실제 사례로는 [TradaZen이 출시 후 범위를 바꾼 이야기](https://devoria.fr/ko/blog/tradazen-case-study-launch-iphone-app)가 있어요. 기획은 측정 가능한 첫 버전을 내고, 실제 피드백으로 다음 버전을 정하기 위해 있는 거예요.

## 기능 카탈로그의 함정

자연스러운 반응은 앱이 "해야 할" 모든 걸 나열하는 거예요. 지도, 채팅, 알림, 추천 보상, 오프라인 모드. 이런 카탈로그는 끝나지 않는 프로젝트의 가장 확실한 신호예요. 이유는 간단해요. 출시 전에 추가하는 기능 하나하나가 실제 사용자가 무엇이 중요한지 알려 주는 순간을 늦추거든요.

좋은 첫 버전은 한 가지를 잘해요. 그래도 반대 극단은 조심하세요. [App Review Guidelines의 4.2 규정](https://developer.apple.com/app-store/review/guidelines/)에 따라 Apple은 앱이 웹사이트를 포장한 것 이상이기를 요구해요. 핵심 기능 하나는 좋지만, 빈 껍데기는 안 돼요. 그게 [가이드라인 4.2](https://devoria.fr/ko/blog/guideline-4-2-minimum-functionality-app-rejected) 리젝 사유예요.

## 모바일 앱 기획서에 넣지 말아야 할 것

- **완전한 디자인 가이드.** 처음에는 참고 스크린샷 몇 장이면 충분해요.
- **하루 단위 일정.** 아직 지킬 수 있을 만한 정보가 없어요. 주간 목표면 충분해요.
- **상세한 기술 아키텍처.** 검증된 스택을 고르고, 세부 사항은 만들면서 정하세요.
- **나머지와 섞인 "나중에" 기능.** 전부 버전 1 제외 항목으로 보내세요.

## 기획서는 언제 업데이트해야 할까요?

매주 작업을 시작할 때 다시 읽으세요. 업데이트는 진짜 이유로 결정이 바뀔 때만 하세요. iPhone 테스트에서 어떤 화면이 안 된다는 걸 알았을 때, 테스터의 피드백, 진행 중에 발견한 Apple의 제약 같은 거요. 매일 고친다면 더 이상 아무것도 정하지 못하고 있다는 뜻이에요.

첫 버전을 출시하면 이 페이지는 다음 버전의 기반이 돼요. 버전 1에서 제외했던 것들이 숫자가 알려 주는 우선순위대로 올라와요. 아이디어에서 출시까지의 전체 흐름은 [iPhone 앱 만들기](https://devoria.fr/ko/expertise/create-iphone-app) 페이지에 있어요.

## 한 페이지에서 출시된 앱으로

열 가지 질문에 답했다면, 많은 프로젝트가 건너뛰는 작업을 이미 해낸 거예요. 다음은 핵심 기능을 만들고, iPhone에서 테스트하고, 구독을 연결하고, Apple 심사 자료를 준비하는 거예요.

이 과정이 바로 [iOS Kit](https://devoria.fr/ko/kits/ios)이에요. 자기 속도에 맞춰 따라가는 4단계로, 첫 단계에서는 수익을 낼 수 있는 앱과 그 대상, 가격을 정하고, 여러분의 기획서가 그 출발점이 돼요.

아이디어를 한 페이지에 담을 준비가 됐는지 모르겠나요? [무료 진단](https://devoria.fr/ko/diagnostic)이 지금 프로젝트를 막고 있는 것과 먼저 해야 할 단계를 알려 줘요. 이어서 홈에서는 이 기획을 바탕으로 Claude Code로 [모바일 앱을 만드는](https://devoria.fr/ko) 방법을 보여 줘요.

수익도 출시도 약속하지 않아요. 승인은 Apple이 하고, 나머지는 시장이 정해요. 키트가 없어도 이 템플릿이면 시작하기에 충분해요.

## 자주 묻는 질문

### 모바일 앱 기획서는 어떻게 작성하나요?

기획서를 한 페이지로 유지하세요. 질문 열 개, 답 하나에 한두 문장이에요. 대상, 문제, 핵심 기능, 수익 모델, 계정 없이 가능한 것, 유지되어야 하는 데이터, 플랫폼, 첫 버전에서 빠지는 것, 성공 신호, 제약에 관한 질문이에요. 답이 두 문장을 넘는다면 아직 결정을 못 내린 경우가 많아요.

### 앱 기획서는 어떤 프로그램으로 작성하나요?

간단한 메모나 프로젝트 루트의 텍스트 파일이면 돼요. 템플릿을 복사한 뒤 한 줄씩 채우세요. [템플릿과 검증 표(.md)를 다운로드](https://devoria.fr/ressources/cahier-des-charges-app-ios.md)할 수도 있어요. 가입은 필요 없어요. AI를 이끌려면 그다음 프로젝트의 컨텍스트 파일에 넣어 두세요.

### 앱을 만들려면 40페이지짜리 기획서가 필요한가요?

아니요, 내 앱을 직접 만든다면 한 페이지면 충분해요. 인터넷의 40페이지짜리 템플릿은 외주 업체에 앱을 맡기면서 계약 문서가 필요한 클라이언트를 위한 거예요. 여러분은 직접 결정하고 만들어요. 이 페이지는 코딩 전에 결정을 내리고 AI에게 맥락을 주는 데 쓰여요.

### 코딩하는 AI에게 기획서를 어떻게 전달하나요?

페이지를 프로젝트의 상시 컨텍스트에 넣으세요. Claude Code는 루트의 `CLAUDE.md` 파일을 읽고, Cursor에는 자체 규칙 파일이 있어요. AI가 너무 많이 하려 할 때는 "버전 1 제외" 항목을 인용하세요. 큰 작업 전에는 바로 코딩하지 말고 페이지를 지키는 계획부터 요청하세요.

### 기능이 기획서를 지키는지 어떻게 확인하나요?

기능마다 동작, 기대 결과, 증거 세 줄을 추가하세요. 증거는 계산이라면 자동화 테스트, 사용 흐름이라면 기기에서의 확인이 될 수 있어요. 완성된 화면과 실제로 쓸 수 있는 기능을 혼동하지 않도록 테스트하지 않은 것도 적어 두세요.

### 앱 기획서에 넣지 말아야 할 것은 무엇인가요?

피해야 할 네 가지가 있어요. 완전한 디자인 가이드, 하루 단위 일정, 상세한 기술 아키텍처, 나머지와 섞인 "나중에" 기능이에요. 처음에는 참고 스크린샷 몇 장, 일정은 주간 목표면 충분해요. 나중에 할 기능은 전부 버전 1 제외 항목으로 보내세요.


## 내 프로젝트

[iOS Kit](https://devoria.fr/ko/kits/ios): Claude Code로 iPhone 앱을 만드세요. 제 앱들의 Starter Code, 작업을 검사하는 skill, Apple Review Kit, App Store Screenshots Kit, ASO Kit 포함. 129,99 €.