“내 PC에서는 되는데요” — 이 문장을 영원히 퇴장시키는 방법
새 프로젝트에 합류할 때마다 반나절을 개발 환경을 세팅하는 데 쓴 경험, 한 번쯤 있을 것이다. README에 적힌 설치 순서를 따라가는데 Python 버전이 맞지 않고, 특정 시스템 라이브러리가 빠져 있고, 운영체제마다 경로가 다르다. 팀원에게 물어보면 돌아오는 답은 “어? 나는 잘 되는데” — 이 말을 들을 때의 막막함은 경력과 무관하다.
문제의 근원은 명확하다. 개발 환경이라는 것이 각자의 PC에 암묵적으로 쌓인 설정, 도구, 라이브러리의 조합이기 때문이다. 아무리 상세한 문서를 작성해도 운영체제 차이, 글로벌 패키지 버전, 셸 설정 같은 변수까지 통제할 수 없다. Docker가 애플리케이션 배포 환경을 컨테이너로 표준화했듯이, 개발 환경 자체를 컨테이너로 표준화하면 어떨까? 바로 이 발상이 Dev Containers의 출발점이다.
Dev Containers는 프로젝트 저장소 안에 .devcontainer/devcontainer.json 파일 하나를 두어 개발 환경 전체를 선언적으로 정의한다. 어떤 언어 런타임을 쓸지, 어떤 도구를 설치할지, IDE에 어떤 확장을 자동으로 붙일지, 어떤 포트를 열지 — 모두 코드로 관리된다. 이 파일을 커밋해두면 팀원 누구든, 어떤 운영체제에서든, 컨테이너 하나를 열어 즉시 동일한 환경에서 코딩을 시작할 수 있다.
이 글에서는 Dev Containers의 개념부터 첫 설정, 핵심 옵션 해부, 실전 프로젝트 레시피, GitHub Codespaces 연동, 그리고 운영 팁까지 처음부터 끝까지 안내한다. Docker 기본 개념만 알고 있다면 충분히 따라올 수 있다.
Dev Containers란 무엇인가
개념: 개발 환경을 통째로 컨테이너 안에 넣는다
Dev Containers(개발 컨테이너)는 Docker 컨테이너를 개발 환경 자체로 사용하는 방식이다. 보통 Docker 컨테이너는 애플리케이션을 패키징해서 배포하는 용도로 쓰지만, Dev Containers에서는 코드를 작성하는 환경이 컨테이너 안에 들어간다. 편집기(IDE)의 서버 프로세스가 컨테이너 내부에서 실행되고, 로컬의 IDE 클라이언트가 이 서버에 연결하는 구조다.
쉽게 비유하면 이렇다. 기존 방식은 내 작업 책상(로컬 PC)에 필요한 도구를 하나씩 가져다 놓는 것이고, Dev Containers 방식은 도구가 이미 완벽하게 배치된 작업실(컨테이너)에 들어가서 일하는 것이다. 작업실 설계도(devcontainer.json)만 공유하면 누구나 같은 작업실을 재현할 수 있다.
단순히 Docker를 쓰는 것과 무엇이 다른가
Docker 컨테이너에서 개발한다고 하면, 많은 사람이 docker exec으로 컨테이너에 들어가서 vim으로 코드를 편집하는 장면을 떠올린다. 그것도 가능하지만 Dev Containers는 전혀 다른 경험을 제공한다.
- IDE가 컨테이너 안에서 동작한다 — VS Code의 경우 Extension Host, Language Server, 터미널 프로세스가 모두 컨테이너 내부에서 실행된다. 로컬 PC에서는 UI만 렌더링한다. 따라서 자동 완성, 디버거, 린터 모두 컨테이너의 런타임과 라이브러리를 기준으로 동작한다.
- 포트 포워딩이 자동이다 — 컨테이너 안에서 웹 서버를 띄우면 로컬 브라우저에서 localhost로 바로 접근할 수 있다. 별도의 -p 옵션 없이도 IDE가 알아서 포트를 감지하고 연결한다.
- 파일 시스템이 연결된다 — 프로젝트 소스 코드는 로컬 파일 시스템과 컨테이너 사이에 마운트되어 Git 히스토리도 유지되고, 로컬 파일 탐색기에서도 접근 가능하다.
- 설정이 선언적이다 — docker run 명령의 긴 옵션 나열 대신 JSON 파일 하나로 환경 전체를 정의한다.
오픈 스펙: 특정 도구에 종속되지 않는다
Dev Containers는 Microsoft가 처음 VS Code용으로 만들었지만, 현재는 Development Containers Specification이라는 오픈 표준으로 관리된다. 이 표준을 지원하는 도구는 계속 늘어나고 있다.
- VS Code — Dev Containers 확장을 통해 가장 완성도 높은 경험을 제공한다.
- GitHub Codespaces — 동일한 devcontainer.json을 클라우드에서 실행한다. 로컬에 Docker를 설치할 필요조차 없다.
- JetBrains IDE — IntelliJ, PyCharm 등에서 Dev Containers를 원격 개발 환경으로 지원한다.
- DevPod — 오픈소스 Dev Container 관리 도구로, 로컬 Docker뿐 아니라 AWS, GCP 등 클라우드 VM에서도 Dev Container를 실행할 수 있다.
- devcontainer CLI — 터미널에서 Dev Container를 빌드하고 실행하는 공식 CLI 도구다. CI/CD에서도 활용할 수 있다.
이 표준 덕분에 팀원 A가 VS Code를, 팀원 B가 JetBrains를, 팀원 C가 Codespaces를 쓰더라도 모두 같은 devcontainer.json으로 동일한 환경을 사용할 수 있다.
시작하기 — 첫 Dev Container 만들기
사전 준비물
로컬에서 Dev Containers를 사용하려면 세 가지가 필요하다.
- Docker Desktop — Windows, macOS 모두 지원한다. 이미 Docker가 설치되어 있다면 그대로 사용하면 된다. Linux에서는 Docker Engine만으로 충분하다.
- VS Code — 가장 완성도 높은 Dev Containers 경험을 제공하는 편집기다.
- Dev Containers 확장 — VS Code 마켓플레이스에서 “Dev Containers”를 검색해 Microsoft가 배포하는 공식 확장을 설치한다. 확장 ID는 ms-vscode-remote.remote-containers이다.
3단계로 첫 Dev Container 열기
1단계: 프로젝트에 설정 파일 추가
프로젝트 루트에 .devcontainer 폴더를 만들고, 그 안에 devcontainer.json 파일을 생성한다.
mkdir .devcontainer가장 간단한 devcontainer.json은 이미지 하나만 지정하면 된다.
{
"name": "My Dev Environment",
"image": "mcr.microsoft.com/devcontainers/base:ubuntu"
}이것만으로도 Ubuntu 기반의 개발 환경이 준비된다. Git, curl, wget 같은 기본 도구가 이미 포함되어 있다.
2단계: 컨테이너에서 프로젝트 열기
VS Code에서 명령 팔레트(Ctrl+Shift+P 또는 Cmd+Shift+P)를 열고 Dev Containers: Reopen in Container를 선택한다. 처음 실행하면 Docker 이미지를 다운로드하고 컨테이너를 빌드하는 데 1~2분 정도 걸린다. 이후에는 캐시된 이미지를 사용하므로 몇 초 만에 열린다.
3단계: 컨테이너 안에서 개발 시작
VS Code 왼쪽 하단 모서리에 초록색 아이콘과 함께 “Dev Container: My Dev Environment”라고 표시되면 성공이다. 이 상태에서 터미널을 열면 컨테이너 내부의 셸이 열리고, 파일을 편집하면 컨테이너 안의 파일 시스템에 반영된다. 동시에 로컬의 Git 히스토리도 그대로 유지된다.
VS Code 명령 팔레트 없이 더 빠르게
프로젝트 폴더에 .devcontainer/devcontainer.json이 있으면, VS Code가 폴더를 열 때 자동으로 “이 프로젝트에 Dev Container 설정이 있습니다. 컨테이너에서 다시 열까요?”라고 물어본다. 알림을 클릭하면 바로 컨테이너 환경으로 전환된다.
devcontainer.json 핵심 설정 완전 해부
기본 이미지 하나만으로도 동작하지만, devcontainer.json의 진가는 개발 환경의 모든 측면을 세밀하게 제어할 수 있다는 점이다. 실무에서 자주 쓰는 핵심 속성을 하나씩 살펴보자.
image vs build — 이미지를 고를 것인가, 직접 만들 것인가
image는 미리 만들어진 Docker 이미지를 그대로 사용한다. Microsoft가 관리하는 공식 이미지가 주요 언어별로 제공된다.
// 미리 만들어진 Python 이미지 사용
{
"image": "mcr.microsoft.com/devcontainers/python:3.12"
}build는 Dockerfile을 지정해서 커스텀 이미지를 빌드한다. 팀 전용 도구나 특수한 시스템 라이브러리가 필요할 때 유용하다.
// 커스텀 Dockerfile 사용
{
"build": {
"dockerfile": "Dockerfile",
"context": ".."
}
}처음에는 공식 이미지로 시작하고, 요구사항이 복잡해지면 Dockerfile로 전환하는 것이 실용적이다.
features — Dockerfile 없이 도구를 추가하는 마법
Dev Containers에서 가장 편리한 기능 중 하나가 Features다. Features는 이미지 위에 특정 도구나 런타임을 레이어로 추가하는 모듈형 설치 스크립트다. Dockerfile을 직접 수정하지 않고도 필요한 도구를 선언적으로 추가할 수 있다.
{
"image": "mcr.microsoft.com/devcontainers/base:ubuntu",
"features": {
"ghcr.io/devcontainers/features/python:1": {
"version": "3.12"
},
"ghcr.io/devcontainers/features/node:1": {
"version": "20"
},
"ghcr.io/devcontainers/features/docker-in-docker:2": {}
}
}이 설정 하나로 Ubuntu 위에 Python 3.12, Node.js 20, 그리고 Docker-in-Docker까지 설치된다. 공식 Features 레지스트리에는 200개 이상의 Feature가 등록되어 있으며, AWS CLI, Terraform, Go, Rust, kubectl 등 거의 모든 주요 개발 도구를 지원한다.
customizations — IDE 확장과 설정을 자동으로
팀 전체가 같은 린터 확장, 같은 포맷터 설정, 같은 디버그 구성을 사용하도록 강제할 수 있다. 개인 취향의 영역이 아니라 프로젝트 표준으로 관리하는 것이다.
{
"customizations": {
"vscode": {
"extensions": [
"ms-python.python",
"charliermarsh.ruff",
"ms-python.mypy-type-checker",
"eamodio.gitlens"
],
"settings": {
"python.defaultInterpreterPath": "/usr/local/bin/python",
"editor.formatOnSave": true,
"editor.defaultFormatter": "charliermarsh.ruff",
"[python]": {
"editor.defaultFormatter": "charliermarsh.ruff"
}
}
}
}
}컨테이너가 열리면 지정한 확장이 자동으로 설치되고, 설정이 적용된다. 새 팀원이 합류해도 “ruff 확장 설치했어?”라고 물어볼 필요가 없다.
forwardPorts — 컨테이너 포트를 로컬로 연결
웹 서버, 데이터베이스 등 컨테이너 안에서 실행되는 서비스의 포트를 미리 선언할 수 있다.
{
"forwardPorts": [8000, 5432, 6379],
"portsAttributes": {
"8000": {
"label": "FastAPI",
"onAutoForward": "openBrowser"
},
"5432": {
"label": "PostgreSQL",
"onAutoForward": "silent"
}
}
}FastAPI 서버가 8000번 포트에서 시작되면 자동으로 브라우저가 열리고, PostgreSQL 포트는 조용히 포워딩만 해둔다. portsAttributes로 각 포트의 동작을 세밀하게 제어할 수 있다.
라이프사이클 명령 — 환경 구성 자동화
컨테이너 생성 시점에 의존성 설치, 데이터베이스 마이그레이션, 환경변수 설정 같은 초기화 작업을 자동으로 실행할 수 있다.
{
"postCreateCommand": "pip install -e '.[dev]'",
"postStartCommand": "echo 'Dev environment ready!'",
"postAttachCommand": "git fetch --all"
}- postCreateCommand — 컨테이너가 처음 생성될 때 한 번 실행된다. 의존성 설치, DB 초기화 등에 적합하다.
- postStartCommand — 컨테이너가 시작될 때마다 실행된다. 백그라운드 서비스 기동 등에 쓴다.
- postAttachCommand — IDE가 컨테이너에 연결(attach)될 때마다 실행된다.
여러 명령을 순서대로 실행해야 한다면 배열 형태로 지정할 수도 있고, 별도의 셸 스크립트 파일을 가리킬 수도 있다.
mounts와 환경변수
호스트의 특정 디렉토리를 컨테이너에 마운트하거나, 환경변수를 주입할 수 있다.
{
"mounts": [
"source=${localEnv:HOME}/.ssh,target=/home/vscode/.ssh,type=bind,readonly"
],
"containerEnv": {
"TZ": "Asia/Seoul",
"PYTHONDONTWRITEBYTECODE": "1"
},
"remoteEnv": {
"DATABASE_URL": "${localEnv:DATABASE_URL}"
}
}SSH 키를 읽기 전용으로 마운트하면 컨테이너 안에서도 Git 푸시가 가능하다. containerEnv는 컨테이너 전체에, remoteEnv는 IDE 프로세스에만 적용되는 환경변수다. localEnv 변수를 사용하면 호스트의 환경변수 값을 컨테이너로 전달할 수 있어 시크릿을 안전하게 주입하는 데 유용하다.
실전 프로젝트별 Dev Container 레시피
이론은 충분하다. 실제 프로젝트에 바로 복사해서 사용할 수 있는 완성된 레시피를 세 가지 소개한다.
레시피 1: Python + FastAPI 프로젝트
Python 웹 개발에 가장 많이 쓰이는 조합이다. Python 3.12와 함께 ruff(린터/포맷터), mypy(타입 체커), 그리고 VS Code의 Python 확장이 자동으로 구성된다.
{
"name": "Python FastAPI",
"image": "mcr.microsoft.com/devcontainers/python:3.12",
"features": {
"ghcr.io/devcontainers/features/github-cli:1": {}
},
"forwardPorts": [8000],
"portsAttributes": {
"8000": {
"label": "FastAPI Dev Server",
"onAutoForward": "openBrowser"
}
},
"postCreateCommand": "pip install -e '.[dev]'",
"customizations": {
"vscode": {
"extensions": [
"ms-python.python",
"charliermarsh.ruff",
"ms-python.mypy-type-checker"
],
"settings": {
"python.defaultInterpreterPath": "/usr/local/bin/python",
"editor.formatOnSave": true,
"[python]": {
"editor.defaultFormatter": "charliermarsh.ruff"
}
}
}
}
}이 설정으로 컨테이너를 열면 Python 3.12 환경에 프로젝트 의존성이 자동 설치되고, 코드를 저장할 때마다 ruff가 포맷팅을 적용한다. uvicorn으로 서버를 시작하면 8000번 포트가 자동으로 포워딩되어 브라우저가 열린다.
레시피 2: Node.js + TypeScript 프로젝트
프론트엔드 또는 풀스택 프로젝트에 적합한 구성이다. Node.js 20 LTS와 TypeScript, ESLint, Prettier가 포함된다.
{
"name": "Node.js TypeScript",
"image": "mcr.microsoft.com/devcontainers/typescript-node:20",
"forwardPorts": [3000, 5173],
"postCreateCommand": "npm install",
"customizations": {
"vscode": {
"extensions": [
"dbaeumer.vscode-eslint",
"esbenp.prettier-vscode",
"bradlc.vscode-tailwindcss"
],
"settings": {
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"typescript.preferences.importModuleSpecifier": "relative"
}
}
}
}Next.js(3000번)와 Vite(5173번) 포트를 모두 포워딩해서 어떤 프레임워크를 쓰든 바로 브라우저에서 확인할 수 있다. Tailwind CSS 확장까지 자동 설치되므로 클래스명 자동 완성도 즉시 사용 가능하다.
레시피 3: Docker Compose 멀티 서비스 환경
실제 프로덕션에 가까운 환경을 로컬에서 재현하려면 애플리케이션 서버뿐 아니라 데이터베이스, 캐시, 메시지 큐 같은 의존 서비스도 함께 띄워야 한다. Dev Containers는 Docker Compose와 통합하여 이를 지원한다.
먼저 docker-compose.yml을 작성한다.
# .devcontainer/docker-compose.yml
services:
app:
build:
context: ..
dockerfile: .devcontainer/Dockerfile
volumes:
- ..:/workspace:cached
command: sleep infinity
depends_on:
- db
- redis
db:
image: postgres:16
environment:
POSTGRES_USER: dev
POSTGRES_PASSWORD: dev
POSTGRES_DB: myapp
volumes:
- pgdata:/var/lib/postgresql/data
redis:
image: redis:7-alpine
volumes:
pgdata:그리고 devcontainer.json에서 이 Compose 파일을 참조한다.
{
"name": "Full Stack App",
"dockerComposeFile": "docker-compose.yml",
"service": "app",
"workspaceFolder": "/workspace",
"forwardPorts": [8000, 5432, 6379],
"postCreateCommand": "pip install -e '.[dev]' && python manage.py migrate",
"customizations": {
"vscode": {
"extensions": [
"ms-python.python",
"ckolkman.vscode-postgres"
]
}
}
}이 구성으로 컨테이너를 열면 Python 앱 서버, PostgreSQL, Redis가 동시에 기동된다. 앱 서버 컨테이너 안에서 개발하면서 db:5432로 PostgreSQL에, redis:6379로 Redis에 접근할 수 있다. 모든 데이터는 Docker 볼륨에 영속화되므로 컨테이너를 재시작해도 데이터가 유지된다.
GitHub Codespaces — 같은 설정, 클라우드에서
로컬 Dev Container가 그대로 클라우드로
Dev Containers의 가장 강력한 장점 중 하나는 GitHub Codespaces와의 완벽한 호환이다. 프로젝트에 커밋해 둔 devcontainer.json을 Codespaces가 그대로 읽어서 클라우드 VM 위에 동일한 환경을 생성한다. 로컬에 Docker를 설치할 필요도, 고사양 PC가 필요하지도 않다. 브라우저만 있으면 된다.
GitHub 저장소 페이지에서 초록색 Code 버튼을 누르고 Codespaces 탭에서 “Create codespace on main”을 클릭하면 끝이다. 몇 분 안에 브라우저 기반 VS Code가 열리며, 로컬에서 쓰던 것과 동일한 확장, 동일한 설정, 동일한 도구가 준비되어 있다.
Codespaces가 빛나는 순간
- 온보딩 — 새 팀원이 합류했을 때 “이 저장소 Codespace 열어”가 세팅 가이드의 전부가 된다.
- 오픈소스 기여 — 관심 있는 프로젝트에 코드스페이스를 열면 로컬 환경을 전혀 건드리지 않고 수정, 테스트, PR 제출까지 할 수 있다.
- 이동 중 작업 — 태블릿이나 저사양 노트북에서도 클라우드 VM의 성능으로 개발할 수 있다.
- 보안 격리 — 민감한 프로젝트를 개인 PC에 클론하지 않고 클라우드에서만 작업할 수 있다.
비용 관리
GitHub Codespaces는 무료 플랜에서 월 120시간의 코어 시간(2코어 기준 60시간)을 제공한다. 개인 사이드 프로젝트에는 충분한 양이다. 비용을 절약하려면 다음을 실천한다.
- 사용하지 않을 때 Codespace를 중지(Stop)한다. 기본 30분 유휴 타임아웃을 15분으로 줄여두면 깜빡 잊어도 자동 중지된다.
- 가장 작은 머신 타입(2코어)으로 시작한다. 빌드가 느리다고 느낄 때만 스케일업한다.
- GitHub 설정에서 Codespaces 비용 한도(spending limit)를 설정해두면 예상치 못한 과금을 방지할 수 있다.
성능 최적화와 실전 팁
볼륨 마운트 전략 — 느린 파일 I/O 해결
Dev Containers에서 가장 흔한 불만은 파일 I/O가 느리다는 것이다. 특히 macOS에서 Docker Desktop을 사용할 때, 호스트와 컨테이너 사이의 바인드 마운트 성능이 네이티브 대비 눈에 띄게 떨어진다. node_modules 같은 수만 개의 작은 파일이 있는 디렉토리에서 체감이 크다.
해결 방법은 두 가지다.
- Named Volume 사용 — 의존성 디렉토리를 호스트 마운트 대신 Docker Named Volume에 저장한다. devcontainer.json에서 다음과 같이 설정한다.
{
"mounts": [
"source=myproject-node_modules,target=${containerWorkspaceFolder}/node_modules,type=volume"
],
"postCreateCommand": "npm install"
}node_modules가 Docker Volume에 저장되므로 파일 I/O가 네이티브 속도로 동작한다. 다만 호스트에서 직접 node_modules에 접근할 수 없으므로, 모든 npm 작업은 컨테이너 터미널에서 수행해야 한다.
- Clone in Volume 모드 — VS Code에서 “Dev Containers: Clone Repository in Container Volume”을 사용하면 소스 코드 자체를 Docker Volume에 클론한다. 바인드 마운트를 완전히 우회하므로 가장 빠르지만, 호스트의 파일 탐색기에서 파일을 직접 볼 수 없다는 단점이 있다.
dotfiles로 개인 환경 유지
Dev Containers는 팀 표준을 강제하지만, 개인 취향(셸 alias, Git 설정, tmux 설정 등)까지 포기할 필요는 없다. VS Code 설정에서 Dotfiles Repository를 지정하면 컨테이너 생성 시 자동으로 dotfiles를 클론하고 설치 스크립트를 실행한다.
VS Code 설정(settings.json)에 다음을 추가한다.
{
"dotfiles.repository": "your-github-username/dotfiles",
"dotfiles.targetPath": "~/dotfiles",
"dotfiles.installCommand": "install.sh"
}이렇게 하면 어떤 Dev Container를 열든, 어떤 Codespace를 시작하든 자신의 셸 설정이 자동으로 적용된다. 팀 환경 안에서 개인의 생산성을 유지하는 균형점이다.
Rebuild vs Rebuild Without Cache
devcontainer.json을 수정한 뒤에는 컨테이너를 다시 빌드해야 변경이 반영된다. VS Code 명령 팔레트에서 두 가지 옵션을 제공한다.
- Rebuild Container — Docker 캐시를 활용해서 빌드한다. 대부분의 경우 빠르게 완료된다.
- Rebuild Without Cache — 캐시를 무시하고 처음부터 빌드한다. Features 업데이트가 반영되지 않거나, 이미지가 손상된 것 같을 때 사용한다.
일상적인 설정 변경에는 Rebuild, 문제가 생겼을 때는 Rebuild Without Cache를 선택한다. Dockerfile을 크게 수정했는데 변경이 반영되지 않는다면 캐시 문제일 가능성이 높다.
보안 고려사항
Dev Containers를 사용할 때 보안 측면에서 기억해야 할 점이 있다.
- 시크릿은 devcontainer.json에 넣지 않는다 — API 키, 데이터베이스 비밀번호 같은 시크릿은 반드시 localEnv를 통해 호스트 환경변수에서 주입하거나, GitHub Codespaces의 Encrypted Secrets 기능을 사용한다. devcontainer.json은 저장소에 커밋되므로 시크릿이 노출된다.
- 컨테이너 내부에서 Docker를 사용할 때 — Docker-in-Docker Feature를 사용하면 컨테이너 안에서 docker 명령을 실행할 수 있다. 이 경우 호스트 Docker 소켓을 마운트하는 방식(Docker-outside-of-Docker)보다 격리가 안전하다.
- 신뢰하지 않는 저장소의 Dev Container는 주의 — devcontainer.json의 postCreateCommand는 임의의 셸 명령을 실행할 수 있다. 낯선 오픈소스 프로젝트의 Dev Container를 열기 전에 설정 파일을 먼저 확인하는 습관을 들인다.
멀티 플랫폼 지원
Apple Silicon(ARM) Mac과 Intel/AMD(x86) PC가 혼재된 팀이라면 이미지의 플랫폼 호환성을 확인해야 한다. Microsoft 공식 Dev Container 이미지는 대부분 멀티 아키텍처를 지원하므로 걱정할 필요가 없다. 하지만 커스텀 Dockerfile을 사용한다면 베이스 이미지가 두 아키텍처를 모두 지원하는지 확인한다.
Dev Containers를 도입하면 달라지는 것들
Dev Containers는 단순히 개발 환경 세팅을 자동화하는 도구가 아니다. 도입하면 팀의 개발 문화 자체가 바뀐다.
온보딩 시간이 극적으로 줄어든다
기존에는 새 팀원이 첫 커밋을 하기까지 반나절에서 이틀이 걸렸다. README를 읽고, 의존성을 설치하고, 안 되는 부분을 구글링하고, 옆자리 동료에게 물어보고. Dev Containers가 있으면 이 시간이 5분으로 줄어든다. git clone 후 VS Code에서 Reopen in Container를 누르면 끝이다. 모든 도구, 모든 설정, 모든 확장이 준비되어 있다.
환경 문제가 코드 리뷰 대화에서 사라진다
PR 리뷰에서 “내 환경에서 테스트해봤는데 안 되던데?”라는 코멘트가 사라진다. 모든 팀원이 동일한 환경에서 작업하므로 환경 차이로 인한 false positive/negative가 없다. CI 환경과 로컬 환경의 차이도 최소화된다.
프로젝트 간 전환이 깔끔해진다
프로젝트 A는 Python 3.11 + PostgreSQL 14를, 프로젝트 B는 Python 3.12 + PostgreSQL 16을 사용한다고 하자. 전통적인 방식에서는 pyenv, nvm 같은 버전 관리 도구로 전환하거나, 시스템 전역 설정을 변경해야 했다. Dev Containers에서는 각 프로젝트의 컨테이너가 완전히 격리되어 있으므로 VS Code 창만 바꾸면 된다. 한 PC에서 서로 다른 버전의 도구를 충돌 없이 사용할 수 있다.
README의 환경 세팅 섹션이 세 줄로 줄어든다
더 이상 운영체제별 설치 가이드를 유지할 필요가 없다. README에는 이렇게만 적으면 된다.
## 개발 환경
1. Docker Desktop을 설치합니다.
2. VS Code에서 Dev Containers 확장을 설치합니다.
3. 이 저장소를 열고 "Reopen in Container"를 실행합니다.세 줄이면 충분하다. 나머지는 devcontainer.json이 알아서 처리한다.
마무리 — 개발 환경도 코드다
인프라를 코드로 관리하는 Infrastructure as Code(IaC)는 이미 업계 표준이 되었다. Dev Containers는 그 철학을 개발 환경에 적용한 것이다. 서버 환경을 Terraform으로 선언하듯, 개발 환경을 devcontainer.json으로 선언한다.
시작은 간단하다. 현재 진행 중인 프로젝트의 루트에 .devcontainer/devcontainer.json 파일을 하나 만들어보자. 이미지 하나를 지정하는 세 줄짜리 설정으로 시작해서, 필요에 따라 Features, 확장, 라이프사이클 명령을 하나씩 추가하면 된다.
Dev Containers를 한 번 경험하면, 로컬 PC에 직접 개발 도구를 설치하는 것이 이상하게 느껴지기 시작한다. 마치 Docker 없이 서버에 직접 패키지를 설치하던 시절이 아득하게 느껴지는 것처럼. 환경 세팅에 쓰던 시간을 코드 작성에 쓸 수 있다는 것, 그것만으로도 충분히 시도해볼 가치가 있다.
공식 Dev Containers 스펙 문서와 Microsoft의 공식 이미지·Features 카탈로그는 GitHub의 devcontainers 조직에서 확인할 수 있다. 이 글에서 소개한 레시피를 기반으로 자신만의 Dev Container를 만들어보고, 팀에 도입해보자. 한 번 맛보면 돌아갈 수 없다.
- [opencode 12일 집중 — 터미널 네이티브 AI 코딩 에이전트 완전 정복] 10/12화: opencode serve·run 자동화 완전 가이드 — 헤드리스 AI 코딩
- [opencode 12일 집중 — 터미널 네이티브 AI 코딩 에이전트 완전 정복] 9/12화: opencode MCP 서버 연동 — 외부 도구·데이터 확장 실전 가이드
- [온프레미스 AI Assistant 아키텍처 — Qwen3·Qwen3-VL 14일 설계] 13/14화: LLM 가드레일·평가 아키텍처 — Qwen3 온프레미스 안전 설계
- [온프레미스 AI Assistant 아키텍처 — Qwen3·Qwen3-VL 14일 설계] 12/14화: Qwen3 Function Calling·MCP·에이전트 오케스트레이션 실전 설계
참고 자료
- Development Containers 공식 사양 — devcontainer.json 스키마, 라이프사이클, Features 등 오픈 스펙 전문
- VS Code 공식 문서 — Developing inside a Container — Dev Containers 확장 설치부터 설정·활용까지 단계별 안내
