encoding이란 대체 무엇입니까?

geekforum의 이미지

흔히들 프로그래밍할때 EUC-KR, UTF-8, KSC5601..등으로 encoding 한다고들 합니다. 저도 전산을 전공하고 있지만 누군가가 encoding이 뭔지,그리고 키보드를 찍을때 편집기에서 어떻게 글자가 보이게 되는지 물어 보았을때 뭐라고 꼬집어 대답해 주지 못하고 대충 가르쳐 주고 넘어갔습니다. 작동원리를 분명히 배웠음에도 불구하고 말이죠.

이 참에 원리를 파악하고자 자료를 찾아 보았지만, 저의 경험과 머릿속의 지식이 정리가 안되더군요.

encoding에 대한 경험많으신 여러분들의 지식을 듣고 싶습니다. 범위가 너무 넓기 때문에 디지털, 네크워크분야쪽을 제외하고 일반적인 프로그래밍 차원수준에서 한 수 부탁드립니다.

질문은
1. 유니코드, UTF-8, KSC5601 등 이런 문자세트의 차이점은?
2. 키보드에서 글자를 치면 편집기에서 글자가 찍히는 것의 원리는?
3. 텍스트 파일과 이진파일의 차이점은요? 둘다 이진파일로 저장되는게 아닙니까? 0,1로요.

질문이 많아서 죄송합니다.

댓글

익명 사용자의 이미지

방금 slashdot에서 Unicode의 기술적인 문제에 대한 외국인이 작성한
글을 읽고 왔습니다. 아래는 원문의 링크 입니다.

http://www.hastingsresearch.com/net/04-unicode-limitations.shtml

유니코드가 국제 표준이라고 하는데, 표준 작업시에 중국, 한국, 일본이
제외되었다고 내용안에 적혀 있군요.
<- 외국 회사가 편의를 위해 지들끼리 모여 만들고 표준으로 하자고
주장하는 코드임.

외국인도 인정하는 유니코드의 허접함을 한국인-곧 피해 당사자-인 우리가
가만히 앉아서 주는 떡이나 먹을려고 하고 있으니.. 꿀꿀합니다.

저자는 English 사용자들에게 동양권 국가의 처지를 빗대서, 알파벳에서 Q나 X가 비슷하니까 두글자중 하나를
편의상 없애자고 하면 니들은 편리함을 앞세워 알파벳에서 글자들을 없앨 수 있냐는 표현까지 하더군요.

익명 사용자의 이미지

위의 글을 보니 그런 이야기가 아니군요.

아시다시피 우리나라하고 대만, 홍콩은 정자, 일본은 약자, 중국은 간체자를 씁니다. 이것이 문제 1번입니다.
이들을 코드를 분리하지 않고 같은 코드에 배치한 뒤 화면에 표시만 다르게 하는 방법을 쓸 수는 없는 노릇이니 (한번 잘 생각해보면 이것이 유니코드의 취지와 전혀 맞지 않는다는 것을 알 수 있습니다. 이렇게 쓴다면 '언어'를 따로 지정해야 하는데 이런 것은 단일 코드체제에서는 맞지 않죠.) 같은 코드표에 담기 위해서는 이것을 따로따로 처리해야 하는데 그러기는 6만 5천자라는 글자는 턱없이 모자랍니다.
지금 중국에 있는 한자가 5만자 이상이고 (이중 대부분은 실생활에서 거의 쓰이지 않는다 해도) 다른 나라에서도 수천개가 쓰이니 남을 자리는 없죠.
약간의 해결책으로 공통 한자 영역이 있기는 하지만 (Han ideography라는 이름으로 있을 것입니다) 이것도 각각의 나라마다 주로 쓰는 한자가 조금씩 다르기 때문에 문제가 있지요. 아마 이 영역에 몇천개 들어있을 것입니다. 그리고 정자체, 간자체가 '같은' 글자라도 따로따로 들어있죠. 한번 코드표를 보면 무슨 말인지 아시리라 봅니다.
아마 유니코드에 한자가 약 3만개정도 들어 있을 것입니다만 이것이 각각의 언어를 고려하다 보니 실제 한 나라에서 쓸 수 있는 문자는 그렇게 많지 않죠.
그리고... 우리나라에서도 제정안에 한컴 등 여러 회사와 단체가 참가하였습니다. 그렇지 않으면 현대 한글이 포함되었을리가 없죠. (2350자밖에 없는 코드표라면 안쓰고 맙니다. -_-)

아마 Q나 X가 C나 Z랑 비슷하다는 이야기는 한자가 비슷한게 많으니까 좀 자르면 어떠냐 하는 말에 대한 대답인 것 같군요. 뭐 우리같이 한자를 자주 안쓰는 나라에서는 그렇게 큰 문제는 아닌 것 같습니다만. 그 글의 필자는 우리나라에서 한자의 용도를 과대평가한 것 같군요. 분명 사전에 한자로 된 단어는 많지만 실생활에 그렇게 많이 쓰이는것 같지도 않을뿐더러 무엇보다도 한자 단어라도 한글로 표기하는 경우가 많기때문에 실제 한자 글자를 쓰는 일은 그렇게 많지 않다고 생각됩니다.

익명 사용자의 이미지

풀어쓰기와 모아쓰기에 대한 간단한 내용

풀어쓰기... :
: 언어의 발음...을 표시하기에 편하다.
: 형태소 분석이 어렵다.
: 의미에 따른 입력에서는 약간 문제가 있다. (옛이응 등이 부활되어야 하는 점도 그 가운데 하나)

모아쓰기... :
: 발음에 대해 약간의 생각이 필요하다.
: 형태소 분석이 쉽다.(단 구어체는 제외한 문어체만)
: 의미와 발음의 동시 기록이 가능하다.

간단한 요약 :
모아쓰기와 풀어쓰기는 각각 장단점이 있으나,
풀어쓰기는 익숙하지 못하기 때문에, 사람들이 그 단점을 먼저 생각한다.
하지만, 풀어쓰기가 꼭 나쁜 것은 아니며,
단지, 모아쓰기가 의미를 표시하는 글자로서의 의미와
말의 소리내기를 표시하는 발음기호로서는 의미를 동시에 살릴 수 있기 때문에 그것을 선호하는 것일 뿐이다.

익명 사용자의 이미지

하나, 빼먹었네요...
국어학자들도... 국어나 다른 언어의 한국어 발음기호를 표기할 때에는...
풀어쓰기를 한다네요...

익명 사용자의 이미지

이 글은 아래 여러곳에 있는 준호님의 글들에 대한 댓글/질문입니다.

준호님의 글을 통해 많이 배웠습니다.
unicode가 상용조합형보다 나쁘지 않다라는 것도.
하지만

1. n-byte 조합형이 구현하기 힘들어 거의 사장되었다고 하셨는데,
첫가끝도 마찬가지 아닌가요 ? 둘다 가변형이니.
제 생각에는 첫가끝이 국제 표준으로 되길 기대
하는것는 불가능할것 같은데 님의 생각은 어떠신지 ?
여기서 표준이란, 예를 들어, 저처럼 외국에 있는 사람이 한국 고어를
쉽게 읽고 쓸수 (가능하면 patch 없이!) 있다라는 말이겠죠.
그럴려면 X-windows, window manager, web-brouser 등 많은 프로그램들이
이를 기본적으로 지원해야 겠지요. 무식한 소리인가요?
저는 우리가 현실적으로 불가능한 소리로 위안을 삼으면서 우리
고어를 버리고 있다고 생각 합니다.

2. 만약 운이 좋아 모든 program에서 첫가끝이 구현되는 세상이 빨리 왔다고
칩시다. 그럼 만여개의 현대어 table은 뭔가요? 2300여자의 완성형이 그랬듯이
이도 결국에는 한글 발전을 방해하지 않을까요 ?

3. 현재 unicode는 2-byte이지만 (BMP라고 하나요?) 확장중에 있다고 하는 데
이것도 반가운 소식은 아니라고 봅니다. 왜냐하면 앞의 표준과의 호환성때문에
제대로 하기가 힘들기 때문이죠. 예를 들어 이 확장된 공간에 고어 table을 만들수도
있을텐데, 이렇게 되면 신판 확장완성형이 되는 셈이죠. 이런 류의 문제들은
MS-DOS의 ram-size의 640K 제한, hard-disk의 CHS 방식의 제한 등으로 지겹게
봐 왔었죠. 별거 아니라고 할 수도 있겠지만.

한글을 위해선 unicode의 BMP가 2-byte가 아닌 처음부터 3-byte
표준이었어야 한다고 생각합니다. 예를 들어 현재의 2-byte unicode에서 한글이
차지하는 부분은 20 % 정도입니다. 만약 unicode가 3-byte 표준이면
0.2*2^(3*8)= 3 백만이고 이는 (첫가끝이 표시할 수 있는) 우리말 모두를
(현재 unicode가 현대어를 표시하듯이) 표시하고도 남습니다.
참고로 첫가끝이 표시할 수 있는 우리말은 60여만자입니다.
이렇게 되었다면 우린 더 이상 바랄게 없겠지요.
준호님께서 말 했듯이, 언어(말)는 소멸하기는 쉬워도 새로 생기기는 어렵죠.
이 말은 다시 말해 지금 제대로 표준을 정하면 언어가 소멸되어 없어 질
때까지 천년 만년 잘 쓸 수 있는 거라는 말이죠. 그런데 unicode는
우리에게 굴곡된 한글을 쓰기를 요구하고 있는 것 아닌가요?

4. 따라서, 저는 unicode의 보급이 한글의 절름발이를 의미한다고 봅니다.
상용조합형의 한계에서 알 수 있듯이, 고어 포함 한글은 2-byte 언어가 아니기
때문입니다. 기술적인 문제나 낮은 국력 등으로 unicode외에 다른 대안이
없을지는 모르겠지만.
무식의 소치로 틀린 소리만 했다면 죄송하고요.

준호의 이미지

1. n바이트 이야기는 80년대의 이야기입니다.
그때는 시스템의 용량이나 처리속도상 문제가 많았죠.
지금은 큰 문제가 되지 않는다고 생각합니다. 이전에는
코드와 한글 표시를 동일시하는 경우가 많았지만 지금은
워드프로세서부터 윈도우 시스템까지 모두 가변폭 글꼴이나
기타 멀티바이트 인코딩을 잘 처리하고 있습니다.
따라서 지금은 가능한 시기에 있다고 생각합니다.

그리고 첫가끝 코드는 이미 표준에 들어 있습니다. -_-
문제는 말씀하신 대로 구현입니다. 제가 전에도 이야기
했지만, 구현에 있어서는 아무래도 우리나라 사람들이
하는 것이 옳다고 봅니다. 말씀하신 대로 윈도우 시스템,
웹 브라우저, 워드프로세서 등에서 모두 지원해야 하는데,
이러한 시스템이나 어플리케이션에서 첫가끝 지원을 하려면
해야 할 일이 많습니다. 이미 정해진 것 외국 사람들도
제대로 구현한 것을 가져다 주면 반대할 사람도 거의
없습니다. MS의 것은 모르겠지만 적어도 X윈도우나
모질라 등에서는 구현이 가능하지 않을까요? 모질라의
경우 일부 지원 계획이 이미 있는 상태입니다.
잘 안된다고 아예 포기하면 너무 아깝잖아요. 이 기회에
살려볼 수 있는 방안을 찾아보는게 좋으리라 생각합니다.

2. 말씀하신대로 첫가끝 영역으로 표현할 수 있는 글자수는 유니코드에 들어있는 현대어 영역과 겹칩니다.
가령 현재의 MS윈도우에서는 이 영역만 지원하는데,
이런 현상이 계속되면 사람들은 그것만이 유니코드의 한글
영역인줄 알겠죠. 이것은 바람직하지 않다고 봅니다.
내부적으로는 첫가끝으로 처리하고 외부적으로는 가능한
글자만 현대어 영역으로 표시할 수도 있으니 피할 길은
얼마든지 있다고 보아야죠.
다만 이 영역의 의의는 유니코드가 그랬듯 기존의 한글
코드 표준에서 제시하는 글자를 모두 모은 것입니다.
(완성형+확장완성형+조합형+완성형보조1,2)
당시에는 그 영역을 만들어야만 했을 거라 생각해 봅니다.

3. 제 생각에는 한글 영역에서 특별한 이유가 없는 한
고어 영역을 지금 스타일로 만들 이유가 거의 없다고
봅니다. 일단 양이 너무 많고, 첫가끝 방식으로 커버가
가능하기 때문입니다(물론 그것이 완전한지는 제외하고).
따라서 그런 일은 거의 일어나지 않을까... 합니다.
실제로 그렇게 하려는 사람도 없을 테고요.

4. 일단은 처음으로 국제 표준에서 첫가끝과 같은
조합 방식의 한글 처리가 가능해졌으니 되도록이면 이를
살리는 것이 중요하다고 봅니다. 아직 제대로 지원하는
어플리케이션을 보지 못했는데 미리 지레짐작으로
안된다고 생각하는 것은 그리 옳지 못하다고 봅니다.
먼저 이러한 코드를 이용한 어플리케이션 개발에 힘을
쏟고, 나중에 평가하는 것이 좋겠죠.

기존의 X윈도우 등도 대대적인 수정이 필요할지 모릅니다.
이러한 것은 차차 해결되어 나갈 수 있으리라 봅니다.
다만 이러한 부분을 모두 외국 사람들이 해결하기는 어려울
테니 우리들이 직접 해서 X윈도우 시스템에 넣는다든가
하면 정말 좋겠죠.

익명 사용자의 이미지

유니코드의 한글 코드 테이블 만든 사람들입니다.

전부 M$직원이군요. SUN이랑 IBM은 왜 빠져있지? 한국인 전문가들은?

유니코드는 완성형 코드에서 출발해서 코드 테이블 크기가 몇년에 한번씩 늘어나서 2.0에 이르러 11,172가 되는군요.

몇년에 한번씩 코드 테이블을 갈아치우는 코드체계가 표준이라, 참 황당하군.

출처는 Unicode 공식 사이트의 ftp 서버임.

Korean Hangul Encoding Coversion Table

---
Date: Oct 04, 1995
Author: K.D.Chang
In Sook Choi
Jung Ho Kim

Colum 2 : Wansung (KSC 5601-1987)

Colum 3 : Unified Hangul

Colum 4 : Johab (KSC 5601 - 1992)

Column 5 : Unicode 1.0
2,350 : Hangul

Column 6 : Unicode 1.1
2,350 : Hangul
1,930 : Hangul Supplementry-A
2,376 : Hangul Supplementry-B

Column 7 : Unicode 2.0
11,172 : Hangul

---

준호의 이미지

말씀하신 표는 "변환표"이지 표준 문서가 아닙니다.
변환표 만든 사람이 표준 제정에 참여했을지는 모르지만
동일하지는 않겠죠. (전 누가 표준을 제정했는지는
잘 모릅니다)

그리고 MS직원이 참여하면 안되는 이유가 무엇인지요?
쓸데없는 반감은 해가 됩니다. 그들이 잘못한게 있다면
무엇이 잘못되었는지를 밝혀 주셔야겠죠.

표준이 자주 바뀌는 것은 우려할만할 일이겠지만, 결국
2.0 이후에는 한글 인코딩은 거의 굳어졌습니다.
(즉 1.1 이전의 유니코드를 지원하는 어플리케이션은
거의 없다는 의미입니다) 그러니 더 이상 바뀔 일은
거의 없겠죠. 필요한 것이 다 들어 있으므로...
(도글님이 원하시는 첫가끝도 1.1대에 들어갔습니다)

그리고 심심하시면 한국어나 일본어, 중국어에 대한 표준이
몇번이나 바뀌었는지 살펴보세요. :) 올바른 변화는
권장할만한 것이지 비난할일이 아닙니다.

아마 바꾸기 어렵다고 유니코드에 완성형만 넣고 그만이었으면 비난이 더 심했겠죠?

익명 사용자의 이미지

>말씀하신 표는 "변환표"이지 표준 >문서가 아닙니다.
>변환표 만든 사람이 표준 제정에 >참여했을지는 모르지만
>동일하지는 않겠죠. (전 누가 >표준을 제정했는지는
>잘 모릅니다)

변환표, code table은 표준문서에 반드시 들어갑니다.

익명 사용자의 이미지

여러 분들의 글을 보고 또 다시 글을 적게 되었습니다.

한글이 훌륭하다는 것은 저 역시 한국인으로
자부심을 가집니다. 그리고 한글 모아쓰기에
대한 여러 근거를 잘 알고 있습니다. 더불어
저는 결코 모아쓰기를 버리고 풀어쓰기로 만
가야 한다고 생각하지 않습니다.

다만...
저는 풀어쓰기도 한글의 다른 모습이지 결코
배척되어야만 하는 이단이 아니다 라고 생각
합니다. 그리고 요즘 같은 정보화,전산화 시
대에 꼭 필요한 부분이라고 생각합니다.

그리고...
영어가 결코 한글에 비해 떨어지는 언어도
아니지요. 또 설혹 결점이 있다 하여도 계속
수정,보완,발전이 된다면 그 것이 더 나은
모습이 아닐런지요. 즉 여러 목소리를 수용하는
방향으로 나가는 것이 더 중요합니다.

이 세상에 결코 완전한 문자나 언어는 없습니다.
한글의 현재의 모습도 결코 완전하지 않습니다.
이 것은 되고 저 것은 안된다는 이분론은 결코
바람직한 모습이 아니지요.

예를 들어 봅시다, 대만, 싱가폴등 화교문화
권이면서 괄목할 만한 발전을 이룬 나라들은
제가 저번 글에서 말한 것 처럼 전산환경에
는 모두 영어로 처리를 합니다, 심지어 이름
까지 한자,영문 두 개를 명함에 가지고 다닌
다고 합니다. 하긴 요즘 우리나라도 이러지요.
이스라엘 중국도 그러한 것으로 보입니다.
프랑스는 얼마나 궁지에 몰렸으면 자국내 행사
시에 모국어를 쓰도록 법을 만들었겠습니까?

이번에 개항한 인천 국제공항, 표기용 이름,
주소, 등을 빼고 공항을 움직이는 시스템은
아마 영어로 돌아갈 것입니다. 이미 대다수의
영역에서 컴퓨터가 사용되고 있고 그 곳에서는
어김없이 영어가 주도권을 꽉 쥐고 있지요.

전세계의 인구가 얼마인지 한 80억쯤 되나요.
그 중에 대다수는 영어문화권이지요. 이들에게
아무리 한글의 우수성을 강조한 들 그 들이
얼마나 반응을 할까요? 아니 그 들에게 알릴
방법이나 능력이 있을까요. 더구나 설령
인정한다 하여도 그 들이 영어를 버리고
한글을 쓸까요.....

아니 우리의 모습을 돌아 보십시요. 그 우수한
한글이 쓰이는 곳이 과연 얼마나 됩니까? 거리를
도배한 간판을 보십시요. 우리가 자랑스럽게 수출
하는 반도체, 자동차, 텔레비젼등 어느 상표를
보아도 영어가 도배를 합니다. 아니 오히려 이제는
그 것이 더 자연스럽게 느껴집니다.

우리가 한글을 버리고 있는 모습이 아닌가요?

다시 한번 말씀 드리지만 결코 한글이 안좋다,
모아쓰기를 버리고 풀어쓰기로 가야한다, 등의
예기가 아닙니다. 한글의 생존방안을 모색해야 할
때라고 저는 생각합니다. 정말 이 대로 가다가는
한글은 그저 그런 용도로 밖에 쓰이지 않는 날이
결코 멀지 않았습니다. 언제까지 한글의 우수성이
어쩌고 저쩌고 하면서, 근세 개화기때 대원군이
한 쇄국정책 같은 모순된 길을 가야 할까요?

문자나 언어는 쓰여질때 생명력이 있는 것이 아닌가요.
더구나 한글은 한자가 그 대단한 위세를 떨치던
시대에 생성되고 인고의 세월을 거쳐 오늘날 모습을
갖추었습니다. 이제 영어가 위세를 떨치는 현재의
상황을 한글을 쓰는 우리가 헤쳐 나가야 할 것
아닙니까. 그 범위를 컴퓨터로 좁혀 보았을 때
풀어쓰기도 하나의 방법이라고 생각합니다.
컴퓨터에서 한글 모아쓰기는 그간 수많은 컴쟁이의
노력의 결실이며 그 과정에 모아쓰기와 컴퓨터의
부조화가 노출되었고, 그 것을 극복하는 과정이었습니다.
그리고 그 과정에 한글을 알파벳처럼 쓸수 있다면...
하고 생각 안해본 프로그래머는 없을 겁니다.

한글의 정통성을 주장하시는 분 들이여...
제발 그 지식과 능력을 한글이 다른 모습으로 도
쓰일 수 있다는 것을 인정하고 긍정적으로 대처해
주기를 바랍니다.

박영록의 이미지

먼저, 현재 우리 나라에서 외래어가 범람을 하는 것과 한글의 풀어쓰기 주장은 아무런 관련이 없어 보입니다. 한글을 풀어쓰기 한다고 영어로 써 놓은 광고판을 한글로 바꿀 것도 아니고 영어 상표를 한글 풀어쓰기로 바꿀 것도 아니죠. 쇄국 정책과 비교해서 이야기하셨지만, 오히려 제가 보기엔 풀어쓰기가 사대주의로 보입니다. 우리의 장점을 왜 우리가 스스로 포기해야합니까? 머, 모아쓰기를 버리자는 주장이 아니라고 하셨지만, 버릴 게 아니라면 풀어쓰기의 의미는 더더욱 찾아보기 어렵죠. 어차피 모아쓰기도 같이 할 꺼면 풀어쓰기를 병행할 이유가 아무 것도 없습니다.

