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

약속 드린대로 올해 강연했던 pt자료 공유합니다. 강연장이 가득 차서 뒤에 서계신분들도 많았고 아티스트/프로그래머 비율이 반반이라 꽤 즐거웠던 강연이었습니다. ^_^



TAG KGC, 포프

댓글을 달아 주세요

  1. Favicon of http://blog.naver.com/chakanz 죽은개구리들 2013.10.17 16:53  댓글주소  수정/삭제  댓글쓰기

    좋은 강의 감사합니다~~~

Posted by 비회원

오랜만에 글이라는 것을 올려보는군요. ㅎㅎ;;;

궁금하시지는 않겠지만, 오랜만이니 근황이라도 살짝 이야기 하자면 최근에는 잠시 고급 렌더링 기술에 대한 작업을 잠시 미루어 두고, 생존을 위한 (모바일) 게임을 열심히 개발하면서 "기획, 디렉팅"과 같은 다양한 분야에 도전하고 있습니다. 차라리 프로그래밍이 젤 쉽군요. ㅜㅜ;;

오늘은 지난 KGC2013에서 발표했던 내용을 공유드릴까 합니다. 3일차 오전 첫 시간이라 많이 안오실 것이라고 생각했는데, 그래도 찾아주신 분들이 꽤 되셔서 감사하기도 하고 그랬습니다. 이 내용은 제가 모바일을 대상으로 엔진 개발 및 게임을 만들면서 겪었던 문제들을 해결하면서 느낀 점들을 적은 내용입니다. 공감하실 수도 있고 아닐 수도 있지만, 나름대로는 "모바일 게임"을 개발한다면 알아두면 좋은 내용이지 않을까? 라는 생각에서 정리해 보았습니다.

아마 당분간은 (모바일) 게임을 만들게 될 것 같아서 새로운 기술적인 내용에 대해서는 도전을 많이 못 할 듯 하지만, 나름 그 범위 내에서는 멋지게 할 수 있는게 무엇인지 찾아서 해보고 그 결과를 보고 싶기도 하네요. 그리고 어느 정도 안정화가 된다면, 최근 콘솔에서처럼 DirectX11의 최신 기술을 펑~펑~ 쓸 수 있는 프로젝트를 한 번 해보고 싶기도 하구요. ㅎㅎ. 

그럼 보시고 궁금한 것들을 댓글로 남겨주시면 답변드리도록 하겠습니다. 


댓글을 달아 주세요

  1. Favicon of http://hol_ding.blog.me TerNer 2013.10.16 21:47  댓글주소  수정/삭제  댓글쓰기

    좋은 글 보고 갑니다.
    아직은 Windows 용 2D 게임 엔진을 개발하는 학생이지만..

    슬슬 모바일 쪽도 파야할 시점 인거 같은데..
    뭔가 나중을 위해서(?) 라도 필요할 내용인거 같습니다.
    도움 정말 많이 됬습니다 ㅠㅠ

    • 알 수 없는 사용자 2013.10.17 17:23  댓글주소  수정/삭제

      도움이 되셨다니, 저도 기분이 좋네요. ㅎㅎㅎ.

      아~ 좋아라~ 헤헤~

  2. 근본없는개발자 2013.12.06 18:59  댓글주소  수정/삭제  댓글쓰기

    밑에서 배우고 싶네요 ㅜ,.ㅜ

Posted by 비회원

안녕하세요. 기시감입니다. 누구지? 들어본거 같은데? 싶은 그 기시감 맞습니다. ^^

한동안 백수질을 오래해서 글이 뜸했습니다. 뭐 올릴거 없나 싶던 차에..


이번에 참석한 KGC 2013의 강연 내용중 제가 들었던 강연들의 웹 기사 내용과 제가 따로 정리한 내용을 올려봅니다.

내용 중에는 개인적인 감상도 포함되어 있습니다.

감사합니다.


----------


Game QA로 살아가는 방법

웹진 기사 모음

This is gamehttp://www.thisisgame.com/webzine/news/nboard/4/?sf=subject&sw=KGC&page=4&n=49718

인벤 : http://www.inven.co.kr/webzine/news/?news=64113

 

게임QA 를 한번 해볼까? 하고 생각하고 있거나 이제 1,2년차로서 커리어패스에 대해 고민하고 있다면 정말 도움이 되는 강연입니다.

추가 사족을 붙이자면 레벨 1에서도 소개되는 ‘개발자도 알아야하는 소프트웨어 테스팅’ 서적의 테스팅 기법을 어떻게 게임 테스팅에 적용 할 수 있는가에 대한 고민을 해보는 것도 좋다고 생각합니다. 언제나 이런 책 보면 나오는 MP3, ATM기기, 인터넷 뱅킹 과 같은 예제가 게임하곤 다르잖아라고 생각하고 포기하는 경우가 많다고 생각하는데 고민해보면 다 게임에 적용 가능한 기법들입니다. 이게 풀리지 않으면 다른 테스팅 관련 서적을 봐도 포기하게 되더군요. …알아도 포기하게 되는 판에 모르면 더더욱 포기가 빠릅니다.

그리고 회사 내부적인 QA 프로세스도 중요합니다. QA 프로세스는 어떤 책을 봐도 가르쳐주지 않습니다. 개발 모델하고 QA 프로세스하고는 다릅니다. 솔직히 회사별로 다 다르게 가지고 있는게 QA 프로세스라 레퍼런스라고 정의하기도 어렵습니다.

하지만 첫 QA 직장이 이런 프로세스에 대해 관심이 없는 곳이고 분위기도 조성되지 않는 곳이라면 과감히 다른 곳으로 이직하시기를 저는 말씀드리고 싶습니다. 그런 곳일 수록 강연 꼭지에 나오는 QA에 대한 대우가 제대로 되지 않은 곳이라고 생각하시면 될 것 같습니다. 시니어 이상 되는 분들이라면 분명 노력하고 있는 부분이라고도 생각합니다.

 

몬스터헌터 개발 경험으로 나온 멀티액션의 사고방식

웹진 기사 모음

Thisisgame : http://www.thisisgame.com/webzine/news/nboard/4/?sf=subject&sw=KGC&page=4&n=49722

http://www.thisisgame.com/webzine/news/nboard/4/?sf=subject&sw=KGC&page=4&n=49724

