현행: 새로운 작품이 입고될때, 관리자가 관련 정보를 검색해서 검색 결과를 수동으로 채우고 있음.

구현내용: 상세정보 필드에 작품 관련 내용은 API에서 값을 받아 로 자동 입력. 가이드라인은 메일의 길이에 따라, 상세내용 별도 노션페이지로 생성.

구현 항목 상세 내용
데이터 모델 src/models/work.py — Work 클래스 (작품 제목·권리사·개봉년도·감독·출연·장르·영상타입·국가·플랫폼·링크 등 전체 필드)
핸들러 src/handlers/c3_work_register.py — run(work, admin_api_base_url, token) 진입점. API URL 미설정 시 dry-run 모드 반환
Lambda 핸들러 lambda/c3_work_register_handler.py — event에서 Work 필드 파싱 → c3_run() 호출
Admin API 연결 stub — POST {ADMIN_API_BASE_URL}/api/works (Bearer 인증). 응답에서 id/work_id 추출. API 명세 확인 후 구현 완성 예정
환경 변수 ADMIN_API_BASE_URL, ADMIN_API_TOKEN, SLACK_BOT_TOKEN, SLACK_ERROR_CHANNEL
테스트 tests/test_c3_work_register.py — 4개 pytest (stub 모드, API 성공/실패, payload 검증) ✅ 통과

C-3 동명이작 문제

C-3에서 작품을 식별하는 수단은 오직 work_title(문자열)입니다. 등록 전 중복 체크가 없고, 이후 단계(가이드라인, Notion)도 모두 work_title만 참조합니다.

같은 제목의 작품이 존재하는 실제 사례:

1. StubAdminAPIClient — 동명이작이 동일한 work_id를 받는다

위치: admin_api_client.py:97

def register_work(self, work: Work) -> Optional[str]:
    stub_id = f"stub-{abs(hash(work.work_title)) % 100_000:05d}"

hash()의 입력이 work_title만입니다. "신병"이라는 제목을 가진 작품은 권리사나 개봉 연도와 무관하게 항상 같은 stub_id가 반환됩니다.

"신병" (웨이브, 2022) → stub-XXXXX
"신병" (다른 권리사)  → stub-XXXXX  ← 동일한 ID

이 ID로 STEP 2의 update_guideline(work_id, ...) 가 호출되므로, 나중에 등록된 작품의 가이드라인이 먼저 등록된 작품의 가이드라인을 덮어씁니다.

2. HttpAdminAPIClient — 서버 응답을 구분하는 코드가 없다

위치: admin_api_client.py:177