ISMS-P 인증을 받아도 해킹 당하는 이유

By PLURA 2026-05-21

“ISMS-P 인증을 받았다는 기업이 랜섬웨어로 수십억 피해를 입었다.
DLP, NAC, DB 암호화까지 다 갖췄는데도 해킹을 당한다.
왜 이런 일이 반복될까?"😱

이유는 정보보안과 사이버보안을 같은 것으로 착각하기 때문이다.

보안 논의가 흐려지는 이유는 의외로 분명합니다.
우리는 정보보안과 사이버보안을 너무 자주 같은 말처럼 사용합니다.

정보보안은 중요합니다.
문서도 보호해야 하고, 개인정보도 관리해야 하며, 계정 권한도 정리해야 합니다.
보안 교육, 인증 대응, 백업 정책, 내부 규정도 모두 필요합니다.

하지만 정보보안이라는 큰 이름 아래 모든 보안 업무를 한꺼번에 묶어 버리면,
정작 공격자가 어떻게 침투하고 있는지를 다루는 사이버보안 논의는 흐려질 수 있습니다.

문서 암호화, DRM, DLP, NAC, DB 암호화, 계정 권한 관리, 개인정보 보호, 인증 대응, ISMS-P 대응, SAST, SBOM, 모의해킹은 모두 정보보안의 중요한 구성요소입니다.
그러나 이들은 대체로 공격자를 직접 추적하고 차단하는 영역이라기보다
IT 통제, 정책 집행, 컴플라이언스, 개발·공급망 사전 점검, 공격면 검증에 가깝습니다.

현장에서 정보보안은 주로 정책, 관리체계, 인증, 통제의 언어로 다루어집니다.
반면 사이버보안은 해킹 공격과 직접 마주하는 대응의 언어로 말합니다.

사이버보안은 공격자가 실제로 들어오는 경로를 보고,
웹 요청, 계정 로그인, 서버 이벤트, PC 행위 로그를 분석해
침해를 탐지하고 차단하고 대응하는 일입니다.

특히 미토스급 AI 공격 시대에는 이 구분이 더 중요해집니다.
AI가 취약점 후보를 빠르게 찾고 공격 경로를 조합할 수 있다면,
관리체계 중심 보안만으로는 부족합니다.
방어도 실시간 로그 분석과 침해 흐름 재구성으로 대응해야 합니다.

여기서 사이버 복원력을 먼저 내세우면 또 다른 오해가 생길 수 있습니다.
복원력은 침해 이후 버티고 복구하는 데 필요하지만, 이미 빠져나간 데이터는 복구할 수 없습니다.
지금 사이버 공격의 핵심 피해는 시스템 중단만이 아니라 데이터 유출입니다.

이 구분이 없으면
기업은 정보보안을 열심히 하고 있다고 생각하면서도
정작 사이버 공격에는 제대로 대응하지 못할 수 있습니다.

정보보안과 사이버보안의 차이

먼저 구분해야 할 세 가지

각각의 역할을 정확히 구분할 때,
우리가 보안 현장에서 겪는 많은 혼란을 줄일 수 있습니다.

정보보안은 조직이 지켜야 할 기준을 정리하는 데 강합니다.
IT 통제는 그 기준이 업무 시스템과 사용자 환경에서 지켜지도록 만듭니다.
사이버보안은 공격자가 그 기준을 우회하거나 무너뜨리려는 순간을 포착하고 대응합니다.

구분	주된 언어	중심 질문	대표 영역	핵심 목적
정보보안	정책·관리체계의 언어	정보가 안전하게 관리되는가?	정책, 인증, 개인정보, 문서 보호, 접근 권한	정보 자산 보호와 관리체계 유지
IT 통제	운영·통제의 언어	사용자가 정책에 맞게 시스템을 쓰고 있는가?	DRM, DLP, NAC, DB 암호화, IAM, 백업, 형상관리	업무 환경과 자산의 통제
사이버보안	공격·대응의 언어	공격자가 지금 어디로 들어오고 있는가?	WAF, EDR, XDR, 로그 상관분석, 침해 대응	공격 탐지·차단·대응

즉, 정보보안은 기준을 세우고,
IT 통제는 그 기준을 시스템에 적용하며,
사이버보안은 공격자가 그 기준을 우회하는 순간을 탐지하고 대응합니다.

세 영역은 경쟁 관계가 아닙니다.
정보보안과 IT 통제는 사이버보안의 기반이 됩니다.
다만 기반을 갖추었다고 해서 실시간 공격 탐지와 침해대응이 자동으로 완성되는 것은 아닙니다.

비유하면 정보보안, IT 통제, 사이버보안의 관계는 건축, 감리·시공관리, 조경의 관계와도 비슷합니다.

건축은 전체 공간의 큰 그림을 설계합니다.
감리와 시공관리는 그 설계가 현장에서 기준에 맞게 구현되고 있는지 확인합니다.
이 관계는 정보보안과 IT 통제의 관계와 닮아 있습니다.

정보보안이 조직의 보안 정책과 관리체계라는 큰 설계를 만든다면,
IT 통제는 그 기준이 실제 시스템, 계정, 권한, 백업, 설정, 운영 절차에 반영되도록 관리합니다.

하지만 조경은 또 다른 전문 영역입니다.
조경은 단순한 장식이 아니라 배수, 동선, 식재, 계절 변화, 유지관리까지 포함하는 독립된 분야입니다.
건축의 큰 그림 안에 포함될 수는 있지만, 조경에는 조경만의 언어와 판단 기준이 있습니다.

사이버보안도 그렇습니다.
정보보안이라는 큰 틀 안에 포함될 수는 있지만,
사이버보안에는 공격자의 침투 경로, 로그 흐름, 실시간 탐지와 차단이라는 별도의 언어와 판단 기준이 있습니다.

1. 정보보안은 너무 넓은 말이 되었습니다

정보보안은 원래 중요한 개념입니다.

정보의 기밀성, 무결성, 가용성을 보호하는 전체 활동이기 때문입니다.
기업과 기관이 정보를 안전하게 관리하기 위해 반드시 필요한 큰 틀입니다.

문제는 이 말이 현장에서 너무 넓게 사용된다는 점입니다.

예를 들어 다음과 같은 업무가 모두 정보보안으로 분류됩니다.

