표준이 된 세벌식? - (1) 1980년대에 쓰인 여러 가지 한글 표현 방식

※ 「표준이 된 세벌식?」은 「한글 문화원이 보급한 세벌식 자판」(https://pat.im/1141)에 이어서 제2부로 올리는 묶음글 제목입니다. 한글 자판에서 이야깃거리를 돌려 한글 부호계와 한글 조합 방안에 얽힌 이야기로 글을 이어 갑니다. (2018.12.6.)

1) N 바이트 조합형과 3바이트 조합형

  'N 바이트 조합형'과 '3바이트 조합형'은 소형 컴퓨터가 '퍼스널 컴퓨터(PC)'나 '교육용 컴퓨터'라는 이름으로 일반에 보급되기 시작한 1980년대 초반부터 쓰인 한글 처리 방식이다. 한글 낱자들을 1바이트 부호계(7비트 또는 8비트 부호계)의 부호값들과 짝지어서 부호값을 이어 붙이는 방법으로 한글을 나타내었다.

  'N 바이트 조합형'에서는 확장 문자의 시작과 끝을 알리는 부호로 SO(Shift Out)와 SI(Shift In)를 한글 내용의 앞뒤에 붙이고 한글 낱자를 나타내는 부호값들을 넣었다. 한글 낱자를 닿소리와 홀소리로만 나눈 2벌식 부호계가 쓰였다. 내부에서 한글 부호값을 처리하는 과정에서 홑낱자를 겹낱자로 조합하는 처리를 하지 않아서, ㅘ · ㅝ 같은 겹홀소리를 2바이트로 나타냈다. 한글 낱내(음절) 완성자에 들어가는 낱자 수에 따라 '아'는 2바이트, '꽉'은 5바이트로 나타내었다.

  월간 《마이크로소프트웨어》 1985년 11월호에 실린 특집 기사 「언제쯤이나 가능할까? 컴퓨터의 만족스런 한글처리」에서는 CALL 3327 한글을 이렇게 설명하였다.

  • CALL 3327 한글은 일반인이 최초로 접할 수 있었던 한글 처리 방식임
  • CALL 3327 한글이 채택한 자판 배열은 두벌식 타자기 자판 배열을 기준으로 하였고, 이 배열이 초기의 16비트 퍼스널 컴퓨터에 그대로 이어짐
  • 표준 두벌식 자판 기준으로 하여 한글 ㄱ을 같은 자리에 있는 영문 r로 나타내는 방식주1이어서 한글 소팅(sorting, 차례짓기)를 할 수 없음
  • 이 한글의 방식을 가리키는 N 바이트 방식이라고 이름은 한글의 음소 하나를 영문자 하나로 대응시키기 때문에 한 음절이 몇 바이트일지(2~5바이트) 알 수 없다는 뜻에서 붙임
  • 한글의 한 낱내자와 영어의 한 문자의 비율이 일정하지 않아서 화면에서의 한글 처리에 어려움이 따름
  • CALL 3327 한글이 보급된 이듬해(1984년)에 CALL 3327 한글을 본 프로그래머와 엔지니어들이 회의를 느끼고 그들 나름대로 한글 처리 개념/방식을 개발하기 시작함
    → 2바이트 한글, 3바이트 한글, 소트(차례짓기)가 가능한 한글 코드 체계 개념이 알려짐

  N 바이트 조합형은 시작 부호(SO : Shift Out)와 끝 부호(SI : Shift In)를 찾고 나서 한글 내용을 살펴야 해서 번거로움이 컸다. 커서를 움직여 이미 넣은 한글을 고치는 기능을 구현하기 어려웠고, 글꼴 처리가 정교하지 못하여 화면에 나오는 글씨는 타자기 글씨에 가까웠다. N 바이트 조합형은 명령줄 기반 환경(터미널 환경)에서 주로 쓰였고, 워드프로세서에는 거의 쓰이지 않았다.

N 바이트 조합형과 3바이트 조합형으로 부호값 매기기
[그림 10-1] N 바이트 조합형과 3바이트 조합형으로 부호값 매기기

  3바이트 조합형은 한글의 첫소리 · 가운뎃소리 · 끝소리를 각각 1바이트로 나타내는 방식이다. 겹낱자까지 모두 1바이트로 나타내면서, 빈 낱자 자리에는 채움값을 넣었다. N 바이트 조합형보다는 한글을 분석하고 처리하기 쉬운 꼴이어서 8비트 환경의 한글 워드프로세서(문서 편집 프로그램)에 많이 쓰였다. '중앙한글'을 비롯한 워드프로세서들에 쓰인 3바이트 조합형은 시작-끝 기호를 붙이지 않고 낱자 차례가 첫소리-가운뎃소리-끝소리로 일정하여 N 바이트 조합형보다 한글 처리가 쉬운 꼴이었다. 하지만 한글을 나타내는 기억 공간이 많이 드는 것은 N 바이트 조합형보다 나아지지 않았다.

  불편하거나 만족스럽지 않은 점이 있었어도 N 바이트 조합형이나 3바이트 조합형을 한동안 써야 했던 까닭은 8비트 컴퓨터 기종들의 한계에 있었다. 8비트 기종들은 CPU의 주소 처리 한계로 주기억 장치의 기본 용량이 많아야 64KB였으므로, 프로그램에 기능을 많이 담을 수 없고 한꺼번에 다룰 수 있는 글의 길이도 짧았다. 7비트 부호계를 쓰는 때에는 쓸 수 있는 부호값이 너무 적어서 영문 부호값을 한글을 나타내는 데에도 써야 했다.

  CALL 3327 한글에 쓰인 N 바이트 조합형은 그런 환경에서 쓸 수 있는 자원을 가장 쥐어짜서 하드웨어 한글 카드를 따로 쓰지 않고 한글을 나타내는 방안이었다. 3바이트 조합형을 쓴 한글Ⅲ이나 중앙한글 등도 하드웨어 장치를 따로 쓰지 않았다. 3바이트 조합형에서는 7비트 부호계보다 확장된 8비트 부호계를 바탕으로 더 나은 한글 처리 기술과 더 미려한 글꼴을 접목했지만, 8비트 기종의 기억 · 처리 능력에 발목 잡혀 한글 입출력 기능을 개발하고 누리는 것에 한계가 있었다.

  그래서 '바이덱스 한글'이나 'JJ 한영 터미널'처럼 하드웨어 한글 카드를 쓰는 방식도 등장했다. 한글 카드는 글꼴 정보 등을 카드의 롬(ROM) 칩(chip)에 담아서 프로그램이 쓰는 메모리 공간을 아끼고 한글 처리 속도를 높이는 구실을 했다.

  16비트 기종에서는 주기억 장치의 기본 용량이 128~640KB로 늘고 부호계를 16비트로 확장할 수 있는 길까지 열려 프로그램이 나타내고 처리할 수 있는 문자 수가 크게 늘었다. 16비트 환경에서 N 바이트 조합형과 3바이트 조합형은 거의 쓰이지 않았고, 더 적은 기억 공간으로 한글을 나타낼 수 있고 한글 처리가 더 손쉬운 2바이트 방식들(7비트 2바이트 완성형, 2바이트 조합형, 2바이트 완성형 등)이 주로 쓰였다.

▣ 8비트 기종에서 쓰일 수 있었던 조합형 한글 부호계

[표 10-1] 영문 로마 문자용 7비트 부호계
(SO: 확장 문자 시작, SI: 확장 문자 끝)
  8
