[컨퍼런스] NDC(Nexon Developer Conference) (2022/06/08~06/11)

이번에는 NDC(NEXON DEVELOPER CONFERENCE) 후기를 작성해보고자 한다. 컨퍼런스 시작할 시점에는 바빠서 직접 듣지 못했지만, 아직 온라인에 많은 세션들이 올라와있다. 일부 세션만 영상이 내려간 상태라고 한다.

NDC-NEXON DEVELOPERS CONFERENCE

NDC-NEXON DEVELOPERS CONFERENCE

 

NDC를 이번에 보긴했지만, 컨퍼런스 전에 세션 목록을 보고 기대하고 있던 컨퍼런스였다. 다행히 아직도 많은 세션이 온라인으로 있었다. 보고 싶은 세션만 골랐는데도 10개나 골랐다.

 

그중에 오늘은 개발 관련된 5개 세션에 대해서 요약 및 후기를 작성하고자 한다. 나머지 5개는 개발이라기보다는 경력/운영/마케팅 등에 대한 세션이다. 이 세션들에 대한 내용도 추가할 수도 있겠지만, 아직 몇 개는 보지 못했기도 했고 요약 내용을 추가할 생각이 지금은 없다.

 

전체적으로 이전에 들었던 AWS나 Google의 컨퍼런스보다 더 재밌었고 알찼다. 자신들의 제품을 홍보하기 위한 컨퍼런스의 느낌을 받지 못하고 세미나 같은 성격이 강했다. 이런 국내 컨퍼런스들이 많이 있으면 좋겠다.

---

1. 라즈베리 파이로 직접 만드는 네트워크 시뮬레이터

NDC | 온라인세션 (nexon.com)

NDC|온라인세션|라즈베리 파이로 직접 만드는 네트워크 시뮬레이터

첫 번째 세션은 '라즈베리 파이로 직접 만드는 네트워크 시뮬레이터'로 들었다. 임베디드는 개발을 못 해봐서 궁금한 것도 있었고, 회사 업무가 네트워크 관련된 일을 하고 있는데 실제 사용되는 다양한 네트워크 환경에서 재현이 안 되는 이슈들도 있어서 테스트에 어떻게 적용할 수 있을지 궁금하기도 했다.

 

강연에서는 내가 겪었던 어려움과 비슷하게 실제 네트워크 환경에서의 불안정성 때문에 개발을 했다고 한다. 개발 중에는 확인이 어려운 부분이라 실제 배포 후에 네트워크로 시달리는 경우가 많았다고 하는데, 공감됐다.

자세한 실제 코드로 강연을 하지는 않았지만, 대부분 리눅스 도구들을 그대로 사용한 것으로 보였다. 개발을 크게 3가지로 나눠서 진행을 했다고 한다.

1. 트래픽 속도 조절 및 불안정한 네트워크 상황 재현
   • 리눅스의 iproute2의 트래픽 컨트롤(tc)를 이용했다.
   • tc 중에는 qdisc를 이용해 패킷에 대한 큐 처리를 제어할 수 있다.
   • 기본적으로는 ingress 패킷에 대한 제어가 불가능하기 때문에, ifb를 ingress 방향에 삽입 후 ifb의 egress 방향을 제어함으로써 양방향 패킷에 대한 제어를 수행했다.
2. 무선 AP 만들고 IP 동적 할당
   • 기기가 라즈베리 파이에 Wi-Fi 신호를 잡아서 연결할 수 있도록 해야 한다.
   • 무선 AP를 만들기 위해 hostapd를 사용했으며, DHCP 서버를 통해 동적 IP를 할당했다.
3. 연결된 기기 모두 인터넷을 자유롭게 사용하기
   • 동적 IP는 private IP였기 때문에 인터넷 사용에 제한이 있다.
   • Masquerading rule을 사용해 여러 pirvate IP에 대한 Source NAT를 적용했다.

이외에도 도메인별 환경 제현을 위해 eBFD를 사용했다. 위의 3가지 개발 내용은 전체 네트워크에 대한 제어라면, eBFD로 특정 패킷만 제어할 수 있도록 했다.

