How long can your skills be before your agent forgets what you told it? — Laurie Voss, Arize AI

한 줄 핵심

프론티어 모델은 한 번에 따라할 수 있는 지시의 수가 1년 만에 10배가량 늘었지만, 이제의 핵심 문제는 용량이 아니라 모델이 정말로 지시를 지켰는지 검증하는 일이다.

시간별 요약

1. 0:00
   200개 지시 한계와 그 출처 에이전트가 따라야 할 규칙을 skills file에 많이 넣을수록 어느 순간 모델이 더 이상 전부를 추적하지 못하는 지점이 생기며, 이 한계가 대략 200개 수준이라는 주장이 문제의 출발점이다.
2. 1:49
   규칙을 실제로 지켰는지 알 수 없는 문제 큰 규칙 집합을 넣은 뒤 결과를 봐도 모델이 모든 조건을 따른 것인지, 아니면 대충 비슷하게 맞춘 것인지 판별하기 어렵고, 이 불안이 이 연구를 검증하게 만든다.
3. 2:58
   IFScale 벤치마크의 작동 방식 IFScale는 보고서에 특정 단어를 정확히 포함시키게 한 뒤, 주어진 규칙 수와 실제 준수율을 측정하는 단순한 방식으로 지시 추종 능력을 정량화한다.
4. 4:19
   작년 결과 재현 원래 벤치마크를 다시 돌려 GPT 4.1, Claude Sonnet 4, Gemini 2.5 Pro에서 비슷한 결과를 재현했고, 200~300개 규칙 부근에서 성능이 무너지는 기존 결론이 실제였음을 확인한다.
5. 6:12
   현재 모델에 같은 테스트를 적용 같은 테스트를 GPT 5.5, Claude Opus 4.7, Gemini 3.1 Pro, Deepseek V4 Pro에 적용하자 모두 너무 쉽게 통과해, 새로운 한계를 찾기 위해 규칙 수를 500에서 10,000까지 늘려야 했다.
6. 7:07
   1년 만에 10배 뛴 핵심 결과 프론티어 모델은 1년 사이에 동시에 추적할 수 있는 지시 수가 약 10배 늘어 2,000개 수준은 일반화됐고, 최고 성능 모델은 5,000개 부근까지 버티면서 예전의 200개 한계는 사실상 사라졌다.
7. 9:01
   네 모델, 네 가지 실패 방식 Deepseek 4는 단순히 잊고, Claude는 안전성 판단 때문에 일찍 거부하며, Gemini 3.1 Pro는 생각에 토큰을 다 써버려 출력이 비고, GPT 5.5는 반쯤 보고서를 쓴 뒤 테스트 자체가 어리석다고 판단하며 중단한다.
8. 14:27
   실무 워크플로에서 바뀌는 점 예전처럼 짧게 압축하고 하위 skills로 쪼갤 필요가 줄었고, 100~300개의 구체 규칙은 한 프롬프트에 직접 넣을 수 있지만, 이제는 가능 여부보다 비용과 지연이 감당할 만한지 따지는 문제가 더 중요해졌다.
9. 16:29
   이 테스트가 증명하지 않는 것들 이 벤치마크는 긴 skills file이 가능하다는 근거이지, 복잡한 지시를 일관되게 추론한다는 증명은 아니며, 같은 지시도 순서나 표현에 따라 성능이 크게 흔들릴 수 있어 검증과 모니터링이 여전히 필요하다.
10. 19:32
    용량은 늘었지만 신뢰성은 그대로 모델은 2,000개 지시를 잘 처리할 수 있어도 문구나 순서가 조금 바뀌면 급격히 불안정해질 수 있어, capacity 향상과 reliability 향상은 서로 다른 문제임이 드러난다.
11. 21:06
    압축은 해결됐고 검증은 남았다 이제는 프롬프트를 더 잘 압축하는 문제가 아니라, 모델이 실제로 지시를 지켰는지 매번 확인하는 검증 문제로 옮겨갔으며, 이를 해결하려면 eval과 출력 모니터링이 필수다.

실무 인사이트

• skills file과 시스템 프롬프트 설계는 이제 길이 최적화보다 검증 체계 설계에 더 많은 비중을 둬야 한다.
• 긴 지시를 한 번에 넣을 수 있게 됐더라도, 안전성 거부·침묵 실패·중간 포기 같은 실패 유형별 감시 로직을 따로 두는 것이 중요하다.
• 실무에서는 프롬프트가 길어질수록 비용과 지연을 함께 계산하고, 배포 전후에 eval로 회귀를 상시 점검하는 구조가 필요하다.