암호화된 비상 영상 증거 보전에 대하여

시작점 — 오래된 아이디어#

이 아이디어를 가장 단순하게 표현하면 이렇다.

"카메라로 위급할 때 찍혔는데, 휴대폰엔 남지 않고, 어딘가 서버에 암호화된 상태로 저장한다. 사용자한테 무슨 일이 생기면 그 암호화된 것을 다시 볼 수 있다. 그래서 잠재적 위험을 예방한다."

문장은 짧지만 안에 네 가지 요구가 들어 있다.

1. 휴대폰 밖으로 즉시 증거가 빠진다 — 단말이 파괴·압수·분실되어도 남는다.
2. 서버는 평소에 영상 원문을 복호화할 수 없다 — 운영자, 내부자, 해커, 수사기관이 저장소를 확보해도. (업로드 시각·크기·IP 같은 메타데이터는 별개 문제다)
3. 사용자가 위험에 처했을 때는 열린다 — 본인이 못 여는 상황을 포함.
4. 그 열림은 정당해야 한다 — 법적으로 설명 가능하고 감사 가능해야.

이 네 조건을 동시에 만족시키는 게 단순해 보이지만, 사실 암호학적으로 가장 어려운 지점이다. 서버도 못 보게 암호화하면, 사용자가 못 여는 상황에서 누가 어떻게 여는가. 이 질문이 사실상 이 글 전체의 주제다.

이미 있는 것들#

"응급 녹화 → 클라우드 업로드 → 보호자 공유"는 이미 흔하다. "단말 밖 증거 보전"도 흔하다. "서버도 못 보는 영상 암호화"는 일부 있다. 그런데 "앞의 네 조건을 동시에 만족"하는 대중 제품은, 적어도 공개된 범위 안에서는 거의 없다.

요약하면, 응급 녹화·클라우드 백업·보호자 공유는 이미 산업적으로 자리 잡았다. 무결성·체인 오브 커스터디도 활동가 도구와 기관 인프라 양쪽에서 성숙해 있다. 그러나 "서버 운영자도 평소엔 못 보지만, 사용자가 위급 상황일 때 정당한 절차로 열리는" 구조를 깔끔하게 갖춘 대중 제품은, 적어도 공개 사례 안에서는 비어 있는 자리다.

무결성 도구에 대해서는 단서를 하나 달아야 한다. ProofMode 측도 스스로 밝히듯, 이런 서명·진위 메타데이터는 그 자체가 암호화도 아니고 조작 가능성을 낮추는 보조 증거일 뿐이며, 자동으로 법정 증거능력을 보장하지 않는다. 실제 증거능력은 관할 법, 수집 경위, 보관·제출 절차에 따라 따로 판단된다.

제품으로 정의해보기#

이 아이디어를 한 줄로 정의한다면 이렇다.

자동차 블랙박스와의 차이를 표로 잡으면 윤곽이 더 분명해진다.

기술적으로는 어떻게 만들 수 있나#

트리거 — 언제 녹화·업로드가 시작되는가

MVP에서는 수동 SOS와 Safety check 미응답의 조합이 가장 안전하다. 완전 자동 범죄 감지는 기술적으로도 윤리적으로도 부담이 크다.

저장 — 어떻게 단말 밖으로 빠지나

권장 구조는 다음과 같다.

