게임 엔진 없이 게임 만들던 시절, 엔진이 남의 집 살림이 되면 생기는 일

BioWare가 문을 닫는다는데, 이유를 경영진 탓으로만 돌리면 반만 본 거다. 개발자 입장에서 같이 볼 게 하나 더 있다. 엔진이다.

먼저 밝혀둘 게 있다. 원문 기사는 폐쇄 소식과 감원 규모, EA의 로드맵을 다루는 뉴스이고, 엔진 이야기는 한 줄도 없다. 그러니 이 글은 “기사가 엔진 때문이라고 했다”는 글이 아니다. 기사를 계기로 게임 엔진이 어떻게 생겼고, 왜 한번 고르면 발목을 잡는지를 개발자 시점에서 풀어 보는 글이다. 기사에서 가져온 사실과 내 해설은 구분해서 쓰겠다.

게임 엔진은 “그리기, 입력, 물리, 리소스 관리”를 매번 새로 짜기 싫어서 쌓아 올린 재사용 덩어리다. 엔진을 직접 만들면 통제권이 생기지만 유지비가 영원히 따라붙는다. 사서 쓰면 빠르지만 남의 로드맵에 묶인다. BioWare가 어떤 엔진을 거쳤고 그 비용이 얼마였는지는 이번 기사로는 확인하지 못했다. 아래 엔진 이야기는 일반론으로 읽어라.

엔진이라는 말이 없던 시대

초창기 게임은 게임마다 처음부터 다 짰다. 화면에 점 찍는 코드, 키보드 읽는 코드, 시간 재는 코드가 전부 게임 하나 전용이었다. 요즘 감각으로 비유하면 요리 한 접시 만들 때마다 가스관부터 깔고 칼부터 벼리는 셈이다.

그래서 다음 게임을 만들 때 하는 일은 이전 프로젝트 폴더를 통째로 복사해서 필요 없는 부분을 지우는 것이었다. 재사용이라고 부르기엔 민망한 수준이다. 복사본은 원본과 따로 늙는다. 원본에서 버그를 고쳐도 복사본에는 반영되지 않으니, 같은 버그를 게임 수만큼 다시 고치게 된다.

“그럼 그때는 게임이 구조 없이 막 짜여 있었나?” 하는 의문이 들 수 있다. 아니다. 이때도 모든 게임이 공통으로 가진 구조가 하나 있었다. 게임 루프다. 입력을 읽고, 상태를 갱신하고, 화면에 그리고, 이걸 계속 반복한다. 영화가 정지 사진을 빠르게 넘기는 것처럼, 게임도 “지금 상태”를 그려 낸 한 장을 초당 수십 번 갈아 끼우는 물건이다. 일반 앱은 사용자가 뭘 눌러야 움직이지만 게임은 아무도 안 건드려도 시간이 흘러가야 해서, 이벤트를 기다리는 대신 루프를 계속 돌린다.

그 방식 그대로 만들어 보기

아래는 고정 시간 간격으로 상태를 갱신하는 가장 단순한 루프다. 화면 대신 콘솔에 출력한다.

# Python 3.x, 표준 라이브러리만 사용
import time

STEP = 1 / 30                      # 갱신은 1/30초 단위로 고정
state = {"x": 0.0, "hp": 100.0, "t": 0.0}

def update(s, dt):
    s["x"] += 2.0 * dt             # 캐릭터가 오른쪽으로 이동
    if s["x"] > 3:                 # 3칸 넘으면 함정 구역
        s["hp"] -= 10 * dt

def render(s):
    print(f"t={s['t']:.1f}  x={s['x']:.1f}  hp={s['hp']:.0f}")

acc, prev, shown = 0.0, time.perf_counter(), -1
while state["t"] < 3.0:
    now = time.perf_counter()
    acc += now - prev
    prev = now
    while acc >= STEP:             # 밀린 시간만큼 갱신을 따라잡는다
        update(state, STEP)
        state["t"] += STEP
        acc -= STEP
    if int(state["t"] * 2) != shown:   # 0.5초마다 한 번 출력
        shown = int(state["t"] * 2)
        render(state)
    time.sleep(0.005)

