IT 업계에는 절대 건드리지 말아야 할 성역 같은 존재들이 있습니다. 리눅스 커널, TCP/IP 스택, 그리고 암호화 라이브러리의 사실상 표준인 OpenSSL이 그렇습니다. 우리는 이들이 언제나 안정적이고, 빠르며, 검증되었다고 믿고 의심 없이 yum update나 apt-get install을 때립니다. 하지만 최근 Python 생태계의 핵심 라이브러리인 pyca/cryptography 메인테이너들이 발표한 문서는 이 믿음이 얼마나 위험한 착각인지 적나라하게 보여줍니다. 저는 평소 "코드는 자산이 아니라 부채"라고 강조해 왔습니다. 그런데 지금 OpenSSL 3.0은 단순한 부채를 넘어, 시스템 전체를 무너뜨릴 수 있는 '악성 채무'가 되어가고 있습니다.
가장 치명적인 문제는 성능 회귀입니다. OpenSSL 3.0은 이전 1.1.1 버전에 비해 키 로딩 속도가 5배에서 8배까지 느려졌습니다. 이게 어느 정도 수치인지 감이 오지 않는다면, 당신이 운영하는 인증 서버의 처리량이 하루아침에 1/5 토막 났다고 상상해보세요. SI 프로젝트에서 이런 일이 발생했다면, 저는 아마 고객사 전산실에 불려가 시말서를 쓰고 있었을 겁니다. 더 절망적인 것은 OpenSSL 팀의 태도입니다. 그들은 "3.0에서 성능 저하는 예상된 것이며, 1.1.1 수준으로 돌아가는 건 기대하지 말라"고 못 박았습니다. 최적화를 통해 3배 느린 수준으로 '완화'되었지만, 여전히 심각한 수준입니다. 반면 pyca/cryptography 팀이 Rust로 직접 짠 X.509 파서는 OpenSSL 3 대비 10배나 빨랐습니다. 복잡한 SIMD 최적화 덕분이 아닙니다. 그저 불필요한 메모리 할당과 락(Lock)을 피했기 때문입니다.
도대체 OpenSSL 내부에서 무슨 일이 벌어진 걸까요. 원인은 과도한 추상화와 잘못된 설계에 있습니다. OpenSSL 3는 OSSL_PARAM이라는 새로운 방식을 도입했습니다. 함수에 명시적인 인자를 넘기는 대신, 키-값(Key-Value) 쌍의 배열을 넘기는 구조입니다. 컴파일 타임에 타입을 체크할 수도 없고, 런타임 오버헤드는 늘어나며, 코드는 지저분해집니다. 더 황당한 건 'Providers'라는 개념입니다. 런타임 중에 SHA-256 같은 기본 알고리즘 구현체를 교체할 수 있게 만든 건데, 상식적으로 실행 중인 애플리케이션에서 해시 함수를 갈아끼울 일이 얼마나 있겠습니까. 이 유연성을 확보하겠답시고 코드 곳곳에 락을 걸고 캐싱 레이어를 추가하다 보니 시스템은 비대해졌고, 이를 해결하겠답시고 리눅스 커널에서나 쓸법한 복잡한 RCU(Read-Copy-Update) 패턴까지 끌고 들어왔습니다.
개발자로서 가장 참을 수 없는 건 코드의 가독성 실종입니다. 저는 주니어들에게 항상 "문제 생기면 라이브러리 소스 까보라"고 시킵니다. 오픈소스는 블랙박스가 아니니까요. 하지만 지금의 OpenSSL 소스는 "자기 학대(self-flagellation)" 수준입니다. C 코드를 직접 짜는 게 아니라, Perl 스크립트로 C 코드를 생성하는 전처리기가 남발되어 있습니다. BoringSSL이나 LibreSSL 같은 대안 구현체들이 직관적인 코드를 유지하는 것과 대조적입니다. 소스 코드를 읽고 동작을 이해할 수 없다면, 그 라이브러리는 통제 불가능한 시한폭탄과 같습니다. 장애 상황에서 디버깅이 불가능하다는 뜻이니까요.
결국 pyca/cryptography 팀은 OpenSSL에 대한 의존성을 걷어내고 Rust 기반의 자체 구현으로 선회하고 있습니다. 이는 단순히 Rust가 유행이라서가 아닙니다. 생존을 위한 지독하게 실용적인 선택입니다. 그들은 불필요한 복잡성을 제거함으로써 전체 X.509 경로 검증 속도를 60%나 끌어올렸습니다. 기술 부채를 갚는 가장 확실한 방법은, 부채를 발생시키는 근본 원인을 도려내는 것임을 증명한 셈입니다.
여러분도 막연히 "최신 버전이 좋겠지"라며 프로덕션 환경의 OpenSSL을 3.0으로 올리지 마십시오. 특히 높은 처리량이 요구되는 API 게이트웨이나 인증 서버를 담당하고 있다면, 반드시 벤치마크를 수행해야 합니다. 때로는 레거시로 남는 것이, 혹은 검증된 대안(BoringSSL, AWS-LC 등)을 찾는 것이 진정한 엔지니어링일 수 있습니다. 기술 스택을 선정할 때 명성보다는 실제 효용과 내부 구조를 들여다보는 습관, 그것이 여러분을 야근과 장애 보고서로부터 구해줄 유일한 무기입니다.
