서비스 기획서 작성법 2026: 앱 기획서 양식과 개발 발주 전 준비 항목

서비스 기획서는 만들려는 서비스가 누구의 어떤 문제를 어떻게 푸는지, 그리고 그 결과로 어떤 화면과 기능이 필요한지를 한 문서에 모아 놓은 문서예요. 개발사는 이 문서를 읽고 견적을 계산하고 일정을 잡습니다. 발주자 입장에서 기획서는 잘 쓴 문서가 아니라 견적과 일정의 근거가 되는 문서입니다.

이 글은 기획자가 사내에서 쓰는 기획 문서 작성법이 아니라, 비개발 창업자가 개발사에 들고 갈 최소 문서 세트를 기준으로 정리했어요. 무엇을 반드시 넣고, 무엇은 넣지 않아도 되고, 어떤 순서로 채우며, 기획서 다음에 어떤 문서가 어떤 순서로 이어지는지를 다룹니다.

서비스 기획서는 개발 발주에 왜 필요한가요?

포텐랩이 견적을 낼 때는 만들 것의 개수를 셉니다. 화면이 몇 개인지, 기능이 몇 개인지, 외부 서비스에 몇 군데 붙는지가 금액과 기간으로 환산돼요. 기획서는 그 개수를 세게 해주는 문서입니다.

문서가 없으면 개수를 셀 수 없으니 그 자리가 가정으로 채워집니다. 그 가정은 견적서에 드러나지 않고, 착수 후에 서로 다른 그림이 부딪히면서 드러나요. 이 시점의 조정은 추가 비용과 일정 지연으로 정산되기 쉽습니다.

또 하나, 기획서는 여러 개발사의 회신을 같은 축에 놓게 해줍니다. 같은 문서를 받은 세 곳의 금액은 비교할 수 있지만, 각자 다르게 상상한 세 곳의 금액은 비교 대상이 아니에요. 견적서를 항목 단위로 뜯어보는 방법은 앱 개발 견적서 뜯어보는 법에 따로 정리해 두었습니다.

기획서를 말로만 설명하면 견적서에 무엇이 남나요?

문서 없이 말로만 설명한 미팅에서는 다음과 같은 일이 반복적으로 관찰됩니다. 하나는 견적이 하나의 금액이 아니라 폭 넓은 구간으로 오는 것입니다. 하한과 상한이 크게 벌어진 회신이 오기도 합니다. 셀 수 있는 항목이 없으면 위험을 폭으로 표현하게 돼요.

다른 하나는 빈칸이 회신하는 쪽에서 채워지는 것입니다. 회원 가입은 이메일만 받는지 소셜 로그인까지 넣는지, 관리자 화면이 있는지 없는지 같은 항목이 문서에 남지 않은 채 정해져요. 그러면 세 곳의 회신이 서로 다른 범위를 담게 되고, 금액이 달라도 그 차이가 범위 때문인지 단가 때문인지 구분할 수 없습니다.

여기서 잃는 것은 금액 자체가 아니라 비교의 축입니다. 회신을 같은 표에 올릴 수 없으면 어느 쪽이 싼지도 판단이 안 되고, 착수 이후의 조정도 문서가 없어 협상이 됩니다. 변경을 문서로 처리하는 절차는 변경 요청서(CR) 작성 가이드에 있습니다.

서비스 기획서에 반드시 있어야 하는 항목은 무엇인가요?

발주 목적의 기획서라면 일곱 개 블록이면 충분합니다. 분량보다 중요한 건 각 블록이 제3자가 읽고 같은 뜻으로 다시 말할 수 있는가예요. 아래 표의 오른쪽 칸은 그 판정 기준입니다.

일곱 개 중 하나라도 비어 있으면 그 자리가 개발사의 가정으로 채워집니다. 특히 마지막 블록인 우선순위가 비면 견적이 전체 기능 합계로 나와서 금액이 부풀어요. 무엇을 1차에서 빼는지 정하는 절차는 MVP 범위 확정 절차에서 다룹니다.

