기획에서 기능 명세 얻어내기

저는 요즘 제 개인 블로그와 KLDP 블로그에 글을 중복 투고하고 있습니다. 두 곳에 올리는 글이 완전히 같은 것은 아니고 KLDP에만 올라오는 글이 있고 개인 블로그에만 올라가는 글이 있습니다. 지금 올리는 글은 리눅스와 거의 관계가 없고 현업에 쓰이는 용어와 예제가 포함되어 있어서 KLDP에는 올리지 않으려고 했는데 이 다음에 올릴 글과 다소 연관이 있어서 그냥 올립니다. 양해 바랍니다.

아래에서 제가 설명하고자 하는 내용은 현업에서 폭넓게 다양한 사람들에게 적용해본 결과는 아닙니다. 몇 가지 개인적인 실험의 일환으로 시도해 보았고, 나름대로 성과를 얻었기에 공유하고자 합니다. 글을 쓰다가 흥이 올라서 과장을 하거나 막 나가는 경우가 있었는지도 모릅니다. 양해를 구하겠습니다. 어쩌면 흐름이 일정치 않은 부분도 있을 것이고요. 그건 최근 따로 여유 시간이 없는 관계로 며칠에 걸쳐서 조금씩 적어서 그렇습니다. 본문에서 사용하는 예는 모두 순전히 가상입니다. (오해하실까봐)

용어의 혼란

여러분에게는 이런 경험이 있었을 것입니다. 

"캐릭터가 특정 존에 들어왔을 때 캐릭터에게 특정한 효과가 부여되게 하고 싶은데요,"

"잠깐만요, '존'이라는 게 정확히 뭔가요?"

"'존'이 뭐냐고요? 캐릭터가 돌아다니는 게임 공간을 말하는 거죠."

"아, 제가 필드라고 부르는것 말이군요."

"그래요? 필드라고요? 그래픽팀이나 우리도 다 '존'이라고 부르는데 용어를 좀 통일하면 안 될까요?"

"안돼요, 소스코드에 이미 그렇게 썼어요."

"?_?"

이런 일도 있었겠죠?

"사용자가 여기를 지나다가 함정에 빠지면 대미지를 입고요, 여기서는 무조건 죽어요. 그러면 죽음 페널티를 받게 되는데, 레벨 차이가 얼마나 나는 캐릭터가 살려주느냐에 따라 부활 페널티의 효과가 높아지거나 낮아지거나 하는거죠."

"잠깐만요. 아까 전에 말한 '죽음 페널티'는 '부활 페널티'와 다른건가요?"

"뭐가요?"

"아까는 '죽음 페널티', 좀전엔 '부활..'"

"아아, 그건 그냥 그렇게 부른거예요."

"그럼 그 '뭔가' 페널티는 죽을 때 적용되나요 부활할 때 적용되나요?

"?~?"

아마 이 비슷한 예는 셀 수도 없이 많을 겁니다. 어떤 때는 몇 시간동안 서로의 용어를 질문하고 고쳐주느라고 정신이 없기도 하죠. 그렇다고 어디 나와 너의 용어만 다르던가요? 같은 내용을 지칭하는 용어가 내가 말하는 중에도 조금씩 바뀌거나 하죠. 설령 그게 죽음 페널티이든 사망 페널티이든 뭐 그렇게 중요하겠어요? (하지만 부활 페널티는 뉘앙스가 정말 다릅니다.) 그래서 책을 읽거나 다른 선배님들의 경험을 들으면 그렇게들 프로젝트의 용어 사전을 만들어야 한다고 하는가봐요. 그건 어떻게 만들까요? 조금 있다가 알아보죠.

내용의 중복

좀 다른 이야기. 이런 저런 이유로 열심히 문서를 작성하다보면 간혹 문제에 봉착할 때가 있습니다. 내용들이 서로 관련이 있을 때죠. A를 설명하는 중에 B의 일부와 밀접한 관련이 발생했습니다. B-a를 빼놓고는 A-b를 설명할 수가 없어요. 어떻게 해야 할까요? 좀 불친절하게도 B-a를 설명하는 문서를 참조하시라고 적을 수도 있겠죠. 어쨌든 모든 내용은 제 머릿속에 있는데, B-a가 정말은 어느 문서에 있는지 알 수가 없네요. 제일 쉬운 방법은 제가 알고 이해하고 있는 내용을 A-b 근처에 다시 적는 겁니다. 사실 아직 어느 문서에도 없을 수도 있잖아요. 저라면 그렇게 하겠어요. 두 번 쓰는게 뭐 그리 대수인가요?