인벤 : http://www.inven.co.kr/webzine/news/?news=64126

 

2시간 짜리 세션인데 앞에 한시간은 QA 세션을 들어서 뒤에 부분만 들었습니다.

몬스터헌터 내에 나오는 몬스터의 디자인이 어떻게 개발되었나에 대해 완성된 몬스터를 예를 들어 설명했습니다.

요약

1. 몬스터의 디자인은 몬스터의 특징을 주변 사물에서 가져와 만들었다. 더불어 몬스터의 약점또한 디자인에서 표현이 되어 있다.

- 쿠르페코 : 목을 부풀려 주변의 몬스터를 불러모으는 몬스터. 그래서 입은 관악기와 같은 형태이며 목젓이 부풀어 오르는 형태를 하고 있다. 목젓은 붉은색으로 표현되어 있어 해당 부분을 공격해 주변의 몬스터를 불러모으지 않게 할 수 있다.

- 베리오로스: 빙상에서 움직이는 몬스터. 빙상에서의 움직임을 위해 몸에 촘촘히 스파이크가 박혀있다. 스파이크를 먼저 공격해 제거하면 몬스터도 빙상에서의 움직임에 제약이 생겨 클리어에 도움이 된다.

- 로아루드로스: 목에 스펀지와 같은 질감의 부위가 표현되어 있는데 수륙양용 몬스터로 육지에 나왔을때는 목의 스펀지에 흡수된 물로 호흡을 한다는 특징을 가지고 있다. 육지에서 목의 스펀지를 공격 시 물로 돌아가려고 하며 공격 확률을 높일 수 있다.

2. 몬스터는 모두 플레이어의 학습을 유도하며 상위 몬스터를 사냥하기 위한 학습 기능을 가지고 있다.

- 수중전 몬스터로 바로 사냥을 하는 형태가 아닌 로아루드로스와 같은 수륙양용 몬스터를 통해 수중전에 대해 이해를 시키고 수중전 몬스터로 진행하는 형태

그 외의 얘기는 가쉽성 거리라 기사를 보는 것으로도 충분한 것 같습니다.

질의응답

3번 정도의 질의응답이 나왔는데 대체적으로 질문도 비슷했고 답변도 비슷했습니다.

질: 몬스터 헌터에 더 발전된 기술(오큘러스 리프트, 고사양 그래픽)은 쓰지 않을 생각인가?

답: 과거에 오락실에서 모여서 게임을 했듯 몬스터헌터는 오프라인 상에서 모여서 게임을 하는 즐거움에 초점을 두고 있다. 물론 더 발전된 기술을 등한 시 하지는 않을 것이다.

개인적으로는 아케이드 게임 개발사의 선두에 있던 캡콤다운 게임 철학이라고 생각했습니다. 왜 더 좋은 그래픽으로 가정용 콘솔로 게임을 만들지 않는가? 라고 많은 사람들이 몬스터헌터 개발팀에 요구를 하지만 모여서 게임을 할때 더 즐겁다라는 철학은 충분한 답이 되지 않을까 싶네요.

 

스마트폰 게임 해킹과 대응

웹진 기사 모음

Thisisgame : http://www.thisisgame.com/webzine/news/nboard/4/?sf=subject&sw=KGC&page=3&n=49762

발표 슬라이드 : http://www.slideshare.net/ChanhoSong/for-kgc2013

자세한 설명은 디스이즈게임 기자님이 너무 잘 써주셨습니다.

개발자분들도 신경써야 하는 내용이지만 QA팀에서도 참고 해야하는 내용이 있는 듯 합니다.

- 버전별 세이브 파일 호환성 검사 여부 기능

- 메모리 주소 검색 해킹툴 수집 및 사용 방법 숙지

- 주요 해킹 커뮤니티 모니터링 : 앱짱닷컴, 구글 검색 언제나 새로운 해킹 방법이 선보이기 때문에 모니터링을 통해 발빠르게 대처 할 수 있도록 해야 한다.

위 활동은 QA팀에서도 할 수 있도록 해야 할 것 같습니다.

중국 내에서 아이드림스카이가 높은 퀄리티의 게임을 퍼블리쉬 할 수 있는 노하우

웹진 기사 모음 없음

웹진에서 해당 기사를 찾을 수 없기에 들은 내용을 정리했습니다.

Image00037

아이드림스카이? (자회사 홍보)

- 50개 가량의 게임을 서비스 중 쿠키런(예정), 제트팩 조이라이드, 템플런2 등

- 3억 유저풀 보유, 많을때는 5만~ 30만 유저가 등록하며 10만 유저가 매달 유료 이용자로 전환되고 있다.

- 스마트폰 게임을 주력으로 하고 있다. (중국은 주로 모바일 게임을 한다.)

 

Image00046

 

Image00045

여기까지 자회사 홍보

중국 시장

- 안드로이드 75%, iOS 25% 정도의 점유율을 가지고 있으며 큰도시는 아이폰을 쉽게 볼 수 있지만 대부분은 안드로이드 폰을 사용한다. 걔중에는 아이폰을 닮은 짝퉁 아이폰도 많다.

- 유료 전환율이 10 – 25%로 높다.

- 온라인 (Clash of clan과 같은 게임을 온라인 게임으로 얘기했다.)은 남성 위주 하드코어 게이머가 주로 하며 캐쥬얼 게임은 여자나 아이들이 많이 한다.

- 자회사의 유료 전환율은 5~8% 정도

유저 확보를 위한 휴일 타켓 마케팅

- 신정: 중국에서 긴 휴일로 게임 발표를 신정으로 잡는다. 그래서 휴일 기간동안 유저 확보를 노릴 수 있다. 2주 동안 2000만 유저를 확보 한 적도 있으며 중국도 한국과 같이 민족 대이동이 있어 기차에서 게임을 많이 하기 때문에 인터넷에 연결 안해도 되는 퍼즐 게임을 주로 하게 된다.

- 발렌타인 데이: 짝을 찾는 사람들을 노리는 마케팅을 한다.

- 근로자의 날: 중국에서는 3번째로 연휴가 길다. 노동자(남자)들이 대부분 쉬면서 게임을 많이 하기 때문에 온라인 게임 유저가 많이 상승한다.

