← 대표 사례로

CASE STUDY / 04 · REAL-TIME GRAPHICS

Orbital Cells
결정론적 생명주기
크로스플랫폼 렌더링

90분의 궤도 주기를 살아가는 생성형 생명체를, 웹·데스크톱·임베디드 장치처럼 서로 다른 실행 환경에서 같은 시드와 같은 시간에 같은 상태로 재현하도록 설계하고 구현했습니다.

PARK STUDIO LLC2025.10.20 — 2026.02.20TECHNICAL DIRECTOR
지구 궤도에서 Orbital Cells 작품이 탑재 화면에 렌더링된 장면

AT A GLANCE

PROBLEM

시간이 단순한 재생 위치가 아니라 생명체의 상태를 결정하는 작품을 여러 런타임에서 일관되게 재현해야 했습니다.

KEY DECISION

공유하는 것은 렌더링 코드가 아니라 시드·시간·상태 전이·스냅샷이라는 생명주기 모델로 정했습니다.

MY ROLE

시간 모델, p5.js·C++/OpenGL·WebGL·EGL/GLES 구현과 임베디드 실행 환경을 구성했습니다.

OUTCOME

하나의 생명주기 → 4개 환경웹·데스크톱·헤드리스 렌더러·소형 디스플레이 출력

01 CONTEXT & PROBLEMS

하나의 생명주기를
여러 런타임에 재현하기

Orbital Cells는 위성의 탑재 화면에서 살아가는 인공 생명체를 다루는 실시간 생성형 작업입니다. 메타볼 기반 생명체는 태어나고, 자라며, 생식과 재탄생을 거쳐 다음 세대로 이어집니다. 인공위성이 지구를 한 바퀴 도는 90분은 이 생명체에게 하루이자 한 번의 완전한 생애입니다. 지구의 24시간이 아닌 궤도의 시간이 작품의 시간 단위가 됩니다.

한 주기 안에서 생명체는 성장하고, 생의 끝에서 작은 셀을 만들어내며, 그중 하나가 다음 생명체의 계보를 이어갑니다. 이 반복은 단순한 애니메이션 루프가 아니라, 우주적 규모의 연결과 단절, 그리고 불완전함을 넘어 연결되고자 하는 인간의 욕망을 드러내는 작품의 표현 원리입니다.

따라서 기술적으로 필요한 것은 예쁜 움직임을 만드는 일만이 아니었습니다. 위성의 궤도 시간과 생명주기 규칙을 기준으로 특정 시점의 생명체 상태를 다시 구성할 수 있어야 했습니다. 웹 브라우저, 데스크톱, Jetson 장치, 작은 LCD를 가진 Raspberry Pi 장치가 각기 다르게 실행되더라도 시간의 의미와 생명체의 상태는 하나여야 했습니다.

문제는 렌더러 하나를 이식하는 일이 아니라, 주어진 생명주기 규칙을 여러 런타임에서 같은 방식으로 해석하고 재현하는 일이었습니다.

해결할 문제

위성의 90분 궤도 시간에 따라 변화하는 생성형 생명체를, 웹·데스크톱·임베디드·소형 디스플레이 환경에서 같은 시드와 같은 시점에 같은 상태로 재현하려면 어떻게 해야 하는가?

CONSTRAINTS

시간의 기준

특정 시각은 생명체의 생성 순서, 성장 단계, 이동과 형태를 결정합니다.

긴 시간 축

생성 시점부터 매번 전체를 계산하지 않고 제한된 장비에서 현재 상태에 도달해야 했습니다.

다른 실행 환경

그래픽 API, 프레임 루프, 빌드·출력 방식이 다른 런타임을 함께 다뤄야 했습니다.

02 SYSTEM APPROACH

시간 기반 생명주기라는
공통 모델

여러 대상이 공유해야 하는 것은 렌더링 코드가 아니라 생명체가 살아가는 방식입니다. 90분 궤도와 상태 전이 규칙을 바탕으로 작품이 운영될 미래 시간 구간까지 미리 시뮬레이션하고, 그 과정의 중간 상태를 시간별 스냅샷으로 저장했습니다.

현재 시각이 들어오면 생성 시점부터 다시 계산하지 않습니다. 현재 시각보다 앞선 가장 가까운 스냅샷을 찾고, 그 지점부터 현재까지 필요한 시간만 시뮬레이션해 생명체 상태를 복원합니다. 이 방식으로 긴 시간 축의 계산량을 제한하면서도, 같은 시각에서 같은 상태를 재현할 수 있게 했습니다.

