내 사이트 직접 스캔하기: 공격자보다 먼저 취약점을 찾는 웹 보안 자가 진단 5단계 완전 가이드

공격자는 지금 이 순간에도 자동화된 스캐너로 인터넷을 훑으며 패치 안 된 서버, 열린 포트, 빠진 보안 헤더를 찾고 있습니다. 문제는 단순합니다. 당신이 그들보다 먼저 그 결과를 볼 것이냐, 아니냐.

서버 설정 파일에 안전한 값을 적어 넣는 것과, 그 사이트가 외부에서 실제로 안전하게 보이는 것은 전혀 다른 이야기입니다. 그 사이의 간극을 메우는 유일한 방법은 "측정"입니다. 방어를 아무리 잘 쌓아 올렸어도 검증하지 않으면 그것은 보안이 아니라 그저 희망일 뿐입니다.

이 글에서는 자기가 운영하는 사이트를 공격자와 똑같은 도구로, 똑같은 각도에서 직접 점검하는 방법을 다룹니다. 무엇을 점검해야 하는지, 어떤 스캔이 있는지, 쏟아진 결과를 어떻게 읽고 우선순위를 매기는지, 그리고 이 점검을 어떻게 한 번 하고 끝나는 이벤트가 아니라 배경에서 도는 루틴으로 만드는지까지 — 복붙 가능한 명령어와 체크리스트로 정리했습니다.

시작하기 전에 — 합법성 경고. 이 글의 모든 스캔 기법은 자신이 소유하거나 서면으로 명시적 허가를 받은 자산에 대해서만 수행해야 합니다. 내 사이트를 스캔하는 것은 합법이며 권장되지만, 타인의 사이트를 허가 없이 스캔하는 것은 한국 정보통신망법을 비롯한 여러 법률 위반이며 처벌 대상입니다. 특히 뒤에서 다루는 취약점 스캔은 성격상 더욱 엄격하게 자기 자산에만 국한해야 합니다.

왜 "방어자가 공격자의 시선"을 가져야 하는가

보안 작업은 대개 방어자의 시선에서 출발합니다. 공격면을 줄이고, 안 쓰는 포트를 닫고, SSH를 단단히 하고, 통신을 암호화하고, 보안 헤더를 추가합니다. 여기까지는 "무언가를 만드는" 일입니다.

그런데 여기엔 함정이 하나 있습니다. 만든 것이 의도대로 작동한다고 "믿는" 순간, 검증을 건너뛰게 된다는 점입니다. HTTPS를 켰으니 통신은 안전할 것이고, 헤더를 추가했으니 XSS는 막혔을 것이고, 방화벽을 걸었으니 포트는 닫혔을 것이다 — 이 모든 "~일 것이다"는 외부에서 실제로 스캔해 보기 전까지는 검증되지 않은 가정에 불과합니다.

자가 진단은 시선을 한 번 뒤집는 작업입니다. 내가 만든 것을, 공격자가 보는 바로 그 위치에서 다시 들여다보는 것이죠. 의도와 실제가 일치하는지, 미처 보지 못한 구멍은 없는지를 같은 도구로 확인합니다. 이 글의 나머지는 그 점검을 다섯 영역으로 나누어, 각 영역마다 직접 쓸 수 있는 실제 도구와 함께 설명합니다.

자가 진단의 다섯 영역

내 사이트를 점검할 때 무엇부터 봐야 할까요? 점검 대상을 다섯 영역으로 쪼개면 빠뜨리는 곳 없이 체계적으로 훑을 수 있습니다. 아래 표가 전체 그림이고, 이어서 각 영역을 하나씩 풀어 설명합니다.

영역 1 — TLS/SSL 설정 점검

첫 번째는 TLS 설정입니다. 내 사이트가 어떤 TLS 버전을 허용하는지, 어떤 암호 스위트(서버와 브라우저가 합의하는 암호화 방식의 묶음)를 쓰는지, 인증서는 유효한지, 그래서 전체적으로 몇 등급인지를 봅니다.

