"기획서를 먼저 만들어야 외주를 맡길 수 있다"고 생각하시는 분이 많습니다. 그래서 기획서를 쓰다가 지치거나, 기획 대행 업체에 먼저 돈을 쓰거나, 아예 시작을 못 하기도 합니다. 결론부터 말씀드리면, 기획서 없이 오셔도 됩니다.

기획서가 완벽해야 한다는 오해

외주 개발을 처음 맡기는 분들이 가장 많이 하는 착각이 있습니다. "내가 모든 걸 정리해서 줘야, 개발사가 그대로 만들어준다." 마치 설계도를 완벽하게 그려서 공장에 넘기는 이미지입니다.

하지만 소프트웨어는 공장에서 찍어내는 제품이 아닙니다. 기획 → 개발이 일직선으로 진행되지 않습니다. 개발 과정에서 기획이 바뀌고, 기술적 제약을 반영해서 기획이 조정되고, 사용자 피드백으로 다시 수정됩니다.

완벽한 기획서를 만들고 나서 시작하겠다는 건, 실제로는 시작하지 않겠다는 것과 비슷합니다.

실제로 기획은 대화에서 만들어진다

프로덕트 메이커에 상담 오시는 분들의 상당수가 기획서 없이 오십니다. 그리고 그게 전혀 문제가 되지 않습니다.

미팅에서 이런 대화가 오갑니다:

• "이런 서비스를 만들고 싶은데요" → 핵심 기능이 뭔지 함께 정리
• "이 앱이랑 비슷한데, 여기서 이 부분만 다르게" → 레퍼런스 기반으로 범위 구체화
• "회원이 이렇게 쓰면 좋겠어요" → 사용자 흐름을 화이트보드에 그려봄
• "이 기능이 가능한가요?" → 기술적으로 가능한 방식과 대안 제시

한 번의 미팅으로 끝나지 않을 수도 있습니다. 2~3번 대화를 나누면서 기획이 구체화됩니다. 이 과정 자체가 기획입니다.

아이디어만 있어도 충분하다

상담에 가져오시면 좋은 것:

• 한 줄 설명: "~한 사람을 위한 ~한 서비스"
• 레퍼런스 1~2개: "이 서비스의 이 기능처럼"
• 핵심 시나리오: "사용자가 가입하고, 이걸 하고, 결제한다"

이 정도면 충분합니다. 50페이지짜리 기획서가 아니어도 됩니다. 메모장에 적은 아이디어 몇 줄이면 대화를 시작할 수 있습니다.

오히려 너무 상세한 기획서가 문제일 때

의외겠지만, 200페이지짜리 기획서가 오히려 프로젝트를 어렵게 만드는 경우도 있습니다.

기술적 제약을 고려하지 않은 기획

• "버튼을 누르면 실시간으로 AI가 분석해서 결과를 보여준다" → 실시간 처리가 불가능한 규모일 수 있음
• "모든 데이터를 한 화면에 보여준다" → 성능상 페이징이나 필터가 필수
• "앱과 웹이 완전히 동일하게 동작" → 플랫폼별 제약이 다름

기획자가 기술을 모르는 상태에서 너무 구체적으로 작성하면, 개발 단계에서 대부분 수정이 필요합니다. 기획에 들인 시간이 아까워서 억지로 구현하면, 사용성이 떨어지는 서비스가 됩니다.

변경이 어려운 구조

기획서가 너무 상세하면, 클라이언트도 개발사도 "기획서에 있으니까"라는 말에 갇힙니다. 개발 중에 더 좋은 방법을 발견해도, 기획서를 벗어나는 것에 부담을 느낍니다. 유연성이 사라지는 겁니다.

미팅에서 함께 정리하는 과정

프로덕트 메이커의 첫 미팅은 이렇게 진행됩니다:

1. 아이디어 듣기: 어떤 문제를 풀고 싶은지, 어떤 서비스를 상상하는지
2. 핵심 기능 정리: 전체 기능이 아니라, "이것만 있으면 서비스가 된다"는 핵심 3~5개
3. 기술적 피드백: 이건 이렇게 하면 되고, 이건 이런 제약이 있다
4. 우선순위 정리: 한 번에 다 만들 필요 없음, 뭐부터 만들지 순서 정하기
5. 범위와 일정 가늠: 이 정도면 몇 개월, 이 정도 예산

기획서를 대신 써드리는 건 아닙니다. 대화를 통해 머릿속에 있는 아이디어를 개발 가능한 형태로 함께 구체화하는 과정입니다.

단, 요구사항은 명확해야 한다

기획서가 없어도 된다는 말은, 대충 말해도 된다는 뜻이 아닙니다. 요구사항은 명확해야 합니다.

"대충 이런 거 만들어주세요"로 시작하면, 개발사가 해석한 "대충"과 고객이 생각한 "대충"이 다릅니다. 결과물을 보고 "이게 아닌데요"가 반복됩니다.

기획서라는 형식이 아니어도 됩니다. 하지만 "무엇을 만들고 싶은지", "사용자가 어떤 흐름으로 쓰는지", "핵심 기능이 무엇인지"는 명확하게 정리되어야 합니다.

기획을 개발사에 맡기면 안 되는 이유

"기획까지 다 해주세요"라는 요청이 있습니다. 기획을 함께 정리하는 것과, 기획을 개발사에 위임하는 것은 전혀 다릅니다.

개발사가 기획의 주도권을 가지면 주객이 전도됩니다.

• 개발사 입장에서 오래 걸리고 까다로운 기능은 슬그머니 빠질 수 있습니다
• 돈이 안 되는 기능은 "불필요하다"는 이유로 축소될 수 있습니다
• 개발사에 편한 방향으로 기획이 흘러가면, 정작 고객의 비즈니스에 중요한 기능이 후순위로 밀립니다

기획의 주도권은 반드시 고객에게 있어야 합니다. 개발사는 기술적 가능성과 효율적인 구현 방법을 제안하는 역할이지, 비즈니스 방향을 결정하는 역할이 아닙니다.

좋은 미팅은 고객이 "이걸 만들고 싶다"고 말하고, 개발사가 "그러면 이렇게 만드는 게 좋겠다"고 제안하는 구조입니다. 개발사가 "이건 빼고, 이건 이렇게 바꾸죠"라고 주도하는 순간, 그 기획은 고객의 서비스가 아니라 개발사의 편의에 맞춰진 결과물이 됩니다.

정리

• 기획서가 완벽해야 외주를 시작할 수 있다는 건 오해입니다
• 아이디어와 레퍼런스만 있어도 충분히 대화를 시작할 수 있습니다
• 단, 요구사항은 명확해야 합니다. 기획서 형식이 아니어도, 무엇을 원하는지는 정리되어야 합니다
• 오히려 기술을 모른 채 작성한 상세 기획서는 수정 비용을 키울 수 있습니다
• 기획의 주도권은 고객에게 있어야 합니다. 개발사에 기획을 위임하면 주객이 전도됩니다
• 기획은 한 번에 완성되는 문서가 아니라, 대화를 통해 만들어지는 과정입니다

"아직 기획이 안 됐는데 문의해도 되나요?" — 네, 됩니다. 그게 첫 번째 미팅의 목적입니다.

*아이디어 단계에서부터 상담이 가능합니다. 프로젝트 상담을 통해 편하게 문의해 주세요.*