모의해킹과 취약점 진단 차이: 우리 서비스엔 무엇이 맞을까

취약점 진단은 정해진 점검 항목을 빠짐없이 확인하는 일이고, 모의해킹은 공격자처럼 생각해서 실제로 피해가 날 수 있는 경로가 있는지 증명하는 일입니다. 진단 보고서는 "어떤 항목이 양호하고 어떤 항목이 취약한가"를 목록으로 보여줍니다. 모의해킹 보고서는 "이 경로로 들어오면 다른 사용자의 주문 정보를 볼 수 있다" 같은 시나리오를 보여줍니다. 하나는 점검 범위를 넓게 덮고, 다른 하나는 깊게 파고듭니다.

그래서 "둘 중 뭐가 더 좋은가"를 따질 문제는 아닙니다. 답은 누가, 왜 점검을 요구했는지에 따라 달라집니다. 고객사가 "진단 결과서"를 달라고 했다면 항목 기반 진단 보고서가 필요하고, 결제·개인정보를 다루는 서비스를 출시하기 전이라면 비즈니스 로직까지 보는 모의해킹이 더 맞을 수 있습니다. ISMS-P를 준비한다면 인증기준이 요구하는 정기 점검 체계부터 갖춰야 합니다.

이 글에서는 용어 정의는 짧게 끝내고, 서비스 단계별로 어떤 점검을 고르면 되는지, 견적을 요청할 때 범위와 산출물을 어떻게 정하면 되는지 의사결정 순서대로 정리합니다.

범위·방식·결과물로 본 차이

구분	취약점 진단	모의해킹
목적	알려진 취약 항목이 있는지 빠짐없이 확인	실제로 악용 가능한 공격 경로와 영향 증명
방식	체크리스트 기반, 자동 도구와 수동 확인 병행	시나리오 기반 수동 테스트 중심
범위	넓음 (서버, 웹, DB, 네트워크 장비 등)	좁고 깊음 (핵심 기능, 권한, 결제 흐름 등)
결과물	항목별 양호/취약 판정표, 조치 가이드	공격 시나리오, 재현 절차, 영향도, 조치 권고
결과 편차	수행자가 달라도 비교적 일정함	수행자의 역량과 투입 시간에 크게 좌우됨

국내에서 "취약점 진단"이라고 하면 보통 KISA가 공개하는 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드 같은 기준의 항목을 바탕으로 합니다. 이 가이드는 2025년 12월에 새 버전이 올라왔으니, 견적서에 적힌 기준이 어느 버전인지도 확인해 두는 편이 좋습니다. 웹 애플리케이션 테스트 방법론으로는 OWASP Web Security Testing Guide(WSTG)가 널리 쓰이고, 모의해킹 업체도 이 가이드를 참고하는 경우가 많습니다.

헷갈리기 쉬운 점이 하나 있습니다. 많은 업체가 "웹 취약점 진단"이라는 이름으로 수동 테스트를 상당 부분 포함해서 팔고, 반대로 "모의해킹"이라는 이름으로 스캐너 결과를 정리해 주는 경우도 있습니다. 이름보다 실제로 무엇을, 며칠 동안, 어떤 계정 권한으로 테스트하는지를 보고 판단해야 합니다.

자동 점검이 잘 못 찾는 취약점

스캐너는 누락된 보안 헤더, 오래된 라이브러리 버전, 전형적인 입력값 검증 오류처럼 패턴이 정해진 문제는 잘 찾습니다. 반면 "이 요청을 보낸 사람이 이 데이터의 주인인가"라는 비즈니스 맥락은 알지 못합니다. 아래 가상의 주문 조회 API를 보겠습니다.

// 취약한 코드: 로그인만 확인하고, 주문 소유자는 확인하지 않음
app.get('/api/orders/:orderId', requireLogin, async (req, res) => {
  const order = await db.order.findUnique({
    where: { id: req.params.orderId },
  });
  if (!order) return res.status(404).json({ message: 'Not found' });
  return res.json(order);
});

이 API는 문법상 문제가 없고, 응답도 정상이며, 에러도 나지 않습니다. 그래서 스캐너 입장에서는 "양호"에 가깝습니다. 하지만 사용자 A로 로그인한 상태에서 사용자 B의 주문 ID를 넣으면 B의 주문 정보가 그대로 보입니다. 이런 문제는 테스터가 계정 두 개를 받아 서로의 리소스에 접근해 보는 수동 테스트에서 주로 드러납니다.

// 고친 코드: 조회 조건에 현재 사용자 ID를 포함
app.get('/api/orders/:orderId', requireLogin, async (req, res) => {
  const order = await db.order.findFirst({
    where: { id: req.params.orderId, userId: req.user.id },
  });
  if (!order) return res.status(404).json({ message: 'Not found' });
  return res.json(order);
});

