AI를 사용하여 AI 메모리 가격 책정에 맞서기

보십시오, 저희도 여러분의 목소리를 듣고 있습니다. 모든 미니 워크스테이션 리뷰, AI 시스템 리뷰, GPU 리뷰, 서버 리뷰, 심지어 라우터의 메모리 추가 비용에 이르기까지 마찬가지입니다. 메모리 가격이 폭등하기 전에는 메모리가 하드웨어 비용 중 1순위였습니다. 이제는 우리가 배포하고자 하는 시스템을 위해 메모리를 구매하는 것조차 감당하기 어려울 정도입니다. 올해 서버를 배포해야 하기에, 저는 한 가지 생각을 했습니다. 만약 AI를 사용하여 메모리 가격 책정에 맞서 대응할 수 있다면 어떨까요? 아이디어는 간단했습니다. AI를 사용하여 우리가 실제로 얼마나 많은 메모리를 사용하는지 프로파일링 (Profiling)하고, 서버를 구매 및 배포하기 위한 비즈니스 케이스 (Business case)를 구축하는 것입니다. 여기에는 세 가지 핵심 질문이 있었습니다. 첫째, 우리가 실제로 얼마나 많은 메모리를 사용하는지 파악해야 했습니다. 머신에 더 많은 메모리를 장착하는 것은 오버프로비저닝 (Overprovisioning) 비용이 상대적으로 낮았던 "이전 시대"의 사치였습니다. 이제는 그렇게 할 여유가 없습니다. 그것은 더 적은 수의 노드 (Nodes)를 배포해야 함을 의미하기 때문입니다. 둘째, 성능을 저하시키지 않으면서 배포에 필요한 메모리 용량의 비용을 낮추는 방법을 찾아야 했습니다. 셋째, 더 저렴한 메모리 구성 (Configuration)을 선택하여 성능 손실이 발생한다면, 그 절감액으로 손실을 상쇄하고도 남을 만큼의 추가 코어 (Cores)나 시스템을 구매할 수 있는지 알고 싶었습니다. 많은 이들에게 이것은 무섭게 들리거나, 혹은 우리가 테스트 랩 (Testing lab)을 보유하고 있기 때문에 우리만이 할 수 있는 일처럼 들릴 수도 있습니다. 단순히 "이렇게 하라"고 말하는 대신, 여러분의 환경을 프로파일링하는 방법에 대한 몇 가지 생각과 메모리 구성 (Memory population)이 왜 중요한지에 대한 데이터 포인트를 제공하고자 합니다.

소규모에서 대규모까지 워크로드 프로파일링 (Profiling Workloads)

요즘 대부분의 사람들은 이미 어떤 종류의 인프라 (Infrastructure)를 갖추고 있습니다. 그것은 VPS나 클라우드 인스턴스 (Cloud instance), 실험실 서버와 같이 작을 수도 있고, 서버 플릿 (Fleet of servers)처럼 클 수도 있습니다. 다행히 그것이 무엇이든, 메모리 사용량을 모니터링 (Monitor)할 수 있는 방법은 존재합니다.

VMware 환경에서는 보통 가상화 계층 (Virtualization layer)을 가장 먼저 확인합니다. ESXi와 vCenter는 호스트 메모리 소비량 (Host memory consumption), 활성 메모리 (Active memory), 벌루닝 (Ballooning), 압축 (Compression), 그리고 스와핑 (Swapping)을 보여줄 수 있습니다. 이 중 마지막 세 가지가 특히 중요합니다. 메모리 소비율이 높게 유지되는 호스트는 단순히 메모리를 효율적으로 사용하고 있는 것일 수 있지만, 벌루닝 (Ballooning)이나 스와핑 (Swapping)이 발생하는 호스트는 적정 규모 산정 (Right-sizing)이 이미 너무 과하게 이루어졌음을 알려주는 것입니다. 이 연습에서 우리가 관심을 가져야 할 숫자는 "메모리가 얼마나 설치되어 있는가?"가 아닙니다. 그것은 "캐시 (Cache)와 일반적인 OS 관리 작업 (OS housekeeping)을 제외한 후의 지속적이고 정점인 워킹 셋 (Working set)은 무엇인가?"입니다.

