블로킹 I/O (Blocking I/O)

핵심 인사이트 (3줄 요약)

본질: 블로킹 I/O(Blocking I/O)는 애플리케이션(스레드)이 디스크나 네트워크 같은 외부 기기에 데이터를 요구(read/write)했을 때, 데이터가 도착할 때까지 OS가 해당 스레드의 실행을 강제로 기절(Sleep/Wait 상태)시켜 무한정 대기하게 만드는 가장 직관적이고 고전적인 동기화 모델이다.

가치: 개발자가 코드를 위에서 아래로 순서대로만 짜도 물 흐르듯 실행(Sequential)되게 만들어 프로그래밍 난이도를 극단적으로 낮춰주며(개발 생산성 최고), 대기 시간 동안 스레드를 수면 상태로 던져 CPU 점유율(Busy Wait)을 0%로 아껴 다른 앱에 양보하게 해준다.

융합(한계): 하지만 대규모 네트워크(웹 서버) 환경에서는 수만 개의 블로킹 스레드를 띄웠다가 메모리(스택)와 컨텍스트 스위칭 오버헤드가 터져 시스템이 붕괴하는 'C10K 문제'의 원흉이 되므로, 현대 백엔드에서는 넌블로킹(Non-blocking)과 I/O 멀티플렉싱(epoll)에 밀려 레거시로 취급받는 양날의 검이다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: "데이터가 올 때까지 나는 아무것도 안 하고 여기서 얼음(Block) 상태로 기다리겠다." C언어의 scanf()나 파이썬의 input(), 파일 read() 함수를 호출했을 때의 기본값이다. 1초가 걸리든 10년이 걸리든, 하드웨어가 짐을 다 싸서 램에 올려주고 커널이 내 스레드의 어깨를 툭 쳐서 깨워줄(Wake-up) 때까지 다음 줄의 코드는 절대 실행되지 않고 시간이 정지한다.
필요성: 내가 텍스트 파일을 읽어와서 그 파일에 적힌 숫자 2개를 더하는 코드를 짠다고 치자. 1번 줄: 파일 읽기, 2번 줄: 숫자 더하기. 만약 블로킹이 없다면? CPU는 미친 듯이 빨라서 파일이 디스크에서 도착하기도 전에 2번 줄(숫자 더하기)을 실행해 버릴 것이다. 당연히 데이터가 안 왔으니 빈 깡통을 더하다가 에러가 팍 터진다(Segmentation Fault). "내 코드의 논리적 순서를 지키려면, 제발 앞의 재료가 도착할 때까지 내 시간을 완벽하게 멈춰줘!" 이 당연하고도 간절한 프로그래머의 욕구가 블로킹 I/O를 OS의 절대 디폴트(Default) 값으로 만들었다.
💡 비유: 블로킹 I/O는 중국집에서 음식이 나올 때까지 카운터에 서서 멍때리는 손님과 같다. 손님(스레드)이 짬뽕(데이터)을 주문(read)했다. 주방장(디스크)이 요리하는 데 15분이 걸린다. 블로킹 손님은 자리에 가서 유튜브를 보거나 폰 게임을 하지 않는다. 카운터 앞에 목석처럼 꼿꼿이 굳어 서서(Blocked) 짬뽕이 내 손에 쥐여질 때까지 아무 짓도 안 하고 영원히 기다린다. 짬뽕이 내 손에 딱 들어와야만 비로소 몸이 녹아서 자리로 걸어가 짬뽕을 먹는(다음 줄 코드 실행) 가장 융통성 없고 단순한 식사법이다.
등장 배경 및 OS 스케줄러의 타협:
1. 폴링(Polling)의 낭비: 옛날엔 짬뽕 나올 때까지 CPU가 1초마다 "나왔냐?" 묻느라 CPU 100%가 타버렸다(Busy Wait).
2. 수면(Sleep) 매커니즘 도입: "어차피 기다릴 거면 아예 마취총을 쏴서 스레드를 기절시키고(CPU 양보), I/O가 끝나면 인터럽트로 깨우자!"는 인터럽트 구동 아키텍처가 확립됨.
3. 개발 편의성의 승리: 코드가 눈에 보이는 대로 직관적으로 흘러가기 때문에, 50년간 전 세계 모든 프로그래밍 언어의 I/O 기본 뼈대로 군림함.