결제 금액을 클라이언트가 보내는 값 그대로 믿는 문제도 마찬가지입니다. 원인과 방어 패턴은 IDOR 취약점 정리 글과 결제 금액 변조 방지 글에서 더 자세히 다뤘습니다. 핵심은 권한·결제·쿠폰·포인트처럼 돈과 개인정보가 오가는 기능이 많을수록 수동 테스트의 비중이 커져야 한다는 점입니다.

서비스 단계별로 어떤 점검이 맞을까

출시 전: 핵심 기능 중심의 웹·API 모의해킹

정식 출시 전, 특히 결제·회원·개인정보 기능이 처음 붙는 시점이라면 범위를 좁혀서라도 수동 테스트를 받는 편이 효과적입니다. 이때 서버 OS나 네트워크 장비까지 넓게 보는 진단보다는 다음에 집중하는 것이 좋습니다.

회원가입, 로그인, 비밀번호 재설정 흐름
사용자 간 데이터 분리 (주문, 예약, 메시지, 파일)
관리자 기능 접근 통제
결제 금액, 쿠폰, 포인트 검증
BaaS를 쓴다면 DB 접근 정책 (예: Supabase의 RLS 설정은 별도 가이드를 참고)

고객사·입점처 요구: 요구 문서부터 확인

B2B 고객사나 플랫폼 입점처가 보안 점검을 요구했다면, 업체부터 알아보기보다 요구 문서를 먼저 정확히 읽는 것이 순서입니다. 확인할 것은 세 가지입니다.

요구하는 결과물 이름: "취약점 진단 결과서", "모의해킹 보고서", "보안 점검 확인서" 중 무엇인가
수행 주체 조건: 자체 점검으로 충분한지, 외부 전문업체가 해야 하는지, 특정 자격 요건이 있는지
조치 완료 증빙 필요 여부: 발견 항목을 조치하고 이행 점검까지 마쳐야 하는지

조건이 모호하면 담당자에게 "어떤 기준의 항목 점검인지, 수동 침투 테스트가 포함되어야 하는지"를 서면으로 물어보세요. 이 질문 하나로 견적이 크게 달라질 수 있습니다.

ISMS-P 준비: 정기 점검 체계가 먼저

ISMS-P 인증기준에는 '2.11.2 취약점 점검 및 조치' 항목이 있습니다. 이 항목은 정기적으로 취약점을 점검하고 조치하는 절차를 운영하라고 요구하고, 모의침투테스트는 조직의 규모나 정보의 중요도에 따라 고려하도록 되어 있습니다. 즉 일회성 보고서 한 장보다 점검 계획 → 수행 → 조치 → 이행 확인 → 기록으로 이어지는 운영 체계가 핵심입니다.

다만 제도가 바뀌고 있습니다. 2026년에 정부는 사고 이력이 있거나 고위험군으로 분류된 기업을 대상으로 심사 과정에 취약점 진단과 모의해킹을 넣는 방향의 실효성 강화 방안을 발표했고, 관련 시행령 개정도 추진 중이라는 보도가 이어졌습니다. 최종 적용 대상과 시점은 KISA와 개인정보보호위원회 공지에서 직접 확인하는 것이 안전합니다. 준비 중이라면 "항목 기반 진단으로 넓게 덮고, 개인정보 처리 핵심 기능은 모의해킹으로 깊게 보는" 조합을 기본안으로 검토할 만합니다.

견적 요청 전에 정해야 할 범위

범위가 모호하면 업체마다 견적이 몇 배씩 차이 나고, 비교도 어렵습니다. 아래 항목을 미리 정리해서 보내면 견적의 정확도가 크게 올라갑니다.

[점검 범위 정의서 예시]
- 대상: https://app.example.com (웹), https://api.example.com (API), 관리자 페이지 1개
- 제외: 외부 PG사 결제창, 사내 그룹웨어
- 환경: 스테이징 서버 (운영 DB와 분리, 테스트 데이터 사용)
- 계정: 일반 사용자 2개, 관리자 1개 제공
- 테스트 방식: 그레이박스 (API 명세 제공, 소스코드 미제공)
- 기간: 영업일 기준 N일, 테스트 가능 시간대 명시
- 금지 행위: 서비스 가용성에 영향을 주는 부하 테스트, 실제 결제 승인
- 긴급 연락: 고위험 취약점 발견 시 즉시 공유할 담당자

판단 기준을 몇 가지 덧붙이면 다음과 같습니다.

