Hwijae Lee's Blog

소리로 보기(Human echolocation)

2013-08-20T00:00:00+00:00

30대 초반이었던 것 같은데, 누군가 꿈을 물었다. 그래서 배트맨을 만드는 것이 꿈이라고 했던 기억이 난다. 영화의 주인공 배트맨과는 별 관계가 없다. 오히려 데어데블의 주인공을 떠올리는 것이 당시의 내 생각과 비슷할 것이다. 박쥐는 시력이 거의 없는 수준인데도 주변 지형지물을 인지하고 날아다니는데 별다른 불편을 느끼지 않는다. 입으로 초음파를 만들고 반사되는 초음파를 들음으로 시력의 도움 없이 이러한 일이 가능하다.

보지는 못하지만 들을 수는 있는 사람들이 박쥐처럼 초음파로 주변 지형지물을 인지할 수 있다면 큰 도움이 되지 않을까? 초음파 발생기와 초음파 마이크, 주파수 변환 등으로 가능하지 않을까?

이 생각에 커다란 구멍이 있다는 것을 안 것은 얼마 전의 일입니다. 그 구멍은 굳이 초음파가 아니어도 된다는 것입니다. 입으로 소리를 내고 반사되는 소리를 들음으로 주변 지형지물을 인지하는 것이 가능하고 그런 사람들이 있다는 것을 알게 되었습니다. 떼지어 자전거도 타고 하더군요.

Human echolocation

직역하면 "인간 반향 위치측정" 정도가 되겠군요. 간단히 "딱, 딱" 거리는 소리를 내고 들음으로 눈으로 보듯이 주변 환경을 입체적으로 파악하는 기술이라고 하겠습니다. 대표적인 사람으로 벤 언더우드(Ben Underwood)와 데니얼 키쉬(Daniel Kish)가 있습니다. 벤의 뉴스 동영상을 보시면 대충 감을 잡으실 수 있을 것입니다.

How A Blind Teen 'Sees' With Sound

키쉬는 이 기술을 가르치고 전파하는 것을 주목적으로 하는 World Access For The Blind라는 단체의 대표입니다.

단체 소개 연설 (자전거 타기 동영상 포함)

홈페이지 동영상 중 - Bat School For The Blind

키쉬의 TEDx 연설 (Teaching the blind to navigate the world using tongue clicks)

벤이나 키쉬는 따로 배우지 않고 이 기술을 습득했는데, 뭐랄까 들어 보면 시각장애인이라는 이유로 특별 보호를 받지 않았던 것이 도움이 많이 되었던 것 같습니다.

프로그래밍을 배우고 싶습니다. 어떻게 하는 게 좋을까요?

2013-05-21T00:00:00+00:00

질문

"프로그래밍을 배우고 싶습니다. 어떻게 하는 게 좋을까요?"
"프로그래머가 되려고 합니다. 무엇을 공부하는 게 좋을까요?"
"뛰어난 개발자가 되려면 무엇을 해야 할까요?"

프로그래밍 관련 게시판들에서, 간혹 후배들에게서 이런 질문을 보거나 듣게 되는 경우가 있습니다. 제가 이런 질문들에 자신 있게 답을 해도 될만한 사람인지 의문이 들기도 하고 해서, 다른 선배들의 이야기들을 먼저 소개하고 조금 덧붙일까 합니다.

그 외

Tom DeMarco 와 Timothy Lister 의 "피플웨어"

다른 책들에 비해서 동의가 덜 되는 부분들이 좀 있기는 하지만, 그래도 읽어보기를 권하고 싶은 책입니다. 특히 리더의 역할을 해야 하는 개발자들이라면.

Richard P. Gabriel 의 "Patterns of Software"

우리말로 번역된 책은 없는 것 같습니다. 권한다기보다는 그냥 소개하고 싶은 책입니다. 글이 길고 뒤에는 자서전 성격의 내용도 많이 포함되어 있기는 한데, 나름(?) 재미도 있고 IT 산업이나 프로그래밍 언어, 소프트웨어 개발 등에 대해서 생각해 볼 수 있었던 책입니다.

http://www.dreamsongs.com/RPG.html 에 가면 PDF 파일을 받을 수 있습니다.

