대용량 TXT 파일 번역 방법: 인코딩, 챕터, 줄바꿈

대용량 TXT 파일을 번역하려면 업로드하기 전에 세 가지를 준비해야 합니다. 첫째, 텍스트가 올바르게 디코딩되었는지 확인하고 UTF-8로 저장하세요. 둘째, 모든 챕터 제목을 각각 한 줄에 두고 앞뒤에 빈 줄을 넣으세요. 셋째, 파일이 고정 폭으로 줄바꿈되어 있다면 각 문단이 한 줄이 되도록 줄을 합치고 문단 사이에 빈 줄을 넣으세요. 그런 다음 파일 전체를 번역하고, 원문과 번역문의 문단 수와 챕터 수를 비교하세요.

일반 텍스트 파일에는 스타일도, 제목도, 메타데이터도 없습니다. 번역 도구가 파일 구조에 대해 아는 모든 정보는 바이트와 줄바꿈에서 나옵니다. 그래서 같은 세 가지 문제가 계속 반복됩니다. 바이트를 잘못된 인코딩으로 읽거나, 챕터를 일반 줄과 구분할 수 없거나, 줄바꿈이 문장이 끝나는 위치를 전혀 알려주지 않는 경우입니다.

네 가지 인코딩의 샘플 파일을 만들고, 무료 검사기를 작성한 뒤, 강제 줄바꿈된 단편 소설을 로컬 모델로 중국어 간체로 아홉 번 번역했습니다. 모델은 파일 전체를 볼 때는 강제 줄바꿈을 잘 처리했습니다. 하지만 파일을 줄 수 기준으로 잘라서 넣은 세 번의 실행에서는 모두 문장이 끊기고 한 인물의 행동이 다른 인물에게 배정되었습니다.

빠른 점검 목록

검사기는 모든 행에 대해 보고하고 인코딩, 바이트 순서 표시, 줄바꿈 문자, 강제 줄바꿈을 수정합니다. 장 제목과 누락된 빈 줄은 직접 수정해야 합니다. python3 check_txt.py inspect yourfile.txt를 실행하면 보고서를 볼 수 있고, python3 check_txt.py convert yourfile.txt clean.txt --unwrap를 실행하면 단락을 합친 UTF-8 사본을 작성합니다. Python 3만 있으면 되며 원본 파일은 절대 변경하지 않습니다.

1단계: 인코딩을 올바르게 설정하기

TXT 파일은 바이트의 연속입니다. 인코딩은 그 바이트를 문자로 바꾸는 규칙이며, 파일 자체는 어떤 규칙이 사용되었는지 알려주지 않습니다. 프로그램이 잘못 추측하면 깨진 글자(mojibake)가 나타납니다. 즉, 텍스트가 엉망이 되거나, 더 나쁘게는 겉보기에는 멀쩡하지만 실제로 쓰인 내용과 다른 텍스트가 됩니다.

다음은 동일한 중국어 구절 最后一班渡轮("마지막 페리")를 잘못된 규칙으로 읽은 결과입니다. Python의 내장 코덱으로 생성했으며, 샘플 파일로 재현할 수 있습니다.

마지막 행이 위험합니다. 일본어 바이트를 중국어로 읽으면 오류도 �도 없이 실제 중국어 문자가 생성됩니다. 번역 도구는 이를 아무 문제 없이 번역할 것이고, 결과는 문법은 좋지만 의미 없는 문장이 됩니다.

검사기는 "오류 없이 열렸다"는 것에 의존할 수 없는 이유를 보여줍니다. Shift_JIS 샘플에서 실행했을 때, 두 가지 인코딩이 파일 전체를 단 한 번의 오류도 없이 디코딩했습니다:

encoding: unknown (not UTF-8)
these legacy encodings decode without errors; read the previews,
because a wrong one can still produce real-looking characters:
  gb18030  戞堦榖丂嵟屻偺僼僃儕乕
  cp932    第一話　最後のフェリー

일본어인 것은 두 번째 줄뿐입니다. 첫 번째 줄은 아무도 쓰지 않은 희귀 중국어 문자의 나열입니다. GB18030 중국어 샘플에서는 다섯 가지 인코딩이 오류 없이 디코딩되었고, 그중 GB18030만이 장 제목 第一章 最后一班渡轮을 표시했습니다. 따라서 규칙은 간단합니다. 프로그램이 불평했는지 여부가 아니라 첫 줄들을 읽어 인코딩을 결정하세요.

