BuildKit vs Kaniko — 폐쇄망 빌드 관점에서의 결정 가이드

BuildKit 과 Kaniko 는 Docker daemon 없이 컨테이너 이미지를 빌드하는 도구다. 둘 다 Kubernetes 환경에서 안전한 빌드 가 가능하다고 광고한다. 인터넷에는 둘이 비슷하다 는 글이 많지만, 폐쇄망 / 규제 환경 에서 보면 두 도구가 매우 다른 답 을 준다.

이 글은 4 평가축에서 둘이 어떻게 다른지 다룬다.

평가축 1 — root 권한 요구

Kaniko: user-space 에서 동작. root 또는 privileged container 불필요. unprivileged Kubernetes pod 에서 빌드 가능.

BuildKit: 기본은 privileged container 또는 rootless 모드. Rootless 는 동작하지만 세부 기능 제약. unprivileged pod 에서는 제한된 기능 만.

폐쇄망 관점 — 보안팀이 unprivileged pod 만 허용하면 Kaniko 가 거의 항상 답. BuildKit 의 rootless 는 기능 제약 + 디버깅 어려움 으로 운영 비용 ↑.

평가축 2 — cache 효율

BuildKit: cache mount + layer cache + registry cache — 3 단계 cache. 재빌드 시간 30~70% 감소 가능.

Kaniko: layer cache 만. cache mount 없음. 재빌드 시간 감소 제한적.

폐쇄망 관점 — 빌드 시간 차이가 분 단위 가 됨. BuildKit 의 cache 효율이 결정적 advantage. 다만 Kaniko 도 충분 한 워크로드 (간단한 앱, 빠른 base image) 도 많음.

평가축 3 — registry 호환성

BuildKit: 거의 모든 registry 와 호환. internal Harbor / Nexus / Artifactory OK.

Kaniko: 주류 registry 는 OK. pre-2020 internal registry 와는 간헐적 호환성 이슈. 우리 케이스 — 한 고객사의 2018년 Nexus 와 push 인증 헤더 형식 충돌.

폐쇄망 관점 — 내부 registry 의 버전 을 먼저 확인. 오래된 registry 면 BuildKit 이 더 안전.

평가축 4 — secret 처리

BuildKit: --mount=type=secret 으로 빌드 중에만 노출되는 시크릿 지원. 최종 이미지에 남지 않음. 빌드 캐시에도 기록 안 됨.

Kaniko: 환경변수 또는 빌드 인자 로 시크릿 전달. 캐시 layer 에 남을 수 있음. 별도 secret store 통합 필요.

폐쇄망 관점 — 컴플라이언스 (특히 K-ISMS / SOC2 / FIPS) 가 빌드 시점 secret 비-노출 을 요구하면 BuildKit 이 답. Kaniko 로 가려면 별도 wrapping 필요.

4축 결정 매트릭스

조건                              | 권장
─────────────────────────────────┼────────
Unprivileged pod 강제           | Kaniko
Build cache 의 효율이 결정적     | BuildKit
오래된 internal registry        | BuildKit
빌드 시점 secret 노출 금지       | BuildKit
간단한 앱 + 빠른 base image     | 둘 다 OK (Kaniko 가 더 단순)
복잡한 multi-stage + 큰 dep    | BuildKit (cache 효율 결정적)

우리 6 고객사의 선택

고객 | 환경 / 우선순위                     | 선택
─────┼─────────────────────────────────────┼─────────
A    | 공공 / unprivileged 강제             | Kaniko
B    | 금융 / cache 효율 + secret 금지     | BuildKit (privileged 허가받음)
C    | 일반 / 간단 앱                      | Kaniko (단순성)
D    | 방산 / unprivileged + secret 금지   | Kaniko + 별도 secret wrapping
E    | 일반 / 큰 monorepo                  | BuildKit (cache 결정적)
F    | 공공 / 오래된 Harbor                | BuildKit (호환성)

결정이 갈린 핵심 변수 — D 고객의 사례. unprivileged + secret 금지 가 동시에 요구되면 둘 다 한계. Kaniko 를 별도 secret wrapping 으로 보강하거나, BuildKit 을 제한적 privileged 로 (보안팀 합의 후) 운영. 답이 조건부.

폐쇄망의 답은 폐쇄망의 축으로

폐쇄망 / 규제 환경에서 컨테이너 빌드 인프라를 지금 결정하려는 플랫폼 리드라면, 인터넷의 일반 BuildKit vs Kaniko 비교 글부터 덮자. 그 글들은 클라우드 기준 이라 privileged / cache / registry / secret 4축의 우선순위가 다름. 위 4축과 6 고객사 표로 다시 평가하면 답이 뒤집힐 수 있다.