전체 글 20

FitPass 1:1 채팅 기능 트러블슈팅

👋 들어가며헬스장 예약 플랫폼인 FitPass는 헬스장과 사용자 간의 문의 및 상담을 실시간으로 처리할 수 있는 1:1 채팅 기능이 필요했습니다.기존 REST API 방식으로는 즉시 응답이 어려워, WebSocket 기반의 STOMP 프로토콜로 구조를 고도화하게 되었습니다.🧱 채팅 기능의 기본 구조구성 요소 설명WebSocket실시간 메시지 송수신 담당STOMP메시지 라우팅, 구독 관리REST API채팅방 생성 및 조회DTO & Entity메시지 구조 및 DB 저장SimpMessagingTemplate서버 → 클라이언트 전송❗ 주요 트러블슈팅 사례1. 🔥 WebSocket 연결 실패 (404 또는 CORS)현상// 브라우저 콘솔 에러WebSocket connection to 'ws://localho..

Spring 2025.07.01

FitPass 1:1 채팅 기능 기술 고도화: WebSocket → STOMP 전환기

🎯 프로젝트 개요FitPass 헬스장 예약 플랫폼에서 사용자와 헬스장 운영자 간의 실시간 소통을 위한 1:1 채팅 기능을 구현했습니다.초기에는 Spring WebSocketHandler 기반의 로우레벨 방식으로 구현했으나, 서비스 확장과 안정성 확보를 위해 STOMP(Simple Text Oriented Message Protocol) 기반 구조로 전환하는 기술 고도화를 진행했습니다.📈 기술 진화 과정1단계: 로우레벨 WebSocket 구현 (초기 버전)기술 스택백엔드: Spring Boot + WebSocketHandler프론트엔드: React + 네이티브 WebSocket API연결 방식: ws://localhost:8080/ws/chat?userId=1초기 구현 코드백엔드 WebSocketHan..

카테고리 없음 2025.07.01

FitPass 1:1 실시간 채팅 기능 - 기술적 의사결정

문제 정의기술적 의사결정 배경FitPass 플랫폼에서 사용자(User)와 체육관(Gym) 간의 실시간 1:1 상담 기능이 필요했습니다. 사용자들이 체육관에 대한 문의사항, 운영 시간, 프로그램 정보 등을 실시간으로 소통할 수 있는 채팅 시스템의 도입이 요구되었습니다.핵심 요구사항실시간 메시징: 사용자와 체육관 간 즉시 메시지 전달1:1 매칭: 각 사용자-체육관 쌍별로 독립적인 채팅방 생성메시지 영속성: 채팅 내역 저장 및 조회 기능연결 상태 관리: 접속/퇴장 이벤트 처리확장성: 다수의 동시 접속자 처리사용자 경험: 빠른 응답성과 직관적인 인터페이스기술 스택 비교 분석1. 실시간 통신 방식 선택HTTP Polling vs WebSocket vs Server-Sent Events방식 실시간성 리소스 효율성 ..

카테고리 없음 2025.07.01

TIL - Cache와 Redis

🔍 검색 API에 Cache를 적용한 이유✅ 1. 성능 최적화 (Performance Optimization)검색 API는 사용자가 검색어를 입력할 때마다 DB에서 LIKE 쿼리를 실행하게 되어 성능에 부담이 생깁니다.특히 트래픽이 많은 시간대나 인기 키워드의 반복 요청이 잦은 경우, DB에 큰 부하가 발생합니다.따라서 동일한 키워드 + 페이지 조건으로 반복되는 요청에 대해 Redis Cache를 활용하면 DB 부하를 획기적으로 줄일 수 있습니다.✅ 2. 빠른 응답 속도 제공 (Response Speed)캐시에 저장된 데이터는 메모리 기반 저장소인 Redis에서 가져오기 때문에 응답 속도가 매우 빠릅니다.사용자 경험(UX) 향상에 효과적입니다.✅ 3. 핫 키워드 대응 전략인기 검색어는 동일한 키워드로 ..

카테고리 없음 2025.05.20

TIL - Map

map을 이용한 댓글 대댓글 개수찾기● Map이란?키(key) 와 값(value) 을 쌍으로 저장하는 자료구조● Map 생성Map commentCountMap = new HashMap();Long 타입의 키값과 Long 타입인 값을 commentCountMap이라는 빈 Map객체 생성여기서는 스케줄 ID(Long) 를 키로, 댓글 수(Long) 를 값으로 저장합니다.● 왜 사용했을까?댓글 수를 scheduleId 별로 빠르게 조회하려고.예를 들어 1번 스케줄에 댓글 5개, 2번 스케줄에 댓글 0개 이런 식으로 저장해서,나중에 .get(스케줄ID) 하면 바로 댓글 수를 알 수 있습니다.● 코드 해석Map commentCountMap = new HashMap();commentCountMap라는 이름의 비어 ..

카테고리 없음 2025.05.13

walkproject 트러블 슈팅