이게 왜 중요하냐면 — 브라우저 주소창에 자물쇠 아이콘이 떴다고 해서 안전한 게 아니기 때문입니다. 그 자물쇠 뒤에 폐기됐어야 할 낡은 프로토콜 버전이나 약한 암호 스위트가 그대로 살아 있을 수 있습니다. 설정을 바꿀 때마다, 그리고 정기적으로 실제 등급이 유지되는지 확인해야 합니다.

가장 먼저 할 일은 의외로 간단합니다. 브라우저에 도메인만 넣으면 A+부터 F까지 등급을 매겨 주는 온라인 도구 SSL Labs(Qualys SSL Test)를 한 번 돌려 보세요. 그다음 명령줄에서 종합 점검을 하려면 testssl.sh를 씁니다.

# 한 줄로 프로토콜 버전·암호 스위트·인증서·알려진 TLS 취약점을 종합 점검
testssl.sh https://example.com

testssl.sh는 프로토콜 버전, 암호 스위트, 인증서 상태, 알려진 TLS 취약점을 한 번에 평가하고 등급과 개선점을 보여 줍니다. 설치 없이 등급만 빠르게 보고 싶다면 SSL Labs로 충분합니다.

영역 2 — 심층 TLS 분석

두 번째 영역은 첫 번째의 더 깊은 버전입니다. 영역 1이 "등급과 전반적 상태"를 본다면, 영역 2는 "정확히 무엇이 어떻게 설정되어 있는가"를 봅니다. 지원되는 모든 프로토콜과 암호 스위트의 정확한 목록, 인증서 사슬의 세부, 특정 약점에 대한 노출 여부를 정밀하게 들여다봅니다. 보안 담당자가 깊은 점검을 해야 하거나, 특정 약점의 노출을 정확히 짚어야 할 때 가치가 큽니다.

이 영역의 도구는 sslyze입니다.

# TLS 구성을 정밀 분석하고 결과를 JSON으로 저장 (자동화·이력 비교에 유리)
sslyze --json_out=scan.json example.com

sslyze는 지원 프로토콜과 암호 스위트의 상세 목록, 인증서 사슬, 알려진 TLS 취약점에 대한 노출을 기술적으로 깊이 점검합니다. 결과를 JSON으로 뽑을 수 있어 뒤에서 다룰 자동화·이력 비교와 특히 잘 맞습니다. 점검 후 설정을 손봐야 한다면 Mozilla SSL Config Generator가 서버 종류별 권장 설정을 그대로 만들어 주므로, 추측하지 말고 검증된 값을 가져다 쓰세요.

영역 3 — 보안 헤더 점검

세 번째는 보안 헤더입니다. 응답에 어떤 보안 헤더가 들어 있는지, 빠진 것은 없는지, 들어 있는 값이 올바른지를 봅니다.

보안 헤더는 단 한 줄로 공격의 부류 전체를 막아 주는, 비용 대비 효율이 매우 높은 방어입니다. 그러나 설정만 하고 검증하지 않으면 의미가 없습니다. 의도한 헤더가 실제로 적용됐는지, 정상 페이지뿐 아니라 오류 페이지에서도 적용되는지, 값이 올바른지를 확인해야 합니다.

이 영역은 별도의 특별한 도구가 필요 없습니다. 터미널에서 응답 헤더를 직접 까 보면 됩니다.

# 응답 헤더 전체를 확인
curl -sI https://example.com

# 보안 헤더만 추려서 보기
curl -sI https://example.com | grep -iE 'content-security-policy|x-frame-options|x-content-type-options|referrer-policy|permissions-policy|strict-transport-security'

확인해야 할 핵심 헤더는 다음과 같습니다.

