너T야? 나 T(story)야….

프로젝트를 진행하면서 댓글 작성 기능을 구현하던 중 고민이 생겼습니다.댓글이 저장된 후 작성자에게 알림을 보내는 과정이 하나의 트랜잭션 안에서 순차적으로 묶여 있었기 때문입니다.만약 알림을 보내는 과정에서 문제가 생기거나 시간이 지연된다면 사용자는 댓글 작성이 완료될 때까지 계속 기다려야 하거나 심지어 댓글 등록 자체가 실패할 수도 있다는 문제가 있었습니다.오늘은 이 문제를 해결하기 위해 Spring Event와 @Async를 도입하여 시스템의 구조를 유연하게 리팩토링한 과정을 공유합니다.1. 기존 방식의 문제점 (As-Is)초기 코드는 CommentService가 NotificationService를 직접 의존하고 호출하는 구조였습니다. // 기존 코드 (동기 방식)@Transactionalpublic..

1. Docker (도커)"애플리케이션을 실행하기 위한 패키징 툴 (단일 컨테이너 관리)"주요 특징컨테이너화 (Containerization): OS, 라이브러리, 소스 코드를 하나의 '이미지'로 묶습니다.이식성 (Portability): "내 컴퓨터에선 되는데 서버에선 안 돼요"가 불가능합니다. 어디서든 똑같이 돌아갑니다.이미지 불변성: 한 번 빌드된 이미지는 변하지 않습니다. (Immutable Infrastructure)장단점 비교구분내용장점- 가볍고 빠름: VM(가상머신)보다 부팅 속도가 압도적으로 빠름.- 환경 일치: 개발/운영 환경의 차이를 없앰.- 배포 용이: docker run 명령어 하나로 실행 끝.단점- 단일 호스트 한계: 서버가 여러 대일 때 관리하기 힘듦.- 데이터 휘발성: 컨테이너..

1. AOP (Aspect Oriented Programming)1) 개념 및 특징AOP는 "관점 지향 프로그래밍"입니다. 애플리케이션 전체에 걸쳐 반복되는 부가 기능(로깅, 트랜잭션, 보안, 실행 시간 측정 등)을 '횡단 관심사(Cross-cutting Concerns)'라고 부르며, 이것을 비즈니스 로직에서 분리해 내는 프로그래밍 패러다임입니다.2) 장점 (Pros)코드 중복 제거: 반복되는 코드를 한곳에 모아 관리할 수 있습니다.비즈니스 로직 집중: 핵심 로직이 깔끔해져 가독성과 유지보수성이 좋아집니다.생산성 향상: 어노테이션 하나로 복잡한 기능을 적용할 수 있습니다.3) 단점 (Cons)디버깅의 어려움: 코드 흐름이 눈에 보이지 않고 숨겨져 있어(Magic), 실행 흐름을 추적하기 어렵습니다.러닝..

JPA를 사용하다 보면 N+1 문제를 해결하기 위해 가장 먼저 Fetch Join을 접하게 됩니다. 하지만 무분별한 Fetch Join 사용은 코드의 유연성을 해치거나, 심각한 성능 이슈(OOM)를 유발할 수 있습니다. 1. Entity Graph vs Fetch Join: 무엇이 다를까?두 기능 모두 N+1 문제를 해결하고 연관된 엔티티를 한 번에 가져오는(Eager Loading) 역할을 합니다. 하지만 설계 관점에서 큰 차이가 있습니다.1) 핵심 차이: 관심사의 분리 (Separation of Concerns)Fetch Join: 쿼리 문장(JPQL) 안에 '비즈니스 로직(Where)'과 '페치 전략(Join fetch)'이 뒤섞여 있습니다.Entity Graph: 비즈니스 로직은 쿼리 메서드에, ..

락 선택 기준표 (한눈에 정리)구분충돌 발생 가능성충돌 시 영향도권장 락 종류예시 거의 없음낮음낮음 락 없음게시판, 댓글 수정 가끔 있음중간중간 낙관적 락문서, 프로필, 게시글 편집 자주 발생높음높음 비관적 락재고, 결제, 송금, 좌석 예매 여러 서버높음높음 분산 락쿠폰, 이벤트, 배치, 예약 작업 미션 크리티컬매우 높음매우 높음 비관적 + 분산 락 조합금전 거래, 회계 정산 시스템이 표를 보면 알 수 있듯이 충돌 가능성과 결과의 심각도가 커질수록“락의 강도”를 점점 높여가는 게 핵심이다. 실무에서 자주 발생하는 문제 ① Deadlock Deadlock이란?두 트랜잭션이 서로가 가진 락을 기다리면서무한 대기 상태에 빠지는 현상.예시 트랜잭션 A트랜잭션 B① row1 잠금① row2 잠금② row2 잠금 ..

