수집 대상이 수백 건이 되면 사람이 규칙을 고르는 순간 편향이 들어갑니다. 후보를 코드가 전부 검증하고 기준 미달을 버린 뒤, 60초 주기로 전 대상을 다시 매칭해 대시보드로 밀어 주는 파이프라인입니다. 금융 데이터로 만들었지만 구조는 수집 → 통계 검증 → 실시간 모니터링이 필요한 어느 도메인에나 같습니다. 기획·데이터·백엔드·프런트를 단독 수행했습니다.

검증 기준을 코드에 박았습니다. 적중률 55% 미만이거나 표본 30회 미만이면 저장 단계에서 버립니다. 대상 503종목, 5분봉 380만 바, 규칙 엔진 다섯 개, 스캔 주기 60초입니다.

실무에서 걸리는 건 셋입니다. 표본이 작으면 어떤 가설이든 들어맞고, 조합을 사람이 다 돌릴 수 없고(갭 7단계 × 시간 3개 × 조건 4종만 해도 84가지), 찾아 놓은 규칙이 지금 어디에 걸렸는지 눈으로 볼 수 없습니다.

엔진은 다섯이고 보는 데이터가 각각 다릅니다. 일봉 90일, 5분봉 60일, 주봉 2년, 매크로 지표, 캘린더 이벤트. 어느 엔진에서 나왔든 후보는 전부 같은 관문을 지납니다.

검증 결과 테이블입니다. 적중률 막대와 점수 막대를 같은 줄에 놓아 적중률은 높은데 표본이 얇은 항목이 눈에 띄게 했습니다. 방향 필터와 정렬(점수·적중률·표본·Wilson 하한)을 붙였습니다.

수집 루프입니다. 503건을 한 번에 요청하면 받는 쪽에서 끊기기 때문에 50건씩 끊어서 받고 한 바퀴를 주기 안에 끝냅니다. 임계값을 넘으면 신호로 보고, 들어가는 조건보다 나가는 조건(손절·최대 보유·건당 금액)을 먼저 고정했습니다.

운영 파라미터는 화면에서 바꿉니다. 런타임에 고치면 설정 파일에 즉시 쓰여 재시작해도 유지됩니다. 메모리에만 남기면 재기동 때 조용히 되돌아가기 때문입니다.

주기가 다른 셋을 한 프로세스에 묶지 않았습니다. 규칙 발견은 배치, 스캐너는 60초 루프, 화면은 SSE 로 5초마다 push 하고 서로는 DB 로 만납니다. 프로세스는 pm2 가 들고 죽으면 다시 올립니다.

사용 기술과 한계입니다. Python, pandas, numpy, SQLite(WAL), FastAPI, uvicorn, asyncio, SSE, pm2. 과거 데이터의 적중률과 실제 운영 결과는 같지 않고 그 간격은 아직 좁히는 중입니다. 화면의 금액과 손익은 전부 가렸으며, 적중률은 과거 데이터 검증값이지 수익률이 아닙니다.