개발자를 화나게 하는 기획서를 만들지 않으려면

개발자를 화나게 하는 기획서를 만들지 않으려면

제가 주니어 시절 있었던 일을 말씀드리죠. 제가 야심 차게 준비한 기획서 리뷰 시간. 저는 한껏 긴장한 채 제가 밤새워 그린 화면 설계서(와이어프레임)를 제 사수와 팀장님에게 보여주고 있었죠. "사용자는 이 버튼을 누르면, 이 화면으로 이동해서..." 스스로 생각하기에도 물 흐르듯 완벽한 플로우라고 생각했어요. 그런데 한참을 설명하고 있는데, 팀장님이 미간을 살짝 좁히시더니 저를 멈춰세우고 물으셨어요.

"M님, 설명은 잘 들었습니다. 그런데 방금 보여주신 그 '결제 완료' 팝업 말인데요. 그건 어떤 화면 위에서 뜨는 건가요? 상품 상세 페이지? 아니면 장바구니 페이지? 그리고 그 팝업의 확인 버튼을 닫으면 이전 화면으로 돌아가나요, 아니면 주문 내역 페이지로 가나요?"

순간 머리가 띵 하고 하얘지더라고요. 제 머릿속에서는 너무나 당연한 흐름이었기에, IA(정보구조도)에는 그냥 <결제 완료 팝업>이라는 네모 상자 하나만 툭 던져놨거든요. 제 대답이 "어... 그건 아마..."라며 우물쭈물 길어지자, 기다렸다는 듯이 질문이 터져 나오기 시작했습니다.

"이 화면 이름은 왜 기획서 앞쪽에선 '내 정보'인데, 뒤쪽 와이어프레임에선 '마이페이지'예요? 같은 화면 맞죠?"

"검색 결과가 하나도 없을 땐 이 목록이 어떻게 보이나요? 그냥 빈 화면인가요?"

분명 화면은 빠짐없이 다 그렸다고 생각했는데, 그 화면들이 서로 어떻게 연결되고, 어떤 규칙으로 움직이며, 어떤 예외 상황을 갖는지에 대한 설계도가 완전히 엉망이었던 거죠. 그날의 회의는 결국 기획서를 처음부터 다시 정리하라는 지시와 팀장님과 사수님의 격려(얘가 이러고 있는 동안 너는 뭘 했냐는 팀장님의 제 사수님을 향한 호통과 도대체 뭘 믿고 이따위로 일하는 거냐는 사수의 질책)가 이어졌고, 저는 제자리에 돌아와 한숨을 쉬며 생각했습니다. '나는 멍청이야. 왜 이런 것들을 생각하지 못했을까?'

많은 주니어 기획자분들이 저와 비슷한 경험을 하셨을 거예요. IA를 그저 메뉴 목록이나 사이트맵 정도로만 생각하다가, 개발과 디자인이 시작되는 순간 수많은 커뮤니케이션 비용을 폭탄처럼 맞는 경우 말이에요. 오늘은 잘못된 IA가 어떻게 팀 전체를 야근의 수렁으로 몰아넣는지, 그리고 어떻게 하면 모두가 행복해지는 '소통을 위한 IA'를 만들 수 있는지에 대한 아주 구체적이고 실질적인 팁을 공유해 보려고 합니다.

1. "마이페이지? 내 정보? 프로필?" 사소한 이름짓기가 지옥을 만든다

가장 흔하게, 그리고 가장 쉽게 하는 실수가 바로 이름을 아무렇게나 짓는 거예요. 기획할 때의 기분에 따라, 혹은 그냥 직관적으로 떠오른 생각에 따라 어떤 화면에서는 마이페이지라고 썼다가, 다른 기능 명세서에는 내 정보라고 쓰는 식이죠. “다들 이해하겠지” 싶은 마음이었을 수도 있고, 아니면 그저 생각을 못하는 바람에 놓쳐버린 것일 수도 있고요.

하지만 개발자와 디자이너는 기획자의 마음을 읽는 독심술사가 아니에요. 그들에게 '마이페이지'와 '내 정보'는 데이터 구조나 컴포넌트가 완전히 다른 별개의 화면일 수 있거든요. 아래는 가상의 상황이지만, 아주 자주 일어나는 일이기도 합니다.

디자이너: "M님, 요청하신 '내 정보 수정' 화면 디자인 시안 전달드립니다. 수정 완료 버튼 누르면 말씀하신 '프로필' 화면으로 이동하게끔 플로우 연결해 뒀어요!"

저 (PM): "아, 고생하셨어요! 그런데 완료 후에는 '프로필'이 아니라 '마이페이지'로 보내주셔야 해요."

디자이너: "네? 아니... 네, 알겠습니다. 그럼 내비게이션 구조를 다시 수정해서 드릴게요."

(잠시 후, 개발자가 슬랙으로 메시지를 보낸다)

