[소고] 게임 보안: 허들 넘기…

사용자들은 언제 게임보안 제품을 느낄까? 해킹툴을 잘 잡아서 게임 내 해킹이 줄었을 때? 아니다. 사실 일반 게이머들은 게임보안 제품이 해킹툴을 잡는다는 사실을 모르는 경우가 대부분이다. 그들이 게임보안 제품을 느끼는 대표적인 순간은 바로 잘되던 게임이 안되기 시작하는 순간이다. 게임보안 제품이 게임 구동을 방해하는 허들이 되는 그 지점인 것이다. 이 순간이 되면 모든 게이머들이 안티치트 솔루션 이름에 대해서 알게된다. 더불어 그 게임이 진짜 인기있는 게임이라면 네이버 실시간 검색어 1위에서 10위까지 휩쓰는 기염을 토하기도 한다. 이 모든 일들과 함께 안티치트 솔루션에 대한 욕과 비방이 범람한다. 한마디로 아찔한 순간이다.

XIGNCODE라는 제품을 처음 만들 때 사실 별 생각이 없었다. ㅋㅋ~ 후에 제품의 틀을 잡으면서는 크게 두 가지 다짐을 했다. 하나는 아이러니하게도 진짜 해킹툴을 잡는 제대로 된 솔루션을 만들자는 생각이었고, 다른 하나는 절대로 게임의 허들이 되는 제품을 만들지는 말자는 생각이었다. 하지만 시간이 흘렀고, 우리 제품도 게임에 속속 탑재되기 시작했고, 해킹툴과 전쟁도 뻘짓나게 많이 하면서 자연스럽게 허들이 되는 순간도 생기게 됐다. 그렇게 장애물은 되지 말자고 했는데 애물단지가 되는 순간이 발생한 것이다. 그럴때면 나 또한 똑같은 한명의 게이머로서 한없이 죄송함을 느끼곤 한다. 그리곤 또 다짐한다. 정신차리고 똑바로 만들자고 말이다.

그렇다면 왜 그렇게 모든 게임보안 제품은 하나같이 다 허들이 되는 것일까? 또 그 허들은 왜 생기는 것일까? 피할 순 없는 것일까? 또 반대로 게이머 입장에서는 조금이라도 허들을 피하기 위해서는 어떤 점들에 주의해야 할까? 역설적이게도 게임보안 제품이 허들이 되는 이유는 그들에게 봉착한 허들을 제대로 넘지 못했기 때문이다. 여기서는 게임보안 제품 개발을 하면서 겪게 되는 허들에 대해서 살펴보고 작게나마 앞선 질문들에 대한 해답을 찾아보는 시간을 가져보도록 하자.

#0 운영체제 허들

일단 게임보안 제품에게는 운영체제 하나가 거대한 산맥으로 다가온다. 왜 그럴까? 게임도 똑같이 다양한 운영체제 위에서 구동되는 프로그램이고 게임보안 프로그램도 그럴 뿐인데 왜 게임보안 제품에게는 운영체제 자체가 허들이 되는 것일까? 그 이유는 게임보안 제품의 특성상 운영체제에서 공개하지 않은 다양한 기능들을 사용하기 때문이다. 왜? 도대체 왜? 많은 이유가 있는데 주된 이유만 들어보자면 하나는 해킹툴이 그런 기능을 사용하기 때문에 탐지하기 위해서 부득이하게 사용하는 경우고, 다른 하나는 해킹툴로부터 자신을 보호하기 위한 목적으로 사용한다. 이렇게 공개되지 않은 부분들을 사용하는 것이 호환성을 떨어뜨리는 대표적인 요인이다. 여러분이 생각하는 그 모든 호환성 이슈는 다 이 하나의 사실에 기인한다고 할 수 있다. 그렇다면 이건 어떻게 해결해야 할까? 테스트만 열심히 한다고 해결될까? 물론 문제가 그렇게 쉽진 않다.

