일반 텍스트는 여전히 우리가 가진 최고의 기술 중 하나다

글에서도 잠깐 다루지만, 시대와 분야에 따라 일반 텍스트의 모습이 얼마나 다른지 흥미로움. 주요 운영체제는 이제 대체로 \n을 쓰지만, 내 오래된 파일에는 Microsoft의 \r\n, Macintosh의 \r, RiscOS의 \n\r도 남아 있음. 마지막 줄의 종료 방식도 다름. POSIX는 마지막 줄까지 \n으로 끝내지만, Microsoft 소프트웨어는 다른 부분에서 POSIX식 줄바꿈을 채택한 뒤에도 마지막 줄은 종료 문자가 없어도 된다고 보는 경향이 있음. 줄바꿈을 줄의 종료가 아니라 구분으로 취급하는 셈이라, 두 파일의 줄을 이어 붙이려 할 때 cat(1)과 잘 맞지 않음. 다른 유닉스 계열 도구들은 마지막 줄이 제대로 종료되지 않을 가능성에 적응한 듯함.
인코딩도 걸림돌임. 원래 인코딩을 휴리스틱으로 추정해 UTF-8로 변환하는 좋은 도구가 있다면 알고 싶음. 영어라는 사실만 알아도 축약형의 아포스트로피나 따옴표 바이트로 인코딩을 추정하기 어렵지 않을 듯함. 그래도 영어로 된 8비트 인코딩 파일은 잘못된 바이트를 네모로 표시하기만 해도 대체로 읽을 만함.

텍스트는 훌륭하지만, 이 글에는 파싱이라는 핵심 단어가 빠져 있음. 처음부터 구조화된 바이너리 형식으로 만들었다면 훨씬 쉽게 처리했을 데이터를 위해 텍스트 파서를 작성하느라 얼마나 많은 일이 추가되는지 생각해 봐야 함. 형식마다 바퀴를 새로 설계하는 즐거움은 여전히 남아 있음.

Microsoft가 \n을 채택했다는 부분을 자세히 설명해 줄 수 있는지? 처음 듣는 얘기이고 온라인에서도 관련 내용을 찾을 수 없음.

오늘 아침 Copilot으로 LINQPad 스크립트를 만들어 이런 문제 상당수를 해결했음. 다만 모든 파일이 UTF-8이라는 사실을 알고 있었으므로, BOM 없이 인코딩을 추측할 필요는 없었음.

이는 표준 하나가 마침내 승리했을 때 모두가 얻는 혜택임. 글은 Unicode에 공을 돌리지만, 일반 텍스트의 이식성과 수명을 보장한 것은 ASCII의 확실한 승리임. Unicode도 같은 방향으로 가고 있지만 아직 도달하지는 못했음. 예기치 않은 오류를 피할 유일한 방법이라 내가 쓰는 텍스트 파일은 여전히 대부분 순수 ASCII임. Windows 줄바꿈 문제는 별개임.

일반 텍스트에서 ‘일반’이라는 말이 너무 많은 것을 떠맡고 있음. 간단한 4바이트 식별 표식만 있었어도 훨씬 나았을 것임.
지금은 프로그램이 인코딩과 코드 페이지, UTF-16의 바이트 순서, CR·LF·CRLF 같은 줄바꿈, 100.000과 100,000 같은 숫자 표기, 월-일-연도와 일-월-연도 같은 날짜 형식, 작성 언어까지 추측해야 함. CSV는 말할 것도 없음.
XLS보다는 읽고 파싱하고 추측하기 쉽고, 어느 정도 추정할 수 있다는 점은 인정함. BOM도 인코딩 문제를 해결하려 하지만 대부분의 파일에 없고 지원하지 않는 도구도 많으며, 나머지 문제는 해결하지 못함. 영어에 미국식 날짜와 Windows 줄바꿈만 쓰는 ASCII 파일이라면 아무 문제 없겠지만 말임.

이른바 Windows 줄바꿈인 CRLF는 HTTP와 SMTP 같은 통신 프로토콜에서도 표준임. Windows나 DOS 때문이 아니라 CR과 LF가 모두 필요했던 텔레타이프에서 유래했으며, 오히려 Unix 같은 시스템이 표준에서 벗어났다고 볼 수 있음.
ASCII를 벗어나면 Unicode 지원이 안정적인 영역부터 까다롭고 문제가 많은 영역까지 이어진다는 데는 동의함. HN도 결합 문자로 만든 Zalgo 텍스트나 이모지 등 여러 요소를 걸러 내지만, 무엇을 지원하는지 명세가 없음.
ASCII 안에서도 대부분의 제어 문자는 이식 가능한 의미를 갖지 못함. 결국 출력 가능한 ASCII 문자만 해당하며, 역슬래시가 엔화 기호로 바뀌는 일본식 변형까지 고려하면 엄밀히는 그마저도 아님.

파일 끝 처리도 예외임.

ASCII로 파일을 작성한다면 이미 UTF-8로 작성하는 셈임.

