AI가 작성한 코드를 위한 품질 관문, aislop 소개
출처: Dev.to
나는 PR을 검토하면서 “괜찮아 보이는데, 아니었어” 하는 상황에 지쳤다.
코드는 컴파일되고, 테스트는 통과하고, diff도 합리적으로 보였다. 그런데 중간 어딘가에 모든 오류를 삼키는 catch 블록이 있거나, 가짜 데이터를 반환하는 TODO가 있거나, 타입 작업을 마치지 못한 에이전트가 남긴 as any 캐스트가 있었다.
AI가 만든 코드에 대해 사람들이 과소평가하는 부분이 바로 이것이다. 첫 번째 문제는 코드가 명백히 깨졌다는 것이 아니라, 종종 보기에 괜찮아 보인다는 점이다.
나는 그 빈틈을 메우기 위해 aislop 을 만들었다.
aislop은 프로덕션에 배포되기 전에 AI가 작성한 코드를 스캔하는 오픈소스 CLI다. 프롬프트가 동작하도록 최적화하려는 AI 코딩 에이전트가 남기는 패턴을 찾아낸다.
한 번 실행해 보라:
npx aislop@latest scan또는 설치해서 로컬 워크플로에 포함시키자:
npm install --save-dev aislop
aislop scan --changesaislop은 코드를 점수화하고, 발견 사항을 보고하며, 기계적인 문제를 자동으로 고칠 수도 있다. 더 중요한 부분은 게이트이다: 팀이 AI 슬롭을 정상화되기 전에 잡을 수 있게 해준다.
Claude Code, Cursor, Codex, Copilot 등 다양한 코딩 에이전트는 유용하다. 이것이 그들을 비판한다는 뜻은 아니다. 나는 실제 엔지니어링 작업을 더 빠르게 만들기 때문에 사용한다.
하지만 에이전트는 인간과 다른 실패 프로파일을 가진다.
- 오류 처리를 작성해 함수가 예외를 던지지 않게 만들지만, 실제 실패를 가릴 수 있다.
- 코드 자체를 설명하기보다는 결정 이유를 설명하는 주석을 추가한다.
- 기존 헬퍼를 찾기 위해서는 컨텍스트가 필요한데, 이를 몰라 헬퍼를 중복 생성한다.
- 컴파일러가 작업을 방해한다는 이유로 타입 오류를
as any로 캐스팅한다.
이것이 에이전트가 쓸모없다는 뜻은 아니다. 단지 출력물에 다른 품질 게이트가 필요하다는 뜻이다.
기존 린터와 테스트, 타입 체크는 여전히 중요하다. aislop은 그 도구들 옆에 서서 더 좁은 질문을 던진다:
AI 코딩 에이전트가 이 코드를 유지보수하기 어렵게 만들 패턴을 남겼는가?
흔히 발견되는 패턴
- 스스로 설명이 가능한 코드 위에 달린 서술형 주석
- 예외를 삼키는
catch블록 및 빈 폴백 - 위험한
as any캐스팅 - 존재하지 않는(환각된) import 구문
- 중복된 헬퍼와 죽은(dead) 코드
- 프로덕션에 남은
TODO스텁 - 하드코딩된 환경값
- 에이전트가 계속해서 파일·함수에 내용을 추가해 만든 과도하게 큰 파일/함수
이러한 문제들은 첫날에 버그가 아닐 수도 있다. 그래서 리뷰를 통과한다. 하지만 누적되면 파일이 시끄러워지고, 타입이 약해지며, 오류 처리가 신뢰성을 잃고, 중복 로직이 늘어나며, 향후 변경이 느려진다.
일반 목적 린터는 인간이 작성한 코드를 염두에 두고 설계되었다. 포맷팅 문제, 사용되지 않는 변수, 위험한 문법 등 여러 유용한 정확성 문제를 잡아준다. 하지만 에이전트 출력물에 반복되는 특성을 완전히 이해하지는 못한다.
예를 들어, 린터는 다음 코드를 잡을 수 있다:
try {
await sync();
} catch {}하지만 다음 코드는 잡지 못한다:
try {
await sync();
} catch {
return [];
}두 번째 버전은 에이전트가 자주 쓰는 형태다. 오류 처리처럼 보이지만, 프로덕션에서는 “동기화 실패”와 “레코드가 없음”이 동일하게 처리된다.
그런 패턴을 잡아내기 위해 aislop이 만들어졌다.
사용 예시
변경된 파일부터 스캔한다:
aislop scan --changes그 다음 CI에 추가한다:
aislop ci --changes --base origin/main팀이 에이전트 훅을 사용한다면 하나 설치한다:
aislop hook install --claude목표는 간단하다: AI 보조 개발의 속도는 유지하되, 품질이 낮은 잔여물이 눈에 띄지 않게 병합되는 것을 막는다.
aislop 뒤에 숨은 베팅은 이렇다: AI 코딩 에이전트는 앞으로도 계속 존재할 것이므로, 코드 품질 도구도 그에 맞게 진화해야 한다.