Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering 논문 정리

한 줄 요약

이 논문은 LLM 에이전트의 발전을 “모델을 더 크게 만드는 문제”가 아니라 “모델 바깥에 무엇을 잘 배치할 것인가”의 문제로

정리합니다.

핵심 관점은 외부화(Externalization)입니다.

• 기억해야 할 것은 메모리로 뺍니다.
• 반복 절차는 스킬로 뺍니다.
• 도구·사용자·다른 에이전트와의 상호작용은 프로토콜로 뺍니다.
• 이 셋을 실행 가능한 시스템으로 묶는 층이 하네스(Harness)입니다.

논문이 말하는 좋은 에이전트는 단순히 “똑똑한 모델”이 아닙니다.
잘 조직된 외부 인지 인프라 안에서 작동하는 모델입니다.

핵심 문제의식

LLM은 강력합니다.
하지만 혼자서는 장기 작업에 취약합니다.

대표적인 한계는 세 가지입니다.

• 이전 세션의 상태를 안정적으로 기억하지 못합니다.
• 긴 절차를 매번 새로 만들어내며 흔들립니다.
• 도구 호출, 권한, 실패 복구를 자유 형식 프롬프트에 맡기면 취약합니다.

논문은 이 문제를 한 문장으로 압축합니다.

모델이 어려워하는 부담을 바깥 구조로 옮기면, 모델이 풀어야 하는 과제 자체가 쉬워진다.

 

여기서 중요한 점은 “보조 도구를 붙인다”가 아닙니다.
외부 구조가 모델의 일을 대신하는 방식으로 문제의 형태를 바꾼다는 점입니다.

 

예를 들어 쇼핑 목록은 인간의 기억력을 늘려주지 않습니다.
대신 “머릿속에서 떠올리기”를 “목록에서 확인하기”로 바꿉니다.

LLM 에이전트에서도 같은 일이 일어납니다.
메모리는 회상을 검색으로 바꾸고, 스킬은 즉흥 생성을 재사용으로 바꾸며, 프로토콜은 애매한 대화를 구조화된 계약으로 바꿉니다.

주목할 영역: 하단의 Weights → Context → Harness 흐름을 보면, 논문이 에이전트 발전을 “모델 내부”에서 “외부 인프라”로 이동하는 과정으로 해석한다는 점이 드러납니다.

논문의 큰 주장

이 논문은 네 가지 주장을 중심으로 전개됩니다.

1. 메모리는 상태를 외부화한다

에이전트는 긴 작업에서 이전 맥락을 잃기 쉽습니다.
메모리는 이 문제를 바깥 저장소로 옮깁니다.

이때 메모리는 단순한 로그가 아닙니다.
작업 상태, 과거 실행 기록, 사용자 선호, 프로젝트 지식이 필요할 때 다시 불러올 수 있는 형태로 정리됩니다.

2. 스킬은 절차적 전문성을 외부화한다

LLM은 어떤 일을 “알고” 있어도 매번 같은 품질로 수행하지는 못합니다.
스킬은 반복 가능한 절차, 판단 기준, 안전 조건을 재사용 가능한 문서나 패키지로 만듭니다.

즉, 모델은 매번 절차를 발명하지 않습니다.
이미 검증된 절차를 선택하고 따릅니다.

3. 프로토콜은 상호작용 구조를 외부화한다

도구 호출, 다른 에이전트와의 위임, 사용자 인터페이스 출력은 모두 형식이 필요합니다.
프로토콜은 이 형식을 명시합니다.

모델은 더 이상 “어떤 모양으로 호출해야 하는지”를 추측하지 않습니다.
정해진 스키마와 상태 전이에 맞춰 행동합니다.

4. 하네스는 외부화된 요소들을 실행 환경으로 묶는다

메모리, 스킬, 프로토콜은 따로 있으면 충분하지 않습니다.
이들을 언제 읽고, 언제 불러오고, 어떤 권한으로 실행하고, 어떻게 기록할지 정해야 합니다.

그 역할을 하는 것이 하네스입니다.

하네스는 에이전트의 실행 루프, 권한, 샌드박스, 승인 절차, 관찰성, 피드백 루프를 관리합니다.

배경: Weights에서 Context, 그리고 Harness로

