Synchronous(동기), Asynchronous(비동기) 단어의 의미부터 파악하여 제대로 이해하기. + Blocking I/O, Non-blocking I/O

📍개요

개발책을 읽다 소단원 제목이 "비동기"로 되어 있는 책을 봤습니다. 그러다 문득 이런 생각이 들었습니다.

 

동기? Synchronous? 이런 방식이 왜 동기라고 부르는 거지? 왜 Synchronous라는 용어를 사용한 거지?

 

 

생각을 곱씹다보니 약간의 인지부조화를 느꼈습니다. 그동안 이해하고 있던 개념이 맞는지 의심이 들기 시작했고, 제가 이해한 개념과 "동기"라는 개념이 연관성이 있나 생각해보게 되었습니다. 

 

 

우리는 동기/비동기를 너무 자연스럽게 사용합니다. 웹 개발에선 익숙하게 “동기”, “비동기”, “Blocking I/O”, “Non-blocking I/O”라는 단어를 정말 자주 사용하게 됩니다. 저 역시 오랫동안 이 개념들을 사용해왔고, 충분히 이해하고 있다고 생각했습니다. 동기면 순차적인 동작, 비동기면 병렬 동작처럼 반사적으로 막역하게 떠올리곤 했습니다. 

 

 

느낌적인 느낌으로 이런 모델, 방식을 동기라고 하는 거겠지 하고 대충 넘기기엔 너무 찜찜해서 제대로 알아보게 되었습니다.  제대로 알아보면서 동기 시스템은 왜 한국어로 "동기" 영어로 "Synchronous" 라고 부르고 그와 반대인 개념은 "비동기",  "Asynchronous"로 불리게 됐는지까지 알아 보았습니다. 그리고 동기, 비동기와 함께 자주 언급되는 Blocking I/O, Non-blocking I/O 에 대해서도 공부를 했습니다. 제가 만든 그림과 함께 내용을 공유해 드리도록 하겠습니다.

 

먼저 제가 그동안 알고 있던 개념에 대해 부끄럽지만, 한번 말씀드려 보겠습니다. 동기방식과 Blocking I/O을 사람들이 많이 혼용하고 혼동하는 개념으로서, 저는 헷갈리지 않도록 다음과 같이 이해하고 있었습니다.

 

동기

• "순차적으로 일어나는 것"

 

Blocking I/O

• "호출을 한 뒤 결과를 기다리는 것(대기)"

 

그전까지 동기에 대한 개념은 절대 "대기"라는 개념이 들어가면 안된다고 생각했고, 동기에 대한 개념을 설명할 때 "대기"라는 설명이 포함되어 있으면 Blocking I/O에 대한 개념과 혼용하여 잘못 설명한 거라고 생각했습니다.

하지만 학습해보니 제가 잘못생각하고 있는 것이었고, 대기가 포함된 설명은 그다지 틀린 설명이 아니었다는 걸 깨달았습니다. 😓

 

 

 

🖼️이해를 도울 그림

아래 그림을 이용해서 이번 글에 적절한 예시를 들어보겠습니다.

먼저, 당신은 카페를 창업했고  AI 서빙 로봇을 한 대 고용했습니다.

 

이 카페에서 해야 할 주요 작업은 다음 세 가지입니다.

• 손님 주문 응대 (파란 작업)
• 미니 오븐에서 빵 데우기 (노란 작업)
• 커피 머신에서 커피 내리기 (보라 작업)

그리고 현재 카페에는 두 명의 손님이 있습니다.

• 손님 이순신
• 손님 윤봉길

 

손님으로는 지금 2명 이순신과 윤봉길이 있고, 당신의 로봇은 2가지 프로그래밍 모델 형식으로 작업을 할 수 있습니다. 작업을 스레드에 입각해서 보면 바로 "동기 + Blocking  방식"과 "비동기 + Non-blocking  방식"입니다.

 

 

이 그림을 가지고 단어적 이해와 함께 설명해보겠습니다.

 

 

 

📖논문이나 학술자료에서 서술하는 Synchronous 와 Asynchronous

