TCHAR 에 대한 이해

이 글은 윈도우의 역사, 문자 인코딩의 변화, 그리고 TCHAR의 탄생 배경을 함께 다룹니다.
내용이 다소 길고 깊기 때문에, 모든 세부를 완벽히 이해하지 않으셔도 무방합니다.
다만 전체 흐름을 따라가면, TCHAR가 왜 생겼고 왜 지금은 과거의 유물이 되었는지 자연스럽게 이해하실 수 있을 것입니다.

 

1. 아스키 코드 시대

초기의 컴퓨터 환경에서는 아스키(ASCII) 코드만으로 충분했습니다.

아스키는 문자 하나를 **1바이트(8비트)**로 표현하며, 실제로는 다음과 같은 숫자 체계입니다.

'A' → 65
'B' → 66
'a' → 97
'0' → 48

 

즉, 문자는 개념이 아니라 숫자였고, char 하나에 이 숫자를 담아 처리했습니다.

이 구조는 영문 환경에서는 매우 단순하고 효율적이었습니다.

 

2. ANSI와 글로벌 문자 문제

윈도우는 이후 ANSI 인코딩을 채택합니다. 
ANSI 역시 1바이트 기반이지만, 문제는 같은 숫자가 지역마다 다른 문자로 해석된다는 점이었습니다.

 

예를 들어 : 0xB0 

 

 • 한국 코드 페이지 → '가'

 • 일본 코드 페이지 → 전혀 다른 문자

 • 다른 지역 → 깨진 문자

 

즉, 숫자는 같지만 해석 기준이 시스템 설정에 따라 달라지는 구조였고, 글로벌 환경에서는 문제가 되었습니다.

 

3. 유니코드란 무엇인가

이 문제를 해결하기 위해 등장한 것이 유니코드(Unicode) 입니다.

유니코드는 모든 문자를 디지털화 하기 위한 규약입니다. “전 세계의 모든 문자에 고유한 번호를 부여하자” 라는 문자 사전과 같은 개념입니다. 

예를 들면 다음과 같습니다.

'A'  → U+0041
'가' → U+AC00
'中' → U+4E2D
'😀' → U+1F600

 

여기서 중요한 점은 이 숫자는 단순한 번호일 뿐, 프로그래밍적으로 어떻게 처리할지와는 무관합니다. 

 

4. UTF-8 / UTF-16 / UTF-32의 차이

이 유니코드 숫자를 컴퓨터 메모리에 어떻게 저장할지를 정한 것이 UTF ( Unicode Transformation Format ) 방식입니다.

UTF-8 (인터넷 표준)

 • 가변 길이 (1~4바이트)

 • 영문은 1바이트

 • 한글은 3바이트 

'가' (U+AC00)
→ UTF-8: 0xEA 0xB0 0x80

UTF-16 (윈도우의 선택)

 • 기본 단위 : 2바이트

 • 대부분 문자는 2바이트

 • 일부 이모지 등은 4바이트

'가' (U+AC00)
→ UTF-16: 0xAC00 (2바이트)

 

이 때문에 문자 하나는 2 byte 라는 개념이 자연스럽게 자리 잡게 됩니다.

UTF-32

 • 모든 문자를 무조건 4바이트로 표현

 • 단순하지만 메모리 낭비 큼

 

5. 윈도우의 선택과 wchar

마이크로소프트는 UTF-16 을 유니코드 인코딩 방식으로 채택했습니다.

그 결과 기존 char (1바이트) 로는 표현하기 어려웠기 때문에 2바이트 문자를 담기 위한 타입 필요하게 되었습니다. 

그 결과 2 byte 문자를 표현할 수 있는 wchar(wchar_t) 가 등장하게 되었고,  이 시점부터 윈도우에는 char 기반 문자열 (ANSI) 과 wchar 기반 문자열 (Unicode) 이 공존하게 됩니다.

 

6. 과도기의 해결책 : 윈도우 TCHAR

개발자가 매번 "이 문자열은 char인가, wchar인가” 를 고민해야 했기 때문에 윈도우는 TCHAR를 도입합니다.

TCHAR는 컴파일 옵션에 따라 다음처럼 해석됩니다. 

 

 • 유니코드 옵션 OFF : char

 • 유니코드 옵션 ON : wchar

 

즉, TCHAR는 ANSI 에서 Unicode 전환기의 호환 장치였습니다.

다만, wchar 에 대한 플랫폼간 호환은 문제가 있습니다. 

 

 • 윈도우는 UTF-16 이기 때문에 wchar 는 2 byte

 • macOS는 UTF-32 이기 때문에 wchar 는 4바이트

 

즉, wchar 의 크기는 플랫폼마다 다릅니다.

 

8. C# 은 이 문제를 어떻게 해결했나

C# 은 이런 혼란기를 지나 탄생한 언어입니다.

그래서 언어 차원에서 다음을 결정했습니다. 

 • char 는 무조건 2 byte 

 • 내부적으로 UTF-16 사용

 • 별도의 wchar, TCHAR 개념 없음

 

즉, C#에서는 sizeof(char) == 2 byte 이며, 그냥 char 를 쓰면 곧 유니코드 문자입니다.

 

9. 언리얼 엔진의 TCHAR

언리얼 엔진은 플랫폼마다 크기가 달라지는 wchar를 그대로 사용하지 않았습니다.

 

 •  이름은 TCHAR

 •  크기는 항상 2바이트

 •  플랫폼 무관

 •  UTF-16 고정

 

즉, 언리얼의 TCHAR는 윈도우 TCHAR 와 이름만 같을 뿐, 엔진 차원에서 재정의된 타입입니다.

 

10. 정리

 • 유니코드는 “문자에 부여된 고유 번호”입니다.

 • UTF는 그 번호를 메모리에 저장하는 방식입니다.

 • 윈도우는 UTF-16 을 선택했고, 그 결과 wchar와 TCHAR가 등장했습니다.

 • TCHAR 는 유니코드 과도기를 넘기기 위한 윈도우 전용 호환 타입입니다.

 • C# 은 처음부터 유니코드를 전제로 설계되어 이런 문제가 없습니다.

 • 언리얼 엔진은 플랫폼 독립성을 위해 자체 TCHAR 를 정의했습니다.