security-audit-skill 딥다이브
— AI의 의심을 검증 가능한 보안 증거로 바꾸는 법

1프로젝트 한줄 요약

security-audit-skill은 코딩 에이전트가 소스를 조사하고, 취약점 후보를 찾고, 다른 에이전트에게 반박을 맡긴 뒤, 결과를 JSON과 보고서로 남기도록 안내하는 저장소입니다. 여기서 스킬은 에이전트가 읽는 작업 지침 묶음이며, 실제 모델 호출과 도구 실행은 사용 중인 에이전트 플랫폼이 담당합니다.

이 프로젝트의 핵심은 취약점을 많이 주장하는 것이 아니라, 어떤 증거로 무엇을 확정했는지 추적하게 만드는 것입니다. 이를 위해 절차를 Markdown에 적고, 기록이 그 절차의 데이터 규칙을 지켰는지는 JavaScript로 검사합니다.

1-1. 결과는 세 가지 판정으로 나뉩니다

예를 들어 소스에 소유권 검사가 보이지 않아도, 앞단 공통 함수가 이미 검사할 수 있습니다. 그 경로를 확인하면 rejected가 될 수 있습니다. 반면 생성된 코드가 없어 호출 경로를 끝까지 볼 수 없다면, 구체적인 차단 요인을 적은 needs_validation이 적절합니다.

1-2. 질문에 답하는 모드와 전체 감사 모드

skills/security-audit/SKILL.md는 기본 동작을 guidance로 정합니다. 보안 질문이나 특정 코드 검토에는 필요한 지침만 사용합니다. 코드베이스 감사·침투 테스트·전체 검토 또는 보고서 산출물을 명시적으로 요청할 때 full audit의 여섯 단계를 적용합니다.

2왜 주목받는가

2-1. 실제 운영 경험에서 출발한 단일 저장소용 절차

Cloudflare는 2026-06-18 공식 글에서 단일 저장소용 보안 스킬을 발전시켜 여러 저장소를 다루는 감사 시스템을 만들었다고 설명합니다. 이 저장소의 README도 자신을 그 출발점으로 소개합니다. 공개된 것은 전체 사내 시스템이 아니라 한 저장소를 검토하는 데 쓰는 지침과 결과 검증기입니다. Cloudflare 공식 배경 글

TrendShift Daily #9 선정과 GitHub 스타 40,122개는 2026-10-23 기준입니다. 일일 순위와 누적 스타 수만으로 관심이 늘어난 직접 원인을 판단할 수는 없습니다. 다만 공개된 방법론, 독립 검증, 기계가 읽을 수 있는 산출물은 관심을 끌 만한 설계상 이유로 해석할 수 있습니다.

2-2. 비교할 때는 탐지 엔진과 감사 절차를 구분합니다

CodeQL의 처리 흐름은 공식 개요, Semgrep의 제품 범위는 공식 문서를 기준으로 비교했습니다. 이 표는 기능의 중심을 비교한 것이며, 탐지율·속도·비용의 우열을 측정한 결과가 아닙니다. 이 저장소에는 두 제품을 자동 호출하는 통합 코드도 없습니다.

이 저장소의 장점은 판단을 여러 번 검토하고 미완료 범위를 기록하도록 요구하는 데 있습니다. 그 요구를 실제로 수행하는 능력은 모델과 호스트 플랫폼에 달려 있습니다.

2-3. “한 번 돌리면 다 찾는다”는 설명을 스스로 경계합니다

README 기준, 자체 시험에서 한 번의 실행이 반복 실행 전체에서 나온 취약점의 대략 절반을 찾았다고 합니다. 저장소에는 그 수치를 재계산할 데이터셋이나 벤치마크 실행기가 없습니다. 따라서 이를 일반적인 탐지율 50%로 받아들이면 안 됩니다. 공부할 부분은 수치 자체보다, 이전 기록을 다음 실행의 입력으로 삼아 빈틈을 다시 조사하는 설계입니다.

3기술 스택 전체 지도

3-1. 의존성 명세와 실행 구성

커밋 c1c8a8c의 추적 파일은 22개입니다. package.json, 잠금 파일, Cargo.toml, pyproject.toml, go.mod, Dockerfile, .github/workflows/는 없습니다. 따라서 프레임워크 버전·Node.js 최소 버전·CI 이미지 버전을 의존성 파일에서 인용할 수 없습니다. 없는 버전을 추정해서 채우지 않는 것도 소스 분석의 기본입니다.

