김 용묵의 절대공간 - 블로그

2020년은 2~40년 전쯤에 만들어졌던 각종 소설과 SF물에서나 다루던 까마득한 미래 시점이다. 그게 현실로 찾아왔다니 감회가 새롭다.
하지만 현실의 2020년은 코로나19라는 웬 신종 바이러스 때문에 교회 예배가 중단되고 학교 개학과 심지어 올림픽까지 연기되는 초유의 사태와 함께 시작되었다. 세상의 그 어떤 소설과 SF물도 이런 걸 예측하지는 못했을 것이다.

2020년은 날개셋 한글 입력기도 개발 20주년에 진입한 시점이다. 그리고 무려 10.0 버전이 현재 개발 중이며, 이게 9.x 시절부터 지금까지 수 년째 미뤄지고 또 미뤄졌던 파이널이다.
원래 9.5를 파이널로 삼으려고 했다. 9.5 이후로도 1년 반 동안 9.6, 9.7, 9.8x 등 새 버전이 도대체 몇 개가 더 나왔던가?? =_=;; 그러던 게 이제야 드디어 제동이 완전히 걸렸다.

이 글에서는 개발 중인 10.0에서 이미 작업이 완료된 것, 더해지고 고쳐지는 것들이 어떤 것이 있는지 잠시 소식을 전하도록 하겠다.

1. '기본 글자판 설정' 빠른설정에 no-shift 두벌식 세팅

10.0 버전에서 본인이 가장 먼저 알리고 싶은 소식은.. 날개셋 한글 입력기의 제어판에서 사용자가 가장 자주 접하게 될 UI인 '기본 글자판 설정' 빠른설정에 no-shift 두벌식을 간편하게 세팅하는 기능이 추가됐다는 것이다. 바로 여기에 말이다.

지금까지 사용자들로부터 받은 피드백을 종합해 보면.. 두벌식에서 shift 없이 쌍자음을 언제나 연타로 입력하는 것에 대한 수요가 제법 많다는 걸 알 수 있었다. 하지만 별 생각 없이 낱자 결합 규칙만 추가해 놓으면 '이끼, 바삐, 앗싸, 홀씨' 같은 단어에서 뒷글자에 등장하는 쌍자음을 연타로 입력할 수 없다. 음절 경계 모호성에 걸려서 '익기, 밥비, 았사, 홄시' 따위와 구분이 안 되기 때문이다.

이런 모호성을 해소하려면 그런 쌍자음은 어쩔 수 없이 shift를 동원해서 입력하거나.. 아니면 capslock 같은 글쇠를 눌러서 앞 글자의 조합을 수동으로 끊는 수밖에 없다. 옛한글 글쇠배열이야 모호성이 훨씬 더 많이 발생하기 때문에 대놓고 조합 중단 글쇠가 배당돼 있기도 하다.

하지만 그런 고전적인 방법 말고 타자 시간 간격을(타이머) 이용해서 음절 경계 구분을 할 수도 있다.
이건 구버전에서도 진작부터 지원돼 왔으니 기술적으로 새로운 기능은 전혀 아니다. 하지만 사용자가 일일이 설정을 하는 게 마냥 간단하고 쉽지 않다. 수요가 많은 상징적인 설정을 곧장 세팅해 주는 기능을 빠른설정에다가 도입한 것은 그 자체만으로도 버전업의 명분이 될 수 있다.

더구나 타이머를 적용하는 방식도 두 가지 중 하나를 선택할 수 있다.

• 통상적인 방법(가-까 타이머): 뒷글자가 쌍자음이면 앞글자를 다 입력한 뒤 한 박자 쉰다(이-끼 → 이끼). 쉬지 않으면 예전처럼 ‘익기’가 된다.
• 다른 방법(각-가 타이머): 위와 반대로, 쌍자음을 지연 없이 빠르게 치고, 자음이 앞뒤 글자에 분산돼 있을 때 한 박자 쉰다(익-기 → 익기). Google 단모음이 이런 방식을 사용한다.