개발자: "M님, 지금 디자인 시안 보니까 완료 후에 '마이페이지'로 가던데, 제가 전달받은 기획서에는 '내 정보' 화면으로 이동한다고 되어 있어서 API 연동을 그렇게 해뒀거든요. '마이페이지', '내 정보', '프로필'이 다 다른 화면 아니었어요? 어떤 게 맞는 건가요?"

이 사소한 불일치 하나 때문에 발생한 비용을 계산해 볼까요? 디자이너는 이미 짜놓은 프로토타입의 연결 플로우를 다시 수정해야 했고, 개발자는 잘 짜놓은 코드의 라우팅(routing) 부분을 다시 손봐야 했습니다. 이틀이면 끝날 줄 알았던 작업은 꼬박 나흘이 걸렸고, 팀원들 사이에는 "기획이 또 난리났네"라는 미묘한 불신의 기류가 흘렀죠.

이것은 기획서의 품질을 명확하게 깎아먹는 중요한 문제예요. 이러한 문제를 방지하기 위해 반드시 해야할 일은, 프로젝트 초반에 '용어 정의서'를 만드는 거예요. 거창할 필요도 없습니다. 그냥 구글 시트나 노션에 표 하나 만들어서 팀원들과 함께 우리 프로젝트에 사용되는 모든 용어를 자세히 정의해놓는 거죠.

이렇게 기준만 한 번 정해두면, 기획서는 물론이고 디자인 가이드의 레이어 이름, 개발자의 변수명까지 모두가 같은 언어를 사용하게 됩니다. "저번에 그거 있잖아요..." 같은 모호한 대화가 사라지고, 마치 잘 조율된 오케스트라처럼 정확한 소통이 가능해지는 거죠.

2. "저기... 세 번째 화면에서 왼쪽 두 번째 버튼요"를 막아주는 화면 ID의 마법

프로젝트 규모가 커지면 화면 개수는 수십, 수백 개로 늘어나죠. 이럴 때 화면을 말로 설명하는 건 정말 끔찍한 일이 됩니다. "상품 목록에서 필터 아이콘 누르면 나오는 팝업창의 두 번째 탭 화면 있잖아요..." 이렇게 설명하는 순간, 듣는 사람의 머릿속은 이미 미궁에 빠져버려요. 마치 주소 없이 "서울에서 세 번째로 큰 사거리에서 좌회전하면 나오는 빨간 벽돌집"이라고 설명하는 것과 같달까요?

이럴 때 필요한 게 바로 '화면 ID'라는 명확한 주소 체계입니다. 규칙은 팀마다 정하기 나름이지만, 서비스의 구조에 따라 논리적으로 번호와 약어를 부여하는 것이 일반적입니다.

• 대분류(Depth 1): HOME, PD(Product), MY(My Page), CS(Customer Service) 

• 중분류(Depth 2): 목록(01), 상세(02), 등록(03) 

• 소분류(Depth 3): 탭(-01), 팝업(-PO-01), 바텀시트(-BS-01)

이 규칙에 따라 주소를 부여하면 이렇게 됩니다.

• PD-01: 상품 목록 화면

• PD-02: 상품 상세 화면

• PD-02-01: 상품 상세 화면 내 '리뷰' 탭

• PD-02-01-PO-01: 상품 상세 화면 내 '리뷰' 탭에서 '리뷰 작성하기' 버튼을 눌렀을 때 뜨는 팝업

이렇게 IA 단계에서부터 모든 화면과 주요 컴포넌트(팝업, 바텀시트 등)에 고유 ID를 부여해두면 협업의 퀄리티가 극적으로 올라갑니다. 지라(Jira)나 슬랙에서 오가는 대화가 어떻게 바뀌는지 한번 볼까요?

Before: "개발자님, 상품 상세 페이지에서 리뷰 쓰는 팝업 있잖아요. 거기서 별점 안 누르고 등록하면 앱이 죽는 버그가 있어요."

After: "개발자님, [PD-02-01-PO-01] 화면에서 별점 미입력 시 Null 값으로 인한 크래시가 발생합니다. JIRA-247 티켓 확인 부탁드려요."

후자의 방식은 누가 봐도 명확하고, 히스토리 추적도 용이합니다. 더 이상 "어떤 화면 말씀이시죠?"라는 질문에 스크린샷을 찍어 보내고 부연 설명을 하느라 30분씩 시간을 낭비할 필요가 없어지는 겁니다

3. "데이터가 없을 땐 어떻게 보이나요?" 개발자의 단골 질문에 대비하는 법

기획자는 보통 모든 것이 완벽하게 채워진 '해피 케이스(Happy Case)'를 상상하며 화면을 그려요. 상품 목록은 멋진 상품들로 가득 차 있고, 내 쿠폰함에는 사용 가능한 쿠폰들이 즐비하죠. 하지만 개발자는 그 반대편에 있는, 온갖 예외 상황으로 가득한 '엣지 케이스(Edge Case)'를 먹고사는 사람들이에요. 그들은 기획서를 보자마자 이렇게 물어볼 겁니다.

