Windows의 문자 코드와 개행 코드를 정리한다 - Shift_JIS / UTF-8 / UTF-16, 문자 깨짐, CRLF / LF, 왜 혼란스러운가

Windows의 텍스트 주변의 상담에서는 꽤 자주 다음 이야기가 한꺼번에 섞입니다.

• Shift_JIS와 UTF-8은 무엇이 다른가
• 왜 문자 깨짐이 일어나는가
• CRLF와 LF는 무엇이 다른가
• UTF-8로 했는데 왜 읽을 수 없는 경우가 있는가
• 왜 같은 file인데 editor, console, Excel, Git에서 보이는 방식이 바뀌는가

이 이야기는 일본어나 한국어가 어렵기 때문에 일어나는 것이 아닙니다. 대부분은 같은 바이트 열을 다른 전제로 읽었거나, 잘못 읽은 내용을 그대로 저장했기 때문입니다.

게다가 Windows에서는 Unicode의 세계와 code page의 세계가 지금도 공존하고 있습니다. 거기에 BOM, 개행 코드, editor의 자동 판정, console의 code page, Git의 개행 변환까지 겹치므로 이야기가 복잡해 보입니다.

이 글에서는 Windows에서 자주 섞이는 Shift_JIS / UTF-8 / UTF-16, 왜 문자 깨짐이 일어나는지, CRLF와 LF의 차이, 그리고 왜 이 이야기가 혼란스럽기 쉬운지를 실무용으로 정리합니다.

내용은 2026년 4월 시점의 Microsoft Learn, PowerShell, Git, W3C / Unicode 계열의 공개 정보를 전제로 하고 있습니다. 자세한 것은 말미의 참고 자료를 참조해 주세요.

1. 먼저 짚어야 할 것

먼저 결론만 나열하면 중요한 것은 다음 7가지입니다.

• text file은 문자열 그 자체가 아니라 bytes + 문자 코드 + 개행 코드로 이루어져 있습니다. 경우에 따라서는 BOM도 붙습니다.
• 문자 깨짐은 같은 bytes를 다른 문자 코드로서 decode했을 때 일어납니다.
• 개행 문제는 문자 코드가 올바르더라도 행 구분의 전제가 어긋나 있을 때 일어납니다.
• Unicode와 UTF-8은 같은 의미가 아닙니다. Unicode는 문자 집합 측의 이야기이고, UTF-8이나 UTF-16은 encoding의 이야기입니다.
• Windows에서 「Shift_JIS」라고 불리는 것은, 실무에서는 CP932 / Windows 계열의 일본어 code page로 의식하는 편이 대화가 흔들리기 어렵습니다.
• UTF-8로 했다만으로는 아직 사양으로서 부족합니다. BOM의 유무와 개행 코드까지 결정해야 비로소 운용 규칙이 됩니다.
• 혼란의 근원은 일본어 자체가 아니라, 역사가 다른 복수의 전제가 같은 Windows 위에 남아 있는 것입니다.

요컨대 Windows의 text를 다룰 때는 다음 4가지를 나누어 생각하는 것이 출발점입니다.

1. 그 file의 bytes는 무엇인가
2. 어느 encoding으로 쓰였는가
3. 어느 encoding으로 읽혔는가
4. 개행은 CRLF / LF 중 어느 것인가

여기가 나뉘는 것만으로도 꽤 망설이기 어려워집니다.

2. 용어를 분해한다

2.1 Unicode / UTF-8 / UTF-16 / CP932는 무엇이 다른가

먼저 용어를 한 번 분해하는 편이 빠릅니다.

예를 들어 あ라는 1 문자라도, bytes는 encoding마다 다릅니다.

문자: あ

UTF-8    : E3 81 82
CP932    : 82 A0
UTF-16LE : 42 30

중요한 것은 문자와 bytes는 별물이라는 것입니다. 앱은 화면상에서는 「문자」로 보이는 것을 다루고 있지만, 저장이나 통신에서는 최종적으로 bytes를 주고받습니다. 사고는 대개 그 변환의 경계에서 일어납니다.

