안티-슬롭 검사

에이전트는 신속하게 타당한 코드를 작성하지만, 일부는 신중한 엔지니어라면 사용하지 않을 단축 경로를 택합니다: 빌드 성공을 위해 건너뛴 테스트, 무시된 오류, 남겨진 스텁, 비활성화된 타입 체크, 기존 코드베이스에 이미 존재하는 기능의 중복 구현 등입니다.안티-슬롭검사는 모든 변경 사항에서 이러한 문제를 찾아내어 사용자가 확인하기 전에 개발자 에이전트에게 해당 변경 사항을 다시 보냅니다.

이는 귀하의품질 관리정책 내의 하나의 검사일 뿐이며 별도의 점수로 산정되지는 않습니다. 해당 변경 사항이 차단 요소를 도입하지 않는 경우 통과됩니다.

검사 대상#

규칙은 그룹으로 분류됩니다. 각 규칙은차단, 권고또는정보.

• 테스트— 집중적으로 실행되거나 건너뛴 테스트, 삭제된 테스트, 제거되거나 약화된 어서션, 실패할 수 없는 테스트 등입니다.
• 억제 사항— 새로운 린트 비활성화 설정, 타입 무시 처리 및any형변환입니다.
• 빌드 및 CI— 테스트 단계가 제거되거나 무력화됨, 임계값이 낮아짐, "테스트 없이도 통과", GitHub 액션이 커밋에 고정되지 않음 등입니다.
• 테스트 증거— 캐시된 결과를 실제 실행 결과로 오인함, 실행된 테스트가 전혀 없음, 부분적인 실행 결과를 완료된 것으로 보고함 등입니다.
• 프로덕션 코드— 디버그용 잔여물, 플레이스홀더, 모의 데이터, 사람을 위한 메모, 테스트 코드가 배포됨 등입니다.
• 오류 처리— 무시된 오류, 실패를 숨기는 대체 처리 방식, 열린 상태의 권한 확인 등입니다.
• 종속성— 존재하지 않거나 악성으로 간주되는 패키지, 인기 있는 패키지와 유사한 이름의 새 패키지, 설치 시 코드를 실행하는 패키지, 잠금 파일 없이 매니페스트가 변경됨 등입니다.
• 보안— 코드 내에 포함된 비밀번호, 비활성화된 TLS 확인 절차, 제거된 인증 확인 절차, 네트워크에서 직접 실행되는 다운로드된 스크립트 등입니다.
• 코멘트, 아키텍처, 변경 범위, 캐싱및 에이전트 활동 내역— 테스트가 실패한 직후에 해당 테스트를 수정하는 등 에이전트의 작업 내용을 기록한 것입니다.

내의 각 규칙은안티-슬롭 규칙, 품질 관리 내의 안티-슬롭 행에서 열면 해당 규칙이 일치하는 대상, 중요성 및 조직 기본 설정이나 프로젝트 내에서의 작동 방식을 확인할 수 있습니다.

변경 사항에서 도입된 항목만이 차단 요소가 됩니다.#

대부분의 리포지토리에는 이미 이러한 패턴이 일부 존재합니다. 안티-슬롭은 모든 발견된 항목을 세 가지 그룹으로 분류합니다:

• 도입된 항목— 이번 변경 사항에서 새로 추가된 항목입니다.
• 수정된 항목— 이미 존재하며 변경 사항에서 수정된 줄이나 함수에 포함된 항목입니다.
• 기존 항목— 리포지토리의 다른 곳에 존재하는 항목입니다.

차단 규칙에 해당하는 도입된 항목만이 검사를 통과하지 못합니다. 수정된 항목과 기존 항목은 기록되어 Factory의 Debt 섹션에서 기술 부채를 확인하고 해당 규칙의 문제를 해결하기 위한 작업을 생성할 수 있지만, 이로 인해 무관한 작업이 지연되지는 않습니다. 코드를 이동하는 것은 도입으로 간주되지 않으며 복사하는 경우에만 해당됩니다.

