Figure 1은 우리가 흔히 보는 한글 컴퓨터 키보드를 보여주고 있다.

Figure 1. Korean Computer Keyboard

Modify Delete

키보드의 레이아웃은 국제표준 ISO/IEC 9995-7:2009 (2012)로 기본적으로 요구되고 있다.

한글 컴퓨터 키보드의 글자 배열은, 특수문자를 포함하여 KS X 5002 (2013)에서 규정하였는데 통상시판품인 Figure 1은 사실 KS에 비해 특수문자의 배열 위치가 약간 다르다. KS의 특수문자 배열은 영국 표준 BS 4822 (1994)의 그것과 비슷하다. 그런데 통상품은 Figure 2의 미국 표준(ANSI-INCITS 154, 1988) 키보드와 정합적이며 여기에 "한자", "한/영" 키가 추가된 것과 같다. ANSI 자판은 ASCII 자판으로도 불린다.

Figure 2. ANSI Keyboard Layout used primarily in the United States

Modify Delete

엔터키의 모양은 보통 3가지가 있으며 규정상 ANSI와 KS가 모양이 다르지만 큰 문제는 없다.

배열 문제에서 가장 큰 문제는 왼빗금(\)이 없다는 것이다. 왼빗금은 영어로 흔히 'backslash(역슬래시)'라고 하는데 유니코드에선 'reverse solidus'라고 한다.

왼빗금 자리에 원화기호(₩)가 할당되어 있고 왼빗금을 넣을 수 없다는 것이 문제이다. 왼빗금은 코딩이나 인터넷 주소 분리자 등에서 자주 쓰인다. 한편 최근의 글꼴(폰트)에서는 원화기호 대신 왼빗금이 나타나기도 한다. 즉 글꼴, SW에 따라 달라지기도 하는데 엄연한 문제이다. 왼빗금과 원화기호는 엄연히 다른 기호이다. 무엇이 잘못되었는지, 이 문제를 검토하고자 한다.

또한 텍스트의 한 열(column) 위치에서 수직으로 정렬하고 싶지만 글자의 폭이 미세하게 달라서 Figure 3의 예와 같이 불일치되고 있다.

Figure 3. An Example of Different Vertical Alignment

Modify Delete

이런 경우 좁은 공백(공백의 약 반 넓이)가 수직 정렬을 위해 필요하게 된다. 탭을 사용할 수 있지만 단어 사이에 바람직하지 않게 넓게 떨어질 수 있다.

또한 줄 끝에서 공백으로 인한 자동으로 줄바꿈을 원하지 않을 때 종종 비분리공백(non-breaking space, NBSP, 묶음빈칸)이 필요하다. 이러한 공백 입력의 문제도 검토하고자 한다.

왼빗금과 원화기호는 유니코드(ISO 10646) 곧 이의 한국화 표준인 KS X ISOIEC 10646 (2010)에서 달리 정의된다. 유니코드에서 관련된 문자를 찾아보면, Table 1과 같다.

Table 1의 부호 모양들은 폰트에 따라 원래 유니코드에서 정의한 것과 미세하게 달리 출력되기도 한다. 예를 들어 그 크기나, 원화기호의 경우 가로막대가 한 줄 또는 두 줄인 예와 같다.

ANSI 키보드는 우상단에 왼빗금이 표시되어 있으며 출력 역시 왼빗금이다. 그런데 한국 키보드는 원화기호를 표시하고 원화기호를 출력한다. 설사 ANSI 키보드를 사용한다고 하더라도 한글윈도 또는 한글 맥은 왼빗금 키를 누르면 원화기호를 출력한다. 어디에서 잘못되었나?

영문자판의 왼빗금은 한글자판에서도 왼빗금으로 정의되어야 정합성이 있다.

KS 자판과, 한글 통상품, ANSI 자판, 영국 자판을 상호 비교하고, 문자코드를 살펴보자.

앞서 언급한 것과 같이 통상품은 엄밀하게 KS X 5002 (2013), "정보 처리용 건반 배열"의 규정과 다르다. 한글 자모 부분은 문제가 없으나, 기호 부분이 다르다. 그런데 기호 부분은 ANSI 표준과 왼빗금 자리 외에는 같다.

참고로 키보드 레이아웃 및 배열은 ANSI 표준과 ISO 또는 영국 표준은 약간 다른데, 영국 표준은 ANSI 보다 키가 1개 더 많고 그에 따라 글자 2개가 더 많은데 이는 ¬(부정 기호, not sign), £(파운드 기호, pound sign)이다. 구체적 배열도 다소 다르다. 그뿐 아니라, 영국 표준은 오른쪽 ALT 키를 이용하여 Á, É, Í, Ó, Ú 등의 악센트문자와 ¦(끊긴 막대, broken bar), €(유로화 기호)를 넣을 수 있다. '끊긴 막대'는 '세로 막대 |'와 다른 글자인데 혼용해서 쓰이기도 한다.