그런데... 문제는 하나의 사실을 표현하는 말이 역시 하나인 것은 아니라는 겁니다. 왜 비슷한 내용이 여기 저기에 있죠? 고쳐야 할 일이 있을 때는 어떻게 할까요? 그 내용이 대체 어디어디에 있는거에요?

사실 기획은 문서에 있는 것이 아닙니다. 그건 기획자의 머릿속에 있죠. (어쩌면 기획자들의 '사이에' 있는 경우도 있어요.) 그러니까 기획서의 오류도 뭐 그리 대단한 것은 아니에요. 기획자에게 물어보면 언제나 정답을 알 수 있습니다. 그리고 기획서를 갱신해주겠다는 대답도 하죠. 기획서는 소통의 도구일 뿐입니다. 이 사람과 저 사람의 소통을 위한 도구이기도 하고, 한 사람의 과거와 현재를 이어주기도 하고요. 기획서가 아예 없다고 하더라도 기획만 잘 전달이 된다면 괜찮습니다. 어차피 잘 쓰여진 기획서라도 그것만 갖고는 모든걸 이해할 수는 없어요. (작가의 의도는 무엇인가 - 한 두 번 들어보셨어요?) 정말 문제는 내가 기획을 제대로 이해하고 있는가 아닌가입니다.

자, 이제 기획자에게 꼬치꼬치 캐물어 기획에 대한 모든 걸 다 들었다고 칩시다. 그럼 그건 이제 어디에 있나요? 제 머릿속에요? 농담마세요, 저는 들은지 5분이면 까맣게 다 잊는다고요!

명세서를 쓰자

가끔 우리는 한참 설명을 듣다가 이렇게 말하는 때가 있습니다. "제가 다시 설명을 해 볼테니 제대로 이해했는지 들어주세요." 마치 '제가 전화번호를 제대로 들었는지 다시 불러볼게요' 같죠. 이건 꽤 유용한 행동입니다. 다른 사람에게 말로 설명할 때 자신이 제대로 이해하고 있는지 아닌지를 알 수 있게 되는 경험, 여러번 해보셨을 거예요. 기록이 남지 않는다는게 단점이긴 하죠. 글로 적어보는 것은 어떻습니까? 남의 글을 별로 읽을 기회가 없는 기획자에게 거꾸로 문서를 주어보자구요.

글을 쓰는데 제가 추천하는 도구는 위키위키입니다. 몇 가지 장점이 있습니다. 적는 법을 알려드리죠. 대신 전제가 있습니다. 여러분은 기획자와 방금 기획서 리뷰를 끝내고 돌아와 아직 모든걸 다 잊기 전이어야 합니다. 그러니까, 제 경우는 5분이 지나기 전이죠.

새로운 페이지의 이름을 정해야 합니다. 뭐가 좋을까요? 기획서 이름으로 해도 좋고, 일반적으로 통용될 수 있는 이름이라면 다 좋습니다. 기존에 정해둔 이름이 있다면 그걸로 해도 좋습니다. 저는 '캐릭터의 죽음과 부활'이라는 문서를 받았는데, 제가 선택한 페이지 이름은 '플레이어의 죽음'이었습니다. 공교롭게도 지난번에 거기까지만 정의를 해놓고 페이지 만들기를 끝낸 적이 있었거든요. 뭐든 앞으로 '그 내용'을 지칭할 땐 '그 이름'을 써야 한다는 것만 지키면 됩니다. 이유는 곧 알게 되실 겁니다.

다음은, 그 페이지에 기획서의 내용 전체를 털어넣겠다고 덤벼듭니다. 안 들어갈 것 같죠? 맞습니다. 다 넣을 필요도 없고요. 군더더기는 다 뺍니다. 빼야할 것들의 목록은 다음과 같습니다. 그림, 그래프, 순서도, 도표, 표들은 뺍니다. 설명을 위한 설명, 접속사, '~습니다', '~할 것입니다', '다음 기획서 A32067zQ에서 보강합니다...', 뺍니다. 기획 의도, 동기들도 빼야할 주요 요소 중 하나입니다. 그런 것들은 기획자와의 리뷰에서 벌써 해결했어야 합니다. 여기까지 들고 오진 마세요. 이제와서 기획 의도를 의심해서 어쩌겠어요?

진짜 알맹이들은 구조화 해서 모아야 합니다. 단락이나 들여쓰기, 총알 목록 등을 이용해서 관련 있는 것끼리 모읍시다.

문제가 생겼어요!

정리를 하다보니 앞에 나왔던 유사한 내용이 다시 등장했습니다. 어쩌죠?

