NDC 2017을 다녀와서...(2일차)

NDC 2017

NDC 2017 일정

---

NDC 기념품

없습니다.!!(과자 몇개가 전부.. ㅎㅎ)

---

NDC 2017 외부 전시

ROBO RECALL

NDC 접수 후 바로 보이는 곳은 ROBO RECALL 이라는 VR 게임이 전시되어 있는 곳이었습니다.

이곳에서 풀VR 게임인 ROBO RECALL(오큘러스, 오큘러스 컨트롤러 이용)한 게임을 직접 체험해볼 수 있었습니다. 실제로 보이는 공간 안에서 고개를 돌리는 것 이외에도 직접 총을 쏘고 적을 잡아보면서 vr이 많이 발전했음을 확인할 수 있었습니다.

EXIBITION

EXIBITION에는 다양한 종류의 일러스트들을 볼 수 있었습니다. 이 일러스트들은 디자인을 공부하는 사람들에게 매우 유익한 부분인 것 같습니다.

---

NDC 

NDC 2일차 세션

1. <빅데이터> 데이터의 대모험(데이터 파이프라인) - 이도호




1. 목적: 넥슨에서는 실시간으로 유저의 피드백들을 종합하고 분석하여 빠르게 대응하기 위해 빅데이터를 이용할 필요성이 생김.
   
2. 빅데이터 분석의 핵심 키워드: 절대량, 유형, 속도, 접근성
1. 데이터의 양이 방대하고 포맷이 다양하며, 실시간 분석이 가능할 정도로 빨라야 하고 기존 방식을 활용해 데이터에 접근할 수 있어야 한다는 것
3. 따라서 오픈소스와 아마존 AWS 서비스를 이용하여 사용자들에게 다양한 서비스를 제공
1. Athena
2. kinesis
3. 제플린
4. fluentd
4. 로그 분석 과정
1. 게임 - 로그 수집 서버 - 메시지 큐 - 머신러닝, 실시간 집계 - RDB, 파일 스토리지 - 실시간 피드백 서버, 메시지 피드백 서버, 비정형 데이터 분석
1. 로그 수집
1. fluentd
1. simplified web server
2. core는 c++로 구성되어 있음
2. docker
1. commandline 이용
2. AWS에서 현재 web UI 형태로 제공 중
3. 서버 중단 없이 Live로 지원 가능
2. 메시지 큐
1. 로그 수집으로 부터 들어온 로그들을 필터링 후 메시지 큐에 차례대로 넣게 된다.
3. 머신러닝, 파일 스토리지
1. 머신러닝
1. 메시지 큐에 들어있는 로그들을 일정한 형태로 분석을 하여 여러 개의 그룹으로 나누게 한다.(비슷한 종류의 피드백을 묶기 위함)
2. 형태소 분석 등 다양한 분석 기법들을 활용하여 그룹핑
2. 파일 스토리지
1. 로그들을 파일 스토리지에 저장을 하게 된다.(해당 로그들을 활용 및 저장, 몇 년 저장을 하는지는 기억이 나지 않는다.)
2. 비정형 로그이기 때문에 꼭 필요함.
4. 실시간 피드백 서버
1. 실시간으로 LIVE 서버에 피드백을 주는 서버이다.
5. 메시지 피드백 서버
1. 해당 피드백을 내린 사용자에게 피드백에 관련된 저치사항을 알려주는 서버이다.
5. 빅데이터는 이와 같이 로그들을 이용하여 사용자에게 올바른 피드백을 주기 위해서 사용을 하고 있다.
6. 이는 빅데이터의 이용의 한 방향 중에 하나이다.(데이터 분석가들에게 유용)

2. <던전앤파이터> 시즈키 도장 포스트모템 - 임희종




