10장. 자기 사이트를 직접 스캔하라 | SGAEPS 2026 웹 보안 실전 가이드

공격자는 이미 당신의 사이트를 스캔하고 있습니다. 유일한 질문은, 당신이 그들보다 먼저 그 결과를 볼 것인가입니다.

들어가며: 방어자가 갖춰야 할 공격자의 시선

3부까지 우리는 방어를 쌓아 올렸습니다. 공격면을 줄이고, 포트를 닫고, SSH를 단단히 하고, 통신을 암호화하고, 보안 헤더를 설정했습니다. 그런데 8장과 9장에서 반복된 한 가지가 있었습니다. "설정했다고 믿지 말고 측정하라." 이 정신이 4부의 핵심입니다.

4부 "검증과 공격적 보안"은 시선의 전환을 다룹니다. 지금까지 우리는 방어자의 시선으로 무언가를 만들고 설정했습니다. 이제 공격자의 시선으로 그것을 점검합니다. 공격자가 1장에서 본 방법으로 당신을 발견하고 조사한다면, 당신은 그들이 보는 것을 먼저 보아야 합니다. 같은 도구로, 같은 각도에서, 자신을 들여다보는 것입니다.

이것이 바로 이 책의 네 번째 원칙입니다. "검증 없는 보안은 희망일 뿐이다." 설정 파일에 안전한 값을 적어 넣는 것과, 외부에서 실제로 그 사이트가 안전하게 보이는 것은 다릅니다. 그 간극을 메우는 유일한 방법은 측정입니다. 자신을 공격자의 시선으로 스캔하여, 의도와 실제가 일치하는지, 미처 보지 못한 구멍은 없는지 확인하는 것입니다.

이 장에서는 자가 진단의 체계적인 방법을 다룹니다. 무엇을 점검해야 하는지, 어떤 종류의 스캔이 있는지, 그 결과를 어떻게 읽고 우선순위를 매기는지, 그리고 이 점검을 어떻게 지속 가능한 루틴으로 만드는지를 살펴봅니다. 각 영역마다 직접 사용할 수 있는 실제 도구를 함께 소개하고, 더 깊이 점검하고 싶을 때를 위한 추가 도구들도 추천합니다.

합법성에 대한 거듭된 강조: 이 장의 모든 스캔 기법은, 반드시 자신이 소유하거나 서면으로 명시적 허가를 받은 자산에 대해서만 수행해야 합니다. 자신의 사이트를 스캔하는 것은 합법이며 권장되지만, 타인의 사이트를 허가 없이 스캔하는 것은 한국의 정보통신망법을 비롯한 여러 법률 위반이며 처벌 대상입니다. 특히 이 장에서 다루는 취약점 스캔은 그 성격상 더욱 엄격하게 자기 자산에만 국한해야 합니다. 이 책의 모든 공격적 기법은 오직 자기 방어와 자가 점검을 위한 것입니다.

10.1 자가 진단의 다섯 영역

자기 사이트를 점검할 때, 무엇을 보아야 할까요? 지금까지 이 책에서 다룬 내용을 바탕으로, 자가 진단을 다섯 영역으로 나눌 수 있습니다. 각 영역이 무엇을 점검하는지, 왜 중요한지, 그리고 어떤 도구로 직접 점검할 수 있는지를 함께 살펴보겠습니다.

영역 1: TLS/SSL 설정 점검

첫 번째 영역은 8장에서 다룬 TLS 설정입니다. 자신의 사이트가 어떤 TLS 버전을 허용하는지, 어떤 암호 스위트를 쓰는지, 인증서는 올바른지, 그리고 전반적으로 어떤 등급인지를 점검합니다.

이 점검이 중요한 이유는 8장에서 충분히 다뤘습니다. 자물쇠 아이콘이 떴다고 안전한 것이 아니며, 낡은 버전과 약한 암호 스위트가 그 뒤에 숨어 있을 수 있기 때문입니다. 설정을 바꿀 때마다, 그리고 정기적으로, 실제 등급이 유지되는지 확인해야 합니다.

