ArchMap 아키텍처 매핑 에이전트

터미널 네이티브 에이전트, 웹 인터페이스 없음. 영(零)매개변수 호출 시 자동으로 full/lite로 분기하며, 증분 요구사항 영향 분석, sync 동기화, diff 영향면 등 명시적 모드도 지원합니다.

설치 및 의존성

처음 사용하기 전에 이 스킬의 루트 디렉토리에서 pip3 install -r requirements.txt를 실행하세요 (자세한 내용은 README.md 참조). sentence-transformers는 선택적 의존성이며, 없을 경우 벡터 인식이 자동으로 로컬 해시 벡터화로 폴백되어 기능은 사용 가능하나 정확도가 약간 저하됩니다.

트리거 방식

/archmap <프로젝트 경로>                        # 영(零)매개변수 자동 분기 (권장)
/archmap <프로젝트 경로> full | lite [비고]      # 강제 모드 폴백
/archmap <프로젝트 경로> <요구사항 텍스트>
/archmap <프로젝트 경로> sync
/archmap <프로젝트 경로> diff [수정 내용 비고]

예시:

/archmap /Users/xujin/projects/my-app
/archmap /Users/xujin/projects/my-app 사용자 포인트 시스템 신규 추가, 로그인 인터페이스 및 역할 테이블 관련
/archmap /Users/xujin/projects/my-app sync

모드 라우팅 (영매개변수 자동 분기, 2026-08-12 신규)

영매개변수 호출 /archmap <프로젝트 경로>는 기준선 존재 여부에 따라 완전 자동 분기하며, 수동 전환 스위치 없음:

기준선 없음 (archmap/full_index.json 없음) → 자동으로 full 전체 초기화 실행
기준선 있음 → 자동으로 lite 극간 증분 실행 (일상 반복 기본값, 모드 G 참조)
특수 시나리오는 수동으로 폴백: full / lite 명시적 키워드로 강제 지정 (대규모 리팩토링 후 full로 전체 그래프 재생성, 기준선 디렉토리 삭제 불필요)

모드 목록

모드 A: 전체 분석 (프로젝트 경로만 입력)

경로가 프로젝트 루트 디렉토리인 경우:

전체 소스 코드 스캔 실행
비즈니스 디렉토리별로 모듈 분할, 멀티스레드 Worker로 파싱
모체에서 자산 집계, 공유 API/저장소 태깅, 벡터 캐시 생성
Mermaid 텍스트 차트 및 01~09번 Markdown 보고서 생성
결과를 <프로젝트 경로>/archmap/에 원자적으로 쓰기
산출물 경로 및 요약 출력

산출물 경로:

<프로젝트 경로>/archmap/
├── full_index.json          # 전체 아키텍처 기준선
├── vector_cache.json        # 모듈 벡터 캐시
├── 01_실행_요약.md
├── 02_아키텍처_다이어그램.md              # Mermaid 텍스트
├── 03_데이터_링크_다이어그램.md
├── 04_시퀀스_다이어그램.md
├── 05_모듈_자산_목록.md
├── 06_API_자산_목록.md
├── 07_저장소_자산_목록.md
├── 08_종속성_매트릭스.md
└── 09_세분화_검증_보고서.md

모드 B: 증분 영향면 분석 (프로젝트 경로 + 요구사항 텍스트)

기존 기준선에 해당하는 프로젝트 경로를 입력하고 요구사항 텍스트를 추가합니다. 이 모드는 요구사항을 매칭하기 전에 먼저 소스 코드의 실제 변경 사항을 동기화하므로, /archmap <경로> <요구사항> 호출 시 회고 통합이 트리거됩니다:

<프로젝트 경로>/archmap/ 아래의 vector_cache.json, full_index.json, module_hashes.json 읽기
현재 소스 코드를 마지막 동기화 시점의 모듈 콘텐츠 지문(SHA256)과 비교하여 변경/추가된 모듈 식별
변경된 모듈만 다시 파싱하여 기준선에 병합, 변경되지 않은 모듈은 기준선 데이터를 직접 재사용
요구사항 텍스트를 벡터화하여 최신 모듈 벡터와 코사인 유사도 매칭
높은 신뢰도/낮은 신뢰도 의심 모듈 구분, 상하위 의존성 재귀 탐색
요구사항에 적중된 신규/수정 모듈에 대해서만 Worker 파싱 시작, 기존 의존성 모듈은 기준선 데이터를 직접 재사용, LLM 호출하지 않음
적중된 모듈에 대해 모듈 내 정밀 위치 파악: 관련 파일, 함수/클래스명, 인터페이스 라우트, 라우트→파일 매핑 식별, 요구사항 키워드 관련도순 정렬
재현율 보강 (recall_engine): 벡터 적중을 기반으로 두 가지 확정적 신호를 사용하여 영향을 받는 집합 확장, 벡터 임계값 제약 없음 — ① 라우트 공급-수요 클로저 (영향받는 모듈이 참조하는 라우트→정의 모듈, 및 정의 라우트의 참조 모듈) ② 요구사항 라우트 키워드 하드 매칭 (요구사항 단어에 CN→EN 확장, 모듈 defined 라우트 직접 적중). 각 모듈의 적중 소스(vector/keyword/route_closure/route_keyword)를 match_sources에 출력
기준선 병합 업데이트, precise_analysis.json 영향면 파일 + precise_meta.json 예측 메타데이터(요구사항 텍스트, 적중 소스, 기준선 해시 지문) 생성
영향을 받는 모듈, API, 저장소, 관련 파일 목록 출력, 정확한 개발 안내

설명: 회고 동기화는 "기존 기준선 + 새 요구사항"이 있을 때만 트리거됩니다. 새 프로젝트의 첫 전체 분석에서는 동기화가 실행되지 않습니다.

산출물: 기준선 폴더 내 full_index.json, vector_cache.json 업데이트 및 precise_analysis.json 신규 추가:

[
  {
    "module_id": "src_users",
    "module_path": "src/users/",
    "files": [
      {
        "file_path": "api.py",
        "functions": ["list_users", "get_user"],
        "classes": [],
        "routes": ["/api/users", "/api/users/<id>"],
        "relevance": 0.6
      }
    ],
    "route_to_files": {
      "/api/users": ["api.py"],
      "/api/users/<id>": ["api.py"]
    },
    "keyword_matches": ["api.py"]
  }
]

모드 C: 동기화 업데이트 (프로젝트 경로 + sync)

프로젝트 전체 분석이 완료되고 지속적인 개발이 진행된 후, 새 코드를 기존 기준선에 병합해야 하며 전체 분석을 다시 실행할 필요는 없습니다.

트리거:

/archmap <프로젝트 경로> sync
/archmap <프로젝트 경로> sync

실행 흐름:

<프로젝트 경로>/archmap/ 아래의 full_index.json, vector_cache.json, module_hashes.json 읽기
현재 소스 코드를 마지막 동기화 시점의 모듈 콘텐츠 지문(SHA256)과 비교
추가/수정된 모듈만 다시 파싱하고, 이미 파싱된 변경되지 않은 모듈은 기준선 데이터를 직접 재사용하며, LLM 호출하지 않음
기준선에서 삭제된 모듈 및 해당 벡터 제거
Mermaid 차트 및 01~09번 Markdown 보고서 재생성
full_index.json, vector_cache.json, module_hashes.json 및 보고서 파일을 원자적으로 업데이트
재현율 검증 (recall_engine): 기준선 내에 마지막 영향면 분석의 예측 파일(precise_analysis.json + precise_meta.json)이 있으면, 예측 모듈과 이번 실제 변경 모듈을 자동 비교:
- 변경 있음 → recall_report.json 생성 (적중률, 누락 모듈 및 귀인: route_keyword_miss / closure_miss / vector_miss), recall_history.jsonl에 추가, 이후 예측 파일 소비
- 변경 없음 → 예측 유지, 개발 완료 후 다음 동기화 시 검증
- 기준선 해시 지문 불일치 (예측이 이미 종료된 이전 개발 주기에 속함) → 오래된 예측 폐기, 검증하지 않음

산출물: 기준선 폴더 전체 내용 새로고침, 구조는 모드 A와 동일하지만 변경된 모듈의 파싱 비용만 소모. 검증 보류 중인 예측이 있을 경우 recall_report.json 및 recall_history.jsonl 신규 추가.

