에이전트가 이전 지시사항을 잊어버리기까지 스킬이 얼마나 길어야 할까요? — 로리 보스, Arize AI

AAI Engineer
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00-
00:00:12좋습니다, 여러분 안녕하세요.
00:00:15이 유쾌하게 괴짜 같은 발표에 찾아주셔서 감사합니다.
00:00:20이 발표는 제목이 정말 깁니다.
00:00:22그러니 먼저 짧은 버전부터 말씀드릴게요.
00:00:23우리는 스킬 파일에 온갖 지시사항을 가득 채워 넣습니다.
00:00:27하지만 어느 순간부터 모델은 그 모든 걸 추적하지 못하게 되죠.
00:00:31그렇다면 그 한계점은 과연 어디일까요?
00:00:33스킬 파일에 지시사항을 몇 개나 넣어야
00:00:35너무 많아지는 시점이 될까요?
00:00:36그리고 그 답은 지난 1년 동안 정말 많이 바뀌었습니다.
00:00:40저는 로리이고, 어라이즈 AI에서 개발자 관계(DevRel) 총괄을 맡고 있습니다.
00:00:44이전에는 NPM Inc.를 공동 창업했고요.
00:00:46그래서 자바스크립트 시절을 통해 저를 아시는 분들도 계실 겁니다.
00:00:48요즘에는 AI와 이를 테스트하는 방법에 대해
00:00:50많은 시간을 고민하고 있습니다.
00:00:53몇 달 전, 저는 마이애미에서 열린 AI 엔지니어 컨퍼런스에 참석했습니다.
00:00:55아주 좋은 컨퍼런스였죠.
00:00:57거기서 덱스터 호시의 발표를 보게 되었습니다.
00:00:59좋은 발표였어요.
00:01:00물론 이 주제에 대한 이야기는 전혀 아니었지만요.
00:01:02하지만 그 발표를 하던 중에
00:01:04그가 지나가는 말로 이런 언급을 했습니다.
00:01:06에이전트는 지시사항을 잊어버리기 시작하기 전까지
00:01:10대략 200개 정도까지만 따를 수 있다고 하더군요.
00:01:13그러고 나서 그는 자신의 발표를 이어갔고,
00:01:15그건 말 그대로 가벼운 삼천포였습니다.
00:01:17그 수치가 2025년 기준이라서
00:01:20지금은 상황이 좀 나아졌을지도 모른다고 하더군요.
00:01:22하지만 저는 그 순간 귀를 의심하며 멍해졌습니다.
00:01:25지시사항 200개라니,
00:01:27그건 정말 얼마 안 되는 숫자 아니겠습니까?
00:01:31쓸만한 스킬 파일이라면 200개 정도의 지시사항은
00:01:33순식간에 훌쩍 넘겨버리니까요.
00:01:35사용자가 X라고 말하면 Y를 해라,
00:01:37Z에 관한 섹션은 항상 포함해라,
00:01:39W라는 표현은 절대 쓰지 마라.
00:01:40이런 것들이 전부 각각의 개별 지시사항입니다.
00:01:42그런데 모델이 200개가 넘어가면 조용히 추적을 멈춘다면,
00:01:45이건 우리가 구축할 수 있는 시스템의 복잡성에
00:01:47정말 가혹한 상한선을 긋는 셈입니다.
00:01:49그래서 저는 그 숫자가 어디서 나왔는지, 그리고 정말 사실인지
00:01:52확인해보고 싶었습니다.
00:01:55여러분도 제가 무슨 말 하는지 아실 겁니다.
00:01:57크고 멋진 스킬 파일을 작성하고 나면,
00:01:58수많은 규칙과 예외 케이스, 어조, 포맷 규칙들이 담기죠.
00:02:00그리고 이걸 에이전트에게 건넵니다.
00:02:01그럼 작업을 수행하죠.
00:02:03출력 결과를 보며 우리는 이렇게 생각합니다.
00:02:05정말 제대로 신경을 쓴 걸까?
00:02:07이 모든 규칙들을 빠짐없이 따르기는 한 걸까?
00:02:09아니면 그냥 대충 자기가 내키는 대로 하면서
00:02:11내가 기대했던 것과 비슷해 보이는 흉내만
00:02:14대충 낸 것에 불과할까?
00:02:16쉽게 알 수가 없죠. 정말 그럴까요?
00:02:18이건 나중에 더 다루겠습니다.
00:02:20그래서 우리는 실행 버튼을 누를 때마다
00:02:23이런 가벼운 불안감을 안고 살아가게 됩니다.
00:02:24바로 그 감정이 이번 연구를 시작하게 된 계기이자,
00:02:27우리가 과연 이를 피할 수 있을지 알아보려는 이유입니다.
00:02:30자, 이어지는 18분 동안 제가 여러분께 드리는 약속은 이렇습니다.
00:02:33그 200이라는 숫자가 어디서 왔는지,
00:02:36여전히 유효한지,
00:02:37그리고 오늘날의 실제 숫자는 얼마인지 보여드리겠습니다.
00:02:39자릿수가 완전히 달라졌거든요.
00:02:41그런 다음 그것이 여러분에게 시사하는 바가
00:02:44무엇인지 이야기해 보겠습니다.
00:02:46우리의 스킬과 프롬프트는 실제로 얼마나 길어야 하는지,
00:02:49그리고 그 결과로 워크플로우를
00:02:51어떻게 바꿔야 하는지요.
00:02:54이 200이라는 숫자는 단순한 풍문이 아닙니다.
00:02:57IfScale이라는 실제 벤치마크에서 나온 것인데,
00:02:59작년에 제가 이름도 제대로 발음하기 힘든 저자,
00:03:03야로슬라비치와 공동 저자들이 쓴 논문에서 비롯되었습니다.
00:03:06그리고 이 테스트는 놀라울 정도로 단순합니다.
00:03:10IfScale의 작동 방식은 이렇습니다.
00:03:12모델에게 비즈니스 보고서를 작성해 달라고 요청하면서,
00:03:14보고서에 반드시 포함해야 하는
00:03:16특정 단어 목록을 함께 제공합니다.
00:03:19정확히 '고객'이라는 단어를 넣고,
00:03:20정확히 '매출'이라는 단어를 넣는 식으로,
00:03:22원하는 만큼 단어를 추가하는 거죠.
00:03:24이 각각의 요구사항이 모두 따라야 할 지시사항이 됩니다.
00:03:27그런 다음 그 지정된 단어들이 실제로 몇 개나 들어갔는지 세어보는 겁니다.
00:03:32테스트가 이처럼 단순하기 때문에
00:03:34우리가 기억해야 할 숫자는 딱 두 가지뿐입니다.
00:03:36하나는 밀도로, n이라고 부르는 값입니다.
00:03:38이는 한 번에 다루는 규칙이 몇 개인지 나타냅니다.
00:03:41두 번째는 정확도인데,
00:03:42이는 그 규칙들 중에서 모델이 실제로
00:03:43제대로 지켜낸 비율을 뜻합니다.
00:03:46보고서에 무작위 단어를 포함시키는 것이 실제 지시사항을 따르는 것과
00:03:50같지 않다고 반박하실지도 모르겠습니다.
00:03:52그것도 맞는 말씀이고, 이 부분은 나중에 다룰 겁니다.
00:03:55하지만 키워드 테스트는 일종의 대용 지표입니다.
00:03:57'매출'이라는 단어를 넣으라는 요구는
00:04:01'가격 책정에 관한 섹션을 포함해라'와 같은 형태의 작업입니다.
00:04:02혹은 '이 표현은 절대 쓰지 마라'처럼요.
00:04:04이것들은 에이전트에게 지시한
00:04:06개별적이고 명확한 제약 조건들입니다.
00:04:09모델이 하나의 프롬프트 안에서 200개의 단어를 추적하지 못한다면,
00:04:11더 복잡한 200개의 지시사항이 주어졌을 때는
00:04:13분명히 훨씬 더 고전할 것입니다.
00:04:16그러니 좋게 봐줘도 결과는 더 나쁘면 나빴지 좋진 않을 겁니다.
00:04:20따라서 이 숫자는 일종의 상한선입니다.
00:04:22도달할 수 있는 가장 높은 한계치라는 말이죠.
00:04:23더 복잡한 지시사항을 부여한다면,
00:04:25그 수치는 아마 더 낮아질 것입니다.
00:04:27그리고 200개라는 건 정말 낮은 상한선입니다.
00:04:30그러므로 새로운 모델을 쫓아가기 전에
00:04:32제대로 된 과학적 검증을 거쳐야 합니다.
00:04:33즉, 기존의 결과를 그대로 재현해 보고
00:04:36200개라는 상한선이 실제로 맞는지 확인해야 한다는 뜻입니다.
00:04:39그래서 저는 원래의 벤치마크를 다시 실행해 보았습니다.
00:04:42원본 논문에서는 아주 다양한 모델들을 테스트했는데,
00:04:45AI 모델들은 세대 교체가 정말 빠르게 이루어집니다.
00:04:47제가 이 테스트를 직접 준비하고 실행할 시점에는,
00:04:50원래 사용되었던 10개의 모델 중
00:04:52단 3개의 모델만이
00:04:54어떤 형태로든 API를 통해 여전히 이용 가능한 상태였습니다.
00:04:57그 모델들은 GPT 4.1, 클로드 소넷 4,
00:04:59그리고 제미나이 2.5 프로였습니다.
00:05:0112개월 전에 출시되어 지금까지도
00:05:03살아남아 있는 모델들이었죠.
00:05:05그래서 그 세 모델을 테스트했던 것입니다.
00:05:07달리 남은 게 없었으니까요.
00:05:08그런데 제가 이 연구를 처음 발표한 지
00:05:11몇 주 지나지도 않았는데,
00:05:12저 세 모델 중 하나가 또 퇴출되었습니다.
00:05:14그러니 이번이 이 테스트를 돌려볼 수 있는
00:05:16말 그대로 마지막 기회였던 셈입니다.
00:05:17결국 그 라인업에서 벌써 둘만 남게 되었네요.
00:05:20그러니 특정 모델에 너무 정을 주지 마세요.
00:05:22자, 이것이 기존 IfScale의 연구 결과를
00:05:25그대로 재현하여 얻은 결과입니다.
00:05:27세로축은 정확도를 나타냅니다.
00:05:29100%에서 시작해서 점차 떨어지기 시작하죠.
00:05:32그리고 가로축은 로그 스케일로 표시된 규칙의 개수입니다.
00:05:35오른쪽으로 절반 갈 때마다
00:05:36다루어야 할 규칙의 수가 두 배씩
00:05:37늘어난다는 뜻입니다.
00:05:42따라서 규칙이 500개에 달하면 30%, 40%, 50%를 잃게 됩니다.
00:05:46우리 곡선은 원래 논문의 결과와 정확히 일치했습니다
00:05:49노이즈 범위 내에서 말이죠. 즉, 해당 현상은 실존했습니다.
00:05:521년 전만 해도 200개에서 300개 사이의 규칙만 들어가도
00:05:55최신 모델들이 무너지기 시작했습니다.
00:05:57정말 낮은 한계치였죠.
00:06:00이것이 우리의 기준점이고, 이제부터가 진짜 재미있는 부분입니다.
00:06:03정확히 똑같은 테스트를 가지고
00:06:05현재의 최신 기술 수준을 시험해 보았습니다.
00:06:07정확히는 제가 이 테스트를 실행했을 당시의
00:06:09최신 기술 말입니다.
00:06:10그래서 GPT 5.5, 클로드 오푸스 4.7을 돌려봤는데
00:06:134.8 버전은 이 테스트를 실행하고 일주일 뒤에 나왔거든요.
00:06:17제미나이 3.1 프로와 딥시크 V4 프로도 함께 테스트했습니다.
00:06:20동일한 프롬프트와 동일한 단어들을 주고
00:06:22모든 것을 같게 설정하자마자 바로 문제가 생겼습니다.
00:06:25모델들이 전부 만점을 받아버린 겁니다.
00:06:27이 테스트에서 즉시 전원 100점을 기록했고
00:06:30버그도 전혀 없었습니다.
00:06:34한계를 찾기 위해 테스트를 만들었더니
00:06:36모델들이 그 한계가 존재한다는 것조차 눈치채지 못한 채
00:06:37그냥 곧바로 통과해 버렸습니다.
00:06:40이건 문제였습니다. 왜냐하면 벤치마크가
00:06:42500단어에서 상한선을 찍도록 설계되었기 때문에
00:06:43새로운 한계를 찾아내기 위해서는
00:06:45벤치마크를 수정해야만 했거든요.
00:06:47그래서 기준을 바꾸어 포함해야 할 단어 수를 늘렸습니다.
00:06:50500단어에서 1,000단어로 두 배 늘리고
00:06:521,000단어에서 2,000단어로 또 두 배 늘렸으며
00:06:5510,000단어 어휘 수준에 도달할 때까지
00:06:56계속 그렇게 밀어붙였고, 비로소 요즘 모델들이 할 수 있는
00:07:00작업의 한계를 발견하기 시작했습니다.
00:07:03자, 화면에 띄워보겠습니다. 이게 핵심 슬라이드이자 결과입니다.
00:07:06결과 화면입니다.
00:07:07기억하시겠지만, x축은 로그 스케일로 되어 있습니다.
00:07:12즉 500에서 1,000, 5,000, 10,000으로 증가합니다.
00:07:16그래프가 낭떠러지로 떨어지는 것처럼 보이지만
00:07:18실제로는 1,000개 정도의 숫자 구간에 걸쳐 일어나는 일입니다.
00:07:20하지만 이 새로운 곡선들이 꺾이기 전까지 얼마나 우측으로
00:07:25뻗어 나갔는지 보십시오.
00:07:261년 전만 해도 200~300개 지시사항에서 무너졌는데
00:07:29이제 모델에 따라 한계선이 2,000개에 가까워졌고
00:07:32가장 뛰어난 모델의 경우 낭떠러지로 떨어지기 전까지
00:07:36무려 5,000개의 지시사항을 처리합니다.
00:07:38즉, 약 12개월 만에 최신 모델들은 동시 지시사항 수행 능력이
00:07:41거의 10배 가까이 향상되었습니다.
00:07:44이것이 핵심 결과이며, 우리가 파고들어야 할
00:07:47많은 미묘한 차이점들이 있습니다.
00:07:49단일 프롬프트에서 2,000개의 명명된 제약 조건을 추적하는
00:07:53역량이 생긴 것입니다.
00:07:55정말 흥미로운 부분입니다. 왜냐하면 제 생각에는,
00:07:57다른 분들도 다 그렇게 느끼시는지 모르겠지만
00:07:59제 느낌상으로는, 예를 들어 GPT 5.1에서 GPT 5.5로의 도약은
00:08:04다소 점진적인 발전처럼 느껴졌거든요?
00:08:0710배나 좋아졌다는 체감은 들지 않았는데
00:08:09이 테스트는 '내 스킬 파일이 얼마나 길어질 수 있는가'와 같은
00:08:14아주 실용적인 측면에서 진정으로 중요한 의미를 지닙니다.
00:08:17그리고 불과 1년 만에 우리는 10배 더 좋아졌습니다.
00:08:21제가 놀라는 점은 이 벤치마크가
00:08:23겨우 1년밖에 안 되었다는 사실입니다.
00:08:251년이 지난 지금 500이라는 숫자는 오차 수준에 불과하며
00:08:27기준점은 계속 제 발밑에서 움직이고 있습니다.
00:08:294.7을 테스트했더니 오푸스 4.8은 심지어 더 뛰어납니다.
00:08:35따라서 이 차트는 벌써 약간 구식이 되어버렸고
00:08:36바로 그것이 핵심입니다.
00:08:37만약 스킬 파일이 어떻게 작동해야 하는지에 대한
00:08:39엔지니어링 가정이나
00:08:41프롬프트가 얼마나 길어야 하는지에 대한 가정을
00:08:446개월 이상 전에 세우셨다면
00:08:46지금은 그 가정이 틀렸으며
00:08:48작업 방식을 재설계해야 할 것입니다.
00:08:52하지만 이 이야기에는 뒷부분이 더 있습니다.
00:08:54모델들이 실패하는 방식이
00:08:59극적으로 변했으며
00:09:00그 실패 방식이 매우 중요하기 때문입니다.
00:09:02이 부분은 실험을 시작할 때 전혀 예상치 못했던 발견이었으며
00:09:06처음에는 제 테스트를 완전히 엉망으로 만들었습니다.
00:09:07왜냐하면 과거의 실패 양상은 지루했기 때문입니다.
00:09:10그냥 지시사항을 잊어버렸고 저는 그들이 얼마나 많은
00:09:13지시사항을 기억하거나 잊었는지
00:09:14측정할 수 있었거든요.
00:09:16하지만 새로운 모델들은 자신들만의 기이하고
00:09:17아주 독특한 방식으로 무너집니다.
00:09:20그러니 이 네 가지 모델이 어떻게 실패하는지 소개해 드리죠.
00:09:22딥시크 4는 전통적인 모델입니다.
00:09:26그냥 내용을 잊어버릴 뿐입니다. 별다른 드라마가 없습니다.
00:09:29그냥 까먹습니다.
00:09:30별다른 드라마가 없습니다.
00:09:31750개 정도의 규칙부터 지시사항을 잊어버리기 시작하더니
00:09:352,000개가 되면 거의 절반을 빠뜨립니다.
00:09:38즉 그냥 까먹는 것인데, 솔직히 이건 예측 가능하기 때문에
00:09:41제가 가장 신뢰하는 실패 양상입니다.
00:09:43측정하기 매우 쉽죠.
00:09:44하지만 다른 모델들은 그렇게 협조적이지 않았습니다.
00:09:48오푸스 4.7은 반복해서
00:09:52테스트가 위험하다고 판단하곤 했습니다.
00:09:54그리고 어떻게 하냐면 API 수준에서
00:09:57테스트 완료를 거부해 버립니다.
00:09:59클로드로부터 그런 API 응답이 온다는 걸 몰랐어요
00:10:01마치 '아니, 할 수는 있지만 안 하겠어'라는 식의
00:10:03응답 말입니다.
00:10:06하지만 그것은 클로드가 지원하는 확실한 API 수준의 응답입니다.
00:10:09그들이 안전을 워낙 중요하게 생각하기 때문이죠.
00:10:10그래서 저는 그런 응답을 끊임없이 받기 시작했습니다.
00:10:13그런 일이 일어난 이유는
00:10:15클로드의 안전 분류기가 매우 민감하기 때문입니다.
00:10:16클로드의 안전 분류기가 매우 민감하기 때문입니다.
00:10:19만약 특정 단어 조합을 입력하면, 예를 들어
00:10:22탄저균이나 시안화물 같은 단어 말입니다.
00:10:24요청 전체가 위험하다고 판단하고
00:10:26발을 빼버립니다.
00:10:27제 테스트가 무엇을 하는지 기억하신다면 아시겠지만
00:10:29제 테스트는 5,000개에서 10,000개의 무작위 단어를
00:10:33지시사항 파일에 집어넣는 것입니다.
00:10:35그래서 무작위로 선택된 단어들 속에는
00:10:38안전 필터가 볼 때 조합상 위험해 보이는
00:10:39온갖 종류의 단어가 포함되어 있었습니다.
00:10:41그래서 제가 폭탄을 만들거나 하라고 요구하는 줄 알고
00:10:43계속 거부했던 것입니다.
00:10:47따라서 클로드가 협조하게 만들기 위해서 저는 모든 단어를 가져와서
00:10:52모든 단어를 가져와서
00:10:54오픈에이아이의 안전 필터에 통과시켜
00:10:56문제 있어 보이는 단어들을 모두 걸러내야만 했습니다.
00:10:58어디든 진행할 수 있었죠.
00:10:59일단 그렇게 조치하자 클로드는 정말 잘해냈습니다.
00:11:03하지만 실패 양상이라는 게, 클로드는 아주 이른 시기부터,
00:11:05예를 들어 지시사항이 단 200개나 300개일 때조차도
00:11:08예를 들어 지시사항이 단 200개나 300개일 때조차도
00:11:11하고 있는 작업에
00:11:13의학적 조언과 관련된 내용이 조금이라도 포함되어 있으면
00:11:15당신의 행동이 위험하다고 판단할 가능성이 더 높습니다.
00:11:17의학적인 것은 종종 이중 목적을 띠기 때문입니다. 위험할 수도 있고 안전할 수도 있죠.
00:11:20세 번째 실패 양상은 제미나이 3.1 프로였습니다.
00:11:24제미나이는 5,000개의 지시사항까지 아주 견고합니다.
00:11:28정말 훌륭하게 해냅니다.
00:11:30차트에서 단연 최고 중 하나입니다.
00:11:32그러다 그 선을 넘어가면 이상해집니다.
00:11:35지시사항을 잊어버리는 게 아닙니다.
00:11:37지시사항들에 압도당하는 것입니다.
00:11:39이 모델이 하려는 것은, 모든 지시사항을 한 번에 잘 따르고 있는지
00:11:44확인하기 위해
00:11:45생각 토큰을 사용합니다.
00:11:46그러다 지시사항 개수가 정말 많아지면
00:11:48모든 사고 토큰을 소비해 버립니다.
00:11:50사고하는 데 전체 토큰 예산을 다 써버린 나머지
00:11:53정작 출력을 내놓지 못하게 됩니다.
00:11:55말하자면 이런 식이죠.
00:11:57만약 1만 토큰 분량을 주면
00:11:599,500토큰 분량만큼 생각을 하다가
00:12:02딱 500단어 분량의 응답만 내놓는데,
00:12:04그 응답에는 요구사항이 하나도 안 들어있죠.
00:12:07결국 스스로 생각을 너무 많이 한 나머지 진퇴양난에 빠져서
00:12:09실제로 답변할 공간이 부족해지는 겁니다.
00:12:10비용도 엄청나게 들고 전혀 쓸모가 없죠.
00:12:13왠지 Gemini답지 않나요?
00:12:19물론 제 입으로 직접 이런 말은 안 하겠지만요.
00:12:23그리고 대망의 승자는 바로 GPT 5.5입니다.
00:12:26GPT 5.5는 단연 최고였으며 99%의 정확도를 기록했고
00:12:295,000개의 규칙까지 완벽하게 소화했습니다.
00:12:32하지만 한계까지 밀어붙이면
00:12:33이 중에서 가장 기괴한 모습을 보여줍니다.
00:12:35처음부터 딱잘라 거부하지도 않고
00:12:37조용히 잊어버리지도 않거든요.
00:12:38대신 어떤 식으로 나오냐면, 짜증을 내면서
00:12:41테스트가 멍청하다고 따집니다.
00:12:45일단 보고서를 쓰기 시작해요. 몇 가지는,
00:12:47그러니까 이게 무슨 말이냐면
00:12:48처음부터 안 한다고 딱 잡아떼는 게 아니에요.
00:12:50보고서를 시작하긴 합니다.
00:12:51보고서 작성을 시작해요.
00:12:52그러다 보고서를 한 500단어쯤 썼을 때즈음
00:12:54“아니, 이거 너무 멍청한데” 하는 식이죠.
00:12:55“나 이거 안 해” 이러는 겁니다.
00:12:56그리고는 아주 정중하게 이거 멍청하다고 말해줘요.
00:12:58“나 이제 더는 안 할 거야”라고요.
00:13:00실제로 제게 보낸 답변이 바로 이거였습니다.
00:13:02하지만 이건 제가 시킨 비즈니스 보고서 작성의 5,000단어 중
00:13:05내가 작성하라고 시켰던.
00:13:08생각해보면 틀린 말도 아니에요, 그렇죠?
00:13:10아무 주제나 상관없이 무작위 단어 5,000개가 들어간
00:13:12일관성 있는 비즈니스 보고서를
00:13:14작성해 달라고 요구했으니 말입니다.
00:13:17네 말이 맞다, GPT야.
00:13:19정말 터무니없는 걸 요구하긴 했어.
00:13:23분명 대단히 무리한 요구이긴 했고
00:13:25GPT는 그 점을 정확히 짚어냈습니다.
00:13:27하지만 테스트 통과 관점에서는 여전히 실패입니다.
00:13:29절반만 완성된 채 건네받은 보고서에는
00:13:31대부분의 키워드가 빠져 있을 뿐더러
00:13:32이 실패 유형이 가장 알아차리기도 어렵거든요.
00:13:35Claude는 즉시 발을 빼니까요.
00:13:36Claude는 아니,
00:13:37이건 안 하겠다고 딱 잘라 말합니다.
00:13:39DeepSeek도 할 수 있는 최선을 다하죠.
00:13:41하지만 GPT는 제법 잘 해내는 것처럼 굴다가도
00:13:44보고서 맨 끝부분에 가서는 이렇게 말합니다.
00:13:46“아니, 솔직히 이건 너무 멍청해서
00:13:47여기서 그만두겠습니다”라고요.
00:13:51네 가지 모델을 한데 놓고 비교해 보면 이렇습니다.
00:13:53DeepSeek은 조용히 잊어버리고,
00:13:54Claude는 겁을 먹고 거부하며,
00:13:56Gemini는 생각을 너무 많이 한 나머지 침묵에 빠집니다.
00:13:58그리고 GPT 5.5는 절반쯤 일을 끝내놓고서는
00:14:00나머지는 자기 수준에 안 맞는다고 타박하는 식이죠.
00:14:04요점은 이 중 어떤 모델이 제일 웃기냐가 아닙니다.
00:14:07비록 실제로도 꽤 웃기긴 하지만요.
00:14:09진짜 요점은 '내 지시를 잘 따랐는가'에 대한
00:14:12실패 양상이 더 이상 한 가지가 아니라는 점입니다.
00:14:14실패하는 방식만 무려 네 가지로 나뉩니다.
00:14:16게다가 지금 상대하는 모델이 무엇이고 어떤 패턴으로
00:14:19실패하는지 정확히 알지 못하면 그 실패를 알아차릴 수도 없죠.
00:14:23모델들의 성능은 10배나 좋아졌지만
00:14:27실패하는 모습도 참 별나졌습니다.
00:14:29그렇다면 여러분이 자리로 돌아갔을 때 왜 이 점을 신경 써야 할까요?
00:14:31여러분의 워크플로우에 세 가지 변화가 생겼기 때문입니다.
00:14:34첫째로, 1년 전만 해도 현명한 방법은 모든 스킬 파일을 아주 짧게 유지하는 것이었습니다.
00:14:39지시사항을 200개 이하로 제한한 다음, 하위 스킬들이나 복잡하게 얽힌 추가 스킬 파일, 서브 파일 등으로 연결하는 식이었죠.
00:14:50제한된 공간에 억지로 맞추려고 지시를 압축하곤 했는데, 이제는 그럴 필요가 없어졌습니다.
00:14:57이제 스킬 파일은 아주 길어져도 됩니다.
00:14:59둘째로, 구체적인 규칙이 100개나 300개 정도 필요하다면 그냥 프롬프트에 전부 넣어도 됩니다.
00:15:06모델이 어떤 규칙을 조용히 무시했을지 밤잠 설치며 고민할 필요가 없다는 뜻이죠.
00:15:12여러분도 모델을 직접 사용해 본 경험을 떠올려보면 이미 체감하셨을 겁니다.
00:15:21모델들이 프롬프트를 따르는 능력이 정말로 10배 좋아졌기 때문에 프롬프트가 길어지는 것에 대한 부담이 확실히 줄어들었을 겁니다.
00:15:322,000개의 명시적 제약 조건이면 그 자체로 완벽한 스타일 가이드나 다름없습니다.
00:15:35모든 브랜드 규칙과 온갖 법적 고지 사항을 다 담을 수 있죠.
00:15:381년 전이었다면 이걸 수십 개의 특화 에이전트로 쪼갠 다음, 서로 원활하게 인수인계가 되기를 기도해야 했을 겁니다.
00:15:46하지만 이제는 그런 신경을 꺼도 됩니다.
00:15:48그리고 세 번째 변화가 가장 큽니다.
00:15:50예전에는 '모델이 과연 이걸 해낼 수 있을까?'가 늘 문제였습니다.
00:15:53하지만 이제는 확실히 '그렇다'고 말할 수 있습니다.
00:15:55물론 꽤 확실하게 말이죠.
00:15:58이제 새로운 질문은 '과연 그 비용을 들일 가치가 있는가?'입니다.
00:16:01프롬프트에 1만 개의 서로 다른 지시사항을 넣을 수는 있지만, 그렇게 되면 프롬프트가 엄청나게 거대해질 테니까요.
00:16:07비용도 어마어마하게 비싼 프롬프트가 될 겁니다.
00:16:09처리 속도도 아주 느려질 거고요.
00:16:10따라서 예전에는 부딪히기만 하면 막히던 높은 벽이, 이제는 '비용과 지연 시간이 더 늘어날 만큼 이 모든 추가 지시를 넣을 가치가 있는가'라는 완만한 트레이드오프로 바뀌었습니다.
00:16:19자, 이제 Q&A에 앞서 몇 가지 주의 사항을 짚어보겠습니다.
00:16:25첫째로 가장 중요한 건, 아까도 말씀드렸듯 가짜 비즈니스 보고서에 무작위 단어를 집어넣는 이 프록시 작업은 긴 스킬 파일이 작동한다는 방증일 뿐입니다.
00:16:38긴 스킬 파일이 무조건 통한다는 완벽한 증거는 아니라는 뜻이죠.
00:16:41또한 모델마다 한계에 부딪히는 지점이 750개에서 9,000개 이상까지 제각각이므로 모델을 아주 신중하게 선택해야 합니다.
00:16:49우리 테스트에서 측정하지 못한 부분은 거대한 프롬프트 위에서 모델이 과연 명확하게 추론을 수행했는가 하는 점입니다.
00:16:57다행인 점은, 제가 몇 주 전에 이 연구를 마친 이후 많은 분들이 이 주제에 뛰어들어 현재는 훌륭한 연구들이 많이 나와 있다는 것입니다.
00:17:05전문 연구자들이 직접 참여하여 Chroma에서 18개 모델을 대상으로 컨텍스트 저하(Context Rot) 연구를 진행한 결과, 긴 입력에 대한 정확도가 컨텍스트 윈도우 한계에 도달하기도 전에 30~50%까지 떨어질 수 있음이 밝혀졌습니다.
00:17:21그들의 연구 결과에서 흥미로웠던 점은, 지시사항을 무작위 순서로 뒤섞어 넣었을 때보다 논리적이고 구조화된 텍스트일수록 오히려 이러한 실패 유형을 겪을 가능성이 더 높다는 것이었습니다.
00:17:33왜 그런 현상이 발생하는지는 저도 그들의 보고서를 더 읽어봐야 알 수 있겠네요.
00:17:37즉, 모델이 2,000개, 5,000개, 심지어 10,000개의 지시사항까지 추적할 수는 있어도 그 내용을 바탕으로 반드시 명확하게 추론해 낸다고 보기는 어렵습니다.
00:17:46지시사항들끼리 서로 충돌하거나 긴장 관계가 존재할 때, 모델이 그것을 올바르게 처리하리란 보장이 없다는 뜻이죠.
00:17:53그리고 아까 잠시 언급했던 다른 문제도 있습니다.
00:17:56Claude의 거부 반응은 짜증 나긴 하지만 적어도 티가 확 납니다.
00:18:00에러가 나기 때문에 실패했다는 걸 바로 알 수 있죠.
00:18:02하지만 GPT의 정중하고 절반만 끝마친 보고서는 진짜 답변처럼 보여서 훨씬 더 위험합니다.
00:18:07중간에 조용히 포기했다는 사실을 눈치채려면 처음부터 끝까지 다 읽어봐야 하므로 출력 결과 전체를 신뢰할 수 없게 됩니다.
00:18:13결국 제대로 작동했는지 확인하려면 매번 출력을 일일이 읽어봐야 한다는 의미죠.
00:18:17결국 모델은 여러분의 규칙 2,000개를 받아들이고는 적어도 겉보기에는 자신 있고 그럴듯하지만 중간에 슬쩍 포기해 버린 결과물을 건네줄 수도 있습니다.
00:18:30참고로, 다들 이 모든 작업을 하는 데 비용이 얼마나 들었는지 항상 물어보시는데요.
00:18:34이 모든 쿼리를 실행하는 데 총 209달러가 들었습니다.
00:18:377개 모델에 걸쳐 2,300번 호출을 했는데 209달러밖에 안 나왔죠.
00:18:43새로운 연구를 수행하는 데 생각보다 비용이 많이 들지 않는다는 뜻입니다.
00:18:46그리고 이 대목은 바로 프로덕션 환경에서 이런 내용을 직접 검증해야 한다고 강조했던 부분입니다. 모델이 조용히 실패하지 않는다고 장담할 수 없으니까요.
00:18:55제가 Arise에서 일하고 있고 또 거기서 그런 일을 하다 보니 결국 평가(eval) 얘기를 꺼낼 줄 다들 아셨을 겁니다.
00:19:01그렇다고 Arise 홍보를 장황하게 하려는 건 아닙니다.
00:19:03딱 한 가지 진실만 말씀드리자면, 실제 AI 애플리케이션을 구축하고 있고 정말 까다로운 작업을 맡기고 있다면
00:19:10프론티어 모델을 쓰면서 방금 말씀드린 실패 유형 중 하나 이상을 반드시 겪게 될 것입니다.
00:19:14API 레벨에서 Claude가 아예 욕을 하며 거절하는 경우가 아니라면, 무언가 잘못되었다는 것을 알아내는 유일한 방법은 다른 LLM으로 출력을 모니터링하는 것뿐입니다.
00:19:23그게 바로 평가(eval)이고 Arise가 하는 일입니다. 설명은 이쯤에서 줄이겠습니다.
00:19:27우리 연구 이후로 새로운 연구들이 또 나왔다고 앞서 말씀드렸죠.
00:19:30여기에 또 다른 중요한 연구가 있습니다.
00:19:3146개의 모델을 테스트한 '언어 모델의 지시 따르기 신뢰성 재방문(Revisiting the Reliability of Language Models in Instruction Following)'이라는 논문이 발표되었는데요.
00:19:37직접 그런 연구를 해봤던 저로서는 이 논문 소식을 듣자마자 귀가 번쩍 뜨일 수밖에 없었습니다.
00:19:41연구진은 꽤 뼈아픈 사실을 발견했습니다. 모델이 우리 같은 벤치마크에서 만점을 받더라도 여전히 엄청나게 불안정할 수 있다는 점이었죠.
00:19:47동일한 지시사항을 미묘하게 다른 방식으로 다시 표현하기만 해도 지시를 따르는 성능에 극적인 차이가 발생할 수 있기 때문입니다.
00:19:56모델이 2,000개의 지시를 완벽하게 따를 수 있더라도
00:20:00그 동일한 2,000개의 지시사항 순서를 다르게 배치하는 것만으로도 모델의 지시 이행 능력이 갑자기 형편없어질 수 있습니다.
00:20:08혼란스러워하는 것 없이 모델이 지시를 완벽하게 따르도록 하려면 지시사항을 정확히 어떤 순서로 배치해야 하는지에 대해서는 여전히 연구가 진행 중인 영역입니다.
00:20:19요약하자면 처리 용량은 늘어났지만 신뢰성은 여전히 해결해야 할 문제입니다.
00:20:24이건 제가 기뻐서 하는 가벼운 자랑이지만, 저는 과학자가 아니라 그저 약간의 연구를 해본 사람일 뿐입니다.
00:20:31그런데 그 후에 진짜 과학자들이 대거 뛰어들어서 똑같은 의문에 대해 본격적인 과학적 연구를 수행하더군요.
00:20:36이제 이 동일한 질문을 측정하기 위해 생겨난 벤치마크들도 아주 많아졌습니다.
00:20:40Firebench, CCRbench, Guidebench 등이 모두 같은 것을 측정하려고 시도하고 있죠.
00:20:44모델들이 수많은 실제적이고 복잡한 제약 조건을 한꺼번에 얼마나 잘 따르는가 하는 점 말입니다.
00:20:49이제 업계 전체가 이 문제를 주목하고 있으니, 제 엉성한 '1만 개의 무작위 단어' 실험보다 훨씬 더 수준 높은 진짜 과학적 연구 결과를 찾아보실 수 있을 겁니다.
00:20:58자, 이제 오늘 제가 드리고 싶은 결론으로 넘어가겠습니다.
00:21:001년 전만 해도 스킬 작성에서 가장 힘든 부분은 모델이 맥락을 잃지 않도록 모든 것을 억지로 우겨넣는 것이었습니다.
00:21:05그건 압축의 문제였고, 이제 그 압축 문제는 해결되었습니다.
00:21:08이제 모델은 여러분의 지시 2,000개를 거뜬히 소화해 냅니다.
00:21:11새롭게 어려워진 부분은 모델이 실제로 지시한 대로 수행했는지를 파악하는 것, 즉 검증의 문제입니다.
00:21:16검증의 문제는 더 나은 프롬프트를 작성한다고 해서 해결되지 않습니다.
00:21:20다른 코드를 테스트하듯 매번 출력 결과를 확인하는 방식, 즉 평가(eval)를 통해 해결해야 합니다.
00:21:26기술의 한계선이 1년 만에 10배나 뛰어올랐습니다.
00:21:29그러니 프롬프트가 얼마나 길어져야 하는지, 지시사항이 얼마나 커져도 되는지에 대해 6개월 전에 세웠던 가정들이 이미 틀렸을 수도 있으니 꼭 다시 확인해 보시기 바랍니다.
00:21:41오늘 발표는 여기까지입니다.
00:21:42모든 코드와 데이터를 확인하고 싶으신 분은 이 깃허브 URL을 참고해 주세요.
00:21:48그리고 이 다른 QR 코드는 마케팅 팀에서 억지로 넣으라고 한 겁니다.
00:21:51오늘 저녁 5시에 월드컵 시청 파티가 있을 예정입니다.
00:21:55저희 파티에 놀러 오셔도 좋습니다.
00:21:56저 링크는 파티 신청 페이지인 Luma로 연결됩니다.
00:22:01오늘 제 발표가 여러분께 참신한 정보나 소소한 웃음을 드렸기를 바라며, 경청해 주셔서 정말 감사합니다.
00:22:07감사합니다.
00:22:08감사합니다.

핵심 요약

AI 모델의 동시 지시사항 처리 용량이 1년 만에 10배 늘어나 최대 5,000개까지 확장되었으므로, 이제는 긴 프롬프트 작성보다 출력 결과를 검증하는 평가(eval) 작업이 핵심 과제이다.

하이라이트

  • 최신 AI 프론티어 모델은 단일 프롬프트에서 최대 5,000개의 명시적 제약 조건을 동시에 추적할 수 있다.

  • 과거 IfScale 벤치마크 기준 200~300개였던 지시사항 상한선이 1년 만에 약 10배 향상되었다.

  • 모델들이 실패하는 방식은 단순 누락, API 수준의 안전성 거부, 과도한 사고 토큰 소모, 중간 포기 등 네 가지 양상으로 갈린다.

  • 프롬프트에 7개 모델을 대상으로 2,300번 호출을 수행하는 데 총 209달러의 비용이 소요되었다.

  • 지시사항의 순서 배치나 미묘한 표현 변경만으로도 모델의 지시 이행 신뢰성이 급격히 저하될 수 있다.

타임라인

지시사항 한계에 대한 의문과 배경

  • 에이전트가 지시사항을 잊어버리기 전까지 따를 수 있는 한계는 약 200개로 알려져 있었다.
  • 기존 IfScale 벤치마크는 비즈니스 보고서에 특정 단어 목록을 얼마나 포함하는지 측정한다.
  • 모델 세대 교체가 빠르게 일어나면서 1년 전 모델 대부분이 API에서 퇴출되었다.

