에이전트 메모리와 하네스 엔지니어링 — Total Recall

URL: https://www.youtube.com/watch?v=xs-ob87TTzg 날짜: 2026-09-19 채널: aiDotEngineer 발표: Ignacio Martinez, Oracle AI Developer Advocate

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==에이전트의 신뢰성은 모델의 가중치만으로 결정되지 않으며, 모델을 둘러싼 메모리·도구·검색·컨텍스트·실행 루프를 설계하는 하네스가 비결정적 추론을 반복 가능하고 관찰 가능한 시스템으로 바꾼다.==

• 모델(Reasoning)은 대부분 가중치가 고정된 채 제공되므로 애플리케이션 개발자가 직접 통제하기 어렵다.
• 하네스는 데이터와 도구를 연결하고, 필요한 정보만 컨텍스트에 넣으며, 실패를 복구하고, 성공한 작업을 재사용 가능한 기억과 스킬로 승격한다.
• 파일은 모델과 운영체제에 친화적인 단기 작업 공간이고 데이터베이스는 트랜잭션·백업·벡터 검색·고가용성을 제공하므로 둘을 함께 쓰는 하이브리드 구조가 현실적인 선택이다.

에이전트는 대규모 언어 모델(LLM)과 하네스의 결합이다. LLM은 추론을 담당하지만 동일한 입력에 다른 결과를 낼 수 있고, 하네스는 저장·검색·도구 호출·오류 복구·컨텍스트 조립을 담당해 그 변동성을 업무에 쓸 수 있는 수준으로 제어한다.

1. 에이전트 스택과 에이전트의 정의

1.1. 다섯 층으로 보는 AI 에이전트

1. 애플리케이션 층

   1. 사용자가 실제로 상호작용하는 제품 표면이며, 챗 인터페이스나 업무 애플리케이션으로 나타난다.
   2. 에이전트의 내부 구성보다 사용자에게 제공되는 결과와 경험을 책임진다.

2. 데이터 층

   1. 메모리, 지식, 인코딩, 검색, 검색 결과의 재순위화(reranking), 리트리벌이 모이는 층이다.
   2. 에이전트 하네스가 가장 밀접하게 붙어 있고, 애플리케이션 개발자가 가장 많이 통제할 수 있는 영역이다.

3. 모델 층

   1. 대규모 언어 모델이 추론을 수행하는 층이며, 일반적인 서비스 이용자는 가중치를 직접 바꾸지 못한다.
   2. 모델 인터페이스가 OpenAI 프로토콜이나 Anthropic API 규격처럼 표준화되면 하네스에서 모델을 교체할 수 있다.

4. 인프라 층

   1. 오케스트레이션과 모델 서빙을 담당하며, 필요한 추론 노력에 따라 어떤 모델을 선택할지 결정한다.
   2. 하네스 내부의 에이전트 루프와 컨텍스트 조립도 이 층과 연결된다.

5. 컴퓨트 층

   1. 클라우드, GPU, 데이터베이스 엔진이 실제 연산과 저장을 제공한다.
   2. 애플리케이션·모델·인프라·컴퓨트는 점점 상품화되지만, 데이터와 그 데이터에 대한 설계는 차별화 여지가 남는다.

1.2. AI 애플리케이션의 네 가지 형태

1. LLM 챗봇

   1. 사용자가 질문할 때 응답하는 수동적(passive) 형태다.
   2. 지속적인 백그라운드 처리나 자율 행동보다 대화 응답이 중심이다.

2. 검색 증강 생성(RAG) 애플리케이션

   1. 문서를 인코딩하고 검색하는 백그라운드 작업을 수행하므로 챗봇보다 반수동적(semi-passive)이다.
   2. 질문 임베딩과 문서 벡터를 비교하고, 관련 결과를 재순위화해 모델에 제공한다.

3. LLM 기반 워크플로

   1. 정해진 단계와 모델 호출을 조합해 자동화(automation)를 제공한다.
   2. 절차가 고정된 영역에서 예측 가능성을 확보하기 좋다.

4. AI 에이전트

   1. 도구와 환경을 관찰하고 계획을 세우며 행동하는 자율성(autonomy)을 제공한다.
   2. 실용적인 에이전트는 자동화의 신뢰성과 자율성의 유연성을 함께 사용한다.

