LLM이 로봇 코드를 디버깅하게 만들려다 포기하고 직접 한 개발자의 이야기
I'm a seeing-eye dog for a computer
로봇 코드를 작성하는 개발자가 LLM 코딩 어시스턴트에게 시각적 디버깅을 맡겨보려 했지만, 모델이 로봇의 정상적인 동작을 이해하지 못하고 도구도 제한적이어서 결국 직접 디버깅을 하게 된 경험을 공유합니다. 시각화 도구와 MCP 서버를 갖췄음에도 불구하고 LLM은 잘못된 답을 반복하며 시간만 낭비했습니다.
결국 가장 멍청한 워크플로우만 남았습니다. 제가 직접 디버그 뷰어를 켜고, 이상한 실수를 찾아보고, 스크린샷을 찍어 언어 모델에게 이번에 얼마나 망쳤는지 알려주는 것뿐이었습니다.
HN 토론
95- dwedge
> 나는 인터넷에서 사람들과 논쟁하곤 했는데, 여섯 번 정도 답장을 주고받으면 상대가 생각할 능력이 없는 사람이라는 걸 깨닫게 된다.
그는 현재 상황의 문제점을 깨닫지만, 자신이 봇 농장과 바로 이런 이유로 고용된 팀들(불안, 논쟁, 참여를 유도하기 위한)과 논쟁해 왔다는 사실은 깨닫지 못한다.
약 10년 전, 나는 트위터의 인기 주제에서 이런 현상을 발견했다. 상대가 반대한다고 해서 어리석은 게 아니라, 그들이 말하는 방식에서 동시에 지적이고 어리석은 면이 보였는데, 이는 진짜 사람에게서 본 적 없는 방식이라서 한 계정 아래 서로 다른 사람들이나 봇이 있을 거라고 깨달았다.
내가 10년 전에 알아챘다면, 아마 최소 15년 전부터 그런 일이 있었을 것이다. 그는 그들보다 나은 게 아니라 그들의 함정에 빠진 것이다.
- onion2k
내가 멘토링하는 주니어/미드 레벨 개발자들에게 처음으로 해주는 말 중 하나는 "코드를 읽는 것만으로는 디버깅할 수 없다"는 것이다. 우리 모두는 코드가 어떻게 작동하는지에 대한 정신적 모델을 가지고 있는데, 대개는 조금 틀려 있다. 버그는 그런 실수들이 실제 세계에서 드러난 것이다. 코드를 읽을 때는 모두 그 모델을 통해 걸러지기 때문에, 예상치 못한 일이 왜 일어났는지 보지 못하게 된다. 무언가를 디버깅하려면 시스템을 버그가 발생하는 상태로 만들어서 왜 발생했는지 볼 수 있어야 한다.
LLM은 일반적으로 프롬프트에서 주는 정보와 함께 코드를 읽는 방식으로만 시스템을 디버깅한다. 기사 속 이미지는 메타 프롬프트다. 프롬프트는 AI가 '이해'하기 위해 사용하는 비전 모델에서 나오는 것이다. 그건 작동하지 않을 것이다. 성공적으로 디버깅하려면 훨씬 더 나은 상태 정보가 필요하다. '선반'이 설명되었는가? 이미지의 대비와 그림자 부족이 비전 모델을 방해하는가? 이미지에 '뚜껑'이 왜 없는가? 등등.
LLM은 영리하지만 마법은 아니다. 순진한 주니어 개발자처럼 대하라. 무언가의 상태에 대해 충분한 데이터를 주어 제대로 이해하게 하라.
- hspeiser
나는 이것을 완전히 이해한다. 나는 로봇 손과 5.6/Fable 5에서 작업해 봤는데, 시각적으로 디버깅하는 데 거의 쓸모가 없었다.
실제로 매우 유용했던 것은 모델이 인터랙티브 3D 뷰어를 만들게 하는 것이었고, 그 뷰어에서 이동/강조/페인팅(소프트 바디 페인팅을 지오메트리에 직접 하여 문제를 표시하고 다른 색상은 다른 실패를 의미)을 사용했다. 이는 라벨이 붙은 스크린샷으로 전달하기 어려운 물리적 관계와 위치를 전달하는 훨씬 더 나은 방법을 제공한다.
물론 여전히 많은 수작업이 필요하므로 '안내견'이라는 설명이 확실히 맞다. 그러나 추가 컨텍스트를 가진 몇 가지 예시 후에는 모델이 문제를 처리하는 데 훨씬 더 능숙해지고 유용해진다는 것을 발견했다.
- beklein
주제에서 약간 벗어나지만, 저자의 메인 프로젝트 랜딩 페이지(https://rerun.io/)에 있는 작은 로봇이 정말 마음에 든다.
나는 보통 마우스 하이재킹을 비난하지만, 이 구현은 허용될 것이다.
- Fr0styMatt88
LLM은 특정 종류의 디버깅에 특히 서툴다는 것을 발견했지만, 정확히 무엇인지 설명하기는 어렵다.
코드를 보고 버그 패턴과 대조할 수 있는 "이 코드에서 버그를 찾아봐" 같은 것은 정말 잘하는 것 같다.
"이 로그 파일이 있는데, 무슨 일이 일어나고 있다고 생각하나?" 같은 디버깅의 일부도 놀라울 정도로 잘한다.
문제는 그 중간에 있는 것이다. 솔직히 말하면, 보면 안다. 최근 예를 들면, 네트워크 메시지 파서에서 잘못된 데이터를 받고 있다. 즉시 내 잘못인지 상대방 잘못인지 알 수 없지만, LLM에게 그 동작을 막연하게 설명하려 하면 토큰을 쏟아내기 시작할 것이라는 것을 안다.
이런 문제에 대한 나의 현재 접근 방식은 이렇다. LLM에게 문제를 해결하는 데 필요한 데이터를 스스로 얻기 위해 무엇을 해야 하는지 알려줘야 한다. 이제 내 첫 반응은 "작동하지 않아, 버그야, X를 안 해"가 아니라 "좋아, 이건 제대로 작동하지 않아. X, Y, Z 주변에 디버그 로깅을 추가해서 우리가 알아낼 수 있게 해줘"이다. 그렇게 하면 나선형으로 빠지는 것을 피하고 상황에서 훨씬 더 빨리 벗어날 수 있다.
안내견 비유는 꽤 적절하다. 저자가 가능하다면 몇 가지 대화 기록을 공유해 주면 좋겠다.
편집하여 추가: 내가 암시하는 '그것'은 아마도 이것일 것이다. 버그 동작을 말로 명확하게 표현하는 데 어려움이 있다면, 아마도 꽤 많은 왕복이 필요할 것이라는 것을 안다.