3-2. “의존성 없음”은 어떤 뜻일까요?

validate-findings.cjs는 fs·path·util을, validate-coverage-ledger.cjs는 같은 Node.js 내장 모듈을 node: 접두사로 가져옵니다. 결과 검증에 필요한 외부 npm 패키지가 없다는 의미입니다. 모델 사용료, 호스트 에이전트, 대상 프로젝트의 빌드 도구까지 필요 없다는 뜻은 아닙니다.

// validate-findings.cjs: 실제 진입점과 내보내기 방식의 발췌
module.exports = {
  LIMITS,
  collect,
  collectFindingSemanticErrors,
  collectSchemaErrors,
  validateDocument,
  // 그 밖의 공개 보조 함수·상수는 원본 참조
};
if (require.main === module) process.exit(run(process.argv[2]));

마지막 조건 때문에 이 파일은 두 역할을 가집니다. 직접 실행하면 파일 경로를 받는 명령행 도구가 되고, 테스트에서 require()하면 함수 묶음으로 사용할 수 있습니다. 위 코드는 구조를 설명하기 위해 일부 내보내기를 생략한 발췌입니다.

3-3. 코드 규모

집계는 .git/을 제외하고 UTF-8 파일의 줄바꿈 수를 세었습니다. 빈 줄·주석·문서 속 코드 예시를 포함하며, 순수 실행문 수가 아닙니다. JavaScript는 합계 3,037줄이고, 테스트 파일에는 최상위 test( 선언이 각각 34개와 31개 있습니다. 선언 수를 실제 통과한 테스트 수로 해석하면 안 됩니다.

이 레포에서는 문서가 작업 방식을 정하고, 작은 프로그램이 결과 기록의 계약을 검사합니다. JavaScript만 읽으면 감사 방법을 놓치고, Markdown만 읽으면 기계적으로 보장되는 범위를 과대평가하기 쉽습니다.

4아키텍처 심화 분석

4-1. 전체 흐름: 호스트가 지침을 실행합니다

아래 그림은 SKILL.md의 전체 감사 절차를 재구성한 것입니다. 저장소에 이 흐름을 자동으로 실행하는 스케줄러 함수가 있다는 뜻은 아닙니다. Parent와 하위 에이전트는 사용 중인 플랫폼의 역할이며, 이 레포는 그 역할 사이의 계약을 제공합니다.

전체 감사의 공유 파일은 Parent만 씁니다. 하위 에이전트는 자신에게 할당된 scratch/에서만 작업하고 구조화된 결과를 반환합니다. 이 규칙은 동시 작업 중 장부가 서로 덮어써지는 문제와, 조사 대상이 증거 파일을 조작하는 문제를 함께 다룹니다.

4-2. 설계 패턴 ① 단일 작성자와 독립 검토자

HUNTING.md의 발견자는 units, candidates, hardening, uncovered를 가진 JSON 객체를 돌려줍니다. 조정자는 배정한 범위 ID와 응답을 대조하고 공유 장부에 반영합니다. 발견자에게 전체 보고서를 직접 편집하게 하지 않는 구조입니다.

VALIDATION-AND-REPORTING.md의 Phase 3 검증자는 후보를 발견하지 않은 새 에이전트입니다. Phase 5에서는 최종 confirmed·needs_validation 기록을 다시 확인합니다. quick만 두 검토를 한 새 검증자가 맡고, 나머지 프로필은 두 검토를 분리합니다.

같은 모델을 새로 호출해도 오류가 통계적으로 독립적이라는 보장은 없습니다. 여기서 독립성은 발견자와 검증자의 역할·문맥·작성 권한을 분리한다는 절차적 의미입니다. 이를 실행하는 에이전트 관리 코드는 이 저장소에 포함되어 있지 않습니다.

소스 연결: SKILL.md의 Write isolation, HUNTING.md의 Parent consolidation and ledger update, VALIDATION-AND-REPORTING.md의 Phase 3·5. 검증 지침 원문

4-3. 설계 패턴 ② 판정별 데이터 계약과 의미 검증

report-schema.json의 최상위는 배열이고 각 원소는 oneOf 세 분기 중 정확히 하나에 맞아야 합니다. verdict의 const가 분기를 구별합니다. 각 판정 객체의 additionalProperties: false는 발견자 응답의 임시 필드가 최종 기록으로 섞여 들어오는 것을 막습니다.

// report-schema.json의 구조를 요약한 설명용 조각
{
  "type": "array",
  "items": {
    "oneOf": [
      { "properties": { "verdict": { "const": "confirmed" } } },
      { "properties": { "verdict": { "const": "needs_validation" } } },
      { "properties": { "verdict": { "const": "rejected" } } }
    ]
  }
}

위 조각은 필수 필드들을 생략한 구조 설명입니다. 실제 confirmed는 execution.observed_result, remediation.strategy, severity, confidence 등까지 요구합니다. needs_validation에는 확정 원인인 root_cause 대신 가설임을 드러내는 claimed_root_cause가 들어갑니다.

validate-findings.cjs의 validateDocument()는 스키마 자체 검사, 데이터 한도 검사, 구조 검사, collectFindingSemanticErrors() 순으로 진행합니다. 마지막 함수는 스키마만으로 표현하기 번거로운 규칙을 확인합니다.

심각도 검사는 SEVERITY_RANK로 등급을 비교합니다. 가능성과 영향을 수치로 곱해 자동 점수를 계산하는 구현은 없습니다. 문서의 “가능성 × 영향” 원칙과, 코드가 실제로 강제하는 overall_severity 상한을 구분해야 합니다.

소스 연결: collectFindingSemanticErrors()와 validateDocument().

4-4. 설계 패턴 ③ 안정적인 식별자와 상태 불변식

장부의 한 단위는 입력 표면 × 신뢰 경계 × 하위 시스템 × 공격 유형의 조합입니다. deep에서는 필요한 생명주기 구분도 더합니다. 사람에게 보여줄 이름과 canonical_refs의 안정적인 원본 참조를 별도로 둡니다.

// validate-coverage-ledger.cjs: 실제 함수
function canonicalCoverageId(refs) {
  if (!isObject(refs)) throw new TypeError("canonical_refs must be an object");
  const fields = hasOwn(refs, "lifecycle") ? [...REF_FIELDS, "lifecycle"] : REF_FIELDS;
  if (Object.keys(refs).length !== fields.length || fields.some((field) => !hasOwn(refs, field))) {
    throw new TypeError("canonical_refs has missing or unexpected fields");
  }
  return fields.map((field) => encodeCanonicalRef(refs[field])).join("::");
}

encodeCanonicalRef()는 UTF-8 바이트를 퍼센트 인코딩합니다. route name은 route%20name, route-name은 그대로 남아 서로 구별됩니다. 공백을 하이픈으로 바꾸는 단순한 슬러그보다 정보 손실을 줄입니다. 입력은 NFC 정규형이어야 하며, 함수가 다른 정규형을 조용히 변환해 받아들이지는 않습니다.

validateStateInvariants()는 상태마다 허용되는 증거 모양을 검사합니다. 예를 들어 planned에는 담당자와 완료 증거가 없어야 하고, covered에는 담당자·검토 경로·검사 기록이 있어야 합니다.

not_applicable과 out_of_scope도 미배정 상태이며 제외 이유가 필요합니다. 증거가 있는 단위를 재배정할 때는 이전 증거를 attempts에 보존합니다. validateAttempts()는 이전보다 증가한 차수, 새 담당자, 이전 산출물의 재사용 금지 등을 확인합니다.

단, 검증기는 현재 장부와 그 안의 이력만 읽습니다. 실제 실행 중 모든 전이가 적법했는지, 이전 파일이 몰래 바뀌지 않았는지까지 자동으로 증명하는 이벤트 저장소는 아닙니다.

소스 연결: canonicalCoverageId(), validateStateInvariants(), validateReviewedPathOwnership(), validateAttempts().

4-5. 설계 패턴 ④ 검증기 자신의 입력도 신뢰하지 않기

두 CLI의 readFileWithinLimit()는 파일을 열 때 O_NOFOLLOW와 O_NONBLOCK을 사용합니다. 열린 파일 기술자를 fstatSync()로 검사하고 일반 파일만 읽습니다. 읽기 전 크기와 누적 읽기 크기를 모두 제한하며, 잘못된 UTF-8은 엄격한 TextDecoder로 거부합니다.

enforceJsonTextLimits()와 preflightJsonText()는 JSON.parse() 전에 구조 한도를 검사합니다. 파싱 이후에만 검사하면 거대한 입력을 이미 메모리에 펼친 뒤일 수 있기 때문입니다. 진단 메시지도 safeQuote()와 escapeUnsafeDiagnosticCharacters()를 거쳐 제어문자의 영향을 줄입니다.

검증기를 통과했다는 사실은 기록의 형식과 일관성을 뜻하며, 기록 속 주장이 사실임을 뜻하지 않습니다. 예를 들어 양의 줄 번호를 요구하지만 그 줄에 정말 해당 함수가 있는지 소스를 열어 확인하는 코드는 없습니다.

5디렉토리 구조 해부

5-1. 먼저 읽을 다섯 파일

그다음 report-schema.json의 판정 한 분기와 대응하는 테스트 데이터를 읽습니다. 773줄 검증기를 처음부터 전부 이해하려 하기보다, 특정 필드가 어디서 검사되는지 찾아가는 편이 효율적입니다.

5-2. 분야별 동반 문서 10개

아래 문서는 해당 기술을 구현한 모듈이 아니라 그 기술을 사용하는 감사 대상을 읽는 방법입니다. RECONNAISSANCE.md는 의존성 이름이 보인다는 이유만으로 선택하지 말고, 실제 신뢰 경계가 드러났을 때 관련 문서를 선택하라고 요구합니다.

6학습 포인트 (기술별)

6-1. JavaScript: 자료형보다 깊은 데이터 검증

validate()는 배열·객체·문자열을 재귀적으로 검사합니다. hasOwn()은 상속된 속성을 필수 필드로 인정하지 않게 합니다. 테스트에는 Object.create()로 상속한 verdict를 거부하는 사례도 있습니다.

canonicalKey()는 객체 키를 정렬해 구조화된 값을 안정적으로 비교합니다. 키 순서가 다른 {"id": 0, "label": "0"}과 {"label": "0", "id": 0}은 같은 항목으로 취급됩니다. 중복 비교를 위해 만든 문자열과 집합 자체에도 메모리 한도가 있습니다.

실습 아이디어: 두 객체의 키 순서만 바꿔 종이에 정규 비교 키를 써 보세요. 문자열 "1"과 숫자 1이 왜 다른 키를 가져야 하는지도 설명해 봅니다.

6-2. JSON Schema: 판정이 다르면 요구하는 정보도 다릅니다

oneOf는 대충 하나 이상 맞으면 되는 조건이 아닙니다. 정확히 한 분기만 맞아야 합니다. 이 저장소의 findDiscriminator()는 실패 시 verdict와 맞는 분기를 찾아 유용한 오류를 덧붙입니다. 오류 메시지가 명확해야 에이전트와 사람 모두 기록을 바로잡기 쉽습니다.

또한 visibleContent는 이 검증기가 추가로 해석하는 사용자 정의 키워드입니다. 일반 스키마 도구로 파일을 열었다고 같은 규칙이 모두 적용되는 것은 아닙니다. collectSchemaErrors()는 지원하지 않는 키워드를 조용히 무시하지 않고 오류로 처리합니다.

실습 아이디어: 세 판정에서 공통 필드와 전용 필드를 색으로 나눠 보세요. needs_validation에 severity를 넣으면 왜 의미까지 달라지는지 짧은 예로 설명합니다.

6-3. Unicode: 길이·보이는 내용·원문 보존은 다른 문제입니다

codePointLength()는 JavaScript 문자열의 UTF-16 코드 단위 수와 구별해 코드 포인트 수를 셉니다. hasValidUnicodeScalarValues()는 짝이 맞지 않는 서로게이트를 거부합니다. hasVisibleProse()는 공백·제어·표시되지 않는 문자만 있는 설명을 걸러냅니다.

반면 시험 입력을 보관하는 execution.payloads와 교체 코드의 fixed_code는 원문 그대로 남겨야 합니다. producerShapedFindings() 테스트 데이터는 빈 문자열과 특수 문자를 포함해 이 차이를 점검합니다. 설명문을 정리하는 규칙과 증거 원문을 보존하는 규칙을 분리한 사례입니다.

실습 아이디어: "", 공백만 있는 문자열, 한글 설명, 이모지를 표로 나누고, 각각 “보고서 설명문”과 “재현 입력”으로 허용할지 근거를 적습니다.

6-4. 파일 시스템: 경로 검증과 열린 파일 검사는 다릅니다

isSafeRelativeSourcePath()와 isSafeRelativePath()는 절대 경로, .., 역슬래시, 콜론, 일부 Windows 예약 이름 등을 거부합니다. 그러나 문자열이 안전해 보여도 실제 경로의 구성요소가 심볼릭 링크일 수 있습니다. 이 때문에 문서는 파일 기술자에 기반한 증거 보존 절차를 별도로 요구합니다.

실습 아이디어: 가상 경로 toy/auth.js, ../auth.js, C:/auth.js, toy/con.txt를 검사 함수의 조건과 한 줄씩 대조합니다. 파일을 만들 필요 없이 문자열과 조건만으로 연습할 수 있습니다.

6-5. 에이전트 설계: 외부 상태와 제한된 문맥

장부는 모델의 대화 기억 밖에 조사 상태를 둡니다. 검증자에게는 후보와 관련 경계·증거만 전달하며, 다른 검증자의 결론은 전달하지 않도록 지침이 정합니다. attempts는 재조사의 과거 소유자와 증거를 현재 결과에 섞지 않고 보존합니다.

에이전트의 품질은 모델의 답뿐 아니라, 어떤 상태와 증거를 다음 단계에 넘기는지에도 달려 있습니다. 이 관점은 보안 감사 외에도 코드 리뷰, 데이터 정제, 문서 검토에 적용할 수 있습니다.

실습 아이디어: 조정자·발견자·검증자 세 역할의 입력과 출력만 표로 설계해 봅니다. 어떤 파일을 누가 쓸 수 있는지까지 적으면 프롬프트가 작업 프로토콜로 바뀌기 시작합니다.

6-6. 보안 방법론: 권한 부여와 행동 의도의 연결

AI-AND-LLM.md는 모델이 도구를 호출할 권한이 있는지와, 사용자가 그 정확한 작업을 의도했는지를 별개의 통제로 다룹니다. 사용자가 파일 정리를 요청했는데 검색된 문서가 추가 작업을 유도했다면, 일반적인 도구 권한만으로 그 추가 작업의 의도를 입증할 수 없습니다.

같은 문서는 “프롬프트 주입 문장이 보인다”만으로 취약점을 확정하지 말라고 요구합니다. 낮은 신뢰의 입력이 실제 권한 사용·데이터 노출·원치 않은 상태 변경으로 이어지는 코드 경로가 필요합니다.

실습 아이디어: 장난감 문서 검색 기능을 가정하고, 검색 문서 작성자·질문한 사용자·도구 실행 계정·변경될 자원을 네 칸에 나눠 적어 보세요.

6-7. 테스트 설계: 정상 입력보다 경계 조건을 읽어보기

테스트는 형식 오류뿐 아니라 FIFO, 심볼릭 링크, 잘못된 UTF-8, 깊은 중첩, 오류 메시지의 제어문자, 재배정 시 증거 혼합을 다룹니다. 장부 테스트의 archives prior evidence when a critic assigns a fresh owner 사례는 상태 저장 설계를 테스트로 설명하는 예입니다.

실습 아이디어: 테스트 이름 하나를 골라 “어떤 입력을 넣고, 무엇이 나오면 실패인가?”를 한국어로 다시 써 보세요. FIFO·심볼릭 링크 관련 테스트에는 OS와 안전한 파일 열기 플래그의 지원 여부에 따른 건너뛰기 조건이 있습니다.

7하드웨어 / 시스템 요구사항

README의 요구사항은 기능 중심입니다. “최소 16GB RAM” 같은 수치는 없습니다. 모델을 원격으로 쓰는지 로컬에서 추론하는지에 따라 하드웨어가 달라지며, 이 레포는 추론 서버나 모델 가중치를 제공하지 않습니다. 현재 학습 과제는 소스 읽기이므로 별도 GPU가 필요한 작업을 포함하지 않습니다.

7-1. 플랫폼 호환성은 실패 시 동작까지 읽어야 합니다

두 검증기의 readFileWithinLimit()는 O_NOFOLLOW와 O_NONBLOCK이 정수이면서 0이 아닌지 먼저 확인합니다. 이 보호 기능이 없으면 안전하지 않은 대체 경로를 사용하지 않고 입력을 거부합니다. 따라서 “Node.js가 설치된다”와 “이 CLI가 안전하게 파일을 읽는다”는 같은 조건이 아닙니다.

테스트에는 플랫폼에 따라 일부 사례를 건너뛰는 조건도 있습니다. Windows 경로를 거부하는 문자열 규칙이 있다고 해서 Windows에서 전체 감사가 검증됐다고 결론 내릴 수는 없습니다. 실제 지원 범위는 OS의 파일 API와 개별 테스트 조건을 함께 살펴야 합니다.

7-2. 대상 코드를 실행하려면 갖춰야 하는 통제

• 외부 네트워크를 차단하고, 필요한 로컬 통신도 격리된 루프백 안으로 제한합니다.
• 빈 환경에서 허용된 안전한 변수만 제공하며, 실제 자격 증명과 사용자 데이터를 넣지 않습니다.
• 대상 소스와 도구는 읽기 전용으로 노출하고, 할당된 scratch/만 쓰게 합니다.
• CPU·메모리·프로세스·파일 크기·디스크·실행 시간을 명시적으로 제한합니다.
• 증거 파일은 실행 종료 후 신뢰되는 조정자 코드가 제한된 절차로 보존합니다.

이는 SKILL.md가 요구하는 조건입니다. 단순히 폴더 이름을 sandbox로 짓거나 프롬프트에 “안전하게 실행”이라고 적는 것으로 충족되지 않습니다. 필수 통제를 제공하지 못하면 대상 코드를 실행하지 않고, 구체적인 차단 요인을 기록하도록 지침이 정합니다.

7-3. 실제로 커지는 자원은 에이전트 호출 예산입니다

최초 조사에는 기본 4개 역할이 있습니다. 한 번의 조사 묶음에서 발견자 수를 H, Phase 3에 넘길 후보 수를 C로 놓고, 모든 후보가 confirmed 또는 needs_validation으로 남는다고 가정하면, quick은 대략 4 + H + 1 + C, standard는 대략 4 + H + 2 + 2C번의 호출을 계획할 수 있습니다.

이 식은 최초 조사 4개, 조사 후 비평 1개, 표준 모드의 별도 최종 비평 1개, 후보별 검증 횟수를 더한 한 차례 실행의 학습용 계산입니다. 추가 조사·재배정·기록 교체 검증이 발생하면 늘어나며, 토큰 수나 금액을 예측한 공식은 아닙니다.

감사 예산을 줄일 때는 검증 기준을 낮추기보다, 조사 범위와 남은 공백을 명시해야 합니다. 소스의 예산 규칙도 비평·검증 호출을 먼저 예약하고, 그 안에서 발견자 작업을 배정하도록 요구합니다.

8직접 해볼 수 있는 실습 과제

# 저장소 루트에서 파일 읽기·집계만 하는 명령
rg --files --hidden -g '!**/.git/**'
wc -l skills/security-audit/validate-findings.cjs \
      skills/security-audit/validate-coverage-ledger.cjs \
      skills/security-audit/validate-findings.test.cjs \
      skills/security-audit/validate-coverage-ledger.test.cjs
rg -n '^function ' skills/security-audit/validate-findings.cjs

[
  {
    "verdict": "needs_validation",
    "fingerprint": "toy-export-owner-scope",
    "title": "가상 내보내기 경로의 소유권 범위 확인",
    "description": "가상 함수의 호출자 권한 전달을 끝까지 확인하지 못했다.",
    "claimed_root_cause": "중간 호출에서 소유자 범위가 빠질 가능성이 있다.",
    "trace": [
      {
        "kind": "entrypoint",
        "file": "toy/export.js",
        "line": 12,
        "scope": "exportDocument",
        "description": "문서 식별자를 받는다고 가정한 예제 진입점이다."
      }
    ],
    "evidence": [
      {
        "file": "toy/export.js",
        "line": 12,
        "description": "학습용 가정이며 실제 취약점의 증거가 아니다."
      }
    ],
    "blockers": ["예제에서 후속 권한 검사 함수의 구현을 제공하지 않았다."],
    "validation_plan": {
      "local": "후속 함수 소스를 확보해 두 가상 소유자의 접근 조건을 대조한다."
    }
  }
]

좋은 실습의 완료 기준은 명령 실행 여부보다, 어떤 규칙이 어떤 실패를 막는지 설명할 수 있는가입니다. 위 다섯 과제는 저장소 파일을 수정하지 않고 진행할 수 있습니다.

9관련 기술 심화 학습 로드맵

주차는 진도 구분을 위한 제안입니다. 기간보다 각 주의 산출물을 설명할 수 있는지에 초점을 맞추세요. 1~4주는 JavaScript와 데이터 모델링, 5~6주는 보안 경계와 에이전트 절차를 연결합니다.

9-1. 관심 분야에 따라 다음 경로를 고릅니다

• 웹 개발: WEB-PROTOCOL-AND-AUTH.md에서 세션·계정 복구를 읽고, CLIENT-SIDE.md로 화면 출력과 메시지 출처 검사를 연결합니다.
• AI 도구 개발: AI-AND-LLM.md에서 도구 인자·권한·행동 의도의 연결을 읽고, DATA-ISOLATION-AND-LIFECYCLE.md로 검색과 기억의 소유권을 확장합니다.
• 백엔드·인프라: PROTOCOLS-RPC-AND-MESSAGING.md의 재전송·요청 경계와 CLOUD-AND-DEPLOYMENT.md의 실행 신원을 함께 읽습니다.
• 시스템 개발: MEMORY-SAFETY-AND-BINARY.md의 수명·단위·FFI 계약을 읽고, DESKTOP-MOBILE-AND-LOCAL-IPC.md에서 프로세스 간 권한을 따라갑니다.

기술 이름을 많이 외우기보다, 한 입력이 어느 권한으로 어느 자원에 도달하는지 끝까지 따라가 보세요. 이 질문을 유지하면 새로운 프레임워크나 프로토콜을 만나도 같은 학습 틀을 사용할 수 있습니다.

10핵심 키워드 사전

장부의 candidate와 발견 기록의 confirmed는 서로 다른 축입니다. 전자는 조사 단위가 후보 지문과 연결되어 있음을, 후자는 후보의 최종 판정을 나타냅니다. 두 값을 하나의 상태 목록으로 섞지 않는 것이 데이터 모델을 이해하는 첫걸음입니다.

11참고 링크

11-1. 공식 저장소와 분석에 사용한 소스

• 공식 GitHub 저장소 — 현재 프로젝트 상태를 확인하는 출발점입니다.
• 분석 기준 커밋의 전체 파일 — 이 글의 파일 경로와 코드는 이 시점에 고정했습니다.
• README — 설치·사용·요구사항과 저자의 성능 주장을 확인합니다.
• SKILL.md — 모드·격리·예산·전체 절차를 읽습니다.
• RECONNAISSANCE.md — 조사 질문과 범위 장부 설계의 근거입니다.
• HUNTING.md — 발견자 결과와 범위 비평 반복의 계약입니다.
• report-schema.json — 세 판정의 필드 계약을 직접 대조합니다.
• 발견 기록 검증기와 범위 장부 검증기 — 기계적으로 강제되는 규칙의 근거입니다.
• 발견 기록 테스트와 범위 장부 테스트 — 정상·비정상 입력의 사례를 읽습니다.

11-2. 관련 기술의 공식 학습 자료

• Cloudflare의 배경 설명 — 2026-06-18 공개 글. 초기 스킬과 확장된 사내 시스템을 구분해 읽습니다.
• Node.js 파일 시스템 API — 파일 기술자, 파일 상태 검사, 열기 플래그를 학습합니다.
• Node.js 테스트 실행기 문서 — node:test의 테스트·건너뛰기·하위 테스트 개념을 확인합니다.
• JSON Schema의 조건 조합 — oneOf·anyOf·allOf의 차이를 학습합니다.
• RFC 3986 — URI의 예약되지 않은 문자와 퍼센트 인코딩 배경을 확인합니다.
• CodeQL 공식 개요와 Semgrep 공식 문서 — 감사 절차와 정적 분석 도구의 역할을 비교합니다.
• TrendShift — 2026-10-23 Daily #9 선정의 출처입니다.

현재 상태 (2026-10-23 확인)