Unorganized honesty

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

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

이 글은 『서버 개발 수기』 시리즈의 세 번째 글이다.지난 회에서는 서버의 3계층 구조를 살펴봤다.오늘부터 Layer 2 안으로 들어간다. 첫 번째는 락.※ 이 시리즈에서 다루는 서버 코드는 Project-AO(Ancient Origin)라는 가명으로 부른다. 화장실 이야기부터 하자스레드 8개가 돌고 있다. 패킷이 들어올 때마다 버퍼를 하나 빌려야 한다. 버퍼는 공용이다.화장실이라고 생각하면 된다. 스레드 1이 들어가서 문 잠근다. 스레드 2가 와서 문을 당겨본다. 잠겼다. 기다려야 한다.문제는 이 "기다림"을 어떻게 하느냐는 거다.내가 SI에서 쓰던 건 델파이 같은 4GL 도구였다. DB에 직접 붙여서 화면 만들면 끝. 소켓이니 스레드니 하는 세계가 아니었다. 그 후에는 웹을 했는데, 동접 1~2만도 ..

우리는 태어날 때 하나의 모델로 배포된다. AI를 조금이라도 아는 사람이라면 프리트레인드 모델(pretrained model)이라는 말을 들어봤을 것이다. 방대한 데이터로 기본적인 언어 능력을 학습한 상태, 아직 특정한 용도로 특화되지 않은 상태의 모델. 인간도 마찬가지다. 유전자가 뇌의 기본 아키텍처를 설계하고, 초기 가중치를 설정한다. 어떤 모델은 불안에 민감한 구조로 태어나고, 어떤 모델은 좀 더 둔감한 구조로 태어난다. 하지만 아직은 아무것도 정해지지 않은 상태다. 그리고 인생이 시작된다. 파인튜닝이 시작된다.파인튜닝(fine-tuning)이란 이미 학습된 모델에 새로운 데이터를 넣어 특정 목적에 맞게 조정하는 과정이다. 우리의 삶이 정확히 그렇다. 부모의 말투, 친구의 배신, 첫사랑의 온기, 직..

이 글은 『서버 개발 수기』 시리즈의 두 번째 글이다.지난 회에서는 20년 만에 코드를 다시 열어본 이야기를 했다.오늘은 본격적으로 코드를 들여다보기 전에, 이 서버의 전체 구조부터 살펴본다.※ 이 시리즈에서 다루는 서버 코드는 Project-AO(Ancient Origin)라는 가명으로 부른다.SI 서버와 게임서버는 다르다사실 이것부터 Claude한테 물어봤다. "내가 SI에서 하던 서버랑 게임서버는 뭐가 다른 거야?" SI에서 내가 알던 서버는 단순했다. 사실 단순한지도 몰랐다. 프레임워크가 다 해주니까 스레드가 어떻게 돌아가는지 신경 쓸 일이 없었다. 요청 들어오면 처리하고 응답하면 끝. 그 안에서 스레드가 어떻게 생기고 어떻게 관리되는지는 내 영역이 아니었다.동시 접속 200명? 스레드 200개...

이 글은 『서버 개발 수기』 시리즈의 첫 번째 글이다.2006년산 MMORPG 서버 코드를 2026년에 Linux로 포팅하는 과정을 기록한다.그 시절 이야기SI로 시작한 나의 개발 커리어, 항상 아쉬웠던 게 있었다.빵빵한 서버 사양을 가지고 겨우 저걸 돌리고 있나? PC 스펙은 해마다 올라가는데 실제 리소스의 10%도 안 쓰고 있군. 그래서 생각했다. 어떤 분야가 컴퓨팅 파워를 한계까지 몰아서 쓸까? 게임이었다.그런데 게임업계로 넘어가는 건 그렇게 쉬운 일이 아니었다. 워낙 좁은 바닥이기도 했고, SI랑은 완전히 다른 분야니까. SI 출신은 안 받는 거지. 어찌저찌 얇은 동아줄 잡고 간신히 건너왔다. 서버팀에 배치받았고, 받은 지시는 "길드워를 만드시오".그런데 손에 열린 서버 소스 코드가 문제였다. X..

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

이번 편에서 다루는 것이전 편에서 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 성능 ..

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

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

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