멘토링 2회차 (26.06.13)

오전 방향 점검
이번 회의에서 방향은 초반보다 구체화됐지만, 무엇을 증명하는 서비스인지, 무결성을 어떻게 입증할지, 딥페이크 탐지와 증거 위변조 검증을 어떻게 나눌지에 대한 설명이 부족하다는 피드백이 많았습니다.

팀은 딥페이크와 음성 복제, 이미지 합성, 가짜 뉴스, 보이스피싱, 디지털 성범죄 같은 문제를 배경으로 잡았고, 디지털 증거는 무결성과 원본성이 보장되어야 법적 효력이 있다는 점을 문제의식으로 삼았습니다. 수사나 공공에서 문서 중심 수동 관리가 남는다는 한계를 보고, 업로드부터 분석, 보관, 검증, 보고서까지 이어지는 플랫폼을 만들겠다고 설명했습니다.

멘토님은 문제의식은 좋다고 하시면서도, 기존에 이런 기술이 없었겠냐는 관점에서 기존 기술과 표준, 서비스 대비 차별화가 무엇인지 설명해야 한다고 하셨습니다. 안전하게 보관한다는 말만으로는 부족하고, 기존 방식의 한계와 우리 시스템의 개선 지점이 문서에 드러나야 한다는 뜻이었습니다.

무결성은 해시만으로 부족하다
팀은 업로드 직후 SHA-256 해시를 만들고 원본을 S3에 저장하며, DB에서 해시 체인으로 감사 로그를 엮는 방식을 설명했습니다. 멘토님은 해시만으로는 누가 만들었는지, 원본성이 왜 보장되는지, 법적 증거로 왜 신뢰할 수 있는지를 충분히 말할 수 없다고 하셨습니다. 해시에 더해 디지털 서명, 감사 로그, 검증 API나 검증 보고서, 필요하면 워터마크, 그리고 변경 불가능한 레저나 블록체인 구조까지 검토해야 한다고 하셨습니다.

문서에 적힌 자동화된 무결성 인증 체인이라는 표현도, 체인이 정확히 무엇인지 설명할 수 있어야 한다고 강조하셨습니다. 해시를 서로 엮는다는 추상적인 말이 아니라, 어떤 이벤트가 어떻게 연결되고, 서명은 어디서 이뤄지며, 검증 때 무엇을 비교하는지까지 구체적이어야 한다는 설명이었습니다.

그래서 무결성 구조는 해시 생성, 디지털 서명, 체인 오브 커스터디 기반 로그, 변경 불가능한 저장이나 레저 검토, 검증 시각화와 검증 리포트까지 포함하는 방향으로 보완하기로 했습니다.

C2PA라는 국제 표준도 언급하셨습니다. 디지털 콘텐츠의 생성과 수정 이력, 출처를 기록하고 검증하는 표준인데, 이를 충분히 봤는지 물으셨습니다. 앞으로 문서에는 C2PA가 무엇인지, 우리 프로젝트와 접점이 무엇인지, 기존 표준이 못 푼 문제는 무엇인지, 우리가 추가로 제안하는 차별점은 무엇인지가 들어가야 한다고 하셨습니다. 경쟁력은 기능 나열이 아니라, 기존 표준을 이해한 상태에서 왜 이 설계를 골랐는지 설명하는 데 있다는 말씀이었습니다.

핵심 기능은 두 축으로
회의에서 가장 중요하게 정리된 것은 기능을 두 축으로 나누는 일이었습니다.

첫 번째는 업로드 시점 분석입니다. 파일을 처음 올렸을 때 딥페이크나 합성, 조작 가능성이 있는지 분석하고, 메타데이터와 해시, 의심 구간을 보여준 뒤, 서명과 저장을 거쳐 원본 기준점으로 관리하는 기능입니다.

두 번째는 저장된 원본과 신규 파일을 비교하는 검증입니다. 나중에 같다고 주장되는 파일이 오면 기존 원본과 비교해 위변조가 있었는지 보는 기능으로, 단순 딥페이크 탐지를 넘어 증거 보존 과정에서 변경이 있었는지를 보는 포렌식 검증에 가깝습니다.

멘토님은 지금 문서와 발표에서 이 둘이 섞여 있어 핵심이 헷갈린다고 지적하셨습니다. 앞으로는 기능 정의, 사용자 플로우, UI, 결과 리포트에서 분리해서 설명해야 한다고 하셨습니다.

