바이브 코딩, 코드 읽기 없이 어디까지 가능할까(평균회귀 로또 번호 출력 서비스 - Balance Pick)

https://balancepick-frontend.vercel.app/

BALANCE PICK

1. 만들게 된 이유

로또는 독립시행이라 

이전 회차에 어떤 번호가 나왔든지 다음 회차에 어떤 번호가 나올지 예측이 불가능하다.

 

https://www.dhlottery.co.kr/lt645/stats

그런데.. 예전부터 생각한 거지만

45개의 번호가 장기적으로 어느 정도 평균으로 돌아오려는 성질을 보인다면

상대적으로 덜 나온 번호 위주로 사는 게 아주 미세하게라도 의미가 있지 않을까?

그래서 내가 쓰려고 만든 balance pick

 

전체 회차를 다 가지고 하기엔 +1회가 그리 큰 영향을 주진 않을 것 같아서
범위를 최근 111회차로 좁혀서 프로젝트를 진행했다.

 

2. 이번 프로젝트의 개발 방식

상반기 공채 시즌이기도 하고 오픽에 코테가 겹친 시점이라 
직접 구현하거나 코드를 읽지 않고 

결과만 보고 일을 시켰다. 이게 바이브코딩...?

1. 내가 원하는 기능을 나열한다.
2. GPT에게 코덱스에 전달할 프롬프트를 만들어 달라고 한다.

3. 코덱스에게 작업을 시킨다.

4. 나온 결과를 확인한 뒤 수정 사항을 말하고 어떻게 진행할지 실행 계획을 묻는다.

5. 실행 계획을 읽고 지적하거나 진행하라고 한다.

6. 1 ~ 5를 반복한다. (모든 지시는 테스트를 동반하라고 한다.)

 

3. 진행하면서 겪은 문제들

3-1. 동행복권 API 수집이 계속 실패하던 문제

처음에는 최신 로또 데이터를 동행복권 API로 가져오도록 진행이 됐다.

하지만 계속 실패했다.

실행 -> 실패 -> 안 됐는데? -> 실패 -> 또 안 됐는데? -> 실패

그러다 왜인지 물어보니 API 111회의 요청을 단순 for 문으로 진행하고 있었고
너무 짧은 간격의 반복 요청 때문에
디도스성 접근으로 의심받아 IP가 차단된 것 같다는 식의 답을 받았다.

 

그래서 요청 사이에 대기시간도 넣고 핫스팟으로 시도해 봤는데도 

결과는 실패.

안티그라비티가 맨 처음에 API 가 되는지 확인해 본다고 하면서 최신 회차 하나만 요청했을 때
DB에 들어간 것은 내 눈으로 확인했었다.

그래서 API 자체의 문제는 아닌 것 같았다.
여기에 시간을 너무 쓰는 것 같아서 
동행복권에서 제공하는 엑셀파일을 다운로드 받아 이거 DB에 넣어달라고 지시했다.

 

그렇게 해결... 지시하고 내 공부하고 지시하고 반복하고 싶었는데

계속된 실패에 시간을 너무 잡아먹었다...

 

3-2. MongoDB 데이터가 예상한 곳이 아니라 다른 쪽으로 쌓이던 문제

처음엔 Antigravity (gemini 3.1 pro high) 를 이용해서 개발을 진행했는데

혼자서 디비 구조를 백엔드와 테스트 환경을 분리해서 만들었다.

무료 토큰을 다 쓰고 회복되는데 며칠이 걸린다기에 
코덱스를 이용하기 시작했는데 며칠 운영하다가

이용자 분석을 위해 MongoDB Atlas에 들어가 확인해 보니

데이터가 테스트 쪽으로 쌓이고 있는 것을 확인했다.

이런~

정확한 원인을 100프로 확신할 수는 없지만 

작업 중간에 모델을 바꾸면서 맥락이 어긋난 영향이 컸던 것 같다.

이후에는 모델이나 세션을 바꾸기 전에 지금까지 작업한 내용을 md 파일로 정리해서 남기라 하고 
넘어가는 방식으로 바꿨다.

 

이렇게 하니 세션이 바뀌어도 맥락이 맞지 않는 부분이 많이 줄었다.

 

3-3. 컬럼 추가는 해도 기존 데이터까지는 자동으로 맞춰주지 않던 문제

처음 설계된 엔티티가 있으면

이후 컬럼을 추가해야 한다고 판단하고 지시하면

이전 데이터들이 자동으로 맞춰주지는 않았다.

 

