Python UTF-8 in Windows

Windows 는 메이저 OS 3종(Windows, Linux, MacOS) 중 가장 빠르게 Unicode 지원을 시작했다. 무려 우리가 현재 사용하는 유니코드의 베이스인 Unicode 2.0 출시보다도 3년이 빠른 1993년에 Windows NT 3.1 과 함께 출시되었다. 물론 Unicode 1.0 과 2.0 사이에 호환성이 없기 때문에 한번 갈아엎어야 했지만…

참고로 MacOS 는 1998년 MacOS 8.5 부터, Linux 는 현실적으론 2002 년 Redhat Linux 8 출시와 함께 제공되기 시작했다.

문제는 MS 는 당시부터 글로벌하게 OS를 팔고있었기 때문에 영어에는 불리하고, 다른 언어에는 유리한 UTF-16 을 사용하지만, Linux 와 MacOS 는 영어에만 유리한 UTF-8을 사용한다는 것과, MS의 병적인 하위호환 지원(Windows 3.1 시절에 내장되어있던 32bit 프리셸이 아직도 돌아간다…) 이 겹치면서 2026년 시점에 이상한 문제를 만들었다. 그건 바로 Full Unicode 기반 OS 임에도, 아직도 비 유니코드 콘솔 프로그램을 돌리기 위해 Terminal 의 기본 인코딩이 멀티바이트라는(한국어 기준 CP949) 것이다…

참고로 Linux 와 MacOS는 그냥 기존에 작성된 모든 SW의 호환성을 포기하는것으로 해결보았고, 애초에 멀티바이트 시절이 존재하지 않는 Windows CE 는 애초에 멀티바이트 관련 API 자체가 없고 유니코드 전용이다. 이걸 UTF-8로 바꾸는 옵션이 존재 하긴 하는데… Windows 11 25H2 기준 아직 Beta 인 데다가, 이거 바꾸면 반대로 UTF-8을 고려하지 않은 콘솔 프로그램이 모두 박살난다.

사실 이걸 처음부터 제대로 고려하고 만든 SW 는 문제가 전혀 없다. 요즘 내가 쓰는 Cloude Code 도, Codex CLI도 AntiGravity CLI 도, 오픈소스인 OpenCode 도 전혀 문제가 없다. 그런데 문제는 이런 코딩 에이전트들이 문제을 해결하기 위해 Python 을 호출 하는 경우가 있는데 이 Python 의 출력에 한국어가 있을경우 몽땅 깨져버려서 코딩 에이전트에서 인식을 못하게 된다는 것이다. 물론 AI 가 알아서 고치는 경우도 많지만 시간도 오래걸리고 토큰도 낭비되니 좋은 방법은 아니다

다행히도 Python 은 환경변수로라도 인코딩을 바꿀 수 있게 되었는데 그 변수가 PYTHONUTF8 이다. 변수명 중간에 Hyphen 이 없다는 것에 주의해라.
아래와 같이 넣어서 제어할 수 있는데

cmd 일 경우

set PYTHONUTF8=1

powershell 일 경우

$env:PYTHONUTF8="1"

와 같이 세팅하여 사용할 수 있다.

만약 매번 세팅하기 귀찮다면 OS 에 환경변수를 등록하면 되는데 시작메뉴에서 env 를 검색하면 메뉴가 뜰거고

Apply 버튼 위의 환경 변수를 클릭하면 설정화면으로 들어갈 수 있다

여기에 PYTHONUTF8 변수를 추가하고 값을 1로 주면 된다