TXT 파일이란? 일반 텍스트, 인코딩, UTF-8

TXT는 컴퓨터에서 가장 단순한 문서 형식입니다. 굵게도, 글꼴도, 페이지 레이아웃도 없이 문자와 줄 바꿈만 있습니다. 이 단순함 덕분에 이식성이 매우 뛰어납니다. 50년 전에 쓴 텍스트 파일을 오늘 열 수 있고, 오늘 쓴 파일도 수십 년 뒤에 열릴 가능성이 높습니다. 하지만 "일반 텍스트"는 보기만큼 간단하지 않습니다. 악센트가 붙은 글자가 "é"나 "?"로 바뀌고, 여러 줄이 한 줄로 합쳐지고, 파일 맨 앞에 보이지 않는 문자가 생기는 현상은 모두 TXT 파일 속에 숨은 한 가지 요소, 즉 문자 인코딩에서 비롯됩니다. 이 글에서는 TXT 파일이 어떻게 작동하는지, 이런 문제를 어떻게 해결하는지 설명합니다.

TXT 파일이란 무엇인가요?

.txt 확장자를 가진 파일에는 텍스트 문자 외에는 아무것도 없습니다. 헤더도, 메타데이터도, 서식도 없으며 모든 바이트가 텍스트 자체에 속합니다. 핵심 질문은 이것입니다. 어떤 바이트가 어떤 문자를 뜻할까요? 이 대응 관계를 문자 인코딩이라고 부르는데, TXT 파일은 대개 자신이 어떤 인코딩을 쓰는지 밝히지 않습니다. 파일을 여는 프로그램이 추측해야 합니다.

간략한 역사: ASCII에서 UTF-8까지

ASCII는 1963년 ASA X3.4-1963으로 처음 발표되었습니다. 7비트를 사용해 영문 알파벳, 숫자, 문장 부호, 줄 바꿈 같은 제어 문자 등 128개 문자를 정의합니다. é, ñ, ö 같은 글자나 한글은 ASCII에 포함되지 않습니다.

이 빈틈을 메우기 위해 8비트 바이트의 나머지 128개 값을 언어별로 배정하는 코드 페이지가 등장했습니다. 서유럽 언어용 Windows-1252와 ISO-8859-1, 터키어용 Windows-1254와 ISO-8859-9 등 그 밖에도 많습니다. 문제는 같은 바이트가 코드 페이지마다 다른 글자를 뜻한다는 점입니다. 예를 들어 바이트 FD는 Windows-1252에서는 "ý"이지만 Windows-1254에서는 "ı"입니다. 코드 페이지를 잘못 추측한 프로그램은 텍스트를 엉뚱하게 표시합니다.

근본적인 해결책은 모든 문자 체계의 모든 문자에 고유 번호를 부여하는 유니코드였습니다. UTF-8은 그 번호를 바이트로 바꾸는 가장 널리 쓰이는 방법입니다. 롭 파이크(Rob Pike)에 따르면 켄 톰슨(Ken Thompson)이 1992년 9월 무렵 어느 밤 뉴저지의 한 식당에서 테이블 매트 위에 UTF-8을 설계했습니다. 현재 정의는 2003년 11월의 RFC 3629입니다. UTF-8은 U+0000부터 U+10FFFF까지의 모든 문자를 1~4바이트로 인코딩하며, ASCII 문자는 ASCII와 똑같은 1바이트로 씁니다.

UTF-8이 얼마나 지배적인지는 웹에서 드러납니다. 2026년 10월 15일 기준 W3Techs 데이터에 따르면 문자 인코딩이 확인된 웹사이트의 99.1%가 UTF-8을 사용하며, 그 뒤를 ISO-8859-1(0.8%)과 Windows-1252(0.2%)가 잇습니다.

TXT 파일 안에는 무엇이 있나요?

문자와 바이트

"café"라는 단어를 UTF-8과 Windows-1252로 각각 저장하면 서로 다른 바이트가 만들어집니다.

텍스트:         c   a   f   é
UTF-8:          63  61  66  C3 A9   (5바이트)
Windows-1252:   63  61  66  E9      (4바이트)

UTF-8 파일을 Windows-1252로 읽는 프로그램은 C3과 A9을 별개의 두 문자 "é"로 표시합니다. 반대로 Windows-1252 파일을 UTF-8로 읽는 프로그램은 E9을 잘못된 바이트로 보고 대신 "�"를 표시합니다. 글자 깨짐 문제는 거의 모두 이 두 가지 경우 중 하나입니다.

