DEVOCEAN

JDK 28에 도입될 Valhalla의 값 객체(Value Object) 배열을 측정해보니 원소당 20바이트에서 8바이트로 줄어들 것으로 예상했던 Long 기반 객체가 오히려 원소당 메모리를 28바이트나 차지했습니다. 개발자가 명세서의 문구만 읽고 기대했던 메모리 절감 효과가 특정 조건에서는 반대로 메모리 팽창으로 돌아온 것입니다.

오늘 고른 세 가지 기록은 공통된 사실을 지적합니다. 프레임워크나 cloud 인프라가 제공하겠다는 이점이 실제 하드웨어 및 실행 환경의 밑바닥 특성과 만날 때 설계자가 계산해둔 수치는 깨지기 쉽습니다. JVM 메모리 배치, 가상 머신(VM)의 물리 자원 경계, 클라우드 재해 복구(DR)의 우선순위라는 세 가지 영역에서 실제 수치와 지표가 말해주는 현장을 다룹니다.

나머지 AI 상담 서비스 및 가자 지구 지도 업데이트 등의 소식은 글 끝에 짧게 모았습니다.

JDK 28 Valhalla 값 객체: 8바이트 필드가 28바이트로 부풀어 오르는 원인

Java의 Valhalla 프로젝트는 객체의 참조 오버헤드를 없애고 힙(Heap, 자바 객체가 저장되는 메모리 공간) 메모리에 데이터만 단단하게 붙여 배치하는 '값 객체(Value Object)' 도입을 목표로 합니다. 하지만 최근 실행된 실험 기록에 따르면, 필드 구성에 따라 메모리가 줄어들기는커녕 더 커지는 현상이 확인되었습니다. 원문은 JDK 28 Valhalla의 값 객체 배열 메모리 측정 기록입니다.

실험 결과를 보면 Integer나 LocalDate를 감싼 값 객체 배열은 원소당 20바이트에서 8바이트로 메모리 사용량이 크게 줄었습니다. 하지만 8바이트 크기인 long 필드 하나만 들고 있는 값 객체는 상황이 달랐습니다. 원소당 메모리가 줄어들지 않았을 뿐만 아니라, 힙 객체 자체의 크기가 16바이트에서 24바이트로 늘어나면서 배열 전체 관점에서는 원소당 28바이트까지 부풀어 올랐습니다.

이 현상이 발생하는 원인은 널 표식(null indicator)과 메모리 정렬(alignment) 규칙에 있습니다. JEP(JDK Enhancement Proposal, 자바 개선 제안서) 명세에는 64비트 경계가 기준이라고 언급되어 있지만, 실제 JVM 내부 동작에서는 널(null) 상태를 구분하기 위한 1바이트 표식이 추가됩니다.

이 1바이트가 추가된 후 JVM은 메모리 접근 효율을 위해 전체 크기를 2의 거듭제곱 단위로 올립니다. 따라서 필드 합이 7바이트 이하인 객체는 널 표식 1바이트가 더해져 8바이트 안으로 딱 접혀 들어가지만, 이미 8바이트를 채운 long 필드 객체는 널 표식 1바이트가 더해지는 순간 9바이트가 됩니다. 그 결과 다음 거듭제곱 단계인 16바이트 영역으로 메모리 요구량이 뛰어넘게 됩니다.

원문이 보여주는 실제 배열 메모리 할당 구조는 다음과 같습니다.

// JDK 28 Valhalla 값 객체 정의 예시
public value class LongWrapper {
    private final long value; // 8 bytes

    public LongWrapper(long value) {
        this.value = value;
    }

    public long getValue() {
        return value;
    }
}

public class MemoryTest {
    public static void main(String[] args) {
        // LongWrapper 배열 생성 시 널 표식(1 byte)과 메모리 정렬에 의해
        // 원소 하나당 8 bytes가 아닌 24 bytes 힙 영역 소비 및 배열 오버헤드 발생
        LongWrapper[] array = new LongWrapper[1000];
        for (int i = 0; i < array.length; i++) {
            array[i] = new LongWrapper(i);
        }
    }
}

실무에서 달라지는 점은 명확합니다. Valhalla가 공식 상용화되더라도 8바이트 단일 필드(long, double)를 보유한 객체를 값 레코드로 변환할 때는 주의해야 합니다. 메모리 절감을 목적으로 무작정 값 객체 전환을 적용하면 힙 메모리 사용량이 증가할 수 있습니다.