- 단오 : 중국의 중요한 명절로 연휴 기간이 길지는 않기 때문에 캐쥬얼 게임 유저가 늘어난다.

- 여름 휴가(방학) : 게임 유저들이 급증하는 기간이다. 게임 회사 매출의 절반이 이때 나온다고 한다.

- 칠석: 중국의 발렌타인 데이와 같다.

- 추석: 주로 밤에 유료화로 넘어가는 유저가 많다. 9월이 되면 매출이 줄어 들기 시작하는데 방학이 끝나는 학생들을 대상으로 하는 이벤트를 주로 하게 된다.

- 국경절: 중국에서 휴일이 가장 긴 기간으로 매출이 늘어나는 기간이기도 하다. 게임 광고 홍보가 많이 시행되지만 중국 대부분의 업체가 국경절을 노린 광고를 많이 하기 때문에 효과를 많이 보지 못하기도 한다.

- 크리스마스, 신정: 매출 영향이 크지 않다.

* 중국은 7월 ~ 9월의 매출이 가장 중요하다. 한 해중 해당 기간 동안에 매출을 충분히 올리지 못하면 다른 기간 동안에 만회하기는 어렵다.

 

중국 유저 분류

- Top tier: 재벌 2세, 벼락부자 같은 사람들 평균 일회당 10만원 가량의 돈을 사용한다. 옛날 MMORPG 시절에는 1억가량의 돈을 쓴 사람도 있다고 한다. 주변 친구들에게 영향을 주는데 20만원을 충전에 10만원은 본인이 사용하고 1만원씩은 직원들에게 나눠주어 같이 게임을 하고는 한다. 게임회사에서는 집중관리 대상이 되며 사용금액이나 폰을 바꾸는 주기가 빠른 사람을 찾는 식으로 찾는다.

- Mid tier: 화이트 칼라층, 똑똑하기 때문에 게임 선정에 까다로우나 평균 매출이 좋지는 않다. 그러나 주변 사람들에게 영향성이 크다.

- Low tier: 노동자, 경비원, 교도소 수용자(?), 아직 중국의 많은 사람들이 이 층에 속하고 있기 때문에 유저풀을 늘리는 중요한 층이다. 게임에 투자하는 비율도 화이트 칼라보다 높다. 타인의 영향을 받는 것도 적어 이탈율도 적으며 게임에 중독되기도 쉬워 접속 시간도 높다.

중국 퍼블리싱 포인트

- 게임의 용량이 작아야 한다.

: 중국의 통신망 사정은 매우 좋지않다. (아직도 2G를 쓰는 환경) 그렇기 때문에 클라이언트의 용량도 크면 안되며 패킷 사이즈 또한 작아야 한다.

: 클라이언트 크기는 50mb 이하가 좋으며 자사의 경우 100mb 이상은 퍼블리싱 계획 자체를 안한다고 한다.

Image00043Image00042

- 중국의 폰 호환성은 한국과 비교 불가하다. 한국은 삼성 갤럭시를 레퍼런스로 볼 수 있으나 중국은 중소기업 폰이 쏟아져 나온다. (사진 참조)

- 중국은 현금 구매 아이템을 구매해 게임 내 금전화 하는 것을 어려워한다. 현금으로 바로 게임 금전 아이템을 구매 할 수 있도록 해야 한다.

- 현금 구매만큼 네트워크에 열악한 환경이 없기 때문에 게임내 BM이 복잡한 것 없이 과감하게 현금 구매로 유도 시키는 것이 좋다.

- 해외 게임을 퍼블리싱 할 경우 로컬라이징도 중요하다. 중국 마켓에는 카피캣이 많기 때문에 저작권 관리에 도움이 된다. (자회사 홍보 문구인듯)

Image00044

 

해당 강연 내용은 여기까지입니다. 중간중간 통역하는 분이 내용을 먹거나 이해하지 못하고 바로 통역한 듯한 부분도 있어 저도 정리하는데 어려움이 좀 있었습니다. 개인적으로는 KGC 마지막 강연인 핫독 스튜디오 김민우 대표님이 발표하신 중국 시장 진출 내용과 통하는 내용도 있어 마지막날가서야 흥미로웠던 내용이었습니다.

 

1억명 데일리 플레이어의 사랑 받는 게임 만들기

웹진 기사 모음

인벤 : http://www.inven.co.kr/webzine/news/?news=64203

Thisisgame : http://www.thisisgame.com/webzine/news/nboard/4/?sf=subject&sw=KGC&page=4&n=49743

기대 강연중의 하나이다보니 웹진 기사가 상세하게 잘 작성되어 있습니다. 특히 Thisisgame 쪽을 추천합니다.

강연 내용 중 Depth 를 얘기하며 No spike 에 대해 얘기를 하는데 이 부분 설명은 웹진에도 없는 것 같아 추가합니다.

캔디 크러쉬 사가의 Grossing Rank를 확인해보면 Spike가 없다는 얘기를 하는데 말 그대로 유저들이 빠지거나 줄어드는 그래프 없이 일직선으로 죽 간다는 이야기 였습니다. 이런 지표를 만들기 위해서 게임 디자인을 지속적으로 추가해 수명을 늘리고 있는데 주력하고 있다는 점을 얘기하고 있었는데 퍼즐형의 게임 레벨 디자인이 쉬운 게임의 이점이 크게 들어나는 부분이라고 생각했습니다. 물론 그런것들이 반영된 캔디 크러쉬 사가가 잘 만든 게임이기도 합니다.

 

소프트웨어 개발에서 버그 관리의 모든 것.

웹진 기사 모음 없음

현재 블리자드에 재직중이신 박종천님의 강연. 사진도 못찍고 말이 너무 빠르셔서 정리하기가 어려웠다.

- 블리자드에서는 QA의 중요성을 개발자도 체험시키기 위해 개발자를 실제 CS 업무에 투입한다고 한다.

- 자신이 잘못짠 코드로 인해 유저가 어떤 피해를 입는지 그리고 그것이 CS팀에 어떤 영향을 끼치는지를 체험하고 자신이 만든 코드에 더 신경을 쓰게 된다고 한다.

