코드 생성에선 클로드가 더 빠르고, 내가 보기엔 클로드가 더 철저한 테스트를 수행해서 더 오래 걸리는 것처럼 보이는 듯?
예를 들어 방금 2FA 포함 로그인을 만들었는데, 아스트라 6 울트라로 버그 체크하는 데 6분 걸렸고 아무것도 못 찾았음. 오퍼스 5.5는 엄청 오래 걸렸는데 테스트가 끝날 때까지 기다린 거였음. AI가 생성한 상세 요약은 아래와 같음:
|M1 인증 브랜치(m1-auth) 검토: 두 에이전트, 동일 요청
두 에이전트 모두 요청은 동일했음: 첫 번째 프롬프트 변경 사항의 로직이 정확하고 버그가 없는지 확인.
첫 번째 에이전트의 1차 패스 (약 5분)
- diff를 읽고 기존 체크 실행: npm test (84 .NET, 21 프론트엔드, 12 게이트), lint, 빌드, compliance:check, publish:iis.
- 버그 없음 보고. 유일하게 찾은 건 교체된 Identity 보안 스탬프 검증기였는데, 이건 이미 의도적으로 변경된 사항이었음.
- 브라우저에서 애플리케이션을 열어보지는 않음.
클로드의 패스
- 프롬프트에 맞춰 백엔드와 프론트엔드 전체를 읽고 동일한 테스트 스위트, lint, 빌드 및 종속성 검토 실행.
- 테스트가 알아채는지 확인하려고 저장소 외부 복사본에서 보안 코드를 32가지 방식으로 의도적으로 망가뜨림. 28개를 잡아냄. 살아남은 4개 중 2개는 실제 테스트 공백이었음: 복구 코드 재생성에서 TOTP 체크가 제거되었을 때나, 감사 작성기에서 트랜잭션 가드가 제거되었을 때 아무것도 실패하지 않음.
- 스위트가 다루지 않는 시나리오(잠금 만료, 한 세션 내 동시 비밀번호 변경, MFA 재등록, 유휴 시간 초과 후 로그인)에 대해 실제 SQL 서버를 대상으로 10개의 추가 테스트 작성.
- 실제 브라우저에서 create-admin부터 강제 비밀번호 변경, MFA 설정, 복구 코드 로그인, MFA 비활성화까지 애플리케이션을 직접 구동함. 그 과정에서 실제 버그 하나를 발견함: 계정 페이지의 두 입력창이 id="code"를 공유해서, "MFA 비활성화" 아래의 라벨이 다른 폼의 필드를 가리키고 있었음.
- M2 전에 결정이 필요한 설계상 동작 4가지를 나열함 (인증기 분실, 세션만 일시 중단하는 비활성화 동작, 라이브 세션의 비밀번호 변경을 차단하는 잠금, 전체 신원과 역할을 포함하는 MFA 챌린지 쿠키).
두 번째 에이전트의 2차 패스
- 클로드의 보고서를 바탕으로 버그와 테스트 공백 2개를 독립적으로 재현하고 확인.
- 올바른 수정 사항 2개 추가: 모든 거부가 잠금으로 이어지지는 않아야 하며, 비활성화 동작을 조건 없이 프롬프트 준수라고 불러서는 안 됨.
- 수정 사항 구현: 폼 이름, 테스트 케이스 4개, 문서화.
수정 사항에 대한 클로드의 검증
- 살아남은 2개의 변형과 더 미묘한 3번째 변형(코드 형식만 체크)을 재실행; 3개 모두 이제는 잡아냄.
- 브라우저에서 ID가 고유하고 각 라벨이 자신의 필드에 집중하는지 확인.
