메아리 저널

요전에 플레인 텍스트를 옹호하는 이유에 대해서 글을 쓴 적이 있었는데, 비단 일반적인 글이 아니더라도 텍스트 기반 파일 포맷 역시 바이너리 파일 포맷에 비해 보통 많은 장점을 가진다. 에릭 레이몬드도 비슷한 글을 쓴 적이 있기도 하니 자세한 내용은 이 쪽을 보시고, 내 생각에 가장 중요한 장점은 애플리케이션이 사라졌거나 오동작할 때도 데이터를 어떻게든 뽑아 올 수 있다는 것이다. 나만 해도 몇 가지 사례를 가지고 있다:

• 옛날에 쓰던 핸드폰에서 주소록을 뽑아 와야 했는데, 전용 소프트웨어(EVER Communicator-_-)에서 데이터를 컴퓨터로 옮기긴 했지만 그걸 다시 현재 핸드폰으로 어찌 옮기느냐가 막막했다. 그런데 확인해 보니까 다행히도 CSV라서 어렵지 않게 확인할 수 있었다. 반면 옛 핸드폰에 남아 있던 문자 송수신 기록들은 바이너리 포맷이라서 뭐 어째야 할질 모르겠다. (리버스 엔지니어링이라도 해야 하나…)
• 서버에 irssi를 올려 놓고 IRC 프락시로 쓰고 있는데, 여기에서 돌리고 있는 네트워크가 제각각 인코딩이 달라서 터미널로는 현재 터미널 인코딩과 다른 인코딩을 쓰는 네트워크에 채널을 추가하거나 하는 것이 매우 곤란하다. 다행히도 ~/.irssi/config 파일은 텍스트이기 때문에, 여기서 수동으로 파일을 고쳐서 채널을 추가한 뒤 irssi에서 /reload 명령을 실행하는 것만으로 쉽게 고칠 수 있었다. (이 문제는 궁극적으로는 screen과 irssi의 상성 문제라서 해결이 쉽지 않은 것으로 알고 있다.)
• 비슷하게, VLC에서 설정을 잘못 해서 아예 뜨지도 않을 때 (실수로 Qt 인터페이스를 지워버린다거나 하는…) vlcrc 파일을 고쳐서 손쉽게 원래대로 돌릴 수 있었다. 참고로 나는 VLC 설정이 꽤 있는 편이라서 그냥 지우면 좀 많이 곤란하다(…).
• 예엣날에 비주얼 스튜디오를 안 깔고 살 적에(지금은 깔려 있지만), 어떤 라이브러리의 비주얼 스튜디오 프로젝트 파일만 보고 대응되는 Code::Blocks 프로젝트 파일을 만든 적이 있다. 참고로 비주얼 스튜디오 프로젝트·솔루션 파일은 예나 지금이나 텍스트 기반이며(요즘은 XML 기반) 심지어 옛 버전은 Makefile 기반이기까지 했다(정확히는 nmake 호환 Makefile).

물론 텍스트 파일 포맷이 만능인 것은 아니다. 몇 가지 문제와 해결책을 나열하자면:

• 가장 큰 문제는 파일 포맷의 파싱 등으로 인한 비효율 및 버그인데, 뭐 처리 속도는 요즘이라면 상관 없지만 버그 — 이를테면 문자열을 "로 묶는데 문자열 안에 "가 들어 가야 하는 상황을 제대로 처리하지 못 한다거나 — 는 여전히 문제가 된다. 그나마 요즘은 이런 류의 파일들을 저장하고 처리하는 라이브러리들이 좀 있어서 그걸 갖다 쓰면 되긴 한다.
• 파일 크기가 크다는 문제는 요즘은 gzip 및 zip 파일로 컨테이너를 만드는 방법으로 많이 극복된 상태이다. 당장 ODF와 OOXML의 예만 봐도… 하지만 만약 네트워크로 전송되거나 해야 해서 파일 크기를 줄여야 한다면 잘 생각해 볼 필요가 있다. (PNG 같은 것들)
• 또 다른 문제는 요즘 대세가 XML이랍시고 모든 파일을 XML로 만들고 하는(…) 정신나간 경우가 많이 보인다는 것이다. XML은 물론 대강 구조화되어 있는(semi-structured) 데이터에는 괜찮지만, 구조가 선형적이거나¹ 한 파일로 뭉갤 수 없을 정도로 대규모의 데이터를 저장할 경우 그 비효율 및 단점은 바이너리 포맷을 능가한다.
• 원래부터 바이너리일 수 밖에 없는 데이터(임의의 이미지, 사운드 등)를 텍스트로 저장하겠답시고 base64를 쓰고 하는 건 미친 짓에 가깝다. 차라리 별도의 컨테이너(zip 등)를 쓰고, 데이터는 컨테이너 안에 따로 (이미 잘 알려진) 포맷으로 저장한 뒤 필요하면 컨테이너 내의 경로로 그 데이터를 가리키게 하는 것이 효율적이다. 텍스트큐브 백업 포맷이 대표적인 예인데, 나는 이 파일을 필요해서 종종 볼 때마다 base64 때문에 구역질이 나서 죽겠다…

이렇게 생각하면, 텍스트 파일 포맷의 장점은 텍스트 파일 포맷”이라서” 좋은 게 아니라 단순히 텍스트 파일이 최소한의 표준(minimal standard)이기 때문에 얻은 게 아닐까 하는 생각도 든다. EBML이나 sBOX와 같은 표준화된 바이너리 포맷이 텍스트 파일과 같은 목적을 가지지만 바이너리 포맷의 장점도 취하고 싶은 경우에 딱 맞는 게 아닐까 싶긴 하지만, 나는 EBML을 Matroska 바깥에서 본 적이 전혀 없기 때문에(…) 확신할 수는 없다. (그나마 텍스트 파일 포맷을 담는 압축 컨테이너는 zip으로 거의 자리가 잡혔으나;) 이런 종류의 괜찮은 대안이 나오지 않는 한, 텍스트 포맷 및 이를 담는 컨테이너는 계속 꾸준히 쓰일 거라 보며 또한 쓰여야 한다고 본다.