[C#] 문자열 처리 최적화: 가독성과 성능 비교

Unity 실무에서 4가지 문자열 처리 방식을 비교하고, 최종적으로 선택한 방법을 공유

---

 

Unity로 개발하다 보면 UI에 데이터를 표시하는 상황이 정말 많다.
특히 캐릭터, 아이템 등 여러 속성을 화면에 보여줄 때,
어떤 방식으로 문자열을 구성하느냐에 따라 가독성, 유지보수성, 성능이 크게 달라진다.

 

이번 글에서는 실제로 제가 차량 팝업 정보를 구현하면서

• 처음에 사용했던 방식
• 개선 과정에서 시도했던 방법
• 최종적으로 선택한 방식

을 비교하고, 실무에서 어떤 기준으로 선택하면 좋은지 정리해봤다.

 

---

1️⃣기존 방식 – 각 Text 컴포넌트에 직접 할당

처음 구현은 단순하게 각 UI Text(또는 TextMeshProUGUI) 컴포넌트에 값을 직접 넣는 방식이었다.

public void WriteCarPopup()
{
    if (carViewTarget == null) return;

    txtCarMES_PROD_SEQ.text = carViewTarget.PosInfo.MES_PROD_SEQ;
    txtCarBODY_NO.text = carViewTarget.PosInfo.BODY_NO;
    txtCarDP_CMT.text = carViewTarget.PosInfo.DP_CMT;
    txtCarLINE_CD.text = carViewTarget.PosInfo.LINE_CD;
    txtCarPROC_CD.text = carViewTarget.PosInfo.PROC_CD;
    txtCarTAG_ID.text = carViewTarget.PosInfo.TAG_ID;
    txtCarState.text = carViewTarget.carState.ToString();
    txtCarPositionX.text = $"{carViewTarget.transform.position.x:#,##0.0}";
    txtCarPositionY.text = $"{carViewTarget.transform.position.y:#,##0.0}";
    txtCarPositionZ.text = $"{carViewTarget.transform.position.z:#,##0.0}";
}

 

장점	• 기능 추가 필요시 부담없이 적용 가능
단점	• UI 오브젝트가 많아짐 → 관리 복잡 • 각 필드마다 Text 참조 필요 → 유지보수 부담

 

---

 

2️⃣개선 – StringBuilder + AppendFormat

UI 오브젝트 수를 줄이기 위해, 하나의 Text에 모든 정보를 합쳐 출력하도록 변경했다.
이때 문자열 합치기 성능을 위해 StringBuilder를 사용.

sb.AppendFormat(LOG_FORMAT, "차량정보", _car.logInfo);
sb.AppendFormat(LOG_FORMAT, "BODY_NO", _car.BODY_NO);
sb.AppendFormat(LOG_FORMAT, "LINE_CD", _car.LINE_CD);
sb.AppendFormat(LOG_FORMAT, "PROC_CD", _car.PROC_CD);
sb.AppendFormat(LOG_FORMAT, "TAG_ID", _car.PosInfo.TAG_ID);
sb.AppendFormat(LOG_FORMAT, "위치", _car.transform.position);

 

장점	• UI 오브젝트 대폭 감소 • 대량 반복 시 성능 우수
단점	• LOG_FORMAT을 따로 확인해야 해서 직관성 떨어짐

 

---

 

3️⃣중간 단계 – string.Format + 포맷 변수

가독성을 위해 포맷 문자열을 변수로 보관하고, string.Format으로 값 삽입.

private string carFormat =
"----------------------------\n" +
"차량정보 : {0}\n" +
"BODY_NO  : {1}\n" +
"LINE_CD  : {2}\n" +
"PROC_CD  : {3}\n" +
"TAG_ID   : {4}\n" +
"위치     : {5}\n" +
"----------------------------";

string result = string.Format(carFormat,
    _car.logInfo,
    _car.BODY_NO,
    _car.LINE_CD,
    _car.PROC_CD,
    _car.PosInfo.TAG_ID,
    _car.transform.position
);

장점	• 포맷 재사용 가능 • 코드 구조 깔끔
단점	• 포맷과 값이 분리되어 가독성이 떨어짐 • index 헷갈릴 수 있음

 

---

 

4️⃣최종 추천 – 문자열 보간($@"{ }")

가장 직관적이고 가독성 좋은 방식은 문자열 보간 방식.
포맷과 값이 한눈에 보여 유지보수에도 유리.

string result = $@"
----------------------------
차량정보 : {_car.logInfo}
BODY_NO  : {_car.BODY_NO}
LINE_CD  : {_car.LINE_CD}
PROC_CD  : {_car.PROC_CD}
TAG_ID   : {_car.PosInfo.TAG_ID}
위치     : {_car.transform.position}
----------------------------";

 

장점	• 포맷+값 한 곳에서 확인 가능 • 직관적이고 수정이 쉬움
단점	• 포맷 재사용이 어렵고, 대량 반복에서는 StringBuilder보다 미세하게 성능 낮음

 

---

📝정리

기준	Text 직접 할당	StringBuilder + AppendFormat	string.Format + 포맷 변수	$@"{}" (문자열 보간)
가독성	✅ 직관적	❌ 포맷 확인 필요	❌ 포맷·값 분리됨	✅ 매우 좋음
유지보수성	❌ UI 참조 많음	❌ 포맷·값 관리 분리	❌ 인덱스 관리 필요	✅ 변수명 바로 확인 가능
성능	❌ UI 오브젝트 많음	✅ 반복 처리 강점	✅ 동일	✅ UI 수준에서는 동일
재사용성	❌ 낮음	✅ 포맷 재활용 가능	✅ 포맷 재활용 가능	❌ 포맷 재사용 어려움
다국어화	❌ 불편	✅ 포맷 기반 처리 유리	✅ 포맷 기반 처리 유리	❌ 포맷 직접 수정 필요

 

---

3️⃣의 변수 저장 방식과  4️⃣의 성능 차이가 있을까?

$@"{}" 는 컴파일 타임에 string.Format으로 변환된다.

// 이 코드는
string result = $@"차량정보: {_car.BODY_NO}";

// 내부적으로는 이렇게 처리됩니다
string result = string.Format("차량정보: {0}", _car.BODY_NO);

• 런타임 성능 차이는 사실상 없다.
• $@""는 문법적 설탕(syntactic sugar).

문법적 설탕(Syntactic Sugar)은 프로그래밍 언어에서 더 간결하고 직관적으로 코드를 작성할 수 있도록 제공하는 문법적인 편의 기능을 의미한다. 이것은 기능적으로 동일하지만, 더 읽기 쉽고 사용하기 편한 형태로 코드 작성이 가능하도록 돕는다.

 

---

❗ 단, 기획 의도에 따라 방식이 달라져야 한다

1️⃣ 방식(각 Text 직접 할당)도 경우에 따라 필요할 수 있다.
예를 들어, 특정 텍스트를 클릭했을 때 상세 정보가 떠야 하는 등 개별 컴포넌트 단위의 기능이 필요하다면,
하나의 Text로 모든 정보를 합치는 방식은 구현이 어렵다.

 

위에서 비교한 방식들은

• 현재 UI 요소들이 아무런 추가 기능이 없는 상황에서
• 앞으로도 기능이 추가될 가능성이 거의 없다고 판단했기 때문에

유지보수성과 최적화를 우선 고려하여 진행한 사례다.

 

 

---

 

📌 결론

• UI 오브젝트가 많지 않고 문자열 크기가 크지 않다면 문자열 보간($@"") 방식을 추천
• 여러 UI 텍스트 → 하나의 Text 컴포넌트로 합치면 오브젝트 수 감소 + 유지보수 편의성↑
• 대량 데이터 처리나 반복 연산에서는 여전히 StringBuilder 효율성이 유리할 수 있음
• 단, 특정 기능 필요시 각 컴포넌트 직접 할당해서 기능 구현 필요