Q5. 이벤트 루프 관점에서 requestAnimationFrame은 setTimeout이나 Promise와 실행 시점이 어떻게 다른가요? (어디 쯤에 줄을 서나요?)
1. 적재 위치의 차이
- Promise: Microtask Queue (가장 높은 우선순위)
- setTimeout: Task Queue (Macrotask Queue)
- rAF: Animation Frame List (별도의 대기열 관리)
2. 실행 시점의 차이 (VSync)
- Promise: 콜 스택이 비워지자마자 즉시 실행됩니다. 렌더링보다 먼저 실행되므로, 너무 많으면 렌더링을 막습니다.
- setTimeout: 큐에서 꺼내질 때 실행됩니다. 프레임 생성 주기와 상관없이 실행되므로 화면 갱신 시점과 어긋날 수 있습니다.
- rAF: 브라우저가 화면을 새로 그리기(Repaint) 바로 직전에 실행됨을 보장합니다.
3. 이벤트 루프 흐름도
- [Task 실행] ➡ [Microtask 모두 비우기] ➡ (렌더링 기회 도래 시) ➡ [ rAF 실행 ➡ Style/Layout/Paint ] ➡ [다음 Task 실행]
Q6. Iframe에서의 이벤트 루프 공유 여부는 어떻게 결정되나요?
공유 여부를 결정하는 기준은 출처(Origin)와 브라우저의 프로세스 격리 정책(Sit Isolation) 입니다.
Iframe이 부모창과 동일 출처(Same-Origin)라면 이벤트 루프를 공유하고, 교차 출처(Cross-Origin)라면 별도의 이벤트 루프로 분리 됩니다.
1. 동일 출처 (Same-Origin)인 경우
- 상태 : 공유함
- 이유 : 동일 출처인 경우 Iframe 내부에서 window.parent.document 등을 통해 부모의 DOM에 동기적으로 접근할 수 있어야 하기 때문입니다. 만약 스레드가 다르다면 DOM 접근 시 복잡한 락(Lock)이나 통신 비용이 발생하므로, 브라우저는 이들을 하나의 렌더 프로세스내에 동일한 메인 스레드에 묶어둡니다.
- 리스크 : Iframe 내부에서 무한루프가 돌면, 부모 창의 UI도 함께 멈춥니다. (Freezing)
2. 교차 출처 (Cross-Origin)인 경우
- 상태: 분리됨 (Separate Event Loop / Process)
- 이유: 보안(SOP, Same-Origin Policy) 및 최신 브라우저의 Site Isolation(사이트 격리) 정책 때문입니다. 서로 다른 사이트는 메모리 공간을 철저히 분리하여 보안 취약점(예: Spectre/Meltdown)을 방어하고, 한쪽이 뻗어도 다른 쪽에 영향을 주지 않도록 별도의 프로세스를 할당합니다.
- 장점: Iframe 안에서 무거운 연산을 해도 부모 창은 멀쩡하게 반응(Non-blocking)합니다. (완전히 남이라서 서로 영향이 없습니다. 단, 통신은 postMessage로만 가능)
+ Deep Dive
상황: Iframe 내부 스크립트에서 에러 발생 (throw new Error(...))
1. 동일 출처 (Same Origin)
- 부모의 window.onerror혹은 try-catch가 Iframe 내부(contentWindow)에 접근해서 에러를 포착할 수 있습니다.
- 단, iframe.contentWindow.onerror = ... 처럼 명시적으로 연결해줘야 확실합니다.
- 조금 더 정확하게는 main window의 Heap과 Call Stack을 공유하지는 않지만 (실행 컨텍스트는 분리됨), Task Queue소비하는 Event Loop는 공유합니다. => 동기화 문제 발생 가능.
2. 교차 출처 (Cross Origin)
- 보안 정책(SOP) 때문에, 부모 창은 자식 창의 구체적인 에러 내용을 알 수 없습니다.
- 콘솔에는 빨간 에러가 뜨지만, 부모의 window.onerror에는 'script error'라는 무의미한 텍스트만 넘어 옵니다. (정보 은닉)
- 줄번호도 파일명도 안알려줍니다.
- 별도 프로세스 -> 별도 스레드 -> 별도 이벤트 루프 => 완전한 비동기 병렬 실행.
Iframe의 경우 이를 해결하려면 postMessage를 통해서 전송해야 합니다.
+ [외부 스크립트에 대한 해결책]
1. script 로드시 <script src"..." crossorigin="anonymous"></script> 속성 추가
=> script 태그나 img src 이런 것들은 모두 Simple Request로 진행된다. Simple Request로 진행된다는 것은 실행은 가능하지만, 읽기는 안된다는 것이다. 여기에서 읽기 권한도 얻으려면 CORS요청을 해서 허용 승인을 받아야 된다. 그 속성이 crossorigin="anonymous"이고 이걸 추가하게 되면 브라우저는 CORS 요청을 하게 된다.
2. 서버(CDN) 응답 헤더에 Access-Control-Allow-Origin:* 추가.
=> 해당 헤더를 통해서 읽기 권한을 승인하면 Error를 읽을 수 있다.
*브라우저는 보안상 "다른 출처의 스크립트가 실행되는 건 막지 않겠지만, 그 스크립트 내부에서 무슨 일이 일어났는지(에러 내용 등)를 너(부모 페이지)에게 알려주진 않겠다"라는 원칙을 가지고 있습니다. 이것이 SOP(Same-Origin Policy)의 일환입니다.
'CS 질문' 카테고리의 다른 글
| [Deep Dive CS- Q10] React.useEffect vs React.useLayoutEffect (feat. EventLoop) (0) | 2025.12.15 |
|---|---|
| [Deep Dive CS- Q7, Q8, Q9] setTimeout, await/async, promise 에서의 에러 처리 (0) | 2025.12.15 |
| [Deep Dive CS- Q3,Q4] 실행결과 (0) | 2025.12.15 |
| [Deep Dive CS- Q2] - 실행결과 (0) | 2025.12.15 |
| [Deep Dive CS- Q1] Javascript Run-to-completion, Event Loop (0) | 2025.12.15 |