AI 슬롭(AI Slop)이 소프트웨어 엔지니어링의 문제가 되고 있다

AI 코딩 도구들은 소프트웨어가 작성되는 방식을 변화시켰습니다.

개발자들은 이제 Cursor, Claude Code, Codex, Copilot, Windsurf, Cline, Lovable, Bolt 및 기타 에이전트형 도구(agentic tools)를 사용하여 그 어느 때보다 빠르게 작업하고 있습니다. 이들은 몇 분 만에 컴포넌트를 생성하고, 서비스를 리팩터링(refactor)하며, 테스트를 작성하고, API 스캐폴딩(scaffold)을 수행하며, 프레임워크를 마이그레이션(migrate)하고, 생소한 코드베이스(codebases)를 설명할 수 있습니다.

그 속도는 실재합니다.

하지만 그 과정에서 남겨지는 엉망인 결과물 또한 실재합니다.

AI 코딩 에이전트를 더 많이 사용할수록, 서로 다른 프로젝트에서 동일한 패턴이 나타나는 것을 발견하기 시작했습니다. 항상 깨진 코드는 아니었습니다. 항상 명백히 나쁜 코드도 아니었습니다. 하지만 무언가 약간 어색하게 느껴지는 코드였습니다.

빠른 점검을 통과할 만큼은 작동하지만, 이상한 결정, 불필요한 래퍼(wrappers), 삼켜진 에러(swallowed errors), 가짜처럼 보이는 추상화(abstractions), 사용되지 않는 임포트(unused imports), 하드코딩된 값(hardcoded values), 중복된 로직(duplicated logic), 그리고 자신감 있게 들리지만 아무런 가치도 더하지 않는 주석들을 포함하고 있는 코드 말입니다.

이것이 제가 **AI 슬롭(AI slop)**이라고 부르는 것입니다.

AI가 생성한 코드가 자동으로 나쁘기 때문이 아닙니다. 그렇지 않습니다. 그중 일부는 진정으로 유용합니다.

AI 슬롭은 코드가 빠르게 생성되었지만, 적절하게 정리되거나 검증되지 않았거나, 혹은 유지보수 가능한 형태로 다듬어지지 않았을 때 남겨지는 잔여물입니다.

그리고 더 많은 AI 작성 코드가 프로덕션(production) 환경에 도달함에 따라, 저는 이것이 차세대 중요한 소프트웨어 엔지니어링 문제 중 하나가 되고 있다고 생각합니다.

AI 슬롭의 모습

AI 슬롭은 단 하나의 현상을 의미하지 않습니다.

이는 코딩 에이전트가 도움을 주려 하거나, 방어적으로 행동하거나, 혹은 지나치게 완벽을 기하려 할 때 나타나는 일련의 패턴 범주입니다.

예를 들어:

try {
  await saveUser(user);
} catch (error) {
...

이와 같이 삼켜진 에러(swallowed error)는 생성된 흐름 속에서는 무해해 보일 수 있지만, 프로덕션 환경에서는 디버깅에 꼭 필요한 정확한 실패 원인을 숨길 수 있습니다.

또 다른 흔한 사례는 다음과 같습니다:

const data = response as any;

이것은 전형적인 "TypeScript가 불평하지 못하게 만들기" 위한 수법입니다. 컴파일러(compiler)를 통과하게는 해주지만, 애초에 TypeScript를 사용했던 목적이었던 안전성을 제거해 버립니다.

그다음에는 다음과 같은 것들을 보게 됩니다:

// 이 함수는 사용자 데이터를 처리하고 처리된 사용자 데이터를 반환합니다
function processUserData(userData) {
  return userData;
...

주석은 아무런 정보도 더해주지 않습니다. 함수 또한 아무런 역할도 하지 않습니다. 하지만 코드베이스에는 이제 더 많은 노이즈(noise)가 쌓였습니다.

다른 사례들은 다음과 같습니다:

• 여러 번의 에이전트 반복(agent iterations) 후에 남겨진 사용되지 않는 임포트(unused imports)
• 하드코딩된 URL, ID 또는 설정 값(configuration values)
• 영구적으로 남게 된 TODO 주석
• 이미 타입이 지정된 입력값에 대한 과도하게 방어적인 검증(over-defensive validation)
• 코드베이스의 다른 곳에 이미 존재하는 타입을 재선언하는 행위
• 이전 시도에서 남겨진 데드 코드(dead code)
• 이름이 절반만 변경된 변수
• 중복된 헬퍼 함수(helper functions)
• 프로덕션 경로에 남겨진 콘솔 로그(console logs)
• 실제 실패를 숨기는 광범위한 catch 블록
• 환각(hallucinated)된 임포트 또는 의존성
• 한 번의 실행으로 생성된 지나치게 거대한 함수

개별적으로 보면 각각은 작아 보일 수 있습니다.

하지만 이들이 모이면 코드베이스를 신뢰하기 어렵게 만듭니다.

문제는 AI가 나쁜 코드를 작성한다는 것이 아니다

저는 "AI 코드는 나쁘다"라고 규정하는 것이 적절한 프레이밍(framing)이라고 생각하지 않습니다.

그것은 너무 게으른 접근입니다.

진짜 문제는 AI 코딩 에이전트(coding agents)가 '완성(completion)'을 최적화한다는 점입니다. 그들은 프롬프트(prompt)를 만족시키고, 그럴듯한 결과물을 만들어내며, 워크플로우(workflow)를 계속 진행시키는 데 집중합니다.

이는 에이전트가 코드를 제대로 다듬기 전에, 마치 완료된 것처럼 보이는 코드를 생성하는 경우가 많음을 의미합니다.

물론 인간 개발자도 이런 실수를 합니다.

차이점은 규모(scale)입니다.

개발자는 지저분한 코드를 천천히 작성할 수 있지만, AI 에이전트는 단 몇 초 만에 여러 파일에 걸쳐 지저분한 코드를 생성할 수 있습니다.

이것이 리뷰(review) 문제를 변화시킵니다.

이전의 코드 리뷰는 주로 다른 인간이 의도적으로 작성한 내용을 확인하는 것이었습니다. 이제 리뷰에는 에이전트가 무엇을 생성했는지, 왜 그것을 생성했는지, 그것이 주변 코드베이스와 실제로 잘 어우러지는지, 그리고 미묘한 유지보수 부채(maintainability debt)를 유발하지는 않았는지를 확인하는 과정이 점점 더 포함되고 있습니다.

이것은 차원이 다른 종류의 부담입니다.

기존 도구들은 진정으로 이를 위해 만들어지지 않았다

우리에겐 이미 린터(linters), 포매터(formatters), 정적 분석 도구(static analysis tools), 타입 체커(type checkers), 보안 스캐너(security scanners), 그리고 AI 코드 리뷰어가 있습니다.

이들 모두 중요합니다.

ESLint는 구문(syntax) 및 스타일 문제를 잡아낼 수 있습니다. TypeScript는 타입 오류(type errors)를 잡아낼 수 있습니다. Snyk는 알려진 취약점(vulnerabilities)을 잡아낼 수 있습니다. Sonar는 품질 문제를 표시할 수 있습니다. AI 리뷰 도구는 풀 리퀘스트(pull requests)에 코멘트를 달 수 있습니다.

하지만 AI 슬롭(AI slop)은 약간 다른 영역에 위치합니다.

그것은 항상 컴파일러 오류(compiler error)인 것은 아닙니다.

그것은 항상 보안 취약점(security vulnerability)인 것도 아닙니다.

그것은 항상 포매터(formatter)가 수정할 수 있는 것도 아닙니다.

그리고 풀 리퀘스트(pull request) 리뷰 단계에 도달했을 때, 코드는 이미 개발자의 워크플로(workflow)에 수용된 상태입니다. 이제 누군가는 그것을 풀어내기 위해 시간을 써야만 합니다.

더 일찍 발견할수록, 수정 비용은 더 저렴해집니다.

그렇기 때문에 저는 차세대 개발자 도구(developer tooling)가 생성 시점(point of generation)에 더 가까워져야 한다고 생각합니다.

단순히 풀 리퀘스트(pull request) 이후가 아니라.

단순히 CI 이후가 아니라.

에이전트(agent)가 코드를 생성하고 있는 바로 그 순간에 말입니다.

AI 생성 코드에는 품질 게이트(quality gate)가 필요합니다

에이전트가 개발 워크플로(development workflow)의 일부가 될 때, 그들에게도 가드레일(guardrails)이 필요합니다.

AI 생성 코드를 위한 품질 게이트(quality gate)는 빠르고, 결정론적(deterministic)이며, 로컬에서 실행하기 쉬워야 합니다. 출력을 판단하기 위해 또 다른 거대 모델(large model)을 필요로 해서는 안 됩니다. 매번 다른 답을 내놓아서도 안 됩니다. 개발자들이 이미 위험하거나 소음(noisy)이라고 알고 있는 반복적인 패턴을 잡아낼 수 있어야 합니다.

그것이 제가 **aislop**을 통해 탐구해 온 방향입니다.

aislop은 AI 코딩 에이전트(AI coding agents)가 흔히 남기는 패턴을 코드를 스캔하는 오픈 소스 CLI입니다. 이 도구는 점수를 부여하고, 발견된 사항을 강조하며, 삼켜진 에러(swallowed errors), 안전하지 않은 as any, 데드 코드(dead code), 환각된 임포트(hallucinated imports), 하드코딩된 값(hardcoded values), 무의미한 주석(useless comments), 과도하게 큰 함수(oversized functions) 및 기타 슬롭(slop) 패턴에 집중합니다.

목표는 인간의 리뷰(human review)를 대체하는 것이 아닙니다.

목표는 명백한 AI 생성 쓰레기가 애초에 인간의 리뷰 단계에 도달하는 것을 막는 것입니다.

간단한 워크플로(workflow)는 다음과 같습니다:

npx aislop scan

또는 에이전틱 워크플로(agentic workflow) 내부에서:

npx aislop scan --json

에이전트가 코드를 작성하고, 스캐너가 실행되며, 코드가 풀 리퀘스트(pull request)에 도달하기 전에 피드백이 루프(loop)로 다시 전달됩니다.

이 부분이 제가 가장 흥미롭다고 생각하는 지점입니다.

단순히 다음과 같이 요청하는 것이 아니라:

내 저장소(repo)를 스캔해줘.

다음과 같이 요청하는 것입니다:

작업이 완료되었다고 말하기 전에, 코드가 계속 진행하기에 충분히 깨끗하다는 것을 증명해줘.

바로 이 지점에서 이 카테고리가 유용해집니다.

결정론적 검사(Deterministic checks)는 여전히 중요하다

LLM 기반의 코드 리뷰에 대해 많은 기대가 모이고 있으며, 그 이유를 이해합니다. LLM은 단순한 규칙이 놓칠 수 있는 것들을 설명하고, 추론하며, 잡아낼 수 있습니다.

하지만 모든 것에 또 다른 모델이 필요한 것은 아닙니다.

어떤 패턴들은 본질적으로 결정론적(deterministic)입니다.

비어 있는 catch 블록은 존재하거나, 존재하지 않거나 둘 중 하나입니다.

안전하지 않은 캐스트(unsafe cast)는 존재하거나, 존재하지 않거나 둘 중 하나입니다.

사용되지 않는 임포트(unused import)는 존재하거나, 존재하지 않거나 둘 중 하나입니다.

하드코딩된 비밀값(secret-like value) 같은 것은 존재하거나, 존재하지 않거나 둘 중 하나입니다.

거대한 생성 함수, 반복되는 헬퍼(helpers), 쓸모없는 주석이 포함된 파일은 LLM으로 보내지 않고도 점수를 매기고 플래그(flag)를 지정할 수 있습니다.

이것이 중요한 이유는 결정론적 도구들이 빠르고, 저렴하며, 반복 가능하고, CI(지속적 통합) 환경에서 더 신뢰하기 쉽기 때문입니다.

코드가 더 빈번하게 생성됨에 따라, 우리는 그 속도를 따라갈 수 있는 도구가 필요합니다.

오탐(False positives)이 어려운 부분이다

이런 종류의 도구를 만드는 가장 어려운 부분은 나쁜 패턴을 찾는 것이 아닙니다.

게으른 판단을 피하는 것입니다.

슬롭(slop)처럼 보이는 코드와, 타당한 이유로 의도적으로 특정 방식으로 작성된 코드 사이에는 큰 차이가 있습니다.

그렇기 때문에 오탐(false positives)이 매우 중요합니다.

저는 누군가가 성숙한 오픈 소스 Python 프로젝트에 aislop를 실행했을 때 점수가 나쁘게 나온 경험을 통해 이를 어렵게 배웠습니다. 언뜻 보기에는 도구가 많은 문제를 찾아낸 것처럼 보였습니다. 하지만 발견된 사항들을 하나씩 검토해 보니, 상당수가 실제 문제가 아니었습니다. 그것들은 제 자체적인 탐지 로직의 버그였습니다.

그래서 저는 그것들을 수정했습니다.

그 경험이 도구를 더 낫게 만들었습니다.

또한 이는 철학을 더 명확하게 만들어 주었습니다. 목표는 코드베이스를 비난하거나 극적인 점수를 만들어내는 것이 아닙니다. 목표는 개발자들이 AI 보조 개발 (AI-assisted development) 과정에서 남은 잔여물을 정리하는 데 도움이 되는 유용하고 공정한 피드백을 제공하는 것입니다.

이러한 도구는 개발자들이 분석 결과를 보고 다음과 같이 말할 수 있을 때에만 신뢰를 얻을 수 있습니다.

그래, 이건 타당해.

이 카테고리는 더욱 중요해질 것입니다

코드 에이전트 (code agents)가 더 많은 코드를 작성할수록, 팀들은 에이전트 출력물에 대한 표준을 더 많이 필요로 하게 될 것입니다.

저는 다음과 같은 질문들이 나타나기 시작할 것이라고 생각합니다:

• 에이전트가 불필요한 추상화 (abstractions)를 도입했는가?
• 데드 코드 (dead code)를 남겨두었는가?
• 에러를 삼켜버렸는가 (swallowed errors)?
• 코드를 강제로 통과시키기 위해 안전하지 않은 형변환 (unsafe casts)을 사용했는가?
• 기존에 있던 것을 재사용하는 대신 기존 로직을 중복시켰는가?
• 아무것도 설명하지 못하는 주석을 생성했는가?
• 설정 (config)에 있어야 할 것들을 하드코딩 (hardcode)했는가?
• 로컬에서는 통과하지만 장기적인 유지보수 부채 (maintenance debt)를 생성하는 코드를 만들었는가?

이것들은 이론적인 질문이 아닙니다.

이미 실제 워크플로우 (workflows)에서 나타나고 있습니다.

AI 코딩 도구로부터 가장 큰 이득을 얻는 기업과 팀은 생성된 모든 디프 (diff)를 맹목적으로 수용하는 곳이 아닐 것입니다. 그들은 생성 (generation), 검증 (validation), 테스트 (testing), 리뷰 (review) 및 정리 (cleanup)를 중심으로 강력한 피드백 루프 (feedback loops)를 구축하는 팀이 될 것입니다.

AI는 우리가 코드를 더 빠르게 작성하도록 도울 수 있습니다.

하지만 품질 관리 (quality control) 없는 속도는 병목 현상 (bottleneck)을 단지 다른 곳으로 옮길 뿐입니다.

도구: aislop

이것이 제가 aislop을 만들기 시작한 이유입니다.

aislop은 AI 코딩 에이전트가 자주 남기는 종류의 코드 품질 문제를 탐지하기 위한 오픈 소스 CLI (Command Line Interface)입니다. 로컬에서 코드베이스를 스캔하여 0에서 100 사이의 점수를 부여하며, 에러 삼킴 (swallowed errors), 안전하지 않은 as any, 데드 코드 (dead code), 환각된 임포트 (hallucinated imports), 하드코딩된 값 (hardcoded values), 쓸모없는 주석, 비대해진 함수 (oversized functions), 중복된 로직 및 기타 AI 생성 난장판의 징후와 같은 패턴을 강조 표시합니다.

다음 명령어로 시도해 볼 수 있습니다:

npx aislop scan

CI 또는 에이전트 워크플로우 (agentic workflows)를 위해서는 JSON 출력도 사용할 수 있습니다:

npx aislop scan --json

링크:

• GitHub: github.com/scanaislop/aislop
• npm: npmjs.com/package/aislop
• Website: scanaislop.com

아이디어는 간단합니다:

AI가 생성한 코드가 풀 리퀘스트 (Pull Request) 리뷰에 도달하기 전에, 빠르고 결정론적인 (deterministic) 품질 게이트 (quality gate)를 실행하는 것입니다.

사람의 리뷰를 대체하기 위함이 아닙니다.

에이전트 (agent)나 개발자가 여전히 빠르게 수정할 수 있는 시점에, 명백한 슬롭 (slop)을 조기에 잡아내기 위함입니다.