최근 모 업체에 파일을 보내야하는 일이 생기게 되었다. 한글 제목의 파일을 작성하여 보내려고 하는데, 마음 속에 걸리는 부분이 있었다. 그것은 바로 맥에서 윈도우즈로 한글 파일명의 파일을 보내면 파일명이 “보고서.pdf”가 “ㅂㅗㄱㅗㅅㅓ.pdf”와 같은 식으로 깨진다는 사실이었다. 회사에서 근무할 때도 그런 현상을 자주 목격했었고, 어떤 경우에는 그런 파일명이 프로그램의 오작동을 야기한 적도 있었다. 아무래도 파일명이 깨져서 보이면 인상이 안 좋으니까, 윈도우즈에서도 화면에 제대로 보이게 하고 싶었다.
해당 현상은 유니코드 정규화 방식(NFC와 NFD)의 차이 때문에 발생하는 것이다. 최근 자주 사용하고 있는 Dart 언어를 사용해서 파일명의 정규화 방식을 수정하도록 CLI 프로그램을 작성했다. Dart는 컴파일하면 네이티브로 실행할 수 있는 바이너리도 만들 수 있으니 좋아보였다. 하지만 컴파일하고 나니 신경 쓰이는 부분이 있었다.
6.3M 11 12 16:13 unicode_norm바로 빌드된 바이너리의 사이즈가 6.3MB나 차지를 하는 것이였다. 엄청 간단한 프로그램인데도 이 정도의 사이즈가 되니, 더 작은 사이즈의 프로그램을 만들고 싶어졌다.
그래서 C로 프로그램을 작성하기로 결심하고 unicode_norm을 다시 짜기 시작하였다. 그래서 만들어진게 바로 아래의 unicode_norm 프로젝트이다. 여러 사람들에게 도움이 될 것 같은 유틸성 프로그램이라 오픈소스로 공개하였다. 이렇게 C로 만들고 나니 51KB까지 사이즈를 줄일 수 있었다. 물론, 이것은 해당 프로그램에서 사용하는 utf8proc이라는 라이브러리를 동적 링크하여 빌드한 경우라서, 정적 링크를 하는 경우에는 391KB 정도의 사이즈가 되는 것을 볼 수 있었다.
51K 12 23 22:35 unicode_normhttps://github.com/arrghsoft/unicode_norm
아무튼 처음 Dart로 1~2시간 안에 작성한 것을 C로 작성하려니 은근 시간이 걸렸다. 거기다가 MacOS 뿐만 아니라 Windows, Linux 지원까지 추가하고 테스트하려고 하니 몇시간 단위가 아닌 몇일 단위로 필요하게 되었다. 역시 C를 사용하지 않고, 좀 더 고급 언어를 사용하는 이유가 있었다. 그렇지만 C로 프로그래밍하는 것도 상당히 즐거웠다.
아래는 해당 프로그램에 대해서 설명하는 영상이다. 최대한 짧은 시간에 컴팩트하게 내용을 전달하는 것을 목표로 편집을 해서 만들었다. 동영상의 결과물은 2분도 채 안되지만 동영상 편집도 몇 시간이 걸린 것 같다.
오른쪽 클릭으로 파일명을 수정하는 기능을 추가했는데 꽤 편리한 듯 하다.
맥에서는 Finder에서 NFC 방식이나, NFD 방식이나 화면에 똑같이 표시하기 때문에, 확실하게 파일명을 확인하기 위해서는 ls | xxd 와 같은 명령을 통해서 실제 바이트를 확인하는 것도 추천한다.
해당 프로그램을 작성하면서 느낀 점을 정리해보면…
1. 윈도우즈 지원 관련: 윈도우즈에서는 OS 내부적으로 UTF-16을 사용한다. int main(int argc, char* argv[])로 프로그램 인자를 받으려고 했을 때, 유니코드로 된 문자가 argv로 받아들여지지 않는 문제가 있었다. (?로 표시) 이 문제 때문에 많이 고생을 했다. 윈도우즈에서는 main이 아닌 wmain 함수를 사용할 수 있어서 UTF-16 방식으로 입력을 받아서 UTF-8으로 변환을 하고 로직을 수행하는 식으로 처리하는 방향도 있다. 그렇지만 그렇기 하기에는 너무 지저분하지 않은가. 인터넷을 하루종일 찾아봐도 main으로 유니코드 파일 인자를 받는 이야기는 거의 찾을 수 없었다. 결국엔 neovim 소스코드를 확인하고 빌드된 바이너리를 뜯어봄으로써 알게 되었는데, 애플리케이션 매니페스트 xml 파일이라는 것이 있어서 해당 파일에 UTF-8을 명시하면 UTF-8로 인자를 잘 받았다. 해당 이슈를 해결하느라 고생을 좀 한 것 같다.
2. 역시 빠르게 개발을 해야하면 C보다는 더 고급 언어가 좋을 것 같다. 즐겁게 코드를 작성하고 싶을 때, 또는 컴퓨터가 너무 궁금해졌을 때는 C나 어셈블리도 써보는 것도 좋은 듯 하다. 이번에 오랜만에 C로 코드를 작성하니 즐거웠다.
3. 동영상 편집 힘들다… 짧은 영상을 만드는 것도 은근히 손이 많이 가서 밤늦게까지 편집을 하였다. 내 편집 실력이 안 좋은 것도 늦게까지 해야했던 이유일지도 모른다.
4. 프로그램의 전파(Distribution)가 어렵다… 역시 프로그램을 만드는 것으로 끝이 아니라, 이 프로그램이 필요한 사람에게 이런 프로그램이 생겼다는 사실을 전해줘야하는데, 그것은 정말 쉽지 않은 일인 듯 하다. 프로그램을 만들 때부터 사람들에게 퍼뜨릴 방법을 생각해야하는 걸지도 모른다.
5. 새롭게 배우게 된 것들도 많아서 좋았다. homebrew를 통해 나의 패키지를 설치할 수 있게 만드는 방법이라던가, msi 인스톨러를 생성하는 방법 등 다양한 것들을 접할 수 있었다.
일단 내가 쓸려고 만든 프로그램이라 다른 사람이 쓰지 않아도 내가 잘 쓰면 그걸로도 충분히 만든 가치가 있는 프로그램일지도 모른다. 그래도 아무래도 다른 여러 사람들이 내가 만든 프로그램을 사용하는 모습을 보는 것이 정말로 보람찬 일인 것 같다. 많은 사람들이 내 프로그램을 사용해줬으면 좋겠다.
읽어주셔서 감사합니다.
답글 남기기