확장자

특정한 파일의 내용물의 종류가 무엇인지를 파일명을 보고 확인하기 위한 목적으로 만들어진 분류 방법. 확장명이라고도 한다.

확장자의 기원은 굉장히 오래 전으로 거슬러 올라간다. DOS 시절에도 확장자는 존재하였으며, 현 시점에서도 파일 종류를 구분하는 데 제 1 기준으로 사용되고 있다.

확장자는 보통 3자리인데, 이는 FAT에서 사용하던 8.3 RULE 에 그 유래를 두고 있다. 파일명은 최대 8바이트, 확장자는 최대 3바이트까지 사용가능하다는 룰에 의거, 거의 대부분의 어플리케이션에서 3바이트 확장자를 정의하였으며, 이것이 호환성을 이유로 현재까지 이어지는 것이다. 8.3 RULE이 완화된 이후 만들어진 확장자는 4자리 이상을 갖는 경우(jpeg, html, aspx, pptx, xlsx, docx, cell, show, accdb, prproj, torrent 등)도 많다. Windows에서는 아직 3~4글자 정도의 확장자를 주로 사용하고 있지만, macOS에서는 Pages의 .pages 확장자와 Numbers의 .numbers 확장자나 Final Cut Pro X의 .fcpbundle 확장자, iMovie의 .imovielibrary나 .theater 확장자 등 이미 공식에서 단어형 확장자를 많이 사용하는 편이다. 물론 macOS쪽도 3글자 확장자(.dmg, .pkg, .smi, .app 등)는 잘만 쓰고 있지만.

윈도우 95부터는 VFAT가 도입되면서 긴 파일 이름이 지원되었다. 8.3 RULE이 완화되어, 파일명, 확장자와 구분기호인 점(.)을 포함하여 최대 255바이트까지 사용할 수 있다.

윈도우를 처음 설치하면 기본 설정으로 '알려진 파일 형식의 파일 확장명 숨기기'가 설정되어[1], 대부분 파일의 이름만 보이고 확장자는 보이지 않는다. 윈도우 탐색기의 구성 → 폴더 옵션 → 보기 탭에서 해당 옵션의 체크를 해제하면 확장자를 볼 수 있으며, 수정도 가능하다. 윈도우 8부터는 보기 → 파일 확장명에 체크하는 것으로 간편하게 확장자 표시를 할 수 있다.

파일 확장자를 가지고 낚는 악성코드가 많기 때문에[2] 확장자를 항상 표시해 놓는 것을 강력히 권장한다.

윈도우 XP까지는 확장자를 표시해놓으면 '이름 바꾸기'할 때 확장자까지 선택되기 때문에 이름만 바꾸려고 했는데 확장자까지 지워지는 사태가 자주 발생했다. 결국 윈도우 비스타부터는 확장자 표시를 해 놓아도 파일 이름만 선택되게 바뀌었다.

윈도우 API에서는 파일명을 포함한 파일의 경로가 255자로 제한되기 때문에, 이를 초과하는 경로의 파일을 다루고자 할 때 문제가 생길 수 있다. 이는 유니코드를 사용하는 현재의 윈도우 시리즈에도 적용된다. 윈도우 10에서는 설정을 바꾸면 65535자까지 제한적으로 사용 가능하게 바꿀 수 있다. 그런데 파일 탐색기는 여전히 255자까지만 지원해서 그 이상 되는 파일은 다른 파일관리 프로그램을 사용해야 한다.

BSD, 리눅스 등 유닉스 계통 OS에서는 고유의 파일시스템을 사용하며, 확장자 보다는 후술할 파일 헤더에 의존적이었다. 그러나 사용자가 파일 종류를 한 번에 파악할 수 있는 편리성 등을 이유로, 현재는 유닉스 계통에서도 확장자를 사용하고 있다. 다만 FAT처럼 파일시스템에 확장자를 기록하는 부분이 따로 있는 것은 아니고, 그냥 파일명의 마지막 점(.) 이후부분을 확장자라고 부른다.[3]

이 때문에 확장자가 좌르륵 여러개 붙는 경우도 있다. 가장 흔히 볼 수 있는 경우가 파일명.tar.gz의 형태. 이것은 tar 명령어로 파일을 묶은 뒤 gzip이라는 프로그램으로 압축한 파일이라는 의미이다. 유닉스 계열에서는 여러 개의 파일을 하나로 묶는 기능을 운영체제 차원에서 지원을 해 줬는데, 이 기능에는 원래 압축 기능이 없었다. 따라서 별도의 프로그램으로 묶은 파일을 압축하다보니 저런 형태가 된 것. 하도 이런 방식으로 많이 쓰다보니 tar 명령어에 아예 gzip 압축 기능이 들어갔고, 별도의 옵션을 안 주면 tar.gz가 기본으로 붙어 나온다.