층위를 하나 갈라 둘게요. 예산 계획, 일정 수립, 출시 후 유지보수까지 포함한 프로젝트 기획 전반은 IT 프로젝트 기획 완전 가이드에서 다룹니다. 이 글은 그 안에서 개발사에 실제로 넘기는 문서 한 건으로 범위를 좁혔어요. 그래서 아래에서도 예산과 일정은 제약 항목으로만 적고 더 파고들지 않습니다.

기획서에 없어도 되는 항목은 무엇인가요?

넣지 않아도 되는 것까지 채우려다 문서가 멈추는 일이 있습니다. 아래 항목들은 비워두는 편이 낫고, 억지로 채우면 오히려 견적을 왜곡합니다.

기술 스택을 지정하지 않는 대신, 개발사가 제안한 스택이 우리에게 어떤 제약을 남기는지는 확인해야 합니다. 그 판단 기준은 앱 개발 언어 선택 가이드에 정리돼 있어요.

앱 기획서 양식은 어디서 구하고, 어떤 순서로 채우나요?

양식 파일을 구하는 일에 시간을 쓸 필요는 없습니다. 슬라이드든 문서든 표 계산 파일이든, 앞의 일곱 개 블록이 순서대로 들어 있으면 그게 양식이에요. 회신을 준비하는 쪽이 보는 것은 파일 형식보다 블록의 존재 여부인 경우가 많습니다.

다만 목차 순서와 채우는 순서는 다릅니다. 목차는 정의에서 기능으로 내려가지만, 실제로는 사용자와 흐름을 먼저 잡아야 기능 목록이 저절로 나와요. 채우는 순서는 이렇게 잡습니다.

1. 대상 사용자와 역할을 이름으로 갈라 적습니다. 역할이 두 종류 이상이면 각각 별도로 씁니다.
2. 역할별로 서비스를 처음 열어서 목적을 이룰 때까지의 동작을 순서대로 적습니다.
3. 그 순서에 등장하는 화면에 이름을 붙입니다. 여기서 화면 목록이 나옵니다.
4. 각 화면에서 사용자가 누르는 것을 기능 문장으로 옮깁니다. 여기서 기능 목록이 나옵니다.
5. 저장해야 하는 정보와 외부에 붙어야 하는 지점을 표시합니다.
6. 마지막으로 1차 출시에 넣을 것과 미룰 것을 갈라 표시하고, 맨 앞으로 돌아가 한 줄 정의를 씁니다.

한 줄 정의를 마지막에 쓰는 이유는 앞의 다섯 단계를 거친 뒤라야 서비스가 실제로 무엇인지가 손에 잡히기 때문이에요. 처음부터 한 줄 정의를 붙들고 있으면 문서가 앞으로 나가지 않습니다.

기획서 다음에는 어떤 문서가 어떤 순서로 이어지나요?

발주자가 자주 헷갈리는 지점이 여기예요. 기획서·요구사항 정의서·기능명세서·화면설계서는 같은 것을 네 번 쓰는 게 아니라, 앞 문서가 확정돼야 다음 문서를 시작할 수 있는 순서를 가진 네 개의 문서입니다. 아래 표는 그 순서만 봅니다.

각 문서에 어떤 항목이 들어가는지, 양식이 어떻게 생겼는지는 문서별로 따로 다룹니다. 이 표는 정본이 아니라 어느 문서가 먼저 확정돼야 다음이 시작되는지만 보여주는 자리예요.

순서를 건너뛰면 뒤에서 되돌아옵니다. 기획서 없이 화면 디자인부터 시작하면 예쁜 화면이 나온 뒤에 그 화면이 왜 필요한지 설명하지 못하게 되고, 기능명세서 없이 개발에 들어가면 검수 때 합격 기준이 없어서 인수가 지연돼요.

발주자가 직접 쓰는 문서는 이 중 서비스 기획서 한 건이면 됩니다. 나머지는 개발사가 작성하고 발주자는 확인해요. 창업자 몫과 개발사 몫을 산출물별로 가르는 기준은 MVP 기획, 개발사에 뭘 들고 가야 할까에 정리돼 있으니, 여기서는 위 표의 작성 주체는 그대로 두고 확인 항목만 봅니다.

확인은 읽고 고개를 끄덕이는 작업이 아니라 오른쪽 칸을 하나씩 짚는 작업입니다. 짚다가 답이 안 나오는 항목이 그다음 미팅의 안건이 되고, 그 자리에서 정리되지 않으면 착수 후에 비용이 붙는 자리가 돼요.

