라이브3실 국내 개발 보고서

기술자료 등 많이 올려보려고 자료 정리하다가 찾은거에요.

한참 혈기왕성하던 젊은 시절 작성했던 보고서 입니다.

조금 급진적인...

---

라이브3실 국내 개발 보고서

1. 개발 협의 과정의 문제

1.1. 개발 일정과 패치 일정의 차이

개발 일정 이란 목표한 기능을 기대한 수준 까지 만들기 위한 Unstable 버전을 다루는 것을 뜻하는 것이며, 패치 일정 이란 Stable 버전을 만들기 위한 Unstable 버전의 품질 및 안정성을 향상 시키는 단계를 이야기 하는 것입니다.

1.2. 일정 협의 시 고려 사항

소프트웨어 개발은 예를 들어 부품 공장의 운용처럼 기계를 오래 돌려 상품을 많이 생산하는 식의 찍어내기 방식과는 전혀 다른 산업 분야라고 생각 됩니다. 이는 지식을 기반으로 응용을 하여 생산을 해내야 하는 학습과 창의력을 요구하는 일이기 때문이며, 일정 관리자에게 있어서 끊임 없는 연구를 하게 만드는 일이기도 합니다. 만약 개발 일정을 무시한 채 패치 일정을 세우는 행위를 지속 한다면 지킬 수 없는 약속들로 인해 결국 모든 신뢰를 잃고 말게 될 것 입니다.

2. 개발 일정 관리에 대한 비전문적 운용 방식

2.1. 분별 없는 Conference의 폐단

항상 아이디어를 채택 할 때는 분명한 목적과 기대 효과를 신중히 검토 하는 습관을 가져야 합니다. 더불어 시스템 분석과 Simulation을 바탕으로 기획서가 작성 되어야 하는 것인데 현재 국내 OOO 개발 회의의 대부분이 아이디어 수준의 대화 내용 들을 패치 일정으로 확정 시키고 있어 분석 및 검증이 부족한 기획서 들을 기준으로 개발 협의를 진행 시키는 것이 일반적인 관행이 되어가고 있습니다.

단지 시간과 인력이 부족 하다는 이유만으로 이러한 상황들을 합리화 시키고 있다면 Sophist 적인 매우 위험한 발상들을 하고 있는 것으로 생각 됩니다.

2.2. Planning Team의 역할

개발 일정 진행을 위해 기획팀이 해야 할 일은 게임 플레이를 시작 부터 끝까지 고민해 보고 기획서를 작성 하는 것이며 각 예외 상황들에 대한 고려를 충분히 해주는 것이 주요 하다고 생각 합니다.

2.3. Programming Team의 역할

개발 일정 진행을 위해 프로그램팀이 해야 할 일은 구현 가능한 기획서를 바탕으로 최적화 또는 코딩이 가능하게 재구성 시켜 설계를 완성 하는 것이 주요 업무가 되게 됩니다.

2.4. Project Manager의 역할

구체화 될 수 있는 개발 일정 인지를 파악 하여 기획 일정과 프로그램팀 일정을 Rough 하게 조정 할 수 있는 능력이 필요 합니다. 이후 Unstable 버전을 Stable 버전으로 업데이트 하기 위해 전반적인 작업 공정을 관리 하는 것이 주요 업무라고 생각 합니다.

2.5. Buffer Schedule이 필요한 이유

배수의 진이라는 것은 예외 상황에 대한 대처가 불가능한 최악의 진법 중 하나라고 생각 합니다. 모든 사람은 예측 할 수 없는 조건을 내재 하고 있으며, 이를 위한 대처를 위해 Buffer는 반드시 고려가 되어야 하는 부분 입니다.

2.6. 휴식이 필요한 이유