코드에서 눈여겨볼 건 acc다. 컴퓨터가 느려서 한 바퀴가 오래 걸리면, 그 사이 흐른 시간이 acc에 쌓이고 안쪽 while이 밀린 만큼 갱신을 여러 번 몰아서 한다. 그리는 속도와 상태가 움직이는 속도를 떼어 놓은 거다. 이걸 안 하면 성능 좋은 PC에서는 캐릭터가 빠르게, 느린 PC에서는 느리게 움직인다. 이 정도는 엔진이 대신 해주는 대표적인 일이다.

그런데 이 샘플로 작은 게임 하나는 돌아가도, 커지는 순간 아픈 지점이 줄줄이 나온다.

• 함정, 이동 속도 같은 규칙이 update 안에 하드코딩돼 있다. 규칙이 늘면 if가 끝없이 늘어난다. 규칙을 바꾸려면 코드를 고치고 다시 실행해야 하니 기획자가 실험하기도 어렵다.
• 캐릭터가 하나만 있다는 가정이다. 100개가 되면 상태 관리부터 다시 짜야 한다.
• 대사, 선택지, 퀘스트 같은 RPG 데이터는 이 구조에 자리가 없다. 전부 코드에 박아야 한다. 대사 한 줄 고치려고 빌드를 다시 돌리는 상황을 상상해 봐라.

세 번째 항목은 뒤에서 다시 나온다. 이야기가 많은 RPG일수록 이 지점이 비싸지기 때문이다.

그래서 어떻게 굳어졌나

flowchart LR
    A["게임마다 처음부터"] --> B["공통 코드 라이브러리화"]
    B --> C["엔진 + 툴 분리"]
    C --> D["상용 엔진 라이선스"]
    C --> E["사내 엔진"]

위 그림은 왼쪽에서 오른쪽으로 읽는다. 마지막에 길이 둘로 갈라진다는 게 핵심이다. 각 칸이 왜 다음 칸으로 넘어가는지 하나씩 보자.

첫 번째 단계는 코드 복붙이 지겨워서 공통 부분을 라이브러리로 뽑는 것이다. 이러면 중복은 줄고 버그도 한 곳에서 고치게 된다. 하지만 아직 프로그래머만 건드릴 수 있다. 레벨을 하나 옮기려 해도 기획자가 프로그래머를 불러야 한다. 병목이 코드 중복에서 사람으로 옮겨 갔을 뿐이다.

두 번째 단계는 데이터와 툴을 분리하는 것이다. 맵 에디터, 스크립트, 리소스 파이프라인이 생기고 기획자와 아티스트가 직접 콘텐츠를 만들게 됐다. 위 샘플 코드로 치면 update 안에 박힌 규칙과 대사를 코드 밖 파일로 빼낸 거다. 대신 대가가 있다. 엔진과 툴이 거대해지고, 그걸 돌보는 전담팀이 필요해졌다. 게임을 만드는 팀 옆에 게임 만드는 도구를 만드는 팀이 생긴 거다.

세 번째 단계는 그 전담팀 비용을 아끼려고 엔진을 사서 쓰는 것이다. 90년대 후반부터 Unreal 같은 엔진이 라이선스로 팔렸고, 2000년대 중반에는 Unity도 나왔다. 집을 직접 짓는 대신 전세를 구하는 것과 비슷하다. 입주는 빠르지만 벽에 못 하나 박을 때 집주인 눈치를 봐야 한다. 엔진이 안 맞는 장르를 만들 때는 구조를 뜯어고쳐야 하고, 엔진 회사의 방향이 곧 내 일정이 된다.

네 번째 단계는 대형 퍼블리셔가 엔진을 사내에 두는 것이다. EA의 Frostbite가 대표적이다. 원래 DICE가 슈팅 게임용으로 만든 엔진이다. 같은 그룹이니 한 번 만든 기술을 여러 스튜디오가 나눠 쓸 수 있다는 논리다. 전세와 자가의 중간, 회사 사택쯤 된다. 다만 사택은 회사가 정한 구조대로 살아야 한다.

