고객 intent와 태그가 생성한 동적 proof를 Worker에서 검증합니다. 도장 1개는 바로 적립하고, 여러 개는 관리자 확인을 거쳐 확정합니다.
04 / INTENT → PROOF → AWARD
좌우로 이동해서 전체 흐름을 볼 수 있습니다.
검증 경계 URL fragment는 proof 전달용 입력입니다. 실제 적립 여부는 Worker 검증과 D1 조건부 batch에서 결정합니다.TECHNICAL DETAILS · 4개 단계NFC 검증·승인·결과 복원 상세담당 구성 · 처리 방식 · 입출력상세 펼치기상세 접기
intent, fragment, 암호학적 검증, 단일/다중 적립과 상태 복원을 설명합니다.
01적립 intent와 fragment 입력ARMED · d/e/c열기접기
담당 구성
고객 NFC store → Worker intent API / Vue fragment parser
처리 방식
고객이 stampCount와 함께 intent를 arm합니다. 기존 ARMED intent를 무효화하고 새 opaque token/context cookie와 만료 시간을 저장합니다.
REDEEMED · 결과 snapshot 또는 pending confirmation 확정 적립 / 거절 이력
04고객 결과 화면과 복원snapshot · 서버 상태열기접기
담당 구성
Worker 결과 snapshot → customer NFC store → 상태 화면
처리 방식
프론트는 서버 intent 상태와 consume 결과로 적립 완료·확인 대기·만료·인증 오류를 표시합니다.
새로고침이나 중복 fragment에서는 현재 상태와 결과 snapshot을 확인해 화면을 복원합니다.
만료 표시는 서버 시간과 수신 후 단조 증가 시간을 함께 사용합니다. NTAG213 test token은 제한된 개발 경로로 구분합니다.
입출력
입력
current intent · consume result result snapshot · expiry
출력
적립 완료 / 관리자 확인 대기 만료·재사용·인증 오류 화면
NFC 장치와 물리 처리
등록 파일 준비, 태그 개인화, 서버 검증, 서비스 활성화를 구분합니다. 두 번의 proof와 counter 증가를 확인한 뒤 OWNER가 장치를 활성화합니다.
05 / PROVISION → PERSONALIZE → ACTIVATE
좌우로 이동해서 전체 흐름을 볼 수 있습니다.
상태 분리 CLI 개인화 성공과 서버 validation 완료만으로 ACTIVE가 되지 않습니다. 별도의 OWNER activation이 필요합니다.TECHNICAL DETAILS · 3개 단계개인화·검증·활성화 상세담당 구성 · 처리 방식 · 입출력상세 펼치기상세 접기
full/light consumer가 Kafka 요청을 수신하고 영상 ID·객체 경로를 worker 작업과 연결합니다.
Queue로 추론 작업을 전달한 뒤 consumer는 poll과 결과 수거를 계속합니다. worker는 로드된 모델을 작업 간 재사용합니다.
타임라인·finalize·reference는 각각의 consumer 처리 경로에서 실행하고, 미디어 작업에 FFmpeg/ffprobe와 OpenCV를 사용합니다.
Workspace와 ArtifactRegistry로 로컬 산출물 재사용·MinIO 업로드를 관리하고 Kafka 응답으로 결과를 전달합니다.
입출력
입력
Kafka 작업 요청 video_id · bucket · 객체 경로 · 작업 옵션
출력
MinIO 분석 산출물 Kafka 응답: 작업 상태 · 영상 ID · 결과 경로 · 요약 내부 Queue 진행/완료 이벤트
인물 검수와 재판정
자동으로 제안된 얼굴 묶음을 사용자가 같은 인물의 세트로 정리합니다. 검수 결과는 기존 임베딩을 재사용하는 재판정의 입력이 됩니다.
04 / HUMAN REVIEW → REFERENCE
좌우로 이동해서 전체 흐름을 볼 수 있습니다.
cluster ≠ set 클러스터는 자동 추천 단위, 세트는 사용자가 확정한 인물 묶음입니다. 세트가 있는 경우 reference 작업으로 연결됩니다.TECHNICAL DETAILS · 4개 단계인물 검수·재판정 상세담당 구성 · 처리 방식 · 입출력상세 펼치기상세 접기
사용자 그룹 데이터가 서버 저장과 Python 재판정으로 이어지는 계약을 설명합니다.
01추천 클러스터와 사용자 세트cluster → set열기접기
담당 구성
Python 추천 산출물 → Vue 그룹 검수 화면
처리 방식
추천 얼굴과 자동 클러스터, 저장된 세트 정보를 읽어 그룹 편집 상태를 구성합니다.
사용자가 같은 인물의 클러스터를 세트로 묶고 배정을 해제하거나, 잘못 배정된 개별 얼굴을 이동합니다.
미매칭 얼굴 일부를 선택해 새 클러스터로 승격할 수 있습니다. 자동 cluster와 사용자 set은 서로 다른 식별자로 유지합니다.
입출력
입력
추천 crop · cluster_id 저장된 세트/클러스터 매핑
출력
세트 구성 · 미배정 목록 승격 클러스터 · 얼굴별 소속 변경
02그룹 저장 요청과 서버 반영HTTP · metadata · 객체 경로열기접기
담당 구성
Vue payload helper → Spring SuggestClusterSetService
final.mp4 / final_rework.mp4 결과 썸네일 finalize 응답 · 결과 파일 URL
05결과 반영과 재작업DB · SSE · 다운로드열기접기
담당 구성
Spring 응답 handler → DB / SSE → Vue 결과 화면
처리 방식
Spring이 성공 응답의 결과 파일·썸네일 정보를 기록하고 phase에 따라 COMPLETE 또는 REWORK_COMPLETE를 반영합니다.
SSE 상태 알림으로 화면 갱신을 유도하고 사용자가 결과 화면에서 영상을 확인·다운로드합니다.
재작업을 시작하면 편집 단계로 돌아갑니다. 프레임별 수정은 같은 metadata.json에 저장하고 결과 파일 이름은 phase로 분기합니다.
입출력
입력
finalize 성공/실패 · phase 결과 영상·썸네일 정보
출력
COMPLETE / REWORK_COMPLETE · 결과 파일 정보 SSE 상태 알림 · 결과 화면 재작업 편집 흐름
편집 화면
샘플 영상의 캔버스와 타임라인
원본 영상 위에 Canvas를 겹쳐 얼굴 영역을 표시합니다. Pinia가 프레임별 Rect를 보관하고, 고정·범위·추적 도구의 편집 결과를 저장 전 프레임 데이터에 반영합니다.
구현과 개선
다중 참조를 통한 인물 판정과 사용자 검수 결과를 재판정에 연결한 과정을 정리했습니다.
01 / 다중 참조 · 임베딩 매칭정면 한 장으로 부족했던 식별 기준참조 품질과 촬영 각도를 인물 판정에 반영하기기록 자세히 읽기기록 접기+
인물별 참조 이미지를 여러 장으로 확장하고, 샘플의 품질·일관성·촬영 각도를 고려해 비교에 사용할 대표 임베딩을 구성했습니다.
참조 1장과 다중 참조
좌우로 이동하거나 크게 보기로 전체 그림을 확인하세요.
점은 얼굴 임베딩, 마름모는 참조 기준입니다. 같은 임베딩 분포 위에 비교 기준을 추가한 설명용 개념도입니다.
문제: 같은 사람도 촬영 조건에 따라 다르게 보인다
얼굴 검출과 인물 식별은 서로 다른 문제입니다. 검출은 영상에서 얼굴의 위치를 찾는 일이고, 식별은 그 얼굴이 등록한 참조 인물과 같은 사람인지 판단하는 일입니다. 얼굴 박스를 잘 찾았더라도 식별 결과가 항상 맞는 것은 아닙니다.
기존 경험 기록에는 얼굴 크기·각도·가림 등 촬영 조건에 따라 같은 인물의 판정이 달라지는 사례를 비교한 내용이 있습니다. 특히 참조 이미지 한 장에만 의존하면 그 사진의 흐림, 정렬 상태, 촬영 방향이 해당 인물을 대표하는 기준 전체에 영향을 줍니다.
이 문제를 다루면서 참조를 ‘정답 사진 한 장’이 아니라 서로 다른 품질과 촬영 조건을 가진 샘플 집합으로 보기 시작했습니다. 인물별 여러 이미지를 입력받고, 어떤 샘플을 사용할지와 어떻게 합칠지를 참조 처리의 책임으로 나눴습니다.
비교 가능한 임베딩을 만드는 공통 경로
영상에서 검출한 얼굴과 참조 이미지 모두 얼굴 검출·정렬·임베딩 추출이라는 공통 경로를 거칩니다.
YOLO 계열 얼굴 검출로 얼굴 위치와 landmark 정보를 얻습니다.
5점 landmark를 이용해 얼굴을 정렬합니다. 정렬 정보가 불안정한 경우의 처리와 품질 정보를 함께 다룹니다.
선택한 embedding backend에 맞춰 입력을 정규화하고 임베딩을 추출합니다.
임베딩을 L2 정규화해 cosine 유사도 비교에 사용합니다.
현재 코드는 ArcFace와 FaceNet 계열의 실행 경로를 지원합니다. 참조와 영상 얼굴은 같은 embedding backend를 기준으로 비교해야 하며, 두 모델의 점수 분포나 임계값을 같다고 가정하지 않습니다.
이 기록의 범위는 기존 모델을 연결하는 파이프라인과 참조 판정 정책입니다. 얼굴 인식 모델을 새로 학습하거나 독자 모델을 개발한 성과로 설명하지 않습니다.
여러 장을 받는 것만으로 해결되지 않는 문제
참조 이미지 수를 늘려도 잘못 검출된 얼굴, 심하게 흐린 이미지, 정렬이 어긋난 샘플이 함께 들어오면 대표 벡터의 기준이 흔들릴 수 있습니다. 입력 수 증가와 참조 품질 관리는 별도로 다뤄야 합니다.
기존 기여 기록에는 낮은 품질의 참조 제외, robust mean 적용, 참조 일관성 보완이 단계적으로 추가된 흐름이 있습니다. 현재 구현에서도 얼굴 크기와 검출·정렬 정보를 다루고, 사용 가능한 참조 임베딩으로 대표 벡터를 구성합니다.
품질과 일관성은 같은 의미가 아닙니다. 선명한 다른 사람의 얼굴은 시각적 품질은 좋더라도 해당 인물의 참조로는 부적절할 수 있습니다. 반대로 중심 벡터와 유사도가 낮은 사진이 반드시 다른 사람이라고 확정되는 것도 아닙니다. 샘플을 거르는 기준을 실제 신원의 정답으로 취급하지 않도록 구분했습니다.
대표 벡터를 구성하는 robust mean
현재 구현의 robust mean은 중심과의 cosine 유사도가 낮은 샘플의 영향을 줄이는 trimmed mean 방식입니다.
참조 임베딩들을 다시 L2 정규화합니다.
임시 평균 벡터를 만들고 정규화해 중심을 구합니다.
각 참조 벡터가 중심과 얼마나 유사한지 계산합니다.
설정된 하위 분위수에 해당하는 샘플을 제외하고 남은 벡터를 평균합니다.
최종 평균을 다시 정규화해 대표 벡터로 사용합니다.
항상 샘플을 잘라내지는 않습니다. 현재 함수는 샘플이 4개 미만이거나 trim 비율이 0 이하이면 trimming 없이 평균을 사용하고, 설정 비율은 0~49 범위로 제한합니다. 적은 샘플에서 과하게 제외하거나 잘못된 설정으로 대부분의 정보를 없애지 않기 위한 조건입니다.
이 방법의 목적은 일부 비일관적인 샘플이 대표 벡터에 주는 영향을 줄이는 데 있습니다. 다수의 잘못된 참조가 섞여 있거나 표본 자체가 부족한 상황까지 자동으로 해결하는 방식은 아닙니다.
촬영 각도를 별도의 비교 조건으로 반영한다
정면과 측면 얼굴을 하나의 평균으로만 압축하면 서로 다른 촬영 조건이 섞입니다. 현재 참조 구성은 인물 ID를 유지하면서 각도 구간별 대표 벡터를 만들고, 비교할 때 각도 구간과 좌우 방향 정보를 함께 사용합니다.
단계
처리 내용
참조 구성
동일 인물의 샘플을 각도 구간별로 모아 대표 임베딩 구성
원시 비교
영상 얼굴 임베딩과 각 참조 벡터 사이의 cosine 유사도 계산
조건 보정
각도 구간·좌우 조건에 따른 penalty를 반영
인물별 집계
같은 인물에 속한 여러 참조 벡터 중 최대 보정 점수를 선택
최종 판단
backend에 맞는 임계값과 판정 정책으로 인물 매칭 여부 결정
여러 참조 벡터를 비교하더라도 최종 결과는 인물 단위로 정리합니다. 어떤 각도 구간의 참조가 선택됐다는 사실과, 어느 인물로 판정됐다는 결과를 구분하기 위해서입니다.
원시 cosine 유사도와 조건을 반영한 보정 점수도 구분합니다. 보정된 점수만 보면 임베딩 자체가 비슷했던 것인지, 어떤 비교 조건이 결과에 영향을 줬는지 추적하기 어렵기 때문입니다.
품질 점수·추천 점수·식별 점수를 구분한다
파이프라인에는 얼굴 크기·선명도·조명·가림·각도 등 품질 정보와 추천 후보 점수가 존재합니다. 이들은 사용자가 검수하기 좋은 얼굴을 우선 제시하거나 참조 구성에 필요한 정보를 남기는 데 사용합니다.
하지만 검출 confidence, 추천 점수, cosine 유사도, 실제 식별 정확도는 서로 다른 값입니다. 추천 점수가 높은 얼굴이라고 해서 특정 인물일 확률이 그만큼 높다는 뜻은 아닙니다. 휴리스틱 점수를 정답률처럼 표현하지 않고, 각 값의 생성 목적과 사용 단계를 분리했습니다.
바뀐 점과 남은 한계
참조 한 장을 기준으로 비교하던 흐름에서 여러 참조의 품질과 일관성을 살피고, 촬영 각도를 고려한 대표 벡터와 인물별 점수로 판단하는 흐름으로 확장했습니다. 잘못된 결과를 볼 때도 검출·정렬·샘플 구성·유사도·각도 조건 중 어느 부분을 살펴볼지 나눌 수 있게 됐습니다.
다만 가림이 심하거나 얼굴 정보가 부족한 장면, 참조 자체가 부적절한 경우의 판단에는 한계가 남습니다. 이 때문에 자동 판정 뒤에 사용자가 얼굴 묶음을 검수하고 다시 반영할 수 있는 경로를 연결했습니다.
정확도 개선을 수치로 말하려면 동일한 영상·정답 데이터·모델·임계값·처리 설정으로 전후 비교해야 합니다. 현재 원고에는 그러한 비교 결과가 없으므로 정확도 향상률을 적지 않습니다.
배운 점
인물 식별을 개선할 때 임계값 하나만으로 판단하기보다 비교 기준이 되는 참조가 어떻게 만들어졌는지부터 살펴볼 필요가 있었습니다. 입력 품질, 대표 벡터 구성, 비교 조건을 나눠야 어느 조정이 어떤 결과를 만들었는지 설명할 수 있습니다.
영상 얼굴 식별·편집 / 구현과 개선
02 / 사용자 검수 · 재판정자동 클러스터링에 사용자 보정 더하기인물 그룹 수정에서 기존 임베딩 재사용과 편집까지기록 자세히 읽기기록 접기+
자동 얼굴 군집을 사용자가 인물 단위로 정리하고, 그 결과를 기존 임베딩을 사용하는 재판정 입력으로 연결했습니다.
자동 클러스터링 → 사용자 보정 → 재판정
좌우로 이동하거나 크게 보기로 전체 그림을 확인하세요.
같은 인물은 합치고 잘못 섞인 얼굴은 옮깁니다. 기존 임베딩을 유지한 채 참조 기준과 인물 판정을 갱신합니다.
문제: 클러스터링 오류를 화면에서만 수정하면 부족하다
자동으로 묶은 얼굴은 실제 인물과 항상 일치하지 않습니다. 같은 사람이 각도나 품질 차이 때문에 여러 군집으로 나뉠 수 있고, 서로 다른 사람이 같은 군집에 섞일 수도 있습니다. 어느 군집에도 충분히 매칭되지 않은 얼굴이 검수 대상이 될 수도 있습니다.
이때 화면에서 그룹 이름이나 배치만 바꾸고 분석 데이터가 그대로라면, 사용자가 내린 판단이 다음 편집이나 영상 처리에 이어지지 않습니다. 검수 UI의 결과를 저장하는 것과 영상 전체의 인물 판정에 반영하는 것을 하나의 흐름으로 연결할 필요가 있었습니다.
기여 이력에는 타깃 후보 추천, 노이즈 얼굴 remap, 클러스터 승격, 그룹 세트 저장과 재판정 응답 대기가 이어서 추가된 기록이 있습니다. 자동 결과를 확인하는 화면에서, 사용자의 판단을 다시 분석에 사용할 수 있는 구조로 확장한 과정입니다.
자동 클러스터링 결과와 사용자 인물 세트를 구분한다
개념
의미
사용자가 할 수 있는 작업
cluster
자동으로 제안된 얼굴 묶음
같은 인물의 다른 군집과 함께 배정
set
사용자가 같은 인물이라고 정리한 군집 집합
여러 cluster를 한 인물 세트로 구성·해제
unassigned
인물 세트에 배정하지 않은 군집
배정하거나 미배정 상태로 유지
unmatched
자동 클러스터링 결과에 충분히 매칭되지 않은 얼굴
검수 후 일부 얼굴 선택
promoted cluster
선택한 미매칭 얼굴에서 만든 새 군집
인물 세트에 포함
embedding remap
개별 얼굴의 군집 소속 변경
잘못 섞인 얼굴만 다른 군집으로 이동
군집 전체를 이동하는 작업과 얼굴 한 개의 잘못된 배정을 수정하는 작업을 구분했습니다. 사용자 입장에서는 모두 ‘인물 정리’이지만, 서버가 갱신해야 할 데이터 범위가 다르기 때문입니다.
얼굴을 다시 찾을 수 있는 연결 키
정밀 분석에서 추출한 임베딩은 embeddings.npy에 저장하고, 프레임별 얼굴 정보에는 해당 행을 가리키는 embedding_idx를 남깁니다. 검수 화면의 얼굴 이미지, 자동 클러스터링 결과, 프레임의 얼굴 정보가 같은 샘플을 가리킬 수 있게 하는 연결입니다.
여기서 embedding_idx는 얼굴 샘플의 인덱스이며 전역 인물 ID가 아닙니다. 한 사람이 여러 프레임에 등장하면 여러 얼굴 샘플과 임베딩이 생깁니다. 자동 묶음은 cluster_id, 사용자가 구성한 인물은 set_id, 재판정 결과는 target_group_id로 구분해 해석합니다.
이 구분 덕분에 이미 추출한 임베딩을 유지하면서 얼굴의 군집 소속이나 인물 세트 구성을 수정할 수 있습니다. 사용자가 그룹을 수정할 때마다 영상 전체에서 얼굴을 다시 검출하고 임베딩을 추출하는 경로로 돌아갈 필요가 없도록 한 것입니다.
프론트에서 서버로 보내는 검수 결과
프론트는 검수 화면의 상태를 다음 항목으로 나눠 Spring에 전달합니다.
sets: 인물 세트 ID와 포함된 cluster ID 목록.
unassignedClusterIds: 세트에 배정하지 않은 군집 목록.
promotedClusterIds: 미매칭 얼굴에서 승격한 군집 목록.
embeddingRemaps: 개별 embedding index의 새 cluster ID.
설명용 예로, cluster 2와 3이 같은 사람이라면 같은 set에 넣고, cluster 4는 미배정으로 남길 수 있습니다. 그중 한 얼굴만 다른 사람이라면 해당 embedding_idx의 배정을 별도로 수정합니다. 이 예시의 번호는 실제 사용자 데이터가 아닙니다.
세트의 표시 이름과 저장 식별자도 구분합니다. 현재 서버 계약에서 label은 영구 저장 대상이 아니므로, 화면에 입력한 이름 자체가 이후 분석의 기준이 된다고 설명하지 않습니다. 재판정에서 사용하는 핵심은 세트와 군집의 식별 관계입니다.
Spring에서 맞춰야 하는 데이터
검수 결과는 브라우저 상태뿐 아니라 현재 metadata, 추천 얼굴 이미지의 정보, DB 세트 매핑에도 영향을 줍니다. SuggestClusterSetService는 다음 순서로 작업을 조율합니다.
사용자와 영상의 소유 관계를 확인하고 세트·군집·remap 입력을 검증합니다.
개별 얼굴의 remap을 현재 metadata에 반영합니다. 수정 전에는 기준 metadata의 백업을 확인합니다.
추천 얼굴 이미지의 경로와 그룹 정보를 변경된 배정에 맞춥니다.
기존 세트 매핑과 새 요청을 비교해 추가·삭제·승격 결과를 반영합니다.
삭제된 세트를 참조하던 기존 판정 정보를 정리합니다.
남은 인물 세트가 있으면 Kafka로 reference 재판정을 요청합니다.
세트를 모두 제거하는 경로에서는 관련 매핑과 참조 정보를 정리하고 재판정 요청을 생략합니다.
각 구성요소가 서로 다른 편집 파일을 보지 않도록 현재 작업 기준은 metadata.json으로 맞추고, 최초 기준 보존에는 og_metadata.json을 사용합니다. 기존 작업 기록에 있던 ‘프론트가 보는 파일과 Python이 수정하는 파일이 다른 문제’와 연결되는 정합성 기준입니다.
다만 DB와 객체 저장소, Kafka 작업을 하나의 분산 트랜잭션으로 묶는 구현은 아닙니다. 중간 실패 시 어떤 파일과 매핑까지 반영됐는지는 따로 확인할 필요가 있습니다.
Python은 기존 임베딩으로 인물을 재판정한다
그룹 기반 재판정은 최초 참조 이미지 등록과 다른 진입 경로인 run_reference_from_groups로 들어옵니다. 이미 생성한 embeddings.npy와 현재 metadata.json이 필요하며, 두 산출물이 없으면 이 경로를 그대로 실행할 수 없습니다.
세트별로 포함된 cluster와 얼굴의 embedding index를 찾습니다.
세트에 속한 임베딩을 모아 각도 구간·좌우 방향별 대표 벡터를 구성합니다.
기존 참조·그룹·추적 판정 필드를 정리하고 새 세트를 기준으로 얼굴을 다시 매칭합니다.
그룹 기반 재판정 경로의 추적 보완으로 검출된 얼굴 사이에서 비어 있는 그룹 판정을 보완합니다.
참조 대상에 배정되지 않은 얼굴에도 추적 정보를 구성해 후속 편집에 활용합니다.
갱신한 metadata와 처리 결과를 다음 화면 및 응답 처리로 연결합니다.
여기서 추적 보완은 이미 검출된 얼굴의 판정을 이어주는 처리입니다. 검출하지 못한 얼굴을 항상 복원하거나, 가려진 얼굴의 정확한 위치를 모두 알아낸다는 의미는 아닙니다. 최초 참조 이미지 매칭 경로에도 같은 후처리가 항상 적용된다고 묶어 설명하지 않습니다.
저장 요청과 재판정 완료를 구분한다
검수 결과를 서버가 받았다는 사실만으로 Python 재판정이 끝난 것은 아닙니다. Spring은 Kafka 요청 전에 videoId를 키로 응답 대기를 등록하고, CompletableFuture로 최대 30초 동안 결과를 기다립니다.
대기 중 성공 응답이 도착하면 재판정 완료를 확인할 수 있습니다.
오류 응답이 도착하면 실패를 전달합니다.
제한 시간 안에 완료되지 않으면 아직 처리 중임을 나타내는 HTTP 202 경로로 응답합니다.
HTTP 202를 최종 성공으로 해석하면 화면은 새 판정을 보여준다고 생각하지만 실제로는 이전 결과를 읽을 수 있습니다. 접수·처리 중·완료를 구분하는 것이 검수 저장과 후속 편집을 연결하는 데 중요합니다.
현재 응답 대기는 서버 프로세스의 메모리에 있습니다. 서버 재시작 후 대기 복구나 여러 인스턴스 사이의 응답 전달까지 지원하는 영속 작업 추적기로 설명하지 않습니다. 같은 영상에 대한 동시 요청을 모두 독립적으로 추적하는 구조도 아닙니다.
재판정과 최종 편집의 역할
재판정은 얼굴이 어느 인물 그룹에 속하는지 갱신합니다. 사용자는 이후 편집기에서 프레임의 얼굴 영역과 적용 여부를 최종 확인하고 수정할 수 있습니다.
is_target은 참조 인물과 매칭됐는지 나타내고, apply_blur는 실제 모자이크 적용 여부를 나타냅니다. 참조로 식별된 인물을 기본적으로 모자이크에서 제외하는 화면 정책이 있더라도, 최종 출력에는 사용자가 확정한 apply_blur를 명시적으로 저장하는 계약이 필요합니다.
검수·재판정·편집은 서로 이어지지만 각 단계가 결정하는 값이 다릅니다. 군집을 합쳤다는 이유만으로 모든 프레임의 최종 출력이 확정된 것으로 취급하지 않도록 구분했습니다.
바뀐 점과 배운 점
자동 추천에서 끝나던 결과를 사용자가 인물 단위로 수정하고, 그 판단을 기존 분석 산출물에 다시 반영할 수 있게 연결했습니다. 프론트의 드래그·배정 결과가 metadata 수정과 reference 재판정의 실제 입력이 된다는 점이 핵심입니다.
이 작업에서 중요했던 것은 검수 화면의 조작 수보다 사용자가 수정한 얼굴을 서버와 분석 엔진도 같은 대상으로 해석하는 데이터 계약이었습니다. 임베딩 인덱스, 군집 ID, 인물 세트 ID의 의미와 저장 시점을 구분해야 화면의 수정이 다음 처리에서도 유지됩니다.
기존 임베딩 재사용으로 검출·임베딩 추출을 반복하지 않는 실행 경로를 만들었지만, 전체 검수 시간이나 정확도 개선율을 측정한 자료는 별도로 필요합니다. 이 기록에서는 사용자의 정정이 재판정과 편집으로 이어지는 기능적 변화까지 설명합니다.
Spring Boot
Vue 2
MySQL
MariaDB
