유니코드 변환 규칙, 사실상 프로그래밍 언어였다?

본문은 UTS #35 변환 규칙이 재귀적 치환(Revisiting Cursor) 기능을 통해 2-태그 시스템(2-Tag System)을 시뮬레이션할 수 있음을 보여준다. 이는 콜라츠 추측(Collatz Conjecture)과 같은 보편적인 계산을 수행할 수 있음을 의미하며, 결과적으로 변환 규칙 파일 자체가 실행 가능한 프로그램(Executable Program)으로 간주될 수 있다고 설명한다. 특히, ICU 라이브러리에 포함된 규칙 데이터가 이러한 보편성을 지닌다는 점이 주목할 만하다.

커뮤니티에서는 APFS 파일 시스템의 유니코드 정규화 비민감성(Normalization Insensitivity)과 같은 사례를 언급하며, 의도치 않게 튜링 완전성(Turing Completeness)을 갖게 되는 경우의 위험성을 지적한다. 데이터 격리 아키텍처(Data Isolation Architecture)가 부재한 환경에서 외부에서 제공된 변환 규칙을 그대로 수용할 경우, 잠재적인 무한 루프(Infinite Loop)나 예측 불가능한 동작을 유발할 수 있다는 우려가 제기된다. 따라서 런타임 시 실행 제한(Runtime Limits)을 두는 것이 필수적이라는 의견이 나온다.

일부 개발자들은 파일 시스템과 같은 저수준(Low-level)에서 유니코드 알고리즘을 처리하는 방식에 의문을 제기한다. 사용자 정의 가능한 변환 규칙이 무한 루프를 유발할 수 있다면, 이를 방지하기 위한 명시적인 제한 장치(Explicit Safeguards)가 필요하다는 것이다. 또한, 유니코드 정규화(Unicode Normalization)와 같은 작업은 커널 레벨이 아닌 사용자 공간(Userland)에서 처리하는 것이 더 유연하고 안전할 수 있다는 의견도 제시된다.

본문은 ICU 라이브러리가 각 코드 포인트당 최대 16회의 재작성 제한(Loop Limit)을 두는 재작성 가드(Rewrite Guard)를 통해 무한 계산을 방지한다고 언급한다. 이는 결정 불가능성(Undecidability)이라는 이론적 문제를 해결하기 위한 실용적인 접근 방식이다. 커뮤니티에서는 이러한 런타임 제한(Runtime Limitation)이 변환 규칙을 안전하게 사용하는 데 필수적임을 강조하며, 이는 단순한 데이터가 아닌 코드(Code)로 간주해야 함을 시사한다.