- 당일 발생한 버그는 무조건 당일 처리하도록 하는 Zero bug 도 수행을 했는데 어차피 나중에 수정할 내용이라면 지금 수정하는게 맞다라는 인식에서 진행했다고 한다. 생산성에 문제가 있을것 같았지만 오히려 도움이 되었다고 한다. 현재도 Zero bug 까지는 아니지만 발생한 버그는 당일 수정하도록 하고 있다고 한다.

- 버그와 에러는 다르다.

- 버그는 혼자 사라지지 않는다.

- 모든 버그는 시간을 들여 수정해야 한다.

- 버그가 많이 발생하는 곳에는 문제가 있는 것이다. 그만큼 신경을 써야 한다.

- 에러를 잘 다루면 버그가 되지 않는다. (블리자드 게임을 하다보면 나오는 많은 에러 메시지들과 같은 관리에 대한 얘기)

- 에러 코드에 대해서는 지속적인 정리를 해야 하며 유저들이 스스로 고칠 수 있도록 도와야 한다.

- 자동화 테스트에도 많은 신경을 써야 한다. 어려운 영역임은 맞지만 야간 자동 빌드, log 모니터링등 쉽게 할 수 있는 영역도 있다.

 

Biowaer 개발의 QA 모델

웹진 기사 모음

Thisisgame : http://www.thisisgame.com/webzine/news/nboard/4/?sf=subject&sw=KGC&page=2&n=49780

인벤 : http://www.inven.co.kr/webzine/news/?news=64245

해외 거대 개발사 Bioware의 QA디렉터 튜레이 테이커의 강연.

어찌보면 첫 날 발표된 ‘게임QA로 살아가는 법’과는 사뭇 다른 강연이었다고 봅니다. 그만큼 해외쪽 게임 QA는 기술적으로나 문화적으로 앞서있다고 볼수도 있구요.

개인적으로 가장 마음 아펐다고 해야 하나.. 이직에 대한 내용이었습니다. QA는 개발의 한 문화다라는 생각을 하고 있는 요즘. 한 개발사, 한 회사에서 QA가 잘 정착 될 수 있도록 스며들려면 그 만큼 시간을 더 써야하지 않았나 하는 생각을 했습니다.

배고플때는 퀄리티에 대해 생각하지 않습니다. 배가 불러야 퀄리티에 대해 생각하게 되죠. 하지만 배가 부른지점에서 퀄리티를 생각하면 먹은 것들에 문제가 있었을수도 있고 결국 병치례를 하고야 퀄리티가 중요하다고 하게 됩니다. 그런점에서 모바일 게임회사를 선택한 이유가 되는 것 같습니다. 아직 배부르지 않지만 그래서 먹는 것의 퀄리티에 대해서 미리 생각 할 수 있어야 하지 않을까 합니다. 그래야 나중에 탈이 날 일도 없을거라구요.

QA의 커리퍼 패스등 앞으로의 역활에 대해 롤모델 삼을 좋은 얘기가 많았던 강연이라고 생각합니다.

 

모바일 게임 테스트, 어떻게 해야 하나?

웹진 기사 모음

Thisisgame : http://www.thisisgame.com/webzine/news/nboard/4/?sf=subject&sw=KGC&page=1&n=49805

Thisisgame.com 기자분이 진행한 내용이라 내용 정리가 잘 되어 있습니다. FGT를 어떻게 진행해야 하는가에 대한 내용이 주이며 수행 중 발생했던 사례들로 실패 하는 FGT에 대해서도 자세히 강연해 주셨습니다.

개인 의견

위에 설명된 FGT 방식으로도 검증 못하는 부분이 있습니다. 게임의 개발 의도가 어떤 타겟을 목표로 하고 있는지가 명확하다면 해당 타겟층을 모아 진행한 FGT를 결과가 유의미하겠지만 우리 게임은 남녀노소 다 즐길수 있는 게임이다를 검증하기에는 어려움이 있다고 봅니다. 그만큼 게임성에 대한 검증은 광범위한 영역을 다루는 것이라고 생각합니다.

게임성 검증을 위한 방법은 FGT 외에 좀 더 다양한 기법들이 나와야 된다고 생각합니다.

댓글을 달아 주세요

  1. dedukisa 2013.10.01 17:57  댓글주소  수정/삭제  댓글쓰기

    좋은 정리 잘 봤습니다. 올해 강연은 중복이 많아 아쉬웠지만, 그래도 여전히 좋은 강연이 많았던 것 같아요. =)

    p.s - 사족이지만 스마트폰 해킹 기사는 디스이즈게임인데 설명이 인벤으로 되어 있네요.. ^^;

  2. NeoZest 2013.10.03 01:29  댓글주소  수정/삭제  댓글쓰기

    게임 QA 세션도 링크가 잘못되어 있네요 :)

Posted by 김포프

스티브가 KGC 2012에서 강연했던 The Producer란 강연입니다. 부제는" 최대로 효과적인 프로듀서 되기"이군요.


스티브가 아직까지 안올렸기에 허락을 받고 제가 올리는 겁니다 ^_^


스티브는 올해에도 KGC에 강연하러 옵니다 ^_^/




TAG 포프

댓글을 달아 주세요

  1. Favicon of http://blog.naver.com/takkyungmo 탁경모 2013.09.30 16:50  댓글주소  수정/삭제  댓글쓰기

    아!! KGC 강연 잘 들었습니다!
    그리고 사인도 정말 감사드립니다 ^^
    고등학생이라고 열심히 하라고 적어주셨는데 ㅎㅎ 아직도 생생하게 기억나네요!

Posted by 비회원

사운드 디렉터와 PD와의 사례

보통 피디분들은 사운드에 크게 관심을 주기도 하지만, 디테일한 것을 함께 잡아가진 않습니다.

다양한 분야를 담당해야 하는 만큼, 기본적인 것은 제시하지만, 그 이후는 보통 믿고 맡기는 스타일의 PD분들이 많은 점을 감안해, 이번 편을 작성했습니다.


큰 그림을 제시 하고, 거기에 맞는 요소들을 사운드 디렉터가 파악하고, 관련 자료들과 함께 결과 보고 하는 방식이 주를 이루며,
사운드 디렉터가 제안을 먼저 하는 경우는, PD가 검토 후, 진행 또는 다시 제안을하는 것으로 마무리 되어집니다.
서로 신뢰하고 있다면, 더더욱 할 얘기는 많지 않습니다. 비교적 다른 파트에 비해 내용이 간단하네요

