추첨 직후의 속도보다 회차 정확성을 먼저 지키는 데이터 정책

1. 원본은 동행복권 공개 응답과 공식 결과 페이지입니다

자동 동기화는 www.dhlottery.co.kr의 회차별 공개 응답 경로를 주 출처로 사용하고, 같은 공식 도메인의 두 번째 응답 경로를 예비 출처로 순차 확인합니다. 각 요청에는 회차와 현재 시각을 넣어 중간 캐시가 오래된 응답을 돌려주는 가능성을 줄입니다. 응답 형식은 이전 API의 returnValue=success 구조와 최신 목록 구조 둘 다를 해석하되, 어느 형식이든 같은 필드로 정규화합니다.

공개 응답에서 받는 항목은 회차, 추첨일, 당첨번호 1~6, 보너스, 1등 총당첨금, 1등 당첨자 수입니다. 일반 화면에서 보여주는 출처 URL은 동행복권 공식 결과 페이지와 회차 매개변수를 결합한 주소입니다. 최종 당첨 판정·당첨금 지급은 이 공식 페이지와 실물 복권을 기준으로 합니다.

2. ‘예상 최신 회차’는 토요일 오후 9시 KST에 바뀍니다

추첨이 있는 토요일 낮부터 다음 회차를 ‘누락’으로 간주하면 결과가 나오기 전부터 반복 요청을 보내게 됩니다. 로또 시그널은 1회 추첨일인 2002년 12월 7일 오후 9시 KST를 시작점으로 두고, 이후 7일 간격을 계산합니다. 토요일 오후 8시 59분 59초까지는 직전 회차가 예상 최신이고, 오후 9시부터 해당 주 회차가 예상 대상이 됩니다. 일요일에는 직전 토요일 오후 9시를 기준으로 합니다.

이 규칙은 공식 실제 게시 시각이 항상 정확히 오후 9시라는 선언이 아닙니다. 주간 동기화 필요 여부를 안정적으로 계산하기 위한 운영 컷오프입니다. 공식 응답이 아직 준비되지 않았다면 동기화는 실패 상태를 남기고 기존 캐시를 보존합니다. 따라서 추첨 직후에 화면의 최신 회차가 즉시 바뀌지 않을 수 있으며, 화면의 “데이터 기준 회차”가 현재 분석 경계입니다.

3. 많은 방문자가 같은 순간에 공식 서버를 두드리지 않게 합니다

동기화 신호는 공개 요청에서도 발생할 수 있지만, 실제 외부 요청은 서버 전역 잠금과 상태 파일로 제어합니다. 잠금을 얻지 못한 프로세스는 “다른 동기화가 진행 중”이라는 상태를 반환하고, 외부 요청을 추가로 보내지 않습니다. 기본 재시도 대기는 15분이며, 캐시가 최신이더라도 기본 6시간마다 공식 응답과 현재 회차가 같은지 재확인합니다.

예상 최신 회차와 현재 캐시의 간격이 1~3회면 빠진 회차를 오래된 순서부터 하나씩 가져옵니다. 기본 3회보다 더 큰 간격이면 자동으로 대량 보정하지 않고 “관리자 동기화 필요”로 멈춥니다. 초기 회차 캐시가 아예 없을 때도 공개 트래픽이 전체 역사를 자동 설치하지 않습니다. 이는 공식 서버에 부하를 주거나, 잘못된 응답을 여러 회차에 걸쳐 대량 반영하는 위험을 줄이는 제한입니다.

4. 외부 응답을 유효한 회차로 받아들이는 검사표

당첨번호는 오름차순으로 정렬해 저장합니다. 1등 총당첨금과 당첨자 수는 공식 응답에 없을 수 있어 null을 허용하지만, 회차·추첨일·당첨번호·보너스는 한 항목이라도 잘못되면 반영하지 않습니다. 응답은 중간 리다이렉트를 무제한으로 따라가지 않고, TLS 피어와 호스트 인증서를 검증합니다. 외부 서버가 지연되어도 요청 버퍼를 1MB로 제한하고 읽은 뒤 해제하여 공유 호스팅의 메모리가 무제한으로 늘지 않게 합니다.

5. 새 회차는 기존 순서를 파괴하지 않고 병합합니다

캐시의 기존 회차와 새로 검증한 회차를 회차 번호를 키로 하는 맵에 합칩니다. 같은 회차가 있으면 나중에 검증한 새 값이 기존 값을 대체하고, 회차 내림차순으로 다시 정렬합니다. 병합 전·후 JSON이 같으면 캐시 파일을 불필요하게 바꾸지 않고 ‘공식 데이터와 일치’ 상태를 남깁니다.