2.2 Shift_JIS와 CP932를 어떻게 생각할까

현장에서는 일본어 Windows의 text file을 묶어서 「Shift_JIS」라고 부르는 경우가 꽤 많습니다. 대화로서는 통하지만 실무에서는 약간 거칩니다.

Windows의 일본어 legacy text를 정확하게 의식한다면, CP932 또는 Windows 계열의 일본어 code page로 생각하는 편이 안전합니다.

여기를 거칠게 하면 다음과 같은 대화가 흔들립니다.

• Shift_JIS로 저장해라고 말했지만, 상대는 Windows 측의 CP932를 상정하고 있었다
• Linux / macOS 측에서는 shift_jis로서 다뤘지만, Windows 유래 file의 일부에서 재현이 맞지 않는다
• ANSI 저장이라고 들었지만, 어느 code page인지는 환경 의존이었다

그래서 사양이나 조사 메모에서는 가능한 한 다음과 같이 쓰는 편이 안전합니다.

• Shift_JIS가 아니라 CP932
• ANSI가 아니라 ACP (active code page) / 일본어 환경에서는 통상 CP932
• text가 아니라 UTF-8 no BOM, LF처럼 구체화한다

2.3 ANSI, Unicode, UTF-8N이라는 용어의 함정

Windows 주변에서는 용어 라벨도 혼란의 원인입니다.

특히 많은 것은 다음입니다.

• ANSI Windows의 UI나 오래된 설명에서 나오지만, ASCII가 아닙니다. 많은 경우는 그 머신의 active code page를 가리킵니다.
• Unicode 일부의 editor나 도구에서는 menu 상의 Unicode가 UTF-16LE를 의미하는 경우가 있습니다. Unicode로 저장했다라고 들어도 UTF-8이라고는 한정되지 않습니다.
• UTF-8N 일본어권의 editor에서 볼 수 있지만, 이것은 보통 UTF-8 no BOM을 구별하기 위한 UI 라벨입니다. encoding의 정식 명칭이 아닙니다.

즉, 같은 말이라도 도구마다 의미가 어긋나는 것이 Windows입니다. 여기가 최초의 큰 혼란 포인트입니다.

3. 왜 문자 깨짐이 일어나는가

3.1 문자 깨짐의 정체

문자 깨짐의 정체는 꽤 단순합니다.

1. 문자열을 어느 encoding으로 bytes로 한다
2. 그 bytes를 다른 encoding으로 문자열로 되돌린다
3. 전제가 일치하지 않으면 별개의 문자열이 된다

예를 들어 あ를 UTF-8로 저장하면 bytes는 다음입니다.

E3 81 82

이것을 UTF-8로서 읽으면 あ이지만, CP932 측의 전제로 읽으면 縺�과 같은 별개의 문자열로 보입니다. 이때 망가져 있는 것은 「일본어」가 아니라 decode의 전제입니다.

문자 깨짐을 1행으로 말하면 이렇습니다.

같은 bytes를 다른 encoding으로서 읽었다.

3.2 표시 붕괴와 데이터 파손은 별개

여기서 중요한 것은 아직 되돌릴 수 있는 단계와 이미 되돌리기 어려운 단계를 나누는 것입니다.

예를 들어 다음 흐름이라면 아직 되돌릴 수 있는 가능성이 있습니다.

1. UTF-8의 file을 CP932로서 연다
2. 화면상에서는 縺�와 같이 보인다
3. 아직 저장하지 않았다

이 단계에서는 원래의 bytes는 UTF-8 그대로 남아 있습니다. 올바른 encoding으로 다시 열면 돌아오는 경우가 있습니다.

위험한 것은 다음입니다.

1. UTF-8의 file을 CP932로서 오독한다
2. 망가져 보이는 내용을 그대로 저장한다
3. 원래의 UTF-8 bytes가 사라진다

여기까지 가면 표시 붕괴가 아니라 데이터 파손입니다.

실무에서는 「문자가 깨졌다」라는 1문으로 정리하지 말고, 적어도 다음을 나누는 것이 중요합니다.

