"가볍다"를 추상어로 받아치는지, 아니면 스택 크기·컨텍스트 스위칭·스레드 점유 해제라는 세 축으로 풀어내는지를 가른다. 후속으로 블로킹 호출·CPU 바운드·Virtual Thread 비교를 던질 판단 기준이 된다.
스레드는 OS 자원이라 각자 수백 KBMB 단위 스택과 커널 구조체를 들고 있고, 전환할 때마다 커널 모드로 들어가 레지스터·메모리 매핑을 갈아 끼운다. 코루틴은 사용자 공간 객체라서 상태만 몇십수백 바이트로 저장하고 전환도 함수 호출 수준에서 끝난다. 결정적으로 suspend 지점에서 스레드를 반납하기 때문에 I/O 대기 중에도 그 스레드가 다른 작업을 돌릴 수 있다. 그래서 소수 스레드로 수만 단위 동시 작업을 받아내는 구조가 가능해진다.
스레드 풀 고갈로 장애를 한 번 본 경험이 있다면 "스레드를 점유하지 않는다"는 의미가 왜 결정적인지 자기 언어로 풀 수 있다
비동기 전환 작업에서 블로킹 라이브러리를 만나 처리량이 안 늘던 경험은 디스패처/블로킹 경계 이야기로 자연스럽게 이어진다
JMeter·k6로 동시 사용자 수를 올리며 메모리/CPU를 본 적 있다면 경량성이 처리량으로 어떻게 환산되는지 수치로 말할 수 있다
코루틴 도입 후에도 성능이 기대만큼 오르지 않아 디스패처 설정이나 블로킹 호출을 뒤진 경험이 있다면 suspend 메커니즘 이해가 디버깅에 직결된다는 근거로 쓸 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.