Gukin Han

통합 테스트 cleanup 방식 전환으로 누적 수행 시간 개선

Mon, 20 Apr 2026 17:46:21 +0900

테스트 코드를 실무에 적용하면서 겪는 문제들

복잡했던 도메인 로직들이 리팩토링되고, 필요한 Fixture를 만들어두니 테스트 코드 작성 속도가 빨라지고 있다. 요즘은 매 스프린트마다 테스트 개수가 크게 증가하며, 하나 둘씩 관련 문제가 생기고 있다.

지난 포스트에서는 Application Context(이하 컨텍스트)의 증가¹로 인해 MySQL로 연결되는 커넥션 수가 max_connections에 도달해서 발생하는 Too Many Connections을 다뤘다. 클래스마다 MockBean 조합이 다르면 Spring 컨텍스트의 캐시미스가 발생하여 Spring이 컨텍스트를 새로 만들기 때문에, MockBean을 통합하는 방식으로 해결할 수 있었다. 현재는 어드민 권한 테스트용 하나와 일반 유저 테스트용 하나의 컨텍스트로 총 2개만 유지되도록 매 스프린트마다 유지보수하는 중이다.

Hugo로 새 블로그를 시작합니다

Wed, 08 Apr 2026 00:00:00 +0000

티스토리에서 새 글은 이곳에 쓰기로 결정했습니다. 점진적으로 이전할 예정이며, 기존 글은 티스토리에 그대로 있습니다.

Spring 통합 테스트의 다중 ApplicationContext로 인한 Too many connections

Wed, 01 Apr 2026 00:00:00 +0000

개별 테스트는 통과, 전체 실행시 Too many connections 발생

여러 기능 브랜치가 개발 브랜치로 머지된 후, 그동안 기능 개발하면서 놓친 실패 테스트들을 점검하기 위해 전체 테스트를 실행했다. Too many connections 에러로그가 발생하면서 통합테스트들 일부가 실패하였다. 로그의 일부는 아래와 같다:

Error creating bean with name 'liquibase': Too many connections
  → Error creating bean with name 'databaseCleanupUtil'
  → Failed to load ApplicationContext

하지만, 각각 테스트 클래스들을 개별로 실행했을때는 모두 통과했다. 도대체 왜 동일한 코드에서 실행 범위만 다를 뿐인데 결과가 다를까?

Virtual Thread로 인한 HikariCP 커넥션 풀 고갈 해결 과정 - 트랜잭션 경계 분리로 타임아웃 제거

Thu, 19 Mar 2026 00:00:00 +0000

Virtual Thread 적용 이후 대량 이벤트 발생시 DB 저장 로직 실패

진행중인 개인 프로젝트에서는 DART 전자공시를 이용한다. 매일 수백 개의 전자공시가 DART 전자공시를 통해 게시되며 이를 수집해서 필터링하고 시장의 반응과 LLM의 감성분석을 집계하는 목표를 갖고 있다.

공시 자료 폴링(Polling)이 중단되었다가 재시작 하는 경우 다량의 공시자료를 조회하고 이벤트를 발행하게 된다. 이때 분석된 결과를 DB에 저장하는 과정에서 이슈가 발생했다. 이 과정의 비즈니스 로직은 아래와 같이 정리할 수 있다.

Polling으로 새 공시를 수집한다.
수집된 공시의 제목으로 후속 처리가 필요한지 필터링한다.
후속 처리가 필요하면 NewDisclosureEvent를 발행한다.
이벤트 메시지에 담긴 공시 번호로 공시 문서를 조회한다.
조회된 공시 문서를 LLM에게 넘겨서 감성 분석(Sentiment Analysis)을 실시한다.
분석 결과를 DB에 저장한다.

문제가 발생한 코드는 다음과 같다.

시간당 34GB Spring Boot 로깅이 TPS에 미치는 영향과 병목점 분석

Sun, 01 Mar 2026 00:00:00 +0000

시간당 34GB의 로그 발생

사내 인프라 담당자가 우리가 담당하고 있는 서버의 로깅 설정 관련된 내용을 공유해주었다. 간단하게 정리하면 다음과 같다:

Cloudwatch는 로그 GB마다 과금되는 형태
불필요한 로그로 인해 비용이 발생하는것으로 확인됨
현재 서비스에서 발생하는 로그(특히 info)를 점검할 필요가 있음

도메인 개발자라서 인프라 업무를 직접 수행할 기회와 권한이 없었다. 이번에 인프라팀이 공유해준 걸 계기로 개인적으로 살펴보았다. 먼저 Cloudwatch에 들어가 직접 눈으로 로그 발생량을 확인했다.

우리 서비스는 HR 서비스이기 때문에 대부분의 트래픽은 9시부터 18시 사이에 발생한다. 시간당 대략 34GB(2.7억건)의 로그가 발생하며 그 중에 44% 정도가 jdbc.resultset=INFO 에서 발생함을 확인했다. 여기서 몇 가지 의문이 들었다.

자바 객체 생성(new) 비용은 비쌀까? - 힙 메모리 할당 과정 3단계 분석

Wed, 04 Feb 2026 00:00:00 +0000

들어가며

이전 포스팅들은 스택 영역에서의 바이트코드의 상호작용을 다뤘다. 런타임 데이터 영역에는 스택 영역 뿐만 아니라 힙 영역이 존재한다. JVM 스펙에 따르면 다음 내용을 확인할 수 있다:

“자바 가상 머신은 모든 스레드가 공유하는 힙(Heap) 영역을 가지고 있습니다. 힙은 모든 클래스 인스턴스와 배열의 메모리가 할당되는 런타임 데이터 영역입니다.”

따라서, 이 글에서는 객체와 힙 영역에 관련된 여러 요소들을 탐험하고 실험하는데 목적이 있다.

Object 클래스의 객체 생성 (new 키워드)

처음으로 시도해볼 실험은 가장 순수한 객체를 생성해보는 것이다. 아무런 필드도, 로직도 없는 가장 순수한 형태의 객체를 생성해 볼 수 있는 클래스는 java.lang.Object이다. Object 객체를 생성할때 과연 몇 번의 CPU 명령어를 소모할까? 어떤 과정을 거칠까?

바이트코드로 이해하는 자바 제어 흐름(Control Flow)

Sun, 25 Jan 2026 00:00:00 +0000

들어가며

이전 포스팅에서는 컴파일된 증감연산자(i++, ++i)의 정적인 바이트코드를 분석했다. 해당 실험에서는 load, store 등의 명령어를 피연산자 스택을 통해 어떻게 연산이 이뤄지는지, iinc 명령어의 최적화 방식을 이해할 수 있었다.

이번에는 단순한 연산을 벗어나, 프로그램의 실행 순서를 바꾸고 제어하는 **제어 흐름(Control Flow)**을 다뤄보려고 한다. 코드의 흐름을 나누는 분기문(if-else), 특정 구간을 반복하는 반복문(for-loop, while), 조건에 따라 특정 점프하는 스위치문(switch)에 해당된다.

각각 바이트코드 레벨에서 어떻게 흐름을 제어하는지 실험을 통해 살펴본다.

실험

java 코드를 작성하고 javac ControlFlowTest.java 와 javap -c -p -v ControlFlowTest > result.txt 명령어를 이용해서 컴파일과 역어셈블을 하였다. 3개의 섹션을 나눠서 각각 분기문, 반복문, 스위치문을 실험 및 분석하였다.

레지스터 vs 스택 머신 - 자바는 왜 스택 방식을 택했는가? (바이트코드 분석)

Mon, 19 Jan 2026 00:00:00 +0000

들어가며

이 글은 거창하게 바이트코드를 분석하려는 의도로 시작하지 않았다. 단지 JVM을 학습하는 과정에서 제시된 간단한 실습 예제를 직접 실험해보고 있었다. 작성된 자바 파일을 javac와 javap 명령어로 컴파일하고 역어셈블(Disassemble)하는 과정은 생각보다 많은 질문을 던져주었다.

“우리가 작성한 소스코드는 실제로 JVM 위에서 어떻게 돌아갈까?” “단순한 i++ 연산은 CPU와 메모리 관점에서 어떤 비용을 지불하는가?”

