혼자 만드는 게임을 오래 완성하기 위한 멘탈 케어와 번아웃 대응법

혼자 게임을 만들면 기획자, 프로그래머, 아티스트, QA, 홍보 담당자의 판단을 한 사람이 모두 떠안게 됩니다. 피로가 쌓이는 이유는 단순히 오래 일해서만이 아닙니다. 끝나지 않는 할 일, 불명확한 완성 기준, 느린 피드백이 겹치면 작업 자체를 피하게 되기 쉽습니다.

번아웃 대응의 목표는 매일 높은 의욕을 유지하는 것이 아닙니다. 의욕이 낮은 날에도 프로젝트가 아주 조금은 전진하고 회복한 뒤 다시 큰 작업으로 돌아올 수 있는 구조를 만드는 데 있습니다.

번아웃을 먼저 작업 설계 문제로 본다

번아웃에는 개인의 컨디션이 영향을 주지만 프로젝트 구조도 큰 비중을 차지합니다. 특히 1인 개발에서는 다음 세 가지가 반복되기 쉽습니다.

• 완료 조건이 없는 작업: 전투를 재미있게 만들기, 그래픽을 개선하기처럼 끝을 판단하기 어렵습니다.
• 역할 전환 과부하: 버그 수정 중에 UI를 고치고 다시 홍보용 영상을 만들면 집중을 다시 만드는 비용이 커집니다.
• 피드백 지연: 몇 주 동안 시스템만 만들면 플레이 가능한 결과를 보기 어렵습니다.

따라서 더 열심히 하기보다 작업을 작게 나누고 확인 가능한 결과를 자주 만드는 편이 효과적입니다. 예를 들어 전투 개선을 다음처럼 바꿉니다.

• 적 1종에 피격 경직 0.15초를 적용한다.
• 10분 플레이 테스트에서 피격 사유를 로그로 남긴다.
• 테스트 후 수치 하나만 조정하고 다시 빌드한다.

이렇게 쓰면 시작 조건과 종료 조건이 생깁니다. 작업이 끝났다는 감각은 동기보다도 다음 작업을 시작하는 데 직접 도움이 됩니다.

위험 신호를 발견했을 때의 대응 순서

피곤한 날이 있다고 번아웃이라고 단정할 필요는 없습니다. 다만 며칠 이상 개발 시작이 지나치게 어려워지거나 사소한 버그에도 강한 자기비난이 이어지거나 휴식 중에도 프로젝트 걱정이 멈추지 않는다면 작업 방식을 조정할 신호로 볼 수 있습니다.

flowchart TD
    A[작업 저항 또는 피로를 알아차림] --> B{며칠 이상 이어지는가?}
    B -- 아니오 --> C[가벼운 작업으로 전환하고 휴식]
    B -- 예 --> D[이번 주 범위와 일정 점검]
    D --> E[기능을 축소하거나 마감 조정]
    E --> F[짧은 플레이 가능한 목표 설정]
    F --> G{수면·식사·일상 기능도 무너지는가?}
    G -- 아니오 --> H[작업 시간과 회복 시간을 기록하며 재개]
    G -- 예 --> I[가까운 사람 또는 전문가에게 도움 요청]

핵심은 감정이 완전히 나아질 때까지 프로젝트를 방치하는 것이 아니라 현재 에너지로 가능한 작업의 크기를 낮추는 것입니다. 예를 들어 새 시스템 구현 대신 빌드 오류 정리, 테스트 시나리오 작성, 에셋 이름 정리처럼 판단 부담이 적은 일을 선택할 수 있습니다.

일상 기능이 계속 무너지거나 무기력, 불안, 수면 문제가 심하게 이어진다면 개발 방법만으로 해결하려 하지 않는 편이 좋습니다. 신뢰할 수 있는 사람이나 의료·상담 전문가에게 도움을 요청하세요.

주간 작업량은 시간보다 회복 가능성으로 정한다

주당 40시간이 가능한지보다 그 시간을 몇 주 연속 유지한 뒤에도 정상적인 수면과 생활을 유지할 수 있는지가 더 중요합니다. 계획할 때는 실제 개발 가능 시간을 보수적으로 잡고 예상치 못한 버그와 생활 일정을 위한 여유를 남깁니다.

간단한 계획식은 다음과 같습니다.

$$주간\ 작업\ 용량 = 확보한\ 시간 \times 집중\ 가능\ 비율$$

예를 들어 확보한 시간이 15시간이고 회의·정리·컨디션 변동을 고려해 집중 가능 비율을 0.6으로 잡으면 계획 가능한 작업량은 약 9시간입니다. 남은 6시간은 실패가 아니라 버퍼입니다.

이번 주에 15시간 일한다보다 플레이 가능한 방 하나를 만들고 남는 시간에 버그를 두 개 처리한다처럼 결과 중심으로 계획하세요. 주간 목표는 하나의 핵심 목표와 두세 개의 보조 목표면 충분합니다.

작업을 세 종류로 분리한다

하루의 에너지 상태가 매번 같지 않으므로 작업 목록도 난이도별로 나눠 두는 것이 좋습니다.

고에너지 작업

