상태: 초안 (2026-10-13), 문서·논문 기준(우리 실측 없음). 이 글은 공식 문서(2026-10-13 열람)와 논문의 수치로 썼습니다. 우리 실험에서는 영상-언어 모델을 실제로 호출하지 않았습니다. 느린 확인 층은 계획 단계입니다. 작성 규칙: 실측 데이터가 기본이고, 못 잰 것은 「미실측」으로 표시합니다.
목차
1. 솔깃한 생각
영상-언어 모델(VLM)은 영상을 넣으면 무슨 일이 있었는지 문장으로 답합니다. 탁구 규칙도 글로 알고 있습니다. 그렇다면 1편부터 7편까지의 공 찾기, 탁구대 기하, 이벤트 규칙, 심판 엔진을 모두 건너뛰고 「이 랠리 누가 이겼어?」라고 물으면 되지 않을까요.
결론부터 말하면, 지금은 점수를 정하는 일에는 맞지 않습니다. 모델이 똑똑하지 않아서가 아니라, 점수를 정하는 순간이 모델의 입력에 들어가지 않기 때문입니다.
2. 이유 하나: 1초에 한 장
Gemini API 의 영상 이해 문서(2026-10-09 갱신)는 이렇게 적습니다.
- 영상 입력은 기본으로 1초에 한 프레임을 뽑아 처리한다.
fps를 따로 지정할 수 있다. - 낮은 해상도 설정에서 프레임 하나는 66토큰, 영상 1초는 약 100토큰이다.
- 영상 안의 특정 시점은
MM:SS꼴의 시각으로 묻는다. - 그리고 문서 스스로 경고한다: 「빠른 동작은 1 FPS 표본 때문에 세부를 잃을 수 있다.」
실시간 대화용 Live API 문서는 더 분명합니다. 영상은 낱장 그림으로 보내고 최대 1초에 한 장이며, 소리와 영상을 함께 보내는 세션은 2분으로 제한됩니다.
탁구에 대 보면 이렇습니다.
| 우리가 아는 시간 | 값 | 근거 |
|---|---|---|
| 60fps 프레임 하나 | 16.7ms | — |
| 서브의 첫 두 바운드 간격 | 0.18–0.55초, 중앙 0.40초 | 실제 경기 12편, 라벨 서브 275개(직접 잼) |
| 랠리 안 바운드 간격 | 98% 가 1.5초 안 | 같은 자료 |
| 같은 쪽 두 바운드를 의심해야 하는 간격 | 0.25초 미만 | 5편 |
1초에 한 장을 보면, 서브 하나에서 일어나는 두 바운드가 대개 같은 1초 안에, 두 표본 사이에서 지나갑니다. 「어느 쪽에 몇 번 떨어졌나」가 점수를 정하는데, 그 순간이 아예 입력에 없습니다. 모델이 할 수 있는 것은 앞뒤 장면으로 짐작하는 것뿐입니다.
fps 를 올리면 되지 않을까요. 문서는 지정 방법을 주지만 상한을 적지 않았고, 예시는 오히려 0.5 입니다. 60fps 로 보내면 토큰이 60배가 되고, 그래도 모델이 프레임 사이의 짧은 접촉을 시각으로 짚는다는 근거는 찾지 못했습니다. 시각을 초 단위로 다룬다는 점도 걸립니다. 16.7ms 단위의 순서가 중요한 판정에 초 단위 시각은 너무 거칩니다.
3. 이유 둘: 벤치마크가 보여 주는 수준
라켓 스포츠 영상에서 VLM 이 얼마나 하는지 잰 벤치마크로 TennisTV(arXiv 2509.15602, 2026-04 의 v5)가 있습니다. 테니스 영상 1,298개, 질문 2,527개, 과제 8종으로 VLM 17개를 쟀습니다.
| 대상 | 전체 정확도(논문) |
|---|---|
| 사람 | 89.2% |
| GPT-4.1 | 45.1% |
| GPT-4o | 44.5% |
| Gemini 2.5 Pro | 43.9% |
| 무작위로 고르기 | 27.9% |
가장 어려운 과제는 랠리에서 공을 몇 번 쳤는지 세기였고, Gemini 2.5 Pro 가 31.5% 였습니다. 어떤 모델은 무작위(25%)보다 낮았습니다. 비용 때문에 상용 모델은 1fps 로 평가했다는 점도 논문에 적혀 있습니다. 공개 모델(Qwen2.5-VL-7B)로 프레임 수를 바꿔 보니 1fps 38.1, 16장 38.6, 32장 38.8, 64장 38.4 로 거의 변하지 않았습니다. 프레임을 더 줘도 저절로 나아지지 않는다는 뜻입니다. 저자들은 과제마다 표본 밀도를 맞춰야 한다고 결론 냅니다.
벤치마크 판본마다 과제 수와 숫자가 조금씩 다르니, 인용할 때는 판본을 함께 적어야 합니다. 탁구를 직접 다룬 VLM 판정 벤치마크는 이번 조사에서 찾지 못했습니다.
4. 이유 셋: 실시간과 책임
- 지연. Live API 문서에는 지연 측정값이 없습니다(미확인). 1편의 판정 예산은 1.5초이고, 지금 엔진의 판정 지연 중앙값은 0.16초입니다.
- 세션. 소리 + 영상 세션이 2분이면, 경기 하나를 보는 동안 세션을 계속 이어 붙여야 합니다.
- 설명할 수 있는가. 규칙 엔진은 「이 바운드가 이 쪽에 이 시각에 났으므로 이 선수가 졌다」고 이벤트를 하나하나 보여 줄 수 있습니다. 사람이 고칠 때 어디가 틀렸는지 알 수 있습니다. VLM 의 문장 답은 그럴듯해도 어느 장면을 근거로 했는지 확인하기 어렵습니다.
5. 그래서 어디에 두나: 느린 확인 층
VLM 이 못 하는 것은 「16.7ms 안의 순서」이고, 잘하는 것은 「장면 전체의 의미」입니다. 랠리가 끝났는지, 선수가 점수를 세는 몸짓을 하는지, 공을 주우러 가는지 같은 거친 사건은 1초에 한 장으로도 보입니다. 그래서 1편의 네 층 가운데 맨 아래, 느린 확인 층에 둘 계획입니다.
- 점수판은 규칙 엔진의 판정을 그대로 올립니다. VLM 을 기다리지 않습니다.
- 「확인 필요」로 표시된 랠리만, 앞뒤 몇 초의 클립을 비동기로 VLM 에 보냅니다.
- VLM 의 답이 심판과 다르면 표시만 합니다. 점수를 바꾸는 것은 사람입니다.
비용은 작습니다. 문서 단가로 계산하면 10초 랠리 하나를 1fps 로 다시 보는 데 약 1,300토큰, 가장 싼 등급에서 약 0.0004달러입니다(문서 단가로 계산한 값, 미실측). 다만 영상을 외부 서비스로 보내는 일이라 사용자 동의와 데이터 보관 조건을 먼저 정해야 합니다. 아직 실제로 호출해 본 적은 없고, 연구 실험에서도 호출하지 않았습니다(미실측).
6. 정리
| 질문 | 규칙 엔진 | 영상-언어 모델 |
|---|---|---|
| 입력 시간 해상도 | 매 프레임(16.7ms) | 기본 1초에 한 장 |
| 시각 표현 | 초의 소수 | MM:SS |
| 판정 근거 | 이벤트 열로 보여 줌 | 문장 |
| 잘하는 것 | 바운드 순서, 쪽, 시각 | 장면의 의미, 설명 |
| TT Score 에서의 자리 | 1–3층(판정) | 4층(느린 확인, 계획) |
영상-언어 모델이 더 촘촘한 시간을 다루게 되면 이 표는 바뀔 것입니다. 그때도 같은 질문으로 다시 재면 됩니다. 「점수를 정하는 순간이 입력에 들어가는가.」
티티 한마디. 1초에 한 번 눈을 뜨는 심판은 공이 어디에 떨어졌는지 볼 수 없어요. 대신 경기가 끝난 뒤 「이 장면 이상하지 않아?」라고 말해 주는 조수로는 쓸 만할 거예요.
참고
- Gemini API 영상 이해: https://ai.google.dev/gemini-api/docs/video-understanding (2026-10-09 갱신, 2026-10-13 열람)
- Gemini Live API 가이드: https://ai.google.dev/gemini-api/docs/live-guide (2026-10-13 열람)
- TennisTV: https://arxiv.org/abs/2509.15602 (v5)
- 바운드 간격의 실측: 저장소
ttscore/referee.py머리말,events.py의END_AFTER_BOUNCE_S주석