▲

30년 전 우리가 가졌고, 이제는 잃어버린 IDE들

 (blogsystem5.substack.com)
1P by GN⁺ 11시간전 | ★ favorite | 댓글 1개
  • 1990년대 초 텍스트 기반 IDE들은 제약된 하드웨어에서도 뛰어난 기능을 제공했음
  • 당시 대표적 IDE였던 Borland Turbo 시리즈는 구문 강조, 컴파일러 통합, 디버깅, 도움말 등 현대 IDE에 필적하는 환경을 갖췄음
  • 리눅스의 Vim과 Emacs는 커스터마이징 가능하지만, 배우기 어렵고 초보자에게 직관적이지 않은 점이 한계였음
  • 최근 TUIs(텍스트 UI)와 IDE 기능은 LSP 등 신기술 등장으로 점차 부활 중이나, 여전히 90년대 수준의 일체감은 부족함
  • TUI IDE의 장점은 원격 접속, 가벼운 리소스 소모, 오픈소스 자유 등이며, 반면 현대 IDE는 기능 추가에 따른 비대화 현상이 두드러짐

서론: 1990년대 초 텍스트 기반 IDE의 추억

  • 1980년대 후반~1990년대 초, 필자는 DOSBox로 옛날 개발 환경을 다시 체험하며 현대와 비교해보는 즐거움을 느꼈음
  • 당시 텍스트 기반 IDE들은 하드웨어 제약에도 불구, 많은 기능을 갖추고 있었음
  • 그 이후 대다수의 기능이 윈도우 운영체제의 부상과 함께 오랜 기간 사라졌고, 최근에서야 일부 기능이 다시 등장하고 있음

초기 에디터와 TUI 환경

  • 1990년대 대부분 DOS 프로그램은 풀스크린 Text User Interface(TUI) 를 사용해 텍스트 기반 윈도우, 컬러, 그림자, 심지어 마우스까지 지원했음
  • 각 프로그램은 디자인이 달랐지만, 비슷한 작동 방식 덕분에 금방 배울 수 있었음
  • MS-DOS는 5버전(1991)부터 내장 TUI 에디터를 제공했으나, 컴파일/실행을 위해 에디터를 종료해야 했고, 다시 불러오면 작업 위치를 찾아야 하는 불편함이 있었음
  • SideKick Plus(1984)처럼 TSR(상주 프로그램) 기반 도구도 있었으며, 이는 멀티태스킹이 되지 않던 OS에서 효율적 코드 편집과 빌드를 가능하게 해줬음
  • 이미 1980년대 중후반에는 Turbo Pascal, QuickBASIC 등 초기 IDE가 등장했고, 통합 개발 경험을 제공했음

Borland Turbo 시리즈: 통합 IDE의 정점

  • Borland Turbo C++, Turbo Assembler, Turbo Pascal 등은 특정 언어 전용이었으나, 풀스크린 TUI와 강력한 기능을 제공했음
  • 주요 기능:
    • 구문 강조로 코드 가독성 향상
    • 컴파일러 통합 및 경고/진단
    • 프로젝트/빌드 시스템 제공 및 멀티윈도우
    • 디버거(중단점, 콜스택 등)
    • 내장 도움말/레퍼런스 매뉴얼
  • 모든 기능은 90년대 초 인터넷 없이도 자체적이고 직관적인 환경을 제공했음

당시 리눅스 환경 비교

  • 리눅스 역시 텍스트 기반 툴이 주류였으나, 풀스크린 TUI는 흔치 않았음
  • 책과 커뮤니티에서 추천한 Vim, Emacs는 기능적으로 확장 가능했으나, 초보자 입장에서 불친절하고 직관성이 부족했음
  • 예를 들어 Emacs는 꾸밈 없는 창, 제한적 컬러, 불안정한 마우스 지원, 어렵고 낯선 메뉴 인터페이스 등이 문제였음
  • Borland Turbo C++ 등의 IDE는 아무런 사전 지식 없어도 몇 분 만에 “Hello World” 프로그램을 만들고 환경 탐색이 가능했음

오늘날의 텍스트 기반 IDE

  • 현대에는 과거의 TUI IDE와 가장 유사한 환경으로 RHIDE, Free Pascal, QB64 등이 있음
    • RHIDE는 Turbo C++와 거의 동일하지만 DOS 전용으로 개발 중단됨
    • Free Pascal은 유닉스 환경 지원, 내장 계산기, ASCII 테이블 등 강력한 통합 환경 제공
    • QB64는 TUI처럼 보이지만 실제는 GUI 시뮬레이션이며 터미널에서는 실행 불가
  • Free Pascal, QB64 모두 최근까지 개발되고 있으나, 낡은 언어 노출로 대중적 인기는 약함