도구: testssl.sh — 명령 한 줄로 사이트의 TLS/SSL을 종합 점검합니다. 8장에서 다룬 프로토콜 버전, 암호 스위트(서버와 브라우저가 합의하는 암호화 방식의 묶음), 인증서 상태, 알려진 TLS 취약점을 평가하고 등급과 개선점을 보여 줍니다. 설치 없이 등급만 빠르게 보고 싶다면 온라인 SSL Labs(Qualys SSL Test)도 좋습니다. 브라우저에 도메인만 넣으면 A+부터 F까지 등급이 나옵니다 — 가장 먼저 해 볼 일은 이것입니다.

영역 2: 심층 TLS 분석

두 번째 영역은 첫 번째의 더 깊은 버전입니다. TLS 설정을 더 세밀하게, 기술적으로 분석하는 것입니다. 지원되는 모든 프로토콜과 암호 스위트의 정확한 목록, 인증서 사슬의 세부, 알려진 TLS 관련 취약점에 대한 노출 여부 등을 정밀하게 들여다봅니다.

영역 1이 "등급과 전반적 상태"를 본다면, 영역 2는 "정확히 무엇이 어떻게 설정되어 있는지"를 봅니다. 8장에서 다룬 암호 스위트의 세부를 검증하거나, 특정 약점에 대한 노출을 정밀하게 확인할 때 유용합니다. 보안 담당자나 깊은 점검이 필요한 경우에 특히 가치가 있습니다.

도구: sslyze — TLS 구성을 정밀하게 분석합니다. 지원 프로토콜과 암호 스위트의 상세 목록, 인증서 사슬, 알려진 TLS 취약점에 대한 노출을 기술적으로 깊이 점검합니다. 결과를 JSON으로 뽑을 수 있어, 뒤에서 다룰 자동화·이력 비교에 특히 잘 맞습니다. 설정을 바꿔야 한다면 Mozilla SSL Config Generator가 서버별 권장 설정을 그대로 만들어 줍니다.

영역 3: 보안 헤더 점검

세 번째 영역은 9장에서 다룬 보안 헤더입니다. 자신의 사이트가 어떤 보안 헤더를 응답에 포함하는지, 빠진 헤더는 없는지, 설정된 값은 올바른지를 점검합니다.

9장에서 강조했듯, 보안 헤더는 한 줄로 공격의 부류 전체를 막는 비용 대비 효율 높은 방어입니다. 그러나 설정하고 검증하지 않으면 의미가 없습니다. 의도한 헤더가 실제로 적용되었는지, 오류 페이지에서도 적용되는지, 값이 올바른지를 확인해야 합니다.

도구: 보안 헤더는 별도의 특별한 도구가 필요 없습니다. 응답 헤더에서 다음을 직접 확인하면 됩니다 — Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Strict-Transport-Security(HSTS, 브라우저에게 "이 사이트는 앞으로 무조건 HTTPS로만 접속하라"고 강제하는 헤더). 터미널에서 curl -sI https://example.com로, 또는 브라우저 개발자 도구의 네트워크 탭에서 응답 헤더를 보면 됩니다. (온라인으로 한눈에 보고 싶다면 securityheaders.com·Mozilla Observatory도 같은 헤더를 점검해 줍니다.) CSP를 손봤다면 그 값이 실제로 안전한지 CSP Evaluator에 붙여 넣어 한 번 더 확인하세요 — 헤더가 "있다"와 "제대로 막는다"는 다릅니다.

영역 4: 포트와 노출 스캔

네 번째 영역은 5장과 6장에서 다룬 네트워크 노출입니다. 자신의 서버가 어떤 포트를 외부에 노출하는지, 어떤 서비스가 응답하는지, 그리고 1장에서 본 흔한 민감 경로(노출된 설정 파일 등)가 접근 가능한지를 점검합니다.

이 점검은 두 가지를 확인합니다. 첫째, 6장에서 닫은 포트가 정말로 닫혀 있는지(인바운드 포트가 0개가 되었는지). 둘째, 5장에서 본 그림자 자산이나 의도치 않게 노출된 것이 없는지. 공격자가 1장의 스캐너로 보는 것을, 방어자가 먼저 보는 것입니다.

도구: OWASP ZAP — 세계에서 가장 널리 쓰이는 오픈소스 웹 애플리케이션 보안 스캐너입니다. 사이트를 스캔해 노출된 민감 정보, 잘못된 헤더, 취약 지점 등 웹 표면의 문제를 점검합니다. 열린 포트와 응답 서비스 자체는 5장에서 다룬 nmap으로 함께 확인하여, 5·6장의 공격면이 의도대로 관리되고 있는지 검증합니다. 내가 잊고 있던 서브도메인이 어딘가 떠 있는지부터 알고 싶다면, 인증서 발급 기록을 모아 보여 주는 crt.sh에 자기 도메인을 한 번 넣어 보세요. 현장에서 "이런 서버가 아직 살아 있었나" 하는 그림자 자산은 대개 여기서 먼저 드러납니다.

영역 5: 알려진 취약점 스캔

다섯 번째 영역은 4장에서 다룬 알려진 취약점(CVE)입니다. CVE는 공개적으로 알려진 보안 취약점 하나하나에 붙는 고유 번호로, CVE-연도-일련번호 형태입니다. 자신의 사이트와 서버가 이 알려진 취약점에 노출되어 있는지를, 방대한 취약점 점검 항목으로 스캔합니다. 이것은 4장에서 강조한 n-day 위협 — 패치가 나왔는데도 적용하지 않아 생기는 위험 — 을 직접 점검하는 것입니다.

왜 이것이 핵심일까요. 2026년 현재 실제 침해의 압도적 다수는 화려한 제로데이가 아니라, 이미 패치가 나와 있는데도 누군가 적용하지 않은 n-day에서 시작됩니다. 예컨대 2023년 MOVEit Transfer 취약점(CVE-2023-34362)은 Cl0p 랜섬웨어 조직이 대량으로 악용해 전 세계 수백 개 조직을 한꺼번에 침해했고, Citrix Bleed(CVE-2023-4966)는 패치가 있었는데도 미적용 장비들이 줄줄이 뚫렸습니다. 공격자가 자동화된 스캐너로 "패치 안 한 곳"을 훑고 다닌다면, 방어자도 똑같은 스캐너로 자기 자신을 먼저 훑어야 합니다. 실제로 악용이 관측된 취약점만 추린 CISA KEV 목록을 곁에 두면 "지금 진짜 급한 것"을 가리기 쉽습니다.

이런 취약점 스캔은 알려진 수많은 취약점 패턴을 자신의 사이트에 대해 점검하여, 어떤 것에 노출되어 있는지를 찾아냅니다. 이것이 4장의 우선순위화 5단계 중 "내가 무엇에 취약한지 안다"를 실제로 수행하는 방법입니다.

도구: nuclei — 템플릿 기반 취약점 스캐너로, 커뮤니티가 관리하는 방대한 점검 템플릿을 활용해 알려진 다양한 취약점과 노출을 점검합니다. 4장에서 다룬 n-day 취약점에 자신의 사이트가 노출되어 있는지를 폭넓게 확인합니다. 발견 항목에 CVE 번호가 붙어 나오면, 그 번호를 NVD나 위 CISA KEV 목록에 넣어 실제 악용 여부와 심각도를 바로 교차 확인하세요. 웹 서버 자체의 설정과 알려진 문제를 함께 보고 싶다면 Nikto를 곁들이면 됩니다.

10.2 다섯 도구를 함께 쓰기: 통합된 자가 진단

위 다섯 영역은 따로따로가 아니라 함께 작동할 때 온전한 그림을 만듭니다. 다섯 영역의 도구를 함께 사용하면, 이 책에서 다룬 방어의 거의 모든 측면을 한 번에 점검할 수 있습니다. 각 도구가 이 책의 어느 장과 대응하는지 정리하면 다음과 같습니다.

testssl.sh → 8장(TLS 설정)의 검증. 등급과 전반적 상태.
sslyze → 8장(TLS 설정)의 심층 검증. 정밀한 기술 분석.
보안 헤더 직접 확인(curl -sI) → 9장(보안 헤더)의 검증. CSP·X-Frame-Options·X-Content-Type-Options·Referrer-Policy·Permissions-Policy·HSTS의 존재와 설정값.
OWASP ZAP(+nmap) → 5·6장(공격면과 포트)의 검증. 웹 노출과 열린 포트.
nuclei → 4장(CVE)의 검증. 알려진 취약점 노출.

