들어가며
데이터베이스를 조금이라도 다뤄본 개발자라면 “삭제된 레코드”라는 표현이 주는 기술적 뉘앙스를 이해할 것이다. 이 글에서는 카카오톡 대화 복원을 SQLite 내부 구조 관점에서 살펴본다. 일반적으로 “삭제된 데이터 복구”라고 뭉뚱그려 표현되지만, 실제로는 데이터베이스 페이지 구조·B-Tree·저널·WAL이 복잡하게 얽힌 작업이다.
1. SQLite 저장 단위 – 페이지(Page)
SQLite는 모든 데이터를 페이지 단위로 관리한다. 페이지 크기는 일반적으로 4,096 바이트이며, 파일 전체가 이 페이지들의 연속으로 구성된다.
각 페이지는 용도에 따라 다음과 같이 나뉜다:
- 테이블 B-Tree 페이지: 레코드가 저장되는 본체
- 인덱스 B-Tree 페이지: 검색 성능을 위한 인덱스
- Overflow 페이지: 하나의 페이지에 담기지 않는 큰 필드 저장용
- Free 페이지: 재사용 가능한 빈 페이지
- Lock-byte 페이지: 파일 잠금 관리용
메시지 하나가 저장되는 과정을 거슬러 올라가면, 결국 테이블 페이지의 특정 셀(cell) 에 기록된다는 뜻이다.
2. “삭제”가 페이지에 미치는 영향
DELETE 쿼리의 내부 동작
애플리케이션에서 DELETE 쿼리를 실행하면, SQLite는 해당 셀을 페이지의 “프리 블록(free block)” 체인에 추가한다. 이 과정에서 다음이 일어난다:
- 셀 포인터 배열에서 해당 엔트리 제거
- 셀 콘텐츠 영역은 그대로 보존
- 페이지 헤더의 freeblock 링크드 리스트에 추가
- 페이지가 완전히 비어지면 전체를 프리 페이지로 변환
핵심은 “실제 바이트 데이터는 건드리지 않는다” 는 점이다. 새로운 INSERT가 해당 영역을 요청하기 전까지, 삭제된 메시지의 원본 바이트는 물리적으로 페이지 내부에 잔존한다.
페이지 재사용 시점
새로운 INSERT가 발생하면 SQLite는 프리 블록을 우선적으로 재사용한다. 이때 덮어쓰기가 발생하며, 그 순간부터 해당 데이터는 복원 불가능해진다. 재사용 속도는 애플리케이션의 쓰기 빈도에 정비례한다. 카카오톡처럼 메시지가 활발히 주고받는 앱에서 삭제된 데이터는 빠르게 덮어써질 수 있다.
3. 저널 파일과 WAL의 역할
SQLite는 트랜잭션 무결성을 위해 두 가지 저널링 방식을 사용한다:
Rollback Journal (*.db-journal)
트랜잭션 시작 시 수정 전 페이지를 저널 파일에 복사해둔다. 트랜잭션 중 문제가 생기면 이 파일로 원복한다. 성공적으로 커밋되면 저널은 일반적으로 삭제되지만, 파일 시스템에 따라 물리적 잔재가 남을 수 있다.
WAL Mode (*.db-wal, *.db-shm)
Write-Ahead Logging 모드에서는 변경사항을 WAL 파일에 먼저 기록하고, 주기적으로 메인 DB에 반영(checkpoint)한다. WAL 파일에는 최근 트랜잭션의 원본 데이터가 상당 기간 남아있을 수 있다.
포렌식 분석에서는 이 저널·WAL 파일이 보물창고 역할을 한다. 메인 DB에서 이미 덮어써진 데이터가 여기에서 발견되는 경우가 적지 않다.
4. 카카오톡 DB 구조의 특이점
메시지 테이블 구조
카카오톡의 메시지 관련 테이블은 일반적으로 다음과 같은 필드를 포함한다 (버전에 따라 상이):
- message_id (INTEGER PRIMARY KEY)
- chat_id (INTEGER)
- user_id (INTEGER)
- message (TEXT)
- attachment (TEXT/BLOB)
- created_at (INTEGER, UNIX timestamp)
- type (INTEGER)메시지 본문은 TEXT 필드, 첨부 미디어는 별도 파일 시스템 경로를 참조한다.
암호화 레이어
최신 버전의 카카오톡은 일부 필드에 암호화를 적용한다. 이는 일반 SQLite 브라우저로는 내용을 읽을 수 없게 만들지만, 포렌식 도구는 키 추출과 복호화 절차를 포함하므로 분석이 가능하다. 물론 iOS처럼 하드웨어 보안 영역(Secure Enclave)과 결합된 경우 난이도가 크게 올라간다.
대화방과 메시지의 관계
대화방(Chat) 테이블과 메시지(Message) 테이블은 chat_id로 연결된다. 대화방 나가기를 하면 Chat 레코드가 삭제되지만, 연결된 수많은 Message 레코드가 일괄 삭제 처리되며 대량의 프리 블록이 한 번에 생성된다. 이 때문에 대화방 나가기는 개별 메시지 삭제보다 복구 난이도가 높다.
5. 포렌식 분석의 기술적 단계
Stage 1. 물리 이미징
기기 스토리지를 비트 단위로 복제한다. 원본은 봉인 보관하고, 이후 모든 분석은 이미지 파일에서만 수행한다. 해시값(SHA-256 등)을 생성해 무결성을 보증한다.
Stage 2. 파일 시스템 분석
이미지에서 카카오톡 관련 파일 경로를 식별한다:
KakaoTalk.dbKakaoTalk.db-journal또는KakaoTalk.db-walKakaoTalk.db-shm- 미디어 캐시 디렉터리
Stage 3. DB 내부 스캔
추출된 DB 파일에 대해 다음을 수행한다:
- 프리 블록 영역 전수 스캔
- Overflow 페이지 내용 재조립
- 커밋되지 않은 WAL 엔트리 추출
- 저널 파일의 원본 페이지 복원
Stage 4. 카빙(Carving)
파일 시스템 메타데이터가 손상된 경우, 시그니처 기반으로 SQLite 페이지 자체를 찾아내 재조립한다. 공장초기화 이후에도 이 방식으로 일부 복원이 가능한 경우가 있다.
Stage 5. 재구성과 시간 정렬
추출된 레코드를 created_at 기반으로 정렬하고, chat_id로 그룹화해 읽을 수 있는 대화 형태로 복원한다.
6. 복원율에 영향을 주는 기술적 요소
① 페이지 재사용 압력
저장공간이 부족할수록 SQLite 및 파일 시스템이 공격적으로 프리 영역을 재활용한다. 저장공간 95% 이상이 지속되면 삭제 데이터 수명이 급격히 짧아진다.
② WAL 체크포인트 주기
WAL 모드에서는 체크포인트가 자주 일어날수록 과거 데이터가 메인 DB로 흡수되며 잔재가 줄어든다. 반대로 앱이 비활성 상태로 오래 있었다면 WAL에 많은 정보가 남아있다.
③ TRIM 명령 지원 여부
SSD 기반 스토리지는 TRIM 명령을 통해 삭제된 영역을 물리적으로 0으로 덮는 경우가 있다. 스마트폰 내부 저장소도 eMMC/UFS 구조에서 유사한 동작을 한다. TRIM이 적극적으로 활성화된 기기에서는 복원 난이도가 현저히 올라간다.
④ 암호화 계층
파일 시스템 레벨 암호화(Apple Data Protection, Android File-Based Encryption)는 이미지 자체를 암호화된 상태로 만든다. 기기 잠금 해제 정보가 있어야 분석 가능하며, 이것이 아이폰 복원 난이도가 높은 기술적 이유다.
7. 증거능력과 분석 품질
기술적 복원 가능성과 법적 증거능력은 별개의 문제다. 법정에서 인정받기 위해서는:
- 동일성(Identity): 원본과 이미지의 해시값 일치 증명
- 무결성(Integrity): 분석 과정에서 변경되지 않았음을 로그로 증명
- 신뢰성(Reliability): 업계 표준에 부합하는 절차 사용
- 재현성(Reproducibility): 동일 절차로 동일 결과 도출 가능
이러한 요건은 개인이 임의로 수행한 복구 앱 결과로는 충족 불가능하다. 전문 포렌식 기관의 정식 절차를 통해서만 법적 증거로 기능하는 결과물을 얻을 수 있다.
이런 기술적 배경과 실제 서비스 절차에 대해서는 카카오톡 대화내용 복구 안내에서 단계별 정리를 확인할 수 있으며, 종합적인 포렌식 서비스와 감정서 발급 기준은 카카오톡 대화내용 복구 전문 기관을 통해 자세히 안내받을 수 있다.
8. 개발자·IT 실무자를 위한 권고
개인 사용자라면
.db-journal,.db-wal파일의 중요성 인지- 삭제 후 즉시 기기 사용 중단
- 복구 앱 설치는 오히려 역효과 (쓰기 발생)
법무·수사·감사 실무자라면
- 체인 오브 커스터디(Chain of Custody) 문서화 필수
- 해시값 기반 무결성 증명 체계 이해
- 증거 보전 명령 시점과 덮어쓰기 진행도의 관계 파악
일반 IT 관리자라면
- SQLite 기반 앱에서 DELETE와 VACUUM의 차이 이해
- VACUUM을 실행하면 프리 블록이 정리되어 복원 불가능해짐
- 법적 보존 의무가 있는 경우 VACUUM 자동 실행 주의
결론
카카오톡 메시지 복원은 단순한 “지운 파일 되살리기”가 아니라, SQLite 내부 구조·파일 시스템·암호화 계층이 결합된 다층적 엔지니어링 문제다. 각 계층에서 어떤 일이 벌어지는지 이해하면, 왜 “삭제 직후 기기 사용 중단”이 그토록 강조되는지, 왜 “앱 재설치가 치명적”인지, 왜 “전문 장비가 필요한지” 자연스럽게 이해된다.
기술을 아는 사람일수록, 오히려 “일단 꺼두고 전문가에게 맡기는” 선택을 한다. 섣부른 자가 조치가 상황을 악화시킬 수 있음을 알기 때문이다. 디지털 데이터의 본질을 이해하는 것, 그것이 가장 현명한 첫 대응이다.