<div id="readability-page-1" class="page"><div>
                                    <p><a href="/m/category/Java%20%26%20Kotlin"><span>Java &amp; Kotlin</span></a></p><h3>Kotlin Coroutine과 CompletableFuture</h3>
                                </div><p><cite>페페로니피자</cite>
                                    <span> 2023. 7. 25. 03:29</span>
                                </p><div>
                                <h2 data-ke-size="size26"><b>1) 서론</b></h2><div data-ke-size="size16"><p>이번에는 코틀린을 사용하면서 들었던 의문점을 기록으로 공유드리려고 합니다.</p><p>&nbsp;그동안 자바를 오랫동안 사용하면서 비동기 요청 시 Future 객체를 자주 사용했는데요. 코틀린에서는 주로 코루틴을 이용하여 처리하는것을 볼 수 있는데요.</p><p>&nbsp;처음 코루틴을 사용하면서 동일한 비동기처리인데 어떤것이 다른지 의문이 들었습니다. 오히려 future가 더 직관적이고 사용하게 쉽다는 생각도 했었는데요.</p><p>&nbsp;이러한 궁금증을 직접 비교해 봤습니다.</p></div><hr data-ke-type="horizontalRule" data-ke-style="style6"><h2 data-ke-size="size26"><b>2) 코루틴은 비동기 요청을 쉽게 해줘요</b></h2><figure data-ke-mobilestyle="widthOrigin" data-origin-width="1934" data-origin-height="1220">
    <span data-url="https://blog.kakaocdn.net/dn/embq9P/btsoxaGjg9z/96iHv0nGh0y9thGsOCQOl1/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/embq9P/btsoxaGjg9z/96iHv0nGh0y9thGsOCQOl1/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1934" data-origin-height="1220">
    </span>
    
</figure><ul data-ke-list-type="disc"><li><b>1개의 스레드를</b> 가진 쓰레들풀을 coroutine scope에 할당합니다</li><li><b>2개의 외부 API</b>를 요청합니다</li><li>각 API는 <b>3초의 delay</b>가 있습니다</li><li>각 API는 비동기로 요청합니다</li></ul><p data-ke-size="size16">&nbsp;<br>코루틴을 이용해서 손쉽게 비동기 요청을 보낼 수 있습니다.</p><ul data-ke-list-type="disc"><li><b>장황한 콜백 패턴을 작성하지 않아도 됩니다</b></li><li><b>스레드풀을 지정하여 각 요청을 할당할 수 있습니다</b></li></ul><p data-ke-size="size16">&nbsp;<br>코틀린의 간결함이 코루틴에서도 쉽게 보이는 것 같습니다. 로직이 복잡하지 않고, 간결하면서도 비동기 요청을 쉽게 사용할 수 있습니다.</p><hr data-ke-type="horizontalRule" data-ke-style="style6"><h2 data-ke-size="size26"><b>3) Future 객체도 가능해요</b></h2><p data-ke-size="size16">비동기 요청은 자바의 문법을 사용하더라도 쉽게 할 수 있는데요. 바로 Future 객체를 활용하면 됩니다. 자바와 동일하게 코틀린에서도 사용할 수 있는데요.</p><figure data-ke-mobilestyle="widthOrigin" data-origin-width="1938" data-origin-height="1048">
    <span data-url="https://blog.kakaocdn.net/dn/34bsR/btsoz8AtI21/LKI0ai0z9vgBJZRaxIkZS0/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/34bsR/btsoz8AtI21/LKI0ai0z9vgBJZRaxIkZS0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1938" data-origin-height="1048">
    </span>
    