이 다섯 가지를 함께 돌리면, "내 사이트가 외부에서 어떻게 보이는가"에 대한 종합적인 답을 얻습니다. TLS는 단단한가, 헤더는 갖춰졌는가, 노출된 것은 없는가, 알려진 취약점은 없는가. 이 네 질문에 대한 답이 한자리에 모입니다.

여기서 이 책의 구조가 드러납니다. 1부에서 3부까지 우리는 방어를 쌓았고, 각 방어가 어느 도구로 검증되는지를 이 장에서 연결했습니다. 만드는 것(1~9장)과 검증하는 것(10장)이 짝을 이루는 것입니다. 무언가를 설정했다면, 그것을 검증하는 도구가 있습니다. 설정과 검증이 함께 갈 때, 비로소 "희망"이 아니라 "확인된 보안"이 됩니다.

그 외에 알아두면 좋은 자가 진단 도구

위 다섯 가지로 핵심은 거의 덮입니다. 더 넓게, 더 깊이 점검하고 싶다면 아래 도구들이 도움이 됩니다. 모두 자기 자산에만 사용해야 한다는 원칙은 동일합니다.

설치 없이 온라인으로 — SSL Labs(TLS 등급), Mozilla Observatory(종합 보안 점검), securityheaders.com(보안 헤더). 브라우저만 있으면 됩니다.
포트·자산 발견 — nmap(열린 포트·서비스)에 더해, 외부에 흩어진 자산을 찾는 amass·subfinder·httpx, 인터넷 전체 노출을 검색하는 Shodan·Censys. 5장의 자산 인벤토리와 연결됩니다.
웹 취약점 — OWASP ZAP·nuclei 외에 Nikto(웹 서버 설정과 알려진 문제), wapiti(웹 취약점 크롤링).
서버 하드닝 점검(로컬) — Lynis·OpenSCAP로 서버 자체의 설정을 감사합니다. 6·7장의 하드닝이 실제로 적용됐는지 확인하기 좋습니다.
의존성·컨테이너 — Trivy·Grype로 이미지와 패키지의 취약점을, 언어별로는 npm audit·pip-audit로 의존성을 점검합니다. 4장의 공급망 위험과 연결됩니다.
CMS — 워드프레스를 쓴다면 WPScan으로 플러그인·테마 취약점을 점검합니다.

도구가 많다고 전부 돌릴 필요는 없습니다. 자신의 스택에 해당하는 것부터, 그리고 핵심 다섯 영역부터 시작하면 됩니다.

10.3 스캔 결과를 읽는 법: 우선순위 매기기

스캔을 돌리면 결과가 나옵니다. 그런데 결과를 받는 것과 그것을 제대로 활용하는 것은 다릅니다. 특히 취약점 스캔(영역 5)은 많은 항목을 쏟아낼 수 있어, 그것을 어떻게 읽고 무엇부터 해결할지 판단하는 것이 중요합니다. 이것은 4장의 우선순위화와 직결됩니다.

모든 발견이 똑같이 급하지 않다

4장 4.2에서 강조한 것을 기억하십시오. CVSS 점수(취약점의 심각도를 0~10으로 매긴 표준 점수)만으로 우선순위를 정하면 오판합니다. 점수가 높아도 외부에 노출되지 않았거나 악용 조건이 까다로우면 덜 급하고, 반대로 점수가 중간이어도 실제로 악용되고 있으면 최우선입니다 — 그래서 점수보다 CISA KEV(실제 악용 목록)이 더 유용할 때가 많습니다. 스캔 결과도 마찬가지입니다. 스캐너가 "발견"으로 표시한 모든 것이 똑같이 위험하거나 급한 것은 아닙니다.

