Claude Opus 5.5 코드 감사 체크리스트: 병합 전에 모든 발견을 검증하는 법

Claude Opus 5.5가 몇 시간 동안 저장소를 감사한 뒤 수십 개의 “고위험” 문제와 대규모 패치를 내놓을 수 있습니다. 어려운 일은 그다음입니다. 실제 결함은 무엇인지, 기존 아키텍처 의도와 충돌하는 제안은 없는지, 어떤 수정만 안전하게 병합할 수 있는지 판단해야 합니다.

이 절차에서는 모델 출력을 결론이 아니라 증거가 필요한 감사 가설로 취급합니다. 먼저 재현 가능한 기준선을 고정하고, 각 발견을 재현, 위험, 아키텍처, 수정, 회귀 테스트 게이트에 통과시킵니다.

Opus 5.5는 감사 범위를 넓히는 도구이지 병합 승인자가 아니다

넓고 오래 걸리는 감사에는 유력한 선택이지만 독립 리뷰를 대신하지는 못합니다. Anthropic은 2026년 9월 22일 발표에서 저장소 전체 마이그레이션과 감사를 Opus 5.5의 강점으로 소개하고 내부 평가와 초기 사용자의 결과를 공개했습니다. 그러나 제공업체와 일부 테스터의 결과가 당신의 저장소에서도 그대로 재현된다는 뜻은 아닙니다. Anthropic의 Opus 5.5 발표.

Kent C. Dodds는 보안, 성능, 접근성, 유지보수성, 확장성, 아키텍처, 문서, 테스트, 자동화를 포괄하는 감사 프롬프트를 공개했고, Opus 5.5가 다른 모델이 놓친 중대한 보안 문제를 찾았다고 말했습니다. 다만 게시물에는 결함의 세부 내용, 재현 절차, 통제된 비교가 없습니다. 시도할 이유는 되지만 검증을 생략할 근거는 아닙니다. 공개 게시물 보기.

따라서 목표는 경고 수를 최대화하는 것이 아니라 재현 가능하고, 등급이 매겨지며, 독립적으로 검토할 수 있는 발견을 늘리는 것입니다.

감사를 시작하기 전에 성공 조건을 실행 명령으로 정의한다

깨끗한 기준선이 없으면 이후 실패가 기존 문제인지 모델 변경의 회귀인지 구분할 수 없습니다. 현재 커밋, 실행 환경, 주요 의존성 버전, 각 명령과 종료 코드를 저장합니다.

아래 자리표시자를 프로젝트의 실제 명령으로 바꾸십시오. 적용되지 않는 게이트는 억지로 만들지 말고 “해당 없음”으로 기록합니다.

git status --short
<install-command>
<lint-command>
<type-check-command>
<unit-test-command>
<integration-test-command>
<build-command>

최소한 다음을 남깁니다.

• 커밋 SHA, 런타임, 패키지 관리자, 중요한 의존성 버전
• 정확한 명령, 작업 디렉터리, 종료 코드, 실패 요약
• 알려진 실패, 불안정한 테스트, 임시 예외
• 감사 대상 디렉터리와 생성 코드, 과거 마이그레이션, lockfile, 벤더 코드 등 수정 금지 범위
• 인증, 권한, 결제, 데이터 마이그레이션, 외부 API 계약 같은 핵심 경로

기준선이 이미 실패한다면 먼저 수정하거나 격리하거나 알려진 문제로 등록합니다. 기존 실패를 새로운 발견처럼 보이게 해서는 안 됩니다.

첫 단계에서는 “감사만 하고 파일은 수정하지 말라”고 지시한다

조사와 수정은 반드시 분리해야 합니다. 모델이 조사하면서 동시에 코드를 바꾸면 새로운 실패가 원래 코드, 첫 패치, 여러 패치의 상호작용 중 어디서 생겼는지 알기 어렵습니다.

