오랫동안 소프트웨어 개발에서 가장 어려운 부분은 코드를 작성하는 것이었습니다.

이제는 더 이상 그렇지 않습니다.

AI 보조 코딩 (AI-assisted coding) 및 에이전트 기반 워크플로우 (agent-driven workflows)가 주류가 됨에 따라, 코드를 생성하는 비용은 급격히 낮아지고 있습니다. 하지만 코드를 이해하고, 검토하고, 단순화하며, 삭제하는 비용은 그만큼 빠르게 상승하고 있습니다. 이제 코드는 검증하는 것보다 추가하는 것이 더 쉽습니다. 통합하는 것보다 복제하는 것이 더 쉽습니다. 안전하게 제거하는 것보다 생성하는 것이 더 쉽습니다.

이러한 비대칭성은 새로운 엔지니어링 문제를 야기하고 있습니다. 질문은 이제 더 이상 다음과 같지 않습니다:

어떻게 하면 더 많은 코드를 더 빠르게 생성할 것인가?

대신 점점 다음과 같은 질문이 중요해지고 있습니다:

어떻게 하면 생성된 코드가 코드베이스 (codebase)의 구조를 소리 없이 저하시키는 것을 막을 것인가?

그것이 바로 AI-SLOP-DETECTOR가 구축되고 있는 영역입니다.

v3.8.1이 중요한 이유는 이 프로젝트가 세 가지 계층을 분리된 상태로 유지하면서, 탐지 (detection) 에서 관리된 정리 (governed cleanup) 로 이동하고 있기 때문입니다:

• 스코어링 (scoring): 구조적 위험 측정
• 액션 플래닝 (action planning): 검토하기에 안전하거나 중요한 작업의 우선순위 지정
• 강제 적용 (enforcement): 반드시 차단되어야 하는 사항 검증

이러한 분리가 이번 릴리스의 핵심입니다. 또한 이 프로젝트를 진지하게 받아들여야 하는 가장 강력한 이유이기도 합니다.

왜 지금 이 릴리스가 중요한가

“AI 코드 품질”을 측정한다고 주장하는 도구는 많습니다. 유의미한 차이점은 그 도구들이 결과물을 내놓을 수 있느냐가 아닙니다. 결과물이 워크플로우를 주도하기 시작할 때, 경계 규율 (boundary discipline)을 유지할 수 있느냐 하는 점입니다.

v3.8.1이 중요한 이유는 다음 세 가지 주장을 더욱 날카롭게 다듬었기 때문입니다:

1. 스코어링 경로가 더 안전해졌습니다
2. 정리 작업이 더 실행 가능해졌습니다
3. 거버넌스 (Governance)를 우회하기가 더 어려워졌습니다

이번 릴리스의 다른 모든 사항은 이 세 가지 주장 중 하나를 뒷받침하는 증거입니다.

v3.6.0 이후의 변경 로그 (Changelog) 증거

최근의 릴리스들은 개별적인 기능 추가라기보다 하나의 연속된 흐름으로서 더 큰 의미를 갖습니다.

버전	주요 변경 사항	중요했던 이유
v3.6.0	Claude Code 기술, CI 게이트 수정, pre-commit 재작성, VS Code 패키징	프로젝트가 단순히 스캔(scan)을 인지하는 수준을 넘어, 워크플로우(workflow)를 인지하게 됨
...

이 릴리스들을 종합해 보면 하나의 패턴이 나타납니다. 단순히 더 많은 기능이 추가된 것이 아니라, 더 높은 정확성(correctness), 더 높은 설명 가능성(explainability), 더 높은 거버넌스(governance), 그리고 더 사용하기 쉬운 워크플로우 접점(workflow surfaces)을 제공하고 있습니다.

주장 1: 점수 산출 경로(Scoring Path)가 더 안전해졌다

v3.6.0 이후 가장 중요한 기술적 강화는 프로젝트가 더 많은 신호(signals)를 추가했다는 점이 아닙니다. 점수 산출 경로를 더 신뢰할 수 있도록 안전하게 만들었다는 점입니다.

