비밀번호 보안 관련 이슈 (2026-02-08)

요즘 특정 플랫폼 숏츠 콘텐츠를 보다 보면 자주 등장하는 문장이 있다.

“요즘은 링크만
눌러도
해킹됩니다.”
,
“보안 앱
설치하면
막아집니다.”

이 문장은 강력하고, 직관적으로 무섭다.

일부 유튜버는 댓글이나 상세창에 추가 설명글을 넣어
정정하고 있긴 하지만, 영상내에서는

대부분 위 문구처럼 대본을 쓴다.

하지만 현실의 해킹 사고 구조와 비교해 보면,
이 설명은 중요한 진실을 가리고 있다.

이 글에서는

• 실제 해킹 피해가 발생하는 구조
• 피싱과 제로데이의 정확한 위치
• 왜 비밀번호 관리가 가장 중요한지
• 그리고 “비밀번호는 암호화돼 있는데 왜 뚫리는가”

를 공포 마케팅 없이,
기술적으로 정리해 본다.

1. 실제로 가장 많이 발생하는 해킹 피해 구조

현실에서 대다수의 계정 탈취는 아래 구조를 따른다.

쇼핑몰을 예시로 들자면

• 사용자 DB 구조 예시
  • 사용자 이름
  • 주민등록번호 (현행법상 인증 된 토큰값 저장으로 대체)
  • 연동된 서비스(카카x톡, 네x버, 다x, 구x, 페이x북, 인스x램) 프로필
  • 전화번호 & 계좌번호
  • 카드 정보
  • 구매 이력 & 결제 이력
  • 관심 목록 이력
  • 집 주소 & 직장 주소
  • 생년월일
  • 이메일 & 아이디
  • 비밀번호(암호화 된 값)

이러한 정보들은
어느 계정이 누구의 것인지,
어떤 서비스를 이용하는지,
결제는 어떻게 이루어지는지,
상품은 어디로 배송해야 하는지
이 사람에게 어떤 정보를 주어야 결제가 이루어지는지 등
마케팅 및 핵심 서비스 제공 과정에서
구조적으로 불가피하게 저장된다.

때문에 일반적으로, 그리고 국내외 현행법으로도
해당 데이터는 자격이 지정된 보안 책임자(관리자)의 관리 하에
암호화·난독화 등 보안 처리를 거쳐 보관하도록 요구된다.

하지만, 최근 공공기관과 민간 기업을 가리지 않고
위와 같은 개인정보가 포함된 DB 유출 사고가
빈번하게 발생하고 있다는 사실이다.

실제 과거 사고들을 살펴보면,
비밀번호 및 민감정보 관리 과정의 설계·운영 미흡에서 주로 발생한다.

• 필요 이상의 사용자 데이터 수집
• 민감 데이터 평문보관
• 보안 정책 업데이트 미흡
• 접근 통제 부재
• 역할 분리 실패

와 같은 문제가 반복적으로 지적되어 왔다.

이로 인해 가장 흔하게 발생하는 공격이 바로
크레덴셜 스터핑(Credential Stuffing)이다.

쉽게 말해,

이 정보들만 있으면
사용자 비밀번호를 암호화 되어 알지 못해도

• 어떤 타사 서비스들을 사용하고 있을 가능성이 높은지
• 기입 된 정보를 토대로 타사 시스템에서 추가적으로 수집
• 이 사람이 사이트를 통해 최근 어떤 행위를 했는지
• 이 사람의 관심사가 무엇인지
• 어떤 비밀번호를 다른 사이트에 재사용하고 있을지
• 이 사람에게 어떻게 속이고 관련있는 척 연락하면 되는지

를 상당 부분 추측할 수 있게 된다.

공격자는
직접 대입해서 로그인 시도를 하거나,
보이스 피싱, 피싱 메일, 스팸 메일등을 보내어
사용자의 혼란을 유도해 정보를 탈취하는데 큰 도움을 준다.

해커의 입장에서 보면,
사용자 정보가 들어있는 DB는

“가져다 대면 무조건 열리는 마스터 키가 아닌,
어느 방에 어떤 것이 있는지 표시된 약도(지도)”에 가깝다.

정확히 말하면,
마스터 키를 꽂는다는 표현은
공격 대상에
악성 코드나 해킹 툴을 설치해
기기 자체를 침투·장악하는 공격에 더 가깝다.

2. 크레덴셜 스터핑은 ‘접속 유도 공격’이 아니다

크레덴셜 스터핑은 다음과 같은 공격이다.

• 과거 다른 서비스에서 유출된 혹은 가짜 사이트에서 입력 된
  • 이메일 / 아이디
  • 비밀번호
  • 주민등록번호
  • 전화번호
• 이 자격증명을 공격자가 자기 서버에서 보관하고
• 다른 사이트의 정상 로그인 API에 자동 대입

이 공격에서 중요한 사실은:

• 피해자는 아무 링크도 누르지 않았을 수 있고
• 해당 서비스에 접속조차 하지 않았을 수 있으며
• 공격은 사용자 행위와 무관하게 진행된다