1. 롤링 버퍼. 평시에는 RAM 또는 임시 암호화 버퍼에 최근 15-60초만 유지한다. 트리거 발동 시 그 직전 구간까지 포함해 업로드한다. 단 현대 모바일 OS는 백그라운드 카메라·마이크를 강하게 제한하므로, 이 버퍼는 앱이 포그라운드에서 활성화된 동안에만 현실적이다 — 은밀한 상시 녹화는 가정하지 않는다.
2. 청크 단위 업로드. 영상을 2-5초 단위로 쪼개 전송한다. 네트워크가 끊기면 로컬 암호화 큐에 보관하고, 연결 복구 시 따라잡는다 (catch-up).
3. 클라이언트 측 암호화. 청크는 단말에서 먼저 AES-256-GCM으로 암호화된 뒤 서버로 간다. 서버는 암호문만 본다. AES-GCM은 nonce 재사용이 치명적이므로 사건 키마다 청크 nonce가 절대 겹치지 않아야 한다 — event_id·chunk_index·랜덤 salt를 조합해 고유 nonce를 만들고, event_id·chunk_index·직전 해시는 AAD(추가 인증 데이터)로 묶어 청크 재배열·바꿔치기를 탐지한다.
4. 해시 체인. 각 청크에 직전 청크의 해시를 포함시킨다. 중간 삭제·삽입·순서 변경이 그대로 드러난다. 다만 해시 체인만으로는 서버가 마지막 N개 청크를 통째로 숨기는 truncation을 막기 어렵다. 사건의 Merkle root 또는 체인 체크포인트를 주기적으로 외부 타임스탬프 서버·transparency log·제3자 미러에 고정하면, 사후에 일부 청크를 숨기거나 사건 존재 자체를 부인하기 어려워진다.
5. 단말 서명. Android Keystore 또는 iOS Secure Enclave에 묶인 개인키로 사건 단위 메타데이터를 서명한다. 여기에 기기 attestation(Android Key Attestation·Play Integrity, iOS App Attest·DeviceCheck)과 외부 타임스탬프를 결합하면 "이 키를 가진 단말이 이 사건 레코드를 특정 시점 이전에 생성했다"는 점을 강하게 뒷받침할 수 있다. 다만 이것이 촬영 시각이나 장면의 진실성을 절대적으로 증명하는 것은 아니다 — attestation도 진실 보장이 아니라 조작 비용을 높이는 장치이고, 법정 증거성은 수집·보관·제출 절차와 함께 판단된다.

한 가지는 정확히 해둬야 한다. 클라이언트 측 암호화는 영상 원문을 가리지만, 업로드 시각·청크 크기·단말 IP·계정 식별자·위치 메타데이터 같은 정보는 별도 보호 설계가 없으면 서버에 그대로 노출된다. "서버가 못 본다"는 말은 "원문을 복호화할 수 없다"는 뜻이지 "아무것도 알 수 없다"는 뜻이 아니다. 이 메타데이터 누출 metadata leakage 자체를 줄이려면 크기 패딩, 더미 트래픽, 전송 시각 교란 같은 추가 설계가 따로 필요하다.

키 관리 — 누가 언제 열 수 있나

이 부분이 제품의 핵심이자 가장 어려운 지점이다. 여섯 가지 설계안을 비교해보면 다음과 같다.

연구 가치가 가장 큰 구조는 다음의 조합이다.

여기에 모든 복호화 시도가 변조가 드러나는(tamper-evident) 추가 전용(append-only) 감사 로그에 남는 구조를 더하면 "평소엔 아무도 못 보고, 정당한 조건에서만 열리고, 누가 열었는지 추적 가능"이라는 세 요건이 동시에 충족된다.

키가 분산돼 있어도 사람은 강요당할 수 있다. 그래서 "어떤 상태에서 무엇이 열리는가"와 "강요당하면 어떻게 되는가"를 미리 설계해 둬야 한다. 한 사건의 상태 전이를 그리면 이렇다.

평시 Normal
 │  SOS 트리거 · Safety check 미응답
 ↓
사건 봉인 Sealed ─ 청크 암호화·업로드, 단독 삭제 불가
 │  업로드 완료
 ↓
잠금 보류 Pending ─ 서버는 암호문만 본다
 │
 ├─ 본인 즉시 해제 ───────────→ 본인 복호화
 │
 └─ 부재 · 비상 요청
      │  사용자 통지 + 지연창(취소 가능)
      ↓
     접근 요청 Access Request
      │  2-of-3 quorum 동의 — 독립적 제3자 1명 필수
      ↓
     제한적 복호화 Limited Decryption
      │  모든 시도는 감사 로그에 남음
      ↓
     종료 · 보존 · 이관