각 방식이 어떻게 구현됐는지를 살펴보면.. 전자는 중성까지만 입력됐을 때도 타이머가 발동돼야 하며 오토마타도 상태가 두 개 더 필요하다.
후자는 오토마타 상태가 하나만 있으면 되지만 특수 도깨비불 규칙과 다단계 입력 분리(65531) 낱자 결합이 추가로 필요하다. ‘밝’까지 쳤다가 도로 ‘발ㄲ’을 만드는 것은 명백하게 더 과격한 동작이기 때문이다.

그래도 사용자의 타자 행동 관점에서 두 방식에 절대적인 우열은 없으니 그냥 자기에게 편한 방식을 골라서 쓰면 된다.
기본으로 설정되는 시간 threshold는 0.5초(500밀리초)이다. 타이머 설정에서 이 값을 더 늘리거나 줄일 수 있다.

2. “조합 안에 조합 생성” 입력 도구

얘는 여러 글자로 이뤄진 단어 같은 덩어리를 다른 형태의 문자로 변환하는 핵심 인터페이스이다. 한글 단어나 훈으로 한자 입력하기, 그리고 T9 방식으로 영단어 입력하기 기능이 제공되고 있는데..

• 변환에 쓰이지 않는 문자는 애초에 조합창에 들어가지 않고 바로 본문으로 삽입되게 인터페이스를 개선했다.
• Ctrl 내지 Shift 클릭을 좀 다르게 인식하게 했다. T9 영단어 입력의 경우 마침표 and/or 공백을 뒤에 같이 삽입하게 했고, 한글-한자 변환의 경우 지금 외부 모듈이 지원하는 것처럼 "한자(漢字)" 내지 "漢字(한자)" 형태의 삽입이 되게 했다.
• 여러 독음 후보들이 존재하는데 이들이 길이가 길고 앞부분이 상당수 일치한다면 명령 프롬프트나 개발툴 에디터에서 하는 것처럼 앞부분의 ‘자동 완성’이 되게 했다. 타이핑 수고를 상당 부분 덜 수 있을 것이다. 자동 완성 단축키는 tab 또는 Ctrl+space 중에서 선택 가능하다.

3. 편집기: 자잘한 개선

날개셋 편집기에서 파일을 읽고 쓰는 아주 기본적인 동작과 관련하여 다음과 같은 강화· 개선 작업이 이뤄졌다.

(1) 파일을 제대로 불러오지 못한 상태에서 저장을 시도하거나, 아까 전에 제대로 저장하지 못한 상태에서 창을 닫으려 하면 확인 질문을 하게 했다.
여기서 ‘제대로’ 열기나 저장을 못 한 상황이란.. 인코딩이 잘못 지정되어서 깨진 문자가 발생했고, 현재 메모리에 존재하는 문서와 파일 형태로 존재하는 문서 내용이 서로 일치하지 않는 것을 말한다. 그 상태로 저장을 하면 문서를 변경하지 않았더라도 원래 있던 정보는 소실될 것이고, 창을 닫으면 마찬가지로 깨진 문자가 원래 무엇이었는지 알 수 없게 될 것이다.

(2) 저장 옵션을 통해서 파일의 인코딩을 변경했다면 문서 내용을 대놓고 변경하지 않았더라도 창을 닫을 때 파일을 다시 저장할지 묻게 했다.

(3) 아울러, 문서창의 시스템 메뉴에 ‘파일 이름 변경’이라는 기능을 추가했다. 이걸 실행하면 ‘다른 이름으로 저장’과 비슷한 대화상자가 나타나며, 여기서 파일 이름을 새로 지정하면 문서창을 열어 놓은 상태에서 프로그램 상의 이름과 디스크 상의 이름을 그걸로 간단히 바꿀 수 있다. 탐색기에서 따로 이름을 바꾼 뒤에 다시 불러온다거나 하는 번거로운 수고를 하지 않아도 된다.

4. 외부 모듈: Chrome 브라우저에서 추가적인 보정

