브리프에 "언제 감지되는가"에 답하는 이미지가 하나도 없었다. 쓰러진 사람
'사진'을 부적절하다고 제외하면서 '감지 시점을 설명하는 그림'까지 함께
빠졌다. 둘은 다르다 — 일러스트로 그린 사고 장면은 프라이버시 제약과
충돌하지 않고, 안전 자료에서는 표준 표현이다.
신설 §B (감지 장면) 4종:
- 08-넘어짐-감지-시퀀스: 상태기계를 그림으로. 1초(위험 자세) → 3초(확정)
→ 10초(미동 없음), ②에서 회복 시 니어미스 분기. 전체 최우선.
- 09-앉기-vs-넘어짐: 도입 검토 첫 질문("앉으면 울리냐")에 대한 답
- 10-위험구역-판정: 판정 기준이 몸통이 아니라 발 위치라는 점 + 0.75초
- 11-2인1조: 인원 수 기반 규칙 (30초)
수치·판정 조건은 edge/detectors/{fall,zone,occupancy}.py 실코드값으로
확인해 적었다. 그림이 제품과 어긋나면 영업 문서에 거짓을 싣는 것이 된다.
기존 B(다이어그램)→C, C(정리)→D, D(제외 목록)→E 로 재번호.
E의 '실제 프레임 제외' 항목에는 일러스트는 포함했다는 단서를 남겨,
나중에 판단이 뒤집힌 것으로 읽히지 않게 했다.
기존 소개서의 문제는 문장이 아니라 구조와 최신성이었다.
- 기대효과 섹션이 아예 없었다. 기능 목록만 있고 "그래서 뭐가 달라지나"가 없었다.
- 왜 만들었나가 4문장이었다. 이미 CCTV 가 있는 현장이 왜 또 사는지에 답하지 못했다.
- 내용이 0.9.0 시점이었다. 1.0.0 의 핵심인 통보·에스컬레이션이 로드맵에 "P3 예정"으로
적혀 있었고 테스트 320건·감사 43항목도 옛 수치였다 — 완성된 기능을 미완성으로 소개하는
문서가 고객에게 나갈 뻔했다.
재작성
- 기능 나열을 버리고 감지 → 대응 → 증거의 사슬로 재구성. 어느 한 칸이 비면 나머지가
무의미해진다는 것이 이 제품의 논지이므로 문서 구조도 그래야 한다.
- 왜 만들었나를 "CCTV 는 이미 있는데 왜 사고를 못 막나" 세 가지(아무도 안 본다 / 발견이
늦다 / 증명할 자료가 없다)로 세우고, 각각에 대응하는 답을 표로 연결.
- 기대효과 신설. 지어낸 ROI 대신 **제품이 스스로 계측해 보여주는 지표**(TTA, 니어미스:사고,
조치 전후 밀도, 오탐율)로 썼다 — 공급자 주장이 아니라 고객 화면의 숫자다.
'약속하지 않는 것' 절을 함께 넣었다. 사고를 없애지 못하고, 감지율 100%는 없고, 오탐은
초기에 반드시 난다. 과장은 도입 후에 반드시 되돌아온다.
- 설계 제약(감시하지 않는다 / 인터넷 없이 동작한다 / 클라우드를 안 쓴다)을 기능보다 앞에
두었다. 이 제품의 형태는 거기서 나왔다.
수치는 전부 코드와 대조해 교정
- 테스트 535건(pytest 311 + PHPUnit 224), 감사 55건, 감지 17종 + 서버 발행 1종
- "3초 안에 찾아낸다"는 과장이었다. 실제로는 쓰러진 자세가 3초 지속되면 확정이므로
"3초면 알아채고"로 고치고, 근거가 되는 3초를 감지 표에 함께 적었다.
이미지 브리프 신설 (docs/소개서-이미지-브리프.md)
- 현장 사진 4장 + 다이어그램 3장의 발주 명세. 각 항목에 "이 이미지가 없으면 전달 안 되는
것", 담을 것, 피할 것, 사양, 캡션안, 우선순위.
- 제품 화면 캡처 8장은 이미 확보되어 있어 발주 대상에서 제외.
- 개인정보 제약을 최상단에 명시. 얼굴이 식별되는 작업자 사진이 한 장이라도 들어가면
"감시하지 않는다"는 이 제품의 핵심 주장이 무너진다.
- 검토했으나 뺀 이미지(쓰러진 순간 프레임, 블러 전/후 비교, 스켈레톤 오버레이)와 그 이유도
기록. 나중에 "왜 없지"가 반복되지 않도록.
HTML 은 md-to-html-report 로 재생성(목차·표·콜아웃·인쇄 스타일). 실렌더 확인.