스캔 결과를 읽을 때 던져야 할 질문들은 4장에서 본 것과 같습니다. 이것이 실제로 외부에 노출되어 있는가? 이것이 실제로 악용 가능한 상태인가? 이것이 나의 중요한 자산에 영향을 주는가? 거짓 양성(실제로는 문제가 아닌데 문제로 표시된 것)은 아닌가? 이 질문들을 통해, 쏟아진 결과를 실제 위험 순서로 재정렬해야 합니다.

우선순위화의 실용적 순서

4장 4.5의 우선순위화를 스캔 결과에 적용하면 다음과 같습니다.

먼저, 외부 노출 + 실제 악용 가능 + 중요 자산에 해당하는 발견을 최우선으로 처리합니다. 이런 것은 즉시 대응해야 합니다. 다음으로, 외부에 노출되어 있지만 악용 난이도가 높거나 영향이 제한적인 것을 처리합니다. 그 다음으로, 내부에만 있거나 직접적 위험이 낮은 것을 처리합니다. 거짓 양성으로 판단되는 것은 기록해 두되, 정말 거짓인지 신중히 확인한 뒤 우선순위에서 내립니다.

이 우선순위화는 "전부 다 빨간불이니 다 급하다"는 마비도, "양이 많으니 무시하자"는 회피도 아닙니다. 진짜 위험한 것을 가려내어 거기에 집중하는 것입니다.

AI를 활용한 결과 해석

스캔 결과의 해석과 우선순위화는, 부록 E에서 다룬 AI 활용의 좋은 대상입니다(영역 4: 스캔 결과 해석과 우선순위화). 많은 양의 스캔 결과를 AI에게 주고, 각 발견의 심각도를 평가하고, 실제 위험과 수정 난이도를 고려한 우선순위를 제안하며, 구체적 수정 방법을 안내하게 할 수 있습니다. 이것은 스캐너가 주지 못하는 "그래서 무엇을 먼저 하면 되는가"라는 맥락을 채워 줍니다. 다만 부록 E의 한계선을 기억하십시오. AI의 판단은 사람의 검토를 보조하는 것이지 대체하는 것이 아닙니다.

10.4 자가 진단을 루틴으로 만들기

이 책에서 반복된 원칙 5 — 보안은 과정이지 상태가 아니다 — 가 자가 진단에도 그대로 적용됩니다. 한 번 스캔하고 끝내는 것은 무의미합니다. 시스템은 변하고, 새 취약점은 계속 나오며, 설정은 시간이 지나며 약해질 수 있습니다.

언제 스캔할 것인가

부록 E에서 다룬 재점검 트리거를 자가 진단에 적용하면 다음과 같습니다.

정기적으로. 주간 또는 월간으로 다섯 영역의 스캔을 수행합니다. 이것은 기본입니다.

변경 후에. 무언가를 바꿨을 때 — 새 서비스를 추가하거나, 설정을 변경하거나, 새 코드를 배포했을 때 — 그 변경이 새로운 노출이나 취약점을 만들지 않았는지 스캔으로 확인합니다.

새 위협이 등장했을 때. 사용하는 소프트웨어에 새 고위험 취약점이 공개되면, 자신이 그것에 노출되어 있는지 즉시 스캔합니다(4장).

AI 모델이 업그레이드되었을 때. 부록 E에서 강조한 트리거입니다. 더 나은 모델은 결과를 더 잘 해석하고 더 많은 위험을 식별할 수 있으므로, 모델 업그레이드를 재점검의 신호로 삼습니다.

결과를 추적하라

스캔을 정기적으로 수행한다면, 그 결과를 시간에 따라 추적하는 것이 중요합니다. 지난번에 발견된 문제가 해결되었는지, 새로 나타난 문제는 없는지, 등급이 유지되는지를 비교할 수 있어야 합니다. 결과를 한곳에 모아 기록하고 변화를 추적하는 것이, 일회성 스캔을 지속적인 보안 관리로 바꿉니다.

자동화하라