파일명에 확장자만 존재하는 경우에는 숨김 파일로 취급되어 파일 탐색기나 ls 명령 실행시 목록에 나타나지 않는다. 이건 파일 이름이 점(.)으로 시작하면 숨김 파일로 취급되기 때문. ls -a를 사용하여 확인할 수 있다.

확장자라는 것은 본래 파일에 붙어서 파일의 속성을 표시하기 위해 존재하는데 macOS의 경우 폴더명을 확장자를 붙이는 식으로 명명하면 GUI 인터페이스 상에서 폴더를 파일처럼 보이게 해서 해당 아이콘을 클릭하면 폴더가 파일처럼 작동하는 경우가 있다. 이를테면 macOS의 응용프로그램은 app 확장자를 이용한 아이콘 달랑 하나만 보이는 것 같아 실행 파일 하나에 응용프로그램이 몽땅 다 패키징 되어있는 것 처럼 보이지만 실제로는 이게 파일이 아니라 폴더이고 패키지 내용 보기 라는 방식으로 접근하면 실제 폴더 내부를 볼 수 있다.

이 방식은 어플리케이션에서만 쓰이는게 아니라 각종 미디어 관리, 편집 프로그램의 프로젝트 폴더도 실제로는 단일 파일처럼 보이게 만드는 경우가 있고 심지어는 오피스 프로그램인 아이워크의 문서 저장이 이런 식으로 이루어지는 시절도 있었다. 오픈오피스의 성공 이후로 문서 데이터 기록은 기존의 hwp나 doc 같은 방식처럼 각 오피스가 독자적인 방식으로 아무렇게나 저장을 하는 것이 아니라 폴더 내부에 문서의 내용과 형식을 기록한 xml 파일과 첨부된 미디어 파일을 각각 따로 담아서 ZIP 방식으로 압축해 하나의 파일로 만드는 방식으로 이루어지고 있다. ooxml도 바로 이러한 방식을 따른 MS오피스의 새로운 저장방식이다. 이렇게 데이터 파일의 가독성을 높여 이를테면 한컴오피스 같은 다른 소프트웨어에서도 MS오피스의 파일을 이전보다 훨씬 높은 호환성으로 열어볼 수 있게 된 것이 이런 오픈 도큐먼트 방식의 장점이다. 심지어 오피스 프로그램이 없어도 확장자명을 ZIP으로 변경해 압축을 해제하고 내부의 xml 파일을 직접에디터로 열어 사람의 눈으로 파일 내용을 확인하는 것이 가능할 정도로 높은 가독성을 보장한다.

하지만 이 방식의 문제는 바로 데이터가 ZIP 방식으로 압축이 되어야한다는 것인데 파일을 열 때 압축을 풀어야 하고 저장할 때 다시 파일 압축을 수행하는 과정이 필수적으로 필요해진다는 것이다. 당연히 연산에 비효율적인 부분이 생기게 되고 사양이 낮은 컴퓨터에서는 열기, 저장 시간이 길어질 수도 있다. 그래서 애플이 이 문제를 다루면서 생각한 해결책이 기존에 이미 폴더를 파일처럼 만들게 하는 운영체제의 기능을 가지고 있었으니 그냥 데이터를 압축하지 않고 이 기능을 이용해 폴더를 파일처럼 보이게 만들어버린 것이었다. 2000년대에 아이워크가 처음 나왔던 시절에는 아이워크 형식의 데이터가 다른 운영체제를 사용하는 컴퓨터로 갈 일도 없었고 문서도 애플 컴퓨터끼리만 물리 저장장치를 이용해 주고 받는 것이 일반적이었기 때문에 크게 문제될 것이 없었지만 클라우드 스토리지의 이용이 일반화되면서 이 방식에서 헬게이트가 열리기 시작했다. 드롭박스나 구글 드라이브 같은 서비스들이 아이워크 형식의 폴더를 특별하게 다뤄줘야할 이유도 없었고 거기다 극히 최근까지도 웹페이지에서 파일이 아닌 폴더를 첨부파일로 올리는 것은 거의 불가능한 것이었기에 클라우드 업로드가 이상하게 되는 것 정도가 아니라 메일 첨부 자체가 안 되는 희한한 상황까지 발생하게 되었다.

그래서 맥용 기본 메일 클라이언트나 아이메시지를 사용할 때는 파일처럼 보이는 폴더 형식의 데이터를 첨부할 때는 자동으로 ZIP으로 압축을 한다던가 하는 방식의 꼼수만 찾아다니는 애플 특유의 똥고집을 부리며 사용자를 한동안 뒷목을 잡게 만들었지만 결국 ZIP 압축/해제가 사용자 경험에 의미 있는 딜레이를 발생시키지 않을 정도로 컴퓨터 성능이 올라간 시점이 한참을 지나서야 다른 오픈 도큐먼트가 하고 있는 ZIP 압축 방식으로 데이터 저장 방식을 확정하였다. 그래서 지금도 오래된 아이워크 문서는 실제로는 파일이 아니라 폴더 형식으로 되어 있을 가능성이 있다.

