저도 처음에는 이 부분이 제일 헷갈렸습니다. PC에서는 Docker 명령어가 보이고, 시놀로지 NAS에서는 Container Manager라는 이름으로 보이니 완전히 다른 제품처럼 느껴졌거든요. 그런데 실제로 써보면 구조는 생각보다 단순합니다. Docker는 컨테이너를 실행하는 기반 기술이고, DSM 7.3의 Container Manager는 NAS에서 그걸 좀 더 쉽게 다루게 해주는 관리 도구에 가깝습니다. Docker 컨테이너는 호스트의 커널을 공유하는 가벼운 격리 프로세스라 VM보다 부담이 적고, Docker Compose는 여러 서비스를 한 번에 정의하고 띄울 수 있게 해줍니다.

이번 글에서는

• Docker가 왜 필요한지
• 시놀로지 NAS에서 Container Manager로 무엇을 할 수 있는지
• 둘의 차이를 어떻게 이해하면 쉬운지
• 실제 예시는 어떤 식으로 시작하면 좋은지

이 순서로 정리해보겠습니다.

Docker를 한 문장으로 설명하면

Docker는 애플리케이션을 필요한 실행 환경과 함께 묶어서, 어느 서버에서든 비슷하게 실행할 수 있게 해주는 컨테이너 플랫폼입니다. Docker 공식 문서도 Docker를 “애플리케이션을 개발·배포·실행하기 위한 오픈 플랫폼”으로 설명하고 있고, 컨테이너는 필요한 파일을 포함한 격리된 프로세스로 설명합니다.

쉽게 말하면 이런 느낌입니다.

예전 방식은
“서버마다 설치 환경이 달라서 여기서는 되는데 저기서는 안 된다”는 문제가 자주 생겼습니다.

Docker 방식은
“앱 + 라이브러리 + 실행 환경”을 이미지로 묶어두고, 그 이미지를 어디서든 같은 방식으로 실행하는 구조입니다.

그래서 개발 PC에서 잘 돌던 앱을 NAS나 리눅스 서버로 옮길 때도 훨씬 예측 가능해집니다.

컨테이너와 가상머신은 무엇이 다를까

처음 입문할 때 가장 많이 비교하는 대상이 VM입니다.

가상머신은 운영체제 자체를 통째로 하나 더 올리는 느낌입니다.
반면 컨테이너는 호스트 OS의 커널을 공유하면서 필요한 프로세스만 격리해서 실행합니다. Docker 문서에서도 여러 컨테이너가 같은 커널을 공유한다고 설명합니다. 그래서 보통 컨테이너가 더 가볍고, 시작도 빠르고, 작은 단위의 서비스 배포에 잘 맞습니다.

제가 실무나 홈서버 관점에서 느낀 차이는 이렇습니다.

• 가상머신: 운영체제까지 따로 필요, 무겁지만 독립성이 큼
• 컨테이너: 앱 단위 배포에 유리, 가볍고 빠름
• 홈서버/NAS: 제한된 자원에서 여러 서비스를 띄우려면 컨테이너가 훨씬 효율적

즉, NAS처럼 CPU·메모리가 아주 넉넉하지 않은 환경에서는 Docker가 특히 잘 맞습니다.

Docker에서 자주 보는 핵심 용어 5가지

1) 이미지(Image)

컨테이너를 만들기 위한 템플릿입니다.
예를 들어 nginx, postgres, wordpress 같은 것들이 이미지입니다.

2) 컨테이너(Container)

이미지를 실제로 실행한 상태입니다.
이미지는 설계도, 컨테이너는 실행 중인 인스턴스라고 생각하면 이해가 쉽습니다.

3) 볼륨(Volume)

컨테이너를 지워도 데이터를 남기기 위한 저장소입니다.
DB 데이터, 업로드 파일, 설정 파일은 보통 볼륨에 분리합니다. Docker Engine 문서는 이미지·컨테이너 외에도 볼륨과 네트워크 같은 객체를 daemon이 관리한다고 설명합니다.

4) 네트워크(Network)

컨테이너끼리 통신하거나 외부와 연결될 때 쓰는 가상 네트워크입니다.

5) Compose

여러 컨테이너를 한 번에 정의하는 방식입니다. Docker는 Compose를 단일 YAML 파일로 서비스·네트워크·볼륨을 관리하는 도구로 설명합니다.

Docker Engine과 Synology Container Manager의 관계

이 부분이 가장 중요합니다.

Docker Engine은 실제로 컨테이너를 실행하는 핵심 엔진입니다. Docker 공식 문서에 따르면 Docker Engine은 dockerd 데몬, API, CLI로 구성되고 이미지·컨테이너·네트워크·볼륨 등을 관리합니다.

반면 시놀로지 DSM 7.3의 Container Manager는
NAS 환경에서 컨테이너를 GUI로 다루기 쉽게 만든 관리 레이어라고 보면 됩니다. Synology 공식 문서에서는 Project 메뉴에서 하나 또는 여러 컨테이너로 구성된 프로젝트를 생성·운영·관리할 수 있다고 안내합니다.

즉,

• Docker Engine = 실제 실행 엔진
• Container Manager = NAS에서 쉽게 다루는 관리 화면
• Compose / Project = 여러 컨테이너를 한 세트로 관리하는 방식

이라고 이해하면 거의 맞습니다.

DSM 7.3 Container Manager가 편한 이유

시놀로지 NAS를 쓰는 분이라면 명령어보다 GUI가 편한 순간이 많습니다.

Container Manager의 장점은 이런 쪽에서 크게 느껴집니다.

1) GUI로 이미지 검색과 다운로드가 쉬움

Docker Hub에서 이미지를 찾고 내려받는 과정을 NAS 화면에서 처리할 수 있습니다.

2) 컨테이너 생성이 쉬움

포트, 환경변수, 볼륨 마운트, 재시작 정책 등을 화면에서 입력할 수 있어 초보자 진입장벽이 낮습니다.

3) 로그와 상태 확인이 쉬움

실행 여부, 에러 로그, 리소스 사용 현황을 빠르게 확인할 수 있습니다.

4) Project 방식으로 Compose 운영이 가능함

여러 컨테이너를 하나의 프로젝트처럼 묶어 관리할 수 있어서, 웹앱 + DB 같이 함께 움직여야 하는 구성을 다루기 편합니다. Synology 공식 Project 문서도 이 개념을 지원한다고 설명합니다.

반대로 CLI Docker가 더 좋은 경우

Container Manager가 편하긴 하지만, 모든 상황에서 최고는 아닙니다.

직접 docker 나 docker compose 명령어를 쓰면 좋은 경우도 분명합니다.

