KESE-KIT이란 2026, KISA 보안 가이드를 Claude Code 플러그인으로 묶는 법

가끔 GitHub 저장소를 보다 보면 기능보다 구조가 먼저 눈에 들어오는 프로젝트가 있다. KESE-KIT이 딱 그랬다.

겉으로 보면 KISA 보안 가이드를 Claude Code 플러그인으로 묶은 프로젝트다. 근데 조금만 더 보면 더 재밌다.

CII
AI 보안
로봇 보안

같이 서로 성격이 다른 기준 문서를 한 저장소에 넣어두고도, 스킬 자체는 과하게 비대해지지 않게 쪼개놨다.

특히 2026년 3월 30일 v2.0.0에서 적용한 progressive disclosure 리팩토링은 Claude Code 스킬이 커질 때 어떻게 안 터지게 관리하는지 보여주는 꽤 좋은 예시다.

한 줄 결론부터 말하면 이렇다.

KESE-KIT의 진짜 재미는 “보안 평가를 자동화했다”보다, “거대한 공식 가이드를 Claude Code가 먹을 수 있는 구조로 어떻게 잘라 넣었는가”에 있다.

Quick Answer

KESE-KIT은 KISA 2026 보안 가이드 문서를 바탕으로 만든 Claude Code 플러그인이다.
README 기준으로 CII, AI 보안, 로봇 보안 평가를 한 프로젝트 안에서 다룬다.
명령은 /start, /check, /fix, /guide 네 갈래로 역할을 나눴다.
v2.0.0부터는 SKILL.md를 두꺼운 설명서가 아니라 얇은 라우터로 두고, 세부 지식은 references/로 분리했다.
이 구조가 중요한 이유는 보안 지식이 커져도 스킬 진입점은 얇게 유지할 수 있기 때문이다.

이 글이 필요한 사람

Claude Code 스킬이나 플러그인을 직접 설계하는 사람
SKILL.md에 다 때려 넣다가 점점 관리 지옥을 느끼는 사람
보안/컴플라이언스 문서를 AI 워크플로우에 붙이는 방법이 궁금한 사람
KESE-KIT을 설치할지 말지보다 왜 이 구조가 흥미로운지 알고 싶은 사람
progressive disclosure를 말로만 듣고, 실제 저장소 예시를 보고 싶은 사람

지금 결론

질문	KESE-KIT에서 보이는 답
공식 문서가 너무 크면 SKILL.md에 다 넣어야 하나	아니다, 라우터만 남기고 references로 분리
기능이 늘면 스킬 개수도 계속 늘려야 하나	꼭 그렇진 않다, 역할 고정 후 자료만 확장 가능
보안 플러그인의 가치는 실행 결과만 있나	아니다, 구조 자체도 배울 점이 크다
바로 설치해서 쓰면 되나	실무 도입 전엔 범위와 검증 방식부터 봐야 한다
내 프로젝트에 가져갈 핵심 패턴은 뭔가	얇은 진입점 + 깊은 references + 명령 역할 분리

핵심은 이거다. KESE-KIT은 “보안 플러그인”이면서 동시에 “큰 스킬을 어떻게 안 무너지게 설계할까”에 대한 좋은 구조 샘플이다.

내가 직접 확인한 것과 아직 안 한 것

이 글은 설치 체험기보다 구조 분석 글이다. 그래서 어디까지 직접 봤는지 먼저 선을 긋고 갈게.

내가 직접 확인한 것

GitHub 저장소 README
프로젝트 폴더 구조
v2.0.0 / v2.1.0 변경 이력
SKILL.md 라우터 + references 분리 설명
Anthropic 공식 Skills 문서의 progressive disclosure 원칙

아직 안 한 것

실제로 플러그인을 설치해서 /start, /check, /fix, /guide를 실행해보진 않았다
README에 적힌 모든 항목 수가 명령 결과와 1:1로 맞는지도 실행 검증은 하지 않았다

즉 이 글은 효과 검증 후기가 아니라 구조 해부 + 설계 포인트 정리로 읽는 게 맞다.

KESE-KIT이 다루는 범위

README 기준으로 이 저장소는 공식 문서 5종을 바탕으로 구성됐다.

주요정보통신기반시설 기술적 취약점 분석·평가방법 상세가이드
주요정보통신기반시설 관리·물리적 취약점 분석·평가 방법 안내서
인공지능(AI) 보안 안내서
로봇 보안모델(고도화)
로봇 보안취약점 점검 체크리스트 해설서

이걸 Claude Code 플러그인 관점에서 보면 꽤 공격적인 범위다.

CII 기술적 560+ 항목
관리적 127항목
물리적 18항목
AI 보안 54+ 항목
로봇 보안 약 103항목