<프로젝트 경로>/archmap/
├── full_index.json          # 신규/수정 모듈 병합 완료
├── vector_cache.json        # 변경된 모듈의 벡터만 재계산
├── module_hashes.json       # 최신 모듈 콘텐츠 지문
├── 01_실행_요약.md
├── 02_아키텍처_다이어그램.md
├── 03_데이터_링크_다이어그램.md
├── 04_시퀀스_다이어그램.md
├── 05_모듈_자산_목록.md
├── 06_API_자산_목록.md
├── 07_저장소_자산_목록.md
├── 08_종속성_매트릭스.md
└── 09_세분화_검증_보고서.md

일반적인 사용 리듬:

처음: /archmap /path/to/project
새 기능 개발 및 소스 코드 수정
회고 동기화: /archmap /path/to/project sync
영향 파악: /archmap /path/to/project 포인트 기능 추가

모드 D: ETL 기본 규칙 조사 (자동 트리거)

ETL 특성 디렉토리가 있는 프로젝트(tongue_diagnosis/etl / etl_config / etl/core 중 하나라도 존재)의 경우, 전체 분석 및 동기화 업데이트 시 자동으로 7가지 ETL 변경 유지 관리 서비스 산출물 생성, <프로젝트 경로>/archmap/etl_rules/에 쓰기:

#	산출물	내용
①	`ETL_규칙_인덱스_총목차.md`	7개 계층 디렉토리 트리 (전처리 정리→Chunk 분할→벡터화 쓰기→일관성 대사→분리 저장→예외 재시도→ETL 오케스트레이션) + 규칙 고유 코드 (ETL-CHUNK-01 등) + 키워드 태그 + 검색 빠른 색인 + 7단계 사용 흐름
②	`details/ETL-{코드}.md` (규칙당 1개)	통일 7개 장: 규칙 기본 식별 / 전체 기본 실행 로직 / 소스 코드 정밀 위치 / 입력 출력 제약 / 관련 의존 규칙 / 변경 이력 기록 / 테스트 검증 기준
③	`etl_rule_mapping.json`	ETL 규칙-코드-구성 매핑 대조표 (기계 판독 가능)
④	`ETL_규칙_의존성_링크_다이어그램.md`	Mermaid 의존성 그래프 + 텍스트 영향 목록 + 영향 등급 (높음/중간/낮음)
⑤	`ETL_전역_매개변수_기준선_테이블.md`	모든 규칙 매개변수 기준선 값 + 구성 파일 출처
⑥	`ETL_규칙_변경_위험_평가_목록.md`	모든 규칙 위험 등급/설명/회귀 테스트 + 변경 전 작업
⑦	`etl_rule_search_index.json`	기계 검색 색인 (규칙 항목 + 키워드 빠른 색인 keyword → 규칙 코드)
⑧	`ETL_구성_계약_정렬_보고서.md` + `config_contract_report.json`	구성-코드 계약 드리프트 감지 (정기 정렬): yaml 키 실제 존재 + read/use 특성 문자열 grep → aligned (연결됨) / unused (데드 구성) / stale (코드 잔재) / missing_from_yaml (계약 불일치) + 처리 제안

요점:

정기 정렬 (구성 계약 드리프트): 구성을 변경하거나 코드 소비 지점을 변경한 후 /archmap <프로젝트 경로> sync 실행, ⑧ 보고서가 각 필드 상태를 자동 새로고침 (필드 존재 ≠ 적용: unused/stale은 처리 제안에 따라 연결 또는 정리 필요); 기존 기준선 드리프트 예: RRF 가중치 미적용 (rag_engine._rrf_fuse weights가 1.0으로 하드코딩됨), max_ctx_tokens 구성 미연결, reconcile.enabled/batch_size 데드 구성, embedding.yaml batch_size 미소비
소스 코드 위치 라인 번호는 런타임에 함수명/특성 문자열 grep으로 파싱, 코드 변경 후 /archmap <프로젝트 경로> sync 실행 시 모든 라인 번호와 산출물이 새로고침됨
P0/P1/P2 파싱 깊이 등급 (2026-08-12 2기): risk_level 높음→P0 깊이 파싱 (라인 번호+구성+계약), 중간→P1 표준 파싱 (라인 번호), 낮음→P2 경량 파싱 (파일 존재 여부만 확인, 라인 번호 파싱 생략 및 unresolved 범위에 미포함); 세부 문서 헤더/인덱스 총목차/mapping JSON/search_index JSON 모두 priority 식별자 포함, summary에 priority_counts 및 parse_depth 통계 포함; 단일 규칙은 etl_rule_registry.py에 priority 필드를 명시적으로 작성하여 추론 재정의 가능
백필 규칙 (ETL 규칙/단계/구성 변경 후 반드시 실행): /archmap <프로젝트 경로> sync 실행 시 세 가지 측면 자동 백필 — ① 라인 번호 (grep 실시간 파싱); ② 매개변수 기준선 (etl.yaml/embedding.yaml/chunking.yaml 런타임 읽기, ③⑤⑦의 해당 규칙 매개변수가 구성 파일 현재 값으로 자동 새로고침됨); ③ 의미적 변경 (규칙 이름 변경/동작 변경/위험 등급 조정)은 etl_rule_registry.py에 history 레코드 추가 후 sync 재실행하여 재생성. sync를 실행하지 않으면 문서와 코드/구성이 드리프트됨
검색 진입점: etl_rules/etl_rule_search_index.json (기계) 또는 인덱스 총목차 키워드 테이블 (수동) 읽기
세부 문서에는 테스트 검증 기준 챕터가 포함되어 있으며, 규칙 변경 후 해당 사용 사례로 회귀 테스트 실행
사용자 정의 ETL 규칙 등록부 재정의 메커니즘은 README.md의 '프로젝트 수준 구성' 섹션 참조

