바이브코딩 게임 개발, 어디까지 되나 테스트해봤습니다

🎮🤖 논쟁의 출발점: 게임 개발에서 AI를 둘러싼 3가지 진영

게임 개발 분야에서는 AI 활용에 대한 반응이 찬반으로 크게 갈리며, “개발은 몰라도 AI만 쓰면 된다”는 찬성파, “버그·일관성 문제로 실무 수준이 아니다”는 반대파, “AI는 발전하지만 개발자는 계속 코딩을 알아야 한다”는 중도파로 의견이 정리됩니다. 이러한 대립을 실제 작업으로 검증하기 위해, 일주일가량 유니티 개발을 실무처럼 진행하며 전 과정에서 AI를 적극 활용했고, 결과적으로 “현재 시점에서 AI가 게임 개발 직업을 대체하는가”를 현실적인 개발 환경에서 점검하는 접근을 택했습니다.

🧭📱 실험 설계: ‘트리플A’ 대신 평균적인 2D 모바일 양산형에 초점

AI로 트리플A 게임이 가능한지 같은 논쟁은 개인이나 소규모 팀이 애초에 달성하기 어려운 목표를 기준으로 삼아 실효성이 낮다는 관점이 제시됩니다. 핵심은 “일반적인 게임 개발자”의 업무를 AI가 대체할 수 있느냐이며, 한국 시장이 모바일 중심이고 2D 비중이 높으며 중소·스타트업 비율이 크다는 점을 고려해 2D 모바일 양산형 게임을 실험 대상으로 삼습니다. 게임 장르 자체는 부차적이며, 실제로 시간이 많이 드는 지점은 전투 로직보다 데이터 처리, 레벨 디자인, 프레임워크·아키텍처 구축처럼 “게임이 돌아가게 만드는 환경”이라는 현실을 전제로 실험의 타당성을 확보합니다.

🧩🛠️ 출발점과 전환: ‘대충 만든 데모’에서 구조적 리팩토링으로

초기 프로토타입은 챗GPT로 급하게 만든 수준으로, 스크립트 수가 적고 기능 분리가 거의 없는 “막 만든 형태”로 시작합니다. 이후 AI에게 프로젝트 분석을 시켜 레포 상태와 구조를 파악하게 한 뒤, 본격적으로 리팩토링을 진행하며 설계 기반의 구조로 전환합니다. 이 과정은 한 번의 지시로 끝나는 “딸깍”이 아니라, 계획 수립 → 승인 → 단계별 적용 → 오류 수정의 반복으로 진행되며, 대규모 리팩토링에서는 사람도 오류를 수정하며 완성하듯 AI도 같은 방식으로 다루어야 한다는 관점이 강조됩니다.

🧠📄 일관성 문제의 해법: 규칙 문서화로 ‘기억’과 품질을 고정

AI가 요청마다 불일치한다는 비판에 대해, 클로드 코드가 프로젝트 루트에 마크다운 문서를 만들고 핵심 규칙을 기록·참조하는 방식이 소개됩니다. 사용자가 “반드시 지킬 규칙, 금지 행동, 컨벤션, 설계 방식”을 문서에 명시하면 AI가 작업 전 이를 확인하고 준수해 일관성이 크게 좋아졌다는 경험이 제시됩니다. 특히 설계 없이 요구하면 최적화에 불리한 코드(예: 매 프레임 무거운 검출 수행 등)가 나올 수 있으나, 규칙과 작업 방식을 선제적으로 정해두면 비효율을 줄이고 코드 퀄리티를 높일 수 있다는 결론으로 연결됩니다.

🏗️🧪 리팩토링 운영 방식: 계획 검토·승인·분할 실행과 오류 수습

리팩토링 요청 시 AI가 먼저 계획서를 제시하고, 추상 클래스와 상속 구조, 디자인 패턴 활용 등 구조적 설계를 포함한 작업 방안을 단계별로 제안합니다. 승인 후에는 스크립트가 대폭 늘어날 정도로 구조가 커지며, 단계 단위로 나눠 진행하는 방식이 효율적이라는 운영 경험이 공유됩니다. 코드가 완전히 바뀌면 기존 씬이 깨지는 것은 자연스러운 결과이므로, AI에게 테스트용 새 씬과 편의 기능(예: 상단 탭 버튼)을 구현시켜 검증 환경까지 갖추는 흐름이 만들어지며, 핵심은 “반복 지시와 검증을 통해 안정화시키는 개발 루프”입니다.

🗺️📊 실무 핵심 검증: 스테이지·데이터 제작을 에디터 자동화로 전환

모바일 게임 개발에서 스테이지마다 몬스터 구성, 경로, 등장 수, 레벨 디자인이 반복되는 현실을 고려해, AI에게 유니티 에디터 스크립팅을 요청해 제작 효율을 검증합니다. 설계를 먼저 제시한 뒤 요청하자, 플레이하며 수작업으로 만들 필요 없이 에디터에서 초기 위치·범위·몬스터·경로 등을 지정하고, 스테이지용 ScriptableObject(SO)를 생성해 데이터만 입력하면 스테이지가 구성되는 체계가 구현됩니다. 몬스터 이동 방식·피격 방식·비주얼 정보 등 서로 다른 SO들이 결합되고, 이를 총괄하는 몬스터 SO와 스테이지 SO가 상호 참조하는 복잡한 구조에서도 구현이 안정적으로 진행되며, “반복 제작을 자동화하는 실무형 개발”에 AI가 강점을 보인다는 평가로 이어집니다.

