Meta의 조직적 세컨드 브레인: AI 에이전트의 메모리는 모델 가중치가 아니라 파일에 있어야 하는 이유

Meta의 Organizational Second Brain은 빠르게 변화하는 조직 지식을 모든 수정 사항, 정책 및 전문가의 판단을 모델 가중치에 담으려 하기보다 명시적인 파일에 보관해야 한다는 점을 강력하게 보여줍니다. Meta는 전문가의 지식을 사람이 읽고 에이전트가 사용할 수 있는 구조화된 파일 시스템으로 정제합니다. 이 파일 시스템은 종속성을 통해 연결되고, 변경 후 테스트 및 버전 관리와 검토를 거치며, 기반 모델을 재훈련하지 않고도 개선할 수 있습니다. 모델은 지능을 제공하고, 지식 레이어는 조직이 학습한 내용을 보존합니다.

그렇다고 모든 형태의 AI 메모리가 Markdown에 속한다는 뜻은 아니며, RAG가 더 이상 필요 없다는 뜻도 아닙니다. 모델 가중치는 여전히 일반 지식을 제공하고, 검색은 드문 참고 자료에 유용하며, 실시간 작업 상태는 데이터베이스나 에이전트 런타임에 저장하는 것이 적절할 수 있습니다. Meta가 해결하려는 문제는 더 좁지만 점점 중요해지고 있습니다. 바로 시간이 지나며 변화하고 출처를 추적할 수 있어야 하며, 어떤 모델이 사용하더라도 유지되어야 하는 조직 지식을 보존하는 것입니다.

Meta의 Organizational Second Brain이란 무엇인가요?

Meta의 Organizational Second Brain은 문서 곳곳에 흩어져 있거나 전문가의 머릿속에만 남아 있을 지식을 포착하도록 설계된 내부 AI 에이전트 아키텍처입니다. Meta는 이 시스템을 범용 챗봇이 아니라 특정 도메인을 위한 보조 전문가로 설명합니다.

Meta의 공식 Organizational Second Brain 아키텍처에 따르면, 이 시스템은 서로 의존하는 네 개의 레이어를 결합합니다.

중요한 점은 전문가가 에이전트를 수정할 때마다 Meta가 모델을 재훈련하는 데 의존하지 않는다는 것입니다. 대신 수정 사항은 외부 지식 파일이나 추론 절차의 변경으로 반영될 수 있습니다.

이를 통해 전문가와의 한 번의 상호작용이 일시적인 채팅 수정에서 잠재적으로 영구적인 조직 자산으로 전환됩니다.

수천 개의 문서가 에이전트 메모리와 같지 않은 이유는 무엇일까요?

문서로 가득한 폴더는 보관소입니다. 시스템이 무엇이 중요한지, 출처들이 어떻게 연결되는지, 특정 규칙이나 해석이 언제 적용되는지를 이해할 때에만 유용한 에이전트 메모리가 됩니다.

대규모 조직은 이미 정책, 사양, 과거 결정, 체크리스트, 보고서, 프로젝트 기록, 표준 및 내부 문서 등 방대한 양의 문서를 보유하고 있습니다. 문제는 가장 가치 있는 지식이 이러한 문서들 사이에 놓여 있는 경우가 많다는 것입니다.

전문가는 다음을 알고 있을 수 있습니다.

• 두 규칙이 충돌할 때 어떤 정책이 우선하는지
• 어떤 예외가 특정 조건에서만 적용되는지
• 어떤 과거 결정이 여전히 관련 있는지
• 조직이 내부적으로 사용하는 용어
• 사례가 에스컬레이션이 필요할 만큼 모호한 경우
• 그리고 겉보기에 비슷한 두 상황을 서로 다르게 처리해야 하는 이유

기존 검색 시스템은 원본 문서를 찾을 수 있지만, 모델은 여전히 매번 그 해석을 처음부터 재구성해야 할 수 있습니다.

Meta는 이를 원시 문서 자체를 조직 지식으로 취급할 때 발생하는 약점 중 하나로 설명합니다. 추론 시점에 청크를 반복적으로 검색하는 에이전트는 이러한 조각에서 조직의 사고방식을 매번 추론해야 하므로 속도가 느리고 일관성이 떨어질 수 있습니다.

Meta는 2026년 초에 이미 비슷한 문제를 경험했습니다. 부족 지식을 에이전트 컨텍스트 파일로 정리한 이전 작업에서 50개가 넘는 전문 에이전트가 4개 저장소의 4,100개가 넘는 파일을 분석해 간결한 컨텍스트 파일 59개를 만들었습니다. Meta는 예비 테스트에서 작업당 에이전트 도구 호출이 약 40% 감소했다고 보고했습니다.

교훈은 비슷합니다. 원시 정보가 많다고 해서 에이전트의 동작이 자동으로 더 나아지는 것은 아닙니다. 부족한 부분은 대개 정제된 구조입니다.

Meta는 왜 에이전트 지식을 구조화된 파일에 저장할까요?

Meta는 하나의 방대한 지침 문서를 유지하는 대신 200개가 넘는 파일을 엄격한 분류 체계로 구성합니다. 이 파일들은 서로 다른 유형의 조직 지식과 서로 다른 라우팅 책임을 나타냅니다.

Meta는 파일 간의 관계를 선언하기 위해 YAML 프런트매터도 사용합니다. 파일에는 해당 파일이 무엇을 정의하는지와 depends_on 그리고 어떤 다른 파일이 이를 참조하는지 referenced_by.

간단한 예시는 다음과 같습니다.

---
유형: 입장
주제: customer-data-retention
종속 항목:
  - data-classification.md
참조하는 파일:
  - privacy-review-recipe.md
적용되는 경우:
  - customer_pii = true
---

# 고객 데이터 보존

## 입장
현재 조직의 입장을 여기에 정의합니다.

## 경계
이 입장이 적용되는 경우와 적용되지 않는 경우를 문서화합니다.

## 예외
알려진 예외를 나열합니다.

## 에스컬레이션이 필요한 경우
전문가 검토가 필요한 사례를 설명합니다.

이는 Meta의 내부 파일을 그대로 옮긴 것이 아니라 설명을 위한 예시이지만, 일반 구조화 파일이 매력적인 이유를 보여줍니다.

다음과 같은 특징이 있습니다.

• 사람이 읽을 수 있습니다.
• 기계가 읽을 수 있으며
• 차이점을 비교하기 쉽고
• 상호 참조하기 쉽고
• 린트하기 쉽고
• 버전 관리가 가능하며
• 개별적으로 되돌릴 수 있고

에이전트가 변경 사항을 제안할 때는 종속성 그래프도 중요합니다. 하나의 정책 파일이 변경되면 시스템은 해당 편집이 고립되어 있다고 가정하는 대신 영향을 받을 수 있는 절차, 색인 및 다운스트림 규칙을 식별할 수 있습니다.

Meta의 세컨드 브레인은 RAG를 대체하는가?

아니요. Meta는 선별된 지식 계층과 검색 기능을 모두 의도적으로 유지합니다. 두 요소는 서로 다른 정보 문제를 해결합니다.

Meta는 정보의 밀도와 예상 사용 빈도에 따라 정보를 구분합니다.

선별된 계층에는 에이전트가 반복적으로 필요로 할 가능성이 높고 조직의 변화하는 도메인 해석을 나타내는 정보가 저장됩니다. 희소한 자료는 특정 사례에 필요할 때 의미 기반 또는 어휘 기반 검색을 통해 계속 이용할 수 있습니다.

이는 최초의 검색 증강 생성 연구에서 확립된 더 광범위한 구분과 일치합니다. 이 연구는 모델에 매개변수로 저장된 지식과 필요할 때 검색할 수 있는 명시적 외부 비매개변수 메모리를 구분합니다.

Meta는 사실상 이 두 극단 사이에 또 다른 계층을 추가하고 있습니다.

모델 가중치
일반 지능
        |
        v
정제된 지식
입장
규칙
해석
의사결정 프레임워크
        |
        v
RAG / 검색
상세한 근거
과거 기록
희귀한 참조 자료
        |
        v
원시 소스

이 구분을 설명하는 유용한 방법은 다음과 같습니다.

RAG는 에이전트가 근거를 찾도록 돕습니다. 엄선된 지식 계층은 에이전트가 매번 조직의 해석을 처음부터 다시 찾아내지 않도록 합니다.

AI 에이전트는 알고 있는 것과 추론하는 방식을 왜 분리해야 할까요?

Meta의 가장 중요한 설계 결정 중 하나는 선언적 지식과 절차적 추론을 분리한 것입니다.

지식 파일은 조직이 무엇을 알고 있거나 믿는지를 설명합니다. Meta의 ‘레시피’는 에이전트가 문제를 어떻게 해결해 나가야 하는지를 설명합니다.

이러한 분리는 실패를 더 쉽게 진단할 수 있게 합니다.

에이전트가 잘못된 결론에 도달하면 유지 관리자는 다음과 같이 질문할 수 있습니다.

• 올바른 지식이 존재했을까요?
• 올바른 파일이 로드되었을까요?
• 조직의 입장 자체가 잘못되었거나 오래된 것일까요?
• 아니면 추론 절차가 원래 올바른 지식을 잘못 사용했을까요?

Meta에 따르면 새로운 조직 직책을 추가할 때 추론 레시피를 변경하지 않고 지식 파일을 추가하고 라우팅 인덱스를 업데이트하면 됩니다. 반대로 방법론의 문제는 기본 도메인 사실을 다시 작성하지 않고 레시피를 변경하여 해결할 수 있습니다.

지식 기반이 커질수록 이러한 모듈성이 점점 더 큰 가치를 발휘합니다.

점진적 공개는 Meta의 토큰 사용량을 어떻게 약 80% 줄였을까요?

대규모 컨텍스트 창이 정보 아키텍처의 필요성을 없애지는 않습니다. 모델은 기술적으로 수십만 또는 심지어 수백만 개의 토큰을 받아들일 수 있지만, 그렇다고 모든 정책, 참고 자료, 지침을 모든 작업에 로드해야 한다는 뜻은 아닙니다.

Meta의 초기 구현은 비교적 평면적인 지침 구조와 시맨틱 검색을 사용했으며, 관련성이 서로 다른 많은 양의 자료를 컨텍스트 창에 가져올 수 있었습니다.

레시피 시스템은 패턴을 점진적 공개 방식으로 바꾸었습니다.

기존 접근 방식

작업
  |
  v
대규모 지침 집합
+ 다수의 검색된 출처
+ 광범위한 도메인 컨텍스트
  |
  v
모델


점진적 공개

작업
  |
  v
1단계
1단계 지침과 지식만 로드
  |
  v
2단계
2단계 지침과 지식만 로드
  |
  v
3단계
필요한 경우에만 근거를 검색합니다

레시피 기반 단계로 전환한 후 Meta는 각 쿼리가 지식 시스템에서 작고 대상이 명확한 하위 집합만 참조했으며, 턴당 소비 토큰이 약 80%.

그렇다고 Second Brain이 전체 AI 비용을 80% 줄였다는 뜻은 아닙니다. 이 결과는 구체적으로 컨텍스트 로딩 전략을 재구성한 후 턴당 토큰 사용량에 관한 것입니다.

더 일반적인 교훈은 중요합니다.

더 나은 질문은 “모델이 얼마나 많은 컨텍스트를 담을 수 있는가?”가 아니라 “이 단계가 문제를 올바르게 해결하려면 얼마나 적은 컨텍스트가 필요한가?”입니다.

Meta는 전문가 피드백을 영구적인 에이전트 메모리로 어떻게 전환하나요?

지식 저장은 시간이 지나도 지식을 올바르게 유지하는 일에 비하면 쉽기 때문에 자기 개선 루프는 Meta 아키텍처에서 가장 중요한 부분이라고 할 수 있습니다.

Meta는 유지 관리를 컴파일 문제로 다룹니다. 전문가의 수정 사항은 네 단계를 거칩니다.

1. 피드백을 진단하고 근본 원인을 파악합니다.
2. 문제를 최소한의 검증된 수정 사항으로 컴파일합니다.
3. 변경 사항이 회귀를 일으키지 않고 문제를 해결하는지 검증합니다.
4. 도메인 전문가와 함께 제안된 변경 사항을 검토합니다.

진단 단계에서는 오류가 지식 부족, 잘못된 추론 절차, 또는 진정한 모호성에서 비롯되었는지 확인하려고 합니다.

정답이 이미 원본 자료에 있었는데도 에이전트가 실패했다면 Meta는 이를 방법론의 문제로 간주합니다. 필요한 정보가 없었다면 지식 격차입니다. 전문가들끼리 의견이 다를 경우에는 시스템에 거짓된 확실성을 강제로 인코딩하는 대신 해당 사안을 상위 단계로 넘길 수 있습니다.

그런 다음 컴파일 단계에서 최소한의 수정안을 제안합니다. Meta에 따르면 별도의 에이전트들이 상호 참조의 영향, 기존 입장과의 충돌, 중복, 토큰 예산의 영향, 테스트 커버리지와 같은 문제를 검토합니다.

새로운 적대적 검토자는 원래의 개선 근거 없이 제안된 변경 사항을 전달받고 모순이나 엣지 케이스를 찾습니다. 그런 다음 결정론적 구조 검증을 통해 참조 손상, 종속성 순환, 식별자 충돌, 파일 크기 제한 위반과 같은 문제를 확인합니다.

이 과정은 다음과 같이 요약할 수 있습니다.

전문가 수정
        |
        v
근본 원인 진단
        |
        v
최소한의 수정안 제안
        |
        v
적대적 검토
        |
        v
구조 검증
        |
        v
재실행 + 회귀 테스트
        |
        v
사람의 검토
        |
        v
변경 사항 반영
        |
        v
실패를 테스트 모음에 추가

수정 사항이 반영되면 원래 실패했던 시나리오가 회귀 테스트 모음의 일부가 됩니다. 따라서 이후 변경 사항은 새로 수정된 동작을 유지해야 합니다.

Meta는 릴리스에서 설명한 6주간의 개발 기간 동안 개선 주기 전반에 걸쳐 회귀가 전혀 없었다고 보고했으며, 이전에는 며칠이 걸리던 개별 평가가 몇 분으로 단축되었다고 밝혔습니다. 이러한 결과는 독립적인 벤치마크가 아니라 Meta의 자체 내부 배포 결과입니다.

파일이 모델 가중치보다 업데이트하기 쉬운 이유는 무엇인가요?

빠르게 변화하는 조직 지식의 경우 파일을 사용하면 변경 사항이 눈에 보입니다. 이것이 이 헤드라인을 뒷받침하는 가장 강력한 주장입니다.

이는 모델 편집이 불필요하거나 불가능하다는 뜻은 아닙니다. MEMIT 모델 편집 연구와 같은 연구는 사실 연관을 Transformer 모델 내부에서 직접 변경할 수 있는 방법을 탐구합니다.

Meta는 다른 아키텍처적 질문을 던집니다.

조직의 지식이 자주 바뀌고 사람이 모든 중요한 업데이트를 검사해야 한다면, 애초에 그 지식을 모델 안에 넣어야 할까요?

Meta는 개선 파이프라인의 최종 출력물이 도메인 전문가가 빠르게 검토할 수 있는 diff라고 말합니다. 더 광범위한 설계 원칙은 이러한 복잡성을 버전 관리되고, diff를 확인할 수 있으며, 되돌릴 수 있는 텍스트 안에 유지하는 것입니다.

이를 통해 지식 유지 관리는 모델 재학습보다 소프트웨어 구성 관리에 훨씬 가까워집니다.

Markdown과 YAML은 AI 에이전트를 위한 이식 가능한 메모리 계층이 되어 가고 있는가?

Meta의 설계는 사람과 에이전트가 직접 검사할 수 있는 지식 표현을 지향하는 더 광범위한 흐름의 일부입니다.

2026년 4월, Andrej Karpathy는 LLM Wiki 패턴을 발표했습니다. 이 아이디어는 LLM이 매번 쿼리할 때마다 원시 RAG 결과에서 문서 간 지식을 재구성하는 대신, 지속적인 구조화된 위키를 점진적으로 유지하도록 하는 것입니다.

중요한 속성은 축적입니다.

출처 A
   |
   v
구조화된 위키

출처 B
   |
   v
기존 페이지 업데이트
관계 추가
모순 표시

출처 C
   |
   v
지식이 더 풍부해집니다
처음부터 다시 시작하지 않고

Google의 Open Knowledge Format 사양은 상호 운용성을 향해 같은 아이디어를 발전시킵니다. OKF v0.2는 중앙 스키마 레지스트리나 독점 런타임 없이 사람과 에이전트가 읽을 수 있는 YAML 프런트매터가 포함된 Markdown 파일 디렉터리를 기반으로 한 의도적으로 최소화된 형식을 정의합니다.

이는 잠재적으로 중요한 방향을 시사합니다.

일반 텍스트 기반 에이전트 지식은 상호 운용성 계층이 될 수 있습니다.

조직의 중요한 지식이 한 제공업체의 독점 메모리 시스템 내부에 숨겨지지 않고 명시적인 파일로 존재한다면, 이 동일한 지식 계층을 이론적으로 서로 다른 에이전트와 모델이 사용할 수 있습니다.

              지식
            Markdown / YAML
                 |
       +---------+---------+
       |         |         |
       v         v         v
    Claude     Gemini     Qwen
       |         |         |
       +---------+---------+
                 |
              에이전트

모델은 교체할 수 있습니다. 축적된 지식까지 반드시 교체할 필요는 없습니다.

AI 에이전트 메모리가 파일이 된다면, 그 파일은 어디에 저장해야 할까요?

에이전트 지식이 장기 보관되는 파일 집합이 되면 새로운 인프라 문제가 나타납니다. 이러한 파일에도 다른 중요한 조직 데이터와 동일한 보호 조치가 필요합니다.

제대로 구축된 지식 계층에는 다음이 포함될 수 있습니다.

• 엄선된 입장,
• 전문가의 결정,
• 분류 체계,
• 추론 레시피,
• 라우팅 로직,
• 평가 사례,
• 소스 문서,
• 인용,
• 에이전트가 생성한 개선 사항,
• 및 이전 버전.

이로 인해 LLM의 크기와는 거의 관련이 없는 요구 사항이 생깁니다.

이러한 요구 사항은 워크스테이션, 프라이빗 서버, 장기 보관 에이전트 지식용 NAS, Git 저장소 또는 통제된 클라우드 환경에서 구현할 수 있습니다. Meta의 아키텍처에는 특정 스토리지 제품이 필요하지 않습니다.

더 큰 관점에서 보면 에이전트 지식은 일시적인 프롬프트 컨텍스트라기보다 장기적으로 유지되는 데이터 자산에 가까워지고 있습니다.

버전 관리만으로 AI 메모리가 충분하지 않은 이유는 무엇일까요?

Git 스타일 버전 관리는 diff, 기록, 검토, 브랜치, 논리적 롤백을 제공하므로 구조화된 에이전트 지식에 매우 유용합니다. 하지만 완전한 데이터 보호 전략은 아닙니다.

버전 관리는 주로 다음 질문에 답합니다.

무엇이 변경되었는가?

빠른 복구를 위한 파일 시스템 스냅샷은 다른 질문에 답합니다.

잘못된 변경이 발생하기 전의 전체 작업 상태를 신속하게 복원할 수 있는가?

백업은 또 다른 질문에 답합니다.

원본 스토리지 시스템 자체가 손실되거나 손상된 경우 복구할 수 있는가?

에이전트가 자체 지식 계층을 업데이트할 수 있도록 허용되면 이러한 차이는 더욱 중요해집니다.

잘못된 편집은 Git에서 쉽게 되돌릴 수 있습니다. 하지만 손상된 저장소, 누락된 첨부 파일 모음, 손상된 벡터 인덱스, 실수로 삭제된 원시 소스 아카이브, 또는 고장 난 스토리지 장치는 전혀 다른 종류의 문제입니다.

지식 베이스가 조직 운영 방식의 일부가 된다면, 지식 보호는 단순한 프롬프트 엔지니어링이 아니라 데이터 인프라로 다뤄야 합니다.