1.3. 하네스가 모델의 비결정성을 다루는 방식

1. 에이전트 = 모델 + 하네스

   1. 모델은 추론을 담당하고, 데이터베이스나 파일은 기억을 제공하며, 도구는 행동을 확장하고, 입력은 환경 인식을 제공한다.
   2. 모델만 가진 시스템은 외부 데이터나 도구에 접근하지 못하므로 실제 업무를 수행할 수 없다.

2. 하네스 엔지니어링의 목표

   1. 같은 입력에서 항상 똑같은 출력을 강제하기보다, 반복해서 신뢰할 수 있고 예측 가능한 결과를 얻도록 주변 시스템을 설계한다.
   2. 모델을 교체할 수 있는 공통 인터페이스를 두고, 개발자의 통제력이 있는 메모리·도구·지각·루프에 투자를 집중한다.

2. 데이터 연결과 하네스 구성 요소

2.1. Gateway와 MCP가 연결하는 외부 세계

1. 게이트웨이의 역할

   1. 대규모 언어 모델을 데이터와 도구에 연결하는 관문이며, 모델을 고립된 텍스트 생성기로 남겨두지 않는다.
   2. 메모리, 시맨틱 계층, 리트리벌, 컨텍스트, 도구, 스킬이 이 관문 위에 구성된다.

2. Outlook 연결 사례

   1. 모델이 컴퓨터의 Outlook에 직접 접근하지 못하더라도 MCP 서버에 함수를 정의하면 통신 경로를 만들 수 있다.
   2. 모델은 MCP가 노출한 함수와 매개변수를 호출해 외부 프로그램을 읽거나 조작한다.

2.2. 하네스가 다루는 핵심 층

1. 스토리지 계층

   1. 메모리가 물리적으로 어디에 살지 정하고 파일, 데이터베이스 또는 둘의 조합을 선택한다.
   2. 동시 에이전트 수와 데이터 수명에 따라 단기 작업 데이터와 장기 기억의 위치를 다르게 둘 수 있다.

2. 메모리 엔지니어링

   1. 인코딩, 검색, 리트리벌을 설계해 필요한 기억을 찾아오는 계층이다.
   2. 데이터 정규화와 중복 제거, 개인정보 비식별화, 메타데이터 관리가 검색 품질과 안전성을 좌우한다.

3. 시맨틱 계층

   1. 조직의 은어, 업무 규칙, 데이터 모델, 쿼리 방식, 메타데이터처럼 명시하지 않아도 팀 안에서는 통하는 지식을 담는다.
   2. 모델이 세상을 해석하는 렌즈를 제공하므로, 엔터프라이즈의 기관 지식과 트라이벌 지식을 재사용 가능하게 만든다.

4. 에이전트 루프

   1. 관찰(observe) → 추론(reason) → 행동(act)을 반복해 모델을 자율적인 에이전트로 바꾼다.
   2. 도구 오류나 잘못된 생성이 생겨도 루프가 즉시 종료되지 않도록 실패 내성을 넣는다.

5. 컨텍스트 엔지니어링

   1. 현재 작업에 가장 관련 있는 정보·도구·스킬만 골라 컨텍스트에 조립한다.
   2. 매 루프 반복마다 컨텍스트를 다시 구성하고, 더 이상 필요하지 않은 항목은 제거해 컨텍스트의 유효성을 유지한다.

6. 지속 학습(continual learning)

   1. 모델 가중치를 바꾸지 않고 임베딩·재순위화·컨텍스트·스킬을 개선해 시간이 지날수록 행동을 바꾼다.
   2. 수백만 달러와 대규모 GPU가 필요한 파인튜닝보다 현실적인 비용으로 모델의 체감 성능을 개선한다.

2.3. RAG의 데이터 처리 파이프라인

1. 문서에서 벡터까지

   1. 문서를 토큰화하고 청크로 나눈 뒤 임베딩 모델로 벡터를 만든다.
   2. 중복 제거, 데이터 정규화, 개인정보(PII) 삭제를 거쳐 텍스트, JSON 메타데이터, 32비트 밀집 벡터를 저장한다.

2. 질의에서 답변까지

   1. 사용자 질문도 임베딩해 벡터 저장소의 문서 벡터와 비교하고 관련성이 높은 후보를 찾는다.
   2. 크로스 인코더를 재순위화 모델로 사용해 질문과 후보 결과를 함께 평가한 뒤 모델에 전달한다.

3. 분산 스택의 비용

   1. 텍스트·메타데이터·벡터마다 별도 데이터베이스를 붙이면 동기화 로직과 유지보수 부담이 커진다.
   2. 한 엔진과 한 쿼리 인터페이스에 다양한 데이터 유형을 모으면 보안 대상과 개발 스택도 단순해진다.

3. 파일과 데이터베이스를 결합하는 메모리 설계

3.1. 파일이 제공하는 장점과 한계

1. 파일의 장점

   1. 파일은 모델의 기본 동작과 잘 맞고 생성·삽입·추가가 쉽다.
   2. POSIX 의미론을 따르므로 Debian, Ubuntu 같은 운영체제와 자연스럽게 연동된다.

2. 동시성 문제

   1. 8·16·32개 에이전트가 같은 파일을 동시에 읽고 수정하면 트랜잭션 일관성이 보장되지 않는다.
   2. 현재 실무의 우회책은 에이전트별 Git worktree에서 작업한 뒤 구현 완료 시 main으로 병합하는 방식이다.

3. 검색과 복구의 한계

   1. 파일만으로는 하이브리드 검색을 구현하기 어렵고, 정규식 같은 제한적인 매칭에 의존하기 쉽다.
   2. 운영체제가 손상되면 백업과 복제가 없는 파일 데이터가 함께 사라진다.

3.2. 데이터베이스가 제공하는 장점

1. 트랜잭션과 가용성

   1. ACID는 원자성·일관성·고립성·내구성을 보장해 여러 에이전트의 동시 변경을 안전하게 처리한다.
   2. 데이터베이스를 여러 지역에 복제하면 고가용성과 장애 대응 능력을 얻을 수 있다.

2. AI 검색 기능

   1. 벡터 검색과 하이브리드 검색을 데이터베이스 안에서 수행할 수 있다.
   2. 파일과 달리 백업·보안·복제·관계형 질의를 같은 운영 경계 안에서 관리할 수 있다.

3.3. Oracle DBFS와 하이브리드 메모리

1. DBFS의 결합

   1. Oracle DBFS(Database File System)는 파일을 데이터베이스 안의 파일 시스템처럼 저장한다.
   2. 파일의 사용성과 데이터베이스의 ACID 트랜잭션, 벡터 검색, 관계형 기능, 보안, 고가용성을 같은 코어에서 제공한다.

2. 메모리 수명에 따른 배치

   1. 코딩 에이전트의 현재 to-do처럼 곧 사라질 단기 기억은 파일에 두는 편이 모델과 운영체제에 자연스럽다.
   2. 사용자 선호도나 반복적으로 재사용될 지식은 구조화된 데이터베이스의 장기 기억으로 승격한다.

3. Oracle 개발 구성 요소

   1. langchain-oracledb는 벡터 저장소 삽입·검색·리트리벌을 LangChain에서 쉽게 연결한다.
   2. 인-데이터베이스 임베딩은 임베딩 모델을 데이터베이스 내부에 두어 외부 서비스 호출을 줄이고 데이터 보존·보안을 강화한다.

4. 에이전트 메모리와 컨텍스트의 수명

4.1. 메모리의 정의와 세 가지 범주

1. 메모리의 목적

   1. 에이전트 메모리는 정보를 보존(retain), 재호출(recall), 재사용(reuse), 정제(refine)하는 모든 메커니즘과 시스템이다.
   2. 세 시간 걸린 문제를 다음번에는 더 쉽게 풀게 만드는 기록과 추출이 메모리의 실용적 가치다.

2. 단기·장기·공유 메모리

   1. 단기 메모리는 현재 코딩 작업의 to-do처럼 일시적인 상태를 담고 장기 보존을 요구하지 않는다.
   2. 공유 메모리는 서브에이전트와 부모 에이전트, 또는 여러 에이전트가 하나의 문제를 협업할 때 교환하는 상태다.

3. 에피소드·절차 메모리

   1. 과거 대화와 문제 해결 경험은 에피소드 메모리로 보존해 다음 작업에서 워크플로와 스킬을 개선한다.
   2. 성공한 프런트엔드 작업처럼 재사용 가능한 절차는 절차 메모리로 바꿔 비슷한 결과를 반복 생성한다.

4.2. 컨텍스트 윈도우가 메모리의 전부가 될 수 없는 이유

1. 컨텍스트는 단기 메모리다

   1. 큰 컨텍스트 창은 현재 대화와 즉시 필요한 자료를 유지하지만 장기 지식과 반복 가능한 절차를 대신하지 못한다.
   2. 컨텍스트가 커질수록 각 항목에 할당되는 주의가 줄어들어 관련 정보가 묻힌다.

2. 컨텍스트 로트(context rot)

   1. 대화 초반에는 정보가 적어 모델이 문제에 집중하지만, 대화를 수 시간 이어가면 오래된 정보와 새 정보가 서로 주의를 나눈다.
   2. 어텐션 행렬은 토큰마다 다른 모든 토큰을 참조하므로 컨텍스트 크기에 따라 계산과 주의 분산이 제곱 규모로 커진다.

3. 운영 원칙

   1. 현재 목표에 기여하는 정보만 검색하고 컨텍스트에 넣어 작업의 현저성(salience)을 유지한다.
   2. 장기 기억은 외부 저장소에 두고 필요할 때 리트리벌해 컨텍스트 창을 작게 유지한다.

4.3. Oracle AI Agent Memory Package와 Context Card

1. Context Card의 구조

   1. 토픽은 모델이 대화의 방향을 잡도록 하고, 요약은 스레드를 압축하면서 현재 에이전트 의도를 기록한다.
   2. 관련 정보는 사실(facts), 선호(preferences), 기억(memories)으로 나뉘고, 에피소드 메모리는 아직 답하지 못한 질문을 추적하며 최근 메시지는 국소 컨텍스트를 제공한다.

2. 하네스 추상화

   1. Context Card는 모델에 무작정 붙이는 원문이 아니라 하네스가 모델에 무엇을 넣을지 결정하는 구조화된 중간 표현이다.
   2. Python의 단일 호출로 관련 내용을 조립해 AI 엔지니어와 에이전트의 인지 부하를 줄인다.

3. 관리형 메모리의 가치

   1. 직접 구현하면 언제 압축·요약할지, 무엇을 남길지, 어떤 추출기를 쓸지, 토큰을 얼마나 쓸지 모두 결정해야 한다.
   2. OAMP(Oracle AI Agent Memory Package)는 이런 결정을 관리형 구성 요소로 묶어 하네스 개발자가 업무 로직과 결과에 집중하게 한다.

5. 시맨틱 렌즈, 에이전트 루프, 지속 개선

5.1. Umwelt와 기업 지식의 시맨틱 계층

1. 환경을 보는 렌즈

   1. Jakob von Uexküll의 Umwelt 개념은 생물이 접근할 수 있는 감각과 환경의 렌즈를 통해 현실을 지각한다는 뜻이다.
   2. 에이전트의 시맨틱 계층은 모델이 조직의 업무 현실을 해석하는 인공적인 Umwelt다.

2. 암묵지를 명시화하기

   1. 동료 사이에서 설명하지 않는 회사의 은어, 데이터 모델, 쿼리 실행 규칙, 메타데이터가 시맨틱 계층에 들어간다.
   2. 조직 지식을 명시화하면 새 에이전트도 숙련된 동료가 가진 전제와 맥락을 재사용할 수 있다.

5.2. 최소 에이전트 루프와 컨텍스트 조립

1. 관찰·추론·행동 반복

   1. 에이전트 루프는 환경을 관찰하고, 모델이 다음 행동을 추론하고, 도구를 실행하는 드라이버다.
   2. 이 반복이 모델에 독립성과 자율성을 부여하지만, 반복 횟수와 실패 처리를 하네스가 통제해야 한다.

2. Toolbox와 Skillbox 패턴

   1. 사용 가능한 도구와 스킬의 설명을 저장하고 필요할 때만 리트리벌해 컨텍스트에 넣는다.
   2. 각 반복에서 해당 도구가 현재 문제에 필요한지 재평가하고, 필요 없어진 항목은 임시로 제거한다.

3. 실패 내성

   1. SQL 생성 오류나 잘못된 도구 호출이 발생해도 루프가 종료되지 않고 수정된 시도를 이어가야 한다.
   2. 다만 무한 재시도는 비용을 폭증시키므로 모델별 인내도와 최대 도구 호출 수를 설정해야 한다.

5.3. 스킬·워크플로 승격을 통한 지속 학습

1. 표현 공간의 개선

   1. 모델 가중치를 바꾸지 않아도 임베딩과 재순위화 모델을 개선해 검색 결과의 표현과 선택을 바꿀 수 있다.
   2. 컨텍스트와 토큰 공간을 조정하는 방법은 비용이 낮고 대부분의 팀이 바로 시도할 수 있다.

2. 스킬 승격(skill promotion)

   1. 몇 시간 동안 성공적으로 수행한 작업의 대화와 결과를 기억에서 회수해 재사용 가능한 스킬로 만든다.
   2. 증류(distillation) 과정으로 기존 skill.md보다 조직의 말투·선호 라이브러리·선호 데이터베이스를 반영한 새 버전을 만들고 이전 버전을 교체한다.

3. 워크플로 승격

   1. 한 번 성공한 절차를 반복 가능한 워크플로로 저장하면 다음 작업의 품질과 속도가 함께 개선된다.
   2. 선호도와 실제 성공 사례가 축적될수록 하네스는 특정 팀과 개인에 맞게 특화된다.

6. 워크숍 구현과 데모 흐름

6.1. 실습 환경

1. Codespaces 준비

   1. workshopwaitingroom.com에 GitHub 계정으로 등록하면 GitHub 저장소 초대장을 받고, 저장소에서 GitHub Codespaces를 생성한다.
   2. Codespaces는 약 5분 만에 환경을 준비하며, VS Code 사용자는 Python 3.12 커널을 선택해 학생 노트북을 실행한다.

2. 학생 노트북의 19개 할 일

   1. 모델만 있는 상태에서 OpenAI Completions API로 질문을 보내는 가장 단순한 단계부터 시작한다.
   2. 이후 검색·리트리벌·인코딩 등 하네스의 층을 하나씩 추가하며, 각 to-do에는 설명 문서와 해답이 제공된다.

3. Appbook

   1. Appbook은 완성된 하네스의 개별 구성 요소를 각각 시험하고, Codespaces에서 자동 배포된다.
   2. OCI Generative AI Service를 통해 Google·Meta·OpenAI·xAI 모델의 추론을 제공하며, 여러 모델을 관리하는 엔터프라이즈형 OpenRouter처럼 작동한다.

6.2. Total Recall 애플리케이션 데모

1. 질의와 관찰성

   1. show the total revenue by product category 질의를 입력하면 데이터베이스 질의와 도구 호출을 조합해 제품 카테고리별 총매출을 계산한다.
   2. Mission Control 화면은 선택된 도구, 로드된 스킬, 데이터 스키마, 데이터 소스, SQL 도구 호출, 토큰 수, 개별 에이전트 트레이스를 보여준다.

2. 오류 복구 사례

   1. 데모 질의는 16단계에 걸쳐 처리되며 중간에 오류를 감지했다.
   2. 에이전트 루프가 fault-tolerant하게 설계되어 오류에서 종료되지 않고 다음 시도를 수행해 최종 결과를 반환했다.

3. 메모리 관찰

   1. 사용자는 전체 컨텍스트 창과 토큰 사용량을 확인할 수 있다.
   2. OAMP가 Context Card를 어떻게 만들고 어떤 정보만 모델에 전달하는지 별도로 살펴볼 수 있다.

6.3. 도구 규모와 모델 선택에 관한 질의응답

1. 수천 개 도구의 검색

   1. Toolbox 패턴은 도구 설명을 벡터화하고 HNSW(Hierarchical Navigable Small World) 그래프 인덱스로 필요한 도구를 계층적으로 찾는다.
   2. 각 그래프 노드는 벡터 인덱스 또는 벡터 저장소이며, 이 방식은 파일보다 데이터베이스에서 구현하기 적합하다.

2. 규모에 대한 현실적인 기준

   1. 일반적인 읽기·쓰기·grep 같은 도구 호출은 보통 100~1,000개 수준이며, 수백만 사용자와 수백만 호출이 되기 전까지 검색 지연을 과도하게 걱정할 필요는 없다.
   2. HNSW 인덱스를 사용하면 2,000개 도구 질의와 10,000개 도구 질의를 같은 방식으로 처리할 수 있다.

3. 비슷한 도구 설명의 분리

   1. 서로 다른 회사의 도구 설명이 유사하면 LLM으로 도구의 docstring과 설명을 확장해 벡터 공간에서 분리 가능성을 높인다.
   2. 단순한 명명된 엔터티 인식보다 의미가 풍부한 설명을 만들어 유사한 도구 사이의 선택 정확도를 높인다.

4. 재시도 한도와 라우팅

   1. 무한 재시도는 비용을 만들고 환각 결과를 반복하므로, 사용한 frontier LLM 기준으로 최대 8~12회 도구 호출을 인내도(hysteresis) 한계로 둘 수 있다.
   2. 어려운 문제는 frontier LLM으로, 쉬운 문제는 오픈 웨이트 소형 언어 모델(SLM)으로 라우팅하면 토큰 비용과 지연을 낮출 수 있다.

5. 전문화된 소형 전문가의 조합

   1. 약 1억 파라미터 규모의 모델도 특정 문제 하나에는 매우 강할 수 있다.
   2. 집계기와 오케스트레이터가 질의 유형에 맞는 모델을 선택하면 하나의 거대 모델을 모든 작업에 쓰는 것보다 토큰 효율적인 하네스가 된다.

주요 발언 모음

“An AI agent is essentially a model plus a harness.”

“AI 에이전트는 본질적으로 모델과 하네스의 결합이다.”

“The harness is what we’re going to talk about.”

“우리가 집중할 대상은 하네스다.”

“You want to keep the context window as small as possible to avoid context rot.”

“컨텍스트 로트를 피하려면 컨텍스트 창을 가능한 한 작게 유지해야 한다.”

“The future is a mixture of small experts for each type of problem.”

“미래는 문제 유형별 소형 전문가들의 조합에 가깝다.”

핵심 데이터 & 수치

• 5개 에이전트 스택 층: 애플리케이션, 데이터, 모델, 인프라, 컴퓨트로 구성된다.
• 하네스 실습 단계: 모델 호출에서 시작해 검색·리트리벌·인코딩을 추가하는 총 19개 to-do를 수행한다.
• 동시 파일 작업 사례: 8·16·32개 에이전트가 같은 파일을 수정하면 트랜잭션 일관성 문제가 발생한다.
• 컨텍스트 로트: 컨텍스트가 커질수록 어텐션 행렬과 정보 간 주의 경쟁이 토큰 수에 따라 제곱 규모로 증가한다.
• 데모 처리량: 제품 카테고리별 총매출 질의가 16단계의 도구·SQL 흐름으로 처리된다.
• 도구 검색 규모: 일반 도구 호출은 100~1,000개 수준이며, HNSW는 2,000개와 10,000개 도구를 같은 검색 방식으로 다룬다.
• 도구 재시도 한도: frontier 모델의 정확도와 비용에 따라 최대 8~12회 호출 뒤 중단하는 인내도 값을 둔다.
• 전문화 모델 예시: 약 1억 파라미터의 소형 모델도 특정 유형의 문제에는 강력한 전문가가 될 수 있다.

실행 시사점

1. 에이전트 프로젝트의 첫 설계 문서는 모델 선택표가 아니라 데이터·메모리·도구·컨텍스트·실패 복구를 포함한 하네스 경계도여야 한다.
2. 현재 대화와 임시 to-do는 파일에 두고, 사용자 선호·성공한 절차·반복 가능한 지식은 데이터베이스 장기 메모리로 승격하는 수명 기반 저장 정책을 만든다.
3. RAG를 도입할 때 텍스트·JSON·벡터를 별도 서비스로 흩뜨리기 전에 동기화 비용과 보안 경계를 계산하고 통합 저장소의 이점을 비교한다.
4. 모든 도구와 스킬을 처음부터 컨텍스트에 넣지 말고 Toolbox·Skillbox 리트리벌로 현재 문제에 필요한 설명만 로드한다.
5. 에이전트 루프에 오류 복구와 최대 재시도·도구 호출 한도를 명시하고, 성공률·토큰·지연·호출 횟수를 함께 관찰한다.
6. 반복 성공한 대화와 절차를 skill.md 또는 워크플로로 증류해 팀의 말투, 라이브러리, 데이터베이스 선호가 반영된 절차적 메모리로 만든다.
7. 쉬운 작업에는 SLM을, 복잡한 작업에는 frontier LLM을 라우팅하고, 모델 교체가 하네스 수정으로 번지지 않도록 공통 API를 사용한다.
8. Context Card처럼 요약·사실·선호·기억·미해결 질문을 분리해 컨텍스트를 구성하면 장기 대화의 정보 부패를 줄일 수 있다.

결론

모델 가중치를 직접 바꾸는 일은 대부분의 팀에 비싸고 느리지만, 하네스는 개발자가 통제할 수 있는 시스템 경계다. 파일과 데이터베이스를 메모리 수명에 맞게 결합하고, MCP로 도구를 연결하고, 검색과 재순위화로 필요한 기억만 꺼내며, 루프마다 컨텍스트를 재조립하면 고정된 모델도 시간이 지날수록 더 유용해진다. 에이전트의 경쟁력은 가장 큰 모델을 고르는 데서 끝나지 않고, 조직의 지식과 성공한 작업을 안전하게 축적하고 재사용하는 하네스에서 나온다.

핵심 요약 (20줄)

에이전트의 실용적 성능은 모델 가중치보다 모델을 둘러싼 하네스 설계에 크게 좌우된다.

하네스는 메모리·도구·환경 입력·오류 복구를 모델의 추론과 연결해 반복 가능한 결과를 만든다.

AI 애플리케이션은 수동적인 LLM 챗봇부터 반수동적인 RAG, 자동화 워크플로, 자율 에이전트까지 네 가지 형태로 발전한다.

데이터 층은 애플리케이션·모델·인프라·컴퓨트보다 개발자가 차별화하기 쉬운 에이전트 스택의 중심이다.

Gateway와 MCP는 고립된 언어 모델을 Outlook 같은 외부 프로그램과 데이터에 연결한다.

하네스는 스토리지·메모리 엔지니어링·시맨틱 계층·에이전트 루프·컨텍스트 엔지니어링·지속 학습을 조합한다.

파일은 생성과 추가가 쉽고 운영체제와 잘 맞지만 동시성·백업·하이브리드 검색에 약하다.

데이터베이스는 ACID 트랜잭션·복제·고가용성·벡터 검색으로 다중 에이전트 상태를 안전하게 관리한다.

Oracle DBFS는 데이터베이스 안에 파일 시스템을 제공해 파일 사용성과 데이터베이스 안정성을 결합한다.

단기 to-do와 임시 상태는 파일에 두고 사용자 선호와 반복 지식은 장기 데이터베이스 메모리로 승격할 수 있다.

에이전트 메모리는 정보를 보존·재호출·재사용·정제해 다음 문제의 해결 비용을 낮춘다.

에피소드 메모리는 과거 대화를 보존하고 절차 메모리는 성공한 워크플로를 재사용 가능한 스킬로 바꾼다.

컨텍스트 로트는 정보가 많아질수록 각 토큰에 대한 주의가 분산되는 현상이다.

Context Card는 토픽·요약·사실·선호·기억·미해결 질문·최근 메시지를 구조화해 컨텍스트를 압축한다.

Umwelt에 해당하는 시맨틱 계층은 조직의 은어·데이터 모델·쿼리 규칙 같은 암묵지를 에이전트의 해석 렌즈로 만든다.

에이전트 루프는 관찰·추론·행동을 반복하며 오류가 생겨도 제한된 범위에서 복구를 시도한다.

Toolbox와 Skillbox는 필요한 도구와 스킬만 검색해 컨텍스트에 로드함으로써 토큰 낭비를 줄인다.

성공한 작업을 증류해 skill.md로 승격하면 모델 가중치를 바꾸지 않고도 팀 맞춤형 지속 학습을 구현할 수 있다.

HNSW 벡터 인덱스와 LLM 기반 도구 설명 확장은 수천 개 도구 중 올바른 도구를 찾는 문제를 완화한다.

하네스 내부의 모델 라우팅과 8~12회 재시도 한도는 비용·지연·정확도를 함께 관리하는 실행 정책이 된다.