[게임과 법] ‘프리서버’ 왜 만들면 안 되는 건가요?

안녕하세요 게임과 법 칼럼의 OOO입니다.

저는 출장이나 여행이 없는 주에는 보통 매주 일요일 저녁부터 밤 사이에 ‘게임과 법’ 원고를 작성하고 자정을 조금 넘긴 월요일 새벽 무렵 TIG에 초고를 넘겨 드립니다. 저는 지금 막 이세돌 9단이 알파고를 상대로 3연패 끝에 첫 승을 거두었다는 기사를 보고 월요일 업무를 준비하면서 원고 또한 작성하기 시작하는 중입니다.

과거에는 오직 인간만이 할 수 있다고 생각했던 일들이 이제는 빅데이터와 신경망을 이용한 계산능력의 발전으로 인해 인공지능을 통해서도 가능해지는 변화를 볼 수 있는 시대에 살고 있습니다. 어쩌면 제가 주제만 정하면 저의 문체를 저보다 더 잘 알고 있는 컴퓨터가 ‘게임과 법’ 원고를 자동으로 만들어내는 시대가 곧 도래할지도 모를 일입니다. 그 때가 되면 아무도 공들여 글을 쓰지는 않게 될지도 모르겠다는 불안감이 함께 남아 있습니다.

만약 인공지능이 만들어낸 예술작품을 사람들이 향유하는 시대가 오게 된다면 그 저작권은 누구의 것이 될까요? 우리나라에서는 현행법상 권리의 주체가 될 수 있는 것은 인(人), 사람과 법인 뿐이므로, 형식적으로 생각해보면 해당 인공지능을 개발하거나 운영하는 사람 혹은 법인이 그 권리를 갖게 될 것이라 생각됩니다.

그러나 한번 더 고민해보아야 할 것은 인공지능이 만들어낸 작품이 과연 저작권법에 의한 보호를 받을 수 있는 것인지에 대한 검토가 선행되어야 한다는 점입니다.

저작권법 제2조 제1호는 저작물을 ‘인간의 사상 또는 감정을 표현한 창작물’로 보고 있으므로 인공지능이 인간의 구체적인 지시 없이 무언가를 ‘스스로’ ‘창작’해내는 시대가 도래한다면 법의 개정 없이 저작권을 인정받을 수 있을지는 의문입니다. 갑자기 재판을 통해 인간됨을 인정받고 싶은 로봇의 이야기를 다룬 영화 <바이센테니얼 맨>이 생각나네요.

어쨌든 재미있는 점은 사이버펑크 공상과학 영화 시나리오에서나 고민할 것만 같았던 인공지능에 대한 법률적 관점에서의 논의와 검토가 이미 시작되는 시대에 살고 있다는 것이 아닐까 합니다. 

■ 지난 연재 - 프리서버의 전체적​ 구조

지난 연재에서 우리는 프리서버가 어떤 과정을 통해 제작되는지를 살펴봤습니다.

간단히 요약하면, 

① 패킷 스니핑 등을 통해 정상적인 게임 서비스에서 서버와 클라이언트가 주고받는 메시지에 대한 정보를 빼내는 단계, ②메시지 정보를 이용해 직접 또는 다른 경로로 입수한 소스코드를 이용해 서버를 제작하는 단계, ③ 클라이언트를 변조하여 제작된 서버에 접속하도록 하는 단계, 회원을 모집하고 웹사이트를 만들어 클라이언트를 배포하고 서비스를 하는 단계로 진행이 된다는 것을 알 수 있었죠.

지난 연재에서 프리서버에 대한 법적 문제를 고찰하진 않았기 때문에 TIG 독자 여러분께서 남겨 주신 많은 질문과 자체적인 답변들을 댓글을 통해 볼 수 있었습니다. TIG 독자 여러분께서 구체적인 내용까지는 잘 모르시더라도 사안에 대해 올바른 답이 무엇인지는 어느 정도 감으로 알고 계신 듯 했습니다. 이 ‘감으로’ 아는 것도 아직까지는 인공지능이 갖지 못한 인간의 능력이죠. ^^;

