TFT_sLLM_PRD_v1.3_최종.docx

문서 정보

항목	내용
버전	v1.3
문서 상태	확정(Final) — 1.0 확정 결정 로그는 13장 참고
작성일	2026-07-30
작성자	suraholic@gmail.com
대상 게임	리그 오브 레전드: 전략적 팀 전투 (TFT)
근거 자료	TFT_sLLM_브레인스토밍.md (v2), PRD 초안 v0.4
데이터 소스 확정	메타 데이터 = op.gg MCP / 개인 매치 조회 = Riot API Personal Key
서비스 범위	MVP — 개인/비상업 목적 한정, 본인 + 지인 약 10명 규모. 상업 서비스 전환 시 별도 PRD 갱신 필요(14장 백로그 참고)

문서 변경 이력

버전	일자	변경 내용
v0.1	2026-07-29	브레인스토밍 자료 기반 최초 초안 작성
v0.2	2026-07-29	3-2 성공 지표에 MVP 목표 수치 반영, 3-3 KPI 측정·모니터링 계획 신설, 9-1 자동 패치 감지 트리거 추가, 8-3/4-1b 계정 연동 방식을 로컬스토리지 기반·임의 계정 조회 허용으로 구체화
v0.3	2026-07-29	데이터 소스를 op.gg MCP(메타) + Riot API Personal/Production Key(개인 매치)로 확정. op.gg MCP 상업 이용 리스크 재평가, TFT 개인 전적 조회 도구 부재 반영, Riot API 키 발급 로드맵 및 TFT 유스케이스 정책 신설, 계정 연동 설계를 2단계로 구체화
v0.4	2026-07-29	서비스 범위를 MVP(개인/비상업 목적)로 명확화. 상업 전환 시에만 필요한 항목을 13장에서 제거하고 14장 '상업 서비스 전환 시 확인사항(백로그)' 신설해 이관
v1.0	2026-07-30	PRD 확정. 13장 확인사항을 (1) 이번 결정으로 해소된 항목, (2) 구현 착수 스파이크로 이관할 항목, (3) 원래부터 출시 후 재보정 대상이던 항목으로 재분류. 구체적으로: 5-1/5-2/7-2 챗봇 배포 채널을 웹사이트 내장 위젯 단일 채널로 확정(디스코드봇 등 추가 채널은 out of scope로 이관), 7-1/9-3 웹사이트 4개 페이지(티어리스트/조합 상세/아이템 빌드/증강체) 전체를 1.0 범위로 확정, 3-2/7-3/12 초기 이용자 규모를 본인+지인 약 10명으로 확정, 3-3/9-5 KPI 계측 도구 스택을 Postgres 구조화 로그 + Metabase + RAGAS로 확정(GA4/PostHog/Grafana 미채택), 10-2/11-2 sLLM 후보에서 EXAONE 제거(Groq 무료 티어 미지원 확인, Llama 3.1/3.3·Qwen3-32B·Gemma2-9B·DeepSeek R1 Distill로 후보 정리), 13장을 '1.0 확정 결정 로그 및 남은 작업'으로 재작성
v1.1	2026-07-30	9-1/9-2에서 이름 매핑 용도로 쓰던 Data Dragon(ddragon)이 곧 바뀔 수 있다는 점을 반영. TFT가 Set 18(2026-08-12, 패치 18.1)부터 언리얼 엔진으로 이전하면서 Riot이 TFT 데이터를 기존 League Data Dragon에서 분리해 별도의 TFT DDragon으로 이관한다고 발표(2026-06-12). 9-1 2차 신호 설명에 이 마이그레이션 리스크를 명시하고, 12장 리스크에 신규 항목 추가
v1.2	2026-07-30	7-3에 '사후 패인 분석'의 실제 구조를 명시 — 조합 이탈도·아이템 집중도·증강체 시너지는 규칙 기반 계산이고 sLLM은 그 결과를 코칭 문장으로 언어화하는 역할이며, 게임 판단 자체를 LLM이 내리는 것이 아님을 명확화. 실시간(게임 중) 코칭은 Riot Live Client Data API가 로컬 클라이언트 전용이라는 접근 한계와 10-1의 '실시간 정보·상대 스카우팅 앱 승인 불가' 정책 양쪽에 막혀 있음을 7-3/12장에 반영. 12장에 AI 코칭 판단 신뢰성 리스크(임계값이 검증되지 않은 초기 가설치) 항목 추가. 15장 'AI 코칭 고도화 로드맵' 신설 — 향후 LLM이 직접 분석 판단을 맡게 하려면 필요한 데이터 한계, 라벨 데이터셋·평가체계 부재, 통계 표본 부족 문제와 단계적 접근 방향을 참고용 백로그로 정리(이번 범위 아님)
v1.3	2026-07-30	반응형 웹 디자인을 1.0 범위로 신규 확정 — 5-1에 반응형 웹 디자인 항목 추가, 7-4 '반응형 디자인(모바일/태블릿 대응)' 신설(브레이크포인트 3단계, GNB·챗봇위젯·카탈로그 레이아웃 전환 규칙), 9-3에 브레이크포인트 반영 문구 추가, 12장에 반응형 QA 리소스 제약 리스크 추가, 13-1 결정 로그에 반응형 지원 여부 항목 추가. 화면 단위 상세 설계는 IA v1.1·화면설계서 v1.1에 반영

1. 개요

TFT(전략적 팀 전투) 플레이어에게 최신 메타 정보를 제공하는 서비스. sLLM(소형 언어 모델) + RAG(검색 증강 생성) 기반 챗봇과, 정형 데이터를 표/카드로 보여주는 웹사이트를 동일한 데이터 계층 위에서 함께 제공한다. 여기에 사용자의 실제 매치 데이터를 메타 데이터와 비교해 코칭 피드백을 주는 사후 패인 분석 기능을 더해, 정보 열람부터 대화형 질의, 개인화된 복기까지 하나의 서비스 안에서 해결하는 것이 목표다.

웹사이트와 챗봇은 같은 데이터를 두 가지 방식으로 노출한다 — 웹사이트는 '찾아서 클릭'(탐색형), 챗봇은 '물어보면 바로 답'(질의응답형). 데이터를 이중으로 만들지 않고, 하나의 정규화된 데이터 계층을 웹사이트는 표로, 챗봇은 검색 후 자연어로 풀어서 보여준다.

2. 배경 및 문제 정의

• TFT는 패치(약 2주 단위)마다 메타가 크게 바뀌는 게임으로, 플레이어는 최신 티어리스트·조합·아이템 빌드를 빠르게 파악해야 한다.
• 기존 메타 정보 사이트(op.gg, MetaTFT 등)는 표 형태의 정보 열람에는 강하지만, '지금 상황에 맞는 조합이 뭔지' 같은 복합 조건 질의나 여러 페이지에 흩어진 정보를 종합해주는 대화형 인터페이스는 제공하지 않는다.
• 자신의 게임을 복기하며 '왜 졌는지'를 메타 기준으로 짚어주는 개인화된 코칭 기능은 시중에 뚜렷한 서비스가 없다.
• 이 세 가지 공백(대화형 질의, 정보 종합, 개인화 복기)을 sLLM + RAG 기반으로 메운다.

3. 목표 및 성공 지표

3-1. 제품 목표

