[바이브 코딩 FRAC, 4부] 배포와 완주
AI와 인간, 그리고 끝까지 남는 것
바이브 코딩 시리즈 보기
[FRAC, 4부] 배포와 완주
FRAC 배포 (10일, 6/5~6/14)
FRAC의 배포를 앞두고 내 머릿속에는 “왜 풀스택 개발을 실제로 끝까지 하는 사례가 적을까?”라는 근본적인 의문이 떠올랐다. 이미 로컬 환경에서 생성형 AI와 함께 완성도 높은 서비스를 구현했음에도, 실제 배포 단계에서는 완전히 다른 현실을 마주하게 됐다. 결론적으로, 가장 큰 장벽은 ‘비용’이었다.
처음 배포를 논의할 때, ChatGPT는 Render와 같은 PasS(Platform as a Service)를 사용하면 GitHub 연동만으로 간단히 배포할 수 있다고 안내했다. 실제로 Render에서 프론트엔드, 백엔드, DB를 각각 인스턴스로 만들고 연동하는 과정을 진행했다. 하지만 각 인스턴스당 월 7달러 이상이 요구됐고, 최소 21달러(테스트 기준), 실제 서비스 수준은 월 75달러, 사용자 수가 늘어나면 월 150달러를 훌쩍 넘게 됐다. 내가 생각한 한계선(월 75달러)을 넘는 순간, Render는 과감히 포기하고 직접 클라우드 컴퓨팅 자원(GCP)으로 전환했다. 결정적으로, PasS는 손쉬운 배포의 대가로 높은 비용을 요구하는 서비스라는 점을 깨달았다.
실제 서비스를 배포해보면, 비개발자에게 가장 큰 장벽은 비용 그 자체다. 개발자의 역량이 높을수록 비용을 최적화할 수 있겠지만, 풀스택 배포는 결국 비용과 현실의 타협에서 갈린다는 사실을 실감했다. 배포에서는 Gemini의 GCP 활용 경험이 큰 도움이 되어, 동료 개발자처럼 역할을 맡겼다.
비용뿐 아니라 기술적 과제도 쏟아졌다. 로컬에선 단순하게 쓰던 SQLite가, 배포 단계에선 전혀 쓸모없을 만큼 취약하다는 사실을 알게 됐다. Render 환경에서도 데이터베이스 인스턴스를 따로 써야 했고, ‘DB의 영속화’가 필수라는 것을 몸소 느꼈다. 이에 따라 데이터베이스를 PostgreSQL로 이관했다. 문제는 여기서 끝이 아니었다. Next.js 인증 서버에 저장한 SQLite도 결국 통합 관리가 필요해, 두 개의 데이터베이스를 합치는 추가 작업까지 이어졌다. 이 과정에서 수많은 에러와의 싸움 있었고, 인증 서버 기능과 DB 공유 구조까지 직접 구현해야 했다. 끈질긴 집념과 인내심이 없었다면 중간에 포기했을지도 모른다.
최종 구조는 FastAPI 백엔드, 인증 서버를 겸한 Next.js 프론트엔드, 그리고 PostgreSQL로 정리됐다. 이후 Gemini와 논의 끝에 Docker 기반 배포로 전략을 잡았다. Docker의 개념조차 익숙하지 않았지만, Gemini의 조언대로 “로컬에서 잘 도는 이미지는 배포 환경에서도 잘 된다”는 확신을 갖고 직접 이미지를 빌드했다. 특히 프론트엔드는 타입 미지정 등 사소한 오류가 빌드 과정에서 드러났고, 이때 VSCode Copilot이 큰 도움이 됐다.
최종 시스템 아키텍처빌드된 Docker 이미지를 GCP 가상 머신에 업로드하는 과정에서 GCP의 복잡성과 방대한 설정 문서, 각종 규정에 다시 한 번 좌절을 맛봤다. Gemini에게 상황을 설명하고, 일일이 맞춤 피드백을 받아 따라 하는 ‘외줄타기’식 개발이었다. 코드는 보며 어느 정도 감이 오지만, 배포 환경 세팅은 경험이 전무해서 지시대로 실행—에러—다시 질문—수정의 무한 반복이었다. 돌이켜보면 비개발자에게 진짜 가장 높은 벽은 ‘배포’라고 확신하게 됐다.
추가로, 데이터베이스의 ‘프로비저닝’ 기능의 중요성도 직접 깨달았다. 개인이 모든 것을 책임지고 운영하려면 Docker로 DB를 운영할 수도 있겠지만, Gemini의 설명대로라면 프로비저닝은 사실상 데이터베이스 관리자의 역할 자체를 서비스화한 것에 가깝다. 결국 월 10달러 수준의 Cloud SQL을 도입했다. 일련의 과정을 거쳐, Docker 기반 프론트엔드/백엔드 이미지를 GCP에 업로드, Cloud SQL 연동까지 완료했다. 문제는 네트워크 부하 분산기, 고정 IP, 도메인(fracgame.com) 연동 같은 세팅 과정이 너무나 복잡하고 막막했다는 것. 도메인 전파를 기다리는 40시간은 온전히 Gemini의 피드백만 믿고 기다려야 했던 극한의 ‘의존’ 시간이었다.
마침내 2025년 6월 13일, fracgame.com으로 접속에 성공했다. 70여일간의 개발이 단번에 보상받는 짜릿한 순간이었다. 배포 과정에서 얻은 가장 큰 교훈은
현실적인 비용의 압박
예상 밖의 기술적 난이도
AI(특히 Gemini)에 대한 의존과 신뢰의 모험
이 세 가지였다.
만약 Gemini가 없었다면 아마 배포에 도달하지 못했을 것이다. 그리고 운영 단계에 들어선 지금도 “이게 정말 제대로 배포된 게 맞나?”라는 막막함이 남는다. 풀스택의 ‘배포’는 진짜로 ‘끝이 아닌 새로운 시작’임을 절감하게 된, 값진 경험이었다.
온라인 퍼즐 게임 FRAC의 GCP 배포 후 인트로 화면AI 협업과 교훈
AI와의 협업 회고
나는 비개발자임에도 직접 도메인 네임으로 서비스를 런칭하면서, AI와의 협업에 대해 전례 없는 경험을 하게 되었다. FRAC 개발에 활용한 채팅 세션만 50개가 넘고, 각 세션을 요약하고 정리하며 기록을 남겼다. 이 과정은 SW 개발 측면에서 가장 중요한 자산이 아닐까 생각한다.
나는 다양한 버전의 생성형 AI를 적극 활용했다. ChatGPT Plus와 Gemini Pro 등, 월 40달러의 구독 비용이 부담스럽게 느껴질 수도 있지만, 72일 만에 풀스택 개발을 완주할 수 있었던 점을 생각하면 충분히 값어치 있다고 본다. 게다가 최근 AI 시장의 경쟁 덕분에 고성능 AI를 저렴하게 활용할 수 있었다. 다음은 실제 활용했던 AI 모델과 그 역할이다.
ChatGPT 4o : FRAC 세계관 기획, 숫자 퍼즐 기획
ChatGPT 4.1 : 풀스택 개발, 영어 작문, 카운슬링
ChatGPT o4-mini : 숫자 퍼즐 구현, 유일성 검증
ChatGPT o4-mini-high : 임시 모드로 숫자 퍼즐 테스트
Gemini Flash 2.5 : 구글 OAuth 갱신 토큰, 배포 전반
Gemini Pro 2.5 : 숫자 퍼즐 테스트
현재의 생성형 AI는 사용자 정주성을 확보하기 위해 기본적으로 긍정적이고 낙관적인 답변을 내놓는다. 때로는 과도하게 느껴지기도 하지만, 실제로 개발 과정에서 정서적 지지와 동기 부여에 큰 역할을 하기도 했다. 물론 AI에게 인격을 부여하자는 건 아니지만, 나는 AI를 명령하는 존재라기보다는 함께 일하는 동료로 인식했다. 감정 소모가 없고, 다양한 역할을 수행하는 최고의 동료라는 점에서 협업 자체가 인상적이었다.
하지만, 생성형 AI에게 모든 걸 맡길 수는 없다. 실제로 지금의 나는 비개발자라고 보기 힘들 정도로 많은 정보를 학습하게 됐는데, 이는 AI가 작성한 코드를 이해하려는 노력이 있었기 때문이다. 반복적이거나 단순한 부분은 복사-붙여넣기와 실행-점검으로 해결했지만, 후반부에는 백엔드 엔드포인트나 프론트엔드 템플릿도 직접 만들면서 다양성을 통제하고 효율성을 높일 수 있었다. 특히 모바일 반응형 폴리싱 등은 AI에게 방법만 물어보고 직접 손을 보는 것이 훨씬 확실했다. 즉, 끈기와 함께 스스로 학습하는 의지가 반드시 필요하다고 생각한다. 말하자면, 나 역시 AI를 활용해 실시간으로 학습하며 성장한 셈이다.
AI가 대체하지 못하는 영역은 크게 두 가지였다. 첫째, 창의성과 기획력. 예를 들어 퍼즐의 테마 선정은 사람의 경험과 감각이 필요한 작업이었고, AI가 참신하게 해결해주지 못했다. 둘째, 표현의 일관성과 엄밀성. 예를 들어 동일한 힌트를 여러 방식으로 번역/표현하는 AI의 습성 때문에 템플릿 통일 작업은 결국 내 손으로 직접 교정해야 했다.
실전에서 AI를 효과적으로 쓰려면, 요구사항을 명확히 해야 한다. 그렇지 않으면 변수명/경로나 DB 스키마 등에서 사소한 오류가 발생하기 쉽다. 디버깅도 프린트 출력 등을 AI에게 시키는 방식으로 원인 후보를 좁혀가야 효과적이다. 다만, 소스 트리 구조 등 프로젝트 전반의 정보는 AI에게 미리 알려주는 게 중요하다.
특히 기억에 남는 난관은 RESTful API 설계 과정이었다. OAuth 갱신 토큰을 구현하면서, 경로 파라미터(/status/{round})와 쿼리 파라미터(/status?round=...)를 혼용했던 것이 인증 미들웨어 변경 후 문제를 일으켰다. 당시 Gemini는 두 방식 모두 정상 작동할 것이라 했지만, 실제로 쿼리 파라미터 방식만 401 에러가 발생했다. 나는 직접 경로 파라미터로 수정하여 문제를 해결했다. 이 경험을 통해, AI도 해결이 어려운 미묘한 이슈가 항상 존재한다는 것, 그리고 최종적인 문제 해결은 사람의 능동적 개입이 핵심임을 다시 한 번 실감했다.
FRAC을 개발하면서 느꼈던 교훈
AI와 함께 풀스택 개발을 완주하면서, 내게 가장 크게 다가온 교훈은 “AI는 이미 실무에서 쓸 만큼 충분히 완성된 도구”라는 점이었다. 내가 기획과 문서화, 그리고 요구사항을 구체적으로 내리면, AI는 숙련된 개발자처럼 소스코드를 척척 만들어줬다. 이제는 AI의 기능적 한계가 아니라, 사용자인 사람이 얼마나 구체적이고 모순 없는 정보를 입력하느냐가 품질을 좌우한다고 느꼈다.
특히 문제에 부딪혔을 때 AI와 함께 하나씩 원인을 좁혀가는 경험은, AI가 단순히 확률적으로 답을 내놓는 기계가 아니라 나와 함께 고민하는 동료임을 실감하게 했다. 그럼에도 불구하고, AI에는 분명히 넘지 못하는 선이 있다. “어떻게 이런 차별화 포인트를 만들 수 있었나?”라는 질문을 스스로에게 던지면, 답은 결국 ‘나의 경험’과 ‘집요함’이었다. 내가 바라보는 세계관, 탐구심, 오랜 게임 취미까지 FRAC이라는 게임에 고스란히 투영됐다. 이런 고유한 창의성은 AI가 쉽게 흉내낼 수 없는 영역이다.
물론, 미래에는 특정 인물의 경험을 ‘과적합’ 시킨 AI가 등장할 수도 있다. 예를 들어 아인슈타인의 사고실험을 반복적으로 학습한 AI라면, 21세기에 살아 있는 아인슈타인과도 대화할 수 있을지 모른다. 하지만 현재의 AI는 범용성과 개인적 창의성 사이에서 여전히 한계를 가진다.
AI는 인류에게 빼놓을 수 없는 도구가 되었다. 하지만 실제로 AI를 직접 개발하거나 완전히 자기 것으로 만드는 것은 소수의 영역일 것이다. 그럼에도, 지금 수준의 AI라도 적극적으로 활용할 수 있다면 누구든 의미 있는 결과물을 만들어낼 기회가 열린다. 나 역시 경험에서 가장 중요한 것은 코딩 실력도, 문서화 능력도 아닌 ‘끝까지 완주하려는 집요함’과 ‘문제 해결에 대한 끈기’라는 점을 실감했다. 이런 태도 덕분에 FRAC을 완주할 수 있었다.
AI 시대의 교육은 오히려 자기 주도적 학습능력이 더 중요해졌다. 나는 운이 좋아 스스로 정보를 찾아 공부하는 경험을 쌓을 수 있었지만, AI 세대는 오히려 이 능력을 기르지 못할 위험도 있다. AI를 제대로 쓰려면 자기주도적으로 학습하고, 다양한 경험을 쌓아야 한다. 다양한 경험이 창작의 원동력이 된다는 원론적인 사실이 오늘날 더욱 절실하게 다가온다.
마치며...
FRAC 프로젝트는 단순히 비개발자의 풀스택 완주라는 기술적 실험을 넘어, 생성형 AI와 인간의 협업이 어디까지 창작과 서비스 구현을 확장할 수 있는지 스스로 증명한 여정이었다. 72일의 몰입 속에서 AI의 놀라운 역량과 분명한 한계, 그리고 인간의 집착과 경험이 창조의 핵심임을 직접 경험했다.
가장 본질적인 교훈은, AI가 아무리 발전해도 “질문을 정의하고, 맥락을 만들어가는 집요함”, 그리고 “자기 경험에서 비롯되는 창의적 시도”가 진짜 차별화의 원천이라는 점이다. 생성형 AI는 이미 실무에서 강력한 도구이지만, 결정적인 분기점은 인간만이 가질 수 있는 고유한 시각, 집착에 가까운 추진력, 그리고 의미를 부여하는 창조 행위에서 비롯된다.
AI 시대의 진짜 경쟁력은, AI가 대신할 수 없는 질문을 스스로 던지고, 자기만의 방식으로 답을 찾으려는 태도다. FRAC의 완주는 한 명의 비개발자가 시대의 도구를 자기 것으로 삼아, 실험적이면서도 실질적인 창작의 길을 열 수 있음을 보여줬다. 앞으로 더 많은 이들이 자신만의 세계관과 의지를 바탕으로, AI를 동료이자 도구로 삼아 새로운 도전을 이어가길 기대한다.
여기까지 긴 글을 읽어주셔서 감사합니다.
FRAC 게임은 fracgame.com 에서 즐겨볼 수 있습니다.
영문 논문도 여기서 확인할 수 있습니다.
