Hyper Company Brain: AI 에이전트 지식베이스 엔지니어링

Claude Code에 코드를 바꿔 달라고 하면, 그것은 팀이 석 달 전에 왜 그 브랜치를 지웠는지 모릅니다. ChatGPT에 제품 결정을 물으면, 대답하기 전에 모든 문서를 다시 읽어야 합니다. 매 호출마다 프로젝트 이력을 다시 설명해야 하는 상황은 에이전트와 일반 RAG의 실제 차이 중 하나입니다. RAG는 정적 문서를 검색하는 데 능하지만, 회사 지식에는 기본적으로 처리하지 못하는 세 가지 차원이 있습니다. 사실 유효성, 권한 범위, 의사결정 뒤의 추론 체인입니다.

Hacker News에서 Hyper는 스스로를 “company brain”이라고 설명했습니다. 마케팅 표현처럼 들릴 수 있지만, 창업자가 출시 스레드에서 공유한 아키텍처 세부 사항은 유용합니다. episodes와 facts로 나뉜 2계층 메모리, typed edges, 타임스탬프 모델, hooks와 MCP라는 두 가지 주입 경로입니다. 이 글은 제품 리뷰가 아닙니다. 저는 이 공개 세부 사항을 사용해 회사 메모리 뒤의 설계 문제를 풀어 봅니다. 5계층 체크리스트, 7일 파일럿 경로, 평가용 위험 표입니다.

일반 RAG가 처리하지 못하는 세 가지 컨텍스트

RAG는 문서를 검색하고 chunks를 반환한 뒤 모델이 답하게 합니다. 이 workflow는 정적 지식베이스에는 잘 맞지만, 회사 지식에는 일반 RAG가 기본적으로 처리하지 못하는 세 가지 차원이 있습니다.

차원	기본 RAG 동작	실제 문제	company brain에 필요한 것
사실 유효성	가장 최근에 매칭된 chunk를 반환	오래된 문서가 곧 무효 사실은 아닙니다. 석 달 전 결정이 뒤집혔을 수 있습니다	사실 생명주기를 표시하는 introduced_at / invalidated_at 타임스탬프
권한 범위	Retrieval이 사용자 신원을 구분하지 않음	모두에게 보이는 것과 이 프로젝트 팀에 보이는 것은 다릅니다. 에이전트가 보면 안 되는 콘텐츠를 읽을 수 있습니다	팀이나 역할로 필터링하는 access-control tags
의사결정 이유	결론 chunk를 반환	결과를 아는 것과 추론 체인을 아는 것은 다릅니다	Episodes가 원본 대화를 보존하고 facts가 derived from 출처를 기록

전통적인 RAG는 최신성이나 관련성으로 순위를 매깁니다. 어떤 정보가 더 새로운 fact에 의해 대체되었는지 알 수 없습니다. Hyper는 각 fact에 두 개의 타임스탬프를 부여합니다. introduced_at은 처음 등장한 시점을 기록하고, invalidated_at은 무효가 된 시점을 기록합니다. Retrieval은 문서 갱신일에 의존하지 않고 무효 facts를 필터링합니다.

권한 범위는 여러 사람이 있는 조직에서 더 민감합니다. 에이전트 호출은 특정 팀원을 대표할 수 있고, 그 에이전트는 해당 구성원의 프로젝트 범위 밖 콘텐츠를 읽으면 안 됩니다. Hyper는 access-control tags로 각 fact의 가시성을 표시하고, retrieval 계층은 결과를 반환하기 전에 호출자 신원으로 필터링합니다. 이는 보통 문서 수준 권한에서 멈추는 일반 엔터프라이즈 검색보다 더 세밀합니다. Company brain에는 fact 수준 필터링이 필요합니다.

의사결정 이유는 일반 RAG가 가장 어려워하는 부분입니다. “왜 MongoDB 대신 PostgreSQL을 골랐나요?”라고 물으면 RAG는 아키텍처 문서의 결론 문단을 반환할 수 있습니다. 그 문단에는 석 달 전의 기술 토론, trade-off, 최종 의사결정 논리가 들어 있지 않을 수 있습니다. Hyper의 episodes 계층은 원본 대화 노드를 보존하고, facts 계층은 derived from typed edges를 통해 원본 episodes를 가리킵니다. 그러면 retrieval은 결과뿐 아니라 추론 체인까지 관계를 따라 돌아갈 수 있습니다.

Hyper의 2계층 메모리 아키텍처

