로보틱스 제어에서 SKIX Harness 구조의 타당성
SKIX가 최종적으로 이동·청정·관찰·화면·음성과 같은 물리 기능을 목표 중심으로 조합하려면 LLM과 기기 함수 사이에 실행 구조가 필요하다. 이 구조를 AI Harness라고 부를 수 있지만, 로보틱스에서는 더 정확히 고수준 목표를 안전한 Action lifecycle과 controller로 연결하는 실행 기반으로 보는 편이 맞다.
결론
현재 SKIX의 Planner → typed plan → TaskManager → DeviceAgent → evidence 방향은
로보틱스 제어에 합리적이다. 단, 다음 경계를 지킬 때만 그렇다.
- LLM은 목표, 도구 선택, 단계와 조건을 제안한다.
- TaskManager는 action의 수명, 순서, 자원, 취소와 timeout을 관리한다.
- DeviceAgent와 domain controller가 실제 동작과 물리 안전을 소유한다.
- 센서와 executor가 feedback과 terminal result를 제공한다.
- 정상 feedback은 로컬에서 처리하고 의미가 바뀐 경우만 LLM에 돌려보낸다.
LLM이 모터·회전·속도·tilt를 매 tick 직접 결정하거나 자연어 결과를 HAL에 바로 전달한다면 현재 구조는 합리적이지 않다.
왜 로봇은 단순 함수 호출로 부족한가
물리 동작은 API가 반환됐다고 끝나지 않는다.
| 특성 | 단순 RPC의 한계 | 필요한 구조 |
|---|---|---|
| 긴 실행 시간 | 호출 수락과 실제 도착이 다름 | Goal·Feedback·Result |
| 취소와 선점 | 실행 중 사용자·안전 이벤트가 발생 | Cancel·Preempt·Safe stop |
| 상태 변화 | 배터리, 장애물, 위치, 사람이 계속 변함 | Fresh observation과 state machine |
| 자원 충돌 | 이동, 청정, 화면, 음성이 동시에 경쟁 | Queue와 resource policy |
| 부분 실패 | 경로 실패 뒤 다른 수단이나 질문이 필요 | Recovery와 bounded replan |
| 물리 불확실성 | 같은 명령도 환경에 따라 결과가 달라짐 | Terminal evidence와 timeout |
| 다중 호출자 | PUI, 앱, IoT, 예약, Agent가 함께 요청 | Admission, priority, correlation |
ROS 2 Action도 장시간 동작을 Goal, 중간 Feedback, 최종 Result와 Cancel이 있는 비동기 실행으로 정의한다. Nav2는 경로 계산, 경로 추종, progress·goal checker와 recovery를 Behavior Tree에서 조합한다. 이는 특정 AI 유행과 무관하게 로봇 실행이 원래 필요로 하는 구조다.
AI Harness와 Robotics Runtime의 차이
| 구분 | AI Harness | Robotics Runtime |
|---|---|---|
| 주 관심사 | context, tool, prompt, model output, eval | goal lifecycle, controller, state, safety, feedback |
| 실패 | 형식 오류, 잘못된 도구, 추론 누락 | 충돌 위험, 미도착, sensor stale, actuator 실패 |
| 완료 | 답변 또는 artifact 생성 | 물리 predicate와 terminal result 충족 |
| 시간 | turn과 model call 중심 | 서로 다른 주기의 controller와 장기 action |
| rollback | prompt·model·workflow 복원 | 이미 발생한 물리 side effect는 보상·safe stop 필요 |
SKIX에는 둘 다 필요하지만 하나로 합치면 안 된다. Cloud A2A는 AI Harness이고, TaskManager·DeviceAgent·domain controller는 Robotics Runtime에 가깝다. 양쪽은 typed action contract와 evidence로 연결한다.
시간 주기 분리
아래 주기는 개념적 구분이며 실제 제품 주파수 사양을 뜻하지 않는다.
| 제어 층 | 대표 주기 | 담당 | LLM 사용 |
|---|---|---|---|
| 하드웨어 보호·servo | 매우 짧은 주기 | MCU, motor·safety controller | 금지 |
| 이동·청정 domain control | 짧고 반복적인 주기 | DeviceAgent domain, vendor controller | 금지 |
| Action lifecycle | event·초 단위 | TaskManager, executor, state/evidence adapter | 정상 진행에서는 사용하지 않음 |
| Mission·Plan | 요청·상태 변화 단위 | Planner, 제한된 Supervisor | 필요할 때 사용 |
| Experience | 장시간 목표·사용자 결과 단위 | Goal state와 bounded replan | admission된 경우만 사용 |
모델이 빨라져도 servo와 safety loop를 LLM으로 올릴 이유는 없다. 모델 향상은 Mission·Plan 층의 일반화, tool 선택과 실패 해석을 개선하지만 하위 controller의 결정성과 deadline을 대체하지 않는다.
ROS 2·Nav2와의 대응
SKIX가 ROS 2를 구현하거나 그대로 복제한다는 뜻은 아니다. 검증된 책임 분리 원리를 제품 구조에 대응하면 다음과 같다.
| ROS 2·Nav2 개념 | SKIX 대응 | 공통 의미 |
|---|---|---|
| Action Goal | Task 또는 workflow step | 달성해야 할 구조화된 결과 |
| Action Server | DeviceAgent domain executor | Goal 수락·실행·종료 책임 |
| Action Client | TaskManager·상위 호출자 | 요청, progress 관찰, cancel |
| Feedback | task event·device state | 실행 중 상태와 진행 |
| Result | terminal evidence·reason | succeeded, failed, canceled |
| Goal state machine | Task lifecycle | accepted·running·terminal 전이 |
| Behavior Tree | typed workflow·recovery policy | 여러 action의 순서·분기·복구 |
| Planner plugin | A2A Planner·domain planner | 목표에 맞는 실행 방법 선택 |
| Controller plugin | 이동·청정 controller | 실제 물리 제어와 local feedback |
차이도 분명하다. SKIX는 Android/AOSP Product Framework와 기존 DeviceAgent API, 앱·IoT·PUI 호환을 전제로 하며 현재 범위는 단일 제품 내부 실행이다. ROS graph, DDS와 Fleet middleware를 도입했다는 의미가 아니다.
SKIX Action 계약
로보틱스 제어로 확장하려면 각 capability가 최소한 다음 계약을 가져야 한다.
Action Definition
identity
task_id · workflow_id · step_id · correlation_id
goal
capability · operation · target · constraints
admission
caller · permission · current state · resource policy
execution
executor · timeout · cancel · compensation
feedback
progress · state · source · observed_at · freshness
result
terminal status · reason · output · physical evidence
Planner는 goal과 단계 의존관계를 만들 수 있다. 그러나 admission, 현재 자원,
실행 성공과 physical evidence를 임의로 만들어서는 안 된다.
모델이 좋아질수록 달라지는 부분
| 향상되는 모델 능력 | 줄일 수 있는 것 | 남아야 하는 것 |
|---|---|---|
| 자연어 목표 이해 | 발화별 intent rule | Goal schema와 권한 |
| 도구 선택 | 고정 capability 분기 | Capability allowlist와 실제 availability |
| 계획 수립 | 과도한 plan template | Step·dependency·condition contract |
| 오류 해석 | failure 문자열별 분기 | 구조화된 reason과 원본 evidence |
| 장기 추론 | 매 단계 고정 decomposition | Task state와 bounded replan budget |
| 시각·센서 이해 | 일부 수작업 의미 매핑 | sensor source·freshness·confidence와 controller |
강한 모델은 상위 계획을 더 자유롭게 만들 수 있다. 그 자유를 안전하게 허용하려면 하위 capability와 evidence 계약은 오히려 더 명확해야 한다.
합리적인 폐루프
사용자·시스템 Goal
-> Planner가 catalog에서 capability 선택
-> typed Action Graph 생성
-> TaskManager admission과 resource 판정
-> DeviceAgent domain executor 실행
-> local controller가 물리 동작 수행
-> feedback·state·terminal evidence 반환
-> 정상: 다음 step을 로컬 진행
-> 실행 실패: local recovery 또는 safe stop
-> 의미 변경: 제한된 replan 또는 사용자 확인
이 구조에서 LLM은 폐루프의 모든 반복을 수행하지 않는다. 폐루프 전체를 이해할 수는 있지만, 의미 판단이 필요한 느린 외곽 loop만 담당한다.
불합리한 구조
- 자연어를 검증 없이 DeviceAgent method로 변환한다.
- LLM이 actuator parameter와 control tick을 직접 생성한다.
- feedback event마다 Cloud 모델을 호출한다.
- 모델 응답을 terminal evidence로 사용한다.
- safety policy를 prompt 문장에만 둔다.
- Graph node가 실행 owner, timeout, cancel과 result를 갖지 않는다.
- 통신 단절 시 local safe state로 수렴할 방법이 없다.
- 모델 rollback이 이미 진행 중인 물리 task를 임의로 종료한다.
현재 SKIX의 강점
- Planner와 실제 기기 실행 계층이 분리되어 있다.
- TaskManager가 queue, workflow, timeout, cancel과 event를 담을 위치를 가진다.
- DeviceAgent가 기존 기능과 기기 정책의 사실 소유자다.
- callback과 terminal evidence를 Cloud 판단에 다시 연결할 구조가 있다.
- 단순 명령은 기존 경로를 유지하고 복합 목표만 typed workflow로 올릴 수 있다.
현재 보강해야 할 공백
| 우선순위 | 공백 | 필요한 보강 |
|---|---|---|
| P0 | capability별 완료 기준 편차 | Goal·Feedback·Result·Cancel 계약표 |
| P0 | ACK와 물리 완료 혼재 | terminal evidence와 freshness 강제 |
| P0 | PUI·앱 취소의 task 반영 편차 | 모든 취소 경로를 동일 lifecycle로 연결 |
| P1 | resource·policy coverage 편차 | 이동·청정·화면·세션 arbitration 명시 |
| P1 | 통신·provider 장애 경계 | local continue·safe stop·deferred report 정책 |
| P1 | recovery와 replan 혼재 | local recovery와 semantic replan 분리 |
| P2 | capability catalog와 executor 불일치 | 자동 conformance와 실기기 closure matrix |
| P2 | 장기 Experience 실증 부족 | 제한 시나리오의 반복 E2E와 사용자 통제 검증 |
Robotics 승격 Gate
다음 조건을 통과해야 단순 기기 workflow를 넘어 Robotics-ready capability로 본다.
- Goal이 구조화되고 실제 executor가 존재한다.
- 실행 중 feedback과 현재 상태를 얻을 수 있다.
- cancel 또는 safe stop 경로가 있다.
- 성공·실패·취소 terminal result가 구분된다.
- 물리 완료 evidence가 최신 source와 함께 제공된다.
- timeout과 통신 단절 시 local policy가 있다.
- 동시 action의 자원 충돌 정책이 있다.
- Planner 장애 시에도 안전하게 마감할 수 있다.
- 잘못된 계획이 admission에서 차단된다.
- 실기기 반복 시험으로 lifecycle이 검증된다.
하나의 데모 성공은 이 Gate의 대체 증거가 아니다.
최종 판단
SKIX가 취하고 있는 harness형 구조는 로보틱스 제어를 위해 우회적으로 추가한 장치가 아니다. Goal을 장시간 물리 Action으로 실행하려면 원래 필요한 책임을 Android·DeviceAgent 환경에 배치한 것이다.
다만 성공 조건은 Harness의 크기가 아니다.
LLM은 더 자유롭게 계획하되, 로봇은 더 엄격한 Action 계약과 local controller로 실행한다.
모델이 향상될수록 semantic cue와 고정 plan 보정은 줄이고, Action lifecycle, state freshness, safety, terminal evidence와 local recovery를 강화하는 방향이 로보틱스 진화에 가장 합리적이다.
내부 연결 문서
- 모델 진화 시대의 SKIX Agent Engineering 전략
- Harness 구성요소 원장과 감축 관리
- 모델 교체 Ablation과 승격 플레이북
- TaskManager 기준 사양서
- Capability Composition Catalog
- DeviceAgent Executor Closure Matrix
외부 근거
- ROS 2 Action Design: Goal, Feedback, Result, Cancel과 goal state machine의 설계 근거.
- ROS 2 Actions: 장시간 동작, feedback과 cancel·preempt를 가진 action 개념.
- ROS 2 Topics vs Services vs Actions: 이동과 장기 상태 동작에 Action을 사용하는 기준.
- Nav2 Behavior Tree Walkthrough: path planning, following, progress checker와 contextual recovery의 조합.
- Anthropic, How Claude Performs on Robotics Tasks: 범용 모델의 직접 저수준 제어보다 pretrained policy와 고수준 도구를 사용·감독하는 구조의 효과.