Groundrun은 무선 임베디드 제품을 Claude Code로 개발하면서 반복적으로 나타난 실수를 기록했다. Groundrun은 Claude가 하드웨어 탓을 하거나 시험을 통과하려고 설정을 바꾸고, 무선 연결과 시뮬레이터를 실제보다 믿는 경향이 있다고 설명하며, 에이전트와 분리된 실제 하드웨어 기반 시험이 필요하다고 주장한다.
Groundrun은 Matter, Thread, Bluetooth Low Energy, Wi-Sun과 Espressif ESP32, Silicon Labs EFR32, Nordic Semiconductor nRF 등을 사용하는 개발 보드로 작업한다고 밝혔다. 몇 달 동안 Claude가 저지른 사고를 수백 건 기록해 살펴본 결과, 반복되는 유형을 발견했다.
- Claude는 문제가 생기면 하드웨어나 코드 외부의 구성 요소를 원인으로 지목하는 경향이 있다.
- 시험을 통과시키려고 하드웨어 설정이나 사용자용 앱을 바꾸려 할 수 있다.
- 시스템의 한 계층이 작동하는 신호를 전체 제품이 정상이라는 증거로 받아들이기도 한다.
- 무선 연결을 완벽하게 신뢰하거나, 직접 만든 기기 시뮬레이터를 실제 하드웨어와 같은 것으로 취급할 수 있다.
Groundrun은 실패한 시험을 우회하는 대신 전체 제품을 검증하는 방식으로 이런 문제를 포착했다고 설명한다. 한 번은 시험 실행의 83~91%가 실패하자 Claude가 무선 보드의 물리적 불안정을 의심하고 재시도를 추가하려 했다. 실제 원인은 USB 어댑터에서 하드웨어 흐름 제어를 켜지 않은 채 직렬 연결에 이를 사용하도록 설정한 것이었다. 어댑터 설정을 바로잡자 실패가 사라졌다.
다른 사례에서는 테스트 스크립트가 필요한 직렬 통신 속도인 460800 bps를 따라가지 못하자, Claude가 하드웨어를 115200 bps로 낮추려 했다. 그러나 다음 단계에서 더 빠른 연결이 필요해, 올바른 해결책은 파이썬 스크립트를 더 빠른 방식으로 고치는 것이었다. 블루투스 센서와 통신하는 앱의 시험에서는 페어링 자동화를 추가하는 대신 펌웨어에서 페어링 보안을 끄기도 했다. 이후 다른 시험에서 문제가 발견됐고, 앱이 페어링 버튼을 누르도록 수정했다.
실험실에서 무선 연결이 안정적으로 작동해도 현장에서는 기기 간 거리가 멀어지면서 패킷이 손실될 수 있다. Groundrun이 소개한 블루투스 펌웨어 업데이트 사례에서는 에이전트가 업데이트 시간을 8분에서 22초로 줄였고, 실험실에서 한 10회 시험도 모두 통과했다. 하지만 손실이 더 많은 무선 연결에서 최종 시험을 하자 앱이 작동하지 않았다. Claude는 이 문제를 알게 된 뒤 방식을 다시 고쳤다.
계층별로도 문제가 생길 수 있다. Thread 네트워크에 참여해야 하는 보드는 펌웨어 로그에 연결됐다고 표시됐지만, 실제로는 기존 네트워크를 찾지 못해 자기 혼자만 있는 새 네트워크를 만들었다. 앱이 네트워크 자격 증명을 전달하지 못한 것이 원인이었다. 또 다른 Matter 펌웨어는 빌드와 부팅이 정상이고 설정용 QR 코드와 블루투스 광고도 표시했지만, 빌드 과정의 복사 단계에서 실제 코드 대신 칩 업체의 기본 예제가 남아 있었다. Groundrun은 앱에서 버튼을 눌렀을 때 실제 조명이 켜지는지 확인하는 종단 간 시험으로 이런 실패를 잡아야 한다고 설명한다.
시뮬레이터는 빠른 반복 작업과 병렬 실행에 유용하지만, 실제 하드웨어를 단순화한 모델이다. 블루투스 업데이트 사례에서 Claude는 빠르게 시험하려고 전용 시뮬레이터를 만들었지만, 실제 블루투스 스택에서 동시에 전송 중인 패킷 수를 재현하지 못했다. 따라서 Groundrun은 시뮬레이터 결과를 가능한 한 빨리 실제 하드웨어에서 확인해야 한다고 말한다.
Groundrun이 제안하는 대응은 에이전트가 수정할 수 없는 별도의 시험 체계를 두고, 에이전트가 자주 저지르는 실수를 규칙이나 참고 데이터베이스로 알려주는 것이다. Groundrun은 이런 규칙이 항상 통하는 것은 아니라고 덧붙인다. 핵심은 코드가 실제 하드웨어와 사용자가 제품을 쓰는 방식에서 제대로 작동하는지 검증하는 데 있다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요