브라우저 개발자 도구의 네트워크 탭에서 응답 헤더를 봐도 되고, 온라인으로 한눈에 보고 싶다면 securityheaders.com이나 Mozilla Observatory가 같은 헤더를 점검해 줍니다. 한 가지 주의할 점 — 헤더가 "있다"와 "제대로 막는다"는 다릅니다. 특히 CSP는 잘못 쓰면 있으나 마나이므로, 값을 손봤다면 CSP Evaluator에 붙여 넣어 실제로 안전한지 한 번 더 확인하세요.

영역 4 — 포트와 노출 스캔

네 번째는 네트워크 노출입니다. 내 서버가 외부에 어떤 포트를 열어 두었는지, 그 포트에서 어떤 서비스가 응답하는지, 그리고 노출된 설정 파일 같은 흔한 민감 경로에 외부에서 접근이 되는지를 점검합니다.

이 점검은 두 가지를 확인합니다. 첫째, 닫았다고 생각한 포트가 정말 닫혀 있는지(외부에서 보이는 인바운드 포트가 0개가 됐는지). 둘째, 잊고 있던 그림자 자산이나 의도치 않게 노출된 무언가가 없는지. 공격자가 스캐너로 보는 바로 그것을, 방어자가 먼저 보는 것입니다.

열린 포트와 응답 서비스는 nmap으로 확인합니다.

# 외부에서 보이는 열린 포트와 서비스 버전 확인
nmap -sV example.com

# 전체 포트(1-65535)를 빠짐없이 훑기
nmap -p- example.com

웹 애플리케이션 표면의 문제 — 노출된 민감 정보, 잘못된 헤더, 취약 지점 — 는 세계에서 가장 널리 쓰이는 오픈소스 웹 보안 스캐너 OWASP ZAP으로 점검합니다. 두 도구를 함께 돌리면 웹 노출과 열린 포트 양쪽을 모두 검증할 수 있습니다.

여기에 한 가지를 덧붙이면 효과가 큽니다. 내가 까맣게 잊고 있던 서브도메인이 어딘가 살아 있는지부터 알고 싶다면, 인증서 발급 기록을 모아 보여 주는 crt.sh에 자기 도메인을 넣어 보세요. 현장에서 "이런 서버가 아직 살아 있었나" 싶은 그림자 자산은 대개 여기서 가장 먼저 드러납니다.

영역 5 — 알려진 취약점(CVE) 스캔

다섯 번째는 알려진 취약점입니다. CVE는 공개적으로 알려진 보안 취약점 하나하나에 붙는 고유 번호로, CVE-연도-일련번호 형태를 띱니다. 내 사이트와 서버가 이런 알려진 취약점에 노출돼 있는지를 방대한 점검 항목으로 스캔합니다.

이게 왜 핵심일까요. 2026년 현재 실제 침해의 압도적 다수는 화려한 제로데이가 아니라, 이미 패치가 나와 있는데도 누군가 적용하지 않은 n-day에서 시작됩니다. 몇 가지 실제 사례를 보겠습니다.

• 2023년 MOVEit Transfer 취약점(CVE-2023-34362)은 Cl0p 랜섬웨어 조직이 대량으로 악용해 전 세계 수백 개 조직을 한꺼번에 침해했습니다.
• Citrix Bleed(CVE-2023-4966)는 패치가 있었는데도 미적용 장비들이 줄줄이 뚫렸습니다.

공격자가 자동화된 스캐너로 "패치 안 한 곳"을 훑고 다닌다면, 방어자도 똑같은 스캐너로 자기 자신을 먼저 훑어야 합니다. 이 영역의 도구는 템플릿 기반 취약점 스캐너 nuclei입니다.

# 커뮤니티가 관리하는 방대한 템플릿으로 알려진 취약점·노출을 점검
nuclei -u https://example.com

