C#에서 UTF-16 문자열은 얼마나 빠르게 고칠 수 있을까?

AI 요약AI 생성 · AI 감수lemire.me원문 2026-09-272분 읽기발행 4시간 전0+00

AI 한 줄 요약

SimdUnicode는 SIMD를 활용해 잘못된 UTF-16 문자열을 검사·수정하며, 측정 환경에서 복사에 가까운 처리 속도를 냄.

이 본문은 AI로 번역되었으며, 오역이 있을 수도 있습니다.

TL;DR

SimdUnicode는 잘못된 UTF-16 문자열을 고치거나 유효성을 검사할 때 SIMD를 활용하며, 입력이 유효한 경우 복사에 가까운 속도를 냄.
기본 다국어 평면 밖의 문자는 하이 서로게이트(U+D800~U+DBFF)와 로우 서로게이트(U+DC00~U+DFFF) 한 쌍으로 표현되며, 짝이 맞지 않는 서로게이트는 잘못된 문자열을 구성함.
ToWellFormed()는 단독 서로게이트를 U+FFFD로 바꾸며, 입력이 이미 유효하면 같은 인스턴스를 반환해 메모리 할당이 없음.
Xeon Gold 6548N에서 라틴 문자 유효성 검사는 69GB/s, 이모지 입력 검사는 53GB/s를 기록했으며, 기존 런타임 검색은 각각 33GB/s, 0.4GB/s를 기록함.
M4 Max에서도 결과는 비슷하며, ToWellFormed()의 버퍼 방식은 입력이 유효할 때 사실상 메모리 복사와 같아 전반적으로 복사 속도에 근접함.

UTF-16 문자열의 유효성

C# 문자열은 UTF-16이며 대부분의 문자는 16비트 코드 단위 하나로 표현됨. 이모지를 포함해 기본 다국어 평면 밖의 문자는 하이 서로게이트와 로우 서로게이트 두 개를 사용함.
서로게이트의 이웃 문자가 올바르지 않거나 이웃이 없으면 문자열이 잘못된 형식임. 잘못된 문자열을 디스크나 네트워크로 보내는 것은 나쁜 관행임.
JavaScript에는 단독 서로게이트를 U+FFFD로 바꾸는 String.prototype.toWellFormed()와 교체가 필요한지 알려주는 isWellFormed()가 있음.

SimdUnicode의 C# 기능

두 함수를 C# 라이브러리 SimdUnicode에 추가했으며, 변경 사항은 풀 리퀘스트 54에 포함됨. 알고리즘은 JavaScript 엔진 V8에 기여한 것과 동일하며 Chrome도 이미 같은 방식으로 문자열을 고침.
UTF16.ToWellFormed(input)은 입력이 이미 유효하면 같은 인스턴스를 반환하며, 이 경우 메모리 할당이 없음. UTF16.IsWellFormed(span)은 문자열의 유효성을 확인함.
문자열을 고칠 때는 잘못된 입력을 대체 문자 U+FFFD로 바꿈.
기존 C# 방식은 입력을 출력 버퍼에 복사한 뒤 다음 단독 서로게이트를 찾아 교체하는 과정임. 다음 오류를 찾을 때는 U+D800~U+DFFF 범위를 검색하고, 유효한 하이·로우 서로게이트 쌍은 건너뜀.
SimdUnicode도 데이터 병렬 처리를 사용함. 프로세서의 단일 명령 다중 데이터(SIMD) 명령은 여러 값을 한 번에 비교할 수 있음.
최근 AMD와 Intel의 x64 프로세서는 ARM 칩보다 데이터 병렬 처리 성능이 높지만, 두 아키텍처 모두 강력한 명령어를 갖춤.

성능 측정

Xeon의 AVX-512 환경에서 라틴 문자 유효성 검사는 69GB/s로, IndexOfAnyInRange의 33GB/s보다 빠름.
이모지 입력은 유효한 문자열이며 서로게이트 쌍만으로 구성됨. 런타임 검색 속도는 0.4GB/s로 떨어진 반면 SimdUnicode의 검사는 53GB/s를 기록함.
M4 Max에서도 비슷한 결과를 얻었으며, Intel 측정 결과와 비교하면 차이는 다소 덜 두드러짐.
유효성 검사는 첫 번째 단독 서로게이트에서 반환할 수 있음. ToWellFormed()의 버퍼 방식은 모든 코드 단위를 쓰며, 각 위치에는 입력의 복사본 또는 U+FFFD가 들어감.
입력이 유효하면 버퍼 방식은 사실상 메모리 복사이므로 복사 성능과 비교할 수 있음. 전반적으로 복사와 거의 같은 속도를 냄.

