← 개발놀이터 오락실로 돌아가기
🎮 게임 개발 스터디 23기

1주차 오프라인 밋업,
같이 만들어볼 준비를 했습니다

평소에는 온라인으로 만나는 스터디가, 이번 주에는 한 번 오프라인으로 모였습니다. 개발 환경을 함께 맞추고 웹과 AI 도구의 기본 원리를 살펴보며, 각자 만들고 싶은 게임 이야기를 나눴습니다.

2026년 7월 25일오프라인 밋업참석 8명

01이번 주, 잠시 오프라인으로 모였습니다

게임 개발 스터디 23기는 평소 온라인으로 진행됩니다. 이번 주에는 화면 너머에서 각자의 작업을 이어가던 분들이 한자리에 모여, 앞으로 게임을 만드는 데 필요한 도구와 흐름을 함께 짚어보는 시간을 가졌습니다.

윈도우 환경에서 필요한 개발 도구를 설치하고 실행 여부를 같이 확인했습니다. 익숙하지 않은 설치 과정도 있었지만, 하나씩 해결해 가며 “막히면 같이 보고 풀면 된다”는 분위기를 자연스럽게 만들 수 있었습니다.

🧰

개발 환경 준비

Claude Code와 Codex 등 필요한 도구를 함께 설치하고, 낯선 환경도 차근차근 확인했습니다.

🧠

웹과 AI의 기본 원리

캐시가 왜 생기고, AI 도구는 대화의 맥락을 어떻게 다루는지 살펴봤습니다.

🎲

게임 아이디어 나누기

진행 중인 프로젝트와 고민을 공유하며 서로의 다음 작업을 응원했습니다.

02함께한 분들을 소개합니다

스터디장

토옵이

22기 영상 스터디를 거쳐, 이번 23기 게임 스터디를 이끌고 계십니다.

스터디원

윤yoon

17기부터 참여해 오셨고, 게임 개발로 기술을 익히며 일주일 만에 많은 것을 깨달았다고 들려주셨습니다.

부스터디장 · 스터디원

은쌤T

토옵이님과 과거 영상 스터디도 함께 진행하셨던 든든한 동료입니다.

스터디원

백구우

중급 과정이라 망설였지만, 누구나 참여할 수 있다는 이야기에 용기 내어 함께해 주셨습니다.

스터디원

아가타

지피터스는 처음이지만, 차근차근 적응하며 질문과 탐색을 이어가고 계십니다.

스터디원

이병관

블로그와 영상 등 여러 회차를 경험하셨고, 게임 요소를 더해보기 위해 영상 바이브 코딩에도 참여하셨습니다.

스터디원

박예빈

13기 참여 경험을 바탕으로, 4학년이 된 지금 다시 게임 개발에 도전하고 계십니다.

스터디원

송세현

12기부터 활동해 오셨고 스터디장을 세 차례 맡으셨습니다. 현재는 Godot 기반 스팀 게임을 준비 중입니다.

03먼저 짚어본 개발 이야기

게임을 만들기 전에, 작업하면서 자주 만나게 될 개념부터 실제 상황에 연결해 살펴봤습니다. 웹페이지의 수정 내용을 배포했는데도 이전과 동일하게 보일 때부터, AI와 오래 대화하며 작업을 이어가는 방법까지 이후 스터디에서 반복해서 만나게 될 문제들이었습니다.

웹에서 수정한 내용이 안 보일 때

브라우저는 같은 CSS·JS 파일을 다시 받지 않도록 저장해 둡니다. 그래서 배포 뒤 화면이 그대로라면 캐시를 의심해 보고, 파일 이름이나 버전을 바꾸는 캐시 버스팅으로 새 파일을 읽게 할 수 있다는 점을 배웠습니다.

AI가 대화 맥락을 잃지 않게 하려면

AI 코딩 도구는 이전 대화를 함께 읽으며 작업하기 때문에, 대화가 길어질수록 속도와 비용에 영향을 줍니다. 컨텍스트가 가득 차면 대화는 요약·압축되고, 그 뒤에는 작업 감각이 달라질 수 있습니다. 작업 목표와 요구사항을 AGENTS.mdCLAUDE.md 같은 프로젝트 파일에 남기고, 큰 일은 작은 과업으로 나누는 방법을 나눴습니다.

