EnvStudio에서 일본어·한국어 경로를 봤을 때 버그인 줄 알았다
2026-05-15
태그：Windows · EnvStudio · 개발 일지
EnvStudio의 10개 언어 국제화 작업을 마치고 다국어 환경에서 테스트를 시작했습니다. 모든 것이 순조로웠습니다——일본어와 한국어 시스템에서 PATH 환경 변수 값을 볼 때까지.
잠깐, 경로 구분자가 왜 통화 기호가 됐지?
영어 시스템에서 PATH는 이렇게 보입니다:
C:\Users\Name\AppData\Local\Programs일본어 시스템에서는 이렇게 됩니다:
C:¥Users¥Name¥AppData¥Local¥Programs한국어 시스템에서는:
C:₩Users₩Name₩AppData¥Local¥Programs¥（엔）과 ₩（원）？？첫 번째 반응은: 경로를 표시하는 코드에 버그가 있구나였습니다.
꼼꼼히 확인해 봤지만, EnvStudio 자체에는 이런 문자를 수정하는 경로 처리 로직이 없었습니다. PATH 값은 Windows 레지스트리에서 그대로 읽어옵니다. 즉, 시스템이 이 형태로 전달한 것입니다.
버그가 아니라 수십 년 된 Windows의 "역사적 유산"
자료를 찾아보니, 이 동작은 수십 년 전부터 존재했고 Windows 11에서도 계속되고 있었습니다.
0x5C: 하나의 바이트, 세 가지 얼굴
이야기는 문자 인코딩으로 거슬러 올라갑니다. ASCII에서 백슬래시 \의 바이트 값은 0x5C입니다. 하지만 일본어와 한국어 문자 집합에서는 이 바이트가 다른 문자에 할당되어 있었습니다:
| 인코딩 | 언어 | 0x5C 표시 |
|---|---|---|
| CP1252 | 서양 | \ 백슬래시 |
| CP932 | 일본어（Shift-JIS） | ¥ 엔 기호 |
| CP949 | 한국어 | ₩ 원 기호 |
| CP936 | 중국어 간체（GBK） | \ 백슬래시 |
| CP950 | 중국어 번체（Big5） | \ 백슬래시 |
이 매핑은 1970년대 JIS X 0201（일본 공업 규격）까지 거슬러 올라갑니다. 제한된 7비트 인코딩 공간에서 0x5C가 엔 기호에 할당되었습니다. 이후 Shift-JIS가 이를 물려받았고, 한국어 인코딩도 비슷한 길을 걸었습니다.
인코딩 문제인가, 폰트 문제인가?
Unicode에서 백슬래시（U+005C）、엔 기호（U+00A5）、원 기호（U+20A9）는 완전히 독립적인 코드 포인트입니다. Windows가 내부적으로 경로를 처리할 때 0x5C는 항상 백슬래시입니다——경로 구분자로서의 역할은 한 번도 바뀐 적이 없습니다.
그렇다면 왜 ¥과 ₩으로 보일까요?
답은 폰트입니다. 시스템 로캘이 일본어 또는 한국어로 설정되어 있을 때, 시스템 폰트（MS Gothic, Malgun Gothic 등）는 U+005C 위치의 글리프를 백슬래시가 아닌 엔이나 원 기호로 렌더링합니다.
마이크로소프트의 Michael Kaplan은 블로그에서 이렇게 설명했습니다:
"일본과 한국의 코드 페이지 기반 시스템에서 각각의 통화 기호가 경로 구분자로 사용된 지 수십 년이 지났으며, 사용자들은 이미 이 표시에 익숙하다고 여겨집니다."
다시 말해: 바꿀 수 없는 것이 아니라, 의도적으로 바꾸지 않는 것입니다.
2026년에도 여전히 볼 수 있나요?
네. 무엇을 사용하느냐에 따라 다릅니다:
- cmd.exe: 여전히
¥/₩으로 표시 - 레거시 Win32 앱: 여전히
¥/₩으로 표시 - Windows Terminal + 모던 폰트（Cascadia Code 등）:
\로 표시 - WinUI 3 / UWP 앱: 폰트에 따라 다름
그래서 같은 일본어 Windows에서도 한 창에서는 C:\Users, 다른 창에서는 C:¥Users로 보일 수 있습니다——둘은 완전히 같은 경로를 가리킵니다.
EnvStudio로 돌아와서: "수정"해야 할까?
EnvStudio는 WinUI 3로 구축되었고 .NET의 네이티브 Unicode 지원을 사용합니다. 그래서 EnvStudio 자체 인터페이스에서는 일반적인 \가 표시됩니다.
하지만 사용자가 cmd.exe에서 ¥가 포함된 경로를 복사해서 붙여넣으면, EnvStudio는 그대로 받아들입니다——Windows는 내부적으로 이 맥락에서 ¥가 \라는 것을 알고 있으며, 경로 해석이 올바르게 작동합니다.
결국 아무런 특별한 처리도 하지 않기로 했습니다. 이유는 간단합니다: 일본과 한국 사용자들은 아마도 이 표시 방식에 익숙할 것입니다. 제가 임의로 ¥를 \로 바꾸면 오히려 현지 사용자들이 혼란스러워할 수 있습니다——"이 경로는 내 시스템에서 보이는 것과 다른데, 잘못된 건가?"
때로는 "아무것도 하지 않는 것"이 최선의 해결책입니다.
개발자로서 국제화 테스트 중 일본어나 한국어 시스템에서 처음으로 C:¥Users를 보고 놀랐다면, 이 글이 "존재하지 않는 버그를 추적하는 시간"을 절약하는 데 도움이 되기를 바랍니다.