티스토리 뷰

Overview

게임 개발에 필요한 기획, 개발, 테스트, 운영, 기술, 프로세스, 용기(?)에 대한 다채로운 내용들로 채워진 NDC 2019 참관 후기입니다.

게임 회사에는 어떻게 개발을 하는지 보고 들으면서, 게임 개발사는 아니지만 우리 회사와 유사한 고민들을 하고 있고, 문제점들을 해결하기 위해서
여러 가지 방법들 시도하고, 노력하고 있다는 것을 보고, 배울 수 있는 유익한 시간이었습니다.

언젠가는 참관자가 아닌 발표자나, 주체사가 되었으면 좋겠다는 생각을 했습니다.

Day1

10:25 ~ 10:50 <AxE> 서비스를 통해 느낀 라이브 환경에서 필요한 기획자의 역량 - 디자인, 커뮤니케이션, 그리고 애티튜드 - 정우식(넥슨 레드 / NEXON RED)

기획자에게 필요한 역량이 무엇인지, 잘 정리된 발표입니다.
크게 다음과 같은 역량이 필요하고, 

  • 디자인 기술
  • 커뮤니케이션 스킬
  • 애티튜드(자세, 마음가짐)

해당 역량을 높이기 위한 방법들을 기술하고 있습니다.
기획자뿐만 아니라 PM이나 개발자들도 가지고 있어야 할 역량이라고 생각이 들었고,
특히 애티튜드 부분을 좀 더 챙겨야겠다는 생각이 들었습니다.

https://drive.google.com/open?id=1ZBmfA17pPMw06vptKHSJSBTYTYGe3QE1

 

1-1.pptx

 

drive.google.com

11:00 ~ 11:50 게임 플레이 프로그래머의 역할 - 최호영(넥슨코리아 / NEXON KOREA)

게임 플레이 프로그래머의 역할에 대해서 설명한 발표로,
처음에는 게임 플레이를 하는 프로그래머라고 생각을 했는데, 
실상은 게임 플레이에 관련된 모든 것 하는 프로그래머였습니다.

게임 플레이 프로그래머가 잘해야 할 부분으로, 아래와 같이 프로그래머, 게임, 플레이로 나누어 설명하고 있습니다.

  • 프로그래머
    • 좋은 품질의 코드를 만들고 유지
    • 코드 리뷰를 잘 하자
  • 게임
    • 콘텐츠 공급과잉으로 빠른 개발이 생명
    • 올바른 방향 설정
    • 기술 명세서 작성
    • 테크니컬 디자이너가 되자
  • 플레이
    • 원활한 소통

게임이라는 콘텐츠의 특성만 빼고, 우리 회사 개발팀과 크게 다른 점은 없다고 생각했고,
프로그래머로서 좋은 품질의 코드를 만들고 유지하는데 얼마나, 노력하고 있는지에 대해서 반성하게 됐고,
발표에서 GitLab을 사용해서 코드 리뷰를 하고 있다는 것을 들어서, 코드 리뷰는 바로 적용해야겠다고 생각했습니다.

https://drive.google.com/open?id=1_bY1mI8XpQvX7CfvdrP2HkbV1-5003fC

 

1-2.pptx

 

drive.google.com

13:30 ~ 13:55 할머니가 들려주신 마비노기 개발 전설 - 김동건(넥슨코리아 / NEXON KOREA)

마비노기 디렉터가 들려주는 마비노기 개발 이야기로, 마비노기를 만들기 시작한 2000대 초반부터 시절에 
기획, 개발, 운영하면서 있었던 에피소드와 그 시절에 문제들을 어떻게 해결하고 운영했는지 설명하고 있는 발표였습니다.
이 발표가 게임 개발을 하시는 분들에게 용기를 주고, 도움이 되었으면 좋겠다는 발표자님의 말이 인상적이었고,
마비노기를 만들기 위해 열정적이고, 능동적으로 노력한 보습이 보였고, 현재의 마비노기가 그냥 만들어진 게 아니구나 라는 
생각을 했습니다.

https://drive.google.com/open?id=1apkg6Q9-HFlMiZ7BS8vw1jpN7JVqhlzY

 

1-3.pptx

 

drive.google.com

14:10 ~ 15:00 <쿠키런: 오븐 브레이크> 2년 된 게임, 2배로 성장시키기 - 배형욱(데브시스터즈 / Devsisters)

