업무 화면에 새 상품이 나타나면 정보를 성공적으로 가져왔다고 생각하기 쉽다. 실제 코드를 다시 읽으니 원문을 못 읽은 뒤에도 제공된 자료로 검토 후보를 만드는 경로가 있었다. 나는 그 대체 경로를 없애기보다 원문 수집과 후보 구성의 상태를 분리해서 설명하고 싶었다.
작동하게 해 달라는 요청에서 결과를 나눠 읽었다
과거 요청은 프로그램이 작동하기를 바란다는 말이었다. 리뷰 기록에는 실패한 URL 수집을 성공으로 처리하던 문제를 고쳤다는 설명이 있고, 후속 질문은 다른 곳에서 정보를 가져오는 방법이었다. 나는 그 설명을 현재의 실서비스 연결 완료로 확대하지 않고 실제 가져오기 함수와 후보 생성 경로를 함께 읽었다.
문서도 시점에 따라 표현이 달랐다. 예전 인계 문서는 API 연결 전 준비를 설명하고, README는 외부 연동이 목업인 로컬 데모라고 밝힌다. 이번에는 서버나 외부 계정을 실행하지 않았다. 예전 시험과 화면 검수 보고는 당시 기록이고, 이번에 직접 확인한 것은 선택한 코드의 조건과 새 독립 합성 예제다.
제공 자료가 없는 실패는 후보 생성 전에 멈췄다
추가 함수는 먼저 URL을 검사하고 수집 응답을 기다린다. 실패했을 때 초기 제목·후보 표시 같은 대체 자료가 없으면 상품을 추가하지 않고 오류를 돌려준다. 대체 자료가 있어도 차단 관련 오류 문구로 분류되면 멈춘다. 나는 이 분기가 실패를 빈 상품 생성으로 덮지 않으려는 현재 코드의 의도로 읽었다.
다만 오류 문구의 일부를 찾는 조건을 완전한 실패 분류기로 설명하지 않았다. 수집 불가와 차단을 기계가 확실히 구별하려면 연결기에서 어떤 상태를 돌려주는지 계약이 필요하다. 공유 예제는 unavailable과 blocked를 명시적으로 받지만 실제 차단이나 네트워크 검증을 수행하지 않는다. 원래 프로그램의 분류 방식도 이번 작업에서 수정하지 않았다.
CSV로 남긴 후보는 원문을 읽었다는 증거가 아니었다
CSV 경로는 제목·가격·옵션을 초기 자료로 전달한다. 원문 수집이 불가해도 허용된 대체 경로로 후보를 만들 수 있고, 추가 함수는 그때 별도 warning을 반환한다. 그런데 CSV 반복문은 result.ok이면 성공 건수를 올린다. 이 건수는 생성한 후보를 세는 것이며 원문을 성공적으로 읽은 상품 수와 같다고 설명할 수 없다.
직접 URL을 넣는 경로는 반환된 경고를 안내에 붙이지만 CSV 집계는 그 경고를 사용하지 않는다. 제공된 자료를 계속 검토할 수 있게 한 선택은 유용하더라도 표시 단계에서 그 이유가 사라질 수 있다. 제작자라면 후보 생성 수와 원문 확인 수를 다른 축으로 보여 줄지 정해야 한다. 이번 글은 그 차이를 기록하며 실제 CSV 처리를 실행한 결과를 보고하지 않는다.
한 번 합친 자료에서 무엇이 읽힌 값인지 잊기 쉽다
원래 앱 코드는 초기 자료 뒤에 API 자료를 펼쳐 합친다. 그래서 API가 빈 제목을 반환해도 앞의 제목을 덮을 수 있다. isMock 역시 명시된 초기 값이 있으면 그 값을 유지하므로 필드마다 어디서 왔는지 설명하는 표식으로 사용할 수 없다. 이것은 선택한 정적 코드의 조건이며 실제 사용자 자료에서 발생시킨 장애가 아니다.
서버의 메타 추출은 제목·설명·이미지·주소·추출 시각을 돌려준다. 가격과 재고를 모두 읽는 함수는 아니다. 반면 데모 생성기는 템플릿 가격과 옵션, 이미지 개수 표시 같은 기본값을 채운다. 제목 하나를 읽었다고 그 모든 값까지 원문에서 확인됐다고 쓰면 범위가 달라진다. 기존 필드 근거 글과 연결되지만 이번 질문은 대체 자료의 합치기와 후보 집계에 있다.
대체 경로를 별도 합성 계약으로 다시 만들었다
새 모듈은 수집 상태와 fetched, provided를 따로 받아 필드별 출처를 돌려준다. 빈 제목은 제공 자료를 지우지 않고 숫자 0은 유효한 값으로 보존한다. 잘못된 자료형은 조용히 바꾸지 않는다. 차단은 후보 없음, 원문 불가는 제공 자료의 검토 후보, 제목 없는 빈 결과는 부족 상태로 나눠 다섯 사용 기록을 만들었다.
숫자 근거 비교 모듈과 일괄 자료 검토 모듈을 먼저 읽었지만 어느 쪽도 이 수집 상태와 대체 필드 선택을 맡지 않았다. 그래서 좁은 책임의 새 예제를 만들고 소스와 압축 추출에서 각각 26개 시험을 실행했다. 이는 옛 앱의 26개 시험을 다시 실행한 것이 아니다. 새 계약은 원래 앱에 설치되지 않았으며 원문 진위도 확인하지 않는다.
코드와 구현 살펴보기
합성 후보의 실제 반환 예
{
"fetch_status": "unavailable",
"candidate": {
"title": "Synthetic item B",
"price_minor": 1200
},
"field_origins": {
"title": "provided",
"price_minor": "provided"
},
"missing_fields": [
"shipping_minor",
"stock"
],
"review_required": true,
"publish_ready": false,
"performs_action": false,
"authenticates_sources": false,
"decision": "provided_candidate"
}다음 화면에 넘길 수 있는 상태를 정확히 부른다
후보의 필드가 모두 채워져도 새 모듈은 검토 필요를 유지하고 발행 가능으로 바꾸지 않는다. 이 정책은 운영자의 검토나 서버 승인을 구현한 것과 다르다. 다음 화면은 원문 수집 상태와 제공 자료의 출처, 아직 없는 값을 읽어 검토 동선을 구성할 수 있다. 후보를 남기는 일과 실제 상품을 외부에 등록하는 일은 별도 연결이다.
나는 원래 앱의 계정·주문·결제·메일·수집 자동화와 고객 자료를 그대로 두었다. 공개한 것은 제작 중 발견한 분기와 더 명확한 합성 계약이다. 홈페이지에서 프로그램을 소개할 때도 무엇을 자동으로 채웠는지보다 어떤 자료로 무엇을 만들었는지 설명하면 고객이 다음 확인을 이해하기 쉽다. 어떤 자료를 읽었고 어떤 후보를 만들었는지 상태별로 구분해 설명한다.