에이전트 메모리와 하네스 엔지니어링 완전 정복

메타데이터

• 원문 제목: [한영자막] 토탈 리콜: 에이전트 메모리와 하네스 엔지니어링을 마스터해보세요
• URL: https://www.youtube.com/watch?v=DesSEX_9Z5A
• 날짜: 2026-09-23
• 채널: Tech Bridge
• 영상 ID: DesSEX_9Z5A
• 주제: 에이전트 메모리(Agent Memory), 하네스 엔지니어링(Harness Engineering), 컨텍스트 엔지니어링(Context Engineering), 지속 학습(Continual Learning)

---

📌 핵심 질문 / 에이전트의 신뢰성을 결정하는 것은 무엇인가

==언어 모델의 고정된 추론 능력을 바꿀 수 없다면, 메모리·도구·검색·컨텍스트·루프를 묶은 에이전트 하네스(Agent Harness)로 비결정적인 모델을 반복 가능하고 신뢰할 수 있는 시스템으로 바꿀 수 있다.==

• 언어 모델은 대체로 가중치가 고정된 ‘추론 코어’이며, 같은 입력에도 매번 다른 출력을 낼 수 있다.
• 데이터 계층은 애플리케이션·모델·인프라·컴퓨트보다 개발자가 훨씬 직접적으로 통제할 수 있는 영역이다.
• 파일과 데이터베이스를 경쟁 관계로 보지 않고, 단기 메모리는 파일에 두고 장기 메모리는 데이터베이스로 승격하는 하이브리드 구조가 실용적이다.
• 컨텍스트 창에 모든 것을 밀어 넣으면 컨텍스트 로트(Context Rot)가 발생하므로, 매 루프마다 필요한 도구와 스킬만 선택해 짧고 관련성 높은 컨텍스트를 만들어야 한다.

에이전트는 대규모 언어 모델(LLM)의 추론 능력 + 하네스의 나머지 모든 구성 요소다. 하네스는 저장소, 메모리 엔지니어링, 시맨틱 계층, 게이트웨이와 MCP, 도구·스킬, 에이전트 루프, 컨텍스트 엔지니어링을 연결한다. 목표는 모델 자체를 고치는 것이 아니라, 모델이 가진 비결정성을 견디면서도 자동화의 신뢰성과 자율성의 유연성을 함께 얻는 것이다.

1. 에이전트 스택과 AI 애플리케이션의 형태

1.1. 다섯 계층으로 보는 에이전트 스택

모든 AI 에이전트는 애플리케이션, 데이터, 모델, 인프라, 컴퓨트라는 다섯 계층 위에 올라간다.

1. 애플리케이션 계층

   1. 제품 표면: 사용자가 실제로 상호작용하는 화면·서비스·업무 흐름이다.
   2. 사용자 경험: 챗봇, 코드 도구, 데이터 분석 도구처럼 모델의 능력이 사용자에게 드러나는 지점이다.

2. 데이터 계층

   1. 구성 요소: 메모리, 지식, 인코딩, 검색, 검색 결과 회수(retrieval)가 포함된다.
   2. 통제 가능성: 모델은 빌려 쓰는 추론 코어에 가깝지만, 데이터의 저장·정제·검색·노출 방식은 조직이 직접 설계할 수 있다.
   3. 하네스의 자리: 에이전트 하네스는 데이터 계층과 매우 밀접하게 작동하며, 데이터가 에이전트의 반복 성능을 좌우한다.

3. 모델 계층

   1. 추론 코어: 대규모 언어 모델이 언어 이해와 다음 행동의 추론을 맡는다.
   2. 고정된 부분: 일반적으로 모델 가중치는 바뀌지 않는다. 수백만 달러, 많은 GPU, 긴 시간이 없다면 가중치를 직접 변경하기 어렵다.

4. 인프라 계층

   1. 오케스트레이션: 필요한 추론 노력에 따라 어떤 모델을 서비스할지, 어떤 작업을 어떤 경로로 보낼지 결정한다.
   2. 모델 라우팅: 쉬운 문제에는 작은 모델을, 복잡한 문제에는 프런티어 모델을 붙이는 구조가 가능하다.

5. 컴퓨트 계층

   1. 실행 자원: 클라우드·GPU와 데이터베이스 엔진이 포함된다.
   2. 상품화: 애플리케이션·모델·인프라·컴퓨트의 복잡성은 점점 플랫폼으로 흡수되고 있다. 상대적으로 차별화가 남는 곳은 데이터와 그 데이터를 다루는 하네스다.

1.2. 게이트웨이·MCP가 모델을 외부 세계에 연결하는 방식

1. 고립된 모델의 한계

   1. 외부 접근 부재: 언어 모델은 데이터와 도구에 접근하지 못하면 컴퓨터에서 실제 작업을 수행할 수 없다.
   2. 연결 계층: 게이트웨이와 MCP(Model Context Protocol)는 모델 하네스가 데이터와 도구를 호출하게 만드는 연결부다.