그리고, 퓨터에서 한글의 모아쓰기에서 컴퓨터와 한글의 부조화가 노출되었다는 것은 처음 듣는 이야기입니다. 오히려 학자들 사이에서는 컴퓨터에서 조합형 한글이 저렇게 자연스럽게 구현되는 것은 한글의 과학성을 증명해주는 것이라고까지 이야기하고 있습니다. 동양권에서 컴퓨터와 자국의 언어를 가장 잘 조화시킨 나라가 한국과 일본입니다. 우리나라처럼 자국의 문자를 편리하게 자판으로 입력할 수 있는 나라가 얼마나 된다고 생각하십니까? 과거 도스시절 가장 널리 쓰이던 조합형 한글은 컴퓨터와 한글이 아주 잘 조합된 예죠. 그게 그대로 표준 코드가 되었다면 지금쯤 한글 걱정은 안해도 될 텐데.. 그래도, 비록 그 망할 정부 표준 완성형과 윈도우의 확장 완성형이 일을 그르쳐 놓긴 했지만, 그리고 리눅스에서는 아직 한글이 제대로 구현되고 있지 않지만, 이제 유니코드에서 한글을 거의 완벽히 지원하고 리눅스의 국제화 체계가 잡혀가는 상황에서 그 방향으로 한글을 더 발전시키는 게 훨씬 생산적인 일입니다. 한글을 알파벳처럼 쓰기보다, 한글로 돌아가는 컴퓨터를 만드는 것이 엔지니어의 할 일이 아니겠습니까.

그리고, 한글이 현재 생존 방안을 모색해야할 정도로 위기에 처해있다고는 생각되지 않습니다. 그리고 괜히 영어 잘 쓰고 있는 나라에 가서 우리말을 보급해야할 이유도 없습니다. 마찬가지로 한글 잘 쓰고 있는 우리나라가 영어처럼 한글을 쓰려고 할 필요도 없구요. 이미 한글을 컴퓨터에서 잘 사용할 수 있게 만들 방법은 얼마든지 있습니다. 머, 다른 사람들은 어떤지 모르지만, 저는 자체한글을 위해 조합형 한글 코드를 구현해보면서 한글이 참 구조적으로 설계가 잘 된 과학적인 언어라는 생각을 많이 했었습니다. 님도 한 번 구현해보시면 생각이 많이 달라지실 겁니다.

익명 사용자의 이미지

컴퓨터에서의 한글과 실제 한글과는 다릅니다.

완성형 덕분에 수많은 한글이 사라지고 있는 슬픈 현실입니다!!
한글의 과학성이 개무시 당하고 있습니다.

> 않지만, 이제 유니코드에서 >한글을 거의 완벽히 지원하고 >리눅스의 국제화 체계가 잡혀가는 >상황에서 그 방향으로 한글을 더 >발전시키는 게 훨씬 생산적인 >일입니다.
유니코드나 완성형의 한글 코드체계는 모래위에 집을 쌓는 것입니다. 불안정한 기술에 매달려 한글 개발자들과 사용자들이 고생할 것입니다.

"한글을 거의 완벽하게 지원"하는 기술을 사용하려고 애를 쓰냐하는 것입니다. 조합형 코드 사용하면 한글 완벽하게 쓸 수가 있는데 말입니다.

>그리고 괜히 영어 잘 쓰고 있는 >나라에 가서 우리말을 보급해야할 >이유도 없습니다.
언어는 민족과 국가를 이해하는 창문입니다. 그냥 다른 나라 놈들이 알아서 한국을 이해해주길 기다리는 것 보다는 적극적으로 우리말을 보급하는 건 바람직한 일입니다. 한가지 기분나쁜 현상 알려드릴까요? 일본놈들의 부단한 일본어 - 영어 번역의 노력으로 아시아에 관련한 문서는 "역사, 기술, 기타" 대부분 일본놈들이 만든 자료의 영문판을 외국인들이 공부를 합니다. 그래서, 외국인들이 한국에 대해서는 일본식 사고를 가지고 있습니다. 단적인 예로, 대한민국이 "Korea"였습니까? 원래는 "Corea"였는데 일본놈들이 "Korea"로 바꿨습니다.

M$의 백과사전 프로그램에 동해는 아마도 "Japan Sea"로 표기가 되있겠지요. 한국인을 제외한 외국인들은 당연히 동해가 '일본해', 일본의 바다로 알게 됩니다. 독도도 조금 비약을 하면 한국만이 독도는 우리 땅이라고 주장을 하고 (원래 사실이지만), 나머지 전세계 인들은 독도는 일본땅이라고 알게 될 수도 있습니다. 미래에 한국-일본 사이에 분쟁이 생겨서 국제 기관이 중재를 할때 독도는 일본 거라고 판결이 나겠지요.

>이미 한글을 컴퓨터에서 잘 >사용할 수 있게 만들 방법은 >얼마든지 있습니다.
동의합니다.

>한글을 알파벳처럼 쓰기보다, >한글로 돌아가는 컴퓨터를 만드는 >것이 엔지니어의 할 일이 >아니겠습니까.
한글을 알파벳처럼 쓰는 것은 사용자 마음입니다. 풀어쓰는 것이 알파벳을 흉내내는 건 아닙니다.

한글 풀어쓰기와 조합형 코드체계가 컴퓨터에서 한글 구현에는 유니코드보다 몇십배 편리합니다. 미래에는 모아쓰기며 유니코드가 한국인 사이에서는 전설로 될 겁니다. 왜냐면, 조합형 코드와 풀어쓰기가 컴퓨터 분야에서 표준으로 자리를 잡을 테니까요. 그날을 기다리면서--

익명 사용자의 이미지

유니코드에 완성형 코드만 있는 게 아니잖아요...
유니코드에서 완성형 안 쓰고 첫가끝 쓰면 될 일을...

그리고 한글을 구현할 때,
모아쓰기가 표시하는데 번거로운 것은 사실입니다.
그렇지만, 구현할 때 잠깐의 불편보다 구현된 글이
읽기 좋도록 만드는 것이 훨씬 중요합니다.

익명 사용자의 이미지

첫가끝으로도... 초성과 종성이 모두 비어 있는 모음만으로 된 문자는 만들 수 없습니다.

그런데, 제 사촌 동생이 초등학교 입학전에 보던
한글 교본에는 초성과 종성이 모두 없는 문자가 있습니다.
보통의 모음과는 다릅니다.

아래아 한/글/에서는 코드표에 이 문자가 있던데...
몇번인지 까먹었네요...

아무튼 유니코드로 현대어(또는 현대어를 쓰는 문서)에서 쓰이는 한글을
모두 쓸 수 있다는 건 아직까지는 요원한 꿈이네요.

익명 사용자의 이미지

만들 수 있을 텐데요...
첫소리/가운데/끝소리 가 각각 독립된 코드인데
못 나타낼 까닭이 있나요?

익명 사용자의 이미지

님이 제 글을 세세히 읽지 않으신 건지 제가 설명이 부족한 건지
이런 식의 반박의 글이나 토달기의 글을 좋아 하지 않지만...

풀어쓰기와 외국어의 범람을 묶은 것이 아니고 한글 생존의 문제와
연결 시켜 생각한 것 입니다. 아무리 뭐라 하여도 전 세계적으로
우리글과 말을 쓰는 사람의 수는 1억도 안됩니다. 그리고 그 중심에
있는 우리들도 결코 영어나 한자문화의 종속에서 벗어 날 수는 없습니다.
아니 그 경향은 갈수록 깊어지고 있습니다. 이걸 부정하시면
할말이 없습니다.

부조화가 컴퓨터의 아주 기본적인 I/O에서 부터 일어 납니다.
그러나 모아쓰기와의 부조화일 뿐 한글과의 부조화는 아닙니다.
초기 아주 제한된 MPU/RAM 그리고 I/O로 구성된 컴퓨터로 개발이
시작이 되었을 때 처리하는 부호는 7비트였습니다.
즉 개별적으로 표현할 수 있는 가지수가 127개 였다는 것
입니다. 아시겠지만 이 곳에 ASCII 하위 코드가 존재 하고
지금도 기본입니다. 나중에 8비트로 확장 되면서 한글도 이 곳의
그래픽문자 영역을 사용하여 처리하게 됩니다. 그래서 깨지면
그래픽문자와 로마자가 나타나게 되지요. 이 7비트에서 한글을
모아쓰기로 표현 하려면 어떻게 될까요? 그리고 이 당시 출력
장치는 지금 우리가 쓰는 모습이 아니었습니다. 지금의 모니터
를 가지고 예를 들어도 영문은 8x8 픽셀 안에서 표현이
가능 하지만 한글은 그 배가 넘게 필요할 뿐더러 그 폰트의
용량은 영문에 비해 엄청나게 커집니다. 더구나 모니터가
아닌 라인 프린터나 숫자와 영문이 겨우 표시되는 디스플레이로
개발할 때를 생각해 보시면 .... 그럼 지금은 상황이 낳을까요?
여전히 제한된 시스템은 수 없이 존재합니다. 그리고 그 곳에서는
모아쓰기 처리는 시스템 자원을 잡아먹는 귀신입니다. 그래서
아예 한글은 쓰지도 않고 영문으로만 만듭니다. 우리가
컴퓨터를 주도적으로 개발하였다면 먼저 한글은 기본이 겠지만
풀어쓰기였을 것입니다. 그리고 모아쓰기로 갔겠지요.
그랬더라면 이런 토론은 제한된 상황은 풀어쓰기 풍요한 상황에는
모아쓰기라는 자연스러운 연출이 되었을 터인데 ....

컴퓨터를 떠나서라도 예기할 것이 있군요.

제 경험담을 하나 말해 보겠습니다. 예전에 CP/M인가 하는
운영체계를 개발한 케리킬달이라는 사람이 있었습니다.
그 당시 대단한 사람이었지요. 젊은 나이에 개발한 운영체계가
도스의 모태가 되었을 겁니다. 그리고 그 사람이 중학생때
부두에서 일하는 아버지를 돕기위해 조수간만의 차를
처리해 주는 프로그램을 만들었다고 인터뷰에서 말하엿더군요.
그 당시 저는 젊은 혈기로 개떡같은 한글처리(그 당시)를
개선해 보고자 노력하고 있던 때였습니다. 그 기사를 읽고
그래 나도 영어로 짠다면, 조수간만표 가져와서 1주일도
안걸리겠다. 하고 자부하였지요. 아니 한글을 풀어 쓸 수만
있어도 같은 결과 였지요. 왜냐구요 컴퓨터는 문자모드에는
코드값만 해당 디바이스에 날려 주어도 나타나고 한글은
그림모드로 전환한 다음 프로그램으로 일일이 한점한점
그려주어야 하는 상황이었습니다.

또 다른 예로 얼마전 딸애의 숙제문제로 표어를 자와 연필을
이용하여 모아쓰기 한글의 외곽선을 그렸습니다. 정말 이런
일에 상당히 익숙한 나에게도 중노동 이더군요. 이런 일이
처음은 아닙니다. 중,고등학교 제도 시간에 영문은 외곽선이
파여진 자가 그 것도 크기별로 있어서 아주 빠르게 아주 쉽게
처리를 할 수 있었습니다. 아니 손으로 그려도 아주 깔끔 합니다.
한글도 있긴 있었지만, 생각해 보십시요 크기별로 글자체별로
초중종성으로 몇벌일까요. 자를 바꿔가면 또 자모의 위치는
어떻게 어울리게 잡지요. 아예 안씁니다.

흠 이 것도 부러운 것이었습니다. 흔히 라벨이라 부르는
두꺼운 플라스틱 테이프에 글자를 펀칭하여 클리어파일이나
바인더 서랍등에 붙이는 한 손에 들어오는 기구가 있지요.
저처럼 정리를 좋아 하는 사람은 정말 좋은 기구였습니다.
하지만 한글은 ???

우리나라처럼 인구도 모자라고 자원도 부족한 나라에서
어떻게 하면은 지금 보다 낳은 삶을 영위 할 수 있을까요.
그 것은 알뜰하고 효율적인 자원의 활용이 아니겠습니까?
널려있는 거대 시장을 놔두고 0.1% 도 안 되는 완벽한
한글모아쓰기 시장에 자원을 쏟아 부어도 되는 상황일까요?

언제나 반대편에 서 있는 사람들이 있습니다.
각자에서 타당한 이유도 있을 겁니다.
세상을 보는 시각도 다를 것입니다.
그러나 서로 의견은 달라도 목적이 같다면 반목할 필요는
없지요. 저 역시 한글이 과학적인 언어라고 누차 말하고
있지 않습니까?? 단지 모아쓰기만이 한글이라고 말하지 않을
뿐입니다. 모아쓰던 풀어쓰던 한글입니다.

고등학교때 교과서에 나오는 시중에 선택의 갈림길에서 가지
못한 길을 아쉬워 하는 외국 시가 있었습니다. 그 시를
읽으며 동서양을 막론하고 인간의 공통점을 발견할 수 있어
좋았습니다. 공통점이 좀재하는 다양성...
"우리나라처럼 자국의 문자를 편리하게 자판으로 입력할
수 있는 나라가 얼마나 된다고 생각하십니까?" 님의 이
글은 저의 첫번째 글에 똑같이 나옵니다.

제발 모든 것을 하나의 잣대로 해결하려 하지 마십시요.
각각의 척도에 맞는 자가 필요합니다.
저는 다시 말씀 드리지만 결코 한글의 모아쓰기를 버리고
풀어쓰기만 쓰자가 아니라니까요. 풀어쓰기도 필요하고
그 것도 한글의 다른 모습입니다. 아시겠지만 컴퓨터에서
정보의 처리는 결국 이진수의 연속일 뿐입니다. 즉 내부에
들어가면 모두 이진수 입니다. 그걸 인간과 교감할 때
비로소 인간이 인지할 수 있는 형태로 표현할 뿐입니다.

영문도 코드가 하나가 아니지요. 자판도 하나가 아니지요.
심지어 요즘 흑인 들이 부르는 랩송에는 그 들만의 단어가
마구 나오지요. 다양성 저는 이 단어를 정말 좋아 합니다.
다양성이 없다면 모두 같은 모습이고 개성이나 인간적인 것
들이 없는 그야 말로 삭막한 획일화된 모습이 아니겠습니까?
이런 상황은 항상 누군가는 지시를 하고 대다수는 따라야
만 하는 상황을 연출합니다. 아 정말 싫습니다.
님께 한글 모아쓰기를 버리고 풀어쓰기를 하라고 말한 적도
없고 말하지도 않습니다. 마찬가지로 님도 그래 주시길 바랍니다.

저도 풀어쓰기에는 어느 정도 진전을 가지고 있습니다.
님도 모아쓰기에 진전 하시어 방향은 다르지만 컴퓨터와
조화를 이루는 한글의 완성이라는 성취를 가지고 만나기를
바라며 그만 적겠습니다.

추신: 이런 토론의 특성인 상대편 글에 마음이 상하여 서로
말꼬리를 무는 그런 상황이 오지 않기를 바라며 생산적인
토론이 되도록 님의 넓은 이해를 바랍니다.
그리고 그런 상황이 오면 서로 글을 적지 말았으면 합니다.

박영록의 이미지

다양성은 분명 좋은 이야기입니다. 님 말씀처럼 풀어쓰기를 하고 싶어하는 사람이 자기 혼자 만들어서 자기 컴퓨터에서만 쓴다면 저도 그것까지 말리진 않습니다. 하지만, 그게 보급되어야한다는 생각은 절대 반대입니다. 저는 하나의 표준을 만들어서 거기에 다수가 다 따라라..이런 관점에서 풀어쓰기를 반대하는 것이 아닙니다. 풀어쓰기가 많은 단점을 갖고 있기 때문에 반대하는 것입니다. 다양성을 논하며 무조건적인 양시론을 주장하는 것은 정당한 반론마저 차단하게 만듭니다.

먼저, 제가 님의 글을 읽고 조금 화가 났던 점은, 한글이 한자의 영향으로 모아쓰기를 하게되었다는 주장 때문입니다. 한글을 공부하는 사람으로서 제가 아끼는 것이 다른 사람에 의해 훼손된 것 같은 느낌을 받았습니다. 여기에 대한 이야기는 이미 제가 여러 개의 글을 통해 충분히 설명드렸다고 생각되므로 더는 언급하지 않겠습니다. 그냥, 한글에 대해서 제 글을 통해서나마 조금 더 생각해보는 기회가 될 수 있었다면 그걸로 충분합니다.

그럼 본론으로..
제가 반대하는 가장 큰 이유는 한글의 장점을 살리지 못한다는 것입니다. 모아쓰기가 지금도 충분히 잘 구현될 수 있는데도 불구하고 한글의 장점을 버려가면서까지 풀어쓰기를 할 이유가 없다는 거죠.

7비트 코드에서 한글 모아쓰기를 할 때의 부조화를 말씀하셨는데, 컴퓨터와 모아쓰기의 부조화가 아니고 7비트 코드와 모아쓰기와의 부조화입니다. 님의 말씀처럼 코드의 종류는 아주 다양합니다. 7비트 코드를 지금 고수해야할 이유는 아무 것도 없습니다. 16비트 코드를 쓰면 간단한 일입니다. 문제가 있다면 용량이 커진다는 것 뿐인데 부조화가 아니라 용량의 문제죠. 작은 컴퓨터에서 복잡한 수학 문제를 푸는 게 오래 걸린다고해서 수학과 컴퓨터가 부조화라고는 말하지 않습니다.

만약에 처음부터 컴퓨터가 16비트 코드를 기반으로 만들어졌다면 어떨까요? 그랬더라면 한글을 표현하는데 아무 문제도 없었을 겁니다. 아주 자연스럽게 한글을 표시할 수 있었겠죠. 디바이스에 코드값만 날려주면 해당 폰트를 표시하게 하는 것은 한글도 똑같이 가능한 일입니다. 초성, 중성, 종성의 코드를 각각 모은 다음 그것을 가상의 폰트로 전송해주면 간단한 일이고, 이 작업이 그렇게 로드가 많이 걸리는 것도 아니고, 운영체제 차원, 혹은 그 이전의 하드웨어 차원에서도 충분히 해결 가능하며, 실제로 현재에 텍스트모드에서 한글을 표현하는 시스템도 있습니다. 영문은 디바이스에 코드값을 전송하면 그대로 표시되는 이유가 무엇입니까? 코드값을 보고 해당 폰트를 찾아서 그려주는 역할을 하는 루틴이 있기 때문이죠. 그 부분만 한글 처리가 가능하게 바꿔주면 모든 문제가 해결되는 겁니다.

한글 폰트파일이 크다는 것도 동의하기 어렵습니다. 물론 완성형 한글 폰트라면 용량이 상당히 크겠지만, 조합형 방식의 한글 폰트라면 풀어쓰기보다 그리 크다고 말할 수 없습니다. 풀어쓰기에 비해서 2~3배 정도 클 뿐입니다. 컴퓨터에서 용량이 linear scale로 차이가 나는 건 별로 문제가 아니죠.

그리고, 표시 공간의 측면에서는 풀어쓰기가 모아쓰기보다 나을 것이 없습니다. 어차피 영문과 같은 크기로 표시된다면 초성중성종성이 다 있는 글자는 3바이트를 차지할 텐데, 화면상으로도 더 넓은 공간을 필요로 합니다. 모아쓰기는 이런 점에서 글자의 화면상 압축력에서도 풀어쓰기에 비해 장점이 있는 셈이죠. 어떤 방식을 써도 풀어쓰기로 모아쓰기보다 적은 공간에 표시하는 것은 불가능할 겁니다.

그리고, 한 시스템에서 모아쓰기와 풀어쓰기가 병존하는 것은 풀어쓰기의 장점-리소스를 아낄 수 있다는 점-이 전혀 발휘되지 못하는 것이 되버리죠. 결국 풀어쓰기가 있는 시스템은 풀어쓰기만으로로 갈 때만 의미가 있습니다.

그리고, 한글을 표시하기 힘든 시스템도 있다고 말씀을 하셨는데, 제가 볼 때는 노력의 부족일 뿐입니다. 어차피 그런 시스템에서 영어가 아주 이쁘게 표시되는 것도 아니고 영어가 표시되는 수준 정도로 한글을 표시하는데 들어가는 노력과 비용은 그리 크지 않습니다. 만약 현재 시판되는 10만원대의 계산기에 한글이 표시되게 만든다면 단가가 얼마나 비싸질까요? 1만원 안팎입니다. 50만원 정도 하는 레이저 프린터의 액정에 영문 대신 한글이 표시되게 만들려면 얼마나 비싸질까요? 제가 볼 때, 2~3만원 이내입니다. 개발자의 입장에서 어마어마한 노력이 더 들어가는 것도 아니고, 훨씬 큰 하드웨어 리소스가 필요한 것도 아닙니다. 핸드폰의 그 작은 액정 화면에 간단한 화상 정보까지 표현되는 시대입니다.
어떤 것이든 장점을 얻으려면 그만큼의 투자가 필요한 법입니다. 풀어쓰기로 모아쓰기에 비해 아낄 수 있는 리소스의 양보다 모아쓰기로 풀어쓰기에 비해 얻는 만족감이 훨씬 클 것입니다. 만약, 컴퓨터를 거의 모르는 사람이 모아쓰기로 표시되는 기계를 본다면 어떻게 생각할까요? '거참, 되게 불편하네. 이 정도 기술력도 안되는 회사인가?' 하고 생각할 겁니다. 영어 대신에 풀어쓰기나마 한글이 표시된다고 좋아할 만한 사람은 그다지 많지 않을 겁니다.

