바이브 코딩으로 어디까지 가능할까? 2, MSA로 아키텍처 대격변

안녕하세요! CNC 입니다.

지난 MVP 런칭 이후, “밥값 내기 게임” 기능을 추가하기로 결정했습니다. 그런데 문제가 생겼습니다. 게임 로직을 수정하다가 실수로 메인 메뉴 추천 서버까지 다운되어 버린 것이죠.

서비스가 커지면 단일 서버(Monolith)는 한계에 봉착합니다. 그래서 저는 결심했습니다. “그래, MSA(Microservice Architecture)로 가자!” AI 동료들과 함께한 대격변의 기록입니다.

🏗️ 서비스 분리: 1개가 4개가 되다

기존에 하나였던 FastAPI 서버를 역할에 따라 4개의 독립적인 컨테이너로 분리했습니다.

  • User App: 사용자 트래픽을 담당하는 메인 메뉴 추천 서비스
  • Pay Game: 결제자 선정 미니게임 전용 서비스 (Socket 통신 고려)
  • Admin: 데이터 시각화 및 관리를 위한 통합 대시보드
  • CMS (Strapi): 모든 서비스가 공유하는 공통 데이터(메뉴, 식당 정보) 저장소

🧩 Headless CMS, Strapi의 도입

가장 큰 변화는 Strapi의 도입입니다. 기존에는 메뉴 데이터를 코드 안에 하드코딩하거나 JSON 파일로 관리했습니다. 수정할 때마다 배포를 다시 해야 했죠.

Strapi를 도입하니 개발자가 아닌 사람도(심지어 AI도) 관리자 페이지에서 클릭만으로 메뉴를 추가하고, 게임 확률을 조정할 수 있게 되었습니다. Headless CMS 덕분에 프론트엔드 변경 없이 데이터만 실시간으로 업데이트하는 유연함을 얻었습니다.

Strapi Page

🐳 Docker Compose & Nginx의 마법

서비스가 4개로 늘어나니 포트 관리부터가 지옥이었습니다. 이를 해결한 구세주가 바로 Docker Compose입니다. 하나의 설정 파일(docker-compose.yml)로 4개의 컨테이너와 DB를 한 번에 실행하고 관리합니다.

또한, 앞단에 Nginx Reverse Proxy를 두어 사용자는 하나의 도메인으로 접속하지만, 내부적으로는 /api/game, /api/user 처럼 경로에 따라 각기 다른 컨테이너로 트래픽을 분산시켰습니다. 이 과정에서 겪은 수많은 CORS 에러와 네트워크 문제는… AI가 없었다면 해결하지 못했을 겁니다.

what now, eat docker compose ps

이제 튼튼한 뼈대가 완성되었습니다. 다음은 이 시스템을 실제로 움직이는 ‘데이터’와 ‘자동화’ 이야기입니다.


🍽️ 오늘 점심, 아직도 고민 중이신가요?
AI 바이브 코딩으로 탄생한 스마트 메뉴 추천 알고리즘!
지금 바로 1초 만에 메뉴를 정해보세요.
🎲 뭐먹지? 추천받으러 가기

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다