1) 재현성이 좋음

Compose 파일 하나만 있으면 다른 서버에서도 거의 같은 구조로 올리기 쉽습니다. Docker Compose는 다중 컨테이너 앱을 YAML로 정의하고 전체 라이프사이클을 관리할 수 있다고 공식 문서가 설명합니다.

2) 백업과 버전관리가 쉬움

설정이 파일로 남기 때문에 Git으로 관리하기 좋습니다.

3) 자동화에 강함

스크립트, CI/CD, 배포 자동화와 연결하기 좋습니다.

4) 옵션을 세밀하게 다루기 좋음

GUI에서 안 보이는 옵션도 CLI로는 직접 제어하기 쉽습니다.

한눈에 비교: Docker CLI vs DSM 7.3 Container Manager

제 경험상

• 처음 시작은 Container Manager
• 구성이 커지면 Compose 파일 관리
  이 흐름이 가장 안정적이었습니다.

실제 예시 1: 가장 쉬운 시작, Nginx 하나 띄워보기

Docker 입문에서 제일 쉬운 예시는 정적 웹서버입니다.

예를 들어 Nginx 컨테이너 하나를 띄우면
“이미지 다운로드 → 컨테이너 실행 → 포트 연결”
이라는 Docker의 핵심 흐름을 빠르게 익힐 수 있습니다.

Docker 공식 문서에서 docker run은 이미지로부터 컨테이너를 실행하는 기본 명령이고, 이미지 참조에는 태그를 붙여 특정 버전을 지정할 수 있다고 설명합니다.

예시 명령은 이런 형태입니다.

docker run -d --name my-nginx -p 8080:80 nginx:latest

이 의미는 다음과 같습니다.

• -d : 백그라운드 실행
• --name my-nginx : 컨테이너 이름 지정
• -p 8080:80 : NAS나 서버의 8080 포트를 컨테이너 80 포트와 연결
• nginx:latest : 실행할 이미지

DSM 7.3 Container Manager에서는?

같은 작업을 GUI로 할 수 있습니다.

1. 이미지 검색에서 nginx 다운로드
2. 새 컨테이너 생성
3. 로컬 포트 8080 → 컨테이너 포트 80 연결
4. 실행
5. 브라우저에서 NAS주소:8080 접속

처음 Docker를 이해할 때는 이 예시 하나만 성공해도 감이 많이 잡힙니다.

실제 예시 2: 웹서비스답게, WordPress + MariaDB 같이 올리기

여기부터는 Compose 개념이 정말 편해집니다.

워드프레스는 단독으로 끝나지 않고 보통

• WordPress 컨테이너
• MariaDB 또는 MySQL 컨테이너
  두 개 이상이 함께 필요합니다.

이런 구조를 각각 따로 만들 수도 있지만, Compose로 관리하면 훨씬 정리됩니다. Compose는 여러 서비스를 한 YAML로 정의하는 방식이고, Docker 공식 빠른 시작도 Python 앱 + Redis 예시로 이런 멀티 컨테이너 구조를 보여줍니다.

아래는 입문용 예시입니다.

services:
  db:
    image: mariadb:11
    container_name: wp-db
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: strong_root_password
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wpuser
      MYSQL_PASSWORD: strong_wp_password
    volumes:
      - ./db_data:/var/lib/mysql  wordpress:
    image: wordpress:php8.2-apache
    container_name: wp-app
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "8081:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wpuser
      WORDPRESS_DB_PASSWORD: strong_wp_password
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - ./wp_data:/var/www/html

이 예시에서 중요한 포인트

• services 아래에 앱과 DB를 같이 정의
• depends_on으로 실행 순서를 어느 정도 정리
• volumes로 데이터를 컨테이너 밖에 보관
• 포트 8081:80으로 워드프레스 접속 가능

DSM 7.3 Container Manager에서는?

Project 기능에서 이런 YAML 기반 구성을 가져와 관리할 수 있습니다. Synology 공식 문서도 Project가 하나 또는 여러 컨테이너로 구성된 프로젝트를 생성·관리하는 메뉴라고 설명합니다.

즉, NAS에서도
“단순 GUI 클릭”만이 아니라
“Compose 스타일의 프로젝트 운영”이 가능하다는 점이 꽤 큰 장점입니다.

시놀로지 NAS에서 Docker를 쓸 때 특히 좋은 사례

제가 보기엔 DSM 7.3 Container Manager는 아래 같은 용도에서 특히 강합니다.

1) 홈서버 서비스 운영

• 워드프레스
• n8n
• Jellyfin
• Joplin Server
• Grafana
• Portainer

2) 작은 사내 서비스 테스트

• 내부용 웹앱
• API 서버
• 대시보드
• DB 실험 환경

3) 개발·검증용 분리 환경

같은 NAS 안에서도 프로젝트별로 분리해서 돌리기 좋습니다.

특히 시놀로지는 파일 접근, 폴더 권한, 백업 구조를 NAS 친화적으로 관리할 수 있어서 “홈랩 + 운영 연습” 용도로 꽤 괜찮습니다.

Docker를 처음 쓸 때 가장 많이 하는 실수

실제로 처음 할 때는 기술 자체보다 운영 습관에서 문제가 많이 납니다.

1) 데이터를 컨테이너 안에만 저장함

컨테이너 삭제 시 데이터가 같이 날아갈 수 있습니다.
DB, 업로드 파일, 설정 파일은 볼륨 또는 바인드 마운트로 분리하는 습관이 중요합니다. Docker Engine 문서도 persistent data에 volume 사용을 안내합니다.

2) 포트 충돌을 확인하지 않음

NAS에서 80, 443, 8080, 5000 계열 포트는 이미 다른 서비스가 쓰고 있을 수 있습니다.

3) latest 태그만 무조건 사용함

처음에는 편하지만, 나중에 버전이 달라져 예기치 않은 변경이 생길 수 있습니다. Docker 문서도 이미지 참조에 태그를 써서 특정 버전을 지정할 수 있다고 설명합니다.

4) 환경변수를 정리하지 않음

비밀번호나 설정값을 하드코딩하면 나중에 관리가 어렵습니다.

5) 백업을 안 함

Compose 파일, 데이터 폴더, DB 덤프는 반드시 따로 백업하는 습관이 필요합니다.

입문자에게 추천하는 시작 순서

처음이면 너무 어렵게 가지 않는 게 좋습니다.

1단계

Container Manager에서 Nginx 하나 띄워보기

2단계

볼륨 마운트와 포트 매핑 이해하기

3단계

환경변수 넣는 컨테이너 실행해보기
예: DB, 워드프레스