7
6
5
0
0
0
0
0
0
0
1
0
0
1
0
0
0
1
1
0
1
0
0
0
1
0
1
0
1
1
0
0
1
1
1
4321   0 1 2 3 4 5 6 7
0000 0 NUL TC7 (DLE) SP 0 @ P ` p
0001 1 TC1 (SOH) DC1 ! 1 A Q a q
0010 2 TC2 (STX) DC2 " 2 B R b r
0011 3 TC3 (ETX) DC3 # 3 C S c s
0100 4 TC4 (EOT) DC4 $ 4 D T d t
0101 5 TC5 (ENQ) TC8 (NAK) % 5 E U e u
0110 6 TC6 (ACK) TC9 (SYN) & 6 F V f v
0111 7 BEL TC10 (ETB) ' 7 G W g w
1000 8 FE0 (BS) CAN ( 8 H X h x
1001 9 HT EM ) 9 I Y i y
1010 A LF SUB * : J Z j z
1011 B VT ECS + ; K [ k {
1100 C FF IS4 (FS) , < L \ l |
1101 D FE5 (CR) IS5 (GS) - = M ] m }
1110 E SO IS6 (RS) . > N ^ n ~
1111 F SI IS7 (US) / ? O _ o DEL

  N 바이트 조합형은 흔히 아스키 코드(ASCII code: American Standard Code for Information Interchange, 미국 정보 교환 표준 부호계)로 불리는 7비트 부호계(표 10-1)에 얹혀 쓰였다. 7비트 부호계는 한글 낱자를 따로 둘 공간이 넉넉하지 않았다. 그래서 확장 문자의 시작과 끝을 알리는 기호(SO, SI)를 앞뒤에 붙이고 영문이나 기호를 나타내는 부호값을 써서 한글을 나타내는 방법도 쓰였다.

[표 10-2] 7비트 조합형 부호계
(자판 배열 대응형) (33개 낱자)
  8
7
6
5
0
0
0
0
0
0
0
1
0
0
1
0
0
0
1
1
0
1
0
0
0
1
0
1
0
1
1
0
0
1
1
1
4321   0 1 2 3 4 5 6 7
0000 0       0 @    
0001 1     ! 1    
0010 2     " 2    
0011 3     # 3    
0100 4     $ 4    
0101 5     % 5    
0110 6     & 6    
0111 7     ' 7    
1000 8     ( 8    
1001 9     ) 9    
1010 A        
1011 B     [    
1100 C     , \    
1101 D     ]    
1110 E SO   . ^    
1111 F SI   / ?      
[표 10-3] 7비트 조합형 부호계
(33개 낱자)
  8
7
6
5
0
0
0
0
0
0
0
1
0
0
1
0
0
0
1
1
0
1
0
0
0
1
0
1
0
1
1
0
0
1
1
1
4321   0 1 2 3 4 5 6 7
0000 0       0 @ P
0001 1     ! 1 A Q
0010 2     " 2 B R
0011 3     # 3 C S
0100 4     $ 4 D T
0101 5     % 5 E U
0110 6     & 6 F V
0111 7     ' 7 G W
1000 8     ( 8 H X
1001 9     ) 9 I Y
1010 A     * : J Z
1011 B     + ; K [
1100 C     , < L \
1101 D     - = M ]
1110 E SO   . > N
1111 F SI   / ? O  

  표 10-2은 표준 두벌식 배열(KS C 5715)과 영문 쿼티 배열에 그대로 대응시킨 CALL 3327 한글(그림 10-2)의 7비트 한글 부호계이다.주2 이런 한글 부호계는 프로그램 내부에서 자판 배열을 처리하기에는 편한 꼴이지만, 부호값으로 한글 내용의 낱자 차례(ㄱ,ㄴ,ㄷ 차례)로 맞출 수 없고 ㅃ처럼 특수 기호의 부호값으로 나타내는 낱자를 파일 이름 등에 쓰지 못하는 제약이 걸릴 수 있다.

  그래서 한글 정보를 주고받기에 더 알맞은 한글 부호계는 표 10-3과 같은 꼴이다. 표 10-3의 한글 부호계를 쓰면 한글 낱자들이 자판 배열에 얽매이지 않고 낱자 차례대로 놓여 있어서 한글 차례짓기를 할 수 있고, 파일 이름 등에 한글을 넣는 때에 걸리는 문자 제약주3에서 좀 더 자유로울 수 있다.

CALL 3327 한글의 자판 배열
[그림 10-2] CALL 3327 한글의 자판 배열

  CALL 3327 한글로 쓰인 N 바이트 조합형에서 부호값을 매킨 한글 낱자의 수는 33개였다. 하지만 그림 10-3에 보이는 CALL 3327 한글의 패턴 배치표처럼 프로그램 내부에서는 글꼴을 세밀하게 나타내기 위해 ㄳ 같은 겹받침이 더 들어간 부호계가 따로 쓰일 수 있었다.

[표 10-4] 7비트 조합형 부호계
(51개 낱자 + 채움 문자)
  8
7
6
5
0
0
0
0
0
0
0
1
0
0
1
0
0
0
1
1
0
1
0
0
0
1
0
1
0
1
1
0
0
1
1
1
4321   0 1 2 3 4 5 6 7
0000 0         (채움)    
0001 1            
0010 2        
0011 3        
0100 4        
0101 5        
0110 6        
0111 7        
1000 8            
1001 9            
1010 A        
1011 B        
1100 C        
1101 D          
1110 E SO        
1111 F SI          

  표 10-4에 담긴 7비트 조합형 부호계는 KS C 5601(현재의 KS X 1001)에 '7단위 한글 자모용 부호'라는 이름으로 실린 표준 부호계이다.주4 채움 문자가 있고 겹낱자를 다 갖추고 있어서, '첫+가+끝' 차례로 한글 낱자를 이어 붙이는 3바이트 조합형의 한글 부호계로 쓸 수 있다. 그러나 쓸 수 있는 부호값의 범위가 제한되는 때에는 표 10-3의 부호계보다 한글을 나타내는 것에 제약을 더 받으므로, 초기 컴퓨터 환경에서 이 부호계가 널리 쓰이기는 어려웠다.

[표 10-5] 8비트 조합형 부호계 (51개 낱자 + 채움 문자)
  8
7
6
5
0
0
0
0
0
0
0
1
0
0
1
0
0
0
1
1
0
1
0
0
0
1
0
1
0
1
1
0
0
1
1
1
1
0
0
0
1
0
0
1
1
0
1
0
1
0
1
1
1
1
0
0
1
1
0
1
1
1
1
0
1
1
1
1
4321   0 1 2 3 4 5 6 7 8 9 A B C D E F
0000 0       0 @ P ` p         (채움)    
0001 1     ! 1 A Q a q            
0010 2     " 2 B R b r        
0011 3     # 3 C S c s        
0100 4     $ 4 D T d t        
0101 5     % 5 E U e u        
0110 6     & 6 F V f v        
0111 7     ' 7 G W g w        
1000 8     ( 8 H X h x            
1001 9     ) 9 I Y i y            
1010 A     * : J Z j z        
1011 B     + ; K [ k {        
1100 C     , < L \ l |         ㅣ 
1101 D     - = M ] m }          
1110 E SO   . > N ^ n ~          
1111 F SI   / ? O _ o              

  표 10-5은 8비트로 확장된 부호계를 쓰는 환경에서 쓸 수 있는 한글 부호계이다.주5 주6 이 부호계에서 한글 낱자들이 들어간 자리에는 문화권마다 다른 문자를 넣어 쓸 수 있다. 이를테면 영어권이 아닌 유럽 나라들은 Ç처럼 영문에 쓰이지 않는 로마 문자들을 8비트 확장 영역에 넣어 쓸 수 있다.

  7~8비트 부호계가 쓰인 8비트 기종에서는 쓸 수 있는 부호값이 적고 기억 · 처리 용량에서 제약을 받는 데다가 한글 처리 기술도 미숙했다. 그래서 표 10-3 ~ 10-5처럼 깔끔한 한글 부호계는 널리 쓰이지 못했고, 표 10-2처럼 특정한 자판 배열에 맞춘 한글 부호계가 쓰이는 때가 더러 있었다.

  만약 표 10-5의 부호계처럼 한글 낱자들을 부호계에 우선하여 배치하면서 끝닿소리(받침) 부호값을 따로 둔다면, 시작-끝 기호를 붙이지 않으면서 부호값 운용 규칙이 단순한 한글 부호계가 나올 수 있다. 이 점은 나중에 3벌식 한글 부호계인 '첫가끝 부호계'가 나오는 실마리가 되었다.

  2바이트(16비트) 확장 부호계를 쓰인 16비트 이상 컴퓨터 기종에서는 8비트 기종에서보다 쓸 수 있어서 쓸 수 있는 부호값이 크게 늘어났다. 그 덕분에 낱자만이 아니라 낱내자마다 부호값을 붙인 한글 부호계가 흔히 쓰일 수 있었다.

 ▣ N 바이트 조합형 : CALL 3327 한글, 바이덱스 한글, 멋한글

  이른바 'CALL 3327 한글'은 1981년에 8비트 기종인 애플 Ⅱ에 쓰인 프로그램이고, 개발한 사람은 '류백현'이다. CALL 3327은 애플 베이직에서 한글을 쓰기 위해 CALL 3327이라는 명령문을 수행해야 했기 때문에 붙은 이름이다.주7

  월간 《마이크로소프트웨어》에 실린 기사 「CALL 3327 한글 소스 리스트」에서는 "류백현씨가 KSI(후에 KSI, 엘렉스, 삼보엔지니어링 3사가 합병하여 현재의 삼보컴퓨터가 되었다)의 연구원으로 일을 때 동료 연구원인 김희용씨의 도움을 받아 완성한 것이다.(김희용씨는 현재 동양화학 자동화사업부에 근무하고 있다.) 따라서 3327한글의 소유권은 삼보컴퓨터에 속하게 되었다."고 하였다. 그리고 큐닉스에서 개발한 한글 프린트 모듈이 3327 한글을 치원하자 많은 프로그램에서 3327 한글을 쓰게 되었다고 한다.주8

  CALL 3327 한글은 복제 방지 기술을 쓴 상업용 프로그램이었지만, 강력한 복제 프로그램 도구(COPY Ⅱ Plus 등)가 등장한 데다가 큐닉스에서 이 방식을 지원하는 프린터 모듈을 보급한 통에 누구나 복제해 쓰는 퍼블릭 도메인(public domain) 소프트웨어처럼 되었다고 한다. 원 제작자를 모르던 마이크로소프트 쪽에서 수소문하여 소유자(삼보컴퓨터)와 개발자(류백현)가 누구인지를 밝혔고,주9 《마이크로소프트웨어》 1986년 6월호에 실린 특집 기사 「CALL 3327 한글 소스 리스트」를 통하여 김홍배(삼보컴퓨터 개발실)가 주석을 더 상세하게 붙여 작성한 중간 버전 소스 프로그램이 공개되었다.주10