이러한 질문을 가지고 실험을 하면서, 컴파일러의 최적화와 JVM의 스택 머신 아키텍처 특징을 바이트코드와 그 연산 플로우에서 확인할 수 있었다. 이 글에서는 간단한 증감 연산자(i++) 실험을 통해 소스코드가 바이트코드로 변환될 때 발생하는 차이와 그 원리를 정리해본다.

자바 플랫폼 vs 가상 스레드 - 언제, 왜 성능 차이가 나는가?

Sun, 11 Jan 2026 00:00:00 +0000

요약

가상 스레드는 CPU성능을 높이는 기술이 아닌, 대기 중인 스레드의 점유 비용을 낮추는 동시성 모델이다.
스파이크 트래픽 환경에서 I/O-bound 작업은 가상 스레드로 인해 큐 대기와 p95 지연이 크게 줄어들었다.
CPU-bound 작업에서는 스레드 모델 변경만으로 유의미한 성능 차이가 나타나지 않았다.
가상 스레드는 병목을 제거하기보다, 병목의 위치를 스레드에서 다른 계층(DB, 외부 API 등)으로 이동시킨다.
따라서 가상 스레드 도입은 성능 최적화 문제가 아니라, 백프레셔/타임아웃/제한 등의 설계를 포함한 시스템 설계 문제로 여겨야한다.

문제

상관 서브쿼리로 인한 읽기 병목 개선

Sat, 13 Dec 2025 00:00:00 +0000

요약

문제
- 운영 환경에서 조회 API 응답 지연(1초 이상) 이슈 발생
- 상관 서브쿼리로 인한 N+1 패턴이 DB 레벨에서 발생
과정
- 실행 계획 분석을 통해 Nested Loop 반복 실행과 옵티마이저 통계 오류를 확인
- 상관 서브쿼리를 CTE + Hash Join 구조로 리팩토링
성과
- 서브쿼리 실행 92회에서 1회로 감소
- 총 실행 비용 246.0에서 40.6로 감소 (약 83% 개선, 6배 성능 향상)
- 운영 데이터 기준으로 실행 계획 변화와 성능 개선을 수치로 검증

문제 배경

운영 중인 서비스에서 특정 테넌트 기준 조회 API의 응답지연이 보고되었다. 슬로우 쿼리 분석 결과, 직원을 그룹화하는 테이블의 조회 쿼리 내부에 상관 서브쿼리(Correleated Subquery)가 포함되어있었다. 그 영향으로 메인 쿼리 결과 행 수만큼 서브쿼리가 반복 실행되는 문제가 발생했다.

Fat 메시지로 인한 Consumer 메모리 누수 케이스

Sun, 23 Nov 2025 00:00:00 +0000

문제

현상: 8개 Fargate Task 중 1개만 메모리 사용률이 지속 상승 (60% → 97%)
결과: 메모리 알람 후 해당 Task 재시작
특이점: 동일 코드 기반의 다른 Task들은 GC 정상 작동
환경: Java 21, Spring Boot, Kafka Consumer, MyBatis Batch, AWS Fargate

증상 분석

CloudWatch 메모리 그래프: 특정 Task만 계단식 상승
덤프 서버: 동일 이벤트 처리에도 톱니형 GC 패턴 (정상)
GC 자체 문제라기보다는 객체 참조 유지로 인한 회수 불가 상황에 가까움

원인 분석

대량 청크 메시지

권한 갱신 이벤트를 한 번에 2,500건 단위로 Kafka에 게시
특정 Task가 해당 청크를 독점 처리하면 순간적으로 수만 개 객체 생성

중복 역직렬화

Consumer 내부에서 Map → DTO → VO 변환을 최대 세 번 반복
일시적 객체 폭증, Eden → Old Gen 승격 가속

MyBatis Batch 누적

ExecutorType.BATCH 사용 시 flushStatements() 전까지 파라미터 참조 유지
GC 입장에서는 여전히 “사용 중” 객체로 인식

컨슈머 병렬성 부족

단일 스레드 리스너로 동작
특정 파티션이 한 Task에 몰리면 부하 편향 및 메모리 사용량 집중

GC 관점에서 정리