</figure><ul data-ke-list-type="disc"><li>동일하게 <b>1개의 스레드를</b> 가진 풀을 만들고, 사용합니다</li><li>CoroutineScope &gt; <b>CompletableFuture</b>로 대체되었습니다</li><li>첫 번째, 두 번째 API를 요청합니다</li><li>allof().join()을 이용하여 모든 요청의 완료를 기다립니다</li></ul><div data-ke-size="size16">&nbsp;<p>이미 자바에서부터 존재하던 Future 객체를 코틀린에서도 동일하게 사용할 수 있습니다. 위에서 작성했던 코루틴 로직과 동일하게 동작합니다. 코루틴에 비해서 로직이나 사용법이 복잡하지도 않습니다.</p><p>&nbsp;자바를 비교적 많이 사용했던 입장에서 의문이 듭니다. 꼭 코루틴을 사용해야 할까요? 뭐가 다르길래 코틀린에서는 사용하는 것일까요?</p></div><hr data-ke-type="horizontalRule" data-ke-style="style6"><h2 data-ke-size="size26"><b>4) 코루틴은 논블럭킹(non-blocking)이에요</b></h2><p data-ke-size="size16">위의 코루틴, <b>Future</b>를 사용한 로직들의 수행시간을 측정해 봅시다.</p><pre data-ke-type="codeblock" data-ke-language="bash"><code>// Future
2023-07-23T20:15:34.562251: first api start
2023-07-23T20:15:37.568754: first api finish&nbsp;&nbsp;// 3초 지연
2023-07-23T20:15:37.571075: second api start
2023-07-23T20:15:40.576289: second api finish // 3초 지연
all apis finished
6047ms // 총 수행 시간</code></pre><ul data-ke-list-type="disc"><li><b>Future</b> 객체를 사용합니다</li><li>각 API 요청 시 3초의 delay가 발생합니다</li><li>싱글스레드를 사용하기 때문에 <b>순차적으로 처리됩니다</b></li></ul><pre data-ke-type="codeblock" data-ke-language="bash"><code>// coroutine
2023-07-23T20:16:58.237301: first api start
2023-07-23T20:16:58.241090: second api start
2023-07-23T20:17:01.256741: first api finish
2023-07-23T20:17:01.264407: second api finish
all apis finished
3089ms // 총 수행시간</code></pre><ul data-ke-list-type="disc"><li><b>Coroutine</b>을 사용합니다</li><li><b>첫 번째 API에서 blocking 발생합니다</b></li><li><b>곧바로, 두 번째 API를 요청합니다</b></li><li>동일하게 싱글스레드입니다</li></ul><div data-ke-size="size16">&nbsp;<p>두 로직 모두 동일하게 싱글스레드를 사용합니다.</p><p>&nbsp;각 API는 3초의 지연이 발생합니다. 하지만 <b>future를 사용했을 때는 6초</b>, <b>coroutine은 3초</b>의 수행시간이 소요되는데요.</p><p>&nbsp;<b>Future</b>의 경우 싱글스레드를 사용하기 때문에 <b>runAsync()를 사용하였지만, 실제로는 동기식으로 수행</b>될 수밖에 없습니다. <b>첫 번째 API에서 3초 지연 발생하고, 스레드는 block</b> 됩니다. 즉 해당 API의 응답이 올 때까지 대기하게 됩니다.</p><p>&nbsp;하지만 <b>Coroutine</b>의 경우 동일한 싱글스레드를 사용했지만 blocking 되지 않습니다. <b>첫 번째 API에서 3초 지연이 발생하지만</b> 곧바로 <b>두 번째 API를 요청합니다.</b> 그리고 응답이 온 순서대로 처리해 줍니다.</p><p>&nbsp;이렇게 동일한 싱글스레드를 사용했지만 결과는 다릅니다. 겉으로 보기에는 동일한 로직이지만, 수행시간에서 큰 차이를 보이는데요.</p><p>&nbsp;왜 그럴까요?</p></div><hr data-ke-type="horizontalRule" data-ke-style="style6"><h2 data-ke-size="size26"><b>5) Coroutine은 CPS 스타일을 사용하고 있어요</b></h2><p data-ke-size="size16">코루틴은 <b>suspend</b> 수정자를 이용해서 수행을 연기시킬 수 있는데요. suspend 함수에서 <b>외부 IO와 같이 대기가 필요한 순간이 오면, 스레드는 기다리지 않고 다른 일을 하러 떠납니다.</b></p><pre data-ke-type="codeblock" data-ke-language="kotlin"><code>suspend fun requestFirstExternalApi(): String {
&nbsp;&nbsp;&nbsp;&nbsp;val start = LocalDateTime.now()
&nbsp;&nbsp;&nbsp;&nbsp;println("$start: first api start")
&nbsp;&nbsp;&nbsp;&nbsp;delay(3_000L) // 3초 지연 -&gt; 쓰레드는 requestFirstExternalApi() 밖으로 나감

