나는 백엔드 없이 122개의 웹 툴을 배포했다

It looks like only the source citation was provided, but the article text itself is missing. Could you please share the content you’d like translated? Once I have the full text, I’ll translate it into Korean while preserving the original formatting, markdown, and code blocks.

서버 기반 변환기의 문제점

업로드하는 모든 파일은 SaaS 변환기에 대해:

• 네트워크를 통해 전송됨 (느림)
• 누군가의 서버에서 처리됨 (비용이 많이 듦)
• 잠시라도 저장됨 (프라이버시 위험)
• 다시 반환됨 (다시 느림)

일반적인 도구의 ~80 % 에서는 이러한 단계가 전혀 필요하지 않습니다. 2026년의 브라우저는 이를 수행할 수 있습니다. “어느 정도”가 아니라, “제한이 있는” 것이 아니라—실제로 서버 왕복보다 더 빠르게 수행할 수 있습니다.

사고 방식의 전환

브라우저를 얇은 클라이언트로 생각하는 것을 멈추세요.

백엔드를 대체한 패턴

// Pseudocode for the pattern that replaced our backend
const file = await input.files[0].arrayBuffer();
const result = await wasmModule.compress(file, { quality: 0.7 });
download(result, 'compressed.pdf');

그게 전부입니다. 업로드도 없고, 대기열도 없으며, “파일을 처리 중입니다.”라는 메시지도 없습니다.

50 MB PDF 파일은 중간 사양 노트북에서 ~2 초 만에 압축되며, 서버에 업로드하는 시간보다 빠릅니다.

같은 패턴은 다음에도 적용됩니다:

• 이미지 압축
• 비디오 트리밍 (FFmpeg.wasm 사용)
• 오디오 변환
• ZIP 생성
• EPUB 생성

압축이나 형식 변환을 위해 여전히 파일을 서버로 라우팅하고 있다면, 더 나쁜 사용자 경험을 제공하면서 실제 비용을 지불하고 있는 것입니다.

WASM이 필요 없을 때

대부분의 “도구”는 WASM이 필요하지 않습니다. 대부분은 프레임워크조차 필요하지 않죠. JSON 포매터, 정규식 테스트기, 문자 카운터, 텍스트‑케이스 변환기 등은 50–200줄 정도의 순수 JavaScript로 충분합니다. 도구 자체가 가치이며, 프레임워크는 부가적인 부담일 뿐입니다.

• Vue를 시도해봤습니다.
• 순수 HTML로도 해봤습니다.
• SEO를 위해 Next.js를 선택했지만(아래에서 자세히 다룹니다), 각 도구의 실제 로직은 단일 함수입니다. 과도하게 설계하지 마세요.

워커 규칙: UI 반응성 유지

전체 사이트에서 가장 큰 UX 향상은 한 가지 규칙에서 나왔습니다: 계산이 200 ms 이상 걸리면 워커에서 실행합니다.

const worker = new Worker(new URL('./hash.worker.js', import.meta.url));
worker.postMessage({ file, algorithm: 'sha256' });
worker.onmessage = (e) => updateUI(e.data);

• 메인 스레드에서 1 GB 파일을 해싱 → 탭이 멈춤 → 사용자가 탭을 닫음.
• 워커에서 동일한 파일을 진행 상황 이벤트와 함께 해싱 → 부드러운 경험, 사용자가 도구를 신뢰함.

같은 코드, 10배의 인지된 품질.

SEO 교훈

“이것은 잘못되었습니다. 나는 그것들을 배포했고, 그들은 색인되었습니다 (결국 264페이지), 그리고 구글은 전체 사이트를 평균 위치 72에서 몇 달 동안 머물게 했습니다. 색인 ≠ 순위.”

해결책은 더 많은 도구가 아니라 더 적고, 더 잘 연결된, 더 좋은 콘텐츠를 가진 도구 페이지였습니다. 각 도구는 이제 다음을 가지고 있습니다:

1. 실제 키워드가 포함된 고유한 H1
2. 인‑브라우저 처리 방식을 설명하는 “How it works” 섹션
3. 검색 쿼리의 일반적인 변형을 대상으로 하는 FAQ
4. 관련 도구에 대한 3–5개의 내부 링크

평균 위치가 드디어 상승하고 있습니다. 교훈: 도구 사이트의 SEO는 도구 수가 아니라 콘텐츠 + 권위입니다.

개발 단축키

• 나는 맞춤형 WASM PDF 라이브러리를 만들려고 시도했다. 두 주가 걸렸다. pdf-lib 은 이미 존재했고 더 좋았다.
• 나는 순수 WebCodecs API 로 비디오 트리머를 만들었다. FFmpeg.wasm 은 코드의 1/10 정도로 같은 일을 해냈다.

브라우저 도구의 경우, 2026년의 생태계는 이미 성숙했다. 이를 활용하라. “처음부터 직접 만들었다”는 배지는 도구를 한 달 일찍 배포하는 것보다 가치가 낮다.

모바일‑First 디자인

“무료‑툴 사이트 트래픽의 50 %가 모바일입니다. 초기 툴 중 절반은 1280 px 화면을 전제로 만들었습니다.”

수정은 반응형 CSS가 아니라 워크플로우 재고였습니다. 모바일에서는 “파일을 끌어다 놓기” 인터페이스가 쓸모 없습니다. 사람들은 탭하고, 끌지는 않습니다. 파일 선택기를 여는 하나의 버튼을 원합니다.

유틸리티를 만들고 있다면, 먼저 모바일 흐름을 설계하세요.

아키텍처 개요

┌─────────────────────────────┐
│  Static Next.js page (SSG)  │ ← SEO, fast first paint
├─────────────────────────────┤
│  Lazy‑loaded tool component │ ← only loads when user interacts
├─────────────────────────────┤
│  Web Worker (when needed)   │ ← keeps UI responsive
├─────────────────────────────┤
│  WASM module (when needed)  │ ← for "real" processing
└─────────────────────────────┘

• API 없음.
• 데이터베이스 없음.
• 큐 없음.
• 인증 없음.
• Stripe 없음.

전체 사이트는 CDN에서 제공되는 정적 파일입니다. 인프라 비용은 도메인과 Cloudflare 계정뿐입니다.

이것은 모든 제품에 적합한 것은 아닙니다. 현재 개발자들이 사용하는 것보다 훨씬 더 많은 제품에 적합합니다.

브라우저 내 접근 방식이 무너지면

다른 모든 경우: 브라우저 우선 버전을 시도해 보세요. 얼마나 자주 작동하는지 놀라실 겁니다.

요약

• 먼저 지루한 도구를 선택하세요. A JSON‑to‑CSV 변환기는 이미 검색 수요가 존재하기 때문에 새로운 아이디어보다 더 빠르게 순위에 오릅니다.
• WASM은 두렵지 않습니다. 라이브러리를 선택하고, README를 복사해서 배포하세요.
• 자신만의 UI 라이브러리를 만들지 마세요. 기존에 있는 것을 사용하고, 절약한 시간을 실제 도구에 투자하세요.
• 정적 + 클라이언트‑사이드는 경쟁자가 서버 비용을 지불할 때 경쟁 우위가 됩니다.
• 프라이버시는 부가 기능이 아닙니다. 첫날부터 내리는 아키텍처 결정입니다.
• 웹 플랫폼은 현재 실제로 충분히 강력합니다. “이걸 위해 백엔드가 필요하다”는 생각은 2015년의 근육 기억일 뿐이며, 재고할 가치가 있습니다.

122개의 도구 중 하나를 사용해 보고 싶으신가요?

모두 여기에 있으며, 파일을 업로드하지 않고 모두 브라우저에서 완전히 실행됩니다.

They are free, and the source patterns above are the same ones running in production.  
Ask me anything in the comments.