1315.8 타입 설계의 모범 사례

1. 타입 설계의 기본 원칙

PDDL 도메인의 타입 설계는 도메인의 구조적 명확성, 플래닝 효율성, 유지 보수성에 직접적 영향을 미친다. 다음의 모범 사례를 따르면 체계적이고 효율적인 타입 시스템을 구축할 수 있다.

2. 사례 1: 도메인 개념에 충실한 타입 분류

타입은 도메인의 실제 개념적 분류를 충실히 반영해야 한다. 인위적이거나 기술적 편의를 위한 타입 분류는 도메인의 가독성을 저하시킨다:

;; 권장: 도메인 개념에 충실
(:types
    robot waypoint cargo charging_station - object
    ground_robot aerial_robot - robot
    package fragile_package - cargo
)

;; 비권장: 기술적 편의에 의한 인위적 분류
(:types
    movable_thing stationary_thing - object
    ;; "movable_thing"은 로봇과 물체를 혼합한 인위적 범주
)

3. 사례 2: 적절한 세분화 수준

타입의 세분화 수준은 액션에서의 실제 구분 필요성에 의해 결정되어야 한다:

;; ��절한 세분화: 액션에서 구분이 필요한 수준
(:types
    robot - object
    ground_robot aerial_robot - robot
)
;; ground_robot만 drive 가능, aerial_robot만 fly 가능

;; 과도한 세분화: 액션에서 구분 불필요
(:types
    robot - object
    ground_robot aerial_robot - robot
    wheeled_robot tracked_robot bipedal_robot - ground_robot
)
;; 세 하위 타입이 모든 액션에서 동일하게 취급되면 불필요한 분류

판단 기준: 두 타입이 모든 술어와 액션에서 동일하게 취급되면, 이를 합치는 것이 바람직하다.

4. 사례 3: 적절한 계층 깊이 유지

;; 권장: 2-3 수준 계층
(:types
    entity - object
    robot obstacle - entity
    mobile_robot stationary_robot - robot
)

;; 비권장: 과도한 깊이
(:types
    thing - object
    animate_thing - thing
    autonomous_thing - animate_thing
    robot - autonomous_thing
    mobile_robot - robot
    wheeled_mobile_robot - mobile_robot
    ;; 6 수준: 대부분 불필요한 중간 ���층
)

5. 사례 4: 상위 타입을 활용한 공통 액션 정의

(:types
    robot - object
    scout_robot transport_robot repair_robot - robot
)

;; 공통 액션: 상위 타입 사용
(:action move :parameters (?r - robot ?from ?to - waypoint) ...)
(:action communicate :parameters (?r - robot ?msg - message) ...)
(:action charge :parameters (?r - robot ?station - charging_station) ...)

;; 특화 액션: 하위 타입 사용
(:action scan_area :parameters (?r - scout_robot ?area - zone) ...)
(:action load_cargo :parameters (?r - transport_robot ?c - cargo) ...)
(:action repair_equipment :parameters (?r - repair_robot ?eq - equipment) ...)

6. 사례 5: 일관된 명명 규칙

타입 이름은 도메인 내에서 일관된 명명 규칙을 따라야 한다:

혼용을 피하고, 도메인 전체에서 동일한 규칙을 적용한다.

7. 사례 6: 향후 확장을 고려한 설계

초기 도메인이 단순하더라도, 향후 확장이 예상되면 중간 계층을 미리 설계한다:

;; 초기 도메인: 로봇 1종류
;; 향후 확장 고려 시:
(:types
    robot - object           ;; 중간 계층 유지
    mobile_robot - robot     ;; 현재 유일한 로봇 유형
)
;; 나중에 aerial_robot, underwater_robot 추가 용이

;; 향후 확장 미고려 시:
(:types mobile_robot - object)
;; 나중에 robot 상위 타입 추가 시 모든 술어/액션 수정 필요

8. 사례 7: 타입과 술어의 역할 구분

타입으로 표현할 수 있는 것과 술어로 표현해야 하는 것을 명확히 구분한다:

;; 타입으로 표현: 객체의 본질적, 불변적 범주
(:types
    ground_robot aerial_robot - robot  ;; 로봇의 본질적 유형 (변하지 않음)
)

;; 술어로 표현: 객체의 가변적 상태, 관계
(:predicates
    (robot_active ?r - robot)          ;; 상태 (변할 수 있음)
    (equipped_with ?r - robot ?t - tool)  ;; 관계 (변할 수 있음)
)

핵심 기준: 도메인 실행 중 변할 수 있는 속성은 술어로, 변하지 않는 구조적 범주는 타입으로 표현한다.

9. 사례 8: PlanSys2 호환 타입 설계

PlanSys2 환경에서 사용할 타입은 다음의 추가 제약을 고려한다:

1. 타입 이름에 소문자와 밑줄만 사용한다
2. PlanSys2의 Domain Expert가 타입 계층을 올바르게 파싱할 수 있도록 표준 PDDL 구문을 준수한다
3. 타입 이름이 ROS2의 명명 규칙과 호환되도록 한다

10. 안티패턴: 피해야 할 타입 설계

1. 모든 것을 하나의 타입으로: 단일 object 타입만 사용하여 타입 시스템의 이점을 포기하는 설계
2. 타입의 과잉 세분화: 액션에서 구분이 필요 없는 객체를 불필요하게 세분화
3. 타입과 상태의 혼동: 가변적 속성을 타입으로 표현 (예: charged_robot, empty_robot)
4. 순환 참조: 타입 계층에 순환이 발생하는 선언
5. 일관성 없는 명명: 같은 도메인에서 GroundRobot, aerial_robot, underwater-robot 등 혼용

11. 참고 문헌

• Haslum, P., Lipovetzky, N., Magazzeni, D., & Muise, C. (2019). An Introduction to the Planning Domain Definition Language. Morgan & Claypool Publishers.
• Ghallab, M., Nau, D., & Traverso, P. (2004). Automated Planning: Theory and Practice. Morgan Kaufmann.
• Helmert, M. (2009). “Concise Finite-Domain Representations for PDDL Planning Tasks.” Artificial Intelligence, 173(5–6), 503–535.