naeda

Naeda 프로젝트 스토리

SSAFY 핀테크 프로젝트를 시작하면서 나는 인프라 전체와 백엔드 일부 기능을 맡게 되었다. 나는 인증 부분을 맡게 되었는데, 결제 시스템이다 보니 인증이 허술하면 아무 의미가 없다고 생각했다. 회원가입, 로그인 등의 기능부터 구현을 시작하였는데, JWT를 선택했다.

이전 글에서 JWT 기반 인증 시스템을 만들었다. 근데 실제로 써보면 금방 문제가 생긴다.Access Token 만료 시간을 30분으로 잡았는데, 사용자가 결제 앱을 쓰다가 30분마다 다시 로그인해야 하면 미친 거다. 그렇다고 만료 시간을 7일로 늘리면 토큰이 탈취됐을

인증 시스템의 뼈대(Security + JWT + Redis)를 다 만들었으니, 이제 실제로 사용자가 호출할 API를 만들 차례다. 회원가입, 로그인, 토큰 재발급, 로그아웃 이렇게 4개.근데 우리 프로젝트는 단순한 회원가입이 아니다. SSAFY에서 제공하는 금융 AP

처음 프로젝트 서버를 받았을 때 솔직히 좀 막막했다. 인프라에 대한 경험이 전무했고, EC2 인스턴스 하나 주고 "여기에 서비스를 올려라"하는데, SSH 접속부터 Docker 설치까지 전부 직접해야했다. SSH 접속 SSAFY 에서 제공받은 .pem 키 파일로 접속한

우리 프로젝트는 서비스가 4개다. Spring Boot 백엔드, PostgreSQL, Redis, 그리고 AI 서버(FastAPI). 이걸 전부 Docker 컨테이너로 묶어서 docker compose 한 방에 올리는 게 목표였다. 전체 구조 Spring Boot

수동 배포를 딱 3번 하고 나니까 자동화의 필요성을 절감했다. git push → SSH 접속 → git pull → docker compose 재시작 → 로그 확인... 이걸 매번 하는 건 미친 짓이다.CI/CD를 분리해서 이해해야 한다.코드를 자주 통합하고, 통합할

HTTP로 서비스하면 안 되는 이유가 많지만, 우리 프로젝트는 결제와 얼굴 인증 데이터를 다루기 때문에 HTTPS가 필수였다. Let's Encrypt로 무료 SSL 인증서를 발급받았다. HTTPS가 필요한 이유 HTTP는 평문 통신이다. 클라이언트와 서버 사이 서 누군가 네트워크를 도청하면(Man-in-the-Middle Attack) 데이터가 그대로 ...

배포할 때마다 "서버 올렸습니다~" 하고 팀 채널에 메시지를 치는 것도 자동화했다. Mattermost Incoming Webhook을 활용했다.Webhook은 방향에 따라 두 종류가 있다.Incoming Webhook: 외부에서 Mattermost 안으로 메시지를 보

인증과 인프라를 마무리하고, 본격적으로 페이스페이의 결제 흐름 개발에 들어갔다. 매장에서 얼굴만 인식하면 결제가 되는 시스템이다. 생각해야 할 부분들이 존재했다. POS, 얼굴 인식 단말기, 백엔드 서버 — 세 가지가 각자 역할을 나눠서 동작한다 POS가 결제 요청을