즉,

크레덴셜 스터핑은
“가짜 사이트로 유도해서 속이는 공격”이 아니라
이미 털린 정보를 재사용해 문을 여는 공격이다.

따라서 이 공격의 핵심 대응은:

• 링크 경계 ❌
• 접속 주의 ❌
• 비밀번호 재사용 금지 ⭕
• 서비스별 비밀번호 분리 ⭕

“URL에서 로그인으로 연결되는 형식을 경계하라”는 설명은
피싱 사이트에서 사용자 로그인을 통해 발생하는 정보로

크레덴셜 스터핑을 이용한 공격 시도 중 하나를
차단하는 방법일 순 있으나,

크레덴셜 스터핑의 본질적인 대응은 아니다.

※ 이는 정상적인 서비스 링크마저도 불신하는 결과와 더불어,
추후 설명할 실제 핵심 대응을 흐릴 논점으로 이어질 수 있다.

3. 피싱은 주범이 아니라 ‘확정 수단’에 가깝다

피싱으로 생기는 위협이 존재하지 않는다는 말은 아니다.
다만 역할이 과장되어 설명되는 경우가 많다.

현실적으로 보면:

• 대량 피해의 주력 → DB 유출 + 비밀번호 재사용
• 피싱의 역할 →
  • 일부 정보 보완
  • 고가치 표적 공격
  • 2FA(2차 인증) 우회 시도

즉, 피싱은 주 공격 경로라기보다는
확정 수단에 가깝다.

“링크 클릭 피싱 방식 때문에 털렸다”고 느끼는 경우도,
실제 원인은 이미 다른 서비스에서 유출된 정보와,
피싱 과정에서 전달 된 개인정보인 경우가 많다.

다만, 필자가 이 글에서 정확히 짚고 싶은 부분은 다음과 같다.

현재 시점 기준으로는,
일반 사용자가 ‘링크를 클릭했다’는 행위만으로
즉시 계정 탈취나 시스템 장악까지 이어지는 경우는 극히 제한적이라는 점이다.

그렇다고 해서 링크 기반 공격을 가볍게 보라는 의미는 아니다.
현실적으로 가장 안전한 행동은 여전히 다음과 같다.

• 출처가 불분명한 링크는 의심하고
• 굳이 확인할 필요가 없다면 눌러보지 않는 것

이 원칙은 지금도, 그리고 앞으로도 유효하다.

다만 이를 “링크를 누르면 바로 해킹된다”는 식으로 단순화하는 것은
현실의 공격 구조를 정확히 설명하지 못한다.

아래에서 설명하겠지만,
만약 앞으로 알려지지 않은 취약점(제로데이) 이 대중 환경에서 발견되어
링크 클릭만으로도 안정적인 원격 코드 실행이나 권한 탈취가 가능해지고,

이 수법이 대량 자동화 공격에 적합한 형태로 정착된다면,
또한 보안 업데이트를 완벽히 무력화 시킨다면,

해킹의 주 공격 경로는 지금과는 완전히 다른 양상으로 바뀔 수 있다.

하지만 그 시점은 이 글을 작성하는 시점에서는 오지 않았고,
현재 우리가 마주하고 있는 다수의 피해는

여전히 유출 DB 데이터 + 자격증명 재사용 + 가짜 사이트 및 가짜 신분으로
사용자에게 정보 입력, 현금 입금, 행위 유도라는

고전적이지만 효과적인 공격 구조 위에서 발생하고 있다.

이걸 사회공학(Social Engineering) 기반 공격 이라 부른다.
이 방식이 제일 싸고, 시도하기 쉬운 방식에 해당한다.

복잡한 보안 우회 과정을 만들 필요도 없으며,

사용자를 속여 본인만 알고 있는 정보를 스스로 말하게 끔 유도하여
더욱 확실하게 끌어 낼 수 있는 수법이니까.

때문에 금융·사기 범죄에서는 여전히 핵심 수단으로 사용된다.

그래서 이 글의 목적은
위험을 축소하는 것이 아니라,

지금 시점에서 실제로 가장 많이 발생하는 원인과
현실적인 대응 지점을 정확히 구분하자는 데 있다.

4. CSRF는 ‘사용자 부주의 공격’이 아니다

또 하나 자주 언급되는 수법이
CSRF(Cross-Site Request Forgery, 사이트 간 요청 위조)다.

CSRF는 다음 조건이 동시에 성립해야 한다.

• 사용자가 이미 로그인된 상태
• 서버가 요청의 출처를 제대로 검증하지 않음
• CSRF 토큰, SameSite 쿠키 등의 방어 미구현

즉,

CSRF는 “서버가 사용자를 어떻게 인증하느냐”의 문제다.

정확히는:

• 서버가 요청(Request) 을 처리할 때
• 그 요청이
  • 어디서 왔는지
  • 사용자가 실제로 의도한 것인지
• 를 검증하지 않는 구조적 결함을 이용하는 공격

즉, 공격자는:

• 사용자의 비밀번호를 훔칠 필요도 없고
• 사용자를 속여서 입력시키지도 않으며
• 사용자를 가짜 사이트에 로그인시킬 필요도 없다

