UNIX as IDE: 1. Introduction

이 시리즈의 원 저자인 Tom Ryder의 허락을 받고 올리는 번역글입니다. IDE가 할 수 있는 기능을 UNIX 계열의 shell 안에서도 원활하게 할 수 있는 비결을 초보자도 알기 쉽게 잘 설명한 글일 뿐만 아니라 UNIX 자체의 철학이나 기본 사용법을 따라잡기에도 굉장히 좋은 글이라 생각되어 우리말로 옮기고자 합니다. 프로그래밍 용어는 웬만하면 원래 영단어로 쓰겠습니다. 언제든지 더 좋은 표현에 대한 의견은 감사합니다.

UNIX as IDE: Introduction

2012년 2월 9일 Tom Ryder가 작성

초보 개발자부터 고수까지 IDE(Integrated Development Environment)의 개념은 모두 비슷하게 알고 있을 것이다. 공통된 인터페이스 안에서 프로젝트 구성, 파일 작성, 유지 보수, 테스팅, 디버깅을 위한 주요 도구들을 통합한 하나의 응용프로그램은 확실히 중요한 재산이다. 또한 각 프로그래밍 언어에 알맞게 구성된 환경의 IDE는 자동 완성, syntax 검사 및 하이라이트를 제공한다.

GNU/Linux, BSD를 포함한 주요 데스크탑 운영 체제에서 이러한 도구를 대부분 자유롭게 사용할 수 있다. 따라서 Windows 메모장이나, nano, cat을 이용해서 코딩을 하는 것은 딱히 좋지 않을 것이다.

하지만 UNIX(와 그 후예들)의 추종자들 사이에서는 이런 우스갯소리가 있다. "UNIX is an IDE.", 최신 IDE의 주요 기능을 터미널의 도구를 이용해서 대등한 능률로 작업할 수 있다는 의미이다. 이에 대한 의견은 분분하다. 당신은 UNIX가 Eclipse나 MS Visual Studio와 같은 IDE와 대등하다고 생각하는가? 당신은 구닥다리 Bash shell이 얼마나 훌륭한 개발 환경이 될 수 있는지 놀라게 될 지도 모른다.

그래서 어떻게 UNIX가 IDE로?

개발자에게 필요한 개별적인 도구들이 각각 서로 협동하기 위해 노력하기 보다는, 그 도구들을 이미 한 곳에 모아 놓고 어느 정도 일관적인 UI(User Interface)를 통해 조화롭게 사용할 수 있도록 하는 것이 IDE를 사용하는 가장 주요한 이유일 것이다. 특히나 GUI 프로그램들 간에 서로 소통할 수 있도록 만드는 것은 매우 어렵기 때문에 더욱이 중요한 이유가 된다. 복사 + 붙여 넣기를 제외하고는 GUI 프로그램 사이에서는 데이터가 오갈 수 있도록 하는 공통된 인터페이스를 공유하지 않는 것이다.

Shell 사용자의 입장에서 흥미로운 점이 있다. 오랜 시간을 거쳐 잘 디자인되고 발전하고 있는 UNIX 도구들은 항상 공통된 UI를 영구적인 객체로서 텍스트와 파일 stream의 형태로 -- 그렇지 않다면 "Everything’s a file"이라는 UNIX 원칙에 맞는 형태로 -- 갖는다는 것이다. UNIX의 대부분은 이러한 두 가지 개념을 바탕으로 만들어졌으며, 40년에 걸쳐 사용자와 개발자가 상호운용성(interoperability)을 특히 중요하게 여기면서 개발해 온 강력한 도구들과 결합된 일관적인 UI는 오래 전부터 Unix를 본격적인 IDE로 나아가게 하고 있다.

UNIX 철학에 맞는 방법으로

