자료보관함‎ > ‎가마수트라‎ > ‎

온라인 게임도구 개발용 소프트웨어 프로세스


저작권 정보

현재 가마수트라가 번역허가를 내주고 있지 않은 관계로 원문의 링크만을 제공합니다. 하지만 영어에 도움이 필요하신 분들을 위해 아래에 해석을 달아놓았습니다. 원문을 읽으시다가 모르시는 부분이 있으시다면 비교하면서 읽어보시길 바랍니다.


원문 정보


소개

MMOG(Massively Multiplayer Online Game)을 만드실 계획이십니까? 끝내주는 게임 기획안, 최고의 그래픽 엔진, 업계 최고의 프로그래머와 디자이너 및 개발에 필요한 충분한 자금을 가지고 계시다구여! 와~ 정말 대단한데요? 하지만 소프트웨어 툴은 어떤가요? 게임 디자인 스펙에 있는 내용들을 어떻게 구현하실 건가요? 물론 도구를 사용해야 한다는 것쯤은 이미 알고 계실 것이고, 그에 필요한 개발시간도 이미 할당해 두셨겠죠? 그리고 그 도구들은 사용하기가 쉽겠죠? 맞죠? 네? 네?


애쉬론즈 콜 2: 폴른 킹즈



MMO용 툴을 개발하는 방법은 비록 스케일은 조금 작긴 하지만 일반적인 소프트웨어 프로젝트를 개발하는 방법과 유사합니다. 어떤 측면에서 보면 툴은 게임의 전체 기능중 일부 기능들을 조작하는 소형 클라이언트이기도 합니다. 따라서 일반적인 소프트웨어 개발론을 따르는 것이 매우 중요합니다. 별다른 사전 계획없이 필요할 때마다 도구를 만들어나가다 보면 많은 문제를 일으킬 소지가 있습니다. 철저한 디자인하에 개발된 툴은 많은 시간을 아껴줄 뿐만 아니라 여러분이 다른 일로 옮겨간 후에도 유지 보수 팀이 오랫동안 여러분의 업적을 기릴 것이라는 것을 (아니면 뒷다마를 깔지도...) 기억하시기 바랍니다.

그렇다면 "표준 소프트웨어 개발론"이란 정확히 무엇일까요? 소프트웨어 개발론 관련 서적들에 나온 여러가지 과학적 정의들이라고 생각하시는 분이 계실지도 모르겠지만 저는 "신뢰성 있는 방법과 반복적인 방법에 의해서 이루어지는 개발 과정" 라고 생각합니다. 여기서 반복이라는 것은 개발 프로세스 표준화가 정착되어 있지 않은 상태에서 개발이 계속적으로 반복되어 시행착오를 거쳐 최종적으로 하나의 표준 개발 프로세스가 되는것을 의미합니다.

터빈 엔터테인먼트 소프트웨어 회사에서는 5단계에 걸쳐 툴을 개발합니다. 조사와 요구사항 수집, 설계, 프로토 타입 제작과 구현, 테스트, 보정 작업이 그 5단계입니다. 각 단계의 의미는 부연 설명이 필요 없을 정도로 명확하니 곧바로 터빈 엔터테인먼트 소프트웨어 회사가 각 단계에서 맞닥뜨렸던 성공과 실패에 대해서 설명하겠습니다.



==조사 및 요구사항 수집==

새로운 툴을 개발하거나 기존의 툴에 새로운 기능들을 추가할 때 적용하는 철저한 "조사 및 요구사항 수집" 과정은 여러분의 프로젝트에 탄탄한 기반을 제공할 것입니다. 저희는 3가지 방법을 사용하여 요구사항을 수집했습니다. 우선 개발자들이 사용자들의 작업 흐름을 관찰하기 위해 사용자와 함께 자리했습니다. 둘째, 툴 개발자들이 툴 사용자와 동일한 작업을 따라해 보았습니다. 마지막으로 브레인 스토밍 회의를 실시 했습니다.

저희가 찾아낸 가장 유용한 방법은 사용자들이 작업하는 것을 지켜보는 것이었습니다. 일례로 과거 이러한 과정에서 사용자들이 버젼 관리 시스템에서 파일의 체크아웃을 위해 프로그램을 전환하는 것이 생산성에 나쁜 영향을 미친다는 사실을 알아냈습니다. 그 이유는 툴에서 파일을 저장하고 다시 버젼 관리 시스템을 실행시켜서 수정하려는 파일을 일일이 찾아서 체크아웃하려면 귀찮을뿐더러 시간이 걸렸기 때문입니다. 그래서 이 부분이 생산성에 나쁜 영향을 미쳤기 때문에 저희는 이것을 해결하기 위해 툴에 자동으로 버전 컨트롤 기능 즉 체크아웃을 하는 기능을 포함시켜서 생산성의 효율을 높였습니다.

