vi

vi는 빌 조이가 1976년도에 만든 UNIX 계열 운영체제에서 주로 쓰이는 유서 깊은 오픈 소스 문서 편집기이다. "Visual editor"라는 뜻이다. 요즘 대다수의 유닉스와 리눅스 배포판에서 터미널에 vi를 치면 vim의 vi 호환모드가 뜨도록 하여 요즘에 리눅스나 유닉스를 배운 사람들은 vim이 vi인 줄 아는 경우도 있다. vim은 vi와 호환되기는 하지만 개발자부터 시작해서 완전히 다른 물건이다. 원칙적으로 텍스트 모드에서 작동하도록 만들어졌기 때문에 어떠한 플랫폼용 버전을 사용해도 기본적으로 모든 GUI가 텍스트 문자로 이루어져 있다. 내부 창 구분이나 구역 분할 등등.

옛날 옛적에는 텍스트를 편집할 때 라인 에디터(ed)라는 물건을 썼는데, 요즘에는 텍스트 에디터가 당연히 WYSIWYG이지만 라인 에디터는 "어디부터 어디까지 보여줘라"를 명령해야 보여주고 편집이 가능해지는 등 아주 골치 아프고 쓰기 불편한 물건이었다. MS-DOS 시절에도 EDLIN이라는 이름으로 들어가 있었고, PC통신에도 회원 간 편지 보내기 기능의 기본 에디터로 들어가 있는 경우가 많았다. ed가 POSIX 표준으로 지정되어 있기 때문에 오늘날 유닉스 호환 컴퓨터에도 깔려는 있다. 이는 당시 터미널로 모니터가 아니라 텔레타이프라는 일종의 프린터를 쓰는 경우가 있었고[1], 통신 속도가 1,000 bps도 안 되는 극저속이었기 때문에 1초에 한 화면 분량의 텍스트도 다 전송할 수 없었기 때문이다.

하지만 1줄씩만 보면서 코딩을 하는 건 귀찮은 일이었고, 결국, BSD 유닉스를 만들던 버클리 대학에서 빌 조이라는 전설적인 프로그래머가 '비주얼 모드'를 코딩해서 플러그인으로 만들어 넣었다고 알려져 있다. [2] 빌 조이는 후에 자바와 솔라리스 등으로 유명한 썬의 공동창업자가 된다. vi가 등장하면서 텍스트 편집이 매우 편해졌고, 라인 편집기에 플러그인으로 들어가 있던 vi가 아주 인기가 좋자 아예 별도의 프로그램으로 만들어졌다.

당시엔 Emacs가 유료였던 시절이고, BSD에 기본으로 설치된 에디터가 ed와 vi뿐이었기 때문에 선풍적인 인기를 끌게 된다.

vi는 ed에서 파생되어 자유 소프트웨어가 아니었기 때문에 AT&T의 라이선스 없이는 코드 수정이 불가능했다. 따라서 vi를 오픈소스화한 여러 vi의 복제판들이 등장했는데, 그 중 하나가 vim이었다. vim은 1991년 브람 무레나르가 개발했으며 vi와의 호환성을 우선으로 하였다. vim은 "vi imitation"이라는 뜻이었지만 얼마후 "vi improved"로 바뀌었다.

오늘날에는 대부분 환경에서 vi를 입력해도 자동으로 vim으로 연결되기 때문에 일반적으로 vi라고 하면 오리지널 vi뿐 아니라 vim을 포함하는 경우가 대부분이다.

진입장벽이 높고 복잡한 모드라는 직관성을 다소 희생하는 수단을 취하는 대신 텍스트를 조작하는 기능에 치중하여 다른 편집기에 비하여 매우 간단한 키 입력으로 텍스트를 조작하는 것이 가능해졌다. 게다가 당시 컴퓨터 화면에는 지금의 모니터처럼 다양하고 직관적인 그래픽적 표시를 할 수가 없었으므로 화면에 일일이 시각적으로 표시해 주지 않을 바에야 최대한 짧고 간결한 명령 조작 체계를 도입하는 것이 합리적이었다.

과거 편집기의 주된 사용 용도는 C 프로그래밍이었다. 프로그래밍의 특성 상 한 번에 타이핑하기보다는 조금씩 변경, 추가를 하는 일이 많다. 이렇다 보니 당시에는 '라인 편집기' 개념이 중요했다. 라인 편집기는 편집할 줄과 편집 방식을 지정-> 방식에 따라 편집->다시 돌아와서 다음 번 편집할 줄과 편집 방식을 지정 의 순환을 거치며 작동한다.