이 소식에 대한 DEVOTEE의 판단은 '아직은 지켜볼 단계'입니다. JDK 28의 메모리 인라인 규칙과 널 표식 최적화 방식은 상용 정식 버전 발간 전까지 계속 변경될 수 있으며, 실제 프로덕션 도입 전 반드시 JOL(Java Object Layout) 같은 도구로 실측을 진행해야 합니다.

VMware가 느려졌을 때 게스트 OS 지표가 숨기는 물리 호스트의 진실

가상화 환경에서 가상 머신(VM) 내부의 CPU 사용률이 30%에 불과한데도 애플리케이션 응답 속도가 급격히 떨어지는 현상이 자주 발생합니다. 가상 머신 내부의 게스트 OS(Guest OS) 지표만 모니터링해서는 이 원인을 절대 찾아낼 수 없습니다. 원문은 VMware 모니터링과 호스트 지표입니다.

원문은 가상 머신 성능 저하 시 게스트 OS 지표에 수집되지 않는 대표적인 호스트 지표로 CPU Ready Time, Memory Ballooning, Swap, Host NUMA Imbalance, Storage Latency 등 5가지를 제시합니다.

가장 대표적인 지표는 CPU Ready Time입니다. 이는 가상 머신이 연산을 진행하기 위해 물리 CPU 자원을 할당받으려고 기다리는 시간입니다. 가상 머신 내부에서는 자원을 쓰지 않고 한가하게 대기하는 것으로 보이지만, 실제 물리 호스트 상에서는 다른 가상 머신들이 물리 코어를 점유하고 있어 대기 줄이 길어진 상태입니다.

또한 Memory Ballooning은 물리 호스트의 메모리가 부족해질 때 하이퍼바이저가 특정 가상 머신의 메모리를 강제로 회수하는 기법입니다. 이때 게스트 OS 내부 메모리 사용량 그래프는 정상이지만, 실제 물리 메모리가 할당 해제되어 disk swap으로 이속되면서 I/O 병목을 유발합니다.

[ 물리 호스트 (ESXi Host) 자원 경계 ]
┌─────────────────────────────────────────────────────────┐
│  물리 CPU (Core 0..7)  /  물리 RAM (64GB)                │
└────────────────────────────┬────────────────────────────┘
                             │ (하이퍼바이저 자원 할당)
               ┌─────────────┴─────────────┐
               ▼                           ▼
┌───────────────────────────┐ ┌───────────────────────────┐
│ 가상 머신 A (VM A)         │ │ 가상 머신 B (VM B)         │
│ CPU Ready: High (대기 발생) │ │ Memory Ballooning 회수 작동│
│ 게스트 OS CPU 지표: 25%    │ │ 게스트 OS RAM 지표: 정상   │
└───────────────────────────┘ └───────────────────────────┘

실무 모니터링 체계에서 달라져야 하는 지점은 분명합니다. Datadog이나 Prometheus 기반 시스템을 구축할 때 가상 머신 내부 에이전트 수집 정보만 볼 것이 아니라, ESXi 및 vCenter API와 연동된 호스트 단위 모니터링 지표를 함께 연동해야 합니다.

이 항목에 대한 판단은 '지금 써볼 만하다'입니다. 가상화 인프라를 운영하는 팀이 게스트 지표에만 의존할 경우 원인 불명의 대기 시간 증가를 애플리케이션 코드 문제로 오인하여 쓸데없는 리팩터링에 시간을 허비하게 됩니다. 호스트 지표 5가지를 대시보드에 즉시 추가해야 합니다.

클라우드 DR 설계: 모든 시스템을 동등하게 복구하겠다는 환상 깨기

시스템 재해 복구(DR, Disaster Recovery) 환경을 구축할 때 가장 흔히 범하는 실수는 '모든 서버를 장애 발생 직전 상태로 동일하게 복구하겠다'는 목적을 설정하는 것입니다. AWS Elastic Disaster Recovery(EDR) 기반의 실제 클라우드 복구 사례를 다룬 원문은 웅진프리드라이프의 클라우드 DR 환경 구축입니다.

재해 복구의 핵심 지표는 RTO(Recovery Time Objective, 목표 복구 시간)와 RPO(Recovery Point Objective, 목표 복구 시점)입니다. RTO는 장애 발생 후 몇 시간 내에 서비스를 정상화할 것인가를 의미하며, RPO는 몇 분 전의 데이터까지 손실 없이 복구할 것인가를 뜻합니다.

모든 시스템의 RTO와 RPO를 '0'에 가깝게 맞추려면 실시간 동기화 블록 데이터 복제 인프라와 상시 켜져 있는 미러링 서버가 필요하므로 비용이 기하급수적으로 증가합니다. 원문이 강조하는 핵심은 복구 대상의 분류와 차등화입니다.