기계는 과열이 될 경우 잦은 고장을 일으키게 됩니다. 망가지는 것은 한순간 이지만 수리를 맡길 경우 언제 수리가 완료 될 지 증상에 따라 기약이 없을 것입니다. 게임 개발자는 마라톤 선수 처럼 페이스 관리를 망칠 경우 오히려 개발 속도가 느려지게 되거나 개발을 완료 하지 못할 가능 성이 높습니다.

3. 인력 확보에 대한 시점 차이와 현실적 문제

3.1. 인재 양성과 자기 개발의 중요성

필요한 포지션에 준비된 사람을 채용 하는 것은 항상 매우 어려운 일이 될 것입니다. 각 팀의 Leader 들은 일정 수준 이상의 개발자 들을 교육 시키는 것에 대해 긍정적인 생각을 가지고 있어야 하며, 적절한 기회를 통한 경험을 주어 자기 개발을 할 수 있게 기회를 주는 것이 준비된 사람을 찾는 것 보다 훨씬 현실적인 것이 아닐까 생각 됩니다.

3.2. Leader Staff의 기준과 역할

Leader란 시스템 구현에 대한 충분한 경험과 문제 해결을 위한 원인 분석 능력이 일정 수준 이상이 되어야만 될 수 있다고 생각 합니다. 이를 바탕으로 팀원들의 업무를 Leading 할 수 있게 되는 것이며 Leader의 의무적 역할 중 하나라고 생각 합니다. 더불어 상호 배타적이지 않은 자세가 반드시 필요 합니다.

3.3. Expert 인력 확보의 중요성

뛰어난 사람은 대부분 경험과 Reference를 가지고 있어 시행 착오를 줄일 수 있는 능력을 가지고 있고 뛰어난 사람을 배출 할 수 있는 능력을 보유 하고 있습니다. 특히 프로그래머들에게는 학습에 대한 욕구가 남달라서 Expert에 대한 존재가 강한 결속력을 가질 수 있게 하는 동기가 되기도 합니다.

3.4. Live Projects에 대한 Expert 들의 생각

상위권 수준의 프로그래머가 라이브 업무를 바라보는 시각은 자신의 실력을 증명 할 수 없는 제한적 프로젝트이며 Career에 전혀 도움이 안되는 일 이라는 인식을 가지고 있습니다.

3.5. Vision의 중요성

회사에서의 업무는 지시 하는 것이 아닌 참여 하는 것이 되어야 합니다. 비전이란 참여를 유도 할 수 있는 명분을 제공 하는 것이며 확실한 목표와 방향성은 사람들로 하여금 자발적인 책임과 의무감을 부여하게 하기도 합니다. 성공적인 프로젝트의 필수 요소 중 한 가지라고 생각 합니다.

4. 시스템 이해의 필요성

시스템 분석이 중요한 이유는 이해의 깊이 만큼 응용 개발을 할 수 있다는 점을 들 수 있습니다. 장기적 개발 또는 단기적 개발의 일정 계산은 이에 근거 하여 구별 할 수 있는 것이며, 프로그램 팀의 경우 위 과정을 반드시 확인 하고 넘어 가게 됩니다.

기획 팀의 경우 구현 단계 까지는 분석이 안되더라도 프로그래머와의 원활한 업무 협의를 이루기 위해 기존 시스템에서의 설계 단계 까지는 분석(시스템 기획서)이 완료 되어 있어야 한다고 생각 합니다.

5. 시스템 활용의 필요성

경험이 많은 프로그래머 들의 공통점 중 한 가지는 바로 확장성 있는 설계를 지향 한다는 것입니다. 이는 유사한 시스템에 대한 개발 기간을 단축 시킬 수 있기 때문이며 더불어 프로그램에 대한 유지 보수 및 버그 추적을 쉽게 처리 할 수 있기 때문 입니다.

상용화 된 게임들이 대부분 위와 같은 이유로 확장성을 고려하고 있지만 어디 까지나 제한된 자원에서의 코드 구조가 작성 되게 됩니다. 현재 기획자들의 가장 큰 문제점은 이러한 제한을 분석하지 않아 근거 없는 확장성을 계속 내세우게 되며 기간 단축 할 수 있다고 주장하는 것에 있습니다.