• 최신 패치 기준 메타 정보(티어리스트/조합/아이템/증강체)를 정확하고 빠르게 제공한다.
• 자연어 질의로 복합 조건 검색과 여러 페이지 정보 종합을 챗봇 한 번의 대화로 해결한다.
• 사용자의 실제 매치를 메타와 비교해 구체적인 코칭 피드백을 제공한다.
• 무료/저비용 인프라로 개인/비상업 목적의 MVP를 검증한다. 상업 서비스 전환은 이번 PRD 범위가 아니며 14장 백로그로 남긴다.

3-2. 성공 지표 및 MVP 목표

초기 이용자 규모는 본인 + 지인 약 10명으로 확정한다(Personal Key 레이트리밋·무료 인프라 한도 내에서 충분히 여유 있는 규모, 12장 리스크 참고). 아직 실사용 데이터가 없어 자체 과거 수치를 근거로 쓸 수 없다. 대신 성격이 유사한 업계 벤치마크에 이 서비스의 마찰 요인(계정 연동 필요, 익명 트래픽, 무료 인프라 콜드스타트)을 반영해 보수적으로 잡은 초기 가설치이며, 출시 후 2~4주 실측 데이터로 재보정하는 것을 전제로 한다(이 재보정은 1.0 확정을 막는 미해결 항목이 아니라, 1.0에 이미 포함된 출시 후 계획이다 — 13장 참고).

지표	MVP 목표	설명
데이터 최신성	패치 감지 → 갱신 완료 평균 1시간 이내	9-1 자동 패치 감지 트리거의 실행~완료 시간으로 측정
챗봇 답변 근거율	85% 이상 (RAGAS 등 faithfulness 스코어 기준)	RAG 평가 프레임워크의 프로덕션 기준선(85~90%)을 준용
챗봇→웹사이트 전환율	링크 포함 답변 기준 15~20%	하이인텐트 챗봇의 '방문자→행동' 전환율(10~20%) 하단에서 시작
사후 분석 이용률	계정 연동 완료자 중 30일 30%, 90일 45~50%	SaaS 신규 기능 채택 곡선(30일 20~30%, 90일 40~60%)의 중간값으로 보수화
응답 지연	웜 상태 p50 3초 이하, 콜드스타트 포함 p95 60초 이하	Groq 추론 자체는 빠르나 Render 무료 티어 콜드스타트(30~60초)가 병목

3-3. KPI 측정 및 모니터링 계획

목표 수치를 세우는 것과 별개로, 실제 달성률을 확인하려면 아래 계측(로깅/이벤트)과 집계 파이프라인을 개발 범위에 포함해 구축해야 한다(5-1 개발 범위 참고). KPI 도구 스택은 이용자 규모(본인+지인 약 10명)를 감안해 별도 SaaS(GA4/PostHog) 없이 Postgres 구조화 로그 + Metabase + RAGAS 조합으로 확정한다.

지표	필요 계측 (로깅/이벤트)	집계·확인 방법
데이터 최신성	9-1 자동 패치 감지 트리거의 시작/완료 타임스탬프 로깅	트리거 실행 로그에서 감지~적재 완료 소요 시간 자동 계산, 주간 Metabase 대시보드에 표시
챗봇 답변 근거율	질의, 검색된 문서 ID/patch_version, 생성 답변을 구조화 로그로 저장	주간 샘플(N건)에 RAGAS faithfulness 스코어러를 배치로 실행해 비율 산출
챗봇→웹사이트 전환율	답변에 포함된 링크에 answer_id를 태깅해 클릭 이벤트를 Postgres 구조화 로그 테이블에 직접 적재(별도 SaaS 불필요, 이용자 규모상 자체 로깅으로 충분)	노출 대비 클릭 수를 Metabase에서 일/주 단위로 집계
사후 분석 이용률	계정 연동 완료 이벤트, 분석 요청 이벤트를 사용자 단위로 로깅	연동 완료 시점 기준 코호트를 만들어 30일/90일 시점 분석 요청 비율 산출
응답 지연	API 게이트웨이 레벨에서 요청~응답 시간 로깅, 콜드스타트 여부 플래그 태깅	p50/p95를 콜드스타트 포함·제외로 분리 집계

모니터링 운영 방식

• 주간 KPI 대시보드(Metabase, Postgres 직접 연결)에서 5개 지표를 목표 대비 달성률(%)로 상시 확인
• 2주 연속 목표 미달 시 알림 발송 + 원인 분석 태스크 생성(이용자 규모상 초기에는 수동 확인도 가능)
• 근거율·전환율·이용률은 최소 4주치 데이터가 쌓인 뒤 목표 수치 자체를 재검토(초기 가설치이므로) — 이는 1.0 확정 이후 정상적으로 진행되는 후속 작업이며 1.0 확정의 선행조건이 아니다
• 응답 지연은 콜드스타트 비중이 일정 수준(예: 전체 요청의 10%) 넘으면 백엔드 유료 플랜 전환을 트리거하는 기준으로 사용

4. 대상 사용자

• 메타를 빠르게 훑어보고 싶은 일반 플레이어 — 웹사이트 티어리스트/조합 페이지 위주 이용
• 특정 상황에 맞는 조합·아이템을 찾는 플레이어 — 챗봇의 복합 조건 질의 이용
• 게임 용어·시스템에 익숙하지 않은 초보 유저 — 어떤 메뉴를 써야 할지 몰라도 챗봇에 자연어로 질문
• 본인 전적을 복기하고 실력을 늘리고 싶은 플레이어 — 사후 패인 분석 이용

5. 제품 범위

5-1. 이번 개발 범위 (In Scope)

• 웹사이트: 티어리스트 / 조합 상세 / 아이템 빌드 / 증강체 정보 페이지 (4개 페이지 전체, 1.0 확정)
• 챗봇: RAG + sLLM 기반 대화형 질의응답. 배포 채널은 웹사이트 내장 위젯 단일 채널로 확정(1.0). 디스코드봇 등 추가 채널은 5-2 Out of Scope 참고
• 사후 패인 분석: Riot ID 연동 → 최근 매치를 메타 데이터와 비교한 코칭 답변
• 데이터 배치 수집·정규화 파이프라인 및 공통 데이터 계층(구조화 DB + 벡터 DB)
• KPI 계측/모니터링 파이프라인: 챗봇 Q&A·근거문서 로깅, 링크 클릭 이벤트, 계정연동·분석요청 이벤트, 응답 지연 로깅을 Postgres 구조화 로그로 적재하고 Metabase 주간 대시보드로 확인(3-3 참고)
• 반응형 웹 디자인: 모바일(<768px)/태블릿(768~1023px)/데스크톱(1024px~) 3단계 브레이크포인트로 웹사이트 전체를 대응한다 (1.0 확정, 7-4 참고)

5-2. 이번 범위 제외 (Out of Scope — 별도 트랙)