오피스 문서처럼 빈번하게 주고받아야 하는 데이터는 그래서 결국 파일화가 이루어졌지만 여전히 응용프로그램이나 미디어 프로젝트 같은 분야에서는 여전히 이런 폴더에 확장자 붙이기를 이용한 눈속임이 쓸모가 있기 때문에 이 시스템 자체는 아직도 사용이 되고 있다.

물론 그 용도와 이름이 널리 알려진 확장자들은 겹치는 일이 매우 드물다. 그러나 소프트웨어가 인지도가 낮거나 개발과정에서 편의상 사용하는 확장자는 우연히 겹치는 경우가 드물지 않으며, 겹치는 확장자는 전혀 호환이 안 된다. 파일명의 일부라는 근본적인 한계로 사용자가 마음대로 변경할 수 있기 때문에, 프로그램 개발자는 확장자를 100% 신뢰하면 안 된다.

예를 들면
1. FLP - Adobe Flash와 Image-Line FL Studio 두 프로그램에서 프로젝트 파일의 확장자로 쓰고 있다. 당연히 두 FLP는 전혀 호환이 되지 않는 별개의 형식이다.
2. SMI - 한국에 한정한다면 자막 포멧과 Mac OS의[4] 디스크 포맷으로 역할이 겹친다.
3. DAT - 가장 심한 것이 .dat 확장자로, 파일 구조를 뜯어보지 않는 한 어디에 쓰이는지 컴덕도 모를 정도.
4. HPT - 한쇼(구 한컴슬라이드)와 (어린이) 훈민프레젠테이션 두 프로그램에서 사용된다. 한쇼의 경우 지금은 .show로 바뀌었다.
5. MSP - 윈도우 3.1까지 그림판에서 사용하고, 최신 윈도우에서는 Windows Installer 패키지로 사용한다.

이러한 문제를 해결하기 위하여, 정형화된 데이터는 항상 "파일 헤더"와 "매직 워드"를 두어 파일을 구분한다. 확장자와 달리 매직 워드는 파일 데이터의 일부분으로 사용자가 임의로 수정하기 힘들며, 임의 길이의 고유한 매직 워드를 사용함으로써 이 파일이 올바른 데이터 파일임을 예측할 수 있다.

예를 들어, 대표적인 이미지 형식인 비트맵 포맷은 항상 파일의 첫머리에 "BM" 을 기록함으로써 자신이 비트맵임을 알린다. 설령 사용자가 (고의든 실수든) 확장자를 .jpg로 바꾸더라도, 헤더를 제대로 분석하는 이미지 뷰어라면 잽싸게 비트맵임을 눈치채고 적절히 처리할 수 있다. 심지어는 .txt와 같은 전혀 엉뚱한 확장자로 바꾸더라도, 일단 헤더가 온전하다면 대부분의 제대로 작성된 프로그램은 데이터 파싱이 가능하다.[5] 또는, 적어도 데이터가 잘못되었음을 사용자에게 알릴 수 있는 것이다. 이런 의미에서 확장자만 바꾸는 게 아니라 실제 내용도 지져버리는 랜섬웨어가 개쌍놈

다만 파일 헤더를 이용하는 경우, 어쨌든 파일을 열어서 헤더를 분석하는 과정을 거쳐야 하기 때문에 확장자보다는 처리 속도가 떨어지며, 사용자 가독성 또한 확장자와 비교할 수 없을 정도로 부족하다는 단점이 존재한다. 특히 어떤 파일인지 모를 경우 해당 프로그램이 아닌 파일 탐색기에서 바로 이용하기는 매우 난감하다.

위와는 반대로, 어떠한 이유로 같은 내용임에도 확장자를 달리 하여 저장하는 경우가 있다. 가까운 예를들면 당신의 야동이라던가 주로 특정 데이터를 압축하여 저장하는 경우가 그러한데, 일반적인 압축 처리기 대신 특정 프로그램에 바로 연결하기 위하여 이러한 방법을 사용한다. 그런 경우 확장자만 다르지 실제 파일의 내용을 규정하는 헤더는 그대로이기 때문에 억지로 불러들이거나 확장자만 바꿔서 불러오면 대부분 잘 불러와진다.

