소개
저는 바이오·제약 데이터를 분석합니다. 게임을 만들어 본 적이 없고 게임을 즐기지도 않아서, 이 스터디는 제가 가진 것과 가장 멀어 보였습니다.
그런데 스터디장이 첫머리에 이렇게 말했습니다.
저희 게임 스터디지만 게임을 만들고 싶지 않은 분도 오셔서 우리 같이 게임 만들면서 놀면 됩니다. 꼭 게임이 아니 어도 된다.
그래서 질문을 바꿨습니다. 게임을 만들어 본 적은 없지만 브라우저에서 도는 것은 계속 만들어 왔습니다. 분석 리포트를 HTML로 내고, 발표 자료도 HTML로 만듭니다.
그렇다면 제가 만든 것과 게임의 거리는 얼마나 될까. 세어 봤습니다. 생각보다 멀었습니다.
진행 방법
어떤 도구를 사용했고, 어떻게 활용하셨나요?
Tip: 사용한 프롬프트 전문을 꼭 포함하고, 내용을 짧게 소개해 주세요.
Tip: 활용 이미지나 캡처 화면을 꼭 남겨주세요.
Tip: 코드 전문은 코드블록에 감싸서 작성해주세요. ( / 을 눌러 '코드 블록'을 선택)
사용 도구: Claude Code, Python 3
Step 1. 내가 만든 HTML 세기
프로젝트 다섯 곳에서 제가 만든 HTML을 모았습니다. 외부 라이브러리와 빌드 산출물은 뺐습니다.
skip = ('/.git/', 'node_modules', '_site', '/vendor/')
htmls = [p for r in roots for p in r.rglob('*.html') if not any(k in str(p) for k in skip)]
138개였습니다. 적지 않습니다.
Step 2. 처음 기준이 너무 느슨했다
먼저 "사용자 입력을 받는가"를 <button>, onclick, addEventListener 유무로 봤습니다.
결과
값
입력을 받는 것
86개 (62%)
읽기 전용
52개 (38%)
이 숫자는 버렸습니다. 접기·펼치기 버튼 하나만 있어도 걸립니다. 게임과 리포트를 가르는 기준이 못 됩니다.
Step 3. 게임의 조건으로 좁히기
게임이 리포트와 다른 지점을 세 가지로 잡았습니다. 키를 누르면 반응하고, 화면을 직접 그리고, 매 프레임 돌아간다는 것입니다.
조건
검사 대상
해당 파일
키보드 입력
keydown, keyup
4개 (2%)
화면 직접 그리기
getContext(
3개 (2%)
프레임 루프
requestAnimationFrame, setInterval(
3개 (2%)
상태 저장
localStorage
5개 (3%)
(참고) 버튼·토글만
<button>, onclick
86개 (62%)
세 조건 중 둘 이상을 만족하는 파일은 3개였습니다.
Step 4. 그 3개가 무엇인지 확인
3개라면 그래도 몇 개는 있다는 뜻입니다. 체크섬을 떠 봤습니다.
0616faacc12b 509KB econ-radar/slides/econ-radar-harness-2026-06-27.html
b6e2afb878a9 547KB econ-radar/slides/econ-radar-harness.html
b6e2afb878a9 547KB kakyungkim.github.io/assets/decks/econ-radar-harness/index.html
뒤의 둘은 체크섬이 같습니다. 같은 파일을 배포용으로 복사한 것입니다. 앞의 하나는 같은 덱의 이전 버전입니다.
3개가 아니라 실질 1개였습니다.
그리고 그 1개의 키 입력이 무엇인지 봤습니다.
ArrowLeft
ArrowRight
발표 슬라이드를 넘기는 좌우 화살표였습니다.
결과와 배운 점
측정 결과
항목
값
내가 만든 HTML
138개
버튼·토글이라도 있는 것
86개 (62%)
키보드 입력을 받는 것
4개 (2%)
화면을 직접 그리는 것
3개 (2%)
프레임 루프가 있는 것
3개 (2%)
게임 조건 2개 이상 만족
3개 → 중복 제거 시 1개
그 1개의 정체
발표 슬라이드 덱 (좌우 화살표로 넘김)
실제로 만든 게임
0개
배운 점
만들어 온 것과 게임은 방향이 반대였습니다. 제 HTML 138개는 전부 읽히려고 만든 것입니다. 리포트, 논문 요약, 슬라이드입니다. 게임은 놀아지려고 만듭니다. 같은 브라우저에서 도는데 방향이 정반대라, 138개를 만들었어도 게임 쪽으로는 한 발도 안 간 상태였습니다.
기준을 좁히지 않으면 62%가 나옵니다. 처음 기준으로는 "내 산출물의 62%가 상호작용한다"였습니다. 좁히니 2%가 됐습니다. 버튼이 있다는 것과 반응한다는 것은 다릅니다. 앞의 숫자를 그대로 썼으면 "나는 이미 인터랙티브한 걸 만들고 있다"는 반대 결론이 나왔을 것입니다.
파일 개수는 사본을 세는 일이기도 합니다. 3개인 줄 알았던 것이 체크섬을 뜨니 1개였습니다. 배포하면서 복사한 파일이 개수를 부풀립니다. 개수를 세면 반드시 내용도 대조해야 합니다.
스터디장이 게임 개발자가 아니라는 점이 중요했습니다. 컴퓨터 게임을 잘 즐기지도 않는 사람이 스터디를 여는 이유가 "예전에는 만들기 힘들었을 게임이 올해 들어 흔한 게 됐다"입니다. 저처럼 게임과 거리가 먼 사람에게는 그 말이 조건이 아니라 초대로 읽혔습니다.
시행착오
상호작용 여부를 정규식 하나로 판정하려다 62%라는 무의미한 숫자를 얻었습니다. 조건을 셋으로 나누고 각각 세고 나서야 2%가 보였습니다. 하나의 기준으로 성격이 다른 것을 가르려 하면 안 됩니다.
파일 3개를 세고 "그래도 몇 개는 있다"로 넘어갈 뻔했습니다. 크기가 비슷해 이상해서 체크섬을 떠 봤고 두 개가 같은 파일이었습니다.
앞으로의 계획
1주차 사례글용 게임은 제 데이터로 만들 계획입니다. 없는 소재를 새로 만들기보다, 이미 있는 분석 결과를 조작해 볼 수 있는 형태로 바꾸는 쪽이 제 자리에 맞습니다. 값을 바꾸면 결과가 따라 움직이는 것이 게임의 최소 조건과 겹칩니다.
도구는 클로드 코드로 시작합니다. 스터디장이 "테트리스를 만들고 배포까지 양쪽 다 잘된다"고 했고, 저는 이미 클로드 코드를 쓰고 있어 새로 붙일 것이 없습니다.
첫 목표는
getContext를 한 번 써 보는 것입니다. 138개 중 3개에만 있고 그 3개도 제가 게임을 만들려고 쓴 것이 아니라, 제게는 처음 쓰는 도구에 가깝습니다.4주가 끝날 때 읽히는 산출물과 놀아지는 산출물을 각각 하나씩 가지고 있는 것을 목표로 잡았습니다. 지금은 앞쪽만 138개입니다.
도움 받은 글 (옵션)
23기 게임 바이브코딩 1주차 강의 (토옵이): 게임이 아니어도 된다는 스터디 성격, 클로드 코드와 코덱스의 차이, 발표는 쓴 글을 띄워 놓고 게임 화면을 보여 주는 방식, "뭐라도 만들고 뭐라도 이야기하라"는 기준