스킬 파일에 수많은 규칙과 예외 케이스를 넣을 때 모델이 이를 실제로 전부 추적하는지 확인하는 과정에서 연구가 시작된다. IfScale 벤치마크는 단어 포함 여부를 개별 지시사항으로 상정하여 모델의 상한선을 측정하는 도구이다.

최신 모델 성능 측정 결과

  • 현재 최신 프론티어 모델들은 기존 벤치마크를 가볍게 만점으로 통과했다.
  • 단어 수를 1,000개에서 5,000개까지 늘려 테스트한 결과 최대 5,000개의 제약 조건을 처리했다.
  • 1년 만에 모델의 동시 지시사항 수행 능력이 거의 10배 향상되었다.

기준을 1만 단어 어휘 수준까지 확장하여 실험한 결과, 최신 모델들은 단일 프롬프트에서 2,000개에서 5,000개에 이르는 제약 조건을 추적할 수 있는 역량을 증명했다. 이는 6개월 이상 전에 세워둔 프롬프트 길이와 스킬 파일 관련 엔지니어링 가정을 전면 재설계해야 함을 시사한다.

모델별 네 가지 실패 양상

  • DeepSeek 4는 한계를 넘으면 단순히 지시사항을 조용히 잊어버린다.
  • Claude Opus 4.7은 안전 분류기 민감도로 인해 API 수준에서 요청을 거부한다.
  • Gemini 3.1 Pro는 과도한 사고 토큰을 소비한 뒤 정작 출력을 내놓지 못한다.
  • GPT 5.5는 보고서를 절반쯤 작성한 뒤 지시가 터무니없다고 따지며 멈춘다.

모델마다 한계를 초과했을 때 드러나는 양상이 극적으로 다르다. 단순 누락부터 API 거부, 사고 토큰 고갈, 자조적인 거부 응답까지 다양한 형태로 실패하기 때문에 실패 패턴을 파악하지 않으면 오류를 알아차리기 어렵다.

엔지니어링 워크플로우의 변화

  • 스킬 파일을 짧게 압축할 필요 없이 길게 작성할 수 있게 되었다.
  • 핵심 과제가 용량 확보에서 출력 결과를 확인하는 검증(eval)의 문제로 전환되었다.
  • 동일한 지시사항이라도 배치 순서나 표현에 따라 신뢰성이 크게 달라진다.

프롬프트를 압축하던 기존 방식에서 벗어나 이제는 비용과 지연 시간의 트레이드오프를 고려해야 한다. 벤치마크 만점을 받더라도 순서 배치에 따라 성능이 흔들리기 때문에, 실제 프로덕션 환경에서는 출력 결과를 모니터링하는 평가 시스템이 필수적이다.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기