멘토링 3회차 (26.06.27)

오전 발표와 자료 피드백
발표 중 이제라는 습관어가 잦아서, 팀끼리 서로 지적하고 스크립트를 점검하기로 했습니다. 스크립트 기반 발표는 좋다고 하셨지만 구두 습관어는 따로 관리하라고 하셨습니다.

슬라이드는 Canva보다 PowerPoint로 옮기라고 하셨습니다. 애니메이션과 호환성 이슈 때문이었습니다. 표지가 빠져 있어서 추가해야 하고, 개요와 프로젝트 개요, 수행 경과처럼 섹션 제목과 위치, 번호 체계가 제각각이라 통일하라고 하셨습니다. 텍스트는 양쪽 정렬, 단어 중간 줄바꿈 방지, 줄바꿈으로 가독성을 살리라고 하셨고, 다이어그램의 불필요한 꺾임과 화살표, 아이콘 크기도 다듬으라고 하셨습니다. 브랜드명은 메인메모가 아니라 ForenShield로 통일하기로 했습니다.

콘텐츠 구조는 배경, 문제, 솔루션 목표, 차별화 전략 순으로 다시 짜라고 하셨습니다. 차별화 앞에 기존 솔루션 대비 우리 목표와 접근 슬라이드가 없다고 하셨고, 차별화는 남들이 안 하는 기능이 아니라 여러 기능을 단일 플랫폼으로 통합한다는 관점으로 쓰라고 하셨습니다. CoC 표기도 소문자 CoC로 맞추라고 하셨습니다.

증거 등록과 비교 검증 흐름
1차 딥페이크 분석 흐름은 파일 업로드 후 업로드와 분석 시작 버튼, S3 저장, SHA-256 해시, 전자서명, 블록체인 해시 앵커, 다시 분석 시작을 눌러 RabbitMQ로 AI 분석, PDF 리포트로 이어진다고 설명했습니다. 멘토님은 드래그앤드롭과 사건명, 분석 시작이 한 화면에 있어 블록체인 진입 시점이 불명확하다고 하셨습니다. 파일 등록과 분석 시작을 한 세트로 분명하게 표현하고 구현하라고 하셨습니다.

블록체인 앵커는 세 가지로 정리했습니다. Evidence Hash Anchor는 업로드 증거 파일 해시로 이미 구현됐고, Report Hash Anchor는 PDF 리포트 해시로 추가 예정이며, Daily CoC Log Merkle Root는 전일 CoC 로그를 합친 Merkle Root로 추가 예정입니다. Daily CoC Log는 DB에 쌓인 CoC 이력을 합쳐 Merkle Root를 만들어 S3와 DB 변경을 추적하려는 목적입니다. 아키텍처 도에 세 종 앵커와 데이터 출처를 넣고, 해시 앵커 용어도 분명히 하라고 하셨습니다.

2차 위변조 검증은 딥페이크와 별도 메뉴, 별도 플로우입니다. 비교 검증 메뉴에서 등록된 사건을 고르고, 1차 분석이 끝난 Evidence를 원본으로 선택한 뒤, 제출본을 새로 올려 해시와 서명 후 원본과 비교합니다. 원본은 1차 딥페이크 분석 때 등록되어 블록체인에 저장된 Evidence이고, 제출본은 검증 때 새로 올리는 파일입니다. 제출본에도 전자서명과 해시는 필요하고, 블록체인 앵커까지 갈지는 설계를 다시 보기로 했습니다. 서비스 구성도에 검증 전용 등록 경로를 따로 넣어야 하고, 현재 다이어그램은 흐름이 부정확하다고 하셨습니다. FastAPI와 GPU 표기는 AI 분석 큐잉 정도로 단순화하라고 하셨습니다.

