lottodraw.kr

로또 6/45 번호 생성기와 전 회차 통계 사이트. 주소는 https://www.lottodraw.kr.

이 문서는 작업 인수인계서다. 회사 PC, 집 PC, Claude 채팅, VS Code 등 어디서 작업하든 이 파일 하나만 읽으면 "지금 어디까지 왔고, 다음에 뭘 해야 하는지"를 알 수 있도록 쓴다. 작업을 마칠 때마다 맨 아래 진행 기록에 한 줄씩 추가한다.

Claude에게: 작업을 시작하기 전에 이 문서를 끝까지 읽을 것. 작업이 끝나면 "진행 기록"과 "할 일"을 갱신하는 것까지가 작업이다.

---

1. 지금 상태 한눈에 보기 (2026-10-02 기준)

항목	상태
사이트 운영	✅ 정상 (GitHub Pages, www.lottodraw.kr)
매주 당첨번호 자동 갱신	✅ 정상 (최근 1244회차까지 반영, 2026-10-04). 토요일 밤 추첨 직후 반영 + 네이버·Bing 즉시 색인 요청 추가(2026-10-04, 첫 토요일 확인 필요) → 3번
블로그 (글 16편, 한국어·영어)	✅ 공개 (2026-10-02). 애드센스 대응으로 쓴 글. 원고는 content/blog/ → 4-3번
무료 기능 (생성기, 통계, 당첨번호, 실수령액, TOP 50 · 회차별 그래프)	✅ 공개 중
유료 기능 (5개월 통계, 상세 분석 4종, TOP 50 그래프 보조지표·그림도구)	✅ 무인 판매 중 (2026-10-02~). 카카오뱅크 사업자 계좌 · 휴대폰(MacroDroid 프로) 입금 알림으로 자동 발급 · 텔레그램 알림 · 매일 실서버 점검. 실제 1,500원 입금으로 1분 안에 발급 확인. 키 메일(Resend) 켜짐(2026-10-05)
회원 (구글 로그인 · 좋아요 ♥/$. 가입 무료 체험은 2026-10-11 끝)	🔄 코드 완성 (2026-10-06). 구글 클라이언트 ID 를 넣으면 켜진다 → 4번 설치 순서 8
내 번호 저장 · 추첨 결과 메일 (회원)	🆕 코드 완성 (2026-10-17, 메일은 2026-10-18 "추첨 결과 메일"로 바꿈). 머지하면 deploy-worker 가 배포하고 저절로 켜진다(새 비밀값 없음). 첫 일요일 메일 확인 필요 → 4-5번
1등 판매점 통계 (statistics-stores.html)	🆕 2026-10-17. 262~1245회 1등 · 2등 판매점, 매주 자동 갱신. 머지 뒤 색인 요청 필요 → 4-6번
당첨번호 중복 (statistics-repeat.html)	🆕 2026-10-18. 회차와 회차를 통째로 견준 페이지(6개가 모두 같은 회차 0쌍 · 5개 21쌍, 생일 문제), 매주 자동 갱신. 머지 뒤 색인 요청 필요 → 4-8번
검색 노출	🔄 "로또 통계" 1면 목표 (경쟁: superkts.com). 화면·메뉴는 지금 그대로 두고 푼다 → 4-4번
애드센스	❌ "가치 있는 콘텐츠 부족"으로 반복 반려 → 4-2번. 2026-10-18 스팸 정책 점검: 원인은 회차 1,246쪽(숫자 빼면 97% 같음) → noindex 없이 회차마다 다른 사실 · 메모로 보강 → 4-7번
유료화	🔄 카드 결제는 국내외 모두 업종에서 막힘 → 계좌이체 직접 판매로 전환 (페이앱 카드는 심사 신청 가능) → 4번

---

2. 사이트 구성

페이지

파일

내용

index.html

