어떤 파일 형식을 50년 뒤에도 안심하고 열 수 있을까. 이 질문에 자신 있게 답할 수 있는 후보는 많지 않지만, 플레인 텍스트(plain text)는 그 드문 예외에 속한다. 얼핏 보면 이는 칭찬이라기보다 한계처럼 들린다. 텍스트 파일은 스프레드시트를 품을 수도, 정교한 페이지 레이아웃을 보존할 수도, 프레젠테이션을 실행할 수도 없다. 대신 그것은 글자를 컴퓨팅에서 가장 단순하고 널리 이해되는 형태로 저장한다. 그리고 바로 그 단순함이 수십 년을 살아남은 핵심 이유다.
유니코드 표준은 플레인 텍스트를 사실상 '문자 코드의 연속'으로 정의한다. 리치 텍스트가 품는 서식 정보, 즉 글꼴·색상·레이아웃 같은 표현 요소는 플레인 텍스트의 영역이 아니다. 사용자 입장에서 중요한 것은 더 간단하다. 파일이 특정 애플리케이션 없이도 내용 그 자체를 담는다는 점이다. 리눅스에서 만든 텍스트 파일을 윈도우로 복사하고, 웹 서버에 올리고, 터미널에서 열고, 명령줄 도구로 검색하고, 전혀 다른 시스템을 쓰는 상대에게 보내도 거의 문제가 없다. 파일이 '어떻게 만들어졌는가'에 의존하는 부분이 극히 적기 때문이다. 반대로 상당수 문서 포맷은 정보가 특정 애플리케이션 계열에 단단히 묶여 있어, 오래된 파일을 여는 일이 '지금도 그 소프트웨어가 존재하기를 바라는' 도박이 되기도 한다.
잊힌 기술이 아니라 배관이다
플레인 텍스트는 구조받아야 할 유물이 아니라 컴퓨팅의 기본 배관으로 여전히 작동한다. 소스 코드, 설정 파일, 로그 파일이 대개 텍스트다. HTML, XML, JSON, CSS, 셸 스크립트, 프로그래밍 언어와 각종 설정 포맷도 사람이 눈으로 들여다볼 수 있는 문자를 중심으로 만들어진다. 물론 이들은 평범한 산문이 아니라 구조화된 형식이다. HTML 문서가 .txt 메모와 같지는 않다. 공통점은 내용이 여전히 '보인다'는 데 있다. 기본 텍스트 편집기로 열면, 전부 이해하지 못하더라도 무엇이 들어 있는지는 확인할 수 있다.
이 특성은 실무에서 곧바로 값을 한다. 텍스트 설정 파일에 문제가 생기면 그것을 만든 프로그램 없이도 직접 들여다보고, 복사하고, 버전을 비교하고, 특정 설정을 검색하고, 백업할 수 있다. 정상적인 애플리케이션 밖에서도 읽히는 데이터는 문제 해결과 보존이 훨씬 쉽다. 게다가 이미 존재하는 방대한 도구 생태계가 텍스트를 다룰 줄 안다. 유닉스 계열에서는 grep, sed, awk, sort, diff 같은 수십 년 된 유틸리티에 파일을 넘길 수 있고, 스크립트는 사람이 메뉴를 클릭하는 척하지 않고도 수천 개의 파일을 처리한다. 핵심은 정보가 하나의 인터페이스에 밀착되어 있지 않다는 점이다. 현대 소프트웨어는 종종 그 반대로 간다. 데이터의 위치, 조직 방식, 동기화, 검색, 접근 권한까지 애플리케이션이 결정하면서 데이터를 점점 그 애플리케이션 중심으로 만든다. 플레인 텍스트는 그런 선택을 사용자에게 더 많이 남겨 둔다.
마크다운이라는 실용적 타협
플레인 텍스트의 뚜렷한 약점은 서식이다. 제목, 강조, 링크, 목록, 인용 같은 구조는 문서를 읽기 쉽게 하지만 기본 .txt에는 이를 표현할 표준 방법이 거의 없다. 2004년 등장한 마크다운은 이메일과 유즈넷에서 이미 익숙했던 관례를 끌어온 실용적 타협안이다. 그 진짜 강점은 마크다운 처리기가 사라져도 원본이 여전히 쓸모 있다는 데 있다. 제목은 여전히 제목처럼 보이고, 글머리 목록은 목록처럼 보이며, 링크에는 설명과 목적지가 그대로 남는다. 서식 문법이 바이너리 구조 속에 묻히지 않고 눈에 보이기 때문이다. 플레인 텍스트의 핵심 장점을 포기하지 않으면서 유용한 기능을 더한 좋은 사례다.
수명이야말로 플레인 텍스트의 가장 강력한 논거일지 모른다. 컴퓨팅의 역사는 버려진 포맷과 애플리케이션으로 가득하고, 오래된 문서를 되살리려면 폐기된 소프트웨어를 찾거나 에뮬레이터를 돌리거나 여러 중간 포맷을 거쳐야 할 때가 있다. 텍스트 파일이 호환성 문제에서 완전히 자유로운 것은 아니다. 오래된 파일은 문자 인코딩 문제를 안고 있을 수 있고, 줄바꿈 처리 방식의 차이는 오랫동안 성가신 골칫거리였다. 그래도 이런 문제는 난해한 독점 포맷에서 정보를 복구하려는 시도에 비하면 대체로 다룰 만하다. 오래된 텍스트 파일을 발견하면 지금 쓰는 컴퓨터의 어떤 프로그램이 그것을 열 가능성이 매우 높고, 서식이 거칠거나 인코딩에 손이 가더라도 글자 자체는 대개 복구된다. 유니코드는 과거 영문 위주의 ASCII 개념을 넘어 전 세계 문자 체계를 담아내면서도 '파일은 독점적 표현이 아니라 인코딩된 문자를 담는다'는 기본 발상을 그대로 유지한다.
단순함이 적절할 때
이 장점은 소프트웨어가 계정, 클라우드 저장소, 동기화 서비스, 구독으로 옮겨 갈수록 더 두드러진다. 텍스트 파일은 그저 디렉터리에 존재하면 된다. 다른 파일과 함께 백업하고, 원하는 방식으로 동기화하고, 버전 관리에 넣고, 내가 통제하는 서버에 보관할 수 있다. 그 무엇도 편집기를 만든 회사가 사업을 계속하거나 서비스를 유지하는 데 의존하지 않는다. 그렇다고 모든 클라우드 애플리케이션이 나쁜 선택은 아니다. 협업, 데이터베이스, 임베디드 미디어, 복잡한 서식, 서로 다른 정보 간의 관계는 텍스트만으로는 쉽게 해내기 어렵고 분명한 쓰임이 있다. 쓸모 있는 기준은 '추가된 복잡성이 실제 문제를 푸는가, 아니면 또 하나의 의존성이 될 뿐인가'다.
플레인 텍스트가 만능은 아니며, 그래서도 안 된다. 사진을 픽셀의 텍스트 설명으로 대체하고 싶은 사람은 없고, 수식을 일일이 재구성해야 하는 숫자 더미로 재무 워크북을 바꾸고 싶지도 않다. 데이터베이스는 디렉터리 속 텍스트 파일이 강제할 수 없는 관계를 보장하고, 워드프로세서는 손으로 재현하기 번거로운 페이지 레이아웃을 처리한다. 문제는 더 풍부한 도구를 쓰는 것이 아니라, 작업이 요구하지 않는데도 그 도구가 당연히 낫다고 가정하는 데 있다. 놀랄 만큼 많은 경우, 충분한 수준의 가장 단순한 표현이 가장 오래가는 표현이기도 하다. 플레인 텍스트는 너무 잘 작동해서 거의 보이지 않는 기술이다. 참여도를 끌어올리려는 회사도, 계정 요구도, 구독 등급도, 사업 모델이 바뀌면 중단될 서비스도 없다. 화려하지는 않지만, 적게 하면서 오래 살아남는 기술이 긴 시간 앞에서 보여 주는 안정성은 그 자체로 상당한 성취다.