┌──────────────────────────────────────────────────────────────────────────┐
│        블로킹 I/O(Blocking I/O) 호출 시 OS 스케줄러의 생사여탈권 시각화  │
├──────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│ [ 유저 스레드의 코드 실행 ]                                              │
│ 1. `print("읽기 시작!");`  (스레드 달리는 중 🏃‍♂️)                      │
│                                                                          │
│ 2. `data = read(file_fd);` ◀ (I/O 블로킹 시스템 콜 작렬!)                │
│     │                                                                    │
│     ▼ (이 순간 OS 스케줄러가 개입하여 멱살을 잡음)                       │
│ ┌──────────────────────────────────────────────────┐                     │
│ │ OS: "디스크 읽어올 테니까 넌 대기실(Wait Queue)로 꺼져!"       │       │
│ │ -> 유저 스레드를 'Running' -> 💤 'Sleep (Blocked)' 강제 변환! │        │
│ │ -> CPU 코어는 재빨리 딴 앱(유튜브)을 가져와서 돌림 (효율 극강)    │    │
│ └──────────────────────────────────────────────────┘                     │
│     │                                                                    │
│     ▼ (--- 8 밀리초의 영겁의 시간이 흐름 ---)                            │
│ [ 디스크 하드웨어 ] 💥 인터럽트 발생! "야 데이터 다 긁어왔어!"           │
│                                                                          │
│ 3. OS: "대기실에 자고 있던 유저 스레드 깨워라!"                          │
│    -> 스레드 💤 'Sleep' -> 🏃‍♂️ 'Ready/Running' 으로 부활!              │
│                                                                          │
│ 4. `print(data);` (잠에서 깬 스레드가 다음 줄 실행 재개!)                │
└──────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] "Block 당했다"는 것은 프로그램이 렉이 걸려 에러가 난 게 아니다. OS 커널이 이 녀석의 CPU 점유 권한을 강제로 박탈하고 대기 큐(Wait Queue)에 쑤셔 박아, CPU가 허공에 삽질(Polling)하는 것을 완벽하게 막아준 고도의 자원 절약 스케줄링의 혜택을 받은 것이다.

📢 섹션 요약 비유: 수술실 의사(CPU)가 수술 중(코드 실행) 메시가 필요하다(I/O)고 외칩니다. 간호사가 창고에서 메스를 가져오는 5분 동안 의사는 허공에 칼질(폴링)을 하지 않습니다. 의사는 그 자리에서 쿨쿨 잠을 잡니다(Blocked). 간호사가 메스를 손에 딱 쥐여주는 순간(인터럽트), 의사는 눈을 번쩍 뜨고 0.1초의 오차도 없이 완벽하게 다음 수술(다음 코드)을 이어갑니다. 의사의 체력(CPU)을 완벽히 아끼는 기술입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

대기 큐 (Wait Queue)의 무덤

OS 커널 안에는 디스크 드라이버나 소켓마다 '대기 큐(Wait Queue)'라는 이름의 닭장이 하나씩 딸려 있다.

스레드가 블로킹 I/O를 치면, OS는 스레드의 상태를 캡처(PCB 백업)해서 이 닭장 안에 구겨 넣는다.
여러 스레드가 동시에 같은 파일에 블로킹을 걸면, 닭장 안에 10개, 100개의 스레드가 나란히 잠들어 있게 된다.
하드웨어가 1개의 I/O를 끝내고 인터럽트(IRQ)를 터뜨리면, OS는 닭장을 열고 "1번 스레드 일어나! 짐 가져가!" (Wake-up) 라며 순서대로 하나씩 멱살을 잡아 깨워 다시 CPU Ready 큐로 올려보낸다.

Uninterruptible Sleep (D 상태)의 공포

리눅스 top 명령어를 쳤을 때, 프로세스 상태(State) 컬럼에 뜬금없이 D 라는 철자가 뜰 때가 있다.