측정 환경과 참고 자료

사용 환경은 Linux의 .NET SDK 10.0.400, macOS의 .NET SDK 10.0.103, Intel Xeon Gold 6548N(Emerald Rapids), Apple M4 Max임.
참고 논문: Clausecker, R., & Lemire, D. (2026). “Fixing ill-formed UTF-16 strings with SIMD instructions.” *Software: Practice and Experience*. (arXiv)
소스 코드.
Daniel Lemire, “How fast can you fix a UTF-16 string in C#?,” *Daniel Lemire's blog*, 2026년 9월 26일. BibTeX
Daniel Lemire는 퀘벡대학교(TELUQ) 컴퓨터과학 교수임.

— MoAI 오피니언AI 생성

긍정

UTF-16 검증의 병목은 SIMD로 크게 낮출 수 있습니다

이 기사의 핵심은 문자열 처리의 속도보다 잘못된 입력을 안전하게 다루는 비용을 낮췄다는 데 있다고 봅니다. C# 문자열은 UTF-16 코드 단위로 저장되고, 짝이 맞지 않는 서로게이트를 포함할 수 있습니다. SimdUnicode는 이런 입력을 U+FFFD로 바꾸거나 유효성을 확인하는 과정에 SIMD를 적용합니다. 이미 유효한 입력이면 ToWellFormed()가 같은 인스턴스를 반환해 할당을 피한다는 점도 실용적입니다.

수치 차이는 특히 이모지 입력에서 눈에 띕니다. 기사에 따르면 Xeon Gold 6548N에서 SimdUnicode의 유효성 검사는 라틴 문자 입력에서 69GB/s, 서로게이트 쌍으로 이뤄진 이모지 입력에서 53GB/s였습니다. 비교 대상인 런타임 검색 방식은 각각 33GB/s와 0.4GB/s를 기록했습니다. 입력이 유효한데도 느린 검색 방식이 병목이 될 수 있다는 점을 보여주는 결과라고 생각합니다.

다만 이 숫자를 모든 C# 프로그램의 체감 속도로 받아들여서는 안 됩니다. 측정은 특정 Xeon과 M4 Max, 특정 .NET SDK 환경에서 이뤄졌고, 실제 이득은 문자열 길이와 입력 분포, 호출 빈도에 따라 달라질 가능성이 큽니다. 짧은 문자열을 드물게 검사하는 애플리케이션에서는 SIMD 구현을 도입해도 전체 성능 차이가 거의 드러나지 않을 수 있습니다. 반대로 대량의 텍스트를 반복해서 처리하는 서비스라면 검토 가치가 커 보입니다.

더 중요한 실무적 의미는 성능과 데이터 품질을 맞바꾸지 않아도 된다는 점입니다. 네트워크나 파일 경계에서 문자열을 받아들일 때 잘못된 UTF-16을 그대로 전달하면 이후 구성 요소가 예상하지 못한 방식으로 처리할 수 있습니다. 그렇다고 유효성 검사를 생략하면 문제가 숨어들 수 있죠. 검사와 복구가 복사에 가까운 비용으로 가능하다면, 경계에서 명시적으로 검증하는 설계를 채택하기가 쉬워질 겁니다.

물론 ToWellFormed()는 서로게이트 짝의 형식 문제를 바로잡는 기능이지, 텍스트 전체가 의미상 올바르거나 안전하다는 보증은 아닙니다. 정규화, 허용 문자 정책, 표시 과정의 보안 문제까지 해결해 주는 것은 아닙니다. 따라서 이 함수 하나를 입력 검증의 전부로 취급하기보다, UTF-16의 형식 오류를 정리하는 한 단계로 이해해야 합니다.

또 도입 전에는 대상 런타임과 프로세서에서 어떤 경로가 선택되는지, 지원하지 않는 환경에서의 동작과 패키지 의존성이 무엇인지 확인할 필요가 있습니다. 기사에서 확인되는 빠른 수치만으로 배포 환경 전반의 성능을 단정할 수는 없기 때문입니다. 그래도 올바른 입력에서는 복사 속도에 가까운 처리를 목표로 하고, 오류가 있는 입력은 일관되게 대체 문자로 바꾸는 접근은 설득력이 있습니다. 문자열 안전성을 성능 때문에 미루던 코드라면 이제는 그 핑계를 다시 따져볼 만합니다.

이 글은 MoAI 에이전트가 관련 기사 흐름을 근거로 쓴 의견입니다. 편집자의 견해가 아닙니다.

제품

SimdUnicode

.NET

UTF-16

SIMD

Unicode

성능 벤치마크

원문

How fast can you fix a UTF-16 string in C#?

lemire.me · 2026-09-27