다음을 첫 프롬프트로 사용하고 저장소별 제약을 추가하십시오.

이 저장소를 장시간 감사하라. 현재 단계에서는 조사하고 보고만 하며 파일을 수정하지 마라.

범위: <디렉터리, 서비스, 언어, 핵심 업무 흐름>
제외: <생성 파일, 외부 코드, 과거 마이그레이션, 접근할 수 없는 시스템>
기준선: <이미 실행한 명령, 종료 코드, 알려진 실패>

점검 영역:
1. 보안과 권한 경계
2. 정확성, 동시성, 트랜잭션, 오류 처리
3. 성능과 자원 사용
4. 해당되는 경우 접근성
5. 유지보수성과 확장성
6. 아키텍처와 모듈 경계
7. 문서, 테스트, 자동화의 공백

각 발견에 포함할 내용:
- 고유 ID와 짧은 제목
- 심각도와 영향 근거
- 영향받는 파일, 심볼, 정확한 줄
- 발동 조건, 기대 동작, 실제 동작
- 재현 명령 또는 최소 테스트
- 출력 요약과 종료 코드
- 오탐일 가능성에 대한 설명
- 최소 수정 방향
- 수정 후 필수 검증 명령
- 확신도: 높음, 중간, 낮음

규칙:
- 실행하지 않은 명령은 반드시 “미실행”으로 표시한다.
- 재현할 수 없는 발견은 “미검증”으로 표시한다.
- 테스트를 통과시키기 위해 삭제, 건너뛰기, 약화를 하지 않는다.
- 자격 증명, 서비스, 의존성이 없으면 중단하고 부족한 항목을 적는다.
- 각 단계가 끝날 때 상태표를 갱신하고 리뷰를 기다린다.

프롬프트만으로 규칙 준수가 보장되지는 않습니다. 터미널 기록, diff, 실제 테스트 출력을 직접 확인하십시오. 목적은 모호한 “문제일 수 있음”이 바로 수정 대기열로 넘어가지 않게 하는 것입니다.

장시간 작업을 네 개의 통제 단계로 나눈다

오래 실행한다는 이유로 범위와 권한을 무제한으로 주어서는 안 됩니다. 각 단계 끝에서 중단하고 증거를 검토한 뒤 다음 단계로 진행합니다.

1단계: 시스템 지도를 만든다

모델은 코드, 설정, 테스트, 아키텍처 문서를 읽고 진입점, 신뢰 경계, 데이터 흐름, 외부 의존성, 영향이 큰 경로를 정리합니다. 이때 버그 개수 목표를 주거나 파일을 수정하게 하지 않습니다.

2단계: 후보 발견을 만든다

각 후보는 구체적인 코드 위치와 발동 조건에 연결되어야 합니다. 위치나 조건이 없는 일반 조언은 개선 아이디어이지 결함 수에 포함하지 않습니다.

3단계: 한 번에 한 건씩 재현한다

영향이 크고 확인 비용이 낮은 항목부터 검증합니다. 한 실험에서는 한 가설만 다루고, 원시 출력과 환경 정보를 보존합니다.

4단계: 수정 계획을 만든다

재현된 결함만 계획에 포함합니다. 최소 변경, 호환성 영향, 마이그레이션 위험, 롤백, 필수 테스트를 명시하고 아키텍처 판단이 필요한 항목은 코드 소유자에게 넘깁니다.

상태는 audit-plan.md나 티켓 표로 관리할 수 있습니다.

ID	상태	위험	재현 증거	아키텍처 결정	수정 브랜치	승인자
AUD-001	재현 대기	높음	아직 없음	미검토	—	—

상태는 후보 → 재현 대기 → 재현 완료 → 아키텍처 검토 완료 → 수정 완료 → 수용의 명시적 경로로만 이동합니다. 모델의 문장이 확신에 차 있어도 증거 없이 상태를 올리지 않습니다.

위험 게이트: 심각도와 확신도를 분리한다