이 모든 반복적 점검은 자동화에 이상적입니다(원칙 6). 사람이 매번 손으로 다섯 가지 스캔을 돌리고 결과를 비교하는 것은 지속되기 어렵습니다. 정기 스캔을 예약하고, 결과를 자동으로 수집하며, 이전과 비교하여 변화를 알리고, AI의 도움으로 우선순위를 해석하게 하는 것이 현실적입니다. testssl.sh·sslyze·nmap·nuclei는 모두 명령줄 도구라 cron이나 CI 파이프라인에 그대로 넣어 자동화하기 좋습니다. 내가 운영하는 서버들에서는 이 도구들을 주기적으로 돌려 결과를 JSON으로 남기고, 직전 결과와 달라진 부분만 추려 알림을 받습니다 — 평소엔 조용하다가 무언가 바뀌었을 때만 신호가 오니, 점검이 부담이 아니라 배경에서 도는 일이 됩니다. 핵심은 점검을 어렵고 드문 이벤트가 아니라, 쉽고 일상적인 루틴으로 만드는 것입니다.

10.5 이 장이 남기는 교훈

이 장에서 확인한 것을 압축합니다.

첫째, 방어자는 공격자의 시선을 갖춰야 합니다. 공격자는 이미 당신을 스캔하고 있습니다. 당신이 그들보다 먼저 그 결과를 보고 구멍을 막아야 합니다. 검증 없는 보안은 희망일 뿐입니다(원칙 4).

둘째, 자가 진단은 다섯 영역으로 이루어집니다. TLS 설정, 심층 TLS 분석, 보안 헤더, 포트와 노출, 알려진 취약점. 각각 testssl.sh, sslyze, 보안 헤더 직접 확인(curl -sI), OWASP ZAP·nmap, nuclei로 점검할 수 있습니다.

셋째, 만드는 것과 검증하는 것은 짝을 이룹니다. 1~9장에서 쌓은 방어 각각이, 10장의 도구로 검증됩니다. 설정과 검증이 함께 갈 때 확인된 보안이 됩니다.

넷째, 스캔 결과는 우선순위로 읽어야 합니다. 모든 발견이 똑같이 급한 것은 아닙니다. 외부 노출, 실제 악용 가능성, 자산 중요도로 재정렬하십시오(4장). 마비도 회피도 아닌, 집중이 답입니다.

다섯째, 자가 진단은 루틴이어야 합니다. 정기적으로, 변경 후에, 새 위협이 등장했을 때, 그리고 AI 모델이 업그레이드되었을 때 스캔하십시오. 결과를 추적하고, 자동화하십시오(원칙 5, 6, 부록 E).

이 장에서 우리는 자신을 외부에서 점검하는 법을 배웠습니다. 그러나 자동화된 스캔이 모든 것을 잡아내지는 못합니다. 스캐너가 놓치는 것들, 사람의 통찰이 필요한 것들, 그리고 실제 침투 테스트 현장에서만 드러나는 것들이 있습니다. 다음 장에서는 펜테스트의 관점으로 한 걸음 더 들어가, 실제 현장에서 반복적으로 발견되는 것들 — 사람들이 "설마 이것이?" 하는 것들 — 을 살펴보겠습니다.

이 장의 실행 항목

다섯 영역을 모두 점검하십시오. TLS(testssl.sh), 심층 TLS(sslyze), 헤더(curl -sI로 CSP·HSTS 등 확인), 포트·노출(nmap·OWASP ZAP), 알려진 취약점(nuclei). (10.1, 10.2)
6장에서 닫은 포트가 정말 닫혔는지 확인하십시오. nmap으로 인바운드 노출을 검증하십시오. (10.1, 6장)
스캔 결과를 우선순위로 재정렬하십시오. 외부 노출 + 악용 가능 + 중요 자산을 최우선으로. (10.3, 4장)
결과 해석에 AI를 활용하되 검증하십시오. 우선순위 제안을 받되 사람이 확인하십시오. (10.3, 부록 E)
자가 진단을 정기 루틴으로 만드십시오. 정기·변경 후·새 위협·모델 업그레이드를 트리거로. (10.4)
결과를 추적하고 자동화하십시오. 일회성 스캔을 지속적 관리로 바꾸십시오. (10.4)
반드시 자기 자산에만 스캔하십시오. 타인 자산 무허가 스캔은 불법입니다. (10장 서두)

다음 장: 11장 — 펜테스트 현장에서 실제로 보는 것들. 스캐너가 놓치는 것, "설마 이것이?" 하는 것들.