[Delivery Project] 인프라 기동부터 Eureka 연동, CI 오류 해결까지어제는 Delivery Project의 본격적인 개발에 들어가기 전에 프로젝트의 전체적인 틀을 잡았다.API 설계, 테이블 설계, ERD 설계, 인프라 설계를 진행했고, 팀원들이 같은 기준으로 개발할 수 있도록 팀 컨벤션도 정리했다.오늘은 어제 설계한 내용을 실제 개발 환경에 적용하면서 Docker 기반 인프라를 실행하고, Eureka를 통한 서비스 디스커버리를 구성한 뒤, GitHub Actions CI에서 발생한 오류까지 해결하는 과정을 진행했다.1. 전날 진행한 설계 및 팀 컨벤션개발을 시작하기 전에 프로젝트의 기본적인 구조부터 맞췄다.API 설계각 서비스에서 어떤 API를 제공할지 정의하고 요청과 응답 구조를 ..

RabbitMQ로 주문 처리 흐름 구현오늘은 RabbitMQ를 이용해서 주문 처리 흐름을 구현해봤다.먼저 Order 애플리케이션에서 주문 요청을 받으면 DB에 주문 정보를 저장한 뒤 market.product 큐로 메시지를 전송하도록 만들었다. Product 애플리케이션은 해당 큐를 구독하고 있다가 메시지를 받으면 재고를 차감하고, 처리가 끝나면 market.payment 큐로 다시 메시지를 보낸다.Payment 애플리케이션은 market.payment 큐를 구독하면서 결제를 진행한다. 정상적으로 결제가 완료되면 그대로 프로세스가 끝난다.이번 실습에서 중요한 부분은 하나의 애플리케이션이 Producer와 Consumer 역할을 동시에 할 수 있다는 점이었다.Order : 주문 메시지 발행 + 오류 메시지..

오늘 배운 내용오늘은 크게 다섯 가지를 배웠다.Redis Sorted Set과 리더보드CQRSNoSQLEvent Sourcing캐싱(Cache)1. Redis Sorted Set과 리더보드게임을 하면 항상 랭킹이 있다.점수 랭킹인기 검색어인기 상품좋아요 순위이런 기능을 리더보드(Leaderboard) 라고 한다.처음에는 이런 생각을 했다."그냥 MySQL에서 ORDER BY 하면 끝 아닌가?"하지만 실제 서비스에서는 수백만 명이 계속 점수를 올리고 있기 때문에 문제가 생긴다.예를 들어 인기 상품 Top10을 가져오려면SUM()COUNT()GROUP BYORDER BY같은 집계가 계속 발생한다.사용자가 많아질수록 DB는 계속 계산해야 하므로 점점 느려진다.Redis Sorted Set은 왜 빠를까?Redi..

오늘의 학습일지날짜: 2026.07.22오늘의 학습 키워드In-Memory DatabaseRedisNoSQLCache(캐싱)Key-ValueStringList(Linked List)DockerRedis InsightLPUSH / RPUSH / LPOP / RPOPMSET / MGETINCR / DECR오늘 배운 점오늘은 Redis가 왜 필요한지부터 설치, 그리고 가장 기본적인 자료형인 String과 List까지 공부했다.기존에 Spring Boot 프로젝트를 만들면서 사용했던 MySQL이나 PostgreSQL 같은 관계형 데이터베이스는 모두 영속성(Persistence) 을 목적으로 사용한다.프로그램이 종료되어도 데이터가 파일 시스템에 저장되어 있기 때문에 계속 유지된다.하지만 서비스에서는 항상 영구적으..

대규모 스트림 처리와 MSA. 이제 진짜 실무가 시작되는 것 같다.새로운 프로젝트가 시작됐다.이번에는 단순히 기능 하나를 만드는 수준이 아니라 대규모 스트림 처리, MSA, Redis, Docker, CI/CD처럼 실무에서 정말 많이 사용하는 기술들을 중심으로 배우게 된다.커리큘럼을 처음 봤을 때는 솔직히 조금 압도됐다. 예전 같았으면 "이걸 언제 다 배우지?"라는 생각부터 했을 텐데, 이번에는 이상하게 그런 부담보다 설렘이 더 컸다.오히려 '이제 진짜 개발자가 배우는 것들을 배우는구나.' 라는 생각이 먼저 들었다. 그동안은 Spring Boot로 API를 만들고, 데이터베이스를 연결하고,기능구현하고, 프로젝트를 완성하는 과정에 집중했다.물론 그것도 정말 많은 공부였고, 그 과정에서 성장도 많이 했다...

발표회를 통해 배운 점프로젝트 발표회를 들으며 구현한 기능 만을 소개하는 것이 아니라, 같은 기술이라도 전달하는 방식과 문제를 설명하는 흐름이 프로젝트의 완성도를 크게 높여준다는 점을 느꼈다. 특히 인상 깊었던 점은 대부분의 팀이 단순히 "무엇을 구현했다"가 아니라 "왜 이런 기술을 선택했고, 어떤 문제를 해결하기 위해 적용했는지"를 중심으로 발표를 구성했다는 것이다. 예를 들어 QueryDSL을 사용한 팀은 "검색 기능을 구현했다"에서 끝나지 않고, 기존 JPQL 방식에서 문자열 기반 쿼리의 한계와 유지보수 문제를 설명한 뒤 QueryDSL을 적용한 이유와 기대 효과까지 자연스럽게 이어서 설명했다. 기술을 적용한 배경과 선택 이유를 함께 설명하는 방식이 훨씬 설득력 있게 느껴졌다. 아키텍처를 소개할 때..