XIGNCODE는 기본적으로 Windows 2000 SP4, Windows XP SP2, Windows XP SP3, Windows Vista SP1, Windows Vista SP2, Windows 7 RTM, Windows 7 SP1, Windows 8 CP에서 게임 구동 테스트를 거친다. 우와 장난 아니다. 그런데 여기서 놀라면 안된다. 저 모든 운영체제를 한중일영으로 테스트 한다. 보면 알겠지만 서팩별로도 많이 사용되는 것들은 분리해서 테스트 한다. 그 이유가 서팩별로도 많은 차이를 가지기 때문이다. 이런 복잡한 테스트를 몇 시간씩 하고, 일주일 내내하고, 또 하고, 또 하고, 제품 릴리즈를 함에도 문제는 발생한다. 왜 그럴까?

그 이유는 바로 우리가 기대고 있는 언덕이 그만큼 부실하기 때문이다. 공개되지 않은 부분이라는 그 사소하지만 절대 사소하지 않은 사실 때문이다. 즉, 오전까지는 잘되다가 오후에는 안되도 전혀 이상할 이유가 없는 단서들에 제품이 기반하고 있기 때문이다. 우리가 이 사실에 대해서 어떤 불평을 한다면 운영체제를 만든 MS에서는 이렇게 대답할 것이다. “야, 그건 우리가 그래서 공개안한거야. 니네들 쓰라고 만든건 아니거든.” 이라고 말이다. 어쨌든 그래서 테스트 만으로는 이 허들을 넘기가 쉽지 않다. 우리가 관찰한 100시간 동안은 운영체제가 A라는 방식으로 동작했겠지만 그건 단지 우리가 관찰한 100시간 동안만 그랬기 때문일 수도 있기 때문이다.

이 허들을 넘기 위해서는 테스트 보다는 운영체제에 대해서 보다 더 정확하게 알 수 있는 방법이 필요하다. 즉, 100시간의 관찰보다는 실제로 그렇게 돼 있는지 안 돼 있는지를 판단할 수 있어야 한다는 말이다. 그래서 운영체제를 직접 리버싱 하는 것이 더 도움이 된다. 맞다. 그런데 리버싱도 한계가 있다. 그래서 이 허들을 넘는 궁극의 도구는 MS 소스 코드 라이선싱 프로그램이다. 바로 그 놈이 답지고 그 놈이 갑이기 때문이다.

이 허들과 관련해서 사용자가 겪게 되는 또 다른 불편 중에 하나는 다양한 환경에서 게임을 즐기지 못한다는 요소다. 우리 제품도 종종 불만사항으로 올라오는 내용 중에 하나가 와인에서 실행되지 않는다는 것들이다. 이럴때면 늘 우리는 갈등한다. 사실 와인에서 실행되도록 만들어주는 것은 전혀 어려울 게 없다. (<== 어려울 수도 있다 ㅋㅋ) 그런데 문제는 와인을 통해서 해킹을 한다면 문제가 복잡해지기 시작한다. 물론 나는 선량한 리눅서가 와인을 통해서 게임을 즐기기 위함이지 절대 해킹을하기 위해서 리눅스를 깔고 와인을 올려서 게임을 구동하리라곤 생각하지 않는다. 그래도 만에 하나의 경우 그래 버린다면 문제가 될 수도 있다는 것이다. 어쨌든 우리는 이 옵션에 대해서 심각하게 고민하고 있다. 벤더 정책에 따라서 옵션으로 와인 호환성을 제공할까도 고려중이다.

#1 시스템 허들

다음으로 우리가 넘어야 할 허들은 게임 시스템이다. 이 또한 정말 다양한 시스템들이 있다. 이제는 우리가 시중에서 구하기도 힘든 시스템으로 게임을 하는 유저들이 적지 않다. 특히 오래된 게임들은 더 그렇다. 이 부분은 사실 테스트도 어렵다. 우리는 다양한 환경이라고 테스트 시스템 수십대를 구비해 놓지만 정작 유저들이 사용하는 시스템에 비한다면 그 수십대는 샘플 수량조차 되지 못한다. 그만큼 다양한 환경이 존재한다. 그리고 그 다양한 시스템을 게이머들은 우리가 상상도 못한 방식으로 변형시켜 사용한다.

