Hun's DEV

AI 4개한테 로또 분석 시켜봤더니 — 비개발자의 앱 개발기

AI로 만들어봤습니다··21분 읽기·
AI 코딩AI 로또 분석사이드프로젝트비개발자 앱 개발프롬프트 엔지니어링바이브 코딩Claude Code
AI PICKSIX 로또 분석 플랫폼 메인 페이지 — 4가지 AI 엔진으로 로또 번호를 분석하는 대시보드 화면

"로또 앱 만들어줘"라고 했더니 랜덤 번호 생성기가 나왔다

처음에는 진짜 이렇게 시작했습니다. "AI로 로또 번호 분석하는 앱 만들어줘." 결과요? 로그인 화면 하나에 데이터베이스는 비어있고, 분석이라고는 이름만 걸린 Math.random() 번호 생성기가 나왔습니다. AI한테 "만들어줘"라고 하면 AI도 대충 만들거든요.

그래서 프롬프트를 바꿨습니다.

Before — 초급 프롬프트: 
로또 번호 분석하는 웹앱 만들어줘
After — 중급 프롬프트: 
당신은 데이터 분석 전문가이자 풀스택 개발자입니다.

[맥락]
- 한국 로또 6/45 데이터를 분석하는 웹 플랫폼을 만들 겁니다
- 1회차~최신 회차까지 약 1,200회분의 당첨 데이터가 있습니다
- 타겟 사용자: 데이터 기반 분석을 선호하는 로또 구매자

[제약조건]
- 기술 스택: Next.js 15 + TypeScript + Supabase + TensorFlow.js
- "당첨 보장" 같은 표현 절대 금지 (법적 문제)
- 모바일 우선 반응형

[요청]
먼저 PRD(제품 요구사항 문서)를 작성해주세요. 다음 항목을 포함해야 합니다:
1. 핵심 가치 제안과 차별점
2. 페이지 구조와 사용자 플로우
3. AI 분석 알고리즘 종류와 각각의 역할
4. 데이터 모델 (Postgres 스키마)
5. API 명세
6. 단계별 구현 계획

차이는 역할 부여 + 맥락 + 제약조건 + 구조화된 요청. 이렇게 바꾸니까 AI가 페이지 구조, API 명세, Postgres 스키마까지 포함된 PRD를 만들어냈습니다.

AI 코딩 프롬프트 Before After 비교 — 단순 지시 vs 구조화된 PRD 작성 요청의 차이

PRD에서 코드까지 — AI 엔진 4개를 설계시킨 프롬프트

PRD가 나왔으니 다음은 핵심 기능 설계였습니다. "로또 분석 AI 만들어줘"가 아니라, TensorFlow.js가 브라우저에서 실행되어야 한다는 제약조건을 걸었거든요. 서버리스 환경인 Vercel에서는 무거운 AI 모델을 돌릴 수 없으니까요.

당신은 AI 알고리즘 아키텍트입니다.

[맥락]
로또 6/45 분석 플랫폼에 4가지 AI 엔진을 설계해야 합니다.
각 엔진은 서로 다른 분석 관점을 가져야 합니다.

[제약조건]
- TensorFlow.js로 브라우저에서 실행 가능해야 함 (Vercel 서버리스 환경)
- 각 엔진은 "왜 이 번호를 추천하는지" 근거를 제시해야 함
- 사용자 기기 성능에 따라 분석 깊이를 조절해야 함

[요청]
4가지 엔진 각각의:
1. 분석 관점과 핵심 알고리즘
2. 입력 데이터와 출력 형식
3. 장단점과 한계
를 설계해주세요.

AI가 설계한 구조 중 LSTM 엔진이 흥미로웠습니다. 기기 성능에 따라 4단계 티어(basic/medium/high/premium)로 나누고, basic 등급 스마트폰에서도 돌아가도록 최적화하는 방식이었거든요. 실제로 구현된 4가지 엔진은 이렇습니다:

| 엔진 | 핵심 방식 | 실제 구현 |
|------|----------|----------|
| 알파고식 랜덤워크 | Monte Carlo 5,000회 시뮬레이션 | 135개 특징 → 256 → 128 → 64 → 45 뉴런 신경망 |
| LSTM 패턴 분석 | 최근 20회차 시계열 학습 | LSTM 3층 + Dense 2층, 기기별 4단계 티어 |
| 빅데이터 가중치 | 출현빈도 30% + 트렌드 40% + 간격 20% + 계절성 10% | 45개 번호 가중치 계산 후 구간별 균등 선택 |
| 연관 규칙 마이닝 | Apriori 알고리즘 | 번호 간 공출현 빈도 분석 |

그런데 여기서 심각한 문제를 발견했습니다.

AI가 만든 "신뢰도 82%"가 사실은 Math.random()이었다

디자인 리뉴얼 작업 중이었습니다. 화면에 표시되는 수치를 정리하다가 이상한 걸 발견했거든요. "confidence: 0.82" 같은 신뢰도 점수가 매번 새로고침할 때마다 미세하게 바뀌는 겁니다. 실제 분석 결과라면 같은 데이터에서 같은 값이 나와야 하는데...

코드를 까보니 Math.random()이었습니다. 4개 엔진 전부에서요.

  • 알파고 엔진: 수렴도 점수가 Math.random() 기반
  • 빅데이터 엔진: 가중치에 15% 랜덤 노이즈 추가, 최종 선택도 랜덤 셔플
  • 연관 규칙 엔진: 신뢰도에 ±20% 랜덤 분산
  • Enhanced 엔진: 정확도가 랜덤값, 분석 실패 시 Mock 데이터 폴백
사용자한테 "이 조합의 신뢰도는 82%입니다"라고 보여주고 있었는데, 실제로는 아무 근거 없는 랜덤 숫자였던 거예요. 사이트 신뢰성에 치명적인 문제였습니다. 
당신은 코드 감사(audit) 전문가입니다.

[현재 상태]
- 4개 AI 엔진에서 confidence, stability score, accuracy 등의 메트릭이
  Math.random()으로 생성되고 있음을 발견
- 사용자에게 가짜 신뢰도를 보여주고 있어서 즉시 수정 필요

[요청]
1. 4개 엔진 파일에서 Math.random()이 사용된 모든 위치를 찾아줘
2. 각각을 실제 데이터 기반 계산으로 교체하는 코드를 작성해줘
   - 알파고: 수렴도 → 이전 결과와의 overlap 비율
   - 빅데이터: 랜덤 노이즈 제거, 구간별 균등 선택으로 교체
   - 연관규칙: ±20% 분산 제거
   - Enhanced: 랜덤 정확도 → 최근 20회차 매칭률 기반
3. 고정값(65%)으로 하드코딩된 부분도 찾아서 범위별 분포 균형도(40~75%)로 변경

이 피드백 프롬프트가 핵심이었습니다. "Math.random() 고쳐줘"가 아니라, 각 엔진별로 뭘로 대체해야 하는지를 구체적으로 지시한 거죠. AI가 만든 코드의 문제를 AI로 고치려면, 문제의 원인과 대체 방안을 함께 알려줘야 하더라고요.

결과적으로 4개 파일에서 250줄을 수정했고, 모든 메트릭이 실제 통계 기반으로 바뀌었습니다.

321개 하드코딩 색상을 발견한 날

가짜 메트릭을 고치고 나서, 디자인 전체를 점검했습니다. 그때 또 하나 발견한 게 있었거든요. 색상 코드가 31개 파일에 걸쳐서 321개나 하드코딩되어 있었습니다.

예를 들어 로또볼 1~10번은 #fdb813, 11~20번은 #69c8f2... 이런 식으로 hex 코드가 파일마다 직접 박혀 있었어요. 같은 색상인데 파일마다 미세하게 다른 값을 쓰고 있는 경우도 있었습니다.

당신은 디자인 시스템 전문가입니다.