먼저 Synchronous(동기)라는 개념을 제대로 이해하기 위해서, 서양 논문이나 학습자료들에서 나온 개념들을 찾아봤습니다. 프로그래밍이라는 기술은 서양에서 처음시작해, 정의와 개념을 확립했기 때문입니다.

 

 

통신에서의 Synchronous / Asynchronous

📖Towards a Harmonization of UML-Sequence Diagrams and MSC (1999)

Synchronous communication means that the involved parties have to meet and perform the communication together.
In synchronous method calls, the calling object is suspended until the called method completes and returns its result.

Asynchronous communication means that sending and consumption are decoupled; the caller is not suspended and may perform other work while the operation executes.

 

동기식 통신이란 관련 당사자들이 만나 함께 통신을 수행해야 함을 의미합니다.
동기화 메서드 호출에서는 호출된 메서드가 완료되어 결과를 반환할 때까지 호출 개체가 일시 중단됩니다.

비동기 통신은 전송과 소비가 분리되어 있음을 의미합니다. 호출자는 작업이 실행되는 동안에도 중단되지 않고 다른 작업을 수행할 수 있습니다.

 

• 동기 통신은 호출자 → 호출된 쪽 → 완료/리턴까지 기다리고 있고,
• 비동기 = 호출자 → 즉시 반환, 그 사이 실행은 분리된다고 설명하고 있습니다.

 

 

분산시스템에서의 Synchronous / Asynchronous

📖 Unifying Partial Synchrony (2024, arXiv)

Synchronous communication assumes that messages get delivered within a known bounded time frame and parties’ clocks are synchronized.
Asynchronous communication makes no timing assumptions, only that messages will eventually be delivered

 

동기 통신은 메시지가 알려진 제한된 시간 내에 전달되고 통신 당사자들의 시계가 동기화되어 있다고 가정합니다.
비동기 통신은 시간 관련 가정을 하지 않고, 단지 메시지가 결국 전달될 것이라는 사실만 가정합니다.

 

• 동기 통신 시스템 전체에 공통 시계(common clock) 존재, 시간적 bound 가 있고,
• 비동기 통신 그런 timing 보장 없음, 오직 eventual delivery 만 보장한다고 합니다.

 

 

프로그래밍에서의 Synchronous / Asynchronous

📖https://www.sciencedirect.com/topics/computer-science/synchronous-and-asynchronous-communication

Synchronous
“An execution model in which the caller waits for an operation to complete and return its result — actions happen in a coordinated, time-bounded way.”

Asynchronous
“An execution model in which send/execute and receive are decoupled — the caller is not suspended and other work can proceed before the result arrives.”

 

동기

호출자가 작업이 완료되어 결과를 반환할 때까지 기다리는 실행 모델 — 전체적인 작업은 하나의 시간적 구조 안에서 함께 움직이는 모델이다.

 

비동기

전송/실행(send/execute)과 수신(receive)이 분리되어(decoupled) 있는 실행 모델 — 호출자는 중단되지 않으며, 결과가 도착하기 전에 다른 작업을 계속 수행할 수 있다.”

 

• 동기 실행 모델은 호출자가 작업이 끝날 때까지 제어를 반환받지 못하며, 작업과 호출자의 흐름이 하나의 시간적 구조 안에서 함께 움직이는 모델
• 비동기 실행 모델은 작업의 시작과 완료 시점이 분리되어 있으며, 호출자는 작업 완료를 기다리지 않고 자신의 실행 흐름을 계속 진행할 수 있는 구조

 

 

각 학술적 설명을 보면 시간에 대한 개념들이 많이 나오고, 동기는 대기한다, 비동기는 중단하지 않고 바로 반환하여 호출자가 바로 다른 작업을 한다라는 이야기를 볼 수 있습니다. 결국 동기를 설명할때 기다림(대기)에 대한 설명이 들어간 건 틀린 설명이 아니라 올바른 설명이었던 거죠. 그럼 왜 동기의 개념에서 시간, 대기, 순차적  이런 표현들이 사용될까요? 이번엔 어원과 단어의 의미를 분해하여 파악해 봤습니다.

 

 

 

