<!-- canonical: https://docs.axelabs.ai/architecture/para-os -->
<!-- source: content/architecture/para-os.mdx -->

---
title: PARA OS — 일하는 방식과 지식의 구조
description: Blueprint 의 PARA 는 파일 정리법이 아니라 조직론. Area(영속 기능) × Project(임시 TFT) matrix org 를 substrate 로, 지식이 claim·judgment·document 로 흐른다. dispatch="집"(link) 모델, governance 결정로그+결재워크플로, 죽은 딜 본질.
---

# PARA OS — 일하는 방식과 지식의 구조

Blueprint 의 PARA 는 파일 정리법이 아니라 **조직론**이다. Area(영속 기능) × Project(임시 TFT) 의 matrix org 를 substrate 로 삼고, 그 위에 지식이 흐른다. 도메인 서비스(frame/hive/index)는 성숙한 Area 가 물질화한 것, Blueprint 는 모든 Area 의 기본 substrate + 가로 결정로그.

> 본 페이지 = 설계 **철학·원칙** (방향). 저장·citation·schema 구현 세부는 [/architecture/artifacts](/architecture/artifacts), 결정 이력은 [D-bp-para-1](/ops/decisions). 일부 항목은 **열린 질문** (§10) — 확정 시 decisions 등재. SoT 메모 = `project_para_ai_os_philosophy.md` (Blueprint global memory).

## 1. PARA = 조직론

| Layer | 조직론적 정체 | 시간성 | 예 |
|---|---|---|---|
| **Project** | cross-functional TFT (동적 조직) — 목표 향해 모였다 끝나면 흩어짐 | 임시 | 딜, 펀드 결성, 유상증자, 분쟁 조정 |
| **Area** | 영속 기능 (정적 조직) — 통상의 부서 | 영속 | Finance · HR · Investment · Legal · IR · BOD |
| **Resource** | 일하는 방법·틀 — Project·Area 수행의 지식 기반 | 재사용 | DD 체크리스트, IC 템플릿, 섹터 프레임, 회사소개서 |
| **Archive** | 식은 이력 — 적극 탐색 불요 | 냉동 → 폐기 | 죽은 딜, 종료 프로젝트 |

Project 와 Area 는 matrix org 의 두 축이다 — **정적 기능 × 동적 태스크포스**. Project 가 전사에 던져지면 참여자가 emerge 하므로 "살아있는 팀"이자 "컨테이너"다 (둘 다).

## 2. 기하학 — Area 가 척추, R/A 는 Area 안

PARA 는 4 개 평등한 형제가 아니다. **Area 가 척추**이고, Resource 와 Archive 는 *각 Area 안에* 매달린다. Project 만 Area 들을 가로지른다.

```text
Area (영속 기능) ── 척추
  ├─ Live state   서비스화(frame/hive/index)  |  미졸업(Blueprint artifact)
  ├─ Resource     그 기능의 방법·틀  (hot)
  └─ Archive      그 기능의 식은 이력  (cold)
Project (TFT) ── Area 들을 가로지르는 동적 레이어
```

## 3. MCP = 물질화된 Area + 졸업 경로

도메인 서비스는 추상 서비스가 아니라 **Area 를 AI-native 로 물질화한 것**이다. frame = Finance Area, hive = HR Area, index = Investment Area. "폴더+artifact 만으로 Area 관점이 부족 → 개별 서비스화 + DB 적재로 UX 극대화" 가 그 동기.

- **기본 = Blueprint artifact** (인큐베이터). 새 테넌트·새 Area 는 전부 여기서 시작.
- **졸업 = 전용 MCP 서비스**. 트리거 = 저장이 아니라 **도메인 로직/operation + AI 상호작용** (frame=복식부기·마감, hive=급여계산, index=IRR). 단순 저장이면 Blueprint 로 충분.

## 4. Blueprint = 모든 Area 의 기본 substrate

| 층위 | 미졸업 / 무서비스 Area | 졸업 Area (frame/hive/index/gate) |
|---|---|---|
| Live state | Blueprint artifact | 서비스가 소유 |
| Resource | Blueprint | **서비스가 자기 도메인 Resource 소유** (index = DD 체크리스트·섹터 프레임·IC 템플릿) |
| Archive | Blueprint (cold) | **서비스가 자기 도메인 Archive 소유** (index = 죽은 딜) |
| 결정 로그 | gate SoR · Blueprint citation mirror (가로) | gate SoR · Blueprint citation mirror (가로) |

→ **Blueprint = 도메인 서비스가 *안 덮는* 것의 substrate**: (a) 미졸업·전용 서비스 없는 Area 의 live + R/A, (b) **cross-service 종합물**(보드팩·cross-domain 메모 — 각 서비스로 citation), (c) PARA fabric(workspace/dispatch/home·link) + **gate.decision mirror**(가로). 졸업한 서비스(index 등)는 자기 도메인 지식(**죽은 딜·섹터 프레임 포함**)을 *가져간다* — moat(죽은 딜 복리) = index, Blueprint = 토대 + 연결 조직.

