역사 수업: .txt 파일이란? 오래된 텍스트 파일이 이상한 문자로 보이는 이유

.txt 파일이란?

어떤 편집기로 .txt 파일을 열어도 보이는 것은 문자뿐입니다. 글자, 숫자, 문장 부호, 공백, 줄바꿈. 이것이 형식의 전부입니다. 헤더도, 글꼴도, 굵게나 기울임도, 페이지 크기도, 글의 언어에 대한 기록도 없습니다. 파일이 실제로 담고 있는 것은 0에서 255 사이의 숫자인 바이트의 나열이고, 파일을 여는 프로그램이 각 숫자가 어떤 문자인지 정해야 합니다. 확장자 '.txt'는 Windows에 어떤 프로그램을 제안할지만 알려 줄 뿐, 바이트를 어떻게 읽어야 하는지는 말해 주지 않습니다. 그래서 일반 텍스트는 지금까지 만들어진 형식 중 가장 이식성이 좋은 형식 중 하나이면서, 가장 잘못 읽기 쉬운 형식 중 하나이기도 합니다.

.txt 파일에 이상한 문자가 보이는 이유는?

파일을 읽는 프로그램이 파일을 쓴 프로그램과 다른 문자 인코딩을 쓰고 있기 때문입니다. 같은 글자도 서로 다른 바이트로 저장될 수 있습니다. é는 Microsoft가 영어 등 서유럽 언어에서 일반적으로 쓰이는 코드 페이지라고 설명하는 Windows-1252에서는 1바이트 E9이지만, UTF-8에서는 2바이트 C3 A9입니다. UTF-8 파일을 Windows-1252로 열면 모든 é가 é가 됩니다. 둥근 아포스트로피 ’(UTF-8에서 E2 80 99)는 ’가 됩니다. 바이트 순서 표시(BOM, 아래에서 설명)로 시작하는 UTF-8 파일은 맨 앞에 가 나타납니다. 반대로 Windows-1252 파일을 UTF-8로 열면, 홀로 있는 바이트 E9는 올바른 UTF-8이 아니므로 프로그램이 대체 문자 �를 표시합니다.

DOS 시대의 파일은 다른 방식으로 틀어집니다. 최초의 IBM PC에서는 같은 바이트가 또 다른 문자일 수 있었습니다. DOS 문자 집합인 코드 페이지 437에서 바이트 82는 é이고, 5바이트 C9 CD CD CD BB는 상자의 윗변(╔═══╗)을 그립니다. Windows는 이를 코드 페이지 1252로 읽어 ‚와 ÉÍÍÍ»로 표시하므로, café라는 단어는 caf‚가 되고 README의 테두리 배너는 글자 나열로 바뀝니다.

어떤 프로그램도 혼자서 항상 맞힐 수는 없습니다. 2007년 Microsoft의 Raymond Chen은 D0 AE라는 2바이트 파일로 메모장의 딜레마를 보여 주었습니다. Windows-1252로 읽으면 Ю, UTF-8로 읽으면 키릴 문자 Ю, UTF-16(문자당 2바이트)으로 읽으면 바이트 순서마다 다른 한국어 한글 음절 하나입니다. 그는 네 가지 읽기가 모두 그럴듯하다고 지적했습니다. 파일 안에 표시가 없다면 '이상하다'는 것은 틀린 짐작이 어떻게 보이는지를 말할 뿐입니다.

1963년: ASCII가 128개 문자에 번호를 붙이다

일반 텍스트가 파일이 되려면 서로 다른 기계가 합의하는 문자 번호가 필요했습니다. American Standards Association은 1960년 8월에 부호화 문자 집합 소위원회를 만들었고, 1963년 6월 17일에 표준 X3.4-1963, 곧 American Standard Code for Information Interchange인 ASCII를 승인했습니다. 제어 문자, 숫자, 문장 부호, 영어 알파벳을 위한 128개의 값을 가진 7비트 코드였습니다. 1963년판은 알면서도 불완전했고, 표의 상당 부분이 아직 배정되지 않았습니다. 1967년 7월 7일에 승인된 개정판 X3.4-1967에 대한 1967년의 공지는 ASCII 프로젝트 참여자 대부분이 이를 기본 7비트 코드의 첫 진정한 완성으로 본다고 밝혔습니다.

