백엔드 개발자로서 3년간의 경험을 쌓으며 단순한 CRUD를 넘어서 더 깊은 고민과 역량이 필요한 영역으로 도약하고 싶었습니다. 기능을 구현하는 것에서 벗어나 백엔드 개발자가 반드시 알아야 할 원리와 고민해야 할 지점들을 배우고 싶었고, 그 과정에서 제 열정을 다시 끌어낼 수 있기를 바랐습니다. 그런 다짐으로 루퍼스 부트캠프의 백엔드 과정을 수강했고 10주간의 몰입을 통해 제 열정을 다시 일깨우고 새로운 동기를 얻을 수 있었습니다. 무엇보다도 훌륭한 멘토분들의 이끌어 주심 덕분에 즐겁게 배우고 성장할 수 있었습니다. 10주간의 과정 PG 개발에서의 원자성 보장과 테스트코드 당시에는 메서드에 붙은 @Transactional이 어떻게 작성되어야 원자성이 보장되는지 잘 알지 못했다. 이전 주차에 했던 내용이라..

이번주는 랭킹 시스템을 개발하였고 레디스의 ZSET 자료구조를 사용했다. 그러면서 공부했던 것들을 정리해본다. 1. Redis 자료구조 학습랭킹 시스템 구현의 핵심은 Redis ZSET(정렬된 집합) 이다.ZSET은 (member, score) 쌍을 저장하고, 점수 기준으로 정렬된 상태를 유지한다.랭킹 시스템에서 자주 쓰는 명령어는 다음과 같다. 점수 추가/갱신:ZADD rank:product:day:20250914 100 productId:123 ZINCRBY rank:product:day:20250914 1 productId:123랭킹 조회 (Top-N):ZREVRANGE rank:product:day:20250914 0 9 WITHSCORES특정 상품 점수/순위 조회:ZSCORE rank:prod..

1 사용자 행동 수와 랭킹 점수1.1 랭킹은 사용자 행동을 점수로 환산한 결과사용자가 남긴 행동은 좋아요, 조회, 구매처럼 다양하며 먼저 이러한 행동이 몇 번 일어났는지를 저장한다.하지만 랭킹에 반영할 때는 어떤 행동이 순위에 더 중요한지를 표현하기 위해 가중치를 적용해 점수로 계산한다.따라서 랭킹을 만들려면 두 가지가 필요하다.하나는 사용자 행동 횟수를 저장하는 것, 다른 하나는 그 데이터를 바탕으로 점수를 계산해 저장하는 것이다.행동 집계 저장소: product_metrics 테이블날짜별, 상품별로 좋아요 수, 조회 수, 주문 수 같은 count 데이터를 저장한다.이곳은 원천 데이터이자 점수를 계산하기 위한 재료 역할을 한다.랭킹 계산 저장소: Redis Sorted Setproduct_metrics..

이번 주에는 카프카를 직접 써봤다.글로벌 이벤트와 로컬 이벤트… “이벤트에도 글로벌이 있구나” 싶은 순간도 있었다. 어디에 쓰이는지가 먼저 궁금K.A.F.K.A라는 이름 정도만 아는 상태에서, 이 도구가 무엇으로 구성되는지보다 어디에 쓰이는지가 먼저 궁금했다.그 부분은 월요일 멘토링에서 전체 흐름을 들으며 큰 도움을 받았다.이벤트 분리를 처음부터 미세하게 하려니 막막했는데, “쉬운 것부터 해보자”는 말이 전환점이었다.즉, 주문등록(재고 차감, 포인트 차감, 쿠폰 사용) 같은 핵심 트랜잭션부터 쪼개기보다, 우리 시스템 관점에서 바깥이라고 볼 수 있는 데이터 플랫폼 전송 같은 곳부터 분리해보기로 했다.그리고 나서 주문등록 이벤트를 떼어내 보니, 예컨대 주문 이벤트 발행 후 포인트 차감이 실패하면 보상 트랜잭..

Spring Application Event를 사용해보긴 했지만, 용어와 코드가 어떻게 매칭되는지는 늘 헷갈렸다. 이번 글에서는 이벤트 관련 용어와 Spring을 이용해 내부 이벤트를 사용할 때 참고할 수 있는 예시 코드를 소개하려 한다. 1. 이벤트 용어멘토링 시간에 들었던 예시는 이벤트 관련 용어를 이해하는 데 가장 도움이 되었다. 마라탕집 3000평 가게에 식사하러 갔다.테이블A에서 "계산해" 달라고 한다 → 지나가던 알바가 무전기로 "A테이블 계산이요"라고 전달한다. → 계산 서버가 달려와서 "계산해드리겠습니다"이벤트 프로듀서 (Publisher) = 테이블A이벤트 = "계산 해줘" → 커맨드가 아니니깐, “계산해줘” 보다는 "여기 식사 다 했어요!" 일 듯.이벤트 브로커 = 알바 + 무전기이벤트..