이미 로그인된 세션을 서버가 믿어버리는 구조를 악용하는 것이다.

현대적인 웹 서비스에서
CSRF 방어가 제대로 적용되어 있다면,
링크 클릭 만으로 CSRF가 성립하는 경우는 극히 제한적이다.

일반적으로는
링크 클릭 이후에도

• 이미 인증된 세션이 유지된 상태에서
• 사용자의 추가 행위(폼 제출, 버튼 클릭 등)가 발생
• 브라우저가 자동으로 요청을 전송할 수 있는 조건

이 충족 되어야만,
다른 사이트에서 유도된 요청이

서버의 민감한 상태 변경 요청(송금, 설정 변경 등)으로
처리될 수 있다.

따라서 CSRF를 사용자에게
“링크를 조심하라”는 문제로 설명하는 것은
공격의 책임 주체와 원인을 잘못 전달하는 설명이 된다.

5. “비밀번호는 암호화돼 있는데 왜 뚫리는가”

위 1번 문단 설명에서 패스워드가 암호화 되어있다는 설명을 보고
많은 사람들이 이렇게 생각한다.

“비밀번호는
암호화돼서 저장된다는데,
그럼 왜 해킹이 되지?”

여기에는 중요한 오해 하나가 있다.

5.1 비밀번호는 ‘암호화’가 아니라 ‘해시’된다

대부분의 서비스는 비밀번호를 이렇게 저장한다.

비밀번호 → 해시 함수 → 해시값(DB 저장)

• 원문 비밀번호 ❌ 저장하지 않음
• 해시값 ⭕ 저장

해시는 복호화가 불가능하다.
즉, 해커가 해시값을 “되돌려 푸는” 건 아니다.

5.2 그럼 어떻게 뚫리는가

정답은 대입과 매칭이다.

해커들은 이미
수십억 개의 흔히 사용되는 비밀번호와
그에 대응하는 해시값을
알고리즘별로 정리한 사전(DB)를 보유하고 있다.

이 중, 사전에 계산된 해시값을 미리 저장해 둔 형태를
일반적으로 레인보우 테이블(Rainbow Table)이라고 부른다.

공격 흐름은 다음과 같다.

• 유출된 DB에서 해시값을 확보한다
• 사용된 해시 알고리즘(MD5, SHA-1, bcrypt 등)을 파악한다
• 보유한 사전(DB)의 해시값과 비교한다
• 해시값이 일치하면
  • “이 해시는 123456”
  • “이 해시는 qwerty123”
    와 같이 원문 비밀번호를 역으로 추정한다

이 과정은 암호를 되돌려 푸는 ‘복호화’가 아니라,
이미 계산된 값과의 매칭(대입 비교)이다.

브루트 포스(Brute Force) 공격은 어디에 해당하는가

사전(DB)에 존재하지 않는 비밀번호의 경우,
공격자는 브루트 포스(무차별 대입) 방식을 사용한다.

브루트 포스란 다음과 같은 방식이다.

• 가능한 모든 문자 조합을 생성
  (숫자 → 소문자 → 대문자 → 특수문자 조합)
• 로그인 페이지에 각 조합 직접 입력하거나
• 같은 암호화 알고리즘을 쓰는 해시 생성 함수에 입력
• 생성된 해시값을 유출된 해시값과 비교
• 실제 로그인 성공 시
• 해시 값이 일치할 경우 해당 조합을 평문 비밀번호로 추정

즉, 브루트 포스 역시
해시를 되돌려 푸는 것이 아니라,
가능한 모든 입력값을 앞에서부터 만들어 대입하는 방식이다.

5.3 때문에 ‘쉬운 비밀번호’는 즉시 털린다

123456, password, qwerty,
이름+생일 같은 비밀번호는 특수문자가 붙었든, 대소문자를 썼든,

레인보우 테이블:

• 이미 해커의 DB에 다 들어 있고
• 연산조차 거의 필요 없다

Salt가 있어도:

• salt 값은 DB에 함께 저장되고
• 쉬운 비밀번호라면 다시 계산해 맞춰보면 끝이다

브루투 포스방식:

• 별도 로그인 반복 시도에 대한 제제가 없고
• 패스워드가 단순하다면

해커들은 제일 먼저 시도해볼 방식일 수도 있다.
결국 핵심은 이것이다.

보안은
‘못 풀게’가
아니라
‘풀기 비싸게’
만드는 문제다.

이 때문에 기업과 서비스 제공자들은
다음과 같은 기준을 지속적으로 강조한다.

• 특수문자
• 대문자
• 소문자
• 숫자
• 이전 패스워드 재사용 금지

를 섞은 일반적으로 8자 이상, 최근에는 12자 이상 권장의 비밀번호 사용을 요구하고,
일정 기간마다 비밀번호 변경을 권장한다.

기업 차원에서는 다음과 같은 서버·인프라 측 방어 요소를 함께 적용한다.

