유리를 놓치지 않고 통로도 막지 않기 — GlassGuard와 지도 수용 시험

2026년 10월 1일 arXiv에 공개된 GlassGuard는 건축용 유리를 복원하면서 실제 통행 공간의 잘못된 점유도 함께 평가한다. RA-L 제출본이며, 주행 성공률의 정량 검증은 아니다. GlassGuard 초록·§V-E

이 글의 실무 제안은 지도 변경을 두 개의 독립된 질문으로 심사하는 것이다. 실제 벽이 빠졌는가, 그리고 지나갈 수 있는 길을 새 벽이 막았는가. 두 질문의 합격 여부를 따로 기록해야 한쪽의 개선으로 다른 쪽의 퇴행을 가리지 않는다.

예를 들어 같은 복도에서 유리문을 닫은 기록과 연 기록을 준비한다. 닫힌 문을 통과하도록 계획한 경우와 열린 출입구에서 경로를 찾지 못한 경우를 서로 다른 실패로 분류한다. 이는 설명을 위한 시험 설계이며 실제 측정 사례가 아니다. 이후 절의 ‘실무 제안’ 역시 저자들의 구현·검증 결과와 구분한다.

Tibebu 등의 연구는 유리를 통과하는 레이저의 거리 측정 변화에 주목한다. 인접 관측의 거리 분산을 먼저 검사하고, 거리와 강도의 변화로 후보를 좁혀 지도에 사용할 측정값을 보정한다. 단순히 강도가 크면 유리라는 규칙과는 다른 접근이다. Sensors 2021, 방법·결론

실무 제안: 로그에서 ‘유효 거리’, ‘반환 없음’, ‘범위 밖’, ‘유리 의심’을 서로 다른 상태로 남긴다. 전처리 단계에서 전부 같은 빈 셀로 바꾸면, 후처리 결과가 달라졌을 때 원인을 역추적하기 어렵다. 원시 강도도 정규화 전후를 구분해 보관하고 센서 모드와 펌웨어 식별자를 함께 기록한다.

회귀 시험에는 동일 위치에서 입사 방향만 달리한 관측, 문 상태만 바뀐 관측, 뒤쪽 물체만 바뀐 관측을 포함시키자. 알고리즘을 바꾸기 전에 입력 자체가 달라진 것인지 확인할 수 있어야 한다. 여기서 제안한 기록 항목은 특정 센서의 보장 사양이 아니라 디버깅을 위한 설계안이다.

MonoGlass3D는 단안 영상에서 유리 분할과 평면 회귀를 결합한다. 반면 GlassRecon을 제시한 연구는 깊이 모델의 상대적 구조를 센서 깊이에 맞춰 절대 척도로 정렬한다. 후자는 국소 패치에서 만든 RANSAC 후보를 전체 영상의 오차로 선택한다. MonoGlass3D §IV · 깊이 정렬 논문 §IV

TOPGN의 표현은 높이 구간별 강도를 이용한다. 위 표는 각 논문의 방법을 구분한 것이며 동일 장비에서의 성능 순위가 아니다. TOPGN §IV

실무 제안: 인터페이스 문서에 좌표계, 단위, 시각, 유효 영역을 필수 필드로 둔다. ‘유리 있음’이라는 마스크만 받는 모듈과 미터 단위 벽을 받는 플래너 사이에는 변환 책임자를 명시한다. 출력 형태를 합의하면 실패 지점을 분할·깊이·좌표 변환 중 어디서 찾을지도 명확해진다.

GlassGuard는 Slim SAM3 마스크와 LiDAR 구조로 만든 평면 후보를 영상 기하로 검사한다. 단일 시점의 방향 일치는 절대 깊이의 독립 검증이 아니다. GlassGuard §IV-B–D

실무 제안: 후보마다 orientation_check, metric_support, observation_time, frame_id를 별도로 기록한다. 이 이름들은 설명용 스키마이며 논문의 API가 아니다. 방향 검사를 통과했지만 거리 근거가 약한 후보를, 모든 조건을 통과한 후보와 동일하게 취급하지 않도록 하기 위한 구분이다.

