회사 홈페이지 리뉴얼했습니다.

http://www.nettention.co.kr 

프라우드넷 간단 소개 프리젠테이션 슬라이드입니다.

오늘 기술지원 이슈를 하나 받았습니다.

 

매우 이상한 이슈 이던군요... 어떤 문제인고 하니..

 

vs2005 Release 빌드 Server에서 Client가 접속이 끊겼을때의 이벤트가 나오지 않는다는 이슈 였습니다.

 

저는 생각하기를...'아닌데..테스트를 많이 해봤는데..'라고 생각하며 다시 테스트를 했습니다.

 

그런데, 아니나 다를까 이벤트가 잘오더군요...쩝..

 

그래서 엔진 패키징 하는 컴퓨터에 접근하여 문제가 생기는 버젼을 빌드하여 테스트 해봤더니...

 

'헉...이벤트 타이머가 작동을 안하자나....jQuery1520967723500682041_1326957222827?'

 

이벤트 타이머가 작동을 안하면...모든 이벤트와 처리등이 죽는등의 크리티컬한 문제 였습니다.

 

그래서 이벤트를 추적...1개 1개...용의자를 좁혀가던중...

 

'double연산이 이상하게 나오네??? NaN??..헐 나눗셈에서 분모에 0이 들어갔나 보군..'

이라고 생각을...

 

했는데!! 글쎄 모든 값은 정상인데..꼭 그부분에서만 연산 결과 값이 이상하게 나오던군요..

 

'이건 뭥미...?^^;'하고.. asm을 보니 캐스팅부분이 이상하게 나오던 부분이 있더군요...

 

결국 컴파일러 버그...^^; '근데 내컴에선 왜 잘되지? 로직은 똑같은데...'라는 생각이 번쩍!!

 

하고 드는 순간...버젼을 체크해보니...아니나 다를까 service pack1이 안깔려 있더군요...ㅜ,.ㅜ

 

결론은 닥.치.고. 서.비.스.팩.깔.아!!!

저번 냥이 술자리 껀의 뒷 이야기를 살살 풀어보려 한다.

바빠서 너무 오랜만에 글을 올려 본다..

 

먼저 엔진과 컨텐츠의 차이에 대하여 이야기 해보고 싶다.

아는 사람들은 왜 저런 뻔한 소리를 하고 그러냐고 하겠지만 의외로 모르는 사람이 더 많다.

하물며 개발자 중에도 프로그래머 아니면 모르는 사람이 있는데 일반인이야 오죽할까..

 

엔진하면 무엇이 떠오를까? Engine!! (기관!!)

흔히 자동차 엔진을 많이 생각하리라 생각된다.

냥이 로봇에도 엔진…?!

 

기계들마다 엔진이 다 들어가는데 프로그램 소스에도 엔진이 들어갈 수 있지 않을까? 꼭 물리적 개념으로 생각하지 말아보자.

 

크라이 엔진, 언리얼 엔진 이라고 하면 일반 유저도 다 안다.

3D 엔진!

모르면 간첩내지 게임을 하지 않는 사람, 나이 많으신 분, 너무 어린애, 매우 바쁜 삶으로 잠깐씩만 게임으로 시간 때우는 사람......

음.. 은근히 늘어놓으려니 많다. 괜한 짓 했다..

 

이제 이야기를 조금 확장해 보자.

3D에는 엔진이 있다. 흔히 거 그래픽 구리네 돈 좀 더 쓰지 하는 말을 하곤 한다.

그렇다면 서버 발로 만들었냐 하는 말들이 게시판에 오르는 건 어떻게 생각하는 가? (개발자는 정말로 손으로 만들었다며 아니라고 운다.. ㅠ_ㅜ)

응?

 

유저가 보지 못하는 서버와 통신을 위한 엔진 있을 것 같아지지 않는가? 그냥 단순히 Send Recv 이걸로만 게임 다 만들 수 있을까?

서버와 클라이언트 간에 많은 데이터가 오가면서 많은 연산이 필요하다. 클라이언트는 결과값을 보여주는 역할이며, 모든 중요연산은 서버가 다 한다.