결제 및 회원 데이터베이스처럼 핵심 트랜잭션을 처리하는 서버는 RPO를 수 초 단위로 설정하고 실시간 블록 수준 복제를 적용해야 합니다. 하지만 일간 배치 작업 서버이나 내부 통계 시스템은 RTO를 수 시간 단위로 늘리고 Snapshot 기반 백업 및 장애 발생 시 인스턴스 자동 생성 스크립트 실행 방식으로 구성하는 것이 타당합니다.

실무 적용 측면에서 AWS EDR을 도입할 때 설정해야 하는 인프라 구성 예시는 아래 IaC(Infrastructure as Code, 코드 기반 인프라) 형태와 같습니다.

# AWS CloudFormation / Terraform 개념 구조
# 모든 서버가 아닌, 중요도 Tier 1 시스템에만 실시간 Replication 지원 EDR 적용
DisasterRecoveryPolicy:
  Type: AWS::DataReplication::ReplicationConfiguration
  Properties:
    StagingAreaSubnetId: "subnet-12345678"
    AssociateDefaultSecurityGroup: true
    BandwidthThrottling: 500 # Mbps 제한을 통해 운영 네트워크 영향 최소화
    DataReplicationCompressionType: NONE
    DefaultLargeStagingDiskType: GP3
    EbsEncryption: DEFAULT

이 접근법에 대한 판단은 '조건부로 유효하다'입니다. 클라우드 DR 도구가 기술적으로 복제를 자동화해 주더라도, 비즈니스 우선순위에 따라 서비스 등급(Tier 1, Tier 2, Tier 3)을 나누는 내부 정책 수립이 선행되지 않으면 막대한 클라우드 데이터 전송 및 스토리지 비용을 감당하기 어렵습니다.

세 가지 기록이 주는 결론

소프트웨어 스펙과 인프라 설명서가 약속하는 성능과 편의성은 실제 동작 조건에 따라 큰 오차를 만들어냅니다.

1. Java Valhalla의 값 객체는 메모리 널 표식 1바이트와 alignment 경계 때문에 특정 구조에서 오히려 메모리가 늘어납니다.
2. VMware의 가상 머신은 게스트 OS 지표만 봐서는 호스트의 CPU 대기 시간과 메모리 회수 상태를 알아챌 수 없습니다.
3. 클라우드 DR 복제 도구는 비용 효율성을 고려해 시스템별 RTO/RPO 기준을 분리하여 설정해야만 실질적으로 운영 가능합니다.

추상화된 레이어 밑에서 실제 일어나는 수치와 물리 자원 경계를 측정하는 시스템을 마련해야 실질적인 안정성을 확보할 수 있습니다.

도입 전 확인할 것

프로덕션 환경에 위 기술과 접근법을 도입하기 전 다음 세 가지 항목을 먼저 점검해 보시기 바랍니다.

• JVM 버전 업그레이드 전 메모리 측정 도구 확보: JDK 28 값 객체 전환을 검토 중이라면 JOL(Java Object Layout) 플러그인을 빌드 파이프라인에 추가해 필드 구성에 따른 실제 힙 메모리 점유량을 실측하고 계신가요?
• 하이퍼바이저 통합 지표 수집 여부: 가상화 모니터링 대시보드에 게스트 OS 지표 외에 호스트의 CPU Ready Time과 Memory Ballooning 지표가 연동되어 있으신가요?
• DR 복구 등급 분류표 존재 여부: 장애 발생 시 복구할 인프라 전체 목록 중 1시간 이내 복구(Tier 1)와 24시간 이내 복구(Tier 2) 대상이 문서화되어 나누어져 있으신가요?

그 밖의 소식

• 토스뱅크 AI 상담 서비스 도입 사례: 주택담보대출 및 전세대출 단순 서류 문의를 AI 상담으로 전환해 연 300시간의 상담 인력 소모를 절감했습니다. 원문 보기
• 페이페이 리의 World Labs, AMD 합류: 공간 AI 기술 개발 스타트업 World Labs가 AMD에 합류하며 페이페이 리 교수가 AMD 수석과학자로 합류합니다. 원문 보기
• Google for Developers 9월 넷째 주 업데이트: Antigravity SDK의 로컬 AI 모델 지원 및 Android Studio AI 에이전트 확장 소식이 발표되었습니다. 원문 보기
• 구글 지도 라파 지역 업데이트: 가자 지구 라파 도시의 파괴 현황이 구글 지도 위성 사진 최신화로 드러났습니다. 개발 실무와 직접 관련은 없어 링크만 남깁니다. 원문 보기