여튼 이런 다양한 시스템이 문제가 되는 주된 요소들은 시스템 버그에 대한 패치를 사용자가 하지 않는다는 점이다. 대표적인 예를 들어보자면 AMD CPU의 Cool’n Quiet 기능 버그가 있다. 해당 기능을 사용하면 특정 운영체제에서는 시간을 측정하는 함수가 비정상적으로 동작하는 문제가 있다. 이건 패치를 해야 하는데 사용자들이 그러한 패치를 알리가 만무하고 또 그 패치를 하지 않더라도 일반 프로그램 사용에는 문제가 없기 때문에 하지 않는 경우가 많다.

하지만 우리에게는 그러한 것들이 굉장히 크리티컬하게 다가온다. 게이머가 해킹툴을 설치해서 시간이 이상한지 아니면 패치를 안해서 이상한지를 구분해야 하기 때문이다. 그래서 온갖 꼼수들이 동원된다. 당연히 그 꼼수들로 인해서 프로그램의 호환성은 더 떨어지고, 테스트는 더 힘들어지고, 제품은 더 쉽게 부서진다.

#2 오진 허들

여기부터는 이제 우리가 우리 발목을 잡기 시작하는 허들이다. 해킹툴 차단 방식은 크게 나누자면 패턴 방식과 로직 방식으로 나눌 수 있다. 패턴 방식은 사람 지문으로 누군가를 구분하는 것처럼 해킹툴의 특정 시그니처로 해당 해킹툴을 차단하는 방식을 말한다. 지문이 데이터베이스에 없다면 인식이 안되는 것처럼 이 경우도 수집이 안 된 해킹툴에 대해서는 차단을 하지 못한다는 문제가 있다. 그래서 도입된 개념이 로직 방식이다. 이건 이렇게 행동하는 사람은 A 밖에는 없다고 우리가 추론하는 것과 똑같은 원리로 해킹툴을 진단한다. 즉, 어떤 프로그램이 a, b, c라는 동작을 하면 해킹툴로 간주하는 것이다. 당연히 우리가 인식하는 세계처럼 여기에는 맹점이 생길 수 밖에 없다. 그 사람이 아닌데, 내지는 해킹툴이 아닌데도 a, b, c라고 동작을 하는 경우가 있기 때문이다. 이게 우리 발목을 잡는다. 물론 대놓고 난 정상 프로그램이라고 말하면 문제는 한결 가벼워 지는데 그 정상 프로그램이 각종 꼼수 꼼수에 꼼수를 사용해서 마치 해킹툴처럼 판단하기 어렵게 만든 경우에는 허용 처리가 안드로메다로 가버린다.

그럼 어떤 프로그램이 주로 오진 케이스에 말려들까? 가장 대표적인 프로그램들은 아이러니하게도 게임 유틸리티다. 게임 동영상 촬영 도구라던지, 게임 내에서 채팅 기능을 구현한 메신저 프로그램이 대표적이다. 이들 프로그램은 게임과 동시에 동작한다는 것이 특징인 것들이지만 내부 구현 방식은 해킹툴의 그것과 상당히 유사하기 때문이다. 또 이 프로그램들이 진화하면서 이 프로그램들 나름대로 탐지를 회피하기 위해서 각종 테크닉을 사용하기 때문에 요즘은 허용 처리도 참 쉽지 않은 경우가 많다.

그 다음 대표적인 유틸리티 들로는 가상화 유틸리티들 SandBox, Vmware, Virtual PC부터 네트워크 프록시 도구들이 있다. 이런 프로그램들은 해킹툴과 동작 방식이 유사히진 않지만 벤더 요청으로 차단하는 경우가 있다. 그렇게 차단된 것임에도 사용자 입장에서는 정상 프로그램을 오진한다고 생각하기도 한다.