크롬 브라우저는 과거에 자신이 데스크톱 앱인데도 돌아가는 IME에다가는 자신이 메트로 앱이라고 잘못 알려주는 문제가 있었다. 그 버그는 얼마 안 가서 수정됐지만, 그 다음으로 또 약간 알쏭달쏭 아리까리하게 동작하는 게 있다(2020년 3월의 80 버전 기준).

마소 Edge와 Firefox는 TSF를 온전히 지원하는 브라우저이다. 그러나 IE와 Chrome은 그렇지 않다.
TSF를 지원하지 않는 프로그램에서는 앞뒤 글자를 요청한다거나 caret 이동 같은 지시를 내리면 어차피 실패한다. 내 프로그램은 실패에 대한 대비는 물론 돼 있다. 그리고 처음부터 앱을 가려가며 동작하는 게 아니라, 이런 실제 기능의 성공 여부를 토대로 동작한다.

그런데 크롬의 경우, 앱의 종류를 식별해 보면 "TSF 미지원"이라고 나오지만, 앞뒤 글자 요청이나 caret 이동 등의 지시를 내리면 마치 TSF 지원 프로그램처럼 수행되고 성공했다는 리턴값이 돌아온다. 하지만 그게 제대로 올바르게 correctly 수행되어 있지는 않다.

크롬에서 '대한민국' 같은 단어를 입력하고 단어 단위 한자 변환을 시도해 보면 마소 한글 IME는 안 되지만 날개셋은 된다. 하지만 변환을 해 봤자 '大韓民國'이 아니라 '대한민국大韓民國' 이런 식으로.. 정확하게 동작하지 않는다.
더구나 낱자 단위로 달라붙기 옵션을 사용하면서 bksp를 눌러 보면 caret이 앞 글자로 제대로 가지 않고 계속 자기 자리에서 머무른다.

여러 정황상 인접 글자의 fetch는 되지만 텍스트 selection을 변경하는 건 안 되는 것 같다.
결정적으로 크롬이 대외적으로 자신을 "TSF 미지원"이라고 보고를 하므로 날개셋 역시 크롬에 대해서 "오동작을 하느니 아예 동작을 안 하도록" 조치를 취하는 게 바람직해 보인다.

요 보정을.. "데스크톱 앱으로 인식"이라는 보정 옵션에다가 추가했다. 이 옵션이 켜져 있고 앱이 자신을 "TSF 미지원"이라고 표시한 경우, 내 프로그램은 텍스트 고급 조작 지시를 시도조차 하지 않고 방어적으로 동작하게 된다. "TSF 지원"이라는 명시적인 정보가 있을 때만 고급 조작을 하게 된다.

5. 도깨비 한글 글꼴

옛날 도스 시절의 한글 바이오스 유틸인 '한글 도깨비'의 최종 버전  5.1에서 제공되었던 고유한 둥글동글한 글꼴, 일명 '둥근도깨비'체가 날개셋 한글 입력기의 다음 버전에서 제공될 예정이다.
"둥근모, 한솔바탕, 도깨비고딕, 한메굵은본문"을 한데 섞은 듯한 인상이지만 어느 것에 딱 떨어지지 않는 변별성과 독창성이 있고, 모양이 상당히 예쁘기도 한 편이다.

내부 구조를 살펴보니 얘는 놀랍게도 일종의 완조형이었다.
'가'부터 '히'까지 받침이 없는 글자는 완성형으로 각각의 글자들이 일일이 그려져 있고, 받침이 붙었을 때의 '가'~'히'도 마찬가지이다. 그 뒤 받침은 ㅗㅛㅜㅠㅡ용 아니면 나머지.. 이렇게 두 벌만 있다. 이런 형태의 글꼴은 난생 처음 봤다.

이 글자들로부터 초성과 중성을 일일이 decompose한 뒤, 뭔가 반복· 규칙과 패턴을 찾아내어 3차원 조합 테이블을 복원하고 날개셋 편집기에서 읽을 수 있는 11172자 조합형 한글 글꼴로 얼추 재구성했다. 어렵지만 흥미진진한 작업이었다.