&nbsp;&nbsp;&nbsp;&nbsp;val finish = LocalDateTime.now()
&nbsp;&nbsp;&nbsp;&nbsp;return "$finish: first api finish"
}</code></pre><div data-ke-size="size16">&nbsp;<p>그렇다면 지연된 함수가 어떻게 재개할 수 있을까요?</p><p>&nbsp;<b>코틀린은 CPS를 사용하고 있는데요</b>. Continuation Passing Style의 약자입니다. 기존의 코드들을 컴파일하게 되면 아래와 같이 되는데요.</p></div><figure data-ke-mobilestyle="widthOrigin" data-origin-width="856" data-origin-height="325">
    <span data-url="https://blog.kakaocdn.net/dn/baMUs7/btsoSmdIwNn/l56DS93GPoa8kyRxM2FMA0/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/baMUs7/btsoSmdIwNn/l56DS93GPoa8kyRxM2FMA0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="856" data-origin-height="325">
    </span>
    
</figure><div data-ke-size="size16">&nbsp;<p>코틀린 컴파일러는 suspend 함수 사용 시 <b>파라미터로 Continuation 객체를 넘겨주고 있습니다</b>. 그리고 suspend 함수 내부에 <b>중단지점(suspension point)을 label로 표시합니다</b>.</p><p>&nbsp;코루틴에 할당된 스레드는 중단지점을 만났을 때 현재의 label을 Continuation 객체에 기록합니다. 그리고 해당 쓰레드는 <b>실행 혹은 재개가 필요한 다른 label을 실행하러 함수를 빠져나가게 됩니다</b>.</p><p>&nbsp;마치 state machine처럼 <b>현재 함수의 상태를 기록해 두고, 다른 함수를 실행시키러 가게 됩니다.</b> 그리고 재개될 때 상태를 다시 읽고, 실행시키게 됩니다.</p><p>&nbsp;즉 코틀린에서의 Continuation Passing Style은 컴파일 시점에 Continuation 객체를 파라미터로 전달하고, 상태를 기록하는 것을 의미합니다.</p><p>&nbsp;위의 CompletableFuture와 Coroutine을 싱글스레드로 동작시켰을 때 차이가 나는 이유입니다.</p><p>&nbsp;<b>Future</b>의 경우 싱글스레드를 사용할 때는 <b>외부 IO 등이 발생하면 스레드는 blocking 됩니다</b>. 즉 그대로 멈추고, 응답이 오기를 기다리게 되는데요.</p><p>&nbsp;만약 아주 큰 파일을 읽거나, throughput이 낮은 서버에서 응답에 5초가 걸린다면 어떻게 될까요? 해당 로직을 사용하는 모든 요청에 지연이 발생합니다.&nbsp;</p><p>&nbsp;이러한 장애를 피하고자 요청마다 스레드를 생성하여 할당한다면 한정된 스레드는 금방 고갈될 것이고, CPU는 문맥교환을 하느라 자원을 아주 많이 사용하게 될 것입니다. 심지어 전혀 관계없는 다른 요청이 스레드가 부족하여 함께 지연될 수 있습니다.</p><p>&nbsp;<b>Coroutine</b>의 경우에는 <b>잠시 지연시켜 두고, 다른 일을 처리할 수 있기 때문에</b> 적은 수의 스레드로도 많은 요청을 처리할 수 있게 됩니다. 그만큼 CPU의 문맥교환 빈도도 줄일 수 있을 것입니다.</p><p>&nbsp;즉 시스템 자원을 효율적으로 사용하는 측면에서도 Coroutine은 많은 이점이 있습니다.</p></div><hr data-ke-type="horizontalRule" data-ke-style="style6"><h2 data-ke-size="size26"><b>6) 총 100번 요청을 한다면, 얼마나 차이 날까요?</b></h2><p data-ke-size="size16">위와 동일하게 <b>싱글스레드</b>를 사용하여, <b>총 100번의 요청</b>을 보내봅니다. 각 요청당 지연은 3초입니다.</p><figure data-ke-mobilestyle="widthOrigin" data-origin-width="1071" data-origin-height="204">
    <span data-url="https://blog.kakaocdn.net/dn/YLBRJ/btsoUL483UB/qb8AC925VEWekqInhpcHr0/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/YLBRJ/btsoUL483UB/qb8AC925VEWekqInhpcHr0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1071" data-origin-height="204">
    </span>
    