동적 컨텐츠 제공은 CDN을 사용하는데, CDN 특성상 전세계에서 빠르게 접속이 가능하다. 하지만 서비스를 제공하는 우리들의 서버는 속도가 느리기 때문에 도메인별로 패킷을 분류할 필요가 있다. tc의 filter를 사용해 패킷 별로 qdisc를 나눠서 분류할 수 있다. 하지만 도메인별 패킷을 분류하기에는 여러 문제가 있다. 시간과 공간에 따라 서로 다른 IP를 표시할 수 있는 위험이 있어, 도메인 주소는 항상 IP로 변경해주는 작업이 필요하다. 이때 도메인은 여러 IP를 가질 수 있기 때문에 모든 IP에 대한 필터가 필요하다. 여기서 필요한 게 eBPF로, 어떤 프로그램을 커널에서 안전하고 빠르게 실행시켜줄 수 있는 기능이다.

eBPF를 네트워크 인터페이스에 붙이면, 커널단에서 모든 패킷을 볼 수 있게 된다. 여기서 DNS 패킷을 모두 뽑아 IP 변환을 할 수 있는 것이다.

 

마지막으로, 디스플레이와 버튼을 연결해 사용자가 직접 제어할 수 있도록 했다. 리눅스이기 때문에 물리버튼 입력은 GPIO 신호를 파일로 읽고 쓰면 된다. 디스플레이도 마찬가지로 파일로 읽고 쓰면 된다.

 

전체적인 개념은 알았으니, 나중에 토이 프로젝트 겸으로 한 번 해보고 싶었다. 우선 저번에 하다가 멈췄던 것부터 후딱 끝내고 할지 말지 고민해봐야겠다.

---

2. <카트라이더: 드리프트> 머신러닝을 활용한 위치 예측 개선

NDC | 온라인세션 (nexon.com)

NDC|온라인세션|<카트라이더: 드리프트> 머신러닝을 활용한 위치 예측 개선

실시간 온라인 게임에서는 레이턴시가 중요하다. 그런데 레이싱 게임과 같은 것들은 정말 작은 시간 단위도 중요하다. 상대의 위치를 어떻게 그렇게 동시에 게임하는 것처럼 보이는지 항상 궁금했다. 그러다 보니 자연스럽게 이 강연에 흥미가 갔다.

 

강연에서도 상대의 위치를 어떻게 보다 현재의 상대방 위치를 내 화면에 보여줄지를 고민한 내용이다.

 

기본적으로 온라인 <카트라이더> 게임은 '등속 예측 모델'을 사용한다고 한다. 과거의 위치와 속도를 통해 패킷에 기록된 시간 이후 일정하게 이동했다고 가정하며 예측하는 것이다. 곡선 주행에서의 문제는 인터넷 상태가 좋다면 크게 문제 될 게 없다고 한다. PC 게임이며 한국에 서버가 있다 보니 레이턴시(20ms)가 비교적 낮아 '등속 예측 모델'로도 충분하다.

하지만, <카트라이더: 드리프트>는 상황이 다르다. 모바일 게임이며 글로벌 게임 제공을 목적으로 서버가 외국에 있어, 한국 유저들끼리 만나도 레이턴시(50ms)가 비교적 높다. 그래서 '등속 예측 모델'만으로는 정확한 위치를 표시하지 못하고 레이싱에 문제가 있었다.

 

고려사항은 두 가지였다. 연산량이 많지 않으면서 네트워크 환경에 레이턴시가 있어도 서비스가 가능할 정도여야 했다.

 

다양한 모델들을 테스트했지만, 초반에는 ML을 도입해 Linear Regression(선형 회귀) 모델을 적용했다. 연산량이 적고 오차가 약간 개선되었다. 여기서 추가적인 튜닝에 대한 한계가 있었고, 데이터가 비정형 정보라 판단해 DL을 도입하기 시작했다.

