제10부 시뮬레이션
10.6 Sim2Real 간극과 검증
10.6.1 이 장에서 배우는 것 / 선수 지식
"시뮬에서는 되는데 실기에서 안 된다." 이 문장이 제10부 전체의 이유이자 이 장의 주제다.
10.1.3에서 검증 가능·불가능의 경계를 그었고, 10.3.7에서 센서의 비현실성을 나열했고, 10.4.5에서 무엇이 이전되지 않는지 봤다. 이 장은 그것들을 체계로 묶고, 간극을 줄이는 방법과 시뮬 결과를 어디까지 믿을지 판단하는 방법을 다룬다.
핵심 관점 하나를 먼저 세운다. 간극을 없애는 것이 목표가 아니다. 없앨 수 없고, 시도하면 비용이 발산한다. 목표는 간극의 크기와 방향을 알고, 그것을 고려해 판단하는 것이다.
배우는 것:
- 간극의 원천 — 체계적 분류.
- 식별 방법 — 어디가 얼마나 다른가.
- 줄이는 방법 — 시스템 식별·랜덤화·노이즈.
- 검증 방법론 — 시뮬과 실기를 비교하는 절차.
- 신뢰 구축 — 단계적 검증.
- 실기 데이터 활용 — bag 재생의 위치.
- "시뮬에서 됐다"의 함정 — 오판을 피하는 법.
선수 지식: 제10부 전체(10.1~10.5), 8.8.7(Nav2 시뮬 평가), 7.6.7(오도메트리 검증), 9.6.4(캘리브레이션), 11.3(기록 — 함께 읽으면 좋다).
정직: 이 장은 방법론이며 특정 수치를 제시하지 않는다. 간극의 크기는 로봇·환경·시뮬 설정에 따라 자릿수가 다르므로, 측정 방법을 가르치는 것이 이 책의 방침이다(BK-03·3.6.1). 이 환경에서 검증하지 않았다(목차 3).
10.6.2 간극의 원천
10.6.2.1 ① 동역학 간극
| 요소 | 실제 | 시뮬 |
|---|---|---|
| 질량·관성 | 실측 어려움 | URDF 값(5.3.5) |
| 마찰 | 비선형·상태 의존 | 단순 모델 |
| 백래시·유격 | 있음 | 없음 |
| 탄성·진동 | 있음 | 대개 강체 |
| 액추에이터 특성 | 비선형·포화 | 이상적(10.4.4) |
| 부하 변동 | 있음 | 모델링한 것만 |
10.6.2.2 ② 센서 간극
10.3.7의 목록이 여기 해당한다. 유리·검은 물체·햇빛·반사·운동 왜곡·오염.
10.6.2.3 ③ 타이밍 간극
| 요소 | 실제 | 시뮬 |
|---|---|---|
| 제어 주기 지터 | 있음(2.5) | 규칙적 |
| 통신 지연 | 있음(6.7) | 거의 없음 |
| 센서 지연 | 수~수십 ms(7.7.8) | 모델링 안 됨 |
| 계산 시간 | 하드웨어 의존 | 다름 |
| RTF ≠ 1 | — | 시간 흐름 자체가 다름(10.2.8) |
10.6.2.4 ④ 환경 간극
모델링하지 않은 모든 것 — 케이블, 문턱, 경사, 조명 변화, 사람, 먼지, 바닥 재질 변화.
10.6.2.5 ⑤ 실행 환경 간극
| 요소 | 설명 |
|---|---|
| 통신(무선·DDS) | 3.9의 문제가 시뮬에 없음 |
| 계산 자원 | 개발 PC vs 임베디드 |
| 실시간성 | 6.6의 제약 |
| 하드웨어 고장 | 없음 |
견해: ⑤가 가장 자주 간과된다. 시뮬은 개발 PC에서 실행되지만 실기는 임베디드 보드에서 실행된다. 계산이 느려 주기를 못 지키거나(6.6.6), 무선에서 통신이 끊기는(3.9.3) 문제는 시뮬에서 절대 나타나지 않는다.
견해: 간극의 원천을 알면 "무엇을 실기에서 반드시 확인해야 하는가"가 정해진다. ①~⑤ 각각에 대해 "우리 시스템에서 이것이 문제가 되는가"를 답하고, 되는 것은 실기 검증 항목에 넣는다.
10.6.3 간극 식별
"어디가 얼마나 다른가"를 측정한다.
비교할 지표:
| 영역 | 지표 |
|---|---|
| 동역학 | 같은 명령에 대한 실제 속도·가속·정착 시간 |
| 오도메트리 | 직진·회전·폐루프 오차(7.6.7) |
| 센서 | 같은 장면의 스캔·이미지 통계 |
| 제어 | 궤적 추종 오차(6.5.5) |
| 항법 | 성공률·소요 시간·복구 횟수(8.8.5) |
| 조작 | 파지 성공률·사이클 타임(9.5.8) |
| 타이밍 | 주기 분포·지연(2.5.6·7.7.8) |
구체적 시험 예:
| 시험 | 확인 |
|---|---|
| 정지 → 1 m/s 가속 | 도달 시간·오버슈트 |
| 제자리 360도 회전 | 소요 시간·최종 오차 |
| 정지 상태 스캔 | 노이즈 분포·유효 점 비율 |
| 직선 3 m 주행 | 오도메트리 오차·경로 편차 |
| 정해진 관절 궤적 | 추종 오차 프로파일 |
견해: "같은 시험을 양쪽에서 수행하는 절차"를 만들어 두라. 스크립트로 자동화하면 시뮬을 고칠 때마다 간극이 줄었는지 확인할 수 있고, 실기 하드웨어가 바뀌었을 때도 재측정이 쉽다. 7.6.7의 검증 시험을 시뮬·실기 공통으로 쓰는 것이 자연스럽다.
견해: 간극을 표로 기록하라. "회전 소요 시간: 시뮬 2.1초, 실기 2.6초(+24%)"처럼 적어 두면, 시뮬 결과를 해석할 때 보정할 수 있고 개선 우선순위도 보인다.
10.6.4 간극 줄이기
세 가지 접근이 있다.
10.6.4.1 ① 시스템 식별 — 시뮬을 실제에 맞춘다
측정으로 시뮬 파라미터를 정한다.
| 파라미터 | 측정 방법 |
|---|---|
| 질량·관성 | 저울·CAD·진자 시험(5.3.5) |
| 마찰 | 정지 마찰·구름 저항 측정 |
| 액추에이터 응답 | 스텝 응답 측정 |
| 센서 노이즈 | 정지 상태 통계(7.1.7) |
| 지연 | 명령→반응 시간(7.7.8) |
견해: 시스템 식별은 효과가 확실하지만 비용이 크다. 모든 파라미터를 맞출 수는 없으므로, 검증 목적에 영향이 큰 것부터 한다. 항법 검증이라면 마찰·오도메트리 스케일이, 제어 검증이라면 관성·액추에이터 응답이 중요하다.
함정: 과적합에 주의하라. 특정 시나리오에 맞춰 파라미터를 조정하면 다른 시나리오에서 더 악화될 수 있다. 여러 시험으로 검증해야 한다.
10.6.4.2 ② 도메인 랜덤화 — 시뮬을 다양하게
파라미터를 매 실행마다 무작위로 바꿔, 알고리즘이 특정 값에 의존하지 않게 한다.
| 랜덤화 대상 | 예 |
|---|---|
| 물리 | 마찰·질량·관성 ±20% |
| 센서 노이즈 | 노이즈 크기·바이어스 |
| 지연 | 통신·처리 지연 |
| 환경 | 조명·재질·배치 |
| 초기 조건 | 시작 자세·위치 |
견해: "파라미터를 정확히 맞추는 것"과 "파라미터에 둔감하게 만드는 것"은 다른 전략이다. 정확한 값을 모르거나 변동이 크면 후자가 낫다. 바닥 마찰처럼 실제로도 변하는 것은 랜덤화가 적합하다.
견해: 랜덤화는 학습 기반 방법에서 특히 강력하지만, 전통적 알고리즘 검증에도 유용하다. "마찰이 ±30% 변해도 항법이 성공하는가"는 의미 있는 강건성 시험이다.
10.6.4.3 ③ 보수적 시뮬 — 실제보다 가혹하게
10.3.4에서 언급한 전략이다.
| 방법 | 효과 |
|---|---|
| 노이즈를 실제보다 크게 | 여유 확보 |
| 지연을 실제보다 길게 | 타이밍 여유 |
| 성능을 실제보다 낮게 | 보수적 판단 |
견해: "시뮬에서 겨우 되는 것"보다 "시뮬에서 여유 있게 되는 것"을 목표로 하라. 시뮬이 실제보다 관대하면(대개 그렇다) 겨우 되는 것은 실기에서 실패한다. 보수적 시뮬은 그 관대함을 상쇄한다.
10.6.5 검증 방법론
"이 시뮬을 어디까지 믿을 수 있는가"를 답하는 절차다.
질문별 신뢰도 표를 만든다:
| 검증 질문 | 관련 간극 | 신뢰도 | 근거 |
|---|---|---|---|
| 좁은 통로 통과 가능? | 기하만 | 높음 | 기구학은 정확 |
| 코스트맵이 장애물 인식하나? | 센서② | 중간 | 노이즈 차이 |
| 제어 게인이 최적? | 동역학① | 낮음 | 실기 재튜닝 필요 |
| 복구 로직이 동작? | 없음(로직) | 높음 | — |
| 사이클 타임 3초? | ①③⑤ | 낮음 | 근사만 |
| 무선에서 동작? | ⑤ | 없음 | 시뮬에 없음 |
견해: 이 표가 시뮬 활용의 핵심 산출물이다. "시뮬 결과를 믿을지 말지"를 매번 추측으로 판단하는 대신, 질문 유형별로 미리 정해 두면 팀 전체가 일관되게 해석한다.
견해: 신뢰도 "없음"인 항목을 명시하는 것이 중요하다. 그것들은 반드시 실기에서 확인해야 하는 목록이 되며, 계획에 반영되어야 한다.
10.6.6 실기 데이터 활용
시뮬의 한계를 우회하는 강력한 방법이다(10.3.7).
| 검증 | 시뮬 | bag 재생 |
|---|---|---|
| 센서 현실성 | ❌ 근사 | ✅ 실제 |
| 폐루프 제어 | ✅ | ❌ 개방 루프(8.8.6) |
| 새 시나리오 | ✅ 생성 가능 | ❌ 기록된 것만 |
| 반복성 | ✅ | ✅ |
분업이 명확하다:
| 목적 | 도구 |
|---|---|
| 인지·측위·SLAM 알고리즘 | bag 재생(실제 센서) |
| 제어·항법 로직·회피 | 시뮬(폐루프 필요) |
| 통합 흐름 | 시뮬 |
| 회귀 검증 | 둘 다 |
견해: "인지는 bag, 제어는 시뮬"이 좋은 기본 분업이다(10.3.7의 반복). 인지 알고리즘은 로봇이 움직이지 않아도 검증되고, 실제 센서 데이터가 훨씬 현실적이다. 반면 회피·제어는 로봇이 반응해야 하므로 폐루프가 필요하다.
견해: 실기 bag을 자산으로 관리하라. 다양한 조건(조명·환경·상황)의 bag을 모아 두면 회귀 시험 데이터셋이 된다. 알고리즘을 고칠 때마다 전체에 실행해 성능 변화를 본다 — 이것이 인지 개발의 표준 관행이다(11.3).
하이브리드 접근:
| 방법 | 설명 |
|---|---|
| 실기 센서 + 시뮬 물리 | 하드웨어 인 더 루프(10.1.4의 ⑤) |
| 시뮬 로봇 + 실기 컨트롤러 | 타이밍 검증 |
| 실기 노이즈 통계를 시뮬에 주입 | 10.6.4의 ① |
10.6.7 "시뮬에서 됐다"의 함정
흔한 오판과 그 교정이다.
| 오판 | 교정 |
|---|---|
| "시뮬에서 100% 성공" | 시뮬 조건이 관대함 — 보수적 시뮬(10.6.4) |
| "시뮬 게인이 최적" | 동역학이 다름 — 실기 재튜닝(10.4.5) |
| "시뮬에서 안 부딪혔으니 안전" | 센서·물리 근사 — 안전은 별개(8.7.7) |
| "시뮬 사이클 타임 = 실기" | 타이밍 간극③ |
| "시뮬에서 되니 통합 끝" | ⑤ 실행 환경 미검증 |
| "실기 실패는 시뮬을 정교화하면 해결" | 대개 아님 — 실기 계측이 빠름 |
견해: 마지막 항목이 흔한 함정이다. 실기에서 문제가 생기면 "시뮬을 더 정교하게 만들어 재현하자"는 유혹이 있는데, 원인이 시뮬이 모델링하지 않는 것이면 정교화해도 재현되지 않는다. 시간을 쓰기 전에 실기에서 직접 계측하는 것이 대개 빠르다(10.1.6).
건강한 태도:
| 태도 | 설명 |
|---|---|
| 시뮬은 필터 | "여기서 실패하면 실기에서도 실패한다" |
| 시뮬은 증명이 아님 | "여기서 성공해도 실기는 별개" |
| 간극을 안다 | 어디가 얼마나 다른지 |
| 실기 검증을 계획에 | 미루지 않음 |
견해: "시뮬은 실패를 걸러내는 필터"라는 관점이 정확하다. 시뮬에서 실패하면 확실히 문제가 있고, 성공하면 "적어도 이 층위에서는 문제없다"는 것이다. 증명이 아니라 필터로 이해하면 과신을 피할 수 있다.
10.6.8 단계적 신뢰 구축
시뮬에서 실기로 가는 안전한 순서다(9.1.9·9.6.9의 확장).
| 단계 | 확인 | 실패 시 |
|---|---|---|
| 1 mock | 배선·로직(6.2.8) | 코드 |
| 2 시뮬 | 동작 흐름·충돌 | 설정·로직 |
| 3 실기 정지 | 센서·tf·규약(7.1.9) | 하드웨어·설정 |
| 4 실기 저속 | 실제 동작 | 튜닝 |
| 5 정상속도 | 성능 | 튜닝 |
| 6 반복 | 성공률(9.6.9) | 견고성 |
| 7 예외 | 복구(8.8.8) | 로직 |
견해: 3단계(실기 정지 검증)를 빠뜨리지 말라. 로봇을 움직이기 전에 센서·tf·규약을 확인하면(7.1.9) 대부분의 통합 문제가 안전하게 드러난다. 시뮬에서 바로 실기 주행으로 넘어가는 것이 사고의 흔한 경로다.
견해: 각 단계에서 "시뮬과 다른 점"을 기록하라. 그것이 10.6.3의 간극 표를 채우고, 다음 프로젝트에서 시뮬 신뢰도를 판단하는 근거가 된다.
10.6.9 제10부를 마치며
시뮬레이션에 대한 이 부의 결론을 정리한다.
제10부가 반복한 것은 셋이다.
- 목적에서 역산하라. 검증하려는 질문이 필요한 충실도를 정하고, 그것이 도구와 모델링 범위를 정한다. 질문 없이 시작하면 과투자하거나 부족하다(10.1.5·10.1.10).
- 경계를 알라. 시뮬은 논리를 검증하고 물리를 근사한다. 무엇이 검증되고 무엇이 안 되는지 명시하지 않으면, 시뮬 결과를 잘못 해석한다(10.1.3·10.3.7·10.4.5).
- 간극을 없애려 하지 말고 측정하라. 간극은 없앨 수 없다. 크기와 방향을 알면 시뮬 결과를 보정해 해석할 수 있고, 그것이 실용적 목표다(10.6.3·10.6.5).
그리고 단일 출처 원칙이 여기서도 관통한다 — 하나의 URDF·xacro에서 mock·sim·real이 나오게 하면(5.6.6·10.4.3), 시뮬과 실기가 어긋나는 가장 흔한 원인이 구조적으로 제거된다.
10.6.10 함정 카탈로그
| # | 함정 | 증상 | 대처 |
|---|---|---|---|
| 1 | 간극을 모른 채 시뮬 신뢰 | 실기에서 실패 | 신뢰도 표(10.6.5) |
| 2 | 간극을 없애려 함 | 비용 발산 | 측정·보정 |
| 3 | 실행 환경 간극⑤ 간과 | 임베디드·무선에서 실패 | 실기 조기 확인 |
| 4 | 시뮬 게인을 실기에 | 낮은 성능 | 재튜닝 전제 |
| 5 | 시뮬 성공률을 실기 예측으로 | 오판 | 보수적 시뮬 |
| 6 | 시스템 식별 과적합 | 다른 시나리오 악화 | 여러 시험 검증 |
| 7 | 실기 문제를 시뮬 정교화로 | 재현 안 됨·시간 낭비 | 실기 계측 |
| 8 | 인지를 시뮬 센서로만 검증 | 실기 실패 | bag 재생 병행 |
| 9 | 제어를 bag으로 검증 시도 | 개방 루프 한계 | 시뮬 사용 |
| 10 | 실기 정지 검증 생략 | 사고 위험 | 3단계 필수 |
| 11 | 간극 기록 없음 | 지식 축적 안 됨 | 표로 기록 |
| 12 | 시뮬을 증명으로 오해 | 과신 | 필터로 이해 |
10.6.11 체크포인트
- 간극의 다섯 원천을 말하고 각각의 예를 들 수 있는가. 가장 자주 간과되는 것은?
- 간극을 식별하는 절차와 비교할 지표 일곱 가지를 말할 수 있는가.
- 간극 표를 기록하는 것의 이점 둘은?
- 간극을 줄이는 세 접근과 각각이 적합한 상황을 말할 수 있는가.
- 시스템 식별과 도메인 랜덤화가 서로 다른 전략인 이유는? 바닥 마찰에는 어느 쪽이 적합한가.
- "보수적 시뮬"이 유용한 이유와, "시뮬에서 겨우 되는 것"을 경계하는 근거는?
- 질문별 신뢰도 표를 만드는 절차와, 그것이 팀에 주는 가치는?
- 신뢰도 "없음" 항목을 명시하는 것이 왜 중요한가.
- 시뮬과 bag 재생의 분업 원칙은? 각각 무엇에 강한가.
- 실기 bag을 자산으로 관리하라는 조언의 근거는?
- "시뮬에서 됐다"의 함정 여섯 가지 중, 시간 낭비로 이어지는 것은?
- "시뮬은 증명이 아니라 필터"라는 관점을 설명할 수 있는가.
- 단계적 신뢰 구축 여덟 단계에서 빠뜨리면 안 되는 단계와 그 이유는?
- 제10부가 반복한 세 원칙을 말할 수 있는가.
여기까지가 제10부 시뮬레이션이다. 전략(10.1), Gazebo(10.2), 센서(10.3), 제어(10.4), 대안 도구(10.5), 그리고 간극(10.6).
이제 로봇은 움직이고, 보고, 길을 찾고, 물건을 다루고, 가상에서 검증된다. 그런데 실제로 실행되기 시작하면 새로운 질문이 생긴다 — 무슨 일이 일어나고 있는지 어떻게 아는가? 데이터를 기록하고, 시각화하고, 추적하고, 성능을 측정하고, 문제를 진단하는 일. 제11부 도구·관측성(11.2~11.1) 의 주제다. rosbag2부터 시작한다.