논문은 LLM 에이전트의 흐름을 세 단계로 나눕니다.

1단계: Weights

초기에는 능력이 모델 파라미터 안에 있다고 보았습니다.

• 더 큰 모델
• 더 많은 데이터
• 더 나은 사전학습
• 더 정교한 정렬

이 관점은 여전히 중요합니다.
모델의 언어 이해, 일반 추론, 기본 지식은 대부분 이 층에서 나옵니다.

하지만 문제가 있습니다.
모델 내부 지식은 수정하기 어렵고, 감사하기 어렵고, 사용자별로 다르게 적용하기 어렵습니다.

2단계: Context

다음 단계에서는 프롬프트와 컨텍스트가 중요해졌습니다.

• 프롬프트 엔지니어링
• Chain-of-Thought
• ReAct
• RAG
• 긴 컨텍스트

이 단계에서는 모델을 다시 학습시키지 않고도 행동을 바꿀 수 있습니다.
필요한 정보를 입력에 넣고, 모델이 그것을 활용하게 만듭니다.

하지만 컨텍스트는 비용이 크고, 길어질수록 잡음이 늘며, 세션이 끝나면 사라집니다.

3단계: Harness

현재의 핵심 이동은 하네스입니다.

모델 주변에 실행 인프라를 둡니다.

• 장기 메모리
• 도구 레지스트리
• 스킬 문서
• 프로토콜 인터페이스
• 샌드박스
• 승인 게이트
• 실행 로그
• 평가기
• 서브에이전트 오케스트레이션

이제 질문은 “모델이 얼마나 똑똑한가?”만이 아닙니다.
“어떤 부담을 모델 밖으로 빼서 더 안정적으로 만들었는가?”입니다.

주목할 영역: 상위 Harness 층이 2024년 이후 두꺼워지는 흐름은 에이전트 연구의 중심이 프롬프트 개선에서 실행 인프라 설계로 이동했음을 보여줍니다.

하네스형 LLM 에이전트의 기본 구조

논문은 하네스를 중심에 둡니다.
그 주변을 세 가지 외부화 축이 둘러쌉니다.

• Memory: 시간에 걸친 상태
• Skills: 반복 가능한 절차
• Protocols: 외부 시스템과의 상호작용 규칙

여기에 실행을 안정화하는 운영 요소가 붙습니다.

• 샌드박스
• 관찰성
• 압축
• 평가기
• 승인 루프
• 서브에이전트 오케스트레이션

이 구조에서 모델은 혼자 일하지 않습니다.
모델은 하네스 안에서 필요한 정보와 절차와 인터페이스를 받아 행동합니다.

주목할 영역: 중앙의 Harness와 주변의 Memory·Skills·Protocols 연결부를 보면, 논문이 에이전트 능력을 모델 단독이 아니라 실행 환경 전체의 결합으로 본다는 점이 명확해집니다.

Memory: 시간을 외부화하기

메모리는 에이전트의 시간 부담을 해결합니다.

LLM은 매 호출마다 새 컨텍스트에서 시작합니다.
따라서 장기 작업에서는 이전 상태를 계속 다시 구성해야 합니다.

메모리는 이 문제를 바깥으로 옮깁니다.
중요한 상태를 저장하고, 현재 작업에 필요한 조각만 다시 불러옵니다.

논문은 메모리를 네 가지로 나눕니다.

Working Context

현재 작업의 살아 있는 상태입니다.

예시:

• 열려 있는 파일
• 임시 변수
• 부분 계획
• 실행 체크포인트
• 최근 도구 출력

이 정보는 빠르게 변합니다.
하지만 작업을 재개하려면 반드시 필요합니다.

Episodic Experience

과거 실행 경험입니다.

예시:

• 어떤 결정을 했는지
• 어떤 도구를 호출했는지
• 어디서 실패했는지
• 어떤 수정이 효과가 있었는지

이 경험은 나중에 비슷한 문제를 만났을 때 참고가 됩니다.
또한 스킬을 만들기 위한 원재료가 됩니다.

Semantic Knowledge

시간과 무관한 일반 지식입니다.

예시:

• 도메인 규칙
• 프로젝트 컨벤션
• 안정적인 사실
• 반복되는 휴리스틱

에피소드가 “무슨 일이 있었는가”라면, 시맨틱 지식은 “보통 무엇이 성립하는가”입니다.

Personalized Memory

사용자, 팀, 환경에 특화된 기억입니다.

예시:

• 사용자의 선호
• 반복되는 요청 방식
• 조직별 규칙
• 특정 프로젝트의 제약

이 메모리는 일반 지식과 섞이면 안 됩니다.
개인화 정보는 보존, 접근, 삭제, 프라이버시 기준이 다르기 때문입니다.

주목할 영역: 왼쪽의 원시 컨텍스트가 네 종류의 메모리로 분리되는 흐름을 보면, 메모리의 핵심이 “많이 저장하기”가 아니라 “현재 의사결정에 맞게 상태를 재구성하기”라는 점이 보입니다.

메모리 설계의 진화

논문은 메모리 아키텍처를 네 단계로 정리합니다.

 

첫째, 단일 컨텍스트 방식입니다.
모든 기록을 프롬프트에 넣거나 요약합니다.
간단하지만 오래 버티지 못합니다.

 

둘째, 검색 저장소 방식입니다.
장기 기록은 외부 저장소에 두고, 필요할 때 검색합니다.
RAG 기반 메모리의 기본 형태입니다.

 

셋째, 계층형 메모리입니다.
모든 기록을 같은 방식으로 보관하지 않습니다.
중요도, 최신성, 기능에 따라 저장·압축·삭제·승격을 다르게 처리합니다.

 

넷째, 적응형 메모리입니다.
검색 전략, 저장 정책, 라우팅 방식을 실행 경험에 따라 바꿉니다.

 

핵심은 분명합니다.

메모리는 단순 저장소가 아닙니다.
무엇을 현재 컨텍스트로 가져올지 결정하는 제어 표면입니다.

잘못된 메모리는 위험합니다.

• 오래된 기억은 현재를 왜곡합니다.
• 너무 추상적인 기억은 실행에 쓸 수 없습니다.
• 너무 자세한 기억은 컨텍스트를 오염시킵니다.
• 악성 기억은 이후 판단 전체를 오염시킵니다.

따라서 좋은 메모리의 기준은 저장량이 아닙니다.
지금 결정에 필요한 과거를 정확히 보여주는 능력입니다.

Skills: 절차적 전문성을 외부화하기

스킬은 에이전트의 절차 부담을 해결합니다.

LLM은 많은 작업의 절차를 대략 알고 있습니다.
하지만 실제 실행에서는 자주 흔들립니다.

• 단계를 빠뜨립니다.
• 순서를 바꿉니다.
• 실패 후 복구하지 못합니다.
• 완료 조건을 잘못 판단합니다.
• 안전 조건을 잊습니다.

스킬은 이런 절차를 외부 문서나 패키지로 만듭니다.

즉, 모델이 매번 “어떻게 할지”를 새로 만들지 않게 합니다.
대신 적절한 스킬을 찾고, 필요한 부분을 읽고, 실행 환경에 맞게 따릅니다.

논문은 스킬을 세 요소로 설명합니다.

Operational Procedure

작업의 뼈대입니다.

예시:

• 어떤 단계로 나눌지
• 어떤 순서로 실행할지
• 어디서 검증할지
• 언제 멈출지

이 절차가 외부화되면 실행은 덜 즉흥적이 됩니다.

Decision Heuristics

분기 상황에서의 판단 기준입니다.

예시:

• 실패하면 무엇을 먼저 확인할지
• 어떤 증거가 충분한지
• 언제 사용자 승인을 받을지
• 여러 경로 중 무엇을 우선할지

휴리스틱은 스킬의 “전문가 스타일”에 가깝습니다.

Normative Constraints

허용 가능한 실행의 경계입니다.

예시:

• 테스트를 반드시 통과해야 함
• 민감 정보에 접근하지 말 것
• 특정 파일은 수정하지 말 것
• 위험 작업은 승인 후 실행할 것

좋은 스킬은 단순히 일을 잘하는 방법만 담지 않습니다.
어떤 방식으로 해야 안전하고 조직 규칙에 맞는지도 담습니다.

