코드에서의 AI Slop(AI 슬롭)이란 무엇인가?

코드에서의 AI slop(AI 슬롭)은 단순히 망가진 결과물을 의미하는 것이 아닙니다. 그것은 테스트는 통과하지만 코드베이스(codebase)를 유지보수하기 더 어렵게 만드는 생성된 코드입니다.

코드에서의 AI slop은 컴파일에 실패하는 코드와는 다릅니다.

이 점이 중요한 부분입니다.

대부분의 AI slop은 컴파일됩니다. 해피 패스(happy-path) 테스트를 통과합니다. 티켓(ticket) 요구사항을 충족합니다. 변경 사항(diff)을 빠르게 훑어본다면 괜찮아 보입니다.

문제는 그것이 시스템이 어떻게 노후화되어야 하는지 고민하는 엔지니어가 아니라, 프롬프트(prompt)를 완성하는 모델의 지문을 담고 있다는 점입니다. 그대로 방치하면, 그 지문들은 기술 부채(technical debt)로 변합니다.

유용한 정의

코드에서의 AI slop은 기능적으로 작동하는 것처럼 보이지만 유지보수성(maintainability), 신뢰성(reliability), 또는 명확성(clarity)을 약화시키는 생성된 코드입니다.

이것은 "작업이 완료되었다"라고 말하면서, 조용히 시스템을 다루기 더 어렵게 만드는 코드입니다.

이는 침묵하는 에러 처리(silent error handling), 가짜 기본값(fake defaults), 안전하지 않은 타입 캐스팅(unsafe type casts)을 의미할 수 있습니다. 또한 복사된 유틸리티(utilities), 불필요한 주석(noisy comments), 또는 에이전트 세션(agent session)을 벗어나서는 안 되었을 프로덕션 스텁(production stubs)을 의미할 수도 있습니다.

공통적인 특징은 코드가 명백히 망가져 있다는 것이 아닙니다. 공통적인 특징은 코드가 판단력(judgment)이 낮다는 것입니다.

예시: 서술형 주석 (narrative comments)

에이전트(Agents)들은 종종 다음과 같이 주석을 작성합니다:

// 사용자들이 알파벳 순서로 나타나도록 이름을 기준으로 정렬합니다
const sortedUsers = [...users].sort((a, b) => a.name.localeCompare(b.name));

이 주석은 문법적으로 정확합니다. 하지만 쓸모가 없습니다. 코드가 이미 그 내용을 말해주고 있기 때문입니다.

좋은 주석은 제약 사항(constraint)을 설명해야 합니다:

// 이름에 악센트가 포함되어 있으므로, 제품 요구사항에 따라 로케일(locale)을 인식하는 정렬을 적용합니다.
const sortedUsers = [...users].sort((a, b) =>
  a.name.localeCompare(b.name, userLocale),
...

첫 번째 주석은 서술(narration)입니다. 두 번째 주석은 결정 사항(decision)을 보존합니다.

이 차이는 매우 중요합니다. 생성된 코드는 파일들을 서술형 주석으로 채울 수 있기 때문입니다. 그러면 리뷰어(Reviewers)들은 엔지니어링 신호(engineering signal)를 담고 있지 않은 글자들을 읽는 데 더 많은 시간을 소비하게 됩니다.

예시: 삼켜진 예외 (swallowed exceptions)

이것은 가장 위험한 패턴 중 하나입니다:

async function loadInvoices(customerId: string): Promise<Invoice[]> {
  try {
    return await billingApi.invoices(customerId);
...

이제 이 함수는 "고객에게 송장이 없음"과 "결제 API(billing API)가 실패함"을 동일한 이벤트로 취급합니다.

이것은 회복탄력성 (resilience)이 아닙니다. 정보의 손실입니다.

AI 에이전트 (AI agents)가 이렇게 작성하는 이유는 함수를 사용하기 쉽게 만들기 때문입니다. 호출자 (callers)가 에러 처리 (error handling)를 할 필요가 없고, 테스트를 작성하기 쉬우며, 기능 구현이 계속 진행될 수 있습니다.

그러다 운영 환경 (production)에서 문제가 발생하면, 왜 UI에 송장이 없다고 표시되는지 아무도 모르게 됩니다.

예시: 안전하지 않은 캐스트 (unsafe casts)

모델이 타입 불일치 (type mismatch) 문제에 막히면, 종종 캐스트 (cast)를 시도합니다:

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

컴파일러 (compiler)는 더 이상 불평하지 않습니다. 진짜 문제는 런타임 (runtime)으로 옮겨집니다.

하나의 as any는 국소적인 타협일 수 있습니다. 하지만 코드베이스 전반에 걸쳐 수십 개가 존재한다면, 이는 타입 시스템 (type system)이 보호 수단이 아닌 장식용으로 사용되고 있다는 신호입니다.

AI 보조 팀 (AI-assisted teams)에서는 이러한 현상이 빠르게 누적될 수 있습니다. 에이전트들은 전체 시스템의 타입 규율 (type discipline)을 유지하는 것이 아니라, 요청된 변경 사항을 완료하는 것에 최적화되어 있기 때문입니다.

예시: 중복된 헬퍼 함수 (duplicate helpers)

에이전트들은 재사용하는 대신 종종 새로 생성합니다.

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

이 헬퍼 함수는 이미 존재할 수도 있습니다. 새로 복사된 코드는 작동하며, 테스트도 통과합니다. 향후 변경 사항이 발생하여 한 버전은 업데이트되고 다른 버전은 업데이트되지 않을 때까지 아무도 알아차리지 못합니다.

이것이 AI 슬롭 (AI slop)이 종종 집합적인 문제인 이유입니다. 단 하나의 중복된 헬퍼 함수는 위기가 아닙니다. 하지만 그것들로 가득 찬 코드베이스는 변경 속도가 느려집니다.

이것이 중요한 이유

AI 슬롭이 중요한 이유는 에이전트가 인간이 거의 따라갈 수 없는 속도로 이를 생성할 수 있기 때문입니다.

인간은 긴 디버깅 세션 후에 안전하지 않은 캐스트를 하나 도입할 수 있습니다. 하지만 에이전트는 하나의 PR (Pull Request)에서 열 개를 도입할 수 있습니다. 인간은 허술한 폴백 (fallback)을 하나 남길 수 있지만, 에이전트는 동일한 폴백 패턴을 기능 전체에 퍼뜨릴 수 있습니다.

그것은 리뷰의 경제성을 변화시킵니다. 더 크고 빠른 디프 (diff) 내에서 반복되는 모든 패턴을 발견하기 위해 오직 인간 리뷰어에게만 의존할 수는 없습니다.

다음과 같은 일반적인 도구들이 필요합니다:

• 테스트 (tests)
• 타입 체크 (typechecking)
• 린팅 (linting)
• 보안 점검 (security checks)
• 코드 리뷰 (code review)

그리고 AI 출력물에 맞춰 조정된 게이트 (gate)가 필요합니다.

그 지점에 aislop이 적합합니다. aislop은 AI 코딩 에이전트가 남기는 반복적인 패턴을 스캔하여, 코드가 머지 (merge) 되기 전에 이를 가시적인 결과물로 변환합니다.

AI가 생성한 코드는 사라지지 않을 것입니다. 이를 배포하는 표준은 더욱 날카로워져야 합니다.