프로젝트 산출물 목록에는 무엇을 어떻게 적어야 하나요?

계약서에 산출물 목록이 없으면, 프로젝트가 끝날 때 무엇을 받아야 하는지가 서로 다르게 남습니다. 산출물은 이름만 적으면 부족하고 형식과 받았다고 인정하는 기준을 같이 적어야 해요.

오른쪽 칸을 계약서에 적어 두는 것과, 그 기준으로 실제 검수를 통과시키고 잔금을 정산하는 것은 다른 일입니다. 이 글은 계약서에 목록과 인정 기준을 적는 데까지만 다루고, 승인 단계와 사인오프 절차는 IT 외주 개발 산출물 검수·사인오프 가이드에서 이어서 보시면 됩니다.

표에서 계정 명의가 두 번 나오는 건 의도한 겁니다. 저장소와 외부 서비스 계정이 개발사 명의로 남으면, 계약이 끝난 뒤에도 서비스의 열쇠를 남이 들고 있게 돼요. 인계 시점에 확인할 자산 목록은 IT 외주 개발 인수인계 가이드에 더 자세히 있습니다.

기능 목록은 어떤 문장으로 적어야 하나요?

기능 목록은 기획서에서 개발사가 개수를 세는 부분입니다. 셀 수 있게 쓰려면 문장 형태를 고정하는 게 좋아요. 권하는 형태는 "누가 어디에서 무엇을 할 수 있다" 한 줄입니다.

• 세기 어려운 문장: "회원 관리 기능" — 가입인지 탈퇴인지 등급 변경인지 알 수 없어서 개발사마다 다르게 셉니다.
• 셀 수 있는 문장: "관리자는 회원 목록 화면에서 회원의 등급을 변경할 수 있다" — 화면 하나와 동작 하나로 분해됩니다.
• 세기 어려운 문장: "결제 기능" — 카드만인지 간편결제까지인지, 부분 취소가 있는지 없는지가 열려 있습니다.
• 셀 수 있는 문장: "구매자는 주문서 화면에서 카드로 결제할 수 있다" "구매자는 주문 내역 화면에서 결제를 전액 취소할 수 있다" — 두 줄로 나뉘고 각각 견적에 잡힙니다.

예외가 있는 기능은 기획서에 예외가 있다는 사실만 표시해 두면 됩니다. 결제 실패나 중복 취소가 어떤 조건에서 어떻게 처리되는지를 조건문으로 확정하는 것은 기능명세서 단계의 일이고, 그 방법은 아이디어를 기능 명세서로 만드는 방법에 있습니다.

화면 목록은 몇 개까지 적어야 하나요?

기획서에서 화면은 그리는 대상이 아니라 세는 대상입니다. 필요한 건 그림의 완성도가 아니라 화면의 개수와 이동 규칙이에요. 도구를 배우느라 문서 작성이 멈추는 편이 더 손해입니다.

세 가지가 있으면 개수를 셀 수 있습니다. 화면마다 이름이 중복 없이 붙어 있을 것, 어느 화면에서 어느 화면으로 갈 수 있는지 적혀 있을 것, 그리고 로그인하지 않은 사용자가 볼 수 있는 화면과 없는 화면이 갈려 있을 것. 손으로 적은 목록이어도 이 세 가지가 있으면 셀 수 있어요.

여기서 자주 빠지는 것이 관리자 화면입니다. 사용자용 화면만 세다가 운영자가 쓸 화면이 목록에서 빠진 채로 견적이 나가는 경우가 있고, 이건 착수 후에 발견되면 화면 수가 통째로 늘어나는 항목이에요.

반대로 화면 안에 무엇을 어디에 놓을지, 어느 수준까지 그릴지는 화면설계서 단계에서 정합니다. 색상·폰트·여백도 그 단계의 일이에요. 기획서에서는 이름과 개수, 그리고 이동 규칙까지만 확정하면 됩니다.

기능 말고 따로 적어야 하는 조건에는 무엇이 있나요?

기능 목록에 안 잡히는데 견적을 크게 움직이는 항목들이 있습니다. 기획서 뒤쪽에 조건 항목으로 모아 적어두면 됩니다.

