zip 포맷과 표준. 그리고 알집 이야기

압축 파일 형식 중 가장 광범위하게 전 세계적으로 사용하는 zip포맷과 표준, 그리고 그와 관련 된 알집 이야기를 전해 드립니다.

zip 포맷과 표준

zip 포맷은 일반적으로 Deflate 압축 알고리즘을 통해서 압축됩니다. Deflate 알고리즘은 RFC-1951로 관리되고 있는 국제 표준입니다. 반면 zip 압축포맷은 특별한 표준은 존재하지 않으며 원작자인 PKWare에 의한 De facto 표준만 존재합니다.

컴퓨터 산업에서의 표준이란?

Global 표준	De facto 표준
공익과 표준화를 위해 설립된 단체가 개발,수정 등으로 관리하는 표준. 적법한 절차를 통해 이의 제기 및 수정 요청 가능한 것이 특징. * ISO(국제 표준화 기구) - ISO * IETF(국제 인터넷 표준화 기구) - RFC	시장에서 많이 사용하여 표준으로 여겨 지게 된 경우로서 업체의 이익이 반영됨. 표준의 공개 및 변경에 대한 권리 및 의무가 모호하여 변경사항에 대한 견제 및 이의제기가 어려운 것이 특징.

포맷과 압축 알고리즘

실제 데이터의 압축을 수행하는 것은 압축 알고리즘이며, 압축포맷과 압축 알고리즘은 별개의 기능을 수행합니다. 압축 알고리즘이란 순수하게 데이터의 양을 줄이기 위한 기능만을 담당하는 반면 압축 포맷은 이렇게 생성된 압축 데이터를 파일에 담기 위한 방법을 제시합니다. 압축 포맷 안에는 데이터 해제 후 원본 파일로 복원하기 위한 원본파일의 속성 정보와 파일설명과 같은 부가기능을 제공하기 위한 정보들이 포함됩니다. 일반적인 압축 포맷들은 다수의 압축 알고리즘을 선택하여 사용할 수 있습니다.

PKWare와 Winzip의 서로 다른 zip표준, 호환성의 위기

PKWare는 Appnote라는 형태로 표준을 관리해 오고 있는데, 2003년 PKWare는 Appnote에 공개하지 않은 채 자사 제품에 강력한 암호화 기능을 추가했고, 이를 비난하던 Winzip은 자신만의 암호화 방법을 적용하게 되었습니다. 이로 인해 zip 포맷은 심각한 호환성 위기를 맞이하게 됩니다. 다행히 2004년 상호간의 방식을 서로 존중하고 지원하는데 합의하게 됐습니다. 다만, 이 사건은 현재까지도 영향을 미쳐 zip 표준의 강력한 암호화 지원 방식이 두 가지라는 오점을 남기게 되었습니다.

 

만약 PKWare와 Winzip 중 한 회사가 상대를 견제할 힘이 없었다면 어느 한쪽의 압도적인 승리로 끝났을 것입니다. Zip 포맷에 De facto 표준만이 존재하기 때문입니다. 그렇다면 이들이 합의를 할 수 밖에 없었던 이유는 무엇일까요? 두 회사는 “사용자들의 불편과 혼란은 곧 zip 포맷의 몰락이며 결국 자신들의 손실이다.”라는 사실을 누구보다 잘 알고 있었기 때문입니다.

 

새로운 방법과 표준을 만들어 추가하는 것은 어렵지 않습니다. 만약 시장에서 절대적인 지위를 가지고 있으며, 사용자 수를 확보하고 있다면 이는 결국 표준이 될 수 밖에 없습니다. 하지만 이 때 발생할 사용자들의 혼란과 불편을 피해가기는 쉽지 않습니다.

zip포맷에 대한 알집의 대처

zip 포맷 자체는 지속적으로 확장되어 가고 있습니다. 하지만 최초 설계 당시의 구조적인 문제로 인하여 zip 포맷의 확장은 하위 호환성에 많은 문제점들을 보입니다. 알집은 이런 zip 포맷 확장에 대하여 “하위호환성을 최대한 고려하여 De facto 표준을 수용한다.” 라는 철학을 가지고 있습니다. 해외 유수의 프로그램들이 새로운 포맷 형식을 지원한다고 하여 무작정 따라서 기능을 지원하게 되면 하게 되면 최신 알집에서 생성된 파일이 구 버전에서 동작을 못하게 되는 일이 발생하게 됩니다. 이는 사용자간에 큰 혼란을 초래할 수 있기 때문에 새로운 포맷 형식을 지원하는 것은 하위호환성을 고려하여 시간을 두고 서서히 진행을 해야 합니다.

 

