프로그래밍 언어 입문서가 아닌 프로그래밍 기초 개념 입문서
문과생, 비전공자를 위한 프로그래밍 입문책입니다.
jobGuid 꽃미남 프로그래머 "Pope Kim"님의 이론이나 수학에 치우치지 않고 실무에 곧바로 쓸 수 있는 실용적인 셰이더 프로그래밍 입문서 #겁나친절 jobGuid "1판의내용"에 "새로바뀐북미게임업계분위기"와 "비자관련정보", "1판을 기반으로 북미취업에 성공하신 분들의 생생한 경험담"을 담았습니다.
Posted by 월하

안녕하세요. 월하(달땡땡) 입니다.
먼저 이렇게 미천한 실력으로 글을 써서 다른분들에게 누가 되지는 않을지 걱정이 앞서네요.
워낙에 훌륭하신 분들이 많고 전문적인 이야기가 오고 가지만....
어쩌면 저같이...
아무런 기본 지식도 없이 맨땅에 해딩하듯 기획자를 지망 하시는 분들에게
제가 겪은 실수를 되풀이 하지 마시라고 적는 글 입니다.


기획서는 어떻게 써야 할 까요?

어떻게 보면 답이 없는 문제일 수도 있습니다.
아래 글은 제 주관적인 의견이 다분히 반영된 글이기도 하니 하나의 참고로만 보시기 바랍니다.

잘 쓴 기획서... 그 이전에 기획서는 무엇일까요?

기획서는 아이디어를 구현 하는 방법을 개발자에게 설명 하기 위한 글 입니다.
즉, (잘 쓴)기획서는

  1. 아이디어가 담겨 있으며
  2. 해당 아이디어의 구현 방안이 담겨 있으며
  3. 개발자가 이해하기 쉬워야 한다

는 조건을 가지게 됩니다.

일반적으로 기획서와 잘 쓴 기획서의 차이는 위 사항 중 2번, 혹은 3번이 부족한 경우입니다.

  1. 구현 방법이 구체적이지 않거나
  2. 개발자가 이해하기 어려운 경우

입니다.

두 개로 나누어 적었지만 "뭔 소리인지 모르겠다!"의 한 문장으로 설명 할 수도 있죠.
즉, 뭔 소린지 알아 들을 수 있는 기획서가 좋은 기획서라고 볼 수 있습니다.

그래서 좋은 기획서는 "세 살배기 꼬마와 여든 살 어르신이 읽어도 어떤 말인지 이해를 해야한다." 고 합니다.
(글 쓰는 주제에 부끄럽지만 전 아직 저 정도 수준이 못 됩니다.)

그럼 기획서가 직관적으로 보이려면 어떻게 해야 할까요?

  1. 이미지화
  2. 도표화

해야 합니다.

위에서 언급한바와 같이 기획서는 개발자를 위한 글입니다.
하지만... 모든 개발자가 그렇지는 않지만 발자분들은 기획서를 읽지 않습니다.[각주:1]
정확히 말하면 기획"서"를 읽지 않습니다.[각주:2]
위의 이미지, 도표, 수식을 중심으로 보지 그 옆에 주석(혹은 메모)처럼 달려 있는 글은 잘 안 읽습니다.
더욱이 글로만 작성된 부분은 거의 안 읽습니다.
(개발자분들에게 돌 맞을지도 모르겠네요.)



1. 이미지화
너무나도 당연한 이야기지만 텍스트로 적힌것 보다 이미지로 설명하는게 훨씬 알아보기가 편합니다.
보통 UI나 화면 연출등을 위해 사용 됩니다. 

어떤 장면을 묘사한 글과 촬영한 사진. 둘 중에 사진이 해당 장면을 명확하게 전달 할 수 있죠.

HP / MP 게이지 표현

텍스트 버전
HP 게이지와 MP 게이지는 막힌 원형이되 캐릭터의 키에 맞게 세로로 늘어져 있으며 
유저 캐릭터 좌, 우에 각기 바깥쪽으로 90도 회전해 있으며 HP는 붉은색, MP는 푸른색이다

이미지 버전


위 두 가지 버전을 보면 분명 아래 이미지 버전이 좀 더  눈에 잘 들어 옵니다.
이미지만 있는것 보다 간략한 메모를 달아 두는게 조금 더 효율적입니다.

위의 이미지 같은 경우에는

 
 
  HP / MP 게이지는 캐릭터 좌, 우에 배치
  HP 게이지: 붉은색 계통의 색상
  MP 게이지: 푸른색 계통의 색상

라고 설명을 달아 줍니다.

즉, 사진에 제목과 설명을 달아 주는 겁니다.[각주:3]