CALL 3327 한글의 소스가 실린 《마이크로소프트웨어》 기사 (1986.10.)
[그림 10-3] CALL 3327 한글의 소스가 실린 《마이크로소프트웨어》 기사 (1986.10.)
CALL 3327 한글의 개선판인 '멋한글'을 구동한 화면 (움직그림)
[그림 10-4] CALL 3327 한글의 개선판 '멋한글' (움직그림)

  '바이덱스 한글'과 '멋한글'은 CALL 3327 한글의 소스가 공개된 뒤에 나온 개선판이다.

  '바이덱스 한글'은 한글 정보를 롬(ROM)에 담은 한글 카드(바이덱스 카드)를 써서 한 화면에서 쓸 수 있는 한글 분량을 늘리고 화면 표시 속도를 높혔다. CALL 3327 한글은 한 화면에 20×12자를 쓸 수 있었는데, 바이덱스 한글은 '가' 꼴을 한 줄에 40자까지 '고' 꼴을 한 줄에 80자까지 나타내는 식으로 (40~80)×12자를 나타낼 수 있게 하였다. 백스페이스(뒷걸음쇠) 기능과 줄 편집기(라인 에디터) 기능이 더 들어갔다.주11

  바이덱스 한글에 이어서 나온 '멋한글'은 하드웨어 카드를 쓰지 않은 프로그램이다. 그림 10-4에 보이는 멋한글을 살피면, 한글 처리 방식에서 다음과 같은 특징들을 볼 수 있다.

  • 입력 방식
    • Ctrl + k로 한글을 넣을 수 있는 상태로 들어감
    • Ctrl + a로 영문 상태가 됨
      • 조합하던 한글은 조합을 마침
      • 영문은 대문자만 넣을 수 있음
    • 영문 조합 상태일 때와 한글 조합 상태일 때의 커서 모양이 다름
    • 된닿소리 ㄲ · ㄸ · ㅃ · ㅆ · ㅉ은 그림 10-2 배열에 따라 기호 자리에서 넣음
    • ㄲ, ㅆ을 뺀 겹받침들은 2타에 넣음
    • 요즘낱자(첫소리 19개, 가운뎃소리 21개, 끝소리 27개)로 조합할 수 있는 한글 낱내자를 모두 나타낼 수 있음
  • 글꼴 처리
    • 한글의 세로폭이 영문의 2배임
    • 홀소리 낱자를 2벌을 둔 4벌식 타자기에 가까운 글꼴임
    • ㅏ · ㅐ · ㅑ · ㅒ · ㅓ · ㅔ · ㅕ · ㅖ · ㅣ가 붙을 때
      • 받침이 있을 때와 없을 때에 이들 홀소리의 길이가 다름
      • 한글의 가로폭과 영문의 2배가 됨
      • 겹받침의 폭이 달라짐
        - '옮'에 들어가는 ㄻ과 '닮'에 들어가는 ㄻ이 폭이 다름
    • 끝소리인지 첫소리인지 판가름하지 못한 닿소리 낱자는 다음 낱내 자리에 찍음
      (요즈음의 도깨비불 방식과 다름)
  • 뒷걸음쇠(Backspace)로 글 지우기
    • 조합이 끝나지 않은 낱자는 낱자 단위로 지울 수 있음
    • 조합이 끝난 한글은 영문 폭만큼 지워짐
    • 같은 세로줄에 들어간 닿소리와 홀소리는 지워질 때에도 함께 지워짐
    • 폭이 넓은 '닮', '하' 등은 조합이 끝난 뒤에 지우려면 뒷걸음쇠를 2번 눌러야 함
  • 글 고치기
    • 한글 상태에서 화살 글쇠를 써서 커서를 움직이면 한글이 지워짐
    • 영문 상태에서 화살 글쇠를 쓰면 커서를 움직일 수 있지만, 한글 내용을 고치거나 지나가면 영뚱한 곳이 바뀌거나 글이 깨질 수 있음
      (한글 편집 기능은 거의 쓰기 어려움)

▣ 3바이트 조합형 : 한글 Ⅲ, 중앙한글

'중앙한글'로 한글 넣고 지우기 (움직그림)
[그림 10-5] '중앙한글'로 한글 넣고 지우기 (움직그림)

  3바이트 조합형이 쓰인 '한글 Ⅲ'은 '정재열'이 운영한 캐나다 회사인 재 콘설턴트(JAE Consultant)에서 애플 기종에서 쓸 수 있게 개발한 워드프로세서(컴퓨터용 소프트웨어)이다.

  '중앙한글'은 '한글 Ⅲ'을 바탕으로 하여 한글 글꼴 기능 등을 개선한 프로그램이다. 개발자인 '이충수'는 '중앙대학교'을 다니던 때에 프로토 타입(시제품)을 만들었고, 중앙대학교 전자과 교수 '김정기'가 이를 보고 상품화하면 좋겠다고 하여 '중앙한글'이라 이름지었다. 본래 판매하려 했으나 복제 방지 장치가 풀려 널리 퍼졌고, 월간지 《마이크로소프트웨어》에 기사를 내면서 공개 소프트웨어로 공개하고 소스도 공개하였다고 한다.주12

  한글 Ⅲ과 중앙한글은 한글과 함께 영문과 기호까지 3바이트로 처리했다. 영문과 기호는 첫째 바이트와 셋째 바이트에 각각 $FF와 $00을 넣고 두째 바이트에 본래 부호값을 넣었다.(그림 10-1) 일관되게 3바이트로 문자들을 처리하므로 기억 공간은 많이 들지만 한글을 다루는 처리가 쉬워진다. 네모꼴 글꼴 처리를 위해 같은 한글 낱자를 글씨 모양에 따라 부호값을 다르게 나타냈다. 그래서 가, 강, 구, 귀, 그, 글, 익에 들어가는 'ㄱ'의 부호값이 모두 달랐다. 글씨꼴에 따라 같은 낱자에 다른 부호값을 매긴 것은 '기형적'이라는 평가도 받을 만큼 보기 드문 한글 부호계의 모습이었다.주13