🔠Synchronous의 어원

Synchronous 는 다들 아시다시피 다음 단어들로 이루어진 단어입니다.

syn (together, 같이) + chronos (time, 시간)

 

우리가 흔히 쓰는 synchronous, synchronize, synthesis, symmetry 같은 단어들에는 공통적으로 syn- 또는 sym-이라는 접두사가 들어갑니다. 이 syn-은 단순히 “같다”는 뜻이 아니라, 고대 그리스어에서 온 매우 오래된 개념입니다.

syn-은 고대 그리스어 σύν (sýn) 에서 따왔다고 합니다.
의미는 다음과 같습니다.

“with”, “together”, “in union”, “jointly”

 

즉, 단순한 동일성(equality)이 아니라, “함께 결합되어 있음”, “공동으로 움직임”, “연결되어 있음”에 가까운 의미입니다.

여기서 중요한 건, syn-은 정적인 “같음”이 아니라 동적인 결합 상태를 나타낸다는 점입니다.

 

Synchronous 의 구조를 다시 보면 Synchronous는 syn(함께)와 chronos(시간)에서 온 단어입니다. 말 그대로 “시간을 함께 맞춘다”는 의미입니다. 한국어로 번역된 “동기(同期)” 역시 같을 동(同), 때 기(期)입니다. 같은 시기, 같은 타이밍이라는 뜻입니다. 그렇다면 무엇과 무엇이 같은 시간을 공유한다는 걸까요?

synchronous 는 원래 물리학/전자공학/통신공학에서 쓰던 말입니다. synchronous motor (동기 모터), synchronous signal (동기 신호) 등이 있습니다. 의미적으로는 다음과 같습니다.

 

두 개 이상의 시스템이 같은 시간 기준에 맞춰 동작한다.

 

이 용어가 프로그래밍이란 학문이 만들어지면서 자연스럽게 사용되기 시작했습니다.

 

즉, “시간을 함께 공유하는 상태” 여기서 중요한 건 단순히 “같은 시간”이 아니라, 서로 분리된 두 흐름이 하나의 시간 구조 안에서 결합되어 움직인다는 의미입니다.

프로그래밍에서 synchronous는 "호출자의 시간, 작업의 완료 시간" 이 둘이 분리되지 않고 같은 시간 축 위에 묶여 있는 상태를 의미하게 된 것입니다.

 

 

 

🖥️I/O 에서 Synchronous 와 Asynchronous 

프로그래밍에서 이 용어가 본격적으로 등장한 곳은 I/O (입출력) 시스템입니다. 초창기 컴퓨터는 CPU 연산은 매우 빠랐지만 디스크/네트워크 I/O는 매우 느렸습니다.

Synchronous I/O 에선 CPU가 I/O 요청 후 완료될 때까지 멈춰 있었습니다. 이런 경우는 CPU와 I/O가 “시간을 맞춰” 움직이는 거죠. 

1. CPU → I/O → CPU resumes

 

이러한 한계때문에 다음과 같이 생각하게 됐습니다.

"CPU가 I/O 끝날 때까지 기다려야 하는가?"

 

반대로 Asynchronous I/O은 CPU가 I/O 요청 후 바로 다른 일 수행을 수행했습니다. 그리고 I/O가 완료되면 인터럽트로 알렸습니다.

1. CPU → I/O 시작
2. CPU 다른 일 수행
3. I/O 완료 → 인터럽트

 

 

 

동기 호출에서는 호출자의 실행 흐름과 작업의 완료 시점이 하나의 시간 흐름 안에 묶입니다. 예를 들어 어떤 함수를 호출했을 때, 그 함수가 끝나기 전에는 다음 줄의 코드로 넘어갈 수 없습니다. 여기서 묶여 있는 것은 단순히 “작업과 다음 작업”이 아니라, 호출자의 제어 흐름과 작업의 완료 시점입니다. 즉, 제어 흐름이 작업의 완료에 종속되는 구조가 됩니다. 이것이 동기 방식의 본질입니다.

