들어가며: "우리 회사 문서 다 넣었는데 왜 답이 이상하죠?"

실무에서 AI 에이전트 도입하다 보면 한 번쯤 듣는 질문이에요. 사내 위키, Confluence, PDF 수천 개를 벡터 DB에 밀어 넣고 "이제 똑똑해졌겠지" 했는데, 막상 돌려보면 일반론만 줄줄 읊는 챗봇이 나오죠.

메타(Meta) 엔지니어링 팀도 같은 문제를 정면으로 마주했습니다. 특정 도메인(예: 컴플라이언스)의 전문가들이 똑같은 질문에 매일 답하느라 정작 중요한 판단이 필요한 케이스에 시간을 못 쓰는 상황. 그래서 그들은 **"조직의 세컨드 브레인(Second Brain)"**이라는 컨셉으로 완전히 다른 접근을 시도했고, 6주 만에 실사용 가능한 수준까지 끌어올렸습니다.

이 글에서는 그 아키텍처를 뜯어보면서, 왜 순수 RAG로는 부족한지, 그리고 모델 재학습 없이 전문가 피드백을 영구적으로 반영하는 법까지 실무 관점에서 정리해볼게요.

📎 원문 근거자료: Meta Engineering - Organizational Second Brain

AI agent chat interface representing organizational second brain knowledge system for enterprise expert reasoning Dev Environment Setup

핵심 아키텍처: 4개 레이어로 쪼개라

메타가 공개한 시스템은 4개의 레이어로 구성됩니다. 각 레이어는 서로 의존하기 때문에 하나라도 빠지면 전체가 무너지는 구조예요.

1. Knowledge System (지식 레이어) - 조직의 세컨드 브레인

가장 중요한 통찰은 이겁니다. "문서 = 지식"이 아니다. 진짜 지식은 전문가 머릿속의 판단 방식에 있어요.

그래서 메타는 200개 이상의 파일을 **엄격한 분류 체계(taxonomy)**로 재구성했습니다.

  • Position files: "이 질문엔 이렇게 판단한다"는 조직의 공식 입장 + 경계 조건
  • Taxonomy / Vocabulary files: 조직이 쓰는 용어의 단일 진실 공급원(Single Source of Truth)
  • Routing indexes: 입력 특성 → 어떤 파일을 로드할지 결정 (임베딩 유사도에 의존하지 않음!)
  • Gateway files: 분석 도메인 진입 전 통과해야 하는 임계값 테스트

모든 파일은 YAML frontmatter에 depends_on, referenced_by를 선언해서 양방향 의존성 그래프를 형성합니다. 이게 왜 중요하냐면, 자기개선 루프가 자동 편집을 제안할 때 "이거 바꾸면 어디까지 영향 가는지" 추적이 가능해지기 때문이에요.

2. 지식은 '밀도'와 '사용 빈도'로 나눠라

여기서 실무적으로 진짜 중요한 결정이 나옵니다.

구분Wiki (구조화)RAG (검색)
특징고밀도, 상시 참조저밀도, 상황부 참조
예시Position, 결정 프레임워크, 경계 사례개별 제품 스펙, 과거 결정 기록, 외부 자료
이유매 턴 참조하니까 최신성 유지 필요매번 로드하면 컨텍스트 낭비

핵심은 **"핵심 추론은 항상 정제된 조직 지식에 그라운딩, 필요할 때만 RAG로 보조 증거 확보"**입니다.

3. Recipe (레시피) - 지식과 추론을 분리하라

여기가 제가 가장 감탄한 부분이에요. **Knowledge files는 선언적(declarative), Recipes는 명령적(imperative)**입니다.