추측이 보통 틀리는 지점:

• 구형 Windows 시스템이나 중국 사이트에서 가져온 중국어 텍스트는 종종 GBK 또는 GB18030입니다. GB18030은 GBK가 지원하는 모든 것을 포함하며, 브라우저가 따르는 WHATWG 인코딩 표준은 더 나아가 "GBK의 디코더는 gb18030의 디코더"라고 명시합니다. 파일이 GBK라면 GB18030으로 열면 됩니다.
• 대만이나 홍콩에서 온 번체 중국어는 종종 Big5입니다.
• 일본어는 종종 Shift_JIS 또는 Microsoft의 확장 버전인 cp932(Windows와 Python에서 부르는 이름)입니다.
• 한국어는 종종 EUC-KR입니다.
• NUL 바이트로 가득 찬 파일이나 다른 모든 문자가 비어 보이는 파일은 보통 바이트 순서 표시(BOM)가 없는 UTF-16입니다.

바이트 순서 표시(BOM)는 파일 시작 부분에 있는 짧고 보이지 않는 코드로, UTF-8, UTF-16 또는 UTF-32임을 알려줍니다. BOM이 있으면 그것을 신뢰하세요. 같은 표준은 "바이트 순서 표시가 다른 어떤 것보다 더 권위 있다"고 말합니다. 저희 검사기는 BOM을 먼저 읽고, 없을 때만 추측합니다.

파일을 UTF-8로 저장하세요

텍스트가 올바르게 읽히면 UTF-8로 저장하세요. WHATWG 표준은 UTF-8을 "유니코드 교환에 가장 적합한 인코딩"이라고 부르며, 어떤 번역 도구에도 가장 안전한 선택입니다.

특히 번역에서 중요한 두 번째 이유가 있습니다. 레거시 인코딩은 해당 지역의 문자만 포함합니다. Shift_JIS에는 这是最后一班渡轮의 첫 글자인 这에 대한 코드가 없고, Big5에도 없습니다. 간체 중국어 문자이기 때문입니다. Windows-1252는 키릴 문자를 저장할 수 없습니다. 번역된 파일을 원래 레거시 인코딩으로 다시 작성해야 한다면 대상 언어가 맞지 않을 수 있습니다. BookTranslator의 TXT 번역기는 일반적인 인코딩을 자동 감지하고 번역된 파일을 "입력과 동일한 인코딩"으로 반환한다고 합니다. 따라서 UTF-8에서 시작하면 이 문제가 완전히 사라집니다.

텍스트 편집기에서 변환하거나(올바른 인코딩으로 열고 "다른 이름으로 저장"에서 UTF-8 선택), macOS나 Linux에서 iconv -f GB18030 -t UTF-8 in.txt > out.txt를 사용하거나, 검사기로 변환할 수 있습니다:

python3 check_txt.py convert book.txt book-utf8.txt --encoding gb18030

파일에 이미 � 문자가 포함되어 있다면, 손상은 파일을 받기 전에 발생한 것입니다. 다시 변환해도 누락된 문자는 복원되지 않습니다. 더 나은 원본 사본을 찾으세요.

2단계: 장을 쉽게 찾을 수 있게 만들기

장은 세 가지 이유로 중요합니다. 긴 파일은 여러 조각으로 나뉘어 번역되며, 장 구분은 나누기에 가장 깔끔한 지점입니다. 번역 후 각 장을 확인하고 싶을 것입니다. 그리고 나중에 텍스트를 전자책으로 만들면 장 제목이 목차가 됩니다.

각 제목을 별도의 줄에 두고 앞뒤에 빈 줄을 넣으며, 책 전체에서 하나의 패턴을 사용하세요. 저희 검사기가 세는 패턴은 다음과 같습니다:

• Chapter 1, Chapter One: The Last Ferry, Part Two, Prologue, Epilogue
• 第一章, 第12回, 第三話, 第二卷
• 한 줄에 숫자나 로마 숫자만 있는 경우, 예: 12 또는 XII.

inspect를 실행하고 발견된 제목 목록을 읽으세요. 책에 40개의 장이 있는데 검사기가 37개를 찾으면 세 개의 제목이 숨어 있는 것입니다. 하나는 첫 문장에 붙어 있고, 하나는 "Ch. 7"과 같은 다른 단어를 사용하며, 하나는 같은 줄에 텍스트가 있습니다. 그 세 개를 직접 수정하세요. 번역된 파일에서 문제를 찾는 것보다 시간이 덜 걸립니다.

