폐쇄망 RHEL 6.5에 파이썬 배포하기 (2) 도커로 자체완결 번들 만들기

핵심 요약

• 1편에서 "왜 그냥 안 되는가"(RHEL 6.5 = GLIBC 2.12 = 최신 라이브러리 거부)를 정리했습니다. 이번 편은 실제로 자체완결 번들을 만든 과정입니다.
• 핵심은 RHEL 6.5와 같은 GLIBC 2.12 환경(manylinux2010 도커 이미지)에서 빌드하는 것입니다. 윈도우나 최신 우분투에서 만들면 GLIBC가 높아 RHEL 6.5에서 안 돕니다.
• 만드는 동안 함정이 여럿 있었습니다. ① 도커의 Python이 실제 파일이 아니라 심볼릭 링크였던 것(번들이 196KB로 나옴) ② RHEL 6.5에 없는 비표준 라이브러리 2개를 같이 담아야 했던 것 ③ 검증 환경(CentOS 6 컨테이너)이 세그폴트로 죽은 것 등입니다.
• 라이브러리 로드뿐 아니라 앱이 끝까지 도는지(수집→탐지→리포트), 모델 재학습, 그래프 한글 폰트까지 검증했습니다.
• 최종 산출물은 약 124MB의 tar.gz 한 개입니다. RHEL 6.5에서 인터넷·시스템 파이썬 없이 풀어서 실행하면 한글 그래프 리포트까지 나옵니다.

---

1. 빌드 전략: 왜 도커이고, 왜 manylinux2010인가

만들 것은 "인터넷 없이 RHEL 6.5에서 그냥 풀면 도는 한 덩어리(tar.gz)" 입니다. 안에 들어갈 것은 ① RHEL 6.5 호환 Python ② 라이브러리 ③ 앱 코드 ④ 모델입니다.

여기서 가장 중요한 결정은 어디서 빌드하느냐입니다. 1편에서 봤듯, RHEL 6.5는 GLIBC 2.12라 그 환경에서 도는 Python·라이브러리는 같은 GLIBC 2.12 환경에서 만들어야 합니다. 그 환경을 손쉽게 주는 것이 manylinux2010 도커 이미지입니다. 이 이미지는 CentOS 6 기반(GLIBC 2.12)에 파이썬 패키지 빌드에 필요한 것들이 미리 들어 있습니다.

도커 컨테이너는 "그 오두막과 똑같은 낡은 방을 즉석에서 짓고 다 쓰면 버리는 조립식 방"입니다. manylinux2010은 "RHEL 6.5와 같은 평형의 모델하우스"입니다. 가구(파이썬·라이브러리)는 그 모델하우스 안에서 맞춰야 진짜 오두막 문틀(낮은 GLIBC)에 들어갑니다.

manylinux2010 컨테이너(CentOS 6 / GLIBC 2.12)에서 번들을 만들고, 그 결과물을 RHEL 6.5에 가져가는 흐름을 보여줍니다. 두 환경의 GLIBC가 같기 때문에 빌드 결과가 목적지에서 그대로 돈다는 점이 핵심입니다.

로컬에 도커가 깔려 있으면(Docker Desktop) 별도 서버 없이 윈도우에서도 리눅스 컨테이너로 빌드할 수 있습니다. 이미지부터 받습니다.

$ docker pull quay.io/pypa/manylinux2010_x86_64
Status: Downloaded newer image ...   # 약 1GB

컨테이너 안에서 Python 3.7은 /opt/python/cp37-cp37m/bin/python 에 있습니다.

---

2. 라이브러리가 진짜 도는지 먼저 확인

전략은 좋은데, 가장 큰 의문이 남아 있었습니다.

"그래서 진짜로, RHEL 6.5에서 도는(manylinux2010) pandas·scikit-learn이 존재하긴 하나?"

이게 안 되면 전략 자체가 무너집니다. 그래서 이걸 제일 먼저 확인했습니다.

