토끼발 하고 까꿍해!

박 과장은 7대낭비를 △과잉생산 △대기 △운반 △부정확한 공정 △과잉재고 △불필요한 동작 △불량으로 규정하고 각 항목들에 대한 세부적인 사례들을 제시했다.

1. 과잉생산
지나친 생산은 트렌드에 적합하지 못할 수 있을 뿐만 아니라 향후의 기술과 효율적인 적용이 어려워져 발전 가능성을 저해할 수 있다며 필요한 만큼의 목표를 빠르고 정확하게 반영해야한다고 말했다.

2. 대기
80%의 가치를 제공하는 20% 기능에 집중할 필요성을 역설했는데, 다양한 공정을 동시다발적으로 진행하면서 일부 공정을 대기시키는 현상은 시간낭비라며, 이크레디빌드 사용으로 빌드시간 단축은 물론 높은 집중력을 얻게 되었다고 회고했다. 또한 허들 시스템 역시 간소화로 긴장감과 결단력 향상을 꾀하는 것도 좋은 사례라고 전했다.

3. 운반
지식운반에 집중해야하는데 기획서 없이는 작업하지 말 것과 문서 공유를 권했다. 다시 배우는 일 없이 직접 고치고 배우는 기반을 마련해야 하며, 전임자의 의도와 제반 데이터를 보다 쉽게 수정, 업데이트할 수 있도록 해야 한다고 강조했다.

4. 부정확안 공정
직접 가서 보면서 안목지도를 활용해야 개인별, 팀별 의사소통이 원활해지고 공정 표준화로 버그가 줄어들게 되는 만큼 맨투맨에 집중해줄 것을 당부했다.

5. 과잉재고
전통 산업에 비해 재고가 적으나 집중하지 않으면 역으로 지나칠 수 있으니 신경써서 과잉을 억재한다고 강조했다. 그 결과 빠른 업데이트와 보다 유저 욕구에 맞는 콘텐츠를 효과적으로 제공할 수 있게 된다고 조언했다. 특히 용어의 통일 및 정리등 작은 부분까지도 업무 협조를 극대화시키며 유닛테스트로 코드 에러 최소화하면 큰 결과를 얻게 될 것이라고 첨언했다.

6. 불필요한 동작
자신의 행동 및 동료와의 협조에 있어서 정확한 의사전달과 공조가 있어야만 시간을 절약할 수 있다고 말했다. 특히 비주얼 소스 절약이 현재 개발자들에게 당면한 큰 과제라며 이를 위해 퇴근 시 무조건 컴파일할 것과 작업을 작은 단위로 나눠서 개발하여 타인의 시간을 묶지 말아야 한다고 역설했다. 특히 공용 인터넷PC를 복도에 설치해 부당한 활동을 제동할 필요성도 제시했다.

7. 불량
불량은 브랜드하락으로 이어져 향후 사업에도 큰 차질이 빚어지므로 위기 관리에 민감해야 한다며 QA팀과의 협조와 신뢰회복에 노력을 아끼지 말라고 조언했다. 일환을 가상 공격 공식 산정 툴 등 QA팀의 편의를 고려한다면 보다 친절한 피드백이 돌아올 것이라고 귀뜸하기도 했다.

그는 이러한 7대낭비에 대한 해결책으로 △일일 1분간의 스탠드 미팅 △2주 4주 단위의 짧은 마일스톤을 갖는다 △팀과 개인별 백로그로 작업량 할당 원할 △정보방열판을 통한 작업의 당위성 및 정보교류 증대화 △자동 검사 시스템으로 테스트 인력 극소화 △눈에 보이지 않는 Null Point 등의 결과들에 집중 △스크랩트 체크 시 상호 참조를 위한 통합 스크립트 체커(자동화 체커) △안돈 시스템으로 버그 픽스 없이는 모든 공정 중지를 제시했다.
 
이어 그는 조직내 인간 신뢰 확보, 일일빌드시스템, 좋은 문화 직접 전파하기 등 기업문화로 발전하기 위한 노력들에 대해서도 큰 의미를 가져달라고 당부했다.

제목 : 넥슨에 대해 끄적이기.
펌 URL : http://yuno.org/323?TSSESSIONyunoorg=21ef2317575c81ed3d6020633111e094

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

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

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

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

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

예전에 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 에서 충분한 수준의 기획이 나와준다면 어느 정도 충분히 판단의 근거가 될 수 있을 것이라고 생각한다.


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

제목 : 7대 낭비를 통해 본 리니지2 개발 시스템
펌 URL : http://www.betanews.net/article/435084