비교 검증 흐름도 구체화했습니다. 원본에 디지털 서명을 붙여 저장했다면, 비교 대상도 같은 기준으로 처리한 뒤 비교해야 한다는 말씀이었습니다. 서명된 원본과 서명 안 된 신규 파일을 그대로 비교하지 말고, 비교 대상도 복사본을 만들어 같은 방식으로 서명한 뒤 원본과 비교하는 구조가 더 논리적이라고 하셨습니다. 흐름은 원본 업로드, 딥페이크와 조작 분석, 해시와 디지털 서명, 원본 기준 저장, 이후 비교 대상 업로드, 대상 복사본 생성과 동일 기준 처리, 원본과 비교 검증, 위변조 여부와 차이점 리포트 출력으로 정리되었습니다. 이 흐름은 서비스 구성도와 시스템 아키텍처에 반영하기로 했습니다.

UI, 리포트, AI 운영, 범위
현재 UI는 로그인 후 메인, 분석, 분석 기록, 관리자 초대코드 승인 정도였는데, 첫 업로드 중심이라 비교 검증 플로우가 따로 없다고 지적받았습니다. 첫 파일을 등록하는 화면과, 저장된 원본을 고른 뒤 비교 대상을 올려 검증하는 화면은 목적이 다르니 분리해야 합니다. 비교는 업로드 화면을 재사용하기보다, 분석 기록이나 증거 목록에서 원본을 고른 뒤 비교로 들어가는 흐름이 맞다고 하셨습니다. 상세보기, 비교 결과, PDF 보고서 화면도 아직 구체화가 부족해 재설계가 필요하다고 하셨습니다.

PDF 리포트에는 종합 위험도, 탐지 근거, 의심 구간, 메타데이터 이상, 로그 기록 등을 넣겠다고 했는데, 멘토님은 방향은 맞지만 항목이 있다 수준이고 실제로 어떤 내용이 어떤 근거로 채워지는지가 부족하다고 하셨습니다. 리포트는 왜 의심되는지, 어느 구간에서 어떤 근거가 나왔는지, 저장 이후 변경은 어떻게 판단했는지, 어떤 모델과 버전, 해시, 로그가 근거인지를 답할 수 있어야 한다고 하셨습니다.

AI 모델은 음성 쪽에서 AASIST, RawNet2, Wav2Vec2 등을 시험 중이라고 공유했습니다. 멘토님은 새 모델이 나왔다고 바로 쓰지 말고, 왜 채택하는지 설명 가능한 평가 프로세스가 필요하다고 하셨습니다. 골든셋 기반 비교, 오탐과 미탐 기준, 성능 개선 판단, 필요하면 롤백까지 가능해야 하고, 모델 버전 관리와 변경 시 승인, 완전 자동 배포가 아닌 Human in the loop 검토도 생각해보라고 하셨습니다. DevOps만이 아니라 AIOps, MLOps, DevSecOps 관점까지 보라는 조언이었습니다.

한국어 음성 데이터셋이 짧고 부족하다는 이야기에, 지금은 음성까지 욕심내면 완성도 리스크가 크니 영상 중심으로 MVP를 먼저 만들고 시간이 남으면 확장하라는 조언이 있었습니다. 완벽한 것을 만들려 하지 말고, 남은 시간 안에 설명 가능하고 시연 가능한 MVP를 만들라는 메시지였습니다. AI가 코드를 도와줄 수는 있어도, 팀이 구조와 원리를 모른 채 겉만 그럴듯한 프로젝트를 만들면 의미가 없다는 점도 강조도 있었습니다.

인프라는 AWS와 EKS, GPU 하이브리드를 말했고, VPN 이슈로 터널을 뺐다는 이야기도 나왔습니다. 보안이 해소되면 다시 써도 된다는 취지였습니다. S3 Object Lock이나 WORM, 버전 관리로 무결성을 강화하려는 구상에는, S3는 파일 저장소로 두고 무결성 증빙의 핵심은 별도의 레저, 체인, 서명 구조로 명확히 하라는 방향이었습니다.

