- 프로필과 역할을 기준으로 Docker Compose를 구성하면 수십 개의 서비스를 사용하는 홈랩 관리가 간소화됩니다.
- .env 파일에 설정을 중앙 집중화하고, 오버라이드 기능을 사용하며, Git을 통해 버전 관리를 하면 환경을 이식성이 뛰어나고 마이그레이션이 용이해집니다.
- 전용 네트워크, Traefik 및 상태 점검은 서비스의 안전성, 격리 및 복원력을 향상시킵니다.
- 모니터링, 관리형 로그, 자동 백업 기능을 통해 홈랩은 장기적으로 안정적인 플랫폼이 됩니다.
컨테이너를 이용한 최신 홈랩 구축은 많은 IT 전문가들의 인기 취미가 되었습니다. Docker Compose는 이러한 구축의 핵심 요소로 , YAML 형식으로 서비스를 정의하고, Git으로 버전 관리를 하고, 단 하나의 명령어로 전체 환경을 시작할 수 있도록 해줍니다.
하지만 규모가 커지면 상황이 달라집니다. 컨테이너 두세 개에서 수십 개의 서비스, 내부 네트워크, 리버스 프록시, 데이터베이스, CI 실행기 등 으로 확장하게 되죠 . 이때 중요한 질문이 떠오릅니다. 하나의 거대한 Docker Compose 인스턴스를 사용할 것인가, 아니면 여러 개의 작은 파일로 관리할 것인가? 프로필, 네트워크, 백업, 보안을 어떻게 구성하고, 더 나아가 마이그레이션을 어떻게 용이하게 할 것인가?
실제 환경에서 홈랩을 구축하기 위한 Docker Compose 설정 방법
실제로 홈랩을 오랫동안 사용해 온 사람들은 일반적으로 각각 장단점이 있는 세 가지 Compose 구성 모델을 사용합니다. 적절한 접근 방식을 선택하면 규모를 확장하거나 새로운 장비로 마이그레이션할 때 많은 어려움을 피할 수 있습니다.
한편으로는 Docker Run 명령어를 단독으로 사용하다가 Portainer로 넘어갔고, 최종적으로 Docker Compose로 넘어간 사람들이 있습니다 . 이는 흔한 시나리오입니다. Portainer는 뛰어난 가시성, 사용자 친화적인 인터페이스, 템플릿 등을 제공하지만, 결국 파일에 아무런 정보가 없다면 복잡한 매개변수를 편집하거나 구성을 마이그레이션하는 것이 번거로워집니다.
정반대의 극단에는 리버스 프록시, 미디어, 유틸리티, 모니터링, LLM, 데이터베이스 등 홈랩의 모든 서비스를 실행할 수 있는 단일 "메가" docker-compose.yml 파일로 모든 것을 통합한 사람이 있습니다 . 이 모든 것이 단일 스택에 포함되어 있습니다.
그 중간 단계에서 많은 사용자는 컨텍스트별(예: 미디어, 인프라, 생산성, 모니터링)로 그룹화된 여러 개의 작은 docker-compose.yml 파일을 사용하는 혼합 방식을 고수합니다. 이 파일들은 모두 동일한 저장소 아래에 있으며 일반적으로 전역 환경 변수를 공유합니다.
상당히 세련된 해결책은 두 가지 방식을 결합하는 것입니다. 바로 다른 파일들(각각 앱이나 서비스의 하위 폴더에 있음)을 포함하는 "루트" docker-compose 파일을 만드는 것입니다 . 이렇게 하면 홈랩 전체를 한눈에 볼 수 있으면서도 읽기 힘든 수천 줄짜리 YAML 파일을 다룰 필요가 없습니다.
프로필, 기능별 그룹화 및 대규모 홈랩
홈랩에 30개, 40개, 50개에 달하는 서비스 (데이터베이스, 캐시, 인덱서와 같은 백업 서비스 포함) 가 생기면 , 이러한 서비스들을 체계적으로 관리하는 것이 매우 중요합니다. 이때 기능별 그룹화 와 Docker Compose 프로필 사용이 유용하게 활용됩니다.
가장 흔한 패턴은 모든 것을 하나의 Compose "프로젝트"로 묶되, 프로필별로 논리적으로 구분하는 것입니다. 예를 들면 다음과 같습니다.
- 핵심 프로필홈랩 코어는 Traefik을 리버스 프록시로 사용하고, ID 공급자(예: OAuth 또는 Authentik)를 통해 동일 도메인 내의 모든 앱을 HTTPS로 인증합니다.
- 미디어 프로필Plex, Sonarr, Radarr, Ombi, SABnzbd 또는 qBittorrent와 같은 서비스는 멀티미디어 콘텐츠를 선별, 다운로드 및 제공하는 역할을 합니다.
- 유틸리티 프로필컨테이너 및 업데이트를 관리하고 모니터링하기 위한 Portainer, Watchtower(사용하는 경우), Diun, dockcheck 또는 이와 유사한 도구.
- 인프라/모니터링 프로필Traefik, cAdvisor, Prometheus, Grafana, Uptime Kuma, Dozzle 등 모니터링 및 로깅 관련 모든 도구.
- 실험 프로필 또는 LLM: LLM 또는 특이한 앱(ChatGPT Next Web local, LibreOffice Online 등)에 대한 특정 스택으로, 일반적으로 기본적으로 비활성화되어 있습니다.
프로파일링의 가장 큰 장점은 필요에 따라 인프라의 일부만 배포할 수 있다는 것입니다 . 예를 들어, 저전력 미니 PC에는 코어 및 인프라 프로파일만 실행하고, 디스크와 GPU가 더 많은 대형 서버에는 미디어 프로파일만 배포할 수 있습니다.
잘 설계된 저장소에서는 일반적으로 루트에 `include` 구문을 사용하여 개별 파일을 `apps/` 또는 `services/` 폴더로 푸시하는 "마스터" `docker-compose.yml` 파일이 있습니다 . 또한 거의 모든 서비스는 단일 전역 `.env` 파일을 통해 구성되고 일부 비밀 정보는 `secrets/` 디렉터리에 저장되어 초기 설정이 크게 간소화됩니다.
이러한 방식을 따르면 홈랩 관리는 기본적으로 .env 파일과 시크릿을 편집하고, 프로필을 활성화 또는 비활성화하고, 각 호스트에서 시작할 서비스를 결정하는 것으로 요약 됩니다 . 이는 여러 대의 머신에 동일한 애플리케이션 세트를 배포하려는 경우에 이상적입니다.
하나의 거대한 docker-compose 파일 vs. 여러 개의 작은 파일
이것은 영원한 논쟁입니다. 모든 것을 담는 하나의 docker-compose.yml 파일을 사용할 것인가, 아니면 서비스/스택별로 여러 개의 파일을 사용할 것인가? 실제 답은 대개 "마이그레이션의 단순성을 우선시하느냐, 아니면 서비스별 명확성을 우선시하느냐에 따라 다르다"입니다.
단일 마스터 파일 사용을 옹호하는 사람들은 일반적으로 다음과 같은 몇 가지 장점을 강조합니다.
- 호스트 마이그레이션은 매우 쉽습니다.저장소를 복제하고, .env 파일과 비밀 키를 복사하고, 볼륨을 마운트한 다음 `docker compose up -d`를 실행하면 됩니다. 디렉토리별로 이동할 필요가 없습니다.
- 진실의 코드로서의 인프라홈랩의 전체 토폴로지(서비스, 네트워크, 볼륨, 종속성)가 한 곳에 있습니다.
- 중앙 집중식 업데이트이미지 버전, 재부팅 정책 또는 로깅을 변경할 때 정확히 어디를 수정해야 하는지 알 수 있습니다.
하지만 YAML 방식에는 분명한 단점도 있습니다. 방대한 YAML 파일은 유지 관리가 어려워지고, 병합 충돌이 증가하며, 특정 문제를 디버깅할 때는 수백 줄에 달하는 복잡한 코드를 헤쳐나가야 합니다. 모든 것이 너무 커져버리면 후회하는 마음이 드는 것도 드문 일이 아닙니다.
다른 방법은 다음과 같은 구조로 앱별 또는 논리적 스택별로 docker-compose.yml 파일을 만드는 것입니다.
docker/
├── bookstack/
│ └── docker-compose.yml
├── dashy/
│ └── docker-compose.yml
└── traefik/
└── docker-compose.yml
이렇게 하면 각 컨테이너에 bookstack-app-1 또는 traefik-reverse-proxy-1 과 같은 이름이 지정되어 문제를 신속하게 찾을 수 있습니다. 예를 들어 bookstack-app-1 컨테이너가 충돌하면 어떤 폴더를 확인해야 하는지 정확히 알 수 있습니다.
시각적으로 훨씬 깔끔하고 각 서비스를 독립적으로 관리할 수 있습니다 (다른 서비스에 영향을 주지 않고 시작, 중지 또는 업데이트). 또한 Dozzle과 같은 애플리케이션은 별도의 스택을 활용하여 로그를 더욱 체계적으로 관리합니다.
단점은 모든 것을 너무 분리하면 Traefik이나 공유 네트워크와 같은 공통 서비스 간의 조정에 더 많은 주의가 필요하다는 것입니다 . 외부 네트워크를 선언하고, 특정 Traefik 레이블을 지정하고, 다른 docker-compose에서 생성된 네트워크의 명명법을 기억해야 합니다.
.env 파일, 오버라이드 및 버전 관리에 대한 모범 사례
가장 과소평가되는 팁 중 하나는 .env 파일에 설정을 중앙 집중화하는 것 입니다 . docker-compose.yml 파일에 환경 변수를 잔뜩 넣는 대신 다음과 같이 정의하면 됩니다.
DB_USERNAME=myuser DB_PASSWORD=secretpassword
그리고 YAML 파일에서는 ${DB_USERNAME} 또는 ${DB_PASSWORD} 와 같이 참조됩니다 . 이렇게 하면 Compose 코드를 한눈에 쉽게 읽을 수 있고, 여러 서비스 간에 변수를 공유 할 수 있으며 , 가장 중요한 것은 비밀번호를 별도의 파일에 저장하여 Git에서 제외할 수 있다는 점입니다.
다양한 환경(프로덕션, 테스트, 개발)에서 사용할 때는 docker-compose.override.yml 파일을 활용하는 것이 매우 유용합니다 . 기본 docker-compose.yml 파일을 만들고, 오버라이드 파일에서 포트, 경로, 디버그 플래그 등 변경해야 할 부분만 수정하는 방식입니다.
예를 들어 개발 환경에서는 다른 포트를 노출하고, 디버깅을 활성화하고, 로컬 소스 코드를 마운트하는 오버라이드 버전을 로드할 수 있습니다 . 메인 YAML 파일은 건드리지 않고, 실행 환경에 맞게 스택을 조정하는 것입니다.
당연히, 홈랩을 조금이라도 전문적으로 운영하고 싶다면 Git을 사용하여 모든 것을 버전 관리하는 것은 필수적입니다 . 일반적으로 다음과 같은 구조를 갖게 될 것입니다.
homelab-docker/ ├── docker-compose.yml ├── .env.example ├── services/ │ ├── media/ │ ├── infra/ │ └── ... └── scripts/
그다음에는 저장소를 초기화하고, 인프라 변경 사항을 커밋하고, 문제가 발생하면 몇 초 만에 이전 버전의 Compose로 되돌릴 수 있습니다 . 야심찬 홈랩을 구축하려는 경우, 이는 선택 사항이 아니라 혼란을 피할 수 있는 유일한 방법입니다.
네트워크, Traefik 및 보안 서비스 노출
중급 수준의 홈랩에서는 거의 대부분 Traefik을 리버스 프록시로 사용하고 중앙 집중식 ID 공급자(Auth 또는 Authentik)를 사용하는 조합이 일반적입니다 . 이를 통해 여러 앱을 HTTPS 및 SSO를 사용하여 서브도메인으로 노출할 수 있습니다.
일반적인 접근 방식은 Traefik과 외부에서 제공할 모든 웹 서비스가 연결되는 reverse_proxy 또는 이와 유사한 전용 Docker 네트워크를 설정하는 것입니다 . 나머지 컨테이너(데이터베이스, 캐시 등)는 격리된 내부 네트워크에 유지됩니다.
Traefik을 사용하고 서비스를 여러 Docker Compose 인스턴스로 분리하는 경우, 공유 외부 네트워크를 정의 해야 합니다 . 예를 들면 다음과 같습니다.
services:
bookstack:
image: lscr.io/linuxserver/bookstack
networks:
- traefik-net
labels:
- "traefik.docker.network=traefik_default"
networks:
traefik-net:
name: traefik_default
external: true
여기서 traefik_default 네트워크는 Traefik 스택에 의해 생성되며, 다른 서비스들은 traefik-net이라는 외부 네트워크를 통해 이 네트워크에 추가됩니다. 레이블은 Traefik에게 트래픽 라우팅에 사용할 네트워크를 알려줍니다.
단일 스택에 백엔드 서비스(예: 웹 컨테이너와 데이터베이스)가 포함된 경우, 이러한 서비스들을 공유 기본 네트워크에 연결하고 웹 컨테이너에만 Traefik 네트워크에 대한 접근 권한을 부여 할 수 있습니다 . 데이터베이스에는 `traefik.enable=false`라는 레이블이 설정되어 Traefik이 이를 무시하도록 합니다.
이러한 설정 방식은 서비스 간 격리와 제어된 노출 이라는 두 가지 주요 이점을 제공합니다 . Traefik 레이블이 지정되고 프록시 네트워크에 있는 컨테이너만 외부에서 접근할 수 있습니다.
데이터 영속성, 볼륨 및 디스크 구조
영구 데이터가 없는 홈랩은 그다지 유용하지 않습니다. 데이터베이스, 설정 파일, 미디어, 문서 등 모든 것이 Docker Compose Down 명령이 실행되더라도 손상되지 않고 유지되어야 합니다. 볼륨과 바인드 마운트는 이러한 작업을 위한 생명줄입니다.
많은 사람들이 다음과 같은 구조를 이용하여 수납공간을 정리합니다.
/mnt/storage/
├── downloads/
│ ├── movies/
│ └── tv/
├── media/
│ ├── movies/
│ ├── tv/
│ └── music/
└── srv/
└──
핵심은 다운로더(qBittorrent, SABnzbd 등)는 다운로드 폴더만 볼 수 있고 , Radarr/Sonarr 같은 파일 관리 프로그램은 다운로드 폴더와 미디어 폴더 모두에 접근하여 하드 링크를 이동/생성할 수 있으며, Plex나 Jellyfin 같은 서버는 미디어 폴더만 볼 수 있다는 것입니다.
이렇게 하면 최소 권한 원칙이 적용됩니다 . 각 컨테이너는 실제로 필요한 것에만 접근할 수 있습니다. 또한 명확한 분리는 클라우드 또는 외장 드라이브에 백업할 볼륨이나 경로를 결정할 때도 도움이 됩니다.
srv 디렉터리는 일반적으로 애플리케이션 구성(예: /srv/jellyfin/config, /srv/traefik, /srv/paperless 등)을 저장하는 데 사용됩니다. 일반적으로 템플릿, Caddyfile 등은 부분적으로 버전 관리되지만, 중요하거나 리소스 집약적인 파일은 제외됩니다.
경우에 따라 다운로드 체인에 하드 링크를 사용하는 것이 유용할 수 있습니다 . Radarr나 Sonarr 같은 서비스는 다운로드한 파일을 링크하여 디스크 공간을 중복 사용하지 않고도 시딩을 유지할 수 있습니다. TRaSHGuides와 같은 가이드에서 제안하는 디렉토리 구조는 바로 이러한 원칙에 기반합니다.
GitHub Actions와 로컬 러너를 사용하여 배포 자동화
더 나아가고 싶다면 CI/CD를 사용하여 홈랩 업데이트를 자동화 할 수 있습니다 . 여러 사용자가 Jenkins와 같은 도구를 GitHub Actions와 홈랩 자체에 호스팅된 러너를 사용하는 워크플로로 대체했습니다.
이 메커니즘은 간단합니다. 홈랩 저장소의 메인 브랜치에 푸시할 때마다 GitHub Actions 워크플로가 실행되어 테스트와 린터를 수행하고, 모든 것이 순조롭게 진행되면 변경 사항을 서버에 배포합니다.
일반적인 워크플로는 다음과 같은 단계를 포함합니다.
- Gitleaks 유형의 비밀 스캐너혹시 실수로 비밀번호나 토큰을 저장소에 업로드했을 경우를 대비한 것입니다.
- 보풀 읽기 쉽고 일관된 형식을 유지하기 위해 YAML 또는 인프라 코드를 사용합니다.
- 홈랩 내 저장소 업데이트대상 서버에서 `git pull`을 실행합니다.
- 컨테이너의 제어된 재구성기존 프로세스를 중지하고 새 프로세스를 시작한 다음 상태를 확인합니다.
장점: 보안 강화(비밀 정보 유출 방지), 코드 품질 향상, 단일 푸시로 반복 배포 가능 . 또한 로컬 러너를 사용하므로 이미지와 볼륨이 네트워크를 벗어나지 않고 GitHub 인터페이스를 통해 파이프라인을 시각화할 수 있습니다.
Docker Compose가 홈랩 운영을 훨씬 편리하게 만들어주는 이유
많은 사람들이 Docker Run과 Portainer 에 수년간 의존해 왔지만 , 장애 발생이나 마이그레이션 이후에는 접근 방식을 재평가해야만 했습니다. 호스트에 장애가 발생하거나 서비스를 다른 머신으로 이전해야 할 때, Portainer 내의 개별 명령이나 구성에만 의존하는 것은 함정입니다.
Compose로 전환했을 때 가장 큰 차이점은 전체 서비스 정의가 텍스트로 작성된다는 것입니다 . 볼륨, 포트, 네트워크, 레이블, 변수 등 모든 것이 복사, 공유, 버전 관리 및 재사용이 가능한 YAML 파일에 저장됩니다.
서비스 편집은 더 이상 "수동으로 컨테이너를 다시 빌드"하는 방식이 아닙니다. 이제 파일에서 한 줄만 수정하고 저장한 다음 `docker compose up -d`를 실행하면 됩니다 . 원래 명령어를 기억하거나 여러 Portainer 화면을 클릭할 필요가 없습니다.
또한, 여러 서버(미니 PC, NAS, 데스크톱)를 사용하는 경우, 동일한 Compose 파일을 다른 컴퓨터로 복사하고 네 가지 경로만 조정하면 다른 하드웨어에서 동일한 스택을 실행할 수 있다는 점이 매우 편리합니다 . 실제로 많은 사용자들이 데이터 손실이나 혼란스러운 마이그레이션과 같은 문제를 겪은 후 Compose 덕분에 이후 복구 과정에서 많은 시간을 절약할 수 있었다고 인정합니다.
추가적인 이점으로, 기존 서비스를 기반으로 새로운 서비스를 구축하는 것이 매우 간단해집니다. 예를 들어, 동일한 미디어 경로와 트랜스코딩 장치를 재사용하여 Plex 구성을 복제하고 Jellyfin을 설정하는 데는 YAML 블록을 복사하는 방식으로 단 몇 분밖에 걸리지 않습니다.
최적화: 빌드 컨텍스트, 다단계 빌드 및 리소스
대부분의 홈랩 컨테이너는 공개 이미지를 사용하지만, 경우에 따라 직접 컴파일해야 할 수도 있습니다. 이러한 경우 빌드 컨텍스트 를 관리하는 것이 중요합니다 . 전체 저장소를 필터링 없이 업로드하지 말고, 강력한 `.dockerignore` 지시문을 사용하여 프로젝트 폴더만 업로드하도록 제한하면 빠르고 가벼운 빌드를 보장할 수 있습니다.
또 다른 매우 유용한 기술은 Dockerfile에서 다단계 빌드를 사용하는 것입니다 . 첫 번째 단계에서는 종속성을 설치하고 컴파일하고, 두 번째 단계에서는 필요한 아티팩트만 작은 기본 이미지에 복사합니다. 결과적으로 불필요한 툴체인이나 라이브러리가 포함되지 않으므로 최종 이미지가 훨씬 작고 안전해집니다 .
Docker Compose를 사용하면 CPU 및 RAM 제한을 정의할 수 있습니다 (특히 Swarm 환경이나 Docker가 해당 매개변수를 준수하는 경우). 이를 통해 리소스 집약적인 앱이 리소스를 과도하게 사용하는 것을 방지할 수 있습니다. 홈랩 환경에서는 이러한 기능을 통해 잘못 구성된 서비스가 시스템 전체에 악영향을 미치는 것을 막을 수 있습니다.
재시작 정책 (재시작: 항상, 중지되지 않을 때, 장애 발생 시) 을 잊지 마세요 . 이러한 정책을 통해 중요한 서비스(리버스 프록시, VPN, 주요 데이터베이스)가 재부팅이나 일회성 장애 발생 후 자동으로 재시작되도록 할 수 있습니다.
마지막으로, docker image prune, docker container prune, docker volume prune과 같은 명령어를 사용하여 주기적인 정리 작업을 예약하는 것이 좋습니다. 이렇게 하면 이전 빌드의 잔여물, 중지된 컨테이너 또는 사용되지 않는 볼륨을 제거하여 디스크 공간을 확보할 수 있습니다.
의료 서비스, 기록 및 모니터링
홈랩이 블랙박스가 되는 것을 방지하려면 세 가지 핵심 요소, 즉 상태 점검, 제어된 로깅 및 모니터링 에 집중해야 합니다 . Docker Compose를 사용하면 `curl -f http://localhost`와 같은 명령이나 특정 스크립트를 사용하여 서비스별로 컨테이너의 정상 상태를 확인하는 상태 점검을 선언할 수 있습니다.
이를 통해 "정상적인" 컨테이너만 트래픽 (예: Traefik을 통해)을 수신하도록 하고, 응답이 중단될 경우 구성된 정책에 따라 재시작되도록 할 수 있습니다. 이는 최소한의 노력으로 시스템 복원력을 크게 향상시킵니다.
로그와 관련하여, JSON 파일 드라이버에 최대 크기 및 최대 파일 제한을 설정하면 디스크에 수 기가바이트에 달하는 방대한 로그 파일이 쌓이는 것을 방지할 수 있습니다. Dozzle과 같은 웹 도구를 사용하면 브라우저에서 모든 컨테이너의 로그를 탐색할 수 있어 특정 서비스를 디버깅하는 데 매우 편리합니다.
메트릭 및 지속적인 모니터링을 위한 대표적인 조합은 cAdvisor + Prometheus + Grafana 입니다 . cAdvisor는 컨테이너별 CPU, 메모리, 디스크 및 네트워크 사용량 통계를 제공하고, Prometheus는 이러한 통계를 주기적으로 수집하며, Grafana는 보기 좋은 대시보드에 표시하고, 특정 항목에서 급증이 발생하면 알림을 보냅니다.
잘 구성된 홈랩에는 일반적으로 가용성 점검 (HTTP, ICMP, TCP 등)을 위한 Uptime Kuma와 중요 데이터를 다른 디스크나 클라우드에 복사하는 Duplicati와 같은 자동 백업 시스템이 포함됩니다. 이렇게 하면 시스템 상태를 파악할 수 있고, 문제가 발생하더라도 중요한 데이터를 잃지 않을 수 있습니다.
홈랩의 보안 및 원격 접속
어떤 방식으로 설정하든 보안은 선택 사항이 아닙니다. 많은 사람들 이 NAS 또는 NAS의 서비스를 외부 세계에 직접 노출하지 않고 VPN을 통해 원격 액세스를 제한합니다(WireGuard는 성능과 간편함 덕분에 매우 인기 있는 옵션입니다).
이 모델에서 라우터는 게이트웨이 역할을 합니다. VPN 서버에는 임의의 포트만 열리고, 연결되면 내부 서비스에 대한 모든 요청은 암호화된 터널을 통해 전달됩니다 . Traefik이나 앱은 이러한 사전 필터링 없이는 인터넷에 노출되지 않습니다.
VPN을 직접 관리하고 싶지 않은 사람들은 포트 개방 없이 홈 랩에 접속하기 위해 클라우드플레어 터널이나 테일스케일을 이용하기도 합니다. 이러한 서비스는 편리하지만, 개인 정보 보호가 최우선이라면 이러한 제3자가 수집할 수 있는 메타데이터에 대해 고려해야 합니다.
또 다른 좋은 방법은 서버와 NAS 디스크를 암호화하고 , 패치를 정기적으로 적용하며, 자동 업데이트를 제한하는 것입니다(많은 사람들이 Watchtower 대신 수동으로 업데이트를 제어합니다). 업데이트 때문에 홈랩의 절반이 망가지는 것보다는 조금 뒤처지더라도 업데이트를 제어할 수 있는 것이 훨씬 낫습니다.
보시다시피, "엔터프라이즈" 수준까지 도달할 필요는 없지만, 홈랩이 보안에 취약하거나 끊임없이 불안감을 조성하는 곳이 되지 않도록 최소한의 보안 및 관리 수준을 확립하는 것이 좋습니다 .
결론적으로, Docker Compose를 사용하여 제대로 된 홈랩을 구축하는 것은 체계성, 상식, 그리고 실험 정신의 조합입니다. 서비스를 그룹화하고, 네트워크를 잘 정의하고, Git에 문서를 기록하고, 약간의 자동화를 적용하면 단 하나의 명령으로 시작할 수 있고, 다른 머신으로 쉽게 마이그레이션할 수 있으며, 통제 불가능한 정글처럼 되지 않고 조금씩 확장할 수 있는 환경을 만들 수 있습니다.