ㅏㅑㅓㅕ 같은 모음은 거의 판에 박은 듯이 똑같지만, ㅘㅙ 같은 복합 중성 및 이와 결합한 초성들은 자형이 의외로 제각각 임의로 그려져 있었다. 그래서 규칙을 찾기 어려웠다.
요런 모양의 글꼴을 이런 복잡한 완조형 말고 8*4*4벌로 간소화(?)된 형태로도 옛날에 봤던 것 같기도 한데 정확하게 기억은 안 난다.

도깨비 말고도 1990년대까지 도스 시절에 텍스트 모드에서 쓰였던 유명한 한글 바이오스 유틸로는 태백한글, 한메한글이 있다. 태백과 한메는 제품 이름 겸 개발사의 이름이기도 하지만, 도깨비의 경우 개발사가 '한도 컴퓨터'여서 제품명과 일치하지 않는다.

한글 도깨비의 개발자인 최 철룡 씨는 정말 대단한 분이었다. 1980년대에 IBM 호환 PC의 내부 구조를 모두 마스터하여 한글 바이오스를 만들었을 뿐만 아니라.. 사실은 안 철수와 거의 비슷하게 브레인 바이러스 백신까지 자작했었다. 처음에는 마이크로소프트웨어 잡지의 기자로 재직하다가 나중에는 성이 안 차서 자기 회사를 차리게 된다.
날개셋 한글 입력기는 아래아한글과 마소 도스/Windows뿐만 아니라 태백, 한메, 도깨비에서 제공하던 글꼴들도 한 종류 이상씩은 courtesy 차원에서 제공하고 있다.

6. 그 밖에

• 프로그램 UI를 여러 군데 찔끔찔끔 수정했다. 기억에 남는 것으로는.. 이모지 문자표에다가도 우클릭 메뉴에 '복사'를 추가하고 전용 도움말을 넣었다.
• 지난 8.8부터 9.0대 기간 동안 심혈을 기울여서 구현했던 '복합 낱자 입력 로직 생성기' 빠른설정이 언제부턴가 제대로 동작하지 않고 적용 후에 프로그램이 뻗던 문제를 뒤늦게 발견하여 고쳤다. 직전인 9.9보다 전부터 존재했던 문제로 보인다. 처음에 구현이 잘못된 건 아니고, 나중에 소스 코드를 리팩터링을 잘못 했기 때문이다.
• 24픽셀(화면 확대 배율 150% 이상) 환경에서 날개셋 제어판을 꺼내서 ‘낱자 처리’ 탭에서 ‘낱자 코드 번호 병기’ 옵션을 켰는데.. 자그마한 낱자 번호가 초-중-종성별로 세로 위치가 차이가 나지 않고 언제나 같은 위치에 찍히던 문제를 뒤늦게 발견해서 고쳤다.
• 이 외에도 그 밖에 24픽셀 비트맵 글꼴을 표시하는 목록에서 줄 간격을 1픽셀에서 2픽셀로 늘렸으며, U+200?대에 있는 특수한 공백과 줄표에 대한 글립도 16픽셀일 때와 마찬가지로 추가했다. 또한 외부 모듈에 24픽셀용 아이콘을 추가했다. 고해상도 24픽셀 환경에 대한 지원을 여러 방면에서 강화한 셈이다.
• 외부 모듈의 ‘프로그램 호환성’ 탭에 현재 화면에 보이지 않는 몇몇 Metro 앱이 불필요하게 목록에 표시되어 있던 것을 감췄다. 그리고 ‘모두 원래대로’ 버튼의 원래 의도는 프로그램의 기본 보정 방식으로 되돌리는 것인데 그러지 않고 설정을 몽땅 삭제만 해 버리던 것을 고쳤다.
• 정말 사소한 것이지만.. 立의 한자 훈이 '설 립'(stand 서다)이 아니라 '설사 립'(??!!!)으로 잘못 등록돼 있던 것을 고쳤다. 2020년 현재 마소 한글 IME의 한자 데이터에도 동일한 오류가 있으며, 그게 날개셋에도 그대로 전해진 것 같다.