오전을 한 문장으로 정리하면, 예쁘게 보이는 프로젝트보다 왜 이 구조가 맞는지 설명할 수 있는 프로젝트가 되어야 한다는 것이었습니다. 그리고 클라우드 아키텍처를 그리기 전에 서비스 구성도부터 명확히 하라는 지적이 있었습니다. 사용자가 어떤 기능을 어떻게 쓰는지 논리적 흐름을 먼저 잡고, 그다음 시스템 아키텍처, 그다음 클라우드라는 순서를 지키라고 하셨습니다. 점심 이후에는 기술 스택에 얽매이지 말고 서비스 구성도를 손그림 수준이라도 그려오라는 액션이 나갔습니다.

오후 서비스 구성도와 추적성
오후에는 오전 피드백을 반영한 서비스와 시스템 구성도, 요구사항 정의서와 지라 백로그, WBS를 점검했습니다.

서비스 구성도는 AI로 뽑은 인포그래픽이 정보와 흐름이 너무 많아 산만하고 핵심이 안 보인다고 하셨습니다. 회원가입이나 게시판 같은 기본 기능은 빼고, 메인 피처인 딥페이크 유무 판별과 증거 등록, 그리고 위변조 재검증을 단순하게 표현하라고 하셨습니다. 누구에게 어떤 가치를 주는가에 집중하라는 말씀이었습니다. 시스템 구성도는 클라이언트 React, API, 무결성과 탐지 엔진과 보고서 같은 서비스 계층, S3와 블록체인과 PostgreSQL 같은 데이터 계층으로 레이어를 나눠 연계를 보여주라고 하셨습니다. KISS와 YAGNI 원칙도 이야기하셨습니다. 하기로 한 핵심만 심플하게 구현하라는 뜻이었습니다.

요구사항 정의서는 내용이 구체적이지 않고, 실제 개발은 지라 백로그만으로 돌아가서 문서와 연결이 없다고 하셨습니다. 개인정보 수정이라면 비밀번호, 이메일처럼 수정 가능 항목을 적어야 API를 설계할 수 있다고 하셨습니다. RTM, 즉 요구사항 추적 매트릭스를 도입해서 고객 요구사항 RQ가 지라의 어떤 기능 FR로 쪼개졌고, 어떤 테스트 케이스 TC로 검증되는지 ID로 연결해야 한다고 하셨습니다. 하나라도 빠지면 구현 누락이나 검증 실패 리스크가 난다고 하셨습니다.

WBS도 지적받았습니다. 제출용 WBS는 진척도가 0퍼센트로 방치돼 있고 지라 타임라인과 안 맞는다고 하셨습니다. 화자 분리 기능 구현 7일처럼 덩어리가 커서 일일 진척을 보기 어렵다고 하셨습니다. WBS는 일정이 맞는지 보는 나침반이니, 최소 2일에서 3일, 가급적 일 단위로 태스크를 쪼개라고 하셨습니다. 최종 발표가 7월 말이라 인프라 배포, AI 튜닝, 시스템 통합, 테스트, 발표 자료 같은 마일스톤을 보고 남은 스프린트 계획을 재정비하라고 하셨습니다.

다음 주까지 할 일
공통으로는 피드백을 반영해 Draw.io와 Figma로 서비스 구성도를 단순하게 다시 그립니다. 월화요일 안에 맞추기로 했습니다. 요구사항 정의서와 지라 백로그, 테스트 케이스를 ID로 잇는 매핑 매트릭스도 차주 중 만듭니다. WBS와 지라 스프린트 일정도 현행화하고 태스크를 2일에서 3일 단위로 쪼갭니다.

백엔드와 인프라는 S3 업로드 형식 검증, API 구조 설계, VPN 등 남은 인프라를 스프린트 2 안에 체크합니다. AI는 탐지 결과 시각화와 이후 AI Ops 구성도, KPI 목표치를 스프린트 3 전까지 구상합니다.

소감
2회차에서 가장 크게 남은 말은, 해시만으로 무결성을 말할 수 없다는 점과, 딥페이크 탐지와 원본 대비 위변조 검증을 섞지 말고 두 축으로 나누라는 점이었습니다. 클라우드 그림보다 서비스 구성도가 먼저라는 순서도 다시 각인됐습니다. AI가 그려준 복잡한 그림에 갇히지 말고, 누구에게 어떤 가치를 주는지와 산출물끼리의 연결부터 다시 잡아가기로 했습니다.