• bytes 자체는 아직 올바른가
• 오독한 내용이 이미 재저장되었는가

3.3 표현할 수 없는 문자로 떨어뜨리면 돌아오지 않는다

또 하나 위험한 것은 Unicode 문자열을 CP932와 같은 좁은 code page로 떨어뜨릴 때입니다.

이때 상대 측에 존재하지 않는 문자가 포함되어 있으면 다음 중 어느 것이 일어납니다.

• ?로 치환된다
• 치환 문자가 들어간다
• 변환 에러가 된다
• 별개의 가까운 문자로 기울여진다

예를 들어 일부의 이모지나 확장 한자는 CP932로 그대로 떨어뜨릴 수 없습니다. 이 사고는 「읽을 수 있는가」가 아니라 왕복 변환해서 원래대로 돌아가는가로 생각해야 합니다.

한번 잃어버린 정보는 나중에 올바른 encoding을 알아도 원래대로 돌아가지 않습니다.

4. 개행 문자의 차이란

4.1 CRLF / LF / CR

개행도 bytes입니다.

• CR = carriage return = 0D
• LF = line feed = 0A
• Windows의 text file에서는 CRLF (0D 0A)가 전통적
• Linux / Unix 계에서는 LF (0A)가 일반적
• CR 단독은 구 Mac 계 등의 오래된 문맥에서 나오는 경우가 있다

표로 하면 이렇습니다.

4.2 개행은 문자 코드와는 별개 문제

여기가 꽤 중요합니다.

개행 코드는 encoding과는 별개 문제입니다.

같은 UTF-8의 file이라도 개행은 CRLF로도 LF로도 됩니다. 예를 들어 A, 개행, B라는 내용이라면 bytes는 다음과 같이 바뀝니다.

UTF-8 + LF   : 41 0A 42
UTF-8 + CRLF : 41 0D 0A 42

즉,

• UTF-8인데 개행만 다르다
• CP932인데 개행은 LF
• UTF-16LE인데 개행은 CRLF

는 평범하게 있을 수 있습니다.

그래서 UTF-8로 했는데 아직 다르다라고 할 때, 실제로는 encoding이 아니라 개행만 어긋나 있는 경우가 있습니다.

4.3 \n과 file 상의 개행 bytes는 같지 않다

프로그래머 시점에서 수수하게 혼란스럽기 쉬운 것이 여기입니다.

source code 속에서 \n이라고 썼다고 해서, file 상에 반드시 0A만이 나온다고는 한정되지 않습니다. 언어나 런타임, I/O API의 text mode에서는 Windows 상에서 \n이 CRLF로 변환되는 경우가 있습니다.

즉, 다음이 어긋날 가능성이 있습니다.

• 소스 코드 상의 개행 표현
• 실행 시의 문자열
• file에 저장된 bytes
• editor 상에서 보이는 개행

이 때문에 「자신은 LF를 썼을 터인데 file은 CRLF였다」는 사고가 일어납니다.

최근의 editor는 LF 단독을 평범하게 다룰 수 있지만, 주변 도구, legacy 앱, 업무 운용은 아직 CRLF 전제가 남아 있습니다. 그래서 개행 문제는 「옛날 이야기」가 아니라 지금도 실무에서 평범하게 나옵니다.

5. 왜 Windows에서는 특히 혼란스럽기 쉬운가

5.1 Unicode와 legacy code page가 공존하고 있다

Windows가 까다로운 최대의 이유는 이것입니다.

Windows에는,

• Unicode를 사용하는 길
• code page 베이스로 다루는 길

의 양쪽이 남아 있습니다.

새롭다 할 수 있는 앱, web, cross-platform 계 자산은 UTF-8로 기울기 쉬운 한편, 오래된 CSV, TXT, 로그, Excel 주변, 업무 시스템 연계에서는 CP932가 남아 있습니다. 게다가 일부의 출력이나 API 주변에서는 UTF-16LE도 평범하게 나옵니다.