구분	설명
GC는 참조가 끊긴 객체만 수거	리스트, 세션 등에서 참조 중이면 회수 불가
부하가 높으면 safepoint 진입 지연	GC 실행 타이밍이 밀리면서 Old Gen 누적
Old Gen 승격 가속	장수 객체가 많아질수록 Old Gen 압박 증가
덤프 서버에서 정상인 이유	부하가 낮아 GC 개입 여유가 충분

단기 개선 해결책

조치	설명	기대 효과
DTO 직접 바인딩	@KafkaListener에서 Map 대신 DTO로 수신	중복 역직렬화 제거
청크 분할 처리	2,500건 → 500건 단위로 분할 처리	동시 생성 객체 수 감소, 생존 시간 단축
리스트 참조 해제	처리 후 리스트 `clear()` 또는 참조 `null`	GC 회수 가능 시점 앞당김
Batch flush 주기 조정	200건마다 `flushStatements()` 호출	MyBatis 내부 파라미터 참조 조기 해제
필드 누락 복구	누락된 `accessType` 필드 복원	불필요한 대량 delete 방지

장기 개선 해결책

Kafka Consumer 병렬성 향상 (factory.setConcurrency(2) 등)
Partition assignment 전략을 cooperative-sticky로 조정
DLQ(Dead Letter Topic) 구성으로 재시도 루프 제거
Micrometer로 배치 크기, 처리 시간, lag 메트릭 수집 및 모니터링

근태 서비스에 이벤트 기반 아키텍처를 적용한다면 - Polling Adapter + Kafka

Fri, 05 Sep 2025 00:00:00 +0000

우리는 매일 아침 출근을 한다. 근태관리에서 출퇴근은 결국 돈과 관련되기 때문에 고용주/고용인 양쪽 입장에서 모두 중요하며 민감하게 생각한다.

과거에는 종이에 구멍을 뚫어(punch) 출퇴근 관리를 하였다. 언어란 신기하게도 현대 사회에서는 더 이상 사용하게 되지 않은 사물이나 행위를 나타내는 용어를 관습적으로 사용하는 경우가 많다. 여기서 얘기하는 펀치(punch)도 유사하게 출퇴근을 나타내는 용어로 여전히 사용 중이다. 펀치 인은 출근, 펀치 아웃은 퇴근. 아마 일부 외국 e-HR 시스템에서는 여전히 이러한 용어들을 사용하지 않을까?

트랜잭션에서 이벤트로 - Sync / Async / Redis 성능 비교와 TTV 분석

Fri, 29 Aug 2025 00:00:00 +0000

문제

@Transactional
public void like(String loginId, Long productId) {

    // 1. 유저 조회
    User user = userService.getByLoginId(loginId);

    // 2. 상품-좋아요 Insert
    boolean isInserted = productLikeRepository
      .insertIgnoreDuplicateKey(user.getUserId(), productId);
    
    if (!isInserted) return;
    // 3. 좋아요 수 집계 Update
    productRepository.incrementLikeCount(productId);

}

좋아요 기능에서 처음엔 모든 로직을 하나의 트랜잭션 안에서 동기적(Sync)으로 처리
안정적이지만 트랜잭션 크기가 커지고, 상품 핫키에 경합으로 인한 병목이 발생
그래서, 이벤트 기반 설계를 통해 결합도를 낮추고(loosely coupled), 책임을 분리하려는 시도

Github PR : https://github.com/gukin-han/commercial-service/pull/7

정규화부터 캐싱까지 - 상품 목록 페이지네이션 최적화 과정

Fri, 15 Aug 2025 00:00:00 +0000

요약

정규화 쿼리(집계 + 정렬) → 풀스캔 + filesort로 ~17초 소요.
역정규화 + 정렬 포함 인덱스 → ~227ms (약 76배 향상).
OFFSET 페이지네이션 → 인덱스 순차 스캔 시작 → 임계점에서 Table Scan + Filesort로 전환 → 이후 응답시간 급등.
전환 전 일정한 속도는 InnoDB 버퍼 풀/캐시 히트율 덕분.
Keyset(Seek) 페이지네이션 → 깊은 페이지에서도 일정 성능 (421ms → 31ms, 92.6% 단축).
인덱스 설계는 핫 트래픽 패턴(브랜드 + 인기순/최신순/최저가순)에 맞춘 3개의 복합 인덱스 유지가 가성비 최적.
- 설계 원칙: 필터 선두 → 정렬키 → tie-breaker(id)
캐시(Cache-Aside) 적용 시 200RPS에서도 DB I/O 부하 없이 ms 단위 응답 가능.
- 단, TTL·Evict 정책·실시간성 요구사항·정합성 유지·스탬피드 방지 등 고려 필수.
결론: 정규화/역정규화 → 인덱스 설계 → 페이지네이션 전략 → 캐싱이 단계적으로 맞물려 성능을 좌우함.

