POSA_Copyrighter/docs/reviews/2026-09-23-codex-feature-review.md

2026-09-23 codex 기능 검토 (원문)

codex exec --sandbox read-only (codex-cli 0.154.0). 프롬프트: 하루 50~100건 운영 가정, 병목 · 없는 기능 · 점수 오도 시나리오 · 기준 DB 오염 · 상위 5개. 파일 링크의 절대 경로는 작성 당시 로컬 경로다. 검증 결과와 채택 여부는 INDEX 의 같은 날짜 항목 참조.

가장 큰 문제는 검색·심사·권리 확인의 미완료 상태가 위험 점수와 기준 DB에 섞이고, 판정을 바꾼 뒤에도 과거 판단의 영향이 남는 것입니다. 하루 50~100건에서는 검색 자체보다 보류 재처리와 잘못 남은 판정 근거를 정리하는 일이 병목이 될 가능성이 큽니다.

지정 문서·화면 구조와 관련 구현을 읽었습니다. 점수 시나리오와 메모 조회는 합성 입력으로 실행 확인했습니다. 파일·DB는 수정하지 않았으며, 처리 시간과 발생 빈도는 실사용 측정이 아닌 추정입니다.

1. 시간을 잡아먹거나 실수를 유발하는 지점

발견	운영에 미치는 영향	파일·줄 근거
F1. 검색 장애로 보류한 사진이 다음에는 ‘등록 권리 대상’이 된다. 보류·반려 모두 활성 주의 후보를 만들고, 주의 후보도 유사도 0.9 이상이면 80점을 받는다.	“확인하지 못함”이 “위험하다고 확인함”처럼 재사용된다. 장애 때문에 보류한 정상 이미지가 재제출될 때 high로 올라가 반복 심사를 유발할 수 있다.	sqlite_store.py:798, store_operations.py:167, internal_analyzer.py:53, risk_scoring.py:190
F2. ‘미사용’ 버튼의 뜻과 실제 효과가 다르다. 행 버튼은 사용/미사용 두 개이고, 미사용을 false_positive로 전송한다.	“다른 증거를 대표 근거로 골랐으니 이것은 인용하지 않겠다”는 조작이 오탐 판정과 점수 제거로 이어진다. 가이드는 무관/오탐을 구분하지만 화면에서는 구분이 사라진다.	app-render-evidence.js:336, app-format.js:506, risk_scoring.py:160
F3. 보류가 작업 목록에서 사실상 완료처럼 빠진다. 다음 이동은 미심사만 찾고, 백로그도 미심사만 센다.	보류 필터는 있지만 담당자·다음 확인일·보류 사유별 후속 작업이 없다. 검색 복구나 자료 보완 후 돌아올 건을 운영자가 별도로 기억해야 한다. 누락 위험은 추정이다.	app-keyboard-batch.js:67, store_workflow.py:220, index.html:182
F4. 판정 변경은 가능하지만, 변경을 완결하는 기능이 부족하다. 승인으로 바꿔도 이전 주의 후보를 정리하지 않고 최신 스냅샷을 덮어쓴다.	오조작이나 소명 후 승인 변경 시 기준 DB까지 사람이 찾아 정리해야 한다. 특히 반려→메모 없는 승인에서 이전 반려 메모가 조회되는 동작을 재현했다. 지원자용 내보내기도 이 메모를 사용한다.	sqlite_store.py:790, store_workflow.py:328, store_workflow.py:380
F5. 일괄 재분석의 대상 선정·복구가 수작업이다. 브라우저가 선택 건을 순차 호출하며, 한 요청이 실패하면 반복을 중단한다.	“어제 한도 때문에 빠진 네이버만”, “기준 변경에 영향받은 건만” 처리하기 어렵다. 실패 후 남은 대상도 다시 골라야 한다. 장당 최대 5콜이면 문서상의 네이버 한도 100은 20장에 소진될 수 있어, 50~100건 운영에서 반복될 가능성이 높다.	app-submissions.js:9, store_operations.py:295, calibration-corpus.md:36
F6. 폴더 투입에서 서로 다른 제출이 같은 건으로 합쳐질 수 있다. 제출 ID가 파일명 stem이다.	지원자A/photo.jpg, 지원자B/photo.png 같은 입력을 내용 중복과 무관하게 충돌시킨다. 일부 건이 심사되지 않은 채 “다 처리했다”고 생각할 수 있다. 흔한 파일명에서의 발생 빈도는 추정, 충돌 한계 자체는 코드에 명시되어 있다.	image_store.py:93, calibration-corpus.md:63