일반적인 Sleep(S 상태, Interruptible)은 자고 있다가도 유저가 Ctrl+C를 누르면 "앗 깜짝이야!" 하고 깨어나서 바로 죽어(종료) 준다.
하지만 디스크 I/O 블로킹에 걸려 하드웨어 장비와 깊게 엮인 상태는 **D (Uninterruptible Sleep)**라는 특수 기절 상태로 들어간다.
이 상태에 빠지면 유저가 kill -9 (우주 최강의 살인 명령어)를 백 번 날려도 절대 쳐다보지도 않고 무시한다!
이유: 디스크가 데이터를 램으로 한창 쏟아붓고 있는데, 여기서 스레드가 Ctrl+C 맞고 돌연사해버리면 램 메모리가 붕괴되어 커널 패닉이 올 수 있기 때문이다.
결과: 만약 꽂혀있는 외장 하드디스크가 물리적으로 고장 나버렸다면? 하드디스크가 영원히 인터럽트를 안 보내준다. 이 프로세스는 영원히 깨어나지 못하는 좀비(D 상태)가 되어 시스템에 박제되고, 이 좀비를 치우려면 서버 전원 코드를 뽑는(Reboot) 수밖에 없는 최악의 사태가 터진다.
📢 섹션 요약 비유: 일반 수면(S 상태)은 꿀잠 자다가도 뺨을 때리면 화들짝 깨서 일어납니다. 하지만 디스크 I/O 락에 걸린 수면(D 상태)은 전신 마취 수술 상태입니다. 수술(I/O)이 다 끝나서 마취가 풀리기 전까지는, 옆에서 건물을 폭파시키고 귀에 대고 총을 쏴도 절대 일어날 수 없는 끔찍하고 무거운 잠에 빠진 겁니다.

Ⅲ. 융합 비교 및 다각도 분석

비교 1: Blocking vs Non-blocking (현대 서버 아키텍처의 전쟁)

네트워크(소켓) 통신 시대가 열리며 블로킹의 위상이 180도 뒤집혔다.

비교 항목	블로킹 I/O (Blocking)	넌블로킹 I/O (Non-blocking)
데이터 없을 때 행동	올 때까지 스레드가 수면 상태(Sleep)로 정지됨	멈추지 않고 "에러(EAGAIN) 뱉고 즉시 딴일 하러 도망감"
코딩 스타일	`1->2->3` 물 흐르듯 직관적이고 읽기 매우 편함	루프(`while`)를 돌거나 `epoll` 이벤트 처리를 해야 해서 지저분함
스레드 요구량	유저 1만 명 접속 시 스레드 1만 개 띄워야 함	1만 명 접속해도 스레드 1~4개면 혼자 뺑이치며 커버 가능
최악의 단점	멀티스레드 Context Switch 렉으로 서버 폭파 (C10K 문제)	코드를 1번 잘못 짜면 CPU가 무한루프 도느라 서버 타버림

아파치(Apache)의 몰락과 톰캣(Tomcat)의 한계

2000년대 전 세계 1위 웹서버 아파치(Apache MPM Prefork)는 이 '블로킹 I/O'를 뼈대로 썼다.
유저가 접속해서 사진 파일을 다운받는 1분 동안, 아파치 스레드 하나가 통째로 '블로킹' 상태로 잡혀서 아무 일도 못 했다.
동시 접속자가 1만 명(C10K)이 들어왔다. 아파치는 스레드 1만 개를 띄웠다!
스레드 1만 개가 각자 2MB씩 스택 메모리를 쳐먹어 램 20GB가 터져나갔고(OOM), OS가 1만 명을 0.1초 단위로 번갈아 깨워주는 '문맥 교환(Context Switch)' 렉 때문에 CPU 가동률이 100%를 찍고 서버가 질식사했다.
이 블로킹의 끔찍한 확장성(Scalability) 한계 때문에 아파치는 왕좌를 내려놓고, 논블로킹(epoll) 기반의 닌자 같은 웹서버 Nginx에게 전 세계를 지배당했다.

┌──────────┬────────────┬────────────┬──────────────────────────────────┐
│ I/O 아키텍처 │ 동작 방식    │ 동시접속 1만명 렉│ 대표적인 프레임워크  │
├──────────┼────────────┼────────────┼──────────────────────────────────┤
│ Blocking │ 1인당 1스레드 배정│ ☠️ 서버 즉사  │ 과거 Apache, Spring(구)│
│ Non-Block│ 소수 스레드가 뜀 │ 🚀 거의 0초 컷 │ Nginx, Node.js, Netty  │
└──────────┴────────────┴────────────┴──────────────────────────────────┘

[매트릭스 해설] "그럼 무조건 넌블로킹이 좋은 거 아닌가?" 절대 아니다. 넌블로킹으로 짜인 코드는 인간이 읽기 더럽게 어렵다. "데이터 오면 이거 해주고, 실패하면 저기로 가고..." 온갖 콜백(Callback) 지옥이 펼쳐진다. 그래서 현대에는 코드는 겉보기에 꿀 뚝뚝 떨어지는 순차적 '블로킹'처럼 예쁘게(async/await, 코루틴) 짜면서, 뒤에선 OS가 알아서 '넌블로킹'으로 찢어 돌려주는 궁극의 하이브리드 문법(Golang, Kotlin)이 세상을 지배하게 된 것이다.