핵심 모델은 여전히 네 가지 차원에 걸쳐 가중 기하 평균 집계(weighted geometric aggregation)를 사용합니다:

$$

\mathrm{GQG}

\prod_{i \in {\mathrm{ldr},\mathrm{inflation},\mathrm{ddc},\mathrm{purity}}} x_i^{w_i}
$$

결손 지향 점수(deficit-oriented score)는 다음 식에 의해 구동됩니다:

$$

\mathrm{deficit}

100 \cdot (1 - \mathrm{GQG}) + \mathrm{pattern_penalty}
$$

이 공식 자체가 흥미로운 부분은 아닙니다. 중요한 부분은 그 공식을 둘러싸고 무엇이 강화되었는가 하는 점입니다.

변경된 사항

• 설정(config) 값들이 모델에 입력되기 전에 검증됨
• 지표 범위(metric ranges)가 점수를 오염시키기 전에 보호됨
• deficit_breakdown을 통해 점수 귀속(score attribution)을 검사할 수 있음
• 교차 언어 집계(cross-language aggregation)가 더 이상 프로젝트 요약을 잘못 기술하지 않음
• 구조적 일관성(structural coherence)이 임계값 이상에서 결정론적 폴백(deterministic fallback)과 함께 확장됨

중요성

이러한 강화 조치들이 없다면, 공식은 단순히 권위 있어 보이는 질감(authority texture)에 그칠 위험이 있습니다. 하지만 이러한 조치들을 통해 공식은 공학적 도구(engineering instrument)처럼 작동하게 됩니다.

기술적인 독자에게 관찰 가능한 개선 사항은 추상적인 수학적 위엄이 아닙니다. 그것은 다음과 같습니다:

• 깨진 요약(broken summaries)의 감소
• 설정으로 인한 왜곡(config-induced distortions)의 감소
• 점수가 어디에서 유래했는지에 대한 더 나은 설명
• 대규모 리포지토리(large repositories)에서의 예측 가능한 동작

요약하자면, 모델은 오용하기 더 어려워졌고, 설명하기 더 쉬워졌으며, 규모가 커져도 더 안정적이 되었습니다.

주장 2: 정리(Cleanup)가 더 실행 가능해졌다

대부분의 코드 품질 도구들은 이슈를 발행(issue emission)하는 단계에서 멈춥니다. 이는 유용하지만, 불완전합니다.

개발자들은 단순히 무엇이 존재하는지만 알아야 하는 것이 아닙니다. 그들은 다음을 알아야 합니다:

• 무엇이 중요한가
• 무엇이 검토하기에 아마도 안전한가
• 무엇에 인간의 주의가 필요한가
• 무엇을 가장 먼저 살펴봐야 하는가

이 지점이 바로 v3.8.1이 제품 수준에서 가장 명확한 도약을 이뤄낸 부분입니다.

정리(Cleanup) 신뢰도 계획

정리(Cleanup) 계열의 출력물은 이제 다음을 포함할 수 있습니다:

• confidence (신뢰도)
• action_class (조치 클래스)
• evidence (근거)

중요한 아키텍처적 선택은 이것이 별개의 분리된 스코어링 모델(scoring model)로 구현되지 않았다는 점입니다. 정리 신뢰도는 기존 시그널(signals) 위에 구축된 재사용 레이어입니다:

• deficit_score (결손 점수)
• churn (변경 빈도)
• coverage gap (커버리지 격차)
• cleanup-local evidence (정리 로컬 근거)

단순화된 멘탈 모델(mental model)은 다음과 같습니다:

confidence = base_evidence
confidence += low_churn_bonus
confidence += low_coverage_bonus
...

정확한 산술 연산보다 중요한 것은 아키텍처입니다. 즉, 시스템이 스코어링을 위한 하나의 진실 모델(truth model)과 정리를 위한 또 다른 진실 모델을 별도로 유지하지 않는다는 점입니다.

매니페스트 인식 의존성 위생(Manifest-aware dependency hygiene)