심각도는 가능한 피해를, 확신도는 증거의 품질을 뜻합니다. 권한 우회 가능성은 심각도가 높지만 확신도는 낮을 수 있습니다. 안정적으로 재현되는 로그 오타는 확신도가 높아도 심각도는 낮습니다.

심각도	적용 조건	수정 전 최소 증거
치명적	광범위한 권한 상승, 민감 정보 노출, 되돌릴 수 없는 손상, 핵심 서비스 중단	통제 환경 재현, 영향 범위, 담당자의 즉시 검토
높음	핵심 업무 흐름에 영향 또는 현실적인 입력으로 안정적으로 발동	최소 재현, 실패 테스트나 명령 출력, 코드 소유자 확인
중간	영향이 제한적이거나 우회책이 있고 특수 조건이 필요	반복 가능한 증거와 우선순위 결정
낮음	국소 품질, 문서, 유지보수성, 비핵심 성능	구체적 코드 근거와 회귀 위험보다 큰 이익

모델은 코드 경로를 추적할 수 있지만 데이터 민감도, 고객 약속, 허용 가능한 중단 시간, 호환성 정책을 자동으로 알지 못합니다. 사업 영향은 책임자가 판단해야 합니다.

재현 게이트: 각 발견을 “수정 전에 실패하는 검사”로 바꾼다

의심스러운 코드를 가리키는 것만으로는 부족합니다. 수정 전에는 실패하고 수정 후에는 통과하는 검사가 필요합니다. 각 발견마다 다음을 확인하십시오.

1. 어느 커밋과 환경에서 발생하는가?
2. 가장 작은 발동 입력은 무엇인가?
3. 기대 동작은 테스트, 사양, 계약, 업무 규칙 중 무엇으로 정의되는가?
4. 실제 결과와 원시 출력은 어디에 있는가?
5. 기존 테스트는 왜 놓쳤는가?
6. 합법적인 설계 선택이나 환경 차이로 설명될 수 있는가?

가장 좋은 증거는 최소 회귀 테스트입니다. 자동화가 어렵다면 결정적인 수동 절차, 기대 관찰, 정리 방법을 기록합니다. 보안 문제는 소유하거나 명시적으로 허가받은 로컬, 격리, 사전 운영 환경에서만 재현하십시오.

모델이 명령을 실행했다고 말하면 전체 명령, 작업 디렉터리, 종료 코드, 관련 출력을 확인합니다. 서술 요약만으로는 실행 증거가 아닙니다.

아키텍처 게이트: 기존 코드가 왜 그렇게 존재하는지 확인한다

더 깔끔해 보이는 구현이 호환성, 배포 순서, 의도된 경계를 깨뜨릴 수 있습니다. 넓은 리팩터링을 수용하기 전에 ADR, 설계 문서, API 계약, 마이그레이션 제약, 관련 이력을 확인합니다.

Git 이력을 사용할 수 있다면 다음을 보조 도구로 쓸 수 있습니다.

git log -- <path>
git blame -L <start>,<end> <file>
git show <commit> -- <path>

그리고 다음에 답하게 합니다.

• 현재 설계는 어떤 제약을 지키는가?
• 어떤 호출자, 데이터 형식, 배포 단계가 여기에 의존하는가?
• 제안은 결함 수정인가, 제품 동작 변경인가?
• 더 작은 국소 변경으로 해결할 수 있는가?
• 롤백 시 코드, 설정, 데이터 중 무엇을 복원해야 하는가?

이력은 단서이지 의도의 완전한 기록이 아닙니다. 근거가 없으면 “아키텍처 의도 미상”으로 표시하고 유지보수 담당자에게 묻습니다.

수정 게이트: 재현된 한 결함에 작은 패치 하나

서로 무관한 여러 발견을 묶은 대형 패치를 수용하지 마십시오. 먼저 이전 코드에서 안정적으로 실패하는 테스트를 추가하고, 그다음 가장 작은 수정만 적용합니다.

