Pegasus 1.5를 만든 사람들

제품이 세상에 나올 때, 가장 먼저 보이는 것은 보통 기능과 성능입니다.
하지만 실제 출시를 만드는 것은 그 뒤에 있는 사람들의 판단과 노력, 그리고 협업하는 과정입니다.

Pegasus 1.5 역시 그랬습니다.

이번 릴리즈는 리서치, 머신러닝 엔지니어링(MLE), 백엔드, 데이터, 테스트 인프라까지 여러 역할이 하나의 목표 아래 더 촘촘하게 연결되며 진행됐습니다. 누군가는 학습과 데이터 품질을 맡았고, 누군가는 evaluation과 serving 구조를 처음부터 다시 설계했습니다. 누군가는 User-facing API와 SDK를 만들었고, 또 누군가는 촉박한 일정 안에서 테스트 자동화 작업으로 릴리즈 품질을 향상시켰습니다.

무엇보다 Pegasus 1.5 팀에게는 이번 릴리즈가 단순한 업그레이드가 아니라 “다시 바닥부터 쌓아 올린다”는 감각에 더 가까웠습니다. 학습 코드, 서빙 구조, 평가 방식까지 다시 정리하며 다음 단계를 위한 기반을 만드는 과정이었죠.

더 선명해진 목표, 더 중요해진 데이터

이번 Pegasus 1.5 릴리즈 중 크게 달라졌던 점 중 하나는 모델 개발의 목표가 훨씬 명확해졌다는 것이었습니다.

단순히 모델을 개선하는 것이 아니라, “어떤 문제를 더 잘 풀 것인가”를 먼저 정의하고, 그에 맞춰 데이터와 학습이 설계되었습니다.

이 변화는 데이터 팀에도 영향을 미쳤습니다. 예전에는 데이터를 수집하고 전달하는 역할이 중심이었다면, 이번에는 그 데이터가 실제로 학습에 어떻게 쓰이고 어떤 병목을 만드는지 더 가까이서 볼 수 있었습니다. 이전까지의 협업이 '코끼리 발 더듬듯이' 부분적으로만 보였다면, 이번에는 전체가 연결된 형태로 보이기 시작한 것입니다.

역할은 더 넓어졌고, 일하는 방식도 바뀌었다

이번 Pegasus 1.5에서는 각자의 역할이 자연스럽게 확장되었습니다.

TwelveLabs의 엔지니어링 + 리서치 팀은 Pod 구조로 조직되어 있습니다. 이 구조 안에서는 기능별 역할에 머무르지 않고, 제품 목표를 중심으로 필요한 문제를 더 넓게 맡게 됩니다. Pod는 특정 목표나 제품 영역을 중심으로 구성된 소규모 협업 팀입니다. 예를 들면, 엔지니어 + PM + 디자이너 + QA가 한 팀으로 묶여 하나의 기능이나 도메인을 자율적으로 담당하는 구조입니다.

실제로 머신러닝 엔지니어가 training task를 end-to-end로 경험하고, 데이터 엔지니어가 학습 직전 단계의 최적화까지 맡고, 백엔드 엔지니어가 API 스펙부터 서비스 연동, SDK까지 함께 보는 일이 자연스럽게 일어났습니다.

이 변화는 단순히 업무량의 증가가 아니라, 개인이 더 많은 맥락을 이해한 상태에서 의사결정과 실행의 속도가 빨라졌다는 변화에 가까웠습니다.

촉박했지만, 그만큼 밀도 있었던 과정
(그리고 그 안에 있었던, 조금은 현실적인 순간들)

이번 릴리즈는 여러 팀원이 공통적으로 “타이트했다”고 표현할 만큼 일정이 촉박했습니다. 실제로 밤을 새워 학습 문제를 해결하거나, 릴리즈 직전에 몇 시간만 자고 다시 작업을 이어가는 상황도 있었죠.

하지만 동시에, 그 압축된 과정이 빠른 학습과 성장으로 이어졌다는 이야기도 많았습니다. 처음 일정을 들었을 때 "불가능하다"고 생각했던 Kevin은 evaluation platform을 처음부터 끝까지 구축하며 LLM 모델 사이클 전체를 손으로 경험했습니다.

