종이에서 디지털로
문서는 정보를 기록하고 전달하기 위한 수단이다. 수천 년 동안 문서는 종이 위에 글과 그림을 남기는 방식으로 발전해 왔다. 종이는 사람이 읽고 이해하기 위한 매체였으며, 문서도 사람을 중심으로 만들어졌다.
컴퓨터가 등장하면서 문서는 새로운 환경을 맞게 되었다. 종이에 적던 내용을 컴퓨터에서도 작성하고 저장할 수 있게 된 것이다. 그러나 컴퓨터는 종이와 전혀 다른 방식으로 정보를 처리한다. 종이는 글자를 그대로 기록하지만, 컴퓨터는 모든 정보를 전기 신호와 숫자로 처리한다.
따라서 문서를 컴퓨터에서 사용하려면 먼저 글자와 그림을 컴퓨터가 저장할 수 있는 형태로 변환해야 했다. 화면에 보이는 문서와 컴퓨터 내부에 저장되는 데이터는 서로 다른 개념이다. 사용자는 문서를 읽지만, 컴퓨터는 데이터를 처리한다.
초기의 문서 기술은 이 문제를 해결하는 것에서 출발했다. 문서를 얼마나 정확하게 저장할 것인가, 얼마나 적은 용량으로 저장할 것인가, 얼마나 빠르게 불러올 것인가가 중요한 과제였다. 당시의 컴퓨터는 저장 공간과 메모리가 매우 제한적이었기 때문에 저장 효율과 처리 속도가 무엇보다 중요했다.
이러한 환경에서 선택된 방식이 바이너리(Binary) 파일이다. 바이너리는 당시의 하드웨어 환경에서 가장 효율적으로 문서를 저장하고 처리할 수 있는 방법이었다. 오늘날에는 호환성과 확장성의 한계가 많이 알려져 있지만, 당시의 기술 환경에서는 매우 합리적인 선택이었다.
문서 기술의 출발점은 사람이 보는 문서를 만드는 것이 아니라, 컴퓨터가 문서를 저장할 수 있도록 만드는 것이었다. 문서 기술의 진화도 바로 이 지점에서 시작되었다.
바이너리의 시대
컴퓨터는 모든 정보를 0과 1로 처리한다. 문서도 예외는 아니다. 사람이 보는 글자와 그림도 컴퓨터 안에서는 모두 0과 1의 데이터로 저장된다.
하지만 문서를 어떤 형태로 저장할 것인지는 또 다른 문제였다. 컴퓨터가 0과 1만 사용한다고 해서 모든 저장 방식이 같은 것은 아니다. 데이터를 어떻게 구성하고 기록하느냐에 따라 저장 용량과 처리 속도, 프로그램의 성능이 달라졌기 때문이다.
초기의 컴퓨터는 지금과 비교할 수 없을 정도로 성능이 낮았다. 메모리는 수 KB에서 수 MB 수준이었고, 저장장치도 매우 비쌌다. 프로세서의 처리 속도 역시 제한적이었다. 이런 환경에서 문서를 저장할 때 가장 중요한 기준은 호환성이 아니라 저장 효율과 처리 속도였다.
이러한 조건에서 등장한 것이 바이너리(Binary) 파일이다. 바이너리 파일은 프로그램이 사용하는 데이터 구조를 그대로 저장하는 방식이다. 별도의 변환 과정이 거의 필요하지 않아 저장과 읽기 속도가 빠르고 파일 크기도 작았다. 당시의 하드웨어 환경에서는 가장 효율적인 저장 방식이었다.
초기의 워드프로세서도 대부분 이 바이너리 방식을 따랐다. 한글(HWP), Microsoft Word(DOC), Lotus Word Pro를 비롯한 많은 문서 프로그램이 독자적인 바이너리 파일 형식을 만들었다. 각 프로그램은 자신의 기능을 가장 효율적으로 구현할 수 있도록 파일 구조를 설계했고, 그 결과 문서 형식도 프로그램마다 달라졌다.
당시에는 이것이 큰 문제가 되지 않았다. 같은 프로그램으로 문서를 작성하고 같은 프로그램으로 열어보는 것이 일반적이었기 때문이다. 오히려 프로그램의 성능과 저장 효율을 높이는 것이 더 중요한 경쟁력이었다.
바이너리는 당시의 기술 환경에서 가장 현실적인 선택이었다. 그러나 컴퓨터가 널리 보급되고 문서를 서로 주고받는 일이 늘어나면서 새로운 문제가 나타나기 시작했다. 프로그램마다 파일 구조가 달라 다른 프로그램에서는 문서를 제대로 열 수 없었고, 새 버전이 나오면 이전 버전과의 호환성마저 문제가 되었다.
문서 기술의 중심은 저장 효율에서 호환성과 확장성으로 옮겨가기 시작했다.
왜 바이너리
지금은 바이너리 파일보다 XML이나 JSON처럼 구조를 공개한 형식이 더 익숙하다. 그래서 과거의 바이너리 파일을 폐쇄적이고 호환성이 낮은 기술로 평가하는 경우가 많다. 그러나 당시의 기술 환경을 고려하면 현재의 기준으로 과거를 판단하는 것이다.
1980년대와 1990년대의 개인용 컴퓨터는 지금과 비교할 수 없을 정도로 제한적이었다. 메모리는 매우 적었고 저장장치는 비쌌으며 프로세서는 느렸다. 조금이라도 더 빠르게 저장하고, 조금이라도 더 적은 공간을 사용하는 것이 경쟁력이었다.
이러한 환경에 바이너리 파일은 가장 적합한 방식이었다. 프로그램이 사용하는 내부 데이터 구조를 그대로 저장할 수 있었기 때문에 별도의 해석 과정이 거의 필요하지 않았다. 파일 크기도 작았고 처리 속도도 빨랐다. 기술적으로나 경제적으로 모두 합리적인 선택이었다.
또 하나 중요한 이유는 기능의 차별화였다. 워드프로세서는 단순히 글자를 입력하는 프로그램이 아니었다. 글꼴, 표, 수식, 그림, 각주, 머리말과 꼬리말 등 다양한 기능을 경쟁적으로 추가했다. 프로그램마다 신기능을 효율적으로 구현하기 위해 파일 구조를 계속 발전시켰고, 그 과정에서 독자적인 바이너리 형식을 사용하게 되었다.
문제는 문서가 컴퓨터 안에만 머물지 않았다는 점이다. 기업과 기관은 전자문서로 업무를 처리하고, 이메일로 문서를 주고받기 시작했다. 인터넷이 확산되면서 다른 프로그램이나 OS에서도 같은 문서를 열어야 하는 상황이 늘어났다.
그러나 바이너리 파일은 프로그램마다 구조가 달랐다. 파일 형식이 공개되지 않은 경우도 많았고, 같은 프로그램이라도 버전이 달라지면 문서가 제대로 열리지 않는 일이 발생했다. 문서를 공유할수록 파일 형식의 차이는 더 큰 문제가 되었다.
결국 문서 기술의 과제도 달라졌다. 초기에는 문서를 얼마나 효율적으로 저장할 것인가가 중요했다면, 이제는 어떤 환경에서도 같은 문서를 읽고 활용할 수 있는지가 더 중요한 문제가 되었다. 문서 기술은 저장 중심에서 공유와 활용 중심으로 발전하기 시작했다.
이 변화는 새로운 문서 기술을 요구했다. 사람뿐만 아니라 컴퓨터도 문서의 구조를 이해할 수 있어야 했고, 특정 프로그램에 종속되지 않는 저장 방식도 필요해졌다. 이러한 요구에 따라 문서 기술은 구조 중심으로 전환되기 시작했다.