2주년 이 된 쿠키런 게임이 현재에 안주하지 않고 성장하기 위해서 어떤 노력을 했는지에 대한 발표였습니다.

  • 게임 서비스
    • 대규모 업데이트(콘텐츠 강화)
    • 초저과금 상품 출시
    • 스토리상 하나는 주고 하나는 구매할 수 있는 아이템 제작
  • 개발 문화
    • 부정적인 순환 끊기
    • 리더의 역할

성장하기 위해서는 게임 서비스 측면보다는 개발 문화가 더 중요하다고 생각한다는 발표자의 말에 공감했고, 
좋은 개발 문화를 위해서는 시니어 개발자로서 얼마나 노력하고 있는지 반성하는 시간이 되었습니다.

https://drive.google.com/open?id=1WiKGrRdK2imWTrbMFUYrrDftygXHAuol

 

1-4.pptx

 

drive.google.com

15:20 ~ 16:10 전지적 참견 시점 - 게임 개발 PM - 안광섭(넥슨코리아 / NEXON KOREA)

게임 개발 PM의 업무와 이를 잘하기 위한 방법들이 잘 정리된 발표였습니다.
PM의 업무는 다음과 같고,

  • 일감 관리
  • 문서화
  • 개발 진행
  • 배포 및 후속 조치
  • 업무 상기시키기
  • 분배하기
  • 전달하기
  • 문서화
  • 결정 돕기

이를 잘하기 위해 필요한 것은 다음과 같습니다.

  • 맥락적 이해능력
  • 새로운 지식의 습득
  • 신뢰주기
  • 타협하기

게임 개발에 국한된 내용이 아니라 모든 개발의 PM이 들으면 좋은 내용의 발표라고 생각했고, 
개발을 하다 보면 PM을 하게 되는 경우가 있는데, 발표 내용을 참고해서 PM 업무에 적용해봐야겠다고 생각했습니다.

https://drive.google.com/open?id=1GKVt6YPw5cmadgX_A-4frMQplq0RGHfE

 

1-5.pptx

 

drive.google.com

16:30 ~ 17:20 <FIFA 온라인 4> 서버 포스트모템 - Microservices on Kubernetes - 김에스더(EA코리아 / EA Korea)

FIFA 온라인 4게임을 쿠버네티스로 마이크로 서비스들로 구현하면서, 기존 버전의 모놀리식 아키텍처에 있었던 문제점들을 
어떻게 마이크로서비스 아키텍처 & 쿠버네티스로 해결하였는지와, 이를 운용하가 위하서 어떤 것들을 했는지에 대한 발표였습니다.
모놀리식 아키텍처의 단점은,

  • 장애 시, 전체 서비스 장애
  • 작은 변경을 위해 전체 서버 빌드 및 배포 필요
  • 비효율적인 Scale out

이고, 마이크로 서비스 아키텍처의 장점은,

  • 개발 속도가 빠르다
  • 서버 배포가 쉽다
  • 서버 장애의 영향도가 일부 서비스에 국한된다
  • 스케일링이 쉽고 효율적이다

인데, 마이크로 서비스를 하다 보니, 서버가 40개로 많아졌고, 이를 효율적으로 관리하기 위해서, 쿠버네티스를 도입했다고 합니다.
쿠버네티스 패키지 관리 및 배포를 위해서는 HELM이라는 패키지 매니저를 사용하였고, 서버 운영 위해서는 커스텀 모터링 툴을 자체 제작해서 운영 중이라고 합니다. 또한, 오픈전에 로드테스트하기 위해서 AWS에 유사한 서버를 구축해서 테스트하였고, 메모리 이슈 등 많은 버그를 잡을 수 있었다고 합니다. 

마이크로 서비스와 쿠버네티스 환경 운영에 대한 노하우들을 조금이나마 엿볼 수 있었고, 해당 아키텍처로 개발 시 참고하면 좋을 것 같습니다.

https://drive.google.com/open?id=14Pa80GhybACNknViWmgXuk2slLLMr1TB

 

1-6.pptx

 

drive.google.com

17:40 ~ 18:30 <리니지 M> 모바일 게임의 호환성 테스트와 자동화 적용 - 이호승(엔씨소프트 / NCSOFT), 홍상영(엔씨소프트 / NCSOFT)

