1. 블러 기능 추가
2. 사진
NASA 이미지는 퍼블릭 도메인이다. STS-64 미션의 우주비행사 단체사진을 골랐다. 이유가 두 개 있다.
- 얼굴이 여섯 개 있다. 가리기 기능을 시험하려면 가릴 것이 필요하다.
- 메타데이터가 실제로 박혀 있다. 내가 만든 격자무늬 이미지에는 EXIF가 없어서, 메타데이터 패널을 진짜로 시험할 수 없었다.

| 항목 | 값 |
|---|---|
| 크기 | 4278 × 2852 |
| 파일 | 1,401,708 바이트 (1.3 MB) |
| 비화소 데이터 | 24,363 바이트 |
| 들어 있던 것 | EXIF, IPTC, XMP, ICC, APP14 |
3. 올리고, 기본값 확인
파일을 떨어뜨리면 큐에 4278 × 2852 · 1.3 MB로 올라온다. 아무것도 안 만졌을 때의 기본 출력은 1600 × 1067, 예상 용량 ~320 KB (−77%).
예상 용량은 상수를 곱한 값이 아니다. 같은 설정으로 최대변 480px짜리 견본을 실제로 인코딩해서 픽셀당 바이트를 재고, 그 값을 목표 해상도에 곱한다. 사진이냐 단색 그라데이션이냐에 따라 상수 추정은 열 배씩 틀리기 때문에 그렇게 만들었다.
그런데 이번 실측에서 예상이 실제보다 컸다. 뒤에 나오는 표를 미리 당겨 오면 이렇다.
| 픽셀당 바이트 | |
|---|---|
| 480px 견본에서 잰 값 (예상의 근거) | 0.19 |
| 1080 × 1350 실제 파일 | 0.13 |
같은 품질이라도 작게 렌더한 견본이 픽셀당으로는 더 무겁다. 축소하면 고주파 디테일이 남은 화소에 더 촘촘하게 몰리기 때문이다. 그래서 출력이 견본보다 훨씬 클 때는 예상이 1.5배 정도 높게 나온다. 숫자에 ~가 붙어 있는 이유이고, 실제 크기는 내보낸 뒤 파일 목록에 그대로 표시된다. 다만 "여유 있게 잡힌다"는 걸 알고 봐야 한다는 뜻이기도 하다 — 이건 손볼 여지가 있다.
4. 규격 프리셋 — 비율 먼저, 픽셀 나중
프리셋은 20종이다. 인스타그램 4종, 영상 3종, 그 외 소셜 7종, 웹 2종, 여권·증명사진 3종.

Feed 4:5 · 1080 × 1350을 눌렀다. 눌렀을 때 일어나는 일이 이 기능의 전부다.
- 크롭 비율을 4:5로 맞춘다. 크롭 상자는 중심을 유지한 채 그 비율로 다시 잡힌다.
- 그 다음에 출력 픽셀을 1080 × 1350으로 지정한다.
순서가 이쪽인 이유는, 반대로 하면 버릴 필요가 없는 화소를 먼저 버리기 때문이다. 결과는 이렇게 나왔다.
| 항목 | 값 |
|---|---|
| 크롭 영역 | X 998 · Y 0 · 너비 2282 · 높이 2852 |
| 출력 | 1080 × 1350 |
세로는 2852를 그대로 쓰고 가로만 2282로 잘렸다. 4:5를 만들려면 그게 최대다. 4278 중 1996 화소를 버렸다.

5. 얼굴 하나 가리기
블러 탭에서 앞줄 가운데 얼굴 위를 한 번 끌었다. 그게 조작 전부다. 세기는 기본값 60.

여기서 중요한 건 화면이 아니라 내보낸 파일이다. PDF에서 글자 위에 검은 사각형을 얹어 놓고 유출되는 사고가 몇 달에 한 번씩 뉴스가 되는데, 그건 원본 화소가 파일 안에 그대로 남아 있기 때문이다. 얹은 것은 걷어낼 수 있다.
그래서 이 도구는 화소를 실제로 파괴한다. 내려받은 파일을 열어 확인했다.

가려진 자리에서 복원할 것이 남아 있지 않다. 미리보기와 내보내기가 같은 함수를 부르기 때문에 화면에서 가려진 자리가 파일에서도 정확히 같은 자리다.
6. 여기서 문구가 틀렸다
형식 변환 탭에는 "이 파일에 들어 있는 정보" 패널이 있다. 지우는 기능이 아니다. 캔버스로 다시 인코딩하면 어차피 사라지니까, 무엇이 사라지는지 보여주는 패널이다.