4단계

Project 기능으로 Compose 스타일 구성 써보기

5단계

나중에는 YAML 파일을 따로 관리하면서 버전관리까지 연결하기

이렇게 가면 GUI의 편의성과 Docker 본질 둘 다 잡을 수 있습니다.

결국 무엇이 더 좋을까

정리하면 이렇습니다.

Docker는 컨테이너를 실행하는 기술 자체이고,
DSM 7.3 Container Manager는 그 기술을 시놀로지 NAS에서 쉽게 다루는 도구입니다. Docker는 애플리케이션을 컨테이너로 패키징해 실행하게 해주고, Docker Compose는 여러 서비스를 하나의 YAML로 정의·운영하게 해주며, Synology의 Project 기능은 이런 멀티 컨테이너 구성을 NAS GUI에서 관리하는 데 초점을 둡니다.

그래서 제 추천은 단순합니다.

• 처음 배우는 단계라면 → DSM 7.3 Container Manager부터
• 반복 배포와 구조화가 필요해지면 → Compose 파일 관리까지
• 실무형으로 확장하고 싶다면 → CLI와 YAML 중심으로 이동

처음부터 명령어만 붙잡고 씨름할 필요는 없습니다.
반대로 GUI만 쓰다 보면 구조를 놓칠 수도 있습니다.
가장 좋은 방법은 시놀로지 GUI로 감을 잡고, 나중에 Compose로 정리하는 흐름입니다.

이 방식이 홈서버 운영에도 좋고, 나중에 리눅스 서버나 클라우드로 넘어갈 때도 가장 자연스럽습니다.

마무리

Docker를 배우면 단순히 “앱 하나 실행하는 법”만 익히는 게 아닙니다.
서비스를 더 깔끔하게 배포하고, 더 쉽게 옮기고, 더 안정적으로 관리하는 방식을 배우게 됩니다.

시놀로지 NAS의 DSM 7.3 Container Manager는 그 첫걸음을 꽤 쉽게 만들어줍니다.
특히 홈서버, 개인 블로그, 자동화 도구, DB 실험 환경, 내부 웹서비스를 운영하려는 분들에게는 정말 좋은 입문 도구입니다.

저도 처음에는 NAS에서 GUI로 시작했지만, 나중에는 Compose 파일을 직접 관리하는 쪽이 훨씬 편해졌습니다.
그래서 처음 시작하시는 분이라면 이렇게 말씀드리고 싶습니다.

“Container Manager로 시작하고, Docker Compose로 정리해가면 됩니다.”

그 흐름만 잡혀도 Docker가 훨씬 덜 어렵게 느껴질 겁니다.

게시물 Docker란 무엇인가? 시놀로지 NAS DSM 7.3 Container Manager와 함께 이해하는 실전 입문 가이드이 하우인포-IT·테크에 처음 등장했습니다.

1) 준비물 체크

• Windows 11 (Pro/Home 무관)
• Docker Desktop 설치 완료 (docker ps가 에러 없이 동작해야 함)
• 공유기: ipTIME (KT 회선 환경 가정)
• 접속 클라이언트: 안드로이드 Minecraft(베드락)

2) BDS 기본 포트(중요)

베드락 서버 기본 포트는 다음과 같습니다.

• UDP 19132 (게임 접속 포트)

즉, 내부/외부 모두 UDP 19132만 제대로 열리면 접속이 됩니다.

3) Docker로 BDS 설치(Compose 방식)

3-1. 서버 폴더 만들기 (월드/설정 영구 저장)

예시: D:\minecraft\bedrock

PowerShell:

mkdir D:\minecraft\bedrock
cd D:\minecraft\bedrock

3-2. docker-compose.yml 만들기

D:\minecraft\bedrock\docker-compose.yml 파일을 만들고 아래 내용을 그대로 붙여넣습니다.

services:
  bds:
    image: itzg/minecraft-bedrock-server:latest
    container_name: mc-bedrock
    ports:
      - "19132:19132/udp"
    environment:
      EULA: "TRUE"
      SERVER_NAME: "Howinfo Bedrock Server"
      GAMEMODE: "survival"
      DIFFICULTY: "normal"
      LEVEL_NAME: "HowinfoWorld"
      MAX_PLAYERS: "10"
      ONLINE_MODE: "true"
      TZ: "Asia/Seoul"
    volumes:
      - ./data:/data
    restart: unless-stopped

3-3. 서버 실행

docker compose up -d

정상 동작 확인:

docker ps
docker logs -f mc-bedrock

• docker ps에서 mc-bedrock이 Running이면 1차 성공
• docker logs -f에서 심각한 에러 없이 대기 상태로 들어가면 OK

4) Windows 방화벽 열기 (UDP 19132)

서버 PC(Windows 11)에서 방화벽이 막고 있으면, 같은 집에서도 접속이 안 될 수 있습니다.

Windows 보안 → 방화벽 및 네트워크 보호 → 고급 설정 → 인바운드 규칙 → 새 규칙

• 규칙 유형: 포트
• 프로토콜: UDP
• 포트: 19132
• 허용
• 프로필: 보통 개인(Private) 포함(필요 시 도메인도)
• 이름 예: Minecraft Bedrock UDP 19132

5) 안드로이드에서 “같은 와이파이”로 접속 확인 (내부 접속)

외부 설정 전에 먼저 내부에서 정상 접속되는지 확인하는 게 가장 빠릅니다.

5-1. 서버 PC 내부 IP 확인

PowerShell:

ipconfig

예: 192.168.0.15

5-2. 안드로이드 Minecraft에서 서버 추가

Minecraft(베드락) → 플레이 → 서버 → 서버 추가 (핸드폰에서 연결할 서버주소 또는 도메인 직접 입력)

• 서버 이름: 아무거나
• 서버 주소: 192.168.0.15 (서버 PC 내부 IP)
• 포트: 19132

✅ 같은 와이파이에서 접속이 되면, BDS 설치/컨테이너/방화벽은 거의 끝난 것입니다.

6) ipTIME 공유기 포트포워딩(외부 접속) 설정

이제 집 밖(모바일 데이터, 회사, 외부 PC)에서도 접속되게 하려면 공유기에서 포트를 열어야 합니다.

6-1. 서버 PC 내부 IP 고정(권장)

서버 PC의 내부 IP가 바뀌면 포트포워딩이 무용지물이 됩니다.

• ipTIME 관리자 페이지 접속(보통 192.168.0.1)
• DHCP 서버 설정 / 주소 예약 메뉴에서
  서버 PC의 MAC 주소에 192.168.0.15처럼 고정 예약 권장