앞에 나온 내용으로 다시 돌아가서 둘을 비교해 보세요. 완전히 같거나 혹은 완전히 같아야 할 내용인가요? 좋아요, 그러면 잘라냅니다. 새로운 페이지를 만들어서 거기에 넣고 두 군데에 그 이름으로 링크를 겁니다. 왠지 익숙한 행동이네요... ReFactoring에서 ExtractMethod라고 부르는 그것이죠. 위키위키에서는 이런걸 ExtractPage라고 합니다. 이제 앞으로 이 새로운 페이지가 여러 곳에서 불려진다면 좋겠네요. 그래야 잘 분리한 거겠죠? 중요한 건 페이지의 이름이 '바로 그 내용'을 잘 반영하는 좋은 이름이어야 한다는 겁니다. 앞으로 그런 내용을 이야기할 때는 내용을 일일이 말하거나 아무래도 좋은 이름을 사용하는 대신, 정확하게 바로 그 페이지 이름을 사용하세요. 기껏 열심히 생각해서 만들었는데 아깝잖아요.

이제 다 됐나요? 혹시 명세서가 너무 길진 않나요? 위키위키에서 긴 글을 편집할 수도 있지만, 위키위키로 정리한 명세서는 통상 그리 길어지지 않습니다. 저는 15페이지짜리 기획서를 정리하는데 스무줄 정도면 됐어요.

페이지를 뚫어져라 노려봅시다. 비슷한 성격의 기능 명세는 서로 모여있을 것입니다. 유사한 명세의 묶음과 다른 성격의 묶음들이 눈에 들어오나요? 따로 분리할 수 있을 것 같은 기분이 들진 않나요? 이름을 하나 붙여준다면 그 묶음을 따로 떼어 부르기 쉬울 것 같은데요. '어쩌구저쩌구.doc'의 '4.2.1 뭐뭐의 기능과 효과'라고 부르는 대신 말이에요.

저는 '죽었을 때는 이것과 저것과 요것, 조것, A, B, C, D는 할 수 없다. E는 할 수 있다. F는 받을 수만 있다'를 모아놓은 총알 목록이 눈에 띄이길래 ExtractPage를 하고, [사망 상태]라고 이름을 붙여주었습니다. 원래 페이지에는

• [사망 상태]가 된다

라고 적었습니다. 그리고 이런 내용들도 있더라고요. 'A가 Aa만큼 감소한다. B가 Ba만큼 감소한다. C는...'. [죽음 페널티]로 묶었습니다. '마을에서 부활하거나, 그 자리에서 부활하거나, 다른 사람이..' 라는 기능 묶음은 [부활]이라고 이름을 붙였습니다. 그랬더니,

• [사망 상태]가 된다
• [죽음 페널티]가 주어진다
• [부활]을 기다린다

죽었을 때 일어나는 일은 사실 몇 가지 되지 않네요. 이제 명세서가 한 화면 이내로 줄었나요? 수고하셨습니다. 이제 명세서의 주소를 기획자에게 주고 검토해 달라고 하세요. 구현은 기획서를 보고 하는게 아니라 명세서를 기준으로 할 거고, 그러므로 기획서와 명세서가 같은지 검토할 필요가 있다고 하세요. 즉, '제가 제대로 이해했는지 적어봤어요, 읽어주세요'와 같습니다.

기획자가 명세서를 읽는 동안, 우리도 지금까지 우리가 무엇을 했는지 검토해 봅시다.

• 용어를 정립했습니다: 우리는 어떤 기능 목록마다 알맞는 이름을 정해주었습니다. 이제는 [죽음 페널티] 대신 [사망 페널티], [부활 페널티]라고 부를 방법이 없습니다. 그런 페이지는 아예 있지도 않으니까요.
• 중복되는 내용들을 제거했습니다: 이제 더 이상 여기서 조금 다르고 저기서 조금 다른 내용은 없습니다. 딱 하나뿐이니까요!
• 기획을 잘 이해했습니다: 어떤 내용을 다른 사람에게 설명하는 것은 자신이 오히려 더 잘 이해할 수 있는 방법입니다. 기획자의 설명을 듣고 기획서를 읽는 동안 괜찮다고 생각했던 내용에 오류가 있었다는 것도 발견했을 겁니다. 기획서의 오류를 고치는 공짜 기능도 있었네요!
• 비슷한 기능 명세를 서로 모아놓았습니다
• 꼭 필요한 내용만 남기고 분량이 줄어서 전체 흐름을 더 잘 이해할 수 있게 되었습니다
• 어떤 기능이 영향을 미치는 다른 시스템과 기능들을 찾아냈습니다: 페이지 제목을 눌러서 역링크를 찾아보세요. [이동 속도]를 고치면 어떤 기능들이 영향을 받나요?
  

이렇게 정리된 명세서를 가지고 구현에 들어갈 수 있는데요, 사실 다른 것도 할 수 있습니다. 다음 번엔 사용자 스토리를 도출하는 방법을 알아보죠.