해당 질문과 답변을 읽어보고 이번 연재를 준비하면서 든 생각은, 지난 연재에서 설명한 전체 구조를 따라가 보면서 TIG 독자 여러분과 제가 가지고 있는 프리서버에 대한 궁금함을 질문하고 답해 본다면 단순히 법리적인 해석을 나열하는 것 보다 더 잘 읽힐 수 있지 않을까 하는 것이었습니다. ‘게임과 법’은 본래 게임에 대한 법적 논의를 쉽게 전달해드리려는 의도로 시작된 연재였으니 말이죠.

자, 그럼 프리서버에 대한 질문과 답변, 이제 시작해 보겠습니다.  

■ 프리서버 - 서버의 제작과 관련한 문제들

Q. 프리서버 중 서버는 원작자의 도움 없이 순수하게 개발자들의 노력으로 만들어지는 것인데도 법적으로 문제가 되나요?

프리서버 서비스에서 ‘프리서버’ 그 자체, 즉 서버 프로그램은 역공학(Reverse Engineering, 리버스 엔지니어링)의 산물입니다. 이것은 온라인게임의 서비스 구조상 지극히 당연한 결과입니다. 이용자들이 다운로드하는 형태로 무료로 배포되는 클라이언트 프로그램과는 달리, 개발사가 그 통제권을 쥐고 있는 서버 프로그램에 대해 일반 이용자들이 직접 설치할 일은 전혀 없고, 하다못해 바이너리 코드의 일부라도 들여다 볼 기회는 거의 없기 때문입니다.

그런데 저작권 침해를 판단하는 요건은 ‘의거성’과 ‘실질적 유사성’이므로, 전혀 원작에 근거하지 않고 만든 프리서버 서버 프로그램이 법적으로 문제가 되는지에 대해서는 논란이 있을 수 있습니다. 지난 연재에서도 말씀 드렸다시피 프리서버의 서버 프로그램 그 자체는 똑똑한 해커들이 오랜 시간에 걸쳐 패킷 스니핑을 통해 알아낸 정보를 이용해 만들어지는 것이라서요.

잠깐, 프리서버가 전혀 원작에 근거하지 않고 만든 프로그램이라고요? 외부에서 정상적인 서버의 동작을 관찰해 제작되는 프리서버가 의거성이 없다는 것에 대해 의문을 가지시는 분들도 있을 것입니다. 그러나 프리서버는 정식 서버의 기능을 모방한 것이지, 표현을 모방한 것이 아니라는 것을 참고하시기 바랍니다(이런 면에서는 외국의 용어 중 ‘에뮬레이션 서버’가 잘 맞는 표현인 것 같습니다). 

프리서버가 정식 서버의 소스코드를 조금도 참조하지 않고 온전히 개발자들의 노력으로만 제작됐다면 서버 부분에 ‘한해서는’ 저작권 침해의 이슈에서 어느 정도 자유로울 수 있습니다. 그러나 저작권 침해에만 해당이 되지 않을 뿐 불법이 아닌 것은 아닙니다(정식 서버의 소스코드를 참조한 경우는 뒤에서 다시 말씀 드리겠습니다).

통상 일반적인 온라인게임 서버에서 서버와 클라이언트가 주고받는 메시지들은 그 내용과 구조가 외부에 노출되면 프리서버의 제작에 사용될 수도 있지만 핵툴의 개발 등에도 악용될 수 있습니다. 개발사들은 이 메시지의 코드와 내용(메시지에 따라오는 파라미터 등)을 감추기 위해 노력을 기울입니다. 메시지를 암호화하는 등의 방법으로요.

따라서 일반적인 온라인게임에서 사용되는 서버와 클라이언트간의 메시지에 대한 약속(‘프로토콜’이라 불리기도 하고, 개발 때 헤더 파일이나 라이브러리의 형태로 서버와 클라이언트 간에 공통적으로 쓰이는 게임서버와 클라이언트 사이의 통신규약)의 내용은 개발사나 퍼블리셔의 ‘영업비밀’이 됩니다. 영업비밀의 요건인 비공지성, 경제적 유용성, 비밀관리성이 모두 인정될 가능성이 높기 때문이죠.

