완벽했던 게임, 그리고 완벽한 실패

방학을 맞은 아이들에게 코딩의 세계를 경험하게 해주고 싶었다. 첫 번째 시도는 AI(lingguang)의 도움을 받아 만든 ‘스페이스 인베이더’ 게임이었다. VS Code를 처음 설치하고, AI가 제안한 코드를 로컬에서 실행했을 때 화면 위로 우주선이 움직였다. 기술적으로는 완벽한 성공이었다.

하지만 정작 사용자인 아이들의 반응을 보자, 나의 모든 가정은 산산조각 났다.

“이게 뭐하는 거예요?”

게임은 잘 돌아갔지만, 아이들은 5분도 채 지나지 않아 “다른 거 하자”며 이탈해 버렸다. 적이 내려오고 총알을 쏘는 단순한 메커니즘만으로는 아이들을 화면 앞에 계속 머물게 할 ‘흥미로운 이유’가 부족했던 것이다. 2주를 투자해 코드를 이해하고 배포하며 나는 바이브 코딩의 가능성을 체감했지만, 그것은 철저히 ‘나의 학습 경험’일 뿐, 정작 서비스의 대상인 ‘아이들의 동기’를 끌어내지는 못했다.

스페이스 인베이더: 기술적 성공, 사용자 관점에서는 실패. 케이팝 퀴즈: 단순한 기술, 폭발적 반응.

전환점: “케이팝 퀴즈”가 보여준 본질

그 실패 직후, 나는 완전히 다른 방식을 시도했다. 코딩의 화려함을 버리고, 아이들에게 친숙한 소재인 ‘케이팝 퀴즈(K-pop Quiz)’ 프로그램을 만들었다.

기술적으로는 훨씬 단순했다. 복잡한 충돌 로직도, 화려한 그래픽도 없었다. 화면에는 단지 “이 뮤직비디오는 어느 가수의 곡일까?“라는 질문과 4개의 선택지만 존재했다.

하지만 반응은 폭발적이었다.

아이들은 10분, 30분씩 화면에서 떨어지지 않았다. 자기 차례를 놓치지 않으려 안달했고, 집에 가서도 “케이팝 퀴즈 다시 하고 싶어”라고 말했다.

이 순간, 내 모든 가정이 뒤집혔다.

아이들은 코딩이 어떻게 짜였는지, 게임의 로직이 얼마나 훌륭한지에는 전혀 관심이 없었다. 오직 퀴즈의 내용, 즉 ‘콘텐츠(Content)’에만 몰입하고 있었다. 두 프로젝트 모두 AI와 대화하며 코드를 복붙하는 같은 기술 스택(Cloudflare 배포, GitHub 저장)을 사용했지만, 결과는 완전히 달랐다.

차이는 단 하나, ‘매일 새로운 것이 나오는가’ 하는 콘텐츠의 다양성이었다.

코더(Coder)에서 시스템 설계자로

이 깨달음은 나의 개발 철학을 송두리째 바꿨다.

사람들을 끌어당기고 유지하는 것은 ‘코드의 정교함’이 아니라 ‘경험의 질’이었다. 나는 더 이상 예쁜 디자인이나 깨끗한 코드를 작성하는 데 시간을 낭비하지 않기로 선언했다. 대신 초등학교 5~6학년을 대상으로 한 폐쇄형 소셜 플랫폼, ‘무지개 유치원(Rainbowkidz)’ 프로젝트를 기획하며 목표를 완전히 재정의했다.

나의 새로운 목표는 “매일 아이들이 하고 싶을 정도로 재미있는 콘텐츠를 끝없이 공급하는 시스템을 만드는 것”이었다.

병목 현상은 이제 ‘코딩’이 아니라 ‘콘텐츠 생산 속도’로 이동했다. 사람이 하루에 퀴즈 10~20개를 직접 만드는 것은 한계가 뚜렷했다. 이 병목을 돌파하기 위해 나는 화면 중심의 자바스크립트에서, 자동화와 파일 처리에 압도적으로 유리한 파이썬(Python)으로 도구를 바꿨다.

AI의 진짜 가치는 ‘코드’가 아니라 ‘생산 속도’다

파이썬 스크립트를 통해 AI에게 “K-pop 퀴즈 50개를 한국 노래 제목과 뮤직비디오로 생성해”라고 요청하자, 불과 15분 만에 작업이 끝났다. 사람이 며칠을 고민해야 할 분량이 순식간에 쏟아져 나왔다.

파이썬 스크립트 ← AI → 무지개 유치원 콘텐츠. 자동화 파이프라인의 탄생.

이 과정에서 나는 AI의 진정한 가치를 재발견했다. AI는 단순히 코드를 대신 짜주는 도구가 아니었다. 나의 하루 가용 시간(약 1시간) 안에서, 혼자서는 절대 불가능했던 ‘압도적인 콘텐츠 생산 속도’를 만들어주는 엔진이었다.

이때부터 나는 질문의 방향을 바꿨다.

❌ “코드를 더 잘 짜려면 어떻게 해야 할까?”
✅ “어떻게 하면 콘텐츠를 더 빨리, 다양하게 자동 생성할 수 있을까?”

이것이 나를 ‘코딩하는 사람’에서 ‘파이프라인을 운영하는 사람’으로 이끈 첫 번째 결정적 전환점이다. 완벽한 기술을 추구하는 대신, 매일 새로운 퀴즈와 이야기가 자동으로 갱신되는 ‘지속 가능한 운영 시스템’을 설계하기 시작한 것이다.

다음 글에서는

방향은 정해졌다. 하지만 나에게 주어진 현실은 하루 종일 개발에 매달릴 수 있는 전업 프로그래머의 환경이 아니었다.

다음 글에서는 하루 1시간(출근 전과 점심시간), 그리고 Mac mini와 아이폰이라는 파편화되고 제한된 환경이 어떻게 나를 가장 효율적인 아키텍처(Cloudflare + Supabase 기반의 Zero-Install Web App)로 강제했는지, 그 치열한 생존기를 다룬다.

제약 조건: 시간, 기기 다양성. 해답: Cloudflare + Supabase. 결과: 가장 효율적인 설계.

제약은 방해물이 아니라, 완벽한 설계를 강제하는 최고의 조건이었다.