에이전트는 스킬 지시를 얼마나 많이 기억할 수 있는가?

URL: https://www.youtube.com/watch?v=XzJD1bvXKjs
날짜: 2026-09-10
채널: aiDotEngineer

📌 핵심 질문 / 에이전트 스킬 파일의 지시 한계는 어디에 있는가

==프론티어 모델이 한 번에 추적할 수 있는 명시적 제약의 한계는 1년 만에 약 200개에서 모델에 따라 2,000~5,000개로 이동했지만, 긴 지시를 실제로 올바르게 추론하고 수행하는 능력과 결과 신뢰성은 여전히 별도의 검증 문제다.==

• 2025년 기준으로 에이전트가 약 200개 지시를 넘기면 지시를 잊기 시작한다는 IFScale 결과가 있었다.
• 12개월 뒤 GPT-5.5, Claude Opus 4.7, Gemini 3.1 Pro, DeepSeek V4 Pro는 500개 지시를 모두 수행했고, 모델에 따라 약 2,000~5,000개까지 높은 정확도를 유지했다.
• 모델마다 실패 방식이 다르다. DeepSeek는 조용히 잊고, Claude는 안전성 판단으로 거부하며, Gemini는 생각 토큰을 소진하고, GPT-5.5는 작업을 중단하면서도 그럴듯한 중간 결과를 남긴다.

스킬 파일의 길이를 줄이는 압축 문제는 크게 완화됐지만, 비용·지연·충돌하는 지시·구조화된 긴 문맥의 성능 저하·조용한 반완료를 확인하는 검증 문제가 새롭게 중심이 됐다. 긴 프롬프트를 더 잘 쓰는 것만으로는 충분하지 않으며, 코드와 마찬가지로 매번 출력물을 평가하는(eval) 운영이 필요하다.

1. 출발점: “200개 지시”라는 낮은 천장

1.1. 200개가 스킬 파일을 얼마나 빨리 채우는가

1. 짧은 지시 하나도 독립적인 제약이다

   1. “사용자가 X라고 하면 Y를 하라”는 한 개의 지시다.
   2. “항상 Z 섹션을 포함하라”와 “W라는 표현을 절대 쓰지 말라”도 각각 한 개의 지시다.
   3. 규칙·예외·문체·포맷을 담은 제대로 된 스킬 파일은 200개를 거의 즉시 넘어선다.

2. 낮은 한계는 시스템 복잡도를 제한한다

   1. 모델이 200개 부근에서 조용히 지시를 놓친다면 복잡한 업무 자동화의 상한도 함께 낮아진다.
   2. 지시를 더 많이 넣을수록 에이전트가 모든 규칙을 기억하는지 확인하기 어렵고, 결과가 기대와 비슷해 보이는 모조품인지 판단하기도 어렵다.
   3. 긴 스킬 파일을 실행할 때마다 “모든 규칙을 따랐는가, 대충 비슷한 결과만 냈는가”라는 불안이 생긴다.

1.2. 연구가 답하려는 실무 질문

1. 한계의 출처를 확인하는 질문

   1. 200이라는 숫자가 실제 벤치마크에서 나온 것인지 확인해야 한다.
   2. 숫자가 2025년 모델에만 해당하는지, 현재 모델에도 유효한지 다시 측정해야 한다.

2. 18분 발표의 약속

   1. IFScale이 200이라는 숫자를 어떻게 만들었는지 밝힌다.
   2. 과거의 200개 천장이 실제였는지 재현한다.
   3. 오늘의 실제 한계를 찾고, 스킬 파일과 프롬프트를 어떻게 설계할지 워크플로우 변화를 제시한다.

2. IFScale 벤치마크와 과거 결과 재현

2.1. 단순한 키워드 과제로 지시 추적을 측정하는 방법

1. IFScale의 기본 과제

   1. 모델에게 비즈니스 보고서를 작성하라고 요청한다.
   2. 보고서에 customer, revenue 같은 특정 단어를 정확히 포함하라고 요구한다.
   3. 요구 단어를 원하는 개수만큼 늘린 뒤 실제 보고서에 나타난 단어 수를 센다.

2. 측정에 필요한 두 숫자

   1. 밀도(density) n은 한 번에 부여한 규칙의 개수다.
   2. 정확도(accuracy)는 모델이 지킨 규칙의 비율이다.
   3. 정확한 단어 삽입은 실제 업무 지시와 같은 형태의 이산적이고 이름 붙은 제약(discrete named constraint)을 만든다.

3. 키워드가 실제 지시의 대리 지표(proxy)인 이유

   1. “revenue라는 단어를 포함하라”는 “가격 책정(pricing) 섹션을 포함하라”와 같은 종류의 추적 과제다.
   2. “특정 표현을 사용하지 말라”도 모델이 기억하고 지켜야 하는 이산적 제약이다.
   3. 무작위 단어 200개를 추적하지 못하는 모델은 더 복잡한 지시 200개를 추적할 때 최소한 그보다 어렵게 수행할 가능성이 높다.
   4. 따라서 키워드 벤치마크의 한계는 복잡한 실제 지시가 가질 수 있는 상한에 가깝고, 실제 한계는 더 낮아질 수 있다.

2.2. 2025년 결과를 세 모델로 재현한 과정

1. 비교 가능한 모델을 고르는 제약

   1. 원래 논문은 10개 모델을 묶어서 평가했다.
   2. 모델은 빠르게 교체·은퇴하므로 재현 시점에 API로 접근 가능한 원래 모델은 GPT-4.1, Claude Sonnet 4, Gemini 2.5 Pro 세 개뿐이었다.
   3. 세 모델은 측정 12개월 전에도 존재했고 재현 시점에도 사용할 수 있었기 때문에 비교 대상으로 남았다.
   4. 연구가 처음 공개된 뒤 세 모델 중 하나가 이미 은퇴했으므로, 같은 조건의 마지막 재현 기회가 됐다. 모델에 지나치게 애착을 두기 어려운 이유도 여기에 있다.

2. 과거 곡선의 의미

   1. 세로축은 정확도이며 100%에서 시작해 규칙 수가 늘면 하락한다.
   2. 가로축은 규칙 수의 로그 스케일이라 그래프가 절반 이동할 때마다 규칙 수가 두 배가 된다.
   3. 규칙 500개 부근에서는 모델마다 30~50%를 잃고 있었다.
   4. 재현 곡선은 원 논문의 결과와 노이즈 범위 안에서 일치했다.
   5. 1년 전 프론티어 모델이 약 200~300개 지시에서 무너지기 시작했다는 결론은 실제였다.

3. 현재 프론티어의 10배 향상

3.1. 500개 한계를 넘어 새 벤치마크를 만든 과정

1. 같은 과제를 최신 모델에 적용한 조건

   1. GPT-5.5, Claude Opus 4.7, Gemini 3.1 Pro, DeepSeek V4 Pro에 같은 프롬프트와 같은 단어 목록을 제공했다.
   2. 네 모델 모두 기존 최대치인 500개 단어를 즉시 100% 정확도로 처리했다.
   3. 500개에서 멈추는 IFScale은 새 모델의 한계를 찾지 못하고 모델이 천장 위로 걸어 올라간 것처럼 보이게 했다.

2. 한계를 찾기 위한 목표 상향

   1. 요구 단어 수를 500개에서 1,000개로 두 배 늘렸다.
   2. 다시 2,000개로 두 배 늘린 뒤 같은 방식으로 계속 증가시켰다.
   3. 최대 10,000단어 어휘까지 확장한 지점에서 현재 모델의 천장이 드러나기 시작했다.

3.2. 2,000~5,000개 제약이라는 새 경계

1. 정확도 곡선이 꺾이는 지점

   1. 로그 스케일의 가로축은 500, 1,000, 5,000, 10,000을 보여준다.
   2. 새 곡선은 1년 전 200~300개에서 무너지던 위치보다 훨씬 오른쪽까지 평평하게 유지된다.
   3. 모델에 따라 약 2,000개에서 하락이 시작된다.
   4. 가장 좋은 모델은 급격한 하락 전까지 약 5,000개 지시를 유지한다.

2. 10배 향상이 의미하는 것

   1. 12개월 동안 프론티어 모델의 동시 지시 추적 능력이 거의 10배 좋아졌다.
   2. 2,000개의 이름 붙은 제약은 브랜드 규칙·법적 고지·문체 지침을 합친 하나의 스타일 가이드에 해당한다.
   3. GPT-5.1에서 GPT-5.5로의 변화가 체감상 점진적으로 보였어도, 스킬 파일 길이라는 실용적 평가에서는 10배 변화가 나타났다.
   4. IFScale은 발표 시점 기준으로도 만들어진 지 1년 남짓한 벤치마크였고, 그 1년 뒤 500은 반올림 오차에 가까운 숫자가 됐다.
   5. Claude Opus 4.8이 측정 직후 출시됐고 Opus 4.7보다 더 좋아졌으므로 그래프는 이미 최신 상태가 아니다.
   6. 6개월보다 오래된 프롬프트 길이 가정은 현재 모델의 능력을 과소평가할 수 있어 재설계가 필요하다.

4. 모델별로 달라진 네 가지 실패 방식

4.1. 잊어버림과 안전성 거부

1. DeepSeek V4 Pro: 예측 가능한 망각

   1. 약 750개 규칙에서 지시를 잊기 시작한다.
   2. 2,000개에 이르면 거의 절반의 규칙을 놓친다.
   3. 전통적인 실패 방식이라 무엇을 얼마나 잊었는지 측정하기 쉽고, 예측 가능하다는 점에서 신뢰하기 가장 쉽다.

2. Claude Opus 4.7: 위험하다고 판단하고 API에서 거부

   1. Claude는 테스트를 위험한 요청으로 판단하면 생성 전에 API 수준에서 거부한다.
   2. anthrax와 cyanide 같은 단어 조합이 무작위 목록에 함께 들어가면 폭탄 제작 요청처럼 해석할 수 있다.
   3. 5,000~10,000개 무작위 단어를 한 파일에 넣는 실험은 안전성 분류기(safety classifier)에 위험해 보이는 조합을 쉽게 만든다.
   4. 협조를 얻기 위해 모든 단어를 OpenAI 안전성 필터에 먼저 통과시켜 위험해 보이는 단어를 제거해야 했다.
   5. 필터링 후 Claude는 높은 성능을 보였지만, 의학 조언처럼 안전·위험 양쪽으로 사용될 수 있는 주제에서는 200~300개 수준에서도 일찍 거부할 가능성이 있다.

4.2. 생각 토큰 소진과 그럴듯한 반완료

1. Gemini 3.1 Pro: 지시를 지키려다 출력 공간을 소진

   1. Gemini는 5,000개 지시까지 매우 견고하게 수행했다.
   2. 그 이상에서는 지시를 잊기보다 모든 지시를 동시에 지키려는 사고(thinking)에 압도된다.
   3. 10,000토큰 예산에서 약 9,500토큰을 생각에 쓰고 실제 답변에는 약 500단어만 남기는 식으로 작동한다.
   4. 최종 답변에는 요구 단어가 거의 들어 있지 않으며, 모델이 스스로 생각의 구석으로 들어가 실제 답변 공간을 없애는 셈이다.
   5. 긴 사고 토큰을 소비하고도 유용한 출력을 내지 못하므로 비용이 크고 실무적으로도 도움이 되지 않는다.
   6. 이런 과잉 사고가 Gemini의 이미지와 잘 맞는다는 농담이 이어졌고, 웃음과 코웃음이 섞인 반응이 나왔다.

2. GPT-5.5: 좌절한 뒤 작업을 중단하는 반완료

   1. GPT-5.5는 네 모델 중 가장 좋았고, 5,000개 규칙까지 99% 정확도를 유지했다.
   2. 충분히 밀어붙이면 즉시 거부하거나 조용히 잊지 않고, 보고서를 쓰다가 요청 자체가 어리석다고 판단한다.
   3. 보고서를 시작해 수백 단어쯤 작성한 뒤 “이건 멍청한 요청이니 계속하지 않겠다”는 식으로 정중하게 중단한다.
   4. 주제도 정하지 않은 비즈니스 보고서에 무작위 단어 5,000개를 넣으라는 요구는 실제로 일관된 보고서를 만들기 어려운 부당한 요청이다.
   5. 요청이 불합리하다는 판단 자체는 타당하지만, 반쯤 끝난 보고서에는 대부분의 키워드가 빠지므로 IFScale 기준으로는 실패다.
   6. 초반 결과가 전문적이고 자신 있어 보이기 때문에, 끝까지 읽어 중단 선언을 확인하지 않으면 실패를 발견하기 가장 어렵다.

3. 네 모델의 대비

   1. DeepSeek는 조용히 잊는다.
   2. Claude는 겁을 먹고 거부한다.
   3. Gemini는 과도하게 생각하다 침묵한다.
   4. GPT-5.5는 작업의 절반을 끝내고 나머지가 가치 없다고 말한다.
   5. “지시를 따랐는가”라는 질문에는 더 이상 하나의 실패 패턴만 존재하지 않으며, 사용하는 모델의 패턴을 알아야 실패를 식별할 수 있다.

5. 스킬·프롬프트 워크플로우가 바뀌어야 하는 이유

5.1. 압축 중심 설계에서 긴 스킬 파일로

1. 과거의 권장 전략

   1. 1년 전에는 스킬 파일을 200개 지시 아래로 유지하는 것이 현명했다.
   2. 추가 규칙은 하위 스킬 파일과 전문 에이전트로 쪼개고, 파일 사이에 복잡한 전달 구조를 만들었다.
   3. 작은 용량에 맞추기 위해 지시를 압축하고, 여러 하위 에이전트가 서로 깨끗하게 인계하기를 기대해야 했다.

2. 현재의 실무 전략

   1. 스킬 파일을 매우 짧게 유지해야 한다는 압박이 사라졌다.
   2. 100개나 300개의 구체적인 규칙이 필요하면 모두 프롬프트에 넣어도 된다.
   3. 2,000개의 명시적 제약은 브랜드 규칙과 법적 고지까지 포함하는 전체 스타일 가이드 규모이며, 이를 수십 개 전문 에이전트로 분할하지 않아도 된다.

5.2. “가능한가”에서 “비용을 낼 가치가 있는가”로

1. 하드 월(hard wall)의 완화

   1. 과거의 핵심 질문은 모델이 많은 규칙을 아예 처리할 수 있는지였다.
   2. 현재의 답은 “상당히 확실하게 그렇다”이며, 최소 2,000개와 일부 모델의 5,000개 추적 능력이 근거가 된다.

2. 소프트 트레이드오프(soft trade-off)의 등장

   1. 10,000개의 지시를 프롬프트에 넣을 수는 있지만 프롬프트 자체가 매우 커진다.
   2. 프롬프트가 커질수록 비용이 커지고 응답 지연(latency)이 길어진다.
   3. 이제 설계자는 지시를 더 추가해 얻는 품질 향상이 추가 비용과 지연을 정당화하는지 판단해야 한다.

6. 정확도 수치만으로는 충분하지 않다는 경고

6.1. IFScale의 범위와 한계

1. 대리 지표와 증명의 차이

   1. 무작위 단어를 가짜 비즈니스 보고서에 삽입하는 과제는 긴 스킬 파일이 작동할 가능성을 보여주는 증거다.
   2. 같은 결과가 현실의 긴 스킬 파일에서도 성립한다는 증명은 아니다.
   3. 모델마다 무너지는 지점이 750개부터 9,000개 이상까지 크게 달라 모델 선택이 중요하다.

2. 측정하지 못한 능력

   1. IFScale은 거대한 프롬프트 위에서 모델이 얼마나 명료하게 추론하는지 측정하지 않는다.
   2. 모델이 2,000·5,000·어쩌면 10,000개의 지시를 추적할 수 있어도, 서로 충돌하거나 긴장 관계에 있는 지시를 정확하게 조정한다는 보장은 없다.

6.2. Context Rot와 문맥 구조의 역설

1. Chroma의 18개 모델 연구

   1. 새로운 Context Rot 연구는 컨텍스트 윈도(context window) 한도에 도달하기 훨씬 전에 긴 입력의 정확도가 30~50% 떨어질 수 있다고 보고했다.
   2. 긴 입력을 잘 정리한 일관된 구조의 텍스트가 무작위로 섞은 지시보다 오히려 이런 실패를 더 쉽게 일으켰다.
   3. 구조화된 텍스트가 왜 더 취약한지는 추가 연구가 필요하다.

2. 정리된 글이 곧 명료한 추론을 보장하지 않는 이유

   1. 지시 추적 용량과 긴 문맥 위에서의 명료한 추론은 서로 다른 능력이다.
   2. 지시 간 우선순위와 충돌을 모델이 제대로 해결하는지는 키워드 포함률만으로 알 수 없다.
   3. 모델이 지시를 모두 기억하는 것처럼 보여도 결과의 논리적 일관성을 별도로 검사해야 한다.

6.3. 표현과 순서가 바꾸는 신뢰성

1. 46개 모델을 평가한 “Revisiting the Reliability of Language Models in Instruction Following”

   1. 모델은 IFScale과 같은 벤치마크를 훌륭하게 통과하면서도 실제로는 매우 불안정할 수 있다.
   2. 같은 지시를 조금 다르게 표현하면 지시 준수율이 급격히 달라질 수 있다.
   3. 같은 2,000개 지시도 순서만 바꾸면 성능이 크게 나빠질 수 있다.
   4. 어떤 순서로 지시해야 완벽하게 따르는지에 관한 정답은 아직 연구 중이다.

2. 새로운 실제 제약 벤치마크

   1. Firebench는 같은 문제를 측정하려는 벤치마크 중 하나다.
   2. CCRBench도 실제 제약 추적 능력을 평가한다.
   3. GuideBench도 지저분하고 현실적인 제약을 동시에 따르는 능력을 측정한다.
   4. 무작위 10,000단어 실험보다 실제 업무에 가까운 연구가 빠르게 늘고 있다.

7. 검증 문제와 eval 운영

7.1. 조용한 실패를 알아내는 방법

1. 실패의 가시성 차이

   1. Claude의 API 거부는 짜증스럽지만 오류가 크게 드러난다.
   2. GPT-5.5의 정중한 반완료는 실제 답변처럼 보이므로 훨씬 위험하다.
   3. GPT-5.5가 끝까지 읽어야 보이는 중단 선언을 남길 수 있어, 결과를 매번 확인하지 않으면 신뢰할 수 없다.

2. 출력 검사가 필수인 이유

   1. 복잡한 AI 애플리케이션은 프론티어 모델에서도 네 가지 실패 방식 중 하나 이상을 만날 수 있다.
   2. Claude처럼 API가 명시적으로 거부하지 않는 경우, 문제가 생겼다는 사실은 출력물을 검사하기 전까지 드러나지 않는다.
   3. 다른 LLM으로 출력물을 모니터링하는 평가(evaluation, eval)가 조용한 실패를 발견하는 실용적인 방법이다.

7.2. 평가 비용과 Arize AI의 역할

1. 실험 비용

   1. 7개 모델에 걸쳐 약 2,300개의 호출을 실행하는 데 총 29달러가 들었다.
   2. 새로운 연구도 모델 API 비용만 감당하면 생각보다 저렴하게 수행할 수 있다.

2. 프로덕션 평가

   1. 까다로운 업무를 수행하는 실제 AI 애플리케이션은 긴 지시의 실패 방식과 마주칠 수밖에 없다.
   2. API 수준의 명시적 거부를 제외하면, 출력 모니터링 없이는 모델이 틀렸는지 알기 어렵다.
   3. Arize AI는 다른 LLM을 활용한 출력 평가와 모니터링을 제공한다.

8. 최종 결론과 행사 마무리

8.1. 압축 문제에서 검증 문제로

1. 지난해의 어려움

   1. 스킬을 작성할 때 모든 규칙을 모델이 기억할 수 있도록 작은 공간에 억지로 압축해야 했다.
   2. 이 압축 문제가 200개 부근의 하드 월을 만들었고, 하위 스킬과 전문 에이전트 분할을 강제했다.

2. 오늘의 어려움

   1. 모델은 2,000개 안팎의 지시를 보유할 수 있고 일부 모델은 5,000개까지 높은 정확도를 보인다.
   2. 이제 핵심은 모델이 실제로 모든 요구를 수행했는지 아는 검증 문제다.
   3. 더 나은 프롬프트를 작성하는 것만으로 검증 문제를 해결할 수 없다.
   4. 다른 코드와 마찬가지로 매번 출력물을 검사하는 eval이 필요하다.

8.2. 발표 종료와 공유 자료

1. 재검토해야 할 엔지니어링 가정

   1. 6개월 전에 정한 프롬프트 길이와 스킬 파일 크기 가정은 이미 틀렸을 수 있다.
   2. 모델 능력의 이동 속도가 빠르므로 정기적으로 같은 평가를 다시 실행해야 한다.
   3. 10배 높아진 용량이 곧 10배 신뢰성을 뜻하지 않으므로 용량·비용·지연·검증을 함께 설계해야 한다.

2. 마지막 안내

   1. 실험 코드와 데이터는 GitHub URL로 공개됐다.
   2. 별도의 QR 코드는 마케팅팀이 삽입한 월드컵 시청 파티 홍보물이다.
   3. 월드컵 시청 파티는 당일 오후 5시에 열리며, QR 코드의 Luma 링크로 입장할 수 있다.
   4. 새로운 정보와 몇 번의 웃음을 얻었기를 바란다는 인사로 발표가 끝났다.

주요 발언 모음

