로봇 소프트웨어 아키텍처 검증

• 아키텍처 결함은 코드 결함과 급이 다름 — 구조를 잘못 잡으면 시스템 전체를 뜯어고쳐야 함
• 그래서 코드를 쓰기 전에, 설계 자체를 검증한다
• 시험 핵심 출제 포인트:
  • 결함 수정 비용의 법칙(늦을수록 폭증)
  • 검토 3형제(동료 검토·워크스루·인스펙션)의 격식 순서
  • 시나리오 기반 아키텍처 평가(ATAM)
  • 프로토타이핑의 목적

왜 설계 단계에서 검증하는가 (시험 단골)

• 결함은 늦게 발견될수록 수정 비용이 기하급수적으로 증가 — 요구 단계의 결함을 운영 단계에서 발견하면 수십~수백 배의 비용(Boehm의 법칙으로 알려진 경험칙)
• 아키텍처는 모든 코드가 올라타는 토대 → 설계 결함 하나가 전체 재작업을 부름
• 실행할 코드가 없어도 검증할 방법이 있다는 것이 이 노트의 주제

무엇을 검증하나

• 요구 충족성: 아키텍처 드라이버(품질 속성 시나리오)를 이 구조가 달성할 수 있는가
• 일관성: 뷰·다이어그램 간 모순이 없는가 (모델 도구의 일관성 검사 → 로봇 소프트웨어 설계 도구)
• 완전성: 모든 요구가 어떤 설계 요소에 배정되었는가 — 추적표로 확인
• 실현 가능성: 이 구조를 주어진 기술·자원·일정으로 만들 수 있는가

정적 검증 — 검토(Review) 3형제 (격식 순서 단골)

실행 없이 사람이 산출물을 읽고 결함을 찾는 방법. 격식(공식성)이 낮은 것부터:

1. 동료 검토(Peer Review): 동료 1~2명이 비공식적으로 훑어봄 — 가볍고 빠름
2. 워크스루(Walkthrough): 작성자가 주도하여 산출물을 설명하며 회의 참가자들이 의견 제시 — 교육 효과 겸함, 준비 부담 중간
3. 인스펙션(Inspection): 가장 공식적. 훈련된 중재자(moderator)가 주도하고, 역할(중재자·낭독자·기록자·검토자)을 나누며, 체크리스트 기반으로 결함을 찾고, 결함의 수정·재확인까지 추적 — 결함 검출률이 가장 높다

구분 포인트: 주도자 — 워크스루는 작성자, 인스펙션은 중재자. 격식 — 동료 검토 < 워크스루 < 인스펙션.

시나리오 기반 아키텍처 평가 — ATAM

ATAM(Architecture Tradeoff Analysis Method): 품질 속성 시나리오를 이용해 아키텍처를 평가하는 대표 방법(SEI 개발).

• 이해관계자들이 품질 속성 시나리오를 도출·우선순위화 ("LiDAR 노드가 죽어도 2초 내 안전 정지")
• 아키텍처가 각 시나리오를 어떻게 처리하는지 분석하여 위험(risk), 민감점(sensitivity point — 한 품질에 크게 영향 주는 결정), 절충점(tradeoff point — 한 품질을 올리면 다른 품질이 내려가는 결정) 을 식별
• 핵심 사상: 아키텍처는 절대 평가가 아니라 품질 속성 간 트레이드오프의 평가다 (전신인 SAAM은 시나리오 기반 평가의 초기 방법)

동적·실험적 검증

• 프로토타이핑: 위험이 큰 부분만 미리 최소한으로 구현해 실현 가능성·성능을 실측 — "이 미들웨어로 1 kHz 제어가 되는가"를 종이가 아닌 실험으로 답한다. 확인 후 버리는 것(throwaway)이 원칙
• 시뮬레이션: 모델을 실행해 동작·성능을 관찰 (→ 로봇 소프트웨어 개발환경)
• 성능 예측·예산 분석: 제어 주기·통신 대역폭·메모리의 예산(budget) 을 각 모듈에 배분하고 합계가 한도를 넘지 않는지 계산 — 통합 후 놀라지 않기 위한 산수 (→ 로봇 시스템 최적화)
• 정형 검증(Formal Verification): 상태 기계 모델의 성질("비상정지 상태에는 어떤 상태에서도 도달 가능", "교착 없음")을 수학적·자동적으로 전수 검사(모델 체킹) — 안전 필수 부분에 적용 (→ 교착상태)

검증 결과의 처리

• 발견된 문제는 결함 목록으로 등록 → 아키텍처 수정 → 재검토
• 검증을 통과한 아키텍처는 기준선(baseline) 으로 확정하고 형상 관리 → 이후 변경은 변경 통제 절차
• 코드 단계의 시험(로봇 시스템 평가절차)과 짝을 이루는 설계 단계의 품질 활동

결함 발견 시점과 수정 비용

flowchart LR
    R["요구 단계
비용 1"] --> D["설계 단계
비용 ×수 배"] --> C["구현 단계
비용 ×수십 배"] --> O["운영 단계
비용 ×수백 배"]

검토 3형제의 격식 스펙트럼

flowchart LR
    P["동료 검토
비공식·신속"] --> W["워크스루
작성자 주도 회의"] --> I["인스펙션
중재자 주도·역할·체크리스트
검출률 최고"]

1. 소프트웨어 결함의 수정 비용에 대한 설명으로 옳은 것은?

① 발견 시점과 무관하게 일정하다 ② 운영 단계에서 발견할수록 저렴하다 ③ 늦게 발견될수록 기하급수적으로 증가하므로 설계 단계 검증이 경제적이다 ④ 설계 결함은 코드에서 자동으로 보정된다

2. 작성자가 회의를 주도하며 산출물을 설명하고 참가자들의 의견을 받는 검토 기법은?

① 인스펙션 ② 워크스루 ③ 감사(Audit) ④ 회귀 시험

3. ATAM에 대한 설명으로 옳지 않은 것은?

① 품질 속성 시나리오를 이용해 아키텍처를 평가한다 ② 위험, 민감점, 절충점을 식별한다 ③ 한 품질을 올리면 다른 품질이 내려가는 결정을 절충점이라 한다 ④ 소스 코드의 구문 오류를 컴파일러로 찾는 방법이다

4. "선정한 미들웨어로 1 kHz 제어 주기가 실제로 달성 가능한가"라는 위험을 설계 단계에서 해소하는 가장 적절한 방법은?

① 해당 부분만 최소 구현하는 프로토타이핑으로 실측한다 ② 전체 시스템을 완성한 뒤 확인한다 ③ 카탈로그 사양만 믿고 진행한다 ④ 코드 리뷰 회의를 연다

5. 상태 기계 모델에 대해 "어떤 상태에서도 비상정지 상태에 도달 가능하다", "교착상태가 없다" 같은 성질을 수학적으로 전수 검사하는 기법은?

① 동료 검토 ② 정형 검증(모델 체킹) ③ 부하 시험 ④ 프로파일링

• 로봇 소프트웨어 아키텍처 오류분석 — 발견된 오류의 분석 기법
• 로봇 소프트웨어 아키텍처 모델링 — 검증 대상인 모델과 드라이버
• 로봇 소프트웨어 설계 도구 — 일관성 검사·시뮬레이션 도구
• 로봇 시스템 평가절차 — 구현 이후 단계의 시험 프로세스
• 미들웨어 프로세스 관리 — 교착상태 등 검증 대상 성질
• _MOC 로봇소프트웨어구조설계