모바일 환경에서도 온라인 게임을 즐길 수 있는 이유

■ 상황 요약
게임을 플레이할 때 거의 무선 통신을 이용해서 게임을 한다. 스마트폰으로 WiFi 나 LTE 혹은 간혹 3G 통신을 쓰기도 하고, PC나 랩탑으로 게임을 할 때도 굳이 유선 랜을 쓰는게 선 없이 아니라 WiFi를 쓰기도 한다.

무선 통신으로 보내는 메시지는 얼마나 잘 깨질까?

1
▲ 출처 : https://xkcd.com/654/

  1. 여보세요. 메건 찾아? 걔 게임 중이야 / 알아. 근데 나초가 참 맛있는데.
  2. 나초 칩 위에 모두 치즈를 얹고, 쑤어 크림이랑 살사에 빠뜨리면…
  3. 으음 그거 맛있지. 재료도 다 있네. / 만들어 봐! / 그럴께 / 어서!
  4. (전자렌지 돌아가는 소리)
  5. 내 WiFi!
  6. (쾅) 헤드샷.

조금 과장되긴 했지만, 전자렌지를 쓰면 흔히 2.4 GHz 대역을 쓰는 WiFi 신호에 악영향을 준다. (사실 이건 WiFi가 쓰는 ISM 대역은 전자렌지가 방출하는 신호 때문에 간섭이 커서, 다른 용도로 할당하기 어려워서 특정 기준만 만족하면 아무나 쓸 수 있는 대역이라 그런 것이다.)


■ 문제
무선 환경 자체가 어떤 문제를 주는가? 물리적인 문제와 게임에서 흔히 쓰는 TCP 프로토콜 자체의 문제를 확인해보겠다.


무선 환경에 영향을 주는 것들
WiFi 처럼 주파수 대역을 다른 통신 방식 (Bluetooth, …) 이나 전자렌지 같은 전자 제품과 공유하지 않는 경우에도, 무선 통신은 여러 가지 문제를 겪는다.

우선 무선 신호를 쏘면 이 신호는 감쇄 (attenuation 혹은 path-loss) 된다. 물리법칙에 의해 먼거리를 갈수록 신호 세기가 줄어든다. 그래서 스마트폰 게임을 할 때 기지국 (base station) 과의 거리가 멀면 통신 상태가 고르지 않은 경우가 있다.

또한 무선 신호는 중간의 장애물 등으로 인해 음영지역 (shadowing) 이 생길 수 있다. 특히 WiFi 나 3G, 혹은 LTE 에서 사용하는 주파수는 30 Mhz 보다 큰 상대적으로 고주파 대역이다.(수백에서 수 기가 Hz 정도의 영역) 이 경우 사실상 무선 신호는 직진하는 것에 가깝다. 그래서 장애물이 있다면 신호 전송이 쉽지 않다. 다만 상대적으로 큰 물체 — 예를 들어 큰 빌딩 — 에는 신호가 “반사” 해서 신호가 가기는 한다. 반사되면서 세기가 좀 줄어들기는 해도 말이다.

마지막으로, 직진해서 온 신호, (여러 경로로 )반사된 신호가 모두 스마트폰 등에 도착한다. 그러면 진행해 온 경로에 따라서 도착하는 시간에 미묘한 차이가 생기고, 이에따라 상쇄/보강 간섭도 일어난다. 그리고 좀 더 미세한 수준에서 보면, (시간 상으로) 이전에 보낸 신호가 늦게 도착해서, (시간 상으로) 현재에 해당하는 신호와 서로 간섭을 일으켜서 문제를 일으키기도 한다.

덤으로, 모바일 게임의 경우 한 자리에서만 플레이하는 것도 아니다. 걸어다니면서 (포켓몬 고?), 혹은 자동차나 지하철, 기차 등을 타고 이동하면서 플레이하는 것도 흔하다. 이 경우 기지국과의 이동 방향/속도에 따라서 도플러 효과가 발생하고, 인접한 주파수 대역을 쓰는 다른 통신, 혹은 자신의 통신의 다른 부분에 (악)영향을 준다.

유선 통신인 10G Ethernet 의 경우, 상대적으로 나중에 나온 표준이고 데이터센터 환경에 가까운 곳에서 쓰기 때문에 비트 오류율 (BER) 목표치가 대략 1/10^12 다. 즉, 1 Tbit 정도 보내면 오류가 하나 이하인 확률을 의미한다. 대략 이런 환경에서 하나의 일반 이더넷 (ethernet) 프레임 하나 (1500 bytes 정도)가 잘못 전송될 확률은 약 0.00000015 % 정도다. 거의 오류 날 확률이 없는 셈.

반대로 LTE 환경에서 최대 전송속도일 때 쓰는 64-QAM 의 경우 BER은 1/10^3 수준까지 올라갈 수도 있다. 아주 나이브하게 계산하면 이더넷 프레임 하나를 보냈을 때 오류 없이 전송할 확률이 22% 쯤 된다.


TCP 특성
TCP는 현재의 인터넷을 움직이는 가장 중요한 전송 프로토콜입니다. 아마 네트워크 간 연결 (즉 인터넷 그 자체) 을 담당하는 IP 만큼이나 중요한 프로토콜로 그 역사가 길기도 합니다. TCP 설계 철학과 구현에서 모바일에 영향을 받는 부분은 아래와 같다.

  • 종단간 원칙 (end-to-end principle): 통신하는 양쪽 끝의 주체 — 게임이라면 게임 서버와 클라이언트 — 에서 필요로하는 정보만 프로토콜에 담으며, 이를 이용해서 잘 할 수 있는 것만 처리. 예를 들어 TCP는 종단간 RTT 를 측정하고, 이를 이용해서 그 사이에 들어갈 수 있는 (전송 중인) 메시지 양을 추정하고, 이 값을 이용해서 혼잡 제어를 수행한다.
  • 약한 체크섬: 현대적인 관점에서 볼 때, 단순히 전체 메시지의 바이트 합으로만 이뤄진 16bit 체크섬은 오류를 복구할 수 없으며, 검출할 수 있는 오류 수에도 한계가 있습니다.
  • (상대적으로) 오류 없는 하위 계층에 대한 가정: TCP 메시지가 중간에 손실되거나 중복 전송되면 메시지가 없어진 이유가 적대적인 무선 환경 (혹은 데이터링크/물리 계층) 때문이 아니라, 메시지가 너무 많아서 생긴 혼잡 제어로 인해 없어진것이라고 가정하는 것.

 