또한 zip 포맷은 세계적으로 가장 널리 쓰이는 포맷이기 때문에 무엇보다 호환성이 중요하며, 이 호환성은 단순히 단일 제품이 가진 하위호환성의 개념을 넘어 업계 전반에 걸쳐 널리 공유되고 있는 추세를 반영해야 합니다. 한 제품이 만들어 낸 파일을 타 제품 사용자가 해제할 수 없다면 의미가 없습니다. 때문에 알집은 세계 어떤 압축 소프트웨어를 사용하더라도 해제 할 수 있는 호환성을 가진 zip 파일만을  생산하고, 압축 해제에 대해서도 표준에 입각하여 최대한 반영하도록 노력하고 있습니다. 그리고 호환성 이슈가 있거나 기존 포맷에서 지원하지 않는 기능 요구사항은 호환성 이슈에서 다소 자유로운 독자 포맷을 통해 해결하려고 노력하고 있습니다. 

zip 유니코드 지원

zip 포맷은 최초 고안 당시 Unicode에 대한 고려가 전혀 없었습니다. 이후 1991년 유니코드협회에 의해 Unicode 1.0이 제정된 이후로 많은 압축 소프트웨어들은 여러 가지 방법을 동원하여 Zip 포맷에 Unicode 형태의 데이터를 저장하기 위한 독자적 노력을 해 왔습니다. 하지만 그 때마다 업계의 호응을 얻지 못하고 독자적으로 자신이 만들어 낸 파일에 대해서만 Unicode 형태로 압축을 해제 하는 형태에 그쳐 왔습니다.

 

 이후 2006년 9월 PKWare는 기존 파일명 영역을 UTF-8(Unicode)형태로 저장하는 방법을 Appnote에 추가하였으나, 이는 해당 방법을 알 지 못한 채 출시된 프로그램이나 아직 지원하지 않는 프로그램들의 오동작이라는 결과를 낳았습니다. 말 그대로 하위 호환성을 뒤흔드는 방식이었기에 처음에 정착되지 못하다가 2008년 말부터 차츰 업계에서 지원하기 시작했습니다. 하지만 현재까지도 많은 호환성 이슈가 존재합니다. 알집은 8.0 beta1 버전부터 이 방식에 대한 압축해제만 지원하며, 하위호환성 이슈를 고려하여 해당 방식의 압축은  지원하지 않습니다.

zip 대용량 파일 지원

zip 포맷이 최초 개발되던 1986년 당시 기가바이트(Giga Byte)라는 단위는 상상을 초월하는 단위였으며, 당연히 Giga Byte 단위의 압축에 대해서는 고려되지 못했습니다. zip 포맷은 기본적으로 4byte로 파일의 크기와 데이터의 위치를 저장하기 때문에 이를 넘는 용량을 저장할 수 없었습니다.

 

시대가 바뀌고 대용량 데이터들이 점점 익숙해 지기 시작하자 PKWare는 2001년 zip64라는 새로운 형식을 발표합니다. 하지만 1byte의 데이터라도 절약해야 하는 압축파일의 특성과 이를 구현하는 소프트웨어들의 구현방법상의 특징으로 인하여 크기와 위치를 8byte로 저장하는 zip64 포맷은 많은 호환성 이슈들을 만들어 냅니다. 이후 2004년부터 업계에 점차 받아들여지기 시작하여 현재는 대부분의 소프트웨어들이 zip64 포맷에 대한 해제를 지원합니다. 알집도 2005년부터 zip64 포맷 해제를 지원하고 있습니다.

zip 분합압축 지원

zip의 분할압축은 2002년 이전에 PKWare에 의해 공개되었지만 당시 지원하는 소프트웨어는 거의 없었습니다. 이후 2002년 말 Winzip이 지원하기 시작했습니다. 알집 최초 출시 시점인 1999년 당시 분할 zip 파일은 표준 방법론이 없었으나 느린 네트워크 등으로 인해 사용자들의 분할 압축에 대한 요구사항이 많아 자체적으로 alz포맷을 통해 기능을 제공해 왔습니다. 물론 분할 zip파일 해제도 지원하고 있습니다.그 후 알집 8.0 을 준비하면서 개발한 egg 포맷으로 분할 압축을 지원하고 있습니다. egg 포맷은 이스트소프트 개발진들의 3년 여 간에 걸친 연구 개발의 결과이며, 효율과 안정성 면에서 더욱 향상되었다는 평가를 받고 있습니다.

요약하자면, zip 포맷에서 주로 사용되는 Deflate 압축 알고리즘은 RFC-1951로 관리되고 있는 국제 표준입니다.

반면 zip 포맷은 특별한 국제 표준없이 원작자인 PKWare가 만든 De facto 표준만 존재하는 상황입니다.

알집은 하위 호환성(상위 버전에서 압축한 zip파일이 이전 버전에서 안 풀리는 문제 등)과 유저들의 의견을 고려하여 최대한 불편함이 없는 방향으로 제품 개발과 개선을 진행해 오고 있습니다.