문제 해결형

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

개발자 도구의 네트워크 기록을 이용해 파일 도구가 선택한 파일을 서버로 업로드하는지 직접 확인하는 절차와 결과 해석법을 설명합니다.

‘브라우저에서 처리됩니다’라는 문구만으로는 파일이 정말 서버에 전송되지 않는지 알기 어렵습니다. 그러나 Chrome이나 Edge에 기본으로 들어 있는 개발자 도구를 이용하면 파일을 선택한 뒤 어떤 네트워크 요청이 발생했는지 직접 확인할 수 있습니다.

이 글은 특정 도구의 사용법이 아니라 로컬 파일 처리 주장을 검증하는 방법을 다룹니다. 웹사이트의 일반 통신과 파일 업로드를 구분하고, 확인 결과를 과장 없이 해석하는 것이 목적입니다.

검증 전에 구분할 세 가지

네트워크 요청과 파일 처리는 다릅니다

페이지 자원이나 통계 요청이 보여도 선택한 파일이 전송됐다는 뜻은 아닙니다.

파일을 보내는 요청인지 확인해야 합니다

선택한 파일과 크기가 비슷한 전송이나 파일명·파일 데이터가 포함된 요청이 있는지 봅니다.

한 번의 확인은 범위를 가집니다

확인한 브라우저·도구·작업에 대한 관찰이며 모든 미래 동작을 보증하지는 않습니다.

직접 확인하는 순서

  1. 1

    Chrome 또는 Edge에서 확인할 파일 도구 페이지를 열고 F12를 눌러 개발자 도구를 엽니다.

  2. 2

    Network 탭에서 기록 지우기 버튼을 누른 뒤 Preserve log는 끄고, 가능하면 Size와 Method 열이 보이게 합니다.

  3. 3

    도구에 파일을 선택하고 변환·압축·병합 같은 실제 작업을 끝낸 다음 결과를 내려받습니다.

  4. 4

    작업 중 새로 생긴 요청을 Method, Type, Size 순으로 살펴봅니다. 특히 POST·PUT·PATCH 요청과 크기가 큰 요청을 우선 확인합니다.

  5. 5

    의심스러운 요청을 열어 Payload 또는 Request 탭에서 multipart/form-data, 파일명, 파일 내용 일부가 들어 있는지 확인합니다.

  6. 6

    더 확실히 보려면 개발자 도구의 네트워크 속도를 Offline으로 바꾼 뒤, 이미 로드된 페이지에서 같은 작업이 가능한지 다시 확인합니다.

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

웹페이지는 사용자가 고른 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 기록을 보는 것이 중요합니다.

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

검증 가능한 설명이 더 중요합니다

브라우저 기반 파일 도구의 개인정보 보호 주장은 단순한 문구가 아니라 사용자가 확인할 수 있는 동작이어야 합니다. Network 기록에서 파일 업로드 요청이 없는지 살피고, 페이지 로딩 후 오프라인에서도 핵심 작업이 가능한지 확인하면 서버 처리 여부를 상당 부분 판단할 수 있습니다.

다만 ‘파일이 업로드되지 않는다’와 ‘사이트가 어떤 외부 통신도 하지 않는다’는 서로 다른 주장입니다. 파일 처리, 통계, 광고, 외부 자원을 나누어 설명하는 서비스가 더 투명한 서비스입니다.