nuclei는 커뮤니티가 관리하는 방대한 점검 템플릿을 활용해 알려진 다양한 취약점과 노출을 폭넓게 확인합니다. 발견 항목에 CVE 번호가 붙어 나오면, 그 번호를 NVD나 CISA KEV 목록에 넣어 실제 악용 여부와 심각도를 바로 교차 확인하세요. CISA KEV는 실제로 악용이 관측된 취약점만 추린 목록이라, "지금 진짜 급한 것"을 가려내는 데 특히 유용합니다. 웹 서버 자체의 설정과 알려진 문제까지 함께 보고 싶다면 Nikto를 곁들이면 됩니다.

다섯 도구를 한 번에: 통합 자가 진단

다섯 영역은 따로 돌릴 때보다 함께 돌릴 때 온전한 그림이 나옵니다. 다섯 도구를 묶어 사용하면 "내 사이트가 외부에서 어떻게 보이는가"라는 질문에 대한 종합적인 답을 한자리에 모을 수 있습니다.

#!/usr/bin/env bash
# 자가 진단 통합 스캔 — 반드시 자기 소유 자산에만 사용
TARGET="example.com"

echo "== [1] TLS/SSL 등급 =="
testssl.sh "https://$TARGET"

echo "== [2] 심층 TLS (JSON 저장) =="
sslyze --json_out="tls-$TARGET.json" "$TARGET"

echo "== [3] 보안 헤더 =="
curl -sI "https://$TARGET" | grep -iE 'content-security-policy|x-frame-options|x-content-type-options|referrer-policy|permissions-policy|strict-transport-security'

echo "== [4] 열린 포트·서비스 =="
nmap -sV "$TARGET"

echo "== [5] 알려진 취약점(CVE) =="
nuclei -u "https://$TARGET"

이 다섯을 함께 돌리면 네 가지 질문에 한 번에 답이 모입니다. TLS는 단단한가, 헤더는 갖춰졌는가, 노출된 것은 없는가, 알려진 취약점은 없는가. 무언가를 설정했다면 그것을 검증하는 도구가 반드시 짝으로 존재한다는 것 — 설정과 검증이 함께 갈 때 비로소 "희망"이 아니라 "확인된 보안"이 됩니다.

더 넓게 보고 싶을 때 — 추가 도구 모음

위 다섯 가지로 핵심은 거의 덮입니다. 더 넓게·깊이 점검하고 싶다면 아래 도구들이 도움이 됩니다. 단, 자기 자산에만 사용한다는 원칙은 똑같이 적용됩니다.

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

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

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

스캔을 돌리면 결과가 나옵니다. 그런데 결과를 "받는 것"과 그것을 "제대로 활용하는 것"은 전혀 다릅니다. 특히 취약점 스캔(영역 5)은 수많은 항목을 한꺼번에 쏟아내기 때문에, 무엇부터 손볼지 판단하는 능력이 스캔 자체보다 중요해집니다.

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

흔한 오판이 하나 있습니다. CVSS 점수(취약점 심각도를 0~10으로 매긴 표준 점수)만으로 우선순위를 정하는 것입니다. 점수가 높아도 외부에 노출돼 있지 않거나 악용 조건이 까다로우면 덜 급하고, 반대로 점수가 중간이어도 실제로 악용되고 있다면 최우선입니다. 그래서 점수보다 CISA KEV(실제 악용 목록)이 더 유용할 때가 많습니다.

스캔 결과를 읽을 때는 다음 질문을 던지며 재정렬해야 합니다.

• 이것이 실제로 외부에 노출되어 있는가?
• 이것이 실제로 악용 가능한 상태인가?
• 이것이 나의 중요한 자산에 영향을 주는가?
• 거짓 양성(실제로는 문제가 아닌데 문제로 표시된 것)은 아닌가?

우선순위화의 실용적 순서

위 질문을 거치면 쏟아진 결과를 다음 순서로 줄 세울 수 있습니다.