unused-deps 또한 파일 로컬 힌트(file-local hints)의 범위를 넘어 확장되었습니다. 이제 다음을 읽습니다:

• pyproject.toml
• package.json

그리고 다음을 발행할 수 있습니다:

• manifest_unused_dependency (매니페스트 미사용 의존성)
• undeclared_import (선언되지 않은 임포트)

이것이 중요한 이유는 많은 의존성 문제들이 단일 파일 내부에서는 보이지 않기 때문입니다. 이 문제들은 소스 코드와 프로젝트 메타데이터 사이의 경계에 존재합니다.

이것이 중요한 이유

이전:

sweep -> 후보 목록

이후:

sweep -> 순위가 매겨진 이슈 -> 조치 클래스 -> 근거에 기반한 검토 계획

이것이 탐지기(detector)와 정리 도구(cleanup instrument) 사이의 차이입니다.

주장 3: 거버넌스(Governance)를 우회하기가 더 어려워졌다

이것은 단연코 이 글에서 가장 강력한 신뢰의 닻이며, 솔직하게 말할 가치가 있습니다:

이 프로젝트는 점수가 정책이 되라고 요구하지 않으며, 정책이 점수를 조용히 변질시키도록 허용하지도 않습니다.

이것이 올바른 아키텍처적 판단입니다.

변경된 사항

이제 프로젝트는 거버넌스를 별도의 fail-closed(실패 시 차단) 경로로 취급합니다:

• 분석(analysis)은 결정론적인 거버넌스 아티팩트(governance artifact)를 생성합니다.
• 검증(verification)은 해당 아티팩트의 해시(hash)를 재계산합니다.
• 정책 확인(policy checks)은 전용 검증 게이트(verification gate)에서 실행됩니다.

워크플로우는 의도적으로 계층화되어 있습니다:

analysis -> governance_record.json -> verify-governance -> pass/fail enforcement

이것이 중요한 이유

이러한 분리는 다음을 의미합니다:

• 수학적 모델(math)이 CI 정책을 조용히 변경하지 않고도 발전할 수 있습니다.
• 점수 모델(scoring model)을 손상시키지 않고도 정책을 더 엄격하게 만들 수 있습니다.
• 거버넌스를 단순히 일시적인 보고서(transient report)에서 추론하는 것이 아니라, 하나의 아티팩트(artifact)로서 감사(audit)할 수 있습니다.

모호한 "AI 코드 품질" 주장으로 가득 찬 카테고리 내에서, 이러한 서브시스템 분리(subsystem separation)야말로 진정으로 진지함을 나타내는 지표입니다.

지원 강화 사항

이번 릴리스에는 기존의 세 가지 주요 주장을 대체하지 않으면서도 이를 강화하는 몇 가지 중요한 지원 개선 사항이 포함되어 있습니다.

계층형 아키텍처 리뷰 (Layered architecture review)

이제 아키텍처 분석(Architecture analysis)은 단순히 임포트 사이클(import cycles) 단계에서 멈추지 않고, 계층형 프리셋(layered preset)을 선택적으로 사용할 수 있습니다.

간소화된 설정은 다음과 같습니다:

architecture:
  enabled: true
  preset: layered

내장된 의도는 설계 단계부터 좁게 설정되어 있습니다:

• api -> domain 허용
• domain -> data 금지
• domain -> service 금지
• domain -> api 금지

이는 기본적으로 활성화되어 있지 않으며, 그것이 올바른 방향입니다. 아키텍처 리뷰는 오탐(false-positive) 제조기가 되지 않을 때에만 가치가 있습니다.

표준 CLI (Canonical CLI)

공개 CLI를 이제 훨씬 더 쉽게 기억할 수 있습니다:

• scan
• review
• pulse
• sweep

이러한 단순화는 중요합니다. 인터페이스의 표면(surface)이 사용자의 신뢰보다 빠르게 확장될 때 채택(adoption)은 중단되기 때문입니다.

선택적 Rust 가속 (Selective Rust acceleration)

