Loading Services...

도커컴포즈 관리스크립트 | Nuuthang

📚 워드프레스 개발 환경 자동화 마스터 청사진 (Docker & Shell Script)

💡 상황 해독

현재 상태: 새로운 워드프레스 프로젝트를 시작할 때마다, 매번 docker-compose.yml 파일을 수동으로 복사하고, 컨테이너 이름, 포트 번호, 폴더 경로 같은 것들을 일일이 손으로 고쳐주고 있습니다.
핵심 쟁점:
반복 작업: 똑같은 일을 계속 반복하느라 시간이 낭비됩니다.
사람의 실수: 포트 번호를 잘못 적거나, 이름을 오타내는 등 실수가 발생할 위험이 큽니다.
비일관성: 프로젝트마다 설정이 조금씩 달라져서 나중에 관리하기가 헷갈립니다.
선택의 부재: 레디스(캐시 서버)처럼 어떤 프로젝트에는 필요하고 어떤 프로젝트에는 필요 없는 기능을 유연하게 넣고 빼기가 어렵습니다.
예상 vs 현실:
예상: "도커 쓰면 그냥 명령어 한 줄로 새 프로젝트 뚝딱 만들어지는 거 아니었어?"
현실: 실제로는 새 프로젝트를 만들 때마다 설정 파일을 열어서 여러 곳을 고쳐야 하는 '숨겨진 수작업'이 계속 발생하고 있습니다.
영향 범위: 이 문제는 단순히 '조금 귀찮은 것'에서 그치지 않습니다. 프로젝트 개수가 늘어날수록, 사소한 실수 하나가 전체 개발 서버를 멈추게 하거나, 다른 프로젝트의 데이터를 덮어쓰는 심각한 사고로 이어질 수 있습니다. 개발 속도가 느려지는 것은 물론, 안정성까지 위협받습니다.

🔍 원인 투시

근본 원인: '프로젝트의 공통적인 뼈대(템플릿)'와 '프로젝트마다 달라지는 개성(설정값)'을 분리하지 않고, 하나의 파일 안에서 모두 관리하고 있기 때문입니다.
연결 고리:

모든 설정이 docker-compose.yml 파일 하나에 '하드코딩(Hard-coding)'되어 있습니다.
새 프로젝트를 만들려면 이 파일을 통째로 복사할 수밖에 없습니다.
복사된 파일은 이전 프로젝트의 설정(이름, 포트 등)을 그대로 담고 있습니다.
이 값들을 새 프로젝트에 맞게 직접 수정해주지 않으면 충돌이 발생합니다.
이 수작업 과정에서 실수가 생기고, 비일관성이 누적됩니다.

일상 비유:

붕어빵 틀: 지금 상황은 붕어빵을 만들 때마다 붕어빵 틀 자체를 매번 새로 조각하는 것과 같습니다. 우리는 '붕어빵 틀(템플릿)'은 그대로 두고, 안에 넣는 '팥소나 슈크림(설정값)'만 바꾸고 싶습니다.
계약서 양식: 매번 새로운 계약을 할 때마다 계약서 전체를 처음부터 타이핑하는 것과 같습니다. 똑똑한 사람은 '계약서 양식(템플릿)'을 만들어두고 '갑', '을', '계약 금액(설정값)'만 빈칸에 채워 넣습니다.
편지 봉투: 여러 사람에게 편지를 보낼 때, 봉투마다 보내는 사람 주소를 매번 손으로 쓰는 것과 같습니다. '보내는 사람 주소 스티커(템플릿)'를 미리 인쇄해두면 훨씬 빠르고 정확합니다.

숨겨진 요소:
'지금 당장'의 편리함: 파일을 복사해서 몇 군데만 고치는 것이 '지금 당장은' 가장 빨라 보이기 때문에, 이 방식이 계속 유지됩니다.
자동화의 초기 비용: 자동화 스크립트를 만드는 것은 처음에는 시간이 더 걸립니다. 이 초기 투자 비용을 부담스러워해서 근본적인 해결을 미루게 됩니다.
기술의 선택적 적용: 레디스처럼 '좋은 기술'이라고 해서 모든 곳에 무조건 적용하는 것이 능사가 아니라는 점을 간과하기 쉽습니다. 각 프로젝트의 특성에 맞게 기술을 선택적으로 적용할 유연한 시스템이 필요합니다.

🛠️ 해결 설계도

[1단계: 뼈대와 살 분리하기 - 템플릿과 설정 파일 만들기]

핵심 행동: 모든 프로젝트의 공통 구조(뼈대)가 될 wp-template 디렉터리를 만들고, 프로젝트별 개별 정보(살)는 template.env 라는 설정 파일에 따로 보관합니다.
실행 가이드:

wp-template 라는 새 폴더를 만듭니다.
wp-template 안에 docker-compose.yml, wordpress.ini 등 공통 파일을 넣습니다.
docker-compose.yml 안의 모든 고정값(예: container_name: wp-uncle-wordpress, ports: - "8054:80")을 변수(예: container_name: ${PROJECT_NAME}-wordpress, ports: - "${WORDPRESS_PORT}:80")로 바꿉니다.
이 변수들의 기본값을 wp-template/template.env 파일에 정의합니다.

성공 지표: docker-compose.yml 파일에는 더 이상 특정 프로젝트의 이름이나 포트 번호 같은 고유 정보가 남아있지 않고, 오직 ${...} 형태의 변수만 존재합니다.
예시/코드:

// 변경 전 (wp4-uncle/docker-compose.yml)
services:
  wordpress:
    container_name: wp-uncle-wordpress
    ports:
      - "8054:80"

// 변경 후 (wp-template/docker-compose.yml)
services:
  wordpress:
    container_name: ${PROJECT_NAME}-wordpress
    ports:
      - "${WORDPRESS_PORT}:80"
      
// 변경 후 (wp-template/template.env)
PROJECT_NAME=myproject
WORDPRESS_PORT=8080

// 핵심 변화 설명
// 특정 값("wp-uncle-wordpress", "8054")을 추상적인 변수(${PROJECT_NAME}, ${WORDPRESS_PORT})로 대체했습니다.
// 실제 값은 .env 파일이 결정하도록 역할을 위임했습니다.

주의사항: .env 파일은 민감한 정보를 담을 수 있으므로 .gitignore에 추가하여 Git 저장소에 올라가지 않도록 하는 것이 좋습니다. (우리는 template.env로 만들어서 이 문제를 회피했습니다.)

[2단계: 자동 조립 로봇 만들기 - 대화형 생성 스크립트 작성]

핵심 행동: 템플릿을 복사하고, 사용자에게 질문을 던져 .env 파일을 자동으로 채워주는 셸 스크립트(create_project.sh)를 만듭니다.
실행 가이드:

create_project.sh 파일을 생성합니다.
스크립트는 사용자에게 "새 프로젝트 이름은 무엇인가요?"라고 질문합니다.
기존에 사용된 포트 번호(used_ports.log)를 확인해서, 겹치지 않는 새 포트 번호를 자동으로 제안합니다.
template.env에 있는 기본값들을 보여주며 다른 설정들도 질문합니다.
모든 질문이 끝나면, 사용자의 답변을 모아 새 프로젝트 폴더 안에 .env 파일을 생성해줍니다.

성공 지표: ./create_project.sh 명령어 하나만 실행하면, 어떤 파일도 수동으로 수정할 필요 없이 완벽하게 설정된 새 프로젝트 폴더가 생성됩니다.
예시/코드:

// 변경 전 (수작업)
$ cp -r wp4-uncle wp6-new-project
$ nano wp6-new-project/docker-compose.yml  # 열어서 5~6곳 수정

// 변경 후 (자동화 스크립트 실행)
$ ./create_project.sh
--- 새 워드프레스 프로젝트 생성 ---
프로젝트 이름을 입력하세요: wp6-new-project
워드프레스 포트 [8058]: (Enter)
... (다른 질문들) ...
✅ 'wp6-new-project' 프로젝트가 성공적으로 생성되었습니다!

// 핵심 변화 설명
// 사람이 하던 '복사 -> 파일 열기 -> 수정' 과정을 스크립트가 대신 '질문 -> 답변 취합 -> 파일 생성'으로 자동화했습니다.

주의사항: 스크립트가 제대로 작동하려면 chmod +x create_project.sh 명령어로 실행 권한을 부여해야 합니다.

[3단계: 옵션 부품 추가하기 - 선택적 레디스 기능 구현]

핵심 행동: 스크립트에 "레디스를 사용하시겠습니까?"라는 질문을 추가하고, 답변에 따라 Dockerfile 사용 여부와 네트워크 연결을 동적으로 결정합니다.
실행 가이드:

wp-template 폴더에 Redis 확장 모듈을 설치하는 Dockerfile을 미리 준비해둡니다.
스크립트 실행 중 "레디스 사용 여부"를 묻습니다.
사용자가 'y'를 선택하면:
a. 생성될 docker-compose.yml 파일에서 image: wordpress:latest 부분을 build: .으로 바꿉니다.
b. redis-net이라는 외부 네트워크에 연결하는 설정을 추가합니다.
c. 사용 가능한 레디스 DB 번호를 자동으로 할당하여 WORDPRESS_CONFIG_EXTRA 변수에 추가합니다.
사용자가 'n'을 선택하면, 미리 준비했던 Dockerfile을 그냥 삭제해서 프로젝트를 깔끔하게 유지합니다.