리니지 M에서 모바일 기기의 호환성 테스트를 어떻게 하고 있고, 어떠게 테스트 자동화 툴을 제작하였는지에 대한 발표였습니다.

호환성 테스트 대상은 다음과 같고,

  • 장치(Display, CPU/GPU, RAM)
  • OS(Android, iOS)
  • Game(Unreal, Unity, Cocos2d)

이런 테스트를 자동화하기 위해서, Appium 오픈소스를 사용하여, 테스트 자동화 프레임워크(NCQA)를 어떻게 구축했는지 알 수 있었습니다.
NCQA의 구조는 다음과 같습니다.

  • 게임 오브젝트 인스펙터 뷰어 : 스크립트 작성에 필요한 UI 정보 확인 도구
  • Gappium Python Client Library : 스크립트가 Gappium에 명령을 내릴 때 사용하는 라이브러리
  • Gappium : 게임 오브젝트 인스텍터와 통신, Appium 확장
  • 게임 오브젝트 인스펙터(Unity3d, Cocos2D, Unreal) : 게임 UI 정보 전달, 게임 빌드 삽입하는 모듈, 엔진별)

이렇게 엔씨소프트에서 수많은 디바이스들의 호환성 테스트를 위해서 노력하고 있다는 것에 놀라웠고, 역시 잘 나가는 게임은 그냥 만들어지는 것이 아니구나라는 생각을 하게 되었습니다.

https://drive.google.com/open?id=1_f9YX2UPZKyNDIUcFstkGTd9qQWlmhr-

 

1-7.pptx

 

drive.google.com

Day2

09:50 ~ 10:40 Redis 주요 시스템과 Redis 5.0 살펴보기 - 한종영(EA코리아 / EA Korea)

Redis에 대한 전반적인 설명과 5.0에 추가된 주요 기능과 클러스터 구성 방법에 대한 발표였습니다.
Redis에서 직접 모듈을 만들어서 사용하는 방법을 소개하였고, Redis thread 구조 등을 설명하였습니다.
5.0에서 추가된 기능으로

  • Streams 자료구조
    • Streams는 List + Sortedset + Hashset
    • ID 기준으로 정렬된 메시지 큐
    • 한 번에 여러 개의 필드/값을 입력할 수 있음
    • 변경이 없는 주기적 로그성 데이터에 유리
  • sortedset 명령
    • ZPOPMIN/MAX key [count]
      • sortedset의 작은/큰 값부터 n개 획득
      • 획득 후 해당 키 삭제(LPOP처럼)
    • BZPOPMIN/MAX key [key... ] timeout
      • 값이 있으면 ZPOP*과 동일
      • 값이 없으면 blocking 상태로 timeout 시간만큼 대기하고 반환
  • redis-cli cluster 지원
    • 기존에는 cluster 명령을 위한 ruby package인 redis-trib.rb를 사용
    • 5.0부터는 redis=cli에서 cluster 명령을 지원

등에 대해서 설명 및 시연하였습니다.

시스템 엔지니어에게 상당히 도움이 될만한 내용이라고 생각했고, 추가된 기능을 가지고 무엇을 할 수 있을지 고민할 수 있는 시간이었습니다.
이제 막 추가된 기능들로 검증이 필요하지만, 토이 프로그램 등에 활용해보면 좋을 것 같다는 생각을 했습니다.

https://drive.google.com/open?id=1VvP1jYDi5Pst2nQTiE_fm_CTbtyIodHo

 

2-1.pptx

 

drive.google.com

11:00 ~ 11:50 마이크로 서비스, 운영하기 좋은 게임 벡엔드로의 변화! - 최학윤(넥슨 아메리카 / NEXON AMERICA)

마이크로 서비스들로 운영하기 좋은 게임 백엔드를 만들 때 고려 사항들에 대해서 발표하는 시간이었습니다.
마이크로 서비시스 구조가 예전에도 있었고, 일반적으로 책에서 말하는 장점들이 모두 해당하는 것은 아니지만, 
아래와 같은 운영적인 개선을 위해서,

  • 적거나 없는 다운타임
  • Fail-resilient
  • Scal-out, scale-in 이 쉬운
  • 배포가 쉬운

