같이보기에 늦게 온 시청자, AI가 '지금 무슨 상황이에요?'에 대신 답한다

한줄 요약: 같이보기에 늦게 들어온 시청자는 맥락을 잃고 나가고, 이미 본 시청자의 채팅은 스포일러가 됩니다. 늦게 온 사람에게 지금 방송 시점까지 요약해 주고, 아직 방송되지 않은 장면을 말하는 채팅은 올라오는 순간 블러로 덮는 AI 매니저의 AI 부분을 해커톤 하루 동안 만들었습니다.

목차

1. 같이 보면 재미가 배가된다, 하지만 같은 시간에 보기는 어렵다
2. 같이보기 방송의 두 가지 문제
3. 채팅을 쓴 시각이 아니라 채팅이 말하는 장면으로
4. 하루를 기획 70, 발표 20, 개발 10으로
5. 수상작을 보고 알게 된 것
6. 시청회에서 써 본 결과

1. 같이 보면 재미가 배가된다, 하지만 같은 시간에 보기는 어렵다

올여름 「스파이더맨: 브랜드 뉴 데이」 개봉 때를 기억하시나요? 월드 프리미어 직후 쿠키 영상이 온라인에 퍼졌습니다.

같이 보면 재미가 배가됩니다. 축구 경기나 드라마처럼 지금 봐야 하는 것은 같이 볼 때 가장 재미있습니다. 하지만 누구나 같은 시간에 시청하기는 어렵습니다. 늦게 오면 스포일러를 보게 되고, 앞의 맥락도 놓칩니다.

10월 16일 밤 10시에는 친구들과 시청회가 있습니다. 친구들이 서바이벌 예능 「더 커뮤니티2」를 보자고 해서 즉석으로 꾸렸습니다. 각자 집에서 팝콘과 맥주를 들고 동시에 재생하고, 단톡방에서 반응합니다. 그런데 아이를 키우는 친구 한 명은 아이를 재우고 들어와야 해서 10분쯤 늦습니다.

2. 같이보기 방송의 두 가지 문제

해커톤 날 아침, 그 친구에게 최근 일을 물었습니다. 늦게 들어가면 보통 그냥 나간다고 했습니다. 처음 보는 작품이면 더 그렇다고 했습니다.

같이보기는 이미 큰 판입니다. 침착맨과 티빙의 같이보기는 9시간 51분 이어졌습니다(2025년 10월, 티빙 발표). SOOP 같이보기는 2025년 3월 기준 3개월 누적 시청자 1,000만 명, 치지직은 2025 롤드컵 때 전용 중계 채널과 스트리머 같이보기를 합쳐 최고 동시접속 76만 명을 기록했습니다.

같은 문제는 크리에이터의 같이보기 방송에서 더 크게 생깁니다. 크리에이터는 매일 무엇을 방송할지 고르는 일부터 고민입니다. 풍월량 님은 2017년 트위치 시절 인벤 인터뷰에서 게임을 찾는 데 시간과 고민을 많이 쓴다고 말했습니다. 이미 있는 작품을 함께 보는 같이보기에는 두 가지 문제가 있습니다.

1. 늦게 온 시청자는 앞의 맥락을 모릅니다. 해외 영화 같이보기에서도 새로 들어온 사람이 “What did I miss?“를 묻고 진행자가 줄거리를 다시 요약하는 일이 반복됐다는 시청자 관찰담이 있습니다.
2. 이미 본 시청자가 스포일러를 흘립니다. 본 사람과 안 본 사람이 한 채팅방에 있습니다. SOOP의 한 같이보기 방송은 제목에 「스포금지」를 붙여 공지했습니다.

치지직과 SOOP에는 지나간 장면을 되돌려 보는 기능이 있습니다. 그런데 되감으면 그만큼 다른 사람들보다 뒤처집니다. 채팅이나 지금 생방송을 요약해 주는 기능은 있지만, 지금 방송된 장면까지 영상 내용을 요약해 주는 것은 아직 보지 못했습니다. 늦게 온 사람이 원하는 것은 처음부터 다시 보는 것이 아니라, 지금 바로 같이 웃는 것입니다.

3. 채팅을 쓴 시각이 아니라 채팅이 말하는 장면으로

그래서 만든 것이 「Watch Party Host」, 같이보기 방송의 AI 매니저입니다.

모두 TV처럼 방장이 트는 같은 장면을 봅니다. 늦게 들어와도 바로 지금 장면에 붙습니다. 그 위에서 AI가 두 가지를 합니다.

