의문의 시작
20여 년 전, PC에서 한글을 입출력하기 위해 8/16bit ISA 슬롯에 한글 비트맵 폰트를 넣어두고 VGA 출력을 내부적으로 가로채서 화면에 한글 출력을 대신해 주던 시절, C 및 C++ 언어가 영어로만 되어 있다는 이유로 이를 한글로 처리하는 언어가 나왔던 기억이 불현듯 들었습니다. 물론 그 계획은 결국 역사적으로 사라졌던 기억이 어렴풋 납니다만...
현상 파악
C/C++ 언어 모델은 대부분 ANSI를 기반으로 하는 영문권 기반으로 만들어지는 것이 사실이고, 이런 형태의 기초적인 데이터 형태는 NULL이라는 0x00 이 문자열 끝에 오면 해당 문자열 데이터는 종료된다는 형태에서 시작합니다. 하지만 이런 형태는 1 byte라는 0에서 255까지의 표현만 가능했던 제한이 있었고, 이를 가변적으로 해결하기 위한 형태 중 하나가 UTF-8이라는 표준 언어모델이 있습니다.
이 UTF-8을 이용하면 C/C++ 언어 컴파일을 UTF-8 을 인식하는 대부분의 GCC6 이후부터는 한글로 대체해서 컴파일이 가능할 것이다, 라는 추측이 들어 심심하던 차에 이를 실행에 옮겨 봅니다.
한글로 프로그래밍 시작
근래 C/C++ 컴파일러들은 대부분 UTF-8 을 기반으로 하고 있고, 이게 공백으로 인식되는 space 나 tab 등의 규칙만 잘 지켜진다면 100% 컴파일이 될 수 있을 것이라는 추측으로 위와 같이 macOS 에서 만들어 보았습니다. 그리고 간단히 makefile을 만들고...
이를 통해 make를 돌려 봅니다. 잘 될 것인가?
잘 됩니다.
역시 예상대로 한글이던 중국어던, 일본어던 UTF-8으로 표현이 가능하면 컴파일러도 이를 인식하고 문제없이 컴파일과 링크까지 모두 가능하다는 점입니다. export 되는 함수명도 한글(UTF-8)로 만들 수 있겠습니다. 물론 이는 wide char를 쓰는 윈도나, 컴파일러가 뭔가 다른 차원에 가 있는 MSVC에서는 잘 될지 모르겠습니다.
방금 빌드한 걸 잘 돌아 가는지도 테스트.
잘 됩니다.
어디까지 표현 가능할까?
이왕지사 한글로 다 바꿔 볼 수 있을까?
해 봅니다.
여기까지 가능합니다.
역시 #define으로 정의가 가능하다면 코드상에 precompile 과정에서 대체되는 형태에 문제가 없다면 안될 게 없다는 점입니다. 컴파일은 물론 실행도 문제가 없습니다. 혹시나 해서 clang 14 인 macOS 13에서만 될까? 싶어 두 번째 코드는 macOS12 clang 14에서도 문제는 없었습니다.
어떻게 써먹을 수 있을까?
만인 공통의 오픈 소스라면 사실 이런 형태는 테러라 봐 질 부분 입니다만, github에만 봐도 issue 에 영어는 고사하고 자국어로 질문만 해 놓고 대답은 언제 하냐는 땅떵이는 큰데 속은 더럽게 좁은 아시아의 한 국가사람들 못지 않은 나쁜결과를 불러 올지도 모르겠습니다만, 영어에 최적화 되어 machine learning 을 통해 github 에 올라온 여러 코드를 저작권 무시하고 돌려 쓰는 copilot을 대비하는 형태나, 정말 소수의 한국어 전용 프로젝트에서 사용을 해 본다던가... 하려면 할 수 있다는 것을 알고 응용을 하면 재미난 결과를 얻을 수 있을지도 모르겠습니다.
또는 한국인만 이해하는 특정 함수명을 사용해서 개발을 하는 미친놈이 되어 보겠다는 분들이 계시면, 물론 응용도 가능하겠습니다만, 글쎄요... 공용 프로젝트에서는 한글을 쓰는 것은 좋은 모습이 아닐 수도 있겠습니다만, 한국인들만 써야 하는 것에 사용이 된다면 그때는 재미난 기믹으로 동작할 수 있지 않을까요?
덧,
물론 이 방법은 MSVC에서는 아마 안될 겁니다.