성능 작업 또한 절제된 상태를 유지했습니다. 프로젝트는 네이티브 코드(native code)를 중심으로 전체를 재작성하지 않았습니다. Python을 제품의 핵심(product core)으로 유지하면서, 다음과 같이 측정된 핫 패스(hot paths)에만 Rust를 사용했습니다:

• 파일 워킹 (file walking)
• Glob 중심의 트래버스 (glob-heavy traversal)

이것이 올바른 트레이드오프(trade)입니다. 네이티브 코드는 여기서 성능을 돕는 보조 도구이지, 제품의 정체성이 아닙니다.

심층적인 후속 조치가 필요한 5가지 주제

다음의 다섯 가지 영역은 이번 릴리스의 아키텍처(architecture)가 가장 명확하게 드러나는 부분이기 때문에 별도의 기술 노트로 다룰 가치가 있습니다.

1. 수학적 모델 강화 (Mathematical Model Hardening)

점수 산정 모델(scoring model)에 더 화려한 공식이 필요했던 것은 아닙니다. 모델에는 더 안전한 경계(boundary)가 필요했습니다.

그렇기에 검증(validation), 지표 가드(metric guards), 교차 언어 집계(cross-language aggregation), 속성 결핍 출력(attributed deficit output), 그리고 규모 임계값 초과 시의 결정론적 폴백(deterministic fallback)을 중심으로 중요한 작업이 이루어졌습니다. 그 이점은 실질적입니다. 이상한 요약이 줄어들고, 설정 변경이 더 안전해지며, 디버깅하기 쉬운 점수 출력 결과가 제공됩니다.

스캔(scan) -> 검증된 지표(validated metrics) -> 속성 점수(attributed score) -> 프로젝트 요약(project summary)

이제 모델은 불투명한 탐지기(detector)라기보다 측정 서브시스템(measurement subsystem)에 가깝게 동작합니다.

2. 정리 신뢰도 계획 (Cleanup Confidence Planning)

"이것은 데드 코드(dead code)일 수 있습니다"라는 말은 실제 정리 작업을 수행하기 위한 가이드로서는 충분하지 않습니다.

v3.8.1은 정리 대상군(cleanup-family) 결과에 신뢰도(confidence), 작업 클래스(action class), 증거(evidence)를 부착함으로써 정리를 리뷰 계획(review plan)에 더 가깝게 이동시킵니다. 핵심적인 설계 선택은 재사용(reuse)입니다. 정리 신뢰도는 두 번째 진실 체계(truth system)를 새로 만드는 대신 결핍(deficit), 변경량(churn), 커버리지(coverage), 로컬 증거(local evidence)와 같은 기존 신호(signals)로부터 도출됩니다.

dead-code 스윕(sweep) -> 순위가 매겨진 이슈(ranked issue) -> 작업 클래스(action class) -> 증거(evidence)

이를 통해 정리는 인간에게는 더 안전해지고, 에이전트(agents)가 소비하기에는 더 쉬워집니다.

3. 매니페스트 인지 의존성 위생 (Manifest-Aware Dependency Hygiene)

의존성 부채(dependency debt)는 파일 단위가 아닌 프로젝트 단위인 경우가 많습니다.

pyproject.toml과 package.json 전반에 걸쳐 선언된 의존성(declared dependencies), 임포트된 의존성(imported dependencies), 그리고 정규화된 최상위 매핑(normalized top-level mappings)을 비교함으로써, 이제 도구는 사용되지 않는 선언된 패키지나 누락된 선언과 같은 매니페스트 수준(manifest-level)의 문제를 드러낼 수 있습니다.

이로써 unused-deps는 단순한 파일 힌트에서 저장소 위생(repository hygiene) 신호로 전환됩니다.

4. 계층형 아키텍처 리뷰 (Layered Architecture Review)

순환 탐지(cycle detection)는 유용하지만, 많은 아키텍처 실패는 순환이 발생하기 전에 나타납니다.