</figure><ul data-ke-list-type="disc"><li><b>코루틴: 3130ms</b></li></ul><figure data-ke-mobilestyle="widthOrigin" data-origin-width="786" data-origin-height="287">
    <span data-url="https://blog.kakaocdn.net/dn/eoTmK5/btsoTooNnCY/994wabCcVBPzXgg0Yli1Vk/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/eoTmK5/btsoTooNnCY/994wabCcVBPzXgg0Yli1Vk/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="786" data-origin-height="287">
    </span>
    
</figure><ul data-ke-list-type="disc"><li><b>Future: 300510 ms</b></li></ul><div data-ke-size="size16">&nbsp;<p>동일한 3초 지연, 싱글스레드 환경이지만 <b>Future의 수행시간이 100배 느립니다</b>.</p><p>&nbsp;코루틴은 지연이 발생했을 때 상태를 저장해 두고, 다른 루틴을 실행시키기&nbsp;때문입니다. 즉 동시(concurrency) 수행이지만, 병렬 수행인 것처럼 동작시킬 수 있습니다.</p></div><hr data-ke-type="horizontalRule" data-ke-style="style6"><h2 data-ke-size="size26"><b>7) 결론</b></h2><div data-ke-size="size16"><p>겉보기의 코드만 봤을 때는 동일하게 동작하기 때문에 궁금증을 가졌습니다. 하지만 실제 내부의 동작과 수행시간을 측정했을 때는 아주 큰 차이가 보이는 것을 알 수 있었는데요.</p><p>&nbsp;이러한 코루틴의 장점 덕분에 코틀린에서는 Future 객체의 필요성은 아직까지 느끼지 못하고 있습니다. 적은 리소스를 이용해서 더 좋거나 혹은 동일한 성능을 가지고 올 수 있다면 큰 이득입니다. 해당 리소스를 다른 요청에 사용한다면 훨씬 더 대용량 처리에 이점이 있을 것 같습니다.</p></div><hr data-ke-type="horizontalRule" data-ke-style="style6"><h2 data-ke-size="size26"><b>8) 참고 문서</b></h2><p data-ke-size="size16"><a href="https://kotlinlang.org/spec/asynchronous-programming-with-coroutines.html#coroutine-state-machine" target="_blank"><span><b>코틀린 공식 문서</b></span></a></p>
            
            
                </div></div>

당근케잌

1) 서론
이번에는 코틀린을 사용하면서 들었던 의문점을 기록으로 공유드리려고 합니다.
 
그동안 자바를 오랫동안 사용하면서 비동기 요청 시 Future 객체를 자주 사용했는데요. 코틀린에서는 주로 코루틴을 이용하여 처리하는것을 볼 수 있는데요.
 
처음 코루틴을 사용하면서 동일한 비동기처리인데 어떤것이 다른지 의문이 들었습니다. 오히려 future가 더 직관적이고 사용하게 쉽다는 생각도 했었는데요.
 
이러한 궁금증을 직접 비교해 봤습니다.
2) 코루틴은 비동기 요청을 쉽게 해줘요
1개의 스레드를 가진 쓰레들풀을 coroutine scope에 할당합니다
2개의 외부 API를 요청합니다
각 API는 3초의 delay가 있습니다
각 API는 비동기로 요청합니다
 