중간 도구 없이 기호에서 의미를 쉽게 읽어 낼수록 내구성과 복원력이 높아짐. 종이에 적힌 기호가 가장 좋고, 어느 컴퓨터에서나 열 수 있는 일반 텍스트 파일이 그다음이지만 도구가 필요함. 하드웨어뿐 아니라 전용 소프트웨어까지 필요한 복잡한 파일 형식이 가장 불리함.
다만 표현력과의 절충은 중요함. 복잡한 형식은 단순한 기호만으로 전달하기 어려운 정보를 표현하고, 상호작용을 통해 이해를 도울 수도 있음.

오랜 친구인 Base64가 빠졌다니 아쉬움! Base64를 쓰면 굳이 텍스트일 이유가 전혀 없는 것까지 모든 것을 텍스트로 만들 수 있음. 온갖 자원을 낭비하는 일이 흔한 요즘 기준으로는 비교적 효율적이기까지 함. 페타바이트 단위로 밀어 넣어도 되겠고, 완전히 비꼬는 말만은 아님.

거기에 RFC2045 헤더를 붙이면 어떤 인코딩인지도 알 수 있음.

마침 이번 주말에 작은 프로젝트로 브라우저 기반 일반 텍스트 희곡 작성 앱을 만들었음. 극본 작성 소프트웨어의 불편함과 파일 공유의 어려움이 정말 싫어졌기 때문임.
일반 텍스트라면 누구에게나 어떤 기기로든 파일을 건넬 수 있지만, 정작 일반 텍스트 극본을 받고 싶어 하는 사람은 없다는 단서가 붙음. 10년 전에 희곡을 쓰던 소프트웨어는 오래전에 지원이 중단돼 파일을 사실상 열 수 없게 됐지만, 일반 텍스트는 여전히 남아 있음.

자체 마크업을 만들 때는 XML도 좋은 기반임. DTD나 네임스페이스 같은 번거로운 요소는 무시하고 태그는 태그로, 텍스트는 텍스트로 쓰면 됨.

John August도 영화·TV 극본에 일반 텍스트를 활용하는 방법을 다뤘고, Markdown과 할리우드 표준에 기반한 형식을 정의했음: https://fountain.io/.
공유뿐 아니라 버전 관리에도 일반 텍스트 형식이 도움이 될 듯함.

첫 세 문단을 Pangram에 넣으니 AI 생성 확률이 100%로 나왔음. 더 읽지 않고 넘어가겠음.

Markdown을 쓰는 대부분의 상황에서 나는 일반 텍스트를 훨씬 선호함. 이런 용도에서는 서식 문법보다 WYSIWYG가 더 유용함. Markdown 문법을 무시하고 일반 텍스트로 읽으면 된다고 하지만, 줄바꿈부터 그렇게 되지 않음.
Markdown은 가독성을 오히려 해치는 사소한 서식에 시간을 쓰게 만들기도 함. 필드까지 넣어 HTML처럼 쓰기 시작하면 더 나빠짐. 이전 직장에서는 이것이 내부 문서 작성 의욕을 꺾기에 새 문서를 모두 Google Docs로 작성하기 시작했고, 결과적으로 문서가 훨씬 충실해지고 최신 상태로 유지됐음.
이제 LLM이 Markdown을 쓰게 할 수도 있지만 사람이 읽지 않을 가능성이 크고, 읽더라도 서식이 지나치게 복잡해지기 쉬움. Claude에 맥락 정리본을 요청할 때도 .md 대신 .txt로 달라고 계속 말해야 함. 에이전트용 README에 .md가 인기인 것은 제목 구조에 맞춰 최적화돼 있기 때문일지도 모름.

일반 텍스트를 좋아하지만, 에이전트 시대에는 50년 뒤에도 내용을 읽을 수 있을지를 따지는 일이 더 흥미로워짐. 에이전트는 스키마 없이 구조화된 데이터의 의미를 추론하고, 압축을 풀고, 내부에 포함된 파일을 찾아낼 수 있음. 완벽하지는 않아도 바이너리 형식의 장기 활용 가능성은 그 어느 때보다 높아짐.
임의의 바이너리 형식을 다루는 능력이 모델 가중치에 모두 들어 있지는 않지만, 에이전트는 스스로 도구를 작성해 기존 유닉스 유틸리티의 이점을 상당 부분 얻을 수 있음. Godot의 텍스트 기반 장면 기술 형식을 좋아함. 시각적 스크립팅인 블루프린트를 바이너리로 저장하는 Unreal Engine과 뚜렷하게 대비됨.

일반 텍스트를 어휘 분석·구문 분석 결과로 변환하는 데 가장 좋은 도구는 무엇인지? 이런 도구라면 사용자가 EBNF 문법을 작성해야 할 것으로 예상함. ANTLR는 괜찮았지만 Java 의존성 때문에 도구로 쓰기에는 지나치게 복잡하고 발전도 정체된 듯함. tree-sitter 역시 복잡하고, 사용법을 이해하려면 C/C++까지 알아야 하는 부담이 있음.