NDC 간략한 참관기 #1

개발 2011.06.04 17:00

 저번 주 내내 NDC를 참관했는데, 기억이 흐릿해지기 전에 몇몇 세션에 대해 글로 정리해본다 강연의 정리는 다른 분들이 잘 해놓으셨으니 개인적인 수준의 감상만 남김. 강연 요약본이 아니니 강연 내용 자체를 원하셨던 분들께는 죄송. 들었던 세션 전부를 정리하는 건 아니고, 정리해 볼 만한 의견이 있는 경우만 정리해본다.



 구세대 개발자의 신세대 플레이어를 위한 게임 만들기 (김동건 본부장 / 넥슨)

 ( 관련 링크 : NDC 공식 블로그, NDC 2011의 강연 노트를 모아보아요! (05월 30일) )

 우선은 Entry age의 확보에 대한 강조로 시작했는데, 새로 게임을 시작하는 유저에 대한 강조는 이미 닌텐도부터 시작하여 수 많은 게임 회사들이 강조하지만 그걸 실제 게임 디자인까지 반영시키는 경우는 그리 많지 않은 것 같다. 그 이유는 보통 게임 개발자들이 자신에게 재미있는 게임을 만들려고 하기 때문인데, 이를 정확히 짚어냄. 닌텐도가 Wii로 성공한 까닭이 바로 그 지점이고. 개인적으로는 Wii Sports가 개발자와 유저의 괴리를 잘 보여주는 지점이라고 생각한다. 이 게임은 메타 크리틱 점수가 평균 76점으로 닌텐도 게임 치고는 최악의 평가를 받았음에도, 판매고는 거의 8000만장에 육박.

 다만 충성 고객에 대한 언급이 부족한 것은 조금 의아했다. 아마 PT의 주제를 흐리지 않을까 걱정한 게 아닐까 싶은데, 그래도 언급할 가치는 있지 않았을까? Wii는 신규 유저 창출에 극단적으로 올인한 케이스인데, 분명 잘 나가긴 했지만 파급 효과에 비해 지속력이 떨어져 한 순간의 바람이 되어 버렸다. PT에서 언급하고 있는 20%의 이탈률은 아주 충성률이 높은 경우라고 생각하는데[각주:1], 여기에 대해서도 어느 정도 이야기는 하는게 좋지 않았을까.

 이후 이어진 게임 디자인적인 관점은 대공감. 새로운 게임 메커닉에 대한 천착으로 인해 망한 온라인 게임의 수는 셀 수도 없고, 반대로 새로운 게임 경험의 도입/구시대적 게임 경험의 척출을 거부하다가 뒤쳐진 게임들도 많다. 이제 중요한건 어떻게 플레이하느냐가 아니라 그게 재미있느냐라는 이야기. 게이머 커뮤니티인 루리웹에서 나온 루까성[각주:2] 같은 단어는 이러한 내용들이 하드코어한 게이머들에게도 느껴질 정도로 대세가 되었다는 의미도 될 수 있지 않을까?

 와우 패치의 역사를 보면 이런 방향성이 느껴지는데, 간단한 어그로 미터의 도입이라거나 퀘스트 라인의 일직선화, 퀘스트 목표를 지도에 표시, 던젼 도감의 도입 등 가장 핵심적인 게임 플레이를 제외한 다른 잡다한 요소는 전부 쳐내고 게이머로 하여금 중요한 게임 경험에만 집중하도록 발전하는 것을 볼 수 있다. 게임 디자인에 있어서 한국과 해외의 가장 큰 차이라면 이런 부분이 아닐까 싶었는데, 역시 탑 레벨 스튜디오는 트렌드를 아주 빠르게 따라가는구나 싶었음.

 근데 문제는 이 쪽만 따라가면 또 안 된다는거다. (...) 일반론적으로는 새로운 게임 유저들이 지속적으로 유입되는 것도 중요하지만, 이게 온라인 게임으로 가면 그 유저들이 계속해서 남는 것 역시 중요하다. 여기에는 하드코어 게이머들이 만들어내는 이야기와 커뮤니티의 역할이 무척 큼. 그리고 그 하드코어 게이머를 잡아내려면 탄탄한 게임 플레이와 하이엔드 컨텐츠가 있어야 한다. 와갤과 용개가 없었다면 한국에서 와우 커뮤니티는 반토막 나지 않았을까? 상충되는 두 목표를 함께 잡아내기는 참 어려울텐데[각주:3] 여기에는 어떤 답을 냈을지 궁금...



 영웅전 액션 시스템:기민하면서도 다채로운 액션 프로토타이핑 (박영준 / 넥슨)

 ( 관련 링크 : NDC 2011의 강연 노트를 모아보아요! (05월 30일) )

 궁극적으로 게임 플레이 프로그래머를 지향하는 입장에서 무척 재미있게 봤던 세션. 기술이 발전하고 게임 플레이에 대한 요구 레벨이 점차 올라가면서 게임 플레이와 프레젠테이션 레이어 사이의 경계가 모호해지는 추세다. 조금 더 정확히 말하자면 전통적으로 프레젠테이션 레이어에서 담당하던 영역이 은근슬쩍 게임 플레이로 넘어오고 있다. 그 이유야 조금 더 직관적인/사실적인 게임 플레이를 위해서고...

 특히나 애니메이션이 그런 경향이 있는 것 같은데, 이렇게 될수록 게임 플레이 프로그래밍은 점점 고달퍼질 것으로 예상된다. 물리니 IK니 하는 절차적 애니메이션 기법들이 끼어들어가는 와중에 또 이걸 어색하지 않은 애니메이션으로 잘 맞춰주는게 꽤 어려운 일이라고들 하는 것 같다. 근데 나는 여기에 대해 아는게 거의 없다는 문제가... (...)

 어쨌든 나름 성공적으로 서비스하고 있는 마영전에서는 여기에 대해 어떤 접근을 취했는지에 대해 다루는데, 기본적으로는 액션 자체를 데이터 드리븐하게 다루고 여기에서 발생하는 이벤트를 적당한 애니메이션을 연동시키는 방향... 으로 이해했다. 아직까지 PT가 올라오지 않은 상황이라 정확히는 기억은 못하겠지만. 이렇게 기반을 만들고 실제 컨텐츠를 만들어 내는 사람들이 실제 액션을 작업하면서 필요한 기능을 프로그래머들에게 요청하는 형태인 듯.

 놀랐던 건 이런 기반 시스템을 베타 3개월 전에 뒤엎어서 만들었다는 점. 라이브하는 게임을 뒤엎은 것과 다를 바가 없는 일인데, 이걸 해냈다. 물론 그 이유는 생산성이다. 사실 논리적으로 생각해보면 이게 올바른 길이 맞는게, 앞으로 엄청난 수의 컨텐츠를 만들어 내야 하는데 개발 프로세스가 병목이 되어 이터레이션 자체가 안 되는 상황이라면 이걸 뜯어 고치는게 당연한거다. 보통 이런 문제는 나중에 갈수록 고치기 점점 힘들어지고, 가장 싼 값에 고칠 수 있는 시점은 당장인 경우가 많다.
 
 허나 현실적으로 "무슨 일이 일어날지 모르니까" "여태까지 잘 되던건데 꼭 고쳐야 하나" "문제되면 그 때 고치지" 같은 방어적/수동적인 생각들이 없을 수 없다. 하지만 이건 비용에 비해 이득이 작아 안 해도 될 정도로 사소한 일인 경우나 시간이 지나도 문제가 심각해지지 않을 경우에나 적용될 말이고, 근본적인 부분의 문제라면 가능한 이른 시일 내로 작업에 들어가는게 맞다고 본다. 그런 관점에서 이 사례는 확신만 있다면 문제점을 안고 가는 것보다는 이를 근본적으로 해결하는게 맞는 일이라는 증명이 되어줄 듯 하다. 2일차 박종천씨의 세션에서도 한 번 언급된 내용이지만, 사소하지만 긴급한 일보다는 중요하지만 긴급하지 않은 일이 우선.


 
 메이플 스토리 : 잘되는 게임을 위한 라이브 코어 개발 (황의권 / 넥슨)

 ( 관련 링크 : rein's worldNDC 2011의 강연 노트를 모아보아요! (05월 30일) )

 또 하나의 좋았던 세션. 사실 NDC 세션 중에서 별로였던 세션은 몇 개 없었지만. 여기에서는 크게 라이브 서비스에서의 혁신과 개선, 이 두 가지 내용에 대해 다루었는데, 이제 막 업계에서 일하기 시작한 뉴비로써 배울 게 굉장히 많았다.

 게임 업계에서는 라이브 서비스를 좋아하는 사람도 있겠고 싫어하는 사람도 있겠지만, 내 경우는 프로젝트에 대한 컨트롤이 안 된다는 점 때문에 라이브 유지보수를 별로 안 좋아한다. 일단은 자기가 짠 코드가 아니라 함부로 코드를 고친다거나 하기가 어렵고, 그 비용을 예상하기가 어렵다. 엄청난 분량의 레거시가 잔뜩 쌓여 있는 상황에서는 작은 수정에 들어가는 비용도 신작에 비해 훨씬 크다. 게다가 팀의 분위기도 가능하면 사고나 치지 말자~ 이런 경우도 많고. 능력자 입장에서 하고 싶은 건 많은데 현실이 안 받쳐주는 경우 그냥 모럴이 붕괴해버리는 결과도 많을 것이다.

 세션과는 무관하게 여기에 대해서는 할 말이 참 많은데 (...) 코드의 의도를 설명하는 주석이나 가능한 경우 기초적인 단위 테스트 작성 정도는 후에 해당 코드를 유지보수할 사람에 대한 최소한의 예의다. 조금 더 욕심을 부리자면 더 좋은 코드를 - 사이드 이펙트가 적고 구조화, 모듈화가 아주 잘 되어 있는 등 - 작성하는게 좋겠지만, 이건 개개인의 능력에 달린 일이니 강요할 수는 없다. 하지만 앞에서 말한건 최소한의 의지만 있어도 할 수 있는 일인데 이조차 안 한다는 것은 그냥 배려가 없다는 이야기.

 이 세션을 들으면서 느낀 점 중 하나가 발표자 분이 이런 모럴적인 부분에 대해 경험적으로든 직관적으로든 잘 이해하고 있다는 점이었다. 특히나 지금 현재 상황이 더 나아지고 있다는 느낌을 주는게 중요하다는 점을 강조하는 부분이 인상 깊었다. 내츄럴 본 개발자들이 싫어하는 것은 환경을 개선조차 할 수 없도록 만드는 상황이지, 개선 자체의 어려움이 아니다.

 하지만 라이브이기 때문에 이런 개선/변경도 영향력 검토가 수반되어야 한다. 어떻게 보면 약간 과하다고 생각될 정도로[각주:4] 방어적인 자세가 아닐까, 하는 생각도 들긴 했지만 이 정도는 의견 차이일 뿐 맞다/틀리다를 논할 부분은 아닐 것 같다. 어찌되건 수정이 사이드 이펙트를 가져오지 않도록 보장하는 것은 상품을 돈 받고 파는 입장, 조금 더 세련되게 말하자면 프로로써 지극히 당연한 일이기 때문.

 그보다 중요한 것은 이런 자세를 취하면서도 현 상황을 개선하려는 의지를 놓지 않는다는 점인 듯하다. 그 사이의 타협점을 맞추는게 리더로써 중요한 자질이 아닐까 싶고. 실제로 레거시에 이런 개선 사항을 적용하려면 타협이 없을 수 없는데, 우리는 이런 적용을 위해 어떤 타협을 했으며 결과적으로 어떤 개선을 했다, ndc에는 전반적으로 이런 세션이 많아서 좋았음. 실제로 당장은 아니라도 근 시일 내로 레거시 프로젝트에 적용해 볼 만한 내용이 많았던 듯.



 마비노기 영웅전 자이언트 서버의 비밀 (양승명 / 넥슨)

 ( 관련 링크 : rein's world, NDC 2011의 강연 노트를 모아보아요! (05월 30일) )

 단일 서버의 구현에 대한 내용으로 기술적/설계적으로 가장 흥미로웠던 세션 중 하나였다. 일단은 성공적으로 서비스하고 있는 게임의 서버 구조를 다룬다는 자체만으로도 흥미로운데 게다가 그 서버는 C#으로 만들어진 확장성 있는 단일 서버인데다 크고 아름다운 구조를 가지고 있다. (...) 내가 발표의 문맥을 제대로 이해했다면 이러한 기술적인 결정은 전적으로 엔지니어들 선에서 이루어진건데, 이게 사실이면 데브캣은 엔지니어들이 재미있게 일할 수 있는 환경이 아닐까 싶다는 생각.

 전반적으로 다양한 컨셉들의 추상화가 꽤 잘 되어 있다는 느낌을 받았다. 기본적으로 Service로 수행 주체를 추상화하여 물리적인 서버 대신 추상적인 서비스를 이용하도록 하는 것이 핵심 아이디어. 여기에 Entity로 대상 객체를[각주:5], Operation으로 수행 로직을 정의하고 이를 적절하게 분산 처리하면 scalable한 throughput을 얻을 수 있지 않겠느냐...는 접근인 듯.

 다만 퍼포먼스 측정을 위한 프로토타이핑이 선행되지 않아서인지 예상보다 좋지 않은 성능을 보여줬다고 하는데, 현재로써는 부하가 가장 큰 메시지 직렬화 부분을 극한으로 최적화하는 정공법으로 문제를 완화했다고 한다. 따지고 보자면 근본적인 문제를 해결한 것은 아닌 듯. 개인적으로는 데이터를 처리하는 로직의 시간 복잡도에 추가로 서버 간 커뮤니케이션으로 인해 데이터의 크기까지도 시간 복잡도에 영향을 주게 되는게 핵심적인 문제라고 보이는데[각주:6], 이런 면을 볼 때 게임 서버에 있어서 로직 처리와 이를 분산시키는 기반 엔진의 칼 같은 분리는 아직까지 쉬운 일이 아닐지도 모르겠다. 

 또 하나 궁금했던게 레이턴시였는데... 실시간 게임이라면 레이턴시가 무척 중요한 로직이 반드시 있다. 그런데 지금의 구조에서는 한 엔티티는 계속해서 한 서비스가 처리하는데, 특정 서비스에 부하가 걸리면 해당 서비스에 걸려있는 엔티티 전부가 느려지고, 엮여 있는 서비스들까지 연달아서 반응이 느려지는 문제가 있었다고 한다. 이게 단일 프로세스 내부의 쓰레드 간 로드 밸런싱이라면 그냥 랜덤하게 Work stealing하는 구조로 만들어서 간단하게 해결할 수 있지만 분산 처리에서는 발생 빈도에 비해 그 자체의 커뮤니케이션 오버헤드가 너무 크기 때문에 쉽게 택할 수 있는 방법은 아닐 듯 하다.

 사실 이 부분에 대해서는 그다지 경험이 없어서 잘 모르겠고 또 결과론적인 이야기지만 서비스를 기준으로 서버 인스턴스를 나누기보다는 엔티티를 기준으로 서버 인스턴스를 나누는게 좀 더 나은 성능을 보이지 않았을까? 하나의 오퍼레이션이 여러 서비스를 돌면서 생기는 커뮤니케이션 오버헤드와 한 서버 인스턴스가 하나의 서비스만을 다룸으로 생기는 성능적인 이득을 비교해보면 아무래도 앞이 더 크지 않을까 하는 생각이 들었다. 구조는 약간 덜 우아하겠지만 ;

 또 하나 눈 여겨 볼 부분 중 하나가 바로 DB로 인한 병목. DB의 이론 중 하나로는 CAP 이론이 있는데, 간단히 말해서 일관성, 가용성, 분할 가능성 셋 모두를 만족시키는 DB는 없다는 이야기다. 이 중 분할 가능성은 다르게 말하면 확장성이라고 볼 수 있는데, 대부분의 게임 서버에서는 게임 디자인 상 일관성, 가용성 모두가 필요하기 때문에 확장성을 포기하는 RDBMS를 쓰게 된다. 그런데 기술적인 문제를 해결하는 대신 게임 디자인을 약간 바꾸는 선택을 취한다면 어떨까 하는 생각이 들었다. 이를테면 일관성의 레벨을 eventual consistency 수준으로 낮추는 대신 비일관된 경우를 최대한 덜 보도록 디자인 차원에서 플레이어들을 적절하게 클러스터링을 해준다면? 등등. 물론 망상 수준이다 (...)

 그런데 이런 것 다 제쳐두더라도 이런 구조의 게임이 실제 수만명 단위의 동접자를 받아 성공적으로 서비스된다는 자체가 무척 인상적이었다. 한 10년 지나면 반응성이 중요한 심리스 MMO 같은 게임에서도 적용할 수 있는 분산 서버 모델이 나올 수 있을 것 같다는 생각도 들었다. 물론 그런 시대도 이러한 기술적인 도전이 계속되어야 나올 것이라는 점에서 무척 가치 있는 도전이었다고 생각한다. 




 첫 날은 인상적인 세션이 많았다. 덕분에 글도 길어짐.
  1. 와우의 경우 리치왕의 분노 시절까지 신규 유저의 70%가 10레벨 이전에 떨어져 나갔다. 친구 초대 등도 있지만 기본적으로 결제가 필요한 유료 게임이라는 점에서 상당히 충격적인 지표다. [본문으로]
  2. "루리웹에서 까이면 성공한다"의 약자. - -; [본문으로]
  3. 와우의 레이드에는 하드 모드라는게 있다. 하드 모드 도입 이전에 캐쥬얼 게이머들은 하이엔드 컨텐츠를 해보지 못한다고 징징거렸는데, 도입 이후에는 할 게 너무 많다 (...), 코어 게이머들과 격차가 너무 많이 난다 등으로 징징거린다. [본문으로]
  4. 개인적으로 64비트 플랫폼으로의 포팅은 msdn의 가이드만 꼼꼼히, 충실히 따라도 큰 문제 없다고 생각한다. 물론 이 경우는 포팅 자체보단 테스트의 문제였지만. 자체적인 스트레스 테스트가 가능했다면 좀 다른 선택을 했을지도 모르겠다는 생각이 들었다. [본문으로]
  5. 이건 추후 성능 문제가 발생한 이후 추가된 개념 [본문으로]
  6. 물론 분산 처리 자체로 인해 constant factor가 낮아지는 것도 있겠지만... [본문으로]

'개발' 카테고리의 다른 글

NDC 간략한 참관기 #3  (4) 2011.06.19
NDC 간략한 참관기 #2  (1) 2011.06.12
NDC 간략한 참관기 #1  (0) 2011.06.04
기본 타입 간 (무분별한) 변환은 자제합시다  (3) 2011.05.14
Visual Studio는 C/C++을 싫어해 (?)  (3) 2011.02.27
Bitwise Switch  (2) 2011.02.19
tags : , ,
Trackback 0 : Comment 0

티스토리 툴바