1293.93 이벤트 기반 Tick의 장단점
1. 이벤트 기반 Tick의 장점
1.1 자원 효율성
이벤트 기반 Tick은 외부 이벤트가 발생할 때에만 트리를 순회하므로, 환경에 변화가 없는 유휴 기간 동안 CPU 연산을 소비하지 않는다. 주기적 Tick에서 10 Hz로 실행되는 트리가 실제로 유의미한 상태 변화가 초당 1~2회만 발생하는 경우, 나머지 8~9회의 Tick은 동일한 결과를 반환하는 불필요한 연산이다. 이벤트 기반 모델은 이러한 중복 연산을 제거하여 전력 소비와 열 발생을 줄인다(Colledanchise & Ogren, 2018).
이는 특히 배터리 구동 로봇에서 중요한 이점이다. 감시 모드로 대기하는 로봇이 이상 감지 시에만 행동 트리를 실행하면, 배터리 수명을 유의미하게 연장할 수 있다.
1.2 응답 지연 최소화
주기적 Tick에서 이벤트 응답의 최악 지연(worst-case latency)은 Tick 주기와 동일하다. 10 Hz 주기에서 이벤트가 Tick 직후에 발생하면, 해당 이벤트는 약 100ms 후의 다음 Tick에서야 반영된다. 이벤트 기반 Tick은 이벤트 발생 즉시 Tick을 실행하므로, 이 지연을 이벤트 처리 시간(통상 마이크로초 단위)으로 단축한다.
주기적 Tick (10 Hz):
이벤트 발생 → 최대 100ms 대기 → Tick에서 처리
이벤트 기반 Tick:
이벤트 발생 → ~1ms 이내 → Tick에서 처리
1.3 CPU 부하의 분산
주기적 Tick은 매 주기마다 동일한 연산 부하를 생성하여 CPU 사용의 피크가 주기적으로 발생한다. 이벤트 기반 Tick은 이벤트의 자연적 분포에 따라 부하가 분산되므로, 다른 실시간 태스크와의 CPU 경합을 줄일 수 있다.
1.4 다중 이벤트 소스의 자연스러운 통합
ROS2 환경에서 다양한 토픽, 서비스, 액션의 결과가 비동기적으로 도착한다. 이벤트 기반 모델은 이러한 비동기 이벤트를 자연스럽게 Tick 트리거로 활용할 수 있어, 주기적 폴링(polling)보다 시스템 구조가 직관적이다.
2. 이벤트 기반 Tick의 단점
2.1 RUNNING 노드의 재방문 문제
행동 트리에서 RUNNING 상태의 비동기 액션 노드는 주기적으로 재방문되어야 작업 완료를 확인할 수 있다. 순수 이벤트 기반 모델에서는 명시적인 이벤트 없이는 Tick이 발생하지 않으므로, RUNNING 노드가 무한히 방치될 수 있다.
문제 시나리오:
1. NavigateToGoal 노드가 RUNNING 반환
2. 네비게이션이 완료되었지만 별도의 이벤트가 발생하지 않음
3. Tick이 실행되지 않아 완료가 감지되지 않음
4. 로봇이 목적지에 도착했지만 다음 행동을 개시하지 못함
이 문제를 해결하기 위해서는 RUNNING 노드가 존재하는 동안 보조적인 주기적 Tick을 유지하거나, 비동기 작업의 완료를 이벤트로 전달하는 메커니즘이 필요하다.
2.2 이벤트 소스의 완전성 보장 어려움
트리의 동작에 영향을 미치는 모든 외부 변화가 이벤트로 포착되어야 한다. 이벤트 소스가 누락되면 해당 변화가 트리에 반영되지 않는 상태 누락(missed state change)이 발생한다. 주기적 Tick은 매 주기마다 모든 조건을 재평가하므로 이러한 누락의 위험이 없지만, 이벤트 기반 모델에서는 개발자가 모든 관련 이벤트 소스를 명시적으로 등록해야 한다.
2.3 실행 시간의 비결정성
이벤트의 발생 빈도와 시점이 예측 불가능하므로, Tick의 실행 빈도와 간격이 비결정적이다. 이는 실시간 시스템에서 시간적 보장(temporal guarantee)을 제공하기 어렵게 만든다. 주기적 Tick은 일정한 빈도를 보장하므로, 실시간 분석과 최악 실행 시간(WCET) 계산이 용이하다.
2.4 이벤트 폭주에 의한 과부하
센서 데이터의 고빈도 수신, 네트워크 노이즈, 또는 시스템 오류에 의해 이벤트가 폭주(burst)하면, 매 이벤트마다 Tick이 실행되어 CPU가 과부하 상태에 빠질 수 있다. 주기적 Tick은 최대 실행 빈도가 설정된 주기에 의해 자연스럽게 제한된다.
이벤트 폭주 시나리오:
LiDAR 토픽: 20 Hz 수신
카메라 토픽: 30 Hz 수신
IMU 토픽: 200 Hz 수신
→ 이벤트마다 Tick 시: 최대 250 Hz Tick (과부하)
2.5 디버깅의 복잡성
이벤트 기반 실행은 Tick의 발생 시점과 빈도가 불규칙하므로, 재현 가능한 디버깅이 어렵다. 동일한 이벤트 시퀀스를 재현하기 위해 이벤트 로그의 기록과 재생(replay) 기능이 필요하다.
2.6 구현 복잡도의 증가
이벤트 소스의 등록, 이벤트 큐 관리, 중복 제거, 우선순위 처리, 스레드 안전성 보장 등 주기적 Tick에 비해 구현이 복잡하다. 이벤트 처리 코드의 버그가 트리의 동작 오류를 유발할 수 있으며, 이는 진단이 어렵다.
3. 장단점 종합 비교
| 평가 기준 | 주기적 Tick | 이벤트 기반 Tick | 혼합 모델 |
|---|---|---|---|
| CPU 효율 | 낮음 | 높음 | 중간~높음 |
| 응답 지연 | 최대 1주기 | 최소 | 최소 |
| 결정성 | 높음 | 낮음 | 중간 |
| RUNNING 노드 지원 | 자연스러움 | 별도 처리 필요 | 자연스러움 |
| 상태 누락 위험 | 없음 | 있음 | 없음 |
| 과부하 위험 | 없음 | 있음 | 제한적 |
| 구현 복잡도 | 낮음 | 높음 | 중간 |
| 디버깅 용이성 | 높음 | 낮음 | 중간 |
| 전력 효율 | 낮음 | 높음 | 중간~높음 |
| 실시간 분석 | 용이 | 어려움 | 중간 |
4. 적용 환경별 권장 모델
순수 이벤트 기반 모델은 이벤트의 종류가 한정적이고 RUNNING 노드가 없는 단순한 의사 결정 트리에 적합하다. 복잡한 로봇 시스템에서는 혼합 모델이 가장 실용적인 선택이며, 주기적 Tick으로 안정성과 예측 가능성을 확보하면서 긴급 이벤트에 대한 즉각 응답을 병행하는 것이 권장된다(Faconti, 2022).
참고 문헌
- Colledanchise, M., & Ogren, P. (2018). Behavior Trees in Robotics and AI: An Introduction. CRC Press.
- Faconti, D. (2022). BehaviorTree.CPP documentation and API reference. https://www.behaviortree.dev/