[현재 상태]
- 31개 파일에 321개의 하드코딩된 hex 색상 코드가 흩어져 있음
- 같은 의미의 색상인데 파일마다 다른 hex 값 사용 (#fdb813 vs #fdb814)
- 다크모드 대응, 접근성 개선이 사실상 불가능한 구조

[요청]
1. CSS 변수 기반 시맨틱 토큰 시스템을 설계해주세요
   - neutral: Slate 계열
   - semantic: success, warning, error, info
   - chart: 12색 팔레트
   - lotto-ball: 각 번호대별 색상
2. 321개 hex 코드를 토큰으로 매핑하는 변환 계획을 세워주세요
3. 로또볼 색상에는 glow shadow 변수도 포함해주세요

이 작업은 4단계(Phase 0~3)로 나눠서 진행했습니다. 가장 큰 Phase 3에서 31개 파일을 수정하면서 1,480줄을 삭제하고 404줄을 추가했거든요. 삭제가 추가보다 3.6배 많다는 건, 그만큼 중복 코드가 많았다는 얘기입니다.

22초 걸리던 AI 예측이 1.2초로 — 성능 94.5% 개선

410개 커밋 중에서 가장 체감이 컸던 건 성능 개선이었습니다. AI 예측 API가 22.5초 걸리고 있었거든요. 사용자가 "분석하기" 버튼을 누르고 22초를 기다려야 한다면... 그냥 나가죠.

당신은 Next.js 성능 최적화 전문가입니다.

[현재 상태]
- AI 예측 API: 22,515ms (22.5초)
- 최신 로또 API: 885ms
- 프로덕션 빌드: 39.8초
- 초기 번들: 2.1MB

[제약조건]
- Vercel 서버리스 함수 실행 시간 제한 (10초)
- TensorFlow.js 모델은 브라우저에서 실행
- Supabase 쿼리 최적화 포함

[목표]
- AI 예측 API: 3초 이내
- 최신 로또 API: 200ms 이내

AI가 제안한 방법 중 가장 효과가 컸던 건 Supabase 쿼리 최적화와 캐싱이었습니다. 매번 1,200회차 전체를 불러오던 쿼리를 최근 100회차만 가져오도록 바꾸고, 5분 캐싱을 적용한 거죠.

| 항목 | 개선 전 | 개선 후 | 감소율 |
|------|---------|---------|--------|
| AI 예측 API | 22,515ms | 1,228ms | 94.5% |
| 최신 로또 API | 885ms | 71ms | 92.0% |
| 통계 API | 751ms | 68ms | 90.9% |
| 프로덕션 빌드 | 39.8초 | 15.9초 | 60.0% |
| AI 리포트 페이지 | 72KB | 9.6KB | 87.0% |

7개월 410커밋, 솔직한 결과

AI가 로또를 맞출 수 있냐고요? 없습니다. 로또는 완전 랜덤이거든요. 이 프로젝트의 가치는 "당첨"이 아니라, 비개발자가 TensorFlow.js 신경망, Monte Carlo 시뮬레이션, LSTM 시계열 분석 같은 걸 실제로 구현하고 운영하고 있다는 점에 있습니다.

7개월 동안 겪은 걸 정리하면:

  • AI가 대충 만든다 → 프롬프트에 역할 + 맥락 + 제약조건을 넣으면 결과가 완전히 달라짐
  • AI가 가짜 데이터를 넣는다 → 신뢰도 점수, 정확도 수치는 반드시 코드 레벨에서 검증 필요
  • 일관성은 스스로 안 생긴다 → 321개 하드코딩 색상처럼, AI가 만든 코드는 파일 간 일관성이 없음
  • 성능은 마지막에 잡는다 → 기능 먼저 만들고, 성능은 구체적 수치와 목표를 주고 최적화
현재 pick6.kr에서 운영 중이고, 매주 자동 리포트가 돌아가고 있습니다. 완벽하진 않지만... 1,187회차 데이터를 4가지 관점으로 분석하고, 그 근거를 사용자에게 보여주는 시스템이 실제로 작동하고 있거든요.
공유

댓글