BOM(바이트 순서 표시)

일부 프로그램은 UTF-8 파일 맨 앞에 EF BB BF 바이트를 넣습니다. 이는 U+FEFF 문자의 UTF-8 형태로, "이 파일은 UTF-8"이라는 서명으로 쓰입니다. RFC 3629는 이 서명이 항상 이 세 바이트로 나타난다고 설명합니다. 유니코드 FAQ에 따르면 UTF-8에서 BOM은 필수가 아니며 서명 역할만 하고, 파일 시작 부분에 ASCII 문자를 기대하는 프로토콜에서는 피해야 합니다. 실제로 BOM은 일부 구형 Windows 프로그램과 Excel이 UTF-8을 인식하는 데 도움이 되지만, Unix 셸 스크립트나 특정 소프트웨어가 읽는 설정 파일을 망가뜨릴 수 있습니다.

UTF-16에서는 BOM이 더 중요합니다. 바이트 순서를 알려 주기 때문입니다. FF FE는 리틀 엔디언, FE FF는 빅 엔디언 UTF-16을 뜻합니다.

줄 끝 문자

줄의 끝을 나타내는 문자도 운영 체제마다 다릅니다.

오랫동안 Windows 메모장은 CRLF만 인식했기 때문에 Linux에서 작성한 파일이 긴 한 줄로 보였습니다. Microsoft는 2018년 5월 8일 메모장의 LF와 CR 지원을 발표했고, 이 변경은 Windows 10 버전 1809와 함께 사용자에게 제공되었습니다.

TXT는 어디에 쓰이나요?

• 메모와 초안: 서식이 필요 없는 간단한 메모.
• 소프트웨어: README 파일, 라이선스 문구, 소스 코드, 설정 파일, 로그.
• 데이터 교환: 시스템 사이에서 주고받는 단순 목록과 내보내기 파일.
• 장기 보관: 특정 프로그램에 의존하지 않고 보관해야 하는 텍스트.
• 접근성과 처리: 화면 낭독기, 검색 엔진, 텍스트 분석 도구에 가장 깔끔한 입력.

장점과 단점

장점: 모든 기기와 운영 체제에서 열립니다. 파일이 아주 작습니다. 프로그램 버전에 의존하지 않고 손상 위험도 매우 낮습니다. Git 같은 버전 관리 시스템이 변경 내용을 줄 단위로 보여 줄 수 있습니다. 매크로나 내장 개체를 담을 수 없어 안전합니다.

단점: 서식, 이미지, 표, 링크를 담을 수 없습니다. 인코딩이 파일에 기록되지 않아 잘못 추측될 수 있습니다. 줄 끝 문자의 차이가 시스템 간에 사소하지만 성가신 문제를 일으킵니다. 제목이나 목록 같은 구조가 필요하다면 Markdown이 더 낫습니다.

TXT는 어떤 프로그램으로 여나요?

Windows의 메모장, macOS의 텍스트 편집기, Linux의 gedit 같은 편집기 모두 TXT를 열며, 브라우저도 텍스트 파일을 바로 표시할 수 있습니다. Visual Studio Code, Notepad++, Sublime Text 같은 고급 편집기는 상태 표시줄에 인코딩과 줄 끝 문자 유형을 보여 주고 클릭 한 번으로 둘 다 바꿀 수 있어, 인코딩 문제를 진단하는 데 가장 실용적인 도구입니다.

자주 겪는 문제와 해결 방법

악센트 문자가 "é"나 "ü"처럼 보입니다

파일은 UTF-8로 저장되었는데 읽는 프로그램이 Windows-1252로 가정한 경우입니다. 인코딩을 선택할 수 있는 편집기에서 UTF-8로 다시 여세요. CSV나 텍스트 파일이 Excel에서 이렇게 보인다면 BOM이 있는 UTF-8로 저장하면 대개 해결됩니다.

문자가 "?"나 "�"로 바뀌어 있습니다

파일은 구형 코드 페이지로 저장되었는데 UTF-8로 읽히는 경우입니다. 편집기에서 올바른 코드 페이지를 선택해 연 뒤 UTF-8로 저장하세요. 텍스트가 실제 "?" 문자로 저장되었다면 원래 문자는 사라진 것이므로 원본으로 돌아가야 합니다.