진정한 현대 콘솔 IDE

  • 최신 텍스트 기반 통합 개발환경으론 Neovim, Doom Emacs, Helix 등이 유명함
  • 이들은 다양한 플러그인 덕분에 IDE 수준 경험을 제공하지만, Borland 제품군과 같은 언어별 통합성/직관성은 부족함
  • 최근 GNU Nano 등이 단순 TUI 에디터로 각광받지만, IDE 기능이 없어 WordStar와 유사한 느낌임
  • 결국 오늘날의 콘솔 에디터는 90년대의 경험 수준에 미치지 못하거나, 30년 전 기능을 겨우 회복하고 있음

TUI IDE의 필요성

  • VSCode의 원격 기능이 뛰어나더라도, TUI IDE는 원격 머신에서 SSH 접속 후 바로 사용 가능하다는 점에서 유리함
  • 게다가 VSCode의 원격 확장기능이 오픈소스가 아니고, 일부 OS(FreeBSD 등)에서는 작동하지 않아 제약이 있음
  • TUI IDE는 자원 소모가 적고, 원격 환경에서 더욱 활용도가 높음

비대화 및 "Bloat" 현상

  • Borland Turbo C++은 모든 기능을 포함해 설치시 9MB 이하, 640KB RAM 내 동작 가능했음
  • 현행 Doom Emacs는 500MB 이상, 현대 IDE들은 수 GB에 이르면서 비대화가 심각해짐
  • VSCode는 350MB로 꽤 가볍지만 Electron 기반이라 실제 시스템 자원 소모가 큼
  • 기능, 리팩터링 등 일부 발전 요소는 있지만, 30년 전과 비교해 혁신은 제한적임
  • AI 코드보조 등은 최근 변화이나, 실상은 원격 서비스 제공이 주류임

결론

  • 필자는 상황에 따라 Doom Emacs, Vim, VSCode, IntelliJ 등 다양한 개발 환경을 활용 중임
  • 30년 전의 TUI IDE가 제공하던 일체형 개발 경험 및 효율성은 현대 IDE의 비대화 및 파편화와 뚜렷한 대조를 이룸
  • 텍스트 기반 IDE가 갖는 가치와 잠재력은 여전히 유효하며, 그 진화와 부활 여부는 앞으로 지켜볼 필요 있음
