분류 전체보기273

• 

  Spring AOP 완벽 이해하기 AOP 구현 방식 2가지Spring은 AOP(관심사 분리 — 로깅·트랜잭션·보안 등 부가기능을 핵심 로직과 분리)를 프록시 객체로 구현한다. 대상 빈을 감싸는 프록시를 런타임에 생성하는 방법이 두 가지다.1) JDK Dynamic Proxy조건: 인터페이스가 반드시 있어야 함원리: java.lang.reflect.Proxy + InvocationHandler로, 인터페이스를 구현하는 프록시 클래스를 런타임에 생성한계: 인터페이스에 선언된 메서드만 프록시 가능 (구현체의 인터페이스 외 메서드는 프록시 안 됨)성능: 생성되는 바이트코드가 단순해서 CGLIB보다 빠름2) CGLIB조건: 인터페이스 불필요 — 구체 클래스를 상속해서 프록시 생성원리: ASM 바이트코드 조작 라이브러리로 대상 클래스의 서브클래스를.. Framework/Spring 2026. 7. 30.

• 

  Java 개발자라면 반드시 알아야 할 GC의 동작 원리와 실무에서의 성능 영향 들어가며: "왜 Spring Batch 테스트가 OOM으로 터졌을까?"어느 날 Spring Batch 통합 테스트를 돌리다 갑자기 빌드가 java.lang.OutOfMemoryError: Java heap space로 실패했다.메모리 누수도 없고, 데이터도 적은데 왜 떨어지는 걸까. 며칠간 삽질한 끝에 알게 된 사실은 충격적이었다. Context 캐싱 한계로 Spring TestContext Framework가 새로운 Application Context를 계속 생성했고, GC가 충분히 빠르지 못해 메모리가 쌓여가고 있었던 것이다.그때 느낀 것이다.GC를 모르면, Java 개발자는 왜 느린지, 왜 터지는지 원인을 절대 알 수 없다.이 글에서는 GC의 동작 원리를 실제 운영 관점에서 설명하고, OOM 같은 .. Language/Java & Kotlin 2026. 7. 17.

• 

  Spring Batch 프로젝트 테스트코드 최적화 방안 배경12월 4일 이후, Spring Batch 프로젝트의 테스트코드 양이 증가하며, OOM 문제로 인해, 테스트가 50분이 넘도록 돌아가지 않고 실패했습니다. 불과 100개도 안되는 테스트 였음에도 말이죠!! 무언가 이상했습니다. webapp은 300개가 넘는 테스트가 돌고 있음에도, 동일한 Heap Memory 스펙 하에서, 더 빠른 시간 안에 처리가 됐기 때문입니다.뿐 만 아니라, 테스트가 중간에 끝났음에도 Heap Memory Size는 줄어들지 않고 있었습니다. 이로써, Batch 쪽 테스트코드 로직에 문제가 있음을 직감할 수 있었습니다.문제해결과정테스트를 실행할 때, 갑작스럽게 OutOfMemoryError가 발생했을 때, 어딘가 메모리 누수가 발생되고 있다고 판단했습니다. 따라서 기존에 작성된.. 생각정리 2026. 7. 17.

• 

  Java 개발자라면 알아야 할 JVM의 모든 것: 클래스 로더부터 실행 엔진까지 Java의 탄생 배경Java는 1991년 썬 마이크로시스템즈(이하 썬)의 제임스 고슬링과 아서 밴 호프를 주축으로 한 엔지니어들이 플랫폼으로부터 독립적으로 실행 가능하도록 개발한 언어입니다. 참고로 여기서 플랫폼이란 운영체제와 CPU 아키텍처를 말합니다. 대표적으로 Windows, Linux, Mac 그리고 x86과 핸드폰에 주로 쓰이는 arm이 있습니다. 90년대 초는 C와 C++의 사용률이 높았던 시절입니다. 썬의 개발자들이 당시 핫했던 C나 C++를 사용하지 않은 이유는 무엇일까요? 객체지향 프로그래밍은 C++로도 가능했지만, C++는 플랫폼에 따라 컴파일러에 차이가 있어 플랫폼 간 실행파일의 호환성이 보장되지 않았습니다. 이는 인터넷의 발전으로 다양한 환경에서 실행될 가능성이 높아진 프로그램들을 .. Language/Java & Kotlin 2026. 7. 17.