1. 대전 AI 관련된 주제
2. 던파 결투장 아케이드 모드의 시즈키 도장 AI 개발에 대한 설명
3. 던파는 15개의 캐릭터, 51개의 전직, 3,000여개의 스킬을 구현되어 있고 X, Y축을 사용한 무빙, 다양하고 화려한 콤보시스템, 공중콤보, 스탠딩콤보, 바닥콤보, 보정시스템까지 다양한 공격 스킬을 가지고 있다.
4. 따라서 AI를 개발할 때는 이런 다양한 스킬들을 조합해서 나온 콤보들과 무빙들을 종합하여 유저들이 진짜 유저들과 붙는 것 같은 느낌이 들 수 있을 정도로 하는 AI를 개발할 필요성이 있음
5. 난이도를 3가지로 구분하여 총 153개의 AI를 개발
1. AI 로직은 하나의 Main 함수를 만들고 난이도별 data 파일들을 따로 만든 후 import 해서 생성
6. 위험 영역의 경우 피하는 무빙들을 가지고 있어야 함
1. 적의 공격영역을 인지시키고, 스킬별로 적의 공격데이터를 정의. 스킬 쿨타임에 따라 위험 영역을 구분.
2. 해당 영역은 사각형의 형태로 존재를 함.
1. 사각형 영역안에 유저가 들어오면 AI가 알아서 위치 이동하여 해당 영역을 벗어남.
2. 이는 AI가 공격을 하는 것도 가능
7. AI는 과거 일일이 전부 체크하는 방식을 사용했기 대문에 버벅임과 많은 api call이 존재 했었음.
8. 하지만 최근에는 event를 script에서 발생시에 call 하는 방식으로 변경되었기 때문에 속도적인 issue는 존재하지 않음.
9. AI는 끊임없이 진화하고 있으면 빅데이터를 도입한다면 더욱 좋은 AI가 나올 것으로 생각됨.

3. <로보리콜> 포스트모템 - 신광섭




1. 로보리콜은 에픽게임즈가 약 12개월을 들여서 만든 풀 vr 게임
2. 오큘러스에서 게임 컨트롤러를 만들고 개발되었기 때문에 오큘러스 독점
3. 풀 vr: 모션 인식 + vr
4. 이전 블릿트레인을 개발했었기 때문에 이를 참조를 많이 해서 개발
5. 로보리콜의 5가지 원칙
1. 매트릭스
1. 매트릭스의 네오처럼 악을 물리치는 주인공
2. 아케이드
1. 아케이드 게임처럼 슈팅을 화려하게 할 수 있도록 구현
2. 총 이외에도 타격기 등을 사용할 수 있도록 함
3. 스코어 방식을 이용하여 다른 플레이어와의 경쟁심을 이용할 수 있도록 함.
3. 디바이스에 최적화된 경험
1. vr을 통해 실제와 비슷한 경험 + 그래픽적인 이슈를 해결함으로써 이질감을 없앨 수 있도록 해야함.
4. 현실적인 몰입감
1. vr을 현실과 비슷한 근미래의 배경을 설정하였기 때문에 현실과 비슷한 경험을 할 수 있음
5. 20분 플레이의 경험주기
1. 20분을 넘어가게 되면 유저가 지루함을 느끼기 때문에 컨텐츠는 20분 이내가 적당(컨텐츠 개발시 중요)
6. 텔레포테이션
1. 로보리콜에서 텔레포테이션을 활용한 이유는 vr에서의 멀미 때문이다.
2. vr에서는 실제로 사용자가 이동을 하지 않지만 이동을 한다는 착각을 줄 수 있다.(멀미를 일으키는 요인)
1. 또한 위험을 야기할 수 있다. (등반을 하는 화면이 나왔을 때 유저가 등반을 허공에서 하다 넘어지는 등 위험할 수 있음)
3. 따라서 텔레포테이션을 통해 이를 해결함.
4. 또한 텔레포테이션시 멀미 유발을 해결하기 위해 잠시 눈을 깜빡이는 것처럼 표시
5. 처음에는 손목을 움직엿을 때 트리거를 주는 방식을 차용했지만 이는 인식률이 떨어졌고 유저가 해당 동작을 취하기 어려워서 오큘러스 게임 컨트롤러의 아날로그 스틱을 이용하여 하도록 설정이 변경
6. 이동 범위 인식 문제는 포물선 방식을 통해 이를 해결
7. 유저가 머리가 돌아갈 곳을 미리 계산하여 사용자가 멀미감을 느끼는 것을 해결하는 데 도움을 줌
7. 퍼포먼스 확보
1. vr 컨텐츠는 다른 컨텐츠들에 비해 많은 리소스를 소모함.
2. 따라서 연산 리소스를 효율적으로 관리하는 방법이 필요.
3. 로보리콜에서의 퍼포먼스 확보
1. 유저의 시선은 상하 약간 정도를 유지하기 때문에 인간형 로봇의 경우 머리와 몸통 부분의 폴리곤에 집중함.
2. 다리 등의 부분은 적은 텍스쳐 이용
3. 렌더링 기법
1. 포워드 렌더링
1. 하드웨어가 발달하기 전 사용된 방식이라 라이팅 연산 등은 느리지만, 대신 리소스 소모가 적다는 것이 강점
2. 속도적인 문제를 해결하기 위해 MSAA 등의 방법을 이용