• 사용 범위: 웹만인지, 앱까지인지, 앱이라면 iOS와 안드로이드를 둘 다 내는지.
• 로그인 방식: 이메일 가입인지, 카카오·네이버·애플 같은 소셜 로그인을 붙이는지. 붙일 계정 종류를 이름으로 적습니다.
• 결제와 정산: 결제만 받는지, 판매자에게 나눠주는 정산까지 있는지.
• 알림: 앱 푸시인지, 문자인지, 이메일인지. 발송 비용은 개발비와 별개로 매달 나가는 항목입니다.
• 언어: 한국어만인지 다국어인지.
• 데이터 보관과 권한: 어떤 정보를 얼마나 보관하는지, 누가 열람할 수 있는지.
• 운영 환경: 서버를 우리 계정에 두는지 개발사 계정에 두는지.

이 목록은 항목 이름까지만 적는 자리입니다. 각 항목이 며칠짜리 작업인지, 얼마가 붙는지는 기획서에서 추정하지 말고 회신에 맡기세요. 발주자가 미리 계산해 적어 넣으면 그 숫자가 협상의 기준선이 되어 버립니다.

마지막 항목은 비용보다 통제권의 문제입니다. 서버와 도메인이 개발사 계정에 있으면 개발사를 바꾸는 순간 서비스가 멈출 수 있어요. 기획서 단계에서 우리 명의로 하겠다고 한 줄 적어두면 계약서에도 그대로 반영됩니다.

기획서에서 자주 빠지는 항목은 무엇인가요?

사용자가 보는 화면을 따라 적다 보면 뒤에서 돌아가는 것들이 통째로 빠집니다. 아래 항목은 빠져도 미팅에서 티가 나지 않고, 개발 중반이나 출시 직전에 별건으로 붙는 자리예요.

마지막 줄은 기획서 단계에서 한 문장으로 끝낼 수 있습니다. 스토어 계정은 우리 명의로 만들고 비용도 우리가 부담한다고 적어 두면 됩니다. 계정 종류와 등록 절차는 애플 개발자 계정 비용과 등록 절차에서 확인할 수 있어요.

기획서는 얼마나 자세해야 충분한가요?

페이지 수로 판단하지 않는 편이 좋습니다. 대신 세 가지 질문을 던져 보세요. 이 문서만 읽은 사람이 화면 수를 셀 수 있는가, 기능을 셀 수 있는가, 그리고 1차 출시에서 무엇이 빠지는지 말할 수 있는가.

세 질문에 다 답이 되면 그 기획서는 발주에 쓸 수 있습니다. 답이 안 되는 부분만 보강하면 되고, 나머지를 더 예쁘게 다듬는 작업은 견적에 아무 영향을 주지 않아요.

확인하는 방법도 간단합니다. 서비스를 모르는 지인에게 문서만 주고 화면이 몇 개인지 세어 보라고 하면 됩니다. 세다가 막히는 지점이 개발사가 가정으로 채울 지점이에요.

AI 도구로 기획서 초안을 만들어도 되나요?

초안을 빨리 만드는 용도로는 쓸 만합니다. 화면 목록을 뽑거나, 빠뜨린 예외 상황을 물어보는 식으로 쓰면 문서 작성 시간이 줄어요. 다만 발주 문서로 쓸 때는 AI가 채운 빈칸은 우리가 판단한 내용이 아니다라는 점을 기억해야 합니다.

넘기기 전에 세 가지를 확인하세요. 우리가 말한 적 없는 기능이 목록에 들어가 있지 않은지, 사용자 역할이 실제 사업 구조와 맞는지, 그리고 근거 없는 수치가 문서에 섞이지 않았는지입니다.

세 번째가 특히 문제가 됩니다. 목표 사용자 수나 처리 건수 같은 숫자가 근거 없이 들어가면, 그 숫자가 서버 구성과 견적의 기준으로 쓰이게 돼요. 확인되지 않은 숫자는 지우고, 아직 모른다고 적는 편이 낫습니다.

기획서를 그대로 견적 요청에 써도 되나요?

기획서는 견적 요청의 핵심 첨부 문서이지만, 그것만 보내면 회신이 제각각으로 옵니다. 기획서가 무엇을 만들지를 말한다면, 견적 요청서는 어떤 조건으로 회신해 달라를 말하기 때문이에요.

