Backend/Java

자바 변수와 자료형: 왜 String은 기본 타입이 아닐까?

미니임 2026. 3. 3. 23:48

 

자바(Java)를 처음 접할 때 우리를 가장 먼저 당황하게 만드는 것은 **'타입(Type)'**의 이분법적인 구조입니다. int, double 같은 녀석들은 소문자로 시작하며 가볍게 쓰이는데, 유독 문자열을 다루는 String만은 대문자로 시작하며 '클래스'라는 무거운 이름을 달고 있죠.

단순히 문자의 집합일 뿐인 String이 왜 메모리를 직접 점유하는 **기본 타입(Primitive Type)**의 지위를 얻지 못했는지, 그 이면에 숨겨진 자바의 설계 철학과 메모리 관리 전략을 깊이 있게 파헤쳐 보겠습니다.

1. 메모리 설계의 철학: 고정 크기 vs 가변 크기

자바의 자료형은 크게 **기본 타입(Primitive Type)**과 **참조 타입(Reference Type)**으로 나뉩니다. 이 둘을 가르는 가장 결정적인 잣대는 "데이터의 크기를 컴파일 시점에 확정할 수 있는가?"입니다.

1-1. 정해진 규격의 상자, 기본 타입

int는 4바이트, double은 8바이트로 그 크기가 엄격하게 정해져 있습니다. 컴퓨터 입장에서는 메모리 상에서 다음에 올 데이터가 어디에 위치할지 예측하기 매우 쉽죠. 이는 스택(Stack) 영역에서 매우 빠르게 할당되고 소멸됩니다.

1-2. 예측 불가능한 거인, String

반면 문자열은 "A" 한 글자일 수도 있고, 백과사전 한 권 분량일 수도 있습니다. 만약 String이 기본 타입이었다면, 자바는 변수를 선언할 때마다 메모리 공간을 얼마나 예약해야 할지 몰라 갈팡질팡했을 것입니다.

따라서 자바 설계자들은 String을 참조 타입으로 분류하고, 실제 데이터는 힙(Heap) 영역에, 그 주소값(포인터)만 스택 영역에 보관하는 방식을 택했습니다.

2. String의 핵심: 불변성(Immutability)과 Pool의 마법

String이 클래스로 설계된 가장 큰 이유는 바로 메모리 최적화와 보안 때문입니다. 여기서 자바만의 독특한 개념인 String Constant Pool이 등장합니다.

왜 불변(Immutable)이어야 하는가?

자바의 String 객체는 한 번 생성되면 그 내부 값을 절대 바꿀 수 없습니다. 우리가 흔히 하는 str = str + "add"; 연산은 기존 문자열을 수정하는 게 아니라, 새로운 String 객체를 생성하는 작업입니다.

이런 비효율을 감수하면서까지 불변성을 유지하는 이유는 무엇일까요?

  1. 캐싱(Caching): 똑같은 내용의 문자열이 프로그램 전체에서 수천 번 쓰인다면, 이를 매번 새로 만드는 대신 힙 영역의 'Pool'에 하나만 저장해두고 공유(Share)하기 위함입니다.
  2. 보안(Security): 네트워크 연결이나 데이터베이스 비밀번호가 String으로 전달되는 경우가 많습니다. 만약 누군가 참조값을 통해 원본 문자열을 슬쩍 바꿀 수 있다면 심각한 보안 홀이 생기겠죠.

3. 실전 예제: 주문 번호 생성 로직으로 본 String 활용

단순한 예제 대신, 이커머스 시스템에서 흔히 볼 수 있는 '가독성 있는 주문 번호 생성' 로직을 통해 String의 작동 원리를 코드로 살펴봅시다.

Java
 
public class OrderService {
    public String generateOrderCode(String userId, long orderSequence) {
        // 1. 접두어 설정 (String Pool 활용)
        String prefix = "ORD"; 
        
        // 2. 날짜 포맷팅 (불변 객체 생성)
        String datePart = java.time.LocalDate.now().toString().replace("-", "");
        
        // 3. 효율적인 문자열 결합 (StringBuilder 활용)
        // String + String 연산은 내부적으로 StringBuilder를 만들지만, 
        // 루프나 복잡한 결합에서는 명시적으로 사용하는 것이 성능상 유리합니다.
        StringBuilder sb = new StringBuilder();
        sb.append(prefix)
          .append("-")
          .append(datePart)
          .append("-")
          .append(String.format("%05d", orderSequence))
          .append("-")
          .append(userId.substring(0, 3).toUpperCase());

        return sb.toString(); // 최종적으로 새로운 String 객체 반환
    }
}

코드 분석 및 팁

  • prefix: "ORD"는 String Pool에 저장되어 동일한 메서드가 호출될 때 재사용됩니다.
  • StringBuilder: + 연산자를 반복해서 사용하면 그때마다 새로운 String 객체가 생성되어 메모리 파편화가 발생합니다. 가변적인 결합이 3회 이상 일어난다면 StringBuilder를 쓰는 것이 정석입니다.
  • substring(): 원본 문자열을 자르는 것처럼 보이지만, 사실 잘린 형태의 새로운 String 객체를 반환합니다.

4. 트러블슈팅: ==와 equals()의 늪

많은 주니어 개발자들이 String을 다룰 때 범하는 가장 흔한 실수는 비교 연산입니다.

  • 상황: if (inputRole == "ADMIN") 이 코드는 가끔 작동하지만, 가끔 실패합니다.
  • 원인: ==는 스택에 저장된 메모리 주소값을 비교합니다. 만약 inputRole이 외부 통신이나 new String()으로 생성되었다면, 내용은 "ADMIN"일지라도 String Pool에 있는 객체와 주소가 달라 false를 뱉습니다.
  • 해결책: 반드시 .equals()를 사용하세요. 이는 객체의 메모리 주소가 아닌 실제 데이터 내용을 하나씩 비교합니다.

5. Trade-offs: 성능과 편의성 사이의 선택

String이 클래스이기 때문에 얻는 이점은 명확하지만, 대가도 따릅니다.

구분 기본 타입 (int, char 등) 참조 타입 (String)
속도 매우 빠름 (CPU 레벨 연산) 상대적으로 느림 (간접 참조 필요)
메모리 고정적, 적음 가변적, 큼 (객체 헤더 정보 포함)
기능 데이터 저장뿐임 다양한 메서드(split, replace 등) 제공

만약 수만 번의 문자열 수정이 일어나는 알고리즘 문제를 풀고 있다면, String 대신 char[] 배열이나 StringBuilder를 사용하는 것이 시간 복잡도 $O(N^2)$을 $O(N)$으로 줄이는 열쇠가 됩니다.

결론: 데이터의 성격이 형식을 결정한다

결국 자바에서 String이 기본 타입이 아닌 이유는 **"데이터의 크기가 가변적이며, 안전하고 효율적인 공유가 필요하기 때문"**으로 요약할 수 있습니다. 자바는 성능(기본 타입)과 확장성(참조 타입)이라는 두 마리 토끼를 잡기 위해 이러한 이중 구조를 설계한 것입니다.

반응형