*vr 컨텐츠 개발시 리소스를 줄이는 것은 매우 중요

  4. 아이펀 엔진 개발 노트 - 문대경

1. 네트워크 엔진이 아닌 서버 프레임워크 개발에 대한 일지 및 느낀점 등에 대해서 알려주기 위한 주제
2. 개발 과정 순서
1. 배포 관련
1. 먼저 사용자에게 배포를 하기 위해 플랫폼 및 패키징 방식들에 대해 개발이 되어야 한다.
2. 프로그래밍 모델 관련
1. 솔루션에 사용될 데이터, 로직 등을 가진 모델을 구현을 해야 한다.(본 구현)
3. 운영 및 관리 관련
1. 솔루션을 운영하고 지속적으로 관리를 하기 위한 부분의 구현
3. 결언
1. 솔루션 배포 방식을 고민하라
1. 처음부터 패키지를 업그레이드하는 방식에 대한 고려가 필요
2. 설치 과정이 단순해야 함(out of box 방식)
2. 버그는 치명적이다.
1. 패치를 한 번 내보내도 해당 버그가 오랫동안 수정이 안될 수 있다.(갤럭시 S7)
2. 한 번 등을 돌린 사용자는 돌아오지 않는다.
4. 추가된 결언
1. Peer Code review의 생활화
1. 버그의 가능성을 개발자가 아니라 시스템으로 풀어야 한다.
2. peer가 code를 review 함으로써 나 혼자가 아닌 2명 이상의 사람이 서로 공유가 된다.
2. 빌드는 자동화 하라
1. 빌드 자동화는 일관된 품질을 보장하는데 도움이 됨
2. 작업자의 결과물에 따른 위험을 미리 제거하는 것이 가능
3. 문서화는 매우 중요하다.
1. 문서화가 되어 있지 않으면 다른 사람들이 해당 제품에 대해서 알 수가 없음.
2. 문서는 솔루션에 있어 UI나 다름이 없음.
4. black box라는 것을 명심하라
1. 사용자는 안에 코드가 어떤지 어떻게 구현되어 있는지 모른다.
2. 인터페이스는 최소화하고 동작은 직관적이게 해야 한다.
5. 서비스 운영/모니터링에 신경써라
1. Black box를 진단하는 방식에 신경을 써야한다.
5. Co-Work의 중요성
1. 프로젝트는 내가 잘났다는 것을 과시하기 위해서 하는 것이 아님.
1. 읽기 쉬운 코드 선호(서로간의 code review)
2. 상세한 commitlog의 활성화
3. 내 코드를 쓰면서 동료가 실수한다면 동료가 바보가 아니라 나 혼자만을 위한 코드를 짠 것이다.(중요)
6. 서버 엔진 vs 네트워크 엔진
1. 서버 엔진
1. 전반적인 생산성과 확장성을 고려해야 한다.

  5. Kubernetes로 개발서버 간단히 찍어내기 - 오승용

1. devOps enginner : 엔지니어가, 프로그래밍하고, 빌드하고, 직접 시스템에 배포 및 서비스를 RUN한다. 그리고, 사용자와 끊임 없이 Interaction하면서 서비스를 개선해 나가는 개발자들을 통칭
   
