Kotlin Coroutine 성능 및 최적화 개선

🚀 Kotlin Coroutine 최적화 개선 내용 4가지

---

1️⃣ runBlocking → suspend fun으로 변경 (동기 실행 문제 해결)

문제점

• 기존 코드에서 runBlocking을 사용하여 코루틴이 동기적으로 실행되고 있었음.
• runBlocking을 사용하면 현재 스레드를 블로킹하기 때문에 비효율적.
• 비동기 실행의 장점을 활용할 수 없음.

개선 사항

• runBlocking을 제거하고, 함수를 suspend fun으로 변환하여 완전한 비동기 실행 가능.
• suspend 방식은 스레드를 블로킹하지 않고 비동기적으로 실행됨.

비교: runBlocking vs suspend fun

방식실행 방식블로킹 여부동시성 지원성능

runBlocking	동기 실행 (Blocking)	✅ 블로킹됨	❌ 제한적 (한 번에 하나의 작업 실행)	❌ 성능 저하 가능
suspend	비동기 실행 (Non-blocking)	❌ 블로킹되지 않음	✅ 여러 개의 코루틴 실행 가능	✅ 고성능

결론

✅ 스레드를 블로킹하지 않기 위해 suspend fun을 사용해야 함.
✅ 비동기 API와 자연스럽게 연동되므로 성능 최적화 가능.
✅ 일반적인 비즈니스 로직에서는 suspend fun 방식이 더 적합.

---

2️⃣ CoroutineScope(Dispatchers.IO).launch() 대신 withContext(Dispatchers.IO) 사용

문제점

• 기존 코드에서는 CoroutineScope(Dispatchers.IO).launch {}를 사용하여 I/O 작업을 실행하고 있었음.
• 하지만 launch는 새로운 코루틴을 생성하기 때문에, 불필요한 리소스 낭비 발생 가능.
• 실행 순서가 보장되지 않으며, 결과 값을 받을 수 없음.

개선 사항

• launch 대신 withContext(Dispatchers.IO) {} 사용하여 새로운 코루틴을 만들지 않고, 현재 컨텍스트만 변경.
• withContext를 사용하면 I/O 작업을 실행 순서를 보장하면서 동기적으로 실행 가능.

비교: launch vs withContext

차이점launch (Job)withContext (suspend 블록)

반환값	없음 (Job)	T 값을 반환 가능
코루틴 생성 여부	새로운 코루틴 생성	새로운 코루틴을 생성하지 않고 컨텍스트만 변경
실행 순서 보장	❌ 실행 순서를 보장하지 않음	✅ 실행 순서를 보장
예외 처리	부모 코루틴으로 전파됨	예외를 호출한 곳으로 직접 전달 가능
사용 목적	결과값이 필요 없는 비동기 실행 (Fire & Forget)	비동기 작업을 동기적으로 실행하고 결과를 받아야 할 때

결론

✅ I/O 작업을 수행할 때는 withContext(Dispatchers.IO)를 사용해야 함.
✅ 불필요한 코루틴 생성을 방지하고 실행 순서를 보장할 수 있음.
✅ 예외를 안전하게 처리하면서 비동기 작업을 동기적으로 실행 가능.

---

3️⃣ launch 대신 async + await() 사용하여 병렬 실행 최적화

문제점

• 기존 코드에서는 launch를 사용하여 비동기 작업을 실행한 후 join()을 사용하여 기다림.
• 하지만 launch는 Deferred를 반환하지 않기 때문에, 결과를 받을 수 없음.
• launch는 병렬 실행에는 적합하지 않으며, 결과를 필요로 하는 비동기 작업에서는 비효율적임.

개선 사항

• launch 대신 async를 사용하여 비동기 작업 후 결과를 받을 수 있도록 변경.
• 병렬 실행이 필요한 경우 awaitAll()을 활용하여 최적화.

비교: launch vs async

차이점launch (Job)async (Deferred<T>)

반환값	없음 (Job)	Deferred<T> (결과 있음)
결과 접근	.join() (완료 대기)	.await() (결과 가져오기)
예외 처리	즉시 전파됨	await() 호출 시 발생
사용 목적	단순한 비동기 실행 (Fire & Forget)	결과를 반환해야 할 때

결론

✅ 결과가 필요 없는 경우 → launch 사용
✅ 비동기 결과를 받아야 하는 경우 → async + await() 사용
✅ 즉, launch는 "실행만", async는 "결과를 반환하는 비동기 처리"에 적합! 🚀

---

4️⃣ await() / awaitAll() 사용하여 병렬 실행 최적화

문제점

• 기존 코드에서 awaitAll()을 사용하면 성능 최적화가 가능하지만, 각 API의 반환 타입이 다르기 때문에 Type Mismatch 오류 발생 가능.
• awaitAll()을 사용하면 모든 async 결과가 같은 타입이어야 함, 하지만 현재 구조에서는 반환 타입이 다름.

개선 사항

• 각 API의 응답 DTO 타입이 다르므로, 개별 await()을 사용하는 것이 더 안전하고 명확함.
• 특정 API의 결과를 먼저 받아야 하는 경우 await()을 사용하면 순서대로 로직을 제어할 수 있음.

비교: awaitAll() vs 개별 await()

차이점awaitAll()개별 await()

실행 방식	모든 async 작업을 병렬 실행 후 한 번에 결과 수집	개별 async 결과를 각각 가져옴
타입 문제	모든 응답 타입이 같아야 함	각 응답 타입이 다를 때 안전하게 처리 가능
순서 제어	순서를 제어하기 어려움	특정 API 결과를 먼저 사용할 수 있음

결론

✅ 모든 응답이 같은 타입일 때 → awaitAll() 사용
✅ 각 API의 응답 타입이 다를 때 → 개별 await() 사용
✅ 즉, 현재 코드에서는 awaitAll()보다 개별 await()을 사용하는 것이 더 적절함! 🚀

---

🔥 최종 정리

✅ 1️⃣ runBlocking → suspend fun 변경

• runBlocking을 제거하여 비동기 실행 최적화.
• 멀티스레드 환경에서도 효율적인 비동기 처리 가능.

✅ 2️⃣ CoroutineScope(Dispatchers.IO).launch() 대신 withContext(Dispatchers.IO) 사용

• 불필요한 코루틴 생성 방지.
• I/O 작업에서 실행 순서 보장 및 예외 처리 강화.

✅ 3️⃣ launch 대신 async + await() 사용하여 병렬 실행 최적화

• launch는 결과를 반환하지 않으므로, 병렬 실행이 필요할 때 async + await() 활용.

✅ 4️⃣ await() / awaitAll() 사용하여 병렬 실행 최적화

• 응답 DTO 타입이 다르므로 awaitAll() 대신 개별 await() 사용.
• 병렬 실행 최적화 및 코드 안전성 향상.