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

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

본 페이지 = 설계 철학·원칙 (방향). 저장·citation·schema 구현 세부는 /architecture/artifacts, 결정 이력은 D-bp-para-1. 일부 항목은 열린 질문 (§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 들을 가로지른다.


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 의 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 로 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.

(2026-06-07 갱신 · D-gate-5, D-gate-3 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 §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 — artifact `scope` 컬럼)
2	Governance servicization — Blueprint core 결정로그 vs 독립 서비스	확정: 독립 `gate` 서비스 + Blueprint citation mirror (D-gate-1·D-gate-2, §7)
3	Project staffing (“던지면 emerge”) 메커니즘	후속 defer (D-bp-rust-1 — Project=컨테이너 + WorkspaceMember, emerge UX 는 후속)
4	Rust 적용 범위	확정: Blueprint 백엔드 점진 Rust 전환(strangler-fig), substrate=첫 organ, 프론트는 TS 유지 (D-bp-rust-1)

구현 토폴로지 (§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 “monolith first·신규 인프라 0” 을 언어만 Rust 로 refine). 상세 = D-bp-rust-1 + ADR docs/adr/blueprint-rust-migration.md.