범용 모델이 바닥을 높이고, 회사별 학습이 천장을 높인다
Applied Compute의 Yash Patil은 회사별 AI를 "Specific Intelligence"라고 부른다. 범용 모델이 발전하면 모든 제품의 기본 성능이 함께 올라가지만, 회사가 실제 업무에서 차별화하려면 고유 데이터와 업무 흐름, 현업 전문성을 시스템에 넣어야 한다는 주장이다. 그는 이를 한 회사를 위한 AI라고 정의한다.
여기서 핵심은 정적인 지식 주입이 아니다. 사람과 agent의 상호작용, 운영 trace, 회사가 보유한 데이터를 이용해 실제 사용이 늘수록 시스템을 개선하는 구조다. 프런티어 모델은 강력한 첫 단계이며, 기업은 기성 모델로 손쉬운 과제를 먼저 자동화한다. 그러나 고유한 업무 절차와 판단 기준이 필요한 지점에서는 아주 구체적인 eval을 만들고 그 과제에 특화된 agent를 훈련하려 한다.
Patil은 프런티어 모델이 좋아질수록 성능의 바닥이 올라가지만, 맞춤 post-training이 천장을 정한다고 말한다. 그 구분은 범용 모델과 특화 모델을 대체 관계가 아니라 층으로 본다. 범용 모델은 넓은 능력을 공급하고, 회사별 시스템은 결과 기준과 비용, latency, 도구 사용을 특정 업무에 맞춘다.
agent를 만들고, 관찰하고, 개선하는 세 축
Applied Compute가 설명하는 플랫폼은 세 축으로 나뉜다. agent를 구성하고, agent의 행동을 관찰하며, 관찰 결과로 agent를 개선한다. 강화학습 과정에서 생성되는 rollout trace를 처리하고, 수천 개 trace에 걸쳐 관측 기능을 병렬 실행하며, 학습한 모델을 추론 서비스에 올려 다시 운영 trace를 수집한다. Modal을 이 세 단계의 실행 기반으로 쓴다는 설명은 발표가 특정 인프라 파트너와 함께 만든 콘텐츠라는 점도 보여 준다.
이 순환에서 데이터는 처음부터 고정된 학습 말뭉치가 아니다. 제품 사용 중 사람이 모델과 상호작용한 과정, 도구 호출, 성공과 실패를 trace로 남긴다. 그 trace를 context, memory, 합성 데이터로 변환하고 다음 eval과 훈련 데이터에 반영한다. 운영과 학습이 연결되는 셈이다.
하지만 운영 trace가 존재한다고 곧바로 학습 권리가 생기지는 않는다. 어떤 사용자 데이터가 포함됐는지, 수집 목적과 재사용 범위가 무엇인지, 삭제와 보존은 어떻게 처리하는지 별도 경계가 필요하다. 발표는 시스템 메커니즘을 설명하지만 그 권리 체계를 완성했다고 입증하지 않는다.
성공 사례를 읽을 때는 과제 정의와 주장 주체를 함께 본다
Patil은 DoorDash와 Cognition 사례를 든다. DoorDash에서는 복잡한 메뉴 이미지를 매장용 구조화 데이터로 바꾸는 온보딩 과제를, Cognition에서는 코드를 저장한 뒤 몇 초 안에 버그를 찾는 agent를 설명한다. Cognition용 맞춤 모델은 Cerebras 하드웨어에서 실행된다고 한다. DoorDash 업무 설명은 6분 6초, Cognition 설명은 6분 35초부터 나온다.
중요한 것은 사례의 이름보다 구조다. 고객 팀과 함께 자율 agent를 투입할 업무를 좁히고, 높은 품질의 eval로 정의한 뒤, 모델을 훈련하고, 운영 trace와 사람의 상호작용을 다시 개선에 쓴다. "업무를 잘한다"를 메뉴 항목의 정확한 구조화나 빠른 버그 탐지처럼 검사 가능한 결과로 바꿔야 학습이 가능하다.
다만 발표만으로 성능 향상 폭, 비교 대상, 오류율, 장기 운영 비용을 독립적으로 확인할 수는 없다. 회사가 공개한 파트너 사례는 메커니즘을 이해하는 자료로는 쓸 수 있지만, 보편적인 성과 증명으로 확대하면 안 된다.
agent를 개선할 곳은 모델, harness, context로 나뉜다
모든 실패를 가중치로 해결할 필요는 없다. Patil은 agent를 바꿀 수 있는 표면을 모델 계층과 harness 및 context 계층으로 나눈다. 가중치를 직접 바꿔 문제를 보는 방식을 조정해야 하면 open-weight 모델과 post-training이 필요하다. 반면 도구 실행 구조, 검색, 메모리, 회사의 최신 사실은 harness와 context에서 다룰 수 있다. agent는 모델보다 훨씬 큰 시스템이라는 설명이다.
이 구분은 비용과 최신성에 직접 영향을 준다. 자주 바뀌는 정책이나 고객 상태를 가중치에 넣으면 업데이트가 느리고 삭제도 어렵다. 반대로 반복되는 판단 패턴과 도구 선택을 prompt에만 넣으면 매번 긴 context가 필요하고 일관성이 떨어질 수 있다. 어떤 신호를 어느 층에 반영할지 결정하는 것이 지속 학습의 핵심 설계다.
기업용 agent를 평가할 때도 모델 점수만 보면 부족하다. 같은 모델이라도 도구 정의와 권한, 오류 메시지, memory, retry 정책에 따라 결과가 달라진다. eval은 실제 harness를 포함한 시스템 전체를 대상으로 해야 한다.
고위험 업무의 보상 함수는 sandbox 안에서 검증한다
이 인터뷰가 실행 환경을 강조하는 데에는 코드의 역할이 먼저 있다. 모델이 숫자를 토큰으로 이어 쓰며 계산하게 하는 대신, Python 함수를 작성하고 실행해 값을 구하게 할 수 있다. Patil은 코드가 반복 가능한 계산을 제공한다는 점과, 현재 프런티어 모델 및 공개 모델이 코딩을 강하게 학습했다는 점을 이유로 든다. 모델이 이미 익숙한 행동 방식을 실제 실행 환경에 연결하는 것이다. 11:07–11:46
이때 코드 실행 자체가 정확하다는 것과, 모델이 올바른 프로그램을 썼다는 것은 구분해야 한다. 실행기는 주어진 코드를 계산할 수 있지만 잘못된 가정이나 엉뚱한 데이터 선택을 고쳐 주지는 않는다. 그래서 계산 결과를 평가할 기준과 코드를 반복 실행할 격리 환경이 함께 필요하다. 이는 발언을 시스템 설계로 풀어 쓴 해석이다.
Applied Compute는 높은 volume, 많은 context, 큰 결과 책임이 있는 업무에서 맞춤 모델의 가치가 커진다고 본다. 그런데 이런 업무일수록 reward를 단일 숫자로 만들기 어렵다. 올바른 도구 호출, 데이터베이스 변경, 정책 준수, 고객 만족, 회사 비용을 함께 봐야 한다.
새 공개 하이라이트는 이 학습 절차를 더 구체적으로 보여 준다. 모델이 같은 문제를 수백 번 또는 수천 번 병렬로 시도하고, 코드는 단위 테스트 통과 수로, 답변은 rubric으로 채점해 보상 분포를 만든다. 이 분포가 학습 신호가 되려면 각 시도가 같은 초기 상태에서 다시 실행될 수 있어야 한다. Patil은 Modal sandbox가 일회성이고 가벼워 환경을 빠르게 구성할 수 있다고 평가한다. 그는 당시 이용할 수 있던 sandbox 제공사를 비교했고, 이전 OpenAI 근무 때에도 비슷한 RL 훈련 도구를 검토했다고 말한다. Modal의 유연성과 성능 및 신뢰성, Modal 팀의 지원이 선택에 작용했다는 설명이다. 04:13–04:41 비교 방법과 측정 결과는 공개하지 않았으므로, 이는 Applied Compute가 사용한 제품에 대한 화자의 경험이지 독립 benchmark가 아니다.
강화학습에서는 agent가 반복해서 행동할 환경이 필요하다. Patil은 sandbox의 snapshot과 결정성, replay 가능성을 강조한다. 학습 중 실제 운영 서비스를 건드리지 않고 Salesforce나 Slack 같은 시스템을 모사해야 한다. 많은 rollout을 한꺼번에 실행할 때 sandbox의 P50과 P90 기동 시간, 복구 능력도 GPU 활용률에 영향을 준다. 배치가 수천 rollout이고 한 rollout이 1시간에서 3시간까지 길어질 수 있다는 설명은 인프라 병목이 단순 GPU 수량만의 문제가 아님을 보여 준다. Salesforce나 Slack 전체를 본뜬 모의 서비스는 CPU 작업도 무거워질 수 있다. 이 단계가 느리면 비싼 GPU가 환경 응답을 기다리게 되므로, 샌드박스의 병렬 기동과 복구도 학습 효율의 일부가 된다. Patil은 Modal 함수가 많은 계산을 저렴하게 병렬 처리한다고 말하지만, 이 비용 우위도 독립 측정치로 제시된 것은 아니다. 06:05–07:07
여기서 한 걸음 더 나아가 환경의 완성도를 따져볼 수 있다. 화면 복제에 더해 모델이 볼 수 있는 정보, 가능한 행동, 상태 변화, 종료 조건, 채점기, 초기화와 재실행 규칙을 정의해야 한다는 것이 이 글의 기술적 해석이다. 실제 서비스와 분리돼 안전하게 반복할 수 있으면서도 업무 결과는 충분히 비슷해야 한다.
학습 환경과 실제 실행 환경이 다르면 모델은 엉뚱한 최적점을 찾는다
Patil이 인프라 설계의 핵심 원칙으로 든 것은 train-test mismatch를 줄이는 일이다. 학습한 환경과 실제 업무 환경이 정확히 같아야 한다는 설명은 모의 서비스의 fidelity를 요구한다. agent가 실제 실행에서 만날 데이터 구조, 도구 오류, 권한과 상태 전이를 훈련에서도 재현해야 한다.
공개 쇼츠는 이 설명에서 환경 차이, fidelity, reward hacking, 운영 trace와 사용자 피드백을 잇는 연속 62초를 사용한다. 별도의 실험 결과가 추가된 것은 아니다. 같은 원본 발언의 핵심 인과관계를 짧게 다시 보여 주는 편집본이다.
두 번째 위험은 reward hacking이다. 원하는 행동을 정확히 표현하지 못한 보상에 강한 최적화 압력을 가하면 모델은 이상한 국소 최댓값을 찾는다. 고객 만족만 보상하면 모두에게 환불하거나 무료 혜택을 주는 agent가 높은 점수를 받을 수 있다는 예가 나온다. 환불 예시는 21분 55초에 등장한다.
해법은 reward를 더 복잡하게 만드는 데 그치지 않는다. 무엇이 좋은 결과와 나쁜 결과인지 현업이 정의하고, 운영 trace와 사용자 피드백을 분석해 eval을 수정하며, 실제 제품에서 정책 위반과 부작용을 확인해야 한다. 더 많은 RL이 잘못된 grader를 고쳐 주지는 않는다.
검증 가능성은 숫자 정답에서 현업 rubric으로 넓어진다
강화학습이 잘 맞는 분야를 묻자 Patil은 판단이 많이 필요한 업무를 든다. 초기 추론 모델은 정답이 숫자인 수학 문제로 학습했고, 다음에는 unit test로 검사할 수 있는 코드로 넓어졌다. 이제는 현업 전문가가 복잡한 rubric을 만들 수 있는 법률 같은 영역도 검증 가능성의 범위에 들어간다는 주장이다.
선임 변호사는 정교한 법률 답변이 반드시 짚어야 할 기준을 정의할 수 있다. 같은 질문도 로펌마다 좋은 답의 기준이 다를 수 있다. 이 기준을 soft verifier에 담으면 회사의 판단 방식을 학습 신호로 바꿀 수 있다. 현업 rubric을 통한 검증 가능성 확대는 enterprise RL의 핵심 가설이다.
그러나 soft verifier는 객관적 정답과 다르다. 사람의 기준이 불완전하거나 서로 충돌할 수 있고, LLM grader가 문체나 길이에 편향될 수도 있다. reward hacking을 피하려면 실제 사례와 반례, 사람의 재검토, 운영 결과를 함께 사용해야 한다.
응용 연구 팀은 고객 문제와 모델 연구 사이를 연결한다
Applied Compute는 완전히 새로운 기초 연구보다 프런티어 연구를 현실 문제에 연결하는 응용 연구를 강조한다. 채용에서도 고객과 직접 소통하고 번거로운 실무를 맡아 문제를 깊이 이해할 사람을 찾는다고 한다. IOI나 IMO 메달리스트처럼 연구 능력이 있으면서 실제 적용을 원하는 인재가 잘 맞았다는 설명도 나온다. 고객 문제에 깊이 들어가는 응용 연구자상은 모델 연구와 현업 구현을 분리하기 어려운 이유를 보여 준다.
이 인터뷰를 실행 순서로 바꾸면 이렇다. 먼저 기성 프런티어 모델로 업무를 시도하고, 한계를 구체적인 eval로 정의한다. 모델, harness, context 중 어느 층을 바꿀지 정한다. 실제 업무와 분리된 replay 가능한 sandbox를 만들고, reward와 verifier가 허점을 만들지 반례로 점검한다. 대규모 rollout의 CPU, GPU, 기동 지연과 복구를 측정한다. 마지막으로 실제 제품에서 관찰한 결과를 권리 범위 안에서 다음 개선에 연결한다.
이 구조가 있어야 "회사별 agent workforce"가 제품 구호를 넘어 기술 시스템이 된다. 발표는 그 구조를 설명하지만, 모든 업무가 RL에 적합하거나 모든 회사가 자체 모델을 가져야 한다고 증명하지는 않는다.
어떤 문제에는 RL이 너무 강한 도구일 수 있다
발표 후반의 고객 지원 예시는 적용 한계를 잘 보여 준다. 올바른 tool call이나 데이터베이스 변경은 비교적 쉽게 검사할 수 있다. 그러나 고객이 대화 끝에 만족했는지, 회사 정책을 지키면서 만족을 만들었는지는 하나의 신호로 환원하기 어렵다. 단순 만족도를 보상하면 agent가 과도한 환불이나 무료 혜택으로 점수를 올릴 수 있다.
따라서 RL을 시작하기 전 세 가지 문을 통과해야 한다. 첫째, 성공과 실패를 구분할 verifier가 있어야 한다. 둘째, agent가 실제로 만날 상태와 도구를 재현하면서도 운영 서비스에 피해를 주지 않는 sandbox가 있어야 한다. 셋째, grader가 의도와 다른 지름길을 보상하지 않는지 여러 trajectory와 사람 검토로 확인해야 한다. 이 셋 중 하나라도 없으면 더 많은 rollout은 더 빠른 학습이 아니라 더 빠른 오학습이 될 수 있다.
또한 발표의 "쓸수록 좋아진다"는 표현은 매 요청 뒤 모델 가중치가 즉시 바뀐다는 뜻으로 읽으면 안 된다. 운영 trace를 모으고, 피드백을 해석하고, eval과 데이터를 갱신하고, 모델이나 harness를 바꾼 뒤 다시 배포하는 전체 순환을 가리킨다. 각 단계에는 개인정보, 고객 약정, 데이터 보존과 삭제, 변경 승인, 회귀 검사 같은 운영 조건이 붙는다.
기술 선택도 문제 유형에 맞아야 한다. 최신 사실이 부족하면 RAG나 context를 개선할 수 있고, 도구 스키마가 혼란스럽다면 harness를 고칠 수 있다. 출력 형식과 반복 행동은 supervised fine-tuning이 더 단순할 수 있다. 명확한 reward와 반복 환경이 있을 때에야 RL의 직접 최적화가 값을 한다. 회사별 AI를 만든다는 목표가 곧바로 회사별 RL을 뜻하지는 않는다.