기획서 작성법, 외주 넘기기 전 개발자에게 줄 뼈대

기획서를 어떻게 써야 개발 업체가 제대로 알아들을지 막막하다는 분이 많습니다. 2026년 기준으로 보면 외주 발주 전 기획서는 화려한 문서가 아니라 '무엇을, 왜, 누구를 위해 만드는지'와 화면 목록·사용자 흐름·필요 기능을 개발자가 읽고 바로 견적을 낼 수 있게 적은 뼈대입니다. 형식을 갖추는 것보다 서로 같은 그림을 그리게 만드는 일이 먼저입니다.

핵심 요약

• 기획서는 아이디어를 개발자 언어로 옮기는 첫 문서로, 뒤이어 쓰는 요구사항 정의서나 기능 명세서와 역할이 다릅니다.
• 최소한의 뼈대는 서비스 목적, 화면 목록, 사용자 흐름, 필요 기능 네 가지입니다.
• 화면마다 이름과 번호를 붙여 표로 정리하면 개발자가 작업량을 가늠하기 쉽습니다.
• '알아서 예쁘게' 같은 애매한 표현이 견적 부풀림과 추가 비용, 분쟁의 출발점이 됩니다.

기획서·요구사항 정의서·기능 명세서는 다른 문서다

세 문서를 같은 것으로 여기면 어디까지 적어야 할지 감이 잡히지 않습니다. 기획서는 '무엇을 왜 만드는가'를 담고, 요구사항 정의서는 그 요구를 항목으로 정리하며, 기능 명세서는 각 기능이 어떻게 동작하는지를 자세히 적습니다. 발주자가 처음 쓰는 문서는 기획서이고, 나머지는 그 뼈대 위에서 구체화됩니다.

문서	답하는 질문	주로 쓰는 사람
기획서	무엇을 왜 누구를 위해	발주자(비개발자)
요구사항 정의서	어떤 기능이 필요한가	발주자·기획자
기능 명세서	그 기능이 어떻게 동작하나	기획자·개발자

그래서 기획서 단계에서는 세세한 동작까지 정할 필요가 없습니다. 항목별 정리는 다음 단계인 요구사항 정의서 작성법에서, 화면 동작의 상세는 기능 명세서 작성법에서 이어 가면 됩니다.

기획서에 꼭 들어가는 네 가지 뼈대

실제 프로젝트에서 견적이 매끄럽게 나오는 기획서는 대체로 네 부분을 갖추고 있습니다. 첫째, 서비스 목적입니다. 배경과 해결하려는 문제, 주 사용자를 비즈니스 관점에서 두세 문단으로 적습니다. 기술 설명보다 '이 서비스가 왜 필요한가'가 먼저입니다.

둘째, 화면 목록입니다. 필요한 화면을 빠짐없이 나열하고 화면마다 이름과 번호를 붙입니다. 화면 번호가 있으면 개발자가 페이지 전환과 작업량을 화면 단위로 셀 수 있습니다. 셋째, 사용자 흐름입니다. 방문자가 첫 화면부터 목표 지점까지 어떤 순서로 움직이는지 화살표로 이어 그립니다. 넷째, 필요 기능입니다. 화면별로 어떤 동작이 있어야 하는지 문장으로 적되 있으면 좋은 기능과 없으면 안 되는 기능을 구분해 둡니다.

빈 종이가 막막할 때 시작하는 순서

기획서를 처음 쓰면 빈 화면 앞에서 막막해지기 쉽습니다. 실제로 해 보면 글부터 쓰기보다 화면을 손으로 그려 보는 편이 훨씬 빠릅니다. 종이에 네모를 여러 개 그리고 각 네모를 하나의 화면으로 삼아 이름을 붙인 다음, 화면 사이를 화살표로 이으면 화면 목록과 사용자 흐름이 한 번에 만들어집니다. 이 스케치를 그대로 문서로 옮기면 절반은 끝난 셈입니다.

순서를 정리하면 이렇습니다. 먼저 서비스가 풀려는 문제와 주 사용자를 한 문단으로 적고 다음으로 필요한 화면을 손그림으로 나열합니다. 화면이 정해지면 첫 화면부터 목표 행동까지 흐름을 잇고 마지막으로 화면마다 필요한 기능과 예외 상황을 한 줄씩 답니다. 이때 자주 빠뜨리는 것이 예외 상황입니다. '결제가 실패하면 어디로 가는지', '검색 결과가 없으면 무엇을 보여줄지' 같은 문장을 미리 적어 두면 개발 중에 되묻는 일이 줄어듭니다.

애매한 요구가 분쟁으로 번지는 지점

외주를 진행하다 보면 기획서의 한 줄이 프로젝트 전체를 흔드는 장면을 만납니다. '요즘 스타일로 세련되게', '결제는 알아서 붙여 주세요' 같은 문장이 대표적입니다. 발주자는 당연히 통할 거라 생각하지만 개발자는 범위를 알 수 없어 넓게 잡습니다. 그만큼 견적이 벌어집니다.

자주 부딪히는 오해를 짚어 보겠습니다. 첫째, '말로 설명하면 된다'는 생각입니다. 말은 기록이 남지 않아 나중에 서로 기억이 달라집니다. 둘째, '개발자가 알아서 채워 준다'는 기대입니다. 적히지 않은 것은 견적과 범위에서 빠지고 나중에 추가 비용으로 돌아옵니다. 셋째, '기획서는 완성해야 넘긴다'는 부담입니다. 초안이라도 화면 목록과 흐름이 있으면 업체와 함께 다듬을 수 있습니다. 담당자에게 이렇게 물어 두면 좋습니다. "이 기획서에서 범위가 애매해 견적을 넓게 잡은 항목이 어디인가요?"

개발자에게 넘기기 전 점검

노바랩에서 견적을 낼 때 보면 같은 아이디어라도 기획서가 있느냐에 따라 범위가 크게 달라집니다. 기획서가 없으면 안전하게 넓게 잡아 금액이 커집니다. 뼈대가 잡혀 있으면 불필요한 항목을 덜어낼 수 있습니다. 넘기기 전에 아래를 확인하면 이 차이를 줄일 수 있습니다.

1. 화면 목록에 빠진 화면이 없는지, 화면마다 번호가 붙어 있는지 봅니다.
2. 사용자 흐름이 첫 화면부터 목표 행동까지 끊기지 않고 이어지는지 따라가 봅니다.
3. 기능마다 '있으면 좋은 것'과 '없으면 안 되는 것'을 표시했는지 확인합니다.
4. '알아서·적당히·세련되게' 같은 애매한 표현을 구체적인 문장으로 바꿉니다.
5. 참고할 사이트나 화면 예시를 두세 개 붙여 눈으로 맞춥니다.

가상 예시로, 동네 공방이 수강 신청을 받는 사이트를 맡긴다고 해 보겠습니다. '수강 신청 페이지'라고만 적으면 결제와 정원 관리, 알림이 포함인지 알 수 없습니다. 대신 '강좌 목록(화면1) → 상세(화면2) → 신청·결제(화면3) → 완료·알림(화면4)'로 흐름과 화면 번호를 적으면 업체가 바로 범위를 가늠합니다. 발주 준비 전체 그림은 외주 준비물 7가지에서, 실제 제작을 맡길 때의 진행은 웹앱 제작에서 이어 볼 수 있습니다.