컨테이너 안에서 도커를 쓰는 두 가지 길

DinD(Docker in Docker)와 DooD(Docker out of Docker)

CI/CD 파이프라인을 컨테이너로 실행하다 보면,
컨테이너 내부에서 docker build나 docker push 같은 명령을 실행해야 하는 상황이 자주 발생한다.

이를 해결하는 대표적 방법이 DinD와 DooD다.
두 방식은 구조, 보안, 리소스 소비 면에서 차이가 뚜렷하므로 목적과 환경에 맞는 선택이 중요하다.

 

 

도커 아키텍처 한눈에 보기

도커는 클라이언트, 데몬, 레지스트리로 이루어진다.

 

사용자가 터미널에서 docker... 명령을 입력하면,
클라이언트가 /var/run/docker.sock을 통해 도커 데몬과 통신하고,

데몬은 실제로 컨테이너 및 이미지를 관리한다.

 

결국 컨테이너 내부에서 도커를 사용하는 핵심 열쇠는 이 소켓에 접근할 수 있느냐에 달려 있다.

 

 

Docker in Docker (DinD) - 컨테이너 안에 새 데몬 띄우기

DinD는 컨테이너 내부에서 호스트와 별개의 도커 데몬을 실행하는 방식이다.

 

이렇게 하면 완전히 독립된 도커 환경이 생기므로 테스트 결과를 깔끔하게 격리할 수 있다.

반면 데몬이 하나 더 돌아가기 때문에 메모리와 CPU를 추가로 소모하며,
--privileged 옵션이 필수라서 컨테이너에 호스트 수준의 권한이 부여된다.

 

이 권한은 보안 측면에서 상당히 위험할 수 있다.

 

[ 실행 방법 ]

# DinD 데몬 컨테이너 실행 예시
docker run --privileged -d --name dind docker:dind

 

 

Docker out of Docker (DooD) - 호스트 소켓 공유하기

DooD는 호스트의 도커 데몬이 이미 쓰고 있는
/var/run/docker.sock을 컨테이너에 그대로 마운트해 클라이언트를 실행하는 방법이다.

 

별도의 데몬을 띄우지 않으므로 리소스 소비가 적고,
호스트의 이미지와 볼륨을 그대로 활용할 수 있다.

 

하지만 컨테이너가 소켓을 통해 호스트 도커 데몬을 그대로 조작할 수 있으므로,
권한 남용에 대한 주의가 필요하다.

 

[ 실행 방법 ]

# DooD 컨테이너 실행 예시
docker run -it -v /var/run/docker.sock:/var/run/docker.sock docker

 

 

두 방식의 주요 차이점

구분	DinD	DooD
구조	컨테이너 내부에 별도 도커 데몬 실행	호스트 도커 소켓 공유
리소스	추가 데몬을 인해 메모리/CPU 소비 ↑	리소스 소비 낮음
권한	--privileged 필수 (보안 취약점 있음)	호스트 도커 직접 제어 가능 (주의 필요)
격리성	매우 높음 (독립된 도커 환경)	낮음 (호스트 자원 접근)

 

 

선택 가이드

• 테스트 환경을 철저히 격리해야 한다면 DinD가 적합하다.
• 빌드 속도와 리소스 효율을 우선하거나 --privileged 사용이 금지된 조직에서는 DooD가 유리하다.
• DooD를 쓰더라도 컨테이너 권한과 마운트 범위를 최소화해 소켓 남용을 방지해야 한다.
• Docker 공식 문서 역시 가능한 한 소켓 공유 방식을 우선으로 권장한다.

 

 

마무리

컨테이너 내부에서 도커를 돌리는 일은
격리와 단순성 사이의 균형점을 찾는 과정이다.

 

DinD와 DooD가 제공하는 장단점을 정확히 이해하고,

파이프라인 요구 사항과 조직의 보안 정책을 바탕으로 최적의 방식을 선택하면
빌드 속도, 안정성, 보안 수준을 모두 끌어올릴 수 있다.

 

 

참고 자료:

Docker Official Web Site - What is Docker-in-Docker?

Docker-in-Docker: Containerized CI Workflows | Docker