정보보안 담당자를 위한 Claude Code 도입 판단 가이드
20장 · 약 7시간 · 2026.10.31
EBOOK · 2026년 11월 4일
중소기업 보안 가이드 2026: 어디까지 하면 충분한가
김재우 지음 · 22장 · 읽는 시간 약 7시간
전담 팀이 없는 회사에서 처음으로 보안을 맡게 된 사람을 위한 책입니다. 임원이 "우리 회사는 괜찮아?"라고 물어도, "어디까지 하면 충분한가"라는 기준이 없으면 답할 수 없습니다. 과학기술정보통신부·KISA(한국인터넷진흥원)·개인정보보호위원회의 가이드라인과 ISMS·ISMS-P 인증기준, AWS 보안 성숙도 모델을 바탕으로 자사의 현재 위치를 Lv0~Lv4로 측정하고 자사에 맞는 목표 레벨을 정한 뒤 다음 한 수와 최종 모습을 그립니다. 사내 IT, AWS, GitHub, AI 시대의 위험, 야간·휴일 모니터링, 인시던트 대응, 첫 90일 로드맵까지 다룹니다. 3분이면 할 수 있는 간이 체크 포함(2026년 11월 4일 기준).
웹 뷰어에서만 읽을 수 있는 책입니다. 본문 복사·인쇄·저장은 막혀 있어요.
목차
1. 들어가며 ― "우리 회사는 괜찮아?"에 답할 수 있습니까
예를 들어 이런 장면을 상상해 보세요.
절 7개 보기
- 어느 날의 회의에서
- 대상 독자와 상정하는 회사
- 이 책의 목표
- 3분이면 할 수 있는 간이 체크
- 레벨별 추천 읽는 순서
- 이 책의 구성
- 주의
2. 왜 지금인가 ― 2025~2026년에 일어난 일
"보안은 중요하다"는 말은 줄곧 있어 왔습니다. 그런데도 많은 회사에서 보안은 뒷전으로 밀려 왔습니다. 그러다 2025년부터 2026년에 걸쳐 상황이 확실히 달라졌습니다.
절 8개 보기
- 3가지 변화
- ① 랜섬웨어가 사업을 멈춘다
- ② AI가 공격과 방어의 속도를 바꿨다
- ③ 제도가 움직였다
- 2026년 10월의 사건들
- 3가지 흐름에 공통된 교훈
- 첫 보안 담당자에게 "지금"이란
- 참고: 연표
3. 무엇을 기준으로 할 것인가 ― 국내 법령, ISMS·ISMS-P, 이 책의 레벨
이 장에서는 "어디까지 하면 충분한가"를 판단할 기준을 정리합니다. 전반부에서는 국내 법령과 KISA의 가이드·지원사업, ISMS·ISMS-P 인증, 정보보호 공시와 AI 관련 규범을, 후반부에서는 성숙도 모델을 다루고, 마지막으로 이 책에서 쓰는 Lv0~Lv4 레벨을 정의합니다.
절 12개 보기
- 경영진의 책임 ― 개정 정보통신망법과 개인정보보호법
- 중소기업이 먼저 볼 곳 ― KISA 보호나라와 지역정보보호센터
- ISMS·ISMS-P 인증 ― 간편·표준·강화
- 보충: ISO/IEC 27001과의 관계
- 정보보호 공시와 정보보호수준 평가
- AI 기본법과 생성형 AI 가이드
- 국내 기준의 관계
- 대표적인 성숙도 모델
- 이 책의 레벨 정의: Lv0~Lv4
- 자사의 목표 레벨 정하기
- 레벨을 올릴 때의 원칙
- 각 레벨의 "완료 정의"
4. 현재 위치 체크시트
이 장은 자사의 현재 위치를 측정하는 체크시트입니다. 분기에 한 번 이 장을 복사해 채우고, 지난번과의 차이를 경영진에 보고하는 용도로 만들었습니다.
절 10개 보기
- 사용 방법
- 기입란
- A. 조직·거버넌스
- B. ID와 사내 IT(7·8장)
- C. AWS 기반·인프라(9장)
- D. 탐지와 취약점 관리(5·9~11·15장)
- E. 개발·코드(12·13장)
- F. AI 이용·개발(14장)
- G. 인시던트 대응과 복구(16·17장)
- 결과 해석 예시
5. 체제와 규칙 ― 누가 책임지고, 누가 고치는가
제2부에서는 도구 이야기로 들어가기 전에, 그것을 돌릴 체제와 전체 지도를 만듭니다. 도구를 아무리 도입해도 누가 책임지고, 누가 들여다보고, 누가 고칠지가 정해져 있지 않으면 보안은 좋아지지 않습니다. 현재 위치 체크시트(4장)에서 Lv1·Lv2의 맨 앞에 놓인 것도 책임자 임명과 투입 시간 확보입니다. 이 장에서는…
절 9개 보기
- 체제: 전담 팀 없이 시작하는 형태
- 규칙(규정)
- Lv2를 위한 문서와 기록(ISMS-P 기준)
- 위험 등록부
- 취약점 관리 SLA
- 취약점 정보를 모으고 영향을 확인한다
- 위탁업체·SaaS 관리
- 교육
- 경영진 보고
6. 도구의 역할 분담 맵 ― 무엇을, 어떤 순서로 도입하고, 어떻게 돌릴 것인가
이어지는 제3부에서는 사내 IT, 제4부에서는 AWS·코드·AI를 지키는 방법을 다룹니다. 그 전에 이 장에서 도구의 전체 지도를 그려 둡니다.
절 8개 보기
- 도구가 효과를 내지 못하는 전형적인 패턴
- 11가지 역할과 이 책에서의 조합
- 아직 도입하지 않았을 때의 순서
- 흐름으로 보기
- 중복을 정리한다
- 빈틈을 확인한다
- 운영에서 정할 것
- 사용 중인 도구를 "전수 점검"한다
7. 직원 ID 지키기 ― IdP·MFA·입사와 퇴사·위탁업체 계정
제3부에서는 사내 IT를 지키는 방법을 두 장에 걸쳐 다룹니다. 직원의 ID, PC, 메일, VPN과 네트워크 장비, 업무에 쓰는 SaaS(Microsoft 365 / Google Workspace, 채팅, 스토리지 등)를 말합니다.
절 8개 보기
- ID를 한곳에 모으기
- 인증 강화하기
- 관리자 계정
- 입사·부서 이동·퇴사
- 위탁업체·외부 인력의 계정
- 탈취 알아차리기
- 레벨별 진행 방법
- 흔한 함정
8. 단말·메일·네트워크·SaaS 지키기 ― PC·EDR·VPN·업무용 SaaS
7장의 ID에 이어, 이 장에서는 사내 IT의 나머지 입구를 다룹니다. 직원의 PC와 스마트폰, 메일, VPN과 네트워크 장비, 업무에 쓰는 SaaS입니다. ISMS-P 인증기준으로는 2.10.6 업무용 단말기기 보안, 2.10.8 패치관리, 2.10.9 악성코드 통제, 2.6.1 네트워크 접근, 2.6.6 원격접근…
절 9개 보기
- 사내 IT의 입구
- 직원 PC
- 스마트폰
- 메일
- VPN·네트워크 장비
- 업무용 SaaS
- PC와 SaaS의 데이터를 복구할 수 있게 하기
- 레벨별 진행 방법
- 흔한 함정
9. AWS 기반 만들기 ― Organizations·Security Hub·GuardDuty
제4부에서는 개발과 클라우드를 지키는 방법을 다룹니다. 첫 번째인 이 장에서는 AWS 보안 성숙도 모델의 순서에 따라 AWS상의 보안을 Lv1 → Lv2 → Lv3로 끌어올리는 구체적인 절차를 정리합니다. ISMS-P 인증기준으로는 2.10.2 클라우드 보안을 중심으로 2.5.5 특수 계정 및 권한 관리, 2.9.3…
절 9개 보기
- 전체 그림
- Lv1: Quick Wins(먼저 2주 안에 할 일)
- Lv2: Foundational(기반)
- Lv3: Efficient(체계화)
- Lv4: Optimized(최종 모습)
- 로그와 백업을 "삭제되지 않는 곳"에 두기
- 레벨별 진행 방법
- 흔한 함정
- AWS 이외의 클라우드로 바꿔 읽기
10. AWS 전체를 정기적으로 건강검진하기 — SATv2
과기정통부·KISA의 '2026년 상반기 사이버위협 동향'(2026년 7월 30일)에 따르면 상반기 침해사고 신고는 1,236건으로 전년 같은 기간보다 19.5% 늘었습니다. 랜섬웨어는 145건(+76.8%), 디도스는 373건(+56.7%)이었고, 유형별로는 서버 해킹이 487건으로 전체의 39.4%를 차지했습니다.…
절 5개 보기
- SATv2란
- Security Hub나 Wiz가 있는데 왜 SATv2인가
- 결과 읽는 법
- 분기별 운영
- 주의할 점
11. 클라우드 전체의 위험을 파악하고 우선순위를 매기기 — CNAPP(Wiz)
KISA는 최근 침해사고를 분석하면서 관리자·임직원 계정 탈취를 주요 초기 침투 경로로 꼽았고, VPN·방화벽 같은 경계 장비의 취약점과 백업 서버를 삭제하는 공격도 짚었습니다. 2026년 10월에는 하이브가 전자결재에 연동된 외부 업체의 문서 미리보기 솔루션을 거쳐 침입당해 9월과 10월 두 차례 정보가…
절 7개 보기
- Wiz란
- 시큐리티 그래프와 "유해한 조합"
- 주요 제품과 에이전트
- AWS 기본 기능과의 분담
- 단계적 활용법
- AI 자산 파악
- 흔한 함정
12. 코드와 개발 프로세스 지키기 — GitHub
소스 코드와 그 개발 프로세스는 AWS만큼 중요한 자산입니다. GitHub가 탈취되면 코드 도난뿐 아니라 CI/CD를 거쳐 운영 환경까지 침입당할 수 있습니다. 또한 의존 패키지를 노리는 공급망 공격에서는 개발자 PC와 CI 양쪽이 표적이 됩니다.
절 6개 보기
- 최근 사례
- GitHub의 보안 제품(2026년 시점)
- Lv1: 먼저 할 일
- Lv2: 표준화하기
- Lv3: 개발 프로세스에 녹여 넣기
- Lv4: 최종 모습
13. 앱의 취약점을 AI로 찾아서 고치기 — Takumi와 Claude Security
2장에서 본 대로 2026년 10월 국내 금융권에서 해킹에 의한 개인정보 유출이 잇따랐고, AI를 활용한 해킹 시도로 인증 절차를 우회하는 취약점이 드러났다는 보도가 나왔습니다. 금융당국이 긴급 점검한 금융회사 555곳 가운데 130곳에서 보안 패치 미적용 같은 미흡 사항이 나왔습니다. 같은 달에는 생성형 AI 해킹…
절 9개 보기
- 무엇이 바뀌었나
- Takumi byGMO
- Claude Security
- 둘을 어떻게 분담할까
- 보충: AWS Security Agent(AWS Continuum)
- 진단 전에: 공개 중인 앱과 API의 기본 방어
- 단계적 확대 방법
- 효과를 측정하는 지표
- AI 진단을 쓸 때의 주의점
14. AI를 사용하고 만들 때의 위험과 대책
13장에서는 "AI로 지킨다"는 이야기를 했습니다. 이 장은 반대로 AI를 사용하고 만들면서 생기는 위험 이야기입니다. 먼저 자사가 어떤 입장에서 AI와 관련되어 있는지 확인하고, 참고할 목록(OWASP)을 살펴본 다음, 입장별 대책과 처음 만들 AI 이용 가이드라인 템플릿을 제시합니다.
절 5개 보기
- 세 가지 입장
- 기준으로 삼을 국내 법과 가이드
- 참고할 프레임워크
- 입장별 대책
- AI 이용 가이드라인 템플릿(최소판)
15. 모니터링을 이어 가기 ― 경보를 누가, 언제 볼 것인가. 야간·휴일은 어떻게 할 것인가
제5부에서는 공격을 알아차리고, 대응하고, 계획을 다시 세우는 부분을 다룹니다. 그 첫 장인 이 장은 알아차리기까지의 이야기입니다.
절 9개 보기
- 두 종류의 알림을 구분한다
- 무엇을 모니터링할 것인가
- 모으는 곳을 하나로
- 도착하면 먼저 무엇을 확인할 것인가
- 모니터링이 멈춰 있지 않은가
- 야간·휴일은 어떻게 할 것인가
- SIEM은 필요한가
- 레벨별 진행 방법
- 흔한 함정
16. 인시던트 대응 ― 초동 대응, 대외 발표, 사업 연속성, 훈련
아무리 대비해도 인시던트는 일어납니다. 앞의 15장에서는 알림을 알아차리고 인시던트로 다룰지 정하는 데까지 다뤘습니다. 그때 피해를 키우느냐 마느냐는 처음 몇 시간 동안 누가 무엇을 할지를 평소에 정해 두었는지에 달려 있습니다. 이 장에서는 그 이후의 초동 대응 절차, 법정 신고, 대외 발표, 멈췄을 때의 대체…
절 6개 보기
- 최소한의 초동 대응 절차(Lv1~Lv2)
- 신고·통지 의무와 기한
- 무엇을, 언제, 누구에게 전할 것인가
- 멈췄을 때의 대체 수단(사업 연속성)
- 준비해 둘 플레이북(Lv3)
- 훈련
17. 침해 조사 ― 이미 침입당하지 않았는가, 침입당했다면 무엇을 조사할 것인가
이 장에서는 침해 조사를 두 가지로 나누어 다룹니다.
절 4개 보기
- 전제: 조사할 수 있을 만큼의 로그가 있는가
- 평시 침해 조사
- 인시던트 후 조사(포렌식)
- 레벨별 대비
18. 로드맵과 최종 모습
이 장에서는 지금까지의 장을 정리해 현재 위치에서 Lv4(최종 모습)까지의 로드맵을 그립니다.
절 11개 보기
- 전체 흐름
- 비용과 공수 기준
- 거래처가 ISMS 인증을 서두르라고 할 때
- 단계 0~1 전반: 첫 보안 담당자의 처음 90일
- 단계 1: 구멍 막기 ― Lv1(2개월)
- 단계 2: 기반 ― Lv2 달성(필요하면 ISMS 간편인증 취득)(6개월)
- 단계 3: 체계화 ― Lv3 / ISMS·ISMS-P 인증(9개월)
- 단계 4: 최적화 ― Lv4 / 최종 모습(12개월~)
- 최종 모습의 전체상
- 도구별 진행 방법
- 계획을 재검토할 시점
19. 부록: 기초 지식·용어와 기준의 상세
본문에서 쓰는 개념과 용어를 정리한 부록입니다. 본문을 읽다가 모르는 말이나 개념이 나오면 참조하세요.
절 7개 보기
- 보안으로 지키는 것: CIA
- 위험을 생각하는 방식
- 대책의 전체상: NIST CSF 2.0의 6가지 기능
- 알아 두어야 할 원칙
- 지금의 위협: 국내 사이버위협 동향(2026년 상반기)
- 미니 용어집
- 기준과 성숙도 모델의 상세(3장 보충)
20. 부록: ISMS·ISMS-P 핵심 항목 준비 체크표
이 부록은 ISMS·ISMS-P 인증기준의 핵심 항목을 기준으로 자사의 준비 상태를 확인하는 체크표입니다. 4장의 체크시트는 "이 책의 레벨로 지금 어디에 있는가"를 재는 잣대라 항목을 핵심만 남기고 추려 두었습니다. 인증 심사나 거래처 보안 점검에서는 그보다 세세한 것(공지, 기록, 연 1회 점검, 비밀번호 글자 수…
절 13개 보기
- 사용 방법
- 1. 관리체계(4·5·8·9장)
- 2. 조직·인적 보안(5·7·16장)
- 3. 외부자(5·7장)
- 4. 계정·인증·권한(7·8·9·12장)
- 5. 접근통제(7·8·9장)
- 6. 암호(8·9장)
- 7. 개발 보안(9·12·13장)
- 8. 운영: 변경·백업·로그(9·15·17장)
- 9. 보안시스템·클라우드·단말·패치·악성코드(5·8·9장)
- 10. 사고 예방·대응(5·10·13·15·16·17장)
- 11. 재해복구(9·16장)
- 일본 비교: SCS ★3 요구사항과 ISMS-P 대응
21. 참고 자료·최근 발표 자료
이 책을 쓸 때 참조한 1차 정보와 최근 발표 자료입니다(2026년 11월 기준). 제품 기능이나 제도의 세부 사항은 빠르게 바뀌므로 판단하기 전에 반드시 최신 정보를 확인하세요. 국내 자료를 먼저 싣고, 일본 사례 박스의 출처는 맨 뒤 "일본 비교 자료"에 모았습니다.
절 14개 보기
- 국내 자료
- 해외 동향(2장·각 장의 칼럼)
- 성숙도 모델·프레임워크
- 사내 IT(7·8장)
- 모니터링(15장)
- 취약점 정보의 정보원(5장)
- AWS 이외의 클라우드(9장)
- AWS
- GitHub
- Wiz
- Takumi byGMO(GMO Flatt Security)
- Anthropic(Claude Security / Project Glasswing)
- AI 보안
- 일본 비교 자료
부록: 한국·일본 제도 대응표
이 책은 한국 제도를 기준으로 쓰고 일본 사례는 비교 박스로 넣었습니다. 일본 사례 박스에 나오는 기관·제도가 한국에서는 무엇에 해당하는지, 그리고 국내 신고·지원 창구를 한곳에 모았습니다. 2026년 11월 4일 기준으로 확인했습니다. 국내 참고자료 목록은 21장의 "국내 자료"로 옮겼고, SCS ★3 요구사항과…
절 2개 보기
- 기관·제도 대응표
- 국내 신고·지원 창구 한눈에 보기
독자 평가
현재 상태를 확인할 수 있는 계기가 되었네요 작은 기업들에게는 소중한 자료네요.