멘토링 5회차 (26.07.17)

오전 검증 가능한 완료
멘토님은 기능을 많이 구현해도 테스트가 없으면 정상 동작한다고 보장할 수 없다고 하셨습니다. 수정 후 기존 기능에 영향이 없는지 보는 회귀 테스트가 필요하고, 버그를 발견할 때마다 임시로 고치는 방식으로는 사이드 이펙트를 통제하기 어렵다고 하셨습니다. 시간이 부족하면 범위를 줄이더라도, 선택한 핵심 기능은 테스트 결과까지 제시해야 한다고 하셨습니다. 열심히 구현했다가 아니라, 어떤 기준을 충족하면 완료인지 객관적으로 정의해야 한다는 말씀이었습니다.

요구사항 명세서의 모든 항목을 기준으로 구현 상태를 다시 점검하라고 하셨습니다. 구현 완료, 부분 구현 또는 보완 필요, 미구현으로 나누고, 구글 드라이브 엑셀에 색으로 표시하며 비고에 미완료 사유와 향후 조치를 적으라고 하셨습니다. 요구마다 대응하는 테스트 케이스가 있어야 하고, 구현하지 못한 기능은 숨기지 말고 기술적 한계와 시간 제약, 대체 구현 여부를 분명히 설명하라고 하셨습니다.

필요한 문서로는 기능 테스트 계획서, 테스트 케이스와 결과서, AI 베이스라인 리포트, 버그 목록을 말씀하셨습니다. 기능 테스트는 로그인, 분석 요청, 결과 조회, 비교 검증, 보고서, 관리자처럼 사용자 기능을 대상으로 하고, AI 베이스라인과는 별도 문서로 쓰라고 하셨습니다. 고정된 시나리오를 반복해 일관성을 보고, 버그 수정 후 관련뿐 아니라 기존 통과 항목도 재검증하며, 핵심 사용자 흐름을 우선하고, 테스트 영상은 재사용 가능한 고정 세트로 관리하며, 통과하지 못한 기능은 완료로 표시하지 말라고 하셨습니다.

우선 테스트 흐름은 비로그인 보호 경로 차단, 로그인과 역할별 화면, 업로드와 분석 요청, 비동기 진행 상태, 결과 상세, 딥페이크와 위변조와 오버레이, PDF 보고서, 블록체인과 전자서명과 CoC, 관리자와 알림 순으로 잡았습니다.

긴급 버그와 버그 관리
비로그인 상태에서 주소창으로 main에 들어가면 목업과 홍길동 화면이 보이는 문제가 긴급이었습니다. 라우트 가드와 API 인증을 함께 보고 자동화 테스트를 추가하기로 했습니다. 분석 결과 상세가 간헐적으로 무한 로딩되는 문제도 긴급이었고, 요청 상태와 캐시, 폴링 종료, 에러 처리를 점검하기로 했습니다. 영상 오버레이 위치가 해상도 처리 후 밀리는 문제도 긴급이라, 원본 좌표와 렌더링 크기 스케일, 레터박스 오프셋을 보정하기로 했습니다. 비동기 진행 화면에서 TimeSformer 계열 모델명이 빠지는 것과, 통합 후 수정이 과거 버그를 다시 만드는 현상도 높음으로 잡았습니다. 시연 영상은 버그를 피해서 찍는 것만으로 끝내지 말고, 핵심 버그를 고치고 재테스트한 뒤 제작하라고 하셨습니다.

버그가 카카오톡에만 있고 목록으로 안 관리된다는 점도 있었습니다. Jira나 공용 시트에 제목, 재현 절차, 기대와 실제, 우선순위, 담당, 원인, 수정, 재테스트, 반영일을 넣고, 수정 완료와 테스트 통과를 구분하며, 완료 전에 최초 재현과 영향 기능을 다시 테스트하라고 하셨습니다.

범위도 다시 말하셨습니다. 초기에 정한 범위를 다 하기 어려우면 우선순위를 재조정했어야 하고, 마감 직전에 테스트를 생략하고 기능을 추가하는 방식은 설득력이 부족하다고 하셨습니다. 시연을 막는 치명적 버그, 요구사항 충족에 필요한 핵심 보완, 발표 이후로 미룰 부가 기능으로 나누라고 하셨습니다.