“왜 다 상용 엔진 하나로 안 모이나?” 싶을 수 있다. 엔진은 만든 쪽이 가장 잘 만들 수 있는 장르에 최적화되기 마련이라서 그렇다. 수수료와 로드맵 종속이 싫은 회사는 비용을 내고라도 자기 엔진을 들고 간다. 아래 표는 그 거래를 한눈에 정리한 것이다.

방식	장점	한계
게임마다 직접	완전한 통제	매번 재발명
자체 엔진	장르에 최적화	엔진팀 유지비
상용 엔진	빠른 시작, 인력 풍부	로드맵 종속, 수수료
퍼블리셔 사내 엔진	그룹 내 기술 공유	다른 장르엔 안 맞을 수 있음

지금은 어떤가

여기부터는 기사에서 확인한 것과 못 한 것을 나눠서 쓴다.

기사에서 확인한 것. BioWare는 30년 넘게 이어 온 스튜디오이고 Baldur’s Gate, Neverwinter Nights, Knights of the Old Republic, Dragon Age, Mass Effect, Anthem을 만들었다. EA는 폐쇄와 함께 개발 초기였던 다음 Mass Effect 프로젝트도 접는다. Bloomberg에 따르면 감원은 약 400명이고 BioWare에서는 약 50명이다. 기사는 최근 부진의 이유로 2017년 Mass Effect: Andromeda가 시리즈의 실수로 평가받은 점, 2019년 라이브 서비스에 크게 걸었던 Anthem이 실패한 점, 2025년 Dragon Age: The Veilguard가 판매 기대에 못 미쳐 감원이 있었던 점을 든다. 거기에 EA가 약 550억 달러 규모 거래로 비상장화된 상황이 겹쳐 있다.

기사에서 확인하지 못한 것. 어느 게임에 어떤 엔진을 썼는지, 엔진이 개발 일정을 얼마나 깎았는지는 기사에 없다. 앞서 쓴 “슈팅용 엔진에서 RPG 기능을 새로 얹느라 고생했다”는 이야기는 당시 업계에 돌던 얘기로 알고 있을 뿐, 이 글의 원문으로는 검증하지 못했다. 그러니 사실이라 해도 “여러 요인 중 하나”로만 봐야 한다. 라이브 서비스 도박과 판매 부진, 구조조정만으로도 스튜디오가 흔들릴 이유는 충분하다.

다만 일반론으로는 이 가정이 꽤 설득력 있다. 인벤토리, 대화, 선택지 분기, 퀘스트 상태 같은 RPG 필수 기능이 엔진에 기본으로 없으면 스튜디오가 그걸 직접 만들어야 한다. 앞의 샘플 코드에서 세 번째 아픈 지점이 그대로 비싼 버전이 되는 셈이다. 엔진이 장르를 모르면 그 차이를 사람의 시간으로 메우게 된다.

그럼 지금 선택지는 뭔가. 셋이다. Unreal이나 Unity 같은 상용 엔진은 인력 구하기가 쉽다. 이직해 온 사람이 이미 엔진을 안다는 건 생각보다 큰 장점이다. 대신 로드맵이 남의 것이다. 사내 엔진은 그룹 안에서 기술을 공유하기 좋지만 장르가 다르면 고생한다. 직접 만드는 건 강력하지만 소규모 팀이 감당할 수준이 아니다. 어느 쪽이든 공짜는 없고, 비용을 언제 어디서 내느냐만 다르다.

엔진은 한번 정하면 바꾸는 비용이 너무 커서 사실상 스튜디오의 운명을 같이 정한다. 바꾸려면 툴, 데이터, 사람의 숙련도가 전부 같이 옮겨 가야 하기 때문이다. 그걸 기술 선택 회의에서 가볍게 정하는 곳이 많다는 게 문제다.

---

원문: EA is shutting down BioWare (via hn)