홈. 번호 생성기 + 통계 요약 + 잠긴 상세 분석 4종. 제목 줄 오른쪽에 다음 회차 판매 마감 · 추첨 방송까지 남은 시간(2026-10-13, js/draw-countdown.js — 휴대폰은 제목 아래 세 줄. 다른 페이지는 메뉴 아래 한 줄 띠). 생성 이력 / 보렐의 법칙 카드는 PC · 휴대폰 모두 끝까지 펼쳐 보인다(2026-10-11 — 예전에는 높이를 12vh · 6vh 로 묶어 안에서 스크롤). PC(두 칸)에서는 두 카드의 위아래 끝을 맞춘다(접은 카드는 늘리지 않음, 본문 첫 · 끝 여백도 같게). 생성 과정 로그는 번호 생성 칸의 "번호 생성" 단추 아래(2026-10-11 — 생성 이력 카드에서 옮김. 생성 전에는 안내 한 줄, 쪽 넘김은 로그 제목 줄 오른쪽의 작은 ‹ 1 / 3 ›. PC 는 제목 + 5줄 자리를 미리 잡고, 긴 까닭이 두 줄로 접혀 넘치면 상자 안에서만 스크롤 — 줄 수 · 쪽이 바뀌어도 단추와 아래 카드가 움직이지 않는다. 번호를 못 만든 오류 때는 "혹시 모르죠…" 문장을 감추고 그 자리(줄 + 여백)를 오류 문장 칸이 이어받아 단추가 움직이지 않는다. PC 로그 상자는 마지막 쪽이면 고른 번호 줄이 보이게 끝으로, 쪽을 넘기면 처음부터. 휴대폰 쪽 넘김 단추는 34×28px). 회원 기능(2026-10-11, 로그인하면 — 직전 당첨 조합 제외 · 5게임은 이용권이 있어도, 서버 로그인이 꺼져 있으면 잠그지 않음 · 잠금은 화면에서만): "번호 생성" 옆 5게임(용지 한 장 AE 를 한 번에 — 이력에 E 부터 넣어 1쪽에 AE 차례, 결과 칸에는 A, 로그 줄 앞에 "A · "), 단추 아래 직전 당첨 조합 제외 끌기 막대(끔 · 1 · 2 · 3 · 5 · 10 · 20 · 30 · 50 · 100회 · 전체 — 그 회차 당첨번호 6개 묶음(보너스 제외)과 똑같은 조합은 뽑지 않고 로그에 "1245회 당첨 조합과 같아 제외", 고정수 6개가 그 조합이면 오류), 그 아래 AC값 막대(2026-10-14 — 끔 · 610 · 710 · 810 · 910 · 10, AC값이 그보다 낮은 조합은 로그에 "AC값 7, 기준 10 미만이라 제외", 고정수 6개가 낮으면 오류. 두 막대는 .gen-sliders subgrid 로 이름 · 막대 · 값 칸을 맞춘다. AC값 통계 페이지의 "AC값 조건으로 번호 뽑으러 가기"가 index.html#gen-ac 로 와서 그 줄을 잠깐 밝힌다), 내 설정 저장 · 불러오기(고정수 · 제외수 · 켠 패턴 · 막대 칸 · AC값을 계정에 — POST /api/me/generator, 서버가 다듬어 u:<계정>.gen 에, /api/me 로 본인에게만, 탈퇴하면 함께 지움. 2026-10-17 부터 카드마다 따로: 고정수/제외수 카드는 번호 · 두 막대, 배제할 특수 패턴 카드는 켠 패턴만 — 서버에는 한 덩어리라 저장할 때 내 정보를 새로 받아 그 카드 몫만 바꿔 보낸다(SET_PARTS), 저장한 설정이 없으면 화면 전체를 저장). 특수 패턴 기본값(2026-10-17, DEFAULT_PATTERNS): 16개 중 12개를 켜고 4 · 8(모두 131 · 3145 안) · 13 · 14(합계 두 구간)는 꺼 둔다 — "모두 체크"는 16개 전부. 잠겼을 때는 자물쇠 표시, 누르면 로그인 창(이유 문장). 생성 이력 아래 초기화(2026-10-12 — "되돌릴 수 없습니다" 한 번 묻고 오늘 이력과 "오늘 n회 생성"을 지운다. 지난날의 numberHistory_ · clickCount_ 칸도 함께 치운다. 지운 뒤 초점은 카드 제목으로) · 복사(2026-10-12 "번호 복사"에서 줄임, 화면 읽기 이름은 "번호 복사". 머리줄 "로또 6/45 번호 n조합 (날짜) — lottodraw.kr" + 한 줄에 한 조합, 최근 것부터. 누르면 단추 폭 그대로 "완료" · "실패"를 잠깐 보이고 긴 문장은 화면 읽기 프로그램에만) · 공유(2026-10-12 — 휴대폰 공유 창(Web Share: 카카오톡 · 문자 등)으로 "내 로또 6/45 번호 n조합 (날짜)" + 복사와 같은 줄 + https://lottodraw.kr/. 이 기능이 없는 브라우저(PC 대부분)는 단추를 숨긴다. 닫으면 그만, 막히면 복사로 대신) · 출력(생성 이력만 — 용지 한 장 = 5게임 A~E 로 묶은 인쇄 종이. 인쇄 규칙은 가 아니라 머리의 에 둔다: 배포 직후 옛 를 쥔 브라우저에서 홈 전체가 찍혔다. 은 인쇄 창을 닫고 페이지를 다시 만질 때(pointerdown · keydown) 푼다 — afterprint 로 풀면 안드로이드 크롬에서 홈 전체가 찍힌다: 가 곧바로 돌아오며 beforeprint · afterprint 를 먼저 보내고, 시스템 인쇄 창이 미리보기를 그릴 때(용지 · 프린터를 바꿀 때마다) beforeprint 를 다시 보낸다. 단추 없이 시작한 인쇄는 평소 화면 — Ctrl+P 는 키라 먼저 풀린다), 이력이 없으면 단추는 꺼짐. 379px · 339px 이하에서는 단추 좌우 여백(339px 이하는 횟수 글자도 12px)을 줄여 320px 에서도 "오늘 n회 생성"(두 자리까지)과 단추 넷이 한 줄("완료" · "실패"가 떠도 그대로). 생성 이력(오늘 최근 100개, 최근 것이 1쪽 맨 위)과 과정 로그(한 번 생성할 때의 시도, 최근 50줄 — 처음엔 마지막 쪽)는 한 쪽에 씩, 넘치면 카드 안에서 "‹ 이전 · 1 / N · 다음 ›"으로 쪽을 넘긴다(창 폭이 경계를 넘으면 보던 줄이 든 쪽으로 다시 그린다). 통계 카드 순서: 많이 나온 번호 · 보너스 · 연속번호 · 합계 · 1등 당첨자 수 · 최근 50회 · 궁합수 · 미출수 · (2026-10-11 3·4번에서 뒤로) · AC값 · 끝수 — 와 생성기 가 같은 순서(5개월 통계는 미출수 카드가 없어 AC값이 홀짝 앞, 잠금 미리보기와 같게). 쪽을 넘기면 화면 읽기 프로그램에 "생성 이력 2/3쪽"을 읽어 주고, 짧은 마지막 쪽도 빈 줄로 채워 쪽 단추가 제자리에 있다

데이터와 코드

파일	역할
lotto-data.json	전 회차 당첨 기록 원본. 모든 페이지의 숫자가 여기서 나온다
favicon.svg · favicon.ico · apple-touch-icon.png	탭 아이콘(사이트 남색 바탕 + 노란 로또공 7). 모든 페이지 머리말에 세 줄 — 생성기 shell() 과 손으로 관리하는 페이지(index · about · top-prize · tax · statistics · ranking · contact · privacy · terms · mypage · admin). ico 는 16·32·48px(구글 검색 결과 아이콘은 48의 배수)
prize-data.json	회차별 2~5등(당첨 게임 수 w2~w5 · 1게임당 금액 a2~a5) · 판매액(sales). 회차 하나에 한 줄. 같은 동행복권 응답에서 tools/update-lotto-data.js 가 받는다(1회부터 있음). lotto-data.json 은 모든 페이지가 받으므로 따로 둔다 — 생성기 · TOP 50 만 읽는다
js/lotto-stats.js	통계 계산
js/stats-render.js js/insights.js js/details.js	통계를 화면에 그리기. details.js 는 상세 분석 4종(연속번호가 나온 회차 · 번호별 동반 출현 · 내 번호 성적표 · 1등 당첨금 추이 — 성적표 카드는 2026-10-21 "내 번호 과거 대조" 자리에, 계산은 js/report.js 그대로, 2~5등 금액 prize-data.json 은 처음 누를 때 받는다. 처음 열면 마지막 회차의 2등 조합(당첨번호 앞 5개 + 보너스) 예시가 펼쳐져 있다(노란 줄로 "예시 — n회 2등 번호…"를 밝히고, 입력 칸 안내도 같은 번호. 내 번호를 넣으면 예시 줄은 사라진다). 카드에는 요약 · 등수별 횟수 · 가장 좋았던 회차 · 아까웠던 회차 5개, 당첨 회차 전체 · 연도별은 report.html?n= 로 이어 본다). 카드는 제목 · 안내 · 본문 · 주석 네 칸(잠긴 카드는 제목 · 설명 · 단추 세 칸)이고 한 줄의 카드끼리 칸마다 높이를 맞춘다(.detail-card subgrid). 연속번호 · 동반 출현 · 1등 당첨금 목록은 40개까지 그려 두고 12 · 10 · 20개는 늘 보이며, 옆 카드가 길면(성적표 결과 등) fitAll() 이 남는 높이만큼 더 연다(카드는 늘리지 않음, 1등 당첨금 제목 옆 "최근 n회차"도 따라 바뀜)
cpi-data.json	월별 소비자물가지수(총지수). 그래프 "물가 반영"이 쓴다. tools/update-cpi.js 가 받는다(손으로 고치지 않는다). credit·link 가 그래프 아래 출처 줄에 그대로 나온다(지금은 OECD, DBnomics 경유)
tools/update-cpi.js · .github/workflows/update-cpi.yml	물가지수 받기. 매월 7일 10:20 KST 예약 실행 + 이 두 파일을 고쳐 푸시하면 그 브랜치에서 한 번. 받는 곳: ECOS(비밀값 ECOS_API_KEY 가 있을 때) → OECD → FRED → DBnomics. 1회 달(2002-12)부터 빠짐없고 마지막 달이 6개월 안쪽일 때만 저장
min-wage.json	최저임금(시간급). TOP 50 그래프의 2·3등 비교선(2등 ↔ 연봉, 3등 ↔ 월급). 손으로 고친다 — 다음 해 최저임금은 매년 8월 5일까지 고시되니, 그때 에 한 줄() 더하고 을 그 해 12월 31일로 바꾼다. 월급 = 시급 × (209시간 — 주 40시간 + 주휴, 지금 기준을 모든 해에 똑같이), 연봉 = 월급 × 12. 회차 날짜에 적용되던 시급을 쓰고(2002이듬해 8월, 2005-09-0112월), 뒤 회차는 선을 그리지 않는다. 그래프 선은 계단 대신 직선( — 기간 가운데 날짜에 그 기간 금액, 사이는 날짜 비율). · 가 출처 줄에 나온다. 시험: ( · )

기타 파일

• CNAME: 사이트 주소(www.lottodraw.kr)를 GitHub Pages에 알려주는 파일
• ads.txt: 구글 애드센스 광고 인증 파일
• naver….html: 네이버 서치어드바이저 소유 확인 파일. 지우면 안 된다
• df151d56acb974ec33c521ed980fa1f2.txt: IndexNow 열쇠 파일(내용도 같은 값). 네이버·Bing 이 색인 요청이 우리 사이트에서 온 것인지 이 파일로 확인한다. 공개돼도 되는 값이다. 지우거나 바꾸면 색인 요청이 거절된다 (바꾸려면 tools/indexnow.js 의 KEY 도 같이)
• robots.txt sitemap.xml: 검색엔진용 안내 파일
• _config.yml: GitHub Pages(Jekyll) 설정. 블로그 원고(content/)가 /content/blog/…html 이라는 중복 페이지로 올라가지 않게 뺀다
• 방문자 통계(Cloudflare Web Analytics): 모든 페이지 </head> 바로 앞에 비콘 스크립트 한 줄이 있다. DNS가 "DNS only"(프록시 꺼짐)라 클라우드플레어가 자동으로 넣어주지 않으므로 직접 심은 것이다. 생성 페이지는 tools/build-static-stats.js의 CF_BEACON에서, 손으로 관리하는 페이지(index about contact privacy terms statistics tax top-prize report)는 각 파일에 직접 들어 있다. 새 페이지를 손으로 만들면 이 줄도 복사해 넣을 것
• css · js 지문(?v=): 손 관리 페이지(tools/asset-version.js 의 PAGES)의 css/… · js/… 주소 끝 ?v= 는 그 파일 내용의 sha1 앞 8자리다. js/i18n.js 가 불러오는 account.js · theme.js 의 지문은 i18n.js 안 LOAD_V 줄에 같은 도구가 적는다(2026-10-27 — 배포 직후 옛 theme.js 가 쥐어져 홈 메뉴 "판매점 지도"가 안 보였다). node tools/build-static-stats.js 가 끝에 맞춘다 — css · js 를 고쳤으면 빌드를 돌려 커밋할 것(안 돌리면 배포 직후 10분 동안 옛 파일과 섞일 수 있다). 두 작업이 같은 파일을 고쳐 ?v= 줄이 부딪히면 빌드를 다시 돌리면 된다. 새 손 관리 페이지는 PAGES 에 넣는다

---

3. 자동 갱신은 어떻게 돌아가나 (GitHub Actions)

GitHub Actions란? GitHub가 빌려주는 임시 컴퓨터가 정해진 시간에 저장소의 대본(.github/workflows/*.yml)대로 명령을 실행해 주는 기능이다. 내 컴퓨터가 꺼져 있어도 돌아간다.

① 토요일 낮 12:07·16:07 예약 (draw-night)
   · GitHub 예약은 2시간 반~5시간 늦게 시작한다(2026-09 기록). 그래서 일찍 시작해 기다린다
   · 20:40 까지 자다가 1분마다 동행복권 조회
   · 한 번 실행은 5시간 반까지 — 그 전에 결과가 안 나오면 자기 자신을 다시 실행해 이어서 기다린다
        ↓
② 새 회차의 번호와 1등 당첨자 수가 나오면 update-lotto-data 를 바로 실행 (보통 토요일 21시 전후)
   · 1등 당첨자 수까지 기다리는 이유: 추첨 직후 API 가 1등 0명/0원을 줄 때가 있다(1228회).
     그대로 올리면 회차 페이지에 "1등이 없어 이월"이라고 잘못 나간다
   · 자정까지 안 나오면 그만둔다 → 아래 일요일 예약이 받는다
        ↓
③ 동행복권에서 새 회차를 받고, 최근 3회차를 다시 확인 → 바뀐 게 없으면 여기서 끝
        ↓
④ 통계 페이지, 회차 페이지, 블로그, 사이트맵을 새 데이터로 다시 생성
        ↓
⑤ "github-actions[bot]" 이름으로 저장소에 저장(커밋) → GitHub Pages에 재배포 요청 → 사이트 반영
        ↓
⑥ 사이트에 반영된 것을 확인한 뒤 바뀐 페이지를 네이버·Bing 에 알림 (IndexNow)

안전망: 일요일 03:10 · 월요일 09:10 예약으로 ③~⑥ 을 한 번 더 돈다 (1등 금액이 늦게 확정되는 경우 보정).

• 토요일 밤 반영이 핵심이다. 추첨 직후 기사가 수십 개 뜨고 검색이 몰리는 때가 토요일 21~24시인데, 전에는 회차 페이지가 일요일 아침 6시쯤에야 올라갔다(예약 실행 지연).
• 예약 실행은 예정보다 2~5시간 늦는 게 보통이다. GitHub 예약 실행은 정시를 보장하지 않는다. 일요일·월요일 예약은 안전망이라 늦어도 괜찮다.
• IndexNow(색인 요청): 바뀐 페이지 주소를 네이버(서치어드바이저)와 Bing 에 바로 보낸다. 로봇이 언제 올지 기다리지 않게 하려는 것이다. 블로그는 머리글의 회차만 바뀌므로 보내지 않는다. 처음에는 "202(열쇠 확인 대기)", 그 뒤로는 "200"이 정상이다. 실패해도 갱신은 끝난 상태라 노란 경고만 남고 워크플로는 성공으로 끝난다. 구글은 IndexNow 를 받지 않는다 — 구글은 지금처럼 사이트맵으로 간다.
• 동행복권 데이터를 브라우저에서 직접 불러오지 않는 이유: 동행복권 서버가 다른 사이트에서의 호출을 막는다(CORS라는 브라우저 보안 규칙). 그래서 GitHub의 임시 컴퓨터가 대신 받아서 lotto-data.json 파일로 저장해 두고, 사이트는 그 파일만 읽는다.
• 실행 기록 보는 법: GitHub 저장소 → 상단 Actions 탭. 초록 체크는 성공, 빨간 X는 실패다. 토요일에는 draw-night 이 몇 시간씩 "실행 중"(노란 점)인 것이 정상이다(기다리는 중). 겹친 예약이 회색 "Cancelled" 로 남는 것도 정상이다(기다리는 실행은 하나만 남긴다).
• 수동 실행: Actions 탭 → 왼쪽 update-lotto-data → Run workflow 버튼. 바뀐 게 없어도 최신 회차 페이지들을 네이버·Bing 에 다시 알린다. 토요일 낮에 draw-night 을 수동 실행하면 추첨까지 기다린다.
• 주의: 예약 실행은 저장소의 기본 브랜치(html)에 있는 대본만 돈다.

---

4. 유료화: 계좌이체 직접 판매로 전환 (2026-10-01)

결론: 카드 결제는 국내외 어디서도 막혀 있다. 그래서 내 계좌로 직접 받고, 입금되면 사람 손 없이(새벽에도) 서버가 서명한 이용권 키를 바로 내주는 방식으로 바꿨다. 입금 확인 · 키 발급 · 점검이 전부 자동이다. 사람이 하는 일은 드물게 오는 환불 문의를 확인하는 것 하나뿐이다. 키 발급 뒤 단순 변심 환불은 없다(약관 4조, 2026-10-02 개정). 코드는 완성돼 있고, 남은 것은 처음 한 번의 설정(아래 설치 순서)뿐이다.

왜 이 방식인가 — 검토한 결제 수단 (2026-10-01 조사)

수단	판정	이유
Polar	❌	"복권 관련 상품" 거절, 이의신청도 거절 (2026-09-27)
토스페이먼츠 · 나이스페이 등 카드 PG	❌	카드사 공통 등록불가 업종에 "로또번호 생성 서비스"가 그대로 적혀 있다 (나이스페이 등록불가 업종). 토스페이먼츠 약관 제17조도 복권을 판매금지 상품으로 둔다. 사업자등록을 해도 업종에서 막힌다
카카오페이 직접 연동	❌	가맹 불가 업종에 "투자/로또정보제공업" 명시, 비사업자 불가 (카카오페이 가맹 안내)
포트원	❌	PG를 묶어 주는 곳일 뿐 심사는 각 PG가 한다. "사행성(복권)" 입점 불가 (포트원 고위험 업종)
네이버 스마트스토어 · 네이버페이	❌	네이버페이 취급불가에 "복권", 그리고 2025-11-03부터 정보성·비실물 상품 판매 금지. README 옛 계획의 A2(스마트스토어)는 불가로 바뀌었다
Paddle · Lemon Squeezy · Gumroad · Stripe · PayPal	❌	전부 약관에 lottery 금지 (Polar와 같은 이유). Stripe는 한국 사업자 가입 자체가 안 된다
구글 플레이 결제	⏸️ 나중에	웹사이트에서는 못 쓰고 안드로이드 앱(TWA)으로 감싸야 한다. 로또 분석 앱의 인앱결제는 실제로 판매 중이다. 다만 사업자등록번호 + 통신판매업 신고번호, 테스터 12명 × 14일 비공개 테스트, 수수료 15%(2026-12-31부터 10%)가 필요하다. 판매가 검증된 뒤 검토
텔레그램 결제	❌	디지털 상품은 Telegram Stars만 허용. 사이트를 미니앱으로 다시 만들어야 하고, 수수료·환전 손실 약 35%, 정산이 TON(코인)으로 나온다. 국내 로또 이용자층과 맞지 않는다
비트코인 · 이더리움 · USDT	❌	기술적으로는 가능(직접 지갑, BTCPay 등)하지만, 2025-02부터 업비트는 본인 지갑·인증된 거래소로만 출금을 허용해 구매자가 내 지갑으로 보내기가 사실상 어렵다. $2짜리에 수수료도 맞지 않는다
페이앱(PayApp)	🔶 신청 가치 있음	비사업자도 가입 가능(카드 4%). "로또번호 생성 서비스"가 불가가 아니라 '리스크업종'(심사) 으로 분류된 유일한 곳 (페이앱 업종 안내). 통과하면 카드 결제를 켤 수 있도록 코드에 넣어 뒀다
계좌이체 (내 우리은행 계좌)	✅ 채택	심사·수수료가 없다. 업계 1위 로또 분석 서비스도 카드 없이 무통장입금과 인앱결제만 받는다

어떻게 돌아가나

구매자: 이용권 고름 → 입금자명 적고 주문
        → 화면에 내 계좌와 "주문마다 다른 금액"이 뜸 (예: 5,900원이 아니라 5,866원)
        → 계좌이체 (모바일은 "토스 앱으로 보내기" 버튼)
내 휴대폰: 은행 입금 알림을 받으면 그 내용을 서버로 그대로 넘김 (MacroDroid / 아이폰 단축어)
서버:   알림 속 금액 5,866원 = 입금 대기 주문 하나 → 그 주문이라고 보고 키 발급
구매자: 열어 둔 화면이 10초마다 확인하다가 키를 받아 바로 잠금 해제 (보통 1분 안)

• 주문마다 금액 끝자리가 다르다 (정가에서 1~99원 할인, 입금 대기 중인 주문끼리 겹치지 않게). 그래서 입금자명이 달라도(가족 계좌, 법인 계좌 등) 금액만으로 주문을 찾는다. 금액이 같은 대기 주문이 둘 이상이면 입금자명으로 한 번 더 좁히고, 그래도 애매하면 발급하지 않고 알린다. 구매자가 안내 금액을 무시하고 정가로 보내도(예: 5,866원 대신 5,900원), 입금자명이 맞는 대기 주문이 하나뿐이면 그 주문으로 보고 자동 발급한다. 덜 보냈거나 정가보다 많이 보냈으면 판매자 확인으로 넘긴다. "잔액 …원"은 금액으로 치지 않고, 같은 알림이 두 번 와도 한 번만 처리한다.
• 휴대폰 연결 지킴이: 휴대폰은 6시간마다 "ping"을 보낸다. 서버가 한 시간마다 확인해서 13시간 넘게 조용하면 텔레그램으로 알리고, 그동안 구매 화면은 "판매자 확인 뒤 열림"으로 바뀐다(구매자를 속이지 않게). 이때 들어온 주문은 관리자 페이지에서 "입금 확인"을 누르면 된다.
• 환불은 두 경우뿐이고, 메일로 소명자료를 받는다 (약관 4조, 2026-10-02 개정): 상품이 "보는 것"이라 키를 정지해도 본 내용은 돌아오지 않기 때문에 단순 변심 환불은 없다. 대신 전 회차·최근 10회차 통계를 무료로 보여 준다(전자상거래법 제17조 제2항 제5호의 시용상품 제공). 환불하는 경우는 ① 중복 결제(이체 확인증·입출금 내역 캡처) ② 작동하지 않음(오류 화면 캡처, 기기·브라우저 — 먼저 고쳐 주고 못 고치면 환불)뿐이고, [email protected] 로 주문번호·돌려받을 계좌·소명자료를 받는다(문의 페이지 "환불 신청"). 확인되면 관리자 → 그 주문 → "환불 처리(키 정지)" 를 누르고, 계좌이체는 돈을 직접 보낸다(카드는 결제 취소까지 자동). 약관에는 "이 밖에 법률이 청약철회를 인정하는 경우에는 그에 따른다"는 한 줄만 남겼다(법이 정한 권리는 약관으로 못 없앤다). 최종 문구는 법률 전문가에게 한 번 확인받기를 권한다.
• 자동 점검: 배포할 때마다, 그리고 매일 아침 6시 23분에 GitHub 가 실서버로 주문 → 입금 알림 → 키 발급 → 브라우저 확인 → 관리자 환불 처리 → 키 정지를 해 보고 지운다 (worker/test/live-smoke.mjs). 돈은 오가지 않는다. 실패하면 텔레그램과 GitHub 메일로 온다. 사람이 시험 구매를 할 필요가 없다.
• 이용권 키는 서버가 서명하고, 확인은 방문자 브라우저가 혼자 한다 (ECDSA P-256). 그래서 서버가 멈춰도 이미 산 사람은 열리고, 키를 외부로 보내지도 않는다. 형식은 worker/src/keys.js 첫머리.
• 페이앱이 승인되면: 비밀값 3개만 넣으면 "카드 · 간편결제"가 나타나고, 결제 즉시 키 발급, 관리자 환불 처리 때 결제 취소까지 자동이다. 휴대폰 연결도 필요 없다.
• 월 구독은 없앴다. 계좌이체는 자동 결제가 안 되기 때문이다. 1일·1주·1개월·평생 4종.

가격 (원화)

이용권	가격	기간
1일	1,500원 · 또는 300포인트(로그인 회원)	키 받은 때부터 24시간
이번 회차 (2026-10-21, 추천 카드)	2,900원	키 받은 때 판매 중인 회차의 토요일 밤 12시까지. 토요일 20:00(판매 마감) 뒤에 발급되면 다음 토요일 밤 12시까지
1개월	5,900원	키 받은 때부터 30일
평생	12,900원	제한 없음

• 1주 이용권(2,900원 · 7일)은 2026-10-21부터 팔지 않는다 — 이번 회차 이용권으로 바꿨다. plans.js 에 sale: false 로 남아 이미 판 키 · 주문 기록과 관리자 "직접 발급"에만 쓰인다(/api/config 에는 나오지 않고, 주문하면 bad_plan).
• 이번 회차 이용권: 기간이 날짜 수가 아니라 worker/src/plans.js 의 roundEndsAt 으로 입금이 확인돼 키를 발급하는 때 정한다. 결제 카드에는 "제1247회 · 10월 24일(토) 밤 12시까지 · 남은 시간 3일 08:59:59"를 1초마다 줄여 보여 준다(js/premium.js, 같은 셈). 키 종류 번호 6.
• 포인트로 1일 이용권: 1일 카드의 "포인트로 열기 (300P)"(로그인이 켜진 서버에서만 보인다). POST /api/me/point-pass — 쓸 수 있는 포인트(total − spent)에서 POINTS.dayPass(300)를 쓰고 24시간 키(키 종류 7 pday)를 준다. 랭킹 점수는 그대로. 그 키가 살아 있는 동안은 다시 못 쓴다. 키는 0원 주문(method: 'points')으로 남아 관리자 주문 목록 · 정지가 같은 길이고, 계정에도 붙어(ppass) 다른 기기에서 로그인하면 저절로 들어간다. 발급이 실패하면 포인트를 돌려준다.

바꾸려면 worker/src/plans.js 와 js/premium-config.js 두 곳을 같이 고친다(테스트가 둘이 다르면 실패한다). 코드 없이 금액만 바꾸려면 Worker 비밀값 PRICES 에 {"day":1500,"round":2900,"month":5900,"lifetime":12900} 형식으로 넣는다 — 결제 페이지가 서버 값으로 덮어쓴다. 포인트 값은 worker/src/community.js 의 POINTS.dayPass(이용약관 7조 문구도 같이).

설치 순서 (내가 할 일) — 이것만 하면 판매가 열린다

1. Cloudflare API 토큰 만들기: Cloudflare 대시보드 → My Profile → API Tokens → Create Token → 템플릿 "Edit Cloudflare Workers" → Zone Resources 에 lottodraw.kr 선택 → 만들기. 계정 ID는 대시보드 오른쪽(Workers & Pages 화면)에 있다.

2. GitHub 저장소 Secrets 넣기: 저장소 → Settings → Secrets and variables → Actions → New repository secret

   이름	값
   CLOUDFLARE_API_TOKEN	1번 토큰
   CLOUDFLARE_ACCOUNT_ID	1번 계정 ID
   ADMIN_TOKEN	관리자 페이지 비밀번호. 20자 이상 아무 문자열 (비밀번호 관리자로 생성 권장)
   BANK_NAME	우리은행
   BANK_ACCOUNT	받을 계좌번호 (예: 1002-123-456789)
   BANK_HOLDER	예금주 이름
   TELEGRAM_BOT_TOKEN · TELEGRAM_CHAT_ID	(강력 권장) 휴대폰으로 받는 알림: 휴대폰 연결 끊김, 자동 확인 못 한 입금, 자동 점검 실패, 새 주문. @BotFather 로 봇 생성 → 봇에게 말 걸기 → https://api.telegram.org/bot<토큰>/getUpdates 에서 chat id 확인. 없으면 관리자 페이지를 가끔 봐야 한다

3. 배포: 이 브랜치를 html 에 합치면 deploy-worker 가 저절로 돈다(또는 Actions 탭 → deploy-worker → Run workflow). 첫 배포 때 저장소(KV)가 자동으로 만들어지고 api.lottodraw.kr 이 연결되며, 이어서 자동 점검이 서명 키와 입금 알림 열쇠를 만들고 주문부터 환불까지 한 바퀴 돌려 본다. Actions 탭에 초록 체크가 뜨면 서버 쪽은 끝이다.

   • 도메인 연결에서 실패하면: Cloudflare → Workers & Pages → lottodraw-api → Settings → Domains & Routes → Add → Custom domain → api.lottodraw.kr.

4. 휴대폰 입금 알림 연결 (한 번, 약 5분): https://www.lottodraw.kr/admin.html 에 ADMIN_TOKEN 입력 → "입금 알림 연결" 카드의 안내대로 설정한다.

   • 안드로이드: MacroDroid 로 은행 앱 입금 알림 → 서버로 전달, 6시간마다 ping (2026-10-02 연결 완료: MacroDroid 프로, 카카오뱅크 앱 알림. 무료 버전은 7일마다 "기간 연장"이 필요하다)
   • 아이폰: 은행 입출금 문자 알림 신청 → 단축어 자동화(메시지 수신)로 전달, 하루 여러 번 ping
   • 1~2분 안에 카드 상태가 "✔ 연결됨"이 되면 끝. 그 뒤로는 새벽 입금도 저절로 열린다.
   • 가능하면 판매 전용 계좌를 쓴다. 다른 입금(월급 등)도 서버로 넘어가기 때문이다 (이용권 금액대가 아니면 무시하고 저장하지 않는다).

세금 · 신고 (판단은 내 몫)

• 사업자: 월데코 코리아(226-27-62319). 2026-10 일반과세자로 전환 — 통신판매업 신고가 필요하고(간이과세자만 면제), 이용권 매출은 부가세(10%) 신고 대상이다. 판매자 정보 표시 의무가 있다.
• 계좌이체 매출도 소득 신고 대상이다. 관리자 페이지의 주문 기록이 매출 장부 역할을 한다.

운영 메모

• 관리자 페이지: admin.html (검색 제외, 메뉴에 없음). 토큰은 그 브라우저에만 저장된다. 방문자 통계 비콘은 일부러 넣지 않았다.
• 결제 흐름(관리자 페이지 카드, 2026-10-21부터): 결제 페이지(이용권이 없어 결제 화면이 보인 것, 같은 브라우저 하루 한 번) → 고름("구매하기"로 주문서를 연 것) → 주문 → 입금(키 발급, 계좌이체 · 카드) → 포인트(포인트로 1일 이용권)를 오늘 · 7일 · 30일 · 전체와 하루씩, 주문률(주문 ÷ 결제 페이지) · 입금률(입금 ÷ 주문)까지. 앞의 둘은 화면이 /api/tap 으로 보내고(스크립트를 돌리는 로봇 · 광고 차단기는 빠진다), 뒤의 셋은 서버가 센다(화면에서 보내면 거절). 저장은 공유 · 출력 집계와 같은 e:<날짜>.
• 입금 대기 주문은 14일 뒤 저절로 지워진다. 입금 기한 안내는 72시간. 기한이 지난 주문은 새 주문 상한(전체 50건, 한 IP 3건)에 세지 않는다. 늦게 입금되면 관리자 페이지에서 그대로 확인하면 된다.
• 관리자 페이지는 2분마다(최대 1시간) 저절로 새로고침한다. Cloudflare 무료 요금제의 KV 목록 조회 한도(하루 1,000회)를 아끼려는 것이다.
• 발급된 키는 KV 에 남고, 키를 잃어버린 구매자는 주문번호·입금자명으로 찾아 "키 보기"로 다시 보내 준다.
• 자동 확인이 안 된 입금(금액을 다르게 보냄 등)은 텔레그램으로 오고, 관리자 페이지에서 그 주문의 "입금 확인 → 키 발급"을 누르면 된다.
• 입금 알림 연결 주소: https://api.lottodraw.kr/api/hooks/deposit (머리글 Authorization: Bearer 열쇠). 열쇠는 관리자 페이지에서 복사한다. 바꾸려면 GitHub Secret DEPOSIT_HOOK_SECRET 을 넣으면 그 값이 우선한다.
• 서명 키를 바꾸거나 KV 를 지우면 이미 판 키가 전부 무효가 된다. 건드리지 않는다.
• 서버 비밀값 목록과 설명: .github/workflows/deploy-worker.yml 첫머리, worker/src/index.js.
• 로컬 테스트: cd worker && npm test (Worker 와 브라우저 키 확인을 같이 검사).

지난 기록: Polar

날짜	내용	결과
2026-09-27	Go live 심사	거절 ("lottery-related products are not supported")
2026-09-27	1차 이의신청	거절
2026-09-28	2차 이의신청 (사람 검토)	대기 중 — 승인돼도 카드 결제 대안 하나가 늘 뿐, 계좌이체 구조는 그대로 둔다

이의신청용으로 넣은 영어 전환은 그대로 쓴다 (4-1번). Polar 설정값과 결제 링크는 커밋 6017b78 에 남아 있다.

4-1. 영어 전환은 어떻게 되어 있나

머리글의 KO / EN 단추로 바뀐다. https://www.lottodraw.kr/?lang=en 처럼 주소로 바로 열 수도 있고, 고른 언어는 그 브라우저에 기억된다.

문장을 고칠 곳은 두 군데뿐이다.

1. js/i18n-dict.js — 회차가 바뀌어도 그대로인 문장(메뉴, 버튼, 안내). HTML 에는 data-i18n="키" 만 붙어 있고 한국어 원문도 그대로 남아 있다.
2. tools/build-static-stats.js — 회차마다 숫자가 달라지는 해설. pEn(한국어, 영문) 처럼 영문을 나란히 적어 두면 생성기가 data-i18n-en 속성에 같이 찍는다.

주의할 점:

• 스크립트가 I18N.t() 로 꺼내 쓰는 키는 사전에 ko 도 적어야 한다. 화면에 붙은 문장과 달리 HTML 에 원문이 없기 때문이다.
• 언어를 바꾸면 페이지를 다시 읽는다. 차트를 부분적으로 다시 칠하는 것보다 한 번 새로 그리는 쪽이 어긋날 여지가 없다.
• 검색 노출은 한국어 기준이다. 기본 언어가 한국어이고 영문은 속성에만 들어 있어, 구글은 지금처럼 한국어 페이지로 읽는다. 영어권 검색까지 노리려면 /en/ 주소로 영어 페이지를 따로 생성해야 한다 (같은 사전을 쓰므로 번역을 다시 할 필요는 없다).

4-2. 애드센스 심사 반려 (2026-09-28)

사유: "가치 있는 콘텐츠가 부족함". 여러 번 같은 사유로 반려됐다.

기술적인 문제가 아니다. ads.txt, robots.txt, 광고 코드, 소유 확인 메타태그는 모두 정상인 것을 확인했다.

왜 이런 판정이 나오나 — 본문 글자 수

페이지	본문 글자 수
round/ 회차 페이지 × 1,243쪽	각 525자 (대부분 숫자)
top-prize.html	150자 — 표를 JS로 그려서 크롤러에게는 거의 빈 페이지
tax.html	767자
about.html	1,239자
probability.html	1,199자
통계 12쪽	950 ~ 3,306자 (표 안 숫자 포함)

심사자에게 이 사이트는 "같은 틀에 숫자만 바뀐 1,243쪽 + 설명 몇 장" 으로 보인다. 사람이 쓴 글은 다 합쳐도 원고지 40매가 안 된다. 회차 페이지는 검색 유입을 노리고 만든 것이지만, 심사에서는 대량 생성 콘텐츠로 읽힌다.

할 일 (순서대로)

• 1. top-prize.html 정적화. → 2026-10-02. 스크립트가 그리는 표와 글자 하나까지 같은 표를 <!-- seo:rows --> 표식 사이에 미리 박는다. 화면은 그대로(스크린샷 비교로 확인), JS 없이 읽으면 111자 → 1,470자
• 2. 사람이 쓴 글 6~8편. → 15편으로 블로그에 올렸다 (2026-10-02, 4-3번). 아래 후보 중 마지막 하나만 남았다: - 1등 당첨되면 실제로 어떻게 수령하나 (절차·서류·기한·세금) - 로또 세금 완전 정리 — 실수령액 계산기와 연결되는 사례 - 34번이 186회 나온 게 특별한가 — 표준편차로 읽는 법 - 사람이 직접 고르면 왜 당첨금이 쪼개지나 — 생일 번호와 분할 당첨 - 미출수·궁합수·AC값이 무슨 뜻인가 — 용어 정리 - 자동·수동·반자동의 차이 (16번째 글 후보)
• 3. 회차 페이지 보강 → 2026-10-18. noindex 대신 회차마다 다른 사실 · 링크 · 메모를 넣었다(4-7번). noindex 는 여전히 검색 유입과 맞바꾸는 마지막 수단 — 사용자 결정: 검색 유입을 잃지 않는다(2026-10-13)

글을 다 써도 복권 사이트라는 이유로 반려될 수 있다. 구글도 복권 관련 콘텐츠의 광고를 제한적으로만 허용한다. 그때의 대안은 카카오 애드핏 — 승인 기준이 훨씬 느슨하고 국내 사이트에 맞는다. 단가는 애드센스보다 낮다.

글을 쓸 때도 문구 규칙은 그대로다. 예측·적중률·추천 번호는 쓰지 않는다 (아래 문구 규칙).

4-3. 블로그는 어떻게 되어 있나

메뉴의 블로그(blog/index.html)에 사람이 쓴 글 16편이 있다. 4-2번의 "가치 있는 콘텐츠 부족" 반려에 대응해 2026-10-02에 올렸다. 머리글의 KO / EN 으로 영어도 된다.

content/blog/01-is-number-34-special.md      ← 한국어 원고. 글은 여기서 고친다
content/blog/en/01-is-number-34-special.md   ← 영어 원고. 파일 이름이 같아야 짝이 된다
        ↓  node tools/build-static-stats.js   (tools/build-blog.js 를 불러 쓴다)
blog/index.html                               ← 목록: 카테고리 단추, 앞부분 미리보기
blog/is-number-34-special.html                ← 글: 목차, 이어지는 페이지, 이전·다음 글
sitemap.xml                                   ← 블로그 주소 17개(목록 + 글 16편)가 같이 들어간다

• blog/ 의 HTML 은 직접 고치지 않는다. 생성기가 다시 만들면 덮어쓰인다.
• 원고를 고치면 node tools/build-static-stats.js 를 돌려 blog/ 와 같이 커밋한다. 잊어도 다음 일요일 자동 갱신 때 반영된다(워크플로가 blog/ 도 다시 만들어 커밋한다).
• 블로그 페이지는 머리글에 최신 회차가 찍혀 있어서 매주 자동 갱신 때 같이 바뀐다. 정상이다.
• 원고(content/)는 사이트에 올리지 않는다. 그대로 두면 GitHub Pages(Jekyll)가 원고를 /content/blog/…html 이라는 중복 페이지로 바꿔 올리기 때문에 _config.yml 에서 뺐다.

원고 쓰는 법

머리말(맨 위 --- 사이):

---
title: 34번이 186회 나온 게 특별한가 — 표준편차로 읽는 출현 횟수
slug: is-number-34-special      ← 주소 blog/<slug>.html. 한 번 정하면 바꾸지 않는다
category: 통계 읽기              ← 당첨 이후 · 통계 읽기 · 번호 고르기 · 확률 기초
description: 목록과 검색 결과에 나오는 요약 한두 문장
date: 2026-10-01                 ← 화면에는 안 보인다. 사이트맵·검색엔진용
pick: 3                          ← 흥미도 1~3. 클수록 목록 위쪽에 올 가능성이 크다 (빼면 1)
related: [frequency]             ← 글 끝 "이 글과 이어지는 페이지"
updated: 2026-11-01              ← (선택) 크게 고친 날. 사이트맵·검색엔진에 갱신일로 간다
---

• 영어 원고의 머리말은 title 과 description 두 줄뿐이다.
• related 에 쓰는 이름: frequency(많이 나온 번호) · gap(미출수) · pair(궁합수) · ac(AC값) · sum(합계) · even-odd(홀짝) · low-high(저고) · consecutive(연속번호) · prize-stats(1등 당첨자 수) · prize-tiers(2등·3등 당첨금) · probability(확률) · tax(실수령액) · top-prize(TOP 50) · generator(번호 생성기). 새 이름이나 새 카테고리는 tools/build-blog.js 맨 위의 RELATED · CATEGORIES 에 더한다.
• 본문 문법: ## 소제목(목차가 저절로 생긴다), 빈 줄로 나눈 문단(문단 안에서 줄을 바꾸면 줄바꿈), - 목록, 1. 목록, > 인용, | 표 |, **굵게**, `코드`, [링크](/tax.html). 링크는 사이트 뿌리 기준(/statistics-frequency.html, /blog/why-jackpots-split.html)으로 쓰면 생성기가 알맞게 고쳐 단다.
• 문구 규칙은 통계 페이지와 같다 — 예측·적중률·추천 번호는 쓰지 않는다(문구 규칙).

영어 원고는 한국어와 블록 수가 같아야 한다

한국어 블록 하나에 영어 블록 하나가 짝지어져 data-i18n-en 속성으로 들어간다. 그래서 소제목·문단·목록 항목·표 칸·인용의 수와 순서가 한국어와 똑같아야 한다. 어긋나면 빌드가 아래처럼 경고하고 그 글의 영어만 뺀다 (영어 화면에서 그 글만 한국어로 보인다).

  ! 블로그: en/04-why-jackpots-split.md 의 구조가 한국어와 다르다 — 7번째 블록: 한국어 p, 영어 h2. 이 글의 영어는 뺀다

빌드를 멈추지 않는 것은 일부러다. 매주 도는 자동 갱신이 원고 하나 때문에 서면 안 된다.

저절로 정해지는 것

• 목록 순서 (의도된 무작위): 방문할 때마다 흥미도(pick) + 0~1.6 사이 무작위 값으로 줄 세운다. 흥미도 높은 글이 대체로 위에 오고, 이웃한 단계끼리는 섞인다. 지금 흥미도: 3 = 도박사의 오류 · 의사난수와 셔플 (기대값·전망 이론 글은 구매 의욕을 꺾을 수 있어 1), 2 = 34번 · 당첨금 쪼개짐 · 명당 · 궁합수 · 연속 번호, 1 = 나머지(세금·수령·용어 등 실용 글). 섞는 폭은 tools/build-blog.js 의 PICK_JITTER
• 카테고리 단추: 그 카테고리 글이 맨 위로 가나다순(영어 화면은 알파벳순)으로 모이고, 나머지는 흐리게 그 아래에 남는다. 자리 이동은 홈 막대그래프 정렬과 같은 미끄러지는 애니메이션(움직임 줄이기 설정이면 바로 바뀜). '전체'를 누르면 처음 순서로 돌아간다
• 정렬 단추 [기본 순서 | 많이 읽은 순] (2026-10-18): 카테고리 단추 아래 오른쪽. 많이 읽은 순은 조회수(시작값 포함) 큰 순, 같으면 기본 순서. 카테고리를 골랐으면 그 카테고리 안에서도 조회수 순(나머지 흐린 글도 조회수 순). 기본 순서로 돌리면 카테고리 안은 다시 가나다순. 조회수를 받아 와야 보인다 — js/views.js 가 카드마다 data-n 을 적고 ld:views 를 알리면 목록 스크립트가 단추를 연다(서버가 안 되면 숨은 채). 고른 정렬은 기억하지 않는다(다시 오면 기본 순서)
• 날짜·읽는 시간은 화면에 표시하지 않는다 (2026-10-02 결정)
• 목록 미리보기: 본문 앞에서부터 표를 빼고 최대 5블록, 420자를 넘으면 멈춘다
• 이전 글 · 다음 글: 흥미도 높은 순, 같으면 파일 번호 순 (HTML 에 적힌 순서)
• 원고를 지우거나 slug 를 바꾸면 옛 blog/ 페이지는 생성기가 지운다
• 조회수 (2026-10-18): 글 제목 아래 카테고리 옆에 "조회 1,234"(영어 "1,234 views"). 글에 들어가야만 보인다 — 목록 카드에는 숫자를 적지 않고(같은 날 결정), 카드의 숨은 자리는 "많이 읽은 순" 정렬에만 쓴다. 숫자는 빌드가 아니라 js/views.js 가 Worker 에서 받아 채운다 — HTML 에는 빈 자리(.post-views[data-post])만 있다.
  • 세는 법: 글을 열면 글 이름만 POST /api/view 로 보내고 센 뒤의 수를 받는다. 같은 브라우저의 같은 글은 하루 한 번 (센 날을 localStorage ld_viewed 에 둔다 — 새로 고침으로는 오르지 않는다). 자동화 브라우저(navigator.webdriver)와 스크립트를 돌리는 검색 로봇 · 측정 도구(Googlebot · Yeti · HeadlessChrome · Lighthouse 등, Worker BOT_UA)는 세지 않는다. 우리 사이트(Origin)에서 온 것만, 같은 IP 1분 60번까지(VIEW_LIMIT). 광고 차단기 · 저장소를 막은 브라우저에서 연 것은 빠질 수 있다.
  • 읽기: GET /api/views?ids=글,글…(100개까지, 누구나, 60초 캐시). 목록은 카드의 글 이름을 모아 한 번에 읽는다.
  • 저장: Community 의 v:<글> 숫자 한 줄. 누가 읽었는지는 남기지 않는다(개인정보 처리방침 1번).
  • 0 은 적지 않는다. 숫자가 작은 동안 숨기려면 js/views.js 의 MIN 을 올린다.
  • 시작값 (2026-10-18): 직접 세기 시작한 때(2026-10-18 18:41 KST) 전의 방문은 Cloudflare Web Analytics 에만 있어서, 그때까지의 글별 페이지뷰를 시작값으로 넣는다. 보이는 수 = 시작값(Community vbase) + 직접 센 수(v:<글>). 같은 때에서 잘라 두 번 세지 않는다. Actions → seed-views → Run workflow(tools/seed-views.js): apply 를 끄면 표만(Actions 요약에 글별 페이지뷰 · 방문 표), 켜면 넣는다. 시작값은 통째로 갈아 끼워 다시 돌려도 두 번 더해지지 않는다. 비밀값은 CF_ANALYTICS_TOKEN(권한 "Account Analytics: Read", 없으면 배포용 을 써 본다) · · . Cloudflare 를 못 읽으면 칸에 대시보드에서 읽은 수를 JSON 으로. 관리자 API: (글별 직접 센 수 · 시작값), (). 페이지뷰는 새로 고침도 세서 하루 한 번만 세는 직접 센 수보다 조금 후하다

4-4. 검색 1면 전략 — 지금 구조 그대로 (2026-10-02)

목표: 구글에서 "로또 통계"로 superkts.com/lotto/stat/ 보다 위에 뜨는 것. 조건: 지금 보이는 화면·메뉴 구성은 바꾸지 않는다.

superkts 가 1면에 있는 이유

• 오래된 도메인이고 바깥 링크(다른 사이트가 거는 링크)가 많다. 순위 차이의 대부분은 이것이다.
• 검색어마다 그 말이 제목인 페이지가 있다(/lotto/stat/ "로또 통계", /lotto/stat/number, /lotto/recent/10, /lotto/stat/hi100·lo100, /lotto/download 엑셀). 표가 전부 HTML 글자로 박혀 있다.
• 광고가 많은 것, 디자인 완성도는 순위에 거의 영향이 없다.

우리 쪽 점검 결과

• 검색엔진용 기본은 이미 잘 돼 있다: 통계 12쪽·회차 1,243쪽이 정적 HTML, 자동완성 말로 고른 제목, 사이트맵, 구조화 데이터.
• 지금 구조에서 "로또 통계"를 맡는 쪽은 홈이다(제목 "로또 통계 분석 · 번호 생성기", h1 "로또 통계 · 번호 생성기", 통계 12쪽의 이동 경로 "로또 통계"도 홈을 가리킨다).
• 걸리는 점 하나: statistics.html. 9-15 전까지 무료 "로또 통계" 페이지였고 구글에는 아직 그 제목으로 색인돼 있다. 지금은 유료 결제 페이지라, 이 주소가 "로또 통계"로 노출되면 결제 화면으로 들어오게 되고 홈과 같은 검색어를 두고 다툰다.
• top-prize.html 표가 JS 로만 그려져 검색 로봇에게 빈 표였다 → 2026-10-02 고침(화면 변화 없음).

사이트 정의: "로또 데이터 플랫폼" (2026-10-11)

구글에서 lottodraw.kr 을 치면 AI 요약이 "16가지 특수 패턴을 제외해 번호를 생성하는 도구"라고만 소개했다. 머리글 문구("특수 패턴을 걸러내는 로또 6/45 번호 생성기"), 홈 설명, About 첫 문장이 모두 생성기 이야기였기 때문이다. 지금은 기능이 훨씬 많으므로 사이트를 "로또 데이터 플랫폼" 으로 정의하고, 검색엔진이 읽는 자리마다 같은 말을 쓴다.

자리	문구	고치는 곳
모든 페이지 머리글	"당첨번호부터 통계·당첨금까지, 로또 데이터 플랫폼"	js/i18n-dict.js brand.tag + 손으로 관리하는 페이지의 brand-tag + build-static-stats.js 틀(생성 페이지)
홈 설명(meta · og · twitter)	"lottodraw.kr은 로또 데이터 플랫폼입니다. …" + 통계 · 당첨금 TOP 50 · 실수령액 · 생성기	build-static-stats.js updateHome (SITE_KIND)
홈 통계 칸 아래 안내 문단	같은 첫 문장. 구글이 홈 검색 결과 설명으로 이 문단을 가져다 쓴다	같은 곳. 아래 목록 "통계와 기능 자세히 보기"에 TOP 50 · 실수령액 · 블로그 추가
홈 구조화 데이터	WebSite.description 에 기능을 하나씩 다 적는다	같은 곳
About	제목 · 설명 · 첫 문단 · 주요 기능 목록	about.html (영문은 사전 about.*)

홈 제목("로또 통계 분석 · 번호 생성기")은 "로또 통계" 검색어를 맡고 있어 그대로 두었다. 새 기능을 만들면 About 주요 기능 목록과 WebSite.description 에 한 줄씩 더한다. 구글 요약이 바뀌는 데는 다시 긁어 갈 때까지 몇 주 걸린다 — Search Console 에서 홈 · About 색인 생성 요청을 하면 앞당겨진다.

내가 할 일 (순서대로)

1. Search Console → 실적 → 검색어 "로또 통계" → 페이지 탭: 어느 주소가(홈? statistics.html?) 몇 위로 노출되는지 본다. statistics.html 이 잡혀 있으면 아래 "결정할 것" 1번을 검토한다. 2~4주마다 같은 화면을 적어 둔다.
2. 이번 변경 머지 뒤 Search Console 에서 top-prize.html 색인 생성 요청. 네이버 서치어드바이저에 사이트맵 다시 제출.
3. 바깥 링크 — 순위에 가장 큰 일이다. 링크 구매·자동 생성은 하지 않는다(구글 페널티). 뉴스 기사 댓글에 링크를 자동으로 다는 것도 하지 않는다(포털 약관 위반 → 계정 정지, 스팸 신고가 쌓이면 도메인 평판이 떨어져 검색 순위에 직접 손해. 2026-10-04 검토). 네이버 블로그·티스토리에 블로그 글 요약 + 원문 링크, 로또 카페·커뮤니티에서 통계 질문에 답하며 해당 페이지 링크, 매주 로또 통계 기사를 쓰는 매체에 데이터 출처로 제보.
4. 기대치: 도메인이 2025-12 시작이라 몇 달 단위로 본다. 미출수·궁합수·회차별 같은 세부 검색어에서 먼저 올라온다.

순위 기록 ("로또 통계")

Search Console → 실적 → 검색결과 → 기간 3개월 → + 새 필터 → 검색어 → "로또 통계"(검색어 포함) → 아래 페이지 탭. 2~4주마다 한 줄씩 적는다. 이 표가 "결정할 것"을 고르는 근거다.

날짜	노출되는 주소	노출수	클릭수	평균 게재순위	메모
(첫 기록)					머지 직후 한 번

결정할 것 (화면 영향 순)

안	화면 변화	효과
1. statistics.html 에 noindex	없음 (검색 결과에서만 빠진다)	"로또 통계" 신호가 홈 하나로 모인다. 대신 결제 페이지가 검색에 안 나온다
2. 통계 12쪽 맨 아래에 "이 통계와 이어지는 글"(블로그 링크)	페이지 맨 아래 목록 한 줄 추가	블로그 ↔ 통계 내부 링크. 아래 7번 할 일 10
3. draws.html 에 "엑셀(CSV) 내려받기" 단추	단추 하나 추가	"로또 당첨번호 엑셀" 검색어 (superkts /lotto/download 가 1면)
4. 무료 "로또 통계" 허브 페이지 + 메뉴 개편	메뉴가 바뀐다	"로또 통계" 전용 착지점. 보류(2026-10-02). 만들어 둔 것이 커밋 692f3b5 에 있다(되돌림 revert 커밋 앞)

4-5. 내 번호 · 추첨 결과 메일 (2026-10-17)

로그인한 회원 기능 두 가지. 결제 서버(worker/)에 붙였지만 결제와는 따로 돈다.

내 번호

• 마이페이지 내 번호: 회차(이번 회차 + 지난 7회)를 고르고 한 줄에 한 게임씩 적어 저장한다(한 번에 20게임). 홈 생성기에서 번호를 만들면 "이번 번호" 칸 왼쪽 위에 ＋ 내 번호 단추가 나타나 방금 만든 1게임 · 5게임을 이번 회차로 바로 저장한다(회차는 서버 시계로 — 토 20:00 뒤는 다음 회차).
• 등수는 저장하지 않는다. 마이페이지가 lotto-data.json 을 받아 그때그때 맞춘다. 그래서 토요일 밤 봇이 당첨번호를 갱신하면 따로 할 일 없이 등수(1~5등 · 낙첨), 맞은 번호(색칠), 최근 4/12/52회 · 전체 누적 횟수가 나온다. 추첨 전 회차는 "추첨 전".
• 한도: 한 회차 20게임, 최근 104회차(2년), 모두 600게임. 넘치면 오래된 회차부터 지운다. 같은 회차의 같은 조합은 한 번만.
• 탈퇴하면 내 번호와 메일 구독을 바로 지운다(관리자 "회원 삭제"도 같다).

추첨 결과 메일 (2026-10-18 — 처음의 "이번 주 생성 번호 메일"을 바꿨다)

• 왜 바꿨나: 생성 번호 5게임은 홈에서 "5게임"을 한 번 누른 것과 같아 메일로만 얻는 것이 없고, "매주 번호를 보내 주는 메일"은 번호 추천 업체와 모양이 같다. 같은 Resend 계정 · 도메인으로 나가는 이용권 키 메일의 도착률도 지켜야 한다. 그래서 회원이 궁금해하는 "내가 됐나"에 답하는 메일로 바꿨다. 생성 번호는 보내지 않는다(사용자 결정).
• 회원이 마이페이지에서 직접 켜고 끈다(예전 구독이 그대로 이어진다 — ms:). 켠 회원 가운데 그 회차 번호를 내 번호에 저장한 회원에게만 보낸다 (보낼 것이 당첨번호뿐인 주에는 보내지 않는다).
• 내용: 그 회차 당첨번호 + 보너스, 내 번호에 저장한 그 회차 번호 게임마다 등수 · 맞은 번호(요약 "3게임 중 1게임 당첨 — 5등 1게임" / "모두 낙첨"), "당첨 여부는 복권 실물과 동행복권에서 한 번 더 확인" 한 줄, 회차 페이지 링크(/round/<회차>.html — 등수별 당첨금 · 당첨 게임 수)와 마이페이지 링크, 수신 거부 · 문의. 제목 "[lottodraw.kr] 1246회 당첨번호와 내 번호 결과". 글자 메일(HTML 아님). 등수는 서버가 rankOf 로 맞춘다(마이페이지 화면과 같은 규칙).
• 보내는 때: 일요일 · 월요일 0921시(Worker 한 시간 예약 17 * * * *). 사이트의 lotto-data.json 맨 앞 회차가 그 회차가 된 뒤에만 보낸다(토요일 밤 갱신 — 늦으면 기다린다). 밤 9시 ~ 아침 9시는 보내지 않는다(광고성 메일 야간 전송 제한(21시8시)보다 넓게 — 이 메일은 광고가 없지만 같은 선을 지킨다). Resend 하루 한도에 걸리면 나머지는 월요일 9시에 이어 보내고, 월요일 21시가 지나면 그 회차는 그만둔다.
• 문구 규칙: 예측 · 추천으로 읽히는 말은 쓰지 않는다(시험이 "추천 · 예측 · 적중 · 생성 번호"가 없는지 본다). 이용권 홍보 · 광고는 넣지 않는다(넣으면 광고성 메일이 되어 별도 규칙을 따라야 한다).
• 수신 거부: 메일마다 링크(로그인 없이). 링크를 열면 "수신 거부" 단추가 있는 쪽이 나오고 눌러야 꺼진다(메일 보안 검사기가 링크를 미리 열어도 꺼지지 않게). 메일 앱의 "구독 취소"(List-Unsubscribe + List-Unsubscribe-Post 한 번 누르기)도 된다. 링크에는 구글 계정 번호 대신 회원 참조값과 서명(HMAC, 비밀값은 회원 저장소 mailkey 에 처음 쓸 때 만든다)만 들어간다.
• 어디까지 보냈는지는 mr:<회차> 에 둔다. Resend 에는 같은 묶음은 한 번만 보내라는 표시(Idempotency-Key result-<회차>-…)를 붙인다. 예전 생성 번호 메일 기록(mw:)은 같은 회차 결과 메일을 보낼 때 치운다.
• 실패가 사이트 · 결제에 번지지 않게: 한 시간 예약에서 지킴이(입금 알림 연결)와 따로 waitUntil 로 돌고 오류를 삼킨다. 결제용 KV 는 읽지도 쓰지도 않는다(시험이 확인). Resend 가 실패하면 다음 시간에 다시, 세 번 연달아 실패하면 그 회차는 멈추고 텔레그램으로 알린다. 다 보내면 "발송 끝: n통"도 텔레그램으로(0통이면 알리지 않는다).
• 관리자 페이지 설정 목록에 "추첨 결과 메일 — 구독 n명 · 1246회 발송 끝 n통 · 오늘 n/80통"(마지막으로 추첨한 회차).
• 켜는 데 새 비밀값은 필요 없다. 키 메일(RESEND_API_KEY · MAIL_FROM)과 구글 로그인이 켜져 있으면 저절로 켜진다. 선택: WEEKLY_MAIL_DAILY(하루 몇 통, 기본 80), WEEKLY_MAIL_FROM(보내는 사람, 기본 MAIL_FROM) — 이름은 처음 그대로 둔다.
• 코드: worker/src/index.js 의 resultMail · resultText, 저장은 community.js 의 mailPrepare · mailCommit. 시험: worker/test/mynumbers.test.mjs.

Cloudflare · Resend 무료 한도 안에서 도는 근거

한도 (무료)	이 기능이 쓰는 양	판단
Workers KV 쓰기 하루 1,000회 (결제가 쓴다)	0회. 내 번호 · 구독 · 발송 기록은 전부 회원 저장소(Durable Object Community, SQLite)에 둔다 — 좋아요 · 랭킹과 같은 곳. KV 는 손대지 않는다	결제 한도에 영향 없음
Durable Object 쓰기 하루 100,000행	번호 저장 · 지우기 1번에 1행(회원 한 명의 번호를 한 줄 k:<계정> 에 모은다), 메일 켜기 · 끄기 2행, 메일 1통에 1행(지난번 번호) + 묶음마다 2행. 회원 1,000명이 하루 다섯 번씩 저장해도 5,000행	5%
Durable Object 읽기 하루 5,000,000행	마이페이지를 열 때 4행(세션 · 계정 · 내 번호 · 구독), 메일 묶음(100명)마다 약 200행	매우 여유
Durable Object 저장 5GB	회원 한 명 최대 600게임 ≈ 30KB → 1,000명이 꽉 채워도 30MB	매우 여유
Workers 요청 하루 100,000회, 예약 실행 CPU 10ms	마이페이지 열 때 API 2번. 메일 번호 만들기는 회원 저장소 안에서 하고, 예약 실행은 당첨번호 파일 앞 1KB 만 읽는다	여유
Resend 하루 100통 · 한 달 3,000통 (키 메일과 함께)	결과 메일은 하루 80통까지(20통은 키 메일 몫). 일 80 + 월 80 = 한 주 160명까지(그 회차 번호를 저장한 구독자 수). 한 달로는 160 × 4.3 ≈ 690통	받을 회원이 160명을 넘으면 월요일 저녁까지 다 못 보낸다 → 텔레그램 경고. 그때 Resend Pro(월 $20, 5만 통, 하루 한도 없음)로 바꾸고 WEEKLY_MAIL_DAILY 를 올린다

(무료 한도 값은 2026-10 Cloudflare · Resend 문서 기준. 바뀌면 이 표를 고친다.)

4-6. 1등 판매점 통계 (2026-10-17)

자료는 어디서 받나 — 확인한 것

• 출처: 동행복권 홈페이지 "판매점 → 당첨 판매점 조회"(/wnprchsplcsrch/home) 화면이 부르는 공개 조회 https://www.dhlottery.co.kr/wnprchsplcsrch/selectLtWnShp.do?srchWnShpRnk=all&srchLtEpsd=<회차>(GET, 로그인 없음, JSON). 한 회차의 1등 · 2등 판매점이 한 번에 온다. 262회(2007-12-29)부터 있고 그 앞은 빈 목록이다. 1등은 자동 · 수동 · 반자동이 나오고 2등은 최근 회차만 방식이 나온다. 1245회 1등 10곳 = 1등 당첨자 10명, 2등 91곳 = 2등 91게임(prize-data.json)으로 한 줄이 한 게임임을 확인했다.
• robots.txt(2026-10-17): Disallow: /resources/, Disallow: /winImages/ 뿐 — 판매점 조회는 막혀 있지 않다.
• 이용약관(사이트 이용약관, 2026-10-17에 읽음): 자동 수집을 금지하는 조항은 없다. 금지 행위는 "회사가 게시한 정보의 무단 변경", "저작권 등 지식재산권 침해" 등이다. 판매점 이름 · 지역 · 회차는 사실 정보이고, 우리는 통계(횟수 · 비율)와 상위 목록만 보여 주며 출처를 밝힌다. 상세 주소 · 전화 · 좌표는 받지 않는다.
• 조심할 점(판단은 내 몫): 공개 저장소에 stores-data.json(전 회차 판매점 목록)이 올라간다. 저작권법의 데이터베이스 제작자 보호(제93조)는 "상당한 부분"을 복제하는 것을 막는데, 공공 수탁사업자가 공개한 당첨 사실 자료라 문제 될 가능성은 낮다고 보지만 확실하지 않다. 걱정되면 저장소를 그대로 두고 이 파일만 빼는 방법(생성기가 매주 전체를 다시 받는 대신 집계만 남기기)도 있다. 동행복권이 막거나 요청하면 바로 멈춘다(워크플로에서 "1등 판매점 수집" 단계를 지우면 끝, 페이지는 마지막 자료로 남는다).
• 예의: 평소에는 한 주에 4번(새 회차 + 최근 3회차) 요청, 요청 사이 0.3초. 처음 한 번 전체(984회차)를 받을 때만 1초 간격(--slow, STORES_MAX_MINUTES 로 시간 상한 — 끊겨도 받은 데까지 저장되고 다음 실행이 잇는다).

페이지가 말하는 것

1등이 자주 나온 곳은 많이 팔린 곳일 가능성이 크다. 판매점별 판매량은 공개되지 않으므로 같은 판매점의 2등 횟수를 판매량의 대리 지표로 쓴다 (2등은 한 게임 6/8,145,060 — 1등보다 6배 잘 나오고, 1등과는 다른 게임에서 나오며, 팔린 게임 수에 비례해 쌓인다). 1등 횟수 묶음별 평균 2등이 함께 올라가면 "운 좋은 곳"보다 "많이 팔린 곳"이라는 설명이 맞다. 문장은 자료에 따라 조건을 건다(함께 올라가지 않으면 단정하지 않는다). 순위 표 아래에는 "지난 기록일 뿐, 앞으로 1등이 나올 곳을 뜻하지 않는다".

4-7. 스팸 정책 점검 (2026-10-18)

애드센스 "가치 있는 콘텐츠 부족" 반려와 구글 스팸 정책(대량 생성 콘텐츠 남용 · 출입구 페이지 · 얇은 콘텐츠)에 생성 페이지가 걸리는지 실측했다. 2026-10-13 에 한 번 했고(PR #77), 그사이 html 이 많이 바뀌어 PR #77 은 닫고 2026-10-18 최신 코드(1246회 · 1등 판매점 포함)에서 다시 했다. 측정 도구는 일회용이라 저장소에 넣지 않았다.

실측 (고치기 전, 2026-10-18)

종류	쪽수	본문 글자	숫자	사람이 읽는 문장	페이지끼리 같은 정도	제목 · 설명	사이트맵	들어오는 링크(중앙)
회차	1,246	약 740	약 270	약 280 (전부 공통 문장)	숫자 빼면 97% (문장 틀 5가지뿐)	모두 고유	모두	3
통계 (12종 + 1등 판매점)	13	약 940	약 300	약 390	56% (주로 "다른 통계" 목록)	모두 고유	모두	15
2·3등 통계	1	3,290	1,160	1,770	—	고유	들어 있음	거의 모든 페이지
블로그 글	16	약 2,060	약 250	약 1,650	4%	모두 고유	모두	3 이상

글자 수는 <main> 안, 공백 · 그림(SVG) 글자 제외. "사람이 읽는 문장"은 표 밖 문단 중 한글 15자 이상인 것. "같은 정도"는 숫자를 #로 바꿔 같은 종류 페이지 절반 이상에 나오는 블록의 비율, 회차 "숫자 빼면 97%"는 5글자 조각 겹침. 중복 제목 · 설명 0, 설명 빠짐 0, 깨진 내부 링크 0, 사이트맵 누락 · 잘못 들어감 0, canonical 이상 0 — 바로 고칠 것이 없었다.

위험도

종류	스팸 정책	애드센스 · 품질	근거
회차	중	상	틀로 찍은 1,246쪽 = 생성 페이지의 대부분. 다만 실제로 찾는 정보(회차 당첨번호)와 진짜 자료(등수별 표)가 있고 다른 곳으로 몰아가지 않아 "순위 조작 목적" · 출입구 페이지로 보기는 어렵다
통계 13쪽	하	중	주제가 다 다르고 계산기 · 분포 표 · 그래프가 있다. 설명 문장이 짧은 쪽이 있다
2·3등 · 블로그	하	하	고유한 글

정책 문구는 구글 공식 문서를 직접 열지 못했다(작업 환경 네트워크가 developers.google.com 을 막음). 검색 결과 요약과 알려진 공식 문서 내용으로 판단했다 — 대량 생성 콘텐츠 남용은 "순위 조작이 주목적 + 더해 주는 가치가 적은 많은 페이지"(만드는 방법은 묻지 않음), 출입구 페이지는 "비슷한 검색어로 순위를 얻으려고 만든, 실제 목적지로 보내는 중간 페이지".

선택지와 결정

안	검색 유입	애드센스	작업량	매주 자동 갱신	결정
(a) 회차마다 고유 정보 보강	잃지 않음(주소 · 제목 그대로), 회차 사이 링크로 오히려 도움	도움(보장은 아님)	생성기 수정 + 메모 원고	그대로 — "당시" 기준이라 옛 회차가 매주 바뀌지 않음	✅ 채택
(b) 오래된 · 정보 적은 회차 noindex / 사이트맵 제외	그 회차 유입이 사라짐	도움	작음	조건만 넣으면 됨	❌ 사용자 결정(2026-10-13): 유입을 잃지 않는다
(c) 묶음 페이지로 합치고 canonical	주소가 바뀌어 순위를 다시 쌓는 동안 줄어듦	도움	큼(새 페이지 · 이동)	묶음 갱신 규칙 필요	❌ 같은 이유

(a) 의 주의점: 틀은 같고 숫자만 바뀐 문장을 늘리면 오히려 대량 생성 쪽 위험이 커진다. 그래서 문장 대신 표 칸 · 링크로, 문장은 "해당될 때만"으로, 그리고 사람이 쓴 메모로 넣었다. 후보마다 회차별로 값이 몇 가지로 갈리는지 재서 골랐다 (직전 출현 간격 1,244가지 · 가장 많이 겹친 지난 회차 974가지 · 당시 1인당 순위 1,232가지 → 채택, 판매액 증감 · "그 해 몇 번째"는 뺐다).

한 일과 결과

측정 (회차 1,246쪽)	전	후
모든 회차에 같은 설명 문장	약 280자	약 180자 (세금 설명을 한 줄 + 링크로, "당첨 게임 수는 따로 셉니다" 삭제)
페이지끼리 같은 정도 (숫자 포함)	39%	30%
같은 정도 (숫자 무시)	97%	96% — 같은 칸에 다른 자료를 담는 자료 페이지라 뼈대는 그대로
회차로 들어오는 링크(중앙)	3	8
회차만의 문장이 있는 쪽	0	49 (기록 · 이월 · 5개 일치 · 메모 9개) → 메모를 23개로 늘려 58쪽(2026-10-18)

그 밖에: 1회 "1~1회 출현" → "1회 출현", 사이트맵 회차 lastmod 를 2026-10-18 로(ROUND_FACTS_SINCE). 같은 자료로 두 번 돌리면 바뀌는 쪽 0. tax.html 설명이 208자로 검색 결과에서 잘릴 수 있다 — 다른 세션이 1등 평균 두 기준을 넣어 일부러 쓴 문장이라 손대지 않았다(필요하면 줄일 것).

다음

• 메모(content/round-notes.md)를 조금씩 늘린다 — 사람이 쓴 고유 내용이 가장 강한 신호다.
• 4~8주 뒤 Search Console 에서 회차 페이지의 색인 제외 사유 · 노출을 보고(7번 할 일) 애드센스 재신청.

4-8. 당첨번호 중복 (2026-10-18)

사용자 질문 "지금까지 완전히 같은 번호가 나온 회차가 있나?"에서 시작했다. 답은 없다(1~1246회, 보너스까지 7개로 봐도 없다). 한 번 답하고 끝내기보다 매주 바뀌는 숫자라 통계 페이지로 만들고, 설명(생일 문제)은 이미 다룬 블로그 09 에 한 문단 + 링크로 붙였다.

• 페이지(statistics-repeat.html): 회차 쌍 N(N−1)/2 개를 모두 견준다. 같은 번호 k개 쌍의 기대 = 쌍 수 × C(6,k)·C(39,6−k)/C(45,6). 1246회 기준 실제/기대: 6개 0/0.10 · 5개 21/22.3 · 4개 1,001/1,058 · 3개 17,361/17,406. "지금까지 한 번이라도 같았을 확률"은 생일 문제 곱 (1 − 1/T)(1 − 2/T)… 으로 9.1%, 50%를 넘는 회차는 3,361회(매주 한 번이면 2067년 무렵). 다음 회차가 지난 회차 중 하나와 똑같을 확률 1,246/8,145,060 ≈ 1/6,537.
• 문장 조건: 6개가 같은 쌍이 생기면 첫 문단 · 소제목 · 홈 목록 · 궁합수 문장이 그에 맞게 바뀐다. "실제가 기대와 가깝다"는 문장은 모든 줄이 기대 ± 3√기대 안일 때만(회차 쌍끼리 독립이 아니라 검정이 아닌 어림 기준).
• 링크: 홈 "통계와 기능 자세히 보기"(회차별 당첨번호 다음) · 궁합수 페이지 문단 · 확률 페이지("얼마나 드문 일일까" 문단 + 관련 통계, 회차에 따라 바뀌지 않는 숫자만 — lastmod REPEAT_SINCE) · 5개 일치 회차 21쪽의 "눈여겨볼 점" 문장(2등이 되는 786회는 한 문장 더) · 블로그 09 한 · 영(related: repeat, updated: 2026-10-18) · 사이트맵.
• 5개 일치 표는 휴대폰(360px)에서 옆으로 밀리지 않게 칸을 셋(회차 쌍 + 간격 · 같은 번호 · 다른 번호)으로 했다.

4-9. 판매점 지도 (2026-10-26)

생성기 · 통계와 따로 둔 페이지 store-map.html. 생성기 페이지에 기능을 더 얹지 않으려고 나눴다(사장님 결정). 가는 길(2026-10-27 메뉴 맨 오른쪽으로 다시 — 아래): 생성기 제목 아래 "판매점 지도 →"(PC), 휴대폰은 오른쪽 아래 낮/밤 단추 위 동그란 MAP 단추, 모든 페이지 바닥글 아래 큰 띠("🗺️ 로또 판매점 지도 보러 가기", 다른 사이트 광고 띠처럼). MAP 단추 · 띠는 js/theme.js 가 붙인다(지도 페이지 자신에는 없음). 홈 "사용법 보기"에 판매점 지도 · 낮/밤 · 채팅 단계를 더했다(숨겨진 단계는 빼고 센다).

• 지도: MapLibre GL JS 5.24.0(js/vendor/, BSD — 사이트에 직접 둔다, CDN 의존 없음) + OpenFreeMap "positron" 바탕(키 · 요금 없음, 상업 사이트 가능, © OpenStreetMap). 바탕 글자는 한글 이름(name:ko)으로 바꿔 그린다. 큰 나라 이름은 위쪽 도구와 겹쳐 감춘다.
• 모양 — "화이트 모형"(2026-10-26 사장님 결정, 제안 6가지 중 ②): 하얀 땅 · 연한 물 · 공원, 반투명 흰 건물(투명도 0.4) + 가는 윤곽선, 색은 판매점에만. 줌인하면 건물이 솟는다: 줌 14.6 → 16 사이에서 높이가 0 → 실제 높이(OpenMapTiles building 의 render_height), 줌 15를 넘으면 지도가 저절로 55° 기울고 13 밑으로 나가면 다시 평평해진다. 3D 단추로 손으로 기울이기/펴기(손으로 2D 를 고르면 13 밑으로 나갈 때까지 저절로 기울이지 않는다). 두 손가락으로 돌리기 · 기울이기도 된다. 모양 값은 js/store-map.js 의 whiteModel() · RISE 에 모여 있다.
• 막대 지도(제안 ④ — 6차에 뺐다, 아래 기록은 참고용. 처음엔 로그인 회원 기능 → 5차에 누구나): 위쪽 "막대" 단추 → 1등 · 2등 판매점을 기둥으로 세운다(1등 나온 곳 주황 · 높이 ∝ 1등 횟수, 2등만 나온 곳 파랑 · 낮게). 화면에서 늘 비슷한 굵기 · 높이로 보이게 — 높이는 줌 지수 보간(밑 0.5)이라 확대 · 축소하는 동안 끊김 없이 바뀌고, 굵기는 줌 0.25 단계마다 미리 만든 모양을 바꿔 낀다 (한 단계 차이 16%. 처음 1단계마다 겹쳐 흐리게 바꾸던 것은 바뀌는 동안 막대가 옅어져 깜빡였다 — 2026-10-26 사장님 지적으로 고침). 지금 줌 둘레 단계만 만들고 먼 단계는 지운다. 로그인하지 않았으면 로그인 창을 띄운다 — 서버에 구글 로그인이 꺼져 있으면 잠그지 않는다(다른 회원 기능과 같음). 잠금은 화면에서만(자료는 누구나 받는 store-map-data.json 그대로). "내 위치" 단추는 이 기기 안에서만 쓰고 서버로 보내지 않는다(위치정보법 신고 대상 아님 — 아래).
• 점: 1등 · 2등이 나온 판매점(인터넷 판매 · 위치가 없는 곳 제외). 크기 = 2등 + 1등 × 6(1등은 2등보다 6배 드물다 — 팔린 양을 짐작하는 값). 주황 = 1등이 나온 곳, 파랑 = 2등만 나온 곳. 위 단추로 끄고 켜고, "폐점 포함"(처음엔 끔 · 옅게). 이름 찾기(1등 많은 곳부터 20곳).
• 점을 누르면 카드: 상호 · 시도 시군구 · 1등(자동/수동/반자동) · 2등 횟수, "많이 팔린 곳일 가능성이 크다 · 어디서 사든 확률은 같다", 카카오맵 · 네이버 지도 링크. 네이버 · 카카오의 거리뷰 · 업체 사진은 그쪽 저작물이라 캡처해 싣지 않는다 — 링크로 넘긴다.
• 페이지 HTML: 시도별 1등 · 2등 표(지역 이름을 누르면 지도가 그 지역으로)와 설명을 박아 둔다 — 검색 로봇 · 지도가 안 뜨는 브라우저용.
• 자료: store-map-data.json(생성기가 stores-data.json 으로 매주 만든다, 약 0.5MB). stores-data.json 의 판매점에 좌표(소수 5자리)를 더했다 — 사업장 위치라 개인위치정보가 아니다. 처음 한 번 좌표까지 전 회차를 다시 받았고, 그 뒤로는 평소 갱신(새 회차 + 최근 3회차)이 새로 나온 판매점의 좌표를 채운다. 좌표가 있는 판매점이 1,000곳 아래면 지도 페이지 · 링크를 만들지 않는다.
• 광주 · 전남: 동행복권은 주소 앞을 "전남광주"(2026년 출범한 전남광주통합특별시)로 적는다. 통계 · 지도는 예전 회차와 견줄 수 있게 시군구로 나눠 적는다 — 구(동 · 서 · 남 · 북 · 광산구)면 광주, 시 · 군이면 전남(tools/update-stores.js 의 place). 2026-10-26 전체 다시 받기 때 시 · 군이 광주로 들어간 것을 고쳤다.
• 일반 판매점 층(2026-10-26, 칩 "일반 판매점", 처음엔 끔): 지금 로또 6/45 를 파는 전국 판매점(동행복권 "판매점 찾기" — 2026-10-26 9,142곳) 중 1등 · 2등 기록이 없는 곳(2,341곳)을 회색 작은 점으로. 칩을 처음 켤 때 store-map-all.json(약 130KB)을 받는다 — 첫 화면은 가볍게. 카드에는 "262회부터 1등 · 2등 기록이 없는 판매점"과 지도 링크. 켜 두면 이름 찾기에도 나온다(1등 · 2등 판매점 다음에).

다음 단계 (계획)

1. 일반 판매점 레이어 — 2026-10-26 완료(위).
2. 판매점 댓글 — 2026-10-27 완료(위치 인증 없이, 로그인 · 별명 회원). 인증샷 · GPS 현장 인증(회원): 아래 위치정보법 결론에 따라 신고 뒤 설계한다.

위치정보법 확인 (2026-10-26) — 댓글 · 인증샷에 GPS 현장 인증을 붙이려면

하는 일	신고	근거
판매점 위치를 지도에 보여 주기	필요 없음	판매점은 사업장이다. 개인위치정보는 "특정 개인"의 위치만 — 법인 · 장소 정보는 빠진다(법 제2조, 방통위 해설서)
"내 위치" 단추(지도에 내 위치 점만, 서버로 안 보냄)	필요 없음	위치정보를 이용자 단말기 안에서만 쓰고 사업자 시스템으로 보내지 않으면 신고 대상에서 빠진다(위치정보센터 안내)
지역 공유 링크(?area=서울+노원구, 2026-10-28)	필요 없음	지역 이름(시군구)만 주소에 넣는다. 내 위치 · 지도 좌표를 넣거나 서버로 보내지 않는다
GPS 현장 인증 — 휴대폰 위치를 서버로 보내 "판매점 100m 안"인지 확인	필요함 — 위치기반서비스사업 신고	회원 계정과 이어진 위치 = 개인위치정보(법 제9조). 신고 없이 하면 처벌 규정이 있다(1년 이하 징역 또는 1천만 원 이하 벌금이라는 해설)
GPS 확인을 휴대폰 안에서만 하고 서버엔 "통과"만 보냄	신고 부담은 줄지만 조작이 너무 쉽다(브라우저 개발자 도구로 통과값을 보낼 수 있다)	현장 인증의 의미가 없어 권하지 않는다

• 소상공인 특례(제9조의2): 소상공인 · 1인 창조기업은 사업 개시 후 1개월 동안 사전 신고 없이 시작할 수 있고, 계속하려면 1개월 안에 "소상공인등의 위치기반서비스사업 신고"를 한다. 서류: 소상공인확인서(또는 1인 창조기업 확인서) + 사업 내용 설명 자료, 수수료 없음, 전자민원센터(emsit.go.kr) 온라인 접수. 소상공인에서 벗어나면 일반 신고로 바꾼다. 기관 이름은 2025-10-01부터 방송미디어통신위원회(예전 방송통신위원회).
• 신고 뒤 함께 갖출 것(해설 자료 기준, 신고할 때 다시 확인): 위치기반서비스 이용약관 · 개인위치정보 수집 별도 동의, 개인정보 처리방침에 위치정보 항목, 위치정보 이용 · 제공 사실 확인자료 자동 기록 · 보관, 확인이 끝난 좌표는 저장하지 않고 바로 지우기(남기는 것은 "인증됨"과 판매점 번호뿐).
• 권장안: 소상공인 위치기반서비스사업 신고를 하고(무료 · 온라인), 서버에서 거리 확인 → 좌표 즉시 삭제. VPN · 해외 접속은 Cloudflare 가 주는 접속 국가 · 통신사(ASN)로 거른다 (해외 · 데이터센터 IP 거절, IP 지역과 GPS 가 크게 다르면 거절 — 완벽하지 않다, GPS 조작 앱도 막지 못한다 → "현장 인증" 정도의 장치).
• 참고: 국가법령정보센터 위치정보법 제9조 · 정부24 위치기반서비스사업 신고 · 위치정보센터 소상공인등의 신고 · 방통위 위치정보법 해설서(2022). 최종 판단은 법률 전문가 · 위치정보센터(lbsc.kr) 문의로 확인할 것.

5. 작업 방식과 주의사항

브랜치

브랜치란? 같은 저장소 안의 별도 작업 공간이다. 실제 사이트는 html 브랜치 하나에서 나온다.

• html이 실제 사이트다. 여기에 올라간 것이 곧바로 배포된다.
• Claude(웹)가 작업하면 claude/… 브랜치에서 고친 뒤 Pull Request(변경 제안서)를 만든다. GitHub에서 Merge 버튼을 눌러야 html에 합쳐진다.

⚠️ 옛 파일로 덮어쓰지 말 것

봇이 매주 html 브랜치에 직접 저장한다. 그래서 GitHub에 있는 파일이 항상 내 컴퓨터(Dropbox 날짜 폴더)의 파일보다 최신이다.

로컬에 있던 옛 파일을 GitHub 웹 업로드로 올리면 봇이 넣은 최신 회차가 이전 상태로 되돌아간다. 에러도 나지 않는다. 특히 조심할 파일:

lotto-data.json · prize-data.json · index.html · draws.html · statistics-*.html · sitemap.xml · round/ · blog/ · tax.html · top-prize.html · probability.html

수정할 파일은 항상 GitHub에서 최신본을 받아서 고친다.

낮/밤 모드 색 (2026-10-21)

• 새 CSS 에 흰 바탕 · 검은 글자를 박지 않는다. css/site.css 맨 위 "낮/밤 모드" 주석의 변수를 쓴다: 바탕 --bg · 카드/창/입력칸 --surface · 옅은 바탕 --soft --soft-2 · 글자 --fg --text --muted --faint · 선 --line --line-soft --line-strong · 파랑 글자/선 --brand · 흰 글자를 얹는 파란 바탕 --brand-bg · 강조 바탕 --hl --tint-*.
• 낮 모드 색은 그대로다 — 예전에 박혀 있던 색은 var(--surface, #fff) 처럼 원래 색을 기본값으로 둔 변수로 바꿨고, 낮에는 이 변수들을 정의하지 않는다. 그래서 낮 화면은 바꾸기 전과 픽셀까지 같다(17쪽 × PC · 휴대폰으로 견줘 확인). 밤 값은 :root[data-theme="dark"] 한 곳.
• 변수로 못 바꾸는 것(그림의 반투명 흰 막, 최근 10회차 칸 색 단계, TOP 50 그래프 선 색)은 파일 맨 끝 "밤 모드 손질"에서 고친다. 인쇄는 늘 낮 색.
• 공 색(번호 구간)은 낮 · 밤 같다. 생성기의 AC값 페이지 <style> 도 같은 변수를 쓴다(tools/build-static-stats.js).

문구 규칙

• "당첨 확률을 올려준다"는 뉘앙스의 문구는 쓰지 않는다. 로또는 모든 조합의 확률이 같다. "확률 상승", "적중률", "추천 번호", "AI 예측" 금지.
• 통계는 "지나간 기록이 이랬다"까지만 보여준다. 예측으로 읽히게 쓰지 않는다.
• 1등 평균 당첨금의 기본값은 당첨자 1인 기준(총당첨금 ÷ 당첨자 수, 동행복권 · 언론과 같은 값)(2026-10-14). 회차 평균(회차마다의 1인당 금액 평균)도 있다는 걸 알려 오해를 막는다 — 글에는 1인 기준을 앞에 쓰고 회차 평균을 함께(괄호 · 설명), 그래프는 평균 기준 단추로 고른다(처음은 1인 기준). 계산은 build-static-stats.js 의 firstPrizeAvg() · prize-chart.js 의 summarize(…, weight)
• 사이트를 한마디로 소개할 때는 "로또 데이터 플랫폼" 이라고 쓴다(2026-10-11). "번호 생성기"는 기능 가운데 하나로 적는다 → 4-4번

참고: 옛 계획 문서

Dropbox 260914 클로드 폴더의 README와 CLAUDE.md는 실제로 적용되지 않은 초기 계획이다(Python, templates/ 폴더, Cloudflare 배포 기준). 지금 구조와 다르니 그 문서의 파일 경로나 배포 설명을 따르지 말 것. 이 README가 기준이다.

---

6. 진행 기록

새 작업은 맨 위에 추가한다. 형식: 날짜 | 어디서(회사/집, 채팅/VS Code) | 한 일

날짜	어디서	한 일
2026-10-27	Claude Code 웹	판매점 지도 8차 — 0등 · 내 기록 · 답글 알림(#139~) — ① 0등(동행복권 인터넷)을 다른 판매점과 같은 규칙의 지도 층으로(붉은 버블 / TOP 50 붉은 별), 카드에 1등 · 2등 회차 ② 칩 "📍 내 기록": 다녀온 곳만 지도 + 목록, 내 댓글 목록 ③ 판매점 댓글에 답글(한 단계) + 답글 알림(마이페이지 "답글 알림 · 내 댓글", 머리글 빨간 점) ④ 휴대폰 댓글 안내 문구 11px. 다음에: 다녀왔어요 GPS 50m 인증 + 점수(위치기반서비스사업 신고 뒤). 워커 시험 85개 통과
2026-10-27	Claude Code 웹	판매점 지도 7차 — TOP 50 · 근처 찾기 · 댓글(#121~#130) — ① TOP 50 칩(1등 칩 왼쪽): 켜면 원은 감추고 TOP 50 만 노란 반짝이 별(사장님이 준 모양, 투명도 0.75) + 숨 쉬듯 빛나는 별 테두리, 평소엔 원 안에 1등 횟수 ② 바탕 지도의 도로 번호판(흰 네모) 감춤 ③ 카드의 1등 · 2등 회차는 토글로 하나씩, 휴대폰 카드 절반 크기(250px · 화면 38%) ④ 상호 이름표: 화면 안 판매점이 7곳 이하(휴대폰 기준, PC 15곳)일 때 모든 점 · 별 아래 ⑤ 이 근처 판매점 찾기: 지도 위 "⟳ ○○구 근처 판매점" → 화면 안 목록(1등 많은 순), "📍 내 위치 기준"이면 가까운 순 + 거리(위치는 기기 안에서만) ⑥ 판매점 댓글("다녀왔어요" 아래, 로그인 · 별명 회원, 다녀온 곳으로 표시한 사람은 "✓ 실방문자"): 블로그 댓글과 같은 서버 길 · 규칙(/api/comments, 글 이름 shop-판매점번호), 관리자 댓글 목록에서 store-map.html?shop=번호 로 그 카드, 개인정보 처리방침에 "판매점 댓글"(시행일 10-27) ⑦ 가는 길: 생성기 제목 아래 단추 → 메뉴 맨 오른쪽 "판매점 지도"(js/theme.js 가 붙인다). js/i18n.js 가 부르는 theme.js · account.js 에도 지문(LOAD_V) — 배포 직후 옛 theme.js 때문에 홈에 단추가 안 보였다 ⑧ 공유 이미지: 지도 OG 를 기본 OG 짜임으로, TOP 50 OG + 공유 주소 store-map-top50.html(별로 열림), 낮/밤 · 한/영은 사이트 값(지도 도구 줄에 KO · EN), 바닥글 띠 배경 다시 찍기(밤 모드는 TOP 50 별). 워커 시험 84개 통과
2026-10-27	Claude Code 웹(밤 리뷰)	회원 자료 백업 리뷰 · 고침(#115 머지 뒤) — ① 되살리기 묶음을 글자 수가 아니라 UTF-8 바이트로 재어 900KB씩(한글 댓글이 많으면 1MB 를 넘겨 413 으로 매번 같은 곳에서 멈추던 것). 서버도 본문을 바이트로 잰다. ② 회원이 있는 저장소에는 확인 없이 덮어쓰지 않는다 — 서버가 409, 화면이 "덮어쓰기"를 적게 한 뒤에만(백업 뒤 탈퇴한 회원 · 메일 구독이 되살아나기 때문). ③ 메일 발송 기록(mr: · mw: · mday)은 백업에서 빼고 되살릴 때도 건너뛴다(옛 기록이면 결과 메일을 또 보낸다). ④ 되살리기 끝에 POST /api/admin/restore/finish 가 회원 기록(u:) 기준으로 별명 색인 n: · 랭킹 색인 b: · 회원 수를 다시 맞춘다(나눠 받는 사이 별명이 바뀌면 어긋났다). ⑤ 랭킹 줄을 만드는 중이면 끝난 뒤에 비움, 되살리는 동안 단추 잠금, 확인창 시각을 한국 시간으로. 워커 시험 83개 통과, 가짜 API 로 409 → 덮어쓰기 → 마무리까지 브라우저 확인
2026-10-27	Claude Code 웹(밤 작업)	회원 자료 백업 · 되살리기 — 관리자 페이지 회원 명부 아래 "회원 자료 백업"(접힘). 내려받기: Worker GET /api/admin/backup?after= 가 회원 저장소(Community)의 줄을 1,000줄씩 내주고 화면이 끝까지 이어 받아 한 파일로(회원 수 상한 없음, 회원 명부의 2,000명 제한과 별개). 로그인 세션 는 빼고, 채팅은 다른 저장소라 처음부터 없다. : 같은 파일을 골라 확인창 뒤 700KB · 1,000줄씩 (이 길만 본문 1MB 까지)로 덮어쓴다 — 파일에 없는 줄은 지우지 않고, 되살린 뒤 랭킹 줄 · 조회수 시작값 · 메일 비밀값은 다시 읽는다. 이메일이 들어 있으니 비밀번호 관리자 · 암호 건 폴더에만 두라는 안내를 화면에. 주문 KV 는 넣지 않았다(할 일 3-1). 워커 시험 2개 추가(1,500줄로 끊어 읽기 · 세션 제외 · 빈 저장소에 되살려 회원 · 별명 · 다시 로그인, 1,000줄 · 1MB 넘으면 거절) — 전체 79개 통과. 가짜 API 로 관리자 화면 PC 1440px · 휴대폰 390px 확인(관리자 페이지는 원래 밤 모드가 없다)

7. 할 일

📍 다음에: "다녀왔어요"를 GPS 현장 인증으로 (2026-10-27 사장님)

• "다녀왔어요"는 내 위치가 그 판매점 50m 안일 때만 누를 수 있게. 그때부터 다녀왔어요를 누르면 점수도 준다(하루 상한 · 같은 곳 한 번 등 규칙은 그때 정함).
• 인증 시각도 기록(사장님 — 나중에 타임랩스 등에 쓰려고): 판매점마다 인증한 때를 남긴다(같은 곳을 여러 번이면 여러 번 · 상한은 그때). 좌표 자체는 저장하지 않고 "50m 안이었다"는 결과와 시각만 — 위치정보 보관을 최소로.
• 전제: 위치기반서비스사업 신고(사장님 할 일 — 위치를 서버에서 판정하면 위치정보를 다루게 된다, 4-9 · 개인정보 처리방침 · 약관도 함께 고침). 신고 전에는 지금처럼 위치 없이 표시만.

🔜 다음 스텝 — "로또 통계" 검색 (2026-10-02, 이 브랜치 머지 직후부터)

자세한 이유와 선택지는 4-4번. 화면은 바꾸지 않는 것이 전제다.

① 머지 당일 (10분)

• 사이트 반영 확인: https://www.lottodraw.kr/top-prize.html 이 전과 같은 화면으로 뜨는지 (배포는 머지 후 1~2분)
• Google Search Console → 맨 위 URL 검사 칸에 https://www.lottodraw.kr/top-prize.html → 색인 생성 요청
• Search Console → Sitemaps → sitemap.xml 다시 제출
• 네이버 서치어드바이저 → 요청 → 사이트맵 제출(https://www.lottodraw.kr/sitemap.xml) · 웹 페이지 수집(top-prize.html)

② 이번 주 (15분) — 판단 근거 모으기

• Search Console 에서 "로또 통계" 노출 주소·순위를 4-4번 순위 기록 표에 첫 줄로 적는다
• 결과에 따라 고른다
  • statistics.html(결제 페이지)이 잡혀 있다 → "결정할 것" 1번(noindex, 화면 변화 없음) 진행. Claude 에게 "4-4 결정할 것 1번 해줘" 라고 하면 된다
  • 홈이 잡혀 있다 → 구조는 그대로. ③ 바깥 링크에 집중
  • 아무 주소도 안 잡힌다(노출 0) → 아직 순위권(100위) 밖. ③ 바깥 링크가 답이다

③ 매주 꾸준히 — 순위에 가장 큰 일

• 바깥 링크 주 1~2개. 링크 구매·자동 생성 금지(구글 페널티). 할 만한 것:
  • 네이버 블로그·티스토리에 블로그 글 요약 + 원문 링크 (블로그 15편이 재료)
  • 로또 카페·커뮤니티에서 "많이 나온 번호", "미출수" 같은 질문에 답하며 해당 통계 페이지 링크
  • 매주 "로또 N회 당첨번호 통계" 기사를 쓰는 매체에 데이터 출처로 제보
• 2~4주마다 순위 기록 표에 한 줄

④ 4~8주 뒤 — 다시 판단

• 순위 기록을 보고 "결정할 것" 2번(통계 페이지 아래 블로그 링크) · 3번(엑셀 단추) 진행 여부
• 그래도 "로또 통계" 순위가 안 움직이면 4번(허브 페이지, 커밋 692f3b5)을 화면을 덜 바꾸는 방식으로 다시 검토

🔜 판매점 지도 확인 (2026-10-26 머지 뒤)

• https://www.lottodraw.kr/store-map.html 이 휴대폰 · PC 에서 잘 되는지 — TOP 50 칩(별) · KO/EN · 근처 판매점 찾기(내 위치 기준) · 판매점 댓글 · 상호 이름표, 홈 메뉴 맨 오른쪽 "판매점 지도"
• 11월 2일 이후 Actions → update-all-shops 가 성공했는지(첫 매달 갱신)
• 이번 토요일 추첨 뒤 store-map-data.json 이 새 회차로 바뀌었는지(매주 갱신에 지도 파일을 넣은 뒤 첫 확인)
• 로그인 켠 뒤 판매점 카드 "다녀왔어요"가 저장되는지 · Search Console 에 blog/lotto-store-extremes.html 색인 요청
• Search Console URL 검사 → https://www.lottodraw.kr/store-map.html → 색인 생성 요청 · 네이버 서치어드바이저 웹 페이지 수집
• (시간 날 때) 위치기반서비스사업 신고 — 하고 나면 인증샷 · GPS 현장 인증(3단계)을 붙인다(판매점 댓글은 위치 없이 2026-10-27 먼저 열었다). 방법은 4-9번

🔜 추첨 직후 반영 · 색인 요청 확인 (2026-10-04 머지 뒤)

• 머지 직후: Actions → update-lotto-data → Run workflow (또는 Claude 가 실행) → 마지막 단계 "네이버·Bing 색인 요청" 로그에 네이버: HTTP 202·Bing: HTTP 200/202 가 찍히는지
• 첫 토요일(10-10) 밤: Actions → draw-night 이 초록 체크로 끝나고, 이어서 update-lotto-data 가 21시 전후에 돌았는지. 사이트 round/1245.html 이 토요일 밤에 떠 있는지
• 1~2주 뒤: 네이버 서치어드바이저 → 리포트 → 수집 현황에서 회차 페이지가 추첨 당일 수집되는지
• (판단 대기) 당첨 판매점 정보 — 별도 전국 판매점 페이지는 보류 의견, 회차 페이지에 "이번 회차 1등 판매점" 표를 넣는 쪽을 검토 중. 데이터 출처(동행복권 판매점 조회)를 GitHub Actions 에서 먼저 확인해야 한다 (2026-10-04)

🔜 내 번호 · 추첨 결과 메일 확인 (2026-10-18 머지 뒤)

• 머지 직후: Actions → deploy-worker 가 초록 체크인지. 관리자 페이지 설정 목록에 "✔ 추첨 결과 메일 — 구독 n명"
• 내 구글 계정으로 마이페이지 → 내 번호에 지난 회차 번호 한 줄 저장 → 등수가 맞게 나오는지. 홈에서 번호를 만들고 "＋ 내 번호" → 마이페이지에 이번 회차로 들어오는지
• 마이페이지 → "메일 받기" + 내 번호에 이번 회차 번호 저장 → 추첨 다음 날(일요일) 09:17 이후 메일이 오는지(스팸함도), 등수 · 맞은 번호 · 회차 페이지 링크가 맞는지, 텔레그램 "발송 끝" 알림. 메일 아래 수신 거부 링크 → 단추 → 마이페이지에 "받지 않음"
• 그 회차 번호를 저장하지 않은 주에는 메일이 오지 않는지
• 개인정보 처리방침을 바꿨다(항목 추가 2026-10-17, 메일 내용 2026-10-18 — 시행일 2026-10-18). 회원에게 알리고 싶으면 공지(예: 채팅 · 블로그) 한 줄 — 법률 확인은 4번 "가격·약관 최종 확인" 때 함께
• 구독자가 160명을 넘기 전에 Resend 요금제를 정한다(4-5번 표)

🔜 당첨번호 중복 페이지 확인 (2026-10-18 머지 뒤)

• 머지 · 배포 뒤 https://www.lottodraw.kr/statistics-repeat.html 이 뜨는지. Search Console URL 검사 → 색인 생성 요청, 네이버 서치어드바이저 → 웹 페이지 수집(새 페이지라 IndexNow 만으로는 늦을 수 있다)
• 다음 토요일 밤 갱신 뒤 제목의 회차 범위 · "견준 회차 쌍"이 1247회 기준으로 바뀌었는지

🔜 1등 판매점 통계 확인 (2026-10-17 머지 뒤)

• 머지 · 배포 뒤 https://www.lottodraw.kr/statistics-stores.html 이 뜨는지. Search Console URL 검사 → 색인 생성 요청, 네이버 서치어드바이저 → 웹 페이지 수집
• 다음 토요일 밤: Actions → update-lotto-data 의 "1등 판매점 수집" 단계가 초록인지, 새 회차 1등 판매점이 페이지 맨 아래에 나오는지. 추첨 직후에 아직 안 올라왔으면 "다음에 다시"가 찍히고 일요일 · 월요일 예약이 채운다
• (판단) 공개 저장소에 stores-data.json 을 두는 것이 괜찮은지 — 4-6번 "조심할 점"

🔜 네이버 검색어 변화 확인 (2026-10-14 머지 뒤)

• 머지 · 배포 직후: 네이버 서치어드바이저 → 요청 → 웹 페이지 수집에 statistics-frequency.html · statistics-gap.html · about.html (제목 · 설명을 고쳤는데 IndexNow 는 데이터가 바뀔 때만 돌아 자동으로 알려지지 않는다. 구글은 Search Console URL 검사 → 색인 생성 요청)
• 2~4주 뒤 같은 화면(리포트 → 콘텐츠 노출/클릭 → 최근 60일 · PC + Mobile)을 열어 비교. 기준값(10-13 갱신, 60일): 클릭 141 · 노출 약 4,000 · CTR 3.5% / 검색어 "로또 많이 나온 번호" 노출 1,245 · 클릭 5 / "로또 장기미출수" 노출 158 · 클릭 14 / lottodraw 클릭 21 · 노출 53 / 페이지 statistics-frequency 노출 2,068 · 클릭 28 · statistics-gap 노출 280 · 클릭 32 · about 노출 29 · 클릭 16
• 볼 것: ① "많이 나온 숫자 순위" 계열 노출 · 클릭이 늘었나 ② 한글 "로또드로우" 검색어가 TOP 30 에 들어오나 ③ lottodraw 브랜드 클릭이 계속 about 으로 가나(제목을 바꿨으니 CTR 55% 가 떨어지지 않았나). 노출이 늘었는데 클릭이 그대로면 순위 문제 → 바깥 링크 쪽
• 이 표에는 평균 순위 열이 없다. CTR 으로만 짐작하고, 정확한 순위는 네이버에서 직접 검색해 본다

🔜 스팸 정책 점검 뒤 Search Console 확인 (2026-10-18 머지 뒤)

이 작업 환경에서는 Search Console 에 들어갈 수 없다. 머지 뒤 직접 본다. 첫 기록은 머지 직후, 그다음은 4주 · 8주 뒤. 숫자는 4-7번 아래에 적는다.

• 사이트맵 다시 제출 — 회차 1,246쪽의 lastmod 가 바뀌었다. Search Console → Sitemaps, 네이버 서치어드바이저 → 요청 → 사이트맵 제출
• 색인 생성 → 페이지: "페이지가 색인되지 않은 이유" 표의 사유별 쪽수를 적는다. 특히 "크롤링됨 - 현재 색인이 생성되지 않음"(구글이 읽고도 가치가 낮다고 본 것), "발견됨 - 현재 색인이 생성되지 않음", "중복 페이지 …", "대체 페이지(적절한 canonical 태그 포함)". 사유를 누르면 예시 주소가 나온다 → round/ 가 대부분인지 본다. 4주 뒤 줄었는지 비교
• 보안 및 직접 조치 → 직접 조치: "문제가 감지되지 않았습니다"인지. 있으면 사유를 그대로 Claude 에게 붙여 넣는다
• 실적 → 검색결과(기간 3개월) → + 새 필터 → 페이지 → URL 포함 /round/ 로 회차 페이지의 클릭 · 노출, 같은 방법으로 /blog/ · statistics-. "비교" 탭으로 머지 전후를 본다
• AI 요약(AI 개요)이 생긴 검색어: Search Console 은 AI 개요를 따로 나눠 보여 주지 않는다(일반 실적에 섞여 셈). 실적 → 검색어 탭에서 노출은 그대로인데 클릭률(CTR)만 떨어진 검색어를 고른다(예: "로또 1등 세금", "로또 확률"). 그 검색어를 시크릿 창으로 직접 검색해 AI 요약이 뜨는지, 우리 사이트가 출처 링크로 나오는지 적는다. 2~4주 간격으로 같은 검색어를 비교
• 네이버 서치어드바이저: 리포트 → 수집 현황(회차 페이지가 수집되는지) · 색인 현황(색인된 쪽수 추이) · 검색 유입(검색어 · 페이지), 진단 → 사이트 최적화(오류 없는지)
• 4~8주 뒤 숫자를 보고 애드센스 재신청. 그래도 반려되면 메모를 늘리는 쪽을 먼저(noindex 는 사용자 결정으로 보류)

🔜 블로그 조회수 확인 (2026-10-18 머지 뒤)

• 머지 직후: Actions → deploy-worker 가 초록 체크인지(VIEW_LIMIT 제한이 새로 생긴다)
• 블로그 글 하나를 열어 제목 아래 조회수가 뜨는지, 새로 고쳐도 그대로인지. 목록 카드에는 숫자가 없어야 한다
• (판단) 숫자가 작은 동안 숨길지 — js/views.js 의 MIN. 지금은 1 이상이면 보인다
• 시작값: Actions → seed-views 를 apply 끄고 돌려 표 확인 → apply 켜고 다시 (2026-10-18 — 배포용 토큰으로 읽혔다, 글 16편 · 페이지뷰 117)
• 블로그 목록에서 [많이 읽은 순] 단추가 보이고 누르면 조회수 큰 순으로 바뀌는지

다음에 할 일 (2026-10-02 정리, 위에서부터)

1. 키 메일 켜기 (Resend) — 2026-10-05 켜짐, 메일 수신 확인 1-1. [ ] 구글 로그인 켜기 — 4번 설치 순서 8. 15분. 켠 뒤 내 구글 계정으로 가입 → (가입 체험은 2026-10-11부터 꺼짐) ♥/$ 가 눌리는지, 탈퇴까지 한 번 해 본다
2. 서명 키 백업 확인 — 관리자 페이지 "서명 키 백업" 줄이 "✔ 맞음"인지. 아니면 "서명 키 백업 복사" 칸의 값으로 GitHub Secret LICENSE_PRIVATE_JWK Update → Run workflow. 비밀번호 관리자에도 보관
3. 비밀값 보관 — ADMIN_TOKEN·입금 알림 열쇠·텔레그램 봇 토큰을 비밀번호 관리자에 옮기기. 대화에 남은 값이 걱정되면 텔레그램은 BotFather /revoke, 열쇠는 Secret DEPOSIT_HOOK_SECRET 로 바꾸고 MacroDroid 헤더도 같이 바꾼다 3-1. [ ] 회원 자료 백업 (2026-10-13 기록, 2026-10-27 화면 · 서버 만듦) — 관리자 페이지 회원 명부 아래 "회원 자료 백업" 에서 내려받기 · 되살리기(세션 · 채팅 제외, 1,000줄씩). 남은 것(내 몫):
   • 머지 뒤 Actions → deploy-worker 초록 체크 → 관리자 페이지에서 한 번 내려받아 파일이 열리는지 · 회원 수가 명부와 같은지 본다. 받은 파일은 비밀번호 관리자 · 암호 건 폴더에만(이메일이 들어 있다)
   • 그 뒤로 한 달에 한 번 받는 습관(또는 Actions 자동 백업 — 그때는 어디에 둘지 먼저 정한다)
   • (판단) 주문 KV(order: 등)도 같이 받을지 — 지금은 빠져 있다. 관리자 페이지 주문 기록이 매출 장부 역할이라 함께 두면 좋지만, 구매자 연락처가 더 들어간다
   • (판단) 백업 파일 보관을 개인정보 처리방침에 적을지 — 법률 확인은 4번 "가격·약관 최종 확인" 때 함께
4. 가격·약관 최종 확인 — 1,500 / 2,900 / 5,900 / 12,900원, 약관 4조(환불은 중복 결제·작동 안 함만)는 법률 전문가에게 한 번
5. 부가세 신고 준비 — 일반과세자. 관리자 페이지 주문 기록이 매출 장부 역할
6. 판매 시작 알리기 — 사이트 첫 화면·블로그에서 5개월 통계로 오는 길 점검, 첫 구매 후기·문의 대응
7. ⏸️ 페이앱(카드 결제) 보류 (2026-10-02 결정) — 가입·서류·업종 심사 손이 많이 가는 데 비해 효과가 작다고 판단. 이 업종은 카카오페이·네이버페이 같은 간편결제가 막혀 있어 페이앱을 붙여도 "카드 결제창 하나 추가" 정도이고, 수수료가 붙으며, 승인도 불확실. 계좌이체는 "토스 앱으로 보내기"와 자동 발급으로 이미 편하다. 연동 코드는 남겨 두었으니 다시 하려면 대로 비밀값 3개만 넣으면 된다

끝난 일

• 판매 열기 (2026-10-02): Cloudflare 토큰 → GitHub Secrets → 배포·실서버 점검 → 휴대폰 입금 알림 연결(MacroDroid 프로) → 판매자 정보 → 텔레그램 알림 → 실제 입금 시험
• 환불 기준: 단순 변심 환불 없음, 중복 결제·작동 안 함만 메일 소명 (2026-10-02)
• 사업자: 월데코 코리아, 일반과세자, 통신판매업 신고 2025-경기파주-4164 (2026-10-02)
• 1일 이용권 1,500원 추가 (2026-10-02)
• 결제 직후 키 안내 강조, 주문 연락처는 이메일만 (2026-10-02)