▣ 첫가끝 갈마들이의 원조? - 'JJ 한영 터미널'의 3소자 입력 방식

  'JJ 한영 터미널'이라는 이름으로 나온 한글 카드는 미국에서 활동한 과학자 이병철이 개발하여 1985년에 8비트 애플 기종 컴퓨터에 쓸 수 있게 만든 상품이다.주14 이 한글 카드는 3바이트 조합형에 바탕한 '3소자 음절 입력 방식'이라는 특이한 한글 입력 방식으로 쓰였다. 한 글쇠로 넣을 수 있는 낱자를 2~3개씩 두어서 한글 낱자를 넣는 차례에 맞추어 때에 따라 다른 낱자가 들어가게 하였다.

  아래 표는 월간 《컴퓨터학습》 1987년 2월호에 실린 「기획특집 ― 한글과 컴퓨터 (PC에서의 한글 구현)」에 실린 것을 옮긴 것이다.

[표 10-6] JJ 한글의 글쇠값/부호값 대응표
아스키
부호
시스템 부호 글쇠 대응 부호
A 채움 채움 채움  
B    
C
D
E
F
G
H
I  
J
K
L
M   ㄵ,ㄿ
N   ㄶ,ㅀ
O  
P  
Q  
R  
S  
T  
U    
V    
W    
X    
Y        
Z      
{          
/          

  JJ 한글은 영문과 기호를 나타내는 부호값으로 한글을 나타낸다. 표 10-5에서 '시스템 부호'는 컴퓨터 내부의 문자 처리기가 한글을 기록할 때 쓰는 내부 부호값을 나타내고, 글쇠 부호는 영문 쿼티 자판을 기준으로 한글 낱자가 글쇠 자리와 짝지어지는 자판 배열을 나타낸다. 표 10-5에 따라 JJ 한글에서 한글 낱자들이 대응되는 글쇠 자리를 나타내면 아래와 같다.

JJ 한글 카드에 쓰인 자판 배열
[그림 10-6] JJ 한글에 쓰인 자판 배열

  영문 쿼티 자판을 기준으로 kkk로 K 자리 글쇠를 3번 거듭 누르면 ㅃ-ㅏ-ㅄ이 차례로 들어가서 '빲'이 조합된다. dsd를 치면 '왕'이 들어가고 dss를 치면 '완'이 들어간다. dhk를 치면 '와'가 아니라 '옶'이 들어간다.

  JJ 한글은 대체로 윗글쇠를 쓰지 않고 1벌 낱자를 1타에 넣되, ㅀ 또는 ㄿ만 예외로 윗글쇠를 함께 눌러 넣게 하였다.주15 낱자를 넣는 차례를 이용하여 윗글쇠를 쓰지 않고 모아쓰는 한글을 넣게 한 것은 1995년에 신광조가 개발하여 '신세벌식 자판'으로 선보인 '첫가끝 갈마들이'의 선조 격으로 볼 수 있다.

신세벌식 자판 원안 배열표 (1995, 신광조)
[그림 10-7] 신세벌식 자판 원안 배열표 (1995, 신광조)

  공세벌식 자판은 첫소리와 끝소리를 다른 글쇠에 놓는 3벌식 자판이면서 겹홀소리를 만드는 ㅗ · ㅜ를 따로 더 둔 것이 특징이다. 신세벌식 자판은 공세벌식 자판의 한글 배열 특징을 받아들였지만, 한글 낱자들이 더 규칙성을 띠는 자리에 들어가고 겹낱자 수가 줄어 바탕으로 삼은 공세벌식 자판보다 한글 배열이 간결하다. 3벌식 자판답게 받침을 넣을 때에 사이띄개를 쓰는 동작을 따로 할 필요가 없고, 모아쓰기로 요즘한글 낱내자를 넣을 때에는 윗글쇠를 누르는 동작을 하지 않아도 된다.주16

  하지만 JJ 한글의 3소자 입력 방식은 신세벌식 자판처럼 수동 전환 동작이 없는 갈마들이 방식이 아니었다. 한글 낱자를 넣는 차례에 따라 2벌식 한글 배열로 윗글쇠를 덜 쓰는 3벌식 한글 입력 체계를 꾸린 것은 남달랐지만, 받침이 없는 때에 사이띄개를 눌러 채움 문자를 넣는 수동 전환 동작을 햐야 했다. 잘 알려진 두벌식 한글 배열을 이용한 JJ 한글은 첫닿소리와 끝닿소리를 가리는 문제를 다 넘지 못하였고, 겹낱자도 많이 들어가서 바탕으로 삼은 두벌식 배열보다 복잡한 한글 배열이 되었다.

  'JJ 한영 터미널'을 개발한 이병철은 외국산 소프트웨어에 일일이 한글을 심기에는 비용이나 시간이 많이 들고 국내 소프트웨어 시장이 좁으므로, 영어 문화권에서 제작된 컴퓨터와 소프트웨어를 전혀 고치지 않고 한글을 올려(얹어) 쓰자는 주장을 펼쳤다. 그런 논리의 결과물인 JJ 한글은 첫가끝 갈마들이의 시조 격으로 보이는 독특한 발상이 담겨 있어서 더 응용해 볼 구석이 있었다. 하지만 JJ 한글도 2바이트 방식이 주로 쓰인 16비트 환경으로는 이어지지 못했다.

2) 1980년대에 나온 한글 조합 방식과 한글 부호계

  컴퓨터 기종이 8비트 기종에서 16비트 기종으로 넘어갈 무렵에는 그야말로 각양각색의 한글 부호계와 한글 조합 방식이 쓰였다. 한글 조합 방식은 크게 완성형과 조합형으로 나뉘었다. 조합형은 2바이트 조합형이 주류였고, 완성형은 7비트 부호계에 바탕한 2바이트 방식과 ISO 2022의 부호계 확장법을 따르는 2바이트 방식으로 갈렸다. 16비트 기종에서 널리 쓰이는 한글 부호계들은 2바이트 방식을 쓰는 것에 공통점이 있고, 2바이트 방식은 8비트 기종에서는 기억 장치의 용량 한계로 쓰일 수 없었던 한글 표현 방식이다.

  7비트 2바이트 완성형은 청계천 주변 조립 상가에서 많이 팔려서 흔히 '청계천 카드'로 흔히 불린 한글 바이오스 카드 제품들에 많이 쓰였다. 7비트 부호계를 써야 하는 환경에서 잘 쓰이지 않는 아스키 문자 조합을 이용하여 2바이트로 한글 낱내자 하나를 나타내는 방식이었다.

  2바이트 조합형과 2바이트 완성형은 ISO 2022을 따르는 2바이트 확장 부호계에서 쓰였다. ISO 2022의 부호계 확장법을 따른다면, 부호값의 맨 첫 비트(msb, 최상위 비트)가 0이면 1바이트 부호값이 되고 1이면 2바이트 부호값이 된다. 한글은 2바이트(16비트)에서 맨 첫 비트를 뺀 15비트 부호값으로 한글을 나타냈다. 한글을 분석하려면 앞뒤 부호값을 살펴야 하는 N 바이트 조합형이나 3바이트 조합형과 달리, 2바이트 조합형과 2바이트 완성형은 부호값 하나가 한글 낱내자 하나에 대응되므로 낱내자 단위로 한글을 분석하고 처리하기 쉽다.

ISO 2022을 따르는 부호계 확장
[그림 10-8] ISO 2022을 따르는 부호계 확장

  2바이트 완성형은 낱자 단위 한글 처리를 헤아리지 않는 방식이었다. 행정 전산망에 쓰이기 시작하여 1987년에 나온 'KS C 5601-1987'을 통하여 표준 규격이 된 'KS 완성형'이 2바이트 완성형의 대표 주자였다.

  2바이트 조합형은 15비트를 셋으로 나누어서 한글 낱내자를 이루는 3벌 낱자들에 값을 매기는 방식이었다. 3바이트 조합형과 원리가 비슷한 2바이트 조합형은 민간 시장에서 주로 쓰였고 부호계의 종류가 가장 많았다.

2바이트 조합형 한글 부호계의 첫가끝 낱자 부호값 구성
[그림 10-9] 2바이트 조합형 한글 부호값의 첫가끝 낱자 비트 구성

  1987년 이후의 주된 산업 표준은 2바이트 완성형인 'KS 완성형'이었지만, 7비트 2바이트 완성형과 2바이트 조합형도 시장에서 함께 쓰였다. 2바이트 조합형 부호계들은 부호계를 제품에 쓴 기업들의 이름을 따서 상용 조합형(삼보 조합형), 금성 조합형, 삼성 조합형 등으로 불렸다.

