코디잉

👩‍💻 나는,올해로 백엔드 개발 경력 1년 차를 넘긴 개발자로, 그동안 풀스택 개발을 경험했지만, 현재는 운영 업무를 맡고 있다. 마음 한켠에는 "기본기가 부족하다"는 생각이 늘 있었고, 여러 곳에서 많이 볼 수 있는 TDD, Redis, Kafka, 대용량 트래픽 처리, 아키텍처 설계 같은 주제들을 직접 경험해 보고 싶었다. 🤔 시작 전 고민 & 항해 Lite 선택 이유 퇴근 후 집에 오면 "공부해야지"라는 생각은 가득했지만, 막상 실행으로 옮기는 건 쉽지 않았다. 공부할 건 정말정말 많고, 어떤 것부터 시작해야 할지도 막막했다. 예전부터 항해 플러스를 해볼까 고민했지만, 직장과 병행하기엔 빡세 보이는 커리큘럼과 금액 때문에 망설여졌다..ㅎㅎ 그러던 중 퇴근 후 + 주말에 유연하게 참여할 수 있는..

🧐 9주차 과제 Kafka 도입: 결제 성공 후 처리 로직을 Kafka 메시지 기반으로 비동기 처리하도록 개선 🙋‍♀️ 고민했던 부분 기존 ApplicationEvent → Kafka 기반 구조로 리팩토링 ◾ 기존에는 @TransactionalEventListener(phase = AFTER_COMMIT) 기반으로 비동기 이벤트를 처리했음 ◾ Kafka를 도입하여, 이벤트들을 Kafka 메시지로 발행하고 별도 Consumer에서 처리하도록 구조 변경 ◽ 발행: ReservationService.pay() 성공 시 PaymentSuccessMessage Kafka로 전송 ◽ 소비: PaymentSuccessKafkaConsumer.consume()에서 메시지 수신 후 랭킹/토큰/내역 순..

🧐 8주차 과제 1. Application Event: 이벤트를 활용하여 트랜잭션과 관심사를 분리하기 2. Asynchronous Design: 대기열 기능에 대해 Redis 기반의 설계를 진행 3. feedback - RedisReservationRankingManager 상수값 외부 설정으로 빼기 4. feedback - redis 분산락 TTL 충분히 길게 줘서 중복실행 확률 낮추기 🙋‍♀️ 고민했던 부분① Event 활용하여 트랜잭션과 관심사 분리◾ 기존에는 모든 로직이 ReservationService.pay() 내에 포함되어 있어, 핵심로직과 부가로직이 혼재된 구조였다. ◽ 핵심 로직: 대기열 토큰 검증, 포인트 사용, 좌석 상태 변경 ◽ 부가 로직: 예매율 랭킹 갱신..

🧐 7주차 과제 1. Ranking Design - (인기도) 빠른 매진 랭킹을 Redis 기반으로 개발하고 설계 및 구현 2. Asynchronous Design - 대기열 기능에 대해 Redis 기반의 설계🙋‍♀️ 고민했던 부분◾ 처음엔 5분 주기 배치로 DB를 조회해 Redis에 예매율을 갱신하는 스케줄러 방식을 고려했다. ◽ 이유: Redis를 활용하더라도 DB에 자주 접근하지 않도록 하기 위해 ◾ 하지만 스케줄러 방식으로 했을 경우 아래와 같은 단점이 있을 것 같았다. ◽ 실시간성이 떨어지고, 실제 예매 완료 시점과 랭킹 반영 시점 간의 지연 발생 ◽ 불필요한 콘서트 전체 조회 쿼리가 주기적으로 발생하여 DB 부하 가능성 ◽ 예매 취소나 상태 변경이 스케..

🧐 6주차 과제 1. Distributed Lock - Redis 기반의 분산락 구현해보기2. Distributed Lock - 주문, 결제 등에 적절한 키와 범위를 선정해 분산락 적용하고, 통합테스트 작성하기3. Cache - Cache 전략 취할 수 있는 구간 점검하고 적절한 전략 선정하기4. Cache - Redis 기반의 캐싱 전략 적용하기✅ Keep (잘한 점 / 유지할 점)- 콘서트별로 토큰을 관리하려던 구조를 전환하여 전체 예약서비스 접근 제어용 대기열 구조로 단순화 - 허용된 대기열 토큰의 유효시간을 고려한 스케줄러를 도입하여 유효하지 않은 토큰 자동 만료 처리 - 재시도 방식의 Spin Lock 로직을 Redis로 직접 구현하고 Lua 스크립트로 안전하게 락 해제 처리 - 100개 동..

