AI를 고친 시간은 누구의 자산이 되는가

AI가 만든 답을 사람이 고쳤다. 검색할 문서를 바꾸고, 잘못 호출한 도구를 되돌리고, 빠진 조건을 다시 설명했다. 그 수정이 다음 요청에 반영되지 않는다면, 같은 종류의 일을 맡길 때마다 사람이 다시 가르쳐야 한다.

이 시간을 기업의 자산으로 바꾸려는 회사가 Trajectory다. 직원이 일을 끝내기 위해 남긴 수정과 재시도를 모아, 다음번 AI가 같은 업무를 더 잘하게 만드는 플랫폼을 개발하고 있다. 공식 제품 설명

나는 기업별로 AI를 계속 개선하는 시장이 커질 것으로 본다. 특히 같은 종류의 업무가 많이 반복되고, 잘했는지 판단할 수 있는 곳에서다. 이때 기업이 확보해야 할 것은 학습할 데이터와, 그 데이터로 만든 다음 모델을 통제할 권리다.

15분짜리 화면이 보여준 것

8월 13일 공개된 Sequoia 영상에서 공동창업자 Arjun Karanam은 Trajectory의 제품 화면을 소개했다. Harvey의 법률 업무 평가인 LAB을 가져오고, 모델을 학습시킨 뒤 평가하고 비교해 배포하는 흐름이다. 사람의 실제 작업은 훈련을 기다리는 시간을 빼면 약 15분이라는 설명도 붙었다. 원영상 13:15–14:28

이 장면은 발표 슬라이드에 들어간 정지 화면이다. 현장에서 모델이 학습을 끝냈거나, 고객 업무가 개선된 과정을 보여준 것은 아니다. 15분도 발표자의 추정이다. 이 구분을 하고 보면 영상의 의미가 더 분명해진다. Trajectory는 기업이 모델을 학습하고 평가하고 교체하는 일을 하나의 제품 흐름으로 만들려 한다.

관심을 끄는 대목은 학습의 재료다. 사용자가 결과에 남기는 별점뿐 아니라, 무엇을 고쳤는지, 어느 행동을 되돌렸는지, 왜 다시 시도했는지를 보겠다는 것이다. 업무를 완성하기 위해 사람이 개입한 자리에 다음 개선의 단서가 있다는 관점이다. Sequoia 공식 전사

무엇을 배웠다는 것인가

예를 들어 거래처 주소가 오늘 바뀌었다면 최신 문서를 찾아 답하게 만들면 된다. 계약 검토에서 어떤 조항을 먼저 확인하고 언제 다른 자료를 찾아야 하는지는 조금 다르다. 여러 번의 실패와 수정에서 반복되는 판단 방식을 찾을 수 있다. 이것도 도구 설명 한 줄을 고쳐 해결할 수 있고, 더 깊은 모델 학습이 필요할 수도 있다.

여기서 “학습”을 구분해야 한다. RAG는 필요한 문서를 검색해서 모델에게 보여준다. 메모리는 과거의 교정이나 사건을 저장했다가 다음 요청에 꺼내 쓴다. 둘 다 다음 답을 바꿀 수 있지만, 그 동작만으로 모델의 가중치가 바뀌지는 않는다. RAG 원논문

프롬프트나 하네스 수정은 지시문과 실행 방식을 바꾼다. 하네스는 모델 주변에서 도구 호출, 상태, 작업 순서를 관리하는 프로그램이다. 주기적 파인튜닝은 모아 둔 데이터로 새 가중치나 어댑터를 만든다. 어댑터는 기반 모델에 붙이는 작은 학습 모듈이다.

온라인 학습은 새로 들어오는 데이터 흐름을 따라 모델을 점진적으로 갱신한다. 이때도 데이터를 작은 묶음으로 처리할 수 있다. 데이터를 언제 학습에 쓰고, 새 모델을 언제 운영에 내보낼지는 별도로 정한다. 온라인이라는 말이 매 요청마다 가중치가 즉시 바뀐다는 뜻은 아니다.

강화학습(RL)은 보상으로 행동을 개선하는 학습 방법이다. 한 번만 실행할 수도 있으므로, RL을 썼다는 말이 계속 배우는 시스템을 만들었다는 뜻은 아니다. 새 업무를 배우면서 기존에 잘하던 일도 유지되는지 봐야 한다. Continual learning 연구 개관

