• 주제 : Try & Error - 대항해시대 오리진의 시행 착오 개발기
  • 강연자 : 이득규 / 디렉터
  • 분야 : 게임 디자인
  • 시간 : 2022.11.18(금) 15:00 ~ 15:50
  • 요약 : 2017년 11월 11일 모티프 법인 설립 후, 2018년 11월 30일부터 현재까지 '대항해시대 오리진'이 개발되어 온 과정을 되짚어보며, 어떤 시행착오를 거쳐 서비스까지 이르게 되었는지 살펴보는 시간을 가집니다.



  • ■ Out Game Side: 개발이 오래 걸린 이유


    '대항해시대 오리진'의 원래 2020년 12월 출시를 목표로 했었다. 하지만 타이슨도 그런 말을 하지 않았던가. "누구나 그럴싸한 계획을 가지고 있다. 맞기 전까지는" 이라고. '대항해시대 오리진'도 마찬가지였다. 2020년 12월 출시가 목표였는데 1차 CBT를 2021년 1월에 했으니 이때부터 계획과는 크게 멀어졌다. 그렇게 시간이 흘러 1년 5개월이 밀려서 2022년 8월 23일 정식 출시를 하게 됐다.

    '대항해시대 오리진'이 이렇게까지 오래 걸린 데에는 여러 가지 이유가 있다. 대부분은 경험 부족으로 인한 실수로 여러 시행착오를 겪는 과정에서 발생하는 자연스러운 실수였지만, 예기치 못한 인재와 천재지변도 겪었다.

    이득규 디렉터에게 있어서 모티프는 두 번째로 창업한 회사다. 다른 개발자들과 마찬가지로 그 역시도 만들고 싶은 게임을 만들기 위해 회사를 창업했다. 외부의 간섭 없이 원하는 게임을 만들고 싶은 마음에서 창업하다 보니 당연히 투자를 받지 않았고 투자를 받지 않으니 돈이 없어서 사람을 구하는 일 등 금전적인 어려움에 직면했다. 다행스럽게도 그 시기 그에게 넥슨에서 '삼국지조조전 온라인'을 맡아달라는 연락이 왔고 그렇게 넥슨에 들어감으로써 그의 첫 번째 창업은 실패로 마무리됐다.

    그래도 '삼국지조조전 온라인'은 여러모로 좋은 피드백을 받았다. 자신감을 얻은 그는 차기작으로 대항해시대 IP를 만들고 싶었다. 실제로 넥슨에서 IP 협상 시도를 하기도 했지만, 여러 이유로 넥슨에서는 만들지 않는 거로 결론이 났다. 자신이 원하는 게임을 만들기 위해서는 회사를 떠나야 하는 상황. 이득규 디렉터는 지금이 그런 도전을 할 마지막 기회라고 여기고 결국 넥슨을 떠나 모티프를 창업했다.


    첫 창업의 실수를 반면교사 삼아서 이번에는 투자를 받고 사업을 진행했다. 하지만 문제는 또 있었다. 원하는 게임을 만들고 싶어서 한 창업이지만, 대표로서 해야 할 일이 너무 많았다. 대표 업무에 집중하다 보니 개발에 소홀할 수밖에 없었고 그 결과 개발 일정에도 악영향을 끼쳤다. 이득규 디렉터도 처음 겪는 상황이었다.

    물론 그것 때문만은 아니었다. 일정이 지연된 가장 큰 원인은 구인난 때문이었다. 필요할 때 필요한 만큼만 뽑을 생각이었는데 회사가 필요한 사람들이 타이밍 좋게 있을리가 없다. 여기에 개발자들 연봉이 한창 오르던 시기여서 이제 막 창업한 신생 개발사에 오려는 사람도 적었다.

    천재지변도 겪었다. 모두가 겪은 코로나19 사태였다. 안 그래도 사람이 없어 힘든데 제대로 채용을 할 수가 없었다. 채용 과정에서의 어려움도 있었지만, 개발 과정에서의 문제도 있었다. 첫 번째는 유대감에 대한 부분이었다. 아무래도 원격으로 근무하다 보니 유대감이 생기질 않았다. 전달 과정에서 문제가 발생하기도 했다. 전화나 채팅 등 비대면으로 의견을 나누다 보니 '어? 이거 이렇게 하라고 한 거 아니었어요?', '네? 이렇게 하라고 한 건데요?' 하는 경우가 더러 있었다. 결국, 작업을 또 해야 했고 이런 게 일정을 더 늘리는 원인이 됐다.


    고전 IP라는 점 역시 발목을 잡았다. 기획서를 종이에 손으로 쓰던 시절의 게임이어서 자료가 남아있질 않았다. 한글판 데이터는 테이프 백업 데이터가 손상되어서 읽을 수도 없었고. 어쩔 수 없이 일본어 버전의 소스 코드를 분석하고 번역해서 개발하는 수밖에 없었다.

    신생 개발사였던 만큼, 도전하고자 하는 욕구가 문제가 되기도 했다. '삼국지조조전 온라인'을 개발할 당시에는 이미 계약 납기일을 초과해서 최대한 아는 기술, 해본 기술, 검증된 솔루션을 바탕으로 빠르게 개발하는 데 집중했었다. 하지만 '대항해시대 오리진'은 당시에는 그래도 시간이 있었기에 스튜디오의 기술 축적을 중시해 필요하다면 연구 개발을 우선시하는 쪽으로 방향을 정했다. 실수였다. 서로 손발을 맞춰본 경험도 없었던 만큼, 커뮤니케이션을 구축하는 데만도 꽤 많은 시간이 들었다.

    목업(Mockup)을 만든 후 개발하는 방식 역시 문제가 됐다. 개발 중반까진 UI/UX 목업을 먼저 설계하고 검증한 후 안정화되면 구현하는 방식을 썼었는데 목업이 안 끝나면 개발을 할 수 없는 상황이 발생했다. 여기에 목업을 만드는 사람과 UI를 작업하는 사람이 다르니 결과물이 목업과 다르거나 목업대로 만들면 성능이 나오려면 구조가 바꿔야 해서 다시 작업하는 경우도 있었다. 결과적으로 기능 하나를 만들어서 플레이할 수 있게 만들기까지의 시간이 점점 장기화됐다.

    사전 검증 후 개발하면 재구현하는데 들이는 시간이 줄어들 테니 개발 시간을 줄일 수 있겠다는 생각에 시도한 방식이 오히려 문제가 된 거였다. 담담히 설명을 이어가던 이득규 디렉터는 "그냥 빨리 플레이할 수 있도록 한 다음에 문제를 고치는 게 더 빨랐을 것"이라고 소회했다.

    언리얼 엔진을 쓴 것에 대해서는 일장일단이 있다고 설명했다. 유니티는 나름 개발 경험도 많고 자신도 있었으며, 구인도 쉬운 편이었다. 하지만 유니티로 개발할 당시 한계를 경험했기에 다른 대안을 찾고 싶었고 이에 자연스럽게 언리얼 엔진에 눈이 갔다. 노하우는 적더라도 문제가 발생하면 소스 코드를 공개했으니 자유롭게 뜯어볼 수도 있으니 괜찮겠지 하고 언리얼 엔진을 선택했다. 문제는 다 좋았지만, 유니티와 비교했을 때 추가 개발 기간이 매우 많이 필요하다는 점이었다.

    간단한 구현도 인력, 시간, 난이도 모두 공수가 더 많이 필요했으며, 엔진을 뜯어고쳤더니 언리얼 엔진을 업데이트하면 문제가 발생하는 경우도 있었다. 결국, 엔진 업데이트 및 유지보수에 쓴 개발 기간만 물리적으로 1년을 초과했다. 엔진을 많이 뜯어고치니 버전 업데이트 시에 따로 작업해야 할 것도 많았고 서드 파티 플러그인이나 SDK 동작 문제를 해결하는데에도 상당한 시간이 소요됐다.


    BM도 싹 뜯어고쳤다. 원래는 확률형 상품 없는 BM으로 기획했었는데 협의 끝에 확률형 상품을 넣게 되었다. 그런데 CBT에서 부정적인 얘기를 많이 들었다. 결국, 다시 원래대로 돌아왔다. 결론적으로 BM을 세 번이나 바꾼 셈으로 그 과정에서 BM 및 밸런스를 수정하는 추가적인 작업을 해야 했다.

    중국 판호 심사와 일본 서비스를 고려해서 리소스를 수정하는 데에도 많은 공수가 들었다. 잘 됐다면 아무 문제 없었겠지만, 판호 심사 빌드 준비까지 마쳤던 게 최종적으로 시국이 좋지 않아 심사를 포기했다. 결국, 시간만 허비한 셈이 됐다. TGS 출품 역시 부담이 됐다. 예정에 없다가 갑자기 출품하게 되어 영상 제작 및 리테이크에만 1.5개월이 들었다. 그 외에도 서비스 직전까지 분쟁 요소의 최소화를 위해 리소스를 따로 만드는 등 수정을 지속했다.

    사고도 있었다. 반도체 대란은 애교고 업계에서 전설처럼 내려오는 이야기의 당사자가 되기도 했다. 신규 채용한 분이 모르고 서버실 에어컨을 꺼서 서버가 다 터진 사건이었다. 문제는 그걸 보고하지도 않고 몰래 해결하려고 했다는 점이다. 몰래 AS를 받았는데 비싸니까 장비를 하위 등급으로 내렸다. 어느 순간부터 개발할 때 퍼포먼스가 안 나와서 왜 그런가 해서 업체에 연락하니까 서버를 바꿨다고 해서 그 내막을 알게 됐다. 여러모로 충격적인 사고였다.

    어쩌다보니 회사를 자주 이전하게 됐는데 이럴 때면 항상 직접 서버를 옮겼던 이득규 디렉터였지만, 그때는 하필 다른 사람에게 맡긴 일이 있었다. 그런데 그 스토리지 서버를 발로 차서 서버가 나가는 말도 안 되는 사건이 터진 적도 있었다. 20테라에 달하는, 3년 동안 개발한 모든 리소스가 들어간 서버였다. 당시를 회상하며 이득규 디렉터는 "일주일 동안 집에도 안 들어가고 기도하는 마음으로 사무실에 살다시피 했는데 운 좋게도 복구할 수 있었다. 결과적으로 일정이 일주일 정도 밀렸는데 수명이 깎이는 느낌이었다"라며, 당시를 생각하면서 가슴을 쓸어내렸다.

    지난 10월에는 위층 에어컨에 물이 샌다고 '대항해시대 오리진'을 개발하던 개발팀이 있던 층의 전기를 갑자기 끊는 일도 있었다. 이에 이득규 디렉터는 일정상 20% 정도는 여유를 잡았는데도 소용없었다고 술회했다.




    ■ In Game Side: 시행착오와 실패 사례


    본격적으로 게임을 개발하면서 구상한 기획을 실체화하는 과정에서도 수많은 시행착오를 거듭했다. '대항해시대 오리진'은 구형으로 만들어져 있는데 항해를 할 때는 썩 괜찮은 모습이었다. 문제는 도시였다. 구형의 세계 위에 도시를 올리니 렌더링은 많이 쓰지 공간 인지는 안 되지 예쁘지도 않았다. 주변에서 모두 이건 하지 말자고 했지만, 3개월만 더 해보자고 했다. 노력했는데도 안되더라. 3개월만 더 해보자고 했다. 안되더라. 결국, 그렇게 9개월을 허비했다.

    동적 라이팅을 구현하는 것도 쉽지 않았다. 보통 라이트매스를 쓰지만, 실시간 그림자, 라이팅 변화가 어렵고 개발 중 베이킹 시간이 오래 걸리는 문제도 있어서 동적 라이팅을 쓰자고 결론을 내렸다. 그런데 테스트를 해보니 목표 사이즈가 2기가였는데 라이트맵이 수 기가가 넘는 상황이 발생했다.

    용량과 비전을 위해 실시간 라이팅을 적용할 방법이 필요했는데 고민 끝에 모바일 디퍼드 렌더링을 만들었다. 개발 초기에 에픽 코리아에 기능 구현을 문의했는데 안 할 거라고 해서 직접 만들었다. 여기까지 설명하면서 이득규 디렉터는 "아마도 세계 최초의 상용 모바일 디퍼드 렌더링 적용 사례가 아닐까 싶다"고 전했다.


    하지만 PBR 2D 노멀맵 라이팅은 실패했다. 2D 캐릭터를 입체감 있게 만들기 위해서 라이팅 하고자 했는데 좌우 이미지를 각각 작업하지 않으면 한쪽에서만 성립했으며, 메모리가 많이 필요했기에 결국 포기했다.

    멋진 세계를 구축하기 위해 항해 지형 랜드스케이프와 식생 자동 배치를 도입하려고 했지만, 이 역시 실패했다. 항해 지형 랜드스케이프의 경우 샘플 제작을 해보니, 컬리전 데이터만 최소 8GB 이상이 필요할 것으로 예상됐다. 결국, 메시로 일일이 배치해 구성했다. 식생 자동 배치 역시 마찬가지다. 지형에 풀이나 나무를 일일이 심는 건 고단한 일이라 고도와 지형 경사, 텍스쳐 정보를 기준으로 식생 자동 배치 시스템 도입을 검토했다. 프로토타입은 나쁘지 않았지만, 저사양 기기에서 성능 문제가 발생해 결국 랜드스케이프 사용을 포기하면서 같이 제거하고 수동 배치로 진행하기로 했다.


    이외에도 에픽에서 적극적으로 권장한 최적화 방법으로 항해 지형에 HLOD를 도입하려고 했지만, 용량 문제로 도입을 포기했다. 전투 지형 최적화는 랜드스케이프, HLOD, 인스턴스 병합, 액터 병합 + 메시 분할 등 다양한 방법을 시도했지만, 원하는 만큼 최적화가 이뤄지지 않았다. 결국 액터 병합 + 맵 크기를 75%로 축소한 끝에 용량은 25% 증가했지만, DP Call은 50%나 감소하는 성과를 낼 수 있었다.

    '대항해시대 오리진'은 바다에 있는 시간이 많다. 당연히 이득규 디렉터도 바다 환경 표현을 소위 목숨을 걸었다. 그냥 화면을 보는 것만으로도 해류, 파도, 바람을 알 수 있길 바랐다. 이러한 바다 환경을 표현하기 위해서 먼저 빅데이터를 활용했다. 실제 환경 데이터를 게임에 그대로 구현하는 것으로 태풍이 제주도 앞바다에 있다면, 게임에서도 같은 상태가 되도록 하는 게 목표였다. 그런데 이런 데이터는 생각보다 크고 비쌌다.

    그럼에도 실제 환경 데이터는 꼭 쓰고 싶었다. 여러 차례 타협을 거친 끝에 '대항해시대 오리진'은 게임 내에 쓰일 환경 데이터를 마련할 수 있었다. 그렇게 열심히 만들었고 시간도 많이 쓰고 개선도 많이 한 환경 데이터였지만, 항해 속도 변화가 체감되는 정도였고 안타깝게도 정작 게임 내에서 티가 나진 않았다. 전투에서도 마찬가지였다. 충무공의 역사적 해전이나 해류 등 환경과 지형이 영향을 많이 준 이벤트 전투 개발에 도움이 될 거로 생각했지만, 대부분 이를 인지하지 못했다.


    메모리 사용량을 개선하기 위해서 Offline File DB, Couchbase Lite, SQLite3 등 다양한 방법을 도입하고자 했으나 하나씩 문제가 있었다. 결국, SQLite3 도입과 별개로 Chunk 분할 테이블을 활용해서 문제를 개선했다. 하지만 시간이 든 만큼의 극적인 개선은 없어 아쉬움이 남았다고 덧붙였다.

    항해시 길찾기 성능 문제도 빼놓을 수 없다. 항해 지형이 너무 커서 최장 거리 경로 탐색 시 PC는 수 초, 모바일은 수십 초에서 몇 분이나 걸리는 경우가 많았다. 이 문제는 항해하며 연산하도록 대응해 타협했다. 원치 않게도 생긴 문제도 있다. 플랫폼 별로 상이한 패치 시스템이 그것이다. '대항해시대 오리진'은 현재 스팀, 플로어, iOS, 안드로이드 무려 4개의 플랫폼을 지원하는데 플랫폼 별로 패치 시스템이 다르기에 각각의 패치 시스템을 구축해야 했다.


    실패만 있던 건 아니었다. 스크립트 시스템을 도입한 덕분에 매번 컴파일할 필요가 없게 되어서 일정을 많이 줄일 수 있었으며, 게임 내에서 각종 오류가 발생하면 다양한 형태로 오류 리포트 취합하고 분석하는 시스템을 구축해 큰 문제부터 빠르게 해결할 수 있도록 했다. 이외에도 Oodle Compression과 머신 러닝을 도입한 덕분에 용량이나 품질을 올리는 데에 걸리는 시간을 많이 줄일 수 있었다.


    개발 일정이 늘어진 이유와 그간의 시행착오를 담담히 전하며, 이득규 디렉터는 끝으로 "'대항해시대 오리진'이 오랫동안 재미를 제공하는 게임이 되길 바라는 마음에 많은 시도를 했던 것 같다"라며, "게임을 통해서 사회에 좀 더 긍정적인 변화나 영향력을 갖출 수 있는 게임이 나오길 바란다"고 전했다.