문서 암호화
DRM
DLP
NAC
DB 암호화
DB 접근제어
데이터 마스킹
키 관리
계정 권한 관리
보안 교육
개인정보 보호
인증 대응
ISMS-P 대응
백업 정책
물리 보안
내부 규정
소스코드 정적 분석
SAST
SCA
SBOM
모의해킹

물론 이들은 모두 필요합니다.
조직의 보안 수준을 유지하고, 내부 통제를 강화하고, 법과 인증 요구사항을 충족하는 데 중요한 역할을 합니다.

그러나 이 모든 것을 같은 수준에서 “사이버보안”이라고 부르기 시작하면 문제가 생깁니다.

정보보안 논의는 넓어지지만,
사이버보안 논의는 오히려 얕아지기 때문입니다.

사이버보안은 단순히 정보를 안전하게 관리하는 일이 아닙니다.
공격자가 실제로 어떤 경로로 들어오고 있는지,
어떤 행위를 하고 있는지,
어디서 차단해야 하는지를 보는 일입니다.

2. 정보보안 도구 중 상당수는 사이버보안이 아니라 IT 통제 애플리케이션에 가깝습니다

정보보안 영역에는 여러 도구와 업무가 포함됩니다.
하지만 그 성격을 하나씩 보면 사이버보안과는 결이 다른 것들이 많습니다.

2-1. 데이터·문서·접근 통제 영역

No	항목	일반적 분류	실제 성격	사이버보안과의 차이
1	문서 암호화	정보보안	문서 사용 통제 애플리케이션	공격 탐지보다 문서 열람·저장·반출 통제 중심
2	DRM	정보보안	권한 기반 문서 관리 시스템	해킹 대응보다 문서 사용 정책 집행 중심
3	DLP	정보보안	데이터 반출 통제 시스템	침투 탐지보다 내부 정보 유출 방지 정책 중심
4	NAC	정보보안	네트워크 접속 통제 시스템	공격 분석보다 단말 접속 허용·차단 관리 중심
5	DB 암호화	정보보안	저장 데이터 보호·규제 대응 시스템	공격 탐지보다 DB에 저장된 데이터의 암호화와 열람 통제 중심
6	DB 접근제어	정보보안	DB 접속·쿼리 권한 통제 시스템	침투 흐름 분석보다 사용자·관리자의 DB 접근 정책 집행 중심
7	데이터 마스킹	정보보안	개인정보·민감정보 노출 최소화 시스템	공격 차단보다 화면·개발·테스트 환경의 데이터 노출 통제 중심
8	키 관리	정보보안	암호키 생성·보관·사용 통제 시스템	공격 탐지보다 암호키 생명주기와 사용 권한 관리 중심
9	계정 권한 관리	정보보안	IAM·권한 관리 시스템	공격 행위 탐지보다 계정 생성·권한·승인 관리 중심
10	PAM	정보보안	관리자 권한·접근 통제 시스템	공격 탐지보다 관리자 계정 사용 승인·기록·통제 중심
11	SSO	정보보안	통합 인증 애플리케이션	공격 행위 분석보다 사용자 인증 편의성과 접근 통제 중심
12	MFA	정보보안	추가 인증 통제 시스템	침해 탐지보다 로그인 단계의 인증 강화 중심

이 표에서 중요한 것은 이 항목들이 불필요하다는 뜻이 아닙니다.
오히려 기업과 기관의 기본 보안 체계를 유지하기 위해 반드시 갖추어야 할 것들입니다.

다만 이들의 중심 목적은 대부분 다음에 가깝습니다.

“사용자가 정책에 맞게 시스템을 사용하도록 통제하는 것”
“정보가 내부 규정에 맞게 관리되도록 하는 것”
“감사와 인증에 필요한 절차와 증적을 갖추는 것”
“업무 시스템과 사용자 환경을 관리하는 것”

즉, 이들은 대체로 IT 통제와 정책 집행의 성격이 강합니다.

2-2. 운영·관리·컴플라이언스 통제 영역

실무에서는 아래 항목들도 자주 정보보안으로 분류됩니다.
그러나 대부분은 공격자의 침투 행위를 직접 추적하기보다,
조직의 자산·권한·데이터·업무 환경을 통제하는 성격이 강합니다.

No	항목	일반적 분류	실제 성격	사이버보안과의 차이
1	보안 교육	정보보안	인식 제고·컴플라이언스 활동	실시간 공격 대응이 아니라 예방 교육 중심
2	개인정보 보호	정보보안	법·규정 준수 관리	해킹 탐지보다 개인정보 처리·보관·파기 기준 중심
3	인증 대응	정보보안	감사·증적·절차 관리	실제 공격 대응보다 인증 항목 충족 중심
4	ISMS-P 대응	정보보안·컴플라이언스	정보보호·개인정보보호 관리체계 인증 대응	실시간 공격 탐지보다 관리체계, 보호대책, 개인정보 처리 기준 충족 중심
5	백업 정책	정보보안·IT 운영	데이터 복구·운영 연속성 관리	공격 탐지보다 장애·랜섬웨어 이후 복구 중심
6	물리 보안	정보보안	출입·시설 통제	사이버 공격 행위 분석과는 별도 영역
7	내부 규정	정보보안	조직 정책과 절차	공격 차단 기술이 아니라 관리 기준 수립
8	비밀번호 정책	정보보안	계정 보안 기준 관리	공격 추적보다 비밀번호 복잡도·변경 주기 등 정책 집행 중심
9	패치 관리	정보보안·IT 운영	시스템 업데이트 관리	실시간 공격 대응보다 취약점 노출을 줄이는 예방 통제 중심
10	취약점 진단	정보보안	취약점 식별·점검 활동	침해 탐지보다 사전 위험 식별과 개선 권고 중심
11	보안 형상관리	정보보안·IT 운영	시스템 설정 기준 준수 관리	공격 대응보다 보안 설정값 점검과 기준 준수 중심
12	CSPM	클라우드 보안	클라우드 설정 오류 점검 시스템	공격 행위 추적보다 클라우드 설정 위험 식별 중심
13	SSPM	SaaS 보안	SaaS 설정·권한 점검 시스템	공격 탐지보다 SaaS 계정·권한·설정 통제 중심
14	MDM	정보보안·IT 운영	모바일 단말 관리 시스템	공격 분석보다 단말 등록·정책 적용·분실 대응 중심
15	EMM	정보보안·IT 운영	기업 모바일 환경 관리 시스템	침해 대응보다 업무용 모바일 앱·데이터·단말 통제 중심
16	매체제어	정보보안	외부 저장매체 사용 통제 시스템	공격 탐지보다 USB·외장하드 등 사용 제한 중심
17	USB 제어	정보보안	이동식 저장장치 통제 시스템	침투 행위 분석보다 파일 반출·악성 저장매체 사용 억제 중심
18	출력물 보안	정보보안	인쇄물 사용 통제 시스템	사이버 공격 대응보다 출력 문서 추적·반출 억제 중심
19	워터마크	정보보안	문서 식별·책임 추적 기능	공격 차단보다 문서 유출 시 사용자 식별과 억제 중심
20	메일 아카이빙	정보보안·컴플라이언스	이메일 보관·검색 시스템	피싱 공격 탐지보다 증적 보관과 감사 대응 중심
21	로그 보관	정보보안·컴플라이언스	감사 로그 저장 시스템	공격 분석 자체보다 로그 보존과 사후 증적 관리 중심
22	GRC 시스템	정보보안	거버넌스·리스크·컴플라이언스 관리	실시간 공격 대응보다 정책·위험·인증 관리 중심
23	BCP	정보보안·IT 운영	업무 연속성 계획	공격 탐지보다 장애·재해 이후 업무 유지 계획 중심
24	DR	정보보안·IT 운영	재해 복구 체계	공격 차단보다 시스템 장애·재해 발생 후 복구 중심
25	자산관리	정보보안·IT 운영	IT 자산 목록·상태 관리	공격 탐지보다 장비·소프트웨어 현황 관리 중심
26	라이선스 관리	IT 운영	소프트웨어 사용 현황 관리	사이버 공격 대응보다 소프트웨어 자산·계약 관리 중심
27	보안 서약서	정보보안	임직원 준수 의무 확인	기술적 공격 대응보다 내부 규정 준수 확인 중심
28	보안 점검표	정보보안	체크리스트 기반 관리 활동	실제 공격 흐름 분석보다 항목별 준수 여부 확인 중심
29	위험평가	정보보안	조직 위험 식별·평가 활동	실시간 탐지·차단보다 관리적 위험 판단과 우선순위 설정 중심