읽어낸 값은 이랬다.
| 항목 | 값 |
|---|---|
| 촬영 시각 | 2010:03:17 10:40:51 |
| 편집 프로그램 | Adobe Photoshop CS3 Windows |
| 그 외 | IPTC, XMP, ICC, APP14 |
| 크기 | 24 KB (화소가 아닌 데이터) |
카메라 항목은 비어 있다. 1994년 미션 사진이 2010년에 찍힌 것으로 나오는 것도 정상이다. 필름을 스캔해 포토샵으로 처리한 시점이 EXIF에 남은 것이고, 이 패널은 파일에 실제로 적혀 있는 것만 보여준다. 있어야 할 것 같은 값이 아니라.
그런데 패널 아래 초록색 문구가 이렇게 되어 있었다.
✓ 위의 정보는 내보낸 파일에 남지 않습니다. 캔버스는 화소만 씁니다.
내보낸 파일을 직접 열어 쟀다.
| 비화소 데이터 | 남은 것 | |
|---|---|---|
| 원본 | 24,363 바이트 | EXIF, IPTC, XMP, ICC, APP14 |
| 내보낸 파일 | 492 바이트 | ICC |
0이 아니었다. EXIF도 GPS도 IPTC도 XMP도 전부 사라졌지만, 492바이트가 남는다. 브라우저 캔버스가 JPEG을 쓸 때 sRGB 색 프로파일을 자기가 새로 붙이기 때문이다. 개인정보가 남은 게 아니라 색 정보가 새로 생긴 것이라 실질적인 문제는 아니지만, "화소만 씁니다"는 사실이 아니다.
문구를 고쳤다.
✓ EXIF·GPS를 비롯한 위의 정보는 내보낸 파일에 남지 않습니다. 캔버스는 화소와, 자신이 붙이는 색 프로파일만 씁니다.
8개 언어 전부 고치고, 근거가 되는 실측값을 README에 같이 적어 뒀다. 나중에 누가 이 문구를 다시 단순하게 만들고 싶어질 때 왜 이렇게 길어졌는지 알 수 있도록.
이런 건 테스트 이미지로는 절대 안 나온다. 내가 만든 격자무늬 PNG에는 EXIF가 없어서 패널이 늘 "메타데이터가 없습니다"만 띄웠고, 나는 그걸 통과로 읽고 있었다.
7. 목표 용량 — 예상과 반대로 움직였다
같은 사진을 두 방식으로 내보내 비교했다.

| 방식 | 출력 | 파일 | 화면 표시 |
|---|---|---|---|
| 품질 82 | 1080 × 1350 | 192,398 바이트 (188 KB) | ~ 287 KB |
| 목표 200 KB | 1080 × 1350 | 202,127 바이트 (197 KB) | ≤ 200 KB |
목표를 걸었더니 파일이 커졌다. 품질 82로 이미 188 KB였는데, 200 KB를 목표로 주니 197 KB가 나왔다.
버그가 아니다. 목표 용량 모드는 "목표를 넘지 않는 가장 높은 품질"을 찾는다. 200 KB가 허용된다면 188 KB에 머무를 이유가 없으니 품질을 올려 197 KB까지 붙인 것이다. 파일 하나마다 인코딩을 여덟 번까지 반복하면서 이분탐색으로 찾고, 품질만으로 목표에 못 들어가면 픽셀 수도 줄인다.
다만 "용량 줄이는 기능"으로 생각하고 들어온 사람에게는 직관에 어긋난다. 서류 제출처가 "2MB 이하"를 요구할 때는 이게 맞는 동작이고, 그냥 가볍게 만들고 싶을 때는 품질 지정이 맞다.
그리고 하나 더 조심할 것이 있다. "200 KB"를 204,800바이트로 해석한다. 202,127바이트는 200 KiB 이하지만 200,000바이트는 넘는다. 제출 시스템이 십진 기준으로 자르면 걸린다. 여유가 필요하면 목표를 조금 낮게 잡는 게 안전하다.
8. 이 글의 스크린샷도 같은 도구로 줄였다
블로그에 4MB짜리 PNG를 올리는 건 이 글이 다루는 내용과 정면으로 어긋난다. 그래서 스크린샷 다섯 장을 한꺼번에 큐에 올리고 WebP · 최대변 1600 · 목표 200 KB로 내보냈다.
| 파일 | 전 | 후 |
|---|---|---|
| 자르기 화면 | 4560 × 3120 · 3.6 MB | 1600 × 1095 · 184 KB |
| 블러 화면 | 4560 × 3120 · 4.1 MB | 1600 × 1095 · 197 KB |
| 프리셋 패널 | 1248 × 3112 · 178 KB | 642 × 1600 · 49 KB |
| 메타데이터 패널 | 1248 × 3112 · 175 KB | 642 × 1600 · 56 KB |
| 목표 용량 패널 | 1248 × 3112 · 184 KB | 642 × 1600 · 56 KB |
| 합계 | 8.3 MB | 542 KB (−94%) |
위쪽 원본 사진도 같은 설정으로 1600 × 1067 · 195 KB가 됐다.
9. 정리
여섯 가지를 실제로 확인했다. 규격 프리셋, 블러, 메타데이터 판독, 목표 용량, PNG→WebP 변환, 여러 장 처리. 전부 브라우저 안에서 돌았고 사진은 기기를 떠나지 않았다.
고친 것은 한 건이다. 코드가 아니라 문구였다.
작동하지 않는 코드는 테스트가 잡아준다. 잡히지 않는 건 맞는 코드에 붙은 틀린 설명이다. 메타데이터는 예상대로 지워지고 있었고, 다만 "전부 지워진다"고 적어 둔 것이 조금 더 나갔던 것뿐이다. 프라이버시를 내세우는 도구에서 이런 과장은 기능 결함보다 나쁘다. 지켜지지 않는 약속이 하나 있으면 나머지 약속도 같이 의심받는다.
측정하지 않고 쓴 문장은 언젠가 틀린다. 그걸 확인하는 방법은 하나뿐이다. 진짜 파일을 올려서 결과물을 열어 보는 것.
10. 사이트, 사진 정보
editimg.online은 브라우저에서 도는 무료 이미지 편집 도구다. 크기 조절, 자르기, 블러, 필터, 형식 변환. 업로드 없음. 사진: NASA STS-64 (public domain)
댓글 0
불러오는 중…