• Rate limiting (로그인 시도 횟수 제한)
• CAPTCHA (자동화 공격 차단)
• IP reputation (악성 IP·프록시·봇 네트워크 차단)
• MFA / 2FA (자격증명 탈취 이후 단계 차단)

이러한 정책의 목적은
“완벽한 보안”이 아니라,
공격자가 대량 자동화 공격을 수행하기 어렵게 만들고
연산 비용과 시간을 감당할 수 없게 만드는 것에 있다.

즉, 복잡한 비밀번호와 주기적 변경은
사용자를 불편하게 만들기 위한 규칙이 아니라,
공격의 경제성을 무너뜨리기 위한 최소한의 방어선이다.

그럼 ‘복호화’는 언제 등장하는가

엄밀히 말하면, 실제 공격 현장에서는
비밀번호를 대입, 연산하는 이 과정을 관행적으로 “복호화”라고 부르기도 하지만,
기술적으로는 복호화가 아니라 대량 계산 기반 대입 공격에 가깝다.

대표적인 방식은 다음과 같다.

• GPU / ASIC 기반 대규모 해시 계산
• 사전 기반 해시 생성 + 온디맨드(On-demand) 계산
• bcrypt / scrypt / argon2 대응을 위한 맞춤형 패턴 사전

이 방식은
단순 해시 매칭과 달리 연산 비용이 매우 높고 시간도 오래 걸리며,
현존하는 범용 PC 최고 성능 기준으로는 현실성이 낮다.

실제 공격에서는
고성능 GPU·CPU가 다수 투입된
연구기관·데이터센터급 서버 환경이 필요하다.

그마저도 암호화 방식에 따라 계산 시간 차이가 크게 달라진다.
표준 패스워드 규칙(아래 9번 문단 참조)을 잘 지켰다면,

비양자 컴퓨팅 환경에서는 물론,
양자 가속을 가정하더라도 해시값만을 기준으로

사람이 읽을 수 있는 평문 비밀번호를
실용적인 시간 내에 도출하는 것은 사실상 불가능한 범주에 속한다.

암호화 복호화에 대한 더 자세한 내용은 아래 블로그를 참조해도 좋다.

[Security] 암호화/복호화 이해하기 -1 : 기초, 암호화 종류(단방향, 양방향)

해당 글에서는 암호화/복호화에 대해 이해하며 암호화의 종류에 대해 이해를 돕기 위해 작성한 글입니다. 1) 암호화(Encryption) / 복호화(Decryption)1. 암호화(Encryption)💡 암호화(Encryption)- ‘평문’ 형태로 되어 있는 데이터나 정보를 ‘읽을 수 없는 형태(암호화 된 데이터)’로 변환하는 것을 의미합니다. 이러한 읽을 수 없는 형태로 만들기 위해 ‘암호화 키’가 필요합니다.- 암호화의 목적은 정보를 보호화하고 기밀성, 무결성, 인증성을 보장하기 위해 사용이 됩니다. 💡 암호화 과정 예시- 송신자와 수신자 간의 “Hello”라는 평문으로 데이터를 주고 받습니다.- 이 데이터는 외부의 사용자가 이를 읽고 데이터를 가로챌 수 있기에 사용자 간의 암호화…

TISTORYadjh54

그래서 사회공학 공격이 병행된다

이 때문에 실제 공격에서는 다음이 함께 사용된다.

• 탈취된 DB에 포함된 해시값으로 저장되지 않은
  이메일, 전화번호, 이름, 주소 등의 개인정보
• 이를 참조한
  피싱, 사칭, 심리 유도와 같은
  사회공학(Social Engineering) 기반 공격

따라서 연산 비용이 크고 탐지·차단 위험이 높은
해시 대입 공격이나 브루트 포스(Brute Force Attack)를 무한정 시도하기보다는,
사회공학(Social Engineering) 기반 공격 병행하게 되는 것이다.

그래서 필자가 사회공학 기반 공격 이 방식이 제일 싸고,
시도하기 쉬운 방식이라 주장하는 것이다.

6. 그럼 제로데이 수법은?

제로데이는 종종 신비화되거나, 과도한 공포의 대상이 된다.

예를 들면, 아래 기사처럼 한때 떠들썩하게 했던
RCS 기능 취약점을 이용한 제로클릭(CVE-2024-49415) 수법이 있다.

출처 : 시큐리티월드
https://www.boannews.com/media/view.asp?idx=140230

복잡해 보이지만 비유로 풀면 이해가 쉽다.
영화에서 도둑이 은행을 터는것을 비유한다면,

도둑이
경비원, 관계자, 손님의
감시를 피하기 위해
대문이나
창문이 아니라

일반 사람이 출입 경로로
생각하지 않는 곳인

환기구,
전기배관,
수로관을 이용해서

현금 다발이 있는
금고 안에 들어간 후
현금만 털고
조용히 나오는
것이다

이 상황에서 중요한 점은,

이 도둑이 은행 직원, 손님 앞에서
경찰이나, 은행 직원 행세를 하거나,

순간이동과 같은 말도 안되는 마법을 사용하여
털었다던가,

총을 들이밀면서
경찰이나, 직원, 손님 모두에게

