▲

Docker는 무엇이 되었는가?

 (tuananh.net)
8P by GN⁺ 21시간전 | ★ favorite | 댓글 3개
  • 컨테이너화의 선구자였던 Docker가 2026년 현재 정체성과 수익 모델을 찾기 위해 여러 차례 방향 전환을 거듭하고 있음
  • Kubernetes와의 경쟁 실패 이후 Swarm을 매각하고, 개발자 경험 중심의 도구 생태계(Scout, Testcontainers) 로 초점을 이동함
  • 이후 AI 모델 실행 플랫폼(Model Runner) 과 AI 보안(MCP Defender) 으로 확장하며 AI 인프라 기업으로 변모 중
  • 2025년 말에는 보안 강화 이미지(Hardened Images) 1,000여 개를 Apache 2.0 오픈소스로 공개, Chainguard의 성공에 대응함
  • 일련의 변화와 CEO 교체, 인수설은 Docker가 독립 기업으로서보다 매각을 위한 재정비 단계에 있음을 시사함

Docker의 정체성 위기

  • Docker는 컨테이너화 표준을 만든 기업으로, 이미 시장 적합성을 확보했음에도 수익화에 실패하며 정체성 위기를 겪음
    • 핵심 기술이 오픈소스화 및 범용화되면서, 차별화된 부가가치를 창출하기 어려워짐
    • “모두가 사용하는 인프라”가 되었지만, 직접 비용을 지불하려는 고객은 줄어든 상황

Swarm의 종료와 전략 후퇴

  • Docker Swarm은 Kubernetes와 경쟁하기 위한 오케스트레이션 솔루션이었으나, Kubernetes의 완승으로 시장에서 철수함
    • 이후 Docker는 풀스택 플랫폼 전략을 포기하고, 자사가 독자적으로 제공할 수 있는 영역에 집중하기 시작함

개발자 도구 중심 전환

  • Docker는 개발자 경험 개선을 핵심 차별점으로 삼음
    • Docker Scout은 2022년 Atomist 인수로 도입된 기능으로, 소프트웨어 공급망 보안과 취약점 가시화를 지원
    • AtomicJar 인수를 통해 Testcontainers를 확보, 실제 의존성 기반의 통합 테스트를 가능하게 함
    • 이러한 기능은 보안·관찰성·테스트 신뢰성 측면에서 Docker의 가치를 강화함

AI 중심 전환

  • 이후 Docker는 AI 모델 실행 플랫폼으로 방향을 전환함
    • Docker Model Runner를 통해 AI 모델 실행을 지원하고, Docker Compose는 AI 에이전트 및 모델 구성을 지원하도록 확장됨
    • Docker Offload는 클라우드 규모의 GPU 기반 AI 작업 실행을 가능하게 함
    • Google Cloud, Microsoft Azure, CrewAI, LangGraph, Vercel AI SDK 등과 파트너십 체결
    • 2025년 9월 MCP Defender 인수로 AI 보안 및 런타임 위협 탐지 역량을 확보, AI 인프라 보안 기업으로의 전환 가속

보안 강화 이미지 공개

  • 2025년 12월, Docker는 1,000개 이상의 Hardened Images를 Apache 2.0 라이선스로 무료 공개
    • 기존 이미지 대비 최대 95%의 취약점 감소를 달성
    • 이는 Chainguard의 보안 이미지 성공에 대응한 조치로 평가됨
    • 무료·오픈소스화는 강력한 경쟁 전략이지만, 수익 모델의 불명확성을 드러냄

리더십 교체와 인수설

  • 2025년 2월, CEO Scott Johnston이 퇴임하고 Oracle Cloud Infrastructure 창립자 Don Johnson이 후임으로 취임
    • 이 인사 변화 이후 대형 클라우드 기업의 인수 가능성이 업계에서 거론됨
    • 잇따른 전략 전환과 CEO 교체는 독립적 성장보다 매각 준비 가능성을 시사함

향후 전망

  • Docker 기술 자체는 인프라에 깊이 통합되어 지속될 전망
    • 오픈소스 특성상 기업의 향방과 무관하게 컨테이너 기술은 유지됨
  • 그러나 Docker Inc의 기업적 지속성은 불투명
    • 잦은 전략 전환과 리더십 변화로 장기 비전 부재가 드러남
  • Docker의 사례는 오픈소스 기술이 지나치게 성공했을 때의 수익화 한계를 보여주는 경고 사례로 평가됨
▲
hongminhee 18시간전  [-]

좀 가혹한 평가일 수도 있긴 한데, 균형을 잡기 위해 Lobsters에 올라온 이 댓글도 읽어볼 만 합니다. 대충 우리가 Docker, Inc.가 혁신했다고 알고 있는 많은 것들이 이미 그 전부터 존재했던 개념들과 기술들이고 Docker, Inc.가 이를 사유화하려고 시도했다는 것입니다.

