강의를 듣고 문득 궁금한 점이 생겼습니다.

Question

현재 강의는 핵사고날 아키텍처를 사용하여 결제 시스템을 구축하고 있습니다. 어니언 아키텍처로도 충분히 의존성을 안쪽으로 향하게 하여 entity와 usecase를 외부 변경으로 부터 보호가 가능하지 않나 생각이 들었습니다. (결정적으로 핵사고날은 구조가 좀 복잡했습니다.) webflux를 쓰신 이유가 궁금합니다. 강의에서 내세운 견고한 시스템을 만들기위한 요구사항을 읽어봤을 때 반응성이 아니더라도 충분히 무리가는 상황이 아니기도 했고 성능보단 견고함이 중요한 상황인데 webflux를 쓰신 이유가 궁금합니다!   제 역량이 모자라 이해 못하는 부분이 있을 수 있어 배우고자 질문드립니다. 감사합니다!

여정민 · Answer

안녕하세요~ 질문 남겨주셔서 감사합니다. 궁금한 사항이 있으셨던 것 같은데 제 생각을 남겨볼게요.   1) 어니언 아키텍처가 아닌 핵사고날 아키텍처로 한 이유: 저는 어니언 아키텍처와 핵사고날 아키텍처가 크게 다르다고 생각하지는 않아요. 핵사고날 아키텍처가 조금 더 복잡할 순 있겠지만 외부 시스템과의 입출력 상호작용을 파악하기 더 쉽다라고 생각하기 때문에 사용했습니다. 장단점을 판단해서 자신에게 맞는 아키텍처를 사용하면 될 것 같습니다.   2) Webflux 를 사용한 이유: Spring Webflux 와 Spring MVC 를 비교했을 때 Webflux 가 좀 더 복잡한 프로그래밍을 요구하는 것 제외하고는 웬만해서는 MVC 보다 안정성 측면에서도 더 뛰어나다고 생각해요. 현재의 시스템은 서비스들이 마이크로서비스처럼 대부분 쪼개져있고 필요할 때 외부 통신을 하는데요. Spring MVC 와 같은 Synchronous Client 를 사용하게 되면 외부 서비스들이 장애가 나거나 요청이 안왔을 때 리소스가 점유당하는 문제가 생길 수 있습니다. 그에 반해서 웹플럭스와 같은 Asynchronous Client 는 하나의 이벤트 루프에서 최대 500개 까지의 Active Channel 을 맺을 수 있기 때문에 외부 서버의 장애에 클라이언트를 보다 보호해줄 수 있는거죠. 현재의 이 결제 시스템의 경우에는 외부 시스템과 상호작용하는 API 가 거의 없는데요. 카카오페이의 경우에는 수십개의 API 를 사용한다고도 합니다. 이 경우에는 Webflux 가 보다 안전할거에요.   도움이 되셨으면 좋겠습니다. 제 답변이 잘 와닿지 않는다면 다시 질문 주세요~