벤더 정책으로 누명을 쓰는 또 하나의 대표적인 프로그램으로는 또 JoyToKey가 있다. 이름에서 볼 수 있듯이 조이스틱을 컴퓨터에서 매핑해서 사용할 수 있게 해주고, 또는 매크로 기능을 사용할 수 있게 해주는 프로그램이다. 그런데 이게 왜 문제인고 하면 게임 벤더에 따라서 어떤 쪽은 이 프로그램을 허용처리하고 어떤 곳은 차단 처리를 하기 때문이다. 유저들의 반응은 딱 갈리게 된다. 저걸 해킹툴로 많이 사용하는 게임인데 벤더에서 허용을 해주면 어떤 반응이냐면 우와 XIGNCODE는 쓰레기다. JoyToKey도 차단이 안된다. 이런 반응들이 올라온다. 사실 우리가 못 막아서 안 막는 경우는 아님에도 말이다. 또 반대로 이 프로그램을 별로 해킹툴로 사용하지도 않는 게임인데 벤더 정책상 차단하게 되면 와 이런 정상 프로그램을 왜 차단하냐. 미친거 아니냐. 라는 반응들이 올라온다. 마찬가지로 우리가 차단하고 싶어서 차단한건 아님에도 말이다. 즉, 가끔은 중간에 끼여서 욕을 먹는 경우에는 조금 억울한 생각이 들 때도 있다.

#3 충돌 허들

충돌은 정말 장난아닌 문제다. 게임보안 제품은 그 모든 것들과 충돌을 일으키지만 특히 안티바이러스 이슈가 많다. 가장 최근에 겪었던 충돌 문제를 한 번 살펴보자. 이 문제는 안티바이러스의 코드 에뮬레이션 기능과의 충돌이었다. 처음 보고가 들어온 제품은 AVAST였다. 이런 문제의 99.8971234%는 서로 같은 포인트를 후킹하거나 후킹하려고 하는 것이 문제이기 때문에 그 체크를 먼저 했다. 어라? 근데 깨끗하다. 아무 문제가 없어 보였다. 근데 게임이 크래시가 난다. 그래서 AVAST의 이 옵션, 저 옵션 조정하면서 왜 크래시가 나는지를 관찰했다. 그랬더니 아니나 다를까 AVAST의 코드 에뮬레이션 기능을 켜면 크래시가 발생하는 것이었다. 게임이!!! 도대체 왜? 아마 우리의 코드가 그 코드 에뮬레이터가 이해하기는 힘들었는지도 모르겠다. 여튼 QA팀에게 AVAST에 충돌 보고를 하라고 했다. 내가 보기에는 AVAST에서 봐야 할 문제였기 때문이었다. 그러고 끝일까? 당연히 아니다. 게이머한테 이건 AVAST 버그니 코드 에뮬레이션 끄고 게임하세요. 이렇게 말할수는 없기 때문이다. 그래서 우리는 그 코드를 AVAST가 켜진 경우에는 AVAST가 딱 이해할만한 수준으로 낮춰서 동작시키도록 했다.

이 문제가 억울한 이유는 사실 이런 경우는 우리쪽 버그가 아니다. AVAST 코드 에뮬레이터 버그지 않겠는가? 결국 AVAST에서 해당 기능을 고쳤다는 보고를 해왔다. 하지만 게임사나 유저들은 우리 잘못으로 오인하는 경우가 많다. 안타까운 현실이다. AVAST만 거론해서 그렇는데 동일한 이슈를 겪은 다른 3종의 백신이 더 있었다. MS SE, ESET Smart Security, McAfee였다. 물론 다른 벤더엔 귀찮아서 오류 보고도 하지 않았다.

그렇다면 우리는 왜 AVAST 코드 에뮬레이터도 이해하지 못하는 그런 코드를 써야 했을까? 첨부터 그냥 다 평이한 걸 사용했으면 문제가 없지 않을까라고 생각할 수도 있겠다. 근데 이게 딜레마다. 우리 제품은 해커로부터 우리 코드를 보호해야 한다. 또 해커가 우리 코드를 이해하는 것을 막아야 한다. 그러니 당연히 복잡하게 꼬아 놓을 수 밖에는 없는 것이다. 그게 경쟁력이니 포기할 수가 없는 것이다. 충돌을 감수하더라도 그 코드를 계속 써야만 하는 이유다.