2. 추가할 가치가 명확한 기능

중복 그룹·선례 승계, 일괄 판정, 선택 재분석, 판정 CSV는 이미 있습니다. 아래는 그 기능들이 아직 해결하지 못하는 부분입니다. 크기는 기존 구조를 활용하는 기준으로 S=국소 변경, M=화면·저장·워크플로 연결, L=여러 수명주기 또는 외부 시스템 연동입니다.

필요한 기능	왜 유용한가 / 없으면 생기는 일	크기	근거
보류 사유·담당자·기한·재개 조건을 가진 후속 심사함	검색 장애, 라이선스 확인, 지원자 자료 대기를 구분한다. 지금은 모두 보류로 묶여 미심사 백로그 밖에서 정체된다.	M	F1·F3. review-guide.md:44
판정 취소·재개·정정 이력과 파생 기준의 동시 정리	실수한 판정 복구와 소명 처리를 한 작업으로 끝낸다. 없으면 현재 승인과 과거 반려 근거가 공존한다. 판정별 메모·증거·스냅샷을 보존해야 한다.	M	F4. sqlite_store.py:776
조건별 재분석 작업 목록과 중단 후 재개	실패 제공자·미수행 사유·분석일·기준 변경으로 대상을 고르고 필요한 단계만 수행한다. 없으면 정상 분석도 반복하고 실패분을 재선택한다.	M	F5. store_operations.py:298
권리 증빙과 적용 범위 기록	라이선스 문서, 허용 제출자·용도·기간, 초상 동의 확인을 케이스 및 클리어 기준에 연결한다. 없으면 “이 사진이 승인된 적 있음”과 “이번 사용도 허용됨”을 구분하기 어렵다.	M	클리어 등록은 지문·메모·원 제출 중심이다. store_operations.py:236
선례 승계 전 적용 조건 비교	같은 이미지라도 신청자·용도·계약 상태가 다르면 재검토하도록 한다. 현재 승계 가능 여부는 선례 판정의 일치만 본다. 권한이 다른 재제출에 승인 선례가 전파될 가능성은 추정이다.	M	app-selectors.js:319, app-navigation.js:455
투입 전 대사 화면과 안정적인 제출 ID	발견 파일 수·신규 건수·내용 중복·ID 충돌·지원하지 않는 파일을 따로 보여준다. 없으면 파일 정리 실수가 심사 누락으로 바뀐다.	M	F6. image_store.py:105
판정 시점 기준의 케이스 리포트	당시 점수·사용 증거·메모·판정자·버전을 묶어 재현한다. 현재 내부 CSV는 현재 점수와 현재 사용 표시를 읽으므로 나중에 다시 내보내면 설명이 달라질 수 있다.	M	store_workflow.py:339, sqlite_store.py:802
지원자 통지 인계·수신 확인 상태	폐쇄망에서는 우선 승인된 파일 교환 방식으로 인계 ID·수신 여부·정정 통지를 관리할 수 있다. 현재 ‘승인 대기/반려 예정’과 CSV만으로는 실제 전달 완료 여부를 알 수 없다. 중복·누락 통지는 추정이다.	M, 직접 연동 L	sqlite_store.py:794, store_workflow.py:267

검색 캐시는 “전혀 없음”으로 판정하지 않습니다. 현재 케이스별 쿼리 중복 실행 방지가 있습니다. 보완할 것은 유효기간·강제 갱신·다른 중복 제출 간 재사용입니다. 성공했던 오래된 쿼리는 계속 생략되므로 ‘재분석’과 ‘최신 검색’이 다를 수 있습니다. 규모 M입니다. store_enrichment.py:711, store_serialization.py:647