Trajectory는 이 여러 층을 아우르는 넓은 의미로 continual learning을 설명한다. 모델뿐 아니라 프롬프트와 하네스를 바꾸고, 정보의 성격에 따라 문맥에 남길 수도 있다는 것이다. 공개된 학습 실험을 근거로 매 요청마다 고객 모델의 가중치가 즉시 바뀐다고 말할 수는 없다. 제품 설명, 원영상의 학습 대상 Q&A 14:28–16:08

교정을 가중치로 옮기는 방법도 연구하고 있다. Trajectory가 공개한 SDPO 설명에서는 같은 모델을 두 역할로 쓴다. 한쪽은 실패 뒤에 얻은 힌트를 보고, 다른 쪽은 그 힌트 없이도 더 나은 판단을 하도록 학습한다. 사후 정보를 이용해 다음 행동을 바꾸려는 방법이다. 다만 6월 2일 연구 글은 실제 운영 기록에 이 방법을 적용하는 일을 앞으로의 계획으로 적었다. 그 실험을 고객 운영에서 이미 완성된 학습 루프로 읽어서는 안 된다. Scaling SDPO

교정이 다음 배포까지 이어지는 과정

9월 11일 공개된 Dwarkesh Podcast에서도 이 구분이 논의됐다. Charlie O’Neill은 배포 데이터를 모아 후속 학습하는 방식과 개별 모델이 경험 직후 배우는 방식을 구별했다. John Schulman은 자연스럽게 들어오는 업무 데이터에서 무엇을 보상으로 삼을지가 어렵다고 지적했다. 사용자가 수정을 받아들였다는 신호조차 잘못 최적화될 수 있다는 것이다. 공식 전사, 원영상 41:23–45:24

토론에서 예로 든 Cursor의 원문을 보면 신호가 다음 배포로 이어지는 과정이 구체적이다. Cursor는 운영 중인 Composer와 사용자의 상호작용을 대량으로 모아 보상 신호를 만들고, 모델 가중치를 갱신한다고 설명한다. 그다음 CursorBench를 포함한 평가에서 성능 저하가 없는지 확인한다. 결과가 좋아야 새 체크포인트를 배포한다. 회사는 이 전체 과정을 약 5시간에 수행해 하루에도 여러 번 개선 버전을 내보낼 수 있다고 보고했다. 고정된 배포 보장이나 요청마다 즉시 배우는 구조는 아니다. Cursor의 3월 26일 보고

그 과정에서 실제로 문제가 생겼다고 한다. 잘못된 도구 호출은 학습 사례에서 제외했는데, Composer가 어려운 작업에서 일부러 잘못된 호출을 내보내면 나쁜 보상을 피할 수 있었다. Cursor는 이런 호출도 부정적인 학습 사례에 넣어 고쳤다. 사람이 만들어 둔 데이터 선별 기준의 허점을 모델이 학습한 셈이다. 같은 보고서의 실패 사례

이 사례는 기록을 많이 모으는 것으로 끝나지 않는다는 점을 보여준다. 무엇을 잘못으로 볼지 정하고, 그 기준으로 가중치를 바꾸고, 다른 능력이 나빠지지 않았는지 평가한 뒤 운영에 반영해야 한다. Cursor 제품의 개선 사례이므로 고객 회사마다 자기 모델을 소유한다는 증거로 쓸 수는 없다. 기업별 학습 제품도 이 과정을 얼마나 안정적으로 반복하는지 보여줘야 한다.

120개 중 10개, 그리고 늘어난 토큰

가능성을 판단할 더 구체적인 자료는 8월 11일 공개된 법률 업무 실험이다. Trajectory는 NVIDIA Nemotron 3.5 Lightning을 후속 학습시킨 결과, Harvey LAB의 평가 문제에서 완전 통과율이 0%에서 8.3%로 올랐다고 보고했다. 24개 영역에서 5개씩 뽑은 120문제 중 10개다. 학습에 사용하지 않은 평가 문제를 대상으로 한 회사 자체 보고다. 실험 원문