그리고 님이 경험으로 드신 것은 아주 특수한 예인 듯 하군요. 얼마든지 대안이 있는 상황에서 그런 것 때문에 풀어쓰기를 주장하신다는 것은 좀 이해하기 어렵네요.

하나의 잣대로 해결하고자함이 아닙니다.
'나는 생각이 이래.'
'어, 그래? 난 생각이 이런데.'
'그렇군. 우린 서로 생각이 다르구나.'
'그렇군. 우리 서로의 생각을 존중해주자.'
이런 식이라면 무슨 토론이 되겠습니까. 상대의 생각이 틀렸다고 생각된다면 당연히 지적해줄 수 있는 일입니다. 그래야 서로 생각이 오가고 서로의 생각이 좀더 다듬어질 수 있는 거죠. 이 geekforum도 그런 다양한 생각들이 오가고 토론하라고 만들어둔 곳 아닙니까. 그냥, 어, 너는 그렇구나..수준에서 그친다면 무슨 의미가 있겠습니까. 머, 그래도 약간의 의미가 있긴 하겠지만.--; 어쨋든, 서로 예의만 지킨다면 논쟁이 오갈 수 있는 것은 자연스러운 것이고 그것이 더 발전적인 것이라고 생각합니다. 제가 특별히 무례를 범한 건 아니라고 생각되는데요. 혹시 제가 무례하게 말한 게 있다면 지적해주시기 바랍니다.

익명 사용자의 이미지

이 글을 마지막으로 하겠습니다.

님과 저의 중대한 차이점을 발견했습니다.
저는 한비트라도 아끼는 방향으로 사고방식이 흐릅니다.
님은 모자라면 더 쓰면 되지 라고 하시는 군요.
아마 인문계열이신듯 ...
아니 국문과계열이신가 보군요.

그런분과는 항상 이런식의 대화가 되고 말더군요.
물론 아닌 분들도 요즘은 많습디다 많은...
사고방식의 차이는 항상 존재하는 것이니...

컴퓨터의 발전은 요즘들어 컨텐츠네 뭐네 하면서 그 용량이
커졌지 지금도 핵심분야은 한비트를 가지고 싸웁니다.
님이 보지 못하는 아니 님에게는 볼 필요가 없는 세상이 있습니다.
그 곳은 결코 키우면 되지 더 쓰지 라는 논리가 통하지
않습니다.

제가 글을 그만 쓰겠다는 것은 이미 이 토론도 본론에서
벗어나 감정싸움에 가까운 수준에 다다르고 있다고
생각해서 입니다. 저는 저의 길을 갈 것입니다. 님의
말씀은 이미 제가 만났던 예기들이고 그 정도로는 제가
생각을 바꿀 수 없습니다.

님의 태도는 저에게는 한글이 만들어 질 당시 주류였던
한문학자들의 한글에 대한 억압적인 태도로 보입니다.
이렇게 훌륭한 한자가 있는 데 어디서 그런 싸구려를
가지고 나서느냐고....

다시 말씀 드리지만 풀어쓰기도 한글입니다.
저는 대다수가 가지 않는 길을 갈 뿐입니다.

박영록의 이미지

감정 싸움이라..흠..저는 감정 같은 건 별로 없습니다. 하나 있다면, 처음 님께서 한글에 대해 잘 모르시고 한자 운운 하신 게 조금 기분 나빴을 뿐. 서로 의견이 다르다면 대립하고 의견을 주고 받는 것은 당연한 일인데, 그걸 왜 감정 싸움이라고 하시는지 모르겠군요. 그리고, 제 전공은 전기공학이고 그 중에서도 저는 디지탈 설계 쪽입니다. 한글에 관심이 있고 인코딩에 관심이 있어서 몇 년 동안 한글 공부를 좀 했을 뿐이죠. 프로그래밍에도 상당히 관심이 있구요. 한 바이트도 아껴야한다는 사고 방식을 말씀하셨는데, 지금 프로그래밍에도 패러다임이 바뀌고 있습니다. 제가 볼 때, 님은 아직도 20년 전 64kB 메모리를 쓰던 시절의 패러다임에서 벗어나지 못한 걸로 보입니다. 핵심 분야는 지금도 한 바이트만 가지고 싸우고 있다고 하셨는데, 대체 어떤 분야가 그런가요? 전 간단한 CPU 설계도 해봤었고, 임베디드 시스템도 꽤 만져봤는데 영어 디스플레이는 무리 없으면서 한글 디스플레이는 무리한 그런 시스템은 없었습니다.
요즘 알고리즘의 연구 추세도 예전처럼 1바이트, 1클럭을 아끼려는 시도는 거의 사라졌습니다. 하드웨어가 소프트웨어의 패러다임을 바꾸어놓은 것이죠. 지금은 어셈블리로 레지스터 하나를 아껴가면서, 인스트럭션 하나를 아껴가면서 코딩을 하는 시대가 아닙니다. 제가 대학 3학년 때 실험 프로젝트로 한 것 중에는 8051보드로 님이 말씀하신 8*8 액정에 한글을 표시하는 것도 있었습니다. 대학생이 학기 중에 한 과목의 프로젝트로 할 정도의 노력만 기울이면 되는 일입니다.

머, 정 귀를 막고 님의 길을 가시겠다면 제가 아무리 말해도 소용 없는 일이겠지요. 그러나, 최소한 반대 논리에 대항할 논리는 갖추고 있으셔야하는 게 아닐까요.
'이건 이런 문제가 있습니다.'
'그래도 나는 내 갈 길을 가겠다.'
'이건 이런 점에서 효율이 떨어집니다.'
'그래도 나는 내 갈 길을 가겠다.'
'이건 근본적으로 방향 설정이 잘못되었습니다.'
'그래도 나는 내 갈 길을 가겠다.'
이런 식은..개발자로서는 올바른 자세가 아니라고 생각합니다.

익명 사용자의 이미지

오 이런 제가 잘못봤군요. 님이 전기공학 전공이시면서
이정도로 한글에 관심이 많으신 분인 줄은 정말 대단 하시군요.
저는 완전히 한글이 전공인 사람이라 착각하였습니다.

저도 어줍잖게 전자공학이 전공이고 님과 같은 과정을 겪으며
정 반대로 한글에 대한 풀어쓰기의 필요성에 더 무개를 두게
되었습니다. 그리고 지금 저는 웹 어플리케이션에 종사 하지만
아직도 테이블 설계시에도 타이트하면서 가변성을 갖추려
노력합니다. 1비트나 1바이트도 꼭 필요한 이유가 있어야합니다.

귀를 막는 것도 아닙니다. 단지 보여주는 것이 최상입니다.
한글 모아쓰기가 지금처럼 되기 위해 많은 과정을 겪었지요.
풀어쓰기도 그렇게 과정을 겪어야 겠지요.
그리고 보여 주어야 할 것입니다.

타당한 논리요? 있지요.
그러나 그건 상대방에게 설득하기 어렵습니다.
종교 전쟁이 그런 양상을 띄지 않습니까?

저는 보여주는 쪽으로 저의 능력을 집중하려 합니다.
배경 논리는 그때 가서 설명하는 것이 의미가 있지요.
그래서 마지막글에 그런 글을 남겼지요.

님께서 제가 피하는 것으로 보시는 것 같아
다시 댓글을 달았습니다.. 사실 시간도 없구요.
그럼 이만...

익명 사용자의 이미지

모아쓰기-풀어쓰기에 관한한 아주 논점이 분명히
정리되었군요.
21세기에 왜 다시 풀어쓰기 얘기가 나와야 하나요?

익명 사용자의 이미지

흠 ......

많은 글들을 보면서 한가지 의문이 듭니다.
왜 우리는 한글을 지금처럼 모아서 쓰게 됐을 까요??
분명 자음/모음, 초성/중성/종성 하는 식으로 분리된
부분으로 인식하고 생성을 하였는 데 왜 모아 쓰게
된 걸까요... 아무리 생각해 보아도 그 당시 우리는
한자 문화권에 완전히 종속돼 있었고 그 외의 세상은
생각도 못하였던 건 아닐까요. 그래서 한자 한자당
한글 한자 즉 발음기호로서의 의미로 모아쓰기를
하게 된건 아닐가요. 아니 거의 틀림 없을 겁니다.

이제 우리는 한자문명 보다 더 많은 영향을 영어문명
으로부터 받고 있습니다. 컴퓨터는 중요한 그들 문명의
상징들 중 하나이지요. 그리고 그 문명에서는 글자를
옆으로 길게 늘어 붙여 의미 있는 단어를 표현하지요.
그 들도 처음부터 자신들의 글자에만 치중 하였을 뿐
동양의 문자들은 생각하지도 못하였지요. 그럴 여유도
없었을 겁니다.

이 둘 사이에서 한글은 참 대단하다는 생각을 갖게
합니다. 지금 이렇게 쉽게 자판을 쳐서 글을 쓸 수
있는 동양의 문자가 있습니까? 흠 ... 다시 봐도
대단합니다. 그러나 문화나 문명으로 들어가 보지요.
과연 우리가 한글로 쳐대는 글자중 토씨 빼고 우리
순수 문화를 표현하는 단어는 얼마나 되나요.
과거에는 한자 요즘 에는 영어 못하면 사회 지도층
에 끼지도 못하는 세태를 제외 하고서 라도 거의
한자문명과 영어문명의 발음기호들 입니다.
안 그런가요.......

이웃 나라 일본은 얼마전 영어를 제2의 국어로 채택
한다던가 하자고 하던가 하는 말이 있었지요.
그리고 우리나라에서도 상당한 세력이 있지요.
하긴 요즘 유행가를 봐도 영어가 안들어 간 걸 찾기
힘들더군요. 이렇게 가다가는 여러 소수민족처럼
모국어는 그들끼리의 안부인사용으로 전락하고
생활언어는 영어로 바뀔날이 멀지 않은 것 같습니다.
그러길 바라는 것은 결코 아닙니다만...

이쯤에서 이 글에 대한 저의 생각을 말씀 드려야 겠지요.

저는 한글을 풀어 썼으면 합니다. 그것도 로마자의
자모 글자 즉 알파벳을 위주로 하고 우리에게 필요한
몇개의 철자를 더 추가 한다면 아마 유럽국가들 처럼
되겠지요. 너무 파격적인가요. 관심을 가지고 찾아
보시면 예전 부터 이런 논의는 있어 왔습니다.
새삼 스러운건 아니지요. 제가 시작한 것도 아니구요.
아마 주시경 선생이 앞장을 서셨던 듯 합니다.

그럼 현재의 모양(모아쓰기)을 완전히 버려야 할까요.
그렇게 해서는 결코 안되지요. 한글의 이 놀라운
능력의 일부를 버릴 수는 없지요. 현재의 기술로
풀어쓰기 모아쓰기는 전부 가능할 것 입니다.
즉 파일로 저장될 때는 풀어쓰기로 들어가고
그걸 그냥 편집기로 본다면 풀어쓰기(로마자기반)로
보이고 모아쓰기 편집기로 본다면 현재의 모아쓰기로
보이는 것 이지요. 이 둘간에 호환을 제공할 기술력은
이미 있다고 생각됩니다.

이렇게 한다면 한글은 유럽처럼 1바이트 코드로도 가능
합니다. 물론 모아쓰기 글자는 유니코드로 처리가 되겠
지만은...

이제 우리의 한글을 컴쟁이 들이 한단계 발전 시킬 수는
없는 걸까요. 발전이라는 단어가 싫으시다면 적응이라는
표현도 나쁘지는 않을 겁니다. 흠....

다시 보아도 한글은 대단한 문자체계입니다.
과학적 근거도 가지고 있고요.
이걸 사용하는 우리들의 능력이 문제겠지요....

그럼 이만...

박영록의 이미지

한글을 모아쓰게 된 이유는 한자의 발음기호로서의 역할을 하기 위해서가 절대로 아닙니다. 그게 아니고 우리말 자체가 '음절 단위'의 말이기 때문입니다. 처음부터 한글을 표음문자로 설계한 것은 한자를 표기하기 위해서가 아니라 구어를 기록하기 위함입니다. 훈민정음 머리말에도 있듯, 세종대왕께서는 백성들이 한자어를 한글로 써서 이해하기 쉽게 하려고 만든 게 아니고 백성들이 일상 생활에서 쓰는 말들을 기록하기 쉽게 하기 위해서 만든 것입니다. 그러니, 당연히 표음문자로 간 것이고 우리말의 발음이 음절 단위로 이루어지다보니 문자도 당연히 음절 단위로 모아쓰기를 하게 된 것입니다. 한글자 한글자가 곧 말할 때의 한 음과 일치한다는 것, 이것 때문에 모아쓰기를 하는 것입니다. 이런 면에서 한글은 알파벳보다 훨씬 합리적입니다. 알파벳도 표음문자임에도 불구하고 전혀 음절 단위의 표기가 되지 않죠. 게다가 단순히 발음기호로서의 가치만 따져봐도 한글의 표현력이 훨씬 좋습니다.

그리고, 우리가 쓰는 말 중에 한자어나 영어권의 외래어가 많다는 것은 한글에 문제가 있는 것이 아닙니다. 우리의 의식이 문제인 것이죠. 그리고, 사실 따지고보면 이게 크게 문제가 될 것도 없습니다. 언어란 것은 원래 서로 영향을 주면서 발전하게 마련입니다. 영어 뿐 아니라 모든 유럽지역의 언어들은 모두 라틴어를 모태로 하고 있고, 또 각각의 언어들끼리 서로 많은 영향을 주고 받았습니다. 영어만 해도 순수하게 앵글로-색슨족이 쓰던 단어는 영어에서 극히 일부분에 불과합니다. 라틴어, 프랑스어가 어원인 단어가 대부분을 차지하고 있죠. 비교적 순도가 높다는 프랑스어도 라틴어와 이태리어로부터는 자유롭지 못합니다. 세계 어느 언어를 봐도 독자 언어의 단어만으로 언어의 완결성이 갖추어지는 건 없습니다. 어차피 한글은 표음문자입니다. 그 어원이 어디서 온 것이건 한글로 표기하면 그건 우리말이 될 수 있는 겁니다. 무분별하게 외래어를 받아들이는 것은 잘못이나, 적절한 정화 노력을 하면서 자연스럽게 받아들이는 것은 결코 잘못이 아닙니다.

어쨋든 한글을 풀어쓴다는 발상은 한글의 기본 구조 자체를 무너뜨리는 일입니다. 왜, 우리가 다른 나라에 맞춰야합니까. 훨씬 과학적이고 합리적인, 그리고 우리에 맞는 문자 체계를 갖고 있는데도요. 한글이 과학적이라는 이야기를 많이 하는데, 저는 그 근거 중 가장 중요한 것으로 음절 단위의 모아쓰기를 들고 싶을 정도입니다. 이걸 버리고 풀어쓰기를 한다면 그건 더 이상 한글이 아닙니다.

현실적인 문제도 있습니다. 첫째, 한글을 풀어쓰기한다고 해서 1바이트로 할 수는 없습니다. 이미 1바이트 문자 체계는 ASCII로 거의 통일이 되어 있고 그 코드는 모두 할당이 되어 있습니다. 이런 상황에서 한글을 쓰기 위해 새로운 1바이트 코드를 만들어내는 것은 무의미한 일입니다. 둘째, 가독성을 심각하게 떨어뜨립니다. 풀어쓰기한 글 한 줄을 읽는 것과 모아쓰기한 글 한 줄을 읽는 것. 이건 시험적으로 아무 글이나 써보시면 알 겁니다. 우리가 그런 불편을 사서 감수해야할 이유는 없습니다.

저는 억지로 우리가 1바이트 체계로 편입하는 것보다 우리가 2바이트 체계를 더욱 발전시켜서 동양권 사람들이 문자 입력하는 것을 더 쉽게 만들었으면 좋겠습니다. 언젠가 국산 운영체제에 관한 논쟁이 있었는데, 저는 코드의 국제화 측면에서 국산 운영체제가 있었으면 좋겠습니다. 아예 커널 차원에서 2바이트를 기본으로 하는 운영체제가 나와서 자유롭게 한글을 쓰고, 동양권 다른 문자들도 쉽게 포용할 수 있게 만들고, 해서 수출까지 할 수 있었으면 좋겠습니다. 리눅스도 솔직히 아직 국제화가 부족한 점이 많죠. 컴퓨터가 영어권에서 만들어져서 영문자를 표기하기 좋게 되어있다면 우리가 다시 컴퓨터를 만들면 되지 않을까..하는 생각까지 해봅니다. 가능한지는 모르지만..--;

p.s. 개인적으로 주시경 선생이 참 하신 일이 많긴 하나, 그 분의 작업 중에 저는 맘에 안드는 것이 좀 많습니다.--;

익명 사용자의 이미지

>어쨋든 한글을 풀어쓴다는 발상은 >한글의 기본 구조 자체를 >무너뜨리는 일입니다.
한글의 모아쓰기는 한자의 영향을 받아서 그렇습니다. 오래된 책을 보면 가로쓰기가 아니라 세로 쓰기로 되있습니다. 현재의 가로쓰기인 왼쪽에서 출발해 오른쪽으로 진행하는 것과는 정반대인 위에서 아래로, 오른쪽에서 왼쪽으로 단어들이 배열되었습니다.

신문이나 책에서 한자를 없애자고 했을 때 지식인 층에서 X나게 반대했습니다. 한자도 한국인의 언어다! 결국엔 바뀌었습니다.

한글 풀어쓰기는 한글의 컴퓨터에서의 사용 및 인쇄 문화에 새로운 혁신을 가져올 것이 분명합니다. 한글의 풀어쓰기는 한글의 기본구조와 잘 맞습니다.

박영록의 이미지

세로쓰기와 한글의 모아쓰기는 아무런 관련이 없습니다. 한글을 풀어쓰기 하는 게 어째서 한글의 기본구조와 잘 맞다는 거죠? 근거는 없고 주장만 있군요. 음절과 글자가 1:1 대응이 된다는 그 한글 최대의 장점을 무너뜨리려는 이유가 대체 뭐죠? 이해할 수가 없군요. 함부로 한글을 망가뜨리려는 시도를 제발 하지 말았으면 좋겠습니다. 언어학은 전혀 무시한 채 컴퓨터 입장에서만 생각하지 마십시오. 풀어쓰기라니..기가 막힐 따름입니다.

익명 사용자의 이미지

제가 풀어쓰기를 주장하는 것은 아닙니다.

풀어쓰기의 아이디어가 첫가끝에 들어있습니다.

코드 내부적으로는 가변폭 코드라서 풀어쓰기의 방식이면서,
완성형(모아쓰기)의 장점과 조합형의 장점을 모두 수용하고 있는 것이죠.

풀어쓰기를 주장하는 것이 한글을 망가뜨린다거나 한다는
말씀은, 님의 사고방식이 유연하지 않는다는 것밖에 되지 않습니다.

원 글은, 황당한(:-) 풀어쓰기를 하자는 주장이지만, 첫가끝이 결국은
풀어쓰기와 모아쓰기 장점을 수용한 것이라는 말입니다.

그리고, 첫가끝을 가장 손쉽게 구현하는 방법이 바로 풀어쓰기이고,
프로그램적인 테크닉으로, 모아쓰기를 구현하기도 쉽습니다.

프로그램 구현에 관해서 잠시 말씀드리자면,
hanterm 은 내부적으로 만든 한텀조합코드를 사용합니다.

개념적인 설명을 예를 들자면,

'학교' -(코드를 자소로 분리시킴)-> (ㅎㅏㄱ)(ㄱㅛ) -> 다시 화면에 모아씀

개념적으로, 괄호는 모아쓰기이고, 내부적으로 풀어진 코드는 풀어쓰기라는
말입니다. 그리고, 위의 코드를 해석해서, 조합형 글꼴을 *모아서*
화면에 표시하지요.

첫가끝은, 위의 괄호에 해당하는 코드를 넣은 것이라고 생각하시면
됩니다. 순수하게 프로그래밍적 관점으로, 괄호를 모두 없애면
(괄호에 해당하는 폰트를 글폭이 0 인 폰트로 대체시키면 됨)
풀어쓰기잖아요 ? 괄호 단위로 모아서 표현하면 모아쓰기가 되고요.

박영록의 이미지

님의 글은 논지를 좀 빗나간 듯 한데..음..어쨋든..뭔가 잘못 알고 있으신 듯 한 게, 완성형은 모아쓰기, 조합형은 풀어쓰기가 아닙니다. 첫가끝에 대한 글은 저도 꽤 많이 찾아보았는데, 제가 볼 때, 그 글을 쓴 사람이 용어를 잘못 사용한 듯 하더군요. 첫가끝 뿐만이 아니라, 과거에 많이 쓰이던 조합형 한글은 다 원리적으로는 풀어쓰기와 모아쓰기의 혼용의 구현이 아주 손쉽게 가능합니다. 저도 옛날에 도스시절 자체한글을 구현해본 적이 있어서 압니다.

그리고, 그게 풀어쓰기를 옹호하는 근거는 전혀 될 수가 없는 듯 한데요. 풀어쓰기가 한글의 구조적 장점을 해치는 일이라는 것은..조금만 공부를 해보시면 알 겁니다.

익명 사용자의 이미지

박영록 wrote...
> 님의 글은 논지를 좀 빗나간 듯 한데..음..어쨋든..뭔가 잘못 알고 있으신 듯 한 게, 완성형은 모아쓰기, 조합형은 풀어쓰기가 아닙니다.
---
제가 조합형을 풀어쓰기라고 했나요 ?
전 그런 말은 안썼습니다.