vi는 라인 편집기 개념에 기반하고 있어 GUI에 익숙한 사용자들에게는 접하기 힘들고 생소하다. 초보자들이 vi를 처음 보고 가장 당황하는 것은 실행을 시켰는데 키보드가 먹히질 않는다는 점이다. 당황해서 막 누르다 보면 또 어느 순간 입력이 되기 시작한다. vi에는 일반 모드, 입력 모드, 명령 모드의 세 가지 모드가 존재하기 때문인데, 그걸 모르고 초심자가 vi로 뭔가 하려고 손댔다가 입력은 안 되지, 삭제도 안 되지, 갑자기 모드가 바뀌어서 입력이 되지, Esc 눌러도 종료는 안 되지... 이런 상황 때문에 봉변을 당하는 경우가 많다.

vi의 해괴한(?) 기능 키 선정 역시 당시의 키보드 구조를 보면 납득이 가는데, 아래의 그림을 보면 알 수 있겠지만 많이 쓰는 Esc, Ctrl 키는 지금과 달리 아주 가까운 곳에 있고 방향키는 애초에 키보드에 없어서 다른 키에 매핑하고 있는 것을 알 수 있다. 물론 지금 와서 완전한 구형 키배치를 쓰는 키보드는 해피해킹과 같은 덕후용(?) 특수 생산품을 제외하고는 거의 없긴 하지만, 사람 버릇이 된 단축키라는 것이 어디 그리 쉽게 옮겨가던가. (FPS에서 마우스와 키보드를 동시에 쓰기 위해 방향을 WASD로 옮겨서 쓰는 것이 관습인 것처럼) 커서를 이동하는 것만 봐도 위, 아래, 왼쪽, 오른쪽으로 이동하는 키는 각각 J, K, H, L이고, 입력 모드에서는 Alt+(J, K, H, L)이다. 처음에는 생소하겠지만 익숙해지면 손가락이 화살표 쪽으로 갈 일이 없다는 점에서 꽤나 높은 편의성을 가져다 준다.

Emacs와 비교하면, 명령 입력을 위해서는 거의 항상 양손이 키보드 위에 있어야 하는 Emacs에 비해 vi에서의 편집은 한 손만으로도 웬만한 것들은 가능하다. 그리고 한 번 여기에 맛들이면 항시 양손을 사용해야 하거나 마우스를 건드려야 하는 편집기에는 기능이고 뭐고를 떠나서 자연스레 거부반응이 늘어나게 된다.

초심자들에게는 리눅스에서는 nano를, FreeBSD에서는 ee를 권한다. 혹은 리눅스 이용자라면 대부분 배포판에 vimtutor라는 튜토리얼이 깔려 있으니 이를 사용해서 하라는 대로 해보면 어느 정도 중요한 기능들을 익힐 수 있다.

심지어 vi의 키맵을 bash에서도 쓸 수 있다. `set -o vi`라고 치면 Esc 키로 일반 모드로 들어가는 등 vi에서 쓰던 키맵을 거의 그대로 쓸 수 있다.[3] 지금 편집 모드인지 일반 모드인지 바로 알기 어렵고 선택 기능이 먹히지 않는다는 (즉 비주얼 모드가 없다는) 불편함이 있긴 하지만[4] 엄청 긴 스크립트 짜는 것도 아닌 한 줄 짜리 bash 작업을 위한 것이라고 생각하면 오히려 차고 넘치는 기능일 것이다. (심지어 yank(복사)-paste도 먹힌다!) zsh에서도 같은 방식으로 사용 가능하다.

vim 8.0부터는 터미널 에뮬레이팅도 지원한다. :term이라고 입력해 보자. Ctrl+W를 위시로 한 다양한 단축키들을 이용하면 vim 내부의 터미널 내용을 편리하게 스크롤 할 수 있고 복사해서 가져 올 수도 있으며 반대로 vim 버퍼에 있던 내용을 vim 터미널 에뮬레이터에 Ctrl+V 하는 것마냥 붙여넣는 것도 가능하다.