📑🔁 엑셀 기반 파이프라인: CSV → SO 자동 생성으로 데이터 워크플로우 완성

“실무에서는 엑셀로 데이터를 관리한다”는 반론까지 포함해, 프로젝트를 훑어본 뒤 데모 엑셀(또는 CSV)을 만들고 이를 읽어 SO를 자동 생성하는 임포트 툴을 제작하는 흐름이 구현됩니다. 임포트 메뉴, 미리보기, 파일 누락 시 경고 표시(색상 변화), 전체 임포트 버튼으로 일괄 생성까지 갖추며, 데이터 입력만 바꾸면 게임 내 시스템이 이를 읽어 스테이지에 반영되는 자동화 파이프라인이 완성됩니다. 이는 단순 기능 구현을 넘어 “레벨·유닛·스킬 데이터가 늘어나도 운영 가능한 제작 체계”를 AI가 빠르게 구축할 수 있음을 보여주는 사례입니다.

🖼️🧷 UI 제작과 한계: MCP로 정확도는 올리되 후처리는 필요

UI는 그림판으로 대략적인 시안을 만든 뒤 AI에게 전달하고 설명을 덧붙여 구현하도록 하며, 이때 코드 생성만으로 부족한 부분은 MCP를 통해 유니티에 직접 작업 지시를 내려 정확도를 높이는 방식이 활용됩니다. 클릭 한 번으로 프리팹을 생성하는 편의 기능, 인스펙터 연결 자동화 등 실무 친화적 결과가 나오지만, 피봇·앵커 같은 UI 정렬 요소는 개발자가 일부 손보는 후처리가 필요하다는 한계도 확인됩니다. 그럼에도 전체 UI를 빠르게 구축하는 데에는 충분히 실용적이라는 판단으로 정리됩니다.

📝🧑‍💼 문서화까지 포함한 개발: 온보딩 문서 생성과 토큰 비용

개발 속도가 빨라질수록 신규 투입 인력이 구조를 따라가기 어려워지므로, AI에게 신입 개발자용 온보딩 문서 제작을 맡겨 문서화 품질을 검증합니다. 프로젝트 세팅 방법, 코드 구조, 기능 설명, 사용 방법, 향후 개발 과제 등이 비교적 상세히 정리되어 실무 문서로 쓸 만한 수준이라는 평가가 나오며, 동시에 문서 생성은 프로젝트 전체를 훑는 과정이 필요해 토큰 소모가 크다는 운영상 비용이 함께 제시됩니다.

✅🕹️ 결과물 데모: 복잡한 데이터 얽힘 속에서도 기능 구현은 지속 가능

며칠간의 작업 결과로 로그인 씬(익명 로그인), 메인 씬, 스테이지 선택, 25개 유닛 구성, 상점 UI, 보상·강화 반복 루프 등 기본 플레이 사이클이 구현됩니다. 리소스 작업은 제외했지만, 스크립트 수와 SO 파일 수가 크게 늘고 상호 참조가 복잡해진 상태에서도 AI가 작업을 이어갈 수 있었던 점이 핵심 성과로 제시됩니다. 또한 “장르가 단순해서 가능한 것”이라는 반론에 대해, 실제로 시간이 많이 드는 지점은 로직 자체보다 프레임워크·데이터·에디터·자동화 구축이라는 점이 재확인됩니다.

🎯👨‍💻 결론: AI는 ‘대체’가 아니라 ‘실무 가속’이며, 운용자는 개발자

AI가 게임 개발 실무에 도움 될 수준으로 성장했으나, 이를 제대로 활용하려면 알고리즘·패턴·최적화 같은 개발 지식과 경험이 필수라는 결론입니다. 에디터 툴 제작, CSV→SO 자동화처럼 “필요를 발상하고 설계를 정의하는 일”은 개발 경험이 없으면 요청 자체가 어렵고, 결국 AI에게 적절한 명령을 내려 품질과 방향을 통제할 수 있는 주체는 개발자라는 판단입니다. 따라서 현 단계에서 AI는 개발자를 대체하기보다는, 개발자가 설계와 검증을 주도하며 생산성을 크게 끌어올리는 도구로 자리 잡고 있다는 결론으로 정리됩니다.

⏱️🔁 현실적 전제: ‘며칠 만에 완성’이 아니라 반복 검증이 개발의 본질

작업 과정은 요청 → 검증 → 수정의 반복으로 진행되며, 한 번에 매끄럽게 끝나는 흐름이 아니라 시행착오를 줄이기 위한 전략 수립과 재시도가 지속되었다는 점이 강조됩니다. 게임 개발은 본래 최소 수개월 이상이 필요한 작업이므로, 단기간에 완성하지 못하는 것은 AI의 실패가 아니라 개발의 정상적인 속성으로 제시됩니다. 이 실험은 “딸깍 완성”이 아니라 실무 개발 프로세스에 AI를 끼워 넣었을 때 어디까지 가속이 가능한지를 확인한 사례로 귀결됩니다.