합성 시험에서는 동일한 벽에 대해 회전 오차와 평행 이동 오차를 따로 주입하자. 회전만 검사하는 단계가 평행 이동을 검출하지 못하는 것은 예상 가능한 경계다. 검출하지 못한 항목은 후속 관측으로 처리할지, 미확정으로 남길지 문서화한다. 검증기가 담당하는 오류 유형과 담당하지 않는 오류 유형을 함께 적어야 실패를 숨기지 않는 인터페이스가 된다.

GlassGuard Table III의 GG-pin은 9개 장면, 1 m 복셀에서 Ever coverage 82.1%, spill/frame 16.7을 보고한다. Ever는 평가 대상인 정답 유리 복셀 중 적격 프레임에서 한 번 이상 검출된 비율이다. Spill/frame은 로봇 10 m 이내의 프레임당 평균 오점유 복셀 수다. 비교는 기록된 rosbag 재생이며, 같은 pinhole 영상이어도 방법별 LiDAR 사용은 다르다. GlassGuard §V-A–C, Tables II–III

실무 제안: 자체 결과표의 각 행에는 모델 이름 외에 센서 입력, 시야각, 지도 해상도, 누적 정책, 평가 장면 식별자를 넣는다. 다른 해상도의 복셀 개수는 별도 열에 둔다. 유리 면적이 큰 장면 하나가 전체 평균을 좌우하는지 보기 위해 장면별 결과와 합산 결과도 함께 제시한다.

비교표를 만드는 순서는 ‘원 논문 설정 재현 → 자체 환경에서 동일 입력 비교 → 센서 구성을 포함한 시스템 비교’가 좋다. 앞 단계가 빠졌다면 재현 성공으로 표시하지 않는다. 표 제목에는 실제로 완료한 단계만 적는다. 그래야 전처리 차이, 시야 차이, 알고리즘 차이가 한 숫자에 섞인 채 개선으로 보고되는 일을 줄일 수 있다.

GlassGuard의 전역 관리는 병합·바닥 증거·다중 시점 관측으로 평면을 수정한다. 다중 시점 검증의 효과도 모든 지표에서 일관된 이득은 아니다. GlassGuard §IV-E·§V-D

실무 제안: 지도 변경 로그를 ‘후보 생성 → 채택 → 수정 또는 철회’의 사건 목록으로 만든다. 각 사건에 이유와 근거 관측을 붙이고, 플래너가 읽은 지도 버전을 남긴다. 화면에서 벽이 지워졌는지보다 실제 경로 계산에 전달된 버전에서 지워졌는지가 시험의 대상이다.

회귀 사례에는 열린 문이 계속 막혀 있는 경우와, 닫힌 문이 잠시 가려졌다가 지도에서 사라지는 경우를 함께 넣자. 철회를 빠르게 하면 좋은지 느리게 하면 좋은지를 평균 하나로 판단하지 않는다. 출입구 복구 시간과 실제 벽의 공백 시간을 별도 기록한다. 이 사건 모델과 두 시간 지표는 구현 검토를 위한 제안이며, 논문이 동일한 상태 기계나 운영 기준을 제공한다는 뜻은 아니다.

GG-pin의 평균 처리 시간은 RTX 5070 Ti laptop GPU에서 프레임당 0.74초다. GlassGuard Table II

TOPGN은 LiDAR 강도를 이용하는 별도 접근이며, 저자들은 센서의 수직 시야와 품질, 급격히 굽거나 기울어진 표면, 위치추정 오차를 한계로 명시한다. 따라서 GPU 사용 여부만으로 두 접근의 적용 범위를 정할 수 없다. TOPGN §VI

실무 제안: 센서 취득, 전송 대기, 추론, 좌표 변환, 지도 반영, 플래너 소비 시각을 같은 시간축에 남긴다. 평균 추론 지연과 함께 오래된 지도가 사용된 시간, 처리 큐 길이, 드롭된 관측 수도 확인한다. 장비가 달라지면 정확도 시험과 지연 시험을 함께 다시 수행한다.