Case와 Evidence 관계도 짚었습니다. 사건명은 직접 입력보다 등록된 사건을 콤보박스로 고르는 UX가 낫고, 사건 관리 페이지를 따로 두어 사건을 먼저 등록한 뒤 분석 때 선택하라고 하셨습니다. S3 저장명은 caseId, evidenceId, version처럼 체계적으로 짓기로 했습니다. Evidence 삭제는 물리 삭제가 아니라 Soft Delete로, 포렌식 무결성과 CoC, 블록체인 이력을 남기라고 하셨습니다.

WBS, 화면, AI 발표 자료
RQ, PR 같은 ID 의미가 불명확해서 팀 컨벤션을 문서화하고 슬라이드에 반영하기로 했습니다. WBS에서 Jira로 등록은 됐지만, Jira를 고칠 때 WBS에 다시 반영하는 일은 안 되고 있었습니다. 스프린트 뷰만으로는 전체 일정과 잔여가 안 보이니 간트나 전체 진행률 뷰를 검토하라고 하셨습니다.

UI에서는 업로드를 영상만 허용하고 이미지는 빼며, ForenShield 브랜드를 적용하기로 했습니다. 분석 상세는 딥페이크 결과 전용, 무결성 검증은 검증 결과 전용으로 나누고, 검증은 Case에서 Evidence, 제출본 업로드 순서를 지키며 삭제된 Evidence는 고를 수 없게 하라고 하셨습니다. 한 페이지에 정보가 너무 많아 탭이나 분할 레이아웃으로 개선 중이라고 공유했습니다.

AI 수행 경과 슬라이드에서는 딥페이크 판별 카테고리라는 말보다 판별 기준이나 판별 관점, 추론 축처럼 분명히 쓰라고 하셨습니다. 벤치마킹 데이터 구축은 골든셋 구축으로 바꾸고, Train Test 6대4 표현은 골든셋이 학습에 절대 안 들어가므로 철저 분리로 고치라고 하셨습니다. S3 추론은 AI 생성 오류라 지우라고 하셨고, 위변조 3지 착수 같은 말도 위변조 검증 기능 착수처럼 명확히 하라고 하셨습니다. CNN, Temporal, Optical(GMFlow) 3축은 유지하되, CNN Transformer GNN 비교 그림은 출처가 없고 설명과 안 맞아 지우거나 적절한 자료로 바꾸라고 하셨습니다. 다음 주까지는 AI 성능 고도화, 3모델 Late Fusion 설계, 위변조 검증 고도화에 집중하기로 했습니다.

인증과 권한도 아직 발표에 안 나왔다고 하셨습니다. 최종 발표 Q&A에서 인증 없이 증거 등록과 삭제가 되냐는 질문이 나올 수 있으니, 분석 요청, 비교 검증, 이력 조회처럼 권한을 나누고 CoC에 행위자를 남기라고 하셨습니다.

오후 시연과 아키텍처
오후에는 실제 UI를 보며 상세 페이지 피드백이 이어졌습니다. 증거 선택이 별도 화면 없이 상세에서 바뀌고, 왼쪽 리스트 효과가 불명확하니 상단 콤보박스나 파일 리스트로 바꾸라고 하셨습니다. 분석 요약, 딥페이크 상세, 무결성 검증을 한 화면에 몰지 말고, 모델별 점수와 프레임 위험도, 대표 프레임, 탐지 근거는 별도 레이어로 빼라고 하셨습니다. 우상단 테스트 사용자 표시도 인증과 역할과 맞춰야 한다고 하셨습니다. 로그인과 초대코드 가입, 관리자 페이지는 있지만 역할별 기능 분리는 더 정리하고, 중간 발표에 인증 이야기가 없었으니 최종 Q&A용 설명을 준비하라고 하셨습니다.

문서 종류도 다시 정의하셨습니다. 서비스 구성도는 ForenShield가 무엇을 하는지이고, 시스템 아키텍처는 컴포넌트와 인터페이스, 데이터 위치, 계층 통신이며, 클라우드 아키텍처는 그걸 AWS에 어떻게 올렸는지입니다. 시스템 없이 클라우드만 있으면 안 되고, 클라우드가 시스템을 대체할 수 없다고 하셨습니다.