핵심은 둘이다. 첫째, "봉인"은 한 명이 싸고 빠르게 시작할 수 있되 "열람"은 독립적 제3자를 포함한 quorum 없이는 불가능하다. 둘째, 어떤 경로로도 자동 공개는 없다 — 부재 신호는 곧장 공개가 아니라 통지·지연·검토 단계로 들어간다.

마지막 빈틈은 강압이다. 가해자가 사용자를 협박해 직접 해제·삭제하게 만드는 상황은 암호로 막을 수 없다. 그래서 강요당한 동작이 정상처럼 보이되 실제로는 보존·경보로 이어지는 duress 흐름을 둔다.

강압을 완벽히 막을 수는 없다. 다만 "조용한 삭제"를 불가능하게 만들고 강압 시도를 흔적으로 남기면, 가해자가 그 행위로 얻을 수 있는 것이 줄어든다.

다만 이 불변성은 잊힐 권리와 충돌할 수 있다. 개인정보보호법 제36조의 삭제 요구권을 생각하면, 오작동으로 타인의 내밀한 장면이 올라갔는데 본인이 지울 수 없는 구조는 위험하다. 그래서 "변경 불가"는 누가 언제 접근했나라는 감사 로그에만 적용하고, 콘텐츠 자체는 사용자 삭제권을 보장하되 강압 방지를 위한 지연·확인만 두는 편이 옳다. 자동 만료 보관(일반 7일·보존 표시 90일)이 나머지를 메운다.

고급 암호 기법은 어디까지 쓸 수 있나#

이 영역에서 가장 자주 떠오르는 질문은 "동형 암호 Homomorphic Encryption, HE를 쓸 수 있는가"이다. 결론부터 말하면 쓸 수 있는 지점은 있지만, 영상 원본 위에 직접 거는 건 현재 비현실적이다.

대표적 최적화 연구인 HyPHEN도 ResNet-20으로 CIFAR-10 추론에 1.4초, ResNet-18로 ImageNet 추론에 14.7초가 걸린다(단일 이미지 기준). 이후 후속 연구들이 더 큰 모델과 더 나은 지연 시간을 보였지만, 30fps 영상 1분이면 1800프레임이다. 실시간 근처도 못 간다. 거기에 암호문 팽창 문제까지 더하면 영상에 직접 HE를 거는 설계는 당분간 무리다.

대신 응용 가능한 지점은 네 군데다.

첫째, 트리거 판단을 센서 데이터 위에서. 영상이 아니라 가속도계·심박수·GPS 같은 저차원 시계열에는 HE 추론이 이미 가능하다. 워치/폰의 헬스 데이터를 CKKS로 암호화해 서버에 올리고, "낙상 + 심박 급변 + 비명 패턴" 같은 복합 조건을 암호화 상태로 평가한 뒤 트리거를 발동시킨다. 영상은 보통 암호화로 저장해두고, 트리거가 켜지면 키를 곧바로 해방하기보다 사건 보존·보호자 알림·복호화 요청 워크플로를 시작하는 신호로 쓰는 분리 구조(자동 모델이 키 해방까지 직결되면 오탐 때 위험하다). 핵심은 트리거 로직의 세부 조건이 서버 운영자에게 노출되지 않는다는 점이다. 다만 이는 기밀성에 대한 이야기일 뿐이다. 서버가 업로드를 거부하거나, 청크를 지연·삭제하거나, 알림 전달을 막는 availability 공격은 HE로 해결되지 않는다 — 그 부분은 다중 업로드 경로, 외부 타임스탬프, append-only 로그, 제3자 미러링으로 따로 방어해야 한다.

둘째, 암호화된 데이터에 대한 제한적 질의. 장기 연구로는 "사람이 등장했는가", "비명·충격·급격한 움직임이 있었는가" 같은 비식별 event-ness 질의를 1-bit 출력으로 뽑아, 수사 기관이 영장을 받아도 영상 전체가 아니라 yes/no만 얻어가는 모델을 생각해볼 수 있다. 다만 "특정 인물 X가 등장했는가" 같은 생체식별 질의는 성능·오탐·모델 편향·법적 근거·프라이버시 위험이 모두 커서 MVP에서는 제외해야 한다.

