메인 스레드를 '막아도' 되는 순간

Smashing Magazine의 Victor Ayomipo가 프런트엔드의 오랜 계율인 '메인 스레드를 절대 막지 마라'에 조심스럽게 예외를 달았습니다. 그는 스크린샷 크롬 확장(Fastary)을 만들며, 권장 아키텍처대로 작업을 백그라운드로 넘겼는데도 2~3초의 지연이 사라지지 않는 문제를 만났습니다. 원인은 '연산'이 아니라 '데이터 이동'이었습니다.

"데이터를 워커로 옮기는 것이, 그냥 메인 스레드가 처리하도록 두는 것보다 느릴 때가 있다."Victor Ayomipo, Smashing Magazine

왜 중요한가

스레드 사이로 데이터를 넘기면 구조화 복제(Structured Clone)라는 동기 작업이 데이터 크기에 비례해 커집니다. 1080p 화면의 Base64 이미지는 1MB를 넘고 레티나에서는 두 배가 되죠. Transferable Objects는 32MB 기준 300ms를 7ms로 줄일 만큼 빠르지만 모든 타입에 쓸 수 없고 원본 접근권을 잃습니다. 결국 진짜 원칙은 '메인 스레드를 막지 마라'가 아니라 '너무 오래 막지 마라'입니다.

실무 적용

작업을 두 종류로 나눠 판단하세요. 이미지 압축·물리 시뮬레이션처럼 CPU를 오래 태우는 '연산 중심' 작업은 워커로 격리하는 게 맞습니다. 반면 이미지 크롭·배열 필터처럼 '데이터 중심' 작업은 옮기는 비용이 처리 비용을 넘어서므로 메인 스레드에 두는 편이 낫습니다. 감이 아니라 performance.mark()/performance.measure()로 실제 비용을 재고, 사용자가 직접 누른 액션이라면 약 1초 정도의 블로킹은 정당화될 수 있습니다.

교차 참고

• Smashing Magazine: The Fight For The Main Thread — 메인 스레드가 왜 성능의 병목이 되는지 기본 맥락을 함께 봅니다.
• MDN: Transferable objects — 복제 대신 소유권을 넘겨 전송 비용을 줄이는 방식의 원리를 보완합니다.

Wemeet의 관점

Wemeet은 성능 규칙을 '금기'가 아니라 '측정'으로 다룹니다. 모범 사례를 맹목적으로 따르다 오히려 느려지는 일은 흔합니다 — 좋은 엔지니어링은 규칙을 외우는 게 아니라, 이 작업이 '옮기기 비싼가, 처리하기 비싼가'를 그때그때 재는 데서 나옵니다.