2. Outlook 사례

   1. 기능 명세: Outlook처럼 모델이 원래 접근할 수 없는 프로그램에 대해 MCP에서 호출할 함수들을 정의한다.
   2. 새로운 능력: 함수가 MCP에 등록되면 LLM은 Outlook과 통신하고, 외부 프로그램을 읽거나 조작할 수 있다.

3. 데이터 계층의 주변 구성

   1. 게이트웨이와 MCP 위의 기능: 메모리 계층, 시맨틱 계층, 검색 계층, 컨텍스트 계층, 도구와 스킬이 게이트웨이에 연결된다.
   2. 역할 분리: 모델은 무엇을 추론할지 결정하고, 하네스는 무엇을 볼 수 있는지와 어떤 행동을 실행할 수 있는지를 조절한다.

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

1. LLM 챗봇

   1. 수동성: 사용자가 질문할 때까지 기다리고, 질문에 답하는 수동적 형태다.
   2. 제한된 행동: 별도의 검색·도구 호출·지속 상태가 없다면 한 번의 질문과 한 번의 응답에 머문다.

2. RAG 애플리케이션

   1. 반수동성: 뒤에서 문서를 검색하고 처리하는 작업을 수행하므로 챗봇보다 적극적이다.
   2. 여전한 수동성: 사용자의 질문이 출발점이라는 점에서는 여전히 수동적이다.

3. LLM 기반 워크플로우

   1. 자동화: 정해진 단계와 규칙에 따라 작업을 자동으로 실행한다.
   2. 신뢰성: 자동화는 시스템이 같은 절차를 안정적으로 반복하도록 만든다.

4. AI 에이전트

   1. 자율성: 주변을 인식하고, 추론하고, 도구를 사용해 다음 행동을 선택한다.
   2. 실제 제품의 조합: Cloud Code 같은 현대적 AI 애플리케이션은 LLM 워크플로우의 자동화와 에이전트의 자율성을 함께 사용한다.

2. 에이전트와 하네스의 설계 원리

2.1. 에이전트의 정의와 목표

1. 에이전트의 구성식

   1. 추론: 대규모 언어 모델이 인지 기능과 추론을 담당한다.
   2. 기억: 데이터베이스나 파일이 정보를 보존하고 다시 꺼낸다.
   3. 행동: 도구가 외부 세계에 영향을 주는 수단이 된다.
   4. 지각: 입력과 환경 신호가 에이전트가 주변을 인식하도록 만든다.

2. 하네스의 구성식

   1. 에이전트 = 모델 + 하네스: 모델이 추론이고, 나머지 모든 설계가 하네스다.
   2. 통제 가능한 영역: 모델의 가중치보다 메모리·도구·지각·컨텍스트를 훨씬 쉽게 사용자화할 수 있다.
   3. 렌털 비유: 모델은 구독해서 빌리는 추론 능력이고, 하네스는 그 능력을 실제 업무에 맞춰 꾸미는 조직의 자산이다. 발표자는 세상에 있는 구독을 모두 신청하는 사람처럼 모델은 우리가 제공받는 것을 받아들일 수밖에 없다고 농담했다.

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

   1. 반복 가능성: 비결정적인 모델에 같은 입력을 줘도 매번 다른 답이 나올 수 있으므로, 출력이 안정적으로 재현되도록 주변 시스템을 설계한다.
   2. 자동화와 자율성의 결합: 자동화는 신뢰성을, 자율성은 유연성을 제공한다.
   3. 모델 교체성: OpenAI 프로토콜이나 Anthropic API 명세처럼 공통 인터페이스를 사용하면 모델을 교체할 수 있고, 하네스 설계는 유지할 수 있다.

2.2. 일곱 구성 요소의 개요

하네스는 모델 계층을 제외한 주변의 일곱 영역을 쌓아 올리는 구조로 설명된다.

1. 저장소 계층(Storage Layer): 메모리가 실제로 어디에 존재할지 결정한다.
2. 메모리 엔지니어링(Memory Engineering): 데이터를 인코딩하고, 검색하고, 회수하는 방식을 설계한다.
3. 시맨틱 계층(Semantic Layer): 조직 안에서 말하지 않아도 통하는 지식과 의미를 모델이 사용할 수 있는 형태로 만든다.
4. 게이트웨이와 MCP: 모델을 데이터 및 외부 도구에 연결한다.
5. 도구와 스킬(Tools and Skills): 에이전트가 실행할 수 있는 함수와 반복 가능한 작업 절차를 제공한다.
6. 에이전트 루프(Agent Loop): 관찰·추론·행동을 반복해 모델을 자율적 에이전트로 바꾼다.
7. 컨텍스트 엔지니어링(Context Engineering): 매 반복에서 가장 관련성 높은 정보·도구·스킬만 컨텍스트 창에 배치한다.

3. 저장소 계층: 파일과 데이터베이스의 하이브리드

3.1. 파일이 주는 장점과 한계

1. 파일이 모델의 본능에 잘 맞는 이유

   1. 생성의 용이성: 파일을 만들기 쉽고, 데이터를 삽입하거나 뒤에 추가하기 쉽다.
   2. 비구조성: 구조를 미리 강제하지 않아 모델이 자연스럽게 텍스트를 쓰고 운영체제와 상호작용할 수 있다.
   3. 이식성: POSIX 의미론을 따르므로 Debian, Ubuntu 등 여러 운영체제에서 동일한 방식으로 다룰 수 있다.

2. 파일의 약점

   1. 트랜잭션 일관성 부재: 여러 에이전트가 같은 파일을 동시에 수정하거나 삽입하면 원자적·격리된 갱신을 보장하기 어렵다.
   2. 백업과 가용성 부족: 운영체제가 손상되면 파일 데이터도 함께 잃을 수 있고, 기본적으로 여러 지역에 복제되지 않는다.
   3. 검색 한계: 벡터 검색이나 하이브리드 검색을 파일만으로 구현하려면 정규식 매칭 같은 우회가 필요하다.

3. 동시 수정의 우회책

   1. Git worktree: 여러 에이전트가 같은 파일을 수정해야 하면 각자 별도 worktree에서 작업하고, 완료 후 main 또는 master에 병합한다.
   2. 근본 해결은 아님: worktree는 충돌을 피하는 방법이지, 저장 계층이 트랜잭션을 제공하는 것은 아니다.
   3. 워크숍 실험: 세 에이전트가 같은 파일의 카운터를 동시에 증가시키는 실험으로, 누가 더 빨리 쓰는지와 파일 기반 동시성의 문제를 확인한다. 발표자는 답을 이미 알고 있지만 참석자가 직접 결과를 보게 하겠다고 했다.

3.2. 데이터베이스가 주는 장점과 DBFS

1. 데이터베이스의 기본 보장

   1. ACID: 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)을 제공한다.
   2. 고가용성: 복제 계수를 두고 세계 세 지역에 데이터베이스를 복제할 수 있다.
   3. 검색: 벡터 검색, 관계형 질의, 하이브리드 검색을 자연스럽게 제공한다.

2. Oracle DBFS(Database File System)

   1. 파일과 DB의 결합: 데이터베이스 안에 파일을 파일 시스템처럼 저장한다.
   2. 통합 효과: 파일의 편리한 인터페이스를 유지하면서 ACID 트랜잭션, 벡터 검색, 관계형 기능, 보안, 고가용성을 함께 얻는다.

3. 하이브리드 메모리 배치

   1. 단기 메모리: 지금 진행 중인 코딩 에이전트의 할 일 목록처럼 짧게 살고 사라지는 정보는 파일에 둔다.
   2. 장기 메모리: 사용자 선호도처럼 반복해서 사용해야 하는 정보는 구조화된 데이터베이스로 승격한다.
   3. 핵심 원칙: 파일과 데이터베이스 중 하나를 고르는 것이 아니라, 수명·검색성·동시성 요구에 따라 둘을 함께 사용한다.

3.3. 통합 데이터베이스와 인-데이터베이스 임베딩

1. Oracle의 통합 데이터베이스(converged database)

   1. 데이터 형식: JSON, 관계형 데이터, 공간 데이터, 그래프를 한 엔진에서 다룬다.
   2. 개발 표면: 하나의 데이터베이스 엔진, 하나의 질의 인터페이스, 하나의 개발 스택을 사용한다.
   3. 보안 단순화: 여러 데이터베이스를 각각 패치하고 보호하는 대신 한 곳을 보호하면 되므로 공격 표면과 운영 부담을 줄인다.

2. 인-데이터베이스 임베딩(In-Database Embeddings)

   1. 모델 위치: 임베딩 모델을 데이터베이스 안에 둔다.
   2. 기업 이점: 외부 제3자 서비스로 데이터를 보낼 필요가 줄어 데이터 보존과 보안 요구를 맞추기 쉽다.
   3. LangChain 연동: langchain-oracle-db를 사용하면 벡터 저장소에 데이터를 넣고, 검색하고, 회수하는 작업을 연결하기 쉽다.

4. 메모리 엔지니어링과 RAG

4.1. 인코딩·검색·재순위화의 흐름

1. 문서에서 벡터로

   1. 전처리: 문서 토큰화, 청크 분할, 중복 제거, 데이터 정규화, 개인정보(PII) 삭제를 수행한다.
   2. 인코더: 임베딩 모델이 각 청크를 벡터로 변환한다.
   3. 벡터 저장소: 텍스트, JSON 형태의 메타데이터, 32비트 밀집 임베딩 벡터를 저장한다.

2. 질의에서 답변으로

   1. 질의 임베딩: 사용자의 질문도 같은 방식으로 임베딩한다.
   2. 유사도 검색: 질의 벡터와 저장된 벡터를 비교해 관련 문서를 찾는다.
   3. 교차 인코더(cross-encoder): 질문과 검색 결과를 함께 읽어 재순위화(reranking)하고, 가장 적합한 결과를 답변 근거로 보낸다.

3. 동기화 오버헤드

   1. 분리형 스택의 문제: 텍스트용 DB, 메타데이터용 DB, 벡터용 DB를 각각 쓰면 데이터 동기화 로직과 유지보수가 AI 엔지니어에게 전가된다.
   2. 통합의 목표: 여러 저장소를 오가며 데이터를 맞추는 복잡성을 줄이고, 하나의 엔진에서 모든 표현을 관리한다.

4.2. 에이전트 메모리의 종류

1. 에이전트 메모리의 정의

   1. 네 가지 동작: 정보의 유지(retain), 재호출(recall), 재사용(reuse), 정제(refine)를 가능하게 하는 모든 메커니즘과 시스템이다.
   2. 문제 해결의 누적: 세 시간 걸린 문제를 다시 만났을 때, 에이전트와 엔지니어 모두 과거의 정보를 재사용해 더 빨리 해결해야 한다.

2. 단기 메모리(Short-Term Memory)

   1. 수명: 매우 일시적이며 지금 일어나는 작업에만 유용하다.
   2. 예시: 코딩 에이전트의 현재 할 일 목록은 지금은 필요하지만 장기 저장할 이유가 없다.
   3. 저장 방식: 파일처럼 빠르고 유연한 저장소가 어울린다.

3. 장기 메모리(Long-Term Memory)

   1. 에피소드 메모리(Episodic Memory): 이전 대화와 과거 작업의 경험을 보존한다.
   2. 워크플로우 개선: 과거 대화에서 반복되는 작업 흐름과 스킬을 추출해 다음 작업에 재사용할 수 있다.
   3. 절차 메모리(Procedural Memory): 잘 작동했던 워크플로우를 반복 가능한 절차로 저장한다. 예를 들어 마음에 드는 프런트엔드 디자인을 만든 뒤 전체 작업 대화를 워크플로우로 바꾸면 다음 프런트엔드 작업에서도 비슷한 결과를 낼 수 있다.

4. 공유 메모리(Shared Memory)

   1. 에이전트 협업: 자식 에이전트가 부모 에이전트와 결과를 공유하거나, 두 에이전트가 하나의 문제를 함께 풀 때 사용한다.
   2. 새로운 요구: 여러 에이전트의 상태와 발견을 연결해 공동 작업의 맥락을 유지한다.

4.3. 컨텍스트 로트와 컨텍스트 창의 한계

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

   1. 만능 해법이 아님: 컨텍스트 창을 1,500만 토큰으로 키우면 모든 기억을 넣을 수 있다는 생각은 단기 메모리의 역할을 장기 기억까지 확장하려는 오류다.
   2. 선별 필요: 지속적으로 남길 사실·선호·절차와 지금만 필요한 메시지를 분리해야 한다.

2. 컨텍스트 로트(Context Rot)

   1. 주의력 희석: 컨텍스트 창에 정보가 많아질수록 각 항목에 할당되는 주의력이 줄어든다.
   2. 인간 비유: 대화를 시작한 지 30분이면 상대의 주의가 높지만, 한 사람이 8시간 동안 쉬지 않고 말하면 상대는 “그만 좀 하라”며 화를 낼 수 있다. 모델도 컨텍스트가 길어질수록 핵심에서 벗어난다.
   3. 수학적 이유: 어텐션 행렬은 각 토큰이 컨텍스트의 다른 토큰을 참조하므로 행과 열이 함께 늘어난다. 컨텍스트가 커질수록 관계를 계산할 양이 사실상 제곱으로 증가한다.

3. 설계 원칙

   1. 작게 유지하기: 현재 문제에 필요한 정보만 남겨 컨텍스트 창을 가능한 한 작게 만든다.
   2. 기억으로 분산하기: 과거의 사실과 절차는 검색 가능한 메모리로 옮기고, 필요할 때만 다시 불러온다.

4.4. Oracle Agent Memory Package와 컨텍스트 카드

1. 관리형 메모리의 목적

   1. 결정 부담 감소: 엔지니어가 언제 압축할지, 어떤 요약기를 쓸지, 무엇을 보존할지, 이전 대화에서 무엇을 추출할지, 이 작업에 몇 토큰을 쓸지를 매번 직접 결정하지 않게 한다.
   2. 한 줄 호출: Oracle Agent Memory Package(OAMP)는 이러한 조립을 Python의 한 번의 호출로 수행하도록 만든다.
   3. 대상: AI 엔지니어뿐 아니라 기억을 검색·정제해야 하는 에이전트 자체의 인지 부하도 낮춘다.

2. 컨텍스트 카드(Context Card)의 구성

   1. 토픽(Topics): 대화가 어떤 주제를 다루는지 알려 모델의 방향을 잡는다.
   2. 요약(Summary): 긴 스레드를 압축하고 에이전트의 현재 의도를 명시한다.
   3. 관련 정보(Relevant Information): 사실(facts), 선호(preferences), 이 대화와 연관된 기억(memories)을 분리해 담는다.
   4. 에피소드 기억: 현재 풀리지 않은 질문을 명시적으로 추적한다.
   5. 최근 메시지: 모델에 가장 가까운 지역적 맥락을 제공한다.

3. 하네스와 모델의 경계

   1. 카드의 위치: 컨텍스트 카드는 모델에 직접 주입되는 마법이 아니라 하네스가 구성하는 추상화다.
   2. 모델의 역할: 모델은 구조를 이용해 답을 생성하고, 하네스는 그 구조를 만들어 모델이 가능한 한 안정적으로 일하도록 한다.

5. 시맨틱 계층: 조직의 ‘렌즈’를 모델에 제공하기

5.1. 의미는 접근 가능한 세계를 통해 만들어진다

1. Umwelt 비유

   1. 생물의 렌즈: Jakob von Uexküll의 관점처럼 모든 생명체는 접근할 수 있는 감각과 환경이라는 렌즈를 통해 현실을 인식한다.
   2. 인간과 에이전트: 인간은 눈과 감각을 사용하지만, 에이전트는 학습한 지식과 제공받은 컨텍스트라는 시맨틱 렌즈를 사용한다.
   3. 필터 효과: 사용자가 에이전트에게 무엇을 요청하든, 에이전트는 자신이 학습했거나 컨텍스트로 받은 렌즈를 거쳐 해석한다.

2. 조직 지식의 암묵성

   1. 동료 사이의 생략: 매일 함께 일하는 동료에게는 데이터 모델, 쿼리 방식, 메타데이터를 일일이 설명하지 않는다.
   2. 새로운 사람에게 설명하기: 어린아이가 팀에 들어와 일을 시작한다고 상상하면, 당연하게 여겼던 규칙을 아주 자세히 설명해야 한다.
   3. 에이전트에 필요한 것: 조직의 부족 지식(tribal knowledge), 기관 지식(institutional knowledge), 업무의 숨은 어휘를 명시적으로 저장해야 한다.

5.2. 시맨틱 계층에 들어가는 내용

1. 조직·기업 지식

   1. 데이터 모델: 데이터가 어떤 구조와 의미를 가지는지 정의한다.
   2. 질의 실행 관행: 어떤 질의를 어떤 방식으로 실행하는지 보존한다.
   3. 메타데이터: 필드·테이블·문서의 의미와 관계를 저장한다.

2. 메모리와의 결합

   1. 메모리의 시간축: 메모리는 과거의 사실과 절차를 기억한다.
   2. 시맨틱의 의미축: 시맨틱 계층은 그 사실과 절차가 조직 안에서 어떤 의미를 갖는지 해석할 틀을 제공한다.
   3. 결과: 같은 검색 결과라도 조직의 용어·규칙·선호를 아는 에이전트가 더 정확한 행동을 선택한다.

6. 에이전트 루프와 컨텍스트 엔지니어링

6.1. 관찰·추론·행동 루프

1. 최소 루프

   1. 관찰(Observe): 환경, 사용자 요청, 도구 결과를 읽는다.
   2. 추론(Reason): 모델이 다음에 필요한 정보와 행동을 판단한다.
   3. 행동(Act): 도구를 호출하거나 외부 상태를 변경한다.
   4. 반복: 새 결과를 다시 관찰하고 목표가 달성될 때까지 사이클을 계속한다.

2. 모델을 에이전트로 바꾸는 장치

   1. 독립성: 루프가 모델에 스스로 다음 행동을 선택할 기회를 준다.
   2. 자율성: 모델 하나만으로는 답변 생성기에 머물지만, 루프가 붙으면 환경과 상호작용하는 에이전트가 된다.
   3. 고장 내성: 한 번의 도구 오류로 프로세스를 종료하지 않고, 원인을 관찰해 다음 시도를 할 수 있어야 한다.

6.2. 툴박스와 스킬박스 패턴

1. 필요할 때만 노출하기

   1. 툴박스(Toolbox): 사용 가능한 도구 목록과 설명을 저장한다.
   2. 스킬박스(Skillbox): 반복 가능한 작업 절차와 스킬을 저장한다.
   3. 동적 검색: 모든 도구와 스킬을 매번 컨텍스트에 넣지 않고, 현재 문제에 필요한 것만 검색해 추가한다.

2. 루프별 컨텍스트 재구성

   1. 매 반복 판단: 각각의 에이전트 루프에서 현재 도구와 스킬이 정말 필요한지 다시 확인한다.
   2. 임시 제거: 필요하지 않은 항목은 컨텍스트에서 임시로 제거한다.
   3. 살리언시 유지: 현재 목표와 직접 연결된 정보만 남겨 컨텍스트 창의 주의력을 보호한다.

7. 지속 학습과 스킬 승격

7.1. 가중치를 바꾸지 않고 행동을 개선하는 세 경로

1. 가중치 경로

   1. 비용: 모델 가중치를 직접 바꾸는 일은 대부분의 팀에게 비싸고 느리다.
   2. 현실성: 일반적인 상황의 99.9%에서는 모델 가중치가 그대로 유지된다.

2. 표현 경로

   1. 임베딩 개선: 지식과 경험을 표현하는 임베딩을 바꾼다.
   2. 재순위화 개선: 검색 결과를 고르는 reranker를 조정해 모델에 들어가는 근거의 질을 높인다.

3. 컨텍스트·토큰 경로

   1. 가장 접근 가능한 방법: 거액의 GPU 비용 없이도 메모리와 컨텍스트 조립 방식을 바꿔 행동을 개선할 수 있다.
   2. 워크숍의 초점: 가장 저렴하고 현실적인 지속 학습으로 컨텍스트와 토큰 공간을 다룬다.

7.2. 스킬·워크플로우 승격

1. 경험의 회수

   1. 긴 작업의 가치: 하루 동안 세네 시간 이상 공들여 성공한 작업 흐름은 일회성 대화로 버리지 않는다.
   2. 메모리 저장: 작업 결과와 절차를 메모리 구성 요소에 넣어 다음 작업에서 회수한다.

2. 스킬 승격(Skill Promotion)

   1. 증류(Distillation): 기존 스킬에서 성공에 기여한 규칙과 선호를 뽑아 더 나은 skill.md를 만든다.
   2. 버전 교체: 오래된 버전을 은퇴시키고 새 버전을 기본 스킬로 업데이트한다.
   3. 개인화: 선호하는 라이브러리의 모양과 느낌, 버그가 적은 데이터베이스 엔진, 개인의 말투와 작업 방식이 재사용 가능한 스킬에 반영된다.

3. 워크플로우 승격(Workflow Promotion)

   1. 절차화: 한 번 성공한 작업을 다음에도 그대로 재현할 수 있는 흐름으로 만든다.
   2. 점진적 개선: 새 경험이 쌓일 때마다 스킬과 워크플로우를 수정해 개인과 조직에 맞는 에이전트로 발전시킨다.

8. 워크숍 구현과 ‘Total Recall’ 데모

8.1. 참가 준비와 코드 구조

1. 접속 절차

   1. 등록: workshopwaitingroom.com에서 등록하면 GitHub 저장소 초대장을 받는다.
   2. 실행 환경: 저장소에서 GitHub Codespace를 만들면 필요한 환경이 미리 준비된다.
   3. 문의 채널: Oracle Agent Memory Package 관련 Discord 서버와 발표자의 LinkedIn을 통해 질문할 수 있다.

2. 학생 노트북

   1. 처음부터 쌓기: 모델만 있는 상태에서 시작해 일곱 계층의 하네스 구성 요소를 하나씩 추가한다.
   2. 19개 할 일: 단순히 모델에 질문하는 첫 단계부터 검색·회수·인코딩 등 전체 구성 요소까지 총 19개의 TODO를 순서대로 해결한다.
   3. 도움말: VS Code에서 Python 3.12 커널을 선택하고, 각 TODO의 설명 문서와 정답을 참고할 수 있다. 먼저 시도하지 않고 정답만 보는 사람에게는 “게으르지 않다면 먼저 해보라”는 식의 농담이 따라붙는다.

3. 비용 농담

   1. 리소스 선택: Codespace를 8코어 또는 16코어로 만들 수 있지만, 발표자가 직접 비용을 내고 있으니 너무 큰 인스턴스를 만들지 말라고 했다.
   2. 워크숍 시간: 남은 실습 시간은 약 1시간 15분으로 안내됐다.

8.2. 앱북(Appbook)과 관찰 가능한 하네스

1. 구성 요소별 테스트

   1. 앱북: 하네스 전체뿐 아니라 각 구성 요소를 개별적으로 시험한다.
   2. 자동 배포: GitHub Codespace에 앱북과 노트북이 자동으로 배포된다.
   3. OCI Generative AI: Oracle의 관리형 서비스에서 Google, Meta, OpenAI, xAI 모델의 추론을 제공하며, 여러 모델을 연결하는 기업용 오픈 라우터처럼 동작한다.

2. Total Recall 애플리케이션

   1. 포트 공개: Codespace의 포트 가시성을 public으로 바꾸면 공개 게이트웨이에서 개인 Total Recall 인스턴스에 접속할 수 있다.
   2. 질문 예시: “제품 카테고리별 총매출을 보여 달라”는 자연어 질문을 입력한다.
   3. 컨텍스트 시각화: 어떤 도구가 선택되어 컨텍스트에 들어갔는지, 어떤 스키마가 사용됐는지, 몇 토큰을 썼는지를 확인한다.
   4. 트레이스: 로드된 스킬, 사용한 데이터 소스, SQL 실행 같은 도구 호출을 단계별로 볼 수 있다.
   5. 고장 내성: 질의가 16단계를 거치는 동안 오류가 감지되어도 루프가 중단되지 않고 다시 시도해 데이터베이스 결과를 만든다.

