728x90

분류 전체보기 110

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

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

EP.04 — 16슬롯 버퍼 풀: 도서관을 16개로 늘린 이유

이 글은 『서버 개발 수기』 시리즈의 네 번째 글이다. 지난 회에서는 3단계 스핀락을 다뤘다. 오늘은 그 스핀락이 지키는 버퍼 풀 이야기다. ※ 이 시리즈에서 다루는 서버 코드는 Project-AO(Ancient Origin)라는 가명으로 부른다. 도서관 이야기지난 회에서 화장실 비유를 했으니까, 오늘은 도서관으로 바꾸어본다.패킷이 들어올 때마다 데이터를 담을 버퍼가 필요하다. 그런데 패킷이 올 때마다 메모리를 새로 할당하면 느리다. 그래서 버퍼를 미리 수천 개 만들어놓고, 빌려주고 반납받는 시스템을 만든다. 이게 버퍼 풀이다.도서관이라고 생각하면 된다. 책이 필요할 때마다 인쇄하는 게 아니라, 도서관에 꽂아두고 빌려가고 반납하는 거다.간단해 보이는데, 문제가 하나 있다.도서관이 1개면스레드 ..

[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

EP.03 — 3단계 적응형 스핀락: 왜 spin하다 yield하다 sleep하는가

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

파인튜닝 인생과 참을 수 있을지 없을지 모르는 존재의 가벼움

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

프로그래밍/AI 2026.03.02

EP.02 — 전체 아키텍처: 3계층 구조와 설계 철학

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

EP.01 — 프롤로그: 20년 만에 열어본 코드

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

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 쿼리 작성법을 학습합니다. 정규화, 인덱스, 트랜잭션 처리를..

반응형