[표 10-7] 1980년대에 많이 쓰인 한글 조합 방식
구분 종류 특징 쓰인 곳
N바이트
조합형
  • 닿소리/홀소리로 나눈 2벌식 부호계임
 - 첫닿소리, 끝닿소리를 같은 부호값으로 나타냄
 - '닿홀 조합형'으로도 불림주17
• 최상위 비트(msb)를 쓰지 않음
• 한글 내용의 시작, 끝에 SI, SO를 붙임
• 낱내자의 낱자들을 2~5바이트로 나타냄
8비트 기종
• CALL 3327 한글
• 바이덱스 한글
• 멋한글
3바이트
조합형
  • 낱내자를 나타내는 크기가 3바이트임
• 겹낱자도 1바이트로 나타냄
• 채움 부호(fill code)로 빈 낱자를 채움
• 변칙을 두지 않는다면 2벌식 부호계를 씀
• 운용 방법에 따라 한글 내용의 시작,
 끝을 알리는 기호가 필요할 수도 있음
8비트 기종
• 한글 Ⅲ
• 중앙 한글
• JJ 한영 터미널
7비트
2바이트
완성형
대우 7비트
옴니 7비트
청계천 7비트
• 잘 쓰이지 않는 아스키 부호값 조합을 이용함
 - 영문 소+대문자 또는 기호 조합
 - 'dBASE'가 '늦ASE'로 나타남
• 1300~1600개 한글 완성자를 나타냄
 (+ 한글 낱자 51개)
• 최상위 비트(msb)를 쓰지 않음
• 청계천 한글 카드
2바이트
조합형
금성 조합형
삼성 조합형
상용 조합형
• 한글 완성자 11172개를 나타냄
• 미완성 한글 낱내자 1147개를 나타냄
• 낱내자마다 2바이트 부호값을 매김
• 3벌식 체계를 따르는 한글 부호계를 씀
 - 낱자를 겹낱자까지 5비트로 나타냄
• 도스 프로그램
• 일부 사설 BBS
2바이트
완성형
KS 완성형 • KS C 5601-1987에 실린 표준 부호계
 (현재의 KS X 1001와 EUC-KR)
• 한글 완성자 2350개를 나타냄
• 낱내자마다 2바이트 부호값을 매김
• 행정 전산망(행망)
• 행망 지원 프로그램
• 도스 프로그램
• 윈도우 3.×, 95 한글판
• 다수 BBS

  이렇게 다양하게 쓰인 한글 조합 방식들에는 저마다 좋은 점과 아쉬운 점이 있었다.

  N 바이트 조합형과 일부 3바이트 조합형은 한글 정보의 시작과 끝을 알리는 기호를 살펴야 하는 것에 따르는 번거로움이 컸다. 한글 차례짓기 기능을 구현하기가 쉽지 않았고, 영문과 한글이 차지하는 기억 공간의 크기 비율이 화면에 나타내기 좋은 글씨 크기 비율(1:2)과 맞지 않아서 영문 프로그램에 한글 입출력 기능을 덧붙이는 방식으로 개발하기가 쉽지 않았다. 프로그램 개발자에게는 두 방식이 다루기 까다로웠고, 한글이 차지하는 기억 공간이 커서 긴 글을 편집하기에 불리했다.

  2바이트 방식은 영문과 한글이 차지하는 기억 공간의 비율(1:2)이 화면에 나타내는 글씨 크기 비율과 맞아떨어져서 영문 환경에 맞추어진 프로그램에 한글 입출력 기능을 덧붙이기 편리했다. 2바이트 조합형과 2바이트 완성형은 한글을 낱내자 단위로 나타내는 2바이트 기억 공간이 확장 부호계 차원에서 처리되므로, 다른 방식들보다 한글 처리가 훨씬 손쉬워서 한글 프로그램 개발자들이 선호했다. 하지만 세부 종류들을 살피면 2바이트 방식들에는 저마다 아쉬운 점이 있었다.

  7비트 2바이트 완성형은 최상위 비트(msb)를 한글을 나타내는 데에 쓰지 않아서 최상위 비트를 홀짝(패리티) 검사에 쓰는 영문 프로그램과 통신망에서 쓰기 좋았다. 하지만 'aY', 'x/'처럼 잘 쓰이지 않는 아스키 문자 조합을 편법으로 이용하는 방안이어서 'dBASE'가 '늦ASE'로 나타나는 것과 같은 문제가 일어났다. 낱자 분석을 하기 쉬운 꼴이 아니고, 나타낼 수 있는 한글 낱내(음절)의 수는 1600개 이내였다. 한자를 쓰지 못했고 프린터 생산 업체들이 지원하지 않은 방식이기도 했다.

  2바이트 조합형은 요즘한글에 쓰이는 요즘낱자 67개(첫소리 19개 + 가운뎃소리 21개 + 끝소리 27개)로 조합할 수 있는 11172개 낱내 완성자를 모두 나타낼 수 있다. 2바이트 조합형은 부호값만으로 낱자 정보를 분석할 수 있어서 민간 시장에서 프로그램 개발자들이 가장 선호한 한글 조합 방식이었다. 하지만 한글이 차지하는 부호값의 수가 많아서 도형 문자나 메타 문자가 깨지거나 통신 제어 부호와 부딪히는 문제와 씨름해야 했다. 2바이트 조합형이 안고 있는 문제는 그 무렵의 전산 · 통신 환경에서 완벽한 해결책이 나올 수 없었다. 다급하지 않은 요소를 일부 포기하고 꼭 필요한 요소에 집중하여 고쳐 만든 부호계가 자꾸 나오는 바람에 2바이트 조합형은 부호계 가짓수가 유난히 많았다.

  KS 완성형은 한글을 나타내는 앞뒤 바이트의 맨 앞 비트가 언제나 0이 되게 하여 한글을 나타내는 부호값이 메타 문자나 통신 제어 부호로 잘못 읽힐 가능성을 미리 막았다. 이 때문에 KS 완성형은 통신 환경에서 쓰기에 알맞았지만, 한글 낱내 완성자를 2350개밖에 나타내지 못하는 것이 큰 약점이었다.

  이처럼 1980년대에 쓰인 한글 조합 방식들에는 두드러진 약점이 적어도 하나씩은 있었고, 모든 면에서 약점이 없는 한글 표현 방식은 없었다. 한글을 나타내는 문자 부호계가 대체로 운영체제나 통신망에서도 함께 쓰였기 때문에 프로그램에 쓰이는 메타 문자나 통신에 쓰이는 제어 부호를 피하는 것에도 신경 써야 했다. 또한 16비트 기종에서 한글 입출력 프로그램을 만들던 개발자들은 한글 처리가 편하고 기억 공간을 가장 적게 쓰는 2바이트 방식에서 벗어나기 어려웠다. 이 때문에 한글 조합 폭이 넓으면서 한자를 넣을 공간도 많고 통신망에 쓰기에도 좋은 한글 부호계는 쓰일 수 없었다.

  그래서 민간 시장에서는 그때그때의 필요와 형편에 따라 한글 부호계를 고쳐 쓰는 일이 거듭되었다. 날이 갈수록 가짓수가 늘어나는 한글 조합 방식과 한글 부호계는 컴퓨터로 한글 정보를 주고 받는 일을 번거롭게 했다. 개인용 컴퓨터(PC) 시장에 뛰어든 큰 기업들은 자신들이 바꾼 한글 부호계를 내세웠고, 다른 기업이 만든 프로그램과의 호환에는 크게 신경 쓰지 않으며 힘겨루기를 하는 모습을 보였다. 문서 편집 프로그램마다 다른 한글 부호계가 쓰이고 사람마다 주로 쓰는 문서 편집 프로그램이 달랐으므로, 다른 곳에서 만든 문서를 보려면 한글 부호계를 바꾸는 작업을 따로 거쳐야 하는 때가 흔했다. 아래 글에 이런 상황이 잘 설명되어 있다.

  1980년대 후반은 개인용컴퓨터 제조회사마다 한글코드가 달라 사용자는 매우 불편했다. 특히 출판사나 조판소, 인쇄소는 적어도 5종류 이상의 제조회사가 다른 개인용 컴퓨터를 구비해놓아야 영업이 가능했다. 삼성컴퓨터, 금성컴퓨터, 삼보컴퓨터, 세운상가컴퓨터, 효성컴퓨터, 대우컴퓨터, 현대컴퓨터 등 컴퓨터 회사마다 다른 한글코드를 사용하므로 삼성컴퓨터로 만든 문서화일은 금성컴퓨터나 삼보컴퓨터의 모니터 화면으로 볼 수도 없고 프린터로 한글을 인쇄할 수도 없었기 때문이다. 컴퓨터를 여러 대 사기 힘든 개인이나 업소에서는 한글코드변환 프로그램을 별도로 구입해서 코드변환을 해야만 모니터나 프린터로 한글을 제대로 읽고 인쇄할 수 있었다.