블랙박스 vs 그레이박스: 스타트업이라면 API 명세와 테스트 계정을 주는 그레이박스가 같은 기간 대비 더 많은 문제를 찾는 경우가 많습니다. 정보를 숨긴다고 결과가 더 "실전적"이 되지는 않고, 테스터가 정찰에 시간을 쓰게 될 뿐입니다.
운영 vs 스테이징: 가능하면 운영과 같은 코드가 배포된 스테이징 환경을 준비하세요. 운영 환경에서 해야 한다면 허용 범위를 문서로 합의해야 합니다.
API 개수와 화면 수: 견적은 보통 대상 규모로 정해집니다. 엔드포인트 목록을 대략이라도 뽑아 두면 좋습니다.
모바일 앱 포함 여부: 앱이 있다면 앱 자체 분석까지 포함하는지, 앱이 호출하는 API만 보는지 구분하세요.

산출물에서 확인할 체크리스트

보고서는 받는 순간보다 받은 뒤에 쓸모가 있는지가 중요합니다. 계약 전에 샘플 보고서를 요청하고 아래 항목을 확인하세요.

발견 항목마다 위험도 등급과 그 판단 근거가 있는가
재현 절차가 개발자가 따라 할 수 있을 정도로 구체적인가
영향 범위가 서비스 맥락으로 설명되는가 ("타 사용자 주문 정보 열람 가능" 수준)
조치 방법이 일반론이 아니라 우리 기술 스택 기준으로 제시되는가
점검 범위, 제외 범위, 수행 기간, 사용한 기준이 명시되어 있는가
조치 후 이행 점검(재점검)이 계약에 포함되는가, 몇 회까지인가
고객사 제출용 요약본이나 확인서를 따로 발급하는가
보고서와 테스트 데이터의 보관·폐기 방식이 정해져 있는가

특히 이행 점검 포함 여부는 놓치기 쉽습니다. 고객사가 "조치 완료"까지 확인하는 경우가 많기 때문에, 재점검이 빠진 견적은 싸 보여도 나중에 추가 비용이 생깁니다.

결과를 받은 뒤의 운영

점검은 한 시점의 스냅샷입니다. 다음 배포에서 새 API가 추가되면 그 API는 점검 범위 밖입니다. 그래서 외부 점검과 별개로 팀 안에서 할 수 있는 최소한의 루틴을 함께 두는 것이 좋습니다.

발견 항목을 이슈 트래커에 등록하고 위험도별 조치 기한을 정한다
같은 유형이 반복되지 않도록 공통 미들웨어나 쿼리 헬퍼로 구조를 고친다 (예: 소유자 조건을 강제하는 리포지토리 계층)
권한 검사가 필요한 API에 "다른 사용자 리소스 접근 시 404/403" 테스트를 추가한다
의존성 취약점 알림을 CI에 연결한다
큰 기능 추가나 아키텍처 변경 시점에 범위를 좁힌 재점검을 계획한다

// 회귀 테스트 예시: 다른 사용자의 주문에 접근하면 404
test('사용자 A는 사용자 B의 주문을 조회할 수 없다', async () => {
  const res = await request(app)
    .get(`/api/orders/${orderOfUserB.id}`)
    .set('Authorization', `Bearer ${tokenOfUserA}`);
  expect(res.status).toBe(404);
});

자주 묻는 질문

스캐너만 돌려도 취약점 진단이라고 할 수 있나요?

자동 도구 결과는 진단의 일부일 수 있지만, 그것만으로는 오탐을 걸러내지 못하고 권한·로직 문제도 놓치기 쉽습니다. 고객사 제출용이라면 수동 확인 여부와 점검 기준이 명시된 보고서인지 확인하세요.

모의해킹을 받으면 취약점 진단은 안 해도 되나요?

목적이 다릅니다. 모의해킹은 핵심 경로를 깊게 보지만 서버 설정이나 장비 항목을 전부 덮지는 않습니다. ISMS-P나 고객사 요구처럼 항목 기반 증빙이 필요하면 진단이 따로 필요할 수 있습니다.

얼마나 자주 받아야 하나요?

정해진 정답은 없습니다. 인증이나 계약 조건이 있다면 그 주기를 따르고, 그 밖에는 연 1회 정기 점검에 큰 기능 출시나 구조 변경 시점의 범위 한정 점검을 더하는 방식이 현실적입니다.

정리

취약점 진단은 항목을 넓게 확인하고, 모의해킹은 실제 공격 경로를 깊게 증명합니다.
출시 전에는 핵심 기능 중심 모의해킹, 고객사 요구는 요구 문서의 결과물 조건 확인, ISMS-P는 정기 점검 체계가 출발점입니다.
견적 요청 전에 대상·제외 범위, 환경, 계정, 테스트 방식, 이행 점검 포함 여부를 문서로 정리하면 비교가 쉬워집니다.
우리 서비스에 어떤 점검이 맞는지 직접 판단하기 어렵다면 무료 분석 신청으로 먼저 현황을 확인해 볼 수 있습니다.