[ForenShield] 2차 멘토링 회의록 — 서비스 구성도 재정의 & RTM 매핑

[ForenShield] 2차 멘토링 회의록 — 서비스 구성도 재정의 & 요구사항 추적 체계

복사 안내: 아래 전체를 그대로 티스토리 에디터에 붙여넣으시면 됩니다.
(HTML 모드 사용 시 <br> 대신 줄바꿈 그대로 사용해도 무방합니다.)

---

📌 회의 개요

항목내용

프로젝트명	ForenShield (포렌실드) — AI 기반 디지털 포렌식 증거 분석 시스템
회의 차수	2차 멘토링
일시	2026년 6월 13일 (토)
참석	멘토님, 팀원 전원
주요 주제	서비스/시스템 구성도 피드백, 요구사항 정의서·지라 백로그 매핑, WBS 일정 관리

회의 목적
현재 기획·구현 현황을 점검하고, 프로젝트의 핵심 기능·무결성 보장 방식·AI 모델 운영 방향·서비스 구성을 구체화하기 위함.

---

💡 한 줄 요약

"딥페이크 탐지 도구"가 아니라, "법적 증거 활용까지 고려한 디지털 포렌식 검증 플랫폼"으로 프로젝트를 재정의해야 한다.

클라우드 인프라(AWS)를 먼저 그리기 전에, **서비스가 무엇을 증명하는지(Who, What)**부터 명확히 정의하라는 것이 이번 멘토링의 핵심 메시지였다.

---

🔥 핵심 요약 (Key Summary)

1. 서비스 구성도 — 단순하게, 본질만

• AI로 생성한 복잡한 인포그래픽·아키텍처 그림은 정보가 과밀해 제3자(평가위원, 고객)가 핵심을 파악하기 어렵다.
• 회원가입·게시판 등 부가 기능은 생략하고, 메인 피처 2가지만 명확히 표현할 것.
• KISS / YAGNI 원칙 적용 — 하기로 한 핵심 기능만 심플하게 구현.

2. 추적성 매핑 Matrix — 반드시 구축

• 요구사항 정의서(노션) ↔ 지라(Jira) 백로그 ↔ 테스트 케이스가 따로 놀고 있음.
• RQ-001, FR-001, TC-001 등 ID 기반 상호 연결(RTM) 없이는 구현 누락·검증 실패 리스크 발생.

3. WBS 일정 — 세분화 & 현행화

• 6~7일 단위 덩어리 일정은 진척도 공유가 불가능.
• 2~3일, 가급적 일 단위로 태스크 분할.
• WBS 0% 방치, 지라 타임라인 미반영 상태 개선 필요.

---

📋 주요 논의 내용

1) 작업 순서가 잘못되었다 — 인프라보다 서비스가 먼저

멘토 지적 사항

• 서비스가 어떻게 작동하는지에 대한 그림(피그마, 스케치 등) 없이 클라우드 배포도만 먼저 가져옴.
• "예쁜 인프라 그림"보다 **"왜 이 구조가 맞는지 설명 가능한 프로젝트"**가 되어야 함.

올바른 설계 순서

1. 서비스 구성도 → 사용자가 어떤 기능을 어떻게 쓰는지 (Who, What)

2. 시스템 아키텍처 → 통신 프로토콜, API, Queue, 인터페이스

3. 클라우드 인프라 → AWS EC2/EKS/S3 등 최종 배포 방식

---

2) 프로젝트 핵심 기능 2축 재정의

멘토님 피드백으로, 지금까지 혼재되어 설명되던 기능을 아래 2축으로 명확히 분리하기로 했다.

기능 1 — 증거 등록 & 딥페이크 탐지 (업로드 시점 분석)

단계내용

①	사용자가 파일(영상·음성·이미지) 업로드
②	딥페이크/합성·조작 가능성 AI 분석
③	SHA-256 해시 생성 + 디지털 서명 적용
④	원본 기준 파일을 S3 등 스토리지에 안전 보관
⑤	CoC(Chain of Custody) 감사 로그 기록