코루틴을 이용해서 손쉽게 비동기 요청을 보낼 수 있습니다.
장황한 콜백 패턴을 작성하지 않아도 됩니다
스레드풀을 지정하여 각 요청을 할당할 수 있습니다
 
코틀린의 간결함이 코루틴에서도 쉽게 보이는 것 같습니다. 로직이 복잡하지 않고, 간결하면서도 비동기 요청을 쉽게 사용할 수 있습니다.
3) Future 객체도 가능해요
비동기 요청은 자바의 문법을 사용하더라도 쉽게 할 수 있는데요. 바로 Future 객체를 활용하면 됩니다. 자바와 동일하게 코틀린에서도 사용할 수 있는데요.
동일하게 1개의 스레드를 가진 풀을 만들고, 사용합니다
CoroutineScope > CompletableFuture로 대체되었습니다
첫 번째, 두 번째 API를 요청합니다
allof().join()을 이용하여 모든 요청의 완료를 기다립니다
 
이미 자바에서부터 존재하던 Future 객체를 코틀린에서도 동일하게 사용할 수 있습니다. 위에서 작성했던 코루틴 로직과 동일하게 동작합니다. 코루틴에 비해서 로직이나 사용법이 복잡하지도 않습니다.
 
자바를 비교적 많이 사용했던 입장에서 의문이 듭니다. 꼭 코루틴을 사용해야 할까요? 뭐가 다르길래 코틀린에서는 사용하는 것일까요?
4) 코루틴은 논블럭킹(non-blocking)이에요
위의 코루틴, Future를 사용한 로직들의 수행시간을 측정해 봅시다.
// Future
2023-07-23T20:15:34.562251: first api start
2023-07-23T20:15:37.568754: first api finish  // 3초 지연
2023-07-23T20:15:37.571075: second api start
2023-07-23T20:15:40.576289: second api finish // 3초 지연
all apis finished
6047ms // 총 수행 시간
Future 객체를 사용합니다
각 API 요청 시 3초의 delay가 발생합니다
싱글스레드를 사용하기 때문에 순차적으로 처리됩니다
// coroutine
2023-07-23T20:16:58.237301: first api start
2023-07-23T20:16:58.241090: second api start
2023-07-23T20:17:01.256741: first api finish
2023-07-23T20:17:01.264407: second api finish
all apis finished
3089ms // 총 수행시간
Coroutine을 사용합니다
첫 번째 API에서 blocking 발생합니다
곧바로, 두 번째 API를 요청합니다
동일하게 싱글스레드입니다
 
두 로직 모두 동일하게 싱글스레드를 사용합니다.
 
각 API는 3초의 지연이 발생합니다. 하지만 future를 사용했을 때는 6초, coroutine은 3초의 수행시간이 소요되는데요.
 
Future의 경우 싱글스레드를 사용하기 때문에 runAsync()를 사용하였지만, 실제로는 동기식으로 수행될 수밖에 없습니다. 첫 번째 API에서 3초 지연 발생하고, 스레드는 block 됩니다. 즉 해당 API의 응답이 올 때까지 대기하게 됩니다.
 
하지만 Coroutine의 경우 동일한 싱글스레드를 사용했지만 blocking 되지 않습니다. 첫 번째 API에서 3초 지연이 발생하지만 곧바로 두 번째 API를 요청합니다. 그리고 응답이 온 순서대로 처리해 줍니다.
 
이렇게 동일한 싱글스레드를 사용했지만 결과는 다릅니다. 겉으로 보기에는 동일한 로직이지만, 수행시간에서 큰 차이를 보이는데요.
 
왜 그럴까요?
5) Coroutine은 CPS 스타일을 사용하고 있어요
코루틴은 suspend 수정자를 이용해서 수행을 연기시킬 수 있는데요. suspend 함수에서 외부 IO와 같이 대기가 필요한 순간이 오면, 스레드는 기다리지 않고 다른 일을 하러 떠납니다.
suspend fun requestFirstExternalApi(): String {
    val start = LocalDateTime.now()
    println("$start: first api start")
    delay(3_000L) // 3초 지연 -> 쓰레드는 requestFirstExternalApi() 밖으로 나감
    val finish = LocalDateTime.now()
    return "$finish: first api finish"
}
 