셋째, 다자간 집계. 여러 사용자의 암호화된 영상·메타데이터에서 "이 시간대 이 지역에서 이상 사건이 N건 이상 감지되었는가" 같은 집계는 개별 영상을 풀지 않고 사회적 신호만 추출할 수 있다.

넷째, 학습 데이터로서의 활용. 원본을 평문화하지 않는 학습은 장기적으로 secure aggregation, federated learning, differential privacy에 일부 HE 추론을 조합하는 방향이 더 현실적이다. HE 상태에서 영상 모델을 직접 재학습하는 것은 — 학습이 추론보다 훨씬 무겁기 때문에 — 현재로선 제품 기능이라기보다 연구 주제에 가깝다.

그리고 사실 이 아이디어의 "조건 만족 시 복호화" 부분은 HE보다 다른 도구가 더 잘 맞는다.

실전 시스템은 보통 이 도구들의 하이브리드가 된다. 영상 자체는 AES로 빠르게, 키는 ABE 또는 threshold로 보호, 트리거 판정은 센서 데이터에 HE를 적용. 순수 HE 일변도 설계는 거의 없다.

논문 각도로 보면 신선한 지점은 셋이다.

1. 암호화된 영상에 대한 "사건성 event-ness 판별"의 multiplicative depth 최소화. 전체 분류 대신 "뭔가 일어났다"는 얕은 yes/no 술어로 설계하면 depth를 낮게 유지해 bootstrap을 회피할 여지가 생긴다.
2. HE 트리거 평가 결과를 threshold decryption의 share 해방 조건으로 연결하는 합성 프로토콜의 보안 증명.
3. HE 연산이 의도한 회로대로 수행됐음을 보이는 verifiable computation — zkSNARK와 HE의 결합 — 으로 법정 제출 시 계산 과정의 검증·설명 가능성을 높이기. 다만 이것이 자동으로 증거능력을 보장하지는 않는다.

다만 분명히 해두자. 이 절의 고급 기법들 — HE, ABE, witness encryption, TEE — 은 당장 구현할 MVP 기능이 아니라 장기 연구 방향이다. 1차 제품은 클라이언트 측 암호화, 청크 업로드, 키 분산, 감사 로그, 그리고 법적 절차 설계만으로도 충분하다. 이 절은 "지금 만들 것"이 아니라 "여기까지 갈 수 있다"는 지도에 가깝다.

이게 진짜로 범죄를 예방하나#

이 질문은 정직하게 답해야 한다. 증거 보전에는 강하다. 범죄 억제는 조건부다.

행동억제 효과는 보통 가해자가 "촬영되고 있다, 처벌 가능성이 올라간다"고 인지할 때 강해진다. 그런데 이 아이디어처럼 은밀히 서버에 저장되는 구조라면 가해자는 촬영 사실 자체를 모를 수 있다. 그 경우 즉시 억제 효과는 약해진다.

경찰 바디캠 연구에서도 행동 변화 효과는 일관적이지 않다. 미국 국립 형사사법연구원 NIJ는 바디캠의 근거가 혼재되어 있다고 정리했고, 30개 연구를 메타분석한 Campbell 체계적 리뷰(Lum 외, 2020)도 시민 불만 접수는 줄였지만 물리력 사용 등 대부분의 행동 지표에서는 통계적으로 유의하고 일관된 효과를 확인하지 못했다고 평가한다.

그렇다면 이 시스템의 진짜 가치는 어디인가. 정직하게 다섯으로 나눠야 한다.

이 아이디어의 진짜 강점은 "예방"보다는 사후 증거 소실 방지와 사용자 안전 보장이라고 봐야 정확하다. 예방은 부수적 효과일 뿐이다.

한국에서 괜찮나#

정식 법률 자문은 변호사 영역이지만, 제품 기획 단계에서 이미 보이는 지점들이 있다.