성공 지표: 레디스가 필요한 프로젝트와 필요 없는 프로젝트를 동일한 스크립트로, 단지 질문에 대한 답변 하나만으로 완벽하게 구분하여 생성할 수 있습니다.
예시/코드:

// 레디스 'n' 선택 시 docker-compose.yml (일부)
wordpress:
  image: wordpress:latest
  networks:
    - default_network

// 레디스 'y' 선택 시 docker-compose.yml (일부)
wordpress:
  build: .
  networks:
    - default_network
    - redis-net

// 핵심 변화 설명
// 사용자의 답변(USE_REDIS 변수)에 따라 스크립트가 조건문(if-then-else)을 사용해 
// 최종 결과물인 docker-compose.yml 파일의 내용을 다르게 조립합니다.

주의사항: 레디스를 공유해서 사용하려면, 각 프로젝트가 서로 다른 DB 번호를 사용하도록 강제하여 데이터가 섞이는 것을 반드시 막아야 합니다.

🧠 핵심 개념 해부

.env 파일: 일상적 재정의
5살에게 설명한다면: 장난감 로봇이 있는데, 로봇의 이름이랑 색깔을 적어놓는 '설정 스티커' 같은 거야. 스티커에 '번개'라고 쓰면 로봇 이름이 '번개'가 되고, '파란색'이라고 쓰면 로봇이 파란색으로 변해. docker-compose.yml이라는 로봇 본체는 그대로 두고, 이 스티커만 바꿔 붙이는 거지.
실생활 예시: 스마트폰 앱의 '설정' 화면. 알림을 켤지 끌지, 글자 크기를 어떻게 할지 정해두면 앱 전체가 그 설정에 맞춰 동작합니다. .env 파일은 앱의 '설정' 화면을 코드로 옮겨놓은 것입니다.
숨겨진 중요성: 민감한 정보(DB 비밀번호, API 키 등)를 소스 코드(docker-compose.yml)와 분리하여 안전하게 관리할 수 있게 해줍니다. 소스 코드는 깃허브에 공개해도, .env 파일만 제외하면 비밀번호가 유출될 걱정이 없습니다.
오해와 진실:
오해: .env는 그냥 주석 같은 메모장이다.
진실: .env는 docker-compose가 실행될 때, 그 안에 정의된 변수들을 실제 '환경 변수'로 만들어서 컨테이너 내부에 주입하는 강력한 설정 파일입니다.
셸 스크립트 (.sh): 일상적 재정의
5살에게 설명한다면: 컴퓨터한테 시킬 일을 순서대로 적어놓은 '심부름 목록'이야. "1. 내 방에 가. 2. 파란색 상자를 가져와. 3. 거실 테이블 위에 올려놔." 이렇게 적어두고 "이거 해!"라고 한 번만 말하면, 컴퓨터가 목록대로 착착 알아서 다 해주는 거지.
실생활 예시: 요리 레시피. "1. 물을 끓인다. 2. 면을 넣는다. 3. 3분 뒤에 수프를 넣는다." 이 레시피(스크립트)만 있으면 누가 요리해도 비슷한 결과물(프로젝트 폴더)이 나옵니다.
숨겨진 중요성: 단순히 명령어를 나열하는 것을 넘어, 조건문(if), 반복문(while) 등을 통해 사람처럼 '상황 판단'을 하고 다른 작업을 수행하게 만들 수 있습니다. (예: "레디스를 쓴다고? 그럼 Dockerfile을 써야지.")
오해와 진실:
오해: 스크립트는 개발자들만 쓰는 어려운 것이다.
진실: 스크립트는 단순 반복 작업을 줄여주는 '나만의 자동화 도구'이며, 간단한 명령어 몇 줄로도 엄청난 효율을 만들어낼 수 있습니다.
image vs build: 일상적 재정의
5살에게 설명한다면:
image: 가게에서 파는 '완성된 레고 장난감'을 그대로 사 오는 거야. 상자만 뜯으면 바로 가지고 놀 수 있어.
build: '레고 블록 한 통'을 사 와서, 설명서(Dockerfile)를 보고 직접 조립해서 나만의 장난감을 만드는 거야. 기본 장난감에 로켓을 달아주는 것처럼 커스터마이징이 가능해.
실생활 예시: 식당에서 음식을 주문하는 것.
image: 메뉴판에 있는 '김치찌개'를 주문하는 것. 이미 만들어진 표준 음식이 바로 나옵니다.
build: "김치찌개 주시는데요, 돼지고기 많이 넣고 좀 맵게 해주세요" 라고 특별 주문하는 것. 주방장(Docker)이 나의 요구사항(Dockerfile)에 맞춰 특별한 김치찌개를 만들어줍니다.
숨겨진 중요성: build를 사용하면, 공식 이미지에 없는 특정 PHP 확장 모듈(redis, gd 등)을 설치하거나, 서버 설정을 우리 프로젝트에 맞게 미세 조정하는 등 무한한 확장이 가능합니다.
오해와 진실:
오해: build는 항상 image보다 좋다.
진실: 커스터마이징이 필요 없다면, 이미 전 세계 수많은 사람들에 의해 검증되고 최적화된 공식 image를 쓰는 것이 훨씬 빠르고 안정적입니다. build는 꼭 필요할 때만 쓰는 '필살기'입니다.

