코드에서 AI 슬롭이란?

출처: Dev.to

AI 슬롭(AI slop) 코드는 단순히 깨진 출력이 아니다. 테스트를 통과하지만 코드베이스 유지보수를 어렵게 만드는 생성된 코드이다.

AI 슬롭 코드는 컴파일 자체가 실패하는 코드와는 다르다.

그 부분이 핵심이다.

대부분의 AI 슬롭은 컴파일된다. 행복한 경로(happy‑path) 테스트를 통과한다. 티켓 요구사항을 만족한다. 차이를 빠르게 훑어보면 괜찮아 보인다.

문제는 그 코드가 엔지니어가 시스템의 장기적인 모습을 고민해서 만든 것이 아니라, 모델이 프롬프트를 완성한 흔적을 가지고 있다는 점이다. 이런 흔적은 그대로 두면 기술 부채가 된다.

유용한 정의

AI 슬롭 코드는 기능적으로 보이지만 유지보수성, 신뢰성 또는 가독성을 약화시키는 생성된 코드이다.

즉, “작업이 완료되었습니다”라고 말하면서도 시스템을 작업하기 어렵게 만든다.

이는 조용한 오류 처리, 가짜 기본값, 위험한 타입 캐스트, 복제된 유틸리티, 시끄러운 주석, 혹은 에이전트 세션을 떠나서는 안 될 프로덕션 스텁 등을 의미할 수 있다.

공통점은 코드가 명백히 깨진 것이 아니라 판단력이 낮은 코드라는 점이다.

예시: 서술형 주석

에이전트는 종종 다음과 같은 주석을 쓴다:

// We are sorting the users by name so they appear in alphabetical order
const sortedUsers = [...users].sort((a, b) => a.name.localeCompare(b.name));

주석은 문법적으로 맞지만 쓸모가 없다. 코드 자체가 이미 그 의미를 담고 있다.

좋은 주석은 제약 조건을 설명한다:

// Product wants locale-aware sorting here because names include accents.
const sortedUsers = [...users].sort((a, b) =>
  a.name.localeCompare(b.name, userLocale),
);

첫 번째 주석은 단순 서술이고, 두 번째 주석은 의사결정을 보존한다.

이 차이는 중요하다. 생성된 코드는 파일을 서술로 가득 채울 수 있다. 리뷰어는 엔지니어링 신호가 없는 단어를 읽는 데 더 많은 시간을 소비하게 된다.

예시: 예외를 삼키기

가장 위험한 패턴 중 하나다:

async function loadInvoices(customerId: string): Promise {
  try {
    return await billingApi.invoices(customerId);
  } catch {
    return [];
  }
}

함수는 “고객에게 청구서가 없음”과 “청구 API가 실패함”을 동일한 상황으로 처리한다.

이는 복원력이 아니라 정보 손실이다.

AI 에이전트는 이 코드를 작성한다. 함수 사용이 쉬워지고, 호출자는 오류 처리를 할 필요가 없으며, 테스트 작성도 간단해진다. 기능은 계속 진행된다.

하지만 프로덕션에서 문제가 발생하고 UI에 청구서가 없다고 표시되는 이유를 아무도 알 수 없게 된다.

예시: 위험한 캐스트

모델이 타입 불일치에 막히면 종종 캐스트를 사용한다:

const user = response.data as any;
return user.profile.id;

컴파일러는 더 이상 오류를 제기하지 않는다. 실제 문제는 런타임으로 이동한다.

as any 하나는 지역적인 타협일 수 있다. 코드베이스 전체에 수십 개가 쌓이면 타입 시스템이 보호가 아니라 장식으로 쓰이고 있다는 신호다.

AI‑지원 팀에서는 에이전트가 전체 시스템의 타입 규율을 유지하기보다 요청된 변경을 빠르게 완성하는 데 집중하기 때문에 이런 현상이 빠르게 누적된다.

예시: 중복 헬퍼

에이전트는 재사용보다 재생성을 선호한다.

export function formatCurrency(amount: number): string {
  return new Intl.NumberFormat("en-US", {
    style: "currency",
    currency: "USD",
  }).format(amount);
}

이 헬퍼는 이미 존재할 수도 있다. 새 복사본도 동작하고 테스트를 통과한다. 누군가가 미래에 한 버전만 수정하고 다른 버전은 그대로 두면 문제가 발생한다.

AI 슬롭이 흔히 집합적인 문제인 이유다. 하나의 중복 헬퍼가 위기가 되지는 않는다. 하지만 전체 코드베이스에 이런 중복이 가득하면 변경이 느려진다.

왜 중요한가

AI 슬롭은 에이전트가 인간보다 훨씬 빠른 속도로 생성할 수 있기 때문에 문제다.

인간은 긴 디버깅 후에 위험한 캐스트 하나를 넣을 수 있다. 에이전트는 하나의 PR에 열 개를 넣을 수 있다. 인간은 한 번의 부실한 폴백을 남길 수 있다. 에이전트는 같은 폴백 패턴을 전체 기능에 퍼뜨릴 수 있다.

이것은 리뷰 비용 구조를 바꾼다. 규모가 크고 빠른 diff에서 모든 반복 패턴을 인간 리뷰어가 다 잡아내기는 어렵다.

따라서 기존 도구가 필요하다:

• 테스트
• 타입 체크
• 린팅
• 보안 검사
• 코드 리뷰

그리고 AI 출력에 맞춘 게이트가 필요하다.

여기서 aislop이 역할을 한다. AI 코딩 에이전트가 남긴 반복 패턴을 스캔해 가시적인 이슈로 전환하고, 머지되기 전에 발견하게 만든다.

AI가 생성한 코드는 사라지지 않는다. 이를 배포하는 기준은 더욱 엄격해져야 한다.