• 

  배포 후 첫 5분이 느린 이유: JVM 워밍업 없이 트래픽을 받으면 안 되는 이유 들어가며: 이 글은 어떤 질문에서 시작됐나Spring 서버를 배포하고 로드밸런서에 붙인 지 1분이 채 안 돼 모니터링을 보면, 같은 API 요청의 응답 시간이 200ms에서 50ms로 뚝 떨어진다. 처음엔 캐시 워밍업이라고 생각했는데, 알고 보니 JIT 컴파일러 때문이었다.이 글은 "JIT가 뭐죠?" 하는 면접 답변 수준을 넘어서, 실무에서 서버 성능을 직접 다루는 엔지니어가 알아야 할 JIT의 원리를 다룬다. 특히 다음 질문들에 답한다:왜 처음엔 느리고 계속 실행하면 빨라지나?C1, C2 컴파일러는 뭐가 다른가?배포 직후 응답 지연을 어떻게 피할까?문제 상황: 실무에서는 어디서 헷갈리나상황 1: 배포 후 초기 응답 지연서버를 Kubernetes로 무중단 배포하는 상황을 생각해보자.시간 API 응.. Language/Java & Kotlin 2026. 7. 17.

• 

  [MySQL] 인덱스 심화 2 — ORDER BY가 인덱스를 타는 조건, 암시적 형변환, 인덱스 없는 UPDATE의 락 확산 1. 문서 제목MySQL 인덱스 심화 2 — ORDER BY가 인덱스를 타는 조건, 암시적 형변환, 인덱스 없는 UPDATE의 락 확산2. 기술 개요 요약인덱스의 기본 구조(B+Tree, 클러스터드/세컨더리, 복합 인덱스 컬럼 순서)를 이해한 다음 단계는 경계 사례다. "인덱스가 있는데도 안 타는 쿼리"와 반대로 "안 탈 것 같은데 타는 쿼리"를 정확히 가르는 기준, 그리고 인덱스가 조회 성능을 넘어 UPDATE의 락 범위까지 좌우한다는 사실이 이 문서의 주제다. 판단 기준은 두 가지로 압축된다: ① 인덱스는 "저장된 정렬"이므로, 그 정렬을 그대로 활용할 수 있는 형태의 조건/정렬만 인덱스를 탄다 ② 가공되는 쪽이 컬럼이면 못 타고, 비교값이면 탄다.다루는 질문:#질문핵심 키워드1복합 인덱스 (a,b,.. DB/MySQL 2026. 7. 12.

• 

  [Kafka] 핵심 원리 정리 — 처리량이 높은 이유, acks, 오토커밋 유실·중복, 리밸런싱 1. 문서 제목Kafka 핵심 원리 정리 — 처리량의 진짜 이유, acks, 오토커밋 유실·중복, 리밸런싱까지2. 기술 개요 요약Kafka를 학습하다 보면 "파티션으로 병렬 처리한다"는 표면 지식까지는 금방 도달하지만, 한 겹 아래의 질문들 — 브로커 한 대는 왜 빠른가, 프로듀서 단에서도 순서가 꼬일 수 있는가, 오토커밋은 유실을 내는가 중복을 내는가 — 에서 막히기 쉽다. 이 문서는 그 한 겹 아래에 해당하는 6개 질문을 정리한다. 관통하는 원칙은 하나다: Kafka 파티션의 존재 이유는 "병렬 처리"와 "순서 보장" 두 가지이고, 모든 설정(acks, max.in.flight, 오토커밋, 리밸런싱, 파티션 증설)은 이 두 축 + "유실 vs 중복" 트레이드오프 위에서 해석하면 답이 나온다.다루는 질.. 메세지 브로커/Kafka 2026. 7. 12.

• 

  [Kafka] 파티션키·샤딩키로 순서가 보장되는 원리 — 유저 단위로 쪼개는 이유 1. 문서 제목파티션키·샤딩키로 순서가 보장되는 원리 — 유저 단위로 쪼개는 이유2. 기술 개요 요약메시지 큐나 샤딩된 DB에서 "특정 키를 기준으로 파티션/샤드를 나누면 그 키 단위로 순서가 보장된다"는 설계는 자주 쓰이지만 왜 되는지는 종종 뭉뚱그려 이해된다. 원리는 두 가지 사실의 결합이다 — ① 같은 키는 항상 같은 목적지로 라우팅된다(결정적 해싱), ② 그 목적지 하나는 내부적으로 순서가 있는 자료구조다. 이 문서는 이 두 축을 Kafka 파티션과 DB 샤딩 두 사례로 정리한다.3. 핵심 개념 정리개념설명실무 포인트결정적 라우팅partition = hash(key) % 파티션수 — 키가 같으면 파티션 수가 바뀌지 않는 한 항상 같은 목적지가 나옴유저 42의 이벤트는 항상 같은 파티션(혹은 샤드).. 메세지 브로커/Kafka 2026. 7. 12.