이기성, 「한국 전자출판산업과 한글코드의 역사적 고찰」, 《출판논총》 제4권, 2014.8.

  1980년대 후반의 한글 문서 편집 프로그램들은 자체 형식 파일을 쓰지 않고 일반 텍스트 형식으로 문서 파일을 저장하는 경우가 꽤 있었다. 그래서 어느 프로그램에서 저장한 문서 파일을 다른 프로그램이 한글 부호계가 달라서 읽지 못한다면, '카멜레온'처럼 한글 부호계를 바꾸어 주는 프로그램을 써야 했다.

[표 10-8] 2바이트 조합형 한글 부호계
5비트
낱자값
1987
KS 조합형
상용 조합형
(KSSM)
삼성 조합형 금성 조합형 도깨비Ⅱ 조합형
0 00000             (채움)   (채움) (채움)   (채움) (채움)   (채움)
1 00001   (채움) (채움) (채움)   (채움) ᄀᅠ   ᅟᅠᆨ ᄀᅠ   ᅟᅠᆨ ᄀᅠ   ᅟᅠᆨ
2 00010   ᅟᅡ ᅟᅠᆨ ᄀᅠ (채움) ᅟᅠᆨ ᄁᅠ (채움) ᅟᅠᆩ ᄁᅠ ᅟᅡ ᅟᅠᆩ ᄁᅠ (채움) ᅟᅠᆩ
3 00011   ᅟᅢ ᅟᅠᆩ ᄁᅠ ᅟᅡ ᅟᅠᆩ ᄂᅠ ᅟᅡ ᅟᅠᆪ   ᅟᅢ ᅟᅠᆪ ᄂᅠ ᅟᅡ ᅟᅠᆪ
4 00100     ᅟᅠᆪ ᄂᅠ ᅟᅢ ᅟᅠᆪ ᄃᅠ ᅟᅢ ᅟᅠᆫ ᄂᅠ ᅟᅣ ᅟᅠᆫ ᄃᅠ ᅟᅢ ᅟᅠᆫ
5 00101   ᅟᅣ ᅟᅠᆫ ᄃᅠ ᅟᅣ ᅟᅠᆫ ᄄᅠ ᅟᅣ ᅟᅠᆬ   ᅟᅤ ᅟᅠᆬ ᄄᅠ ᅟᅣ ᅟᅠᆬ
6 00110   ᅟᅤ ᅟᅠᆬ ᄄᅠ ᅟᅤ ᅟᅠᆬ ᄅᅠ ᅟᅤ ᅟᅠᆭ   ᅟᅥ ᅟᅠᆭ ᄅᅠ ᅟᅤ ᅟᅠᆭ
7 00111   ᅟᅥ ᅟᅠᆭ ᄅᅠ ᅟᅥ ᅟᅠᆭ ᄆᅠ ᅟᅥ ᅟᅠᆮ ᄃᅠ ᅟᅦ ᅟᅠᆮ ᄆᅠ ᅟᅥ ᅟᅠᆮ
8 01000     ᅟᅠᆮ ᄆᅠ   ᅟᅠᆮ ᄇᅠ   ᅟᅠᆯ ᄄᅠ     ᄇᅠ   ᅟᅠᆯ
9 01001 (채움) ᅟᅦ ᅟᅠᆯ ᄇᅠ   ᅟᅠᆯ ᄈᅠ   ᅟᅠᆰ ᄅᅠ   ᅟᅠᆯ ᄈᅠ   ᅟᅠᆰ
10 01010 ᄀᅠ ᅟᅧ ᅟᅠᆰ ᄈᅠ ᅟᅦ ᅟᅠᆰ ᄉᅠ ᅟᅦ ᅟᅠᆱ   ᅟᅧ ᅟᅠᆰ ᄉᅠ ᅟᅦ ᅟᅠᆱ
11 01011 ᄁᅠ ᅟᅨ ᅟᅠᆱ ᄉᅠ ᅟᅧ ᅟᅠᆱ ᄊᅠ ᅟᅧ ᅟᅠᆲ   ᅟᅨ ᅟᅠᆱ ᄊᅠ ᅟᅧ ᅟᅠᆲ
12 01100 ᄂᅠ   ᅟᅠᆲ ᄊᅠ ᅟᅨ ᅟᅠᆲ ᄋᅠ ᅟᅨ ᅟᅠᆳ   ᅟᅩ ᅟᅠᆲ   ᅟᅨ ᅟᅠᆳ
13 01101 ᄃᅠ ᅟᅩ ᅟᅠᆳ ᄋᅠ ᅟᅩ ᅟᅠᆳ ᄌᅠ ᅟᅩ ᅟᅠᆴ   ᅟᅪ ᅟᅠᆳ   ᅟᅩ ᅟᅠᆴ
14 01110 ᄄᅠ ᅟᅪ ᅟᅠᆴ ᄌᅠ ᅟᅪ ᅟᅠᆴ ᄍᅠ ᅟᅪ ᅟᅠᆵ   ᅟᅫ ᅟᅠᆴ   ᅟᅪ ᅟᅠᆵ
15 01111 ᄅᅠ ᅟᅫ ᅟᅠᆵ ᄍᅠ ᅟᅫ ᅟᅠᆵ ᄎᅠ ᅟᅫ ᅟᅠᆶ   ᅟᅬ ᅟᅠᆵ   ᅟᅫ ᅟᅠᆶ
16 10000 ᄆᅠ   ᅟᅠᆶ ᄎᅠ   ᅟᅠᆶ ᄏᅠ   ᅟᅠᆷ     ᅟᅠᆶ     ᅟᅠᆷ
17 10001 ᄇᅠ ᅟᅬ ᅟᅠᆷ ᄏᅠ   ᅟᅠᆷ ᄐᅠ   ᅟᅠᆸ ᄆᅠ   ᅟᅠᆷ     ᅟᅠᆸ
18 10010 ᄈᅠ ᅟᅭ ᅟᅠᆸ ᄐᅠ ᅟᅬ   ᄑᅠ ᅟᅬ ᅟᅠᆹ ᄇᅠ ᅟᅭ ᅟᅠᆸ   ᅟᅬ ᅟᅠᆹ
19 10011 ᄉᅠ ᅟᅮ ᅟᅠᆹ ᄑᅠ ᅟᅭ ᅟᅠᆸ ᄒᅠ ᅟᅭ ᅟᅠᆺ ᄈᅠ ᅟᅮ     ᅟᅭ ᅟᅠᆺ
20 10100 ᄊᅠ   ᅟᅠᆺ ᄒᅠ ᅟᅮ ᅟᅠᆹ   ᅟᅮ ᅟᅠᆻ   ᅟᅯ ᅟᅠᆹ   ᅟᅮ ᅟᅠᆻ
21 10101 ᄋᅠ ᅟᅯ ᅟᅠᆻ   ᅟᅯ ᅟᅠᆺ   ᅟᅯ ᅟᅠᆼ ᄉᅠ ᅟᅰ ᅟᅠᆺ   ᅟᅯ ᅟᅠᆼ
22 10110 ᄌᅠ ᅟᅰ ᅟᅠᆼ   ᅟᅰ ᅟᅠᆻ   ᅟᅰ ᅟᅠᆽ ᄊᅠ ᅟᅱ ᅟᅠᆻ   ᅟᅰ ᅟᅠᆽ
23 10111 ᄍᅠ ᅟᅱ ᅟᅠᆽ   ᅟᅱ ᅟᅠᆼ   ᅟᅱ ᅟᅠᆾ ᄋᅠ ᅟᅲ ᅟᅠᆼ ᄋᅠ ᅟᅱ ᅟᅠᆾ
24 11000 ᄎᅠ   ᅟᅠᆾ     ᅟᅠᆽ     ᅟᅠᆿ ᄌᅠ   ᅟᅠᆽ ᄌᅠ   ᅟᅠᆿ
25 11001 ᄏᅠ ᅟᅲ ᅟᅠᆿ     ᅟᅠᆾ     ᅟᅠᇀ ᄍᅠ     ᄍᅠ   ᅟᅠᇀ
26 11010 ᄐᅠ ᅟᅳ ᅟᅠᇀ   ᅟᅲ ᅟᅠᆿ   ᅟᅲ ᅟᅠᇁ ᄎᅠ ᅟᅳ ᅟᅠᆾ ᄎᅠ ᅟᅲ ᅟᅠᇁ
27 11011 ᄑᅠ ᅟᅴ ᅟᅠᇁ   ᅟᅳ ᅟᅠᇀ   ᅟᅳ ᅟᅠᇂ ᄏᅠ ᅟᅴ ᅟᅠᆿ ᄏᅠ ᅟᅳ ᅟᅠᇂ
28 11100 ᄒᅠ   ᅟᅠᇂ   ᅟᅴ ᅟᅠᇁ   ᅟᅴ   ᄐᅠ ᅟᅵ ᅟᅠᇀ ᄐᅠ ᅟᅴ  
29 11101   ᅟᅵ     ᅟᅵ ᅟᅠᇂ   ᅟᅵ   ᄑᅠ   ᅟᅠᇁ ᄑᅠ ᅟᅵ  
30 11110                   ᄒᅠ   ᅟᅠᇂ ᄒᅠ    
31 11111                     (채움)        

  1980년대에는 이런저런 까닭들이 겹쳐 한글 부호계의 가짓수가 늘어 갔다. 컴퓨터 기종이 다르거나 한글을 다루는 프로그램이 다르면 다른 한글 부호계가 쓰이는 상황은 전산 환경에서 한글로 정보를 주고받는 일을 거북하게 했다. 이런 불편한 상황을 바꾸려면 표준 한글 부호계를 정하여 널리 쓰이는 한글 부호계를 되도록 하나로 합쳐야 했다. 하지만 서둘러 표준으로 정한 한글 부호계는 해결책이 되지 못했고, 오히려 미처 생각하지 못한 더 큰 문제들을 일으켰다.

