Step 246. EXIF/메타데이터와 문서 포렌식 — 파일 속에 새겨진 지문을 읽는다

Level 3 — CTF 실전과 공격 스킬 심화 | 난이도 ★★★☆☆ | 예상 소요 시간 3~4시간

전제: Step 245 완료. 파이썬 3(pillow, python-docx)을 사용합니다. 모든 파일은 직접 만들어 분석합니다.

⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다.

준비물: 파이썬 3(실측: 3.12.14, pillow·python-docx 포함). 인터넷 연결은 필요 없습니다.
주의: 오늘 다루는 사진과 문서는 전부 실습용으로 새로 만듭니다. 남의 사진의 GPS 좌표를 추적하거나, 매크로 문서를 실행하는 일은 절대 하지 않습니다 — 매크로는 코드를 "읽는" 것이지 "돌리는" 것이 아닙니다.

사진 한 장에는 찍힌 풍경 말고도 또 하나의 정보층이 있습니다 — 무슨 기기로, 언제, 어디서 찍었는지가 파일 안에 새겨져 있습니다(EXIF). 오피스 문서에도 작성자, 마지막 수정자, 만든 프로그램의 이름이 남습니다. 사건에서는 이것이 위치 증거가 되고, OSINT 조사에서는 신원 단서가 됩니다. 오늘은 그 숨은 층을 직접 심고, 직접 읽고, 왜 플랫폼들이 그것을 지우는지까지 배웁니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

EXIF와 문서 메타데이터(metadata)가 무엇이고 왜 증거가 되는지 설명한다
파이썬 pillow로 이미지에 EXIF를 심고 다시 읽는다
GPS 도분초(DMS) 좌표를 십진수로 변환해 지도에 찍을 수 있는 형태로 만든다
docx가 ZIP 묶음임을 이해하고 docProps/core.xml에서 작성자 정보를 추출한다
메타데이터가 거짓말할 수 있음을 실측 사례로 설명한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분	내용
언어·환경	파이썬 3 — pillow(이미지), python-docx(문서), 표준 라이브러리 zipfile
오늘의 명령어	`Image.Exif()`(EXIF 만들기), `img.getexif()` / `ex.get_ifd(0x8825)`(읽기·GPS), `ZipFile("문서.docx").read("docProps/core.xml")`
필요한 개념	EXIF 태그 번호, GPS DMS 좌표, OOXML(docx = ZIP), 메타데이터의 신뢰 한계

2-1. 메타데이터 — 데이터에 대한 데이터

메타데이터(metadata)는 "본문이 아니라 본문에 붙은 설명 정보"입니다. 사진의 본문은 픽셀이고, 메타데이터는 촬영 시각·기기·좌표입니다. 문서의 본문은 글자이고, 메타데이터는 작성자·수정 이력·사용 프로그램입니다.

포렌식에서 메타데이터가 중요한 이유는 Step 244의 아티팩트와 같습니다 — 작성자가 의식해서 쓴 내용이 아니라 프로그램이 자동으로 새긴 것이라, 본문보다 꾸미기 어렵고(그래서 종종 진실을 말하고), 작성자가 존재 자체를 모르는 경우가 많습니다(그래서 지워지지 않고 남습니다).

2-2. EXIF — 사진의 출생증명서

EXIF(Exchangeable image file format)는 JPEG/TIFF 이미지에 붙는 표준 메타데이터 규격입니다. 각 정보는 태그 번호로 구분됩니다. 오늘 쓸 것들:

태그(16진수)	이름	내용
`0x010F`	Make	카메라 제조사
`0x0110`	Model	기기 모델명
`0x0132`	DateTime	촬영(또는 수정) 시각
`0x8825`	GPSInfo	GPS 좌표 묶음으로의 연결

스마트폰 사진에는 여기에 GPS 좌표가 들어가는 경우가 많습니다 — 사진 한 장이 "찍힌 장소"를 스스로 고백하는 셈입니다. 이것이 사건 수사와 언론 검증에서 사진을 먼저 EXIF부터 여는 이유입니다.

2-3. GPS 좌표 — 도분초에서 십진수로

EXIF의 GPS는 도(度)·분(分)·초(秒) 세 값의 쌍(위도, 경도)으로 저장됩니다. 예: (37, 33, 58.9) 북위. 지도 서비스가 쓰는 십진수로 바꾸려면:

도 + 분/60 + 초/3600  →  37 + 33/60 + 58.9/3600 = 37.5664

변환 한 줄이면 "사진 속 좌표"가 "지도의 한 지점"이 됩니다. 오늘 직접 계산합니다.

2-4. docx는 ZIP이다 — 문서의 엑스레이

.docx, .xlsx, .pptx(통칭 OOXML) 파일은 겉보기엔 하나지만 사실 여러 XML 파일을 ZIP으로 압축한 묶음입니다. 그래서 파이썬 zipfile로 그대로 열 수 있습니다. 그 안의 docProps/core.xml에 작성자·수정자·시각이, docProps/app.xml에 만든 프로그램 정보가 들어 있습니다.

매크로 문서(.docm 등)의 위험도 이 구조에서 나옵니다 — 문서에 실행 코드가 함께 들어갈 수 있어서, 악성코드 유포의 고전 수단입니다. 대응 절차는 정해져 있습니다: 열지 말고(실행 금지), 코드만 추출해 읽는다. olevba 같은 도구가 매크로 코드만 안전하게 빼내 줍니다. 오늘은 개념 수준에서 절차를 정리합니다.

2-5. 메타데이터는 거짓말을 한다 — 신뢰의 한계

마지막으로 가장 중요한 교훈: 메타데이터는 자동 기록이지만 조작 가능합니다. 카메라 시계가 틀려 있으면 촬영 시각도 틀리고, 도구로 EXIF를 통째로 바꿀 수도 있고, 문서의 "작성 프로그램" 항목은 파일을 만든 도구가 무엇이든 적습니다. 오늘 실습에서 이 거짓말을 실제로 목격하게 됩니다. 결론: 메타데이터는 단서이지 판결문이 아닙니다 — 다른 증거와 교차 확인할 때만 힘을 가집니다.

3. 따라 하기

3-1. EXIF 심기 — 증거가 있는 사진 만들기

먼저 "촬영 정보가 들어간 사진"을 우리 손으로 만듭니다. exif_lab.py:

from PIL import Image
from pathlib import Path

lab = Path("lab246"); lab.mkdir(exist_ok=True)
img = Image.new("RGB", (320, 240), (40, 90, 160))  # 파란 단색 이미지

exif = Image.Exif()
exif[0x010F] = "ACME Corp"               # 제조사
exif[0x0110] = "PhotonCam X2"            # 모델
exif[0x0132] = "2026:09:09 21:40:17"     # 촬영 시각
exif[0x8825] = {                         # GPS (도분초)
    1: "N", 2: (37, 33, 58.9),           # 위도 37도 33분 58.9초 북위
    3: "E", 4: (127, 1, 40.1),           # 경도 127도 1분 40.1초 동경
}
img.save(lab / "photo.jpg", exif=exif)
print("saved")

실행하면 lab246/photo.jpg가 생깁니다 (2026-09-09 실측 확인). 겉으로는 그냥 파란 그림이지만, 안에는 기기·시각·좌표가 새겨져 있습니다. 증거를 만들어 본 사람이 증거를 잘 읽습니다 — 지금 우리는 "조사 대상의 제작자" 입장을 경험한 겁니다.

3-2. EXIF 읽기 — 사진의 고백 듣기

이제 조사자 입장으로 돌아가 읽습니다:

from PIL import Image

img = Image.open("lab246/photo.jpg")
ex = img.getexif()
print("Make:", ex.get(0x010F))
print("Model:", ex.get(0x0110))
print("DateTime:", ex.get(0x0132))

Make: ACME Corp
Model: PhotonCam X2
DateTime: 2026:09:09 21:40:17

(2026-09-09 실측.)

GPS는 한 겹 더 들어가 있습니다 — 0x8825 태그는 좌표 묶음(GPS IFD)을 가리키는 연결고리라서 get_ifd로 열어 봅니다:

gps = ex.get_ifd(0x8825)
print("GPS raw:", dict(gps))

def dms_to_deg(dms):
    d, m, s = float(dms[0]), float(dms[1]), float(dms[2])
    return d + m / 60 + s / 3600

print(f"위도 {dms_to_deg(gps[2]):.4f} {gps[1]}, 경도 {dms_to_deg(gps[4]):.4f} {gps[3]}")