## 5. 저장 substrate — 저장소(SoR) vs 검색 index 구분

벡터 DB·임베딩·rerank 은 **저장소가 아니라 검색 index**다. 진실 바이트가 아니라 원본 가리키는 임베딩만 둔다. 그래서 "OneDrive 냐 Pinecone 이냐" 는 양자택일이 아니라 "OneDrive(SoR) + 벡터 index".

| 대상 | 저장 (SoR) | 검색 |
|---|---|---|
| typed Area live (예: frame 잔액) | 서비스 DB | typed 쿼리 (벡터 불요) |
| Resource (hot) | 파일 / artifact | **벡터 index** (의미검색) |
| Archive (cold) | 싼 cold 보관 | 거의 안 함 — 폐기 전 *추출 지식만* 영구·queryable |

## 6. Dispatch = "집(home)" 모델

> **move 냐 copy 냐 link 냐 — 이 고민은 폴더가 강요한 가짜 3지선다다.** 폴더는 파일을 물리적으로 한 곳에만 둔다. 그래서 "투자계약서가 딜 소속이냐 Legal 소속이냐" 에 좋은 답이 없다.

전환: **artifact 는 몸통이 하나, 집은 여럿(link).** dispatch = 바이트 이동이 아니라 *집 배정*이다.

| 산출 종류 | 동작 | 예 (실제 워크스페이스) |
|---|---|---|
| 소유·소모성 | **move → Archive → 폐기** | LoI 초안 v1~v5, dataroom 원본, 회의 스크래치 |
| Area 영구 귀속 | **link / 정착** (canonical 은 Area, Project 는 참조) | 인감·고유번호증·통장(펀드 entity), 투자계약서(Legal), 서명 NDA, 최종 LoI, IRR claim(index) |
| 재사용 지식 | **copy-curate → Resource** (복제 아닌 재사용본 저작) | 섹터 경쟁분석, 펀드 결성 템플릿(1호→2호), 리턴모델 방법론 |

즉 **link 가 기본**(다중 집), move 는 소모성 working 파일만, copy 는 재사용본을 *새로 저작*할 때만. 이는 [D-bp-entity-2](/ops/decisions) 의 copy-with-provenance default 를 **link-default 로 revise** 한 것. cross-functional 분배는 별도 동작이 아니다 — Project 가 가로질러서 산출이 *원래부터* 여러 Area 소속이다.

## 7. Governance — 결정로그(record) vs 결재워크플로(process)

지식뿐 아니라 **결정**도 1급이다. 둘을 가른다:

- **결정 로그 (record)** — 무엇이·누가·언제·무슨 권한으로·뭘 근거로 결정됐나. append-only, 불변(수정 아닌 **supersede**), 모든 Area 가 cite. **record SoR = gate `decision` 테이블**(서비스가 SoR 소유) · **Blueprint = `gate.decision` citation mirror(가로 거버넌스)** — [D-gate-2](/ops/decisions) 로 refine(원래 "Blueprint core primitive" → service-owns-SoR + visibility-gated mirror, standalone 가능). frame 의 `register_resolution` / `query_effective_resolutions` / `link_journal_to_resolution` 이 회계 범위 결정로그 — 이를 가로로 일반화.
- **결재 워크플로 (process)** — 기안 → 결재선(DOA) → 승인/반려 → 시행 = 한국형 전자결재. 그 위 policy-driven·agent-assisted 레이어. 워크플로 완료 → 결정로그 한 줄 방출.

**서명은 한 종류**다: 내부 sign-off = 외부 e-sign = "행위자가 결정을 시점에 (법적으로) 확정". 서명은 결정 파이프라인의 **actuator** 로 실행되고, 봉인 결과를 결정에 link 한다. **Area 서비스 = 결정 파이프라인의 actuator** — 승인된 결정 → `frame.post_journal`/`index.register_deal` 호출, 결과를 결정에 link(앞으로) + 도메인 변경이 승인 결정을 cite(뒤로). 통합 구현 = [backlog B-bp-decision-pipeline-esign](/ops/backlog).
>
> **(2026-06-07 갱신 · [D-gate-5](/ops/decisions), [D-gate-3](/ops/decisions) e-sign 입장 supersede)**: 직접 서명엔진 build 는 *defer 되지 않고 당겨져 **구현**됐다* (암호등급). gate Phase-1 = **gate-native `esign.gate` actuator** — 시행 시 승인된 결정의 canonical bytes 를 **CAdES-BES → RFC3161 → CAdES-T** 로 server-seal(단일 서버 서명 identity, RSA-2048+SHA-256), append-only `esign_seal` evidence(전자문서법 §5 custodian) 저장 + `verify_seal` 검증. 법적 근거 = 전자서명법 2020 사서명(실지명의 = gate auth · 서명의사 = 결재 승인). 모두싸인 = optional alt provider 로 강등. **잔여**: 외부 서명자 본인확인기관(정보통신망법 §23-3) = 진짜 Phase-2; HSM(trait ready)·PAdES-PDF·prod-key = 하드닝. red-team 이 직접-build 를 막았던 P0(HSM·HTML→PDF 결정성·custody)는 해소-또는-명시(canonical bytes 결정성 now / HSM abstraction ready / custody = esign_seal + TSA). 상세 = [/architecture/governance](/architecture/governance) §6.

