지난 8~9일에 부산에서 개최된 ICON에서 온라인 게임 처음부터 끝까지 동적언어로 만들기를 발표하고 왔다. 여러 달 만에 다시 보니 더 하고 싶은 얘기들이 생겨서 슬라이드를 좀 수정했는데, 분량과 흐름 상 넣지 못했던 주제가 있어서 블로그 포스트로 정리해 본다.
스크립팅 환경을 고를 때는 언어 뿐만 아니라 런타임이 제공하는 기능이나 바인딩의 편의성, 각종 개발 도구들도 함께 고려해야 한다. 그것들이 모두 생산성에 영향을 미치기 때문이다. 어떤 기능은 언어의 기본 런타임에서 잘 지원하기도 하지만, 기본 런타임은 기초적인 API만 제공하고 필요한 기능을 만들든지 적절한 래퍼를 붙여야 할 수도 있다. 다른 환경을 깊게 경험해 보지 않아서 비교하기 어렵지만 루아는 확실히 이런 경향이 심하다. 그저 '된다더라' 로 끝나는 것이 아니라, 기능이 필요해졌을 때 도입 비용이 생길 수 있다. 처음부터 다 만들고 시작하지는 않더라도, 나중에 어느 정도의 비용이 필요할 지 예상해 두면 좋을 것이다.
이게 안 되면 범용 스크립팅 언어를 쓰는 의미가 없다. 수정한 내용을 실행해서 확인해보는 데 얼마나 걸리나? 스크립트가 복잡해지고 커지면 얼마나 느려지나? 스크립트를 수정했는데 호스트 언어를 재컴파일해야 하지는 않나? 재컴파일을 해야 한다면 그 범위는 얼마나 큰가?
스크립트의 로딩이 빠른 것만으로는 충분하지 않다. 게임 프로그램에서도 충분히 신경을 써야 한다. 단축키 한 번, 혹은 간단한 명령어로 스크립트를 다시 로드할 수 있으면 좋다. 게임 상태를 유지한 채로 변경된 부분만 적용할 수 있으면 좋지만 실제로는 그렇게 하기 쉽지 않다. 특히 스크립트를 넓은 범위에서 쓸 수록 더 그렇다.
언어 사이를 넘나드는 비용이 얼마나 싼가? 최소한 상호 함수 호출은 편하게 되어야 한다. 스크립트에 있는 자료구조를 호스트에서 생성하고 수정하고 탐색하는 기능, 호스트에 있는 객체를 스크립트에서 참조하는 기능도 필요하다.
루아는 환경 자체에서 아주 기초적인 기능만 제공하고, 사용이 썩 편하지 않다. 바인딩 라이브러리를 잘 골라야 한다. 아니면 열심히 잘 만들던가.
중요하다. 아주 중요하다. 이게 제대로 안 되면 빠른 이터레이션으로 버는 시간을 다 까먹는다.
루아 에러 핸들링 참고.
스크립트를 복잡하게 사용할 거라면 OOP는 필수다. 그리고 프로그램이 커지면 커질수록 컴파일 타임에 오타를 잡아주면 좋고, 적어도 정의 안 된 필드나 메소드에 접근하려고 하면 실행시간에 에러를 토해야 한다.
루아의 경우 언어 자체에서 OOP를 지원하지 않으니 별도의 라이브러리를 써야 한다. 구현체가 꽤 많이 있는데 특성이 조금씩 다르다. 그리고 컴파일 타임에 오타를 잡는 것이 라이브러리로는 불가능하다.
게임디자인에서 쓰는 어휘를 그대로 쓸 수 있다. 즉 도메인 주도 설계에서 말하는 UBIQUITOUS LANGUAGE를 실천하기 좋다. 게임디자이너는 물론이고, 영문으로 코딩하는 게 익숙한 프로그래머들에게도 상당한 이점을 제공한다. 스크립트가 복잡하든 간단하든 의미 있다.
루아라면 파서를 살짝 고쳐서 간단히 한글 식별자를 사용할 수 있다.
실행 속도는 빠를수록 좋고, 메모리는 적게 쓸수록 좋다. 이건 당연한 얘기다.
다만 다른 특징에 비해 성능 특성이 얼마나 중요할지를 생각하자. 어디에 어떻게 쓰느냐에 따라 느려도, 메모리를 많이 먹더라도 딱히 상관없을 수 있다.
서버에서 쓰려면 이걸 고려해야 한다. 한 프로세스에 VM을 여러 개 생성할 수 있는가? 여러 스레드에서 병행적으로 VM에 접근하려고 하면 어떻게 되나? 이런 것들을 처음부터 미리 파악해 두어야 한다.
프로그래머가 짜야 할 정도로 복잡한 코드라면 디버거가 필요하다. 에러 처리만으로는 문제를 해결하기 골치아픈 상황이 반드시 온다. 루아라면 Decoda 평가판을 써보자.
에디터는 비프로그래머도 사용한다는 점을 잊지 말자. 에디트플러스 정도로도 충분히 쓸만하지만, 프로젝트에서 사용하는 스크립팅 언어의 문법 파일이 기본 설치되지 않는다면 구해서 팀에 보급하도록 하자. 심지어 자체 개발 포맷인 경우 문법 파일이 없을 텐데, 비슷한 언어의 문법 파일을 한번 열어보자. 에디트플러스의 문법 파일은 확장성은 크지 않지만 아주 쉽게 만들 수 있다.
만약 DH처럼 스크립팅 언어를 넓게 적용하려면 게임 로직 프로그래머들이 그 언어를 능숙하게 쓸 수 있어야 하는데, 학습 곡선을 넘어가지 못하면 그냥 C++로 짜버리는 것보다 못할 수도 있다.
프로젝트나 조직의 성격에 따라서는 스크립팅 환경을 선택하거나 스크립팅 언어의 적용 범위를 결정하는 데 이 점을 심각하게 고려해야 할 수도 있다. 회사의 성공과 개발자의 성공이 일치한다는 비전을 제공하지 못한다면 그냥 업계의 다른 프로젝트에서 하는 방법을 그대로 따라가는 게 답일지도 모른다.
개발자의 반발을 고려하지 않더라도, 널리 쓰이는 환경은 그 자체로 장점이 있다. 많이 쓰이다 보니 버그가 빨리 발견되고, 일찍 고쳐진다. 문제에 부딪치면 검색해서 답을 얻을 가능성이 높다.
고려할 사항들을 그다지 부연 설명을 하지 않고 나열했는데, 스크립팅 언어를 가지고 무엇을 만들려고 하는지에 따라 각 사항들의 무게가 달라진다. 이를테면 제한된 용도로 복잡하지 않은 것을 만든다면 간단한 에러 처리 루틴만으로도 충분히 버틸 수 있겠지만, 데스크탑 히어로즈처럼 게임 로직을 통째로 스크립팅 언어로 만든다는 결정을 내린다면 제대로 된 디버거가 필요하다.