1층짜리 집을 지을줄 아는 건축업자가 있다고 하자.


그 건축업자에게 1층짜리 집을 100채 지으라고 하면 시간은 걸리겠지만 그 일을 해낼 수 있을 것이다.

또한, 100채가 지어지는데 총 얼마의 시간과 비용이 드는지 대략적인 추산도 할 수 있을 것이고,

내부적인 최적화를 통해서 시간과 비용을 단축할 수도 있을 것이다.


하지만, 그 업자에게 100층짜리 건물을 한 채 지으라고 한다면 얘기는 전혀 달라진다.




소프트웨어 개발도 마찬가지다.


자료구조나 알고리즘등 프로그램의 기초를 배워 간단한 프로그램만 짜본 사람에게 대규모 소프트웨어

개발을 시킬 경우에는 거의 대부분의 경우 시간과 비용을 정확하게 추산할 수 없으며, 개발 성공여부

자체도 불투명하다.



100층짜리 건물을 짓는것과 1층짜리 건물을 100채 짓는 것 사이에는 어떠한 차이가 있는 것일까?

마찬가지로 간단한 프로그램을 짜는 것과 대규모 소프트웨어를 짜는 것에는 어떠한 차이가 있는 것일까?

전자의 질문에 대한 답을 건축공학 토목공학에서 찾는 것이라면, 후자에 대한 답을 찾는 것이 소프트웨어 공학이 하는 일이다.


과거의 게임은 대규모 소프트웨어라기보다는 소규모 소프트웨어에 속했다. 한명 내지는 몇명의 프로그래머가

프로젝트를 처음부터 끝까지 완성하는 것이 일반적이었고, 개발기간도 오래 걸리는 경우는 많지 않았다.


하지만, 게임이 인터넷과 만나고, 3D 기술이 보편화되면서 점점 모든 것이 변해갔다.

오늘날 MMORPG 서비스 하나를 구축하는 데에는 다음과 같은 다양한 이종의 기술들의 숙달과 조합을

필요로 한다

- DirectX 나 OpenGL 등을 통한 3D 장치 처리
- 3dsMAX 나 Maya 등의 디지탈 컨텐츠 제작툴로 만든 아트 데이타의 처리와 실시간 표현
- 자체적인 GUI 윈도우 시스템
- MP3 나 OGG, WAV 파일로 구성된 효과음과 배경음악의 연주
- 부가적인 월드의 구성을 위한 자체적인 레벨 에디터
- Lua 나 Python 등의 AI 스크립팅을 위한 별도의 임베딩 언어 운용
- 3D 상에서의 길찾기 처리를 위한 라이브러리와 네비게이션 메시 제작/임포팅
- 비정형적 데이타를 처리하기 위한 XML/YAML 포맷 활용
- 다수의 파일을 빠르게 액세스할 수 있도록 하는 자체 패킹 파일 관리
- 한정된 메모리를 최대한 활용할 수 있도록 해주는 리소스 매니저
- socket 을 이용한 TCP/IP 네트워킹
- 블러킹을 막기 위한 IOCP/epoll 등을 이용한 비동기 송수신 구조
- FTP/HTTP 프로토콜을 활용한 런처/업데이터
- Win32/POSIX 쓰레드를 이용한 복수 CPU/멀티코어 활용
- ODBC/OleDB 등을 이용한 관계형DB 액세스
- PHP/ASP 등을 이용해 구축한 운영자용 관리 도구
- SEH/SMTP 를 이용한 예외 발생시 메일 발송 핸들러
- 기타등등...

위와같은 다양한 분야들은 한명의 개발자가 모두 숙달하여 운용하기엔 너무나 방대한 주제임에 분명하다.


그뿐만이 아니다. 저 기술들이 각자 따로노는 것이 아니라, 조화를 이루어 플레이어에게 24시간

꺼지지 않고 안정적으로 운영이 가능해야 하며, 자칫 사소한 실수라도 범했을 경우 회사가 소송에

휘말리거나 (유저의 id/pass 를 로그 파일로 남겼던 리니지2의 경우) 유저 커뮤니티와 회사 매출에

심각한 타격을 주는 경우 (돈복사로 인한 롤백등) 가 비일비재하다.


또한, 이러한 소프트웨어 개발은 제품 출시가 끝이 아니며, 몇년 이상 계속 지속되는 경우가 흔하다

오픈베타때 10만줄로 구성되어 간신히 돌아가던 코드가 상용화 이후 몇차례의 대규모업데이트를 거치고

나면 복잡도가 너무나 증가해버려서 더 이상 유지보수 불능의 상황에 빠질지도 모른다.