그리고 이런 충돌 이슈는 충돌을 넘어서 좀 더 복잡한 문제들을 야기 시킨다. 충돌때문에 작성한 특수 코드가 우리 발목을 잡는 경우가 생기는 것이다. 해커가 만약 백신 때문에 작성한 특수한 코드에 대한 사실을 눈치채면 그걸 이용해 먹을 수 있다는 말이다. 그런 방법을 공유한다고 사용자들이 백신을 설치할까라고 생각할 수 있다. 근데 뻥안치고 방법만 있다면 게임핵을 사용하고 싶은 모든 사용자는 어디서 구하든 다 구해서 그 백신을 설치한다. 그 정도로 게임핵의 유혹은 강하기 때문이다. 실제로 예전에 중국에서 KAV를 이용해서 해킹 시도를 하는 사례가 있었다. 그래서 귀찮더라도 보고하고 무조건 백신을 고쳐야 한다.

여기까지 생각하면 이제 게임보안 1-2년 정도 해본 사람이라고 할 수 있겠다. 좀 더 해보면 알겠지만 저거 고쳤다고 원래 코드를 쓸 순 없다. 세상이 그렇게 순수하진 않은 탓이다. 백신 업체가 고쳤다고 그걸 업데이트하는 유저도 있지만 하지 않는 유저도 부지기수기 때문이다. 우리가 백신 업체가 고쳤다는 소리만 듣고 순진하게 원래 코드로 원복시켰다가는 다시 똑같은 문제가 생긴다는 소리만 듣는다. 모든 사용자는 업데이트를 하지 않는다고 생각하는게 속편하다. 그래서 그 특수 코드를 이용하는 놈들이 나타나면 다시 그 특수 코드에 대한 특수 코드를 만들어야 한다. 이렇게 소스 코드는 걸레가 되고 로직은 38.7차원 어딘가에 위치하게 된다.

#4 버그 허들

이거야말로 우리가 피해야 할 허들이다. 그런데 가장 많으면서 제일 피하기 힘든 허들이다. 누구 말처럼 이건 명백히 프로그래머의 실수다. 그런데 버그라는 말을 만들어서 책임 회피를 하는 것처럼 보일 수 있다. 어쨌든 맞다. 명백한 우리 실수, 잘못이다. 인정한다.

그럼에도 변명을 좀 대보자면 이렇다. 우선 게임보안 제품은 생각보다 빌드가 굉장히 많이 있다. 왜냐하면 해킹툴이 자주 나오기 때문에 그 취약점도 고쳐야 하고 새로운 방식에 대응도 해야 하기 때문이다. 심한 시기에는 풀빌드가 일주일에 두세 번씩 되기도 한다. 이런 경우에는 머 QA팀은 초죽음이 된다고 보면 된다. 또한 이러한 풀빌드가 전혀 계획되지 않은 상황에서 발생하기도 한다. 왜? 해킹툴을 막아야 하기 때문이다. 자잘한 빌드는 말도 못 할 정도로 많다. 하루 밤에 24번 모듈을 빌드하고 업데이트 한 적도 있었다. 당연히 그 해킹툴 제작자는 그 다음주에 학교로 돌아갔다. 그래서 때로는 이런 어처구니 없는 실수들도 자주 발생한다.

물론 당연하다. 똑똑하다면, 진짜 실력이 있다면 빨리 만들면서도 잘 만들어야 하고, 또 문제가 없어야 한다. 우리가 항상 이런 버그 앞에서 한없이 초라해지고 숙연해지는 이유이기도 하다. 그럼 우린 어떻게 해야 하는가? 프랙티스, 프랙티스, 프랙티스… practice makes perfect를 외치며 항상 연습하는 수 밖에는 없다. 빨리 고치고, 급하게 고치고, 막 바꾸면서도 실수하지 않도록 말이다. 라이브는 말 그대로 전쟁터다.

#5 필요악???

