혼자 또는 작은 팀으로 제작 운영하기

운영도 게임 제작의 일부다

인디게임 개발에서 자주 무너지는 지점은 기술 자체보다 운영이다. 처음에는 모두가 열심히 시작한다. 하지만 시간이 지나면 누가 무엇을 하고 있는지 모호해지고, 새 아이디어가 계속 들어오며, 중요한 결정이 기록되지 않는다. 그러면 작업은 했는데 게임은 앞으로 가지 않는 상태가 된다.

작은 팀일수록 운영을 거창하게 만들 필요는 없다. 오히려 규칙은 적어야 한다. 대신 반드시 지켜야 할 기준은 있어야 한다.

• 이번 주에 무엇을 끝낼 것인가

• 누가 최종 결정을 내릴 것인가

• 어떤 작업은 이번 버전에서 제외할 것인가

• 피드백은 어디에, 어떤 형식으로 남길 것인가

• 지친 사람이 생겼을 때 일정을 어떻게 줄일 것인가

운영의 목표는 팀원을 감시하는 것이 아니다. 프로젝트가 흐려지지 않게 만드는 것이다. 혼자 개발하더라도 마찬가지다. 머릿속으로만 관리하면 어느 순간 중요한 판단이 감정과 기억에 의존하게 된다.

AI 생성 이미지

혼자 만들어도 역할은 나눠서 생각한다

1인 개발자는 혼자 모든 역할을 맡는다. 그래서 더더욱 역할을 구분해야 한다. 같은 사람이 하더라도 "지금은 기획자의 시간인지, 프로그래머의 시간인지, 마케터의 시간인지"를 나누면 판단이 선명해진다.

작은 팀에서는 보통 다음 역할을 겸임한다.

중요한 점은 모든 역할에 전문가가 필요하다는 뜻이 아니다. 첫 게임에서는 각 역할이 만들어야 할 최소 산출물을 정하는 것이 더 중요하다.

예를 들어 2인 팀이라면 이렇게 나눌 수 있다.

• A: 프로그래밍, 빌드, 일정 관리

• B: 기획 보조, 아트, SNS 기록

• 외주 또는 에셋 구매: 음악, 일부 효과음

3인 팀이라면 다음처럼 나눌 수 있다.

• A: 프로그래밍, 기술 결정

• B: 기획, 레벨 설계, 테스트 정리

• C: 아트, UI, 홍보 이미지

• 공통: 주 1회 빌드 테스트

역할을 나눌 때 가장 위험한 말은 "다 같이 정하자"이다. 의견은 같이 낼 수 있다. 하지만 최종 결정자는 정해야 한다. 결정자가 없으면 취향 싸움이 길어지고, 결정이 나도 나중에 다시 뒤집힌다.

작은 팀에서는 분야별 최종 책임자를 한 명씩 둔다.

• 게임 규칙 최종 결정: 1명

• 코드 구조와 기술 선택 최종 결정: 1명

• 아트 스타일 최종 결정: 1명

• 출시 범위와 일정 최종 결정: 1명

한 사람이 여러 개를 맡아도 된다. 다만 최종 결정자가 누구인지는 문서에 적어야 한다.

작업은 사람 기준이 아니라 결과물 기준으로 관리한다

"이번 주에 열심히 해보자"는 계획이 아니다. 작은 팀의 작업은 결과물 기준으로 쪼개야 한다.

나쁜 작업 예시는 다음과 같다.

• 전투 시스템 만들기

• 맵 작업하기

• 사운드 넣기

• 홍보 준비하기

좋은 작업은 끝났는지 확인할 수 있다.

• 플레이어 공격 버튼을 누르면 0.2초 안에 판정이 발생한다

• 첫 번째 맵에서 시작, 실패, 재시작, 클리어가 가능하다

• 점프, 피격, 획득 효과음 3개를 적용한다

• 스팀 페이지용 짧은 소개 문장 3안을 작성한다

