클라이언트 가이드

"기획서 없이 시작된 프로젝트, 결과는 어땠을까?"

makeviibe 2025. 7. 15. 16:05

안녕하세요 makeviibe 입니다.

개발 프로젝트를 진행하다 보면 “기획서는 따로 없고, 대화하면서 조율하면 될 거 같아요”라는 제안을 종종 받습니다.

저희도 과거에는 그런 방식의 프로젝트를 경험한 적이 있습니다.

이번 글에서는 ‘기획 없이 개발을 시작한 프로젝트 vs. 명확한 기획이 준비된 프로젝트’의 차이를 실제 사례 중심으로 비교해보려 합니다.

실제 외주를 맡기거나 내부 프로젝트를 준비 중인 분들에게 도움이 되기를 바랍니다.


🧩 case 1 – 구두 전달만으로 진행한 프로젝트

  • 초기 상황
    • “앱 구조는 인스타그램처럼 가면 돼요”라는 한 줄 설명.
    • 기능 목록은 없고, 미팅에서 나오는 아이디어를 바탕으로 기능을 하나씩 구현.
  • 진행 도중 발생한 문제들
    • 개발자가 구현한 기능이 클라이언트 기대와 다름 → 수정 반복
    • 디자인/기능 기준이 없어서 QA 과정에서 서로 기준 불일치
    • 어느 시점부터는 “이건 처음 말했던 거잖아요” vs “그 얘기는 없었는데요?” 상황 반복
    • 출시 일정이 계속 미뤄짐
  • 결과
    • 구현된 기능은 많지만 사용자 흐름이 매끄럽지 않음
    • 클라이언트와 개발자 모두 피로감↑
    • 결국 일부 기능은 출시 후 비활성화됨

✅ case 2 – 명확한 기획서를 기반으로 한 프로젝트

  • 초기 상황
    • 기획 문서에 화면별 구성, 기능 흐름, 예외 상황까지 정리되어 있었고, 이를 바탕으로 개발 범위 확정 후 진행.
  • 진행 도중 강점
    • 화면정의서/기능정의서 기반으로 개발자와 디자이너가 동일한 기준으로 작업
    • 미리 정의된 API 스펙 기준으로 백엔드/프론트 동시 진행 가능
    • QA 시에도 체크리스트 기반 검수 진행 → 반복 피드백 최소화
    • 클라이언트도 기능 범위 내에서 예상 결과를 사전에 인지
  • 결과
    • 약속한 일정 내 1차 완성
    • 배포 후에도 유지보수가 수월함
    • 운영 과정에서도 새로운 기능 추가 시 명확한 기준 활용 가능

💡 makeviibe 팀의 결론

기획서는 단순히 개발자를 위한 문서가 아닙니다.

오히려 클라이언트와 개발자가 서로 기대하는 결과를 맞추기 위한 가장 강력한 도구입니다.

특히 외주 프로젝트에서는 “내가 생각하는 당연한 것”이 상대방에게는 전혀 다르게 전달될 수 있습니다.

그 간극을 줄이기 위해선 명확한 화면 흐름, 기능 정의, 예외 처리를 문서로 정리해두는 것이 필수입니다.

makeviibe 팀은 앞으로도 작은 프로젝트일수록 더 구조적으로 접근하려고 합니다.

좋은 기획은 좋은 개발을 만들고, 좋은 결과로 이어지기 때문입니다.