주간 기술 부채 정리#

기존 부채는 차단 요소가 되지 않지만 영구히 남아 있어서는 안 됩니다. 품질 관리에서 프로젝트를 열고안티-슬롭을 확장한 뒤주간 기술 부채 정리를 활성화하세요. 매주 Coroid가 프로젝트의 기본 브랜치를 스캔하여 발견된 부채에 대한 소규모 정리 작업을 생성하며, 각각 몇 개의 파일만 다룹니다. 동시에 열려 있는 정리 작업 수는한 번에 열려 있는 작업 수에서 지정한 수(기본값은 두 개)를 초과하지 않으므로 정리 작업이 사용자가 요청한 작업을 방해하지 않습니다. 모든 변경 사항에는 실행 취소 기능이 제공됩니다.

정리 작업은 프로젝트별로 설정됩니다. 해당 일정은 Factory에 표시되며 품질 관리에서 관리된다고 명시되어 있습니다. 설정을 변경하려면 여기서 진행해야 하며 거기서는 할 수 없습니다.

새 작업에서는 이전에 "주간 기술 부채 정리" 템플릿을 제공했습니다. 이 템플릿으로 생성된 일정은 계속 실행되며 스위치 옆에 이름이 표시됩니다. 기술 부채 정리가 이를 대체하는 경우 Factory에서 일시 중지하세요.

활성화 방법#

에서품질 관리, 조직 기본 설정 또는 프로젝트를 선택한 뒤안티-슬롭를 활성화하세요. 이렇게 하면 다음과 같은 다섯 가지 기준이 적용됩니다:

1. 테스트가 여전히 변경 사항을 입증해야 합니다.
2. 미완성된 코드나 테스트용 코드가 배포되어서는 안 됩니다.
3. 새로운 구조적 부채가 발생해서는 안 됩니다.
4. 변경 사항의 범위가 유지되고 해당 코드베이스의 스타일에 맞아야 합니다.
5. 새로 추가되는 종속성은 실제로 신뢰할 수 있는 것여야 합니다.

변경 사항은 즉시 적용됩니다. 해당 프로젝트의 다음 실행 시 또는 기본 설정을 따르는 모든 프로젝트에서 해당 검사가 포함됩니다. 행의 설정에서 변경 사항 준수 기준을 지정하며, 이 기준은 차단 규칙과 판단 규칙을 그룹화합니다. 이 기능을 비활성화해도 다음에 다시 활성화할 때 이전 설정이 그대로 적용됩니다.

변경 사항 준수 기준 선택#

이 기준은 개발자 에이전트에게 변경 사항이 허용되는 범위를 알려줍니다:

• 정밀 처리— 사양에 명시된 내용만 처리하며, 기타 문제는 보고될 뿐 수정되지 않습니다.
• 균형 잡힌 처리(기본값) — 변경이 적용된 줄에 있는 사소한 문제도 함께 수정합니다.
• 복원적 처리— 변경이 이루어진 함수 내의 문제점도 정리합니다.

에이전트는 제출하기 전에 동일한 규칙을 따릅니다. 미리 지정된 규칙과 사용자가 격리한 패턴을 반영하고, 편집 후마다 즉각적인 규칙을 확인한 뒤, QA 단계에서 차단되는 문제를 수정할 기회를 한 번 얻습니다.

코드베이스에 맞게 조정하기#