직접 자신의 툴을 사용해봄으로써 고치거나 제거해야 할 부분을 찾아낼 수도 있을 것입니다. 툴 사용자와 함께 앉아 그 과정을 살펴보지 않는다면 브레인 스토밍 회의는 그다지 큰 의미가 없습니다. "백문이 불여일견입니다. 엔지니어에게 필요한 것을 말하는 대신 직접 보여주십시요. 그렇게 하면 얻고자 하는 것을 얻을 수 있을 것입니다" 기술 부팀장 Chris Dyl의 이 말은 많은 의미를 함축하고 있습니다. 툴 사용자와 함께 작업 과정을 살펴 보지 않고 그냥 브레인 스토밍을 할 경우는 문제점이나 최종 결과에 대해서 회의 하는 것이 아니라 불필요한 새로운 기능들을 추가하는 것으로 결론이 나는 것으로 끝나는 경우가 비일비재하기 때문입니다.

모든 요구사항들을 수집한 후에는 그 수집물들을 잘 정리해야 합니다. 이 때 저희가 최우선으로 고려하는 사항은 어떤 요구사항들이 사용자의 시간을 가장 많이 절약해주는가입니다. 이런 "가장 최대효과를 주는것을 선정" 방법을 사용하다 보면 결과적으로 가장 어려운 프로그래밍 작업이 최대의 시간을 절약시켜주는 경우가 보통입니다. 수작업 과정을 제거하고 지나치게 긴 공정이나 다단계 공정들을 자동화시키는 것이 두번째 초점입니다. 오류 검사, 파일 복사, 코드 및 데이터의 자동생성 등이 이 범주에 속합니다. 저는 최근에 작업자의 생산성을 향상시키는 여러 주제를 논하기로 유명한 Don Moar가 가마수트라에 기고한 "Growing a Dedicated Tools Programming Team : From Baldur's Gate to Knights of the Old Rebulic" 글을 다시 읽었습니다. 저희 툴의 요구사항들을 작성하면서 그의 가이드라인을 염두해두었기 때문에 생산성 향상에 보다 집중할수가 있었습니다. 요구사항을 정리한 뒤에는 다음 단계로 넘어 가기 전에 '요구사항 완성본'을 만들어 결제를 받습니다. 이것은 혹시 빠뜨린 것은 없는지를 확인하는 매우 중요한 작업입니다.

일반적으로 대부분의 엔지니어들은 문서화 작업을 하는 것을 피하려고 합니다. 혹자는 지겹다고도 하고, 타이핑 양이 너무 많다고 하며, 실제 작업에 아무런 도움이 되지 않는다고도 합니다. 하지만 문서화는 조직과 의사소통에 매우 중요한 역할을 합니다. 새로 고용된 기술자들을 문서화 작업에 투입하는 것도 좋은 방법입니다. 이는 그들이 작업에 익숙해질 수 있도록 도울 뿐만 아니라 좋은 소프트웨어 개발습관을 가지도록 해줍니다. 문서작성이 개발 공정에 명시화 되어있다면 기존 엔지니어들도 이를 행해야 합니다. 두번째 "결제"과정 역시 이를 촉진하는 좋은 방법입니다. 문서를 작성하는 것을 뒤로 미루면 미룰수록 일을 더 어렵게 만들 뿐입니다.

이제 문서화된 요구사항을 기반으로 일정을 짤 차례입니다. 저희는 자주 기존 코드에서 사용했던 방법 및 아이디어들을 살펴보기 떄문에 이 작업은 소프트웨어의 설계 단계에까지 영향을 미칩니다. "일정 조사"는 특정 요구사항이나 작업에 얼마만큼의 시간이 소요될지를 대략적으로 추측할 수 있게 해줍니다. 하지만 툴 작업시 주의할 것은 "구현"과 "버그 수정" 에 소요되는 시간의 균형을 잘 맞춰야 한다는 것입니다. 잘 짜여진 코드라 할지라도 곧바로 수정해야할 문제는 반드시 발생하기 때문입니다. 일정을 수립함에 있어 이러한 버그수정 시간을 고려해 둔다면 후에 안정적인 일정 유지가 가능해집니다. 덧붙여 일정에 여유를 두십시오. 작업 난이도에 따른 어느 정도의 예상 시간에 덧붙여 20% ~ 50% 정도의 시간 여분이 있다면 대부분의 예기치 못한 상황에 대처할 수 있을 것입니다. 실제 일정 진행중 여분의 시간이 남았더라도 기존 기능을 보강하거나 사용자들을 위한 또 다른 기능작업에 투자하셔도 좋습니다.