7비트는 1바이트에 깔끔하게 들어맞지 않습니다. 이 문제를 어떻게 할지 말한 가장 이른 문서 중 하나가 1969년 10월에 Vint Cerf가 초기 ARPANET(인터넷에 앞선 연구 네트워크)을 위해 쓴 RFC 20입니다. 이 문서는 '최상위 비트가 항상 0인 8비트 바이트에 넣은 표준 7비트 ASCII'를 제안했습니다. 이 쓰이지 않는 여덟 번째 비트에서 훗날 문제가 시작됩니다. 한 바이트가 256개의 값을 담을 수 있게 되면 나머지 128개는 누구든 마음대로 배정할 수 있기 때문입니다.

CR, LF, 아니면 둘 다: 줄은 어떻게 끝나는가

ASCII는 텔레타이프라이터의 기계적 동작도 부호화했습니다. Chen의 설명에 따르면 캐리지 리턴(CR)은 종이를 보내지 않고 인쇄 헤드를 0번 열로 되돌렸고, 라인 피드(LF)는 헤드를 움직이지 않고 종이를 한 줄 보냈기 때문에, 새 줄을 시작하려면 둘이 모두 필요했습니다. RFC 20에 수록된 1968년판 ASCII는 LF에 '새 줄'의 의미를 허용하면서도, 그렇게 쓰려면 '데이터의 송신자와 수신자 사이의 합의가 필요하다'고 덧붙입니다. 그 합의는 끝내 완전히 이루어지지 않았습니다. RFC 20 자체가 초기 ARPANET 사이트들의 의견이 갈렸다고 기록합니다. SRI는 줄 끝 문자로 마침표를 썼고, UCLA는 캐리지 리턴을 썼습니다.

CP/M, MS-DOS, Windows는 두 문자를 모두 유지해 CRLF(바이트 0D 0A)로 삼았습니다. Unix는 LF(0A) 하나로 충분하다고 보았습니다. Microsoft의 2018년 메모장 동작 변경 발표는 이제 처리하는 세 가지 관례를 열거합니다. Unix/Linux 줄 끝(LF), Macintosh 줄 끝(CR), Windows 줄 끝(CRLF)입니다. 그때까지 메모장은 Windows 줄 끝만 제대로 표시할 수 있어서, Unix나 Linux에서 만든 텍스트 파일은 뒤엉켜 보였다고 발표는 설명합니다. 이 수정은 2018년 5월 Windows 10 Insider 빌드에 반영되었습니다.

1981년: 나머지 128개 값이 제각각 흩어지다

IBM PC는 1981년에 8비트 바이트와 7비트 표준을 가지고 등장했습니다. 엔지니어 중 한 명인 David Bradley는 나중에 PC가 'ASCII 문자 집합을 사용했는데, IBM 제품으로서는 급진적인 변화였다'고 회고했고(IBM의 이전 제품은 EBCDIC을 썼습니다), 채워야 할 새 칸이 128개였기 때문에 팀이 외국어 글자, 블록 그래픽, 수학 기호와 그리스 문자로 채웠다고 말했습니다. 그는 이 문자 집합이 '세 사람이 네 시간 동안 연 회의'에서 개발되었다고 말하기를 좋아한다고 했습니다. 그 결과가 코드 페이지 437이며, Microsoft는 이를 영어용 일반 OEM(DOS) 코드 페이지라고 부릅니다. 위쪽 절반에는 악센트 문자, 선 그리기 문자, 기호가 들어 있습니다.