📢 섹션 요약 비유: 블로킹 방식은 은행원이 손님 1명의 대출 서류가 본사에서 승인(I/O 대기) 날 때까지 1시간 동안 창구에 둘이 뻘쭘하게 마주 앉아 노가리 까는 방식입니다. 뒷사람들은 빡치죠. 넌블로킹은 은행원이 "서류 심사 들어갔으니 번호표 들고 대기실 가 계세요!" 하고 1초 만에 쫓아낸(에러 뱉음) 뒤 뒷사람 업무를 쭉쭉 쳐내는 효율의 극치입니다. 당연히 후자가 일 잘하는 은행입니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오: DB 쿼리와 Connection Pool의 블로킹 늪

개발자의 순진함: 자바(Spring) 개발자가 MySQL에 SELECT 쿼리를 날렸다.
블로킹의 덫: 이 쿼리는 무조건 블로킹 I/O로 작동한다. DB에서 결과가 날아올 때까지(네트워크 지연 + DB 디스크 읽기 지연 5초) 톰캣(Tomcat) 워커 스레드 하나가 완전히 정지(Blocked)한다.
Connection Pool 고갈:
- 이벤트로 접속자가 1,000명이 몰렸다.
- DB가 버벅대서 응답을 안 주니, 톰캣 스레드 1,000개가 전부 DB 응답을 기다리며 '블로킹 좀비' 상태로 굳어버렸다.
- 서버에 여유 스레드(Thread Pool)가 0개가 되어, 새로운 손님이 메인 페이지(DB 안 쓰는 단순 페이지)에 접속하려 해도 스레드를 못 받아서 웹사이트 접속 자체가 튕겨버린다 (Cascading Failure).
실무적 철퇴 (Timeout):
- 그래서 시니어 백엔드 개발자는 외부 API를 호출하거나 DB 쿼리를 날릴 때 절대로 무한정 블로킹을 타게 두지 않는다.
- 무조건 Socket Timeout = 3초 라는 목줄을 묶어둔다. 3초가 지나면 억지로 블로킹을 강제 해제(Exception 터뜨림)시켜서, 기절해 있던 내 스레드를 깨워 다른 손님을 받게 살려내는 것이 대규모 서버 설계의 1순위 생존술이다.

안티패턴: Node.js에서의 동기 파일 읽기 (`fs.readFileSync`)

자바스크립트(Node.js)는 넌블로킹 이벤트 루프의 화신이다. 스레드가 딱 1개다! 그런데 초보자가 서버 설정 파일을 읽겠답시고 fs.readFileSync('config.json')라는 블로킹 함수를 호출했다. 무슨 일이 벌어질까? 디스크에서 그 파일 10KB를 긁어오는 10밀리초 동안, Node.js의 단 1개밖에 없는 메인 심장 스레드가 기절(Blocked)해버린다. 그 10밀리초 동안 전 세계에서 들어오는 수천 명의 API 요청이 모조리 허공으로 날아가고 서버가 멈춘다. Node.js 생태계에서 'Sync(블로킹)' 함수를 쓰는 것은 내 목에 스스로 밧줄을 매는 자살 행위로 엄격히 금지된다.

📢 섹션 요약 비유: 블로킹 쿼리는 피자집 알바생(스레드)이 오토바이를 타고 배달(쿼리)을 갔는데, 손님이 지갑을 5분 동안 찾느라 문을 안 열어주면 멍청하게 5분 내내 문 앞(DB 앞)에 서서 기다리는 꼴입니다. 알바생이 10명뿐인데 10명 다 문 앞에서 멍때리고 묶여버리면(커넥션 고갈), 가게에 전화 오는 주문을 받을 사람이 없어 식당 전체가 망해버립니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

정량/정성 기대효과

구분	내용
개발 생산성(Productivity) 최상	복잡한 콜백/상태 머신 없이 위에서 아래로 떨어지는 직관적 순차 코딩을 허락하여 전 세계 소프트웨어의 99%를 지배
CPU Busy Wait 원천 봉쇄	I/O 지연 동안 while 루프를 돌며 전력을 갉아먹는 폴링(Polling)을 멸종시키고, 스레드를 쿨쿨 재움으로써 CPU 가동률 최적화 달성
멀티스레딩 아키텍처의 촉매	블로킹의 약점(스레드 멈춤)을 극복하기 위해, 하나의 멈춤을 수십 개의 다른 스레드로 덮어버리는 자바/C++ 멀티스레드 모델을 강제 진화시킴

