--

뭐 생각난김에 끄적끄적 해봐야지!

최근에 세계 경제가 흔들리면서 많은 회사들이 구조조정과 회사의 체질 개선을 위해서 과감한 결단을 보여주고 있다. 기존까지 넥슨은 최고 보다는 조금 낮게, 다른 곳 보다는 높게 라는 애매한 수준을 유지해 왔다. 이번에 지난 약 한달 동안 넥슨은 내부에서 여러가지 변화가 있었다.

대표 이사의 교체라던가, 내부 제도의 변경, 소위 말하는 구조조정 과정 등.

이러한 넥슨의 변화는 단순히 재정적이나 구조적인 변화를 이야기 하는 것은 아니다. 이러한 변화는 넥슨의 색을 변하게 하고 있다. 그 색이 아름다워 질지, 더러워 질 것인지는 다직 그 변화가 전부 이루어 진 것이 아니기 때문에 알 수 없다.

넥슨이 변화가 필요한 구조를 가진 회사라는 것에 대해서는 나도 동의 한다. 다만 그 변화의 방향이 '개발자'가 생각하는 변화와 '경영자'가 생각하는 방향이 다르다는 것을 이번에 좀 깨닫게 되었다.

예전에 SE 강의를 들으면서 교수님이 이런 이야기를 한 적이 있었다.

IT 회사는 기술(또는 개발)을 하는 집단과 경영을 하는 집단이 함께 모여서 하나의 기업을 이루고 있다. 한국의 대부분의 회사들은 CEO가 모든 것을 담당하고 있다고. 하지만 이상적인 집단 또는 외국의 대표 기업들은 (나로써는 정말인지 알수는 없다) CEO는 최고 경영자이기는 하지만 그것은 경영에만 국한 되며 CTO 또는 CIO의 역할이 매우 크다는 것이다.

즉, IT 기업의 경우 기술 개발이 주가 될 가능성이 높은데 CEO의 경우 경영적인 마인드가 우선시 되기 때문에 IT 본연의 기술 개발에 대해서 최적의 환경을 구성하는데 큰 도움이 되지 않을 수 있다는 것이다. CTO 또는 CIO는 개발 조직을 대변하고 조직의 발전, 환경 구성을 위해서 존재하는 직책이기 때문에 한국의 대부분의 CEO 가 가지고 있는 소위 문과적 마인드에 이과적 마인드를 보충하기에 충분하며 기술과 관련된 결정을 내리는데 최고로 적합할 것이라는 것이다.

아쉽게도 넥슨에는 그러한 CTO의 역할이 충분히 크지 않다. CTO의 역할을 하는 직책이 있으나 의사 결정 및 무언가를 진두 지위 하기에는 현 넥슨의 구조적인 문제가 발목을 잡을 것이라고 본다.

그렇다면, 넥슨에서 변화가 필요한 것은 무엇이 있을까?

나는 개인적으로 두가지 정도를 대표적인 것으로 생각한다.

첫번째는 넥슨 그룹이라는 이름에 묶여는 있지만 너무 독립적인 각 개발 조직과 성과 위주의 조직 편차다.

이 문제는 넥슨의 기술 노하우를 내부에서도 공유하는데 인색하게 만들고, 각 조직은 서로 동일한 시행 착오와 충분히 없앨 수 있는 불필요한 개발 투자 시간을 크게 늘리는데 일조 하고 있다. 즉, 노하우(Know How)가 절대적으로 개발자 또는 기획자 개인에게 달려 있게 된다. 이러한 상황의 결과는 조직 자체의 기술의 발전을 가져 오는게 아닌 개인의 기술 발전을 가져 올 뿐이다.

예를 들어 S 전자에서 A 반도체를 생산하고 훗날 조금 더 발전된 B 반도체를 생산해 냈으나, A 반도체 개발 조직이 어떠한 이유로 사라 진다면 (타 조직으로의 발령 또는 이직과 같은 이유 등) S 전자에서 더 이상 B 반도체를 생산 할 수 없을 수도 있다는 이야기이다. 물론 S 전자에서는 당연히 그럴리 없겠지만.. 아쉽게도 넥슨에서는 그럴 가능성이 매우 높다.


