파일이 서버로 전송되지 않는지 브라우저에서 직접 확인하는 방법

검증 전에 구분할 세 가지

운영 사이트에서 압축·다운로드 후 실제 요청을 확인했습니다

2026년 10월 14일 운영자가 직접 운영 사이트의 이미지 압축을 실행하고 다운로드한 뒤 Chrome 개발자 도구에서 요청 목록과 세 Payload를 확인했습니다. 아래는 그때 제공한 실제 캡처의 일부입니다. 설명용으로 그린 화면이나 로컬 서버에서 재현한 통계 요청이 아닙니다.

기록된 15개 항목 중 POST는 /api/tool-usage 세 개였고 모두 204 응답이었습니다. Payload의 이벤트는 start·success·download이며, 도구명·파일 개수·언어·유입 분류·익명 식별값 등이 보였습니다. success에는 완료 개수와 작업 시간, 오류 코드도 있습니다. 확인한 세 Payload에는 파일명이나 이미지 데이터가 없었습니다.

PNG와 WebP 항목은 blob:https://toolit.kr/로 시작하는 임시 주소를 읽은 GET이었습니다. 주소에 도메인이 보이더라도 이 blob: 주소는 서버 업로드 경로가 아닙니다. 나머지 열 항목은 McAfee 이름의 CSS·HTML·SVG·글꼴 등을 읽는 GET으로 보였지만, 각 요청의 전체 출처까지 확인한 것은 아니므로 툴릿 자체 요청으로 묶지 않았습니다.

Network의 Size는 요청 본문 크기라고 볼 수 없고, 하단의 3.7MB resources 역시 업로드된 이미지 용량을 뜻하지 않습니다. 완료 통계의 durationMs 약 2101은 이번 작업에서 기록된 구간이며 다른 기기의 속도 예측치가 아닙니다. 이 캡처만으로 선택한 원본의 파일명이나 압축 결과의 정확한 바이트 수까지 검증하지도 않았습니다.

이번에 캡처된 이미지 압축·다운로드 과정에서는 원본 이미지 업로드 요청이 관찰되지 않았습니다. 다만 기록을 시작하기 전 요청, 이후 통신, 다른 도구·브라우저·확장 프로그램의 동작, GA4·광고 전체를 검증한 것은 아닙니다. internalTest가 true였던 운영자 시험 한 번의 관찰로 범위를 한정합니다.

공개 캡처는 원본 픽셀을 그대로 잘랐습니다. 익명 ID와 불필요한 확장 프로그램 URL은 제외했고 요청이나 글자를 새로 그리지 않았습니다. JSON 자료는 캡처에서 읽은 내용을 정리한 전사본이지 HAR이나 원본 HTTP 로그가 아닙니다.

[
  {
    "tool": "image-compressor",
    "fileCount": 1,
    "internalTest": true,
    "language": "ko",
    "source": "direct",
    "event": "start"
  },
  {
    "tool": "image-compressor",
    "fileCount": 1,
    "internalTest": true,
    "language": "ko",
    "source": "direct",
    "event": "success",
    "completedCount": 1,
    "durationMs": 2101.10000143051,
    "errorCode": "",
    "failedPosition": 0
  },
  {
    "tool": "image-compressor",
    "fileCount": 1,
    "internalTest": true,
    "language": "ko",
    "source": "direct",
    "event": "download"
  }
]

현재 코드에서 확인한 파일 처리와 통계 요청은 다릅니다

2026년 10월 14일 현재 이미지 압축 코드를 다시 확인했습니다. 선택한 파일은 createImageBitmap으로 읽고, Canvas에서 그림을 저장한 뒤 결과 Blob에 임시 주소를 붙입니다. 이 파일 처리 경로와 사용 통계를 보내는 경로는 따로 구현돼 있습니다.

자체 도구 통계는 /api/tool-usage로 JSON 요청을 보낼 수 있습니다. 현재 호출 지점에서는 도구 종류, 작업 상태, 파일 개수, 처리 시간 등을 전달하며 원본 File이나 결과 Blob을 전달하지 않습니다. 로컬 개발 주소에서는 이 통계 요청을 건너뛰므로 localhost에서 요청이 없었다는 관찰만으로 운영 사이트도 요청이 없다고 결론 내리면 안 됩니다.

GA4는 Google 기본 태그를 사용하고 수집 설정은 Analytics 관리 화면에서 정합니다. 페이지 주소·제목·유입 정보나 설정한 자동 측정은 별도로 발생할 수 있습니다. 광고 요청도 파일 업로드와 같은 것이 아닙니다. 자체 도구 통계, GA4, 광고를 한 종류의 요청으로 묶어 해석하지 마세요.

아래 호출 흐름은 소스 확인 결과이며, 앞의 운영자 Network 캡처와 별도의 근거입니다. 8월 20일 관찰도 당시 기록으로만 남깁니다. 새 캡처나 코드 확인을 근거로 GA4·광고의 모든 통신까지 검증했다고 확대하지 않습니다.

decodeImageInput(selected File)
  → createImageBitmap(...)
  → Canvas.drawImage(...)
  → Canvas.toBlob(...)
  → URL.createObjectURL(output.blob)

beginToolUsage / finishToolUsage
  → metadata JSON (not File / result Blob)
  → /api/tool-usage
  → skipped on local-development addresses