1. 따라잡기. “Catch me up”을 누르면 지금 방송된 데까지만 요약해 줍니다. 근거가 된 장면 시각도 함께 보여 줍니다. 궁금한 것을 직접 물어볼 수도 있고, 답은 아직 안 나온 내용을 말하지 않습니다.
2. 스포일러 블러. 이미 본 사람이 아직 방송되지 않은 장면을 말하면, 채팅이 올라오는 순간 AI가 그 장면을 찾아 블러로 덮습니다. 보고 싶은 사람만 눌러서 봅니다. 그 장면이 방송되면 블러가 풀립니다.

핵심은 채팅을 다루는 기준입니다. 채팅은 보통 쓴 시각으로만 다룹니다. 저희는 채팅을 쓴 시각이 아니라, 그 채팅이 말하는 장면을 보고 스포일러를 가립니다. AI가 영상을 미리 한 번 보고 장면 기록을 만들어 두기 때문에, 채팅이 어느 장면 이야기인지 판정할 수 있습니다.

영상 자체는 다루지 않습니다. 각자 정당한 구독이나 접근 권한으로 원래 플랫폼에서 봅니다. 저희가 나누는 것은 영상이 아니라 “방장이 어느 영상의 몇 분을 틀고 있는가”입니다. 해커톤에서는 유튜브 공식 임베드(유튜브가 허용하는 퍼가기 플레이어)로 시연했습니다.

생방송처럼 느껴지도록 속도도 챙겼습니다. 장면 경계마다 자주 나올 질문의 답을 미리 만들어 두어, 저장된 요약은 0.2초 만에 나옵니다. 처음 묻는 질문은 7~10초쯤 걸립니다. 스포일러 판정은 저장된 결과가 있으면 0.3초, 새 채팅은 1.3~2.0초입니다.

시청자가 늘어도 장면 기록 비용은 늘지 않습니다. 영상 한 편은 한 번만 처리하고, 그 기록을 모든 방이 같이 씁니다. 비용이 커지는 곳은 채팅 판정이고, 다음 단계에서 핵심어 색인으로 줄일 계획입니다.

4. 하루를 기획 70, 발표 20, 개발 10으로

해커톤은 하루짜리입니다. 심사는 발표자료가 아니라 작동하는 데모로 한다고 안내받았습니다.

그래서 시간을 기획 70, 발표 20, 개발 10으로 나눴습니다. 코드를 오래 붙잡는 것보다 문제를 정확히 잡는 쪽이 결과를 더 많이 바꾼다고 봤습니다.

AI는 셋을 나눠 썼습니다.

1. 조사는 GPT와 제미나이에게. 같이보기 서비스 현황, 크리에이터 인터뷰, 스포일러 조사를 맡기고 출처를 붙여 받았습니다. 출처가 없는 주장은 발표에서 뺐습니다.
2. 코드는 클로드 코드로. 서버와 화면을 만들었습니다.
3. 제품 안의 AI는 제미나이로. 영상을 보고 장면 기록을 만드는 일은 Gemini 4 Argon, 질문 답변과 스포일러 판정은 그보다 가벼운 Flash 계열이 맡았습니다. 작은 모델과 Argon의 판단이 엇갈리면 Argon이 영상을 다시 보고 기록을 유지할지 고칠지 다시 판정합니다.

실시간 재생 맞추기와 채팅 화면은 행사 전(10월 14~15일)에 만들어 둔 개인 프로토타입에서 가져왔습니다. 행사 중에 만든 것은 제미나이를 쓰는 AI 부분, 서버, AI 패널입니다. GitHub 설명 문서에도 같은 내용을 밝혀 두었습니다.

현장에서 막힌 곳

하루짜리 행사라 실수도 하루 안에 다 나왔습니다.

1. Argon에게 코드를 맡기지 못했습니다. 구글의 코딩 에이전트를 터미널에서 쓰는 도구(Antigravity CLI)를 행사 계정과 프로젝트로 로그인하지 않아, 모델 목록에 Argon이 없고 Flash만 보였습니다. 사람이 지켜보지 않는 자동 실행에서 파일 쓰기 승인 단계도 풀지 않아 파일을 쓰지 못했습니다. 결국 코드는 클로드 코드로 썼습니다.
2. 선불 API 키와 프로젝트 결제를 섞어 써서 혼동이 생겼습니다. 조사와 백업 서버에 쓴 AI Studio 선불 키 두 개가 13시와 14시에 차례로 바닥났습니다(402 오류). 그 순간에는 제출용 앱까지 멈춘 줄 알았는데, 배포한 앱은 행사 GCP 프로젝트의 Vertex AI(프로젝트 결제)로 부르고 있어 영향이 없었습니다. 어느 호출이 어느 결제 경로를 타는지 처음부터 하나로 고정했어야 했습니다.
3. 스포일러 설계를 현장에서 바꿨습니다. 처음에는 아직 안 본 장면 이야기를 미리 잠가 두는 설계였습니다. 그런데 생방송에서는 채팅이 방송 시각에 맞춰 올라오니, 미래의 채팅을 미리 잠근다는 말이 성립하지 않았습니다. 그래서 올라오는 순간 판정해 블러로 덮는 방식으로 바꿨습니다.