3단계: 하드 줄 바꿈을 조심스럽게 풀기

일부 TXT 파일은 텍스트가 일반 터미널이나 좁은 창에 맞도록 고정 너비로 모든 줄을 끊습니다. PDF에서 복사한 텍스트와 OCR 출력도 인쇄된 페이지 너비에서 같은 일을 합니다. 이러한 파일에서 줄 바꿈은 "줄이 꽉 찼다"는 뜻이지 "문장이나 단락이 끝났다"는 뜻이 아닙니다.

하드 래핑은 쉽게 발견할 수 있습니다. 하드 래핑된 샘플에서 검사기는 다음과 같이 보고했습니다:

non-empty lines: 43; longest line: 66 chars; 25 lines within 12 chars of the longest
line breaks inside paragraphs that do not end a sentence: 23
looks hard-wrapped: consider convert --unwrap

해결책은 각 단락 내의 줄을 합치고 단락 사이의 빈 줄은 유지하는 것입니다. 함정은 줄 바꿈이 실제인 텍스트입니다: 시, 노래 가사, 편지, 주소, 조리법, 목록. 저희 샘플에는 다섯 줄짜리 편지가 포함되어 있습니다:

My dear Mara,
The key is under the blue pot.
Do not let your uncle sell the boat.
With love, always,
Nonna

무조건 "모든 단일 줄 바꿈을 공백으로 바꾸기"를 하면 그것이 하나의 이어지는 줄이 됩니다. 검사기의 --unwrap은 단락의 대부분 줄이 전체 너비에 가까울 때만 단락을 합치므로, 이 편지처럼 짧은 줄 블록은 그대로 둡니다. 저희 샘플에서는 원래의 래핑되지 않은 파일을 바이트 단위로 정확히 재구성했으며, 편지도 포함되었습니다. 자신의 파일에서는 몇 개의 합쳐진 단락과 모든 시 블록을 확인한 후 신뢰하세요.

두 가지 세부 사항이 더 있습니다. 중국어나 일본어 텍스트의 줄을 합칠 때는 사이에 공백을 넣지 마세요. 검사기는 CJK 문장 부호로 끝나는 줄을 포함하여 CJK 줄을 공백 없이 합칩니다. 그리고 텍스트가 OCR에서 왔다면 단어가 줄 끝에서 하이픈으로 나뉘었을 수 있으며, 이는 별도의 결정이 필요합니다. OCR 줄 바꿈 및 하이픈 수정 가이드에서 다룹니다.

테스트한 내용: 하드 래핑된 텍스트, 전체 vs. 분할

하드 래핑이 실제로 번역 품질을 해치는지, 아니면 단지 보기 안 좋을 뿐인지 알고 싶었습니다. 테스트를 위해 396단어 분량의 단편 소설을 작성했습니다. 세 개의 장, 열다섯 개의 문단, 대화, 위에 나온 편지, 그리고 * * * 장면 전환까지 포함했습니다. 같은 단어를 두 가지 방식으로 저장했습니다. 줄바꿈 없는 버전은 한 문단당 한 줄로 되어 있고, 66자에서 하드 래핑된 버전은 비어 있지 않은 줄이 19개 대신 43개입니다.

그런 다음 로컬 모델에게 이 소설을 중국어 간체로 세 가지 방식으로 번역하도록 요청했고, 각 방식마다 세 번씩 실행했습니다:

1. 래핑됨, 파일 전체. 하드 래핑된 파일을 한 번의 요청으로 처리.
2. 래핑 안 됨, 파일 전체. 줄바꿈 없는 파일을 한 번의 요청으로 처리.
3. 래핑됨, 12줄마다 분할. 하드 래핑된 파일을 12줄마다 나누어 조각별로 요청하고, 응답을 다시 합쳤습니다. 스크립트나 도구가 긴 파일을 문단이 아닌 줄 수 기준으로 분할할 때 발생하는 상황입니다.

모델은 LM Studio에서 Qwen 3.6 27B (Q4_K_M)를 사용했고, 사고 과정은 끄고 temperature는 0.3으로 설정했으며, Apple M4 Max 64GB 메모리 환경에서 실행했습니다. 모든 요청에는 동일한 한 문장 프롬프트를 사용했습니다. 실행일은 2026년 10월 28일입니다. 스크립트는 run_llm_txt_test.py이며, 아홉 개의 출력은 모두 편집 없이 공개되었고, results.csv에는 실행별로 한 행씩 기록되어 있습니다.

