로봇 시각 디버깅을 LLM에 맡겼더니, 결국 사람이 스크린샷으로 오류를 지적하게 됨
- 로봇 개발자인 저자는 LLM 코딩 보조 도구에 시각 디버깅을 맡기려 했지만, 모델이 정상적인 로봇 동작을 이해하지 못해 그리퍼가 뚜껑의 지정 지점을 계속 놓침
- 저자는 이미지 인코더와 Rerun의 MCP 서버를 연결했지만, 사람이 5초 만에 맞추는 디버그 뷰 시점을 MCP 보조 도구는 최대 5분 동안 찾음
- 시각 디버깅을 요청하면 약 30분 뒤에도 새롭지만 여전히 틀린 답을 받는 일이 반복돼, 저자는 직접 뷰어를 살피고 오류 스크린샷을 모델에 보내는 방식으로 돌아감
- 저자는 결국 오류를 찾는 일도 직접 처리해 '컴퓨터의 안내견' 같은 역할이 됐다고 표현하며, LLM이 디버깅의 허드렛일을 대신할 것이라는 기대를 접음
Hacker News opinions
AI를 훈련하고 개선하면 같은 해결책을 매번 다른 맥락에 다시 만드는 허드렛일이 끝난다고 봄. 25년간 소프트웨어 엔지니어 일을 게임 노가다처럼 느꼈는데, 이제 생각하는 속도로 만들 수 있어서 좋음.
나는 코드 자체가 보상임. 45년 동안 직접 코드를 다듬고 최적화하는 게 취미였고, 10년째 언어와 OS도 만들고 있음. LLM은 지루한 코드에 쓰지만 직접 쓰는 즐거움까지 없앨 이유는 없더라.
OpenAI, Anthropic, Google, Meta 같은 회사들이 인류의 자유를 위해 일한다는 말은 믿기 어려움. 그 회사들의 의도를 생각하면 냉소적일 수밖에 없음.
문제는 인간이 에이전트 루프에 필요한 균형점이 얼마나 갈지임. 몇 년짜리 창일 수도 있고 오래갈 수도 있는데, 모델 확장 성능과 추론 비용이라는 불투명한 경제성이 답을 좌우할 듯함.
몇 달 쉬었다가 비전 모델이 더 좋아지고 싸지면 다시 해보면 됨. Astra는 이미 스크린샷을 보고 조작하는 데 꽤 잘한다는 얘기가 있음.
움직일 때만 드러나는 버그나 SBC에서 케이블을 빼먹은 문제는 스크린샷만으로 못 잡음. 저자의 지적은 그대로 유효함.
로봇 손을 다뤘는데 5.6과 Fable 5는 시각 디버깅에 거의 쓸모없었음. 대신 모델에게 이동, 강조, 페인팅을 하는 대화형 3D 뷰어를 만들게 하니 물리적 위치 관계를 전달하기 쉬웠고, 예시를 몇 번 주면 더 쓸 만해졌음.
MoCap을 쓰는 이유가 있음. 실제 움직임과 물리 상황은 시스템이 예측하기 훨씬 복잡한 듯함. 그런데 컴퓨터 명령을 내가 보완하는데 내가 '컴퓨터의 안내견'이라는 비유는 역할이 뒤집힌 느낌도 듦.
CEO들은 여전히 AI가 유급 일자리를 줄여줄 거라고 생각함. 그래서 AI가 아직 이런 문제를 못 푸는 게 실무자에게는 마냥 좋은 일만은 아님.
AI가 계속 일하려면 자기 눈 역할을 하는 사람이 피드백을 줘야 한다는 뜻으로 읽힘. AI가 사람을 자신의 기관처럼 쓰는 셈임.
주니어 개발자에게 늘 코드만 읽고 디버깅할 수는 없다고 말함. 버그가 난 상태를 재현하고 상태 정보를 충분히 줘야 하는데, 빨간 원이 그려진 이미지 하나를 비전 모델이 해석하는 것만으로는 부족함.
코드를 반복해서 읽으면 처음 만든 정신 모델의 메아리만 다시 듣게 됨. 그 모델이 틀렸다면 읽을수록 원인을 더 못 볼 수 있음.
버그를 실제로 본 뒤에는 그 동작을 염두에 두고 코드를 읽어서 찾는 경우도 많음. LLM도 세션마다 코드를 다시 읽고 동작 예측을 잘하니 이 방식이 꽤 통할 수는 있음. 그래도 증거를 더 모으는 능력은 디버깅의 기본임.