이러한 평가는 산전수전 다 겪은 UNIX 수염쟁이들을 위한 오래된 생각이 아니다. 고대부터 텍스트 편집기로 쓰여온 Emacs와 Vi(그 자손인 GNU Emacs와 Vim)가 요즘 시대에 새롭게 태어나는 것을 봐도 알 수 있다. 이 두 텍스트 편집기는 매우 활발한 커뮤니티를 통해 플러그인을 개발해가며 거의 모든 편집 기능을 가능케 하고 있다. 코딩에 관한 웬만한 기능들은 플러그인이 지원해준다. Vim 추종자들에게 물어본다면 스스로 "필수적"이라고 생각하는 플러그인을 최소한 세네 개 정도 곧바로 외쳐댈 것이다.

그런데 이러한 커뮤니티의 노력을 보자면 텍스트 편집기를 IDE에 맞게 만들려고 애쓰고 있다는 생각이 든다. "Never needing to leave Vim", "never needing to leave Emacs"와 같은 주제의 글이 보이기도 한다. 하지만 텍스트 편집기의 본질에서 이렇게 억지로 벗어나려고 시도하는 것이 문제에 대한 올바른 접근이라고 생각이 들지 않는다. :help design-not을 보면 Vim의 창시자 Bram Moolenaar 역시 필자의 의견에 어느 정도 동의하고 있다. Shell은 어디까지나 CTRL-Z 방법으로 사용하는 것이며(원문: The shell is only ever a Ctrl+Z away), shell의 검증된, 서로 결합 가능한 toolset을 통해 편집기 자체로 할 수 있는 것보다 강력해질 수 있다.

2017년 10월 필자의 추가 사항: 새로운 버전인 Vim 8.x 부터는 :terminal 명령을 통해 내장된 터미널에 접근할 수 있게 됐다. 여전히 이런 저런 문제는 있지만, 플러그인 기반의 접근 방식보다는 낫다. 그렇다고 할 지라도 이 글이 주장하는 바는 변하지 않으며, 여전히 필자는 기존 방식을 추천하고 싶다.

이 시리즈에 대해

이 시리즈를 통해서 필자는 IDE의 여섯 가지 주요 기능들을 짚어보며 GNU/Linux가 얼마나 수월하게 기본 도구를 통해 그 기능을 수행할 수 있는 지 예제를 통해 설명하려 한다. 하지만 이 글이 기본 도구에 대해 하나도 빠짐없이 완벽하게 조사하는 것은 아니며, 또한 여기서 설명하는 방법이 유일한 방법이 아님을 미리 알린다.

• File and project management — ls, find, grep/ack, bash
• Text editor and editing tools — vim, awk, sort, column
  
• Compiler and/or interpreter — gcc, perl
  
• Build tools — make
• Debugger — gdb, valgrind, ltrace, lsof, pmap
• Version control — diff, patch, svn, git

오해하지 말아 달라

필자는 IDE가 별로라고 생각하지 않는다. 오히려 훌륭하다고 생각하기 때문에 UNIX를 IDE로 사용할 수 있다고, 또는 적어도 IDE라고 여길 수 있도록 이 글을 쓰며 당신에게 알려주려 하는 것이다. 필자는 또한 UNIX가 항상 프로그래밍 작업을 위한 최고의 도구라고 주장하는 것이 아니다 -- 물론 Java 또는 C#과 같은 "기업 레벨" 언어보다, 특히 GUI가 주된 개발보다는 C, C ++, Python, Perl, shell 개발에 있어서 UNIX 시스템이 훨씬 적합하다고 주장할 수 있지만. 특히, 열심히 익힌 Eclipse 또는 Microsoft Visual Studio 지식을 버리고 기괴한 명령줄의 세계에 들어오라고 설득하려고 하지는 않는다. 필자는 그저 울타리의 반대편에서 우리가 어떻게 일을 하는지 보여주려는 것이다.

UNIX as IDE

• 1. Introduction
• 2. Files
• 3. Editing
• 4. Compiling
• 5. Building
• 6. Debugging
• 7. Revisions