작업을 관리할 때는 칸반 보드가 가장 단순하다. 칸반은 작업 카드를 상태별로 옮기는 방식이다. 처음에는 다음 네 칸이면 충분하다.

• 할 일

• 진행 중

• 검토 필요

• 완료

규칙도 단순해야 한다.

1. 한 사람은 동시에 진행 중 작업을 1~2개만 가진다.

2. 완료 조건이 없는 작업은 시작하지 않는다.

3. 막힌 작업은 혼자 오래 붙잡지 말고 표시한다.

4. 새 아이디어는 바로 작업하지 않고 "나중 목록"에 넣는다.

특히 "진행 중"이 많아지는 순간을 조심해야 한다. 진행 중 작업이 많다는 것은 열심히 하고 있다는 뜻이 아니라 끝난 것이 없다는 뜻일 수 있다. 게임은 완료된 기능이 쌓일 때만 앞으로 간다.

회의는 줄이고 기록은 남긴다

작은 팀에서 회의가 많아지면 개발 시간이 사라진다. 반대로 회의가 전혀 없으면 각자 다른 게임을 만들게 된다. 필요한 것은 긴 회의가 아니라 짧고 반복 가능한 확인 절차다.

가장 현실적인 기본 구조는 주 1회 회의와 비동기 기록이다. 비동기 기록은 동시에 모이지 않고도 글로 남겨 확인하는 방식이다.

주간 회의는 30분 안에 끝내는 것을 목표로 한다.

• 지난주에 끝난 것

• 끝나지 못한 것과 이유

• 이번 주에 반드시 끝낼 것

• 삭제하거나 미룰 기능

• 테스트가 필요한 빌드

회의에서 모든 문제를 해결하려고 하면 길어진다. 회의의 목적은 토론이 아니라 정렬이다. 깊은 논의가 필요한 주제는 따로 담당자끼리 짧게 잡는다.

작업 기록은 한곳에 모은다. 문서 도구, 이슈 트래커, 스프레드시트 중 무엇이든 상관없다. 중요한 것은 팀원이 "최신 결정은 어디에 있는가"를 바로 찾을 수 있어야 한다는 점이다.

최소한 다음 세 가지는 기록한다.

• 결정 로그: 무엇을 결정했고 왜 그렇게 했는가

• 변경 로그: 무엇이 추가, 삭제, 수정되었는가

• 버그 목록: 언제, 어떤 상황에서, 어떻게 문제가 발생했는가

말로 한 결정은 쉽게 사라진다. 채팅방에 흘러간 결정도 찾기 어렵다. 중요한 결정은 반드시 문서의 정해진 위치로 옮긴다.

피드백 규칙을 정해야 감정 소모가 줄어든다

피드백은 필요하지만, 방식이 없으면 사람을 지치게 한다. "별로다", "느낌이 안 산다", "좀 더 예쁘게" 같은 말은 작업자를 막막하게 만든다. 반대로 작업자는 모든 피드백을 공격으로 받아들이면 안 된다. 기준은 게임이다.

피드백은 다음 형식으로 남긴다.

• 문제: 플레이어가 무엇을 이해하지 못하는가

• 근거: 테스트 중 어떤 행동이나 반응이 있었는가

• 제안: 어떤 방향으로 수정해볼 수 있는가

예를 들어 "UI가 별로다"보다 다음이 낫다.

첫 테스트에서 3명 중 2명이 체력바를 보지 못했다. 체력바 색이 배경과 비슷하고 위치도 전투 중 시선에서 멀다. 체력바를 캐릭터 근처에 작게 표시하거나, 피격 시 화면 가장자리에 붉은 효과를 추가해보자.

이렇게 쓰면 취향이 아니라 문제 해결이 된다.

피드백을 받을 때도 우선순위를 둔다.

• 플레이 진행을 막는 문제

• 규칙 이해를 방해하는 문제

