728x90

Python 26

[Python] 로또 분석 서비스를 만들어봤다 #8 - 로또 합계는 정규분포다

그리고 그게 뭘 의미하는가로또 분석 12주차. 처음으로 통계가 "통과"하는 검정을 만났다.12주째 매주 같은 일을 반복하고 있다. 데이터를 들여다보고, 가설을 세우고, 검정을 돌리고, "역시 아무 의미 없다"는 결론으로 끝난다. 그런데 이번 주에 검정 결과가 통과했을 때, 나는 코드를 다시 확인할 수밖에 없었다. 뭐가 잘못됐나?코드는 멀쩡했다. 결과도 진짜였다.익숙한 결론들지난 편에서 "번호마다 성격이 있다"고 했지만, 사실 거의 없었다. 12주 동안의 분석은 매번 같은 결론으로 끝났다 — 로또에 패턴은 없다.갭 패턴? 자기상관 거의 0"이제 쉰다"? p값 0.38, 의미 없음큰 수의 법칙? 차이가 오히려 벌어짐6회 쉰 번호 복귀? 출현율 13.3%로 랜덤(13.3%)과 정확히 같음매번 다른 가설을 세워..

[Python] 로또 분석 서비스를 만들어봤다 #7 — 번호마다 성격이 있다고?

⚠️ 이 글은 통계 분석 교육 목적이며, 로또 당첨을 보장하지 않습니다. 모든 조합의 당첨 확률은 동일하게 1/8,145,060입니다.시리즈 링크#1 로또 번호를 만들어 볼까?#2 로또 번호를 맞춰 볼까?#3 1,213회 데이터 기본 통계#4 "나올 때 됐다" — 도박사의 오류 증명#5 로또 공은 과거를 기억하지 않는다#6 27번의 전설, "빼면 나오는 저주"#7 번호마다 성격이 있다고? ← 지금 읽고 있는 글번호에 "성격"이 있을까?#6에서 27번의 전설을 다뤘다. 9회 중 7회 출현, 빼면 나오는 저주. 27번은 확실히 뭔가 "성격"이 있는 것처럼 느껴졌다.그래서 이번에는 다른 번호들도 파봤다. 1,200회 넘는 데이터에서 번호마다 정말 다른 패턴이 있는지.결론부터 말하면 — 있는 것처럼 보이지만, ..

[Python] 로또 분석 서비스를 만들어봤다 #6 — 27번의 전설, "빼면 나오는 저주"

⚠️ 이 글은 통계 분석 교육 목적이며, 로또 당첨을 보장하지 않습니다. 모든 조합의 당첨 확률은 동일하게 1/8,145,060입니다. 시리즈 링크#1 로또 번호를 만들어 볼까?#2 로또 번호를 맞춰 볼까?#3 1,213회 데이터 기본 통계#4 "나올 때 됐다" — 도박사의 오류 증명#5 로또 공은 과거를 기억하지 않는다#6 27번의 전설, "빼면 나오는 저주" ← 지금 읽고 있는 글27번이라는 번호가 있다이 시리즈를 시작하고 나서, 매주 로또 번호를 분석하고 30개 조합을 만들고, 추첨 후 검증하는 걸 반복하고 있다. 그 과정에서 하나의 전설이 탄생했다. 27번. 1206회부터 1214회까지 9회 동안, 27번은 7번 출현했다. 출현율 78%. 정상 출현율이 13.3%(6/45)인 걸 감안하면 5.9배..

[Python] 로또 분석 서비스를 만들어봤다 #5 — 로또 공은 과거를 기억하지 않는다

⚠️ 이 글은 통계 분석 교육 목적이며, 로또 당첨을 보장하지 않습니다. 모든 조합의 당첨 확률은 동일하게 1/8,145,060입니다. 시리즈 링크#1 로또 번호를 만들어 볼까?#2 로또 번호를 맞춰 볼까?#3 1,213회 데이터 기본 통계#4 "나올 때 됐다" — 도박사의 오류 증명#5 로또 공은 과거를 기억하지 않는다 ← 지금 읽고 있는 글"적게 나온 번호가 따라잡아야 하지 않나?"#4에서 "나올 때 됐다"가 도박사의 오류라는 걸 증명했다.그러면 이런 질문이 나온다."아니, 큰 수의 법칙에 의하면 횟수가 많아지면 각 번호의 출현 비율이 같아져야 하잖아. 그러면 적게 나온 번호가 결국 따라잡아야 하는 거 아냐?" 이 질문은 진짜 좋은 질문이다. 그리고 대부분의 사람이 큰 수의 법칙을 잘못 이해하고 있다..

[Python] 로또 분석 서비스를 만들어봤다 #4 — "나올 때 됐다"를 1,213회 데이터로 검증해봤다

⚠️ 이 글은 통계 분석 교육 목적이며, 로또 당첨을 보장하지 않습니다. 모든 조합의 당첨 확률은 동일하게 1/8,145,060입니다.시리즈 링크#1 로또 번호를 만들어 볼까?#2 로또 번호를 맞춰 볼까?#3 로또 분석 서비스를 만들어봤다#4 "나올 때 됐다"를 검증해봤다 ← 지금 읽고 있는 글이 전략 카드 기억하시죠?🔄 연속 미출현 (Consecutive Absence) "오래 안 나온 번호를 우선합니다" 신뢰도: 70% 서비스를 만들 때 이 전략에 "신뢰도 70%"라고 써놨다. 오늘은 이게 진짜인지 까본다."나올 때 됐다"의 논리로또를 사본 사람이라면 한 번쯤 이렇게 생각해봤을 거다."7번이 10회 연속 안 나왔으니까, 이번엔 나올 때 됐다." 직관적으로 그럴듯하다. 45개 중 하나가 10번이나 빠..

