Building Long-Running Agents with ScaleDown and Deep Agents

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

langchain-scaledown은 ScaleDown의 작업별 제약 디코딩 모델을 LangChain·Deep Agents에 연결해 장기 실행 에이전트의 문맥 관리 비용과 지연을 줄이며, LangSmith LLM Gateway도 ScaleDown을 지원한다.

📌 핵심 요약

• ScaleDown은 요약용 Summarize, 질문에 관련된 문맥을 남기는 Compress, 필드와 신뢰도·원문 위치를 반환하는 Extract, 레이블별 확률과 선택적 판단 이유를 제공하는 Classify를 제공한다. 모든 모델은 최대 1M tokens를 입력받으며, Extract·Summarize·Classify는 이미지와 스캔 PDF도 처리한다.
• ScaleDown은 좁은 작업에서 자사 모델이 프런티어 모델보다 200배 빠르고 467배 저렴하다고 보고한다. 별도의 자체 공개 데이터셋 벤치마크에서는 GPT-5.5·GPT-5.4 Mini·GPT-5.4 Nano 평균 대비 Summarize가 41배 저렴하고 2.7배 빠르며, Compress는 138배 저렴하고 1.8배 빠르고, 두 모델의 정확도도 높았다고 설명한다.
• langchain-scaledown은 오래된 대화 요약, 대형 도구 결과 압축, 대화의 구조화된 정보 추출을 위한 세 미들웨어를 제공한다. 에이전트의 주 모델은 계획과 작업 수행을 계속 담당하고, ScaleDown이 주변 문맥 처리를 맡는다.
• Classify로 반복 실패나 요청 이탈을 감지하는 기능은 기본 제공 미들웨어가 아닌 사용자 정의 미들웨어로 구현한다. 예시는 progressing·looping·drifting 중 progressing이 아닌 레이블의 확률이 0.8을 초과하면 실행을 중단하며, 판단 이유를 알려주거나 먼저 방향 전환을 유도하는 방식도 제시한다.
• LangSmith LLM Gateway는 하나의 LangSmith API 키로 여러 제공자의 모델을 호출하고 호출 추적과 지출·호출률 제한을 적용한다. 본문 핵심 요약은 ScaleDown 호출도 이 관리에 포함된다고 명시하지만, 제공된 원문의 마지막 Gateway 설명은 문장 중간에서 끝난다.

🧩 주요 포인트

1. 계획·코드 작성과 문맥 처리의 역할 분리 → 주 모델을 유지하면서 요약 비용을 줄일 수 있으며, 예시는 문맥 사용 비율 0.8에서 요약하고 최근 0.1을 보존한다.
2. compression_query에 따른 선택적 압축과 사용자 메시지만을 대상으로 하는 추출 → 필요한 도구 정보와 원문 값을 공급한다. 전체 도구 결과는 compression_query 없이 재호출할 수 있고, 누락된 추출 필드는 None으로 남는다.
3. Classify의 레이블별 확률·판단 이유와 LangSmith LLM Gateway의 호출 추적 → 실행 중단 기준과 그 근거를 확인하고 문맥 처리 호출까지 지출·호출률 제한 안에서 관리할 수 있다.

🧠 상세 정리

1. 장기 실행 에이전트의 병목과 CDM의 역할

글은 장기 실행 에이전트를 만드는 핵심을 어떤 정보를 언제 문맥 창에 넣을지 결정하는 문맥 관리로 설명한다. 오래된 이력을 요약하고, 큰 도구 결과를 줄이며, 긴 입력에서 필요한 데이터를 추출하는 판단이 계속 발생하므로 이를 일반 LLM에 맡기면 호출량에 따라 비용과 지연이 커진다는 문제의식이다. 이를 줄이기 위해 langchain-scaledown 통합과 LangSmith LLM Gateway의 ScaleDown 지원이 소개된다. 일반 목적 LLM이 토큰을 하나씩 생성하며 임의의 문자열을 작성하는 것과 달리, 제약 디코딩 모델인 CDM은 단일 작업을 위해 학습되고 지정된 레이블이나 입력의 일부 구간처럼 해당 작업이 허용하는 답을 반환한다. 글은 이 제약 덕분에 모델을 더 작고 빠르며 저렴하게 만들 수 있다고 설명하며, 에이전트의 주 모델은 실행 루프를 담당하고 ScaleDown은 그 주변의 문맥 처리를 맡는 구성을 제시한다.

2. 네 가지 모델과 입력 범위

ScaleDown의 네 모델은 각각 하나의 작업에 특화되어 있으며, Summarize는 긴 텍스트의 짧은 요약을 만들고 Compress는 질문과 관련된 부분만 남기도록 문맥을 줄인다. Extract는 설명한 필드를 텍스트에서 찾아 각 값의 신뢰도와 원문 위치를 함께 제공하고, Classify는 사용자가 정의한 레이블별 확률을 반환하며 자연어 판단 이유의 포함 여부도 선택할 수 있다. 모든 모델은 최대 1M tokens의 입력을 받아, 글은 전체 계약서나 긴 정책 문서, 한 시간 분량의 에이전트 이력을 나누지 않고 한 번에 처리하는 예를 든다. 멀티모달 입력은 Extract·Summarize·Classify에 대해 명시되어 있으며, 비정형 텍스트 외에 이미지와 스캔 PDF를 직접 받을 수 있다. 따라서 스크린샷이나 스캔한 청구서도 입력 예시에 포함되지만, Compress까지 이미지 입력을 지원한다고 본문이 명시한 것은 아니다.

3. 자체 성능 주장과 Jev 비교

ScaleDown은 제한된 작업에서 자사 모델이 프런티어 모델보다 200배 빠르고 467배 저렴하다고 보고하지만, 이는 글이 인용한 ScaleDown 측의 성능 주장이다. 별도로 소개된 자체 벤치마크는 공개 데이터셋에서 GPT-5.5·GPT-5.4 Mini·GPT-5.4 Nano의 평균과 비교한 것으로, Summarize는 41배 저렴하고 2.7배 빠르며 Compress는 138배 저렴하고 1.8배 빠르고 두 작업의 정확도도 더 높았다고 설명한다. 글은 Classify를 판단 모델인 Jev와도 비교하며, 둘 다 형식이 정해진 답과 확률을 반환한다는 공통점을 제시한다. 차이점으로 Jev는 질문당 최대 32K tokens의 텍스트 상태를 받지만, Classify는 이미지를 포함해 최대 1M tokens를 받고 각 판단에 한 문장 이유를 붙일 수 있다고 설명한다. 티켓 분류나 실행 중단처럼 레이블이 다음 행동을 좌우할 때 이 이유가 판단 배경을 보여주어 디버깅을 돕는다는 것이 글의 주장이다.

4. 오래된 메시지 요약과 최근 이력 보존

장시간 작업한 코딩 에이전트에는 수십 건의 파일 읽기와 도구 출력이 쌓이며, 그중 상당수는 원문 그대로 유지할 필요가 없어도 문맥 창을 차지한다. ScaledownSummarizationMiddleware는 Deep Agents의 기본 요약 미들웨어를 대체하고, 동일한 trigger와 keep 옵션으로 요약 시점과 보존할 최근 메시지 범위를 정한다. 예시는 openai:gpt-6-sol의 문맥 창을 기준으로 사용 비율이 0.8에 도달하면 오래된 메시지를 하나의 요약으로 바꾸고 최근 0.1 비율의 메시지를 유지하도록 설정한다. 계획 수립과 코드 작성은 기존 에이전트 모델이 계속 담당하며, ScaleDown이 작성하는 기본 요약은 LangChain 요약 프롬프트와 같은 의도·요약·산출물·다음 단계 구성을 따른다. ScaleDown 호출이 실패하면 이력을 그대로 두고 에이전트 실행을 이어가며, 이 미들웨어는 LangChain의 create_agent에서도 사용할 수 있다.

5. 질문에 맞춘 도구 결과 압축과 원문 재조회

글은 에이전트가 웹 페이지에서 한 문단만 필요해도 수만 자의 결과 전체가 문맥에 남아 이후 단계마다 토큰 비용을 발생시키고 과제 집중을 어렵게 할 수 있다고 설명한다. ScaledownToolCompressionMiddleware는 도구에 선택적 compression_query 인자를 추가해, 모델이 필요한 내용을 도구 호출 시 지정하도록 한다. 미들웨어는 실제 도구 실행 전에 이 인자를 제거하고, 실행 결과를 ScaleDown으로 압축한 뒤 모델에 전달하므로 기존 도구 구현을 바꿀 필요가 없으며 MCP 도구에도 적용할 수 있다. 예시는 fetch_url에 압축을 적용하고 EU 주문 환불 정책에 관한 부분을 요청하며, 본문은 연결된 추적 사례에서 긴 문서 페이지가 거의 90% 줄었다고 소개한다. 별도로 제시한 출력 안내 예시에는 18,402자가 3,110자로 줄었다는 수치와 함께, 전체 출력이 필요하면 compression_query 없이 같은 도구를 다시 호출하라는 설명이 붙는다.

6. 사용자 발화에서 구조화된 필드를 추출하는 방식

