개발자가 좋아하는 기획서 쓰는 법

고은연·2022년 5월 20일

기술 이야기

목록 보기

6/6

1. 서설

이 글은 생각나는대로 계속 업데이트합니다. 현재 최종 버전은 2023.06.08. 입니다.

이 글은 제가 좋아하는 타입의 기획서를 나열한 것입니다. 개인 취향일 수도 있으므로 가볍게 읽으셔도 됩니다.

개발은 뭐라고 하는지 하나도 모르겠고 디자인은 재능이 없는 것 같으니 그나마 (조별발표때 써 봤던) 파워포인트로 문서나 만드는 기획자를 해 볼까? 라고 생각하시는 분들이 만약 있다면, 이 글을 읽고 나면 "차라리 개발이나 디자인을 배워야겠어" 라고 생각하시게 될 겁니다.
그만큼 기획 업무는 전문적이고 골치아프며 어렵습니다.

이 글은 파워포인트의 파워 목업을 다루는 법.. 같은 도구를 다루는 방법에 대해서는 전혀 다루지 않습니다. ~~저도 사용할 줄 몰라요~~

2. 개념론

2.1. 미사어구를 사용하지 마세요.

"엘레강스하고 가독성 좋게" 라는 이야기는 디자이너에게 해 주세요. (~~디자이너가 이 문구를 싫어합니다.~~)
대부분의 개발자는 이런 문구를 보면 "뭘 어쩌라는 거지" 라고 생각할 겁니다.
대신 #fff로 색을 지정해 주세요. 폰트는 나눔고딕입니다. 라고 하면 바로 오케이입니다.

2.2. 디자인을 보고 짐작하게 하지 마세요.

명확하게 써 주세요.
기획하시는 분은 (본인이 생각하신 것을 문서로 옮긴 것이므로) 당연하다고 생각하는 부분들도 가능하면 자세하게 적어주세요.
우리 모두는 경험도 다르고, 생각하는 방식도 다릅니다. 이건 공감의 문제도 아니고, 상식의 문제도 아닙니다. 기획서는 "의사소통을 위한 문서" 이므로 서로간 의도의 곡해가 없도록 작성하는 것이 몹시 중요합니다.

개발자는 모호한 것을 점쟁이처럼 알아맞춘 다음 생각하지 못한 부분까지 커버해줄 수 있는 존재가 아닙니다. ~~그걸 할 줄 알면 여기서 타자나 치고 있을 게 아니라 점집을 차려서...~~ 정의된 사양을 보고 그걸 구현해내는 사람이죠.

2.3. 기획서는 꿈과 희망을 담는 pr 문서가 아니라 설계서입니다.

아주 극소수의 기획자분들에게 보이는 현상입니다.

기획 문서를 가지고 왔는데 세상의 모든 좋은 기능은 다 붙어있네요. 마치 [페이스북 + 인스타그램 + 카카오톡 + 밴드 + 라인 + 싸이월드(음?)] 같습니다.

개발자는 이런 문서를 보는 순간 "엄청 복잡하네. 이걸 기술적으로 구현 가능하며 일정 내에 소화가 가능할까?" 라는 생각도 할 겁니다.

비슷한 내용으로 "xx와 똑같이요." 라고 적혀있는 문서도 있습니다. 데드 카피 제품을 만듬으로써 의욕이 떨어지는 것은 두번째 문제고.. 도대체 "xx와 어떤 부분을 똑같이?" 라는 생각부터 들겁니다.

2.4. 화면 정의서와 기능 정의서는 다른거에요.

에이전시 출신의 기획자 분들에게 가끔 보이는 현상인데.. 웹 에이전시는 디자인 위주의 사이트를 만드는 곳이기 때문에 디자인에 대해서는 엄청 자세하게 적혀있지만, 기능에 대해서는 "게시판 목록" 이라고 달랑 5글자만 적혀있는 경우를 봤어요.
"게시판 목록"은 기능이 아니에요. 기능은 무엇이 보여지고 어떻게 동작할 것인가에 대한 문제이지 어떻게 보여지느냐의 문제가 아닙니다.

따라서 "게시판 목록" 이라는 표현 대신 아래처럼 작성해 주시는 것을 권장합니다.

