임베디드와 Physical AI로 확장되는 설계

design-beyond-apps|앱 너머의 설계에서 한 단계 더 나아가, 소프트웨어가 물리적 세계와 만나는 경우. how-to-design-a-program-from-scratch|6단계 프로세스의 뼈대는 유지되지만, "시간 제약, 자원 제약, 물리적 안전"이라는 세 축이 모든 단계에 추가된다.

근본적 차이

소프트웨어: "틀리면 다시 돌리면 된다." 임베디드/Physical AI: "틀리면 물리적 결과가 생긴다." 이 한 줄이 모든 차이의 근원이다.

추가되는 세 축

1) 시간 제약

웹 앱의 200ms 지연은 불편함. Physical AI의 100ms 지연은 사고. 이건 성능 최적화가 아니라 정확성의 문제다.

2) 자원 제약

서버의 RAM 32GB vs 임베디드의 RAM 256KB. "float 대신 int를 써야 메모리가 맞는가?" 수준의 제약이다.

3) 물리적 안전

실패 시 물리적 피해 가능성. 안전 계층이 다른 모든 계층을 관통하고 항상 최우선이다.

6단계의 변형

요구사항 — 기능 + 물리적 제약 + 안전이 동시에

┌──────────────┬──────────────────┬───────────────┐
│   기능       │   물리적 제약     │   안전 요구    │
├──────────────┼──────────────────┼───────────────┤
│ • 자율 이동  │ 배터리: 2시간    │ 충돌 시 즉시   │
│ • 장애물 회피│ 무게: 5kg 이하   │  정지          │
│ • 물건 배달  │ CPU: Cortex-A72  │ 최대 속도 1m/s │
│             │ 응답: 100ms 이내  │               │
└──────────────┴──────────────────┴───────────────┘

도메인 모델 — 물리 세계가 모델에 들어온다

소프트웨어의 논리적 개념(Course, Lecture) 대신, 물리적+논리적 개념(Robot, Motor, Sensor, Map, Obstacle)을 모델링한다. 물리 법칙이 제약으로 작용한다.

네 계층으로 분해된다:

물리 계층: Motor, Sensor, Battery
인지 계층: Map, Obstacle, Localization
결정 계층: Path Planner, Task Manager
안전 계층: Emergency Stop, Health Monitor (항상 최우선)

아키텍처 — 시간 제약에 따른 분리

실시간 계층에서는 동적 메모리 할당, 네트워크 호출, 디스크 I/O를 하지 않는다.

컴포넌트 분해 — 하드웨어 경계가 추가

"어떤 하드웨어에서 돌아가는가"가 분해 기준에 추가된다:

MCU (STM32): 모터 제어, 센서 드라이버, 안전 감시
엣지 (Jetson): 인지, 경로 계획, 작업 관리
클라우드: 지도 업데이트, 로그, 모델 재학습

통신이 HTTP가 아니라 UART, SPI, CAN 같은 하드웨어 프로토콜이다.

데이터 설계 — 스트림 처리

DB에 저장하고 읽는 정적 방식이 아니라, 센서에서 끊임없이 흘러오는 데이터를 처리하는 스트림 방식. architecture-patterns-overview|Pipe & Filter가 자연스럽게 쓰인다.

검증 — 시뮬레이션 → 실물 단계적 진행

① 시뮬레이션 (Gazebo, Isaac Sim)
② 실험실 (안전한 환경에서 실물)
③ 제한된 환경 (빈 복도, 낮은 속도)
④ 실제 환경 (사람 있는 공간)

각 단계를 통과해야 다음으로 넘어간다. 시뮬레이션에서 되더라도 실물에서 안 될 수 있다 (sim-to-real gap).

서비스까지 확장하면

"배달 로봇 서비스"처럼 확장하면 세 종류의 설계가 동시에 필요하다:

| 영역 | 설계 방식 | 핵심 관심사 | |---|---|---| | 로봇 관제 | 소프트웨어 (앱) | 확장성, API, UI | | 개별 로봇 | Physical AI | 실시간, 안전, 자원 제약 | | 인프라 | 소프트웨어 (서버) | 데이터 파이프라인, ML Ops |

전체 비교

| | 소프트웨어 | 임베디드 | Physical AI | |---|---|---|---| | 실패 결과 | 데이터 손실 | 기기 고장 | 물리적 피해 | | 시간 제약 | 느려도 됨 | ms 필수 | ms 필수 | | 자원 | 넉넉 | 극도로 제한 | 제한적 | | 검증 | 테스트 | HW+SW | 시뮬→실물 | | 안전 | 낮음 | 중간 | 최우선 |

소프트웨어 설계가 "뭘 만들고 어떻게 나누는가"의 문제라면, Physical AI 설계는 거기에 **"물리 세계와 어떻게 안전하게 상호작용하는가"**가 더해진다.