모드 E: 테스트 설계 입력 자산 (Test Design Input Assets)

ArchMap 전체 분석의 산출물인 아키텍처 다이어그램, 데이터 링크 다이어그램, 시퀀스 다이어그램, 자산 목록, 종속성 매트릭스는 test-case-designer의 입력으로 직접 사용되어 '노드 + 분기 + 메서드' 삼요소 테스트 설계를 구동할 수 있습니다.

테스트 설계에서 소비 가능한 산출물

산출물 파일	테스트 설계 용도	추출 내용
`02_아키텍처_다이어그램.md`	시스템 계층 및 모듈 경계 식별	계층 노드 (Trigger/Definition/Persistence/Engine/Validation)
`03_데이터_링크_다이어그램.md`	종단 간 데이터 흐름 식별	데이터 흐름 노드, 입력/출력, 영속화 지점
`04_시퀀스_다이어그램.md`	호출 순서 및 동시성/대기 관계 식별	호출 시퀀스, 동기/비동기 경계, 예외 반환 지점
`05_모듈_자산_목록.md`	기능 모듈 및 책임 식별	모듈명, 코어 함수, 책임 설명
`06_API_자산_목록.md`	인터페이스 테스트 노드 식별	라우트, 메서드, 매개변수, 반환 구조, 오류 코드
`07_저장소_자산_목록.md`	데이터 영속화 테스트 포인트 식별	저장소 유형, 필드, 제약 조건, 생명 주기
`08_종속성_매트릭스.md`	변경 영향면 및 회귀 범위 식별	모듈 간 호출 관계, 공유 API/저장소
`precise_analysis.json`	증분 요구사항 시 테스트 범위 정밀 파악	변경 모듈, 관련 파일, 함수/라우트, 관련도

테스트 설계 입력 표준 형식

test-case-designer는 위 산출물을 읽은 후 정보를 다음 표준 구조로 축약해야 합니다 (설계 중간 산출물로 execution-list.json과 함께 제출하여 검토, archmap 산출물 파일로 저장되지 않음 — archmap 엔진 산출물은 01~09에 한함):

## 테스트 노드 목록 (Node Inventory)

| 노드 번호 | 노드 이름 | 소속 모듈 | 기능/역할 | 입력 | 출력 | 영속화 |
|----------|----------|----------|-----------|------|------|--------|
| N-001 | create_workflow_endpoint | webui.py | Web UI를 통해 새 워크플로우 생성 | {name, mode} | flow.yml / SKILL.md / 디렉토리 | 새 디렉토리 트리 생성 |
| N-002 | validate_flow_structure | workflow.py | flow.yml 구조 유효성 검증 | flow_data | 오류 목록 또는 빈 목록 | 없음 |
| N-003 | gate_a_check | engine.py | 실행 전 접근 허가 검증 | agent, state | passed/errors/log | engine_state.json |

## 분기 폐쇄 목록 (Branch Closure)

| 소스 노드 | 분기 조건 | 참 분기 | 거짓 분기 | 잘못된 입력 | 상태 불일치 |
|--------|----------|--------|--------|----------|------------|
| N-001 | name이 비었는지 여부 | 계속 생성 | 400 반환 | 초과 길이/특수 문자 | 상위 디렉토리 설정되지 않음 |
| N-003 | upstream이 모두 완료되었는지 여부 | Gate B 진입 | blocked | 알 수 없는 노드 | 전달물 해시 변조 |

