멘토링 4회차 (26.07.04)

오전 AI 코딩과 이해
대학과 현업에서 AI로 과제와 프로젝트를 빨리 만드는 일은 흔해졌다고 하셨습니다. 문제는 이해 없이 결과물만 쓰는 것이고, 프롬프트와 변경 이력이 없으면 나중에 수정이 어렵다는 말씀이었습니다. 아모레퍼시픽 관련 사례로, 백엔드가 파이썬 바이브 코딩으로 만들어져 인수인계와 수정이 곤란했다는 이야기도 나왔습니다. 빠른 생산은 좋지만, 설명하고 유지보수할 수 있는 understanding이 없으면 단기 이득이 장기 부채가 된다고 하셨습니다. 우리 프로젝트도 7월 말 종료 후 코드 접근이 줄어들 수 있으니, 빨리 만들기만으로는 부족하다고 하셨습니다.

프로젝트 종료 후에도 과정과 강의 등 후속 논의가 있을 수 있어, 리스크를 줄이는 방향으로 가라고 하셨습니다. 네트워크 환경은 아직 완전히 이전되지 않았고 LG 회선을 검토 중이라고 하셨습니다. 테스트 계획은 스프린트나 파이프라인에 있다는 수준이고 상세 계획은 없다고 하셨습니다. 요구사항 확인 후 전체 테스트만으로는 계획이 아니라고 하셨습니다.

테스트 전략
고객은 테스트했나, 했는데 왜 이 모양이냐를 물을 수 있다고 하셨습니다. 예견된 오류는 예외 처리로, 예견하지 못한 오류는 우회나 안내 메시지로 대응할 방식이 있어야 한다고 하셨습니다.

요구사항 명세는 고객이 요청한 것이고, 기능 명세는 구현자가 해석해 만든 정의입니다. 요구 하나에서 기능이 여러 개로 갈 수 있고, 기능은 여러 요구에 재사용될 수 있습니다. 모든 기능은 최소 하나의 요구에 매핑되고, 모든 요구는 기능으로 커버되어야 한다고 하셨습니다. 로그인에서 구매 같은 여정만 따라가면 상품권 결제처럼 호출이 거의 없는 기능이 남을 수 있으니, 기능 단위로도 검증해야 한다고 하셨습니다.

테스트 종류로는 단위, 기능, 통합, 컴포넌트, 컨트랙트, E2E를 말씀하셨습니다. 단위 테스트는 함수만 분리해 정상뿐 아니라 경계와 예외까지 보고, 개발자가 본인 코드에 하는 것은 기본이지만 시나리오 작성은 요건과 기능 분석자가 맡는 편이 낫다고 하셨습니다. 개발자만 쓰면 통과하기 쉬운 케이스로 편향될 수 있다고 하셨습니다. 통합 테스트는 단위가 된 뒤 시나리오로 연결 흐름을 보고, 팀 시나리오와 고객 시나리오를 합칠 수 있다고 하셨습니다. 우리 프로젝트에서는 단위와 통합을 필수로 두고, 여유가 있으면 API면 컨트랙트, 아니면 최소 E2E를 권하셨습니다. 테스트 결과 보고서와 가능하면 코드 커버리지도 남기라고 하셨습니다.

커버리지는 전 세계 공통 룰이 없고 프로젝트마다 목표를 둔다고 하셨습니다. 테스트 케이스에는 대상 기능, 연결 요구사항, 케이스 내용, 테스트일, 담당자, Expected와 Actual, Pass Fail을 넣으라고 하셨습니다. 개발기 DB만으로 끝내지 말고 UAT는 개발과 분리된 데이터로 검증할 수 있다고 하셨습니다. 기능은 맞아도 데이터 특성으로 터지는 경우가 많고, 금융권 금액처럼 int로 부족해 long이나 Decimal이 필요한 예도 드셨습니다. 오픈 전에는 케이스 전수 Pass가 원칙이고, Fail이면 Critical Medium Minor로 우선순위를 정해 긴급 패치와 오픈 연기를 판단하라고 하셨습니다.

테스트는 케이스 작성과 환경 준비, 전략까지 넣으면 이틀 사흘에 끝나지 않는다고 하셨습니다. 전부 할 필요는 없고, 취사선택해서 우리가 보증할 수 있는 수준을 정하고 그 수준의 결과물과 문서를 남기라고 하셨습니다.