동기 방식에서는 호출자의 실행 흐름이 작업의 완료 시점에 종속되기 때문에 하나의 시간 흐름으로 결합됩니다. 그 결과 이전 작업이 완료되어야 다음 코드로 진행할 수 있으므로 기다림이 발생하고, 전체 작업은 자연스럽게 순차적인 구조를 갖게 됩니다.

이를 앞서 소개한 카페 예시로 살펴보겠습니다.

이 카페에서 로봇이 수행해야 하는 메인 작업은 “손님 응대”입니다. 손님 응대는 주문을 접수하고, 손님이 주문한 빵과 커피를 준비한 뒤 서빙하는 일련의 흐름으로 이루어져 있습니다.

 

그림을 보면 로봇은 손님의 주문을 접수한 뒤 다음 작업인 빵 데우기를 실행합니다. 하지만 이 로봇은 동기 방식으로 동작하는 로봇입니다. 오븐에 빵을 넣고 버튼을 누르면, 로봇은 그 자리에서 빵이 다 구워질 때까지 기다립니다. 빵이 완성된 뒤에야 다음 작업인 커피 내리기를 시작합니다. 그리고 이번에도 커피 머신 앞에서 커피가 내려질 때까지 기다립니다. 커피가 완성되면 그때서야 빵과 커피를 들고 서빙을 합니다.

오븐에 버튼을 누르는 것과 커피 머신에 버튼을 누르는 행위를 하나의 호출(call)이라고 생각해보겠습니다. 동기 방식의 로봇은 호출을 수행한 뒤 그 작업이 완료될 때까지 기다리고 나서야 다음 작업으로 이동합니다. 즉, 호출자의 실행 흐름과 작업의 완료 시점이 하나의 시간 축 위에 결합되어 있습니다.

그래서 작업의 흐름은 다음과 같은 순서를 갖게 됩니다.

1 (작업 호출) → 2 (작업 완료) → 3 (다음 작업 진행)

 

이 구조에서는 작업이 완료될 때까지 기다린 시간이 모두 포함되기 때문에, 하나의 요청을 처리하는 전체 시간에는 대기 시간이 그대로 포함됩니다.

---

반대로 비동기 방식에서는 호출자의 실행 흐름이 작업의 완료 시점과 시간적으로 분리됩니다. 호출자는 작업 완료를 기다리지 않고 즉시 다음 코드로 진행하며, 작업의 완료는 나중에 콜백, Future, 이벤트 등의 형태로 통지됩니다. 이로 인해 실행 흐름과 작업의 완료 시점은 동일한 시간 구조에 묶이지 않게 됩니다.

같은 카페 예시를 비동기 방식으로 다시 살펴보겠습니다.

 

로봇이 손님 이순신의 주문을 접수하고 빵을 오븐에 넣습니다. 하지만 이번에는 오븐 앞에서 기다리지 않습니다. 단순히 시작 버튼만 누르고 바로 다음 작업을 진행합니다. 이어서 커피 머신에도 커피를 내리도록 요청하고, 이번에도 커피가 내려질 때까지 기다리지 않습니다. 커피 머신 역시 시작 버튼만 눌러두고 로봇은 즉시 다음 작업으로 이동합니다.

그 다음 로봇은 다른 손님인 윤봉길의 주문 응대를 시작합니다.

잠시 후 오븐에서 빵이 완성되면 “띵동” 하는 알림이 울립니다. 로봇은 그 알림을 확인하고 빵을 가져옵니다. 이어서 커피 머신에서도 커피가 완성되었다는 알림이 울립니다. 로봇은 완성된 커피와 빵을 들고 손님에게 서빙을 합니다.

여기에서도 오븐과 커피 머신의 버튼을 누르는 행위를 하나의 호출이라고 보면, 비동기 방식에서는 호출 이후 완료를 기다리지 않고 바로 다음 작업을 진행합니다. 즉, 호출자의 실행 흐름과 작업의 완료 시점이 같은 시간 축 위에 묶여 있지 않습니다.

비동기 구조에서는 작업의 흐름이 다음과 같이 나타납니다.

