시뮬레이터 버전 계열 — 자료를 섞으면 안 되는 이유

로봇 시뮬레이터를 처음 붙일 때 가장 많이 태우는 시간이 버전 문제예요. 기능을 못 익혀서가 아니라, 다른 계열의 자료를 보고 따라 해서 그래요.

이름이 비슷한데 다른 물건이에요

시뮬레이터가 세대 교체를 거치면서 계열이 갈렸어요. 이전 세대와 새 세대가 있고, 새 세대 안에서도 릴리스마다 이름이 붙어 있죠.

문제는 계열이 다르면 설정 파일 형식도, 플러그인 구조도, 실행 방식도 서로 안 맞는다는 거예요. 이름은 비슷한데 사실상 다른 물건이에요.

그런데 검색하면 둘이 섞여서 나와요. 블로그 글에 버전이 안 적혀 있는 경우가 많고, 적혀 있어도 눈에 안 들어오죠. 그래서 이전 세대용 설정을 새 세대에 넣고 왜 안 되는지 찾게 돼요.

증상이 고약한 이유가 있어요. 일부는 되거든요. 완전히 다른 물건이면 바로 알아채는데, 겹치는 부분이 있어서 절반쯤 동작하다 막혀요. 그러면 자료가 틀린 게 아니라 내가 뭘 잘못했다고 생각하게 되죠.

미들웨어 배포판과 시뮬레이터 사이에도 공식으로 맞춰 놓은 짝이 있어요. 그 조합으로 나온 연결 패키지가 저장소에 올라가 있고, 문서도 그 기준으로 쓰여 있죠.

짝을 벗어나면 못 하는 건 아니지만 비공식 패키지를 찾아 붙여야 해요. 그 순간 문제가 생겼을 때 물어볼 곳이 사라져요. 같은 조합을 쓰는 사람이 적으니 검색해도 안 나오고요.

그래서 판단 기준이 하나 서요. 구분되지 않는 축에서는 마찰이 적은 쪽을 고르는 게 정답이에요. 어느 계열을 썼는지가 결과물의 가치를 가르지 않는다면, 주변에서 많이 쓰는 쪽, 자료가 많은 쪽, 공식 짝인 쪽을 따라가는 게 맞아요.

이건 게으른 선택이 아니라 어디에 시간을 쓸지의 선택이에요. 버전 조합을 맞추는 데 쓰는 시간은 남는 게 없거든요.

또 하나 자주 하는 판단 실수가 있어요. 직접 만드는 게 더 잘 배우는 길처럼 느껴지는 거요.

그런데 이미 성숙한 생태계가 있는 층을 다시 만드는 건 재사용을 못 한다는 신호로 읽혀요. 구조 파일, 시뮬레이션 연동, 기성 제어기, 좌표 변환 같은 것들은 잘 만들어진 게 이미 있어요.

기여할 자리는 다른 데 있어요. 생태계에 빠져 있는 층이요. 예를 들면 시뮬과 실물의 차이를 정량으로 재고 리포트하는 층 같은 것들이죠. 여기는 각자 알아서 하고 있어서 공용 도구가 잘 없어요.

그래서 판단이 이렇게 갈려요. 있는 건 가져다 적응시키고, 없는 걸 만들어요.

다만 가져다 쓰는 데도 규율이 붙어요. 왜 이걸 골랐고 어디를 고쳤는지에 답할 수 있어야 해요.

비슷한 패키지가 여럿 있을 때 하나를 고른 데는 이유가 있어야 해요. 시뮬레이션 실행이 명확한지, 문서가 있는지, 대상 하드웨어가 맞는지 같은 기준들이요. 찾다가 처음 나온 걸 썼다는 건 판단이 아니거든요.

고친 부분도 마찬가지예요. 대개 그대로는 안 돌아가서 어딘가를 손보게 되는데, 무엇을 왜 고쳤는지가 실제로 배운 부분이에요. 그걸 기록 안 하면 몇 주 뒤에 자기가 왜 그렇게 했는지 모르게 되고요.

마지막으로 구체적인 감각 하나예요.

구조 파일에서 손으로 채우기 어려운 물성치가 어떤 모양인지 보면 이래요. 작은 팔의 링크 하나가 질량 0.147킬로그램이고, 관성값이 0.0001 언저리예요.

이 자릿수 감각이 쓸모 있어요. 공식 문서가 감이 없을 때 권하는 기본값이 0.001 이하인데, 실측값이 그보다 한 자리 더 작은 데 있어요. 그러니 관성값에 1을 넣는 게 얼마나 어긋난 건지 감이 오죠. 네 자리가 차이 나요.

이런 값은 손으로 계산하는 게 아니라 설계 도구가 뽑아 줘요. 다만 재질과 밀도를 제대로 넣었을 때만 맞는 값이 나와요. 그 이야기는 URDF 관성 텐서 — 기본값이 링크를 콘크리트로 만드는 칸에 있어요.

시뮬레이터를 붙일 때 시간을 태우는 자리는 대개 기술이 아니라 판단이에요. 어느 계열을 쓸지, 무엇을 가져다 쓰고 무엇을 만들지요.

앞의 것은 마찰이 적은 쪽을 고르면 되고, 뒤의 것은 생태계에 있는지 없는지로 갈려요. 둘 다 결과물의 가치를 가르지 않는 축에서는 고민을 짧게 끝내는 것이 요령이에요.