서론

최근, no-ai-slop라는 AI 생성 문장 검지·수정 OSS와, 이를 리뷰 기준으로 재해석하는 Algomatic의 기사를 연달아 읽었습니다.

no-ai-slop는 이분법적 대립이나 출처 없는 권위 부여, 과장된 중요성 표현 등 20가지 이상의 AI 같은 문체 패턴을 정의하고 있습니다. Algomatic의 기사는 이를 "문체 수정 도구"가 아니라 "부족한 판단 자료(근거·검증·한계·판단 주체)를 보완하기 위한 프레임워크"로 재정의하는 제안이었습니다.

여기서 궁금한 점이 생겼습니다.

no-ai-slop의 검지 패턴을 코드 리뷰의 코멘트 품질 체크에 전용할 수 있을까?

구체적으로 두 가지 방식을 비교해보고 싶어졌습니다:

방식 A: no-ai-slop의 20+ 패턴으로 리뷰 코멘트의 AI스러움을 검출한다 -
방식 B: Algomatic 방식의 "판단 자료(근거·검증·한계·판단 주체)" 체크리스트로 평가한다

"AI 같지만 내용이 얕은 리뷰", "문체는 자연스럽지만 알맹이가 없는 리뷰", "제대로 된 리뷰"의 3가지 종류 샘플을 사용하여 실제로 검증해 보았습니다.

검증 방법

no-ai-slop의 실체

먼저 오해를 풀어두겠습니다. no-ai-slop는 CLI 도구가 아닙니다. Claude Code나 Codex용 에이전트 스킬(SKILL.md)입니다. 20가지 이상의 패턴 정의와 편집 규칙이 마크다운(Markdown)으로 작성되어 있으며, LLM에게 "이 규칙으로 판정/편집하라"고 지시하는 방식입니다.

검증에서는 gpt-4o-mini에 이 SKILL.md의 패턴 규칙을 시스템 프롬프트(system prompt)로 제공하여 검출 정밀도를 시뮬레이션했습니다.

사용한 샘플

11건의 핸드메이드 샘플을 준비했습니다(일부는 LLM 생성). 다음 3개 그룹으로 나뉩니다:

A군: 의도적으로 AI 냄새가 나게 만든 리뷰 코멘트 (5건)

이분법적 대립이나 weasel attribution(출처 없는 권위 부여), importance puffery(과장된 중요성 표현)를 포함한 극단적인 샘플. 알고리즘 기사에서 말하는 "중2병 수준까지 과장한" 것입니다.

// A1: 아키텍처 리뷰 (AI 문체)
"이 변경은 단순한 리팩터링 (refactoring)이 아닙니다. 그것은 아키텍처 전체의 진화입니다.
많은 전문가가 인정하듯, 이 접근 방식은 모던한 시스템 설계의 베스트 프랙티스 (best practice)이며..."

B군: 현실적인 얕은 코멘트 (3건)

문체는 자연스럽습니다. 하지만 내용이 없습니다. 실제 프로젝트에서 흔히 볼 수 있는 타입입니다.

// B1: 아키텍처 리뷰 (자연스럽지만 얕음)
"이 설계라면 나중에 확장성 (scalability) 문제가 생길 것 같습니다. 이벤트 주도 (event-driven) 방식이 더 좋을 것 같습니다.
검토해 보세요."

// B2: 버그 수정 리뷰
"LGTM입니다. null 안전 (null-safety)해져서 좋네요. 특별한 문제는 없어 보입니다."

C군: 좋은 리뷰 (control) (3건)

수치 데이터, 검증 방법, 잔여 리스크, 다음 액션을 포함한 충실한 리뷰.

// C3: 퍼포먼스 리뷰 (좋은 예)
"Good optimization. I benchmarked this locally:
- Before: 320ms avg (p95: 890ms)
...

검증 결과

결과 요약

각 샘플에 대해 no-ai-slop 패턴 검출 수와 Algomatic 기준의 fails 수(0에 가까울수록 좋음)를 비교했습니다.

NAS = no-ai-slop. 수치가 클수록 "AI 같은 문체 패턴을 많이 포함함".

Algo fails는 Algomatic 기준의 5개 항목 중 몇 개가 FAIL되었는지를 나타냄.

발견 1: no-ai-slop는 "문체의 느낌"은 잡아내지만 "내용의 얇음"은 잡아내지 못한다

A군(의도적으로 AI스럽게 만든 것)은 no-ai-slop로 3~5개의 패턴이 검출되었습니다. binary contrast(이항 대립), weasel attribution(출처 없는 권위 부여), importance puffery(중요성 과장) 등이 자주 포착됩니다. 문체 수준의 AI스러움 검출이라는 용도로는 충분히 사용할 수 있을 것 같습니다.

문제는 B군입니다. "LGTM입니다", "이 설계라면 나중에 확장성(Scalability) 문제가 생길 것 같습니다"와 같은 현실적이면서도 얇은 코멘트는 no-ai-slop 패턴 수가 0이었습니다. 완전히 통과되었습니다.

코드 리뷰에서 정말 문제가 되는 것은 바로 이러한 "문체는 자연스럽지만 판단 근거가 없는" 코멘트입니다. 강조하고 싶은 점은, AI 같은 문체가 아니더라도 리뷰는 얇아질 수 있다는 사실입니다.

발견 2: Algomatic 기준은 문체와 상관없이 얇음을 검출할 수 있다

Algomatic 방식의 5개 항목(판단 주체, 검증 방법, 구체성, 출처 유무, 책임의 명시)으로 평가했을 때, A군과 B군 모두 전수 THIN(45 fails)이었습니다. 문체의 화려함과 관계없이 판단 근거의 유무만으로 평가할 수 있었습니다. 좋은 리뷰(C군)는 MIXED(12 fails)로 나타나 명확한 차이를 보였습니다.