1 (작업 호출) → 3 (다음 작업 진행) → 2 (작업 완료 이벤트)

작업을 다른 장비(오븐, 커피 머신)에 위임해 두었기 때문에 기다리는 동안 로봇은 다른 작업을 수행할 수 있습니다.

이러한 차이 때문에 비동기 방식은 요청 처리량(throughput)이 더 높아질 수 있습니다.

 

동기 방식에서는 작업을 시작하면 완료될 때까지 기다려야 하기 때문에, 그동안 실행 주체(여기서는 로봇 혹은 스레드)는 아무 일도 하지 못한 채 대기하게 됩니다. 특히 네트워크나 디스크 I/O처럼 시간이 오래 걸리는 작업이 포함되면 이러한 대기 시간은 더욱 커집니다.

반면 비동기 방식에서는 작업을 시작한 뒤 완료를 기다리지 않고 다른 작업을 계속 수행할 수 있습니다. 즉, 하나의 작업이 외부 장치에서 처리되는 동안에도 실행 주체는 다른 요청을 처리할 수 있습니다.

결과적으로 동일한 시간 동안 더 많은 작업을 처리할 수 있게 되고, 시스템 전체의 요청 처리량이 높아질 가능성이 커집니다. 이것이 현대의 많은 서버 프레임워크들이 비동기 모델과 Non-blocking I/O를 적극적으로 활용하는 이유입니다.

 

 

🚫Blocking I/O 와 Non-blocking I/O

논문과 학술자료 그리고 어원의 의미를 통해 동기/비동기는 "시간적 결합"의 문제라는 걸 알았습니다. 그리고 그 결합의 대상이 호출자의 실행 흐름과 작업 완료라는 것도 알았습니다. 이 전반적인 제어 흐름이 방식차이가 동기 방식이냐 비동기방식이냐를 구분짓게 합니다.

 

반면 Blocking/Non-blocking은 전혀 다른 차원의 개념입니다. 이는 제어 흐름의 문제가 아니라, 호출을 수행한 스레드가 실제로 대기 상태로 전환되는가의 문제입니다. 즉, 운영체제 스케줄링 관점에서 해당 스레드가 멈추는지 여부를 기준으로 구분합니다.

두 개념은 판단 기준 자체가 다릅니다. 하나는 시간적 관계(제어 흐름), 다른 하나는 실행 주체(스레드) 의 상태입니다. 따라서 서로 비교 대상이 아니라, 서로 다른 축에 놓인 개념으로 이해해야 합니다.

 

I/O는 말 그대로 Input/Output, 즉 입출력입니다. Blocking I/O와 Non-blocking I/O의 차이는 입출력 작업을 수행하는 동안 호출 스레드가 커널에 의해 대기 상태로 전환되는가, 아니면 즉시 반환되어 계속 실행 가능한 상태로 남는가에 있습니다.

Blocking I/O에서는 데이터가 준비되지 않았다면 호출 스레드는 커널에 의해 대기(sleep) 상태로 들어가고, I/O가 완료될 때까지 스케줄링 대상에서 제외됩니다.
Non-blocking I/O에서는 데이터가 준비되지 않았더라도 호출은 즉시 반환되며, 스레드는 대기 상태로 전환되지 않습니다.

 

 

 

1️⃣ Blocking I/O

호출로 인해 현재 스레드가 커널에 의해 대기(sleep) 상태에 들어가는 것
Java에서 가장 전형적인 예는 InputStream.read() 입니다.

InputStream in = socket.getInputStream();
byte[] buffer = new byte[1024];

int bytesRead = in.read(buffer); // 데이터가 올 때까지 대기

 

이 코드를 살펴보면, 네트워크 데이터가 아직 도착하지 않았다면 read()는 반환하지 않습니다.
현재 스레드는 커널에 의해 대기 상태로 들어갑니다.

즉, 작업 완료 전까지 스레드가 멈춰 있는 상태(sleep)이고 이것이 Blocking I/O 입니다.
이건 제어 흐름 문제가 아니라, 호출 스레드가 실제로 멈추는가의 문제입니다.

 

 

