1. 오늘의 배경 전날까지 Chat Service의 로깅, 사용자 검증 연동, 데모 테스트 도구 정리를 진행했다.오늘은 MVP 이후 개선이 필요한 성능 지점을 수치로 확인하기 위해 방 목록 조회 API를 JMeter로 측정했다. 대상 API는 다음이다.GET /api/v1/chat/rooms 이 API는 사용자가 참여 중인 채팅방 목록을 보여준다.방마다 마지막 메시지, 읽지 않은 메시지 수, 방 상태가 함께 내려가므로 실제 서비스에서 자주 호출될 가능성이 높은 API다.처음에는 방 목록 조회가 여러 지점에서 N+1이 발생한다고 생각했지만, 코드를 다시 확인해보니 실제 원인은 더 좁았다.lastMessage 본문 조회는 이미 MongoDB batch 조회로 최적화되어 있었고, 진짜 N+1 원인은 unrea..

1. 오늘의 배경 전날까지 Gateway 경유 STOMP 통합 테스트와 그룹방 퇴장 후 수신 차단 흐름을 확인했다.오늘은 MVP 테스트를 더 안정적으로 반복하기 위해 세 가지를 정리했다.서버 로그만 보고도 채팅 주요 흐름을 추적할 수 있도록 로깅 보강채팅방 생성 전에 user-service 기준으로 사용자 존재 여부와 차단 관계 검증팀원이 브라우저에서 쉽게 1:1/그룹방 채팅을 테스트할 수 있는 데모 HTML 정리특히 user-service 검증 연동은 MSA 구조에서 중요한 작업이었다.chat-service가 user DB를 직접 보지 않고, user-service가 가진 사용자/차단 데이터를 internal API로 확인하도록 만들었다. 2. 오늘의 목표목표Chat Service 주요 흐름에 최소 로..

1. 오늘의 배경 전날까지 presence, 읽음 처리, STOMP 에러 채널, 방 나가기 시스템 메시지 연결을 진행했다.오늘은 MVP 마감 전 실제 Gateway 경유 통합 테스트를 진행하면서, 그 전에 Chat Service 내부 의존 구조도 정리했다.작업은 크게 세 흐름이었다.Chat Service Application 계층이 JPA, Redis, MongoDB 구현체를 직접 알지 않도록 Port/Adapter 구조로 리팩토링Gateway, user-service, chat-service, Redis, MongoDB, PostgreSQL을 함께 띄운 상태에서 1:1 채팅 통합 검증그룹방 통합 테스트 중 확인된 퇴장 후 STOMP 수신 문제를 서버 퇴장 신호 방식으로 보완오늘은 기능을 새로 많이 추가..

1. 오늘의 배경 MVP 마감을 앞두고 Chat Service의 실시간 흐름을 맞춰야 했다.이전 작업에서 채팅방 생성, 조회, 나가기 같은 REST 기반 메타데이터 기능은 어느 정도 정리되었고, 이제 WebSocket/STOMP와 Redis 상태 관리가 연결되어야 했다. 오늘 작업의 핵심은 크게 세 가지였다.사용자가 현재 어떤 방을 보고 있는지 Redis에 저장하는 presence 처리방 나가기 시 SYSTEM_LEAVE 메시지를 저장하고 방 메타데이터와 연결STOMP 읽음 처리와 STOMP 공통 에러 응답 구조 정리추가로, 수동 테스트 중 공통 예외 핸들러가 Chat Service에 등록되지 않아 REST 예외가 500으로 내려가는 문제를 발견했고, 알림 이벤트 발행을 위한 1차 후보 조회 기능도 구현..