3. 현장 운영의 현실

   1. 인터넷 문제: 코드 스페이스가 비활성 상태로 연결이 끊기거나 행사장의 Wi-Fi가 제대로 작동하지 않는 상황이 발생했다.
   2. 복구: 코드 스페이스를 다시 시작하고, 행사 운영진이 AI.gineer Wi-Fi 문제를 지원했다.
   3. 발표 자료: 슬라이드는 AI Engineer 세션에 올라가거나 Discord·LinkedIn을 통해 공유하기로 했다.
   4. 친근한 마무리: Oracle 부스에 들러 질문해 달라며, 사람들이 찾아오면 “우리가 환영받고 친구가 있다는 느낌이 들어 좋다”고 말했다. 인터넷 상태를 묻는 짧은 농담과 “나는 Caesar처럼 느껴진다”는 말로 현장 분위기를 풀었다.

9. Q&A: 도구 수, 실패 한도, 모델 라우팅

9.1. 수천 개 도구를 다루는 툴박스 패턴

1. 도구가 많아질 때의 문제

   1. 조직 규모: 기업에는 수천 개의 도구가 존재할 수 있고, 도구마다 기밀 데이터 접근 권한도 다르다.
   2. 검색 비용: 모든 도구 설명을 컨텍스트에 넣으면 토큰과 주의력이 낭비된다.

2. HNSW 기반 검색

   1. 계층적 탐색: Hierarchical Navigable Small World(HNSW) 인덱스는 그래프 구조를 이용해 필요한 도구를 빠르게 찾는다.
   2. 노드 구성: 그래프의 각 노드는 벡터 인덱스 또는 벡터 저장소가 된다.
   3. DB 적합성: 이런 인덱스는 파일보다 데이터베이스에서 구현하기 쉽다.
   4. 규모 감각: 일상적인 파일 읽기·쓰기·grep 같은 도구 호출은 대개 100~1,000개를 넘지 않지만, 벡터 저장소를 사용하면 2,000개를 조회하는 방식도 10,000개를 조회하는 방식만큼 단순하게 추상화할 수 있다.

3. 유사한 도구 설명의 분리

   1. 문제: 서로 다른 회사의 도구 설명이 비슷하면 벡터 검색이 올바른 도구를 구분하기 어렵다.
   2. 해결: LLM으로 도구의 docstring과 설명을 보강한 ‘향상된 툴박스 설명’을 생성한다.
   3. 효과: 단순한 명명 엔터티 인식보다 풍부한 표현을 만들어 도구와 스킬의 분리 가능성(separability)을 높인다.

9.2. 도구 호출 실패와 인내심 변수

1. 무한 재시도의 한계

   1. 비용 제약: 모델이 환각을 계속 생성할 때 돈이 무한하지 않으므로 영원히 재시도할 수 없다.
   2. 중단 기준: 프런티어 LLM의 정확도와 문제 난이도에 맞춰 최대 도구 호출 수를 정한다.

2. 실제 설정 예시

   1. 8~12회: Groq 4.1 Fast Reasoning을 사용한 환경에서는 포기하기 전 최대 8~12회의 도구 호출이 적절하다고 경험적으로 설정했다.
   2. 변동성: 어떤 질의는 2번 만에 답을 찾지만, 어떤 질의는 16단계가 걸릴 수 있다.
   3. 히스테리시스 변수: 하네스가 모델에 허용할 ‘인내심’을 변수로 두면 작업 유형과 모델 품질에 따라 재시도 정도를 조절할 수 있다.

9.3. 문제 유형별 모델 라우팅

1. 작은 전문가 모델의 조합

   1. 전망: 모든 문제에 하나의 거대 모델을 쓰기보다 문제 유형별 소형 전문가 모델을 조합하는 방향이 효율적이다.
   2. 전문화: 어떤 회사는 특정 문제 하나에 탁월한 1억 파라미터 모델을 만들 수 있다.
   3. 오케스트레이터: 집계기와 오케스트레이터가 질문을 올바른 전문 모델로 보내면 토큰 효율적인 하네스를 만들 수 있다.

2. 경제적 모델 선택

   1. 쉬운 문제: 오픈 웨이트 SLM을 연결한다.
   2. 어려운 문제: 프런티어 LLM으로 라우팅한다.
   3. 비즈니스 모델: 일부 라우팅 회사는 기존에 쓸 비용에서 절약한 토큰 비용의 10%를 받는 방식으로 가치를 만든다.

주요 발언 모음