마이크로 서비스를 적용하게 되었다고 합니다. 마이크로 서비스 고려사항으로는,

  • API Gateway 설계
    • 로드 벨런싱
    • 테스트하기 휘운 프로토콜
    • 인증서 관리의 편리함
  • DB 설계
    • 용도에 따라, RDBMS 1개, NoSQL 한 개, 시계열 DB 한 개 만 사용하는 게 관리하기 용의
  • CAP 이론, 일관성(Consistency), 가용성(Availablity), 단절 내성(Partition Tolerance)
    • 데이터 일관성을 위해서 트랜젝션과, 이벤트 일관성(Eventual Consistency) 구현
  • 동시 접속자(CCU, Concurrent Connected User) 집계
  • Deployment, Scaling, Monitoring
    • Kubernetes 사용
  • 트러블 슈팅
    • 로그 관리 및 검색 Kibana, Splunk 사용

등에 대해서 발표하였습니다. 또한 오래된 게임 백엔드를 마이크로 서비스로 바꾸는 것에 대해서는 Trade-off를 반드시 고려하라고 조언해 주었습니다.

운영적인 측면에서, 마이크로 서비스를 제작할 때 고려해야 할 사항들에 대해 잘 정리한 발표였다고 생각하고, 
트렌드에 따라 무작정 기술은 적용하는 것은 운영 비용을 더욱 높인다는 발표자의 말에 공감하였고,
상황에 맞게 적재적소에 필요한 기술을 사용하도록 노력해야겠다고 생각했습니다.

https://drive.google.com/open?id=1Bp6ivQdeDmSQ7hvjqVM6-fqr-hP-3dSL

 

2-2.pptx

 

drive.google.com

13:30 ~ 14:20 UI는 누가 붙여야 하나? - 아티스트에게 UI 돌려주기 - 박성철(넥슨코리아 / NEXON KOREA)

게임 개발 시에 리소스 제작은 아티스트가 하지만 UI 적용은 프로그래머가 하기 때문에 발생하는 문제를 해결하기 위해서,
UI 적용 과정을 아티스트가 할 수 있는 환경을 어떻게 만들었는지에 대한 발표입니다. 

다음과 같은 UI의 세 가지 기능,

  • Presentation
  • Navigation
  • Operation

을 CUD(Continuous UI Development)를 구현하기 위해, 다음과 같은 기능,

  • Bidirectional Data binding(양방향 데이터 바인딩)
  • View Data Layer(데이터 레이어 보기)
  • UI State Machine(UI 상태 머신)
  • External Interface for Custom Function(사용자 정의 펑션을 위한 외부 인터페이스)
  • Naviagtion Event Hooker(내비게이션 이벤트 후커)

을 어떻게 구현하였는지에 대해서, 설명하였습니다.
게임 개발에서 디자이너에게 직접 UI 적용할 수 있도록 함으로써, 개발자 눈치 보지 않고,
UI를 개선할 수 있어 전체적인 퀄리티도 높아지고, UI가 이상한 건 아티스트에게, 
기능이 이상한 건 프로그래머에게 각각 요청하게 되어서 업무 효율도 높아지게 되었다고 합니다.
이러한 협업에서 문제가 되는 부분을 솔루션 개발 통해서 해결하는 모습이 인상적이었고,
우리도 이러한 부분을 찾아서 적용해보면 좋겠다고 생각했습니다.

https://drive.google.com/open?id=1xeucKslgfWu7dbKIliwasOVc36f9rax9

 

2-3.pptx

 

drive.google.com

14:40 ~ 15:05 Game Data analysis with Deep Learning - 김승원(크래프톤 / KRAFTON)

머신러닝과, 딥러닝에 대한 전반적인 소개와 전통적인 머신러닝과 딥러닝 비교하였고, 딥러닝을 사용하여 TERA 게임 데이터 
분석을 통해 다음과 같은

  • Classification(분류 분석)
    • 이탈 유저 예측
    • 헤비 사용자 예측
  • Regression(회기 분석)
    • 몬스터 클리어 타임 예측
    • 특정 콘텐츠 이용률 예측
    • 생성 골드 및 소비 골드 량 예측

작업을 어떻게 했는지에 대한 발표였습니다. 이러한 예측을 통해서 더 좋은 게임을 만들 수 있는 백데이터를 만들 수 있을 것 같고,
성공을 보장하지는 않지만, 성공할 수 있는 확률을 높여주지 않을까 생각했습니다.