"나 강도입니다" 하며 들어와 금고를 털고
경찰, 언론, SNS 커뮤니티의 추적을 따돌리고
무사히 도주하는 운 좋은 초보자가 아니라는 것이다.

그는

• 은행의 건물 구조를 알고 있고
• 우회 통로가 사람이 이동할 수 있는 정도임을 파악했고
• 우회 통로가 어디까지 이어져 있으며
• 경비원의 위치, CCTV 배치, 순찰 패턴을 파악했으며
• 사람들의 사각 지점을 이해하고 있고
• 도주로는 어디를 이용하고
• 도주 할 때 이동 수단은 무엇을 쓸지
• 어떻게 하면 강도 행위가 은행, 경찰 등 관리자를 속이고
• 완벽히 은폐까지 가능한지

즉, 제로데이 공격자는
무작위로 문을 두드리는 소매치기가 아니라,

대상을 연구하고,
시간과 비용을 들여 진입 경로를 설계할 수 있는
전문 침입자에 가깝다.

그리고 이 대도는
해당 방식이 대중화되어 여러 사람이 사용하게 되면,
곧바로 대응과 차단이 이루어질 것을 알고 있다.

금고가 반복적으로 털렸다는 사실이 확인되면

은행 관계자는 경찰에 신고할 것이고,
경찰은 도둑이 어떤 경로로 침입 했는지를
면밀히 조사한 뒤 언론 보도까지 이어질 가능성이 높다.

또한 은행 직원 역시 바보가 아니기에,
환풍구나 수도관에 사람이 드나들 수 없도록 쇠창살을 보강할 것이다.

이 시점 이후에는
같은 수법을 다시 사용하는 것이

도둑 입장에서 더 이상 안전하지 않다는 것도
이미 계산에 들어가 있다.

때문에 제로데이 공격자는
자신의 범죄 행위와 침입 경로가 알려지는 상황을 피하려 하며,

공격 수법을 적극적으로 알리거나, 사용자가 쉽게 파악가능 한 방식이나,
대중적으로 확산시키는 선택을 하지 않는다.

우리가 아는 "창과 방패의 싸움", "수칙과 규칙은 피로 쓰여져 있다"는 말이
어쩌면 이 상황을 놓고도 말할 수 있다.

이 은행 비유를 PC·브라우저 환경에 대응시키면,
다음과 같은 기술적 요소로 정리할 수 있다.

🔹 커널 (Kernel)

• 권한 상승 (LPE)
• 커널 메모리 손상
• 드라이버 취약점
• 시스템 콜 경계 붕괴

→ 사용자 계정 → 시스템 권한으로 이동

🔹 브라우저 RCE (Remote Code Execution)

• JavaScript 엔진 (V8, SpiderMonkey 등)
• JIT 컴파일러 취약점
• 힙 / 스택 메모리 손상
• 타입 혼동(Type Confusion)

→ “페이지를 보는 것만으로” 코드 실행 가능

🔹 샌드박스 탈출 (Sandbox Escape)

• 브라우저 프로세스 분리 우회
• Renderer → Browser → OS 경계 탈출
• IPC 취약점 악용

→ 단일 취약점이 아니라 연결된 체인이 필요

🔹 안정적인 익스플로잇 체인 구성

제로데이는 보통 단일 취약점으로 끝나지 않는다.

일반적인 흐름:

1. 브라우저 RCE
2. 샌드박스 탈출
3. 권한 상승
4. 지속성 확보 (Persistence)

→ 이 모든 단계가 같은 환경에서 안정적으로 동작해야 한다.

이게 바로:

“대상을 연구하고, 시간과 비용을 들여 진입 경로를 설계한다”
라는 표현이 나오는 이유다.

이러한 제로데이 취약점은 누가 만들어 내는가?

제로데이 취약점은 우연히 발견되는 경우도 있지만,
대부분은 의도적으로 투자와 연구를 통해 발굴된다.

• 제로데이 발굴 주체
  • 국가(정보기관, 군): 매우 많음
  • 상업 익스플로잇 기업: 다수
  • 상급 블랙해커 : 다수
  • 상급 화이트 해커 : 다수
• 제로데이 사용 주체
  • 국가 APT: 최다
  • 사이버 범죄 조직: 조건부 사용
  • 개인 단독 공격자: 드묾

국가 단위의 정보기관이나 군은
사이버 작전을 위해 지속적으로 제로데이 발굴에 투자한다.

이들은 대규모 연구 인력과 퍼징 인프라, 장기간 분석 역량을 기반으로
운영체제, 브라우저, 통신 프로토콜 등 핵심 영역의 취약점을 체계적으로 탐색한다.

상업 익스플로잇 기업 역시 중요한 축이다.
이들은 제로데이 취약점을 발굴한 뒤,

정부 기관이나 법집행 기관에 합법적으로 판매하는 사업 모델을 가진다.

주요 대상은
모바일 메신저, 운영체제(OS), 브라우저와 같은
대중적이면서 영향 범위가 큰 플랫폼들이다.

