'AI가 만든 코드는 믿을 수 없다'는 말을 팀에서 자주 듣는다. 그런데 솔직히 물어보자. 동료가 짠 코드는 믿었나? PR 리뷰 없이 머지한 적 없나? 테스트 없이 배포한 적 없나? AI 생성 코드에 대한 불안은 진짜다. 하지만 그 불안의 정체를 정확히 짚지 않으면, 우리는 엉뚱한 곳에 검증 비용을 쏟고 정작 필요한 곳은 놓친다.
AI 슬롭이라는 이름이 가진 문제
dev.to에 올라온 "Bugs and Slop"은 이 감정적 반응을 정면으로 해부한다. LLM이 클래스를 상속 대신 복사하거나, 엣지 케이스를 빠뜨리거나, 모바일에서 이상하게 동작하는 컴포넌트를 생성하면 커뮤니티는 즉각 '슬롭'이라고 부른다. 문제는 이 단어가 기술적 판단이 아니라 도덕적 낙인이라는 점이다. '버그'는 고치면 되는 것이지만, '슬롭'은 오염이다. 코드베이스를 더럽힌 존재다.
그런데 역사 기록은 냉정하다. 1999년 화성 기후 궤도선은 단위 불일치 하나로 $3억 2천7백만짜리 탐사선을 잃었다. 1996년 아리안 5 로켓은 64비트 부동소수점 값을 16비트 정수 필드에 밀어넣은 오버플로우로 발사 37초 만에 자폭했다. 2012년 Knight Capital은 잘못된 배포 설정 하나로 45분 만에 $4억 4천만을 날리고 파산 직전까지 갔다. 아무도 이것을 '인간 슬롭'이라 부르지 않았다. 버그였고, 포스트모템이었고, 다음 설계의 교훈이었다.
속도가 빨라지면 버그도 빨라진다—그게 전부다
AI 생성 코드의 진짜 문제는 품질 자체가 아니라 속도와 볼륨이다. 사람이 하루에 짜던 코드를 AI는 한 시간에 쓴다. 버그 비율이 같아도 절대 건수는 10배다. 이게 AI 슬롭처럼 느껴지는 이유다. 실제로 코드가 더 나빠진 게 아니라, 나쁜 코드가 더 빨리 쌓이는 것이다.
이 구분이 중요한 이유는 처방이 달라지기 때문이다. '품질 자체 문제'라면 AI 사용을 줄이거나 프롬프트를 더 정교하게 짜야 한다. '속도와 볼륨 문제'라면 검증 파이프라인을 같은 속도로 돌려야 한다. 소스 기사가 지적한 핵심이 여기 있다: AI는 버그를 만드는 만큼 빠르게 로그를 추적하고, 스택 덤프를 분석하고, 패치를 생성할 수 있다. 대칭성이 기회다.
세션 컨텍스트 단절—잊어버리는 에이전트의 구조적 리스크
품질 문제를 더 복잡하게 만드는 요인이 있다. AI 코딩 에이전트는 세션이 끊기면 이전 결정을 기억하지 못한다. 어제 왜 이 아키텍처를 선택했는지, 지난주에 어떤 엣지 케이스를 확인했는지—다음 세션의 에이전트는 모른다. 이건 단순히 불편한 문제가 아니다. 컨텍스트 없이 생성된 코드가 기존 설계 결정과 충돌할 때, 그 충돌은 즉시 드러나지 않고 기술 부채로 누적된다.
GeekNews에서 소개된 agentmemory 같은 솔루션이 이 문제를 직접 겨냥한다. 4단계 메모리 구조—Working(단기 도구 사용) → Episodic(세션 요약) → Semantic(패턴 추출) → Procedural(워크플로우 결정)—를 통해 에이전트가 프로젝트의 결정 이력을 이어받는다. LongMemEval-S 벤치마크에서 R@5 95.2%라는 수치보다 주목할 것은 22K 토큰 컨텍스트를 1,900 토큰으로 압축하면서도 핵심 결정을 유지한다는 점이다. 에이전트가 왜 그 코드를 그렇게 짰는지 추적할 수 있다면, 검증 비용이 절반 이하로 줄어든다.
프로덕션 GPT-5 3개월—신뢰 기준을 숫자로 본다
dev.to의 GPT-5 프로덕션 운영 경험은 AI 생성 결과물의 신뢰 기준을 추상이 아닌 숫자로 보여준다. 하루 4만 건의 문서 요약 서비스에서 비용은 30% 감소했다. 코드 리뷰 어시스턴트는 비용이 15% 늘었지만 출력 품질이 올라 유지했다. 흥미로운 건 GPT-5가 더 깨끗한 JSON을 뱉기 시작하자 기존 오류 처리 브랜치가 동작을 멈추고 downstream 버그가 터졌다는 사례다. 모델이 나빠진 게 아니라 좋아졌는데 버그가 났다. 기존 코드가 나쁜 입력에 의존하고 있었기 때문이다.
이 사례가 주는 교훈은 명확하다. AI 생성물을 신뢰하기 전에, 그 신뢰를 받아낼 코드가 준비되어 있는지를 먼저 검증해야 한다. 모델을 바꿀 때 로그부터 읽고, 병렬로 일주일 돌리고, 100개 샘플을 직접 눈으로 보라는 조언은 단순 팁이 아니라 AI-First 워크플로우에서 신뢰를 쌓는 최소 프로세스다.
검증은 새로 발명하는 게 아니다—이미 있다
세 소스를 관통하는 공통 메시지가 하나 있다. AI 생성 코드를 신뢰할 수 있는 구조를 만드는 데 필요한 도구는 이미 존재한다. 단위 테스트, 통합 테스트, 컨트랙트 테스트, CI 게이트, 관찰가능성 파이프라인—이것들은 AI 시대 이전부터 있었고, AI 시대에 더 중요해졌을 뿐이다.
실무적으로 지금 당장 적용할 수 있는 기준을 정리하면 이렇다:
- 에이전트가 생성한 코드는 같은 세션 안에서 테스트가 통과해야 머지 후보가 된다. 다음 세션으로 검증을 미루는 순간 컨텍스트가 끊기고 책임 소재가 흐려진다.
- 컨트랙트 테스트로 인터페이스 계약을 잠가라. 화성 궤도선 사고는 단위 불일치였다. AI가 생성한 컴포넌트 간 API 계약이 실제로 맞는지는 런타임이 아닌 CI에서 검증해야 한다.
- 메모리 없는 에이전트를 장기 프로젝트에 쓰지 마라. 세션 간 컨텍스트 단절은 기능 문제가 아니라 아키텍처 일관성 문제다. agentmemory류의 솔루션이 실용적이지 않다면 최소한 CLAUDE.md나 설계 결정 로그를 체계화해야 한다.
- 모델을 바꿀 때는 기존 오류 처리 코드부터 감사하라. GPT-5 사례처럼 모델이 좋아지면 기존 버그가 숨어있던 자리가 드러난다.
AI 코드 품질의 기준은 결국 팀이 설계한다
AI 생성 코드를 '슬롭'으로 부르는 문화가 팀에 자리잡으면 두 가지 중 하나가 일어난다. 모든 AI 출력을 과도하게 의심해 속도를 죽이거나, 반대로 비판을 터부시해 품질 게이트를 건너뛰거나. 둘 다 나쁜 결과다.
진짜 AI-First 팀의 품질 관리는 AI 코드라서 더 의심하거나 덜 검증하는 게 아니다. 출처와 무관하게 동일한 게이트를 통과시키는 것이다. 역할의 변화는 여기서 나온다. '올바른 코드를 처음부터 타이핑하는 사람'에서 '어떤 출처의 코드든 빠르게 검증되는 시스템을 설계하는 사람'으로. 이게 지금 팀 리빌딩에서 내가 가장 먼저 묻는 질문이다: 이 팀은 AI가 짠 코드와 사람이 짠 코드를 같은 파이프라인에서 검증하고 있나?