How-To Guide on Advanced Beginner

코루틴 디버깅

d8lzz1gpw@mozmail.com (kimbenji) — Wed, 13 May 2026 00:00:00 +0000

비동기 코루틴 코드에서 예외가 어디서 왔는지, 어떤 코루틴이 멈춰 있는지 추적하는 절차를 단계별로 안내합니다.

소요 시간: 약 15~20분

TL;DR

JVM 옵션 -Dkotlinx.coroutines.debug를 추가하면 스레드 이름에 코루틴 이름이 표시됩니다.

CoroutineName("이름")으로 코루틴에 이름을 부여해 로그에서 식별합니다.

IntelliJ의 Coroutines 탭에서 실행 중인 모든 코루틴 상태를 시각적으로 확인합니다.

kotlinx-coroutines-debug의 DebugProbes로 스택 트레이스를 복원합니다.

이 가이드가 해결하는 문제#

다음 상황에서 이 가이드를 사용하세요:

코루틴 예외의 스택 트레이스가 의미 없는 kotlinx.coroutines 내부 프레임만 보일 때
어느 코루틴이 어느 스레드에서 실행 중인지 알 수 없을 때
코루틴이 완료되지 않고 무한 대기하거나 메모리 누수가 의심될 때
CancellationException이 예상치 않게 발생할 때

시작하기 전에#

항목	요구 사항
kotlinx-coroutines-core	1.8.x
kotlinx-coroutines-debug	1.8.x (선택, 스택 트레이스 복원용)
IntelliJ IDEA	2023.1 이상 (Coroutines 탭 지원)
JVM	11 이상

의존성 추가 (Gradle Kotlin DSL):

Null Safety 마이그레이션

d8lzz1gpw@mozmail.com (kimbenji) — Wed, 13 May 2026 00:00:00 +0000

Java 코드를 Kotlin으로 이전할 때 null 관련 문제를 안전하게 처리하는 절차를 단계별로 안내합니다.

소요 시간: 약 15~20분

TL;DR

Java에서 넘어온 타입은 Kotlin에서 플랫폼 타입(예: String!)으로 추론됩니다.

@Nullable/@NotNull 어노테이션을 Java 코드에 추가하면 Kotlin이 올바른 타입을 추론합니다.

플랫폼 타입은 !! 대신 ?. 또는 ?: 기본값으로 방어적으로 처리합니다.

클래스 단위로 점진적으로 마이그레이션하고, 각 단계마다 테스트로 검증합니다.

이 가이드가 해결하는 문제#

다음 상황에서 이 가이드를 사용하세요:

Java 코드를 Kotlin으로 이전 중에 NullPointerException이 발생할 때
Kotlin에서 Java 메서드를 호출할 때 반환 타입이 nullable인지 알 수 없을 때
!! 연산자를 남발하게 되어 null 안전성의 의미가 없어질 때
Java 라이브러리를 Kotlin 코드에서 안전하게 사용하는 방법이 필요할 때

시작하기 전에#

항목	요구 사항
Kotlin	1.9.x 이상
기존 Java 코드	`@Nullable`/`@NotNull` 어노테이션 권장
IntelliJ IDEA	Java to Kotlin 변환 지원

어노테이션 의존성:

Gradle Kotlin DSL 팁

d8lzz1gpw@mozmail.com (kimbenji) — Wed, 13 May 2026 00:00:00 +0000

Gradle Kotlin DSL을 실무에서 효율적으로 사용하는 노하우와 자주 쓰는 패턴을 정리합니다.

소요 시간: 약 10~15분

TL;DR

libs.versions.toml(Version Catalog)으로 모든 의존성 버전을 한 곳에서 관리합니다.

buildSrc나 composite build로 빌드 로직을 재사용합니다.

plugins { } 블록은 apply(plugin = "...") 대신 사용하는 최신 방식입니다.

멀티모듈 컨벤션 플러그인으로 반복되는 설정을 DRY하게 유지합니다.

이 가이드가 해결하는 문제#

다음 상황에서 이 가이드를 사용하세요:

여러 모듈에서 동일한 Gradle 설정을 복사-붙여넣기하고 있을 때
의존성 버전이 여러 파일에 흩어져 있어 업데이트가 번거로울 때
Groovy DSL을 Kotlin DSL로 전환하려는데 문법이 헷갈릴 때

1단계: Version Catalog 설정 (libs.versions.toml)#

gradle/libs.versions.toml은 Gradle 7.4부터 지원하는 의존성 버전 중앙화 파일입니다.

Kotest vs JUnit

d8lzz1gpw@mozmail.com (kimbenji) — Wed, 13 May 2026 00:00:00 +0000

Kotest와 JUnit 5 스택을 비교하고, 프로젝트에 맞는 선택과 마이그레이션 절차를 안내합니다.

소요 시간: 약 15~20분

TL;DR

JUnit 5 + AssertJ + MockK: 기존 Java 팀의 마이그레이션에 유리, Spring Boot 통합 성숙

Kotest: Kotlin 네이티브 스타일, BDD 스펙, Property-based Testing 내장

둘 다 Spring Boot에서 사용 가능하며, 동시에 혼용할 수도 있습니다.

신규 순수 Kotlin 프로젝트라면 Kotest, Java 혼용 또는 팀 전환 중이라면 JUnit 5를 권장합니다.

이 가이드가 해결하는 문제#

다음 상황에서 이 가이드를 사용하세요:

성능 프로파일링

d8lzz1gpw@mozmail.com (kimbenji) — Wed, 13 May 2026 00:00:00 +0000

Kotlin/JVM 애플리케이션의 성능 병목을 찾고 최적화하는 절차를 단계별로 안내합니다.

소요 시간: 약 20~25분

TL;DR

추측하지 말고 측정 먼저. Async Profiler 또는 JFR로 실제 핫스팟을 찾습니다.

코루틴의 Dispatcher 선택이 성능에 가장 큰 영향을 줍니다. I/O는 Dispatchers.IO, CPU는 Dispatchers.Default.

람다 캡처와 boxing 비용을 줄이려면 inline 함수와 원시 타입을 활용합니다.

JIT 워밍업 전에 측정한 결과는 실제 프로덕션 성능을 반영하지 않습니다.

이 가이드가 해결하는 문제#

다음 상황에서 이 가이드를 사용하세요:

API 응답 시간이 기대보다 느릴 때 어디서 병목이 발생하는지 찾고 싶을 때
코루틴 전환 후 오히려 성능이 나빠진 것 같을 때
GC(가비지 컬렉션) 압력이 높아 지연이 발생할 때
람다와 고차 함수를 많이 쓰는 코드의 오버헤드를 줄이고 싶을 때

시작하기 전에: 측정 원칙#

추측보다 측정
성능 최적화는 항상 측정 → 분석 → 최적화 → 재측정 순서로 진행합니다. 코드를 보고 “이 부분이 느릴 것 같다"는 직관보다 프로파일러 데이터를 신뢰합니다.

측정 지표: