Rethinking Environments for Long-Horizon Work — Rayan Garg, Theta Software

URL: https://www.youtube.com/watch?v=2aS7aKoXn64 날짜: 2026-08-01 채널: AI Engineer

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

Theta Software의 공동창업자(CEO Rayan Garg, CTO)가 발표한 세션으로, ==현재 업계가 사용하는 "long horizon(장기 과업)" 정의와 벤치마크가 근본적으로 결함이 있으며, 진짜 모델 능력을 측정하려면 환경 복잡도·상태 변화·모호성을 갖춘 환경과 에이전트 기반 Judge/Rubric 시스템이 필요하다==는 것이 핵심 주장이다.

• METR의 "human-horizon"(사람 기준 소요시간) 지표와 모델 고유 지표(토큰 수, 스텝 수)는 각각 한계가 있어 둘 다 함께 봐야 한다
• 장기 과업 여부는 단순히 시간이 오래 걸리는가가 아니라, 이전 결정이 이후 결정에 영향을 주는 "상태 변화(state change)"와 "순차적 복잡도(sequential complexity)"가 있는가로 판단해야 한다
• 소프트웨어/금융처럼 결정론적 검증(deterministic verifier)이 불가능한 도메인에서는 Judge(critic model)와 Rubric이 필수이며, Judge 자체도 환경에 접근 가능한 "에이전트"로 설계해야 한다
• GDPval, ToolBench, Apex Agents 같은 기존 금융 벤치마크는 실제로는 long horizon이 아니고, 이미 포화(saturated) 상태이며, 다루는 영역도 지나치게 좁다

발표자들은 이 문제의식을 바탕으로 Theta Software가 자체 제작한 금융 도메인 데이터(평균 사람 소요시간 15시간짜리 과업 50개 샘플)를 예시로 들며, 현재 모델들이 이런 진짜 long horizon 과업에서는 여전히 크게 고전한다는 점을 보여주며 마무리한다.

---

1. Long Horizon을 어떻게 정의할 것인가

Long horizon은 고정된 이분법적 카테고리가 아니라 상대적인 스칼라(scalar) 지표이며, 1년 전의 long horizon과 지금의 long horizon, 1~2년 후의 long horizon은 전혀 다른 기준이 된다.

1.1. Human-horizon 접근 (METR 방식)

1. METR의 정의 방식

   1. 50% 임계값 방법론: 특정 모델이 "16시간 임계값"에 도달했다는 것은, 사람이 16시간 걸리는 과업을 그 모델이 50% 성공률로 해낼 수 있다는 뜻이다
   2. 엄밀한 측정 방법론 존재: "사람이 16시간 걸렸다"는 것을 어떻게 측정했는지에 대한 엄밀한 방법론이 있으나 발표에서는 세부사항은 생략

2. Human-horizon 접근의 한계

   1. 사람에게 어려운 것 ≠ 모델에게 어려운 것: 예를 들어 금융 분석가가 엑셀 파일 전체의 서식(색상 테마 등)을 일일이 고치는 작업은 사람에게는 며칠씩 걸리는 지루한 작업이지만, 모델은 파이썬 스크립트 한 번으로 순식간에 끝낼 수 있다 — 그런데 정작 사람 분석가는 파이썬 스크립트 작성법을 모르는 경우가 대부분이라 이런 방식을 기대하지 않는다
   2. 측정 방법론 간 비교 불가능성: "우리 과업은 평균 16시간짜리다", "우리는 20시간짜리다"라는 주장들은 전문가 숙련도 차이 등 방법론적 변수가 너무 많아 서로 비교하기 어렵다
   3. 최상위 인간 능력 근처로 갈수록 노이즈 증가: 상위 10%, 1%, 0.1% 인간만 할 수 있는 과업으로 갈수록 이 추정치는 점점 더 노이즈가 심해진다

1.2. 모델 고유(model-native) 접근