2-3. 개발보안·공급망 통제 영역

최근에는 소스코드 정적 분석, SAST, SCA, SBOM도 자주 사이버보안 영역으로 묶입니다.
하지만 이들도 운영 중인 공격자의 침투 행위를 실시간으로 추적하고 차단하는 도구라기보다,
개발 단계와 공급망 단계에서 취약점과 구성요소를 식별하는 통제 체계에 가깝습니다.

No	항목	일반적 분류	실제 성격	사이버보안과의 차이
1	소스코드 정적 분석	개발보안·애플리케이션 보안	소스코드 취약점 점검 도구	운영 중인 공격 탐지보다 개발 단계의 보안 결함 식별과 개선 중심
2	SAST	개발보안·애플리케이션 보안	정적 애플리케이션 보안 테스트 도구	실시간 침해 대응보다 배포 전 코드 취약점 진단 중심
3	오픈소스 구성 분석	개발보안·공급망 보안	오픈소스 라이브러리·의존성 위험 분석 도구	공격자 행위 추적보다 사용 중인 컴포넌트의 취약점·라이선스 위험 식별 중심
4	SCA	개발보안·공급망 보안	소프트웨어 구성요소 분석 도구	실시간 공격 차단보다 오픈소스 의존성, 취약 버전, 라이선스 관리 중심
5	SBOM	공급망 보안·컴플라이언스	소프트웨어 구성요소 명세서	공격 탐지보다 소프트웨어에 포함된 구성요소를 식별하고 추적하는 가시성 관리 중심

예를 들어 소스코드 검증기는
SAST 기반 개발보안 점검 도구로 볼 수 있습니다.

SBOM은
소프트웨어 구성요소 명세서 또는
소프트웨어 공급망 가시성 관리 체계로 보는 것이 자연스럽습니다.

둘 다 중요합니다.
하지만 운영 중인 웹 공격, 계정 탈취, 서버 침해, 악성 행위 로그를 실시간으로 분석하고 대응하는 사이버보안의 본질과는 구분해야 합니다.

2-4. 공격면 검증·침투 테스트 영역

모의해킹, 레드팀 훈련, 침투 테스트, 버그바운티는 정보보안 컴플라이언스 항목으로 다루어지기도 하지만, 본질적으로는 공격자 관점에서 실제 침투 가능성을 확인하는 활동입니다.
다만 운영 중인 공격을 실시간으로 탐지·차단하는 대응 체계 그 자체는 아니므로, 사이버보안 사전 검증 또는 공격면 검증 영역으로 구분하는 것이 좋습니다.

No	항목	일반적 분류	실제 성격	사이버보안과의 차이
1	모의해킹	정보보안·취약점 진단·컴플라이언스	공격자 관점의 침투 가능성 검증 활동	실시간 탐지·차단은 아니지만, 실제 공격면을 확인하는 사이버보안 사전 검증
2	레드팀 훈련	사이버보안·침해대응 훈련	실제 공격 시나리오 기반 방어 역량 검증	단순 점검보다 탐지·대응 조직의 실전 능력 검증에 가까움
3	침투 테스트	사이버보안·공격면 검증	시스템·웹·계정·네트워크의 침투 가능성 검증	운영 중 실시간 방어는 아니지만 공격 경로를 사전에 확인
4	버그바운티	취약점 검증·공격면 관리	외부 연구자를 통한 취약점 발견 체계	실시간 대응보다는 사전 취약점 발견과 개선 중심

모의해킹은 정보보안 컴플라이언스 항목으로 자주 다루어지지만, 본질은 공격자 관점에서 실제 침투 가능성을 확인하는 활동입니다.
따라서 단순한 인증 대응 증적으로만 소비해서는 안 됩니다.
모의해킹 결과는 WAF, EDR, XDR, 로그 상관분석, 침해대응 체계가 실제 공격을 탐지하고 차단할 수 있는지 검증하는 자료로 연결되어야 합니다.

모의해킹은 정보보안 점검표가 아니라, 사이버보안 침해대응 체계를 검증하기 위한 공격면 검증 활동으로 보아야 합니다.

3. ISMS-P는 중요하지만, 사이버보안 실전 대응 기준으로는 한계가 있습니다

여기서 ISMS-P를 별도로 짚을 필요가 있습니다.

