2025년 가장 뜨거운 게임을 하나 꼽으라면 <클레르 옵스퀴르: 33 원정대>를 언급하는 게이머들이 정말 많을 것이다. 전통의 답습에서 그칠 수 있는 턴제 장르에 회피, 패링 등 실시간 반응 요소들을 넣고, 이 시스템과 관련된 긴장감과 보상을 극대화해 전투의 재미를 크게 끌어올렸다는 평을 받은 작품이다.
스토리의 깊이와 영화 뺨 치는 화려한 컷씬 연출, 어렵고 복잡한 듯 하면서도 계속 돌아보고 상호작용하게 만드는 월드 구성도 마찬가지다. 정교한 동시에 압도적이고 방대해서 게임을 직접 해본 사람들은 극찬을 아끼지 않곤 했다.
사람들이 <클레르 옵스퀴르: 33 원정대>의 개발 비화에 한 번 더 놀라게 된 이유 중 하나는, 핵심 개발진이 30명 내외로 작품의 규모에 비해 말도 안 되게 적은 인원이 게임을 만들었다는 사실 때문이다. 심지어 프로그래머만 따지면 4명뿐이다. 레벨 디자이너 등을 포함한 디자이너도 3~4명 규모다.
핵심 개발진 외에도 애니메이션 제작을 담당했던 한국 애니메이터 등 외주 협업 인원들이 있었다곤 하지만, 콘솔 포팅 작업 정도 외에는 게임플레이에 대한 개발은 모두 4명의 프로그래머가 전담했다고 한다. 이게 어떻게 가능했던 것일까. 개발자 컨퍼런스 데브컴에서 샌드폴 인터랙티브의 플로리안 토레스 프로그래머가 그 비결에 대해 소개했다. /독일=디스이즈게임 김승준 기자
▲ <클레르 옵스퀴르: 33 원정대>를 만든 핵심 개발자 30여 명 중 프로그래머는 고작 4명뿐이다. 프로그래머 4명끼리도 전투, 탐험, 진행, 엔진 관련 등 서로 다른 역할을 담당하고 있다.
▲ 이런 효율적인 개발을 할 수 있던 비결에 대해 플로리안 토레스 프로그래머가 직접 소개했다.
블루프린트로 95%를 만든 게임?
샌드폴 인터랙티브가 그렇게 영리하게 선택한 도구는 언리얼 엔진 안에 있는 비주얼 스크립팅 시스템인 ‘블루프린트’였다. 게임 디자이너와 아티스트가 C++ 코드를 작성하지 않아도 노드를 연결하는 방식으로 게임 로직에 대해 서로 쉽게 소통할 수 있는 도구였기 때문이다.
게임 개발 기간 중에 언리얼 엔진 4.21 버전에서 5.4.4버전까지 활용하면서 여러 장단점을 몸으로 직접 느꼈다고 한다. ‘블루프린트’ 덕분에 프로토타이핑과 이터레이션 과정이 매우 빨라졌다.
프로그래머의 구현을 기다릴 필요 없이 디자이너가 직접 구체적인 테스트까지 진행할 수 있었다. 프로그래머들이 최적화와 코어 시스템에 집중하는 동안, 다른 세부적인 시스템을 다른 인원들이 함께 개발하면서 작업 부하도 줄었다. 서로 다른 파트끼리의 소통도 더 원활해졌다. C++에서 흔히 발생하는 널 포인터(Null Pointer) 관련 게임 크래시도 블루프린트에선 거의 일어나지 않아 안정성도 높다.
그러나 잘 알려져있듯 블루프린트는 C++ 코드에 비해 실행 속도도 느리고, 최적화와 디버깅이 어렵다. 또한 노드끼리 선으로 연결하는 방식이 직관적이지만, 시스템이 복잡해질수록 이 연결도 엉킨 스파게티처럼 복잡해져 구조적으로 유지보수가 어렵다는 단점도 있다. 엔진의 기본적인 기능 안에서 움직여야 했고, 바이너리 데이터라서 동시에 두 명이 같은 파일을 작업할 수 없다는 문제도 있었다.
이를 위해 C++과 블루프린트를 함께 사용하는 전략을 채택하면서, 꼭 필요한 부분에서는 C++을 사용하고, 다른 대부분의 시스템은 블루프린트를 활용하는 방식으로 이 장단점을 어느 정도 상쇄했다. 재밌는 점은 그렇게 일부 부분에서 C++을 사용하면서도 게임의 95% 이상을 블루프린트로 만들었다는 것이다. 블루프린트를 활용하는 ‘장점’을 더 크게 생각했음을 알 수 있는 대목이다.
▲ 블루프린트는 저런 식으로 노드를 연결해 로직을 만드는 언리얼 엔진 내부의 기능이다.
▲ C++은 프로그래머들이 불가피하게 사용할 때만 활용했다. 게임 디자이너, 아트 등 다른 파트의 인원들도 모두 블루프린트를 함께 활용하며 각자의 의견을 바로 반영하고, 서로의 부담을 덜어냈다.
개발팀에겐 3가지 핵심 원칙이 있었다
1. 바퀴를 다시 발명하지 마라 (Do not reinvent the wheel) 개발팀은 이미 엔진이 제공하는 검증된 기능들을 최대한 활용했다. 자체 시스템을 고집하기보다, 기존 도구를 창의적으로 응용해 원하는 결과물을 만드는 데 집중하며 개발 시간을 극적으로 단축했다. 플러그인을 사용하는 과정에서도 UMG 대신 ‘Common UI’로 기본 UI를, Wwise 대신 ‘Metasound’로 오디오를 구축하는 등 적극적인 선택을 이어갔다.
2. 더 적은 자원으로 더 많은 것을 (Make more with less) 팀의 가장 중요한 신조였다. 4명의 프로그래머라는 절대적인 한계 속에서, 팀원 모두가 '개발자' 역할을 수행해야 했다. 블루프린트는 디자이너와 아티스트에게 코딩 능력을 부여하는 날개가 되어주었고, 팀 전체의 생산성을 극대화하는 결과를 낳았다. 한정된 자원을 탓하기보다, 가진 것을 어떻게 활용해 최대의 결과를 낼지 끊임없이 고민했다.
3. 싸워야 할 곳을 현명하게 선택하라 (Choose your battles) 소규모 팀에게 가장 중요한 것은 선택과 집중이다. 개발팀은 게임의 핵심 재미와 직결되는 부분, <클레르 옵스퀴르: 33 원정대>만의 독특한 경험을 제공하는 시스템에 개발력을 집중했다.
그래서 구체적으로 어떻게 이 환경을 활용했을까
블루프린트가 이어준 협업 방식은 꽤 인상적이다. 전투 버프 시스템이 대표적인데, 프로그래머는 ‘버프’의 바탕이 되는 “턴 시작 시”, “피해를 입을 시”와 같은 이벤트 조건만 제공했다. 게임 디자이너는 여기에 “화상” 같은 블루프린트를 만들어 살을 붙이고, 이벤트에 맞춰 “체력을 깎는다”, “행동을 막는다”와 같은 결과로 로직을 스크립팅한다. 디자이너가 상상한 대로 플로우를 만드는 게 어렵지 않은 환경이었다.
조건 검사기(컨디션 체커)를 한가득 만들어 공유한 것도 유용한 방법이었다. 프로그래머가 발생할 수 있는 거의 모든 경우의 수에 대한 기본 조건들을 정리해 우측에 체크 박스를 마련해두면, 특정 퀘스트를 완료했는지 여부 등을 체크하며 게임 디자이너가 “컷씬 재생”, “전투 시작” 같은 행위로 연결한다. 순서대로 조합하는 것만으로 원하는 이벤트 흐름을 함께 만들어낸 셈이다. 다만, 이런 환경을 미리 만드는 초기 개발 시간이 오래 걸린 단점이 있긴 했다.
▲ 화면 우측에 빼곡하게 나열된 '체크 박스'가 보이시는가.
높아진 개발 자유도만큼 디버깅 및 유지 보수를 위한 안전책도 꼭 필요했다. 한 번 엉키기 시작하면 이를 뒤늦게 고치기 어려운 환경이었기 때문이다. 그래서 처음엔 로그 파일에 문제가 되는 부분을 다른 색상으로 표시하고, 화면에 텍스트 경고도 출력했다. 하지만 다른 UI에 가려져 놓치는 경우가 잦았고, 결국 심각한 오류들에는 프로그램을 일시 중단하는 블로킹 팝업 경고까지 사용했다.
‘널 포인터’와 만나도 멈추지 않는 블루프린트 특성이 버그를 찾기 어렵게 해주는 원인이 되는 사례도 발견해, 널 객체 접근 시 실행을 중단하는 옵션도 활성화했다. 이런 과정을 통해 프로그래머 외에도 디자이너, 아트, QA 등 다른 파트의 인원들도 문제 상황을 무시하고 지나가지 않는 구조를 마련했다.
▲ 디버깅 과정을 게임처럼 시각화해 보여주기도 했다.
단점을 극복하기 위한 시간적 경제적 비용이 없었던 것은 아니지만, 결과적으로 소규모 팀이 제한된 시간과 리소스만으로도 서로의 역량을 최대로 끌어올리며, 오히려 다른 개발팀이 쉽사리 해내지 못했던 자유로운 협업 환경을 만들어낸 독특한 사례가 된 셈이다. 연단에 선 플로리안 토레스 프로그래머는 이렇게 말했다.
“저희는 게임 디자이너들을 신뢰했고, 디자이너들은 저희가 시스템의 바탕을 설계할 때 생각지도 못했던 놀라운 것들을 매번 만들어냈습니다.”