https://drive.google.com/open?id=1Af-Rn41K6sQBA9YE6z-Jkm-fx7I1N0hB

 

2-4.pptx

 

drive.google.com

15:15 ~ 16:05 게임 서버의 목차 - 시작부터 출시까지 - 홍성우(넥슨코리아 / NEXON KOREA)

게임 서버 개발을 위한 프로세스 전체를 순서대로 하나하나 짚어가며, 고려해야 할 사항에 대해 빠르고 자세하게 설명하는 발표였습니다.

  • 최초의 의사결정
    • 서버의 용도, 장르
    • 사용자 규모
    • 통신환경
    • 데이터 손실 허용성
    • 데이터 저장소
    • 언어
    • 운영체제
  • 기반구조 보강
    • 프로토콜
    • DB추상화
    • 데이터 동시성
    • 시간 처리
  • 게임 콘텐츠 구현
    • 서버 로직의 분류
    • 테스트 자동화
    • 레이어링
    • 동시성
    • 실행 성능
    • 도메인 언어
    • 경제 버그 예방
  • 스케일아웃
    • 목표 동접 / 가입자 수
    • 봉투 뒷면 계산법
    • 간이 부하 테스트
    • 게임 서버 분할
    • 유저 간 상호작용
    • DB 분할
    • Redis 분할
  • 출시 준비
    • 마켓, 결제 연동
    • 인증 시스템
    • 보안 검수
    • 모니터링 툴, 분석 도구
    • 넥슨 표준 로그
    • NXLog
    • 운영 툴, 대량 지급
    • 자금결제법 대응
    • 점검 공지
    • 실시간 공지
    • 패치 시스템
    • 에러 리포트
    • 다국어 지원
    • 커뮤니티 연동
    • 이벤트 제어
    • 백오피스
  • 무점검 스케일아웃
    • 출시 피크
    • 게임 서버
    • 저장소
  • 부하 테스트
    • 개념
    • 서버군
    • 더미 클라이언트
    • 부하 패턴
    • 문제 확인
    • 문제 해결
    • 일정
  • 장애 안정성
    • SPOF
    • 목표
    • 설계
    • 동작 예시
    • 테스트
  • 예측 실패 대비
    • 준비가 충분할까?
    • 서버군 분리
    • 대기열 서버
    • 차단 스위치
  • 출시 이후
    • 출시 초기 문제
    • 패킷 로그 조회
    • 데이터 분석
    • 장애 대응
    • 세대교체 준비

게임 서버 개발을 위해서 이렇게나 많은 고려 사항이 필요하다니 놀라웠고, 
웹 서비스 서버 개발을 위해서 필요한 부분과 실제로 차용하면, 좋을 내용들이 많았는데, 
실제로 프로젝트 진행 시에 위 내용들을 고려해보면 좋을 것 같습니다.

https://drive.google.com/open?id=1-5CYQH0_-H1FwptK0bL3CzI5NvU_38_H

 

2-5.pptx

 

drive.google.com

16:25 ~ 17:15 어머님, A/B 테스트를 댁으로 들이십시오 - <DevPlay> A/B 테스트 플랫폼 개발기 - 김민수(데브시스터즈 / Devsisters), 오우택(데브시스터즈 / Devsisters)

시간제한이 있는 상품의 판매 시간을 어떻게 설정해야 가장 많이 팔릴까라는 기획자들의 고민을 해결하기 위해서 A/B테스트 플랫폼을 제작하는데, 
어떤 고려사항들이 발생했고, 이를 어떻게 해결했는지에 대한 발표였습니다.
다음과 같은 순서로 발표하였고,

  1. 상품 기획자의 고민
  2. 실험 기획
  3. 실험군 나누기
  4. 여러 실험 동시에 하기
  5. A/B 테스트 플랫폼 개발
  6. 실험 결과
  7. 결론

A/B 테스트를 통해서 얻은 데이터를 기반으로 의사결정을 하고 있다는 것 자체가 합리적이라 생각했고,
웹 솔루션에 A/B 테스트를 위한 플랫폼도 고려해보면 좋겠다는 생각을 하게 되었습니다.

https://drive.google.com/open?id=1UJutvnBAB_FefGvJ-1Co_Gv_wRiYsHct

 

2-6.pptx

 

