목차
- OpenSSL 3.0 마이그레이션이 남긴 교훈
- 4.0.0에서 달라진 것
- 디펜던시 체인 — 진짜 병목은 여기다
- 그래서 언제 올리나 — 타이밍 판단 기준
- 스테이징 테스트 전략
- 현실적인 마이그레이션 로드맵
- 급하지 않다면 안 올려도 된다
Before — OpenSSL 3.2가 돌아가는 서버 12대. 인증서 갱신 자동화 세팅 완료, 보안 스캔 통과, TLS 1.3 정상 동작. 건드릴 이유가 없는 상태다.
After — OpenSSL 4.0.0 릴리즈. Hacker News에서 200포인트를 넘기고, 슬랙 보안 채널에 링크가 올라온다. "우리 언제 올려요?"라는 메시지가 달린다. 이 글은 그 질문에 대한 답을 정리한 것이다.
OpenSSL 메이저 버전 업그레이드는 apt upgrade 한 줄로 끝나는 작업이 아니다. Python, Node.js, Nginx, curl — 서버에 물려 있는 거의 모든 것이 OpenSSL에 의존한다. 하나를 올리면 연쇄적으로 전부 확인해야 하고, 하나라도 호환이 안 되면 빌드가 깨진다. OpenSSL 3.0 마이그레이션 때 이걸 직접 겪었고, 4.0.0에서도 같은 구조의 문제가 반복될 수밖에 없다.
OpenSSL 3.0 마이그레이션이 남긴 교훈
4.0.0 얘기를 하기 전에, 3.0 때 무슨 일이 있었는지부터 짚어야 한다. 2021년 9월 OpenSSL 3.0이 나왔을 때, 많은 프로젝트가 1.1.1에서 3.0으로의 전환에 상당 기간 시행착오를 겪었다.
가장 큰 변화는 Provider 아키텍처 도입이었다. 기존 ENGINE API가 deprecated 처리되면서, 커스텀 암호화 모듈을 쓰던 프로젝트는 코드를 전면 수정해야 했다. FIPS 모듈도 완전히 재설계됐다. 공식 문서(OpenSSL 3.0 Migration Guide)에 마이그레이션 가이드가 있긴 했는데, 실제로 부딪히면 문서에 없는 케이스가 속출했다.
필자가 겪은 대표적인 사례가 Python cryptography 패키지 빌드 실패였다. OpenSSL 3.0 초기에 pyca/cryptography가 3.0 바인딩을 완전히 지원하지 않았고, pip install cryptography를 실행하면 컴파일 단계에서 에러가 터졌다. 결국 cryptography 패키지가 공식 지원할 때까지 기다려야 했다. 라이브러리 하나 때문에 OpenSSL 업그레이드 전체가 블로킹된 셈이다.
:::stats OpenSSL 1.1.1 → 3.0 전환에 걸린 시간
- Python cryptography 공식 지원: 릴리즈 후 약 3개월
- Node.js 공식 빌드 지원: Node 17부터 (3.0 릴리즈 약 1개월 후)
- 주요 Linux 배포판 기본 탑재: Ubuntu 22.04 (2022년 4월, 약 7개월 후)
:::
이 경험에서 배운 건 명확하다. OpenSSL 메이저 업그레이드의 병목은 OpenSSL 자체가 아니라 디펜던시 생태계의 대응 속도다.
4.0.0에서 달라진 것
2026년 4월 기준, OpenSSL 4.0.0이 릴리즈된 상태다. 릴리즈 노트와 공식 블로그(openssl.org/blog)에 공개된 내용을 기준으로 주요 변경점을 정리하면 다음과 같다.
Post-Quantum Cryptography 본격 지원
가장 눈에 띄는 변화다. NIST가 2024년에 확정한 PQC 표준 — ML-KEM(구 CRYSTALS-Kyber), ML-DSA(구 CRYSTALS-Dilithium) — 이 기본 Provider에 포함됐다. OpenSSL 3.2~3.4에서 실험적으로 지원하던 것이 4.0에서 정식으로 올라간 것이다. 양자 컴퓨팅 위협이 당장은 아니더라도, 규제 대응이나 정부 프로젝트에서는 PQC 지원 여부가 요구사항에 들어가기 시작했다.
레거시 API 정리
3.0에서 deprecated된 API 중 상당수가 4.0에서 실제로 제거된 것으로 보인다. EVP_PKEY의 일부 저수준 함수, RSA_* 계열 직접 호출 등이 해당된다. 3.0 때 "경고만 뜨고 동작은 했던" 코드가 4.0에서는 컴파일 자체가 안 될 수 있다. 이 부분은 개별 프로젝트마다 영향 범위가 다르니 직접 빌드해봐야 안다.
QUIC 프로토콜 지원 확대
OpenSSL 3.2에서 기초적인 QUIC API가 들어갔고, 4.0에서 더 안정화된 형태로 제공된다. HTTP/3 도입을 고려 중인 프로젝트라면 관심을 가질 부분이다.
변경점을 쭉 보면, 3.0 때만큼의 아키텍처 수준 대격변은 아니다. Provider 구조 자체는 유지되고, 그 위에서 레거시 정리와 PQC 추가가 이뤄진 형태다. 그래서 "3.0보다는 덜 아프겠다"는 기대가 있는데, 이건 반만 맞다.
디펜던시 체인 — 진짜 병목은 여기다
OpenSSL을 직접 호출하는 코드를 작성하는 경우는 드물다. 대부분은 OpenSSL 위에 얹어진 라이브러리를 통해 간접적으로 사용한다. 문제는 이 체인 어딘가 하나라도 4.0을 지원하지 않으면 전체가 막힌다는 것이다.
스테이징 환경에서 OpenSSL 4.0.0을 올려봤더니, 예상대로 첫 번째로 터진 게 Python cryptography 패키지였다. pip install cryptography를 실행하니 Rust 컴파일 단계에서 다음 에러가 나왔다.
error: the OpenSSL version (4.0.0) is not yet supported
--> src/_cffi_src/openssl/binding.py
3.0 때와 정확히 같은 패턴이다. pyca/cryptography GitHub 이슈(github.com/pyca/cryptography)를 확인해보면 4.0 지원 관련 논의가 진행 중인 걸 볼 수 있다. 작성 시점 기준으로 아직 정식 지원 릴리즈는 나오지 않은 상태다.
아래는 주요 디펜던시별 OpenSSL 4.0 지원 상태를 정리한 것이다(2026년 4월 기준, 변동 가능).
| 디펜던시 | 4.0 지원 상태 | 비고 |
|---|---|---|
| Python cryptography | 미지원 (작업 중) | 이슈 트래킹 중, 정식 릴리즈 대기 |
| Node.js | 공식 빌드 미제공 | 차기 LTS에서 지원 예상 |
| Nginx | mainline에서 컴파일 가능 (비공식) | stable 브랜치는 미확인 |
| curl | 7.x 최신 버전에서 지원 | 비교적 빠르게 대응하는 편 |
| Ruby OpenSSL gem | 미지원 | ruby/openssl 이슈 확인 필요 |
이 표는 빠르게 바뀔 수 있다. 프로덕션 적용을 고려한다면 각 프로젝트의 GitHub 이슈를 직접 확인하는 게 정확하다.
그래서 언제 올리나 — 타이밍 판단 기준
"최신 버전이 나왔으니 바로 올려야지"라는 접근은 OpenSSL에서는 위험하다. 반대로 "안정될 때까지 기다리자"만 반복하면 3년째 1.1.1을 쓰게 된다(실제로 그런 서버를 본 적이 있다). 타이밍을 잡으려면 몇 가지 기준이 필요하다.
기준 1: 핵심 디펜던시의 공식 지원 여부
위 표에서 자기 스택에 해당하는 항목이 전부 "지원"으로 바뀌었는지 확인한다. Python 서버라면 cryptography 패키지, Node.js 서버라면 Node LTS 빌드가 핵심이다. 하나라도 미지원이면 무리하지 않는 게 맞다.
기준 2: 4.0.x 패치 릴리즈
메이저 버전의 .0 릴리즈는 초기 버그가 있을 수 있다. OpenSSL 3.0.0도 릴리즈 직후 몇 가지 이슈가 보고됐고, 3.0.1~3.0.2에서 수정됐다. 4.0.1이나 4.0.2가 나올 때까지 기다리는 건 합리적인 전략이다. 보통 1~3개월 안에 첫 번째 패치가 나온다.
기준 3: 보안 압박의 강도
현재 쓰고 있는 3.x 버전에 CVE가 나오고 있는가? 3.x가 아직 보안 지원 기간 내라면 급할 이유가 없다. OpenSSL 프로젝트는 LTS 버전에 대해 보안 패치를 제공하므로, 3.x 최신 패치를 적용하면서 4.0 생태계가 안정되길 기다리는 게 현실적이다. 다만, 3.x의 EOL(End of Life) 일정은 반드시 확인해둬야 한다. OpenSSL Release Strategy에서 각 버전별 지원 종료일을 공개하고 있다.
기준 4: PQC 규제 요구사항
정부 프로젝트나 금융권에서 PQC 지원을 요구하는 경우가 늘고 있다. NIST SP 800-208 같은 표준이 계약 요건에 들어가기 시작하면, 4.0으로 올려야 하는 외부 압력이 생긴다. 이 경우엔 타이밍을 선택할 여지가 줄어든다.
스테이징 테스트 전략
프로덕션에 올리기 전에 스테이징에서 검증하는 건 당연한 얘기인데, OpenSSL 업그레이드는 확인할 항목이 좀 많다.
첫 번째로, 전체 디펜던시를 OpenSSL 4.0 환경에서 빌드해본다. Docker 기반이라면 베이스 이미지를 4.0이 탑재된 것으로 바꾸고 전체 빌드를 돌리는 게 가장 빠르다.
# OpenSSL 4.0 탑재된 베이스 이미지로 교체
FROM ubuntu:26.04
# 빌드 디펜던시 설치 후 전체 앱 빌드
RUN apt-get update && apt-get install -y libssl-dev
# 여기서 빌드 에러가 나면 해당 패키지의 4.0 지원 여부 확인
두 번째로, TLS 핸드셰이크 테스트. 기존 클라이언트가 4.0 서버와 정상적으로 통신하는지 확인한다. 특히 TLS 1.2 하위 호환성, 인증서 체인 검증, mTLS 설정이 깨지지 않았는지 봐야 한다.
세 번째로, 성능 회귀 테스트. 암호화 라이브러리는 성능에 민감하다. 3.0 때 일부 알고리즘에서 1.1.1 대비 성능 저하가 보고된 적이 있다. 4.0에서도 비슷한 일이 생길 수 있으니, 핵심 API의 응답 시간을 비교해둘 필요가 있다. 벤치마크 수치를 직접 측정하지 않았으니 단정은 못 하지만, 체감상 TLS 핸드셰이크 속도에서 차이가 느껴질 수 있다는 보고가 커뮤니티에 올라오고 있다.
현실적인 마이그레이션 로드맵
이론적인 기준은 위에서 다뤘고, 실제로 어떤 순서로 움직이면 되는지 정리하면 이렇다.
1단계 — 현황 파악 (지금 당장)
현재 서버에서 사용 중인 OpenSSL 버전과 의존하는 라이브러리 목록을 뽑는다. openssl version과 패키지 매니저의 dependency tree를 확인하면 된다.
# 현재 OpenSSL 버전 확인
openssl version -a
# Python 환경에서 OpenSSL 바인딩 확인
python3 -c "import ssl; print(ssl.OPENSSL_VERSION)"
# 시스템 패키지 중 libssl에 의존하는 것 목록
apt-cache rdepends libssl3
2단계 — 스테이징 테스트 (디펜던시 지원 확인 후)
핵심 디펜던시가 4.0을 공식 지원하면 스테이징에 올린다. 빌드 성공 여부, TLS 통신, 성능을 확인한다.
3단계 — 프로덕션 적용 (4.0.1 이후)
스테이징에서 문제가 없고 4.0.x 패치가 1~2회 나온 뒤에 프로덕션에 적용한다. 필자 기준으로는 메이저 릴리즈 후 3~6개월이 현실적인 타이밍이라고 본다. 급한 보안 이슈가 없다면.
3.0 때를 돌아보면, 대부분의 프로덕션 환경이 실제로 3.0을 도입한 건 Ubuntu 22.04가 기본 탑재한 2022년 4월 이후였다. 릴리즈 후 약 7개월. 4.0도 비슷한 패턴을 따를 가능성이 높다. 다만 이번에는 PQC 규제 압박이 있어서, 특정 산업군에서는 더 빠르게 움직일 수도 있다.
급하지 않다면 안 올려도 된다
이 말이 무책임하게 들릴 수 있는데, 현실이 그렇다. OpenSSL 3.x가 아직 보안 지원 기간 내라면, 패치만 잘 적용하면 당장 4.0으로 올릴 기술적 이유는 약하다. PQC가 필요하지 않고, 레거시 API를 쓰지 않고 있다면 더욱 그렇다.
급해지는 시점은 두 가지다. 3.x EOL이 가까워질 때, 그리고 사용 중인 디펜던시가 4.0 이상만 지원하기 시작할 때. 이 두 시점 중 먼저 오는 쪽에 맞추면 된다.
현재 스테이징에 4.0.0을 올려둔 상태에서 cryptography 패키지 지원을 기다리고 있다. 이게 풀리면 전체 빌드를 돌려보고, 문제 없으면 4.0.1 릴리즈에 맞춰서 프로덕션 하나를 카나리로 올려볼 생각이다.
관련 글
- 로컬 LLM 보안 운영 — Ollama로 사내 데이터 유출 없이 AI 쓰는 법 – 사내 외부 LLM API가 차단된 뒤 Ollama로 로컬 LLM 보안 운영 환경을 구축했다. 기본 설정의 보안 구멍부터 네트워크 격리, 접…
- Trivy로 컨테이너 이미지 취약점 스캔을 CI/CD에 붙인 3개월 회고 – 프론트엔드에서 백엔드로 넘어오고 나서 처음 맡은 컨테이너 보안 스캔 자동화. Trivy를 GitHub Actions에 붙이면서 겪은 시행착…
- Prometheus Grafana 알람 Slack 연동 설정 — 웹훅·임계값 튜닝·온콜 라우팅 – Prometheus alerting rules 작성부터 Alertmanager Slack 웹훅 연동, group_wait·repeat_in…