3. 점수·밴드가 판단을 오도하는 구체적 시나리오

아래 점수는 각각 표에 적힌 증거만 있고, 라벨 신뢰도는 1.0인 합성 입력으로 실행 확인했습니다. 라이선스 유무와 이용 상황은 시나리오 가정입니다.

시나리오	증거 조합 → 실제 점수	잘못된 우선순위 또는 해석
권리 확인된 인물 사진이 먼저 올라온다.	신뢰 등록되지 않은 사이트의 완전일치 40 + 식별 가능 인물 30 + 라벨 10 → 80/high	해당 용도의 라이선스·동의가 확인되었다고 가정해도 점수에 반영되지 않는다. 다음 행보다 먼저 심사한다.
무단 사용된 비인물 작품이 뒤로 밀린다.	등록 DB에 없는 그림의 완전일치 40 + 라벨 10 → 50/medium	사용 허락이 없다고 가정한 명확한 사본도 인물이 없어서 앞의 허가된 사진보다 낮다. ‘권리 확인 필요성’과 ‘얼굴 존재’가 섞인다.
검색 장애 보류가 강한 위험 선례가 된다.	장애로 보류되어 만들어진 주의 후보와 유사도 1.0 → 80/high	새 권리 증거가 전혀 없어도 이전의 확인 불가 상태만으로 high다.
클리어 기준이 있어도 고위험으로 남는다.	클리어 일치 0 + 외부 완전일치 40 + 인물 30 + 라벨 10 → 80/high	동일 용도로 유효하게 클리어된 자산이라고 가정해도 가점이 없을 뿐 기존 위험 점수는 그대로다. 운영자는 ‘클리어 이력’과 high를 다시 해석해야 한다.
폐쇄망에서 미검색이 저위험처럼 보인다.	EXTERNAL_SKIPPED, 사유 disabled, 다른 신호 없음 → 0/low	이 설정은 의도된 예외지만, 검색을 하지 않은 사진이 검색 완료 후 증거가 없는 사진과 같은 low에 들어간다. ‘low=확인 완료’로 읽으면 위험하다.
계약처 도메인의 모든 이미지가 같은 취급을 받는다.	유일한 완전일치 출처가 신뢰 등록 호스트 → 0/low	계약이 일부 자산에만 적용되거나 만료되었다고 가정하면, 해당 사진의 사용 권한은 미확인인데 웹 증거가 제외된다.

배점·클리어 처리 근거: risk_scoring.py:49, risk_scoring.py:165. 미수행 예외: risk_scoring.py:278. 신뢰 호스트 제외: risk_scoring.py:125, risk_scoring.py:218.

여기에 검증되지 않은 정확성 인상이 더해집니다. 통계는 판정 당시가 아닌 현재 밴드를 사용하고, 분모가 0이면 비율 0.0을 반환합니다. 화면도 숫자를 유지하고 색만 중립으로 바꿉니다. 따라서 ‘미탐 0%’는 실제 성능 근거가 아닐 수 있습니다. store_workflow.py:214, store_workflow.py:398, app-stats.js:75

4. 기준 DB의 오염·노후화 경로와 빠진 절차