Hyper는 메모리를 두 계층으로 구성합니다. 원본 저장소인 Episodes와 구조화 계층인 Facts이며, 둘은 knowledge graph로 연결됩니다.

Episodes 계층: Episodes는 원본 대화 노드를 보존하고 컨텍스트를 버리지 않습니다. Facts의 provenance anchor 역할을 합니다. 에이전트가 의사결정 과정을 추적해야 할 때, fact에서 derived from edge를 따라 원본 대화 조각으로 돌아갈 수 있고, 요약된 결론만 읽지 않아도 됩니다.

Facts 계층: Facts는 subject-predicate-object 구조를 사용합니다. 각 fact에는 subject, relation, object가 있고, 타임스탬프와 typed edges가 붙습니다. 창업자는 세 가지 typed edges를 공개적으로 설명했습니다.

Typed edge	의미	사용 사례
derived from	fact가 어느 episode에서 왔는지	의사결정 뒤의 추론 추적
supersedes	새 fact가 옛 fact를 대체	무효 fact를 표시하고 오래된 결론 필터링
tension	두 facts가 충돌하거나 불일치	사람에게 교정을 알리고 충돌 정보 신뢰 방지

타임스탬프 모델: 각 fact에는 두 개의 시간선이 있습니다. T 시간선은 “결정이 3월에 내려졌다”처럼 이벤트가 발생한 시간을 기록합니다. T’ 시간선은 “이 fact가 6월에 지식베이스에 기록됐다”처럼 시스템이 fact를 받아들인 시간을 기록합니다. 이 구분은 중요합니다. 회사 지식은 종종 늦게 들어옵니다. 회의 결론이 일주일 뒤에 기록될 수 있으므로, 시스템은 어떤 일이 발생한 시간과 시스템이 그것을 알게 된 시간을 분리해야 합니다.

아키텍처 핵심 포인트:

• Episodes는 요약되어 사라지지 않습니다. HN 창업자 댓글과 Zep paper 맥락에 따르면 원본 대화 노드를 보존합니다.
• Facts는 공개 HN 세부 사항에 따라 triples로 구조화되고, 각각 timestamps와 typed edges를 가집니다.
• introduced_at / invalidated_at은 fact 생명주기를 표시하고, retrieval 계층은 무효 콘텐츠를 필터링합니다.
• Typed edges는 그래프가 단순 facts가 아니라 관계를 저장하게 합니다. 이것이 평범한 벡터 데이터베이스와의 핵심 차이입니다.

이 아키텍처의 목적은 더 많은 데이터를 저장하는 것이 아닙니다. 에이전트가 관계를 따라 컨텍스트를 찾게 하는 것입니다. 일반 벡터 데이터베이스는 유사한 chunks를 반환하지만, chunks 사이의 논리적 의존성, 대체 관계, 충돌을 알지 못합니다. Typed edges와 timestamps의 조합은 retrieval 결과가 이 fact가 어디에서 왔는지, 아직 유효한지, 대체되었는지 같은 메타데이터를 함께 갖게 합니다.

두 경로: retrieval과 주입

지식이 쓰인 뒤 에이전트는 두 경로로 그것을 사용할 수 있습니다. 에이전트가 능동적으로 질의하는 retrieval과, 에이전트가 수동적으로 컨텍스트를 받는 주입입니다.

Retrieval 메커니즘은 창업자의 HN 댓글을 기준으로 보면 다음과 같습니다.

• Postgres full-text search: 특정 API endpoint 정의처럼 정확한 질의에 맞는 키워드 매칭.
• Embedding semantic search: “지난번 성능 최적화에 대해 무엇을 결정했지?”처럼 모호한 질문에 맞는 벡터 유사도 검색.
• Reciprocal Rank Fusion (RRF): full-text와 semantic recall을 결합하고 집계 순위로 결과 반환.
• Access-control tag 필터링: 호출자 신원에 따라 결과를 잘라 권한 경계를 보존.

이는 순수 벡터 데이터베이스와 다릅니다. 순수 semantic recall은 정확한 키워드 질의에서 결과를 놓칠 수 있습니다. Hyper는 RRF로 두 recall 경로를 결합하고, keyword match와 semantic similarity를 모두 순위에 반영합니다.

주입 경로 비교: hooks와 MCP는 서로 다른 데이터 채널입니다.