• 조작감과 피드백 문제

• 스타일 취향 문제

첫 게임에서는 취향 문제보다 플레이 진행 문제를 먼저 고친다. 예쁘게 다듬는 일은 끝이 없다. 하지만 시작, 실패, 재시작, 클리어가 불안정하면 게임은 완성되지 않는다.

외주는 작은 계약서처럼 문서화한다

작은 팀은 모든 작업을 직접 할 수 없다. 음악, 캐릭터 일러스트, 로고, 번역, 트레일러, 포스터는 외주를 맡길 수 있다. 외주는 제작 속도를 높이지만, 요구사항이 흐리면 비용과 일정이 늘어난다.

외주를 맡길 때는 친한 사람에게 부탁하더라도 문서로 정리한다. 복잡한 계약서가 아니어도 다음 항목은 반드시 적는다.

• 작업 내용: 무엇을 만드는가

• 사용 목적: 게임 내 사용, 스토어 이미지, 홍보 영상 등

• 산출물 형식: PNG, PSD, WAV, MP3, 프로젝트 파일 등

• 크기와 규격: 해상도, 길이, 반복 가능 여부, 파일명 규칙

• 일정: 1차 시안 날짜, 최종 납품 날짜

• 수정 횟수: 몇 회까지 포함되는가

• 비용과 지급 방식: 선금, 중도금, 잔금 여부

• 저작권과 사용권: 소유권 이전인지, 사용 허락인지

• 크레딧 표기: 이름을 넣을지, 어떤 이름으로 넣을지

• 포트폴리오 공개 가능 여부

저작권 조건은 특히 중요하다. 돈을 냈다고 해서 항상 모든 권리를 갖는 것은 아니다. 게임 안에서 사용할 권리만 받은 것인지, 수정과 재판매까지 가능한지 확인해야 한다. 스토어 출시, DLC, 후속작, 굿즈 사용 가능성까지 필요 범위를 생각해두면 나중에 문제가 줄어든다.

요구사항도 구체적으로 써야 한다.

나쁜 요청은 다음과 같다.

귀여운 몬스터 5마리 그려주세요.

좋은 요청은 다음과 같다.

2D 탑다운 퍼즐 게임에 사용할 몬스터 5종입니다. 화면에서 64x64픽셀 크기로 보입니다. 배경이 어두운 보라색이므로 실루엣이 분명해야 합니다. 각 몬스터는 정지 이미지 1장과 피격 이미지 1장이 필요합니다. 파일은 투명 배경 PNG로 납품해주세요. 수정은 1차 시안 후 2회까지 포함합니다.

외주는 "알아서 잘 만들어주세요"가 통하지 않는다. 외주 작업자가 게임 전체 맥락을 모르는 것은 당연하다. 필요한 정보를 주는 것도 개발자의 일이다.

범위 확장을 막는 운영 규칙

개발 중 새 아이디어가 나오는 것은 자연스럽다. 문제는 좋은 아이디어가 아니라 지금 넣으면 안 되는 아이디어다. 작은 팀은 기능 하나가 추가될 때마다 구현, 아트, 사운드, UI, 테스트, 버그 수정까지 함께 늘어난다는 사실을 기억해야 한다.

새 기능을 넣기 전에는 네 가지 질문을 한다.

1. 이 기능이 없어도 게임을 끝까지 플레이할 수 있는가?

2. 핵심 플레이 루프를 더 선명하게 만드는가?

3. 이번 일정 안에 구현, 테스트, 수정까지 가능한가?

4. 추가되는 작업이 다른 필수 작업을 밀어내지 않는가?

네 질문 중 하나라도 불안하면 "나중 목록"으로 보낸다. 나중 목록은 쓰레기통이 아니다. 지금 버전을 지키기 위한 보관함이다.