==설계 단계==

설계 단계에서는 개발자들이 정말로 사용자들의 요구를 이해하고 있는지 확인하는 장소일 뿐 아니라, 요구사항 및 기능을 바꿀 수 있는 마지막 단계입니다. 이 이후에 무언가를 바꾸려고 하면 코드 재작성에 들어가는 시간 및 비용이 상당할 것입니다. 저희는 이 단계에서 두가지 문서를 만듭니다. 하나는 실제 사용자를 위한 추상 설계 문서이며, 다른 하나는 엔지니어를 위한 상세 설계 문서입니다. 추상적 설계 문서는 "이용사례 (Use Cases)" 와 다이얼로그 박스 예제를 포함합니다. "이용 사례"는 툴이 지원하는 기능을 사용자가 사용하는 방법을 설명합니다. 사용자가 작업을 시작하기 위해 취하는 행동과 예상되는 그에 따른 결과에 대한 간단한 설명도 추가합니다. 여기서 주의할 것은 "이용사례"는 엔지니어에게 코드를 구현하는 법을 설명하는 것이 아니라 사용자에게 각 기능이 어떤 일을 하는지를 설명하는 문서라는 것을 기억하시기 바랍니다.

툴 개발시에 대화상자를 비롯한 기타 사용자 화면을 자주 사용합니다. 마이크로소프트 DevStudio의 대화상자 편집기를 사용하면 사용자 화면을 쉽게 프로토타입으로 만들고 그 화면을 캡춰하여 설계문서에 포함시킬 수 있습니다. 저희는 보통 이런 대화상자와 프로토타입을 설계 문서에 넣기 전에 사용자들로부터 UI 의 형태나 데이타를 집어 넣을 수 있는 방식에 대한 느낌과 같은 의견들을 수렴합니다. 대화상자에 있는 각 입력필드, 오류 검증, "확인/취소" 버튼처리 등에 대한 설명을 포함하는 것이 보통입니다. 이러한 사항들이 모두 완료 되면 요구사항 단계처럼 고수준 설계문서에 결제를 받습니다.

상세 설계문서는 좀 더 기술적인 부분에 중점을 두는 문서로 사용자보다는 개발자를 위한 문서입니다. 상세설계 과정은 그 중요성에도 불구하고 수많은 소프트웨어 제작 팀이 그냥 넘어가는 단계입니다. 상세 설계문서의 작업은 하나의 "이용 사례"를 실질적인 파일이나 모듈 단위로 쪼개 나갑니다. 이 시점에서 새로운 시스템의 API들을 명시해나가고 여러명의 개발자들이 모여 최적의 구현 방식에 대해 논의하며, 이미 존재하는 코드로 여러가지 테스트를 해보면서 최종 형태를 명확히 해둡니다. 이러한 상세 설계 단계에서는 실제 구현상에서 발생할 수 있는 문제들을 미리 확인하고 제거할 수 있습니다. 설계 단계에서 약간의 시간을 투자함으로써 이후 많은 시간을 아낄 수 있게 되는 것입니다.

상세 설계문서가 필요한지 바로 코딩에 들어가야 하는지에 대한 논의가 있습니다. 어떤 개발자들은 설계문서를 만들기 보다는 프로토타입을 만들어 보는 쪽을 더 선호하기도 합니다만 그렇다 하더라도 어느 정도의 설계는 필요합니다. 설계문서는 코드의 흐름을 구성하고, 일반적인 코드를 작성할 곳을 결정하며, 소스파일과 모듈레벨에 그 작업을 문서화하고, 이 공정을 마치는데 필요한 각 단계들의 로드맵을 제공하는데 큰 도움을 줍니다. 터빈의 개발자들은 갑작스레 발생한 문제를 수정하거나 매우 중요한 부분을 재작업 해야할때 문서들을 통해 무엇이 문제인지 어떻게 수정해야하는지를 매우 쉽게 찾아낼 수 있었습니다.

"설계문서 수정"도 중요한 주제입니다. 여러분은 작업 진척에 따라 문서를 업데이트 하시나요? 아니면 땅에 뭍어두는지요? 고수준으로 설계된 문서는 실제 구현단계 중에는 수정하지 않으며 이 문서에 쓰여있는 "요구 사항" 및 "설계"도 수정할 필요가 없을 만큼 훌륭해야 합니다. 덧붙여 사용자와 개발자가 이 문서에 있는 모든 내용에 동의하였기에 이후 어떤 결과물이 나올지에 대한 것도 모두 같은 생각을 가지고 있습니다. 상세 설계문서는 개발자 문서지만 실제 구현중 변경이 필요할 경우 그 내용을 업데이트 합니다. 좋은 상세설계는 실제 개발시간의 1/3 정도를 쉽게 줄여줍니다.

