안녕하세요.
|
개발자 최민준입니다.

외부 서비스 장애로부터 살아남기

February 17, 2026

에서 외부 서비스 장애 대응 작업을 했다. Oracle Object Storage에 QR 코드를 업로드하는 과정에서, 외부 서비스가 불안정할 때 시스템 전체가 영향을 받는 문제가 있었다. 이 글에서는 Circuit Breaker와 Retry를 도입하면서 고민한 과정을…


네트워크 불안정 상황에서도 메시지 유실 없는 견고한 게임 서버 설계

February 14, 2026

실시간 멀티플레이어 게임을 개발하면서 마주친 문제가 있다. 특정 상황에서 유저가 게임 흐름에서 이탈하는 현상이었다. 이 글에서는 문제를 분석하고 해결한 과정을 공유한다. 문제 인식 유저 피드백 ZZOL은 실시간으로 여러 명이 함께 플레이하는 게임 서비스다. 배포와 동…


쿼리 최적화, 36초를 1초로 줄이기까지

February 05, 2026

우테코 프로젝트 에서 대시보드 API 성능 개선 작업을 했다. 레이싱 게임 TOP 플레이어 조회 API가 너무 느려서 원인을 파악하고 개선하는 과정을 기록해본다. 문제 상황 dev 환경에 데이터를 넣고 API를 호출해보니 응답이 너무 느렸다. 로 쿼리 실행 계획을 확…


2025년 회고

January 01, 2026

지난 회고: retrospect-2024-2 돌아보기 2025년은 유독 기억에 많이 남을 한 해로 남을 것 같다. 할 말이 너무 많은데 이 글에 다 담길지 모르겠다. 우아한테크코스를 마치며 IMG_7091.jpeg 올해는 우테코가 차지하는 비중이 정말 크다. 정말 몰…


WebSocket 서비스에서 Graceful Shutdown이 필요한 이유와 구현

December 29, 2025

ZZOL 서비스에 Graceful Shutdown을 구현했다. 단순히 "서버를 안전하게 끄자"가 아니라, WebSocket 기반 실시간 게임 서비스에서 "게임 중인 유저의 세션을 어떻게 보호할 것인가"에 대한 이야기다. OS의 SIGTERM 시그널부터 Spring의 …


커피빵에서 ZZOL로, 유저가 알려준 진짜 서비스

November 19, 2025

우테코 프로젝트에서 서비스 기획을 전면 수정했다. 원래 "커피 내기" 서비스였던 커피빵(CoffeeShout)을, "똥손도 즐기는 게임 기반 추첨 서비스" ZZOL(쫄)로 바꿨다. 왜 바꿨고, 뭘 바꿨는지 기록한다. 원래 기획: 커피빵(CoffeeShout) 커피빵의…


Redis Pub/Sub을 활용한 다중 서버 간 실시간 메시지 동기화 전략

October 14, 2025

infra_design 지난 글에서 이어집니다! Redis pub/sub Redis Pub/Sub의 동작 원리를 이해하면 왜 이 방식이 실시간 게임 동기화에 적합한지 명확해진다. Redis 내부 구조 Redis 서버는 C로 구현되어 있으며, Pub/Sub 기능은 내부…


단일 서버에서 분산 환경으로: 확장성 있는 아키텍처로의 전환

October 13, 2025

단일 인스턴스 목표 TPS 커피빵은 게임 기반 실시간 서비스이기 때문에 유저 간의 양방향 통신을 위해 웹소켓 통신을 이용하고 있다. 웹소켓 통신의 경우 서버가 각 클라이언트의 구독 상태를 세션별로 메모리에서 관리하고 있는데, REST API와는 다르게 연결이 지속적으…


스레드풀, 감으로 잡지 마세요: 부하 테스트로 증명하는 최적의 설정값

September 27, 2025

커피빵(CoffeeShout) 서비스의 WebSocket 스레드풀을 부하 테스트 기반으로 튜닝했다. "스레드 몇 개가 적절한가?"라는 질문에 감이 아닌 데이터로 답을 내리는 과정을 기록한다. 왜 스레드풀 튜닝이 필요했는가 커피빵은 실시간 멀티플레이어 게임 서비스다. …


우아한테크코스 7기 BE 레벨3 회고

August 30, 2025

지난 회고: 우아한테크코스_7기_BE_레벨2_회고 레벨3도 끝났다. 가속도가 붙은 것처럼 시간이 점점 빨리 지나간다. 지난 8주간 내가 느꼈던 것들을 하나씩 톺아보자! 문제를 정의하고 요구사항을 파악하는 능력은 어떻게 기를까 레벨3 내내 머릿속에서 맴돈 질문이다. 아…