계층형 아키텍처 (layered architecture) 프리셋은 팀이 허용되거나 금지된 임포트 (import) 방향을 선택적으로 표현할 수 있는 방법을 제공하며, 위반 사항에 대한 증거를 함께 첨부합니다. 중요한 부분은 자제력입니다. 이는 모든 리포지토리 (repository)에 강제되는 것이 아닙니다.

boundary-violations -> cycles + optional layered rule review

이를 통해 아키텍처 리뷰 (architecture review)가 소음 섞인 확신으로 변질되지 않으면서도 유용성을 유지할 수 있습니다.

5. 거버넌스 검증 게이트 (Governance Verification Gate)

측정 (measurement)과 집행 (enforcement)은 동일한 레이어 (layer)로 붕괴되어서는 안 됩니다.

거버넌스 게이트 (governance gate)는 결정론적인 아티팩트 (deterministic artifact)를 생성하고, 이를 별도로 검증하며, 정책 또는 무결성 체크 (integrity checks)가 깨질 경우 '페일 클로즈 (fail closed, 차단)' 상태가 됩니다. 이는 CI (지속적 통합) 동작을 더 명시적이고 감사 (audit) 친화적으로 만듭니다.

scan -> governance artifact -> verify-governance -> pass / fail

이것은 시스템 내에서 가장 강력한 분리 중 하나입니다. 측정, 아티팩트 생성, 그리고 집행은 각각 자신만의 경계 (boundary)를 가집니다.

이 카테고리가 계속 성장할 이유

우리는 아직 초기 단계에 있습니다.

대부분의 팀은 대규모 AI 보조 개발 (AI-assisted development)이 시간이 지남에 따라 리포지토리 (repository)에 실제로 어떤 영향을 미치는지 이제 막 느끼기 시작했습니다. 처음에는 가속화되는 것처럼 느껴집니다. 그러다 점차 소용돌이 (churn), 중복 (duplication), 방치된 로직 (abandoned logic), 부풀려진 구조 (inflated structure), 그리고 무엇이 여전히 안전하게 수정 가능한지에 대한 불확실성으로 느껴지기 시작합니다.

이것이 바로 슬롭 (slop)에 대한 관심이 계속 높아질 수밖에 없는 이유입니다.

코드 에이전트 (code agents)가 더 많은 코드를 생성할 수 있게 될수록, 애초에 코드베이스 (codebase)에 남아있지 말았어야 할 것을 인간이 결정하도록 돕는 도구들의 가치는 더욱 높아집니다.

에이전트 주도 코드 개발 (agent-driven code development)이 주류가 됨에 따라, 다음과 같은 시스템에 대한 필요성은 가속화될 것입니다:

• 구조적 신뢰 (structural trust) 측정
• 정리 (cleanup) 우선순위 지정
• 증거 (evidence)와 정책 (policy)의 분리
• 삭제 (deletion)를 더 안전하게 만들기
• 거버넌스 (governance)를 명시적으로 만들기

AI-SLOP-DETECTOR는 그 방향을 향해 점진적으로 구축되고 있습니다.

단발적인 아이디어로서가 아닙니다.
트렌드를 쫓는 래퍼 (wrapper)로서도 아닙니다.
유행하는 라벨을 붙인 린터 (linter)로서도 아닙니다.

하지만 다음과 같은 단순한 현실을 바탕으로 단계별로 형성되는 시스템으로서 구축되고 있습니다:

만약 AI가 코드 생성 비용을 낮춘다면, 구조적 검토(structural review), 정리 규율(cleanup discipline), 그리고 거버넌스(governance)는 그 어느 때보다 더 가치 있어질 것입니다.

그것이 바로 이 프로젝트의 이면에 있는 장인 정신(craft mindset)입니다:

• 도구(instrument)를 정교화하기
• 워크플로우(workflow)를 엄격하게 만들기
• 계층(layers)을 분리하기
• 한 번의 릴리스(release)마다 신뢰 표면(trust surface)을 개선하기

그것이 바로 이 프로젝트의 이면에 있는 장인 정신(craft mindset)입니다:

- 도구(instrument)를 정교화하기
...