논동기와 비블로킹

익숙해서 당연하게 쓰는것도 돌아보면 뭔가 아이디어를 얻을 수 있지 않을까요?

동기(Synchronous) & 비동기(Asynchronous)

 

블로킹(Blocking) & 논블로킹(Non-Blocking)

 

조합

조합	의미	특징/활용
블로킹-동기	제어권 안 줌 + 결과 올 때까지 기다림	가장 직관적. 파일 읽기, JDBC 쿼리, HTTP
논블로킹-동기	제어권은 바로 줌 + 하지만 결과 확인을 직접 계속 해야 함(polling)	CPU 낭비가 있을 수 있음. NIO 소켓, IoT polling
블로킹-비동기	제어권 안 줌 + 결과는 나중에 콜백/알림으로 옴	GUI 이벤트 루프, Future.get
논블로킹-비동기	제어권 즉시 반환 + 결과는 알림/콜백/Promise로 받음	현대 시스템에서 가장 많이 쓰는 패턴, Node.js, WebFlux, Kafka

 

먼저보는 결론

실무에서는 논블로킹 또는 비동기를 활용할 때, 가능한 논블로킹-비동기 조합을 활용하는게 유리함
대부분 2번째(논블로킹-동기)·3번째(블로킹-비동기)를 굳이 쓸 필요가 없음

논블로킹-동기

호출은 즉시 반환되지만, 결과를 얻으려면 내가 계속 확인(polling)해야 함

 

블로킹-비동기

작업은 비동기로 실행되지만, 호출자가 get() 같은 메서드로 기다리는 순간 결국 블로킹됨.

 

논블로킹-비동기

요청 즉시 반환 + 결과는 콜백/Promise/이벤트 처리

 

 

추가 활용

서버 아키텍처

• 논블로킹-비동기: 이벤트 루프 기반 서버 (예: Node.js, Netty, Spring WebFlux). 동시성 처리에 강함. I/O가 많은 환경(채팅, 게임 서버, API Gateway 등)에 적합.
• 혼합 전략: DB 접근은 블로킹-동기, 네트워크 I/O는 논블로킹-비동기로 운영해 안정성과 성능을 동시에 확보.

네트워크 통신

• REST API: 주로 블로킹-동기 구조. 직관적이지만 대기 시간이 길어질 수 있음.
• WebSocket + 논블로킹-비동기: 실시간 알림/채팅/IoT 센서 데이터 수집 등에 활용.
• gRPC: 동기/비동기 방식 모두 지원. 대규모 마이크로서비스 간 통신에 맞춤.

UI/UX

• 블로킹-동기: 버튼 클릭 시 앱이 멈춰 있는 듯한 경험 → 사용자 경험 악화.
• 논블로킹-비동기: 버튼 클릭 시 스피너(로딩 UI) 띄우고, 응답이 오면 화면 업데이트. 대부분의 모바일/웹 앱에서 이 패턴 사용.

데이터 처리

• 배치 작업: 블로킹-동기 방식이 적합. (순차적, 보장된 실행 필요)
• 스트리밍 처리 (Kafka, Spark Streaming): 논블로킹-비동기. 데이터가 계속 들어오므로 이벤트 기반으로 처리.

 

정리

• 작고 단순한 프로그램: 블로킹-동기
• 고성능/대규모 서버: 논블로킹-비동기
• 특수 상황(거의 없다): 블로킹-비동기나 논블로킹-동기