에이전트가 생성한 풀 리퀘스트에서 신뢰하고 되돌리고 테스트해야 할 것

어떤 에이전트가 요약(summarization) 엔드포인트를 추가하는 풀 리퀘스트를 열었다고 가정해 봅시다. CI는 성공했습니다. 이 diff는 공유 설정 로더와 인증 미들웨어 파일 하나도 수정합니다.

이것은 극적인 경우는 아니며, 일반적인 경우입니다. 에이전트가 작성한 PR은 구문(syntax)에서 리뷰에 실패하는 경우가 거의 없습니다. 범위(scope)에서 실패합니다.

본 기사는 세 가지 버킷별 분류 방법과 재현 가능한 감사 스크립트를 제공합니다. 목표는 두 번째 엔지니어가 다시 실행할 수 있는 리뷰 판결을 내리는 것입니다.

Green CI가 증명하는 것은 컴파일만, 의도는 아니다

성공적인 파이프라인은 한 가지 질문에 답합니다. 코드가 빌드되고 기존 테스트를 통과하는가?

그것은 변경 사항이 이 PR에 속하는지 여부를 알려주지 않습니다. 공유 기본값이 표류했는지(drifted)도 알려주지 않습니다. 배지를 바닥(floor)으로 취급하고, 결코 증거로 간주하지 마십시오.

에이전트는 명시된 작업에 대해 최적화합니다. 그 작업과 인접한 모든 것은 에이전트에게 공략하기 쉬운 표적처럼 보입니다. 설정 로더, CI 워크플로우, 미들웨어는 거의 모든 기능 옆에 위치합니다.

1단계 — diff를 세 가지 버킷으로 분류하라

로직을 읽기 전에, 모든 hunk(변경 블록)를 분류하십시오. 이 버킷이 해당 hunk가 얼마나 많은 주의를 받을지 결정합니다.

비대칭성이 중요합니다. 잘못된 신뢰 hunk는 되돌림(revert) 비용을 발생시킵니다. 잘못된 되돌림 hunk는 사고(incident) 비용을 발생시킵니다.

2단계 — 스크립트로 폭발 반경 측정하기

첫 번째 산출물은 범위 감사입니다. 이것은 설명이 아닌 diff를 읽습니다.

#!/usr/bin/env python3
""diff_scope.py - 명시된 범위를 벗어나는 PR 변경 사항을 플래그 지정합니다."" 
import fnmatch
...

PR 브랜치에 대해 실행하십시오:

python diff_scope.py origin/main

솔직한 주의사항이 하나 있습니다. fnmatch는 슬래시를 가로질러 *를 탐욕적(greedy)으로 처리합니다. 이 목록은 의도적으로 과매칭됩니다. 리뷰 보조 도구는 조용한 누락(silent misses)이 아니라 거짓 양성(false positives)을 생성해야 합니다.

3단계 — 버그를 숨기는 세 가지 hunk 모양에 대해 grep하기

경로 필터는 범위 내 파일 내부의 로직 편집 사항을 놓칩니다. 세 가지 모양은 목표 지향적인 grep을 받을 자격이 있습니다.

git diff -U0 origin/main...HEAD -- '.py'
| grep -nE '^⬜.(except Exception|except:|= None|os.environ|default=)'

모든 히트(hit)를 검토하세요. 처리된 예외(Swallowed exceptions)는 500 에러를 빈 본문(empty body)을 가진 200으로 바꿉니다. 변경된 기본값(Changed defaults)은 새로운 호출자뿐만 아니라 모든 호출자의 동작을 변경합니다. 새로운 os.environ 읽기는 PR 설명에 누락되었을 가능성이 있는 배포 요구 사항을 추가합니다.

4단계 — 로직 검토 전에 범위 이탈(scope creep) 되돌리기

먼저 되돌리고, 나중에 검토하세요. 오염된 diff 내부에서 로직을 읽는 것은 주의력을 낭비합니다.

PR이 건드리지 않았어야 할 파일의 경우 파일 레벨 복원(file-level restore)을 사용하세요:

git checkout origin/main -- app/config/defaults.py .github/workflows/ci.yml
git commit -m "revert: out-of-scope changes, split into follow-up PRs"

그런 다음 축소된 diff로 CI를 다시 실행하세요. 기능이 여전히 통과한다면, 되돌린 파일들은 실제로 관련 없는 것이었습니다. 만약 실패한다면, 에이전트가 당신이 이제 알게 된 숨겨진 종속성(hidden dependency)을 가지고 있었다는 의미입니다.

그 실패가 유용한 결과물입니다. 그것은 눈에 보이지 않던 결합도(coupling)를 검토 가능한 결정으로 바꿉니다.

