개요[편집 / 원본 편집]
유니코드(Unicode)는 전 세계에서 사용되는 문자, 기호, 이모지 등을 컴퓨터에서 일관되게 표현하고 다루기 위해 만든 국제 문자 인코딩 표준이다. 쉽게 말하면, 전 세계 모든 언어의 글자 하나하나에 고유한 번호(코드)를 붙여서, 어떤 컴퓨터·운영체제·프로그램에서도 같은 문자를 같은 방식으로 주고받을 수 있게 만든 규칙이라고 보면 된다.
과거에는 나라마다, 심지어 회사마다 자기들만의 문자 인코딩 방식(EUC-KR, Shift-JIS, ASCII 등)을 따로 썼기 때문에, 서로 다른 인코딩으로 만든 문서를 열면 글자가 깨지는 일이 흔했다. 이런 문자 깨짐(모지바케, 몬스터 텍스트) 문제를 근본적으로 해결하기 위해 등장한 것이 유니코드다.
유니코드는 유니코드 컨소시엄(Unicode Consortium)이라는 비영리 단체가 관리하며, 애플·구글·마이크로소프트·IBM 등 주요 IT 기업들이 회원사로 참여하고 있다.
역사[편집 / 원본 편집]
- 1987년: 제록스와 애플의 엔지니어들이 각 나라의 문자 인코딩을 통합하자는 아이디어를 처음 논의하기 시작했다.
- 1991년 10월: 유니코드 1.0.0 버전이 정식으로 발표되었다. 당시에는 모든 문자를 2바이트(16비트, 최대 65,536자)로 표현하면 충분할 것이라고 생각했다.
- 1992년 6월: 1.0.1 버전에서 CJK 통합 한자(CJK Unified Ideographs), 즉 한자 영역이 처음 정의되었다.
- 1993년 6월: 1.1 버전에서 기존에 들어가 있던 한글 2,350자에 4,306자가 추가로 할당되었다.
- 1996년 7월: 2.0 버전이 발표되면서 이른바 한글 대이동 사건이 벌어졌다. 한국 측의 요청으로 기존 한글 배치를 전부 삭제하고, 현대 한글로 조합 가능한 11,172자 전체를 U+AC00~U+D7A3 영역에 새로 배치했다. 이 사건 이후로 "한번 할당된 문자의 코드는 다시는 옮기지 않는다"는 원칙이 확립되었다.
- 그 후로도 3.0(1999), 4.0(2003), 5.0(2006), 6.0(2010, 이모지 최초 지원), 8.0(2015), 10.0(2017), 13.0(2020) 등 문자 집합을 계속 확장해 왔다.
- 2025년 9월: 유니코드 17.0이 발표되었다. 이 시점 기준 최신 정식 버전이다.
- 2026년 9월 16일(예정): 유니코드 18.0 출시가 유니코드 기술위원회(UTC) 제188차 회의에서 공식 승인되었다. 특이하게도 그동안 화요일에 맞춰 오던 정기 릴리스 관행을 깨고 처음으로 수요일에 출시되는데, 릴리스 관리팀은 "월요일이 공휴일과 겹치는 경우가 많아 화요일 배포가 번거롭다"는 이유를 들었다. 원래 인도 북동부 쿠르말리어 표기에 쓰이는 치소이 문자(Chisoi script)도 포함될 예정이었으나 막판에 이번 릴리스에서 제외되었다.
왜 만들어졌는가[편집 / 원본 편집]
유니코드 이전에는 다음과 같은 지역별 인코딩이 난립했다.
문제는 같은 코드 번호라도 인코딩에 따라 전혀 다른 문자를 가리킨다는 점이었다. 예를 들어 한국어 EUC-KR로 작성된 문서를 일본어 Shift-JIS로 읽으면 글자가 전혀 다른 문자로 뒤바뀌어 버렸다. 인터넷이 전 세계로 퍼지면서 이 문제는 더 이상 무시할 수 없는 수준이 되었고, "전 세계 모든 문자에 겹치지 않는 고유 번호를 하나씩 부여하자"는 발상에서 유니코드가 탄생했다.
구조[편집 / 원본 편집]
코드 포인트[편집 / 원본 편집]
유니코드에서 문자 하나하나에 부여된 고유 번호를 코드 포인트(code point)라고 부른다. 표기할 때는 'U+' 뒤에 16진수를 붙여서 쓴다. 예를 들어 알파벳 대문자 A는 U+0041, 한글 '가'는 U+AC00이다.
현재 유니코드는 U+0000부터 U+10FFFF까지, 총 1,114,112개의 코드 포인트 공간을 가지고 있다. 이 중 실제로 문자가 할당된 것은 일부이고 나머지는 앞으로 새 문자를 위해 비워둔 공간이거나, 사용자가 자유롭게 쓸 수 있는 사용자 정의 영역(Private Use Area)이다.
평면(Plane)[편집 / 원본 편집]
유니코드 공간은 편의상 65,536개(0x10000)씩 묶어 총 17개의 평면(plane)으로 나눈다.
| 평면 번호 | 범위 | 이름 | 설명 |
|---|---|---|---|
| 0 | U+0000~U+FFFF | 기본 다국어 평면(BMP) | 한글, 한자, 라틴 문자 등 실생활에서 가장 많이 쓰는 문자 대부분이 위치 |
| 1 | U+10000~U+1FFFF | 보조 다국어 평면(SMP) | 고대 문자, 이모지, 수학 기호 다수 |
| 2 | U+20000~U+2FFFF | 보조 표의 문자 평면(SIP) | 잘 쓰이지 않는 CJK 확장 한자 |
| 3 | U+30000~U+3FFFF | 제3 표의 문자 평면(TIP) | 추가 한자 확장 영역 |
| 14 | U+E0000~U+EFFFF | 보조 특수 목적 평면(SSP) | 언어 태그 등 특수 제어용 |
| 15~16 | U+F0000~U+10FFFF | 사용자 정의 영역(PUA) | 표준에 없는 문자를 개인/조직이 임의로 정의해 쓰는 공간 |
인코딩 방식: UTF-8, UTF-16, UTF-32[편집 / 원본 편집]
유니코드는 "어떤 문자에 어떤 번호를 매길지"를 정한 표준일 뿐이고, 그 번호를 실제로 컴퓨터 메모리에 몇 바이트로 어떻게 저장할지는 별도로 정해야 한다. 이를 위한 대표적인 인코딩 방식이 세 가지 있다.
- UTF-8
- 문자에 따라 1바이트에서 4바이트까지 가변적으로 사용한다.
- 영어(ASCII) 문자는 기존 ASCII와 완전히 호환되게 1바이트로 저장되고, 한글이나 한자는 보통 3바이트가 필요하다.
- 웹 페이지, 이메일, 대부분의 프로그래밍 언어 소스코드 등 인터넷 환경에서 사실상 표준으로 자리잡았다.
- UTF-16
- 대부분의 문자를 2바이트로, 기본 다국어 평면을 벗어나는 문자(이모지 등)는 서로게이트 페어(surrogate pair)를 이용해 4바이트로 저장한다.
- 자바(Java), 자바스크립트, 윈도우 내부 문자열 처리 등에서 많이 사용된다.
- UTF-32
- 모든 문자를 예외 없이 고정 4바이트로 저장한다.
- 구조가 단순하지만 저장 공간을 많이 차지해서 실제로는 잘 쓰이지 않는다.
BOM(Byte Order Mark)[편집 / 원본 편집]
파일 맨 앞에 붙어서 이 파일이 어떤 인코딩(UTF-8/UTF-16LE/UTF-16BE)으로 저장되었는지, 그리고 바이트 순서(엔디언)가 어떤지 알려주는 표식이다. UTF-8에서는 필수는 아니지만, 특히 윈도우 메모장 등에서 자동으로 붙이는 경우가 있어 프로그램에 따라 파일 맨 앞에 이상한 문자가 나타나는 원인이 되기도 한다.
한글과 유니코드[편집 / 원본 편집]
현대 한글은 초성 19개, 중성 21개, 종성(받침 없음 포함) 28개의 조합으로 총 11,172자를 만들 수 있으며, 이 글자들은 앞서 언급한 한글 대이동 사건 이후 U+AC00부터 U+D7A3까지 순서대로 빠짐없이 배정되어 있다.
특정 한글 글자의 코드는 다음 공식으로 계산할 수 있다.
코드값 = (초성 순번 × 588) + (중성 순번 × 28) + 종성 순번 + 44032(=0xAC00)
이 외에도 유니코드에는 옛한글 자모를 표현하기 위한 한글 자모 확장-A/B 영역과, 현대 한글에 쓰이지 않는 낱자를 위한 한글 호환 자모 영역이 따로 마련되어 있어, 훈민정음 창제 당시의 옛한글까지도 이론적으로는 표현이 가능하다.
이모지와 유니코드[편집 / 원본 편집]
이모지 역시 유니코드 표준의 일부로 관리된다. 2010년 10월 발표된 유니코드 6.0에서 처음으로 이모지가 정식 지원되었으며, 이는 원래 일본 이동통신사에서 쓰이던 이모지와의 호환성을 확보하기 위한 목적이 컸다. 이후 매 버전마다 새로운 이모지가 꾸준히 추가되고 있으며, 다가올 유니코드 18.0에도 '금이 간 얼굴', '유성' 등 새로운 이모지들이 공개된 바 있다.
다만 유니코드 표준 자체는 이모지의 코드 포인트(어떤 번호를 쓸지)만 규정할 뿐, 실제로 그 이모지가 어떤 모양으로 그려질지는 애플, 구글, 삼성 등 각 플랫폼 제조사가 자체적으로 디자인한다. 그래서 같은 이모지라도 아이폰과 갤럭시에서 모양이 다르게 보이는 것이다.
유니코드 버전 변천사[편집 / 원본 편집]
| 버전 | 발표 시기 | 주요 내용 |
|---|---|---|
| 1.0 | 1991년 10월 | 최초 발표 |
| 2.0 | 1996년 7월 | 한글 대이동, 4바이트 확장 개념 도입 |
| 3.0 | 1999년 9월 | 여러 고대 문자 체계 추가 |
| 4.0 | 2003년 4월 | 표의 문자 확장 |
| 5.0 | 2006년 7월 | 다수의 소수 문자 체계 추가 |
| 6.0 | 2010년 10월 | 이모지 최초 정식 지원 |
| 8.0 | 2015년 6월 | 이모지 피부색 표현(스킨톤) 도입 |
| 10.0 | 2017년 6월 | 비트코인 기호 등 추가 |
| 13.0 | 2020년 3월 | 코로나19 관련 이모지 다수 추가 |
| 15.0 | 2022년 9월 | 신규 문자 및 이모지 추가 |
| 16.0 | 2024년 9월 | 신규 문자 및 이모지 추가 |
| 17.0 | 2025년 9월 | 현재 기준 최신 정식 버전 |
| 18.0(예정) | 2026년 9월 16일 | 최초로 수요일 릴리스, 신규 문자·이모지 추가 예정 |
장점과 한계[편집 / 원본 편집]
장점[편집 / 원본 편집]
- 전 세계 거의 모든 문자 체계를 하나의 표준으로 통일해, 서로 다른 언어 간 문서 교환이 훨씬 쉬워졌다.
- ASCII와 하위 호환되는 UTF-8 덕분에 기존 영어 기반 시스템과의 호환성 문제가 크지 않다.
- 웹 표준(HTML, XML), 대부분의 최신 운영체제와 프로그래밍 언어가 기본적으로 유니코드를 지원한다.
한계와 논란[편집 / 원본 편집]
- 한중일 통합 한자(Han unification) 문제: 한국, 중국, 일본, 대만에서 모양이 조금씩 다른 한자를 유니코드에서는 하나의 코드로 통합해버린 경우가 있어, 특정 지역의 한자 글꼴을 정확히 표현하기 어렵다는 비판이 있다.
- 유니코드 표준이 계속 확장되면서 예전에는 존재하지 않던 문자, 기호, 이모지가 새 버전마다 계속 추가되기 때문에, 오래된 시스템이나 폰트에서는 최신 문자가 깨져 보이거나 네모(▢, '두부')로 표시되는 경우가 흔하다.
- 서로게이트 페어, 결합 문자(combining character), 정규화(NFC/NFD) 등 개념이 복잡해서, 프로그래밍할 때 문자열 길이 계산이나 자르기에서 실수가 자주 발생한다.