모델은 똑똑해져도 회사에서는 늘 첫날처럼 행동한다
Arjun Karanam은 모델의 발전을 IQ라는 한 축으로 설명한다. 주머니 속에 수학자 Terrence Tao가 있어도 회계법인 첫날에는 최고의 회계사가 아닐 수 있다. IQ와 별개로 회사의 도구, 관행, 고객과 실패를 배운 경험이 필요하다. 그는 이 간격을 experience gap이라고 부른다.
이 예는 Tao가 실제 회계법인에서 일했다는 일화가 아니다. Karanam은 몇 년, 어쩌면 며칠의 경험만 쌓아도 아마 잘할 것이라고 가정하면서, 지능과 경험을 서로 다른 축으로 보자고 제안한다. 가상의 첫 출근과 경험 격차를 설명하는 구간은 본편 1:33–1:57이다.
agent는 막대한 토큰과 실제 작업 결과를 만들지만, 사람이 그 결과를 수정하고 행동한 뒤 신호가 버려진다. Trajectory의 가설은 바로 그 상호작용을 학습 재료로 바꾸자는 것이다. 목표는 단순히 더 큰 모델을 쓰는 것이 아니라 사용될수록 더 빠르고, 더 좋고, 더 저렴해지는 시스템을 만드는 일이다.
그는 에이전트가 만드는 토큰의 규모를 말하며 100조라는 숫자를 들지만, 측정 대상이나 집계 방법을 제시하지 않는다. 그 수치를 실제 사용량 통계로 받아들일 수는 없다. 여기서 핵심은 생성량보다 버려지는 신호다. 사람이 결과를 읽거나 그에 따라 행동했는데도, 다음 작업을 개선하는 데 그 정보가 쓰이지 않는다는 문제 제기다. 실제 작업에서 배우자는 발언은 본편 1:58–2:29에 나온다. 이 주장은 Trajectory가 택한 방향이며, 상호작용을 저장하는 것만으로 학습 효과가 입증됐다는 뜻은 아니다.
이 55.60초 쇼츠는 회계법인에 처음 출근한 수학자의 가상 예에서 출발해, 실제 작업과 사람의 반응을 학습 신호로 삼자는 Trajectory의 관점까지 담는다. 뒤에 나오는 구체적인 학습 절차와 제품 시연은 포함하지 않는다. 쇼츠 전체 구간
첫 단계는 전체 작업 트리를 추적하고 spec으로 바꾸는 일이다
continual learning의 출발점은 traceability다. 최종 답변만 저장해서는 agent가 왜 성공하거나 실패했는지 알 수 없다. 주 행동뿐 아니라 tool call, subagent, 중간 상태와 결과를 함께 추적해야 한다. subagent와 도구 호출을 버리면 전체 작업에서 배울 수 없다는 설명이 나온다.
다음에는 interaction을 model spec으로 바꾼다. 사용자가 무엇을 원했고 어떤 행동을 수정했는지, agent가 무엇을 해야 하는지를 정확한 기준으로 표현한다. Trajectory는 긴 trace에서 reward와 spec을 추출하고, SDPO 같은 방법과 RL로 모델을 개선한다고 설명한다. 발표는 알고리즘의 성능을 독립적으로 입증하기보다 제품 방향을 소개한다.
공개 하이라이트는 원본 03:13.100–10:26.650의 연속 구간이다. 상호작용 수집과 행동 명세, 모델과 harness의 개선 대상을 설명한 뒤 traceability, eval, harness 설계로 이어진다.
좋아요보다 실행 취소와 재시도가 더 많은 정보를 준다
좋아요와 싫어요는 편하지만 잡음이 많다. 사용자는 코딩 agent의 제안을 매번 자세히 평가하지 않고 일단 수락할 수 있다. 다섯 번째 커밋쯤 가서 전체가 망가졌음을 깨닫고 되돌리기도 한다. 그래서 편집, undo, retry 같은 교정 행동을 포착해야 한다.
피드백에는 정보량 차이가 있다. 사용자가 욕하거나 세션을 떠나면 무언가 잘못됐다는 사실은 알 수 있지만 정답은 모른다. agent가 재시도해 올바른 해법에 도달하거나 사용자가 차이를 직접 고치면 원하는 결과를 더 강하게 알 수 있다. 전자는 행동을 패널티할 신호이고, 후자는 보상과 정답 후보를 함께 준다.
제품, eval, 훈련 환경을 같은 곳에 가깝게 둔다
두 번째 축은 eval이다. 사용자가 실제로 쓰는 제품, 평가가 실행되는 환경, 모델이 훈련되는 환경이 최대한 같아야 한다. eval은 현재 트래픽뿐 아니라 사용자가 요청했지만 아직 제품이 수행하지 못하는 frontier 요청에서도 뽑을 수 있다.
모든 과제를 rollout할 수 있어야 한다는 요구도 붙는다. 사용자가 한 일을 상태와 도구까지 포함해 재생할 수 있어야 여러 정책과 모델을 같은 조건에서 비교할 수 있다. 그리고 변형된 테스트 harness가 아니라 실제 프로덕션 harness로 채점해야 한다. 이 글의 추가 해석은 재실행의 성공과 현실 성능의 예측을 구분하자는 것이다. 저장한 상태에서 다시 실행할 수 있더라도, 그 평가 순위가 이후 실제 업무 결과와 맞는지는 별도로 검증해야 한다.
harness는 agent를 묶는 흐름보다 사용할 수 있는 primitive를 제공한다
과거 harness는 형식 오류와 무작위 실패를 막는 안전 레일에 가까웠다. Karanam은 모델이 강해진 지금 정해진 흐름을 강제하기보다 검색, 비공개 정보, 쓰기 도구 같은 primitive를 제공하고 agent가 이를 오케스트레이션하게 해야 한다고 주장한다. 사용자 UI에서 가능한 일을 agent도 tool call로 할 수 있어야 한다.
도구 응답도 done이나 finished만 반환하면 학습 신호가 없다. 실제로 무엇을 읽고 썼는지, 어떤 상태가 바뀌었는지 알려 줘야 agent가 다음 행동을 결정하고 나중에 trace를 평가할 수 있다. agent interface와 user interface가 가까울수록 제품 행동을 그대로 학습과 eval에 재사용하기 쉽다.
open-weight 모델로 바꾸는 데에도 보안과 배포 역량이 필요하다
발표의 네 번째 바람은 open-weight 모델을 실제로 운영할 준비다. Karanam은 모델만 교체하면 끝날 것 같지만 보안, 안전, 접근 권한 설정 등 수많은 고려사항이 따라온다고 말한다. 그럼에도 직접 운영하는 경험을 쌓아야 자신의 방식으로 모델을 개선하는 경로를 열 수 있다는 주장이다. 10:34–11:03
모든 요청에 같은 모델을 쓰자는 뜻도 아니다. 과제가 요구하는 능력에 맞춰 적절한 모델로 보내는 router가 중요해질 것이라 전망하고, 여러 모델을 나눠 쓰는 실험을 권한다. 단순히 저렴한 모델로 바꾸는 문제에서 어떤 업무에 어느 모델을 쓸지 정하는 문제로 넓어진다. 발표는 이 역할의 중요성을 예상하며, 최적의 routing 방법이 완성됐다고 보고하지는 않는다. 11:03–11:23
새 정보는 모델, harness, context 중 알맞은 층으로 간다
continual learning을 실시간 가중치 업데이트로만 정의하면 발표의 핵심을 놓친다. 제품의 지능은 모델, harness, context와 도구로 이뤄진 시스템이다. 상장 폐지처럼 바뀌는 사실은 가중치보다 context에 두는 편이 낫다. 특정 도구 호출이 모든 사용자에게 반복해서 실패한다면 모델이나 공통 harness를 고칠 수 있다. 한 사용자가 특정 subagent를 싫어한다면 개인 context에 남겨야 한다.
Karanam은 RAM과 디스크 중 어디에 저장할지 사용자가 매번 결정하지 않듯, 무엇을 모델과 harness, context 중 어디에 반영할지도 시스템이 추상화해야 한다고 말한다. 피드백이 개인, 고객, 조직, 전역 중 어디에 유효한지 분류하는 일이 먼저다.
피드백의 적용 범위는 개인, 고객, 조직, 전역으로 나뉜다
같은 행동도 누구에게서 나왔는지에 따라 의미가 다르다. 한 사용자가 특정 subagent를 싫어한다고 말한 것은 그 사용자의 context에 둘 수 있다. 한 고객의 보안 정책이 특정 도구를 금지한다면 고객 단위 harness나 policy가 맞다. 여러 고객에서 같은 도구 실패가 반복되면 공통 harness나 모델의 개선 후보가 된다. 피드백의 위계를 설명하는 구간은 personalization과 전역 학습을 섞을 때 생기는 피해를 막는다.
승격에는 증거가 필요하다. 개인 피드백 하나를 전역 모델에 넣으면 다른 사용자의 선호를 침해할 수 있다. 반대로 여러 번 반복되는 공통 오류를 개인 memory에만 두면 조직 전체가 같은 실수를 치른다. 적용 범위, 유효 기간, 충돌 해결 규칙과 rollback 경로를 함께 저장해야 한다.
context에 둔다는 말도 단순히 대화 기록을 계속 붙인다는 뜻은 아니다. 어떤 요청에서 memory를 검색할지, 오래된 정보는 언제 만료할지, 고객 경계를 넘어 검색되지 않는지 eval해야 한다. 가중치 업데이트보다 되돌리기 쉽다는 장점은 있지만 잘못된 retrieval은 여전히 행동을 바꾼다.
15분이라는 시연 수치는 사람의 조작 시간을 가리킨다
제품 시연에서는 학습 후보를 만들고, 성능을 평가하고, 기존 모델과 비교한 뒤 배포하는 흐름을 보여 준다. Karanam은 이 과정에 사람이 실제로 들인 작업 시간이 대략 15분이었다고 설명한다. 모델이 학습되기를 기다리는 시간은 포함하지 않았다는 단서를 직접 붙인다. 따라서 전체 학습과 검증이 15분 만에 끝났다는 뜻으로 읽으면 안 된다. 13:53–14:08
이 시연이 보여 주는 가치는 작업 단계를 한 도구 안에서 이어 볼 수 있다는 점이다. 학습된 모델의 일반적인 우수성이나 모든 고객의 도입 시간을 입증한 결과는 아니다. 앞서 설명한 기록 수집, 평가, 실제 harness와의 연결이 준비돼 있어야 같은 흐름을 자신의 제품에서도 시험할 수 있다.
continual learning loop는 수집, 해석, 비교, 승격의 네 단계다
첫째, trace를 완전하게 수집한다. 입력과 최종 출력뿐 아니라 tool call, subagent, 환경 상태 변화, 사람의 수정과 retry를 연결한다. 둘째, 신호를 해석한다. 세션 이탈과 욕설은 실패 가능성을 알리지만 정답을 말해 주지 않는다. 사용자의 직접 수정이나 성공한 재시도는 더 강한 정답 후보다.
셋째, 바꾸기 전에 replay로 비교한다. 동일한 초기 상태와 실제 harness에서 기존 정책과 후보 정책을 실행하고, 성공률뿐 아니라 비용, latency, 금지 행동, 사람 수정량을 측정한다. frontier 요청은 현재 모델이 못 한다는 이유로 eval에서 빼지 않는다. 실제 트래픽과 아직 수행하지 못하는 요청에서 eval을 뽑으라는 설명이 여기에 해당한다.
넷째, 가장 좁은 범위에 승격한다. context 변경, tool 설명 수정, router 조정, model update 가운데 필요한 층만 고른다. 배포 뒤에는 새로운 trace가 실제 개선을 뒷받침하는지 보고, 회귀가 생기면 이전 버전으로 돌아간다. 이 구조가 없다면 데이터를 계속 모아도 학습 루프가 아니라 로그 적재에 머문다.
Karanam은 발표의 미해결 과제를 네 가지 소원으로 묶는다. 공개 하이라이트는 그중 traceability, eval, harness에 관한 세 번째 소원까지 다룬다. 네 번째인 open-weight 운영은 하이라이트가 끝난 뒤 시작되므로 별도 절에서 원본 구간을 기준으로 설명한다.
고객 interaction을 배운다는 말은 권리 문제를 자동으로 해결하지 않는다
질의응답에서는 고객 데이터로 직접 훈련하지 않으면서 분포를 표본화하고 합성 데이터를 생성해 비교하는 접근이 언급된다. Karanam은 고객 데이터 자체로 직접 훈련하지 않는 방법을 연구한다고 말한다. 이 답변은 privacy가 핵심 문제임을 인정하지만, differential privacy 보장이나 모든 고객 약정 준수를 입증하지는 않는다. 원자료로 훈련하지 않더라도 분포 표본, 합성 데이터, eval 결과가 민감한 특징을 보존할 수 있다.
권리는 용도별로 확인해야 한다. 운영을 위해 trace를 보관할 권리와 모델 평가에 쓸 권리, 가중치 학습과 파생 데이터 생성 권리는 서로 다르다. 고객 간 신호를 합칠 수 있는지, 삭제 요청이 모델과 eval corpus에 어떻게 전파되는지, retention 기간과 접근 주체도 정의해야 한다. 직접 학습하지 않았다는 문장 하나로 이 질문을 닫을 수 없다.
continual learning이 특히 유용한 과제로는 사용자가 모델 능력의 가장자리를 시험하는 경우를 든다. 모델이 겨우 수행하거나 실패한 요청을 훈련에서 배우면 이전에 못 하던 일을 할 수 있게 된다. 고객이 못 하던 일에서 frontier를 넓힌다는 설명은 매력적인 방향이지만, 대부분의 과제에 적용 가능하다는 발표자의 견해와 실제 경제성은 구분해야 한다.
공개 쇼츠는 이 질의응답의 원본 20:20.520–21:45.680을 연속으로 담는다. Karanam은 대체로 대부분의 과업이 continual learning에 맞는다고 보면서도, 특히 현재 능력의 경계에 있는 일을 강조한다. 사용자는 제품이 할 수 있다고 기대하는 수준까지 요청하고, 실패를 보면 물러난다. 그는 2년 전 Cursor에는 지금 같은 질문을 떠올리지도 않았지만 모델이 좋아지면서 더 큰 일을 요청하게 된 자신의 변화를 예로 든다. 이어 일부 고객에게서 모델이 겨우 하던 일을 훈련 중 배워 사용자가 이전에 못 하던 일을 하게 된 사례를 관찰했다고 말한다. 이는 화자의 견해와 회사 사례이며, 모든 과업의 효과나 경제성을 독립적으로 입증한 결과는 아니다.
실행 순서는 명확하다. 전체 trace를 수집할 권리부터 확인하고, 성공과 실패의 신호 강도를 구분하며, feedback의 적용 범위를 정한다. 실제 harness에서 replay와 eval을 하고, 모델과 context 가운데 가장 좁은 층을 고친다. 그 뒤 회귀 검사를 거쳐 배포한다. 이 순환이 있어야 agent가 매번 첫날로 돌아가지 않는다.