■ 해결책
앞서 말한 내용만 놓고보면, 현대의 무선 통신은 오류도 엄청 날 것 같고, 그 오류 위에서 TCP를 쓰는건 말도 안되는 일 같다. 하지만 지금 모바일 게임을 플레이하면 전혀 그런 문제를 겪는 것 같지 않다. 왜 그런지 살펴봅시다.


채널 코딩
무선으로 신호를 보내는 (논리적이고도 물리적인) 주파수 대역을 “채널” 이라고 부릅니다. 이 채널에 신호를 보낼 때 0을 0, 1을 1로 보내는게 아니라,

  • 오류가 있다면 이걸 감지하고
  • 감지된 오류가 있다면 수정할 수 있는 여러 bit의 심볼로 변환하는

방식으로 바꿔서 보냅니다. 이런 방식을 오류를 인지하면 재전송하는 방식 (Backward Error Correction) 에 빗대어 FEC (Forward Error Correction) 이라고 부른다. 이런 변환은 “채널 코딩” 이라고 부릅니다. 가장 흔히 쓰이고, 다른 더 복잡한 채널 코딩 방식의 기반이 되는 컨볼루션 코드 (convolutional code) 는 다음과 같이 만든다.

2

  • 입력이 들어올 때마다 하나씩 오른쪽 레지스터로 시프트
  • 레지스터에 들어있는 값과 입력값이 각각 + 로 표시한 xor 게이트를 거쳐서 출력으로.
  • 입력에 대한 처리가 끝나면, 레지스터 값들이 0이 될 때까지 0을 추가로 넣는다. (그 동안 값도 출력으로 사용)

예제로 든 컨볼루션 코드는 1/3 rate 코드라고 부르는데, 입력 값 대비 출력 값이 세 배라서. 인코딩한 결과는 받는 쪽에서 SW를 사용하는 경우 Viterbi 알고리즘을 써서 다이너믹 프로그래밍으로 디코딩하거나, 이에 대응하는 Trellis diagram 을 하드웨어로 만든 구현을 써서 디코딩한다.

3

위 인코더에서 m_1 은 상태에 포함되지 않는 입력 값이라서, 상태 값은 2 bit으로 표현되고, 시작과 끝은 00 이고 이걸 이용해서 오류를 수정한다. 여기서 0이 들어왔을 때의 상태 전이를 실선, 1이 들어왔을 때의 상태 전이를 점선으로 표현하고, 한 bit 들어올 때마다 오른 쪽으로 한 칸씩 움직이는 걸 의미한다. 시작과 끝이 00 이고, 일부 bit이 오류일 수 있을 때, 이 중 가장 높은 확률인 경로를 찾는 다이너믹 프로그래밍 알고리즘이 Viterbi 알고리즘이다. 위 다이어그램에서 해당 알고리즘으로 붉은 선으로 표시된 것이 해당 경로다. (0, 1, 0, 1 이 전송된 것으로 판정)

추가로 이런 컨볼루션 코드 출력 결과를 양 끝단에서 서로 동의한 형태로 일부 bit을 제거해서 — puncturing 이라고 부른다 — 통신 환경이 양호할 때 오류율을 거의 증가시키지 않으면서 전송량을 늘릴 수도 있다.

터보 코딩과 LDPC
이 컨볼루션 코드는 802.11 WLAN — 흔히 말하는 WiFi — 나 GSM 을 사용하는 3G 통신 등에 광범위하게 사용한다. 이런 컨볼루션 코드를 기반으로 해서 더 좋은 성능 — 더 좋은 채널 코딩 후의 BER — 을 갖는 채널 코딩도 존재한다. 802.11ac 에서는 LDPC 를 써서 추가적인 성능을 끌어내고, LTE나 심우주 임무 (deep-space mission) 에서는 터보코드를 이용한다.

터보코드는 두 개의 컨볼루션 코드를 써서, 데이터, 데이터에 대한 패리티, 데이터의 순서를 (미리 정의한 방법을 써서) 섞은 것(인터리브)에 대한 패리티를 보낸다. (두 패리티를 각각 컨볼루션 코드 인코더를 이용해서 생성합니다) 디코딩하는 단계가 “터보”에 해당하는 단계입니다. 이 부분은,

  • 데이터에 대한 디코딩 — 단 0, 1을 고르는게 아니라 0, 1일 확률을 구하는 — 을 수행
  • 인터리브한 데이터에 대한 디코딩 (역시 확률을 구함)
  • 다시 이 데이터를 가지고 데이터 디코딩 (첫 단계의 반복)
  • 인터리브에 대한 디코딩을 수행

이렇게 데이터 디코딩을 반복해서 BER을 향상시키는 방식으로 동작한다. 그리고 반복마다 BER이 내려간다. (즉 더 잘 디코딩한다)

예를 들어 LTE 시스템에서 얘기하는 1/10^3 정도의 오류율을 갖는 채널이 있을 때, 이 위에 터보 코드를 끼얹으면 약 1/10^6 이하의 (유효한) BER로 감소한다. 즉, 이더넷 프레임을 하나 보낸다면 오류가 발생할 확률이 78% 에서 1% 이하수준으로 떨어진다. 또한 이 BER에서 전송이 실패했을 때는, ARQ가 자동으로 실패한 메시지를 재전송한다. (TCP와는 달리 MAC 수준에서는 수학적으로 훨씬 나은 CRC나 패리티를 이용하기 때문에, 에러가 감지되지 않고 TCP까지 올라갈 확률은 천문학적으로 낮다.)

