소프트웨어를 한 번 배포한 뒤 고정된 시스템으로 두지 않는다
Ronak Malde가 제시하는 비전은 제품을 ‘살아 있는 시스템’으로 만드는 것이다. 모델, prompt, harness가 실제 사용에서 나온 경험을 받아 계속 바뀌는 제품을 상정한다. 일반적인 소프트웨어 개선처럼 사람이 로그를 읽고 다음 버전을 만드는 데서 멈추지 않고, 사용 과정 자체를 학습 루프에 연결하려는 구상이다. 00:00–02:12
이 비전에서 continual learning은 매 요청 직후 가중치를 바꾸는 한 가지 구현만 뜻하지 않는다. 배포에서 신호를 모으고, 선별하고, batch로 학습한 뒤 새 checkpoint를 내보내는 느린 루프도 포함한다. 화자는 현재 구현과 장기 방향을 오가므로, ‘계속 학습한다’는 표현을 실시간 업데이트가 이미 완성됐다는 말로 읽으면 범위를 넘는다.
중심 질문은 데이터가 있는가보다 어떤 행동을 개선할지 알 수 있는가에 있다. 제품에는 accept, reject, 수정, 재시도, 후속 지시가 쌓인다. 이 가운데 무엇이 사용자의 의도를 가장 잘 나타내는지, 어떤 신호가 우연이나 편의 행동인지 가려야 한다. 02:12–03:44
이진 반응보다 수정의 방향이 풍부한 학습 신호가 된다
화자는 Windsurf에서 agent가 웹사이트를 만든 뒤 사용자가 버튼 위치나 class 구조를 고치는 장면을 예로 든다. 사용자는 ‘이 답이 싫다’고만 말하지 않는다. 원하는 상태를 향해 결과를 직접 움직인다. 법률 업무에서도 agent가 놓친 조사를 변호사가 보충하고 계약서 redline을 수정한다. 그 차이는 다음 행동이 어느 방향으로 바뀌어야 하는지 보여 준다. 09:40–10:57
공개 쇼츠는 본편 09:40.447–10:57.218, 원본 16:33.186–17:49.957을 정확히 사용한다. thumbs up/down이 noisy하다는 평가는 화자의 제품 경험에 근거한 주장이다. 사용자 수정을 학습 데이터로 쓸 수 있다는 가능성과, 그 데이터로 특정 성능이 실제로 올랐다는 검증 결과는 구분해야 한다. 쇼츠 끝에서도 어려운 부분은 이 모든 행동을 학습에 맞는 형식으로 압축하는 일이라고 남긴다.
수정을 그대로 정답으로 쓰기도 어렵다. 사용자는 시간 때문에 임시로 고쳤을 수 있고, 서로 다른 사용자는 반대 방향을 원할 수 있다. 코드 diff에는 원하는 결과와 스타일 취향, 기존 시스템 제약이 함께 섞인다. 따라서 학습 파이프라인은 변경 내용뿐 아니라 이전 상태, 후속 검증, 사용자의 권한과 범위를 함께 보존해야 한다. 이는 영상의 문제 제기에서 도출한 기술적 해석이다.
법률 업무의 마지막 20%는 전문가 판단 데이터가 된다
Harvey 사례에서 화자는 법률 agent가 문서를 조사하고 계약서를 redline하는 workflow를 설명한다. 법률처럼 높은 완성도를 요구하는 분야에서는 80%까지 해낸 결과도 실제 업무에서는 사용할 수 없을 수 있다는 표현을 쓴다. 여기서 80%는 독립 benchmark 수치가 아니라 불완전한 결과의 실무 가치를 강조한 비유다. 사용자가 나머지 20%를 고치는 과정이 전문가 판단을 드러내는 데이터가 된다는 주장이다. 02:55–05:05
Harvey LAB의 공개 자료는 1,200개 이상 task, 24개 practice area, 75,000개 이상 expert rubric criteria를 제시한다. 이 수치는 Harvey의 공식 소개에 적힌 범위이며, Trajectory의 학습 효과를 독립적으로 입증하지는 않는다. 공개 task와 rubric의 존재, 실제 사용자 수정의 축적, 그 수정에 따른 모델 성능 향상은 각각 따로 확인해야 한다.
영상은 이어 NVIDIA Nemotron 3 Super를 기반 모델로 고른 이유를 설명한다. 공개 checkpoint와 학습 가능성, 배포 주권이 고려 대상이었다는 회사의 선택이다. 120B total, 12B active 같은 구조는 NVIDIA 공식 모델 자료에서 확인되지만, 기반 모델의 공개성이 Trajectory의 지속 학습 성능을 자동으로 보장하지 않는다. 06:46–09:08
프로덕션 trace를 그대로 넣으면 사용자의 실수까지 배울 수 있다
온라인 제품 데이터는 benchmark보다 현실적일 수 있지만, 곧바로 좋은 학습 데이터가 되지는 않는다. 실패한 agent 응답 뒤에 사용자가 완전히 다른 목표로 이동했을 수 있다. 후속 수정이 원래 답의 결함 때문인지, 요구가 바뀐 것인지도 구분해야 한다. 화자는 모델이 만든 trajectory와 사용자 행동을 선별하고 학습 가능한 형태로 만드는 데이터 큐레이션을 중요한 층으로 둔다. 09:08–11:23
법률 문서나 기업 workflow처럼 민감한 자료에서는 접근할 수 있다는 사실과 학습에 재사용해도 된다는 판단을 구분해야 한다. 이 문장은 영상 속 특정 계약을 설명하는 내용이 아니라, 제품의 사용자 수정을 학습 데이터로 다룰 때 필요한 추가 조건이다.
또한 과거 정책이 만든 데이터는 새 정책에 off-policy일 수 있다. 사용자가 예전 모델의 약점을 보완하려고 만든 습관을 새 모델이 그대로 모방하면, 이미 사라진 한계를 다시 학습할 수 있다. 좋은 큐레이션은 성공 사례만 모으는 일이 아니라, 어떤 모델과 제품 상태에서 그 행동이 생겼는지 함께 남기는 일이다.
자기 증류는 점수 하나를 token 단위 방향으로 바꾸려 한다
Trajectory가 설명하는 SDPO 계열 접근은 rich feedback을 본 모델과 보지 않은 모델을 비교한다. 같은 모델이 feedback이나 hint가 있는 조건에서는 teacher, 없는 조건에서는 student 역할을 맡는다. student가 실제로 만든 rollout 위에서 teacher의 token 분포를 따라가게 하면, 마지막에 받은 점수 하나보다 촘촘한 학습 신호를 얻을 수 있다는 발상이다. 11:23–14:50
관련 원 연구인 Reinforcement Learning via Self-Distillation은 runtime error나 judge feedback을 token-level signal로 바꾸는 SDPO를 제안한다. 논문의 존재와 방법 설명은 1차 자료로 확인할 수 있다. 영상에서 언급되는 SDPO++의 5% 대비 25% 결과는 Trajectory가 특정 APEX 조건에서 보고한 회사 실험이다. 서로 다른 조건의 수치를 합쳐 보편적인 5배 성능 향상으로 표현하면 안 된다.
자기 증류에도 편법이 생길 수 있다. hint에 정답이 직접 들어 있으면 teacher는 중간 추론을 생략할 수 있고 student는 문제 해결법보다 누설된 답의 흔적을 따라갈 수 있다. 따라서 feedback이 결과를 설명하는지, 정답을 건네는지, 실제 배포 시점에도 얻을 수 있는 정보인지 검사해야 한다.
여러 고객의 LoRA를 동시에 학습하려면 학습 시스템도 제품이 된다
지속 학습을 여러 고객에게 제공하면 알고리즘만으로 끝나지 않는다. 각 고객과 workflow의 adapter를 분리하고, 여러 학습 작업을 동시에 실행하며, 추론과 학습 자원을 조정해야 한다. 화자는 Multi-LoRA와 C-LoRA, SkyRL을 소개하며 하나의 GPU 인프라에서 여러 비선형 학습 작업을 병렬화하는 방향을 설명한다. 16:46–21:53
Trajectory는 8개 동시 실행에서 2.81배 throughput을 보고한다. 이것은 회사 Field Report의 특정 benchmark 결과다. 고객 수가 늘어날 때 비용이 항상 같은 비율로 감소한다는 뜻도 아니고, 학습 품질이 유지됐다는 독립 평가도 아니다. 처리량과 학습 효과를 따로 측정해야 한다.
동시 학습에서는 격리도 중요하다. 한 고객의 데이터와 adapter가 다른 고객의 업데이트에 섞이지 않는지, base model 변경 뒤 adapter가 계속 유효한지, 되돌리기와 삭제가 가능한지 검증해야 한다. throughput은 운영 가능성의 한 축이다. 데이터의 출처와 적용 이력, 업데이트 전후의 회귀 검사가 빠지면 빠르게 학습할수록 문제도 빠르게 전파될 수 있다.
주 1회 업데이트에서 Fortune 500까지는 아직 로드맵이다
마지막 구간에서 화자는 연구 중심 제품 회사로서 초기 AI-native 고객과 함께 학습 루프를 만들고, 장차 Fortune 500 기업까지 확장하려는 계획을 말한다. WIRED의 2026년 5월 보도는 당시 약 11명 팀, 1,500만 달러 seed, 주 1회 업데이트와 장래 목표를 전한다. 이는 시점이 붙은 회사와 창업자 자기보고를 포함한 보도다. 현재 달성 상태로 바꾸어 쓰면 안 된다. 21:53–27:05
공개 쇼츠는 현재 제품이 사용 신호를 모아 모델을 학습하고 관측과 평가를 붙이는 단계에 있지만, 구성 요소와 학습 실행은 아직 회사가 직접 관리한다고 설명한다. Malde가 ‘회사의 2막’으로 제시한 다음 단계는 이 과정을 고객에게 이해할 수 있게 보여 주고 통제권을 주는 것이다. 제품 PM이 agent의 강점과 실패 지점을 짚고 모델과 관련 구성 요소를 고쳐, 다음 날 운영에서 개선을 확인하는 흐름을 구상한다. 이는 현재 고객이 모두 직접 수행하는 기능이나 검증된 성과가 아니라 화자가 말한 제품 방향이다. 원본 28:19.279–29:26.422, RLDR 본편 21:26.54–22:33.683의 범위다.
이 대화에서 지속 학습은 단일 기능이 아니라 연결된 시스템이다. 사용자 행동에서 방향 신호를 찾고, 권리와 품질에 맞게 선별하고, token 단위 학습 신호로 바꾸고, 여러 고객의 업데이트를 격리해 배포한다. 각 단계는 별도의 실패 조건을 갖는다.
실제로 ‘살아 있는 시스템’을 입증하려면 업데이트 빈도만 보여 줘서는 부족하다. 어제보다 목표 행동이 좋아졌는지, 다른 능력은 유지됐는지, 수정된 사용자의 의도가 제대로 반영됐는지, 잘못된 업데이트를 되돌릴 수 있는지를 함께 확인해야 한다. 사용자가 고친 흔적은 강한 출발점이다. 그 흔적에서 정당한 학습 변화까지 이어지는 전 과정이 제품의 실질적인 증거가 된다.