위변조와 딥페이크 모델 현황
시스템은 단순 fake 판별이 아니라 디지털 증거의 진위와 무결성을 다루는 방향이라고 정리했습니다. 위변조는 GMFlow와 TruFor 조합은 타당하지만 성능과 신뢰가 문제라고 공유했습니다.

GMFlow는 TruFor가 못 잡는 움직임과 컷편집을 보완하는 보조인데, 초기에 후보 중 상대적으로 나았고 재학습으로 올랐어도 신뢰가 부족하다고 했습니다. 카메라 흔들림과 정상 움직임을 편집과 구분하지 못하고, 리소스를 더 써도 크게 안 오를 가능성이 있어 TimeSformer 등 대안을 검증하며 GMFlow는 일단 접어두고 비교하기로 했습니다. 당일 진행으로는 GMFlow에서 TimeSformer로 바꾼 테스트가 있었고, 해당 데이터셋에서는 GMFlow가 특징 구분에 한계가 있어 위변조 측을 TimeSformer로 대체할 예정이라고 정리했습니다.

TruFor는 프레임을 뽑아 보는 이미지 모델이라 영상 컷 연속성은 본질적으로 약하다고 했습니다. threshold를 고정하면 과적합 우려가 있고, 국제 표준셋 추가는 어려워 단일 데이터셋 학습 후 교차 추론으로 일반화를 보고, 히트맵과 이미지 조작에 집중하고 컷편집은 다른 모델에 맡기는 역할 분리를 검토하기로 했습니다. 멘토님은 데이터와 튜닝은 맞다, 모델이 틀렸다만으로 단정하기 전에 적용과 라벨, 스코어 해석을 다시 보라고 하셨습니다. 50퍼센트는 동전 던지기 수준이라고도 하셨습니다.

딥페이크 쪽 Xception과 Transformer는 테스트셋에서 꽤 높게 나왔지만, 육안으로도 구분 쉬운 샘플이 많고 휴먼 평가가 부족하다고 지적하셨습니다. 잘 나온 쪽도 정말 맞는지, 안 나온 쪽도 데이터인지 라벨인지 모델인지 사람 눈으로 검증해야 신뢰가 가능하다고 하셨습니다.

서비스 의사결정으로는 모델 실패 시 플랜 B를 미리 정하라고 하셨습니다. 무한 튜닝은 일정상 어렵고, 개별 모델이 일정 수준이고 서로 다른 영역을 커버하면 조합을 쓰고, 둘 다 실패하면 그 기능을 서비스에 넣지 않는 선택도 가능하다고 하셨습니다. UI와 리포트에서는 모델별 스코어와 통합 스코어를 나누어 보여주고, 우리 시스템이 단정한다기보다 사용 모델 기준 가능성으로 설명하라고 하셨습니다. 결과 JSON 항목은 팀이 정리해 공유하기로 했습니다.

오후 Fabric과 서명
원본 파일 본문은 온체인에 넣지 않고, 원장에는 해시와 검증에 필요한 메타만 둔다는 원칙을 확인했습니다. 원본과 분석 해시는 필수에 가깝고, Merkle Root로 여러 해시를 묶는 것도 적절하다고 하셨습니다. 모델 버전과 분석 시각, ID 같은 메타는 재현성에 필요할 수 있지만 과하면 복잡도가 오른다고 하셨습니다. 증거별 해시가 있어도 루트 하나로 묶으면 전체 원본을 다시 비교하지 않고 특정 항목 변경을 검증하기 좋다는 평가였고, 팀의 Merkle Root 앵커 방향은 적절하다고 확인하셨습니다.

Hyperledger Fabric을 쓰는 이유로는 허가형이라 허가된 Organization만 참여할 수 있고, 체인코드로 등록과 검증 로직을 정의할 수 있으며, 필요하면 Private Data로 민감 데이터를 나눌 수 있고, 캠프 맥락에서 오픈소스 Fabric이 역할에 잘 맞는다고 정리하셨습니다.