아이디어	제외 사유
게임 중 보드 스크린샷 분석 코칭	일반 VLM은 작은 아이콘(챔피언 별/스택 아이템) 오인식 위험이 커 CV 기반 하이브리드 방식이 필요. 사후 패인 분석으로 상당 부분 대체 가능해 우선순위를 낮춤
게임 중 실시간 인게임 오버레이 코칭	웹은 OS 차원에서 오버레이 불가, 모바일은 실시간 보드 데이터를 읽을 공식 API 없음. Windows에서 Overwolf SDK 활용만 현실적이며 별도 네이티브 앱 개발이 필요한 독립 제품 라인. 게임 메모리 직접 읽기는 치팅 도구 오인 리스크로 배제
챗봇 추가 배포 채널 (디스코드봇 등)	1.0은 웹사이트 내장 위젯 단일 채널로 우선 검증한다(같은 챗봇 API를 재사용하는 구조라 이후 추가 자체는 어렵지 않음). 봇 호스팅·토큰 관리·디스코드 API 레이트리밋 대응이라는 추가 공수가 붙으므로, 위젯 채널의 이용자 반응을 먼저 확인한 뒤 별도 트랙으로 재검토한다

6. 웹사이트 vs 챗봇 역할 구분

근본적으로 같은 데이터를 두 UX로 노출하는 구조다. 챗봇이 웹사이트를 대체하는 것이 아니라, 브라우징은 웹사이트, 구체적 질문과 정보 종합은 챗봇이 맡는 상호보완 관계로 설계한다.

상황	더 적합한 채널	이유
전체 티어리스트/조합 목록 훑어보기	웹사이트	표·그래프로 시각적 탐색이 유리
복합 조건 질의 (예: 초반 강하면서 재사공 아닌 조합)	챗봇	필터 여러 번 조작 대신 자연어 한 번으로 처리
여러 페이지(조합+아이템+증강체)에 흩어진 정보 종합	챗봇	페이지 이동 없이 하나의 답으로 결합
용어를 잘 모르는 초보 유저의 진입	챗봇	어떤 메뉴/필터를 써야 할지 몰라도 자연어로 질문 가능
특정 조합 상세 스탯/빌드 확인	웹사이트	정형 데이터를 정확한 표로 확인
맥락을 이어가는 후속 질문 (drill-down)	챗봇	'그 조합에 어울리는 증강체는?' 같은 대화 이어가기

7. 핵심 기능

7-1. 웹사이트 (정보 제공)

정형 데이터를 사람이 훑어보기 좋은 표/카드로 렌더링하는 대시보드. LLM 없이 구조화 DB를 직접 조회한다. 4개 페이지 전체를 1.0 범위로 확정한다.

• 티어리스트, 조합 상세, 아이템 빌드, 증강체 정보 페이지
• 패치별 · 랭크별 · 챔피언별 검색/필터
• 특정 조합 클릭 시 상세 페이지(빌드, 증강체 추천 등)로 이동
• 페이지 내 챗봇 위젯 삽입 (탐색 중 바로 질문 가능)

7-2. 챗봇 (RAG + sLLM)

자연어 질문을 의도 분류 후 RAG로 검색하고, sLLM이 검색 결과를 근거로 답변을 생성한다. 답변에는 근거 데이터와 패치 버전을 명시하고, 관련 웹사이트 상세 페이지 링크를 함께 제공해 챗봇→웹사이트 트래픽을 유도한다. 배포 형태는 웹사이트 내장 위젯 단일 채널로 1.0 확정(디스코드봇 등 추가 채널은 5-2 참고).

• 의도 분류: 조합 추천 / 아이템 추천 / 증강체 추천 / 일반 전략 질문
• 의도별 검색 쿼리 생성 → 구조화 DB/벡터DB 조회
• 검색 결과 + 질의를 sLLM 프롬프트에 결합해 답변 생성 (근거·패치 버전 포함)
• 후속 질문으로 맥락을 이어가는 drill-down 대화 지원

7-3. 사후 패인 분석 (Post-game Review)

사용자의 최근 매치 데이터를 메타 데이터와 비교해 코칭 답변을 제공하는 기능. 데이터는 op.gg MCP가 아닌 Riot 공식 API(Match-V1)로만 조회한다 — op.gg MCP의 TFT 도구 목록에는 개인 전적 조회 기능이 없기 때문이다(10-1 참고). 이번 PRD는 개인/비상업 목적의 MVP로 한정하므로 Riot Personal Key만으로 구성하며, 본인 + 지인 약 10명 규모로 운영한다(9-1 참고). Production Key·RSO 로그인 전환은 상업 서비스로 넘어갈 때의 일이라 이번 범위가 아니며 14장 백로그에 남겨둔다.

