[바이브 코딩 FRAC, 2부] 시스템 아키텍처/차별화
기획이 실제가 되기까지
바이브 코딩 시리즈 보기
[FRAC, 2부] 시스템 아키텍처 / 차별화
FRAC 시스템 아키텍처
FRAC 문제 기획은 34일에 걸쳐 이루어졌고, 실제 서비스까지는 추가로 35일이 소요되었다. 비개발자가 풀스택 개발 과정을 처음 경험하면서 시스템 아키텍처도 그만큼 변화가 많았다. 나는 프론트엔드와 백엔드라는 용어만 어렴풋이 알고 있었고, 각각을 구현하는 다양한 프레임워크가 있다는 정도만 인지하고 있었다. 실제로 FRAC의 구조를 직접 설계하기보다는, ChatGPT에게 추천을 받아 선택을 진행했다. 그 결과, 초기에는 SQLite 데이터베이스, 파이썬 기반 FastAPI 백엔드, React 기반 Next.js 프론트엔드, 그리고 tailwind CSS로 구성하게 되었다.
시스템 아키텍처 (MVP)사용자 인증은 Google OAuth만 사용했고, 프론트엔드에서 모든 백엔드 접근 시 OAuth 인증을 강제했다. 또한 프론트엔드에는 FRAC 문제와 관련된 정보는 일절 저장하지 않고, 항상 백엔드와의 통신을 통해서만 정보를 얻는 구조로 구현했다. 하지만 초기에 구현한 Google OAuth는 로그인 후 약 1시간 뒤 세션이 만료되는 현상이 있었다. ChatGPT와의 논의 끝에 “갱신 토큰(refresh token)” 개념을 알게 되었으나, OAuth 인증에 대한 사전 지식이 전무했던 나에게 이 과정은 큰 난관이었다. 이후 대안으로 Gemini를 활용하여 구글 공식 문서를 참고해 갱신 토큰을 성공적으로 구현했다. 이 과정에서 Next.js에 인증 서버를 새로 구현하고, 별도의 SQLite 데이터베이스를 두어 갱신 토큰을 저장했다. 결과적으로 시스템 아키텍처에 인증 서버가 추가되는 변화가 있었다.
시스템 아키텍처 (인증 서버 추가)모든 기능을 완성한 뒤에는 배포 단계에 들어갔다. 처음에는 GitHub와 연동이 쉬운 Render 플랫폼을 선택했다. 그러나 배포 과정에서 SQLite 데이터베이스를 영속적으로 관리해야 한다는 점을 깨달았다. Render와 같은 서비스는 코드를 수정하거나 서버를 재실행할 때마다 데이터베이스가 초기화되는 구조임을 알게 되었고, SQLite는 본질적으로 로컬 테스트에 적합한 데이터베이스임을 실제로 체감했다.
이 문제를 해결하기 위해 기존 SQLite에서 PostgreSQL로의 마이그레이션을 진행했다. 그런데 프론트엔드의 인증 서버 역시 별도의 SQLite 데이터베이스를 사용하고 있어서, 최종적으로 두 데이터베이스를 FastAPI 백엔드에서 사용하는 PostgreSQL로 통합하는 추가 작업이 필요했다. 이 과정은 비개발자인 나에게 가장 큰 도전이었지만, 성공 이후에는 큰 자신감을 얻게 되었다. 데이터베이스 영속화 이후에는 프론트엔드, 백엔드, 데이터베이스의 3단 구조로 시스템 아키텍처가 단순해졌다.
시스템 아키텍처 (데이터베이스 통합)그 다음에는 구글 클라우드 플랫폼(GCP)에 배포하기 위해 Docker 컨테이너를 활용했다. 데이터베이스는 관리·백업·보안 등 유지보수가 쉽도록 Cloud SQL(프로비저닝 DB)을 사용했다. Cloud SQL은 최소 월 10달러의 비용이 들지만, 운영의 편의성을 위해서라면 합리적인 선택이었다.
최종 시스템 아키텍처클라우드 컴퓨팅 리소스는 e2-medium을 선택했고, 여기에 프론트엔드와 백엔드 Docker 이미지를 업로드해 배포를 완료했다. e2-medium의 서울 리전 기준 월 사용료는 31달러 정도이고, 네트워크 비용도 100명당 약 5달러 수준으로 산정되었다. 결과적으로 전체 서비스의 월간 운영 비용은 약 46~50달러로, 자신의 작품을 세상에 공개하는 비용으로 이 정도가 적정한지 여부는 각자의 판단에 달려 있다.
FRAC 차별화 포인트와 주요 원칙
FRAC은 8자리 수를 예측하는 게임이다. 이 수를 맞히는 과정에서, 생성형 AI의 도움을 받게 될 것이라는 점을 처음부터 염두에 두었다. 생성형 AI가 없다면 스스로의 지식만으로 풀어야 하겠지만, 요즘은 누구든 막히면 AI에게 물어볼 수 있기 때문에, AI의 개입을 전제로 게임 난이도를 설계하게 되었다. 물론 이 선택은 난이도를 높이고, 경우에 따라 사용자 이탈로도 이어질 수 있지만, 오히려 사용자가 적극적으로 AI를 활용하도록 유도하는 것이 필요하다고 판단해 Guide와 Rules에도 이를 명시했다. 숫자 퍼즐에 익숙하지 않은 사용자도 AI를 활용해 문제를 풀 수 있다는 점에서 긍정적인 경험이 될 수 있다고 본다.
FRAC의 퍼즐 문제 예시 (Cycle 0, Cycle 1)FRAC에서 AI의 가장 큰 역할은 '규칙 찾기'다. Cycle 0만 하더라도 다양한 규칙과 조합이 문제에 사용되었다. 초반에는 가장 쉬운 규칙을 적용한 문제로 시작해서, AI든 사람이든 규칙을 직접 체득하게 한다. 이를 통해 유사 규칙을 반복적으로 경험하며 점점 복잡한 조합도 익히게 된다. 나는 이런 과정을 일종의 학습 곡선으로 설계했다. 문제를 풀수록 다양한 규칙과 조합을 자연스럽게 익히도록 했다.
규칙과 조합을 많이 알수록 문제를 더 잘 풀 수 있지만, 막힌다면 언제든 AI에게 지금까지 알아낸 규칙을 설명하면서 함께 풀 수도 있다. 실제로 이런 접근은 무한한 문제 공간을 한정적으로 좁혀가는 효과가 있다. FRAC은 AI 활용을 제한하지 않고, 오히려 독려함으로써, 생성형 AI 시대에 새로운 유형의 퍼즐을 제안했다고 자부한다.
단, AI에게 묻는 것만으로는 쉽게 풀리지 않는 문제도 일부러 기획했다. 예를 들어, 어떤 집합의 수들이 특정 규칙을 따르는지 직접 검증해야 하는 유형은, 생성형 AI가 전체 수의 집합을 일일이 기억하거나 한 번에 추론하기 어렵다. 물론 채팅 세션에서 코딩이 가능한 추론형 AI에 물어보면 풀 수도 있지만, 문제의 의도를 정확히 파악해야만 그런 접근이 가능하다.
여기까지가 FRAC의 퍼즐과 AI 협업이라는 본질적인 특성이라면, 이제는 서비스 철학에 대해 얘기할 차례다. FRAC은 광고가 전혀 없는 무료 게임이다. 수익은 전적으로 후원에 의존한다. 광고가 없는 무료 게임을 찾기 힘들다는 것은, 클라우드 운영 비용만 확인해봐도 쉽게 알 수 있다. 나는 게임 분위기를 해치는 광고 배너가 너무 싫었고, 비용 회수를 위해 유료 아이템을 도입하는 것도 FRAC의 정체성에 맞지 않는다고 봐서 과감히 무료 공개를 선택했다. 1년 정도 서비스를 목표로 운영하고, 후원 기반이 한계에 도달하면 오픈소스화나 교육 플랫폼 전환 등 다양한 옵션도 염두에 두고 있다.
마지막으로, FRAC의 디자인 원칙은 단순함과 일관성이다. 나는 디자인을 전공하지 않았지만, 과도한 애니메이션은 배제하고 깔끔함과 통일성을 지향했다. 버튼 클릭 시 미세한 픽셀 움직임, 반응형 디자인, 모바일 테스트 등 군더더기 없는 UI에 집중했다. 이미지 편집 경험이 없어서 인포그래픽도 코딩으로 직접 구현했고, 덕분에 외부 템플릿이나 이미지에 의존하지 않고, 저작권·유지보수·완성도 측면에서 자유롭고 견고한 웹페이지를 만들 수 있었다. Guide 페이지의 모든 시각자료 역시 타입스크립트로 직접 작성한 코드의 결과물이다.
FRAC 게임은 fracgame.com 에서 즐겨볼 수 있습니다.
영문 논문도 여기서 확인할 수 있습니다.