그렇다면 지연된 함수가 어떻게 재개할 수 있을까요?
 
코틀린은 CPS를 사용하고 있는데요. Continuation Passing Style의 약자입니다. 기존의 코드들을 컴파일하게 되면 아래와 같이 되는데요.
 
코틀린 컴파일러는 suspend 함수 사용 시 파라미터로 Continuation 객체를 넘겨주고 있습니다. 그리고 suspend 함수 내부에 중단지점(suspension point)을 label로 표시합니다.
 
코루틴에 할당된 스레드는 중단지점을 만났을 때 현재의 label을 Continuation 객체에 기록합니다. 그리고 해당 쓰레드는 실행 혹은 재개가 필요한 다른 label을 실행하러 함수를 빠져나가게 됩니다.
 
마치 state machine처럼 현재 함수의 상태를 기록해 두고, 다른 함수를 실행시키러 가게 됩니다. 그리고 재개될 때 상태를 다시 읽고, 실행시키게 됩니다.
 
즉 코틀린에서의 Continuation Passing Style은 컴파일 시점에 Continuation 객체를 파라미터로 전달하고, 상태를 기록하는 것을 의미합니다.
 
위의 CompletableFuture와 Coroutine을 싱글스레드로 동작시켰을 때 차이가 나는 이유입니다.
 
Future의 경우 싱글스레드를 사용할 때는 외부 IO 등이 발생하면 스레드는 blocking 됩니다. 즉 그대로 멈추고, 응답이 오기를 기다리게 되는데요.
 
만약 아주 큰 파일을 읽거나, throughput이 낮은 서버에서 응답에 5초가 걸린다면 어떻게 될까요? 해당 로직을 사용하는 모든 요청에 지연이 발생합니다. 
 
이러한 장애를 피하고자 요청마다 스레드를 생성하여 할당한다면 한정된 스레드는 금방 고갈될 것이고, CPU는 문맥교환을 하느라 자원을 아주 많이 사용하게 될 것입니다. 심지어 전혀 관계없는 다른 요청이 스레드가 부족하여 함께 지연될 수 있습니다.
 
Coroutine의 경우에는 잠시 지연시켜 두고, 다른 일을 처리할 수 있기 때문에 적은 수의 스레드로도 많은 요청을 처리할 수 있게 됩니다. 그만큼 CPU의 문맥교환 빈도도 줄일 수 있을 것입니다.
 
즉 시스템 자원을 효율적으로 사용하는 측면에서도 Coroutine은 많은 이점이 있습니다.
6) 총 100번 요청을 한다면, 얼마나 차이 날까요?
위와 동일하게 싱글스레드를 사용하여, 총 100번의 요청을 보내봅니다. 각 요청당 지연은 3초입니다.
코루틴: 3130ms
Future: 300510 ms
 
동일한 3초 지연, 싱글스레드 환경이지만 Future의 수행시간이 100배 느립니다.
 
코루틴은 지연이 발생했을 때 상태를 저장해 두고, 다른 루틴을 실행시키기 때문입니다. 즉 동시(concurrency) 수행이지만, 병렬 수행인 것처럼 동작시킬 수 있습니다.
7) 결론
겉보기의 코드만 봤을 때는 동일하게 동작하기 때문에 궁금증을 가졌습니다. 하지만 실제 내부의 동작과 수행시간을 측정했을 때는 아주 큰 차이가 보이는 것을 알 수 있었는데요.
 
이러한 코루틴의 장점 덕분에 코틀린에서는 Future 객체의 필요성은 아직까지 느끼지 못하고 있습니다. 적은 리소스를 이용해서 더 좋거나 혹은 동일한 성능을 가지고 올 수 있다면 큰 이득입니다. 해당 리소스를 다른 요청에 사용한다면 훨씬 더 대용량 처리에 이점이 있을 것 같습니다.
8) 참고 문서
코틀린 공식 문서

Kotlin Coroutine과 CompletableFuture

댓글