ISMS-P는 정보보호와 개인정보보호 관리체계를 점검하는 중요한 인증입니다.
조직이 정책, 책임, 위험관리, 보호대책, 개인정보 처리 절차를 갖추었는지 확인하는 데 의미가 있습니다.

그러나 ISMS-P는 기본적으로 정보보안 관리체계 인증입니다.
따라서 사이버보안의 실전 대응 역량, 특히 실시간 공격 탐지·상관분석·차단 능력을 직접 평가하는 체계로 보기는 어렵습니다.

물론 ISMS-P 안에도 사이버보안과 관련된 통제 항목은 있습니다.

방화벽
웹방화벽
침입탐지·침입방지
악성코드 대응
로그 관리
보안시스템 운영
공개서버 보호

하지만 이 항목들도 대체로 다음 관점에서 다루어집니다.

보안시스템을 운영하고 있는가?
정책과 절차가 있는가?
담당자가 지정되어 있는가?
로그가 생성되고 보관되는가?
정기적으로 점검하고 증적을 남기는가?

이것은 매우 중요한 정보보안 관리 기준입니다.
그러나 사이버보안 관점에서는 질문이 더 깊어져야 합니다.

로그를 보관하는가?
가 아니라,
로그를 실시간으로 분석해 공격 흐름을 보고 있는가?

방화벽 정책이 있는가?
가 아니라,
공격자의 요청과 이후 서버 행위가 연결되어 보이는가?

웹방화벽을 운영하는가?
가 아니라,
웹 공격 이후 계정·서버·PC·데이터 유출 이벤트까지 상관분석되는가?

ISMS-P의 한계는 여기에 있습니다.

로그가 있어도 대부분은 수집·보관·정기 점검·장기 보존의 관점입니다.
예를 들어 6개월, 1년, 2년처럼 보관기간을 충족하는 일은 컴플라이언스에서 중요합니다.
하지만 그것만으로 공격을 실시간으로 탐지하고 차단할 수는 없습니다.

사이버보안에서 중요한 것은 단순 보관이 아니라
실시간 분석, 상관분석, 공격 흐름 재구성, 즉시 대응입니다.

특히 데이터 유출은 사이버 복원력만으로 해결되지 않습니다.
백업, DR, 업무 연속성 계획은 시스템을 다시 세우는 데 도움을 줄 수 있습니다.
그러나 개인정보, 고객정보, 영업기밀이 외부로 유출된 뒤에는 복구가 아니라 책임과 피해 확산의 문제가 됩니다.

따라서 앞으로의 컴플라이언스는 하나로 뭉뚱그릴 것이 아니라,
다음 두 축으로 나누어 보아야 합니다.

No	구분	정보보안 관점의 컴플라이언스	사이버보안 관점의 침해대응
1	대표 체계	ISMS-P	침해 탐지·분석·대응 체계
2	핵심 목적	정보보호·개인정보보호 관리체계 수립	실제 공격의 조기 탐지와 피해 확산 차단
3	주요 질문	정책과 절차가 있는가?	공격이 지금 발생하고 있는가?
4	로그 관점	수집·보관·점검·증적	실시간 분석·상관분석·공격 흐름 재구성
5	방화벽·웹방화벽 관점	운영 여부와 정책 관리	공격 요청, 계정 행위, 서버 이벤트 연결 분석
6	책임 방식	관리체계 운영 책임	침해 예방·탐지·대응 실패에 대한 운영 책임
7	성격	정보보안 자율 관리 체계	사이버보안 자율 대응 체계

여기서 중요한 것은 두 체계를 모두 자율 관리 체계로 보아야 한다는 점입니다.

정부나 인증기관이 모든 기업의 보안을 대신 운영해 줄 수는 없습니다.
정부는 최소 기준, 점검 항목, 표준 로그, 보고 체계, 침해대응 가이드를 제시할 수 있습니다.
그러나 실제로 시스템을 운영하고, 로그를 생성하고, 공격을 탐지하고, 사고를 차단해야 하는 주체는 기업 자신입니다.

따라서 기업은 이렇게 말할 수 없어야 합니다.

“우리는 ISMS-P를 받았으니 사이버보안도 충분합니다.”

또는 이렇게 말할 수도 없어야 합니다.

“방화벽과 웹방화벽이 있으니 침해대응 책임은 다했습니다.”

인증은 면책이 아닙니다.
보안장비 도입도 면책이 아닙니다.
컴플라이언스 통과도 면책이 아닙니다.

기업은 정보보안 관리체계를 자율적으로 운영해야 하고,
동시에 사이버보안 침해대응 체계도 자율적으로 구축하고 운영해야 합니다.
그리고 실패했을 때의 책임 역시 기업 스스로 져야 합니다.

이 책임은 단순히 사고가 발생했다는 이유만으로 묻는 책임이 아닙니다.
다음 질문에 답하지 못했을 때 발생하는 운영 책임입니다.

필요한 로그를 만들고 있었는가?
로그를 보관만 한 것이 아니라 분석하고 있었는가?
공격 징후를 실시간으로 탐지할 체계가 있었는가?
웹 공격 이후 서버·PC·계정 이벤트를 연결해 보았는가?
사고 발생 후 원인과 범위를 설명할 수 있었는가?
같은 공격이 반복되지 않도록 개선했는가?

이 질문에 답하지 못한다면
인증을 받았더라도 사이버보안 대응 체계는 부족한 것입니다.

따라서 ISMS-P를 만든 사람들이 잘못했다는 뜻은 아닙니다.
제도의 설계 목적 자체가 정보보호와 개인정보보호 관리체계에 있기 때문에 생기는 관점의 한계입니다.

문제는 ISMS-P를 통과했다는 사실을
“우리는 사이버보안도 충분히 잘하고 있다”는 의미로 오해할 때 발생합니다.

ISMS-P는 필요합니다.
그러나 ISMS-P는 사이버보안의 출발점일 수는 있어도,
실전 공격 대응 역량의 종착점은 아닙니다.

앞으로 필요한 것은
정보보안 관점의 ISMS-P와
사이버보안 관점의 침해대응 체계를 구분하는 일입니다.

그리고 두 영역 모두 기업이 자율적으로 관리하되,
실패에 대한 책임도 기업 스스로 지는 구조로 가야 합니다.

결국 컴플라이언스의 핵심은 인증서가 아니라 운영 책임입니다.
정보보안은 관리체계로 증명하고,
사이버보안은 침해를 보고 막고 설명하는 능력으로 증명해야 합니다.

