이벤트 루프와 비동기 제어
Promise/async의 문법보다 동작 순서, 취소, 경합 제어를 우선 정렬합니다.
학습 목표
이벤트 루프를 “무엇이 동시로 돈다”가 아니라 “무엇이 언제 반영되는가”로 이해합니다. 브라우저 렌더 흐름과의 연결까지 보면, 비동기 결과의 지연·뒤섞임을 예측할 수 있습니다.
이벤트 루프 핵심 관점
JavaScript는 단일 실행 흐름에서 이벤트 루프를 통해 작업을 처리합니다. 핵심은 동시 실행이 아니라 언제 처리되고 언제 반영되는지입니다.
브라우저 렌더 기준은 일반적으로 60fps를 가정합니다.
이는 1초를 60으로 나눈 약 16.67ms 간격으로 화면을 갱신한다는 뜻입니다.
프레임마다 사용자 입력 반응, 상태 반영, 그리고 그릴 준비가 제때 끝나지 않으면 체감은 즉시 떨어집니다.
아래는 처리 흐름의 핵심입니다.
이미지 출처: JavaScript Visualized: Promises & Async/Await
실행 순서 정렬
이미지의 동작은 다음처럼 정리됩니다.
- 현재 태스크가 끝나고 콜 스택이 비워집니다.
- 마이크로태스크 큐를 모두 비웁니다.
- 다음 매크로태스크로 진행합니다.
이 순서를 기준으로 봐야 화면 반영 시점의 불일치 원인을 정확히 잡을 수 있습니다.
비동기 제어의 실무 목적
비동기 제어의 목적은 속도보다 반영 시점의 안정성입니다.
Web API에 위임한 작업은 큐에 등록된 규칙에 따라 다시 들어옵니다.
현재 실행 중인 호출이 끝난 뒤(콜 스택 비움) 마이크로태스크가 먼저 정리되고,
이후 매크로태스크가 진행되며 다음 단계로 넘어갑니다.
개발자가 직접 다루는 대상은 콜 스택의 구조가 아니라 작업의 크기와 분할입니다.
즉, 하나의 동기 구간을 짧게 유지해 16.67ms 프레임 안에서 상태 반영을 마치거나 다음 프레임으로 넘길지를 설계해야 합니다.
이 흐름을 이해하면 어떤 비동기 결과가 언제 화면에 보일지 예측 가능한 판단이 가능합니다.
실무 적용 체크
- 동기 작업은 짧게, 긴 작업은 분할하거나 비동기로 밀어냅니다.
- 화면 이동/해제 경로에서는 늦은 응답 반영이 일어나지 않게 분기점을 둡니다.
- 재시도는 상한선을 두고, 실패·지연 시 사용자 피드백을 명확히 보여줍니다.
핵심 한 줄
이벤트 루프를 암기하는 목적은 성능 튜닝이 아니라,
사용자에게 보이는 최종 상태가 언제 어떻게 바뀌는지를 의도대로 제어하기 위함입니다.
이제 다음은 값 공유가 만드는 상태 버그로 이어지는 포인트를 정리합니다.