헤르메스 같은 에이전트 도구는 무엇이 다를까요?

헤르메스나 오픈클로 계열 도구는 사용자가 세션의 압축과 공간 관리를 계속 의식하지 않도록 돕는다는 점을 살펴봤습니다. 대신 코딩 전용 도구는 아니고, 실시간 확인 같은 동작이 토큰 사용량에 영향을 줄 수 있습니다. 어떤 도구를 쓰든 프로젝트의 맥락을 파일로 남겨두는 습관이 안전한 출발점이라는 데 의견이 모였습니다.

게임 개발 프롬프트도 하나의 자료가 됩니다

현장에서는 토옵이의 게임 개발 프롬프트 기록도 함께 보았습니다. 영상 제작처럼 같은 프롬프트를 그대로 따라 하기보다, 게임은 장르와 규칙에 따라 요청이 달라집니다. 그럼에도 어떤 순서로 기획을 말하고, 밸런스·그래픽·버그를 어떻게 요청했는지 보면 “이 사람은 이렇게 게임을 만들었구나”라는 작업의 흐름을 배울 수 있습니다.

프롬프트 로그는 어떻게 남길까요?

토옵이가 프롬프트를 자동으로 쌓아두는 방법과, 그 기록을 왜 남기는지 설명했습니다. 프롬프트만 저장해도 당시 무엇을 바꾸려 했는지와 어떤 판단을 했는지 다시 따라갈 수 있고, 최근 기록에는 에이전트가 한 답변의 요약도 함께 붙여두어 나중에 훑기 쉽게 만들 수 있습니다. 설정 방법과 의미는 프롬프트 로그 기록 글에도 정리되어 있습니다.

닫은 세션도 다시 찾을 수 있을까요?

Claude Code와 Codex는 사용자가 입력한 프롬프트와 에이전트의 답변을 PC 로컬에 자동으로 남깁니다. 창을 닫거나 exit한 뒤에도 기록은 유지되지만, 기본 보관 기간은 30일입니다. “6개월로 늘려줘”, “1년으로 늘려줘”처럼 도구에 요청해 보관 기간을 늘려두면 예전 작업의 세션·프롬프트를 검색하고 복원하는 데 활용할 수 있습니다. 직접 만든 프롬프트 로그와 별개로, 도구 자체의 기록도 충분히 꺼내 쓸 수 있다는 점을 확인했습니다.

처음 만드는 게임의 엔진은 무엇이 좋을까요?

Godot처럼 무료 엔진을 고려할 수 있지만, 이번 스터디에서는 우선 웹에서 가볍게 완성해 보는 경험에 집중합니다. 빠르게 만들고, 바로 반응을 확인하며 다음 버전을 고쳐 가보기로 했습니다.

04각자의 게임 이야기를 자세히 나눴습니다

이번 자리에서는 단순히 아이디어를 소개하는 데서 멈추지 않고, 실제로 어디까지 만들었는지와 다음에 부딪힐 문제를 함께 이야기했습니다. 화면을 어떻게 보여줄지, 자산과 움직임을 어떻게 만들지, AI 캐릭터가 어떤 대화를 해야 하는지까지 대화가 이어졌습니다.

윤yoon님의 헤르메스 시각화: 온라인 오피스를 게임처럼

윤yoon님은 에이전트 ‘헤르메스’가 하는 일을 온라인 오피스처럼 보이는 대시보드로 시각화하는 프로젝트를 소개해 주셨습니다. 각 에이전트가 하나의 작업 공간, 혹은 방을 오가며 맡은 일을 수행하는 모습이 한눈에 보이도록 만드는 것이 핵심입니다.

윤yoon님은 원래 크레이지 아케이드·봄버맨 같은 게임을 만들어볼까 생각하셨지만, 지금은 헤르메스 오피스를 더 업그레이드하는 방향도 함께 고민하고 계신다고 말씀해 주셨습니다. 게임을 새로 만드는 일과 이미 만들어 둔 온라인 오피스형 화면을 더 잘 다듬는 일 사이에서, 다음 작업의 방향을 살펴보는 이야기였습니다.

송세현님의 덱빌딩 로그라이크: 밸런스 다음의 화면과 움직임