이 정도면 그냥 “문서 몇 개 넣어둔 스킬”이 아니라 사실상 문서 기반 평가 프레임워크에 가깝다.

왜 `/start`, `/check`, `/fix`, `/guide`로 쪼갰을까

이 부분이 되게 실무적이다.

README의 명령 구조를 보면 기능을 문서 종류가 아니라 사용자 의도로 나눴다.

/start: 전체 평가 시작
/check: 배포 전 체크리스트
/fix: 하드닝 스크립트 / 보안 수정 생성
/guide: 시큐어코딩 프롬프트 / 개발 가이드

이게 좋은 이유는 사용자가 문서 번호보다 지금 뭘 하고 싶은지로 접근하기 때문이다.

예를 들어 사람은 보통 이렇게 묻는다.

“전체 진단 돌려줘”
“배포 전에 뭐 빠졌는지 봐줘”
“고칠 스크립트 초안 줘”
“개발팀용 가이드 뽑아줘”

즉 문서 중심 분류보다 워크플로우 중심 분류가 더 AI 도구답다.

이 저장소에서 제일 배울 만한 포인트: progressive disclosure

여기가 핵심이다.

Anthropic 공식 Skills 문서는 progressive disclosure를 SKILL.md는 개요만 두고, 자세한 자료는 필요할 때만 읽게 하는 방식으로 설명한다.

KESE-KIT v2.0.0은 이걸 꽤 정직하게 적용했다.

README에 적힌 구조상 변화는 이렇다.

항목	v1.0	v2.0
SKILL.md	지식을 인라인으로 많이 포함	라우터 위주 얇은 구조
지식 저장 방식	SKILL.md 하드코딩	`references/` 분리
확장 방식	새 가이드라인 추가 시 스킬 자체가 비대해짐	스킬 4개는 유지하고 reference만 추가
문서 범위	초기 CII 중심	CII + AI 보안 + 로봇 보안 확장

README 설명대로라면

이전엔 SKILL.md가 270~465줄까지 커졌고
v2.0에선 라우터만 약 80줄 수준으로 얇아졌다
세부 지식은 references/ 18개 파일로 분리됐다

이게 왜 좋냐면, Claude Code 스킬은 결국 어떻게 처음 진입하고, 언제 더 깊게 읽게 하느냐가 성능과 유지보수 둘 다에 영향을 주기 때문이다.

구조를 보면 왜 덜 무너지는지 바로 보인다

README의 프로젝트 구조를 보면 대충 이런 모양이다.

KESE-KIT/
├── skills/        # 영문 스킬
├── skills-ko/     # 한글 스킬
├── 문서/          # 원본 PDF 5개
├── authorkit/     # 변환 산출물
├── docs/          # 다국어 README
└── .claude-plugin/

그리고 각 스킬 안은 다시 이렇게 나뉜다.

start/
├── SKILL.md
└── references/
    ├── cii/
    ├── ai-security/
    └── robot-security/

이 구조가 좋은 이유는 세 가지다.

1. 진입점이 얇다

SKILL.md가 라우터면 Claude가 처음부터 모든 세부 문서를 다 읽지 않아도 된다.

2. 도메인별 분리가 명확하다

cii, ai-security, robot-security로 분리돼 있으니 나중에 한 축만 업데이트해도 구조가 덜 꼬인다.

3. 다국어 확장이 가능하다

skills와 skills-ko가 나뉘어 있으니 영문/국문 워크플로우를 분리해 관리하기 좋다.

즉 이건 단순한 폴더 정리가 아니라 컨텍스트 비용과 유지보수 비용을 같이 줄이려는 구조다.

내 워크플로우 기준으로 보면 왜 흥미롭냐

이 대목이 TECHTAEK 포인트다.

나는 이런 저장소를 볼 때 이걸 당장 설치할까?보다 먼저 내 스킬 설계에 뭘 가져올 수 있나?를 본다.

KESE-KIT에서 바로 가져올 만한 건 이거다.

1. SKILL.md를 설명서가 아니라 라우터로 본다

많은 스킬이 커질수록 SKILL.md에 다 밀어 넣다가 뚱뚱해진다. KESE-KIT은 반대로 입구는 짧게, 깊이는 references에서로 갔다.

2. 기능은 4개로 고정하고 지식만 확장한다

기능 축을 자주 늘리면 사용자는 매번 어디로 들어가야 하는지 헷갈린다. KESE-KIT은 명령 역할을 고정하고, 뒤의 기준 문서만 늘리는 쪽이다.

3. 원본 문서와 변환 산출물을 같이 둔다