1. 최우선 (즉시 대응) — 외부 노출 + 실제 악용 가능 + 중요 자산. 이건 미루면 안 됩니다.
2. 차순위 — 외부에 노출돼 있지만 악용 난이도가 높거나 영향이 제한적인 것.
3. 그다음 — 내부에만 있거나 직접적 위험이 낮은 것.
4. 보류 — 거짓 양성으로 판단되는 것. 다만 기록은 남기고, 정말 거짓인지 신중히 확인한 뒤에 내립니다.

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

AI를 활용한 결과 해석

많은 양의 스캔 결과를 정리하는 일은 AI를 붙이기에 좋은 작업입니다. 결과를 통째로 주고 각 발견의 심각도를 평가하게 하거나, 실제 위험과 수정 난이도를 고려한 우선순위를 제안받거나, 구체적 수정 방법을 안내받을 수 있습니다. 스캐너가 주지 못하는 "그래서 무엇을 먼저 하면 되는가"라는 맥락을 채워 주는 셈이죠. 다만 한계선은 분명합니다 — AI의 판단은 사람의 검토를 보조하는 것이지 대체하는 것이 아닙니다. 최종 결정은 반드시 사람이 확인하세요.

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

보안은 상태가 아니라 과정입니다. 한 번 스캔하고 끝내는 것은 사실상 무의미합니다. 시스템은 계속 변하고, 새 취약점은 매일 공개되며, 설정은 시간이 지나며 슬그머니 약해지기 때문입니다.

언제 스캔할 것인가

스캔을 돌리는 시점은 네 가지 트리거로 정리됩니다.

• 정기적으로 — 주간 또는 월간으로 다섯 영역을 스캔합니다. 이게 기본입니다.
• 변경 후에 — 새 서비스를 추가하거나, 설정을 바꾸거나, 새 코드를 배포했을 때. 그 변경이 새로운 노출이나 취약점을 만들지 않았는지 확인합니다.
• 새 위협이 등장했을 때 — 사용하는 소프트웨어에 새 고위험 취약점이 공개되면, 내가 거기 노출됐는지 즉시 스캔합니다.
• AI 모델이 업그레이드되었을 때 — 더 나은 모델은 결과를 더 잘 해석하고 더 많은 위험을 식별할 수 있으므로, 모델 업그레이드 자체를 재점검 신호로 삼습니다.

결과를 추적하라

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

자동화하라

이 모든 반복적 점검은 자동화에 이상적입니다. 사람이 매번 손으로 다섯 스캔을 돌리고 결과를 일일이 비교하는 방식은 오래 가지 못합니다. testssl.sh·sslyze·nmap·nuclei는 모두 명령줄 도구라 cron이나 CI 파이프라인에 그대로 넣어 자동화하기 좋습니다.

# 매주 월요일 새벽 4시에 통합 자가 진단 실행 (crontab -e)
0 4 * * 1 /opt/security/self-scan.sh >> /var/log/self-scan.log 2>&1

실전에서 잘 작동하는 패턴은 이렇습니다. 이 도구들을 주기적으로 돌려 결과를 JSON으로 남기고, 직전 결과와 달라진 부분만 추려 알림을 받는 것입니다. 평소엔 조용하다가 무언가 바뀌었을 때만 신호가 오니, 점검이 부담이 아니라 배경에서 도는 일이 됩니다. 핵심은 점검을 어렵고 드문 이벤트가 아니라, 쉽고 일상적인 루틴으로 만드는 것입니다.

실행 체크리스트

당장 따라 할 수 있도록 정리했습니다.