즉, 1대의 Windows 속에 복수의 text 문화가 동거하고 있는 것입니다.

5.2 라벨이 맞춰져 있지 않다

혼란을 증가시키는 것은 기술 그 자체보다 라벨의 어긋남입니다.

• Shift_JIS라고 말하고 있지만 실태는 CP932
• ANSI라고 말하고 있지만 실태는 active code page
• Unicode라고 말하고 있지만 실태는 UTF-16LE
• UTF-8이라고 말하고 있지만 실제로는 BOM 있음 / 없음이 미확정
• UTF-8N과 같은 editor 독자 라벨이 나온다

여기를 애매하게 하면 대화에서는 통하는 것처럼 보여도 실체가 맞춰져 있지 않습니다.

5.3 ASCII만이라면 문제가 숨는다

이것도 큽니다.

UTF-8은 ASCII 범위와 호환성이 있으므로, 영숫자와 기호만의 file은 잘못된 전제여도 「어쩐지 읽혀 버리는」 경우가 있습니다. CP932 측에서도 ASCII 상당의 범위는 외관이 망가지기 어려우므로 문제가 표면화되지 않습니다.

그 결과 다음과 같은 상태가 됩니다.

• 영어만의 config는 문제없이 보인다
• 일본어를 1행 넣은 순간에 망가진다
• 계속 숨어 있던 문제가 운용 중에 처음으로 발화한다

그래서 문자 코드 사고는 「어제까지 동작하고 있었는데 오늘부터 갑자기 망가졌다」처럼 보이기 쉽습니다. 실제로는 이전부터 지뢰가 있고, 비 ASCII 문자가 들어간 순간에 보였을 뿐이라는 것이 많습니다.

5.4 file 내용, file 이름, console, source file은 별도 레이어

Windows에서는 다음을 묶어 「문자 코드」라고 부르면 미로에 빠집니다.

• file 이름 / path
• file의 내용
• console로의 표시
• source code file 자체의 encoding
• 실행 시의 문자열 형식
• clipboard나 GUI 부품상의 표시

예를 들어 일본어의 file 이름이 평범하게 보이고 있어도 file의 내용은 CP932로 저장되어 있을지도 모릅니다. 반대로 file 자체는 UTF-8이라도 console의 code page가 맞지 않으면 표시만 망가집니다.

chcp 65001과 같은 조작도 기본적으로는 console 측의 전제에 효과적인 이야기이며, 기존 file의 bytes를 바꾸는 이야기가 아닙니다.

게다가 source code file이 UTF-8이라도 실행 시에 써내는 log file이 UTF-8이라고는 한정되지 않습니다. 어느 층의 encoding 이야기를 하고 있는가를 매번 나눌 필요가 있습니다.

덧붙여 일본어 Windows에서는 \이 엔 기호로 보이는 경우가 있어 이것도 문자 코드의 이야기와 섞이기 쉽습니다. 다만 많은 경우 이것은 표시 폰트나 glyph의 문제이며 path 구분이나 escape의 의미가 바뀐 것은 아닙니다.

5.5 BOM과 개행 코드도 별도 축으로 효과적

UTF-8이라는 말하기 방식만으로는 아직 절반밖에 결정되어 있지 않습니다.

실무에서는 다음도 효과적입니다.

• BOM은 있는가, 없는가
• 개행은 CRLF인가 LF인가

예를 들어 같은 UTF-8이라도,

• BOM 있음이라면 읽을 수 있는 Windows 도구가 있다
• BOM이 있으면 선두 열에 불필요한 문자가 타는 Unix 계 처리가 있다
• LF만이라면 legacy 측에서 다루기 어려운 도구가 있다
• CRLF라면 shell script나 diff가 거칠어지는 경우가 있다

라는 식으로, encoding이 맞아 있어도 아직 사고난다는 것입니다.

5.6 도구가 마음대로 바꾼다

더욱 까다로운 것이 수중의 도구가 암묵으로 바꾸는 것입니다.

