개발자가 선호하는 기획서
IA, 화면정의서, 기능정의서... 작성할게 너무많다
기획자가 협업하는 동료들에게 생각을 전달하는 여러가지 방법이 있다. 찾아가서 화이트보드에 그려가며 말로 설명할수도 있고, 이메일이나 메신저를 통해 소통할 수도 있다. 그런데 보통은 다양한 제목의 문서들, ‘화면기획서‘, ‘스토리보드‘, ’기능정의서’, ‘메뉴구조도‘등의 문서를 작성해서 전달하게 된다. 각 문서는 회사별로 각각의 형식이 있다. 불필요하게 작성해야하는 항목이 있을수도 있지만, 이 문서들은 함께 일하는데 필요한 대부분의 것들을 포함하는것을 목표로 작성된다.
같은 상황을 함께 겪어도 각자 다르게 이해하는 경우가 왕왕 있다. 상사의 지시사항을 듣고도 서로 이해가 달라 본인의 이해가 맞는지 크로스체크하는건 흔한 일이다. 원래 작성된 문서만으로 정확하게 내 생각을 전달하는 건 어려운 일이다. 그나마 여러 수단중에 가장 오해가 적고 많은 정보를 담을 수 있는게 문서를 통한 소통이다.
그런데 이게 참 어렵다. 어느 장단에 맞춰 써야할지 모르겠다. 최대한 자세하게 모든걸 담아도 읽지도 않고 물어보는 사람도 있고, 어떤 경우엔 읽어도 이해가 안간다며 내 문서에 지적을 하는 경우도 있다. 도대체 뭐가 문제일까? 내 문제이긴 한걸까?
기획서가 이해가 안되는 이유
모호한 표현과 불명확한 요구사항은 기획서 이해가 어려워지는 이유중 하나다. 예를들어 날씨를 보여주는 서비스를 상정해보자. 당신은 화면에 고객이 흥미로워할 만한 ‘추천’ 카드를 하나 보여주고 싶다고 가정해보자. 요즘은 일상적으로 사용하는 많은 서비스들에서 내가 좋아할만한 컨텐츠를 추천해주는것이 흔하다. 그래서 자연스럽게 기능정의서에, “고객이 바로 알면 좋을만한 날씨 컨텐츠 노출한다. ex)미세먼지 경고, 집중호우 예상”이라고 적을 수 있다. 적어놓고 보니 고객이 바로 알면 좋을만하다는 표현이 모호한 것 같아서 “기상특보가 있는경우 해당 특보 노출, 없는 경우 미세먼지가 많은날이나 짜증지수가 높은날 등 사용자 친화적인 컨텐츠 노출”이라고 바꿔보았다. 이정도면 충분히 구체적이지 라고 생각했다. 그렇지만 이 문구는 여전히 너무 모호하다. 구체화를 어디까지 할 수있는지 제한은 없지만, 개발에 필요한 만큼만 어느정도 구체화 했을때 아래와 같이 작성할 수 있다.
“고객의 일상 생활에 직접적인 영향을 미치는 날씨 정보를 실시간으로 ‘추천카드’ 형식으로 제공한다. 주요 기준은 기상청 발표 및 환경부 데이터를 기반으로 한 미세먼지 경보, 집중호우 예상, 폭염 경보, 한파 주의보 등이다. 날씨 정보는 앱 메인 화면 최상단에 카드형태로 노출하며, 긴급 상황(예: 미세먼지 초미세먼지 '나쁨' 이상, 집중호우 예상) 시 푸시 알림을 발송한다. 긴급 상황에 해당되는 기상특보의 종류는 표 참조. 배너 클릭 시 해당 특보에 대한 상세 정보 페이지로 이동한다. 추천카드 정보는 텍스트와 아이콘으로 제공하며, 긴급 상황 시 빨간색으로 강조 표시한다. 상세 정보 페이지에서는 그래프와 지도 형태로 추가 정보를 제공한다. 날씨 정보는 기상청 발표 후 10분 이내로 업데이트한다."
물론 위 예시도 여전히 모호한 점이 남아있고 실제 개발을 위해서는 질의응답이 오고갈테지만 개발하는 입장에서 우선 궁금한 점은 많이 커버할 수 있다. 이와 비슷한 형태로 자주 등장하는 모호한 표현들이 있다. ‘~처럼’, ‘~같이’ 해주세요 라는 표현은 개발자를 혼란스럽게 만든다. 예를 들어 “카카오톡처럼 채팅 기능을 구현해주세요. 스냅챗처럼 일시적인 메시지 기능같은것도 있으면 좋겠어요.” 라는 요구사항이 있다면, 개발자는 구체적으로 어떤 기능을 구현해야 할지 판단하기 어렵다. 메시지 전송? 읽음 확인? 이모티콘? 답장/전달? 채팅방 나가기? 어디까지가 ‘카카오톡처럼’의 범위이고 어디까지가 ‘스냅챗처럼’에 해당하지?
“편리하게”, “직관적으로” 같은 주관적인 표현도 문제다. 무엇이 편리하고 직관적인지는 사람마다 다르게 느낄 수 있다. 개발자는 이런 모호한 표현을 보면 “구체적으로 어떻게 구현하기를 원하시나요?“라고 다시 물어볼 수밖에 없다.
기술적 제약사항을 고려하지 않은 요구사항들도 있다. ‘실시간으로 처리해주세요’라는 요구사항이 있다고 가정해보자. 실제로 얼마나 빨라야 하는지(1초 이내? 0.1초 이내?), 동시 접속자 수는 얼마나 예상하는지(100명? 1000명?), 처리해야 할 데이터의 양은 얼마나 되는지 등 구체적인 수치가 필요하다. 또한 레거시 시스템과의 호환성이나 현재 개발 환경의 제약사항도 반드시 고려해야 한다.
예외 케이스 정의가 부족한것은 흔한 케이스다. 예를 들어 ‘회원가입’ 기능 하나만 보더라도 수많은 예외 상황이 존재한다. 미성년자는 어떻게 처리할 것인지(법정대리인 동의 필요), 중복 가입은 어떻게 방지할 것인지(이메일? 휴대폰 번호? SNS 계정?), 본인인증은 어떤 방식으로 할 것인지(휴대폰 인증? 이메일 인증? 신분증 인증?), 탈퇴 후 재가입은 언제부터 가능하게 할 것인지 등 세세한 정의가 필요하다. 이런 예외 케이스들이 명확히 정의되지 않으면, 개발 과정에서 계속해서 추가 질문이 발생하고 일정 지연으로 이어진다.
이 외에도 외부 요소들에 대한 누락도 발생할 수 있다. 외부 시스템과의 연동이 필요한 경우, 해당 시스템의 API 스펙이나 연동 가이드가 없다면 개발이 불가능하다. “소셜 로그인 연동”이라고만 써있고 구체적인 플랫폼이나 필요한 정보가 명시되지 않은 경우가 많다. 연동을 위한 계약이나 그쪽의 준비는 되어있는지, 연동을 위한 암호화 키와 계정등은 준비되어 있는지 상태에 대한 정보가 API 스펙과 함께 전달되어야 하는데, 거기까지 신경써주는 기획문서는 드물다.
화면정의와 기능정의는 다르다.
단어가 다르듯 두 기획서의 영역은 다르고 상호 보완적이다. 서비스의 화면 구성과 디자인을 설명하는 문서가 전자에 해당하고 그 안에서 어떻게 동작하고 기능하는지를 설명하는 문서가 후자다. 나는 기억한다, 초등학교때 그림을 제일 처음 배울때 전체 그림을 어떻게 그릴지 먼저 생각하고, 여러 선들로 그림의 중요 요소들을 채워나간다. 건축 과정도 비슷하다 전체 조감을 생각하고 이를 어떻게 구현할지 상세하게 채워간다. 화면정의와 기능정의를 나누지 않고 한꺼번에 스토리보드에 작성하기도 하지만 이 경우 설계서가 되기보다 이용자들을 위한 ‘사용설명서‘같은 문서가 되는 경우가 많다.
선술했듯 우리가 작성하는 문서는 내가 뜻하는 바를 이뤄내기 위한 도구로서 선택된 것이다. 개발자는 물론 QA와 디자이너까지 모든 동료들에게 내 생각을 최대한 차이없이 전달하기 위함이다. 그 과정에서 화면정의는 전체 요소를 설명하는 조감도나 낮은 축척의 지도라고 생각한다. 기능 정의서는 각 층이나 방마다 있는 도면에 해당한다. 개발자는 이 도면을가지고 실제로 구현하는 목수나 인테리어업자에 해당한다.
상황에따라 두 문서의 구분없이 한가지만 작성하는 경우도 있을 수 있다. 이 경우 상세한 내용들을 명시하지 않을경우 인테리어업자에 해당하는 개발자의 영역이 더 늘어난다는 점을 이해해야 한다.
여러 기획 문서들.
기획 문서는 종류가 참 많다. 주변을 설득시키기 위한 시장분석보고서 같은 문서부터 시작해 사용자 스토리, Information Architecture 설계서, 기능정의서, 화면 설계서, 스토리보드, API명세서, 운영계획서 등이 있으며 사실 세분화하면 더 많아질 수도 있다.
효과적인 기획문서 작성법
효과적인 기획 문서를 작성하기 위해서는 우선 명확한 목적과 범위 설정이 필요하다. 무엇을, 왜 만들려고 하는지 명확히 해야 한다. "고객 편의성 증대를 위해"라는 모호한 표현 대신 "회원가입 단계를 n단계에서 n-2단계로 줄여 가입 완료율을 현재 60%에서 80%까지 높인다"와 같이 구체적으로 작성해야 한다.
구체적인 기능 요구사항을 작성할 때는 입력값과 출력값, 처리 과정을 명확히 해야 한다. 예를 들어 "로그인 시 이메일 또는 전화번호를 입력받고, 비밀번호는 8자리 이상, 특수문자 1개 이상 포함"과 같이 구체적인 조건을 명시한다. 처음부터 완벽할 필요는 없다. 초안을 작성하고 구체화 과정에서 발생하는 문제들은 함께 정의해 나갈 수 도 있다.
예외상황에 대한 처리도 중요하다. 정상적인 케이스만 고려하면 실제 서비스 운영 시 많은 문제가 발생한다. 네트워크 오류, 서버 장애, 사용자의 잘못된 입력 등 발생 가능한 모든 예외 상황을 고려하고, 각각의 경우에 대한 처리 방안을 명시해야 한다. 이 역시 경험이 쌓일수록 예측 가능한 예외상황의 범위가 넓어진다. 흔치 않지만 예외처리를 개발자보다 깊게 고민해온 기획서를 보면 노력을 많이한게 느껴진다.
위에 담긴 내용들은 리뷰와 피드백을 진행하면서 계속 변경된다. 따라서 변경사항을 관리하는 프로세스도 필요하다. 이때 변경 사항을 추적할 수 있도록 문서의 버전 관리가 필요하며, 주요 변경 사항과 그 이유를 명확히 기록해야 한다. 기획팀이 Git이나 SVN같은 변경사항 관리툴을 잘 사용하지는 않지만 적극적으로 활용하면 이런면에서 도움이 될거라고 생각한다. 왜냐하면 어디가 달라졌는지 확인하기가 너무 편하기 때문이다.(!!)
기획/개발간 소통 개선방향
효과적인 소통을 위해서는 먼저 공통된 문서 프레임워크가 필요하다. 매번 일할때마다 다른 형식을 사용하면 혼란스러울 수 있다. 표준화된 템플릿과 절차를 만들고, 이를 지속적으로 개선해나가는 것이 좋다.
정기적인 기획 리뷰는 매우 중요하다. 개발이 시작되기 전에 반드시 개발팀과 함께 기획 내용을 검토하는 시간을 가져야 한다.(물론 QA와 디자이너 등 모든 동료들과 함께해야 한다) 이때 기술적 제약사항이나 구현 방식에 대한 논의가 이루어지며, 잠재적인 문제점들을 미리 발견할 수 있다. 이때 많은 갈등이 생기고 많은 기획자들이 힘들어하는데 각 상황별 해결방법에 대해서는 이어지는 글에서 다룰 생각이다.
피드백 루프도 필수적이다. 개발 과정에서 발견되는 문제점이나 개선사항들을 기획에 반영할 수 있는 체계가 필요하다. 일방적인 소통이 아닌, 양방향 소통이 이루어져야 한다. 개발자가 R&R을 혼동하고 월권한다는 생각에 기분이 안좋은 경우도 발생할 수 있다. 하지만 결국 내 생각 혹은 조직의 생각이 구체화되고 공통의 작업물이 발전되고있다고 생각하자. 의사결정권이 여러분 기획자에게 달려있기때문에 이야기 한 것이다. 좋은면으로 생각하고 성장하는 기회로 여길수록 좋다고 생각한다.
개발자가 선호하는 기획서에 대해 알아봤다. 여러 문서가 있고, 오해가 발생하는 지점에 대해 짚어봤다. 문서작업에 매몰되기 보다는 기획자가 뜻하는바를 이루기 위한 도구임을 인식하고 문서의 주인이되어 슬기롭게 이겨냈으면 좋겠다.