답변달기
▲
ethanhur 19시간전  [-]

업계에 기여한 게 많은 기술/회사인데 여론이 너무 안 좋아진 게 아쉽네요.

라이센스 정책 변경 같은 실책도 크게 작용했겠지만 오픈소스 기업의 수익화가 점점 어려워진다는 느낌을 지울 수 없습니다.

답변달기
▲
GN⁺ 21시간전  [-]
Hacker News 의견들

  • Docker 기술은 성공했지만 수익화 전략을 제대로 세우지 못한 게 문제였음
    사실 Docker는 처음부터 오픈소스였고, 다른 팀들도 이미 비슷한 걸 만들었음
    다만 Docker는 일반 사용자도 쉽게 쓸 수 있게 만들었고, 그 후 너무 오래 기다리다 다른 회사들이 더 나은 제품을 냈음
    Swarm은 Kubernetes 경쟁용으로 만든 게 아니라 단순한 클러스터링 도구였음
    보안 기능을 무료로 제공한 건 훌륭했지만, 결국 스스로에게 기회를 주지 못한 셈임
    비영리단체처럼 행동했기에 사용자에게는 좋았지만 회사에는 장기적으로 손해였음

    • Docker가 오픈소스 기업의 전통적인 수익 모델인 기업용 지원 계약을 거부한 게 문제였음
      기업 고객들은 root 권한으로 실행되는 Docker daemon의 보안 문제, systemd와의 충돌, 자체 레지스트리 운영 등을 원했지만 Docker는 이런 요구를 무시했음
      Red Hat이 직접 패치를 제안했지만 거절당하자, 결국 Podman과 Quay 같은 대안을 만들어 기업 시장을 가져갔음
    • Docker가 2015년에 Open Container Initiative를 공동 설립했다는 점을 생각하면, 비영리처럼 행동했다는 말이 더 흥미로움
      혹시 Docker라는 회사 자체가 VC 자금을 이용해 오픈소스를 지원하려는 “장기 계획”이었을지도 모른다는 농담을 던짐
    • Docker는 초기에 Docker Desktop을 유료화했어야 했음
      월 5달러라도 받았다면 자연스러웠을 텐데, 나중에 유료화하면서 “러그 풀” 처럼 느껴졌음
      초기에 수익 모델을 세우지 않고 멋진 아이디어에만 집중한 게 결국 문제였음
    • Docker의 진짜 혁신은 Dockerfile 포맷과 무료 레지스트리였음
      이 두 가지 덕분에 커뮤니티가 폭발적으로 성장했음
      지금은 다른 툴을 쓰더라도 여전히 Dockerfile을 작성하고, Docker Hub와 유사한 저장소를 사용하고 있음
    • Swarm이 Kubernetes 경쟁용이 아니었다는 주장에는 동의하지 않음
      마케팅에서는 분명히 그렇게 포지셔닝했음

  • Docker가 라이선스 정책을 바꿨을 때의 대응 방식이 신뢰를 잃게 했음
    매출이 있는 회사에 상업용 라이선스를 요구한 건 이해하지만, 접근 방식이 문제였음
    회사에 30일 내 라이선스를 구매하지 않으면 소송하겠다는 식의 메일을 보내서 불신을 키웠음
    결국 회사들은 Rancher Desktop으로 갈아탔음

    • 우리 회사도 비슷한 경험을 했음
      갑자기 “Docker Desktop 설치하지 말라”는 메일이 돌았고, 컨테이너 전환을 추진하던 시점이라 혼란스러웠음
    • 이런 행보는 마치 Oracle처럼 느껴졌음
    • 라이선스 변경 자체는 괜찮지만, 왜 30일 통보가 문제인지 궁금함
      사전에 공지했고, 사용 중단이나 결제를 요구하는 건 당연한 절차 아닌가 하는 의견임
    • 이런 정책 변화가 오히려 Podman의 존재 이유를 만들어줬음
      만약 Docker가 그렇게 하지 않았다면 대체재 개발 동기가 없었을 것임
      차라리 초기에 Docker Hub 유료화나 엔터프라이즈용 워크플로 솔루션을 만들었어야 했음
    • 중간 규모 회사라면 SCCM 같은 설치 관리 시스템을 써야 한다는 지적도 있었음

  • Docker는 훌륭한 기술을 가졌지만, 시장(Product-Market Fit) 은 찾지 못했음
    무료 오픈소스로 퍼졌기 때문에 성공했지만, 유료 시장에서는 통하지 않았음

    • 결국 Docker는 단지 setns() 시스템 호출을 감싼 래퍼에 불과하다는 냉소적인 의견도 있었음

  • Docker가 뭘 해도 비판받는 분위기임
    오픈소스로 유지해도 문제, 기업 기능을 유료화해도 문제, AI 도구를 탐색해도 문제라는 식임
    Docker는 여전히 containerd와 runc 같은 핵심 런타임을 유지하고 있음
    그런데도 사람들은 Docker가 무의미하다고 말함

    • runc는 이미 OCI에 기부됐고, containerd는 CNCF 산하에서 관리됨
      Podman은 Red Hat의 별도 코드베이스를 사용함
    • Podman은 Docker와 거의 모든 걸 재구현했기 때문에 Docker에 의존하지 않음
    • containerd와 moby의 유지보수자 목록을 보면 여전히 Docker 직원이 있음
      다만 그들이 공식적으로 Docker의 지원을 받는지는 불분명함
    • Rancher, containerd, podman은 Docker에 의존하지 않으며, 단지 호환 계층만 제공함
    • Docker Desktop은 오픈소스가 아니며, Open Core 모델은 진정한 오픈소스 정신과 다르다는 비판도 있음

  • Docker 창립자가 직접 등장해 “2008년 Dotcloud로 시작했고 2018년에 떠났다”고 밝히며 AMA(무엇이든 물어보세요) 를 열었음

    • 한 사용자는 Docker 개발과 사업화 과정, 그리고 현재 근황에 대해 듣고 싶다고 함
    • 또 다른 사용자는 지금 Docker가 가장 해야 할 일이 무엇인지 질문함
    • Podman에 대한 생각을 묻는 사람도 있었음
    • 새 프로젝트 Dagger의 향후 계획을 묻는 질문도 있었음
    • “지금 돌아본다면 무엇을 다르게 했을지”에 대한 질문도 나옴

  • Docker가 새로운 제품을 내야 한다는 제안도 있었음
    예를 들어 DockerVM이라는 초고속 부팅 VM을 만들어 Firecracker나 gVisor와 경쟁하거나,
    AI 에이전트용 샌드박스 러너를 출시하자는 아이디어였음

    • 실제로 Docker는 이미 AI Sandboxes 문서를 공개했음
    • 혹은 CI Runner 서비스를 만드는 것도 좋은 방향이라는 의견이 있었음

  • Docker를 싫어하는 이유 중 하나는 root 권한 필요성과 이미지 관리 방식 때문임
    단순히 mv나 cp로 옮기고 싶은데, Docker는 내부 데이터베이스로 관리함

    • rootless 모드가 있지만, 호스트 설정이 필요함
      이는 Docker의 한계가 아니라 리눅스 커널의 제약임
      이미지 저장은 데이터베이스가 아니라 컨텐츠 주소 기반 파일시스템으로 되어 있음
      직접 수정하면 보안 문제가 생김
      자세한 내용은 rootless Docker 문서 참고
    • Podman의 rootless 튜토리얼 도 있음
    • 비root 사용자가 설치를 못한다고 불평하는 건 이상함
      오히려 Docker 사용 중 root 권한 상승이 가능한 게 진짜 문제였고, Podman이 이걸 해결했음
    • 더 강력한 샌드박싱을 원한다면 gVisor(runsc) 같은 대안도 고려할 수 있음
      gVisor 문서 참고

  • macOS에서는 apple/container가 Docker for Mac의 좋은 대체재로 떠오르고 있음
    6개월째 사용 중인데, 아직 문제는 있지만 활발히 개발되고 있음
    apple/container GitHub

    • containerd의 nerdbox도 대안으로 언급됨 (nerdbox GitHub)
    • 이게 Windows나 Linux에서도 동작하는 이미지를 빌드할 수 있는지 궁금하다는 질문이 있었음
    • 성능 오버헤드가 Docker for Mac보다 어떤지 묻는 사람도 있었음

  • 예전엔 docker-compose를 좋아했지만, 요즘은 nix + process-compose 조합이 더 마음에 듦
    필요할 때만 k3s나 tilt를 추가할 수 있어서 유연함

    • 여러 서버 인스턴스를 관리할 때 Nix를 어떻게 써야 하는지 묻는 사람도 있었음
      Docker 안에서 Nix를 돌릴지, Nix 안에서 Docker를 돌릴지 고민 중임
    • process-compose를 꼭 써봐야겠다는 반응도 있었음

  • 우리 회사는 지금도 Docker Swarm을 프로덕션에서 쓰고 있음
    대부분의 회사에서 Kubernetes는 과잉 설계라고 생각함
    Swarm은 단순하고 충분히 강력함

답변달기