이 관점에서 정부 정책도 달라져야 합니다.
해킹 피해에 대비한다는 명분으로 ISMS-P 의무화와 인증 항목을 계속 늘리는 방식은 한계가 분명합니다.
ISMS-P는 정보보안 관리체계로 남아야 합니다.
이를 해킹 대응의 중심 대책처럼 강제하거나 확대하는 방식은 멈춰야 합니다.

기업의 예산 편성도 바뀌어야 합니다.
ISMS-P 대응, 인증 컨설팅, 증적 관리, 문서 정비에만 예산이 집중되면 실제 침해를 보는 역량은 약해질 수 있습니다.
해킹 피해에 대비하려면 별도의 사이버보안 예산이 필요합니다.
원본 웹 요청 수집, 계정 행위 분석, 서버·PC 이벤트 상관분석, 실시간 차단, 포렌식 증적 확보, 침해대응 훈련에 예산이 배분되어야 합니다.

정리하면 방향은 분명합니다.

정부는 ISMS-P 강제 확대를 해킹 대책처럼 보는 접근을 멈추고,
기업은 ISMS-P 중심 예산에서 사이버보안 침해대응 중심 예산으로 전환해야 합니다.

4. 문서 암호화와 DB 암호화가 있다고 해서 웹 공격을 막을 수는 없습니다

앞서 본 항목들은 모두 중요한 정보보안 활동입니다.
문서 암호화는 문서 사용을 통제하고, DLP는 데이터 반출을 제한하며, NAC는 네트워크 접속을 관리합니다.
DB 암호화와 DB 접근제어는 저장 데이터와 DB 접속 권한을 보호하고, SAST와 SBOM은 개발·공급망 단계의 위험을 줄입니다.
모의해킹은 공격자 관점에서 침투 가능성을 사전에 검증합니다.
ISMS-P는 관리체계와 증적을 점검합니다.

하지만 이 자체가 곧 사이버 공격 대응은 아닙니다.

특히 DB 암호화와 DB 접근제어는 이 차이를 잘 보여줍니다.
DB 암호화는 저장 데이터를 보호하고, DB 접근제어는 DB 접속 권한을 통제합니다.
그러나 둘 다 웹 애플리케이션의 취약한 입력값을 통해 들어오는 SQL Injection 공격을 직접 차단하는 기술은 아닙니다.

SQL Injection은 공격자가 애플리케이션의 정상 DB 조회 경로를 악용하는 공격입니다.
애플리케이션이 정상 권한으로 DB에 접근해 데이터를 조회하면,
DB 암호화가 되어 있어도 결과 데이터는 애플리케이션을 통해 노출될 수 있습니다.

문서 암호화나 DLP가 있다고 해서 웹셸 업로드나 SQL Injection을 실시간으로 탐지할 수 있는 것은 아닙니다.
NAC와 DB 접근제어가 있다고 해서 탈취된 계정의 침투 흐름이 자동으로 재구성되는 것도 아닙니다.
SAST와 SBOM이 있다고 해서 운영 중인 웹 요청의 공격 페이로드나 취약 구성요소 악용 시도를 즉시 차단할 수 있는 것도 아닙니다.
모의해킹을 수행했다고 해서 실제 운영 환경에서 같은 공격을 실시간으로 탐지·차단할 수 있다는 뜻도 아닙니다.
ISMS-P 인증을 받았다고 해서 공격자의 침투 흐름이 실시간으로 상관분석되는 것도 아닙니다.

따라서 정보보안 도구와 사이버보안 도구는 구분해서 봐야 합니다.

정보보안 도구는 주로 사용자, 정보, 접근 권한, 저장 데이터, 구성요소, 증적을 통제합니다.
사이버보안 도구는 공격자와 공격 행위를 봅니다.

이 둘을 구분하지 않으면
기업은 보안 솔루션을 많이 도입하고도
정작 공격자의 침투 흐름은 보지 못하는 상황에 놓일 수 있습니다.

5. 웹 공격을 먼저 논의하는 것은 다른 공격을 묻고 가자는 뜻이 아닙니다

사이버보안 논의에서 자주 발생하는 문제가 있습니다.

웹 공격을 이야기하면 곧바로 이런 반론이 나옵니다.

“공격은 웹만 있는 것이 아닙니다.”
“PC 악성코드도 있습니다.”
“이메일 피싱도 있습니다.”
“내부자 위협도 있습니다.”

맞는 말입니다.

공격은 웹에만 존재하지 않습니다.
PC 악성코드도 있고, 이메일 피싱도 있고, 계정 탈취도 있고, 내부자 위협도 있습니다.

하지만 이 말이 웹 공격 대응 논의를 흐리는 방식으로 사용되어서는 안 됩니다.

웹 공격을 먼저 논의하는 것은
다른 공격을 무시하자는 뜻이 아닙니다.
가장 넓게 열려 있고, 가장 먼저 두드려지는 공격면부터 제대로 보자는 뜻입니다.

건축에서도 마찬가지입니다.
건물이 안전하려면 지반과 골조가 튼튼해야 합니다.
인테리어, 조경, 설비도 중요하지만, 지반과 골조가 흔들리면 전체 건물의 안전을 말하기 어렵습니다.

사이버보안에서도 웹, API, 로그인, 공개 서버는 그와 같은 기본 공격면입니다.
외부에 공개된 웹사이트, API, 로그인 페이지, 관리자 페이지, 파일 업로드 기능, 검색 기능, 게시판, 결제 페이지는 공격자가 가장 먼저 만나는 접점입니다.

따라서 웹 공격을 먼저 보는 것은 선택의 문제가 아닙니다.
가장 근본적인 공격면을 먼저 확인하는 일입니다.

특히 많은 기업의 실제 침해 흐름은 웹에서 시작해 웹에서 끝나지 않습니다.

웹 취약점 공격은 서버 명령 실행으로 이어질 수 있고,
탈취된 계정은 내부 시스템 접근으로 이어질 수 있으며,
업로드된 웹셸은 추가 악성 도구 실행으로 이어질 수 있습니다.
이후에는 Living-off-the-Land 방식으로 정상 도구를 악용해
내부 이동, 권한 상승, 데이터 유출을 시도할 수 있습니다.

그러므로 논의의 순서는 분명해야 합니다.