주목할 영역: 가운데 Skill Artifact가 절차, 휴리스틱, 제약을 함께 담는 부분을 보면, 스킬이 단순 명령어가 아니라 재사용 가능한 전문성 패키지라는 점이 드러납니다.

도구와 스킬은 다르다

이 논문에서 중요한 구분이 있습니다.

도구는 “무엇을 실행할 수 있는가”를 제공합니다.
스킬은 “그 도구들을 어떻게 묶어 일을 완수할 것인가”를 제공합니다.

예를 들어 코드 검색 도구, 파일 편집 도구, 테스트 실행 도구가 있다고 합시다.
이것만으로는 “버그를 안정적으로 고치는 절차”가 생기지 않습니다.

스킬은 다음을 정합니다.

• 먼저 재현할 것
• 관련 파일을 찾을 것
• 최소 수정할 것
• 테스트를 돌릴 것
• 실패하면 원인을 좁힐 것
• 최종 변경 내용을 요약할 것

도구는 실행 단위입니다.
스킬은 절차 단위입니다.

스킬 시스템의 핵심 기능

스킬은 단순히 저장되어 있으면 부족합니다.
실행 중에 쓸 수 있어야 합니다.

논문은 다섯 가지 기능을 강조합니다.

• Specification: 스킬의 범위, 전제, 제약을 명시합니다.
• Discovery: 현재 작업에 맞는 스킬을 찾습니다.
• Progressive Disclosure: 처음부터 모든 내용을 넣지 않고, 필요할 때 자세한 내용을 로드합니다.
• Execution Binding: 스킬을 도구, 파일, API, 서브에이전트에 연결합니다.
• Composition: 여러 스킬을 조합해 더 큰 작업을 수행합니다.

스킬의 위험도 있습니다.

• 설명과 실제 행동이 어긋날 수 있습니다.
• 환경 변화로 오래된 스킬이 틀릴 수 있습니다.
• 여러 스킬 조합이 예상치 못한 보안 문제를 만들 수 있습니다.
• 긴 작업 중 과거 컨텍스트가 새 스킬 지침과 충돌할 수 있습니다.

따라서 스킬은 정적인 문서가 아닙니다.
실행 기록을 통해 계속 수정되고 폐기되고 재구성되어야 합니다.

Protocols: 상호작용을 외부화하기

프로토콜은 에이전트의 상호작용 부담을 해결합니다.

LLM이 도구를 써야 한다고 판단해도, 실제 호출에는 많은 세부사항이 필요합니다.

• 어떤 형식으로 호출할지
• 어떤 인자를 넣을지
• 결과는 어떤 구조로 받을지
• 권한은 충분한지
• 실패하면 어떤 상태로 넘어갈지
• 다른 에이전트에게 위임할 때 무엇을 넘길지

이것을 프롬프트만으로 처리하면 취약합니다.
프로토콜은 상호작용을 명시적인 계약으로 바꿉니다.

논문은 프로토콜이 외부화하는 내용을 네 가지로 정리합니다.

Invocation Grammar

호출 문법입니다.

도구 이름, 인자 이름, 타입, 반환 구조를 정합니다.
모델은 형식을 추측하지 않고 필드를 채웁니다.

Lifecycle Semantics

상태 전이 규칙입니다.

누가 다음에 행동할지, 작업이 진행 중인지 완료인지 실패인지, 어떤 다음 행동이 허용되는지 정합니다.

Permission and Trust Boundaries

권한과 신뢰 경계입니다.

어떤 데이터에 접근할 수 있는지, 어떤 작업은 승인이 필요한지, 어떤 결과를 감사할 수 있어야 하는지 정합니다.

Discovery Metadata

사용 가능한 기능을 찾기 위한 메타데이터입니다.

에이전트는 프롬프트에 숨은 설명을 읽는 대신, 등록된 기능 카드나 스키마를 통해 무엇을 호출할 수 있는지 확인합니다.

주목할 영역: API 하드코딩에서 표준 프로토콜로 넘어가는 흐름을 보면, 프로토콜의 가치는 단순 연결이 아니라 상호작용을 재사용 가능하고 감사 가능한 구조로 만드는 데 있음을 알 수 있습니다.

프로토콜의 주요 범주

