1261.62 행동 제어 시스템의 모듈화 원칙

1. 모듈화의 개념과 의의

모듈화(modularization)는 복잡한 시스템을 독립적이고 교체 가능한 구성 단위(모듈)로 분해하는 설계 전략이다. 소프트웨어 공학에서 모듈화는 시스템의 복잡도를 관리하고, 유지보수성, 재사용성, 테스트 용이성을 향상시키는 핵심 원칙으로 확립되어 있다(Parnas, 1972).

로봇 행동 제어 시스템에서 모듈화는 다음과 같은 구체적 이점을 제공한다.

1. 독립적 개발: 각 행동 모듈을 별도의 팀 또는 개발자가 병렬적으로 개발할 수 있다.
2. 구성 가능성(Composability): 기본 행동 모듈을 조합하여 새로운 복합 행동을 구성할 수 있다.
3. 테스트 용이성: 각 모듈을 독립적으로 단위 테스트할 수 있으며, 결함의 원인 추적이 용이하다.
4. 교체 가능성(Replaceability): 인터페이스가 동일한 대체 모듈로 교체가 가능하여, 알고리즘 변경이나 하드웨어 교체에 유연하게 대응할 수 있다.
5. 확장성(Scalability): 새로운 행동 모듈의 추가 시 기존 시스템에 대한 변경을 최소화할 수 있다.

2. 모듈화의 기본 원칙

2.1 높은 응집도(High Cohesion)

응집도(cohesion)는 하나의 모듈 내부에서 구성 요소들이 얼마나 밀접하게 관련되어 있는지를 나타내는 척도이다. 높은 응집도를 가진 모듈은 단일 기능이나 밀접하게 관련된 기능만을 수행하며, 모듈의 목적이 명확하다.

행동 제어 모듈에서 높은 응집도를 달성하기 위해서는 다음의 지침을 따른다.

• 하나의 행동 모듈은 하나의 명확한 행동 기능(예: 장애물 회피, 목표 추종, 물체 파지)만을 담당한다.
• 센서 처리, 행동 결정, 명령 생성 등의 이질적 기능을 하나의 모듈에 혼합하지 않는다.
• 모듈의 책임 범위를 문서화하여 기능의 범위를 명시적으로 한정한다.

2.2 낮은 결합도(Low Coupling)

결합도(coupling)는 모듈 간의 상호 의존 정도를 나타내는 척도이다. 낮은 결합도를 가진 시스템에서는 하나의 모듈을 변경하더라도 다른 모듈에 미치는 영향이 최소화된다.

행동 제어 시스템에서 결합도를 낮추기 위한 전략은 다음과 같다.

• 인터페이스 기반 통신: 모듈 간의 직접적인 함수 호출 대신, 정의된 인터페이스(토픽, 서비스, 액션)를 통해 통신한다.
• 데이터 은닉(Data Hiding): 모듈 내부의 상태와 구현 세부사항을 외부에 노출하지 않는다.
• 의존성 주입(Dependency Injection): 모듈이 직접 의존 대상을 생성하지 않고, 외부에서 주입받는 방식을 적용한다.

2.3 정보 은닉 원칙

Parnas(1972)가 제안한 정보 은닉(information hiding) 원칙은 모듈의 설계 결정과 구현 세부사항을 모듈 경계 내에 캡슐화하고, 외부에는 안정적인 인터페이스만을 공개하는 것이다. 이 원칙에 의해 모듈의 내부 알고리즘이 변경되더라도 인터페이스가 유지되는 한 다른 모듈에 영향을 주지 않는다.

행동 제어 모듈에서 정보 은닉의 대상은 다음과 같다.

• 행동 결정 알고리즘의 구현 방식(예: 규칙 기반, 학습 기반)
• 내부 상태 변수의 구조와 갱신 로직
• 사용하는 센서 데이터의 전처리 방식
• 액추에이터 명령의 내부 변환 로직

3. ROS2에서의 모듈화 구현

3.1 노드 기반 모듈화

ROS2에서 가장 기본적인 모듈화 단위는 노드(node)이다. 각 행동 모듈을 독립적인 노드로 구현하면, 프로세스 수준의 격리(isolation)가 보장되며 토픽, 서비스, 액션을 통한 표준화된 인터페이스로 통신한다.

노드 기반 모듈화의 장점은 다음과 같다.

• 프로세스 격리: 하나의 노드에서 발생한 오류(segmentation fault, 무한 루프 등)가 다른 노드에 전파되지 않는다.
• 생명주기 독립성: 각 노드가 독립적으로 시작, 정지, 재시작될 수 있다.
• 분산 배치: 노드를 서로 다른 컴퓨터에 배치하여 계산 부하를 분산할 수 있다.