차원	Hooks	MCP
메커니즘	에이전트에 실시간 컨텍스트 주입 (push)	표준화된 tool-calling protocol (pull)
투명성	HN 댓글은 설치 prompt가 충분히 보였는지 의문을 제기	OpenAI SDK workflow는 명시적인 MCP server 선언을 요구
적합한 용도	현재 프로젝트 docs 같은 자동 컨텍스트 주입	데이터베이스 질의 같은 에이전트 주도 tool call
기술 의존성	클라이언트 측 interception layer 필요	OpenAI나 Anthropic tools처럼 agent framework의 MCP 지원 필요
거버넌스 위험	사용자가 어떤 데이터가 주입됐는지 모를 수 있음	관리자가 MCP server 권한 범위를 제어 가능

두 경로는 함께 존재할 수 있습니다. Hyper 창업자는 Claude Code를 열 때 프로젝트 docs를 로드하는 것처럼 hooks가 에이전트에 실시간 컨텍스트를 주입하는 데 쓰이고, MCP는 에이전트가 Notion이나 Gmail 같은 외부 도구를 능동적으로 호출할 때 쓰인다고 말했습니다. 하지만 일부 HN 댓글은 hook 투명성을 질문했습니다. 사용자가 어떤 데이터가 에이전트 대화에 자동 주입되는지 명확히 알고 있나요?

평가할 때는 두 가지를 확인하세요. hooks에 명시적인 설치 prompt가 있는지, MCP server 권한 범위가 관리자로 제어되는지입니다. OpenAI의 developer mode 문서는 MCP apps에 보안 검증이 필요하고, Enterprise plan에서는 RBAC로 접근을 제어할 수 있다고 말합니다. 그래서 MCP 거버넌스 모델은 상대적으로 성숙하지만, hook 투명성은 제품 설계에 달려 있습니다.

5계층 company brain 체크리스트

Company brain을 만들거나 평가한다면 다섯 계층 모두에 구체적인 답이 있는지 확인하세요. 어떤 계층이 빠져도 실제 사용에서 드러납니다.

1계층은 데이터 소스 수집입니다.

• 도구 선택: 팀 workflow에 따라 Notion, Gmail, Slack, GitHub, Linear, Jira.
• 수집 방식: 실시간 업데이트에는 webhooks, 예약 확인에는 polling. Webhooks가 빠르지만 원본 시스템 지원이 필요합니다.
• 데이터 정리: Slack 잡담 채널 같은 noise 필터링, 민감 정보 표시, 인코딩 정규화.
• 초기 import: 전체 이력 또는 새 데이터만. 이력 데이터에는 오래된 facts가 많을 수 있습니다.

2계층은 fact schema입니다.

• Fact 형태: 일관된 형식으로 저장되는 subject-predicate-object triples.
• Timestamps: 첫 등장에는 introduced_at, 무효화에는 invalidated_at. 둘 중 하나가 없으면 생명주기 판단이 약해집니다.
• Typed edges: provenance용 derived from, 대체용 supersedes, 충돌용 tension은 최소한 필요합니다.
• 충돌 처리: 사람 검토를 위해 tension을 자동 표시하거나, 적절할 때 timestamp 기준으로 더 새로운 fact를 선택합니다.

3계층은 retrieval입니다.

• Recall 조합: full-text keyword search + semantic embeddings + RRF fusion. 순수 semantic recall은 정확한 질의를 놓칠 수 있습니다.
• 권한 필터링: 호출자 신원으로 결과를 잘라내는 fact 수준 access-control tags.
• 순위화: recency, relevance, fact validity를 결합하고 무효 facts를 필터링합니다.
• 지연 시간 목표: 실제 retrieval 응답 500 ms 미만. 그렇지 않으면 에이전트 호출이 느리게 느껴집니다.

4계층은 주입입니다.

• 경로 선택: 실시간 컨텍스트 주입에는 hooks, 에이전트 주도 접근에는 MCP. 둘은 함께 쓸 수 있습니다.
• 에이전트 호환성: Claude Code, Cursor, ChatGPT, Codex가 선택한 경로를 지원하는지.
• 거버넌스 모델: hooks에 투명한 설치 prompt가 있는지, admins가 MCP server 권한을 제어하는지.
• 컨텍스트 크기 제어: token 초과를 피하려고 주입 컨텍스트 길이를 제한하고 relevance가 높은 facts를 우선합니다.

5계층은 거버넌스입니다.