'￦ 및 |'의 키 위치는 제품에 따라 1) 맨 윗줄(숫자줄), 2) 둘째 줄(QWERTY줄), 3) 세째 줄(ASDF줄)의 세 가지가 있고, Figure 4에 보듯이 각각 엔터키의 모양에 따라 L형, I형, T형이라고 부른다.

Figure 4. Enter key and Reverse solidus key positions

Modify Delete

정리하면, 한국키보드와 ANSI 표준과의 차이점은, 1) ANSI 자판에는 왼빗금(\)이 있으나, 한국자판에는 그 대신 ￦ 기호로 대체되어 있고, 2) ANSI 자판은 엔터키가 I자형이고 한국키보드는 L형이다. 이에 따라 왼빗금 또는 원화기호의 위치가 다르다. 그러나 현실적으로는 엔터키의 모양이나 왼빗금 키의 위치는 별 문제가 없이 사용되고 있다.

유니코드 또는 ASCII와 KS X 1001 (2014)을 비교하면 왼빗금 문제가 심각한 문제이다. ASCII의 왼빗금 위치에 KS X 1001 (2014)는 ￦로 규정한 것이다. 단 KS X 1001 (2014)의 문자들은 반각이냐 전각이냐의 구분은 없다. 현실적으로 전각에 대응시킬 뿐이다. 우리나라의 문자집합은 KS X 1001 (2014)을 기본으로 사용하고 있다. 유니코드가 일반화된 지금에는 왼빗금과 원화기호가 폰트마다 Table 2처럼 제각각이다. 폰트에 따라 왼빗금 코드와 원화기호 코드를 모두 원화기호로 표시한다. 윈도시스템의 바탕, 돋움, 굴림과 같은 기본 폰트들이 그 예이다. 맑은고딕, 새굴림도 코드 005C를 원화기호로 표시한다. 큰 오류이다. 하지만 전각왼빗금(＼, FF3C)와 전각원화기호(￦, FFE6)는 어떤 폰트이든 제대로 나온다. 원화기호의 가로막대가 한 개이기도 하고 두 개이기도 하는 차이가 있다.

결국 유니코드 005C의 표시가 관건이며, 워드프로세서나 폰트에 따라 왼빗금과 원화기호로 달리 나타나기도 한다.

현재 한국의 KS X 5002 (2013)은 왼빗금을 넣지 않고 원화기호를 넣었다.

유니코드 철학에 따라 모든 기호는 정확히 해당 기호를 표시해야 한다. 그런데 다른 기호를 표시하거나, 20A9 원화기호 대신 ‘??’ 식으로 나타나는 것은 잘못이다.

인터넷 주소 표시나, 폴더 구분, 또는 코딩 시, 005C의 왼빗금이 필요한 데도 불구하고 원화기호가 나타나면 명백히 잘못이다. 유니코드 철학에 어긋난다.

따라서 가장 시급한 것은 왼빗금을 원래대로 키에 배열하고, 한편 우리나라는 원화기호가 필요하므로, 원화기호는 대안을 설계해야 한다. 이의 방법으로 다음과 같은 방안이 있다.

제1안. 한글 모드와 영문 모드를 구분하여, 영문 모드에서는 원래대로의 왼빗금으로, 한글 모드에서는 원화기호로 사용하는 방법. 현실을 반영하고 쉽게 정합성을 높이는 방법이지만, 한글모드에서 왼빗금을 입력하고자 할 때 매우 불편하므로 바람직하지 않다.

제2안. 한글 모드나 영문 모드나 왼빗금은 원래대로 정의하고, 원화기호는 한글 모드의 경우 비어 있는 시프트 자리의 하나에 할당하는 방법. 현실성있고 특별한 변경이 아니므로 바람직하다. 대표적 예로서 'ㅣ(L)'의 시프트 자리이다.

제3안. 하드웨어적 방법으로서 영국 자판처럼 키 하나를 추가한 '48키형'으로 사용하는 방법. 왼쪽 시프트키와 Z 사이에 한 키가 더 들어가는 데 추가 키에는 원화기호 외에 다른 중요 부호 예를 들어 가운뎃점을 할당할 수 있다. 이것은 하드웨어나 OS의 IME를 바꾸어야 하는 단점이 있어서 현재로선 가능성이 낮다.

다음으로 공백문자의 입력에 관한 개선방향이다. ANSI 키보드는 NBSP가 없으나 국제적으로 몇 나라는 이를 AltGr+공백으로 구현하고 있다.

핀란드의 다언어 키보드, 캐나다의 다언어 키보드, 독일의 T2형(DIN 2137:2012-06)이 그 예이다. 독일은 시프트+공백으로 NNBSP(좁은 비분리공백)를 구현한다.

따라서 1.절에서 서술한대로 좁은 공백의 소요와 비분리공백의 두 가지 소요가 있는데, 좁은비분리공백(NNBSP)을 사용하면 이 두 가지 목적을 달성할 수 있다. NBSP은 NNBSP의 두 번으로 가능하기 때문이다.

KS X 5002 (2013)을 분석해 볼 때, 이는 배열의 표준으로서 범위가 한글 자모, 영문, 숫자 및 기호를 수용하는 것인데, 왼빗금 외에 아래와 같은 문제를 개선해야 한다.