오래 지속되는 로컬 에이전트 지식 스택은 어떤 모습인가?

실용적인 에이전트 메모리 아키텍처는 지능, 정제된 지식, 검색, 소스 데이터, 보호 기능을 하나의 계층으로 강제하지 않고 분리할 수 있습니다.

AI 모델
Claude / Gemini / Qwen / 기타
        |
        v
에이전트 런타임
도구 / 라우팅 / 세션
        |
        v
정제된 지식
입장
분류 체계
레시피
규칙
        |
        v
RAG / 검색
인덱스
임베딩
어휘 검색
        |
        v
원시 소스
PDF
문서
코드
과거 기록
        |
        v
데이터 보호
버전 관리
스냅샷
백업

이 아키텍처의 장점은 독립성입니다.

모델은 지식 베이스를 다시 작성하지 않고도 변경할 수 있습니다. 원시 소스를 삭제하지 않고도 검색 엔진을 변경할 수 있습니다. 전문가의 결정을 잃지 않고도 에이전트 프레임워크를 교체할 수 있습니다. 지식 자체의 논리적 구조를 변경하지 않고도 스토리지 하드웨어를 업그레이드할 수 있습니다.

이는 “현재 챗봇이 우연히 기억하는 모든 것”보다 훨씬 오래 지속될 수 있는 AI 메모리의 정의입니다.

Meta의 세컨드 브레인은 AI 에이전트 메모리의 미래를 보여주는가?

Meta의 아키텍처는 AI 에이전트 시스템에서 장기적인 자산이 모델보다 지식 계층이 될 가능성이 점점 커지고 있음을 시사합니다.

모델은 계속해서 빠르게 발전할 것입니다. 조직은 독점 프런티어 모델, 로컬 오픈 웨이트 모델, 특화 에이전트 또는 이 세 가지의 조합 사이를 오갈 수 있습니다.

조직 지식은 다른 시간 척도로 변화합니다.

회사는 다음과 같은 사항을 알아내는 데 수년을 투자할 수 있습니다.

• 어떤 절차가 실제로 효과가 있는지,
• 어떤 예외가 중요한지,
• 어떤 용어가 모호함을 피하는지,
• 어떤 과거의 결정이 여전히 유효한지,
• 그리고 어떤 전문가의 수정 사항을 다시 발견할 필요가 없어야 하는지도 알아야 합니다.

모델이 바뀐다는 이유만으로 그 지식이 폐기되어서는 안 됩니다.

Meta의 설계는 파일 기반 메모리가 다른 모든 메모리 기법을 대체하는 것이 아님을 분명히 보여줍니다. 더 강력한 아키텍처는 계층형입니다.

일반 지능을 위한 모델 가중치, 관리되는 조직 지식을 위한 구조화된 파일, 양이 적은 근거를 위한 RAG, 방법론을 위한 레시피, 진행 중인 작업을 위한 런타임 상태, 그리고 지속성을 위한 버전 관리와 백업으로 구성됩니다.

그 결과 AI “세컨드 브레인”을 바라보는 방식이 달라져야 합니다.

단순히 더 큰 컨텍스트 창인 것도 아닙니다.

PDF가 가득한 폴더인 것도 아닙니다.

그 자체로 벡터 데이터베이스인 것도 아닙니다.

그리고 지식이 하나의 모델 안에 영구적으로 갇혀 있는 것도 아닙니다.

지속 가능한 세컨드 브레인은 검사, 수정, 테스트, 복구가 가능하고 다음 모델에 넘겨줄 수 있도록 관리되는 지식 시스템입니다.

모델은 다음 달에 교체될 수 있습니다. 조직이 수년에 걸쳐 쌓은 지식은 모델과 함께 사라져서는 안 됩니다.

FAQ: Meta의 조직용 Second Brain과 AI 에이전트 메모리

Meta의 조직용 Second Brain이란 무엇인가요?

이는 Meta가 전문적인 조직 지식을 보존하기 위해 구축한 내부 AI 에이전트 아키텍처입니다. 구조화된 지식 파일, 조합 가능한 추론 레시피, 평가, 그리고 모델 자체를 재학습하지 않고 전문가의 수정을 검증된 업데이트로 전환하는 자기 개선 루프를 결합합니다.

