이 영상에서 단테는 검색 결과가 없을 때 안내 문구가 나오지 않는 버그를 코딩 에이전트에게 맡기고, 에이전트가 문제를 재현하고 고치고 검증하는 과정을 처음부터 끝까지 보여 줍니다. 방법의 출발점은 리액트 컴파일러 개발에 참여한 개발자가 강연에서 강조한 "에이전트를 믿을 수 있게 만드는 검증"입니다. 에이전트에게 일을 맡길 때마다 결과 확인에 시간을 쓰고 있다면 참고할 만한 내용입니다.
사람이 병목이 되지 않게 하기
강연의 핵심 주장은 이렇습니다. 사람이 매번 앱을 열어 오류를 대신 확인하면 결국 사람이 병목이 됩니다. 에이전트가 어디로 가서 무엇을 확인해야 하는지 알려 주고, 결과를 스스로 관찰할 수 있게 만들어야 합니다.
그래서 단테는 작업 전에 "기능 지도" 역할을 하는 문서를 하나 준비했습니다. 여기에는 다음 내용이 들어갑니다.
- 앱을 실행하는 명령과 접속 주소
- 검색창을 찾을 때 쓰는 이름
- 사용자 행동과 기대 결과를 연결한 시나리오
시나리오는 네 줄입니다. 처음에는 항목이 세 개 보인다. "리액트"를 검색하면 한 개가 남는다. "우주 고양이"처럼 없는 단어를 검색하면 0개와 함께 안내 문구가 보인다. 입력을 지우면 다시 세 개가 된다. 이 네 줄이 그대로 작업의 완료 기준이 됩니다.
첫 요청: 고치지 말고 재현부터
첫 요청에서는 아직 코드를 고치지 말라고 했습니다. 문서를 읽고, 브라우저에서 문제를 재현하고, 기대 동작과 실제 동작을 비교해 달라는 요청입니다.
에이전트는 파일을 읽고 서버를 실행했습니다. 중간에 브라우저 제어 스크립트가 실패했는데, 성공했다고 넘어가지 않고 다시 시도했습니다. 이후 화면을 띄우지 않고 실제 브라우저를 실행하는 헤드리스 방식으로 검증을 이어 갔습니다.
결과적으로 검색 결과가 0개인 상황을 확인했고, 안내 문구가 문서 안에 존재하지만 숨겨져 있다는 사실도 찾아냈습니다. 원인은 표시 조건이었습니다. 검색으로 걸러진 결과의 개수가 아니라 원본 목록의 개수를 보고 있었던 것입니다. 원본 목록에는 언제나 세 항목이 있으니 안내 문구가 계속 숨겨졌습니다. 관찰한 실패와 코드의 원인을 이렇게 연결해 두면 수정 범위도 작아집니다.
두 번째 요청: 최소 변경과 같은 시나리오 재검사
다음으로 최소 변경으로 수정하고, 같은 네 가지 시나리오를 다시 검사해 달라고 요청했습니다. 에이전트는 원본 목록을 뜻하는 items를 필터 결과인 visible로 바꿨고, 변경은 한 줄이었습니다. 단테는 코드가 짧다는 사실보다, 이 변경이 처음 확인한 실패를 해결하는지가 중요하다고 강조합니다.
수정된 앱에서 같은 단어를 검색하자 안내 문구가 나타났습니다. 에이전트의 브라우저 검사에서도 첫 화면, 정상 검색, 결과 없는 검색, 입력 초기화가 모두 통과했습니다. 에이전트는 "통과했다"는 말만 남긴 것이 아니라 목록 개수, 안내 문구 표시 상태, 스크린샷을 함께 남겼습니다. 나중에 문제가 다시 생겼을 때 비교할 근거가 됩니다.
pstack과 다음 단계
강연자가 공개한 pstack은 작업 순서와 검증 방법을 담은 스킬 묶음입니다. 이번 촬영은 pstack을 쓰지 않고 기능 지도와 검증 기준을 에이전트에 직접 전달해 진행했으며, pstack까지 적용하려면 공식 가이드의 플러그인 추가와 설정 순서를 따르면 된다고 안내합니다.
단테가 제안하는 습관은 간단합니다. 다음 작업에서는 무엇을 고칠지만 적지 말고, 어디에서 어떻게 확인할지도 함께 적습니다. 여러 에이전트에게 일을 나누는 것은 이렇게 작은 작업 하나를 끝까지 검증할 수 있게 만든 다음에 해도 늦지 않습니다.
정리
- 에이전트에게 앱 실행 방법, 접속 주소, 확인할 요소를 담은 기능 지도를 먼저 줍니다.
- 사용자 행동과 기대 결과를 짝지은 시나리오를 완료 기준으로 씁니다.
- 첫 요청은 수정이 아니라 재현과 원인 파악으로 제한합니다.
- 수정 후에는 같은 시나리오로 다시 검사하고, 개수·표시 상태·스크린샷 같은 근거를 남기게 합니다.