1) 용어를 KS간 일관성이 있게 할 것

2) 통상 현실을 반영하여 영국 표준 배열보다는 ANSI 정합형으로 할 것(사실 영국 표준처럼 키가 하나 더 있는 것도 아님). 예를 들어 KS는 윗줄(¯)이 있는데 ANSI와 맞게 윗줄 대신 물결기호(~)를 넣어야 하고, 세로줄도 '깨진 세로줄(¦, 00A6)'이 아닌 그냥 '세로줄(007C)'을 넣어야 함.

이들은 향후 하드웨어 표준인 KS X 5003 (2011)과 함께 일관성 있게 개선해야 한다.

KS X 5002 (2013)은 순전히 배열만 다루든지 (휴먼인터페이스적인 그래픽 문자), KS X 5003 (2011)은 순전히 하드웨어만 다루든지 하는 방법이 있다. 사실 KS X 5002 (2013)이 현실에 더 가깝다. KS X 5002 (2013)은 26 문자자리만 정의하고 나머지는 ANSI와 동일하게 한다고 규정하는 것이 바람직하다.

특히 한국 언어에 적합하게 가운뎃점(·), 참고표(※), 한국형 따옴표 등을 수용해야 한다. 윗글자 자리 여분이 많으므로 충분하다.

사용자들이 잘 알고 있듯이, 한국 키보드는 우상단에 원화기호가 각인되어 있다. 이것을 입력했을 때 출력의 표시는 폰트에 따라 원화기호가 나타나거나(윈도 기본 글꼴), 왼빗금이 나타나기도 한다.

이것은 유니코드 철학에 맞지 않으며 우리의 문자 생활에 심각한 문제이다. 키보드는 ANSI와 일관성을 위해 원화기호 대신 왼빗금으로 일관화되어야 하고, 원화기호는 빈 윗글자 자리 하나에 할당되어야 한다.

PC 키보드의 엔터키는 L형, I형, T형이 있는데노트북은 공간절약 상 I형으로 일관화되고 있다. 데스크탑 키보드(큰 키보드)는 KS의 규정과 달리 통상 세 가지 유형이 다 보이고 있고 큰 문제는 없으나, ANSI와 정합성을 높이고, 노트북과의 정합성을 높이기 위해 I형으로 일관화가 바람직하다.

근본적으로 KS X 1001 (2014)의 규정 상 원래 ASCII의 왼빗금의 자리에 원화기호가 자리잡았기 때문인데, 궁극적 해결은 KS X 1001 (2014)를 함께 개선하는 것이다.

백슬래시와 원화기호 문제의 근본은 문자집합 문제인데, 한국의 문자집합은 일본 JIS X 0201 (1969) 체계에서 벤치마킹한 것으로서 한국과 일본은 각각 ASCII 문자 집합에 대응하는 KSX1003과 JIS X 0201 (1969)에서 왼빗금 자리에 그것 대신 원화기호(₩)와 엔화기호(¥)를 대체한 것이 원초적 문제의 시작이다.

그러나 대부분의 운영시스템 또는 SW에서는 ASCII와의 호환성을 위해 이들을 원화 또는 엔화기호라 하더라도 왼빗금으로 간주하여 처리하고 있다. 하지만 원화기호와 왼빗금을 서로 혼동하는 것은 잘못으로서 이를 앞서 제시한 방법으로 해결해야 한다.

KS의 한글키보드는 규정과 통상상품이 부호문자에서 배열이 약간 다른데, 이를 ANSI와 정합성이 있게 개선하여야 한다. 26개의 알파벳 영역 외의 부호 자리는 원칙적으로 ANSI 자판과 정합되어야 한다. 특히 원화기호 자리는 원래대로 왼빗금을 할당해야 한다.

또한 NBSP의 소요와 좁은 공백의 소요의 두 가지를 맞추기 위하여 NNBSP를 시프트+공백이나 우알트+공백으로 규정하는 것이 바람직하다.

한편 우리나라는 원화기호가 필요하다. 이의 방법은 여러 가지 대안이 있지만 현실성이 있는 방안은 왼빗금을 원래대로 규정하고, 원화기호는 비어 있는 시프트 자리의 하나, 예를 들어 ‘ㅣ(L)’자의 윗글자 자리에 할당하는 것이다.

어쨌든 지금과 같이 왼빗금 기호와 원화기호가 혼동되게 출력되어서는 안된다.

향후, KS의 원래 규정과 실제 키보드의 차이와 구체적 개선에 있어서 배열 위치를 기존의 학습을 침해하지 않고 개선하는 것을 깊이 연구할 계획이다.

장기적으로 KS에서 권장 위치라고 규정하는 윗글자 7개도 없애서 단순하게 하고 'ㅐ, ㅔ'도 'ㅘ'나 마찬가지의 합자의 하나이므로 없애는 방향이, 휴대폰과 일관성 있게 연구되어야 한다고 보지만, 당장의 저항감이 클 것이므로, 우선 원화기호와 왼빗금 문제부터 해결해야 한다.