→ **"이 파일이 처음부터 조작됐을 가능성이 있는가?"**를 판단하는 기능

기능 2 — 위변조 검증 (원본 대비 비교)

단계내용

①	검증 대상 파일 제출 (수사기관·제3자 소지본)
②	제출본 SHA-256 산출 → 등록 해시와 대조
③	등록 증거·CoC 이력 교차 확인
④	무결(일치) / 변조·치환(불일치) / 검증 불가 판정
⑤	사법 제출용 PDF 보고서 출력

→ **"저장 이후 변경이 있었는가?"**를 판단하는 포렌식 검증 기능

비교 검증 상세 프로세스 (멘토님 정리)

원본 업로드 → 딥페이크 분석 → 해시+서명 → 원본 저장

↓

추후 비교 대상 업로드 → 복사본 동일 기준 처리 → 원본과 비교 → 차이점 리포트

⚠️ 서명된 원본과 서명 없는 파일을 그대로 비교하면 안 됨.
비교 대상도 동일한 방식으로 처리한 후 대조해야 논리적으로 타당함.

---

3) 무결성 보장 — 해시만으로는 부족하다

팀이 설명한 방식: 업로드 즉시 SHA-256 생성 → S3 저장 → DB 해시 체인 감사 로그

멘토 핵심 피드백

한계보완 필요 요소

해시만으로는 "누가 만들었는지" 설명 불가	디지털 서명
원본성·법적 신뢰 근거 부족	감사 로그 (CoC)
"자동화된 무결성 인증 체인"이 추상적	이벤트별 연결 방식·서명 위치·검증 비교 대상 구체화
저장만으로는 증빙 불충분	검증 API/리포트, 레저·블록체인 구조 검토

무결성 보장 구조 (보완 방향)

• ✅ 해시값 생성 (SHA-256)
• ✅ 디지털 서명 적용
• ✅ Chain of Custody 기반 로그 관리
• ✅ 변경 불가능한 저장/레저 구조 검토
• ✅ 검증 시각화 및 검증 리포트 제공

저장 구조 관점

• S3 = 파일 저장소 (Object Lock·WORM은 보조 수단)
• 무결성 증빙 = 별도 레저/체인/서명 구조
• "왜 이 구조가 더 적절한가"를 설명할 수 있어야 함

---

4) C2PA 및 표준 기술 벤치마킹 필요

멘토님이 C2PA(Content Provenance and Authenticity) 표준을 언급.

향후 문서에 포함할 내용:

• C2PA가 무엇인지
• 우리 프로젝트와의 접점
• 기존 표준/솔루션이 해결하지 못한 문제
• 우리 팀의 차별화 포인트

→ 경쟁력은 기능 나열이 아니라 **"기존 표준을 이해한 상태에서 왜 이 설계를 선택했는가"**를 설명하는 것.

---

5) UI/서비스 플로우 — 비교 검증 화면 분리 필요

현재 문제

• UI가 '첫 업로드' 중심으로만 구성됨
• '비교 검증' 플로우가 별도 설계되어 있지 않음

멘토 가이드

• 첫 등록 화면 ≠ 비교 검증 화면 → 사용자 목적이 다르므로 분리
• 비교 검증 진입: 단순 업로드 재사용 ❌ → 분석 기록/증거 목록에서 원본 선택 후 비교 작업 진입 ✅
• 상세보기, 비교 결과, PDF 보고서 화면 기획 보완 필요

---

6) PDF 포렌식 리포트 — "항목 있음"이 아니라 "근거 설명"이 핵심

리포트가 답해야 할 질문:

• 이 파일은 왜 의심되는가?
• 어느 구간에서 어떤 근거가 검출되었는가?
• 저장 이후 변경 여부는 어떻게 판단했는가?
• 어떤 모델/버전/해시/로그가 근거인가?