이상이다. 이 정도면 9.9에서 0.1이 더해진 10.0에 딱 어울리는 수준의 변화로 손색이 없다고 여겨진다.

대략 9.x 초기 시절에.. Windows 10의 특정 버전 내지 특정 게임에서 한글 입력이 안 될 때 내 프로그램을 쓰면 된다는 소문이 퍼졌으며, 날개셋 한글 입력기의 다운로드 트래픽이 폭증하여 내 홈페이지가 며칠 연속으로 셧다운 됐던 적이 있었다.
그래서 한동안 다운로드 링크를 내 홈페이지 서버가 아닌 Google Drive 링크로 제공했는데.. 요즘은 그런 시절도 지났는지 구글 드라이브를 안 써도 트래픽 초과가 뜨지는 않는다.

요즘은 프로그램 관련 문의를 메일로만 받고 있지만 그래도 여러 사용자에게서 문의와 버그 의심 신고 연락이 종종 오곤 한다. 정말 꿈에도 상상할 수 없던 곳에서 내 프로그램을 잘 쓰고 있다는 연락을 받은 적도 있었다. 덕분에 이번 버전도 자잘한 개선 중에는 메일을 통해 접수된 사용자 피드백이 반영된 게 무척 많았다.

내 프로그램을 사용하면서 개인 메일까지 보내서 질문이나 건의를 남겨 주는 분들이 계시니 고마운 일이 아닐 수 없다. 어서 새 버전이 완성되어서 새 기능들이 두벌식과 세벌식 사용자에게 모두 큰 도움이 되었으면 좋겠다.

Posted by 사무엘

오늘날처럼 미터법과 SI 단위가 세계 공통 표준으로 정착하기 전에는 동양에서는 척관법이, 서양에서는 야드파운드법이 오랫동안 쓰였다. 성경에서 마 5:41은 번역 과정에서 서양 단위(1마일, 2마일)가 동양 단위(5리, 10리)로 로컬라이즈도 된 흥미로운 예이다. 마치 "결혼하거나 결혼당하고"가 "시집 가거나 장가 가고"로 로컬라이즈 된 것처럼 말이다.

옛날 단위들은 기준이 서로 제각각일 수밖에 없다. 하지만 그럼에도 불구하고 1자(척)와 1피트는 둘 다 비슷하게 30cm대인 것 같다. 그리고 펄롱과 스타디온은 1/8마일에서 유래되었으며 둘 다 비슷하게 200m가량인 듯하다. 이런 식으로 뭔가 비슷한 쌍도 있다.

피트의 경우 말 그대로 발의 길이에서 유래되었는데, 보통 성인 남자의 신발 사이즈가 270 등 20cm대 후반인 것을 감안하면 그 정도 규모가 공감이 갈 것이다.
이 피트가 오늘날 항공업계에서 비행기의 고도를 나타낼 때도 활발하게 쓰인다. 3만 피트는 10km에 가까우며 여객기 순항 고도의 거의 상한선이다. 물론 비행기를 넘어 우주 발사체의 고도까지 가면 그런 거 없고 다시 km로 돌아간다.

그에 비해 성경에 나오는 큐빗은 발이 아니라 팔꿈치에서 가운뎃손가락 끝까지의 길이에서 유래되었으며, 파운드야드나 척관법과 무관한 히브리 고유의 단위인 것 같다. 그래서 성경의 번역 과정에서 딱히 로컬라이즈 되지도 않는 편이다. (참고로 큐피드 Cupid하고는 마찰음의 위치가 서로 맞바뀌어 있다. ㄲㄲ)