먼저 라이브러리를 받을 수 있는지부터 봤습니다. 여기서 중요한 점은, 이 확인은 윈도우 로컬에서 했다는 것입니다. pip download는 패키지를 설치·실행하지 않고 파일만 내려받기만 하고, "어떤 OS·파이썬 버전용 wheel을 받을지"를 옵션으로 지정할 수 있어서, 윈도우에서도 RHEL 6.5용 리눅스 wheel 파일을 받아볼 수 있습니다.

$ pip download --only-binary=:all: \
    --platform manylinux2010_x86_64 --platform manylinux1_x86_64 \
    --python-version 37 --implementation cp --abi cp37m \
    -d ./wheels \
    numpy==1.19.5 scipy==1.5.4 pandas==1.1.5 \
    scikit-learn==0.24.2 matplotlib==3.3.4 joblib==1.1.0 PyYAML==5.4.1

옵션을 풀어 읽으면 이렇습니다.

• --platform manylinux2010_x86_64 : "RHEL 6.5(CentOS 6) 호환 wheel만"
• --python-version 37 : "파이썬 3.7용으로" (구버전 라이브러리는 보통 3.7까지 manylinux2010 wheel이 있음)
• --only-binary=:all: : "소스 말고 미리 컴파일된 wheel만" (현장에서 컴파일 못 하니까)
• 버전을 구버전으로 콕 집음 (pandas 1.1.5 등) — 최신은 manylinux2014라 안 되니까

결과는 전부 받아졌습니다. 15개 wheel, 합계 86MB. 파일 이름 끝의 manylinux2010_x86_64·manylinux1_x86_64가 "RHEL 6.5에서 돈다"는 보증서입니다.

numpy-1.19.5-cp37-cp37m-manylinux2010_x86_64.whl       # RHEL6.5 호환
scipy-1.5.4-cp37-cp37m-manylinux1_x86_64.whl           # 더 옛날 기준이라 더 안전
pandas-1.1.5-cp37-cp37m-manylinux1_x86_64.whl
scikit_learn-0.24.2-cp37-cp37m-manylinux2010_x86_64.whl
matplotlib-3.3.4-cp37-cp37m-manylinux1_x86_64.whl
...

그런데 "받아진다"와 "진짜 돈다"는 다릅니다. 다음으로, manylinux2010 컨테이너 안에서 인터넷을 끊고(--no-index) 설치하고 import까지 되는지 봤습니다.

$ docker run --rm -v "$PWD/wheels:/wheels:ro" -v "$PWD:/deploy:ro" \
    quay.io/pypa/manylinux2010_x86_64 bash -c '
      cat /etc/redhat-release; ldd --version | head -1
      PY=/opt/python/cp37-cp37m/bin/python; $PY --version
      $PY -m pip install --no-index --find-links /wheels -r /deploy/requirements-rhel65.txt
      MPLBACKEND=Agg $PY -c "import numpy,scipy,pandas,sklearn,matplotlib,yaml,joblib; print(pandas.__version__)"'

결과:

CentOS release 6.10 (Final)
GLIBC: ldd (GNU libc) 2.12
Python 3.7.13
Successfully installed numpy-1.19.5 pandas-1.1.5 scikit-learn-0.24.2 ... matplotlib-3.3.4
ALL OK -> pandas 1.1.5 | sklearn 0.24.2 | numpy 1.19.5 | matplotlib 3.3.4

--no-index는 "마트(인터넷) 문을 잠그고, 들고 온 장바구니(wheel)만으로 요리가 되나 본 것"입니다. import 성공은 "재료를 실제로 냄비에 넣어보니 멀쩡히 익더라" — 즉 보관만 된 게 아니라 진짜 쓸 수 있는 상태임을 확인한 것입니다.

import가 전부 성공했다는 건 GLIBC 2.12(=RHEL 6.5)에서 라이브러리가 실제로 로드된다는 실증입니다. 이 작업의 가장 큰 불확실성이 여기서 풀렸습니다.