그렇다면 모든 것은 통신 데이터의 신뢰성과 안전성 있는 하위 개발의 바탕부터 깔려주어야 작업이 가능해 진다는 말이 된다.

 

물론 3D엔진과 서버엔진이 빵빵 하다고 다는 아니다. 어떻게 쓰느냐가 또한 아주 중요한 문제가 되며 잘 못쓰게 되면 발제(수제의 반대) 서버가 나오기도 한다.

 

 

 

보검을 들고 주먹과 동등하면 암울..

 

그런고로 3D엔진과 통신엔진이 존재하고 이것을 이용하여 기능들을 구현하는 부분을 컨텐츠라 한다.

 

 

‘엔진이 왜 필요하고 중요할까’ 하고 심도 있게 생각해 본 사람이 과연 얼마나 될까?

(개발자 뺴고..-_-;;)

 

알다시피 유명하고 비싼 엔진 쓰면, 거시기한 말로 "퀄리티 쩐다."

그럼 안쓰면 안쩌나?

꼭 그렇지 않다!!

 

프로그래머들이란 자신의 기술력에 자부심을 갖고 있거나 갖을 만큼 실력을 키우고 싶어 하는 존재 들이다. 반대로 개발능력이 되는 사람도 상당히 있다는 소리.

실력 되면 만들 수 있다. 하지만 그래도 사 쓴다.

 

왤까?!?!

 

사장님 왈

"저도 게임 만들 때 엔진 직접 다 만들었죠. 속된 말로 ‘씩X 엔진 만들다 토나오겠네’가 입에서 튀어나오죠 그게 엔진 만들 줄 알아도 사는 이유 중 하나랍니다..."

 

 

 

워워 릴렉스..

 

엔진 무엇이 편해서 쓰는 걸까?

 

만들 때에는 신경 쓸 것이 별의 별게 많다. 쓰기도 편해야 한다.

엔진 하나 만드는데 얼마의 시간과 사람이 필요할까?

1. 최소 5년 이상의 경력자 1~2명 이상 필요.

2. 그 프로그래머가 전에 다니던 회사서 만든 엔진은 그 회사의 재산이다.

3. 개발은 1년은 잡아야 안전성이 높다.

4. 테스트 머신 100마리 200마리 늘려가며 테스트하다 뭔가 이상하면 다시 문제 해결하고 다시 테스트.

5. 아니면 그냥 그 연봉 값과 시간, 개발진들의 스트레스로 엔진을 산다..(잘 만들어진 엔진의 사용은 시간과 돈에 있어 상당히 큰 절약의 수단이 된다.)

 

그리고 나서 만약 엔진 쪽에 에러가 났다. 시급히 잡아야 한다. 근데 다른 일도 너무 많다.

1. 직접 만들고 죽자 살자 미친 듯이 고치자. 까짓 거 없는 시간은 한 달이고 일년이고 잠 안자고 개인시간 다 버리면 되지

   뭐. 그래도 안되면 사람도 더 써!!

2. 걍 사쓰고 에러 났다고 빨랑 고치라고 통보만 보내면 빠른 시일 내에 알아서 해준다. 추가 인력도 안 들고 내 일에만 집

   중하면 된다. (스트레스 감소 최대화)

 

 

 

안전성에 대한 증명사례가 필요하다

1.     미친 듯이 테스트 머신 돌리고 사람 붙여봐서 안 걸려도 만 단위 이상 붙으면 무슨 일이 생길지 아무도 모름..

2.     그냥 이미 다른 게임에서 성공사례가 있는 엔진을 사자..

 

속도가 느리다. 엔진에 대한 업그레이드가 필요하다.

1.     할게 많고 미친 듯이 바쁘다.. 시간을 쪼개고 쪼개서 계획을 세우자..

2.     엔진이나 사 쓰고 통보 한번 보내자 어디가 느리면 테스트 툴로 테스트해 보고 요청 보내면 끝.

 

더러는 어떤 기능을 구현하려고 한다.

1.     죽어라 개발하고 2~3명씩 붙여 유지 관리도 해주어야 할 때가 있다.