또한 개발 중반 이후에는 기능 추가 중단 시점을 정해야 한다. 예를 들어 12주 프로젝트라면 8주 차 이후에는 새 기능을 넣지 않고, 버그 수정과 밸런스, UI 개선, 사운드 적용, 출시 준비에 집중한다. 이 시점을 정하지 않으면 출시 직전까지 게임의 모양이 바뀐다.

번아웃은 의지 문제가 아니라 운영 문제다

번아웃은 단순히 게으름이나 열정 부족이 아니다. 쉬지 못하고, 끝이 보이지 않고, 해도 진척이 느껴지지 않을 때 생긴다. 인디게임은 본업, 학교, 생활과 병행하는 경우가 많기 때문에 작업량을 현실적으로 관리해야 한다.

가장 먼저 할 일은 작업 시간을 기록하는 것이다. 정확한 생산성을 계산하려는 목적이 아니다. 자신이 실제로 얼마나 일할 수 있는지 알아야 일정을 세울 수 있다.

기록은 간단하면 충분하다.

2주만 기록해도 많은 것이 보인다. 생각보다 작업 시간이 적을 수 있다. 특정 요일에는 집중이 안 될 수 있다. 회의와 메시지 확인에 시간이 많이 나갈 수도 있다. 이 정보가 있어야 계획을 줄일 수 있다.

주 단위 리듬도 정한다.

• 월요일: 이번 주 작업 3개 이하로 확정

• 평일 중간: 막힌 작업 확인

• 주말 또는 정해진 날: 빌드 테스트

• 주간 종료: 끝난 것, 밀린 것, 삭제할 것 정리

여기서 핵심은 매주 계획을 다시 세우는 것이다. 한 번 만든 일정표를 끝까지 고집하면 현실과 어긋난다. 대신 목표는 유지하되, 경로를 조정한다. 작업 시간이 줄어든 주에는 새 기능을 넣지 않는다. 테스트에서 큰 문제가 나오면 콘텐츠 추가를 멈춘다. 팀원이 지쳤다면 완성 범위를 줄인다.

쉬는 시간도 계획에 포함해야 한다. 쉬는 날이 없으면 결국 예고 없이 멈춘다. 주 7일 작업보다 주 4~5일을 꾸준히 유지하는 편이 더 안전하다.

작은 팀을 위한 주간 운영 체크리스트

매주 한 번 다음 항목을 확인한다.

• 이번 주에 완료된 실행 가능한 결과물이 있는가?

• 진행 중 작업이 너무 많지 않은가?

• 막힌 작업을 누가 도와야 하는가?

• 새로 나온 아이디어가 필수 기능을 밀어내고 있지 않은가?

• 결정된 내용이 문서에 남아 있는가?

• 외주 작업의 일정, 형식, 수정 범위가 명확한가?

• 테스트 가능한 빌드가 있는가?

• 팀원 또는 본인의 피로가 누적되고 있지 않은가?

• 다음 주 작업을 3개 이하의 핵심 결과물로 줄였는가?

이 체크리스트의 목적은 더 많이 일하게 만드는 것이 아니다. 덜 흔들리게 만드는 것이다.

운영이 안정되면 완성 가능성이 올라간다

소규모 인디 개발은 부족한 자원으로 끝까지 가는 일이다. 모든 것을 잘할 수는 없다. 그래서 역할을 나누고, 기록을 남기고, 피드백 형식을 정하고, 외주 조건을 문서화하고, 작업 리듬을 관리해야 한다.

좋은 운영은 창작을 방해하지 않는다. 오히려 쓸데없는 혼란을 줄여 창작에 쓸 힘을 남겨준다. 팀이 작을수록 규칙은 단순해야 한다. 하지만 단순한 규칙이라도 반복해서 지켜야 한다.

이번 주에 무엇을 끝낼지 정하고, 끝난 것을 확인하고, 불필요한 것을 줄이는 것. 이 기본이 유지되면 게임은 조금씩 완성에 가까워진다.