로봇 소프트웨어 프레임워크

• 모든 로봇 프로젝트가 통신·드라이버·도구를 밑바닥부터 만들 수는 없음
• 프레임워크 = 검증된 뼈대와 부품을 제공해 개발자가 로봇 고유의 문제에 집중하게 해 줌
• 시험 핵심 출제 포인트
  • 프레임워크 vs 라이브러리(제어의 역전)
  • 로봇 프레임워크가 제공하는 4대 요소
  • 대표 프레임워크(ROS·OROCOS·OpenRTM)의 특징 매칭
• ROS 1→2 비교와 통신 패턴은 로봇 미들웨어 구조 설계에서 이미 다룸

프레임워크 vs 라이브러리 — 제어의 역전 (시험 단골)

• 라이브러리(Library): 내 코드가 필요할 때 호출하는 기능 묶음 — 주도권이 내 코드에 있다 (예: 행렬 연산 라이브러리)
• 프레임워크(Framework): 전체 구조와 실행 흐름을 프레임워크가 쥐고, 내 코드는 정해진 자리에 끼워져 호출당한다 — 제어의 역전(IoC, Inversion of Control). "Don't call us, we'll call you"(할리우드 원칙)
• 로봇 프레임워크에서: 노드 초기화·통신·스케줄링은 프레임워크가 담당하고, 개발자는 콜백(메시지 수신 시 처리 함수)을 채운다

로봇 프레임워크가 제공하는 4대 요소

1. 통신 기반: 노드 간 메시지 전달 — 토픽(발행–구독)·서비스(요청–응답)·액션(장기 작업) (→ 로봇 미들웨어 구조 설계)
2. 하드웨어 추상화: 센서·구동기의 표준 인터페이스와 드라이버 — 기종이 바뀌어도 상위 코드 유지 (→ 계층화)
3. 패키지 생태계: 기능 단위 패키지 관리 + 커뮤니티의 검증된 구현(내비게이션, SLAM, 모션 계획) 재사용
4. 개발 도구: 시각화, 데이터 기록·재생, 시뮬레이터 연동, 빌드 시스템 (→ 로봇 소프트웨어 개발환경)

대표 로봇 프레임워크 (특징 매칭 단골)

기억 포인트: ROS = 생태계·범용, OROCOS = 실시간 제어, OpenRTM = 컴포넌트 표준(RTC).

프레임워크 사용의 득과 실

장점

• 개발 기간 단축: 통신·도구·검증된 알고리즘 재사용
• 품질: 수많은 사용자가 검증한 코드 기반
• 표준화: 팀·회사 간 코드 호환, 인력 수급 용이
• 모듈화 강제: 노드·컴포넌트 단위 설계를 자연스럽게 유도

단점·유의점

• 오버헤드: 범용 계층의 통신·추상화 비용 — 극한 실시간 루프에는 부적합할 수 있음 (→ 해당 부분만 펌웨어·OROCOS로)
• 학습 곡선: 프레임워크 고유 개념·도구 습득 비용
• 종속성(Lock-in): 프레임워크의 수명·버전 정책에 묶임 — LTS 버전 선택, 인터페이스 계층으로 격리
• 제어의 역전의 대가: 세부 실행 흐름 제어가 어려움

프레임워크 선정 기준

1. 요구 충족: 실시간성(제어 주기), 지원 OS·언어, 통신 품질(QoS)
2. 생태계: 필요한 기능의 검증된 패키지 존재 여부 — 내비게이션·SLAM을 직접 만들 것인가?
3. 라이선스: 상용 제품 탑재 가능 여부 (오픈소스 라이선스 검토)
4. 커뮤니티·지원: 문서, 업데이트 지속성, 사내 경험
5. 이식성·확장성: 타깃 보드 지원, 다중 로봇 확장

프레임워크 위의 아키텍처

• 프레임워크 = 아키텍처 스타일(로봇 소프트웨어 아키텍처 분류)을 구현해 주는 재료
  • 발행–구독 → 토픽 / 클라이언트–서버 → 서비스 / 컴포넌트 조립 → 노드·패키지
• 프레임워크를 정해도 "어떤 노드로 나누고 어떤 토픽으로 이을지"의 설계 책임은 여전히 설계자에게 있음

라이브러리 vs 프레임워크 — 제어의 역전

flowchart LR
    subgraph LIB["라이브러리 사용"]
        MY1["내 코드 (주도권)"] -- 호출 --> L["라이브러리 함수"]
    end
    subgraph FW["프레임워크 사용"]
        F["프레임워크 (주도권)
초기화·통신·스케줄링"] -- 콜백 호출 --> MY2["내 코드
(정해진 자리에 삽입)"]
    end

프레임워크의 4대 제공 요소

flowchart TD
    FW["로봇 프레임워크"] --> C["통신 기반
토픽·서비스·액션"]
    FW --> H["하드웨어 추상화
표준 인터페이스·드라이버"]
    FW --> P["패키지 생태계
검증된 구현 재사용"]
    FW --> T["개발 도구
시각화·기록/재생·시뮬레이터"]

1. 프레임워크와 라이브러리를 구분하는 핵심 개념으로, 실행 흐름의 주도권이 개발자 코드가 아닌 프레임워크에 있는 것을 가리키는 용어는?

① 정보 은닉 ② 제어의 역전(IoC) ③ 다형성 ④ 지연 바인딩

2. 로봇 소프트웨어 프레임워크가 일반적으로 제공하는 요소로 가장 거리가 먼 것은?

① 노드 간 통신 기반(토픽·서비스) ② 하드웨어 추상화 인터페이스 ③ 시각화·데이터 기록 등 개발 도구 ④ 로봇 기구부의 기계 가공 도면

3. 프레임워크와 특징의 연결로 옳지 않은 것은?

① ROS — 방대한 패키지 생태계와 개발 도구 ② OROCOS — 실시간 제어 루프 구성에 특화 ③ OpenRTM — OMG RT-컴포넌트(RTC) 표준 기반 컴포넌트 개발 ④ OROCOS — GUI 화면 디자인 전용 프레임워크

4. 프레임워크 사용의 단점·유의점으로 옳지 않은 것은?

① 범용 통신·추상화 계층의 오버헤드가 있다 ② 프레임워크 고유 개념의 학습 비용이 든다 ③ 프레임워크의 수명·버전 정책에 종속될 수 있다 ④ 검증된 코드를 재사용하므로 개발 기간이 길어진다

5. 상용 서비스 로봇 제품에 오픈소스 프레임워크를 채택할 때의 선정 기준으로 가장 거리가 먼 것은?

① 요구 실시간성과 타깃 OS·언어 지원 ② 필요한 기능의 검증된 패키지 존재 여부 ③ 오픈소스 라이선스의 상용 탑재 허용 여부 ④ 프레임워크 로고의 색상

• 로봇 미들웨어 구조 설계 — 통신 패턴(토픽·서비스·액션)과 ROS 1→2 비교
• 로봇 소프트웨어 아키텍처 분류 — 프레임워크가 구현하는 스타일들
• 로봇 소프트웨어 개발환경 — 프레임워크 생태계의 개발 도구
• 로봇 소프트웨어 운영체제 — 프레임워크가 올라가는 OS
• 미들웨어 프로세스 관리 — 노드(프로세스) 관리의 실제
• _MOC 로봇소프트웨어구조설계