Chapter 3. 기획서는 있는데 왜 계속 오해가 생길까

“기획서는 다 드렸는데요?”
이 말, 정말 많이 듣는다.

나는 외주 개발 프로젝트를 시작할 때 항상 이렇게 묻는다.
“기획서는 어느 수준까지 준비돼 있나요?”
그러면 되돌아오는 답은 대부분 자신 있다.
“다 정리해놨습니다. 파워포인트로 10장 넘게 돼 있어요.”
“피그마도 거의 다 완성됐고요.”

그리고 그 기획서를 받아보면,
나는 10분 만에 이 프로젝트가 어디에서 어긋날지를 예측할 수 있다.

왜냐하면 그 기획서는 대부분 의도를 설명하지, 행동을 정의하지 않기 때문이다.
기획서가 있음에도 계속 오해가 생기는 이유는 간단하다.
기획자가 쓰는 언어와 개발자가 해석하는 언어는 다르기 때문이다.

---

기획자는 “사용자가 쉽게 로그인할 수 있게 한다”고 쓴다.
그 말 자체는 명확해 보인다.
하지만 개발자의 입장에서 그건 질문만 던진 문장일 뿐, 명령이 아니다.

• ‘쉽게’는 어떤 로그인 방식인가?
• 카카오/네이버/애플 중 뭐를 쓰는가?
• SNS 연동 후 이메일은 어떻게 연결하는가?
• 이미 가입된 이메일이면 중복 가입은 허용하는가?

이건 기획자가 빠뜨린 게 아니다.
기획서라는 도구가 원래 그렇게 불완전한 것이다.
그래서 개발자는 기획서를 읽고서도 끊임없이 묻는다.
“이건 어떤 의미인가요?”, “여기선 어떤 동작을 해야 하나요?”,
그리고 기획자는 속으로 생각한다.
“그건 너무 당연한 거 아닌가요?”

아니다.
그건 당신에겐 당연하지만, 코드로 만드는 입장에선 추측일 뿐이다.

---

기획자들은 자주 “피그마 보면 다 알 수 있다”고 말한다.
맞는 말이다. 디자인 흐름은 실제 흐름을 시각화해준다.
하지만 피그마는 보이는 것만 보여줄 뿐, 보이지 않는 흐름은 말해주지 않는다.

피그마가 말해주지 않는 것들개발자가 물어봐야 할 것들

버튼이 눌렸을 때 로직	API 연동 여부, 오류 처리 방식
조건 분기	로그인 상태, 사용자 유형 구분
비정상 동작 시 처리	실패 응답, 빈 화면 대응
보안 및 인증 흐름	토큰 관리, 세션 유지 방식

 

실제로 기획서를 받아보고 나서
“이건 기획에 없던 건데요” 라고 말하는 개발자와
**“그건 당연히 들어가는 거잖아요”**라고 말하는 기획자의 대화는
같은 한국어로 말하고 있는 것처럼 보여도,
전혀 다른 구조에서 나온 결과다.

---

개발자가 원하는 건 ‘아이디어’가 아니다.
해석할 수 있는 단위로 쪼개진 실행 지시서다.

기획자가 “이런 흐름이면 좋겠어요”라고 말할 때,
개발자는 “이런 흐름이니까 어떤 데이터를 받아서 어떤 방식으로 보여줘야겠다”고 생각해야 한다.
그런데 중간이 비어 있으면
개발자는 스스로 결정을 내려야 한다.
그러면?
오해가 발생한다.

그리고 그 오해는 제품 후반에
**“이건 왜 이렇게 됐어요?”**라는 말로 돌아온다.
그때 개발자는 “그때는 그렇게밖에 판단할 수 없었다”고 말하고,
기획자는 “그걸 왜 말 안 했어요?”라고 반응한다.

---

기획서를 쓸 때 가장 위험한 말은
**“그건 나중에 정리할게요”**다.

왜냐하면 실제로 정리되지 않는 경우가 많고,
그 공백은 대부분 개발 단계에서 충돌로 이어지기 때문이다.
초기 기획서는 대개 ‘의도를 담은 설계서’지만,
개발자가 원하는 건 ‘예외 처리가 포함된 사양서’다.
이 둘의 간극을 줄이지 않으면,
기획서가 있어도 오해는 반복된다.

---

기획서를 정리할 때, 개발자 입장에서 꼭 필요한 최소 기준은 이렇다.

개발자 입장에서 필요한 기획 기준체크

각 화면의 ‘기능’이 아닌 ‘행동’이 정의돼 있는가	✅ / ❌
조건 분기 및 예외 상황이 명시돼 있는가	✅ / ❌
화면 간 이동 조건이 논리적으로 연결돼 있는가	✅ / ❌
UI 구성 외에 API, DB 연동 흐름도 정리되어 있는가	✅ / ❌
피드백, 보완 요청을 어디까지 허용할지 범위가 명확한가	✅ / ❌

 

이 기준이 안 되어 있는 기획서는
기획서가 아니라 **‘제안서 초안’**에 가깝다.
그리고 개발자는 그 초안 위에 진짜 시스템을 만들어야 하니,
늘 벼랑 끝에서 선택을 하게 된다.
“일단 구현하고 나중에 맞추자”
→ 그리고 그게 누적된 오해가 되어 돌아온다.

---

기획은 의도가 아니라 예측 가능한 동작의 조합이다.
그리고 그 동작을 문서화할 수 있을 때 비로소 기획서가 된다.
그게 없다면
기획서는 있어도 계속 오해가 생긴다.

개발자는 당신의 머릿속을 못 본다.
그러니 기획서는 더 설명해야 하고, 더 따져야 하고, 더 쪼개야 한다.
오해는 기획자의 책임이 아니라, 구조의 문제다.
그리고 그 구조는 개발자만 만들 수 없다.