게시판 목록은 제목, 내용, 작성일, 작성자 닉네임으로 구성됩니다.
제목을 클릭하면 게시판 상세 페이지로 이동합니다. (ppt p32 참조)
내용은 100글자가 넘어갈 경우 100글자로 한정합니다.
작성일은 2023-06-08 형식으로 표현합니다. 다만 당일일 경우 "오늘" 이라고 표시하고, 오늘을 기준으로 7일 이내에는 n일 전 (어제였을 경우 1일전) 으로 표기합니다. 만약 7일-14일 이내라면 "일주일 전" 으로 표기해 주세요. 그보다 오래될 경우 2023-06-08 형식으로 표기합니다.
닉네임은 전체를 표기합니다. 닉네임 클릭시 닉네임에 해당하는 작성자의 프로필 페이지로 이동합니다.

2.5. 개발을 할 필요는 없지만, 배워두는 게 정신건강에 좋습니다.

이 부분에 대해서는 많은 기획자 분들이 통감하시고, 따로 시간과 돈을 들여서 수업을 듣는 것을 많이 봤습니다.

다만 .. 백엔드는 어려워서 그런지 몰라도 (보이는 것은 코드 뿐..) 프론트엔드를 많이 배우시는데요.
우리가 생각하는 "기능"은 대부분 백엔드에서 구현합니다. 프론트엔드는 백엔드의 데이터를 받아서 보여지는 부분을 담당하는거죠.
그래서 어려워도 데이터베이스 설계나, 최소한의 서버 사이드 어플리케이션들이 어떻게 돌아가는지에 대해서는 기초 서적이라도 몇 권 읽어 두시는 것이 나중에 "잘하는 기획자"라는 호칭으로 돌아옵니다.

변화를 싫어하시는 기획자 분들 중에서는 개발을 배우면 본인들의 창의성이 저하된다고 말씀하시는 분들도 있으세요.
개발을 배우라는 것은 "본인의 한계를 제한"하라는 뜻이 아니라, 어떤 것이 가능한지 가늠하고, 커뮤니케이션을 원활하게 하라는 뜻입니다.
개발을 배우면 창의성이 저하된다고 생각한다면, 그냥 기획자를 그만두는 것이 낫다고 생각합니다. 본인이 논리적인 사고가 안되므로 "나는 꿈을 꿀테니 니가 현실로 만들어라"라는 마인드를 증명하는 것 같은 것입니다.

2.6. 용어를 명쾌하게 정의해 주세요.

개발자 용어로 개념을 구분해서 서로 동작이 달라야 하는 것들을 "엔티티(entity)"라고 합니다. 예를 들어서 "게시판"을 구현한다고 하면, "게시글", "첨부파일", "작성자" 등이 엔티티가 됩니다.

이를 구분하는 이유는, 실제로 각 엔티티별로 할 수 있는 일이 다르고, 개발을 할 때는 엔티티별로 쪼개서 속성과 할 수 있는 일을 구현하기 때문입니다.

반면 이런 것은 지양하셔야 합니다.

같은 개념에 대해서 서로 다른 용어를 쓰는 일 (기획서 37페이지에서는 "작성자", 45페이지에서는 "글쓴이" 라고 쓴다거나)
다른 개념에 대해서 서로 같은 용어를 쓰는 일 (로그인한 "회원"은 게시판에 글을 쓸 수 있음. 관리자 "회원"은 다른 사람의 게시글을 삭제할 수 있음).

이는 "사람"은 "문맥"에 따라서 유추라는 것이 가능하지만, 컴퓨터는 그런 것이 불가능하기 때문입니다. 개발자들은 "일을 할 때는 컴퓨터에 가까운 모드로 전환" 되므로, 문맥에 따라 같은 용어가 다른 동작을 한다거나, 다른 용어가 같은 동작을 한다거나.. 하는 식으로 코드가 작성되면 나중에는 본인도 못알아보는 이상한 코드가 되어버리기 때문에 본능적으로 싫어합니다.

기획자의 롤을 벗어나서 PO(Product Owner) 레벨이 되면 용어의 혼선을 막기 위해서 "용어사전" 이라는 것을 만드는 것도 좋은 방법입니다.

2.7. 용어(엔티티)를 개발자가 이해하는 법

개발자는 기획서를 읽고, 엔티티를 추출해내고, 이를 코드로 옮깁니다.

엔티티는 속성, 이벤트, 상태 전이로 구분됩니다.

속성 : 엔티티를 구성하는 값들. ex. )게시글의 제목, 본문, 댓글 .. 등
이벤트 : 동작. ex.) 게시글 작성 후 "저장하기" 버튼을 눌렀을 때

이벤트는 a.)발동 조건과 그에 따른 b.)이펙트가 있습니다. 예를 들면 a.)게시글 작성 후 "저장하기" 버튼을 누르면 b.) 데이터 저장 => 방금 쓴 글 상세로 이동 .. 이런 식입니다.

