← 전체 글 보기

웹 도구가 정말 파일을 업로드하지 않는지 검증하는 법 (DevTools 실습)

2026-05-30

짧은 답: 브라우저 DevTools를 열고 Network(네트워크) 탭으로 가서 비운 다음, 도구로 파일을 처리해 보세요. 파일이 브라우저를 떠나지 않으면 도구의 코드가 다운로드되는 건 보이지만, 당신 파일의 바이트가 업로드되는 건 보이지 않습니다. 아래는 60초 버전과, 보이는 것을 읽는 법입니다.

"파일을 저장하지 않습니다"로는 부족한 이유

대부분의 "무료" 온라인 파일 도구는 파일을 서버에 업로드하고, 거기서 처리한 뒤, 결과를 돌려줍니다. 개인정보 처리방침에서 나중에 삭제한다고 약속할 수도 있지만, 그건 당신이 확인할 수 없는 약속입니다. "파일을 저장하지 않습니다"라고 해도, 당신의 파일은 전송되어 암호가 풀린 채 남의 기계에 놓였던 것입니다. 검증할 수 없는 보장은 프라이버시가 아니라 마케팅입니다.

좋은 소식: 요즘 브라우저는 진짜 작업을 스스로 합니다 — 이미지 처리, PDF 렌더링, WebAssembly를 통한 동영상 인코딩, 심지어 WebGPU를 통한 신경망까지. 도구가 로컬로 돌면, 당신의 파일은 브라우저 탭의 메모리로 읽혀 처리된 뒤 다운로드로 돌려받습니다. 네트워크에는 전혀 닿지 않습니다. 그리고 약속과 달리, 이건 1분 안에 직접 확인할 수 있습니다.

60초 점검 (Network 탭)

  1. 새 탭에서 도구를 엽니다 (예: 이미지 압축 또는 이미지에서 텍스트).
  2. DevTools를 엽니다 — F12를 누르거나 우클릭 → 검사. (Mac은 Cmd+Opt+I, Windows/Linux는 Ctrl+Shift+I.)
  3. Network(네트워크) 탭을 클릭합니다.
  4. 지우기(🚫) 아이콘으로 기존 요청을 비우고, **Preserve log(로그 유지)**를 체크해 아무것도 사라지지 않게 합니다.
  5. 이제 파일을 도구에 끌어다 놓고 실행합니다.
  6. 요청 목록을 보고 **Size(크기)**로 정렬합니다.

찾는 것: 당신의 파일을 업로드하는 요청은 POST(또는 PUT)이고 요청 본문 크기가 파일과 거의 같습니다. 5 MB 사진을 올리면 약 5 MB의 페이로드가 밖으로 나가는 게 보입니다. 큰 전송이 도구 자체의 코드와 .wasm 파일이 안으로 들어오는 것뿐이고, 캐시되어 첫 실행 뒤 멈춘다면, 당신의 파일은 그대로 있는 겁니다.

업로드와 정상 트래픽을 구분하는 법

모든 요청이 위험 신호는 아닙니다. 100% 로컬 도구에서도 이건 정상입니다:

  • 코드와 자원 로딩 — JavaScript 번들, .wasm 바이너리(FFmpeg, Tesseract 등), 폰트, 페이지 자체. 이건 다운로드입니다: 응답에 크기가 있고, 요청 본문은 비어 있으며, 첫 방문 후 캐시됩니다.
  • 분석과 광고 — Google Analytics나 AdSense로 가는 작은 핑. 아주 작고, 당신의 파일은 절대 담지 않습니다(담을 수 없습니다 — 당신의 파일은 그들이 닿을 수 있는 변수에 없으니까요).

이것이야말로 위험 신호입니다:

  • 요청 페이로드가 파일과 거의 같은 크기인 POST/PUT. 그 요청의 Payload/Request 탭을 열면 바이트 자체, 또는 파일명을 담은 multipart 폼이 그대로 보입니다.
  • "처리"를 누르는 순간 예상치 못한 저장 도메인(S3 버킷, 어떤 CDN)으로의 업로드.

경험칙: 들어오는 다운로드 있음, 나가는 큰 업로드 없음 = 로컬 처리.

핵폭탄 옵션: 선을 뽑아라

요청 로그를 읽기 싫다면, 누구나 할 수 있는 더 거친 테스트가 있습니다:

  1. 먼저 도구 페이지를 한 번 로드해 코드를 받게 합니다.
  2. 비행기 모드 켜기 / Wi-Fi 끄기 — 또는 DevTools에서 Network 스로틀링을 **Offline(오프라인)**으로 설정합니다.
  3. 도구를 실행합니다.

오프라인에서도 작동하면, 물리적으로 파일을 업로드할 수 없습니다. 업로드할 연결이 없으니까요. (일부 도구는 필요 시 큰 엔진 파일을 받습니다 — 어떤 동영상 도구는 처음에 FFmpeg를 받습니다. 그 한 번의 다운로드를 끝낸 뒤 오프라인으로 처리하세요.)

그럼 왜 이렇게 많은 도구가 업로드할까

솔직히, 서버 쪽이 수익화하기 쉬워서입니다. 업로드하면 회사는 기능을 구독 뒤에 숨기고, 사용을 기록하고, 최악의 경우 당신의 파일을 모델 학습에 쓸 수 있습니다. 로컬 처리는 더 많은 엔지니어링을 요구합니다 — C 라이브러리를 WebAssembly로 컴파일하고, 브라우저 메모리 예산에 맞추고, 그 지렛대를 포기하는 것. 그래도 가치 있는 이유는 하나 — 당신의 파일은 어디에도 가지 않고, 나를 믿을 필요도 없습니다. Network 탭을 보면 되니까요.

그게 ToolKoala의 전체 아이디어입니다: 모든 도구가 당신의 브라우저에서 돕니다. 아무거나 DevTools를 열어 직접 확인하세요.

자주 묻는 질문

"업로드 없음"이 오프라인 작동을 뜻하나요? 첫 로드 이후엔 대개 그렇습니다. 코드가 캐시되어 대부분의 도구는 연결 없이도 돕니다. 필요 시 큰 엔진을 받는 일부(어떤 동영상 도구)는 그 한 번의 다운로드가 먼저 필요합니다.

도구가 WebSocket이나 백그라운드로 몰래 내 파일을 올릴 수 있나요? Network 탭은 WebSocket과 백그라운드 fetch/XHR 트래픽도 페이로드까지 보여줍니다. 당신 파일의 바이트가 나가면 거기 나타납니다. 그게 핵심입니다 — 업로드는 Network 탭에서 숨을 곳이 없습니다.

분석이나 광고는 프라이버시 문제인가요? 그들이 보는 건 표준 방문 신호 — 대략적 위치, 기기 유형 — 이지 당신의 파일이 아닙니다. 당신의 파일은 광고 스크립트가 닿는 변수에 들어가지 않고, 차단해도 도구는 작동합니다.

이건 ToolKoala 전용인가요? 아닙니다. 이 점검은 어떤 웹 도구에도 쓸 수 있습니다. 민감한 파일을 어떤 "무료 온라인 변환기"에 맡기기 전에 매번 이렇게 확인하세요.

— Milo 🐨