지원 에이전트가 티켓을 등록하려면 주문 번호, 오류 메시지, 고객 이메일처럼 그대로 도구에 전달할 값이 필요한데, 주 모델이 이를 직접 작성하면 오류 코드를 바꾸어 표현하거나 이메일을 잘못 옮길 수 있다는 문제가 제시된다. ScaledownExtractionMiddleware는 자연어로 설명한 필드를 Extract가 원문에서 복사하도록 하고, 필드가 레이블 집합이면 Classify를 사용해 문제 유형을 분류한다. 실행의 첫 모델 호출 전에 사용자 메시지를 처리한 결과는 에이전트 상태의 scaledown_extraction에 저장되며, 도구는 여기서 필드를 읽어 사용할 수 있고 예시의 context_chars=0 설정은 근거 발췌를 생략해 상태 크기를 줄인다. 추출 대상은 에이전트 응답이 아닌 사용자 메시지뿐이며, checkpointer가 있으면 매 턴 추출을 다시 실행해 고객이 추가한 정보를 반영한다. 주문 A-1042와 ERR_PAYMENT_DECLINED가 등장하는 예시에서는 두 값이 그대로 추출되고 issue_type은 billing이 되지만, 언급되지 않은 customer_email은 None으로 남는다.

7. Classify로 반복과 요청 이탈 감지

에이전트는 현재 상태를 바탕으로 작업 완료 여부나 도구 호출 성공 여부를 판단하며, 장기 실행에서는 같은 실패를 반복하거나 생산적이지 않은 순환에 빠지는 상태도 감지할 필요가 있다고 글은 설명한다. 이를 위한 기본 제공 미들웨어는 없지만, 사용자 정의 미들웨어에서 ScaleDown 모델을 직접 호출할 수 있으며 예시는 매 모델 호출 뒤 이력을 Classify로 보내는 실행 중단 장치를 구현한다. 레이블은 새 진전이 있는 progressing, 성과 없이 같은 단계를 반복하는 looping, 사용자가 요청하지 않은 일을 하는 drifting으로 구성된다. 최상위 레이블이 progressing이 아니고 해당 확률이 0.8을 초과하면 실행을 끝내며, 최종 메시지에 한 줄 판단 이유를 넣어 중단 배경을 확인하게 한다. 더 완만한 대안으로는 첫 감지 때 이유를 대화에 추가해 방향 전환을 유도하고, 다시 이탈할 때에만 중단하는 방식이 제시된다.

8. 모델 조합과 LangSmith LLM Gateway 지원

글은 앞서 설명한 요약·압축·추출·분류가 ScaleDown 활용 지점을 모두 나열한 것은 아니며, 작업에 맞추어 조합할 수 있다고 덧붙인다. 예를 들어 긴 도구 결과에 추출이나 요약을 적용하거나, 분류를 실행 중 모델 라우팅에 사용하는 방식이 언급되고 다른 데이터 유형의 활용 사례는 ScaleDown Cookbooks로 안내한다. 이어지는 LangSmith LLM Gateway 설명은 하나의 LangSmith API 키로 여러 제공자의 모델을 호출하고, 모든 호출을 추적하며 지출과 호출률 제한을 적용하는 기능을 소개한다. 글 앞부분의 핵심 요약은 ScaleDown이 이 Gateway에서 지원되어 해당 호출도 추적과 지출·호출률 제한에 포함된다고 명시한다. 다만 제공된 원문은 마지막 단락의 ‘ScaleDown is’에서 끊기므로, 이후에 이어질 구체적인 연결 설정이나 추가 설명은 이 자료만으로 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 문맥 관리를 별도 작업으로 분리하면 에이전트의 주 모델을 유지하면서 반복적인 요약·압축·추출에 특화 모델을 배치할 수 있다. 글의 핵심은 주 모델 전체의 교체보다 주변 처리의 비용과 지연을 줄이는 데 있다.
• 압축 결과에서 전체 도구 출력을 다시 요청할 수 있고, 추출에서 사용자에게 없는 값은 None으로 남기는 방식은 정보 축소와 원문 충실성을 함께 다루는 설계로 볼 수 있다.
• 성능 수치는 ScaleDown 자체 주장과 벤치마크라는 출처를 유지해 해석해야 한다. 또한 분류 기반 실행 중단은 기본 제공 기능이 아니라 확률 기준과 대응 방식을 직접 정하는 사용자 정의 구현이다.

✅ 액션 아이템

• ScaleDown의 200배 속도·467배 비용 주장과 Summarize·Compress 자체 벤치마크를 구분해 도입 판단에 반영.
• langchain-scaledown 적용 시 요약의 0.8·0.1 설정, compression_query를 통한 압축과 전체 결과 재호출, 사용자 메시지 추출 범위를 작업에 맞게 선택.
• Classify의 0.8 초과 중단 기준과 판단 이유 활용 방식을 정하고, LangSmith LLM Gateway의 호출 추적·지출·호출률 제한 적용을 확인.

❓ 열린 질문

• ScaleDown이 보고한 200배 속도·467배 비용 차이와 Summarize·Compress 자체 벤치마크 결과는 실제 적용할 문맥 관리 작업에서도 재현되는가?
• 요약 시점 0.8과 최근 메시지 보존 비율 0.1, compression_query에 따른 압축은 필요한 정보를 유지하는 데 적절한가?
• Classify가 progressing이 아닌 레이블에 0.8 초과 확률을 부여했을 때 즉시 중단할지, 판단 이유로 방향 전환을 유도할지는 어떤 기준으로 정할 것인가?