비관적 락(Pessimistic Lock)이란?비관적 락은 이름 그대로 **“비관적으로 본다”**는 개념이다.“어차피 동시에 접근할 사람 있을 거야.그러니 내가 수정하는 동안 다른 사람은 아예 접근하지 못하게 막자.”즉,데이터를 읽는 순간 DB 레벨에서 행(row)을 잠그고,트랜잭션이 끝날 때까지 다른 트랜잭션이 접근하지 못하게 하는 방식이다.SQL로는 이렇게 쓴다. SELECT * FROM item WHERE id = 10 FOR UPDATE; 이 쿼리가 실행되면,id=10인 row는 해당 트랜잭션이 끝날 때까지 잠긴다.다른 트랜잭션이 같은 row를 수정하려 하면 대기(block) 하거나 LockTimeoutException이 발생한다.비관적 락이 꼭 필요한 상황1) 재고 차감, 수량 관리동시에 여러 ..

“서버가 여러 대로 나뉘어 있는 분산 환경에서는DB의 비관적 락만으로는 완벽히 동시성을 막을 수 있을까?”불가능하다.그래서 등장하는 개념이 바로 분산 락(Distributed Lock) 이다.왜 분산 락이 필요한가?단일 서버에서는 synchronized, ReentrantLock, FOR UPDATE 같은 락으로 충분하다.하지만 서버가 여러 대면 상황이 달라진다.예를 들어보자 서버 A와 서버 B가 같은 DB를 바라본다.두 서버 모두 동시에 “쿠폰 발급 로직”을 실행한다.서버 A에서는 이미 쿠폰 수량을 줄였는데,서버 B는 DB 락 정보를 모르기 때문에 동시에 줄여버린다.→ 결국 “하나 남은 쿠폰을 두 명이 받는” 결과가 나온다.즉,서버가 여러 대일 경우, 각 서버 간의 동기화 락이 없으면비관적 락도 완벽하..

글쓴이만 수정하는데 굳이 락이 필요할까?일반적인 게시판 구조는 이렇게 되어 있다.게시글을 수정할 수 있는 건 글쓴이 본인뿐이다.다른 사람은 수정 권한이 없다.그럼 자연스럽게 이런 의문이 든다.“동시에 수정하는 사람 자체가 한 명뿐인데, 락이 필요할까?”정답은 이렇다 필수는 아니지만, 낙관적 락(Optimistic Lock)을 걸어두는 건 매우 유용한 안전장치다.거의 성능 저하 없이 데이터 유실을 예방할 수 있다. 실제로 발생할 수 있는 “희귀하지만 짜증나는” 상황글쓴이 1명만 수정할 수 있어도 충돌이 완전히 불가능한 건 아니다.예를 들어보자.사용자가 PC 브라우저에서 수정 페이지를 열어둠.동시에 스마트폰에서도 같은 글을 열고 일부 수정.둘 다 저장 버튼을 눌렀을 때,→ 나중에 저장한 쪽이 앞서 저장한 내..

문제 상황: 동시에 수정하면 어떻게 될까?게시판이나 블로그 서비스에서 이런 상황은 흔하다.A 사용자가 게시글을 수정 중이다.B 사용자가 같은 시점에 그 게시글을 조회하거나, 심지어 수정하려 한다.이때 두 명의 수정이 겹치면 어떤 결과가 되어야 할까?둘 다 수정할 수 있다면, 나중에 저장한 사람이 앞사람의 내용을 덮어쓴다.아니면, “누가 먼저 수정했는지” 감지해서 나중 수정은 막을 수도 있다.이걸 통틀어 동시성 제어(Concurrency Control) 라고 한다. 1. 단순한 방법: “마지막 저장이 이긴다”가장 쉬운 방식은 아무 제어도 하지 않고 마지막 저장이 최종본이 되는 것이다.A가 10시에 수정 → 저장B가 10시 1분에 수정 → 저장→ 결국 B의 내용이 DB에 남는다.이건 구현은 단순하지만,문제는..

Spring Boot에서는 클라이언트로부터 데이터를 전달받을 때 @RequestBody, @RequestParam, @PathVariable 등의 어노테이션을 사용합니다. 그 중에서도 @RequestBody와 @RequestParam은 어떤 것을 써야할지 고민이 됩니다.  둘의 특징을 생각해보고 결정을 해보고자 합니다.  @RequestParam 특징 상세1. 요청 파라미터 (Query Parameter) 수신주로 GET 요청의 ?key=value 형식이나 POST 폼 요청에서 사용됨.내부적으로 HttpServletRequest.getParameter("key")와 유사하게 동작. 2. 폼 전송 (application/x-www-form-urlencoded) 지원 태그에서 submit한 값들을 받을 때 ..