# recipe_example.yaml (개념 예시)
name: compliance_assessment
steps:
  - step: 1
    action: "입력 분류"
    load_knowledge: ["taxonomy/entity_types.md"]
    checkpoint: true  # 전문가 검토 지점
  - step: 2
    action: "관련 position 로드"
    load_knowledge: ["positions/data_handling.md"]
    escalation_condition: "evidence_conflict"
  - step: 3
    action: "리스크 가중 평가"
    load_knowledge: ["frameworks/risk_weights.md"]

이 분리의 힘:

  • 조직 입장 추가 = knowledge file 추가 + routing index 업데이트 (레시피 변경 X)
  • 방법론 수정 = 레시피만 수정 (knowledge file 변경 X)
  • 실패 원인 = 어느 레이어 문제인지 깔끔하게 귀속

4. 토큰 80% 절감의 비밀

초기 버전은 단일 플랫 파일에 모든 소스를 시맨틱 검색으로 로드했어요. 매 턴마다 관련성 낮은 파일들이 컨텍스트를 잡아먹었죠. Recipe 기반 단계 분리 후 각 쿼리는 작고 타겟팅된 서브셋만 터치 → 턴당 토큰 소비 약 80% 감소. 컨텍스트 윈도우는 유한하고 어텐션은 볼륨에 따라 저하되니까, 이건 단순 비용 절감이 아니라 추론 품질 향상입니다.

Server infrastructure diagram visualizing structured knowledge files and dependency graph for AI agent compilation pipeline Technical Structure Concept

자기개선 플라이휠: 모델 재학습 없이 전문가 피드백을 영구 반영하는 법

이 시스템의 가장 독특한 부분은 Self-Improvement Flywheel입니다. 전문가 피드백을 4단계 컴파일 파이프라인으로 처리해요.

Step 1. Diagnosis - 대화 형태가 아니라 근본 원인으로 분류

처음엔 휴리스틱으로 시도했다가 실패했다고 합니다. "정보를 줬으면 지식 갭, 방향을 틀었으면 절차 문제"라는 접근은 대화 형태 ≠ 근본 원인이라서 안 통했어요.

작동하는 방식은 추출과 분류의 분리입니다:

  1. 전문가의 실질적 시그널 + 에이전트의 전체 지식 매니페스트(어떤 파일을 언제 어떻게 썼는지) 추출
  2. 실제 지식 파일을 읽고 단 하나의 귀속 테스트 적용:
    • 소스에 정답이 있었는데 틀림 → Recipe 문제
    • 소스에 정답이 없음 → Knowledge gap
    • 전문가들끼리 의견 갈림 → Ambiguity (인간 논의로 플래그)

Step 2. Compilation - 적대적 검토(Adversarial Review)

서브 에이전트들이 병렬로 영향도를 분석합니다. 신뢰성을 만드는 두 가지 설계:

  • 독립적 적대 검토: 개선 근거를 전혀 모르는 별도 에이전트가 오직 diff만 받아서 문제점(모순, 엣지 케이스 파괴, 입장 훼손)을 찾음. 컨텍스트를 공유하지 않으니 제안자의 블라인드 스팟을 상속받지 않음
  • 결정론적 구조 검증: Linter가 dangling 참조, 파일 크기 예산 위반, 식별자 충돌, 의존성 사이클을 프로그래밍적으로 잡음 (확률적 아님, Pass/Fail)

Step 3. Evaluation - 블라인드 이중 검증

  • Targeted replay: 피드백을 유발한 원본 시나리오로 재실행. 에이전트는 테스트받는 줄 모름. 별도 judge가 뭘 바꿨는지 모른 채 결과 평가 → 확증 편향 차단
  • Regression testing: 도메인별 Q&A 벤치마크를 병렬 독립 세션으로 실행. 회귀 감지 시 원본 이슈 + 시도된 수정 + 회귀 위치를 담은 프롬프트로 재컴파일

Step 4. Landing - 고정된 실패 시나리오가 자산이 됨

승인된 PR이 랜딩되면, 원래 실패 시나리오 + 검증된 정답이 자동으로 회귀 테스트 스위트에 추가됩니다. 즉, 모든 수정이 영구적으로 바를 올리고, 이후 변경은 방금 고친 동작을 반드시 보존해야 함.