5단계 — 계약(contract) 테스트 후, 실패 경로 테스트하기

테스트 세트에는 최소 두 가지 테스트가 필요합니다. 행복한 계약(happy contract)을 위한 것 하나와 에이전트가 보통 잊는 실패를 위한 것 하나입니다.

# tests/test_summarize_contract.py - 스케치; 앱에 맞게 임포트를 조정하세요.
from fastapi.testclient import TestClient
from app.main import app
...

두 번째 단언(assertion)은 특정 실패를 포착합니다. 전역 오류 핸들러(global error handler)를 추가하는 에이전트는 종종 예외 텍스트를 클라이언트에게 유출시킵니다. 이것은 조용한 정보 공개(quiet information disclosure)이며, 녹색 상태로 배포됩니다.

새로운 테스트만 먼저 실행하세요:

pytest tests/test_summarize_contract.py -q

되돌리기 전의 diff에 대해 통과한다면, 되돌린 후에 다시 실행하세요. 순서가 중요합니다.

6단계 — PR에 판결(verdict) 기록하기

채팅 스레드에 존재하는 판결은 검토할 수 없습니다. 다음 독자가 볼 곳에 작성하세요.

## Review verdict
- Files outside stated scope: app/config/defaults.py, .github/workflows/ci.yml
- Reverted: both, moving to follow-up PRs
...

가장 마지막 줄이 가장 중요합니다. 리뷰는 확인되지 않은 것을 명시하고, 침묵은 커버리지로 간주됩니다.

무료 모델 접근의 활용 방안

대규모 diff를 처음 검토하는 것은 기계적인 작업입니다. 모델에게 의심스러운 덩어리(hunks) 목록을 작성하도록 요청한 다음, 각각을 수동으로 확인하십시오.

MonkeyCode는 운영자(operator)에 따라 무료 모델 접근과 무료 서버 옵션을 제공합니다. 이 조합은 다음과 같은 좁은 작업에 적합합니다: 후보 목록을 반환하는 상태 비저장형 프롬프트(stateless prompt)입니다. 리뷰어는 모든 결정을 유지하고, 스크립트가 진실의 원천으로 남습니다.

공개 고지: 이 기사는 MonkeyCode의 제품 홍보의 일환으로 작성되었습니다.

프롬프트는 작게 유지하십시오. diff와 명시된 작업(stated task), 그리고 민감 경로 목록을 붙여넣으십시오. 파일명과 줄 번호가 포함된, 해당 목록과 일치하는 덩어리들을 요청하십시오. git diff에서 확인할 수 없는 답변은 무시하십시오.

제한 사항 및 사용하지 말아야 할 경우

이 워크플로우는 파일 경로(file-path) 기반입니다. 범위 내 파일 내부의 미묘한 논리 변경을 볼 수는 없으며, 테스트 스위트 실행을 대체하는 일은 결코 없습니다. 단일 파일 에이전트 PR도 범위 감사(scope audit)를 통과할 수 있지만 여전히 틀릴 수 있습니다.

또한 이 감사는 안정적인 origin/main을 가정합니다. 리베이스(rebase)가 많은 브랜치는 ...HEAD 비교를 복잡하게 만듭니다.

다음 세 가지 경우에 이 접근 방식을 건너뛰십시오. 핀 고정되고 감사된 모델 버전이 필요한 팀은 diff를 어떤 호스팅 엔드포인트에도 붙여넣어서는 안 됩니다. 엄격한 데이터 거주지 규칙(data-residency rules)을 가진 팀은 diff를 로컬로 유지해야 합니다. 촉박한 마감 기한에 있는 팀은 전체 모델 지원 검사를 시도하기보다는 공격적으로 롤백(revert)해야 합니다.

무료 등급 이용 가능 여부와 할당량(quotas)은 예고 없이 변경될 수 있습니다. 파이프라인에서 의존하기 전에 현재 제한 사항을 확인하십시오.

핵심 요약

기계적인 것은 신뢰하고, 인접한 것을 롤백하며, 실패를 테스트하십시오. 이 순서는 모델 업그레이드와 도구 변경(tool churn) 속에서도 살아남습니다.

스크립트는 30줄입니다. 판정 템플릿은 5개입니다. 둘 다 아무도 읽지 않은 설정 기본값 때문에 발생하는 하나의 사고보다 저렴합니다.

모델 지원 첫 검사를 시도하고 싶은 독자들은 무료 모델 접근과 무료 서버 옵션으로 시작한 다음, 모든 플래그를 원본 diff와 대조하여 확인해 볼 수 있습니다.