PDF 원본과 변환 결과를 같이 잡아두면 AI가 읽는 버전과 사람이 확인할 원본을 분리할 수 있다.

이건 나처럼 볼트에서 스킬/에이전트 구조 만지는 사람한텐 꽤 유용한 패턴이다.

그렇다고 바로 “실무 도입 완료”로 보면 안 되는 이유

여기서 한 번 브레이크를 밟아야 한다.

KESE-KIT이 재밌는 구조라는 것과, 지금 내 조직에 바로 넣어도 된다는 건 완전히 다른 얘기다.

특히 보안 평가 플러그인은 아래를 따로 봐야 한다.

실제 명령 결과 품질
최신 문서 반영 주기
오탐/누락 가능성
내부 보안 정책과의 충돌 여부

즉 이 프로젝트는 지금 단계에서 완성형 보안 자동화 솔루션이라기보다, 문서 기반 보안 평가를 Claude Code 워크플로우에 어떻게 얹을지 보여주는 매우 흥미로운 설계 예시로 보는 게 더 정확하다.

1분 체크리스트

STEP 1. 이 프로젝트를 “보안 도구”로 볼지 “구조 샘플”로 볼지 먼저 정한다

둘 다 볼 수 있지만, 처음 읽을 땐 구조 샘플로 보면 얻는 게 더 많다.

STEP 2. 명령 분리가 사용자 의도 기준인지 본다

start/check/fix/guide처럼 사람이 실제로 던지는 작업 단위로 나뉘어 있는지 보는 게 중요하다.

STEP 3. SKILL.md가 라우터 역할을 하는지 본다

만약 SKILL.md 하나에 모든 지식이 다 박혀 있다면 그 순간부터 유지보수 난도가 확 올라간다.

STEP 4. references가 도메인별로 잘 분리돼 있는지 본다

cii, ai-security, robot-security처럼 확장 단위가 깔끔해야 나중에 덜 터진다.

STEP 5. 원본 문서와 AI용 변환 산출물이 분리돼 있는지 본다

이 구분이 없으면 사람 검증과 AI 소비가 한 파일에 엉켜버린다.

실수 TOP 5

1. KESE-KIT을 그냥 “보안 체크리스트 저장소” 정도로 본다

실제로 더 흥미로운 건 지식 구조화 방식이다.

2. 스킬이 커질수록 명령도 계속 늘려야 한다고 생각한다

KESE-KIT은 반대로 기능 축은 고정하고 뒤의 references를 확장하는 쪽이다.

3. SKILL.md에 다 넣는 게 친절하다고 생각한다

처음엔 친절해 보여도, 나중엔 모델도 사람도 둘 다 지친다.

4. 공식 문서를 AI가 읽게 만들면 바로 실무 투입 가능하다고 믿는다

문서 기반 자동화와 실제 보안 평가 품질은 또 다른 레벨의 문제다.

5. progressive disclosure를 “파일 쪼개기” 정도로만 본다

진짜 포인트는 쪼개기가 아니라 언제 무엇을 읽게 할지 통제하는 설계다.

FAQ

Q. KESE-KIT은 정확히 뭐야?

A. KISA 2026 보안 가이드 문서를 바탕으로 CII, AI 보안, 로봇 보안 평가를 Claude Code 플러그인 형태로 재구성한 프로젝트다.

Q. 이 프로젝트의 핵심은 보안 항목 수야, 구조야?

A. 둘 다지만, TECHTAEK 관점에선 구조가 더 흥미롭다. 특히 큰 지식 덩어리를 SKILL.md + references로 나누는 방식이 배울 점이 많다.

Q. progressive disclosure가 왜 그렇게 중요해?

A. 스킬이 커질수록 처음부터 모든 문서를 다 읽는 방식은 비효율적이기 때문이다. 입구를 얇게 두고 필요할 때만 깊게 읽게 해야 유지보수와 컨텍스트 효율이 둘 다 좋아진다.

Q. 바로 설치해서 회사 보안 점검에 써도 돼?

A. 그건 별도 문제다. 이 글 기준으로 나는 구조와 문서를 확인했지, 실제 평가 품질을 검증하진 않았다. 실무 도입 전엔 반드시 별도 검증이 필요하다.

Q. 내가 지금 만드는 Claude Code 스킬에도 이 패턴을 가져올 수 있어?

A. 충분히 가능하다. 특히 SKILL.md가 점점 뚱뚱해지는 중이면 지금이 갈아탈 타이밍이다.

참고 자료

GitHub, cdppcorp/KESE-KIT README
Claude Docs, Agent Skills
Claude Docs, Skill authoring best practices