사용자 경험까지 연결된 설계

이번 릴리즈에서는 모델의 기술적인 개선뿐 아니라,
사용자가 실제로 어떻게 이 기능을 쓰게 될지에 대한 고민도 깊어졌습니다.

특히 API 설계에서는 단순한 기능 제공을 넘어,
더 직관적인 사용 경험을 만들기 위해 여러 차례 방향이 바뀌며 많은 논의가 이어졌습니다.

예전에는 영상을 분석하려면 indexing을 먼저 거쳐야 했지만, 이번에는 그 과정 없이 URL만 있어도 바로 돌릴 수 있도록 구조가 바뀌었습니다. 사용자 입장에서는 눈에 띄지 않을 수 있지만, 그 설계 하나에 꽤 많은 고민이 들어갔습니다.

QA 측면에서도 변화는 분명했습니다. 단순히 기능이 동작하는지를 확인하는 것을 넘어, “이 정도면 실제 사용자에게 충분히 좋은 경험인가”를 기준으로 품질을 판단했습니다.

서울에서 함께 일한다는 것

이번 Pegasus 1.5를 돌아보며 많은 팀원이 공통적으로 이야기한 것은 서울 오피스에서 함께 일한 경험이었습니다.

핵심은 단순히 같은 공간에 있었다는 사실보다, 논의와 의사결정 사이의 거리가 짧아졌다는 점에 있었습니다. 

슬랙 메시지를 길게 정리해 태평양 건너편의 팀의 답을 다음날까지 기다리는 대신, 필요한 순간 바로 화상 회의를 열고 함께 논의하고 수정할 수 있었습니다. Pod 안에서 결정권이 모여 있었기 때문에 가능한 속도였습니다.

이 변화는 단순한 커뮤니케이션 방식의 차이를 넘어, 일하는 구조 자체와 연결되어 있었습니다.

서로 다른 팀 사이의 협업이 아니라, 실제로 함께 결정해야 하는 사람들이 한 단위 안에서 움직이게 되면서 “진짜 팀처럼 일했다”는 감각이 생겼기 때문입니다. 빠른 의사결정이 가능해졌고, context를 주고받는 기회비용도 줄어들었습니다.

QA를 담당한 Luke는 이 모든 변화를 가장 단순한 문장으로 요약했습니다.

완성보다, 다음을 위한 기반

흥미로운 점은, 이번 릴리즈를 이야기한 많은 팀원이 Pegasus 1.5를 “완성된 결과”보다
“다음 단계를 위한 기반”에 더 가깝게 설명했다는 점입니다.

이번 과정에서 evaluation platform이 zero-to-one으로 구축됐고, 데이터와 학습 파이프라인이 더 긴밀하게 연결됐고, 앞으로 모델을 더 빠르게 개선하기 위한 마일스톤도 조금씩 더 선명해졌습니다. 

그러면서도 이번 모델에 대한 솔직한 기대감도 있었습니다. ML Research Scientist Lia는 타사 VLM과 블라인드로 비교한 평가 결과를 아직도 완전히 믿지 못한다고 했습니다.

만든 사람이 오히려 가장 의심했다는 점. 그리고 그 의심에도 불구하고 결과가 나왔다는 점. 아직 보완할 부분은 분명히 있지만, 다음에는 더 빠르게 앞으로 나아갈 수 있다는 확신만큼은 팀 안에서 분명해졌습니다.

마무리

Pegasus 1.5는 기능과 성능만으로 설명되는 릴리즈가 아니었습니다.

각자 다른 역할을 가진 사람들이 더 가까이 연결되고, 더 넓은 책임을 가지고, 더 빠르게 결정하고 실행했던 과정이었습니다. 그리고 그 과정은 결국 하나의 결과로 이어졌습니다.

더 나은 다음을 더 빠르게 만들 수 있는 팀. Pegasus 1.5는 그 변화의 시작이었습니다.

페가수스 1.5에 대해 더 알아보고 싶다면 → Pegasus 1.5 Tech Blog

팀과 여정을 함께할 분들을 찾고 있습니다 → TwelveLabs Careers