👀 들어가기 전에 개발을 좋아해 매주 주말마다 사이드 프로젝트를 진행해왔다. 다만 그동안은 아이디어나 고민들을 노션에 단편적으로 정리해두는 데 그쳤고, 하나의 프로젝트를 처음부터 끝까지 체계적으로 정리할 기회가 부족했다. 노션은 현재 개인적인 메모 공간에 가깝게 사용하다보니 하나의 프로젝트를 처음 기획부터 구현, 고도화까지 흐름 있게 정리하기에는 뭔가 아쉬웠다. 그래서 이번 기회를 통해 이 블로그에 이미 완료한 사이드 프로젝트와 더불어 앞으로 진행하는 사이드 프로젝트들을 하나의 기록으로 정리해보려 한다. 정리할 부분들은 다음과 같다.왜 이런 선택을 했는지어떤 문제를 만났고어떻게 해결했는지소개 | DAU 100,000명, Peak VUs 1,000명을 목표로하는 고급 명품을 판매하는 이커머스 서비스👀 ..

👀 들어가기 전에 이전 포스팅에서 JWT를 다룬 김에 당시 고민하게 되었던 Refresh Token의 동시성 관리에 대해 더 자세히 남겨보려 한다. 우선 요구사항은 다음과 같다. 동시 로그인은 불가해야하며, 계정 하나당 하나의 기기에서 로그인하게 되며, 나중에 로그인한 기기가 있다면 현재 로그인 중인 기기가 로그아웃 되는 방식이어야한다는 것이다. 단순히 토큰 발급하고 끝나면 될 문제가 아니라 동시성 관점에서 안전한 인증 구조를 어떻게 설계할 것인가에 대해 많은 고민을 했고 이번 글에서 고민했던 Refresh Token 동시성 관리 방식과, 실제로 어떤 설계를 선택했는지 정리해보려 한다. 👀 본론처음 요구사항을 듣고 정리부터 해보았다. 즉, 위 요구사항을 자세히 살펴보면 계정 단위 단일 세션 정책을 반..

👀 들어가기 전에때는 12월 초 오전 7시28분... 갑자기 업무 카톡이 오기 시작했다.이유는 아래와 같다. 멀쩡하게 잘 돌아가던 테스트 서버가 다운되었다는 내용이었다. 메시지를 확인하자마자 머리가 빠르게 돌아가기 시작했다.'내가 껐나? 끈 적이 없는데?', '그렇다는건 서버가 혼자 꺼졌다는건데?', '어?? 왜꺼지지 그게? 그럴 리가 없는데?'출근 중이었고, 회사에 도착하자마자 후다닥 노트북을 열어 확인했다. 결과적으로는 EC2 인스턴스 자체가 다운된 상태였다.우선, 급하게 처리해야할 업무였기에, EC2를 재부팅해 서버를 정상 상태로 복구한 뒤, 로그 및 시스템 지표를 확인했다.👀 본론EC2 재기동 이후 확인한 로그에서 원인은 비교적 명확했다.CPU 사용률 99%, Memory 사용률 99% .....

👀 들어가기 전에 원래 이 포스팅은 프로젝트가 갈무리 되어갈 시점에 올릴 예정이었으나, 한분의 요청으로 예상보다 일찍(?) 작성하게 되었다.2025년 11월 중순, 이전 글에서 언급했던 프로젝트를 통째로 혼자 맡게 되었다.Admin 페이지를 개발하던 중, 기존에 “그냥 쓰고 있던” JWT 로그인 방식에 대해 다시 한번 제대로 정리할 필요를 느꼈다.이 글은 그 과정에서 고민했던 JWT 로그인 전반의 흐름과 설계 포인트를 정리한 글이다.👀 본론JWT로그인이란 무엇일까?다들 아는 그대로 토큰을 사용한 로그인 방식이다. 워낙, 관습처럼 코딩해오던 '그 방식'을 많이들 사용하기에 특별한 의문을 품지 않고 코딩해왔기에 근본적인 것에 대한 질문을 던지기 시작하는 순간 아래와 같은 현상이 발생하게 된다. 현업에서 ..

👀 들어가기에 앞서2025년 10월 중순, 차량 Wallpaper SW 서버 개발 프로젝트를 도맡아 개발하게 되며 감격스러운(?) 나의 서비스 개발이 시작되었다.Wallpaper를 한 번 조회하는 작업을 겉으로 보면 단순해 보이지만, 실제로는 아래처럼 다양한 데이터를 한 화면에 맞춰 조립해야 한다. 예를 들면 아래와 같은 것이다. (회사 보안 문제로 진짜 ERD는 가져오지 못했다)예시를 들기 위해서 직접 만들어본 ERD이다.위 상황에서 Content를 조회할때 필요한 정보는 아래와 같다. 콘텐츠 기본 정보옵션별 파일 URL (media/source/preview 등)카테고리/태그사용자별 좋아요 여부좋아요/다운로드/조회수 같은 지표즉, 한 번의 응답을 만들기 위해 조인이 여러 번 발생하고, 쿼리도 여러 ..

👀 들어가기 전2025년 12월 초, 진행하고 있던 프로젝트를 정리하고, 회사에서도 처음으로 진행하던 프로젝트의 MVP 모델을 마무리 짓고 기존 코드를 튜닝해 나가던 중 의문이 들기 시작했다. Transaction을 처리하고 스레드 풀을 정리하던 중 “동시에 딱 요청이 들어왔다”면 정확히 누가 먼저 실행할까?라는 의문이 들기 시작했다. 물론, 동시성 처리를 공부를 안 했던 것도 아니다.동시에 요청이 들어왔을 때, 나는 보통 이렇게 이해하고 있었다.“동시에 요청이 들어오면, 먼저 스레드풀을 잡은 친구가 먼저 처리된다”그런데 여기서 의문이 생겼다.그 “먼저”는 누가 결정하지?진짜로 0ms 차이도 없이 동시에 들어오면 순서는 어떻게 정해지지?사람이 제어 가능한 영역일까?이 글은 그 질문 하나에서 시작한다.그..