🔮 이중성(Duality)의 본질
DS(Dualsoft) 시스템은 복잡한 산업 자동화 환경에서 유연하고 확장 가능한 시스템 설계를 위해
하나의 구성 요소가 맥락에 따라 역할과 의미가 달라지는 설계 구조를 채택합니다.
이를 통해 모듈화 및 재사용성, 시스템 간 연결성, 동적 해석 가능성을 극대화합니다.
🤖 생성형 AI 활용의 강력한 기반: 그래프 기반 언어
DS Language Graph Structure
JSON
1{
2 "system": "SmartFactory",
3 "works": [
4 {
5 "id": "ConveyorSystem",
6 "type": "Transport",
7 "calls": ["StartMotor", "CheckSensor", "StopAtPosition"],
8 "state": { "R": "Ready", "G": "Going", "F": "Finish", "H": "Homing" }
9 },
10 {
11 "id": "RobotArm",
12 "type": "Assembly",
13 "calls": ["MoveToPosition", "GripObject", "PlaceObject"],
14 "apiDef": "AssemblyControl"
15 }
16 ],
17 "arrows": [
18 { "from": "ConveyorSystem.Finish", "to": "RobotArm.Start", "type": "trigger" }
19 ]
20}
- 구조화된 그래프 표현: DS는 Work-Call 그래프 구조로 모든 로직을 표현하여, LLMLarge Language Model - 대규모 언어 모델이 쉽게 파싱하고 생성할 수 있는 명확한 구조 제공
- 명시적 인과 관계: Arrow를 통한 원인-결과 연결이 그래프로 표현되어, AI가 시퀀스 로직을 정확히 이해하고 생성 가능
- 계층적 추상화: Bit → Call → Work → System → Project 구조가 AI의 단계별 코드 생성에 최적화
- 반복 가능한 패턴: ApiDef → Work → Call → ApiCall → ApiDef 순환 구조가 AI 학습과 생성에 일관된 패턴 제공
- JSON 기반 IR: 그래프 구조가 JSON으로 직렬화되어 LLM의 입출력 처리에 최적화
🔷 인과 기반 프랙탈 구조: System of Systems 설계
1
Bit
2
Call
3
Work
4
System
5
Project
- 자기 유사성(Self-Similarity): DS 모델링은 모든 계층에서 동일한 Work-Call-Arrow 패턴이 반복되는 프랙탈 구조 — 하위 시스템도 상위 시스템과 동일한 인과 구조로 설계
- 무한 확장 가능: System 안에 System을 포함하는 재귀적 구조로 복잡한 대규모 플랜트도 일관된 방식으로 모델링
- 인과 관계 보존: 계층 간 Arrow 연결이 인과 관계를 명시적으로 표현하여, 어느 수준에서든 원인-결과 추적이 가능
- AI 생성 최적화: 프랙탈 구조 덕분에 LLM이 작은 패턴을 학습하면 전체 시스템 생성이 가능 — 동일 패턴의 재귀적 적용
- System of Systems (SoS): 독립적으로 운영되는 시스템들이 ApiDef/ApiCall로 연결되어 더 큰 시스템을 구성 — 각 시스템은 자율성을 유지하면서 협업
이중성의 핵심 원리
- 동적 역할 전환: 동일한 객체라도 호출 방향, 관찰 관점, 흐름 조건에 따라 다른 역할 수행
- 관계 기반 해석: 객체 자체보다 인과 연결(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 | 의미 이름과 물리 주소 연결 | I/O 매핑 |
| 8 | Arrow = Start ⊕ Reset | 인과 신호 역할 분리 | 제어 흐름 |
상세 Case 설명
Case 1
System ⊕ Device — 동적 역할 전환
▼
DS 시스템은 특정 상황에 따라 "System" 또는 "Device" 역할을 수행할 수 있으며, 이 두 가지는 배타적이지 않고 동적으로 전환됩니다.
🔹 System (Active System)
- 다른 시스템을 호출하고 실행 흐름을 주도하는 주체
- ApiCall을 사용하여 외부의 ApiDef 호출
- 외부 제어 흐름을 개시하고 요청/응답에 대한 책임
🔹 Device (Passive System)
- 외부로부터 호출되어 동작하는 대상 시스템
- ApiDef를 통해 외부 요청에 반응
- 내부 FSM 흐름을 포함하지만 외부 제어 불가
동적 역할 전환 예시
DS
1// 상황 1: A가 System, B가 Device
2A.ApiCall → B.ApiDef
3 → A = System (능동 호출)
4 → B = Device (응답 수신)
5
6// 상황 2: B가 System, A가 Device
7B.ApiCall → A.ApiDef
8 → B = System (능동 호출)
9 → A = Device (응답 수신)
🔹 실생활 예시: 제조 자동화
- 컨베이어 (A) → 로봇팔 (B): 제품 전달 요청 → A는 System, B는 Device
- 로봇팔 (B) → 컨베이어 (A): 픽업 완료 알림 → B는 System, A는 Device
이중성 설계의 효과
🏗️ 설계 측면
- 명확한 구성 요소 정의
- 재사용성 향상
- 설계-실행 간 추상화 경계 확립
⚡ 실행 측면
- 흐름 해석의 명시성
- 자동화 가능성 향상
- 상태 기반 제어 로직 설계 용이
🔗 시스템 통합
- 계층 간 결합도 감소
- 상호 운용성 강화
- 분산 실행과 참조 기반 설계 공존
🎯 이중성 설계 원칙 요약
- Bit는 고정된 구조체가 아니라 흐름의 관찰점
- 모든 구성은 흐름(Arrow) 안에서 원인 ⊕ 결과로 해석됨
- ApiDef의 지시 및 관찰 인터페이스 존재 여부가 해석 기준
- 반복 구조 안에서 구조적, 실행적 이중성이 함께 순환됨