코드 편집기의 필수 요소
요리사, 도예 장인, 그래픽 디자이너 등 뭔가 만드는 사람들은 자신만의 작업공간과 질서를 만듭니다. 소프트웨어 엔지니어에게 가장 중요한 도구는 프로그램을 작성하는 코드 편집기 입니다. 이번 글에서는 코드 편집기를 바꿔온 여정을 소개하며 제가 생각하는 코드 편집기의 필수 요소들을 이야기해보겠습니다.
코드 편집기를 바꾼 경험
저는 오랫동안 Emacs 코드 편집기를 사용하고 있었습니다. 제가 프로그래밍을 시작했던 시기엔 요새 많이 사용하는 Visual Studio Code 같은 발전된 코드 편집기기 없었습니다. 그 시기엔 리눅스 환경에도 익숙해지려고 하던 때라 터미널 안에서 사용할 수 있는 코드 편집기를 선택했습니다. 가장 널리 사용되던 편집기는 Emacs와 Vim이었는데 Lisp 언어로 자유로운 확장이 가능하다는 점과 더 배우기 어렵다는 점에 끌려 Emacs를 택했습니다. 오랫동안 Emacs를 사용해오며 능숙한 사용자가 되었고 나중에 VS Code 같은 편집기가 등장해도 별로 옮겨갈 생각이 들지 않았습니다. 가장 큰 이유는 VS Code 를 터미널 안에서 사용할 수 없다는 점이었는데 저는 주로 백엔드 개발을 터미널 상에서, 그리고 종종 원격으로 하기 때문입니다.
또한 소프트웨어를 개발하는데 대단한 도구들이 필요하지 않았기 때문입니다. 저는 터미널, 쉽게 여러 터미널을 사용하게 해주는 도구, 소프트웨어 작성을 위한 명령행 도구들 그리고 코드 편집기 이렇게 준비되었다면 개발 시작입니다. 터미널에서 작업하며 도움이 된 습관이 있습니다. 대부분의 작업은 마우스 대신 키보드 키입력을 통해 수행하는데 마우스와 키보드를 오갈 필요가 없어 효율적으로 일할 수 있습니다.
이런 와중에 1년 전 즈음 변화가 한번 있었습니다. Goldtouch 인체공학 키보드를 구입하고 봤더니 Emacs를 사용하기엔 키 배열이 불편했습니다. 며칠 간은 시스템 설정을 통해 해결해볼까 고민하여 고쳐봤는데 쉽지 않았습니다. 그러다 깨달음의 순간이 있었습니다. Hardware를 바꾸기 어렵다면, Software를 바꾸기 어렵다면 Wetware를 바꾸자! 그냥 제가 Vim binding에 익숙해지면 되는 일이었습니다. 그땐 바로 Vim을 사용하는 대신 Doom emacs라는 Emacs 설정 도구를 사용했습니다. Emacs에서 Vim 키바인딩을 사용할 수 있게 해주는 Evil mode + SpaceEmacs에서 차용한 Leader key 기반의 명령 수행 + 쉬운 패키지 관리 등의 기능을 제공합니다. 아직은 Emacs의 여러 지식들이 익숙하기도 하고 원하면 고전적인 Emacs 키바인딩을 사용할 수도 있었기 때문에 큰 거부감은 없었습니다.
그렇게 잘 사용하다가.. 어느 날 작동이 이상해졌는데 알고보니 Doom emacs에서는 최신 버전의 Emacs는 지원하지 않는 것이었습니다. 리눅스 배포판에서 기본으로 제공하는 Emacs 패키지는 버전이 정해져있고 굳이 다운그레이드 시키기는 싫어서 이때 다시 새로운 변화를 가졌습니다. 이제 Vim 키바인딩에도 익숙해졌겠다.. Emacs 대신 Vim을 사용해보기 시작합니다. Vim에도 여러 파생 버전이 있는데 저는 Neovim을 선택했습니다. Neovim은 Lua 언어를 통한 확장이 가능해서 유연하게 기능을 더할 수 있고 필요하면 직접 만들어 사용할 수도 있습니다. 맘에 드는 패키지들을 선택하고 키 매핑도 하고 (Emacs에서 사용하던 키 매핑 일부를 가져왔습니다) 컬러 테마도 바꾸고 했습니다. 하지만 얼마 지나지 않아 좋은 도구를 찾았는데 마치 Doom emacs와 같이 Vim에도 미리 패키징 해둔 설정 도구가 있었습니다. LunarVim, LazyNvim, AstroNvim 등이 있었는데 저는 AstroNvim을 골랐습니다. 한번 실행해보니 Doom emacs처럼 Space leader key 기반의 명령 호출이 기본이고 개발에 필요한 모든 도구들이 잘 갖춰져 있었습니다. 패키지 설치도 쉽고 빠릅니다. 보통은 제 입맛에 맞게 편집기 설정을 매만져 사용하는데 AstroNvim의 경우 이미 사려깊게 설정이 되어있어 공식 매뉴얼을 참고하여 키 매핑들을 익히는게 나았습니다. 가벼운 설정을 마치고 며칠 사용해봤는데 예전만큼 아니 그 이상 효율적으로 소프트웨어 작성을 할 수 있을 것 같습니다.
쾌적한 개발 환경에는 어떤 것들이 필요할까
코드 편집기를 여러번 바꾸면서 든 생각은, “내가 원하는 개발 환경을 갖추기 위해선 코드 편집기의 어떤 요소들이 필수인가” 입니다. 물론 파일을 열고 편집하고 저장하는 기능만 있어도 코드를 작성할 수 있겠지만 생산적인 소프트웨어 개발은 그 이상이 필요합니다. 사실 하나의 단일한 개발 환경은 없을텐데 사람마다 손에 익은 도구들과 사용법이 다르고 작업 분야에 따라 서로 다른 접근이 있을 것이기 때문입니다. 저는 앞서 알려드린 것처럼 백엔드 개발이 주 업무라 그래픽 화면 혹은 외부 장치 등에 대한 고려는 특별히 하지 않아도 됩니다. 따라서 다른 개발 분야와 비교했을 땐 더 작은 영역, 공통적으로 적용될 수 있는 그런 영역이 될 것 같습니다.
버전 컨트롤 기반 프로젝트 감지
현대의 대부분의 소프트웨어 프로젝트는 Git과 같은 버전 컨트롤 도구 아래에 파일을 두고 작업합니다. 따라서 대부분의 소프트웨어 개발 작업은 이런 프로젝트 (예. Git 저장소) 단위로 수행합니다. 편집기는 현재 사용자가 다루고 있는 프로젝트가 무엇인지 알아야 하며 아래 나올 기능들도 그런 프로젝트 감지 기반으로 동작해야 합니다. 특히 검색의 경우, 관련 없는 위치의 파일을 보여주거나 프로젝트와 무관한 파일에서 내용을 검색하면 사용성을 크게 해칩니다.
손쉬운 파일 접근 및 검색
소프트웨어는 다수의 파일로 구성됩니다. 소프트웨어 자체를 구성하는 소스 코드들이 있으며 그 밖에 인프라 구성, 설정 파일, 개발 과정을 지원하는 스크립트 등 다양한 파일들을 오가며 편집합니다. 이때 파일을 오가는 행위가 편해야 하는데 프로젝트 내 파일들을 대상으로 Fuzzy 검색을 해주는 기능이 있다면 파일 경로와 파일명의 일부만 입력하여 쉽게 원하는 파일로 이동할 수 있습니다. 추가적으로 파일 트리를 보여준다면 현재 어떤 파일을 편집하고 있는지 알 수 있고 넓은 시야로 프로젝트 구조를 볼 수 있습니다. 이 기능이 없거나 활용하지 않는다면, 수동으로 파일 위치를 찾아가야 하며 파일 트리를 탐색하는 과정에서 커서의 이동을 위한 많은 키 입력이 필요합니다.
프로젝트 전반에 걸친 내용 검색
단어 기반 검색은 하나의 파일 안에서 수행하거나 다수의 파일을 대상으로 수행할 수 있습니다. 이때 역시 프로젝트와 관련된 파일들을 자동으로 파악하여 검색 대상으로 한정시켜주면 도움이 됩니다. 또한 하나의 파일을 검색하든 다수의 파일에서 검색하든 공통으로 도움이 되는 기능은 Fuzzy Search입니다. 앞서 파일 검색에서 사용했듯이 단어의 철자를 정확히 입력하지 않고도 유사도를 따져 검색을 수행해주는 기능입니다.
화면 분할 및 이동
소스코드를 작성할 때나 문제 해결을 위해 참고하는 경우 하나의 화면이 부족한 경우가 있습니다. 이럴 땐 화면을 세로 혹은 가로로 분할하여 서로 다른 파일들을 동시에 열어 참고할 수 있어야 합니다. 또한 현재 커서가 위치한 화면에서 다른 화면으로 손쉽게 이동할 수 있어야 합니다. AstroNvim의 바인딩의 경우, “|” (화면 세로분할) “/” (화면 가로분할) “C-h,j,k,l” (화면 상하좌우 이동) 한번의 키 입력으로 각자의 기능을 수행할 수 있어 화면 분할과 이동이 시간/인지비용을 거의 소비하지 않습니다.
세션 관리
작업은 보통 하나의 프로젝트를 대상으로 하지만 경우에 따라선 서로 다른 프로젝트 사이를 오가며 작업을 해야하는 경우가 있습니다. 저의 경우엔 기존 프로젝트를 템플릿 삼아 다른 프로젝트를 만들어 사용할 때 필요했습니다. 어떤 기능들을 가져올지 예전엔 어떤 방식으로 해결했는지 참고하며 구현할 땐 두 프로젝트를 자주 오갑니다. 이때 필요한게 세션 관리 기능입니다. 한 프로젝트에서 작업하던 내용들을 기억해주는 기능인데 어떤 파일들을 열고 있었는지 어떤 화면 구성을 사용하고 있었는지 등을 기억해줍니다. 코드 편집기를 종료하고 다시 실행해도 마지막으로 작업한 상태에서 다시 시작할 수 있습니다.
코드 분석 및 에러 탐지
소스코드 역시 하나의 글이기 때문에 오탈자가 발생할 수 있고 구조적으로 흠이 있을 수 있습니다. 예를 들어 변수를 선언하고 사용하지 않고나 미리 정의한 타입과 다른 타입의 값을 할당하는 문제가 있을 수 있습니다. 어떤 경우는 명백한 오류는 아니지만 더 나은 방법이 있을 때도 있습니다. 이렇게 프로그램의 품질 (곧 작성한 글의 질)을 낫게 만드는 여러가지 도구가 있는데 대표적으로 코드의 형태를 표준화시켜주는 Formatter, 코드의 오류를 정적으로 분석해주는 Linter, 그리고 타입 오류를 찾아주는 Type checker 등이 있습니다. 코드 편집기가 이런 도구들을 통합하여 편집 화면에서 보여주면 빠르고 손쉽게 오류를 찾아 고칠 수 있습니다.
버전 컨트롤 도구 지원
현대의 소프트웨어들은 혼자 작성하는 것이 아니라 다수의 엔지니어들이 힘을 합쳐 작성합니다. 동시에 서로 다른 부분을 병렬적으로 작업하고 때로 동일한 파일을 편집하기도 합니다. 이렇기 때문에 소프트웨어의 수정 사항을 추적하는 버전 컨트롤 도구를 사용합니다. 프로젝트의 마지막 동기화 상태에서 내가 어떤 수정들을 만들었는지 정리해서 보여주는 기능이 코드 편집기에 통합되어 있다면 실수를 줄일 수 있습니다.
내장 터미널 화면
저는 백엔드 작업을 하면서 때때로 터미널에서 명령을 실행합니다. 작성한 코드를 로컬 환경에서 실행해보거나 데이터베이스의 상태를 확인하는 작업 등이 필요합니다. 저는 Tmux라는 도구를 사용하여 쉽게 편집기와 터미널 사이를 오가고 있는데 코드 편집기 자체적으로 내장 터미널을 제공하는 것도 작업 효율을 높여줄 수 있습니다.
Emacs vs Vim? 아니 Code Editor
지금은 Visual Studio Code가 가장 널리 사용되지만, 제가 처음 프로그래밍을 하던 시기에는 Emacs와 Vim이 코드 편집기의 양대 산맥이었고 두 진영이 서로 자신의 편집기가 우월하다고 주장하는 일이 있었습니다. 그때 Emacs를 사용하던 저 역시 제가 선택한 도구에 대한 편향이 있어 Emacs의 장점을 떠올리는 동시에 Vim의 단점을 떠올리곤 했습니다. 하지만 십년이 넘는 시간이 지나 지금의 다시 보니 그때의 장단점은 서로 희석되고 부족한 부분들을 보완하여 각자 나름의 취향을 가진 뛰어난 편집기들이 되어 있었습니다. 사용하기 어렵기로 소문났었던 Emacs는 Doom emacs 같은 설정 도구들이 사용성을 높여 초심자들도 쉽게 적응할 수 있게 되었으며, 확장성 부분이 아쉬웠던 Vim은 Neovim처럼 프로그래밍 언어 기반의 확장을 도입하여 무한한 기능 추가의 길을 열었습니다. 불교의 가르침 중 하나는, “상을 짓지 말라”입니다. 세상의 모든 것들은 인연에 따라 일어나며 고정되고 영원한 것은 없습니다. 한때의 Emacs 사용자가 오늘은 Vim 사용자가 될 수 있고 경우에 따라선 Notepad 사용자가 될 수도 있습니다. 다만 그때 그때의 상황에 따라 소프트웨어 개발에 가장 적합한 도구가 있을 뿐입니다. 하나의 도구에 집착하는 것, 그 도구를 사용하는 나 자신의 이미지에 집착하는 것은 진짜 문제를 보지 못하게 합니다. 결국 도구를 사용하는 건 쉽고 편하게 소프트웨어를 만들기 위함이니까요.
닫는글
오늘의 내가 어제의 나, 미래의 나와 같지 않듯 오늘의 코드 편집기와 작업 환경도 영원하지 않습니다. 우리의 모험은 끝나지 않을 것이며 그 여정을 즐기는 마음을 갖는게 필요하겠습니다 :)