TCP 강화
TCP는 그 긴 역사에 걸맞게 처음 프로토콜을 작성할 때완 다른 현재의 환경에 적합한 변경 사항들을 추가하고 있다. 앞에서 언급한 TCP의 문제는 다음과 같은 방책을 가지고 있다.

– 종단간 원칙 (end-to-end principle)
TCP 성능을 위해서는 종단간 왕복 시간 (RTT)에 대한 추정이 어느 정도 정확해야 한다. TCP 에 대한 RFC-7323 에선 TCP 헤더에 타임스탬프를 추가해서 RTT를 더 정확하게 측정할 방법을 제공한다. 이를 이용해서 네트워크 지연 시간의 변동으로 RTT를 제대로 측정하지 못해서 재전송이나 타임아웃이 일어나는 문제를 줄일 수 있다.

또한 대부분의 TCP 알고리즘 향상분은 OS 업데이트로 반영될 수 있어서 개발자가 크게 신경쓰지 않아도 된다. 예를 들어, TCP timestamp 가 추가된 linux kernel 버전으로 올리면 해당 효과를 바로 받을 수 있다. (현재 이미 광범위하게 사용되는 확장 기능) 비슷하게, Android 커널 버전이 올라가거나, iOS 버전업에도 비슷한 효과가 따라올 수 있다.

– 약한 체크섬
TCP 수준의 체크섬 오류가 일어나려면,

  • ECC 를 사용한 채널 코딩에서 에러 복구가 실패
  • 링크 계층의 체크섬 검사에서 확인 실패하고 통과 (CRC32)
  • IP 체크섬 검사 통과 (다만 IP의 체크섬은 TCP 수준으로 약함)

해야 가능하다. 그리고 처음 두 단계에서 대부분 걸러지기 때문에 실제로 문제를 일으킬 가능성은 매우 낮다.

– 오류 없는 하위 계층
WiFi 나 3G UMTS, 그 이후의 LTE 환경 등에서는 전송 오류 등이 발생하지 않도록 채널 코딩을 수행한다. 또한 전송 오류가 발생했을 때에도, 자동 재전송 메커니즘이 내장되어있기 때문에, 단순히 전송을 포기하는 것이 아니라 자동으로 해당 프레임을 재전송해서 TCP 계층에서 혼잡이 발생했다고 잘못판단할 가능성을 낮춘다.

TCP에서 재전송을 위한 타임아웃이 굉장히 긴데 (같은 ACK이 3번 온게 아닌 이상 2 RTT), 링크 계층의 재전송 시간은 LTE 의 경우 약 8ms 등으로 굉장히 짧아서 링크 수준의 전송 실패로 TCP 재전송이 일어날 가능성은 낮다.

■ 결론
모바일 / 무선 환경에서도 별 무리 없이 게임을 즐길 수 있는 것은 TCP 수준, 그리고 무선 통신 수준에서 광범위한 최적화가 이루어져서다. 무선 통신 수준에서는 물리적인 무선 통신 용량에 거의 근접한 채널 코딩 알고리즘이 적용되고 있으며, 새 무선 표준이 나올 때마다 — 그리고 해당 무선 표준이 통신사 망에 넓게 적용될 때 마다 — 더 나은 통신 방식으로 발전한다. 비슷하게 OS 수준의 TCP 기능 강화도 지속적으로 이뤄지고 있다. 앞으로도 이런 변화가 계속 될거라 기대하며 글을 마칩니다.

아이펀팩토리 김진욱 CTO

[인벤기고컬럼 10] 인터넷 세상에서의 캐싱 (caching)



컴퓨터 공학에서 캐시(cache) 는 굉장히 광범위하게 사용되는 개념이다. CPU 의 사양을 기재할 때 어김없이 등장하며, 하드디스크 스펙에서도 “디스크 버퍼” 라는 이름으로 표시되고, 인터넷 뱅킹이나 관공서 웹사이트에서 뭔가 안될 때 브라우저 설정 들어가서 삭제하라고 안내 받기도 하며, 웹사이트가 잘 되더라도 민망한 기록을 지우기 위해 일부러 지우기도 하는 대상이다. (개인적으로는 이런 경우에 브라우저 캐시를 지우기 보다는 in-private browsing 이나 incognito window 를 추천한다.)

1
그림 1: 인텔 CPU 소개에서 캐시는 클럭속도 다음으로 표시될 정도로 중요한 요소이다. (출처: intel.com)
2
그림 2: 인터넷 브라우저들은 임시 파일 이라는 이름으로 열었던 사이트들의 내용을 캐시로 저장한다.

.

■ 캐시는 책장에 있는 책을 책상위에 올려두는 것과 같다.

캐시(cache) 는 “은닉처” 라는 뜻의 영어 단어인데, 현금을 의미하는 cash 와 발음이 똑같아서, 컴퓨터 공학 교재에서는 캐시를 표시할 때 “$” 로 표시하기도 한다. 캐시는 매번 데이터 소스로부터 읽어들이는 것이 상당한 시간이 걸릴 때, 처음 읽어들인 데이터를 임시로 저장해두고 두번째부터는 데이터 소스까지 가지 않고 데이터를 반환하기 위한 공간이다. 마치 매번 책장에서 책을 꺼내 오는 대신 자주 쓰는 책은 책상 위에 책을 놓아두는 것과 같은 이치다.

인벤기고컬럼 본문 더보기>

2015년 12월 버전 APNs 변경 사항 정리

Apple과 google 에서 제공하는 푸시 서비스는 모바일 게임 운영 중 공지 및 광고, 이벤트 홍보 등 다양한 용도로 활용되는 기능이다. 푸시는 가장 널리 퍼진 모바일 디바이스 플랫폼인 ios/android 모두에서 사용할 수 있으며, 게임이 실행중이지 않더라도 메시지를 전송할 수 있다. 또한 전화번호 등의 개인정보를 수집,관리하지 않고도 게임 유저들에게 필요한 정보를 알릴 수 있다. 반면, 메시지 전송을 위해서는 전적으로 Google/Apple 에서 제공하는 플랫폼을 사용할 수 밖에 없어 이를 위한 구현 및 관리, 업데이트가 필요하다는 단점도 있다.