• 권한 상속: 원본 권한을 fact 수준 가시성으로 매핑합니다. 비공개 Slack 채널의 facts가 모두에게 보이면 안 됩니다.
• 감사 로그: 누가 언제 어떤 fact를 주입했는지, 에이전트가 어떤 facts를 읽었는지. 사고에는 추적성이 필요합니다.
• 사람 교정: 잘못된 facts를 표시하고 invalidated 흐름을 설계하며, 수동 clarification facts를 지원합니다.
• 데이터 export: lock-in 위험 평가를 위해 전체 fact store를 JSON이나 CSV로 export할 수 있는지 확인합니다.

체크리스트의 논리는 단순합니다. source 계층은 데이터가 어디에서 오는지 결정합니다. fact 계층은 어떤 구조가 저장되는지 결정합니다. retrieval 계층은 시스템이 정보를 찾는 방식을 결정합니다. injection 계층은 컨텍스트가 에이전트에 도달하는 방식을 결정합니다. governance 계층은 누가 통제하고, 교정하고, 감사하는지 결정합니다. 어느 한 계층이라도 빠지면 지식베이스는 실전에서 막힙니다.

7일 파일럿 경로

소규모 팀은 첫 주에 모든 Slack, 이메일, CRM 데이터를 연결하면 안 됩니다. 권한은 복잡하고, noise는 너무 많아서 거버넌스 문제가 너무 일찍 드러납니다. 저위험 출처부터 시작하고, recall과 교정을 검증한 뒤 확장하세요.

1-2일차: 저위험 데이터 소스 선택

• 제품 로드맵과 기술 명세 같은 공개 Notion 문서.
• 프로젝트 아키텍처와 API docs 같은 GitHub README와 Wiki.
• 비공개 Slack 채널, 과거 이메일, CRM 고객 데이터는 권한에 민감하고 noise가 많으므로 제외합니다.

3일차: fact schema 설계

• 3-5개 필드를 사용하세요. subject, predicate, object, introduced_at, source.
• 완벽한 schema를 목표로 하지 마세요. 파일럿은 retrieval 경로 검증이 목적이고, schema는 진화할 수 있습니다.
• 이름 규칙을 정하세요. subject에는 ProjectX 같은 일관된 형식을 쓰고, predicate는 uses 같은 동사를 사용합니다.

4-5일차: retrieval과 주입 테스트

• Retrieval test: 5-10개 질의를 준비하고 핵심 facts가 발견되는지 확인합니다.
• Injection test: Claude Code나 Cursor 같은 에이전트 하나를 선택하고 주입된 컨텍스트를 읽을 수 있는지 검증합니다.
• 지연 시간 기록: retrieval이 500 ms 미만인지, 주입 뒤 에이전트가 facts를 올바르게 인용하는지 확인합니다.

6-7일차: 재생과 사람 교정

• 과거 질의를 재생하고 결과에 잘못되었거나 오래된 facts가 포함되는지 확인합니다.
• 오류 기록: invalidation이 필요한 facts를 나열하고 표시 흐름을 설계합니다.
• 교정 설계: 사람이 clarification facts를 추가하고 잘못된 facts에 invalidated_at 타임스탬프를 표시하게 합니다.

첫 주에는 하지 마세요:

• Slack, 이메일, CRM을 연결하지 마세요. 권한과 noise가 너무 복잡합니다.
• 완벽한 schema를 좇지 마세요. retrieval 경로를 먼저 검증하고 그다음 반복하세요.
• production data source를 연결하지 마세요. test data나 public docs로 흐름을 검증하세요.

파일럿이 끝나면 작동하는 retrieval-plus-injection 흐름, 검증된 facts 5-10개, 교정 프로세스가 있어야 합니다. 이것들이 데이터 소스를 확장하기 위한 전제 조건입니다. 먼저 시스템이 facts를 찾고, 읽고, 교정할 수 있는지 확인한 뒤 더 많은 도구를 연결하세요.

평가용 위험 표

결정하기 전에 일곱 가지 위험 차원을 확인하세요. 각 항목에는 source와 confidence level이 있어야 합니다.