> 한국 시장에서 전자결재 + e-sign 은 **table-stakes** — 테넌트가 당연히 기대한다. internal 편의가 아니라 product requirement.

## 8. 본질 — 죽은 딜을 저장한다

live deal 관리는 누구나 한다 (moat 아님). **VC 지식의 압도적 대부분은 죽은 딜에 있다** — 시장맵·경쟁분석·섹터 thesis·valuation, 그리고 무엇보다 **judgment("왜 패스했나")**. 통상 이게 Archive 에 묻혀 증발한다. AI-native fund 가 **죽은 딜 지식을 재사용 Resource + queryable judgment corpus 로 harvest** 하면 복리로 쌓인다 ("이 섹터 딜 N 건 봤고 패턴은 이렇다").

그래서 Archive 모델이 정밀해진다: **raw 파일은 싸게 폐기, 추출 지식(judgment + 큐레이션된 섹터 Resource)은 영구·queryable.** 폐기 전 harvest 가 §6 dispatch 의 copy-curate 가 존재하는 *이유*다. 이것이 Investment Area 서비스(index)가 invested 딜뿐 아니라 **passed/dead 딜을 1급으로 저장**해야 하는 근거.

## 9. 관통 원칙

- **종류별로 가른다** — 한 상자에 여러 종류를 욱여넣으면 탁해진다. copy/link, Archive/Area, dispatch 가 다 그 증상이었다. 조직론 축(Area/Project/Resource/Archive) + 인식론 축(claim/judgment/document)으로 분해하면 녹는다.
- **claim · judgment · document** — claim(관측: source-cited, live, 갱신) · judgment(판단: author, 불변·supersede) · document(산출: 둘의 구성).
- **link 가 기본, 단일 출처** — copy 는 재사용본 저작에만.
- **결정은 불변 로그** — process(결재)가 record(결정로그)를 낳는다.
- **신규 코드 = Rust** (2026-06-06 사용자 지침).

## 10. 열린 질문 — 처리 현황

| # | 질문 | 상태 (2026-06-06) |
|---|---|---|
| 1 | 2-level scope (personal efforts + shared Areas) | **확정: personal + shared** ([D-bp-rust-1](/ops/decisions) — artifact `scope` 컬럼) |
| 2 | Governance servicization — Blueprint core 결정로그 vs 독립 서비스 | **확정: 독립 `gate` 서비스 + Blueprint citation mirror** ([D-gate-1](/ops/decisions)·[D-gate-2](/ops/decisions), §7) |
| 3 | Project staffing ("던지면 emerge") 메커니즘 | **후속 defer** ([D-bp-rust-1](/ops/decisions) — Project=컨테이너 + WorkspaceMember, emerge UX 는 후속) |
| 4 | Rust 적용 범위 | **확정: Blueprint 백엔드 점진 Rust 전환(strangler-fig), substrate=첫 organ, 프론트는 TS 유지** ([D-bp-rust-1](/ops/decisions)) |

**구현 토폴로지** (§4 substrate 가 *어떻게* 사느냐): PARA substrate 는 Blueprint 의 **첫 Rust organ** 으로, `blueprint-postgres` 의 `substrate` schema 를 소유하는 sidecar(axum)다 — frame/hive 식 독립 product-service 가 아니라 `axe ship blueprint` 한 경로 안의 내부 organ ([D-bp-artifact-4](/ops/decisions) "monolith first·신규 인프라 0" 을 *언어만 Rust* 로 refine). 상세 = [D-bp-rust-1](/ops/decisions) + ADR `docs/adr/blueprint-rust-migration.md`.

## 관련

- [/architecture/artifacts](/architecture/artifacts) — Artifact · Citation 저장/스키마 구현 세부 (본 페이지의 field-level 토대)
- [/architecture/governance](/architecture/governance) — gate 결정 거버넌스(결재 + e-sign + 법무) 상세 + Phase-1/2 경계 ([D-gate-1](/ops/decisions))
- [D-bp-para-1](/ops/decisions) — 본 페이지의 결정 등재 ([D-bp-entity-2](/ops/decisions) copy→link revise)
- [backlog B-bp-decision-pipeline-esign](/ops/backlog) — 결재 + e-sign 통합 서비스화