GPS raw: {0: b'\x02', 1: 'N', 2: (37.0, 33.0, 58.9), 3: 'E', 4: (127.0, 1.0, 40.1)}
위도 37.5664 N, 경도 127.0278 E

(2026-09-09 실측.)

출력 읽는 법: 2: (37.0, 33.0, 58.9)가 위도의 도·분·초, 1: 'N'이 북위 표시입니다. 변환 결과 37.5664, 127.0278 — 지도에 찍으면 서울 도심 근처입니다. 실제 사건이라면 "이 사진은 이 좌표 부근에서 촬영됐다"는 단서가 확보된 겁니다. 여러분이 지도 서비스에 이 좌표를 넣어 보는 것까지가 오늘의 흐름입니다(인터넷이 된다면).

3-3. 왜 SNS 사진에서는 안 나올까 — 스트리핑

여기서 의문: "그럼 SNS에 올라온 사진에서도 좌표를 뺄 수 있나?" 대부분의 큰 플랫폼은 업로드 과정에서 EXIF를 삭제(스트리핑, stripping) 합니다. 이용자의 위치가 새어 나가는 사고가 반복됐기 때문입니다.

확인 방법은 간단합니다: 같은 사진의 원본과 플랫폼에서 다운로드한 사본을 3-2절 코드로 각각 읽어 비교해 보세요. 원본에 있던 태그가 사본에서 비어 있으면 스트리핑된 겁니다. 포렌식 관점의 교훈: "메타데이터가 없다"는 "애초에 없었다"와 "누군가 지웠다"를 구분 못 합니다 — Step 245의 "지워진 흔적" 원리가 여기에도 그대로입니다.

3-4. docx 해부 — ZIP으로서의 문서

이제 문서로 넘어갑니다. 메타데이터가 심어진 docx를 만들고:

import docx
from pathlib import Path

lab = Path("lab246")
d = docx.Document()
d.add_paragraph("Quarterly incident summary (sample document).")
cp = d.core_properties
cp.author = "lee.minsu"            # 최초 작성자
cp.last_modified_by = "park.jihye" # 마지막 수정자
cp.title = "Incident Summary"
cp.comments = "draft v3 - internal only"
d.save(lab / "report.docx")

문서를 ZIP으로 엽니다. 확장자를 바꿀 필요도 없이 파이썬이 읽어 줍니다:

from zipfile import ZipFile

with ZipFile("lab246/report.docx") as z:
    for n in z.namelist()[:6]:
        print(" ", n)
    core = z.read("docProps/core.xml").decode("utf-8")
    print(core)

  [Content_Types].xml
  _rels/.rels
  docProps/core.xml
  docProps/app.xml
  word/document.xml
  word/_rels/document.xml.rels
--- core.xml ---
...<dc:title>Incident Summary</dc:title>...<dc:creator>lee.minsu</dc:creator>...
<dc:description>draft v3 - internal only</dc:description>
<cp:lastModifiedBy>park.jihye</cp:lastModifiedBy><cp:revision>1</cp:revision>
<dcterms:created ...>2013-12-23T23:15:00Z</dcterms:created>
<dcterms:modified ...>2013-12-23T23:15:00Z</dcterms:modified>...

(2026-09-09 실측. 네임스페이스 선언부는 생략했습니다.)

출력 읽는 법: <dc:creator>lee.minsu</dc:creator>에 최초 작성자가, <cp:lastModifiedBy>park.jihye</cp:lastModifiedBy>에 마지막 손댄 사람이 그대로 남아 있습니다. 실제 유출 문서 분석에서 "작성자 A, 수정자 B"가 다른 조직의 이름으로 밝혀져 진원지가 드러난 사례들이 있습니다.

3-5. 메타데이터의 거짓말 — 실측으로 확인

그런데 위 출력을 잘 보세요. 방금 2026년에 만든 파일인데 created가 2013-12-23입니다. 이유: python-docx가 쓰는 기본 템플릿에 그 시각이 박혀 있고, 우리가 고치지 않았기 때문입니다. 거짓말은 여기서 끝이 아닙니다. app.xml을 열어 보면:

with ZipFile("lab246/report.docx") as z:
    print(z.read("docProps/app.xml").decode("utf-8")[:300])