카페 예시에서 파란색 작업(손님 응대)을 하나의 스레드에서 처리한다고 가정해보겠습니다.

이 스레드는 손님의 주문을 받고, 빵을 데우기 위해 오븐을 사용합니다. 여기서 오븐에 빵을 넣고 버튼을 누르는 행위를 하나의 I/O 호출이라고 생각할 수 있습니다.

Blocking I/O 방식에서는 오븐을 작동시키는 작업을 호출한 뒤, 그 작업이 완료될 때까지 호출한 스레드가 대기 상태에 들어갑니다.

즉, 파란색 작업을 수행하던 스레드가 노란색 작업(빵 데우기)을 호출하면 다음과 같은 흐름이 됩니다.

 

1. 파란 스레드가 오븐 작업을 호출
2. 오븐 작업이 완료될 때까지 스레드는 대기 상태(sleep)에 들어감
3. 빵이 완성된 뒤에야 스레드가 다시 실행을 재개

이때 중요한 점은 스레드 자체가 멈춘다는 것입니다. 오븐이 빵을 데우는 동안 로봇은 다른 일을 할 수 없고, 해당 스레드는 단순히 기다리고만 있습니다. 같은 방식으로 커피 머신 작업을 호출하면, 커피가 내려질 때까지 스레드는 다시 대기 상태에 들어갑니다. I/O 작업이 완료될 때까지 호출 스레드가 커널에 의해 대기 상태로 들어가는 방식입니다.
이것이 바로 Blocking I/O입니다.

 

 

 

2️⃣Non-blocking I/O

Java에서는 NIO(Non-blocking I/O)를 통해 이를 구현할 수 있습니다.

SocketChannel channel = SocketChannel.open();
channel.configureBlocking(false);

ByteBuffer buffer = ByteBuffer.allocate(1024);
int bytesRead = channel.read(buffer);

if (bytesRead == 0) {
    System.out.println("데이터가 아직 준비되지 않음");
}

 

이 코드를 살펴보면, 데이터가 준비되지 않은 경우 read()는 즉시 0을 반환합니다. 그리고 현재 스레드는 멈추지 않습니다.

즉, 데이터가 준비되지 않았더라도, 호출 스레드는 대기 상태로 들어가지 않습니다.
이것이 Non-blocking I/O 입니다.

 

 

 

그림에서 보면 앞선 Blocking I/O 과 다르게 Non-blocking I/O 방식에서는 상황이 조금 다르게 동작합니다.
파란색 작업을 수행하던 스레드가 노란색 작업(빵 데우기)을 호출하더라도, 이번에는 오븐 작업이 완료될 때까지 기다리지 않습니다.

오븐을 작동시키는 호출은 즉시 반환되고, 스레드는 대기 상태로 들어가지 않습니다.

즉 흐름은 다음과 같이 됩니다.

1. 파란 스레드가 오븐 작업을 호출
2. 호출은 즉시 반환됨
3. 스레드는 다음 작업을 계속 수행

그리고 호출한 작업인 빵이 완성되면 나중에 완료 알림(event)을 통해 작업 완료가 전달됩니다.
커피 머신도 동일합니다. 커피를 내리는 작업을 시작한 뒤 스레드는 기다리지 않고 바로 다음 작업을 진행할 수 있습니다.

이 방식에서는 스레드가 대기 상태로 들어가지 않기 때문에, 같은 시간 동안 더 많은 작업을 처리할 수 있습니다.

 

 

앞서 살펴본 것처럼 Blocking I/O에서는 I/O 작업이 진행되는 동안 스레드는 아무 일도 하지 못하고 기다려야 합니다.
특히 네트워크나 디스크처럼 I/O 시간이 긴 작업이 많아지면, 많은 스레드가 단순히 대기 상태로 묶이게 됩니다. 반면 Non-blocking I/O에서는 작업을 시작한 뒤 완료를 기다리지 않고 다른 작업을 처리할 수 있습니다.
그래서 동일한 수의 스레드로도 더 많은 요청을 처리할 수 있게 됩니다.