🧐 5주차 과제 1. 동시성문제 - ① 좌석 임시배정 (중복예약)2. 동시성문제 - ② 포인트 차감/충전3. 동시성문제 - ③ 결제, 스케줄러 간 좌석 상태 충돌✅ Keep (잘한 점 / 유지할 점)- 멀티스레드 테스트를 통해 실제 동시성 문제를 재현하고, 문제를 해결할 수 있는 전략(비관적 락 / 조건부 UPDATE)을 각각 상황에 맞게 적용함 - 스케줄러와 결제 로직 간의 상태 충돌 가능성을 인지하고, 이를 테스트 코드로 검증 - 예외 상황에서도 결제 실패 이력을 남길 수 있도록 별도 트랜잭션 분리를 적용 (REQUIRES_NEW)- 요청 DTO에 검증 애노테이션(@NotBlank, @Min 등)을 활용해 잘못된 요청을 조기 차단할 수 있도록 개선 ❗️ Problem (문제점)- SeatStatus..

🧐 4주차 과제 1. 예약/결제 기능 : 레이어드 아키텍처 ➡ 클린 아키텍처로 전환하기2. 테스트 컨테이너로 테스트 가능하도록 구성 3. 기능별 통합테스트 작성 ✅ Keep (잘한 점 / 유지할 점)- 클린 아키텍처의 구조를 이해하고, 레이어드 아키텍처로 구현했던 패키지를 클린 아키텍처로 전환함- 대기열 토큰 로직을 설계하면서 예매 흐름(조회 ➡ 예약 ➡ 결제)의 전반적인 흐름을 제어하는 구조를 구성해봄 - 상태 기반의 접근 방식(READY / EXPIRED 등)을 적용하고, 클린 아키텍처 구조 내에서도 Validator 컴포넌트를 활용해 공통 검증 로직을 분리함 ❗️ Problem (문제점)- DB 제약조건(UNIQUE) 설정으로 인해 이미 EXPIRED 된 토큰이 있음에도 발급이 막히는 문제가 발생..

🧐 3주차 과제 : 비즈니스 로직 개발 및 단위 테스트 작성 1. 콘서트 조회 : 레이어드 아키텍처 2. 포인트 충전 기능 : 레이어드 아키텍처3. 예약/결제 기능 : 클린 아키텍처 ✅ Keep (잘한 점 / 유지할 점)- DDD구조로 콘서트, 포인트, 예약/결제 기능을 도메인별로 나누어 구현하면서, 레이어드 아키텍처 구조에 익숙해졌다. (기존에 항상 구현하던 방식이 레이어드여서 이미 익숙했지만..ㅎㅎ)- 예약과 결제를 하나의 흐름으로 구성하고, 단위 테스트도 서비스 레벨에서 꼼꼼히 작성해보며 테스트 작성 능력이 조금 더 익숙해졌다.- 스프링 스케줄러를 이용한 좌석 상태 변경 로직(EXPIRED → HOLD → AVAILABLE)을 설계·구현하고, 테스트해보며 시간 기반 로직도 경험할 수 있었다.-..

🧐 2주차 과제 : 선택한 시나리오 분석1. 시나리오 선택 및 github 프로젝트 Milestone 작성: 콘서트 예약 서비스 2. 분석 문서 작성 ◾ 요구사항 정의서 ◾ 시퀀스 다이어그램 ◾ 클래스 다이어그램 ◾ ERD ◾ 상태 다이어그램 ◾ 인프라 구성도 ✅ Keep (잘한 점 / 유지할 점)- 콘서트 예약 서비스를 선택하고, 시나리오를 구체화하여 요구분석을 작성하며 도메인 흐름을 명확히 잡으려고 했다.- 실제 구현을 생각하며, ERD, 상태/시퀀스/클래스 다이어그램을 정리했다. ❗️ Problem (문제점)- 상태/시퀀스/클래스 다이어그램을 작성하는게 막막해서 흐름을 잡는데 시간이 오래걸렸다.- 좌석의 상태 변화에 대해 고민이 많아 설계가 반복적으로 바뀌었다. (좌석 임..

🧐 1주차 과제 : TDD 기반 포인트 서비스 구현1. TDD기반으로 controller 및 필요한 코드 작성2. 각 기능에 대한 단위 테스트 작성3. 동시성 제어에 대한 통합 테스트 작성✅ Keep (잘한 점 / 유지할 점)- 테스트를 먼저 작성하고 실제 구현을 진행하는 TDD 흐름을 최대한 따르며 개발을 진행했다. (Red - Green -Refactor 사이클 기반)- 단위 테스트에서는 Mock 객체를 활용해 빠르고 명확한 단위 검증을 수행했고, 통합 테스트에서는 실제 구현체로 전체 흐름을 검증했다. - 예외 상황을 정의해보고, 동시에 여러 요청이 들어오더라도 순서대로 제어될 수 있도록 리팩토링했다. ❗️ Problem (문제점)- TDD 흐름을 처음 적용하다보니, 테스트 코드를 작성하는 것이 더..