2026년 Dockerfile 베스트 프랙티스 — 2020년 베스트가 *틀린* 5 지점
2020년의 Dockerfile 베스트 프랙티스 중 *5가지* 가 2026년에 *반대로* 작동한다. 무엇이 바뀌었나.
2020년에 권장되던 Dockerfile 패턴 중 5가지 가 2026년에 반대로 작동 한다. BuildKit, distroless, multi-arch, supply chain 보안 도구의 등장이 이유다.
변화 1 — RUN 명령 합치기 는 더 이상 답이 아니다
2020 권장:
RUN apt-get update && apt-get install -y curl jq \
&& rm -rf /var/lib/apt/lists/*이유 — 각 RUN 이 layer 를 만든다. 합치면 layer 수 ↓.
2026 — BuildKit 이 cache mount 를 지원. layer 수 자체가 덜 중요. 더 중요한 건 cache 효율.
RUN --mount=type=cache,target=/var/cache/apt \
--mount=type=cache,target=/var/lib/apt/lists \
apt-get update && apt-get install -y curl jqcache mount 를 쓰면 각 RUN 이 자체 cache 를 가지고, 합치는 것보다 재빌드가 빠름.
변화 2 — alpine 기반은 더 이상 default 가 아니다
2020 — FROM alpine 이 가벼운 default.
2026 — alpine 의 musl libc 가 Python / Node / glibc-기반 라이브러리 와 호환성 문제. 디버깅 시간이 Alpine 의 작은 크기 절감을 항상 능가.
권장 — distroless (Google) 또는 chainguard 의 minimal images. glibc 호환 + Alpine 보다 더 작음.
# 2020
FROM alpine:3.18
# 2026
FROM gcr.io/distroless/nodejs22-debian12
# 또는
FROM cgr.dev/chainguard/node변화 3 — latest 태그 절대 금지 는 부분적으로 틀림
2020 — FROM node:latest 는 절대 X. 고정 버전 사용.
2026 — latest 는 여전히 X 지만, 특정 digest 고정 이 표준이 됨.
# 2020 권장 (충분치 않음)
FROM node:20-alpine
# 2026 권장 (digest 고정)
FROM node:22.11.0-slim@sha256:af16...이유 — 같은 태그 (node:22-slim) 도 시간에 따라 다른 이미지 를 가리킬 수 있음. 공급망 보안 (SLSA, supply-chain attacks) 에 대비하려면 digest 까지 고정.
변화 4 — root 가 아닌 user 는 충분치 않음
2020 — USER appuser 로 non-root 전환.
2026 — non-root 만으로 부족. 이 5가지 모두 권장:
USER appuser
WORKDIR /app
COPY --chown=appuser:appuser . /app
# 2026 추가
COPY --chmod=0444 ./config.json /app/config.json # read-only files
LABEL org.opencontainers.image.base.digest=sha256:...
LABEL org.opencontainers.image.source=https://github.com/...추가 LABEL 들은 공급망 추적 용. docker scout / trivy / grype 같은 도구가 이 라벨을 읽어 원본 추적 함.
변화 5 — single-stage 는 더 이상 정당화 X
2020 — multi-stage build 는 복잡할 때만. 간단한 앱은 single-stage.
2026 — 모든 프로덕션 이미지는 multi-stage. 빌드 도구 (gcc, npm, etc.) 가 런타임 이미지에 들어가면 공격 표면 ↑. multi-stage 의 복잡도 보다 공격 표면 감소 가 더 큼.
# Build stage
FROM node:22-slim AS build
WORKDIR /app
COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm npm ci
COPY . .
RUN npm run build
# Runtime stage
FROM gcr.io/distroless/nodejs22-debian12
WORKDIR /app
COPY --from=build /app/dist /app/dist
COPY --from=build /app/node_modules /app/node_modules
CMD ["dist/index.js"]런타임 이미지에 npm 자체 가 없음. 공격 표면 이 수십 개의 빌드 도구만큼 줄어듦.
5가지 변화의 공통점
위 5가지의 공통점 — 우선순위가 변했다. 2020 에는 이미지 크기 / 단순성 이 우선. 2026 에는 공급망 보안 / 빌드 캐시 효율 / 호환성 이 우선.
Dockerfile 은 6년 마다 베스트가 바뀐다. 2020년 "best" 가 2026년 "worst" 일 수 있음.
2020년 가이드로 쓴 Dockerfile, 지금 고쳐야 하나
2020년 가이드로 작성한 Dockerfile 이 위 5가지 변화 중 3가지 이상 을 반영하지 않았다면, 다음 보안 검토에서 권고 가 나올 가능성이 크다. Dockerfile 을 그때 작성한 뒤로 손대지 않았다면, 보안 검토가 시키기 전에 먼저 고치는 쪽이 싸다.
비슷한 글
기획자가 코드를 배포하면, 장애는 누가 책임질까
AI로 제품 담당자가 직접 코드를 만들고 여러 에이전트가 동시에 작업하는 조직에서, 운영에 나가는 변경을 누가 무엇으로 확인해야 하는지. NIST SSDF, SLSA provenance, Google SRE 포스트모템 문화를 근거로 작성자와 분리된 검증·승인·복구의 역할 설계를 정리했다.
백재민
에이전트 시대의 Eclipse 플러그인 — 작업 컨텍스트는 20년 전에도 문제였다
Mylyn 이 2000년대에 풀려던 문제와 지금 에이전트 컨텍스트 문제는 같습니다. 달라진 건 그 컨텍스트를 읽는 쪽에 사람만 있는 게 아니라는 점입니다.
김영상
에이전트 시대의 VS Code 확장 — 개발자는 에디터에서 무엇을 보는가
코드 작성 비용이 무너진 뒤 개발자의 시간은 판단과 승인으로 옮겨갔습니다. 그 일들이 왜 에디터 밖에 있으면 안 되는지, VS Code 확장을 만들며 내린 선택들.
이승백