Backend/Java

String, StringBuilder, StringBuffer: 어떤 상황에 어떤 '무기'를 꺼내야 할까?

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

 

현대 애플리케이션에서 문자열 데이터는 혈액과 같습니다. 사용자 이름부터 대규모 로그 데이터까지, 우리는 끊임없이 문자열을 생성하고 수정하죠. 하지만 Java에서 문자열을 다루는 방식에 따라 시스템의 메모리가 효율적으로 관리될 수도, 혹은 "Stop-the-world(GC)"의 늪에 빠질 수도 있습니다. 오늘은 성능 최적화의 첫걸음인 문자열 클래스 3인방의 내부 구조와 적재적소의 활용법을 깊이 있게 파헤쳐 보겠습니다.

1. 핵심 개념: 불변(Immutable) vs 가변(Mutable)

가장 먼저 이해해야 할 핵심은 **"메모리 위에서 데이터가 어떻게 변하는가"**입니다.

String: 변하지 않는 성벽

String 객체는 한 번 생성되면 그 값이 절대 변하지 않는 불변(Immutable) 객체입니다.

  • 작동 원리: 우리가 str1 + str2를 수행할 때, 기존의 str1이 변경되는 것이 아닙니다. 힙(Heap) 메모리의 String Constant Pool이라는 영역에 완전히 새로운 String 객체가 생성되고, 변수는 새 객체를 참조하게 됩니다.
  • 비유: 마치 일기장에 볼펜으로 글을 쓰는 것과 같습니다. 내용을 수정하려면 기존 페이지를 고치는 게 아니라, 새 페이지를 뜯어서 처음부터 다시 써야 하는 셈이죠.

StringBuilder & StringBuffer: 자유로운 화이트보드

반면, 이 두 클래스는 가변(Mutable) 객체입니다.

  • 작동 원리: 내부적으로 가변적인 배열(Buffer)을 가지고 있어, 새로운 문자열을 추가하더라도 새 객체를 만들지 않고 기존 배열의 크기를 조정하며 데이터를 변경합니다.
  • 비유: 언제든 쓰고 지울 수 있는 화이트보드와 같습니다. 공간이 부족하면 옆에 보드를 덧붙여서 계속 쓸 수 있죠.

2. Deep Dive: 내부 작동 원리와 메모리 구조

단순히 "가변적이다"라는 설명만으로는 부족합니다. 실제 JVM 내부에서 어떤 일이 일어나는지 살펴봅시다.

String의 결합 연산이 잦아지면 메모리에는 사용되지 않는 쓰레기 객체(Garbage)들이 쌓입니다. 반면 StringBuilder와 StringBuffer는 AbstractStringBuilder라는 추상 클래스를 상속받아 구현됩니다. 이들은 문자열을 byte[] (Java 9 이상 기준) 배열에 저장하며, 용량이 부족할 때만 배열을 복사하여 확장하는 전략을 취합니다.

3. 실전 Hands-on: 대규모 데이터 가공 시나리오

단순한 예제 대신, 실제 커머스 시스템에서 여러 개의 상품 정보를 조합해 하나의 긴 알림 메시지를 생성하는 비즈니스 로직을 가정해 보겠습니다.

가쁜 숨을 몰아쉬는 String 연산 (Bad Case)

Java
 
// 수천 명의 사용자에게 보낼 메시지를 생성한다고 가정
String finalMessage = "";
for (Product item : productList) {
    // 매 루프마다 새로운 String 객체가 생성되어 메모리에 쌓임
    finalMessage += "상품명: " + item.getName() + ", 가격: " + item.getPrice() + "\n";
}

효율적인 StringBuilder 활용 (Best Practice)

Java
 
// 초기 용량(Capacity)을 예상하여 할당하면 배열 복사 비용까지 줄일 수 있음
StringBuilder sb = new StringBuilder(1024); 

for (Product item : productList) {
    sb.append("상품명: ")
      .append(item.getName())
      .append(", 가격: ")
      .append(item.getPrice())
      .append("\n");
}

String finalMessage = sb.toString();

트러블슈팅: StringBuilder가 만능일까?

만약 멀티 스레드 환경에서 여러 스레드가 동시에 sb.append()를 호출한다면 데이터가 꼬이는 현상이 발생합니다. 이때가 바로 **StringBuffer**가 등장할 타이밍입니다. StringBuffer는 각 메서드에 synchronized 키워드가 붙어 있어 Thread-safe를 보장합니다.

4. 성능 분석과 선택 기준 (Trade-offs)

세 클래스의 성능 차이를 수식적으로 비교하면 다음과 같은 관계를 가집니다.

$$Speed: StringBuilder > StringBuffer \gg String$$
특성 String StringBuilder StringBuffer
가변성 불변 (Immutable) 가변 (Mutable) 가변 (Mutable)
스레드 안전 안전 (공유 가능) 불안전 안전 (Synchronized)
주요 사용처 짧은 문자열, 키값, 설정 정보 단일 스레드 내 대량 연산 멀티 스레드 공유 자원

고려해야 할 한계점

  1. String의 반격: Java 8 이후부터는 단순한 String a + b 연산을 컴파일러가 내부적으로 StringBuilder로 변환해 줍니다. 따라서 짧은 문장 한두 개를 합치는 용도라면 가독성을 위해 그냥 + 연산자를 쓰는 것이 낫습니다.
  2. 과도한 최적화의 함정: 무조건 StringBuilder를 쓰기 위해 코드를 복잡하게 만드는 것은 유지보수 측면에서 마이너스입니다. 루프(반복문) 안에서 문자열을 합치는 경우가 아니라면 String의 불변성이 주는 안정성을 누리세요.

5. 결론: 당신의 선택은?

정리하자면, 도구의 선택 기준은 명확합니다.

  • 변하지 않는 값이나 가독성이 중요하다면? String
  • 단일 스레드 환경에서 빈번한 수정이 일어난다면? StringBuilder
  • 멀티 스레드 환경에서 안전하게 공유되어야 한다면? StringBuffer

최근의 고성능 서버 애플리케이션에서는 동기화 오버헤드 때문에 StringBuffer보다는 지역 변수로 StringBuilder를 활용하는 패턴을 더 선호하는 추세입니다.

여러분이 지금 작성하고 있는 코드의 루프 안에는 혹시 수천 개의 무의미한 String 객체가 생성되고 있지는 않나요? 설계 단계에서 이 작은 차이를 인지하는 것이 바로 시니어 개발자로 가는 첫걸음입니다.

다음 프로젝트에서 문자열 연산이 포함된 로직을 작성할 때, 어떤 클래스를 선택하시겠습니까? 그 이유를 메모리 구조 관점에서 한 번 더 고민해 보시길 바랍니다.

반응형