결론 및 미래 전망

블로킹 I/O (Blocking I/O)는 컴퓨터가 한 번에 한 가지 일밖에 못 하던 단일 프로세스 시절, 가장 정직하고 논리적으로 흠결이 없던 순백의 프로그래밍 모델이다. OS의 기절(Sleep) 스케줄링 덕분에 CPU를 아끼는 기적을 낳았지만, 역설적으로 그 멈춤(Blocking) 때문에 인터넷 시대의 수백만 동시 접속 트래픽(C10K) 앞에서는 서버를 질식시키는 가장 무서운 암살자로 돌변했다. 오늘날 고성능 백엔드 생태계(Nginx, Redis, Netty)는 이 블로킹의 늪에서 벗어나기 위해 넌블로킹(Non-blocking)과 I/O 멀티플렉싱(epoll)이라는 험난한 사막으로 피난을 떠났다. 하지만 인간의 뇌는 태생적으로 콜백(비동기)의 지저분함보다 순차적 흐름(블로킹)을 편안하게 느낀다. 결국 미래에는 Go 언어의 Goroutine이나 Java의 Virtual Thread처럼, "코드의 겉모습은 달콤한 블로킹인데, OS 밑바닥에서는 하드코어한 넌블로킹으로 자동 치환해 주는" 극한의 기만적 컴파일러/런타임 마술이 세상을 완전히 통일할 것이다.

📢 섹션 요약 비유: 옛날엔 편지를 보내고 답장이 올 때까지 우체통 앞에서 밤새 쪼그려 자며 기다렸습니다(블로킹). 답답해서 요즘 사람들은 편지를 넣고 바로 딴 일을 하러 뛰어다니죠(넌블로킹). 하지만 뛰어다니는 게 너무 피곤해진 현대인들은, 결국 겉보기엔 편안하게 소파에 앉아 자는 척(Virtual Thread)을 하면서 뇌파로는 다른 일을 미친 듯이 처리하는 궁극의 초능력 시대로 진화하고 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

넌블로킹 I/O (Non-blocking I/O) | 데이터가 없으면 스레드를 재우는(Blocking) 대신 즉시 "없어!"라고 에러를 뱉고 도망쳐서 서버의 자유를 얻어낸 반항아
컨텍스트 스위치 (Context Switch) | 블로킹으로 뻗은 스레드의 뇌 상태를 저장하고 다른 스레드를 깨우느라 OS가 치르는 엄청나게 비싸고 느린 행정 비용
C10K Problem | 1만 명의 유저가 블로킹 렉을 걸었을 때 스레드 1만 개가 뜨면서 서버가 박살 나는 2000년대 웹 아키텍처 최대의 재앙
epoll / kqueue (멀티플렉싱) | 수만 개의 블로킹 구멍을 1개의 스레드가 쳐다보면서, "알람 울린 구멍만 딱딱 찔러줄게!" 하고 교통정리 해주는 현대 서버의 영웅
D State (Uninterruptible Sleep) | 블로킹 I/O 중에서도 가장 끔찍한 하드디스크 락에 걸려, 킬(Kill) 명령조차 무시하고 시스템에 좀비로 남는 최악의 수면 상태

👶 어린이를 위한 3줄 비유 설명

블로킹 I/O가 뭔가요? 엄마한테 "물 줘!"라고 심부름을 시켰을 때, 엄마가 물을 가져와서 내 손에 쥐여줄 때까지 나는 숨도 안 쉬고 그대로 얼음! 하고 굳어버리는 거예요.
왜 얼음 상태로 굳어있나요? 내가 물을 마신 다음에 밥을 먹어야 하는데, 물이 아직 안 왔는데 밥부터 먹어버리면(순서가 꼬이면) 배탈이 나고 프로그램이 엉망진창 에러가 나거든요.
불편한 점은 없나요? 얼음 하고 기다리는 동안 내 손발이 다 묶여서, 숙제도 못 하고 TV도 못 보고 소중한 10분(CPU 시간)을 아무것도 못 한 채 허공에 날려버리는 게 제일 짜증 난답니다.