찾아낼 것:
- 서로 경쟁하는 여러 개의 진실 공급원(source of truth).
- 정의되지 않은 우선순위 규칙.
- 상위 수준의 요구사항을 무시하는 로컬 코드.
- 구식 동작을 그대로 담고 있는 테스트.
- 의미론을 조용히 바꿔버리는 설정.
- 강제력 없이 권한만 주장하는 문서.
- 필수 관문을 우회하는 런타임 경로.
- 실패 시 명확히 드러나야 하는데도 그냥 뚫려버리는(fail-open) 동작.
명확한 권한 순서, 충돌 해결 규칙, 강제 지점, 그리고 의도한 계층 구조를 기계적으로 강제할 수 있는 회귀 테스트를 만들어라. GitHub는 쓰지 마라. ```
## 7. 테스트 로직 및 커버리지 감사
```text 첨부된 테스트 스위트를 단순히 테스트 개수나 통과 여부가 아니라, 동작의 정확성 측면에서 감사해라.
확인할 것:
- 각 테스트가 어떤 요구사항을 증명하는지.
- 테스트가 프로덕션 코드를 직접 돌리는지, 아니면 대역(substitute)을 쓰는지.
- 단언문(assertion)이 의미 있는 결과를 검증하는지.
- 모의 객체(mock)가 통합 실패를 숨기고 있지는 않은지.
- 부정 케이스, 경계값, 중단, 재시도, 복구 케이스가 존재하는지.
- 결정론적 동작이 테스트되는지.
- 예상된 실패와 인프라 실패가 구분되는지.
- 실제 시스템은 박살 났는데 테스트만 통과하는 상황은 없는지.
요구사항, 현재 커버리지, 취약점, 누락된 테스트, 필요한 픽스처, 정확한 단언문, 수락 기준을 포함한 테스트 갭 매트릭스를 만들어라. GitHub는 쓰지 마라. ```
## 8. 실패 근본 원인 감사
```text 첨부된 실패 사례, 로그, 테스트 결과, 시도된 수정 사항을 분석해라. 코드 변경을 권장하기 전에 실행 단위별 근본 원인 매트릭스를 작성해라.
모든 실패에 대해 다음을 기록해라:
- 실행 또는 아티팩트 식별자.
- 정확히 실패한 명령어, 작업, 또는 단계.
- 최종적으로 전파된 오류가 아닌, 첫 번째 원인 오류.
- 입력값 및 환경.
- 실패가 결정론적인지 여부.
- 제품 결함, 테스트 결함, 데이터 결함, 설정 결함, 인프라 문제, 보고 결함 중 무엇인지.
- 이전에 시도한 수정 사항과 그 결과.
- 각 가설을 확인하거나 기각하는 증거.
동일한 근본 원인을 가진 실패들을 그룹화하고, 최소한의 올바른 순서로 된 수리 계획을 제시해라. GitHub는 쓰지 마라. ```
## 9. 의존성 감사
```text 첨부된 파일이나 저장소 스냅샷에 기술된 모든 의존성을 감사해라.
확인할 것:
- 어떤 의존성이 필수, 선택, 구식, 중복, 비호환, 미사용인지.
- 선언된 버전과 설치되어 런타임에 로드된 버전이 일치하는지.
- 새로운 의존성이 실제로 프로덕션 경로에 통합되어 있는지.
- 네이티브 기능을 불필요하게 재구현하고 있지는 않은지.
- 업그레이드가 API, 스키마, 성능, 동작을 변경하는지.
- 락파일, 빌드 파일, 런타임 이미지, 테스트, 문서가 서로 일치하는지.
- 폴백(fallback)이 의도한 의존성을 조용히 우회하지는 않는지.
정확한 추가, 업그레이드, 제거, 마이그레이션, 통합 지점, 검증 테스트를 권장해라. 증거에 의해 변경이 정당화되지 않는 한 기존의 작동하는 동작은 유지해라. GitHub는 쓰지 마라. ```
## 10. 데이터 무결성 및 직렬화 감사
```text 첨부된 데이터 파이프라인의 읽기, 파싱, 검증, 변환, 직렬화, 저장, 재로드, 비교 전반에 걸쳐 무결성을 감사해라.
확인할 것:
- 스키마 드리프트(Schema drift).
- 타입 강제 변환(Type coercion).
- 정밀도 손실(Precision loss).
- 불안정한 순서(Unstable ordering).
- 타임스탬프 또는 시간대 오류(Timestamp or timezone errors).
- Null 및 누락된 값의 모호성(Null and missing-value ambiguity).
- 중복되거나 누락된 레코드(Duplicate or dropped records).
- 부분 쓰기(Partial writes).
- 비원자적 게시(Non-atomic publication).
- JSON, YAML, CSV, Parquet 또는 데이터베이스 왕복(round-trip) 간의 차이.
- 비표준 표현으로 계산된 해시(Hashes computed over noncanonical representations).
- 손상된 데이터가 이미 전파된 후에 수행된 검증(Validation performed after corrupted data has already propagated).
정확한 불변량, 정규화 규칙, 스키마 요구 사항, 조정 검사 및 왕복 테스트를 제공해. GitHub는 쓰지 마. ```
## 11\. 성능 및 확장성 감사
```text 첨부된 구현 내용을 성능, 동시성, 메모리, 스토리지, I/O 효율성 측면에서 감사해.
측정된 병목 현상과 추측을 구분하고 다음 항목들을 검토해:
- 중복된 읽기, 쓰기, 파싱 및 직렬화.
- 반복적인 전체 데이터셋 스캔.
- 비효율적인 배치 처리 또는 페이지네이션.
- 제한 없는 동시성 또는 큐.
- 잘못된 동시성 텔레메트리.
- 과도한 중간 아티팩트.
- 캐싱 누락 또는 잘못된 캐시 재사용.
- 점진적으로 처리할 수 있는 작업.
- 불필요하게 비싼 추상화를 사용하는 핫 패스(Hot paths).
- 정확성을 저해하는 성능 최적화.
기준 지표, 제안된 변경 사항, 예상 효과, 정확성 제약 조건 및 개선을 증명하는 데 필요한 벤치마크를 포함한 우선순위 최적화 계획을 만들어. GitHub는 쓰지 마. ```
## 12\. 안전 및 장애 의미론 감사
```text 첨부된 시스템의 장애 동작과 안전 제어 장치를 감사해.
시스템이 다음을 수행하는 지점을 식별해:
- 실패 시 닫혀야 하는데 열린 상태로 실패함(Fails open when it should fail closed).
- 무해한 텔레메트리나 보고 불일치 때문에 실패 시 닫힘(Fails closed for harmless telemetry or reporting discrepancies).
- 경고를 차단 요소와 혼동함.
- 부분적이거나 검증되지 않은 출력을 게시함.
- 불변량이 위반된 후에도 계속 작동함.
- 수락 규칙이 너무 광범위해서 안전한 진행을 방해함.
- 재시도 불가능한 실패를 재시도함.
- 중단 후 안전하게 복구되지 않음.
- 실패한 작업 후 모호한 상태를 남김.
모든 문제에 대해 올바른 심각도, 대응, 재시도 정책, 롤백 또는 재개 동작, 게시 규칙, 그리고 의도된 의미론을 증명하는 데 필요한 테스트를 정의해. GitHub는 쓰지 마. ```
## 13\. 다음 작업 결정
```text 첨부된 모든 증거를 검토하고 다음에 무엇을 해야 할지 정확히 결정해.
기존 계획을 단순히 반복하지 마. 먼저 완료된 작업, 부분적으로 완료된 작업, 차단 요소, 잘못된 가정, 해결되지 않은 증거 격차를 포함하여 현재 검증된 상태를 확립해.
그런 다음 남은 작업을 다음 기준으로 순위를 매겨:
- 의존성 순서.
- 근본 원인 해결 능력.
- 위험 감소.
- 사용자 가치.
- 후속 작업을 차단 해제할 수 있는 능력.
- 비용 및 가역성.
- 객관적인 수락 증거의 가용성.
각 작업이 왜 그 위치에 있는지, 무엇에 의존하는지, 무엇을 생성하는지, 그리고 다음 단계로 넘어가기 위해 필요한 정확한 조건이 무엇인지 설명하는 순차적 작업 목록을 반환해. GitHub는 쓰지 마. ```
## 14\. 상세 수리 계획
```text 첨부된 감사 결과를 사용하여 상세하고 순서가 올바른 수리 계획을 만들어.
모든 수리 항목에 다음을 포함해:
- 문제 및 근본 원인.
- 진단을 뒷받침하는 증거.
- 의도된 동작.
- 영향을 받을 가능성이 있는 파일, 모듈, 구성, 테스트 및 문서.
- 정확한 구현 변경 사항.
- 필요한 마이그레이션 또는 호환성 처리.
- 변경 사항을 검증하기 위한 명령어 또는 절차.
- 긍정, 부정, 경계 및 회귀 테스트.
- 예상 출력 및 수락 기준.
- 롤백 또는 복구 절차.
- 이전 수리에 대한 의존성.
관련 없는 수정 사항을 묶지 마. 이미 검증된 완료 작업을 다시 하지 마. 하위 증상보다 근본적인 권한 및 논리 문제를 먼저 해결해. GitHub는 쓰지 마. ```
## 15\. 계획을 Codex 실행 프롬프트로 변환
```text 첨부된 계획을 상세하고 순서가 올바른 하나의 Codex 실행 프롬프트로 변환해.
프롬프트는 Codex에게 다음을 지시해야 해:
- 수정하기 전에 현재 증거를 검토할 것.
- 정확한 시작 상태를 확립할 것.
- 검증된 완료 작업은 보존할 것.
- 완료된 단계를 다시 하지 말고, 누락된 부분을 찾아 채울 것.
- 의존성 순서를 따를 것.
- 적용 가능한 경우 저장소 전체에 각 요구사항을 구현할 것.
- 구성 요소가 실제 런타임 경로에서 활성화되어 있는지 확인할 것.
- 의미 있는 테스트를 추가하거나 업데이트할 것.
- 각 단계 이후에 적절한 검증을 실행할 것.
- 실패 원인을 근본 원인별로 기록할 것.
- 관련 없는 리팩토링은 피할 것.
- 명시적인 수락 기준을 사용할 것.
- 각 단계를 구현한 후 다시 읽어보고, 다음 단계로 넘어가기 전에 완료 여부를 확인할 것.
- 간결한 최종 증거 보고서를 작성할 것.
GitHub를 사용하거나 라이브 저장소에 접근할 수 있다고 가정하지 마라. 완성된 Codex 프롬프트만 단일 마크다운 코드 블록으로 반환하라. ```
## 16. 여러 계획을 하나의 실행 계획으로 병합
```text 첨부된 모든 계획을 중복 없고 순서가 정확하며 권위 있는 하나의 실행 계획으로 병합하라.
병합 전:
1. 모든 개별 요구사항을 추출하라.
2. 중복, 모순, 쓸모없는 지침, 의존 관계를 파악하라.
3. 각 충돌 상황에서 어떤 지침이 우선할지 결정하라.
4. 유효한 고유 요구사항은 보존하라.
5. 동작을 제거하지 않으면서 반복되는 문구만 제거하라.
6. 이미 완료된 작업과 남은 작업을 분리하라.
병합된 계획에는 요구사항 ID, 단계, 의존성, 영향을 받는 구성 요소, 검증 명령어, 예상 증거, 수락 기준, 중단 조건이 포함되어야 한다. 모든 원본 요구사항이 유지, 대체, 거부 또는 완료 상태로 매핑되도록 하라. GitHub를 사용하지 마라. ```
## 17. 계획 대 구현 간극 분석
```text 첨부된 계획, 구현 증거, 테스트, 로그, 출력을 비교하라.
각 계획된 요구사항에 대해 상태를 다음과 같이 분류하라:
- 완전히 구현되고 증명됨.
- 구현되었으나 활성화되지 않음.
- 활성화되었으나 검증되지 않음.
- 부분적으로 구현됨.
- 잘못 구현됨.
- 대체됨.
- 구현되지 않음.
- 현재 증거로는 검증 불가능.
각 분류의 근거가 되는 증거를 설명하라. 불완전한 요구사항에 의존하는 하위 요구사항을 파악하라. 그런 다음 검증된 완료 상태에 도달하기 위해 필요한 남은 작업만 제공하라. GitHub를 사용하지 마라. ```
## 18. 새로운 아이디어 및 가능성 검토
```text 첨부된 시스템이나 계획을 연구하고 정확성, 효율성, 감사 가능성, 신뢰성 또는 기능을 실질적으로 개선할 수 있는 새로운 아이디어를 제안하라.
제안을 다음 항목으로 분류하라:
- 저위험 개선 사항.
- 아키텍처 개선 사항.
- 새로운 검증 방법.
- 자동화 기회.
- 더 나은 지표 및 텔레메트리.
- 새로운 기능.
- 실험적 가설.
- 장기적 가능성.
각 아이디어에 대해 해결하려는 문제, 작동할 이유, 필요한 변경 사항, 위험, 의존성, 측정 가능한 이점, 그리고 이를 테스트할 수 있는 작은 실험을 설명하라. 증거에 기반한 권장 사항과 추측성 가능성을 명확히 구분하라. GitHub를 사용하지 마라. ```
## 19. Codex 프롬프트 품질 감사
```text 실행하기 전에 첨부된 Codex 프롬프트를 감사하라.
다음 항목을 찾아라:
- 모호한 지침.
- 상충하는 권한.
- 누락된 전제 조건.
- 잘못된 순서.
- 정의되지 않은 용어.
- 무제한적인 조사.
- 누락된 수락 기준.
- 반복 작업을 유도하는 지침.
- 증명할 수 없는 요구사항.
- 과도한 범위.
- 중단, 에스컬레이션, 재개 또는 실패 규칙 누락.
- Codex가 의도한 동작을 달성하지 않고도 문구만 만족시킬 수 있는 부분.
그런 다음 프롬프트를 결정론적이고, 증거 중심적이며, 의존성을 인식하고, 변경에 강하며, 구현, 테스트, 검증 및 완료에 대해 명시적이도록 다시 작성하라. GitHub를 사용하지 마라. ```
## 20. 최종 준비 상태 및 수락 감사
```text 첨부된 요구사항, 구현, 테스트, 로그, 지표 및 아티팩트를 사용하여 최종 수락 감사를 수행하라.
요약이 통과됐다고 해서 무조건 성공했다고 착각하지 마라. 다음 사항들을 직접 검증해라.
- 모든 요구 사항에 대한 구현 근거가 있는지.
- 모든 구현이 의도한 경로에서 제대로 작동하는지.
- 테스트가 요구된 동작을 확실히 증명하는지.
- 출력값이 입력값과 일치하는지.
- 알려진 결함들이 해결됐거나 명확하게 수용됐는지.
- 문서가 실제 동작과 일치하는지.
- 치명적인 우회 경로, 자리표시자, 검증되지 않은 대체 로직이 남아있지 않은지.
- 기록된 시작 상태에서 결과가 재현 가능한지.
- 다른 검토자가 동일한 결론을 내릴 수 있을 만큼 근거가 충분한지.
최종 판정으로 ready, conditionally ready, not ready 중 하나를 내리고, 그 뒤에 정확한 근거, 남은 조건, 승인을 위해 필요한 최소한의 조치를 적어라. GitHub는 쓰지 마라.