6-2. 포트포워딩 추가

ipTIME 관리자 페이지 → NAT/라우터관리 → 포트포워드

• 프로토콜: UDP
• 외부 포트: 19132
• 내부 IP: 서버 PC 내부 IP (예: 192.168.0.15)
• 내부 포트: 19132

저장 후 적용

7) 집 밖(외부)에서 접속 확인

7-1. 공인 IP 확인

서버 PC 또는 휴대폰에서 “내 IP” 검색(공인 IP 확인)
외부 접속 테스트 시 주소로 사용합니다.

7-2. 안드로이드에서 모바일 데이터로 접속 테스트

안드로이드에서 와이파이를 끄고(모바일 데이터로 전환) Minecraft → 서버 추가:

• 서버 주소: 공인 IP
• 포트: 19132

✅ 모바일 데이터에서 접속되면 외부 접속까지 성공입니다.

8) 외부 접속이 안 될 때(가장 흔한 원인 3가지)

1. UDP 포트포워딩을 TCP로 걸어둔 경우
   • 베드락은 기본이 UDP입니다. 포워딩 프로토콜이 UDP인지 다시 확인하세요.
2. Windows 방화벽 규칙 누락
   • UDP 19132 인바운드가 실제로 허용됐는지 재확인
3. 이중 NAT (KT 장비 + ipTIME)
   • KT 모뎀/공유기가 라우팅을 하고, ipTIME도 라우팅을 하면 “겹 NAT”가 생겨 외부 접속이 막히는 경우가 있습니다.
   • 이때 해결 방법은 보통:
     • KT 장비를 브릿지 모드로 전환하거나
     • KT 장비에서 ipTIME을 DMZ로 지정하거나
     • ipTIME을 AP 모드로 전환(권장 시나리오에 따라 다름)

외부 접속이 막히면, 집 네트워크 구조(“KT 장비가 따로 있는지”)부터 확인하는 게 제일 빠릅니다.

9) 운영 팁(최소한만)

• 서버 재시작:

docker restart mc-bedrock

• 서버 종료/시작:

docker stop mc-bedrock
docker start mc-bedrock

• 데이터(월드/설정) 저장 위치:
  • D:\minecraft\bedrock\data\
    이 폴더만 백업하면 됩니다(서버 중지 후 압축 권장).

마무리

정리하면, Windows 11에서 Docker로 BDS 운영은 아래 순서로 끝납니다.

1. Docker Compose로 BDS 실행
2. Windows 방화벽 UDP 19132 허용
3. 안드로이드(같은 와이파이) 접속 확인
4. ipTIME UDP 19132 포트포워딩
5. 안드로이드(모바일 데이터)로 외부 접속 확인

여기까지 되면 “서버가 실제로 운영 가능한 상태”입니다.

게시물 너무나 쉬운 윈도우즈11+docker 이용 베드락 마인크래프트 설치하고 외부에서 접근하여 게임즐기기이 하우인포-IT·테크에 처음 등장했습니다.

저는 미니스포럼 N5 Pro 같은 저전력·고효율 미니PC를 홈서버/NAS 보조 서버로 쓰는 경우가 많은데, 이때 Windows 11 Pro에서 Docker를 가장 쾌적하게 돌리는 방식은 Docker Desktop + WSL 2 백엔드 조합이었습니다.

이 글은 초보자도 그대로 따라 하면 설치가 끝나는 흐름으로 정리했고, 실제로 많이 막히는 오류 해결까지 함께 넣었습니다. (붙여넣기용 완성본)

1) 오늘 설치할 구성 (핵심 요약)

• Windows 11 Pro
• WSL 2 활성화
• Docker Desktop 설치 (WSL 2 백엔드 사용)
• docker run hello-world로 최종 검증
• 오류 발생 시 체크 순서 제공

2) 사전 준비 체크 (여기서 80%가 결정됩니다)

(1) BIOS 가상화(VT-x/AMD-V) 활성화 확인

WSL 2와 Docker는 가상화 기능에 의존합니다.

• BIOS 메뉴에서 아래 항목이 Enabled인지 확인
  • Intel Virtualization Technology (VT-x)
  • 또는 SVM / AMD-V

✅ 증상 힌트

• 가상화가 꺼져 있으면 WSL 설치가 되더라도 Docker가 정상 실행되지 않거나, WSL이 1로 떨어지는 경우가 있습니다.

(2) Windows 기능 켜기 (필수)

시작 메뉴 → “Windows 기능 켜기/끄기” 검색 후 실행, 아래 항목을 체크합니다.

• Linux용 Windows 하위 시스템
• 가상 머신 플랫폼
• (Pro라면 켜두면 좋은 편) Hyper-V

체크 후 [확인] → 재부팅

✅ 포인트

• WSL 2는 “가상 머신 플랫폼”이 꺼져 있으면 정상 동작이 어렵습니다.
• Hyper-V는 WSL 2 백엔드에서도 환경에 따라 도움이 됩니다(특히 회사 PC/보안정책 환경).

3) WSL 2 설치 및 업데이트 (PowerShell 관리자)

PowerShell을 관리자 권한으로 실행합니다.

(1) WSL 설치/업데이트

wsl --install
wsl --update

(2) WSL 기본 버전 2 고정

wsl --set-default-version 2

(3) WSL 상태 확인(선택)

wsl --status
wsl -l -v

✅ 여기서 확인할 것

• wsl -l -v 출력에서 배포판이 보이고, VERSION이 2인지 확인

4) 리눅스 배포판(Ubuntu) 설치 (없으면 반드시)

wsl -l -v에서 배포판이 하나도 없다면 Ubuntu를 설치합니다.

wsl --install -d Ubuntu

설치 후 Ubuntu를 한 번 실행하면 Linux 사용자 이름/비밀번호를 설정하는 단계가 나옵니다.
(비밀번호는 입력해도 화면에 안 보이는 게 정상입니다)

5) Docker Desktop 설치 (WSL 2 백엔드로)

(1) 설치 파일 실행

Docker Desktop Installer.exe 실행

(2) 설치 중 가장 중요한 옵션

설치 과정에서 아래 옵션이 나오면 반드시 체크된 상태로 진행합니다.

• ✅ Use WSL 2 instead of Hyper-V (recommended)

(3) 설치 완료 후 재부팅

설치가 끝나면 Close and restart로 재부팅합니다.

6) Docker Desktop 설정 확인 (WSL 통합)

재부팅 후 Docker Desktop 실행 → Settings에서 확인합니다.

• Settings → Resources → WSL Integration
  • Ubuntu(또는 설치한 배포판)에 대해
  • ✅ Enable integration 켬