업로드에서 백엔드, Fabric 흐름을 문서로 그렸는지 물으셨고, 팀은 Figma로 구조와 설치 구성을 공유했습니다. 시스템 전체 아키텍처와 블록체인 전용 아키텍처를 구분해 그리라고 하셨습니다. Frontend는 업로드와 조회와 시각화, Backend는 인증과 메타와 AI 요청과 리포트와 해시와 체인코드 호출, AI는 딥페이크와 위변조 탐지, Storage는 원본과 분석 데이터 오프체인 저장, Fabric은 증거 등록과 검증이라고 레이어를 정리하셨습니다.

현재 채널과 체인코드는 각 하나이고, Peer는 네트워크상 둘이나 실제로는 Peer0 하나, Org도 사실상 단일이라고 했습니다. 멀티 Org는 이번 범위가 아니라 의도적으로 단순화한 것은 타당하다고 하셨습니다.

리포트 전자서명에서는, 업로드 시 업로더 정보로 서명하는 것이 초반에 합의한 업무상 전자서명의 핵심이고, 리포트는 시스템이 만드는 산출물이라 작성자 서명은 거의 불필요하다고 하셨습니다. 리포트는 아무나 열게 두기보다 권한 있는 사람에게만 보여주고, 서명은 작성자 증명보다 열람과 인증용으로 쓸 수 있다고 하셨습니다. 결론은 리포트 PDF에 작성자 전자서명을 새로 얹기보다, 업로드 증거 서명과 접근 제어로 충분하고, 리포트 열람은 인증과 권한으로 제한하는 방향이었습니다.

AI 정확도가 낮다고 프로젝트 실패로 단정할 수 없고, 리소스와 데이터셋과 환경 제약이 있다고 하셨습니다. 하다가 안 됐습니다로 끝내면 안 되고, 대안을 의미 있게 준비했고 일정과 환경상 여기까지라는 과정과 한계를 말할 수 있어야 한다고 하셨습니다. 발표에서는 두 달 반 동안 한 과정과 현재 결과 범위, 더 시간이 있으면 시도할 향후 계획, 언제까지 시도하고 안 됐을 때 서비스 미제공이나 제한 고지나 다른 모델 같은 contingency plan을 넣으라고 하셨습니다. 수치와 별개로 모델을 어떻게 검증했는지가 중요하고, 결과가 안 나와도 리포트 포맷이 바뀌지 않으면 대기만 하지 말고 검증 방법과 대안을 병렬로 하라고 하셨습니다.

당일 진행과 다음 주
당일 AI 쪽에서는 GMFlow 튜닝과 Late Fusion golden 평가, TruFor 분기 학습과 hold out 과적합 검증, GMFlow를 TimeSformer로 바꾸는 테스트, GPU Worker RabbitMQ 연동 자동화가 진행됐습니다. 백엔드는 RBAC Phase 1과 2로 수사관과 검토자와 기관관리자 역할, 사건 검토자 배정, 프론트 요청 반영이 들어갔고, Fabric E2E에서 Evidence Hash와 Report Hash와 Merkle Root, integrity verify가 Pass됐습니다. 리포트는 해시 앵커와 인증 권한 열람으로 가고 작성자 서명은 빼는 방향으로 멘토 가이드와 맞췄습니다. 프론트는 무결성 블록체인 탭 실데이터 연동과 PDF 보고서 추가가 있었습니다. 인프라는 Fabric chaincode 필드 확장, park wake 시크릿 정리, GPU RabbitMQ wake 자동화가 이어졌습니다.

다음 주에는 GPU 공인 IP 변경과 VPN 재설정, 발표 준비를 미리 하기로 했습니다. 발표는 당일 프레젠테이션에 따라 결과가 달라지니 기승전결과 청중이 이해하기 쉬운 스토리가 중요하고, 초안이 나오면 공유하기로 했습니다. 7월 17일 멘토링에는 테스트 케이스 보완과 발표 자료를 가져오기로 했습니다.

소감
4회차에서 가장 크게 남은 말은, 바이브 코딩과 모델 수치만으로 끝내지 말고 이해와 테스트와 휴먼 검증과 실패 시 대응까지 우리가 보증할 수 있는 범위를 문서로 남기라는 점이었습니다. Fabric은 원본이 아니라 해시와 Merkle과 최소 메타만 올리고, 서명은 업로드 증거 중심이며 리포트는 작성자 서명보다 권한 기반 열람으로 가기로 했습니다. AI는 정확도만 보고 실패로 단정하지 말고, 검증 과정과 대안과 한계를 발표에 넣을 준비를 하기로 했습니다.