리눅스 환경, 특히 CentOS나 RHEL과 같은 엔터프라이즈 시스템에서 Python을 소스 코드로부터 컴파일하여 설치하는 과정은 종종 예상치 못한 의존성 문제와 맞닥뜨리게 됩니다. 이 가이드는 개발자들이 가장 흔히 겪는 두 가지 주요 문제인 SSL/TLS 모듈 누락으로 인한 네트워크 통신 실패와 GCC 링크 오류를 심층적으로 다루고, 더불어 Bash 셸의 명령어 캐시 문제 해결 방법까지 제시합니다.

1. Python SSL 모듈 누락 문제 해결

pip 명령 실행 시 ssl module in Python is not available 또는 SSLError와 같은 오류 메시지가 나타난다면, 이는 Python 인터프리터가 보안 HTTPS 연결을 설정할 수 없음을 의미합니다.

문제 진단

Python의 ssl 모듈은 자동으로 빌드되지 않습니다. ./configure 스크립트 실행 시 시스템에 OpenSSL 개발 라이브러리가 설치되어 있지 않으면, Python은 SSL 지원 없이 컴파일됩니다.

해결책

1. OpenSSL 개발 패키지 설치

RHEL/CentOS 기반 시스템에서는 openssl-devel 및 기타 필수 의존성 패키지를 반드시 설치해야 합니다.

yum install openssl-devel zlib-devel bzip2-devel libffi-devel -y

2. 빌드 환경 초기화 및 재설정

의존성 패키지를 설치한 후에는 기존에 컴파일된 파일과 설정을 깨끗하게 정리하고 Python 소스 코드를 다시 설정해야 합니다.

# 이전 빌드 파일 및 객체 제거
make clean

# 설정 스크립트 실행. 시스템에 설치된 OpenSSL을 자동으로 감지합니다.
# 참고: '--with-ssl' 옵션은 OpenSSL 개발 패키지가 설치되어 있다면 별도로 지정할 필요가 없습니다.
# 만약 스크립트가 해당 옵션을 인식하지 못한다고 경고해도 무시할 수 있습니다.
./configure --prefix=/usr/local/python3 --enable-optimizations

3. 컴파일 및 설치

make
make install

이 단계를 완료하면 새로 설치된 Python 인터프리터는 완벽한 SSL 기능을 갖추게 됩니다.

2. GCOV 링크 오류 처리

make 단계에서 undefined reference to '__gcov_...'와 같은 대량의 링크 오류가 발생한다면, 이는 전형적인 GCOV 관련 문제입니다.

문제 진단

이 오류는 이전 ./configure 과정에서 의도치 않게 GNU 코드 커버리지(GCOV) 관련 컴파일 플래그(예: -fprofile-arcs 또는 -ftest-coverage)가 활성화되었지만, 최종 링크 단계에서 GCOV 라이브러리(-lgcov)를 찾지 못할 때 발생합니다.

해결책: 코드 커버리지 기능 비활성화

가장 간단한 해결책은 설정 단계로 돌아가 모든 GCOV 관련 컴파일 옵션을 제거하고 표준 최적화 설정에 의존하는 것입니다.

1. 빌드 잔여 파일 제거:

make clean

2. 재설정: configure 명령에 어떤 -fprofile-arcs 또는 -ftest-coverage 관련 환경 변수나 매개변수도 포함되지 않았는지 확인합니다.

# GCOV 관련 옵션 없이 다시 설정합니다.
# 이 예시는 공유 라이브러리를 활성화하고, 특정 OpenSSL 경로를 지정하는 경우를 보여줍니다.
./configure --prefix=/usr/local/python3 --enable-shared --with-openssl=/usr/local/openssl

# 동적 라이브러리 검색 경로 설정 (필요한 경우)
echo "/usr/local/python3/lib" > /etc/ld.so.conf.d/python3.conf
ldconfig

3. 다시 컴파일:

make

3. make test 중 CERTIFICATE_EXPIRED 오류 처리

make test 명령 실행 중 [SSL: SSLV3_ALERT_CERTIFICATE_EXPIRED] 오류가 발생할 수 있습니다. 이는 외부 테스트 리소스의 인증서 만료로 인한 것이며, 새로 컴파일되는 Python 인터프리터 자체에는 영향을 미치지 않습니다.

해결책

이 오류는 외부 문제이므로, 테스트를 즉시 중단(Ctrl+C)하고 make install 명령을 실행하여 설치를 완료할 수 있습니다.

4. Bash 명령어 캐시 문제 해결

새로운 심볼릭 링크(예: /usr/local/python3/bin/pip3에 대한 /usr/bin/pip3)를 생성했음에도 불구하고, pip3 명령을 직접 실행하면 No such file or directory 오류가 발생하는 경우가 있습니다. 이는 주로 Bash 셸의 내부 캐시 문제 때문입니다.

문제 진단

Bash는 명령어의 전체 경로를 기억하기 위해 해시 테이블(Hash Table)이라는 캐시 메커니즘을 사용합니다. 심볼릭 링크를 생성하거나 프로그램을 이동한 후 Bash에 이를 알리지 않으면, Bash는 이전에 기억하고 있던 잘못된 경로로 계속 명령을 실행하려고 시도합니다.

해결책: Bash 해시 캐시 초기화

hash -r 명령을 사용하여 Bash가 $PATH 환경 변수에 있는 모든 디렉토리를 다시 검색하도록 강제할 수 있습니다.

# pip3 또는 다른 명령어를 찾지 못하는 문제 해결
hash -r

# 변경 사항 검증
pip3 -V