Proxmox VE, KVM, Hyper-V, Nutanix, XCP-ng 또는 다른 가상화 스택을 사용하는 경우에도 동일한 개념이 적용됩니다. 호스트 레벨에서는 메모리 압박 (Memory pressure), 스왑 활동 (Swap activity), 벌루닝 (Ballooning), 그리고 NUMA 불균형 (NUMA imbalance)을 확인하십시오. 게스트 레벨에서는 OS 관점의 지표를 확인하십시오: Linux의 MemAvailable, 페이지 폴트 (Page faults), 스왑 인/아웃 (Swap in/out), PSI 메모리 압박 (PSI memory pressure), cgroup 또는 컨테이너 메모리 제한 (Container memory limits), 그리고 Windows의 커밋된 바이트 (Committed bytes), 워킹 셋 (Working set), 하드 폴트 (Hard faults) 등이 있습니다. 위험한 지름길은 "여유 메모리 (Free memory)"만 보고 나머지는 모두 필요하다고 가정하는 것입니다. 현대의 운영 체제는 사용되지 않는 DRAM은 낭비되는 DRAM이기 때문에 캐시 (Cache)를 위해 메모리를 공격적으로 사용합니다. 해당 캐시는 종종 회수 (Reclaim)될 수 있습니다. 데이터베이스 버퍼 풀 (Database buffer pool), JVM 힙 (JVM heap), 또는 고정된 메모리 (Pinned memory)를 사용하는 AI 추론 서비스 (AI inference service)는 이야기가 다릅니다.

단일 워크스테이션(Workstation)이나 소규모 서버의 경우, Task Manager, Resource Monitor, top, htop, free, vmstat, sar, 또는 Netdata만으로도 시작할 수 있습니다. 핵심은 적절한 기간(window) 동안 데이터를 수집하는 것입니다. 5분간의 스냅샷(Snapshot)은 용량 계획(Capacity plan)이 될 수 없습니다. 백업 시간대, 패칭(Patching), 인덱스 재구축(Index rebuilds), 모델 로드(Model loads), 월말 작업, 그리고 고객 트래픽 피크(Peak)를 포함하는 한 달간의 데이터가 훨씬 더 낫습니다. 대규모 플릿(Fleets)의 경우, Prometheus와 node_exporter, Grafana, Telegraf, Zabbix, Datadog, New Relic, CloudWatch, Azure Monitor, Google Cloud Monitoring 또는 기존의 관측성 플랫폼(Observability platform)이 활용되는 지점입니다. Kubernetes 환경에서는 kube-state-metrics, cAdvisor, 컨테이너 메모리 요청(Requests) 및 제한(Limits), 그리고 포드(Pods)가 OOM-kill(Out-of-Memory kill)되거나 스로틀링(Throttled)되는지 여부로 이야기가 확장됩니다. 물론 여러분이 사용 중인 다른 도구들도 있겠지만, 대략적인 개념은 이해하셨기를 바랍니다.

우리의 파일럿(Pilot) 프로젝트에서는 일회성 스크린샷 이상의 것을 원했습니다. 핵심은 정상적인 비즈니스 활동, 유지보수 시간대, 그리고 한가한 오후를 기준으로 적정 규모 산정(Right-sizing)을 하는 실수를 피할 수 있을 만큼 충분한 일일 변동성을 포착할 수 있는 기간을 확보하는 것이었습니다.

이 첫 번째 단계에서 우리가 얻고자 하는 결과물은 용량 목표(Capacity target)입니다. 예를 들어, 어떤 서버에 512GB가 설치되어 있더라도, p95 재할당 가능 조정 사용량(Reclaimable-adjusted usage)이 170GB이고 p99가 220GB라면, "항상 해오던 방식이니까"라는 이유로 또 다른 512GB 서버를 구매하는 것은 비용이 많이 드는 습관적 행동(Muscle memory)입니다. 어쩌면 해당 워크로드(Workload)에는 여유 공간을 포함한 256GB가 정말로 필요할 수도 있습니다. 혹은 분기별 스파이크(Spike)가 있기 때문에 384GB가 필요할 수도 있습니다. 아니き는 미스(Miss) 발생 시 비용이 많이 드는 데이터베이스나 캐시 계층(Cache tier)이므로 건드리지 말아야 한다는 것이 답일 수도 있습니다. 중요한 점은 2026년 가격으로 메모리를 구매하기 전에 우리가 어떤 선택을 해야 할지 알고 있어야 한다는 것입니다.

이 첫 번째 검토 과정에서 나온 불편한 헤드라인은, 과거에 오버프로비저닝(Overprovision)하는 비용이 저렴했기 때문에 얼마나 많은 메모리가 배치되어 있었는가 하는 점이었습니다. 그것이 바로 우리가 다음 시스템 물량을 구매하기 전에 수치화하여 바로잡으려는 습관입니다.

