디버깅 철칙：먼저 Log, 그 다음 수정
AI가 오류를 만나면 첫 번째 반응은 원인을 추측하고 고쳐보는 것이고, 안 되면 다른 추측을 합니다. 이 절은 가장 핵심적인 규칙을 세웁니다：추측성 수정 금지. 아래 두 가지 데모로 두 가지 버그 수정 경로를 직접 비교해 보세요.
추측성 수정 금지.근본 원인을 확인할 수 없을 때는 먼저 Log, 브레이크포인트, 또는 테스트 스크립트로 가설을 검증해야 합니다. 「한번 고쳐보고 어떻게 되나 보자」는 금지입니다. 백엔드는 터미널에, 프론트엔드는 브라우저 Console에 상세 로그를 남기세요. 어떤 문제든 첫 번째 단계는 항상 Log를 추가하는 것입니다.
경로를 클릭하여 수정 과정을 관찰하세요. 오른쪽 카운터가 라운드 수와 누적 변경 행 수를 기록합니다.
추측성 수정 · 결과
Log 먼저, 그 다음 수정 · 결과
규칙에 따라 버그를 수정하기 전에 반드시 세 가지 질문에 답해야 합니다. 순서대로 세 가지 질문을 열어보면 모두 확인한 후에야 「수정 시작」 버튼이 잠금 해제됩니다.
사전 조사 완료 — 진행하세요.수정 완료 후 마지막 단계가 있습니다：영향 범위를 선언하여 회귀 테스트해야 할 곳을 모두가 알 수 있도록 합니다.
Mock으로 실제 AI 인터페이스 우회 금지
AI 모델 호출이 포함된 기능은 납품 전에 인터페이스가 실제로 접근 가능한지 확인해야 합니다. 사용자가 API Key를 제공하지 않았으면 멈추고 요청해야 합니다 — 가짜 응답을 하드코딩하거나 로컬 Mock으로 실제 호출을 우회하는 것은 금지입니다. Key를 받으면 먼저 테스트 요청을 보내 사용 가능한지 확인한 후 개발을 계속하세요.
단위 테스트 통과 없이 납품 불가
핵심 비즈니스 로직, API 인터페이스, 데이터 처리 함수, 경계 조건을 모두 커버하세요. 테스트 파일은 tests/에 통합하고 test_{모듈명}.py로 명명하며, Python 프로젝트는 pytest를 사용합니다. 디버깅용 임시 스크립트는 사용 후 삭제하세요.
증거 먼저.Log를 추가하는 2분이 세 라운드의 추측성 재작업과 숨겨진 근본 원인을 방지합니다. 수정 후 ⚡ 영향 범위：XXX, YYY, ZZZ 형식으로 영향 범위를 선언하고, 납품 전에 실제 인터페이스와 단위 테스트 두 가지 기준을 통과하세요.