다른 사람과 소통하기 위한 텍스트를 작성하는 데 있어서 워드 프로세서는 멍청하고 전적으로 비효율적인 도구이다. 이 글에서 필자가 주장하려는 논지이다. 일견 해괴한 주장으로 여겨질지 모르겠다. 워드 프로세서에 반대한다면, 대안이 무엇인가? 연필로 쓰자는 것인가? 아니면 기계식 타자기를? 물론 답은 No이다. 이런 식의 텍스트 작성에 대해서 말하는 한, 이 글을 읽는 대부분의 독자들이, 내가 그러하듯이, 컴퓨터로 문서를 작성하는 것을 당연하게 생각하고 있을 것이다. 내가 말하고자 하는 것은, 컴퓨터를 글을 쓰면서도 워드 프로세서보다 훨씬 더 나은 방법이 있다는 것이다.
의도적으로 도발적인 주장을 제시하였으나, 분명히 해두고 싶은 것이 있다. 즉, 내가 멍청하다고 말한 것은 워드 프로세서를 가리켜서 한 말이지 그것을 사용하는 사람(당신)을 두고 한 말이 아니었다는 점이다. 내가 비난하는 것은 대기업 소프트웨어 제조회사가 주도면밀하게 시장 개척을 하여 그 분야의 사실상 de facto 표준이 된 특정 소프트웨어가 아니라, 그 기술(technology)이다. 워드 프로세서 이외의 다른 대안이 있다는 것을 알지도 못한 채로 지낼 뻔하였으니 그것을 알게 된 당신은 운이 좋은 편이다. 그 대안을 대기업이 프로모션하는 것도 아닌데, 그 이유는 이제 보게 되겠지만 자유롭게 이용할 수 있는 것이기 때문이다.
최종 결과물이라는 관점에서 얘기를 시작하자. 다른 사람에게 어떤 생각이나 정보를 전달하기 위하여 작성되는 텍스트는 대개 두 가지 형태로 유포된다.
두 가지가 겹쳐있는 경우도 있다. 예컨대 인쇄용으로 작성된 문서를 디지털 매체로 배포하여, 수신자가 그 파일을 인쇄하여 보도록 할 수도 있다. 그렇지만 이 두 가지 배포 형태를 하나씩 검토해보자.
문서를 컴퓨터로 입력하여 프린터에서 멋지게 인쇄된 형태로 나오게 하고 싶다. 이 두 과정이 동시에 일어나기를 바라지는 않을 것이다. 즉 키보드로 타이프하는 즉시 출력이 이루어지는 것을 원하는 것은 아니다. 먼저 문서를 입력하여 저장장치에 전자적 형식으로 “저장”한다. 나중에 이 문서를 불러들여서 필요하다면 수정하고 편집한 다음, 다 잘 되었다고 생각될 때 프린터로 보낸다. 이 일을 하는 데 있어서 워드 프로세서, 이를테면 가장 많은 사용자를 가진 마이크로소프트 워드(Word)가 확실히 가장 “자연스런” 방식일 것인가? 워드를 이용하는 것도 한 가지 방법이기는 하다. 그러나 가장 좋은 방법은 아니다. 왜 그런가?
여기 두 가지 일이 있다. 이 둘은 “개념상” 구분되며, “실제로” 구분되어야만 시간을 효율적으로 사용할 수 있고 최종적 소통이 효과적으로 이루어질 수 있게 된다. 그런데, 워드 프로세서를 이용하여 인쇄물을 작성하게 되면, 이 두 가지 일이 한꺼번에 뒤엉키고 만다.
텍스트의 작성자는 적어도 처음 단계에서는 첫번째 일에 전적으로 집중해야 한다. 그것이 원고 작성자가 해야 하는 일이다. 아담 스미드가 분업의 놀라운 혜택을 설파한 바 있듯이, 책을 만드는 데 있어서 본문을 작성하고 논리적 구조를 부여하는 것은 원고 작성자의 전문 분야이고, 조판은 조판사의 전문 분야이다. 컴퓨터 시대가 오기 전 전통적인 출판 분야에서는 이러한 분업이 아주 잘 지켜지고 있었다. 원고 작성자는 글을 쓴 다음 여러 가지 주기(注記)를 붙여 출판인에게 텍스트의 논리적 구조를 지시해 주었다. 조판사는 원고 작성자의 아이디어를 구체적인 타이포그라피 디자인의 형태로 구현하여 원고를 인쇄된 문서 형태로 만들었다. 제인 오스틴이 『오만과 편견』의 장 표제를 무슨 글꼴로 표시할까 고민하고 있다고 한다면, 이 얼마나 바보같은 생각인가. 제인 오스틴은 위대한 작가이다. 그러나 그녀가 조판사는 아닌 것이다.
이것이 논점을 벗어난 것이라는 생각이 들지 모르겠다. 제인 오스틴의 원고는 출판에 부치기에 충분하였고 전문적인 조판사는 레이아웃을 주고 인쇄하는 데만 관심을 가져도 되었다. 우리가 처한 형편은 그렇게 한가롭지 않다. 인쇄물을 작성하려면 그 모든 것을 스스로 해내야 하는 것이다. 게다가 전통적인 조판의 경우보다 훨씬 빨리 해야 한다. 좋다. 그 주장도 일리는 있다. 모든 것을 스스로 자신의 컴퓨터에서 다 해야 하니 벅차다는 생각이 들겠지만, 도움받을 수 있는 것이 많다. 특히 전문가 수준의 품질을 내는 조판 전문 프로그램을 이용할 수 있다. 이 프로그램, 혹은 프로그램 집합이 하는 일은, 전통적 조판사들이 셰익스피어, 제인 오스틴, 월터 스콧 경 등의 작가들에게 해주었던 것과 같은 일을, 1초 이내 또는 몇 초 내에, 그것도 무료로, 해주는 것이다. 우리는 그저 전통적 작가들이 했던 것처럼 텍스트에 적절한 주기를 붙여서(mark-up), 프로그램에게 전해주기만 하면 된다.
그러므로 내가 제안하는 것은, 컴퓨터를 이용하여 책을 만들 때도, 두 가지 “단계”를 구분하자는 것이다. 첫번째로 텍스트를 작성하고 논리적 구조를 부여한 다음, 이 구조를 간략한 주기로 표시하여 둔다. 이 일은 텍스트 에디터로 한다. 텍스트 에디터는 워드 프로세서와는 다른 소프트웨어인데, 차이점을 뒤에 좀더 자세히 말하겠다. 그런 다음에, 이 텍스트를 조판 프로그램에게 “넘겨주면” 그 프로그램이 금세 아름다운 최종 출력물을 만들어준다.
오늘날 WYSIWYG(“What You See Is What You Get”) 워드 프로세서에서는 이 두 가지 일이 하나로 뒤엉켜 있다. 글자를 입력하면 입력한 대로 컴퓨터 화면에 구체적인 타이포그라피 형태로 나타난다. 마치 화면에서 보이는 대로 출력 결과가 나타나는 것으로 여겨진다(여러 가지 이유에서 완전히 동일한 출력을 항상 얻을 수 있는 것은 아니지만). 결국 텍스트를 입력함과 동시에 조판이 지속적으로 이루어지고 있는 셈이다. 언뜻 보기에 이것은 대단히 편리해 보인다. 그러나 조금 더 생각해보면 이것은 재앙이다. 다음 세 가지 이유를 제시할 수 있다.
처음 두 가지는 자명하다. 세번째 논점을 좀 더 논의해보자. 다만, 논리적 구조의 중요성은 작성하는 문서의 유형에 크게 좌우될 것이다.
절 표제(섹션 헤딩)의 경우를 예로 들어보자. 문서의 논리적 구조가 문제라면, 중요한 것은 텍스트의 특정 부분이 절 표지라는 사실을 어떤 식으로든 “표시”해주는 것일 뿐이다. 예를 들어 \section{절 표제} 와 같이 적어주면 된다. 이 부분이 인쇄되어 나왔을 때 어떤 타이포그라피로 구현되느냐 하는 것은 전혀 별개의 문제이다. 그런데, 워드 프로세서를 사용하게 되면, 눈에 보이는 것밖에는(!) 얻을 수 없다. 절 표제를 작성하는 그 순간에도 특정 타이포그라피 모양을 결정하지 않으면 안되는 것이다.
이제 이 절 표제를 굵은 글꼴로 하되 본문 글꼴보다 조금 크게 적고 싶다고 하자. 이러한 모양(외관)을 어떻게 얻을 것인가? 여러 가지 방법이 있겠지만, 대부분의 사용자에게 가장 자명하고 직관적인 방법은(완전한 WYSIWYG 환경이라고 가정하고), 절 표제에 해당하는 텍스트를 입력하고 그 부분을 선택한 다음 boldface 버튼을 클릭하고, 글자 크기 박스를 열어서 조금 큰 값을 지정하는 것이라고 생각한다. 절 표제가 조금 큰 크기의 굵은 글꼴로 바뀌었다.
멋지다! 그런데, 이 부분이 절 표제라는 사실을 보여주는 것이 무엇일까? 이 문서의 논리적인 맥락에서 이 부분이 절 표제라는 사실을 지시하는 것은 아무것도 없다. 좀 지난 뒤에 마음이 바뀌어서 절 표제를 작은대문자로 식자하게 하고 싶어지거나, 절 번호를 붙이고 싶어지거나 중앙정렬로 배치하고 싶어진다면 어떻게 할 것인가? “문서의 모든 절 표제에 이러저러한 설정 변화를 적용하라”고 간단히 명령하는 것이 가장 편하다. 그런데, 만약 문서를 위에 적은 방법으로 작성해둔 경우라면, 문서 전체를 훑어가면서 각 절 표제 부분을 일일이 찾아서 손으로 수정하지 않으면 안된다.
현재는 마이크로소프트 워드와 같은 프로그램에도 텍스트에 논리적 구조를 부여하는 방법이 있다고 한다. 조금 신경써서 문서를 작성하면 워드에서도 모든 절 표제의 모양을 한 번의 명령으로 일괄 변경하는 것이 가능하다. 그런데 워드를 이런 식으로 일관되게 사용하는 사람은 극소수이다. 조금도 놀라운 일이 아닌 것이, WYSIWYG 접근방법 자체가 구조에 관심을 가지도록 유도하지 않기 때문이다. 저수준 형태설정 명령으로 마치 구조를 부여한 것처럼 흉내내는 것이 쉽기 때문에, 너무나 쉽기 때문에 구조 자체에 관심을 가질 필요를 별로 느끼지 못하게 된다. 이와 달리, 문서를 텍스트 에디터로 작성하는 경우라면 구조를 지시하여야 할 필요성이 즉시 명확해진다.
자, 이제 텍스트 에디터에 대해 설명할 차례다. 요즘 텍스트 에디터는 워드 프로세서와 상당히 비슷하게 생겼다. 풀-다운 메뉴 장치, 파일 열기/닫기, 찾기/바꾸기 등의 기능을 가진 누름 버튼, 철자법 검사기 등을 에디터도 갖추고 있다. 그래도 뭔가 다른 점이 있는데, 그것은 조판 기능이다. 즉, 화면 상에 텍스트를 잘 정렬해서 입력해도 출력이 그것과 동일한 모양이 되는 것은 아니다.
문서를 저장하면 플레인 텍스트 형식으로 저장된다. 플레인 텍스트란 미국에서 흔히 “아스키” (ASCII: The American Standard Code for Information Interchange) 를 의미한다. 아스키 코드는 128 문자로 이루어지며(즉 “7비트” 문자 세트. 2의 7승은 128이다.), 숫자 0에서 9까지, 그리고 대소문자 로마자 알파벳, 표준 문장부호, 그리고 특수 문자를 포함한다. 아스키는 디지털 형식의 텍스트 교환에 있어서 최소의 공통분모이다. 아스키 메시지는 지구상의 어떤 컴퓨터에서도 “이해할 수 있다”. 아스키 문자로만 메시지를 보낸다면 수신자가 그것을 읽게 되리라는 것을 확신해도 좋다.
반면, 워드 프로세서 파일을 저장해서 보낸다면, 이 파일에는 아스키 문자로는 표현할 수 없는 여러 가지 “제어” 문자가 들어가게 된다. 이 제어 문자는 주로 형태 지정(예를 들면 굵은 글꼴 지정, 기울인 글꼴 지정 등)을 위한 것과, 워드 프로세서의 내부 동작에 관계된 것들이다. 당연히 이런 것들은 일반적으로 이해가능한 것이 아니다. 이것들이 의미를 가지려면 그 문서가 만들어진 바로 그 워드 프로세서로 열거나 적절한 변환 필터를 사용하여야 한다. 워드 프로세서 파일을 텍스트 에디터로 열어보면, 텍스트 일부 또는 텍스트 조각과 함께 이해할 수 없는 수많은 “웃기는 문자들”을 보게 된다. 이것은 이진 코드 형식이다.
텍스트 에디터는 이진 코드를 전혀 집어넣지 않기 때문에, 이탤릭체임을 알리려면 어떤 식으로든 표시(mark-up)를 해야 한다. 즉, 오로지 아스키만을 사용하여 조판사에게 특정 부분을 이탤릭 처리하라는 지시사항을 기록해주어야 한다. 나중에 말하게 될 LATEX 조판 프로그램에게는 \textit{이탤릭체로 표시될 부분} 이라고 기록해서 넘겨준다. 실은 LATEX과 함께 동작하도록 설계된 에디터를 사용하고 있다면 이것을 직접 기록할 필요가 없을 수도 있다. 문장을 써넣고 이 부분을 선택하여 메뉴에서 찾거나 아이콘을 누르면 적당한 지시사항이 삽입된다. LATEX을 위한 아스키 문서를 작성하는 메카니즘은 워드 프로세서를 사용하는 것과 그다지 크게 다르지 않다.
이 접근방법, 즉 문서를 텍스트 에디터를 써서 플레인 텍스트로 작성하고, 그것을 조판하는 것은 별도의 프로그램에게 맡기는 방식은 몇 가지 “부수적인” 이점을 가진다.
(샘 스타인골드의 No Proprietary Binary Data Formats 를 읽어보라.)
이제 필자가 주장하는 글쓰기 전략의 조판기 부분에 대하여 좀더 상세히 말할 때가 왔다. 기술적인 세부사항으로 들어갈 생각은 없지만 내가 하고자 하는 말이 무엇인지에 대해서 잘 알 수 있도록 충분히 얘기할 생각이다.
내가 염두에 두고 있는 기본 조판 프로그램은 TEX이라 불리는 것이다. 이것은 스탠포드 대학의 다널드 크누쓰 (명예)교수가 만든 것이다. TEX은 자유롭게 이용할 수 있고(인터넷 사이트에서 내려받을 수 있다), 거의 모든 컴퓨터 플랫폼에서 사용가능하다. 필요하다면 적절한 가격으로 완전한 TEX 파일이 포함된 CD-ROM을 구입할 수도 있다. 크누쓰는 1977년부터 TEX을 만들기 시작하였는데, 1990년에는 이 프로그램을 더이상 개발하지 않겠다고 선언했다. 흥미가 없어져서가 아니라, 이 때쯤 되어 이 프로그램이 완전해졌기 때문이다. 버그 없는 컴퓨터 프로그램으로서, 단순한 텍스트에서 복잡한 수학식에 이르기까지 어떤 것이라도 훌륭하게 조판할 수 있게 되었다.
앞서 LATEX에 대해서 언급한 바가 있다. TEX이 조판 기본 엔진이라면, LATEX은 레슬리에 램포트가 1980년대에 처음 개발하기 시작하여, 현재는 국제 전문가 그룹에 의하여 유지되고 있는 매크로 집합이다. LATEX은 지속적으로 개발이 진행되고 있고, 새로운 기능과 패키지들이 TEX 조판기를 기반으로 추가 구축되어가고 있다. 다양한 TEX “부가 기능”도 개발이 진행되어 아스키 입력 파일로부터 PDF(어도비 사의 Portable Document Format)를 직접 산출하는 시스템도 나와 있다. 여기서 “개발이 진행중”이라 한 것은 지속적으로 기능이 갱신되어 간다는 뜻일 뿐이다. 이 프로그램들은 이미 충분히 안정적이고 기능도 다 갖추어져 있다.
앞서 말한 것처럼, 문서를 작성하면서 문서의 구조와 조판 형태를 일련의 지시명령 형식으로 LATEX에게 지시해준다. 이러한 지시명령의 상세한 부분에 대해서는 많은 책과 온라인 문서가 나와 있으므로 여기서는 이 문제를 더 다루지 않겠다. 일반적인 지시명령은 간단하고 기억하기 쉬우며, LATEX-친화적인 에디터에서는 도움말까지 제공한다.
LATEX의 매력적인 측면 하나는, 문서의 외형을 몇 개의 명령으로 완전히 다른 모습으로 일관성있게 바꿀 수 있다는 점이다. 문서 전체의 외관은
에 의하여 결정된다.
예를 들자면, 본문, 절 표제, 각주 등에 사용된 글꼴 종류나 크기를 완전히 바꾸는 것이, 원본 아스키 입력 파일의 “프리앰블”에서 한두 개의 파라미터를 수정하는 것으로 가능하다. 마찬가지로, 문서 전체의 모양을 2단 편집으로 만들거나 landscape로 회전시키는 것도 간단히 된다. 이런 비슷한 일을 워드 프로세서라고 못할 것은 없을 것이다. 그러나 일반적으로 그리 쉽지는 않을 것이며, 어떤 식으로든 의도하지 않은 포맷 상의 불일치를 피하기 어려울 것이다.
LATEX으로 조판하는 것은 사용자가 원하는 대로 얼마든지 복잡하게 할 수 있다. “간단 작성” 방법을 선택한다면, 문서 클래스만을 지시하고 다른 모든 설정을 기본값 매크로에게 처리하도록 하는 것이다. 이렇게 해도 결과물은 상당히 훌륭하여, 일반 워드 프로세서에서 얻은 것보다 훨씬 높은 품위의 조판 결과를 얻을 수 있다. 당연히 장절 표제, 각주 등에 번호가 자동으로 붙으며, 상호 참조도 구현된다. 아니면, “사용자 설정” 접근 방법을 채택할 수도 있다. 이 때는 여러 가지 패키지나 스스로 작성한 스타일을 얹어서 타이포그라피의 다양한 측면을 제어한다. 이 방식으로 문서를 작성하게 되면 정말로 아름답고 자신만이 표현할 수 있는 결과물을 얻을 수 있다.
이 모든 일이 어떻게 진행되는지 간단히 살펴보자. TEX이 잘 설치되어 있다고 할 때, 먼저 TEX-친화적인 에디터에서 글을 써넣는다. 필요한 지시 명령을 직접 써넣거나 에디터의 메뉴나 단추로부터 선택하여 삽입한다. 자신이 작성하고 있는 문서의 조판된 결과물을 한번 보고 싶어지면, 메뉴를 선택하거나 버튼을 클릭하여 조판기를 호출한다. 미리보기를 위한 메뉴 아이템이나 단추가 있을 것이다. 이것을 누르면 최종적으로 인쇄되었을 때 어떤 모양이 되는지를 시각적으로 볼 수 있다. 이것이야말로 진정한 “WYSIWYG”이다. 미리보기 프로그램은 실제로 인쇄될 세부적인 것까지 모두 보여준다. 확대하여 일부만을 볼 수도 있고, 축소하여 전체 페이지의 모양을 살펴볼 수도 있다. 이 결과를 인쇄기로 보내여 인쇄하도록 하는 메뉴나 단추가 마련되어 있을 것이다. 혹은 다시 편집 상태로 되돌아온다.
작업 진행 과정에서 수정된 결과를 보고 싶을 때도 있다. 조판기 호출 버튼을 다시 클릭한다. 이 경우에는 미리보기 프로그램을 다시 부를 필요가 없다. 열려 있는 미리보기 프로그램은 업데이트된 조판결과를 다시 불러들여서 수정된 결과를 보여준다. 편집이 끝나면 디스크 공간을 절약하기 위해 조판 결과물 파일을 지워도 상관없다. 저장해야 할 것은 아스키 원본 파일뿐이다. 조판 결과물 파일은 필요할 때 다시 생성하면 된다.
앞 절에서 주로 고려한 것은 인쇄 측면에서 훌륭한 조판 결과를 얻는 데 초점을 맞추었다. 전자우편이나 웹페이지 등을 통하여 전자적으로 배포할 문서를 작성할 때는 고려해야 할 점이 조금 다르다.
먼저 전자우편의 경우를 생각하자. 짧고 즉흥적인 메시지를 보내려 할 때는 대개 전자우편 작성 프로그램에 직접 써넣는다. 프로그램은 “전통적인” 텍스트 기반 클라이언트 프로그램인 Pine이거나 Netscape, Eudora 같은 GUI(Graphical User Interface) 프로그램을 사용한다. 이럴 경우 메시지는 아스키 형식이거나, HTML(아스키 코드로 이루어지는 웹 언어, HyperText Mark-up Language)이다. 그러나, 별도로 사전에 쓰여진 긴 텍스트를 보내고 싶을 때는 어떻게 하는가?
이 목적을 위하여 워드 프로세서로 작성된 문서를 “첨부(attach)”하는 경우가 일반적이다. 이 글에서 제시한 대안적 접근방법에서는 이 문제를 어떻게 해결하는가?
우리는 두 가지 상황을 구별하려 한다. 하나는 작성하는 텍스트가 상대적으로 짧고 복잡하지 않은, 메모, 편지, 회의 의사록, 의제 목록, 방문 계획서 등인 경우이고, 다른 하나는 좀더 복잡한, 상당한 양의 수식이 포함된 학술 논문, 그림을 곁들인 보고서, 단행본 원고 등인 경우이다. “아스키 원본 + 조판기” 접근은 이 두 가지 경우에 다른 방법을 제시하게 된다.
단순한 문서의 경우라면, 과연 정말로 조판이, 즉 글꼴 정보라든가 여백 처리 등이 꼭 필요한 것인지 물어보아야 한다. 그냥 아스키 텍스트로 보내거나 아스키 텍스트에 최소한의 수식을 하는 정도가 의사소통의 효율성과 경제성 면에서 더 나은 것은 아닌지 생각해보아야 한다. 이것은 의사소통의 대역폭 때문이기도 하고(워드 프로세서 파일은 일반적으로 동일한 내용을 지닌 아스키 파일에 비하여 훨씬 크기가 크다는 사실을 기억하자), 상대방이 Snazz 9.0 프로그램이 없는 관계로 소통이 불가능해질 가능성이 있기 때문이기도 하다. 그냥 편집기에서 작성된 아스키 파일을 워드 프로세서 파일을 첨부하는 것처럼 첨부해서 보내거나, 전자우편 본문에 그 내용을 붙여넣기해서 보내는 정도가 좋다. TEX 원본 파일도 본질적으로 아스키 파일일 따름으로, 단순한 문서라면 복잡한 조판지시 명령을 포함하고 있지 않을 것이며, 내용을 한눈에 알아볼 수 있을 것이므로 같은 방식으로 처리하면 될 것이다.
더 길고 복잡한 문서는 조판된 형태가 더 이해하기 쉬울 수 있다. 수학식은 아스키 형태로 전달하기 어렵고, 복잡한 다이어그램이나 그림도 당연히 아스키로는 처리할 수 없다. 이럴 때 TEX은 어떻게 사용될 수 있는가? 워드 프로세서 파일은, 상대방이 Snazz 9.0을 가지고 있지 않을 수도 있기 때문에 문제가 된다고 했다. 그런데 이 문제는 마찬가지가 아닌가? TEX을 통달하여 그것을 이용해보기로 했다 해도, 과연 수신자 중에 얼마나 많은 사람들이 TEX을 설치하여 사용하고 있을 것인가? 이것은 그럴 법한 질문이다. 그러나 해답이 있다. 상대방에게 자신이 작성한 문서의 출력 형태를 보여주고자 하고, 상대방이 TEX을 설치 사용하고 있지 않은 경우, 다음 세 가지 가운데 하나를 선택하면 된다.
전자우편으로 텍스트를 주고받는 상황을 설명하면서, 웹 페이지용 문서를 작성하는 문제에 대해서도 이미 논의하였다. HTML 코드를 직접 입력하여 작성해도 된다. 아니면 Netscape Communicator나 나모와 같은 적당한 GUI 에디터를 이용하여 HTML 문서를 작성할 수도 있다. 마이크로소프트 워드를 이용해서 HTML을 만들 수도 물론 있을 것이다(그런데 워드가 만들어내는 HTML 파일은 다른 응용 프로그램으로는 도저히 편집 불가능한 수많은 tag 들로 가득찬 끔찍한 것이기는 하지만). TEX을 이용한다면 자신의 문서를 깔끔하고 호환성 높은 HTML 문서로 손쉽게 변환할 수 있다.
지금까지 워드 프로세서에 비하여 “아스키 원본 + TEX 조판기” 방식의 우수성을 열심히 강조했다. 그렇지만, WYSIWYG 워드 프로세서가 실제 더 나은 도구라고 생각되는 경우도 몇 가지 있음을 인정한다. 즉, 텍스트 본문 내용에 다양한 장식을 해야 되는 짧고 즉흥적인 문서, 찌라시, 포스터, 파티 초대장 같은 경우가 그러할 것이다. 이런 것을 TEX으로 못 만들 것이야 없겠지만, 효율적인 방법은 못 된다. 표준 LATEX 문서 클래스는 이 경우 쓸모가 없다. LATEX이 공식적 문서에 사용되는 글꼴들을 아주 잘 처리하지만, 이런 일회성 문서에서 장식 글꼴을 “섞고 합치고” 하는 일에는 그다지 능숙하지 못하다. 이 경우는 문서의 논리적 구조와는 하등 상관없고, “원시 포맷”으로 처리되어야 하는 것이다. 예컨대 특정 위치에 특정 라인을 36포인트로 삽입하고자 하는데, 페이지 마지막 줄이 다음 페이지로 넘어가는지 어떤지 궁금하다면, WYSIWYG이 좋은 선택이다.
내가 이 문제에 있어 약간 흥분하고 있다는 사실을 눈치챘는가? 사실 그렇다. 이것은 문서 작성에 있어서 어떤 방법이 더 나은가 하는 학술적인 토론이 아니다. 이것은 막강한 힘과 부를 가진 거대 소프트웨어 제조사와의 힘의 균형 문제이다. 대놓고 말하자면, 우리는 MS Word가 전세계적으로 컴퓨터를 이용한 문서작성에 있어 사실상 표준으로 간주되는 상황을 목도하고 있다. 그러나 워드는 표준이거나 표준이 되어야 할 만한 이유가 별로 없는 그런 종류의 표준이다.
이것은 QWERTY 이야기와 비슷하다. 타자기의 자판, 나아가 컴퓨터 자판의 제일 윗 줄에 키들이 왜 QWERTYUIOP 순으로 배열되어 있는지 들어본 적이 있는가? 원래 타자기는 이런 순서가 아니었다고 한다. 이러한 키 배열은 순전히 타자수들의 타자 속도를 떨어뜨리기 위해 고안된 것이다. 초창기 기계식 타자기가 개발되었을 때 숙련된 타자수들의 타자 속도는 타자기 자체의 성능을 뛰어넘는 것이었다. 그 결과 리본을 친 키가 제자리로 돌아오기 전에 타자수들은 다음 글자를 이미 치고 있었으므로 키가 엉키기 일쑤였던 것이다. QWERTY 방식으로 키를 배열한 이후로는 아무도 그처럼 빨리 타자를 칠 수 없게 되었다. 이렇게 해서 만들어진 QWERTY 키배열을 컴퓨터에도 그대로 적용하는 것은 정신나간 짓이다. 그러나 바꾸기에는 너무 늦어 있었다. QWERTY는 표준이었고, 이 키배열을 합리적으로 바꾸려는 어떤 시도도 이 엄연한 사실 앞에서 좌절할 수밖에 없었다.
내가 주장하는 것도 마찬가지다. MS Word가 문서 작성의 표준이 되어야 할 어떤 권리도 없다. 왜냐하면 이미 이용할 수 있는 다른 방법과 비교해 볼 때 (대부분의 경우) 비효율적임이 명백하기 때문이다. 이번만은 너무 늦지 않은 것이기를 바란다. 아직은 Word에 대해 NO라고 말할 기회가 남아 있는 것이다. 실제 Word의 경우는 QWERTY의 경우보다 훨씬 나쁘다. 실제 표준도 아니면서 문제를 악화시키는 주범이기 때문이다. 문서를 이진 형식으로 표현하는 마이크로소프트의 이른바 “표준”은, 마이크로소프트사의 변덕에 좌우되는 것이다. 워드의 준독점적 지위는 마이크로소프트 윈도우즈의 준독점적 지위(이 문제를 더 깊이 취급하지는 않겠다)에 기대고 있다. 그들은 상업적 경쟁 상대의 압박을 받아본 적이 없기 때문에 문서의 이진 표현 형태에 대한 장기적인 어떤 표준을 마련하려는 특별한 관심을 가질 필요도 없다. 오히려 그들의 관심은 사용자가 워드를 주기적으로 새로운 버전으로 “업그레이드”하도록 유인하는 데 있다. Word N.0 은 동료가 보내준 문서를 읽지 못한다. N+1 버전으로 업그레이드해야겠지? N.0 버전에 없던 기능이 N+1 버전에도 없고, 새로운 기능이래야 하등 쓸모없는 것이라 하더라도 말이지.3
여기까지 읽어온 독자라면, 좋은 에디터, TEX 조판기 등에 대해 좀더 알고 싶은 흥미가 생겼을 것이다.
TEX에 대해 알아보려 할 때 가장 좋은 출발점은 TUG HOMEPAGE일 것이다.4 TUG이란 TEX 사용자 그룹이라는 뜻이다. 이곳에 가면 필요한 모든 링크가 다 있다. 그 중 중요한 것은 Comprehensive TeX Archive Network(CTAN) 사이트인데, 이곳에서 각각의 플랫폼에 적합한 TEX시스템과 파일들을 내려받을 수 있다. TEX 시스템은 조판기 자체와 엄청난 양의 매크로, 화면보기 프로그램, 그리고 인쇄용 파일을 만들어내기 위한 유틸리티들로 이루어져 있다.
TEX시스템 패키지는(적어도 무료 배포판의 경우) 꼭 필요한 텍스트 편집기 그 자체는 포함하고 있지 않은 경우가 많다. 이미 쓰던 손에 익은 편집기가 있으면 좋고, 그렇지 않더라도 선택 폭은 넓다. 내가 TEX 작업을 할 때 개인적으로 즐겨 쓰는 것은 Emacs에 AUCTeX을 얹은 것이다. AUCTeX은 Emacs을 TEX-친화적 환경으로 만들어준다. TEX 구문 하일라이팅을 통해서 마크-업 오류를 한눈에 찾아낼 수 있게 해주고, TEX관련 명령을 편리한 메뉴를 통하여 제공한다.
참고로 내가 Emacs에서 TEX을 편집하고 있는 스크린 샷을 구경하라.
이 글은 Allin Cottrell 씨의 Word Processor: Stupid and Inefficient5 를 우리말로 옮긴 것이다. 이 번역본의 PDF 버전을 열람할 수 있다. PDF 버전의 소스도 참고하라. HTML로의 변환은 texmf-KTUG의 tex4ht를 이용하였다.