1. 관련 단위들: 트래젝토리에서 소비된 토큰 수, 스텝 수, 툴 콜(tool call) 횟수 등
   1. 모델/하네스 의존성으로 인한 노이즈: 어떤 모델을 쓰는지, 어떤 하네스를 쓰는지가 토큰 소비량에 큰 영향을 준다 (예: Codex 계열 모델은 Claude 계열보다 토큰 효율이 높다고 알려져 있음) — GPT 모델이 특정 과업에 50만 토큰을 쓴다고 해서 Claude 모델에서 얼마나 걸릴지는 알 수 없다
   2. 그럼에도 유용한 이유: 토큰 소비량은 AI 에이전트가 자율적으로 그 과업을 얼마나 어려워하는지 알려주는 중요한 신호다 — 장기 트래젝토리에서는 압축(compaction) 문제, 충분히 긴 스텝/트래젝토리 길이에서 일관성을 유지하지 못하는 문제 등을 다뤄야 한다
   3. 모델 세대 간 비교에 유용: 예를 들어 GPT-5.5가 컨텍스트 윈도우 확장이나 개선된 압축 엔드포인트 덕분에 이제 100만 토큰짜리 트래젝토리를 달성할 수 있다면, 이는 AI 에이전트가 얼마나 오래 자율적으로 작업할 수 있는지에 대한 기술적 프론티어를 잘 보여준다
   4. 사람과 직접 대응 안 됨: 사람은 "토큰" 단위로 사고하지 않으므로 한 과업이 사람에게 몇 토큰짜리인지는 말하기 어렵다

1.3. 종합적 접근이 필요한 이유

1. 둘 중 하나만으로는 불충분

   1. 모델 지표만 볼 때의 한계: 위에서 설명한 대로 모델/하네스 종속적이라 노이즈가 크다
   2. 사람 지표만 볼 때의 한계: 사람에게 오래 걸리는 일이 모델에게는 안 어려울 수 있고, 방법론 간 비교가 어려우며, 프론티어 인간 능력 영역으로 갈수록 추정이 노이즈투성이가 된다

2. 두 경로는 서로 다른 방식으로 발전 중

   1. 에이전트의 작동 방식은 사람과 별개의 경로로 발전한다: 에이전트가 사람보다 나은 지점, 사람이 에이전트보다 나은 지점의 병목이 서로 다르다
   2. 두 지표를 함께 봐야 전체 그림이 보인다: 사람 기준과 모델 기준 각각이 다른 그림을 그려주기 때문에, 하나만 봐서는 전체를 파악할 수 없다

---

2. 모델 능력을 어떻게 측정할 것인가 — 환경 설계의 3가지 축

발표자들은 "long horizon 과업만이 유일한 관심사가 아니다"라며, 모델 훈련용 환경과 과업을 만들 때 고려해야 할 더 근본적인 질문으로 넘어간다.

2.1. 환경 복잡도 (Environment Complexity) — 툴 조율(Tool Coordination)

1. 저복잡도 세계 vs 고복잡도 세계

   1. 과거의 저복잡도 세계: 에이전트가 코드베이스에서 파일 하나 또는 파일 세트 하나만 읽으면 되는 수준이었다
   2. 현재의 고복잡도 요구사항: 에이전트가 로그 파싱을 위한 Grafana(observability), CI/CD를 위한 GitHub, AWS CloudWatch, 데이터베이스 읽기/쓰기 등 다수의 서로 다른 툴을 조율해서 사용해야 한다

2. 상태 변화(state change) 관점의 환경 복잡도

   1. 정의: 과업이 진행되는 동안 환경이 얼마나 변화하는가의 정도
   2. 모든 long horizon 과업이 동등하지 않음: 서로 무관한 독립적 과업들을 인위적으로 이어붙여 "장기 과업"처럼 만들 수 있지만, 이는 모델 능력을 의미 있게 측정하지 못한다 — 핵심은 초기 결정이 이후 결정에 실제로 영향을 미치는가이다

2.2. 병렬 가능 복잡도 vs 순차적 복잡도

1. 병렬화 가능한(parallelizable) 복잡도 — 상태 변화가 적은 경우

   1. 구체 예시: 대형 코드베이스를 분석하는 에이전트가 여러 서브 에이전트를 스폰해서 여러 파일을 동시에 병렬로 살펴본 뒤 마스터 에이전트로 결과를 취합하는 경우 — 병렬화가 쉽다

2. 순차적(sequential) 복잡도 — 상태 변화가 큰 경우

   1. 구체 예시: 대시보드나 로그를 사용해야 하는 경우, 초기의 잘못된 쿼리나 오독(misread)이 다운스트림 스텝으로 계속 누적(cascade)되어 나중에 큰 결과 차이를 만든다 — 전적으로 툴을 어떻게 사용했는지, 환경 상태가 어떻게 변했는지에 달려 있다

2.3. 모호성 (Ambiguity)

1. 정의: 과업 시작 시점에 에이전트에게 주어지는 정보(지시문, 아티팩트 등)의 불완전성 정도

2. 모호성을 넣어야 하는 이유

   1. 사람의 실제 작업을 반영: 사람은 항상 완전한 정보를 갖고 시작하지 않으며, 탐색(exploration)을 통해 문제를 해결해 나간다 — 모델도 이런 아티팩트 탐색 능력을 시험해야 한다
   2. 트레이드오프: 모호성을 넣을수록 에이전트가 취할 수 있는 경로가 많아지고 "정답이 될 수 있는 방식"도 다양해지므로, 표준화된 평가(standardized evaluation)가 훨씬 어려워진다

---

3. Verifier(검증자)와 Judge 설계

발표에서 "환경 설계에서 가장 어렵고 뉘앙스가 많은 부분"으로 꼽은 주제. 에이전트가 한 작업이 맞았는지 어떻게 판단하고 훈련 과정에서 보상 신호를 줄 것인가에 대한 논의다.

3.1. 왜 Judge/Rubric이 필요한가

1. 배경: RL의 무게중심 이동

   1. 과거: 수학, 자료구조형 코딩 문제처럼 결정론적으로 검증 가능한(hard verifiable) 도메인에서 초기 RL의 성과가 나왔다
   2. 현재: 경제적으로 가치 있는 작업의 상당수는 "소프트웨어/파일 도메인"에 있는데, 여기서는 파이썬 스크립트를 돌리거나 테스트 케이스를 실행하거나 증명(proof)을 써서 정답을 확인하는 방식이 통하지 않는다

2. Judge/Critic 모델을 도입하는 이유

   1. 결정론적 검증자가 불가능한 문제 영역이 존재: 이런 영역에서 결정론적 verifier를 만드는 것은 비실용적이거나 취약(brittle)하거나 아예 불가능하다
   2. 트래젝토리 자체의 질을 봐야 함: 모든 솔루션과 그 경로가 동등하지 않다 — 최악의 경우는 리워드 해킹(reward hacking)이다. 예: 에이전트가 샌드박스를 탈출해서 코딩 과업의 숨겨진 테스트 스위트 같은 특권 정보를 미리 엿보는 행위. 이런 행동을 막으려면 verifier와 환경 설계를 강화해야 하고, Judge가 이런 행동을 잡아내는 데 결정적 역할을 한다
   3. 참조 답안 비교 방식의 한계: 초기의 단순한 Judge 접근은 참조 답안/샘플 트래젝토리를 주고 모델의 답과 일치하는지만 비교하는 방식이었는데, 모호하고 열린(open-ended) 과업에서는 정답이 너무 다양해서 모든 경우의 수를 커버하는 게 사실상 불가능하다 — 더 강건한(robust) 방법이 필요하다

3.2. 좋은 Judge를 설계하는 원칙

1. Judge도 에이전트다

   1. 하네스가 환경을 따라가야 함: 환경이 복잡해질수록 Judge의 하네스도 그 환경이 쓰는 새 툴들을 지원하고, 에이전트가 환경에서 일어나는 일을 명확히 관찰(observability)할 수 있어야 한다
   2. Judge도 결국 환경 상태를 직접 봐야 정확성을 판단할 수 있음: 에이전트용으로 설계한 하네스를 Judge용으로도 재사용하는 경우가 많다
   3. 구체 예시(배포 실패 시나리오): 소프트웨어 엔지니어링 과업에서 배포 실패가 발생 → 에이전트가 GitHub의 CI/CD 로그와 CloudWatch 로그를 살펴 원인을 파악 → 코드베이스에 변경사항 적용 → PR 오픈 → 머지 후 재배포까지 진행하는 과업이라면, Judge는 단순히 tool call 로그(신뢰도가 낮음)만 보는 게 아니라 실제로 GitHub 로그나 AWS 로그를 배포 이후 시점에서 다시 확인해서 실제로 제대로 작동하는지 검증해야 한다
   4. 중요한 안전장치: Judge가 에이전트 작업 완료 후 환경에 실수로 변형(mutation)을 가하지 않도록 해야 한다 — 예를 들어 읽기 전용(read-only) 권한을 강제하고, 재배포를 트리거하지 못하게 막는 등의 조치가 필요하다
   5. 트래젝토리만 봐서는 완료 여부가 명확하지 않은 경우가 많음 — 이런 경우 상태 자체를 봐야만 검증이 가능하다

2. 트래젝토리를 쿼리 가능(queryable)하게 만들기

   1. 단순히 컨텍스트 윈도우에 트래젝토리를 통째로 넣는 방식은 통하지 않음: 트래젝토리가 매우 길고 복잡해지므로, 이걸 그냥 기본적인 LLM 콜에 욱여넣는 식의 단순한 접근은 안 된다
   2. 더 사려깊은(thoughtful) 처리 필요: 트래젝토리를 데이터베이스에 저장하고, 서브 에이전트를 활용해 특정 정보를 보강(enrich)하며, 로그를 살펴보는 단계 / 코드를 작성하는 단계 / 이후 결과를 확인하는 단계처럼 특정 국면(phase)을 파싱해내는 작업이 필요하다
   3. 목적: 에이전트가 실패 지점(failure point) 같은 핵심 스텝을 찾아내고 그것이 실제 실패인지 검증할 수 있도록 만드는 것이 중요하다

3. 환경의 학습 가능성(learnability)

   1. 핵심은 보상 신호의 밀도(density): 이는 Rubric과 Judge가 그것을 어떻게 정의하는지에서 나온다
   2. Rubric 과밀 주의: 특히 모델이 아직 잘 못 하는 프론티어 문제에서 rubric에 밀도를 과도하게 넣으면 Judge가 이를 일관되게 적용하는 데 어려움을 겪는다 — Judge가 정보를 정확히 적용하는지 확인하는 QA가 많이 필요하다
   3. 기타 학습 가능성 요인: 과업의 분포(distribution)와 그 기저 데이터의 성질 등도 중요하게 측정하는 요소다 — 그렇지 않으면 모델이 실제로 학습할 수 없는 문제에 컴퓨트를 낭비하게 된다

4. 떠오르는 Rubric/Judge 패턴들 (간략 소개)

   1. 결정론적 verifier와 Judge의 병행: 결정론적 verifier가 완전히 죽은 것은 아니며, Judge가 검토할 아티팩트를 생성하거나 지표를 수집하는 용도로 함께 쓰인다
   2. 동적 평가시점 rubric(dynamic evaluation time rubric): 모델이 만든 일부 가정을 맞다고 전제하고 부분 점수를 주는 방식 — 마치 시험 채점에서 "1번 문제를 틀렸다고 치고, 그 전제 하에 나머지를 맞았는지" 채점하는 방식과 유사하며, 이는 크레딧을 정확히 배분하는 데 중요하다

3.3. Rubric에 대한 QA

1. 각 rubric마다 여러 종류의 테스트를 실행
   1. 기본 테스트: Gold 테스트, No-op variance 테스트 등 — 어떤 verifier든 기본적으로 고려해야 하는 테스트들
   2. AI가 rubric 생성/검증/전문가 보조에 관여할수록 테스트가 더 많이 필요함: 특히 과업이 더 long horizon이 될수록 더 그렇다
   3. 커버리지(coverage)와 전문가 일치도(expert agreement): 이 두 가지가 핵심 검증 축이다

---

4. 왜 이게 중요한가 — 현재 벤치마크의 문제와 Theta의 데이터

4.1. 3대 금융 벤치마크(GDPval, ToolBench, Apex Agents)의 결함

1. 문제 1: 실제로는 long horizon이 아님

   1. METR 기준 대비 미달: Meter가 정의한 프론티어 모델들의 "과업당 평균 사람 소요시간" 기준으로 봤을 때, 이 벤치마크들의 과업당 평균 사람 소요시간은 그 기준보다 훨씬 낮아서 실제로는 long horizon 과업으로 간주될 수 없다

2. 문제 2: 이미 포화(saturated)됨

   1. 원인: 과업당 평균 사람 소요시간이 짧다 보니 벤치마크가 이미 상당히 포화된 상태라는 게 다운스트림 효과로 나타난다
   2. Apex Agents의 IB(투자은행) 섹션 사례: pass@1 지표에서 57%의 케이스가 100% 완전히 해결됐다는 것은, 상당 부분의 과업이 이미 손쉽게 풀리고 있다는 뜻이다

3. 문제 3: 다루는 범위(breadth)가 좁음

   1. GDPval: 금융을 위한 엑셀 과업 세트가 매우 좁게 한정되어 있다
   2. Apex Agents: 투자은행(IB) 업무에 크게 편중되어 있다
   3. 결과: 신용(credit), 부채(debt), 리스크(risk) 등 금융 도메인에서 학습 가능성이 중요한 영역들이 제대로 커버되지 않는다