그래서, 패킷스니핑을 통해 온라인게임 정식 서버의 서버와 클라이언트가 주고 받는 메시지를 열어 보고 이를 프리서버의 제작에 사용하는 것은 영업비밀 침해행위에 해당하게 됩니다. 

게다가 패킷스니핑은 그 행위가 어떻게 이루어지느냐에 따라 허용된 접근권한을 넘는 경우 정보통신망 이용촉진 및 정보보호 등에 관한 법률에서 금지하는 정보통신망 침해행위에 해당할 수 있습니다. 만약 서버 제작 행위나 서버 제작을 위한 패킷스니핑 작업이 해외에서 이루어지는 경우 같은 법에 규정된 ‘중요정보의 국외유출’에 해당할 수도 있게 됩니다.

(다만 ‘중요정보의 국외유출’의 경우는 정부의 조치가 가능하다는 점에 대한 규정이라 해당 법상의 특별한 처벌 규정은 아직 없습니다, 정보통신망 침해행위는 형사처벌 조항이 있고요)

Q.​ 인터넷에서 떠도는 특정 게임의 서버 코드를 다운받아 프리서버의 서버를 만들었습니다. 제가 받은 소스코드는 어차피 누구나 다 받아볼 수 있는 코드를 이용한 것인데 그게 문제가 될까요?

물론 저작권에 관해 이제는 아주 기본적인 상식이 되어 버린, ‘인터넷에 떠도는 자료들도 저작자의 허락이 없으면 함부로 사용할 수 없다’는 점만 알아도 기본적으로 문제가 된다는 감은 가질 수 있겠지만, 우리는 ‘게임과 법’을 이야기하고 있으니 조금 더 깊이 들어가 논의해 보도록 하죠.

이 문제는 다운받은 서버 코드가 무엇인지에 따라 논의의 구조가 미세하게 달라질 수 있습니다. ‘저작권법위반’, ‘저작권 침해’라는 결론에는 차이가 없고요.

사실 특정 게임의 서버 코드가 인터넷에서 떠 돌게 되는 경위는 여러 가지가 있을 것입니다. 게임 서비스 제공자가 서버 관리를 잘못해 게임 서버가 해킹을 당해서 게임 서버의 실행파일(이진 코드, binary code)가 유출됐을 수도 있고, 개발사의 개발자가 몰래 소스코드 그 자체를 빼돌린 경우도 있을 것입니다.

우리나라가 온라인게임의 역사를 써 나가던 시절과 비교하면 지금은 게임 제작에 대한 노하우도 많이 공개돼 있고, 여러가지 툴들이 나와 있는 관계로 게임 개발이 상대적으로 용이해진 감은 있습니다. 다만, 게임 서버를 개발하는 것 자체가 여전히 간단한 일은 아닙니다. 이런 점은 프리서버라고 해서 크게 다르지는 않죠.

그러나 타겟으로 하는 게임의 소스코드가 일부라도 있다면 프리서버의 개발은 훨씬 수월할 것이고, 운이 좋은 경우 해당 소스코드를 조금만 수정해도 안정적인 프리서버를 구축할 수도 있을 것이고요.

소스코드를 이용해 프리서버의 서버를 제작하는 것은 그 자체로 저작권자의 허락 없는 저작물의 복제에 해당합니다. 참고로 컴퓨터프로그램의 소스코드를 미국에서는 문언저작물(소설과 같이 글로 쓴 저작물)로 봅니다. 그 입장에 의하더라도 명백히 저작권 침해에 해당하고, 컴퓨터프로그램의 저작권에 대해 독립적인 별개 저작물로 보는 입장, 즉 우리나라 법이 취하는 입장에 의할 때에도 저작권 침해에 해당하게 됩니다.

그뿐만 아니라 정식 게임서버의 소스코드를 수정하는 것은 이론적으로는 저작권법상의 ‘프로그램코드역분석’에 해당하기도 합니다.

