04. [Docker] 환경 컨테이너화: "내 PC에선 됐는데 서버에선 안 돼요" 해결

안녕하세요! 보배로의 북테크랩입니다.

지난 시간, 우리는 AWS 서울 리전에 튼튼한 성벽을 갖춘 서버(EC2)를 구축했습니다. 이제 그곳에 우리가 짠 파이썬 자동매매 코드를 올릴 차례입니다.

그런데 개발자들 사이에서 가장 유명한 공포 괴담이 하나 있습니다. 바로 "내 PC에선 분명히 잘 됐는데, 왜 서버에만 올리면 에러가 나지?"라는 상황입니다. 파이썬 버전이 달라서, 설치된 라이브러리 버전이 꼬여서, 혹은 운영체제의 설정이 달라서 발생하는 이 지긋지긋한 문제를 우리는 Docker(도커)로 깔끔하게 해결할 것입니다.

---

1. 왜 도커(Docker)인가? : "이동식 냉동 컨테이너"

도커는 한마디로 '코드와 그 코드가 실행되는 데 필요한 모든 환경을 통째로 박스(컨테이너)에 담는 기술'입니다.

• 일관성: 내 노트북(Windows/Mac)에서 담은 박스를 AWS 서버(Linux)로 가져가도, 박스 안의 환경은 100% 동일합니다.
• 격리성: 봇 A와 봇 B가 서로 다른 라이브러리 버전을 요구해도, 각각 다른 컨테이너에서 돌리면 충돌이 전혀 없습니다.
• 신속함: 서버가 고장 나면? 새로운 서버에서 도커 이미지만 내려받아 실행하면 1분 만에 복구가 끝납니다. ([Self-Healing]의 기초)

---

2. [실습] 봇 컨테이너 제작 및 배포 명령어

이제 우리의 자동매매 봇을 도커 이미지로 만들고 실행하는 핵심 과정을 코드로 확인해 보겠습니다.

1단계: 보안까지 고려한 도커 설계도 (Dockerfile) 작성

단순히 실행만 시키는 것이 아니라, 현업 수준의 보안과 효율을 담은 설계도입니다.

Dockerfile

 

# 1. Multi-stage build: 빌드 환경과 실행 환경을 분리하여 최종 이미지 크기를 최소화하고 보안을 강화합니다.
FROM python:3.10-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --user --no-cache-dir -r requirements.txt

# 2. 실행용 최종 이미지
FROM python:3.10-slim
WORKDIR /app

# 3. Non-root user: 보안을 위해 root 권한이 아닌 일반 사용자(appuser)로 봇을 실행합니다.
RUN groupadd -r appuser && useradd -r -g appuser appuser
USER appuser

# 4. builder 단계에서 설치된 라이브러리만 복사
COPY --from=builder /root/.local /home/appuser/.local
COPY . .

# 환경 변수 경로 설정
ENV PATH=/home/appuser/.local/bin:$PATH

# 5. 봇 실행
CMD ["python", "main.py"]

💡 현업 엔지니어의 한 끗: .dockerignore

이미지를 빌드할 때 .git, __pycache__, 그리고 절대 유출되면 안 되는 .env(API 키 포함 파일) 등이 포함되지 않도록 반드시 .dockerignore 파일을 설정하세요. 이것이 보안의 기본입니다.

2단계: 오케스트라 지휘자, Docker Compose (50강)

실제 자동매매 시스템은 하나의 프로그램으로 끝나지 않습니다. 시세 수집기, 매매 엔진, Redis, 모니터링 시스템, 로그 서버가 각각 따로 움직이죠. Docker Compose는 이 복잡한 시스템을 하나의 버튼으로 동시에 시작시키는 ‘오케스트라 지휘자’ 역할을 합니다.

YAML

 

# docker-compose.yml
version: '3.8'
services:
  # 데이터 저장소 (기억 장치)
  redis:
    image: redis:alpine
    restart: always
    ports:
      - "6379:6379"

  # 우리의 메인 매매 봇
  trading-bot:
    build: .
    restart: always
    depends_on:
      - redis
    # 💡 핵심: 로그 볼륨 연결
    # 컨테이너는 삭제되면 내부 데이터도 함께 사라집니다. 
    # 만약 거래 로그를 내부에만 저장했다면 장애 복구 시 수익 기록과 주문 내역이 통째로 증발합니다.
    # 그래서 반드시 서버 디스크(/var/log/bot)와 컨테이너 폴더를 연결해야 합니다.
    volumes:
      - /var/log/bot:/app/logs
    environment:
      - REDIS_HOST=redis

3단계: 실행 및 로그 확인 명령어

Bash

 

# 1. 오케스트라 가동 (전체 서비스 동시 실행)
docker-compose up -d

# 2. 봇이 잘 돌아가고 있는지 실시간 로그 확인
docker logs -f trading-bot-1

# 3. 컨테이너 내부 상태 확인 (보안상 권장되지는 않지만 점검 시 사용)
docker exec -it trading-bot-1 /bin/bash

---

📖 실제 장애 사고 사례: "증발한 거래 로그와 세무 조사"

과거 한 전업 트레이더가 봇의 장애를 복구하기 위해 컨테이너를 새로 띄웠습니다. 하지만 [로그 볼륨 연결]을 깜빡하는 바람에, 지난 3개월간의 정교한 수익 기록과 수만 건의 매매 내역이 순식간에 증발해 버렸습니다.

나중에 수익금에 대한 소명 자료가 필요했을 때, 증빙할 데이터가 없어 큰 곤혹을 치렀죠. "봇은 뇌(Logic)뿐만 아니라 기억(Persistence)을 가져야 하며, 그 기억은 컨테이너 외부에 안전하게 보관되어야 합니다."

---

🛡️ 도커 환경 보안 & 운영 체크리스트

• [ ] Multi-stage Build 적용: 최종 이미지에 불필요한 빌드 도구가 포함되지 않았는가?
• [ ] Non-root User 사용: 컨테이너가 해킹당하더라도 서버 전체 권한이 뚫리지 않도록 설정했는가?
• [ ] Read-only Filesystem: (심화) 봇의 소스 코드가 실행 중 수정되지 않도록 읽기 전용으로 설정했는가?
• [ ] 로그 볼륨 마운트: 서버 재시작이나 컨테이너 교체 시에도 거래 기록이 유지되는가?
• [ ] .dockerignore 설정: API 키나 불필요한 설정 파일이 이미지에 포함되지 않았는가?

---

📝 보배로의 통찰: "환경을 지배하는 자가 수익을 지배한다"

"내 PC에선 됐는데..."라는 말은 엔지니어로서 가장 피해야 할 변명입니다. 도커를 통해 환경을 완전히 통제하고, Docker Compose로 복잡한 시스템을 지휘할 수 있을 때, 비로소 우리의 시스템은 어떤 서버에서도 일관된 수익 로직을 실행할 수 있습니다.

이미지 한 장에 담긴 당신의 전략은 이제 클라우드 위에서 휘발되지 않는 강력한 기억을 가진 수익 엔진으로 거듭났습니다.

---

다음 시간에는 우리가 코드를 수정하면 자동으로 서버에 반영되는 꿈의 시스템, [05. CI/CD] GitHub Actions 기반 자동 배포 시스템 구축에 대해 알아보겠습니다.

---

보배로의 북테크랩(Booktech-lab) 공학적으로 투자하고, 데이터로 증명하며, 시스템으로 승리합니다.