바뀐 내용이 있으면 전체 새 JSON을 작성하여 난수 접미사가 포함된 임시 파일에 쓴 뒤 최종 캐시 경로로 이름을 바꾸어 교체합니다. 쓰기 바이트 수가 전체 길이와 다르거나 파일 교체가 실패하면 임시 파일을 제거하고 실패를 기록합니다. 회차 정보의 절반만 쓰인 파일이 공개 읽기 경로에 남는 상황을 줄이는 절차입니다. 실패한 새 회차는 ‘최신’으로 표시되지 않고, 이전 회차가 그대로 남습니다.

6. 공개 읽기 캐시와 DB를 서로 다른 용도로 유지합니다

일반 페이지에서 회차를 읽을 때는 동기화된 JSON 캐시를 먼저 사용합니다. 최신 회차가 앞에 오는 정렬된 배열이므로 최신 회차, 최근 N회, 특정 회차를 외부 DB 조회 없이 읽을 수 있습니다. 한 요청 안에서 처음 읽은 배열은 메모리에 재사용하여 같은 JSON을 반복 파싱하지 않습니다. 캐시 파일이 없거나 읽을 수 없을 때는 DB의 회차 테이블을 내림차순으로 조회하는 예비 경로를 사용합니다.

동기화에서는 새로 검증한 회차를 DB에도 트랜잭션으로 업서트합니다. 회차가 이미 있으면 추첨일·번호·당첨금·출처·동기화 시각을 갱신하고, 없으면 새 행을 넣습니다. 회차 반영 후에는 1~45 번호의 전체 빈도, 최근 20회 빈도, 마지막 출현 회차, 미출현 간격을 현재 회차 기준으로 다시 계산합니다. DB 쓰기가 실패하면 트랜잭션을 롤백하고 상태를 별도로 남깁니다. 공개 캐시는 이미 안전하게 쓰였다면 읽기 경로로 계속 사용할 수 있지만, DB 상태는 건강 검사에서 따로 확인해야 합니다.

7. 실패도 데이터 상태입니다

실패 상태에서도 기존 캐시가 예상 최신 회차와 같다면 공개 화면은 기존 데이터를 계속 제공할 수 있습니다. 반대로 캐시가 뒤처졌다면 건강 상태를 경고로 올리고, 화면의 기준 회차는 실제로 저장된 최신 회차를 계속 표시합니다. 최신성 표시를 실패와 분리해야 “외부 재확인은 실패했지만 현재 보유 회차는 아직 최신”인 상태를 정확히 설명할 수 있습니다.

8. 건강 검사는 회차 하나만 보지 않습니다

공개 건강 응답은 최신 저장 회차, 다음 대상 회차, 예상 최신 회차와 지연 여부를 보여줍니다. 데이터 항목이 있는지, 최신 추첨일이 현재일로부터 10일을 넘어 오래되지 않았는지, 캐시의 updated_at과 출처 메타데이터가 있는지, 자동 동기화가 지연 상태인지를 따로 검사합니다.

회차 데이터와 파생 분석물의 최신성도 다릅니다. 추천 캐시가 최신이어도 전략 비교 리포트의 기준 회차가 이전 회차이면 분석 리포트는 ‘지연’입니다. 추천 캐시, 추천 엔진 캐시, 전략 비교 리포트, DB·연구 스키마를 개별 항목으로 보는 이유입니다. 건강 상태가 경고인데도 개별 추천 회차가 정상일 수 있고, 반대로 서버가 응답해도 분석 리포트가 오래되었을 수 있습니다.

9. 수정·재계산·공개 기준

공식 기관이 회차 데이터를 정정하면 같은 회차키에 새로 검증한 내용을 병합하고, JSON 캐시와 DB의 회차 행을 일치시켜야 합니다. 번호 또는 추첨일이 바뀌면 파생된 번호 통계, 회차 진단, 추천 캐시, 전략 비교 리포트, 공개 발행본의 사후 판정을 영향 범위에 따라 다시 계산해야 합니다. 의미 있는 정정을 단순히 캐시 시각만 바꾸고 끝내지 않는 것이 정책의 핵심입니다.

현재 자동 동기화 서비스는 공식 응답의 새 값을 같은 회차에 병합할 수 있고 DB 번호 통계를 재계산합니다. 다만 모든 파생 산출물의 재생성을 하나의 요청에서 원자적으로 보장하는 전용 오케스트레이터까지는 아닙니다. 따라서 운영자는 회차 정정 후 건강 상태, 추천 발행 기준, 전략 리포트 기준 회차, 사후 판정을 함께 재확인해야 합니다.