프로그래머가 사랑하는 기획서란? (개발 명분과 정책, 예외사항 케이스 떡칠)
 |
| <그림 1. 컨트롤러 UI 기획서 첫장> |
며칠 전 회사 근처 식당에서 20년 차 클라이언트 프로그래머(플머) 형과 점심을 먹고 있었습니다.
식사를 마치고 근처 커피숍에서 신규 입사자 친구들 이야기를 하던 중, 플머 형이 삶이 힘들다는 표정을 지으며 깊은 한숨을 내쉬었습니다.
"형, 무슨 일 있어? 왜 또 누가 고풍스러운 빨간색으로 옵션 창 꾸며 달래?"
제 농담에 플머 형은 쓴웃음 지으며 대답했습니다.
"그건 아무 빨간색이나 대충 칠이라도 하면 되는 건데, 유저가 뒤로 가기 누르거나 초기화 시키면 어떻게 할 것인지 예외 사항 처리가 하나도 안 되어 있잖아. 매번 이걸 어떻게 말해줘야 하냐."
그 푸념을 듣다 가만히 생각해 보니 문득 제 옛날에 처음 작성했던 기획서 내용에 빠뜨렸던 부분들이 하나둘 생각나기 시작했습니다.
"나도 그랬는데..."
프로그래머가 사랑하는 기획서
신입 기획자 시절, 와우? 던파? 이런 게임보다 100배는 더 잘 나가는 세상에 둘도 없는 천상천하 유아독존 같은 멋진 시스템을 가진 게임을 만들겠다는 미친 생각으로 회사에 입사했습니다.
하지만 실무에 첫발을 내딛는 그 순간, 기획자를 가로막는 '프로그래머'라는 까칠하고 공포스러운 험난한 파도가 절 기다리고 있었습니다.
이들의 가장 큰 특징은 일 할 때 감성이나 막연한 느낌 따위는 완전 무시하고 철저한 논리와 계산만이 가득한 대문자 T 아저씨들이었습니다.
특히 기획서에
"유저가 설정 취소를 누르면 해당 사항을 인지할 타이밍에 토스트 툴팁을 띄워줍니다"라는
소리를 적는 순간, 몇 번의 한숨과 나와 기획서를 번갈아 가며 눈을 희번뜩거리고는
"그 타이밍이 언제라는 거죠? 명확하게 그 순간을 가져와 주셔야 그렇게 만들 수 있습니다."란
말을 하며 회의를 끊어버렸죠.
즉 기획자에게 있어 프로그래머란 ?
내 기획의 허점을 파고드는 검증자이자 상상을 현실로 구현해 주는 무섭지만 유일한 동반자입니다.
특히 이 깐깐한 논리왕 전문가들을 납득시키고 원활하게 협업하려면, 그들이 진정으로 사랑하고
신뢰하는 '명확한 논리와 수치 그리고 룰'을 기획서에 담아내야 합니다.
개발 명분과 정책
프로그래머가 불만을 거두고 키보드에 손을 올리게 만들려면, 개발에 대한 정확한 '정책(Scope)'과 그에 걸맞은 합당한 '명분'이 필요합니다. "그냥 요즘 다 패드 지원하니까 우리도 넣죠"라는 빈약한 논리로는 절대 그들을 움직일 수 없습니다.
제가 2010년에 작성했던 '컨트롤러 UI 기획서'
 |
| <그림 2. 기획서 개요 부분> |
"패드 탭을 추가하기 위해 기존 조작 키 탭 부분의 크기를 맞추어 전체적인 옵션 UI 창의 크기를 확장한다."
 |
| <그림 3. 조작 관련 예시 화면> |
"조이패드를 사용할 경우, '대전 및 미션' 진행 시에만 사용이 가능하도록 제한한다."
이렇게 기존 시스템과 어디까지 간섭할 것인지 정책을 칼같이 그어주어야 플머 형들도 개발 리소스를 정확히 산출할 수 있습니다.
또한 변경점에는 반드시 기획적인 '명분'이 뒤따라야 합니다. 해당 게임은 TPS 장르였기에 거리에 따른 신속한 무기 교체가 생명이었습니다.
 |
| <그림 4. 빠른 무기 교체를 위한 패드 조작 방법> |
따라서 "기존 키보드의 '저격모드 + 공격' 같은 느린 키 조합 대신, 패드의 남는 버튼을 활용해 단독 키로 무기 교체를 할 수 있게 변경한다"
게다가 "조이패드는 게임 플레이에만 사용하는 것이기 때문에 불필요한 ESC 키 기능은 삭제한다"
이런 합당한 논리가 있어야 대문자 T 아저씨들도 고개를 끄덕입니다.
예외사항 케이스로 떡칠하라
명분과 정책으로 기틀을 잡았다면, 이제는 플머 형들의 매서운 공격을 방어할 튼튼한 방패가
필요합니다.
유저가 기획자의 의도대로만 얌전히 버튼을 눌러줄 거란 순진한 생각은 당장 쓰레기통에
버려야 합니다.
기획자는 최대한 머릿속으로 시뮬레이션을 돌려보며 온갖 예외사항(Edge Case)을 찾아내고, 거기에 맞는 답을 기획서에 떡칠해 놔야 합니다.
안 그러면 회의실에서 뼈도 못 추리게 물려갑니다.
 |
| <그림 5. 예외 사항 처리1> |
"유저가 이미 설정된 키를 중복으로 입력하면 어떡하죠?" -> "조작 키 중복 입력 시 해당 키끼리 치환하는 방식으로 처리한다."
 |
| <그림 6. 예외 사항 처리2> |
"버튼 세팅 다 안 하고 그냥 확인 누르고 꺼버리면요?" -> "모든 버튼을 설정하지 않고 확인 및 취소 버튼을 누를 경우, '모든 조작 버튼을 설정하세요'라는 경고 문구가 깜빡이고 팝업 창 종료를 막는다."
 |
| <그림 7. 예외 사항 처리 3> |
"유저가 자기가 키 바꾼 걸 어떻게 인지하죠?" -> "새로운 키를 입력하면 조이패드 그림에서 입력한 버튼이 3번 깜빡여서 시각적으로 알려준다."
이렇듯 "설마 유저가 이렇게까지 하겠어?" 싶은 예외적인 행동 하나하나에 대한
시스템의 반응과 경고 문구를 미리 정의해 두어야, 비로소 라이브 서버의 수많은
변수와 버그로부터 살아남을 수 있습니다.
포스팅 요약
정해진 규칙에 따라 움직이는, 이 호랭이 물어갈 프로그래머들이 진정으로
사랑하는 기획서는 결국 하나로 귀결됩니다.
유저의 기상천외한 변수를 통제할 '예외 사항'이 듬뿍 담겨 있고, 흔들리지 않는
'명분과 정책'으로 깔끔하게 마무리된 설계도.
신입이나 지망생 여러분, 화려한 아이디어에 매몰되어 겉 포장만 번지르르하게
꾸미고 있진 않으신가요?
오늘 당장 내 기획서에 빈틈(예외 처리)은 없는지, 프로그래머를 설득할 명분은 충분한지
다시 한번 꼼꼼히 살펴보시길 바랍니다.