현대의 엔지니어링 조직은 특이한 문제를 안고 있습니다.

그들은 너무 많은 컨텍스트 (Context)를 가지고 있습니다.

Slack에는 논의 내용이 담겨 있습니다.

Jira에는 이슈 (Issue)가 담겨 있습니다.

GitHub에는 구현 (Implementation) 내용이 담겨 있습니다.

Notion에는 명세 (Specification)가 담겨 있습니다.

고객 지원 시스템에는 최초의 불만 사항이 담겨 있습니다.

정보는 그곳에 존재합니다.

하지만 사라지는 것은 그것들을 연결하는 스레드 (Thread) 입니다.

몇 달 후, 누군가 질문합니다:

이 기능은 왜 만들어졌나요?

그 답변을 얻으려면 6개의 시스템을 열고, 수십 개의 메시지를 검색하고, 오래된 Jira 티켓을 읽고, 커밋 (Commit)을 조사하며, 원래의 결정을 기억하는 누군가에게 물어봐야 할지도 모릅니다.

이것은 일차적으로 검색 (Search)의 문제가 아닙니다.

이것은 계보 (Lineage) 문제 입니다.

ThreadWeaver v3는 다른 아키텍처를 탐구합니다:

인과적 작업 그래프 (The Causal Work Graph)

단순히 엔티티 (Entity)들이 어떻게 연관되어 있는지를 나타내는 것이 아니라, 증거와 불확실성을 보존하면서 조직의 시스템 전반에 걸쳐 작업이 어떻게 진화했는지를 나타내도록 설계된 그래프입니다.

1. 문제점: 파편화된 컨텍스트, 퇴락하는 관계

간단한 제품 결정을 생각해 봅시다.

고객 불만 (Customer complaint)
        ↓
Slack 논의 (Slack discussion)
...

모든 아티팩트 (Artifact)는 독립적으로 존재합니다.

하지만 조직적 의미는 관계 (Relationships) 속에 존재합니다.

고객 불만은 논의 내용을 설명합니다.

논의 내용은 결정을 설명합니다.

결정은 티켓 (Ticket)을 설명합니다.

티켓은 구현 (Implementation)을 설명합니다.

구현은 릴리스 (Release)를 설명합니다.

이러한 연결 고리들을 제거하면 조직은 데이터는 유지하지만 역사는 잃게 됩니다.

이는 특히 비용이 많이 드는 질문을 만들어냅니다:

"우리는 왜 이것을 했는가?"

2. 핵심 논지

ThreadWeaver는 의도적으로 좁게 설정된 가설을 바탕으로 합니다:

엔터프라이즈 AI (Enterprise AI)는 관련 정보를 검색하는 능력이 점점 더 좋아지고 있습니다. 하지만 더 어려운 문제가 남아 있습니다: 조직의 결정이 실제로 일어나는 시스템들 사이에서 작업의 인과적 계보 (Causal lineage)를 재구성하는 것입니다.

이것은 기존의 엔터프라이즈 검색 시스템이 그래프를 구축할 수 없다는 주장이 아닙니다.

현대의 엔터프라이즈 AI 시스템은 시맨틱 그래프 (semantic graphs), 커넥터 (connectors), 관계 (relationships), 그리고 조직적 컨텍스트 (organizational context)를 점점 더 많이 사용하고 있습니다.

ThreadWeaver가 탐구하는 차이점은 더 좁은 범위입니다:

단순히 관련된 지식을 검색하는 것을 넘어, **증거에 기반하고 탐색 가능한 결정 사항과 그 결과의 이력 (evidence-backed, traversable history of decisions and their consequences)**을 생성할 수 있는가?

그 차이점은 중요합니다.

그것은 기본 단위 (primitive)를 다음과 같이 변화시킵니다:

검색 (Search) → 문서 (Documents)

에서:

질문 (Question) → 서브그래프 (Subgraph) → 증거 (Evidence) → 계보 (Lineage)

로 말입니다.

3. 지식 그래프 (Knowledge Graph)에서 인과적 작업 그래프 (Causal Work Graph)로

전통적인 지식 그래프 (knowledge graph)는 다음과 같이 표현할 수 있습니다:

고객 (Customer)
   │
   ├── 소유 (owns) → 계정 (Account)