KESE-KIT이란 2026 — KISA 보안 가이드를 Claude Code 플러그인으로 묶는 법과 progressive disclosure 설계

Quick Answer

이 글이 필요한 사람

지금 결론

내가 직접 확인한 것과 아직 안 한 것

내가 직접 확인한 것

아직 안 한 것

KESE-KIT이 다루는 범위

왜 `/start`, `/check`, `/fix`, `/guide`로 쪼갰을까

이 저장소에서 제일 배울 만한 포인트: progressive disclosure

구조를 보면 왜 덜 무너지는지 바로 보인다

1. 진입점이 얇다

2. 도메인별 분리가 명확하다

3. 다국어 확장이 가능하다

내 워크플로우 기준으로 보면 왜 흥미롭냐

1. SKILL.md를 설명서가 아니라 라우터로 본다

2. 기능은 4개로 고정하고 지식만 확장한다

3. 원본 문서와 변환 산출물을 같이 둔다

그렇다고 바로 “실무 도입 완료”로 보면 안 되는 이유

1분 체크리스트

STEP 1. 이 프로젝트를 “보안 도구”로 볼지 “구조 샘플”로 볼지 먼저 정한다

STEP 2. 명령 분리가 사용자 의도 기준인지 본다

STEP 3. SKILL.md가 라우터 역할을 하는지 본다

STEP 4. references가 도메인별로 잘 분리돼 있는지 본다

STEP 5. 원본 문서와 AI용 변환 산출물이 분리돼 있는지 본다

실수 TOP 5

1. KESE-KIT을 그냥 “보안 체크리스트 저장소” 정도로 본다

2. 스킬이 커질수록 명령도 계속 늘려야 한다고 생각한다

3. SKILL.md에 다 넣는 게 친절하다고 생각한다

4. 공식 문서를 AI가 읽게 만들면 바로 실무 투입 가능하다고 믿는다

5. progressive disclosure를 “파일 쪼개기” 정도로만 본다

FAQ

Q. KESE-KIT은 정확히 뭐야?

Q. 이 프로젝트의 핵심은 보안 항목 수야, 구조야?

Q. progressive disclosure가 왜 그렇게 중요해?

Q. 바로 설치해서 회사 보안 점검에 써도 돼?

Q. 내가 지금 만드는 Claude Code 스킬에도 이 패턴을 가져올 수 있어?

참고 자료

다음에 읽을 글

Quick Answer

이 글이 필요한 사람

지금 결론

내가 직접 확인한 것과 아직 안 한 것

내가 직접 확인한 것

아직 안 한 것

KESE-KIT이 다루는 범위

왜 /start, /check, /fix, /guide로 쪼갰을까

이 저장소에서 제일 배울 만한 포인트: progressive disclosure

구조를 보면 왜 덜 무너지는지 바로 보인다

1. 진입점이 얇다

2. 도메인별 분리가 명확하다

3. 다국어 확장이 가능하다

내 워크플로우 기준으로 보면 왜 흥미롭냐

1. SKILL.md를 설명서가 아니라 라우터로 본다

2. 기능은 4개로 고정하고 지식만 확장한다

3. 원본 문서와 변환 산출물을 같이 둔다

그렇다고 바로 “실무 도입 완료”로 보면 안 되는 이유

1분 체크리스트

STEP 1. 이 프로젝트를 “보안 도구”로 볼지 “구조 샘플”로 볼지 먼저 정한다

STEP 2. 명령 분리가 사용자 의도 기준인지 본다

STEP 3. SKILL.md가 라우터 역할을 하는지 본다

STEP 4. references가 도메인별로 잘 분리돼 있는지 본다

STEP 5. 원본 문서와 AI용 변환 산출물이 분리돼 있는지 본다

실수 TOP 5

1. KESE-KIT을 그냥 “보안 체크리스트 저장소” 정도로 본다

2. 스킬이 커질수록 명령도 계속 늘려야 한다고 생각한다

3. SKILL.md에 다 넣는 게 친절하다고 생각한다

4. 공식 문서를 AI가 읽게 만들면 바로 실무 투입 가능하다고 믿는다

5. progressive disclosure를 “파일 쪼개기” 정도로만 본다

FAQ

Q. KESE-KIT은 정확히 뭐야?

Q. 이 프로젝트의 핵심은 보안 항목 수야, 구조야?

Q. progressive disclosure가 왜 그렇게 중요해?

Q. 바로 설치해서 회사 보안 점검에 써도 돼?

Q. 내가 지금 만드는 Claude Code 스킬에도 이 패턴을 가져올 수 있어?

참고 자료

다음에 읽을 글

왜 `/start`, `/check`, `/fix`, `/guide`로 쪼갰을까