이 사람이 소위 Worse is better 논란을 시작한 사람인데, 이 얘기도 나름 재미있습니다. 자신도 프로 진영인지 안티 진영인지 결정을 못 했다고 ㅜㅜ. 어쨌든 이 Worse is better 는 초심자분들께는 굳이 권하고 싶지 않네요.

프로그래밍 관련 사이트들

책이나 글과는 달리 웹사이트들은 쉽게 유행이 바뀌기도 하고, 내용이 가벼운 경우가 많기도 합니다. 웬만한 것은 네이버나 구글에게 물어보는 게 답이기도 하구요. 그래도 알고 있는 것이 좋겠다 싶은 사이트를 몇 개 적어봅니다. - StackOverflow - Github - 요즘의 저는 Reddit programming 이나 - Slashdot 등을 이 바닥 소식을 접하는 데 활용하고 있습니다.

영어, 고전

꼭 잘해야만 잘하는 게 좋다고 말할 수 있는 것은 아니니까요.

영어

너무나도 뻔한 얘기이긴 한데, 간혹 일찍 포기하거나 별로 중요하지 않다고 생각하는 경우들이 있는 것 같아서 써봅니다. 알아야 하는데 한글로 된 자료가 부족하거나 없는 경우가 꽤 많습니다. 영어 쓸 줄 아는 개발자 수와 한글 쓸 줄 아는 개발자 수를 생각해보면... 자료의 양을 생각해보면...

고전

프로그래밍과는 별 상관없는 이야기이기는 합니다만, 오랜 세월 살아남은 책들이 주는 뭔가가 있다는 것을 늦게 알았습니다. 작은 차이들이 생겨난다고나 할까요.

그럼, 행복한 프로그래머가 되시길 바랍니다.

Emacs에서 한글 맞춤법 검사기 사용하기 업데이트

2013-04-30T00:00:00+00:00

문서 수정 사항

2014-04-14 - Bug fix 후 patch file link 제거

개선된 점

이전에 hunspell 기반으로 한글 맞춤법 검사를 가능하게 해주는 프로젝트가 있다는 것을 알고 emacs ispell.el 에서 이것을 사용할 수 있게 하느라 애썼던 적이 있습니다. (관련 포스트)

당시에는 hunspell 과 emacs 간의 통신에 문제가 있어서 enchant 를 대신 사용했었습니다. 그런데, 최근에 다시 사용하면서 내용에 따라 간혹 동작을 멈추는 일들이 발생하게 되었습니다.

이 참에 좀 더 근본적으로 문제를 해결하고자 맘 먹고, enchant 에 의존하는 대신 hunspell 을 수정해 버렸습니다. 더불어 이전에 동작하지 않았던 개인 사전 같은 기능도 동작하도록 작업을 하였습니다. .emacs 에 넣을 내용도 조금 수정하였고요.

작업

우선 hunspell 용 한국어 사전은 깔려 있어야 합니다. 요즘, 웬만한 리눅스 배포판에는 hunspell-ko 가 패키징 되어 있을 것입니다. 아니면 맞춤법 검사 프로젝트 페이지에서 받을 수 있습니다.

Hunspell 은 두 가지가 변경되었는데, 하나는 원래의 문제였던 문자 대신 바이트를 세던 문제를 해결한 것이고, 또 하나는 개인 사전이나 세션 단어 기능이 동작하도록 수정한 것입니다.

Hunspell 1.3.2 기반 수정된 소스는 github에서 받으실 수 있습니다.

git clone https://github.com/hj-lee/hunspell.git
cd hunspell
./configure --prefix=<프리픽스>
make
make install

이미 깔린 hunspell 이 있다면, 그것 대신 새로 설치한 hunspell 이 실행되도록 해주어야 합니다. (PATH를 변경 한다든가, 깔려 있는 hunspell 을 지운다든가...)

이제 .emacs 파일에 아래 코드를 추가하면, 작업 완료. (hunspell-init.el)

(setq ispell-program-name "hunspell")
(setq ispell-really-hunspell t)

;; 사전 목록에 한국어("korean") 추가
(if (>= emacs-major-version 23)
    (setq ispell-local-dictionary-alist
          '(("korean"
             "[가-힣]"
             "[^가-힣]"
             "[0-9a-zA-Z]" nil
             ("-d" "ko_KR")
             nil utf-8)))
  (setq  ispell-local-dictionary-alist
         '(("korean"
            "[가-힝]"
            "[^가-힝]"
            "[0-9a-zA-Z)]" nil
            ("-d" "ko_KR")
            nil utf-8))))