두번째는 넥슨의 개발 허들 시스템이다.

이상적인 정석의 소프트웨어 개발론을 따르자면 소프트웨어는 개발( 코딩 )전에 문서로 소프트웨어의 구조와 상세 명세 등이 다 나와 있어야 한다. 이것을 보고 개발 조직이 순수하게 문서만으로 완벽하게 구현해 하는 환경이야 말로 최적의 개발 경로일 것이다.

개인적으로 넥슨의 허들 시스템을 평가 하자면, 그것은 특정 기간마다 게임의 상태를 점검해서 진행 여부를 결정 하는 지극히 반기술적이며 완성도를 크게 저하시키는 시스템이다.

개인적으로 게임 개발을 하기 위해서 개발팀은 아래의 순서를 따르는게 최선이라고 본다.(개인 의견)

1. 개발 하고자 하는 게임의 기획 완료(여기서 기획이란 플레이 방법, 목표 등 게임의 모든 것을 이야기 한다)
2. 게임에 필요한 기술적인 결정 요소 확정
3. 게임에 필요한 테스트 리소스와 프로토 타입 개발을 위한 툴 제작 작업 & 프로토 타입 개발
4. 프로토타입 완성
5. 진행 여부 결정
6. 기획 수정 사항 및 기타 기획 확정
6. 게임에 필요한 툴 제작 & 공용 소프트웨어를 이용한 리소스 제작
7. 툴을 사용한 게임 리소스 개발
8. 게임 코드 개발
9. 알파 완성

물론 순서에 대해서는 논란의 여지가 많겠지만 개인적으로는 저러한 순서가 제일 무난하다고 생각된다. 대략적인 1~9까지는 커다란 하나의 단계로써 9 단계는 소위 말하는 사내 테스트 또는 오픈 베타가 되어야 한다고 생각한다. 싹수가 노란 게임은 단계 5에서 접어야 한다.

하지만 넥슨의 허들 시스템은 1에서 5까지 진행을 하고 게임 조직의 탄생하고 단계 6에서 단계 9를 완성까지 무한 반복하게 된다. 그냥 생각하면 문제가 없을 것 같으나 현실은 그렇지 않다. 그것은 완성 되지 않은 기획에서 부터 문제가 시작된다. (이것은 기획자의 탓이 아닌 허들 시스템의 문제이다. 기획팀에 충분한 완벽한 기획 준비가 되어진다면 문제가 없을테니)

이것은 건축 회사가 마치 건물을 짓는데, 1층을 짓고 2층을 짓다 보니 1층에 빼야 하거나 더해야 할게 나타나는 상황과 같다. 이상적이라면 완성도를 위해서 필요한 부분까지 Undo를 해서 다시 지어야 하지만 그것은 시간, 돈, 인력 모든 것을 낭비하는 것이고 2층을 짓다 말고 1층을 수리 한다면 그것 역시 Undo 보다는 훨씬 단축 된 것이지만 마찬가지로 어느정도의 시간, 돈, 인력을 낭비 하는 것이다. 이것이 쌓이고 쌓여서 30층까지 올라 왔는데 1~15층에 수정이 필요한 상황이 또 발생한다면? 그 건축 회사가 무한의 리소스를 가지고 운영되는 곳이 아니라면 프로젝트가 깨지는 것은 당연한 것이고, 만약 각 층마다 정해진 시간과 요구되는 퀄리티 (허들 시간과 재미 정도)가 있다면 보수 또는 공사 강행의 기로에서 공사 강행을 선택 하게 될 것이다.

그렇게 완성된 건물은 소위 부실 공사가 될 수 밖에 없다. 그렇지 않을까? 나만의 생각일까?

만들어 보기 전에는 알 수 없잖아. 라는 말이 나올 수도 있지만 영화나 드라마를 볼때 시놉시스(또는 대본)를 보고 그 재미를 판단 할 수 있듯이 (물론 100% 맞는건 아니지만) 단계 1 에서 충분한 수준의 기획이 나와준다면 어느 정도 충분히 판단의 근거가 될 수 있을 것이라고 생각한다.


내가 너무 이상적인 생각과 이야기를 하는 걸까?
그런걸까?
그런걸까?
--