1) 서비스 개념
SUPERSUB(슈퍼서브)은 아마추어 축구·야구 동호인을 위한 용병(대체 선수) 매칭 및 실력분석 플랫폼이다. 이름은 축구에서 교체 투입되어 기대 이상의 활약을 하는 선수를 가리키는 “슈퍼 서브(super substitute)”에서 따왔다 — 낯선 팀에 들어가도 제 몫을 하는 선수를, 그 실력을 미리 알고 부를 수 있게 하겠다는 뜻이다.
2장에서 정리했듯 지금의 용병 구인은 오픈채팅방·지인 소개 같은 비정형 채널에 의존하고, 실력·매너는 직접 겪어보기 전까지 확인할 방법이 없다. SUPERSUB은 이 문제를 매칭과 검증을 하나의 흐름으로 묶어 푼다.
- 매칭 — 팀은 부족한 포지션과 필요 인원을 등록하고, 용병은 그 공고에 지원한다. 채팅방 공지보다 구조화된 데이터(포지션, 실력 구간, 일정)로 연결되므로 검색·필터링이 가능하다.
- 검증 — 지원자의 실력은 자기소개가 아니라 본인이 올린 경기 영상을 코드가 측정하고 AI 에이전트가 판정한 결과로 뒷받침된다. 측정과 판단을 분리하는 이유는 아래 3)절에 있다.
두 축은 서로를 보강한다. 검증된 데이터가 쌓일수록 매칭의 신뢰도가 올라가고, 매칭이 반복될수록 검증에 쓸 영상과 상호 평가가 쌓인다.
2) 주요 기능
아래 네 기능군은 실제 구현 경계와도 그대로 대응한다 — 기능 단위와 구현 단위를 일치시켜, 한쪽을 바꿀 때 다른 쪽을 추측하지 않아도 되게 했다.
| 기능군 | 하는 일 |
|---|---|
| 매칭 | 팀이 경기·훈련을 등록하고 필요 포지션·인원을 명시한다. 용병은 조건에 맞는 공고에 지원하고, 팀은 지원자 중 후보를 고른다. |
| 실력 분석 | 업로드한 영상에서 관절 각도·궤적 등을 코드로 측정하고, AI 에이전트가 채점 기준과 대조해 항목별로 판정한다. 점수를 모델이 지어내지 않는다는 원칙은 3)절에서 다룬다. |
| 선수 카드·호칭 | 분석 결과를 근거로 호칭을 부여하고, 카드 형태로 공개 공유할 수 있게 한다. 카드에는 판정 결과의 요약만 담고 원 수치는 노출하지 않는다. |
| 상호 평가 | 경기 종료 후 참가자끼리 선택형으로 서로를 평가한다. 노쇼·신고 같은 제재성 기록은 평가 점수와 분리해 별도로 남긴다. |
각 기능군의 세부 설계는 아래 3)~5)절과 시스템 설계에, 기능 단위의 현재 구현 상태는 요구사항 분석에 정리되어 있다.
3) 영상 분석 및 AI 에이전트 적용 방안
기본 원칙 — 측정과 판단의 분리
영상을 언어 모델에 그대로 넣고 “점수를 매겨 달라”고 요청하는 방식은 채택하지 않는다. 언어 모델은 픽셀에서 관절 각도를 측정할 수 없다. 그런 요청을 받으면 측정하지 않은 수치를 그럴듯하게 만들어 내고, 같은 영상을 두 번 넣으면 다른 점수가 나온다. 근거를 제시할 수 없는 점수는 실력 검증 서비스의 산출물이 될 수 없다.
따라서 세 역할을 분리한다.
| 단계 | 담당 | 산출물 | 적재 위치 |
|---|---|---|---|
| 측정 | 포즈 추정 (결정론적 코드) | 관절 각도, 각속도, 무게중심 궤적 | analysis_metric_value |
| 판단 | AI 에이전트 (언어 모델) | 항목별 등급, 판정 근거, 요약 문장 | analysis_report |
| 합산 | 애플리케이션 코드 | 총점, 등급 | analysis_metric_value |
언어 모델은 수치를 생성하는 주체가 아니라, 코드가 측정한 수치를 채점 기준과 대조해 판정하는 주체다. 부록 D가 지표 테이블과 리포트 테이블을 분리한 것도 같은 이유이며, 이 문서의 설계는 그 구조를 그대로 따른다.
처리 흐름
영상 업로드
│
├─ (A) 포즈 추출 프레임별 관절 좌표 시계열
├─ (B) 특징 추출 정규화 → 동작 구간 분할 → 각도·속도·궤적 산출
├─ (C) 기준 조회 (종목, 동작) → 채점 루브릭
├─ (D) 에이전트 판정 수치 + 기준 → 항목별 등급 + 근거 + 코멘트
└─ (E) 점수 합산 항목 등급 × 가중치 → 총점
(A)와 (B)는 재현 가능한 계산이다. 같은 영상은 언제나 같은 수치를 낸다. (D)만이 판단이 개입하는 단계이며, 여기서 나온 결과도 근거가 되는 측정값과 프레임 번호를 함께 남긴다. 상세 설계는 시스템 설계 3)·4)절에 기술한다.
촬영 조건의 표준화
카메라 거리와 각도가 다르면 같은 자세라도 다른 수치가 나온다. 이를 보정하기 위해 어깨 너비를 기준으로 스케일을 정규화하고 골반 중심을 원점으로 이동시킨다. 다만 정규화로 흡수되지 않는 편차가 있으므로, 업로드 단계에서 촬영 가이드(측면 촬영, 전신 포함, 최소 해상도)를 제시하고 video_validation에서 규격을 검사한다.
4) 실력 검증 및 적합도 판단
루브릭 기반 채점
종목·동작별로 채점 기준(루브릭)을 문서로 정의한다. 루브릭은 항목마다 가중치, 등급 정의, 그리고 그 항목이 어떤 측정값에 근거하는지를 명시한다.
| 필드 | 내용 |
|---|---|
| 항목 ID | 채점 단위 식별자 |
| 가중치 | 총점 기여도 (합 1.0) |
| 등급 정의 | 0 / 1 / 2 각각에 해당하는 수치 조건 |
| 근거 지표 | 이 항목 판정에 사용할 측정값 이름 |
| 출처 | 기준의 근거가 된 교본·지도서 |
등급을 0·1·2의 이산값으로 두는 것은 의도적이다. 0~100의 연속 점수를 모델에 직접 매기게 하면 같은 영상에서 87점과 72점이 오간다. 사람 지도자도 “83점과 85점”은 구분하지 못하므로, 판단은 이산 등급으로 받고 연속 점수는 계산으로 만든다.
총점은 코드가 계산한다. 항목별 등급에 가중치를 곱해 합산하므로, 가중치를 조정해도 재분석 없이 재계산되고 같은 판정에서는 언제나 같은 점수가 나온다.
산출물
분석 1회의 산출물은 다음 네 가지다.
- 총점과 등급 —
analysis_metric_value에 항목 하나로 적재 - 항목별 등급과 판정 근거 — 근거가 된 측정값과 프레임 번호를 포함
- 선수에게 보여줄 짧은 코멘트 — 두 문장 이내, 교정 지시 한 가지에 집중
- 신뢰도 — 키포인트 검출 품질이 낮으면 낮음으로 표기
코멘트에 총점이나 등급 숫자를 넣지 않는다. 수치는 리포트 경로로만 조회되며 선수 카드에 능력치로 노출하지 않는다는 원칙(부록 D)과 일관된다.
검증 기준
채점 시스템의 성패는 정확도보다 재현성에서 갈린다. 같은 영상을 세 번 넣어 87 / 72 / 91이 나오면 서비스가 성립하지 않는다. 지도자 섭외 여건에 따라 지표를 둘로 나눈다 — 사람 라벨 없이 지금 측정하는 것과 골든셋이 갖춰지면 추가하는 것이다.
| 지표 | 의미 | 목표 | 비고 |
|---|---|---|---|
| 재현성 | 동일 영상 5회 반복 시 총점 표준편차 | 3점 이내 | 사람 라벨 불필요 |
| fps 불변성 | 동일 장면을 다른 프레임레이트로 넣었을 때 최종 등급 변동폭 | [TBD] | 사람 라벨 불필요 |
| 지표 타당성 | 근거 지표가 측정 대상 동작을 실제로 포착하는 정도 | [TBD] | 사람 라벨 불필요 |
| QWK | 순서형 등급의 사람-모델 일치도 | 0.6 이상 | 골든셋 확보 시 — 지도자가 라벨링한 50~100건 없이는 정의 자체가 안 됨 |
| MAE | 총점 절대 오차 (100점 만점) | 8점 이내 | 골든셋 확보 시 — 위와 동일 |
등급 경계값의 근거는 지도자 검수가 1순위이나, 여건이 안 되면 생체역학 문헌· 공개 지도 자료를 인용해 「임의값」에서 「인용값」으로 낮춘다. 저희 표본 분포에 맞춰 경계를 긋지는 않는다 — 그건 기준을 결과에 맞추는 것이지 검증이 아니다.
골든셋이 없으면 QWK·MAE는 측정할 방법 자체가 없다. 그래서 루브릭 개선 여부는 당분간 재현성·fps 불변성·지표 타당성 세 지표로 판단하고, 골든셋 라벨링은 여건이 되는 대로 진행하는 별도 트랙으로 둔다.
적합도 판단
실력 점수와 경기 적합도는 다른 값이다. 점수는 영상 1건에 대한 절대 평가이고, 적합도는 특정 경기 지원 건에 대한 상대 평가다. 부록 D의 fitness_score는 수준·역할·성향 세 축으로 이를 분리해 저장한다.
- 수준 — 모집 팀이 요구한 실력 구간과 지원자 점수의 거리
- 역할 —
match_position_need의 포지션 요구와 지원자 분석 지표의 부합도 - 성향 — 플레이 스타일 벡터(
player_vector) 간 유사도
적합도는 경기 지원 건에 종속되며 단독으로 조회하거나 순위표로 만들지 않는다. 사용자 간 비교 점수를 저장하는 테이블을 두지 않는다는 설계 원칙을 따른다.
5) 선수 카드와 호칭
(내용 작성 예정)