▲
GN⁺ 11시간전  [-]
Hacker News 의견

  • Visual Basic가 그래픽 프로그래밍 분야에서는 최고였음에 큰 충격을 받음. 예전엔 하루면 중간 수준의 GUI 애플리케이션을 아주 빠르게 개발할 수 있었음. 그나마 C# WinForms가 이에 가장 근접했지만, 그 이후의 도구들은 모두 개인 개발자 입장을 고려하지 않아 아쉬움. 새로운 강력한 개발 패러다임으로 보이스/스피치 기반 개발(SDD/VDD)을 제안함. 많은 타이핑의 고통에서 해방되며 AI와의 상호작용이 동료와의 대화처럼 자연스러워졌으면 하는 바람임. 다만 이를 제대로 실현하려면 AI 모델이 훨씬 더 신속해져야 함

    • Delphi가 당시에도 Visual Basic보다 뛰어났고, 여전히 사용 가능함. Lazarus도 계속 남아 있음. 실제로 C# WinForms가 Delphi 경험에 가장 가까움

    • Qt Creator가 VB6와 비슷한 경험을 제공한다고 느꼈음. 혹시 사용해 본 적 있는지 궁금함

  • Emacs는 여전히 이런 특징을 모두 제공한다고 생각함. 다만 저자가 “비전통적”이라 주장하는 것은 자신이 익숙하지 않은 관례 때문임. Emacs는 완전히 자체 문서화되었고, 대화형임. 내가 지금까지 사용한 최고의 텍스트 기반 인터페이스는 Emacs 내부의 Magit임(https://magit.vc/). Emacs의 더 많은 부분이 Magit처럼 되었으면 함. IDE가 달라도 git 클라이언트로는 Emacs를 씀

    • Emacs는 Apple이 cmd-z/x/c/v 단축키를 개발하기 이전부터 존재했던 역사 깊은 툴임. 당시에는 프로그래머의 에디터 단축키로 Wordstar 계열(예: 대부분의 Borland 제품)의 단축키가 주류였음. 요즘에는 잘 알려지지 않았던 30~40년 전의 뛰어난 IDE들이 있었음. 예로 Apple MPW(1986)는 모든 윈도우가 유닉스 셸이 되는 GUI 에디터로, 셸 스크립트로 윈도우와 편집 작업을 제어할 수 있었고, 소스 코드 관리 시스템도 내장됨. 명령어를 입력하고 옵션-Return을 누르면 GUI 기반의 'Commando' 창이 떠서 모든 옵션을 선택할 수 있었음. Apple Dylan(1992-1995)은 Lisp/Smalltalk 스타일의 강력한 IDE였고, THINK Pascal 및 C(1986), Metrowerks Codewarrior(1993), Macintosh Allegro Common Lisp 등도 혁신적이었음. 80년대~90년 초의 8~40MHz M68000, 2~32MB RAM 환경에서 이렇게 세련된 IDE가 구현됐다는 게 놀라움

    • Emacs가 자체 문서화되어 있고 대화형이라는 의견에 대해, 실제로는 처음 접했을 때 문서 저장 방법조차 쉽게 알 수 없었음. vi보다는 낫겠지만, 초보자가 설명 없이 바로 쓰기엔 부족함

    • Magit이 정말 놀라움. 어떻게 이런 데이터 모델을 떠올렸는지 궁금함. git의 데이터 모델 그 이상을 구현한 느낌을 받음. git porcelain의 와해됨에 비해 Magit은 체계적인 구조를 가지고 있음

    • Turbo-Vision 스타일 IDE는 Alt, Tab, Return, Esc, 방향키 등 몇 가지만 알면 대부분의 기능을 파악할 수 있는데 비해, Emacs는 이런 통일적 조작성을 갖추지 못함

    • 25년 넘게 Emacs를 써와서 이제는 완전히 익숙해졌음

  • Turbo Pascal은 정말 놀라웠음. 처음에는 비표준 Pascal 구현이라 쓰기를 망설였으나, 경쟁 도구들이 너무 비싸고 덜 강력했음. 직접 써보고 완전히 매료됨. 빠르고 직관적인 IDE를 IBM PC에서 경험함. 모던 IDE 중에서는 Intellij가 25년 넘게 경쟁자들보다 훨씬 뛰어남. Microsoft 제품은 오래전부터 안 써서 VSCode 경험은 없음. Eclipse도 느리고 직관적이지 못하며 버그도 많았음. JetBrains는 사명을 지키며 훌륭함을 유지하는 드문 회사임. 다양한 언어, 표준, 툴을 끊임없이 지원하면서도 탁월한 품질을 유지하는 게 인상적임

    • Visual Studio는 여전히 WinForms와 그래픽 폼 디자이너를 지원하여, 90년대 후반 Delphi 경험과 매우 유사함. WinForms는 VCL을 대놓고 모방했기 때문임

    • 다만 리소스 사용량 문제가 큼. 클라우드 데스크탑에서 neovim을 쓸 수 없어 ideavim을 쓰게 되었으나, 코어 4개, 램 16GB임에도 여러 프로젝트만 열면 버벅임. 회사 보안 소프트웨어 영향도 있겠지만 VSCode는 그만큼 힘들지 않음

  • Turbo Pascal IDE가 시대를 앞서 있었고 CP/M(특히 Z-80)에서도 마법처럼 훌륭했음. 당대 그 어떤 것보다 뛰어났음

  • 글은 2023년 것이라 제목 연도를 32년 전으로 업데이트해야 맞을 듯함. 요즘 TUI에서 가장 아쉬운 점은 비동기 프레임워크가 키 입력을 종종 무시해버리는 것임. 2000년 이전 TUI는 시스템이 준비되지 않아도 키 입력을 대기시켰음. 반면, 최신 "웹 기반" TUI 프레임워크는 이벤트 리스너가 등록되기 전 키를 눌렀다간 아예 무시됨. 이외의 문제를 제외하면 TUI는 여전히 잘 되고 있음. Neovim은 LSP와 플러그인 덕분에 역대 최고 기능을 자랑함. 마우스 기반 TUI는 아니지만 생산성 면에서는 매우 뛰어남

    • DOS 시절 실제 터미널에서는 키 입력 버퍼가 있었고, 인터페이스에 익숙한 사람들은 여러 키를 미리 입력해 UI보다 앞서 나갔음. 입력이 버퍼에 쌓이고 화면에 순식간에 나타나 사라지는 경험이 있었음. 현대 프레임워크로도 이 구조는 구현 가능하지만, 신중하게 접근해야 함

    • 1984년에도 이런 경험이 있었으니 41년 전까지도 범위임. Visual Studio 1.0 또는 NetBeans처럼 GUI 제품이 나올 때까지 초창기 프로젝트들이 주류였음. vim(1991) 이전이지만, ncurses 대신 플로팅 윈도우를 원하는 느낌이었음

    • 이런 키 입력 무시 현상이 미칠 듯이 불편함. 옛날에는 빠른 단축키 조합으로 컴퓨터를 엄청난 속도로 사용할 수 있었으나, 이제는 마치 끈적이는 당밀 속을 걷는 기분임

    • 30년 전이 정확히 언제인지 감을 못 잡았는데, GUI Smalltalk 시스템 브라우저가 나오길 기대했으나 DOS TUI가 등장해서 아쉬웠음. 대신 Turbo C/Pascal, MS C 4.0 그리고 CodeView를 추억하며 즐거워졌음. 이 도구들은 43줄, 50줄 모드에서도 사용 가능했음

    • 특정 IDE에 과도하게 의존하면 자신의 경쟁력이나 코드에도 해가 된다고 생각함. 터미널 IDE를 말하자면, GNU/Linux 터미널이야말로 최고의 앱임. 타일링 윈도 매니저에서 여러 터미널을 띄워 사용하면 생산성이 극대화됨. 대형 화면에서의 현대적 스케일링은 개발자 인체공학적으로도 탁월함

  • 아직까지 직접 만든 텍스트 기반 에디터/IDE(https://github.com/alefore/edge)를 개발하며 사용 중임. 10년간의 개발 결론을 최근에 적었음(https://github.com/alefore/weblog/blob/master/edge/README.md)

  • DOS 전성기에는 문자를 바이트 배열로, 속성(배경, 전경색 등)도 별도의 배열로 관리함. 특정 위치에 'A'를 쓰고 싶으면 메모리 주소에 0x41만 쓰면 됨. wait state가 좀 있었지만 9600 baud 터미널에서 ANSI 명령으로 출력하는 것보다 훨씬 빨랐음. Emacs는 느린 시리얼 터미널이나 Sun 워크스테이션의 터미널 에뮬레이터에서 쓸 수 있었으나, 셸 기반 TUI가 사라진 배경임

    • 옛날 방식이 오히려 더 우월해 보임. 화면 크기를 변경할 때 어떻게 처리했는지 궁금함

  • 이 글이 텍스트 기반 IDE에 초점을 맞추고 있지만, Visual Basic이나 Delphi 같은 전통적 IDE에도 해당된다고 생각함. 초보자에게는 Python용 IDE가 정말 필요하다고 봄. 텍스트 기반이 아닌 Visual Basic 스타일로, 모든 게 통합되고, 발견이 쉬운 구조(중요!). GUI 빌더와 디버거도 내장되어 있으면 좋겠음. 코드 에디터는 구문 강조, 자동 완성, 그리고 쉬운 코드 탐색 기능이 있으면 충분할 것임. 예를 들면, 창에 버튼을 놓고 GUI 에디터에서 더블클릭하면 해당 버튼의 핸들러 코드로 바로 이동하는 방식임. 예전에 비슷한 아이디어로 사람들이 모여서 논의해봤는데 어떤 GUI 프레임워크를 쓸지(Pyside, Dear PyGui, 웹 기반 등) 이견이 커서 논의가 흐지부지됨. Free Pascal 얘기가 나왔으니, Delphi를 복제한 Lazarus(https://www.lazarus-ide.org/)도 언급해야 함. 매우 훌륭하고 활발하게 개발 중임. 다만 Object Pascal은 요즘 많이 쓰이지 않아 다소 낡은 느낌임

    • 초보자를 위한 Python용 통합 IDE로 Visual Basic 스타일, GUI 빌더, 내장 디버거가 필요하다는 데 전적으로 동의함. Boa Constructor(https://boa-constructor.sourceforge.net/)라는 파이썬 IDE가 2000년에 있었지만 대중화되지는 않았음

    • 나도 최근에 Windows 3.11에서 VB3로 토이 앱을 만드는 과정을 동영상으로 찍었고, 그 트윗이 “바이럴”을 일으킴. 결국 중요한 건 TUI가 아니라, 통합적 사용 경험임

    • 나에게는 Lazarus가 진정한 IDE의 기준임. Lazarus는 Lazarus로 만들어졌고, 저자가 직접 자신만의 제품을 열심히 사용하고 예제와 튜토리얼을 제공함. 아이들에게 프로그래밍을 가르치는 데도 탁월함. Microsoft Visual Studio 같이 태깅, 검색, 도움말, API 문서, 위젯 예제, 라이브러리 등이 통합되어 있음. 다른 IDE는 이런 통합성이 없으며, Xcode도 말은 IDE지만 Lazarus에 비하면 별로임. 너무 고집이 세서 6개월째 JS 대신 Go로 UI 프론트엔드 프레임워크를 직접 만드느라, 언젠가 IDE도 만들 수 있었으면 하는 바람임

  • Borland의 IDE는 진정한 기쁨이었음. 아직도 그 정도의 경험을 주는 현대 툴을 찾지 못함. 물론 향수가 좀 있겠지만, Free Pascal을 쓸 구실을 일부러 만들어서라도 그 인터페이스를 불러오는 게 즐거움. Pascal도 좋아함. Plan 9의 Sam과 Acme를 쓰기도 하지만, 이건 IDE가 아니라 에디터임. 나를 방해하지 않고 생각하게 해주는 도구를 선호함. 예전 TUIs에서 배워야 할 점이 많음. 예를 들어, File 메뉴에서 셸을 띄워서 무언가 실행한 후 다시 복귀하는 것도 충분히 용납되고 영웅적인 행동이었음. 그리고 키바인딩! 옛날 TUI들은 WordStar의 단축키 패턴을 많이 차용했는데, 너무 몸에 익숙해서 Emacs는 오븐 장갑 끼고 타이핑하는 느낌임. 오랫동안 joe(jstar 별칭)를 애용했음. 이제 Dr. DOS VM을 부팅하고, Advent of Code 도전도 해보고, 일부러 비효율적으로 추억파티를 할 시간임

    • DOS 시절의 “프로페셔널” 소프트웨어(Emacs 등)는 사용자가 그 소프트웨어 내에서 완전히 생활하도록 설계됐음. 기계와 일체화되어 오르간 연주자처럼 단축키를 자유자재로 쓸 수 있음. Fry’s Electronics 직원들이 TUI를 너무 빠르게 다뤄 화면이 뜨기도 전에 일을 마치고 인쇄물이 나오는 걸 지켜보던 기억이 있음

    • WordStar 바인딩이 무엇이고 어떤 점이 좋은지 궁금함. 이런 패턴의 역사와 각 방식의 장점을 연구하는 데 관심이 있음

    • 훌륭한 글에 공감함. 나 역시 개인 시간에 Turbo Pascal 스타일의 tui 코드 에디터를 개발 중임. 향후 make와 lldb도 내장할 계획임

    • Plan 9의 여러 면을 좋아하지만, Acme의 마우스 위주 UI에는 도저히 적응이 안 됨. 정교한 마우스 에임이 요구되는 UI는 오랜 시간 사용하거나 장애가 있을 경우에 매우 불편했을 것임

    • djgpp와 vi for dos 1991의 조합이 최고였음

  • Visix Vibe라는 Java IDE와 Delphi를 모두 사용했는데, 두 제품 모두 생산성을 엄청나게 올려줌. 고객에게 UI 개발, 논리 연계, 배포 준비까지 손쉽게 일정 예측이 가능했음. 특히 두 IDE의 통합성이 가장 그리움. 데이터베이스를 연결해 폼을 생성하면 바로 입력 및 검증 가능했고, 며칠이면 프로젝트 요구사항을 반영한 UI로 발전시킬 수 있었음. 요즘은 UI와 API, 백엔드가 제대로 연동될지 더 세심한 설계와 고민이 필요해졌음. AI가 UI 코드를 생성하는 수준이 아니라, 여전히 비주얼하게 코드를 직접 그리고 UI로 프로그램을 만드는 방식의 도구가 필요하다고 느낌. 누가 JUCE용으로 제대로 된 WYSIWYG 툴을 내놓으면 황금기가 다시 올 거라 생각함

    • 웃을 수도 있지만, 오늘날에는 html 폼을 이런 식으로 사용함. 단순하고 효과적임

  • DOS 시절에는 문자를 나타내는 바이트 배열과 색상 속성 배열을 가지고 있었고, 하드웨어가 직접 이를 그려줌. 메모리 주소에 값을 쓰면 바로 화면에 출력되는 형태여서, 느린 시리얼 터미널이나 ANSI 명령 기반보다 훨씬 빨랐음. Emacs를 Sun 워크스테이션의 터미널에서 쓸 땐 어디까지나 느릴 수밖에 없었기에 TUI가 사라진 것임

    • 당시 구조가 오히려 더 편했던 것 같음. 화면 크기를 유연하게 변경하는 방법이 궁금함
답변달기