> 첫가끝에 대한 글은 저도 꽤 많이 찾아보았는데, 제가 볼 때, 그 글을 쓴 사람이 용어를 잘못 사용한 듯 하더군요. 첫가끝 뿐만이 아니라, 과거에 많이 쓰이던 조합형 한글은 다 원리적으로는 풀어쓰기와 모아쓰기의 혼용의 구현이 아주 손쉽게 가능합니다. 저도 옛날에 도스시절 자체한글을 구현해본 적이 있어서 압니다.

----
그렇습니다. 한글은 초/중/종성으로 분리시킬 수 있으니 모아서 쓸수도 있고
풀어서 쓸수도 있죠.

>
> 그리고, 그게 풀어쓰기를 옹호하는 근거는 전혀 될 수가 없는 듯 한데요. 풀어쓰기가 한글의 구조적 장점을 해치는 일이라는 것은..조금만 공부를 해보시면 알 겁니다.

---
풀어쓰기를 주장한 말이 아닙니다. 짧은 글이니 다시 읽어보시죠.

이어서 글은 님에게 반박하는 글도 아니고, 님과 비슷하게
제 글을 오해하신 분이 계실까봐서 다시 설명하는 글입니다.

첫가끝은 *개선된 풀어쓰기*라는 말입니다. 무슨 풀어쓰기가 한글의 장점을
해친다 아닌다는 말은 아무 의미 없습니다. 그런 *고정적* 사고방식으로는 아무런 발전도 없다는 말이 제 글의 핵심이죠.

코드가 고정폭이라는 말은, 모아쓰기의 특징이고, 완성형은 고정폭 코드이므로
모아쓰기라고 말할수 있겠죠. 조합형은 고정폭 코드라서 모아쓰기의 특징을
가지지만, 간단한 알고리즘으로 초/중/종을 구별해 낼 수 있으니
모아쓰기 및 풀어쓰기의 특징을 가지고 있고요. 유니코드에 있는 한글 역시
간단한 알고리즘으로 초중종을 구별할 수 있으니, 고정폭 코드이면서 풀어쓰기의 속성도 가지고 있는 셈입니다.

(그러니, 조합형과 유니코드 논란은 무의미합니다. 유니코드의 한글은
기존 조합형과 꼭 같다 해도 틀린 말이 아니라는 겁니다.)

그런데, 첫가끝은 *가변폭* 코드이면서, 초중종이 완전히 구별되어 있으니
완전히 풀어쓰기죠.

물론, 위에서 언급하는 풀어쓰기와는 사뭇 다릅니다. 즉, 위에서 쓴 글은
초성과 종성을 구별할 수 없는 풀어쓰기지만, 첫까끝은 초성과 종성의 코드가
틀립니다. 그러니, 개선된 풀어쓰기라고 할 수 있지요.

----------
하지만, 풀어쓰기된 코드를 바로 글꼴로 일대 1 대응시켜 화면에 풀어쓰기를
한다면, 엄청 혼란을 주겠죠. 여기서 부터는 프로그램을 어떻게 만드냐에
딸린 문제입니다. 프로그램을 잘 만들면, 가변폭 코드를 모아서 화면에
모아쓰기를 하는 문제가 됩니다. 박영록 님께서 말씀하시는 부분은,
이쪽 부분에서 주장하는 부분일겁니다.
----------

화면에 풀어쓰기를 하느냐 마느냐는 이제 선택사항 뿐입니다.
(풀어쓰기 영역은 단순히 프로그래머의 몫이 되었다는 말입니다)
무슨 독재자가 아닌 이상, 이미 익숙해진 모아쓰기를 풀어헤쳐진 꼴로
만들 프로그래머가 어디 있겠습니까 ? 첫가끝이 탄생하여
풀어쓰기에게 한 손을 들어주었지만, 프로그래머는 이제, 화면에 모아찍어주어야
하는 부담감을 안게 되었다는 이야기죠.

박영록의 이미지

조합형, 완성형, 풀어쓰기..이런 이야기는..제가 찾아본 첫가끝에 관한 글 중에 잘못 알고 쓰여진 글이 있어서 혹시 님도 그런 오해를 하지 않았나..해서 그런 겁니다. 제가 알기로는 첫가끝에 풀어쓰기가 가능한 아이디어는 있을지 모르나, 원래 풀어쓰기를 할 수 있게 일부러 디자인한 것은 아닙니다. 조합형 역시 풀어쓰기가 가능한 아이디가 들어있으나, 풀어쓰기를 고려해서 만든 게 아닌 것처럼요. 그래서, 님이 혹시 착각하고 있으신 게 아닌가..해서 적어봤습니다. 머, 말씀하신 것처럼 조합형과 유니코드상의 한글은 지금은 거의 같다고 할 수 있죠.

그리고, 풀어쓰기가 한글의 장점을 해친다는 것이 왜 아무 의미가 없죠? 읽는 사람의 입장은 고려하지 않고 개발자의 입장만 생각하면 된다는 건가요? 풀어쓰기된 글을 읽으면서 사람들이 답답해하건 말건 만드는 사람만 편하면 된다는 생각인가요?

그리고..님의 글 중에 이런 부분이 있었죠.
풀어쓰기가 한글의 장점을 망가뜨리는 일이라는 것은 님의 사고가 유연하지 않다는 것이 되겠죠..라는..

이런 얘기를 하신다는 것은 풀어쓰기의 단점을 잘 모르신다는 뜻이죠. 그저, 모아쓰기와 비슷한 표기의 하나의 대안일 뿐이라고 생각하고 있으신 거죠. 그래서, 이것도 일종의 풀어쓰기에 대한 옹호라고 간주하였습니다. 님께서, 풀어쓰기를 하느냐 마느냐가 선택사항이라고 하셨지만, 전 그 선택사항마저도 될 수 없다고 이야기하고 있는 겁니다.

어떤 생각에 반대한다고 해서 그 반대를 고정적인 사고방식으로 몰아붙이는 것은 그것이 오히려 반론을 받아들이지 않으려는 편협한 견해 아닌가요? 오로지 주장할 뿐, 반박은 사양한다는 것인가요? 저는 제가 풀어쓰기를 반대하는 이유를 충분히 이야기했다고 생각하는데요. 유연하지 못한, 고정적 사고방식으로 반대하는 게 아니라 충분한 근거가 있기 때문에 반대하는 것이란 말입니다. 그 근거를 제대로 비판하지도 않으면서 그런 식으로 상대의 사고방식 자체를 비난하는 것은 올바른 토론 자세가 아니라고 생각되는 군요. 그런 식으로 반론을 차단하는 것이야말로 발전을 가로막는 장애라고 생각되는군요.

익명 사용자의 이미지

박영록 wrote...
> 조합형, 완성형, 풀어쓰기..이런 이야기는..제가 찾아본 첫가끝에 관한 글 중에 잘못 알고 쓰여진 글이 있어서 혹시 님도 그런 오해를 하지 않았나..해서 그런 겁니다. 제가 알기로는 첫가끝에 풀어쓰기가 가능한 아이디어는 있을지 모르나, 원래 풀어쓰기를 할 수 있게 일부러 디자인한 것은 아닙니다. 조합형 역시 풀어쓰기가 가능한 아이디가 들어있으나, 풀어쓰기를 고려해서 만든 게 아닌 것처럼요. 그래서, 님이 혹시 착각하고 있으신 게 아닌가..해서 적어봤습니다. 머, 말씀하신 것처럼 조합형과 유니코드상의 한글은 지금은 거의 같다고 할 수 있죠.
>
> 그리고, 풀어쓰기가 한글의 장점을 해친다는 것이 왜 아무 의미가 없죠? 읽는 사람의 입장은 고려하지 않고 개발자의 입장만 생각하면 된다는 건가요? 풀어쓰기된 글을 읽으면서 사람들이 답답해하건 말건 만드는 사람만 편하면 된다는 생각인가요?
>
-------
제가 화면 표기로 풀어쓰기를 하자고 주장하던가요 ?

> 그리고..님의 글 중에 이런 부분이 있었죠.
> 풀어쓰기가 한글의 장점을 망가뜨리는 일이라는 것은 님의 사고가 유연하지 않다는 것이 되겠죠..라는..
>
> 이런 얘기를 하신다는 것은 풀어쓰기의 단점을 잘 모르신다는 뜻이죠. 그저, 모아쓰기와 비슷한 표기의 하나의 대안일 뿐이라고 생각하고 있으신 거죠. 그래서, 이것도 일종의 풀어쓰기에 대한 옹호라고 간주하였습니다. 님께서, 풀어쓰기를 하느냐 마느냐가 선택사항이라고 하셨지만, 전 그 선택사항마저도 될 수 없다고 이야기하고 있는 겁니다.
>
> 어떤 생각에 반대한다고 해서 그 반대를 고정적인 사고방식으로 몰아붙이는 것은 그것이 오히려 반론을 받아들이지 않으려는 편협한 견해 아닌가요? 오로지 주장할 뿐, 반박은 사양한다는 것인가요? 저는 제가 풀어쓰기를 반대하는 이유를 충분히 이야기했다고 생각하는데요. 유연하지 못한, 고정적 사고방식으로 반대하는 게 아니라 충분한 근거가 있기 때문에 반대하는 것이란 말입니다. 그 근거를 제대로 비판하지도 않으면서 그런 식으로 상대의 사고방식 자체를 비난하는 것은 올바른 토론 자세가 아니라고 생각되는 군요. 그런 식으로 반론을 차단하는 것이야말로 발전을 가로막는 장애라고 생각되는군요.

------
??

현재 누구나 모아쓰기를 합니다.
그러니, 반론은 바로 풀어쓰기라고 할 수 있죠.
여기 글 읽는 사람들은 대부분 암묵적으로 풀어쓰기를 바보라고 생각하겠죠 ?
그러므로, 그것에 대한 반론은 바로 풀어쓰기를 조금이나마 옹호하는 글이
반론이 되겠죠. 그런 의미에서 쓴 글이니 오해 마시길

그리고, 첫가끝은 내부 코드상으로, 풀어쓰기를 수용한 셈이 되는 것이고,
그것을 화면에 모아서 쓰는것과는 전혀 *별개*의 문제입니다.

박영록의 이미지

저는 지금 님의 토론 자세를 문제 삼고 있는 겁니다. 님은 먼저, 제가 풀어쓰기가 한글의 장점을 버리는 것이라고 말한 것에 대해 무의미한 일이라고 일축했습니다. 어떠한 설명도 없이 말입니다. 그것이 님이 범한 첫번째 잘못입니다.

그리고, 님은 풀어쓰기에 반대하는 제 글을 고정적 사고방식, 유연하지 못한 사고방식이라고 표현하였습니다. 제가 님이 말씀하신 그 암묵적인 동의를 기반으로 풀어쓰기를 바보 같은 생각이라고 한 것도 아니고 충분한 근거를 들어서 풀어쓰기에 반대하고 있는데 님은 그 근거에 대한 아무런 얘기 없이 제 말을 고정적 사고방식이라고 몰아붙여 풀어쓰기에 대한 반론을 차단하고자 하고 있습니다. 이것이 님이 범한 두번째 잘못입니다. 그리고 반론이 무슨 뜻인지 잘 모르시나요? 단어 뜻부터 좀 잘 알고 말씀하셨으면 좋겠군요.

그리고, 마지막으로 말하지만, 첫가끝이라는 게 풀어쓰기를 수용한 게 아닙니다. 원래부터 한글이라는 글자 체계가 풀어쓰기의 가능성은 충분히 갖고 있는 글자입니다. 첫가끝이 아니라 완성형을 제외한 대부분의 한글 코드 체계는 풀어쓰기로 전환할 가능성을 갖고 있습니다. 그리고, 그것을 모아서 쓰는 것은 별개의 문제라고 하셨는데, 저는 지금 그 별개의 문제를 논하고 있는 겁니다. 논점에서 벗어난 이야기는 이제 그만두셨으면 좋겠군요. 님이 하고 싶은 얘기가 풀어쓰기에 대한 찬반이 아니라 첫가끝에 대한 얘기라면 여기에 반론으로 달지 말고 새로 글을 쓰시던지, 아니면 새로운 주제로 하나 만드시던지 하시죠. 풀어쓰기에 반대하는 글을 반박해놓고 정작 자신은 풀어쓰기를 주장하지 않는다는 말로 정작 자신은 반박을 피해가려 하는 건가요.

익명 사용자의 이미지

박영록 wrote...
> 저는 지금 님의 토론 자세를 문제 삼고 있는 겁니다. 님은 먼저, 제가 풀어쓰기가 한글의 장점을 버리는 것이라고 말한 것에 대해 무의미한 일이라고 일축했습니다. 어떠한 설명도 없이 말입니다. 그것이 님이 범한 첫번째 잘못입니다.
>
> 그리고, 님은 풀어쓰기에 반대하는 제 글을 고정적 사고방식, 유연하지 못한 사고방식이라고 표현하였습니다. 제가 님이 말씀하신 그 암묵적인 동의를 기반으로 풀어쓰기를 바보 같은 생각이라고 한 것도 아니고 충분한 근거를 들어서 풀어쓰기에 반대하고 있는데 님은 그 근거에 대한 아무런 얘기 없이 제 말을 고정적 사고방식이라고 몰아붙여 풀어쓰기에 대한 반론을 차단하고자 하고 있습니다. 이것이 님이 범한 두번째 잘못입니다. 그리고 반론이 무슨 뜻인지 잘 모르시나요? 단어 뜻부터 좀 잘 알고 말씀하셨으면 좋겠군요.
---
오해하신것이 몇개 있으신 것 같아서, 마지막 답장을 달게 되네요.

우선 님에 글에 토를 단 이유만 짧게 말씀드리죠.
풀어쓰기에 대한 주장보다 님의 글이 더 논리적으로 쓰셨습니다.
그래서 님의 글이 더 가치있다고 생각하여서 이 글에 답장을 다는 겁니다.
위의 풀어쓰기 주장은 논리성이 떨어지므로, 그 글에 답장을 달지 않은
것 뿐입니다.

그리고 답장 달때는 어쩔 수 없이 감정섞인 말이 나올 수도 있습니다.
그것 가지고 말씀하시면, 어쩔 도리가 없잖아요. 제가 죄송하다고
말씀드리면 감정이 풀리시겠습니까 ?
(비꼬는 게 아니구요. 어쩔 수 없이 감정섞인 말이 들어가게 되는데,
그것은 한국말 실력이 부족해서 그러는 것일테니 너그러운 이해 바랍니다.
직접 대면하는 말보다 글쓰는게 어려운 법이니까요)

>
> 그리고, 마지막으로 말하지만, 첫가끝이라는 게 풀어쓰기를 수용한 게 아닙니다.
> 부터 한글이라는 글자 체계가 풀어쓰기의 가능성은 충분히 갖고 있는 글자입니다. 첫가끝이 아니라 완성형을 제외한 대부분의 한글 코드 체계는 풀어쓰기로 전환할 가능성을 갖고 있습니다.
---
고드체계가 *가변폭*입니다. 위에서 누군가가 주장한 풀어쓰기와는 다르지만
개선된 풀어쓰기입니다. 뭐, 이점은 님께서도 인정하셨으니 더 이상 언급은
않겠습니다.

> 그리고, 그것을 모아서 쓰는 것은 별개의 문제라고 하셨는데, 저는 지금 그 별개의 문제를 논하고 있는 겁니다.
> 논점에서 벗어난 이야기는 이제 그만두셨으면 좋겠군요. 님이 하고 싶은 얘기가 풀어쓰기에 대한 찬반이 아니라 첫가끝에 대한 얘기라면 여기에 반론으로 달지 말고 새로 글을 쓰시던지, 아니면 새로운 주제로 하나 만드시던지 하시죠. 풀어쓰기에 반대하는 글을 반박해놓고 정작 자신은 풀어쓰기를 주장하지 않는다는 말로 정작 자신은 반박을 피해가려 하는 건가요.

---
님의 글의 가치를 떨어뜨리는 것으로 오해하지 마시기 바랍니다.
제가 말씀드린 요지는,
화면에 풀어쓰고 안쓰고는 프로그래머가 책임질 일이라는 것을 말씀드린 겁니다.

익명 사용자의 이미지

음냐... 궁금해서 그러는건디...

학교 를 풀어쓰면 ㅎ ㅏ ㄱ ㄱ ㅛ
그리고 핚요를 풀어쓰면 ㅎ ㅏ ㄱ ㄱ ㅛ 인데...

두개가 틀리다는걸 어떻게 인식을 하게되죠?

그럼 고운 하루되시길...

준호의 이미지

두벌식 입력을 생각해 보시면 되겠네요. :)

코드상으로는, 첫가끝처럼 초중종 코드가 나누어져 있으면
그런 구별에 대해서는 신경쓰지 않아도 됩니다.

학교 = (초 ㅎ)(중 ㅏ)(종 ㄱ)(초 ㄱ)(중 ㅛ)
하꾜 = (초 ㅎ)(중 ㅏ)(초 ㄲ)(중 ㅛ)

이런 식입니다. 세벌식으로 입력하면 확실하겠죠.

만약 자음을 하나로만 쓰게 된다면 구별하기 어려워집니다.
풀어쓰기를 하더라도 초중종성은 구별해야겠죠.

익명 사용자의 이미지

이 세상의 어떤 언어라도, 발음은 자음과 모음이 섞인 음절 단위로
이루어집니다. 중학교에서 처음 영어를 배울 때 나오는 문제중의 하나가
영어단어를 음절단위로 자르는 거죠..

물론 한글이 한자의 토를 달기 위한 것은 아니겠지만, 우리가 한자를
한음절로 발음하던 방식의 고정관념에서 탈피하지는 못했기 때문에
모아쓰게 되었다고 생각합니다.

박영록의 이미지

음..위의 분은 음절 단위의 언어라는 게 뭔지 잘못 이해하고 있으신 듯 한데...

영어의 발음은 음절 단위로 구분된다고 말하기 힘듭니다. 모음을 기준으로 영어 단어의 음절을 구분하는 것은 사실이나, 영어 발음을 따져보면, 모음 없이 자음만 연속으로 있는 경우는 서로 다른 음절로 분리하지 않습니다. 예를 들자면, stress 같은 단어에서 s, t, r은 각각 서로 다른 음가를 가지고 있음에도 불구하고 한 음절로 간주하죠. 저 단어는 영어에서는 한 음절 단어입니다. 이처럼 영어의 발음이 그 음가와 음절이 1:1 대응이 되지 않습니다. 자음과 모음이 섞이지 않아도 음가가 있는 발음이 나오지만 음절은 또 모음을 기준으로 나뉩니다. 이것은 영어가 음절 단위의 언어가 아니라는 명백한 증거죠. 우리말은 발음의 기본 단위가 음절이지만, 영어는 발음의 기본 단위가 음절이 아닙니다.

그리고 또 하나, 영어의 표기는 더더욱이나 음절에서 멀어집니다. 영어의 표기는 음절의 구분과는 아무! 상관이 없죠. 그래서 영어의 발음 기호는 아예 알파벳과 다른 모습을 하고 있죠. 알파벳이 표음문자임에도 불구하고 음절 단위의 표기가 되지 않는다는 것은 영어 자체가 음절 단위의 발음이 중시되는 언어가 아니라는 뜻이죠. 이에 비해 한글은 한 음절과 한 글자가 정확하게 1:1 대응이 되죠.

한자의 발음과 한글의 모아쓰기를 연관짓는 것은 참으로 본말이 전도된 해석입니다. 생각해보십시오. 우리가 왜 한자를 한 음절로 발음합니까? 중국 사람들이 한자 한 글자를 한 음절로 발음하기 때문입니까? 그게 아니라 원래 우리말이 명확하게 음절 단위로 발음되는 것이기 때문입니다. 우리말에서 자음만으로 나는 소리는 없죠. 반드시 자음과 모음이 모여서 한 음절이 되어야 우리말에서 음가를 갖는 하나의 발음이 됩니다. 한글은 알파벳처럼 상형문자에서 출발해서 자연발생적인 변화를 거친 문자가 아니라 체계적으로 언어학을 공부한 사람들의 연구에 의해 만들어진 것입니다. 처음부터 구어를 표기하고자하는 목적이었으므로 당연히 우리가 어떻게 말을 하고 있는가에 초점을 맞추어서 설계한 거죠. 한자 한글자를 중국 사람들은 한음절로 발음하고 있지 않은데도 우리 나라 사람들은 그걸 굳이 한음절로 발음하는 건 우리 말 자체가 그렇기 때문입니다. 따라서 음절과 문자가 1:1 대응이 되어야한다는 발상은 지극히 당연한 거죠. 한자와 한글은 하등의 관련이 없습니다. 저는 왜 사실이 그렇지가 않은데 억지로 한글과 한자를 연관시키려는지 이해를 못하겠습니다. 한글이 모아쓰기를 한다는 게 한글의 과학성의 결정적인 증거이고 당대 엘리트들이 밤낮 없이 연구한 결과인데 왜 이게 한자의 토를 다는 것이니, 고정관념이니..하는 것들과 연관이 되는지 전 불쾌하기까지 하군요. 좀 알고 말씀해주셨으면 좋겠습니다.

익명 사용자의 이미지

stress가 한 음절이라는 게 뭐가 이상한 거죠? 너무 우리말 중심적으로
생각하고 계시네요.

또 우리말이 발음하는 그대로 표기합니까? 훈민정음 시대에는 그랬겠지만
지금 그렇게 표기했다간 초등학교 안 나왔냐는 소리 듣겠죠.

