터미널은 흔쾌히 OpenSSL 버전을 알려 주지만 소스 트리는 암호화 헤더가 없다는 메시지와 함께 계속 실패합니다. 두 진술은 동시에 참인데, 런타임 도구와 빌드 입력 집합이 따로 배포되기 때문입니다. 다음 네 가지 점검을 순서대로 하세요: 설치된 패키지, 탐색 출력, 검색 경로, 그리고 소스 자체가 호환되는지 여부입니다. 오래된 의존성 목록을 붙여 넣는 대신 실패를 설명하는 첫 점검에서 멈추세요.

런타임과 빌드 입력은 서로 다른 패키지

배포판은 OpenSSL을 공유 라이브러리와 명령줄 도구를 제공하는 런타임 패키지와, 헤더와 버전 없는 링커 이름과 pkg-config 메타데이터를 제공하는 개발 패키지로 나눕니다. 첫 번째를 설치해도 두 번째는 설치되지 않으며, 컴파일러에는 두 번째만 필요합니다.

설치했다고 기억하는 것이 아니라 실제로 무엇이 있는지 확인하세요. Debian 계열 시스템에서 개발 패키지는 보통 libssl-dev이고, 런타임은 버전이 붙은 라이브러리 패키지에 openssl 바이너리를 더한 것입니다.

dpkg -l | grep -E 'libssl-dev|libssl3|openssl'
pkg-config --modversion openssl
openssl version

첫 명령은 세 가지 중 무엇이 설치되었는지 보여 주고, 두 번째는 빌드 시스템이 pkg-config로 찾을 버전을 보고하며, 세 번째는 런타임 버전을 보고합니다. 첫 출력에서 빠진 줄이 곧바로 오류를 설명합니다. 두 번째와 세 번째 사이의 버전 불일치는 다른 문제이며 보통 두 설치가 경쟁하고 있다는 뜻입니다.

빌드 자체의 탐색 출력을 읽으세요

요약 전에 읽으면 대부분의 실패가 구성 로그에 보입니다. CMake의 FindOpenSSL 모듈은 어떤 include 디렉터리와 라이브러리를 찾았는지 보고하며, 필요한 구성 요소가 없으면 구체적인 메시지와 함께 실패합니다.

프로젝트가 어느 모듈 버전을 쓰는지 확인하세요, 소스 트리 안에 함께 들어 있는 사본은 설치된 CMake에 포함된 것과 다르게 동작할 수 있기 때문입니다. 그다음 구성 요소 목록을 읽으세요: Crypto만 요청하는 프로젝트에는 SSL 라이브러리가 필요 없고, SSL을 요청하는 프로젝트는 개발 패키지의 일부만 있으면 실패합니다.

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
grep -i -E 'openssl|ssl' build/CMakeCache.txt

첫 명령은 처음부터 다시 구성하고, 두 번째는 모듈이 정한 루트 디렉터리나 라이브러리 경로까지 포함한 캐시 결과를 보여 줍니다. 캐시가 이전 시도의 오래된 접두사를 가리키면 값을 손으로 고치는 대신 빌드 디렉터리를 지우고 다시 구성하세요. 낡은 캐시 항목은 올바른 수정 이후에도 남는 실패의 흔한 원인입니다.

빌드를 올바른 설치로 좁게 향하게 하세요

승인된 OpenSSL이 기본 검색 경로 밖에 있으면 FindOpenSSL은 OPENSSL_ROOT_DIR를 바로 그 빌드를 위한 힌트로 문서화합니다. Unix 계열 시스템에서는 pkg-config도 참조하므로 적절한 PKG_CONFIG_PATH는 전역으로 아무것도 바꾸지 않고 도움이 될 수 있습니다.

cmake -S . -B build -DOPENSSL_ROOT_DIR=/opt/openssl-3.2 -DCMAKE_BUILD_TYPE=Release
ldd build/vpn_client | grep -i ssl

첫 명령은 힌트를 빌드 디렉터리 하나로 한정하고, 두 번째는 결과 바이너리가 런타임에 어느 공유 라이브러리를 불러오는지 보여 줍니다. 의도한 접두사에 링크된 빌드와 다른 것을 불러오는 바이너리는 런타임 경로 문제이지 탐색 문제가 아니며, 또 다른 구성 플래그가 아니라 rpath나 로더 구성에 대한 결정이 필요합니다.

이 선택은 빌드 안에만 두세요. 프로젝트 하나를 만족시키려고 시스템 라이브러리를 바꾸거나 전역 pkg-config 파일을 편집하는 것이 작동하는 데스크톱을 망가뜨리는 길입니다. 접두사를 기록하는 빌드 디렉터리는 재현 가능하지만, 머신 전체의 변경은 다음 프로젝트를 기다리는 지원 사건입니다. 힌트를 바꿀 때는 캐시가 옛 답을 유지하지 못하도록 빌드 디렉터리를 지우세요.

문제가 소스 자체일 때를 알아두세요

성공한 구성 단계는 점검이 끝났다는 것만 증명합니다. 컴파일은 소스가 기대하는 API를 여전히 거부할 수 있고, 링크는 없는 심볼 때문에 여전히 실패할 수 있습니다. 각 단계의 첫 번째 구체적인 오류를 남기세요, 뒤에 오는 것들은 보통 결과일 뿐입니다.

OpenSSL 3은 오래된 VPN 클라이언트가 직접 쓰는 여러 인터페이스를 폐기하고 제거했으므로, 그 시절의 소스 트리는 새 include 경로가 아니라 실제 변경이 필요할 수 있습니다. 관리자가 현재 릴리스를 지원하면 그것을 쓰세요. 지원하지 않는다면 결정은 서비스를 소유한 쪽의 몫이며, 오래된 라이브러리 파일 이름을 찾는 일이 아닙니다.

선택적 데스크톱 구성 요소에도 각자의 요구가 있는데, 깔끔하게 구성되는 명령줄 대상은 GUI 툴킷과 편집기가 빌드될지에 대해 아무것도 말해 주지 않으므로 오래된 Qt 패키지 목록을 사양이 아니라 역사로 다루세요. 어떤 인터페이스가 기본으로 켜지는지는 소스 리비전 자체의 옵션에서 확인하세요. 그다음 필요한 것만 빌드하세요. 선택적 의존성은 모두 일어나기를 기다리는 또 하나의 탐색 문제입니다.

관련 글