---
title: PCE 파라메트릭 변경 엔진 (Parametric Change Engine)
tags: [solver, PCE, dependency-graph, DAG, propagation]
sources:
  - raw/ai-research/레빗(Revit) 파라메트릭 모델링의 핵심 솔버(Solver)와 연산 아키텍처에 관한 심층 연구.md
  - raw/ai-research/Google AI Ultra 로 업그레이드시 구현가능성.md
updated: 2026-04-14
principles: [증분]
---

# PCE 파라메트릭 변경 엔진 (Parametric Change Engine)

## 요약
Revit의 거시 계층 엔진. 모델 내 모든 매개변수·요소의 관계를 **종속성 그래프(Graph of Dependencies)**로 유지하고, 변경을 연쇄 전파해 뷰·도면·일람표의 **양방향 연관성(Bidirectional Associativity)**을 보장. 오토데스크 독자 개발.

## 사실 (Facts)

### 종속성 그래프와 전파 메커니즘
1. **상태 변경(Triggering):** 사용자가 파라미터를 수정.
2. **연쇄 전파(Propagation):** PCE가 그래프를 추적해 종속 노드를 **무효화(Invalidated)** 마킹.
3. **재평가(Re-evaluation):** 무효 노드 재계산. 기하 갱신이 필요하면 [[GCS 기하학적 구속조건 솔버|GCS(D-Cubed)]] 호출.

### 바인딩 구조
- Revit 객체는 **절대 좌표가 아닌 상대값 + 호스트-게스트(Host-Hosting) 관계**로 바인딩.
- 모든 객체·주석·치수선은 단일 빌딩 모델 DB의 **포인터** 역할.

### DAG 요구사항과 순환 의존성
- 종속성 그래프는 **Directed Acyclic Graph (DAG)** 이어야 함.
- 매개변수 A→B→C→A 순환 발생 시 솔버는 **교착 상태(Deadlock) / 무한 루프**에 빠짐 → 시스템 크래시 가능.
- Revit은 입력 단계에서 **구문 분석 + 위상 정렬(Topological sorting)**로 순환 감지 시 "Cyclic dependency exists" 에러를 반환하고 **하향식 강제 차단**.
- 부작용: 자기 참조적(Self-referential) 피드백 루프 생성을 원천 차단 → 설계 자유도 제약.

### 성능 병목 — 직렬화(Serialization)
- 그래프 연산은 **본질적으로 직렬화**: A의 결과가 나와야 B, B가 나와야 C.
- 따라서 **멀티스레드·GPU 가속의 한계.** 단일 코어 CPU **클럭 속도 + L1/L2/L3 캐시** 성능이 최대 병목.
- Nav isworks 간섭검토(단순 기하 충돌)가 GPU 가속되는 것과 대조적.
- MEP 네트워크처럼 긴 종속 사슬이 있으면 성능이 극도로 저하.

### 외부 엔진과의 충돌
- **FEM (구조해석):** Revit은 형태 중심, Robot Structural Analysis 등은 중심축 기반 분석 모델 필요 → 변환 시 파라메트릭 논리 손실 · 편심(Eccentricity) 정보 불일치.
- **에너지/환경 최적화:** 수만 번 반복 필요 → 매 반복마다 전체 종속성 그래프 재구축 → 시뮬레이션 시간 기하급수적 증가. 실무자는 **Dynamo / Grasshopper**로 우회.

### 자체 구현 시 소프트웨어 공학적 난제 (출처 2)
- 순환 의존성 통제(실시간 구문 분석 + 위상 정렬 안전장치).
- 단일 코어 CPU 캐싱을 극한으로 끌어올리는 **C++/Rust 기반 메모리 아키텍처** 필요.

### HFDM / Project Quantum (미래 방향)
- Autodesk Amar Hanspal·Brian Mathews가 주도. 이후 **Plasma / AEC Data Model API**로 계승.
- **고주파 데이터 관리(High-Frequency Data Management)**: 파일(RVT) 단위 트랜잭션 → 클라우드 기반 객체 단위 분산.
- 효과: 종속성 재계산을 **마이크로서비스·클라우드 노드로 병렬 분산** → CPU 병목 해소.
- 솔버가 **오픈 API 마이크로서비스**로 진화 (Speckle 등 오픈소스 협업 데이터 허브와 결합).

## 해석 (Interpretation)

- PCE의 직렬화 병목은 우리 **증분 인터랙티브 파라메트릭** 원칙이 정면으로 돌파해야 할 지점. 토목은 선형에 수백~수천 객체가 종속되므로 Revit식 접근은 스케일 문제.
- 대안 탐색 방향:
  1. **증분 갱신 알고리즘** — 전체 DAG 재평가 대신 변경의 영향 경계(영향권, cone of influence)만 재계산. 반응형 프로그래밍(Reactive Programming), Incremental Computation 문헌 조사 필요.
  2. **데이터 지역성 최적화** — Rust 재설계 검토 중인 엔진은 메모리 배치(Structure-of-Arrays, Entity-Component 등)로 캐시 효율 극대화 가능.
  3. **분산 아키텍처** — HFDM 방향성을 처음부터 반영하면 로컬/클라우드 하이브리드가 가능.
- 순환 의존성 차단은 정책적으로 동의. 다만 토목은 선형·지형과 구조물 간 양방향 상호작용이 자연스러우므로 **"순환처럼 보이지만 실제로는 고정점(fixed-point) 수렴 문제"**를 구분해 다룰 필요가 있을 수 있음.

## 관련 페이지
- [[Revit 파라메트릭 아키텍처]]
- [[GCS 기하학적 구속조건 솔버]]
- [[파라메트릭 취약성 Davis 5가지]]