Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 기사는 이미지 파일에 포함되는 다양한 메타데이터(EXIF, XMP, IPTC, C2PA)의 위치와 구조를 심층적으로 분석합니다. 특히 AI 생성 콘텐츠의 출처(provenance) 정보를 담는 C2PA 매니페스트가 전송 과정에서 스크린샷이나 재인코딩을 거치면 손실될 수 있음을 테스트를 통해 보여줍니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기고지 사항: 저는 무료 이미지 검사기인 Check AI Free에서 작업하고 있습니다. 아래 언급된 도구와 MCP 서버는 저희가 소유한 것입니다. 테스트 숫자는 저희가 발표한 연구 페이지에서 가져왔으며, 발견된 내용을 최대한 가시적으로 유지하려고 노력했습니다._
누군가 "이 이미지는 AI가 생성한 것인가요?"라고 물었을 때 흔히 하는 질문은 "파일 자체에 그렇게 적혀있지 않나요?"라는 것입니다. 때로는 그렇습니다. 이미지 생성기(Generators), 카메라, 편집 프로그램들은 메타데이터를 작성하며, 점점 더 많은 프로그램들이 서명된 C2PA 매니페스트("Content Credentials")를 기록합니다. 하지만 여러분이 보고 있는 파일은 실제로 생성된 파일일 가능성이 낮습니다. 보통은 전송되는 과정에서 내보내지거나(exported), 스크린샷을 찍거나, 전달되거나, 재인코딩되었기 때문입니다.
본 게시물에서는 세 가지 내용을 다룹니다:
이미지 파일은 컨테이너와 압축된 픽셀의 조합입니다. 메타데이터는 픽셀 내부에 있는 것이 아니라, 픽셀 데이터 옆에 별도의 블록으로 존재합니다. 이 한 가지 사실이 이어지는 대부분의 내용을 설명해줍니다.
EXIF는 작은 TIFF 디렉토리입니다. JPEG 파일에서는 보통 Exif 바이트로 시작하는 APP1 세그먼트에 위치합니다. 여기에는 카메라 제조사 및 모델, 파일을 마지막으로 저장한 소프트웨어, 방향, 노출 시간, DateTimeOriginal, 그리고 중첩된 GPS 디렉토리를 담을 수 있습니다. PNG는 같은 TIFF 블록을 eXIf 청크에, WebP는 EXIF 청크에 담을 수 있습니다.
XMP는 XML 패킷입니다. JPEG 파일에서는 Adobe XMP 네임스페이스로 시작하는 두 번째 APP1 세그먼트에 위치합니다. EXIF 스타일의 필드를 반복할 수도 있고, 캡션과 크레딧을 포함할 수도 있으며, Content Credentials 설명도 담을 수 있습니다. 하지만 XMP 패킷은 여전히 텍스트일 뿐입니다. 서명된 매니페스트는 아닙니다.
IPTC는 뉴스 및 스톡 워크플로우에서 사용되는 캡션 및 크레딧 블록입니다. JPEG 파일에서는 보통 포토샵(Photoshop)의 APP13 리소스 내부에 위치합니다.
C2PA (Content Credentials)는 암호화 기능을 갖춘 메타데이터입니다. 매니페스트(manifest)에는 클레임 (CBOR, 클레임 생성기 명시), 어설션 저장소 (c2pa.actions 및 c2pa.ingredient와 같은 레이블이 지정된 레코드), 그리고 COSE 서명과 일반적으로 서명자의 인증서를 담는 서명 상자가 포함됩니다. JPEG의 경우 매니페스트 저장소는 APP11 세그먼트에 분할되어 있으며, 페이로드는 JP로 시작합니다. PNG의 경우 caBX 청크입니다.
AI 출처(provenance)를 위해 C2PA 내부에서 찾아야 할 필드는 액션에 포함된 디지털 소스 유형입니다. IPTC 값인 trainedAlgorithmicMedia (또는 이를 명시하는 복합 유형)은 매니페스트가 훈련된 생성 모델이 사용되었음을 _단언(assert)_한다는 의미입니다. 이는 파일 내의 진술이며, 시각적 추측이 아닙니다. 또한 이 정보는 서명, 인증서 체인, 그리고 매니페스트와 정확한 픽셀 간의 결속력만큼만 신뢰할 수 있습니다.
흔히 오해하는 두 가지 사례:
**
8 장의 사진 원본(Thomas Bresson, CC BY 2.0, Wikimedia Commons 제공). 이는 편의 표본이며, 0개의 생성 이미지를 포함합니다. 선택 규칙: filetype:bitmap Thomas Bresson으로 Commons에서 검색한 상위 10개 결과를 알파벳 순으로 정렬하고, 그중 10 MiB가 넘는 원본 두 개를 제외했습니다.
각 원본은 변경 없이 보존되었고 SHA-256 해시가 생성되었습니다. 이 해시는 공개되어 있으므로 동일한 바이트를 다시 다운로드하여 확인할 수 있습니다.
변환 A, JPEG 내보내기: EXIF 방향을 픽셀에 적용하고, RGB로 변환하며, 가장 긴 쪽의 크기를 LANCZOS 필터를 사용하여 최대 1536 px로 조정한 후, Pillow 12.3.0으로 품질 85 및 서브샘플링 2를 설정하여 저장하되, 인코더에 메타데이터는 전달하지 않았습니다.
변환 B, 브라우저 스크린샷: 원본을 800 × 600 크기의 흰색 뷰포트(contain sizing)에서 표시한 후, Chromium 152.0.7977.54를 사용하여 장치 스케일 1의 PNG 파일을 캡처했습니다.
이를 통해 24개의 파일이 생성되었습니다: 원본 8개와 변환된 사본 16개입니다.
필드 존재 여부는 Pillow(EXIF 하위-IFD 포함)로 독립적으로 읽었습니다. 별도로, 사이트 자체의 헤더 리더가 각 파일의 처음 64 KiB를 확인했습니다. 0개의 참조 구문 분석 오류가 있었습니다.
결과 (필드를 가진 원본만 보존 개수 계산):
| 필드 | 원본에서 | JPEG 내보내기 후 | 스크린샷 후 |
|---|---|---|---|
| 카메라 제조사 | 8/8 | 0/8 | 0/8 |
| ... |
사이트의 헤더 리더가 자체적으로 측정한 결과, 원본 8/8, JPEG 내보내기 0/8, 스크린샷 0/8에서 소스 단서를 발견했습니다.
격리된 Python 환경에서 동일한 고정 Pillow 버전을 사용하여 반복 실행한 결과, 24개 필드 존재 여부 및 제품 신호 관찰 결과를 모두 재현했습니다. 모든 원본 해시는 일치했습니다. 스크린샷 PNG 중 하나는 실행 간에 다른 바이트를 가지고 나왔지만, 관찰된 필드는 변경되지 않았습니다. 브라우저 캡처는 바이트가 동일할 것이라고 보장할 수 없습니다.
이 결과는 놀랍지 않으며, 저는 마치 그러한 것처럼 제시하는 것이 아닙니다. JPEG 내보내기(export)는 의도적으로 메타데이터를 포함하지 않았고, 스크린샷은 화면의 새로운 사진입니다. 이 테스트의 가치는 '스크린샷이 원본처럼 보일 수 있지만 여전히 소스 필드를 전혀 갖지 않을 수 있다'는 주장에 이제 고정된 프로토콜, 공개된 해시값(hashes), 그리고 반복 실행을 통해 근거를 마련했다는 점에 있습니다.
제시하지 않는 것:
일반화하기 전에, 다음 에디션은 생성된 이미지를 포함하는 더 광범위하고 독립적으로 출처가 확보된 배치가 필요합니다. 이전 카운트는 변경 로그(changelog)에 남아 있습니다.
실제 작동 순서: 가능하다면 원본을 얻고, 파일이 무엇을 말하는지 읽고, 맥락을 유지한 다음, 비로소 픽셀 모델 점수를 확인합니다.
APP1/APP13) PNG(eXIf 및 텍스트)와 WebP에서 로컬로 읽습니다. 파일은 업로드되지 않으므로, GPS 좌표가 파일을 가진 누구에게나 노출된다는 점이 중요합니다.APP11 / caBX 매니페스트 저장소를 탐색하여 클레임 생성기, 첫 번째 인증서의 서명자 이름, 기록된 작업, 재료, 그리고 모든 trainedAlgorithmicMedia 주장을 출력합니다. 이는 서명, 인증서 체인 또는 픽셀 바인딩을 검증하지 않습니다. 신뢰할 수 있는 검증을 위해서는 발행사 자체의 검사기나 Content Authenticity Initiative의 verify 도구를 사용하십시오.사진을 공유하려 한다면, 메타데이터를 _복사본_에서 제거하고 원본은 보관하세요. 필드를 제거하기 전에 내용을 읽어보세요. 왜냐하면 기록된 이력이 있었다는 사실이 없었다고 주장하는 것보다 누락된 매니페스트에 대해서는 나중에 반박하기 어렵기 때문입니다.
스크립트화할 수 있는 것이 필요하다면, 일반적인 오픈 도구들이 잘 작동합니다:
# exiftool이 알고 있는 모든 메타데이터 그룹을 덤프합니다
exiftool -a -G1 photo.jpg
...
그리고 필드 존재 여부를 테스트에 사용한 것과 같은 작은 Pillow 검사입니다:
from PIL import Image
img = Image.open(
- **이미지를 업로드합니다.** 두 도구 모두 선택된 바이트를 Check AI Free의 `/api/v1/detect` 헤더 엔드포인트로 전송합니다. 이는 로컬에서만 작동하는 검사기가 아니므로, 민감한 이미지는 입력하지 마십시오.
- **헤더만 읽습니다.** 픽셀 모델 경로를 호출하지 않기 때문에, 메타데이터가 없는 파일은 결론을 내리지 못할 수 있습니다. 이 어댑터는 절대 생성하지 않는, 완성된 픽셀 분류 점수에 대해서만 모델 백분율을 출력합니다.
- **C2PA를 검증하지 않습니다.** C2PA 라인은 검사된 바이트에서 출처 마커가 관찰되었는지 여부를 의미하며, 서명이 확인되었다는 것을 의미하지는 않습니다.
- 입력은 JPEG, PNG 및 WebP이며, 최대 10 MiB까지 가능합니다.
[developers page](https://checkaifree.com/developers)에서 엔드포인트와 응답 필드(`result.verdict`, `result.ai_probability`, `signals` 배열, `classifier_available`)를 확인할 수 있습니다. 헤더 경로의 경우, `ai_probability`는 모델이 아닌 메타데이터 리더에서 가져옵니다.
## 명확하게 밝히는 한계점들
- **메타데이터는 수정 가능합니다.** 카메라 제조사, 모델 및 캡처 시간은 저장된 텍스트입니다. 이들은 다른 파일에 복사되거나, 편집자에 의해 오래된 상태로 남겨지거나, 제거될 수 있습니다.
- **누락된 필드 역시 아무것도 증명하지 못합니다.** 비어 있다는 것은 실제 결과이며, 스크린샷 후의 일반적인 결과입니다. 이는 장면 자체의 속성이 아니라 _이 복사본_의 속성입니다.
- **서명된 매니페스트(manifest)가 가장 강력한 파일 수준 신호이지만, 검증된 경우에만 해당됩니다.** 매니페스트를 읽는 것이 그것을 검증하는 것과 같지 않으며, 매니페스트는 다른 바이트에 복사될 수 있습니다.
- **메타데이터를 제거한다고 해서 픽셀이 바뀌지는 않습니다.** 프롬프트나 매니페스트를 제거하는 것은 주장(claim)을 제거할 뿐입니다. 합성 이미지가 픽셀 모델이나 사람에게 사진처럼 보이게 만들지 못합니다.
- **픽셀 감지기는 별도의 확률적 문제입니다.** 그 출력을 파일 증거 및 맥락과 함께 유지하십시오. 그것이 대체하게 두지 마십시오.
만약 여러분이 이 프로토콜의 자체 버전을 실행한다면, 특히 실제 플랫폼 업로드 또는 생성된 이미지를 사용해서요, 저는 의견을 교환하고 싶습니다. 방법론과 해시값은 [연구 페이지](https://checkaifree.com/research/image-metadata-survival)에 있으니, 같은 파일부터 시작할 수 있습니다.