제약을 설계의 조건으로 재정의하다
‘무지개 유치원’ 프로젝트를 시작하며 세운 비전은 명확했다. “매일 새로운 콘텐츠로 아이들을 불러 모으는 시스템”을 구축하는 것이었다. 하지만 이 거창한 목표를 실현하기 위해 마주한 현실은 매우 척박했다. 나는 온종일 코드와 씨름할 수 있는 전업 개발자가 아니었기에, 나에게 주어진 시간과 환경은 기술적 선택을 원천적으로 제한했다.
전통적인 개발 방식에서 제약은 극복해야 할 장애물이지만, 바이브 코딩(Vibe Coding)의 관점에서 제약은 최적의 구조를 강제하는 ‘설계의 조건’이 된다. 나는 나의 일상이 가진 한계를 정면으로 응시하며, 그 좁은 틈새에서도 지속 가능한 개발 루프를 만들어야 했다.
파편화된 시간과 장비라는 현실
나의 하루는 일정하지 않은 짧은 조각들로 나뉘어 있었다. 출근 전의 짧은 여유 시간과 점심시간의 짬, 그리고 이동 중의 자투리 시간이 내가 가진 전부였다. 이를 모두 합쳐도 하루에 온전히 집중할 수 있는 시간은 단 1시간 남짓에 불과했다.
장비 역시 파편화되어 있었다. 사무실에 두고 쓰는 Mac mini M2는 안정적이지만 사용 시간이 한정적이었고, 이동 중에는 iPhone을 통해 구조를 점검하거나 아이디어를 수정해야 했다. 또한 집의 MacBook Air는 하루의 작업을 갈무리하고 확장하는 용도로 쓰였다.
이러한 **’단속적 사용 환경’**은 나에게 무거운 개발 세팅이나 복잡한 빌드 과정을 허용하지 않았다. 매번 환경을 동기화하거나 설정을 만지느라 시간을 보내면, 실제 결과물을 만드는 데 쓸 30분조차 남지 않기 때문이었다.
생존을 위한 기술 스택: ‘Cloudflare + Supabase’
결국 기술 스택의 선택은 제 취향이 아니라 **’생존 조건’**에 의해 결정되었다. 로컬 서버를 항상 관리해야 하거나 배포가 복잡한 기술은 과감히 버렸다. 대신 **”최소한의 기술로, 최대한 자동화하고, 어디서든 즉시 접속할 수 있어야 한다”**는 세 가지 원칙을 세웠다.
그 결과 선택된 것이 Cloudflare Pages, Workers, 그리고 Supabase의 조합이다.
- Cloudflare Pages: 코드를 GitHub에 푸시하는 것만으로 전 세계 모든 엣지 노드에 자동 배포되므로 별도의 서버 관리가 필요 없었다.
- Cloudflare Workers: 서버리스 API로서 유지 보수 비용과 서버 운영의 부담을 거의 ‘0’으로 만들어 주었다.
- Supabase: 복잡한 백엔드 구축 없이도 데이터 저장, 인증, 스토리지 문제를 한 번에 해결해 주었다.
이 조합은 파편화된 장비들 사이에서 ‘동기화의 마찰’을 제거해 주었다. 내가 어디서 어떤 기기로 코드를 수정하든, 푸시 한 번이면 전 세계 아이들이 보는 화면이 즉시 업데이트되는 지속 가능한 파이프라인이 완성된 것이다.
초등학생을 위한 ‘Zero-Install Web App’
사용자인 아이들의 환경 또한 강력한 제약 조건이었다. 초등학교 5~6학년 아이들은 앱 설치를 귀찮아하고 복잡한 로그인을 극도로 싫어한다. 특히 카카오톡 인앱 브라우저를 주로 사용하는 환경은 일반적인 PWA 설치 유도가 거의 작동하지 않는 거대한 벽이었다.
나는 이 문제를 해결하기 위해 ‘설치 없는 웹앱(Zero-Install Web App)’ 구조를 설계했다. 별도의 주소를 기억할 필요 없이 카카오톡 대화방에 남겨진 고정 링크가 홈 화면의 역할을 하게 했다. 클릭과 동시에 브라우저에서 실행되며, 기기 기반의 식별을 통해 로그인 과정 없이 즉시 활동을 이어가게 만든 것이다.
이 선택은 기술적으로는 단순했지만, 결과적으로 사용률을 비약적으로 증가시키는 결정적 요인이 되었다. 가장 좋은 디자인은 기술을 뽐내는 것이 아니라 사용자의 마찰을 없애는 설계임을 다시 한번 깨달았다.
완벽함보다 ‘지속 가능성’을 선택하는 용기
하루 1시간의 시간표 안에서 “완벽한 코드”를 쓸 자리는 없었다. 전통적인 개발 문화에서 강조하는 정교한 아키텍처나 철저한 테스트는 나의 리듬을 파괴하는 사치에 가까웠다. 무지개 유치원의 코드는 주석이 부족하고 변수명이 모호할 때도 많았다.
하지만 나의 평가는 냉정했다. “이 코드가 아이들의 하루 재미를 만드는가?”, “내가 1시간 안에 수정하고 복구할 수 있는가?”. 이 두 질문에 ‘YES’라고 답할 수 있다면, 그 코드는 나에게 ‘완벽한 코드’였다. 바이브 코딩은 나에게 코드를 정복하려는 욕심을 버리고, 시스템을 굴리는 운영자의 감각을 선물해 주었다.
다음 글에서는
제약에 맞춘 도구를 선택하고 파이프라인을 구축했지만, 예상치 못한 곳에서 거대한 마찰이 발생했다. 바로 “진짜 개발자라면 당연히 써야 한다”고 믿었던 GitHub였다.
다음 글에서는 협업과 무결성의 상징인 GitHub가 왜 초기 바이브 코딩의 실험 속도를 방해하는 거대한 마찰이 되었는지, 그리고 내가 그 도구의 지위를 어떻게 재정의했는지를 다룬다.
제약이 좋은 설계를 만든다면, 때로는 ‘좋은 도구’가 나쁜 마찰을 만들기도 한다.