93f896af87
4개 관점 병렬 감사 후 각 발견을 반증 시도해 확정. 반증 5건은 문서에 남겼다. 이번 감사의 요지: **구현도 단위테스트도 초록인데 납품 경로에서 동작하지 않는** 결함이 셋 있었다. 전부 같은 모양이다 — 테스트가 기본값이 아닌 설정을 썼거나, 값이 존재해도 되는지 결정하는 상류 허용 목록을 보지 않았다. CRITICAL 4건: R4-1 추락 승격이 기본 설정에서 한 번도 발화하지 않았다. link_s(3.0)를 now 기준으로 쟀는데 넘어짐은 prone_confirm_s(3.0) 지속 후 확정되므로 확정 시점에는 항상 3초 넘게 지나 있다. 다른 테스트가 전부 prone_confirm_s=0.5 를 써서 초록이었다. 착지(prone 시작) 시각과 비교하도록 고치고, 기본값 그대로 도는 회귀 테스트를 넣었다. R4-2 max_workers:0 이 상류 두 곳에서 막혀 있었다 — 서버 규칙 경계가 [1,50] 이라 저장이 400 이고, 엣지 파서가 v<=0 으로 규칙 전체를 무효화해 같이 넣은 2인1조까지 사라졌다. 앞 커밋에서 고친 네 곳은 전부 이 둘보다 하류라 도달 불가였다. R4-3 고소작업 프리셋(elevated)이 완전히 무동작이었다. 서버 경계에 키가 없어 400, 통과해도 엣지 파서가 침묵 삭제. 프리셋 안내문과 커밋 메시지가 시스템이 하지 않는 일을 약속하고 있었다. R4-4 동시 다발이 한 사람을 두 명으로 셀 수 있었다. 트래커는 1초 가려짐에 트랙을 버리고 새 id 를 주고(max_age=1.0) 누운 사람은 새 트랙에서도 즉시 prone 이라 두 번째 fall 이 난다. 그러면 다친 한 사람에게 "공기호흡기 없이 진입 금지"가 나가 구조가 늦어진다 — 기능의 가치가 정반대로 뒤집힌다. ghost 를 인원 집계에서 빼고, 거의 같은 자리의 사건은 같은 사람으로 본다. HIGH 5건: 구역 그룹핑 사문화(엣지가 zone_id 를 안 실어 카메라가 다른 두 희생자가 절대 안 묶였다 — 밀폐공간이 정확히 그 상황), 창 미끄러짐으로 한 사고가 매 분 새 위급 건으로 쏟아지고 인원이 줄면 앞선 알림을 스스로 뒤집던 문제, 무장 미만료·forget 누락·이중 발보, 업그레이드 안내의 마이그레이션 2개 누락(신규 유형 INSERT 가 전부 DB CHECK 에 걸린다), BUILD-INFO 커밋 스탬프. BUILD-INFO 는 1.1.0 에서 고친 R3-6 의 재발이다. 절차로 막으려다 두 번 실패했으므로 HEAD 일치를 검사하는 테스트로 막았다. README 마이그레이션 목록도 같은 이유로 테스트를 붙였다. MEDIUM 14건 중 눈에 띄는 것: 정비 억제가 SCBA 경고를 삼켰고(허가가 발급된 그 구역·그 시간이 질식이 일어나는 자리다) 위급 3종을 억제 예외로 뺐다. 데모 시더 심각도가 제품과 7종 어긋나 fall 이 위급으로 찍혀 1.2.0 의 요점인 넘어짐/추락 구분이 데모에서 지워져 있었다 — 라벨과 달리 화면이 안 깨져 눈으로는 못 잡으므로 엣지를 단일 출처로 강제하는 테스트를 붙였다. 문서의 "17종"은 실제 20종(엣지 16 + 서버 4)으로 정정하고 신규 2종을 소개서 감지 표에 넣었다. 검증: pytest 335 passed / phpunit 269 passed. 신규 테스트 30건. dist 는 이 커밋 이후 재생성한다(BUILD-INFO 가 HEAD 를 가리켜야 한다). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EBjuR7DW6PNNMows4KnbYU
13 KiB
영상 보관 정책과 노조 대응 논리
작성 2026-08-24. 법률 자문이 아닙니다 — §5의 법령 해석은 실제 협의 전에 노무사·변호사 확인을 받으십시오. 이 문서는 제품이 무엇을 하는지(§1)와 그로부터 나오는 논리(§2~§4)를 정리한 것입니다.
1. 먼저, 이 제품은 영상을 녹화하지 않는다
질문의 전제("녹화된 영상을 어떻게 할까")가 이 제품에는 적용되지 않습니다. 코드 기준 실제 동작은 다음과 같습니다.
| 무엇 | 어디에 | 얼마나 | 근거 |
|---|---|---|---|
| 프레임 링버퍼 | 엣지 노드 RAM에만 | 90프레임 = 7.5초(기본 12fps). 계속 덮어씀. 디스크에 쓰지 않음 | edge/snapshot.py RingBuffer(maxlen=90), TARGET_FPS=12 |
| 증거 스냅샷 | 서버 | 이벤트가 발생했을 때만 3장 — 이벤트 2.5초 전·1초 전·그 순간, 얼굴 블러 후 JPEG | edge/app.py SNAPSHOT_OFFSETS_S = (2.5, 1.0, 0.0) |
| 스냅샷 보관 | 서버 | 기본 7일 후 자동 삭제 | Config::snapshotRetentionDays() = 7 |
| 이벤트 기록(텍스트) | 서버 | 기본 영구 — 개인 식별 정보 없음 | Config::eventRetentionDays() = 0 |
"7.5초를 보관하는 것 아니냐" — 그 7.5초는 열람할 수 있는 화면도 API도 없고, 12분의 1초마다 덮어씁니다. 이벤트가 나야 3장이 뽑히고, 나지 않으면 사라집니다. 버퍼가 존재하는 이유는 보관이 아니라 판정 지연의 보상입니다: 넘어짐 확정에 3초가 걸리므로, 확정 시점에서 2.5초 전을 되짚으려면 그만큼은 손에 들고 있어야 합니다. 즉 사고 직전 2.5초가 남는 전부입니다.
얼굴 블러는 엣지에서, 업로드 전에 겁니다. 블러 안 된 이미지는 네트워크로 나가지 않고, 서버에 존재한 적이 없습니다. 과거 프레임은 그 프레임 자신의 머리 위치로 블러합니다(현재 위치로 블러하면 과거 얼굴이 그대로 남으므로).
또한 라이브뷰가 없습니다. 지금 누가 무엇을 하고 있는지 실시간으로 볼 수 있는 화면 자체가 제품에 없습니다.
그래서 질문에 대한 직접적인 답
"감지가 없다면 폐기하는 쪽이 맞을까?"
이미 그보다 강한 것을 하고 있습니다. 감지가 없으면 폐기하는 게 아니라, 애초에 저장하지 않습니다. 폐기 정책은 "저장은 했다"를 전제하지만, 여기서는 데이터가 생성된 적이 없습니다. 노조 앞에서 이 차이는 매우 큽니다.
2. 두 선택지 비교 — (b)는 최악의 선택이다
| (a) 감지 없으면 폐기 | (b) 용량껏 보관하되 아무도 못 봄 | |
|---|---|---|
| 성격 | 구조적 보장 — 데이터가 없다 | 행동에 대한 약속 — 안 보겠다 |
| 검증 가능성 | 저장소를 열어 보이면 끝 | 검증 불가. "안 봤다"는 증명할 수 없다 |
| 뒤집히는 조건 | 제품을 다시 만들어야 함 | 관리자 설정 하나 |
| 유출 시 | 유출될 것이 없음 | 피해 그대로 |
| 수사기관 영장 | 내줄 것이 없음 | 전량 제출 |
노조가 공격하는 지점이 정확히 (b)입니다. 노조의 불신은 "지금 사측이 볼 것이다"가 아니라 "언젠가, 다른 경영진이, 다른 목적으로 볼 수 있다" 입니다. (b)는 그 불신에 대해 "우리를 믿어달라"고 답하는 것이고, 그건 협상에서 가장 약한 카드입니다.
원칙: 존재하지 않는 데이터는 열람될 수 없고, 유출될 수 없고, 목적 외로 쓰일 수 없다. 접근 통제는 되돌릴 수 있지만 미수집은 되돌릴 수 없다.
권고 — (a). 그리고 이미 (a)를 넘어선 상태이므로, 바꾸지 말고 그대로 설명하십시오.
3. "하루치 보관해서 화재·붕괴 조짐을 보자"는 권하지 않습니다
취지는 이해합니다. 사고 원인 분석에 이벤트 전후만이 아니라 더 긴 맥락이 필요할 수 있습니다. 그러나 이 기능을 넣는 순간 잃는 것이 얻는 것보다 큽니다.
- 노조 방어 논리 전체를 잃습니다. §2의 표에서 (a)가 (b)로 바뀝니다. "우리는 녹화하지 않습니다"는 한 문장이 사라지고, 그 뒤로는 기간·열람권 협상만 남습니다.
- 법적 성격이 바뀝니다. 상시 녹화는 고정형 영상정보처리기기 규율(§5)에 정면으로 들어가고, 근참법상 '근로자 감시 설비' 성격이 뚜렷해집니다.
- 실익이 생각보다 작습니다. 붕괴·화재의 조짐 은 영상으로 사후에 판독하기 어렵고, 그건 애초에 이 제품의 감지 대상이 아닙니다(자세·구역 기반).
- 대부분의 현장에는 이미 일반 CCTV가 있습니다. 상시 녹화는 그쪽의 몫입니다. 이 제품이 녹화를 시작하면 기존 CCTV의 열등한 복제품이 되면서 고유 가치를 잃습니다. 포지션은 "기존 CCTV를 대체하는 물건"이 아니라 "기존 CCTV가 못 하는 즉시 대응을 붙이는 물건" 입니다.
- 하드웨어가 감당하기 어렵습니다. 노드당 다중 카메라 24시간치를 로컬에 쓰면 SD/SSD 수명과 용량이 모두 문제가 되고, 폐쇄망에서는 그 관리 부담이 현장에 남습니다.
사고 원인 분석은 이렇게 답하십시오 — 이 제품이 남기는 것은 영상이 아니라 타임라인입니다. 이벤트 시각·유형·위치, 전후 3프레임, 통보 이력, 조치 이력, 위·변조 탐지 감사기록. 원인 분석에 실제로 필요한 것은 대부분 이쪽이고, 영상이 꼭 필요하면 현장의 기존 CCTV에서 해당 시각을 찾아보면 됩니다 — 이 제품이 그 "몇 시 몇 분"을 정확히 짚어 줍니다.
4. 진짜 쟁점은 기간이 아니라 접근 구조다
노조 대응에서 가장 흔한 실수가 보관기간 숫자로 협상하는 것입니다.
90일 보관 + 얼굴 블러 + 모든 열람 기록 + 개인 식별 불가 << 24시간 보관 + 관리자 무제한 열람 + 기록 없음
후자가 훨씬 더 감시적입니다. 기간을 줄이는 것은 노조에게 실질적 안전장치를 주지 못하면서 사고 조사 능력만 깎습니다. 협상 카드로 내밀 것은 기간이 아니라 아래입니다.
이 제품이 이미 가진 것 (그대로 설명하면 되는 것)
- 라이브뷰 없음 — 실시간 감시 화면이 존재하지 않음
- 영상 녹화·전송 없음 — 이벤트 스냅샷 3장이 전부
- 얼굴 블러 — 엣지에서, 업로드 전에
- 개인 식별자 없음 — 사람을 임시 추적번호로만 다루고, 누구인지 모릅니다. 사번·이름·얼굴 인식 어느 것도 없습니다
- 근무태도 관련 이벤트 0종 — 감지 20종 전부가 위험 상태 이고, 자리 비움·작업 속도·휴게 시간 같은 항목은 설계상 존재하지 않습니다
- 위·변조 탐지 감사기록 — 설정 변경·확인·오탐 처리가 해시 체인으로 남아 지우거나 고치면 검증에서 드러납니다
- 스냅샷 7일 자동 삭제, 이후에는 통계와 텍스트 기록만 남음
아직 없는 것 — 보완을 권고합니다
스냅샷을 누가 열람했는지가 감사기록에 남지 않습니다. 현재 감사기록은 쓰기
동작(확인·오탐·구역 변경·설정 변경·로그인)만 기록합니다(server/src/** 의
audit->append 호출부 기준).
이것은 노조 협의에서 가장 강한 카드가 될 수 있는 항목이 비어 있는 것입니다. "아무도 함부로 보지 않는다"를 약속이 아니라 기록으로 만들 수 있습니다.
권고 3가지:
- 스냅샷 열람을 감사기록에 남긴다 — 누가, 언제, 어느 이벤트의 사진을 열었는지.
- 노조 대표에게 열람 계정(viewer)과 감사기록 조회 권한을 준다 — 감시자를 감시할 수 있게 하는 것이 불신을 푸는 가장 빠른 길입니다.
- 보관기간을 화면에 표시한다 — 설정 파일 안이 아니라 눈에 보이는 곳에.
5. 법적 근거 (참고 — 확인 필요)
5-1. 보관기간
표준 개인정보 보호지침 제41조 — 개인영상정보는 보유 목적 달성을 위한 최소한의 기간으로 보유기간을 산정하되, 그 기간을 산정하기 곤란하면 수집 후 30일 이내로 합니다. 30일이 상한이 아니라 기간을 정하기 어려울 때의 기본값 이라는 점이 중요합니다 — 목적이 명확하고 사유를 밝히면 다르게 정할 수 있습니다.
이 제품의 스냅샷 기본 7일은 그 기본값보다 짧고, "이벤트 확인·초기 대응"이라는 목적에 비추어 설명 가능한 값입니다. 7일을 늘릴 이유가 없습니다.
5-2. 사고 기록 보존 의무 — 이미지와 분리해서 보십시오
산업안전보건법 제164조는 산업재해 발생 원인 등의 기록을 3년 보존하도록 합니다. 여기서 요구되는 것은 기록이지 영상이 아닙니다.
그래서 이 제품의 설계가 두 요구를 동시에 만족합니다.
- 개인 식별 이미지 → 7일 후 삭제 (개인정보 최소보유)
- 이벤트 기록·조치 이력·감사기록 → 장기 보존 (사고 조사 대응)
노조에게는 "사진은 일주일이면 사라지고, 남는 것은 몇 시에 무슨 일이 있었다는 기록뿐"이라고 설명할 수 있고, 사업주에게는 보존 의무를 충족한다고 설명할 수 있습니다.
5-3. 노조 협의는 이기고 지는 문제가 아니라 절차 문제입니다
근로자참여 및 협력증진에 관한 법률 제20조는 "사업장 내 근로자 감시 설비의 설치" 를 노사협의회 협의 사항으로 정하고 있습니다. 설치의 주된 목적이 근로자 감시가 아니더라도, 실질적으로 감시 효과를 갖는 설비면 해당할 수 있다고 해석됩니다.
따라서 "이건 감시 설비가 아니다"라고 다투는 것은 좋은 전략이 아닙니다. 협의 대상이 아니라고 우기다가 절차 하자가 생기면, 제품의 기술적 장점과 무관하게 도입 자체가 무효화될 수 있습니다. 권고하는 순서는 다음과 같습니다.
- 협의 대상임을 인정하고 먼저 노사협의회에 올린다.
- §4의 목록을 그대로 설명한다 — 특히 근무태도 이벤트가 0종이라는 점.
- 목적 외 사용 금지를 문서로 합의한다 — 국가인권위원회는 안전·보안 목적으로 설치한 CCTV를 근무 감독에 활용한 사례를 인권침해로 판단한 바 있습니다(2017). 이 제품은 애초에 근무태도 데이터를 만들지 않으므로 지키기 쉬운 약속입니다.
- 노조에 감사기록 조회권을 준다(§4 권고 2). 합의를 검증 가능하게 만듭니다.
- 합의 내용을 회의록으로 남긴다.
참고 자료
- 표준 개인정보 보호지침 — 국가법령정보센터
- 표준 개인정보 보호지침 제41조 해설 — IT위키
- 근로자참여 및 협력증진에 관한 법률 제20조 — CaseNote
- 산업안전보건법 제164조 — CaseNote
- "CCTV 목적 외 근무태도 감독 활용은 인권침해" — 국가인권위원회 보도자료
- 사업장 내 CCTV 등 감시 설비 설치에 따른 법적 문제 — 노동연구원 웹진
6. 한 문단 요약 (노조 설명용)
이 시스템은 영상을 녹화하지 않습니다. 실시간으로 들여다보는 화면도 없습니다. 넘어짐 같은 위험 상황이 감지된 그 순간에만 사진 3장이 남고, 그 사진은 카메라 쪽에서 얼굴을 가린 뒤에 전송되며, 7일이 지나면 자동으로 지워집니다. 시스템은 그 사람이 누구인지 모릅니다 — 이름도 사번도 얼굴 인식도 없습니다. 감지하는 17가지는 전부 위험한 상태에 관한 것이고, 자리를 비웠는지 일을 얼마나 했는지는 만들 수 있는 기능 자체가 없습니다. 설정을 바꾸거나 기록을 열어 본 사람은 지울 수 없는 형태로 남고, 그 기록은 노조도 확인할 수 있게 하겠습니다.