제10부 시뮬레이션

10.1 시뮬레이션 전략 — 무엇을 검증하는가

10.1.1 이 장에서 배우는 것 / 선수 지식

시뮬레이션은 로봇 개발에서 당연한 도구처럼 이야기되지만, 실무에서 가장 자주 잘못 쓰이는 도구이기도 하다. 두 가지 반대 방향의 오용이 있다.

과신 — "시뮬에서 되니까 실기에서도 될 것이다." 그리고 실기에서 처음 문제를 만난다.

과투자 — 사실적인 시뮬을 만드는 데 몇 달을 쓰고, 정작 그것으로 답할 수 있는 질문이 적다는 것을 뒤늦게 안다.

이 장은 그 사이의 균형을 다룬다. 무엇을 검증하려는가에서 출발해 필요한 충실도를 정하고, 시뮬을 개발 흐름의 어디에 놓을지 결정한다.

배우는 것:

• 시뮬이 주는 것 — 안전·속도·반복·비용.
• 검증 가능과 불가능 — 경계를 명확히.
• 충실도 단계 — 기구학부터 사실적 렌더링까지.
• 목적별 충실도 선택 — 얼마나 정교해야 하는가.
• 개발 흐름에서의 위치 — 언제 쓰는가.
• 회귀 시험 — CI에서의 시뮬.
• 무엇을 모델링할 것인가 — 결정 기준.

선수 지식: 8.8.7(Nav2 시뮬 평가), 5.6(SDF·URDF), 5.7(모델 검증), 6.2.8(mock 하드웨어), 4.10(CI).

정직: 이 장은 전략과 판단을 다루며 특정 시뮬레이터에 종속되지 않는다. 구체 도구는 10.2(Gazebo)·10.5(대안)에서 다룬다. 시뮬 성능·정확도 수치는 하드웨어·모델 의존이므로 제시하지 않는다(3.6.1 방침). 이 환경에서 검증하지 않았다(목차 3).(→ 198차 확인: 10.1.7의 "시뮬 테스트는 불안정하기 쉽다" 주장을 TurtleBot3+Gazebo+Nav2로 실제로 재현했다 — 동일 명령을 반복 실행해 부트업 자체가 실패하는 사례(RViz2 크래시로 인한 연쇄 실패)와, 부트업이 성공한 뒤에도 내비게이션 결과가 갈리는 사례(5회 중 1회만 성공)를 둘 다 실측했다. 아래 실행 확인(198차) 참고.)

10.1.2 시뮬이 주는 것

견해: "반복성"이 시뮬의 가장 큰 가치다(8.8.7의 반복). 같은 시나리오를 100번 실행해 성공률을 측정하는 것은 실기로는 며칠이 걸리고, 조건을 동일하게 유지하기도 어렵다. 통계적 비교가 필요한 모든 작업에서 시뮬이 대체 불가능하다.

견해: "모든 상태를 볼 수 있다"도 과소평가된다. 실기에서는 로봇의 실제 위치를 모르지만(그래서 측위를 하는 것이다 — 8.3), 시뮬에서는 안다. 추정 알고리즘의 오차를 직접 측정할 수 있으며, 이것은 실기에서 매우 어렵다.

10.1.3 검증 가능과 불가능

이 표가 이 장의 핵심이다.

핵심 구분: "논리"는 검증되고 "물리"는 근사된다.

견해: 시뮬은 "무엇을 하는가"를 검증하고 "얼마나 잘하는가"는 근사한다. 로봇이 목표에 도달하는 로직이 맞는지는 확실히 알 수 있지만, 실제로 3.2초가 걸릴지 4.1초가 걸릴지는 모른다. 이 구분을 명확히 하면 시뮬 결과를 어디까지 믿을지 정해진다.

특히 위험한 오해:

10.1.4 충실도 단계

시뮬은 하나가 아니다. 목적에 따라 필요한 정교함이 다르다.

단계별 도구:

견해: ①단계가 과소평가된다. RViz2에서 URDF를 표시하고 관절을 움직여 보는 것만으로 도달성·충돌·프레임 문제의 상당수가 검출된다(5.7.7). 물리 시뮬을 켜기 전에 이것부터 하는 것이 빠르고 확실하다.

견해: ④단계는 비용이 매우 높고, 필요한 경우가 제한적이다. 비전 알고리즘을 시뮬 데이터로 학습·검증하려는 것이 아니라면 대개 불필요하다. "예쁜 시뮬"에 시간을 쓰는 것이 대표적 과투자다.

10.1.5 목적별 충실도 선택

"무엇을 검증하려는가"에서 역산한다.

견해: 필요한 최소 충실도를 쓰라. 높은 충실도는 느리고(RTF 저하 — 10.2.8), 만들기 어렵고, 유지보수 부담이 크다. "기구학으로 답할 수 있는 질문을 동역학 시뮬로 답하는 것"은 낭비다.