• editor가 auto-detect한다
• save 시에 BOM을 붙인다 / 뗀다
• Git이 CRLF / LF를 변환한다
• shell이나 command가 기본의 encoding으로 저장한다
• CSV export가 상정 외의 code page를 사용한다
• 다른 version의 PowerShell이나 tool에서 기본값이 다르다

즉, 작업자가 명시하지 않아도 어딘가의 층이 마음대로 전제를 추가해 오는 것이 Windows 실무입니다.

이것이 「자신은 아무것도 바꾸지 않았는데 망가졌다」의 정체입니다. 실제로는 사람이 아니라 도구의 기본값이 바꾸고 있는 경우가 적지 않습니다.

6. 자주 있는 사고 패턴

전형 사고를 표로 하면 다음과 같이 됩니다.

특히 위험한 것은 표시 붕괴를 본 후에 그대로 저장해 사고를 확정시키는 패턴입니다.

7. 실무에서 사고를 줄이는 규칙

여기서부터는 운용 규칙으로서 무엇을 정하면 사고가 줄어드는지입니다.

7.1 신규 text의 기본선을 정한다

신규 file에서는 먼저 UTF-8을 제1후보로 하는 것이 타당합니다. 다만 그것만으로는 부족합니다.

최저한 다음까지 결정하는 편이 안전합니다.

• UTF-8 with BOM인가 UTF-8 no BOM인가
• 개행은 CRLF인가 LF인가
• 누가 읽는 file인가
• legacy Windows 도구 호환이 필요한가
• Linux / macOS / CI / container도 읽는가

예를 들어 cross-platform 전제의 source code나 config라면 UTF-8 no BOM + LF가 제1후보가 되기 쉽습니다. 한편, Windows의 오래된 도구나 기존 운용에 맞출 필요가 있다면 UTF-8 with BOM이나 CP932 + CRLF가 아직 필요한 경우도 있습니다.

중요한 것은 「무엇이 올바른가」의 일반론보다 누구와 주고받을 것인가로 정하는 것입니다.

7.2 기존 legacy file은 마음대로 바꾸지 않는다

기존의 file이 CP932라면, 일상의 작은 수정의 김에 UTF-8화하지 않는 편이 안전합니다.

안전한 것은 다음 운용입니다.

• 기존 file은 원래의 encoding / BOM / 개행을 유지한다
• encoding 변환은 별도의 이행 태스크로 나눈다
• 변환 대상과 하류 consumer를 확인하고 나서 일괄 변환한다

문자 깨짐 사고는 선의의 「김에 modern화」로 일어나는 경우가 꽤 많습니다.

7.3 encoding과 개행을 interface의 일부로서 다룬다

CSV, TXT, log, 설정 file, 간이 protocol은 내용뿐만 아니라 text 형식 자체가 interface입니다.

사양에는 최저한 다음을 쓰는 편이 안전합니다.

• encoding
• BOM의 유무
• newline style
• header의 유무
• quote / delimiter의 사양
• 어느 도구로 검증했는가

예를 들어 CSV라는 3문자만으로는 불충분합니다. UTF-8 with BOM, CRLF, comma delimiter, header 있음까지 써야 비로소 대화가 어긋나기 어려워집니다.

7.4 읽기 쓰기의 경계에서는 명시한다

코드 측에서도 암묵의 기본값에 기울이지 않는 편이 안전합니다.

• file read / write 시는 encoding을 명시한다
• process 간의 text 건네기에서도 encoding을 의식한다
• export / import 처리에서는 개행도 사양으로서 고정한다
• shell의 거친 redirect를 본번 경로로 하지 않는다

특히 Windows에서는 「저장할 수 있었다」는 것과 「올바른 bytes로 저장할 수 있었다」는 것은 같지 않습니다.

7.5 Git과 editor의 규칙도 공유한다

Git은 encoding을 자동으로 바로잡아주는 도구가 아닙니다. 한편, line endings에 대해서는 변환이 들어가는 경우가 있습니다.

그래서 repository 단위로 다음을 정하는 편이 안전합니다.