DL도 여러 모델을 사용했지만, 최종적으로 DNN-GLU 모델을 사용했다. 다른 모델들보다 계산량이 적어 모바일 환경에서도 적합한 것이 이유였다.

 

하지만, 현재도 200ms 이상의 레이턴시가 발생하면 카트가 밀려서 표시되는 문제가 있다. 현재도 계속해서 개선하고자 노력 중이고, 현재는 유저들의 드리프트 타이밍을 통해 드리프트를 미리 예측하는 것을 도입을 고려한다고 한다.

 

친숙한 게임을 통해서 개선되어져가는 모습들을 영상을 통해 확인하니 이해가 잘 됐다. 그리고 생각만 했을 때는 정말 레이턴시를 잡는 게 어려울 것 같다고 생각했는데, 실제는 더 어려운 것 같아 얼마나 지금 서비스되고 있는 게임들이 대단한지 새삼 느꼈다.

---

3. <달빛조각사>에서 서버 테스트 코드를 작성하는 방법

NDC | 온라인세션 (nexon.com)

NDC|온라인세션|<달빛조각사>에서 서버 테스트 코드를 작성하는 방법

'서버' 그리고 '테스트 코드'를 보고 관심이 많이 갔다. 요즘 테스트 코드를 추가하고 싶은데 회사에서는 JAVA에 비해 C++은 그런 문화가 없는 것 같아 아쉬웠다. 여기서 감을 잡을 수 있으면 우리 회사에도 어떤 방식으로 도입하자고 말할 수 있지 않을까 싶었다.

강연에서는 처음 도입한 사례는 아니었고, 도입되어있는 곳에서 발전시켜나간 내용이었다. 그래도 도입 시점의 내용도 잠깐 다뤄줘서 전체적인 흐름을 볼 수 있었다.

 

기본적으로 4가지 스텝으로 서버 테스트 코드를 정착시켰다고 한다.

1. 서버 테스트 뿌리내리기
   • 초반 작업 : 구성원들의 동의 / 테스트 환경 구축 / 주요 로직(필수 콘텐츠) 테스트
   • 이후 작업
     • 테스트 성공 상태 항상 유지 : CI/CD를 도입해 커밋 시 자동으로 테스트가 되도록 시스템을 구축했다. gitlab과 슬랙을 연동해 상태를 항상 확인하고 있다. 마스터 브랜치로 머지될 때도 전체 테스트가 수행되고 있다.
     • 테스트 추가 : 테스트 추가 규칙은 별도로 없다. 하지만, 테스트를 깨면 반드시 고쳐야 한다는 것이 규칙이다. 테스트 작성법은 코드 리뷰를 통해 자연스럽게 전파되었다.
     • 테스트 기반 다지기 : 더 짜기 쉽게, 더 빠르게(최적화), 구조적 개선을 진행한다.
2. 서버 테스트 작성하기
   • 유닛 테스트 : 통합 테스트 = 10 : 90
     • 보통은 유닛 테스트(단위 테스트)가 더 많은데, <달빛조각사>는 아니다.
     • E2E(End-to-End) 테스트는 수행하지 않는다.
   • 유닛 테스트는 다양한 케이스에 대한 테스트가 필요할 때만 사용하고 있다.
   • 통합 테스트는 유닛 테스트보다 느리지만, 효용성이 뛰어나다. 서버 컨텐츠 자체를 테스트하기 때문에 어려운 버그도 단위 테스트보다 쉽게 재현이 되기도 한다.
3. 더 짜기 쉽고 더 튼튼하게 기반 코드 만들기
   • <달빛조각사>에서는 elixier 테스트 프레임워크를 사용한다.
   • 속성 셋업을 통해 테스트 코드 작성에 집중해, 테스트 코드의 가독성을 높일 수 있었다.
   • 일부로 패킷 순서가 깨지기 쉬운 테스트를 만들고, sleep 등을 통해 지연 환경을 두기도 했다.
   • 간격을 두고 비정상 상황에 대해 여러번 테스트하면서 처리를 확인했다.