JPQL + Map 구조로 댓글 수 일괄 조회 최적화문제 상황전체 일정 조회 API에서 댓글 개수(commentCnt)를 보여주기 위해 각 스케줄별로 댓글 수를 조회했는데, 루프마다 DB에 접근하면서 쿼리가 스케줄 개수만큼 실행되는 비효율이 발생했습니다.문제 코드 예시 for (Schedule schedule : schedules) { Long count = commentRepository.countByScheduleId(schedule.getId()); // N번 발생}해결 방법JPQL을 활용하여 한 번의 쿼리로 모든 스케줄 ID별 댓글+대댓글 수를 일괄 조회한 후,Map 구조로 매핑하여 DTO에 삽입하였습니다.적용 SQL & Java // JPQL@Query(""" SELECT c.sche..

카테고리 없음 2025.05.10

🗓️ TIL - 일정(Schedule) 기능 개발 (API & ERD 설계 중심)

스케줄 CRUD, 댓글CRUD, 대댓글CRUD ✅ 1. 학습 목표일정 기능을 위한 API 명세서를 작성하고 RESTful하게 설계할 수 있다.ERD(Entity-Relationship Diagram)를 통해 연관 관계를 시각화하고 데이터 구조를 명확히 설계할 수 있다.📘 2. API 설계✔️ 기능 목록기능설명일정, 댓글 생성사용자가 새로운 일정, 댓글을 등록일정, 댓글 목록 조회전체 일정, 댓글을 조회일정, 댓글 상세 조회단일 일정, 댓글 상세 정보 확인일정, 댓글 수정기존 일정, 댓글 내용 수정일정, 댓글 삭제사용자가 일정, 댓글을 삭제 ✔️ API 명세 예시 스케줄메서드 엔드포인트 설명 요청값 ..

카테고리 없음 2025.05.01

프로젝트 KPT 회고

아웃소싱 프로젝트 KPT 회고1. Keep (잘한 점, 유지할 것)목표와 마감일을 명확하게 설정하여 일정 관리가 원활했다.팀원 간 역할 분담을 명확히 하여 충돌 없이 작업을 진행했다.새로운 기능을 공부하면 프로젝트에 잘 적용시킨 점2. Problem (문제점, 아쉬웠던 점)초기 요구사항 분석이 부족해 중간에 스펙 변경이 잦았다.테스트 케이스 작성이 프로젝트 후반에 몰려 품질 관리가 어려웠다.코드 리뷰가 형식적이 되어, 실제 품질 개선에 크게 기여하지 못했다.소통 부재, 연락 남기고 확인하는 부분이 미숙했다.3. Try (개선 방안, 다음에 시도할 것)개발 초기부터 TDD를 부분적으로라도 적용해 테스트를 자연스럽게 병행한다.코드 리뷰를 사전에 정한 체크 리스트 기반으로 진행하여 실질적인 품질 개선을 이끌어..

카테고리 없음 2025.04.29

TIL - Docker & Redis / InteliJ 연결

✅ 1. Docker란 무엇인가?Docker는 컨테이너 기반 가상화 플랫폼으로, 애플리케이션을 실행하는 데 필요한 환경(코드, 라이브러리, 설정 파일 등)을 하나의 이미지로 패키징하여, 어떤 환경에서도 동일하게 실행할 수 있도록 지원해주는 도구이다.🔹 특징가볍고 빠르다 (VM과 달리 OS 전체를 포함하지 않음)이미지 단위로 버전 관리 가능Dockerfile을 통해 환경 설정 자동화 가능배포 및 테스트 환경 구축에 최적화✅ 2. Redis란 무엇인가?Redis는 인메모리 기반의 키-값 저장소로서, 매우 빠른 속도를 자랑하는 NoSQL 데이터베이스이다.주로 캐시, 세션 저장소, 메시지 큐, 실시간 데이터 처리에 사용된다.🔹 특징데이터는 메모리에 저장되며 디스크에도 백업 가능다양한 자료구조 지원: Stri..

Docker 2025.04.22

TIL - N+ 1 과 Fetch Join

✅ N+1 문제와 Fetch Join 정리🧩 문제 상황JPA에서 연관된 엔티티를 LAZY로 설정한 상태로 조회할 경우, 다음과 같은 N+1 문제가 발생함:1개의 쿼리로 부모 엔티티 N개를 조회한 후,각 부모 엔티티마다 연관된 자식 엔티티를 다시 N번 쿼리 실행결과적으로 총 N+1번의 쿼리 발생 → 성능 저하🔍 해결 방법: Fetch JoinFetch Join을 사용하면 연관된 엔티티를 한 번의 쿼리로 함께 조회할 수 있어 N+1 문제를 해결할 수 있음.@Query("SELECT p FROM Post p JOIN FETCH p.user") List findAllWithUser();이렇게 하면 Post와 User를 단일 쿼리로 조회, 지연로딩 문제 제거.⚠️ 주의사항: Fetch Join + 페이징@On..

카테고리 없음 2025.04.21