• "이 목록에 데이터가 하나도 없으면 어떻게 보여요? (Empty State)" 

• "데이터 불러오는 1~2초 동안에는 화면이 어떻게 보여요? (Loading State)" 

• "갑자기 인터넷이 끊기거나 서버에서 에러가 나면 사용자에게 뭐라고 보여주죠? (Error State)" 

• "로그인 안 한 사람은 이 화면에 들어오면 어떻게 되나요? (Authentication State)"

이런 상태 값에 대한 정의가 빠져있으면, 개발자는 자기 마음대로 처리하거나(최악의 경우), 그때마다 다시 PM에게 물어봐야 합니다. 이건 기획의 빈틈이자, 예측 가능한 커뮤니케이션 비용의 낭비입니다. 훌륭한 IA는 단순히 화면의 목록이 아니라, '화면이 가질 수 있는 모든 상태 값'을 정의한 입체적인 문서여야 해요. IA를 작성할 때 각 화면 아래에 이런 식으로 상태를 함께 정리해 보세요.

• PD-01 (상품 목록 화면) 

- 기본 상태: 상품 목록이 2xN 그리드 형태로 노출됨

- 로딩 상태: 그리드 형태의 스켈레톤 UI가 1.5초간 노출됨 

- 데이터 없음 상태 (검색 결과가 없을 경우): "아쉽지만, 검색 결과가 없어요." 라는 메시지와 함께 '인기 검색어' 목록을 하단에 노출함. 

- 에러 상태: "네트워크에 문제가 생겨 상품을 불러오지 못했습니다." 메시지와 '다시 시도' 버튼을 노출함. 버튼 클릭 시 API 재호출. 

- 인증 상태 (비로그인 유저): 화면은 정상적으로 보이나, '찜하기' 버튼 클릭 시 "로그인이 필요한 기능입니다" 토스트 팝업 및 로그인 화면으로 이동.

어떤가요? 이렇게 미리 모든 경우의 수를 정의해두면, 개발자는 질문 없이도 훨씬 더 완성도 높은 화면을 만들 수 있습니다. 무엇보다 "와, 이 PM분 정말 꼼꼼하시네. 같이 일하기 편하다"라는 말을 듣게 되는 건 덤이고요.

마무리하며: 기획서는 '설명서'가 아닌 '소통의 도구'입니다

우리는 종종 기획서를 내가 만든 결과물을 남에게 설명하고 이해시키는 일방적인 문서라고 생각해요. 하지만 관점을 조금만 바꿔보면 어떨까요? 기획서는 설명서가 아니라, 디자이너, 개발자와 같은 언어로 대화하기 위한 최소한의 약속이자 공동의 목표를 향해 나아가기 위한 소통의 도구라고요.

그런 의미에서 IA는 단순히 메뉴를 나열한 평면적인 지도가 아니라, 우리 팀이 함께 지을 건물의 가장 중요한 '기초 설계도'입니다. 일관된 용어, 명확한 주소, 그리고 발생 가능한 모든 상황에 대한 정의가 담긴 IA는 수많은 회의와 불필요한 재작업을 극적으로 줄여주고, 팀원들이 서로를 신뢰하며 진짜 중요한 '제품의 가치'에 집중하게 만드는 가장 강력한 무기가 되어줄 겁니다.

Action Items for Junior Planners:

지금 바로 용어 정의서 만들기: 현재 진행 중인 프로젝트에서 가장 자주 혼용되거나, 사용은 되고 있지만 무슨 뜻인지 정확하게 알지 못하는 단어 10개를 뽑아 구글 시트에 정리해 보세요. 그리고 팀 슬랙 채널에 공유하며 "앞으로 우리 프로젝트의 공식 언어입니다! 다들 편하게 의견 주세요!"라고 제안해 보세요. 모두가 반길 겁니다.

내 기획서에 화면 ID 붙여보기: 가장 최근에 작성한 기획서를 열고, 사용자의 핵심 플로우(ex: 회원가입~로그인~메인화면)에 해당하는 화면들에만 ID를 붙여보세요. 그리고 다음 회의 때 그 ID를 사용해서 설명해 보세요. 팀원들의 눈빛이 달라지는 걸 느낄 수 있을 거예요.

경쟁 앱의 빈 화면 캡처하기: 지금 당장 휴대폰을 열고, 내가 자주 쓰는 앱 3개의 검색창에 아무도 검색하지 않을 것 같은 단어('롯데자이언츠2025우승확률')를 입력해 보세요. 그리고 검색 결과가 없을 때(Empty State) 어떤 화면을 보여주는지 캡처하고 분석해 보세요. '결과 없음' 메시지만 띄우는지, 아니면 다른 행동을 유도하는지 살펴보는 것만으로도 기획의 깊이가 달라집니다. 

manyfast.io