Cover · Issue 025
"포스트잇은 늘어나고, 달력의 동그라미는 빨개지고, 커피는 식어간다."
TSTF MAG · 2026
AI가 빌드를 돌리고 QA 시나리오를 뽑는 지금도, 게임 개발팀의 막판 밤샘은 줄지 않았다. 도구가 빨라졌는데 마감이 당겨지지 않는 이유 — 그것이 일정 산정의 문제인지, 아니면 "충분히 됐다"는 기준이 계속 올라가는 것인지.
몇 년 전 자동화 도구들이 쏟아지기 시작했을 때, 현장에서 기대했다. "이제 좀 일찍 퇴근하겠지." 하지만 그 기대는 대체로 빗나갔다.
지금도 마찬가지다. 빌드 자동화가 한 시간짜리 작업을 5분으로 줄였고, QA 시나리오 초안을 AI가 뽑아준다. 번역도, 반복 코드도, 밸런스 시뮬레이션도. 그런데 팀의 마지막 주는 여전히 야근이다. 어떤 팀은 오히려 더 촘촘해졌다고 말한다.
"도구가 두 배 빨라지면 두 배 더 쉬어야 할 텐데, 현장은 왜 두 배 더 많은 걸 만들고 있는가."
— 편집부 관찰 · 2026.05이 질문을 붙들고 보면 두 가지 설명이 보인다. 하나는 일정 산정의 문제고, 하나는 "충분히 됐다"는 기준이 올라가는 문제다. 이 호는 그 두 갈래를 따라간다. 어느 쪽이 더 가까운지 — 그 답은 독자에게 미뤄둔다.
Note 크런치(crunch)는 게임 업계에서 출시 직전 팀 전체가 집중적으로 초과 근무하는 시기를 가리킨다. 업계 밖에선 낯선 단어지만, 게임 팀에서는 사실상 하나의 계절처럼 취급된다. 이번 호는 그 "계절"이 사라지지 않는 구조적 이유를 짚는다.
도구가 빨라지면 어떤 일이 벌어지는가. 생각보다 이 질문의 답은 단순하지 않다. "더 빨리 끝내고 쉰다"는 시나리오와 "더 빨리 만들고 더 많이 만든다"는 시나리오가 동시에 가능하다. 어느 쪽이 실제로 일어나는지는 팀 바깥의 힘과 팀 안쪽의 감각이 함께 결정한다.
자동화 도구가 퍼지면 주변에서 보는 눈이 달라진다. "저 팀은 이제 빌드가 5분이래"라는 말이 퍼지는 순간, 다음 마일스톤 날짜가 슬쩍 당겨진다. 팀이 더 빨리 만들 수 있다는 사실이 곧 더 빨리 만들어야 한다는 압력이 된다.
이건 개발팀 혼자 해결하기 어려운 문제다. 도구의 속도가 빨라질수록 기대치가 함께 올라가는 구조가 팀 밖에서 작동하기 때문이다. 일정은 도구의 문제가 아니라, 기대치를 누가 어떻게 잡느냐의 문제다.
이쪽 설명은 조금 다른 곳에서 시작한다. 도구가 더 많은 걸 가능하게 하면, 팀이 기대하는 완성도도 함께 올라간다. "이전엔 없어서 못 했는데, 이제는 할 수 있잖아" — 그 순간 그것이 기본값이 된다.
게임 개발에서 이 현상은 특히 선명하다. 폴리싱(polish)이라고 부르는 마지막 다듬기 과정은 이론적으로 끝이 없다. 사운드 한 개를 더 다듬고, 파티클을 한 번 더 조정하고, 연출 컷을 한 장 더 고친다. 도구가 빨라질수록 그 "한 번 더"를 실행할 수 있는 여지가 생기고, 팀은 그 여지를 쉬는 데 쓰지 않고 더 다듬는 데 쓴다.
실제 현장에서는 이 두 가지가 따로 작동하지 않는다. 위에서는 일정이 당겨지고, 팀 안에서는 기준이 올라간다. 마감 직전에 남은 시간은 양쪽에서 동시에 줄어든다. 이렇게 되면 도구가 아무리 빨라져도, 그 속도만큼 여유가 생기지 않는다. 속도 이득이 새로운 요구로 즉시 채워지기 때문이다.
일정이 문제라면, 다음 마일스톤을 어떻게 잡는지에 대한 싸움이다. 팀 외부의 기대치를 누가 어떻게 조율하는지의 문제다. 반면 기준이 문제라면, 싸울 대상은 팀 외부가 아니라 팀 내부다. "우리가 이번 주에 '됐다'고 말할 수 있는 기준이 무엇인가" — 그 정의를 미리 합의하지 않은 채 도구가 빨라지면, 밤은 계속 온다.
게임 개발에서 "완성"은 정의하기 어렵다고들 한다. 자동차라면 핸들이 달리고 바퀴가 구르면 완성이지만, 게임은 "플레이할 수 있다"와 "출시할 수 있다"와 "자랑할 수 있다" 사이에 셀 수 없이 많은 단계가 있다. 그리고 그 각 단계의 기준은 팀마다 다르고, 같은 팀에서도 사람마다 다르다.
도구가 이 문제에 어떻게 개입하는지를 보면 패턴이 보인다. 더 빠른 도구는 더 많은 이터레이션을 가능하게 한다. 이터레이션이 늘어나면 이전에는 볼 수 없던 결함이 보이기 시작한다. 결함이 보이면 고치고 싶어진다. 고치면 새 결함이 보인다. 완성의 선은 도달할 수 없는 지평선처럼 앞으로 물러난다.
| 일정 산정 문제 | 기준 상승 문제 | |
|---|---|---|
| 원인 | 도구 속도만큼 기대치가 올라간다 | 팀이 만족하는 기준이 도구와 함께 올라간다 |
| 압력 방향 | 팀 외부에서 온다 | 팀 내부에서 온다 |
| 해결 경로 | 일정 협상, 마일스톤 재설계 | "됐다"의 기준 사전 합의 |
| 도구가 도움이 되는가 | 아니다 — 빨라질수록 압박이 늘어남 | 아니다 — 빨라질수록 더 다듬고 싶어짐 |
| 핵심 질문 | 누가 언제 일정을 잡는가 | 팀이 이번 주 무엇을 "충분히"로 보는가 |
이 표에서 흥미로운 지점은 하나다. 두 설명 모두에서 도구는 문제를 해결하지 않는다. 일정 문제라면 더 빠른 도구가 오히려 기대를 높이고, 기준 문제라면 더 강력한 도구가 오히려 더 많이 다듬게 만든다. 밤샘을 줄이기 위해 도구를 더 빠르게 만드는 것은, 모래를 빠르게 퍼내는 양동이가 커질수록 파도도 커지는 것과 비슷할 수 있다.
두 설명 중 어느 하나라도 맞다고 받아들이면, 몇 가지가 달라 보인다.
게임 개발에는 이 문제를 더 어렵게 만드는 요소가 하나 있다. 게임의 품질은 숫자로 잘 나오지 않는다는 것이다. 버그 수, 로딩 시간, 프레임레이트 같은 지표는 있지만, "이 게임이 재미있는가"는 여전히 사람이 플레이해봐야 안다. 그리고 그 "재미"의 판단은 플레이 한 번 할 때마다 조금씩 달라진다.
이런 환경에서 "됐다"는 말은 특히 어렵다. 다음 사람이 플레이하면 또 새로운 개선점이 보인다. 팀 안에서 가장 많이 플레이한 사람이 가장 많은 결함을 보는 역설이 생긴다. 숙련이 완성의 기준을 높이는 구조다.
이번 호의 결론은 독자에게 맡긴다. 답을 정하지 않았다. 팀원들과 점심 자리에서 한 번 꺼내볼 만한 질문들이다.
그 말이 언제 나왔는지, 누가 했는지 기억하는가. 그 말이 없었다면, 팀이 "됐다"의 기준을 공유하지 않고 일했다는 뜻일 수 있다.
솔직하게 따져보면 어느 쪽인가. 늘어난 것이 작업이라면, 그 작업은 처음부터 계획에 있었는가, 아니면 "할 수 있게 됐으니 하자"로 추가됐는가.
그 "조금만 더"가 품질을 위한 것이었는가, 아니면 불안을 잠재우기 위한 것이었는가. 둘을 구분할 수 있는 기준이 있는가.
이번 호는 "왜"에 대한 이야기지 "어떻게"에 대한 이야기가 아니다. 해법을 먼저 내놓기보다, 문제의 구조를 한 번 정확하게 보고 싶었다. 같은 현상을 두고 "일정이 문제"라고 보는 사람과 "기준이 문제"라고 보는 사람이 같은 해결책을 제안하면 하나는 반드시 허공을 향한다.
편집부가 흥미롭게 본 지점은 하나다. 두 설명 중 어느 쪽이 맞든, 더 빠른 도구가 밤샘을 줄이지 않는다는 결론은 같다. 도구가 빨라질수록 일정이 당겨지거나 기준이 올라가거나 — 둘 중 하나가 반드시 일어난다. 그렇다면 크런치를 줄이는 열쇠는 도구의 속도가 아니라, 다른 곳에 있다.
그 "다른 곳"이 어디인지는, 각 팀이 스스로 진단해야 한다. 이번 호의 질문들이 그 진단의 출발점이 되길 바란다. "우리 팀에서 지금 밤을 부르는 건 일정인가, 기준인가." 이 질문 하나를 팀 안에서 꺼낼 수 있다면, 이 호는 제 역할을 다한 것이다.
— Desk γ게임 프로젝트에서 결정의 근거가 사라지는 방식, 그리고 기록이 팀에게 하는 일에 관하여.