Meta는 AI 에이전트의 메모리를 모두 Markdown 파일에 저장하나요?

아니요. 이 시스템은 가치가 높은 조직 지식을 위해 구조화된 파일 기반 지식 계층을 사용하면서, 양이 적은 참고 자료에 대해서는 의미 기반 검색과 어휘 검색을 계속 유지합니다. 모델 자체는 여전히 일반 지능을 제공하며, 그 밖의 런타임 상태는 지식 파일 외부에 존재할 수 있습니다.

Meta의 Second Brain이 RAG를 대체하나요?

아니요. Meta는 엄선된 지식과 RAG를 의도적으로 결합합니다. 자주 사용되는 입장, 의사 결정 프레임워크, 해석은 구조화된 파일로 정리하고, 세부 사양, 과거 기록, 자주 필요하지 않은 근거는 검색을 통해 계속 이용할 수 있도록 합니다.

그냥 백만 토큰 컨텍스트 창을 사용하면 안 되나요?

컨텍스트 창이 크다고 해서 관련 없는 컨텍스트를 무료로 활용할 수 있거나 유용해지는 것은 아닙니다. Meta는 단계적인 점진적 공개를 통해 각 추론 단계에서 필요한 지침과 지식만 불러오도록 하면, 이전의 더 광범위한 로딩 방식에 비해 턴당 사용되는 토큰을 약 80% 줄일 수 있다는 사실을 확인했습니다.

조직의 지식을 모델 가중치 외부에 보관하는 이유는 무엇인가요?

외부 파일은 사람이 검사하고, 편집하고, 인용하고, 버전을 관리하고, 차이를 비교하고, 테스트하고, 롤백하기가 더 쉽습니다. 또한 조직이 모델 제공업체를 변경하거나 기반 LLM을 업그레이드할 때도 동일한 지식을 유지할 수 있습니다.

Meta의 추론 레시피란 무엇인가요?

레시피는 에이전트가 작업을 분석하는 방법을 정의하는 절차적 지침입니다. 레시피는 지식 파일과 의도적으로 분리됩니다. 지식 파일은 조직의 사실과 입장을 설명하고, 레시피는 이를 적용하는 데 사용되는 추론 과정을 설명합니다.

Meta의 Second Brain은 전문가로부터 어떻게 학습하나요?

전문가의 수정 사항은 근본 원인으로 진단하고, 최소한의 수정 사항으로 변환한 뒤, 적대적 검증과 구조적 검증을 거쳐 리플레이 및 회귀 테스트 모음으로 테스트하고, 이후 인간 전문가의 검토를 받습니다. 성공한 수정 사항은 회귀 테스트 모음에 추가되어 향후 업데이트에서도 해당 수정 사항이 유지되도록 합니다.

파일 기반 에이전트 메모리는 벡터 데이터베이스와 같은 것인가요?

아니요. 벡터 데이터베이스는 주로 검색 메커니즘입니다. 구조화된 지식 파일은 엄선된 해석, 규칙, 종속성, 추론의 경계, 인용 및 사람이 검토한 변경 사항을 보존할 수 있습니다. 두 가지를 함께 사용할 수 있습니다.

동일한 지식 파일을 서로 다른 AI 모델과 함께 사용할 수 있나요?

그럴 가능성이 있습니다. Markdown과 YAML 같은 모델 독립적인 형식은 주변 도구가 스키마와 라우팅 규칙을 이해하는 한 서로 다른 에이전트 런타임에서 사용할 수 있습니다. 휴대 가능한 지식 형식이 점점 더 주목받는 이유 중 하나입니다.

에이전트 메모리에 NAS나 홈 서버가 필요한가요?

반드시 그럴 필요는 없습니다. 지식은 안정적이고 권한 관리가 가능한 모든 스토리지 시스템에 저장할 수 있습니다. 공유되고 지속적인 AI 지식을 위한 로컬 서버 또는 NAS는 지식 기반에 스냅샷, 대규모 원본 아카이브, 독립적인 백업도 필요할 때 유용해집니다.