AI는 버그 분류 (Bug Triage)를 더 빠르게 만들 수 있지만, 한 가지 위험한 실패 모드 또한 더 쉽게 만듭니다. 바로 실패가 재현되기 전에 그럴듯한 설명을 확신에 찬 진단으로 바꿔버리는 것입니다.

유용한 질문은 "모델이 원인을 제안할 수 있는가?"가 아닙니다. 대개는 가능합니다. 진짜 질문은 이것입니다: 어떤 증거가 다른 개발자가 그 원인을 검토할 수 있게 해주는가?

다음은 제가 현재 AI 보조 버그 작업에 사용하는 워크플로우입니다.

1. 보고서를 실행 가능한 기록으로 전환하기

빌드, 환경, 사용자 경로, 기대 동작, 실제 동작, 빈도, 영향 및 기존의 모든 증거를 캡처하세요.

관찰 내용(Observations)을 해석(Interpretations)과 분리하여 유지하십시오. "요청이 14:32에 500 에러를 반환했다"는 증거입니다. "데이터베이스 타임아웃이 발생했다"는 로그가 이를 뒷받침하지 않는 한 여전히 가설입니다.

중요한 사실이 누락되었다면, 워크플로우는 이를 요청해야 합니다. 조용히 그 공백을 메워서는 안 됩니다.

2. 재현하거나, 재현되지 않는 범위를 문서화하기

좋은 재현 기록에는 다음이 포함됩니다:

• 정확한 설정 및 버전;
• 입력값 및 관련 타임스탬프(Timestamps);
• 순서대로 나열된 동작;
• 기대 출력 및 실제 출력;
• 로그, 스크린샷 또는 트레이스(Traces);
• 여전히 작동하는 대조군(Control case).

문제가 재현되지 않을 때는 테스트된 매트릭스를 반환하고 다음에 필요한 신호를 명시하십시오. "재현할 수 없음"은 "버그가 유효하지 않음"과 같지 않습니다.

3. 실패하는 경로와 작동하는 대조군을 비교하기

전체 코드베이스를 읽는 것보다 인접한 작동 경로를 확인하는 것이 종종 더 유용합니다.

가상의 스케줄링 결함을 가정해 봅시다: 환자들이 유럽/부쿠레슈티(Europe/Bucharest)에서 일정을 재조정할 때만, 춘계 일광 절약 시간제(Daylight-saving) 전환기 근처의 물리적 슬롯을 중복 예약할 수 있는 문제입니다.

신규 예약 경로는 시간대 인식(Timezone-aware) 스케줄링 경계를 통해 현지 시간을 정규화합니다. 재예정 경로는 단순한(Naive) 현지 값을 저장된 UTC 시점과 직접 비교합니다.

그러한 비교는 우리에게 "시간대는 어렵다"라는 말보다 훨씬 강력한 것, 즉 실패하는 경로와 작동하는 대조군 사이의 좁은 차이를 제공합니다.

4. 증거로 뒷받침되는 가장 작은 원인을 명시하기

유용한 원인 진술(cause statement)은 세 가지 부분으로 구성됩니다:

1. 조건 (Condition): 일광 절약 시간제 (DST) 경계를 가로지르는 일정 재조정.
2. 메커니즘 (Mechanism): 단순한 로컬 타임스탬프 (local timestamp)가 저장된 UTC 인스턴트 (instants)와 비교됨.
3. 증거 (Evidence): 실패하는 경로는 정규화 (normalization)를 건너뛰는 반면, 정상 작동하는 예약 경로는 이를 사용함.

또한 제외된 대안들과 아직 테스트되지 않은 대안들도 기록하십시오. 이는 좁은 범위의 발견이 시스템 전체에 대한 근거 없는 주장으로 변질되는 것을 방지합니다.

5. 증상이 아닌 권한 경계 (authority boundary)를 수정하라

최소한의 수정은 충돌 확인 (collision checks) 전에 기존의 시간대 인식 정규화 함수 (timezone-aware normalization function)를 통해 일정 재조정을 처리하도록 경로를 지정하는 것입니다.

이는 충돌 규칙을 전역적으로 약화시키거나, DST 근처의 검증을 비활성화하거나, 모든 스케줄링 경로를 다시 작성하는 것이 아닙니다.

'최소한(Minimal)'이라는 것이 '부주의함'을 의미하지는 않습니다. 이는 합리적으로 가장 작은 회귀 표면 (regression surface)을 가지면서 입증된 원인을 바로잡는 것을 의미합니다.

6. 불변량 (invariant)을 보호하라

회귀 테스트 (regression test)는 원래의 결함에 대해 실패해야 하며, 중요한 동작을 증명해야 합니다:

• 동일한 인스턴트 (instants)가 동일한 물리적 슬롯을 예약할 수 없음;
• DST 간격이 제품 규칙 (product rule)에 따라 처리됨;
• 인접한 슬롯들이 여전히 정상 작동함;
• 일반적인 날짜들이 변경되지 않고 유지됨;
• 신규 예약 제어 경로 (new-booking control path)가 통과(green) 상태를 유지함.

그 다음, 리스크에 적합한 배포 신호 (rollout signals)와 복구 경로 (recovery path)를 추가하십시오. 로컬 테스트만으로는 운영 환경(production)의 수정이 증명되지 않습니다.

요약된 리뷰 체크리스트

AI 지원 진단을 수용하기 전에 다음을 질문하십시오:

• 정확한 환경과 빌드 (build)를 알고 있는가?
• 기대되는 동작이 구현 (implementation)과 독립적으로 명시되었는가?
• 실패가 재현되었는가, 아니면 재현되지 않음의 범위를 한정했는가?
• 작동하는 제어 경로 (control path)가 있는가?
• 원인 진술이 조건, 메커니즘, 증거를 연결하는가?
• 제안된 변경 사항이 관련 없는 정책을 보존하는가?
• 회귀 테스트가 코드를 그대로 모방하는 대신 불변량 (invariant)을 보호하는가?
• 배포 (rollout) 및 복구 (recovery) 신호가 명시적인가?

이 지점에서 AI는 구조화 및 비교 도구로서 가치가 있습니다. AI는 증거를 정리하고, 재현 매트릭스 (reproduction matrix)를 제안하며, 경로를 비교하고, 회귀 케이스 (regression cases)의 초안을 작성할 수 있습니다. AI는 자신이 관찰하지 않은 근본 원인 (root cause), 테스트 결과, 또는 운영 동작 (production behavior)을 주장해서는 안 됩니다.

저는 작업된 시간대 (timezone) 예시가 포함된 무료 읽기 전용 워크스루 (walkthrough)를 여기에 게시했습니다:

AI Bug Triage Workflow: From Report to Minimal Fix

저는 CodeCurrent Studio를 구축했으며, 누군가 이 제품의 워크플로우 팩 (workflow packs) 중 하나를 구매한다면 도움이 될 수 있습니다. 위의 워크스루는 무료입니다. CodeCurrent Studio는 독립적이며, 어떠한 AI 모델 벤더와도 제휴하거나 보증을 받지 않습니다.