드디어 올 것이 왔습니다. 지난 2025년 12월 31일을 기점으로 HPE의 유닉스 운영체제인 HP-UX의 표준 기술 지원이 공식적으로 종료되었습니다. 이제 HP-UX는 'Sustaining Engineering' 없이, 그저 산소호흡기만 달아둔 상태로 2028년까지 시한부 인생을 살게 됩니다. 아마 지금 입사한 1~3년 차 주니어 개발자들에게 HP-UX는 박물관에서나 볼 법한 단어일 겁니다. "요즘 누가 유닉스를 써요? 리눅스나 클라우드 쓰지."라며 콧방귀를 뀔지도 모르겠습니다. 하지만 10년 전만 해도 금융권 차세대 프로젝트의 핵심은 언제나 HP-UX와 슈퍼돔(Superdome) 서버였습니다.
제가 LG CNS에서 금융권 차세대 시스템을 구축할 때였습니다. 당시 우리는 HP-UX 위에서 돌아가는 C 프로그램을 x86 리눅스로 이관하는 작업을 맡았습니다. 팀원들은 자신만만했습니다. "어차피 둘 다 POSIX 표준 따르는 유닉스 계열 아닌가요? 컴파일만 다시 하면 돌겠죠."라는 안일한 생각이 지배적이었습니다. 결과는 처참했습니다. Itanium 프로세서와 x86의 메모리 정렬 방식 차이, 엔디안(Endian) 이슈, 그리고 HP-UX 특유의 메모리 관리 기법에 의존하던 레거시 코드들은 리눅스 환경에서 모조리 'Segmentation Fault'를 뱉으며 뻗어버렸습니다.
우리는 밤새 덤프 파일을 분석하며 깨달았습니다. 우리가 비웃던 그 '구닥다리' 코드는 사실 그 당시의 하드웨어 한계를 극한으로 극복하며 작성된, 치열한 생존의 결과물이었다는 것을요. 문제는 그 코드를 작성한 선배들이 비즈니스 로직과 하드웨어 종속성을 분리하지 않았다는 점이었습니다. 그들은 자신들의 플랫폼이 영원할 것이라 믿었을 겁니다. 인텔(Intel)이 아이태니엄(Itanium) 라인업을 포기하고, HP가 x86으로 완전히 돌아설 줄은 꿈에도 몰랐겠죠.
지금 여러분이 작성하고 있는 코드를 돌아보십시오. 클라우드 네이티브니, MSA니 하며 최신 기술 스택을 덕지덕지 바르고 있을 겁니다. 하지만 냉정하게 말해, 그 코드들도 10년 뒤엔 HP-UX 꼴이 납니다. 지금 유행하는 기술 스택이 영원할 것이라는 믿음은 환상입니다. 기사에서도 언급되었듯, 인텔조차 2021년에 아이태니엄 출하를 종료했습니다. 하드웨어가 사라지면 소프트웨어는 갈 곳을 잃습니다. 지금 여러분이 AWS 람다(Lambda)나 쿠버네티스(Kubernetes) 특정 버전에 강하게 결합시킨 비즈니스 로직은, 훗날 플랫폼이 변경될 때 후배 개발자들에게 "도대체 왜 이렇게 짰어?"라는 원망을 듣게 될 기술 부채일 뿐입니다.
특히 '이력서 주도 개발(RDD)'에 빠져 비즈니스의 본질보다 도구의 화려함에 집착하는 분들에게 경고합니다. 코드는 자산이 아니라 부채입니다. 작성하는 순간부터 유지보수 비용이 발생하고, 기술 지원 종료(EOL) 시계는 돌아가기 시작합니다. HP-UX 11i v3가 2025년에 수명을 다한 것처럼, 여러분이 지금 열광하는 프레임워크도 언젠가는 보안 패치조차 지원되지 않는 '레거시'가 됩니다.
SUSE 같은 리눅스 진영은 이번 HP-UX 종료를 기회 삼아 "리눅스로 오라"며 손짓하고 있습니다. 하지만 단순히 OS를 바꾸는 게 능사가 아닙니다. 중요한 건 '이식성'과 '방어적 설계'입니다. 특정 벤더나 특정 기술 스택에 종속되지 않도록 로직을 순수하게 유지하십시오. 화려한 라이브러리 뒤에 숨지 말고, 기본기에 충실해야 합니다.
서버가 다운되고, 데이터가 오염되는 장애 상황에서 여러분을 구하는 건 최신 유행하는 프레임워크가 아닙니다. 시스템의 밑바닥까지 이해하고 있는 엔지니어의 통찰력입니다. HP-UX의 퇴장을 그저 남의 일로 치부하지 마십시오. 그것은 기술의 유행을 좇기보다, 변화 속에서도 살아남을 수 있는 견고한 아키텍처를 고민하라는 묵직한 경고장입니다. 10년 뒤, 당신의 코드는 박수받으며 은퇴할 수 있습니까, 아니면 후배들에게 짐만 남기고 사라지겠습니까?