아래는 MMORPG 개발을 바탕으로 이야기를 해본 사례 입니다.

1. 유저 이탈을 방지 하도록 하기위한 대책중, 사운드에서 취해야 할 것
     PD: 유저들이 지루해 하지 않도록, 중간 중간 쉬거나, 다른 장면을 보여주면서, 일종의 환기를 시켜야 할 것 같습니다. 
   피로에 대한 보상 같은 개념을 사운드 쪽에서 지원이 가능할 까요?

     SD: 음악이나 환경들을 유저의 상태와 환경에 맞춰서 재생을 하면 좋을 텐데요. 
            세부 기술내용은 프로그램팀과 기획팀과 협의하겠습니다.
            요즘은 유저 상황에 따라 연출 하는 케이스가 많이 있으니, 어렵진 않을듯 하네요.

2. 연출에 필요한 요소들과 구현이 필요한 것들, 효과분석
     PD : 얼마전 유저 상황에 따른 연출을 각 파트별로 얘기 해봤는데, 기대만큼 큰 효과가 있을지 모르겠네요
     SD : 참고가 될 자료들 취합해서 공유드리겠습니다. 

3. 해외 서비스를 위해선 최적화가 필수인데
     PD : 사운드 용량이 그래픽 리소스 다음으로 많은데, 어떻게 하면 좋을까요?
     SD : 사운드 엔진을 활용해서, 최소한의 리소스로 다채로운 효과를 주도록 하겠습니다.

4. 게임 몰입도를 높일 방법
     PD : 보상과 위기감을 주는 방법을 사용해서 유저들과 밀당을 기회팀쪽에서 제안했습니다 여기에 더 재미있는 것 없을까요?
     SD : 두가지 상황을 모두 극적으로 느낄 수 있도록 음악, 사운드 연출을 하겠습니다.


결국, 원하는 것을 들려주거나, 눈에 보이는 것과 합처야 하는 과정이 포함되어 있습니다.
사운드의 전문가들이 아니니까요, 명확한 방향을 사운드 디렉터가 제시를 해야 하는 경우가 생각보다 많이 있어서, 
필요할 경우엔 바로 사운드 관련자료를 전해 줄 수 있도록, 항상 준비하고 있어야 합니다.

요즘은 구글링, 유튜브에 양질의 자료들이 많이 있어서, 업무에 도움이 많이 되고 있습니다.
심지어, BGM 저장소 라고 부르는 사이트들도 좋은 참고가 됩니다. 



다음은 예산과 개발 로드맵 최전선에 계신 분들과의 업무 사례 입니다.


사운드 디렉터와 PM과의 사례

예산에 맞춰서 시간과 비용을 효율적으로 사용하기 위해 계획을 해 나가는 분들이라, 
아트쪽에 가까운 사운드 분야의 사람들과는 특성이 좀 다른편입니다 :) 
다행이 다른 개발 파트에 비해, 사운드 파트가 비용면에서 크게 지출이 되진 않는 분야이지만, 
최근 들어서 투자 대비, 효과를 크게 볼 수 있는 파트로 자리 잡아가고 있어서, PM분들의 압박이 점점 강해지고 있습니다(?)

제 경험상, 친숙하지만 때론 혼내기도 하는 어머니 같은 분들이 많이 계시더군요.  

1. 개발 기간과 비용을 합리적으로 꾸려 나갈 수 있는 로드맵 제시.
     PM: 프로젝트 제작 기간동안 발생할 음악, 사운드 쪽 예상비용과 인력을 알려주세요.
     SD: 내부에서 처리할 것과, 외부로 해결 할 것을 파악 후, 견적서, 단가표 전달

2. 다른 파트와의 협업에서 얻을 수 있는 장점을 최대한 살리기
     PM: 각 파트의 핵심 인력들과 사운드 디렉터를 소집하고, 사운드 회의를 진행
     SD: 각 파트에서 해결이 필요한 내용들 확인해서 조치

3. 고무줄 처럼 밀리고 땡겨지는 일정에서 사운드 및 음악 제작시간을 최대한 효율적으로 사용하는 방법

     PM : 영상이 나오는 시점에 사운드나 연출이 들어가게 되므로, 미리 진행 할 수 있는 부분을 확인 해주세요.
     SD : 콘티를 보고 미리 리소스 준비, 음악이나 효과들 들어갈 타이밍 예상해서 제작 

4. 새로 제작되는 지역의 배경 음악과 사운드에 다른 느낌을 주고 싶을때
    PM :  이번 지역 테마는 왜 녹음이 필요하죠?
    SD :  지역색을 강조해달라는 기획팀의 요청에서, 해당 지역의 민속 악기를 넣으면, 분위기가 더 살아날 거라 생각합니다.

어디에 얼마나 비용이 투입되고 있고, 그 효과를 내기 위해, 적당한 비용이 들어가고 있는지, 
혹시 불필요한곳에 집중하고 있는 것인지, 항상 꼼꼼하게 체크를 하다보면, 사운드 쪽과 종종 의견이 부딧히는 부분이 발생하곤 합니다

디테일과 품질 향상도 중요하지만, 그보다 신경써야 할 곳을 판별하는 눈, 그리고 개발 예산에서 낭비되는 곳이 없도록 조율을 하려는 PM분들의 노고가 숨어 있습니다  쪼임을 당한다고 슬퍼하지 마시고, 사랑받고 있다고 생각하시면 이곳이 천국입니다.  :)





댓글을 달아 주세요

C++ Coroutine

프로그래밍 2013. 7. 26. 19:00
Posted by 비회원


Coroutine이란?

프로그램이 실행될때 불려지도록 만들어진 프로그램의 중심이 되는 일련의 코드들을 Main Routine(메인 루틴) 이라고 하며, Main Routine외에 다른 Routine들을 모두 Subroutine(서브루틴) 이라고 합니다. 그리고 진입하는 지점을 여러 개 가질 수 있는 Subroutine을 Coroutine(코루틴) 이라고 합니다. Coroutine은 호출한 Routine을 대등한 관계로 호출할 수 있기 때문에 다른 Routine의 종속관계가 아니라고 표현하기도 합니다.