이후 Windows는 자체 코드 페이지를 만들었습니다. Microsoft 문서에 따르면 Windows 코드 페이지 1252는 원래 훗날 ISO 8859-1이 된 American National Standards Institute(ANSI)의 초안에 기반했지만, 표준이 확정되기 전에 구현되어 완전히 같지는 않습니다. Windows 코드 페이지는 지금도 흔히 'ANSI 코드 페이지'라고 불리지만 실제로는 Microsoft 고유의 것입니다. 모두 0~127 값에서는 ASCII와 일치하고 그 위에서는 어긋납니다. 바이트 E9는 코드 페이지 1252에서는 é, 키릴 문자 1251에서는 й, 그리스 문자 1253에서는 ι입니다. 일본어와 중국어는 더블바이트 코드 페이지를 썼고, 일부 바이트는 뒤따르는 바이트와 함께일 때만 의미를 가집니다. Microsoft는 유니코드가 다루는 범위를 하나의 코드 페이지가 모두 포괄하지는 못한다고 밝힙니다.

1992년: 유니코드, 그리고 뉴저지 다이너의 종이 식탁 매트

유니코드는 정반대의 접근을 택했습니다. 모든 문자에 번호 하나씩을 주어 더 이상 코드 페이지를 갈아 끼우지 않게 하는 것입니다. 첫 버전(1991~1995년)은 16비트 인코딩이었고, 1996년 7월의 유니코드 2.0부터는 U+0000에서 U+10FFFF까지의 범위를 다룹니다. 하지만 번호가 곧 파일은 아닙니다. 16비트 값을 파일에 그대로 저장하면 널 바이트와 슬래시 같은 ASCII 바이트에 의존하던 당시의 Unix 소프트웨어와 충돌했고, 1992년에는 X/Open 위원회가 Unix에 알맞은 유니코드 저장 방식을 검토하고 있었습니다.

당시 Bell Labs에 있던 Rob Pike는 2003년에 UTF-8이 '1992년 9월쯤의 어느 밤 뉴저지의 다이너에서 종이 식탁 매트 위에, 내 눈앞에서 설계되었다'고 썼습니다. 위원회 위원들이 그와 Ken Thompson에게 제안을 검토해 달라고 요청한 터였습니다. 두 사람은 저녁을 먹으러 갔고, Thompson이 비트를 채우는 방식을 궁리했으며, 그 뒤 위원회에 전화를 걸었습니다. Pike는 Thompson이 그날 밤 패킹과 언패킹 코드를 작성했고, 금요일까지 그들의 운영체제 Plan 9이 훗날 UTF-8이라 불릴 것만으로 돌아가고 있었다고 말합니다. 동료 Russ Cox가 찾아낸 메일 기록은 이 제안을 1992년 9월 초로 못 박습니다.

UTF-8은 한 문자를 1~4바이트로 저장합니다. 128개의 ASCII 문자는 1바이트 값을 그대로 유지하고, 다른 문자의 어떤 바이트도 ASCII처럼 보이지 않으므로 순수한 ASCII 파일은 이미 올바른 UTF-8입니다. 그 밖의 문자는 2~4바이트를 쓰며, 앞쪽 비트가 읽는 쪽에 시퀀스의 길이를 알려 줍니다. é는 C3 A9가 됩니다. François Yergeau의 RFC 3629(2003년 11월)가 이를 인터넷 표준으로 만들었고, 유니코드 FAQ는 이를 '유니코드 텍스트 파일에 선호되는 형식'이라고 부릅니다.

BOM, 그리고 메모장이 짐작해야 했던 이유

