동기와 비동기, 블로킹과 논블로킹

두 축이 묻는 것이 다릅니다. 블로킹과 논블로킹은 제어권을 바로 돌려주는지이고, 동기와 비동기는 완료 통보를 누가 챙기는지입니다.

가장 자주 빠지는 것이 논블로킹이면서 동기인 조합입니다. 제어권을 바로 돌려받아도 완료 여부를 내가 계속 확인해야 하면 동기입니다.

흔한 실수: 두 축을 하나로 묶어 블로킹은 동기, 논블로킹은 비동기라고 답하는 것. 그러면 네 조합 중 두 개를 설명할 수 없습니다. 제어권과 완료 통보는 별개의 질문입니다.

느린 외부 호출 하나가 스레드를 붙잡아, CPU 가 한가한데도 새 요청을 못 받는 상태를 만듭니다.

요청마다 스레드를 붙이는 서버, 스레드 풀 200개
외부 결제 API 응답이 평소 50ms 에서 3초로 늘어났다

초당 100건 요청이면 동시에 300개 스레드가 필요해진다
풀 200개가 모두 대기 상태로 묶인다
CPU 사용률은 5퍼센트인데 새 요청은 큐에서 밀린다

병목이 계산 능력이 아니라 기다리는 자리의 수입니다. 스레드를 늘리는 것은 임시 방편이고, 컨텍스트 스위칭과 메모리 비용이 함께 늘어납니다.

논블로킹으로 바꾸면 기다리는 동안 그 스레드가 다른 요청을 처리하므로 적은 스레드로 많은 연결을 감당합니다.

흔한 실수: 스레드 풀을 키우면 해결된다고 답하는 것. 스레드마다 스택 메모리를 쓰고 스위칭 비용이 붙어, 어느 지점부터는 늘릴수록 느려집니다.

아닙니다. 작업 하나만 놓고 보면 걸리는 시간은 같습니다.

이득이 나오는 자리는 기다림이 있는 작업입니다. 네트워크 호출, 디스크 읽기, 데이터베이스 질의처럼 CPU 가 놀고 있는 구간이 있어야 그 시간에 다른 일을 시킬 수 있습니다.

CPU 작업은 오히려 나빠질 수 있습니다. 이벤트 루프를 쓰는 구조에서 무거운 계산을 그대로 올리면 루프가 막혀 전체 요청이 함께 느려집니다.

흔한 실수: 비동기를 성능 개선 기법으로만 이해하는 것. 코드 흐름이 나뉘어 디버깅과 예외 처리가 어려워지는 비용이 있습니다. 기다림이 병목인지 먼저 확인하고 고르는 것이 순서입니다.

여러 연결을 한 자리에서 지켜보다가 준비된 것만 처리합니다. 연결마다 스레드를 두지 않습니다.

연결 10,000개를 감시 대상으로 등록한다
커널에게 "이 중에 읽을 준비가 된 것을 알려달라"고 맡긴다
준비된 것만 목록으로 돌아온다
그 연결들만 처리하고 다시 기다린다

스레드는 CPU 코어 수 정도만 있으면 되고, 대기는 커널이 대신합니다. 연결 수가 늘어도 스레드가 늘지 않는 것이 이 구조의 핵심입니다.

흔한 실수: 이 구조를 쓰면 무조건 빠르다고 답하는 것. 요청 하나의 처리 시간은 줄지 않고, 늘어나는 것은 동시에 감당하는 연결 수입니다. 그리고 처리 함수 안에서 블로킹 호출을 하나라도 하면 그 이득이 그대로 사라집니다.