"AI로 CI 자동화하면 QA 속도 몇 배 빨라지죠?" 요즘 팀 리드들한테 가장 많이 받는 질문이다. 그리고 솔직히 말하면, 이 질문 자체가 이미 위험 신호다. 에이전트를 파이프라인에 녹이는 것과 그 결과물을 신뢰하는 것은 완전히 다른 문제인데, 대부분의 팀이 전자만 설계하고 후자는 운에 맡긴다.
최근 세 갈래의 실패 패턴이 동시에 수면 위로 올라왔다. 하나씩 뜯어보면 각각 독립된 버그처럼 보이지만, 한데 놓고 보면 같은 구조적 결함을 가리킨다. AI 에이전트를 CI에 붙이기 전에 반드시 설계해야 할 실패 모드 세 가지다.
실패 모드 1: 환각 진단 루프 (Agentic Deadlock)
dev.to에 올라온 사례가 이 패턴을 가장 선명하게 보여준다. 에이전트 기반 QA 파이프라인이 Vitest 어서션 실패를 만났을 때 어떤 일이 벌어지는가. LLM은 에러 로그를 읽고, 코드를 스캔하고, 자신 있게 결론을 내린다: "비즈니스 로직이 잘못됐다. 리팩터링하겠다." 그리고 수정한다. 파이프라인이 다시 돌아간다. 또 실패한다. 이 루프가 무한 반복된다.
근본 원인은 LLM이 멍청해서가 아니다. 오히려 반대다. LLM은 자신이 검증하지 않은 추론에 지나치게 확신을 갖는다. 에러 로그를 보고 단계별 수식 추적을 하는 게 아니라, 패턴 매칭으로 그럴듯한 원인을 특정하고 100% 확신으로 보고한다. 테스트 작성자가 expected: 100 대신 expected: 108로 잘못 써놨다면? 에이전트는 테스트가 틀렸다고 말하지 않는다. 비즈니스 로직을 깨진 어서션에 맞게 '수정'한다. 커버리지 극장이 실제 프로덕션 회귀로 이어지는 경로가 바로 이것이다.
다중 에이전트 환경에서 이 비용은 배가된다. QA 에이전트가 ENGINE_DEFECT으로 잘못 진단하면, Dev 에이전트는 멀쩡한 코드를 리팩터링하는 데 사이클을 낭비한다. 개발자는 자동화 파이프라인에 대한 신뢰를 잃고, '자율 파이프라인'은 슬랙 노이즈 채널로 전락한다. QA Arbiter 같은 접근, 즉 에이전트에게 지시 대신 제약을 주는 구조가 필요한 이유다. LLM이 "이게 버그인 것 같다"고 말하는 대신 "3단계에서 엔진이 실패했다는 수식 추적이 여기 있다"고 증명하도록 강제하는 것.
실패 모드 2: 묵음 덮어쓰기 (Lost Update)
두 번째 패턴은 더 조용하게, 더 광범위하게 터진다. 두 에이전트가 같은 파일을 동시에 편집할 때 어떤 일이 일어나는가. dev.to의 시뮬레이션 결과가 냉정하다. N=5 에이전트가 최악의 스케줄로 하나의 공유 파일에 커밋할 때, 5번의 쓰기 중 4번이 최종 상태에서 사라졌다. 그리고 시스템은 아무 말도 하지 않았다. 에러 없음, 익셉션 없음, 빨간 로그 없음. 5개의 쓰기 모두 ACK 됐고, 하나만 살아남았다.
이건 AI가 만든 새로운 문제가 아니다. 데이터베이스 격리 이론에서 수십 년 전부터 다뤄온 'Lost Update' 이상 현상이다. AI 에이전트 시대에 새로운 것은 딱 하나다: 사라진 쓰기 하나하나가 실제 모델 토큰을 소각했다는 것. 그리고 그 손실이 아무 흔적도 남기지 않는다.
해결책은 로그를 더 크게 만드는 게 아니다. Append-only 로그는 쓰기가 일어났다는 사실은 보존하지만, 그 변경이 최종 상태에 반영됐는지는 보장하지 못한다. 유일하게 작동하는 픽스는 쓰기 전 버전 체크, 즉 Compare-and-Set이다. 시뮬레이션 결과 46,333번의 인터리빙 샘플에서 Lost Update가 0건으로 떨어졌다. 단, 공짜는 아니다. N=5 최악의 경우 총 작업량이 5에서 9로 늘었다. 무결성을 사는 대가로 재시도 비용을 지불하는 거래다.
CI 파이프라인에 다중 에이전트를 투입하는 순간—플래너가 워커를 스폰하든, 서브에이전트가 공유 스크래치패드에 쓰든—이 문제는 이미 시작된 것이다. 공유 상태에 쓰기 전제조건 없이 에이전트를 돌리는 것은, 조용하게 작업이 증발하는 파이프라인을 운영하는 것과 같다.
실패 모드 3: 속도 착시 (Timeline Illusion)
세 번째 실패 모드는 코드 레벨이 아니라 기대치 레벨에서 터진다. "AI 코딩 도구로 앱 만들면 며칠이면 되죠?" 벨로그에 올라온 이 글이 정확하게 짚은 문제다. AI 코딩 도구가 몇 분 만에 화면과 버튼이 동작하는 데모를 뽑아내면, 비개발자는 곧장 비례식을 세운다. "데모가 5분이면 서비스는 100배, 500분이면 되겠네."
이 계산은 틀렸다. 배수 문제가 아니라 종류가 다른 일이 남아 있기 때문이다. AI가 극적으로 빨라진 건 화면과 뼈대를 만드는 작업이다. 실제 데이터 테스트, 결제·인증 검증, AI 생성 코드와 기존 아키텍처의 충돌 확인, 사용자 피드백 반영—이건 그대로 남아 있다. 더 위험한 건, AI가 생성한 코드는 왜 그렇게 짰는지 설명이 없는 경우가 많아서 나중에 문제가 생기면 원인 파악이 더 오래 걸리기도 한다.
CI에 에이전트를 붙이는 것도 같은 착시를 만든다. 에이전트가 테스트를 실행하고 결과를 보고하는 속도는 빨라진다. 하지만 그 보고가 올바른지 검증하는 비용, 다중 에이전트 간 쓰기 충돌을 감지하는 비용, 환각 진단으로 망가진 코드를 되돌리는 비용—이건 파이프라인에 에이전트를 붙이는 순간 이미 발생하기 시작한다.
테크 리드가 먼저 해야 할 설계
세 실패 모드가 동시에 가리키는 결론은 하나다. 에이전트를 CI에 녹이기 전에 실패 설계를 먼저 해야 한다. 구체적으로:
- 환각 진단 루프 대비: 에이전트에게 "고쳐라"는 지시 대신 "증명하라"는 제약을 줘라. 진단 결과를 구조화된 포맷으로 강제하고, 그 결과가 논리적으로 일관성이 있는지 검증하는 레이어를 파이프라인에 붙여라.
- 묵음 덮어쓰기 대비: 다중 에이전트가 공유 상태에 접근하는 모든 경로에 버전 체크를 설계하라. ACK가 곧 무결성이 아니라는 걸 코드 레벨에서 강제해야 한다.
- 속도 착시 대비: 팀과 스테이크홀더에게 "어느 작업이 얼마나 줄었는지"를 구체적으로 보여줄 수 있어야 한다. "AI 덕분에 빨라졌다"는 감성이 아니라 단계별 측정값으로 기대치를 설정하라.
AI 에이전트는 CI 파이프라인을 더 빠르게 만들 수 있다. 하지만 더 빠른 파이프라인이 더 신뢰할 수 있는 파이프라인은 아니다. 에이전트를 '돌리는 것'과 '신뢰하는 것' 사이의 간극을 메우는 것—그게 지금 테크 리드가 먼저 설계해야 할 일이다.