논문은 프로토콜을 상호작용 대상에 따라 나눕니다.

Agent-Tool Protocols

에이전트와 도구 사이의 프로토콜입니다.
대표적으로 MCP가 언급됩니다.

역할은 명확합니다.

• 도구 발견
• 스키마 확인
• 구조화된 호출
• 표준화된 응답 처리

Agent-Agent Protocols

에이전트와 에이전트 사이의 프로토콜입니다.

역할은 다음과 같습니다.

• 다른 에이전트의 능력 발견
• 작업 위임
• 진행 상태 공유
• 결과 반환
• 스트리밍 업데이트

여기서는 단순 메시지가 아니라 위임의 의미와 상태가 중요합니다.

Agent-User Protocols

에이전트와 사용자 인터페이스 사이의 프로토콜입니다.

역할은 다음과 같습니다.

• 사용자에게 어떤 상태를 보여줄지
• 도구 실행 중 상태를 어떻게 스트리밍할지
• 인터페이스를 어떤 안전한 형식으로 렌더링할지

Domain Protocols

특정 도메인에 맞춘 프로토콜입니다.

예를 들어 결제, 커머스, 신원 확인, 규제 준수 같은 영역에서는 일반 도구 호출보다 강한 증거와 권한 관리가 필요합니다.

프로토콜의 핵심은 “모델이 더 잘 말하게 하는 것”이 아닙니다.
모델의 행동이 시스템 경계를 넘을 때, 그 행동을 검증 가능하게 만드는 것입니다.

Harness: 외부화된 인지를 하나의 실행 환경으로 묶기

하네스는 이 논문의 중심 개념입니다.

하네스는 메모리, 스킬, 프로토콜을 담는 단순 컨테이너가 아닙니다.
그것들이 실제 작업에서 함께 작동하도록 만드는 실행 환경입니다.

하네스는 다음을 결정합니다.

• 어떤 메모리를 읽을지
• 어떤 스킬을 로드할지
• 어떤 도구 호출을 허용할지
• 어떤 작업은 승인을 요구할지
• 언제 중단할지
• 실패 기록을 어디에 쓸지
• 어떤 로그를 남길지
• 다음 실행에 무엇을 반영할지

논문은 하네스를 여섯 가지 설계 차원으로 분석합니다.

Agent Loop and Control Flow

에이전트의 기본 루프입니다.

관찰하고, 검색하고, 계획하고, 행동하고, 결과를 보고, 다시 조정합니다.
하네스는 이 루프가 무한히 돌지 않도록 제한합니다.

예시:

• 최대 단계 수
• 재귀 깊이
• 비용 한도
• 타임아웃

Sandboxing and Execution Isolation

실행 격리입니다.

에이전트가 파일을 쓰거나 명령어를 실행하거나 외부 API를 호출할 때, 환경을 제한합니다.
이는 보안 장치이면서 동시에 인지적 경계입니다.

불필요한 상태를 줄이고, 위험한 행동을 막고, 실패를 재현 가능하게 만듭니다.

Human Oversight and Approval Gates

인간 승인 지점입니다.

모든 작업을 완전 자율로 맡기기는 어렵습니다.
따라서 하네스는 위험한 행동 앞에서 멈추고 승인을 요구할 수 있어야 합니다.

예시:

• 실행 전 승인
• 실행 후 검토
• 위험 신호 발생 시 중단
• 특정 도구 호출에 대한 승인 게이트

Observability and Structured Feedback

관찰성입니다.

에이전트가 무엇을 보고, 어떤 메모리를 읽고, 어떤 도구를 호출하고, 어디서 실패했는지 기록해야 합니다.

이 기록은 두 가지에 쓰입니다.

• 사람이 디버깅하고 감사합니다.
• 시스템이 메모리와 스킬을 개선합니다.

Configuration, Permissions, and Policy Encoding

정책 인코딩입니다.

조직 규칙을 프롬프트에만 넣으면 약합니다.
하네스는 권한과 정책을 설정 파일, 프로젝트 규칙, 조직 규칙으로 분리해 집행합니다.

Context Budget Management

컨텍스트 예산 관리입니다.