1큐빗은 대략 50cm대로, 자/피트보다 더 크다. 그래서 키가 6큐빗 1뼘이라는 골리앗은 키가 3m를 초월하는 거인이며(삼상 17:4).. 바산의 왕인 '옥'이라는 괴수는 침대의 길이가 소형 승용차의 길이와 비슷한 9큐빗이었음을 알 수 있다(신 3:11). 길이가 300큐빗이라고 기록된 방주(창 6:15) 역시, 길이가 270 '미터'인 타이타닉보다는 훨씬 작은 배이다.

길이 말고 거리로 가면 스케일이 더 커진다.
사실, 길이 length나 거리 distance나 차원은 서로 완전히 동일한 단위이다. 하지만 길이는 자(줄자)로 재어 측정하는 반면, 거리는 굳이 직선 형태가 아닐 수도 있고 측정자가 뭔가 직접 구르고 이동하면서 측정한다는 인상이 강하다. '피트'의 경우, 길이의 단위이니까 발의 길이로 정해졌지, 거리의 단위라면 보폭이 기준이 됐을 것이다.

부피만 해도 유체(기체+액체)의 부피와 고체의 부피는 좀 뭔가 다른 인상이 느껴지며, 고체의 부피에 리터나 갤런 같은 단위는 영 안 어울려 보이지 않은가? 그런 인간적인 심상이(?) 단위에 담기기도 한다.

그리고 반대로 물리적인 차원이 다르더라도 그런 인지적인 심상이 비슷하면 동일 단위가 여러 분야에서 쓰이기도 하게 된다.
가령, 무게의 단위 중에는 그대로 화폐 단위로 통용되는 것이 여럿 있다(탤런트, 파운드). 톤은 원래 담당이던 무게와 동시에 선박 배수량 부피 단위, 그리고 동급의 TNT 양을 기준으로 폭발 에너지의 단위로도 쓰인다. 무게라는 게 물질의 고유 물리량인 ‘질량’을 나타내는 것이니 의미 확장에 가장 유리하니 말이다.

얘기가 옆길로 좀 샜으니 거리의 단위로 돌아오면..
동양에서는 아리랑 가사에도 등장할 정도로 유명한 ‘리’(약 400m), 그리고 서양에서는 마일과 노트(knot 약 1.8km) 정도가 있다. 접두사가 덕지덕지 붙은 킬로미터보다 저런 단어가 더 익숙하고 짤막하고 좋긴 해 보인다.

미국에서 시속 55~60마일 제한이 한국으로 치면 시속 100km 제한과 얼추 비슷하다. 그리고 우리나라는 군사분계선의 길이가 어째 킬로미터 대신 155마일이라고 불분명한 출처를 통해 널리 퍼져 있다.
마일은 그렇다 치고 노트는 해상 업계에서 활발히 쓰이는 중이다. 인류는 미터법이 제정되기 훨씬 전부터 배를 타고 신대륙까지 개척했으니 단위가 다른 건 어쩔 수 없는 노릇이다. 1노트는 1해리, 해상 마일이라고도 부르며, 1마일보다 약간 더 크다.

한국과 미국이 기름값이 얼마나 차이가 나는지 정확하게 알기 위해서는 원/달러 환율뿐만 아니라 리터/갤런 부피 단위도 변환해야 한다(1갤런은 약 3.78리터). 2000년대 초엔 갤런당 1$대이던 게 2000년대 말 불황 때는 4$가 넘게 치솟았었고.. 그러다 지금은 2$를 넘어 3$대인 걸로 알고 있다.

지역과 상황에 따라 케바케이긴 하지만 미국의 기름값은 한국 기름값의 거의 50~70%대라고 생각하면 대체로 맞다. 뭐, 저기는 자동차가 신발이나 마찬가지인 동네여서 모든 가족 구성원이 차를 굴리는, 아니 굴리지 않으면 안 되는 곳인 걸 감안할 필요가 있다. 고등학교가 아니라 중학교를 졸업한 뒤에 면허를 따며, 30대 나이의 직장인이 아니라 10대 알바생도 자가용으로 출근한다. 안 그러면 등교고 통근이고 아예 할 수가 없기 때문이다.;;
한국보다 기름을 훨씬 더 많이 소비하겠지만, 같은 일을 했을 때의 소득도 한국보다는 높을 테고.. 그런 차이가 있다.

