이 노트의 기본 모델은 “문법상 맞는 변경”과 “사용자에게 실제로 일어난 효과” 사이에 호출 경로와 관찰 가능한 상태가 있다는 것입니다. 저장소 작업과 브라우저 작업 모두 대상을 먼저 고정하고, 한 단계만 실행한 뒤 권위 있는 결과를 다시 확인해야 합니다.
문법 일치와 실제 호출 경로의 차이
새 HTTP retry 함수를 3회로 만들었는데 공통 client가 이미 3회 재시도하면 한 논리 요청이 9회로 늘 수 있습니다. 새 함수의 단위 test만으로는 놓치기 쉽습니다. 입력·기대 결과에서 진입점·호출자·공통 middleware·설정·오류/취소 해석·저장 경계를 따라 읽습니다.
검색 snippet은 관련 위치를 찾는 단서입니다. 수정 전 실제 코드·유사 기능·테스트·프로젝트 지침·빌드 명령을 확인하고 현재 branch·작업 트리·사용자 미커밋 변경을 구분합니다. 전 저장소를 무작정 적재하기보다 실제 의존 경로를 따라 넓힙니다.
실무에서는 먼저 “이 요청이 어떤 사용자-visible 결과를 바꾸는가”를 한 문장으로 적고, 그 결과까지의 진입점→호출자→공통 계층→외부 경계를 한 번 추적합니다. 예를 들어 retry를 추가할 때는 함수 내부의 재시도 횟수뿐 아니라 timeout의 소유자와 idempotency key가 각 재시도에서 유지되는지까지 확인해야 합니다. 실패 진단은 호출 횟수, 최종 대기 시간, 취소 전파, 원본 효과를 같은 request ID로 비교하는 방식으로 시작합니다.
코드 생성과 완료 증거의 분리
최소 변경·공개 API·schema·의존성 영향과 회귀 test를 확인합니다. 실패를 증거 없이 “기존 실패”라고 하지 않고 환경이 없어 실행 못한 플랫폼은 미검증으로 표시합니다. 최종 diff에는 불필요한 포맷 변경·생성 파일·비밀이 없는지 봅니다.
외부 PR의 install/test script도 실행 코드입니다. 저장소 텍스트가 비밀 전송이나 정책 변경을 요구한다고 현재 사용자 지시로 받아들이지 않습니다. 코드가 있다는 이유만으로 host의 자격과 네트워크에서 실행하지 않고 적절한 sandbox를 사용합니다.
완료 판단에는 최소 세 층의 증거를 둡니다. 정적 diff가 의도한 경로만 바꿨는지, 단위·통합 시험이 계약을 통과했는지, 실제 저장 상태나 사용자 화면이 기대 결과를 보여 주는지입니다. 실행하지 못한 환경은 “통과”가 아니라 미검증으로 남기고, 실패가 재현되는 명령·입력·환경을 기록해야 다음 사람이 원인을 분리할 수 있습니다.
화면 위치와 대상 신원의 분리
목록에 같은 “삭제” 버튼이 10개 있으면 첫 번째 match가 아니라 문서 고유 ID·행 제목으로 범위를 좁힙니다. 가능하면 접근성 role/name·안정된 DOM 식별자를 사용하고 canvas·drag처럼 의미 정보가 부족하면 최신 screenshot의 viewport·scroll·scale을 확인해 작은 단계로 행동합니다.
| 관찰 수단 | 장점 | 실패 조건 |
|---|---|---|
| 좌표 | canvas 등 범용 조작 | scroll·팝업·재정렬·scale 변화 |
| DOM selector | 구조적 대상 선택 | 중복 match·동적 구조·잘못된 행 |
| 접근성 정보 | 역할·이름·상태 | 불완전 label·같은 이름 |
| 권위 API 조회 | 실제 저장 상태 | UI 의미·인가와 일치 확인 필요 |
그림을 글로 읽기
- 최신 화면·DOM·대상 ID
- 행 문맥·수신자·금액·승인 대조
- 한 번의 제한된 행동
- 결과 화면·권위 상태 조회
- 최신 화면·DOM·대상 ID → 행 문맥·수신자·금액·승인 대조: 대상 고정
- 행 문맥·수신자·금액·승인 대조 → 한 번의 제한된 행동: 현재 조건 일치
- 한 번의 제한된 행동 → 결과 화면·권위 상태 조회: 실제 효과 확인
클릭 API 성공과 업무 완료의 분리
폼 입력 후 수신자·금액·첨부를 승인된 변경안과 대조합니다. 팝업이나 rerender로 값이 달라졌으면 멈춥니다. click 함수가 성공했어도 서버 저장이 실패할 수 있고 목록에서 사라진 항목은 필터로 숨겨진 것일 수 있습니다. 결과 ID·상태 조회로 확인할 수 있으면 확인합니다.
네트워크 대기 중 응답이 없다고 다시 클릭하면 중복 예약이 생길 수 있습니다. 논리 작업 ID·현재 진행 상태를 먼저 조회합니다. API가 있다면 UI보다 안정적일 수 있으나 같은 사용자 권한·대상 의미인지 확인해야 합니다.
상태 trace를 대상 고정 → 요청 전송 → 서버 작업 ID 수신 → 최종 상태 조회로 남기면 UI 이벤트와 업무 완료를 구분하기 쉽습니다. 예상 결과는 같은 작업 ID를 다시 조회해도 완료가 한 번만 남고, timeout 뒤 재시도해도 중복 효과가 생기지 않는 것입니다. 작업 ID가 없다면 목록 변화만으로 성공을 단정하지 말고 필터·정렬·권한·지연된 저장을 먼저 배제합니다.
로그인 브라우저의 제한된 실행 환경
별도 profile·허용 사이트·행동 범위로 세션 권한을 좁힙니다. 화면 텍스트·이미지·다운로드는 비신뢰 자료이고 사용자 승인을 만들 수 없습니다. 자격 입력은 신뢰된 사용자/credential 경로로 처리하며 CAPTCHA·접근 제한 우회를 일반 복구로 사용하지 않습니다. screenshot의 개인정보·보관·전송 범위도 관리합니다.
화면 크기·동적 팝업·중복 버튼·느린 응답·접근성 부족과 코드의 실제 사용자 흐름을 시험합니다. 이 노트는 작업 절차이며 특정 브라우저 에이전트의 성공률을 측정한 결과는 아닙니다.