새로운 게임플레이 구현, 어려운 버그 분석, 레벨 구조 설계처럼 깊은 집중이 필요한 일입니다. 가장 맑은 시간대에 배치하고 한 세션의 목표를 하나로 제한합니다.

중간 에너지 작업

UI 연결, 데이터 입력, 기존 시스템의 작은 확장, 플레이 테스트처럼 맥락은 필요하지만 창의적 돌파가 덜 필요한 일입니다.

저에너지 작업

빌드 확인, 버그 재현 단계 기록, 에셋 정리, 짧은 영상 캡처, 다음 작업의 체크리스트 작성이 여기에 해당합니다. 저에너지 작업은 쉬운 일이 아니라 컨디션이 낮을 때 프로젝트와 연결을 유지하는 안전장치입니다.

Unity에서 하루 기록을 가볍게 남기기

감정과 진행 상황을 기억에만 의존하면 힘든 하루가 프로젝트 전체의 실패처럼 느껴질 수 있습니다. 작업 시간, 에너지, 완료한 항목을 짧게 남기면 계획이 과했는지와 어떤 작업이 피로를 키웠는지 돌아보기 쉬워집니다.

아래 Unity 에디터 스크립트는 Assets/Editor/DailyDevLogWindow.cs에 넣을 수 있는 간단한 기록 창입니다. 기록은 프로젝트 폴더의 DailyDevLogs에 텍스트 파일로 저장됩니다.

using System;
using System.IO;
using UnityEditor;
using UnityEngine;

public class DailyDevLogWindow : EditorWindow
{
    private int energy = 3;
    private string completed = "";
    private string nextSmallTask = "";

    [MenuItem("Tools/Daily Dev Log")]
    public static void Open()
    {
        GetWindow<DailyDevLogWindow>("Daily Dev Log");
    }

    private void OnGUI()
    {
        EditorGUILayout.LabelField("오늘의 개발 기록", EditorStyles.boldLabel);
        energy = EditorGUILayout.IntSlider("에너지", energy, 1, 5);
        completed = EditorGUILayout.TextField("완료한 작은 일", completed);
        nextSmallTask = EditorGUILayout.TextField("다음 작은 일", nextSmallTask);

        GUILayout.Space(8);
        if (GUILayout.Button("기록 저장"))
        {
            SaveLog();
        }
    }

    private void SaveLog()
    {
        string directory = Path.Combine(Application.dataPath, "..", "DailyDevLogs");
        Directory.CreateDirectory(directory);

        string date = DateTime.Now.ToString("yyyy-MM-dd");
        string path = Path.Combine(directory, date + ".txt");
        string log = $"Date: {date}\nEnergy: {energy}/5\nDone: {completed}\nNext: {nextSmallTask}\n";

        File.AppendAllText(path, log + "\n");
        Debug.Log($"Daily log saved: {path}");
        completed = "";
        nextSmallTask = "";
    }
}

이 도구의 목적은 생산성을 감시하는 것이 아닙니다. 에너지가 낮은 날에도 무엇을 끝냈는지 확인하고 다음 시작점을 한 줄로 남겨 재개 비용을 낮추는 데 있습니다. 기록이 부담스럽다면 완료한 작은 일과 다음 작은 일만 작성해도 됩니다.

피드백 주기를 짧게 만든다

완성도를 오래 내부 기준으로만 판단하면 불안이 커집니다. 기능 하나를 만든 뒤에는 가능한 한 빨리 직접 플레이하고 작은 범위의 피드백을 받으세요.

피드백 요청도 구체적으로 제한하는 편이 좋습니다. 게임이 재미있나요? 대신 다음처럼 묻습니다.

• 첫 5분 안에 다음 목표를 이해했나요?
• 적에게 맞았을 때 이유를 알 수 있었나요?
• 조작 중 불편했던 행동을 하나만 골라 주세요.

이 방식은 받은 의견을 바로 작업 항목으로 바꾸기 쉽고 개발자 자신을 평가받는 느낌도 줄여 줍니다. 모든 의견을 반영할 필요는 없습니다. 게임의 핵심 목표와 맞는 피드백만 선택하면 됩니다.

휴식은 보상이 아니라 일정의 일부다

휴식은 충분히 일한 뒤에만 허용되는 보상이 아닙니다. 집중을 다시 쓸 수 있게 하는 작업 환경의 일부입니다. 특히 혼자 개발할 때는 퇴근 기준을 명시적으로 정하는 것이 좋습니다.

• 세션이 끝나면 다음 작업을 한 줄로 적고 에디터를 닫습니다.
• 주 1회는 프로젝트와 무관한 활동을 일정에 넣습니다.
• 큰 기능을 마친 뒤에는 새 기능 대신 플레이 테스트나 정리 작업을 배치합니다.
• 빌드가 깨졌거나 컨디션이 나쁜 날에는 목표를 축소합니다.

좋은 페이스는 가장 빠른 하루의 속도가 아니라 나쁜 주에도 다시 돌아올 수 있는 속도입니다. 프로젝트를 지속할 수 있는 작업량을 찾고 작은 완료와 짧은 피드백을 반복하세요. 그것이 혼자 만드는 게임을 끝까지 가져가는 가장 현실적인 멘탈 케어입니다.