• 소스 확인 위치: components/image-compressor.tsx, lib/image-input.ts, lib/tool-usage.ts
• 확인 기준: GA4 기본 태그를 적용한 d42f242 운영 코드. 소스 검토와 Network 캡처는 별도의 근거입니다.

브라우저 내부 처리란 무엇인가

웹페이지는 사용자가 고른 File 객체(브라우저가 선택한 파일을 다루는 방식)를 읽고, Canvas·WebAssembly·PDF 처리 라이브러리 같은 브라우저 기능으로 결과를 만들 수 있습니다. 쉽게 말해 파일을 서버에 맡기지 않고 현재 기기에서 직접 계산하는 방식입니다. 원본과 중간 데이터는 브라우저 메모리 안에 머물고, 완성된 결과 파일 데이터는 임시 주소로 내려받게 됩니다.

서버가 대신 계산하지 않기 때문에 업로드 대기 시간이 없고 파일 내용을 운영자가 보관하지 않는다는 장점이 있습니다. 반대로 대용량 파일은 사용자의 메모리와 CPU를 직접 사용하므로 탭이 느려지거나 종료될 수 있습니다.

Network 탭에 요청이 보이면 모두 업로드일까

아닙니다. 웹사이트는 화면을 그리는 CSS와 글꼴, 처리 엔진 파일, 익명 이용 통계, 활성화된 광고 같은 자원을 불러오기 위해 네트워크를 사용할 수 있습니다. 중요한 질문은 ‘통신이 있었는가’가 아니라 ‘선택한 파일의 내용이 요청에 포함됐는가’입니다.

일반적인 GET 요청은 사이트 자원을 내려받는 경우가 많습니다. 파일 업로드는 보통 POST나 PUT(브라우저에서 데이터를 보내는 요청 방식), multipart/form-data(파일 업로드에 자주 쓰이는 본문 형식), 원본 크기와 비슷한 전송량처럼 다른 흔적을 남깁니다. 다만 전송 방식은 서비스마다 다를 수 있어 요청에 담긴 내용과 전송 크기를 함께 확인해야 합니다.

• Method가 POST·PUT·PATCH인지 확인합니다.
• Transferred와 Resource Size가 선택한 파일 크기에 가깝거나 지나치게 큰지 봅니다.
• Payload에 파일명, multipart/form-data 또는 알아볼 수 있는 파일 내용이 있는지 확인합니다.
• 작업 시작 직후 새로 생긴 요청과 결과 다운로드 직전 요청을 따로 비교합니다.

오프라인 테스트가 알려주는 것과 알려주지 않는 것

페이지와 필요한 처리 엔진이 이미 로드된 뒤 네트워크를 Offline으로 바꾸어도 작업이 끝난다면, 핵심 계산이 원격 서버 응답에 의존하지 않는다는 강한 단서가 됩니다. 네트워크를 끊는 순간 새로고침하면 페이지 자원 자체를 다시 받을 수 없으므로, 반드시 페이지 로딩이 끝난 뒤 시험해야 합니다.

오프라인에서 성공했다고 해서 개인정보 보호 정책 전체가 자동으로 검증되는 것은 아닙니다. 사이트가 온라인일 때 보내는 익명 통계, 광고 요청, 오류 보고처럼 파일 내용과 무관한 통신은 별도로 존재할 수 있습니다. 따라서 오프라인 성공 여부와 온라인 Network 기록을 함께 보는 편이 정확합니다.

2026년 8월 20일 실제 브라우저 확인

Chrome에서 1,741,024바이트·1536×1024px PNG 파일을 선택해 500KB 이하 WEBP 목표 압축을 실행했습니다. 결과는 172.9KB·1536×1024px·품질 95%로 생성되어 원본 해상도를 유지하면서 목표 용량 아래로 내려갔습니다.

파일 선택부터 결과 생성까지 로컬 개발 서버의 요청 기록에는 최초 페이지 GET 외에 파일 업로드 요청이 나타나지 않았습니다. 구현 경로도 createImageBitmap으로 파일을 읽고 Canvas에서 다시 인코딩한 뒤 URL.createObjectURL로 결과 주소를 만드는 구조이며, 파일 데이터나 결과 Blob을 서버로 보내지 않습니다.

이 확인은 2026년 8월 20일 Chrome과 해당 이미지 압축 흐름을 기준으로 합니다. 운영 환경의 익명 이용 통계는 별도 요청으로 전송될 수 있지만 도구 이름, 결과 상태, 파일 개수와 구간화한 처리 시간만 대상으로 하며 파일명과 파일 내용은 포함하지 않습니다.

검증할 때 놓치기 쉬운 부분

파일명이 화면에 표시된다는 이유만으로 서버 전송이 일어난 것은 아닙니다. 브라우저는 사용자가 선택한 파일명과 크기를 페이지 안에서 바로 읽을 수 있습니다. 반대로 화면에 파일명이 보이지 않아도 요청 본문에 바이너리 데이터가 담길 수 있으므로 Network 기록을 보는 것이 중요합니다.

민감한 문서로 시험할 필요도 없습니다. 직접 만든 작은 테스트 이미지나 공개 샘플 파일을 사용하고, 알아보기 쉬운 임시 파일명을 붙이면 요청 본문에서 흔적을 찾기 더 쉽습니다.