게임 개발 외주 실패 사례 — 프로젝트가 엎어지는 2가지 패턴

게임 개발 외주는 실패 확률이 높습니다. 이건 외주사가 못해서가 아닙니다. 구조적으로 실패하기 쉬운 패턴이 있습니다.

18년간 게임을 만들면서 프로젝트가 엎어지는 걸 여러 번 봤습니다. 원인은 거의 같았습니다.

이 글에서는 게임 외주 실패의 가장 흔한 패턴 2가지를 정리합니다. 그리고 이걸 어떻게 막을 수 있는지도 함께 다룹니다.

패턴 1 — 잦은 기획 변경

게임 외주가 엎어지는 가장 흔한 원인입니다.

어떻게 발생하는가

형태는 다양합니다.

형태 A — "이거 빼고 저거 넣어주세요"가 매주 옵니다.

개발 3주차. 서버 구조를 잡고 있습니다. 의뢰자에게서 연락이 옵니다. "이 기능 빼고, 이거 대신 넣어주세요." 다음 주에도 옵니다. 그 다음 주에도 옵니다.

한 번의 변경은 작아 보입니다. 누적되면 설계 전체가 흔들립니다.

형태 B — 거의 다 만들었는데 "방향을 바꾸자".

개발 5개월차. 80% 완성입니다. 의뢰자가 경쟁 게임을 봤습니다. "우리도 이렇게 바꿔야 할 것 같아요."

80%를 버리고 다시 시작합니다. 일정 2배. 비용 2배.

형태 C — 의뢰자 내부에서 의견이 안 모입니다.

대표는 A를 원합니다. 기획자는 B를 원합니다. 투자자는 C를 원합니다.

매 미팅마다 방향이 바뀝니다. 외주사는 매번 되돌립니다.

기획 변경은 자연스러운 일입니다

게임은 "만들어봐야 재미있는지 아는" 제품입니다.

웹사이트는 기획서대로 만들면 됩니다. 게임은 기획서대로 만들어도 재미없을 수 있습니다.

기획이 바뀌는 건 당연합니다. 바뀌지 않는 게임 프로젝트는 거의 없습니다.

문제는 변경 자체가 아닙니다. 변경했을 때 뭐가 얼마나 달라지는지 모르는 상태가 문제입니다.

좋은 외주사는 이렇게 대응합니다

1. 변경 요청이 오면, 영향 범위를 먼저 알려줍니다.

"이 기능을 바꾸면 서버 구조가 이만큼 바뀝니다." "일정은 2주 늘어나고, 비용은 이 정도 추가됩니다."

이걸 먼저 정리해서 알려주는 게 외주사의 역할입니다. 의뢰자는 그 정보를 보고 "바꿀지 말지" 판단하면 됩니다.

2. 변경을 줄이려면, 프로토타입을 먼저 만듭니다.

기획이 자주 바뀌는 이유는 "확신이 없어서"입니다. 2주짜리 프로토타입으로 핵심 재미를 먼저 검증하면, 본개발에서 바뀔 가능성이 줄어듭니다.

프로토타입이 왜 중요한지는 이 글에서 정리했습니다.

3. 변경 이력을 문서로 남깁니다.

뭐가 바뀌었고, 왜 바뀌었고, 비용·일정이 어떻게 달라졌는지. 기록이 있으면 나중에 "왜 늦어졌지?"가 안 나옵니다. 의뢰자와 외주사 모두를 보호하는 장치입니다.

패턴 2 — 초기 소통 부재

두 번째로 흔한 패턴입니다. 그리고 이쪽이 더 위험합니다.

어떻게 발생하는가

의뢰자가 기획서를 보내옵니다. 30페이지짜리 기획서입니다. 겉보기엔 잘 정리되어 있습니다.

외주사가 기획서를 받고 개발을 시작합니다. 3개월 후, 문제가 터집니다.

"이 상황에서 유저가 동시에 요청하면 어떻게 되죠?" "서버 2대일 때 세션은 어떻게 관리하죠?" "이 보상 지급 로직에서 중복 수령은 어떻게 막죠?"

기획서에 안 적혀 있습니다. 의뢰자도 생각 안 해봤습니다. 3개월간 만든 구조 위에서 이걸 해결하려면 설계를 뜯어야 합니다.

왜 위험한가

기획 변경은 "바뀌었다"는 걸 알기라도 합니다. 초기 소통 부재는 **"문제가 있는지조차 모르는 상태"**입니다.

기획서에 적히지 않는 것들이 있습니다.

• 동접 100일 때와 10,000일 때 서버 구조가 다릅니다.
• 결제 시스템은 플랫폼 정책에 따라 설계가 달라집니다.
• 실시간 동기화 방식은 게임 장르에 따라 선택이 갈립니다.

이런 것들은 기획자가 기획서에 안 씁니다. 개발자가 초기에 짚어줘야 합니다.

안전하게 진행하는 방법

이걸 초반에 찾아내는 게 시니어의 역할입니다.

기획서를 받으면 "이대로 만들겠습니다"가 아니라, "이 부분은 결정이 필요합니다"를 먼저 짚어야 합니다.

구체적으로:

1. 착수 전 기술 검토 단계를 넣으세요.

기획서를 받자마자 개발에 들어가지 마세요. 1~2주간 기획서를 읽고, 기획에 빠진 기술 결정 사항을 목록으로 정리합니다. 이 목록을 의뢰자와 합의한 후에 개발에 들어갑니다.

2. "이대로 되나요?"가 아니라 "이 상황에서 어떻게 되죠?"를 물으세요.

기획서에 적힌 것만 묻지 마세요. 적히지 않은 것을 물어야 합니다.

• "유저가 결제 중간에 앱을 끄면?"
• "서버를 2대로 늘리면 이 로직이 깨지지 않나요?"
• "이 데이터를 실시간으로 동기화해야 하나요, 비동기로 충분한가요?"

이 질문들을 착수 전에 던지는 외주사와, 3개월 후에 발견하는 외주사의 결과물은 완전히 다릅니다.

3. 시니어가 초기에 투입되어야 합니다.

주니어는 기획서에 적힌 걸 만듭니다. 시니어는 기획서에 안 적힌 걸 찾습니다.

초기 1~2주에 시니어가 투입되어 기획의 빈 곳을 짚는 것이, 프로젝트 전체의 성패를 가릅니다.

2가지 패턴의 공통점

두 패턴 모두 "초반에 시간을 들이지 않아서" 발생합니다.

• 프로토타입 없이 본개발 → 기획 변경 폭증
• 기술 검토 없이 본개발 → 3개월 후 설계 재작업

초반 2주를 아끼면, 이후 수개월을 잃습니다.

게임 외주의 성공과 실패는 개발 실력이 아니라, 착수 전 2주에서 결정됩니다.

---

관련 글

• 게임 개발 외주, 어디서부터 시작해야 할까 — 종합 가이드
• 게임 개발 외주 전에 꼭 확인해야 할 7가지 체크리스트
• 게임 프로토타입, 왜 본개발 전에 만들어야 하는가

---

게임 외주를 준비 중이시라면, 착수 전 기술 검토부터 같이 해드립니다. 기획서에 빠진 것을 먼저 찾아드리는 게 저희가 하는 일입니다. 30분 무료 미팅에서 시작할 수 있습니다.