NFT 티켓은 왜 상태 흐름이 먼저였을까?

문제 상황

BASE CHAIN은 단순한 예매 화면이 아니라 야구 경기 목록, 좌석 예매, NFT 입장권, QR 검표, 공식 재판매, 팬 카드 조각 거래가 이어지는 서비스였습니다.

이 과정에서 가장 조심해야 했던 부분은 화면보다 상태 흐름이었습니다. 사용자가 보는 티켓 상태, 서버 DB에 저장된 예매 상태, NFT 발급 상태, 재판매 상태가 서로 어긋나면 서비스 신뢰가 바로 깨질 수 있었습니다.

또한 로컬에서는 동작하던 화면이 오라클 서버에 올라간 뒤에는 DNS, HTTPS, API 프록시, CORS, 정적 파일 경로 문제 때문에 빈 화면처럼 보이는 문제가 발생했습니다.

해결 방법

프론트엔드는 정적 파일로 빌드해서 Caddy가 직접 서빙하고, 백엔드 API는 별도 Node.js 서비스로 분리했습니다.

사용자 브라우저
  -> Caddy HTTPS
  -> 정적 프론트엔드 파일
  -> /api 요청은 Node.js API 서버로 프록시
  -> MariaDB에 경기, 좌석, 티켓, 재판매 상태 저장

좌석 예매 흐름에서는 서버 DB를 기준으로 좌석 상태를 먼저 확인하고, 티켓 생성 이후 NFT 민팅 상태와 트랜잭션 정보를 별도로 기록하도록 분리했습니다.

배포 과정에서는 다음 문제를 순서대로 확인했습니다.

DuckDNS 도메인이 실제 오라클 IP를 바라보는지 확인

HTTPS 접속 시 Caddy 인증서가 정상 발급되는지 확인

프론트 빌드에서 API 주소가 로컬 주소로 박혀 있지 않은지 확인

브라우저에서 `/api/tickets/games`가 정상 응답하는지 확인

오라클 용량을 줄이기 위해 빌드 결과와 실행에 필요한 파일만 남김

배운 점

블록체인 기능은 붙이는 것보다 상태를 맞추는 과정이 더 중요했습니다.

NFT 티켓은 온체인 발급 결과와 서버 DB 상태가 같은 의미를 가져야 하고, 사용자는 그 복잡한 과정을 하나의 티켓 상태로 이해할 수 있어야 합니다.

또한 실제 배포에서는 코드보다 운영 환경 문제가 더 크게 보일 때가 많았습니다. DNS, HTTPS, 프록시, 빌드 환경 변수, 서버 용량을 함께 봐야 실제로 보여줄 수 있는 프로젝트가 된다는 점을 배웠습니다.