저 복잡한 괴물을 만들어냈던 사람들이 항상 옆에 함께하면서 모르는 것을 물어볼 수 있다면 (왜 저걸

저렇게 만든거지?) 그나마 다행이라고 해야 할 것이다. 불행하게도 그 선배들은 다른 신규 개발팀으로

옮겨갔을 수도 있고, 회사를 떠나 다른 회사로 스카웃 되어갔을 수도 있으며, 어쩌면 게임 개발에 환멸을

느끼고 시골에 내려가서 농사를 짓거나, 치대 입학을 위해 입시공부를 하고 있을지도 모른다.


과연 업계에 발을 들여놓을 신참 게임개발자들은 위와 같은 악조건을 헤쳐나가는데 필요한 노우하우를

충분히 배울 방법이 있을까? 현장에서 맨땅에 헤딩을 하면서 피투성이가 되는 것만이 유일한 길일까?


암울하게도 현재까지의 결과를 보면 상황은 매우 좋지 못했다.

신생 게임 회사들이 내놓은 게임들중 상용화를 거쳐 안정적인 매출을 올리는 게임의 비중은 높지 않으며

출시 자체조차 못하고 프로토타입 단계에서 사라져간 게임들은 이루 셀 수 없이 많다. 문제는 영세한 신생

회사 뿐만 아니라, 한개 이상의 게임을 안정적으로 서비스하고 있는 회사들 조차 비슷한 문제에 시달리고

있다는 점이다. 자본과 경험을 갖춘 기존 회사조차 내부 신규 개발팀이 일정과 예산에 맞춰 적시에 신작을

출시하는 경우를 찾아보는 것이 더 힘들정도였다. 한편, 거액에 판매되는 상용 엔진들의 존재는 이런 문제

를 해결하는데에 사실상 별 도움을 주지 못하고 있다. 대부분의 상용 라이브러리들은 해결해야 하는 문제

의 아주 일부만을 해결할 뿐이며, 종합적인 엔진의 면모를 갖추고 있는 솔루션들은 대부분 FPS 라는 장르

에 기반해 만들어졌고, 전체가 하나의 덩어리로 이루어져 있어서, 전체를 다 쓰던가 포기하던가, 아니면

직접 뜯어 고쳐야 하는 (사실상 결과적으로 새로 만드는 것과 비슷한 시간을 소요케 하는) 선택을 해야

한다. 이 문제의 근원을 어디서 찾아야 할 것인가?



나는 이 원인의 전부는 아니겠지만 상당부분이 1층짜리 건물과 100층짜리 건물의 차이점과 유사한,

소규모 소프트웨어와 대규모 소프트웨어의 차이점에서 비롯된다고 생각한다.


나를 비롯해 대부분의 게임개발자들은 소규모 소프트웨어의 세계에서 건너온 사람들이다. 이전에는

별로 중요하지 않았던 문제들이 대규모 소프트웨어의 세계에서는 전혀 다른 의미와 중요성을 지닌다.

1층짜리 건물을 짓는 건축가에게 중력, 바람, 지하수, 염분, 열 같은 존재가 의미를 가지는 것과 100층

짜리 건물을 짓는 건축가에게 그런 존재들이 가지는 의미는 전혀 다를 수 밖에 없다.


마찬가지로 소프트웨어를 만드는 사람에게 중력, 바람, 지하수, 염분, 열 같은 존재는 무엇일까?

그것은 바로 복잡성이라는 존재다.

대규모 소프트웨어를 만드는 사람이 복잡성에 대해 심각하게 생각하지 않는다면 아무 사전준비 없이

100층짜리 건물을 지어야 하는 1층짜리 건축가의 처지에 놓일 수 밖에 없을 것이다.


프로그래밍 언어를 배우는 것은 소프트웨어 공학을 배우는 것이 아니다.
알고리즘과 데이타구조를 배우는 것은 소프트웨어 공학을 배우는 것이 아니다
특정 API 나 표현 포맷을 배우는 것은 소프트웨어 공학을 배우는 것이 아니다
디자인 패턴이나 애자일 방법론을 배우는 것은 소프트웨어 공학의 일부를 다루는 것에 불과하다


대규모 소프트웨어 개발 공학을 배우는 것은 복잡성이 무엇인지를 깨닫고, 그것에 대응하기 위한 방법들
을 배워 실제로 실천하는 것이다.

1996년에 John Lakos 가 Large Scale Software Design in C++ 이라는 책을 통해 대규모 소프트웨어의

복잡성의 위험과 그 복잡성을 타개하기 위한 뛰어난 저술을 남겼음에도 불구하고, 책의 부피와 번역서의

부재등으로 인하여 우리나라 게임개발자들에게 제대로 소개되지 못한 점은 매우 안타까운 일이다.