🌌 프랙탈 구조: 현실 세계의 무한 중첩
마치 러시아 인형(마트료시카)처럼 큰 시스템 안에 작은 시스템이,
그 안에 더 작은 시스템이 무한히 중첩되는 구조입니다.
이런 자연의 중첩 구조를 DS Language가 그대로 구현합니다.
🏭 현실 공장의 프랙탈 구조 예제 (5단계 깊이)
📦 Level 1: 스마트 팩토리 (Project)
전체 공장 = 수십 개의 생산 라인 집합
전체 공장 = 수십 개의 생산 라인 집합
🏭 Level 2: 자동차 조립 라인 (System)
하나의 라인 = 여러 스테이션의 연결
하나의 라인 = 여러 스테이션의 연결
🤖 Level 3: 용접 스테이션 (Work)
스테이션 = 로봇팔 + 컨베이어 + 센서
스테이션 = 로봇팔 + 컨베이어 + 센서
🦾 Level 4: 로봇팔 제어 (Call)
동작 = 이동 + 회전 + 그립 + 용접
동작 = 이동 + 회전 + 그립 + 용접
⚡ Level 5: 모터 신호 (Bit)
신호 = ON/OFF, 속도, 위치, 토크
신호 = ON/OFF, 속도, 위치, 토크
🔌 Level 6: 전기 신호
24V DC, PWM 신호, 엔코더 피드백...
24V DC, PWM 신호, 엔코더 피드백...
💡 핵심 통찰
- 각 레벨은 독립적으로 작동하면서도 상위/하위와 유기적으로 연결
- 어느 레벨에서든 동일한 패턴이 반복 (Work → Call → Arrow)
- 상위 레벨은 하위 레벨의 추상화, 하위는 상위의 구체화
- 무한 확장 가능: 공장 → 공장 그룹 → 글로벌 네트워크...
🤖 생성형 AI 활용의 강력한 기반: 그래프 기반 언어
- 자기 유사성(Self-Similarity): DS 모델링은 모든 계층에서 동일한 Work-Call-Arrow 패턴이 반복되는 프랙탈 구조 — 하위 시스템도 상위 시스템과 동일한 인과 구조로 설계
- 무한 확장 가능: System 안에 System을 포함하는 재귀적 구조로 복잡한 대규모 플랜트도 일관된 방식으로 모델링
- 인과 관계 보존: 계층 간 Arrow 연결이 인과 관계를 명시적으로 표현하여, 어느 수준에서든 원인-결과 추적이 가능
- AI 생성 최적화: 프랙탈 구조 덕분에 LLM이 작은 패턴을 학습하면 전체 시스템 생성이 가능 — 동일 패턴의 재귀적 적용
- System of Systems (SoS): 독립적으로 운영되는 시스템들이 ApiDef/ApiCall로 연결되어 더 큰 시스템을 구성 — 각 시스템은 자율성을 유지하면서 협업
🔷 프랙탈 구조 시각화 - System of Systems
📊 시스템 계층 구조 - 하위에서 상위 호출
Level 1 (상위 시스템)
System A
⚡ Work
🦾 Call → ApiCall
📥 ApiDef
System B
⚡ Work
🦾 Call → ApiCall
📥 ApiDef
ApiCall
Level 2 (중간 시스템)
System C
Work
Call→ApiCall
📥 ApiDef
System D
Work
Call→ApiCall
📥 ApiDef
System E
Work
Call→ApiCall
📥 ApiDef
ApiCall
Level 3 (하위 시스템)
System F
Work
Call→Api
📥 ApiDef
System G
Work
Call→Api
📥 ApiDef
System H
Work
Call→Api
📥 ApiDef
System I
Work
Call→Api
📥 ApiDef
📌 핵심 원리
1. 계층 구조
레벨별로 시스템들이 배치
레벨별로 시스템들이 배치
2. 상향 호출
하위 시스템이 상위 시스템 호출
하위 시스템이 상위 시스템 호출
3. 동일 구조
모든 시스템이 Work→Call→ApiCall
모든 시스템이 Work→Call→ApiCall
4. 프랙탈 반복
각 레벨에서 같은 패턴 반복
각 레벨에서 같은 패턴 반복
🏭 실제 예시
Level 1: MES, ERP
Level 2: 생산라인, 창고관리
Level 3: 로봇, 센서, PLC
하위 시스템들이 필요시
상위 시스템 API를 호출
상위 시스템 API를 호출
Project
System
Work
Call
Api 연결
🔄
동일 패턴 반복
Work → Call → Arrow
🔗
System 간 연결
ApiDef ↔ ApiCall
♾️
무한 중첩 가능
System of Systems
이중성의 핵심 원리
- 동적 역할 전환: 동일한 객체라도 호출 방향, 관찰 관점, 흐름 조건에 따라 다른 역할 수행
- 관계 기반 해석: 객체 자체보다 인과 연결(Arrow)과 주변 관계에 따라 해석
- 계층적 추상화: Bit → Call → Work → System → Project 구조로 확장
- 반복 가능한 흐름 구조: ApiDef → Work → Call → ApiCall → ApiDef → ... 구조가 순환됨
이중성 분류
🏗️ 구조적 이중성 (Cases 1-4)
시스템 구성 요소 간의 설계 및 역할 분리와 관계
| Case | 구성 요소 | 설명 |
|---|---|---|
| 1 | System ⊕ Device | 호출 방향에 따라 능동/수동 역할 |
| 2 | Instance ⊕ Reference | 실행 실체와 참조 대상 구분 |
| 3 | 원인(Bit) ⊕ 결과(Bit) | 흐름 속에서 원인이자 결과 |
| 4 | ReadTag ⊕ WriteTag | 맥락에 따른 읽기/쓰기 해석 |
⚡ 실행적 이중성 (Cases 5-8)
실행 시점에서의 상태 변화, 신호 감지, 인과 흐름의 해석
| Case | 구성 요소 | 설명 |
|---|---|---|
| 5 | WorkBit = R⊕G⊕F⊕H | FSM 기반 상태 흐름 표현 |
| 6 | φ(θ) 위상 표현 | 센서 조합 기반 위치 수치화 |
| 7 | Tag = Semantic ⊕ Binding | 의미 이름과 물리 주소 연결 |
| 8 | Arrow = Start ⊕ Reset | 인과 신호 역할 분리 |
상세 Case 설명
Case 1
System ⊕ Device — 동적 역할 전환
▼
DS 시스템은 특정 상황에 따라 "System" 또는 "Device" 역할을 수행할 수 있으며, 이 두 가지는 배타적이지 않고 동적으로 전환됩니다.
🔹 System (Active System)
- 다른 시스템을 호출하고 실행 흐름을 주도하는 주체
- ApiCall을 사용하여 외부의 ApiDef 호출
- 외부 제어 흐름을 개시하고 요청/응답에 대한 책임
🔹 Device (Passive System)
- 외부로부터 호출되어 동작하는 대상 시스템
- ApiDef를 통해 외부 요청에 반응
- 내부 FSM 흐름을 포함하지만 외부 제어 불가
🔹 동적 역할 전환 예시
[상황 1] A.ApiCall → B.ApiDef → A = System (능동 호출) → B = Device (응답 수신) [상황 2] B.ApiCall → A.ApiDef → B = System (능동 호출) → A = Device (응답 수신)
🔹 실생활 예시: 제조 자동화
- 컨베이어 (A) → 로봇팔 (B): 제품 전달 요청 → A는 System, B는 Device
- 로봇팔 (B) → 컨베이어 (A): 픽업 완료 알림 → B는 System, A는 Device
Case 2
Instance ⊕ Reference — 디지털 트윈 구조
▼
DS 시스템은 실제 물리 시스템과 1:1로 연결되는 디지털 트윈 구조를 갖습니다.
| 항목 | Instance | Reference |
|---|---|---|
| 정의 방식 | new로 생성된 시스템 | 기존 시스템을 참조 |
| 실행 가능성 | ✅ Active 설정 시 실행 가능 | ❌ 항상 Passive (읽기 전용) |
🔹 설계 및 운영 가이드
- 새로운 프로젝트에서는 반드시 시스템을 Instance로 정의
- 동일한 물리 시스템을 참조하고자 할 경우 Reference 구조 사용
- 시스템 정의 변경은 Instance를 통해서만 가능
- 순환 참조 및 동일 시스템의 중복 연결 방지 필요
Case 3
Arrow 인과 연결과 Bit 이중성
▼
DS 시스템에서 실행 흐름을 구성하는 최소 단위는 Bit입니다. Bit는 Arrow를 통한 인과적 연결 속에서 원인이자 결과라는 이중적 특성을 지닙니다.
🔹 인과 연결 구조
A (Bit)
▼
B (Bit)
← 결과이자 원인
▼
C (Bit)
🔹 반복 연결 구조
ApiDef
→
Work
→
Call
→
ApiCall
→
ApiDef
🔄
- Work(Bit): 시스템 루트에서 선언되는 Bit 그룹, 외부 ApiDef에 의해 트리거
- Call(Bit): Work 내부에 존재하는 Bit 그룹, ApiCall을 포함
Case 4
Tag = Write ⊕ Read — 데이터 전달
▼
Tag는 시스템 간 데이터 전달을 위한 핵심 인터페이스로, 1:1 연결(Pair)을 전제로 합니다.
🔹 기본 구조
🔧 Active System
→
Write Tag
물리전송
⟹⟹
Read Tag
→
📡 Passive System
🔹 Shared 구조에서의 이중성
| 조건 | Read/Write 가능 | 설명 |
|---|---|---|
| 기본 구조 | ❌ | Write → Read 1:1 구조 (Pair) |
| Shared Memory | ✅ | 공유 변수처럼 다수 접근 가능 |
| DB 매핑 구조 | ✅ | 간접 경로로 다수 시스템 접근 |
Case 5
WorkBit = R ⊕ G ⊕ F ⊕ H — FSM 상태
▼
Work는 네 가지 상태(R, G, F, H)를 가지며, 이 상태는 단일 비트(WorkBit)와 외부 신호 조건에 따라 전이됩니다.
🔹 상태 정의
- Ready (R): 실행 준비 상태
- Going (G): 작업 실행 중
- Finish (F): 실행 완료됨
- Homing (H): 초기화 진행 중
🔹 상태 전이 다이어그램
🟢 Ready
Start 신호
⟹
🔵 Going
완료
⟹
🟣 Finish
⬆
초기화 완료
Reset 신호
⬇
🔴 Homing
🔹 상태 관리 매트릭스
| 상태 | 진입 조건 | 종료 조건 | 제어 주체 |
|---|---|---|---|
| Ready | Homing 완료 | Start 신호 | 외부 |
| Going | Start 신호 | 내부 작업 완료 | 내부 |
| Finish | Going 완료 | Reset 신호 | 외부 |
| Homing | Reset 신호 | 초기화 완료 | 내부 |
Case 6
φ(θ) = 위상 표현 ⊕ 상태 유추
▼
Work의 센서 입력 및 상태 조건을 기반으로 위상(Phase) 값 φ(θ)를 계산하여 상태를 수치화합니다.
🔹 위상 계산 공식
Binary 기반 (2진법):
φ(θ) = (1/2^n) × Σ(2^(i-1) × Vi × Ci,θ) × 2π
Exponential 기반 (지수 가중치):
φ(θ) = (1/e^n) × Σ(e^(i-1) × Vi × Ci,θ) × 2π
🔹 활용 예시
- 디지털 트윈 상태 정렬: 실제 설비와 시뮬레이션 시스템의 위상 비교로 동기화 판단
- 알람/오류 탐지: φ(θ)의 급변 또는 역진행 발생 시 이상 징후로 판단
Case 7
Tag = SemanticLink ⊕ PhysicalBinding
▼
Tag는 의미론적 연결과 물리적 바인딩의 이중적인 역할을 수행합니다.
🔹 구성 요소
| 구분 | SemanticLink | PhysicalBinding |
|---|---|---|
| 정의 | 동작의 의미를 설명하는 이름 | 실제 하드웨어 주소 연결 |
| 예시 | StartCommand, RobotArmReady | X100, Y102, DB100.DBX0.2 |
| 용도 | 설계자/사용자 간 의미 전달 | I/O 연동, PLC 메모리 맵핑 |
🔹 구조 예시
{
"tagName": "StartSignal",
"semantic": "Start",
"binding": "X100",
"type": "Digital"
}
Semantic 값
Physical 바인딩
데이터 타입
Case 8
Arrow = Start ⊕ Reset — 인과 신호
▼
Arrow는 Work 간의 실행 흐름을 제어하는 신호선이며, Start와 Reset 두 가지 논리적 의미를 동시에 내포합니다.
🔹 신호 생성 조건
| 신호 | 감지 방식 | 감지 대상 | 용도 |
|---|---|---|---|
| Start | 라이징 엣지 | 이전 Work의 Finish | 다음 Work 실행 트리거 |
| Reset | 하이 레벨 | 현재 Work의 Going | 현재 Work 초기화 조건 |
🔹 신호 타이밍 다이어그램
시간
t0
t1
t2
t3
t4
t5
t6
Work A
R
G
G
F
F
F
F
Work B
R
R
R
G
G
F
H
Start 신호
0
0
0
1 ↑
0
0
0
Reset 신호
0
0
0
1
1
0
0
↑ = A의 Finish 라이징
■ = B의 Going 레벨
🔹 실제 적용 예시
컨베이어 완료 (Finish↑)
⟹
로봇팔 시작 (Start 신호)
로봇팔 실행 (Going■)
⟹
초기화 조건 활성 (Reset 신호)
이중성 설계의 효과
🏗️ 설계 측면
- 명확한 구성 요소 정의
- 재사용성 향상
- 설계-실행 간 추상화 경계 확립
⚡ 실행 측면
- 흐름 해석의 명시성
- 자동화 가능성 향상
- 상태 기반 제어 로직 설계 용이
🔗 시스템 통합
- 계층 간 결합도 감소
- 상호 운용성 강화
- 분산 실행과 참조 기반 설계 공존
🎯 이중성 설계 원칙 요약
- Bit는 고정된 구조체가 아니라 흐름의 관찰점
- 모든 구성은 흐름(Arrow) 안에서 원인 ⊕ 결과로 해석됨
- ApiDef의 지시 및 관찰 인터페이스 존재 여부가 해석 기준
- 반복 구조 안에서 구조적, 실행적 이중성이 함께 순환됨