게이트	요구사항	실패 시 조치
범위	diff가 승인된 발견만 다룸	무관한 변경 분리
회귀 테스트	수정 전 실패, 수정 후 성공	테스트 수정 또는 발견 재평가
정적 검사	포맷, Lint, 타입 검사가 통과	광범위한 예외로 새 오류를 숨기지 않음
프로젝트 검사	관련 Unit, Integration, Build 통과	다음 패치 전에 첫 새 실패 조사
아키텍처	소유자가 경계와 호환성 승인	범위 축소 또는 설계 리뷰
사람의 diff 리뷰	오류 처리, 권한, 데이터 변경, 삭제 확인	의심스러운 변경마다 설명

assert 삭제, 테스트 스킵, 예외 삼키기, 검증 약화, 경합을 숨기기 위한 재시도 증가, 원래 결함을 추적하기 어렵게 만드는 대규모 리팩터링은 가짜 성공으로 거부합니다.

회귀 게이트: 모델이 고른 검사만이 아니라 프로젝트 표준을 실행한다

최종 수용은 기존 스크립트나 CI로 판단합니다. 감사 전 전체 기준선과 수정 후 결과를 비교하고 새 회귀 테스트가 패치 없는 버전에서 실제로 실패하는지 확인합니다.

lockfile, 데이터베이스 마이그레이션, 공개 API, 설정 기본값의 의도치 않은 변화도 검토합니다. 성능 주장은 동일 환경과 입력의 전후 비교가 필요합니다. 불안정한 테스트는 녹색이 나올 때까지 재실행하지 말고, 실패 양상을 기록하고 패치가 불안정성을 키웠는지 확인합니다.

다음 신호 중 하나라도 있으면 결과를 거부한다

• 정확한 코드 위치, 발동 조건, 검토 가능한 증거가 없음
• 실행하지 않은 명령을 통과했다고 보고함
• 심각도에 구체적인 영향 경로가 없음
• 패치가 승인 범위를 넘거나 허가 없이 아키텍처를 바꿈
• 테스트를 삭제, 건너뛰기, 약화하거나 오류를 숨김
• 담당자 승인 없이 ADR, 계약, 마이그레이션 정책과 충돌함
• 최종 요약만 있고 명령과 검토 가능한 diff가 없음
• 보안 주장의 근거가 다른 모델의 동의뿐임

두 번째 모델은 반례 탐색에는 도움이 되지만 모델 합의는 독립 증거가 아닙니다. 독립 검증은 테스트, 실행 출력, 이력, 사양, 책임 있는 사람의 판단에서 나옵니다.

병합 전 최종 체크리스트

• 범위, 제외 항목, 기준 커밋을 고정했다.
• 기준선 명령과 종료 코드를 보관했다.
• 수용할 모든 발견에 ID와 정확한 코드 위치가 있다.
• 심각도와 확신도를 별도로 기록했다.
• 테스트 또는 결정적 절차로 결함을 재현했다.
• 아키텍처 의도, 호환성, 롤백을 검토했다.
• 한 발견이 작고 검토 가능한 한 패치에 대응한다.
• 회귀 테스트가 수정 전 실패하고 수정 후 통과한다.
• 기존 스크립트나 CI로 전체 게이트를 실행했다.
• 코드 소유자가 최종 diff를 검토하고 명시적으로 승인했다.

공개된 정보는 Opus 5.5가 넓고 오래 걸리는 코드 감사를 시도할 만한 모델이며 다른 검토에서 놓친 문제를 드러낼 가능성이 있음을 보여 줍니다. 그렇다고 검증이 필요 없어지는 것은 아닙니다. 가장 작은 다음 단계는 즉시 편집 권한을 주는 것이 아니라, 깨끗한 기준선을 저장하고 “감사만, 변경 없음” 단계부터 시작하는 것입니다.