2.     그냥 엔진에 붙은 기능 쓰자.

 

네트워크의 경우 플레이어가 2배로 늘면 버그는 제곱으로 는다.. ㅠ_ㅜ 

      1. 내부 테스트에서 잘돌아간다고 그게 정말 버그가 없는 것일까?

      2. 내부 테스트로 모든 확인이 가능하면 '발로 만든' 꼬리표는 세상에 나오지도 않았을 것이다..

 

 

 

실수란 아무리 뛰어난 실력자라 할지라도 피할 수 없다. 사람이기에!!!

결국 가장 중요한 것은 개발된 후, 버그가 발견되고 수정되며 흘러온 많은 시간과, 실질 적용된 사례이다.

 

가만있으면 알아서 어떤 기능이 추가 되어져 올 때가 있다. 예를 들면 다른 게임회사에서 들어가는 어떤 기능 추가 요청에 대한 트렌드가 될 수도 있다. 그냥 그런 기능을 연결만하면 유저는 ‘오 많이 발전했다’ 하고 놀랜다..

 

 

삽질은 많이 해봐야 삽질일 뿐…

 

어떤 에러의 경우 1프로 이하의 확률로 일어나며,

데이터 베이스, 서버엔진, 서버 컨텐츠, 클라이언트 컨텐츠, 글라이언트 엔진

중에 어디가 문제인지 참 애매할 때가 있다. 이럴 때 정신적 고통을 줄이고 시간을 절약하기 위해서도 엔진은 절대적으로 견고해야만 한다.

특히 한달 두달 날수만 늘고 희박한 확률로 버그가 튀어나와서 감도 안 잡히는 경우도 꾀나 종종 생기게 되는데 이런 피마르는 상황을 줄이기 위해서도 엔진의 안정성은 절대적이지 않을 수 없다.

그리고 이중에 저 Server Engine을 개발 하는 회사가 우리 넷텐션인 것이다.

 

 

글좀 줄여바.. 너무 길자나..

온라인 게임 개발에서 로그인 과정은 만들기가 까다롭고 짜증나는 부분 중 하나입니다. 로그온 과정까지 만들기 위해 넘어야 할 산들은 많습니다. 오죽하면게임 서버 개발에서 로그인 과정까지 완성되면 서버 개발의 반은 끝났다고 하겠습니까?

완성되고 나서도 로그온 부분에서 말썽을 일으키기 십상입니다. 로그인 과정 중 오류, 데이터베이스 랙, 그리고 서비스 오픈하면 한차례 겪는 해킹, 아이템 복제 등 후폭풍이 기다립니다.

 

프라우드넷(ProudNet)은 로그인 과정을 쉽고 안전하게 만들 수 있는 여러가지 장치들을 제공합니다. 그중 보안 부분에 대해서 소개합니다.

프라우드넷은 강력한 보안 통신 기능을 제공하고 있습니다. 가령, 로그인 관련 메시지를 높은 암호화를 수행하게 합니다.

 

먼저, 암호화라는 것이 무엇인지 알아봅시다.
어떤 메시지가 다른 컴퓨터로 전달될 때 제3자가 내용을 해독하거나 변조할 수 있으면 해킹을 당하기 쉽습니다. 예를 들어 입력한 아이디,비밀번호가 제3자에 의해 해독/변조가 될 수 있으면, 어느날 게임에 접속했더니 자기 캐릭터가 알몸이 되어 있겠죠.

 

그래서 메시지를 암호화하려면 암호화,해독(복호화)를 하는 알고리즘(공식)이 각각 있어야 합니다. 하지만 알고리즘이 공개되면 위험할 수 있겠죠? 그래서 뻔히 아는 알고리즘이 눈 앞에 있어도 암호화된 메시지를 풀지 못하게 하는 수단, 즉 열쇠(키)가 있어야 합니다. 현대 전산학에서 암호화 알고리즘은 키 기반 암호화가 통용되고 있습니다. 암호키의 길이는 1비트에서 수백 비트까지 다양합니다.

 

