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

서비스를 개발하다 보면 상태 코드, 권한 정보, 시스템 설정값처럼 여러 기능에서 반복적으로 사용하는 데이터가 생긴다.이런 데이터는 요청마다 DB에서 조회하기에는 비효율적이다. 그렇다고 애플리케이션 시작 시 한 번 조회한 뒤 계속 메모리에 보관하면 DB의 변경 사항이 반영되지 않는 문제가 발생한다.이때 사용할 수 있는 방법이 TTL과 Refresh를 이용한 캐시 관리다.TTL과 RefreshTTL은 캐시가 유효한 시간을 정하는 방식이다.Request ↓Cache 조회 ↓TTL 유효 ──────────→ Cache 반환 │ └─ TTL 만료 ↓ DB 조회 ↓ Cache 갱신예를 들어 TTL을 10분으로 설정하면 10분 동안은 DB를 다시 조회..

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

DNS란 무엇이고, 왜 필요한가?DNS(Domain Name System)는사람이 읽을 수 있는 도메인 이름을 컴퓨터가 이해하는 IP 주소로 변환해주는 시스템이다.예를 들어, www.google.com → 142.250.xxx.xxx 인터넷 통신은 결국 IP 주소로 이루어지지만,DNS 덕분에 우리는 IP를 외우지 않고도 서비스를 이용할 수 있다.DNS 조회 과정 (Domain Name Resolution)브라우저에 www.example.com을 입력했을 때 실제로 일어나는 일을 순서대로 살펴보자. 인터넷 주소창에 도메인을 입력했을 때, 사용자가 원하는 웹 사이트로 연결되기까지는 보이지 않는 곳에서 수많은 통신 과정이 일어납니다. 이번 포스팅에서는 도메인 이름을 IP 주소로 변환하는 DNS(Domain N..

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이나 @EntityGraph를 사용합니다.하지만 의욕적으로 연관된 엔티티를 모두 가져오려다 보면 MultipleBagFetchException이라는 낯선 에러를 마주하게 됩니다. 오늘은 @EntityGraph의 원리부터, 이 에러가 발생하는 이유, 그리고 실무에서 가장 권장하는 해결책인 Batch Size까지 한 번에 정리해 보겠습니다.1. @EntityGraph란 무엇인가?Fetch Join은 JPQL을 직접 작성해야 하는 번거로움이 있습니다. 이를 해결하기 위해 Spring Data JPA는 어노테이션만으로 Fetch Join 기능을 수행할 수 있는 @EntityGraph 기능을 제공합니다.사용법/..

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: 비즈니스 로직은 쿼리 메서드에, ..

“프로그래밍 언어는 사용하지 않는 메모리를 어떻게 자동으로 정리할까?”많은 언어(Java, Python, Go 등)는 개발자가 메모리를 직접 관리하지 않아도 된다.그 이유가 바로 가비지 컬렉션(Garbage Collection, GC) 때문이다.이번 글에서는 GC가 무엇인지, 어떻게 동작하는지, 장단점과 필요성까지 한 번에 정리한다. 1. 가비지 컬렉션이란?가비지 컬렉션(GC)은프로그램에서 더 이상 사용하지 않는 객체(메모리)를 자동으로 찾아 삭제하는 메모리 관리 시스템이다.즉,개발자가 일일이 free()를 하지 않아도런타임(JVM, Python 인터프리터 등)이 알아서 메모리를 정리해준다.예전 C 언어처럼 “직접 할당/해제”하지 않아도 된다는 것이 가장 큰 특징이다. 2. 왜 필요할까?GC가 없는 언..

락 선택 기준표 (한눈에 정리)구분충돌 발생 가능성충돌 시 영향도권장 락 종류예시 거의 없음낮음낮음 락 없음게시판, 댓글 수정 가끔 있음중간중간 낙관적 락문서, 프로필, 게시글 편집 자주 발생높음높음 비관적 락재고, 결제, 송금, 좌석 예매 여러 서버높음높음 분산 락쿠폰, 이벤트, 배치, 예약 작업 미션 크리티컬매우 높음매우 높음 비관적 + 분산 락 조합금전 거래, 회계 정산 시스템이 표를 보면 알 수 있듯이 충돌 가능성과 결과의 심각도가 커질수록“락의 강도”를 점점 높여가는 게 핵심이다. 실무에서 자주 발생하는 문제 ① 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) 재고 차감, 수량 관리동시에 여러 명이 접근할 때, 재고가 음수로 떨어지면 안 되는 경우예시:한정 수량 상품을 판매하는 쇼핑몰.@Transactionalpublic void order(Long itemId) ..