메모리, 스킬, 프로토콜 스키마, 도구 설명은 모두 같은 컨텍스트 창을 차지합니다.
하네스는 무엇을 지금 넣고, 무엇을 나중에 넣고, 무엇을 요약할지 결정합니다.

주목할 영역: Memory·Skills·Protocols와 Permission·Control·Observability가 같은 고리 안에 배치된 부분을 보면, 하네스가 능력 확장과 실행 통제를 동시에 담당한다는 점이 보입니다.

세 모듈은 따로 움직이지 않는다

논문의 후반부는 메모리, 스킬, 프로토콜의 상호작용을 분석합니다.

핵심은 간단합니다.
세 모듈은 서로의 입력이자 출력입니다.

Memory → Skill

반복된 경험은 스킬로 승격될 수 있습니다.

실패 기록과 성공 기록이 쌓이면, 하네스는 그중 일반화 가능한 패턴을 찾아 절차로 만듭니다.

Skill → Memory

스킬 실행은 다시 기록을 남깁니다.

어떤 스킬이 잘 작동했는지, 어디서 실패했는지, 어떤 조건에서 위험했는지가 메모리에 저장됩니다.

Skill → Protocol

스킬은 실제 행동으로 이어져야 합니다.

그 행동은 도구 호출, API 호출, 파일 조작, 서브에이전트 위임처럼 프로토콜화된 인터페이스를 통해 실행됩니다.

Protocol → Skill

표준화된 인터페이스가 생기면, 그 인터페이스를 잘 쓰는 절차가 스킬로 만들어질 수 있습니다.

즉, 좋은 프로토콜은 새로운 스킬 생태계를 가능하게 합니다.

Memory → Protocol

과거 경험은 어떤 프로토콜 경로를 선택할지에 영향을 줍니다.

예를 들어 특정 도구가 어떤 작업에서 반복적으로 실패했다면, 하네스는 다른 도구나 다른 에이전트를 선택할 수 있습니다.

Protocol → Memory

도구 결과, 승인 이벤트, 실패 메시지, 위임 결과는 다시 메모리로 들어갑니다.

이 과정을 제대로 하지 않으면 에이전트는 실제 상호작용 이력을 잃습니다.

주목할 영역: Memory·Skill·Protocol 사이의 순환 화살표를 보면, 외부화된 모듈들이 독립 부품이 아니라 지속적으로 서로를 갱신하는 피드백 시스템임을 확인할 수 있습니다.

모델 내부 능력과 외부화 능력의 균형

논문은 모든 것을 외부화하라고 말하지 않습니다.

중요한 것은 분할입니다.
어떤 부담은 모델 안에 두는 것이 낫고, 어떤 부담은 밖으로 빼는 것이 낫습니다.

밖으로 빼기 좋은 것

업데이트가 자주 필요한 것은 외부화에 적합합니다.

• 최신 API 정보
• 조직 정책
• 프로젝트별 절차
• 사용자 선호
• 작업 상태
• 권한 규칙
• 감사 가능한 실행 기록

이런 정보는 모델 파라미터 안에 두면 바꾸기 어렵습니다.

모델 안에 두기 좋은 것

안정적이고 일반적인 능력은 모델 내부에 두는 것이 효율적입니다.

• 언어 이해
• 일반 추론
• 상식적 판단
• 다양한 표현 생성
• 넓은 범위의 개념 연결

이런 능력은 매번 외부에서 가져오면 오히려 느리고 복잡해질 수 있습니다.

외부화의 비용

외부화는 공짜가 아닙니다.

• 검색이 느려질 수 있습니다.
• 너무 많은 스킬이 컨텍스트를 잡아먹을 수 있습니다.
• 도구와 프로토콜이 많아지면 선택이 어려워집니다.
• 메모리 오염과 스킬 주입 같은 보안 위험이 커집니다.

따라서 좋은 하네스는 “많이 외부화한 시스템”이 아닙니다.
필요한 부담만 밖으로 빼고, 실행을 더 단순하게 만든 시스템입니다.

미래 방향

논문은 외부화가 앞으로 더 넓어질 것이라고 봅니다.

계획과 목표 관리의 외부화

현재 많은 에이전트는 계획을 컨텍스트 안에서 즉석으로 만듭니다.
앞으로는 계획 자체가 저장, 수정, 공유 가능한 하네스 객체가 될 수 있습니다.