위험 차원	공개 정보	근거	신뢰도	평가 중 확인할 것
데이터 export	창업자가 export를 지원한다고 말함	Launch thread 창업자 답변	medium	Export 형식(JSON/CSV), 완전성, 마이그레이션 비용
프라이버시 약속	FAQ가 사용자 데이터로 학습하지 않고 AES-256 암호화를 쓴다고 알려짐	Hyper FAQ	medium	SOC 2 / ISO 27001 일정, 데이터 저장 위치
Vendor lock-in	self-hosted 옵션 없음	Launch thread 답변	high	Export가 완전한지, 대안이 대체할 수 있는지
Hook 투명성	사용자들이 설치 prompt가 충분히 보였는지 질문	Launch thread 사용자 피드백	medium	사용자가 어떤 데이터가 주입되는지 아는지
권한 상속	access-control tags	Launch thread 창업자 세부 설명	high	source permissions가 fact-level permissions로 어떻게 매핑되는지. 상속 규칙은 공개되지 않음
Knowledge graph 컨텍스트	typed edges가 관계를 보존	Launch thread 창업자 세부 설명	high	사용자 우려처럼 episode summarization이 의도를 잃는지
충돌 처리	사람 교정 workflow는 공개되지 않음	Launch thread 제품 논의	low	facts를 wrong으로 표시하고 수동 clarification할 수 있는지

이 일곱 차원 중 데이터 export와 vendor lock-in은 평가에서 가장 주의해야 합니다. 창업자는 HN 댓글에서 export가 지원된다고 말했지만, 완전한 공식 약속은 확인하지 못했습니다. 따라서 export 형식이 JSON이나 CSV처럼 구조화되어 있는지, 전체 fact store와 typed edges, timestamps를 포함하는지, 다른 시스템으로 옮기려면 정리가 얼마나 필요한지 확인해야 합니다.

Hook 투명성도 놓치기 쉬운 위험입니다. Hooks는 클라이언트 측에서 컨텍스트를 주입하고, 사용자는 어떤 데이터가 에이전트 대화에 자동으로 로드됐는지 모를 수 있습니다. 평가 중에는 제품이 명확한 설치 prompt를 제공하는지, 사용자가 주입 데이터 범위를 확인하거나 제어할 수 있는지 확인하세요.

권한 상속은 access-control tags라는 공개 기술 방향이 있지만, 상속 규칙은 공개되지 않았습니다. 실제 질문은 구체적입니다. 비공개 Slack 채널에서 온 fact는 fact 수준 가시성으로 어떻게 매핑되나요? CRM 고객 데이터는 팀별로 어떻게 잘리나요? 구매하든 구축하든, 이 매핑 로직에는 설계가 필요합니다.

다음 단계와 관련 글

에이전트와 지식베이스를 더 깊게 보고 싶다면 BetterLink의 관련 글들이 좋은 다음 정류장입니다.

• RAG + Agent: 차세대 AI 애플리케이션 아키텍처 — retrieval 결과가 에이전트 의사결정을 어떻게 이끌 수 있는지.
• AI Agent 메모리 시스템: 에이전트가 컨텍스트를 기억하게 하기 — 개인 에이전트 메모리 아키텍처와 회사 수준 공유 메모리와의 차이.
• Workers AI + Vectorize RAG 튜토리얼 — 작은 RAG 시스템을 만들기 위한 Cloudflare Vectorize 실전 세부 사항.
• AI Agent 모니터링과 자가 복구 — 실패를 감지하고 재시도할 수 있도록 메모리와 실행을 연결하는 방법.
• Agent Tool Calling 실전 — 주입 경로를 보완하는 MCP와 tool calling 세부 사항.

결론

Hyper는 아직 초기 제품입니다. 그래도 2계층 메모리, typed edges, 타임스탬프 모델, hooks/MCP 이중 경로 같은 공개 아키텍처 세부 사항은 회사 메모리를 어떻게 설계해야 하는지 배우는 데 유용한 사례입니다. 소규모 팀이 이런 시스템을 평가하거나 구축한다면, 가장 중요한 세 가지 확인 사항은 데이터 export, hook 투명성, 충돌 처리입니다.

좁은 workflow부터 시작하세요. 공개 Notion docs나 GitHub README로 시작한 뒤, Slack이나 이메일을 연결하기 전에 retrieval recall과 교정을 검증하세요. 완벽한 schema부터 좇지 마세요. Fact 생명주기, 권한 상속, 사람 교정 흐름은 모두 실제 테스트가 필요합니다.

팀이 이미 Claude Code나 Cursor를 사용한다면, 작은 다음 단계는 hooks로 프로젝트 docs를 주입해 에이전트가 facts를 올바르게 인용하는지 관찰하는 것입니다. 그다음에는 monitoring과 recovery로 메모리를 실행과 연결해, 실패가 조용히 반복되지 않고 감지되고 재시도되게 하세요.