또 무슨 단위가 있을까?
면적의 경우, 국내에서는 땅이나 임야에 대해서는 헥타르를 많이 쓰고 집에 대해서는.. 그 유명한 ‘평’을 많이 썼다. 요즘이야 제곱미터로 몽땅 물갈이 됐다. 헥타르는 미터법 단위의 10배수이기 때문에 이해하기 쉽지만 평은 1/3배수에 가까워서 좀 직관적이지 못하다.

리터는 그 정의부터가 세제곱 cm의 1000배이기 때문에 얘 역시 미터법 단위의 10배수 alias(딴이름 별칭)에 가깝다. 옛날에는 이탤릭체/필기체 소문자 l로 많이 썼었지만 요즘은 숫자 1과 혼동된다고 대문자 L로 쓰는 게 대세가 돼 있다.

인치는 한국에서 일상적으로는 거의 쓰이지 않는 듣보잡 단위이지만 디스플레이의 크기를 나타낼 때는 끈질기게 살아남아서 존재감이 각인돼 있다. 12인치 모니터, 30인치 모니터가 대충 어느 정도 크기인지 다들 아실 테니 말이다. 그리고 옛날에는 디스켓의 크기도 5.25인치, 3.5인치 같은 식으로 분류했다. 물론 이것들은 다 미국의 공업 규격으로부터 영향을 받은 흔적이다.

미터법은 철도 궤간이나 국제 표준시(GMT/UTC) 같은 것과 달리, 대영제국이 퍼뜨린 표준이 아니다. 얘는 기원을 굳이 따지자면 프랑스에 가깝다.
미터법은 SI 단위로 체계가 확장되고 현대의 과학계가 정식으로 채택함으로써 (1) 인류 역사상 어떤 도량형도 가져 본 적 없던 엄밀한 정의를 갖게 되었다. “빛이 진공에서 n초만치 진행한 거리, 세슘 원자가 x회 진동하는 데 걸리는 시간, 플랑크 상수가 y가 되게 하는 질량값” 따위 말이다.

(음악으로 치면 도레미파 기준음의 엄밀한 정의를 "어디어디서 나는 특정 소리"가 아니라 소리굽쇠의 440hz 진동수라고 숫자를 동원해 딱 굳힌 것과 비슷하다. 모든 악기의 음높이를 일관되게 조율하려면 그 바닥에서도 절대적인 기준이 필요할 테니... 물론 hz를 엄밀하게 정의하려면 '초'부터 엄밀하게 정의해야 할 것이다.)

길이, 시간, 무게(질량)이야 말 그대로 시공간을 구성하는 기본 축이니까 전근대 시절부터 단위가 존재했지만, 전기(전압, 전류, 전하량)나 밝기 같은 물리량은 애초에 고전 단위계에서는 아웃 오브 안중이었다. 이렇게 (2) 후대에 과학이 발전하면서 추가로 도입된 단위 차원은 오로지 SI 단위에만 존재한다.

다른 단위들의 합성을 통해서 만들 수 없는 새로운 차원이 몇 개가 더 존재하려나 모르겠다. 온도는 그런 새로운 차원의 대표적인 예이다. 서양에는 화씨라고 불리는 단위가 전통적으로 존재해 온 반면, 동양에는 그런 게 없는 것 같다.
길이의 단위가 평균적인 인체의 치수를 근거로 제정되었다면, 온도는 우리 주변에서 쉽게 볼 수 있고 온도별로 다양한 상태로 쉽게 변하기도 하는 물의 끓는점과 어는점을 기준으로 단위가 만들어지는 게 자연스럽다.

