지역별 매장에서 사용 가능한 결제 수단을 보여주는 웹 서비스입니다. 각 기업에서 제공하는 다양한 페이 서비스가 매장마다 지원되는 종류가 달라 불편함을 겪고 있습니다. 특히 애플페이가 국내에 도입되면서 이러한 불편함을 크게 느꼈고, 이에 따라 특정 매장에서 어떤 결제 수단을 사용할 수 있는지 보여주는 지도를 만들고자 했습니다.
- 김민수
- 네이버 API 및 공공데이터 API 활용 능력 향상
- CICD를 위한 도커, Git Action 학습 및 적용
- 이현동
- Typescript 학습 및 활용
- NEXT.JS를 통한 SSR 학습 및 활용
- 네이버 지도 API를 사용하여 외부 API 활용 능력 향상
- 도커, Git Action, EC2를 사용한 웹앱 서비스 운영
- Typescript
- React
- Next.js
- React-query를 통한 서버 통신 상태 관리
- Zustand를 통한 전역 상태관리
- Vanilla-extract를 통한 스타일링
- Spring
- JDK
- Gradle
- DB
- MySQL + JPA, QueryDSL
- 관계형 데이터베이스 관리 및 최적화
- Git Action
- CI 단계를 위한 Git Action 설정
- Docker 이미지 생성 후 Public Repository에 저장
- Docker
- 서비스 컨테이너화
- 네이버 검색 API를 사용하여 현대카드로 결제 가능한 매장 데이터 저장
- 매장명, 위치, 분류 등의 데이터를 활용하여 사용자가 원하는 요청에 맞는 데이터를 전송
- 사용자 희망 조건 입력 페이지
- 애플페이, 네이버페이, 지역화폐 등 사용자가 원하는 페이만 필터할 수 있음.
- 페이 지도 페이지
- 사용자가 선택한 결제 수단이 가능한 매장만을 지도에 표시하여 마커로 표시.
- 오류 정보 신고 페이지
- 사용자가 페이 지원 여부를 신고하고, 관리자가 검토하여 정보 삭제 가능.
TypeScript | Next.js | React Query | Stomp |
Java | Spring-Boot | Spring-JPA | Spring-Security | Stomp | MySQL |
NGiNX | AWS | Docker | GitHub Actions |
Git | Discord | Figma | Notion |
-
공통
-
API 문서 작성하기
-
API
-
-
프론트엔드
- Naver MAP API를 활용한 지도 서비스 구현하기
- Typescript를 사용하여 Next.js 사용하기
- React-query를 사용하여 상황에 맞는 상태 관리하기
- Git Action을 통한 CICD 파이프라인 구성 (Git, GitAction, Docker, AWS EC2)
- Stomp를 사용하여 채팅 서비스 구현하기
-
백엔드
- Naver API를 활용한 매장 데이터 저장하기(Python, Docker, Mysql)
- Spring 프로젝트 기본 세팅하기 (Java, Spring, Mysql, Docker, Spring Data JPA, QueryDSL)
- API에 따른 기능 구현하기
- Stomp를 사용하여 채팅 서비스 구현하기
- HTTPS 구현하기 (Nginx - 리버스 프록시)
- Git Action을 통한 CICD 파이프라인 구성 (Git, GitAction, Docker)
- 데이터 요청 시 전송 방식: request param, path variable, request body
- 네이버 API 요청 데이터 범위 정의
- CICD사용 결정
- Jenkins or Git Action
- 젠킨스와 깃액션 이전에 둘 다 학습을 해본 경험이 존재한다. 다만 젠킨스의 경우 사용가능한 인원이 백엔드 한명이기에, 코드관리를 위한 깃에서 제공하는 Git Action을 사용하는 편이 더 좋다고 판단하였다. Git Action의 경우 Git에서 발생하는 이벤트의 트리거를 바탕으로 동작하고, 작성시 상황에 맞는 템플릿을 제공하기에 학습곡선이 낮다고 판단하였다. 그런 이유를 바탕으로 Git Action을 바탕으로 진행을 하기로 결정하였다.
- CICD를 위한 도커 단일 컨테이너와 쿠버네티스 적용 고민
- 쿠버네티스는 CICD를 위해 필수적인 도구, 다만 현재 프로젝트의 경우 사이드 프로젝트이다. 프로젝트의 크기를 생각하였을 경우 쿠버네티스 적용을 위해서는 작업해야하는 양이 더 많아진다는 단점이 존재한다. 그만큼의 효율을 못 가져온다고 판단하여 기존 EC2배포를 사용하기로 결정하였다.
- Jenkins or Git Action
- 전역 상태 관리 라이브러리 Zustand 설치
- 고객 상담 봇 백엔드 사용 여부 결정
-
CORS 문제
- CORS 설정 오류로 인한 접근 불가
- Spring Security 이해 및 올바른 request 설정을 통한 해결
- CORS 설정 오류로 인한 접근 불가
-
Git Action 사용 시 경로 설정 문제
-
깃 액션은 이벤트 트리거를 바탕으로 주어진 액션을 진행할 때 깃 레포지토리의 루트폴더를 기준으로 액션을 진행한다.
즉 액션을 진행하기 위해서, 해당 액션이 수행이 될 경로를 다시 생성해줘야하는 문제였다. 이전에는 백엔드, 프론트엔드의 각각의 레포지토리에서 작업을 진행하였기에 발생하지 않는 문제였지만 이번에는 하나의 레포지토리에서 전체 프로젝트를 관리하는 방식이기에 발생하는 문제였다.
깃 액션 진행 시 각 액션이 실행될 폴더 경로로 이동하는 방식으로 해결하였다.
working-directory: ${{ secrets.BeWORKINGDIRECTORY }}
-
-
HTTPS 적용 문제 - Nginx
- 프론트에서 사용하는 인증서와 nginx에서 사용하는 인증서가 동일하지 않아서 발생하는 문제였다. 해당 인증서를 동일하게 하여 해결하였다.
-
로컬과 EC2 내의 실행 환경 차이로 인한 이미지 생성 시 플랫폼 지정 문제
-
Vanilla-extract 라이브러리로 인한 Bug fix
- Vanilla-extract/next-plugin의 Next.js App router 버전 다이나믹 라우팅 시 CSS Compiling Error로 인해 버전업 2.3.5 -> 2.4.0
- 에러 예시: [id]/page.css.ts Error: Didn't get a result from child compiler
김민수 | 이현동 |
---|---|
백엔드 개발 및 CICD | 프론트엔드 개발 및 CICD |
Content | Main | Detail |
---|---|---|
매장 위치 확인 | Spring / TypeScript / Naver API | Naver API For Search and I/O Store Data |
채팅 | Spring / TypeScript | Socket / SockJS / Stomp / Axios |
CI/CD | Docker, Jenkins, Dockerhub, Kubernetes | Docker, Jenkins, Dockerhub, Kubernetes Rollout |
Nginx | nginx | Nginx, Let's encrypt, |
For HTTPS | ||
배포 | AWS | EC2(Ubuntu Server 20.04 LTS) |
회원관리 | Spring Security | Spring Security |
매장 정보 관리 | Python, Naver API | Naver API For Search Store and I/O Store Data Base |
지도 | Naver API | Naver Map API |