완전 통과는 한 문제의 채점 조건을 모두 충족했다는 뜻이다. 0%였다는 말도 모든 답이 쓸모없었다는 뜻은 아니다. 어려운 법률 업무 평가에서 일부 조건을 맞히는 것과 전체 조건을 만족하는 것의 차이를 보는 지표다.

토큰 사용량을 함께 보면 이야기가 달라진다. 기반 모델은 과제당 평균 약 2만 2천 개의 출력 토큰을 사용했다. 첫 학습 버전은 10개를 완전 통과하는 대신 약 9만 개를 썼다. 두 번째 학습 버전은 10개 통과를 유지하면서 약 3만 7천 개로 줄였다. 같은 보고서의 토큰 비교

학습으로 성능이 올랐을 때 처음에는 출력량도 크게 늘었다. 이후에는 같은 통과 수를 유지하며 출력량을 줄였다. 모델이 더 잘하고 더 싸게 일하는 목표를 따로 확인해야 하는 이유다.

여기까지가 공개 자료가 보여주는 진전이다. 이 실험은 특정 업무에서 모델을 개선하고 효율을 조정할 수 있다는 초기 근거다. 회사 전체의 업무를 수개월 동안 계속 배우며 좋아졌다는 결과는 아니다. 학습비, 평가비, 운영 인력까지 합친 고객의 총비용도 이 숫자에서 나오지 않는다.

데이터가 회사에 남는다는 약속

직원의 교정에는 회사가 일을 처리하는 방식이 담길 수 있다. 어떤 문서를 믿는지, 언제 결정을 미루는지, 무엇을 잘못된 결과로 보는지까지 드러난다. 이를 학습에 활용한다면 기업이 어느 기록을 내보내고 어떤 용도로 쓰게 할지 결정할 수 있어야 한다.

이 지점에서 “자기 모델을 갖는다”와 “데이터가 회사 밖으로 나가지 않는다”를 따로 확인해야 한다. Trajectory SDK 문서는 로컬에서 기록을 가공하는 절차와, 가공한 기록을 플랫폼에 업로드하는 절차를 모두 제공한다. 로컬 파일만 저장하는 선택지도 있다. 따라서 공개 문서만으로 데이터 무반출을 보장한다고 쓸 수 없다. SDK quickstart, 업로드 API

개인정보를 가리는 기능도 있다. 이메일, 전화번호 등 지정된 항목에 규칙을 적용하는 방식이다. 그러나 회사의 중요한 정보가 전부 개인정보 형식으로 나타나지는 않는다. 제품 계획이나 고객과의 협상 조건까지 해당 규칙이 지워 준다는 보장은 없다. 영상에서 언급한 합성 데이터 역시 원데이터를 어디에서 처리하고 무엇을 보존하는지 확인해야 한다. Redaction 문서, 고객 데이터 Q&A 16:08–17:13

Trajectory는 고객이 학습 데이터를 통제하고, 평가와 고객 승인을 거쳐야 모델 업데이트가 운영에 들어간다고 설명한다. SOC 2 인증 문구도 있다. 다만 공개 홈페이지의 약속과 실제 고객에게 적용되는 배포 구성, 감사 범위, 계약 권리는 서로 다른 증거다. 이 조사에서는 고객별 계약과 감사 보고서까지 확인하지 못했다. 공식 홈페이지

계약이 끝날 때 학습 데이터와 평가 문제를 가져갈 수 있는가. 학습한 모델이나 어댑터를 다른 곳에서 실행하고 수정하거나 다시 학습할 수 있는가. 삭제한 데이터가 파생 산출물에는 어떻게 반영되는가. 기업이 자기 학습을 소유한다면 답이 있어야 할 질문들이다.

Trajectory의 공개 이용약관은 사이트 이용을 다루고, 개인정보처리방침도 서비스 고객 데이터는 별도 계약의 적용을 받는다고 구분한다. 이 문서들로 위 권리를 확정할 수는 없다. 권리가 없다는 판정도 할 수 없다. 현재 공개 근거의 빈칸으로 남는다. 이용약관, 개인정보처리방침

비슷한 회사들은 다른 곳을 고친다

Trajectory 옆에서 볼 만한 회사는 Applied Compute와 Construct Labs다. 둘 다 기업별 모델 학습을 제품으로 만든다. RELAI는 모델 밖의 수정까지 비교할 때 유용하다.