<Properties ...>
  <Template>Normal.dotm</Template>
  <TotalTime>0</TotalTime>
  <Pages>1</Pages>
  ...
  <Application>Microsoft Macintosh Word

(2026-09-09 실측.)

이 파일은 윈도우의 파이썬으로 만들었는데, "만든 프로그램" 칸에는 Microsoft Macintosh Word라 적혀 있습니다 — 템플릿의 기본값을 그대로 물려받은 것입니다.

이것이 2-5절의 실물 증거입니다. "작성 프로그램이 Mac용 워드니까 작성자는 맥 사용자다"라고 추론했다면 완전히 틀린 결론이 됐을 겁니다. 메타데이터는 증언일 뿐이고, 증언은 교차 확인 없이 채택하지 않습니다.

3-6. 매크로 문서 대응 절차 (개념 정리)

오늘 실행하지는 않지만, 문서 포렌식의 다른 절반인 매크로 문서 대응 절차를 정리해 둡니다. 실제로 의심 문서를 받았을 때의 철칙:

절대 더블클릭하지 않는다 — 열리는 순간 매크로가 실행될 수 있습니다
파일을 격리된 분석 환경(랩 VM)으로 옮긴다
olevba 문서.docm 같은 도구로 매크로 코드만 추출해 텍스트로 읽는다
난독화된 문자열을 따라가며 "실제로 무엇을 다운로드·실행하려 하나"를 정적 분석한다
CTF 연습은 안전한 샘플(연습용으로 제작된 것)로만 한다

원리는 3-4절과 같습니다 — 문서도 결국 파일이고, 코드도 텍스트로 읽을 수 있습니다. 읽는 것과 실행하는 것의 차이가 안전의 전부입니다.

4. 미션과 연습문제

미션 — 내 손으로 만드는 메타데이터 수사

3-1절 코드를 변형해 여러분만의 EXIF 사진을 만드세요 (기기명·시각·좌표를 바꿔서)
다른 파이썬 스크립트에서 그 사진을 열어 세 정보를 추출하세요 — "만든 사람과 조사자를 분리"하는 연습입니다
GPS 좌표를 십진수로 변환하세요 (3-2절)
3-4절의 docx에서 작성자·수정자·작성 프로그램 세 가지를 추출해 metadata-report.txt에 정리하세요
마지막 줄에 "이 메타데이터 중 내가 신뢰할 수 있는 것과 없는 것"을 구분해 적으세요

연습문제

문제 1. EXIF와 문서 메타데이터가 "본문보다 진실을 말할 때가 많은" 이유를 2-1절의 관점에서 설명해 보세요.

문제 2. EXIF GPS 값 (37, 33, 58.9) N을 십진수로 변환하는 과정을 손으로 계산해 보세요.

문제 3. 어떤 유출 문서의 core.xml에서 작성자가 kim.cheolsu, app.xml의 Application이 Microsoft Macintosh Word였습니다. "이 문서는 kim.cheolsu가 맥에서 작성했다"고 결론 내릴 수 있나요? 오늘 실측을 근거로 답하세요.

문제 4. 플랫폼에 올라온 사진에서 EXIF가 비어 있었습니다. 이 사실만으로 알 수 있는 것과 알 수 없는 것을 구분해 보세요.

5. 모범 답안과 완료 기준

미션 모범 답안

제작 스크립트 예시:

from PIL import Image
img = Image.new("RGB", (320, 240), (200, 60, 60))
exif = Image.Exif()
exif[0x010F] = "MyLab"
exif[0x0110] = "TestCam 3000"
exif[0x0132] = "2026:09:09 22:00:00"
exif[0x8825] = {1: "N", 2: (35, 10, 46.2), 3: "E", 4: (129, 4, 31.0)}
img.save("lab246/myphoto.jpg", exif=exif)

조사 스크립트는 3-2절 그대로 사용합니다. 변환 결과 예시: 35도 10분 46.2초 → 35 + 10/60 + 46.2/3600 = 35.1795 N.

metadata-report.txt 예시:

=== photo.jpg ===
Make: MyLab / Model: TestCam 3000 / DateTime: 2026:09:09 22:00:00
GPS: 35.1795 N, 129.0753 E  (도분초 (35,10,46.2)/(129,4,31.0) 변환)