4. 더 빠르게 하기
   • 점점 테스트가 많아져 병렬 테스트로 전환을 시도했다.
   • 이때 게임 테이블 데이터 수정이 문제였다. 병렬 테스트 때 동일 데이터를 보는 다른 테스트가 영향을 받는다. 추적이 어렵고 재현도 어렵다.
   • 테스트가 독립적으로 수행될 수 있도록 해야 하며, 새로운 데이터를 추가해 같은 데이터를 수정하지 않도록 했다.

테스트를 짜는게 막막하다면, <달빛조각사>와 같이 통합 테스트 단위부터 추가하는 것도 좋은 방법이다. 시나리오(스토리) 작성에 훨씬 유리하다. 그리고, 처음부터 테스트가 많아질 것을 고려해 처음부터 병렬 테스트가 가능하도록 작성하는 것이 좋다.

 

실제 온라인 게임 회사에서는 테스트를 어떻게 다루는지에 대해 살펴볼 수 있었다. 우리 회사도 분야는 다르지만, 충분히 적용 가능한 내용들로 보였다.

---

4. 엑셀도 머지가 된다구요? - 3-way merge 도구 <XlsxMerge> 개발 이야기

NDC | 온라인세션 (nexon.com)

NDC|온라인세션|엑셀도 머지가 된다구요? - 3-way merge 도구 <XlsxMerge> 개발 이야기

엑셀에 대한 Diff 해주는 툴이 있는지도 몰랐는데, 이 프로그램은 3-way merge까지 된다고 한다. 궁금해서 안 볼 수가 없었다.

 

게임 개발자들에게 엑셀은 특히 자주 쓰는 프로그램 중 하나라고 한다. 테이블부터 수치 계산까지 다양한 것들에 대해 논리적 생각을 도와준다. 게임의 설정 및 여러 옵션 값들도 테이블로 관리가 될 것이다. 그래서 이 엑셀 파일도 형상관리를 하고 있다고 한다.

 

그런데, 엑셀에 적힌 내용들은 항상 조심해야 하는 정보들이다. 중요한 정보가 있어서 그런 것도 있지만, 다른 문제들도 더 있다. 먼저, 엑셀에 적힌 정보들은 상대적으로 믿음직스럽다. 그리고, 각 정보들에 수식이 연결되어있으면 작은 실수로도 큰 임팩트가 발생할 수 있다. 또, 엑셀은 두 파일 비교가 어렵다는 점과 동시 작업이 어렵다는 단점이 있다. 이런 문제들을 해결하기 위해 개발을 했다고 한다.

형상관리 서버와도 쉽게 연결이 가능하며, 이로인해 변경 사항들에 대한 추적이 용이해지는 장점이 있다.

 

다른 강연과 달리 좀 가볍게 들었다. 단순히 Diff만 제공하더라도 어려워 보이는 데, 머지까지 해준다는 게 어떤 규칙이 있을지 궁금했다. 이 강연 내용도 역시 나중에 토이 프로젝트처럼 다른 머지 도구를 개발해도 좋을 것 같다는 생각이 들었다.

 

실제 업무나 생활에서 필요하다고 생각한 것들을 직접 만드는 과정들이 멋있어서 개발자라는 길을 택했었다. 이분 강연을 들으면서 그런 생각들이 다시 떠올랐다.

---

5. 실시간 MMORPG의 플레이 감각을 날카롭게 벼려보자! - 예측과 보정을 통한 자연스러운 동기화

NDC | 온라인세션 (nexon.com)

NDC|온라인세션|실시간 MMORPG의 플레이 감각을 날카롭게 벼려보자! - 예측과 보정을 통한 자연스러

<프라시아 전기>라는 개발 중인 게임에서의 동기화 내용을 다룬다. <카트라이더: 드리프트> 강연에서와 같이 레이턴시를 고려한 것으로 보였다. 서로 다른 게임 장르인데 어떻게 다르게 처리를 했을까 궁금했다. 강연 제목만 봐서는 <카트라이더: 드리프트>와 같이 ML/DL을 도입한 것처럼 느껴졌다. 실제 강연 내용에서는 ML/DL을 도입했다는 언급은 없었다.

 