✅ 추천

• 배포판이 여러 개라면, 실제 사용할 배포판 하나만 통합 켜두는 게 관리가 편합니다.

7) 설치 확인 테스트 (여기까지 오면 끝)

PowerShell 또는 Windows Terminal에서 실행합니다.

(1) 버전 확인

docker --version

(2) hello-world 테스트

docker run hello-world

아래 문구가 나오면 성공입니다.

• Hello from Docker!

8) 오류 해결 모음 (실제로 제일 많이 막히는 구간)

아래는 “증상 → 원인 → 해결” 순서로 정리했습니다.

오류 1) docker 명령어가 인식되지 않음

증상

• docker : The term 'docker' is not recognized...

원인

• Docker Desktop 설치가 안 되었거나, 재부팅 전 상태이거나, PATH 적용이 안 된 케이스

해결

1. Docker Desktop이 설치되어 있는지 확인
2. 재부팅 1회
3. 그래도 안 되면 Docker Desktop 재설치

오류 2) WSL 2 installation is incomplete

증상

• Docker Desktop 실행 시 WSL 2 커널 관련 경고

원인

• WSL 업데이트/Windows 업데이트 미반영 또는 재부팅 누락

해결

1. PowerShell(관리자) 실행

wsl --update

2. 재부팅
3. Windows Update 최신 상태 확인(선택)

오류 3) wsl -l -v에서 VERSION이 1로 뜸

원인

• 기본 버전이 2로 고정되지 않았거나, 배포판이 1로 생성된 상태

해결

wsl --set-default-version 2
wsl --set-version Ubuntu 2

오류 4) 0x80370102 / “가상 머신 플랫폼” 관련 오류

증상

• WSL 실행/설치 중 가상화 관련 오류 코드 발생

원인

• BIOS 가상화 꺼짐, Windows 기능 미활성화, 보안 기능 충돌

해결 체크 순서

1. BIOS VT-x/AMD-V Enabled
2. Windows 기능: Linux용 Windows 하위 시스템 / 가상 머신 플랫폼 체크
3. 재부팅
4. PowerShell 관리자에서 wsl --update

오류 5) docker run hello-world가 다운로드에서 멈춤

원인

• 회사망/프록시/방화벽/DNS 이슈가 흔함

해결

• 집 인터넷/모바일 핫스팟에서 한 번 테스트
• Docker Desktop의 네트워크/프록시 설정 확인
• 회사 PC라면 보안 정책상 Docker 허용 여부 확인 필요

오류 6) Docker Desktop이 “Starting…”에서 멈춤

원인

• WSL 통합 문제, 배포판 손상, 업데이트 충돌

해결(가벼운 순서)

1. Docker Desktop 종료 후 재실행
2. 재부팅
3. PowerShell 관리자:

wsl --shutdown

4. Docker Desktop 다시 실행
5. 그래도 안 되면 WSL 배포판 재설치 고려(마지막 수단)

9) 설치 후 추천: 홈서버/NAS 운영에 바로 쓰는 기본 명령어

컨테이너 목록 보기

docker ps
docker ps -a

이미지 목록 보기

docker images

컨테이너 중지/삭제

docker stop <컨테이너ID>
docker rm <컨테이너ID>

이미지 삭제

docker rmi <이미지ID>

10) 마무리 (제가 이 구성을 추천하는 이유)

Windows 11 Pro에서 Docker를 운영할 때, Hyper-V 기반으로도 가능하지만
실사용(특히 미니PC/홈서버)에서는 WSL 2 백엔드가 설치·유지보수 난이도가 낮고 안정적인 편이었습니다.

• 개발 환경(리눅스 도구)도 WSL에서 자연스럽게 이어지고
• 컨테이너 운영도 Docker Desktop에서 시각적으로 관리 가능해서
• “홈서버 운영 + 개발” 둘 다 잡기 좋았습니다.

게시물 Windows 11 Pro Docker 설치 가이드 (WSL 2 백엔드) + 오류 해결이 하우인포-IT·테크에 처음 등장했습니다.

• **프로세스(Process)**는 서로 독립된 메모리 공간을 가진 실행 단위입니다.
• **스레드(Thread)**는 같은 프로세스 안에서 메모리를 공유하는 실행 흐름입니다.
• 프로세스는 격리(안전성)가 강점, 스레드는 속도와 자원 효율이 강점입니다.
• 실무에선 보통 “프로세스 여러 개 + 스레드”를 혼합합니다.
• 장애/성능/자원 관점에서 이해하면 튜닝 포인트가 보입니다.

1️⃣ 먼저 상황부터: “왜 갑자기 서버가 전체로 죽었지?”

운영하다 보면 이런 순간이 옵니다.

• 특정 서비스 하나만 느린 게 아니라 전체가 버벅임
• 워커 하나가 죽었는데 전체 서비스가 영향을 받음
• CPU는 널널한데 응답이 밀림

이럴 때 원인을 좁히려면
“이게 프로세스 문제인가? 스레드 문제인가?”를 구분할 줄 알아야 합니다.

2️⃣ 핵심 정의 3개 (딱 필요한 만큼만)

• 프로세스: 운영체제가 관리하는 독립 실행 단위 (주소 공간 분리)
• 스레드: 하나의 프로세스 안에서 실행되는 경량 실행 단위 (메모리 공유)
• 컨텍스트 스위칭: 실행 대상을 바꿀 때 드는 전환 비용 (프로세스가 더 큼)

3️⃣ 한 장으로 보는 차이

4️⃣ 실무에서 가장 많이 보는 구조

예시 A) 웹서버 구조

보통 구조는 이렇습니다.

프로세스 여러 개(워커) + 각 워커 내부 스레드

이유:

• CPU 코어 활용을 위해 프로세스를 여러 개 띄움
• 각 프로세스 안에서 스레드로 동시 요청 처리

예:

• Nginx → 마스터 + 워커 프로세스 구조
• Java 서버 → 프로세스 1개 + 스레드풀 다수
• PHP-FPM → 여러 워커 프로세스

실무 포인트:

• 워커 하나 죽어도 전체는 유지 → 프로세스 격리 효과
• 워커 내부는 스레드로 효율 확보

예시 B) 배치/크롤러

CPU 집중 작업:

• 이미지 처리
• 암호화
• 압축

→ 프로세스가 유리한 경우 많음 (코어 분산 + 격리)

I/O 중심 작업:

• HTTP 요청
• DB 조회
• 파일 읽기

→ 스레드/비동기가 효율적

이 차이를 모르고 구조를 설계하면 CPU를 못 쓰거나, 메모리 폭주가 발생합니다.

