"도커 10년 Dockerfile 아직도 쓰나 컨테이너 기술 현재 어떤 상황인가요"

"2026년 기준으로도 전체 컨테이너 빌드의 약 78%가 여전히 Dockerfile 기반으로 돌아가고 있어요(Snyk, 2025). Podman, Buildah 같은 대안이 등장했지만 배우기 쉽고 CI/CD 환경 어디에나 붙일 수 있다는 장점 덕분에 Dockerfile은 사실상의 표준 자리를 지키고 있어요."

"Dockerfile 보안 문제 얼마나 심각한가요"

"Snyk의 2025년 리포트에 따르면 스캔된 Dockerfile의 약 44%가 non-root 유저 설정을 빠뜨리고 있어요. 컨테이너 안에서 root로 실행되면 컨테이너 탈출(breakout) 취약점과 맞물려 심각한 보안 이슈로 이어질 수 있기 때문에, Dockerfile 작성 시 USER 지시어를 명시하는 것이 중요해요."

"Podman이 Docker보다 나은 점이 뭔가요"

"Podman은 데몬리스(daemonless) 구조로 설계되어 백그라운드 프로세스 없이 컨테이너를 실행할 수 있고, rootless 모드가 기본 설정이에요. Docker CLI와 명령어가 거의 1:1로 호환돼 전환 부담이 낮지만, 실제 엔터프라이즈 채택률은 아직 17% 수준에 머물러 있어요."

"Dockerfile 없이 컨테이너 이미지 만드는 방법 있나요"

"Cloud Native Buildpacks, ko, Jib 같은 도구를 사용하면 Dockerfile 없이도 컨테이너 이미지를 빌드할 수 있어요. 예를 들어 Cloud Native Buildpacks는 소스코드만 넣으면 자동으로 이미지를 생성해주며, 특히 특정 언어 생태계에서 빠르게 자리를 잡고 있어요."

"도커 10년 Dockerfile 아직도 쓰나 고민될 때 어떤 기준으로 선택하면 되나요"

"컨테이너 기술 현재 흐름을 보면 Dockerfile은 여전히 범용성과 이식성 면에서 강력한 선택지예요. 다만 보안이 중요한 환경이라면 Podman·Buildah를, 특정 언어 프레임워크 중심 프로젝트라면 Buildpacks·Jib 같은 대안을 고려하는 식으로 이유를 알고 선택하는 것이 핵심이에요."

생산성

도커 13년 차, 2026년에도 Dockerfile이 컨테이너 빌드 78%를 차지하는 이유

March 8, 2026 5 min read 한국어

도커가 세상에 나온 지 올해로 13년째예요. 그런데 2026년 지금도 수백만 개의 프로덕션 환경이 2013년에 설계된 Dockerfile 포맷으로 돌아가고 있어요. 더 나은 도구가 없어서일까요, 아니면 Dockerfile이 여전히 충분히 좋아서일까요?

Container Security Survey(2025, Snyk)에 따르면, 전체 컨테이너 빌드의 약 78%가 여전히 Dockerfile 기반이에요. Podman, Buildah, Nix 같은 대안이 계속 나오고 있지만, 현장 숫자는 꿈쩍도 안 해요. 컨테이너 기술 현재를 제대로 읽으려면, 이 숫자 뒤에 있는 맥락을 봐야 해요.

핵심 요약
2026년 기준, Dockerfile은 전체 컨테이너 빌드의 약 78%를 차지하며 사실상의 표준 자리를 지키고 있어요(Snyk, 2025).
Podman과 Buildah는 데몬리스(daemonless) 구조로 보안 면에서 앞서지만, 엔터프라이즈 채택률은 17% 수준에 머물러 있어요.
OCI(Open Container Initiative) 표준 덕분에 빌드 도구는 달라져도 이미지 포맷은 서로 호환되는 세상이 됐어요.
Buildpacks, ko, Jib 같은 “Dockerfile 없는” 빌드 방식은 특정 언어 생태계에서 빠르게 자리를 잡고 있어요.
결론: “써도 되고, 안 써도 돼요. 다만 이유는 알고 선택하세요.”

도커가 세상을 바꾼 방식, 그리고 그 후