견해: 여러 충실도를 병행하는 것이 실용적이다. CI에는 ①·② 수준의 빠른 시뮬을, 주간 검증에는 ③을, 특정 연구에만 ④를 쓴다. 하나의 시뮬로 모든 것을 하려 하면 어느 쪽에도 최적이 아니다.

10.1.6 개발 흐름에서의 위치

각 시점의 역할:

견해: "설계 단계의 시뮬"이 가장 비용이 낮고 효과가 크다. 로봇을 사고 설치한 뒤 도달성 문제를 발견하면 비용이 크지만, URDF와 작업점 좌표만으로 미리 확인하면 몇 시간이면 된다(9.6.3).

견해: "문제 재현"은 기대만큼 잘 되지 않는다. 실기 문제의 원인이 대개 시뮬이 모델링하지 않는 것(마찰·노이즈·타이밍)이기 때문이다. 재현되면 좋지만, 안 된다고 시뮬을 정교하게 만드는 데 시간을 쓰기보다 실기에서 계측하는 편이 빠른 경우가 많다.

10.1.7 회귀 시험

시뮬의 가장 지속적인 가치는 CI에서 나온다(4.10.5).

시나리오 정의:

# 개념: 시나리오 명세
scenarios:
  - name: "복도 주행"
    world: worlds/corridor.sdf
    start: {x: 0, y: 0, yaw: 0}
    goals: [{x: 10, y: 0}, {x: 10, y: 5}]
    timeout: 60
    success_criteria:
      goal_reached: true
      max_recoveries: 3
  - name: "장애물 회피"
    world: worlds/obstacles.sdf
    # ...

함정: 시뮬 테스트는 불안정하기 쉽다(4.10.5). 물리 엔진의 미세한 차이, 타이밍, 난수가 결과를 바꾼다. 통과 기준을 통계적으로 설정하고(예: 10회 중 8회 성공), 단일 실행으로 판정하지 않는 것이 좋다.

실행 확인(198차) — 이 함정을 TurtleBot3+Gazebo+Nav2(tb3_simulation_launch.py)로 실제로 재현했다, 그것도 두 층위에서. ① 부트업 자체가 무너지는 사례. 소스(tb3_simulation_launch.py)를 직접 읽어보니 headless:=True는 Gazebo GUI(gzclient)만 끄고, RViz2는 완전히 별도의 use_rviz 인자(기본값 True)로 제어돼 headless와 무관하게 항상 뜨려 한다. 디스플레이 없는 컨테이너에서 headless:=True만 주고 4회 연속 실행하니 4/4 모두 RViz2가 크래시(SIGABRT)했고, 그 직후 매번 nav2_container가 RCLError(맥락이 조금씩 다른 문구)로 종료돼 60초 안에 부트업을 못 마쳤다. use_rviz:=False를 추가하자 5/5 모두 8~11초 만에 깔끔히 성공 — 명확한 A/B 대조로 원인을 좁혔다. ② 부트업이 안정된 뒤에도 결과가 갈리는 사례. use_rviz:=False로 고정한 뒤 동일한 시작 포즈(-2.0,-0.5)·목표(0.0,0.5)로 5회 반복하니 1회만 SUCCEEDED(13.2초, 무복구), 나머지 4회는 전부 ABORTED(1회는 1.6초 만에, 나머지는 즉시) — 로그를 보니 실패한 경우마다 amcl이 "Failed to transform initial pose in time"을 반복해, 5 Hz 반복 발행한 /initialpose의 타이밍이 tf 버퍼 성장과 경쟁하는 것으로 보인다. 정직한 교란 변수: 실패한 두 트라이얼(10건·15건)에는 성공한 트라이얼(0건)에 없던 FastRTPS 공유메모리 포트 에러가 있었다 — 같은 컨테이너를 짧은 간격으로 재기동해 DDS 포트가 완전히 반납되기 전에 다음 시도가 시작됐을 가능성이 있다. 그래서 이번에 관측한 "5회 중 1회 성공"이라는 수치 자체는 일반화하지 않는다 — Nav2+Gazebo의 본질적 신뢰도가 아니라 이 시험 하네스(짧은 재기동 간격)가 만든 교란이 섞여 있을 수 있기 때문이다. 이것이 바로 이 절의 "통과 기준을 통계적으로 설정하라"는 조언, 그리고 단일 실행으로 판정하지 말라는 조언이 필요한 이유를 스스로 증명한 셈이다 — 트라이얼 하나만 봤다면 정반대의 결론을 냈을 것이다. 원본: tools/gap_harness/gap197/sim_flakiness/(run_trial.sh, logs/trial_logs/, findings_summary.txt).