;; 한국어를 기본 사전으로 지정
(setq ispell-dictionary "korean")

이전과 달라진 부분은 OTHERCHARS 부분을 숫자와 영문자로 바꾼 것입니다. 이렇게 하면 "3을", "James를" 과 같은 표현이 나왔을 때에도 "를", "을" 등을 각각의 단어로 인식하지 않고 조사로 인식하게 됩니다. (불행하게도 flyspell 모드에서는 잘 동작하지 않습니다.)

개인 사전(Private Dictionary)에 대하여

개인 사전은 홈 디렉터리에 .hunspell_ko_KR 과 같이 언어 별로 생기는데, 여기 있는 단어들에도 '단어/변형 규칙' 과 같은 형태로 단어 변형 규칙을 명시해 줄 수 있습니다. 동사나 형용사는 규칙이 매우 다양해서 규칙을 적어 주기가 어렵고, 명사의 경우 현재의 hunspell-ko 기준으로 규칙 3(단위 명사인 경우 규칙 8)에 해당합니다. 예를 들어 김만중/3 이라는 내용을 사전에 추가하면 "김만중이", "김만중은"과 같이 조사가 붙은 단어들을 더 추가할 필요가 없어집니다. ("홍길동"이 이미 사전에 있는 바람에 그냥 생각나는 사람을 예로 들게 되었네요.)

변경된 부분들에 대해서

hunspell-ko 는 한글 자모 코드로 사전과 규칙 데이터가 정의 되어 있습니다. 그래서 아주 초기에는 한글 사전을 사용하는 경우, 입력을 이 자모 코드로 변환하는 코드가 필요했었습니다. 그래서 당시에는 hunspell 실행 파일도 패치 된 버전을 사용해야 했었습니다. 나중에 입력/출력 변환 테이블을 사전 데이터에 사용할 수 있게 되면서 굳이 패치 된 hunspell 을 사용할 필요가 없게 되었습니다.

제가 작업을 시작할 때 이 사실을 몰라서, 류창우님이 관리하던 hunspell 소스를 fork 해와서 작업을 시작해 버렸었습니다. 나중에 알고 나서 1.3.2 기준으로 작업을 하긴 했지만, 그 때문에 히스토리에는 흔적이 고스란히 남아있습니다.

문자 위치

ispell 호환 모드, 혹은 기본 출력 모드 에서 바이트 위치 대신 문자 위치를 표시하도록 변경한 부분입니다.

이것은 hunspell 라이브러리를 직접 사용하는 프로그램들과는 무관하고, pipe를 사용해서 통신하는 다른 프로그램들과는 문제가 될 수도 있습니다. 다만, 제가 아는 한에서는 emacs 가 이렇게 동작하는 대표 프로그램이고, 이 패치는 emacs 가 hunspell 과 잘 동작하게 해줍니다.

입력 변환

이 패치는 .aff 파일에 ICONV 항목이 있는 경우 개인 사전이나 세션 중의 단어를 추가할 때 무조건 ICONV 변환을 거치도록 합니다.

ICONV 는 사전 파일에서 입력 전환 테이블 같은 것입니다. hunspell-ko 에서는 한글 자모 코드로 변환시켜줍니다.

국어의 경우 문제가 해결 되는데, ICONV를 사용하는 다른 언어들은, 문제가 될 지도 모르겠네요.

Jekyll 과 Github Pages 로 블로깅

2013-04-05T00:00:00+00:00

소개

예전에 잠깐 Blogger 로 블로깅을 했었던 적이 있다. 글, 특히 프로그래밍 관련 글을 작성하고 올리는 것이 불편했던 것이 사실이다.

내가 원했던 것들:

제공되는 웹 에디터가 아닌 늘 사용하던 에디터를 사용하기
HTML 직접 편집은 원치 않음 - 다른 마크업(markup) 필요
소스 코드를 추가 하는 것이 간단해야 함
편집을 마치면 바로 올릴 수 있을 것

당시에 RDoc 을 사용하다가 Markdown 을 사용했었는데, 앞의 세가지 조건은 만족했지만, 마지막이 여전히 불편했다. 글을 작성하고 나서 HTML 변환을 하고, Copy & Paste 를 해야 했고 제목은 또 따로 써야 했다. 약간의 불편함이라고 할 수 있겠지만, 성가셨던 것은 사실이다.