▣ 2바이트 조합형을 쓴 프로그램들 - NKP, 한글 도깨비 Ⅱ, ᄒᆞᆫ글

NKP로 한글을 넣고 지우기 (움직그림)
[그림 10-10] NKP로 한글을 넣고 지우기 (움직그림)
한글 도깨비 Ⅱ로 한글을 넣고 지우기 (움직그림)
[그림 10-11] 한글 도깨비 Ⅱ로 한글을 넣고 지우기 (움직그림)

  1980년대 후반에 나온 'NKP'(개발사: 삼보컴퓨터)와 '한글 도깨비 Ⅱ'(개발자: 최철용)은 도스(DOS)의 명령줄 상태에 한글을 쓸 수 있게 해 준 '한글 바이오스' 프로그램들이다. 이 프로그램들은 옛 KS C 5715(KS X 5002)에 바탕한 표준 두벌식 자판을 지원했고, ISO 2022에 바탕한 확장 부호계가 쓰였다. 이들을 띄워 베이직이나 몇몇 워드프로세서(보석글 등)에서 한글을 쓸 수 있었다.

  위의 NKP를 띄운 화면에 보이는 것처럼 1980년대의 한글 바이오스 프로그램들은 명령줄 상태에서는 워드프로세서에서만큼 한글을 정교하게 처리하지 못하여 뒷걸음쇠(백스페이스)나 del 글쇠로 한글을 지우면 낱내의 반씩(1바이트씩) 지워지는 모습을 볼 수 있었다. NKP는 조합하고 있는 한글 낱내자의 낱자들을 왼쪽 화살 글쇠(←)를 눌러 지울 수 있었다. 2바이트 조합형을 쓰는 프로그램들에서는 KS 완성형으로 넣을 수 없는 '똠'을 넣을 수 있다.

도스판 ᄒᆞᆫ글 1.2로 한글을 넣고 지우기 (움직그림)
[그림 10-12] 도스판 ᄒᆞᆫ글 1.2로 한글을 넣고 지우기 (움직그림)

  한글 카드의 도움을 받지 않고 한글 처리를 빠르게 해낸 도스판 'ᄒᆞᆫ글'은 완숙기에 접어든 한글 조합 기술을 널리 알린 워드프로세서이다. 위 화면에서 보이는 한글 낱자를 조합해 나가는 방식, 한글에 커서가 달라붙는 방식, 한글을 지우는 방식은 오늘날에 흔히 쓰이는 것과 같다. 조합이 끝난 낱내자는 뒷걸음쇠나 del 글쇠를 눌러 낱내자 단위로 지울 수 있다. 이런 한글 조합 방식은 1990년대에 표준 방식처럼 퍼져서 한글 입출력 프로그램들에서 흔히 볼 수 있는 모습이 되었다.

  도스판 ᄒᆞᆫ글에는 상용 조합형 한글 부호계에 옛낱자를 더 넣은 '한컴 2바이트 조합형'이 쓰였다. 아스키 영역에 들어가는 문자들의 부호값까지 2바이트로 처리하여서, 다룰 수 있는 부호값의 수(최대 65536개)가 ISO 2022에 바탕한 확장 부호계(최대 256+32768개)보다 2배 가까이 많았다.

