728x90

Python 29

[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 분석도 넣고, 꽤 ..

프로그래밍/AI 2026.03.07

7편. API 서버 구축과 배포

이번 편에서 다루는 것지금까지 구축한 기능들:데이터 파이프라인XLM-R 임베딩추천 알고리즘LLM 설명 보강성능 최적화이제 이것들을 실제 서비스로 배포할 차례다.이번 편에서는 FastAPI 서버 구축, 인증 처리, 바이너리 빌드, 운영 서버 배포를 다룬다.FastAPI 선택 이유고려한 옵션 선택 여부 이유Django REST❌이 프로젝트에는 과한 기능Flask❌비동기 지원 부족FastAPI✅비동기, 타입 힌트, 자동 문서화 선택 이유:AI 추론이 느릴 수 있어 비동기 처리 필요Pydantic 기반 타입 검증이 ML 파이프라인과 잘 맞음자동 생성되는 API 문서 (Swagger UI)API 설계엔드포인트 설계메서드 경로 설명GET/api/v1/recommend/{student_id}학생별 추천 조회POST/..

6편. 성능 최적화 - CPU에서 27배 빠르게

이번 편에서 다루는 것이전 편에서 LLM을 활용해 강좌 설명을 보강했다. 하지만 심각한 성능 문제가 있었다.1개 강좌 보강: 32초1,200개 보강 예상: 10시간 40분 이번 편에서는 이 문제를 어떻게 27배 빠르게 개선했는지 다룬다.문제 현상 분석증상LLM 추론이 비정상적으로 느렸다.import timestart = time.time()result = model.generate(**inputs, max_new_tokens=150)elapsed = time.time() - startprint(f"추론 시간: {elapsed:.2f}초") # 32.14초 비슷한 크기의 다른 모델은 1~2초대였다. 뭔가 잘못되었다.가설 수립느린 원인으로 생각할 수 있는 것들:모델 크기가 큼토큰 생성량이 많음CPU 성능 ..

5편. LLM으로 강좌 설명 보강하기

이번 편에서 다루는 것이전 편에서 언급한 문제:강좌 설명이 부족하면 임베딩 품질이 떨어진다. 실제 데이터를 보니, 상당수의 강좌가 설명이 없거나 너무 짧았다.이 문제를 LLM(Large Language Model)을 활용해 해결했다.문제 분석데이터 현황강좌 설명을 분석해보니:상태비율예시설명 없음15%NULL 또는 빈 문자열이름과 동일20%"데이터베이스" → "데이터베이스"너무 짧음25%"SQL 기초 학습" (10자 미만)충분함40%2줄 이상의 설명 60%의 강좌가 불충분한 설명을 가지고 있었다.임베딩에 미치는 영향# 설명이 부족한 강좌course_1 = "데이터베이스"# 설명이 충분한 강좌 course_2 = "데이터베이스 설계 원리와 SQL 쿼리 작성법을 학습합니다. 정규화, 인덱스, 트랜잭션 처리를..

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

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

4편. 추천 알고리즘 설계 - 가중치 기반 개인화

이번 편에서 다루는 것임베딩이 준비되었으니, 이제 실제로 "이 학생에게 어떤 강좌를 추천할것인가?"를 결정하는 알고리즘을 설계한다.핵심은 학과 기반 추천과 관심분야 기반 추천을 어떻게 결합할 것인가였다.추천 전략의 고민옵션 1: 학과 기반만 (100%)학생의 소속 학과에 개설된 강좌만 추천 장점:전공 학점 취득에 유리단순하고 명확한 로직단점:학생의 개인적 관심사 반영 불가모든 학생에게 동일한 추천 결과차별화된 가치 제공 불가옵션 2: 관심분야 기반만 (100%)학생이 선택한 관심분야와 가장 유사한 강좌만 추천 장점:개인화된 추천학생 만족도 높음단점:전공과 무관한 강좌가 추천될 수 있음학점 인정 문제 발생 가능옵션 3: 하이브리드 방식 (선택)두 기준을 가중치로 결합최종 점수 = (학과 점수 × W1) +..

3편. XLM-R로 강좌 임베딩 구축하기

이번 편에서 다루는 것추천 시스템의 핵심은 "이 강좌와 이 학생이 얼마나 잘 맞는가?"를 계산하는 것이다.이를 위해 텍스트(강좌 설명, 학과 정보, 관심분야)를 수치로 변환해야 한다. 이것이 임베딩(Embedding)이다.임베딩이란?임베딩은 텍스트를 고정 길이의 숫자 배열(벡터)로 변환하는 기술이다."파이썬 프로그래밍 기초" → [0.23, -0.45, 0.12, ..., 0.67] (768차원)"웹 개발 입문" → [0.21, -0.42, 0.15, ..., 0.63] (768차원) 의미가 비슷한 텍스트는 비슷한 벡터를 가진다. 이 성질을 이용해 코사인 유사도로 두 텍스트의 유사성을 측정한다.모델 선택: 왜 XLM-R인가?고려한 옵션들모델특징검토 결과OpenAI text-embedd..

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

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

2편. 추천을 위한 데이터 파이프라인 설계

이번 편에서 다루는 것AI 추천 시스템의 첫 번째 단계는 데이터 확보다. 아무리 좋은 알고리즘도 데이터가 없으면 무용지물이다.이번 편에서는 외부 학사 API에서 데이터를 가져와 PostgreSQL에 저장하는 파이프라인을 어떻게 설계하고 구현했는지 다룬다.데이터 소스 분석필요한 데이터추천 시스템에 필요한 데이터를 먼저 정리했다.데이터 용도 특징학생 정보추천 대상 식별, 학과 정보5,000건+, 학기마다 변동강좌 정보추천 후보군2,000건+, 매 학기 갱신학과 정보학과 기반 필터링50건, 거의 고정비교과 활동추천 후보군500건+, 수시 등록관심분야개인화 요소100건, 고정학생별 관심분야개인화 매칭10,000건+, 학생이 직접 선택외부 API 구조학사 시스템은 REST API를 제공했다. 각 데이터별로 별도 ..

반응형