이러 저런 이유로 거의 블로그 글을 쓰지 않고 있었는데 최근에 여유가 많아지면서, 다시 블로깅 방법을 고민하다가 찾아낸 것이 Github Pages 와 Jekyll 의 조합이다. 이것이 만족스러운 해결책이 될 것 같다. (Github Pages 는 Github 에서 제공해주는 사용자 별 웹 호스팅이라 할 것이고, Jekyll 은 말하자면 "정적 웹사이트 생성기"라고 할 수 있다.)

여기 저기 둘러보다가 Jekyll Bootstrap 을 기반으로 작업하기로 했다.

필요한 것들

필수적인 것:

텍스트 에디터
Github 계정
Git client
Git 기본 사용법에 대한 이해
Markdown 에 대한 이해

이것만 있으면 Github 에 블로그를 운영할 수 있다. Push 될 때마다 Github 가 알아서 페이지들을 다시 만들어 주기 때문이다. 하지만, 미리보기나 자동으로 포스트(post) 파일 생성 같은 것은 할 수 없기 때문에 그리 바람직하지는 않다.

Jekyll 과 Jekyll Bootstrap 을 사용하기 위해 필요한 것들

Ruby (1.8)
Rubygems (gem)
Rake
Python

작업

일단 만들기

우선 Jekyll 을 깔았다. 참고로 --user-install 옵션은 root로 깔기 싫어서 한 것이다. 이 경우 jekyll 실행 파일의 링크를 만들어 주거나 PATH 에 넣어 주어야 한다.

gem install --user-install jekyll

그리고 Jekyll Bootstrap 을 clone 해 왔다. hj-lee 는 내 Github 계정이다. 그대로 복사하지는 마시길.

git clone  http://github.com/plusjade/jekyll-bootstrap.git hj-lee.github.com
cd hj-lee.github.com
git remote set-url origin git@github.com:hj-lee/hj-lee.github.com.git

이제 Jekyll Bootstrap 의 기본 페이지를 감상해 보자.

rake preview

rake preview 는 jekyll --server --auto 를 실행시키는 또 다른 방법이다. http://localhost:4000 에서 확인해 보자. 작업이 확실히 필요함을 알 수 있다.

_config.yml - title, author, production_url 항목을 수정한다.
예제 블로그 포스트는 지워 버린다 - rm -rf _posts/core-samples

index.md 를 아래와 같이 바꿨다. title 을 바꾸고 글 목록만 나오게 했다.

---
layout: page
title: Hwijae Lee's Blog
---
{% include JB/setup %}

<ul class="posts">
  {% for post in site.posts %}
    <li><span>{{ post.date | date_to_string }}</span> - <a href="{{ BASE_PATH }}{{ post.url }}">{{ post.title }}</a></li>
  {% endfor %}
</ul>

이제 바뀐 것이 잘 적용되어서 만들어 지는지 확인해 볼 때다. http://localhost:4000 을 새로고침 해보자.

(rake preview 를 실행시켜 놓으면 보통 파일이 바뀔 때 HTML 파일들도 알아서 업데이트가 되는데, 가끔 시간이 걸리거나 잘 동작하지 않는 경우가 있다. 이럴 때는 rake preview 를 죽이고 _site 디렉터리를 지운 뒤에 rake preview 를 다시 띄워주면 된다.)

새로운 블로그 포스트

Jekyll Bootstrap 은 새로운 포스트를 쉽게 만들 수 있는 기능을 제공한다.

rake post title="jekyll blogging"

오늘 날짜로 _posts 디렉터리 아래에 Markdown 파일이 만들어 진다. 혹은 아래와 같이 날짜를 지정할 수도 있다.

rake post title="jekyll blogging" date="2013-04-03"

이렇게 하면 _posts 디렉터리 안에 2013-04-03-jekyll-blogging.md 파일이 만들어진다. rake 로 포스트를 만들 때 title 은 파일 명과 생성된 파일 안의 title 항목을 미리 채우는 데 사용된다. 실제 제목은 파일 안에 있는 title 항목이 결정하기 때문에, 파일 명을 일치 시키려고 애쓸 필요는 없다.

