NDC Replay

WCF를 이용하여 쉽게 만드는 모바일 게임서버
최연승
넥슨코리아
	2007년부터 서버 프로그래머를 시작하여 온라인 게임 서버 개발에 참여 하였고 2012년부터 넥슨에서 모바일 게임 서버를 만들고 있습니다.<br/>현재는 storm팀에서 판타지 러너즈 중국 서버 작업에 참여 하였습니다.
	WCF의 기본 구조 및 기능에 대해 간단히 알아보고 이를 토대로 SOAP 메시지를 주고 받는 웹 서비스 서버를 만들어 볼 것입니다. 청강자들은 이를 이용하여 쉽고 빠르며 누구나 만들 수 있는 SOAP 통신 기반의 게임 서버를 만들 수 있습니다. 이 강연을 청강하기 위해서는 약간의 c#관련 지식이 필요합니다.
[새 창에서 슬라이드 보기]
안녕하세요. WCF를 이용하여 쉽게 만드는 모바일 게임서버라는 주제를 가지고 여러분들하고 한 시간 동안 이야기를 나눌 넥슨 코리아 스톰 팀의 최연승 입니다. 저는 많은 분들 앞에서 이야기 하는 것도 처음이고, 원래 송재경 아저씨가 이 시간에 얘기를 하셔서 아무도 안 올 줄 알았거든요, 진짜? 그런데 너무 많이 오셔가지고 되게 부담이 많이 되는데요. 혹시 오신 분들 중에 서버 프로그래머나 아니면 서버를 개발해야 하는 분 계신가요? 아니면 WCF는 들어보신 분 혹시 계세요? WCF가 뭐다. 몇 분 안 계시네요. WCF는 다들 처음 들어 보셨죠? 이 앞 강의가 파이썬이라서 비교가 될 수도 있는데요. WCF, 앞 강의를 혹시 들어보셨던 분은 파이썬하고 얘하고 뭐가 다른지, 그리고 얘의 장점이 뭔지, 파이썬의 장점이 뭔지를 직접 확인해보신 다음에 앞으로 개발을 하시더나 개발을 참고하실 때 도움이 많이 되셨으면 좋겠습니다. 그러면 시작하겠습니다. WCF는 무엇인가요? WCF가요, Windows Communication Foundation 이라는 영어 약자고요. 간단하게 얘기하면 그냥 원래 SOAP 형식의 메시지를 주고받기 위해서 고안된 런타임과 API 집합이거든요. 쉽게 말하면 라이브러리고요. 단일 프레임워크 3.0 이상부터 제공이 됐던 그런 라이브러리입니다. 그리고 보시다시피 HTTP, TCP/IP, Named Pipe, P2P, 그리고 MSMQ같은 프로토콜들을 지원을 하고요. 그리고 이 밑에 보시다시피 WS 식의 여러 가지 웹 서비스 스펙을 지원을 합니다. 여기 보시면 이게 전적인 아키텍쳐인데요. 여기 보시면 이게 전체 WCF의 아키텍처인데요. 응용 프로그램이 이렇게 있으면 어떤 데이터를 우리가 보낼 지에 대해서는 계약 부분하고요. 실질적인 서버의 구성들, 그러니까 쉽게 말해서 웹 서버에서 우리가 어떤 동작을 하겠다, 이런 것들 나타내주는 서비스 런타임 부분하고, 어떤 메시지들을 통신을 하겠다, HTCP를 이용해서 통신을 하겠다, TCP를 가지고 통신을 하든지, MSMQ를 가지고 통신을 하든지, 이런 것들에 대한 메시징 구현 부 하고요. 그리고 어떤 형식으로 전체 서버를, 운영 프로그램을 돌리겠다고 하는 활성화 및 호스팅 방식에 대해서 이렇게 네 개로 나눌 수가 있고요. WCF의 구성요소를 보시면요. 첫 번째는 메시지 하고요, 엔드포인트, 서비스 이렇게 세 가지로 나눌 수가 있는데요. 메시지는 그냥 우리가 보내는 메시지. 통신하려면 메시지가 필요하죠. 그 메시지를 얘기하는 거고요. 엔드 포인트는 서비스를 호출하기 위해서 필요한 엑세스 포인트로서, Address와 Binding, 그리고 Contract 세 가지로 구분을 합니다. 그리고 서비스는 실제 우리가 호출을 하는, 원격 제어에서 호출을 해 오는 그런 API들에 대한 로직, 이런 것을 서비스라고 명칭을 하고요. 엔드 포인트에 대해서 좀 더 세분하게 보실 건데요. 엔드 포인트는 내부적으로 Address, Binding, Contract 로 나뉘거든요. Address는 그냥 간단하게 주소 생각하시면 되고요. HTTP 어쩌고 저쩌고 들어가는 그 주소 생각하시면 되시고, Binding은 어떤 방법으로 우리가 통신을 하겠다, 아까 보셨던 메세징의 이 부분 있죠? HTTP로 할 것인지 TCP로 할 것인지 이 부분을 바인딩을 통해서 구현을 한다고 생각하시면 되고요. Contract는 서비스에 대한 인터페이스와 이 인터페이스를 어떠한 데이터들을 가지고 통신을 할 것이다, 라고 하는 데이터 타입들을 정의를 하고 계약을 하는 부분입니다. 그래서 간단하게 통신하는 부분을 도표로 그려본 건데요. 그려본 건 아니고 이건 인터넷에 있더라고요. 클라이언트가 콜러죠. 클라이언트에서 서버로 어떤 통신을 하겠다고 데이터를 보내기 시작하면요, 클라이언트는 어떤 것을 어떻게, 어디로 보내겠다, 라고 계약, 쉽게 얘기하면 CBA 형식으로 갈 수가 있고요. 받아들이는 서버 입장에서는 ABC 형식으로. 어디서, 어떻게, 뭐가 왔다. 이렇게 해서 데이터를 주고 받는다고 생각하시면 됩니다.
WCF를 이용해서 그러면 어떻게 서버를 만들 것인가, 그것도 게임 서버를 만들 것인가를 보실 건데요. 여기서부터는 제가 작성한 코드랑 같이 병행을 해서 보실 거거든요. 이 코드는 강연이 끝나고 PPT하고 같이 공유를 해 드릴 거에요. 아마 거의 대부분 이 코드 하나 있으면 간단한 테스트 서버는 만드실 수 있을 거에요. 먼저 계약부터 보겠습니다. 계약은 크게 서비스 계약하고 데이터 계약으로 나눌 수가 있는데요. 서비스 계약하는 방법은 하나의 인터페이스에 선언을 한 다음에요, 그 인터페이스에 서비스 컨트랙트라는 키워드를 붙여 주고요. 그리고 얘가 노출하고자 하는 API 상에는 오퍼레이션 컨트랙트하고 키워드를 이렇게 선언을 해 줍니다. 이것을 코드로 보시면 뒤에 잘 보이시나요? 이게 폰트가 큰지 작은지 잘 몰라서. 일단 임의적으로 확대를 했는데요. 여기 보시면 제가 일단 아이서비스라는 하나의 인터페이스를 선언을 했고요, 퍼블릭으로. 걔 위에다가 좀 전에 말씀 드린 서비스 컨트랙트라는 키워드를 선언을 했고요. 그리고 블록 처리 한 것을 일단 배제를 해 보시면요, 기본적으로 오퍼레이션 컨트랙트라고 되어있죠. 그리고 저는 함수를 노출 시키는 함수를 알리큐로그인 프로세서, 이렇게 지칭을 해서 호출을 시킬 거고요. 받는 파라미터로는 씨알리큐 로그인이라는 클래스의 안에 담겨 있는 데이터 형식들을 받을 거고, 얘를 가지고 돌려보내는 것들은 씨 알리큐 로그인 리절트라는 클래스 안에 담겨 있는 데이터들을 보낼 겁니다. 이런 식으로 호출을 한 거고요. 여기 보시면 오퍼레이션 컨트랙트 앞에 네임이라고 있죠. 이것을 설명을 드릴 건데, 오퍼레이션 컨트랙트 내에 여러 가지 속성들이 있는데요. 그 중에서 좀 주목해야 될 게 네임스페이스도 있고 네임도 있는데, 제가 같이 썼는데, 네임스페이스는 그냥 우리가 흔히 얘기하는 라이브러리 묶음이나 클래스 묶음에서 그냥 네임스페이스 지칭을 하잖아요. 그것을 생각하시면 되고요. 네임 속성은 서버 쪽 보다는 오히려 클라이언트하고 통신을 할 때 이게 좀 중요하더라고요. 저는 몰랐는데, 이게 클라이언트 입장에서 나는 꼭 이렇게만 해야 돼, 라고 얘기를 해줄 경우가 있어요. 나는 여기 분명히 알리큐로그인 프로세스라고 이름을 지었는데 갑자기 클라이언트가 우리는 우리가 명명한 이름 규칙 상 이런 거 안 된다, 우리가 좀 헷갈릴 수 있다, 그냥 로그인이라고 해 다오, 라고 얘기가 나올 수 있거든요. 나오더라고요, 저도 몰랐는데. 그럴 때 그냥 여기 네임이라는 속성을 이용을 해서 땡땡 하고 로그인이라고 지칭을 하면 클라이언트에서 이 API로 호출을 할 때 로그인이라고 해서 호출을 하면 실제 호출되는 함수는 이 알리큐로그인 프로세스가 됩니다. 해서 이것은 실제 서버를 돌려 보면요. 뒤에 설명을 드릴 테지만 이게 WCF로 서버를 만들면 이런 페이지를 만들어주거든요, 자동적으로요? 이걸 어떻게 만드는지는 일단 뒤에 설명 드릴게요. 원래 이 네임이라는 속성을 지칭 안 하면 여기 지금 URL에 보시면 알리큐로그인프로세스라고 노출이 되었죠. 얘가 실제 클라이언트에 호출 되어야 하는 API의 이름인데, 이것을 네임이라고 지칭을 하면 바뀌었죠, 로그인이라고. 이렇게 바뀌어서 실제 구현하는 거하고 외부에 노출하는 거하고 다르게 나타낼 수 있고요. 이 네임 속성은 API를 정의하는 정의부 말고, 데이터를 정의하는 데이터 정의부에도 다 공용으로 들어가있는 속성이거든요. 그래서 이것을 가지고 데이터들도 임의적으로 이름을 바꾸어 줄 수 있습니다. 그리고 이 중에서 제가 여기 WebInvoke라고 제가 선언을 했었는데요, 아까. 이게 원래는 WCF가 SOAP 형식의 메시지 통신을 하기 위해서, 그러니까 XML 기반 통신을 하기 위한 그런 라이브러리인데요. 이게 모바일 환경 내에서는 좀 힘들 경우가 있거든요. 왜냐 하면 모바일 대부분 유니티 아니면 포커스 트리 이런 것으로 작업하시죠. 그래서 얘는 제가 작업을 해보니까 WCF로 만든 애는 클라이언트도 WCF로 지원을 해 줘야 돼요. 근데 지금 유니티는 단일 프레임워크 지원을 하기는 하는데 2.0 이상은 아직 지원을 안하고 있어요. 그래서 힘들더라고요. SOAP 형식의 통신이 아니라 일반적인 HTTP 형식의 통신을 해야 되거든요. 제가 소개에는 SOAP라고 썼는데 그게 잘못 썼더라고요, 제가. 원래 HTTP 형식의 통신을 하는 서버를 만들고 있고요. 그러기 위해서 WebInvoke라고 키워드를 박아주면, 이제 얘가 HTTP 통신을 하기 위해서 데이터들을 파싱을 하기 시작 합니다. 파싱을 어떻게 할 거냐, 그러면 여기 Invoke 속성 안에 보시면 리퀘스트 포맷이 있고 리스폰스 포맷이 있거든요. 이것을 가지고 JSON으로 두면 이 안에 포맷이 두 개가 있어요. JSON이 있고, XML이 있는데요. 이렇게 되면 리퀘스트는 받는 것은 XML로 받고, 돌려주는 것은 JSON으로 돌려주겠다고 선언을 하는 거거든요. 그래서 이것을 가지고 양쪽을 다 JSON으로 하고 싶으시면 둘 다 JSON으로 선언을 해 두시면 주고받을 때 다 JSON으로 주고받게 됩니다. 요즘 대부분 JSON으로 많이 통신을 하죠, 그리고. 저희는 이렇게 통신을 썼고요. 여기 있는 디스크립션은 그냥 없어도 되는데 없으면 아까 그 페이지 상에서 설명 부분이 노출이 그냥 이렇게만 나와 있고요. 설명이 아까 디스크립션을 달면 이 API가 어떻게 어떤 API다, 라는 것을 설명으로 보여주는 거죠. 이것을 왜 하냐 하면, 저희가 보통 통신용 프로그램을 만들거나 통신 작업을 할 때 보시면 프로토콜 문서를 많이 만들거든요. 항상 저도 온라인 게임 할 때 프로토콜 문서를 만들고, 이런 모바일용 게임을 할 때 프로토콜 문서를 만들었는데, 이것을 하니까 프로토콜 문서가 별로 필요가 없더라고요. 물론 보관용으로는 작업을 다시 하기는 해야 되는데, 그냥 테스트 서버를 이렇게 띄워 놓으면 클라이언트 프로그래머가 이 URL을 가지고 들어와서 이거 보고 작업을 하면 됩니다. 메소드를 누르면 이에 관련된 데이터들도 주고 받을 수 있고요. 보낼 때는 UID만 보내고 받을 때는 이런 것들을 받을 수 있게 되어 있다, 이렇게 볼 수 있거든요. 이게 JSON 포맷이든, XML 포맷이든 두 개 다요. 볼 수 있어서 이렇게 나름 공유를 하니까 편하더라고요. 그리고 다음으로 데이터 계약인데요. 데이터 계약은 우리가 뭘 주고받을지에 대한 데이터를 계약을 하는 것을 나타내는 거고요. 여기서 중요한 것은 클라이언트와 서비스가 같은 형식을 공유하지 않고 같은 데이터 계약만 공유해도 통신이 가능하다는 것. 이게 데이터 계약만 같이 공유를 하고 실제 클라이언트 내에서 보내는 것을 맞춰서만 보내 주면 된다는 얘기고요. 데이터 계약을 하려면 데이터를 보내주는 계약 부에 컨트랙트 특성과 데이터 멤버 특성을 선언해서 사용자 데이터 타입을 계약을 합니다. 그리고 데이터 컨트랙트로 선언이 되면 송수신시에 자동적으로 Serialization, DeSerialization을 거쳐서 우리가 별도로 파싱 작업이나 이런 것을 하지 않아도 알아서 해주고 있고요, 단일 프레임워크 내에서. 그리고 Serialization의 종류는 변경이 가능합니다. 데이터 컨트랙트 하는 것을 보실 텐데요. 아까 예제를 보면 로그인할 때 제가 씨알리큐로그인이라는 클래스를 가지고 데이터를 받았잖아요. 이 안을 보시면 이렇게 구성되어있거든요. 잘 안보이시죠? 잠시만요. 여기 보시면 씨알리큐로그인이라는 클래스를 선언을 하고요. 그 위에 클래스 위에 데이터 컨트랙트라고 선언을 해 주고요. 그리고 안에 들어가있는 멤버 변수에 이 클래스의 데이터 멤버라는 것을 지칭해주기 위해서 데이터 멤버를 선언합니다. 만약에 이 데이터 멤버를 선언하지 않을 경우, 이럴 경우에는 아까 그 헬프 파일에 노출이 안됩니다. 여기 보시면 요청에 안 나오죠. 그런데 여기에 이렇게 데이터 멤버를 선언하면요. 여기 A, 이렇게 보이시죠. 이렇게 해서 실제 이 하나의 클래스만 가지고 내부에서 쓸 수도 있고요. 내부에서만 쓸 수 있는 변수들은 데이터 멤버를 쓰지 않고 실제 통신할 변수들만 이렇게 데이터 멤버를 쓰면 되고요. 이것은 일종의 버전 관리 측면인데, 이 데이터 멤버 특성 안에 보시면 is required 라고 있는데요. 이렇게 툴을 적용해버리면 얘는 이 패킷을 주고받을 때 필수 멤버 변수가 되거든요. 그래서 클라이언트에서 받을 때, 파싱 하거나 그럴 때 얘를 보낼 때 누락을 시키면 데이터가 정상적으로 처리가 안 돼요. 이런 기능을 가지고 뭐 버전 관리를 한다든가 등으로 쓸 수가 있습니다. 그리고 데이터 컨트렉트 내에서 Serialization나 DeSerialization가 실행이 될 때 작업 시작 전후에 이벤트 발생을 임의적으로 시킬 수 있거든요. 그래서 Serialization이 다 끝난 다음에 암호화를 거기다 건다든가, 아니며 다른 헤더를 갖다가 넣는다든가 하는 식으로 처리가 가능하고요. 그것은 되게 간단하게 여기 안에다가 함수 하나를 놓고 OnSerialized, OnSerializong, OnToSerialized, OnToSerializing, 이렇게 해주면 Serialize위치, 저희가 선언해 놓는 키워드의 위치에 따라서 해당 작업이 수행이 됩니다. 그리고 이게 보내는 데이터가 얼마나 복잡한 데이터를 보낼 수 있느냐가 또 관건인데요. 웬만한 건 다 보내고요. 리스트도 보낼 수 있고, 딕셔너리도 보낼 수 있고, 하다 못해 상속받은 클래스도 보낼 수가 있고요. 우리가 데이터를 주고 받을 때, 예를 들면 이런 데이터도 주고 받을 수 있거든요. 이렇게 C 아이템 리스트를 보내는데 이 C 아이템이 상속 관계의 아이템일 수 있어요. 이렇게 나는 저 아이템 리스트에 웨폰 아이템을 넣고 싶은데 C 아이템을 선언을 해서 그때그때 다른 데이터를 갖다가 상속 관계의 클래스를 보내고 싶을 때 상위 클래스에 KnownType 이라고 지칭을 해 주고 그 하위 클래스를 갖다가 쭉쭉쭉 선언을 해 주면 이제 상위 클래스만 선언을 해도 내부적으로 알아서 얘가 그것을 가지고 전달을 해 줍니다. Serializing을 다 해서 클라이언트로 전달을 해 주고, 클라이언트에서 받아다가 맞는 타입에 맞춰서 풀어주면 되겠죠. 그리고 바인딩은 되게 이 WCF가 잘 만들어진 게 정말 다양한 방법으로 커스터마이징도 가능하고 다양한 종류를 많이 지원을 하거든요. 그런데 아직까지는 저희가 쓸 수 있는 바인딩은 이 WebHttpBinding, 이것을 쓸 수 있고요. 제가 지금 바인딩 종류를 적어 놓은 게 여섯 가지 이거든요? 근데 그 중에서 여섯 가지 적은 이유가 나중에 얘가 버전업이 되거나 WCF MS 회사가 약간 헤까닥 해서 유니티3D도 지원을 해 준다든가, 그럴 경우도 대비를 해서 모바일 용으로만 서버를 만드는 게 아니라 클라이언트 일반 윈도우 클라이언트하고 통신하는 그런 게임들을 만들 수 있잖아요? 거기에 쓰일 만한 것들을 몇 개 추려봤는데요. BasicHttpBinding은 제일 베이스이고요. 얘를 상속받아서, 아니면 다른 것들을 상속받아서 다른 여러 가지 바인딩들을 입맛에 맞게 구현을 할 수 가 있고요. 그리고 WebHttpBinding은 제가 말씀을 드렸고, WS 듀오 HttpBinding이 있는데 저도 이것을 안지 얼마 안되었는데, 양방향 통신이 가능한 그런 바인딩이더라고요. 그래서 클라이언트가 서버에 있는 API를 호출을 하면 서버에서 호출한 놈의 정보를 들고 있다가 비공개 처리를 하고 나서 걔 API를 다시 호출을 해서 데이터를 넘겨 줘요. 그래서 웹 통신인데 웹 소켓을 안 쓰고 내부적으로 어떻게 되는지 제가 아직 거기까지는 공부를 못해봐서 모르겠는데 웹 소켓을 안 쓰고 양방향 통신으로 비동기 통신이 가능한 프로토콜입니다. 그리고 NetTcpBinding은 그냥 TCP/IP 통신 가능하게 만들어주는 바인드고요. NetPeerTcpBinding은 P2P 통신이 가능하게 해주는 바인딩입니다. 둘 다 성능은 더 우수하고요. HTTP 안 쓰니까. 그런데 상호 운영성은 좀 떨어져요. 클라이언트도 같이 WCF를 써야 되더라고요. 제가 안 쓰면서 할 수 있는 방법을 좀 고안을 해 보았는데 저는 일단 제가 공부한 수준에서는 안됐습니다. 일단 아직까지는 안 되는 것 같더라고요, 그게. 그래서 이렇게 알고 있으면 혹시 나중에 혹시 모바일 뿐만 아니라 윈도우용 게임을 만들어도 충분히 얘만 이용해서 되게 손쉽게 서버하고 클라이언트 작업이 가능할 것 같아서 이렇게 소개를 해 드립니다. 그래서 이게 그림이 잘 안보이시죠? 이게 뭐냐 하면요, 우리 프로젝트에는 어떤 바인딩이 적합할까, 를 그냥 도표로 만든 거거든요. 이게 시작이고요. 딱 내려와서, SOAP 방식을 쓸 것인가, REST 방식을 쓸 것인가, 해서 SOAP를 쓰면 거기서 다시 여러 개를 쭉쭉쭉쭉 나눠가지고 여러 가지 바인딩이 나오고 저희는 SOAP를 안 쓰기 때문에 이렇게 내려오면 WebHttpBinding을 써야 된다, 이 얘기를 그냥 도표로 쓴 건데, 잘 보이시나요? 그리고 모든 바인딩들은 제일 밑에는 Custom Binding 이거든요? 커스터마이징이 가능하다, 라는 것을 알아두시면 될 것 같고요. 마지막으로는 서비스 호스트, 서버를 어떻게 돌릴 것인지, 그리고 서버 세팅 관련된 것은요, 제가 코드로 설명을 해 드릴게요. 우선 저희가 아까 아예 서비스를 작성을 한 것을 보셨잖아요. 그럼 이제 얘를 구현을 해야죠. 저는 C 서비스라는 클래스를 하나 만들었어요. C 서비스라는 클래스를 만들어서 아이서비스에 인터페이스를 다 구현을 했는데요. 여기서 좀 주목하셔야 될 게 여기 Service Behavior라고 있죠. 이게 이 서버가 어떤 식으로 동작을 할 것인지에 대해서 선언을 한 건데요. 여기서 서버의 인스턴스 모드하고 컨쿼런시 모드를 변경할 수 있거든요. 인스턴스 모드는 쉽게 얘기하면 얘를 싱글로 돌릴 것인지, 아니면 이 인스턴스, 서버 자체를 세션이 물릴 때마다 원 클라이언트 원 세션으로 묶어가지고 하나의 인스턴스를 묶을 것인지 이런 것들을 설정을 할 수가 있고요. 저희는 싱글 인스턴스로, 왜냐 하면 서버는 올라갔다가 죽을 때까지 하나의 인스턴스로 돌아야 됐었기 때문에 싱글로 뒀고요. 그리고 컨쿼런시 모드는 이게 멀티스레드거든요. 제가 제일 어려워했던, 제가 서버 프로그램 처음부터 제일 어려워했던 멀티스레드였는데, 멀티스레드도 이제 신경 안 써도 돼요. 이것을 쓰면. 그냥 멀티스레드 모드를 어떻게 돌릴까에요. 이 디파인 된 걸 보시면 싱글스레드로 할 것인지, 스레드를 하는데 락을 잡고 쓸 것인지 아니면 그냥 API 하나 취할 때마다 스레드를 계속 하나씩 만들어가지고 돌릴 것인지, 이렇게 나눌 수 있는데요. 저희는 멀티플로 해서 싱글 인스턴스에 멀티 스레드, 해서 하나의 API가 호출이 되면 스레드가 하나가 생성이 되어서 그 API에 대한 모든 로직 처리를 하고, 끝나면 데이터를 반환하고 스레드를 다시 원래 스레드 풀로 돌립니다. 이렇게 해서 저희는 이 서버를 기반으로 해서 중국 쪽에 서비스를 하나 했었거든요. 그 때 초당 대충 한 1500에서 2000건 사이로 처리했던 것 같아요. 그래서 하나로 많이 받았죠. 되게 많이. 개수는 설명하면 제가 큰일 나서 안되고요. 나중에 저희 쪽에 오시면 그 때 내부 되면 설명해드릴게요. 혹시 그런 분 계시면, 제가 원래 말씀을 드리려고 했는데 안 된대요. 그리고 저렇게 환원을 했으면 써먹어야죠. 어떻게 써먹을 것이냐? WCF를 구글링을 많이 해보시는 분들은 아시겠지만 대부분의 예제가 IIS에 올려서 쓰는 웹 서버 형식이에요. 저 싱글 인스턴스에 멀티 스레드도 아니구요. 그래서 약간 코드기반의, 방금 제가 콘솔 창을 띄웠죠. 이런 콘솔 기반의 그런 서비스를 설명을 해 주는 그런 게 없더라고요. 그래서 저희는 지금 중국에서 서비스하고 있는 것은 이렇게 콘솔로도 띄울 수 있고, 윈도우 서비스에 올려서 쓸 수 있는 형식의 서버를 쓰고 있고요. 이 코드 기반도 당연히 그런 형식의 코드로 기반이 되어있습니다. 안 작죠? 여기서부터 이제 WCF 관련된 내용인데요. 저희가 웹 통신을 한다고 했잖아요? 그래서 서비스 호스트라는 것을 생성을 해서 호스트를 만드는데 그 중에서 저희는 웹 통신을 할거니까 웹 서비스 호스트를 선언을 합니다. 이게 서비스 호스트 종류가 데이터의 주고받은 데이터의 바인드나 선언에 따라서 달라지거든요. 저희는 웹 통신을 하려고 하기 때문에 웹 서비스 호스트를 선언을 했고요. 어떤 주소로. 이건 제자리인데. 그래서 포트는 1219번으로 한다. 이렇게 했고요. 이거 바인딩은 제가 아까 말씀 드렸다시피 WebHttpBinding을 쓴다, 라고 설명을 해주고, 여기 보시면 맥스 리시브드 메시지 사이즈가 있고 맥스 버퍼 사이즈가 있는데 이것은 서버 작업을 해보신 분들은 아시겠지만 버퍼 크기하고 내가 받을 메시지의 크기를 지칭을 해 주는 거고요. 이렇게 해서 그냥 아까 저희가 호스트 만들었잖아요? SVC 호스트라는 데에다가. 애드만 해주면 끝이에요. 이렇게 하면 서버 올라가요. 그리고 동작 돼요. 그러면 이거 같은 경우에는 만 바이트에 버퍼 사이즈 만이네요. 이렇게 해놓으면 아까 그 로그인하는 서버 하나 올라간 거에요. 이게 땡이에요. 통신을 위해서 데이터 파싱을 하고, 그 안에 세션을 관리를 하고 그런 작업 할 필요가 없어요, 모두. 저는 원래 온라인 게임부터 서버를 시작을 했는데, 저는 그게 되게 힘들었거든요. 원래 처음은 클라이언트 프로그램만 이해하다가 나이가 너무 많다고 서버로 전향하라고 해서 서른에 서버로 전향을 했거든요. 근데 그 때 정말 힘들었거든요, 저는. 파싱을 하고 TCP/IP가 붙고 포트에 붙어가지고 뭐가 일어나고, 그런 작업을 이해하는 작업이 정말 힘들었는데 그것을 다 이해하고 나니까 이런 것들이 나오더라고요. 정말 편해요. 클라이언트 프로그램들도 그냥 기본 포맷만 아시면 하나 뚝딱 만들어놓을 수 있고요. 이거 하나 만들어놓고 그냥 주구장창 프로세스만 바꿔가지고, 데이터하고 API 로직만 하나 바꿔가지고 다른 서비스도 하실 수 있어요. 단지 내부적인 로직을 좀 더 잘 짜야 되겠죠. 부가적으로 또 설명을 해 드리면 아까 제 웹 페이지 하나 만들어졌잖아요. 이거는 제가 임의로 만든 게 아니고요. WCF 에서 제공을 해주더라고요. 단일 프레임워크 따위를 제공해주는 것 같아요. 이거 그냥 지들이 알아서 만들어주거든요, 내부에서. 이것은 여기 보시면 웹 HTTP 에 관한 게 있어요. WCF는 모든 속성이나 이런 것들을 비헤이버라는 것을 가지고 제어를 다 하거든요. 그래서 그 비헤이버를 찾아다가 우리가 어떤 값들 세팅을 해주면 얘네가 다 알아서 그것을 제공을 해 줘요. 웹 HTTP 비헤이버라는 게 있고요. 이 헬프인에블드라고 하는 프로퍼티거든요. 이 프로퍼티를 가지고 프로를 두면 아까 같은 웹 페이지가 형성이 되고, 펄스를 두면 웹 페이지가 생성이 안 됩니다. 그래서 내부 테스트 하실 때는 프로로 두어가지고 클라이언트 프로그래머들하고 유기적으로 작업을 하시고, 외부에 서비스 하실 때는 항상 꼭 펄스로 하셔야 돼요. 안 그러면 해킹할 때 아주 유용해지실 수 있어요. 그래서 걔네들은 다 비헤이버들 안에 다 넣으시면 되고요. 추가적으로 throttling behavior라고 해서 이 서버에다가 클라이언트 세션을 몇 개를 붙이고 동시에 호출될 수 있는 API 개수는 몇 개다, 이런 것들을 다 호출을 할 수가 있거든요. 이것을 가지고 서버의 성능을 튜닝 할 수가 있겠죠. 그게 서비스 throttling behavior고요. 걔는 서비스 호스트 안에 디스크립션이라는 안에 또 비헤이버들이 여러 개 있거든요? 그 안에 있습니다. 그래서 거기서 찾아다가 맥스 컨커런트 세션스는 최대 클라이언트 접속 수고요. 이게 2000이라고 선언했다고 해서 2000개만 붙이는 게 아니고요, 작업 다 끝난 애들은 떨어져 나가겠죠. 그래서 계속 아무튼 2000개가 넘어가는 클라이언트가 붙으면 나머지 애들은 대기를 하고 있다가요. 빠져 나가는 즉시 대기 루키에서 다시 빼다가 작업을 해요. 그리고 맥스 컨커런트 콜스는 아까 저희가 작성했던 API들, 그 API들의 호출 개수, 그러니까 이게 동시에 몇 개를 처리할 수 있냐, 그것을 나타내는 거거든요. 제가 하나의 클라이언트에 동시에 추출할 수 있는 서버 개수를 써 놨는데요. 이게 아니라 동시에 호출할 수 있는 서비스 개수, 서비스는 API를 의미합니다, 전체 서비스가 아니라. 이런 것들을 다 셋팅을 해서 그냥 오픈, 하나 하면 끝나요. 실행을 시키면 돌아가고 있죠. 이것은 제가 지금 내부로 만든 건데 IOS 헤더가 지금 천 개고, 최대 프로세스 타임은 한 6msec에서 8msec 정도 왔다 갔다 하고 있고요. 이럴 때 제가 클라이언트를 한 번 붙여 볼게요. 지금 이 서버는 제가 중간중간에 말씀을 안 드렸는데 단일 프레임워크에 보면 여러 가지 재미있는 기능이 많이 있거든요? 그래서 그 중에서 엔티티 프레임워크라는 거 하나하고요. 컨쿼런시 쪽 네임스페이스가 있는데 컨커런시 네임스페이스는 이제 멀티스레드 관련된 거에서 딕셔너리나 리스트 같은 것들을 스레드에 세이프티하게 해주기 위해서 쓰는 컨쿼런트 딕셔너리하고 컨쿼런트 백 이런 것들을 얘기하고요. 엔티티 프레임워크는 이제 DB하고 연결을 하는 거거든요. 얘는 실제 마이SQL에 선언이 되어있는 테이블 이름이고요. 엔티티 프레임워크가 하는 일은 DB를 읽어 와서 클래스화 시켜가지고 실제 클래스처럼 구동할 수 있게 만들어주는 되게 유명한 거라 얘도 좀 파고 드시면 되게 유용하실 거에요. 실제로 저희가 중국에 서비스했던 것은 WCF하고 이 엔티티 프레임워크를 다같이 혼용해가지고 작업을 했습니다. 그래서 로그인을 하면요. 아까 그 저희가 생성했던 함수죠. 함수의 구현부인데, 로그인을 하면 UID를 받아다가 get user 함수를 호출해요. 유저 매니저에. 얘는 뭘 하냐? 얘는 유저 리스트를 들고 있고요. 아까 제가 말씀 드린 concurrentdictionary를 이용한 유저 리스트를 들고 있고 거기서 메모리를 찾은 다음에 없으면 DB에서 로드를 해요. 그리고 DB에서 로드 할 때도 셀렉트를 먼저 한 다음에 DB에 없으면 생성을 해요. 셀렉트하고 생성 끝이거든요. 그래서 그것을 가지고 리턴 시키는 건데, 얘를 한번 돌려 볼게요. 초당 500개 해서 돌리면 제 거가 PC가 성능이 좀 딸려서, 지금 쭉쭉쭉 들어오죠. 지금 이 PC, 노트북 안에다가 DB 띄우고, 서버 띄우고, 클라이언트 띄우고 해가지고 되게 느린데 계속 들어오고 있죠. ISO 헤더도 줄었다가, 늘었다가, 줄었다가, 늘었다가 하고 있고요. 프로세스 타임도 늘었다가 줄었다가 하고 있죠. 프레임도 마찬가지로 거의 고정이고요. 뭐 80~90이면 거의 안정적이죠. 이런 식으로 지금 계속 클라이언트 생성하고 있는 것을 보고 계시고요. 지금 시작하고 나서 한 3~40분 지난 것 같은데 3~40분 만에 다 모르시는 분들인데 서버 하나 만든 거에요. 되게 쉽습니다. 그리고 그래서 마지막은 WCF의 장점과 단점을 말씀 드리고 끝낼 건데요. 일단 장점은 다양한 프로토콜과 서비스 방식을 지원한다는 거고요. 지금은 제가 콘솔 창으로 띄웠는데 이것을 IIS로 올려가지고 높이 띄우실 수도 있어요. 그리고 높은 생산성 및 안정성, 이건 C#이니까. 그리고 디버깅이 쉽다, 이게 가장 큰 장점인 것 같아요. 요새 나오는 여러 가지 스크립트 기반 언어 있죠? 파이썬도 있고, node.js도 있고, 다 쓰기 편하고 강력한 툴인데 전 제일 싫었던 게 디버깅이 안 된다는 거, 그게 제일 싫었거든요. 그래서 디버깅이 되게 쉽고요. 네트워크 프로그래밍 전문가가 아니더라도 서버 작업이 가능하다, C#만 아시면 서버 작업이 가능하세요. 그리고 쉽고 빠른 대신에 프로그래머가 로직 및 구조적 코딩에 집중할 수가 있다. 저희도 이거 하나를 딱 만들어 놓고 3개월 정도를 계속 뭘 했냐 하면 리팩토링 하고, 초 재고, 늦으면 다시 리팩토링 하고, 초 재고, 리팩토링 하고, 이 작업을 계속 반복했거든요. 그래서 그런 것들을 좀 중점적으로 공부를 할 수가 있고요. 우리가 매일 책으로만 보던 리팩토링, 그런 것, 다 한번 해보실 수 있고요. 단일 프레임워크에서 돌아가는 거다 보니까, 단일 프레임 워크에서 제공하는 다양하고 풍부한 라이브러리들을 같이 사용할 수가 있습니다. 아까같이 NTT 프레임워크나 컨쿼런시 매니지 페이지 같은 것을 다 같이 쓸 수가 있고요. 그리고 WCF하고 NTT 프레임워크는 정말 서버 프로그래머가 월급 도둑질을 하면서 잉여로운 생활을 할 수 있는 정말 지름길인 것 같아요, 저는. 익숙해지면 시간적 여유가 많이 생겨. 단점은, 가장 큰 단점인데요, 단일 프레임워크에서 제공되는 거다 보니깐 OS 자체가 MS 제품군이어야 돼요. 이게 뭔 얘기냐 하면은 돈이 많이 나가요. 그래서 이 MS가 좀 대단한 가격 정책을 펴가지고 돈이 진짜 많이 들어가더라고요. 저도 몰랐는데, 알고 나니까 많이 들어가더라고요. 그런데 요새 좀 모노라고 많이들 아시죠? 좋으신 분들이 이것을 리눅스에서 돌릴 수 있도록 코팅을 하고 있거든요? 그래서 모노 프로젝트가 여러 개 있는데 그 안에 모노 퍼 WCF인가 있어요. 그것을 쓰시면 완전 최신 기반 기술까지는 아니더라도 어느 정도 수준까지는 그것을 이용을 해서 리눅스에서 돌릴 수 있다고 하더라고요. 그런데 제가 그것을 해 보지는 않아서 성능적인 보장은 저는 잘 모르겠고요. 그리고 모바일 게임의 경우에는 다른 여러 바인딩을 쓸 수가 없고 오직 웹 HTTP 바인딩만 쓸 수가 있다는 것, 그래서 클라이언트의 기능 재현이 필연적이다, 라는 것입니다. 저는 일단 발표는 준비된 것은 여기까지이고요. 
질문 받겠습니다. 보안 말씀 해주셨는데요. 보안에 대해서 되게 취약하죠, 지금은. 클라이언트와 서버 간의 모든 프로토콜이 1219번 포트를 통해 내비게이션 된다면 보안에 대한 취약점은 어떻게 대처할 수 있는지 궁금합니다, 라고 하셨는데요. 이게 바인딩을 하나하나씩 선언하는 게 아니라 여러 개 둘 수 있거든요. 그래서 로직 자체를 아예 그냥 분리를 시켜버릴 수도 있고요. HTTP 뿐만 아니라 HTTPS도 지원합니다. 제가 보안 관련된 것을 말씀을 안 드렸는데요. 보안 설정도 물론 가능하고요. 여기 지금 제가 주석을 해 놓았는데, 여기 보시면 웹 시큐리티라는 항목이 있거든요. 이 웹 시큐리티라는 항목 내에서 보안 모드를 어떻게 할 것인지, 그리고 보안 수준의 레벨은 어떻게 할 것인지, 인증서를 쓸 것인지 안 쓸 것인지, 이런 것들을 다 셋팅 가능하고요. 얘는 바인딩에 넣어주면 웹 보안이 들어갑니다. 그래서 보안 설정을 해 놓으면 HTTP가 아니라 HTTPS로 URL을 오픈 시키셔야 되고요. 여기서 런을 시키면 에러가 나요. 여기 보시면 바인딩의 끝점에 대해서 HTTPS 구성표가 일치하는 기본 주소가 없습니다, 라고 되어있죠. 그래서 얘는 HTTPS로 오픈을 해야 돼요. S로 해서 올라가죠? 네. 그런데 문제가 뭐냐 하면 HTTPS가 인증서가 필요하거든요? 그래서 이렇게 콘솔 창으로 돌리기에는 좀 무리가 있고요. 인증서를 쓰실 거면 IIS에다 돌리시면 됩니다. 저희는 IIS를 안 돌리고 한 번 해보고 싶어서 이렇게 하고 아까 프로토콜 Serializing, Decerializing하는 부분 있잖아요? 거기 암호화를 걸었거든요. 그렇게 해서 작업을 하고 있었고요. 그것도 각각 호출되는 API에서 호출되는 데이터들마다 암호화를 각각 다 방식을 따로 거실 수 있어요. 
그리고, 여기 보시면 내용은 되게 많은데 결론은 “모바일 환경에서 데이터 캐핏에 대한 부담을 어떻게 처리하는지 궁금합니다.” 
라고 하셨는데요. 일단은 전송 방식에 대한 부담은 생각을 안 했고요. 대신 패킷 설계를 좀 약간 다르게 했거든요, 저희는. 중국 같은 경우에는 환경도 되게 안 좋은데 요금도 비싸요. 그래가지고 물론 클라이언트가 하는 일이 많아지기는 하지만 패킷을 보낼 때 이왕 보내는 거 한꺼번에 확 보낸다든가, 서버 로직 내에서 보낸 패킷들을 좀 더 가지고 있다가 처리를 한다든가 하는 식으로 내부적으로 처리를 했었고요.
“여기에 HTTP 기반의 통신에서 msf 중 ASP 닷넷, MVC, 웹 API 등 기존의 웹 환경에서 발전된 베스트폴 형식의 방식이 많은데요. 굳이 WCF가 좋다고 생각하시는 이유에 대해서 궁금합니다.” 
라고 하셨는데요. 제가 생각하기에는 게임이라는 게 요새는 웹 쪽에서 넘어오시는 것도 많고, PHP나 이런 것을 이용해서 웹 형식의 그런 작업들을 하는 게 많은데, 저는 좀 약간 옛날부터 게임 쪽 작업을 하던 사람이다 보니까 일단 1차적으로는 이런 방식이 저는 되게 편했고요. 코드 리스트 보고, 디버깅도 걸고, 내가 여기서 이것저것 다 할 수 있고, 이런 게 되게 좋았고, 웹에서 돌리는 방식하고는 좀 다르게 게임 쪽 서버만의 설명하기 애매한 문제들이 발생할 수 있거든요. 멀티스레드 문제라든가, 그러니까 스레딩 여러 개 돌렸을 때 그 중간에 데이터를 공유하잖아요? 그 안에서 락이 잡힌 것을 처리하는 방법에 대한 문제라든가, 아니면 분산 서버를 할 때, 그리고 데이터를 주고받을 때 중간중간 생기는 미묘한 문제들이 있는데 저는 그런 거에 대한 경험이 웹으로는 솔직히 없었고, 제가 제일 편한 방식으로 찾다 보니까 결국은 WCF를 찾았고, WCF 중에서도 이렇게 콘솔 창을 띄우거나 윈도우 서비스에 올려가지고 쓰는 방식을 택했습니다. 방식이야 여러 개 많죠. 언어도 많고. 세상에 널려있는 게 방식이고, 방법인데 저는 제일 좋은 게 뭐가 좋다고 해서 그것을 따라가는 게 아니라, 그냥 내가 편하면 좋은 거 같아요. 여기서도 그렇게 현재 작업하시는 분들도 많이 계시고, 앞으로 학생 분들도 많이 계셔서 공부를 해서 서버 프로그래머가 되시던지 아니면 서버 쪽 공부 하실 분들이 많이 계실 텐데, 저는 언어를 찾거나 작업 환경을 찾을 때 제가 편했던 방식을 찾거든요. 그게 가장 내 스스로 책임지기 좋고요, 유지보수 하기도 좋고, 그러다 보니까 성능 내구도 더 좋고, 그랬던 것 같아요. 여기 보시면 jmeter로 클라이언트를 대체한 거거든요. jmeter를 보시면 네임이 호출되는 API 이름이에요. 그것을 가지고 있을 필요 없이 그냥 보고 클라이언트를 호출하면 돼요. 이게 제가 아까 보여 드린 파일 보시면요. 이렇게 되어있잖아요. HTTP, 로컬호스트, 1219 / 로그인. 이게 클라이언트가 이 API를 호출하는 원격 주소라고 생각하시면 돼요. JSON으로 파싱 해야죠. XML이 편하시면 XML로 하셔도 되고요. 만약에 클라이언트도 똑같이 그것을 쓰고 싶다, 그러면 윈도우 기반의 WCF를 클라이언트가 쓰시면 됩니다. 그러면 거의 예전에 웹 텐션이었나요? 우리나라 라이브러리 제공하는 회사, 거기서 그런 형식으로 작업을 하거든요, 실질적으로. 서버가 작업을 해가지고 프록시 파일을 클라이언트한테 제공을 해요. 그럼 클라이언트가 그것을 가지고 원격 호출을 해요. 거기도 내부적으로 그렇게 하더라고요. 
또 따로 없으세요? 그렇죠. 없고요. 단일 프레임워크 내에서, 제가 아까 보여드렸잖아요. 엔티티 프레임워크를 저는 썼고요. 이것을 안 쓰실 거면은 그냥 ODBC 할당 해가지고 하셔도 돼요. 그런데 예전 같은 경우에는 엔티티 프레임워크가 좀 느려서 제가 권장을 안 해드렸는데, 지금은 엔티티 프레임워크가 많이 발전을 해 가지고, 그래서 제가 들고 나온 거거든요, 만들어서요. 그래서 엔티티 쓰셔도 될 것 같아요. 그런데 엔티티 프레임워크를 쓰면 회사의 DBA들이 싫어해요. 쿼리를 모른다고 되게 싫어해요. 어떤 쿼리가 날라가는지 모른다고 되게 싫어해요. 하나를 보여 드릴게요. 이게 지금 쉽게 얘기하면 내부에, MY SQL을 깔아 놨거든요. MY SQL 커넥터를 이용해서 DB 정보를 받아 온 거에요. 얘를 지워버리면, 시간이 별로 없어서, 테이블에 보시면 이건 오타고요. 테이블 유저라고 있죠. 이게 실제 DB에 있는 테이블_유저 라는 테이블의 정보에요. 이 정보를 끌고 와서 래핑을 해 줘요. 이게 ORM이라고 하는데, 파이썬에 알코올인가? 정확하게 기억이 안 나는데 아무튼 그런 파이썬에 쓰는 게 있더라고요. 아, 알케미. 그거하고 유사하다고 보시면 되고, 그거와는 다르게 얘는 비주얼로 직접 확인이 가능하고, 솔직히 엔티티 프레임워크만 놓고 설명을 드려도 한 시간 넘거든요. 아무튼 쓰시면 많은 도움이 될 것 같아요.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