첫 번째 발견은 우리를 놀라게 했다. 모델이 하드 랩된 파일 전체를 보았을 때, 스스로 줄을 합쳤다. 세 출력 모두 한 줄에 한 단락씩, 랩되지 않은 실행과 동일한 19줄이었고, 가독성도 같았다. 따라서 하드 랩만으로는 이 짧은 파일에서 이 모델에 해를 끼치지 않았다.

줄 수로 파일을 자르는 것은 매번 같은 위치에서 해를 끼쳤다. 12줄 조각 중 세 개가 문장 중간에서 끝났다. 첫 번째는 "He pointed with his"에서 끝나고 다음 조각은 "pen at a three-storey building on the corner."로 시작한다. 따로 번역하자 후반부는 주어를 잃었다. 두 번의 실행에서는 她瞥了一眼街角那栋三层楼的建筑, "그녀는 모퉁이의 3층 건물을 흘낏 보았다."로 돌아왔다. 세 번째 실행에서는 随后她重新回到填字游戏上, "그런 다음 그녀는 십자말풀이로 돌아갔다."로 끝났다. 이야기에서 매표소의 남자가 가리키고 십자말풀이로 돌아간다. 세 실행 모두에서 중국어 독자는 마라가 그렇게 했다고 생각할 것이다.

두 번째 절단은 "the careful, slightly old-fashioned hand she had learned at a"와 "convent school," 사이에서 일어나, 세 실행 모두에서 중국어 문장이 那是她在, "that was where she,"에서 매달리게 했고(한 실행에서는 잘못된 一이 추가됨), "learned"라는 단어가 사라졌다. 세 번째 절단은 셔터에 관한 문장을 두 줄로 나누었고, 후반부는 "painted, not well, but not long ago"를 벗겨진 페인트로 바꾸었다: 두 실행에서는 油漆虽已斑驳, 세 번째에서는 油漆剥落. 그리고 조각들이 단일 줄바꿈으로 연결되었기 때문에 장면 전환 앞의 빈 줄이 사라져 각 실행이 15개 대신 14개 단락을 가지게 되었다. 우리 검사기는 단락 수를 잡아냈다. 잘못된 문자는 잡아내지 못했다; 우리는 읽으면서 그것을 발견했다.

이것이 귀하의 파일에 의미하는 바:

• 언랩은 통제할 수 없는 분할기로부터 보호합니다. 모든 긴 파일은 어딘가에서 분할됩니다. 자체 스크립트, 채팅 창 제한, 업로드하는 도구 등 무엇이든 말이죠. 단락이 빈 줄로 구분된 단일 줄이라면, 합리적인 분할기는 문장 내부가 아닌 단락 사이에서 자를 수 있습니다.
• 최악의 오류는 유창했습니다. "그녀는 건물을 흘낏 보았다"는 좋은 중국어입니다. 독자는 각 절단 지점의 이상한 줄바꿈과 매달린 那是她在를 알아차리겠지만, 잘못된 문자나 벗겨진 페인트를 실수로 표시하는 것은 아무것도 없습니다. 분할 지점의 오류는 의미 오류가 먼저이고, 형식 오류가 두 번째입니다.
• 이것은 하나의 모델과 하나의 짧은 이야기였습니다. 이 정도로 짧은 파일은 한 번의 요청에 들어가므로, 전체 파일 실행은 아무것도 분할할 필요가 없었습니다. 전체 소설은 반드시 분할해야 하며, 바로 그때 1–3단계의 준비가 효과를 발휘합니다. 이 파일들은 준비와 분할을 테스트하는 것이지, BookTranslator 자체 파이프라인을 테스트하는 것이 아닙니다.

한 가지 더 작은 관찰: 6번의 전체 파일 실행에서 모델은 마라의 이름을 다섯 번은 玛拉로, 한 번은 马拉로 썼습니다. 각 출력은 그 자체로 일관되었지만, 별도 요청은 서로 일치하지 않았습니다. 많은 조각으로 번역되는 긴 책의 경우, 이름 목록과 합의된 철자를 유지하면 모든 장이 일관성을 유지합니다. 우리의 용어집 가이드는 용어집을 만드는 방법을 보여줍니다.