2. 개발 과정
1. Develop - QA - Stage - Product
1. Develop : 개발 서버 환경, server와 client가 처음 만나는 환경
2. QA : 검수 과정, 각종 테스트
3. Stage : 사용자에게 넘어가기 전 전체적으로 점검하는 곳
4. Product : 사용자가 최종적으로 사용하는 솔루션
2. 1개의 develop branch를 사용하지 않는 이유
1. 1개만 사용을 하게 되면 여러 개의 작업을 동시에 실행하는 경우 한 부분을 수정시 다른 부분에 문제를 일으킬 가능성이 높다.
2. 따라서 수정 사항 1개당 1개 이상의 branch를 가지고 있는 것이 중요하다.
3. 예시 사례
1. 로그인 API 변동 ->(인증 Protocol이 변경) -> develop branch ->(API 미호환) -> UX 개선팀에서 오류 발생
1. protocol의 변경이 이미 정상적으로 작동중인 전체적인 기능들에 문제를 발생시킬 수 있음
2. 해결해야 하는 것
1. balance 변경이 영향을 주게하고 싶지 않음
2. 이벤트 QA시 서버 시간 변경을 할 때 다른 서버에 영향을 주고 싶지 않다.
3. test client로부터 동작이 제대로 안된다는 메일을 받고 싶지 않다.
3. 해결 방법
1. 기능 개수많금 develop 서버를 띄우면 된다.
1. 개 수가 많고 사용을 안하면 risk가 된다.
2. 시점에 따른 server를 구현해야 한다.
3. Container orchestration
1. ngix server 이용
2. scheduling
1. 새로 띄운 docker container를 여러대 띄우기
3. Amazon ECS(현재 사용하지 않음
1. AWS에 의존성이 강함
2. 복잡, 기능 부실
4. Docker
1. Swarm mode
2. 심플하지 않음
3. 기능 부족
5. Kubernetes
1. SVC 구조(service view controller)
4. Pod (docker contatiner의 최소 단위)
3. kube -AWS
1. 필요에 따라 서버를 유동적으로 띄울 수 있다.
2. 운영 비용이 감소한다.

  6. 싱글 스레드로 서버를 만들 수 있을까? - 성우경

1. 파이썬
1. library, 참고자료가 많음
2. 멀티 플랫폼
3. 아마존 AWS 친화적
4. I/O에 intensive
5. 수평 확장을 고려
2. Python3.4에서 변경점
1. asyncio
1. 스레드 한 개로 완전 서버를 구성하는 것이 가능
2. 싱글 스레드에서 eventloop 이용
2. 코루틴을 이용하여 inner loop를 제거하는 것이 가능
3. 멀티 프로세스 서버를 구현 가능
1. 장점
1. 서버 프로세스가 각각 독립적으로 가능
2. 확장하기 쉽고 편함
4. 기존 비동기, 코루틴 기반 라이브러리의 종류
1. eventlet
2. gevent
5. 모든 것들을 async하게 하기 때문에 block이 걸리지 않음
1. 멀티 쓰레드의 경우 blcok이 있으면 서버가 정지
2. db가 중간에 있는 경우 response가 올 때까지 block 가능성이 있음(해결 코드 필요)

  7. 멀티게임 5일 완성 - 이현승

1. Python을 사용하는 목적
1. 범용적으로 사용
2. 멀티 플랫폼
3. AWS(Amazon Web Service) 친화적
1. Python의 구성
1. 제네레이터
2. 데코레이터
3. 메타클래스
2. I/O Bound vs CPU Bound
1. I/O Bound: 동시성
2. CPU Bound: 병렬성
3. range(5): 이전에는 숫자의 범위였지만 python 3 부터는 iterator 개념으로 바뀜
4. 일반적인 함수의 경우
1. 코드 실행 - 네트워크 대기 시작 - (대기) - 응답 - 코드 실행(다른 코드 실행)
2. 네트워크에서 응답이 올때까지 대기하는 시간(block)이 존재
5. asyncio의 경우
1. 싱글 스레드로 범용 서버 구현 가능
2. non-block
3. event를 호출 형식으로 사용
4. 콜백 대신 코루틴 사용

NDC 주요 주제

1. VR : 풀 VR 기반의 컨텐츠 개발

2. Python 단일 스레드 서버 개발, python 3.5의 asyncio api

---

후기 및 느낀점

  이번 ndc는 시간과 일정상으로 모든 세션을 참여한 것이 아니라 2일차에 관심있는 세션들이 많아서 2일차 위주로 참여를 했었습니다.

2일차 세션을 들으면서 ndc에서는 매년 주요 it 기술(게임 산업 쪽에 가깝기는 하지만)의 트렌드를 볼 수 있던 기회였던 것 같습니다. 2년 전에는 script 기반의 내용들이 많았던 것으로 기억을 했었습니다. 그런데 2년이 지난 이번 ndc에서는 python 단일 서버에 관련된 내용들이 많았었습니다. 대학교에 다니면서 서버쪽에 관심을 많이 가져서 nodejs 서버, c로 구성된 서버 등을 제 컴퓨터에서 구동을 했었던 저로써는 다시 서버에 대한 열정을 되살아나게 해준 좋은 기회였습니다.

  이번에 들었던 다양한 ndc의 세션들을 참고해서 개인적으로 파이썬 서버를 기반으로 한 프로젝트를 진행해 볼 생각입니다. 처음 접해보는 python을 공부하고 관련된 웹 프로젝트를 기획중에 있습니다.