지윤님의 블로그

1. WebSocket, StompHandler 인증 방식 변경 - 메시지 단위 JWT 검증 적용1) 개요WebSocket 기반의 채팅 기능을 구현하면서, 기존에는 연결 시점(CONNECT)에만 토큰 검증이 이루어져 이후의 메시지 송신에는 보안 취약점이 존재따라서 메시지 단위에도 JWT를 직접 검증하는 로직을 추가해 보안 2) 문제상황기존 구조(StompHandler)는 StompCommand.CONNECT에서만 JWT 인증 수행이후 메시지(SEND)에서는 SecurityContext를 활용해 인증된 상태로 처리됨하지만, 사용자가 WebSocket 연결 이후 로그아웃하거나 탈퇴 또는 추방된 경우에도 여전히 메시지를 보낼 수 있음결론 : 따라서 메시지 전송 시점마다 JWT 재검증이 필요 3) 해결ChatM..

설계 수정 & 개선4~5 주차는 프로젝트를 마무리하는 기간이라, 새로운 기능을 추가하기보다는 기존 코드를 다듬고 성능을 최적화하는 데 집중따라서 프로젝트를 더욱 안정적으로 마무리하기 위해 설계 보완, API 테스트, 성능 최적화, 프론트엔드 연동 및 구현, 코드 리팩토링 등의 작업을 진행 1. 설계 피드백 반영 및 수정 과정*ERD 수정 과정 및 변경 내용처음 설계보다 ERD를 직관적으로 표현하고, 데이터 구조를 개선ERD 도구 변경 : ERDCloud -> DBDiagram 사용1:N 관계를 더 명확하게 표현 가능취향 카테고리 및 연관 테이블 추가기존에는 취향 데이터를 한 테이블에서 관리중간 테이블을 하나로 할지, 각각 둘지 고민결론 : 중간 테이블을 개별적으로 두는 것이 관리하기 쉽고, Null 값 ..

기능 개발 시작& 역할 분배 및 협업2~3주차부터 본격적인 기능 개발 시작 및 팀원별로 역할을 나누고, Git 협업 방식을 정리하여 프로젝트를 체계적으로 진행 1. 기능별 역할 분배채팅 담당 : WebSocket, STOMP, Redis Pub/Sub 을 활용한 실시간 채팅 기능인증 / 인가 와 지도 검색 API 담당 : Spring Security와 JWT를 활용한 보안 기능 + 카카오 지도 연동배포 및 S3 이미지 업로드 담당 : AWS EC2, Docker를 활용한 배포환경 구축 및 S3 연동GPT AI 연동 및 취향 카테고리 담당 : OpenAI API를 연결하고 Spring AI를 활용해 프롬프트 설계 및 취향 기반 추천이렇게 4개의 역할로 분배하고 개발을 진행했으며, 나는 실시간 채팅 기능을 ..

1.  WebSocket 인증 및 Spring Security와 충돌 문제1)개요WebSocket 연결 시 Authorization 헤더에 Access Token이 포함되지 않아 Spring Security의 인증이 실패하여 연결이 차단 됨(인증된 사용자만 접근할 수 있도록 하기 위해 단순 로그인 후 토큰 값을 하드코딩하여 WebSocket 연결을 테스트 하는 과정에서 문제 발생)알고보니 Access Token이 쿠키에 저장되고 있어서 인증이 되지 않았고, 이를 해결하기 위해 WebSocket 연결 시 Headers의 Cookie 값에 자동으로 쿠키에 저장된 토큰 값을 불러오는 방식으로 로직을 변경해봤지만 인증이 여전히 되지 않았음 2)문제상황Access Token의 쿠키 기반 저장Spring Secur..

프로젝트 주제 선정 과정고객 친화적인 서비스(여행, 도서관 등)나 온오프라인 동시 서비스 등의 아이디어도 고려했지만, 조금 더 익숙하고 접근하기 쉬운 맛집을 주제로 선택주제 선정 이유많은 사람들이 "오늘 뭐 먹을까?"에 대한 고민을 자주 함직장인을 포함한 다양한 사용자층을 확보 가능메뉴 추천을 AI로 해결하면 데이터 입력의 한계를 극복할 수 있음지도를 함께 제공하면 사용자 경험을 향상시킬 수 있음오픈채팅 서비스를 통해 사용자 간 소통을 지원하고, 메뉴 추천과 맛집 경험을 공유할 수 있게 함결론 : AI를 활용한 메뉴 추천 + 맛집 지도 연동 + 실시간 채팅 서비스를 주요 기능으로 설계하고 프로젝트를 진행하기로 결정기술 스택 결정 과정백엔드 트랙에서 배운 내용을 기반으로 선택하되, 프로젝트에 적합한 기술을..