먼저 외부에 노출된 웹 공격면을 제대로 보고,
그 다음 계정, 서버, PC, 내부 이동, 데이터 유출 흐름을 연결해서 봐야 합니다.

웹을 먼저 보자는 것은
웹만 보자는 뜻이 아닙니다.
공격의 출발점을 놓치지 말자는 뜻입니다.

따라서 웹 공격을 논의할 때는
논점을 다른 곳으로 옮기기보다 먼저 다음을 물어야 합니다.

우리 웹 요청 원문을 보고 있는가?
공격자가 보낸 요청 본문과 파라미터를 분석하고 있는가?
로그인 실패와 성공의 흐름을 함께 보고 있는가?
크리덴셜 스터핑 공격을 계정 행위로 추적하고 있는가?
웹 공격 IP가 이후 서버나 계정 이벤트와 연결되는가?
웹 공격 이후 호스트에서 이상 행위가 발생했는가?
서버에서 발생한 프로세스 실행, 파일 생성, 외부 통신을 함께 보고 있는가?

이 질문에 답하지 못한다면
사이버보안의 기본 공격면을 놓치고 있는 것입니다.

6. 사이버보안의 본질은 공격 흐름을 보는 것입니다

사이버보안은 제품 이름의 문제가 아닙니다.
사이버보안은 공격 흐름을 볼 수 있느냐의 문제입니다.

공격자는 보통 하나의 지점에서 끝나지 않습니다.

웹 취약점을 찌르고,
계정을 탈취하고,
서버에 파일을 업로드하고,
명령을 실행하고,
권한을 올리고,
내부로 이동하고,
데이터를 빼내려 합니다.

따라서 사이버보안은 다음 흐름을 연결해서 봐야 합니다.

웹 공격 → 계정 행위 → 서버 이벤트 → PC 행위 → 데이터 유출 시도 → 대응

이 흐름을 보지 못하면
각 보안 제품은 따로 움직이게 됩니다.

WAF는 웹 공격만 보고,
EDR은 PC나 서버 행위만 보고,
SIEM은 로그를 모으기만 하고,
DLP는 반출만 보고,
인증 대응은 체크리스트만 보게 됩니다.

그러면 전체 공격 흐름은 보이지 않습니다.

사이버보안의 핵심은
각각의 이벤트를 따로 보는 것이 아니라
공격자의 행위를 하나의 흐름으로 재구성하는 것입니다.

7. 좋은 사이버보안은 로그를 중심으로 연결되어야 합니다

사이버보안에서 가장 중요한 것은 로그입니다.

웹 요청 로그,
계정 로그인 로그,
서버 이벤트 로그,
PC 행위 로그,
보안 장비 로그,
애플리케이션 로그가 연결되어야 합니다.

로그가 없으면 공격은 보이지 않습니다.
로그가 흩어져 있으면 공격 흐름은 끊어집니다.
로그를 모으기만 하고 분석하지 않으면 대응은 늦어집니다.

그래서 사이버보안은 다음 질문에 답할 수 있어야 합니다.

누가 접속했는가?
어디에서 접속했는가?
어떤 요청을 보냈는가?
어떤 계정으로 로그인했는가?
어떤 프로세스가 실행되었는가?
어떤 파일이 생성되었는가?
어떤 권한 변화가 있었는가?
어떤 외부 통신이 발생했는가?
어떤 데이터가 유출되려 했는가?

이 질문에 답할 수 있어야
공격을 탐지하고, 차단하고, 분석하고, 재발을 막을 수 있습니다.

즉, 사이버보안은 단순한 정책 관리가 아닙니다.
실제 공격 흔적을 로그로 보고 대응하는 체계입니다.

8. 정보보안과 사이버보안은 분리되어야 하지만, 단절되어서는 안 됩니다

여기서 오해하면 안 되는 점이 있습니다.

정보보안과 사이버보안을 구분해야 한다고 해서
둘이 서로 무관하다는 뜻은 아닙니다.

오히려 정보보안의 탄탄한 기반이 있어야
사이버보안의 실시간 탐지와 대응도 더 강해집니다.

예를 들어 제로트러스트아키텍처(ZTA) 관점에서는
IAM, MFA, PAM 같은 계정·권한 통제 영역이 중요합니다.

하지만 정말 중요한 것은 그 다음입니다.

계정과 권한을 잘 관리하는 데서 끝나면 정보보안 통제입니다.
반면 계정 로그인, 권한 변경, 관리자 행위, 비정상 접근 시도를
실시간 로그 분석과 연결하면 사이버보안의 강력한 탐지 신호가 됩니다.

즉, 기준은 이것입니다.

정보보안 통제가 실시간 공격 탐지와 연결되는가?

연결되지 않으면 관리 통제에 머뭅니다.
연결되면 사이버보안의 탐지·대응 체계로 확장됩니다.

따라서 필요한 것은 이분법이 아닙니다.
필요한 것은 역할의 구분과 연결입니다.

정보보안은 기반을 만들고,
사이버보안은 그 기반 위에서 공격을 실시간으로 본다.

이 관계를 분명히 해야 합니다.

9. 이런 관점에서 XDR 모델이 의미를 갖습니다

이제 많은 조직이 단일 보안 제품만으로는 공격 흐름을 보기 어렵다는 점을 인식하고 있습니다.

웹 공격은 WAF에 남고,
서버 행위는 EDR에 남고,
계정 로그인은 IAM이나 AD 로그에 남고,
데이터 유출 징후는 DLP나 프록시 로그에 남습니다.

문제는 이들이 따로 있으면
공격자가 실제로 무엇을 했는지 한눈에 보이지 않는다는 점입니다.

그래서 최근 XDR, 즉 확장 탐지 및 대응 모델이 중요해지고 있습니다.

XDR의 핵심은 여러 보안 이벤트를 하나의 맥락으로 묶어
공격 흐름을 더 빨리 파악하고 대응하는 것입니다.

예를 들어 웹방화벽에서 특정 IP의 공격 요청이 탐지되었다면,
그 IP가 이후 어떤 계정으로 로그인했는지, 서버에서 어떤 프로세스가 실행되었는지,
어떤 파일이 생성되었고 외부 통신이 발생했는지를 같은 시간대의 이벤트로 연결해 보아야 합니다.

이 연결이 가능해야 단순한 “탐지 알림”이 아니라
침투 시도 → 계정 행위 → 서버 실행 → 외부 통신으로 이어지는 공격 흐름을 설명할 수 있습니다.