Jekyll 의 페이지(page)와 포스트(post) 파일은 YAML Front Matter 부분과 내용 부분으로 나뉜다. 내용 부분은 Liquid 템플릿의 확장 버전과 확장자에 따른 마크업 처리를 통해 최종 HTML 파일을 만들게 된다. 앞에서 언급한 대로 Jekyll Bootstrap 은 기본 Markdown 포스트 파일을 만들어 주는데, 포스트 파일에서 Liquid 템플릿 을 쓸 일은 그리 많지 않다.

Github Pages에 올리기

Github 계정에 hj-lee.github.com 라는 이름으로 빈 Repository 를 만든다. 혹, 지금까지 수정된 내용과 새로 만들어진 포스트를 commit 하지 않았다면 commit 해준다. 이제 push 하면 Github에서 나의 블로그 사이트를 만들기 시작한다.

git push origin master

성급하게 http://hj-lee.github.com/ 에 가보니, 조금 기다리라고 나온다. 최대 10분 걸린 단다. 그래서 잠시 다른 일 하다가 새로 고침 해보니, 이예~~ 이제 내 블로그가 만들어졌다.

코드 하이라이팅(Code Highlighting)

Jekyll 은 Pygments 를 이용한 코드 하이라이팅을 지원한다. 문서 내에 사용하려면 확장된 Liquid 템플릿 의 highlight 태그를 사용하면 된다. 예를 들어 아래와 같은 내용을 문서 파일 안에 추가 하면

{% highlight ruby %}
desc "Launch preview environment"
task :preview do
  system "jekyll --auto --server"
end # task :preview
{% endhighlight %}

아래와 같은 결과가 보여진다. (참고로 이 코드는 Jekyll Bootstrap 의 Rakefile 일부이다.)

desc "Launch preview environment"
task :preview do
  system "jekyll --auto --server"
end # task :preview

아쉽게도 Jekyll Bootstrap의 기본 tweeter 테마에는 코드 하이라이팅을 위한 CSS 파일이 포함되어 있지 않아서 살짝 수정이 필요했다.

예제 syntax.css 파일을 받아서 assets/themes/twitter/css/syntax.css 로 저장
_includes/themes/twitter/default.html 의 styles 부분에 <link href="{{ ASSET_PATH }}/css/syntax.css" rel="stylesheet" type="text/css"> 추가

기타

이것으로 일단 기본이 되었다. 새로운 글을 올리거나 바뀐 내용을 올리려면 그저 commit 하고 push 하기만 하면 된다.

이 외에도 Jekyll Bootstrap 은 Theme 지원을 하고, 코멘트 지원 사이트나, 분석툴들과 연계가 쉽게 만들어져 있다. 현재 disqus 에 가입해서 사용을 시작했다.

아래에 중요한 페이지들을 모아 보았다.

전반적인 이해와 처음 셋업시

문서(페이지나 포스트) 작성 시 필요한 부분

Markdown 혹은 Markdown 한글 설명 - 필수
Liquid 템플릿 - 포스트 작성 시에는 그다지 필요 없음. raw 태그는 가끔 유용
확장된 Liquid 템플릿 - 포스트 작성 시 highlight 태그 외에는 그다지 필요 없음.
Pygments 지원 언어들 - highlight 태그 사용 시
YAML Front Matter

"네 멋대로 써라"

2009-08-21T00:00:00+00:00

(원제 : "Walking on Water: Reading, Writing, and Revolution")

도서관에서 이 책을 빌려 읽고는 두 권을 샀다. 간혹 다른 사람의 책이나 도서관에 빌려 본 책 중에 가지고 있어야겠다는 생각이 들어서 책을 사는 경우가 있었다. 이 책 이전에 두 권을 가지고 있으려고 책을 산 기억은 없다. (간혹 선물하기 위해서 나중에 한 권 더 샀었던 기억은 있다.)

한 권은 곁에 두려는 의도였다. 또 한 권은 사람들에게 빌려주려는 의도였다. 이 책을 내가 아끼는 많은 사람들에게 꼭 읽으라고 권하고 싶었다. 그렇지만, 그 모든 이들에게 책을 선물하는 것은 주머니에 너무 큰 짐이다. 또 한가지, 선물 받았던 책이 그렇게 읽기 싫었던 기억이 났었던 것 같기도 하다. 책 선물은 받기 싫은 선물 1~2위를 다툴만큼 인기가 없다는 설문 결과도 생각이 났었던 것 같고.