==프로토타입 및 구현==
이제 견고한 요구사항 문서와 상세 설계문서가 준비되었습니다. 이 문서를 잘 따른다면 이젠 개발은 식은죽 먹기이겠죠? 사실 대답은 그렇기도 하고 아니기도 합니다. 상세 설계문서만 따른다면 필요한 기능을 구현할 수는 있겠지만 해결해야할 몇가지 문제가 있습니다. 어떻게 여러 개발자들과 작업의 일관성을 유지할 것입니까? 터빈은 일관성 유지를 위해 코드 작성기준(coding standards)과 상호코드검토(peer-reviews)를 실시합니다.

"코드작성 기준"은 코드를 작성하는 법을 잘 정의해놓은 회사내의 일련의 규칙들입니다. 변수와 클래스 멤버의 이름작성법, 탭과 공백의 사용, 괄호의 사용과 같은 규칙들은 일반적인 코딩 규칙 문서에서도 발견할 수 있는 것들입니다. 이러한 규칙들로 코드의 가독성을 높여주는 것은 MMO를 만드는 대규모의 팀에 매우 중요합니다. 하지만 코드작성 기준은 실제 소프트웨어 작성 과정에 대한 많은 정보를 전달할 수 있습니다. 다음의 내용들이 코드작성 기준에 들어가야 하는 내용들입니다. 1) 각각의 소스 파일에 삽입할 저작권 문구, 2) 라이브러리, 파일, 함수의 이름짓기 규약, 3) 문서화에 사용하는 도구(예, Doxygen). 간혹 소프트웨어를 만들 때 아무런 기준조차 새우지 않는 믿기 어려운 회사들이 있습니다. 코드작성 기준은 단지 ISO-9000이나 국방부의 하도급자를 위한 것만이 아니라 어떤 소프트웨어 개발 프로젝트에서든 중요한 의미를 갖습니다. 만약 여러분의 회사가 엔진의 일부를 라이센싱할 계획이 있다면 엄격한 코드작성 기준을 만들어두시길 바랍니다. 이후 여러분의 고객들에게 깔끔하고, 일관적이고, 한결같은 API 와 코드를 제공할 수 있을 테니까요.

<div align="center">
http://www.galexandria.com/img/picturespaceholder.jpg

'''터빈의 LayerManager'''
</div>

"상호코드검토" 는 여러명이 모든 코드를 검토하는 것을 의미합니다. 조금 부담스러운 작업이 될수도 있겠습니다만 터빈에서는 일반적으로 변경된 코드를 버전관리 프로그램에 체크인하기 전에 다른 프로그래머가 코드 변경사항들을 검토하는 것입니다. 변경 사항이 여러 시스템에 영향을 미칠때는 여려명의 동료들이 참여합니다. 코드를 작성한 프로그래머가 다른 프로그래머에게 변경 사항을 설명하는 동안 스스로 문제점을 찾으내는 경우가 종종 있습니다. 코드를 작성한 프로그래머의 책상앞에서 검토가 이뤄지므로 건설적인 비평이 이루어질 수 있습니다. 회의실에서 프린터 출력물을 가득 쌓아놓고 하는 코드 검토는 코드 작성자에게 공격적으로 느껴질 수도 있습니다. 검토자가 지적한 변경목록들은 소스에 주석으로 달리거나 별도 파일로 기록되어, 체크인 전에 참조됩니다. 상호코드검토는 이외에도 지식의 공유가 용이하며 각 개발자들이 시스템의 전체적인 면을 더 쉽게 볼 수 있다는 장점을 가집니다.

==테스트==
툴 개발은 역사적으로 소프트웨어 테스트에서 소홀히 다루어져 왔습니다.시간, 예산, 인력이 모두 부족했기 때문입니다. 저희는 결국 테스트를 거치지 않은 툴을 사용자에게 넘겨 버렸고 그 결과 사용자들은 버그 투성이의 프로그램에 매우 짜증내 했습니다. 결과적으로 저희는 버그를 고치는 데 더 많은 시간을 소비하였습니다. 툴을 테스트 하는 방법은 크게 두가지 입니다. 화이트박스 테스트(White Box Testing)와 블랙박스 테스트 (Black Box Testing)입니다.

