Wolfi는 컨테이너 전용으로 설계된 초경량 리눅스 "언디스트로(undistro)"이고, 이를 기반으로 만든 Chainguard Images는 CVE가 거의 잡히지 않는 최소 컨테이너 이미지 모음이다. distroless가 "런타임에 불필요한 것을 뺀 이미지"였다면, Wolfi 계열은 거기서 한 발 더 나가 패키지마다 SBOM을 기본 동봉하고 취약점을 공격적으로 빠르게 패치하는 데 초점을 둔다. 2026년 기준, 이미지 취약점 스캔 결과를 깨끗하게 유지하려는 팀이 가장 많이 옮겨 가는 목적지다.
보안 스캐너가 뱉는 CVE 수백 개짜리 리포트를 받아 본 적 있다면 안다. 대부분은 내 앱과 무관한 배포판 기본 패키지에서 나온다. 쓰지도 않는 bash, curl, 패키지 매니저에서. 이미지를 얇게 만들면 그 소음 자체가 사라진다.
왜 얇은 이미지가 곧 보안인가
공격 표면과 CVE 표면은 이미지에 든 소프트웨어 양에 비례한다. 명제는 단순하다. 없는 패키지는 취약할 수 없고, 없는 셸은 악용될 수 없다. 전통적인 ubuntu·debian 베이스는 수백 개 패키지를 깔고 시작한다. distroless와 Wolfi는 앱 실행에 필요한 최소한만 남긴다. 차이는 접근이다. distroless는 구글의 특정 이미지 세트이고, Wolfi는 apk 기반으로 내가 필요한 것만 조립할 수 있는 패키지 생태계다.
멀티스테이지 + 최소 베이스
정석은 빌드 스테이지와 런타임 스테이지를 나누는 것이다. 무거운 빌드 도구는 첫 스테이지에서만 쓰고, 최종 이미지에는 결과물만 얇은 베이스 위에 얹는다.
# 1) 빌드 스테이지 — 컴파일러·도구 다 있어도 됨
FROM golang:1.23 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/server
# 2) 런타임 스테이지 — 셸도 패키지 매니저도 없는 최소 베이스
FROM cgr.dev/chainguard/static:latest
COPY --from=build /app /app
USER nonroot
ENTRYPOINT ["/app"]static 이미지에는 셸이 없다. 그래서 docker exec ... sh로 들어갈 수가 없다. 처음엔 이게 불편하지만, 뒤집어 보면 침입자도 셸을 못 얻는다는 뜻이다. 동적 링크가 필요하면 static 대신 glibc가 든 얇은 베이스를 고른다.
| 베이스 | 셸/패키지매니저 | 성격 |
|---|---|---|
ubuntu | 있음 | 범용, CVE 표면 큼 |
alpine | 있음(musl) | 작지만 musl 호환 이슈 |
| distroless | 없음 | 런타임만, 고정 세트 |
| Wolfi/Chainguard | 대개 없음 | 최소+SBOM 동봉, 빠른 패치 |
옮길 때 데는 지점
- 디버깅이 어렵다. 셸이 없으니
kubectl exec로 들어가ps,cat을 못 한다. 대안은 임시 디버그 컨테이너(kubectl debug)를 같은 프로세스 네임스페이스에 붙이는 것. 운영 이미지는 얇게, 디버깅은 사이드로. - glibc vs musl. alpine의 musl에서 미묘한 호환 문제(특히 일부 네이티브 라이브러리, DNS 해석)를 겪었다면, Wolfi는 glibc 기반이라 그 함정이 없다. 이 점 하나로 alpine에서 넘어오는 팀도 있다.
- 비루트 실행이 기본. 이미지가
nonroot로 돌도록 만들어져 있어, 파일 권한이나 특정 포트(1024 미만) 바인딩에서 걸릴 수 있다. 대개는 옳은 방향이라 맞춰 가는 게 낫다.
스캔을 습관으로
얇은 이미지로 옮겼다고 끝이 아니다. 새 CVE는 매일 나온다. CI에 trivy image나 grype 같은 스캐너를 걸어 두고, 정기적으로 베이스를 최신으로 다시 당겨 빌드하는 리빌드 습관이 중요하다. Wolfi 계열의 진짜 가치는 "지금 CVE 0개"가 아니라, 새 CVE가 떴을 때 패치가 매우 빠르게 반영된다는 데 있다.
자주 묻는 질문
distroless를 이미 쓰는데 Wolfi로 굳이 옮겨야 하나요?
필수는 아닙니다. 다만 Wolfi는 apk 패키지 생태계로 필요한 구성을 유연하게 조립할 수 있고, 각 패키지에 SBOM이 동봉되며 패치 속도가 빠릅니다. glibc 기반이 필요하거나 취약점 대응 SLA가 중요한 팀에 매력적입니다.
셸이 없으면 운영 중 문제를 어떻게 디버깅하나요?
kubectl debug로 디버그 도구가 든 임시 컨테이너를 대상 파드에 붙이면, 운영 이미지는 얇게 유지하면서도 필요한 순간에만 조사 도구를 투입할 수 있습니다. 운영 이미지에 디버깅 도구를 상주시키지 않는 게 핵심입니다.
이미지가 얇으면 정말로 더 안전한가요?
공격 표면이 줄어드는 건 분명합니다. 셸·패키지 매니저·불필요한 라이브러리가 없으면 악용할 도구 자체가 없어집니다. 다만 앱 코드 자체의 취약점은 그대로이므로, 얇은 베이스는 "여러 방어 중 하나"로 이해해야 합니다.
CVE 0개라는 게 취약점이 없다는 보장인가요?
아닙니다. 스캐너가 아는 알려진(known) 취약점이 현재 검출되지 않는다는 의미일 뿐, 미공개 취약점이나 앱 로직 결함은 별개입니다. 그래서 정기 리빌드와 지속 스캔을 함께 운영해야 합니다.
댓글 0