이렇게 기억을 더듬다 보니 빌려 주는 용도의 책을 한 권 더 산 진짜 의도는 다른 데 있었던 것 같기도 하다. 정말 곁에 두고 싶으면서 권하고도 싶었다. 책이 좋다하면, 빌려달라고 할 수도 있는데, 일단 손을 떠난 책은 되돌아오지 않을 가능성이 생긴다. 두 권을 가지고 있으면 되돌아 오지 않더라도 일단 한 권은 가지고 있을 수 있다. 그리고, 그 사이에 누가 빌려달라고 하면 빌려주는 용도의 책이 돌아오면 빌려 줄 수 있다고 얘기할 수 있을테니까. 아니면, 사라고 할 수도 있겠지.

어쨌든 나로서는 처음 있는 일인데, 그만큼 이 책은 내가 아끼는 많은 이들에게 읽어보기를 권하고 싶은 책이다.

재미있는 글쓰기 책인줄 알고 책을 골라 빌려 왔었다. 이 책은 젠슨이 대학과 교도소의 글쓰기 교실에서 가르친 경험을 중심으로 전개된다. 수업 내용을 엿볼 수 있기 때문에 글쓰기 책이 아니라고 하기도 좀 애매하긴 하다. 여하튼 이 책은 단순한 글쓰기의 자세나 기술 같은 것만을 이야기하는 책이 아니다.

이 책에 대해 두어줄 쓰려고 마음을 먹었는데, 책을 읽으면서 웃었던 기억들, 가슴이 벅차 올랐던 기억들은 있는데, 내용에 대한 기억은 가물가물했다. 그래서 얼마 전에 이 책을 다시 읽었다. 처음 읽고 세달 정도 지났을 때다.

다시 읽으면서 몇군데 책을 접어서 표시를 하고 밑줄을 그었다. 처음에는 인용을 해볼까 하는 생각을 했었다. 그렇지만 그것은 별로 좋은 생각 같지가 않았다. 중간이나 끝에 나오는 내용을 미리 보면 재미가 반감 될 수 있으니까. 아니, 그 보다는 젠슨이 잘 배치해 놓은 문장을 미리 보여 준다면 그 문장의 빛이 반감될 것 같아 두렵기 때문이었다. 그래도 그냥 어떤 부분에서 무슨 이야기를 할 때였는지는 조금 써두는 정도면 괜찮을 것 같았다. 조금 쓰기 시작했다. 쓰다가 알게 되었다. 억지로 인용을 안 하는 것도 능력이 있어야 가능하다는 것을. 아니면 원체가 아주 힘든 일이던가.

결국 마지막 장의 일부를 인용하는 것으로 마무리 하기로 했다.

"... 난 죽음 같은 우리 문화 속에서는, 누구라도 할 수 있는 가장 혁명적인 일은 제 가슴을 따르는 것이라는 말을 들은 적 있다. 나는 덧붙이련다. 일단 당신이 그것을 - 당신 자신의 가슴을 따르는 일을 - 하기 시작했다면, 당신이 할 수 있는 가장 도덕적이고 혁명적인 일은 다른 이들이 저들의 가슴을 찾아내어, 그들 자신을 발견하도록 돕는 일이다. 그것은 보기보다 훨씬 더 쉽다. ..."

원서 Reviews

Emacs에서 한글 맞춤법 검사기 사용하기

2009-04-29T00:00:00+00:00

(업데이트된 포스트가 있습니다.)

소개

작년 이맘때까지만 하더라도 소스가 공개된 쓸만한 한글 맞춤법 검사기가 없었습니다. 며칠 전에 hunspell에서 사용 가능한 한글 단어 사전이 개발 되고 있다는 것을 알게 되었습니다.

OpenOffice와 Firefox, 그리고 기타 hunspell이나 enchant를 사용하는 소프트웨어들에서 잘 동작합니다. Emacs에서도 ispell과 enchant를 이용하면 한글 맞춤법 검사를 할 수 있습니다.

Emacs 설정

우선 hunspell 1.2.8 이상의 버전과 한글 사전 데이터(.aff와 .dic 파일), enchant 가 깔려 있어야 합니다.