구글 해커톤에서 Gemini를 Gemini답게 못 썼다

심사 기준은 Argon의 강점을 다섯 가지로 짚었습니다. 돌아보면 저희는 그 강점을 대부분 작게만 썼습니다.

Argon의 강점	이번에 한 것	다시 한다면
100만 토큰 컨텍스트	영상을 5분씩 잘라 넣음	1화 전체(약 61만 토큰)를 한 번에 넣어 복선까지 판단
긴 출력	장면 기록 약 1.7만 토큰	회차 전체의 초 단위 타임라인과 스포일러 핵심어 색인을 한 번에
최첨단 추론	채팅이 몇 분 장면 이야기인지만 판정	스포일러의 강도, 누가 아직 모르는 정보인지까지 판단
여러 모델 지휘	Flash, Flash-Lite와 일을 나눈 정도	Argon이 진행자가 되어 실시간 음성과 요약 그림까지 지휘
검증 루프와 에이전트	엇갈린 기록을 최대 2건 다시 판정	통과할 때까지 스스로 다시 보는 에이전트 루프

원인은 세 가지였습니다.

1. 하루를 기획 70, 개발 10으로 나눠 개발 시간이 짧았습니다.
2. 제미나이 코딩 도구를 행사 계정과 프로젝트로 로그인하지 않아 Argon이 모델 목록에 없었고, 파일 쓰기 승인 단계도 풀지 않았습니다.
3. 가장 큰 원인은 순서였습니다. 제품을 먼저 정하고 Argon을 나중에 끼워 넣었습니다.

남은 교훈은 하나입니다. 모델 설계가 더 중요합니다. 어떤 에이전트에게 어떤 역할을 줄지, 그 기능과 한계를 먼저 조사하고 들어가야 합니다.

결과물 평가

제출하고 나서 두 AI에게 대회 심사 기준 다섯 가지로 점수를 매겨 달라고 했습니다. 클로드는 이 프로젝트를 함께 만든 쪽이고, GPT에게는 처음 보는 심사위원 역할로 따로 읽게 했습니다.

심사 기준	클로드	GPT
작동하는 데모	4	3
Argon과 검증 루프 활용	3	3
문제와 영향	4	3
독창성	4	4
설명의 명확성	4	4
합계	19/25	17/25

결론은 한 줄입니다. 기획과 데모는 강했고, 기술은 얕았습니다. 가장 아팠던 예상 질문은 “Flash만으로도 되지 않나?“였습니다. Flash는 Argon보다 가볍고 싼 모델입니다.

자막과 Flash로도 되는데, 왜 Argon입니까? (GPT 독립 심사의 첫 번째 질문)

화면 속 글자처럼 자막에 없는 정보를 기록하려고 Argon을 썼지만, 자막보다 낫다는 것을 숫자로 보여 주지는 못했습니다. GPT가 가장 좋은 차별점으로 꼽은 것은 채팅이 말하는 장면으로 스포일러를 가리는 접근이었습니다.

다음에 바꿀 것

1. 기능별로 쓸 모델부터 정하고 들어가겠습니다. 기획에 하루의 70%를 썼는데도 생각보다 덜 된 채로 들어갔습니다. 비어 있던 것은 기능마다 어떤 모델을 쓸지 정해 둔 작업 틀이었습니다. 평소 클로드 코드 위주로 일하던 틀에 맞춰 권한을 주다 보니, Argon을 더 많은 곳에 쓰지 못했습니다. 반대로 영상 정리에는 Argon을 통째로 썼습니다. 돌아보면 영상 정리는 대부분 Flash로 충분했고, Argon은 Flash가 틀렸을 때 다시 보는 판정에 몰아 썼어야 했습니다.

2. 이름은 미리 지어 두겠습니다. 제품 이름을 미리 정해야 한다는 생각을 아예 못 했습니다 ㅋㅋ

다음 버전에서 개선할 것

1. Argon의 효과를 숫자로 잽니다. 화면 정보를 묻는 시험 질문을 사람이 직접 만들고, 자막만 쓸 때와 Argon 장면 기록을 쓸 때를 비교합니다.
2. 장면 기록은 Flash가 쓰고, Argon은 심판만 봅니다. Flash가 헷갈리는 장면만 Argon이 다시 봅니다.
3. 검증 루프를 통과할 때까지 돌립니다. 지금은 몇 장면을 뽑아 다시 보는 수준입니다. 통과할 때까지 반복하고, 사람이 만든 정답과 대조합니다.
4. 스포일러 판정을 밀리초 단위로 줄입니다. 장면 기록으로 핵심어 색인을 만들어 모델 호출 전에 거릅니다.
5. 실제 시청회 채팅으로 잽니다. 미리 써 둔 대본 채팅이 아니라, 10월 16일 밤 친구들 시청회의 채팅부터 모읍니다.
6. 크리에이터 방송에 붙이는 방법을 찾습니다. 같이보기 방송 화면 옆에서 매니저처럼 돌아가는 형태를 알아봅니다.