drive.google.com

17:35 ~ 18:00 <카트라이더> 0.001초 차이의 승부 - 300km/h 물체의 네트워크 동기화 모델 구현기 - 강길전(넥슨코리아 / NEXON KOREA)

카트라이더 게임에서 레이싱 경기중에 게임 클라이언트상에서 네트워크 동기화 모델링을 어떻게 해서, 0.001초 차이의 승부를 가늠하고, 카트를 표현해주는 것에 대한 발표였습니다. 현재 속도에 대한 시뮬레이션 모델을 만들어 동기화하는 방법을 사용했고, 시뮬레이션된 결과를 가지고, 있다가 실제 데이터가 오면, 보정하는 방식으로 동기화를 하여 이질감을 최소화하는 방법을 사용한다고 합니다. 프로그래밍도 깊이 들어가면, 수학적인 베이스가 중요하구나라는 생각을 하게 되었습니다.

https://drive.google.com/open?id=1k7ptvuib0wo4qRY5VblhQ4VPYNcWkcYy

 

2-7.pptx

 

drive.google.com

18:10 ~ 18:35 <야생의 땅: 듀랑고> 조직 문화와 라이브 개발 프로세스 - 자유와 관리, 두 마리 토끼 잡기 - 안미루(넥슨코리아 / NEXON KOREA)

듀랑고팀의 자유롭고 개방적, 열심히 소통하는 조직 개발 문화에서 발생하는 문제점들을 해결하고, 자유와 관리 두 마리 토끼를 잡는 라이브 개발 프로세스를 만들기 위해서 어떻게 했는지 에 대한 발표였습니다. 

  • 넘쳐나는 정보량과 의사소통 문제 → 작업 관리 툴(JIRA)을 활용
  • 안정성과 예측 가능성 문제 → 2주 단위의 스크럼 개발 주기

게임 회사라고, 특별히 다르지 않다는 생각을 했고, JIRA를 WBS(Work Breakdown Structure)로 사용하면, 유관 부서들 간의 업무관리가 좀 더 효율적일 것 같다는 생각과 2주 단위로 스크럼 개발 주기도 관리 리스크 및 관리적인 측면에서 도입해 볼만 하겠다는 생각을 했습니다.

https://drive.google.com/open?id=1nxARzuuYiXMq67ZnR0Ux2uo5mKXBt1ns

 

2-8.pptx

 

drive.google.com

Day3

09:50 ~ 10:40 시스템 기획서 잘 쓰는 법 - 이나은(넥슨코리아 / NEXON KOREA)

