코딩 테스트에서 Short가 오히려 독이 될 수 있는 상황(JVM 내부 동작)

알고리즘 문제를 풀거나 자바를 공부하다 보면 문득 이런 의문이 생깁니다. "주어지는 숫자의 범위가 작으니까, 4바이트인 int 대신 2바이트인 short를 쓰면 메모리를 절반으로 아끼고 성능도 좋아지지 않을까?" 하는 생각입니다.

결론부터 말씀드리면, 일반적인 지역 변수 선언에서는 메모리가 전혀 절약되지 않으며 오히려 연산 속도만 미세하게 느려집니다. 그 이유를 JVM(자바 가상 머신)의 동작 원리와 함께 파헤쳐 보겠습니다.

1. JVM의 기본 처리 단위는 32비트입니다 (Operand Stack)

JVM이 메서드 내부에서 연산을 수행할 때 사용하는 작업 공간을 오퍼랜드 스택(Operand Stack)이라고 부릅니다. 중요한 점은 이 스택의 한 칸(Slot) 크기가 기본적으로 32비트(4바이트)라는 것입니다.

int 타입은 4바이트이므로 이 공간에 딱 맞게 들어갑니다. 하지만 2바이트인 short나 1바이트인 byte가 연산을 위해 스택에 올라갈 때는 빈 공간을 패딩(Padding)으로 채워 넣어 강제로 32비트 크기의 int형으로 부풀립니다. 이를 타입 프로모션(Type Promotion)이라고 합니다.

결국 short 변수를 선언해 보았자, JVM 내부에서 계산될 때는 어차피 4바이트 공간을 차지하므로 메모리 절약 효과는 '0'입니다.

2. 불필요한 강제 형변환(Casting) 비용 발생

메모리를 아끼지 못하는 것을 넘어, 연산 과정에서 오히려 비효율이 발생합니다. 자바에서는 short 끼리 사칙연산을 하면 그 결과값이 자동으로 int 타입으로 반환됩니다.

Java

 

short a = 10;
short b = 20;

// short c = a + b; // ❌ 컴파일 에러 발생 (a+b의 결과는 int 타입입니다)
short c = (short) (a + b); // ✅ 컴파일을 위해 매번 강제 형변환을 해주어야 합니다

위 코드처럼 결과값을 다시 short 변수에 담으려면 매번 (short)로 다운 캐스팅을 명시해 주어야 합니다. 이 과정에서 불필요한 형변환 연산이 추가되어 CPU 사이클을 낭비하게 됩니다.

3. 예외: 배열(Array)을 사용할 때는 진짜로 절약됩니다

그렇다면 short나 byte는 자바에서 완전히 무용지물인지 의문이 들 수 있습니다. 하지만 전혀 그렇지 않습니다. 배열을 생성할 때는 실제로 메모리가 절약됩니다.

변수 하나하나가 오퍼랜드 스택에 올라가는 것과 달리, 배열은 힙(Heap) 영역에 연속된 메모리 공간으로 할당됩니다.

• int[] arr = new int[10000]; ➡️ 약 40KB 차지합니다.
• short[] arr = new short[10000]; ➡️ 약 20KB 차지합니다.

힙 영역에서는 short의 2바이트 크기가 정직하게 적용되므로, 정확히 절반의 메모리만 사용합니다.

🎯 결론 및 코딩 테스트 전략

• 첫째, 기본 정수형은 무조건 int를 사용합니다. (int 범위를 넘어가면 long을 사용합니다)
• 둘째, short나 byte를 지역 변수로 선언하는 것은 메모리 최적화에 아무런 도움이 되지 않으며 가독성만 해칩니다.
• 셋째, 단, BFS나 DP 같은 코딩 테스트 문제를 풀 때 메모리 제한이 극단적으로 빡빡하고 2차원 이상의 거대한 배열을 선언해야 한다면, 그때는 short[][] 또는 byte[][] 배열 사용을 고려합니다.