---

7) AI 모델 운영 — 감이 아니라 프로세스

멘토 조언: AIOps / MLOps / DevSecOps 관점

필요 항목내용

골든셋	고정된 테스트셋 구축
비교 실험	동일 조건 성능 비교
지표 관리	정확도 + 오탐/미탐
버전 관리	모델 버전·교체 기준
승인 프로세스	Human-in-the-loop 검토

---

8) MVP 범위 조정 — 영상 우선, 음성은 후순위

• 한국어 음성 데이터셋 부족 → 음성까지 무리하면 완성도 리스크 큼
• 영상 중심 MVP 먼저 완성, 시간 남으면 확장
• AI가 코드는 빨리 짜줘도, 팀이 구조와 원리를 이해하지 못하면 의미 없음

---

9) 서비스 구성도에 반드시 들어갈 요소

멘토님이 요청하신 서비스 구성도 필수 포함 항목:

• 데이터 타입: 음성, 영상, 이미지
• 권한 분리: 일반 사용자(업로드) vs 관리자(승인·제어)
• 핵심 프로세스:
  파일 업로드 → 원본 저장·해싱 → (딥페이크 탐지) → 위변조 비교 매칭 → 결과 리포트

시스템 구성도 레이어 (기술 스택)

클라이언트(React/Next.js)

↓

API (Spring Boot)

↓

서비스 (무결성 엔진 · 탐지 엔진 · 보고서 생성)

↓

데이터 계층 (S3 · PostgreSQL · 레저/블록체인)

---

📊 멘토 피드백 핵심 정리

보완 항목멘토 피드백 요지

무결성 설명	해시만으로 부족, 서명·감사로그·검증 방식 필요
서비스 목적	딥페이크 탐지 vs 위변조 검증 분리 설명
차별화 전략	기능 나열 ❌ → 기존 기술 대비 강점 ✅
UI 플로우	첫 업로드 / 비교 검증 별도 화면
표준 검토	C2PA, CoC, 블록체인 벤치마킹
AI 운영	골든셋·버전관리·평가 프로세스 문서화
범위 설정	음성 무리 ❌ → 영상 MVP 우선
작업 순서	인프라 먼저 ❌ → 서비스 구성도 먼저 ✅
산출물 연결	요구사항 ↔ 지라 ↔ 테스트 RTM 매핑

---

 

⚠️ 리스크 & 유의사항

1. 범위 과다 vs 설명 가능성 부족 — 가장 큰 리스크
2. 실험 수치 혼선 — 발표·문서에 실험 로그 기준 정리된 표 필수
3. AI 의존 + 이해 부족 — 구현 속도보다 "왜 이렇게 설계했는지" 설명력이 중요
4. 산출물 단절 — 요구사항·지라·테스트 연결 없으면 계약·검증 리스크

---

📝 다음 멘토링 전 준비물 (3가지)

#준비물설명

1	서비스 구성도	사용자 관점 흐름·역할 구성 (인프라보다 먼저)
2	핵심 기능 정의 문서	기능 2축별 입력·출력·결과 화면 정리
3	무결성 보장 설명 자료	해시·서명·CoC·검증·저장 구조를 1장으로 설명 가능하게

---

🏁 팀 회고 한 줄

그동안 AI가 뽑아준 복잡한 그림에 갇혀, 정작 중요한 **서비스의 본질(Who, What)**과 **산출물 간 연결고리(RTM)**를 놓치고 있었다. AI가 많은것을 대체해주지만 우리 또한 우리가 무엇을하는지 진행되고있는 상황이 어떠한지 현재위치가 어디인지 정확하게 인지하고 있는것이 가장 중요한 핵심이다라는것을 다시 한번 깨달으면서 오늘이 종료되는것 같다. 항상 유익한 시간이고 나 자신을 돌아보게 만드는 시간이다.