이런 관점에서 XDR 기반 통합 보안 플랫폼이 의미를 갖습니다.

중요한 것은 특정 제품 이름 자체가 아닙니다.
핵심은 무엇을 가능하게 하느냐입니다.

사이버보안이 제대로 작동하려면
웹, 서버, PC, 계정, 보안 장비의 이벤트가 하나의 흐름으로 연결되어야 합니다.

예를 들어 PLURA-XDR은 이런 문제의식에서
웹 공격 요청, 계정 행위, 서버·PC 이벤트, 포렌식 증거를 하나의 흐름으로 연결하는 방향을 지향합니다.

WAF로 원본 웹 요청과 공격 시도를 분석
EDR로 서버와 PC의 행위 이벤트를 분석
SIEM/XDR로 IP, 계정, 프로세스, 파일, 외부 통신을 상관 분석
포렌식으로 사고 원인과 범위를 확인
자동 대응으로 공격 확산을 빠르게 차단

예를 들어 특정 IP의 웹 공격 요청이 탐지된 뒤
같은 시간대에 특정 계정 로그인, 서버 프로세스 실행, 파일 생성, 외부 통신이 이어진다면
이를 하나의 침투 흐름으로 연결해 설명할 수 있어야 합니다.

즉, 단순히 보안 제품을 많이 도입하는 것이 아니라
공격 흐름을 하나로 연결해 보는 것이 중요합니다.

관리체계 중심 보안 도구가 사용자를 통제하고 규정을 집행하는 데 초점을 둔다면,
사이버보안 플랫폼은 공격자의 행위를 추적하고 차단하는 데 초점을 두어야 합니다.

10. 이제 질문을 바꿔야 합니다

정보보안 관점에서는 이런 질문을 합니다.

문서가 암호화되어 있는가?
사용자의 권한이 적절한가?
개인정보 처리 절차가 있는가?
ISMS-P 인증 항목을 충족했는가?
로그를 정해진 기간 보관하고 있는가?
백업 정책이 있는가?
내부 규정이 마련되어 있는가?
소스코드 취약점 점검을 수행했는가?
SBOM을 보유하고 있는가?
모의해킹을 수행했는가?

모두 필요한 질문입니다.

하지만 사이버보안 관점에서는 질문이 달라져야 합니다.

공격자가 지금 어떤 경로로 들어오고 있는가?
웹 요청 원문을 분석하고 있는가?
계정 탈취 시도를 탐지하고 있는가?
서버와 PC에서 공격 행위를 추적하고 있는가?
공격 IP와 계정, 프로세스, 파일, 네트워크 이벤트를 연결하고 있는가?
로그를 보관하는 것을 넘어 실시간으로 분석하고 있는가?
탐지 후 즉시 차단할 수 있는가?
사고 이후 원인과 범위를 빠르게 설명할 수 있는가?
모의해킹에서 확인된 공격 경로가 실제 탐지·차단 검증으로 이어졌는가?

이 질문에 답할 수 있어야
기업은 진짜 사이버보안을 하고 있다고 말할 수 있습니다.

특히 미토스급 AI 공격 시대에는 이 질문이 더 중요해집니다.
공격자가 더 빠르게 취약점을 찾고, 여러 공격 경로를 조합한다면,
기업도 보안 항목을 갖추는 수준을 넘어
공격 흐름을 실시간으로 보고 대응할 수 있어야 합니다.

11. 예산과 KPI도 사이버보안 침해대응 중심으로 바뀌어야 합니다

개념을 구분했다면 다음은 예산과 KPI입니다.
정보보안과 사이버보안을 같은 항목으로 묶어 예산을 편성하면, 실제로는 인증 대응과 통제 도구에 대부분의 비용이 쓰이기 쉽습니다.

그 결과 기업은 이렇게 착각할 수 있습니다.

“ISMS-P 예산을 썼으니 보안 투자를 했다.”
“DLP, NAC, DB 암호화, 백업을 도입했으니 해킹 대응도 충분하다.”
“로그를 보관하고 있으니 사고가 나도 설명할 수 있다.”

그러나 해킹 피해를 줄이는 예산은 조금 다릅니다.

원본 웹 요청과 응답을 수집·분석하는 예산
계정 로그인과 권한 변경을 실시간 분석하는 예산
서버·PC 이벤트를 상관분석하는 예산
WAF, EDR, XDR, SIEM을 하나의 공격 흐름으로 연결하는 예산
탐지 후 차단·격리·증적 확보까지 이어지는 대응 예산
침해사고 이후 원인과 범위를 설명할 수 있는 포렌식 예산
반복 공격을 줄이기 위한 대응 훈련과 개선 예산
모의해킹 결과를 실제 탐지·차단 검증으로 연결하는 예산
데이터 유출 시도를 조기에 탐지하고 차단하는 예산

사이버 복원력 예산도 필요합니다.
하지만 백업과 DR 중심 예산만으로는 해킹 피해를 줄이기 어렵습니다.
랜섬웨어도 이제 단순 암호화 문제가 아니라 데이터 유출과 협박이 결합된 공격으로 보아야 하며, 복구 전에 먼저 유출을 탐지하고 차단할 수 있어야 합니다.

따라서 예산 항목도 분리해야 합니다.

구분	예산의 중심	KPI의 중심
정보보안·컴플라이언스	인증 대응, 정책 정비, 증적 관리, 내부 통제	인증 유지, 점검 통과, 문서화 수준
IT 통제	DRM, DLP, NAC, DB 암호화, 백업, 자산관리	정책 적용률, 사용 통제, 장애·복구 관리
사이버보안 침해대응	WAF, EDR, XDR, SIEM, 로그 분석, 포렌식, 자동 대응, 모의해킹 결과 검증	탐지 시간, 차단 시간, 상관분석 정확도, 사고 설명 가능성

보안 조직도 같은 방식으로 봐야 합니다.
정보보호팀이 정책과 인증을 담당한다면, 사이버위협대응 조직은 실시간 공격 탐지와 침해대응을 담당해야 합니다.
한 조직이 모두 담당할 수는 있지만, KPI와 예산은 구분되어야 합니다.

정부도 같은 관점으로 정책을 설계해야 합니다.
해킹 피해를 줄이려면 ISMS-P 의무를 계속 늘리는 방식만으로는 부족합니다.
정부는 ISMS-P 강제를 해킹 대책의 중심으로 삼는 접근을 멈추고,
사이버보안 침해대응 기준을 별도로 제시해야 합니다.