화이트 박스 테스트는 개발자가 수행합니다. 개발자가 직접 코드의 진행 과정을 하나씩 모두 체크해봄으로써 올바르게 코드가 작성되었는지를 확인합니다. 이러한 방식을 화이트 박스라 부르는 이유는 개발자가 그의 코드, 즉 박스 안을 훤히 들여다 볼 수 있기 때문입니다. 블랙박스 테스트는 주어진 입력 값에 따라 올바른 출력 값이 나오는 지를 확인하는 방식으로 QA 팀이 수행합니니다. 여러분의 소프트웨어 공정도 이 두가지 테스트를 모두 포함하는 것이 좋습니다.

개발자는 적어도 자신이 작성한 코드를 테스트해야 합니다. 화이트 박스 테스트는 기능 테스트에 특화되어 있습니다. 최소한 개발자는 완벽한 코드를 제공해야합니다. 이것은 개발자가 자신이 작성한 코드의 모든 라인을 테스트 해보아야 한다는 의미입니다. 예를 들어 if/switch와 같은 조건문이 있다면 성공과 실패의 경우를 모두 체크해봐야 한다는 것입니다. 이 과정은 다소 시간이 소요될 수 있지만 코드가 모든 상황에서 정상적으로 작동하는지를 테스트 해볼수 있는 유일한 방법입니다. 앞서 말한 상호코드리뷰를 통해 변경 사항들을 확인하고 (덧붙여 실행과정도 시연하고) 모든 요구사항을 구현했는지 확인하고, 오류를 줄이고, 코드작성기준을 충실히 따르도록 코드를 확인/수정합니다.

여러분의 소프트웨어 개발 공정은 QA 팀이 얼마나 쉽게 블랙박스 테스트를 할 수 있는지에 직접적으로 영향을 미칠 것입니다. 요구사항 명세는 QA 팀에게 정확히 무엇이 바뀌었는지 알려줄 것이며, 고수준 설계의 "이용 사례" 는 새로운 기능들이 어떻게 테스트 되어야 하는지를 알려줄 것입니다. 이 두가지 문서를 사용하여 QA 팀은 기능들의 테스트 계획을 세울 수 있습니다. 그리고 테스트 계획을 사용하여 버그와 예상치 못한 동작들이 버그 데이터베이스에 추가됩니다. 현재 터빈은 숙련된 QA 팀이 블랙 박스 테스트를 맡고 있습니다. 물론 그들의 주안점은 게임 클라이언트의 테스트이지만 곧 툴 테스트도 담당할 예정입니다.

제가 만들고 싶은 한가지 기능이 있다면 그건 자가 검사 소프트웨어 툴(self-testing software tools)을 만드는 것입니다. 명령행이나 "테스트" 메뉴를 통해 각 소프트웨어를 자가진단 하는 방식으로 말이죠. 아마도 이 도구는 오브젝트를 만들어 움직여보고 돌려보고 늘리고 줄여보기도 하고, 지워보고, 복구할 수도 있을 것입니다. 이와 같은 간단한 테스트 사례를 적용한다면 저희의 월드 빌딩 툴안에서 일반적인 작업의 약 50%정도를 테스트할 수 있을 것입니다. 각각의 툴의 용도에 맞춰 테스트 사항들을 늘려 나간다면 QA 팀의 테스트 부담은 매우 줄어들겠죠.

==보정==

좋습니다! 코드는 완성되었고 테스트를 할 시간도 좀 있었습니다. 사용자들에게 툴이 배포되었군요. 사용자들은 모두 만족하고 있습니다. 그렇죠? 마무리 보정단계(polish phase)에서는 툴을 좀 더 사용하기 쉽고, 좀 더 빠르게 다듬어 가는 단계입니다. 이것을 하는 가장 좋은 방법중 하나는 내부적으로 사후 평가를 하는 것입니다. 사람들을 회의실에 모으고 복잡한 절차를 거치지 않고 불평 사항이나 개선 사항, 생산성에 있어 무엇이 가장 큰 문제인지 등을 물어보는 것입니다.

터빈은 애쉬론즈콜2:폴른킹스 개발 사이클이 끝날 즈음에 회사 내부에서 사용하는 도구 전체에 대해 사후평가를 실시했습니다. 게임을 출시하기 전에 이 사후평가를 함으로써 디자이너들이 수개월동안 곤혹을 겪어 왔으리라는 사실을 알아챌 수 있었습니다. 결국 저희는 애쉬론즈콜2의 기본 텍스트 컨트롤을 상당 부분 다시 작성해야 함에도 불구하고 게임 속의 텍스트를 쉽게 생성 및 편집할 수 있으며 로컬라이징까지 고려된 간단한 툴을 새로 만들었습니다.