(우분투 9.04의 경우 기본 hunspell 버전이 1.2.6인데 launchpad ubuntu-ko 저장소에 hunspell 1.2.8 버전과 hunspell-ko-kr이 패키징 되어 있습니다. 아래 저장소를 추가하면 쉽게 설치가 가능합니다.)

 deb http://ppa.launchpad.net/ubuntu-ko/ubuntu jaunty main
 deb-src http://ppa.launchpad.net/ubuntu-ko/ubuntu jaunty main

(enchant는 libenchant1c2a 패키지에 있습니다.)

이제 .emacs 파일에 아래의 내용을 추가하면 ispell.el로 한글 맞춤법 검사가 가능하게 됩니다. (flyspell-mode도 잘 동작합니다.)

;; enchant를 ispell 프로그램으로 사용
(setq ispell-program-name "enchant")

;; 사전 목록에 한국어("korean") 추가
(if (>= emacs-major-version 23)
    (setq ispell-local-dictionary-alist
      '(("korean"
         "[가-힣]"
         "[^가-힣]"
         "" nil
         ("-d" "ko_KR")
         nil utf-8)))
    (setq ispell-local-dictionary-alist
      '(("korean"
         "[가-힝]"
         "[^가-힝]"
         "" nil
         ("-d" "ko_KR")
         nil utf-8))))

;; 한국어를 기본 사전으로 지정
(setq ispell-dictionary "korean")

Emacs 버전 22와 23에서 테스트 되었습니다. 버전 22에서는 유니코드로 표현 가능한 모든 글자를 지원하지 않기 때문에 정규식에 '힣'이 들어가면 제대로 보이지도 않고 동작하지도 않습니다. 버전에 따라서 ispell-local-dictionary-alist 설정을 다르게 한 것은 이 때문입니다.

이야기

그동안 공개된 한글 맞춤법 검사기가 없어서 얼마나 아쉬웠는지 모릅니다. 저 뿐만 아니라 많은 분들이 비슷하게 한글 맞춤법 검사기를 기다려왔을 것입니다. 류창우님이 해결책의 실마리를 hunspell 에서 발견했습니다. 이후로 관심 있는 사람들이 모여서 구글 그룹을 만들고 쓸만한 사전을 만들기 시작했습니다.

이런 일이 진행되고 있다는 것을 알게 된 것은 며칠 전 KLDP에서 먼지분투에 대한 글을 보면서였습니다. 글이 KDLP 메인 화면에 자주 나오 길래 뭔가 하고 한 번 들어가 본 것인데 "* hunspell 기반 맞춤법 검사 사전 내장" 이라는 항목에 정신이 번쩍 들었습니다. '어? 한글 맞춤법 검사 사전이 있다고? 왜 이걸 여태 모르고 있었지?' 오버라고 생각할지도 모르겠지만, 저는 전율을 느꼈습니다. (조금 지난 후에 알았는데 KLDP 에 류창우님이 직접 올린 소개의 글이 있더군요.)

우선 아직 양이 얼마 되지 않기 때문에 관련 페이지들과 구글 그룹의 글을 대부분 살펴 볼 수 있었습니다. OpenOffice에서 잘 동작하는 것은 확인을 하였고, Firefox 에서는 빨간 줄이 나타나지 않아서 한참을 헤맸었습니다. 알고 보니 언어 선택을 바꾸지 않아서였더군요. ㅜㅜ

이제 주로 사용하는 프로그램 중에 emacs에서만 한글 맞춤법 검사가 되면 사용에 문제가 없을 것 같았습니다. 그룹 글들을 검색해 보고 nomos님의 시도를 발견했습니다. 일단 창우님의 수정된 hunspell을 설치하고 my-emacs-hunspell을 만들었습니다. 무슨 문제인지 맞춤법 검사도 안 되고 오류도 발생하지 않아서 답답했습니다. hunspell -a -d .... 을 직접 실행시키고 맞춤법이 틀린 문장을 넣으면 잘 동작했기 때문에 emacs와 hunspell의 통신 상에 문제가 있는 것이라는 의심을 했습니다. 둘 사이에 끼여서 관찰했으면 좋겠다는 생각을 했지만 간단한 방법이 떠오르지가 않았습니다. (아시는 분은 댓글 달아 주세요.^^)