상급 블랙해커 또한 제로데이를 발굴한다.
다만 이들 역시 개인 단독으로 활동하기보다는,
조직화된 범죄 그룹에 소속되거나
국가 단위의 후원을 받는 경우가 많다.

이렇게 발굴된 제로데이는
다크웹이나 암시장에서 고가에 거래되거나,
특정 공격 캠페인에 제한적으로 사용된다.

상급 화이트 해커 역시 제로데이 취약점을 적극적으로 발굴한다.
하지만 목적·사용 방식·공개 경로는
블랙해커나 범죄 조직과 근본적으로 다르다.

화이트 해커는
공격자가 먼저 발견하기 전에
실제 악용 가능성을 공격자 관점에서 검증하고,
패치 및 완화 방안을 함께 제시하기 위해
의도적으로 제로데이를 발굴한다.

본문에서 중요한 점은 다음이다.

제로데이는 누가 발굴하느냐에 따라
위협이 될 수도 있고, 방어를 강화하는 도구가 될 수도 있다는 점이다.

또한 제로데이는 ‘아무나 우연히 만들어내는 기술’이 아니라,
시간·인력·자본이 지속적으로 투입되는
고난도 자산이라는 점이다.

이 때문에 제로데이 공격은
비용이 최소화 되어야 이득이 남는
개인 단위의 무차별 해킹보다는

국가 간 사이버 작전이나 고가치 표적 공격에서
훨씬 더 자주 사용된다.

7. 왜 제로데이는 AI도 보안 솔루션도 막기 어려운가

제로데이의 정의 자체는 다음과 같다.

• 패치 없음
• 시그니처 없음
• 사전 정보 없음

이 상태에서는
사람 ❌
룰 기반 보안 ❌
AI ❌

모두 사전 차단을 보장하기 어렵다.

그래서 현실적인 보안의 전제는 이렇다.

“침투는 가정하고,
확산과 피해를 제한한다.”

보안 솔루션의 역할 역시
침입 자체를 완벽히 막는 것이 아니라,
침투 이후의 행동을 빠르게 식별하고 제어하는 데 있다.

이 과정에서 활용되는 탐지 방식은 다음을 포함한다.

• 학습된 데이터 기반 탐지
• 행위 기반 분석 (Behavioral)
• 통계·확률 모델
• 상관 분석 (Graph / Sequence)

즉, 공격이 시작된 이후의 이상 행위를
사람보다 훨씬 빠르게 포착하고 대응하는 것이 핵심이다.

물론 이러한 기술들은
취약점의 문제점이 공개되거나 공격 패턴이 형성되는 순간(N-day 전환 이후),
사람보다 훨씬 빠르게 탐지·차단을 수행할 수 있다.

따라서 문제 삼아야 할 대상은
특정 보안 솔루션의 존재 자체가 아니라,
“모든 위협을 사전에 막을 수 있다”는 과장된 마케팅 메시지다.

필자의 견해로 보더라도,
상당수 보안 사고의 시작점이 사용자 행위에서
비롯되는 경우가 많은 것 역시 사실이다.

여기서 말하는 사용자 행위란 다음과 같은 경우를 포함한다.

• 악성 프로그램 또는 파일을 설치·실행하는 행위
• 전송자가 불분명한 링크에 접속한 뒤 로그인하거나 개인정보를 입력하는 행위
• 보안 정보를 제 3자에게 전달 혹은 확인 가능한 곳에 메모하는 행위
• 사용자가 임의로 보안 설정을 변경하는 행위
  • 방화벽 비활성화
  • 백신/보안 솔루션 비활성화 등
  • 커스텀 펌웨어 (CFW) 포팅

이러한 행위는 시스템의 기본 방어선을 무력화 시키거나,
공격자가 의도한 흐름을 스스로 완성해 주는 결과로 이어지는 경우가 많다.

이건 수천억원에 해당하는 보안 솔루션을 구매하고
사용한다고 해결이 되는 문제가 아니다.

이들은 침투 자체를 완벽히 막지 못하더라도,
피해의 확산을 제한하고 이상 행위를 조기에
포착하는 데 중요한 역할을 한다.

이 때문에 AI 보안이든, 보안 솔루션이
없는 것보다는 있는 편이 분명히 낫다.

다만, 전문가를 자처하거나 보안 솔루션을 설명하는 입장이라면,
막연한 공포를 조장하기보다

무엇이 실제 문제인지,
각 위협에 대해 어떤 대응이 현실적인지를
명확히 구분해 전달하는 것이 옳다고 본다.

8. 그렇다면 왜 ‘링크 공포’가 문제인가

“링크만 눌러도 해킹된다”는 설명은:

• 공포는 주지만
• 실제 원인(DB 유출 + 비밀번호 재사용)은 가리고
• 사용자가 바꿀 수 있는 행동을 알려주지 않는다

그 결과:

• 사용자는 잘못된 지점을 경계하고
• 진짜 중요한 습관은 그대로 유지된다

9. 그래서 진짜 중요한 보안 습관은 무엇인가

참고용으로

