월요일 아침 9시, 팀장님이 커피 한 잔을 들고 다가와 내 책상 모서리를 툭툭 쳤습니다.
팀장님: “김 차장, 이번 차세대 인프라 기획 알지? 이사회 지시 사항이야. 기존 메인 DB 다 **U2L(Unix-to-Linux)**로 전환하는 걸로 검토안 짜와. 클라우드 느낌 나게 대시보드도 착 붙이고.”
나: “팀장님, 지금 계정계 IBM Power 시스템 7년 동안 장애 한 번 없었던 거 아시죠? 밤에 전화 한 번 안 올 정도로 효자 장비인데요…”
팀장님: “아, 요즘 다 리눅스로 가잖아! 트렌드 몰라? 비용도 아끼고 유연하게 오픈소스로 가야지. 이번 주까지 보고서 작성해 와.”
자리에 앉아 한숨을 쉬며 아키텍처 그리기를 시작했습니다. 그리고 정확히 사흘 뒤, 나는 머리를 쥐어뜯으며 모니터 앞에서 망연자실하고 있었습니다.
1. 아키텍처를 그릴수록 늘어나는 ‘더러운 레이어’의 비극
처음엔 단순했습니다. ‘IBM Power 박스 빼고, x86 박스 넣고, RHEL 올리면 끝나겠지?’
하지만 현실은 가혹했습니다. 레거시 유닉스 장비 한 대가 하던 일을 x86으로 옮기려니, 검토해야 할 레이어(Layer)가 괴물처럼 증식하기 시작했습니다.
- 가상화 하이퍼바이저의 난제: VMware를 쓰자니 최근 라이선스 과금 체계 변경으로 예산이 미쳐 날뛰고, OpenShift나 KVM을 쓰자니 기존 DB 엔지니어들이 거세게 반발합니다.
- CMP(클라우드 관리 포털)의 늪: “클라우드처럼 보이게 해달라”는 요청에 대시보드(CMP) 솔루션을 알아봤더니, 배보다 배꼽이 더 큽니다. 가상화 얹고, 클라우드 포털 얹고, 모니터링 툴 얹고… 복잡성이 3배는 늘어났습니다.
- SW 라이선스 폭탄: 목표 TPS(초당 트랜잭션)를 맞추려면 x86 코어 수를 2.5배는 더 늘려야 했습니다 (확인되지 않음). 오라클(Oracle) 견적서를 뽑아보니 DB 코어 라이선스 비용이 서버 하드웨어 값을 훌륭하게 아득히 뛰어넘었습니다.
기존 IBM Power 환경에선 [하드웨어 ➔ PowerVM ➔ AIX ➔ DB] 로 끝나던 깔끔한 3-Tier 아키텍처가, x86으로 오면서 7~8개 레이어로 꼬여버린 것입니다.
“장애가 나면 나는 도대체 어느 벤더에 전화해야 하지? x86 HW업체? OS업체? 가상화업체? 포털업체?”
책임 핑퐁(Ping-pong)의 지옥도가 눈앞에 선했습니다. 트렌드를 쫓으려다 내가 매일 야근하고 주말에 장애 콜 받으며 피 말라 죽을 게 뻔했습니다.
2. 반전: 우리가 너무 익숙해서 잊고 있었던 ‘IBM Power’의 반격
이대로는 죽겠다 싶어, ‘조직을 설득할 명분’을 찾기 시작했습니다. “과연 우리가 Unix를 버려야만 현대화(Modernization)가 가능한가?”
IBM Power 시스템의 최신 장표와 기술 백서를 다시 꺼내 들었습니다. 그리고 깨달았습니다. 우리가 수년간 너무 공기처럼 편하게 써서, 이 장비가 얼마나 괴물 같은 클라우드 기능을 이미 품고 있었는지 까먹고 있었다는 사실을요.
① “클라우드 포털? PowerVC가 이미 다 하는데요?”
x86에 별도 CMP 포털을 억지로 얹을 필요가 없었습니다. IBM은 이미 PowerVC라는 OpenStack 기반의 프라이빗 클라우드 관리 솔루션을 제공하고 있었습니다. 파티션 프로비저닝, 자원 할당, REST-API 연동까지 클릭 한 번으로 끝납니다. 유닉스도 이미 완벽한 ‘프라이빗 클라우드’였습니다.
② “DR 센터로 자원을 무료로 이동시킨다고?”
가장 소름 돋았던 건 Enterprise Pool 2.0 (공유 유틸리티 용량)이었습니다. 메인 센터와 DR 센터의 Power 서버를 하나로 묶으면, 메인 센터에서 쓰던 CPU/Memory 자원이 비상시에 DR 센터로 분 단위로 자동 공유됩니다. DR 센터에 비싼 정적 라이선스를 100% 사둘 필요 없이, 실제 쓴 만큼만 차감되는 클라우드 요금제(Opex) 구조가 이미 완성되어 있었습니다.
③ “메모리 대란 시대, x86이 더 비싸다!”
최근 반도체 대란으로 x86 서버 견적이 과거 대비 3~4배 뛰었습니다 (확인되지 않음). 메모리 슬롯 몇 개 더 꽂으려다 섀시 전체를 추가해야 하는 x86과 달리, IBM Power11은 코어당 성능(SMT8, 최대 4.4GHz)이 월등히 높아 필요한 코어 수 자체를 1/2~1/3로 줄여줍니다. 서버 대수도 줄고, 코어당 과금되는 오라클 라이선스 비용도 억 단위로 찢어발길(?)(절감할) 수 있다는 계산이 나왔습니다.
3. 이사회와 팀장을 설득한 4가지 ‘핵심 논리’ (저장용)
보고서의 방향을 U2L(Linux 전환)에서 U2U(Power11 차세대)로 전격 수정했습니다. 그리고 윗분들이 좋아하는 키워드로 딱 4가지를 정리해 보고서 첫 장에 집어넣었습니다.
┌────────────────────────────────────────────────────────────────────────┐│ [보고서 요약] 차세대 메인 인프라 U2U(Power11) 재전환 검토안 │├────────────────────────────────────────────────────────────────────────┤│ 1. TCO 혁신: x86 가격 폭등 대비, 코어 수 50% 절감으로 SW 라이선스 절감││ 2. 복잡성 제로: 가상화/CMP 추가 레이어 없이 단일 패브릭 통합 ││ 3. 보안 철옹성: Linux 대비 보안 취약점 노출 위험 획기적 감소 ││ 4. 가용성 1위: Live Kernel Update로 OS 패치 시에도 DB 재부팅 제로 │└────────────────────────────────────────────────────────────────────────┘
📌 조직 설득 카드 (포스트잇에 적어두세요)
- “트렌드보다 중요한 건 ‘돈’과 ‘안정성’입니다.”
- x86으로 가면 서버 값은 싸 보일지 몰라도 코어 수 증가로 오라클 라이선스와 유지보수비(MA)가 폭등합니다. Power11은 코어 수를 줄여 SW TCO를 가장 강력하게 다이어트시킵니다.
- “레이어가 늘어나면 담당자는 죽어납니다.”
- x86 가상화+K8s+CMP 조합은 장애 발생 시 책임 소재 규명이 불가능합니다. HW-가상화-OS가 단일 지원 체계(Single Contact Point)인 IBM Power가 장애 복구 속도 1위입니다.
- “재부팅 없는 인프라, 들어보셨습니까?”
- IBM Power11의 AIX Live Kernel Update는 OS 패치 시에도 DB를 끄지 않습니다. 주말 새벽 출근 패치 작업에서 해방될 수 있습니다.
- “양자 내성 암호(PQC)와 랜섬웨어 1분 복구”
- Power Cyber Vault를 통해 랜섬웨어가 침투해도 1분 이내에 변작 불가능한 스냅샷으로 원장을 복구합니다. 요즘같이 보안 사고 터지면 대표님이 옷 벗는 시대에 이보다 완벽한 방패는 없습니다.
🔚 에필로그: 보고서를 제출하고 난 뒤
금요일 오후, 수정한 보고서를 팀장님 책상에 올려두었습니다. 보고서를 쓱 훑어보던 팀장님의 눈빛이 바뀌었습니다. 특히 “오라클 라이선스 수억 원 절감”과 “장애 시 단일 창구 대응” 대목에서 고개를 끄덕이더군요.
팀장님: “김 차장… x86 가상화 레이어 꼬이는 거랑 라이선스 비용 계산해 온 거 맞냐? 이거 이대로 임원 보고 들어가면 U2L 안 한다고 다들 안도하겠는데?”
나: “팀장님, 메인 시스템은 화려한 트렌드를 쫓는 시험대가 아닙니다. 기업의 자산을 지키는 ‘철통같은 방패’여야 합니다.”
퇴근길, 가벼운 발걸음으로 지하철을 탔습니다.
혹시 지금 이 순간에도 위에서 내려온 “U2L 무조건 검토해 봐”라는 지시 때문에, 복잡해진 x86 레이어와 라이선스 견적서 앞에서 머리를 쥐어뜯고 계신 인프라 담당자분이 계신가요?
그렇다면 잠시 멈춰 서서 스스로에게 물어보세요. 우리가 진짜 버려야 할 것이 ‘유닉스’인지, 아니면 ‘남들이 가니까 맹목적으로 쫓아가려 했던 트렌드의 환상’이었는지를요.
이 글을 저장해두셨다가, 다음 주 인프라 기획 회의 때 슬그머니 꺼내보시기 바랍니다. 여러분의 주말과 평정심을 지켜줄 가장 강력한 무기가 되어줄 것입니다.