해커가 암호화된 메시지를 캐내서 얻어냈다고 가정하겠습니다. 해커가 그 메시지의 내용을 알아내려면 메시지를 해독할 키를 알아야 합니다. 이미 알고리즘은 얻었다고 가정합시다. 어떤 키를 넣어봐야 할지 시도해볼 것입니다. 암호키를 일일히 대보는 해커가 만들었다고 가정해도 어마어마한 시간이 소요됩니다. 

 

키, 즉 암호키는 크게 비대칭키와 대칭키로 구별됩니다. 비대칭키는 한 쌍의 열쇠가 있어서, 한 개의 열쇠로 암호화하면 나머지 한 개의 열쇠가 없으면 해독할 수 없습니다. 대칭키는 암호화할 때 쓴 키와 해독할 수 있는 키가 서로 같음을 의미합니다. 이러한 성질을 활용해서, 컴퓨터 네트워크에서는 암호화된 메시지를 전송하기 위해 대칭키와 비대칭키를 혼용하기도 합니다.

 

두 호스트 A,B가 있다고 가정하죠. A가 B에게 안전하게 암호화된 메시지를 전달하고자 합니다. A는 먼저 비대칭키 한쌍을 만듭니다. 그리고 하나는 자기가 갖고 있고 나머지를 B에게 전송합니다. 자기가 갖고 있는 것을 개인키(Private Key), B에게 전송한 키를 공개키(Public Key)라고 부릅니다.

이때 해커는 가뿐하게 공개키를 얻어버렸다고 가정하겠습니다.

 

 

B는 대칭키(Session Key)를 만들고 갖고 있습니다. A로부터 공개키가 도착했습니다. 이제 그것을 갖고 있는 대칭키로 암호화합니다. 그리고 암호화한 대칭키를 A에게 보내줍니다. 해커는 역시 그것도 얻어버렸습니다.

  

A는 받은 대칭키를 개인키로 복호화합니다. 그리고 B가 만든 대칭키를 공유합니다. 해커는 공개키와 암호화된 대칭키를 갖고 있지만 정작 개인키가 없어서 대칭키 내용을 알 수 없습니다.

 

이제 A는 암호화할 메시지 본문을 B로부터 받은 대칭키로 암호화 후 B에게 전송합니다. 해커는 이것도 갈무리했습니다.

B는 암호화된 본문을 가지고 있는 대칭키로 복호화해서 잘 씁니다. 한편, 해커는 아직도 대칭키를 얻지 못했기 때문에 해킹해서 갈무리한 메시지를 얻어내지 못합니다.

 

 

에라 모르겠다, 해커는 B에게 메시지 내용을 이것저것 훼손해서 보내봅니다. B는 받아서 복호화해봤더니 복호화가 되지 않습니다. 뭐, 그냥 버립니다.

 

프라우드넷은 이러한 암호화 방식을 내장하고 있습니다. RSA는 매우 강력합니다. 하지만 계산량이 막대해서 모든 메시지를 암호화하기에는 벅찹니다. 그래서 대칭키 알고리즘과 혼용합니다.

프라우드넷의 이러한 기능을 쓰기 위해서 사용자(게임 프로그래머)는 딱 하나만 하면 됩니다. 프라우드넷에서 메시지 형식을 정의할 때 “이건 암호화할거임~”만 한마디 적어주면 끝입니다. 위 키 주고받기 과정은 사용자는 신경쓰지 않아도 됩니다. 

 

프라우드넷은 클라이언트와 서버간 통신 뿐만 아니라 P2P로 통신할 때도 지금까지 설명한 방식의 암호화 기능을 제공합니다. P2P간 통신도 제3자가 해독/변조하지 못하게요.

 

여기서 잠깐! 프라우드넷이 어떻게 암호화를 하는지 대놓고 공개해도 괜찮냐고요? 암호화 기법은 알고리즘을 공개해도 뚫지 못하는 데 그 가치가 있습니다. 이렇게 대놓고 공개해도 안뚫리니까 공개하는거죠. ^^;;;

 

프라우드넷이 제공하는 기능은 많습니다. 암호화 기능은 작은 부분에 불과합니다. 하지만 지금까지 홍보가 부족했던 것 같습니다.

 

 

 