평가와 검증의 외부화

모델이 스스로 “괜찮다”고 판단하는 것만으로는 부족합니다.
검증 기준, 루브릭, 테스트 절차를 외부화하면 실행 중 품질 관리가 더 명확해집니다.

하네스 자체의 자기 개선

메모리 정책, 스킬 라우팅, 프로토콜 선택, 실행 순서도 조정 대상이 될 수 있습니다.
즉, 하네스가 자신을 개선하는 방향입니다.

다만 위험도 커집니다.
하네스가 잘못 진화하면 오히려 기존 안정성을 무너뜨릴 수 있습니다.

멀티모달 외부화

텍스트뿐 아니라 이미지, 영상, 오디오, 화면 상태도 메모리와 스킬의 대상이 됩니다.

예를 들어 GUI 조작 스킬은 시각적 절차를 포함해야 합니다.
멀티모달 메모리는 텍스트 로그뿐 아니라 시각 경험을 색인하고 검색해야 합니다.

로봇과 물리 세계로 확장

논문은 외부화 논리가 디지털 에이전트에만 머물지 않는다고 봅니다.

로봇에서는 고수준 모델이 계획을 맡고, 저수준 VLA 모델이나 제어 모듈이 조작 스킬을 맡는 구조가 가능합니다.
이는 디지털 에이전트의 하네스 구조와 유사합니다.

계획은 외부화된 상태로 관리됩니다.
조작은 재사용 가능한 스킬로 실행됩니다.
에이전트와 모듈 사이의 통신은 프로토콜로 연결됩니다.

실무적으로 얻을 수 있는 교훈

이 논문은 에이전트 시스템을 설계할 때 유용한 기준을 줍니다.

1. 프롬프트만 늘리지 말 것

긴 프롬프트는 문제를 해결하기보다 새 문제를 만들 수 있습니다.
중요한 것은 컨텍스트 길이가 아니라 구조입니다.

2. 메모리는 저장소가 아니라 선택 시스템으로 볼 것

좋은 메모리는 많이 기억하는 시스템이 아닙니다.
현재 판단에 필요한 상태를 정확히 꺼내는 시스템입니다.

3. 스킬은 “잘 쓴 프롬프트”가 아니라 운영 자산으로 관리할 것

스킬에는 버전, 범위, 전제, 실패 사례, 보안 검토가 필요합니다.

4. 프로토콜은 연결보다 거버넌스가 중요하다

도구를 호출할 수 있는 것만으로는 부족합니다.
어떤 권한으로, 어떤 상태에서, 어떤 증거를 남기며 호출하는지가 중요합니다.

5. 하네스는 에이전트의 실제 제품 품질을 좌우한다

기초 모델이 같아도 하네스가 다르면 결과는 크게 달라집니다.
실패 복구, 승인 흐름, 로그, 컨텍스트 관리가 장기 신뢰성을 결정합니다.

결론

이 논문의 핵심은 명확합니다.

LLM 에이전트의 신뢰성은 모델 내부 능력만으로 설명되지 않습니다.
점점 더 많은 능력이 모델 바깥의 구조로 이동하고 있습니다.

• 메모리는 시간을 다룹니다.
• 스킬은 절차를 다룹니다.
• 프로토콜은 상호작용을 다룹니다.
• 하네스는 이 셋을 실행 가능한 환경으로 묶습니다.

외부화는 단순한 기능 추가가 아닙니다.
모델이 풀어야 하는 문제의 형태를 바꾸는 설계 원리입니다.

따라서 앞으로의 에이전트 발전은 더 큰 모델만의 문제가 아닙니다.
모델과 외부 인프라가 어떻게 함께 진화하는가의 문제입니다.

좋은 에이전트는 더 많은 것을 “머릿속에 아는” 시스템이 아닙니다.
필요한 것을 적절한 외부 구조에 두고, 그 구조를 안정적으로 활용하는 시스템입니다.

Source

• Chenyu Zhou et al. (2026). Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering. arXiv:2604.08224v1. April 10, 2026.
• https://arxiv.org/abs/2604.08224
• https://arxiv.org/pdf/2604.08224v1