어제와 오늘의 숫자가 같다면 아무 일도 없었던 것일까. 실제 스냅샷 비교 코드는 일부 확인 필드를 무시한다. 나는 가격 변경을 과장하지 않으면서 다시 확인한 일도 기록에 남기는 방법을 새 합성 diff로 풀었다.
무시한 필드가 의미하는 일을 읽었다
원래 비교에는 checked와 참조, 노트처럼 값 비교에서 제외되는 필드가 있다. 사소한 수정마다 가격 변경 알림을 만들지 않으려는 의도를 읽을 수 있다. 하지만 제외된 변화 자체가 운영 기록에서도 사라져도 되는지는 다른 질문이다. 확인 작업을 했는데 숫자는 그대로일 수 있다.
새 예제는 값과 확인 메타데이터, 단위 표현을 각각 비교한다. 가격 변화 여부를 판단하면서도 나머지 차이를 보관한다. 실제 운영의 알림을 전송하거나 기존 비교기를 수정하지는 않았다. 무엇을 사용자에게 알리고 무엇을 기록으로 남길지 정하기 전 단계의 분류 계약이다.
세 종류의 차이를 따로 반환한다
value_fields는 정규화한 input·output 값의 차이다. metadata_fields는 checked·reference·note의 차이다. representation_fields는 값과 단위를 적은 원래 구조의 차이다. 실제 값 차이가 있으면 value_changed, 그 외 차이만 있으면 verification_or_representation_only다.
한 사건에 여러 종류의 차이가 함께 있을 수 있다. 가격과 확인일이 함께 바뀌면 둘 다 남긴다. 단위 표현이 바뀌어도 값이 같으면 가격 변경 필드는 비운다. 사건을 한 이름으로 단순화하더라도 왜 그렇게 분류됐는지 세부 값이 남아 있어야 다음 검토자가 설명할 수 있다.
날짜만 바꾼 예제로 이름을 확인했다
고정 합성 행의 확인일만 다음 날짜로 바꾸면 value_fields는 비고 metadata_fields에 checked가 남는다. output 값을 바꾸면 실제 값 변경으로 분류한다. 0.002 per_1k를 2 per_1m으로 바꾸는 경우는 표현 변경이다. 세 반례를 함께 검사해 경계가 흐려지지 않게 했다.
확인일을 바꿨다고 실제 원본을 다시 확인했다는 증거가 자동으로 생기지는 않는다. 이번 함수는 전달받은 날짜와 참조의 차이를 보존할 뿐이다. 실제 검토자의 행동과 원본 자료는 별도로 기록해야 한다. 합성 날짜를 실제 서비스의 최신성 표시처럼 사용하지 않는다.
같은 값이 계속 확인되는 시스템
값이 유지된 기간에도 확인 기록이 쌓일 수 있다. 가격 변경 목록만 남기면 자료가 방치된 것인지 계속 확인된 것인지 알기 어렵다. 반대로 매번 값을 바꿨다고 알리면 방문자는 실제 변화를 과대평가할 수 있다. 두 필요를 한 종류의 이벤트로 해결하려 하지 않았다.
현재 모듈은 결과 배열을 반환하고 파일과 데이터베이스에 이력을 저장하지 않는다. 알림 조건과 보관 기간, 재검토 주기는 실제 서비스에서 별도로 정해야 한다. 자동 스케줄과 외부 제공자 조회를 붙이지 않았으므로 계속 확인 중인 시스템이라고 보고하지 않는다.
추가와 삭제도 다른 사건으로 남긴다
한쪽에만 있는 식별자는 added와 removed로 구분한다. 동일 식별자의 값 변경과 새 행이 생긴 일을 섞지 않는다. 비교 전에는 양쪽 목록의 중복을 검사하므로 같은 키가 여러 번 들어왔는데 한 행처럼 보이는 상황은 실패한다. 다음 글에서 이 비교 이전의 검사를 자세히 다룬다.
이 예제는 제공자와 모델의 합성 조합만 사용한다. 실제 제품 목록의 추가·종료를 소개하지 않는다. 운영 사실을 다룰 때는 단순한 피드 누락이 실제 서비스 종료인지도 별도로 확인해야 한다. removed라는 비교 결과는 목록에서 사라졌다는 뜻이며 사업상의 종료 판단까지 대신하지 않는다.
변경이 없다는 결과도 설명 가능하게
전체 12개 테스트는 날짜 갱신과 표현 변경, 실제 값 변경, 추가·삭제와 입력 보존을 확인했다. 완전히 같은 두 스냅샷은 빈 변경 목록이다. 근거 메타데이터만 달라도 빈 결과로 버리지 않도록 새 계약을 만들었다. 소스와 ZIP 추출 환경의 실제 실행 결과가 공개 모듈에 있다.
나는 방문자가 왜 변경이라고 표시됐는지 물었을 때 한 숫자와 한 필드를 짚어 설명할 수 있는 도구를 만들고 싶었다. 운영자가 다시 확인한 일과 사용자가 알아야 할 값의 변화를 나누면 정보가 더 차분하고 정확해진다. 다른 재고·일정·조건 비교에도 어떤 차이가 어떤 사건인지 먼저 정의하는 방법을 적용할 수 있다.