2016년,(정확히는 2015년 연말경부터) Google 과 Apple 모두 새로운 푸시 서비스를 공개하였다. Google은 기존의 gcm 대신 firebase 와 통합된 푸시 서비스인 FCM을, Apple 은 새로운 프로토콜, 새로운 인증 방식을 적용한 푸시 서비스를 선보였다. 양쪽 모두 새로운 기능들을 많이 선보였지만, 테스트용 대시보드나 퍼널 분석 등 사용성 위주의 변경사항이 대부분인 FCM과는 달리 APNs는 연결 인증 방식 및 전송 프로토콜 등 기능 외 적인 부분에서도 많은 부분에서 변화가 있었다. 그 결과 기존 방식으로 APNs 에 메시지 전송 요청을 전송하는 어플리케이션 서버를 마이그레이션하기 위해서는 요청 전송 부분을 새로 만들어야만 한다.( 반면 Google은 https://developers.google.com/cloud-messaging/faq 에서 확인 가능한 것처럼 기존 프로토콜을 그대로 사용 가능하기에, 신규 기능을 사용하지 않는다면 url 교체 작업 정도면 충분하다. )

새로운 APNs의 변경점 중, 어플리케이션 서버 개발 및 운영과 관련하여 눈에 띄는 것들은 다음과 같다.

전송 가능한 메세지 최대 크기 증가

최대 전송 가능 메세지 크기가 2KB 에서 4KB 로 변경되었다. I18N 지원이나 추가 데이터 전송 등의 이유로 메세지 크기가 점점 커지는 경향이 있었는데 이러한 부분을 고려한 변경점으로 보인다.

토큰 기반 인증 지원

기존에는 APNs에 푸시 요청을 전송하려면 반드시 TLS 인증서 기반의 인증이 필요했다. 이러한 방식을 사용하기 위해서는 항상 인증서 갱신 주기를 신경 써야 하며, 개발(sandbox, development)환경/ 제품(production)환경에 사용되는 인증서를 구분해야 하는 등 신경 써야 할 것들이 많았다.

새로운 APNs에서는 인증서 기반의 인증을 사용하지 않고도 푸시를 전송할 수 있는 방법을 제공한다. 전송 요청 시마다 토큰을 같이 전달하는 방식이며, JWT( https://jwt.io/ ) 방식의 토큰을 사용한다. 토큰 생성에 필요한 key 는 애플 개발자 계정 페이지에서 얻을 수 있다.

기존의 인증서를 이용한 인증 역시 지원하므로 둘 중 하나를 선택해서 사용하면 된다.

이 인증 방식을 사용하면, 개발환경/제품환경에 관계 없이 푸시 전송을 요청할 수 있다. 또한 토큰 자체는 유효기간이 있지만, 토큰 생성에 사용되는 key는 유효기간이 없기 때문에 토큰 생성 기능을 한 번 구현해두면 갱신 등을 걱정할 필요 없이 계속 사용할 수 있다는 장점이 있다.

1
▲토큰 생성에 사용되는 key는 만료 기한이 없다.

제품(production) 인증서로 개발환경(sandbox, development) 대상 푸시 전송 가능

위에서도 언급했지만, 기존에는 제품 환경을 대상으로 푸시를 전송하는 경우와 개발 환경을 대상으로 전송하는 경우에는 별도의 인증서를 사용해야만 했다. 새로운 APNs에서는 제품 환경의 인증서를 이용하여 제품 환경과 개발 환경 모두에 푸시 전송 요청을 보낼 수 있다.

2
▲제품(production) 인증서로 개발 환경과 제품 환경 모두에 푸시를 보낼 수 있다.

전송 요청 프로토콜 변경

기존에 APNs에 전송 요청을 보낼 때는 tcp 로 전용 프로토콜을 통해 요청해야만 했다. 새로운 APNs는 HTTP/2 기반의 프로토콜을 사용한다.

HTTP/2 에 익숙하지 않으신 분들을 위해 간략히 설명하자면, HTTP/2 는 HTTP 1.1 과 비슷한 기능성을 지원하면서도 서버측에서의 응답 시간을 줄이는 것을 주된 목적으로 설계된 프로토콜이다. HTTP method 등 HTTP의 기본 기능은 최대한 바꾸지 않으면서 요청 생성/처리와 관련된 부분을 변경하였다. 예를 들면, 헤더에 인덱싱 개념을 도입하여 요청 자체의 크기를 줄이고 멀티플렉싱을 개념을 도입, 기존 HTTP 1.1 의 반응 속도를 떨어뜨리는 요인 중 하나였던 head-of-line-blocking 문제를 해결했다. head-of-line-blocking 문제란, 작업 시간이 오래 걸리는 작업이 진행 중이면 이미 처리가 끝났거나, 더 빨리 끝낼 수 있는 다른 작업들을 처리할 수 없는 상황을 말한다.

3

위의 그림에서, A의 요청에 대한 응답인 A’ 의 크기가 크거나 처리가 오래 걸리는 경우를 생각해 보자. 반대로 B’의 크기가 매우 작거나 빨리 처리할 수 있다면, 서버는 B’ 를 먼저 전송하고 클라이언트는 그에 대한 처리를 먼저 시작하는 편이 최적화에 도움이 된다. 하지만 HTTP 1.1 은 서버 측에서 요청을 받은 순서에 따라 응답을 보내야 한다고 규정하고 있으므로, 서버는 B’를 A’보다 나중에 보내야만 없다. 즉 B’ 는 A’에 의해 blocking 된 것이다.

반면 HTTP/2 에서는 여러 개의 요청을 별개의 스트림으로 나눠서 전송할 수 있다. 다른 스트림상의 요청은 위에서 언급한 전송 순서에 영향을 주지 않으므로 요청 A,B를 서로 다른 스트림을 이용해서 요청하면 서버에서는 먼저 처리가 끝난 B’를 먼저 전송할 수 있기에 B’는 A’에 의해 blocking 되지 않는다.

새로운 APNs에서는 이 멀티플렉싱 기능을 이용, 하나의 연결에서 다수의 요청을 동시에 전송할 수 있도록 지원하고 있다. 즉 여러 개의 디바이스를 대상으로 푸시 전송 요청을 날리려면 디바이스의 개수만큼 HTTP /2 요청을 보내야 한다. 위에서 설명한 토큰 인증을 사용할 경우, 요청 시마다 생성된 토큰을 포함하여 전송하여야 한다.

기존 방식과 비교했을 때 장점은, 우선 오류 발생 시 오류가 발생한 요청만 실패한다는 점이다. 기존 APNs의 경우, 다수의 전송 요청을 보낼 때 오류가 발생하면 해당 요청에 대한 오류 정보를 전송 후 바로 APNs측에서 연결을 종료했으며, 오류가 발생한 요청 이후의 모든 요청은 무시되었다. 따라서 오류 처리 시, 전송 요청이 어디까지 받아들여졌는지를 확인, 나머지 요청을 모두 재 전송하는 로직을 반드시 구현해야 했다. 반면 새로운 APNs에서는 문제가 있는 요청만 실패하며, 나머지는 모두 정상적으로 처리된다. 따라서 오류가 발생한 메세지에 대한 재전송만 신경 쓰면 된다.

두 번째 장점은 오류에 대한 좀 더 상세한 정보를 얻을 수 있다는 점이다. 기존 APNs에서는 요청 메세지 내의 형식 문제 등으로 오류가 발생한 경우 오류 코드 하나만을 반환하였는데, 오류 코드의 총 수가 10개 남짓으로 지나치게 단순하여 오류 원인을 파악하기 어려웠다. 새로운 APNs는 HTTP error code 및 error string을 동시에 제공, 오류 원인을 알아내기 쉬워졌다.

이 글을 작성하는 시점에, 새로운 APNs는 서비스 된 지 1년 이상이 지났다. 또한 Apple이 레거시 지원을 중요하게 여기는 회사는 아니기에, 신규 프로젝트 개발 시에는 물론이고 기존 방식의 APNs를 사용하여 서비스를 제공하고 있는 경우에도 새로운 APNs 사용을 고려할 필요가 있다. 변경점 중에는 프로토콜 외에 기능적인 변경도 있으며 푸시 서비스 운영에 영향을 줄 수 있는 변경들도 있기에 기존에 운영중인 프로젝트에 사용되는 푸시 기능도 마이그레이션하는 것을 권하고 싶다 .

아이펀팩토리 아이펀 디플로이 테크니컬 디렉터 민영기

[이벤트] 아이펀 엔진 캐릭터의 이름을 지어주세요!

안녕하세요! 아이펀팩토리 사업팀입니다.
오랜만에 즐거운 이벤트 소식을 가지고 인사 드립니다.

바로 게임 서버 개발을 쉽게 도와주는 아이펀 엔진의 대표 캐릭터의 이름을 찾는 이벤트!
그렇습니다!
그 동안 아이펀팩토리 이벤트와 행사 모델로 많이 활동해왔지만, 아직 이름을 찾지 못했었습니다.

아이펀 엔진 캐릭터의 멋진 이름을 지어주시는 분들 중 선정하여 저희가 마련한 푸짐한 선물을 드릴 예정이오니 많은 참여 부탁 드립니다.

%ec%9d%b4%eb%b2%a4%ed%8a%b8-%ed%8e%98%ec%9d%b4%ec%a7%80_20170103_f

.

.

먼저 게임 서버 개발을 쉽게 도와주는 기특한 로보트,
아이펀 엔진 캐릭터
의 프로필 공개할게요.

1-1빨간 망토가 참 잘 어울리죠?
아이펀 엔진은 다양한 플랫폼과 장르를 가리지 않는
서버 변신 능력을 보유한 아주 똑똑한 친구입니다.


나이 : 주름살
키 : 비밀
혈액형 : 스마트형
주소 : 경기도 성남시 분당구 대왕판교로 660 아이펀팩토리
취미 : 서버개발자와 수다, 게임 서버 개발
특기 : 플랫폼과 장르를 가리지 않는 전천후 서버변신 능력 보유!!!
성격 : 다정다감, 진취적, 열정적
특징 : 똑똑하다, 마음이 따듯하다, 무엇이든 척척해낸다.
서버개발자가 원하는 것은 모두 한다.
가끔 불가능한 일을 해내기도 한다.
현재 관심사 : 최신 게임 플레이

.

.

프로필은 여기까지!

.

그럼 지금부터 아이펀 엔진 캐릭터를 자세히 하나씩 볼까요?

.

아이펀 엔진의 머릿속에는 온통 게임 서버 개발로 가득해요!
게임 서버 개발로 고민중인 개발자분들~ 아이펀 엔진에게 털어놓으세요.
여러분의 고민을 모두모두 해결해 드리겠습니다!

1

.

.

.

서버개발의 슈퍼맨인 아이펀 엔진의 가슴에는 아이펀 엔진의 E가 심볼로 있답니다.
여러분을 위해 언제든지 날아갈 준비가 되어 있어요.

%ea%b7%b8%eb%a6%bc8

.

.

로보트지만 따듯한 마음을 가지고 있는 아이펀 엔진은 다양한 표정을 가지고 있어요.
게임 서버를 개발할 때 가장 행복한 표정을 짓는 아이펀 엔진이에요.
그리고 스마트한 모습 뒤에 감성적인 모습이 숨어 있는 반전 매력을 소유하고 있답니다.

%ea%b7%b8%eb%a6%bc1

.

아이펀 엔진에 대해 더 자세히 알고 싶은 분들은 아래 주소를 참고해 주세요.
아이펀 엔진 자세히 보기!

.

.
아이펀 엔진 소개는 여기까지!
이벤트 참여 방법을 안내해 드려야 겠죠?

– 이벤트 참여 기간 : 2017년 1월 17일(화)~2017년 2월 28일(화)
경품 당첨자 발표일 : 2017년 3월 둘째주 중 아이펀팩토리 페이스북에서 경품 추첨 생중계 예정
%ea%b2%bd%ed%92%88-%ec%9d%b4%eb%af%b8%ec%a7%80
대망의 경품!!!! 
1등 아이패드 프로 9.7형 (1명)
2등 시놀로지 NAS 4TB (1명)
3등 리얼포스 기계식 키보드 (1명)
4등 라즈베리파이3 (2명)
5등 구글플레이 1만원권 기프트 카드 (5명)

.

<이벤트 참여하기>
아래 순서대로 1단계부터 3단계까지 완료하면 이벤트 응모 성공

1단계 아이펀팩토리 페이스북 ‘좋아요(팔로우)’ 클릭
페이스북 검색창에 ‘아이펀팩토리’ 검색(또는 아래 링크 클릭) 후 아이펀팩토리 페이스북 페이지 좋아요(팔로우) 클릭
아이펀팩토리 페이스북 가기
 

그림5.png

2단계 아이펀팩토리 페이스북에 있는 ‘아이펀 엔진 캐릭터 작명 이벤트’ 게재글 공유하기
페이스북 이벤트글 공유하러 가기
해시태그 필수 → #아이펀엔진 #아이펀팩토리
공유범위를 ‘전체공개’ 필수

%e3%85%87%e3%85%81%e3%85%87%e3%84%b4

3단계 아이펀팩토리 페이스북에 있는 ‘아이펀 엔진 캐릭터 작명 이벤트’ 게재글에 댓글로 이름 및 간단한 이유(2줄이내)를 남기기
신청 양식 :  신청자 이름 / 페이스북 사용자 이름 / 핸드폰 뒷 4자리 / 작명 / 설명 / 페이스북 공유 및 좋아요 완료
예) 공유 / 공유 / 7890 / 도깨비 / 도깨비 방망이처럼 뚝딱 서버개발이 가능하니까 / 페이스북 공유 및 좋아요 완료 하였음


.
이벤트 응모 주의 사항
– 아이펀팩토리 페이스북 팔로우(좋아요) 필수

– 페이스북 이벤트글을 해시태그(#아이펀엔진 #를 달아 ‘전체공개’로 공유하기 필수!
– 작명한 이름을 신청 양식에 맞추어 아이펀팩토리 페이스북 페이지 이벤트글 게시글에 댓글 남기기(이벤트 응모 완료!!)


*** 주의***
** 아무리 예쁘고 좋은 이름이라도 1~3단계 미션을 완료하지 않으면 무효
** 1등 당첨자의 작명이 반드시 제품의 이름으로 선정되는 것은 아님.
** 중복의 경우는 먼저 응모해 주신 것을 인정.
** 본, 작명이벤트에 신청하신 모든 작명의 경우, 소유권은 아이팩토리에게 있음을 동의하는 것으로 간주됨.
** 본 이벤트의 일정과 경품은 당사의 사정에 의해 변동될 수 있음을 양해부탁드립니다.

** 1등~4등 경품 당첨자의 경우, 제세공과금은 경품 당첨자 본인 부담입니다.
** 경품 당첨자에게는 페이스북 메신저로 개별 연락을 드릴 예정입니다.

여러분의 번뜩이는 아이디어를 기다릴게요~!

.

[인벤기고컬럼 9] 건강한 게임 생태계 구축을 위한 오픈 퍼블리싱 플랫폼의 필요성

오늘은 지금까지의 기술적인 이야기가 아닌 시장에 대한 이야기를 해보려고 한다. 기술적인 내용들에 비하면 좀 더 이해가 쉬울 수 있지만, 다소 무거운 내용을 포함한다.
모바일 게임의 역사는 결국 아이폰이 언제 시장에 소개되었는지와 관련이 있다. 애플은 아이폰을 소개하면서 프로그래머들이 직접 프로그램을 만들어서 올릴 수 있는 AppStore 를 같이 소개했고, PC 에서의 교훈을 보더라도 개발자든 일반 대중이든 가장 많은 관심을 보이는 애플리케이션은 당연 게임이었다. 그 때문에 아이폰이 처음 소개된 미국에서는 2007년부터, 그리고 아이폰 3GS 모델부터 도입된 한국은 2009년부터 모바일 게임들이 본격적으로 개발되고 소비되기 시작했다.

i15538614366.jpg
▲ 애플의 첫 번째 아이폰. 이 당시에는 핸드폰의 크기를 경쟁적으로 줄이던 시기였다. 그 때문에 이 광고가 나왔을 때도 애플이 아이폰을 작게 보이게 하기 위해 일부러 손이 큰 모델을 사용해서 광고를 찍었다는 논란이 있었다. 그에 비하면 지금 패블릿이라 부르며 큰 폰을 선호하는 현상은 다분히 격세지감을 느끼게 한다.(출처: 애플)
■ 네트워크 연결이 필요 없던 초창기 모바일 게임

모바일 게임이라는 이름은 “모바일 (mobile)” 이라는 이름에서 느낄 수 있듯 portable 한 게임을 의미했다. 즉, 들고 다니는 장치에 설치되어 들고 다니면서 플레이할 수 있는 게임이었다. 그 때문에 초기의 모바일 게임들은 자연스럽게 네트워크 기능이 없는 게임들이 주류였다. 들고 다니는 장치다 보니 안정적인 네트워크 상황을 가정할 수도 없었고, 대중들의 기대치도 “들고 다니는” 장소가 비행기같이 네트워크가 아예 불가능한 곳까지 포함됐기 때문이다. (우리나라의 경우 국내선이 1시간을 넘기지 않지만, 미국 같은 곳은 국내선만해도 5-6시간 시간이 걸리는 곳도 많기 때문에 비행기 안에서 게임을 할 수 있는 것은 큰 메리트다.)

이 때문에 초기의 모바일 게임은 3명 이내의 소규모 인원이 석 달 이내에 작업을 해서 결과물을 낼 수 있는 정도의 게임들이었다. 만일 개발 외주를 준다고 해도 3천만원 선에서도 게임을 만들 수 있는 정도였다. 천만 원이라는 숫자가 크게 느껴질 수도 있지만, 당시 경쟁적으로 대작 PC 게임을 만들던 상황에서 게임 하나의 제작비는 수백억까지 호가 했기 때문에, 1억도 안되는 제작비로 만들 수 있는 모바일 게임이 얼마나 라이트하고 단순한 게임들이었는지 알 수 있을 것이다. 나는 개인적으로 모바일 게임들을 보면서 갤러그 수준으로까지 PC 게임의 초창기 시절로 회귀한 것 같은 느낌까지 들었다.

인벤기고컬럼 본문 더보기>

[인벤기고컬럼 8] 자체 서버실부터 GBaaS까지, 게임서버 구축방법의 변천사

우리는 어디서나 컴퓨팅 자원을 쉽게 접할 수 있는 환경에서 살고 있다. 연산능력에 비해 PC 가격은 지극히 낮아졌고, PC를 직접 구하지 않더라도 클라우드라는 이름으로 가상 서버를 손쉽게 얻어 누구나 서버를 돌릴 수 있는 시대가 되었기 때문이다. 하지만 이런 일은 불과 20년 전만 해도 상상도 할 수 없는 일들이었다. 세월이 지나고 기술이 발전하고 내 머리카락이 빠져 프로스카를 쪼개먹는 일이 필요해지는 동안 게임 서버를 구축하는 방식 역시 많이 변화해왔다.

이번 회에서는 게임 서버를 구축하는 방식들이 어떻게 변화되어 왔는지 살펴보도록 하겠다.

■ 자체 서버실의 시대

우리나라에 초고속 인터넷이 대중화되기 시작한것은 대략 1999년정도이다. 지금은 상상도 할 수 없지만 그 전까지는 인터넷 연결 없이 PC를 사용하는 것이 당연하게 여겨졌다. 물론 “접속”같은 영화에서 보듯 하이텔이나 데이콤, 나우누리같은 PC 통신은 존재했고, 그들 서비스가 전화 PPP라는 방식을 통해서 인터넷 연결을 제공하긴 했지만 속도는 너무 느렸고, 전화비도 많이 나와서 마음대로 쓸 수 있는 것이 아니었다.

그래서 개인용 컴퓨터에서 하는 대부분의 작업은 창세기전 같은 패키지 게임을 설치해서 플레이하거나, 문서작업을 하거나, 아니면 CD-ROM이나 ZIP Drive같은 보조 저장장치로 복사해 온 동영상을 보는 것이 전부였다. 1998년도에 서울대학교 공과대학 전산실에 1배속, 그나마도 걸핏하면 뻑나는 CD Writer가 있는 정도였으니 정보의 이동이라는 것이 얼마나 제약이 컸을지 상상이 갈 것이다.

인터넷이 이런 상황이니 서버를 운영하는 주체도 별로 없었다. 서버는 대학이나 대규모 기업에서 활용하는 것으로 생각했다. 그 때문에 서버를 누군가가 대신 운영해준다는 것 역시 상상하기 어려웠다. 그래서 초창기 게임 서비스는 해당 개발사의 건물 어딘가에 서버실을 만들어 거기에 서버를 쌓아두고 이루어졌다.

내가 재직했던 넥슨 역시 선정릉역 인근 건물에 단지 서버 몇 대를 가지고 바람의나라 서비스를 시작했다. 그 서버는 지금 기준으로는 어이없을지 모르지만, 당시 PC 기준으로는 최첨단인 Pentium II 350Mhz CPU 두 개 꽂고 256MB RAM을 사용한 조립 기계였다. 세월이 지남에 따라 Pentium II가 Pentium III가 되고, 메모리는 512MB까지 쓸 수 있었지만 어쨌거나 기계를 직접 마련해서 회사 건물에 쌓아두는 건 마찬가지였다. 당시에도 엔씨소프트처럼 직접 조립을 하지 않고 인텔 서버를 공급하는 업체에서 사다가 쓰는 회사도 있었고, 인텔 서버가 아니라 SPARC이나 IBM AIX를 쓰는 경우도 있었지만, 어쨌거나 서버는 회사 서버실에 있는 것이 보통이었다.

i13166288105
▲ 그림1: 인텔 Pentium III CPU를 두 개 꽂은 서버. 지금의 CPU와는 달리 팬 일체형에 슬롯 형태로 꽂는 타입이다. 이런 서버들을 서버실 한켠에 쌓아두고 서비스를 했었다. (출처: tyan.com)
이렇게 서버를 직접 두고 서비스한다고 할 때 사용자가 늘어남에 따라 어떤 것이 큰 병목이 되기 시작했을까? 바로 네트워크였다. 예나 지금이나 서버측에서는 네트워크가 큰 병목이 되는데, 일반 인터넷망으로 서비스를 하는 것은 불가능하다. 그래서 전용선을 서버실까지 끌어와야 했는데 이것이 돈도 많이 들고 단순히 돈을 지불한다고 한도 끝도 없이 공급해주는 것도 아니었다. 당시에 넥슨에서 이걸 담당하신 분이 과거 넥슨 공동 대표와 네오플 대표를 하셨고 현재 한국인터넷디지털엔터테인먼트 협회장을 맡고 계신 강신철 회장님인데, 그때 회선 따오려고 통신사 분들과 술을 엄청나게 많이 드시고 그랬다. 나의 저질체력이라면 절대 못할 일이었다.

.

인벤기고컬럼 본문 더보기>

Windows에서 Linux 머신을 구성하는 방법들


게임을 개발하다 보면 여러 가지 서버 환경을 준비해야 한다. 개발자가 사용할 개인용 개발 서버부터 팀원들이나 클라이언트 개발자가 꾸준히 접근할 팀 개발 서버, QA를 위한 테스트 서버, 상용화 환경을 준비하기 위한 것까지 최소한 서너가지의 서버 환경은 필수적이다. 또한 의외로 꼭 있으면 좋은 것이 기획자들의 데이터 테스트를 위한 기획자별 테스트 서버인데, 이 경우 전문 개발자가 아닌 사람들을 위한 배포용 서버 환경을 어떻게 구축 할지가 매우 중요해진다.


업무 환경에서 가장 많이 사용하는 운영체제는 대부분의 경우 Windows이다. 하지만 게임은 물론 다수의 프로젝트에서 사용하는 서버는 리눅스에서 동작하는 경우도 많다. 이 경우 전문 개발자가 아닌, 혹은 리눅스 서버 사용 경험이 거의 없는 사람과의 협업이 필요할 때 어떻게 이들을 위해 환경을 설정하고 공유하며 배포를 준비할 수 있을까. 이번에는 이에 대해서 이야기를 해보려고 한다.

 1. Hyper-V

1
(출처: https://www.microsoft.com/)


Hyper-V는 Windows에서 기본으로 지원하는 가상 컴퓨터 관리 기능이다. 다른 운영체제를 사용하기 위하여 추가로 프로그램을 설치하거나 할 필요가 없다는 것이 장점이다.


이후에 설명할 다른 가상 환경도 마찬가지 이지만, Hyper-V 역시 지정된 가상 컴퓨터 이미지를 공유할 수 있다. 이를 통하여 다른 사람들에게 쉽게 서버를 배포할 수 있다.


Hyper-V는 이와 같이 사용이 간단하고 배포가 손쉽지만, 아쉬운 부분이 있다. 대표적으로 NAT설정이 번거롭다.[1] 기본 기능을 통하여 바로 만들 수 있는 외부 스위치를 활용하는 경우, 새로운 하드웨어 주소가 가상 컴퓨터에 설정된다. 그러므로 하드웨어 주소를 통해 접근을 제한하는 네트워크 정책을 사용하는 회사의 경우, 배포가 쉽다는 장점과는 반대로 네트워크 시스템 담당자를 매우 귀찮게 만들게 된다. 즉, 전문 개발자가 아닌 사람과 협업하기 위한 서버 환경 설정 용으로 Hyper-V는 매우 편리하지만, 해당 가상 서버 환경에서 외부 네트워크 접속을 허용하기 위해서는 추가 작업이 필요하다.


하지만 서버가 외부 접속을 지원할 필요가 없다면, Hyper-V로 만든 가상 컴퓨터는 매우 쉽게 공유할 수 있는 리눅스 머신이다. 특히 기획자 개별 데이터 테스트용 서버 머신이라면, 가장 편리한 방법이 아닐까 생각한다.

 
2. Docker

2
(출처: https://www.docker.com/)


Docker는 리눅스 위에 얇은 추상화 레이어를 더해서 프로그램을 구동시킬 수 있는 컨테이너를 만들고, 그 위에서 리눅스 프로그램을 구동시킬 수 있도록 해주는 소프트웨어이다. 다시 설명하자면, Docker는 사용자가 직접 가상 운영체제를 설치하거나 유지보수하지 않더라도, 원하는 머신에 Docker만 깔면 동일한 환경에서 실행할 수 있도록 배포, 관리가 가능하게 만들어준다. 그리고 이 기능은 VM을 이용하는 것이 아니라, 각각의 운영체제에 직접 연동되어 동작한다. 현재 Docker가 지원하는 운영체제는 Mac, Windows, Linux이다.


이 글의 첫 부분에서 이야기한 다양한 서버 환경을 준비하는데 있어서, Docker는 Hyper-V보다 좀 더 나은 관리 방식을 제공한다. 실제로 Docker는 가상 컴퓨터의 관리보다는 소프트웨어 배포용 소프트웨어이기 때문이다. 출시를 위한 환경은 보통 단일한 서버보다는 여러 가지 종류의 서버가 상호 작용하는 형태를 취하게 되는데, Docker를 이용하면 각각의 기능에 따른 가상 환경을 운영체제부터 프로그램까지 전체를 관리하지 않아도 되기 때문에 상대적으로 편하게 유지보수가 가능해진다. 엔터프라이즈 환경에서 검증되었다는 것 역시 훌륭한 점이다.


물론 Docker도 진입장벽이라는 단점이 존재한다. 개발자들에게는 의아한 이야기일 수도 있지만 개발자가 아닌 사람들도 사용하기에는 GUI가 빈약하며 교육을 위한 시간과 비용이 필요하다.

 

 3. 그 외 가상화 소프트웨어

Hyper-V가 나오기 전부터 이미 여러 회사에서 VirtualBox나 VMWare 같은 가상화 관련 소프트웨어를 만들어왔다. 이들은 역사가 깊은 만큼 다양한 인프라스트럭처 관련 툴을 지원하기도 하고, 사용자의 규모에 따라 분리된 프로그램을 제공하기도 한다. 또한 Hyper-V의 약점이었던 NAT지원 등도 손쉽게 설정할 수 있다. 배포 역시 마찬가지로 이미지를 활용하면 어렵지 않다.


하지만 먼저 설치해야 할 프로그램이 존재한다는 것은 개발자가 아닌 사람들이 사용하기에 단점이며, 개발자들이 사용하는 상황에서도 특별한 경우가 아니라면 이러한 가상화를 사용하는 경우는 많지 않다.


편의성이 좀 더 뛰어난 경우가 많아 관련 기능을 사용해야 하는 경우라면 고려해 볼만 하다.

 

 4. 정리하며

서버 개발은 물론이요, 하다 보니 어느새 시스템 엔지니어링까지 해야 하는 수 많은 개발자 분들을 위해 빈약하나마 가상화 프로그램을 소개하는 내용을 정리해 보았다. 다양한 환경을 준비하고 공유하는 방법에 대한 의의도 있겠지만, 개발된 코드와 컨텐츠를 보관하는 것 만큼 이나 개발 환경과 구동 환경을 백업해두는 것도 중요한 만큼, 앞으로 오래오래 개발할 수 있는데 조금이나마 도움이 되었으면 하는 마음에 미약한 글을 여기서 정리한다.

아이펀팩토리   박근환 아이펀 엔진 테크니컬 디렉터


[1]: Hyper-V NAT 네트워크 설정, https://msdn.microsoft.com/ko-kr/virtualization/hyperv_on_windows/user_guide/setup_nat_network