퀴즈: 쪼개기와 옮기기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. 큰 반복문을 조각으로 나누기만 하고 조각 사이에 아무것도 하지 않았습니다. 이벤트 루프 입장에서 달라지는 것은?

   1. 아무것도 달라지지 않는다 — 한 번에 돈 것과 같다
   2. 조각 수만큼 지연이 나뉘어 줄어든다
   3. 조각마다 가비지 컬렉션이 돌아 지연이 늘어난다
   4. 조각 경계에서 자동으로 차례가 넘어간다

2. 4천만 번 도는 계산을 40조각으로 나누고 사이마다 setImmediate 로 양보했습니다. 총 시간은 어떻게 될까요?

   1. 조각 수에 비례해 크게 늘어난다
   2. 양보 비용만큼 조금 늘어난다
   3. 루프가 병렬로 처리해 줄어든다
   4. 정확히 같다 — 계산량이 같기 때문이다

3. 응답 지연을 50ms 안으로 맞추고 싶습니다. 조각 크기를 정하는 근거로 맞는 것은?

   1. 전체 계산 시간을 CPU 코어 수로 나눈다
   2. 조각 수를 동시 요청 수와 같게 맞춘다
   3. 이벤트 루프의 한 바퀴 시간에 맞춘다
   4. 조각 하나를 도는 시간이 50ms 를 넘지 않게 잡는다

4. 워커 스레드로 옮길 수 **없는** 일에 가장 가까운 것은?

   1. 요청 본문의 큰 배열을 정렬해 상위 100개를 고르는 일
   2. 비밀번호 해시를 여러 번 반복해 계산하는 일
   3. 지금 열려 있는 소켓에 직접 응답을 쓰는 일
   4. 이미지 바이트를 받아 크기를 줄여 돌려주는 일

5. 실습 이미지에서 워커 하나를 띄워 빈 일감의 답을 받기까지 22ms 에서 31ms 가 걸렸습니다. 이 숫자가 설계에 주는 뜻은?

   1. 워커는 되도록 쓰지 않는 편이 낫다
   2. 기동 비용보다 가벼운 일은 옮기면 손해이고, 자주 쓰면 미리 띄워 둔다
   3. 워커 수를 CPU 코어 수와 같게 맞춰야 한다
   4. 워커에 보내는 데이터 크기를 줄여야 한다

6. 함수를 `async` 로 선언하면 무거운 반복문이 루프를 막지 않게 될까요?

   1. 된다 — async 함수는 별도 큐에서 실행된다
   2. 된다 — 반환값이 프로미스라 호출자가 기다린다
   3. 안 된다 — await 를 만나기 전까지는 동기로 끝까지 돈다
   4. 안 된다 — async 함수는 스레드 풀에서 돌기 때문이다