COMMON MODEL90분 궤도와 상태 전이탄생 규칙 · 시간별 스냅샷
PRE-SIMULATION미래 시간 구간중간 생명주기 상태 저장
RESTORE현재 생명체 상태가까운 스냅샷부터 필요한 구간만 계산
RUNTIME대상별 렌더링각 환경의 출력 경로

공통 모델은 90분 궤도, 탄생 규칙, 상태 전이, 미리 생성한 시간별 스냅샷으로 이루어집니다. 반면 그래픽 루프, 셰이더와 렌더링 API, 사용자 인터페이스, 프레임 출력 형식, 빌드·배포 방식은 대상별 구현으로 분리했습니다.

DETERMINISTIC LIFECYCLE · SNAPSHOT RESTORE
flowchart TB
Lifecycle["90분 궤도 · 메타볼 탄생 · 상태 전이 규칙"] --> PreSimulation["미래 시간 구간까지 미리 시뮬레이션"]
PreSimulation --> Snapshot["시간별 중간 스냅샷 저장"]
CurrentTime["현재 시각"] --> NearestSnapshot["현재 시각 이전의 가장 가까운 스냅샷 선택"]
Snapshot --> NearestSnapshot
NearestSnapshot --> Recalculate["스냅샷부터 현재까지 필요한 구간만 시뮬레이션"]
Recalculate --> State["현재 생명체 상태"]
State --> P5["p5.js 프로토타입"]
State --> Desktop["C++ / OpenGL 데스크톱 렌더러"]
State --> WebGL["WebGL 웹 뷰어"]
State --> Headless["EGL / GLES 헤드리스 렌더러"]

결정론적 시간 처리와 스냅샷

운영할 미래 시간 구간까지 생명주기를 미리 시뮬레이션하고, 중간 상태를 시간별 스냅샷으로 저장했습니다. 이후 현재 시각이 들어오면 시작 시점부터 전 구간을 되짚지 않고, 현재 시각 이전의 가장 가까운 스냅샷에서 필요한 시간만 진행합니다.

이 방식은 시간이 오래 흐른 뒤에도 계산 범위를 제한하고, 같은 조건에서 같은 결과를 다시 확인할 수 있게 합니다. 스냅샷은 성능 최적화만을 위한 캐시가 아니라 시간 기반 작품을 운영 가능한 형태로 만드는 장치였습니다.

런타임별 렌더링

p5.js

생성 규칙과 시각 언어를 빠르게 검토하는 프로토타입을 만들었습니다.

C++ / OpenGL

데스크톱 환경에서 고정 25fps 기준으로 상태 업데이트와 렌더링을 구현했습니다.

WebGL

날짜와 시간을 선택해 특정 시점의 상태를 확인할 수 있는 웹 뷰어를 구현했습니다.

EGL / GLES

화면이 없는 임베디드 환경에서 렌더링한 프레임을 FBO로 읽어 소형 디스플레이 출력으로 넘겼습니다.

각 구현은 독립적이지만, 시드·시간·생명주기 규칙을 공통 기준으로 삼았습니다. 공유한 것은 하나의 네이티브 렌더링 코어가 아니라 결과를 결정하는 모델과 검증 기준입니다.

03 CONTRIBUTION & OUTCOME

하나의 시간 모델로
여러 환경을 연결

같은 시드와 기준 시각에서 하나의 생명주기 상태가 복원되도록 시간 모델을 공통 기준으로 뒀습니다. 이 기준 위에서 웹·데스크톱·임베디드·소형 디스플레이는 각자의 그래픽·출력·배포 방식으로 구현하되, 환경이 달라도 작품이 가리키는 시간과 상태는 하나로 유지했습니다.

MY CONTRIBUTION

  • 탄생 규칙과 중간 스냅샷을 포함한 생명주기 모델 설계
  • p5.js, C++/OpenGL, WebGL, EGL/GLES 환경 구현
  • 데스크톱·웹·임베디드 대상별 렌더링과 실행 구조 설계
  • Jetson 대상 Docker 기반 빌드·실행 환경 구성과 검증
  • Raspberry Pi 5 기반 소형 디스플레이 실행 환경 구성

OUTCOME

같은 시드, 같은 시간, 같은 생명주기

여러 런타임에서 같은 생명체 상태를 재현할 수 있는 공통 기준을 마련

인공위성 탑재 환경을 고려한 계산 범위 제한

중간 스냅샷으로 시뮬레이션 범위를 줄인 뒤, 90분 궤도 시간을 따르는 생명주기를 인공위성에 탑재해 동작을 완료

웹·데스크톱·임베디드로 확장

하나의 작품 규칙을 웹, 데스크톱, 소형 디스플레이 출력 환경까지 확장

NEXT CASE STUDY

Nachos