Personal Operations MVP Architecture

1. 목적

이 문서는 Palantir for Individuals의 첫 구현을 위해 필요한 시스템 구성과 단계별 빌드 계획을 정리한다.

목표는 "삶 전체를 이해하는 AI"가 아니라 아래 세 가지를 안정적으로 수행하는 시스템이다.

개인 데이터를 운영 그래프로 정규화
현재 상태와 병목을 계산
특정 결정 질문에 대해 시나리오 비교 메모를 생성

2. MiroFish 대비 구조 변환

MiroFish	Personal Operations MVP
문서 업로드	개인 데이터 커넥터
온톨로지 생성	개인 운영 온톨로지
Zep 그래프 빌드	개인 운영 그래프 정규화
OASIS 에이전트 프로필	관점 에이전트 설정
소셜 플랫폼 시뮬레이션	시나리오 개입 엔진
리포트 에이전트	decision memo agent
시뮬레이션 후 인터뷰	관점별 질의응답

3. 시스템 구성

3.1 Ingestion Layer

역할:

외부 시스템에서 데이터 수집
원본 이벤트 저장
증분 동기화 상태 유지

초기 커넥터:

Google Calendar 또는 iCal import
Gmail 또는 email export
Notion 또는 markdown notes
task export
bank CSV

저장:

raw_events
sync_jobs
connector_cursors

3.2 Normalization Layer

역할:

원본 이벤트를 엔티티와 관계로 변환
증거와 신뢰도를 함께 저장
중복 엔티티를 합치고 identity resolution 수행

출력:

entities
edges
evidence_items

핵심 규칙:

source별 parser를 먼저 적용
parser로 불충분한 경우에만 LLM extraction 사용
LLM이 만든 필드는 derived_by=llm과 confidence를 강제

3.3 Graph Store

MVP 저장소는 Postgres 기반으로 시작하는 것이 적절하다.

필수 테이블:

entities
edges
entity_snapshots
metrics
decision_sessions
scenario_runs
decision_memos

이 단계에서 전용 graph DB는 필수가 아니다. 초기 요구는 traversal보다 "상태와 근거의 안정적 저장"이 더 중요하다.

3.4 State Estimator

역할:

그래프를 읽고 현재 상태를 계산
의사결정에 필요한 derived metrics 생성

초기 계산 항목:

WeeklyCommittedHours
DeepWorkHoursPerWeek
RunwayMonths
FreeCashFlow
ExecutionLoad
GoalAlignmentScore
ContextSwitchLoad

이 계층이 없으면 이후 agent는 서술은 잘하지만 실제 상태를 계산하지 못한다.

3.5 Scenario Engine

역할:

기준 상태를 복제
각 옵션별 개입 적용
메트릭 변화를 계산

개입 예시:

recurring meeting 제거
월 지출 절감
특정 프로젝트 pause
사이드 프로젝트 시간 블록 추가
통근 시간 절감 가정

출력:

scenario state delta
metric delta
unresolved assumptions

3.6 Perspective Agents

역할:

같은 상태를 서로 다른 가치 함수로 해석

초기 agent:

Current Self
Future Self
Executor
Risk Officer
Evidence Auditor

중요 원칙:

agent는 상태 계산을 하지 않는다
agent는 계산 결과와 그래프 근거를 해석하는 역할만 한다

3.7 Decision Memo Agent

역할:

질문을 decision session으로 기록
필요한 그래프 조회와 시나리오 실행
최종 메모 생성

출력 구조:

현재 상태
핵심 병목
옵션 비교
가장 큰 불확실성
추천 행동
근거 출처

3.8 Feedback Loop

역할:

사용자의 실제 선택 기록
이후 outcome 반영
예상과 실제 차이 추적

저장:

decision_outcomes
scenario_accuracy_log

이 레이어가 있어야 제품이 시간이 갈수록 calibration된다.

4. API 초안

Ingestion

POST /api/connectors/calendar/sync
POST /api/connectors/email/sync
POST /api/import/bank-csv
POST /api/import/notes

Graph and State

GET /api/graph/overview
GET /api/state/summary
GET /api/state/metrics
GET /api/graph/entity/:id

Decisions

POST /api/decisions
POST /api/decisions/:id/options
POST /api/decisions/:id/run-scenarios
GET /api/decisions/:id/memo
POST /api/decisions/:id/outcome

Time OS

GET /api/week/plan
POST /api/week/rebalance

5. 데이터 흐름

Connectors
  -> raw_events
  -> normalization
  -> entities + edges + evidence
  -> state estimator
  -> metrics
  -> scenario engine
  -> perspective agents
  -> decision memo
  -> user action / outcome
  -> graph update

6. UI 단위 제안

초기 화면은 네 개면 충분하다.

Overview: 현재 상태와 핵심 병목
Decisions: 결정 목록과 메모
Week: 일정 충돌과 재배치 제안
Relationships: follow-up이 필요한 사람과 맥락

7. 단계별 빌드 계획

Phase 0: Offline Prototype

범위:

수동 업로드된 calendar, notes, bank CSV
배치 정규화
정적 graph build
단일 decision memo 생성

성공 기준:

창업 준비나 이직 질문에 대해 읽을 만한 메모 1개 생성

Phase 1: Career + Time MVP

범위:

캘린더 + 노트 + task + bank CSV
state estimator 구현
scenario engine 3개 개입 지원
memo agent + citations

성공 기준:

두 가지 대표 질문을 안정적으로 처리
"이직/창업 준비"
"이번 주 일정 재구성"

Phase 2: Continuous Sync

범위:

커넥터 증분 동기화
outcome logging
memo refresh

성공 기준:

사용자가 한 번 세팅한 뒤 매주 새 상태를 자동으로 받을 수 있음

Phase 3: Relationship and CRM Layer

범위:

email and meeting graph 강화
follow-up detection
relationship heat metric

성공 기준:

중요한 관계와 후속조치를 시스템이 먼저 띄워줌

8. 리스크

데이터 정규화 품질이 낮으면 graph 자체가 오염된다
agent가 계산이 아닌 서술로 과잉 보완할 위험이 있다
개인용 제품에서 프라이버시와 신뢰 비용이 매우 높다
모든 도메인을 한 번에 다루면 제품 메시지가 흐려진다

9. 권장 구현 원칙

계산은 deterministic layer에서 먼저 수행
LLM은 extraction과 interpretation에 제한
모든 memo는 citation과 confidence를 포함
option simulation은 실 그래프가 아니라 복제된 scenario state에 적용
첫 버전은 Career + Time 외 범위를 의도적으로 제한