예시 C) 워드프레스 + DB 장애

디스크가 꽉 찼던 사례를 보면:

• mysqld → 별도 프로세스
• PHP-FPM → 여러 프로세스
• 웹서버 → 별도 프로세스

그런데 디스크가 100% 차니 전부 오류.

여기서 중요한 교훈:

프로세스 격리는 메모리 관점이고,
디스크/CPU는 공용 자원이다.

프로세스 구조만 믿으면 안 됩니다.
자원 모니터링이 핵심입니다.

예시 D) Docker는 프로세스인가?

Docker는 VM이 아닙니다.

• 호스트 커널 공유
• 내부에서 일반 프로세스/스레드 실행

컨테이너가 죽는다는 건 보통
“그 안의 메인 프로세스가 죽었다”는 뜻입니다.

그래서 PID 1 관리가 중요합니다.

5️⃣ 리눅스에서 바로 확인하는 법

프로세스 보기

ps aux | head

스레드까지 보기

ps -eLf | head

특정 PID 스레드 수

ps -o nlwp= -p <PID>

nlwp = 스레드 수

top에서 스레드 모드

top -H

실무에서는 nlwp가 갑자기 늘어나면
스레드 폭주를 의심합니다.

6️⃣ 선택 기준 (운영 관점)

✔ 안정성이 더 중요하다 → 프로세스 비중 ↑
✔ 처리량/공유 데이터가 중요하다 → 스레드 비중 ↑
✔ 대부분은 “혼합 구조”가 정답

튜닝할 때는 이렇게 봅니다:

• 워커 수 = CPU 코어 활용
• 스레드풀 크기 = 동시성 제한
• 메모리 한계 = 프로세스 수와 직결

7️⃣ 자주 하는 오해

❌ 스레드는 무조건 빠르다
→ 동기화/락 경쟁 심하면 오히려 느려짐

❌ 프로세스면 무조건 안전하다
→ 디스크/CPU는 공유 자원

❌ 컨테이너면 완전 격리다
→ 커널은 공유

8️⃣ 장애 대응 체크리스트

• 특정 프로세스만 죽었나, 전체인가?
• 스레드 수(NLWP)가 비정상적으로 늘었나?
• CPU 코어 대비 워커 수 적절한가?
• 스레드풀 제한 설정했는가?
• 디스크/메모리 같은 공용 자원 병목은 아닌가?

9️⃣ 실무에서 얻은 교훈

프로세스 vs 스레드는 시험 문제가 아니라
“격리와 효율의 균형” 문제입니다.

장애가 났을 때:

• 메모리 격리 문제인가?
• 동기화 문제인가?
• 공용 자원 병목인가?

이 질문이 바로 나오면, 대응 속도가 훨씬 빨라집니다.

FAQ

Q1. 프로세스가 무조건 더 안전한가요?
메모리 격리는 강하지만, 디스크/CPU 병목은 같이 영향을 받습니다.

Q2. 스레드는 왜 위험하다고 하나요?
메모리를 공유하기 때문에 동기화 실수나 메모리 오염이 전체 장애로 번질 수 있습니다.

Q3. 요즘은 비동기가 대세 아닌가요?
맞습니다. 하지만 내부적으로는 여전히 스레드/이벤트 루프 구조 이해가 필요합니다.

게시물 프로세스 vs 스레드 — 실무에서 헷갈림이 줄어드는 기준이 하우인포-IT·테크에 처음 등장했습니다.

Linux 명령어에 익숙해졌다면, 이제 한 단계 올라갈 차례입니다.
요즘 서버 운영, AI, 자동화, NAS 환경에서 빠지지 않는 기술이 바로 Docker입니다.

Docker를 이해하면:

✔ 서버 세팅이 빨라지고
✔ 환경 충돌이 사라지고
✔ 자동화 구성이 쉬워지고
✔ 이식성이 극대화됩니다

이번 글에서는 직접 설치 → 실행 → 컨테이너 운영까지 실습해봅니다.

1️⃣ Docker란 무엇인가?

Docker는 컨테이너 기반 가상화 플랫폼입니다.

기존 가상머신(VM)은 OS를 통째로 올리지만,
Docker는 필요한 실행 환경만 분리해서 올립니다.

👉 가볍고 빠릅니다
👉 서버 운영에 최적화되어 있습니다

2️⃣ Docker 설치 실습 (Ubuntu 기준)

📌 1단계: 패키지 업데이트

sudo apt update

📌 2단계: Docker 설치

sudo apt install docker.io -y

📌 3단계: Docker 실행 확인

docker --version

📌 4단계: Docker 서비스 활성화

sudo systemctl enable docker
sudo systemctl start docker

상태 확인:

sudo systemctl status docker

3️⃣ 첫 번째 컨테이너 실행해보기

📌 Hello World 실행

sudo docker run hello-world

정상이라면 테스트 메시지가 출력됩니다.

👉 이 순간 Docker 엔진이 동작한 것입니다.

4️⃣ Nginx 웹서버 컨테이너 실행 실습

📌 Nginx 실행

sudo docker run -d -p 8080:80 nginx

설명:

• -d : 백그라운드 실행
• -p 8080:80 : 포트 연결
• nginx : 이미지 이름

브라우저에서 접속:

http://서버IP:8080

👉 웹서버가 바로 실행됩니다.

5️⃣ 컨테이너 관리하기

📌 실행 중 컨테이너 확인

docker ps

📌 전체 컨테이너 보기

docker ps -a

📌 컨테이너 중지

docker stop 컨테이너ID

📌 컨테이너 삭제

docker rm 컨테이너ID

6️⃣ Docker 이미지 관리

📌 이미지 목록 확인

docker images

📌 이미지 삭제

docker rmi 이미지ID

7️⃣ 실제 운영 감각 익히기 (중요)

Docker는 단순 실행이 목적이 아닙니다.

운영에서 중요한 개념:

🔹 포트 매핑

외부포트:내부포트

-p 3000:3000

🔹 볼륨 연결 (데이터 보존)

docker run -d -p 8080:80 -v /home/data:/usr/share/nginx/html nginx

👉 컨테이너 삭제해도 데이터 유지

🔹 재부팅 시 자동 실행

docker run -d --restart=always nginx

8️⃣ Docker Compose 기초 (실무 핵심)

Docker를 여러 개 운영하면 docker-compose가 필요합니다.

설치:

sudo apt install docker-compose -y

예시 docker-compose.yml

version: '3'
services:
  web:
    image: nginx
    ports:
      - "8080:80"

실행:

docker-compose up -d

👉 실무에서는 거의 이 방식으로 운영합니다.