• 

  [Redis] 분산락 정리 — Watchdog·TTL·Fencing Token·SET NX 취약점 1. 문서 제목Redis 분산락 정리 — Watchdog·TTL·Fencing Token·SET NX 취약점2. 기술 개요 요약분산락(Distributed Lock)은 여러 서버 인스턴스가 같은 자원에 동시 접근하는 것을 막기 위해 Redis 같은 외부 시스템을 조정자로 쓰는 방식이다. SET key value NX EX ttl 같은 명령 하나로 구현이 간단해 보이지만, 실제로는 "락을 쥔 프로세스가 멈췄을 때", "TTL이 만료됐는데 원래 소유자가 살아 돌아왔을 때" 같은 경계 상황에서 정합성이 깨지기 쉽다. 이 문서는 그 경계 상황들을 원인 순서대로 정리한다.3. 핵심 개념 정리개념설명실무 포인트Watchdog락 보유 중 TTL을 주기적으로 연장하는 백그라운드 스레드(Redisson 기본 30초 le.. DB/Redis 2026. 7. 12.

• 

  [MySQL] 인덱스 심화 — 10%룰, B+Tree 리밸런싱, 복합 인덱스 컬럼 순서 1. 문서 제목MySQL 인덱스 심화 — 10%룰, B+Tree 리밸런싱, 복합 인덱스 컬럼 순서2. 기술 개요 요약인덱스를 "있으면 무조건 빠르다"로 이해하면 실전 튜닝에서 막힌다. 옵티마이저가 인덱스 대신 풀스캔을 택하는 기준, B+Tree가 삽입·삭제마다 스스로 균형을 맞추는 방식, 복합 인덱스에서 컬럼 순서를 정하는 진짜 기준까지 알아야 EXPLAIN 결과를 해석하고 인덱스를 설계할 수 있다. 이 문서는 이 세 가지를 정리한다. 인덱스 레인지 스캔과 랜덤 I/O, covering index는 이미 다뤘으므로 여기서는 다루지 않는다.3. 핵심 기능/개념 정리개념설명실무 포인트인덱스 vs 풀스캔 임계점("10%룰")조회 대상 로우 비율이 일정 수준을 넘어 세컨더리 인덱스의 랜덤 I/O 누적 비용이 순.. DB/MySQL 2026. 7. 12.

• 

  [Kafka] 클러스터 구조와 파티션 설계 — 트랜잭셔널 프로듀서부터 토픽 분리 기준까지 1. 문서 제목Kafka 클러스터 구조와 파티션 설계 — 트랜잭셔널 프로듀서부터 토픽 분리 기준까지2. 기술 개요 요약Kafka 클러스터는 "파티션 단위로 데이터를 나누는 샤딩"과 "파티션마다 리더-팔로워로 복제하는 replication"이 동시에 적용된 구조다. 이 구조를 이해하면 파티션 수를 늘릴 때의 비용, 토픽을 나누는 기준, 여러 파티션·토픽에 걸친 쓰기를 원자적으로 처리하는 트랜잭셔널 프로듀서, 브로커 장애 시의 대응까지 하나의 그림으로 연결할 수 있다.3. 핵심 개념 정리개념설명실무 포인트클러스터 구조파티션은 샤딩(데이터 분할), 파티션 내 리더+팔로워 복제는 replication(Redis Master-Replica와 동일 개념)브로커 하나가 죽으면 그 브로커가 리더였던 파티션들에 대해서만.. 메세지 브로커/Kafka 2026. 7. 12.

• 

  DB 커넥션 풀 사이징과 데드락 — API가 느려질 때 원인을 좁히는 순서 1. 문서 제목DB 커넥션 풀 사이징과 데드락 — API가 느려질 때 원인을 좁히는 순서2. 기술 개요 요약DB 성능 저하는 보통 "쿼리 문제 / 락 경합 / 커넥션 풀 고갈 / 리소스 부족" 네 갈래 중 하나에서 시작된다. 이 문서는 그중 커넥션 풀 사이징의 기준(코어 수 vs 쓰레드 수)과 락 경합의 대표 사례인 데드락의 발생 원리, 그리고 API 지연이 발생했을 때 실무에서 원인을 좁혀가는 순서를 정리한다. SHOW PROCESSLIST와 세부 모니터링 지표는 이미 다뤘으므로 여기서는 커넥션 풀 사이징 원리와 데드락에 집중한다.3. 핵심 기능/개념 정리개념설명실무 포인트커넥션 풀 사이징 공식의 "쓰레드"HikariCP 등에서 인용되는 (core_count * 2) + effective_spindle.. DB/MySQL 2026. 7. 12.