AI 생성 코드를 디버깅하는 방법 — 3가지 프로덕션 장애 패턴

저는 Cursor를 사용하여 전체 인벤토리 모듈을 구축했습니다. 데모는 깔끔해 보였고, 클라이언트도 승인했습니다. 그런데 저장할 때마다 중복 레코드가 생성되기 시작했습니다.

근본 원인: AI가 upsert 호출은 올바르게 작성했지만, 레코드의 UUID를 상태(state)에 다시 저장(persist)하지 않았습니다. 모든 저장이 해당 폼을 새로운 레코드로 취급했습니다.

프로덕션 환경의 ERP 및 CRM 작업에서 이러한 사례들을 여러 번 디버깅한 결과, AI 생성 코드가 세 가지 예측 가능한 패턴으로 깨진다는 것을 발견했습니다. 그리고 각 패턴은 서로 다른 디버깅 접근 방식이 필요합니다.

패턴 1: 구조적 위반 (Structural violations)

AI가 로직을 잘못된 위치에 배치합니다. 헬퍼 파일(helper file)에 있어야 할 함수를 부모 컴포넌트(parent component)에 두거나, 모듈 경계를 위반하는 임포트(imports)를 생성합니다. 코드베이스의 나머지 부분과 일치하지 않는 명명 규칙(naming conventions)을 사용하기도 합니다.

발생 원인: 지침 파일(steering file)이 길거나 대화 컨텍스트(conversation context)가 크면, 모델은 구조적 규칙의 우선순위를 낮게 설정합니다.

해결책: 프롬프트(prompt)에 핵심 규칙을 직접 다시 명시하세요. — "이 함수들을 부모 컴포넌트가 아닌 /helpers/moduleName.js에 작성하세요." 번거롭지만 효과가 있습니다.

패턴 2: 데모 전용 기능 (Demo-only functionality)

코드가 첫 번째 실행 시에는 작동합니다. 하지만 두 번째 상호작용, 예외 케이스(edge case) 입력, 또는 취소 후 재시도(cancel-and-retry) 시퀀스 이후에는 실패합니다.

AI는 해피 패스(happy path, 정상 경로)에 최적화되어 있습니다: 단일 사용자, 깨끗한 데이터, 오직 첫 번째 상호작용만을 가정합니다. AI는 작업 전의 컴포넌트 상태(component state)가 어떤 모습인지, 또는 사용자가 어떤 동작을 두 번 반복했을 때 어떤 일이 발생하는지는 모델링하지 않습니다.

해결책: 코드를 수락하기 전에 모든 사용자 흐름(user flow)을 최소 두 번 이상 실행하세요. 대부분의 AI 상태(state) 버그는 첫 번째 실행에서는 보이지 않습니다.

패턴 3: 침묵하는 상태 버그 (Silent state bugs)

필수 댓글 대화창이 있는 파일 업로드 컴포넌트가 있다고 가정해 봅시다. 첫 번째 취소 시: 업로드가 올바르게 차단됩니다. 두 번째 취소 시: 업로드가 그대로 진행됩니다.

AI는 취소 시 차단하기 위해 불리언 플래그(boolean flag)를 설정했지만, 시도 사이에 이를 초기화(reset)하지 않았습니다. 두 번째 시도에서 오래된 값(stale value)을 읽어들인 것입니다.

해결책: 트리거(trigger)로부터 앞으로 나아가는 방식이 아니라, 증상(symptom)으로부터 역추적(trace backwards)하세요. useState(false), useRef(), 그리고 모든 ID/UUID 변수를 검색하세요. 누락된 초기화 작업은 바로 그곳에 있습니다.

배포 전 체크리스트

AI가 생성한 모듈을 수락하기 전에 다음 과정을 수행하세요: 흐름(flow)을 두 번 실행하고, 네트워크 탭에서 API 호출(생성(create)인가 업데이트(update)인가?)을 확인하며, 모든 불리언 플래그(boolean flags)가 상호작용 사이에 초기화되는지 검증하고, 로직을 단 한 줄이라도 읽기 전에 파일 배치(file placement)를 감사(audit)하세요.

15분 정도 소요됩니다. 하지만 사후에 디버깅하는 데 몇 시간이 걸릴 버그들을 잡아낼 수 있습니다.

상세한 체크리스트를 포함한 전체 분석 내용은 원래 StackNova에 게시되었습니다.