C++에서는 main함수가 Main Routine이고 그 외에 다른 함수들은 모두 Subroutine이라고 볼 수 있습니다. 따라서 Coroutine은 함수 내에서 호출한 쪽을 다시 호출할 수 있고 다시 다른 Routine에서 함수의 중간 지점을 호출할 수 있는 것이라고 할 수 있습니다.

Main Routine과 Subroutine


Coroutine



Coroutine은 Thread와 비슷하다?

보통 Coroutine을 Thread와 비슷한 개념이라고 말하기도 하는데, 저는 이것이 Coroutine을 이해하기 어렵게 만든다고 생각합니다. 결과적으로 보면 비슷한면이 많습니다. Thread와 Coroutine 모두 자신만의 스택이 존재하고 실행 순서를 가집니다. 하지만 Coroutine은 Thread가 아닙니다.

Thread란 프로그램 내에서 실행되는 흐름의 단위를 말합니다. 모든 프로그램은 최소 하나의 Thread를 가지며, 이 Thread를 Main Thread(주 스레드)라고 합니다. 그리고 이 Main Thread에서 Main Routine이 불려집니다. Thread는 흐름의 단위이기 때문에 새로운 Thread가 만들어졌다는 것은 새로운 시간 흐름이 만들어졌다고도 볼 수 있습니다. 이렇게 프로그램은 여러 개의 Thread를 동시에 실행할 수도 있고, 이것으로 인해 일종의 흐름이 동시에 진행될 수 있습니다. 이러한 실행 방식을 Multithread(멀티스레드)라고 합니다. 

즉, 독립적인 시간 흐름을 가지고 Routine을 실행하는 것이 바로 Thread인 것입니다. 그래서 보통의 Routine들은 시작부터 끝까지 하나의 Thread에서 실행되지만 Coroutine은 호출자를 다시 호출할 수 있고 진입 지점을 여러 개 가질 수 있다는 특성 때문에 여러 Thread에서 하나의 Coroutine이 실행될 수 있습니다. 이러한 특성 때문에 Coroutine이 비동기 로직 처리에 유용하게 사용될 수 있습니다.


C++ 에서의 Coroutine

Coroutine을 지원하는 언어는 상당히 많지만 C++은 Coroutine을 정식으로 지원하지 않습니다. 하지만 C++에서 Coroutine을 사용하기 위한 많은 시도가 있었으며, 그 중 대표적으로 boost 라이브러리에 포함된 Coroutine(1.53 버전부터 포함)이 있습니다.  boost는 Coroutine을 구현하기 위해 스택을 만들고 점프할 수 있는 기능을 가진 boost Context를 사용합니다. 



Context Switching 비용이 너무 커서 부담스럽다?

Context Switching은 보통 Thread와 밀접한 관계를 가지고 있습니다. 위에서 Thread는 독립적인 시간 흐름을 가지고 Routine을 실행하는 것 이라고 했는데, Thread가 하나 존재한다면 Routine이 하나의 시간 흐름속에서 실행이 되는 것입니다. 그렇다면 이러한 Thread가 100개 존재한다면 어떻게 실행되어야 할까요?

100개의 Thread가 모두 독립적인 시간 흐름을 가지기 때문에 100개의 Routine이 모두 동시에 실행이 되어야 합니다. 하지만 우리가 보통 사용하는 컴퓨터 환경은 그렇게 동작하지 않습니다.

Routine은 어떠한 작업을 수행하기 위한 명령어들로 이루어져있는데 이 명령어들을 해석하여 연산하는 것이 CPU 입니다. CPU는 여러 개의 Core를 가지기도 하는데 이 Core 개수만큼 동시에 연산을 할 수 있다고 생각할 수 있습니다. 따라서 Core가 하나인 CPU이면 동시에 처리할 수 있는 연산은 하나입니다. 따라서 100개의 Thread가 동시에 연산되려면 100개의 Core가 필요한 것입니다.

그래서 우리가 흔히 사용하는 OS들은 OS가 Thread의 CPU 점유를 제어하여 실행될 수 있도록 합니다. 한정된 자원을 분할해서 수백개의 Thread가 동시에 실행될 수 있도록 하는 것입니다. 이 과정에서 Thread들은 CPU 자원을 차지하기 위해 경쟁을 하게 되고 그렇게 CPU 자원을 선점한 Thread가 Routine을 실행할 수 있는 것입니다. 이것이 Preemptive Multitasking(선점형 멀티태스킹)입니다.

Preemptive Multitasking에서는 어느 한 Thread가 CPU 자원을 독점할 수 없기 때문에 모든 Thread가 계속 경쟁을 해서 CPU 자원을 선점하게 되고, Thread가 CPU 자원을 선점하면 다른 Thread는 실행이 중단될 수 있습니다. 이렇게 CPU 자원을 선점하는 과정에서 이전에 CPU 자원을 사용하고 있던 Context의 정보를 저장하고 새로 선점한 Context의 정보를 가져오는 것을 Context Switching 이라고 합니다.

Context Switching은 독립적인 정보를 가지고 명령어를 실행하기 위해 생기는 현상입니다. Thread처럼 C++에서의 Coroutine은 독립적인 정보를 가져야 합니다. Routine이 중간에 빠져나갔다가 다시 호출되었을 때 이전에 Coroutine에서 생성한 로컬 변수나 연산들이 정상적으로 동작해야 하기 때문입니다. 그래서 C++에서의 Coroutine은 독립적인 Stack을 가집니다. 그리고 Coroutine을 호출하거나 빠져나가거나 할 때마다 Context Switching이 일어납니다.

Context Switching을 하는 데에는 확실히 비용이 들어갑니다. 하지만 제 생각에 Coroutine에서 발생하는 Context Switching은 OS에서 실행할 Thread를 관리하는것처럼 Routine을 어떻게 실행시킬것인지 결정하는 일종의 관리 대상으로 봐야 한다고 생각합니다. 따라서 C++ Coroutine에서 발생하는 Context Switching 비용은 관리가 가능합니다. 필요없는 Context Switching은 문제가 되겠지만 그렇지 않은 Context Switching은 부담스럽다고 생각하지 않습니다. 그리고 특히 boost Context의 Context Switching은 현재의 컴퓨터 기준으로 보면 그렇게 부담스러운 작업은 아니라고 보여집니다. x86 CPU의 MSVC 환경에서 어떻게 이루어지는지 간단하게 보면 다음과 같습니다.


