국비에서 과제를 진행하던 도중 발생한 일에 대하여 이야기 해보려한다.

사건의 발단

스프링의 DI와 IOC에 관한 이야기 세션을 진행하던 도중 마지막에 test코드를 보여주었는데 coEvent라는 함수를 통하여 테스트를 진행하던 것을 보았고, 어? 그러면 Spring Mvc에서 비동기 함수를 만들어서 사용해도 되는건가? 라는 의문이 들었다.

사건의 진행

DB와의 통신 과정을 비동기로 처리하는 것에 대하여 괜찮은 것인가 튜터분에게 여쭤보게 되었고 이후 그렇게 추천하지 않는다는 답변을 받았고 시도해보라는 말을 들었기에 진행해보았다.

그렇게 시도하게 되었는데...

일단 코루틴을 사용하게 되었는데 코루틴에 대한 기본이 너무나도 부족한 상황이었다.
그래서 정확히 runBlocking과 Suspend를 잠시 찾아보게 되었는데.

어라...? 왠지 익숙하다...?

사실 이전에 자바에서 특정 이벤트 처리를 위하여 내부적으로 쓰레드 풀을 만들어 관리하는 형태로 만들고 그 안에 함수형 인터페이스를 받는 형태로 설계를 진행해보려 시도한 적이 있었는데 코드의 복잡성과 다른 부수적인 문제들이 나오고 프로젝트에 어울리지 않는 과한 오버엔지니어링에 가까운 시도였기에 금방 접게 되었다. 그 때 진행했을 때 쓰레드를 정지 시키고 이벤트에 처리가 끝나면 다시 본래 쓰레드를 진행 시키는 형태였는데 그것과 매우 유사하여 대강 이런 개념일거라 생각하고 진행하니 이해하기 편해졌다.

물론 내부 동작이나 이런 건 틀리겠지만 뭐 어떤가.
가지고 있는 개념을 통하여 문제를 해결하고, 이에 대한 에러 사항이 발견 되었을 때 다시 추가 학습을 통하여 깊게 알아가는 것이 개발 아니겠는가?

다시 본론으로 돌아와 async를 통하여 일단 비동기로 모든 처리를 날려 동시에 진행시키고 마지막에 데이터를 받아오는 것을 기다리기만 한다면 어느정도 속도가 더 빠르지 않을까? 라는 생각으로 진행하였다.

사건의 결말

아, 큰 차이가 없다.
애초에 적응한 부분은 페이지네이션을 통하여 불러오는 숫자를 제한하는 형태이기도 하였고, 그것이 아닌 부분은 db에 한번 들렸다 오는 것을 굳이 비동기로 처리하니 오히려 오버헤드만 불러 일으켰다.
아주 미세하게 더 빠른 시점도 있기는 했다만 그 차이를 위해 비동기 처리를 하는 것은 절대 아니였기에 코드의 일부만 남겨놓기로 결정하고 추후 비동기 처리가 필요할 떄 사용하는 레퍼런스 코드로 남겨두기로 결정하였다.