aislop 소개: AI가 작성한 코드를 위한 품질 게이트 (Quality Gate)

겉보기에는 괜찮아 보이지만 실제로는 그렇지 않은 풀 리퀘스트 (Pull Request)를 리뷰하는 것에 지쳤습니다.

코드는 컴파일되었고, 테스트는 통과했습니다. 변경 사항 (Diff)도 합리적으로 보였습니다. 하지만 그 중간 어딘가에 모든 에러를 삼켜버리는 catch 블록이 숨겨져 있거나, 가짜 데이터를 반환하는 TODO가 있거나, 에이전트 (Agent)가 타입 작업을 끝내지 못해 발생한 또 다른 as any 캐스팅 (Cast)이 있었습니다.

이것이 사람들이 AI 생성 코드에 대해 과소평가하는 부분입니다. 첫 번째 문제는 코드가 명백하게 망가져 있다는 것이 아닙니다. 첫 번째 문제는 그것이 종종 수용 가능한 것처럼 보인다는 점입니다.

저는 그 간극을 메우기 위해 [aislop](https://github.com/scanaislop/aislop)을 만들었습니다.

aislop이란 무엇인가

aislop은 AI가 작성한 코드가 프로덕션 (Production)에 도달하기 전에 스캔하는 오픈 소스 CLI (Command Line Interface)입니다. 이 도구는 코딩 에이전트들이 "코드베이스를 건강하게 유지하기"보다는 "프롬프트(Prompt)가 작동하게 만들기"를 최적화할 때 남기는 패턴들을 찾아냅니다.

한 번 실행하려면:

npx aislop@latest scan

또는 설치하여 로컬 워크플로 (Workflow)의 일부로 만들 수 있습니다:

npm install --save-dev aislop
aislop scan --changes

이 도구는 코드에 점수를 매기고, 발견 사항을 보고하며, 기계적인 문제들을 자동으로 수정 (Auto-fix)할 수 있습니다. 더 중요한 부분은 게이트 (Gate) 역할입니다. 즉, 팀이 AI 슬롭 (Slop)이 일상이 되기 전에 이를 잡아낼 수 있는 방법을 제공합니다.

해결하는 문제

Claude Code, Cursor, Codex, Copilot 및 기타 코딩 에이전트들은 유용합니다. 이것은 그들에 반대하는 주장이 아닙니다. 저 또한 실제 엔지니어링 작업을 더 빠르게 만들기 위해 이들을 사용합니다.

하지만 에이전트들은 인간과는 다른 실패 프로필 (Failure Profile)을 가집니다.

에이전트들은 실제 실패를 숨기더라도 함수가 더 이상 에러를 던지지 않게 만드는 에러 핸들링 (Error Handling)을 작성합니다. 결정 사항을 설명하는 대신 코드를 설명하는 주석을 추가합니다. 기존 헬퍼 (Helper)를 찾는 데 컨텍스트 (Context)가 필요하기 때문에 헬퍼를 중복해서 만듭니다. 컴파일러 (Compiler)가 작업을 완료하는 데 방해가 된다는 이유로 타입 에러 (Type Error)를 무시하며 캐스팅합니다.

이 중 어느 것도 에이전트가 쓸모없다는 뜻은 아닙니다. 그 출력물에는 다른 종류의 품질 게이트 (Quality Gate)가 필요하다는 의미입니다.

기존의 린터 (Linter)도 여전히 중요합니다. 테스트 (Tests)도 중요합니다. 타입 체크 (Typechecking)도 중요합니다. aislop은 이러한 도구들과 나란히 자리하며, 더 좁고 구체적인 질문을 던집니다:

AI 코딩 에이전트가 이 코드를 유지보수하기 더 어렵게 만드는 패턴을 남겨두었는가?

탐지 대상

주요 탐지 항목은 다음과 같습니다:

• 설명이 필요 없는 코드 위에 작성된 서술형 주석 (Narrative comments)
• 예외를 삼켜버리는 처리 (Swallowed exceptions) 및 빈 폴백 (Empty fallbacks)
• 안전하지 않은 as any 캐스팅 (Casts)
• 환각된 임포트 (Hallucinated imports)
• 중복된 헬퍼 (Duplicated helpers) 및 데드 코드 (Dead code)
• 운영 환경의 TODO 스텁 (Production TODO stubs)
• 하드코딩된 환경 변수 값 (Hardcoded environment values)
• 에이전트가 계속해서 내용을 추가하여 비대해진 파일 및 함수

이러한 요소들이 첫날부터 항상 버그인 것은 아닙니다. 그렇기 때문에 코드 리뷰를 통과하곤 합니다. 하지만 그 피해는 누적됩니다. 파일은 더 지저분해지고, 타입은 약해지며, 에러 핸들링 (Error handling)의 신뢰도는 떨어지고, 중복 로직은 늘어나며, 향후 변경 작업 속도는 느려지게 됩니다.

전용 도구가 필요했던 이유

범용 린터 (General-purpose linters)는 사람이 작성한 코드를 중심으로 설계되었습니다. 이들은 포맷팅 문제, 사용되지 않는 변수, 안전하지 않은 구문, 그리고 유용한 정적 분석 문제들을 잡아냅니다. 하지만 에이전트 출력물에서 반복되는 특유의 지문 (Fingerprints)을 완전히 이해하지는 못합니다.

예를 들어, 린터는 다음과 같은 코드를 잡아낼 수 있습니다:

try {
  await sync();
} catch {}

하지만 다음과 같은 코드는 아마 잡아내지 못할 것입니다:

try {
  await sync();
} catch {
...

두 번째 버전은 에이전트들이 자주 작성하는 방식입니다. 겉보기에는 에러 핸들링처럼 보입니다. 하지만 운영 환경에서는

저장소(Repo): github.com/scanaislop/aislop
사이트(Site): scanaislop.com