Alpine Linux 에서 파이썬을 사용하면 안되는 이유

[IT/Cloud] - [BusyBox] Alpine Linux는 왜 BusyBox를 선택했을까

Alpine Linux 는 경량화된 리눅스라 컨테이너 환경에서 적합하지만 파이썬을 쓰면 안 된다.

Alpine이 좋다고 해서, 모든 워크로드에 적합한 건 아니다.

컨테이너 환경에서는 이미지 크기가 작고, 의존성이 적으며, 보안 표면이 작다는 점에서 매우 매력적이다.

특히 파이썬에서는 이야기가 달라진다.

1. 근본적인 차이: musl vs glibc

• Alpine은 musl libc 사용
• 파이썬 생태계는 glibc 기준으로 빌드된 바이너리가 대부분
• 많은 패키지가 wheel을 못 쓰고 소스 빌드로 떨어진다

참고1 PEP 656 – Platform Tag for Linux Distributions Using Musl

참고2 glibc vs. musl

참고3 Comparing glibc and musl: A Deep Dive into C Standard Libraries part 1

2. Wheel을 못 쓰면 어떤 일이 벌어질까

1. 적절한 wheel 없음
2. 소스 코드 다운로드
3. gcc로 컴파일
4. 시스템 라이브러리 필요
5. build-base, lib-dev 추가 설치

결과적으로, 이런 문제가 발생한다.

• 빌드 시간 급증
• Docker build 단계에서 수분 이상 소요
• 불필요한 빌드 툴이 이미지에 포함

참고 문헌 : Wolfi: A Small glibc-Based Python Container Base

3. 대표적으로 문제가 되는 패키지들

• numpy
• pandas
• cryptography
• psycopg2
• pillow
• lxml

이들은 C 확장 모듈을 포함하고 있고,

glibc 기준 wheel이 기본 전제인 경우가 많다.

 

4. 빌드 단계 분리로 해결할 수 있지 않을까?

물론 해결 방법은 있다.

• 멀티 스테이지 빌드
• wheel을 별도로 생성 후 복사
• gcompat 사용

하지만 여기서 질문이 생긴다.

굳이 이렇게까지 해야 할까?

Debian slim을 쓰면 wheel이 바로 설치되는데?????

 

5. 결론: Alpine은 도구일 뿐이다

 

Alpine은 다음 환경에 매우 적합하다.

• Go, Rust 같은 정적 빌드 언어
• 단일 바이너리 런타임
• 오토스케일링이 중요한 서비스
• 작은 이미지가 직접적인 이점이 되는 경우

 

하지만 Python, 특히 C 확장 의존성이 있는 서비스라면

Alpine은 오히려 생산성을 떨어뜨릴 수 있다.

 

가볍게 시작했지만, 끝은 방대할 수 있다.

좋은 아키텍처는 “가벼워 보이는 선택”이 아니라 “워크로드에 맞는 선택”에서 시작한다.