중증 vi 중독자는 Windows에서도 편하다고 vi를 깔아서 쓴다. 실제로 Windows용이 따로 있다. 실행하면 유닉스나 리눅스에서와 똑같이 윈도우 창에 텍스트 화면만 달랑 나온다. 당연히 현재 Windows는 GUI로 쓰는 것이 일반화되어 있기 때문에, GUI 환경에서 쓰기 쉬운 버전도 있다. 리눅스에서 작성된 텍스트를 읽는데 유용하게 쓸 수 있다. 윈도우에선 일반 편집기와 같은 모드가 기본이나 설정파일을 수정하면 오리지널 모드로 변경 가능하다.

편집 자체를 따로 하나의 모드로 구성하여 키 조작을 크게 단순화시킨 것이 특징이다. 일반 편집기에서는 입력모드와 편집모드가 구분이 되어있지 않기 때문에, 텍스트 입력에 쓰이는 알파벳이나 숫자 키 자체를 기능키로 사용하지는 못한다. 덕분에 편집 시에는 손가락이 거의 항상 shift, ctrl, alt 쪽에 붙어 있어야 하는데, vi에서는 그냥 단타나 연타로 끝난다. 예를 들어, 커서 움직임은 hjkl, 한 글자 지우기는 그냥 x, 한 줄 전체 지우기(컷)는 dd, 한 줄 전체 복사는 yy, 붙여넣기는 p 식이라, 기본적인 수준의 편집은 그냥 hjkl로 움직이고 지우고 복붙하고 하면서 커피 마시면서 한 손으로도 가능하다.

두 번째는 함수형 명령들이다. 함수형 명령이란 예를 들어 f(x,y) 가 있다면 f x y를 순서대로 입력하는 방식이다. 쉽게 예를 들면, d라는 명령은 이것만으로는 아무것도 일어나지 않는다. 위의 예에서 f와 같은 함수라 인자를 받아야 작동한다. 물론 아무 인자나 받는 것은 아니고 '커서 이동'에 관한 명령을 인자로 받는다. 즉, 우측으로 한 칸 이동하는 명령인 l을 인자로 주어 dl을 순서대로 입력하면 우측 한 글자가 지워지고, 줄의 맨 처음으로 커서를 보내는 ^(혹은 0)과 조합하여 d^를 순서대로 입력하면 해당 위치에서 줄 첫부분까지가 모두 지워지는 식이다.

이것이 가장 많이 쓰이는 부분이 바로 수+명령인데, vi 에서 수는 뒤에 오는 인자를 받아 그 수만큼 반복 실행하는 함수로 볼 수 있다. 즉, 문자 하나를 지우는 x라는 명령과 수 50을 조합하여 50x를 입력하면 50글자가 지워지는 식이다.

함수의 인자로 다른 함수를 지정하는 것도 역시 가능하다. 즉, 5dk라는 명령은 5라는 함수, d라는 함수 그리고 k라는 커서 이동 인자로 구성되어 5(d(k)) 라는 함수로 볼 수 있다. 즉, d(k)라는 함수를 5번 반복하는 명령이 된다. k가 커서를 한 줄 위로 올리는 것이고, dk는 윗줄을 지우는 명령이 되기때문에 위로 5dk 는 위로 5줄을 삭제하는 명령 정도로 볼 수 있다.

이런 식으로 매우 간편하게 입력 가능한 편집 명령에 더해서 그것을 함수형으로 조합하여 타수를 더욱 절약하는 것이 가능하기 때문에, 그것에 특화된 기능이 따로 제공되지 않는 복잡한 작업일수록 vi에서 타수는 훨씬 줄어든다.

숙달되면 아주 편하고 강력한 편집기가 되는데, 커서 이동을 비롯하여 대부분의 편집 명령어가 키보드 중심에 몰려있고, 모드를 이용하여 키 조합을 하지 않아도 되는 경우가 많기 때문에 같은 작업을 해도 타 편집기에 비해 손동작이나 타수가 크게 줄어든다. 텍스트 편집에 한정해서는 어떤 물건과 비교해도 크게 꿇릴 일이 없다. 즉, 단축키 등을 모두 습득하면 아주 빠르고 능률적으로 작업을 할 수 있다. 특히 중요한 점은, 어떤 유닉스나 리눅스 시스템에 가도 vim (vi Improved)는 기본적으로 깔려 있다는 것. POSIX에 포함된 사항이다. # 그 결과, vi의 키 조합은 유닉스의 상징과도 비슷한 존재가 되어 오늘날 웹브라우저, 파일 매니저 및 기타 등등 유닉스용 프로그램 상당수는 에디터가 아니라 할지라도 기본적인 vi의 키맵을 지원하는 경우가 많다.