=== report.docx (docProps/core.xml, app.xml) ===
작성자(dc:creator): lee.minsu
마지막 수정자(cp:lastModifiedBy): park.jihye
작성 프로그램(Application): Microsoft Macintosh Word

=== 신뢰도 판단 ===
신뢰 가능: 내가 직접 심은 값(만든 사람이 나라서 검증 가능)
신뢰 불가 단독 사용: created 시각(템플릿 기본값 2013-12-23 실측),
  Application(윈도우 파이썬 생성인데 Mac 워드로 기록됨 실측)

검증하는 법: 조사 스크립트 출력이 제작 스크립트에서 심은 값과 정확히 일치하면 추출 성공입니다. docx 부분은 core.xml과 app.xml을 직접 열어 눈으로 대조하세요. "신뢰도 판단"란이 채워져 있어야 완성입니다 — 추출만 하고 신뢰도를 안 적으면 조사가 아니라 복사입니다.

연습문제 해답

문제 1 해답. 메타데이터는 사용자가 의식해서 쓰는 것이 아니라 프로그램이 자동으로 새기는 기록이라, (1) 꾸밀 의도가 개입할 여지가 본문보다 적고, (2) 존재 자체를 모르는 작성자가 많아 지워지지 않고 남기 때문입니다. 단, 도구로 조작 가능하므로 교차 확인이 필요합니다.

문제 2 해답. 37 + 33/60 + 58.9/3600 = 37 + 0.55 + 0.01636 ≈ 37.5664 → 위도 37.5664°N입니다 (2026-09-09 파이썬 실측 결과와 일치).

문제 3 해답. 안 됩니다. 오늘 실측에서 윈도우 + 파이썬으로 만든 docx의 Application이 "Microsoft Macintosh Word"로 기록됐습니다 — 이 항목은 템플릿 기본값이 들어갈 수 있어 단독 증거가 못 됩니다. 작성자 항목도 도구로 얼마든지 바꿀 수 있습니다. "kim.cheolsu라는 문자열이 기록되어 있다"까지만 사실이고, 그 이상은 다른 증거(파일 전달 경로, 내부 스타일, 시각들의 정합성)와 교차 확인해야 합니다.

문제 4 해답. 알 수 있는 것: "현재 이 사본에는 EXIF가 없다." 알 수 없는 것: 원본에도 없었는지(촬영 앱이 안 심는 경우), 플랫폼이 지웠는지, 누군가 의도적으로 제거했는지. 부재는 원인을 증명하지 못하므로, 보고서에는 "메타데이터 부재 — 원인 불명"으로 기록하고 다른 단서를 찾아야 합니다.

완료 기준 체크리스트

[ ] 메타데이터를 "프로그램이 자동으로 새긴 설명 정보"로 설명할 수 있다
[ ] EXIF 태그 번호(0x010F, 0x0110, 0x0132, 0x8825)의 역할을 안다
[ ] pillow로 EXIF를 심고 getexif()/get_ifd()로 읽을 수 있다
[ ] GPS 도분초를 십진수로 변환할 수 있다
[ ] docx를 zipfile로 열어 core.xml/app.xml을 추출할 수 있다
[ ] 메타데이터가 조작·기본값으로 오염될 수 있음을 실측 사례로 설명할 수 있다
[ ] 매크로 문서는 "실행하지 않고 코드만 추출해 읽는다"는 절차를 안다
[ ] 미션: metadata-report.txt를 완성했다

6. 흔한 실수와 해결

벽 1. getexif()로 GPS가 안 보인다

증상: Make/Model은 나오는데 GPS 항목이 없습니다.
원인: 0x8825(GPSInfo)는 값이 아니라 하위 묶음(IFD)을 가리키는 연결고리라서 getexif() 결과에는 직접 안 나타납니다.
해결: ex.get_ifd(0x8825)로 한 겹 더 열어야 좌표가 보입니다 (2026-09-09 실측 확인). EXIF는 "사진 정보 / 상세 정보 / GPS"처럼 여러 방(IFD)으로 나뉜 구조입니다.

벽 2. EXIF를 심었는데 저장하면 사라진다

증상: PNG로 저장했더니 EXIF가 안 읽힙니다.
원인: EXIF는 기본적으로 JPEG/TIFF 규격입니다. PNG는 메타데이터를 다른 방식(텍스트 청크)으로 저장해서 exif= 인자가 기대대로 들어가지 않습니다.
해결: .jpg로 저장하세요. PNG에서 메타데이터를 다뤄야 한다면 PngImagePlugin.PngInfo로 텍스트 청크를 씁니다 — 개념은 같고 그릇만 다릅니다.

