- 저자 KoRoN/香り屋
- 번역 marocchino
- 발행일 2011/12/31
- 번역일 2012/07/02
- 원문 http://files.kaoriya.net/goto/c81pdf
이 글은 스파르탄 Vim의 α판 입니다. 제가 평소에 생각한것을 글로 적은것 뿐이에요. 그래서 나중에 추가 수정될수 있지만, 그게 어떤 형태로 독자에게 전달 될지는 잘모르겠네요. 미리 양해 부탁드립니다.
스파르탄 Vim(이하, 이책)은 최근 너무 보기 힘들어진 스파르탄한 Vim 유저를 지향하는 독자들을 대상으로 쓰여진 책입니다. 이책은 Vim 뿐만 아니라 컴퓨터를 사용할때, 일체의 어리광이나 타협을 용서하지 않습니다. Vim을 포함해 툴의 기능에 지나치게 의존하거나 CPU속도나 큰메모리에 의존하는것을 금기시 하고있습니다. 그래서, 컴퓨터를 사용할 때 표면에 나오지않는 부분을 좀더 의식하도록 유저에게 강요합니다.
이책의 목표는 Vim을 사용하므로써 얻어지는 유저의 혁신 입니다. 유저 자신이 가지고 있는 하드웨어(뇌를 포함한 육체)의 최적화입니다. 말하자면 뉴타입(역주: 건담에 나오는 신 인류에요.)같은 거죠. 네? 툴을 사람에 맞춘다 구요? 아닙니다. 인간이 툴에 극한까지 적응하는 거에요. 왜냐하면 사람이 적응하는 쪽이 빠르니까요. 툴을 인간에 맞게 수정하는 것은 조금이긴 하지만 시간이 걸립니다. 하지만 인간의 뇌의 학습력, 유연함 적응력은 매우 높아 툴이 인간에 적응하는것 보다 빠르게 툴에 맞게 적응 할수 있습니다. 또 Vim 을 바르게 이해해 이책의 목표 레벨에 도달할정도로 사용할 수 있게 되면, 작업시간도 툴을 사용했을때와 비교해 손색이 없을 정도로 짧아지게 됩니다.
이런이유로 이책은 안그래도 가파른 Vim의 학습곡선을 더더욱 가파르게 합니다. 너무나 과격하고 스파르탄한 내용때문에 독자에 따라서는 두근거림, 호흡곤란, 경우에 따라선 생명의 위험이 될 우려도 있습니다. 읽어 나갈때 건강에 주의하시고, 넒어져도 울지않는 마음가짐을 절대로 잃지 않도록 해주세요.
어떤 툴을 완벽하게 쓰기 위해선 그 툴이 탄생하기 까지의 역사, 사상을 알 필요가 있습니다. 툴을 어떤 생각과 목적으로 만들었는 가를 앎으로써 어떻게 써야 할것인가, 어떤때에 쓰지 말아야 할것인가를 알게 됩니다. 어디에나 쓸 수있는 만능 툴은 존재하지않습니다. 이 원칙에 Vim도 예외는 아니죠.
Vim이라는 이름은 만들 당시엔 Vi IMitation, 지금은 Vi IMproved 의 약자입니다. 이 이름으로 알 수 있듯이 vi가 전신 입니다. vi는 BSD/Unix에서 탄생 했습니다. BSD/Unix는 Unix의 파생 OS 정확히 말하자면 확장판이라고 생각하는 쪽이 좋습니다. 편리한 툴을 많이 개발해 팩키지로 만든게 BSD/Unix 라고 생각 해도 좋습니다. Unix는 Multics의 대항마로써 탄생 했습니다. 대략이긴 하지만 이 역사가 Vim의 툴으로써의 성격에 어떻게 영향을 미치고 있는지를 생각해 봅시다.
Multics는 당시엔 거대한 OS였습니다. 개발 목표도 매우 야심적이고 친취적이어서, 높은 확장성 성능을 목표로 하고 있었어요. 간단하게 말하자면 모든 컴퓨팅에 하나의 OS만 있으면 되게 하자. 였습니다만, 개발 당시의 기술수준이 그 목표에는 못미쳤었죠. 결과적으로는 퍼포먼스가 나빠서 지금 OS로써의 Multics를 아는 사람은 별로 없을꺼에요.
Unix는 그 Muiltics의 실패경험을 바탕으로 심플하고 독립적인 모듈을 구성하는것을 목표로 했습니다. 그 Unix의 특징인 모듈로 구성 되있다는 점을 더욱 부각시킨 중요한 기능이 개발 되었습니다. 어떤 모듈(프로그램)의 출력을 별도의 프로그램에 입력 시키기 위한 기능. 네, 파이프 입니다. 또 여러 데이터를 텍스트 파일로 만들었다는 점도 이 책의 주제이기도한 Vim을 이야기하기 위해 놓치면 않되는 부분입니다. 즉, 프로그램의 입출력을 텍스트 데이터로 규정해, 그것을 파이프로 연결해 여러 프로그램을 연동해 목표를 달성하는 스타일은 Unix시절에 확립되고 새상에 널리 받아들여지게 됩니다.
vi는 그런 Unix프로그램의 하나인(비주얼)텍스트 에디터로 탄생합니다. 그러니까 텍스트를 처리해서 vi이외의 프로그램이랑 파이프를 통해 연개함으로써 진정한 가치인 성능을 발휘 합니다.
그런 vi가 베이스인 Vim은 vi에 비교해 보다 많은 기능을 가지고 있습니다만, 본질은 vi의 본질하고 전혀 다르지 않습니다. 여러 프로그램과 연개 해야만 진짜 힘을 발휘하게 됩니다. 빔을 재대로 사용하고 있는가는 연개하는 프로그램을 얼마만큼 알고있는가에 달려있다라고 말해도 과언은 아닙니다.
Vim 과 함께 사용 해야할 대표적인 프로그램(툴)을 나열해 보겠습니다.
- 각종 셸(bash/tcsh/zsh 등)
- grep
- wc
- find
- xargs
- cat
- 각종 페이져(less/lv)
- head
- tail
- cut
- sort
- uniq
- sed
- make
- 스트립트 언어(perl/python/ruby 등)
이런 툴을 알고있는 것만으로는 부족합니다. 그 특성을 완벽히 간파해 용도에 따라 나눠서 완벽하게 쓰지 않으면 안됩니다. 중요해서 2번 말합니다만 이 툴들은 필수입니다. 밑에서 각 툴을 간단하게 소개 하겠습니다.
Unix계열의 OS로 로그인하면 가장 먼저 볼 수 있는 인터페이스입니다. 이 셸에 대해서도 sh계열 csh계열에 더 들어가면 각 유파들을 등장 시켜 종교전쟁을 벌일 수도 있지만 이책에서는 다루지 않겠습니다. 최근엔 bash가 디폴트로 설정 되어있는 경우가 많은가 봅니다. 또 BSD에서 유래됐다는 공통점이 있는 csh계나 tcsh계를 사용하는 것도 좋을것 같습니다. 단지 Vim사용자로써의 이상적인 환경을 말하자면 sh계 (bash)와 csh계열 (tcsh) 모두 익숙하게 해서, 셸 스크립트를 읽을 수 있을 정도로 잘 알고있는 것이 바람직합니다. 특히 셸에서 필수라 생각하는것을 밑에 나열해 봤습니다. 모르는 것이 있으면 필사적으로 공부합시다.
- 커맨드라인의 편집/이력 불러오기
- 파이프, 리다이렉트
- job작성
- pushd/popd
- 알리아스
이책에선 셸스크립트는 꼭 작성할 수 있을 필요는 없다고 봅니다. 셸 스크립트의 대부분의 것은 나중에 설명할 스크립트언어를 쓰면 구현가능 하기때문이죠. 하지만, 쓸 수 있는쪽이 더 좋다는건 당연합니다.
파일 내의 문자열을 검색해 보여주는 툴
문자수, 단어수, 줄수를 세는 명령입니다. 특히 줄수의 카운트는 빠르게 작업을 검증하는데 편리합니다. 예를 들면 일련의 파일안에서 특정 키워드를 다른것으로 변경하는 작업을 할 경우, 다음의 명령을 실행해서 0이 표시되는지 검증할 수 있습니다.
$ grep -nr {변경하기전의 키워드} . | wc –l
조건을 붙여 파일을 검색하는 툴
입력의 별도의 툴의 인수로 하는 툴
입력된 파일을 출력 할뿐인 툴, 단순하고 잊어버리기 쉽지만 의외로 쓸만하기 때문에 기억해 두세요.
파일의 앞부분을 잘라내는 툴
파일의 뒷부분을 잘라내는 툴
입력을 행별로 컬럼을 잘라내는 툴
입력을 페이지 단위로 화면에 표시하는 툴
행을 재정렬하는 툴
같은 내용의 줄을 필터링 하는 툴
HTTPD의 엑세스로그에서 IP어드레스를 cut으로 잘라내어 sort해서 uniq -c해서 sort -n하면 간단히 엑세스원의 IP랭킹을 알수 있는등 응용범위가 넓습니다. 덧붙여 uniq는 sort -u로 바꿔쓸 수 있는 경우도 있지만 이 예에선 바꿔쓸 수 없습니다.
Stream EDitor 의 약자입니다. 편집할 파일을 한번에 전부 메모리에 올리는 Vim하고는 달리, sed에서는 순서대로 처리합니다. 그래서 인간에게는 편집하기 어려운 경향이 있지만 큰파일을 대량 고속으로 (정형)편집할 때 유용합니다.
프로그램을 빌드할때 사용하는 툴입니다. 반복되는 각종 절차를 자동화시켜 대단히 편리하게 사용할수 있습니다. 대체 툴도 여러개 나왔지만 아쉽게도 범용성측면에서 봤을때 이것을 능가하는 툴은 있을수가 없고 Vim하고의 친화력도 매우 좋기 때문에 뭐가 어쨋든 익혀두어야 합니다. 입력인 Makefile을 적을수있게하는건 물론이고 작고 순순한 make와 GNU make의 베리에이션의 차이를 의식해 각각 Makefile를 따로 쓸수있게 하는것도 거의 필수입니다. 조금 더 말해보자면 Windows의 nmake라는 방언도 이해하고 있으면 좋습니다.
Vim을 사용하는 관점에서보면 표준입력과 표준출력을 쓸수있는 언어라면 어떤 언어를 골라도 좋습니다. 단지 많은 언어를 알고 있는 것은 중요합니다. 각 언어가 제공하는 프로그래밍에 대한 이해와 철학은 다른 언어나 지금까지의 해설해온 툴을 잘 사용하는것에 대해서도 많은 시사점을 제공합니다. 또 Vim의 스크립트 언어를 사용하는데 있어서도 도움이 됩니다.
이것들 이외에도 텍스트 데이터를 입출력하는 파이프 사용가능한 툴 이 라면 사용할 수 있는 것이 많을수록 Vim을 잘 활용하는 것이 됩니다. 더욱이 스크립트언어는 Vim하고 연동가능한 툴을 새롭게 만들수 있는 매우 유용한 툴입니다. 1개 이상의 언어를 충분히 학습해 레퍼런스 없이도 자유자제로 적을수 있게 해두는 것이 좋습니다.
Vim에 대해서 적기 전에 조금더 알아야 할것이 있습니다.
당신은 어떤 키보드를 사용합니까? 메이커PC에 달려오는 키보드? 논외입니다. Vim을 사용하는데 있어서 올바를 키보드의 선택은 땔레야 땔수없어요.
(역주: 일본에는 jis와 us레이아웃의 2종류가 존재합니다. us레이아웃 기준인 우리나라하고는 좀 다르다는걸 염두해 두고 읽으세요.) 먼저 대전재로 영문 키보드가 아니면 안됩니다. 영문키보드와 일문키보드는 특히 기호의 위치가 다릅니다. Vim의 전신인 vi는 영문 기보드를 전재로 만들어졌습니다. 그리고 vi도 Vim도 기호키에 많은 기능을 할당하고 있습니다. 즉 영문 키보드의 기호의 위치를 전재로 각기능을 할당하고 있습니다.그러니까 일문 키보드를 사용하는것은 그만큼 불합리한 키배열에 응석을 부리는것이 됩니다.
보통, 키배열은 os의 설정으로 변경 가능합니다. 즉 일문 키보드도 영문 배열로 사용할 수 있습니다. 단지 추천은 안합니다. 왜냐하면 일문 키보드에 인쇄된 기호와 실제 기호가 크게 달라지기 때문에, 일정 수준이상의 상급자가아니면 이 혼란스러운 상황을 해쳐나가기란 거의 불가능에 가깝기 때문이죠.
진정한 상급자는 거꾸로 일문 키보드에서도 조작 가능하게 되어 있을 필요가 있습니다. 일상생활에서 자신이 익숙하지 않은 키보드를 사용하게 되는 일은 흔합니다. 또 타인의 키보드를 빌려서 조금만 작업하는 일도 생길 수 있죠. 그런 때에 입력에 버벅된다면 진정한 Vim 유저가 아닙니다. 어떤 키보드도 그 자리에서 적응할수있는 유연함이 필요합니다.
키배열이라는 의미로 컨트롤키(Ctrl)는 굉장히 중요합니다. Vim 유저라면 A의 왼쪽이 Ctrl이어야만 합니다. 왜냐하면 Emacs정도는 아니지만 Ctrl은 Vim애서도 자주 쓰입니다. 또 Vim과 연동해야할 툴에서도 Ctrl을 이용한 조작은 피할 수 없습니다.
특히 ESC키를 Ctrl+[로 사용하는 것은 중요합니다. ESC키는 키보드의 종류에 따라서 위치가 크게 바뀝니다. 반면에 Ctrl+[는 위치가 거의 바뀌지 않습니다. 위치가 바뀌지 않는다면 키보드의 종류가 바뀐정도로 곤란해지지 않습니다.
ESC뿐만 아니라 특수 키의 몇종류는 Ctrl키 조합으로 표현이 가능한건,꼭 머리속에 집어넣어 두는게 좋습니다. 밑에 있는 키들이 이용가능합니다만 이것들은 31이하의 값이 같다는 것을 이용하고 있다는 사실을 머리에 넣어 두어서 손해 볼건 없겠죠.
- TAB :
Ctrl+I - Enter :
Ctrl+M - BACKSPACE :
Ctrl+H(터미널을 경유 하는 환경에서는 조금 문제가 있습니다만)
펑션기(F1~12)는 그만 씁시다. 환경에 따라선 재대로 입력 안되는 경우가 있습니다. 이건 펑션키의 단말위에서 입력코드가 단순하지 않아서 인데요. 결과적으로 재대로 쓸만한게 못된다고 생각하는 쪽이 좋습니다.
위에 한 이야기를 바탕으로 Vim유저가 써야할 키보드를 추천 하자면 Happy Hacking Keyboard Pro 말고는 마땅한게 없습니다. 가격이 2만5천엔 정도하지만 진정한 Vim유저라면 컴퓨터랑 마주하는 시간의 80%는 키보드라는 인터페이스를 사용하는 시간 이기때문에 거기에 돈을 투자할 만한 가치가 충분히 있다고 생각합니다.
모처럼 산다면 타이핑소리가 조용한 type S를 추천합니다. 거의 3만엔이 되지만 2만5천엔에서 3만엔으로 늘어났다고 해봐야 20%밖에 되지 않아요. 대단한 지출은 아닙니다.
필자의 경우엔 Windows에서도 90%이상 키보드로 조작합니다. 구입한 HHK Pro는 4대 이상이네요.
지금까지 하드웨어의 이야기만 했습니다만 일단 소프트웨어 적인 이야기로 바꾸겠습니다. 단지 소프트웨어라고 해도 뇌내의 소프트웨어의 이야기입니다.
당신은 타이핑(블라인드터치)가 되나요? 10손가락을 모두 사용해 입력하고 있나요? 안돼는 사람은 먼저 되도록 하세요. 영문이라면 칠수있는 사람은 숫자도 칠수 있도록 해주세요. 영문숫자를 칠수 있는 사람은 기호도 칠수 있도록 해주세요. Vim은 숫자 키도 기호키도 많이 사용합니다. 그걸 예외로 할수는 없어요.
타이핑이 가능하다고하면 다음은 속도와 정확도 입니다. 대충 1분에 100타가 하한선입니다. 제 지인중엔 400타가 넘는 사람도 있습니다만, 정확하다면 속도는 빠를수록 좋습니다.
Vim은 여러의미로 특수한 에디터입니다. 그 진정한 가치를 이해해 받아들여 활용할 때 진정한 가치가 나옵니다.
Vim은 행 지향 에디터 입니다. 따라서 행단위의 편집조작은 매우 뛰어납니다. 그대신 문자단위의 편집은 비교적 나쁩니다. 그런데 일어 문장은 일반적으로 문자단위의 편집이 필요합니다. 그래서 일어를 잘쓰는 사람중에는 일단락을 한행에 적어 Vim으로 편집하기는 힘들다고 지적하는 사람도 있습니다. 하지만 저경우는 저사람의 편집 방법이 Vim에 적합하지 않기 때문입니다.
Vim으로 일본어를 편집하는 베스트 프락티스는 이렇습니다.
- 한문장이하의 짧은 단위로 개행을 하면서 입력
- 행단위로 잘라 붙여가며 편집
- 연결기능(join) 정형기능으로 외관을 정돈
특히 최후의 정형은 원래는 Vim의 일이 아닙니다. 정형 전용 툴을 쓰는게 진정한 Vim 사용자의 모습일 거에요.
이런 원문이 있고 커서가 Phrase B의 앞에 있다고 합시다. 이때 Phrase B를 Phrase B'로 변경하기 위해서는 어떻게 해야 할까요? 단 Phrase C는 10문자를 넘지 않는다고 합시다.
{Phrase A} {Phrase B} {Phrase C}
평범한 에디터라면 Phrase B를 선택하고 그상태에서 Phrase B'의 내용을 입력하겠죠. Vim에서도 같은식으로 조작이 가능합니다. 비주얼 선택해서 c, ct를 계속해서 Phrase C의 전까지 선택해서.. 같은 조작이 가능합니다. 하지만 여기서는 C로 Phase B랑 Phase C를 한꺼번에 지워서 Phrase B'랑 Phrase C를 재입력한다는 선택지를 생각해봅시다.
{Phrase A} {Phrase B} {Phrase C}
{Phrase A}
{Phrase A} {Phrase B'}
{Phrase A} {Phrase B'} {Phrase C}
충분히 타이핑 속도가 나오고 Phrase C가 그렇게 길지 않은 경우는 리타이핑하는 쪽이 생각보다 더 빠르기도 합니다.
이제 스파르탄 Vim의 세계에 안내하겠습니다. 라고 하면 스파르탄 하기 때문에 Vim에 대해서 적을부분은 정말로 적습니다.
네. 메뉴얼을 읽어서 독학해주세요.
Vim을 사용하는데 있어 무엇보다 중요한 것은 메뉴얼을 읽는 것입니다. Vim은 오픈소스 소프트웨어로는 드물에 문서가 매우 충실합니다. 스파르탄 Vim의 입장에선 물론 영문의 원문을 읽는것을 추천 합니다. 현재 일어번역도 갖추어져 실용에 문제가 없을 정도로 완성되어있습니다. 하지만 번역이 틀렸거나 옛날 글일 수도 있고 꼭 그래서가 아니더래도 원문의 미묘한 늬앙스를 전달하는 레벨은 아닌것 같습니다. 그러니까 꼭 원문을 읽으세요.
메뉴얼을 읽어 Vim의 전채를 파악한 경우에는 다음 명령어가 도움이 될겁니다. 단순히 :help라고 하면 목차가 표시됩니다. :help index라고하면 대부분의 키조작의 일람이 표시됩니다. 만약에 메뉴얼을 읽은적이 없다면 이 부분부터 읽어보는 편이 좋습니다.
익숙한 사람은 :help의 뒤에 조사하고 싶은 키워드를 입력해 필요한 부분에 직접 갈수 있겠죠. Vim의 도움말은 하이퍼링크 비슷한 기능이 제공되고 있습니다. 특정 키워드 위에서 Ctrl+]를 입력함으로써 그 키워드의 셜명으로 이동할수있습니다. 이 Ctrl+]로 점프는 이력으로 기록되므로 점프하기전의 장소로는 Ctrl+0로 돌아 갈 수 있습니다. 이것은 빔의 원래 있는 기능하고 완전히 같은 기능입니다.
문제의 시작은 :help의 키워드가 알수없다는 점일거에요. 그럴때 키워드의 입력중에 Ctrl+D를 입력하면 존재하는 키워드 중에 입력이 끝난 키워드를 포함한 검색 결과를 표시해줍니다. 이 키워드는 전부 영어이므로 Ctrl+D로 검색하기 위해 입력하는 것도 영어로 해야합니다. 결국 영어의 어휘가 어느정도 있으면 어떻게든 기능을 찾을수 있습니다. 그게 스파르탄Vim로써 영어 메뉴얼에 익숙해지는 걸 권장하는 이유중에 하나입니다.
키워드중엔 어느정도 규칙성이 있는것도 있습니다. 만, 이 이후의 규칙성은 메뉴얼을 읽어 스스로 익혀주세요.
스파르탄Vim에서는 커스터마이징을 하지 않을 것을 권장 합니다. 가능한한 설정 파일vimrc은 짧게 하세요. 또 플러그인도 넣지 않는것이 좋습니다.
필요한 설정은 그때그때 하는것이 원칙입니다. 어떻해서든 필요한 설정은 modeline에 적던가 filetype-plugin에 적는걸 추천 합니다. 그이외에 분류 안되는것들은 어쩔 수 없습니다. vimrc에 적읍시다.
플러그인중에 편리한것이 있는건 맞습니다. 단지 플러그인을 사용하기 시작하면 무엇을 넣고 무엇을 넣지않을까의 선택이 힘들어지고 결국 많은 플러그인을 넣게 되어 Vim자체의 동작이 느려집니다. Vim을 켤때 1초이상 걸리면 이미 틀려 있는 겁니다. 일단 플러그인을 전부 지워 버립시다. Vim은 순식간에 켜져야 그밖의 툴과 연동하기 쉬워집니다.
또 플러그인 끼리의 상성도 문제가 됩니다. 조합에따라선 재대로움직이지 않는 일도 발생합니다. 이것은 플러그인을 적을때 충돌을 피하도록 하는 규칙이 없는것이 원인입니다.
그래서 플러그인 작성 뿐만 아니라 키맵을 조금 변경하는 것도 원래는 고려할것이 매우 많습니다.
어쩔수없이 커스터마이즈를 할수 밖에 없는 일도 있겠죠. 그런때를 위한 철의 규칙을 제시합니다.
- 기존의 키맵은 건들지 말것
- (가능한한)키맵은 늘리지 말것
- 커맨드를 늘려라
기존의 키맵은 건드려선 안됩니다. 왜냐하면 Vim의 디폴트 키맵은 잘 이어내려져온 것이기 때문입니다. 명백하게 적당히 붙였군 싶은 키맵도 있는듯 합니다만 사용해보면 의외로 그렇지 않습니다. 또 기존의 키맵을 변경하지 않으면 이용하는 플러그인이 normal!이 아닌 normal 커맨드를 사용해서 자신이 건드린 키맵이랑 충돌해 험한꼴을 보는것도 사전에 막을 수 있습니다.
키맵을 늘리면 않되는 이유는 모든 키맵은 Vim이 앞으로 사용할 가능성도 있기 때문입니다. 유일한 mapleader/maplocalleader 는 재외하고는 mapleader를 사용안하는 키맵은 전혀 없습니다. 뭐 쓰다보면 플러그인들끼리 mapleader에서 투닥투닥해서 아픈꼴을 당하는 일도 있겠지만, 그게 일상이 되면 대책이 없으니 알아서 하세요.
커맨드를 늘리는것은 허용합니다. 왜냐하면 다른 플러그인이랑 부딧혀 아픈꼴을 당하는 일이 일단 없습니다. 또 커맨드만 정의해서 키맵을 정의 안하는 스타일은 원래 추천하지는 않지만 커스터마이징의 가장 세련된 방법입니다.
스파르탄한Vim사용자의 가장 중요한 3개의 소양이 있습니다. 기억력과 사고력 그리고 키보드를 치는 손가락의 순발력 입니다.
이상적으로는 모든 모드에서 키맵을 기억하고 툴별로 다른 정규표현같은 언어사양을 완전히 간파하고 현재의 조작대상에 따라서 빠르게 대응해 사용해 내어야 합니다. 그것을 특정 툴에 맞투기 위해 커스터마이징을 시작한다면 시간이 얼마든지 있다고 해도 부족해집니다. 상기해주세요. 당신은 일을 해결하기위해 Vim을 사용하고 있는 거에요. 각각의 툴에 적절한 사용법을 알고 있다면 에초에 커스터마이징 할 시간 같은건 필요하지 않습니다.
단기기억도 마찬가지 입니다. 점프리스트, 디랙토리스택, 이런걸 Vim에 맏기지 않고 인간 쪽에서 파악해두면 효율적인 조작이 실현될꺼에요. 뭐 원만하지 않다고는 하더래도 그것들이 표시하는 방법을 기억해두는 것은 매우 의미가 있는 일입니다.
사고력은 즉 응용력을 말합니다. Vim로 기본적인 조작을 조합해 복잡한 편집이 가능해집니다. 그런 조작의 조합이 빨리 되느냐가 Vim을 사용하는데 있어서 결정적인 효율의 차로 나타나게 됩니다.
최후의 요소, 손가락의 순발력은 의도한 키를 정확하고 빠르게 입력하는 것입니다. 더 말하자면 타이핑을 무의식상태에서 해야합니다. 인간의 뇌는 잘만들어져있어서, 특히 신체(손가락)을 운영하는 부분에서는 훈련을 거듭하기만하면 대뇌는 쓰지않고 소뇌수준에서 완수됩니다. 즉 족합한 타이핑을 소뇌만으로 실행 할수있도록 되있으면 어떤 키 타이핑을 하는지 대뇌에서 의식한(명령을 한)뒤에 소뇌가 멋대로 타이핑을 해주므로 그 키 타이핑이 끝날때까지 몇초동안 대뇌는 휴식을 하고있습니다. 하지만 대뇌를 쉬게하는 아까운일은 하면 않됩니다.다음 편집내용과 조작방법을 생각하게 할수있으니까요.
즉 스파르탄Vim이 목표로 하는 경지는 대뇌의 전두엽이담당하는 사고력 통솔력의 아래, 시각피질에서오는 디스플레이정보를 바탕으로 해마에서 적절한 기억을 끄집어내면서 좀더 좋은 판단을 하면서 소뇌에 타이핑을 시키는 사이클을 병렬로 끊임없이 하는 것입니다. Vim은 뇌내에서 이 사이클을 실혈하는게 적합하다고 해도 좋겠네요. 일단 이 사이클이 완성되면 엔돌핀같은 뇌내 물질이 분비돼는지는 모르겠지만 쾌감을 기억하면서 피로를 잊고 일사분란하게 Vim을 계속 조작할수 있게됩니다.
그렇게 하다보면 일반인 300인 분의 일을 할수있는 스파르탄Vim이 탄생하는 것입니다.
Vim 추억이야기는 2011년 여름 저의 Web사이트에서 집중적으로 연재했던 블로그글을 수정해서 수록한 것입니다.
mattn횽의 블로그 기사를 읽다보니 옛날 생각이 나서 추억팔이라도 할까 싶어서
당시 나는 대학생이었고 집, 연구실, 알바하던 회사 3군데에서 개발 했었다. Visual C(Studio의 전신)、ViVi、jvim 같은걸 써서 프로그래밍 했던 기억이 난다. jvim의 사이트에 gvim(version 5)의 바이너리가 있길레 시험해 보았지만, 재대로 설정도 돼있지 않아서 "아아 jvim이 좋구나"라고 생각했었다.
그런데 사소한 일로 영문 Vim의 메뉴얼을 읽게 되고 첨부되어있는 샘플 설정(vimrc_example, gvimrc_example)을 써보았을때 나는 충격을 받았다. 그때까지 써놓았던 C, Perl, TeX의 코드가 컬러풀하게 색이 입혀져 있었기 때문이다. 비약적으로 읽기 쉽다. 지금은 그렇게 신기한 일이 아닌 신텍스하일라이트도 당시엔 키워드 하일라이트가 시작될 무렵이었으니 아직 신기했었다. 더욱이 vim에서는 많은(본적도 없는것이 대부분이었음) 파일 형식에 대해서 이미 신텍스 하일라이팅이 제공되어있었다. 거기에 하늘과 땅이 차이가있었다. 하지만 문제없었던 것은 아니었다.
TeX파일이 일어가 섞여있으면 하일라이트가 깨져버렸었다. 원인은 Vim의 정규표현 엔진이 일본어(멀티바이트 문자)를 대응하지 않아서 였다. 졸업논문을 TeX로 적은 나에겐 치명적인 문제였기 때문에 마감에 임박한 졸업논문을 미뤄두고 정규표현 엔진의 개선에 몰입했다. regexp.c를 인쇄해서 재본해 짧지 않은 통학시간의 대부분을 해독과 수정방법 검토에 썻었다. 그렇게 정규표현엔진의 멀티바이트대응이 완성되었다. 또 그것 말고도 많은 수정을 해 평소사용에 곤란하지 않도록 해두었다.
나는 이 성과를 자랑스럽게 생각하고, 공유&공개하려고 생각해 Bram횽(설명할 것도 없지만 Vim의 원작자)에게 메일로 연락했다. 생각해보면 명확하게 의도를 가지고 영어로 메일을 보낸건 그때가 처음이다. 머지않아 Bram횽한테 흔쾌히 허락을 받아 컴파일된 바이너리를 배포하게 되었다. 당시의 나는 아직 독자 도메인인 kaoriya.net를 갖고있기 전이라 연구실의 서버를 사용해 배포했다. 배포당시의 컨샙은 "다운로드하면 무설정으로 편리하게 사용가능"이었다. 당시의 저는 기술 지식 지혜부족은 있었지만 지금도 그 컨샙은 변하지 않았다고 생각한다.
그 때 같이 생각해둔게 있다. 일본 독자의 것으로 만들면 안된다. 성과는 가능한한 Official하게해 세계전체에 환원해야 한다. 중이병같지만 그래야만 한다. 거꾸로 이야기하자면 변경할때에는 그것이 (자신이나 일본을 위해서가 아니라) 세계적으로 의미를 가지고 있고 어떻게 하면 그 유용성을 평가받을 수 있을지를 생각해가면서 구채적으로 작업을 할 필요가 있다. 이 작업은 결국 어떤 면에서 어떻게 vim-dev로 보내면 순조롭게 받아들여 질지 생각하는 부분도 포함된다. 특히 (지금도 그렇지만) 영어 실력없는 나에게 중요하다. 논의되면 절대 이길 수 없다. 그렇다면 논쟁의 여지가 없을 정도 허튼 소리가 나오지 않을 정도 설득력있는 변경 내용과 패치를 만들면 된다. 이때 훈련은 일을하게 된 지금도 상대가 일본인일 때도 도움이 되고 있다.
그렇게 vim-dev 활동을 거듭하고 서투른 영어로 대화해가나가는 것에 고생을하고 있던 때에 일본인 듯 한 글을 발견했다. 그렇다. mattn횽 이었다. 나는 또 충격을 받았다. 그는 "우선 고쳤으니 필요할지 안필요할지는 모르지만 보내고 보자"라는 자세로 보냈었다. 당시의 그의 패치는 퀄리티가 높았지만 그의 전략은 선진적인 기능일수록 vim-dev에서 받아들이기 힘들게 했으며 또 영어도 그렇게 잘하지 못했다. 지금 생각해보면 오사카지방사람의 적극성이 나온것뿐이지만, 당시의 나는 약간의 반감을 가질정도 였다. 하지만 Official에 보내는 내용과 행동 변경사항에는 매우 공감을 했고, 어느센가 연락을 시작해 정신차려보니 매일 같이 대화하는 사이가 되었다.
이 뒤에 더쓸지도 모르겠다.
사족이지만 mattn횽이랑은 아직도 온라인에서 밖에 연락을 안한다.ㅋ Bram횽은 만나본적 있는게 유머.
Vim 스크립트에 얽힌 유쾌한 추억이야기
전의 이야기가 호평이었어서 계속하는 속편입니다. Vim스크립트에 얽힌 유쾌한 추억 이야기 등등
티켓으로 mattn횽하고 이야기를 하던중에 어떤이야기로 시작해 Vim스크립트 이야기를 하게 되었는지는 잘 기억이 나지 않는다. 아마도 처음에 calendar.vim비슷한 걸 보여준것 같다. 지금하고 비교하면 엉망이고 단순했던 calendar.vim은 그래도 나름 잘 짜여있어서 "오오.."라고 감탄하면서도, 약간 프로그레머의 질투로 "일본달력은 없어요?" 같은 바보같은 소리를 했었는데, 그런 바보같은 요구에 대한 대답은 그것을 뛰어넘어 일본달력에 대응한 버전이 나와 감탄했었다. 대체로 이런 느낌으로 mattn횽이 작은 스크립트를 만들어 제가 첨삭하거나 개량해서 돌려주는 식으로 여러가지 스크립트가 생겨나게 되었다. 특히 신문 사이트의 제목표시(당시엔 RSS는 대중적이지않았고 html을 파싱하는게 일반 적이었다.)나, 지금은 없지만 Excite번역같은게 기억에 남는다.
시간적으로 순서가 바뀌었을 지도 모르지만, 내가 쓸모있는 Vim 스크립트를 만든것은 autodate.vim나 format.vim같은게 처음이다. 특히 format.vim은 니시오카횽의 일본 메일링 리스트에 투고한 스크립트가 시발점이 됐을것 같다. 그 스크립트는 매우 촌스럽게 짜여있었지만, 특정 폭의 턱스트를 되풀이 해 편집하는 것이었다. 지금은 당연한 기능이지만 당시엔 그런것도 안됐었다. 나는 그 스크립트에서 채용한 촌스러운 방법에 실망했지만, 그 목표점에 감명과 영감을 받아, 이시오카횽의 버전을 기준으로 Vim의 기능(정규표현식으로 화면의 컬럼위치를 취급)을 사용한 버전을 내놓았다. 그 이후 그 스크립트는 니시오카횽의 손으로 주석 리더라던가 여러기능을 제공하는 훌륭한 버전으로 성장해 나갔다. 지금은 나카헤이횽의 autofmt.vim에 그자리를 양보했지만 그것을 가능하게한 과정에서도 사실 format.vim이 중요한 역활을 했었다점과 더욱더 말하면 modern한 Vim의 기능을 실현가능하게 한 첫번째 이정표였다는 점과, 더욱더 말해 "목표에 커다란 감명과 영감을 얻었다는 것"에 관해 앞으로 적게 될지도 모르겠다.
이런 느낌으로, 내가 Vim스크립트를 대하는 자세는 만능해결사였다. 다른 사람이 적을 스크립트를 훑어보고 조금 마음에드는 부분이 보이면, 마음에 들지않은 부분을 고쳐서 돌려주었다. 이렇게 한것도 저는 사실 Vim스크립트도 클러그인도 적을수록 좋다고 생각하는 초 보수파였기 때문이고 지금도 그렇다. 그런 내 눈에서 보면 Vim스크립트는 많이 작성되면 안되는 것이 었다. 그날이 오기전엔..
어느날 mattn횽이 평소처럼 한개의 스크립트를 보내주었다. 거대 게시판 2찬네루(통칭 2ch)를 읽어들이는 2ch.vim였다. 또다시 나는 충격을 받았다. 아는 사람도 있겠지만 나는 꽤나 하드코어한 2챤넬유저였다. 지금은 좀 뜸해 졌지만, 당시에는 열심히 글을 쓰고 선동당해 빡치고 했었다. 그래서 이 2ch.vim은 기능은 움직이긴 하지만 지적할 구석이 한두군데가 아니었다. 간단히 말하면 신문 사이트 리더의 확장판으로 HTML을 파싱하고 있었다. mattn횽이 나에게 지적하게 하려고 일부러 이러는건가 싶었지만, 그 당시의 저의 빡침은 머리끝까지 차있어서 스트레스로 수명이 주는것같은 느낌이 들정도였습니다. 아니 당시엔 아직 이런 말투는 없었을것 같다.(역주: 앞의문장은 부론토어 라는 말투를 사용해서 쓴거 같아요.) 이런식이라면 w3m(텍스트브라우져))로 보는게 훨씬 좋지 않은가 적어도 dat(2ch의 데이터파일)로 읽어들여야지!
나는 그 충격과 분노에 몸을 맏겨 처음부터 스크립트를 다시쓰기 시작했다. 그래서 2ch.vim를 받은 날의 점심쯤부터 스크립트를 적기 시작해 다음날 아침에는 2ch을 읽어들일수 있는 브라우져가 만들어졌다. 이게 Chalice for Vim 이다. 한걸음 더해 그 날 저녁인가 그 다음날인가에는 2ch에 글쓰는것도 가능해져 있었다. 그이후 Chalice는 뭐 순조롭게 기능을 추가해 나갔지만, 제가 2ch에 질린 최근에서는 github를 살찌우는 양식 정도의 의미만 있겠다. 아마도 Chalice는 Vim이랑 Vim스크립트를 플렛폼으로 사용한 세계최초의 어플리케이션이라 말해도 좋을것 같다. 어쩌면 지금도 앞으로도 어플리케이션을 없을지도 모르겠지만. 어쨋건 Chalice의 탄생으로 나의 2ch를 사용하는 시간은 증가했고, 빡치고 선동당하는 시간도 늘어났다.
Chalice를 개발하던 중에 Vim 스크립트 뿐만 아니라 Vim의 여러 성질을 채험했다고 해도 좋을것 같다. 찾아낸것은 Vim에게 부족한 부분과 약점의 벨런스, Vim으로 무엇을 할수있으면 Vim무엇을 해야하는가 였다.
이 뒤에 더쓸지도 모르겠다.
덧붙여말하자면, 나중에야 안 사실이지만 2ch.vim를 작성했을당시의 mattn횽은 dat이 있는줄 몰랐다고 한다.
생각해보면 그때는 이상하게 싸울일이 많았던것같다는 추억이야기.
빔스크립트의 암흑시대. 이때는 이런수 저런수를 써서 기능을 구현했었다. 이때 익힌 태크닉은 지금도 사용되고 있으며 스크립트의 파편으로 산재하고 있을 것이다. --- mattn
Vim 스크립트로 커다란 어플리케이션을 적은 일로 스크립트뿐만아니라 Vim 전채의 약점을 보아왔다. 뭐든지 스크립트로 적어주려고 생각은 했지만 그렇게 뭐든 쓸필요 없이, Vim의 코드를 건드리지 않고 스크립트만 알고있어도 이것저것 돼게 변하기도 했다. mattn횽의 패치중에 채용되지 않은것은 대부분 소켓이나, 프로세스작업같은게 대부분의 문맥에 포함되어 있었다고 기억한다. 그런 mattn횽의 패치를 채용하지 않는 편에 서거나, 곁눈질로 구경하면서 "역시 채용 안됐네" 라고 하는등, 나는 말하자면 새로운 가능성의 싹을 자리고 있었는 지도 모른다.
우리들이 왜 이렇게까지 했는가. 그 질문에 대답하기는 쉽다. 싸우고 있었기 때문이다. 상대는 Emacs, Visual Studio나 Eclipse같은 IDE였다. Emacs는 설명할것도없는 만능 에디터 이다. 시작부터 애플리케이션의 틀을 넘어서는 통합환경이었다. 어디벤티지라고 하면 Emacs는 Lisp이라고 하는 일반 유저에게는 절대로 사용할 일 이 없는 난해한 언어로 구성 되어있다는 점이랑 너무 통합되어있어서 어려워져있었기 때문에 조작하기 불편했다. 다른 한편으로는 IDE는 프로그래밍, 개발이라는 결코 넓지 않은 분야에 특화되어 있었기 때문에 많은 편리한 기능을 획득해 공격력이 높은 어플리케이션. 특히 당시에는 Visual Studio의 C++에 Intellisense라는 문맥에 따라서 자동완성 해주는 기능은 타의 추종을 불허할정도로 완성되어있었고, 그러면서도 누구나 알기쉬운 멋진 기능이었다.
특화되어있다는 장점, 그만큼 범용성이 부족한것이 약점이 될수가 있었다.
Vim에는 원래 고도의 자동완성 기능이 포함 되어있다. 보간기능이 여러가지가 있고 유저가 그때그때 선택이 가능하다. 특히 insert 모드에서 CTRL-N / P 키워드 자동 완성라고 하며, 완성된 키워드로 시작하는 모든 단어를 버퍼에서 검색 순차적으로 자동 완성 후보로 임시 입력주는 뛰어난 것이다. 단지 이것을 재대로 사용하기가 어렵다. 익숙해지면 간단한 것이지만, 현재 Vim이 가지는 버퍼의 내용을 어디에 어떤 단어가 들어있는지를 대략 파악 해두는 것 뿐이다.실제 개발 업무에서 언어, 라이브러리, 프레임 워크가 정해져 버리면 쓸 어휘는 그다지 많지 않다.어느 정도의 숙련자라면 "이러 이러 이런 처리를 하고 싶다" "이를 위해 필요한 함수는 저기에서 사용 있었지" "분명히 이런 키워드로 시작했었지"라는 식으로 생각해, 키워드 완성을 하면 Intellisense 이 불필요한 정도의 절대적인 효과를 발휘한다. 이것은 거짓말도 과장도 아니므로 JARO(역주: 과장광고를 신고하는 일종의 소비자 보호기관)에 신고할 필요는 없다.
하지만, 2ch에서 IDE의 Intellisense의 떡밥으로 투닥투닥 누군가 "그래서 Vim은 안돼"라고 주장하면 결국 승산이 없음을 깨닫게에는 상당한 시간과 빡침이 필요했다. 몇 번이나 우회를 한 결과 Intellisense를 Vim에서 제공하기로 결정했다. 이러니저러니해도 자동 완성을 구현한 것이다. Vim에 안되는것은 없어. 실제 언어와 라이브러리를 고정할 수 있으면 완성 기능을 만드는 것은 어렵지 않다. 특히 Java같은 건 구현하기 너무 쉬어서 알고리즘을 쉽게 떠올렸다. 하지만 필요한 것은 그것이 아니다.어떤 언어 포맷에서도 자동 완성할 수, 경우에 따라서는 IME조차 작성 수있는 프레임 워크가 필요했다. 게다가 전세계 Vim 개발 관계자 모두가 납득하는 형태로해야한다. 까다로운 논쟁에 휘말려 버리면 일일히 대응할 수 없다.
아이디어는 이렇다. 우선 Vim에 새로운 자동 완성을 늘린다. 그 자동 완성 방법은 스크립트에서 어떤 자동 완성을 제안할지 결정한다. 그리고 자동 완성 목록이 표시되는 메뉴 기능을 구현한다. 이렇게해두면 나중에 얼마든지 자동 완성 기능을 늘릴 수있다. Intellisense도 IME도 전부 구현가능하다. 나는 메뉴 기능을 없에고(나에게는 필요 없었다), 서서히 스크립트 자동 완성까지 구현해두고 기회를 기다렸다.
그 기회는 생각보다 빨리 해왔다. 세상의 트랜드가 그런시기에 있었던 것이다. 해외있는 사용자가 Windows 전용 Java (이었나?) 자동완성을 작성 vim-dev 제안한 것이다. 나는 거절될거라 생각했고 실제로 그렇게됐다. "그것 Windows 이외의 플랫폼 어떻게 할꺼야" 이유까지 예상했던대로였다 이걸 기다렸습니다싶은 마음에 재빠르게 토론에 참여한다. 그 때의 메일 문구는 대체로 이런 느낌이었다.
Vim은 UI를 제공하면 어떨까요? Vim에는 자동 완성 기능이 있지만 지금은 파일 (버퍼)에서 밖에 가지고 오지 않아서요. 만약 스크립트 자동 완성을 만들 수 있으면서, 메뉴 같은 UI가있는 경우 Intellisense 같은 기능을 여러 언어를 구현할 수 있잖아요. 그러고보니 여기에 내가 만든 자동 완성 패치가 있네요. 이런식으로 쓰면 어떨까요? 여기에 자동완성 후보를 표시하는 플로팅 윈도우가 있으면 Vim에서 Intellisense를 이론적으로 모든 플랫폼과 언어에 배포할 수 있지 않을까요.
일본인들이 좋아하는 "이런일도 있을까봐 해봤어요"를 슬쩍 해본것이다. 거기에 메뉴ui의 구현도 덧붙여서
하지만 이패치는 그때에는 논의되지 않았다. 당장 받아들여지지도 않았던 것 같다. 확실히 7.0으로 메이저 업그레이드에서 머지되 메뉴 UI 그 때 아마 Bram 씨가 구현했다. 즉 나의 제안에 동참 해주고 있었다고 해석해도 좋겠다. 첫 번째 메뉴 UI는 특히 멀티 바이트 관련으로 꽤 버그가 많은 mattn 씨가 상당히 열심히 디버깅 해주었다고 기억한다.
내가 제안했던 기능은 이름과 키 맵은 변했지만 거의 그대로 받아들여져었다. 현재 보완 함수 괴상한 인수의 사양이 그 증거이다. 관심이있는 사람은 :help complete-functions를 보았으면 좋겠다.
이렇게 Vim은 Intellisense를 구현 수있는 범용 완성 기능이 구현되었다. 이 기능은 나중에 neocomplcache.vim 등으로 대표되는 보완 시스템의 스크립트에 연결된다. 내가 당초 의도한 Intellisense에 그치지 않고 그 이상의 기능으로 발전한 것은 진심으로 기쁘다. "저건 이 몸 키웠다"가 아닌 "그건 이 몸의 자식이다"같은 심정이다.
이 뒤에 더쓸지도 모르겠다.
덧붙여말하자면 나는 그런 스크립트를 전혀 쓰고 있지않다. 왜 그렇게 열심히 했을까.ㅋ
스크립트와 네이티브 코드의 확장이 메이져버전에 적용되어가는 승화의 추억 이야기.
회를 거듭할수록 좀 장황해지는 감이있어서 이번에는 간단하게. 전에 이야기에서 조금 시간을 거슬러올라 버전 5.x 사이 Vim에서는 문자 코드를 쓰지 못했다. 나는 qkc(역주: Quick KANJI code Converter 빠른 한자 코드 변환기)를 사용하고 있었기 때문에 곤란하지 않았지만, 나에게 오는 부탁,질문 중에는 최우선이었다고 생각한다. 원래 ABrowser를 만들어 공개했다 정도이므로 문자 코드 인식 및 변환 로직을 사용해 구연하기는 쉬웠지만 jvim처럼 일본 특유의 변경이되어 버리는 것은 용서하기 어려웠다. 그런 때, 개발이 진행되고 있던 새로운 버전 6.0에 광명을 보았다.
지금도 있지만 Vim 개발 버전에 'charconvert'(이하 ccv)라는 옵션이 추가되었다. 이 옵션은 Vim에서 파일을 열 타이밍에 후킹해서 Vim 스크립트 함수로 문자 코드를 변환하는 식으로 사용된다. 또한 이 옵션과 관계없이, 왜인지는 기억하고 있지 않지만 Vim 자신이 libiconv를 사용하도록되어 있었다. 나는 이건 찬스라고 생각해서, Vim 스크립트 (libcall) + 네이티브 코드 (dll/so)+libiconv를 이용하여 문자 코드를 변환 vim_ccv 확장을 작성하고 vim-dev 메일링리스트에 투고했다.
내 메일은 예제로 단순 짧았지만, Bram의 대답은 길었다. 보내 주신 메일을 본 순간 "이렇게 신 내용이니 안됐으려나"라고 생각했지만, 내용은 정반대로 극찬이 었다. 고이즈미 전 총리 식으로 말한다면 "감동했다!"라는 뉘앙스를 를 적은 것이다. 결과부터 먼저 말하자면,이 Vim 스크립트 + 네이티브 코드로 vim_ccv 확장은 매우 모양을 바꾸었지만, 그 의도는 Vim 본체에 받아들여지고있다. Bram자신이 네덜란드 사람이라는 것도 있어서 인지, 일본 등의 멀티 바이트 문자 문화권의 사정 (나아가서는 다양한 사용자 요구가있다는 것)에대해 깊히 이해하고 있고, 일단 문제를 인식하고 주면 순조롭게 그리고 최고의 형태로 해결 해주기 때문에 매우 일하기 편하다. 만일 그가 미국인 또는 영국인이라면 이렇게까진 안했을지도 모른다,라고 생각해 버리는 것은 편견일까싶다.
또한이 vim_ccv에는 Bram의 마음을 움직이는 중요한 계기 일지도 모르는 것이 libiconv.dll의 동적 로딩이다. 동적로드는 Windows를위한 기능으로, 일반적으로 Windows 버전에서는 DLL을 링크 해 버리면 그 DLL이 없으면 시작조차하지 않지만 그 DLL에 의존하는 기능만 비활성화 상태에서 시작하도록 하는 것이다. 이 동적로딩 좋은 점은 하나의 바이너리에서 해당 기능을 필요로하는 사람과없는 사람 모두 지원하는 것이다. 있는 기능은 필요한 사람에게는 매우 중요하지만, 불필요한 사람들에게 진심 쓸모없는 것이다. 나는 이 때 이미 Perl과 Python을 동적로딩하는 패치를 작성했고 accept되어 있었다. libiconv을 동적로딩이라는 일을 다른사람이 하게하고 싶지 않았다. 여하튼 약간의 논의는 있었지만, 이렇게 Vim 스크립트 + 네이티브 코드 확장은 Vim에 추가되었다. 지금에와서 이 사례에서 배울 수있는 것은 무엇일까. 목적을 위해 프로그래밍 언어의 경계를 넘는 데 주저하지 않을것, 일본 특유의 요구를 세계적인 요구로 승화시키는 것, 읽는 것만으로 그 의미,의도가 전해지는 코드를 작성할 것, 자신의 아이디어와 기술이 필요로 하게되는 시기를 놓치지 않을 것…
이 뒤에 더쓸지도 모르겠다.
덧붙여말하자면 어제도 libiconv를 사용한 코드를 짰는데 버그가 있었다. 이것저것 복잡한 녀석이다.
소프트웨어의 번역은 단순히 영어에 능통하는것만으론 부족하구나 싶은 추억이야기
Vim의 매력 중 하나에 잘쓰여진 유용한 문서를 뺴놓을수 없다. 이렇게 문서가 충실한데다 유용한 오픈 소스 소프트웨어는 실은 꽤 드물다. 그러나 그것이 영어이며, 일본인에게없는 것이나 마찬가지라는 것 또한 사실이다. 개인적으로 영어를 잘못한다고 해도 읽히기만 한다면 사전 들고 열심히하면 되잖아라고 생각하지만, 말처럼 쉽지만은 않은 모양이다.
어느 날, 언제나처럼 mattn횽이 "번역해봤어"고 tutor 번역을 보내왔다. tutor는 것은 Vim의 튜토리얼 문서에 적혀있는대로 1 시간 미만의 훈련을하는 문서로 기본적인 Vim 작업을 배울 수라는 꽤 가치있는 문서이다. 그것을 mattn 씨가 번역했기 때문에 리뷰해달라는 이야기. 곧바로 몇가지 신경 쓰이는 부분을 고치면서 mattn 씨가 의도적으로 번역 않은 것 같은 부분에서 멈칫했다. 정확히 기억나진 않지만 이런 원문 이었다.
---> 1) Roses are red,
---> 2) Mud is fun,
---> 3) Violets are blue,
---> 4) I have a car,
---> 5) Clocks tell time,
---> 6) Sugar is sweet
---> 7) And so are you.
2.6 절 "행의 조작"의 대상 예문이시 때문에 번역안해도 연습에 지장은 없었지만, 의미를 모르는보다는 아는 것이 좋겠다 생각해서 번역하기로했다. 만, 어덯게봐도 7 번째의 늬앙스는 표현할수 없었다. 6 번째의 "sweet"에는 "달다"말고 "좋은"이란 의미가 있기 때문에 7 번째 줄에 걸려 로맨틱 세련된 분위기가 있는데, 어찌봐도 그 분위기를 전하는 번역이 아니다. 그래서 영어 잘하는 친구에게 상담했는데 다음과 같은 매우 만족스러운 번역이 나왔다.
---> 1) 장미는 빨개,
---> 2) 쓸데없는 일은 즐거워,
---> 3) 제비꽃은 파래,
---> 4) 난 차를 가지고 있어,
---> 5) 시계는 시간을 말해줘,
---> 6) 설탕은 달아
---> 7) 너처럼.
로맨틱한 분위기는 박살났지만 세련된 분위기는 전해져 온다. 단지 정말 아까운 것이지만, 그렇게 신경써서 읽혀지지 않은 것 같다는 점이다. 이 튜토리얼의이 문구를 지적한 사람은 그리 많지 않았다.
Vim 번역해야 문장에는 크게 두 종류가있다. 하나는 tutor처럼 전달에만 문제없으면 번역 하는것. 여기에는 참조 설명서 및 사용자 설명서가 포함되고 메뉴 등을 포함해도 좋겠다. 설명서는 문장마다하라 저자는 번역 고 안쉽고의 차이가 있지만(Bram 영어는 읽기 쉽다) 양이 방대하기 때문에 확실히 힘들기도하지만 평균적으로 특별히 어려운 일은 없다. 나도 처음에는 약간 했었지만 vimdoc-ja 프로젝트의 멤버 (특히 방대한 양의 사용 설명서를 번역한 시미즈 씨의 이름을 소개하고 싶다)가 노력해 준 덕분에 일본어로 번역 설명서를 지금 볼 수 있지 싶다.
Vim 번역해야 문장의 다른 하나는 Vim 화면에 표시되는 메시지이다. 영어 자체는 매뉴얼보다 훨씬 간단하고 양도 비교적 적지만, 자랑도 뭣도 아니지만 당시는 저를 제외하고 mattn 씨 밖에 번역할 수없는 그런 어려움이 있었다고 생각한다. 그 어려움은 영어 문구만으로는 해석할 수 없는 데 따른 것이지만, 단면적인 부분이라도 몇 가지 예제에서 설명 해보자.
| ID | 원문 | 실제 번역 |
|---|---|---|
| 001 | E817: Blowfish big/little endian use wrong | E817: Blowfish 부호의빅/리틀 엔디안이 틀렸습니다 |
| 002 | E716: Key not present in Dictionary: %s | E716: 사전형 키가 존재하지 않습니다: %s |
| 003 | number changes when saved | 숫자 변경수 변경시기를 저장함 |
001은 좀 쉽다, Blowfish가 암호 알고리즘의 일종이라고 알고 있으면 곧바로 안다. 엔디안도 프로그래머라면 교양의 범위이다. 002 일반 영어 Dictionary와 Key 사이의 관련이 설명할 수 없기 때문에 다소 어렵다. 열쇠가 잠긴 사전? eval의 사전형 (Perl에있어서 연관 배열)라고 알면 순조롭게 번역할수 있다. 003은 가장 난이도가 높은 것들 중 하나. 소스 코드와 그주변 코드를 읽어야 비로서 적절한 번역을 알수있다. 덧붙여서 이것은 실행 취소 목록의 머리글에 해당하는 부분이었다. 귀찮은 것은 003 종류의 원문이 자신이 사용한 적도 본 적이없는 기능인 경우 상당한 시간을 소스 코드와 문서(영문)를 뚫어지게 봐야 결론에 도달하게 된다. 즉 번역시 컴퓨터 자체, 각종 OS, 도구 및 프로그래밍 소프트웨어 (Vim)와 소스 코드, etc ... 등등의 지식이 필요하다. 아니 무슨 번역이라도 번역가는 광범위한 관심과 조예가 있는 사람 이상의 번역가는 없다고 생각한다.
물론 말그대로 번역 해 버릴 수도 있으며, 그런 것도 세상에는 적지 않다. 하지만 자신이 번역할때 영어에 약하다고는 해도 그렇게해도 되냐… 나는 그렇게 번역 할수는 없었다. 물론 아직까지 이상한 번역은 남아 있고, 전부 만족스러운 번역을 한 것은 아니다. 그렇지만 모처럼 수고를 한다면 가능한 사용자에게 알기 쉽게, 가능하면 조금이라도 기뻐해주었으면 했던 것이다.
사실 메시지의 원문은 시간과 흐를수록 알기 쉽게 개선되고있다. 따라서 먼저 메시지를 번역할 때보다 어려운 번역은 훨씬 줄고있다. 내가 익숙해진 것도 다소일지도 모르지만, 이런 곳에서도 Vim은 진보를 하고있는 것이다.
이 뒤에 더쓸지도 모르겠다.
덧붙여서 "너처럼."이라고 번역한 친구는 해비 2챤넬러이다.
사람은 진보를 멈추지않고 멈추어서도 안된다. 그런 미래를 향한 이야기. Vim 추억 이야기, 최종화
추억 이야기에 미래편이 어디있냐? 라는 태클은 달게 받겠다. 사람은 진보를 멈추지않고 멈추어서도 안된다. 항상 매사에 한 걸음을 내딛는 용기가 필요하다, 내일에 대한 자세를 새롭게 한 추억 이야기.
2008 년 가을의 이른 아침, 나는 아카사카 프린스(역주: 아마도 호텔) 로비에 있었다. 긴장하고 있었다. 이야기는 몇 달 전으로 거슬러 올라간다. Bram에서 개인적으로 메일이왔다.
"가을에 도쿄에 가는데 만나지 않을레?" "네, 꼭 만나죠"
Bram이 매년 한달 가량을 세계 곳곳에 여행하는 것을 알고 있었다. 이 해는 일본이었다. 나는 그가 나를 신경 써주어서 얘기해 준 것이 너무 기쁘고, 가벼운 마음으로 만날 약속을했다. 그리고 Bram의 숙소인 호텔 위층 레스토랑에서 아침 식사를하면서 환담 하자는 약속을 하게 됐다.
로비의 전화로 Bram를 불러내, 기다리고있는 동안에도 마음속은 복잡했다. 이메일로 밖에 주고받은 적이없고 평생 만날 수 없었을지도 모르는 상대와 직접 만날 수있는 기쁨과 이메일, 번역 정도는 아니겠지만 회화도 제대로하지 못한 영어 실력에 대한 불안등등으로 뒤범벅이었다. 더욱이 도움을 청할 사람도 없다. 만나자고 가볍게 승락한 몇 달 전 자신을 저주하기도 했다. 여기에다가 나는 고등학교 영어 시험은 한 번 제외하고 모두 낙제점 및 추가 시험이었다고 덧붙여 두겠다.
엘리베이터에서 내려 온 Bram 은 무지막지하게 키가 컷다. 내 키는 170cm 미만으로 크지 않기 때문에, 올려 Bram는 2m 가깝지 않을까. 나이도 먹었기 때문에 자주보던 젊은 시절 사진의 이미지와는 상당히 다르지만, 풍기는 지적인 분위기에 비슷했다.
인사와 악수를 나눈다. 손 크기는 지금도 기억하고있다. 선물로 마련한 아사쿠사의 작은 벚꽃 막과자을 다른 문화에 대한 이해가 깊은 그는 기꺼이 받아 주었다. 그에게서 스위스의 초콜릿 (Bram 스위스 Google 근무한다)를 받았다. 해외 초콜릿의 일본과는 근본적으로 다른 풍미를 아주 좋아하는 나는 필요 이상으로 기쁨을 표현했다 생각이 든다.
여기서 고백하자면. 그다음에 무엇을 말했는지는 정확하게 기억하고 있지 않다. 제대로 대답할 수 있었을지도 모르겠다. 더 아쉬운 것은 또 지금은 먹을 수없는 아카사카 프린스의 조식 뷔페 맛조차 기억에 없다.
그러나 즐거운 웃음이 끊이지 않는 시간이었다. 전날 방문한 야나카(역주: 지명) 풍경을 매우 좋아하는 것. 빌딩에 둘러싸인 풍경은 세계 어디서든 똑같다는 것. "아카사카"며 "아사쿠사"발음이, 구별하기 어려운 것. 오늘은 카마쿠라를보고, 그 후는 간사이로 향하는 것. 태풍시즌이라 걱정이지만, 태풍도 일본의 일부라는 것. 가만히 놔두면 PC만 한다. 이 여행에서는 전자장비를 모두 봉인하고 있는 것. 최신 Vim 스크립트는 Python의 영향이 강한 것. Vim의 향후 유지 보수의 이야기. 그리고 Vim는 멋짐에 감사와 그것을 통해 만난 기쁨을.
즐거운 시간을 보낸 후 아침 식사를 제공하는 레스토랑의 마지막 손님 될 것같은 때에, 우리는 작별했다. 나는 그대로 출근하고 Bram횽은 아마도 가마쿠라 향했을 것이다. 일본여행은 즐거웠을까 태풍은 괜찮을까, 막과자 입에 맞았을까. 더 영어를 잘했으면 더 여러가지 말할수 있었을지도 모르겠다.
하지만 그것은 중요한 것이 아니었다. 끝나고 보니 당초의 불안이 거짓말 같다. 중요한건 상대를 진심으로 존경하고관심을 가질것. 그리고 친해지기 위한 한 걸음을 내딛는 작은 용기.
내가 고친 바이너리를 배포하기 위해 거의 처음 자신의 의지로 쓴 영어 이메일이 전송 버튼을 클릭 때의 그 망설임. 저것을 넘는데 필요했던 것은 정말 작은 용기와 결단 이었지만, 그런 용기가 모여 지금보다 나은 내일로 이어져 간다. 앞으로 뭔가 행동하는 것을 주저한다면,이 경험이 걸음 다음 용기가되어주는 것이다. 여기서 내디디면 다른 풍경이 보일꺼야.
그리고 나의 손에 있던 것은 과거의 용기에 대한 보상이라고 할 수 초콜렛. …초콜릿은, 매우 맛있었습니다.
이상 Vim 추억 이야기는 끝.
덧붙여서 식사하고있을 때의 나의 눈높이는 Bram횽과 거의 다르지 않았다. 우와… 내 앉은키, 너무 큰가…?
원래 어떤 소프트웨어를 어떻게 쓰는지는 유저의 자유입니다. 그렇지만 이책은 정반대로 소프트웨어에 자신이 그 효과적인 방법을 규정하고 있으니까 그것을 따라야한다는 극단적인 주장을 해보았습니다. 하지만 역시 Vim을 비롯한 모든 도구는 자유롭게 사용하는게 좋습니다. 자유롭게 사용하면서도 새로운 영감을 얻을 수있는 책이되면 좋겠다,라고 진심으로 생각하는 바입니다.
Vim 에 관한 자세한 정보는 http://vim-jp.org/ 에서 구할 수있습니다. 필자의 웹 사이트는 http://www.kaoriya.net/ 입니다. 오탈자는 필자의 웹사이트를 통해서 필자에게 연락 해주십시오.
마지막으로 감사를 하고싶습니다. Vim 추억 이야기 편의 이야깃거리를 재공해주신 여러분, 표지를 그려준 @ebicue, 코미케참가에 관한 실무를 맏아준 @rin2_, 여러분 덕분에 이책이 나왔습니다. 감사합니다.
2011/12/31 村岡 太郎 (KoRoN)