먼저 Context 정보를 저장하기 위해 fcontext_t라는 구조체를 사용합니다.

시작은 현재 Context 정보를 저장할 fcontext_t의 주소를 가져옵니다. 그리고 순서대로 EDI, ESI, EBX, EBP 레지스터를 저장합니다.

그리고 이어서 Switching 명령을 하기 전 원래 Routine에서의 ESP 레지스터를 저장하고, 마지막으로 Context Switching 시에 점프할 위치(호출한 다음 위치)를 저장합니다. 참고로 EIP는 실행될 다음 명령어의 주소를 가지는 레지스터로 점프할 위치로 점프 명령을 수행하면 EIP는 그 다음 명령어의 주소를 가지게 될 테니 따로 저장할 필요가 없습니다.


그리고 Switching할 Context의 정보를 가지고 있는 fcontext_t 주소를 가져옵니다. 마찬가지로 순서대로 EDI, ESI, EBX, EBP를 읽어옵니다.


boost Context는 FPU(부동 소수점 장치)를 보존할 것인지 여부를 설정할 수 있으며, 보존하는 경우 추가로 현재 FPU 정보를 저장하고 Switching할 Context의 FPU 정보를 읽어옵니다.


그리고 ESP 레지스터를 읽어오고, 점프할 위치를 읽어와서 ECX에 저장합니다.


마지막으로 jmp 명령어를 통해 Switching할 Context로 점프를 하는 것으로 대략적인 Context Switching 과정이 끝납니다.


이렇게 boost Context의 Context Switching 과정은 상당히 간단하게 처리되며, 비슷한 과정을 수행하는 Windows Fiber등과 비교했을때 훨씬 빠릅니다. boost Context의 설명페이지에서도 Context Switching 퍼포먼스 정보를 다음과 같이 표시하고 있습니다.



그럼 C++에서의 Coroutine은 아무런 문제가 없는 것인가?

그렇다고 해서 C++에서의 Coroutine을 아무렇게나 마구잡이로 만들어서 사용하는 것은 위험할 수 있습니다. C++에서 제대로 된 Coroutine을 구현하려면 한가지 문제가 있습니다. 바로 일정 크기의 Stack을 미리 할당해두어야 한다는 것입니다. 그리고 이렇게 할당된 Stack은 대부분의 경우 Stack 메모리를 모두 사용하였을때 늘릴 수 없습니다. 그래서 Coroutine을 처음 생성할 때에 충분히 큰 메모리를 할당해두고 사용하게 됩니다. Coroutine을 한두개 생성하는 정도라면 Thread처럼 1MB씩 Stack을 할당해서 사용해도 충분하겠지만 수백, 수천개씩 만들어야 하는 경우라면 메모리를 크게 할당할 수 없을 것입니다. 그래서 boost Coroutine의 Stack 메모리 기본값은 Windows인 경우 64kb로 되어있습니다. (64kb를 기본값으로 하는 이유는 최대한 작은 크기로 할당하면서 가장 효율적인 사이즈가 64kb이기 때문인 것 같습니다. 그 이유는 Allocation Granularity Boundary(할당 임계 영역) 때문인데, 이것은 메모리 할당의 시작 주소가 될 수 있는 기본 단위입니다. 따라서 64kb보다 더 작은 사이즈로 할당하는것은 메모리 조각화를 발생시키는 요인이 됩니다.)

Coroutine안에서 하는 일이 많다면 64kb보다 더 크게 할당해야 하는 경우도 생길것이고, 만약 Coroutine을 수만개까지 만들어야 하는 상황이 생긴다면 64kb라고 해도 부담될 수 있을 것입니다.



C++은 왜 Stack을 키우는 것이 어려울까?

메모리가 모자를 때 2배씩 재할당하는 방법은 흔히 메모리를 키워나가는 방식입니다. 간단하게 생각해보면 Stack Overflow가 발생하는 상황에 메모리를 재할당 받고 복사하는 방법으로 구현할 수 있을 것 같습니다. 이런 방식으로 동작하는 대표적인 예로 std::vector가 있습니다. std::vector의 경우 재할당을 받게 되면 객체의 복사생성자가 호출되며 복사가 이루어집니다. 

그런데 이 방식에는 문제가 있습니다. C++ 객체 모델에서는 타입 메타 데이터 없이는 객체의 복사 생성자를 호출할 수 없고, 따라서 제대로 된 복사를 수행할 수 없습니다.  예를 들어 타입 메타 데이터 없이 memcpy같은 방식으로 복사를 수행하게 되면 Stack에 int a; int* b = &a; 이렇게 값이 올라가 있는 경우 재할당 후에 복사를 하고 나면 b는 다른 Stack 위를 가리키게 되는 문제가 발생합니다.

그렇다고 해서 Stack을 키우는 것이 아예 불가능한 것은 아닙니다. gcc 4.6의 경우 Split Stack 이라는 것을 지원합니다. 말 그대로 Stack을 분할하여 사용하는 것입니다.

일반적으로 함수 호출에 의해 Stack이 사용되는 과정은 호출 규약에 따라 조금씩 다르지만 일반적으로 다음과 같이 진행됩니다.


함수 호출을 몇 번 하는 간단한 코드를 예를 들어 설명해보도록 하겠습니다.



testfunc()을 호출 하면 Stack에는 오른쪽 그림과 같이 인자값과 main()으로의 복귀 주소가 쌓이게 됩니다

testfunc()으로 들어오면 이 위치에서 testfunc()이 사용하는 Stack의 크기만큼 Stack 영역을 확보합니다.

그리고 이 위치에서 확보된 Stack 영역을 초기화합니다.

다시 testfunc2()를 호출하면 main()에서 testfunc()을 호출했을때와 마찬가지로 인자값과 testfunc()으로의 복귀 주소가 Stack에 쌓입니다.

testfunc()처럼 testfunc2()로 들어오면 역시 사용할 크기만큼 Stack 영역을 확보합니다.