• 로그인 없이 Riot ID(게임명#태그) 입력 → PUUID 변환 후 브라우저 로컬스토리지에 저장, 소수 개인 사용자 대상으로 제공 (Personal Key 레이트리밋 한도 내)
• 분석 요청 시 Match-V1으로 최신 매치 ID 조회 → 매치 상세(조합/아이템/증강체/등수) 확보
• 매치 데이터 vs 메타 데이터(RAG DB) 비교: 조합의 메타 이탈도, 아이템 집중도, 증강체 시너지 여부 계산
• sLLM이 비교 결과를 근거로 잘한 점·아쉬운 점·다음 게임 제안을 자연어로 생성
• 프라이버시: 같은 매치의 다른 플레이어 데이터 중 익명 처리 안 된 상대 Riot ID는 노출 금지 (조합 정보 언급은 가능, 닉네임은 마스킹)

AI 코칭의 실제 구조: 위 비교·코칭 로직에서 '무엇이 문제였는지'를 판단하는 부분(조합 이탈도, 아이템 집중도, 증강체 시너지 계산)은 규칙 기반 계산이며 LLM은 이 계산 결과를 근거로만 코칭 문장을 작성한다 — LLM이 직접 게임을 분석하거나 근거 없는 판단을 내리지 않는다. 이는 답변의 일관성과 재현성을 보장하기 위한 의도된 설계다.

실시간(게임 진행 중) 코칭은 이번 범위가 아니다. Riot의 실시간 게임 데이터는 로컬 클라이언트에서만 조회 가능해 서버가 원격으로 진행 중인 경기를 들여다볼 방법이 없고, Riot TFT 개발자 정책도 실시간 정보·상대 스카우팅·플레이어 행동 지시 앱을 승인 불가로 명시한다(10-1 참고). 이번 기능은 경기 종료 후 사후 분석으로 한정한다.

7-4. 반응형 디자인 (모바일/태블릿 대응)

이번 서비스는 웹사이트 단일 코드베이스로 데스크톱뿐 아니라 모바일·태블릿 이용자에게도 동일한 기능을 제공한다. 브레이크포인트는 모바일 <768px, 태블릿 768~1023px, 데스크톱 1024px 이상 3단계로 정의하며(1.0 확정), 화면별 세부 레이아웃은 화면설계서 1-2·2장을 따른다.

• 카탈로그 페이지(티어리스트/조합 상세/아이템 빌드/증강체): 데스크톱은 카드 그리드, 태블릿은 2열 그리드, 모바일은 1열 카드 스택으로 전환한다
• 글로벌 내비게이션(GNB): 데스크톱·태블릿은 가로 내비게이션 바를 노출하고, 모바일은 햄버거 아이콘을 눌러 여는 전체화면 드로어 메뉴로 축소한다
• 챗봇 위젯: 데스크톱·태블릿은 우하단 플로팅 위젯으로 유지하고, 모바일은 화면 하단 고정 바 형태로 축소했다가 탭하면 전체화면 바텀시트로 확장한다
• 필터 UI(패치/랭크/챔피언/티어): 데스크톱·태블릿은 드롭다운, 모바일은 하단 시트(Bottom Sheet) 형태로 전환해 좁은 화면에서도 조작하기 쉽게 한다
• 성능: 모바일 환경(상대적으로 느린 네트워크·기기)을 고려해 카탈로그 페이지 ISR 렌더링(5-1 참고)과 이미지 최적화를 우선 적용한다

8. 사용자 플로우

8-1. 웹사이트 경로

• 티어리스트/조합 페이지 방문
• 패치·랭크 필터 선택
• 구조화 DB 조회 결과를 표/카드로 렌더링
• 특정 조합 클릭 → 상세 페이지(빌드, 증강체 추천 등)
• 궁금한 점은 페이지 내 챗봇 위젯으로 바로 질문

8-2. 챗봇 경로

• 자연어 질문 입력
• 의도 분류 → 최신 패치 기준 데이터 검색(RAG)
• sLLM이 검색 결과 근거로 답변 생성 (티어/승률/추천 이유 + 패치 버전 명시)
• 답변에 관련 웹사이트 상세 페이지 링크 제공
• 후속 질문으로 drill-down (예: '그 조합에 어울리는 증강체는?')

8-3. 사후 패인 분석 경로

이번 PRD는 개인/비상업 목적의 MVP 범위이므로 Riot Personal Key + 로컬스토리지 기반 흐름만 다룬다. 상업 서비스로 전환할 때의 RSO 로그인 기반 흐름은 14장 백로그 참고.

• 계정 연동(최초 1회, 로그인 불필요): Riot ID(게임명#태그, 지역) 입력 → PUUID 변환 후 브라우저 로컬스토리지에 저장, 다음 방문부터 자동 재사용
• 다른 계정 분석: 소유 인증이 없는 구조라 언제든 다른 Riot ID를 입력해 그 계정을 분석 가능 — '다른 계정으로 분석' 동선으로 최근 조회한 여러 계정을 오가며 사용
• 분석 요청: 챗봇에 '방금 게임 분석해줘' 입력 또는 웹사이트 '최근 전적 불러오기' 버튼 클릭
• 매치 데이터 조회: Match-V1으로 매치 상세 확보 (게임 종료 후 API 반영까지 짧은 지연 가능)
• 메타 비교 분석: 현재 패치 메타 데이터와 비교 (조합 이탈도, 아이템 집중도, 증강체 시너지)
• 코칭 답변 생성: 잘한 점·아쉬운 점·다음 게임 제안을 자연어로 생성
• 결과 전달: 챗봇에 요약 코칭 표시, 필요 시 웹사이트 상세 리포트 페이지(라운드별 등수 변화, 아이템 타임라인 등)로 연결

9. 시스템 아키텍처

[데이터 수집] → [정규화/저장] → [공통 데이터 계층] → [웹사이트] / [챗봇(RAG+sLLM)]

9-1. 데이터 수집 계층

• op.gg MCP 배치 호출 (주기적, 예: 1일~수 시간 단위) — 메타 조합/아이템/증강체/빌드. 이번 버전의 1차이자 사실상 유일한 메타 데이터 소스로 확정 (10-1 참고)
• Riot API (Match-V1) — op.gg MCP에는 TFT 개인 전적 조회 도구가 없어, 9-1c 사후 패인 분석 모듈에서 개인 매치 조회 전용으로 필수 사용
• MetaTFT — 이번 버전 범위에서 제외 결론(10-1 참고). 추후 보조 지표가 필요해질 때만 재검토

자동 패치 감지 및 갱신 트리거

패치 발생 여부를 수동으로 확인하지 않고, 두 가지 신호를 폴링해 자동으로 감지한다.

• 1차 신호(즉시성 높음): GitHub Actions 크론(예: 매시간)이 op.gg MCP의 메타 데이터 도구 응답에서 patch_version 관련 필드를 조회 → 직전 저장값과 다르면 패치로 판단하고 즉시 전체 배치 재수집을 트리거. 실제 사용할 필드명은 op.gg MCP 응답에 문서화돼 있지 않아(README에는 도구 목록과 desired_output_fields 문법만 공개) 구현 착수 1주차에 실제 호출로 확인하는 스파이크로 처리한다(13장 참고). 필드가 없을 경우 대안으로 Riot 챌린저/그마 리더보드 기반 소량 샘플 매치의 patch 정보를 보조 신호로 사용
• 2차 신호(보조, 이름 매핑용): Data Dragon versions.json을 별도로 폴링해 챔피언/아이템/증강체 ID↔이름 매핑을 갱신. ddragon 갱신은 Riot이 수동으로 처리해 패치 대비 최대 이틀 정도 앞뒤로 어긋날 수 있어 '패치 감지'의 기준으로 삼지 않고, 매치 데이터 신호로 이미 트리거된 갱신에 이름 매핑만 보조로 얹는 용도로 사용. 다만 TFT가 Set 18(2026-08-12, 패치 18.1)부터 언리얼 엔진으로 이전하면서 Riot이 2026-06-12 TFT 데이터를 기존 League Data Dragon에서 분리해 별도의 TFT DDragon으로 이관한다고 발표했다 — 이 PRD가 전제한 "League ddragon과 동일한 versions.json 폴링" 구조가 출시(1.0 개발 착수) 시점에는 이미 바뀌어 있을 가능성이 높으므로, 9-1 스파이크(13장 참고) 때 op.gg MCP 스키마와 함께 신규 TFT DDragon 엔드포인트·버전 관리 방식도 같이 확인한다
• 따라서 데이터 수집은 '주기적 배치'이면서 동시에 '패치 변경 시 즉시 트리거'되는 이벤트 기반 방식을 병행 — 수동 체크 단계 없이 완전 자동화

Riot API 키 단계 (참고: 전체 로드맵)

이번 PRD는 개인/비상업 목적의 MVP로 한정하며, 이 범위에서는 Personal Key 하나로 충분하다. Production Key·RSO는 상업 서비스로 전환할 때 필요한 다음 단계로, 아래 표는 그 전체 그림을 참고용으로 정리한 것이며 이번 PRD에서 실행할 항목은 아니다(14장 백로그 참고).

단계	특징	용도
Development Key	포털 로그인 시 즉시 발급, 24시간마다 만료(수동 재발급 필요), 레이트리밋 최저	로컬 실험·탐색 전용. 상시 운영 파이프라인에는 부적합
Personal Key (이번 MVP가 사용하는 단계)	제품 등록만으로 발급(심사 없음), 만료 없음, 레이트리밋은 Development Key와 동일(상향 불가)	개인 또는 소규모 비공개 커뮤니티용 — 이번 PRD의 사후 패인 분석은 이 단계로 끝까지 운영
Production Key (참고, 이번 범위 아님)	정식 심사 필요, 공식 안내 기준 약 2주(영업일 10일), 실제 사례는 3~6주 이상도 흔함	상업/일반 공개 서비스, RSO 연동의 전제 조건 (14장 백로그)

• RSO(Riot Sign-On) OAuth 연동은 Production Key 승인 이후에만 신청 가능하며, 이번 PRD 범위에서는 다루지 않는다 (14장 백로그 참고)
• Personal Key 레이트리밋 한계상 사후 패인 분석은 소수 개인 사용자 규모(본인+지인 약 10명)로 운영 — Personal Key의 공식 용도('개인 또는 소규모 비공개 커뮤니티용')와 이번 PRD의 비상업 개인 서비스 범위가 정확히 일치함

계정 연동 및 개인 매치 분석 모듈 (Personal Key)

로그인/회원 시스템 없이, 브라우저 로컬스토리지 기반의 클라이언트 저장 방식으로 구성한다.

• Riot ID → PUUID 변환은 서버가 최초 입력 시점에 처리해 결과만 프론트엔드에 반환 — 서버 측 회원 계정에 귀속시키지 않고, 브라우저 로컬스토리지/쿠키에 저장해 재사용 (브라우저 변경·쿠키 삭제 시 재입력 필요)
• 소유 인증 없는 구조 — 임의의 Riot ID를 입력해 조회·분석 가능(본인 부계정, 지인 계정 등). 로컬스토리지는 단일 값이 아닌 '최근 조회 계정 목록'으로 관리해 여러 계정을 오가며 분석 가능하게 함
• Match-V1으로 최신 매치 ID 조회 → 매치 상세(조합/아이템/증강체/등수) 확보
• 매치 데이터 vs 메타 데이터 비교 로직으로 코칭 근거 계산
• 프라이버시: 비-익명 상대 Riot ID 노출 금지, 닉네임 마스킹
• 참고: Riot 정책상 '본인 전적 조회 툴'은 RSO 연동이 필요한 유스케이스로 명시돼 있어, 향후 상업 서비스로 공개 전환할 경우 위 로컬스토리지 방식을 RSO(Riot Sign-On) OAuth 로그인으로 바꿔야 한다. 이번 PRD 범위는 아니며 14장 백로그에 남겨둔다

9-2. 정규화/저장 계층

• 챔피언/아이템/증강체 ID ↔ 한글명 매핑 (Data Dragon/TFT Assets)
• 모든 레코드에 patch_version 태깅 (구버전 데이터 혼입 방지 — 패치 경계에서 특히 중요)
• 저장소: 구조화 DB(PostgreSQL) + 벡터DB(pgvector/Chroma, RAG 검색용 임베딩)

9-3. 웹사이트 계층

• 티어리스트/조합 상세/아이템 빌드/증강체 페이지 — 구조화 DB 직접 조회 렌더링 (LLM 불필요), 4개 페이지 전체 1.0 확정
• 검색/필터 기능(패치별, 랭크별, 챔피언별)
• 페이지 하단/사이드에 챗봇 위젯 삽입
• 모바일/태블릿/데스크톱 3단계 브레이크포인트에 따라 레이아웃을 전환한다(7-4 참고) — 반응형 처리는 프론트엔드가 담당하며 백엔드 조회 API 응답은 브레이크포인트와 무관하게 동일하다

9-4. 챗봇 계층 (RAG + sLLM)

• 사용자 질의 → 의도 분류 → 의도별 검색 쿼리 생성 → DB 조회
• 검색 결과 + 질의를 sLLM 프롬프트에 결합해 답변 생성 (근거·패치 버전 포함)
• 답변 내 웹사이트 상세 페이지 링크 첨부

9-5. 공통 서빙/운영

• API 게이트웨이: 웹사이트용 조회 API / 챗봇용 대화 API 분리
• 캐싱(Redis): 동일 패치 내 동일 질문·페이지는 캐시로 비용 절감
• 모니터링: 9-1 자동 패치 감지 트리거의 실행 여부·소요 시간 로깅, sLLM 응답 품질 로깅
• KPI 계측(3-3 연계): 챗봇 질의·근거문서/patch_version·답변, 링크 클릭, 계정연동·분석요청, 요청-응답 지연(콜드스타트 플래그 포함)을 Postgres 구조화 로그로 적재
• 대시보드/알림: 주간 Metabase 대시보드로 3-2 목표 대비 달성률 확인, 2주 연속 미달 시 알림 및 원인 분석 태스크 생성

9-6. 데이터 적재(배치) vs RAG 검색(실시간) 구분

• 데이터 수집은 배치: 질문마다 외부 API를 직접 호출하지 않고, 미리 가공해 DB에 적재
• RAG 검색은 실시간: 질문 순간 이미 적재된 DB에서 검색해 LLM 프롬프트에 결합 (외부 API 실시간 호출은 아님)
• 웹사이트는 RAG가 아님: 구조화 DB를 SQL로 직접 조회해 표로 렌더링, LLM/RAG 파이프라인 미경유
• 캐싱: 자주 나오는 질문('지금 메타 1티어 조합' 등)은 매번 새로 생성하지 않고 캐시 재사용

10. 데이터 전략

10-1. 데이터 소스 비교

데이터 소스를 op.gg MCP(메타 데이터) + Riot API(개인 매치 조회)로 확정했다. MetaTFT는 이번 범위에서 제외한다. 이번 PRD는 개인/비상업 목적의 MVP로 한정하므로, 아래 '상업적 이용' 관련 리스크는 지금 당장 해소해야 하는 항목이 아니라 상업 전환 시 확인할 사항이다(14장 백로그 참고).

소스	원본/가공	접근 난이도	상업적 이용(참고용)	리스크	이번 버전 역할
op.gg MCP	가공(완제품)	낮음 (공식 MCP)	비상업 MVP는 해당 없음. 상업 전환 시 서면 동의 필요 가능성 높음	MIT는 코드에만 적용, 데이터는 별도 약관 적용. TFT 개인 전적 조회 도구 없음	메타 데이터 1차·유일 소스
Riot API	원본	낮음 (Personal Key, 심사 없음)	비상업 MVP는 해당 없음. 상업 전환 시 Production Key 승인 필요	Legends/Legend 기반 증강체 승률 표시 금지, Personal Key 레이트리밋 낮음	개인 매치 조회(Match-V1) 전용 필수 소스
MetaTFT (api-hc)	가공(완제품)	낮음 (기술적으로 열려있음)	불명확	ToS상 무단 재사용 리스크	이번 범위 제외

op.gg MCP

opgginc/opgg-mcp (GitHub 저장소, MIT 라이선스), 엔드포인트 https://mcp-api.op.gg/mcp. TFT 도구는 tft_get_champion_item_build, tft_get_play_style, tft_list_augments, tft_list_champions_for_item, tft_list_item_combinations, tft_list_meta_decks 6개이며, 메타 정보 웹사이트·챗봇 기능(7-1, 7-2)은 이 6개 도구만으로 완전히 구성 가능하다. 공식 README는 도구 목록과 desired_output_fields 필드 선택 문법만 문서화하고 있고 실제 응답 스키마(필드명 전체 목록)는 공개돼 있지 않다 — patch_version에 해당하는 필드가 실제로 존재하는지는 문서 조사로 확정할 수 없으며, 구현 착수 시 실제 호출로 확인하는 스파이크가 필요하다(9-1, 13장 참고).

라이선스는 두 layer로 분리해서 봐야 한다. MIT 라이선스는 이 저장소의 코드(MCP 서버 구현체)에만 적용되는 것으로, 저작권 고지만 유지하면 코드를 자유롭게 쓸 수 있다는 뜻이지 op.gg가 실제로 제공하는 데이터의 상업적 이용 권한까지 보장하지 않는다. op.gg 공식 헬프센터 FAQ는 '출처 표기만 하면 크롤링/이용이 대체로 문제없다'는 취지지만, op.gg의 정식 이용약관(Terms of Use)은 '당사의 명시적 서면 동의 없이 상업적 목적으로 이용할 수 없다'고 못박고 있다. 다만 이번 PRD는 개인/비상업 목적의 MVP로 한정하므로 이 상업 이용 조항 자체가 당장 적용되지 않는다고 보고 진행하며, 서면 동의 요청은 상업 서비스로 전환할 때 진행할 사항으로 14장에 남긴다.

또한 op.gg MCP의 TFT 카테고리에는 League of Legends 카테고리에 있는 lol_get_summoner_profile / lol_list_summoner_matches 같은 개인 전적 조회 도구가 없다 — TFT 도구 6개는 전부 집계·메타용이다. 따라서 사후 패인 분석(개인 매치 조회)은 op.gg MCP로 커버되지 않으며 Riot API가 필수다.

Riot 공식 API

TFT는 LoL과 별도의 제품으로 등록·승인해야 접근 가능하다. 원본이 매치 로그라 티어리스트를 직접 집계해야 하지만, 이번 버전에서는 메타 데이터를 op.gg MCP가 전담하므로 Riot API는 개인 매치 조회(Match-V1) 용도로만 사용해 이 집계 부담을 지지 않는다. 이번 PRD는 Personal Key만으로 운영하므로 별도의 제품 승인 절차 없이 바로 사용 가능하다.

Riot의 TFT 개발자 정책(2025년 3월 갱신 기준)은 유스케이스를 세 카테고리로 나눈다: RSO 불필요(집계·비개인 통계, 공식 랭크 리더보드 — 우리 메타 기능이 해당), RSO 필요(본인 전적 조회 툴 — 우리 사후 패인 분석이 해당하나, Personal Key·비상업 개인 서비스 범위에서는 RSO 없이도 운영 가능), 승인 불가(실시간 정보, 상대 스카우팅, 플레이어 행동 지시 앱 — 이미 범위 제외한 인게임 오버레이가 해당). 또한 'Legends 및 Legend 기반 증강체의 승률은 표시할 수 없다'는 조항이 있어, 해당 세트 메커니즘이 존재하면 그 항목만 티어리스트에서 제외해야 한다. 상업 이용 조건(데이터 브로커 금지, 무료 티어 필수 등)과 Production Key 절차는 상업 전환 시점의 일이라 14장 백로그에 남긴다.

MetaTFT (이번 범위 제외)

api-hc.metatft.com에서 별도 인증 없이 GET으로 JSON 응답을 받을 수 있음이 확인됐으나(comps_stats, unit_items_processed, games?days=7 등), 공식 문서화된 API가 아닌 내부(비공식) 엔드포인트이고 ToS는 '플랫폼 데이터는 MetaTFT 소유'라 명시해 상업적 재사용에 별도 허가가 필요할 가능성이 높다. op.gg MCP만으로 메타 데이터 요구사항이 충족되므로, MetaTFT를 편입하지 않고 추후 보조 지표가 필요해질 때 재검토하는 것으로 범위에서 제외한다.

10-2. 데이터 계층별 처리 방식

핵심 판단 기준은 '데이터가 얼마나 자주 바뀌는가'다. 자주 바뀌는 데이터를 파인튜닝으로 가중치에 박아넣으면 재학습 비용·최신성 문제가 생기므로, 갱신 주기별로 RAG/파인튜닝/프롬프트 중 어디에 둘지 나눈다.

계층	데이터 종류	갱신 주기	권장 방식
Tier 0 (정적)	게임 규칙, 용어 정의(증강체·재사공 등), 응답 톤/포맷	거의 안 바뀜	시스템 프롬프트 또는 경량 파인튜닝
Tier 1 (저빈도)	세계관/로어, 챔피언 기본 스탯(코스트·직업 태그), 아이템 조합 레시피	세트 단위(~4개월), 가끔 패치 조정	RAG 기본, 구조 안정적이라 가벼운 파인튜닝도 가능
Tier 2 (고빈도)	티어리스트, 승률/픽률, 추천 조합·증강체·아이템 순위	패치 단위(2주) + 패치 내 실시간 변동	반드시 RAG. 파인튜닝 절대 금지

• Tier 2가 서비스의 핵심 가치인데, 파인튜닝하면 (1) 2주마다 재학습 비용, (2) 재학습 사이 구버전 지식을 확신 있게 말하는 문제, (3) 신/구 지식이 가중치 안에서 섞여 환각처럼 나타날 위험이 있음. RAG는 검색 문서에 patch_version을 붙여 출처·기준 시점을 답변에 명시할 수 있음.
• 파인튜닝의 역할은 '지식 주입'이 아니라 '언어 이해·톤 보정'으로 한정: TFT 고유 용어 이해, 질문 의도 파싱, 답변 포맷 일관성. 오픈소스 sLLM은 TFT 전문 용어에 약할 수 있어 이 부분만 가볍게 LoRA로 보강 권장.
• 프레임워크: LangChain/LlamaIndex 등으로 검색-생성 파이프라인 구성. 베이스 모델은 11장에서 채택한 Groq 무료 티어가 실제로 호스팅하는 오픈소스 소형 모델 중에서 선택한다(Llama 3.1/3.3 8B·70B, Qwen3-32B, Gemma2-9B, DeepSeek R1 Distill). EXAONE 등 Groq 무료 티어가 지원하지 않는 모델은 자체 GPU 호스팅으로 전환하기 전까지 후보에서 제외한다(11-1 참고, 1.0 확정 과정에서 발견해 수정한 v0.4와의 불일치).
• 파인튜닝 체크포인트를 올릴 수 없는 무료 API 제약상, LoRA 보강이 필요해지는 시점은 커스텀 GPU 호스팅 전환 시점과 맞물린다(11-1의 (A) 선택지, 13장 참고).

11. 호스팅/인프라 전략

구성 요소별로 무료 가능 여부가 다르다. MVP는 거의 무료로 구축 가능하나, sLLM 추론 부분에서 병목이 생긴다.

구성 요소	무료 옵션	제약/주의사항
웹사이트 프론트엔드	Cloudflare Pages, Vercel, Netlify	Vercel Hobby 플랜은 상업적 이용 금지 조항 있음 — 상업 서비스면 Pro 필요. Cloudflare Pages가 상대적으로 자유로움
백엔드 API(챗봇 API)	Render 무료 웹서비스(512MB RAM)	미사용 시 슬립 → 콜드 스타트 지연(수 초~수십 초). 데모엔 괜찮지만 실사용자 응대엔 불편할 수 있음
DB (구조화 + 벡터)	Supabase 무료 Postgres + pgvector, 또는 Qdrant Cloud 무료 티어	구조화 데이터와 벡터 검색을 하나의 무료 DB로 해결 가능
배치 데이터 수집(스케줄러)	GitHub Actions 무료 티어	주기적 크론잡으로 op.gg MCP 호출 → DB 적재. Riot API(Match-V1)는 Personal Key 레이트리밋에 묶여 있어 사후 패인 분석은 본인+지인 약 10명 규모로 운영
sLLM 추론	Groq 무료 API (Llama 3.1/3.3, Qwen3-32B, Gemma2-9B, DeepSeek R1 Distill 등 오픈소스 모델)	진짜 병목 지점. GPU 추론은 무료 서버에 없음. 요청 수 제한 있음(무료 티어 분당 30회·일 1,000회 수준), 커스텀 파인튜닝 체크포인트는 못 올림. EXAONE은 미지원 확인(10-2 참고)

11-1. sLLM 추론 선택지

• (A) 직접 파인튜닝한 커스텀 모델 자체 호스팅: GPU 서버 필요, 사실상 유료(RunPod, Vast.ai 등 저가 GPU 임대라도 비용 발생)
• (B) 파인튜닝 없이 무료 호스팅 API 그대로 호출: Groq 무료 티어로 오픈소스 모델(Llama 3.1/3.3, Qwen3-32B, Gemma2-9B, DeepSeek R1 Distill 등) 사용. '파인튜닝은 톤/용어 보정용으로만' 방향과 맞물려, 초기엔 프롬프트+RAG만으로 이 옵션을 쓰는 게 합리적

11-2. 권장 전략

• MVP 단계: Cloudflare Pages(프론트) + Render 무료(백엔드) + Supabase 무료(DB+벡터) + GitHub Actions(스케줄러) + Groq 무료 API(LLM 추론, Groq가 실제 지원하는 모델 중 선택) 조합으로 비용 거의 없이 구축
• 이번 PRD(개인/비상업 MVP, 본인+지인 약 10명)는 위 무료 구성으로 충분하며, 트래픽 증가나 상업 서비스 전환에 따른 유료 플랜 전환·Riot Production Key 신청 등은 이번 범위가 아니다(14장 백로그 참고)

12. 리스크

• op.gg MCP 데이터 라이선스 리스크(상업 전환 시): 비상업 MVP 범위에서는 당장 문제되지 않으나, 서비스 전체가 이 단일 소스에 의존하므로 상업 전환 시점에 서면 동의를 못 받으면 메타 데이터 기능 자체가 흔들리는 집중 리스크(14장 백로그)
• Riot API 정책 리스크: Legends/Legend 기반 증강체 승률 표시 금지 조항은 비상업 개인 이용에도 적용되는 게임 정책이므로 지금부터 준수 필요. 데이터 브로커 금지·무료 티어 필수 등 모네타이제이션 조항은 상업 전환 시 해당
• Personal Key 레이트리밋 리스크: 레이트리밋이 Development Key와 동일해 상향이 안 되므로, 사후 패인 분석은 본인 + 지인 약 10명 규모로 운영(3-2/7-3 참고). 이 규모를 넘어서면 병목 발생
• TFT 언리얼 엔진 이전(Set 18, 2026-08-12) 및 TFT DDragon 분리 리스크: Riot이 2026-06-12 발표한 대로 TFT 데이터가 기존 League Data Dragon에서 별도의 TFT DDragon으로 이관된다. 개발 착수 시점이 이 전환과 겹치므로, 9-1/9-2가 전제한 ddragon 이름 매핑 파이프라인이 계획대로 동작하지 않을 수 있다. 엔진 전환 초기에는 op.gg MCP·Riot API 응답 자체도 일시적으로 불안정하거나 필드가 바뀔 가능성이 있어, 9-1 구현 스파이크 때 이 세 가지(op.gg 스키마, TFT DDragon 신규 구조, Riot API 응답 안정성)를 함께 확인하는 것을 권장
• 패치 경계 데이터 정합성: patch_version 태깅 누락 시 구버전 데이터가 최신인 것처럼 노출될 위험
• 무료 인프라 한계: 콜드 스타트, LLM API 요청 제한(Groq 분당 30회 수준)으로 실사용자 트래픽 대응에 한계
• 프라이버시: 매치 조회 시 노출되는 상대 플레이어 정보 처리 미흡 시 개인정보 이슈 발생 가능(Riot의 '비식별 플레이어 식별 금지' 정책 위반 소지도 포함)
• AI 코칭 판단 신뢰성 리스크: 조합 이탈도·아이템 집중도·증강체 시너지의 구간 임계값(예: 이탈도 0.3/0.6)은 실사용 데이터로 검증된 기준이 아니라 초기 가설치다. 판단 자체는 LLM이 아닌 규칙 기반 계산이 담당하지만, 그 규칙의 정확도를 높이려면 별도의 라벨 데이터셋과 평가체계가 필요하며 이번 MVP 규모(본인+지인 약 10명)에서는 자체 데이터만으로 통계적 보정이 어렵다 (15장 참고)
• 반응형 QA 리소스 제약: 개인/비상업 MVP 규모상 다양한 실제 기기로 폭넓게 검증하기 어려우므로, 주요 브라우저·기기(모바일은 iOS Safari·Android Chrome, 데스크톱은 Chrome) 위주로 검증하고 그 외 조합은 출시 후 이용자 피드백으로 보완한다

13. 1.0 확정 결정 로그 및 남은 작업

v0.4까지 13장은 'PRD 확정 전 확인이 필요한 사항' 9개를 성격 구분 없이 나열하고 있었다. 1.0 확정 과정에서 이 9개 항목을 실제 성격에 따라 세 그룹으로 재분류했다 — 지금 결정할 수 있는 제품 판단, 구현 착수 시 처리할 기술 스파이크, 그리고 애초에 출시 후에만 확정 가능한 항목이다. 이렇게 나누고 나면 1.0 확정을 실제로 막고 있던 항목은 없었다.

13-1. 이번 1.0 확정 과정에서 결정된 사항

항목	결정	반영 위치
웹사이트 UI/UX 범위	티어리스트·조합 상세·아이템 빌드·증강체 4개 페이지 전체를 1.0 범위로 확정	5-1, 7-1, 9-3
챗봇 배포 형태	웹사이트 내장 위젯 단일 채널로 확정. 디스코드봇 등 추가 채널은 Out of Scope로 이관(같은 챗봇 API를 재사용하므로 이후 추가 자체는 어렵지 않음)	5-1, 5-2, 7-2
초기 예상 이용자 규모	본인 + 지인 약 10명. Personal Key 레이트리밋(Development Key와 동일 수준) 내에서 여유 있는 규모	3-2, 7-3, 9-1, 12
3-3절 KPI 계측 도구 확정	GA4/PostHog/Grafana 대신 Postgres 구조화 로그 + Metabase(대시보드) + RAGAS(근거율 평가)로 확정. 이용자 규모(약 10명)에서는 별도 SaaS 분석 도구가 과한 스펙이라는 판단	3-3, 9-5
sLLM 베이스 모델 선정	Groq 무료 티어 실제 지원 모델을 확인한 결과 Llama 3.1/3.3, Qwen3-32B, Gemma2-9B, DeepSeek R1 Distill이 후보. 기존 v0.4가 후보로 들었던 EXAONE은 Groq 미지원으로 확인되어 제외(11장 채택 인프라와의 불일치 수정)	10-2, 11-1, 11-2
데이터 갱신 주기	9-1에 기재된 매시간 폴링(GitHub Actions 크론)을 그대로 확정. 리스크 낮음	9-1
커스텀 파인튜닝 필요 시점	특정 시점을 미리 못박기보다 트리거 조건으로 관리: Groq 무료 한도 초과가 잦아지거나 sLLM 답변 품질 이슈가 반복될 때 자체 GPU 호스팅 전환을 검토	10-2, 11-1
반응형 지원 여부	1.0 범위에 포함하기로 확정. 브레이크포인트는 모바일 <768px / 태블릿 768~1023px / 데스크톱 1024px 이상 3단계로 정의하고, 모바일은 카드 스택형 카탈로그 레이아웃 · GNB 햄버거 메뉴 · 챗봇 위젯 하단 바→전체화면 바텀시트 전환을 적용한다	5-1, 7-4, 9-3, 12

13-2. 구현 착수 시 처리할 스파이크 (1.0 확정의 선행조건 아님)

• op.gg MCP 실제 응답 스키마 확인: 공식 README는 도구 목록과 desired_output_fields 필드 선택 문법만 문서화하며 실제 응답 필드 전체 목록은 공개돼 있지 않다. patch_version에 해당하는 필드가 실제로 존재하는지는 9-1 자동 패치 감지 트리거 구현 착수 시 MCP를 직접 호출해 1회 확인하면 되는 개발 스파이크이며, PRD 확정을 막을 이유가 없다. 필드가 없을 경우의 대안(Riot 챌린저/그마 리더보드 샘플링)도 9-1에 이미 명시돼 있다.
• TFT DDragon 신규 구조 확인: TFT가 Set 18(2026-08-12)부터 언리얼 엔진으로 이전하며 TFT 데이터가 League Data Dragon에서 분리된 TFT DDragon으로 이관된다(2026-06-12 발표, 9-1/12 참고). 9-2 이름 매핑 파이프라인 구현 시 신규 엔드포인트·버전 관리 방식을 op.gg 스키마 확인과 함께 스파이크로 처리한다.

13-3. 출시 후 재보정 예정 (1.0에 이미 포함된 후속 작업, 확정을 막는 미해결 항목 아님)

• 3-2절 KPI 목표 수치: 실사용 데이터가 없는 상태에서 업계 벤치마크로 보수적으로 잡은 초기 가설치이며, 애초에 "출시 후 2~4주 실측 데이터로 재보정"을 전제로 설계됐다. 이 항목이 13장에 '확인 필요 사항'으로 남아 있던 것은 성격 오분류였다 — 재보정은 1.0 출시 이후 정상적으로 실행되는 계획이지, 1.0 확정을 가로막는 미해결 항목이 아니다.

13-4. 종료된 항목

• MetaTFT api-hc.metatft.com 재검토 여부: v0.3에서 이미 "이번 범위 제외"로 결론이 난 항목으로, 재확인이 필요한 열린 질문이 아니었다. 10-1에 결론이 명시돼 있어 13장에서 제거한다.

14. 상업 서비스 전환 시 확인사항 (백로그)

이번 PRD는 개인/비상업 목적의 MVP로 한정한다. 아래 항목들은 지금 결정할 필요가 없고, 서비스를 상업적으로 운영하기로 결정해 PRD를 갱신하는 시점에 다시 꺼내 확인·실행한다.

• op.gg에 상업적 이용에 대한 서면 동의 요청 (contact@op.gg / service@op.gg) — 회신 전 상업 출시를 강행할지, 회신을 기다릴지 의사결정 필요 (10-1 참고)
• Riot Production Key 신청 및 심사 대응 — 실제 호스팅된 사이트 + 이용약관·개인정보처리방침 게시가 선행 조건, 심사 기간 2주~수 주 감안해 일정 역산 (9-1 참고)
• Production Key 승인 후 RSO(Riot Sign-On) OAuth 연동 신청 및 로컬스토리지 방식 → 로그인 기반 전환 (7-3, 8-3, 9-1 참고)
• 이용약관·개인정보처리방침 페이지 작성 및 게시 (Production Key 신청의 선행 조건)
• 무료 티어 설계 — Riot 모네타이제이션 정책상 유료화 시 무료 티어 필수 조항 적용, 데이터 브로커 금지·'transformative' 콘텐츠 요건도 이 시점에 재확인
• 유료 인프라 전환 — 프론트엔드(Vercel Pro 등 상업 이용 허용 플랜), 백엔드(콜드 스타트 제거), LLM(유료 종량제 API 또는 자체 GPU 서버) 단계적 전환 (11장 참고)
• Riot API 레이트리밋 상향 요청 — Production Key 승인 후 사용량 실적을 근거로 별도 신청
• MetaTFT 재검토 — 보조 지표가 필요해지면 허가 확보 절차 진행 여부 판단 (10-1 참고)
• 챗봇 추가 배포 채널(디스코드봇 등) 재검토 — 웹 위젯 채널의 이용자 반응 확인 후 별도 트랙으로 진행 여부 판단 (5-2 참고)

15. AI 코칭 고도화 로드맵 (참고, 이번 범위 아님)

이번 PRD의 사후 패인 분석(7-3)은 규칙 기반 스코어링 + LLM 언어화 구조로 확정한다. 아래는 향후 'LLM이 직접 분석 판단까지 맡는' 방향으로 고도화하고 싶을 때 검토할 항목이며, 지금 결정할 필요가 없는 참고용 백로그다. 상업 전환과 무관하게, 데이터·평가 체계가 갖춰지는 시점에 별도로 재검토한다.

15-1. 데이터 한계

• Riot Match-V1은 경기 최종 상태(유닛/아이템/증강체/등수)만 제공하고, 라운드별 골드 곡선·리롤 이력·상점 노출 이력·포지셔닝 변화·상대방 유닛 경합 정보는 제공하지 않는다. 이 데이터가 없으면 '어느 라운드에 무엇을 했어야 했는지'를 판단하는 진짜 시뮬레이션은 모델을 개선해도 불가능하다
• 다만 gold_left, level, time_eliminated, total_damage_to_players 등 Match-V1에 이미 있으나 현재 설계(4.5.1)가 쓰지 않는 필드는 있어, 새 데이터 없이도 분석을 조금 더 풍부하게 만들 여지는 있다

15-2. 라벨 데이터셋·평가체계 부재

• 지금 방식(규칙 기반 계산)은 코드라서 테스트·검증이 가능하지만, LLM이 직접 판단하게 하면 그 판단이 맞는지 확인할 안전장치가 없어진다
• 사람이 직접 채점한 예시 데이터셋(예: 경기 20~30개에 대한 전문가 판단)을 먼저 만들고, 그 기준으로 LLM 판단의 정확도를 재는 평가 지표를 갖춘 다음에야 파인튜닝이든 프롬프트 개선이든 시도할 수 있다 — 순서가 반대로 되면 검증 불가능한 기능이 된다

15-3. 통계 표본 부족

• 이탈도·집중도 구간 임계값처럼 '이 정도면 잘한 편이다'라는 감각은 실제 경기 데이터로 계산한 백분위가 있어야 신뢰할 수 있는데, 이번 MVP는 본인+지인 약 10명 규모라 자체 데이터로는 통계가 쌓이지 않는다
• 의미 있는 백분위를 만들려면 op.gg 같은 대규모 집계 데이터가 필요한데, 이는 10-1/12장에서 이미 다룬 상업적 이용 라이선스 문제로 다시 연결된다

15-4. 단계적 접근 (착수 시 참고)

• 1단계: Match-V1의 미사용 필드(골드, 레벨, 탈락 시점 등) 활용해 결정론적 지표부터 확장 — 모델/학습 변경 없이 가능
• 2단계: 소규모 라벨 데이터셋을 직접 제작해 평가 기준선 확보
• 3단계: 파인튜닝보다 먼저 에이전트형 프롬프트(LLM이 필요 시 통계 조회 도구를 호출하는 방식) 시도 — PRD 10-2의 '파인튜닝은 톤 보정용' 원칙과 일관됨
• 4단계: 위 단계로도 부족하다고 판단될 때만 파인튜닝(SFT) 검토, 이때도 지식 주입이 아닌 판단 패턴 학습으로 범위를 한정