3.2 컴포넌트 기반 모듈화

ROS2의 컴포넌트(component) 아키텍처는 복수의 노드를 동일 프로세스 내에서 실행하면서도 논리적 모듈화를 유지하는 방식이다. 컴포넌트는 공유 라이브러리(shared library)로 빌드되어 컴포넌트 컨테이너(component container)에 동적으로 로드된다.

컴포넌트 기반 모듈화는 프로세스 간 통신 오버헤드를 제거하면서도 코드 수준의 모듈 분리를 유지할 수 있는 장점이 있다. 특히 프로세스 내 통신(intra-process communication)을 활용하면 제로 복사(zero-copy) 데이터 전달이 가능하여 센서 데이터의 고속 처리에 적합하다.

3.3 패키지 기반 모듈화

ROS2의 패키지(package)는 빌드와 배포의 단위이다. 하나의 행동 모듈 또는 관련된 모듈 그룹을 하나의 패키지로 구성하면, 버전 관리, 의존성 관리, 빌드 구성을 독립적으로 수행할 수 있다.

패키지 설계에서 권장되는 구조는 다음과 같다.

behavior_module_package/
├── CMakeLists.txt
├── package.xml
├── include/
│   └── behavior_module/
│       └── behavior_module.hpp
├── src/
│   └── behavior_module.cpp
├── config/
│   └── params.yaml
├── launch/
│   └── behavior_module.launch.py
└── test/
    └── test_behavior_module.cpp

4. 모듈 간 인터페이스 설계

4.1 인터페이스 계약

모듈 간의 인터페이스는 명시적 계약(contract)으로 정의되어야 한다. 인터페이스 계약에는 다음의 요소가 포함된다.

• 입력 데이터: 모듈이 수신하는 토픽, 서비스 요청, 액션 목표의 메시지 타입과 QoS 프로파일
• 출력 데이터: 모듈이 발행하는 토픽, 서비스 응답, 액션 결과 및 피드백의 메시지 타입과 QoS 프로파일
• 파라미터: 모듈의 동작을 조정하는 설정 파라미터의 이름, 타입, 유효 범위, 기본값
• 전제 조건(Precondition): 모듈이 정상 동작하기 위한 선행 조건
• 사후 조건(Postcondition): 모듈의 실행 완료 후 보장되는 상태

4.2 네이밍 규약

모듈 간 통신에 사용되는 토픽, 서비스, 액션의 이름은 체계적 네이밍 규약(naming convention)에 따라 부여한다. 일관된 네이밍은 시스템의 가독성과 유지보수성을 향상시킨다.

ROS2에서 권장되는 네이밍 패턴은 다음과 같다.

5. 모듈 분해 전략

5.1 기능 기반 분해

기능 기반 분해(functional decomposition)는 시스템의 기능 요구사항에 따라 모듈을 나누는 방식이다. 각 모듈이 하나의 기능적 책임만을 담당하도록 설계한다.

행동 제어 시스템의 기능 기반 분해 예시는 다음과 같다.

• 인식 모듈: 센서 데이터 처리 및 환경 인식
• 계획 모듈: 경로 계획 및 행동 계획
• 실행 모듈: 제어 명령 생성 및 액추에이터 구동
• 감시 모듈: 시스템 상태 모니터링 및 이상 탐지

5.2 계층 기반 분해

계층 기반 분해(layered decomposition)는 시스템을 수직적 계층으로 나누어, 각 계층이 하위 계층의 서비스를 사용하고 상위 계층에 서비스를 제공하는 구조를 형성한다. 3계층 아키텍처(반응 계층, 실행 계층, 계획 계층)가 대표적 사례이다.

5.3 행동 기반 분해

행동 기반 분해(behavior-based decomposition)는 로봇의 각 행동을 독립적 모듈로 구현하는 방식이다. 각 행동 모듈은 완전한 감지-결정-실행 루프를 자체적으로 포함하며, 행동 간의 조율은 상위 수준의 중재기(arbiter)가 담당한다(Brooks, 1986).

6. 모듈화 품질 평가 지표

모듈화의 품질을 정량적으로 평가하기 위한 지표는 다음과 같다.

7. 참고 문헌

• Brooks, R. A. (1986). “A Robust Layered Control System for a Mobile Robot.” IEEE Journal on Robotics and Automation, 2(1), 14–23.
• Parnas, D. L. (1972). “On the Criteria to Be Used in Decomposing Systems into Modules.” Communications of the ACM, 15(12), 1053–1058.