UTF-16은 문자를 16비트 단위로 저장하므로 읽는 쪽은 바이트 순서도 알아야 합니다. 유니코드의 답은 서명으로 파일 맨 앞에 두는 문자 U+FEFF, 곧 바이트 순서 표시입니다. UTF-8에서는 바이트 EF BB BF로 나타나는데, 유니코드 FAQ는 거기서는 바이트 순서와 무관하며 파일이 UTF-8임을 표시할 뿐이라고 분명히 말합니다. FAQ는 또한 BOM을 예상하지 않는 프로그램이 있다는 점(#!로 시작하는 Unix 셸 스크립트의 첫 줄이 한 예)과, '.txt 파일에 대한 Microsoft의 관례' 같은 프로토콜이 BOM을 요구할 수 있다는 점을 덧붙입니다. 그래서 .txt 파일은 BOM으로 시작할 수도, 아닐 수도 있으며, 없을 때는 프로그램이 짐작해야 합니다.

Chen의 2007년 글 '메모장 파일 인코딩 문제'는 짐작이 왜 결코 좋게 끝나지 않는지 설명합니다. BOM이 있는 파일은 쉽습니다. BOM이 없으면 세상의 텍스트 파일 대부분은 8비트 ANSI였고, 일부 UTF-8과 UTF-16 파일도 BOM이 없었으며, 그가 시도한 모든 규칙은 한 집단에 유리하면 다른 집단을 망가뜨렸습니다. 그의 예는 이렇습니다. 명령 cmd /u /c dir >results.txt는 BOM이 없는 UTF-16 파일을 씁니다.

Microsoft는 메모장을 두 단계로 바꿨습니다. 2018년에 Unix와 Mac 줄 끝을 처리하게 되었습니다. 이어 2018년 12월 10일 Windows 10 Insider 빌드 18298에서 BOM 없는 UTF-8로 저장하는 옵션을 추가하고, 새 파일의 기본값으로 삼고, 인코딩을 상태 표시줄에 표시했습니다. BOM 없는 UTF-8은 ASCII와 하위 호환되며 'UTF-8이 기본 인코딩이 된' 웹에서 더 잘 작동한다는 이유였습니다. 이 변경은 2019년 5월 업데이트인 Windows 10 버전 1903으로 모든 사용자에게 전달되었습니다. 그 전에는 메모장 새 파일의 기본값이 ANSI였습니다.

2007년 이후: UTF-8이 웹을 장악하다

Google은 2007년 12월에 유니코드가 자사가 색인한 웹 페이지에서 처음으로 가장 흔한 인코딩이 되었으며, 열흘 사이에 ASCII와 서유럽 인코딩을 모두 앞질렀다고 보고했습니다. W3Techs는 현재 인코딩을 식별할 수 있는 웹사이트의 99.1%에서 UTF-8이 쓰인다고 보고합니다(2026년 11월). 하지만 이는 웹사이트에 대한 통계입니다. 오래된 디스크 속 텍스트 파일은 이 변화에 포함된 적이 없고, 누구도 거슬러 올라가 다시 인코딩하지 않았습니다.

오래된 디스크의 .txt 파일이 2026년에도 깨져 보이는 이유

오늘날의 소프트웨어는 UTF-8을 전제로 하지만, 많은 텍스트가 그 이전에 쓰였습니다. DOS README, 초기 Windows 메모, 더는 실행되지 않는 프로그램에서 내보낸 파일, 텍스트로 저장한 메일이나 로그 같은 것들입니다. 이들은 만든 PC의 코드 페이지로 저장되어 있고, 그것은 PC의 언어와 Windows 버전에 따라 달랐으며, 아무 표시도 없습니다. 다른 시스템의 줄 끝과 가끔 있는 BOM 없는 UTF-16 파일까지 더해지면, 같은 확장자 .txt 아래에 서로 무관한 여러 형식이 숨어 있게 됩니다. 그중 상당수는 원래 프로그램에 물어볼 방법이 없는 레거시 파일입니다.

Legacy File Converter는 지원 파일 형식 페이지의 문서 항목에 일반 텍스트(.txt)를 올려 두었으며, 사용 중인 Windows PC에서 DOCX, PDF, Markdown, HTML 같은 최신 형식으로 변환합니다. 아무것도 업로드되지 않습니다. 변환한 뒤에는 악센트 문자, 따옴표, 기호를 원본과 비교하고 원본 파일은 보관하세요. 속은 대부분 텍스트인 다른 형식이 궁금하다면, BOM이 없으면 Excel이 헤매는 역사 수업: .csv 파일이란?과 역사 수업: .rtf 파일이란?을 보세요.