vi가 어렵다는 인식이 있는데, 실제 어려운 건 Emacs이고, vi의 경우는 처음에 직관적이지 않을 뿐, 매우 빠르게 습득이 가능하다. vi가 다양한 빌트인 함수를 이용하는 것이라면, emacs의 경우에는 아예 함수를 바닥부터 직접 만들어서 쓰는 편집기라 보면 간단하다. 덕분에 Emacs는 단순 편집기의 영역을 넘어 뉴스리더, 웹서핑, 메일 클라이언트, 파일매니저 등등등을 다 수행이 가능하고(vim으로도 가능하다.) 그만큼 제대로 사용하기가 엄청나게 어렵다.

명령어를 외울 때도 자주 쓰는 명령어조차 키 조합을 추가로 조합해서 사용하는 경우가 잦은 Emacs에 반해 vi에서는 그냥 영문 단타로 끝나는 경우가 많아 금방 손에 익게 된다. 물론 강력한 사용을 위해서는 정규표현식도 습득할 필요가 있지만, 이것은 굳이 vi가 아니더라도 유닉스 환경이나 프로그래밍에서 모르면 안 되는 것에 속하고, 굳이 모르더라도 매크로 기능으로 대부분 대체가 가능하다. 말 그대로 키 스트로크를 레코딩해서 원하는 횟수만큼 자동 반복을 시키는 기능이다. 정규표현식의 경우 더 편리하긴 하지만, 사소한 오타에 왕창 잘못되는 경우가 많아(undo 기능이 있으니 큰 문제는 아니다.), 직접 눈으로 중간과정을 보면서 컨트롤이 가능한 매크로 기능을 더 애용하는 사람도 많다. 즉 기본적인 커서 이동, 모드 전환, kill/yank/paste, 버퍼/창 관리에 더해 정규표현식과 매크로만 어느 정도 알아도 기본적인 사용에는 거의 문제가 없으며, 텍스트 편집 시 훨씬 적어지는 키보드 타수를 느낄 수 있다.