또 중국사람들이 한자를 한 음절로 발음하지 않는다니.. 무슨 한자인지
예를 들어 보실래요? 생기초뿐이지만 저도 중국어를 공부했는데
그런 말은 금시초문이군요. 우리말과 자음 모음 구분이 좀 다르긴
하지만 한 음절 맞습니다.

박영록의 이미지

stress가 한 음절이라는 게 이상하다고 한 적 없습니다. 음가와 음절이 1:1 대응이 되지 않는다는 점에서 영어는 음절 단위의 언어가 아니라는 근거로 들고 있는 것 뿐이죠. 우리말 기준으로 생각하는 게 아니라, 어느 나라 말이든 음절의 기준은 자음과 모음의 결합입니다. 그런데, 영어는 자음만으로도 그 자체가 음가를 갖습니다. 그런 점에서 영어 발음의 기본 단위는 음절이라고 할 수 없죠. 하지만, 우리말은 자음에 모음이 결합되지 않으면 음가가 없습니다. 곧 발음의 기본 단위가 음절이라는 뜻이죠. 그래서, 우리말은 음절단위의 언어라고 하는 겁니다. 이해하시겠습니까?

우리말이 발음하는 그대로 표기한다고 한 적도 없습니다. 발음하는 것을 한글로 나타낼 수 있다고 했을 뿐이죠. 이 차이를 모르시겠습니까? 영어는 발음의 표시를 위해 별도의 발음기호가 필요합니다. 알파벳과는 다른 모양을 가진 발음기호가요. 하지만, 우리말은 그 발음을 한글로 완벽하게 나타낼 수 있습니다. '국민'의 발음은 '궁민'이죠. 이것 역시 한글입니다. 그리고, 우리말이 발음하는 그대로 표기하는 것은 아니나, 표기의 최대 원칙은 소리나는 대로 적는 것입니다. 소리나는 대로 표기하되 어원을 알아볼 수 있게 표시해주는 것 뿐이죠. 표음문자가 왜 표음문자인지 모르시나요? 그리고, 훈민정음 시대에도 소리나는대로 적지는 않았습니다.

그리고, 중국어는 언어학자들 사이에서도 해석이 엇갈리고 있긴 하나, 차오 같은 발음을 중국에서는 한 음절로 간주를 하지만 언어학적으로 이건 이중모음이 아니라 두 개의 모음이라고 보는 견해가 우세한 걸로 압니다. 두 개의 음절인 셈이죠. 음절의 기준을 어디에 두느냐에 따라 해석이 달라질 수 있는 건 인정합니다만, 중국어의 발음 중에는 이중모음으로 간주해서 한 음절로 보기보다 모음 두 개로 간주해서 두 개의 음절로 볼 만한 발음이 많습니다. 한국어에서 '와'나 '위' 같은 것과는 다르죠. 저런 발음은 자음의 음가가 두 종류의 모음 모두에 영향을 미치니까요. 하지만 중국어에서 차오는 '쵸'가 아니죠. 영어의 관점에서도 저건 두 음절로 표기되는 걸로 압니다. 이런 것들, 당시의 한국 사람이 듣기에는 분명히 두 음절로 들렸을 겁니다. 그럼에도 불구하고 한국 사람들은 한 음절로 발음해왔다는 것은 말의 구조 자체가 다르다는 것을 의미하는 거죠.

익명 사용자의 이미지

전 국어에 대해 잘 모릅니다. 그러니 잘못 알고 있는게 있다면
꾸짖지는 마시고... 알맞게 지적을 해 주시기 바랍니다.

>>음절과 글자가 1:1 대응이 된다는 그 한글 최대의 장점을 무너뜨리려는
이유가 대체 뭐죠?

아다시피 전산적으로 처리하기가 고달프다는 거죠.
물론 세상 만사를 기술적 편의에 의해 재단하자는 뜻은
아닙니다. (아시겠지만...)

>>stress 같은 단어에서 s, t, r은 각각 서로 다른 음가를 가지고 있음에도
불구하고 한 음절로 간주하죠. 저 단어는 영어에서는 한 음절 단어입니다.
이처럼 영어의 발음이 그 음가와 음절이 1:1 대응이 되지 않습니다.

s,t,r이 별개의 음가인 것과 이 단어가 한 음절인 것은 아무런 관련이 없는
얘기입니다. 음가와 음절이 1:1 대응이라는 말은 어불성설인 것으로 생각됩니다.

>>자음과 모음이 섞이지 않아도 음가가 있는 발음이 나오지만 음절은 또 모음을
기준으로 나뉩니다.

우리말 ㅅ,ㅌ,ㄹ도 음가가 있습니다.

>>이것은 영어가 음절 단위의 언어가 아니라는 명백한 증거죠.
우리말은 발음의 기본 단위가 음절이지만, 영어는 발음의 기본 단위가 음절이
아닙니다.

제가 잘 모르는 얘기입니다. -아마 제가 무식해서 그럴겁니다.
영어 사전보면 영어도 발음의 기본 단위가 음절로 되어 있는 것 같던데요...

>>영어의 표기는 음절의 구분과는 아무! 상관이 없죠. 그래서 영어의 발음 기호는 아예 알파벳과 다른 모습을 하고 있죠.

영어는 풀어쓰기죠. 음절구분이 되지 않을 수밖에 없습니다. 물론 음절 구분 기호를
도입할 수는 있겠습니다만...
글구 알파벳하고 발음 기호는 별개입니다. 각 민족은 자기들의 소리를 그리기 위해
알파벳을 차용했을 뿐입니다. 자기네 소리를 표현하기 위해 만든 한글과는 조금
다릅니다.

>>알파벳이 표음문자임에도 불구하고 음절 단위의 표기가 되지 않는다는 것은
영어 자체가 음절 단위의 발음이 중시되는 언어가 아니라는 뜻이죠.

이해할 수 없는 말입니다.

>>한자의 발음과 한글의 모아쓰기를 연관짓는 것은 참으로 본말이 전도된
해석입니다. 생각해보십시오. 우리가 왜 한자를 한 음절로 발음합니까?
중국 사람들이 한자 한 글자를 한 음절로 발음하기 때문입니까? 그게 아니라
원래 우리말이 명확하게 음절 단위로 발음되는 것이기 때문입니다

역사적으로 한글은 한자의 발음을 고정시키기 위한 용도로도 사용되었습니다.
또 그러한 용도에 알맞게 창제되기도 했고요. - 오히려 우리말을 정확히
표현하기 위한 용도로 보다는 한자음을 정확히 보정하기 위한 용도에 더 심혈을
기울였는지도 모릅니다.
우리말이 매우 음절지향적이라는 것은 그 허다한 받침을 보더라도 알 수 있을
것입니다.제가 아는 한 영어, 중국어, 일어에는 거의 받침이 없습니다.
언어사적으로는 받침이 점차 사라져 가는 것이 자연스러운 경향이라고도
하더군요. 그러나 우리말에는 받침이 넘쳐나죠. 그 이유는 우리말 단어들의
상당수를 차지하는 한자 단어 때문일 거라고 봅니다. 한자 단어들의 음을 보존하기
위해, 그 성조를 하나의 단어에서 보정하기 위해 받침들이 강화된 거죠.
중국 글자 한나에 하나의 발음값을 주기 위해 한글이 한 음절 당 하나의 글자로
만들어졌을 가능성은 매우 크다고 봅니다. 물론 그 이전부터 한자음에 맞도록
우리말이 보정되어 왔기도 하고요...

>>영어는 자음만으로도 그 자체가 음가를 갖습니다. 그런 점에서 영어 발음의
기본 단위는 음절이라고 할 수 없죠. 하지만, 우리말은 자음에 모음이 결합되지
않으면 음가가 없습니다. 곧 발음의 기본 단위가 음절이라는 뜻이죠. 그래서,
우리말은 음절단위의 언어라고 하는 겁니다. 이해하시겠습니까

잘 이해가 안됩니다. 자음이든 모음이든 다 음가는 있는 것입니다.
ㅅ도 물론 음가가 있습니다. 물론 모음이 붙어야 음절을 이루지요.
이건 영어도 마찬가지라고 생각합니다.
또, 역사적으로는 우리말 역시 어두에 복자음이 있었던 것으로 압니다.
즉, (ㅄ,ㅏ,ㄹ)같은 경우죠. 지금은 (ㅆ,ㅏ,ㄹ)로 발음하고 있습니다만...
이건 언어의 경향성이죠.

박영록의 이미지

음..국어에 대해서 잘 모르신다면서 어떻게 어불성설이라는 말까지 써가면서 반박하는지 모르겠군요. 잘 모르는 부분에 대해 지적해달라고 하셨으니 지적해드리겠습니다.

먼저, 처음 이유를 모르겠다고 하신 것. 이건 음절과 글자가 1:1 대응이 된다는 게 왜 장점인지 모르겠다는 뜻입니까? 당연히 이건 가독성 때문입니다. 표음문자의 전제 조건은 읽기 쉬워야한다는 것입니다. 한 글자가 한 음절과 1:1 대응이 된다는 것은 그만큼 읽기 쉽다는 뜻이죠. 이게 한국어를 다른 나라 사람들이 배우기 쉽다고 하는 결정적인 이유입니다. 일본어의 히라가나와 가다까나도 이런 면에서 보면 음절과 글자가 1:1 대응이 된다는 점에서 퍽이나 괜찮은 표음문자라고 할 수 있죠. 표현력이 좀 딸리긴 하지만.--; 반면 영어 같은 경우는 음절과 표기가 거리가 멀죠.

그리고 s,t,r이 별개의 음가인 것과 stress가 한 음절인 것은 아무 관련이 없는 얘기라고 하셨는데, 당연하죠. 도대체 제 글을 어떻게 이해하신 겁니까? 아무 관련이 없기 때문에 영어는 음절 단위의 언어가 아니라고 말한 건데.. 음절과 발음이 따로 논다는 것은 음절이 발음의 기본 단위가 아니라는 겁니다. 이게 왜 이해가 안됩니까? 더 쉽게 말씀드릴까요? 영어 발음의 기본 단위는 음절보다 더 작은 단위입니다. 발음기호로 표시되는 것들이죠. 한국어의 ㅅ,ㅌ,ㄹ도 음가가 있다고요? 그럼 ㅅㅌ레ㅅ 하고 말하면 저게 한국말이 됩니까? 음가가 있다는 말의 의미는 그 자체로서 단어 속에서 발음을 갖는다는 이야기입니다. 우리말에서 ㅅ만 따로 말이 되지는 않습니다. 초성, 중성, 종성은 발음을 구조적으로 나눈 것이기는 하나, 실제 발음의 '기본 단위'는 아니라는 겁니다. 한 발음을 형성하는 음절이 발음의 기본 단위죠. 우리말의 발음에서 ㅅ,ㅌ,ㄹ 같은 건 없습니다. 발음으로 인정이 안된다는 거죠. 이런 현상은 알타이어족에서 공통적으로 나타나는 현상입니다. 다만 우리 나라 이외에는 제대로된 표음문자를 갖지 못했고 주변 비알타이어족의 영향으로 그런 특성이 사라져갈 뿐, 알타이어족의 고어를 보면 우리나라말처럼 철저한 음절 단위의 언어임을 알 수 있습니다. 일본 같은 경우는 음절단위의 표음문자가 있어서 우리말과 비슷하게 음절단위의 언어가 잘 보존되고 있죠.

그리고, 한자와 한글의 관계. 이거야말로 어불성설입니다. 저번에 제가 본말이 전도된 해석이라고 말한 적이 있는데, 한자 때문에 우리말이 영향을 받고 한글까지 모아쓰기를 하게된 게 아니고, 한글이 원래 음절 단위이기 때문에 한자를 그렇게 발음하게 된 겁니다. 그리고 한자를 그렇게 발음하기 때문에 한자를 한글 한 글자로 표기하는 거구요. 만약, 한자와 중국어의 영향 때문이라면 오히려 두 음절로 발음하는 한자가 있어도 하나도 이상하지 않습니다. 중국어의 한자 발음을 조선시대 사람들이 들었다면 상당수의 발음을 두 음절로 간주했을 테니까요. 실제로 일본에서는 한자를 두 음절로 발음하고 있죠. 그리고 표기의 합리성에서도 중국어의 차오 같은 걸 한글로 모아쓰기로 표현하는 것보다 영어의 풀어쓰기로 표현하는 것이 더 낫습니다. 중국어의 음절 단위가 한국어와 유럽어의 경계에 있긴 하나 표기에 있어서는 유럽어권에 가깝거든요. 이런 점에서 봐도 모아쓰기의 유래를 한자나 중국어에서 찾는 것은 그야말로 어불성설입니다.

역사적으로 한글이 한자음을 고정시키는 용도로 사용되었다구요? 잘 모르면서 함부로 그런 말씀을 하시지 말았으면 좋겠군요. 실제 훈민정음이 사용된 예에서 한자 음이 기록되어 있는 것은 거의 찾아보기 어렵습니다. 훈민정음 창제 이후 발간된 언해들을 봐도 한자의 음이 기록된 것은 전무하다시피하고 그 외 기타 기록에서도 한자의 음을 한글로 기록한 예는 역사적으로 거의 없습니다. 중국어와 한자의 영향으로 모아쓰기를 하게 되었다는 주장이 어불성설이라는 결정적인 증거죠. 역사적으로 봐도 한글은 한자와 독립적으로 발전해왔고 우리말의 구어를 기록하기 위해 사용되었다는 것은 명백합니다. 한자음에 맞도록 우리말이 보정되어 왔다는 것 또한 얼토당토 않은 이야기입니다.

그리고, 우리말에서 복자음이 있었다는 이야기는 왜 나오는지요? 모아쓰기와는 하등의 관련이 없어보입니다. 게다가, 님이 드신 예에서 ㅄ은 원래 당시에도 발음이 ㅆ이었습니다. 이 때의 ㅂ을 된소리 ㅂ이라고 합니다. 당시는 된소리를 표기하기 위해서 ㅂ이나 ㅅ 등을 붙였습니다. '까'같은 경우는 'ㅅㄱㅏ'로 표기가 되었죠. 복자음이라고는 하지만 발음의 복자음이 아니라 된소리 표기를 위한 복자음이었을 뿐입니다.

익명 사용자의 이미지

어노니로 답글을 달게 되어 죄송합니다. 어짜피 이렇게 된 거 기냥
밀어 부치겠습니다.
간단히 몇가지만 말씀드리겠습니다. - 제대로 답변하려면 많은 자료를 뒤져
보아야 할 것이지만 제가 그쪽 계통에 밝은 사람도 아니고 현재 저의
관심사도 아닌 관계로...

1)어불성설이란 말은 말의 앞뒤가 안맞는다는 뜻으로 쓴 겁니다.
불쾌하셨다면 사과드리겠습니다.

2)stress의 경우 영어로는 분명히 한 음절입니다. 그러나 우리 말로는
'스트레스' 사 음절입니다. 우리 말을 기준으로 영어를 설명하려 해서는
안되리라고 생각합니다.
-영어는 음절과 발음이 따로 노니 음절 단위의 언어가 아니라는 말씀은
제게는 참 이해가 아니되는 말입니다. -stress는 한 음절로 발음되며,
실제로도 한 음절인데 말입니다... (저는 님께서 복자음에 지나치게 신경을
쓰신 게 아닐까 하고 생각했습니다. 우리 말에는 복자음이 거의 죽었으니까...)

3)한글이 한자의 발음 기호 용도 또한 가지고 있었다는 것은 거의
틀림없는 역사적 사실일 겁니다. 당시에는 우리 말 음가가 없는 자모도
마련해 둔 것으로 압니다. 한자 발음 전용으로요...
- 제가 자료를 찾아 보아야 하겠으나 여력이 아니되는군요...

4)한자를 한글로 발음 표기한 것의 대표적인 것이 훈민정음 아닌가요?
한자를 쓰고 거기다가 한글로 발음을 밝혀 놓았지 않습니까?
셍종엉젱... - 한글은 한자의 발음기호 역할한 거 맞지 않나요?

5)복자음 얘기는 님께서 꺼내신 stress 건에 참조가 되도록 말씀 드린 겁니다.
ㅄ가 단지 ㅆ과 같은 소리 즉, 된소리 기호였는지... 저의 기억으로는 그렇지
않거든요. 제가 알기로는 햅쌀이라는 단어는 해 + 쌀로 분석되고, 그것이
해 + ㅂ + 쌀 로 발음되는 것은 예전의 (ㅄ,ㅏ,ㄹ)에서 복자음 ㅄ에 분명히
ㅂ와 ㅅ 발음이 살아 있었으리라는 추정을 가능케 하는 것이라고 봅니다.
즉, stress의 str과 다를 바가 없는 거죠...

6)영어가 음절 단위의 언어가 아니라는 님의 주장에 대한 참조 문서라도
혹 있으면 알려 주시겠습니까? 제게는 잘 이해가 아니되어서...

7)한자음에 맞도록 우리말이 보정되었다는 것도 어느정도 일리가 있는 말로
알고 있습니다. 예컨대 중국말에는 사성이 있고 우리말에는 없습니다.
사성의 효과를 한 음절에서 수용하기 위해 받침이 많이 활용된 것으로 알고
있습니다. 예컨대 거성을 보정하기 위해 'ㄱ'받침을 넣는다든지 해서
말입니다. 아마 관련 연구가 꽤 있을 거라 믿습니다.

박영록의 이미지

두 가지만 얘기하면 될 것 같군요.

1. 먼저, 영어가 음절 단위의 언어가 아니라는 이야기.
stress를 영어 발음기호로 쓰면 [stres]입니다. 여기서 영어 원어민은 s,t,r,e,s를 각각 따로 떼어서 발음할 수 있습니다. 즉, 발음의 최소단위가 음절인 [stres]가 아닌, s, t, r, e, s라는 얘깁니다. 한국말은 어떤가요? 스트레스라는 말에서 ㅅ,ㅡ,ㅌ,ㅡ,ㄹ,ㅔ,ㅅ,ㅡ 이렇게 따로 떼서 발음이 가능한가요? 물론 가능하지 않죠. 즉, 발음의 최소 단위가 초성, 중성, 종성이 아닌 음절이란 뜻입니다. 이래도 이해가 안되시나요? 참조 문서를 요구하셨는데, 온리인으로 볼 수 있는 문서는 잘 모르겠습니다. 국회도서관 같은 데 가서 언어학 관련 문서를 찾아보면 상당히 많은 자료가 나올 겁니다. 미국인이 한국어를 연구한 논문 중에도 한국어의 발음의 특수성을 지적한 논문이 있습니다. 제가 시간이 나면 논문 제목을 찾아보죠.

2. 그리고, 한글의 역사적 활용에 관해.. 님의 말씀처럼, 훈민정음의 활용 중에 한자어를 적고 거기에 한글을 병기한 것이 있긴 합니다. 그러나, 이걸 발음기호로 이해하는 것은 조금 무리한 해석이 아닐까 싶군요. 이 한자어는 발음이 이런 것이다..라고 알려주기 위해 그렇게 썼다기보다, 훈민정음의 표기 원칙-'소리나는 대로 적되, 어원을 밝혀 쓴다.'에 맞춰 한자어는 어원을 중심으로 쓰되, 소리나는대로 적어준 것일 뿐이죠. 이를테면, 라틴어로 santa가 영어로 saint인데 이걸 영어로 쓸 때 santa(saint)라고 표기하는 걸 두고 영어가 라틴어의 발음기호 역할을 한다고 하진 않죠. 표현하려는 한자의 발음이 이거다..해서 병기한 게 아니고, 표현하려는 한자가 우리말로는 이거다..라는 뜻에서 병기한 것입니다.

그리고, 만약 훈민정음이 발음기호 역할을 고려해서 만들어졌다면 천자문부터 훈민정음 음이 표기된 것이 있어야하지 않을까요? 그리고, 훈민정음으로 발간된 언해가 나오기 전에 원문에 음만 병기된 것도 있어야하지 않을까요? 실제로, 한자를 쓰던 사람들은 그 음을 한글로 적어야할 필요가 없었다는 점을 생각해보십시오.

그리고, 처음 말씀하신 것은 훈민정음이 만들어진 이유 아니었던가요. 그 이유 중에 하나가 한자음을 표기하기 위해서라고 하셨었던 걸로 기억나는데.. 제 글은 거기에 반박하기 위한 글이었습니다. 만들어지고 난 이후를 논한다면야, 당장 지금도 한자어의 독음을 달기 위해 한글을 쓰기도 하는데..--; 이건 논의 대상이 아니죠. 왜 아니냐면, 한자의 음 때문에 한글이 영향을 받았다는 근거가 될 수 없기 때문입니다. 이런 발상 자체가 문제가 있는 것이, 표음문자는 말이 먼저 있고, 글자가 있는 것입니다. 한자음을 '왜 우리가 한 글자로 발음하는지' 그 이유를 생각해보십시오. 만약 정말 중국의 한자음 발음에 충실하고자 했다면 한자 한 글자를 굳이 한 음절로 발음할 이유가 전혀 없습니다. 다시 말하지만 한자음이 한글에 영향을 미쳤다는 해석은 본말이 전도된 해석입니다. 이것도 이해가 안되십니까? 한자음을 한 글자로 발음하는 것 역시 우리말 자체의 특성입니다. 따라서 훈민정음은 우리말의 특성에만 맞게 만들면 당연히 한자 한 글자는 한 음절로 발음므로 훈민정음으로도 한 글자일 수 밖에 없습니다. 이해가 되십니까?