실무 결과 (6주 3 스프린트)

  • 컴플라이언스 도메인 SME들이 에이전트 출력을 거의 항상 유용하다고 평가
  • 개별 평가 소요 시간 일(days) → 분(minutes)
  • 제로 회귀 달성, 매 수정이 회귀 스위트를 강화

⚠️ 이 아키텍처의 한계와 주의사항

솔직히 말하면, 이 아키텍처는 모든 팀에 맞지 않습니다. 도입 전에 다음을 반드시 체크하세요.

  1. 초기 큐레이션 비용이 만만치 않음: 200+ 파일을 taxonomy로 재구성하는 작업은 상당한 도메인 전문가 시간을 요구합니다. 문서가 10개 미만이면 그냥 RAG가 낫습니다.
  2. "판단 가능한 텍스트" 도메인이어야 함: 컴플라이언스, 재무 리스크, 보안 리뷰처럼 검색 가능한 텍스트로 판단이 표현되는 도메인에만 적용됩니다. 창의적 설계나 신제품 기획엔 부적합.
  3. Human-in-the-loop이 기본값이어야 함: 고위험 의사결정(컴플라이언스, 금융)에서는 checkpoint/escalation을 끄면 안 됩니다.
  4. 레시피 오버엔지니어링 주의: 절차가 너무 세분화되면 유지보수 지옥이 옵니다. 처음엔 3~5개 레시피로 시작하세요.

🇰🇷 한국 개발 생태계에서의 적용 맥락

국내 SI/SW 기업 환경에서는 특히 다음이 중요합니다:

  • 규제 산업(금융/의료/공공): 감사 추적(audit trail)이 필수인데, 이 아키텍처는 모든 변경이 diff + version-controlled라서 규제 대응에 유리합니다.
  • 사내 위키가 이미 죽어있는 조직: 문서를 "지식"으로 착각하지 마세요. Position file로 재해석하는 작업이 진짜 가치입니다.
  • 외주 개발 후 유지보수: 암묵지가 특정 개발자 머릿속에 있는 상황에서 이 패턴이 특히 빛납니다.

📚 다음 단계 학습 방향

이 아키텍처를 직접 시도해보려면:

  1. Andrej Karpathy의 LLM Wiki 개념부터 이해하기 (지식을 파일 그래프로 구조화)
  2. Google Open Knowledge Format 스펙 훑어보기 (cross-agent 상호운용성)
  3. 작은 도메인 하나 선정 → 10개 파일로 프로토타입 → 회귀 테스트 1개부터 시작

Data analysis dashboard showing regression test results and self-improvement loop metrics for enterprise AI knowledge base Development Concept Image

마무리: "복잡성을 모델 가중치가 아니라 텍스트 파일에 둬라"

메타 엔지니어링 팀이 남긴 가장 중요한 문장입니다:

"Keep the complexity in text files that are readable by both humans and agents, rather than fine-tuned model weights."

파인튜닝은 블랙박스고, 되돌리기 어렵고, 감사가 불가능합니다. 반면 텍스트 파일 기반 지식 시스템은:

  • 모든 개선이 30초 만에 도메인 전문가가 리뷰 가능한 diff
  • 모든 변경이 버전 관리, diff, 롤백 가능
  • 컴파일 파이프라인이 정교해도 출력은 항상 투명

결국 목표는 이겁니다. 전문가의 노력이 영구적으로 복리처럼 쌓이는 시스템. 모든 상호작용이 시스템을 더 낫게 만들고, 모든 수정이 검증된 개선으로 남는 것.

여러분 조직의 집단 지식이 아직도 개인 머릿속에 갇혀 있다면, 이 아키텍처는 진지하게 검토할 가치가 있습니다.

함께 보면 좋은 글

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.