목록으로
업무 생산성 개선을 위한 AI 활용
AI가 낮춘 창작의 장벽 — 중증 뇌병변(뇌성마비) 장애인의 Unity 게임 개발기
중증 뇌병변(뇌성마비) 장애인인 제가 ChatGPT와 Codex를 단순한 질문 도구가 아닌 개발 파트너로 활용해, AI의 작업 방식까지 직접 설계하며 Unity 6 기반 2D 턴제 RPG 「Project Limitless」를 개발하고 있습니다.
🤖 활용 AI 도구
ChatGPT, OpenAI Codex
1. 어떤 상황에서 AI를 활용했나요?
저는 중증 뇌병변(뇌성마비) 장애인입니다.
오랫동안 게임을 즐겨왔고, 언젠가는 제가 생각한 세계와 이야기를 직접 게임으로 만들어보고 싶었습니다. 하지만 게임을 좋아하는 것과 실제 게임을 만드는 것은 전혀 다른 일이었습니다.
게임 개발에는 기획뿐 아니라 프로그래밍, Unity 프로젝트 구성, UI 제작, 데이터 관리, 반복적인 테스트와 오류 수정 등 여러 종류의 작업이 이어집니다. 저에게는 장시간의 키보드와 마우스 조작, 반복 입력 같은 작업 역시 개발 과정에서 추가적인 장벽이 됩니다.
제가 부족했던 것은 만들고 싶은 게임에 대한 생각이 아니었습니다.
머릿속의 아이디어를 실제로 작동하는 코드와 게임 시스템으로 옮기는 과정이 문제였습니다.
그래서 ChatGPT와 Codex 같은 생성형 AI를 개발 과정에 활용하기 시작했습니다.
제가 개발하고 있는 게임은 「Project Limitless」입니다.
Unity 6 기반의 2D RPG로, 필드에서는 캐릭터를 직접 움직여 탐험하고 전투에서는 반응속도를 강요하지 않는 턴제 방식을 사용합니다.
게임에는 시각, 청각, 지적, 지체, 마음의 상처라는 다섯 가지 ‘길’이 등장하지만, 특정 길이 특정 직업을 제한하지 않습니다. 모든 길에서 모든 직업을 선택할 수 있습니다.
장애를 특별한 능력의 근원이나 불행을 위한 장치로 사용하는 대신, 캐릭터가 살아온 여러 조건 중 하나로 표현하고 싶었습니다.
그 생각을 실제 게임으로 구현하는 과정에서 AI를 개발 파트너로 활용했습니다.
2. 어떤 AI를 어떻게 활용했나요?
처음에는 AI에게 프로그래밍 방법이나 Unity 사용법을 질문하는 수준이었습니다.
그러나 프로젝트가 커질수록 단순히 그때그때 “코드를 만들어 달라”고 요청하는 방식만으로는 제가 원하는 게임을 일관되게 만들기 어렵다는 것을 알게 됐습니다.
그래서 저는 AI에게 무엇을 시킬지뿐 아니라, AI가 저와 어떻게 일해야 하는지도 정하기 시작했습니다.
Project Limitless의 GitHub 저장소에는 AGENTS.md, CODEX_WORKFLOW.md 같은 AI 개발 규칙이 있습니다.
AI는 작업 전에 프로젝트의 전체 맥락, 현재 개발 상태, 관련 설계 문서와 기존 코드를 먼저 확인해야 합니다. 제가 결정하지 않은 게임 디자인을 임의로 확정해서도 안 됩니다.
기존에 정상 작동하는 기능을 우선 보호하고, 제가 직접 수정한 이미지나 스프라이트를 허락 없이 다시 만들지 않으며, Unity Editor에서 직접 확인하지 못한 내용은 ‘검증 완료’라고 표현하지 않도록 했습니다.
또한 AI가 작성하는 C# 코드에는 Unity 프로그래밍 비전공자인 제가 다시 읽고 이해할 수 있도록 주요 기능과 이유를 한국어 주석으로 설명하게 했습니다.
제가 사용하는 기본 과정은 다음과 같습니다.
제가 요구사항 결정
→ AI가 기존 문서와 코드 확인
→ 구현 방법 논의 및 코드 작성
→ Unity에서 제가 직접 실행·플레이
→ 문제 발견
→ AI와 원인 분석 및 수정
→ 다시 테스트
→ Git commit과 현재 상태 문서 갱신
즉 저에게 AI는 한 번의 명령으로 완성품을 만들어주는 자동 제작기가 아니라, 제가 방향을 결정하고 결과를 검증하면서 반복적으로 협업하는 개발 도구입니다.
3. 활용 결과 어떤 변화가 있었나요?
가장 큰 변화는 머릿속의 아이디어가 실제로 작동하는 게임 시스템으로 바뀌기 시작했다는 것입니다.
사례 1. 단일 저장 기능을 실제 게임용 5슬롯 시스템으로 발전시키다
Before
처음 구현한 저장 기능은 캐릭터 한 명의 진행 상황을 저장하고 이어서 플레이할 수 있는 단일 저장 방식이었습니다.
AI와 협업
실제로 게임을 개발하면서 여러 캐릭터를 독립적으로 관리할 필요가 생겼습니다.
그래서 저는 5개의 독립적인 캐릭터 저장 슬롯, 기존 저장 데이터 보호, 손상된 슬롯이 다른 슬롯에 영향을 주지 않는 구조 등을 요구사항으로 정했습니다.
AI와 기존 저장 코드를 분석하면서 기능을 단계적으로 확장했습니다.
단일 저장·이어하기
→ 5개 캐릭터 저장 슬롯
→ 월드 위치 저장
→ 슬롯 삭제 및 손상 데이터 검증
After
현재는 다섯 개 캐릭터를 각각 저장하고 이어서 플레이할 수 있습니다. 마지막 월드 위치도 저장하며, 손상된 JSON이나 잘못된 데이터는 다른 슬롯을 손상시키지 않고 안전하게 거부합니다.
처음부터 완성된 저장 시스템을 한 번에 만든 것이 아니라, 제가 실제 결과를 사용해 보고 다음 요구사항을 결정하면서 AI와 단계적으로 발전시킨 기능입니다.
사례 2. AI가 만든 결과도 실제 플레이에서 다시 검증하다
턴제 전투를 구현하면서 또 다른 문제가 발생했습니다.
Before
광역 공격을 사용할 때 해당 범위에 공격할 적이 없으면 입력 상태가 꼬여 스킬 메뉴를 정상적으로 조작하기 어려워지는 문제가 있었습니다.
AI와 협업
제가 실제 플레이 과정에서 이 문제를 발견했고, 어떤 상황에서 문제가 생기는지 다시 정의했습니다.
AI와 함께 원인을 분석한 결과, 유효한 대상을 확인하기 전에 전투 UI 상태가 먼저 변경되는 것이 문제였습니다.
그래서 공격 대상을 먼저 검사하고, 대상이 없으면 행동 자체를 실행하지 않도록 수정했습니다.
After
현재는 공격할 대상이 없으면 행동, 턴, 자원, 재사용 대기시간을 소비하지 않습니다.
동시에 스킬 메뉴와 키보드 포커스도 원래 상태로 복구되어 플레이를 정상적으로 계속할 수 있습니다.
이 사례는 제 AI 활용 방식에서 중요한 부분을 보여줍니다.
AI가 만든 코드를 그대로 게임에 넣는 것이 아니라, 제가 실제로 플레이하고 문제를 발견한 뒤 다시 AI와 수정합니다.
사례 3. AI에게도 프로젝트의 개발 규칙을 적용하다
Before
프로젝트 초반에는 AI에게 질문할 때마다 필요한 배경을 다시 설명해야 했고, 프로젝트가 커질수록 이전 기획이나 코드와 다른 제안이 나올 가능성도 커졌습니다.
AI와 협업
그래서 Project Limitless의 GitHub 저장소 자체에 AI가 따라야 할 개발 규칙을 만들었습니다.
AI는 작업 전에 현재 프로젝트 문서를 읽고, 사용자가 결정하지 않은 기획을 임의로 확정하지 않으며, 기존 정상 기능을 보호하고, 작업 후 검증 결과와 제가 직접 확인해야 할 사항을 구분하도록 했습니다.
After
이제 AI에게 짧게 새로운 기능을 요청하더라도 기존 프로젝트의 문서와 코드를 먼저 확인하고 이전 작업과 연결해서 개발하도록 할 수 있습니다.
저는 단순히 AI를 사용하는 데서 그치지 않고, AI가 제 프로젝트 안에서 일하는 방식 자체를 설계하고 있습니다.
이러한 과정을 거쳐 현재 Project Limitless에는 캐릭터 생성, 다섯 가지 길과 다섯 직업의 조합, 마을과 필드 탐험, 몬스터 조우, 턴제 전투, 다중 저장과 이어하기 등 실제 RPG를 구성하는 기능들이 하나씩 구현되고 있습니다.
4. 나만의 방식 또는 개선 포인트는 무엇인가요?
제가 AI를 활용하면서 가장 중요하게 생각하는 원칙은
“AI에게 무엇을 만들 것인지까지 맡기지 않는다”는 것입니다.
제가 하는 일은 게임의 세계와 방향을 결정하고, 필요한 기능을 정하고, 장애와 캐릭터를 어떻게 표현할지 결정하고, AI가 만든 결과가 제 의도와 맞는지 판단하는 것입니다.
AI는 제 요구사항을 구현 가능한 구조로 구체화하고, C# 코드 작성과 수정, 오류 원인 분석, Unity 구조 설명 등을 돕습니다.
즉,
결정은 제가 하고,
구현 과정의 장벽을 AI가 낮추며,
최종 결과는 제가 직접 검증합니다.
또한 이 방법을 일회성 대화로 끝내지 않고 GitHub의 프로젝트 규칙과 문서로 만들어 지속적인 개발 과정으로 연결했습니다.
제게 특히 유용했던 것은 많은 기술적 작업을 자연어로 요구사항을 정의하고 결과를 판단하는 과정으로 바꿀 수 있었다는 점입니다.
AI가 제 장애를 없애준 것은 아닙니다.
대신 기존 개발 환경에서 제가 부딪히던 장벽의 일부를 다른 방식으로 해결할 수 있게 해주었습니다.
5. 다른 사람도 따라 할 수 있나요?
이 방식은 장애인에게만 필요한 방법은 아니라고 생각합니다.
코딩 경험이 부족하지만 자신의 아이디어를 구현하고 싶은 사람, 신체적인 이유로 반복적인 입력 작업에 부담이 있는 사람, 혼자서 여러 개발 분야를 다뤄야 하는 창작자에게도 적용할 수 있습니다.
방법도 복잡하지 않습니다.
목표를 먼저 정하고
→ 작은 작업 단위로 AI에게 설명하고
→ 실제 환경에서 실행하고
→ 문제와 기대한 결과의 차이를 다시 AI에게 설명하고
→ 수정한 뒤 다시 확인합니다.
그리고 프로젝트가 커진다면 AI가 따라야 할 규칙과 현재 상태를 문서로 관리하면 더 일관된 협업이 가능합니다.
저 역시 AI의 첫 번째 답이 항상 옳다고 생각하지 않습니다.
오히려 실제 개발을 하면서 오류가 발생하고, 그것을 다시 분석하고 수정하는 과정을 통해 AI를 더 효과적으로 사용하는 방법을 배우고 있습니다.
그 결과물은 이제 단순한 아이디어나 대화 기록이 아닙니다.
실제로 실행하고 플레이할 수 있는 게임, Project Limitless가 되어가고 있습니다.
저는 여전히 중증 뇌병변(뇌성마비) 장애인입니다.
AI를 사용한다고 해서 제 장애가 사라지는 것도 아닙니다.
달라진 것은 제가 할 수 있는 창작의 범위였습니다.
AI는 저 대신 게임을 만들지 않았습니다.
제가 게임을 만들 수 있는 방법을 바꾸었습니다.
저는 중증 뇌병변(뇌성마비) 장애인입니다.
오랫동안 게임을 즐겨왔고, 언젠가는 제가 생각한 세계와 이야기를 직접 게임으로 만들어보고 싶었습니다. 하지만 게임을 좋아하는 것과 실제 게임을 만드는 것은 전혀 다른 일이었습니다.
게임 개발에는 기획뿐 아니라 프로그래밍, Unity 프로젝트 구성, UI 제작, 데이터 관리, 반복적인 테스트와 오류 수정 등 여러 종류의 작업이 이어집니다. 저에게는 장시간의 키보드와 마우스 조작, 반복 입력 같은 작업 역시 개발 과정에서 추가적인 장벽이 됩니다.
제가 부족했던 것은 만들고 싶은 게임에 대한 생각이 아니었습니다.
머릿속의 아이디어를 실제로 작동하는 코드와 게임 시스템으로 옮기는 과정이 문제였습니다.
그래서 ChatGPT와 Codex 같은 생성형 AI를 개발 과정에 활용하기 시작했습니다.
제가 개발하고 있는 게임은 「Project Limitless」입니다.
Unity 6 기반의 2D RPG로, 필드에서는 캐릭터를 직접 움직여 탐험하고 전투에서는 반응속도를 강요하지 않는 턴제 방식을 사용합니다.
게임에는 시각, 청각, 지적, 지체, 마음의 상처라는 다섯 가지 ‘길’이 등장하지만, 특정 길이 특정 직업을 제한하지 않습니다. 모든 길에서 모든 직업을 선택할 수 있습니다.
장애를 특별한 능력의 근원이나 불행을 위한 장치로 사용하는 대신, 캐릭터가 살아온 여러 조건 중 하나로 표현하고 싶었습니다.
그 생각을 실제 게임으로 구현하는 과정에서 AI를 개발 파트너로 활용했습니다.
2. 어떤 AI를 어떻게 활용했나요?
처음에는 AI에게 프로그래밍 방법이나 Unity 사용법을 질문하는 수준이었습니다.
그러나 프로젝트가 커질수록 단순히 그때그때 “코드를 만들어 달라”고 요청하는 방식만으로는 제가 원하는 게임을 일관되게 만들기 어렵다는 것을 알게 됐습니다.
그래서 저는 AI에게 무엇을 시킬지뿐 아니라, AI가 저와 어떻게 일해야 하는지도 정하기 시작했습니다.
Project Limitless의 GitHub 저장소에는 AGENTS.md, CODEX_WORKFLOW.md 같은 AI 개발 규칙이 있습니다.
AI는 작업 전에 프로젝트의 전체 맥락, 현재 개발 상태, 관련 설계 문서와 기존 코드를 먼저 확인해야 합니다. 제가 결정하지 않은 게임 디자인을 임의로 확정해서도 안 됩니다.
기존에 정상 작동하는 기능을 우선 보호하고, 제가 직접 수정한 이미지나 스프라이트를 허락 없이 다시 만들지 않으며, Unity Editor에서 직접 확인하지 못한 내용은 ‘검증 완료’라고 표현하지 않도록 했습니다.
또한 AI가 작성하는 C# 코드에는 Unity 프로그래밍 비전공자인 제가 다시 읽고 이해할 수 있도록 주요 기능과 이유를 한국어 주석으로 설명하게 했습니다.
제가 사용하는 기본 과정은 다음과 같습니다.
제가 요구사항 결정
→ AI가 기존 문서와 코드 확인
→ 구현 방법 논의 및 코드 작성
→ Unity에서 제가 직접 실행·플레이
→ 문제 발견
→ AI와 원인 분석 및 수정
→ 다시 테스트
→ Git commit과 현재 상태 문서 갱신
즉 저에게 AI는 한 번의 명령으로 완성품을 만들어주는 자동 제작기가 아니라, 제가 방향을 결정하고 결과를 검증하면서 반복적으로 협업하는 개발 도구입니다.
3. 활용 결과 어떤 변화가 있었나요?
가장 큰 변화는 머릿속의 아이디어가 실제로 작동하는 게임 시스템으로 바뀌기 시작했다는 것입니다.
사례 1. 단일 저장 기능을 실제 게임용 5슬롯 시스템으로 발전시키다
Before
처음 구현한 저장 기능은 캐릭터 한 명의 진행 상황을 저장하고 이어서 플레이할 수 있는 단일 저장 방식이었습니다.
AI와 협업
실제로 게임을 개발하면서 여러 캐릭터를 독립적으로 관리할 필요가 생겼습니다.
그래서 저는 5개의 독립적인 캐릭터 저장 슬롯, 기존 저장 데이터 보호, 손상된 슬롯이 다른 슬롯에 영향을 주지 않는 구조 등을 요구사항으로 정했습니다.
AI와 기존 저장 코드를 분석하면서 기능을 단계적으로 확장했습니다.
단일 저장·이어하기
→ 5개 캐릭터 저장 슬롯
→ 월드 위치 저장
→ 슬롯 삭제 및 손상 데이터 검증
After
현재는 다섯 개 캐릭터를 각각 저장하고 이어서 플레이할 수 있습니다. 마지막 월드 위치도 저장하며, 손상된 JSON이나 잘못된 데이터는 다른 슬롯을 손상시키지 않고 안전하게 거부합니다.
처음부터 완성된 저장 시스템을 한 번에 만든 것이 아니라, 제가 실제 결과를 사용해 보고 다음 요구사항을 결정하면서 AI와 단계적으로 발전시킨 기능입니다.
사례 2. AI가 만든 결과도 실제 플레이에서 다시 검증하다
턴제 전투를 구현하면서 또 다른 문제가 발생했습니다.
Before
광역 공격을 사용할 때 해당 범위에 공격할 적이 없으면 입력 상태가 꼬여 스킬 메뉴를 정상적으로 조작하기 어려워지는 문제가 있었습니다.
AI와 협업
제가 실제 플레이 과정에서 이 문제를 발견했고, 어떤 상황에서 문제가 생기는지 다시 정의했습니다.
AI와 함께 원인을 분석한 결과, 유효한 대상을 확인하기 전에 전투 UI 상태가 먼저 변경되는 것이 문제였습니다.
그래서 공격 대상을 먼저 검사하고, 대상이 없으면 행동 자체를 실행하지 않도록 수정했습니다.
After
현재는 공격할 대상이 없으면 행동, 턴, 자원, 재사용 대기시간을 소비하지 않습니다.
동시에 스킬 메뉴와 키보드 포커스도 원래 상태로 복구되어 플레이를 정상적으로 계속할 수 있습니다.
이 사례는 제 AI 활용 방식에서 중요한 부분을 보여줍니다.
AI가 만든 코드를 그대로 게임에 넣는 것이 아니라, 제가 실제로 플레이하고 문제를 발견한 뒤 다시 AI와 수정합니다.
사례 3. AI에게도 프로젝트의 개발 규칙을 적용하다
Before
프로젝트 초반에는 AI에게 질문할 때마다 필요한 배경을 다시 설명해야 했고, 프로젝트가 커질수록 이전 기획이나 코드와 다른 제안이 나올 가능성도 커졌습니다.
AI와 협업
그래서 Project Limitless의 GitHub 저장소 자체에 AI가 따라야 할 개발 규칙을 만들었습니다.
AI는 작업 전에 현재 프로젝트 문서를 읽고, 사용자가 결정하지 않은 기획을 임의로 확정하지 않으며, 기존 정상 기능을 보호하고, 작업 후 검증 결과와 제가 직접 확인해야 할 사항을 구분하도록 했습니다.
After
이제 AI에게 짧게 새로운 기능을 요청하더라도 기존 프로젝트의 문서와 코드를 먼저 확인하고 이전 작업과 연결해서 개발하도록 할 수 있습니다.
저는 단순히 AI를 사용하는 데서 그치지 않고, AI가 제 프로젝트 안에서 일하는 방식 자체를 설계하고 있습니다.
이러한 과정을 거쳐 현재 Project Limitless에는 캐릭터 생성, 다섯 가지 길과 다섯 직업의 조합, 마을과 필드 탐험, 몬스터 조우, 턴제 전투, 다중 저장과 이어하기 등 실제 RPG를 구성하는 기능들이 하나씩 구현되고 있습니다.
4. 나만의 방식 또는 개선 포인트는 무엇인가요?
제가 AI를 활용하면서 가장 중요하게 생각하는 원칙은
“AI에게 무엇을 만들 것인지까지 맡기지 않는다”는 것입니다.
제가 하는 일은 게임의 세계와 방향을 결정하고, 필요한 기능을 정하고, 장애와 캐릭터를 어떻게 표현할지 결정하고, AI가 만든 결과가 제 의도와 맞는지 판단하는 것입니다.
AI는 제 요구사항을 구현 가능한 구조로 구체화하고, C# 코드 작성과 수정, 오류 원인 분석, Unity 구조 설명 등을 돕습니다.
즉,
결정은 제가 하고,
구현 과정의 장벽을 AI가 낮추며,
최종 결과는 제가 직접 검증합니다.
또한 이 방법을 일회성 대화로 끝내지 않고 GitHub의 프로젝트 규칙과 문서로 만들어 지속적인 개발 과정으로 연결했습니다.
제게 특히 유용했던 것은 많은 기술적 작업을 자연어로 요구사항을 정의하고 결과를 판단하는 과정으로 바꿀 수 있었다는 점입니다.
AI가 제 장애를 없애준 것은 아닙니다.
대신 기존 개발 환경에서 제가 부딪히던 장벽의 일부를 다른 방식으로 해결할 수 있게 해주었습니다.
5. 다른 사람도 따라 할 수 있나요?
이 방식은 장애인에게만 필요한 방법은 아니라고 생각합니다.
코딩 경험이 부족하지만 자신의 아이디어를 구현하고 싶은 사람, 신체적인 이유로 반복적인 입력 작업에 부담이 있는 사람, 혼자서 여러 개발 분야를 다뤄야 하는 창작자에게도 적용할 수 있습니다.
방법도 복잡하지 않습니다.
목표를 먼저 정하고
→ 작은 작업 단위로 AI에게 설명하고
→ 실제 환경에서 실행하고
→ 문제와 기대한 결과의 차이를 다시 AI에게 설명하고
→ 수정한 뒤 다시 확인합니다.
그리고 프로젝트가 커진다면 AI가 따라야 할 규칙과 현재 상태를 문서로 관리하면 더 일관된 협업이 가능합니다.
저 역시 AI의 첫 번째 답이 항상 옳다고 생각하지 않습니다.
오히려 실제 개발을 하면서 오류가 발생하고, 그것을 다시 분석하고 수정하는 과정을 통해 AI를 더 효과적으로 사용하는 방법을 배우고 있습니다.
그 결과물은 이제 단순한 아이디어나 대화 기록이 아닙니다.
실제로 실행하고 플레이할 수 있는 게임, Project Limitless가 되어가고 있습니다.
저는 여전히 중증 뇌병변(뇌성마비) 장애인입니다.
AI를 사용한다고 해서 제 장애가 사라지는 것도 아닙니다.
달라진 것은 제가 할 수 있는 창작의 범위였습니다.
AI는 저 대신 게임을 만들지 않았습니다.
제가 게임을 만들 수 있는 방법을 바꾸었습니다.