그리고, 우리말 음가가 없이 한자 발음 전용의 자모가 있었던 적은 없습니다. 이건 거의 확실합니다. 현대 우리말에서 음가가 없는 자모가 있을 수는 있겠지만 당시에는 모두 분명히 음가가 있던 자모입니다. 우리말에서 음가가 없는 자모라면 한자라고 해서 어떻게 우리말로 발음할 수 있겠습니까. 우리말로 표기되고 우리가 발음할 수 있다면 그것은 이미 우리말인 것입니다.

그리고, 중국어가 우리말에 영향을 미쳤다는 것은 틀린 얘기가 아닙니다. 당연한 거죠. 이웃한 언어가 서로 영향을 받을 수 밖에 없는 건 특별한 얘기도 아니죠. 하나, 중국어 때문에 그걸 고려해서 한글이 영향을 받았다는 주장은 문제가 있습니다. 이를테면, 중국어->우리말->한글, 이건 가능하지만, 이걸 중국어->한글로 보는 것은 논리적 비약입니다. 이건 훈민정음 첫 문장만 봐도 알죠. 나랏말이 중국과 달라.. 에서부터 중국어와는 다른 나랏말, 우리말을 표기하기 위한 목적이 분명하죠. 따라서, 훈민정음이 중국어의 영향을 받았다거나 한자 발음의 표기를 위한 목적이 있었다는 주장은 잘못된 것입니다. 관련 연구가 꽤 있다고 하셨는데, 이건 아마 님께서 중국어가 우리말에 영향을 준 것과 착각하신 게 아닌가 싶군요. 물론, 한글이 자연발생적 문자라면 님의 주장도 충분히 타당성이 있겠죠. 하지만, 이건 인위적으로 만든 것이고 중간에 변천 과정에도 정부가 깊이 개입해있으며 그 창제 목적이 분명하고 초성, 중성, 종성의 하나하나가 창제 원칙이 밝혀져 있는 것인데, 엉뚱하게 있지도 않은 목적을 갖다 붙이는 것은 잘못입니다.

익명 사용자의 이미지

이제야 읽었습니다.
마지막으로 간단히...
1.stress: 아시다시피 영어와 우리말은 발음 구조가 달라요.
안정환을 우리는 '안'이라고 발음하지만, 저쪽 사람들은 '안느'라는
식으로 발음하죠. 우리랑은 자음 발성 자체가 다르다는 거죠...
암튼 제 얘기의 요지는 영어랑 우리말은 발음 구조가 다르기 때문에
우리말의 관점에서 영어를 보면 안되리라는 거였습니다.

2.반복해서 말씀 드릴 필요는 없겠습니다.

마지막으로...
이 논쟁의 감정적 발단은, 적어도 제 생각엔 이렇습니다.
기술적 이상주의에 의해 전통과 문화가 재단되어서도 안되지만,
전통과 문화에 얽매여 기술적 진보의 발목을 잡아서도 안될 것이라구요.
저 역시 풀어쓰기 반대입니다.
그러나 한글의 과학성을 훼손시키기 때문에 반대하는 것은 아닙니다.
-이 말을 하고 싶었습니다.

익명 사용자의 이미지

stress를 한 음절이라고 하는 건
음절의 뜻을 넓게 생각하신 듯...

소리마디는 홀소리(모음) 하나를 중심으로
이루어진 하나의 덩이소리라고 사전에 나와 있던데요.

영어를 읽을 때 구분하는 마디를
우리말의 음절이나 소리마디로
번역하는 것이 바람직할까요?

익명 사용자의 이미지

추신)영어는 풀어써도 읽는데 별 어려움이 없습니다.
물론 한국어는 그렇지 않습니다. 결정적인 차이는 한국어에는
종성이 매우 발달했다는 것일 겝니다.
저는 한국어에서의 종성 발달은 중국어 발음의 영향으로 봅니다.
세종이 자-모 체계가 아닌 초-중-종 체계를 선택하고, 한 음절당
한 글자의 모아쓰기 체제를 선택한 건 우리말 구조상 매우 당연하다고
봅니다만, 그러한 우리말 구조가 성립된 배후에는 중국어의 영향이 매우
컸다고 생각합니다.

익명 사용자의 이미지

Anonymous wrote...
> 추신)영어는 풀어써도 읽는데 별 어려움이 없습니다.
> 물론 한국어는 그렇지 않습니다. 결정적인 차이는 한국어에는
> 종성이 매우 발달했다는 것일 겝니다.
> 저는 한국어에서의 종성 발달은 중국어 발음의 영향으로 봅니다.
> 세종이 자-모 체계가 아닌 초-중-종 체계를 선택하고, 한 음절당
> 한 글자의 모아쓰기 체제를 선택한 건 우리말 구조상 매우 당연하다고
> 봅니다만, 그러한 우리말 구조가 성립된 배후에는 중국어의 영향이 매우
> 컸다고 생각합니다.

대체적으로 동감이 가는 내용이네요

한글 덕택에 한자음이 보존이 잘 되었다는 말도 일리가 있습니다.

여기, 님께서 쓰신 내용의 논리를 뒤집어 생각하고 있는 곳도 있네요.

http://www.hanja.com

가보시면 아주 황당하고 재밌습니다.

Just for FUNNNNNNNNNNNN !!

익명 사용자의 이미지

으악!!
(가봤습니다...^^)

익명 사용자의 이미지

하지만 님의 의견에도 약간의 문제가 있습니다.
바로 이응의 처리입니다.
첫소리 이응(ㅇ)이 반드시 묵음(소리없음)이 되지 않기 때문입니다.
낱말끼리 합쳐질 때, 다시 제 소리를 가지는 경우가 가끔 있다고 합니다.

한글을 풀어쓰자면, 첫소리 이응을 항상 없애고 써야 하는데, 그 '가끔'을 사람이 일일이 기억하고 있어야 합니다.
전산입력은 컴퓨터 프로그래머가 프로그램을 잘 짜야 하지만요.
아니면, 옛이응을 부활시키는 방안을 검토해야겠지요.

풀어쓰기는 이어쓰기나 연음법칙의 표현에는 좋지만...
낱말의 분석에는 상당히 어렵답니다.
즉, 모아쓰기 한글의 좋은 점이 풀어쓰기 한글에서는 좋지 못한 점이 되죠.

또한, 모아쓰기가 한글의 한자 발음기호화라면, 풀어쓰기는 한글의 서양 자모의 발음기호화이기도 하구요.
(풀어쓰기를 반대하는 사람들의 주장입니다. 저 개인은 모아쓰기나 풀어쓰기 모두 필요하다고 생각합니다.)

ㅐㅇㄷㅜㄱㅏㅂㅅㅡㄴㅓㄹㅁㅏ <== 이건 무얼 뜻할까요?
앵둑앖으넒아 일까요?

처음에는... 굉장히 불편할 것입니다.
'첫소리 이응'이나... '겹자음 종성'에 대한 처리가 되지 않는다면 ....

익명 사용자의 이미지

풀어쓰기로 가장 유명한 것은, 기울여 풀어쓰기죠.

세로쓰기를 무시하시면 안되겠죠. 첫가끝에는 풀어쓰기의 아이디어가
들어있으니까요.

조합형 및 완성형의 장점을 모두 모았다는 것이 바로 첫가끝이라고
되어있습니다.

http://trade.chonbuk.ac.kr/~leesl/code/isounicode.html#2

첫가끝은 고정바이트길이의 조합형이 아닌, 가변폭 조합형이라고
보시면 되며, 바로 풀어쓰기의 아이디어가 들어있죠.

현재 유니코드의 한글은, 기존 조합형을 완전히 표현하고, 완성형의 장점
(1대1 매핑)을 가지고 있지만,

첫가끝을 쓰면, 두가지 장점을 동시에... 그리고, 옛한글을 완벽히(?)
구현할 수 있다는군요.

위의 링크를 잘 읽어보시길~

익명 사용자의 이미지

아참...
첫가끝은 유니코드에 포함되어있습니다.

첫가끝을 쓰면 단점은...

폰트와 일대일 매핑이 어렵게 되겠죠.
초성이 없는 글꼴도 존재해야 할것이고...
옛글자도 지원하면 좋고,

첫가끝은 가변폭 이기 때문에 이를 지원하려면
관련 프로그램이 하루 빨리 개발되어야 겠죠...

익명 사용자의 이미지

장난하십니까?

님의 의견을 무시하는건 아니지만...

한글가지고 장난치시는걸로 밖에 보이지 않는군요.

처음에는... 굉장히 불편할거라고 말씀하시는데...

몇백년후에 편해지면 뭐합니까...

프로그램 개발언어처럼 몇몇 사람이 쓰는게 아니라는걸 좀 생각해 보세요.

익명 사용자의 이미지

ㅁ ㅏ ㄹ ㄷ ㅗ ㅇ ㅏ ㄴ ㄷ ㅚ ㄴ ㅡ ㄴ ㅅ ㅗ ㄹ ㅣ

익명 사용자의 이미지

ㄷㅗㅇㄱㅏㅁ-.-;

익명 사용자의 이미지

당연히 모아 쓰도록 디자인된 자모를 늘어 놓으니 읽기가
깝깝하죠. 만일 한글을 풀어 쓰게 된다면 풀어쓰기용 자모가
디자인되어야 겠져...

-근데 그날이 올려나...

익명 사용자의 이미지

질문에 대한 정답을 줄 수 있는 좋은 책이 있습니다.

컴퓨터속의 한글 이야기 - 김경석

ISBN 89-7316-116-4

이 책에는 유니코드, KSC 5601, UTF8 등 코드에 대해서 많이 나와있습니다.

익명 사용자의 이미지

님들 글 잘봤어여.전 전자전기공학부 재학중인 학생이거든여.
인코딩,디코딩 이란 말 많이 쓰져.익스플로러 나 넷스케이프에도 보면 language encoding 이라구 있더라구여.
디지털 시스템 시간에 배운것중에서,encoder,decoder 가 있어여
4-to-1 mux는 입력이 4개가 들어오면 그 중에서 한 입력을 택해서출력으로 해주는 것이고, 그 반대 개념이 encoder입니다.
전산쪽에서 쓰는것도 비슷하리라구 생각하네여..
헤헤..잘 모르겠당..

익명 사용자의 이미지

모두들 답변에 감사드립니다.

그런데 아직까지 텍스트파일과, 이진파일의 구분이 힘든데요..

익명 사용자의 이미지

#incldue

int
main ()
{
FILE *txt = NULL;
FILE *bin = NULL;
char *sample = "abc\n";

if (!(txt = fopen ("sample.txt", "w"))) /* as text file - default */
perror ("");
else if (!(bin = fopen ("sample.bin", "wb"))) { /* as binary file - 'b' flag */
perror ("");
fclose (txt);
} else
goto FILE_OP;
exit (1);

FILE_OP:
fprintf (txt, sample);
fprintf (bin, sample);

fclose (txt);
fclose (bin);

return 0;
}

결과로 나온 sample.txt, sample.bin 두 file을 dump 해보시면 text file과 binary file은 같은 작업이 다른 결과를 낳는걸 확인하실 수 있을겁니다.

cdpark의 이미지

> 결과로 나온 sample.txt, sample.bin 두 file을 dump 해보시면 text file과 binary
> file은 같은 작업이 다른 결과를 낳는걸 확인하실 수 있을겁니다.

Unix 쪽에선 같은 결과입니다.

MS-DOS(와 그 계승자들)에서는 다르고요.

CP/M 계열이나 MacOS 계열은 정보가 없네요.

익명 사용자의 이미지

도스가... CP/M을 계승한 부분이 많으니... 아마도 결과도 같지 않을까요?

익명 사용자의 이미지

허걱!
음....
예를 들겠습니다. 메모장같은 텍스터 에디터로 'A'를 타이핑하고 저장한다음 Hex Edit로 읽어 보세요. 그러면 41 이라고 되어 있을 겁니다.(16진수 이므로) 이 41 이라는 숫자는 어느 에디터로 보든 'A'라고 출력이 될겁니다. 이런형식으로 이미 알려진 코드에 의해 작성되는 파일을 텍스트파일이라고 합니다.

근데 'A'를 01 로 정하여 파일에 저장하고자 한다면 프로그램을 작성하여 저장해야 겠지요? 그리고 그걸 정한 자신 혹은 그걸 아는 사람만이 01을 'A'라고 판단 할겁니다. 이렇게 특정한 코드나 필요에 의한 규칙으로 만들어지는 파일을 이진파일이라고 합니다. 이진파일은 그걸 읽어들일 수 있는 전문프로그램이 있어야만 합니다. 다시말해 그림판 따위를 이용해 'A'를 쓴다음 메모장으로 읽어 보세요.

익명 사용자의 이미지

3번에 대해서만 다시 설명하면,
0번부터의 32개의 code는 컴퓨터제어용 code로 사용됩니다. 따라서 이부분을 사용하게되면 이미 text file로 읽어들일수가 없게 됩니다. 예를 들어서 줄바꿈 같은 LF나 CR같은 code가 제어용 code로 text file에서 사용되는 데 이를 사용할 수 없게 0부터 255까지 모든 code를 쓰게 되는 file은 text file이 될 수 없겠죠. 이 경우는 binary file로 저장해서 제어코드를 해석하지 않고 그냥 읽고 쓰게 되는 것이죠.

익명 사용자의 이미지

제어코드를 아스키셋 내에서 주어진 의미로 해석하는 것은 일부 application에 제한된 관점이고 시스템 입장에서는 제어코드나 프린터블코드나 바이너리 정보일 뿐입니다. 실제로 제어코드가 포함된 file을 text file로 open해서 사용해도 프로그램엔 아무런 이상이 없습니다. 다만 도스계열의 OS에서는 바이너리 파일을 텍스트파일로 열었을때 바이너리 값 0x0a와 0x0d를 있는 그대로 처리하지 않고 시스템콜이 임의로 변환을 해버리므로 문제가 되서 이 변환을 수행할지 여부에 대한 옵션을 두고 이걸로 텍스트파일과 바이너리파일을 구분하고 있을 뿐입니다.

익명 사용자의 이미지

간만에 답글을 달수 있는 문제네요. ^^;
1. 위에 열거하신 코드명의 차이점은 문자코드의 차이점을 말하는 것으로 답변이 될까 합니다. 예를 들어 '가'를 표현하고자 할때 각기 다른 코드로 저장되는 거지요. 따라서 유니코드로 저장된 '가'는 유니코드를 지원하는 문서편집기 따위로 읽어들여야 한다는 거지요. (문서작성기를 이용해서 실험해 볼 수 있어요.)

2. 키보드에서 키가눌리면 키보드는 대응되는 신호를 컴(본체)에 전달하게 됩니다. 이때 컴에서는 인터럽트라는 것을 발생시켜 키보드의 신호를 분석하여 저장(메모리)하게 됩니다. 여기까지는 BIOS가 처리합니다. 현재의 OS(멀티테스크가 가능한, Windows, Linux의 X Windows등)는 이걸 이벤트 루틴에 집어넣어 각프로그램으로 전달합니다. 우선권을 갖는 프로그램이 이걸 읽어 들여 출력을 시켜 주지요. 우선권이 편집기 프로그램이라면 자판배열에 따라 입력된 코드를 폰트(글자의 모양이 담겨있음)에서 찾아 화면에 뿌려 줍니다. 여기서 기능키따위를 분석하게 되는 경우가 많습니다. 그리고 저장을 시킬때 위에서 말하는 코드로 저장을 시키게 됩니다. 현재의 유니코드는 행망용 한글코드에 한글을 몇글자 추가시킨 것으로 알고 있습니다. 한글을 컴퓨터에서 표현하고자 한다면 많은 방법이 존재하지만 조합형한글이 모든한글을 표현할 수 있다는 것을 아시게 될겁니다. 여기에 대해서는 논란이 많으므로 생략합니다.(알면 열받아요. -.-)

3. 이답변 역시 위에서 이어지는 것으로 저장하는 방식에 약간의 차이를 둡니다. 예를 들면 1을 저장한다면 (16비트 기준) 이진파일은 000000000 00000001 (01h) 로 저장시킵니다. 이걸 CPU에서 연산한다면 1로 인식하여 사칙연산을 수행했을 경우 원하는 답을 얻을 수 있습니다. 단, 우리가 알기 쉽게 화면에 보이고자 할 경우 코드변환을 거쳐야 합니다. 1은 ASCII Code (아스키코드) 49 (31h) 가 그 대응값입니다.
텍스트 파일은 1을 ASCII 값 그대로 00000011 00000001 (31h)로 인식하게 됩니다. 이걸 CPU에서 연산한다면? 글쎄요, 원하는 답이 나오지 않겠지요? 위글에서도 언급되었지만, 텍스트 파일은 특수코드(탭, 라인피드, Beep등)를 포함하여 저장을 하게됩니다. 우리는 이걸 TXT, DOC(지금은 MS Word가 사용하지요)등으로 텍스트 파일임을 알려 주는 겁니다.
정리하자면 이진파일은 그파일을 작성한 프로그머나 몇몇 사람만이 알아볼수 있고 텍스트 파일은 알려진 규칙을 알고 있는 누구나 알아 볼수 있다는 것입니다.

마지막으로 코드란 자신의 의지를 한사람 이상에게 전달하고 하는 매개체 입니다. 여기에 많은사람이 알아들을 수 있도록 규칙을 정하고 이를 관리함으로써 약속되어 지는 것이지요. 만일, 잘못된 규칙을 정한다면 자신의 의지를 충분히 전달하지 못하게 되겠지요. 지금의 한글코드는 몇사람의 뜻과 상업적인 어느회사로 인하여 자신들의 기준으로 충분하다고 여겨지는 한글의 일부 만을 유니코드라는 이름으로 표준화 시켰습니다. 한국사람은 한글 전부를 사용하여 자신의 의지를 표현할 수 있어야 합니다. 단지, 잘쓰이지 않거나 거의 사용하지 않는다고 해서 아예 표현하지 못하게 한다는 것은 의지에 대해 제한을 둔다고 생각합니다.

익명 사용자의 이미지

흠 2번 답변에 대해 지적할 부분이 있네요
linux나 win nt계열 운영체제는 32bit protected mode에서만 동작합니다
16bit code인 BIOS는 전혀 이용하지 않죠
기본적으로 현대 OS자체에 키보드 인터럽트 루틴이 포함되어있습니다

익명 사용자의 이미지

아! 잠시 착각을 했습니다. -.-
초반의 로딩에서만 BIOS를 이용하고 그 후에는 각 하드웨어에 맞는 장치를 설정하도록 되어 있는것을...

참고로 Linux는 BIOS를 이용하여 초반로딩을 하기 때문에 다른 OS와 같이 쓰고자 하면 따로 부팅디스크를 만들거나 Linux를 앞에 설치해야 한다고 했습니다. (최근에 발표되는 것들은 이부분을 수정했다고 하던데... - 현재 저는 Windogs 98를 사용하고 있습니다. -.- 그놈의 게임이 뭔지... 변명같지만 작년에 컴을 삿을때 제사양에 맞는 드라이버를 구하지 못했습니다. 지금도 LAN드라이버를 구하지 못해서 사용하지 않고 있지요. 혹시 LAN설정에 도움을 주실분은 masterjo@hanmir.com으로 편지 주세요. Linux라는 보물창고(?)로 들어가기를 목메어 찾고 있습니다.)

준호의 이미지

유니코드는 조합형보다 표현 능력이 더 뛰어납니다.
2.0의 경우 조합형 현대 한글 모두를 수용하고,
첫가끝 방식으로 고어 조합도 전부는 아니지만 거의 모두를
수용할 수 있습니다. 물론 1.0대에는 한글이 완성형
글꼴만 들어있었지만 이젠 쓰이지 않습니다.

유니코드 1.0이라면 모르겠는데 지금 윈도우나 유닉스에서
쓰이는 것은 대략 2.0버전이고 지금은 3.0 버전입니다.

조합형이 유니코드보다 나을 이유는 없습니다. 아직도
많은 분들이 잘못 이해하고 있는 부분이 아닌가 모르겠군요.

익명 사용자의 이미지

한글 인코딩으로 얘기가 가네요..
여기서부터 시작되는군요..

완성형의 승리가 통신 상의 이점(?) 이라는 거 때문이던데...
컴퓨터 속의 한글이야기에 ... 그렇던데요.

세계유일의 자모가 조합되는 글자를 가지고서.....
(설마 한자가 자모조합형이라고 생각하시진 않겠죠.. )

조합형을 발전시키지 않고, 우리는 왜 버리는 건지..
컴 종속국이라 어쩔 수 없었던가..
^^;

익명 사용자의 이미지

앗! 죄송합니다.
유니코드 1.0과 행망용한글에서 질려버려 유니코드는 항상 그런줄 알았거든요. 최근의 유니코드는 모든한글(?)을 표현할 수 있다니 놀랍군요.

하지만 한글을 창제하신 세종대왕님께서는 초성, 중성, 종성을 조합하여 표현하도록 하신게 아닌가 합니다. 이걸 한자나 영문자따위 처럼 완성시켜 놓고 그걸 검색하여 한글을 표현한다니 그냥 보이기만 했지 그 숨겨진 의미야 어찌 됐든 상관이 없다는 식이 아닌가요?!
만일 유니코드형식으로 굳어진다면 후세의 한국인은 한글이 어떻게 표현되어지는 지를 모르고 한자처럼 하나하나 외우게 되지는 않을까요?
저는 모국어는 그나라의 얼이 담겨져 있다고 생각됩니다. 그걸 다른나라 사람이 이해한다고는 말할수 없을 겁니다.

P.S:주제가 빗나가 한글코드 토론장이 되어 버린듯하군요. 물의를 일으켜 죄송합니다. 간만에 글올렸다가 실수만 하는군요. 각각의 견해가 다를수 있는 사안이므로 더이상 한글코드에 대해서는 자제를 부탁드립니다. 가장 첫글(제목)을 쓰신분께 죄송합니다. -.-

