녹음 파일이 편집됐는지 메타데이터와 해시값으로 확인하는 방법

녹음 파일이 편집되었는지 의심될 때 가장 먼저 살펴봐야 할 곳은 파일 자체에 들어 있는 기술적 기록이다. 음성만 들으면 잘라내기, 이어붙이기, 잡음 제거, 볼륨 정규화 같은 조작을 감지하기 어렵다. 하지만 녹음 파일은 단순한 PCM 데이터 덩어리가 아니라 컨테이너와 메타데이터가 함께 존재한다. WAV, FLAC, MP3, M4A, OGG 등 형식마다 저장 방식이 다르지만 모두 인코딩 환경, 생성 시점, 처리 이력에 대한 힌트를 남긴다. 이 흔적을 체계적으로 읽어내는 것이 편집 여부를 추적하는 첫 단계다. 특히 대화 증거, 인터뷰 원본, 통화 녹음, 기자의 취재 자료처럼 출처가 중요한 경우 기술적 문서화가 선행돼야 한다.

형식별 구조를 이해하면 어디를 봐야 할지 명확해진다. WAV는 RIFF 컨테이너 기반이라 fmt 청크와 data 청크 사이에 샘플레이트, 비트 깊이, 채널 수 등 기본 오디오 파라미터가 고정된다. 파일이 편집돼 다시 저장되면 fmt 청크가 바뀌거나 data 청크 길이가 원본과 달라진다. FLAC은 무손실 압축에 메타데이터 블록을 내장한다. STREAMINFO 블록에 총 샘플 수와 샘플레이트가 기록되고, VORBIS_COMMENT 블록에는 인코더 이름, 소프트웨어 버전, 생성일시가 들어간다. MP3는 MPEG 오디오 프레임과 ID3v2 태그로 이뤄진다. ID3 태그에는 타이틀, 아티스트, 인코딩 도구, 인코딩 날짜, 재생 시간 등이 들어갈 수 있고, 프레임 헤더에는 비트레이트와 샘플레이트가 프레임 단위로 반복된다. M4A는 MP4 컨테이너에 AAC 코덱을 넣은 형태로 moov 박스에 creation_time, encoder, duration 등이 저장된다. 이처럼 형식마다 핵심 정보가 기록되는 위치가 다르므로 먼저 어떤 컨테이너인지 확인하는 것이 출발점이다.

실제 검증에서 자주 활용되는 메타데이터 항목은 크게 세 그룹이다. 첫째는 시간 정보다. 파일 시스템 상의 생성일, 수정일, 마지막 접근일과 내부 메타데이터의 creation_time, encoded_by, encoding_date를 비교한다. 두 시점이 크게 어긋나거나, 파일 수정일이 녹음 주장 시점보다 훨씬 늦으면 재처리 가능성을 의심할 수 있다. 둘째는 인코딩 파라미터다. 샘플레이트 44.1kHz로 녹음됐다고 주장하는데 프레임 헤더가 48kHz로 나타난다거나, 채널 수가 스테레오에서 모노로 바뀌어 있다면 편집 과정에서 리샘플링이나 채널 변환이 일어났다는 뜻이다. 셋째는 소프트웨어 흔적이다. ID3 태그의 ENCODER, FLAC의 VORBIS_COMMENT, M4A의 �mef 박스 등에 Audacity, Adobe Audition, ffmpeg, iPhone Voice Memos 등이 남는다. 원본 녹음기는 보통 하나의 고정된 인코더를 사용한다. 중간에 다른 도구가 개입하면 인코더 문자열이 바뀌거나 여러 도구가 섞여 보인다.

편집이 있었는지를 판단하는 실무 포인트는 불연속성과 재인코딩 흔적이다. 편집 후 다시 저장하면 원본의 연속적인 인코딩 체인이 끊긴다. 예를 들어 MP3는 프레임 단위 압축이라 잘라내고 이어붙이면 첫 프레임과 마지막 프레임의 비트레이트 변동 패턴, 비트레이트 전환 지점에서 발생하는 인코딩 아티팩트가 생긴다. 또한 편집 도구는 흔히 파일을 한 번 디코딩한 뒤 다시 인코딩한다. 이 과정을 거치면 원본 인코더 정보가 사라지고 새로운 인코더가 기록되며, MD5나 SHA-256 해시값이 완전히 달라진다. 해시값은 파일 바이트 단위 지문이라 한 비트만 바뀌어도 값이 달라진다. 따라서 원본 파일과 비교 대상 파일의 해시값을 대조하면 동일성 여부를 기술적으로 증명할 수 있다. FilesAudit 홈페이지에서 파일 검증 보고서 생성하기 를 통해 업로드한 녹음 파일의 해시값과 메타데이터를 자동으로 추출해 문서화할 수 있다.

실제 사례를 보면 판단이 더 명확해진다. 카톡 음성 메시지로 받은 M4A 파일이 편집됐는지 확인해야 할 때, moov 박스의 creation_time이 전송 시점보다 수개월 뒤라면 재수출 가능성을 검토한다. 이어서 ffprobe로 추출한 encoder 문자열이 ‘Apple CoreAudio’ 대신 ‘Lavf58.76.100’ 즉 ffmpeg 계열로 나타난다면 이후 처리가 있었음을 시사한다. 인터뷰용 녹음기가 WAV로 남긴 원본과 제출된 MP3를 비교할 때는 샘플레이트와 비트 깊이가 일치하는지, MP3 인코딩 시점 태그가 존재하는지 본다. 인터뷰 당일에 녹음했음에도 인코딩 날짜가 며칠 뒤라면 편집·변환 과정을 거쳤을 가능성이 높다. 잡음 제거를 위해 Audacity로 처리한 파일은 종종 프로젝트 파일명이나 소프트웨어 버전이 메타데이터에 남으며, 파일 크기가 원본 대비 비정상적으로 줄어들거나 늘어난 경우도 편집 흔적이다. 지원되는 모든 음성·영상·문서 형식 목록 을 확인하면 검증 대상이 WAV, FLAC, MP3 외에도 OPUS, AMR, AIFF 등 모바일 녹음 파일도 커버된다는 점을 알 수 있다.

검증은 메타데이터만으로 끝나는 것이 아니다. 해시값 기반 무결성 확인과 타임스탬프 문서화가 함께 이뤄져야 신뢰도가 올라간다. 동일 파일이라도 다른 환경에서 열어 저장하면 메타데이터가 변한다. 그래서 원본을 확보한 직후 해시값을 고정하고, 이후 변경 여부를 주기적으로 비교하는 방식이 권장된다. 또한 메타데이터는 의도적으로 수정될 수 있다. ID3 태그는 쉽게 편집되고, EXIF처럼 오디오 메타데이터도 일부 도구가 임의로 덮어쓴다. 따라서 단일 지표로 편집 여부를 단정하기보다 여러 지표를 종합해 판단한다. 예를 들어