2. 도표화
비슷한 성격의것 중 도표로 만들 수 있는것은 도표로 정리를 하는것이 더 좋습니다.
보통 데이터나 수치적인 부분을 설명 할 때 사용 됩니다.

메신저의 기능과 사용 조건은 아래와 같다.

텍스트 버전
  1. 친구 추가
    1. 로비 / 대기방 / 인게임에서 사용 가능
    2. 친구 리스트가 가득차지 않을 경우 사용 가능
  2. 친구 삭제
    1. 로비 / 대기방 / 인게임에서 사용 가능
    2. 1명 이상의 친구가 리스트에 등록되어 있을 경우 사용 가능
  3. 친구 초대
    1. 대기방에서 사용 가능
    2. 1명 이상의 온라인 상태인 친구가 있을 경우 사용 가능
  4. 편지 보내기
    1. 로비 / 대기방 / 상점에서 사용 가능
    2. 1명 이상의 친구가 리스트에 등록되어 있을 경우 사용 가능

도표 버전
  로비 대기방 인게임 상점 비고
친구 추가 가능 가능 가능 불가 친구 리스트에 여유 공간이 있어야 함
친구 삭제 가능 가능 가능 불가 1명 이상의 친구가 등록 되어야 함
친구 초대 불가 가능 불가 불가 1명 이상의 온라인 상태인 친구가 있어야 함
편지 보내기 가능 가능 불가 가능 1명 이상의 친구가 등록 되어야 함



위와 같이 도표로 정리 하는게 공간도 절약되고 보기도 편합니다.[각주:4]



직관적으로 기획서를 쓰기 위한 두 가지 조건을 언급 했습니다.

물론 해당 두 가지 사항은 기본적인 부분이면 부가적으로 더 많은것들이 있습니다.
(가령 데이터 구조 같은것들이 있겠죠.)

마지막으로 기획서에 꼭!! 무조건!! 절대적으로 들어가야 하는 부분이 있습니다.
바로 처리 순서(프로세스) 예외 처리 입니다.
이게 제대로 안 되어 있으면 시스템적인 버그가 발생 합니다.

가령 상호 동의하에 친구 추가가 되는 구조의 메신저(친구 리스트)라고 할 경우



맞아 죽기 딱 좋습니다.
개발팀이 온갖 쫑코를 다 줄겁니다.
예외 처리와 처리 순서가 다 빠져 있기 때문입니다.

조금 부족 하지만 저기에 살짝만 살을 덧붙여 보겠습니다.

클릭하면 확대 가능 합니다.
(Light TT EX 플러그인이 설치되어 있다면요)



https://t1.daumcdn.net/cfile/tistory/142CC5444EEF734B02

클릭 하시면 크게 볼 수 있습니다.


이렇게 어떤 순서로 처리를 해야 하는지와 예외적인 상황에서 어떻게 처리 할건지가 있어야 합니다.
뭐 위의 샘플에도 빠진 부분이 많습니다.[각주:5]
하지만 원래 기획서라는게 개발 하면서 틀린 부분이 발견 되면 그때 고치는게 제맛이죠.

이상으로 기획서의 (주관적) 정의와 작성 법을 마치겠습니다.

  1. 이건 제 칫솔을 걸고 장담 할 수 있습니다!! [본문으로]
  2. 기획서는 같은 기획자나 높으신분들, 마케터, QA가 봅니다. [본문으로]
  3. 하지만 설명이 너무 길어 지면 오히려 역효과를 가져 옵니다. [본문으로]
  4. 사실 저렇게 알록 달록하게 까지는 하지 않습니다.편의상 색상을 넣고 잘 보이라고 한거죠. [본문으로]
  5. 가령 상대방이 추가 요청 메시지를 받은 후 아무런 액션 없이 게임 종료가 된다거나 하는 부분이요 [본문으로]