익명 사용자의 이미지

어디까지나 유니코드는 '인코딩'일 뿐입니다-.-;;
글자를 어떻게 수치로 표현해서 컴퓨터에 저장할 것이냐.
이건데 결국은 모든 글자를 다 표현할 수 있으니 된 것 아닌가요.
숨겨진 의미까지 따질 필요는 없을 듯-_-;;

물론 초/중/종성을 구별할 수 있는 인코딩이었다면
(우리입장에서는) 더 좋았겠지만 그 정도까지 바라는 건
무리지요. 유니코드는 세계각국의 문자들을 포용하기 위해
만들어진 것이지, 다른 나라 사람들이 한글을 이해하기 위해
혹은 후세를 교육하기 위해-_-; 만들어진 건 아니니까요.

익명 사용자의 이미지

님의 글 잘보았습니다.
하지만 저는 님의 의견에 반대합니다. 초창기부터 컴에 한글을 표현하기 위해 많은 이들이 연구와 독자적인 루틴을 찾고자 애쓰고 있습니다. 처음으로 한글을 구현하기위해 가장기본적인 초성=>중성=>종성 이런식으로 코드를 만든후 폰트에서 찾아 뿌려줍니다. 이과정을 무시하고 주어진 코드로 코드테이블표 따위를 이용하여 한글을 찾는다는 것은 한글의 구성원리도 모르면서 한글을 출력 시키는 것과 무엇이 다르겠습니까? (유니코드만을 배운이들은 코드테이블에서 한글을 찾을 줄만 알았지 구성원리는 알지 못할거라 여겨집니다. 훗날에는 희귀문서정도로만 한글의 구성원리를 알게되지는 않을까요?)
유니코드는 어떻게 하느냐에 따라 이과정이 달리하므로 위험한 발상임니다.

또한 유니코드가 세계각국의 문자들을 포용하기 위해 만들어진 것이라 했습니다. 그렇습니다. 한글이 세계인과 같이 하여야 합니다. 근데 이게 올바른 표현이 아니라면 세계인들이 그게 그렇구나 합니까? 알려진대로 듣겠지요.
한국사람이 한글이 잘못알려지는 걸 막고 올바로 계승해야 되는게 현재사람들의 의무가 아닌가요?
간단한 예로 독도문제를 들겠습니다. 일본이 자기네 땅이라고 하지요. 이걸 그낭 그러려니 하면 해결될 문제인가요? 바로잡지 않으면 언제가는 지도에서 독도가 일본 영토에 들어가 있는걸 보게 되겠지요. (국제사회에서 일본인이 독도에 대해 많은 홍보(?)를 하고 다니지요. 실제로 지도도 만들어 놓고 있습니다.) 하나더말하자면 이번 일본교과서 문제도 그렇습니다. 국제사회는 그문제에대해 당사국인 우리나라보다 중요시 하지 않습니다. 결국 우리가 노력하여 바로잡아야 할 문제들입니다.)
힘의 논리와 불합리성에 굴복하는것은 정의가 아닙니다. 어찌됐든 결과만 같으면 된다는 식의 구시대적 발상이 기초를 흔들고 있습니다.
음,... 말이 맣아졌군요. 죄송 -.-

익명 사용자의 이미지

저도 자세한 건 모르지만,
유니코드의 첫가끝 방식이 님의 말씀대로
첫소리/가운데소리/끝소리 모두
각각 코드값을 갖는다고 알고 있습니다.
같이 들어있는 완성형보다 첫가끝을
쓰는 게 바람직할 듯...

익명 사용자의 이미지

조합형이 유니코드보다 나은 점은... 한글의 제자원리에 충실하다는 점입니다.
유니코드는 일부 문자에서... 한글의 제자원리를 따르지 않고 있습니다.
그리고, 자모순서도 유니코드에서는... MS가 제안한 순서 - 자음 14자 모음 10자를 기본으로 한 순서 - 를 따르고 있습니다. 하지만, 이것은 한글의 기본 구성만을 중요시한 결과 입니다.

일본어의 경우에는 50음도를 기본 구성으로 하지만, 실제 유니코드에서는 108음을 모두 채용했습니다. 그래서 우리도 초성, 중성, 종성 체계로 유니코드에 수용해 줄 것을 건의했습니다만, 유니코드의 기본 방식이 아니라, 곁가지로 끼어붙여졌습니다.

앞으로 유니코드도 사장되고, 그보다 더 많은 문자를 표현할 수 있는 코드가 만들어질 것으로 생각됩니다. 그 때에는 한글의 모든 낱자가 포함되기를 바래봅니다. 그리고, 모든 한자와 제3세계에서 사용하는 모든 문자들도 포함되기를 바래봅니다.
각기 그들이 원하는대로 포함되기를....

익명 사용자의 이미지

조합형이 유니코드보다 좋은 점?
쩝.. '돔','똠','롬' 의 코드 순서가 어떻죠?
국어사전과 조합형에서는 위의 순서대로 나오지만..
완성형 포함 유니코드에서는 위의 순서가 아니죠.
물론 코드 테이블을 이용해서 정열을 하지만 느리겠죠?
이건.. 프로그래밍 관점이구..
그럼 창제원리는? 우리나라 한글이 초성+중성+종성으로 이루어진 것은
대한민국 국민이면 누구나 아는 사실인데.. 왜 한글코드가
초성코드+중성코드+종성코드로 이루어지지 않을까 생각해보지 않으셨나요?

누가 잘못 이해하고 있는지 모르겠군요.
물론 지금 이 시점에서 조합형을 쓰자는 것도 우습지만
최소한 조합형의 우수성은 알아둬야 하는 것 아닌가요?
쓰레기 완성형이 왜 표준이 되었는지.. 짜증만 나는군요.

준호의 이미지

이태웅 wrote...
> 조합형이 유니코드보다 좋은 점?
> 쩝.. '돔','똠','롬' 의 코드 순서가 어떻죠?

조합형이나 유니코드나 같습니다. 코드 위치만 다릅니다.

아래 문서를 보세요.

http://www.unicode.org/charts/PDF/UAC00.pdf

유니코드의 경우도 조합형과 마찬가지로 코드 위치를
표에 의해서만 아니라 단순히 식으로 계산할 수 있습니다.
조합형의 경우와 마찬가지입니다.

확장완성형(UHC)라면 별도의 정렬 테이블이 필요하겠지만,
(최근의 OS에서는 정렬 테이블이라는 것은 큰 오버헤드가
아닙니다) 유니코드에서는 적어도 현대 한글(조합형이
지원하던)은 거의 그대로의 형태로 수용하고 있습니다.

아래 사이트도 반드시 읽어보세요.

http://camis.kaist.ac.kr/~jwjung/seminar/hangul-i18n/ko-code.html

적어도 상용 조합형은 한글 측면에서는 유니코드 2.0 이후
버전보다 나을게 없습니다.

익명 사용자의 이미지

맞아요...
유니코드 2.0/3.0에서 고어를 쓸 수 있는 것은 좋아요.
그런데... 왜 하(haa, 아래아 하)이
"하" 다음이거나, 아니면 "히" 다음이 아닌... 엉뚱한 장소에 있는 것입니까?
그리고, 고어라구요?
"감수광"이라는 말은 지금도 쓰이는데요. 노래 제목으로요.
"감"에서 아래아가 쓰이구요, "광"에서도 아래아가 쓰이니다.
이것들을(감, 광) 유니코드의 코드순서로 정렬하면... "가"에서는 찾지 못한다고 알고 있습니다.

누가 저 대신에 찾아봐 주실 수 있나요?

준호의 이미지

고어까지 모두 고려해서 자모 순서대로 배열하면
유니코드 다 쓰고도 남을 겁니다.
(그리고 상용 조합형도 고어하고는 관련이 없죠)

대신 사용할 수 있는 조합형과 유사한 방법이
첫가끝 코드라는 것입니다.

http://camis.kaist.ac.kr/~jwjung/seminar/hangul-i18n/ko-code.html

2.4절을 보세요.

이 부분도 현재 유니코드에 포함되어 있습니다.

http://www.unicode.org/charts/PDF/U3130.pdf

이것을 사용하면 조합형의 형식으로(물론 유니코드 글자를
초중종의 순서로 나열하는 것인데) 고어 지원이 가능합니다. 기존 글자들과 비교하고 싶으면 기존 글자를
U3130에 기술된 자모들로 다시 나누어 놓고(이것도
그리 어렵지 않게 처리할 수 있습니다) 비교하면 됩니다.
일전에 뉴스그룹에서는 이것조차도 완전히 고어를 커버할
수 없다는 이야기가 있었는데, 그쪽에 대해서는 지식이
부족해서 잘 모르겠습니다만.

글자 순서 비교 문제는 꼭 글자 순서대로만 코드 위치에
배열되어 있어야만 가능한 것은 아닙니다. 어차피 유니코드
등이 사용되면서 글자순 정렬 문제가 대두되고 있기 때문에
(한자등은 더 심각하죠) 일부 글자들에 대해서는 표를
사용하지 않을 수 없습니다.

익명 사용자의 이미지

유니코드나 완성형 코드나 한글의 원리와는 맞지가 않습니다.

정렬은 어떻게 될까요?

'각'이 먼저일까 '강'이 먼저일까는 조합형 체계라면 'ㄱ + ㅏ + ㄱ'과
'ㄱ + ㅏ + ㅇ'의 형태로 단어를 쪼개서 금방 단어의 순위를 정할 수가 있습니다. '각'이 먼저지요.

유니코드나 완성형 코드에서는? 그냥 코드 테이블에 있는 순서를 불러옵니다. 만일, '강'이 '각'보다 먼저 위치한다면 '강'이 정렬하면 앞에 옵니다. 이럴 경우에 개발자가 정렬 루틴을 다시 손질해야합니다. 그냥은 사용할 수가 없겠지요?
영어로 치면
"ab"가
"ac" 의 뒤에 오는 셈이되이지요.

한글은 한국인의 언어입니다. 국제표준코드라고 해도 한글처리가 엉성하면 당연히 사용을 말아야 하고 대한민국 정부는 한글처리가 완전한 코드를 국제표준코드가 받아들이도록 영향력을 행사해야 합니다.

미리 정의된 수천개의 코드값의 조합에서만 한글을 사용해야한다는 현실을 생각하면 가끔은 화가 납니다.

기술은 인간의 편리를 위해 만들어집니다. 그런데, 컴퓨터에서의 한글 코드체계는 한국인이 기술에 어거지로 맞추는 괴상한 형태가 되었습니다.

유니코드는 모든 한글을 표현할 수 있다고 하는데 완성형에서 불가능한 문자들이 추가 된 것 뿐입니다. 모든 한글을 어떻게 표현할 수가 있습니까? 새로운 단어가 생겨나고 새로운 기호가 만들어 집니다.

컴퓨터에서의 한글 코드 체계는 실제 한국인이 한글을 사용하는 체계를 그대로 옮겨와야 합니다. 워드 프로세서 나오기 전의 무식한 타자기가 완성형만 지원하는 최신 컴퓨터의 워드프로세서보다 더 자유롭게 한글을 표현합니다.

가장 바람직한 대안은 대한민국에서 한글 원리에 충실한 코드체계를 만들어 유니코드가 되었든 아니면 다른 코드체계이든 국제표준코드 체계에 집어넣는 것입니다. 외국놈들이 한글을 우리보다 더 잘 압니까?

하루빨리 조합형 코드체계가 한글의 표준으로 자리잡길 바라며..

준호의 이미지

도글 wrote...
> 유니코드나 완성형 코드나 한글의 원리와는 맞지가 않습니다.
>
> 정렬은 어떻게 될까요?
>
> '각'이 먼저일까 '강'이 먼저일까는 조합형 체계라면 'ㄱ + ㅏ + ㄱ'과
> 'ㄱ + ㅏ + ㅇ'의 형태로 단어를 쪼개서 금방 단어의 순위를 정할 수가 있습니다. '각'이 먼저지요.
>
> 유니코드나 완성형 코드에서는? 그냥 코드 테이블에 있는 순서를 불러옵니다. 만일, '강'이 '각'보다 먼저 위치한다면 '강'이 정렬하면 앞에 옵니다. 이럴 경우에 개발자가 정렬 루틴을 다시 손질해야합니다. 그냥은 사용할 수가 없겠지요?

유니코드나 완성형이나 글자순서로 배열되어 있어 그냥
사용하면 됩니다. 말씀하신 가정대로 되어 있지 않습니다.

글자순서대로 배열되지 않은 것은 *통합완성형* 뿐입니다.

그리고 다시 한번 말씀드리는데 정렬 문제를 표로
해결한다고 열등한 것이 아닙니다. 유니코드 들어오면서
알파벳 문자들도 언어 구분 없이 섞이기 때문에
유럽의 각 언어도 자신의 알파벳 정렬 테이블을 써야
합니다.

> 유니코드는 모든 한글을 표현할 수 있다고 하는데 완성형에서 불가능한 문자들이 추가 된 것 뿐입니다. 모든 한글을 어떻게 표현할 수가 있습니까? 새로운 단어가 생겨나고 새로운 기호가 만들어 집니다.

만약 한글 자모가 바뀐다면 조합형도 소용 없습니다.
재정의해야 하기 때문이죠. 가령 ㄱ과 ㄴ사이에
새로운 자음이 들어간다면 어차피 다 바뀌어야 하지
않을까요? "단어"는 코드 재정의의 대상이 아니고,
"기호"는 추가할 수 있습니다.

조합형이나 유니코드가 지원하는 것은 현대 한글
자모를 조합해서 나올 수 있는 모든 조합입니다.
아마 자모 갯수가 바뀌는 등의 커다란 이변이 없으면
코드 자체를 바꿀 이유는 없습니다.

> 외국놈들이 한글을 우리보다 더 잘 압니까?

놀랍게도 그럴 때가 많습니다. 가령 모질라에서 한글
처리하는 부분에 대한 외국인들의 견해를 들으면
한국인으로서 해 줄 말이 없다는데 부끄러움을 느낍니다.

가령 line-breaking이 안되는 문자라든가
세로쓰기 가능한 문자 등에 대해서는 국내에 표준이
있는지도 모르겠고,
언어를 모르는만큼 표준 문서에 기술된 사항을
정확하게 이해하고 코딩하는데 우리는 한국사람임에도
불구하고 한국어 인코딩에 대한 표준조차
이해하지 못하고 있는 것이 현실입니다.

Ken Lunde의 CJKV Information Processing이라는
책을 시간나시면 서점에서라도 한번 보십시오. 이 사람은
일본어는 하지만 한국어는 못하는데, 그래도 놀랍게도
한국어에 대해서 잘 설명하고 있습니다.
(물론 여러 한국인들의 도움도 있었습니다)
우리나라 사람보고 이렇게 설명하라면 아마 할 수 있는
사람은 거의 없을 것입니다.

익명 사용자의 이미지

확장완성형과 유니코드를 혼동해서 죄송하구요...
하여간... 유니코드가 좋은 것은 인정해요. 근데 왜.. 유니코드에 들어가는 한글코드가
완성형 기반이어야 하죠? 계속 버전업되는 유니코드야 고어가 들어가던 말던.. 중요한게 아닙니다. 한글의 표시는 무조건 조합형 기반이 되어야 한다는 거죠. 한글은 표음문자잖아요? 우스운 예기지만 McDonald의 맥도날드잖아요(믁다널드라고 우기는 사람도 있긴하지만 그사람은 그 사람예기고 전 맥도날드예기고요..) 하여간..
Mc는 누구나 맥이라고 읽습니다. 그러면 Mc라는 코드가 유니코드에 있나요? 표음문자기때문에 'M','c'를 조합해서 표시합니다. 당연한거죠?
그러면 우리나라 글자에 '매' 라는 글자가 있습니다.
그럼 '맥'이라는 글자는 새롭게 코드를 만들어야 할까요? 아니면 '매'+'ㄱ' 종성코드를 합쳐야 정상일까요?
제가 보기엔 후자가 더 논리적으로 맞다고 생각합니다만.. 우리나라는 중국이 아닙니다.
그리고 글자쇼트시 오버해드? 최악의 경우 한글자 비교할때마다 6만번의 비교연산을 하는데도요?(물론 6만번이야 하겠습니까만은..)
컴퓨터는 미국인이 만들었죠. 당연히 기초가 되는 용량도 8bit를 기준으로 ascii코드가 만들어지고요. 다른 나라에서 우리도 컴퓨터써! 하면서 새롭게 코드만드니까.. 선심쓰는 것처럼..(뭐 그들이 필요할수도 있었겠지요.) 새롭게 지네맘대로 배정해주고.. 쩝..
그리고.. 한국인이 한국어 인코딩방법을 모르는 것은 당연합니다. 누가 가르쳐준적있나요? 영어처럼 순서대로 배열만하면되는 문자인가요? 그리고 Ken Lunde씨는 일반적인 표본에는 들어가지 않는 사람이라고 생각되는데요? 의외로 많다라... 책으로서 접할수 있는 사람들중인가요? 아니면 컴퓨터를 하는 외국인중에서 인가요? 컴퓨터를 하는 외국인중에서 극소수만이 한글인코딩방법에 대해서 알고 있으며 그나마 인코딩에 관해서 책을 저술한 사람들중에서야 어느정도 높은(그래봤자 낮은) 비율로 한글인코딩에 대해서 아는 것 아닐까요?
하나더.. 한글자모가 추가된다? 그럼 알파벳도 추가되나요? 알파벳에 어떤문자가 추가된다면 그넘은 항상 뒤에 추가되는거 아닌가요? 그야말로 웃기네요?
조합형에서는 '각''갃' 이 있는데 새로운 글자인 가+'ㄱㄷ'종성 이 추가된다면..
바로 쇼트문제나 사용에 문제가 없지만 유니코드에서는 새롭게 테이블을 정의해야 하고 가+'ㄱㄷ'라는 글자코드는 맨뒤로 가겠네요?
완성형에 기반을 둔 한글코드는 주먹구구식 방법이라고 생각합니다.
또 하나더.. 표준화 기구에서는 유니코드 어쩌구 저쩌구 하는데.. 그게 될까요?
제가볼땐.. 영~ 아니올시다입니다. 각나라마다 자신의 나라에 맞는 코드페이지를 사용하겠죠. 영어권에서는 미쳤다고 2byte 코드사용하나요? 1byte문자로도 충분히 표현가능한데... 우리나라? 지금 완성형으로도 별로 힘들지 않게 잘살고 있네요. 확장완성형을 쓰더라도 결국은 사용자는 그걸 쓰는지.. 조합형을 쓰는지 몰라요~ 어차피 조합되는 한글을 전부 테이블안에 넣어놓았으니까요.
유니코드가 정착 되려면 다른거 필요없어요. MS에서 윈도우하나 새롭게 내놓을때..
무조건 유니코드로만 저장이 되게 하고 완성형이나 조합형등은 읽기만 가능하게 하는거죠.
한바탕 대혼란이 일어나겠죠. 그래도 인간은 적응을 잘하기 때문에 다~ 잊어버리고.. 그냥 삽니다. 물론 열받은 프로그래머들중에는 완성형이나 조합형등을 읽고 쓸수 있는 프로그램을 만들겠지만요...
쩝.......
한글.. 그리 우스운 문자가 아닙니다. 세종대왕님께서 한글코드를 만드셨다면 틀림없이
조합형으로 만드셨을겁니다. 발음하는 기관의 모양을 본따서 초성(자음)을 만드시고 천지인의 의미를 담아서 중성을 만드시고 초성을 받침으로 사용하는.. 얼마나 과학적인 문자입니까? 그 창제이념대로 코드를 만들지는 못할망정 조합형이 유니코드보다 않좋다는 예기를 하시니.. 정말 가슴이 아프네요. 조합형기반의 유니코드가 나왔으면 왠만한 한국인(컴퓨터를 하는.. 책을 집필하는 사람이 아닌..)이면 한글인코딩방법에 대해 이해하고 있었을것입니다.

준호의 이미지

이태웅 wrote...
> 그리고 글자쇼트시 오버해드? 최악의 경우 한글자 비교할때마다 6만번의 비교연산을 하는데도요?(물론 6만번이야 하겠습니까만은..)

어떤 경우에 그렇게 되는지 예를 들어 주시죠. 설마 if 문 6만개 쓰실
생각은 아니시겠죠? :) 보통은 테이블에서 두번 읽어들여서 비교하면
됩니다.

> 그리고.. 한국인이 한국어 인코딩방법을 모르는 것은 당연합니다. 누가 가르쳐준적있나요? 영어처럼 순서대로 배열만하면되는 문자인가요? 그리고 Ken

이건 자랑이 아닙니다. 표준으로 되어 있는 한국어 인코딩도 모르면서
외국에 나가서 어찌 조합형이 좋다고 설득을 시켜서 국제 표준으로
만듭니까?

> 컴퓨터를 하는 외국인중에서 극소수만이 한글인코딩방법에 대해서 알고 있으며 그나마 인코딩에 관해서 책을 저술한 사람들중에서야 어느정도 높은(그래봤자 낮은) 비율로 한글인코딩에 대해서 아는 것 아닐까요?

적어도 제가 본 한국어 관련 프로그래머들은 대부분 한국어를 읽을줄
몰라도 한국어 처리를 잘 했습니다. 현재 리눅스에 많이 쓰이는 국제화된
프로그램들이 그것을 증명하죠.

> 조합형에서는 '각''갃' 이 있는데 새로운 글자인 가+'ㄱㄷ'종성 이 추가된다면.. 바로 쇼트문제나 사용에 문제가 없지만 유니코드에서는 새롭게 테이블을 정의해야 하고 가+'ㄱㄷ'라는 글자코드는 맨뒤로 가겠네요?