윈도우 로컬에서 pip download로 wheel을 받고, 그것을 manylinux2010 컨테이너에 넣어 인터넷 없이 설치·import까지 검증하는 단계를 보여줍니다. "받기"와 "실제로 돌기"를 분리해 확인했다는 점이 드러납니다.

---

3. 번들 조립과 첫 함정: 심볼릭 링크

이제 실제로 한 덩어리로 묶을 차례입니다. 처음엔 단순하게 "도커 안 Python 폴더를 복사하면 되겠지" 했습니다.

cp -r /opt/python/cp37-cp37m  $BUNDLE/python

그런데 번들이 196KB밖에 안 됐습니다. Python 하나가 수십 MB일 텐데 이상합니다. 확인해보니 /opt/python/cp37-cp37m은 실제 Python이 아니라 링크 모음이었고, 진짜 Python은 다른 곳에 있었습니다.

$ readlink -f /opt/python/cp37-cp37m/bin/python3.7
/opt/_internal/cpython-3.7.13/bin/python3.7      # 진짜는 여기 (68MB)

더 고약한 건, 첫 "재배치 검증"이 거짓으로 통과했다는 점입니다. 복사본이 링크라, 컨테이너 안에 남아있던 원본을 따라가서 import가 됐던 것입니다. 목적지(RHEL 6.5)엔 원본이 없으니 실제론 안 됐을 상황입니다.

냉장고를 통째로 옮긴 줄 알았는데, 알고 보니 옮긴 건 "냉장고는 저쪽에 있음"이라고 적힌 쪽지(링크)였습니다. 진짜 냉장고(원본 Python)는 원래 방에 그대로 있어서, 그 방 안에서 테스트하면 잘 되는 것처럼 보입니다(거짓 통과). 쪽지만 들고 오두막에 가면 냉장고가 없습니다.

cp -r로 옮긴 것이 실제 파일이 아니라 원본을 가리키는 링크였고, 같은 컨테이너 안에 원본이 남아 있어 테스트가 통과한 것처럼 보였던 상황을 보여줍니다. 목적지엔 원본이 없으므로 실제로는 동작하지 않는다는 점이 핵심입니다.

교훈은 두 가지입니다. ① 진짜 Python(/opt/_internal/cpython-3.7.13)을 복사할 것 ② 검증은 "원본을 다 치운 상태"로 해야 진짜다.

---

4. 같이 담아야 할 라이브러리 찾기 (ldd)

Python을 제대로 복사했어도 끝이 아닙니다. Python 바이너리와 표준 확장 모듈이 의존하는 공유 라이브러리(.so) 중 RHEL 6.5에 없는 것이 있으면 실행 시 죽습니다. 그래서 ldd로 의존성을 훑어, 표준 시스템 경로(/lib64·/usr/lib64) 바깥에서 오는 것을 찾았습니다.

$ { ldd .../python3.7; find . -name "*.so*" -exec ldd {} \; ; } \
    | grep -E '=> (/usr/local|/opt)'
libcrypt.so.2   => /usr/local/lib/libcrypt.so.2     # libxcrypt, 198KB
libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0   # 1.2MB

딱 두 개였습니다. 이 둘만 번들에 같이 넣고, 실행할 때 LD_LIBRARY_PATH로 잡아주면 됩니다.

휴대용 부엌(Python)이 특수 콘센트 두 개(libcrypt·libsqlite3)가 있어야 도는데, 낡은 오두막엔 그 콘센트가 없어 어댑터 두 개도 박스에 같이 챙기는 셈입니다.

나머지는 어떻게 자급되는지도 확인했습니다.

• numpy·scipy·matplotlib·Pillow의 네이티브 라이브러리(openblas·libpng 등): manylinux wheel이 패키지 안 *.libs/ 폴더에 자체 포함합니다. → 번들에 그대로 따라옵니다(자급).
• openssl(_ssl·_hashlib): manylinux Python은 openssl을 정적 링크합니다(ldd에 libssl 없음, ssl.OPENSSL_VERSION이 표시됨). → 외부 openssl 불필요(자급).