이러한 이유 때문에 현대의 많은 서버 프레임워크(Node.js, Netty, WebFlux 등)는 비동기 + Non-blocking I/O 모델을 적극적으로 사용하고 있습니다.

 

 

 

 

 

🔢4가지 조합으로 보는 Synchronous(동기)/Asynchronous(비동기), Blocking I/O / Non-blocking I/O

결국 동기이면서 블로킹일 수도 있고, 비동기이면서 블로킹일 수도 있습니다. 예를 들어 비동기 API를 호출해놓고 future.wait()로 기다린다면, 작업은 비동기적으로 실행되지만 현재 스레드는 멈추게 됩니다. 이것은 비동기 + 블로킹의 조합입니다. 반대로 논블로킹 소켓을 폴링 방식으로 사용한다면, 결과를 직접 받아 처리하는 동기 구조이면서도 스레드는 멈추지 않을 수 있습니다. 각 조합에 대해 살펴보았습니다.

 

 

1️⃣ 동기 + Blocking

HttpURLConnection conn = (HttpURLConnection) url.openConnection();
InputStream in = conn.getInputStream(); // 응답 올 때까지 대기

• getInputStream 함수의 결과 반환까지 기다림 (동기)
• 현재 스레드 멈춤 (Blocking)

전통적인 함수 호출 방식입니다. getInputStream() 함수의 응답이 올 때까지 호출한 스레드는 멈추게 됩니다. 응답을 리턴 받고 나서야 다음 로직을 실행하게 됩니다.

 

 

2️⃣ 동기 + Non-blocking

동기 + Non-blocking I/O 는 존재는 하지만 많이 사용하지 않는 방식입니다. 그래서 구현 방식도 약간 특이합니다.
호출 후 “즉시 반환 + 직접 결과 확인” 구조입니다.

SocketChannel channel = SocketChannel.open();
channel.configureBlocking(false);

ByteBuffer buffer = ByteBuffer.allocate(1024);

while (true) { // I/O 작업 호출 후 스레드 SLEEP 안함.
    int bytesRead = channel.read(buffer); //read()가 데이터 없으면 즉시 0 반환

    if (bytesRead > 0) {
        break; // 데이터 직접 받음 → 동기
    }

    doOtherWork();
}

process(buffer);

• 동기 = 결과를 호출자가 직접 받는다 (control flow가 반환 시점에 결합)
• Non-blocking I/O = 데이터가 준비되지 않았으면 즉시 반환 (스레드 안 멈춤)

즉, "결과는 내가 직접 받아야 하지만 스레드는 멈추면 안 된다." 이게 동기 + Non-blocking 조합입니다.

 

매번 결과를 확인하는 것이 폴링과 유사한 구조입니다. 그래서 “조금만 기다리면 곧 올 것” 같은 짧은 폴링 (저지연 요구) 작업때 사용됩니다. 저도 실무에서 WebForm 으로 사용가 아이디와 비밀번호를 입력하여 로그인한 후 메인페이지에 간다고 했을 때 비슷한 방식으로 로그인 완료를 체크한 적이 있습니다.

 

 

 

3️⃣ 비동기 + Blocking

비동기 + Blocking 조합은 처음 보면 약간 모순처럼 느껴질 수 있습니다.
“비동기인데 왜 Blocking이 발생하지?”라는 생각이 들기 때문입니다.

하지만 두 개념은 서로 다른 기준에서 정의됩니다.

• 비동기는 제어 흐름의 문제입니다.
• Blocking은 스레드 상태의 문제입니다.

따라서 비동기 작업을 시작했더라도, 나중에 호출자가 결과를 기다리면 스레드는 다시 Blocking 상태가 될 수 있습니다.
대표적인 예가 Future 또는 Task를 사용한 뒤 결과를 기다리는 경우입니다.
예를 들어 다음과 같은 코드가 있다고 가정해보겠습니다.

CompletableFuture<String> future =
    CompletableFuture.supplyAsync(() -> {
        try {
            Thread.sleep(2000);
        } catch (InterruptedException e) {}
        return "Hello";
    });

