구장 두 시간 대여, 쿼터당 20~25분. 카메라 2대를 코트 양쪽 코너에 두고 찍었습니다
카메라 2대로 찍은 풋살 4경기, AI한테 편집 맡겨봤더니 ㅋㅋ
구장을 두 시간 빌려 20~25분짜리 네 쿼터를 찍으면 풀영상이 한 시간 반쯤 됩니다. 이걸 경기당 2~4분 하이라이트로 줄였습니다. 카메라는 두 대뿐이고 함성이 후보를 던지면 골대 영역의 네트 흔들림이 그 순간을 짚습니다. 다만 아무도 환호하지 않는 조용한 골은 끝내 잡지 못했습니다.
Behind the episode
영상에 담기지 못한 것들
- 구장을 두 시간 빌려 20~25분짜리 네 쿼터를 찍으면 풀영상이 한 시간 반쯤 됩니다. 여기서 경기당 2~4분 하이라이트를 뽑는데, 골을 찾는 일은 처음부터 끝까지 함성 소리가 합니다. 화면은 보지 않습니다.
- 첫 프로토타입은 가장 시끄러운 순간에 잘랐다가 골 장면을 전부 놓쳤습니다. 함성은 공이 들어간 뒤에 터지기 때문입니다.
- 아무도 환호하지 않는 조용한 골은 끝내 못 잡았습니다. 다섯 가지 방법을 시도했고 전부 재현율 20% 이하였습니다.
- 채널의 첫 콘텐츠입니다. 미완인 채로 올렸고 다음 편의 기준선이 되라고 실패한 자리를 그대로 남겼습니다.
정답을 심은 합성 영상으로 검증했습니다. 첫 경기 파일을 넣기 전에 쌓아 뒀습니다
버그를 잡으니 38개로 줄었는데, 그 38개에도 골은 거의 없었습니다
모션량·모양 특징·정지공·공 유무 VLM·시퀀스 VLM 다섯 가지 모두
하루 만입니다. 코드는 거의 들여다보지 않았습니다
무엇이 켜져 있고 무엇이 꺼져 있나
골을 찾는 일은 처음부터 끝까지 오디오가 합니다. 프로젝트를 시작할 때 「영상 인식은 쓰지 않는다」를 제약으로 못 박았고 나중에 붙인 비전도 그 자리를 가져가지 못했습니다.
편집에서 잘린 이유영상은 소리와 비전을 붙여 완성했다고 말합니다. 그 말이 맞지만, 설정을 열어 보면 비전 쪽 기능 대부분이 꺼져 있습니다. 어느 신호가 실제로 일을 하는지는 이 표가 정확합니다.
| 기능 | 기본값 | 하는 일 |
|---|---|---|
| 함성 피크 탐지 | 항상 켜짐 | 골을 찾습니다. 이게 유일한 탐지기입니다 |
| 오디오 자동 동기화 | 항상 켜짐 | 두 카메라의 시간차를 함성으로 맞춥니다 |
| 네트 영역 프레임 짚기 | 켜서 씁니다 | 오디오가 잡은 몇 초 창 안에서만 봅니다. 스스로 골을 찾지는 않습니다 |
| 골대 영역(ROI) 지정 | 구장마다 손으로 | 편집기에서 골대에 박스를 그립니다. 이 박스가 없으면 위 기능이 돌지 않습니다 |
| VLM 골 라벨링 | 꺼짐 | 어느 클립이 골인지 표시만 합니다. 클립을 지우지는 않습니다 |
| 전체 구간 비전 스캔 | 꺼짐 | 조용한 골을 잡으려다 실패해서 껐습니다 |
공이나 골대를 추적하지 않으니 GPU도 학습 데이터도 필요 없고 노트북에서 로컬로 돕니다. 비전을 전부 꺼도 하이라이트는 나옵니다. 반대로 오디오를 끄면 아무것도 나오지 않습니다. 골대 박스는 구장을 옮길 때마다 다시 그려야 하는데, 카메라를 펜스에 고정하니 같은 구장 안에서는 한 번으로 끝납니다.
영상이 한 장도 없는 상태에서 먼저 만들었습니다
촬영은 나중이었습니다. 파이프라인을 먼저 짜고 정답을 심어 둔 가짜 영상으로 검증했습니다.
편집에서 잘린 이유영상은 완성된 파이프라인을 돌리는 장면부터 시작합니다. 그 앞에 이 단계가 있었다는 이야기는 하지 않습니다.
| 항목 | 값 | 메모 |
|---|---|---|
| 첫 파이프라인 완주 | 커밋 20개 · 하루 | 촬영본 없이 끝까지 도는 상태까지 |
| 테스트 | 26개 · 89초 | 전처리·동기화·피크·플래너·렌더·설정·전 구간 |
| 검증 방법 | 정답을 심은 합성 영상 | 밀린 오프셋과 환호성 시점을 아는 채로 만들어, 파이프라인이 그걸 되찾는지 봅니다 |
| 앵글 전환 싱크 | 목표 0.1초 미만 | 렌더 결과에서 마커 위치를 실측합니다. 인코더 잡음을 감안해 측정 예산은 0.2초 |
「영상이 없어서 못 만든다」가 아니라 정답이 박힌 더미를 만들면 된다는 쪽으로 갔습니다. 덕분에 첫 촬영본을 넣기 전에 검증이 26개 쌓였고 현장에서 터졌을 문제 대부분을 그 전에 잡았습니다.
세리머니가 전부 10초로 잘려 나온 진짜 원인
클립 길이는 소리가 잦아들 때까지 자동으로 늘어나게 만들었습니다. 그런데 결과물이 전부 최소 길이인 10초로 나왔습니다.
편집에서 잘린 이유영상은 세리머니가 잘린다는 증상과 편집기에서 손으로 고쳤다는 결말만 보여줍니다. 그 사이에 있던 기준선 버그는 나오지 않습니다.
| 단계 | 「조용하다」의 기준 | 결과 |
|---|---|---|
| 처음 | 트랙 전체의 중앙값 + 마진 | 골 장면이 중앙값을 끌어올려, 거의 모든 시점이 이미 조용함 판정을 받았습니다 |
| 증상 | 전 클립이 min_len 10초 | 길이를 유동적으로 늘리는 기능이 있으나 마나였습니다 |
| 고친 뒤 | 골 직전 빌드업 구간의 중앙값 | 12초짜리 긴 세리머니가 제대로 살아났습니다 |
「조용하다」는 절대값이 아니라 직전 상태 대비로 정의해야 합니다. 이벤트가 포함된 구간을 기준선으로 삼으면 그 이벤트가 기준선을 올려 스스로를 지웁니다. 자동으로 늘어난 뒤에도 남는 어긋남은 편집기에서 손으로 다듬습니다.
첫 촬영본에서 바로 막혔을 네 가지
실촬영 전에 하드닝 단계를 따로 뒀습니다. 여기서 잡지 않았다면 첫 경기 파일을 넣는 순간 멈췄을 문제들입니다.
편집에서 잘린 이유전부 촬영 전에 끝난 일이라 영상에 나올 자리가 없었습니다. 그런데 같은 걸 만들려는 사람에게는 이쪽이 먼저 걸립니다.
| 문제 | 왜 터지나 | 처리 |
|---|---|---|
| 폰 영상의 가변 프레임레이트 | VFR 을 그대로 두면 뒤의 모든 시각 계산이 조금씩 밀립니다 | 전처리 첫 단계에서 CFR 로 정규화 |
| 캠마다 다른 해상도 | 짐벌과 폰을 섞으면 크로스페이드가 그냥 죽습니다 | 전 캠을 1920×1080 공통 캔버스로 통일 |
| 기준 캠 판정 | 파일명 알파벳 순 첫 파일을 기준으로 삼았는데, 파일명은 카메라가 정합니다 | 설정에서 기준 캠을 직접 지정하고 없으면 경고 후 폴백 |
| ffmpeg 빌드 차이 | 크로스페이드 필터가 빠진 빌드에서는 렌더 도중에 죽어 원인을 찾기 어렵습니다 | 렌더 시작 전에 필터 지원 여부를 먼저 확인하고 명확한 에러로 끊음 |
네 가지 모두 알고리즘 문제가 아니라 입력이 균일하지 않아서 생기는 문제입니다. 카메라를 두 종류만 섞어도 전부 나타납니다.
조용한 골은 끝내 못 잡았습니다
동네 풋살에는 아무도 환호하지 않는 골이 있습니다. 처음엔 텐션이 높아 소리를 지르지만 시간이 지나면 다들 힘들어서 툭 밀어 넣고 그냥 이어갑니다. 소리 파이프라인은 이걸 원천적으로 못 잡습니다.
편집에서 잘린 이유영상은 「여러 가지 해봤는데 안 됐다」로 넘어갑니다. 무엇을 다섯 가지나 시도했고 각각 왜 무너졌는지, 재현율이 얼마였는지는 코드 주석에만 남아 있습니다.
| 시도 | 무엇을 봤나 | 왜 안 됐나 |
|---|---|---|
| 전체 구간 네트 모션 | 골대 영역의 프레임 변화량 | 27분 경기에서 후보 3,297개. 버그를 잡아 38개로 줄였지만 대부분 카메라 앞을 지나가는 사람이었습니다 |
| 모양·속도 특징 | 영역을 넷으로 잘라 크기와 속도 | 네트를 때리는 건 순간이고 사람은 길게 움직입니다. 그런데 실제 골도 정크와 같은 값이 나왔습니다 |
| 골대 안의 공 찾기 | 골대 영역에 공이 있는지 | 공은 잘 찾았습니다. 다만 여분의 공을 골대 뒤나 안에 두는 구장이 많았습니다 |
| 공 유무 VLM | 프레임을 모델에 보여주고 판단 | 공이 있다는 건 압니다. 골인지는 정확도가 떨어졌습니다 |
| 시퀀스 VLM | 여러 프레임을 이어서 판단 | 같은 한계. 결정적인 순간에 키퍼가 공을 가립니다 |
다섯 가지 전부 재현율 20% 이하였습니다. 이 결론은 코드에 주석으로 남겨 두고 기능을 꺼 뒀습니다. 골대 뒤에 카메라를 하나 더 달면 풀리는 문제지만 매번 장비를 하나 더 챙겨야 해서 이 프로젝트가 가려던 방향과 맞지 않았습니다.
채널의 첫 편으로 이걸 골랐습니다
무엇을 첫 편으로 낼지가 만드는 것만큼 어려웠습니다. 결과가 근사해서 고른 게 아니라, 실패한 자리를 그대로 보여줄 수 있는 주제라서 골랐습니다.
편집에서 잘린 이유영상 안에서 할 이야기가 아닙니다. 그래도 남기는 건 다음 편을 만들 때 이 기준선이 필요해서입니다.
| 항목 | 선택 | 왜 |
|---|---|---|
| 주제 | 직접 겪는 문제 | 찍어 두고 안 보는 영상은 저부터 반년치가 쌓여 있었습니다 |
| 증명 방식 | 오탐을 같이 보여주기 | 맞은 것만 보여주면 광고가 됩니다 |
| 기술 난이도 | GPU 없이 노트북에서 | 따라 해 볼 수 있어야 남는 게 생깁니다 |
| 완성도 | 미완인 채로 공개 | 조용한 골은 못 잡습니다. 그 실패가 이 편에서 제일 쓸모 있는 부분입니다 |
| 분량 | 10분 10초 | 롱폼 한 편. 기획 단계에서 잡았던 12~15분보다 짧게 냈습니다 |
첫 편이라 촬영·편집·업로드가 전부 처음이었고 매끄럽지 않았습니다. 다시 만들면 다르게 할 곳이 여럿 보이지만, 기준선이 있어야 나아진 걸 잴 수 있어서 손대지 않고 둡니다.
이런 영상 자동화를 만들 때 쓸 수 있는 방법
풋살이 아니어도 「긴 영상에서 몇 장면만 뽑기」는 같은 모양입니다. 이번에 통했던 순서와 다음에 시도해 볼 만한 것을 함께 적습니다.
편집에서 잘린 이유영상은 풋살 이야기로 끝납니다. 옮겨 쓸 수 있는 형태로 정리한 건 여기가 처음입니다.
| 단계 | 이번에 한 것 | 다른 영상에 옮기면 |
|---|---|---|
| 신호 고르기 | 환호성. 이미 파일 안에 녹음돼 있습니다 | 웃음·박수·비명, 게임 방송의 킬 사운드, 강의의 침묵 구간. 화면보다 오디오가 싸고 정확한 경우가 많습니다 |
| 임계 정하기 | 고정값 대신 롤링 평균 + 표준편차 3배 | 구장·마이크·분위기가 달라도 같은 설정으로 돕니다. 고정 dB 값은 환경이 바뀌면 무너집니다 |
| 경계 잡기 | 최댓값이 아니라 반응이 시작되는 지점 | 반응은 원인보다 늦습니다. 웃음·채팅·댓글 급증 전부 같습니다 |
| 구간 늘리기 | 직전 상태 대비 조용해질 때까지 | 전체 평균을 기준선으로 쓰면 이벤트가 기준선을 끌어올려 전부 최소 길이로 잘립니다 |
| 정밀화 | 오디오가 잡은 창 안에서만 화면 보기 | 탐색 범위를 먼저 좁히면 값싼 화면 비교로도 충분합니다. 전체를 훑게 하면 정크에 파묻힙니다 |
| 결정과 실행 분리 | 컷 결정을 plan.json 으로 떨구고 렌더러는 실행만 | 설정을 바꿔 다시 렌더할 때 분석을 다시 돌리지 않아도 됩니다. 편집 UI 도 이 파일만 읽으면 됩니다 |
| 사람이 들어갈 자리 | 브라우저 편집기에서 컷 다듬기 | 완전 자동을 목표로 두지 않는 편이 빠릅니다. 전부 돌려보지 않게 만드는 것으로 충분합니다 |
아직 안 해 본 것도 적어 둡니다. 여러 각도의 카메라를 두고 어느 쪽이 잘 보이는지 자동으로 고르기, 발화를 받아써서 장면 이름을 붙이기, 같은 파이프라인을 회의 녹화나 라이브 방송 다시보기에 붙이기. 신호만 바꾸면 구조는 그대로입니다.
파이프라인 설정값
실제로 돌린 설정 그대로입니다. 임계값 하나하나가 앞의 실패에서 나왔습니다.
편집에서 잘린 이유영상에 넣을 자리가 없는 숫자들입니다. 같은 걸 만들어 보려는 분에게는 이쪽이 더 쓸모 있습니다.
| 구간 | 값 | 무엇을 정하나 |
|---|---|---|
| 함성 탐지 창 | 0.5초 RMS | 짧을수록 순간적인 소리에 민감해집니다 |
| 함성 임계 | 표준편차 3.0배 | 이보다 낮추면 후보가 급격히 늘어납니다 |
| 후보 최소 간격 | 15초 | 같은 장면이 여러 번 잡히는 것을 막습니다 |
| 클립 길이 | 10~25초 | 빌드업 5초를 앞에 붙입니다 |
| 네트 탐색 창 | 시작점 기준 앞 2.5초 · 뒤 0.5초 | 공이 소리보다 먼저 들어가므로 앞으로 치우쳐 있습니다 |
| 네트 모션 임계 | 구간 중앙값 대비 6 MAD | 조용한 골 스캔에서는 10으로 더 조입니다 |
| 앵글 전환 | 골 후 2.5초 유지 · 3초 미만 전환은 숨김 | 너무 잦은 전환이 산만해서 넣었습니다 |
| 인코딩 | Apple VideoToolbox H.264 | libx264 대비 실측 약 2배 빠릅니다 |
골 라벨링에는 Claude Sonnet 5를, 네트 후보 검증에는 더 싼 Haiku 4.5를 씁니다. 판정 한 번에 크롭 세 장이라 검증 쪽은 저렴한 모델로 충분했습니다.
세 판을 돌리고 남은 것
분석할 축을 바꾸면 무거운 모델이 필요 없어진다
골 장면을 찾으려면 공을 추적해야 한다고 생각하기 쉽습니다. 그러려면 GPU와 학습 데이터가 필요합니다. 그런데 환호성은 이미 같은 파일에 녹음돼 있었습니다. 화면을 보지 않기로 정하고 나서야 노트북에서 도는 파이프라인이 됐습니다.
「영상 인식은 쓰지 않는다」를 시작할 때 제약으로 못 박았습니다. 나중에 비전을 붙였지만 골을 찾는 자리는 끝까지 오디오가 지켰습니다.
보조 신호는 탐지기를 대체하지 못한다
네트 흔들림은 정확한 순간을 짚지만 혼자 두면 카메라 앞을 지나가는 사람이 더 크게 잡힙니다. 오디오가 잡은 몇 초 창 안에서만 보게 하니 쓸모가 생겼습니다. 탐색 범위를 좁혀 주는 신호가 없으면 정밀한 신호는 정크에 파묻힙니다.
소리로 잡은 골 중 10건을 네트 모션이 독립적으로 똑같이 지목했습니다. 다만 반대는 성립하지 않았습니다. 비전만으로 전체 경기를 훑은 결과는 재현율 20% 이하였습니다.
AI에게 시킬 일은 고르는 게 아니라 라벨을 붙이는 것이었다
처음에는 모델에게 「여기 세리머니 있어?」를 물었고 판단이 흔들렸습니다. 골라내게 하는 대신 「이건 골일 수도 있다」를 붙이게 하고 최종 선택은 다른 신호와 종합해서 하도록 바꿨습니다.
라벨을 남겨 두면 나중에 학습 데이터로도 쓸 수 있습니다. 걸러 버린 판단은 다시 꺼낼 수 없습니다.
값이 항상 켜져 있으면 그건 신호가 아니라 배경이다
골대 안에서 공을 찾는 탐지기는 잘 작동했습니다. 그런데 풋살은 경기 흐름 때문에 골대 안에 여분의 공을 넣어 둡니다. 탐지가 잘 되는 것과 그 신호가 쓸모 있는 것은 다른 문제였습니다.
측정값이 카메라 위치를 재고 있는지 먼저 확인해야 한다
같은 경기를 두 카메라로 돌렸더니 팀별 수치가 반대로 나왔습니다. 많이 뛴 팀이 아니라 그 카메라에서 잘 보인 팀이었습니다. 숫자를 내는 대신 기능을 통째로 뺐습니다.
물리가 맞으면 방향이 맞은 것이다
네트 흔들림이 함성보다 살짝 먼저 잡혔습니다. 공이 소리보다 먼저 들어가니 당연한 순서인데, 이 순서가 맞아떨어지는 걸 보고서야 탐지가 우연이 아니라는 확신이 생겼습니다.
촬영본이 없어도 검증은 만들 수 있다
영상이 아직 없다고 파이프라인을 못 만드는 건 아니었습니다. 밀린 오프셋과 환호성 시점을 알고 있는 가짜 영상을 만들어 두고 파이프라인이 그 정답을 되찾는지 봤습니다. 첫 경기 파일을 넣기 전에 테스트가 26개 쌓였습니다.
현장에서 터졌을 문제 대부분이 이 단계에서 걸렸습니다. 가변 프레임레이트, 캠마다 다른 해상도, 기준 캠 판정, ffmpeg 빌드 차이 전부입니다.
「조용하다」를 절대값으로 정의하면 이벤트가 스스로를 지운다
세리머니가 끝날 때까지 클립을 늘리려고 트랙 전체 중앙값을 기준선으로 삼았습니다. 그런데 골 장면이 그 중앙값을 끌어올려서 거의 모든 시점이 이미 조용하다는 판정을 받았습니다. 전 클립이 최소 길이인 10초로 잘려 나왔습니다.
기준선을 골 직전 빌드업 구간으로 바꾸자 12초짜리 세리머니가 살아났습니다.
손으로 한 번 끄는 게 빠른 구간이 있다
세리머니가 잘리는 문제를 모델로 풀려다 실패하고 결국 브라우저 편집기에서 손으로 다듬는 쪽으로 해결했습니다. 골대 박스를 그리고 파형을 보며 컷을 조정하고 앵글을 바꾸는 화면입니다.
사람을 빼려고 자동화한 게 아니라 한 시간 반을 다 돌려보지 않으려고 자동화했습니다.
이 실험이 말할 수 없는 것
- 조용한 골은 여전히 못 잡습니다. 아무도 환호하지 않는 골은 소리 파이프라인이 원천적으로 놓치고 시각 신호로 대체하려던 다섯 가지 시도는 모두 재현율 20% 이하였습니다.
- 네트 영역 감지는 카메라가 고정돼 있어야만 돕니다. 골대 위치가 화면에서 움직이면 성립하지 않습니다. 다만 이 기능을 꺼도 오디오만으로 하이라이트는 나옵니다.
- 코트 옆 코너에서 찍으므로 먼 쪽이 잘 보이지 않습니다. 경기 분석을 뺀 것도 이 때문입니다.
- 임계값은 이 구장과 이 팀에서 맞춘 값입니다. 함성이 작은 팀이나 실내 반향이 큰 구장에서는 다시 잡아야 합니다.
- 완전 자동은 아닙니다. 결과물은 아직 손으로 조금 다듬어야 하고 편집기도 그래서 만들었습니다.
먼저 나올 질문들
왜 골만 찾지 않고 하이라이트라고 부르나요?
골 모음이 아니라 하이라이트를 만들고 싶었기 때문입니다. 멋진 선방이나 아깝게 빗나간 슛, 좋은 수비도 함성을 부릅니다. 소리로 후보를 잡으면 그런 장면이 함께 들어옵니다. 골 라벨링은 클립을 지우는 데 쓰지 않고 어느 클립이 골인지 표시하는 데만 씁니다.
두 카메라의 시간은 어떻게 맞췄나요?
따로 맞추지 않았습니다. 두 영상의 오디오를 비교해 어긋난 만큼을 자동으로 계산합니다. 같은 함성이 두 마이크에 다른 시각으로 찍히므로 그 차이가 곧 시간차입니다. 슬레이트를 치거나 타임코드를 맞출 필요가 없었습니다.
조용한 골은 앞으로도 못 잡나요?
지금 장비로는 어렵습니다. 골대 뒤에 카메라를 하나 더 달면 풀리는 문제인데 매번 장비를 하나 더 챙겨야 해서 이 프로젝트가 가려던 방향과 맞지 않았습니다. 코드에는 기능이 남아 있고 꺼 둔 상태라 골대 뒤 캠이 생기면 다시 켤 수 있습니다.
코드를 얼마나 직접 썼나요?
거의 들여다보지 않고 만들었습니다. AI 코딩에서 중요하다고 하는 것도 계속 바뀌어 왔습니다. 처음엔 프롬프트가 전부인 줄 알았고 그다음은 컨텍스트, 도구와 검증, 하네스 엔지니어링이었습니다. 모델이 좋아질수록 약점을 메우려고 만들어 둔 장치부터 하나씩 덜 중요해졌습니다. 지금은 어떻게 짤지보다 무엇이 문제이고 어떤 판단을 해야 하는지가 더 크게 남습니다.
코드를 볼 수 있나요?
공개했습니다. anyAXgit/autoPitch 저장소에 MIT 라이선스로 올려 뒀습니다. 가져다 고쳐 쓰셔도 되고, 자기 구장 지오메트리에 맞춰 임계값부터 다시 잡으셔야 할 겁니다. 저처럼 찍어는 두고 편집할 엄두가 나지 않던 분들에게 닿으면 좋겠습니다.
Insights
이 회차에서 나온 인사이트
값싼 신호로 범위를 먼저 좁힐 것
정밀한 탐지기는 그 안에서만 쓸모가 있다
풋살 하이라이트에서 골을 찾는 건 함성 소리 하나다. 정밀한 화면 신호를 붙여 봤지만 혼자서는 재현율 20%를 넘지 못했고, 오디오가 좁혀 준 몇 초 안에서만 쓸모가 생겼다.