※ 참고한 자료

  • 「언제쯤이나 가능할까? 컴퓨터의 만족스런 한글처리」,  정보시대, 《마이크로소프트웨어》 1985. 11.
  • 「CALL 3327 한글 소스 리스트」, 정보시대, 《마이크로소프트웨어》 1986.6.
  • 박호용, 「바이덱스 한글」, 정보시대, 《마이크로소프트웨어》 1986.8.
  • 조병연, 「멋한글」, 정보시대, 《마이크로소프트웨어》 1986.9.
  • 이충수, 「중앙한글의 사용법」, 《마이크로소프트웨어》 1986.10.
  • 포니 아트, 「중앙한글의 분석」, 정보시대, 《마이크로소프트웨어》 1986.10.
  • 이찬진, 「한글의 소트와 검색」, 정보시대, 《마이크로소프트웨어》 1986.10.
  • 「기획 특집 - 한글과 컴퓨터 (PC에서의 한글 구현)」, 민컴, 《컴퓨터학습》 1987.2.
  • 김충회, 「국어 자료 처리를 위한 개인용 컴퓨터의 시스템 설치에 대하여」, 《국어생활》 제16호, 1989.1.
  • 박현철, 「한글 코드체계 그 알파와 오메가」, 정보시대, 《마이크로소프트웨어》 1989.3.
  • 김재원, 「KS 완성형과 조합형 한글 코드를 변환시키는 카멜레온」, 정보시대, 《마이크로소프트웨어》 1989.3.
  • 「현행 한글 코드의 문제점과 해결 방안」, 정보시대, 《마이크로소프트웨어》 1989.8.
  • 최은혁, 「한글과 컴퓨터의 만남」, 정보시대, 《마이크로소프트웨어》 1990.6.
  • 이주희, 「통신선 상에서 문제가 되는 한글 코드」, 정보시대, 《마이크로소프트웨어》 1990.08.
  • 류백현, 「컴퓨터 이야기 ― Apple을 생각하면서」, 삼보컴퓨터, 《삼보컴퓨터》 1990.10. (통권 제76호)
  • 이충수, 「컴퓨터 이야기 ― 세종대왕님, 감사합니다」, 삼보컴퓨터, 《삼보컴퓨터》, 1990.12. (통권 제 78호)
  • 이준희 · 정내권, 〈컴퓨터속의 한글〉, 정보시대, 1991.12.2.
  • 김경석, 「한글 부호계의 과거, 현재 그리고 미래 : '한글 제대로 지원하는 것은 첫가끝 조합형'」, 하이테크정보, 《하이테크정보》 제162호, 1996.2.20.
  • 이기성, 「한국 전자출판산업과 한글코드의 역사적 고찰」, 《출판논총》 제4권, 2014.8.
  • 기술표준원, 〈정보 교환용 부호계 (한글 및 한자) ― KS X 1001:1998〉, 한국표준협회, 《한국산업표준》, 1998.12.31. 개정, 1999.1.25. 발행
  • 문자 집합 위키 (http://ko.charset.wikia.com)
  • 프로그램 자료
    • 멋한글
      • 피씨클럽 / 이 재철, [한글] 멋-한글 마스터 디스켓 (일명: CALL3327 한글), APPLE ][ ®애플 컴퓨터 : 네이버 카페, https://cafe.naver.com/appleii/482
    • 중앙한글
〈주석〉
  1. 표 10-2과 그림 10-2을 따라 이 방식으로 그림 10-1의 사과꽃(ㅅㅏㄱㅗㅏㄲㅗㅊ)을 나타낸다면, SO와 SI 사이에 들어가는 부호는 tkrhk-hc이다. back
  2. 「한글의 소트와 검색」(이찬진, 정보시대, 《마이크로소프트웨어》, 1986.10.)에 표 10-2과 내용이 같은 한글 변환표가 실려 있다. back
  3. 파일 이름에 영문 대문자/소문자를 가리거나 특정 기호를 쓰지 못하는 제약이 있을 수 있다. back
  4. KS X 1001:1998에 실린 개정 내용 해설과 문자 집합 위키의 설명에 따르면, '7단위 한글 자모용 부호'(표 10-4)는 KS C 5601-1982에 규격 본문에 실렸는데, KS C 5601-1987에서는 한글 2350자를 담은 2바이트 완성형 부호계가 규격 본문에 실리면서 '7단위 한글 자모용 부호'는 부속서로 자리를 옮겼다고 한다. KS C 5601에서 이름을 바꾼 KS X 1001에도 같은 부호계가 부속서(부속서 4  7비트 낱자 부호계)로 실려 있다. back
  5. 표 10-5의 8비트 부호계는 「한글 표준안 코드에 관하여」(《마이크로소프트웨어》 1987.11.)에 실린 '8단위 로마 문자 밎 한글 자모용 부호'를 옮긴 것이다. back
  6. KS X 1001의 부속서 4에 '7비트 한글 낱자 부호계'라는 이름으로 표 10-5과 낱자 구성과 부호값이 같은 한글 부호계가 실려 있다. 받침이 빠진 곳에 채움 문자를 넣어서 낱내(음절, 소리마디)자 하나를 3바이트로 나타낼 수 있는 한글 부호계이다. (2019.7.25. 주석 더하여 넣음) back
  7. 이준희 · 정내권, 〈컴퓨터속의 한글〉, 20째 쪽, 정보시대, 1991.12.2. back
  8. 「CALL 3327 한글 소스 리스트」, 정보시대, 《마이크로소프트웨어》 1986.6. back
  9. 류백현, 「컴퓨터 이야기 ― Apple을 생각하면서」, 삼보컴퓨터, 《삼보컴퓨터》 1990.10. (통권 제76호) back
  10. 「컴퓨터 이야기 ― Apple을 생각하면서」에서는 CALL 3327 한글의 원 제작자를 '마이크로소프트'가 수소문했다고 한다. 「컴퓨터 이야기...」 기사에 나온 '마이크로소프트'는 이름 그대로 보면 약칭 'MS'로 불리는 기업 '마이크로소프트(Microsoft)'여야 맞지만, '정보시대'가 발행한 월간지 《마이크로소프트웨어》(Microsoftware)에서 취재한 것을 가리킨 것일 수도 있다. 한때 큐닉스와 마이크로소프트가 서로 손잡고 제품을 팔았고 그 사실을 광고에 실은 적도 있었던 터여서, 이름이 비슷한 프로그램 개발 회사 '마이크로소프트'와 월간지 《마이크로소프트웨어》'가 서로 연관이 있다고 알기 쉬웠던 것 같다. back
  11. 박호용, 「바이덱스 한글」, 정보시대, 《마이크로소프트웨어》 1986.8. back
  12. 이충수, 「컴퓨터 이야기 ― 세종대왕님, 감사합니다」, 삼보컴퓨터, 《삼보컴퓨터》, 1990.12. (통권 제 78호)] back
  13. 포니 아트, 「중앙한글의 분석」, 정보시대, 《마이크로소프트웨어》, 1986.10. back
  14. JJ는 쿼티 자판을 기준으로 J 자리 글쇠를 2번 눌러 한 · 영 상태를 바꾸는 것을 가리킨 이름이다. back
  15. M 자리와 N 자리에는 첫소리가 없고 홀소리와 겹받침만 있으므로, 이론상으로는 글쇠를 한 번 더 눌러서 ㅀ과 ㄿ이 들어가게 할 수 있는데, JJ 한글에는 그런 방법이 쓰이지 않았다. back
  16. 신세벌식 자판으로 낱자를 따로 넣거나 요즘한글에서 쓰이지 않는 옛한글 겹낱자를 조합할 때에는 윗글쇠를 누르는 동작이 필요할 수 있다. back
  17. 김경석, 「한글 부호계의 과거, 현재 그리고 미래 : '한글 제대로 지원하는 것은 첫가끝 조합형'」, 하이테크정보, 《하이테크정보》 제162호, 1996.2.20. back
글 걸기 주소 : 이 글에는 글을 걸 수 없습니다.

덧글을 달아 주세요

  1. 전마머꼬 2020/02/04 15:20 고유주소 고치기 답하기

    N바이트 조합형은 뭔가 점자에서 아이디어를 얻어왔나요. 구현이 점자스럽군요.

    • 팥알 2020/02/04 16:12 고유주소 고치기 답하기

      알고 보면 점자는 첫닿소리, 가운데홀소리, 끝닿소리를 가리므로 3벌식 체계인 첫가끝 조합형과 더 통한다고 볼 수 있습니다.
      N바이트 조합형은 겹받침이 따로 들어간 것을 빼면 닿소리/홀소리만 가리는 2벌식 체계에 가깝고요.

      N바이트 조합형이 일본의 영향을 받아 만들어졌다느니 하는 소문들도 있었던 모양인데, 전신기에 쓰인 모르스 부호값과 연관이 있을지 모릅니다.
      요즘에 보면 답답하고 번거롭지만, 쓸 수 있는 부호값이 너무 적었던 때에 묘안을 잘 짜냈다는 생각도 듭니다.

  2. 비밀방문자 2020/03/15 14:56 고유주소 고치기 답하기

    관리자만 볼 수 있는 덧글입니다.

    • 팥알 2020/03/15 16:46 고유주소 고치기 답하기

      그렇네요.

      [표 10-4] 7비트 조합형 부호계 (33개 낱자 + 채움 문자)

      33개 낱자가 아니라 51개 낱자인데 잘못 넣었습니다.
      얼른 고치겠습니다.
      알려 주셔서 고맙습니다.

  3. 피시키드 2023/11/02 17:41 고유주소 고치기 답하기

    한글 코드체계에 대해 이해가 갔으나, 의문점이 몇개 있습니다.

    한글 코드체계를 보면, 완성형(949), 조합형(1391), 그리고 IBM한글(934)가 있었습니다.

    한글 코드 934의 체계를 한번 분석요청 드려봅니다.

    현재 시점에서는 제가 아는 정보 몇가지 찾은 것이 있어 링크로 공유합니다.

    https://cafe.naver.com/olddos/77723
    https://cafe.naver.com/olddos/5046

    • 팥알 2023/11/02 20:42 고유주소 고치기 답하기

      잠깐 찾아 보니 코드 934이 IBM PC-DOS에 쓰인 것 같고, 동아시아 다국어를 담는 것과 관련이 있어 보입니다.

      이 글은 첫가끝 조합형이 어떤 배경으로 나왔는지를 살피려 한 서론입니다. 어쩌다 보니 서론을 장황하게 썼는데, 설명 자료의 도움 없이 제가 알아낼 수 있는 것에 한계가 있습니다.ㅠㅠ

      혹시 나중에 눈에 띄는 자료나 정보가 보이면 소개하고 싶지만, 짧은 동안에 많이 알아내는 건 어려울 것 같습니다.