에이전트가 버그를 수정하는 모습을 본 적이 있다면, 그게 추측에 불과하다는 걸 알게 될 겁니다. 코드를 읽고, 이론을 세우고, 수정하고, 기대하죠. 가끔은 맞기도 하지만, 대부분은 자신감 넘치는 수정처럼 보이면서 실제 버그는 숨겨져 있는 경우가 많습니다.
이를 위해 우리가 만든 것이 바로 Debug Mode 입니다. 에이전트가 코드에 대해 추론하며 앉아 있는 대신, 실행될 때 코드가 무엇을 하는지에 대한 증거를 찾으러 갑니다.
루프는 이렇습니다.
- 에이전트가 여러 가설을 세우고, 가장 가능성 있는 것부터 작업을 시작합니다.
- 그런 다음, 구현을 건드리지 않고 하나의 가설을 테스트하기 위해 로깅을 추가합니다.
- 작은 디버그 서버가 프로그램이 실행되는 동안 런타임 출력을 .cursor/debug.log 에 수집합니다.
- 버그를 재현하면, 에이전트는 이제 로그를 읽고 추측하는 대신 무슨 일이 일어났는지 이해할 수 있습니다.
- Cursor 가 로그에서 근본 원인을 찾아 수정하고, 추가했던 로깅을 제거합니다.
실제 버그에 적용한 예시를 약 1분으로 압축했습니다:
팀이 사용하는 방법
내부적으로 Debug Mode 로 해결한 몇 가지 흥미로운 사례입니다:
- 20번 중 1번 발생하는 경쟁 조건(race condition)이었습니다. 최적의 N개를 선택하는 실행에서 git 메타데이터를 손상시키고 있었는데, Debug Mode 가 1시간 안에 원인을 찾아냈습니다.
- 메모리 누수로, 한 번의 추적으로 추적되었습니다. 프론트엔드 프레임워크를 잘못 사용한 것이 원인이었고, 수정은 단 한 줄이었습니다.
- C++ 깊숙한 곳에서 발생한 네이티브 크래시였습니다. 사람들이 보통 우회하는 Electron 크래시였지만, 로그 덕분에 찾을 수 있었습니다.
- 포기했던 SSR 깜빡임 문제였습니다. 아무도 건드리려 하지 않던 렌더링 버그였지만, 에이전트가 페이지가 런타임에 무엇을 하는지 볼 수 있게 되면서 수정되었습니다.
Shift+Tab 으로 시도해보세요 (CLI 에서도 /debug 를 통해 사용할 수 있습니다).
분명 사용자분들께서 제가 생각하지 못한 방식으로 활용하고 계실 거라 확신합니다. 그러니 알려주세요!