같이 적어 보낼 것은 네 가지입니다. 회신 기한, 회신 형식(항목별 금액과 기간을 나눠 적어 달라는 요구), 우리 쪽 예산과 일정의 제약, 그리고 질문을 받는 방법과 기간. 이 네 가지가 있으면 세 곳의 회신을 같은 표에 올려 비교할 수 있습니다.

공고 형태로 여러 곳에 보내는 경우에는 제안요청서 형식을 갖추는 편이 낫습니다. 무엇을 담고 어떻게 보내는지는 RFP 뜻과 작성법 가이드에 정리해 두었어요.

기존 서비스를 고치는 경우에도 기획서가 필요한가요?

필요하고, 새로 만드는 경우보다 오히려 한 블록이 더 붙습니다. 지금 서비스가 어떤 상태인지를 먼저 적어야 하기 때문이에요. 견적을 내는 쪽은 우리 서비스 내부를 모르는 상태에서 시작하게 되고, 그 정보가 없으면 모르는 부분이 위험으로 남아 금액에 얹히게 됩니다.

현재 상태 블록에는 네 가지를 적습니다. 지금 있는 화면 목록, 지금 쓰고 있는 외부 서비스와 계정 명의, 데이터가 어디에 얼마나 쌓여 있는지, 그리고 손대면 안 되는 부분입니다. 마지막 항목은 운영 중인 서비스에서 특히 중요해요.

그다음에 바꿀 것을 적습니다. 이때도 문장 형태는 같습니다. 무엇을 추가하고, 무엇을 바꾸고, 무엇을 없애는지를 기능 문장으로 나눠 적으면 개수를 셀 수 있어요. 기존 서비스에 기능을 얹을 때 비용이 어떻게 잡히는지는 기존 서비스에 AI 기능 추가 비용 가이드에서 다룹니다.

기획서를 넘긴 뒤에는 무엇이 달라지나요?

넘긴 순간부터 그 문서는 개인 메모가 아니라 계약의 기준선이 됩니다. 그래서 세 가지를 정해 두어야 해요. 문서의 버전과 날짜, 우리 쪽 의사결정권자 한 명, 그리고 변경을 처리하는 방법입니다.

버전과 날짜가 없으면 두 달 뒤에 어느 파일이 기준인지 다투게 됩니다. 파일 이름 끝에 날짜를 붙이고 표지에 버전을 적는 정도면 충분해요. 의사결정권자는 여러 명이면 곤란합니다. 창업 팀 안에서 서로 다른 답이 개발사에 전달되면 그 조정 시간이 일정에 그대로 얹힙니다.

변경은 없앨 수 없으니 처리 경로를 정해 둡니다. 착수 이후의 요청은 말이 아니라 문서로 넣고, 금액과 일정에 미치는 영향을 회신받은 뒤에 결정하는 방식이에요. 프로젝트 시작 첫 주에 무엇을 합의해야 하는지는 킥오프 미팅 가이드에 항목별로 있습니다.

기획서를 혼자 만들기 어렵다면 어떻게 하나요?

일곱 개 블록 중 앞의 세 개(한 줄 정의, 사용자와 역할, 핵심 흐름)는 창업자가 직접 쓰는 편이 낫습니다. 이건 개발 지식이 아니라 사업 판단이고, 대신 써 줄 사람이 없어요. 뒤의 네 개는 개발사와 같이 앉아서 채울 수 있습니다.

기획을 유상 단계로 분리해서 진행하는 개발사도 있습니다. 이때는 그 단계의 산출물을 다른 개발사에 가져가도 되는지를 착수 전에 문서로 확인해 두세요.

포텐랩은 앱과 웹 프로덕트, MVP 개발을 맡고, 트리숲(TreeSoop)은 AI 챗봇·RAG처럼 AI 자체가 제품인 영역을 맡습니다. 만들려는 것이 화면과 기능으로 설명되면 포텐랩 쪽이고, 결과가 매번 달라지는 AI 응답이 제품의 핵심이면 트리숲 쪽이에요. 맞지 않는 쪽에 발주하면 서로 손해라서, 기획서 초안을 보고 이 분기를 착수 전에 갈라 두는 편이 서로에게 낫습니다. 포텐랩은 자체 집계 기준으로 97% 수행완수율을 유지하고 있어요.