📌 Docker를 배우면 생기는 변화

✔ 서버 세팅 시간이 획기적으로 단축
✔ 개발/운영 환경 동일화
✔ 자동화 구성 쉬워짐
✔ NAS 활용도 상승
✔ AI 모델 배포 쉬워짐

Docker는 이제 선택이 아니라 기본입니다.

게시물 Docker 기초 실습 가이드이 하우인포-IT·테크에 처음 등장했습니다.

1. Git: 코드 변경 이력 관리 도구
2. Repository(Repo): 소스코드 저장소
3. Commit: 변경 사항을 기록하는 단위
4. Branch: 작업 분리용 가지
5. Merge: 브랜치 변경 사항 합치기
6. Rebase: 커밋을 다시 정리하며 이력 재배치
7. Conflict: 병합 중 충돌(같은 줄 수정 등)
8. PR/MR: 코드 리뷰 및 병합 요청(Pull/Merge Request)
9. Tag: 특정 버전(릴리즈 지점) 표시
10. Git Flow: 브랜치 운영 전략(예: main/dev/feature)

2) 빌드·패키징·릴리즈 (11~20)

11. Build: 실행 가능한 결과물 생성 과정
12. Artifact: 빌드 결과물(jar, 이미지, zip 등)
13. Dependency: 프로젝트가 필요로 하는 외부 라이브러리
14. Versioning: 버전 관리 규칙(예: 1.2.3)
15. Semantic Versioning(SemVer): MAJOR.MINOR.PATCH 규칙
16. Release: 사용자에게 제공되는 배포 버전
17. Rollback: 문제 발생 시 이전 버전으로 되돌리기
18. Hotfix: 긴급 수정 배포
19. Patch: 소규모 수정(버그/보안 등)
20. Changelog: 버전별 변경 기록

3) CI/CD (21~30)

21. CI(Continuous Integration): 코드 통합/빌드/테스트 자동화
22. CD(Continuous Delivery/Deployment): 배포 자동화(전달/배포)
23. Pipeline: 자동화 작업 흐름(빌드→테스트→배포)
24. Runner/Agent: 파이프라인 작업을 실행하는 실행기
25. Stage/Job: 파이프라인 단계/실행 단위
26. Build Cache: 빌드 속도를 높이는 캐시
27. Artifact Registry: 빌드 결과물 저장소(이미지/패키지)
28. Environment: dev/stage/prod 같은 배포 환경
29. Approval/Gate: 운영 반영 전 승인 단계
30. Blue-Green Deploy: 두 환경 전환으로 무중단 배포

4) 컨테이너·오케스트레이션 (31~40)

31. Container: 실행 환경을 묶은 단위(가볍고 이식성 높음)
32. Docker: 컨테이너 빌드/실행 도구
33. Docker Image: 실행 템플릿(스냅샷)
34. Dockerfile: 이미지 생성 레시피
35. Container Registry: 이미지 저장소(Docker Hub 등)
36. Kubernetes(K8s): 컨테이너 운영 자동화(배치/확장)
37. Pod: K8s의 최소 배포 단위(컨테이너 묶음)
38. Deployment: Pod를 선언적으로 배포/업데이트 관리
39. Service: Pod에 안정적인 접근 주소 제공
40. Ingress: 외부 트래픽을 서비스로 라우팅(HTTP 경로 기반)

5) 인프라·클라우드·운영 (41~50)

41. IaC(Infrastructure as Code): 인프라를 코드로 관리(Terraform 등)
42. Provisioning: 서버/자원 생성 및 초기 구성
43. Configuration Management: 설정 자동화(Ansible 등)
44. Observability: 로그/메트릭/트레이스를 통한 가시성
45. Logging: 이벤트 기록(장애 분석의 핵심)
46. Metrics: 수치 기반 지표(CPU, Memory, QPS 등)
47. Tracing: 요청 흐름 추적(분산 환경에서 필수)
48. Alerting: 이상 징후 알림(PagerDuty, Slack 등)
49. SLA/SLO/SLI: 서비스 약속/목표/지표(신뢰성 관리)
50. Incident Response: 장애 대응 프로세스(탐지→완화→복구→회고)

✅ DevOps에서 특히 자주 나오는 “핵심 세트” 5개

• CI/CD: 자동화의 중심
• Docker/K8s: 배포 단위와 운영 자동화
• IaC: 인프라를 코드로 재현 가능하게
• Observability: 장애를 “빨리 찾고, 빨리 고치기”
• SLO 기반 운영: 목표를 숫자로 관리

게시물 DevOps 필수 용어 50 (DevOps Essentials)이 하우인포-IT·테크에 처음 등장했습니다.

1. Server(서버): 요청을 받고 처리해 응답을 주는 컴퓨터/프로그램
2. Client(클라이언트): 서버에 요청하는 쪽(브라우저, 앱 등)
3. HTTP: 웹 통신 규약(요청/응답의 규칙)
4. HTTPS: TLS로 암호화된 HTTP(보안 강화)
5. Request / Response: 요청 / 응답(백엔드의 기본 흐름)
6. Header / Body: 부가정보 / 실제 데이터(JSON 등)
7. Status Code: 응답 결과 코드(200, 400, 401, 404, 500 등)
8. URI / URL: 자원 식별자 / 자원 위치
9. DNS: 도메인 → IP로 변환하는 시스템
10. Port(포트): 한 서버 안에서 서비스를 구분하는 번호(80, 443 등)

2) API 설계·통신 (11~20)

11. API: 기능을 외부에서 사용하게 하는 인터페이스
12. Endpoint: API 주소(예: /api/users)
13. REST: 자원 중심 설계 스타일(HTTP 메서드 활용)
14. CRUD: Create/Read/Update/Delete(기본 데이터 작업)
15. JSON: 데이터 교환 포맷(가장 흔함)
16. Serialization: 객체 → 전송 가능한 형태(JSON)로 변환
17. Validation: 입력값 검증(보안/품질에 매우 중요)
18. Pagination: 목록을 페이지로 나눠 제공
19. Filtering/Sorting: 조건 검색/정렬(쿼리 파라미터로 구현)
20. Rate Limit: API 호출 횟수 제한(남용/공격 방지)

3) 인증·보안 (21~30)