영상은 개인정보다. 얼굴·신체·차량번호·위치·음성이 들어가면 개인정보성이 생긴다. 서비스로 운영하면 개인정보처리자가 될 가능성이 크다. 개인정보보호위원회는 2024년 9월 안내서를 통해 휴대폰·디지털 카메라 같은 휴대형 장치가 이동형 영상정보처리기기에 포함됨을 명시하고, 업무 목적의 촬영에 대해 개인정보보호법 제25조의2의 허용 요건을 적용한다(2023-09-15 시행).

사적 공간은 매우 위험하다. 화장실·탈의실·목욕실 같은 사생활 침해 위험이 큰 장소의 촬영은 개인정보보호법 제25조의2제2항으로 제한될 뿐 아니라, 신체를 촬영하면 성폭력처벌법 제14조(카메라등이용촬영죄)로 형사처벌까지 될 수 있다. 위급 구조 같은 예외 상황이 아니라면 제품 기본 설계에서 이런 공간에서의 녹화는 강하게 차단되어야 한다.

음성은 영상보다 더 민감하다. 한국 통신비밀보호법상 "타인 간의 비공개 대화"를 제3자가 녹음하는 것은 금지된다. 반면 대화 당사자 중 한 명이 직접 녹음하는 경우는 "타인 간 대화" 녹음으로 보지 않는 판례 흐름이 있다. 사용자가 대화에 참여 중인 상황과, 휴대폰이 방치된 채 제3자들만의 대화를 녹음하는 상황은 법적 성격이 완전히 다르다.

위치는 영상·음성과 또 다른 법의 영역이다. GPS·위치 공유·112/119 연동이 핵심 기능인 이상, 이 시스템은 개인정보보호법과 별도로 위치정보의 보호 및 이용 등에 관한 법률(위치정보법)의 적용을 받는다. 위치기반서비스(LBS)를 사업으로 제공하려면 같은 법 제9조에 따라 방송미디어통신위원회(2025년 10월 방송통신위원회를 대체해 출범)에 신고해야 하고, 개인위치정보를 직접 수집·제공하는 위치정보사업은 제5조의 허가 또는 등록 대상이다. 개인위치정보를 다룰 때는 수집(제18조)·이용·제공(제19조) 동의를 받아야 하고, 무단 수집과 누설·변조·훼손이 금지되며(제15조), 이용·제공사실 확인자료의 기록·보존을 포함한 보호조치(제16조)와 목적 달성 후 파기(제23조) 의무가 따른다. 영상·음성 법리와 별도로 개인위치정보 처리 구조를 처음부터 따로 설계해야 한다는 뜻이다.

서버 위치도 이슈다. 클라우드가 해외 리전에 있거나, 영상이 보호자·수사 기관·보험사·학교·회사로 흘러가면 국외 이전, 제3자 제공, 목적 외 이용 문제가 동시에 생긴다. 국외 이전 동의 시에는 이전 국가, 일시·방법, 수령자, 목적·보유기간, 거부권 등을 고지해야 한다.

요컨대 이 시스템은 "법적으로 가능한가" 이전에 "법적 설계가 제품 설계와 같이 가야 가능한가"의 영역이다. 변호사가 처음부터 함께 가야 한다.

그래서 어떻게 설계해야 하나#

피해야 할 설계

가져가야 할 설계

위협모델 — 막는 것과 못 막는 것#

앞 절들이 "어떻게 만드나"를 다뤘다면, 이 절은 "그렇게 만들어도 무엇을 못 막나"를 본다. 보안 설계에서 가장 위험한 태도는 막지 못하는 것을 막는다고 말하는 것이다. 위협을 공격자별로 나눠 보면, 이 시스템이 강한 자리와 구조적으로 약한 자리가 분명히 갈린다.

이 표의 한 줄 요약은 이렇다. 이 시스템은 "서버를 신뢰하지 않아도 되는" 영역 — 외부자·내부자·서버에 대한 기밀성과 무결성 — 에서 강하고, 사람·물리·법이 얽히는 영역에서 약하다. 그리고 약한 자리의 일부는 더 나은 설계로 메울 수 있지만, 일부는 원리상 메울 수 없다.