모든 텍스트가 한 줄로 보입니다

오래된 편집기가 LF 줄 끝 문자를 인식하지 못하는 경우입니다. 최신 메모장이나 고급 편집기를 쓰거나 줄 끝 문자를 CRLF로 변환하세요.

파일 맨 앞에 보이지 않는 문자가 있습니다

대개 BOM입니다. 스크립트나 설정 파일이 첫 줄에서 오류를 낸다면 "BOM 없는 UTF-8"로 저장하세요.

TXT 파일 변환 팁

저희 변환기에서 TXT 파일은 서버에 업로드되고 30분 이내에 삭제됩니다. 인코딩은 자동으로 감지됩니다. 먼저 BOM을 확인하고(UTF-8, UTF-16 리틀 엔디언과 빅 엔디언), BOM이 없으면 유효한 UTF-8인지 검사하며, 유효한 UTF-8이 아니면 구형 터키어 Windows 코드 페이지인 Windows-1254로 읽습니다. NUL 바이트가 많은 파일은 텍스트가 아닌 바이너리로 간주되어 "텍스트 파일이 아닙니다"라는 메시지가 표시됩니다.

• TXT를 Word로, TXT를 PDF로 변환하면 각 줄이 하나의 문단이 되고 빈 줄도 유지됩니다. 줄 앞의 들여쓰기(코드, 시, 번호가 붙은 조항)는 사라지지 않도록 줄 바꿈 없는 공백으로 바뀌고, 줄 앞의 탭은 공백 네 칸이 됩니다.
• 나중에 일반 텍스트에 제목과 목록을 더하고 싶다면 TXT를 Markdown으로 변환하는 것이 좋은 출발점입니다.
• 반대 방향으로 PDF를 TXT로, Word를 TXT로 변환하면 서식이 빠지고 제목과 문단이 빈 줄로 구분됩니다. 저희가 만드는 TXT 파일은 메모장이나 Excel 같은 프로그램에서 특수 문자가 올바르게 보이도록 BOM이 있는 UTF-8로 저장됩니다.

자주 묻는 질문

TXT 파일은 어떤 인코딩으로 저장해야 하나요?

새 파일이라면 UTF-8입니다. 모든 언어를 지원하고 웹에서는 사실상 보편적인 형식이 되었습니다. BOM 없는 UTF-8을 기대하는 소프트웨어가 읽을 파일이라면 BOM을 빼고, Excel 같은 프로그램에서 열 파일이라면 넣으세요.

UTF-8과 BOM이 있는 UTF-8은 무엇이 다른가요?

내용은 똑같고, BOM 버전은 단지 EF BB BF 바이트로 시작할 뿐입니다. 이 서명은 일부 프로그램이 인코딩을 감지하는 데 도움이 되지만, 다른 프로그램에서는 보이지 않는 첫 문자로 나타날 수 있습니다.

TXT와 RTF는 무엇이 다른가요?

TXT에는 문자만 있습니다. RTF는 텍스트에 넣은 제어 명령으로 굵게, 기울임, 글꼴, 표 같은 서식을 담습니다. 서식이 필요 없다면 TXT가 더 단순하고 이식성이 좋습니다.

TXT 파일의 인코딩은 어떻게 알 수 있나요?

Visual Studio Code나 Notepad++ 같은 편집기는 상태 표시줄에 인코딩을 표시합니다. 현재 버전의 메모장도 상태 표시줄에 인코딩과 줄 끝 문자 유형을 보여 줍니다.

TXT 파일에 바이러스가 들어 있을 수 있나요?

일반 텍스트 파일 자체에는 실행 코드가 없습니다. 다만 "document.txt.exe" 같은 이중 확장자는 조심하세요. Windows에서 파일 확장자를 표시하도록 설정하면 이런 수법을 알아차리기 쉽습니다.

출처

• IETF RFC 3629: UTF-8, a transformation format of ISO 10646 (2003년 11월)
• 유니코드 컨소시엄: UTF-8, UTF-16, UTF-32 및 BOM FAQ
• Rob Pike: UTF-8 history
• W3Techs: Usage statistics of character encodings for websites
• Microsoft: Introducing extended line endings support in Notepad (2018년 5월 8일)
• Wikipedia: ASCII (2차 자료)