21. Authentication(인증): “너 누구야?”(로그인 확인)
22. Authorization(인가): “이거 할 권한 있어?”
23. Session(세션): 서버가 로그인 상태를 관리하는 방식
24. Cookie(쿠키): 브라우저가 저장하는 작은 데이터(세션ID 등)
25. Token(토큰): 인증 정보를 담아 전달하는 값
26. JWT: 토큰 형식(서명으로 위변조 방지, stateless에 유리)
27. OAuth 2.0: 외부 로그인/권한 위임 표준(구글 로그인 등)
28. CORS: 다른 출처 요청을 제어하는 브라우저 보안 정책
29. Hash(해시): 되돌릴 수 없는 변환(비밀번호 저장에 사용)
30. Encryption(암호화): 키로 암·복호화 가능한 변환(민감데이터 보호)

4) 데이터베이스(DB) (31~40)

31. DB(Database): 데이터 저장소
32. RDBMS: 관계형 DB(MySQL, PostgreSQL 등)
33. SQL: 관계형 DB 질의 언어
34. NoSQL: 비관계형 DB(MongoDB, Redis 등)
35. Schema(스키마): 테이블 구조(컬럼/타입/제약조건)
36. Index(인덱스): 조회 성능을 올리는 “목차”(쓰기 비용 증가 가능)
37. Transaction(트랜잭션): 여러 작업을 하나로 묶어 처리(롤백 가능)
38. ACID: 트랜잭션의 4대 성질
39. Join: 여러 테이블을 연결해 조회
40. ORM: 객체로 DB를 다루게 해주는 도구(JPA, Hibernate 등)

5) 캐시·메시징·확장 (41~45)

41. Cache(캐시): 자주 쓰는 데이터를 빠르게 저장(성능 개선)
42. Redis: 대표적인 인메모리 캐시/세션/큐 활용 DB
43. Queue(큐): 작업을 순서대로 처리하는 구조
44. Message Broker: 메시지를 중계하는 시스템(RabbitMQ, Kafka 등)
45. Async(비동기): 기다리지 않고 다음 작업 진행(메일 발송/알림 등)

6) 배포·운영(DevOps) (46~50)

46. CI/CD: 빌드·테스트·배포 자동화 파이프라인
47. Container(컨테이너): 실행 환경을 묶어 어디서나 동일 실행
48. Docker: 컨테이너 생성/실행 도구
49. Kubernetes(K8s): 컨테이너 오케스트레이션(배치/스케일링)
50. Monitoring/Logging: 운영 상태 관측/기록(Prometheus, Grafana, ELK 등)

✅ “헷갈리는 핵심 5개” 한 줄 정리

• 인증 vs 인가: 누구냐 / 권한 있냐
• 세션 vs 토큰: 서버가 상태 저장 / 클라가 증명서 들고 다님
• SQL vs NoSQL: 관계형 / 비관계형
• 캐시 vs DB: 빠른 임시 저장 / 원본 저장
• 동기 vs 비동기: 기다림 / 안 기다림

게시물 백엔드 필수 용어 50 (Back-end Essentials)이 하우인포-IT·테크에 처음 등장했습니다.

이럴 때 가장 많이 쓰이는 도구가 바로 Docker입니다.
이 글에서는 Docker가 무엇인지부터
👉 Ubuntu에서 Docker를 설치하고 정상 동작 확인하는 방법까지
초보자 기준으로 차근차근 정리했습니다.

Docker란 무엇인가?

Docker는 **애플리케이션을 컨테이너(Container)**라는 단위로 실행할 수 있게 해주는 도구입니다.

쉽게 비유하면

• 예전 방식:
  👉 프로그램마다 직접 설치 (환경 충돌 잦음)
• Docker 방식:
  👉 프로그램 + 실행 환경을 한 박스에 담아서 실행

그래서 이런 장점이 있습니다.

Docker의 장점

• ✔ 설치/삭제가 매우 간단
• ✔ 서버 환경이 달라도 동일하게 실행
• ✔ 테스트·운영 환경 분리 쉬움
• ✔ 홈서버, NAS, 클라우드 모두 활용 가능

👉 요즘 홈서버, NAS, AI 서버에서 Docker는 거의 필수입니다.

Docker와 가상머신(VM)의 차이

👉 가볍고 빠른 서비스 운영이 목적이라면 Docker가 훨씬 유리합니다.

Docker 설치 전 확인 사항

아래 환경을 기준으로 설명합니다.

• ✔ Ubuntu 20.04 / 22.04 / 24.04
• ✔ sudo 권한 사용자
• ✔ 인터넷 연결

버전 확인:

lsb_release -a

Ubuntu에서 Docker 설치 방법

1️⃣ 기존 패키지 업데이트

sudo apt update
sudo apt upgrade -y

2️⃣ Docker 설치에 필요한 패키지 설치

sudo apt install -y ca-certificates curl gnupg lsb-release

3️⃣ Docker 공식 GPG 키 추가

sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

4️⃣ Docker 공식 저장소 추가

echo \
"deb [arch=$(dpkg --print-architecture) \
signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

5️⃣ Docker 엔진 설치

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Docker 정상 설치 확인

버전 확인

docker --version

정상이라면 아래처럼 출력됩니다.

Docker version XX.X.X, build XXXXX

테스트 컨테이너 실행

sudo docker run hello-world

✔ 정상 출력되면 Docker 설치 완료입니다.

sudo 없이 Docker 사용하기 (중요)

매번 sudo 붙이기 귀찮다면 사용자 권한을 추가합니다.

sudo usermod -aG docker $USER

적용을 위해 로그아웃 후 재로그인 또는 재부팅하세요.

확인:

docker ps

Docker Compose란?

Docker Compose는
👉 여러 개의 컨테이너를 한 번에 관리하기 위한 도구입니다.

예를 들면:

• 웹서버 + DB
• AI 서버 + API
• 홈서버 서비스 묶음

지금 설치한 Docker에는 Compose 플러그인이 이미 포함되어 있습니다.

확인:

docker compose version

Docker를 어디에 활용할 수 있을까?

Docker는 이런 곳에 특히 많이 쓰입니다.

• ✔ 홈서버 / NAS 서비스 운영
• ✔ 웹서버 (WordPress, Nginx)
• ✔ AI 서버 (Whisper, Stable Diffusion 등)
• ✔ 자동화 도구 (n8n, Home Assistant)
• ✔ 테스트 환경 구성

👉 한 번 익혀두면 서버 운영 난이도가 확 내려갑니다.

마무리 정리

• Docker는 환경 충돌 없이 서비스 실행을 가능하게 해주는 도구
• Ubuntu에서는 공식 저장소 설치가 가장 안정적
• sudo 없이 사용 설정하면 훨씬 편리
• Docker Compose까지 익히면 서버 관리가 쉬워짐

게시물 🐳 Docker 설치 방법 (Ubuntu 기준) – Docker 개념부터 설치까지 한 번에 정리이 하우인포-IT·테크에 처음 등장했습니다.