1. GreenHopper 알고리즘 정밀도 문제1)개요리스트 정렬을 위해 GreenHopper 알고리즘을 사용하여 position 값을 생성하였는데, 처음엔 int 자료형을 사용하여 중간값을 계산했지만, 정밀도 문제로 인해 예상치 못한 값이 저장되는 문제 발생 2)문제상황double 타입으로 변환하여 position 값을 저장했는데, 연산 과정에서 부동소수점 오차 발생.즉, 데이터가 많아질수록 중간값을 정확히 계산하지 못하고 값이 비정상적으로 나오는 문제가 있었음이럴 경우 리스트 두개가 같은 위치를 가지게 되어 정렬이 깨질 가능성이 있음 3)해결방법1. BigDecimal을 사용하여 정밀도 향상-기존 double을 BigDecimal로 변경하여 소수점 오차를 방지 방법2. 기본값을 1에서 100으로 변경..

프로젝트 명 : 판 떼기소개한 줄 정리 : 트렐로를 모티브한 일정관리 서비스내용 : 트렐로를 모티브한 일정관리 서비스진행 날짜 : 2024.12.23 ~ 2024.12.31 프로젝트 요약1. 프로젝트 목적:신입 2년차 백엔드 개발자 채용 공고에서 요구하는 핵심 기술 역량을 실전 프로젝트를 통해 학습하고, 이를 기반으로 개발 역량을 검증하는 것이 목표백엔드 개발 기술 습득Java & Spring Boot 기반의 REST API 개발JPA & MySQL을 활용한 데이터 모델링 및 트랜잭션 관리Spring Security & JWT 기반 인증/인가 구현AWS 클라우드 환경에서의 배포 경험EC2 + Docker + Docker Compose로 컨테이너화된 애플리케이션 배포RDS(MySQL) 분리를 통한 데이터 ..

테스트 개요1. 목표Redis 캐싱 적용 전후의 성능 차이 검증MySQL을 단독 사용했을때의 조회와 Redis 캐싱 적용 후 조회의 TPS 변화 확인부하가 증가할수록 데이터베이스와 캐싱 성능의 차이를 수치로 분석부하가 증가하는 상황에도 안정적인 성능을 유지할 수 있는 지 검증MySQL 단독 사용 시 트래픽이 증가하면 TPS가 급감하는 현상이 발생하는지 검증Redis 캐싱을 도입하면 트랜잭션 처리 속도가 일정하게 유지되는지 확인데이터베이스 부하 감소 효과 확인Redis 캐싱을 활용함으로써 MySQL의 쿼리 요청 횟수가 얼마나 감소하는지 측정2. 목적서비스 응답 속도 개선UX를 향상시키기 위해 응답 지연을 최소화하고 실시간 데이터 조회 성능 개선Redis를 통한 빠른 응답을 유지하면서, 최신 데이터를 효율적..

테스트 개요1. 목표JPA를 이용한 취향 데이터 조회 성능 최적화N+1 문제 해결 및 쿼리 실행 시간 단축최적화된 방식으로 TPS 증가 및 비용 절감 효과 분석@EntityGraph, LEFT JOIN FETCH, Batch Size 등을 활용하여 어떤 방식이 가장 효율적인 조회인지 확인2. 목적N+1 문제 해결 : JPA의 Lazy Loading으로 인해 발생하는 다중 쿼리 문제 개선TPS 분석 : 최적화 기법 적용 전후의 트랜잭션 처리량 비교쿼리 비용 절감최종프로젝트 진행 시 외부 AI API를 연동하여 데이터를 분석하는 기능을 포함매 쿼리 실행 시 AI API가 호출되며, 이는 AI 토큰을 소비하면서 비용이 발생불필요한 API 호출을 줄이고 쿼리를 최적화하여 AI 사용 비용을 절감하는 것이 목적최적..

테스트 개요1. 목표:이중 서버 환경에서 CPU 부하율 및 TPS 처리 검증대량의 트래픽이 발생하는 환경에서 서버 이중화(Scale Out)가 성능에 미치는 영향을 검증서버 2대를 사용하여 부하를 분산하고, CPU 사용률과 TPS 변화를 분석서버 1대와 2대의 환경을 비교하여, 트래픽 증가에 따른 부하 분산 효과를 확인2. 목적CPU 사용률 70% 유지 목표 : 서버의 안정적인 운영을 위해 적정 부하 수준을 설정하고 성능 평가TPS 분석 : 서버 확장 전후의 트랜잭션 처리량 변화를 측정하여 성능 개선 여부 확인확장 전략 수립 : 서버 한 대 기준으로 적절한 사용량을 유지하는지 확인하고, 예상 운영 가능 범위를 정의3. 테스트 환경:서버 및 인프라 환경항목사양로드밸런서 유형Application Load B..