이렇게 하루를 나눠 쓴 방식은 스킬 run-hackathon으로 정리했습니다. 규정과 마감 읽기부터 기획, 개발, 검증, 영상 녹화, 발표, 제출까지 단계마다 어느 세션이 맡고 무엇으로 끝났다고 볼지를 적었습니다. 사내 해커톤이나 데모데이를 준비한다면 스킬 가이드북의 run-hackathon 장에서 흐름을 먼저 보실 수 있습니다.

5. 수상작을 보고 알게 된 것

결과부터 말하면 Watch Party Host는 수상하지 못했습니다. 16시 30분 수상작 발표를 보고 그날 저녁에 녹음해 둔 생각을 여기에 옮깁니다.

2위부터 4위까지는 모두 실시간 처리나 여러 채널을 한꺼번에 다루는 기능으로, 1분 안에 “와” 하는 장면을 보여 주는 제품이었습니다. 2위 팀은 기획도 잘 되어 있었습니다. 기획과 명확한 소프트웨어가 함께 갈 수 있다는 사례였습니다. 한 팀은 소상공인 데이터로 “어디에 카페를 낼까”를 정하는 3D 모델링 도구를 만들었습니다. 시나리오 1,000개를 그리고, 구조물을 옮기면 동선과 비용이 달라졌습니다. 만드는 AI와 검증하는 AI를 나누고, 계산 엔진은 결정론적으로 두었습니다.

깨달은 것은 네 가지입니다.

1. 해커톤 심사는 구현 가능성을 봅니다. 숫자의 엄밀성이나 사업 기획보다 “기술적으로 된다”를 보여 주는 진짜 프로토타입에 관심이 있었습니다. 사업성을 보는 자리가 아니었습니다.
2. 기획을 너무 본격적으로 했습니다. 기획이 겨눈 과녁(문제 정의, 시장 근거, 출처 있는 수치)이 심사 방식(실제 입력으로 3분 안에 도는 데모)과 달랐습니다. 명확한 소프트웨어 하나를 만드는 쪽이 나았을 수 있습니다.
3. 우리 제품은 상황을 이해해야 가치가 보였습니다. “늦게 들어온 사람”이라는 맥락을 먼저 설명해야 했고, 데모도 대본 채팅이라 놀라움이 약했습니다. 수상작은 1분 안에 장면이 바로 보였습니다.
4. 모델 설계가 먼저입니다. 4절의 결론과 같은 방향입니다. 모델의 강점(실시간, 멀티모달, 긴 컨텍스트)에서 출발해 1분짜리 장면을 고르고, 그다음 문제를 붙이는 순서가 맞았습니다.

다음 해커톤에는 이렇게 들어가겠습니다.

• 기획의 첫 산출물을 “1분 안에 보여 줄 한 장면”으로 정합니다.
• 대회 모델의 강점 목록을 먼저 만들고, 그 강점이 화면에서 바로 보이는 기능부터 고릅니다.
• AI가 판단하는 부분과 결정론적으로 계산하는 부분을 나눠 설계합니다.
• 사업성, 시장 수치, 출처 정리는 발표 한 장으로 줄이고 구현에 시간을 더 줍니다.

6. 시청회에서 써 본 결과

10월 16일 밤 10시, 친구들 시청회에서 처음으로 실제 사람들과 써 봤습니다. 행사 계정이 사라진 뒤라 집에 둔 백업 서버로 돌렸고, 백업 서버는 Gemini 키의 크레딧이 바닥나 글 생성을 다른 모델(Claude)로 바꿔 두었습니다. 대본 채팅에서는 안 보이던 문제가 첫날부터 나왔습니다.

1. 스포일러 판정이 실제 채팅에서 오탐을 냈습니다. 아직 안 나온 장면 이야기가 아닌데도 가려지는 채팅이 있어, 그 자리에서 판정 기준을 느슨하게 조정했습니다.
2. 늦게 들어오거나 새로고침하면 이전 채팅이 보이지 않았습니다. 늦게 온 사람을 위한 앱인데 늦게 온 사람이 빈 채팅창을 봤습니다. 바로 고쳤습니다.
3. 25초마다 연결이 끊겼습니다. 접속자 상태를 5초마다 보내다 실시간 서버의 전송 한도에 걸린 것이었고, 전송 간격을 늘려 해결했습니다.

실제 채팅으로 재겠다던 일은 이렇게 수정 목록부터 만들었습니다.