이전에는 단일 시스템이나 VM (Virtual Machine)에 대해 이를 수행하는 것이 쉬웠습니다. 모니터링이 잘 되어 있다면, 무엇을 해야 하는지 알고 있다는 전제하에 대규모 플릿 (fleet)에 대해 수행하는 것도 매우 일반적인 분석 작업이기에 비교적 사소한 일이었습니다. AI를 사용하여 이 데이터를 가져와 분석을 수행하고 권장 사항을 도출하는 단계에서 비로소 매우 유용해집니다. 현대적인 AI 에이전트 (상당히 큰 규모의 모델 기반)를 사용하면 수백 또는 수천 대의 가상 또는 물리적 머신에 걸쳐 인간이 포착하기 어려운 패턴을 요약할 수 있습니다. 예를 들어, 실제 워킹 셋 (working set)이 40%를 넘지 않는 시스템은 무엇인지, 백업 중에만 피크 (peak)가 발생하는 시스템은 무엇인지, 할당량은 높지만 p95 사용량이 낮은 VM은 무엇인지, 어떤 노드에 스왑 (swap) 활동이 있는지, 그리고 어떤 워크로드 (workload)가 명확하게 메모리 상주형 (memory-resident)이어서 공격적인 삭감 대상에서 제외되어야 하는지 등을 파악할 수 있습니다. 시스템이 몇 대 없거나 단순히 VPS (Virtual Private Server)를 운영하며 이를 정기적으로 수행하지 않는 많은 사람들에게, 이 작업은 더 작은 VPS로 이동하여 매달 몇 달러를 아낄 수 있는지에 대한 답을 얻을 수 있는 간단한 과제입니다. 반대편에는 VMware는 알지만 다른 도구는 모르는 사람들이 있을 수도 있습니다. AI 에이전트는 데이터에 접근할 수만 있다면 통찰력 (insights) 생성을 민주화하는 데 도움을 줍니다. AI 에이전트가 아무리 자신감 있게 말하더라도 여전히 인간의 검토가 필요할 가능성이 높지만, 적어도 시작점을 제공하며 서로 다른 AI 에이전트와 프롬프트 (prompt)를 사용하여 두 번째, 세 번째, 그리고 그 이상의 의견을 얻을 수 있는 상대적으로 저비용의 옵션을 제공합니다.

이 지점에서 시각화 (visualization)가 중요해집니다. 호스트 (host) 목록이 담긴 표는 문제를 추상적으로 느끼게 만들 수 있지만, 할당량 대비 관측값 (allocated-versus-observed) 뷰는 유휴 자원 (slack)이 어디에 집중되어 있는지, 어떤 시스템을 우선적으로 인간이 검토해야 하는지를 빠르게 보여줍니다.

다음은 에이전트의 출력을 여전히 사람이 검토해야 하는 이유에 대한 작은 예시입니다. 웹 프런트엔드 (web frontend)는 p95 및 p99가 현재 설정보다 훨씬 낮게 유지된다면, 특히 변경 사항을 되돌릴 수 있는 경우라면 할당량을 줄이기에 쉬운 후보가 될 수 있습니다.

데이터베이스 사례는 다릅니다. 그런 경우에는 단순히 VM (Virtual Machine) 규모를 축소하고 승리를 선언하는 대신, 메모리를 일시적으로 늘리는 (ballooning) 방식이나 다른 가역적인 (reversible) 정책을 사용하는 것이 더 나은 답일 수 있습니다.

플릿 (fleet) 수준에서의 목표는 이러한 개별적인 결정들을 하나의 메모리 회수 계획으로 전환하는 것입니다. 중요한 부분은 단순히 용량을 회수하는 것만이 아닙니다. 팀이 그 결과를 신뢰할 수 있도록 충분한 프로세스를 갖추어 회수하는 것이 중요합니다.

불편한 사실은 우리가 단지 메모리가 저렴하다는 이유만으로 아마도 약 25% 정도 메모리를 과다 배포 (overdeploy) 했을 것이라는 점입니다. 예전에는 그것이 큰 문제가 아니었으며, 여유 공간 (headroom)을 갖는 것은 좋은 일이었습니다. 하지만 요즘에는 그것이 플릿을 위한 서버 여러 대를 구매하느냐 마느냐의 차이를 만들 수 있습니다. 또한, AI 이전에는 이러한 분석을 수행하기 위해 시간과 자원을 쓰는 것이 그저 "조금 더 넉넉하게 배포하면 괜찮을 거야"라고 말하는 것과 다를 바 없었을지도 모릅니다. 오늘날에는 AI를 활용하여 이를 분석할 Python 스크립트를 작성할 수 있기 때문에, 여러 시스템, VM, 그리고 컨테이너에 걸친 데이터를 분석하는 비용이 극적으로 낮아졌습니다. 다시 한번, 결과에 대한 건전성 검사 (sanity check)를 수행하십시오.

우리가 실제로 얼마나 많은 메모리를 사용하고 있었는지에 대한 개념을 파악한 후, 다음 단계는 시스템에 메모리를 실체화 (materialize) 하는 방식 또한 최적화할 수 있는지 결정하는 것이었습니다. 다음 내용으로 넘어가 보겠습니다.