웹 보안 점검, 수동 vs 자동: 뭘 먼저 해야 하나

둘 다 필요하지만, 순서가 있다

"보안 점검을 해야 하는데, 자동 스캐너를 돌릴까 전문가한테 맡길까?" 이 질문에 대한 답은 명확하다. 자동 먼저, 수동은 그다음이다.

자동 스캔으로 잡을 수 있는 기본 취약점을 먼저 제거하고, 그 위에 수동 점검으로 비즈니스 로직 취약점을 찾는 것이 가장 효율적이다.

순서가 중요한 이유는 비용 구조에 있다. 수동 점검(모의해킹)은 사람의 시간을 쓴다. 보안 헤더가 빠졌거나 SSH 포트가 열려 있는 것처럼 스캐너가 3초 만에 잡아내는 문제를 전문가가 손으로 찾게 하면, 시간당 수십만 원짜리 인력을 자동화가 대신할 일에 낭비하는 셈이다. 레드팀 관점에서도 실제 침투 테스트는 항상 자동 정찰(recon)로 시작한다. 손쉬운 취약점부터 걷어내고, 사람의 판단이 필요한 영역에 시간을 집중하는 것이 정석이다.

자동 스캔: 빠르고, 저렴하고, 반복 가능

자동 스캐너의 진짜 가치는 반복 가능성이다. 한 번 돌린 결과는 그 시점의 스냅샷일 뿐이지만, 배포할 때마다 같은 기준으로 돌리면 "어제까지 A였는데 오늘 C로 떨어졌다"를 즉시 감지한다. 사람은 이걸 못 한다. 매주 같은 항목을 같은 기준으로 지치지 않고 검사하는 건 기계의 일이다.

자동 스캐너가 확실하게 잡아내는 대표적 문제들은 대부분 설정 레벨이다. 예를 들어 보안 헤더 누락은 스캐너가 응답 헤더만 읽으면 즉시 판별된다.

# 자동 스캐너가 3초 만에 확인하는 것: 응답 헤더
curl -sI https://example.com | grep -iE "strict-transport|content-security|x-frame"

# 아무것도 안 나오면 HSTS/CSP/X-Frame-Options가 전부 빠진 상태
# → 클릭재킹, 프로토콜 다운그레이드, XSS에 무방비

이런 종류의 취약점은 판단이 필요 없다. 있으면 위험, 없으면 안전으로 기계적으로 갈린다. 그래서 자동화가 압도적으로 유리하다.

수동 점검(모의해킹): 깊고, 정확하고, 비싸다

수동 점검이 필요한 이유는 자동 스캐너가 원리적으로 못 잡는 취약점이 있기 때문이다. 대표적인 게 비즈니스 로직 취약점이다. 스캐너는 "이 요청이 문법적으로 위험한가"는 판단하지만, "이 요청이 이 사용자에게 허용돼야 하는가"는 판단하지 못한다.

실제 공격 시나리오를 보자. 쇼핑몰 결제 API가 클라이언트에서 넘어온 가격을 그대로 신뢰하는 경우다.

// 취약: 클라이언트가 보낸 금액을 그대로 결제
POST /api/checkout
{ "product_id": 42, "amount": 1000000 }
// 공격자가 amount를 100으로 조작 → 100원에 결제 성공
{ "product_id": 42, "amount": 100 }

// 안전: 서버가 product_id로 실제 가격을 다시 조회
const price = await db.getPrice(req.body.product_id);
await pay(price);  // 클라이언트 값 무시

이 요청은 SQL Injection도, XSS도 아니다. 완벽하게 정상적인 HTTP 요청이다. 자동 스캐너는 아무것도 차단하지 않는다. 오직 "이 서비스에서 amount는 서버가 결정해야 한다"는 맥락을 이해하는 사람만 찾아낼 수 있다.

또 다른 예는 IDOR(권한 우회)다. /api/orders/1001을 /api/orders/1002로 바꿨을 때 남의 주문이 보인다면, 이건 인증은 통과했지만 인가(authorization)가 빠진 것이다. 응답 코드는 200이고 문법도 정상이라 자동 스캐너는 정상으로 판정한다.