6. 시스템 기획자 부재의 의미

게임 시스템에 대한 기획적 설계는 결코 기술적 한계를 넘어설 수 없습니다. 게임 기획 이란 제한된 조건을 파악 하여 극한의 응용을 구현 하는 것에 있습니다. 이에 대한 한계치를 프로그래머와 정의 하는 사람이 바로 시스템(메인) 기획자 입니다. 난이도가 높은 시스템의 경우 프로그래밍 지식이 부족한 기획자는 기획을 할 수가 없으며, 이러한 이유로 개발사 들은 프로그래머 출신의 시스템 기획자 들을 가장 선호 하게 되는 것입니다.

7. 기획 단계 에서 발견 된 문제들

7.1. 크루 시스템

설계 되는 시스템의 프로세스를 책임 있는 기획자 들이 이해 하지 못하여 확장 활용에 대한 제안을 따라오지 못했습니다. 해당 기획서는 구현 할 수 밖에 없는 구조들과 투자 하게 되는 시간들을 고려 해 볼 때 사용 되는 기능이 일부에 지나지 않아 그 효율성이 매우 떨어지게 됩니다.

7.2. 피로도 시스템

신규(리케츠) 서버에서 사용 할 피로도 시스템을 밤낯으로 구현 하였으나 어렵게 구현한 퀘스트 스크립트 함수 들을 시간 상의 이유로 활용 하지 못하고 있었습니다. 이후 피로도 시스템을 게이지를 충전 할 수 있게도 방식으로 수정을 해주었으나 아직 퀘스트에는 활용이 되고 있지 않습니다.

7.3. 서버 홀 대항전

기획서의 내용은 대부분 채널 서버의 공성전 시스템을 DK 서버에 그대로 올려서 조금만 고치면 된다는 식의 것이었지만 모두 구현이 불가능 한 내용 들이었습니다. 공성전이 아닌 DK Square의 채널 이동 구조를 참고 하는 것이 유일한 방법이었으며 서버 홀 대항전을 위한 모든 프로토콜 함수와 스크립트 함수는 새롭게 만들어 져야 하는 상황 이었습니다. 기획 팀에서는 더이상 일정을 따라오지 못하고 있었고 스트레스를 너무 많이 받아 작업 도중 중단을 하게 되었습니다.

초기 개발 회의에 참석 했을 때 분명 최악의 상황은 DK 서버의 프로토콜을 모두 다시 구현 해야 한다는 의견을 주었었지만 이에 대한 검토가 제대로 이뤄지지 않았었습니다. 이후 근거 없는 패치 일정이 계속 잡히게 되어 지금의 상황에 이르른것 같습니다.

8. Quality Assurance 관리 문제

개발 팀 에서의 QA는 매우 중요한 위치에 자리 잡고 있습니다. 항상 개발 된 기능들을 지속 적으로 테스트를 해야 하며 피드백 역시 발생 했던 과정들을 상세히 기록 하여 정확한 순서대로 재현을 할 수 있게 해줘야 합니다.

상용 서버에서의 버그 발생률을 줄이기 위해 효율적인 테스트 방법론을 항상 연구 해야 하며, 전문성을 갖추고 업무에 임해야 한다고 생각 합니다.

9. Total Renewal이 불가능 한 이유

계획 했던 Total Renewal은 기존 시스템의 장점과 단점을 모두 분석하여 새로운 아키텍처 구조로 구현 하는 것을 목표로 하고 있었습니다. 난이도가 다소 높은 작업들이 주가 되어 시스템(메인) 기획자가 없을 경우 프로그래머 에게 가중되는 업무 집중도가 비현실 적으로 매우 높아지게 됩니다.

같은 이유로 국내 컨텐츠 개발 역시 동일한 상황을 겪고 있다고 생각 합니다.