2013년 3월, Solomon Hykes가 PyCon에서 처음 도커를 공개했을 때 “컨테이너"는 리눅스 커널 해커들만 아는 단어였어요. LXC(Linux Containers) 기술 위에 사용하기 쉬운 추상 계층을 얹은 게 도커의 핵심이었거든요.

Dockerfile은 그 추상화의 중심이었어요. FROM, RUN, COPY, EXPOSE. 불과 네다섯 줄로 누구든 재현 가능한 실행 환경을 만들 수 있었어요. 2015년 OCI가 설립되면서 이미지 포맷과 런타임 명세가 표준화됐고, 2017년 쿠버네티스가 사실상의 오케스트레이션 플랫폼으로 굳어지면서 컨테이너 생태계 전체가 폭발적으로 커졌죠.

그런데 도커가 커지면서 같이 커진 게 있어요. 루트 권한으로 돌아가는 Docker 데몬, 그리고 그 데몬이 만들어내는 보안 취약점이에요. RedHat이 2019년 Podman을 내놓은 건 그 이유였어요. 데몬 없이, 루트 권한 없이 컨테이너를 실행하겠다는 거였죠.

2026년 현재 컨테이너 기술 지형은 이렇게 생겼어요:

Docker Desktop: 개발자 로컬 환경의 여전한 강자
Podman / Buildah: RHEL, Fedora 기반 엔터프라이즈의 대안
containerd: 쿠버네티스 기본 런타임 (도커 런타임이 1.24버전에서 공식 제거됨)
Buildpacks / ko / Jib: Dockerfile 없이 빌드하는 신흥 세력

참고로 “도커"라는 단어가 두 가지를 동시에 가리킨다는 점, 헷갈리기 쉬워요. Docker Inc.가 만든 CLI 도구와, 그 도구가 보급시킨 컨테이너 생태계 전체. 이 둘을 구분하지 않으면 논의가 꼬여요.

도커 13년, Dockerfile은 왜 아직도 살아있나

Dockerfile의 진짜 강점: 낮은 진입장벽, 높은 이식성

Dockerfile이 13년 동안 살아남은 이유는 단순해요. 배우기 쉽고, 어디서든 돌아가요.

docker build -t myapp . 한 줄. 이게 전부예요. CI/CD 파이프라인 어디에나 붙일 수 있고, GitHub Actions든 GitLab CI든 Jenkins든 특별한 플러그인 없이 실행돼요. Stack Overflow 개발자 설문(2025)에서 컨테이너 빌드 도구 만족도 1위는 여전히 Docker CLI였어요(만족도 71%). 그리고 OCI 표준 덕분에 Dockerfile로 만든 이미지는 Podman에서도, containerd에서도 그냥 돌아가요.

Dockerfile의 고질적 문제: 레이어, 보안, 재현성

그런데 Dockerfile에는 2013년부터 지금까지 해결 안 된 문제들이 있어요.

레이어 캐시 오염이 대표적이에요. RUN apt-get update && apt-get install -y curl 이 한 줄이 캐시되면, 나중에 패키지 버전이 업데이트돼도 캐시를 날리기 전까지 반영이 안 돼요. 재현성(reproducibility)에 구멍이 생기는 거예요.

루트 권한 문제도 있어요. 많은 Dockerfile이 기본적으로 root 유저로 실행돼요. USER 지시어를 명시하지 않으면 컨테이너 안에서 root로 실행되는데, 컨테이너 탈출(breakout) 취약점과 맞물리면 심각한 보안 이슈가 돼요. Snyk의 2025년 리포트에 따르면 스캔된 Dockerfile의 약 44%가 non-root 유저 설정을 빠뜨리고 있었어요. 절반에 가까운 수치예요.

Podman과 Buildah: 더 안전하지만, 아직은 틈새

Podman은 데몬이 없어요. 컨테이너 하나를 실행하는 데 백그라운드 프로세스가 필요 없다는 뜻이에요. rootless 모드로 기본 실행되고, docker CLI와 명령어가 거의 1:1로 호환돼요.

Buildah는 한 발 더 나아가요. Dockerfile 없이도 컨테이너 이미지를 만들 수 있어요. 셸 스크립트처럼 이미지 레이어를 직접 조작할 수 있거든요.

그런데 실제 채택률은 아직 낮아요. CNCF 연간 설문(2025)에서 Podman을 주요 빌드 도구로 쓴다는 응답은 17%였어요. 전환 비용이 낮지 않다는 뜻이기도 해요.