1. 오늘의 배경 6월 19일과 20일에는 Chat Service의 채팅방 메타데이터 기능을 넓혔다.19일에는 그룹 채팅방 생성, 방 상세/목록 조회, 시간 필드 기준, 테스트 환경 문제를 정리했다.20일에는 메시지 파트에서 공통으로 사용할 참여자 검증 계약과 마지막 메시지 메타데이터 갱신 경계를 만들고, 방 나가기, 읽음 처리 REST API, 채팅방 알림 설정 API까지 이어서 구현했다. 이틀 작업의 공통 주제는 “채팅방과 참여자 상태를 PostgreSQL 메타데이터로 안정적으로 관리하는 것”이었다.메시지 원본은 MongoDB에 저장되지만, 방 목록 정렬, 참여자 권한, 방 나가기, 읽음 위치, 알림 설정은 PostgreSQL의 채팅방/참여자 메타데이터에 강하게 의존한다.그래서 메시지 저장 기능과 실..

1. 오늘의 배경 오늘은 Chat Service에서 가장 먼저 필요한 흐름인 1:1 채팅방 생성 또는 기존 방 반환 API를 구현했다.단순히 방을 하나 만드는 API처럼 보이지만, 실제로는 고려할 점이 많았다.이미 두 사용자 사이에 1:1 방이 있으면 새로 만들면 안 된다.기존 방이 ACTIVE면 그대로 반환해야 한다.기존 방이 INACTIVE면 새 방을 만들지 않고 다시 활성화해야 한다.동시에 같은 1:1 방 생성 요청이 들어와도 중복 방이 생기면 안 된다.PostgreSQL 스키마가 Entity와 정확히 맞아야 한다.그래서 오늘 작업은 크게 두 축이었다.PostgreSQL 초기 스키마를 Flyway로 고정한다.POST /chat/rooms/direct API를 구현하고 동시성 충돌까지 방어한다. 2...

1. 오늘의 배경 이번 최종 프로젝트는 기록 기반 매칭 SNS 서비스다.사용자가 남긴 기록과 라이프스타일 정보를 기반으로 유사한 사용자를 매칭한다.매칭된 사용자들이 채팅으로 대화를 이어갈 수 있는 구조를 목표로 한다.나는 이 중 Chat Service를 담당한다.Chat Service는 단순히 메시지를 주고받는 기능만 담당하지 않는다.채팅방참여자 상태읽음 처리현재 접속 상태알림 이벤트오늘은 Chat Service의 첫 작업으로 채팅방 메타데이터 모델을 잡았다. 2. 오늘의 목표오늘 목표는 채팅방 생성 API를 바로 구현하는 것이 아니었다.먼저 이후 기능들이 공통으로 사용할 PostgreSQL 메타데이터 모델을 작게 고정하는 것이 목표였다.목표ChatRoom, ChatRoomParticipant, Dire..

https://school.programmers.co.kr/learn/courses/30/lessons/68935 프로그래머스SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프programmers.co.kr 문제 설명 제한사항n은 1 이상 100,000,000 이하인 자연수입니다. 코드 def solution(n): answer = '' # [1단계] 10진법을 3진법으로 변환 (동시에 앞뒤로 뒤집기) while n > 0: # 3으로 나눈 나머지를 문자열로 바꾸어 차례대로 이어 붙입니다. # 구한 순서대로 붙이기 때문에 자연스럽게 '뒤집힌 3진법'이 완성됩니다. answer += str(n % ..

https://school.programmers.co.kr/learn/courses/30/lessons/12930 문제 설명 제한사항 코드 def solution(s): answer = "" # 단어 내 인덱스를 저장할 변수 idx = 0 for ch in s: # 공백을 만나면 단어가 바뀌므로 인덱스 초기화 if ch == " ": answer += ch idx = 0 else: # 짝수 인덱스 → 대문자 if idx % 2 == 0: answer += ch.upper() # 홀수 인덱스 → 소문자 ..

https://school.programmers.co.kr/learn/courses/30/lessons/131705 프로그래머스SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프programmers.co.kr 문제 설명 제한사항 코드 from itertools import combinationsdef solution(number): answer = 0 # 1. number 배열에서 3명씩 짝지은 모든 조합(comb)을 하나씩 꺼냅니다. for comb in combinations(number, 3): # 2. 뽑은 3명의 번호를 모두 더했을 때 0이 맞는지 확인합니다. if sum(comb) =..