그 끓는점과 어는점을 어떤 숫자로 정할지는 엿장수 마음대로이지만 말이다. 단, 과학이 발전하면서 온도는 열역학적 완전 정지를 나타내는 하한이란 게 있다는 게 밝혀졌다. 절대온도는 섭씨 온도와 비례상수는 동일하고(y=ax+b에서 a), 절대영도를 표현하기 위해 상수인 b만 다르다.

사실, 열과 온도는 마치 질량과 무게만큼이나 엄밀· 정확하게 차이를 이해하기 어려운 개념이다. 열은 또 줄이니 칼로리니 하는 에너지로도 연결되니까.. 같은 열을 받아도 다들 알다시피 공기와 물고 금속은 온도의 변화가 전부 다르니 말이다.

SI 단위계는 인간의 심상 인지 유사도와 무관하게 (3) 물리적으로 차원이 동일하다면 반드시 같은 단위를 쓰게 하고, 기존 차원으로부터 유도· 파생되는 단위라는 개념을 명확히 했다. 이 원칙에 따라 칼로리는 차원이 동일한 줄에 밀려 도태하는 중이고, 요즘은 그냥 영양학적 열량 분야에서만 명맥을 유지하고 있다. 한편 와트는 분야가 다르지만 차원이 동일하기 때문에 고전역학의 일률과 전기에서의 전력을 모두 나타내는 데 쓰인다.

끝으로 SI 단위계는 (4) 숫자의 10진법 자릿수 보정을 위해 킬로, 밀리 같은 접두사도 명시하여 체계화했다.
그러니 여러 모로 굉장히 깔끔하고 쓸 만한 단위계가 됐다. 로마 숫자에서 아라비아 숫자로, 그림문자에서 음소문자로 바뀌는 것 같은 변화가 아닌가 싶은데..

그럼에도 불구하고 미국은 세계에서 거의 독보적으로 미터법을 따르지 않는.. 아니 더 정확히는 따르지 못하고 있는 갈라파고스 국가이다. 관습적으로 정착한 단위와 학술적으로 통용되는 단위가 서로 심하게 다르기 때문에, 대중을 상대로 과학 발표나 강연을 하면서도 각종 통계 자료에서 “아, 이 값들은 단위가 미터법인 걸 양해 바랍니다” 이런 말도 안 되는 해명을 해야 한다.

그리고 극단적으로는.. 현업 종사자조차도 단위를 헷갈리는 바람에 정비 불량으로 비행기와 우주선이 추락하는 사고가 난 적도 몇 차례 있다. 기름을 n 갤런만치 넣어야 하는데 실수로 n 리터만 넣는다거나 하는 식으로 말이다. 세계 최강의 과학기술 강국이며 행정 시스템 선진국인 천조국의 위상과 전혀 어울리지 않는 흑역사가 아닐 수 없다.
심지어 종이 크기도 세계 표준인 A4(제곱미터 기반) 대신 레터라는 인치 기반의 독자 규격을 쓰는데.. 이에 대해서는 나중에 별도의 글로 또 다룰 것이다.

일본이 협궤가 골칫거리라면 미국은 단위계가 골칫거리인 셈이다. 뭐, 둘 다 110V 전압도 골칫거리이긴 하다만.. 근대화 산업화를 일찍 한 나라는 이렇게 시대 흐름에 뒤쳐진 레거시도 하나씩 생기는가 보다.

우리나라는 SI 단위가 잘 정착한 축에 들지만 부동산의 면적에서는 평이 다른 단위로 대체되기는 영 쉽지 않아 보인다.
그리고 딱히 도량형은 아니지만.. 나이를 좀 한국식과 만의 구분을 없애고 간단하게 "현재 연도 - 태어난 연도"로, 즉 만 나이로 통일해 버렸으면 좋겠다. "한국식 나이로, 만 나이로" 이게 미국에서 "미터법을 쓰자면..." 이러는 거나 다를 바 없는 삽질이다.

학년을 따질 때 빠른 생일 1, 2월 구분을 없앤 지는 꽤 됐는데.. 저것도 더 간단하고 합리적으로 바꿨으면 좋겠다.

Posted by 사무엘