법률정보 출처 변경과 응답 정합성 설계

법률정보 서비스는 검색 결과를 반환하는 일보다, 그 결과가 어느 시점의 문서인지 남기는 일이 더 중요해요. 국가법령정보센터와 대법원 데이터 기반으로 법령·판례를 검색하는 플랜엘(plan-l)을 설계할 때도 같은 기준이 필요합니다. 월 3건 무료 이용이라는 상품 정책과 별개로, 검색 응답의 출처와 개정 상태는 모든 사용자에게 같은 방식으로 설명되어야 해요.

문서 본문만 documents 테이블에 저장하면 출처가 갱신된 뒤 이전 검색 결과를 해석하기 어려워집니다. 그래서 문서 식별자, 원문 출처, 수집 시각, 개정 식별값을 분리해 두는 편이 안전해요. 최소 4개 필드인 document_id, source_url, retrieved_at, revision_key를 응답 생성까지 전달하면, 검색 색인과 API 응답이 다른 문서를 가리키는 문제를 줄일 수 있어요.

원문 수집→개정 비교→색인 갱신→API 응답

직접 만들어 보니라는 기록을 남기려면, 먼저 같은 문서 식별자로 2개 개정본을 넣는 재현 테스트가 필요해요. 이전 본문을 덮어쓰지 않고 별도 revision 행으로 저장한 뒤, 현재 개정본만 검색 색인에 반영합니다. 적용해 봤더니 확인해야 할 지점은 3곳이에요. 검색 결과의 제목, 상세 응답의 개정 기준, 캐시된 응답의 만료 시각입니다.

API는 검색 결과마다 revision_key와 retrieved_at을 함께 반환할 수 있어요. 클라이언트는 두 값이 바뀌었을 때 저장된 화면을 갱신하거나, “출처 갱신됨”처럼 상태를 구분해 표시합니다. 테스트해 보면 색인 갱신이 끝나기 전 캐시가 먼저 응답하는 상황도 발견할 수 있어요. 이때는 문서 개정 이벤트에 버전을 포함하고, 캐시 키에도 그 버전을 넣어 오래된 응답을 분리합니다.

돌려 보니 운영에서 가장 피해야 할 일은 출처 변경을 단순 본문 수정으로 처리하는 방식이에요. 1개 문서의 변경은 검색, 상세 조회, 캐시, 감사 로그라는 4개 경로에 영향을 줍니다. 플랜엘처럼 법령·판례 검색을 제공하는 서비스라면, 문서 개정 이력은 부가 정보가 아니라 사용자 응답의 기준점으로 다뤄야 해요.