발견 3: 좋은 리뷰라도 Algomatic 기준은 꽤 엄격하다

다만, 일본어의 좋은 리뷰 예시(C1)에서도 2개의 fails가 발생했습니다. 내용을 자세히 살펴보면 다음과 같습니다:

"이 PR의 이벤트 주도(Event-driven)화, 설계 의도는 이해했습니다. 다만 우려되는 점이 두 가지 있습니다.
① 큐잉(Queuing)에 RabbitMQ를 사용하고 있습니다만, 현재 트래픽은 하루 1,000건 정도이므로
SQS로도 충분하다고 생각합니다. ② 장애 시의 데드 레터(Dead Letter) 설계가 정의되지 않았습니다...
...

이 리뷰는 상당히 정중합니다. 그럼에도 불구하고 "판단 주체의 명시"(리뷰어의 판단과 PR 작성자에게 맡기는 방식이 모호함)와 "남은 리스크의 명시" 항목에서 FAIL 판정을 받았습니다. Algomatic 기준을 완벽히 충족하는 리뷰는 작성하기가 상당히 까다롭다고 할 수 있습니다.

고찰: 어떤 것을 사용해야 하는가?

검증 데이터를 통해 알 수 있는 활용법입니다.

no-ai-slop는 "문체" 검출에 강점이 있고, Algomatic 기준은 "내용" 평가에 강점이 있습니다. 두 방식은 상호 보완 관계에 있습니다.

특히 실용적이라고 느낀 점은 no-ai-slop의 패턴 명명(weasel attribution, importance puffery 등)입니다. 문제점에 이름이 붙어 있으면 지적하기 쉽고, 리뷰 문화로 정착시키기 용이합니다. Algomatic 관련 글에서도 이 명칭을 리뷰 기준으로 전용하고 있었으나, 실제 리뷰 코멘트에서는 no-ai-slop 단독으로는 포착할 수 없는 층(B군)이 존재하기 때문에, 판단 근거 체크와 병행하는 것이 이상적입니다.

기존 리뷰 도구로의 통합 가능성

"genshijin-reviewer"와 같은 기존의 코드 리뷰 헬퍼에 이번 지견을 통합할 경우, 다음과 같은 설계가 가능합니다:

• 필수: Algomatic식 5개 항목 체크 (구현량 적음, 어떤 LLM으로도 판정 가능)
• 옵션: no-ai-slop 패턴 탐지 (문체 체크로서 추가. 효과는 제한적이지만, 라벨링은 유용함)
• 기대 효과: "LGTM입니다"라고만 쓰는 리뷰를 기계적으로 탐지할 수 있음 (B군 박멸)

요약

no-ai-slop의 탐지 패턴을 코드 리뷰 품질 체크에 전용할 수 있는가——라는 질문에 대해, 검증 결과는 "문체 체크만으로는 불충분하며, 판단 근거 체크와의 병용이 효과적이다"라는 답을 보여주었습니다.

no-ai-slop는 "문체의 AI스러운 느낌"을 제거하는 데는 뛰어나지만, 실무에서 문제가 되는 "문체는 자연스럽지만 판단 근거가 없는" 리뷰 코멘트는 탐지할 수 없습니다. 반면, Algomatic식의 "판단 주체·검증·구체성·출처·책임" 5개 항목 체크는 문체와 관계없이 내용의 빈약함을 측정할 수 있습니다.

어느 한쪽이 아니라, **no-ai-slop의 패턴 라벨링 (pattern labeling)**과 Algomatic의 판단 근거 체크를 조합하는 것이 코드 리뷰 품질의 실용적인 평가 기준이 될 것으로 보입니다.

AI로 리뷰 코멘트를 쓰는 일이 늘어날 앞으로의 시대에는, "AI를 사용했는가"가 아니라 "최종적으로 누가 무엇을 판단했는가"가 보이는 문장인 것이 훨씬 더 중요하다고 생각합니다.

부록: 이 기사 자체를 리뷰해 보았다

글을 다 쓴 후, 이 기사 자체를 no-ai-slop와 Algomatic 기준으로 리뷰해 보았습니다. 결과는 다음과 같습니다.

no-ai-slop적 지적

• 직전의 한 문장 "'AI를 사용했는가'가 아니라 '최종적으로 누가 무엇을 판단했는가'가 보이는 문장인 것이 훨씬 더 중요하다"——이것은 바로 본문에서 비판했던 이항 대립 (binary contrast) 그 자체였습니다. 마지막 문장에서 제가 직접 하고 있었습니다.
• "목소리 높여 말하고 싶은 것은" 또한, 중요성 과장 (importance puffery)에 발을 걸치고 있습니다.

Algomatic 기준적 지적

• 한계점에 대한 기재가 본문에 매몰되어 있을 뿐 독립되어 있지 않습니다. "11건의 핸드메이드 샘플", "gpt-4o-mini 단독 시뮬레이션"이라는 조건의 취약함은 별도의 한계점 섹션으로 명시했어야 했습니다.
• 판단 주체가 모호합니다. 실제로 11개의 샘플을 만들고 코드를 작성하여 검증을 돌린 것은 AI 에이전트이며, 인간(mskbhd)은 테마 선정과 최종 승인만을 수행했습니다. "나"라는 표현을 사용하여 작성했지만, 검증 프로세스에서의 인간의 관여도는 본문에서 읽어내기 어렵습니다.

저도 아직 멀었군요.

Discussion