[Python] 로또 분석 서비스를 만들어봤다 — 10가지 전략의 알고리즘을 공개합니다 #3

⚠️ 이 글은 통계 분석 교육 목적이며, 로또 당첨을 보장하지 않습니다. 모든 조합의 당첨 확률은 동일하게 1/8,145,060입니다.시리즈 링크#1 로또 번호를 만들어 볼까?#2 로또 번호를 맞춰 볼까?#3 로또 분석 서비스를 만들어봤다 ← 지금 읽고 있는 글서비스를 만들었다작년에 #1, #2를 쓰고 나서... 멈출 수가 없었다."조합을 줄이는 필터를 더 만들면 되지 않을까?" "머신러닝 돌리면 뭔가 나오지 않을까?" "이걸 서비스로 만들면 사람들이 쓰지 않을까?"그래서 진짜로 만들었다. LottoLabs — 로또 번호 분석 서비스. Python + FastAPI 백엔드, scikit-learn 기반 추천 엔진, 10가지 분석 전략. 머신러닝도 넣고, Claude API 연동 AI 분석도 넣고, 꽤 ..

📝 로그 설정 문제: 에러 추적이 어려운 경우

🚨 이런 상황, 겪어보셨나요?"서버에서 간헐적으로 500 에러가 나는데, 로그에 아무것도 없습니다.""고객이 '결제가 안 된다'고 하는데, 재현이 안 됩니다. 로그라도 있으면...""로그가 너무 많이 쌓여서 디스크가 꽉 찼습니다.""개발 환경에서는 콘솔에 다 보이는데, 프로덕션에서는 어디에 로그가 남는지 모르겠습니다." Django 프로젝트에서 로그는 "잘 될 때는 필요 없지만, 문제가 생기면 가장 먼저 찾는 것"입니다. 그런데 정작 문제가 생겼을 때 로그가 없거나, 너무 많거나, 쓸모없는 내용만 있다면 장애 해결 시간이 기하급수적으로 늘어납니다.🔥 실제 상황: 장애는 발생했는데 단서가 없다새벽 3시, 모니터링 시스템에서 알람이 왔습니다. "주문 성공률 60%로 하락." 정상적으로 99% 이상이어야 ..

🎭 Mock 처리 부족: 외부 의존성 때문에 테스트가 불안정한 경우

🚨 이런 상황, 겪어보셨나요?"테스트를 돌리는데 외부 API가 실제로 호출되어서 결제가 됐습니다.""테스트가 네트워크 상태에 따라 될 때도 있고 안 될 때도 있습니다.""CI 서버에서 외부 API 호출이 차단돼서 테스트가 전부 실패합니다.""이메일 발송 테스트를 돌렸더니 고객한테 실제로 메일이 갔습니다." Django 프로젝트는 결제 시스템, 이메일 서비스, SMS 발송, 외부 API, AWS S3 등 수많은 외부 서비스와 연동됩니다. 이런 외부 의존성을 Mock으로 대체하지 않으면, 테스트가 느리고, 불안정하고, 심지어 실제 결제나 실제 메일 발송 같은 사고가 발생합니다.🔥 실제 상황: 테스트가 실제 결제를 일으키다한 스타트업에서 주문 기능을 개발하고 있었습니다.# services.pyimport ..

🧪 테스트 DB 오염: 테스트 간 데이터가 남아서 실패하는 경우

🚨 이런 상황, 겪어보셨나요?"테스트를 하나씩 돌리면 통과하는데, 전체를 돌리면 랜덤하게 실패합니다.""분명히 어제까지 통과하던 테스트가 오늘 갑자기 실패합니다. 코드를 안 바꿨는데요.""CI에서만 테스트가 실패하고, 로컬에서는 항상 통과합니다.""테스트 실행 순서를 바꾸면 결과가 달라집니다." Django 테스트를 작성하다 보면, 테스트 하나만 돌리면 당연히 통과하는데 여러 테스트를 함께 돌리면 예측 불가능하게 실패하는 경험을 하게 됩니다. 원인은 대부분 테스트 DB 오염 — 이전 테스트가 만든 데이터가 다음 테스트에 영향을 주는 것입니다.🔥 실제 상황: 통과했다 실패했다 들쪽날쪽 테스트E커머스 프로젝트에서 테스트를 작성하고 있었습니다.class ProductTest(TestCase): def..

🔀 API 버전 관리 부족: 기존 클라이언트와 호환성 문제

🚨 이런 상황, 겪어보셨나요?"상품 API 응답 구조를 바꿨더니 모바일 앱이 전부 크래시 났습니다.""필드 이름 하나 변경했을 뿐인데, 프론트엔드가 먹통이 됐어요.""구버전 앱 사용자한테 강제 업데이트 공지를 띄워야 하는데, 이미 별점 테러가 시작됐습니다.""외부 파트너사가 우리 API를 쓰고 있는데, 사전 공지 없이 응답 형식을 바꿔버려서 항의 전화가 왔어요." Django REST Framework(DRF)로 API를 운영하다 보면, 처음에는 버전 관리를 생각하지 않습니다. "우리 앱이랑 우리 프론트만 쓰니까 맞추면 되지" 하고 넘어가죠. 그런데 서비스가 성장하면서 모바일 앱, 웹 프론트엔드, 외부 파트너사, 서드파티 연동이 동시에 같은 API를 호출하게 되면, 필드 하나 바꾸는 것이 전쟁의 시작이..

반응형