일확천금 · lotto-lab
로또 6/45 와 연금복권720+ 전 회차를 통계로 분해하고, 매주 5,000원(로또) + 5,000원(연금) 을
어떻게 나눠 살지 계산하고, 실제 구매 기록까지 관리하는 정적 사이트입니다.
웹에서 바로 열기 → https://ljo0527.github.io/lotto-lab/
서버도, 빌드도, 데이터베이스도 없습니다. index.html·pension.html 이 브라우저에서
동행복권 공식 API 를 직접 호출해 전 회차를 받아오고, 결과를 브라우저에 캐시합니다.
매주 추천·채점·검증은 GitHub Actions 가 자동으로 계산해 커밋·배포합니다(아래 「자동화」 참고).
구성 (사이트 지도)
| 탭 | 파일 | 역할 |
|---|
| 이번 주 | brief.html | 이번 주 살 것(로또 AE, 연금 15순위), 지난주 채점, 전주 반영, 내 돈 요약. 매주 먼저 볼 페이지 |
| 로또 | index.html | LOTTO LAB — 로또 6/45 전 회차 통계, 조합 생성, 백테스트, 내 기록 |
| 연금 | pension.html | PENSION LAB — 연금복권720+ 예상 번호, 자리 통계, 공정성 검정, 발행·판매, 내 번호 |
| 순위 | rank.html | 로또 814만·연금 500만 조합 전체에 순위를 매기고 실제 당첨조합이 몇 위였는지 walk-forward 로 기록. 무한 순위 탐색기·CSV 내보내기 포함 |
| 검증 | validate.html | 모델 적합도 · 선택 규칙의 z이득 · 실구매 원장 · 순위 균등성을 한 페이지에서 보여주는 근거 문서. 매주 자동 갱신 |
| 기록 | record.html | 로또·연금을 합친 내 실제 구매 기록과 손익, 로또 1000회·연금 100회부터의 모의 원장·교차 적중 분석, 그리고 로또 매매 일지(최근 50회 재현 + 추첨 전에 남기는 일지). 「샀어요」로 이번 주 페이지에서 바로 기록됨 |
| (보관) | carryover.html | 2026-09-13(로또 1241회/연금 332회) 시점의 1회성 해설. 이후로는 brief.html의 「전주 반영」이 매주 그 역할을 대신함 |
모든 페이지 하단(모바일)·상단(데스크톱)에 같은 6탭 내비게이션(이번 주·로또·연금·순위·검증·기록)이 붙어 있어 어디서든 서로 오갈 수 있습니다.
5,000원 + 5,000원 — 매주 뭘 사는가 (정직하게)
바뀌지 않는 것: 당첨 확률. 로또 1등은 몇 번을 고르든 1/8,145,060, 연금복권 1등은 1/5,000,000 입니다.
번호 선택으로 확률(분자)은 절대 못 바꿉니다. 아래 두 가지만 손댈 수 있습니다.
로또 5게임(A~E) — 인기도 낮추기 + 겹침 줄이기
1·2·3등 당첨금은 고정된 몫을 당첨자 수로 나눠 받습니다. 그래서 "이 번호가 얼마나 인기 있었나"를
서로 다른 두 데이터로 각각 측정해 상관 0.895를 확인했고(아래 「찾아낸 것」 참고), 인기도가 낮은(=당첨돼도
나눠 가질 사람이 적을 것으로 보이는) 조합을 고릅니다. 바뀌는 건 당첨 시 나눠 갖는 인원이지, 당첨 확률이
아닙니다.
여기에 두 번째 축으로 5게임끼리 번호가 겹치는 정도(≤1개) 를 제한합니다. 개별 줄의 확률은 그대로이지만,
5게임을 하나의 묶음으로 볼 때 "이번 주에 뭐라도 하나 맞을 확률"은 겹침이 적을수록 올라갑니다.
| 5게임 중 1개 이상 당첨(주간) | 5,000원당 기대 회수액 |
|---|
| 무작위 5게임 | 11.36% (기준선) | 2,500원 (m=1 기준) |
| 이 저장소의 포트폴리오(겹침≤1) | 11.75% | 검증(validate.html)의 최근 실측치 — 계산 시점마다 바뀜 |
「11.36% → 11.75%」는 개별 줄의 당첨 확률이 오른 게 아니라, 5줄을 서로 다르게 짜서 묶음 커버리지를
넓힌 결과입니다. 인기도 쪽 효과는 재보정 walk-forward 기준 약 +7%(당첨 시 나눠 갖는 인원 기준,
확률 아님) — 최신 숫자와 신뢰구간은 항상 검증 페이지를 보세요, 이 문서엔 고정된 숫자를 박아두지 않습니다.
연금 5장 — 분산 vs 세트 (기대값은 같음)
연금복권720+는 당첨금이 고정액입니다. 2명이 당첨돼도 각자 월 700만원을 그대로 받습니다.
그래서 로또처럼 "나눠 갖는 인원"을 줄이는 레버 자체가 없습니다. 대신 5장을 어떻게 흩어지게 살지만
고를 수 있고, 어느 쪽을 골라도 5,000원당 기대값은 정확히 같습니다.
| 5장 구성 | 1장이라도 당첨 | 기대값 | 특징 |
|---|
| 분산(끝자리 5개 모두 다름, 기본값) | 50.0% | 3,750원 | 최대 당첨금은 낮지만(2등대) 매주 절반은 무언가 걸림 |
| 세트(같은 번호 × 5조) | 10.0% | 3,750원(동일) | 90%의 주는 0원이지만, 걸리면 1등+2등 4개가 겹쳐 최대 21.6억 |
기본은 분산입니다 — 기대값이 같은 채로 매주 당첨 확률(무언가라도)이 5배 높기 때문입니다.
번호 선택 자체(어떤 숫자를 고르는가)는 확률·기대값에 전혀 영향을 주지 않습니다. 영향을 주는 건
「5장이 서로 다른 끝자리인가, 같은 세트인가」뿐입니다.
이 규칙은 1243회(로또)/334회(연금)부터 적용됩니다. 그 이전 회차를 다시 계산하면(재현) 그 회차 당시의
옛 규칙 그대로 나오도록 만들어져 있습니다 — 그래야 지난주 채점과 원장이 어긋나지 않습니다.
이 도구가 실제로 찾아낸 것 (로또 인기도 모델)
전 회차를 다 뒤진 결과, 번호 선택으로 바꿀 수 있는 건 딱 하나였습니다.
| 통념 | 검정 결과 |
|---|
| 잘 나오는 번호가 있다 | ❌ 카이제곱 균일성 검정 통과 |
| 오래 안 나온 번호는 나올 때가 됐다 | ❌ 기하분포 그대로 (도박사의 오류) |
| 동반쌍에 패턴이 있다 | ❌ 이항분포 범위 안 |
| 추첨 순서에 신호가 있다 | ❌ 순번별 카이제곱 전부 잡음 |
| 당첨자 수는 줄일 수 있다 | ✅ 독립된 두 모델의 예측 상관 0.895 |
모델 A · 판매 기준 — 4·5등 당첨자 수가 기대치보다 얼마나 많았나
(기대 4등 = 총판매게임수 × 11,115 / 8,145,060). 4등 지수와 5등 지수의 상관 0.92.
모델 B · 구매방식 기준 — 1등 당첨자 중 수동 선택 비율이 그 시대 기준선보다 높았나.
자동은 815만 조합에 균등하게 뿌려지지만 수동만 사람이 좋아하는 번호로 몰립니다.
공식 API 의 winType1/2/3(자동/수동/반자동), 262회부터 974개 회차·1등 당첨자 9,174명분.
두 모델은 공유하는 데이터가 하나도 없습니다. 그런데 예측 상관이 0.895입니다.
유의한 특징 일곱 개가 전부 같은 방향이었습니다. 「조합 생성」 탭의 「최소 분배」 전략과 이번 주
페이지의 A~E 5게임이 이 모델을 씁니다.
원장 — 그래서 실제로 얼마나 맞았나
「매주 추천 5게임(로또)/5장(연금)을 산다」를 과거로 되돌려(walk-forward) 그대로 굴린 실측 기록이
검증(validate.html) 과 기록(record.html) 에 있습니다. 각 회차의 추천은 그 회차 직전까지의
데이터로만 다시 계산합니다 — 미래를 쓰지 않습니다.
핵심만 요약하면:
- 회수율은 평균이 아니라 중앙값으로 읽어야 합니다. 1등 꼬리 하나가 평균과 중앙값을 크게 벌립니다.
(무작위 5게임 × 300주 기준: 평균 54.5% vs 중앙값 18.0%.)
- 모델이 실제로 예측하는 건 당첨번호가 아니라 «그 회차의 인기도»입니다. out-of-sample R² 는
재보정 후 약 0.37 — 실재하지만 완만합니다.
- 한 주 실적으로 규칙을 판단할 수 없습니다. 회수금만으로 이 효과를 통계적으로 판별하려면 수백만
주가 필요합니다(검증 페이지 3층 참고). 판단은 모델 적합도·z이득 층에서 합니다.
실측 수치(회수율, R², z이득, 보정 p)는 계산할 때마다 바뀌므로 이 문서에 고정값을 적지 않습니다 —
항상 validate.html을 보세요.
모의 원장 — 로또 1000회·연금 100회부터 (가정)
검증의 「추천 원장」(1243회/334회부터, 규칙이 바뀐 시점부터)과는 별도로, 기록(record.html)에는
로또 1000회·연금 100회부터 매주 그 당시의 추천(로또 5게임·연금 5장)을 그대로 샀다면을 회차별로
다시 계산한 모의 원장이 있습니다. scripts/backfill.mjs가 매주 계산해 brief/sim-lotto.json·
brief/sim-pension.json으로 남기고, scripts/check-sim.mjs가 원자료에서 독립적으로 다시 계산해
대조합니다(불일치·미래 데이터 사용 여부까지 검사).
- walk-forward — 모든 회차의 추천은 그 회차 바로 직전까지의 데이터로만 다시 계산합니다. 미래를
훔쳐보지 않습니다.
- append-only — 이미 채점된(done) 회차는 그대로 두고, 매주 새 회차만 이어 붙입니다. 같은 입력이면
두 번 돌려도 (생성 시각 말고는) 바이트 단위로 같은 결과가 나와야 합니다 —
check-sim.mjs가 매주 그걸
확인합니다.
record.html은 이 모의 원장의 KPI(주·투입·수령·회수율·중앙값·등수 분포), 누적 손익 그래프,
**최근 회차 표(펼치면 전체)**를 보여줍니다. 위 「내 기록」·「추천 원장」과는 절대 합산하지 않습니다 —
어디까지나 "이 규칙을 그때부터 계속 굴렸다면"이라는 가정입니다.
교차 적중 — 우연의 일치이지 확률은 아닙니다
모의 원장에는 교차 적중 분석도 함께 있습니다: 어느 회차에 산 줄(로또 5게임·연금 5장)을 그 회차가
아닌 다른 모든 회차의 당첨번호와 대조해 "몇 개나 우연히 겹쳤는가"를 셉니다. 세 갈래로 나눕니다.
| 구분 | 뜻 | 증거로 쓸 수 있나 |
|---|
| after | 그 줄을 산 회차보다 나중에 나온 추첨과의 대조 | ✅ 그 줄은 미래를 몰랐으므로 유일하게 순수한 우연 비교 |
| same | 그 회차 자체 — 위에서 이미 보여준 실제 채점과 같음 | (참고용, 원장 그 자체) |
| before | 그 줄을 산 회차보다 이전 추첨과의 대조 | ❌ 선택 자체가 과거 데이터를 보고 골랐으므로(로또는 과거 1등 조합 회피, 연금은 과거 끝자리 분포로 점수화) 독립적인 우연이 아닙니다 |
그래서 「기록」 페이지와 「이번 주」의 「전주 반영」이 교차 적중을 알릴 때는 항상 after만 씁니다.
「기록」 페이지의 교차 적중 줄(로또·연금)은 2026-10-26 이론값 정리 뒤로 관측 개수만 보여 줍니다(기대 개수·p 는
화면에서 뺐습니다. brief/sim-*.json 의 값과 check-sim.mjs 의 검증은 그대로입니다). 회차 수백 개 × 5줄을
전부 맞대면 우연만으로도 로또 3등·연금 4등 상당의 일치가 종종 나옵니다 — 겹친 개수가 있다고 확률이 오른 게
아니고, 그냥 우연이 우연대로 나온 것입니다.
매매 일지 (기록 › 매매 일지)
로또를 «종목 → 비중 → 주문» 으로 나눠 사 봤다고 치는 재미용 모의 매매 일지입니다. 종목 네 개 — 패턴 · 자주 나온 번호 ·
오래 쉰 번호 · 무작위 — 가 매 회차 그 직전 회차까지의 당첨번호만 보고 줄을 냅니다(종목마다 최대 2,000줄, 앞에서
산 만큼이 매수). 펀드는 최근 10회에서 각 종목의 기준 100줄이 3개 이상 맞힌 정도를 비중으로 삼아 K장(5·10·20·50·100장,
기본 5장, 1장 1,000원)을 종목에 나눠 삽니다. 입력은 당첨번호·보너스뿐이고 상금은 채점에만 씁니다.
두 가지를 보여 줍니다.
- 최근 50회 재현(창) — 지금 규칙을 과거에 그대로 적용했다면 손익·최대 낙폭·무당첨 최장 기간·첫 5만원(4등)이 나온 회차.
매주 한 칸씩 밀립니다.
- 실제 제시 일지 — CI 가 추첨 전에 다음 회차의 주문(5장)과 «이번엔 이거?» 힌트 7줄을 적어 두고, 추첨 뒤에 채점합니다.
한 번 적은 행은 고치지 않는 append-only 이고(규칙표도 덧붙이기만), 추첨일 20:00 KST 이후에 만든 행은 «늦음» 으로
표시해 성적에서 뺍니다.
정직하게 읽는 법
- 어느 줄이든 당첨 확률은 같습니다(로또 1등 1/8,145,060). 이 일지는 확률을 바꾸지 않고, 위 A~E(나눠 갖는 인원을 줄이는
추천)와는 별개의 모의 매매입니다.
- 기준선은 이론값이 아니라 무작위 대조군의 실제 결과입니다 — 규칙 없는 «무작위» 종목, 그리고 같은 장수를 무작위로
산 «20벌 띠»(펀드 손익이 21개 중 몇 위인지, 사후 값이 무작위로도 어느 범위인지).
- 결과를 본 뒤 거꾸로 찾은 값(최소 장수 등)에는 «돌아보면(사후)» 를 붙이고 같은 칸에 무작위 20벌의 범위를 둡니다.
«최고 종목» 표시도, 앞날 예측(몇 회 뒤에 몇 등)도 없습니다.
- 이론값 안내: 로또 화면에서 «모의 매입 원장» 탭, 몬테카를로 시뮬레이터, 평균 대기, 이번 주 «기대 수령»/«한 장이라도 %»,
백테스트의 기대 횟수·σ 를 뺐고 기준선은 위 무작위 대조군으로 대신합니다(번호 통계·추첨순서 탭의 합계·이월수 이론값과 χ²·p 표,
rank.html 의 기대 점선·몬테카를로 띠·pMC 표, 검증 보드·carryover 의 «300주 walk-forward» 문구는 소유자 판단
전까지 그대로입니다. 목록은 ROADMAP.md 4-1).
데이터 흐름
lotto-history.json ─► scripts/trade-ledger.mjs (엔진 lotto-trade.js) ─► brief/trade-lotto.json ─► record.html 기록 › 매매 일지
└► brief.html 「이번엔 이거?」 카드
scripts/check-trade.mjs 가 엔진 코드를 쓰지 않고 처음부터 다시 계산해 대조합니다(누수·결정성 탐침, 일지 append-only 확인 포함).
record.html 은 CI 값을 바로 그리고, 이 기기에서 다시 계산한 지문이 CI 지문과 같으면 «일치 ✓» 를 표시합니다.
규격은 docs/trade-ledger.md.
순위 (무한 순위 · 당첨 순위 추적)
「사람은 추천 10위 안을 사지만, 실제 당첨번호는 몇 위권에서 나오는가?」를 재는 페이지입니다. rank.html
(내비게이션 「순위」 탭)에서 볼 수 있고, 매주 GitHub Actions 가 새 회차를 계산해 자동으로 갱신합니다.
무엇을 하는가
로또 1000회·연금 100회부터, 매 회차 R 마다 R-1 회차까지의 자료만으로(walk-forward — 미래를 훔쳐보지
않음) 가능한 모든 조합에 순위를 매깁니다: 로또는 8,145,060 조합 전부, 연금은 5,000,000 장(500만 조합) 전부.
그 무한 순위표에서 실제로 나온 당첨 조합이 몇 위였는지, 백분위로 몇 %였는지 를 모델별로 기록해 쌓습니다.
rank.html에서는 다음 회차의 순위표를 1위부터 끝까지 직접 넘겨 보거나, 내가 산 번호의 순위를 조회하거나,
상위 N개를 CSV 로 내보낼 수도 있습니다.
로또 4개 모델 · 연금 6개 모델
| 게임 | 모델 | 뜻 | 성격 |
|---|
| 로또 | pop 분배 모델 | 당첨 시 나눠 가질 사람이 적을 것으로 보이는 순서(「찾아낸 것」의 인기도 모델과 동일 z점수) | 추천 순서 — 확률 순서 아님 |
| 로또 | popf 분배 모델 + 주간 필터 | pop 과 같되, 합계·홀짝·연속·구간 필터를 통과한 조합만(통과 못하면 「제외」로 표시) | 추천 순서 |
| 로또 | hot 빈도 모델 | 최근 52회 많이 나온 번호에 가중 | 검정 대상 — 「잘 나오는 번호가 또 나온다」는 통념을 시험함 |
| 로또 | cold 미출현 모델 | 오래 안 나온 번호에 가중 | 검정 대상 — 도박사의 오류를 시험함 |
| 연금 | freq·cold·recent·gap | 자리·조별 빈도/역빈도/최근가중/미출현기간 가중 | 검정 대상 |
| 연금 | rand | 가중 없는 무작위 점수 | 대조군 — 애초에 적중을 주장하지 않음, 비교 기준선 |
| 연금 | site(사이트 설정 모델) | 그 시점 pension.html 예상 화면이 실제로 쓰던 모델의 별칭(회차마다 다를 수 있음) | 검정 대상 |
로또 pop/popf는 순서 자체가 「추천 순서」이지 「맞을 가능성 순서」가 아닙니다 — 위 「5,000원 + 5,000원」
절과 같은 원칙입니다. hot/cold(로또)와 연금 5개 모델은 반대로, 적중을 주장하는 쪽을 통계로 시험하는
대상입니다.
정직하게 읽는 법
- 우연 기준선(균등분포) — 추첨이 공정하면 어떤 모델로 순위를 매기든 당첨 조합의 백분위는 0~100% 에
균등하게 흩어집니다. 페이지의 모든 수치 옆에는 이 균등 기준선이 함께 나옵니다. 평균이 50%에서 크게
벗어나 있어야, 그것도 여러 회차·여러 검정을 거쳐야 「신호일 수 있다」고 말할 수 있습니다.
- 「확률을 높인다」라고 말하지 않습니다.
pop/popf 는 나눠 갖는 인원을 낮출 뿐이고, hot/cold/연금
모델은 검정 대상 주장이지 확정된 사실이 아닙니다.
- 구간(10분위) 전략도 walk-forward 로만 평가합니다 — 과거 회차에서 가장 많이 맞았던 10분위 구간을
골라 다음 회차를 맞히는 전략을 실제로 회차마다 앞으로만 계산해 적중률을 냅니다. 여러 모델·여러 구간을
동시에 시험하므로 다중검정 경고가 함께 표시됩니다 — 우연히 하나쯤 잘 맞는 조합이 나오는 건 정상입니다.
- 등수별 순위 분포 — 1등 한 개만이 아니라 로또 2
5등(6·228·11,115·182,780개 조합)과 연금 27등(4·45·
450·4,500·45,000·450,000장) 전체의 순위도 20칸 히스토그램으로 봅니다. 다만 같은 회차의 등수 조합들은
전부 같은 당첨번호를 공유해 서로 강하게 상관되어 있어서, 그 조합들을 통째로 풀링한 카이제곱 검정은
과대해석됩니다 — 그래서 회차 단위로 집계한 평균 백분위와 몬테카를로로 다시 뽑은 귀무분포로만
판단합니다(등수 조합 하나하나를 독립 표본처럼 세지 않습니다).
어디서 보는가
rank.html — 로또/연금 토글, KPI(평균 백분위·상위 10%/1%/1,000위/10위 안, χ²·KS p값), 10분위 막대,
회차별 백분위 추이, 회차 표, 구간 전략 결과, 그리고 등수별 순위 분포까지 한 페이지에서 봅니다. 다음 회차의
무한 순위표를 페이지·조회·CSV 내보내기로 직접 탐색하는 탐색기도 같은 페이지에 있습니다.validate.html(검증 보드) 4층 · 순위 균등성 — 기존 1~3층(모델 적합도·선택 규칙 z이득·실구매 원장)
다음에 순위 추적 요약(모델별 평균 백분위·KS p값·상위 10% 관측/기대·등수별 요약)이 한 층 더 붙어
rank.html 로 이어집니다.- 데이터가 아직 계산되기 전(최초 배포 직후 등)에는 「아직 계산 전」안내만 보이고, 계산이 끝나면 자동으로
채워집니다 — GitHub Actions 가 매주 새 회차를 walk-forward 로 이어 붙입니다(append-only, 기존 회차는
그대로 두고 새 회차만 더합니다).
자동화
매주 계산·배포는 GitHub Actions(.github/workflows/weekly.yml)가 합니다. PC를 켜 둘 필요가 없습니다.
- 트리거 —
main 브랜치에 push 하거나(설정 변경 등), 정해진 스케줄(연금 목 21:30·금 09:00 KST 재확인,
로또 토 22:30·일 09:00 KST 재확인)이 되면 자동으로 돕니다. workflow_dispatch로 수동 실행도 됩니다.
- 하는 일 — 동행복권 공식 API 에서 로또·연금 전 회차를 받고,
index.html/pension.html을 헤드리스
크로미움으로 실제로 띄워 그 안의 함수로 이번 주 추천·지난주 채점·검증 지표·실구매 원장을 계산합니다.
이어서 모의 원장(로또 1000회·연금 100회부터, scripts/backfill.mjs)을 갱신하고 scripts/check-sim.mjs로
독립 재검산하며, 추첨순서(공 나온 순서)를 scripts/fetch-order.mjs로 자동 수집·검증합니다. 로또 전 회차 스냅샷 뒤에는 lotto-history.json 만으로 매매 일지
(scripts/trade-ledger.mjs, 독립 검증 scripts/check-trade.mjs)를 이어 씁니다. 마지막으로
바뀐 brief.html/brief//validate.html/lotto-history.json/lotto-order.json만 커밋하고
GitHub Pages 로 배포합니다. 각 단계는 실패해도 나머지를 막지 않도록 짜여 있습니다(다음 주에 다시 시도).
dev/** 브랜치 — 같은 계산을 돌리되 커밋·배포는 하지 않고 결과 요약만 워크플로 로그에 주석으로
남깁니다. 로직을 고칠 때 실제 사이트를 건드리지 않고 검증하는 통합 테스트용입니다.- PC 는 더 이상 「데이터-갱신」이나 예약 작업이 필요 없습니다.
데이터-갱신.bat/update.ps1과
Cowork 예약 작업(setup/triggers/*.md)은 GitHub Actions 로 대체됐습니다. 자세한 내용은
setup/triggers/README.md를 보세요 — 예약 작업을 계속 켜 둘 경우 지켜야 할 규칙이 있습니다.
데이터 출처
당첨번호 · 1~5등 당첨자수 · 1게임당 당첨금 · 총판매액 · 1등 자동/수동/반자동 구성비
동행복권 공식 엔드포인트 /lt645/selectPstLt645InfoNew.do(로또), pt720/selectPstPt720WnList.do(연금).
추첨순서(공 나온 순서) — 공식 데이터에 없습니다.
공식 API 의 tm1~tm6WnNo 는 순서처럼 보이지만 전부 오름차순 정렬값입니다. 이 도구는 방송 기록을 정리해
둔 외부 아카이브를 씁니다. 「번호가 맞았다」와 「순서까지 맞았다」는 서로 다른 확인이라, 신뢰 수준을
세 등급으로 나눕니다.
| 신뢰 등급 | 뜻 | 해당 회차 |
|---|
| ok · 신뢰 가능 | 번호 집합·보너스는 공식 데이터와 항상 일치 + 순서 확인 방식은 구간마다 다릅니다(아래) | 1~328회: 원본(lottohell.com) 단독 — 번호 집합·보너스만 검증(순서를 대조해 줄 다른 출처가 없음). 329~1238회: lottospecial.kr 과 순서가 일치(불일치 4회는 suspect). 1239회~: lottospecial.kr·lottotapa.com 두 출처가 일치 |
| single · 단일 출처 | 번호 집합·보너스만 공식과 대조해 맞았음 — 순서 자체는 출처가 하나뿐이라 교차 검증 불가. 화면엔 표시하되 「신뢰 가능」 집계·순번별 χ² 검정에서는 기본적으로 뺍니다 | 397467회, 그리고 예전엔 「판정 보류」였던 626·635·637·642·643·652·655·664·666670·756회(14개) — lottospecial.kr 단독 자료로 채움. 1239회~ 구간은 두 출처 중 하나만 구해졌을 때(다음 실행에서 나머지 출처가 일치하면 ok로 승격) |
| suspect · 의심(총 6회) | 출처끼리 순서를 놓고 서로 다른 답을 주거나, 그 자체로 오름차순이라 실제 순서인지 자리표시자인지 구분 불가 | 329·583·723·816회(원본과 lottospecial.kr 불일치) · 645·824회(모든 출처가 오름차순 — 자리표시자 의심) |
397~467회는 원래 아카이브(lottohell.com)가 71회 연속 그대로 오름차순(=자리표시자, 실제 순서 아님)이었던
구간입니다. lottospecial.kr 이 이 구간의 실제 순서로 보이는 자료를 별도로 제공해 번호 집합·보너스는
확인했지만, 순서를 교차 검증해 줄 두 번째 출처가 아직 없어 single로 둡니다 — ok 만큼은 아니지만
예전의 「신뢰 불가」보다는 나은 상태입니다.
329·583·723·816회는 lottospecial.kr 이 원본(lottohell.com)과 다른 순서를 말합니다. 세 번째 출처인
lottotapa.com 은 이 네 회차 중 329회는 자료가 없고, 583·723·816회는 오히려 원본(lottohell.com) 쪽과
같습니다 — 그런데 lottotapa.com 과 lottohell.com 은 같은 계통으로 보입니다(773·775회를 포함해 자리표시자
패턴까지 그대로 일치). 그래서 lottotapa.com 은 원본을 독립적으로 검증해 주는 두 번째 출처가 되지
못합니다 — 원본 아카이브(1~1238회) 구간의 신뢰 판정엔 쓰지 않는 이유입니다. 이 네 회차는 결국 "출처
둘이 하나로 뭉쳐 다른 하나와 불일치"가 아니라 "서로 다른 두 계통(원본 계통 vs lottospecial.kr)이
불일치"인 상태라 suspect로 둡니다.
추첨순서 자동 누적(매주) — scripts/fetch-order.mjs가 매주 이 표를 최신 상태로 유지합니다.
- 1239회 이후(원본 아카이브 밖) 새 회차는 lottospecial.kr 과 lottotapa.com 양쪽에서 순서를 받아
비교합니다. 둘이 같으면
ok, 다르면 suspect, 한쪽만 구할 수 있으면 single로 남깁니다(다음 실행에서
나머지 출처가 확보되고 서로 일치하면 자동으로 ok로 올라갑니다).
- 원본 아카이브(1~1238회) 안에서는 lottotapa.com 을 쓰지 않습니다 — 위에서 설명한 대로 원본과 같은
계통이라 독립적인 두 번째 출처가 아니기 때문입니다. 대신 329
1238회는 lottospecial.kr 하나와만
대조하고, 그마저 없는 1328회는 원본 그대로 둡니다.
- 등급과 무관하게 6개 번호 집합과 7번째(보너스)가 공식 당첨번호와 일치하는지는 항상 먼저 확인합니다
— 여기서 어긋나면 등급을 매기지 않고 아예 싣지 않습니다(번호를 지어내지 않습니다).
index.html은 lotto-order.json을 비동기로 읽어 「나온 순서」 탭·추첨순서 필터의 범위를 넓힙니다.
single은 표시는 되지만(그 옆에 표식과 함께) 「신뢰 가능 회차」 집계와 순번별 χ² 검정에서는 기본
빠집니다 — 순서 자체가 교차 검증되지 않았기 때문입니다. 파일을 못 읽으면(오프라인 등) 조용히 기존
내장 아카이브만으로 동작합니다.- 공개 출처가 막히거나 사라지면 그 사실을 그대로 남기지, 순서를 추정해 채우지 않습니다.
현재 등급별 회차 수와 목록은 lotto-order.json이 최신 진실입니다 — 매주 자동으로 바뀌므로 이 문서엔
집계 숫자를 고정해 적지 않습니다.
파일
| 파일 | 역할 |
|---|
index.html | LOTTO LAB — 로또 6/45 딥다이브 도구 |
pension.html | PENSION LAB — 연금복권720+ 딥다이브 도구 |
brief.html, brief/ | 자동 생성되는 「이번 주」 페이지와 지난 호 아카이브 |
validate.html | 자동 생성되는 검증 보드 |
record.html | 내 구매 기록(로또+연금 통합) |
carryover.html | 2026-09-13 기준 1회성 해설 — 보관본, 더 이상 갱신되지 않음 |
site.css, site.js | 공용 스타일·내비게이션·PWA 스크립트 |
.github/workflows/weekly.yml | 매주 계산·배포 파이프라인 |
scripts/weekly-brief.mjs | 이번 주 브리핑 생성 |
scripts/validate.mjs | 검증 보드 + 실구매 원장 갱신 |
scripts/backfill.mjs, brief/sim-lotto.json, brief/sim-pension.json | 모의 원장(로또 1000회·연금 100회부터) 계산 |
scripts/check-sim.mjs | 모의 원장을 원자료에서 독립적으로 다시 계산해 대조(미래 누설·결정성 검사) |
scripts/fetch-order.mjs, lotto-order.json | 추첨순서(공 나온 순서) 자동 수집·검증·누적 |
scripts/fetch-history.mjs | lotto-history.json 전량 스냅샷 수집 |
lotto-trade.js | 매매 일지 엔진 — record.html 과 CI 가 같은 코드를 씀(rank-core.js 에 의존, 상수는 LOTTOTRADE.CONF 한 곳) |
scripts/trade-ledger.mjs, brief/trade-lotto.json | 매매 일지 생성(최근 50회 재현 + 다음 회차 제시 + append-only 일지) |
scripts/check-trade.mjs | 매매 일지를 엔진 없이 독립 재계산해 대조(누수·결정성 탐침, 일지 HEAD 대조) |
docs/trade-ledger.md | 매매 일지 규격(모델·산출 구조·일지 규칙·지문 바이트 규격) |
setup/triggers/*.md | (레거시) Cowork 예약 작업 프롬프트 — GitHub Actions 로 대체됨, 끄는 것을 권장 |
깃허브-올리기.bat / push.ps1 | 로컬에서 점검·커밋·push (선택 사항 — Actions 가 스케줄로도 돈다). 엔진은 옆 폴더 develop/tools/github-upload.ps1(공개 전 점검 → Actions 자동 커밋과 합치기 → 푸시). 은 시험 가지에서 Actions 성공을 본 뒤 main |
로컬에서 쓰기 (GitHub 없이)
모바일서버-켜기.bat 더블클릭 → http://localhost:8766/
Tailscale 이 켜져 있으면 창에 뜨는 http://100.x.x.x:8766/ 주소로 폰에서 접속됩니다.
index.html/pension.html 을 그냥 더블클릭해도 되지만, file:// 에서는 브라우저가 외부 요청을
막을 수 있습니다. GitHub Pages 나 위 서버로 여는 쪽이 확실합니다.
경고
이 도구는 예측하지 않습니다.
- 각 회차는 독립 시행입니다. 지난 회차는 다음 회차에 아무 정보도 주지 않습니다.
- 어떤 번호를 고르든 로또 1등 확률은 1/8,145,060, 연금복권 1등 확률은 1/5,000,000 으로 동일합니다.
- 로또의 구조적 기대 회수율은 판매액의 약 50%, 연금복권720+는 5,000원당 기대값 3,750원입니다.
장기적으로 구매액의 상당 부분은 반드시 사라집니다.
바꿀 수 있는 건 로또는 "터졌을 때 얼마를 나눠 받느냐"(당첨 인원), 연금복권은 "5장이 어떻게 흩어지느냐"
(당첨 분포)뿐입니다. 둘 다 확률이나 기대값 자체를 올리지 않습니다. 실측 숫자는 항상 validate.html을
보세요 — 이 문서의 어떤 숫자도 계산이 갱신되면 낡아집니다.
작성: 잼족