화이트 해커로 활동 중인 노멀틱 유튜버님의
영상을 참조 영상으로 가져왔습니다.

해당 사례 뿐만 아니라, 많은 보안 지식이 업로드 되니,
다양한 보안 취약점 참고 자료도 유용합니다.

대응 방법으로 바로 이어지는 시간대로 고정했으니 참조하면 됩니다.
대응법 영상의 앞 내용은 필자가 주장하는 내용과 비슷합니다.

1️⃣ 비밀번호 재사용 금지 (가장 중요)

• 한 서비스가 털리면 끝이 아니라
• 겹쳐 쓴 모든 계정이 연쇄적으로 열린다

이건 사용자가 유일하게 직접 통제 가능한 영역이다.

2️⃣ 서비스별 비밀번호 분리

• 이메일 / 금융 / 업무 계정 → 완전 분리
• 외부 인증 수단으로 쓰는 계정 보안 관리
• 쇼핑몰 / 커뮤니티 → 별도 그룹

모든 계정을 최고 난도로 관리할 필요는 없지만,
인증 수단으로 쓰는 계정이나, 금융, 업무 등

사용자 생활권에 지장이 갈 수 있는
계정은 반드시 분리·관리되어야 한다.

3️⃣ 주기적 변경은 ‘조건부’

• 모든 계정을 주기적으로 바꾸는 건 현실적이지 않다.
• 대신:
  • 유출 이력이 잦은 서비스
  • 소규모 업체
  • 보안 신뢰도가 낮은 곳 위주로 변경하는 게 효과적이다.

4️⃣ 보안 업데이트는 ‘상시’

비밀번호만 바꿔도, 환경이 취약하면 의미가 없다.
운영체제·브라우저·앱의 보안 업데이트는 공격면 자체를 줄이는 가장 기본적인 대응이다.

• 운영체제(OS) 최신 보안 패치 유지
• 브라우저 및 확장 프로그램 업데이트
• 자주 사용하는 앱·클라이언트 보안 패치 적용
• 더 이상 업데이트 되지 않는 소프트웨어 사용 중단

보안 업데이트는 사용자 행위와 무관하게 악용될 수 있는 취약점(브라우저·커널·라이브러리)을 줄이는 수단이며,

제로데이 대응은 불가능해도 N-day 공격은 대다수 차단 가능하다.

5️⃣ 2단계 인증(2FA/MFA) 필수 적용

비밀번호는 유출을 전제로 설계된 인증 수단이다.
단일 요소(비밀번호)만으로 계정을 보호하는 구조는 현재 위협 환경에서 충분하지 않다.

• 모든 주요 계정에 2단계 인증 활성화
  • 이메일 계정 (최우선)
  • 클라우드 서비스, 개발자 계정
  • 메신저, SNS, 금융·결제 계정
• SMS 기반 인증은 보조 수단으로만 사용
  • 가능하면 OTP 앱(TOTP) 또는 보안 키(FIDO2) 사용
• 백업 코드 안전 보관
  • 계정 탈취보다 복구 실패가 더 치명적인 경우 존재
• 관리자·중요 계정은 MFA 강제
  • 일반 사용자와 동일한 인증 정책은 위험

2단계 인증은

• 비밀번호 재사용
• 피싱
• 크리덴셜 스터핑
  과 같은 계정 탈취 공격의 성공률을 구조적으로 낮춘다.

공격자가 비밀번호를 확보하더라도,
추가 인증 요소 없이는 계정 접근이 차단되는 구조가 되어야 한다.

6️⃣ 해외 IP 접속 차단 (지역 기반 접근 통제)

대부분의 계정 탈취·무차별 대입·봇 공격은
사용자의 생활권 밖(해외 IP) 에서 발생한다.

정상 사용 지역이 명확한 경우,
해외 IP 차단은 공격 표면을 물리적으로 축소하는 매우 효과적인 통제 수단이다.

• 로그인·관리 페이지 해외 IP 차단
  • 관리자 콘솔
  • VPN 미사용 환경의 개인 계정
• 국가 단위 GeoIP 차단 적용
  • 사용하지 않는 국가 전체 차단
• 해외 접속 발생 시 알림 또는 추가 인증
  • 완전 차단이 어려운 경우 보조 통제
• 서버·클라우드·NAS·라우터 관리 포트 차단
  • SSH / RDP / Web Admin 페이지
• CDN·방화벽·라우터 단에서 우선 차단
  • 애플리케이션 이전 단계에서 차단하는 것이 이상적

해외 IP 차단은

• 크리덴셜 스터핑
• 자동화 봇 스캔
• 취약 서비스 무작위 탐색
  과 같은 대량 공격을 초기에 제거한다.

한계 및 주의점 (객관적 관점)

• VPN·프록시 사용자는 우회 가능

해외 IP 차단은 만능 대책은 아니지만,

• 보안 업데이트
• 2단계 인증
  과 결합될 경우 공격 성공 확률을 급격히 낮추는 방어 계층이 된다.
  • 따라서 2단계 인증(MFA)과 병행 필요
• 출장·해외 체류 시 접근 불가
  • 임시 예외 규칙 또는 VPN 정책 필요