자신이 작성한 툴을 스스로 실제 작업에 적용하여 사용해보는 것은 매우 중요합니다. 기능 추가를 완료한 후 사용자나 다른 개발자와 함께 유용성 테스트를 해봄으로써 툴의 개선에 필요한 좋은 피드백을 받을 수 있습니다. 사용자와 나란히 앉아 실제 툴을 사용하는 모습을 지켜보다 보면 어느 부분에서 개선이 필요한지 매우 쉽게 알아차릴 수 있을 것입니다. 저희는 마무리 공정 중 "고급사용자"들을 위해 자주 사용되는 기능들의 단축키와 툴바를 추가했습니다. 또한 다양한 서브루틴 안에서 걸리는 시간들의 스냅샷을 찍고, 그 결과들을 트리뷰로 출력해주는 타이밍 뷰어를 추가하였습니다. 이 도구는 상당한 양의 로딩 및 CPU처리가 일어나는 곳을 알 수 있게 도와주었으므로 최종결과물을 향상시키는데 큰 도움이 되었습니다.

==반복==
자, 이제 다 끝난건가요? 아닙니다. 저희는 5단계의 공정을 모두 거쳐왔습니다만 아직 완전히 끝난건 아닙니다. 이젠 감춰진 6번째 공정인 유지보수(iteration)를 시작할 때 입니다. 이 작업은 MMO 툴 작업에 있어 매우 중요합니다. 여러분의 업데이트 팀의 절반 가량이 아마 몇년동안 여러분의 툴을 사용할 컨텐츠 디자이너일 것입니다. 저희의 경험으로는 업데이트 팀의 예산과 개발자들은 툴 개발에 신경쓰지 않습니다. 게임이 출시되는 시점까지 완성된 도구를 업데이트 팀이 사용하게 되는 것이죠.

<div align="center">
http://www.galexandria.com/img/picturespaceholder.jpg

'''던전 앤 드래곤 온라인'''
</div>

AC2의 개발이 끝날 즈음에도 여전히 "툴 작업 리스트"에 있었던 구현되지 않은 요구사항들이 약 75개 이상 있었습니다. 다행히 게임 출시후에 약 3개월의 시간을 투자해 이 중에 일부 작업들을 끝마칠 수 있었습니다만 이 글을 쓰고 있는 시점에까지도 끝마치지 못한 작업들이 여전히 있습니다. 프로젝트에 따라 저희의 엔진은 많은 부분이 변경됩니다. 따라서 미들어스 온라인과 던전 앤 드래곤 온라인에 사용하는 툴도 AC2의 툴과 많은 차이를 가지게 되었습니다. 저희는 최근에 변경한 엔진 기능들을 다른 게임의 엔진에도 동시에 추가하려고 언제나 노력하지만 엔진의 기반이 바뀌거나 예산이 넉넉치 않을 경우 그럴 수 없는 경우도 있었습니다.

앞서 언급한 단계들을 이해하는데 도움이 될만한 예를 알려드리겠습니다. 이 예들은 저희의 월드 생성툴의 근래 요구 사항들을 몇가지 뽑아본 것입니다. 컨텐츠 디자이너는 마야나 포토샵에 있는 유사한 기능을 넣어주기를 원했습니다. 그 중의 하나를 말씀드리자면 선택된 엔티티들을 가시 레이어에 할당해서 그 레이어의 가시여부를 토글할 수 있는 기능입니다. 이렇게 하면 월드 생성 툴에서 비가시적으로 만들어진 엔티티와 레이어들이 엔진에서 그리지 않기 때문입니다. 다음은 요구사항 문서의 일부분 입니다.

: 요구사항 1 : 여러 작업공간(뷰화면,트리)에서 선택된 엔티티들을 레이어에 추가할수 있도록 "레이어에 추가" 메뉴 옵션을 새로 추가해주십시요. 이 메뉴 옵션은 마우스 오른쪽 버튼으로 실행할 수 있어야 합니다. 이때 레이어에 추가되는 엔티티들은 현재 레이어의 가시상태에 따라 보이거나 보이지 않게 될것입니다.

: 요구사항 2 : 사용자가 새로운 레이어 이름을 넣을수 있게 마우스 오른쪽 버튼을 클릭하면 메뉴에 "새 레이어" 옵션이 나오도록 추가해주십시오.

: 요구사항 3 : 마우스 오른쪽 버튼을 클릭하면 메뉴에 레이어의 리스트도 자동으로 나오게 해주셨으면 합니다.