프로그램코드역분석은 2009년 4월 22일 개정 때 당시 존재하던 ‘컴퓨터프로그램 보호법’이 저작권법에 통합되면서 신설된 저작권법 제2조 제34호에 그 정의가 있습니다. 해당 규정은 "프로그램코드역분석"을 ‘독립적으로 창작된 컴퓨터프로그램저작물과 다른 컴퓨터프로그램과의 호환에 필요한 정보를 얻기 위해 컴퓨터프로그램저작물코드를 복제 또는 변환하는 것을 말한다’고 정하고 있습니다.

저작권법은 저작재산권자의 허락 없이 프로그램코드역분석을 할 수 있는 경우를 한정적으로 열거하고 있고, 프로그램코드역분석으로부터 얻은 정보를 대상 프로그램과 실질적으로 유사한 프로그램의 개발·제작·​판매에 이용할 수 없도록 하고 있습니다(저작권법 제101조의4). 나아가 그 범위를 벗어난 프로그램코드역분석을 위한 기술적보호조치의 해제 또한 금지하고 있습니다(동법 제104조의 2).

그러니 프리서버를 만들기 위해 정식 게임서버의 소스코드를 수정하는 것은 여러 이유로 저작권법 위반에 해당하게 되겠습니다. 

프리서버 제작에 잘 쓰이는 방법은 아닙니다만 원래 게임서버의 실행파일인 바이너리코드를 입수해 프리서버 구축에 활용하는 경우 바이너리코드로부터 원래 게임서버의 구조를 알아내는 작업 또한 역공학에 해당합니다.

이 때는 디컴파일(Decompile, 실행파일이나 목적파일을 다시 원래의 소스코드 형태로 되돌리는 과정) 등을 통해 구조를 파악하고, 서버의 변조를 시도하겠죠. 어떻게 보면 이 작업을 통해 소스코드를 파악할 수 있는 개발자들이 패킷스니핑을 통해 프리서버를 만드는 쪽 보다 더 실력이 좋은 쪽일 수도 있습니다. 

디컴파일된 소스코드는 기계어나 어셈블리어만큼은 아니지만, 원래의 소스코드를 그대로 재현하는 것이 아니라 자동으로 생성된 변수명 등은 사람이 읽기 그리 용이한 편이 아니어서 간단히 이해할 수 있는 것은 아니거든요.

이 경우에도 저작권법상의 ‘프로그램코드역분석’에 해당하게 되므로 문제가 될 수 있을 것입니다. 

사실 저작권법에 ‘프로그램코드역분석’이 입법된 과정을 보면 디컴파일 등을 통한 리버스엔지니어링을 더 염두에 둔 것임을 알 수 있고, 게임과 관련된 케이스는 아니지만 최근 하급심 판례에서도 유사한 사례에 해당 법령이 적용된 사례도 있습니다(2014. 1. 23. 서울중앙지방법원 선고 2013가합23162 저작권 침해금지 등 사건 참조). 

■ 프리서버 - 서버 제작과 관련한 소결론

이렇듯 프리서버는 서버를 제작하는 과정만으로도 원작자의 허락을 받지 못하였다면 법 위반에 해당할 소지가 상당합니다. 해당 조항들은 대부분 금지행위에 따른 형사처벌 조항이 함께 존재하고 있으므로 애초에 고의성이 쉽게 인정되는 프리서버 제작행위의 리스크도 매우 높다고 하겠습니다.

제 사견입니다만, 프리서버를 직접 제작할 수 있을 정도의 실력을 갖춘 개발자라면 상당한 실력을 갖춘 경우가 많으므로 굳이 프리서버 제작과 같은 ‘위험한 일’에 손을 댈 필요는 없다고 생각됩니다. 해외에서는 실제로 ‘컴퓨터천재’인 학생들이 프리서버를 만드는 경우가 많습니다.

서버 이야기만으로도 충분히 길어져 오늘은 이만 줄입니다.

클라이언트 변조에 대한 문제, 운영상의 문제 및 분쟁 절차와 관련한 이야기들은 다음 연재를 통해 말씀 드리도록 하겠습니다.

(본 칼럼은 필자 개인의 의견으로 TIG의 편집 방향과 일치하지 않을 수도 있습니다.)