기획서가 아직 한 줄 정의 단계라도 괜찮습니다. 이 글의 표들을 그대로 목차로 놓고 위에서부터 채워 내려가면, 다음 미팅에서 개발사가 개수를 셀 수 있는 문서가 됩니다.

자주 묻는 질문

서비스 기획서에는 어떤 항목이 반드시 들어가야 하나요?

발주 목적이라면 일곱 개 블록이면 충분합니다. 서비스 한 줄 정의, 대상 사용자와 역할, 핵심 사용 흐름, 기능 목록, 화면 목록과 이동 규칙, 데이터와 외부 연동, 제약과 우선순위입니다. 하나라도 비어 있으면 그 자리가 개발사의 가정으로 채워지고, 특히 우선순위가 비면 견적이 전체 기능 합계로 나와 금액이 부풀어요.

앱 기획서 양식은 어디서 구해야 하나요?

양식 파일을 구하는 데 시간을 쓸 필요는 없습니다. 슬라이드든 문서든 표 계산 파일이든 일곱 개 블록이 순서대로 들어 있으면 그게 양식이고, 회신을 준비하는 쪽이 보는 것은 파일 형식보다 블록의 존재 여부인 경우가 많습니다. 채우는 순서는 사용자와 역할, 사용 흐름, 화면 목록, 기능 목록 순이고 한 줄 정의는 마지막에 씁니다.

기획서 없이 말로만 설명하면 견적서에 무엇이 남나요?

다음과 같은 일이 반복적으로 관찰됩니다. 하나는 견적이 하나의 금액이 아니라 폭 넓은 구간으로 오는 것이고, 셀 수 있는 항목이 없으면 위험을 폭으로 표현하게 됩니다. 다른 하나는 빈칸이 회신하는 쪽에서 채워지는 것이라 세 곳의 회신이 서로 다른 범위를 담게 돼요. 이때 잃는 것은 금액 자체가 아니라 회신을 같은 표에 올려 비교하는 축입니다.

기획서에 넣지 않아도 되는 항목은 무엇인가요?

데이터베이스 설계(ERD), 기술 스택 지정, 완성된 디자인 시안, API 상세 명세, 3년 로드맵과 시장 분석, 조직도는 비워두는 편이 낫습니다. 기능이 바뀌면 다시 그려야 하거나, 개발사가 설계 단계에서 만드는 산출물이거나, 견적 산정에 쓰이지 않기 때문이에요. 대신 저장할 정보 항목 이름, 지켜야 할 조건, 화면별로 반드시 보여야 하는 정보, 연동할 외부 서비스 이름을 적습니다.

기존 서비스를 고치는 경우에도 기획서가 필요한가요?

필요하고, 새로 만드는 경우보다 블록이 하나 더 붙습니다. 현재 상태 블록에 지금 있는 화면 목록, 쓰고 있는 외부 서비스와 계정 명의, 데이터가 어디에 얼마나 쌓여 있는지, 손대면 안 되는 부분을 적으세요. 그다음 무엇을 추가하고 바꾸고 없앨지를 기능 문장으로 나눠 적으면 개수를 셀 수 있습니다.

프로젝트 산출물 목록은 계약서에 어떻게 적어야 하나요?

산출물은 이름만 적으면 부족하고 형식과 받았다고 인정하는 기준을 같이 적어야 합니다. 소스코드 저장소는 우리 명의 계정이 소유자 권한을 가질 것, 운영 매뉴얼과 계정 목록은 외부 서비스 계정이 우리 명의로 되어 있을 것처럼 씁니다. 기획 확정, 설계 완료, 개발 중간, 개발 완료, 검수, 인계 여섯 시점으로 나눠 적으면 빠지는 자리가 줄어들고, 그 기준으로 검수를 통과시키는 승인 절차는 계약서와 별도로 정합니다.

함께 읽으면 좋은 글

• 기능명세서 양식과 한 행에 넣을 항목
• 요구사항 정의서와 기능명세서의 차이
• 화면설계서와 와이어프레임의 차이