• GeoIP 오탐 가능성
  • 차단 로그 기반 점검 필요

7️⃣ 검증된 기관의 보안 솔루션 병행 사용 (현실적 보완 수단)

해외 IP 차단은 매우 효과적인 1차 통제 수단이지만,
단독으로 모든 위협을 차단할 수 있는 만능 해법은 아니다.

VPN·프록시·탈취된 국내 IP를 활용한 우회,
정상 사용자 행위를 모방한 저속 공격,

이미 내부에 침투한 이후의 횡적 이동(Lateral Movement) 등은
지역 기반 차단만으로는 대응이 어렵다.

이 때문에 현실적인 보안 환경에서는 영상에서 주장하는,
검증된 기관의 보안 솔루션을 ‘보조 계층’으로 병행하는 방식이 일반적이다.

대표적인 보완 영역은 다음과 같다.

• WAF(Web Application Firewall) 서비스 제공자 입장
  • 비정상적인 로그인 패턴, 자동화 공격, 알려진 공격 시그니처 차단
  • 크레덴셜 스터핑·봇 트래픽·취약 API 호출 방어
• 로그·이벤트 기반 모니터링(SIEM/UEBA)
  • 로그인 실패 패턴, 인증 우회 시도 상관 분석
  • 단일 이벤트가 아닌 연속된 행위를 위협으로 판단
• 백신 및 EDR / XDR 사용자 입장
  • 침투 이후 행위 기반 탐지
  • 해킹툴 & 악성 프로그램 설치 사전 차단
  • 계정 탈취 이후 발생하는 이상 프로세스·권한 상승·횡적 이동 탐지
• 계정 보호(Account Protection) 솔루션
  • 로그인 시도 행위 분석
  • 비정상 위치·속도·디바이스 변경 탐지
  • 위험 점수 기반 추가 인증 또는 차단
• Anti-Phishing / Anti-Spam 솔루션
  • 스팸 메일 차단
  • 피싱 URL·첨부파일 탐지
  • 발신자 위조(Spoofing) 탐지
  • BEC(Business Email Compromise) 방어
  • 문자 내 URL·번호 패턴 분석
  • 악성 링크 사전/행위 기반 탐지
  • 메신저 기반 사기 탐지

중요한 점은,
이러한 솔루션들의 목적이 “침입을 100% 막는 것”이 아니라
공격 성공 확률을 낮추고, 침투 이후 피해를 제한하는 데 있다는 것이다.

즉,

• 해외 IP 차단 → 공격 표면 축소
• MFA → 자격증명 탈취 무력화
• 보안 솔루션 → 우회·침투 이후 행위 탐지

이 세 가지가 결합될 때,
공격자는 더 많은 시간·자원·위험을 감수해야 하며
대량 자동화 공격의 경제성이 급격히 무너진다.

보안은 단일 기술이 아니라
여러 개의 불완전한 방어선을 겹쳐 두는 문제이며,
검증된 기관의 보안 솔루션은 그 방어선을 현실적으로 두껍게 만드는 수단에 가깝다.

다만 한 가지 더 주의할 점이 있다.
보안 솔루션은 많다고 항상 좋은 것이 아니다.

여러 개의 보안 솔루션을 무분별하게 병행할 경우,

• 이벤트 중복 수집으로 인한 오탐(False Positive) 증가
• 상호 간섭으로 인한 정책 충돌
• 경보 피로(Alert Fatigue)로 인한 실제 위협 대응 지연
• 운영 복잡도 증가로 인한 관리 공백

과 같은 문제가 발생할 수 있다.

따라서 보안 솔루션은
개수가 아니라 역할 분담과 연계 설계가 중요하며,
환경과 위협 모델에 맞춰 필요한 계층만 선택적으로 배치하는 것이 바람직하다.

보안은
“많이 깔아두는 것”이 아니라,
감시 동선을 과도하게 방해하지 않으면서도,

빈틈이 생기지 않도록
방어선을 어떻게 배치할지 결정하는 문제에 가깝다.

10. 정리

현실을 기준으로 보면 결론은 단순하다.

• 대부분의 해킹 피해는
  속아서 당한 게 아니라, 겹쳐 써서 열린 것
• 크레덴셜 스터핑이든 CSRF든
  ‘접속만으로 해킹되는 수법’은 아니다
• 제로데이는 존재하지만
  지속적·상시적 대중 피해의 주범은 아니다.
• 가장 중요한 보안 습관은:
  • 비밀번호 재사용 금지
  • 계정 분리
  • 최상위 계정 보호
  • 검증된 기관의 보안솔루션 사용
  • 보안 솔루션 사용 시 역할 중복 금지

마무리 한 문장

요즘 해킹은
‘클릭해서 당하는 문제’가 아니라
‘같은 비밀번호를 여러군데 겹쳐 써서 생기는 일이다.’

보안은 편해질수록 약해지고,
불편해질수록 강해진다.
그 불편함이 곧 공격자가 지불해야 할 비용이다.

또한 세상에는 완벽한 보안은 없다.