댓글을 달아 주세요

  1. Favicon of https://gamedevforever.com 끼로 2011.12.26 12:04 신고  댓글주소  수정/삭제  댓글쓰기

    확실히 적절한 이미지, 도표와 적절한 설명이 있는 기획서가 읽기 쉽고 이해하기도 쉽고 좋죠 ㅎㅎ 마지막 순서도는 너무 과하게 친절하신거 아닐까요..? 너무 친프로그래머적인 문서가 아닐까 생각될정도.. 아무튼 잘봤습니다!!

    • Favicon of http://blog.daum.net/b820706 gki82 2011.12.26 12:20  댓글주소  수정/삭제

      정말 친프로그래머적으로 순서도를 그리지 않으면 실력없는 또는 개념없는 기획자로 낙인되는 경우가 있습니다. 최소한 기획자에게는 가카 못지 않은 꼼꼼함이 필요합니다!

    • Favicon of https://gamedevforever.com 월하 2011.12.26 13:40 신고  댓글주소  수정/삭제

      끼로님//예전에는 저게 과하다고 생각했었는데...
      "그런거 기획서에 없었잖아요." 피드백을 몇 번
      받고 나니 최대한 자세히 써야 겠다는 생각이 들더라고요.

    • Favicon of https://gamedevforever.com 월하 2011.12.26 13:41 신고  댓글주소  수정/삭제

      gki82//가카못지않은 꼼꼼함.... 으....
      어떻게 보면 맞는 말인데....
      어감이 묘하네요. ㄷㄷㄷ

    • Favicon of https://gamedevforever.com 끼로 2011.12.26 13:56 신고  댓글주소  수정/삭제

      예외처리에 대해서 "기획서에 그런거 없었자나요" 라고 말하는건 프로그래머가 책임회피를 하는거라고 생각합니다.. 물론 기획자분들이 자세히 적으면 트러블메이커 프로그래머가 있어도 트러블이 잘 안생기긴 하겠지만요..

    • Favicon of https://gamedevforever.com 귀거리 2011.12.26 14:13 신고  댓글주소  수정/삭제

      결국 이또한 커뮤니케이션을 잘하기위한 근거자료로도 활용이 됩니다!!

    • Favicon of http://nairrti.com Nairrti 2011.12.26 15:42  댓글주소  수정/삭제

      근거라기 보다는 커뮤니케이션 실패 이후 증거...겠죠.

    • Favicon of https://gamedevforever.com 귀거리 2011.12.28 11:38 신고  댓글주소  수정/삭제

      꼭 실패의 증거라기보단 소통을 위한 기본적인 자료쯤이라고 생각하는게...ㅎ 증거라고하면 너무 삭막하자나요 신뢰가 있다면 더 좋은거겠죵 ^^;

  2. Favicon of https://gamedevforever.com 알콜코더 2011.12.26 12:08 신고  댓글주소  수정/삭제  댓글쓰기

    오옷.. 추천.. 평소에 언제나 바라는 방향이군요..
    제발 기획자들은 이렇게 좀 기획서 갖다 주세요~~ ㅠ.ㅠ

    ps. 제발 와우의 XX처럼 만들어 주세요..라는 기획서 말고..

    • Favicon of https://gamedevforever.com 월하 2011.12.26 13:42 신고  댓글주소  수정/삭제

      와우의 XX처럼 만들어 주세요.....
      개발자분들이 전부 와우의 XX를 즐겨봤다면
      가장 짧고 간결한 기획서가 아닐까요? ㅎㅎ;;;;;

      그래도 그렇게 쓰기에는 기획자의 자존심(?)이
      허락을 못 하지만요.

  3. Favicon of https://gamedevforever.com warehouse83 2011.12.26 12:55 신고  댓글주소  수정/삭제  댓글쓰기

    오오 멋진 기획서입니다.
    저는 QA/Tester 입니다만. 저 정도 기획서(명세서)만 나와도 테스트케이스 작성에 큰 도움이 됩니다.

    실제로 저 정도 기획서에서는 버그도 많이 나오지 않습니다.

    최근 날림 기획 때문에 QA팀에서 예외처리를 정리해 주고 있는데 위의 기획서를 보니 기분이 남다르네요(.....)

    소프트웨어 테스팅의 결정 테이블과 유즈케이스를 이용해 예외처리 방안을 사전에 기획해 놓으면 기획자분들이나 개발자분들에게 큰 도움이 될거라고 생각합니다.(랄까 개발자 분들 손에 가기 전에 하는게 가장 좋고요;;)

  4. Favicon of https://gamedevforever.com 귀거리 2011.12.26 14:11 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 그리고 멋진 기획자시군요!!! 이렇게 정성 가득 기획서에 흠을 잡으려 달려드는 개발자는 그리 많지 않을겁니다..^^

  5. sgpro 2011.12.26 16:03  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 좋은 글 잘 읽었습니다. ^^

    한가지 더 추가했으면 하는 바램이 있어서 글을 적어요. ^^;;;
    (논란에 여지가 있을 수 있겠네요. ㄷㄷㄷ;;)

    저는 서버 프로그래머여서 그런지, 각 시스템 관계에 대해 좀 많이 살펴보는 편입니다. 그리고 게임에 대한 전체적인 그림을 그리기 위해 노력을 합니다. (저만 그럴수도 있습니다. ^^;;;)

    예를 들면...

    >> (새로 추가되는 시스템) 캐릭터는 채집을 한다 - 특정 오브젝트를 클릭하면 일정 시간동안 채집 애니메이션이 나오고, 채집 시간이 되면 해당 오브젝트를 획득한다.

    >> 채집 시스템과 연관된 시스템 :
    1. 전투 시스템 : 선제 공격 Mob이 채집 중인 캐릭터를 발견하면 어떻게 해야 하나?
    1.a. 기존 물물교환 시스템에서는 물물교환 중인 캐릭터들은 선제 공격을 당하면 물물교환이 취소되게 되어 있다.
    1.b. 채집중인 캐릭터의 HP가 1이다. 그래서 공격을 당하면 바로 죽는 경우가 있을 수 있다. (워프 시스템과 연관이 있다)

    3. 물물교환 시스템 : 다른 유져가 다가와서 물물교환을 시도 하려하면 어떻게 해야 하는가? 기존 물물교환 시스템에서는 특정 장소에서만 물물교환을 하도록 되어 있는데, 이 특정 장소에 채집 오브젝트가 있다면?

    4. 인벤토리 시스템 : 기존 아이템과 동일한 방법으로 저장하면 되는가?

    5. 창고 시스템 : 창고에 저장할 수 있는가?

    6. 물물교환 시스템 : 물물교환 할 수 있는가?

    7. 메일 시스템 : 메일로 전달할 수 있는가?

    8. 경매 시스템 : 경매을 할 수 있는 물품 인가?

    9. 시간제 아이템 : 시간이 흐르면 사용할 수 없는 아이템인가?

    9. 기타 등등을 쭈욱 나열~

    위에 예처럼 저는 연관된 시스템들을 쭈욱 나열한 후, 기획 하시는 분과 회의를 하는데요. 전체적인 그림을 그리시는 분과 아니신 분과 회의를 하면 많은 차이가 있음을 느낍니다. 이 느낌에 대해서는 생략할께요. 왠지 의도하지 않게 비하하는 글이 될꺼 같네요. ^^;;;;

    그래서 기획서에 이 시스템은 어느 시스템과 관련이 있으며, 이 시스템과는 이러한 부분이 이렇습니다. 라는게 있으면 더욱 좋을꺼 같습니다. ^^;;

    (그런데 이런것까지 들어가면.. 연관된 시스템 문서들에도 써줘야 할텐데.. 유지보수가 힘들겠네요. ㄷㄷ;; 이건 모르겠습니다. ㅎㅎㅎ;; )

    • Favicon of https://gamedevforever.com 월하 2011.12.27 09:43 신고  댓글주소  수정/삭제

      물론 예외처리 부분이나
      다른 시스템에 영향을 주는 부분이면 다 기술하여 주고
      관련 시스템 기획서를 최신 버전으로 업데이트
      하는게 당연하다고 생각 합니다.
      그렇지 않으면 나중에 기획서간에 충돌이 일어나니깐요.
      정확한 지적 감사드립니다. ^^

  6. Favicon of https://gamedevforever.com 김포프 2011.12.26 18:48 신고  댓글주소  수정/삭제  댓글쓰기

    아니 전.. 이렇게 제대로 된 기획서를 본적이 없는데.. 기획자하고 미팅하면서 받아적었고, 그림은 테크니컬 아티스트가 그려줬었다는.... 물론 Character Customizer만들 때 이야기지만....-_- (그 외엔 기획자하고 일할일이 없었어요.. )

  7. Favicon of http://wontak.blogspot.com isdead 2011.12.26 23:20  댓글주소  수정/삭제  댓글쓰기

    요즘 가끔 드는 생각이지만, 플로우차트 타입의 기획 명세는 현대적인 게임을 디자인하는데 있어서 좀 구식 방법이 아닌가 싶다는 생각도 듭니다.
    저도 아직 마땅한 표현 방법을 찾은건 아니지만, 시퀀스 다이어그램이나 UML 등... '기획자가 원하는 바를 정확히, 그리고 편리하게 표현할 수 있는 방법'을 찾는 것이 좋지 않나 싶습니다.


    현실에선 플로우챠트'라도' 써 주면 감지덕지인 것은 분명 맞습니다만ㅋㅋㅋㅋㅋㅋ

    • Favicon of https://gamedevforever.com 끼로 2011.12.27 00:27 신고  댓글주소  수정/삭제

      저도 공감합니다. 기획자분들이 기획서를 쓰는 본래의 이유는 개발을 해 나가는데 있어서 기획의도나 기획 자체를 같이 개발해나가는 모든 사람들에게 이해시키기 위함이니까요.. 손짓 발짓이 문서보다 더 정확하게 전달할 수 있다면 그 손짓 발짓이 더 좋은 기획서라고 생각해요 ㅎㅎ 기획은 참 어려운일인것 같아요.. 제가 만약 기획을 한다면 게임이 망할껍니다 으하하

    • Favicon of https://gamedevforever.com 월하 2011.12.27 09:46 신고  댓글주소  수정/삭제

      구관이 명관이다... 라고 우기고는 있지만
      뭔가 아쉬움이 남기는 합니다.
      예전에 기획서 없이 html로 실제 구동되는 모습을
      제작하여 브리핑 한 적이 있긴 했는데
      그 방식도 나름 반응이 좋았지만...
      정작 html로 짜는데 걸리는 시간이 꽤나 걸려서
      효율성 부분에서는 별로 안좋았던거 같아요.

    • Favicon of https://gamedevforever.com 스톰(서광록) 2011.12.27 10:09 신고  댓글주소  수정/삭제

      플로우차트의 한계점에 대해서는 저도 같은 생각입니다. 간단한 시스템이야 플로우차트가 좋지만 요즘 게임 시스템들은 복잡해져서 플로우차트로는 기본적인 흐름을 설명하는 용도로만 사용하는 편이 낫다고 봅니다.

      (그래서 대안은... 그냥 와우처럼 만들어주세요!)

    • Favicon of https://gamedevforever.com 월하 2011.12.27 10:11 신고  댓글주소  수정/삭제

      sstorm님//와우 만세!!

  8. Favicon of http://dishdev.me/ Dish 2011.12.27 10:08  댓글주소  수정/삭제  댓글쓰기

    으엌ㅋㅋㅋ 마지막에 예외처리 플로우 대박이네요

  9. Favicon of http://gaebit.tistory.com zinzza 2011.12.29 13:03  댓글주소  수정/삭제  댓글쓰기

    으아...
    기획이 저렇게 되야 하는데...
    종종 예외처리가 빠진 Yes Flow로만 이루어진 기획을 보면...
    만들기 참 쉬워요...ㅡ.ㅡ;

    문제는 고칠때 죽어난다는거.....ㅡ.ㅡ;;;

  10. Byulbram 2012.01.27 17:06  댓글주소  수정/삭제  댓글쓰기

    문제는 저 짓을 하려면 코딩에 대한 개념이 좀 있어야하는데,
    상당수의 꼬꼬마 기획자 애들은 코딩 개념이 없다는게 문제랄까요.
    (그런걸 할 수 있으면 프로그래밍을 하죠. 따위의 대답을 들으면.. 정말 살의가 일어납니다)

    뭐 사실 저야 정리해서 따로 문서로 적는걸 무지 싫어하는 구석기 시대 스타일의 기획자(..?)라서 문서 작성 관련된 과목은 아예 안가르치긴 합니다만..

  11. DreamKiller 2012.02.24 02:46  댓글주소  수정/삭제  댓글쓰기

    개념 글 잘 봤습니다.

    저는 서버프로그래머 입니다만 사실 저렇게 자세히 적어주셔도

    다시 모든사항에 대해서 점검을 하게 됩니다.

    그래서 제가 선호하는 방식은 직관적이게 짧게 쓰고 꼭처리해 줘야 하는 예외에 대해서

    표현해주는 것이 좋습니다... 너무 자세함은 집중력을 잃게 한다.. 랄까요?

    실제로 심플하게 핵심만 작업 후 기획자와 같이 더 필요한 부분에 대해서 정리해서 다시 한번 시간을 갖는것이
    더 좋았던거 같네요.

    주제 넘은 코멘트 였을려나요.. ^^;

    • Favicon of https://gamedevforever.com zinzza 2012.02.24 10:15 신고  댓글주소  수정/삭제

      오홍~
      이분 말씀도 일리가 있는데요?

      친구추가 기능이 추가되어야 합니다.
      1. 친구리스트가 빈공간이 있으면 안됩니다.
      2. 친구를 추가할때 캐릭터이름 규칙은 이러이러합니다.
      3. 상대가 온라인인경우 알려줍니다.
      4. ...
      이런식으로 체크리스트를 주는것도 좋겠네요.
      이것도 길어지긴 하겠지만 말이죠^^

      아무레도 공돌이들은 이런걸 좋아하니까요.

  12. Favicon of https://hsol.tistory.com 훈솔 2012.08.19 17:04 신고  댓글주소  수정/삭제  댓글쓰기

    좋은글이네요, 한번더 읽어봐야겠습니다 ㅎㅎ

  13. 2012.09.28 10:17  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다