기업 역시 예산을 바꾸어야 합니다.
ISMS-P 중심의 관리 예산만으로는 미토스급 AI 공격이나 실제 침해 흐름에 대비하기 어렵습니다.
해킹 피해에 대비하려면 예산은 인증 대응 중심에서 사이버보안 대응 중심으로 이동해야 합니다.

실무자를 위한 최소 점검 질문

이 글을 읽고 바로 확인해야 할 질문은 다음입니다.

1. 로그는 보관되고 있는가, 분석되고 있는가?

로그 보관은 컴플라이언스입니다.
로그 분석은 사이버보안입니다.

2. 웹 공격 이후 서버 행위를 볼 수 있는가?

웹 요청만 보면 절반입니다.
웹 공격 이후 서버에서 어떤 프로세스가 실행되었는지 봐야 합니다.

3. 계정 통제가 탐지 신호로 연결되는가?

IAM, MFA, PAM이 있어도
이상 로그인과 권한 변경이 실시간 탐지로 연결되지 않으면 통제에 머뭅니다.

4. 인증 대응과 침해 대응을 구분하고 있는가?

인증 통과는 필요합니다.
그러나 인증 통과가 공격 대응 능력을 보장하지는 않습니다.

5. 보안 예산이 통제 도구에만 몰려 있지 않은가?

통제 도구도 필요합니다.
그러나 실시간 탐지·차단·상관분석 역량에도 별도 예산과 책임이 필요합니다.

6. ISMS-P 대응 예산과 침해대응 예산을 구분하고 있는가?

ISMS-P 대응 예산은 관리체계 유지에 필요합니다.
하지만 해킹 피해를 줄이려면 별도의 침해 탐지·분석·대응 예산이 필요합니다.

7. 모의해킹 결과가 실제 탐지·차단 검증으로 이어지는가?

모의해킹은 공격면을 확인하는 데 유용합니다.
그러나 결과 보고서로 끝나면 정보보안 점검에 머뭅니다.
WAF, EDR, XDR, 로그 상관분석, 침해대응 체계가 해당 공격 경로를 실제로 탐지하고 차단할 수 있는지 검증해야 합니다.

✍️ 결론

정보보안은 필요합니다.
하지만 정보보안이 곧 사이버보안은 아닙니다.

정보보안이 정책과 관리체계의 언어라면,
사이버보안은 공격과 대응의 언어입니다.
관리체계 중심 보안은 기준을 만들고, 통제 중심 보안은 그 기준을 운영에 적용합니다.
그러나 사이버보안은 공격자가 그 기준을 우회하는 순간을 보고 대응해야 합니다.

두 언어를 구분하지 못하면, 보안 항목은 늘어나도 공격 흐름은 보이지 않습니다.

문서 암호화, DRM, DLP, NAC, DB 암호화, 계정 권한 관리, 보안 교육, 개인정보 보호, ISMS-P 대응, SAST, SBOM, 모의해킹, 백업 정책, 물리 보안, 내부 규정은 모두 중요합니다.
그러나 이들은 대부분 IT 통제, 정책 집행, 컴플라이언스, 사전 점검에 가까운 영역입니다.

사이버보안은 다릅니다.

사이버보안은 공격자가 실제로 들어오는 경로를 보고,
웹 요청과 계정 로그인, 서버 이벤트와 PC 행위 로그를 연결해,
공격을 탐지하고 차단하고 대응하는 실전 방어 영역입니다.

그래서 기업은 다음을 분명히 구분해야 합니다.

1. 정보보안은 큰 틀입니다

정보와 업무 체계를 안전하게 관리하는 전체 활동입니다.

2. IT 통제는 필요하지만 사이버보안의 본질은 아닙니다

문서 통제, 권한 관리, 인증 대응, DB 암호화, SBOM은 중요하지만 공격 흐름을 직접 보는 것은 아닙니다.

3. ISMS-P는 필요하지만 실시간 공격 대응을 보장하지는 않습니다

ISMS-P는 관리체계와 보호대책을 점검하는 중요한 인증입니다.
그러나 로그의 수집·보관·점검과 실시간 공격 상관분석·차단은 다른 문제입니다.

4. 사이버보안은 공격자 행위를 보는 일입니다

웹, 계정, 서버, PC, 네트워크, 데이터 유출 시도를 로그로 연결해 탐지·차단·대응해야 합니다.

5. 정보보안과 사이버보안은 연결되어야 합니다

정보보안 통제는 기반입니다.
그 기반 위에 실시간 로그 분석과 공격 대응이 연결될 때 비로소 사이버보안 역량이 됩니다.

정보보안이라는 이름으로 사이버보안을 흐리면 안 됩니다.
사이버보안은 별도로 깊게 다루어야 할 실전 공격 대응 영역입니다.

결국 중요한 것은
“보안 항목을 갖추었는가”가 아니라
“공격자가 들어왔을 때 볼 수 있고, 막을 수 있고, 설명할 수 있으며, 사전에 검증한 공격 경로를 실제 대응으로 연결할 수 있는가”입니다.

그 질문에 답하는 것이
진짜 사이버보안의 출발점입니다.

미토스급 AI 공격 시대에는 이 출발점이 더 중요해집니다.
더 빠른 공격에는 더 많은 체크리스트가 아니라
더 빠른 탐지, 더 정확한 상관분석, 더 즉각적인 대응이 필요합니다.

그러므로 결론은 예산과 책임으로 이어져야 합니다.
정부는 ISMS-P 강제 확대를 해킹 대책처럼 보는 접근을 멈추고,
사이버보안 침해대응 기준을 별도로 제시해야 합니다.
기업은 인증 대응 중심 예산에서 벗어나
실시간 탐지·차단·상관분석·포렌식 중심 예산을 별도로 세워야 합니다.

해킹 피해에 대비하는 길은 인증 항목을 더 늘리는 데 있지 않습니다.
공격을 볼 수 있는 체계, 막을 수 있는 체계, 설명할 수 있는 체계를 갖추는 데 있습니다.

사이버 복원력도 필요합니다.
그러나 복원력은 탐지와 차단 이후에 의미를 갖습니다.
데이터 유출을 보지 못하고 막지 못한다면, 아무리 빨리 시스템을 복구해도 핵심 피해는 이미 발생한 뒤입니다.