구글 드라이브 자료에는 RabbitMQ가 빠져 있고, Fabric EC2 표기가 불명확하며, CoC 로깅 흐름이 부족하고, PyTorch 위치가 어색하며, 온프레미스 표기는 Site to Site VPN으로 고치고, 무결성 3웨이 비교 위치도 다시 잡으라고 하셨습니다. 횡단 관심사에 무결성 인증과 Multimodal AI를 넣은 것은 틀렸고, 로깅, CoC, 인증이 횡단 관심사라고 하셨습니다.

클라우드 도에서 Argo CD를 AWS 밖에 그린 것도 잘못이라고 하셨습니다. Argo CD는 EKS 안 argocd 네임스페이스에 있고, CI/CD 전체를 클라우드 도에 넣기보다 별도 배포 파이프라인으로 두거나 EKS 안에 표기하라고 하셨습니다. Pod만 그리기보다 Deployment와 Pod 구조를 쓰고, Frontend는 Nginx와 Next.js, Backend는 Spring Boot, RabbitMQ와 AI FastAPI, Fabric EC2를 반영하라고 하셨습니다. AI 생성본을 검증하고 AWS 공식 스타일로 직접 다시 그리되, 초안이 아니라 최종 제출 기준으로 고치라고 하셨습니다.

블록체인은 설치했습니다로 끝내면 안 되고, Peer와 Orderer와 Channel이 몇 개인지, Chaincode가 무엇을 기록하는지, Gateway가 어떤 org identity로 invoke하는지, test network PoC 한계는 무엇인지 설명할 수 있어야 한다고 하셨습니다. AI와 블록체인 모두 결과만이 아니라 과정과 근거와 이해가 중요하고, AI 생성 자료는 팀이 검증한 뒤 쓰라고 하셨습니다.

딥페이크와 위변조 경계
팀이 처음에는 1차를 얼굴과 신체 딥페이크 3축 앙상블, 2차를 TruFor 같은 객체 생성 삭제와 프레임 편집, 재압축 탐지로 나누려 했고, 1차에 모델을 다 넣으면 무거워서라고 설명했습니다.

멘토님은 비교 검증 페이지의 본질은 등록된 원본과 새로 올린 제출본을 해시, 전자서명, 블록체인, CoC로 같다 다르다 보는 것이라고 하셨습니다. 픽셀 단위 편집을 AI로 다시 찾는 곳이 아니라고 하셨습니다. 재압축해서 눈으로 같아 보여도 해시가 다르면 원본과 다름이 되고, 그 비교는 해시와 원본 대조로 충분하다고 하셨습니다.

객체 생성과 편집 탐지는 2차 위변조에 TruFor를 넣기보다 설득력이 약하고, 1차 딥페이크 안에 단계를 나누거나, 위변조 메뉴는 원본 무결성 비교만 두는 방향을 권하셨습니다. 증거 중요도와 리소스에 따라 1단계만, 2단계까지, 3단계까지 선택 실행하고, 못 한 단계는 향후 계획으로 명시하라고 하셨습니다.

영상 컨텍스트인 코덱, 블러, 블록, FFT PEAK는 모델 입력 가중치나 라벨이 아니라 사전 경고와 결과 각주라고 정리했습니다. 분석 요청 파이프라인은 코덱, 컨텍스트 검사, 딥페이크, 위변조, JSON 순서이고, 비교 검증 메뉴의 해시 비교와 혼동하지 말라고 하셨습니다.

Fake Score와 확정된 AI 파이프라인
Fake Score는 모델이 내는 딥페이크일 확률 점수이고, Threshold는 보고서에서 진짜와 가짜를 나누는 팀 튜닝 기준선이며, Confidence는 예측 확신도로 Fake Score와 별개라고 정리했습니다. 사용자에게 딥페이크 20퍼센트처럼 보일 때 확률 점수인지 최종 판정인지 문구가 필요하다고 하셨습니다. 점수가 엉망이면 억지 판정보다 판독 불가가 낫다는 이야기도 나왔습니다.

