[POP-SPOT] 팝업스토어 정보 찾기가 불편해서 직접 만들었습니다

솔직히 처음엔 만들 생각이 없었음.

팝업스토어 정보를 찾으려면 인스타그램 뒤지고, 카카오 지도 검색하고, 브랜드 공식 계정 들어가서 날짜 확인하고... 이걸 매번 반복하는 게 너무 귀찮았음. "아 그냥 내가 만들면 되겠다" 싶어서 시작한 프로젝트임.

뭘 만들었냐면

팝업스토어 정보를 한 곳에서 보고, 같이 갈 사람도 구하고, AI가 이동 동선까지 짜주는 서비스임.

처음 기획할 때는 기능이 5개 정도였는데... 개발하다 보니 어느새 API가 54개가 됨. 처음 생각이랑 많이 달라졌음.

기술 스택

용어 설명

- 백엔드: 사용자 눈에 안 보이는 서버 쪽 코드. 데이터 저장, 로직 처리 담당

- 프론트엔드: 사용자 눈에 보이는 화면 쪽 코드

- DB(데이터베이스): 데이터를 저장하는 창고. PostgreSQL은 창고 종류 중 하나

- Redis: 자주 쓰는 데이터를 빠르게 꺼낼 수 있게 따로 보관하는 임시 저장소

- 인프라: 서버가 돌아가는 컴퓨터 환경. GCP는 구글이 운영하는 클라우드 서버

왜 이 스택을 골랐냐면

Spring Boot — 부트캠프에서 Java를 제일 많이 배웠고, 실제로 써보니 편의 기능이 많아서 선택함. 쓸수록 잘 만들어진 프레임워크라는 걸 느낌.

Next.js — React 기반으로 화면을 만드는 프레임워크. 서버에서 미리 페이지를 만들어줘서 검색엔진에 잘 노출되는 장점이 있음. 팝업스토어 서비스 특성상 검색 노출이 중요해서 선택.

TypeScript — 처음엔 그냥 JavaScript 써도 될 것 같았는데, 코드가 많아질수록 없으면 버그 찾기가 너무 힘들어짐. 쉽게 말하면 코드에 규칙을 강제로 지키게 해주는 도구.

GCP — 구글에서 무료 크레딧을 줘서 선택함. 근데 나중에 서버 메모리 부족으로 서버가 하루에 2~3번씩 죽는 사태가 벌어짐. 그 이야기는 따로 정리해뒀음.

프로젝트 폴더 구조

popspot-backend/          # 서버 코드 (Spring Boot)
  ├── config/             # 보안, 소켓, AI 설정 파일들
  ├── controller/         # 클라이언트 요청을 받는 곳 (21개)
  ├── service/            # 실제 기능 처리 로직
  ├── entity/             # DB 테이블 구조 정의
  └── repository/         # DB에 저장/조회하는 코드

popspot-frontend/         # 화면 코드 (Next.js 14)
  ├── app/                # 페이지 파일들
  ├── components/         # 재사용하는 UI 조각들
  └── lib/                # 서버 통신, 유틸 함수

폴더 구조를 이렇게 나누는 이유는 역할별로 코드를 분리해서 나중에 찾기 쉽게 하기 위함. 요리로 치면 냉장고, 조리도구, 식재료를 각각 다른 곳에 정리해두는 것과 같음.

혼자 만드는 프로젝트라 복잡한 구조는 적용 안 했음. 유지보수가 가능한 범위 안에서 단순하게 구성한 게 오히려 나았음.

다음 글에서는 실시간 채팅 기능 구현하면서 만났던 에러들을 정리해볼 예정.