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

URL: https://www.youtube.com/watch?v=xs-ob87TTzg 날짜: 2026-09-19 채널: aiDotEngineer 발표자: Ignacio Martinez, Oracle Developer Advocate 원문 제목: Total Recall: Agent Memory and Harness Engineering — Ignacio Martinez, Oracle

📌 핵심 질문 / 이 강연이 관통하는 핵심 논점

==가중치가 고정되어 있고 동일한 입력에도 다른 답을 내놓는 LLM을 어떻게 신뢰할 수 있고 반복 가능한 에이전트로 바꿀 것인가?== 답은 모델 자체를 바꾸는 데 있지 않고, 모델을 둘러싼 agent harness—데이터·메모리·도구·컨텍스트·루프·학습을 묶는 실행 계층—를 설계하는 데 있다.

• 모델은 reasoning을 담당하지만 대체 가능하고, 개발자가 직접 통제하기 어려운 “frozen reasoning core”다.
• harness는 저장소, memory engineering, semantic layer, agent loop, context engineering, continual learning을 통해 비결정적 출력을 안정적인 결과로 수렴시킨다.
• 짧은 작업 상태와 장기적인 선호·워크플로를 서로 다른 메모리로 관리하고, 필요한 도구와 지식만 매 iteration 컨텍스트에 넣어 context rot을 막는다.

LLM을 단독으로 쓰면 모델은 외부 데이터와 도구에 접근하지 못한다. MCP gateway, 검색·인코딩·재순위화, 메모리와 의미 계층, 관찰-추론-행동 루프가 붙어야 자율성이 생긴다. 결국 경쟁력은 commoditized되는 모델·인프라보다 기업 고유의 데이터와 그 데이터를 다루는 harness에 남는다.

1. Agent stack과 harness의 역할

1.1. 모든 AI agent를 구성하는 다섯 층

1. Application layer
   1. 사용자가 실제로 만지는 product surface다.
   2. 채팅 UI, 분석 앱, 코딩 도구처럼 모델과 데이터의 기능을 사용자에게 노출한다.
2. Data layer
   1. memory, knowledge, retrieval, encoding, search가 모인다.
   2. agent harness가 가장 밀접하게 붙는 층이며, 개발자가 AI 애플리케이션에서 가장 많이 통제할 수 있는 영역이다.
3. Model layer
   1. 전체 reasoning을 담당하는 large language model(LLM)이다.
   2. 모델 가중치는 통상 변하지 않으므로 frozen core라고 부를 수 있다.
4. Infrastructure layer
   1. orchestration과 model serving을 담당한다.
   2. 필요한 reasoning effort에 따라 어떤 모델을 호출할지, 여러 컴포넌트를 어떻게 배치할지를 결정한다.
5. Compute layer
   1. cloud, GPU, database engine 같은 실행 기반이다.
   2. application·model·infrastructure·compute 네 층은 점점 commoditized되어 복잡성을 사용자의 영역 밖으로 밀어내고 있다.

1.2. Data layer의 연결부: gateway, MCP, 도구와 스킬

1. Gateway와 Model Context Protocol(MCP)
   1. 고립된 LLM은 외부 세계와 통신할 수 없으므로 data와 tools에 연결하는 gateway가 필요하다.
   2. 예를 들어 컴퓨터의 Outlook에 모델이 접근하지 못한다면 MCP로 함수를 명시한다. 그러면 LLM이 Outlook 프로그램과 통신할 수 있다.
   3. MCP gateway는 모델을 컴퓨터, 애플리케이션, 파일과 연결하는 외부 세계의 관문이다.
2. Gateway 위에 놓이는 구성요소
   1. memory layer와 semantic layer가 무엇을 저장하고 어떤 의미로 해석할지를 정한다.
   2. retrieval layer와 context layer가 필요한 내용을 찾아 모델 입력에 구성한다.
   3. tools와 skills가 모델의 행동 공간을 만든다.

1.3. AI 애플리케이션의 네 가지 형태와 자동화-자율성 조합

1. LLM chatbot
   1. 사용자가 질문해야 반응하는 가장 수동적인 형태다.
   2. 모델이 대답하는 순간 외에 지속적인 백그라운드 처리가 없다.
2. RAG application
   1. 문서를 임베딩하고 검색하는 백그라운드 처리가 있어 반수동적(semi-passive)이다.
   2. 그래도 사용자의 질문이 처리의 출발점이라는 수동성이 남는다.
3. LLM-driven workflow
   1. 미리 정해진 자동화(automation)가 여러 모델 호출을 연결한다.
   2. 자동화는 신뢰성과 반복성을 제공한다.
4. AI agent
   1. 자율성(autonomy)을 갖고 도구를 선택하며 다음 행동을 결정한다.
   2. 자율성은 유연성을 제공하지만, 그대로 두면 출력의 비결정성이 커진다.
5. 두 성질의 결합
   1. Cloud Code 같은 현대 AI 애플리케이션은 LLM workflow의 자동화와 agent의 자율성을 결합한다.
   2. 자동화가 시스템을 안정화하고 자율성이 다양한 상황에 대응하게 하므로, 개발 도구에 특히 유용한 조합이 된다.

1.4. AI agent의 정의: model + harness

1. 구성식
   1. AI agent = large language model(추론) + harness(그 밖의 모든 실행·데이터 계층)다.
   2. LLM은 reasoning을 수행하고, database/file이 memory를 제공하며, tools가 action을 확장하고, 입력이 환경을 perceive하게 한다.
2. 통제의 비대칭
   1. 추론은 개발자가 임대해 쓰는 부분이며, 같은 입력에도 매번 다른 출력이 나올 수 있다.
   2. memory·tools·perception은 애플리케이션에 맞게 커스터마이즈할 수 있다.
3. harness engineering의 목표
   1. 반복 호출에서 reliable하고 predictable한 결과를 얻는다.
   2. 모델이 nondeterministic하더라도 저장·검색·도구선택·검증·재시도 계층이 결과를 일정한 방향으로 유도한다.
4. 모델 교체 가능성
   1. OpenAI protocol이나 Anthropic API specification 같은 공통 인터페이스를 사용하면 모델 층은 swappable하다.
   2. 모델이 바뀌어도 harness의 데이터·도구·루프 설계를 유지하는 것이 핵심이다.

2. Harness의 일곱 구성 축과 데이터 설계

2.1. 일곱 층의 전체 구조

1. Model layer — frozen reasoning core
   1. 모델 가중치는 보통 바뀌지 않으며, 모델 자체보다 주위 계층이 설계 대상이다.
   2. 99.9%의 경우 가중치를 바꾸려면 수백만 달러, 많은 시간과 GPU가 필요하다.
2. Storage layer
   1. 데이터와 memory가 물리적으로 어디에 살지 정한다.
   2. 파일과 데이터베이스의 장점을 조합하는 hybrid storage가 적합하다.
3. Memory engineering
   1. encoding, search, retrieval을 구현한다.
   2. 질문과 저장 데이터의 의미를 비교하고, 관련 결과를 다시 모델에 공급한다.
4. Semantic layer
   1. 조직 내부에서 암묵적으로 공유하는 어휘·규칙·tribal knowledge를 명시한다.
   2. 모델이 기업 데이터를 올바른 렌즈로 보게 만드는 enterprise vocabulary다.
5. Agent loop
   1. observe → reason → act를 반복해 모델을 autonomous agent로 만든다.
   2. 실패나 잘못된 tool call이 발생해도 루프를 지속할 수 있어야 한다.
6. Context engineering
   1. 매 iteration에 가장 salient한 정보만 context window에 배치한다.
   2. toolbox·skillbox에서 현재 문제에 필요한 tools와 skills만 꺼낸다.
7. Continual learning
   1. 고정된 모델도 representation, context/token space, 필요하면 weights 주변의 계층을 개선해 시간이 지날수록 더 나은 행동을 하게 한다.
   2. 비용이 낮고 현실적인 방법은 embedding·reranking과 context/token space를 개선하고, 성공한 workflow를 재사용 가능한 skill로 승격하는 것이다.

2.2. 파일과 데이터베이스의 선택이 아니라 결합

1. 파일의 장점
   1. 모델의 본능과 잘 맞고 만들기·append하기·수정하기가 쉽다.
   2. 비정형 데이터를 그대로 담으며 운영체제와 쉽게 통합된다.
   3. POSIX semantics를 따르므로 Debian, Ubuntu 등 여러 OS에서 호환된다.
2. 파일의 한계와 다중 에이전트 충돌
   1. transactional consistency가 없어서 여러 agent가 같은 파일을 동시에 수정하거나 삽입하기 어렵다.
   2. 8·16·32개 agent가 동시에 일하면 한쪽의 수정이 다른 쪽 작업과 충돌한다.
   3. 여러 agent는 별도 Git worktree를 만들어 작업한 뒤 master/main으로 merge하는 방식으로 이 제약을 우회한다.
   4. 파일만으로는 hybrid search가 어렵고, OS가 손상되면 백업 없이 데이터를 잃을 수 있다.
3. 데이터베이스의 장점
   1. ACID—atomicity, consistency, isolation, durability—트랜잭션을 제공한다.
   2. 복제 계수(replication factor)를 사용해 세계 세 곳에 복제하는 high availability를 구현할 수 있다.
   3. vector search와 백업이 기본 설계에 들어간다.
4. Oracle DBFS와 hybrid memory
   1. Oracle DBFS(Database File System)는 파일을 데이터베이스 안의 파일 시스템에 저장한다.
   2. 파일의 인터페이스에 database의 ACID transactional consistency, vector search, relational 기능, security, high availability를 더한다.
   3. short-term memory는 파일에 두고, 사용자 선호처럼 장기 보존할 내용이 되면 구조화된 database로 promote하는 구성이 적절하다.
   4. 실제 workshop은 이 hybrid promotion을 구현한다.

2.3. Retrieval pipeline: encoding, search, reranking

1. 벡터 생성과 1차 검색
   1. 문서를 쪼개고 tokenizer를 거친 뒤 embedder/bi-encoder로 dense embedding을 생성한다.
   2. 벡터를 vector store에 넣고, 사용자의 query도 같은 방식으로 embedding한다.
   3. query와 저장 벡터를 비교해 관련성이 높은 후보를 가져온다.
2. Cross-encoder 재순위화
   1. cross-encoder reranker는 질문과 후보 결과를 함께 보고 relevance를 다시 계산한다.
   2. 이 결과가 RAG 애플리케이션의 답변 근거로 모델에 전달된다.
3. 실제 데이터 전처리
   1. tokenization, embedding 생성, 중복 제거, normalization을 수행한다.
   2. personally identifiable information(PII)을 redaction하고, 문서 원문·JSON metadata·32-bit dense vector를 관리한다.
   3. 서로 다른 종류의 데이터를 각각 별도 database에 두면 synchronization logic과 유지보수 비용이 커진다.
4. Converged database의 제안
   1. Oracle은 JSON, relational, spatial, graph, vector 등 여러 데이터 형태를 하나의 engine에서 지원한다고 소개한다.
   2. 하나의 query interface와 development stack을 쓰면 다섯 개 database를 각각 업데이트할 필요가 없다.
   3. 보안 관점에서도 한 database를 저장·보호하면 되므로 관리해야 할 attack surface가 하나로 줄어든다.
   4. LangChain Oracle DB integration은 vector store 삽입·검색·retrieval을 단순화한다.
5. In-database embeddings
   1. embedding model을 database 안에 둘 수 있다.
   2. enterprise 환경에서 third-party embedding service로 데이터를 내보내지 않아 data retention과 security를 지키기 쉽다.

3. Agent memory와 context engineering

3.1. 기억의 정의와 종류

1. 기억의 네 동작
   1. agent memory는 정보를 retain, reuse, refine, recall하는 모든 mechanism과 system이다.
   2. 세 시간 걸린 문제의 해결 데이터가 다음 동일한 문제를 더 쉽게 만드는 것이 memory의 실용적 가치다.
2. 시간축에 따른 기억
   1. short-term memory는 지금 진행 중인 작업을 위한 ephemeral state다.
   2. 코딩 agent의 현재 to-do list처럼 당장 필요하지만 작업이 끝난 뒤 장기 저장할 필요가 없는 정보가 여기에 해당한다.
   3. long-term memory는 과거 대화, 사용자 선호, 성공한 workflow처럼 앞으로도 유용한 정보를 보존한다.
   4. shared memory는 sub-agent가 parent agent와 소통하거나 두 agent가 한 문제를 공동 해결할 때 공유하는 공간이다.
3. 장기 기억의 구체적 형태
   1. episodic memory는 과거에 나눈 대화와 경험을 저장한다. 과거 대화를 바탕으로 workflow와 skill을 다듬는 데 쓸 수 있다.
   2. procedural memory는 잘 작동했던 절차다. 예를 들어 선호하는 front-end 디자인을 만든 대화를 workflow로 바꾸면 다음 front-end 작업에서 유사한 결과를 반복할 수 있다.

3.2. Context window와 context rot

1. 큰 창이 모든 기억의 해답이 아닌 이유
   1. 15 million token context window를 넣으면 해결된다고 믿는 관점이 있지만, context window 자체는 short-term memory일 뿐이다.
   2. 장기 선호·절차·과거 경험까지 모두 한 창에 넣으면 각 정보가 항상 잘 활용되는 것이 아니다.
2. Context degradation의 원리
   1. context에 정보가 추가될수록 각 토큰에 배분되는 attention이 줄어든다.
   2. 대화 초반 30분에는 상대의 주의가 높지만, 8시간 동안 계속 말하면 상대가 화를 내고 거의 배우지 못한다는 인간 대화 비유가 쓰였다.
   3. neural network attention matrix는 한 토큰이 다른 모든 토큰을 참조하므로 행과 열 방향으로 커지고, context가 커질수록 quadratic하게 부담이 증가한다.
   4. 따라서 필요한 정보만 남겨 context window를 가능한 작게 유지해야 context rot을 피할 수 있다.

3.3. Oracle Agent Memory Package(OAMP)와 context card

1. 관리형 memory abstraction
   1. 개발자가 직접 context compaction 시점, summary 생성 방식, 보존·삭제할 정보, 과거 대화에서 추출할 내용, token 예산을 모두 결정하면 인지 부하가 커진다.
   2. OAMP는 이 결정을 관리형 기능으로 묶어 Python에서 한 번의 호출로 처리한다.
2. Context card의 구성
   1. Topics: 대화에서 어떤 주제가 다뤄졌는지 모델의 방향을 잡는다.
   2. Summary: thread를 압축하고 현재 agent intent를 기록한다.
   3. Relevant information: facts, preferences, memories 세 종류를 보존한다.
   4. Episodic memories: 현재 남아 있는 unanswered question을 명시적으로 추적한다.
   5. Recent messages: 모델에 가까운 local context를 제공한다.
3. 청중 Q&A: context card의 위치
   1. context card가 model에 직접 들어가는 완성 답변은 아니다.
   2. harness의 컴포넌트가 구조를 이해하고, 필요한 부분을 선택해 model에 넣는 abstraction이다.
   3. 모델은 통제할 수 없으므로 이런 abstraction을 위에 쌓아 가능한 한 reliable하게 행동하도록 만든다.

3.4. Semantic layer와 Umwelt

1. 지각의 렌즈
   1. Jakob von Uexküll이 말한 Umwelt는 생명체가 접근할 수 있는 감각과 환경의 렌즈를 통해 현실을 지각한다는 개념이다.
   2. 인간은 눈과 감각을 통해 경험을 해석한다.
   3. agent는 인간의 감각 대신 학습과 제공된 context로 만든 semantic lens를 통해 모든 요청을 해석한다.
2. 기업 지식의 암묵성
   1. 동료끼리는 매일 쓰는 내부 규칙을 굳이 말하지 않지만, 새로 합류한 사람에게는 작업 방법을 자세히 설명해야 한다.
   2. 같은 답을 공유하는 조직의 tribal knowledge와 institutional knowledge가 semantic layer에 해당한다.
   3. 데이터 모델, query 실행 방식, metadata, 내부 어휘와 관행이 모델이 알아야 하지만 대화마다 반복되지 않는 지식이다.

4. Agent loop, context assembly와 continual learning

4.1. Observe–reason–act loop

1. 모델을 agent로 만드는 driver
   1. agent loop는 모델이 독립적으로 다음 행동을 선택하게 하는 driver다.
   2. 가장 작은 형태는 환경을 observe하고, reason한 뒤, act하는 순환이다.
2. 실패 내성
   1. 잘못된 tool call이나 일시적인 오류가 생겨도 루프가 즉시 종료되지 않아야 한다.
   2. 모델에 자율성을 부여하되, harness가 재시도·검증·중단 조건을 제어해야 자율성이 usable한 agent가 된다.

4.2. Toolbox와 skillbox 패턴

1. 필요할 때만 로드
   1. 사용 가능한 tools와 skills를 모두 context에 넣지 않고 toolbox/skillbox에 저장한다.
   2. 매 loop iteration에서 현재 문제에 맞는 항목만 검색해 context에 넣는다.
   3. 다음 iteration에 필요하지 않으면 잠시 제거해 salience를 유지한다.
2. 매 iteration context assembly
   1. agent loop가 진행될 때마다 current intent, 관련 memory, 선택된 tool, 필요한 skill을 새로 조합한다.
   2. 이 조합이 context engineering과 memory engineering을 연결해 작은 context로도 긴 작업을 수행하게 한다.

4.3. Continual learning의 비용 계층

1. Frozen weights의 현실
   1. 모델 weight를 직접 바꾸는 것은 수백만 달러 규모의 비용과 GPU·시간이 필요하므로 대부분의 팀이 매일 할 수 없다.
   2. weight를 바꾸지 않고도 모델의 행동을 개선할 수 있는 representation과 context 계층이 있다.
2. 세 가지 개선 지점
   1. representation space에서는 embedding과 reranking을 바꿔 무엇이 관련 있는지 개선한다.
   2. context/token space에서는 어떤 memory·tool·skill을 어떤 순서와 형태로 모델에 주는지 바꾼다.
   3. weight space는 가장 직접적이지만 비싸고, workshop은 가장 달성 가능하고 저렴한 context/token space에 집중한다.
3. Skill promotion과 workflow promotion
   1. 세네 시간 동안 성공적으로 수행한 workflow는 memory에 저장하고 다시 검색할 수 있다.
   2. distillation으로 기존보다 나은 skill.md를 만들고, 낡은 버전을 retire한 뒤 새 버전으로 교체한다.
   3. 사용자의 말투·작업 방식·선호를 skill에 반영할 수 있다.
   4. “이 라이브러리가 look and feel이 좋아서 사용한다”, “이 database engine은 bug가 적고 다루기 쉽다” 같은 경험적 선택도 재사용 가능한 skill로 승격된다.

5. Total Recall workshop의 구현 흐름

5.1. 참가 준비와 시간 구성

1. 사전 준비
   1. workshopwaitingroom.com에서 등록하면 GitHub repository 초대장을 받는다.
   2. 초대장을 확인·수락한 뒤 GitHub Codespaces에서 workshop을 실행한다.
   3. Codespaces 시작에는 약 5분이 걸린다.
2. 세션 구성
   1. 첫 30분은 agent harness, agent memory와 관련 개념을 소개한다.
   2. 뒤의 약 1시간 30분은 실제 workshop을 함께 진행한다.
   3. 발표자는 Oracle에서 7년, developer advocate로 약 4년 일했으며 Andrew Ng와 agent memory 과정을 만들었다고 소개했다.

5.2. Notebook과 Appbook

1. Notebook의 19개 TODO
   1. student notebook은 모델만 있는 상태에서 시작해 일곱 계층을 하나씩 추가하며 전체 harness substrate를 처음부터 구현한다.
   2. 첫 TODO는 agent harness 없이 OpenAI completions API의 reasoning core에 질문 하나를 보내는 것이다.
   3. 이후 search, retrieval, encoding과 나머지 계층을 차례로 추가한다.
   4. 총 19개 TODO가 있으며, 각 문제의 설명과 해결책이 docs 폴더에 있다.
   5. VS Code에서 Python 3.12 kernel을 선택하면 notebook을 실행할 수 있다.
2. Appbook의 역할
   1. Appbook은 harness의 각 컴포넌트를 개별적으로 시험하고, 전체 agent와 채팅할 수 있는 앱이다.
   2. GitHub Codespaces에 자동 배포된다.
   3. Oracle의 OCI Generative AI managed service에서 Google, Meta, OpenAI, xAI와의 partnership 모델을 호출한다.
   4. 이 서비스는 enterprise 환경에서 여러 회사 모델에 inference를 제공하는 “enterprise open router”로 비유됐다.
3. 배포 중 발생한 실제 운영 상황
   1. 시연 중 inactivity 때문에 Codespace 연결이 끊겼고, 인스턴스를 재시작했다.
   2. 현장 Wi‑Fi가 불안정해 참가자들이 같은 AI.gineer Wi-Fi를 쓰는지 확인하고 동료들이 지원했다.
   3. 발표 자료는 AI Engineer 세션에 올라가며 Discord나 LinkedIn 메시지로도 받을 수 있다고 안내했다.
   4. 발표자는 참가자별 8·16 core 자원을 만들지 말라고 당부했다. 해당 비용을 본인이 부담하고 있으니 기본 Codespace만 만들면 된다고 말했다.

5.3. Mission control 데모

1. 접근 설정
   1. Codespaces의 total recall port visibility를 public으로 바꾸면 public gateway로 자신의 Total Recall instance에 접근할 수 있다.
   2. 포트를 public으로 바꾸는 절차를 화면에서 시연했다.
2. 질문과 내부 흐름
   1. show the total revenue by product category라는 질문을 입력했다.
   2. Mission control 화면은 harness가 선택해 context에 로드한 tools, 현재 schema, agent trace를 시각화한다.
   3. 어떤 skills가 로드됐는지, 어떤 data source를 읽었는지, SQL 등 어떤 tool call이 발생했는지 확인할 수 있다.
   4. 질문은 약 16단계에 걸쳐 만들어졌고, 중간에 오류가 발생했지만 agent loop의 fault tolerance가 재시도를 수행했다.
   5. 최종 결과, 사용 token 수, context window의 내용과 context card 생성 과정을 확인할 수 있다.

6. Q&A: 도구 규모·재시도·모델 라우팅

6.1. 수천 개 도구를 다루는 Toolbox pattern

1. 질문: 조직에 수천 개의 tool이 있으면 어떻게 검색하는가?
   1. 모든 tool 설명을 context에 넣지 않고 toolbox pattern으로 검색 대상을 계층화한다.
   2. HNSW(Hierarchical Navigable Small World) index의 graph 구조를 사용한다.
   3. graph의 각 node는 vector index 또는 vector store이며, database에서 이 index를 구성한다.
2. 규모에 따른 실제 부담
   1. 수백만 사용자와 수백만 종류의 tool call에 도달하기 전까지 retrieval 비용은 크게 걱정할 필요가 없다.
   2. 매일 쓰는 read file, write file, grep류의 일반적인 tool call은 대개 100개 또는 1,000개를 넘지 않는다.
   3. HNSW 덕분에 2,000개를 query하는 방식이 10,000개를 query하는 방식보다 본질적으로 더 복잡해지지 않는다.
3. 질문: 비슷한 tool description의 충돌
   1. 서로 다른 회사의 도구 설명이 비슷하면 vector search가 올바른 tool을 구분하기 어렵다.
   2. LLM을 사용해 tool과 skill의 docstring·description을 더 풍부하고 분리 가능하게 재작성할 수 있다.
   3. 단순한 named-entity recognition보다 LLM-enhanced description을 사용하면 임베딩 공간에서 tool 간 separability가 커진다.
4. 보안 구분
   1. 일부 tool은 confidential data에 접근하고 일부는 그렇지 않으므로 description과 retrieval 결과에 access 권한을 반영해야 한다.

6.2. Hallucination 재시도와 patience 제어

1. 무한 재시도의 한계
   1. 돈이 무한하지 않으므로 hallucination이 계속되는 generation을 무한히 재실행할 수 없다.
   2. model별로 최대 tool call 수를 정하는 cutoff가 필요하다.
2. 실험값과 hysteresis 변수
   1. 사용한 Grok 4.1 fast reasoning 기준으로 최대 8~12 tool call이 포기 시점으로 적절하다는 경험값을 제시했다.
   2. 예시 질의는 어떤 때는 2번 만에 답을 찾고, 어떤 때는 16단계가 걸렸다.
   3. harness가 model에 허용할 patience를 hysteresis variable로 두면 모델 정확도와 문제 난이도에 맞춰 재시도 폭을 조정할 수 있다.
3. 모델 라우팅
   1. 어려운 문제는 frontier LLM으로 보내고, 쉬운 문제는 open-weight small language model(SLM)으로 보내는 router를 harness 안에 둘 수 있다.
   2. 모델 자체가 아니라 aggregator/orchestrator가 query 유형을 판단해 적합한 모델로 라우팅한다.

6.3. 미래의 모델 구성에 대한 답변

1. 작은 전문가들의 혼합
   1. 향후에는 문제 유형별 small expert를 섞는 구성이 유력하다는 개인적 전망이 제시됐다.
   2. 약 100 million parameter 규모라도 한 종류의 문제를 매우 잘 푸는 특화 모델을 만들 수 있다.
   3. aggregator가 올바른 query를 올바른 모델에 보내면 token-efficient harness가 된다.
2. 라우팅 비용 모델
   1. 일부 회사는 원래 지출할 금액에서 절약한 token 비용의 10%를 수수료로 받는 방식으로 이 기능을 제공한다.
   2. 따라서 model routing은 품질뿐 아니라 비용 제어를 위해서도 harness의 핵심 계층이 된다.

주요 발언 모음

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

“모델은 reasoning의 frozen part이고, harness는 비결정적인 LLM을 reliable하고 repeatable한 결과로 바꾸는 부분이다.”

“자동화는 시스템에 reliability를 주고, 자율성은 flexibility를 준다.”

“Context window는 short-term memory의 한 종류일 뿐이며, 더 크게 만드는 것이 모든 기억 문제의 해답은 아니다.”

“필요한 도구와 스킬만 실제로 필요할 때 context에 넣어야 한다.”

“미래는 문제 유형별 small expert들의 혼합이며, aggregator와 orchestrator가 올바른 모델로 query를 라우팅할 것이다.”

핵심 데이터 & 수치

• 약 1시간 1분: 전체 세션 길이(1:00:47)다.
• 첫 30분 + 다음 1시간 30분: 개념 소개와 workshop의 예정 시간 배분이다.
• 약 5분: GitHub Codespaces가 시작되는 데 걸리는 시간이다.
• 99.9%: 모델 가중치가 실무에서 바뀌지 않는다는 경험적 비율이다.
• 8·16·32개: 여러 agent가 한 파일을 동시에 수정할 때 언급된 동시 작업 규모다.
• 3곳: database replication factor 예시로 든 세계 지역 수다.
• 32-bit dense embedding: vector 데이터 표현의 예시다.
• 30분 대 8시간: context가 짧을 때와 지나치게 길 때 인간 attention을 설명한 비유의 시간이다.
• 19개 TODO: 모델 호출부터 전체 harness까지 구현하는 student notebook의 과제 수다.
• 16단계: Total revenue by product category 데모가 결과를 만들 때 표시된 단계 수다.
• 100~1,000개: 일상적인 file read/write/grep류 tool call 수가 보통 이 범위를 넘지 않는다는 설명이다.
• 2,000 대 10,000: HNSW vector index에서는 두 규모의 query 복잡도를 비슷하게 다룰 수 있다는 예시다.
• 8~12회: Grok 4.1 fast reasoning에 제시한 최대 tool call patience의 경험값이다.
• 약 100 million parameters: 특정 유형의 문제에 특화할 수 있는 small expert 모델 규모의 예시다.
• 10%: 일부 model-routing 회사가 절약된 token 비용에서 받는다고 한 수수료 예시다.

결론 및 시사점

1. 모델 선택만으로 신뢰성 문제를 해결할 수 없으며, model + harness를 하나의 제품 단위로 설계해야 한다.
2. application·model·infrastructure·compute가 commoditized될수록 기업 고유의 semantic layer와 데이터 운영 방식이 차별화 요소가 된다.
3. short-term file memory와 long-term database memory를 함께 쓰고, 필요할 때 장기 기억으로 promote하는 hybrid 구조가 현실적이다.
4. context window를 무작정 키우면 context rot과 quadratic attention 부담이 커지므로 context card, retrieval, toolbox로 입력을 선별해야 한다.
5. observe–reason–act loop에는 fault tolerance, retry cutoff, patience/hysteresis, model routing을 넣어야 비용과 hallucination을 통제할 수 있다.
6. OAMP 같은 memory abstraction은 compaction·summary·fact·preference·episodic question 관리를 단순화하지만, harness가 필요한 부분만 모델에 전달하도록 설계해야 한다.
7. embedding·reranking·context/token space 개선은 weight fine-tuning보다 저렴하고 빠른 continual learning 경로다.
8. 성공한 작업을 skill.md와 workflow로 distill하고 promote하면 개인의 선호와 조직의 tribal knowledge가 점점 더 재사용 가능한 절차가 된다.
9. 도구 수가 늘어날수록 HNSW 기반 hierarchical toolbox, 권한 인식 retrieval, LLM-enhanced description이 tool selection 품질을 좌우한다.
10. 100M parameter급 특화 모델을 aggregator가 라우팅하는 구조는 frontier 모델 하나를 모든 요청에 쓰는 것보다 token-efficient한 agent harness를 만들 수 있다.

핵심 요약 (20줄)

1. AI agent는 reasoning을 담당하는 LLM과 주변 실행 계층인 harness의 결합이다.
2. LLM 가중치는 대체로 고정되어 있으므로 데이터와 harness가 실제 제어 지점이 된다.
3. Agent stack은 application, data, model, infrastructure, compute의 다섯 층으로 구성된다.
4. MCP gateway는 고립된 모델을 애플리케이션과 데이터와 도구에 연결한다.
5. Chatbot은 수동적이고 RAG는 반수동적이며 workflow와 agent는 자동화와 자율성을 결합한다.
6. Harness는 storage, memory engineering, semantic layer, loop, context engineering, continual learning을 함께 설계한다.
7. 파일은 쉽게 만들고 append할 수 있지만 동시 수정의 transactional consistency와 백업이 부족하다.
8. Database는 ACID, high availability, vector search를 제공하고 Oracle DBFS는 파일과 database의 장점을 합친다.
9. Short-term memory는 현재 to-do를 담고 long-term memory는 선호와 과거 경험을 보존한다.
10. Shared memory는 sub-agent와 parent agent 또는 협업 agent 사이의 통신 공간이다.
11. Episodic memory는 경험을 저장하고 procedural memory는 재사용 가능한 workflow를 저장한다.
12. Context를 무작정 키우면 attention이 분산되는 context rot이 발생한다.
13. Context card는 topics, summary, facts, preferences, memories, unanswered question, recent messages를 압축한다.
14. Semantic layer는 조직의 암묵적 어휘와 데이터 모델과 query 관행을 agent의 지각 렌즈로 제공한다.
15. Agent loop는 observe, reason, act를 반복하며 오류가 있어도 fault-tolerant하게 지속되어야 한다.
16. Toolbox와 skillbox는 필요한 도구와 스킬만 매 iteration context에 로드한다.
17. Embedding과 reranking과 context 개선은 weight를 직접 바꾸지 않는 저비용 continual learning이다.
18. 성공한 workflow를 더 나은 skill.md로 distill하면 개인화된 skill이 계속 축적된다.
19. HNSW toolbox는 수천 개의 도구를 계층적 vector retrieval로 찾고 LLM-enhanced description은 유사 도구를 구분한다.
20. 최대 8~12회 tool call, 난이도별 model routing, 100M parameter급 small expert 조합이 비용과 신뢰성을 함께 관리한다.