문제 정의와 가설

웹 서비스에서는 쓰기 보다 읽기 트래픽이 압도적으로 많다는 글을 읽거나 실제로 경험해봤을 것이다.

MySQL InnoDB에서 읽기·쓰기 충돌부터 deadlock 로그 분석까지

Fri, 08 Aug 2025 00:00:00 +0000

요약

MVVC는 트랜잭션 시작점을 기준으로 데이터 버저닝을 한다
락 종류에 따라 충돌 상황을 테스트
- 공유락은 말그대로 트랜잭션끼리 공유할 수 있다
- 베타락은 말그대로 하나의 트랜잭션만 가진다
- 공유락을 가진 상태로 업데이트, 삭제 등을 하면 베타락을 획득하려는 시도를 한다
- 락 획득 대기 사이클이 생기면 데드락이 발생한다
데드락을 최소화하기 위한 락 설계 방법:
- 락을 잡는 순서를 트랜잭션 마다 동일하게 유지
- 락 범위를 축소
- 첫 쿼리 부터 for update로 가져오는 방법

배경

이번 주차는 낙관적 락과 비관적 락을 학습하게 되었다. 비관적 락은 흔히 느리지만 정합성이 중요할때 사용하며, 낙관적 락은 충돌 가능성이 낮을 때 상대적으로 빠른 상황을 요구할때 사용한다고 한다.

멱등성 키(Idempotency Key)의 이해와 기업 사례 정리

Fri, 25 Jul 2025 00:00:00 +0000

배경

멱등성(idempotency)은 단순히 “두 번 호출해도 한 번만 처리된다(Exactly-Once)“를 벗어나 시스템에 큰 이점을 제공한다.

우리 서비스에는 급여계산을 위한 근무시간을 산출할 때, 반복적으로 수행되어도 괜찮게 설계되어 있다. 반복적으로 요청이 들어왔을 때 결괏값이 addUp 하는 게 아니라 refresh 된다.

휴가계산도 동일하게 적용된다. 회사의 연차규정과 직원의 입사일에 따라 연차가 계산되는데 새로운 요구사항이 전달되어 수정하게 되었을때 계산결과가 잘못되어도 올바르게 계산되는 로직으로 수정해서 실행시키면 덮어씌워지게 된다. 물론 돈과 관련된 일이라 항상 조심하고 테스트를 잘 작성해야 한다.

좋은 테스트는 무엇인가? 레거시 시스템에 테스트 환경 구축

Fri, 18 Jul 2025 00:00:00 +0000

요약

반복적인 수동테스트로 불편함을 느껴서 테스트 환경을 구축하였습니다
구축하고 테스트를 작성하는 과정에서 구성 방식, 데이터 클린업 등에 대한 고민을 하였습니다
결과적으로 어떻게 설계하고 테스트를 작성할지 자신만의 기준을 정할 수 있게 되었습니다

수동 테스트의 반복 비용

마이클 페더는 “레거시 코드 활용 전략”에서 레거시 코드를 다음과 같이 정의했다:

“테스트가 없는 코드는 곧 레거시 코드다”

테스트 코드가 없는 조직은 신기능 개발이나 이슈로 인한 코드 수정이 발생하면 일부 기능에 대한 수동 테스트를 진행하게 된다. 예를 들어, 연차를 생성하는 옵션에 요구사항이 바뀌면 연차 생성을 위한 옵션 설정을 하고 여러 직원, 근무형태 케이스에 대해 모두 테스트를 진행하게 된다. 아무래도 다양한 경우의 수를 확인하기 어렵기 때문에 숨어있는 모든 버그를 찾아내기란 쉽지 않았다.

Java 스레드의 메모리 관리와 할당에 대한 이해