최종 발표 자료 피드백
중간 발표 수준에 머물러 있고 실제 화면 캡처가 거의 없으며, 기능과 기술 나열만 있고 왜 만들었는지가 약하다고 하셨습니다. 헤더와 여백과 글자 크기와 톤이 일관되지 않고, 용어 설명 없이 나오고, 서비스 구성도와 시스템 아키텍처와 클라우드 아키텍처 목적이 섞여 있다고 하셨습니다.

권장 흐름은 딥페이크 시대의 증거 신뢰 문제, 기존 포렌식의 시간과 검증 한계, ForenShield가 푸는 문제, 업무 흐름과 핵심 기능, 실제 화면과 시연, AI 모델 선정과 성능 개선, 해시와 전자서명과 블록체인, 시스템과 클라우드 아키텍처, 기술적 문제와 해결, 테스트 결과와 남은 한계, 향후 계획이었습니다. 실제 화면, 요구사항 대비 구현, 테스트 계획과 결과, 알려진 한계와 미구현, 기술별 선정 배경과 대안, 수치의 지표명과 개선 전후, 용어 정의를 넣으라고 하셨습니다.

AI는 각 모델이 무엇을 탐지하는지 쉬운 말로 쓰고, 선정 이유를 논문과 벤치마크와 실험에 근거하며, Late Fusion 같은 수치가 정확도인지 F1인지 반드시 밝히고, 초기와 튜닝과 최종을 하나의 개선 스토리로 구성하라고 하셨습니다. 블록체인은 영상 본문이 아니라 증거와 보고서와 CoC 해시를 앵커링한다는 점, Fabric을 고른 이유, Evidence Hash와 Report Hash와 Merkle Root 세 앵커, Gateway와 Chaincode와 Peer와 Orderer와 Channel을 설명하라고 하셨습니다. 인프라는 서비스와 시스템과 클라우드를 구분하고, 네트워크와 보안 문제와 해결을 1에서 2개 사례로 준비하라고 하셨습니다. 향후 계획은 MLOps를 도입하겠다는 선언만 하지 말고 데이터 적재, 드리프트 모니터링, 재학습 조건, 버전과 배포, 도구 후보를 구체화하고, MLOps와 AIOps를 혼용하지 말라고 하셨습니다.

결정으로는 신규 부가보다 인증과 무한 로딩과 오버레이 등 핵심 버그를 먼저 고치고, 요구사항 전수 점검과 테스트 연결, 버그 추적, 발표에 화면과 테스트와 선정 근거 추가, 검증 안 된 성능 단정 금지, 미구현과 한계 명시를 잡았습니다.

오후 범위 조정
요구사항 색상 기준을 정리하고, 구현하지 않기로 한 항목도 행과 번호를 지우지 말라고 하셨습니다. PASS나 범위 제외로 남기고, 제외 사유와 협의 일자와 합의 주체와 향후 가능성을 비고에 적으라고 하셨습니다. 립싱크는 음성을 범위에서 뺀 뒤라 맞지 않으니, 삭제하지 말고 합의에 의한 범위 제외로 두고, 구현 실패가 아니라 분석 범위 변경에 따른 제외라고 발표와 문서에 쓰기로 했습니다.

우선순위는 최종 발표 자료와 스토리라인, 필수 제출 문서, 시연을 막는 핵심 버그, 시연에 필요한 기능 보완, 낮은 우선순위 기능 순이었습니다. 시연에 안 나오고 핵심 가치를 안 바꾸는 표기 누락은 발표와 문서보다 앞세우지 말라고 하셨습니다.

상세페이지에서는 Recovery Score 표시, CoC 주요 이벤트 보완, 결과 정합성, 메타데이터와 코덱 정보를 구현하기로 했고 정합성은 최우선이었습니다. Evidence Manifest 요약 카드, 블록체인 익스플로러 링크, 정상과 의심 구간 비교 화면, PDF QR, 일부 관리자 통계, 3초 응답 검증, 크로스 브라우저 전체 검증 등은 이번 범위에서 제외하고 명세서에는 사유와 함께 남기기로 했습니다.

분석 결과 정합성도 크게 짚었습니다. 기준 초과 신호 1/4 같은 숫자가 정상 위험 판정과 안 맞을 수 있고, 딥페이크 4개 신호는 개별 모델 셋과 Late Fusion 하나라는 설명이었습니다. 정상인데 1/4이면 사용자가 하나가 위험이라고 오해할 수 있다고 하셨습니다. 코드와 API로 의미를 확인하고, 임계값 초과를 실제로 집계하며, 정상 판정과 문구가 맞는지 테스트하고, 위험도와 확신도를 구분하며, 시연 전 여러 영상으로 상세 수치를 검증하기로 했습니다.

