컴퓨터의 문자 체계

컴퓨터는 컴퓨터의 숫자 표현 체계를 가지고 숫자만 이해한다.

그런데 우리가 문자를 보고 쓰고 저장할 수 있는 이유는 문자마다 숫자를 약속해 두었기 때문이다.

A - 65
B - 66
a - 97

컴퓨터가 문자를 다루기 위해서는 각 문자를 특정 숫자로 약속해두어야 한다.

ASCII, Unicode, UTF-8 같은 것들이 대표적이다.

이 약속을 문자 인코딩 ( Character Encoding ) 이라고 한다.

ASCII

American Standard Code for Information Interchange 의 약자이다.

ASCII 는 1963년에 만들어진 가장 기본적인 문자 인코딩 방식이다.

ASCII 는 7비트 ( 128개 )로 영어 알파벳, 숫자, 기본 특수문자들을 표현한다.

0-31:   제어 문자 (예: 줄바꿈, 탭 등)
32-47:  특수문자 (공백, !, ", #, $ 등)
48-57:  숫자 (0-9)
58-64:  특수문자 (:, ;, <, = 등)
65-90:  대문자 (A-Z)
91-96:  특수문자 ([, \, ], ^ 등)
97-122: 소문자 (a-z)
123-127: 특수문자 ({, |, }, ~ 등)

ASCII의 한계

ASCII 는 영어권에서만 사용 가능하다는 치명적인 한계가 있다.

한글, 러시아어, 한자, 아랍어 등은 표현할 수 없기 때문이다.

 

 

Extended ASCII

ASCII 가 7비트였다면, Extended ASCII 는 8비트 ( 256개 ) 로 확장한 버전이다.

추가로 128 개의 문자로 서유럽 언어의 특수문자들 ( ñ, ç, ü 등 )을 표현할 수 있게 되었다.

여전히 아시아 언어들은 표현이 불가능하다.

그래서 각 나라마다 자체적인 인코딩을 만들기 시작했다.

  • 한국: EUC-KR, CP949
  • 일본: Shift-JIS
  • 중국: GB2312

하지만 이 방식은 서로 다른 인코딩 간에 호환이 안되는 문제가 발생했다.

 

Unicode

예전에는 영어권 기준의 ASCII 만으로도 어느 정도 되었다.

그런데 ASCII 는 문자 수가 적어서 한글, 일본어, 중국어, 이모지 같은 걸 제대로 담기 어려웠다.

그래서 전 세계 모든 문자를 하나의 통일된 체계로 표현하자는 목적으로 Unicode 가 등장했다.

1991년부터 개발되기 시작해서, 현재는 거의 모든 언어의 문자를 포함한다.

 

 

Unicode 의 특징

  1. 전 세계 문자를 하나의 기준으로 다룸
  2. 모든 문자마다 겹치지 않는 고유 번호 ( Code Point ) 부여
  3. 언어별 인코딩 혼란을 줄여줌
  4. 문자 집합과 저장 방식이 구분됨
  5. 현재 약 150,000 개 이상의 문자를 지원
  6. 이모지, 고대 문자까지 포함

예시 :

  • 'A': U+0041
  • '가': U+AC00
  • '😀': U+1F600

중요한 점은 Unicode 자체는 문자 번호를 정하는 규칙일 뿐이다.

그 번호를 실제로 메모리나 파일에 어떻게 저장할지는 따로 정해주지 않는다.

그래서 이 번호들을 어떻게 바이트로 저장할지는 별도의 인코딩 방식이 필요하다.

 

UTF-8

8-bit Unicode Trasformation Format 의 약자이다.

UTF-8 은 Unicode 문자를 실제 바이트로 저장하는 방식 중 가장 널리 사용되는 방법이다.

 

 

UTF-8 의 특징

  • 가변 길이 인코딩 : 문자에 따라 1~4바이트 사용
    영어 알파벳, 숫자, 기본 기호 → 1 바이트
    한글, 한자 등 → 2~3 바이트
    이모지 같은 문자 → 4 바이트까지 사용 가능
  • ASCII 호환 : ASCII 문자는 그대로 1바이트로 표현
    영어 대문자, 숫자, 기본 기호들은 ASCII 와 UTF-8 에서 동일하게 처리
  • 웹 표준 : 현재 웹 페이지의 95% 이상이 UTF-8 사용
    웹 페이지, 텍스트 파일, API 응답, 데이터 교환 형식에서 매우 자주 사용

 

UTF-8 의 바이트 구조

1바이트: 0xxxxxxx (ASCII 문자들)
2바이트: 110xxxxx 10xxxxxx (대부분의 유럽 문자)
3바이트: 1110xxxx 10xxxxxx 10xxxxxx (한글, 한자, 일본어)
4바이트: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx (이모지 등)

 

예시 :

  • 'A' (U+0041): 01000001 (1바이트)
  • '가' (U+AC00): 11101010 10110000 10000000 (3바이트)

 

 

UTF-8 의 장점

  1. ASCII 와 완전 호환 : 기존 영어 텍스트 파일들이 그대로 동작
    예전 시스템이나 영어 중심 데이터와 잘 맞는다.
  2. 효율성 : 영어가 많이 쓰이는 환경에서 공간 절약
    영어권 문자는 대부분 1 바이트로 저장된다.
    그래서 코드 파일, 웹 문서, 설정 파일, 로그 파일 같이 영어와 기호가 많은 데이터에서 용량이 효율적이다.
  3. 안정성 : 바이트 스트림이 깨져도 복구 가능
    UTF-8 은 8 비트 단위 기반이라서 파일 저장, 네트워크 전송, 텍스트 처리에서 다루기 편하다.

 

UTF-16

UTF-16 은 2바이트 또는 4바이트로 문자를 표현한다.

즉, UTF-16 도 가변 길이 인코딩이다.

  • 기본 다국어 평면 ( BMP ) : 2 바이트로 표현 ( 한글, 한자 등 대부분 문자 )
  • 보조 평면 : 4 바이트로 표현 ( 일부 이모지, 고대 문자 등 )

 

Windows 가 UTF-16 을 사용하는 이유

Windows 가 Unicode 를 도입할 당시 ( 1990년 )에는 모든 문자가 2바이트면 충분할 것이라고 판단했다.

그래서 UTF-16 을 내부적으로 사용하기 시작했고, 지금도 Windows API 는 UTF-16 기반이다.

 

  1. 당시에는 16비트가 실용적인 타협점이었음
    Windows 가 유니코드 지원을 확장하던 시기
    기존 8 비트 코드페이지 방식은 언어마다 인코딩이 달라서 문자 깨짐과 호환성 문제가 있었다.
    그 시점에는 문자를 16비트 단위로 다루면 대부분 문자 처리가 쉬워진다는 판단이 실용적이었다.
  2. Windows API 가 wide char 중심으로 굳어졌음
    Win32 에는 문자열 API 가 두 종류가 있었음.
    A 버전 : 옛날 8 비트 코드페이지 기반
    W 버전 : 유니코드 기반
    W 버전이 UTF-16 문자열을 받는 방식이다.
    OS 내부와 API 인터페이스가 오래전부터 UTF-16 전제로 짰기 때문에 쉽게 바꾸기 어렵다.
  3. 대부분의 문자에 대해 2 바이트 중심 처리가 당시에는 편했음
    UTF-16 은 많은 문자를 16비트 단위 하나로 처리
    드문 문자만 surrogate pair 로 2개 단위로 사용했다.
    Unicode 문서도 대부분 텍스트에서 surrogate pair 는 드물다고 설명한다.
    그래서 당시 기준으로는 UTF-8 처럼 매 문자 길이가 자주 달라지는 방식보다 좋다고 여겼다.
  4. 하위 호환성이 너무 중요했음
    Windows 는 예전 프로그램과 호환성을 매우 중시한다.
    한 번 운영체제 핵심 문자열 표현과 API 가 UTF-16 기준으로 정착되면
    그 위에 쌓인 앱, 라이브러리, 개발 도구 전부가 영향을 받는다.

 

UTF-16 의 한계

  • ASCII 호환성 없음 : 영어 문자도 2바이트 사용
  • 복잡성 : 2바이트와 4바이트가 섞여 있어 처리가 복잡하다.

 

UTF-32

UTF-8, UTF-16 은 문자마다 바이트 수가 달라질 수 있는데, UTF-32 는 모든 문자를 무조건 4 바이트로 저장한다.

 

 

장점

  • 가장 큰 장점은 단순함
  • 문자 하나가 항상 4 바이트
  • 몇 번째 문자를 찾기 쉽다.
  • 문자 길이 계산이 직관적이고 내부 처리 개념이 단순하다.

 

단점

  • 메모리 낭비 : 영어 텍스트도 4배의 공간이 필요하다
  • 실용성 부족 : 거의 사용되지 않는다.

인코딩 방식 비교

방식 크기 ASCII 호환 사용처 특징
ASCII 1 바이트 100 % 기본 영어 영어만 가능하다
UTF-8 1~4 바이트 100 % 웹, Linux 가장 널리 사용
UTF-16 2~4 바이트 없음 Windows 한글은 2 바이트
UTF-32 4 바이트 없음 거의 사용안함 고정 크기

 

왜 이걸 알아야 할까?

  1. 파일 깨짐 문제
    문자는 그냥 저장되는 게 아니라 인코딩 방식에 따라 바이트 형태로 저장한다.
    그래서 저장할 때 사용한 인코딩과, 열 때 해석하는 인코딩이 다르면 글자가 깨져 보일 수 있다.
    예를 들어 UTF-8 로 저장한 파일을 다른 방식으로 읽으면 한글이 ��� 처럼 깨지거나 다른 문자로 보일 수 있다.
    인코딩을 알아야 왜 글자가 깨졌는지, 어떤 방식으로 저장/열어야 하는지 이해할 수 있다.
  2. 메모리 사용량
    UTF-8, UTF-16, UTF-32 는 같은 문자라도 필요한 저장 공간이 다를 수 있다.
    UTF-8 은 영어에 효율적
    UTF-16 은 2 바이트 중심
    UTF-32 는 항상 4 바이트
    그래서 다루는 언어와 데이터 양에 따라 메모리 사용량이나 파일 크기에 차이가 생긴다.
    인코딩을 이해하면 왜 어떤 방식이 더 가볍거나 무거운지 알수 있고,
    프로그램 설계할 때도 더 적절한 선택을 할 수 있다.
  3. 국제화
    프로그램이 영어만 처리하는 게 아니라 한글, 일본어, 이모지 같은 다양한 문자를 다뤄야 한다면 인코딩 개념이 필요하다.
    이걸 모르면 특정 언어는 잘 보이는데 다른 언어는 깨지거나 입력이 안되는 문제가 발생한다.
    여러 나라 문자를 안전하게 저장하고 출력하기 위해 필수적인 개념이다.
  4. 디버깅
    문자 관련 버그는 겉으로 보기엔 단순해 보여도 원인이 인코딩 문제인 경우가 많다.

    1. 파일은 정상인데 화면에만 깨짐
    2. DB 에는 저장됐는데 읽을 때 이상해짐
    3. 복사 / 붙여넣기 후 글자가 달라짐
    4. API 응답에서 한글만 깨짐

    이런 문제는 대부분 어느 단계에서 어떤 인코딩으로 처리했는지 알아야 원인을 찾을 수 있다.

유니코드와 UTF 를 이해하면 문자 깨짐 문제를 감으로 보는 게 아니라 원리를 바탕으로 정확히 추적할 수 있다.

 

 

정리

유니코드와 인코딩을 알아야 문자 깨짐을 막고, 메모리를 이해하고, 여러 언어를 올바르게 처리하며 문자 관련 버그를 정확히 해결할 수 있다.

'🖥️Computer Science' 카테고리의 다른 글

메모리 구조와 작동 원리  (0) 2025.10.21
CPU 구조  (0) 2025.10.13
최초의 컴퓨터  (0) 2025.09.29
컴퓨터의 역사  (0) 2025.09.29

티스토리툴바