예를 들어 나는 로또 생성 방식을 평균회귀 방식 말고 다른 방식을 추가하고 싶었고
통계도 방식별로 분리해야 한다고 생각했기에 type이라는 컬럼을 추가해 달라고 요청했다.

그런데 새 구조는 반영됐지만

이미 들어가 있던 기존 데이터에는 그 값이 채워지지 않았다.

 

DB를 확인하고 나서야 알게 되었고

이전에 들어간 데이터도 업데이트해줘
라고 다시 말해야 해결됐다.

이 경험으로 알게 된 건

스키마 변경으로 인한 코드 변경은 아주 쉽게 해 주는데
기존 데이터의 마이그레이션까지 당연히 챙겨주지는 않았다.

 

3-4. 테스트해달라 했고 통과까지 했는데 운영에서는 계속 실패하던 문제

최근 111회차를 유지하기 위해 
최신 번호가 나오면 가장 오래된 회차 삭제, 가장 최신 회차 삽입 및 가중치 계산, 당첨 번호 매칭, 명예의 전당 통계까지

배치 작업을 진행하게 했는데

배포한 이후 3주 동안 한 번도 성공한 적이 없다.

분명 테스트를 시켰고 성공까지 했다고 했다. - 테스트 코드가 생성된 것은 봤지만 읽어보지는 않았음

왜 자꾸 실패하는지 대화 끝에 문제점을 발견했다. 

 

추점 시점과 API 반영 시점 사시의 차이를 고려하지 않고, 결과가 올라오기 전에 너무 이른 시점에 요청하고 있었던 것.

그래서 여유있게 토요일 9시로 시각을 변경했다.

그 이후 또 실패

 

그렇게 또 발견한 문제
Render 백엔드 서버 시간과 한국 시간 사이의 차이가 있었고
한국 시간 기준으로 다시 바꿨다.
그리고 Render 무료 버전이라 몇 분 동안 동작이 없으면 잠에 든다고 해서

요청 전에 미리 들어가서 서버를 깨우기도 했지만

 

실패.

 

이제는 실패 시 주기적으로 재시도하도록 바꿨고
관리자 권한으로 접근 가능한 입력 기능을 만들어서 최신 회차를 직접 반영할 수 있게 했다.
최신 회차가 나오면 직접 입력해서 운영 환경에서도 확인해 볼 생각이다.

 

테스트 완료라는 말만으로 절대 안심하면 안 된다는 걸 확실히 배웠다.

4. 느낀 점

일단 계획 설정 - 개발 - 테스트 - 결과 도출 과정의 속도는 굉장히 빨랐다.

내가 원하는 것을 말하면 실행 계획을 통해 디테일한 부분까지 잡아줘서
방향 설정에도 도움이 많이 되었다.

 

하지만 딱 거기까지
내가 말한 것 이상으로 해주지 않고
일관성, 데이터 보정, 운영 중 생길 수 있는 예외, 외부 API, 시간대 등 

직접 확인해야지 판단할 수 있는 문제가 많다는 것을 느꼈다.

 

또한 배치 자동화 이슈를 겪으면서 
테스트까지 완료했다고 말하는 것이
이게 실제 운영 환경에서 제대로 돌아가는 것과 완전히 다른 문제라는 것을 크게 느꼈다.

 

비전공자가 바이브코딩으로 매출 몇천이라는 문구를 자주 봤었는데

특정 지식을 알아야 보이는 것도 분명히 있는데...

어떻게 했지...?

내 방식의 문제가 있을 수도 있다.
바이브 코딩에도 과정을 자동화하고 
더 명확한 결과, 안전한 결과를 내기 위한 프롬프트 방식도 있는 것 같으니
공부가 필요할 것 같다.

 

5. 마무리

27명의 회원이 있고 (가족, 친구)
이 서비스에서 출력한 번호로 로또를 산 사람 중에 5등이 당첨된 사람들도 있고

반대로 200줄을 뽑고도 겨우 5등 몇 개 된 사람도 있다.

콰트라는 운동 앱에 실제 로또 결과 기반으로

응모할 수 있고 실제 상금도 주는 게 있다고 한다.

내 서비스를 믿고 응모권을 썼는데...

 

 

나의 꿈이... 
윽... 이론 확률에 가까워진다.. 큰 수의 법칙...
아니 오히려 낮음...
이제 남은 건 로또 명인 방식... 저번주에 추가했으니
이번 주는 저걸로 밀고 간다.