로봇 소프트웨어 아키텍처 분류

• 소프트웨어 아키텍처에는 오랜 세월 검증된 정형화된 구조 패턴(아키텍처 스타일) 들이 존재
• 스타일을 알면 → 밑그림을 빠르게 그리고 장단점을 예측 가능
• 이 노트 = 일반 아키텍처 스타일 + 로봇에서의 활용
  • 로봇 고유의 제어 구조 3대 패러다임(숙고·반응·혼합)은 로봇 소프트웨어 구조 설계 참조
• 시험 핵심 출제 포인트: 스타일별 특징·장단점 매칭 + 로봇 적용 예(발행-구독=토픽, 블랙보드=세계 모델)

아키텍처 스타일이란

• 모듈을 어떻게 나누고 잇는가에 대한 재사용 가능한 구조의 틀
• 스타일은 상호 배타가 아님 → 실제 시스템은 여러 스타일의 혼합(계층 + 발행-구독 + 클라이언트-서버)으로 구성

주요 스타일 6종 (시험 단골)

① 계층형 (Layered)

• 기능을 수직 계층으로 쌓고 위층은 아래층의 인터페이스만 사용
• 장점: 관심사 분리, 하위 교체 용이(이식성) / 단점: 계층 통과 오버헤드
• 로봇: HW–드라이버–미들웨어–기능–응용의 기본 골격 (→ 로봇 소프트웨어 구조 설계)

② 클라이언트–서버 (Client–Server)

• 서비스를 제공하는 서버와 요청–응답으로 이용하는 클라이언트
• 장점: 중앙 관리, 명확한 역할 분담 / 단점: 서버가 병목·단일 실패점 가능
• 로봇: 관제 서버–로봇, 미들웨어의 서비스 호출 (→ 서버 프로그램, 클라이언트 프로그램)

③ 파이프–필터 (Pipe–Filter)

• 데이터가 필터(처리 단계) 들을 순서대로 통과하며 변환되는 일방향 흐름
• 장점: 필터 교체·재조합 용이, 단계별 병렬화 / 단점: 상호작용적(대화형) 처리에 부적합
• 로봇: 센서 처리 파이프라인 (원시 데이터 → 필터링 → 특징 추출 → 인식)

④ 이벤트 기반 / 발행–구독 (Event-driven / Publish–Subscribe)

• 발신자는 이벤트(메시지)를 던질 뿐, 누가 받는지 모른다 — 수신자는 관심 주제를 구독
• 장점: 낮은 결합도(발행자·구독자 상호 무지), 유연한 추가·제거, 1:N 배포 / 단점: 흐름 추적·디버깅 어려움, 전달 보장 관리 필요
• 로봇: 미들웨어 토픽 통신이 그 자체 — 센서 데이터 배포의 표준 (→ 로봇 미들웨어 구조 설계)

⑤ 데이터 중심 / 블랙보드 (Blackboard / Repository)

• 모든 모듈이 공유 데이터 저장소(칠판) 를 읽고 쓰며 협력 — 지식원들이 칠판에 부분해를 적어 가며 문제를 푼다
• 장점: 다수 모듈의 데이터 공유 자연스러움, 모듈 간 직접 결합 없음 / 단점: 저장소가 병목·경쟁 지점, 일관성 관리 필요
• 로봇: 세계 모델(World Model) — 지도·물체·로봇 상태를 여러 인지·계획 모듈이 공유

⑥ MVC (Model–View–Controller)

• 모델(데이터·논리) / 뷰(표시) / 컨트롤러(입력 처리)의 3분할 — UI 소프트웨어의 표준
• 로봇: 관제·모니터링 GUI, 티치 펜던트 UI (→ 로봇 모니터링 프로그램)

컴포넌트 기반과 서비스 지향

• 컴포넌트 기반(CBD): 표준 인터페이스를 가진 부품(컴포넌트)의 조립으로 시스템 구성 — 로봇 미들웨어(노드 조립)의 사상적 기반. 재사용이 핵심 가치 (→ 모듈화 프로그래밍)
• 서비스 지향(SOA)·마이크로서비스: 독립 배포 가능한 서비스들의 네트워크 협력 — 클라우드 로봇 관제(다수 로봇 + 서버 서비스군)에 적용