예산 초과 시 정책도 명시해야 한다. 최신 관측을 우선할지, 갱신을 중단하고 미확정 상태를 알릴지 결정하고 지연을 주입해 검증한다. 처리 시간 한 값만으로 주행 속도를 정하는 공식을 제시하지 않는다. 실제 정지 거동과 전체 센서·제어 경로를 측정하지 않았기 때문이다.

깊이 사전정보 정렬 논문은 센서 깊이 손상이 심한 경우를 따로 평가하고, 잘못된 유효 깊이가 화면 대부분을 차지하면 정렬도 오염될 수 있다고 설명한다. 평균 깊이 오차만 보고 입력 품질의 차이를 생략해서는 안 되는 이유다. 깊이 정렬 논문 §V·§VI

실무 제안: 다음은 재현 결과와 별도로 운영할 자체 평가표다. 수치 기준은 시험 전에 용도별로 정한다. 아래에는 임의의 합격 수치를 넣지 않았다.

실패 코드를 먼저 고정하면 불리한 장면을 나중에 제외하거나 개입을 성공으로 셀 여지를 줄일 수 있다. 분모가 달라진 결과는 새 평가 버전으로 기록한다.

MonoGlass3D는 영상의 유리 마스크와 3차원 평면을 함께 주석화하고, 센서 동기화와 외부 파라미터 보정을 데이터 수집 절차에 포함한다. 정답 데이터에도 좌표 변환의 책임이 있음을 보여주는 사례다. MonoGlass3D §III

실무 제안: 먼저 장면을 튜닝용과 최종 검증용으로 나누고, 같은 출입구의 인접 프레임이 양쪽에 섞이지 않도록 한다. 출입구 상태와 유리 경계는 예측을 보기 전에 주석화한다. 애매한 경계는 임의로 채우지 말고 불확실 영역으로 남겨 평가 규칙을 정한다.

그다음 원시 재생을 기준으로 하나씩 조건을 바꾼다. 카메라 지연, 외부 파라미터 오차, 일부 관측 누락, 유리 앞 가림을 독립적으로 주입한다. 어떤 모듈이 실패했는지와 최종 지도에 어떤 변화가 생겼는지를 함께 저장한다. 한 번에 여러 조건을 바꾸면 원인 분석이 어려워진다.

마지막으로 버전·설정·입력 식별자·정답 버전을 묶어 결과를 보관한다. 실물 시험에 앞서 기록 재생의 결과를 재계산할 수 있어야 한다. 이 순서는 제안이며, 이 글에서 실험을 수행했거나 어느 구현을 재현했다고 주장하지 않는다.

GlassGuard는 평면에 가까운 수직 유리를 가정한다. 곡면·크게 기울어진 유리와 더 빠른 갱신은 남은 과제다. GlassGuard §VI

실무 제안: 검토 문서의 마지막 표는 ‘확인’, ‘실패’, ‘미검증’ 세 상태를 사용하자. 새 환경에서 아직 시험하지 않은 항목을 기존 논문 결과로 채우지 않는다. 카메라가 없는 구성, 다른 LiDAR, 움직이는 문, 혼잡한 복도처럼 입력과 장면이 바뀌는 경우 각각 독립된 시험 항목을 만든다.

코드·가중치·데이터의 확보 여부와 사용 조건도 실제 확인한 파일 및 버전으로 기록한다. 이 글은 다운로드 가능성이나 라이선스를 확인했다는 주장을 하지 않는다. 적용 검토에서 확보가 안 된 항목은 ‘미확인’으로 남긴다.

착수할 만한 작은 산출물은 자체 장면의 실패 목록, 두 종류의 지도 오류를 재계산하는 평가기, 그리고 동일 설정의 반복 재생 결과다. 이 셋이 갖춰지면 어떤 센서 접근을 더 검토할지 판단할 근거가 생긴다. 신뢰할 만한 개선 주장은 그 다음 실험의 결과로 작성한다.