발표 전략은 무엇을 만들었는지, 어떤 문제를 푸는지, 핵심 기능과 성과가 첫 부분에서 바로 보이게 하고, 대화형보다 기승전결로 가며, 한 것과 성과와 하지 못한 것과 향후 계획을 구분하라고 하셨습니다. 시연은 기능 목록이 아니라 시나리오를 먼저 확정하고, 보여줄 화면만 안정화하며, 핵심을 방해하는 버그는 반드시 고치고, 수정이 끝난 뒤 촬영하라고 하셨습니다.

팀 회의 시연과 스토리
시연 영상은 GPU 데이터셋에서 딥페이크와 위변조를 함께 설명할 사례를 찾고, 없으면 영상을 둘로 나누기로 했습니다. 모델 약점을 숨기기보다 각 모델이 탐지하도록 설계된 대상과 결과를 맞춰 설명하기로 했습니다. 순서는 로그인, 사건과 증거 업로드, 분석, 상세와 오버레이, CoC와 무결성, 비교 검증, 승인 전 PDF 비활성, 승인 후 PDF, 관리자 감사 로그와 CoC, 필요하면 CSV 다운로드로 잡았습니다. 관리자는 초대와 승인, 감사 로그, CoC, CSV를 짧게 보여주되 포렌식 감사 통제 역할로 설명하기로 했습니다. 전체는 배속으로 약 1분 내외로 압축하기로 했습니다.

발표 스토리는 딥페이크와 위변조 증가, 법정 증거의 원본성과 무결성, 취급 이력 추적, 기존 분석의 시간과 도구 분산, ForenShield의 통합 파이프라인을 먼저 제시하기로 했습니다. 문제와 솔루션을 대응시키고, 시간 단축은 앞에서 제기한 문제에 이어서만 성과로 말하기로 했습니다.

AI는 위조 유형마다 관찰할 특징이 다르다는 점부터 쓰고, Xception은 공간과 얼굴, TimeSformer는 시간, GMFlow는 광학 흐름, TruFor는 국소 변조, Temporal은 구간 편집으로 설명하기로 했습니다. 후보와 데이터셋과 벤치마크를 비교한 선정 근거를 넣고, AUC는 단순 정확도가 아니라 여러 판정 기준에서 진짜와 가짜를 얼마나 안정적으로 구분하는지, 0.5는 무작위, 1에 가까울수록 좋다고 설명하기로 했습니다.

블록체인은 Backend에서 Gateway, Fabric chaincode, World State와 Ledger 순으로 가고, 원본 파일이 아니라 해시와 메타와 오프체인 포인터만 저장한다고 쓰기로 했습니다. Evidence Hash와 Report Hash와 Merkle Root는 타입별 키로 구분된 레코드라고 설명하고, HLS 영상 보호와 SHA와 서명과 Fabric 앵커는 목적이 다르니 한 장에 과도하게 합치지 않기로 했습니다.

PPT는 Canva에서 구성한 뒤 PowerPoint에서 애니메이션과 배치를 마무리하고, Noto Sans KR로 통일하며, 제출 전 PPT와 PDF를 모두 검수하기로 했습니다. 향후 계획은 MLOps로 용어를 통일하고 AIOps와 혼용하지 않기로 했습니다.

다음까지 할 일
핵심 버그인 인증과 무한 로딩과 오버레이, 상세페이지 정합성과 Recovery Score와 CoC 이벤트를 우선합니다. 요구사항 명세서는 색과 상태로 전수 점검하고 제외는 사유와 함께 남깁니다. 시연 시나리오와 발표 스토리, 필수 제출 문서를 병행하고, 주말에는 멘토링 일지와 데일리, 데이터 카탈로그, baseline, 통합추론 파이프라인, 단위테스트 결과, 최종 발표 자료, 시스템 아키텍처와 서비스 구성도 등을 나눠 준비하기로 했습니다.

소감
5회차에서 가장 크게 남은 말은, 기능을 많이 만든 것보다 검증 가능한 완료 기준이 우선이라는 점이었습니다. 마감 직전에는 부가 기능을 더하기보다 시연을 막는 버그와 결과 정합성과 발표 스토리를 먼저 잡기로 했습니다. 구현하지 못한 것은 지우지 말고 합의된 제외로 남기고, 최종 발표는 왜 필요한가에서 어떻게 검증되는가까지 한 흐름으로 개편하기로 했습니다.