• 다섯 영역을 모두 점검한다 — TLS(testssl.sh), 심층 TLS(sslyze), 헤더(curl -sI로 CSP·HSTS 등), 포트·노출(nmap·OWASP ZAP), 알려진 취약점(nuclei).
• 닫았다고 생각한 포트가 정말 닫혔는지 nmap으로 외부 인바운드 노출을 검증한다.
• 잊고 있던 서브도메인·그림자 자산을 crt.sh로 먼저 훑는다.
• 스캔 결과를 우선순위로 재정렬한다 — 외부 노출 + 악용 가능 + 중요 자산을 최우선으로.
• AI로 결과 해석을 보조하되 최종 판단은 사람이 확인한다.
• 자가 진단을 정기 루틴으로 만든다 — 정기·변경 후·새 위협·모델 업그레이드를 트리거로.
• 결과를 JSON으로 추적·자동화하고 달라진 부분만 알림받는다.
• 반드시 자기 자산에만 스캔한다 — 타인 자산 무허가 스캔은 불법이다.

자주 묻는 질문 (FAQ)

Q. 내 사이트를 스캔하는 것은 합법인가요? 자신이 소유하거나 서면으로 명시적 허가를 받은 자산이라면 합법이며 오히려 권장됩니다. 그러나 타인의 사이트를 허가 없이 스캔하면 한국 정보통신망법을 비롯한 여러 법률 위반이며 처벌 대상이 됩니다. 특히 nuclei 같은 취약점 스캐너는 성격상 공격 행위로 간주될 수 있으므로, 반드시 자기 소유 자산에만 사용하세요.

Q. 다섯 도구를 다 깔기가 부담스럽습니다. 무엇부터 해야 하나요? 설치 없이 브라우저만으로 가능한 것부터 시작하세요. 도메인을 SSL Labs에 넣어 TLS 등급을 보고, securityheaders.com으로 보안 헤더를 확인하면 영역 1과 3의 큰 그림이 바로 잡힙니다. 그다음 자신의 스택에 맞는 명령줄 도구(testssl.sh, nmap, nuclei)를 하나씩 붙여 나가면 됩니다.

Q. CVSS 점수가 높은 항목부터 고치면 되지 않나요? 점수만으로 우선순위를 정하면 오판하기 쉽습니다. 점수가 높아도 외부에 노출되지 않았거나 악용 조건이 까다로우면 덜 급하고, 점수가 중간이어도 실제로 악용 중이면 최우선입니다. 그래서 단순 점수보다 실제 악용이 관측된 CISA KEV 목록을 함께 보고, 외부 노출·악용 가능성·자산 중요도로 재정렬하는 편이 훨씬 정확합니다.

Q. 스캔 결과를 AI에게 맡겨 우선순위를 정해도 되나요? 보조 수단으로는 매우 유용합니다. 많은 양의 결과를 주고 심각도 평가, 우선순위 제안, 구체적 수정 방법을 받아낼 수 있습니다. 다만 AI의 판단은 사람의 검토를 보조하는 것이지 대체하는 것이 아닙니다. 거짓 양성 판정이나 최종 대응 결정은 반드시 사람이 확인하세요.

Q. 스캔은 얼마나 자주 해야 하나요? 주간 또는 월간 정기 스캔을 기본으로 두고, 여기에 세 가지 트리거를 추가하세요 — 새 서비스 추가나 설정 변경, 새 코드 배포 같은 변경 직후, 사용하는 소프트웨어에 새 고위험 취약점이 공개됐을 때, 그리고 결과 해석에 쓰는 AI 모델이 업그레이드됐을 때입니다. 명령줄 도구들은 cron이나 CI에 넣어 자동화하고 달라진 부분만 알림받으면 부담 없이 유지할 수 있습니다.

원문 출처 및 더 알아보기

이 글은 (주)뎁팀 웹 보안팀이 운영하는 보안 가이드 사이트 SGAEPS(시그앱스)의 가이드를 바탕으로 재구성했습니다. 더 깊은 원문은 SGAEPS 가이드 원문에서 확인하실 수 있습니다.

웹 보안 점검·긴급 대응이 필요하시면 DevTeam의 웹 긴급지원 또는 개발/보안 문의를 이용해 주세요.