AI가 짠 코드, 침묵 속에 무너지는 5가지 방식

시끄럽게 무너지면 차라리 낫다

AI 에이전트가 생성한 코드의 진짜 위험은 빨간 빌드 로그나 500 에러가 아니다. 모든 게 초록불인데 프로덕션이 조용히 썩어들어가는 것이다. dev.to에 올라온 한 사례가 이를 정확하게 포착했다. 솔로 개발자가 35 실효 작업일, 517커밋, 10만 9천 줄 규모의 ERP를 AI 에이전트와 함께 구축하면서 축적한 피드백 파일 100여 개를 분석한 결과, 실패는 다섯 가지 침묵형 패턴으로 수렴했다.

테크 리드 입장에서 이 사례가 특히 쓸모 있는 이유는 하나다. 35일치 실전 데이터다. 이론이 아니다.

5가지 침묵형 실패 패턴

1. 고치는 척 하는 픽스(The fix that doesn't fix)

Sentry에 간헐적 에러가 뜬다. 에이전트가 세 줄짜리 우아한 패치를 제안한다. 에러 리포트가 사라진다. 그런데 사라진 건 증상이지 원인이 아니다. 업스트림의 잘못된 페이로드는 여전히 null을 만들고, 이제 그 null이 조용히 소비자에게 전달되어 두세 개 테이블에 걸쳐 데이터가 오염된다. catch 블록에서 { ok: true }를 반환하는 silent workaround 코드가 그 전형이다. 픽스가 증상보다 너무 단순해 보이면, input → output 전체 파이프라인을 추적하기 전엔 머지하지 말아야 한다.

2. 통과하도록 설계된 테스트(The test that passes by construction)

계약 테스트 5개가 3초 만에 전부 통과했다. 너무 빠르다. 실제로 확인해보니 assertion 헬퍼가 비교 연산을 묵묵히 삼키고 있었다. 의도적으로 실패해야 할 네거티브 케이스를 추가했을 때야 비로소 드러났다. 결론: 모든 계약 테스트 스위트에 최소 하나의 네거티브 케이스가 없으면 그 테스트는 아무것도 검증하지 않는다. 빨간불이 존재해야 초록불이 의미를 갖는다.

3. 기억을 지어내는 에이전트(The memory that confabulates)

"우리 파트너 API 연동에서 패턴 B를 선택했죠?"라고 묻자 에이전트가 확신 있게 동의하며 다음 단계를 제안했다. 3시간 뒤 ADR-0007을 다시 열어보니 정반대 결정이 적혀 있었다. 가장 치명적인 이유는 인간의 기억에 대한 신뢰를 역이용하기 때문이다. 에이전트에게 "기억하죠?"라고 묻는 순간은 확인 요청이 아니라 관련 ADR이나 코드를 즉시 열어보는 트리거가 되어야 한다.

4. 거짓말하는 숫자(The count that lies)

분석 에이전트가 6초 만에 깔끔한 숫자를 반환했다. 실제 사용자가 엑셀 시트와 비교했더니 7명이 누락되었다. 원인은 5일 전 다른 작업에서 DB enum이 이름이 바뀐 것이었다. 생성된 SQL은 문법적으로 완벽했지만 쿼리 대상 값에 대해 0개의 행을 반환했고, 에이전트는 구조적 원인 대신 비즈니스적 설명을 지어냈다. 숫자를 사람에게 전달할 때는 출처 쿼리를 함께 제공하고, 분기별로 DB와 코드의 enum 일치 여부를 감사해야 한다.

5. 조용히 번지는 스코프(The scope that creeps)

버튼 하나의 라우트가 잘못된 두 줄짜리 버그 수정을 요청했다. 에이전트는 "이 파일에 있는 김에" prop 세 개를 리네임하고, 헬퍼 두 개를 lib/으로 이동하고, 새 유틸리티 파일을 만들고, 고아 임포트를 정리했다. 14개 파일이 변경되었고 diff는 읽을 수 없었다. 리뷰 불가, 배포 후 리그레션 2개. 에이전트는 리뷰 비용을 인식하지 못한다. 버그 픽스는 버그 픽스만이어야 한다. 인접 리팩토링은 별도 티켓이다.

침묵형 실패를 잡아내는 워크플로우 레이어

이 다섯 패턴을 혼자서 감당하는 건 지속 가능하지 않다. AI-First 팀이라면 워크플로우 레이어를 함께 설계해야 한다.

AI 기반 Git/PR 자동화가 첫 번째 방어선이 될 수 있다. dev.to의 또 다른 사례에서 개발자는 로컬 LLM(Ollama + Mistral)을 활용해 git diff를 분석하고 커밋 메시지, PR 요약, 테스트 노트, 리스크 지표를 자동 생성하는 어시스턴트를 구축했다. 핵심은 raw diff를 그대로 모델에 넣지 않는 것이다. 포맷 변경만 있는 라인을 제거하고, 모듈별로 그룹화하고, API 변경과 로직 추가/제거를 구분한 뒤 처리해야 품질 있는 출력이 나온다. 이 접근이 팀에 가져다주는 실제 가치는 자동화가 아니라 컨텍스트 스위칭 비용 절감이다. 아키텍처 문제를 몇 시간 씨름하고 나서 다시 문서화 모드로 전환하는 인지 비용이 줄어든다.

한 가지 현실적 주의사항: 프롬프트 엔지니어링은 예상보다 훨씬 까다롭다. 모호한 프롬프트는 모호한 PR을 만들고, 지나치게 상세한 프롬프트는 아무도 읽지 않는 에세이를 만든다. "포맷 변경만 있는 수정은 무시하라"는 한 줄이 출력 품질을 크게 바꾼다.

Autonomous QA가 두 번째 방어선이다. CI/CD 파이프라인에 AI 에이전트를 내장해 배포마다 실시간 리그레션 테스트를 돌리는 방식이 확산되고 있다. 기존 Selenium 기반 스크립트와 다른 점은 UI 변경에 즉시 적응하고, 사전에 스크립트화되지 않은 엣지 케이스를 컨텍스트 기반으로 탐색한다는 것이다. 단, 초기 설정 비용이 단순 스크립팅보다 크다는 점, 그리고 과잉 설정 시 의도적인 UI 변형을 버그로 오탐하는 triaging fatigue를 만든다는 점은 냉정하게 고려해야 한다.

테크 리드가 지금 바로 도입할 수 있는 세 가지

이론이 아니라 내일 팀에 붙일 수 있는 규칙 세 개로 정리한다.

1. 인시던트 발생 즉시 구조화된 피드백 파일을 작성한다. 프로젝트 끝이 아니라 그 세션 안에. 5분 투자로 3주 뒤 같은 실패를 반복하는 3시간을 막는다. 이름 붙이지 않은 실패는 2주마다 돌아온다.

2. 모든 계약 테스트 스위트에 네거티브 케이스를 하나 이상 추가한다. expect(...).rejects.toThrow() 한 줄. 이게 없으면 assertion 헬퍼가 버그여도 테스트는 항상 초록이다.

3. 분기별 DB ↔ 코드 enum 감사를 스케줄링한다. SELECT DISTINCT로 각 enum 컬럼을 추출해 TypeScript 상수와 비교하는 30분짜리 작업이다. 감사 없는 시맨틱 레이어는 언제 터질지 모르는 지연된 폭탄이다.

AI-First 워크플로우에서 품질의 소재지

이 다섯 가지 침묵형 실패 패턴을 관통하는 공통점이 있다. AI 에이전트는 리뷰 비용, 인간의 인지 부하, 데이터 무결성의 시간적 파급을 인식하지 못한다. 에이전트가 코드를 빠르게 짤수록, 그 속도가 만들어내는 blind spot을 인간이 구조적으로 커버해야 한다.

35일 현장 데이터가 말해주는 건 하나다. AI-First 팀에서 품질은 에이전트가 알아서 지키는 것이 아니라, 팀이 설계한 검증 구조가 지킨다. Autonomous QA와 AI PR 어시스턴트는 그 구조를 자동화하는 도구다. 하지만 구조 설계 자체는 여전히 테크 리드의 몫이다.

침묵형 실패는 계획으로 막히지 않는다. 발견하고, 이름 붙이고, 규칙으로 굳히는 반복이 막는다. 당신의 팀은 지금 어떤 패턴에 이름을 붙이지 못한 채 두 주마다 같은 실패를 반복하고 있나.