경로	빠진 운영 절차
주의 후보의 자기 강화. 검색 미완료 보류와 실제 반려가 같은 유형으로 쌓이고 같은 80점 축에 들어간다. F1의 확인된 동작이다.	보류 사유를 구조화하고, ‘검색 대기’는 권리 위험 기준에서 분리해야 한다. 후보의 확정 승격에는 별도의 확인 근거가 필요하다.
정정 후 반대 기준이 공존. 반려→승인은 기존 주의 후보를 정리하지 않고, 클리어는 별도 ID로 등록된다. 클리어·주의 후보가 동시에 활성일 수 있다.	원 판정 변경 시 파생 기준의 유지·철회 여부를 함께 결정하고, 동일 이미지에 반대 기준이 있으면 조정 대상으로 올려야 한다. store_operations.py:155, store_operations.py:229
제외한 후보의 재생성·확정 후보의 상태 후퇴. 같은 원 제출을 다시 보류/반려하면 기존 내용을 읽은 뒤 active=True, entryStatus=watchlist로 덮어쓴다.	재판정 때 기존 제외·확정 결정을 존중하고, 이를 바꾸려면 변경 사유를 남겨야 한다. store_operations.py:155
클리어·신뢰 출처의 만료와 범위 상실. 현재 클리어는 지문 중심이고 신뢰 출처는 활성 도메인 목록이다. 하위 도메인도 포함한다.	책임자·증빙·허용 범위·만료일·정기 재확인일이 필요하다. 계약 갱신·종료 때 영향받는 케이스 목록을 만들어야 한다. store_operations.py:236, store_search_candidates.py:721
기준을 철회해도 기존 케이스의 증거가 남는다. 비활성화는 기준 항목을 갱신하고, 재점수는 저장된 증거를 다시 계산한다. 기존 지문 증거에서 현재 기준의 활성 상태를 재확인하는 경로는 해당 함수에 없다.	기준 변경의 영향 대상을 찾아 과거 증거를 무효화·갱신하고, 처리 완료 여부를 확인하는 절차가 필요하다. store_operations.py:100, store_search_candidates.py:744

출처별 신뢰도 자동 학습은 지금 우선순위가 낮습니다. 현재 ‘미사용’이 오탐으로 저장되고, 운영자 판정도 점수를 먼저 본 상태에서 만들어집니다. 이 기록을 그대로 학습하면 기존 점수와 조작 습관을 강화할 가능성이 있습니다. 먼저 상태 의미를 바로잡고, 출처별 오탐·무관·권리 확인 결과를 분리 집계하는 편이 낫습니다. 이 순환 문제는 구현 주석에도 명시되어 있습니다. store_workflow.py:43

5. 지금 착수할 상위 5개

순위	착수할 일	선정 근거와 완료 기준
1	보류 사유 분리 + 주의 후보의 80점 자동 승격 차단	확인 불가가 강한 위험 선례로 누적되는 F1을 먼저 끊어야 한다. 검색 대기 보류는 권리 기준과 분리하고, 복구 후 재심사함으로 돌아오게 한다. 완료 기준: 장애 보류 사진의 재제출이 그 보류만으로 high가 되지 않는다.
2	판정 정정의 일관성 확보	F4는 실제 내보내기 내용까지 모순시킨다. 최신 판정 메모 조회를 우선 수정하고, 판정별 기록 보존·재개·파생 기준 정리를 연결한다. 완료 기준: 반려→승인 후 화면·기준 DB·내보내기가 같은 결론과 사유를 가리킨다.
3	투입 충돌 감지와 건수 대사	F6은 큐에 제대로 나타나지 않아 운영자가 심사로 발견하기 어렵다. 먼저 충돌을 명시적으로 차단·보고하고, 안정적 ID로 확장한다. 완료 기준: 동일 파일명 두 장이 서로 다른 제출로 보존되거나 명확한 오류 목록에 나온다.
4	증거 인용 여부와 무관·오탐 상태 분리	F2는 매일 반복되는 조작이며 점수와 향후 평가 데이터까지 바꾼다. ‘판정에 인용하지 않음’은 점수를 유지하고, 무관·오탐만 별도 사유로 제외한다. 완료 기준: 대표 증거 하나를 선택하는 작업이 다른 유효 증거의 점수를 지우지 않는다.
5	검색 완결성 표시 + 실제 판정 기반 캘리브레이션	low가 미검색과 섞이고, 현재 코퍼스는 medium/low를 검증할 수 없다. 검색 상태를 밴드와 별도로 명시하고 분모 0은 ‘측정 불가’로 표시한다. 자사 원본·라이선스 자산·비인물 작품을 보강해 판정 시점 스냅샷으로 평가한다. 완료 기준: 배포 설정별 검색 공백과 밴드별 실제 판정 결과를 구분해 볼 수 있다. calibration-corpus.md:19, calibration-corpus.md:101