함정: 시뮬 CI가 느리면 아무도 안 본다. 야간 빌드가 4시간 걸리면 결과를 보기까지 하루가 지난다. 시나리오를 병렬화하거나 개수를 줄여 결과가 아침에 나오게 하라.

견해: 회귀 시험의 목적은 "성능 측정"이 아니라 "깨진 것 감지"다. 시뮬 성공률이 실기와 다르다는 것은 이미 안다(10.1.3). 어제 90%였는데 오늘 40%면 무언가 깨진 것이며, 그것을 검출하는 것이 가치다.

10.1.8 무엇을 모델링할 것인가

모든 것을 모델링할 수는 없다. 무엇을 넣고 무엇을 뺄 것인가.

흔한 판단:

견해: "실제 값을 모르는 것을 정교하게 모델링하는 것"이 흔한 낭비다. 바닥 마찰 계수를 소수점 셋째 자리까지 넣어도 실제 값을 모르면 의미가 없다. 모르는 파라미터는 대략적 값으로 두고, 그것이 결과에 미치는 영향을 민감도로 확인하는 편이 낫다(10.6.4).

견해: 시뮬 월드를 단순하게 유지하라. 복잡한 월드는 느리고(RTF — 10.2.8), 만들기 어렵고, 실제 환경과 다르면 어차피 소용없다. 검증에 필요한 구조만 넣는다.

10.1.9 흔한 오용

견해: "실기 회피"가 가장 위험한 오용이다. 시뮬이 편해서 실기 검증을 미루면, 통합 문제가 뒤로 몰려 프로젝트 후반에 드러난다. 초기에 그리고 정기적으로 실기에서 확인하는 것이 리스크를 앞으로 당긴다.

견해: 시뮬과 실물의 동기화가 유지보수 부담이다. 로봇에 센서를 추가하거나 그리퍼를 바꾸면 시뮬도 바꿔야 한다. 단일 xacro로 시뮬·실기를 분기하면(5.6.6) 이 부담이 크게 준다 — 제5부의 단일 출처 원칙이 여기서 값을 한다.

10.1.10 전략 수립 절차

1단계가 핵심이다. 검증하려는 질문을 구체적으로 적는다.

- 로봇이 좁은 통로를 통과할 수 있는가? (① 기구학)
- 코스트맵 설정이 장애물을 제대로 인식하는가? (③ 센서)
- 복구 동작이 갇힘 상황에서 작동하는가? (② 동역학)
- 팔이 모든 작업점에 도달하는가? (① 기구학)
- Nav2 파라미터 변경이 성공률을 떨어뜨렸는가? (② + 반복)

견해: 질문 목록이 없으면 시뮬이 "단순히 로봇이 움직이는 것"이 된다. 무엇을 확인하려는지 모르면 결과를 어떻게 해석할지도 모르고, 어디까지 정교하게 만들지도 정할 수 없다. 7.8.2의 예산표, 6.6.8의 요구 정의와 같은 논리 — 목적을 먼저 적는다.

7단계 비교 검증이 신뢰의 근거다(10.6). 시뮬과 실기에서 같은 시험을 수행하고 결과를 비교해, 어느 지표가 얼마나 일치하는지 안다. 그래야 "이 시뮬은 이 질문에 대해 믿을 만하다"고 말할 수 있다.

10.1.11 함정 카탈로그

10.1.12 체크포인트

• 시뮬이 주는 이득 여덟 가지를 말할 수 있는가. 가장 큰 가치 둘은 무엇이며 왜인가.
• 검증 가능한 것과 불가능한 것을 각각 다섯 가지 들 수 있는가. "논리와 물리"의 구분은 무엇을 의미하는가.
• 특히 위험한 오해 네 가지를 말할 수 있는가.
• 충실도 다섯 단계와 각각이 답할 수 있는 질문을 말할 수 있는가. ①단계가 과소평가되는 이유는?
• 목적별 충실도 선택 흐름을 그릴 수 있는가. "필요한 최소 충실도"를 쓰라는 조언의 근거는?
• 개발 흐름에서 시뮬의 여섯 가지 역할과, 가장 비용이 낮고 효과 큰 시점은?
• "문제 재현"이 기대만큼 잘 안 되는 이유는?
• 회귀 시험의 세 층과 각각의 빈도는? 시뮬 CI의 목적이 "성능 측정"이 아닌 이유는?
• 모델링 범위를 정하는 기준 네 가지와, "모르는 값을 정교하게"가 낭비인 이유는?
• 흔한 오용 일곱 가지 중 가장 위험한 것은 무엇이며 왜인가.
• 전략 수립 절차 여덟 단계에서 1단계와 7단계가 왜 중요한가.

다음 장 10.2은 ROS 2 생태계의 표준 시뮬레이터 — Gazebo Harmonic과 ros_gz를 다룬다. 세대 구분, 브리지 설정, 성능.