프라우드넷 엔진 코어 소스 량입니다. 툴 소스, 테스트 프로그램 소스, 샘플 소스 등은 모두 제외한 분량입니다.

Classes:                        391
Files:                          303
Functions:                     3968
Lines:                        83747
Lines Blank:                  13710
Lines Code:                   53856
Lines Comment:                13472
Lines Inactive:                1083
Declarative Statements:       14379
Executable Statements:        20939
Ratio Comment/Code:            0.25

도움말이 상당히 상세합니다. 그러다보니 주석량 비율이 높습니다.
메시지 포맷 하나 하나를 클래스로 정의하지도 않았는데도 클래스가 무려 391개! 
소스도 무려 8만라인! 뭘 하길래 이렇게 양이 많지? 라고 생각하실지도 모르겠지만, 프라우드넷은40개가 넘는 고객사가 게임서버개발에 쓰면서 제안된 수많은 기능들의 집합체이니만큼 이정도 양은 충분히 나온다고 봅니다. 당연히 중복 코딩 같은건 없죠. 엔진 최적화와 유지보수가 얼마나 중요한데, 설마요 ^^

넷텐션의 배현직님의 블로그 글의 일부 발췌

Feature creep이라는 말이 있습니다. 게임 개발 뿐만 아니라 많은 소프트웨어 개발 프로젝트에서 발견할 수 있는 것들입니다.

ProudNet 빌드중 찍은 샷. Incredibuild가 쓸만한지 궁금하신 분들에게 참고가 될 것입니다.

하얀 공간은 암달의 저주입니다. 

 

 

우선 나를 깜장냥이라 불러달라!

왜 냥이냐 그냥 좋아해서다. 왜 하필 깜장이냐? 어감이 좋다! 그리고 단순해서 좋다.

단지 오래 전부터 써오던 넷 아이디 일 뿐..

 

냥이가 아시는 분들과 갖은 가벼운 술자리 이야길 해보고자 한다.

꾀나 새롭고 놀라운 자리가 아닐 수 없었다.

아니 놀라움을 떠나 경악의 느낌에 얼음 땡을 연달아 반복하였던 경험을 되살려 보자.

 

"어디쪽에서 일하시나요?"

"넷텐션이요"

"헉! 말로만 듣던 그 넷텐션"

 

여기까지는 아주 뿌듯하다 그리고는 새롭게 알게 된 사실들에 외쳐 주지 않을 수 없었다.

"헉!"

 

새롭게 알게된 사실들...

1. 마영전의 네트워크는 넷텐션에서 만들었다.

- 냥이도 처음 들은 사실 이다.. 우리 회사가 그런 것도 했었구나!! ㄷㄷㄷ

냥이는 마영전의 네트워크에 대한 불만을 열씸히 들어주어야 했다..

마영전에 대한 모든 불만은 죄 냥이에게 쏟아지고 있었고 봇물같은 불만에 휩싸이면서 드는 생각

"님하.. 제발.. 그거 우리가 안 만들었다.. ㅠ_ㅜ, 우리는 통신엔진만 팔았다.."

 

프라우드넷과 마영전 네트워크에 대한 대외비적 기밀을 피해 가벼운 선에서의 이야기와 컨텐츠 프로그램과 넷엔진의 차이를 열심히 설명해 주던 중 알게된 더욱 더 놀라운 사실!!!!!!!

 

2. 마영전 운영좀 잘해라

오오오옷!!! 그렇다 우리는 마영전의 운영도 하고 있었다.!!! 대단히 놀라운 사실! 냥이조차 까맣게 모르고 있었던 사실들과 함께

운영에 대한 제안들이 쏟아지고 있다..

더 웃긴 것은 아이디어도 재미있었다는 사실들..

 

조용히 안구에 습기가 차오르고,

'하늘은 노란색도 띌 수 있다'는 재미난 경험도 해볼 수 있었다.

"님하.. 운영정책은 넥슨에 건의해야 하여요..ㅜ_ㅡ"

 

