2017 아이펀팩토리 Dev Day가 시작됩니다!

%eb%b8%94%eb%a1%9c%ea%b7%b8_dev-day-%ed%83%80%ec%9d%b4%ed%8b%80%ec%95%84%ec%a0%a0%eb%8b%a4_20170222_

2017 아이펀팩토리Dev Day 가 시작됩니다!
Great Technology for Great Games

 일시 : 2017 3 29 () 13:00 ~ 17:00
 장소 : 판교 엔씨소프트 R&D센터 2층 종합게임시연실
 세미나 참여 신청 하러 가기 : http://onoffmix.com/event/92367
 신청 기간 : 2017 2 22() ~ 2017 03 28() 정오까지
 현장등록은 받지 않으며 꼭 사전 등록이 필요합니다.
 점심식사 기념품이 준비되어 있습니다.
(
점심식사 및 기념품은 선착순 제공되며 소진 시, 제공되지 않습니다
.)
 신청 확인을 위해 세미나 당일 명함 지참을 부탁 드립니다.
(
명함이 없으신 분들은 신분증, 학생증으로 확인 가능합니다.)
* 세미나 장소가 협소한 관계로 선착순 입장되오니 양해 부탁 드립니다.
* 주차공간이 별도로 마련되어 있지 않아, 대중교통 이용을 부탁 드립니다.

시간 세션 발표자
12:00 ~ 13:00 (60’) 세미나 등록  
13:00 ~ 13:05 (5’) 웰컴 스피치 문대경 CEO
iFunFactory
13:05 ~ 13:50 (45’) 강연 1. 혼자서 만드는 MMO 서버 박근환 TD
iFunFactory
13:50 ~ 14:30 (40’) 강연 2. Python과 AWS를 이용하여
게임 테스트환경 구축하기
민영기 TD
iFunFactory
14:30 ~ 15:10 (40’) 강연 3. 게임 서버 성능 문제 찾기 김진욱 CTO
iFunFactory
15:10 ~ 15:50 (40’) 강연 4. 쉐이더 단기속성 오지현 에반젤리스트
Unity Technologies Korea
15:50 ~ 16:30 (40’) 강연 5. 게임 서버 구축 방법 비교 :
GBaaS vs. Self-hosted
문대경 CEO
iFunFactory
16:30 ~ 16:40 (10’) 폐회식 / 경품 추첨

 

캐주얼 커넥트(Casual Connect) 유럽 2017 을 다녀오다

%ea%b7%b8%eb%a6%bc24▲ 전 세계 게임 산업 전문가들이 모여 캐주얼 게임 개발 노하우를 공유하는 캐주얼 커넥트 행사장

Casual Connect 는 GDC 와 마찬가지로 전세계적인 게임 컨퍼런스입니다. 이름에서 느껴지듯 모바일 게임을 비롯한 캐주얼한 게임들을 위한 자리이긴 하지만 최근에 게임들이 점점 미드코어 이상급으로 넘어가는 변화가 Casual Connect에서도 느껴진 행사였습니다. 캐주얼 커넥트는 연중 4회, 대륙을 이동해 하면서 행사가 개최되는데, 미국, 유럽, 이스라엘의 텔 아비브, 아시아 순으로 행사가 진행되며 매년 6,500명 이상의 각 게임산업의 전문가들이 참석해 캐주얼게임 개발 노하우 및 정보를 공유하는 자리로 캐주얼 게임의 글로벌 시장 추세를 볼 수 있는 자리였습니다.

캐주얼 커넥트에서는 다양한 주제의 발표를 볼 수 있었는데 게임디자인부터, 소셜게이밍, 펀딩, 차세대 기술과 실무상의 모범 사례에 이르기까지 폭넓은 주제의 발표로 글로벌 게임 산업의 트렌드를 직접 확인 할 수 있었습니다. 게다가 게임업계 다양한 분야의 사람들과의 네트워킹을 통해 세계 게임인들과의 비즈매칭이 열려있는 자리로 다양한 사람들을 만나볼 수 있었습니다.

.

그럼 행사장안을 같이 살펴 볼까요?

5
▲ 캐주얼 게임의 모든 것을 볼 수 있는 캐주얼 커넥트 전시 공간

캐주얼 커넥트에서는 발표와 전시 둘 다 이루어지지만, 전반적으로 발표 보다는 전시 쪽이 더 활발한 편입니다. 그리고 비즈 매칭을 통한 사업 미팅이 아주 활발한 편인데 이 점이 우리 나라 문화와는 많은 차이가 있는 것 같다는 생각이 들었습니다. 게임산업 외에서 보통 비즈 매칭이라고 하면 정장을 입은 사람들이 딱딱한 분위기에서 만나는 것을 떠올릴 수 있는데 캐주얼 커넥트에서는 게임을 만드는 사람들끼리의 캐주얼한 만남이 대부분으로 자유롭게 네트워킹이 이루어졌습니다. 많은 경우 개발사는 퍼블리셔를 만나서 자기들이 심혈을 기울여 개발한 게임을 어필하는 경우가 많지만, 다른 개발사들과의 네트워크 성격의 모임도 종종 있을 정도로 서로 만나 이야기 하는 것에 상당히 오픈된 분위기로 자유로운 유럽을 느낄 수 있었습니다.

.

6▲ 캐주얼 커넥트의 이름답게 캐주얼한 분위기의 비즈매칭 현장

7
▲ 캐주얼 커넥트에 골드 스폰서로 참여한 한국게임개발자협회(KGDA)

8
▲ GICDC 주관 ‘글로벌 인디게임 제작경진대회’ 대학생부문 대상 수상자들과 함께

이번 행사에는 한국게임개발자협회(KGDA)가 골드 스폰서였었고, 국내 KGDA 주관 GIGDC 글로벌 인디게임제작경진대회에서 입상한 일반부문 대상 ,금상과 대학부문 대상의 수상자 3팀의 작품들이 Casual Connect 에 함께 참여하였습니다. 기발하고 재미있는 인디 게임들을 많이 볼 수 있어 즐거운 자리였습니다. 다음 캐주얼 커넥트는 5/16 부터 3일간 아시아 행사로 싱가포르에서 개최됩니다! 다음 행사에는 좀 더 가까운 곳에서 게임업계의 핫트렌드를 볼 수 있다니 다음 캐주얼 커넥트를 기대하며 이만 글을 마치겠습니다.

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

■ 상황 요약
게임을 플레이할 때 거의 무선 통신을 이용해서 게임을 한다. 스마트폰으로 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 게임의 초창기 시절로 회귀한 것 같은 느낌까지 들었다.

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