구체적으로 설명해 드리죠. 조합형은 받침을 모두 하나로 생각하지
ㄱ 받침과 ㄱㅅ은 모두 하나의 순서대로 되어 있습니다. 그리고 ㄱ은
종성 코드 2이고, 그 다음이 ㄱㄱ(3), 그 다음이 ㄱㅅ(4)입니다.

말씀하신 대로 ㄱㄷ 을 추가해야 한다고 하죠. 그러면 3과 4 사이가 되는데
간격이 없으니 ㄱㄷ을 맨 뒤에 추가하고 별도의 정렬 테이블을 쓰거나,
(이렇게 하고 싶지는 않겠죠. "제자 원리"를 따라야 하고 직접
수치로 비교되어야 하고 싶을 테니까...) 아니면
ㄱㅅ부터 하나씩 밀리면서 ㄱㄷ을 추가해야 겠죠? 그럼 기존의 조합형과는
호환성이 없어지니까 그러면 안되겠죠.

님은 "바로 소트나 사용시에" 문제가 없다고 했는데 제가 보기에는
분명히 있습니다. 조합형이나 유니코드나...

> 제가볼땐.. 영~ 아니올시다입니다. 각나라마다 자신의 나라에 맞는 코드페이지를 사용하겠죠. 영어권에서는 미쳤다고 2byte 코드사용하나요? 1byte문자로도 충분히 표현가능한데... 우리나라? 지금 완성형으로도 별로 힘들지 않게 잘

1바이트로 잘 사는건 "미국"등의 "영어"권 국가입니다.
유럽어만 해도 이미 1바이트로 표현 못하고 있습니다.

> 유니코드가 정착 되려면 다른거 필요없어요. MS에서 윈도우하나 새롭게 내놓을때..
> 무조건 유니코드로만 저장이 되게 하고 완성형이나 조합형등은 읽기만 가능하게 하는거죠.

이미 그렇게 하고 있답니다. 최근 윈도우는 모두 내부가 유니코드로
처리됩니다.

> 한글.. 그리 우스운 문자가 아닙니다. 세종대왕님께서 한글코드를 만드셨다면 틀림없이
> 조합형으로 만드셨을겁니다. 발음하는 기관의 모양을 본따서 초성(자음)을 만드시고 천지인의 의미를 담아서 중성을 만드시고 초성을 받침으로 사용하는.. 얼마나 과학적인 문자입니까? 그 창제이념대로 코드를 만들지는 못할망정 조합형이 유니코드보다 않좋다는 예기를 하시니.. 정말 가슴이 아프네요. 조합형기반의 유니코드가 나왔으면 왠만한 한국인(컴퓨터를 하는.. 책을 집필하는 사람이 아닌..)이면 한글인코딩방법에 대해 이해하고 있었을것입니다.

저의 논점은 조합형과 현재 유니코드의 표현력이 같으므로(모두 동일하게
11172자의 현대어 한글을 표현할 수 있으며, 단순한 수치 비교로
정렬이 가능하고, 초중종 번호를 알고 있으면 표도 필요없고
간단한 수치 계산으로 글자 위치를 알 수 있습니다) 조합형이 유니코드보다
현실적으로 나을 근거가 없다는 것입니다. 조합형 한글자의 코드를 얻으려면

0x8000 + 초성 << 15 + 중성 << 5 + 종성

하면 되는 것은 아실 것입니다. 유니코드라면

0xac00 + 초성 * (중성갯수*종성갯수) + 중성 * (종성갯수) + 종성

으로 처리하면 표 없이도 쉽게 얻을 수 있습니다.
이렇게 되면 조합형과 다를게 무엇입니까?
코드의 관점에서 보면 그렇다는 것입니다.

한글이 우수한 문자라는 것을 모르는 바는 아닙니다. 하지만 한글만이
조합형 문자도 아니고, "조합 가능한 문자"를 모두 유니코드에서 수용했고
그것이 조합형의 특징을 모두 갖고 있다면 더 이상 유니코드 대신
조합형을 사용해야 하는 근거를 찾을 수가 없기 때문입니다.

물론 유니코드는 자모 단위가 아니라 글자 단위로 가정하고 있습니다.
한글보다 조합수가 더 많은 언어라면 지금과 같은 방식으로 모두 조합
가능한 문자수를(가령 아라비아어같으면 글자 사이를 연결하는 기호? 같은게
별도로 존재합니다. 이쪽은 쓰는 방향도 다르죠) 배정할 수는 없을 것입니다.
이러한 경우에 있어서, 한글 배정시의 경험이라는 것이 큰 도움이 되겠죠.
또한 유니코드는 "글자나 글자의 일부"를 정의하지, "글자를 쓰는 방법"
에 대해서는 보다 높은 수준에서 정의하고 있습니다. KLDP에 있는
다음 글을 읽어보세요.

http://kldp.org/Translations/html/UTF8-Unicode-KLDP/UTF8-Unicode-KLDP.html

즉 현재의 첫가끝 코드만 사용해도 "화면에 제대로 그리면" 되는 것입니다.
코드의 순서가 어쩌니 하는 것에 얽매일 필요가 없다는 것이지요.

익명 사용자의 이미지

한국인이 한국어 인코딩방법을 모르는 것을 말하는게 자랑이 아니라....
이거야 말로 우습네요?
유니코드 결정하는 곳에 간 한국인이 한국어 인코딩방법을 모르는 것은 창피한 일이지만 일반 프로그래머가 모르는 것은 전혀 쪽팔린 것이 아니라고 생각합니다. 운영체제에서 잘지원해주니까요. 내부방식이야 어떻던...
그리고 현대+고대한글의 문자를 모두 찾아서 2만개라고 칩시다. 이젠 추가될일도 없습니다. 그럼 이걸 완성형으로 만들까요? 조합형으로 만들까요?
어느 방식이든 모든 문자 다 표현합니다. 유니코드 버전10.0(씹기위한 가정입니다만.)에서는 그 문자들이 사전 순서대로 잘~ 배열되어있습니다.
이걸 완성형으로 쓸까요? 한자입니까? 한글이 한자였던가? 우습군요.
이런 상황에서도 한글은 조합형이어야만 합니다. 한글이 그렇게 만들어져있기 때문이죠. 글고 영어권에서도 1byte코드로도 잘만 표시하고 있어요. 독일어DOS써보셨어요? 128개의 문자중에(1byte) 제어코드말고.. 다른 부분을 움라우트같은 문자로 대치해서 사용하더군요. 물론 코드페이지를 이용해서요. 그거 안쓰면 영문도스랑 다를거 별로 없더군요. 이 나라도 DOS시절에는 역시 1byte로 자신들의 문자 잘표현해썼습니다. 다른 영어권나라도 다를바 없다고 생각됩니다만..

익명 사용자의 이미지

최악의 경우를 예를 들죠.
문서에 글자가 3개가 있는데 그 글자는 각각
'가','나','다'가 있습니다.
그런데 이넘들의 순서들은 FFFC, FFFD, FFFE입니다.(물론 이렇지는 않습니다.)
그러면 이걸.. 다->나->가의 순서로 쇼트하고 싶습니다.
현 유니코드에서는 테이블을 기준으로 쇼팅하죠? 가의 코드를 찾아서..
이거 찾거 몇번 비교 연산할까요? 컴퓨터 연산명령말고 우리가 인식하는 단계로요.. 첫번째코드..부터 '가'라는 코드가 나올때까지 테이블을 확인하겠죠?
이게 '가'라는 문자의 순서테이블을 확인했습니다.(6만5천번은 족히 비교했겠죠?) 두번째코드 '나'라는 코드를 확인합니다. 역시 6만5천번은 족히 비교하죠. 도합 19만5천번을 비교연산했네요? 코드만 확인하는데도요.
이제 코드확인했으니.. 뭐 다음 쇼팅이야 금방이지만..요..
그럼 조합형 기반이라면? 볼것도 없이.. 글자의 코드가 사전순으로 배열되는 순서기때문에 글자가 뭔지 확인할필요도 없이 코드값만 비교해서 배열하면 됩니다. 유니코드에 대해서 너무 많은 것을 알고 있는게 조합형에 대해서 편견을 가지게 된 이유가 아닐까요?
저는 조합형의 구현방법도 완성형의 구현방법도 제대로 모릅니다만 각 문자의 코드배정에 대해서만 어디서 주워들은 정도입니다. 이런 상황에서도 조합형의 우수성이 들어나는데 그렇게 많은 것을 아시는 분이 완성형기반의 유니코드를 두둔하시는 것이 이해가 안가네요.
꼭 법을 바꾸면 손해가 나는 집권여당의 모습이라고 생각됩니다.
혹은 역사계에서 자신의 이론이 인정받고 있는데 새로운 유적이나 유물 혹은 책등이 발견되어서 새로운 이론이 인정받게 되면 예전의 기득권자들이 온갖방해를 하는 그런 소설이나 영화같다는 생각도 들게 됩니다. 쩝.
글고 한줄한줄 토달면서.. 꼬투리잡지맙시다.
그리고 받침 'ㄱㅅ'을 예로 든것은 ㄱ+ㅅ을 말하는게 아니라 새롭게 추가된 받침을 예로 든겁니다. 제가 예시할때 뜻의 잘못 전달됨을 미안하게 생각합니다.

그냥 끝내려다가 하나더 예를 들면.. DB를 설계할때 바뀔것이 많은 DB라면.. 그 DB를 타이트하게 설계합니까? 유연하게 설계합니까?
제 경우 DB실력이 형편없어서 타이트하게 짜려고(유연하게 짤줄몰라서) 하다가 DB가 걸레, 넝마처럼 되어버렸네요. 안쓰는 필드.. 똑같은 필드...(길이가 짧아서 더 늘려서 새로운 필드만 쓰게 되고..) 우습더군요. 제가 봐도..

준호의 이미지

저도 이제 한번 한 이야기 두세번씩 쓰기 귀찮으므로 ;_;
이태웅님의 의견과 제 의견을 정리해 보겠습니다.

- 일단, 조합형(태웅님이 말씀하시는 "조합형"은
문맥에 따라 "상용 조합형 인코딩" 또는 "n 바이트
코드 방식과 유사한 자모단위 한글 인코딩"을 의미하고
있습니다만 전반적으로 후자의 방식을 취합니다.
이는 이 스레드 가장 위쪽에 있는 이광님의 의견과
유사한 것으로, 이에 대해서는 역사적으로 존재한 사실도
있고 일부 주장된 바도 있습니다. 그리고 저도 이러한
형태의 인코딩에 대해서는 필요성을 인정합니다.
그에 대해서는 다음 단락을 읽어 주세요.

- 하나 그러한 방식의 코드가 이미 유니코드에서
첫가끝 코드라는 영역에 태웅님이 원하시는 방식의 코드가
제공되고 있습니다.

http://hangeul.cs.pusan.ac.kr/hangeul/book/column/0007.html

위 글은 부산대학교의 김경석 교수님이 쓰신 글입니다.
여기 일부만 인용합니다.

앞으로 시간이 지남에 따라 현재의 상용 조합형이나 완성형은 점점 적게 쓰고, ISO 10646 을 점점 많이
쓰게 될 것이므로, 완성형 2,350 개의 제약은 저절로
해결된다. 다만, ISO 10646 안에 첫가끝 조합형과
완성형이 둘 다 들어 있는데, 우리 글이 과학적인
소리글자임을 생각할 때, 앞으로 완성형을 버리고
첫가끝 조합형으로 나아가는 것이 바람직하다고 본다.

이것이 태웅님이 원하시는 것과 일치하는 것입니다.
여기서 ISO10646은 유니코드와 동일하게(완전히 같지는
않습니다) 생각하실 수 있습니다.

이와 유사한 주장은 이상로님의 또 다른 글에서 읽을 수
있습니다.

http://trade.chonbuk.ac.kr/~leesl/code/isounicode.html

다만 이 글은 한글 11172자가 모두 제공되지 않던
유니코드 1.1에 대한 부분 언급이 되지만 이젠 쓰이지
않으므로 무시하시면 됩니다. 첫가끝 코드에 대한 부분만
읽어 주세요. 다시 중요한 부분만 인용합니다.

...완성형 대 두바이트 조합형의 한글 부호계 논쟁은
새로운 조합형 방식이라는 제 3의 안이 나와서 완성형과
두 바이트 조합형의 모든 문제를 한꺼번에 다
풀어버림으로서 문제가 사실상 끝난 것이나 다름없으며
한글 부호계 문제는 새로운 국면을 맞이하게 되었다.
이제 우리가 해야 할 중요한 일은 국제 표준 한글
부호계의 문제점에 대한 해결 방안을 연구하여 그 연구
결과에 따라서 국제 표준을 고치고 또 국제 표준 한글
부호계를 잘 운용할 수 있는 방안을 마련하는 것이다.

앞으로 우리는 238 글자의 첫가끝 부호계로 조합하는 방식을 지원하는 프로그램을 많이 만들어 보급함으로써 한글의 특성에 맞는 제대로 된 한글 부호계를
정착시키는데 힘을 기울여야 할 것이다.

저는 위 두 글에 전적으로 동감합니다.
또 다른 정보에 대해서는 다음 URL을 참고하세요.

http://toy2.co.kr/lecture/korean/basic/chapter2/uni_code2_iso.html

- 저는 단순히 유니코드가 현대어 한글 조합을 모두
나타내는 11172자를 코드에 배치해 넣었다는 것
때문에 유니코드를 옹호하는 것이 아닙니다.
물론 그것만으로도 기존 조합형을 동일하게
수용할 수 있으며, 첫가끝 코드를 통해 고어를
포함한 나머지 글자도 조합 방식으로 표현할 수 있기
때문입니다.

- 그리고 첫가끝이 아닌 일반 한글 영역에는
단순한 코드 비교로 정렬할 수 있도록 글자 순서대로
"상용 조합형"이 제공하는 모든 조합이 배열되어
있습니다. 이 부분은 단순한 코드 비교로,
"상용 조합형" 또는 유사한 방법에서 하는 것처럼
순서를 쉽게 판별할 수 있습니다.

- 따라서 별도의 변환 테이블을 쓰지 않아도 됩니다.
물론 첫가끝 코드를 써도 마찬가지입니다.

따라서

- 태웅님은 유니코드 2.0 이상 버전이 제공하는
기능에 대해서 충분히 이해하지 못하신 채로
조합형에 대한 장점만을 주장하는게 아닌가
생각합니다. 원하시는 조합 방식은
이미 유니코드에 제공되고 있습니다.

- 따라서 유니코드는 완성형 기반이 아닙니다.
(KSX1001이라는 의미에서나 완성형 스타일의
인코딩이라는 면에서도)

- 유니코드는 일반 한글 문자도 이미 사전 순서대로
배열되어 있습니다. 테이블을 안써도 됩니다.

- 다만, 이에 대한 구현이 부족합니다. 윈도, 리눅스와
같은 주 운영체제에서도 이에 대한 구현이 되어 있지
않은 관계로 유니코드의 현대어 조합 영역만이 이제
구현되고 있는 단계입니다. 따라서 이에 대한 여러가지
구현(가령 hanterm이나 mozilla등에서 첫가끝
인코딩을 출력할 수 있도록 하고, 한글 입력 방식에서
첫가끝 코드에서 입력 가능한 문자를 모두 입력할
수 있도록 하는 입력기를 만들어서)을 제공된다면
태웅님이 갖는 불만사항은 자연스럽게 해결될 수
있을 것이라 생각합니다. 윈도야 MS에서 풀 문제이지만
리눅스의 경우 우리들이 만들어야겠죠.

이상이 제가 정리한 바입니다. 제 의견에 대한 반론이나,
제가 태웅님의 생각을 잘못 이해한 바도 있을 수
있습니다만, 앞으로는 추상적인 이해나 기득권 운운식의 감정적인 비난보다는 보다 사실에 근거한(표준 문서
또는 URL을 제시한다든가, 구현에 대한
구체적인 문제점을 제시한다든가) 반론을 펴 주시면
감사하겠습니다. 제 의견은 이 글에서 잘 정리되어
있으므로, 특별히 새로운 사실이 밝혀지지 않는 한
더 이상 드릴 말씀이 없군요.

긴 글 읽어주셔서 감사합니다. (다른 분들도 :)

익명 사용자의 이미지

저는"UAC00.pdf" 파일을 받아서 보았는데.. 다 보지는 않았어도 기존의 완성형에서
없는 문자가 추가되었음을 알수있었습니다.
그래도 결론적으로 이방식은 완성형이네요? 지금까지의 상용조합형, 기존완성형과는 전혀 호환성이 없는 방식.
그리고 표준문서? 그게 표준맞나요? 제가 보기엔 기존의 완성형이 표준같은데요?
저나 준호님께서 타이핑하는 문자코드가 뭐로 저장되나요? 기존의 완성형 아닌가요?
전 완성형 자체의 문제점을 예기하는거지 사용하지도 않는 유니코드2.0이상의 우수성을 알고자 한게 아닙니다.
제가 쓴글중에서 오류가 많은 것도 인정합니다.(모르는게 너무 많으니까요.)
근데 왜. 제가 말씀드린 'ㄱㅅ'이라는 받침이 새로 생긴 것에 대해서는 언급을 안하시죠?
물론 ㄱ+ㅅ은 아닙니다. 새롭게 생긴 받침이라고 칩시다.(새로 발견된 고문서에서 나왔다고 하죠.)
그러면 유니코드에서는 어떻게 표현할거죠? 모든 초성+중성코드에다가 저 받침이 붙는 코드를 만들어야 하는데.. 공간이 있나요? 다른 어느 동떨어진 비어있는 공간에 코드를 만들겠죠. 틀렸나요? UAC00.pdf 문서를 본결과 '기+ㅎ'의 코드 의 바로 다음에 '까'가 나오더군요. 그럼 'ㄱㅅ'이라는 받침이 있다는 것을 알았는데 '기+'ㄱㅅ''이란 코드는 어디로 가야할까요?
하나의 문제가 아니죠? 유니코드 또 버전업 할까요? 그전 버전의 코드로 만든 문서는 어쩌구요? 문서마다 어떤 버전의 유니코드로 만들었는지 표시해 놓을까요? 버전마다 변환 테이블이 있어야겠네요? 추운날 발에 오줌눠봐야 그 순간만 따뜻하지 더 빨리 식고 얼어버린답니다.
한글 인코딩에 전혀 지식이 없는 저로서도 이런 문제점을 인식하는데 준호님의 생각은 어떠신지요?

익명 사용자의 이미지

모르면 걍 가만히 계세요 -_-;;;
아니면 친절하게도 링크 하나하나 달아주시는거
공부라도 제대로 하고 쓰시던가.

익명 사용자의 이미지

글을 쓰려면(특히 남을 비판하려면) 자신을 밝혀야 도리아닌가요?
전 모든 글을 적을때 그 글에 책임을 지기위해 이름과 될수있으면 Email주소까지 밝힙니다. 하늘을 우러러 부끄럼이 없을때 남을 탓하시기 바랍니다.
(물론 저처럼 무지로인해 부끄럼이 없을때도 남을 탓하기도 합니다만..)

준호의 이미지

한번도 제 글을 자세히 읽지 않으시고 말씀하시는군요.

이제는 다시 말하는 것도 지치니까 제가 썼던 글을
다시 한번 읽고 잘 생각하세요.
이미 답이 나와 있습니다.

그리고 말씀하신 새 받침 문제는 태웅님의 "조합형"에서도
동일한 문제입니다. 제가 지지난 스레드에서
예를 구체적으로 제시했는데 마찬가지로 읽지 않으셨군요.

남의 의견을 비판하기 앞서 그 사람이 어떤 주장을
했는지부터 유심히 살펴보시기 바랍니다. 그전까지는 제가
답을 해 드릴 필요가(왜냐하면 한 말 또 하니까)
없겠군요.

익명 사용자의 이미지

제가 무지해서 그렇습니다. 정말 죄송합니다.
전 조합형이 뭔지도 모르고 무조건 5bit씩 초성,중성,종성에 할당하는 줄 알았습니다.
맨앞의 1bit는 한글을 나타내는 플래그고..
5bit면 32개.. 모든 받침을 수용하고요. 비어있는 공간도 있습니다. 이런거 아니었던가요? 아니라면 제가 코드의 할당에 대해 잘못 이해하고 있는거네요. 조합형을 이렇게 이해하고 있었는데.. 이것이 아니라면 정말 죄송하게 되었습니다. 전 고집이 대단한 놈이라 준호님께서 올려주신 자료를 읽진 않겠지만 다른 분들에겐 정말 도움이 많이 될 자료라고 생각됩니다.
여태동안 적은 제 글은 조합형은 위의 방법으로 코드를 할당한다고 생각하고 적은 글이니 너그럽게 용서해주시기 바랍니다. 참고로 이방법을 쓰면 최소한 받침이 32개가 넘기전까지는 지금까지 제가 말했던 방법이 통용되는군요. 새롭게 받침이 생기던 말던.. 중성이 생기던 말던..요.

익명 사용자의 이미지

지금 준호님께서 제시해준 글을 읽어보니 서로 다른 다리를 긁고 있었던거 같네요.
저는 기존완성형기반의 코드(모든 현대한글을 표현할수 있는 유니코드포함)의 단점을 예기한거고 준호님은 기존완성형이 표현못하는 현대한글을 모두 포함할수 있는 유니코드의 장점을 예기한거네요.
피식.. 그래도 역시 조합형에도 빈공간이 있는 것은 사실인데..

페이지

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.