• 규칙 재정의— 안티-슬롭 규칙에서 규칙을 열어서 조직 전체 또는 특정 프로젝트에 대해 해당 규칙을 차단, 경고, 보고 또는 중단하도록 설정할 수 있습니다.
• 규칙 팩— 사용자 정의 패턴, 금지된 임포트 및 종속성, 파일 크기 제한, 또는 기존에 사용 중인 도구(SARIF)의 결과를 포함합니다. 저장할 때마다 새 버전이 생성되며, 선택된 버전은 체크 시 그대로 유지됩니다.
• 격리— 더 이상 복사되지 않도록 설정한 패턴으로, 대체할 항목도 함께 지정됩니다. 에이전트는 이를 복제하지 않도록 지시받으며, 새로 생긴 복제본은 표시됩니다.
• 제외 경로— 품질 관리 → 안티-슬롭 메뉴에서 안티-슬롭 검사가 수행되지 않는 생성된 파일 또는 외부 라이브러리 파일을 지정하며, 각 항목은 한 줄에 하나씩 입력합니다 (dist/**, vendor/**). 커밋된 빌드 출력물에 사용되며, 스캐너의 512 KiB 제한을 초과하는 변경된 파일은 규칙에 따라 검사가 불가능해집니다.
• 저장소 파일 — .coroid/anti-slop.yml저장소 내의 파일을 통해 규칙을 추가하고generated/, vendor/, node_modules/및__generated__/디렉터리를 제외할 수 있습니다. 이 파일은 변경 사항의 기본 경로에서 읽히므로 변경 자체로 규칙을 완화할 수 없으며, 편집 시에는 승인이 필요합니다.
• 잠금 파일 및 번역 카탈로그— 안티-슬롭은 이들 파일의 변경 내용을 계산하지만 실제로는 읽지 않습니다. 카탈로그 파일은.coroid/i18n.json가 변경 사항의 기본 경로에서 선언한 파일이며, 글로벌화 검사 시 이를 참조합니다. 사용자 정의 규칙에서도 이 파일들을 대상으로 지정할 수 있습니다.

새로운 종속성#

모델이 존재하지 않는 패키지를 제안하는 경우가 있는데, 이는 종종 두 개의 실제 패키지명을 조합한 것일 수 있습니다. 공격자는 npm 및 PyPI에 이러한 이름을 등록하여 다음 설치 시 자신들의 코드가 실행되도록 하는데, 이를 슬롭스쿼팅 공격이라고 합니다. 클라우드 보안 연합이 상황을 설명합니다: 해당 연구에서 언급된 223만 개의 코드 샘플 중 거의 5분의 1이 존재하지 않는 패키지를 참조했습니다.

안티-슬롭은 변경 사항으로 추가되는 각 종속성을package.json, 요구사항 파일 또는pyproject.toml:

• 차단— 공개 레지스트리에 없는 패키지 또는 OSV에서 악성으로 보고된 패키지입니다. 해당 변경 사항은 사용자가 확인하기 전에 개발자 에이전트로 다시 전달됩니다.
• 경고— 출시된 지 30일 미만인 패키지, 다운로드 횟수가 극히 적은 패키지, 인기 있는 패키지와 이름이 한두 글자 차이 나는 패키지, 또는 설치 시 코드가 실행되는 npm 패키지가 여기에 해당합니다. 악성으로 보고된 릴리즈가 있는 PyPI 패키지도 경고 대상이며, Coroid는 어떤 릴리즈가 요구사항에 의해 설치되는지 알 수 없기 때문입니다.

레지스트리에 접근할 수 없는 경우에는 결과에 해당 내용이 표시되고, 조회 가능한 패키지만을 기준으로 판단하며 변경 사항을 보류하지는 않습니다.

Coroid가 조회하는 이름들#

이름을 조회하면 공개 레지스트리로 전송되므로, 소유자 또는 관리자는 Coroid에서 전송될 이름을품질 관리 → 안티-슬롭 → 새로운 종속성 검사. 이 설정은 조직 내 모든 프로젝트에 적용됩니다.

• 공개 npm 및 PyPI이며, 저장소에서 다른 레지스트리를 지정하지 않는 한— 모든 새로운 종속성은 조회되지만,.npmrc, 요구사항 파일,pip.conf, uv.toml,Pipfile또는 Python 도구 설정에서 매니페스트 파일이나 그 상위 폴더에 다른 레지스트리 또는 인덱스가 지정된 경우는 예외입니다. 이 경우에는 저장소 외부(예: 사용자 설정 또는 CI 설정)에 프라이빗 레지스트리가 구성되어 있지 않음을 확인하고, 누가 언제 확인했는지 기록해야 합니다. 범위가 지정된 npm 패키지(@scope/name)는.npmrc가 해당 범위에 대한 공개 레지스트리를 지정한 경우에만 조회됩니다.
• 저장소에서 공개 레지스트리를 지정한 경우에만— 기본 설정입니다. 패키지는.npmrc가 registry=https://registry.npmjs.org/, 요구사항 파일에 정확히 하나의 --index-url https://pypi.org/simple줄이 있거나, Poetry 종속성이 pypi.org를 가리키는 소스를 사용하는 경우에만 조회됩니다. 대부분의 저장소는 이 조건을 충족하지 못하므로 대부분의 새로운 종속성은 검사되지 않습니다.
• 사용 안 함— 어떤 이름도 조회되지 않으며, 가짜 패키지도 탐지되지 않습니다.

새로운 종속성의 이름만 Coroid를 떠나registry.npmjs.org와pypi.org,api.npmjs.org로 npm 다운로드 횟수를 확인하며,api.osv.dev(npm 버전을 사용할 경우) 악성 패키지 보고용으로 활용됩니다. 귀하의 코드는 절대 전송되지 않습니다. 결과는 최대 하루 동안 보관되므로 동일한 이름에 대해 매번 다시 조회하지 않아도 됩니다.

발견 사항 및 승인#

작업의 발견 사항은 해당 작업의품질섹션에 표시됩니다. 변경 사항이 리뷰 단계에 도달하기 전에 개발 에이전트가 차단성 발견 사항을 수정한 경우, 이 섹션은리뷰 전에 안티-슬롭에 의해 포착됨, 포착된 규칙들과, 그 아래의위치 및 시점 확인, 각 발견 사항의 파일 및 줄 번호와 이를 찾아낸 검사 항목이 표시됩니다. Factory의기술 부채섹션에서는 지난 30일간 리뷰 전에 포착된 단축 경로를 집계하며, 소유자와 관리자에게 아직 이를 검사하지 않는 프로젝트를 알려주고,안티-슬롭 활성화하기.

발견 사항을 승인하려면 사유와 유효 기간을 입력해야 하며, 이 승인 내용은 해당 특정 발견 사항에 대해 기록됩니다. 에이전트는 자신이 발견한 사항을 승인할 수 없습니다. 에이전트가 테스트 결과가 잘못되었다고 판단하여 코드를 수정한 경우, 검사가 통과되기 전에 리뷰어의 승인이 반드시 필요합니다.

규칙 판단하기#

두 가지 규칙이 모델에 한 번에 한 줄씩 질문을 던집니다. 하나는 표시된 코드로는 불가능한 상황에 대한 방어적 검사이고, 다른 하나는 인접한 코드와 모순되는 주석입니다. 이 규칙들은 권고만 할 뿐 절대 차단하지 않습니다.규칙 판단 기능 활성화하기는 새 검사에서 활성화되며, 실행당 결정 가능 횟수가 제한됩니다. 검사 설정에서 이 기능을 비활성화할 수 있습니다.

자체 에이전트#

동일한 규칙을 귀하가 직접 운영하는 에이전트에도 적용할 수 있습니다:

• AGENTS.md 스니펫 다운로드,안티-슬롭프로젝트의 설정에서품질 관리, 프로젝트의 변경 관리 규칙, 격리 정책 및 상위 규칙을 에이전트의 지침에 붙여넣을 수 있는 섹션 형태로 제공합니다.
• Coroid MCP 서버를 통해anti_slop_rules는 게시된 정책과anti_slop_scan는 동기화된 프로젝트의 브랜치를 읽기 전용으로 스캔합니다.