초기에는 블러, 블록, FFT를 High Low로 나눠 8리전을 만들고 리전별 모델과 가중치를 관리하자는 구상도 있었지만, 4주 반과 GPU로는 8모델 학습이 사실상 어렵고, 블러가 심하다고 전부 Fake로 몰리면 안 된다고 했습니다.

오후 합의로 MVP 파이프라인은 이렇게 확정했습니다. 먼저 코덱을 추출하고, 블러와 블록 깨짐과 FFT PEAK를 OpenCV로 계산합니다. 임계값을 넘으면 사용자에게 경고하고 계속할지 확인한 뒤 진행합니다. 경고는 중단이 아니라 동의 후 다음 단계입니다. 그다음 clean 데이터로 학습한 모델로 딥페이크를 먼저 추론하고, 이어서 편집과 생성 위변조를 추론한 뒤 JSON으로 모읍니다. 학습은 깨끗한 영상 기준으로, 딥페이크와 위변조 데이터를 분리합니다. 8리전별 모델과 AI Ops는 향후 계획으로 두고, 현재는 clean 모델과 순차 추론과 JSON입니다. 비교 검증 해시 기능과 편집 AI 탐지는 별개로 유지합니다.

프론트는 공공기관형으로 단순하고 명확하게, 영어 잔여 문구를 한국어로 정리하고, Admin과 일반 서비스를 라우트로 분리하기로 했습니다. 인프라는 Terraform EKS park wake 스크립트는 됐고, 클라우드 아키텍처는 다음 주 화요일 전 AWS 공식 스타일로 다시 그려 제출하기로 했습니다.

팀 운영에서는 작업물을 팀장에게 안 공유하는 문제를 짚었고, 완료 시 반드시 공유하고 검수하며, 아침 짧은 스탠드업으로 전날 작업과 당일 계획을 나누자고 하셨습니다. AI 생성 자료는 발표 전에 팀장 확인을 필수으로 하기로 했습니다.

다음 주까지 할 일
서비스 구성도의 검증 플로우를 분리해 다시 쓰고, 업로드 버튼과 분석 시작의 블록체인과 S3 진입 시점을 코드와 UX로 맞춥니다. 사건 선택형 UX와 Soft Delete, S3 네이밍, 앵커 3종과 CoC Merkle Root 계획을 정리합니다. AI는 판별 기준 용어 수정, 골든셋 슬라이드 수정, 코덱에서 컨텍스트, 딥페이크, 위변조, JSON 파이프라인 구현, clean 데이터 분리 학습 문서화, Fake Score와 Threshold와 Confidence 정의를 진행합니다.

인프라는 시스템 아키텍처와 클라우드 아키텍처를 다시 그리고, Argo CD는 EKS 안에, Fabric은 peer orderer channel 토폴로지와 구성 설명을 준비합니다. 발표 자료는 PPT로 옮기고 표지와 섹션을 통일하며, 배경 문제 솔루션 목표 차별화 슬라이드를 넣습니다. 아직 미결인 딥페이크와 비교 검증 페이지 분리 여부, 단계 완료 조건, Threshold와 컨텍스트 임계값, 판독 불가 기준, JSON 스키마는 이어서 확정합니다.

소감
3회차에서 가장 크게 남은 말은, 비교 검증은 해시와 원본 대조이고 위변조 AI를 또 돌리는 곳이 아니라는 점과, 할 수 있는 것만 하고 못 하는 것은 억지 판정하지 말라는 점이었습니다. 8리전 같은 큰 그림은 향후 계획으로 두고, clean 모델과 순차 추론과 JSON으로 MVP를 고정한 것이 이번 합의의 핵심이었습니다. 중간 발표 교훈을 살려 자료 검증과 과정 설명, 아키텍처 재작성부터 다시 잡아가기로 했습니다.