4. 문제 4: 보상 신호가 충분히 세밀하지 않음

   1. 필요 수준: 매우 세밀하고 구체적인 보상 신호가 필요하다 — Theta는 자체적으로 기준(criteria)당 서브기준(sub-criteria) 10~20개 수준의 세밀함을 사용한다
   2. 기존 벤치마크의 부족함: 이런 벤치마크들이 실제로 제공하는 보상 신호의 세밀함(granularity)에는 개선의 여지가 많이 남아있으며, 이는 모델을 실제로 훈련하는 데 중요한 요소다

4.2. Theta Software의 금융 데이터 통계

1. 데이터 규모와 난이도
   1. 사람 평균 소요시간: 50개 과업 샘플 세트 기준, 과업 1개를 완료하는 데 사람이 평균 15시간 걸린다
   2. 모델도 상당한 시간 소요: 모델이 이 과업들을 처리하는 데도 꽤 긴 시간이 걸린다
   3. 모델 성능 격차: 금융 관련 모든 도메인에서 종합적으로 봤을 때, 모델들은 이 과업들에서 여전히 크게 고전(struggle significantly)한다
   4. Mean@5 지표 제시: 앞서 언급된 기존 벤치마크 점수들과는 확연히 다른, 훨씬 낮은 수준의 mean@5 점수를 Theta 데이터에서 제시하며 발표를 마무리한다

---

주요 발언 모음

"What we consider long horizon a year ago probably isn't really long horizon in our definition today. And what's long horizon today probably won't be long horizon in a year or two."

"Not all long horizon tasks are equal... one task can maybe be made artificially long horizon by chaining together unrelated independent tasks. However, that doesn't actually meaningfully measure the model capabilities."

"Judges are agents too."

"You can't just use this really basic approach of taking the trajectory and stuffing it in the context window of the judge and kind of have it be a basic LLM call."

"If you look at the Apex agents IB section of this benchmark... pass at one effectively means that for like 57% of cases, the tasks are 100% solved. That is effectively telling us that there's a large part of these tasks that models are solving [too easily]."

핵심 데이터 & 수치

• METR 50% 임계값: 모델이 16시간 임계값에 도달했다는 것은, 사람이 16시간 걸리는 과업을 50% 성공률로 해낼 수 있다는 의미
• Apex Agents IB 섹션 pass@1: 57%의 케이스가 100% 완전히 해결됨 (벤치마크 포화의 근거)
• Theta 금융 데이터셋: 50개 과업 샘플, 과업당 평균 사람 소요시간 15시간
• Theta의 Rubric 세밀도: 기준(criteria)당 서브기준(sub-criteria) 10~20개 수준

결론 및 시사점

1. Long horizon은 단일 숫자가 아니라 다면적으로 정의해야 한다: Human-horizon(METR식)과 모델 고유 지표(토큰/스텝) 둘 다 각자의 한계가 있으므로, 하나만 보지 말고 종합적으로 판단해야 한다.
2. 진짜 장기 과업을 만들려면 단순히 시간을 늘리는 게 아니라 "상태 변화"와 "순차적 복잡도"를 설계해야 한다: 무관한 과업을 이어붙여 인위적으로 늘리는 방식은 모델 능력을 의미 있게 측정하지 못한다.
3. 모호성(ambiguity)을 의도적으로 설계에 포함시켜야 사람이 실제로 하는 탐색적 작업을 반영할 수 있다: 단, 이는 표준화된 평가를 어렵게 만드는 트레이드오프가 있다.
4. 결정론적 검증이 불가능한 소프트웨어/금융 도메인에서는 Judge/Rubric 시스템이 필수다: Judge는 반드시 환경에 (읽기 전용으로) 접근할 수 있는 "에이전트"로 설계되어야 하며, 트래젝토리를 쿼리 가능하게 만들어야 한다.
5. Rubric은 세밀할수록 좋지만 학습 가능성(learnability)과 균형을 맞춰야 한다: 프론티어 문제에서 지나치게 밀도 높은 rubric은 Judge가 일관되게 적용하기 어렵다.
6. 현재 업계 표준 금융 벤치마크(GDPval, ToolBench, Apex Agents)는 신뢰하기 어렵다: 실제로는 long horizon이 아니고, 이미 포화됐으며, 다루는 영역도 좁고, 보상 신호도 세밀하지 않다 — Theta의 자체 데이터(과업당 평균 15시간, mean@5로 훨씬 낮은 점수)가 이를 실증한다.