차선책으로 떠오른 것이 tee였습니다. tee 는 표준 입력을 파일과 표준 출력에 동시에 써주는 명령입니다. 개선 과정을 거쳐서 나온 최종 my-emacs-hunspell은 아래와 같습니다.

#!/bin/bash
# /usr/bin/hunspell -a -d /usr/share/myspell/dicts/ko_KR
tee ~/tmp/ei_$$.txt | /usr/bin/hunspell -a -d /usr/share/myspell/dicts/ko_KR | tee ~/tmp/eo_$$.txt

($$는 자신의 process id로 바뀝니다. 한 번 ispell-region을 실행하는 경우에도 my-emacs-hunspell을 여러 번 부르는 경우가 있었기 때문에 pid 별로 다른 파일이 생기도록 했습니다. emacs에서 ispell 프로세스가 생길 때마다 ~/tmp/ 디렉터리에 ei_와 eo_로 시작하는 두 개의 파일이 만들어지게 됩니다.)

여러 번의 실패한 시도와 문서 찾아보기의 결과로 위의 ispell-program-name 부분을 제외한 emacs lisp 코드에 정착하게 되었고 nomos님의 결과와 같은 결과를 만들어 낼 수 있었습니다. (검사가 잘 되기도 하고 어떤 때는 Ispell misalignment:...에러가 나는 결과)

에러의 원인을 알아내는 데는 그리 오래 걸리지 않았습니다. 첫 번째 한글 단어가 맞춤법이 잘못되었다고 판단하면 에러가 발생하지 않지만, 첫 번째 한글 단어가 아닌 경우에는 오류가 어김 없이 발생했습니다. 이유는 hunspell의 출력과 emacs의 ispell.el에서 기대하는 입력이 일치 하지 않기 때문입니다. 둘 간의 통신은 emacs가 한 줄을 보내면 hunspell이 맞춤법 검사 결과를 돌려주는 방식입니다. 맞춤법이 잘못된 단어를 발견하면 잘못된 단어의 위치를 알려 주게 되어있습니다. 이 위치가 hunspell은 몇 번째 바이트인가를 알려주는데, ispell.el은 몇 번째 글자인가를 알려주기를 기대하고 그 위치에서 단어를 찾으려니 에러가 발생하는 것입니다.

ispell.el을 고치는 것이 맞는지, hunspell을 고치는 것이 맞는지, (좀 더 정확히는 어떤 것을 고치는 것이 더 간단한지) 고민하던 중에 제3의 프로젝트에서 해결책을 발견하게 되었습니다. 그것이 enchant입니다.

Enchant는 말하자면 여러 맞춤법 라이브러리들을 enchant 라이브러리를 통해서 사용할 수 있게 해주자는 그런 프로젝트입니다. (홈페이지 참조) 명령행 실행기(command line program)에 대해서 그저 "technology demo"라고 하고 있기는 하지만, 일단 검사와 대체 단어 제시 기능을 사용하는 데는 문제가 없었습니다. 이렇게 해서 ispell-program-name을 "enchant"로 바꾸는 것으로 emacs에서 한글 맞춤법 검사 기능 사용하기 "완료".

남은 일들

좀 있습니다.

끝으로

hunspell로 한글 맞춤법 검사가 가능하도록 구체화하는 데 첫 삽을 떼시고 (아직까지는) 작업 대부분을 감당하고 계신 류창우님, 감사합니다. 아울러 옆에서 류창우님의 작업을 도와주시고 격려해 주셨던 다른 여러분께도 감사의 말을 드립니다. 지금의 hunspell이 있기까지 애쓴 여러 연구자들과 개발자들께도 감사의 말을 드립니다.

갈퀴를 이용해서 단어 추가/삭제/변경 등의 제안을 하실 수 있습니다. 작은 참여들이 모여서 훌륭한 맞춤법 검사 환경이 만들어질 수 있습니다. 주저하지 마시고 참여를...

(한두 시간 안에 끝날 줄 알았던 글을 쓰는 데 꽤나 오랜 시간이 걸렸습니다. 너무 오랫동안 글을 안 써서 그런가 봅니다. 잠시, 아직 자리잡히지도 않은 갈퀴에 사람이 너무 몰려서 오히려 방해가 되지는 않을까 어이없는 걱정을 했었습니다. 그리고 깨달은 현실은 '여기 보는 사람이 얼마나 된다고...')