🔮 미래 전략 및 지혜

예방 전략:

'세 번 반복되면 자동화하라': 똑같은 수작업을 세 번 이상 반복하고 있다면, 그 즉시 자동화 스크립트를 만들 후보로 생각합니다.
'설정값은 외부에서 주입하라': 코드 안에 숫자나 문자열(포트 번호, 경로 등)을 직접 쓰지 말고, 항상 변수로 빼서 설정 파일(.env)을 통해 주입하는 습관을 들입니다.
'문서 대신 스크립트를 작성하라': "새 프로젝트 생성 방법" 같은 문서를 만들기보다, 그 문서의 내용을 그대로 실행하는 스크립트를 만듭니다. 스크립트는 거짓말을 하지 않는 '살아있는 문서'입니다.

장기적 고려사항: 이 경험은 단순히 워드프레스 설정 자동화를 넘어, 모든 종류의 반복적인 개발 및 서버 운영 작업을 어떻게 시스템적으로 접근하고 해결할 수 있는지에 대한 중요한 교훈을 줍니다. 이것이 'DevOps(개발운영)' 문화의 첫걸음입니다.
전문가 사고방식: 전문가는 '어떻게 이 일을 더 빨리 할까?'를 넘어 **'어떻게 하면 이 일을 다시는 안 할 수 있을까?'**를 고민합니다. 즉, 눈앞의 문제를 해결하는 데 그치지 않고, 그 문제가 다시 발생하지 않도록 '시스템'을 설계합니다.
학습 로드맵:

기초: 셸 스크립트 기초 (변수, 조건문, 반복문)
중급: awk, sed 같은 텍스트 처리 명령어 마스터하기
고급: Docker Compose의 extends나 override 파일을 이용한 더 유연한 설정 관리 방법 연구
확장: Ansible, Terraform 같은 전문적인 인프라 자동화 도구 학습

🌟 실전 적용 청사진

즉시 적용:

지금 바로 ./create_project.sh를 실행해서 'wp-test'라는 새 프로젝트를 만들어봅니다.
대화형 질문에 기본값 대신 다른 값(예: 포트 9090)을 입력해보고, 생성된 .env 파일에 잘 반영되었는지 확인합니다.
레디스를 사용하는 테스트 프로젝트와 사용하지 않는 프로젝트를 각각 만들어보고, docker-compose.yml 파일 내용이 의도대로 다르게 생성되는지 비교해봅니다.

중기 프로젝트: 1~4주 내에 기존에 수동으로 만들었던 wp3, wp4-uncle, wp5-ds 프로젝트들을 이 스크립트를 이용해 새로 생성하는 마이그레이션 작업을 시도해봅니다. (물론 기존 데이터는 백업 후 이전해야 합니다)
숙련도 점검:
초급: 스크립트를 실행해서 새 프로젝트를 1분 안에 만들 수 있는가?
중급: 스크립트에 "DB 비밀번호 자동 생성 기능"을 추가할 수 있는가?
고급: docker-compose.yml 템플릿에 Nginx-Proxy-Manager와 자동 연동되는 labels 설정을 추가할 수 있는가?
추가 리소스:
초급 (셸 스크립트): The Bash Guide (영문) 또는 따라하며 배우는 리눅스 셸 스크립트 (한글, 유료)
중급 (Docker Compose): Docker 공식 문서 - Compose file reference (영문)
고급 (자동화 철학): 책 피닉스 프로젝트

📝 지식 압축 요약

수작업으로 하던 도커 프로젝트 설정을 '템플릿'과 '설정 파일'로 분리하고, 이 둘을 자동으로 조립해주는 **'셸 스크립트'**를 만들었습니다. 그 결과, 이제는 질문에 몇 번 답하는 것만으로 레디스 사용 여부까지 선택 가능한, 실수 없고 일관된 워드프레스 개발 환경을 1분 만에 찍어낼 수 있게 되었습니다. 이것이 바로 반복 작업을 시스템으로 해결하는 자동화의 핵심입니다.