: 요구사항 4 : 엔티티가 레이어에 하나라도 있다면 레이어에서 엔티티를 제거할수 있도록 마우스 오른쪽 버튼을 클릭하면 메뉴에 "레이어에서 제거" 옵션이 나오도록 해주십시오.

: 요구사항 5 : 하나 또는 하나 이상의 엔티티가 선택된 상태에서 "레이어에 추가" 를 선택하면 그 엔티티들은 레이어의 가시상태를 따르면 좋겠습니다.

위의 각 요구사항들은 하나의 명확한 문장으로 테스트가 가능합니다. 이것은 한번에 하나씩 테스트를 할 수 있도록 해줄뿐만 아니라 그 요구사항들을 테스트 하는 것을 쉽게 만들어 줍니다. 이 시점에 요구 사항들을 배포하고, 결제를 받은 뒤, 스케쥴을 결정합니다. 이 일을 위해 가시성 상태를 기억하는 클래스들을 비롯하여 새로운 메뉴와 대화상자를 만들었었습니다. 또한 가시성 상태를 데이타 파일에 저장하고 그 정보를 다시 로드할 수 있게 만들어 달라는 요구사항은 이 일을 더욱 복잡하게 만들었습니다.

다음 작업은 고수준 설계문서에 "이용 사례" 를 추가하는 것이었습니다.

:이용사례 1 : 사용자는 3D 워크스페이스에서 몇개의 엔티티들을 선택한 뒤 마우스 오른쪽 버튼을 눌렀습니다. 메뉴 맨 위쪽에 "새 레이어 추가" 옵션이 등장할 것입니다. "(레이어이름)에 추가"라는 메뉴옵션이 등장할 것입니다 여기서 "(레이어 이름)"은 이전에 만들어진 레이어 이름의 목록에 있는 각 레이어입니다. 마지막으로 "레이어에서 제거" 메뉴 옵션이 등장할 것입니다. (요구사항 1, 2, 3, 4)

:이용사례 2 : 사용자는 3D 워크스페이스에서 몇개의 엔티티들을 선택하고, 마우스 오른쪽 버튼을 눌러 "LayerA에 추가" 메뉴 아이템을 선택했습니다. 만약 LayerA 가 보임 상태라면 선택된 물체도 보임 상태로 전환됩니다. 반면에 LayerA가 안보임 상태라면 선택된 물체는 안보임 상태로 전환됩니다. LayerA는 이제 각 선택된 물체들의 가시성 상태를 가지고 있으며, VisibilityLayer 대화상자에 있는 트리뷰에서 LayerA가 각 엔티티 이름들을 자식노드로 가지고 있는 모습을 볼 수가 있습니다. (요구사항 5)

이용사례는 요구 사항 이상의 정보를 포함합니다. 이 요구사항들을 다시 설계와 매치시킬 수도 있습니다. 첫번째 이용사례는 처음 4가지의 요구사항을 포함하며, 두번째 이용 사례는 5번째 요구사항을 포함합니다. 요구사항에 굳이 번호를 붙일 필요는 없지만 그런 방법을 사용하면 모든 요구사항이 다 구현되었는지 확인하는데 도움이 될 것입니다.

이용사례들은 상세 설계문서에서 클래스/함수/모듈 수준으로 더욱 세분화 됩니다.


:이용사례 1 : 사용자가 3D 워크스페이스에서 몇개의 엔티티들을 선택한 뒤 오른쪽 마우스 버튼을 클릭했습니다.
:* 모든 기능들은 Wb3DWorkspace::BuildMenu에 있습니다.
:* 선택된 엔티티가 있는지 확인합니다. 그렇지 않다면 메뉴를 열지 않습니다.
:* "새 레이어 추가" 옵션을 더합니다.
:* LayerManager(새 클래스)로부터 VisibilityLayers(새 클래스)의 목록을 얻습니다.
:* 각각의 VisibilityLayer에 대해 레이어의 이름을 얻고 메뉴에 "(얻은 이름)에 추가" 옵션을 추가합니다.
:* "레이어에서 제거" 옵션을 추가합니다.

상세 설계단계에서부터는 최종적으로 코드안에 들어갈 클래스, 함수, 멤버 변수를 보기 시작합니다. 다음은 이용사례 1의 결과물로 나온 코드의 일부로서 터빈에서 사용했던 코드작성 표준을 살펴보실 수 있습니다.

