퀴즈: 레이어와 캐시

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

1. `RUN apt-get update` 를 별도 줄로 두면 왜 위험합니까?

   1. 이미지 레이어가 하나 더 늘어나 최종 용량이 커지기 때문에
   2. 패키지 인덱스 갱신이 오래 걸려서
   3. apt 실행에 루트 권한이 필요해서
   4. RUN 의 캐시 키는 명령 문자열 그 자체라 몇 달이 지나도 캐시에 적중해 낡은 인덱스를 계속 쓰게 되어서

2. CI 에서만 빌드가 8분이 걸리고 로컬은 4초입니다. 가장 그럴듯한 원인은?

   1. CI 머신이 느려서
   2. CI 러너는 매 실행마다 새 머신이라 빌더 로컬 캐시가 없어서
   3. 네트워크가 느려서
   4. Dockerfile 이 달라서

3. 파일을 열어 저장만 했는데(내용 동일) BuildKit 에서 캐시가 깨졌습니다. 무엇을 의심해야 합니까?

   1. 파일 수정 시각(mtime)이 바뀌었다
   2. BuildKit 빌더 자체의 버그다
   3. 파일 권한 비트가 바뀌었다
   4. 내용 해시가 실제로 바뀌었거나, 그 위 레이어에서 이미 캐시가 깨졌다

4. `RUN dd ... /big` 다음 줄에 `RUN rm /big` 을 두면 이미지 크기는?

   1. 20MB 줄어든다
   2. 빌드할 때만 줄어든다
   3. 레이어를 합치면 줄어든다
   4. 그대로거나 오히려 조금 늘어난다

5. "그러니 모든 RUN 을 하나로 합쳐라"는 조언의 문제점은?

   1. 여러 RUN 을 하나로 합치는 것은 문법상 불가능하다
   2. 캐시 재사용이 파괴된다 — 합쳐야 하는 것은 생성과 정리가 짝을 이루는 명령뿐이다
   3. 한 레이어가 커져 레이어 크기 제한에 걸린다
   4. 명령이 길어져 빌드가 실패한다

6. `.dockerignore` 의 주된 효과는?

   1. 빌드 컨텍스트 전송량을 줄인다(그리고 `COPY . .` 을 쓸 때만 크기에도 영향을 준다)
   2. 어떤 경우에나 최종 이미지의 크기를 직접 줄여 준다
   3. 이미지의 레이어 개수를 줄여 준다
   4. 빌드 캐시를 아예 비활성화한다