암호가 풀 수 있는 문제와 풀 수 없는 문제를 갈라 말하는 것 자체가 이 시스템이 지켜야 할 정직함이다. 가장 아픈 지점은 친밀관계 폭력에서 quorum이 무너지는 경우다. 신뢰해야 할 사람이 곧 위협인 상황은 암호로 풀리지 않고, 보호자 선정 기준, 독립적 제3자의 필수 포함, 강압을 드러내는 통지·감사 같은 설계로만 일부 완화될 뿐이다.

만든다면 이렇게: MVP 스케치#

연구 프로토타입 수준으로 만든다면 다음 정도의 범위가 적당하다. 사용자 한 명, 청중 한 명, 데모 한 번을 위한 최소 구성이다.

1. SOS 트리거: 앱 내 패닉 버튼 / Safety timer 미응답 / 플랫폼별 단축 동작(iOS Action Button·잠금화면 위젯·Siri 단축어, Android Quick Settings 타일·포그라운드 서비스). 전원 버튼 연타는 OS 기본 Emergency SOS와 충돌해 일반 앱이 직접 가로채기 어려우므로 기본 경로로 가정하지 않는다.
2. 수집: 전후방 카메라 선택, 마이크, GPS, 시간, IMU
3. 암호화 업로드: 3초 청크, 청크별 AES-256-GCM, 해시 체인, 단말 서명
4. 조건부 복호화: 본인 즉시 / 보호자 2명 동의 / 사고 선언 / 전 과정 로그
5. 보관: 일반 7일, 사용자 보존 표시 90일, 법적 요청 별도

기술 스택 예시

구경할 만한 순서#

이 분야를 한 번도 본 적이 없다면 다음 순서를 권한다.

가장 가까운 개인 안전 앱부터

• Parachute — 단말 밖 증거 보전 + 실시간 영상·음성·위치 공유.
• bSafe — 보호자 실시간 스트리밍 UX 참고.
• iWitness — 가장 단순하지만 핵심 컨셉 일치.
• Mockingjay — AES-256-GCM 실시간 본인 클라우드 업로드.

대형 플랫폼의 구현

• Google Pixel Personal Safety — SOS·백업·공유의 상용 UX.
• Apple Emergency SOS Live Video — 긴급기관 연동 라이브 영상.

한국형 공공 사례

• 보이는 112 — URL 기반 영상·위치 전송, 비밀 모드.
• 긴급신고 바로 — 취약계층 신고 보조 UX.

증거성·무결성 도구

• ProofMode — 촬영물 진위성, 서명, C2PA 메타데이터.
• eyeWitness to Atrocities — IBA의 분쟁지역 증거수집 앱.
• Axon Evidence — 기관용 디지털 증거 관리의 표준 사례.

서버도 못 보는 영상 암호화 사례

• Ring End-to-End Encryption — 강점과 함께, 패스프레이즈 분실 시 영구 접근 불가라는 핵심 난점도 가장 분명히 보여준다.

맺음말#

"카메라로 찍어서 서버에 암호화 저장"만으로는 더 이상 새롭지 않다. 지금 시점에서 이 아이디어가 차별성을 가지려면 네 가지를 동시에 만족시켜야 한다.

• 사용자 휴대폰이 파괴·압수·분실되어도 증거가 남는다.
• 서버 운영자도 평소에는 영상 원문을 복호화하지 못한다.
• 사용자가 복호화할 수 없는 상황에서도 정당한 조건에서 열린다.
• 그 과정이 법적으로 설명 가능하고, 감사 가능하고, 오남용을 막을 수 있다.

이 네 가지를 동시에 푸는 시스템은 단순한 안전 앱이 아니라 개인용 암호화 증거 인프라가 된다. 그 자리가 정말로 비어 있는지, 비어 있다면 누가 채워야 하는지는 또 다른 글의 몫이다. 이 글의 몫은 오래된 아이디어 하나를 다시 꺼내 진지하게 들여다보는 것까지다.