Executive Function 시리즈에서는 AI로 혁신을 이끄는 리더들의 관점을 소개합니다.
JioStar는 5억 명 이상이 이용하는 엔터테인먼트 및 스포츠 생중계 플랫폼을 운영하며, 스포츠 생중계 동시 시청자 수가 최대 7,250만 명에 달하기도 했습니다. 이 정도 규모라면 AI는 빠르고 신뢰할 수 있어야 하며, 실제 서비스에 투입할 준비가 되어 있어야 합니다.
JioStar는 OpenAI API를 활용해 대화로 동영상과 크리켓 통계를 찾는 어시스턴트를 JioHotstar에 구축했습니다. 시청자는 자연스럽게 말하면서 영화와 프로그램, 과거 하이라이트, 생중계 경기 장면, 크리켓 통계를 찾을 수 있으며, 대화를 이어 가면서 결과를 시각적으로 확인할 수 있습니다.
싱가포르에서 열린 OpenAI Executive Summit에서 OpenAI의 아세안 지역 고투마켓 총괄 시다르트 샤르마가 JioStar의 수석 아키텍트 비제이 세샤드리와 대화를 나눴습니다. 약 8주 만에 15개 이상의 언어를 지원하는 서비스를 구축한 과정과 AI를 데모에서 실제 서비스로 발전시키는 리더들이 얻을 수 있는 교훈을 살펴봤습니다.
지난 25년간 콘텐츠 탐색 방식은 거의 달라지지 않았습니다. 마지막으로 일어난 큰 변화는 추천 기능이었습니다. 그 이후의 변화는 대부분 같은 아이디어를 조금씩 개선하는 수준이었죠.
하지만 무엇을 볼지 고르는 일에는 개인의 취향과 상황이 깊이 반영됩니다. 누군가는 이렇게 말할 수 있습니다. “기분이 울적해. 기분이 좋아질 만한 걸 보여 줘.” 이렇게 간단한 요청에도 여러 미묘한 의미가 담겨 있습니다. 어떤 울적함일까요? 평소에는 무엇을 보면 기분이 좋아지는 사람일까요? 코미디를 원하는 걸까요, 편안하게 볼 수 있는 작품을 원하는 걸까요, 아니면 다른 생각을 완전히 잊게 해 줄 무언가를 원하는 걸까요?
기존 추천 시스템은 그 순간의 상황을 이해하기 어려울 수 있습니다. 대화를 통해 시청자가 직접 설명할 수 있게 되는 거죠. 저희는 이를 음성·시각 인터페이스라고 부릅니다.
2월에 주요 크리켓 대회를 앞두고 10월과 11월에 콘셉트를 구체화하기 시작했습니다. 주어진 시간은 약 두 달이었고, 엔터테인먼트 시청자와 크리켓 팬이라는 매우 다른 두 이용자층을 고려해야 했습니다.
엔터테인먼트 시청자는 “금요일 저녁인데, 색다른 걸 추천해 줘”라고 말하거나 제목을 모르는 영화를 설명할 수 있습니다. 스포츠 시청자는 위켓이 나온 상황이나 연속 식스 장면, 특정 선수가 일정 득점을 올린 경기처럼 더 구체적인 정보를 원할 수 있습니다. 크리켓 전문가라면 공 하나하나에 대한 통계를 원할 수도 있죠.
콘텐츠 탐색이라는 측면에서 이들은 서로 매우 다른 과제입니다. 저희는 매우 짧은 시간 안에 엔터테인먼트와 스포츠 장면, 상세한 크리켓 통계를 여러 언어로 이용할 수 있는 하나의 서비스로 통합하고자 했습니다.
아주 초기부터 정확도, 지연 시간, 비용이라는 세 가지 요소 사이에서 균형을 찾는 문제로 접근했습니다. 모든 엔지니어링 의사결정에서 세 요소를 동시에 고려해야 했습니다.
음성 인터페이스에서는 이것이 특히 중요했습니다. 사용자의 60% 이상이 텍스트 대신 음성을 사용합니다. 보고 싶은 것을 말로 전달하는 편을 선호하는 거죠. 그러면서도 응답은 요청에 부합하고 빨라야 하며, 대규모로 운영할 때도 경제성이 있어야 합니다.
저는 평가 프레임워크와 검증 계층, 두 부분으로 나누어 생각합니다. 실제 서비스에 도입하기 전에는 평가 프레임워크를 통해 필요한 개선을 이끌어 내야 합니다. 운영 중에는 피드백 루프를 통해 고객 행동과 실패 사례를 새로운 평가 사례로 만들어야 합니다.
이런 선순환은 스스로 강화될 수 있지만, 제대로 작동하게 만들기는 매우 어렵습니다.
해당 분야의 전문가가 반드시 필요합니다. 스포츠 통계 평가에서는 열성 팬들이 어떤 질문을 할지 잘 아는 스포츠 잡지 편집자 등의 전문가들과 협업했습니다. 프롬프트 하나만으로 시작할 수는 없습니다. 사람의 깊이 있는 전문 지식을 시스템의 토대로 삼아야 합니다.
저희가 잘한 것 중 하나는 팀 구성이었습니다. 명확하게 정의한 문제를 중심으로 데이터 과학자와 엔지니어로 구성된 소규모 팀을 꾸려 시작했습니다. OpenAI의 현장 투입 엔지니어들이 저희와 함께 일하면서 반드시 제대로 해내야 할 몇 가지 핵심 과제를 더 구체적으로 파악했습니다.
첫 번째는 범위였습니다. 음성이나 텍스트 인터페이스에서는 사용자가 거의 무엇이든 물어볼 수 있으므로, 시스템이 답하지 말아야 할 내용을 정하는 것부터 시작했습니다. 가드레일이 최우선이었습니다.
평가를 위해서는 초기 데이터셋을 마련한 뒤 모델을 활용해 더 다양한 사례로 확장했습니다. 지금이라면 생성자-검증자 패턴이라고 부를 만한 구조를 만들었습니다. 한 모델은 질문에 어떻게 답할지 결정하도록 돕고, 다른 모델은 그와 상충하는 목표를 가진 검증자, 즉 LLM 심사자 역할을 맡았습니다.
그러자 또 다른 질문이 생겼습니다. 심사자는 누가 테스트할까요? 검증자를 설계하는 일 자체가 평가 과제였습니다. Codex 덕분에 평가 사례 생성이나 시스템 업데이트 같은 작업을 더 빠르게 진행할 수 있었지만, 개발 속도가 빨라져도 판단과 검증의 필요성이 사라지지는 않았습니다.
실제 운영 환경에서 모델의 효과성을 모니터링하는 데 더 일찍 투자하겠습니다.
P99 지연 시간 같은 기존 인프라 지표도 여전히 중요하지만, 그것만으로는 충분하지 않습니다. 실제 운영 환경에서 모델이 얼마나 효과적으로 작동하는지도 모니터링해야 합니다.
첫째, 기술로 가능한 일과 기업 내부의 현실 사이에는 큰 간극이 있습니다. 프런티어 모델이 발표될 때마다 그에 발맞춰 대응하지 못했다고 해도, 여러분의 회사만 그런 것은 아닙니다.
둘째, 활동 자체보다는 성과에 계속 집중해야 합니다. 특히 기업이 투입 지표를 강조할 때는 눈에 보이는 움직임을 의미 있는 진전으로 착각하기 쉽습니다. 예를 들어, 생성된 코드 줄 수만으로는 의미 있는 가치를 창출했는지 알 수 없습니다.
마지막으로, 대부분의 기업은 사람에게 필요한 역량과 주도성을 과소평가합니다. 일반적인 역량 교육 프로그램만으로는 충분하지 않습니다. 리더에게는 판단력을 바탕으로 이러한 도구를 활용할 수 있는 인재가 필요합니다. 뛰어난 엔지니어에게 Codex 같은 도구를 주면 그 효과는 몇 배로 커질 수 있습니다. 하지만 실제 운영 시스템을 검증할 판단력이 없다면 위험도 그만큼 커집니다.
여러분은 로켓을 손에 쥐고 있는 셈입니다. 특히 실제 운영 시스템에서는 검증과 가드레일이 필요하며, 적임자에게 조종을 맡겨야 합니다.