벽 3. GPS 변환 결과가 지도에서 바다 한가운데다

증상: 변환한 좌표를 지도에 넣었더니 엉뚱한 곳입니다.
원인: 두 가지를 확인하세요 — (1) N/S, E/W 방향 표시(태그 1, 3)를 빼먹어 남반구·서반구로 간 경우, (2) 분을 60이 아니라 100으로 나눈 경우.
해결: 도 + 분/60 + 초/3600 공식을 다시 확인하고, S와 W는 결과에 마이너스를 붙이세요.

벽 4. docx를 zipfile로 여는데 에러가 난다

증상: zipfile.BadZipFile: File is not a zip file.
원인: 그 파일은 OOXML(docx)이 아니라 구형 바이너리 형식(doc)이거나, docx라 이름 붙은 다른 파일입니다. 구형 .doc은 OLE 복합 문서라 다른 도구(olefile 등)가 필요합니다.
해결: 파일의 진짜 정체를 먼저 확인하세요 — Step 239에서 배운 것처럼 시그니처로 판별합니다 (PK로 시작하면 ZIP 계열).

벽 5. 메타데이터를 그대로 믿어 보고서를 엉망으로 쓴다

증상: "작성 프로그램: Macintosh Word"를 보고 "맥 사용자 작성"이라고 단정했습니다.
원인: 3-5절 실측처럼 템플릿 기본값이 그대로 남는 경우가 흔합니다. 시각, 프로그램명, 작성자 모두 조작·상속될 수 있습니다.
해결: 메타데이터 항목마다 "이 값이 이 파일의 실제 이력과 정합한가"를 물으세요. created가 modified보다 늦거나, 프로그램명과 파일 내부 구조가 안 맞으면 오염 신호입니다.

7. 정리

오늘의 개념

개념	한 줄 설명
메타데이터	본문에 붙은 자동 기록 설명 정보 — 작성자가 모르는 경우가 많아 남는다
EXIF	JPEG/TIFF의 표준 메타데이터 — 기기·시각·GPS, 태그 번호로 구분
GPS DMS	도·분·초 좌표 — `도+분/60+초/3600`으로 십진수 변환
OOXML (docx)	XML 여럿을 ZIP으로 묶은 문서 — core.xml에 작성자, app.xml에 프로그램
스트리핑	플랫폼이 업로드 시 메타데이터를 지우는 것 — 사생활 보호 조치
메타데이터의 한계	자동 기록이지만 조작·템플릿 오염 가능 — 단서이지 판결문이 아님

오늘의 명령어·코드

코드	하는 일
`Image.Exif()` + `exif[태그] = 값`	EXIF 심기
`img.getexif()`	기본 EXIF 읽기
`ex.get_ifd(0x8825)`	GPS 묶음 열기
`도 + 분/60 + 초/3600`	좌표 십진수 변환
`ZipFile("a.docx").read("docProps/core.xml")`	문서 작성자 메타데이터 추출
`ZipFile(...).read("docProps/app.xml")`	작성 프로그램 정보 추출

명령어보다 중요한 감각

오늘의 핵심은 대칭 구조입니다: 메타데이터를 심어 본 사람만이 메타데이터를 제대로 의심합니다. 우리는 직접 심고, 직접 읽고, 그리고 템플릿 기본값이라는 거짓말까지 실측으로 목격했습니다. "이 파일은 맥에서 만들어졌다"는 증언이 틀릴 수 있다는 걸 눈으로 봤으니, 앞으로 어떤 메타데이터든 "단독 채택 금지, 교차 확인 필수"가 몸에 배야 합니다.

실무에서는 오늘의 파이썬 코드를 exiftool 한 줄이 대신합니다 — exiftool 사진.jpg면 EXIF와 문서 메타데이터가 한 화면에 나옵니다. 도구가 빠를수록 "출력된 값을 어떻게 신뢰도별로 분류할 것인가"가 분석가의 실력이 됩니다. 오늘 여러분은 그 분류 기준을 실측으로 얻었습니다.

전부 체크되면 Step 246 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.