openssl은 "배터리 내장형 도구"라 콘센트가 필요 없고, numpy·matplotlib 같은 재료는 "자기 양념을 통째로 들고 다니는" 셈입니다. 그래서 박스 밖에서 더 챙길 게 딱 두 개뿐이었습니다.

이제 번들을 조립합니다(컨테이너 안에서).

B=/work/db_ai_bundle
cp -r /opt/_internal/cpython-3.7.13  $B/python                 # 진짜 Python
mkdir $B/python/lib_extra
cp -P /usr/local/lib/libcrypt.so.2* libsqlite3.so.0* $B/python/lib_extra/   # 비표준 .so 2종
$B/python/bin/python3.7 -m pip install --no-index --find-links /wheels -r requirements.txt
cp app/*.py app/config.yaml $B/app/ ; cp -r models $B/app/models   # 앱 코드+모델
cp run.sh $B/ ; tar czf bundle.tar.gz db_ai_bundle                # 압축

run.sh는 번들 안 Python으로 앱을 실행하는 런처입니다. 동봉한 .so 두 개를 찾도록 LD_LIBRARY_PATH를 잡아줍니다.

#!/bin/bash
DIR="$(cd "$(dirname "$0")" && pwd)"
export LD_LIBRARY_PATH="$DIR/python/lib_extra:$LD_LIBRARY_PATH"
cd "$DIR/app"
exec "$DIR/python/bin/python3.7" main.py "$@"

 

번들 한 덩어리 안에 Python 실행기와 동봉한 비표준 라이브러리(lib_extra), 앱 코드와 모델, 실행 런처가 어떻게 들어가는지 보여줍니다. 박스 밖에서 따로 챙길 것이 비표준 .so 두 개뿐이라는 점이 드러납니다.

결과는 번들 폴더 약 414MB, 압축본 tar.gz 약 124MB였습니다.

---

5. 진짜 검증: 깨끗한 환경에서 자급자족

3장의 교훈대로, 검증은 "원본을 다 치운 상태"로 해야 합니다. 처음엔 진짜 RHEL 6.5에 가까운 CentOS 6 도커 이미지(centos:6)로 풀어보려 했습니다.

$ docker run --rm centos:6 bash -c 'cat /etc/redhat-release; ...'
$ echo $?
139      # 세그폴트

종료코드 139는 세그폴트입니다. CentOS 6 컨테이너가 최신 커널에서 못 도는 알려진 문제(vsyscall)입니다. CentOS 6 이미지 자체를 테스트 베드로 쓸 수 없었습니다.

대신, 이미 잘 도는 manylinux2010(같은 GLIBC 2.12) 안에서 manylinux 전용 경로를 숨겨 RHEL 6.5를 재현했습니다.

mv /opt/_internal /opt/_internal_HIDDEN        # 원본 Python 치움
mv /usr/local/lib /usr/local/lib_HIDDEN        # 비표준 라이브러리 출처 치움
cd /tmp/db_ai_bundle ; export LD_LIBRARY_PATH=$PWD/python/lib_extra
ldd python/bin/python3.7 | grep 'not found'    # 미해결 없음 확인
./python/bin/python3.7 importtest.py

결과:

미해결(not found) 없음
Python 3.7.13
FULL import OK
  pandas 1.1.5 | sklearn 0.24.2 | numpy 1.19.5 | matplotlib 3.3.4
  ssl: OpenSSL 1.1.1q | sqlite3: 3.39.2

원본 Python과 비표준 라이브러리 경로를 다 치운 상태에서, 번들 자체 자원만으로 라이브러리와 표준 모듈(ssl·sqlite3 등)까지 전부 로드됐습니다. GLIBC 2.12에서 자급자족으로 도는 것을 실증한 것입니다.

빌드 환경에 남아 있던 원본 Python·라이브러리 경로를 일부러 치우고(숨기고), 번들 안의 자원만으로 동작하는지 확인하는 구조를 보여줍니다. "박스 밖 도움 없이 됐으니 진짜 오두막에서도 된다"는 논리를 시각화합니다.

---

6. 앱이 끝까지 도는가 (e2e)

라이브러리 로드뿐 아니라, 우리 앱이 이 구버전 스택(Python 3.7·pandas 1.1.5)에서 끝까지 도는지도 확인해야 합니다. 코드는 최신(Python 3.12)에서 짰으니, 구버전에서 깨질 수 있습니다.

먼저 문법부터 봤습니다. 코드가 3.8 이상 전용 문법(walrus := 등)을 쓰면 3.7에서 아예 컴파일이 안 됩니다.

$ for f in *.py; do python3.7 -m py_compile "$f"; done
# 전체 통과 — 3.8+ 문법 안 씀

다음으로 실제 파이프라인입니다. 현장과 같은 경로(API에서 데이터 수집)를 재현하려고, 데이터를 API 형태로 서빙하는 모의 서버를 띄우고, 번들이 그걸 호출하게 했습니다. 여기서 작은 함정이 있었습니다.

urllib.error.HTTPError: HTTP Error 404: Not Found

연결은 됐는데 404였습니다. 수집 모듈이 base_url + "/data/metrics" 로 호출하는데, base_url에 API 경로 일부(/v1 등)가 빠져 있었습니다. 경로를 맞추니 통과했습니다.

수집 완료: 3개 DB
[mysql] 등급=warning 이상=1건
[oracle] 등급=warning 이상=1건
[postgresql] 등급=warning 이상=2건
리포트 HTML 저장: report.html
완료.

번들 Python으로 수집 → 이상 탐지 → 리포트 생성까지 에러 없이 완주했습니다. 구버전 스택에서 앱이 정상 동작함을 실증한 것입니다.

데이터를 API 형태로 내보내는 모의 서버와, 그것을 호출해 수집→탐지→리포트까지 도는 번들의 연결 구조를 보여줍니다. 현장(실제 API)과 같은 호출 경로로 검증했다는 점이 핵심입니다.

---

7. 모델 재학습: 버전 삼각관계

이상 탐지에는 미리 학습한 모델이 들어갑니다. 그런데 이 모델은 번들의 scikit-learn 버전(0.24.2)으로 학습해야 로드됩니다. 기존 모델은 최신 버전으로 학습돼 있어 안 맞습니다.

그런데 학습 코드는 엑셀을 읽어야 하고, 엑셀 읽기에 쓴 라이브러리가 신버전 pandas(2.2+)에서만 되는 엔진이었습니다. 즉:

• 엑셀 읽기 = 신버전 pandas 필요
• 모델 학습 = 구버전 scikit-learn 필요
• 그런데 신버전 pandas와 구버전 scikit-learn은 numpy 요구 버전이 충돌해 한 환경에 같이 못 둠

"재료를 다듬는 칼(엑셀 읽기)"은 최신 도마(신 pandas)에서만 맞고, "요리법(구 scikit-learn)"은 옛날 주방에서만 됩니다. 둘을 한 주방에 못 둡니다.

엑셀 읽기에 필요한 신버전 pandas와 모델 학습에 필요한 구버전 scikit-learn이 numpy 요구 버전 때문에 한 환경에 공존할 수 없는 구조를 삼각형으로 보여줍니다. 그래서 "읽기 방식만 바꿔" 우회한 배경이 드러납니다.

해결은, 학습할 때만 엑셀 읽기 방식을 버전 무관한 방법으로 바꿔치기(런타임 몽키패치) 하는 것이었습니다. 원본 코드는 건드리지 않고, 학습 드라이버에서만 엑셀 읽기 함수를 교체했습니다.

# 일회성 학습 드라이버 (원본 코드 무수정)
from python_calamine import get_sheet_data
import collector

def _read_compat(path):
    rows = get_sheet_data(path, 0)          # 라이브러리 직접 호출 (pandas 버전 무관)
    ...                                      # DataFrame으로 변환

collector.ExcelMetricSource._read_series = staticmethod(_read_compat)

import train; train.main()                   # 같은 버전(scikit-learn 0.24.2)으로 학습

번들과 같은 버전(Python 3.7 + scikit-learn 0.24.2)을 깐 컨테이너에서 이 드라이버로 학습해, 모델 세 개를 새로 만들었습니다. 이제 번들의 scikit-learn으로 그대로 로드됩니다.

---

8. 마지막 한 걸음: 한글 폰트

ML까지 켜고 다시 돌리니 그래프 세 개가 나왔는데, 경고가 떴습니다.

RuntimeWarning: Glyph 54588 missing from current font.

그래프의 한글이 □로 나오는 문제입니다. 폐쇄망 서버에는 한글 폰트가 없어서입니다. 평소 같으면 apt install fonts-nanum으로 깔겠지만, 폐쇄망이라 설치 대신 번들에 폰트를 동봉해야 합니다.

다행히 리포트 코드가 폰트를 자동 선택할 때 후보 목록에서 "NanumGothic"을 찾도록 돼 있었습니다. 그래서 NanumGothic.ttf를 번들의 matplotlib 폰트 폴더에 넣기만 하면 됩니다. 코드 수정은 필요 없었습니다.

# 번들의 matplotlib 폰트 폴더에 한글 폰트 동봉
cp NanumGothic.ttf  $B/python/lib/python3.7/site-packages/matplotlib/mpl-data/fonts/ttf/

다시 검증하니 폰트 인식 True, "Glyph missing" 경고 0, 그래프 세 개가 한글까지 정상으로 나왔습니다.

---

9. 결과

최종 산출물은 약 124MB의 tar.gz 한 개입니다. RHEL 6.5에서 인터넷·시스템 파이썬 없이 풀어서 실행하면, 수집부터 한글 그래프가 포함된 리포트 생성까지 동작합니다.

정리하면, 이번 작업은 "받아진다"에서 시작해 다음 순서로 확신을 쌓아간 과정이었습니다.

1. RHEL 6.5 호환 wheel이 존재하는가 → pip download로 확인
2. 그 안에서 import 되는가 → --no-index 설치·import로 확인
3. 번들이 자급자족인가 → 원본 경로를 다 치운 상태에서 확인
4. 앱이 끝까지 도는가 → 모의 API로 e2e 확인
5. 모델·그래프 한글까지 → 재학습·폰트 동봉으로 확인

각 단계에서 "되는 것처럼 보이는 것"과 "진짜 되는 것"을 구분하는 게 핵심이었습니다(심볼릭 링크 거짓 통과가 대표적입니다).

---

부록: 트러블슈팅 요약

증상	원인	해결
번들이 196KB로 나옴	/opt/python이 심볼릭 링크	진짜 Python(/opt/_internal/...) 복사
재배치 검증이 통과하는데 미심쩍음	원본이 같은 컨테이너에 남아 거짓 통과	원본 경로를 치운 상태에서 재검증
실행 시 .so 못 찾을 위험	RHEL 6.5에 없는 libcrypt·libsqlite3 의존	두 라이브러리 동봉 + LD_LIBRARY_PATH
centos:6 컨테이너 세그폴트(139)	최신 커널 vsyscall 비호환	manylinux2010에서 경로 숨겨 RHEL 6.5 재현
모의 API 호출 404	base_url에 API 경로 일부 누락	경로를 맞춰 호출
모델 로드 버전 불일치	신 pandas와 구 scikit-learn 공존 불가	엑셀 읽기만 런타임 교체해 같은 버전으로 학습
그래프 한글이 □	서버에 한글 폰트 없음	NanumGothic.ttf를 번들에 동봉