언제 무엇을 써야 하나

자동 스캔이 적합한 경우

• 배포 직후 기본 보안 상태 확인
• 주기적 모니터링 (매주/매월)
• 초기 스타트업, 예산이 제한된 경우
• CI/CD 파이프라인에 통합할 때
• SSL 만료, 보안 헤더 변경 감지

수동 점검이 필요한 경우

• 결제, 금융 서비스를 운영할 때
• 개인정보를 대량으로 처리할 때
• ISMS, ISO 27001 인증이 필요할 때
• 자동 스캔에서 발견된 취약점을 심층 분석할 때
• 비즈니스 로직(할인, 포인트, 권한) 검증이 필요할 때

정리하면 이렇다. 정형화된 문제는 자동, 맥락이 필요한 문제는 수동이다. 보안 헤더가 있는지 없는지에는 정답이 있으니 기계가 잘한다. "이 할인 쿠폰을 무한히 중복 적용할 수 있는가"에는 서비스마다 정답이 다르니 사람이 필요하다.

직접 확인하는 법: 5분 자가점검

전문가를 부르기 전에 스스로 확인할 수 있는 것들이 있다. 브라우저와 터미널만 있으면 된다.

# 1) 열린 포트 확인 — DB/SSH가 외부에 열려 있으면 즉시 위험
nmap -Pn -p 22,3306,5432,6379,27017 your-domain.com

# 2) 인증 없는 API가 뚫려 있는지 — 토큰 없이 그냥 요청
curl -i https://your-domain.com/api/users
# 200과 함께 사용자 데이터가 나오면 인증 누락

# 3) SSL 만료일 확인
echo | openssl s_client -connect your-domain.com:443 2>/dev/null | openssl x509 -noout -dates

브라우저 개발자 도구(F12)의 Network 탭도 강력한 점검 도구다. 로그인 후 페이지를 새로고침하고, API 응답 중에 화면에 안 보이는 다른 사용자의 데이터까지 통째로 내려오는지 확인해 보라. 프론트엔드에서 필터링하려고 전체 DB를 내려보내는 패턴은 개발자 도구만 열면 그대로 드러난다.

실전 권장 순서

1. 자동 스캔으로 기준선 확보, 기본 취약점 제거
2. 발견된 취약점 수정, 보안 헤더, SSL, 포트 등
3. 재스캔으로 수정 확인, 점수 변화 확인
4. 필요시 수동 점검 의뢰, 비즈니스 로직 심층 분석

대부분의 웹사이트는 1~3단계만으로도 공격 표면의 80%를 줄일 수 있다. 수동 점검 비용이 부담되면, 자동 스캔을 주기적으로 돌리는 것만으로도 큰 차이를 만든다.

우선순위를 명확히 하자. 자동 스캔에서 나온 결과 중 DB 포트 노출, 인증 없는 API, .env·.git 노출, SSL 미적용은 발견 즉시 고쳐야 하는 P0다. 이 넷은 공격자가 별다른 기술 없이 곧바로 데이터를 가져갈 수 있는 통로다. 보안 헤더나 서버 버전 노출 같은 항목은 그다음이다. 손이 많이 드는 수동 모의해킹은 이 기본기를 다 갖춘 뒤에 의뢰하는 것이 비용 대비 효과가 가장 크다.

SENTRIX는 레드팀 실무 관점에서 이 순서를 그대로 권한다. 자동 스캔으로 걷어낼 수 있는 표면을 남겨둔 채 값비싼 모의해킹부터 의뢰하는 건, 청소 안 한 방을 정밀 감정 맡기는 것과 같다.

첫 번째 단계: 자동 스캔

URL만 입력하면 21개 보안 항목을 30초 안에 점검한다. 보안 헤더, SSL, 포트, API 키 노출, 디렉토리 접근까지 한 번에 확인.

지금 무료로 보안 점검 시작하기 →