기능 설계 및 개발 진행 시에 사용하는 시스템 기획서를 잘 쓰기 위한 방법에 대한 발표였습니다. 

  1. 생각하기
    1. 기획 의도
    2. 개발 방향 및 목표
  2. 쓰기
    1. 읽는 대상에 따라 다르게 쓰기(프로그래머, UI 디자이너, 퍼블리셔
    2. 기획서는 어떤 형태로 쓸까?
    3. 어디까지 써야 할까?
  3. 고치기
    1. 기획서 공유 전에 고치기
    2. 개발 진행 과정에서의 수정
    3. 최신 버전 유지하기

위 내용들이 어찌 보면 당연하다고, 생각되는 것들이지만 실제로 문서 작성 시에 얼마나 잘 지켜지고 있는지 반성하게 되는 발표였습니다.

https://drive.google.com/open?id=13y2B6pgE4Wv_4GDSiuLp-IZZv6S3_xeR

 

3-1.pptx

 

drive.google.com

11:00 ~ 11:50 SilvervineUE4Lua - UE4에서 Lua 사용하기 - 전형규(넥슨코리아 / NEXON KOREA)

UE4(Unreal Engine 4)의 Blueprint는 노드 기반 비주얼 스크립팅 시스템으로, 엔지니어의 도움 없이 디자이너가 직접 기능을 구현할 수 있도록 기능을 제공하는데, 다음과 같은 Blueprint의 단점

  1. 복잡도 관리가 어렵다
  2. 공동 작업이 어렵다.
  3. 코드 리뷰가 어렵다.
  4. 디버깅이 어렵다.

을 극복하기 위하여, Blueprint를 쓰지 않고 텍스트 스크립트 언어인 Lua를 도입하여, Blueprint 기능을 대체한 방법에 대한 발표였습니다. 해당 기능을 오픈소스 화해서 SilvervineUE4Lua라는 오픈소스로 공개하였다고 합니다. 분야가 달라서 이해도가 높지는 않았지만, 내부 프로젝트를 범용 플랫폼으로 잘 개발해서, 오픈소스로 기여하는 모습이 인상적이었고, 이런 부분에 도전해보고 싶은 생각이 들었습니다.

https://drive.google.com/open?id=1Buk7ateCyxlxPKnP-l6wDp1l-kye2mpy

 

3-2.pptx

 

drive.google.com

13:30 ~ 14:20 열정적인 테스트가 우리 게임 서비스의 품질을 향상시키지 못하는 이유 - 서정린(넥슨네트웍스 / NEXON NETWORKS)

더 많은 강도 높은 테스트가 품질을 향상 시키지 못하는 이유와 효과 적인 테스트를 위해서 필요한 것이 무엇인지에 대해 발표하였습니다.

  • 결함 발생률 억제는, 생산 과정에서만 통제할 수 있다.
  • 따라서 테스트의 양적 증대는 효과적인 선택 일 수 없다. 
  • 개발과 QA 프로세스는 서로에게 영향을 주고받는다.
    • 가성비 좋은 리스크 관리는 양질의 정보를 필요로 한다.
    • 리스크 정보 없이 수행되는 테스트는 가성비가 매우 떨어진다.
    • 따라서, 품질은 양 부서 모두의 노력 하에서만 향상될 수 있다.

무작정 테스트한다고 해서, 품질이 좋아지는 것이 아니라, 품질이 좋아지도록 개발 시부터, QA 프로세스를 포함시켜야 한다는 것에 공감했습니다. 다만, 현실적인 부분에 대한 고려가 필요할 것 같다는 생각을 했습니다.

https://drive.google.com/open?id=1-mCA2v4S-sbKIeKTJOUDfHkJJemZyeVJ

 

3-3.pptx

 

drive.google.com

14:40 ~ 15:30 개발이 쉬워진다? - 생산성을 올려주는 개발자 도구 툴 - 홍진우(넥슨코리아 / NEXON KOREA)

게임 운영 중에 발생하는 버그를 잡기 힘든 이유를 "원인 파악이 어렵다"로 보고 원인 파악이 어려운 이유를 다음과 같은 문제로 정의하고

  • 근거가 유실되었다.
  • 정보가 흩어져 있다.
  • 작업자의 시간이 시간이 많이 든다.

이를 해결하기 위해서 개발자 도구 툴을 만들어서, 다음과 같은 기능을 제공하여

  • 상주형 모니터링
  • 시간 순 정보 보기, 테스트 단위 정보 보기
  • 빠른 기능 확장/축소, 사용자 SDK 제공

빠른 버그 픽스를 통하여, 개발 생산성을 올렸다는 발표였습니다.

서비스를 위한 도구가 아니라 순수하게 개발을 위한, 도구를 만들고 활용하고 있다는 것과, 이를 개발할 시간을 (한 명이 개발한다지만) 리소스를 부여받아서 진행하고 있다는 것 자체가 좋아 보였고, 최적화된 개발 프로세스를 위한 도구를 정비하고, 개발 생산성을 높이는 것도 중요하지 않을까 생각하게 되었습니다.

https://drive.google.com/open?id=1uZZoD3V9F5ZlF3RvnaNHJKfVT7hUErus

 

3-4.pptx

 

drive.google.com

15:50 ~ 16:40 실버바인 대기열 서버 설계 리뷰 - 강성훈(넥슨코리아 / NEXON KOREA)

게임 서버 접속이나 연말 정산할 때 홈텍스 페이지에서 대기 인원 숫자 카운트 다운하면서, 대기하는 대기열 서버를 어떻게 구축했는지 대한 발표였고, 아래와 같은 내용으로 발표하였습니다.

  • 대기열 서버가 필요한 이유
    • 넘치는 사용자를 막는 것보다는, 다른 사용자가 빠지거나 서버가 충분히 확장될 때까지 기다리게 하는 게 나음
  • 대기열을 만드는 방법
    • 가장 최근에 들어오고 나간 대기자의 순번만 저장하고, 암호학적 인증으로 클라이언트를 주기적으로 폴링 하게 함
  • 대기열 서버가 죽었을 때에 대한 처리
    • 구조적으로 상태를 횡 분할할 수 없지만, 각 서버가 죽었을 경우에도 강건하게 동작하도록 준비할 수는 있음.
  • 대기열을 더 잘 만드는 방법
    • 저장소에 보낼 명령을 미리 합치는 걸로 성능을 향상하거나, 대기 시간을 적은 부하로 추정할 수 있음.

실버바인이라는 서버엔진을 사용하여 만들었다지만, 해당 발표 내용에 설계 내용이 충분히 녹아져 있어서, 실제로 대기열 서버를 구축할 때 훌륭한 레퍼런스가 될 수 있는 발표였다고 생각합니다.

https://drive.google.com/open?id=1OJYdSCbbVfF7zr-qjdQPys6OEBKHmW5E

 

3-5.pptx

 

drive.google.com

17:00 ~ 17:25 <바람의 나라> 사냥터 밸런싱 포스트모템 - 민병재(넥슨코리아 / NEXON KOREA)

23년이나 된 바람의 나라 게임에서 특정 사냥터에만 사용자가 몰리는 현상의 원인을 파악하고, 이를 해결하기 위해서 어떤 방법들을 적용하였는지에 대한 발표였습니다.

사냥터 효율이 맞지 않은 것이 문제라고 생각하고, 사냥터 효율을 경험치/h 단위로 측정하여, 난이도(입장 레벨)에 따라서 경험치 효율을 맞춰주는 작업을 통해서 어느 정도 성과를 얻었습니다. 하지만 라이트 유저가 접근 조치 못 하는 사냥터가 다수 존재하였고, 라이트 유저와 해비 유저가 모두 만족할 수 있도록, 라이트 유저도 사냥할 수 있도록 난이도를 낮추고, 헤비유저 전용 콘텐츠를 추가하여 또 어느 정도 성과를 가져왔지만, 직업 밸런스로 발생하는 효율 차이는 극복하지 못했습니다.

오랫동안 유지되는 게임은 역시 그냥 만들어지는 것이 아니라 지속적인 관리와 여러 가지 시도를 통해서 유지가 되는구나 라는 생각을 했습니다. 그리고 개발자로서, 내가 만든 프로그램이 다른 프로그램으로 대체되지 않고, 바람의 나라처럼 정말 오랫동안 서비스되고, 유지되며 발전할 수 있었으면 좋겠다는 생각과 그렇게 될 수 있도록 잘 만들어 봐야겠다는 다짐을 해보았습니다.

https://drive.google.com/open?id=1RuxNiHqHj8SxWDSaQ9VZESbJhoW7DKJL

 

3-6.pptx

 

drive.google.com

17:35 ~ 18:00 코드 리뷰 실천 방안 제안 - 이연성(넥슨 레드 / NEXON RED)

코드 리뷰를 하게 되면 좋은 점이 무엇인지와  리뷰 프로세스마다 어떻게 하면, 코드 리뷰가 잘 될 수 있는지 코드 리뷰 실천 방안에 대한 발표였습니다. 코드 리뷰란 협업을 통해서 좋은 코드를 만드는 것이라고 정의하였는데, 리뷰어, 리뷰이 모두 코드 리뷰를 통해서 좋은 코드를 만들겠다는 마음 가짐을 가지고, 리뷰이가 리뷰어를  배려하여 코드리뷰를 문서를 작성하고, 리뷰어도 리뷰 시에 리뷰이에 대한 예절을 지켜서 리뷰하면 좋은 코드 리뷰가 될 수 있다는 게 핵심 내용이 었다고 생각합니다. 그리고 이를 잘하기 위한 여러 가지 방법들이 잘 정리되어있는 발표입니다.

https://drive.google.com/open?id=1_kggdwbgDj1Kqk9adYb77TR_SLAuwqy0

 

3-7.pptx

 

drive.google.com

 

'리뷰' 카테고리의 다른 글

DEVIEW 2015 참석 후기  (0) 2020.03.07
DEVIEW 2013 참석 후기  (0) 2020.03.07
갤럭시북 플렉스 리뷰  (0) 2020.01.11
DEVIEW 2017 참석 후기  (0) 2017.11.10
DEVIEW 2016 리뷰  (0) 2016.10.28
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
페이지
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
글 보관함