• source code는 LF를 기본으로 할 것인가
• Windows 전용 text는 CRLF를 허용할 것인가
• .gitattributes로 어떻게 고정할 것인가
• editor 설정을 어떻게 공유할 것인가

encoding과 line endings를 따로따로 생각하는 것이 중요합니다. Git이 개행을 맞춰줘도 encoding 사고는 그대로 남습니다.

7.6 「문자가 깨졌다」에서 멈추지 말고 무엇이 어긋났는지 말한다

현장에서는 다음의 언어 바꾸기가 꽤 효과적입니다.

• 나쁜 말하기: 문자가 깨졌습니다
• 좋은 말하기: UTF-8 no BOM의 file을 CP932 전제로 열고 있는 것으로 보입니다
• 나쁜 말하기: 행말이 이상합니다
• 좋은 말하기: LF의 file이 CRLF로 변환되어 차분이 늘어나고 있습니다

무엇이 어긋났는지 말할 수 있는 것만으로도 조사 속도는 꽤 바뀝니다.

8. 문자 깨짐・행말 차분의 조사는 이 5문으로 진행한다

조사에서 망설이면 다음 5문으로 돌아가는 것이 가장 빠릅니다.

1. 지금 이 file의 bytes는 무엇인가
   • UTF-8인가
   • UTF-8 with BOM인가
   • CP932인가
   • UTF-16LE인가
2. 최초로 누가 어느 전제로 썼는가
   • editor
   • legacy app
   • Excel export
   • shell / script
   • batch / middleware
3. 지금 누가 어느 전제로 읽고 있는가
   • editor의 auto-detect
   • console의 code page
   • library의 default encoding
   • import 측의 사양
4. BOM과 개행은 무엇인가
   • BOM 있음 / 없음
   • CRLF / LF
5. 오독한 내용이 이미 저장되었는가
   • 아직 표시만인가
   • 이미 재저장되어 bytes가 사라졌는가

이 5문이 메워지면 대개 원인은 보입니다.

9. 정리

Windows의 문자 코드와 개행 코드가 까다롭게 보이는 것은 일본어 그 자체가 어렵기 때문이 아닙니다. bytes, encoding, BOM, newline, tool의 기본값이 따로따로 존재하고, 그 위에서 Windows에는 신구의 text 문화가 동거하고 있기 때문입니다.

특히 외워 두고 싶은 것은 다음입니다.

• 문자 깨짐은 같은 bytes를 다른 encoding으로서 읽은 결과
• 개행 문제는 encoding과는 별도 축의 이야기
• Shift_JIS, CP932, ANSI, Unicode라는 말은 그대로 너무 신용하지 않는다
• UTF-8로 했다만으로는 불충분하며, BOM과 개행도 필요
• 표시 붕괴와 재저장 완료의 데이터 파손은 나누어 생각한다
• 사양에서는 text가 아니라 UTF-8 no BOM, LF처럼 쓴다

요컨대 Windows의 text를 다룰 때는 「문자열의 이야기」가 아니라 bytes의 약속을 어떻게 맞출지의 이야기라고 생각하는 것이 실무적입니다.

10. 관련 기사

• Windows의 문자 코드를 정리한다 - 왜 문자 깨짐이 일어나는가, 특히 Linux와 조합했을 때 무엇이 어긋나는가
• Windows 환경에서 Codex의 문자 깨짐 사고를 줄이는 베스트 프랙티스 - 환경 정비보다 『이렇게 지시한다』를 먼저 정한다

11. 참고 자료

1. Microsoft Learn, Code Page Identifiers - Win32 apps https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
2. Microsoft Learn, about_Character_Encoding - PowerShell https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_character_encoding?view=powershell-7.6
3. Microsoft Learn, Understanding file encoding in VS Code and PowerShell https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/vscode/understanding-file-encoding?view=powershell-7.6
4. W3C Internationalization, Character encodings: Essential concepts https://www.w3.org/International/articles/definitions-characters/
5. Git documentation, gitattributes https://git-scm.com/docs/gitattributes
6. Git documentation, git-config https://git-scm.com/docs/git-config

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.