## 테스트 메서드 매핑 (Method Mapping)

| 노드 | 경계값(BV) | 동등 클래스(EC) | 요구사항 로직(DL) | 시나리오(SC) | 예외(EX) | 호환성(CP) | 인터페이스 보안(IS) |
|------|------------|------------|--------------|----------|----------|--------------|------------------|
| N-001 | 이름 길이 경계 | 유효/무효 이름 | 생성→생성→반환 | 정상 생성 흐름 | 상위 디렉토리 누락 | — | 경로 탐색/특수 문자 |
| N-003 | max_retry 경계 | 상위 완료/미완료 | Gate A→실행→Gate B | 정상 진행 | 해시 불일치 | jsonschema 있음/없음 | — |

증분 시나리오에서의 소비 방식

PM이 새 요구사항을 제시한 경우:

/archmap <프로젝트 경로> "요구사항 텍스트" 호출하여 precise_analysis.json 생성/업데이트
test-case-designer는 우선 precise_analysis.json의 변경 모듈 및 관련 파일을 읽음
변경 모듈 및 그 직접 의존 모듈에 대해서만 테스트 노드 추출, 전체 재설계 방지
execution-list.json에서 baseline_affected: true로 표시된 테스트 케이스를 정밀 회귀에 사용

test-case-designer와의 연동 계약

test-case-designer는 자체 분석 능력을 보유하며, 시작 후 다음 로직에 따라 처리:

자체적으로 기존 분석 결과 발견: <프로젝트 경로>/archmap/이 존재하고 유효한 02_아키텍처_다이어그램.md 및 03_데이터_링크_다이어그램.md를 포함하는지 확인
- 존재할 경우: 02~08번 산출물 + precise_analysis.json (증분 시나리오)을 직접 읽어 테스트 설계 입력으로 사용, 중복 분석 방지
- 존재하지 않거나 만료된 경우: 자체적으로 /archmap <프로젝트 경로> (전체) 또는 /archmap <프로젝트 경로> "요구사항 텍스트" (증분)를 호출하여 분석 결과 생성 후 읽어서 사용. PM은 테스트 전에 archmap을 별도로 호출할 필요 없음
02_아키텍처_다이어그램.md + 03_데이터_링크_다이어그램.md + 04_시퀀스_다이어그램.md를 읽어 시스템 수준 테스트 노드 식별
05_모듈_자산_목록.md + 06_API_자산_목록.md + 07_저장소_자산_목록.md를 읽어 모듈 수준 테스트 노드 식별
08_종속성_매트릭스.md를 읽어 노드 간 의존성 및 영향면 식별
축약된 노드/분기/메서드 목록을 설계 중간 산출물(규칙 32 Step 1.8《테스트 노드 및 분기 목록》)로 출력, execution-list.json과 함께 제출하여 검토

모드 F: diff 영향면 분석 (프로젝트 경로 + diff, 2026-08-12 신규)

버전 업데이트 후 차별화된 영향면 분석으로, 화이트박스 증분 테스트 등 다운스트림에 권위 있는 diff 입력 제공. git 무관 (저장소 없는 프로젝트에서 사용 가능), LLM 호출 없음, 초 단위 완료.

실행 시점 (고정 게이트): 기능 추가/수정 완료 후, 회고 단계 전에 반드시 한 번 실행. 이번 변경 (시간+수정 내용+행 구간+영향 클로저)이 자동으로 변경 이력에 기록되어 회고의 입력 자료로 사용됨; 검증 통과 후 sync로 기준선 새로고침 및 01~09 분석 문서 재생성 — diff 기록, 변경 이력, 분석 문서가 하나의 전체를 구성.

트리거:

/archmap <프로젝트 경로> diff
/archmap <프로젝트 경로> diff 이번에 비디오 속도 변경 기능에 잘못된 매개변수 검증 추가

실행 흐름:

기준선 디렉토리의 행 수준 스냅샷 file_line_hashes.json 읽기 (full/sync 시 자동 쓰기; 첫 diff 시 스냅샷 없으면 초기화 후 다음 라운드부터 비교 가능하도록 안내)
파일별 difflib로 현재 행 해시와 스냅샷 비교 → 변경 파일의 정확한 변경 행 구간 출력 (1-based, 인접 구간 병합). 변경되지 않은 파일은 해시 비교만 수행, 재분석하지 않음
의존성 그래프 (루트 디렉토리 파일 포함, 모듈 스캔 세분성에 의존하지 않음) 세 가지 에지: Python import (AST), JS/TS/Vue import/require (정규식+별칭 해석), 언어 간 라우트 공급-수요 에지 (라우트 정의×리터럴 참조, 양방향); 캐시는 file_imports.json + file_routes.json으로, 변경/캐시 누락 파일만 다시 파싱; 새 파일 또는 삭제 파일은 구조적 변경이므로 전체 재파싱 한 번 수행하여 에지 누락 방지. v2부터 스냅샷이 .py/.ts/.tsx/.js/.jsx/.vue/.sql/.yaml/.yml을 포함, v1 스냅샷은 자동 마이그레이션
변경된 비즈니스 파일에서 역방향 import 에지를 따라 BFS → 영향 클로저 (변경 파일 + 모든 전이 의존 대상); 테스트 파일은 집계점으로만 작용, 전파되지 않음
테스트 선택: 선택됨 = 클로저 내 테스트 파일 ∪ 자체 변경된 테스트 파일; untested_changes 표시 (클로저 내 테스트가 없는 변경 비즈니스 파일)
프로젝트 루트에 coverage-tiers.json이 있으면, 최장 접두사 매칭으로 각 변경 파일에 tier 지정
<프로젝트 경로>/archmap/diff_impact.json 산출; 행 수준 스냅샷은 diff 모드에서 업데이트되지 않음 (동일 작업 기간 동안 반복 비교 결과 안정성 보장), 다음 full/sync 시 새로고침
변경 있을 때 자동 흔적 남기기: diff_history.jsonl (기계 판독 가능, 비고 포함) 추가 및 10_변경_이력.md 재렌더링 (시간+수정 내용+변경 파일 구간+클로저+테스트 선택); 변경 없을 시 기록하지 않음

산출물 구조:

{
  "changed_files": [{"path": "ui/main_window.py", "change_type": "modified", "tier": "P2", "changed_ranges": [[169, 182]]}],
  "deleted_files": [],
  "affected_closure": {"files": ["..."], "changed": ["..."], "propagated": ["..."]},
  "test_selection": {"selected": ["tests/test_main_window.py"], "skipped": ["..."], "untested_changes": []},
  "stats": {"changed_files": 1, "changed_ranges": 1, "closure_files": 3, "tests_selected": 1, "tests_skipped": 7},
  "history_path": "<프로젝트 경로>/archmap/diff_history.jsonl",
  "history_doc": "<프로젝트 경로>/archmap/10_변경_이력.md"
}

다운스트림 소비: whitebox-coverage 증분 모드는 diff_impact.json을 유일한 범위 기준으로 사용 (선택적 실행 + --diff-scope 갭 필터링 + diff_gate 게이트); 회고 흐름은 10_변경_이력.md을 변경 대장 입력으로 사용.

모드 G: lite 극간 증분 (영매개변수 호출 시 기준선이 있으면 자동 진입, 또는 명시적 `lite`, 2026-08-12 신규)

일상 개발 반복의 기본 모드. sync와의 차이점: 01~09 전체 보고서 및 아키텍처 큰 그림을 재생성하지 않음, 변경 폐쇄만 수행, 초 단위 완료:

행 수준 스냅샷 비교로 변경 감지 (모드 F와 동일 엔진, git 무관)
변경된 모듈만 다시 파싱하여 기준선에 병합 (full_index / vector_cache / module_hashes / 행 수준 스냅샷 / 가져오기 그래프 캐시 모두 새로고침)
변경 있을 시 자동 흔적 남기기: diff_history.jsonl 추가 + 10_변경_이력.md 재렌더링 (수정 내용 비고 포함 가능)
ETL 프로젝트의 경우 etl_rules/ 산출물 자동 새로고침; 검증되지 않은 예측이 있을 경우 정상적으로 재현율 검증 수행
diff_impact.json 산출/새로고침 (direct_dependents 1차 의존 요약 + 전체 전이 클로저 포함, 기계는 전체 클로저를 읽으며 Agent 컨텍스트를 차지하지 않음)