“The question is where is that point? At what point have you put too many instructions in your skills files?”
“그 지점은 어디인가? 스킬 파일에 지시를 너무 많이 넣은 시점은 언제인가?”

“The capacity to track 2,000 named constraints in a single prompt is there.”
“하나의 프롬프트에서 2,000개의 이름 붙은 제약을 추적할 능력은 존재한다.”

“A year ago 500 was a rounding error.”
“1년 전에는 500이 반올림 오차에 불과했다.”

“DeepSeek quietly forgets, Claude gets scared and refuses, Gemini overthinks itself into silence, and GPT 5.5 finishes half of the job and tells you that the rest of it is beneath it.”
“DeepSeek는 조용히 잊고, Claude는 겁을 먹고 거부하며, Gemini는 과도하게 생각하다 침묵하고, GPT-5.5는 절반을 끝낸 뒤 나머지는 자기 수준에 못 미친다고 말한다.”

“The question used to be can the model even do this? … Is it worth the cost is the new question.”
“예전 질문은 모델이 이 일을 할 수 있느냐였다. 이제 새 질문은 그 비용을 낼 가치가 있느냐이다.”

“A proxy task … is evidence that long skills file works. It is not the same as proof that a long skills file works.”
“대리 과제는 긴 스킬 파일이 작동할 가능성의 증거이지, 긴 스킬 파일이 작동한다는 증명과 같지 않다.”

“The new hard part is knowing whether it actually did what you said.”
“새로운 어려움은 모델이 실제로 지시한 일을 했는지 아는 것이다.”

“A verification problem doesn't get solved by writing a better prompt. It gets solved by checking the output every time.”
“검증 문제는 더 나은 프롬프트로 해결되지 않는다. 매번 출력물을 확인해야 해결된다.”

핵심 데이터 & 수치

• 과거 지시 한계: 2025년 프론티어 모델은 약 200~300개 규칙에서 정확도가 무너지기 시작했다.
• 과거 500개 결과: 규칙 500개 부근에서 모델이 30~50%를 잃었다.
• 현재 지시 용량: 최신 모델은 2,000개 안팎까지 유지하고, 최상위 모델은 약 5,000개까지 높은 정확도를 보였다.
• DeepSeek V4 Pro: 약 750개에서 망각을 시작하고 2,000개에서 거의 절반을 놓쳤다.
• Gemini 3.1 Pro: 약 5,000개까지 견고했으며 이후 사고 토큰을 소진했다.
• GPT-5.5: 5,000개까지 99% 정확도를 보였다.
• Context Rot: 18개 모델 연구에서 컨텍스트 윈도 한도 전에 긴 입력 정확도가 30~50% 떨어질 수 있었다.
• 신뢰성 연구: 46개 모델 연구에서 표현과 지시 순서만 바꿔도 성능이 급격히 달라질 수 있었다.
• 실험 비용: 7개 모델에 걸친 약 2,300회 호출에 29달러가 들었다.
• 확장 범위: IFScale의 기존 500단어 한계를 1,000·2,000·10,000단어로 확장했다.

결론 및 시사점

1. 스킬 파일을 200개 지시 이하로 억지로 압축하거나 수많은 하위 에이전트로 쪼개야 한다는 가정은 재검토해야 한다.
2. 모델별 지시 추적 한계와 실패 양상이 크게 다르므로 모델을 바꿀 때 같은 eval을 다시 실행해야 한다.
3. 2,000~5,000개 지시를 담을 수 있다는 용량은 긴 스타일 가이드와 법적 규칙을 한 프롬프트에 넣을 여지를 만든다.
4. 긴 프롬프트는 비용과 지연을 증가시키므로 모든 규칙을 넣는 것이 항상 경제적인 선택은 아니다.
5. 키워드 포함률은 지시 추적의 대리 지표일 뿐, 복잡한 지시 사이의 추론·우선순위·충돌 해결을 보장하지 않는다.
6. Context Rot, 표현 변화, 지시 순서 변화가 별도의 신뢰성 저하를 만들 수 있으므로 현실적인 제약을 포함한 테스트가 필요하다.
7. 그럴듯한 반완료처럼 눈에 잘 띄지 않는 실패가 가장 위험하므로 출력 전체를 검증하는 eval을 프로덕션에 배치해야 한다.
8. 1년 만에 10배 이동한 한계는 프롬프트 설계 가정을 최소 6개월 단위로 재검증해야 한다는 신호다.