회사 이름을 모으는 것보다 이 차이가 중요하다. 어떤 실패는 검색과 도구를 고쳐서 해결하고, 어떤 실패는 모델 학습의 대상이 된다. 기업은 같은 품질을 달성하는 데 어느 방식이 덜 복잡하고 저렴한지 비교해야 한다. 모델이 바뀌지 않는 개선도 충분히 가치가 있다.

고객 근거의 수준도 다르다. Trajectory 홈페이지의 일부 인용은 모델 테스트나 연구 협업에 관한 말이다. Applied Compute에는 이름이 있는 고객 인용이 있고, Construct Labs의 위 실험은 고객명을 밝히지 않은 파일럿이다. 이들을 모두 독립 검증된 운영 성과로 묶을 수는 없다. 세 회사의 전체 도입 비용을 같은 기준으로 비교할 자료도 아직 없다. Trajectory, Applied Compute, Construct Labs 사례

시장이 커지려면 넘어야 할 계산

가장 강한 반론은 범용 모델이 계속 좋아진다는 것이다. 최신 모델에 문서 검색을 붙이는 것만으로 목표 품질을 얻는다면, 기업이 별도의 학습 체계를 운영할 이유는 줄어든다. 업무량이 작거나 정답을 확인하기 어렵다면 학습과 평가가 새로운 비용이 될 수 있다.

계산은 같은 품질의 일을 기준으로 해야 한다. 업무 한 건에서 아끼는 비용에 반복량을 곱한 값이, 초기 구축과 학습, 재학습, 평가, 운영에 드는 추가 비용보다 커야 한다. 한 건의 비용에는 모델 호출뿐 아니라 사람이 다시 확인하고 고치는 시간도 들어간다. 한 건당 절감액이 없다면 사용량이 늘어도 이 계산은 좋아지지 않는다.

이득이 나와도 다음 모델이 출시되면 다시 비교해야 한다. 기반 모델을 교체할 때 회사의 데이터와 평가를 다시 쓸 수 있는지, 새 모델에 맞춰 학습을 반복하는 비용은 얼마인지가 중요해진다. 특정 모델을 한번 잘 튜닝한 것과, 모델이 바뀌어도 개선을 이어가는 능력은 다르다.

계속 학습한다는 사실만으로 경쟁 우위가 영구히 유지되는 것도 아니다. Dwarkesh 토론에서 Schulman은 배포를 통해 기업이 자기 모델을 개선할 가능성을 제시했고, Beren Millidge는 매일 개선되는 모델의 행동도 매일 증류할 수 있다고 반론을 폈다. 기업별 학습이 기술적으로 가능하다는 판단과, 그 기업만의 이익으로 얼마나 오래 남는가는 다른 질문이다. 기업별 모델과 증류에 관한 토론

직원의 수정이 항상 정답인 것도 아니다. 급해서 승인한 결과일 수 있고, 나중에 드러난 실패가 기록에 연결되지 않을 수도 있다. 이런 신호를 그대로 학습하면 잘못된 습관을 강화할 수 있다. 새로운 업무의 점수와 함께 기존 업무, 시간이 지난 뒤 들어온 문제, 실패했을 때 이전 버전으로 되돌리는 절차를 확인해야 한다. Continual learning 연구가 새로 배우는 능력과 기존 능력의 보존을 함께 다루는 이유다. 연구 개관, 순차 학습을 비교하는 Tinker SDFT 구현

그래서 기업별 학습의 초기 시장은 반복량이 크고, 업무 기준이 분명하고, 수정의 결과를 확인할 수 있는 곳에서 열릴 가능성이 높다고 본다. Trajectory의 공개 실험은 그 가능성을 살펴볼 출발점이다. 자동으로 계속 좋아지는 기업 AI가 이미 완성됐다는 결론까지 뒷받침하지는 않는다.

회사가 지금의 체크포인트를 갖는 데서 끝나면, 다음 모델이 나왔을 때 다시 처음부터 시작할 수 있다. 무엇을 가르칠지 결정하고, 나아졌는지 검증하고, 그 기록으로 다음 모델을 다시 학습할 수 있어야 한다.

직원이 AI를 고치는 데 쓴 시간이, 그 회사의 다음 AI에도 남아야 한다.