채용 공고를 보다 보면 자꾸 이 단어가 눈에 밟히지 않나요? "Docker 사용 경험 우대", "컨테이너 환경에 대한 이해". 학교나 부트캠프 커리큘럼에는 잘 안 나오는데, 채용 공고에는 유독 자주 등장하는 그 이름, Docker예요.
막상 검색해보면 "이미지", "컨테이너", "Dockerfile" 같은 낯선 용어들이 쏟아져서 더 막막해지기도 해요. 그런데 걱정하지 않아도 괜찮아요. 이 글 하나만 따라오면 Docker가 정확히 무엇을 해결해주는 도구인지 이해하고, 오늘 직접 컨테이너 하나를 만들어서 실행까지 해볼 수 있어요.
컨테이너가 대체 뭔가요? (가상머신과 비교)
컨테이너를 한 문장으로 정의하면 이래요. "실행에 필요한 모든 파일을 담은, 격리된 프로세스"예요[2]. 조금 더 풀어보면, 내 애플리케이션과 그 실행에 필요한 라이브러리·설정을 하나로 묶어서, 다른 프로그램들과 서로 영향을 주지 않도록 분리해 놓은 실행 단위라고 이해하면 돼요.
여기서 자연스럽게 떠오르는 질문이 있어요. "그럼 가상머신(VM)이랑 뭐가 다른 거지?" 둘 다 "격리된 환경"이라는 점은 비슷하지만, 격리하는 방식이 완전히 달라요.
가상머신(VM)은 자체 커널, 하드웨어 드라이버, 프로그램까지 포함한 완전히 독립된 운영체제예요[2]. 그래서 무겁고, 부팅에도 시간이 걸려요.
컨테이너는 호스트 운영체제의 커널을 여러 컨테이너가 함께 공유해요[2]. 그래서 훨씬 가볍고, 같은 자원으로 더 많은 애플리케이션을 동시에 띄울 수 있어요[2].
앱 하나를 격리하자고 VM을 통째로 띄우는 건 그 자체로 "상당한 오버헤드"라고 Docker 공식 문서도 설명하고 있어요[2]. 표로 정리하면 이렇게 볼 수 있어요.
구분 | 컨테이너 | 가상머신(VM) |
|---|---|---|
격리 단위 | 프로세스 (커널 공유) | 운영체제 전체 (자체 커널) |
부팅 속도 | 초 단위로 빠름 | 상대적으로 느림 (OS 부팅 필요) |
자원 사용 | 가벼움, 필요한 만큼만 사용 | 무거움, OS만큼의 자원 필요 |
이식성 | 이미지 하나로 어디서든 동일하게 실행 | 이미지 용량이 크고 이동이 상대적으로 번거로움 |
Docker가 왜 필요할까요? — "제 컴퓨터에서는 되는데요?" 문제
주니어 개발자라면 한 번쯤 겪어봤을 상황이 있어요. 내 로컬에서는 멀쩡히 돌아가던 코드가, 동료 컴퓨터나 배포 서버에서는 갑자기 에러를 뿜는 상황이요. Node 버전이 다르거나, 설치된 라이브러리 버전이 미묘하게 다르거나, OS 자체가 달라서 생기는 문제들이죠.
Docker는 "애플리케이션을 개발하고, 배포하고, 실행하기 위한 오픈 플랫폼"이에요[1]. 컨테이너 단위로 앱을 패키징해서 공유하면, "함께 공유받은 모든 사람이 동일하게 동작하는 동일한 컨테이너를 받게 된다"는 게 핵심이에요[1]. 즉 내 컴퓨터, 동료의 컴퓨터, 테스트 서버, 운영 서버까지 — 실행 환경을 컨테이너 하나로 통일해서, "제 컴퓨터에서는 되는데요" 문제 자체를 구조적으로 줄여주는 거예요.
핵심 개념 3가지 — 이미지, 컨테이너, Dockerfile
Docker를 처음 접할 때 가장 헷갈리는 부분이 바로 이 세 단어의 관계예요. 하나씩 정리해볼게요.
이미지(Image): "Docker 컨테이너를 만들기 위한 지침이 담긴, 읽기 전용 템플릿"이에요[1]. 요리에 비유하면 레시피에 가까워요.
컨테이너(Container): "이미지의 실행 가능한 인스턴스"예요[1]. 같은 레시피(이미지)로 여러 개의 요리(컨테이너)를 동시에 만들어낼 수 있어요.
Dockerfile: 이미지를 어떻게 만들지 정의하는, 간단한 문법의 텍스트 파일이에요[1]. Dockerfile의 각 명령어 줄이 이미지의 레이어 하나가 되고, 코드가 바뀌면 바뀐 레이어만 다시 빌드되기 때문에 효율적이에요[1].
레지스트리(Registry) / Docker Hub: 이미지를 저장하고 공유하는 저장소예요. Docker Hub는 누구나 쓸 수 있는 공개 레지스트리이고, Docker는 별다른 설정이 없으면 기본적으로 Docker Hub에서 이미지를 찾아요[1].
정리하면 흐름은 이래요. Dockerfile을 작성 → 빌드해서 이미지를 만듦 → 이미지를 실행하면 컨테이너가 됨 → 이미지를 레지스트리(Docker Hub 등)에 올려서 공유.
자주 쓰는 명령어부터 익혀볼까요?
개념을 알았으니, 실제로 손에 익혀야 할 명령어 몇 가지만 짚어볼게요. 처음에는 아래 다섯 개만 알아도 충분해요.
명령어 | 역할 |
|---|---|
| Dockerfile을 읽어서 이미지를 빌드해요 |
| 이미지로부터 새 컨테이너를 만들고 실행해요[5] |
| 현재 실행 중인 컨테이너 목록을 보여줘요 ( |
| 이미 실행 중인 컨테이너 안에서 명령어를 실행해요 (내부 상태를 확인하거나 디버깅할 때 유용해요) |
| 로컬에 내려받아져 있는 이미지 목록을 보여줘요 |
직접 해보기 — 간단한 앱 컨테이너화 실습
이론은 여기까지, 이제 진짜로 손을 움직여볼 차례예요. Docker 공식 튜토리얼에서 제공하는 아주 간단한 Node.js 앱 예제를 그대로 따라가 볼게요[4].
먼저 프로젝트 루트에 Dockerfile이라는 이름으로 파일을 하나 만들어요.
# syntax=docker/dockerfile:1
FROM node:24-alpine
WORKDIR /app
COPY . .
RUN npm install --omit=dev
CMD ["node", "src/index.js"]
EXPOSE 3000한 줄씩 풀어보면 이래요.
FROM node:24-alpine— Node.js가 미리 설치된 가벼운 리눅스 기반 이미지를 베이스로 사용해요.WORKDIR /app— 컨테이너 안에서 작업할 디렉터리를 지정해요.COPY . .— 현재 폴더의 코드를 컨테이너 안으로 복사해요.RUN npm install --omit=dev— 필요한 패키지를 설치해요.CMD [...]— 컨테이너가 시작될 때 실행할 명령이에요.EXPOSE 3000— 앱이 3000번 포트를 쓴다는 걸 명시해요.
이제 이미지를 빌드하고[4]:
docker build -t getting-started .빌드된 이미지로 컨테이너를 실행해요[4]:
docker run -d -p 127.0.0.1:3000:3000 getting-started-d는 컨테이너를 백그라운드에서 실행하겠다는 뜻이고, -p는 내 컴퓨터(호스트)의 3000번 포트와 컨테이너 안의 3000번 포트를 연결해주는 옵션이에요[4]. 이제 브라우저에서 http://localhost:3000으로 접속하면, 내가 만든 컨테이너가 실제로 서비스를 하고 있는 걸 확인할 수 있어요.
여기서 앞서 배운 명령어들을 바로 써먹어 볼 수 있어요.
docker ps # 방금 실행한 컨테이너가 목록에 보이는지 확인
docker exec -it <컨테이너ID> sh # 컨테이너 내부로 들어가서 직접 확인
docker stop <컨테이너ID> # 확인이 끝났으면 컨테이너 정지docker ps로 컨테이너가 정상적으로 떠 있는지 확인하고, docker exec로 컨테이너 내부에 직접 들어가서 파일 구조나 프로세스를 살펴본 뒤, 다 확인했으면 docker stop으로 정리하면 돼요. 이 네 줄(build → run → ps/exec → stop)만 손에 익어도, "Docker 좀 써봤다"고 말할 수 있는 최소한의 실습 경험이 완성돼요.
왜 취업 준비에도 도움이 될까요?
단순히 "요즘 유행이니까"가 아니에요. 2025년 Stack Overflow Developer Survey에 따르면, Docker는 클라우드/컨테이너화 도구 카테고리에서 사용률 71.1%로 1위를 차지했고, 전년 대비 약 17%p나 상승했어요. 이는 해당 설문에서 집계된 기술 중 가장 큰 폭의 단일 연도 증가였어요[3]. (다만 이 수치에는 그해 설문에서 일부 기술 카테고리를 통합한 방법론 변화도 일부 영향을 미쳤다는 점이 설문 자체에 함께 언급돼요[3].)
국내 채용 시장에서도 마찬가지예요. 사람인의 Docker 관련 채용 카테고리에는 접속 시점 기준으로도 적지 않은 수의 공고가 등록돼 있었어요[6]. 정확한 "신입 공고 중 Docker 요구 비율" 같은 공식 집계는 아니지만, Docker가 더 이상 시니어 백엔드/인프라 엔지니어만의 스킬이 아니라 신입 채용 공고에서도 흔히 마주치는 키워드라는 정황은 충분해요[6].
이력서에 "Docker 사용 가능"이라고만 쓰는 것보다, 오늘 해본 것처럼 작은 프로젝트를 직접 컨테이너화해본 경험을 구체적으로 적는 게 훨씬 설득력 있어요. 예를 들어 "개인 프로젝트를 Dockerfile로 패키징해서 로컬/배포 환경 차이를 없앴다"처럼요.
마무리
컨테이너와 가상머신의 차이, 이미지·컨테이너·Dockerfile·레지스트리의 관계, 그리고 build/run/ps/exec 같은 핵심 명령어까지 — 오늘 하나씩 짚어봤어요. 처음엔 낯선 용어투성이지만, 막상 손으로 한 번 따라 해보면 생각보다 어렵지 않다는 걸 느꼈을 거예요.
Docker Compose나 Kubernetes처럼 더 깊은 주제는 자연스럽게 그다음 단계예요. 지금은 오늘 다룬 개념과 명령어만 확실히 내 것으로 만들어도 충분해요. 작은 실습 하나가 쌓여서 실무 감각이 되니까, 오늘 만든 컨테이너 하나부터 시작해보세요.
더 체계적으로 학습 로드맵을 따라가고 싶다면 트리업의 기술 가이드에서 다음 단계를 확인해보고, 오늘 익힌 내용은 스킬 관리에 등록해서 성장 과정을 기록해보는 것도 좋아요.