상태 전이는 이벤트가 일어났을 경우 상태가 변화하는가..에 대한 것입니다. 예를 들면 "게시글을 수정해서 비공개로 변경되었을 경우 게시글이 다른 사람에게 보여지지 않는다." 같은 걸 말합니다.
상태 전이가 중요한 이유는 엔티티의 상태에 따라서 엔티티가 하는 동작이 달라질 수 있기 때문입니다. 예컨데 "운영 정책 위반으로 블라인드 처리된 글" 이 수정이 가능하다면 "블라인드 처리는 어떻게 되어야 하는가.." 라는 문제가 생기기 때문에 개별 엔티티의 상태에 따라 동작이 어떻게 달라지고, 다른 엔티티에 어떤 영향을 미치는가를 늘 고민해야 합니다.

만약 기획자 분이 엔티티 정의를 기획서에 넣어주시면, 개발자는곧바로 보고 실제 코드로 옮길 수 있으므로 서로간의 커뮤니케이션 미스가 적어집니다.
~~하지만 한번도 이런 걸 정의해주는 기획서는 받아본 적이 없습니다...~~

2.8. 기능 정의를 먼저 하세요.

서비스 개발은 어떤 기능이 있는지 정의가 먼저입니다. 코드가 먼저도 아니고 디자인이 먼저도 아니에요. 이를 기능 명세서라고 부릅니다.

기능 명세서는 가능하면 최대한 자세히 작성하세요. 당연하다는 함정에 빠지지 마세요. 같은 디자인이라도 사용자 경험은 전혀 다를 수 있어요.
개인적으로 추천하는 방법은 "앞에 7살짜리가 있다고 생각하고 그 아이가 이해할 수 있는 수준" 으로 작성하는 겁니다.
이 과정이 귀찮고 번거롭다면 본인이 할 일을 남에게 미루는 거에요.

2.9. 개발자에게 필요한 기획의 3대 요소

무선 청소기를 예로 들어보겠습니다.

디자인을 중시 여기는 기획자는 "청소기가 어떻게 생겼는지"에 대해서 아주 자세히 이야기합니다. 색은 흰색이어야 하고, 그립감이 좋아야 하며, 가벼워야 한다고 적어놓습니다.
기능을 중요하게 여기는 기획자는 "청소기가 어떻게 동작해야 하는지"에 대해서 이야기합니다. 전원 버튼을 누르면 동작해야 하고, 파워 모드를 누르면 더 강하게 흡입이 가능해야 하죠.
스펙을 먼저 보는 기획자는 "청소기가 어떤 스펙을 가지고 있는지"에 집중합니다. 무선 청소기는 모터, 배터리, 충전기, 그리고 껍데기로 이루어지며, 모터는 16v, 배터리는 36A .. 이런 식입니다.

셋 다 중요합니다.

"디자인"은 디자이너 분의 영역이므로 이 글에서는 패스합니다만, 외관이 구매를 결정하는 요인 중 하나이므로 대단히 중요합니다.
"기능"은 엔티티 부분에서 언급한 "이벤트"에 해당합니다.
"스펙"은 엔티티 부분에서 언급한 "속성" 에 해당합니다.

개발자는 "기능"과 "스펙" 이 있어야 동작하는 제품을 만들 수 있기 때문에 세개 다 필요합니다.

3. 실전 도전

이제부터는 실전 기획서에서 꼭 필요한 항목을 예시로 살펴보겠습니다.

3.1. 목록

목록을 정의할 때는 최소한 아래의 항목들이 필요합니다.

3.1.1. 항목의 구분

글 목록 : 개별 글을 모아놓은 목록
개별 글 : 글 목록의 일부로써 게시글을 요약한 글 하나.
글쓰기 버튼 : 글쓰기 화면으로 전환할 수 있는 버튼

3.1.2. 글 목록

3.1.2.1. 속성

개별 글
정렬 : 최신순. ~~오래된 순? 조회수가 많은 순?~~
조건 : 삭제된 글은 보여지지 않는다. 탈퇴한 회원의 글은 보여진다.

3.1.2.2. 이벤트

빈 페이지 처리 : 내용이 하나도 없을 경우 페이지가 없다고 보여진다. or 뒤로 보낸다.
페이지 네비게이션 처리. : 더보기로 할 것인가 페이지가 변할 것인가. 만약 >> 버튼을 누르면 한번에 몇 페이지를 뛰어넘는가. (1페이지에서 눌렀다면 6페이지로 이동, 2페이지에서 눌렀다면 7페이지로.)