...

인과적 작업 그래프 (Causal Work Graph)는 업무의 전환 (transitions in work)을 나타냅니다:

고객 불만 (Customer Complaint)
       │
       │ 영향을 미침 (influenced)
...

따라서 이 그래프는 두 가지 다른 종류의 정보를 포함합니다:

노드 (Nodes)

발생했거나 존재했던 것들.

메시지 (Message)
결정 (Decision)
티켓 (Ticket)
...

엣지 (Edges)

그것들 사이의 관계.

언급 (mentions)
후속 (follows)
참조 (references)
...

엣지는 단순한 연결이 아닙니다.

그것은 **두 이벤트 사이의 관계에 대한 주장 (claim about the relationship between two events)**입니다.

4. 엣지는 일급 데이터 객체 (First-Class Data Object)이다

이것은 ThreadWeaver에서 가장 중요한 설계 결정 중 하나입니다.

다음과 같이 저장하는 대신:

A → B

우리는 다음과 같이 저장합니다:

엣지 (Edge)
├── 소스 (source)
├── 타겟 (target)
...

예시:

{
  "source": "slack:msg_1842",
  "target": "jira:issue_392",
...

이것은 근본적인 규칙을 만듭니다:

출처 (provenance) 없는 인과적 엣지는 없다.

시스템은 항상 다음과 같은 질문에 답할 수 있어야 합니다:

왜 이 두 이벤트가 연결되어 있다고 믿습니까?

5. 유사성 (Similarity)은 인과성 (Causality)이 아니다

이러한 구분은 AI 그래프 시스템에서 가장 위험한 실패 모드 중 하나를 방지합니다.

가정해 봅시다:

Slack:

"고객들이 CSV 가져오기 실패를 보고하고 있습니다."
...

임베딩 모델 (embedding model)은 높은 유사도 점수를 생성할 수 있습니다.

그것은 우리에게 다음과 같이 알려줍니다:

시맨틱 유사도 (semantic similarity) ≈ 높음

하지만 그것이 다음을 증명하지는 않습니다:

인과 관계 (causal relationship) = 참 (true)

해당 Jira 이슈는 몇 달 전에 이미 존재했을 수도 있습니다.

따라서 ThreadWeaver는 다음과 같은 관계들을 분리합니다:

Semantic (의미적)
Temporal (시간적)
Reference (참조)
...

예를 들어:

related_to (관련됨)
mentions (언급함)
follows (후속함)
...

시스템은 다음과 같은 변환을 절대 암묵적으로 수행해서는 안 됩니다:

similar (유사함)

into (다음으로):

caused (원인이 됨)

6. 인과 상태 (Causal Status)

실제 조직은 불완전한 증거를 생성합니다.

따라서 모든 인과 관계 (causal relationship)는 명시적인 상태를 가져야 합니다.

EXPLICIT (명시적)
INFERRED (추론됨)
PROBABLE (개연성 있음)
...

예를 들어:

PM Decision (PM 결정)
     │
     │ EXPLICIT (명시적)
...

은 다음과 같은 것보다 더 강력합니다:

Slack Discussion (Slack 논의)
     │
     │ PROBABLE (개연성 있음)
...

가능한 데이터 모델:

{
  "relation": "influenced" (영향을 미침),
  "causal_status": "probable" (개연성 있음),
...

이것은 단순한 메타데이터 (metadata)가 아닙니다.

이는 제품의 신뢰 모델 (trust model)의 일부입니다.

7. 증거 기반 계보 (Evidence-Backed Lineage)

다음과 같은 질문을 한다고 가정해 봅시다:

Jira #392는 왜 생성되었나요?

ThreadWeaver는 한 단락의 글을 생성하는 대신 다음과 같이 반환합니다:

Jira #392
    ↑
    │ created_after (생성됨)
...

그 다음:

Evidence (증거)

✓ Slack message #1842
...

사용자는 모든 출처를 검사할 수 있습니다.

이는 다음과 같은 결과를 만들어냅니다:

Lineage (계보)
+
Evidence (증거)
...

다음과는 다릅니다:

LLM-generated explanation (LLM 생성 설명)

이러한 차이점은 엔터프라이즈 시스템 (enterprise systems)에서 매우 중요합니다.

8. 그래프 스키마 (The Graph Schema)

최소한의 그래프는 다섯 가지 주요 객체 유형으로 표현될 수 있습니다.

엔티티 (Entity)

Entity {
    id
    type
...

예시:

Customer (고객)
Person (사람)
Project (프로젝트)
...

이벤트 (Event)

Event {
    id
    type
...

예시:

SlackMessage (Slack 메시지)
Decision (결정)
TicketCreated (티켓 생성됨)
...

엣지 (Edge)

Edge {
    id
    source
...

증거 (Evidence)

Evidence {
    id
    edge_id
...

권한 (Permission)

Permission {
    principal
    resource
...

이러한 분리를 통해 그래프는 하위 콘텐츠를 반드시 복사하지 않고도 관계를 보존할 수 있습니다.

9. 소스 데이터는 원래 위치에 머물러야 합니다

ThreadWeaver가 두 번째 엔터프라이즈 데이터 웨어하우스 (enterprise data warehouse)가 되어서는 안 됩니다.

더 안전한 아키텍처는 다음과 같습니다:

Slack ───────────────┐
Jira ────────────────┤
GitHub ──────────────┤
...

가능한 한 원시 데이터(Raw content)는 소스 시스템에 그대로 유지됩니다.

그래프는 다음을 저장합니다:

ID
포인터 (Pointers)
관계 (Relationships)
...

이는 중복을 줄이고 거버넌스 (Governance)를 더 쉽게 만듭니다.

10. 엔티티 해상도 (Entity Resolution)

그래프의 품질은 엔티티 해상도 (Entity Resolution) 성능에 달려 있습니다.

동일한 인물이 다음과 같이 나타날 수 있습니다:

Alice Smith
alice@company.com
alice-dev
...

ThreadWeaver는 3단계 전략을 사용해야 합니다.

1단계 — 결정론적 (Deterministic)

email
계정 ID (account ID)
티켓 ID (ticket ID)
...

2단계 — 확률론적 (Probabilistic)

모호한 사례를 위해 임베딩 (Embedding) 또는 유사도 기반 매칭을 사용합니다.

3단계 — 인간 확인 (Human Confirmation)

영향력이 큰 불확실한 매칭의 경우:

매칭 가능성:

Slack: Alice
...

원칙은 다음과 같습니다:

결정론적 방식을 우선시하고, 확률론적 방식을 그다음으로 하며, 모호함이 중요한 경우에는 인간의 확인을 거친다.

11. 통합 아키텍처 (Integration Architecture)

첫 번째 MVP는 의도적으로 다음 세 가지 시스템만 지원해야 합니다:

Slack
Jira
GitHub

아키텍처:

              ┌─────────┐
              │  Slack  │
              └────┬────┘
...

여기서 MCP는 통합 인터페이스로서 유용합니다.

하지만 MCP가 해자 (Moat)인 것은 아닙니다.

만약 해자가 생긴다면, 그것은 다음으로부터 옵니다:

엔티티 해상도 (Entity Resolution)
+
시계열 모델링 (Temporal Modeling)
...

12. 그래프 저장소 (Graph Storage)

첫 번째 구현에는 생소한 인프라 스택이 필요하지 않습니다.

두 가지 합리적인 접근 방식이 있습니다:

옵션 A — PostgreSQL

PostgreSQL
├── entities
├── events
...

장점:

• 성숙함 (mature)
• 운영이 단순함 (operationally simple)
• 트랜잭션 지원 (transactional)
• 배포가 용이함 (easy deployment)
• 벡터 검색 가능 (vector search available)
• 권한 관리를 위한 관계형 쿼리 (relational queries for permissions)

옵션 B — 그래프 데이터베이스 (Graph Database)

순회 복잡도 (traversal complexity)가 지배적이 될 때 그래프 데이터베이스가 매력적으로 변합니다.

예를 들어:

고객 (Customer)
 → 토론 (Discussion)
 → 결정 (Decision)
...

위와 같은 구조를 자연스럽게 순회할 수 있습니다.

따라서 MVP는 단순히 제품 이름이 '그래프'라는 이유로 그래프 데이터베이스를 선택하기보다는 다음을 최적화해야 합니다:

최소한의 운영 복잡도 (minimum operational complexity)

13. 그래프 제한 검색 (Graph-Bounded Retrieval)

ThreadWeaver는 조직 전체의 컨텍스트 (context)를 검색해서는 안 됩니다.

대신 다음과 같이 동작해야 합니다:

사용자 질문 (User Question)
      ↓
엔티티 탐지 (Entity Detection)
...

예시:

질문:

"CSV Import v2는 왜 출시되었나요?"

엔티티 해소 (Entity resolution)를 통해 다음을 찾아냅니다:

기능 (Feature): CSV Import v2

그 다음 그래프 탐색 (graph traversal)을 통해 다음을 검색합니다:

기능 (Feature)
├── 고객 요청 (customer requests)
├── Slack 논의 (Slack discussions)
...

오직 이 제한된 서브그래프 (subgraph)만이 LLM 컨텍스트 (context)가 됩니다.

이를 통해 다음 요소들이 감소합니다:

• 컨텍스트 크기 (context size)
• 지연 시간 (latency)
• 무관한 검색 (irrelevant retrieval)
• 환각 발생 범위 (hallucination surface)
• 추론 비용 (inference cost)

14. LLM이 그래프를 소유해서는 안 된다

이것은 또 다른 중요한 아키텍처 규칙입니다.

LLM이 데이터베이스가 되도록 두지 마십시오.

그래프는 결정론적 인프라 (deterministic infrastructure)여야 합니다.

LLM은 그 위에서 동작해야 합니다.

             인과적 그래프 (Causal Graph)
                  │
                  ▼
...

LLM은 설명할 수 있습니다.

요약할 수 있습니다.

분류를 도울 수 있습니다.

관계(relationship)를 제안할 수 있습니다.

하지만 권위 있는 상태 (authoritative state)는 모델 외부에 남아 있어야 합니다.

15. 인과적 에지 점수 산정 (Causal Edge Scoring)

유용한 에지 점수 산정 (edge-scoring) 시스템은 여러 신호 (signals)를 결합할 수 있습니다.

예를 들어:

CausalScore =
    w1 * 명시적 참조 (explicit_reference)
  + w2 * 직접 연결 (direct_link)
...

하지만 중요한 제약 사항이 있습니다:

높은 점수가 자동으로 "인과 관계가 있음"을 의미해서는 안 됩니다.

대신 다음과 같이 처리합니다:

점수 (score) ≥ 임계값_A (threshold_A)
    → 인과적 에지 후보 (candidate causal edge)

...

최종 상태는 다음 두 가지를 모두 보존해야 합니다:

점수 (score)

그리고:

인과 상태 (causal_status)

16. 시간적 추론 (Temporal Reasoning)

시간은 강력한 신호입니다.

그럴듯한 순서는 다음과 같을 수 있습니다:

고객 불만 (Customer complaint)
2026-07-01

...

하지만 시간만으로는 인과 관계를 확립할 수 없습니다.

따라서 다음과 같습니다:

시간적 증거 (Temporal evidence)
≠
인과적 증명 (Causal proof)

시간은 단지 추론 모델 (inference model)의 한 구성 요소일 뿐입니다.

17. 역방향 탐색 (Reverse Traversal)

가장 유용한 기능 중 하나는 역방향 탐색 (reverse traversal)입니다.

릴리스 (release)에서 시작하여:

릴리스 4.2 (Release 4.2)
     ↑
Git 커밋 (Git Commit)
...

시스템은 다음과 같은 질문에 답할 수 있습니다:

왜 이 릴리스에 이 변경 사항이 포함되어 있나요?

이것이 조직의 버전 히스토리 (version history)입니다.

Git은 다음과 같이 답합니다:

소스 코드는 어떻게 진화했나요?

인과적 작업 그래프 (Causal Work Graph)는 다음과 같은 질문에 답하려고 시도합니다:

업무는 어떻게 진화했나요?

18. 순방향 탐색 (Forward Traversal)

역방향만큼이나 순방향도 중요합니다.

다음에서 시작하여:

고객 불만 사항 #771 (Customer Complaint #771)

이렇게 질문합니다:

이것이 무엇을 야기했나요?

그래프는 다음과 같이 반환할 수 있습니다:

고객 불만 사항 (Customer Complaint)
        ↓
지원 에스컬레이션 (Support escalation)
...

이제 시스템은 단순히 정보를 검색하는 것이 아닙니다.

조직적 결과(organizational consequences)를 탐색하고 있는 것입니다.

19. UI는 질문에서 시작해야 합니다

ThreadWeaver는 복잡한 대시보드로 시작할 필요가 없습니다.

기본적인 상호작용은 매우 단순할 수 있습니다:

┌──────────────────────────────────────┐
│ CSV Import v2는 왜 구축되었나요?      │
└──────────────────────────────────────┘

그 다음:

고객 요청 (Customer Request)
       ↓
Slack 논의 (Slack Discussion)
...

모든 엣지 (edge)는 검사 가능합니다.

모든 추론 (inference)에는 신뢰 수준 (confidence level)이 있습니다.

모든 중요한 주장 (claim)에는 증거 (evidence)가 있습니다.

20. 명시적 트리거를 우선시하십시오

이 개념의 초기 버전에서는 암시적 의도 탐지 (implicit intent detection)를 고려했습니다:

마우스 움직임 (mouse movement)
스크롤링 (scrolling)
일시 정지 (pauses)
...

이는 불필요한 기술적 위험과 개인정보 보호 위험을 초래합니다.

MVP (Minimum Viable Product)는 다음과 같은 방식을 사용해야 합니다:

호버 (hover)
클릭 (click)
선택 (select)
...

예를 들어:

호버 (Hover):

Acme Corp

ThreadWeaver는 다음과 같이 보여줍니다:

Acme Corp
│
├── 불만 사항 (complaints)
...

행동 감시 (behavioral surveillance)는 필요하지 않습니다.

21. 권한은 그래프 데이터입니다

엔터프라이즈 컨텍스트 시스템 (Enterprise context systems)은 권한 부여 (authorization)를 사후 고려 사항으로 취급해서는 안 됩니다.

만약 Slack 메시지가 비공개라면, 해당 메시지에서 파생된 엣지 (edge)는 그 메시지의 가시성 제약 조건 (visibility constraints)을 상속받아야 합니다.

개념적으로는 다음과 같습니다:

엣지 (Edge)
  │
  ├── 증거 A (Evidence A) → 권한 A (permission A)
...

엣지의 유효한 가시성 (effective visibility)은 기반이 되는 증거를 존중해야 합니다.

근본적인 불변량 (invariant)은 다음과 같습니다:

그래프는 소스 시스템에서 사용자가 볼 권한을 가진 것보다 더 많은 것을 절대 드러내서는 안 됩니다.

22. 보안 모델

MVP는 다음과 같은 방식을 사용해야 합니다:

통합별 OAuth (OAuth per integration)
+
범위 제한 권한 (scoped permissions)
...

쓰기 작업 (Write operations)은 초기에는 비활성화되어야 합니다.

버전 1은 다음과 같아야 합니다:

READ

아니오:

READ + WRITE

제품은 먼저 다음을 증명해야 합니다:

"우리는 가치 있는 조직적 맥락 (organizational context)을 재구성할 수 있다."

그다음에만 다음을 시도해야 합니다:

"우리는 조직 시스템을 수정할 수 있다."

23. MVP 계약 (The MVP Contract)

절제된 MVP는 정확히 하나의 약속만을 가질 수 있습니다:

기능(feature) 또는 이슈(issue)가 주어졌을 때, 그것이 왜 존재하는지를 설명하는 가장 가능성 높은 사건의 사슬 (chain of events)을 재구성한다.

입력 (Input):

기능 (Feature) / Jira 이슈 (Jira Issue)

출력 (Output):

기원 (Origin)
↓
논의 (Discussion)
...

모든 엣지 (edge)에는 다음이 포함됩니다:

관계 (relationship)
신뢰도 (confidence)
근거 (evidence)
...

이것만으로도 첫 번째 제품으로는 충분합니다.

24. 60초 검증 테스트 (The 60-Second Validation Test)

최고의 데모는 다음과 같은 것이 아닙니다:

"우리의 아름다운 그래프를 보세요."

그것은 다음과 같습니다:

사용자 (User):