모든 개발자는 온라인 포맷터에 비밀 정보를 붙여넣은 적이 적어도 한 번은 있을 것이다. API 키가 포함된 설정 파일. 확인하고 싶었던 JWT. 프로덕션 데이터에 대해 테스트해야 했던 정규식. 온라인 도구가 포맷하고 결과를 반환했고, 모두가 넘어갔다. 문제: 이제 그 비밀은 다른 사람의 데이터베이스에 있다.
최신 브라우저 런타임은 개발 도구를 위해 서버가 할 수 있는 거의 모든 것을 수행할 수 있다. JavaScript는 빠르다. Web Crypto API는 안정적이다. WASM 덕분에 무거운 파싱(YAML, JSON Schema, 정규식)도 로컬에서 실행된다. 결과: 클라이언트 사이드에서 모든 것을 처리하고, 데이터를 업로드하지 않으며, 백엔드 없이도 작동하는 차세대 개발 도구가 탄생했다.
이 글은 왜 이것이 중요한지, 작동하지 않는 경우, 그리고 차이점을 어떻게 확인하는지에 대한 것이다.
“클라이언트 사이드”가 실제로 의미하는 것
클라이언트 사이드 도구는 작업이 서버가 아닌 브라우저에서 발생하는 도구이다. HTML, CSS, JavaScript는 한 번 다운로드된다. 그 시점부터 모든 작업은 로컬이다. 서버는 더 이상 관여하지 않는다.
JSON 포맷터의 경우:
<textarea>에 JSON을 붙여넣는다.- 브라우저가 파싱하고, 포맷하고, 결과를 표시한다.
fetch호출이 이루어지지 않는다. API 엔드포인트도 없다. 로깅 서비스도 없다.
JWT 디코더의 경우:
- 세 개의 base64 세그먼트가 브라우저에서 디코딩된다.
- 서명은 로컬에서 실행되는 코드를 사용하여 검증되거나 검증되지 않는다.
- 비밀은 절대 기계를 떠나지 않는다.
이것은 어떤 브라우저에서든 직접 확인할 수 있다. DevTools → Network를 열고 작업을 수행하면 요청 로그를 확인할 수 있다. 진정한 클라이언트 사이드 도구는 입력을 담은 요청이 영 제로일 것이다.
왜 이것이 개발 도구에 더 나은지
프라이버시. 가장 명확한 이점이다. 도구 제공자는 받지 못한 것을 유출할 수 없다. 존재하지 않는 로그를 소환장으로 받을 수 없다. 데이터를 가지고 있지 않으니 팔 수도 없다.
지연 시간. 네트워크 왕복이 없다. 100KB JSON 파일을 포맷하는 데 몇 밀리초가 걸린다. 같은 파일을 서버에 업로드하고 포맷하고 다운로드하는 것은 좋은 날에 200ms가 걸릴 수 있다. 하루에 수십 번 사용하는 도구에서는 이것이 쌓인다.
비용. 도구 제공자는 컴퓨팅이나 스토리지 비용을 지불하지 않는다. 클라이언트 사이드 도구는 사실상 사용자당 한계 비용이 제로이다. 그래서 많은 도구들이 무료이다.
오프라인. 페이지가 로드되면 인터넷 연결 없이도 도구가 작동한다. 비행기, 와이파이가 불안정한 카페, 에어갭 환경에서 유용하다.
회복력. 제공자가 돈이 떨어지거나 암호화폐로 전환하기로 결정할 때 도구가 다운되지 않는다. URL에 접근할 수 있는 한 작동한다.
트레이드오프
클라이언트 사이드는 공짜가 아니다. 어떤 도구가 이 방식으로 갈 수 없는 이유가 있다.
파일 크기 제한. 브라우저 탭은 단일 프로세스이다. 매우 큰 파일(수백 메가바이트)은 탭을 크래시시킬 수 있다. 서버 사이드 도구는 스트리밍하고 임의 크기를 처리할 수 있다. JSON 포맷터의 경우 ~50MB를 넘으면 브라우저에서 둔해지기 시작한다. DevSpeedTools JSON 포맷터는 이를 잘 처리하지만, 진짜로 큰 파일의 경우 스트리밍 CLI 도구가 정답이다.
협업 없음. 도구가 사용자 간 상태를 공유해야 한다면 — Figma, Google Docs, 멀티플레이어 등 — 서버가 필요하다. 하지만 대부분의 개발 도구는 그렇지 않다. 포맷터, 검증기, 디코더, 생성자 — 이 모든 것은 단일 사용자 작업이다.
사용자 데이터에 대한 분석 없음. 제공자는 사람들이 도구로 무엇을 하는지 볼 수 없다. 그게 요점이다. 하지만 동시에 도구 작성자가 사용자가 보고한 문제를 디버깅하기 더 어려워진다. 좋은 클라이언트 사이드 도구는 명확한 오류 메시지와 실제 데이터를 공유하지 않고도 재현 가능한 예제를 공유할 수 있는 방법을 제공한다.
크로스 오리진 자산 제한. 도구가 서드파티 API에서 가져와야 하는 경우(예: JWT 검증자가 ID 제공자에서 JWKS를 가져와야 하는 경우), CORS 구성이 올바르게 되어야 한다. 순수 로컬 도구의 경우 이것은 문제가 되지 않는다.
초기 다운로드. WASM 모듈은 몇 메가바이트가 될 수 있다. 큰 WASM 기반 YAML 파서 또는 정규식 엔진은 첫 방문 시 로드하는 데 시간이 걸릴 수 있다. 이후 방문은 캐시된다. 스트리밍 컴파일(2024년 이후 Chrome과 Firefox에서 표준)은 전체 모듈이 다운로드되기 전에 첫 파싱이 일어나므로, 진짜 고민이었던 것이 사소한 문제로 줄어들었다. WebGPU는 사용 가능한 곳에서, 컴퓨팅 집약적인 개발 도구(이미지 처리, 암호화, 정규식 엔진)가 GPU에서 실행될 수 있게 해준다 — 적절한 워크로드에 대해 JavaScript보다 몇 배 빠르다.
도구가 진정한 클라이언트 사이드인지 확인하는 방법
대부분의 개발 도구 마케팅 문구에는 “클라이언트 사이드” 또는 “브라우저 내” 또는 “업로드 없음”이 있다. 대부분은 사실이다. 어떤 것은 아니다. 확인하는 방법은 다음과 같다.
- DevTools → Network를 열기. 도구를 사용하고, 요청을 확인한다. 도구가 데이터를 담아
POST를 API로 보내고 있다면 클라이언트 사이드가 아니다. 유일한 요청이 HTML, CSS, JS 번들에 대한 것이라면 괜찮다. - 소스 보기. 우클릭 → 페이지 소스 보기. JavaScript를 찾는다. 무거운 작업이
script태그에 있고 로컬에서 실행되면 클라이언트 사이드 도구이다. 서버 API를 감싼 얇은 래퍼에 모두 들어 있다면 아니다. - 네트워크 차단. DevTools → Network → “오프라인”. 도구를 새로고침한다(페이지가 캐시되어 있어야 한다). 도구를 사용한다. 여전히 작동하면 진정한 클라이언트 사이드 도구이다.
- 개인정보 처리방침 읽기. “수집하지 않습니다” 또는 “로깅하지 않습니다” 또는 “모든 처리가 브라우저에서 이루어집니다”라는 줄을 찾는다. 모호한 “개인정보를 소중히 여깁니다”는 노란 깃발이다.
좋은 클라이언트 사이드 개발 도구는 어떤 모습인가
최고의 클라이언트 사이드 도구는 몇 가지 특징을 공유한다:
- 클라이언트 사이드임을 알려준다. 입력 근처에 작은 배지(“로컬에서 처리됨” 또는 잠금 아이콘)로 자주 표시된다.
- 오프라인에서 작동한다. 로드된 후 네트워크 없이도 페이지가 계속 작동한다.
- 큰 데이터 붙여넣기를 우아하게 처리한다. 10MB 붙여넣기가 브라우저를 멈추게 해서는 안 된다.
- URL 프래그먼트를 통해 상태를 공유할 수 있는 방법을 제공한다. 예를 들어, 입력을
#data=...URL 프래그먼트로 인코딩하는 도구는 서버에 데이터를 보내지 않고도 예제를 공유할 수 있게 해준다. DevSpeedTools 공유 헬퍼가 정확히 이것을 한다. - 개인정보 메모가 있다. 도구가 입력으로 무엇을 하는지 설명하는 짧은 문장 — 보통 “아무것도 하지 않습니다”.
서버 사이드가 여전히 정답인 경우
모든 것이 클라이언트 사이드일 수 있는 것은 아니다:
- 데이터베이스가 필요한 도구. “내 IP는 뭔지” 도구는 실제로 IP를 봐야 한다.
- 유료 API를 호출해야 하는 도구. “이 기사를 요약해줘” 도구는 OpenAI를 호출한다. OpenAI 키는 브라우저에 포함될 수 없다.
- 외부 시스템에 쓰기 접근이 필요한 도구. Slack에 게시하거나 GitHub PR을 만드는 모든 것.
- 사용자 간 집계가 필요한 도구. “이 도메인이 차단 목록에 있는지” 도구는 공유 차단 목록이 필요하다.
구분 기준: 작업이 사용자 입력만의 함수라면 클라이언트 사이드여야 한다. 작업에 공유 상태가 필요하면 서버가 불가피하다.
지난 5년간 개발 도구 분야의 변화는 극적이었다. 백엔드가 필요했던 도구(포맷터, 검증기, 디코더, 생성자)가 이제 브라우저에서 완전히 실행된다. 패턴은 간단하다: 한 번 다운로드, 영원히 실행, 아무것도 전송하지 않는다. 민감한 설정이나 프로덕션 토큰을 다루는 개발자들에게, 이 변화는 안전성 측면에서 의미 있는 업그레이드이다.