"convert PNG to JPG"를 검색하면 무료 변환기가 한 면을 가득 채우는 결과가 뜹니다 — 대부분 광고 기반이고, 대부분 같은 비즈니스 모델로 동작합니다: 파일 업로드, 서버 측 변환 실행, 결과 반환. 흐름이 너무 매끄러워서 업로드와 다운로드 사이에 무엇이 일어나는지 대부분의 사람은 생각하지 않습니다. 이 글은 실제로 무엇이 일어나는지, 개인정보 처리방침이 무엇을 말하고 무엇을 말하지 않는지, 그리고 변환기가 당신의 파일을 아예 보지 않는 경우를 가려내는 방법을 다룹니다.

"서버에 업로드"가 실제로 의미하는 것

일반적인 변환기에서 업로드를 누르면, 브라우저는 파일을 제공자의 서버로 POST합니다. 파일은 임시 디렉토리에 떨어지고, 변환이 실행되고, 결과 링크가 반환됩니다. UI에는 드러나지 않지만 그 흐름에서 세 가지 일이 일어납니다:

파일은 적어도 변환이 끝날 때까지 남아 있습니다. 재시도나 다운로드를 위해 더 오래 남는 경우가 많습니다.
로그에 남을 수 있습니다. 서버 액세스 로그, 에러 로그, CDN 로그, 분석 로그 모두 파일명, IP, 메타데이터를 일상적으로 캡처합니다.
관할권을 넘습니다. 제공자가 당신과 다른 데이터 보호 규제의 국가에서 운영될 수 있습니다. EU 사용자가 미국 서버에 업로드할 때마다 이 경계를 넘습니다.

개인정보 처리방침에 흔히 적힌 말

충분히 많이 읽다 보면 패턴이 보입니다:

"파일은 24시간 후 삭제됩니다" — 흔하지만 검증할 방법이 없고, 24시간은 백업 스냅샷이 그것을 캡처하기에 충분한 시간입니다.
"파일을 제3자와 공유하지 않습니다" — 보통 "서비스 제공자 제외" 단서가 붙고, 이는 거의 누구든 의미할 수 있습니다.
"본 서비스 이용으로 콘텐츠 처리에 대한 라이선스를 부여합니다" — 어떤 해석에서는 모델 학습까지 커버할 만큼 광범위합니다.
로그와 분석에 대한 침묵 — 어떤 로그가 무엇을 수집하는지 처리방침이 열거 하는 일은 드뭅니다.

이 모두가 반드시 악용은 아닙니다. 사용자 업로드를 다루는 서버의 정상 운영 현실을 반영합니다. 동시에, 가장 프라이버시를 존중하는 답이 "파일을 보내지 않는 것"인 이유이기도 합니다.

2026년의 대안: 브라우저 전용 변환

모던 브라우저는 ffmpeg, libwebp, libheif에 들어가는 것과 같은 이미지/비디오 코덱을 WebAssembly 로 네이티브 실행할 수 있습니다. 변환은 탭 안에서 전부 일어나고, 파일은 기기를 떠나지 않습니다.

이건 제한된 부분집합이 아닙니다. 이 사이트가 지원하는 모든 변환 — PNG, JPG, WebP, AVIF, HEIC, GIF, MP4, WebM — 이 브라우저에서 실행됩니다. 파이프라인:

드롭존에 파일을 떨굽니다. 파일은 페이지 메모리에 File 객체로 들어갑니다.
WebAssembly 모듈 — 보통 libwebp, libheif, ffmpeg.wasm — 이 원본 포맷을 디코드합니다.
디코드된 픽셀 데이터가 다시 탭 안에서 대상 포맷으로 인코드됩니다.
결과는 Blob으로 감싸 다운로드로 제공됩니다.

브라우저 네트워크 패널은 변환 동안 0건의 아웃바운드 POST를 보여줍니다. 네트워크 활동은 초기 페이지 로드와 사이트가 출하한 분석/광고 스크립트뿐입니다. (Picovert는 분석을 사용하지만 파일 내용은 아닙니다 — 우리 서버에 도달하지 않으므로 원해도 읽을 수 없습니다.)

브라우저 전용 변환기를 가려내는 법

실용적인 다섯 가지 검증, 점진적으로 엄밀해집니다:

주장 자체를 찾으세요. 브라우저 전용 변환기는 의미 있는 차별점이라 이를 앞세웁니다. 홈페이지가 변환이 어디서 일어나는지 말하지 않으면 서버라고 가정하세요.
DevTools를 열고 변환을 실행해보세요. Network 탭을 보세요. 변환 중 POST/PUT 요청이 발생하지 않으면 파일은 업로드되지 않습니다. 가장 신뢰할 수 있는 단일 검증입니다.
변환 중간에 네트워크를 끊어보세요. 그래도 변환이 완료되면 로컬에서 돌고 있는 것입니다.
페이지가 Service Worker나 WASM을 쓰는지 확인. 소스 보기로 .wasm을 검색하세요. 브라우저 측 변환은 거의 항상 WASM 모듈을 로드합니다.
소스 코드를 찾으세요. 오픈소스 변환기는 무엇을 하는지 드러냅니다. Picovert 저장소는 공개돼 있습니다.

서버 측이 적절한 경우

서버 측 변환이 본질적으로 나쁜 것은 아닙니다. 그것이 옳은 아키텍처인 실제 사례가 있습니다:

브라우저 메모리에 들어가지 않는 파일 — 10GB 원본 비디오를 ffmpeg.wasm에 돌리는 건 합리적이지 않습니다.
중앙화된 GPU 자원이 필요한 변환 — AI 업스케일링, 슈퍼 해상도, 복잡한 비디오 트랜스코딩 파이프라인.
출력이 공유 위치에 저장돼야 하는 워크플로 — 팀 공유 자산, 콘텐츠 파이프라인.

개인 사진의 일회성 변환에는 어느 것도 해당하지 않습니다. 서버 측은 WebAssembly가 실현 가능 해지기 전 시대의 엔지니어링 관성일 뿐입니다.

Picovert에서의 선택

우리는 초기에 의도적인 선택을 했습니다: 모든 도구가 브라우저에서 실행됩니다. 변환 서버를 운영하지 않습니다. 사진을 담은 S3 버킷도 없습니다. "사용자 업로드" 테이블이 있는 데이터 베이스도 없습니다. 마케팅 문구가 아닙니다 — 우리가 출하하는 유일한 아키텍처이며, 위 DevTools 검증으로 확인할 수 있습니다.

트레이드오프는 브라우저 탭이 들고 있을 수 있는 크기보다 큰 파일(대부분의 머신에서 약 2GB)은 받지 못한다는 것, 그리고 멀티 GPU 서버 클러스터를 요구하는 변환은 못 한다는 것입니다. 99%의 경우 — 폰 사진 변환, 웹사이트 자산 최적화, GIF를 MP4로 — 에서는 브라우저로 충분합니다.

결론

"온라인 변환기"가 자동으로 "파일을 업로드한다"를 의미해서는 안 됩니다. 2026년 브라우저 기반 변환은 성숙하고, 빠르고, 무료입니다. 변환기가 당신의 파일이 어디로 가는지 말하지 않으면, 답은 "당신이 통제하지 않는 서버로 간다"라고 가정하세요. 위 DevTools 검증은 30초면 끝나고 진실을 알려줍니다.