지금까지 나온 이야기들을 조금만 확대해 보자.

저 이야기 대로면 우리는 네트워크를 통째로 만들고 운영까지 해주는 업체다.

가벼운 산수를 해보자.

ProudNet을 이용하는 업체는 40개가 넘는다.

게임 서버 개발은 소규모의 경우 1명이 만들기도 하지만 오픈 시기가 되면 사람을 증가시킨다.

물론 저 케이스는 매우 토하는 케이스이다.

조금 규모가 커지기 시작하면 최소 4명정도로 잡는다. 그럼 한프로젝트당 3명정도를 잡고 개발 마치면 다른 프로젝트로 메뚜기 하면서 도왔다고 치자. 게임 개발기간은 2년을 잡아보자. 동시 진행되는 프로젝트가 20개만 되어도 우리 직원은 최소 60명이 이상이라는 이야기가 된다.

오오 냥이는 그런 대규모 인력을 회사에서 본 적이 없다.

게다가 운영팀까지 계산을 하면 100명은 우습게 넘어가는 기업이 된다.

거기에 대단히 중요하다는 네트워킹을 다 맡아주는 대가에 대한 수익성은?

 

오옷 대단하다! 사장님은 직원들의 눈조차 숨기고 어딘가에 그 대규모 인력을 지부별로 배치하여 대단한 돈을 끌어 모으고 계셨던 것이다!!

냥이가 본 직원 6명은 단순히 현실을 가리기 위한 눈가리개 였던 것인가? 근데 누구를 가리기 위한 눈가리개지?

그러고 보니 그 많은 직원 다 어따 내버리시고 우리랑 매일 계시네..

 

 

 

-       아니면 설마 형님들의 정체가? 문어와 오징어 형님..   –

-       발이 많아 동시 다중 프로세싱 가능  -

 

 

처음에는 '엔진과 컨텐츠의 차이와 마영전의 버그에 대한 오해들을 사장님도 들으셨을 텐데 왜 별달리 움직임이 없으셨을까?'

하는 생각을 해보고 있었다 그러나 엔진과 컨텐츠에 대한 개념을 모르는 이에겐 상당히 어려운 이야기라는 사실을 알 수 있었다.

 

"그래서 가만히 계셨구나.. 이 많은 사람들을 한명, 한명 매우 신경써서 오랜시간 설명을 해야만 이해를 시킬 수 있구나" 라는 사실을 깨달을 수 있었다

아직은 프라우드넷이 역사가 길지 못하다는 생각 살짝 해보면서 '시간을 들여 인지도를 좀 더 올려야 겠구나' 라는 생각을 해 볼 수 있었다.

 

물론 몇년후에는 점점 코어유저들도 알수 있을 만큼 유명해 질 것이다.

왜냐면 프라우드넷은 시간이 갈수록 더욱 강력한 기능들이 서서히 추가 되어가고 있고 사용될 수 밖에 없는 강한 강점들을 이미 많이

가추어져 있기도 하기 때문이다. 또한 정식 엔진으로서 이름 떨칠 모든 계획이 회사에서는 모두 준비되어 있다.

지금도 모든 것들이 한걸음씩 차근히 올라가고 있다.

 

- 뒤에 이을 이야기 -

엔진과 컨텐츠 차이 이야기

엔진을 사용함으로서의 장점

프라우드넷이 앞으로 강력해 질수밖에 없는 이야기 - P2P & 서버의 보드 사이즈로 인한 트레픽 한계 업체를 대신한 기술 발전에 대한 이야기

등등

 

스크롤 압박에 냥이도 놀랐다.. 하지만 아직 냥이는 입이 근질거린다.. (오그리토그리)

 

 

ProudNet은 강력한 P2P 통신 성능을 제공합니다. 릴레이, P2P 홀펀칭이면 전부였다면 ProudNet의 상품 가치는 없었을 것입니다.

공유기의 4가지 홀펀칭 타입(full cone, port restricted, restricted, symmetric NAT)은 이론일 뿐입니다. 멀웨어 차단 기능, 특정 서비스 지원, 심지어는 공유기 소프트웨어 결함 등으로 인해 저 4가지 타입을 완벽히 준수하지 않는 공유기들이 종종 발견됩니다.

