NavHarness는 집 안을 돌아다니는 로봇이 매번 새 요청을 받을 때, 이전에 쌓은 지도와 탐색 기록을 "대화가 끊긴 뒤에도" 이어 쓰게 만드는 장치다. 모델을 추가로 학습시키지 않고(training-free), 메모리를 읽고 고치는 일 자체를 내비게이션의 매 순간 안으로 집어넣었다. 그 결과 GOAT-Bench에서 매번 백지에서 시작하는 세션보다 성공률을 Astra 기준 18.6점, Opus 5 기준 22.6점 끌어올렸고, SLAM 추정 위치를 쓰고도 기존 최고 기록을 넘어섰다.
요즘 프런티어 모델은 간단한 도구(관찰·이동)만 쥐여줘도 하나의 내비게이션 과제는 꽤 잘 푼다. 여러 번 보고 생각하고 움직이는 멀티라운드 추론 덕분이다. 문제는 그다음이다. 집에서 일하는 로봇은 하나의 심부름으로 끝나지 않는다. 아침에 리모컨을 찾고, 점심에 택배를 옮기고, 저녁에 안경을 가져온다. 각 과제는 앞 과제가 끝난 바로 그 자리에서 시작한다.
여기서 기존 방식의 한계가 드러난다. 새 요청마다 대화를 처음부터 다시 열면, 로봇의 몸은 그 자리에 있는데 머릿속 기억은 리셋된다. 이미 샅샅이 뒤진 방을 또 뒤지고, 앞서 "거실엔 없더라"라고 적어둔 기록을 활용하지 못한다.
반대로 기록을 넘겨받아도 또 다른 함정이 있다. 어떤 방에서 물건을 "못 찾았다"는 기록이, 그 방의 구석구석을 다 봤다는 뜻은 아니다. 예전에 적어둔 "소파는 파란색"이라는 메모가 지금 눈앞의 장면과 어긋날 수도 있다. 기억은 불완전하고, 때로 현재 관찰과 충돌한다. 그러니 기억을 그냥 믿고 따르는 것도, 무시하고 매번 새로 시작하는 것도 답이 아니다. 저자들이 겨냥한 지점이 바로 이 틈이다.
NavHarness의 발상은 간단하게 요약된다. 기억을 읽는 일을 "출발 전 브리핑"으로 몰아넣지 말고, 길을 걷는 내내 수시로 꺼내 보고 눈앞 장면과 대조하고 틀린 건 고쳐 쓰라는 것이다.
인수인계가 꼼꼼한 교대 근무를 떠올리면 가깝다. 밤 근무자가 떠나며 남긴 메모 한 장이 아니라, 지금까지 어디를 봤고 무엇을 배제했으며 어디가 아직 미해결인지를 구조화해 다음 사람에게 넘긴다. NavHarness는 이 구조를 코드로 박아 넣었다. 몇 가지 구성요소로 나눠 보면 이렇다.
| 요소 | 하는 일 |
|---|---|
| 세션(session) | 한 번의 탐색을 맡는 멀티턴 멀티모달 대화. 추론의 핵심 |
| 핸드오버(handover) | 과제를 닫을 때 목표·탐색한 장소·결과 근거·끝내지 못한 탐색을 요약해 다음 세션에 전달 |
| 복구 노트(recovery note) | 같은 목표를 다시 시도할 때, 지금까지의 근거와 남은 선택지를 새 시도에 넘김 |
| 원장(ledger) | 닫힌 과제마다 한 줄씩(목표·기록된 상태·장소명)을 남긴 압축 색인. 나중 세션이 관련 과제를 찾아 상세 기록을 열람 |
| 통합(consolidation) | 한 집에서의 작업(run)이 끝날 때, 과제 기록을 '집 노트'로 간추려 다음 번 작업을 돕는다 |
핵심은 이 기록들을 대화 창(context) 안에 통째로 쏟아붓지 않는다는 점이다. 로봇은 필요할 때 파일을 열어 읽고, 탐색이 전개되면서 추가 기록을 더 찾아본다. 이 접근이 영리한 이유는, 기억을 메모리 전용 모델을 따로 학습시키지 않고도 "코딩 에이전트가 파일을 읽고 고치는" 이미 검증된 습관으로 처리한다는 데 있다.
또 하나 중요한 장치가 검증이다. 그림상 Verify(멈추기 전 검증)와 Certify(멈춘 뒤 인증)로 나뉜다. 왜 필요한가. 나중 탐색이 앞선 기록에 의존하기 때문에, "찾았다"는 잘못된 완료 선언이 그대로 경험으로 굳으면 두고두고 뒤를 오염시킨다. 그래서 완료를 기록으로 승격시키기 전에 증거를 따져본다.
성과는 두 갈래로 읽어야 한다. 같은 실험에서 나온 수치라도, 절대값과 향상폭은 구분해 읽어야 오해가 없다.
첫째, 백지 세션 대비 향상폭이다. 매 과제를 외부 메모리 없이 새 대화로 푸는 "컨텍스트 전용 독립 세션"과 비교해, GOAT-Bench에서 s-SR(성공률 지표)이 Astra 백본에서 65.1%→83.7%(18.6%p), Opus 5 백본에서 58.9%→81.5%(22.6%p)로 올랐다. 같은 실험 안에서 독립 세션의 절대 성능과 NavHarness의 절대 성능을 나란히 놓고 그 차이를 본 값이다. 기억을 이어 쓰는 설계가 단일 과제 능력과 별개로 이득을 준다는 증거다.
둘째, 절대 성능이다. 시뮬레이터가 알려주는 정답 위치가 아니라 SLAM으로 추정한 위치를 쓰고도, GPT-6 Astra 조합의 NavHarness가 GOAT-Bench에서 s-SR 83.7%, e-SR 36.9%를, IR2R-CE에서 s-SR 85.9%를 기록하며 기존 최고 성적을 넘었다. 정답 위치라는 유리한 조건을 빼고도 최고점이라는 점이 설득력을 더한다. 저자들은 네 개 백본 전부에서 같은 백본의 독립 세션 대비 성공률과 경로 효율이 올랐다고 밝힌다.
가장 흥미로운 발견은 성능 수치가 아니라 그 원인 분석에 있다. 같은 분량으로 맞춘 평범한 요약을 넘겨주는 것보다, 구조화된 복구 핸드오버를 넘겨줄 때 결과가 더 좋았다. 즉 "얼마나 많이 넘기느냐"가 아니라 "무엇을 어떻게 구조화해 넘기느냐"가 성패를 가른다. 여러 집을 오가는 장기 배치 실험에서는, 지도와 과제 기록을 단순히 보존하는 것보다 통합(consolidation)까지 했을 때 내비게이션이 더 나아졌다. 사례 연구에는 열아홉 과제가 지난 뒤에야 잘못 찍힌 마커를 바로잡거나, 실패한 탐색을 나중 세션이 이어받아 마무리하는 장면들이 담겼다.
저자들이 직접 짚는 한계가 적지 않다. 평가는 시뮬레이션 벤치마크(GOAT-Bench·IR2R-CE)에서 이뤄졌고, 실제 물리 환경·실시간성에 대한 검증 범위는 제한적이다(논문 Limitations의 실세계 평가·실행 속도 항목). 환경이 정적이라는 가정, 더 긴 배치에서 archive 접근이 어떻게 확장될지, 작은 모델의 역량이 받쳐줄지도 열린 질문으로 남겨둔다.
그리고 사례 연구 중에는 실패 장면도 솔직히 포함된다. 잘못된 완료가 메모리에 인증돼 들어간 경우(Case 7), 진단은 했지만 요약 과정에서 그 정보가 유실된 경우(Case 9), 저장된 경험을 로봇이 거부한 경우(Case 12~14)다. 기억을 이어 쓰는 설계는 좋은 경험만이 아니라 나쁜 경험도 전파할 위험을 함께 안는다 — 여기엔 함정이 있다. 그래서 검증 게이트가 선택이 아니라 필수가 된다.
이 연구를 로봇 이야기로만 읽으면 핵심을 놓친다. NavHarness가 실제로 다루는 건 "세션이 끊겨도 경험을 잃지 않는 에이전트"라는, AI PM 제품의 심장부와 같은 문제다.
온틀의 AI PM이 한 고객사의 요청을 처리하는 장면을 하나 떠올려 보자. 지난주 PM 세션에서 "결제 연동 요청을 검토했지만 카드사 스펙 문서를 못 받아 보류"라고 적어뒀다. 이번 주에 같은 고객이 "환불 흐름도 붙여달라"는 새 요청을 올린다. 지금까지 흔한 에이전트라면 새 대화는 백지에서 시작하고, 앞선 보류 사유나 이미 확인한 제약을 다시 묻거나, 최악의 경우 똑같은 삽질을 반복한다.
NavHarness의 구조를 이 장면에 그대로 대입하면 달라진다. 원장은 이 고객사의 닫힌 요청들을 한 줄씩 색인해두고, 핸드오버는 "결제 검토에서 어디까지 봤고 무엇이 막혔는지"를 구조화해 다음 세션에 넘긴다. 새 환불 요청을 받은 PM 세션은 이 기록을 통째로 프롬프트에 때려 넣는 대신, 필요할 때 열어 읽고 현재 요청과 대조한다. "결제가 보류 상태이니 환불도 같은 카드사 스펙에 묶인다"는 판단을 스스로 꺼내 쓴다. 보류됐던 결제 요청을 복구 노트로 되살려 이어가는 것은, 논문의 "실패한 탐색을 나중 세션이 재개한다"와 정확히 같은 동작이다.
여기서 온틀이 가져갈 교훈은 분량이 아니라 구조라는 발견이다. 긴 요약을 다음 PM에게 넘기는 것보다, "확인한 것 / 배제한 것 / 미해결인 것"을 구조화해 넘기는 편이 낫다. 그리고 완료를 기록으로 굳히기 전 검증 게이트를 두는 것 — 잘못된 "처리 완료"가 고객 이력에 박히면 뒤따르는 모든 판단을 오염시킨다는 경고는, 온틀이 이미 지급성 액션에 멱등·검증을 거는 이유와 맞닿는다. 평생 일하는 PM을 만들고 싶다면, 모델을 더 키우기 전에 세션 경계를 어떻게 설계하느냐부터 봐야 한다는 이야기다.
아닙니다. training-free 설계로, 내비게이션 전용 학습 없이 기성 프런티어 모델에 메모리 처리 루프와 도구만 얹습니다. 그래서 백본 모델을 바꿔 끼울 수 있고, 논문은 네 개 백본 전부에서 향상을 보고합니다.
같은 GOAT-Bench 실험에서 나온 수치입니다. Astra 백본 기준 독립 세션이 s-SR 65.1%, NavHarness가 83.7%이고 그 차이가 18.6%p입니다(Opus 5는 58.9%→81.5%로 22.6%p). 즉 83.7%는 절대 성능이고, 18.6%p는 그 성능이 백지에서 시작하는 독립 세션보다 얼마나 높은지를 나타내는 향상폭입니다. 조건이 다른 게 아니라, 같은 결과를 절대값과 향상폭 두 방식으로 본 것입니다.
많은 벤치마크 결과는 시뮬레이터가 알려주는 정답 위치를 전제로 합니다. NavHarness는 그 유리한 조건 대신 센서로 추정한 위치를 쓰고도 기존 최고 기록을 넘었습니다. 실제 로봇에 더 가까운 조건에서의 성적이라는 점에서 의미가 큽니다.
맞습니다. 논문도 잘못된 완료가 메모리에 인증돼 들어가거나(Case 7), 요약 중 정보가 유실되는 사례를 솔직히 보고합니다. 그래서 멈추기 전 검증(Verify)과 멈춘 뒤 인증(Certify)으로 완료 주장을 걸러 경험으로 굳히기 전에 증거를 확인합니다.