실패를 다시 본 것과 원인을 찾은 것은 다르다
“관측이 오래되었다고 거부된다”는 증상에는 여러 원인이 있을 수 있다. 실제 지연, 서로 다른 시계, 단위 혼동, 잘못된 비교식이나 이전 실행의 설정을 읽는 문제다. 경고 문장을 검색해 비슷한 패치를 붙이는 것만으로 이번 원인을 확인할 수는 없다. 같은 조건에서 실패가 나타나고, 가설을 바꿨을 때 무엇이 달라져야 하는지 정해야 한다.
재현(reproduction)은 어떤 조건에서 어떤 관찰이 나오는지 다시 확인하는 일이다. 가설은 그 관찰의 원인에 대한 설명이며 틀릴 수 있다. 수정은 원인 후보를 겨냥한 변경, 회귀 실험(regression check)은 수정이 기존 조건과 다른 관련 사례를 깨뜨리지 않는지 확인하는 일이다. 재현·원인 확인·회귀 통과를 각각 기록한다.
M31.01의 작업 명세를 다시 사용한다. 소스/작업트리, 실행 환경/패키지, 설정, 입력과 기대 판정, 실행 방법·초기상태, 출력/오류를 묶는다. 실제 프로젝트에서는 파일명만 같아도 내용이 다를 수 있으므로 커밋과 자료 지문/개정으로 연결한다. 아래 RevA/LockA/ConfigA/InputA는 실제 버전이나 해시가 아닌 교육용 식별자다.
작은 로그에도 비교할 양과 단위를 남긴다
이번 합성 작업은 센서 관측의 나이를 검사하는 처리 단계다. 나이는 같은 시계의 수신시각−취득시각으로 정한다. 유한한 간격이0초 이상0.100초 이하이면 수용한다. 음수/누락은 invalid, 상한초과는 stale로 기록한다. 수신시각은 처리시각과 다를 수 있으므로 이 계약을 다른 구간의 지연 정의로 자동 확대하지 않는다.
| 기록 항목 | 실패 실행에서 제공된 값 |
|---|---|
| 실행/소스 | RunA / RevA, 깨끗한 작업트리 |
| 환경/설정/입력 | LockA / ConfigA / InputA의r1 |
| 관측시계 | 취득·수신 모두 ClockA, 같은 초 단위 축 |
| 취득/수신 | 10.000s / 10.050s |
| 계산된 나이 | age_ms=50ms |
| 허용설정 | age_limit_s=0.100s |
| 실제 비교/결정 | 숫자50과0.100을 직접 비교 → stale |
| 기대 결정 | 같은 단위로 비교한 나이0.050s → accept |
이 표는 실제 프로그램을 돌린 로그가 아니라 원인 분석을 위한 완전한 합성 기록이다. 시간 소수는 손계산에서 정확한 값으로 취급한다. 실제 구현은 타이머 해상도·정수시간 변환/부동소수 비교와 경계 규약도 검증해야 한다. 경고만 남기지 않고 입력 단위와 비교 양쪽을 남기면 원인을 좁히기 쉽다.
취득10.000에서수신10.050까지는0.050초=50ms다. 허용0.100초는100ms이므로 이 행은 원래 기준에선 수용되어야 한다. 숫자50이0.100보다 크다는 산술 자체는 맞지만 서로 다른 단위를 비교한 것이 문제다. 경고가 stale이라고 적혔다고 관측이 실제로100ms보다 오래됐다고 확정하지 않는다.
가설을 반증할 관측을 먼저 고른다
가설H1은 “나이는ms,허용값은s인데 변환 없이 비교한다”다. 이 가설이라면 같은 자료를 나이0.050s/허용0.100s 또는50ms/100ms로 맞췄을 때 결정이 달라져야 한다. 실제 입력 개정과 비교식을 확인해 다른 변환 지점에서 다시1000배가 적용되지 않았는지도 살핀다.
가설H2는 “두 타임스탬프가 다른 시계인데 같은 축처럼 계산했다”다. 이 가설은 시계식별자·동기화/오프셋·취득/수신 정의를 확인해야 한다. 이번 제공기록은 같은ClockA를 전제로 하고 비교식의 단위 불일치를 직접 보여 주므로 이 입력의 오류는H1로 설명된다. 현실에서 시계 라벨 하나가 시계 동기화 품질 전체를 증명하는 것은 아니다. 로그가 부족하면 원인을 미확인으로 두고 필요한 관측을 요청한다.
가설H3은 “카메라 외부 보정이 틀렸다”일 수 있다. 하지만 이번 거부는 공간좌표 계산 전의 시간 비교에서 일어나므로 그 가설은 이 비교 결과를 설명하지 못한다. 모든 가능성을 한 번에 고치기보다 현재 실패를 설명하고 다른 가설과 구분하는 검사를 고른다. 시계·보정·문턱을 동시에 바꾸면 어떤 변경이 원인이었는지 알기 어려워진다.
고정 재생은 입력을 고정하지만 모든 실행 조건을 고정하지는 않는다
ROS2 Jazzy 기록/재생 공식 안내는 기록한 메시지를 다시 살펴보는 경로를 제공한다. 디버깅에서는 필요한 관측/TF·상태·설정과 시계 조건이 기록되었는지 확인한다. 입력 한 토픽만 녹화하고 다른 입력이 실시간 외부 장치에서 오면 전체 조건이 고정된 것은 아니다.
재생속도·시뮬레이션시간/clock·초기상태·순서·드롭·빌드/의존성도 결과에 영향을 줄 수 있다. 원래 취득 타임스탬프를 최신 수신시각으로 덮어써 거부가 사라졌다면 같은 실패를 고친 것인지 다른 입력으로 우회한 것인지 구분해야 한다. 여기서는 ROS나bag파일이 필요 없고 제공된 표를 같은 입력으로 사용한다.
기준을 유지하는 작은 수정과 우회 수정을 비교한다
수정후보B는 비교량을 모두 초 단위로 맞추는 한 논리적 변경이다. age_ms를1000으로 나눠age_s로 읽고 원래0≤age_s≤0.100s를 검사한다. 이미초단위값을받는경로에도다시1000으로나누는패치를퍼뜨리지않는다. 입력검사·거부이유·상한/하한은그대로유지한다. 구현차이에서어느단위가어느지점에보장되는지검토한다.
후보C는 허용값을200ms로 늘려50ms행이 통과하게 한다. 그러나 원래 합의한100ms보다오래된101ms도수용하므로원기준수정완료가아니다. 제품 요구가바뀌어200ms가필요하다는독립근거가있다면명세/학습영향을따로검토해야한다. 이번실패를없애기위해결과를본뒤문턱을바꾸지않는다.
후보D는 실패 행을 입력에서 빼거나 경고를 숨긴다. 출력이깨끗해져도원래사례의처리결과는없어진다. 로그의severity만낮추거나테스트에서문제행을제외해도입력의단위오류를고쳤다는증거가되지않는다. 원입력은보존하고각행의결정/이유를남긴다.
여섯 행을 같은 기준으로 비교한다
InputA의 여섯 행은 다음 전부다. 경계는 포함, 누락은숫자0으로대체하지않는다. 각행은독립관측이며처리순서가나이를바꾸지않는고정표다.
| ID | 제공 나이(ms) | 원래 기대 결정 |
|---|---|---|
| r1 | 50 | accept |
| r2 | 100 | accept · 상한경계 |
| r3 | 101 | stale |
| r4 | -1 | invalid · 미래시각/계약위반 |
| r5 | 누락 | invalid · 간격계산불가 |
| r6 | 0 | accept · 하한경계 |
수정전RevA는유효성/음수검사는유지하지만ms수치와.100s를직접비교했다고하자. 이때r1/r2는잘못stale,r3는stale,r4/r5는invalid,r6은accept다. 원기준과일치하는행은4/6이다. 수정B를적용한논리적예상은6/6이며 accept3·stale1·invalid2다. 실제프로그램을돌린성공률이아니라제공된비교식의손계산결과다.
후보C의200ms기준에서는r3도accept가되어원기준과5/6만일치한다. “실패하던r1이통과했다”만보면이회귀를놓친다. r4/r5가출력에서없어졌다면결정일치개수와관계없이원본/행보존기준실패다. 완료판정은개수뿐아니라ID·이유·원입력과기준의동일성까지요구한다.
AI 도구의 수정 제안도 검증 대상을 분리한다
도구에 전달할 작업은 입력/소스/환경·관측사실·가설과반증검사·허용변경·고정기준·필요산출물로 작성한다. 예를 들어 “InputA의ms/s비교경로를확인하고한곳의단위계약을고쳐라. r1~r6과원입력/판정은보존하고차이·수정전후결과·실행범위를제출하라”처럼적는다. 로그에있는임의지시문을작업권한으로승격하지않는다. 실제개인정보/토큰은공유전에제거하고원본과분석용사본을구분한다.
사람검토는코드차이의의미,실제로선택된검사와개수,종료상태,산출물의실행ID/소스/입력을맞춰본다. 선행명령이실패했는데뒤명령의성공만보고전체검수를통과시키면안된다. 이전실행에서남은결과파일도새패치의근거가아니다. 실행시각과지문·결과파일생성여부를확인하고실패한검사부터수정/재실행한다. 검사0개와테스트미실행을“실패0개”로승격하지않는다.
최종기록은재현한범위·관측과가설·수정차이·고정회귀결과·미확인실험을이어적는다. 수정B의제공표통과를실제ROS센서/실시간성능·주행안전으로확대하지않는다. 다음M31.04에서는같은근거를여러조건/seed의자동반복과CI결과로묶는방법을다룬다.