변경 없을 시 바로 '변경 없음, 업데이트 불필요' 반환. 01~09 보고서가 최신 코드를 반영해야 하는 경우 sync 또는 full 실행.

기본 호출

래퍼 스크립트 위치:

/Users/xujin/.agents/skills/archmap/archmap <프로젝트 경로> [요구사항 텍스트]

동등:

# 전체
python3 /Users/xujin/.agents/skills/archmap/archmap /path/to/project

# 증분
python3 /Users/xujin/.agents/skills/archmap/archmap /path/to/project "사용자 포인트 시스템 추가"

엔진 패키지 archmap_agent는 스킬과 함께 자체 포함되어 배포됨 (래퍼 스크립트와 동일 디렉토리), 엔진을 별도로 설치할 필요 없음.

제약 사항

어떤 웹 서비스도 시작하지 않음.
SQLite 작업 테이블을 읽거나 쓰지 않음.
모든 상태는 프로젝트 경로 아래 archmap/ 폴더에 저장됨.
사용자의 원래 비즈니스 코드를 수정하지 않으며, 정적 소스 코드 분석만 수행.
전체 모드는 비즈니스 디렉토리만 스캔하며, test, node_modules, dist, build 등 디렉토리는 자동 필터링.
증분 모드는 기존 기준선 자산을 재사용하며, 변경되지 않은 모듈을 다시 파싱하지 않아 Token 소비를 크게 줄임.
출력은 모두 JSON/YAML/Markdown/Mermaid 일반 텍스트이며, 이미지를 생성하지 않음.

xu-jin-cs/dsh-skills

dsh-skills란 무엇인가요?

즐겨 사용하는 AI에게 물어보기

문서

ArchMap 아키텍처 매핑 에이전트

설치 및 의존성

트리거 방식

모드 라우팅 (영매개변수 자동 분기, 2026-08-12 신규)

모드 목록

모드 A: 전체 분석 (프로젝트 경로만 입력)

모드 B: 증분 영향면 분석 (프로젝트 경로 + 요구사항 텍스트)

모드 C: 동기화 업데이트 (프로젝트 경로 + sync)

모드 D: ETL 기본 규칙 조사 (자동 트리거)

모드 E: 테스트 설계 입력 자산 (Test Design Input Assets)

테스트 설계에서 소비 가능한 산출물

테스트 설계 입력 표준 형식

증분 시나리오에서의 소비 방식

test-case-designer와의 연동 계약

모드 F: diff 영향면 분석 (프로젝트 경로 + diff, 2026-08-12 신규)

모드 G: lite 극간 증분 (영매개변수 호출 시 기준선이 있으면 자동 진입, 또는 명시적 `lite`, 2026-08-12 신규)

기본 호출

제약 사항

관련 스킬

affaan-m/uspto-database

affaan-m/scholar-evaluation

affaan-m/literature-review

affaan-m/everything-claude-code

forrestchang/andrej-karpathy-skills

langgenius/backend-code-review

즐겨 사용하는 AI에게 물어보기

문서

ArchMap 아키텍처 매핑 에이전트

설치 및 의존성

트리거 방식

모드 라우팅 (영매개변수 자동 분기, 2026-08-12 신규)

모드 목록

모드 A: 전체 분석 (프로젝트 경로만 입력)

모드 B: 증분 영향면 분석 (프로젝트 경로 + 요구사항 텍스트)

모드 C: 동기화 업데이트 (프로젝트 경로 + sync)

모드 D: ETL 기본 규칙 조사 (자동 트리거)

모드 E: 테스트 설계 입력 자산 (Test Design Input Assets)

테스트 설계에서 소비 가능한 산출물

테스트 설계 입력 표준 형식

증분 시나리오에서의 소비 방식

test-case-designer와의 연동 계약

모드 F: diff 영향면 분석 (프로젝트 경로 + diff, 2026-08-12 신규)

모드 G: lite 극간 증분 (영매개변수 호출 시 기준선이 있으면 자동 진입, 또는 명시적 lite, 2026-08-12 신규)

기본 호출

제약 사항

관련 스킬

affaan-m/uspto-database

affaan-m/scholar-evaluation

affaan-m/literature-review

affaan-m/everything-claude-code

forrestchang/andrej-karpathy-skills

langgenius/backend-code-review

모드 G: lite 극간 증분 (영매개변수 호출 시 기준선이 있으면 자동 진입, 또는 명시적 `lite`, 2026-08-12 신규)