Sun, 04 May 2025 00:00:00 +0000

배경

Spring Boot에서는 Async 어노테이션으로 비동기 메서드를 쉽게 작성할 수 있다. 우리 팀에서 운영 중인 서비스에는 알림 생성 로직을 비동기로 실행하고 있다. 그 알림들 자체는 미래에 발생하기 때문에 동기적으로 작성할 필요가 없고, 유저들에게 응답속도를 높이기 위한 결정으로 보였다.

Spring Boot의 코어 기능인 AutoConfiguration 덕분에 ThreadPoolTaskExecutor 빈도 자동으로 등록되지만, 실무에서는 IO-Bound, CPU-Bound 등 목적에 맞는 스레드 풀을 만들어 운영할 필요가 있다. 서로 다른 특성을 가진 작업을 혼합해서 사용하면 비효율이 발생하기 때문이다. CPU 사용이 낮은 IO-Bound 작업은 코어보다 많은 수의 스레드를 풀에 담아 사용하고, CPU 사용률이 높아 컨텍스트 스위칭 비용이 높은 CPU-Bound 작업은 코어 수에 비례해서 제한해야 한다.

Java enum을 활용한 전략 패턴(Strategy Pattern) 실무 적용기

Fri, 25 Apr 2025 00:00:00 +0000

B2B 서비스에서 새로운 고객사가 들어오거나 기존 기능을 수정 및 이슈 픽스 해야하는 상황일 때 복잡한 if-else 레거시가 유지보수 효율성 문제를 자주 발생시켰다. enum 방식의 전략 패턴을 도입했고, 각 로직에는 단위테스트를 쉽게 도입할 수 있었다. 결과적으로 회귀테스트 비용이 제로로 떨어졌고, 나중에 팀원이 동일한 작업을 진행하면서 추가 작업이 쉬워졌음을 느꼈다고 공유해주었다.

이 글에 사용된 코드는 실제 프로덕션 코드가 아닌, 핵심 구조만 재구성한 예시입니다.

유지보수 관점에서 if-else의 문제점

모든 if-else 구조가 나쁜 것은 아니다. 때론 간결하고 단순한 코드 방식이 더욱 유지보수에 유리한 경우가 있다.

DELETE-INSERT 패턴에서 발생하는 InnoDB Deadlock 분석

Mon, 21 Apr 2025 00:00:00 +0000

배경

최근 우리 서비스는 Sentry를 통해 데드락 알람을 자주 받고 있다
처음에는 중복 인덱스를 발견해서 제거하는 작업을 진행했다
- 그럼에도 불구하고 동일한 로직에서 데드락이 발생하는 중이다
- 조금은 빈도가 감소했을 수 있는데, 데드락 모니터링과 수집 및 통계화를 다른 회사에서는 어떻게 하는지 리서치가 필요해 보인다
아무튼 데드락을 분석해보니, 동일한 레코드의 DELETE-INSERT가 하나의 트랜잭션 내 수행되는 API에서 발생하였다
명확한 원인을 파악하고 전략을 세우기 위해 분석을 시도하였다

InnoDB Deadlock 분석

InnoDB 엔진 내부 상태를 확인하는 방법

RDMBS 클라이언트에서 위 명령어를 입력:

ECS Auto Scaling의 파라미터 피팅: 목표값 설정, 부하 테스트, 운영 회고

Wed, 15 Jan 2025 00:00:00 +0000

1. 서비스 오픈 대비하여 Auto Scaling 켜기

팀에서 담당하는 서비스 오픈이 임박하게 되었고, 가용성 확보를 위해 ECS에 Auto Scaling을 적용해야 했다. 백엔드 팀 내에는 인프라 작업 경험자가 없었고 주니어 입장에서 서비스를 이해하는데 도움될 것으로 판단하여 자원하였다.

요청된 작업은 기존에 작성된 IaC를 수정해서 Auto Scaling을 적용하는 것이었다. 개인적으로 인프라 자체도 익숙하지 않았지만, IaC를 먼저 학습하고 적용하는 과정이 이 작업의 가장 큰 병목점이라고 생각했다. 하지만 적용하는 과정에서 해야 했던 고민들과 경험들은 단순하지 않았기 때문에 정리해서 공유한다.