String result = future.get(); // 결과 기다림 (Blocking)

System.out.println(result);

 

이 코드를 보면 작업 자체는 CompletableFuture를 통해 비동기적으로 실행됩니다.
즉, 실제 작업은 별도의 스레드에서 수행됩니다. 하지만 future.get()을 호출하는 순간 상황이 달라집니다.
get()은 결과가 준비될 때까지 현재 스레드를 대기 상태로 만듭니다.

그래서
작업 실행 → 비동기
결과 대기 → Blocking
이라는 구조가 됩니다.

이 경우 시스템의 동작은 다음과 같은 형태가 됩니다.

비동기 작업 시작
        ↓
현재 스레드 future.get() 호출
        ↓
결과 올 때까지 스레드 대기
        ↓
결과 반환

 

따라서 이 패턴은 비동기 + Blocking의 대표적인 사례라고 볼 수 있습니다.
실제로 많은 시스템에서 비동기 API를 사용하더라도, 최종적으로는 결과를 기다리기 위해 Blocking 호출을 사용하기도 합니다.

 

 

 

4️⃣ 비동기 + Non-blocking

비동기 + Non-blocking은 현대 서버 시스템에서 가장 많이 사용되는 구조입니다.
이 구조에서는 작업 시작과 완료가 분리되어 있으며 (비동기), 호출 스레드가 중단되지도 않습니다. (Non-blocking)

즉, 작업을 시작한 뒤 호출자는 즉시 반환되고, 작업이 완료되면 콜백, 이벤트, Future completion 등을 통해 결과가 전달됩니다.

예를 들어 Java의 CompletableFuture를 다음과 같이 사용할 수 있습니다.

CompletableFuture.supplyAsync(() -> {
    try {
        Thread.sleep(2000);
    } catch (InterruptedException e) {}
    return "Hello";
}).thenAccept(result -> {
    System.out.println(result);
});

System.out.println("다른 작업 수행");

 

실행 흐름은 다음과 같습니다.

비동기 작업 시작
        ↓
즉시 반환
        ↓
다른 작업 수행
        ↓
작업 완료
        ↓
콜백 실행

 

supplyAsync() 함수를 호출한 스레드는 Blocking 상태로 들어가지 않고, 작업 완료는 이벤트 형태로 전달됩니다.
이 구조가 바로 비동기 + Non-blocking입니다.

 

 

🎈마무리

동기, 비동기 어원을 찾아보고 동작방식을 학습하면서 한가지 철학적 통찰을 얻게 되었습니다. 동기와 비동기는 결국 우리가 시간을 다루는 방식에 대한 선택이라는 점입니다.

동기 모델은 시간을 단순하게 만듭니다. “끝나면 다음” 인간의 사고 구조와 가장 잘 맞는 흐름입니다. 대신 우리는 기다림이라는 비용을 감수합니다.

비동기 모델은 시간을 분해합니다. “시작과 완료를 분리하고, 완료를 사건(알림, 이벤트)으로 받는다.” 대신 우리는 복잡성을 감수해야 합니다. 콜백 지옥, 상태 관리, 예외 전파의 어려움은 모두 이 분해된 시간의 부작용입니다.


“내 제어 흐름은 작업 완료에 묶일 것인가, 아니면 분리할 것인가?”
“그 선택이 현재 실행 자원(스레드)을 멈추게 할 것인가, 아닐 것인가?”

동기/비동기는 시간적 관계의 선택이고,
Blocking/Non-blocking은 자원 점유 방식의 선택입니다.

 

이제 저는 동기와 비동기를 설명할 때 “순차적이다”라고 말하지 않고 "동기는 제어 흐름과 완료 시점이 같은 시간 위에 놓인 구조이고, 비동기는 그 둘을 서로 다른 시간 축에 놓는 구조다." 라고 말할 수 있게 됐씁니다.

이 관점으로 보면, 이 개념들은 더 이상 헷갈리지 않습니다. 그리고 무엇보다, 왜 이런 이름이 붙었는지도 비로소 자연스럽게 이해됐습니다.