“언어 모델은 추론의 얼어붙은 부분이다. 우리는 주어진 것을 받아들여야 한다.”

“에이전트는 대규모 언어 모델과 하네스의 결합이다.”

“자동화는 시스템에 신뢰성을 주고, 자율성은 유연성을 준다.”

“컨텍스트 창은 단기 메모리의 한 종류일 뿐, 모든 것을 해결하지는 않는다.”

“컨텍스트 창은 가능한 한 작게 유지해야 한다. 그래야 해결 중인 작업이 관련성을 유지한다.”

“가중치를 바꾸지 않고도 임베딩·재순위화·컨텍스트를 바꿔 시간이 지날수록 에이전트를 개선할 수 있다.”

“우리가 통제할 수 없는 모델 위에 원하는 추상화를 쌓아, 모델이 가능한 한 신뢰성 있게 작동하도록 만든다.”

핵심 데이터 & 수치

• 5개 스택 계층: 애플리케이션, 데이터, 모델, 인프라, 컴퓨트가 AI 에이전트의 기반을 이룬다.
• 7개 하네스 구성 요소: 저장소, 메모리 엔지니어링, 시맨틱 계층, 게이트웨이·MCP, 도구·스킬, 에이전트 루프, 컨텍스트 엔지니어링을 결합한다.
• 99.9%: 일반적인 환경에서는 모델 가중치가 바뀌지 않는 시간의 비유적 비율로 제시됐다.
• 32비트: RAG 저장소에 들어가는 밀집 임베딩 벡터의 예시 표현이다.
• 세 지역: 데이터베이스 복제 계수로 세계 세 곳에 고가용성을 확보할 수 있다.
• 세 시간~하루: 성공한 작업을 스킬과 워크플로우로 승격할 가치가 있는 경험의 예시다.
• 19개 TODO: 모델 호출부터 전체 하네스 구현까지 학생 노트북에서 수행하는 실습 과제 수다.
• 16단계: Total Recall 데모가 제품 카테고리별 매출 질문을 처리하며 거친 에이전트 단계의 예시다.
• 8~12회: Groq 4.1 Fast Reasoning 환경에서 환각성 도구 호출을 중단하기 전의 권장 최대 시도 횟수다.
• 100~1,000개: 읽기·쓰기·검색처럼 일상적으로 사용하는 도구 호출 수의 대략적 규모다.
• 1억 파라미터: 특정 문제 하나에 특화된 소형 전문가 모델의 예시 규모다.
• 1시간 15분: 실습을 진행할 수 있다고 안내된 남은 워크숍 시간이다.

결론 및 시사점

1. 모델보다 하네스를 먼저 설계한다: 모델 가중치를 직접 바꾸기 어려운 현실에서 신뢰성과 반복 가능성을 결정하는 레버는 메모리·도구·검색·루프·컨텍스트다.
2. 데이터 계층을 핵심 자산으로 만든다: 모델·인프라·컴퓨트가 상품화될수록 조직의 시맨틱 지식과 과거 작업 경험을 얼마나 잘 저장하고 호출하는지가 차별화 요소가 된다.
3. 파일과 데이터베이스를 함께 쓴다: 일시적이고 비정형인 단기 상태는 파일에 두고, 동시성·백업·검색·장기 보존이 필요한 정보는 데이터베이스로 승격한다.
4. 메모리를 시간축으로 분리한다: 현재 할 일은 단기 메모리로, 대화의 경험은 에피소드 메모리로, 성공한 절차는 절차 메모리로, 협업 상태는 공유 메모리로 관리한다.
5. 컨텍스트를 작게 유지한다: 긴 컨텍스트가 곧 좋은 기억은 아니다. 컨텍스트 로트를 막으려면 매 루프마다 필요한 근거와 도구만 검색해 넣어야 한다.
6. 조직의 암묵지를 시맨틱 계층으로 옮긴다: 데이터 모델·질의 관행·메타데이터·업무 용어를 명시해야 에이전트가 팀 동료처럼 행동할 수 있다.
7. 실패를 루프 안에서 처리한다: 도구 오류를 즉시 종료로 연결하지 말고, 제한된 재시도·히스테리시스·모델 라우팅을 통해 회복 가능한 시스템을 만든다.
8. 도구 수가 늘면 검색 계층을 투자한다: 수천 개 도구를 모두 노출하지 말고 HNSW 기반 툴박스와 설명 보강으로 선택지를 좁힌다.
9. 작은 전문가 모델을 라우팅한다: 문제 유형마다 가장 싼 모델을 선택하고, 어려운 문제만 프런티어 모델로 보내 토큰 비용과 지연을 줄인다.
10. 경험을 스킬로 승격한다: 몇 시간의 성공적인 작업을 skill.md와 재사용 가능한 워크플로우로 증류하고, 새 경험이 쌓일 때마다 이전 버전을 교체하면 하네스가 조직의 작업 방식에 맞춰 지속적으로 학습한다.