스타일 선택의 감각 (혼합이 정상)

• 전형적인 자율주행 로봇 = 다섯 스타일의 공존
  • 계층형 골격 위에 노드들이 발행–구독으로 데이터를 흘림
  • 설정 조회 = 클라이언트–서버
  • 지도·상태 = 블랙보드식 공유
  • 관제 GUI = MVC

스타일 4종의 데이터 흐름 비교

flowchart TD
    subgraph PF["파이프–필터"]
        F1["필터1"] --> F2["필터2"] --> F3["필터3"]
    end
    subgraph PS["발행–구독"]
        PUB["발행자"] -- 토픽 --> B1["구독자A"] & B2["구독자B"]
    end
    subgraph CS["클라이언트–서버"]
        CL["클라이언트"] -- 요청 --> SV["서버"] -- 응답 --> CL
    end
    subgraph BB["블랙보드"]
        M1["인지"] <--> BD["공유 저장소
(세계 모델)"] <--> M2["계획"]
    end

로봇 시스템에서의 스타일 공존

flowchart LR
    S["센서 노드"] -- "발행–구독(토픽)" --> P["인지 노드"] --> W["세계 모델
(블랙보드)"] --> PL["계획 노드"]
    UI["관제 GUI (MVC)"] -- "클라이언트–서버(질의)" --> PL
    L["계층형 골격: HW → 드라이버 → 미들웨어 → 기능 → 응용"] -.기반.- S & P & PL

1. 센서 원시 데이터가 "필터링 → 특징 추출 → 물체 인식"의 단계를 순서대로 통과하며 변환되는 구조에 해당하는 아키텍처 스타일은?

① 클라이언트–서버 ② 파이프–필터 ③ 블랙보드 ④ MVC

2. 발행–구독(Publish–Subscribe) 스타일에 대한 설명으로 옳지 않은 것은?

① 발행자는 구독자가 누구인지 알 필요가 없다 ② 구독자의 추가·제거가 발행자에 영향을 주지 않는다 ③ 하나의 메시지를 여러 수신자에게 배포하기 좋다 ④ 모듈 간 결합도가 매우 높아지는 것이 단점이다

3. 지도·물체·로봇 상태 같은 정보를 공유 저장소(세계 모델)에 두고 여러 인지·계획 모듈이 읽고 쓰며 협력하는 구조는?

① 계층형 ② 파이프–필터 ③ 블랙보드 ④ 클라이언트–서버

4. 아키텍처 스타일과 로봇 적용 예의 연결로 옳지 않은 것은?

① 발행–구독 — 미들웨어 토픽 기반 센서 데이터 배포 ② 클라이언트–서버 — 관제 서버와 로봇의 요청–응답 ③ MVC — 모니터링 GUI의 구성 ④ 파이프–필터 — 위층이 아래층 인터페이스만 사용하는 수직 구조

5. 아키텍처 스타일 활용에 대한 설명으로 가장 적절한 것은?

① 하나의 시스템에는 반드시 하나의 스타일만 적용해야 한다 ② 스타일은 요구 상황별로 조합해 쓰며, 실제 로봇 시스템은 여러 스타일의 혼합이다 ③ 스타일을 정하면 모듈 내부 알고리즘도 자동으로 정해진다 ④ 스타일 선택은 소프트웨어 품질과 무관하다

• 로봇 소프트웨어 구조 설계 — 로봇 제어 구조 3대 패러다임(숙고·반응·혼합)
• 로봇 미들웨어 구조 설계 — 발행–구독의 실체(토픽·서비스·액션)
• 로봇 소프트웨어 프레임워크 — 스타일을 구현해 주는 프레임워크
• 로봇 소프트웨어 아키텍처 모델링 — 스타일 선택이 반영되는 모델링
• 모듈화 프로그래밍 — 컴포넌트 기반의 토대
• _MOC 로봇소프트웨어구조설계