이번 주는 카프카를 활용해 외부 이벤트를 처리하며 다양한 고민을 해보는 시간이었습니다.모든 이벤트를 정확히 한 번만 처리해야 할까? 때로는 처리되지 않아도 되는 경우가 있지 않을까? 빠른 처리가 중요한 작업과 정확성이 중요한 작업을 어떻게 처리할까? 이러한 질문들을 바탕으로 카프카의 특성을 활용해 각 작업의 요구사항에 맞는 처리 전략을 설계했습니다. 이 글에서는 그 과정에서 얻은 인사이트와 실제 적용한 설계 방법을 공유하고자 합니다. 카프카를 쓰며 배운 것들: 작업 특성에 맞춘 컨슈머 그룹 분리카프카의 기본 구조카프카는 물리적인 파티션을 논리적으로 묶은 '토픽'이라는 개념을 사용합니다. 토픽은 일정 기간 영속성을 가진 데이터로, 소비된 후에도 그 자리에 계속 남아있습니다. 마치 칠판에 적힌 글씨를 여러 ..

보호되어 있는 글입니다.

Spring에서 애플리케이션 이벤트를 처리할 때는 두 가지 대표적인 방식이 있습니다.@EventListener@TransactionalEventListener(AFTER_COMMIT)두 방식은 “언제 실행되는지”와 “트랜잭션 경계와의 관계”가 달라서 같은 이벤트 처리라도 DB 반영 결과가 완전히 달라질 수 있습니다. 두방식의 차이점을 간단한 프로젝트에서 로그로 확인해보겠습니다. 비교 표항목@EventListener@TransactionalEventListener(AFTER_COMMIT)실행 시점이벤트 발행 즉시(동기)메인 트랜잭션 커밋 직후 콜백 실행트랜잭션 경계서비스 트랜잭션과 동일메인 트랜잭션은 이미 커밋 완료 상태DB 반영서비스 커밋과 함께 반영콜백에서 저장하려면 새 트랜잭션 필요(예: REQUIR..

보호되어 있는 글입니다.

Spring에서 데이터베이스 트랜잭션은 @Transactional로 관리됩니다. 이 애노테이션은 AOP 기반 프록시가 트랜잭션 경계를 만들어 주는 방식으로 동작하며, 애플리케이션은 JPA를 통해 DB에 접근합니다.이렇게 여러 구성 요소가 겹쳐 DB 트랜잭션을 사용하다 보니 실제 동작을 정확히 이해하지 못한 채 무작정 @Transactional을 붙이거나 흐름을 파악하지 못해 시행착오를 겪는 경우가 많습니다. 그래서 이번 글에서는 로그를 확인하면서 프레임워크가 트랜잭션을 실제로 어떻게 시작·합류·커밋·롤백하는지 살펴보려고 합니다. TL;DR결론: REQUIRED → REQUIRED에서 내부 RuntimeException(unchecked exception)은 바깥까지 전파되어 전체 롤백된다.가장 보편적으로..

1. 새롭게 배운 개념/지식RestTemplate 적용잘한 점 : RestTemplate 사용법과 Redis 자료구조와 활용방안에 대해서 공부했다. 공부 방법: Redis 자료구조와 활용방안(레디스 공식 유튜브: 짧고 지루하지 않게 설명 잘함. 단점은 영어라서 피곤, 개발자를 위한 레디스: 자료구조와 활용방안 부분만 봤는데 좋은 책이였다! gpt나 블로그 보지 말고 그냥 이 책 보는 것이 시간 낭비 안함. 짧게 정리된 것만 보면 별 생각을 안하게 되는데, 책을 보면서 따라가다보면 생각을 하게 되기 때문이다. )RestTemplate 사용법과 Redis 자료구조는 정리를 해두었는데, 이거 정리해두니 다른 사람 코드가 잘 읽혔다! 2. 문제를 해결하면서 얻은 인사이트캐시 구현을 어느 레이어에서 어떤 방식으..

Spring에서 Redis 서버에 연결하려면 무엇이 필요할까? Spring에서 Redis에 연결하려면 클라이언트 드라이버(Lettuce, Jedis 등)가 필요합니다.RedistTemplate은 RedisConnectionFactory를 통해 RedisConnection을 얻고 이 커넥션을 사용해 명령을 실행한 뒤 반납합니다.RedisConnection은 Spring Data Redis가 제공하는 추상화 계층으로 내부적으로 Lettuce나 Jedis 같은 클라이언트 라이브러리를 사용해 실제 Redis 서버와 통신합니다.Spring Data Redis는 클라이언트별로 전용 팩토리를 제공합니다. 즉, 어떤 클라이언트를 쓸지는 어떤 커넥션 팩토리를 생성하느냐로 결정됩니다.LettuceConnectionFac..