문제가 한두 가지가 아니다. 한 게임보안 프로그램은 국내 대형 MMORPG에 탑재됐다가 북미에서는 유저들 원성으로 제거되는 굴욕을 겪기도 했었다. 사람들은 늘 말한다. 100% 막지도 못하고, 그렇다고 문제가 0%인 것도 아닌데 왜 필요한가라고 말이다.

하지만 정작 실제 내용을 살펴보면 그런 이야기를 하기는 힘들다. 왜냐하면 게임보안 솔루션을 사용해서 유통되는 유료핵툴 한두 개만 차단하더라도 연간 구독료 값어치는 하고도 남기 때문이다. 특히 MMORPG같이 컨텐츠가 생명인 게임은 더 그렇다. 아래는 한 게임에 오토 유료핵이 나온 경우의 상황을 보여주고 있다. 여러분이 보는 그대로 전체 게이머의 60%가 그 핵툴을 사용하는 시간대도 있다. 이 정도로 말도 안 되게 온라인 게임의 핵은 심하고, 또 게임보안 제품은 여러분이 생각하는 것보다 훨씬 더 쓸모있다. 저 오토들이 컨텐츠 소모에 들어갔다면 어땠을까? 단순히 유저들이 느끼는 불균형의 문제가 아니다. 비싼 돈주고 개발한 컨텐츠가 유저가 아닌 기계에 의해서 순식간에 소모되는 말도 안 되는 일이 벌어질 수 있는 것이다.

해킹툴로 서비스되는 게임을 내려본 게임사는 게임보안 솔루션의 필요성에 대해서 절절하게 실감한다. 몇 백억이 투입된 게임도 해킹으로 난장돼서 서비스가 불가능할 수도 있기 때문이다. 여러분이 생각하는 것 이상으로 반드시 필요하고, 또 좋은 솔루션이 필요하다. 그래야 문제는 낮추고, 탐지율은 높아지기 때문이다.

#6 허들을 넘어서

참 문제도 많고 탈도 많다. 프로그래머는 어떨까? 이런 수많은 허들을 마주하면 게임보안 프로그래머는 위축될 수 밖에 없다. 공격적인 탐지 방식보다는 느슨한 탐지 방식을 사용할 수 밖에 없다. 좀 더 복잡한 숨김 방식보다는 노멀한 방식을 사용할 수 밖에 없다. 자신감이 없어지기 때문이다. 하지만 이런 것들에 위축돼서 쪼는 순간 게임보안 프로그래머로써의 생명은 끝이고, 그 제품 생명도 끝이다. 왜냐하면 그런 자신감이 없어지는 순간 제품과 코드의 경쟁력은 순식간에 사라지기 때문이다. 진짜 프로라면 이 모든 허들을 웃으면서 사뿐히 뛰어넘으면서도 위험한 방법을 과감하게 선택하는 강단이 필요하다.

게이머에게 유쾌한 느낌을 주는 게임보안 솔루션이고 싶다. 물론 쉽진 않다.

적어도 XIGNCODE를 사용하는 게임에게 짐이고 싶진 않다. 또 적어도 XIGNCODE가 탑재된 게임을 하는 게이머들에겐 공정하다는 느낌을 주고 싶다. XIGNCODE 팀은 매 순간 그 시소의 양 극단에서 갈등하고 고민한다. 지금까지 우리는 항상 가장 위험한 방법에 과감하게 도전했고, 그걸 제일 안전하게 구현했다. 또 실수를 최소화하기 위해서 매일 연습했다. 그것만이 우리 제품을 사용하는 모든 이들에게 신뢰를 줄 수 있는 방법이고, 또 우리가 이 수많은 허들을 뛰어넘은 방법이기 때문이다.

새로운 기능이 잔뜩 준비됐다. QA팀은 긴장한다. 그 쏘 쿨한 기능들은 늘 그랬듯이 허들을 하나씩 넘을 것이고, 그걸 다 넘으면 게임에 탑재돼서 새로운 핵들에 대한 대응력을 강화해 나갈 것이다. 이렇게 우리는 매일 조금씩 전진한다. 제품도, 팀도, 회사도 말이다.