지난 15년 동안 개발자가 쓰는 도구는 그 이전 40년을 합친 것보다 더 크게 변했습니다. 방향은 돌이켜보면 분명합니다 — 로컬 설치에서 브라우저로. 다만 표면적인 관찰보다 그 뒤에 깔린 이유가 훨씬 흥미롭습니다.
이 글은 개발자 도구가 어떻게 진화했는지, 각 전환을 무엇이 추진했는지, 그리고 지금의 브라우저 기반 시대가 이전 시대들이 놓쳤던 무엇을 제대로 잡았는지 정리합니다.
1세대: Unix 툴체인 (1970s–2000s)
최초의 개발자 툴박스는 Unix 커맨드라인 유틸리티 모음이었습니다: grep, sed, awk, sort, tr, diff 등 수십 개. 그 뒤의 Unix 철학은 명확합니다 — 한 가지를 잘 하는 프로그램을 만들고, 파이프로 서로 연결되도록 설계한다.
이건 정말로 강력했습니다. 1985년의 개발자는 CSV를 처리하고, 특정 필드를 뽑고, 정렬하고, 중복을 제거하고, 발생 횟수를 세는 작업을 단 한 줄의 파이프라인으로 끝낼 수 있었습니다. 프로그램을 한 줄도 쓰지 않고요. 도구들이 조립되고, 셸이 접착제 역할을 했습니다.
커맨드라인 툴체인의 진짜 강점:
재현성. Unix 명령 파이프라인은 결정적입니다. 같은 명령을 두 번 실행하면 같은 결과가 나옵니다. 스크립트로 묶으면 그대로 자동화 프로세스가 됩니다.
조립 가능성. 작고 목적이 명확하며 텍스트 스트림으로 통신하는 도구들은 제작자도 예상하지 못한 방식으로 결합됩니다. curl을 python3 -m json.tool로 보내고 다시 grep으로 보내면 — 셋은 서로의 존재를 모르지만 함께 동작합니다.
성능. 로컬 도구가 로컬 파일을 처리하면 빠릅니다. 네트워크 왕복도, 서버 큐도, 업로드 오버헤드도 없습니다.
하지만 커맨드라인 시대에도 실제 문제들이 있었습니다.
발견성이 형편없었다. 도구가 존재한다는 걸 알아야 쓸 수 있습니다. man 페이지는 포괄적이지만 불친절합니다. 새 작업을 처음 만난 개발자가 적절한 도구를 찾으려면 입소문, 책, 운에 의존해야 했습니다.
학습 곡선이 가팔랐다. awk는 완전한 프로그래밍 언어이고, sed의 주소 지정 문법은 난해하며, grep 정규식은 전문가도 걸려 넘어지는 디테일이 있습니다. 잘 쓰려면 상당한 투자가 필요합니다.
이식성이 들쑥날쑥. BSD 유틸리티와 GNU 유틸리티는 플래그가 다릅니다. macOS는 BSD 버전을, Linux는 GNU 버전을 씁니다. Linux에서 잘 돌던 셸 스크립트가 macOS에서 깨지는 일은 흔하고, 이 마찰은 지금도 사라지지 않았습니다.
2세대: 로컬 GUI 애플리케이션 (1990s–2000s)
PC가 보편화되면서 또 다른 범주가 등장했습니다: 특정 작업용 GUI 애플리케이션. 데이터베이스 관리 도구, XML 에디터, diff 뷰어, 헥스 에디터, 코드 생성기 등.
GUI 시대는 CLI 시대가 풀지 못한 문제들을 풀었습니다.
시각화. 데이터를 접을 수 있는 트리로 보는 것은 평탄한 텍스트 스트림으로 보는 것과 차원이 다릅니다. 규모가 커진 XML과 JSON은 선형 텍스트로는 이해가 거의 불가능하지만, 트리 뷰어는 구조를 한눈에 보여줍니다.
발견성. 애플리케이션에는 메뉴가 있고, 메뉴는 탐색 가능합니다. 존재하는지 몰랐던 기능도 둘러보다가 발견할 수 있습니다. 이는 man 페이지 대비 실질적인 UX 개선입니다.
접근성. 모든 개발자가 터미널에 익숙한 건 아닙니다. GUI 도구는 CLI 비네이티브 워크플로의 진입 장벽을 낮췄습니다.
하지만 로컬 GUI 시대에도 자체 문제가 있었습니다.
설치와 유지보수. 도구마다 따로 설치해야 하고, 업데이트는 수동이며, 라이선스도 관리해야 합니다. 쓰는 도구가 많을수록 최신 상태로 유지하는 비용이 커집니다.
크로스 플랫폼 비일관성. Windows 개발자와 macOS 개발자가 같은 작업에 완전히 다른 도구, 완전히 다른 인터페이스를 쓰기도 합니다. 지식이 플랫폼 간에 이전되지 않습니다.
오프라인 우선이지만 고립. 이 도구들은 오프라인에서 동작하지만 섬과 같았습니다. 설정, 스키마, 템플릿을 동료와 공유하려면 파일 전송 외에는 방법이 없었고, “팀에 공유한다”는 개념 자체가 없었습니다.
3세대: 웹 기반 SaaS 도구 (2010s)
광대역이 보편화되고 브라우저 기술이 성숙하면서 새 범주가 등장했습니다: 웹 기반 SaaS 개발자 도구. URL을 열고, 무언가를 하고, 결과를 받습니다. 설치할 게 없습니다.
이 시대는 지금도 진행 중입니다. 거의 모든 범주에 적어도 하나의 잘 알려진 SaaS 도구가 있습니다:
- 코드 포매팅과 린팅
- JSON/XML/YAML 에디터와 검증기
- 커뮤니티 패턴 공유가 있는 정규식 테스터
- 클라우드 동기화가 있는 API 클라이언트
- 웹 인터페이스를 가진 데이터베이스 브라우저
SaaS 시대는 배포와 유지보수 문제를 깔끔하게 풀었습니다. 서버 호스팅 도구는 항상 최신이고, 브라우저가 있는 어떤 기기에서든 쓸 수 있으며, 사용자 측 설치는 0입니다.
협업이 가능해졌다. 공유 워크스페이스, 공유 가능한 링크, 팀 계정 — 로컬 도구로는 불가능하거나 어색했던 것들이 핵심 기능이 되었습니다.
모바일 접근. 태블릿이나 전화기만 가진 개발자도 SaaS 도구를 쓸 수 있습니다. 실무에선 드물지만 가끔 결정적입니다.
하지만 SaaS 시대는 이전 시대에 없던 문제를 하나 도입했습니다: 프라이버시와 데이터 소유.
API 응답을 서버 사이드 처리 도구에 붙여넣으면, 그 데이터는 본인 머신을 떠납니다. 네트워크로 전송되고, 본인이 통제하지 않는 서버에서 처리되며, 로그에 남을 수도 있고, 서비스 개선에 쓰일 수도 있고, 데이터 유출 사고에 휘말릴 수도 있습니다.
취미 프로젝트나 공개 데이터라면 상관없습니다. 운영 시스템이라면 큰 문제입니다. 포매팅하는 그 JSON에 실제 사용자 레코드가 들어 있을 수 있고, 디코딩하는 그 JWT가 실제 사용자를 인증할 수 있고, diff하는 그 데이터베이스 export에 PII가 들어 있을 수 있습니다.
SaaS 모델은 “민감한 데이터를 처리하기 위해 제3자 서비스로 보내는” 습관을 일상화했습니다. 많은 개발자가 생각 없이 그렇게 합니다. 보안에 신경 쓰는 조직은 금지하지만, 그 금지는 자주 무시됩니다 — 도구가 편하고 대안이 명확하지 않기 때문입니다.
SaaS 시대는 또 하나, 서비스 가용성 의존성을 들여왔습니다. 도구의 서버가 다운되면 일을 못 합니다. 회사가 방향을 틀거나 인수되거나 폐업하면 워크플로가 깨집니다. 무료 티어가 사라지면 짧은 시간 안에 대안을 찾아야 합니다.
4세대: 클라이언트 사이드 브라우저 도구 (2015–현재)
현재 세대는 다른 아키텍처 선택으로 SaaS 모델의 주요 약점을 해결합니다: 계산을 브라우저 자체로 옮긴다.
현대 브라우저의 JavaScript는 빠릅니다. WebAssembly는 더 빠릅니다. 현대 CPU에서 V8의 JIT 컴파일된 JavaScript가 제공하는 처리 능력은 대부분의 개발자 도구 워크로드에 충분합니다. JSON 포매팅, 해시 계산, 스키마 검증, JWT 디코딩, 텍스트에 정규식 실행 — 이 모든 것이 브라우저 JavaScript에서 마이크로초~밀리초 단위로 동작합니다.
도구가 클라이언트 사이드에서 데이터를 처리할 때:
데이터가 머신을 떠나지 않는다. 데이터를 붙여넣고, 브라우저 탭 안의 JavaScript가 처리하고, 결과가 나타납니다. 데이터는 어디에도 가지 않습니다. 운영 데이터, 민감한 자격 증명, 실제 사용자 레코드에도 안전하게 쓸 수 있습니다.
유지하거나 비용을 낼 서버가 없다. 클라이언트 사이드 도구는 CDN에서 서비스되는 정적 파일입니다. 글로벌하게, 안정적으로, 저렴하게 쓸 수 있습니다. 요청당 컴퓨팅 비용도, 스케일링 문제도, 유지할 데이터베이스도 없습니다.
오프라인에서 사용 가능. 페이지가 로드된 뒤에는 클라이언트 사이드 도구가 네트워크 없이 동작합니다. URL을 저장해두면 Wi-Fi 없는 비행기 안에서도 동작합니다.
계정 불필요. 클라이언트 사이드 도구는 추적, 청구, 인증을 할 필요가 없습니다. 그냥 웹 페이지입니다. 열어서 쓰면 됩니다.
ZeroTool 같은 도구가 이 모델 위에 만들어졌습니다. JSON 포매터, 해시 생성기, JWT 디코더, 정규식 테스터와 나머지 도구 모음 모두가 브라우저 안에서 완전히 동작합니다. 어떤 서버도 입력을 처리하지 않습니다. JavaScript는 공개되어 있고, 감사 가능하며, 재현 가능합니다.
브라우저 기반 시대가 제대로 잡은 것
클라이언트 사이드 브라우저 도구로의 수렴은 우연이 아닙니다. 이전 시대들이 풀지 못한 진짜 긴장을 해소하기 때문입니다.
CLI 시대는 강력했지만 접근하기 어려웠습니다. GUI 시대는 접근하기 쉬웠지만 파편화되어 있었고 협업이 안 됐습니다. SaaS 시대는 접근하기 쉽고 어디서든 쓸 수 있었지만 프라이버시 위험과 외부 의존성을 만들었습니다.
클라이언트 사이드 브라우저 도구는 접근하기 쉽고(설치 불필요), 어디서든 쓸 수 있고(URL 하나), 프라이빗하고(서버 사이드 처리 없음), 신뢰할 수 있습니다(백엔드 의존성 없음). Unix 도구와는 다른 방식으로 조립도 가능합니다 — 파이프가 아니라 URL 기반 워크플로와 브라우저 세션을 통해서요.
여전히 클라이언트 사이드 브라우저 도구가 못하는 것들이 있습니다: 서버 사이드 계산이 필요한 작업(크롤링, 외부 HTTP 요청, 프라이빗 DB 접근), 여러 사용자의 세션을 가로지르는 영구 상태가 필요한 작업(공동 편집), 브라우저 샌드박스가 제공할 수 있는 것보다 더 많은 컴퓨팅이 필요한 작업(대규모 데이터 변환).
이런 경우에는 SaaS 모델이나 로컬 도구가 여전히 적합합니다. 다만 개발자의 일상적인 마이크로 작업 — JSON 포매팅, JWT 검사, 정규식 테스트, 해시 생성, 타임스탬프 변환 — 에는 브라우저가 적합한 플랫폼입니다.
우리가 서 있는 지점
도구 환경은 여전히 움직이고 있습니다. WebAssembly 덕분에 JavaScript만으로는 현실적이지 않던 계산도 클라이언트 사이드에서 돌릴 수 있게 되어, 복잡한 네이티브 도구를 서버 없이 브라우저로 옮길 수 있습니다. PWA는 브라우저 도구를 설치 가능하게 만들고, 오프라인 접근과 OS 통합을 제공합니다.
CLI는 사라지지 않습니다. 자동화, 스크립트, CI 파이프라인은 항상 헤드리스에서 스크립트 가능한 도구를 필요로 합니다. 터미널은 프로그램적 워크플로에 여전히 적합한 환경입니다.
하지만 인터랙티브하고 즉흥적인 개발자 작업 — 디버깅 세션 사이사이에 끼는 작업, 사람의 주의와 판단이 필요한 작업, 하루에 수십 번 일어나며 빠르고 마찰 없이 처리되어야 하는 작업 — 에는 브라우저 기반 클라이언트 사이드 도구가 성숙하고 적절한 형태입니다.
이걸 일찍 깨달은 개발자들은 워크플로를 브라우저 도구 중심으로 짜고, 로컬 설치들의 동물원을 더 이상 유지하지 않습니다. 결과는 단지 편리함만이 아닙니다. 도구와의 관계 자체가 달라집니다 — 의식이 줄고, 유지보수 부담이 낮아지고, 진짜 일에 쓸 시간이 늘어납니다.
브라우저는 어차피 여기까지 올 것이었습니다. 다만 15년이 걸렸을 뿐입니다.