송세현님은 ‘슬레이 더 스파이어’에서 영감을 받은 덱빌딩 로그라이크를 준비하고 계십니다. 약 300장의 카드를 만들고 디자인보다 먼저 밸런스를 중심으로 시뮬레이터를 다듬고 계셨는데, 이제는 카드와 유닛에 어떤 이펙트·애니메이션을 입힐지 고민이 시작된 시점이었습니다.

이야기는 먼저 메쉬(Meshy)로 3D 모델을 만들고, 믹사모(Mixamo)의 준비된 모션을 적용하는 방법으로 시작했습니다. 다만 작은 게임을 빠르게 완성하는 흐름에서는, 그록(Grok)이나 영상 생성 AI로 캐릭터의 동작 영상을 만든 뒤 프레임을 나누어 스프라이트로 활용하는 길도 함께 살펴봤습니다. “완성도 높은 리소스를 처음부터 모두 직접 만들지 않아도 된다”는 점, 그리고 파티클·타격감·카드 등장 같은 작은 효과가 플레이 감각을 크게 바꾼다는 점이 중요한 힌트로 남았습니다.

박예빈님의 1인 AI 머더 미스터리: 추리와 캐릭터챗 사이

박예빈님은 AI 용의자가 사람처럼 변명하고 거짓말하다가, 플레이어가 증거를 제시하면 조금씩 흔들리거나 결국 실토하는 1인용 AI 머더 미스터리를 만들고 계십니다. 단순히 정답을 맞히는 퀴즈가 아니라, 용의자와 대화하며 단서를 모으고 추리를 진행하는 게임을 목표로 하고 있습니다.

대화는 자연스럽게 캐릭터챗 서비스와 연결되었습니다. 토옵이님이 이전에 웹툰 캐릭터챗 개발을 시도했던 경험을 나누며, 동적인 게임을 구현하는 일이 더 어려워 보이지만 사실은 텍스트로 내용을 전달하는 게임을 재미있고 자연스럽게 만드는 일이 훨씬 어렵다는 이야기가 나왔습니다.

그래서 머더 미스터리의 핵심 과제는 화면이나 선택지 자체가 아니라 대사로 이야기를 전달하는 일에 있습니다. 등장인물이 어떤 말투로 말해야 하는지, 같은 정보라도 어떤 뉘앙스로 건네야 하는지, 플레이어가 다음 장면을 궁금해하도록 어떻게 감정을 쌓을지를 만들어야 합니다. 머더 미스터리처럼 스토리가 중심인 게임에서는 결국 좋은 대사와 흐름을 쓰는 일이 소설을 쓰는 일에 가깝고, 그 부분이 가장 공들여야 할 과제라는 이야기를 나눴습니다.

05그래픽 리소스도 함께 살펴봤습니다

이미지와 그래픽은 어떻게 준비할까요?

투명 배경이 필요한 게임 리소스에는 PNG 같은 래스터 이미지가 편하고, 벡터(SVG)는 화면 크기에 맞춰 다루기 좋다는 차이부터 이야기했습니다. Codex의 이미지 생성, Claude Code에 이미지 도구를 연결하는 방법, 배경 제거와 캐릭터 자산으로의 활용까지 함께 살펴봤습니다. 게임의 화면을 한 번에 완벽하게 만들기보다, 필요한 자산부터 작게 실험해 보기로 했습니다.

API와 MCP는 어떻게 다른가요?

API는 다른 서비스에 요청을 보낼 때 지켜야 하는 규격이고, MCP는 AI가 자연어 요청을 이해해 적절한 API를 쓰도록 연결하는 통로에 가깝다고 정리했습니다. 이미지 생성처럼 외부 기능을 AI 도구에 붙일 때 이 둘이 어떤 역할을 맡는지 짚어보는 시간이었습니다.

캐릭터의 움직임과 이펙트는요?

메쉬(Meshy)로 3D 모델을 준비하고 믹사모(Mixamo)의 모션을 적용하는 방법부터, 그록(Grok) 같은 생성형 영상 도구로 동작을 만든 뒤 프레임을 뽑아 스프라이트로 쓰는 방법까지 여러 길을 살펴봤습니다. 제미나이·GPT 등으로 만든 캐릭터 이미지를 영상 도구에 넣어 옆모습이나 공격 동작으로 이어가는 흐름도 참고했습니다. 파티클처럼 작은 효과도 게임의 손맛을 크게 바꿀 수 있다는 이야기가 인상적이었습니다.