대표적으로 DOCX. 파일 자체는 여러 개의 XML 문서를 ZIP으로 압축한 구조이므로 모든 압축해제기에서 압축 해제가 가능하다. 그러나 그 여러 XML 문서들이 하나의 워드 문서를 이루기 때문에 워드로 연결하는 경우이다. 이외에도 만화책 확장자인 cbt, cbz, cbr, cb7은 모두 만화 이미지를 각각 tar, zip, rar, 7zip으로 압축하여 확장자만 변경한것이다. 파일매니저에서 그냥 더블클릭했을 때 압축 프로그램이 아닌 만화 뷰어로 연결하기 위한 꼼수인데, 한국을 제외하고 전세계적으로 널리 쓰인다. 물론 한국에서는 그냥 .zip 파일을 만화책 뷰어에 넣어가며 보지만.[6]

물론 한국에서도 쓰는 것이 있다. 마인크래프트같은 Java 관련 프로그램을 많이 이용하거나 만든다면 .jar 확장자를 많이 보는데[7], 겉으로 보기에는 압축 파일이지만 그 파일을 Java로 연결한다면 떡하니 실행이 된다.[8] 다만 진짜 압축파일인 경우에는 실행이 안 될수도 있다. 알집의 폐해...

더불어 일부에선 단순 확장자를 바꾸는 것만으로도 인코딩이 되는 줄 알고(많은 프로그램은 확장자를 바꿔도 원래 확장자를 알고 실행시키기에) 인코딩이 필요한 PMP나 스마트폰 등에 확장자만 바꿔 넣고 안 된다고 하는 경우도 있다. 더 극단적으로 말하면 사진 파일 확장자를 뭐시기.mp3로 고친다고 그게 노래 파일로 바뀌겠는가?

즉 다시 말하면 확장자와 실제 파일 포맷은 사실 따로 논다고 할 수 있는데, 때문에 아래 확장자 목록을 참고할 시 간혹 해당 확장자를 다른 프로그램에서 전혀 다른 용도로 사용할 수 있다는 사실을 염두에 두어야 한다. 메이저한 프로그램일 경우 대개는 알아서 피해가는 편이지만...

아래는 각 확장자가 가지는 특징을 알파벳 순으로 정리하였다. 여기에 없는 확장자는 이곳에서 찾길 바란다. ^§ 표시는 메모장으로 열 수 있는 일반 텍스트 파일이다.

어떤 확장자가 반드시 이 목록에 있는 것은 아니고, 필요에 따라 실질적인 형식은 같더라도 내용을 구분하기 위해 확장자를 다르게 하거나(.docx, .apk 등), 다른 곳에서 사용되는 확장자를 임의로 사용하는 경우가 있으니 참고.

주로 인터넷 커뮤니티에서 게시물을 올릴때(주로 개드립) 제목 뒤에 게시물의 속성(글,그림,동영상 등)을 설명함과 동시에 주목을 끌기 위해 확장자를 붙이게 되었다.

예시)

공백 대신 언더바를 쓰는 경우도 있다. 그러니까_이런_식으로.TXT
스페이스 대신 언더바를 쓰는 이유는 아주 오래 전 컴퓨터를 GUI없이 터미널로 대부분의 조작을 할 시절 때 정착된 것이다. 터미널의 한계상 파일 이름 같은 문자열을 "에반게리온 15화.avi" 이라고 쓰면 터미널이 인식을 못하고[51], "에반게리온\ 15화.avi" 처럼 그냥 공백 대신 "\ "[52] 을 써야했는데,[53] 매번 이걸쓰는게 귀찮아서 사람들이 "에반게리온_15화.avi"로 쓰기 시작했고, 이게 습관처럼 남아 있는 것. 대부분의 사람들이 GUI를 쓰는 요즘에야 별로 의미 없는 일이지만 아직도 터미널로 조작할 일이 있는 컴퓨터 계열 종사자 및 컴덕들에게는 언더바를 쓰는게 편하다. 특히나 확장자를 따로 요구하지 않는 유닉스 터미널에서는 abc def 라는 파일을 ls 로 볼때 abc 와 def 라는 파일이 각각 하나씩 있는건지, 아니면 abc def 라는 하나의 파일이 있는건지 구분이 힘든 측면이 있다.어차피 tab completion 으로 파일명을 끝까지 쓰는일은 거의 없지만

최근 들어서는 컴퓨터 쪽에서 사용되지 않는 새로운 확장자를 개드립을 치기 위해 만들고는 한다. 예를들면 xx가_xx한_이유.eu 이런 식으로. 특히 각종 커뮤니티 등지에서 퍼오는 기사글의 제목을 기사 제목.gisa 식으로 작성하는 용법도 흔한 편. 정보 게시물의 경우에는 xxx에_대해_알아보자.araboja같은 식으로 쓰이기도 한다. .ssul도 많이 쓰인다.

팀 포트리스 2 관련 커뮤니티에서 Smexual이라는 유형의 영상물에서도 많이 쓰이는 유형이다. 유튜브에서 Smexual 검색 시 나오는 재생 목록도 참고.