물론 이러한 문제를 가진 인터넷 장비는 전체 사용자 중 소수에 불과합니다. 하지만 단 한 건의 문제 발생도 게임개발사는 제보를 받으니까 어쨌거나 해결을 할 필요는 있죠.

 그들 중 일부는 키보드 워리어로도 둔갑합니다.

 

ProudNet을 초기 개발할 당시에는 이러한 부분에 대한 예방책이 부실했습니다. 업체가 사용하다가 문제가 발생하는 인터넷 장비(가령 공유기)가 발견되면 동종 모델의 장비를 구비해서 직접 테스트해보고 문제가 해결될 때까지 씨름하는 방식이었죠. 하지만, 이미 오픈베타가 시작된 게임에서 인터넷 장비 비호환 문제가 나타났을 때에서야 대응하는 것은 위험합니다.

해결방법은 단순무식간단합니다. 전세계 각종 인터넷 장비(특히 희귀종 포함!)들을 진짜로 긁어모아서, 서로 다른 컴퓨터에 연결한 후 테스트하기입니다. 컴퓨터 몇 대만 놓고 장비를 갈아끼우면서 테스트할 수도 있지만, 엔진이 매번 업데이트될때마다 regression test를 하는 것도 시간 낭비입니다. 그러다보니 컴퓨터도 많은 수가 필요합니다.

 

결국 진짜로 저질러 버렸습니다. 각종 인터넷 공유기와 테스트 머신을 구매했죠.

 

 

테스트 전용 컴퓨터들과 수북히 쌓여있는 각종 인터넷 공유기들입니다. 테스트에는 총 30여종 인터넷 공유기가 테스트됩니다. 매 릴리즈마다 말이죠. 서버 전용 랙은 굉장히 비싼지라, 저렴하게 철제 거치대를 주문 제작했습니다.

 

 

 

테스트 전용 컴퓨터 뒤에는 랜카드가 5~12개씩 꽂혀 있습니다. 그리고 이 컴퓨터에는 랜카드 개수 이상의 버추얼 머신이 작동합니다. 즉 서로 다른 인터넷 공유기 뒤에 1~2대의 컴퓨터가 붙어있습니다. 각각 QuadCore 이상의 CPU와 4GB 이상의 RAM이 장착된 컴퓨터들입니다.

 

 

 

IPTV용 장비도 있습니다!

 

 

놀랍게도, 인터넷 전화도 P2P 통신을 방해하더군요. 물론, ProudNet에서는 해결했지만요.

 

 

 

중국산 인터넷 공유기

 

 

 

한국에는 팔지도 않지만 동남아시아에서는 많이 쓰이는 모델 중 하나

 

 

각 테스트 컴퓨터는 개발자용 컴퓨터에서 원격으로 일괄 관리합니다. 테스트 프로그램도 자동 배포된 후 실행되고요.

 

국내외 각종 인터넷 장비를 수집해서 테스트하는 이런 무모한 시도는, 결국 ProudNet의 P2P 안정성을 혁신적으로 향상시켰습니다! 하지만 이것만으로는 한계가 있다고 생각합니다. 왜냐하면 진짜 유저들은 더 엽기적인 환경이나 사용 행태를 가진 경우가 종종 있기 때문입니다. 한 예로 공유기 설정을 자기 마음대로 만졌다가 오히려 사고를 치기도 하는데, ProudNet은 그러한 경우까지도 해결하는 것도 필요하거든요. (실제로도 해결하고 있고요) 어쨌거나 더 희한한 환경과 사용 행태까지도 극복하고 작동하는 네트워크 엔진이 되기 위해서는 더 단순무식적극적인 방법, 즉 검증용 데모 게임을 개발해서 사용자들에게 뿌리고, 그들을 상대로 네트워크 엔진의 성능을 검증하고 개선하는 것이 필요하다고 판단했습니다. 그리고 진짜로! 데모 게임을 개발중입니다.

 

 

진짜 유저들을 상대로 실험해주마!