만들고 나면 누구에게 보여줄까요?

게임은 한 번 완성하고 끝나는 것이 아니라, 플레이한 분들의 반응을 보며 수치를 조정하는 과정입니다. 매번 새로운 테스트 그룹을 구하기 어려운 만큼, 홍차넷이나 지피터스 네트워킹 방처럼 이미 편하게 의견을 주고받는 커뮤니티가 좋은 출발점이 될 수 있습니다. 밸런스 수치 하나까지도 코드 에디터에서 직접 고치기보다 채팅으로 AI에게 요청하며, 제작자는 점점 매니저처럼 게임을 조율할 수 있다는 경험도 나눴습니다.

06이미지가 붙으면 게임의 분위기가 달라집니다

이번 오프라인 자리에서는 이미지 리소스를 게임 화면에 붙이는 방법도 오래 이야기했습니다. 같은 규칙과 구조를 가진 게임도 어떤 자산을 쓰느냐에 따라 전혀 다른 인상을 줄 수 있다는 점을, 실제 작업 사례와 함께 확인했습니다.

숲 배경과 캐릭터 그래픽 리소스가 적용된 타워디펜스 게임 화면 참고 이미지

지녕님의 타워디펜스 이야기에서, 토옵이의 길막TD까지

지녕님의 타워디펜스 게임에서 이미지 리소스를 만드는 방법을 이야기하다가, 토옵이가 만든 길막TD의 두 버전도 함께 꺼내 보았습니다. 홍차넷 버전은 이모지로 규칙과 재미를 빠르게 검증한 버전이고, 오락실 버전은 그래픽 어셋을 붙여 화면의 분위기를 한 단계 끌어올린 버전입니다. 같은 게임도 리소스가 달라지면 몰입감과 읽는 맛이 얼마나 달라지는지 나란히 확인할 수 있었습니다.

어두운 마을 배경과 역할 카드, 캐릭터 리소스가 구성된 한밤의 늑대인간 게임 제작 참고 이미지

박승현님의 한밤의 늑대인간: 분위기를 설계하는 이미지

박승현님의 한밤의 늑대인간 제작 이미지도 함께 살펴봤습니다. 캐릭터 표정, 역할 카드, 테이블과 배경, 작은 아이콘까지 같은 톤으로 이어지면서 게임의 세계관이 한 장면 안에서 전달되는 사례였습니다.

07함께 본 참고 영상

현장에서는 게임 리소스를 빠르게 만들 수 있는 방법도 함께 살펴봤습니다. 다음 작업 때 다시 보기 쉽도록 두 편을 남겨둡니다.

08테스트와 수익화, 다음에 이어갈 이야기

머더 미스터리의 테스트는 왜 특별히 어려울까요?

스토리를 한 번 알게 된 플레이어는 같은 시나리오를 처음처럼 테스트하기 어렵습니다. 그래서 새로운 사람을 계속 만나야 하는 머더 미스터리의 특성, 그리고 AI에게 처음 보는 플레이어처럼 역할을 맡겨 테스트를 도울 수 있을지에 대해서도 이야기가 이어졌습니다. 쉽지 않은 과제지만 충분히 탐색해 볼 만한 방향으로 남았습니다.

1인 개발로 수익화를 시도할 수 있을까요?

수익화를 목표로 하는 관점과 순수한 취미로 만드는 관점이 함께 나왔습니다. 덱빌딩 로그라이크는 카드·효과·조합의 반복성을 잘 설계하면 1인 개발로도 플레이 시간을 넓혀갈 가능성이 있다는 의견이 있었습니다. 반면 실제 결제와 운영은 콘텐츠 품질, 테스트, 지속적인 조정까지 함께 고민해야 하는 긴 과제라는 점도 솔직하게 나눴습니다.

이제, 각자의 첫 버전을 만나볼 차례입니다

이번 주 오프라인 자리에서는 도구를 설치하고, 질문을 나누고, 만들고 싶은 게임을 서로 소개했습니다. 다음 온라인 모임에서는 오늘 나온 아이디어가 조금 더 실제 화면과 움직임으로 이어질 예정입니다. 천천히라도, 재미있게 같이 만들어보겠습니다.