제 9 장
개발 일정 및 결론
1) 단계별 개발 일정
저장소 첫 커밋은 2026-07-06이고 이 보고서가 기준으로 삼은 마지막 날은 2026-09-30이다. 그 사이 커밋 369개이며 달별로 138 · 157 · 74건이다.
| 구간 | 기간 | 내용 |
|---|---|---|
| 기반 | 07-06 ~ 08-19 | 저장소 · 인증 · PLE 예측 · 랭킹 · 기록 · 상점 |
| Phase 0·1 | 08-20 | 디자인 토큰과 새 정보 구조 |
| Phase 2 | 08-21 | 데이터 센터 (제 6 장) |
| Phase 3-0~3-3 | 08-21 | AI 평가 무결성 · 예측 · 에이전트 리포트 · 에이전트 분석 |
| 3-4 ~ 3-6 | 08-24 | RAG 코퍼스 · 합성 산식 · 자격 판정 |
| 3-7 ~ 3-10 | 08-26 ~ 08-27 | 표본 계보 · 채점 모집단 분리 |
| 3-12 | 08-28 | 개정본 계보 평가 관문 |
| 3-13 | 09-07 ~ 09-21 | 계보 신뢰성 관문 · 읽은 청크를 개정본째로 기록 |
| 카탈로그 · 인프라 | 09-22 | 17개 대회 목록 확정 · DB를 Supabase로 이전 |
| 계보 화면 | 09-23 | 질의·읽은 글 기록 · 감사 화면 · 준비도 |
| 자동화 | 09-28 ~ 09-30 | 결과 확정 에이전트 · 챔피언 보드 자동 갱신 · 빠진 예측 자동 생성 |
| 정리 · 게이트 | 09-29 | 라이트 테마 · 쓰이지 않던 앱·의존 제거 · GitHub Actions |
7월이 기능, 8월이 구조, 9월이 신뢰성이다. 커밋 수는 줄어드는데 9월의 변경이 가장 조심스럽다 — 이미 저장된 예측과 사용자 픽이 걸려 있어서, 고치면 과거 기록의 뜻이 바뀌기 때문이다. 그래서 9월 작업의 상당수가 “무엇을 하지 않을지”를 정하는 일이었다(합성 산식 판본 보존 · 소급 재판정 금지 · 위키에 없는 벨트를 지우지 않기).
Phase 번호가 시간순이 아닌 자리가 있다. 3-11은 비어 있고 3-12가 먼저 들어갔으며, 3-13은 3주에 걸쳐 여러 단계로 나뉘었다. 번호를 뒤늦게 맞추지 않은 이유는 커밋 메시지가 이미 그 번호로 남았기 때문이다.
2) 개발 결과 요약
만든 것
| 층 | 결과 |
|---|---|
| 화면 | 19개 — 예측·랭킹 6 · 데이터 센터 6 · AI LAB 7 |
| 백엔드 | 앱 7개 · 파일 512 · 모듈 의존 699 · kayfabe 소유 테이블 13 |
| 아키텍처 계약 | 4 (전부 KEPT) |
| 시험 | 1,182건 (16초) |
| 디자인 토큰 | CSS 변수 255개 · 토큰 유틸리티 사용 825곳 |
들고 있는 데이터 (2026-09-30)
| 항목 | 값 |
|---|---|
| 선수 | 178명 (NXT 58 · RAW 52 · SmackDown 51 · Evolve 13 · Free Agent 4) |
| 경기 | 99건 (끝난 63 · 타이틀전 52) |
| 대회 | 19개 (끝난 12) |
| 벨트 · 획득 기록 | 20개 · 367건 (챔피언 66명) |
| RAG 코퍼스 | 문서 74건 · 청크 915건 |
| AI 예측 | 22건 (채점 12 · 적중 12) |
이 프로젝트가 실제로 답한 질문
목표는 적중률이 아니라 “이 예측을 성적에 셀 자격이 있는가” 에 증거로 답하는 것이었다(제 1 장 2절). 그 답은 냈다 — 그리고 답이 “아직 아니다” 였다.
| 물음 | 답 |
|---|---|
| 적중률은? | 12/12 = 100% |
| 그 숫자를 성능으로 읽어도 되나? | 아니다. 12건 전원이 실격 규칙에 걸린다 |
| 왜 실격인가를 말할 수 있나? | 예측 한 건 단위로 규칙 이름과 근거 문서까지 |
| 실격을 피할 방법을 아는가? | 안다 — 판정이 아니라 수집에서 막는다 |
적중률 100%를 성능이라고 적지 않은 것이 이 프로젝트의 결과물이다. 그 숫자를 그대로 내보내는 것이 더 쉽고 보기에도 좋았지만, 그러면 제 1 장에서 문제로 지목한 것과 같은 주장이 된다.
3) 한계 및 향후 과제
자격 통과 표본이 0건이다
가장 큰 한계다. 지금 22건은 전부 결과가 확정된 뒤에 만들어졌거나 그 대회를 다룬 글을 근거로 들었다. 판정 장치는 서 있는데 그 장치를 통과한 예측이 없다.
통과 표본을 만드는 절차는 이미 알고 있다 — 대회가 열리기 전에 예측을 만들고, 코퍼스에서 그 대회 문서를 먼저 걷어내는 것이다. 준비도 화면이 그 확인을 위해 있고, 다음 기회는 아직 열리지 않은 대회다.
위키만으로는 구조적으로 막히는 자리가 있다
서사 에이전트는 대립 각본을 읽어야 의견을 내는데, 그것이 가장 잘 적혀 있는 문서가 대회 문서다. 그 문서를 읽으면 그 순간 누수이므로, 같은 출처로는 “각본을 읽었고 결과는 안 읽었다”를 만들 수 없다. 배당과 출전 소식을 위키 밖의 출처에서 가져오는 것이 이 막힘을 푸는 경로이고, 통과 표본을 먼저 만든 뒤에 붙이는 순서로 남겼다 — 수집 경로를 늘리면 누수 경로도 함께 늘어난다.
발행일을 채우지 않았고, 판본별 코퍼스를 짓지 않았다
위키가 메타태그로 발행일을 내보내지 않아 코퍼스의 발행일 칸은 비어 있다. 개정본 계보(그 글의 어느 판을 읽었는지)로 우회했고, 발행일을 백필하는 작업은 하지 않기로 했다 — 백필은 판정 게이트를 열어 줄 뿐 엄밀성을 더하지 않는다.
같은 이유로 판본별 코퍼스(Versioned Corpus)를 짓지 않기로 결정했다. 그 대가는 명확하다: 코퍼스가 판본을 하나만 가지므로 “그때 그 코퍼스”를 되살릴 수 없고, 그때 읽은 원문은 예측에 딸린 계보 테이블에만 남는다.
재현은 다섯 단계 중 둘만 돌아간다
| 단계 | 재현 |
|---|---|
| 질의 조립 | 된다 |
| 검색 | 안 된다 — 코퍼스가 그때 상태가 아니다 |
| 에이전트 호출 | 안 된다 — 모델이 결정적이지 않다 |
| 합성 | 된다 — 저장된 산식 판본으로 |
| 판정 | 규칙을 다시 돌릴 수는 있으나 입력이 계보 스냅샷에 묶인다 |
“재현됨”이라는 표시가 뜻하는 범위를 화면에 적어 두는 것이 지금의 해법이다. 표시를 지우는 대신 범위를 좁혀서 쓴다.
누수의 원인을 한 문서에 돌릴 수 없다
귀속 화면은 실격에 관여한 문서를 보여 준다. 그 이상은 못 간다 — 한 예측을 막은 문서가 여럿이면 어느 하나를 빼도 실격이 유지되므로, 원인이 여럿이면 아무도 원인이 아니게 된다. 반사실(“이 문서가 없었다면 통과했을까”)로 답하려면 문서 부분집합마다 판정을 다시 돌려야 하고, 그것은 지금 구조에서 의미 있는 비용이 아니다. 화면이 “원인”이라고 적지 않고 “관여”라고 적는 이유다.
남은 자잘한 것들
- 표본이 작다 — 예측 22건이 대회 하나에 몰려 있어 합의 층위별 비교가 불가능하다(제 7 장 5절).
- 최장 재위 기간을 못 낸다 — 획득일이 자유 텍스트이고 끝난 날짜가 없다(제 6 장 2절).
- 하드코딩 hex 84건 중 실제 정리 대상은
/admin23건이다. 나머지는 로고·타사 브랜드 색으로 토큰이어서는 안 되는 값이다(제 4 장 4절). - 차트 계열색 하나(
--chart-3)가 라이트 표면 대비 2.94 로 3:1 아래다. 재조정을 별도 작업으로 남겼다. - 로컬(k3s)과 운영(EC2 · docker compose)의 실행 방식이 다르다. 매니페스트와 compose 파일을 둘 다 유지하는 비용을 지고 있다.
- 무료 LLM 등급의 모델당 하루 요청 상한이 자동 예측의 속도를 정한다. 모델을 에이전트별로 분산해 하루 안에 끝나게 맞췄다.
4) 참고 자료
산출물
| 항목 | 주소 |
|---|---|
| 서비스 | www.jsangho.cloud |
| 저장소 | github.com/jsangho/cloud.jsangho.all |
데이터 출처
RAG 코퍼스의 URL 74개는 두 도메인에서 왔다 — en.wikipedia.org 62건(대회·선수·각본 문서) · wwe.com 12건(선수 프로필). 챔피언 보드와 PLE 대진의 정본도 위키이며, 사람이 diff를 확인한 뒤 커밋한다(제 5 장 1절).
아키텍처 근거
- 클린 아키텍처 · 헥사고날(포트와 어댑터) · DDD — 레이어 순서와 바운디드 컨텍스트 분리의 기준
- Andrej Karpathy, LLM 코딩 관찰 — 하네스로 규칙을 강제한다는 방향의 출발점
도구
| 분류 | 사용 |
|---|---|
| 게이트 | import-linter · ruff · pre-commit · GitHub Actions · pytest / pytest-asyncio |
| LLM · 검색 | Google Gemini (flash 계열) · BAAI/bge-m3 임베딩 · pgvector · Kiwi 형태소 |
| 프론트 | Next.js 16 · React 19 · Tailwind CSS · Radix UI · Recharts |
| 백엔드 | FastAPI · SQLAlchemy 2.0 async · Alembic · PostgreSQL(Supabase) · Redis |
| 디자인 | 자체 DESIGN.md · 차트 팔레트 검증기 · WCAG 대비 기준 |