이 강연에서의 레이턴시를 보정하는 작업은 예측과 보정이다. 예측을 통해 동기화 준비를 하고, 예측을 틀렸을 때는 적절한 보정으로 동기화를 수행한다. 실제로 한 가지씩 사례를 들어 설명해줬다.

1. 차지게 때리기(예측 사례)
   • LTE에서 손맛이 떨어지는 문제가 생겼다. 천천히 재생하며 플레이 화면을 확인을 해보니, 실제 타격과 타격 이팩트가 달라서 발생한 문제였다.
   • 문제의 발단은 스킬들의 종류가 다양해지면서였다. 타겟 스킬만 있을 때는 문제가 없었다. 논타겟 스킬부터 점차 스킬 시작 시점과 타격 대상 선정 시점이 달라지면서, 스킬을 시전 하는 도중에 계속해서 시점을 계산해야 했다.
   • 이러한 계산을 시스템화해서 '스킬 스테이지'라는 개념을 도입했다. 여러 스킬들이 하나의 스테이지를 거치면서 조합된다.
   • '스킬 스테이지'는 레이턴시가 고려되지 않았고, 이로 인해서 결과적으로 손맛이 떨어졌다.
   • 한 번에 계산할 수 없어 '스킬 스테이지'를 도입한 것이기 때문에, 여러 스테이지 결과를 미리 결정하고 공유하는 예측 시스템을 만들어 해결했다.
2. 정확하게 때리기(보정 사례)
   • 가만히 서있는 대상에게 피격이 되지 않는 문제가 생겼다. 서버가 파악한 상대 위치, 내게 보이는 상대 위치, 실제 상대 화면에서의 상대 위치가 모두 달랐다. 게임 이동 시스템상의 문제다.
   • 게임 서버로부터 이동을 허락받고 움직이면 조작감과 반응성이 너무 떨어진다. 그래서 클라이언트에서 먼저 이동 후 서버로 알리는 방법을 도입했다.
   • 그러다보니, 이동하다 멈춘 경우에는 점점 예전 위치만 갖게 되었다. 멈춘 시점의 위치를 최종적으로 반영하도록 하면, 상대 위치가 뚝뚝 끊기는 느낌이 들게 됐다.
   • 멈춘 시점에 보정 구간을 만들도록 했다. 피어 별로 이동 중의 오차 레이턴시를 의도적으로 늘렸다. 이것으로 보정 시간을 최대한 확보한 것이다.
   • 멈출 때의 위치가 달라 피격이 안 되는 최악의 상황을 피하기 위해 의도적인 레이턴시 보정을 한 것이다.

 

이 세션을 보고 정말 흥미로웠던게, <카트라이더: 드리프트>는 최대한 레이턴시에 맞춰 빠르게 계산하고 정확한 위치를 전달하고자 했던 것과 달랐다. 예측 사례에서는 하나의 프로세스를 도입하면서 빠르게 예측을 할 수 있도록 했지만, 보정을 할 때는 의도적으로 시간을 줬기 때문이다. 게임마다 특징에 따라 다른 특징들을 보여줬다. 둘 다 모바일 환경이지만 집중하는 것이 달랐고, 그에 따라 대처도 달랐다.

<카트라이더: 드리프트>는 최소 연산으로 최대한 빨리 다음 위치를 예측하는 것에 대해 노력했다면, <프라시아 전기>는 상대적으로 많은 정보와 적은 통신으로 예측/보정을 하려고 했다고 느껴졌다.

---

이렇듯 전에 들었던 AWS와 Google의 컨퍼런스와 달리 자신들의 제품을 홍보하기 위함이 우선순위가 아닌 강연들이 많았다. 개발 외의 것들은 특히 더 그랬다. 아무튼 재밌었고, 다른 개발 외의 강연들도 마저 봐야겠다.