Split Stack은 함수가 호출된 시점에 해당 함수에서 사용되는 Stack의 크기만큼 확보할 때에 할당된 영역을 넘었는지 검사하고, 이때 할당된 영역을 넘었으면 새로운 Stack을 할당하여 호출에 의한 인자값 등 해당 함수에서 필요한 데이터들을 새로 할당받은 Stack에 복사하는 형태로 구현됩니다.

testfunc2()에서 사용할 크기만큼 Stack을 확보하려 할때에 만약 할당된 메모리가 부족하다면 여기서 판단할 수 있을 것입니다.

이때 새로운 메모리를 할당하고 해당 함수에서 사용할 데이터들만 새로운 Stack에 새로 쌓으면 문제없이 실행될 것 같습니다.

Split Stack은 함수 호출 규약의 종류가 많고 컴파일러 마다 다르게 처리되는 호출 규약도 존재하기 때문에 라이브러리 수준에서 구현하는것은 어렵습니다. 따라서 컴파일러에 의존적일수밖에 없습니다. 현재는 gcc 4.6 에서만 구현되어있고 LLVM쪽에서는 움직임이 있다고는 하지만 MS에서는 여러가지 문제로 인해 아무래도 지원하지 않을것 같습니다. 그리고 Split Stack은 구현 방식에 의해 어쩔 수 없이 미묘하게 성능 저하도 발생하는데 이러한 문제들로 인해 C++ 표준에 들어가는 것도 쉽진 않을것으로 예상됩니다.

boost Coroutine은 컴파일러가 Split Stack을 지원한다면 해당 기능을 사용할 수 있도록 작업되어있습니다. 현재 boost 1.54 버전에서는 gcc 4.7 이상 버전인 경우 Split Stack을 지원합니다.



결론

C++에서 Coroutine을 사용하는 경우에는 Context Switching 비용을 기반으로 Coroutine의 생성 및 관리를 하는 것 보다는 해당 Coroutine에서 사용되는 Stack 사이즈를 기반으로 관리를 해야 할 것 같습니다. 이러한 관리만 잘 된다면 C++에서도 마음놓고 Coroutine을 문제없이 사용할 수 있지 않을까요?




참조 : 
WINDOWS VIA C/C++
http://www.boost.org/doc/libs/1_54_0/libs/coroutine/doc/html/index.html
http://blogs.msdn.com/b/oldnewthing/archive/2003/10/08/55239.aspx
http://www.sco.com/developers/devspecs/abi386-4.pdf
http://gcc.gnu.org/wiki/SplitStacks


도움을 주신 분들 :
박민철님(@summerlight00), Ted님(@booiljoung), 양승명님(@sequoiaxp), 이현정님(@Blackscomber)


ps. 잘못된 내용이 있는 경우 지적해주시면 수정하도록 하겠습니다!!

댓글을 달아 주세요

  1. 도플광어 2014.02.17 14:04  댓글주소  수정/삭제  댓글쓰기

    좋은글감사합니다.^^;
    첫번째 댓글이네요

  2. jun 2014.02.17 15:19  댓글주소  수정/삭제  댓글쓰기

    좋은글 감사합니다 _^

  3. jacking 2014.02.17 16:04  댓글주소  수정/삭제  댓글쓰기

    스택 확장에서 복사하는 것이 문제라면 C++11에서는 무브세멘틱스 기능이 있는데 이걸 사용하면 해결 할 수 있지 않을까요? boost 1.55 버전이나 항후 어떻게 해결할지 궁금하네요^^

    • 알 수 없는 사용자 2014.02.17 21:47  댓글주소  수정/삭제

      분할 스택이 아닌 스택 확장의 경우 복사가 문제이긴 하지만 위의 경우에는 C++11의 무브세멘틱스는 해결책이 되지 못합니다. 본문에서도 예를 들었던 것처럼 스택메모리에 int a가 선언되고 int* b = &a; 이런 형태로 스택메모리에 쌓여있는 경우 새로운 스택메모리를 할당하고 복사할 때에 스택메모리에 쌓인 데이터들의 메타데이터를 알 수 없기 때문에 스택메모리 전체를 복사할 수밖에 없습니다. 이렇게 복사가 되면 b는 지워질 스택의 메모리를 가리키게 되고 잘못된 동작을 하게 될 것입이다. 무브세멘틱스를 이용할 부분이 아예 없는것이죠..

    • 알 수 없는 사용자 2014.02.17 21:50  댓글주소  수정/삭제

      C++에서 해당 문제를 해결하기 위해서는 gcc에 포함된 분할스택이 가장 현실적인 해결책이라고 생각됩니다. 이 분할스택이 C++ 표준에 들어가게 된다면 C++에서도 코루틴의 시대가 열릴것이라고도 생각합니다. 물론 가능성은 별로 없어보이지만요.. 표준에 포함이 되지 않더라도 msvc에서 구현을 해준다면 좋겠지만 요즘 ms는 C#을 적극적으로 밀고 있으니 아마도 포함되진 않을것 같고요..

  4. luna1x 2014.02.17 17:16  댓글주소  수정/삭제  댓글쓰기

    좋은글 잘 봤습니다.^^

  5. 알 수 없는 사용자 2014.02.17 21:39  댓글주소  수정/삭제  댓글쓰기

    반년도 넘은 글에 드디어 댓글이 달렸네요 감사합니다 ㅋㅋ 구걸해서 댓글 받은 기분이긴 하지만요..

  6. mog422 2014.02.18 07:17  댓글주소  수정/삭제  댓글쓰기

    좋은글 잘 읽었습니다

  7. jacking 2014.02.18 08:46  댓글주소  수정/삭제  댓글쓰기

    끼로 // 아마 비슷한 것이 C++ 표준에 들어갈겁니다. 현재 C++17(차기 C++ 표준)에 MS가 자사의 C#에서 지원하는 async/await와 비슷한 __resumable/__await를 제출한 상태입니다. 현재 VS 2013 CTP을 설치하면 테스트 해 볼 수도 있습니다. 이것은 비동기 프로그래밍을 위한 것이라서 다른 스레드로 작업을 넘기는게 지금의 콜루틴과 크게 다르겠네요.

    • 알 수 없는 사용자 2014.02.18 10:22  댓글주소  수정/삭제

      이름에서부터 코루틴의 느낌이 나네요! 좋은 정보 감사합니다 ㅎㅎ