<pre>
bool Wb3DWorkspace::BuildMenu( const bool& i_bSelection, Menu* io_pMenu )
{
  // LayerManager가 초기화되지 않았다면 메뉴를 만들 수 없다
  if( !m_pLayerManager )
  {
    return false;
  }
  // 메뉴가 존재하지 않는다면 아이템을 추가할 수 없다
  if( !io_pMenu )
  {
    return false;
  }

  // 아무것도 선택되지 않았다면 메뉴에 아무것도 추가할 필요 없음
  // 주의 : 이 경우는 에러가 아님!
  if( !i_bSelection )
  {
    return true;
  }

  // "새 레이어 추가" 라는 메뉴 아이템을 더한다
  io_pMenu->AddMenuItem( ADD_TO_NEW_LAYER_MENU_STRING,
                        ID_ADD_TO_LAYER );

  // 모든 기존 레이어를 메뉴 아이템으로 추가한다
  const SmartArray< VisibilityLayer* >& arrayLayers =
        m_pLayerManager->GetLayers();
  if( arrayLayers.count() > 0 )
  {
    int il;
    for( il = 0; il < arrayLayers.count(); ++il )
    {
      VisibilityLayer* pLayer = arrayLayers[ il ];
      if( pLayer )
      {
        io_pMenu->AddMenuItem( TEXT( "Add To %s" ),
                              pLayer->GetNameString(),
                              ID_ADD_TO_LAYER + il );
      }
    }
  }

  // "레이어에서 제거" 메뉴 아이템을 추가한다
  io_pMenu->AddMenuItem( REMOVE_FROM_LAYER_STRING,
                        ID_REMOVE_FROM_LAYER );
  return true;
}
</pre>
<div align=center>
'''사례 1'''
</div>

위 코드의 화이트 박스 테스트는 디버거 안에서 함수의 첫번째 줄에 브레이크 포인트(중단점)를 걸어놓고 입력 매개변수에 따라 어떤 결과값이 나오는지 한줄씩 실행시켜 봄으로써 완료할 수 있습니다. 간결함을 위해 assert함수와 같은 코드들은 위에서 보이지 않았습니다. 블랙 박스 테스트는 여러 사례들을 테스트 해봅니다. 물체를 선택한 상태와 그렇지 않은 상태에서 각각 오른쪽 버튼을 눌러보기도 하고 레이어를 만들고 없애보기도 합니다. 표시된 메뉴는 물체가 선택되었을때만 나오는지 그리고 존재하는 레이어가 있을때 메뉴에 현재 보임 상태인 레이어가 표시되는지 등을 면밀하게 검사합니다.



마무리 단계에서 저희는 LayerManager에 다음의 몇가지 기능을 추가했습니다. 여러 VisibilityLayer들을 넘나들면서 엔티티들을 드래그 앤 드롭할 수 있도록 변경했으며 LayerDialog에서 Visibility Layer 이름을 더블클릭 함으로써 가시성 상태를 토글할 수 있도록 했습니다. 추후의 요구사항의 수렴과 유지 보수를 통해 툴은 더욱 개선될 것입니다. 위의 예제가 지면관계상 조금 짧은 감은 있지만 그래도 이것을 통해 터빈이 툴에 대해 쏟는 노력과 그 형태를 조금이나마 엿볼수 있으셨을 것입니다.

MMO 게임을 만드는 일은 패키지 게임을 만드는 것 이상의 노력이 들어갑니다. 미래를 생각해야 하죠. 여러분의 개발 과정은 단지 게임만을 생각하는 것이 아니라 추후 게임을 끌고 나갈 업데이트 팀까지 고려해야 합니다. 디자이너들이 컨텐츠를 쉽게 추가 할 수 있는 도구를 만든다면 먼훗날 그 게임의 운영 및 수입에 큰 도움을 줄 것입니다. "1그램의 예방이 1킬로그램의 치료보다 낫다" 라는 옛말도 있듯이 여러분의 툴을 설계하는 도중에 문제를 제거할 수 있다면 훗날 도구가 완성된뒤 버그를 찾는 것보다 현저한 비용절감 효과가 있을 것입니다. 요구사항 취합에서부터 보정작업까지의 소프트웨어 개발론은 게임뿐만 아니라 툴 개발에 있어서도 매우 중요합니다. 현재 자신에게 잘맞는 소프트웨어 개발공정을 사용하고 계신지요?

== 번역문 정보 ==
* 초벌번역: 김민규
* 재벌번역: [[사용자:Pope | 포프]]
* 감수: [[사용자:Es | 이스]]

== 현재상태 ==
* 초벌번역완료 (2005년 9월 10일)
* 재벌번역완료 (2005년 10월 1일)
* 감수완료 (2005년 10월 1일)

[[분류: 도구(가마수트라)]]
[[분류: 도구]]
[[분류: 도구(번역)]]
[[분류: 가마수트라]]

Comments