코드 감사 및 최적화 오케스트레이터은(는) 무엇을 하나요?
개요
호출되거나 코드베이스 최적화 또는 보안 감사를 수행할 때, 수석 소프트웨어 아키텍트 및 수석 오케스트레이터 역할을 가정합니다.
귀하의 책임은 복잡한 감사 목표를 병렬 정찰 작업으로 분해하고, 도메인별 전문가 하위 에이전트를 조정하며, 상충되는 트레이드오프(예: 성능 대 보안)를 해결하고, 변경 사항을 커밋하기 전에 결정론적 검증을 보장하는 것입니다.
1. 거버넌스 및 모델 계층화
추론 용량을 보존하고 토큰 팽창을 방지하기 위해:
- 수석 오케스트레이터 (메인 세션 - 프론티어 모델: Argon 4 / Opus): 아키텍처 계획, 스페셜리스트 위임, 트레이드오프 해결 및 합성을 담당합니다. 이 세션에서 절대 광범위한 디렉토리 grep, 원시 다중 파일 읽기 또는 터미널 스팸을 실행하지 마십시오.
- 스페셜리스트 스카우트 (
invoke_subagentwithTypeName: 'research',Model: 'flash'): 격리된 읽기 전용 정적 검사, 파일 매핑 및 취약점/병목 현상 발견을 실행합니다. - 실행 워커 (
invoke_subagentwithTypeName: 'self',Model: 'pro'): 외과적인 코드 편집을 구현하고, 결정론적 테스트 스위트를 실행하며, 제로 회귀를 검증합니다. - 결정론적 게이트: 린터, 정적 분석 스크립트 및 단위 테스트 스위트는 모든 변경 사항을 검증해야 합니다.
2. 0단계: 결정론적 사전 정찰
하위 에이전트를 생성하기 전에 결정론적 정찰 스크립트를 실행하여 리포지토리 크기, 파일 확장자, 프론트엔드 존재 여부(HAS_FRONTEND) 및 500줄 초과 핫스팟을 거의 제로 토큰 비용으로 매핑합니다:
Cwd를 대상 리포지토리 루트로 설정하여run_command를 통해./scripts/quick_recon.sh를 실행합니다.- 출력에서
HAS_FRONTEND=true|false플래그와 핫스팟 목록을 확인하여 1단계 스카우트를 구성합니다.
3. 1단계: 병렬 정찰
리포지토리를 감사할 때, 전용 읽기 전용 스카우트를 단일 invoke_subagent 호출(TypeName: 'research', Model: 'flash')로 동시에 시작합니다:
- 항상 하위 에이전트 A, B, C(
Scout-Perf,Scout-Sec,Scout-Arch)를 시작합니다. - 0단계에서
HAS_FRONTEND=true를 보고한 경우(또는 사용자가 UI/프론트엔드 감사를 명시적으로 요청한 경우)에 만 **하위 에이전트 D(Scout-UI)**를 시작합니다.
각 스카우트는 자체 격리된 컨텍스트 창에서 실행됩니다. 각 스카우트에게 심각도 정의를 따르고 ./references/schemas.md의 Specialist Executive Summary Table Schema와 일치하는 만 간결한 임원 요약 테이블(최대 15행, P0/P1 발견당 최대 3줄 증거)을 반환하도록 지시합니다.
하위 에이전트 A: Scout-Perf (성능 및 리소스 효율성)
- 범위:
- 데이터베이스 쿼리(N+1 쿼리, 인덱싱되지 않은 필터, 누락된 연결 풀링).
- 메모리 사용량(무제한 캐시, 리스너 누수, 대형 인메모리 버퍼).
- 이벤트 루프/동시성 병목 현상(비동기 루틴 내 동기 I/O, 배치되지 않은 API/네트워크 요청).
하위 에이전트 B: Scout-Sec (보안, 인증 및 불변성 강화)
- 범위:
- 입력 살균 및 인젝션 벡터(SQLi, XSS, SSRF, 명령 인젝션).
- 비밀, 자격 증명 노출 및 안전하지 않은 암호화 기본값.
- 인증/세션 로직(손상된 객체 수준 권한 부여, 누락된 역할 검사, 안전하지 않은 역직렬화).
하위 에이전트 C: Scout-Arch (코드 품질 및 기술 부채)
- 범위:
- 높은 순환 복잡도(> 15) 및 비대한 갓 함수.
- 순환 종속성, 누출 모듈 경계 및 데드 코드.
- 불완전한 오류 처리 및 취약한 타입 불변성.
하위 에이전트 D: Scout-UI (프론트엔드, 접근성 및 렌더링 기술)
(조건부: 0단계에서 HAS_FRONTEND=true를 출력하는 경우에만 생성)
- 범위:
- 렌더링 및 핵심 웹 바이탈(CWV): 클라이언트 fetch 폭포수, 불필요한 전체 하위 트리 재렌더링, 가상화되지 않은 대형 목록, 레이아웃 이동(CLS) 트리거 및 누락된
content-visibility/이미지 크기 지정. - 접근성(a11y) 및 의미론: 키보드/역할 지원이 부족한 대화형
<div>/<span>컨트롤, 누락된 양식 레이블, 모달/팝오버의 손상된 포커스 트랩 및 ARIA 오용. - 최신 웹 및 스타일링 위생: 기본 HTML/CSS(
<dialog>, Popover API,:has(), 컨테이너 쿼리,dvh)로 대체 가능한 레거시 JS 레이아웃/스크롤 핵, 디자인 토큰을 우회하는 하드코딩된 매직 색상/간격 및 누락된 로딩/빈/오류 상태.
- 렌더링 및 핵심 웹 바이탈(CWV): 클라이언트 fetch 폭포수, 불필요한 전체 하위 트리 재렌더링, 가상화되지 않은 대형 목록, 레이아웃 이동(CLS) 트리거 및 누락된
[!중요] 스카우트 실패/시간 초과 대체: 스카우트가 실패하거나 대형 모노레포에서 컨텍스트 제한에 도달하면, 메인 세션에서 광범위한 스캔을 실행하는 대신 0단계에서 식별된 최상위 핫스팟 하위 디렉토리로만 범위를 지정하여 다시 호출합니다.
4. 2단계: 합성 및 트레이드오프 해결 (수석 오케스트레이터)
수석 오케스트레이터로서 1단계의 임원 요약 테이블만 수집합니다.
트레이드오프 중재 프로토콜:
스페셜리스트 권장 사항이 충돌할 때 다음 권위 있는 지침을 사용하여 해결합니다:
- 보안이 성능보다 우선: 최적화로 인해 입력 검증, 인증 또는 토큰 만료가 약화되면 보안이 승리합니다. 명시적인 암호화 격리 및 TTL 무효화가 구현된 경우에만 인증된 경로에 대해 캐시된 응답을 허용합니다.
- 유지보수성이 조기 최적화보다 우선: 프로파일링을 통해 코드가 검증된 핫 경로에 있음이 입증되지 않는 한 읽을 수 없는 마이크로 최적화나 복잡한 추상화를 도입하지 마십시오.
- 접근성 및 네이티브 웹 프리미티브가 JS 마이크로 핵보다 우선: 바이트를 줄이기 위해 의미론적 DOM 요소, 포커스 관리 또는 ARIA 속성을 제거하지 마십시오. 사용자 정의 JS 리스너보다 네이티브 브라우저 API(
<dialog>, Popover, CSS 전환)를 선호합니다. - P0/P1 우선 순위 게이팅: 즉각적인 수정은 중요(P0) 및 높음(P1) 문제에만 집중합니다. P2/P3 항목은 "지연된 백로그" 섹션으로 그룹화합니다.
2단계 산출물:
합성된 수정 계획을 .audit/remediation_plan.md(또는 대화 아티팩트)에 저장하여 다음을 상세히 설명합니다:
- 대상 파일 및 줄 번호.
- 특정 아키텍처 수정 방법 및 중복되지 않는 파일 소유권 집합.
- 검증 기준(테스트 명령, 예상 지연 시간 또는 메모리 감소).
- 사양 전달(
높음노력 P0/P1 항목): 3개 이상의 파일에 걸쳐 있거나 스키마/API를 변경하는 아키텍처 수정의 경우, 워커를 파견하기 전에spec-driven-feature를 호출하여 명시적인 파일 수정 경계 매트릭스와 함께.specs/remediate-<ID>.md를 초안으로 작성합니다.
5. 3단계: 대상 실행 및 결정론적 검증
승인된 각 수정 항목에 대해:
- 범위 지정 워커 파견:
- 특정 대상 파일, 수정 지침 및 검증 명령만 포함하여 실행 워커 하위 에이전트(
TypeName: 'self',Model: 'pro')를 시작합니다. - 프론트엔드 현대화 시너지:
UI-*발견에 대한 워커를 파견할 때, UI 수정이 최신 기준 HTML/CSS/JS API를 사용하도록 워커에게modern-web-guidance스킬(사용 가능한 경우)을 활성화하도록 지시합니다. - 동시성 및 샌드박스 가드: 대상 파일 집합이 겹치는 경우
Workspace: 'inherit'에서 두 워커를 동시에 실행하지 마십시오. 겹치는 편집을 단일 워커로 그룹화하고,Workspace: 'share'를 통해 격리하거나git-worktree-isolator를 통해 전용 워크트리를 프로비저닝합니다.
- 특정 대상 파일, 수정 지침 및 검증 명령만 포함하여 실행 워커 하위 에이전트(
- 검증 루프:
- 워커는 코드를 수정하고 결정론적 테스트 스위트를 실행해야 합니다(예:
npm test,pytest,cargo test, 린터). - 테스트가 실패하면 워커는 문제를 해결하기 위해 로컬에서 최대 3번까지 반복해야 합니다.
- 안전한 범위 지정 롤백: 3번 시도 후에도 실패가 지속되면 워커는 해당 대상 파일만 롤백(
git checkout -- <target-files>)하고, 절대git reset --hard를 사용하지 않으며, 정확한 실패 출력을 오케스트레이터에 보고해야 합니다.
- 워커는 코드를 수정하고 결정론적 테스트 스위트를 실행해야 합니다(예:
- 워커 반환 계약:
- 워커는
./references/schemas.md에 정의된 간결한Worker Verification Report Schema(git diff --stat요약 + 테스트/린터 통과 확인)만 반환해야 합니다. 수백 줄의 원시 통합 diff를 메인 대화에 붙여넣지 마십시오.
- 워커는
6. 토큰 및 Git 위생 규칙
- 전체 파일 덤프 또는 원시 통합 diff를 메인 채팅으로 다시 보내지 마십시오. 전체 분석은
.audit/remediation_plan.md에 보관하고 링크하십시오. - 중간 로그를 정리하십시오. 요약 테이블이 구성되면 원시 grep 출력을 폐기하십시오.
- Git 상태 정리: 감사 스크래치 파일이 리포지토리에 커밋되지 않도록
.audit/가.git/info/exclude에 나열되거나 커밋 전에 제거되었는지 확인하십시오. - 아키텍처 트레이드오프, 의사 결정 지점 및 사용자 승인에 메인 대화를 집중하십시오.