언어 채널

1. 한국 : 완성형 삽질

유니코드와  UTF-8 시스템이 나오기 이전 16비트 문자열의 최대 경우의 수는 9200여자 밖에 안되었음. 8비트 및 7비트와의 호환을 위해서였고.

즉, 2바이트 안에 한글 낱자인 11172자를 모두 집어넣으려면 7비트와의 호환성을 때려 치워야 했음.

아니면 타자기 치듯이 조합형으로 하는 방법이 있었는데... 받침있는 글자는 최소 3바이트를 집어 먹어서 가뜩이나 부족한 용량을 더 먹게 생김.


여기서 완성형 삽질이 무엇이냐 하면.

9200여자 안에 특수문자, 영숫자 이런거 제외하고 8000자 정도는 한글로 때려넣을수 있었는데.

어짜피 다 못한다고 한글을 2300여자만 집어넣음. 심지어 한자는 4000자 넘게 집어 넣는데다가 다른음을 가진 한자는 중복 배당하는 만행을 저지름.

그 때문에 외래어/외국어는 물론이고 표준어 일부 단어도 표기가 불가능해짐.

완성형에 들어간 글자는 빈도순으로 자르긴 했지만, 한국어 IME 특성을 고려 못한 글자도 존재함. 예를들어 쓩을 입력하려면 ㅆ과 쓔 가 먼저 입력이 되야하는데, 쓔가 완성형 글자에 없어서 쓩 글자를 입력하려면 특수문자 처럼 문자표에서 일일히 찾아넣는 수고를 해야함.

한국어에서 받침이 없는 글자는 399자인데... 이 중에 빠진 글자가 존재하면 그 밑 에 받침있는 글자는 모두 해당이 됨.


이 삽질은 유니코드에도 영향을 미쳤는데.

유니코드 최초 제작 당시 한글은 완성형에 있는 글자만 존재 했었음. 그러다 한국측 요구로 인해 2.0에서는 11172자가 모두 배당이 되었는데....

그 순서까지 가나다 순으로 싹 뒤엎으면서 유니코드 2.0 미만의 문서는 현재 호환이 안되는 상황임. 별도로 인코딩을 해줘야 함.

그 뒤로 유니코드는 단 한번도 순서를 바꾸지 않게됨.



2, 일본 : 전각 영문

16비트 시스템이 나오기 이전 문자열을 8비트 (256종류) 안에 다 쑤셔 넣을 수 있으려면 가나만 써야 했음. 그것도 가타카나만.

당시 낮은 해상도와 다른 8비트 문자열과의 호환성을 위해서는 해당하는 가타카나를 가로가 절반인 반각 사이즈로 출력했었고. 그게 반각 가타카나의 원조가 됨.

나중에 16비트 시스템이 나오고 나서, 한자와 히라가나까지 포함한 문자열을 만들었는데.... 가타카나를 기존에 있던 곳에 냅두고 폰트만 좀 키웠으면 됫는데  반각이 보기가 싫었는지는 몰라도 영문까지 포함한 전체를 전각으로 한번 더만들었음.

똑같은 문자를 두번 배당한 탓에, 비슷하게 생긴 특수문자가 생겨버리게됨. ARCA 와  ARCA 는 서로 다른 문자이기 때문에 정렬, 검색 등에서 문제가 됨. 코딩할때도 꽤 문제가 되는모양.


만들어놓고 접근성이라도 안좋았으면 모를까. 일본어 키보드에는 반각/전각 변환키가 존재하기 때문에 (보통의 ~ ` 자리) 전각 영문의 접근성이 너무 쉬워짐. 그래서 일본 홈페이지는 아이디나  비번 같은거 입력할때 굳이 반각이라고 알려줘야 할 정도.

그나마 요즘 IME는 성능이 좋아서 그런자리에 굳이 전각으로 입력하지는 않지만.


3. 중국 : 한자타자기, 한자변환

20세기 타자기가 보급되고 나서 한국은 한글타자기를 만들어 냈는데.

한자를 쓰는 중국은 그게 불가능함.

한자 타자기가 존재하기는 하나, 사이즈가 활판인쇄 사이즈와 맞먹고 속도도 많이 느림. 

서양식 타자기와 같은 효율은 날 수가 없음. 단, 어느정도 빠른 물건이 40년대 개발되긴 했으나 시제품 단계에서 국공내전으로 유실됨.


나중에 중국어를 컴퓨터로 입력하는게 되었을 때에도, 한자 입력 방식때문에 문제가 됨.

한자는 그 특성상 키보드에 모두 담는게 불가능하고, 무조건 입력후 변환이라는 과정을 거치게 되는데, 그게 중구난방으로 통일이 안되었다는점임.

물론 지금와서는 거의 한어병음으로 통일되다 시피 했지만.

주음부호, 창힐수입법 등등 여러 변환방법이 존재했었음.

중국어 키보드중 오래된거는 키보드 하나에 다른 한자가 여러개 존재하는 경우가 있는데, 입력방식이 여러개던 시절의 흔적일 가능성이 높음.

그리고 당연히 다른 시스템끼리는 호환이 안되었다는점.


4. 번외, 일본 : 팩스

이건 번외인게, 인터넷이나 이메일이 보편화 된건 21세기라서. 제목값을 못함.


일본의 경우, 한자 사용으로 타자기 보급이 안됨 + 초창기 IME의 구린성능 + 도장문화  로 인해서 수기문서가 많던 환경이였음.

그리고 팩스는 그걸 보내는 가장 빠른 수단이였고.


늦게잡을경우 1990년대 까지는 그게 괜찮은 방법이였음.

문제는 그 이후. 인터넷이 보급화된 21세기  들어서는 굳이 수기문서작성을 고집할 필요가 없음에도 기존의 방식의 결과를 고집한 결과 종이만 쌓이게 됨.

수기 문서와 팩스로 작업된 문서는 데이터화가 되지 않기때문에! 찾으려면 일일히 찾아야함. 

만일 최대한 효율적으로 하려고 했으면 기존의 문서까지 전부 입력해서 컴퓨터에 저장시켜놨어도 모자랄 판에. 신규로 들어오는 팩스만 넘쳐남.


그게 쌓이고 쌓여서 터진게 올해. 코로나 대응에서 터져버림.

일본의 코로나 환자 집계발표는 실제 발생보다 3일이 늦어지는데, 그 이유가 바로 팩스때문.

병원에서 환자를 기록/검사한 서류를 보건소로 보내면 그걸 후생노동성으로 보내서 집계하는게 그게 전부 '팩스' ...

심지어 병원측에서 이메일로 보내고 싶어도 그 시스템 자체가 안되어 있었음. 부랴부랴 허시스 라는 시스템을 도입하기는 했지만, 잦은 고장으로 문제가 된 모양.

전국 보건소에서 팩스로 보내온 그 수천장의 팩스를 일일히 취합해서 발표하느라 3일이 걸림.

그마저도 지역 보건소와 오차가 생기는 경우도 많고.

환자에 대한 통계작성은 아예 불가능할 지경이였음.

일본에서도 우리나라 재난지원금 같은 시스템이 있었는데, 이건 온라인 지원이 가능했음에도 불구하고. 온라인 지원을 하면 그걸 종이에 뽑아서 직접 대조하는 그딴 시스템이였다고함. 팩스랑 다를바 없는 시스템...  그러다보니 지자체에 따라서는 아예 온라인 지원을 포기하고, 우편으로 보내라고 할 정도.