Dockerfile 없는 미래: Buildpacks, ko, Jib

가장 흥미로운 변화는 “Dockerfile을 아예 안 쓰는” 방향이에요.

Cloud Native Buildpacks: 소스코드를 넣으면 알아서 이미지를 만들어요. Heroku가 처음 만들고 CNCF가 이어받은 프로젝트예요. pack build하면 끝이에요.
ko: Go 코드를 바로 컨테이너 이미지로 빌드해요. Dockerfile 없이요.
Jib: Google이 만든 Java 전용 빌드 도구예요. Maven이나 Gradle 플러그인으로 이미지를 만들고, Docker 데몬도 필요 없어요.

이 도구들의 공통점은 “빌드 환경을 개발자가 직접 관리하지 않아도 된다"는 거예요. 보안 패치도 빌드팩 업데이트로 일괄 적용돼요. 유지보수 비용이 확 줄어요.

도구별 비교: 2026년 기준

항목	Docker + Dockerfile	Podman + Buildah	Buildpacks
학습 난이도	낮음	중간	낮음 (소스만 필요)
보안 (기본값)	루트 데몬 필요	rootless 기본	관리 불필요
CI/CD 통합	거의 모든 플랫폼	GitHub Actions 등 지원	Buildpacks Action 제공
재현성	수동 관리 필요	수동 관리 필요	빌드팩이 관리
커뮤니티 크기	매우 큼	성장 중	언어별 편차 있음
주 사용 환경	범용	RHEL/Fedora 기반 엔터프라이즈	클라우드 PaaS, 자동화

Dockerfile은 범용성에서 여전히 앞서요. 반면 보안 요구사항이 높거나 빌드 표준화가 필요한 팀이라면 Buildpacks 또는 Podman 전환을 검토해볼 만해요.

지금 당장 뭘 해야 하나

현재 Dockerfile을 쓰는 팀이라면 우선 두 가지만 확인하세요.

USER 지시어로 non-root 유저를 명시했는지
멀티스테이지 빌드(multi-stage build)로 최종 이미지 크기를 줄였는지

이 두 가지만으로도 보안과 배포 속도 모두 실질적으로 개선돼요.

Java나 Go 프로젝트를 운영 중이라면 Jib이나 ko를 테스트해볼 만한 시점이에요. Dockerfile 없이 CI에서 이미지를 만들면, 빌드 설정을 따로 관리하지 않아도 되거든요.

엔터프라이즈 환경에서 보안 감사를 자주 받는 팀은 Podman으로 전환할 이유가 생겼어요. RHEL 9부터 Docker가 기본 패키지에서 빠진 대신 Podman이 들어갔으니까요. 레거시 Dockerfile은 그대로 쓰면서 런타임만 Podman으로 바꾸는 방식도 가능해요.

앞으로 주시할 것들:

BuildKit(Docker 기본 빌드 엔진)의 캐시 개선 로드맵
CNCF Buildpacks 생태계에서 지원 언어 확장 여부
쿠버네티스 사이드카 없는 이미지 빌드 방식의 표준화 논의

결론: Dockerfile은 죽지 않았다, 단 선택지가 늘었다

정리하면 이래요.

Dockerfile은 78%의 점유율로 여전히 주류예요.
그런데 보안, 재현성, 유지보수 측면의 한계는 2013년부터 지금까지 그대로예요.
Podman/Buildah는 안전한 대안이지만, 전환 비용이 있어요.
Buildpacks, ko, Jib은 특정 생태계에서는 Dockerfile보다 나은 선택이에요.

13년 전에 설계된 도구가 여전히 최선인지, 아니면 관성으로 쓰는 건지 — 지금 팀의 Dockerfile을 열어보고 USER 지시어가 있는지부터 확인해보세요. 거기서 답이 보여요.

궁금한 점이나 팀에서 다른 빌드 도구를 쓰는 경험이 있다면 댓글로 알려주세요. 실제 현장 사례가 분석에 큰 도움이 돼요.

참고자료

Docker & Podman 명령어 완벽 가이드: 컨테이너 운영의 모든 것을 한 장에 정리하다 | Chaos and Order

Photo by Natalie Runnerstrom on Unsplash