이것이 처음 나온 1976년 당시에는 사진과 같이 키보드에 화살표 키가 따로 배정되지 않았다. 일반 모드에서의 hjkl 키는 이 화살표 키를 대신하는 키들. vim에서는 화살표 키를 사용해도 된다. 그리고 진성 vi빠들은 화살표까지 손을 옮겨가며 타이핑하려면 '손이 항상 자판키 위에 있다'라는 vi만의 장점이 사라지니까 화살표를 쓰면 그건 vi가 아니라고 한다. 그리고 당시 키보드는 사진에서 보이듯이 Esc와 Ctrl이 누르기 아주 편한 위치에 있기 때문에 vi의 키 배열도 이에 최적화되어 Esc 와 Ctrl을 많이 사용한다. 하지만, 오늘날 키보드에서는 이 두 키 모두 키보드 중심과는 좀 떨어져 있기 때문에 OS 상에서 키 배열을 바꿔쓰는 게 편하다. 혹은 Esc 키 대신에 ctrl+[를 써도 된다. 아니면, 해피 해킹 키보드 같은 경우는 아예 윈도우 사용자를 전혀 고려하지 않고 vi에 최적화되어 나온 키보드라 볼 수 있으니 골수 vi 팬이라면 가격이 비싸지만 장만하는 것도 나쁘지 않을 것이다.

세상에 공개되고 많은 시간이 흐른 만큼, 커뮤니티가 크고, 관련 노하우를 쉽게 검색할 수 있다.
커스터마이징이 쉽다는 점, 그리고 많은 사용자들이 사랑한다는 점이 만나 유용한 플러그인들이 굉장히 많이 개발되었고, 또 지금도 개발되고 있다. 관련 플러그인들은 공식 홈페이지의 스크립트 페이지나 Awesome 페이지에서 쉽게 접할 수 있다.

프로그래머를 위한 다양한 플러그인들이 존재하는데, 특히 YouCompleteMe를 추가하고, 각 개발 언어에 따른 세팅을 하고 나면 IDE와 동급이거나 그 이상의 편리함을 자랑한다.

가장 큰 문제는 초심자가 익숙해지기까지의 과정이 험난하다. 까놓고 말하면 불편하다. 숙달되면 편하고 강력하다지만 일단 숙달이 필요하다는 것 자체가 불편하다는 가장 큰 증거다. 이미 vi에 익숙한 사람들은 넉넉잡아 하루 '정도'면 기본적인 조작은 습득 가능하다고 하는 등 이런 장벽을 과소평가하는 경향이 있는데 그건 바둑 기본 규칙 대여섯가지 알려줘 놓고 이제 바둑을 '둘 수 있다'고 말하는 것과 다르지 않다. vi의 강력함은 수많은 명령어와 이들의 조합/연계에서 오는데, 이것을 하루이틀만에 배우고 써먹는 것은 불가능하다. 그리고 그 단계에 이르기 전까진 vi는 그 어떤 면에서도 메모장보다 메리트가 없다.

두번째 문제는 vi의 키맵은 오늘날의 사용자 경험을 전혀 따르지 않는다. 예를 들어 Ctrl CV로 복사와 붙여넣기를 하는 것은 사실상 표준이지만, vi에서는 Y와 P를 사용한다.[5] 화살표 대신 hjkl을 쓰고 Del 대신 x 같은 명령어를 쓰는 것도 익숙해지면 타이핑 기본 자세에서 커서를 움직일 수 있고 키보드 구석까지 손을 안 가져가도 되는 획기적인 배열이겠지만, 배우는 입장에선 WASD 같이 직관적인 방향이 있는 것도 아닌 그냥 평면에 화살표 그려놓은 것일 뿐이다. 무엇보다 인간은 새 것을 배우는데 인색하다. 보통 사람들은 십중팔구는 "우왕, 열심히 hjkl 키를 익혀서 더 편하게 써야지!"라는 반응이 아니라 "요즘 버전은 화살표도 지원하잖아? 걍 화살표 쓸게." 같은 반응을 보인다.

세번째로, 현재 키보드 배치에서는 vi에서 가장 중요한 키인 Esc가 왼쪽 위 구석에 박혀있기 때문에 vi의 장점인 손이 많이 안 움직여도 된다는 사실도 반감되었다. vi가 타겟으로 했던 키보드에서는 현재의 Tab 위치에 Esc가 위치해 있었다. 보통은 Caps Lock과 Ctrl 위치를 바꿔 쓰는 경우가 많은데, vi의 경우는 위와 같은 이유 때문에 추가적으로 Tab과 ESC 위치를 바꾸는 것도 권장된다. 아니면 Ctrl보다 Esc를 vim에서 압도적으로 많이 쓰는 걸 생각해서 Ctrl은 그냥 냅두고 Caps Lock에 Esc를 맵핑하든가 할 수도 있다. 사실 Ctrl+[가 Esc와 똑같은 기능을 수행하므로 딱히 단점은 아닌데, vim 좀 쓴다는 사람들 중에도 모르는 사람이 많다. 또, vi에 익숙하다고 해도 유닉스 터미널에서 프로그래밍 하는 게 아닌 한 다른 일 하기 위해 결국 마우스에는 손이 가야 한다는 점도 있다.

숙련된 프로그래머가 사용할 경우 일반적인 편집기보다 빠르게 소스 코드를 편집할 수 있긴 하나, 그렇다고 생산성을 극적으로 올려 준다고 보기는 힘들다. 예를 들어 윈도우즈 프로그램을 vi와 WinAPI를 써서 개발하는 것보다 그냥 VS와 MFC로 개발하는 것이 더 빠를 것이며, 비주얼 스튜디오, IntelliJ IDEA, 이클립스 등 강력한 IDE에서 언어에 특화된 여러 기능들을 제공하기 때문에 그런 기능을 이용하지 않는다면 구질구질하게 암기해서 타이핑 할 것을 내장된 단축키 조합만으로도 코딩, 리팩터링 작업을 할 수도 있다. vi가 텍스트 편집에 이점이 있더라도 좋은 프레임워크와 클릭 몇 번으로 많은 타이핑 작업을 대체할 수 있는 IDE를 사용하는 것보다 생산성이 높다고 할 수는 없다. 프로그래밍을 할때 타이핑에 걸리는 시간은 극히 적다.

물론 vi와 육중한 IDE의 기능은 서로 충돌하는 것이 아니다. vi의 핵심은 키맵이고, IDE의 핵심은 특정 언어에 특화된 여러가지 편의 기능들이다. 즉, 다양한 편의 기능을 갖고 있는 IDE에 vi의 키맵을 올려 사용한다거나 혹은 vi에서 편집하고 IDE로 불러와서 원하는 기능을 적용하는 식으로 얼마든지 절충이 가능하다. 단순한 비호가 아니고, vi와 IDE를 동시에 사용하는 프로그래머도 적지 않으며, 실제로 많이 쓰는 IDE&편집기에는 vi 플러그인이 있는 경우가 많다. 그 예는 아래 번외편을 참조.

반대로, 전세계 vim 덕후들이 만들어 놓은 vim 플러그인을 붙이고 설정 파일 커스터마이징하면 텍스트 편집기 수준을 넘은 강력한 자동 완성 기능을 포함한 일종의 IDE로 만들어 놓을 수 있다.

한글을 사용하는 사용자라면 입력 모드에서 ESC를 눌러 일반 모드로 전환 시 한글 입력 모드를 영어 입력 모드로 변환해야 하는 번거로움이 있다. vim 자체에서 해결하는 방법도 있지만, pc 환경에 따라 해결이 안 되는 경우도 많다. 이 경우 ESC를 누를 시 자동으로 영어 입력 모드로 변환이 가능한 fcitx나 UIM 같은 입력기를 사용하는 것이 좋다. fcitx의 경우 felis vim 플러그인을 사용하면 되고, UIM일 경우 ESC를 누를 시 자동으로 영어 입력 모드로 변환해 주는 입력기 자체 기능을 사용하면 된다. vim을 주로 사용하는 사용자라면 ibus를 사용하지 않는 것이 정신건강에 이롭다. 사실 ibus는 다른 프로그램과도 호환성이 좋지 않다. 일례로, JetBrains 사의 IDE들은 ibus 입력기가 감지되면 경고를 내뿜는다!

또 한가지 문제라면 정규 표현식이나 GVIM 자체 렌더링 속도가 빠르지 않다. 요즘 컴퓨터에서 아주 문제될 정도는 아니지만 심한 경우에는 버벅거리는 경우가 있는데 주로 IDE처럼 변수명 하이라이팅을 하면 이런 일이 생긴다. 해결 방법은 하이라이팅을 끄든지, 참고 쓰든지, 다른 에디터로 갈아 타든지.

다음은 vi에서 주로 사용하는 3가지 모드.

일단 처음 사용할 때는 대부분 기존에 있는 파일을 수정하는 경우일 것이다. vi는 리눅스를 처음 접할 때 거의 백이면 백 필수적으로 접하게 되고, 리눅스의 각종 설정 변경은 설정이 담겨 있는 텍스트 파일을 직접 수정하는 일이 많기 때문이다. 이 경우는 많은 명령어를 기억할 필요 없이 위에 있는 설명만으로도 충분히 사용 가능하다. 요즘 리눅스 배포판에 기본으로 들어 있는 vi는 입력 모드가 일반적인 텍스트 에디터와 거의 비슷하게 작동한다. 커서도 화살표 키로 이동 가능하다.

vim에서는 wq 대용으로 x 명령어가 있다. :x 의 경우 변동 사항이 없으면 그냥 종료한다. 반면 :wq는 항상 저장하고 종료한다. :x와 달리 :X는 파일 암호화에 사용되는 명령이므로 절대로 혼동하지 않도록 하자.

스크립트를 통한 확장 기능을 사용할 수 있다. vim 사이트에서 하나씩 받아서 적용할 수도 있으나, vundle이란 확장 기능을 통해 플러그인 설치 자동화를 할 수 있다. http://wiki.kldp.org/wiki.php/VimEditor 에서 vundle 관련 내용을 참조.

브라우저에 vim의 키 매핑을 적용해서 웹서핑을 즐기는 것도 가능하다. 마우스나 트랙패드의 필요성이 사라지거나 최소화된다. 특히 포인팅스틱이 탑재된 키보드와 같이 사용하면 매우 최적화된 웹서핑을 할 수 있다. 키보드 정중앙에 위치한 포인팅스틱과 키보드 아래의 버튼들이 마우스 역할을 대신하고, 그럼으로써 키보드에서 손이 떠나지 않고 웹서핑을 할 수 있기 때문이다.