4단계: 번역한 다음 개수를 확인하세요

파일이 깨끗하면 번역은 쉬운 부분입니다. BookTranslator의 TXT 번역기에 업로드할 수 있습니다. 이 번역기는 .txt, .md, .mdx 파일을 허용하고, 최대 300MB의 TXT 파일을 처리한다고 명시하며, 결제 전에 가격을 보여줍니다. 무료 전체 번역은 없지만 업로드 자체가 비용을 알려줍니다. 채팅 모델이나 로컬 LLM으로 작업하는 것을 선호한다면, 파일을 장이나 단락 경계에서 직접 분할하고 이름에 대한 용어집을 유지하세요. 텍스트가 일반 산문이 아닌 Markdown이라면 Markdown 번역 가이드를 참조하세요. Markdown 구문에는 자체 규칙이 필요하기 때문입니다.

번역 후 두 파일을 비교하세요:

python3 check_txt.py compare book-utf8.txt book-translated.txt

두 파일 중 하나라도 UTF-8이 아니면 --source-encoding 또는 --translated-encoding을 추가하세요. 장 확인은 영어 및 중국어/일본어 제목 패턴을 인식합니다. 다른 대상 언어의 경우 스크립트 상단의 패턴에 "chapter"에 해당하는 현지 단어를 추가하세요.

다음은 우리의 분할 실행 중 하나에 대한 보고서입니다:

                            source  translated
paragraphs                      15          14  <- differs
chapter headings                 3           3
non-empty lines                 43          24  <- differs
scene breaks (* * *)             1           1
replacement chars                0           0
source script LATIN characters left in translation: 0

다음과 같이 읽으세요:

• 단락과 장 제목은 일치해야 합니다. 누락된 단락은 종종 두 단락이 병합되었거나 하나가 삭제되었음을 의미합니다.
• 비어 있지 않은 줄은 타당한 이유로 다를 수 있습니다. 우리의 전체 파일 랩 실행은 모델이 하드 랩된 줄을 합쳤기 때문에 43줄에서 19줄로 줄었으며, 이는 개선이었습니다. 원본이 이미 언랩된 경우에만 줄을 비교하세요.
• 남아 있는 원본 문자는 전혀 번역되지 않은 구절을 가리킵니다. 이름, 제품 용어 또는 인용문의 경우 몇 개는 정상입니다. 연속으로 나타나면 건너뛴 섹션입니다.
• 번역에서 대체 문자는 출력 과정의 인코딩 문제를 의미합니다.

개수만으로는 번역이 올바른지 알 수 없습니다. 각 장의 첫 단락과 마지막 단락, 그리고 파일이 분할된 모든 위치의 양쪽 단락을 읽으세요. 우리 테스트에서 모든 심각한 오류가 발견된 곳이 바로 그곳입니다.

자주 묻는 질문

왜 내 TXT 파일이 한 프로그램에서는 괜찮아 보이고 다른 프로그램에서는 깨져 보이나요?

두 프로그램이 서로 다른 인코딩을 추측했습니다. 하나는 맞혔습니다. 텍스트를 올바르게 표시하는 인코딩을 찾은 다음 파일을 UTF-8로 저장하여 모든 프로그램이 동일하게 읽도록 하세요.

번역하기 전에 TXT 파일을 EPUB 또는 DOCX로 변환해야 하나요?

다만 해당 형식이 제공하는 기능을 원할 때만 그렇습니다. 장이 명확한 깔끔한 TXT 파일은 그대로도 잘 번역됩니다. 목차, 장 탐색, 기기에서 읽을 수 있는 전자책을 원하신다면 웹 소설을 번역 가능한 EPUB로 변환하기 가이드에서 자세히 다룹니다.

여러 언어가 섞인 TXT 파일도 번역할 수 있나요?

가능하지만, 번역기에 무엇을 그대로 둘지 알려주세요. 제3언어의 인용문이나 용어, 원래 문자로 유지해야 하는 이름은 나중에 고치는 것보다 용어집이나 짧은 지시로 보호하는 편이 쉽습니다.

웹사이트에서 다운로드한 TXT 파일은 어떻게 하나요?

사용 권한이 있는지 확인하세요. 퍼블릭 도메인 도서나 직접 작성한 파일이라면 위 단계를 그대로 따르면 됩니다. 파일의 인코딩이나 형식만으로는 저작권 여부를 알 수 없습니다.