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

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

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

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

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

영상 내에서는
대부분 위 문구처럼 대본을 쓴다.

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

만약 저 방식이 실제로 가능했다면,
지금 이 사이트에 들어와 이 글을 보고있는 독자들은

이미 해킹이 되어있는 상태라는 것이다.
아예 불가능한 것은 아니지만,

그렇다고 과하게 생각할 필요성이 없다는 것을
전달하고자 한다.

이 글에서는

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

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

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

현실에서 대다수의 계정 탈취는 아래 구조를 따른다.
쇼핑몰을 예시로 들자면

• 사용자 DB 구조 예시
  • 사용자 이름
  • 주민등록번호
  • 연동된 서비스(카카x톡, 네x버, 다x, 구x, 페이x북, 인스x램) 프로필
  • 전화번호 & 계좌번호
  • 카드 정보
  • 구매 이력 & 결제 이력
  • 관심 목록 이력
  • 집 주소 & 직장 주소
  • 생년월일
  • 이메일 & 아이디
  • 비밀번호(암호화 된 값)
    
• 데이터 보관 사유
  • 계정 소유자 확인
  • 서비스 이용 현황 제공
  • 결제 프로세스
  • 배송 프로세스
  • 마케팅 정보 제공
  • 기타 서비스 제공

와 같은 이유로 기업이 사용자에게 핵심 서비스 및 마케팅 정보를
제공하기 위해 불가피하게 저장된다.

때문에 일반적으로,
국내외 현행법으로도 해당 데이터는

자격이 지정된 보안 책임자(관리자)의 관리 하에

주민등록번호는 원칙적으로 보관이 제한되며,
카드정보는 암호화·토큰화 등 보호조치를 거쳐 관리된다.

비밀번호는 단방향 해시로 저장되고,
기타 개인정보는 접근 통제와 최소 수집 원칙이 적용된다.

이러한 이유로, DB 자체가 유출되었다고 해서
즉시 모든 계정이, 금융 피해로 이어지지는 않는다.

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

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

이는 단발적으로 일어나는 문제점이 아닌
인터넷 문화가 도입된 이후부터 지금까지도
지속적으로 일어나던 문제였다.

또한, 기업과 사용자는 이를 즉시 탐지하기 어렵고
언론과 SNS에 보도되는 사건·사고들은 빙산의 일각일 뿐이다.

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

① 수집·법적 준수 단계의 문제

• 필요 이상의 사용자 데이터 수집

② 저장·처리 단계의 기술적 문제

• 민감 데이터의 평문 보관
• 보안 정책 및 패치 업데이트 미흡
• 지정된 DB 외 경로를 통한 데이터 유출

③ 접근 통제·권한 관리 문제

• 접근 통제 부재 (별도 접근 승인 및 차단수단)
• 보안 책임자가 아닌 제3자의 DB 접근

④ 조직·운영 구조상의 문제

• 보안 책임자 지정 없이 운영만 이루어지는 구조
• 현행 개인정보 보호 관련 법령 미준수

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

서비스 제공자가 가진 데이터를 훔쳐오는 것이다.

쉽게 말해,
공격자가 기업 서버를 공격해서

탈취한 DB 데이터를 열람하고,
사용자 정보가 들어있는 데이터 테이블의 구조를 파악하게 되면

• 사용자가 어떤 타사 서비스들을 사용하고 있을 가능성이 높은지
• 어떤 비밀번호를 다른 사이트에 재사용하고 있을지
• 기입 된 정보를 토대로 타사 시스템에서 추가적으로 수집
• 이 사람이 사이트를 통해 최근 어떤 행위를 했는지
• 이 사람 성별이 무엇이고
• 이 사람 이름이 무엇이고
• 어디에 거주하고
• 해당 주소지에 몇명이 거주 중인지
• 연령대가 어느정도인지
• 이 사람의 관심사가 무엇인지

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

공격자는 이 정보를 토대로

사용자 비밀번호를 암호화 되어 알지 못한다 하더라도
다양한 수법을 통해 로그인 시도를 하거나,

관심사, 연령, 주소, 연락처 정보를 이용해

• 로맨스 스캠
• 관공서 사칭
• 수사기관 사칭
• 배송 기사 사칭
• 피싱·스팸 메일
• 금융기관 사칭
• 지인 사칭

등 피싱이라는 수법으로 사용자의 혼란을 유도해 정보를 탈취하는데
큰 도움을 준다.

결국 DB 탈취는 후속 단계를 위한
하나의 연계 과정이라 보면 된다.

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

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

정확히 말하면,
마스터 키를 꽂는다는 표현은

공격 대상에
악성 코드나 해킹 툴을 설치해
기기 자체를 침투·장악하는 공격에 더 가깝다.

[출처]
Verizon, 2024 Data Breach Investigations Report (DBIR)에서는 대다수의 계정 침해가 단일 취약점이 아닌 DB 유출, 자격증명 재사용, 크레덴셜 스터핑, 사회공학 공격의 결합으로 발생한다고 분석하고 있다.

특히 초기 침투 단계(Action)에서 “Use of stolen credentials”가 가장 빈번하게 관측되는 요소로 보고된다 DBIR 2024, Actions & Initial Access 섹션, Figure 15 / Figure 18.

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

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

• 과거 기업에서 유출된 혹은 피싱 사이트에서 입력 된
  • 이메일 / 아이디
  • 비밀번호
  • 주민등록번호
  • 전화번호
• 이 자격 증명을 공격자가 자기 서버에서 보관하고
• 평문으로 유출 된, 해커가 대입해서 평문으로 바꾼 계정 정보를 이용
• 다른 사이트의 정상 로그인 API에 자동 대입
• 로그인 성공 시 해당 계정 장악
• 금전 및 2차 피해발생

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

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

즉,

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

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

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

“URL에서 로그인으로 연결되는 형식을 경계하라”는 설명은

피싱 사이트에서 사용자 로그인을 통해 유출 된 정보로
크레덴셜 스터핑 공격 시도 중 하나를
차단하는 방법일 순 있으나,

많은 기업 중에서 유출 된,
해커들이 암시장에서 실제 거래되고 있는 정보에 대한
크레덴셜 스터핑의 본질적인 대응은 아니다.

크레덴셜 스터핑은
URL을 통한 피싱 과정에서만 해당되는 내용이 아니라는 말이다.

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

[출처]
ENISA는 크레덴셜 스터핑을 “이미 유출된 자격증명을 자동화 도구를 통해 다른 서비스의 정상 로그인 인터페이스에 대입하는 공격”으로 정의하며, 피해자가 링크를 클릭하거나 해당 서비스에 접속하지 않았더라도 공격이 성립할 수 있음을 명시한다.
(ENISA Threat Landscape – Credential-based Attacks 섹션)

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

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

현실적으로 보면:

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

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

일반적인 피싱 사이트 기준으로
아래 행위를 했을 때 실제 계정 정보가 해커에게 유출이 된다.

[출처]
Verizon DBIR와 ENISA 보고서 모두, 피싱을 단독 주 공격 경로라기보다는 이미 확보된 정보의 보완, 고가치 표적 공격, 2차 인증 우회 시도 등에 활용되는 보조·확정 수단으로 분류한다.
대규모 피해의 주 원인은 자격증명 재사용과 자동화 공격임을 반복적으로 강조한다.
(Verizon DBIR 2024, Social Engineering / Credentials 섹션)

3. 사용자 과실로 인한 유출과정

계정 침해 준비상태

• 피싱 페이지 접속 유도 (sms, 이메일, 전화로 유도)
  • 준비 단계 (단순 접속)
  • 계정 침해 없음
  • 시스템 침해 없음

※ 유튜버들이 설명하는 솔루션은
해당 준비 단계에서

이미 알려진·신고된 URL 접근을 사전 차단하는 데에는 효과적이나,
자격증명 입력 이후 단계까지는 직접적으로 막아주지 못함

계정 침해 상태

• 피싱 페이지 내에서 개인정보 입력 후
  로그인 및 전송버튼 클릭
  • 계정 침해 상태
  • 자격증명 탈취만 된 상태
  • 시스템은 침해 없음

※ 계정 탈취 후 공격자가
로그인까지 성공한다면, 피해 확산 가능함,

탈취 된 계정명의로
연락처 내 3자에게 피싱 링크 추가 전달
(내 명의로 지인에게 전달되므로
URL 링크 전달보다 파급력이 매우 큼)

시스템 침투 시도

• 피싱 사이트에서 애플리케이션 설치 파일 다운로드
  • 정상 애플리케이션으로 사용자 속여 다운로드 유도

※ ​다운로드 행위로 운영체제 권한·지속성·원격 제어가 확보되지 않음

권한 상승

• 해커 시스템 권한 장악 시도
  • 관리자 권한 / SYSTEM 권한 획득 (사용자 행위 유도)
  • 백신 무력화 시도 (사용자 행위 유도)

※시스템이 '이 앱은 위험할 수 있습니다'라고 경고하거나
백신의 실시간 감시를 비활성화를 해달라고 요구하거나,

'접근성 및 관리자 권한'을 요구할 때 멈춘다면,
시스템 침해라는 최악의 상황은 회피가능

악성 코드 실행

• 다운로드 된 백도어 애플리케이션 실행
  • 사용자가 직접 실행
  • 보안 솔루션이 차단하지 못 할 경우
  • 공격 코드가 정상 프로세스로 동작

※ 여기서 부터는 우리가 아는
백신들이 담당하는 영역이며,

실시간 감시 무력화 상태,
백신 DB에 없는 악성코드 일 경우, 백신도 차단 불가

이 단계부터 시스템 침해 확정

사후 침투 활동

• 사용자 정보 수집 및 통제
  • 지속성 확보
  • Host 위조 (피싱 사이트로만 이어지도록)
  • 메신져 및 통화 기능 마비,위조 (피싱 사실 3자 전파차단)
  • 정보 탈취 (공격을 더 강화하기 위한 단계)
  • 2차 인증 무력화
  • 추가 공격 준비 (금전, 목적 달성을 위한 단계)

경우에 따라 아래 행위까지 진행

• 사용자 감시 및 랜섬웨어 감염 (추가 금전요구)
• 시스템 파일 손상이나 포멧 실행
• 연락처 내 3자에게 피싱 링크 추가 전달
  (내 명의로 지인에게 전달되므로
  URL 링크 전달보다 파급력이 매우 큼)

※ 실제 피해 발생

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

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

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

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

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

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

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

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

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

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

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

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

피싱이라는 고전적이지만 효과적인 공격 방식에서 발생하고 있다.

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

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

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

때문에 금융·사기 범죄에서는
피싱을 여전히 핵심 수단으로 사용하는 이유이다.

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

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

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

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

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

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

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

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

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

3-4. 그럼 뉴스에서 ‘복호화’를 한다는건 무엇인가?

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

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

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

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

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

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

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

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

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

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

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

TISTORYadjh54

3-5. 그럼 대입과 매칭이 어떻게 이루어지는가?

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

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

공격 흐름은 다음과 같다.

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

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

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

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

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

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

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

[출처]
NIST SP 800-63B는 비밀번호가 복호화되는 것이 아니라, 해시값 비교 및 대입 공격을 통해 추정된다는 점을 명확히 설명하며, 비밀번호 재사용과 약한 패스워드가 계정 침해의 가장 큰 위험 요소라고 규정한다.

3-7. 때문에 ‘쉬운 비밀번호’는 즉시 털린다

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

레인보우 테이블:

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

Salt가 있어도:

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

브루투 포스방식:

• 별도 로그인 반복 시도에 대한 제제가 없고
• 패스워드가 단순하다면
• 사람들이 주로쓰는 패스워드 패턴을 입력

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

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

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

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

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

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

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

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

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

[출처]
OWASP는 사전 기반 공격(Rainbow Table)과 브루트 포스 공격이 여전히 현실적인 위협이며, 공격의 핵심은 “비밀번호를 푸는 것”이 아니라 공격 비용을 낮추는 것이라고 설명한다.
(OWASP Authentication Cheat Sheet)

3-8. 그래서 사회공학 공격이 병행된다

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

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

따라서 연산 비용이 큰 해시 대입 공격이나,
탐지·차단 위험이 높은 브루트 포스(Brute Force Attack)를
무한정 시도하기보다는,

크레덴셜 스터핑(Credential Stuffing)과 함께,
사회공학(Social Engineering) 기반 공격 병행하게 되는 것이다.

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

4.그럼 실제 클릭만으로 가능한 취약점은 없는가?

“링크만 눌러도 해킹된다”는 주장에는
완전 없다고는 할 수 없다.

다만 이 부분은,

현대화 된 웹사이트 환경에는
조건을 만족하기가 어렵고,

작은 규모의 해커가 시도하기는 어렵다는 사실이다.
또한

유튜버가 영상에서 설명한 기법은
사용자 부주의 보다는 서비스 제공자(서버) 측
보안이 필요한 부분이라는 점이다.

열람만으로 실제 해킹이 가능한 취약점으로는 많은 수법이 있으나,
두 가지 사항만 예로 놓고 설명하겠다.

CSRF(Cross-Site Request Forgery) 와
XSS(Cross-Site Scripting) 다.

4-1. 서비스 제공자 측 취약점

이 부분은 사용자 과실로 생겨나는 문제점이 아니다,

그 이유로는,
서버는 요청이 정상 사용자에 의해 발생했는지,
악성 코드·자동화 스크립트·감염된 브라우저에 의해 발생했는지를
기술적으로 구분할 수 없다.

모든 요청은 동일한 HTTP 요청 형태로 도착하며,
서버가 판단할 수 있는 것은,

요청의 의도가 아니라 서버가 직접 검증 가능한 조건뿐이다.

이 때문에 서버는 사용자 행위나 상태를 신뢰하지 않고,
항상 불신을 기본값으로 두는 구조로 설계·운용된다.

CSRF와 XSS는 이러한 불신 전제가
설계·구현 단계에서 지켜지지 않았을 때 발생하는 대표적인 취약점이다.

[출처]
2021 OWASP Top 10에서는 CSRF와 XSS를 사용자 부주의 문제가 아닌 서버·애플리케이션 설계 및 구현 실패로 분류하며, 현대적 방어가 적용된 환경에서는 단순 링크 클릭만으로 민감한 상태 변경이 성립하기 어렵다는 점이 OWASP의 분류·대응책 설명으로부터 도출된다.

4-2. CSRF는?

CSRF의 핵심은 ‘이미 로그인된 세션을 서버가 과신하는 구조’

정확히 말하면 CSRF는 다음 구조를 악용한다.

• 서버가 요청(Request)을 처리할 때
  • 이 요청이 어느 페이지에서 시작됐는지
  • 사용자가 정말 의도한 행동인지를 확인하지 않고
• “로그인된 세션에서 온 요청이니까 정상”이라고 처리하는 경우

이 공격에서 공격자는:

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

이미 로그인된 브라우저가
자동으로 요청을 보내도록 유도하는 것만으로 충분하다.

“링크 클릭만으로 CSRF가 된다”는 설명이 부정확한 이유

현대적인 웹 서비스에서
CSRF 방어가 제대로 적용되어 있다면,

• 단순히 링크를 클릭했다는 이유만으로
• 즉시 송금, 설정 변경, 탈퇴 같은
  민감한 상태 변경 요청이 처리되는 경우는 극히 제한적이다.

일반적으로는 다음 조건이 추가로 필요하다.

• 로그인 세션이 유지된 상태에서
• 사용자의 추가 행위
  (폼 제출, 버튼 클릭, 자동 전송되는 요청 등)
• 그리고 서버가
  해당 요청이 자기 서비스 내부에서 발생했는지를 검증하지 않는 경우

이 조건들이 겹쳐야만,
다른 사이트에서 유도된 요청이
서버의 중요한 기능으로 처리될 수 있다.

4-3. XSS 는?

XSS(Cross-Site Scripting)는

서버가 신뢰할 수 없는 입력을 적절히 검증·처리하지 못했을 때,
브라우저가 해당 웹사이트의 권한(신분) 으로
악성 스크립트를 실행하게 되는 취약점이다.

여기서 말하는 “웹사이트의 권한”이란,
주소(도메인)가 같은 정상 서비스 내부에서 실행되는 것처럼
브라우저가 스크립트를 신뢰해 버리는 상태를 의미한다.

XSS의 근본 원인은 다음과 같은 구현·설계 문제에 있다.

• 입력값 검증(Input Validation) 미흡
• 출력 시 인코딩(Output Encoding) 누락
• Content Security Policy(CSP) 미적용 또는 부실
• 위험한 DOM API 사용 (innerHTML, document.write 등)
• 세션 토큰을 JavaScript에서 접근 가능한 위치에 저장

이 항목들은 모두
사용자가 선택하거나 통제할 수 없는 영역이며,

사용자의 보안 습관과 무관하게
서버·프론트엔드 구현 책임에 해당한다.

4-4.“클릭만으로 실행되는 XSS”가 존재하는 경우

일부 환경에서는

• Stored XSS
• 자동 실행되는 Reflected XSS

와 같이,
링크 클릭 또는 페이지 접속만으로
스크립트가 실행되는 경우도 존재한다.

이 경우에도 사용자는
정상적인 웹페이지를 열었을 뿐이며,
“부주의하게 클릭해서 당했다”기보다는
서버가 악성 스크립트를 정상 코드처럼 내려보낸 것에 가깝다.

4-5. 그렇다고 해서 “즉시 계정 탈취”가 되는 것은 아니다

중요한 점은 다음이다.

• XSS는 해당 웹사이트 내부에서만 동작하며
• 현대적인 웹 서비스에서
  • HttpOnly / SameSite 쿠키
  • CSP
  • 세션 분리
• 서버 측 보안이 정상적으로 설계·운영된다는 전제하에,
  다른 서비스나 다른 계정의 로그인 정보까지 즉시 탈취되는 구조는 아니다.

즉, CSRF, XSS는
‘클릭 한 번으로 모든 계정이 바로 털리는 공격’이 아니라,
서버 보안 설계가 실패했을 때만 성립하는 취약점이다.

4.6 그래서 이 표현이 부정확한 이유

“링크를 눌러서 해킹 당했다”

라는 설명은,

• 공격의 실제 원인(서버 구현 결함) 을 가리고
• 사용자가 경계해야 할 지점을 잘못 안내하며
• 실제 대응 지점(6문단)을 흐린다

기술적으로도, 책임 모델 측면에서도 정확하지 않다.

4-7. 그럼 제로데이 수법은?

일부 제로데이 공격은
링크 접속만으로도 계정 정보 탈취나 시스템 침해로
이어질 수 있는 수준에 도달할 수 있다.

다만, 이것은 항상 성립하는 일반적인 상황은 아니며,
명확한 전제와 조건이 붙는 한정적인 경우라는 점을 이해할 필요가 있다.

이러한 공격은

• 사용자만의 문제도 아니고
• 서비스 제공자만의 문제도 아니다.

공격 대상, 환경, 구현 상태에 따라 성립 조건이 달라지기 때문에
특정한 “하나의 방식”으로 일반화하기 어렵다.

이 특성 때문에 제로데이는 종종 신비화되거나 과도한 공포의 대상이 된다.
대표적인 사례로, 한때 큰 이슈가 되었던

RCS 기능 취약점을 이용한 제로클릭 공격(CVE-2024-49415)이 있다.

기사 읽기
출처: 시큐리티월드

간단하게 말하면 이 취약점은 사용자가 확인하지도,
열어보지도 않았고, 상대방에게서 메세지로
이미지만 수신 받았는데

푸시 알람에서 미리보기 이미지를 렌더링 과정 중에
악성 코드가 활성화 된 유형이다.

이는 어떻게 보면 마법 같아 보이지만 비유로 풀면 이해가 쉽다.
영화에서 도둑이 은행을 터는 것을 비유한다면,

건물에는 전기, 물, 배기를 하려면 필수 시설물이 있다.
일반적으로는 사람들이 그곳을 지나다니진 않고,
들어올 거라 생각하지 않는다.

이곳은 사람의 시선이 닿기도 힘들며,
별도의 감시도 강화하지 않는다.

첩보 영화나, 범죄 영화를 보면 거의
클리셰 침임 경로로 쓰는 것과 같이

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

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

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

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

이 상황에서 중요한 점은,

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

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

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

"나 강도입니다" 하며 들어와 금고를 털고
경찰, 언론, 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: 최다
  • 사이버 범죄 조직: 조건부 사용
  • 개인 단독 공격자: 드묾

국가 단위의 정보기관이나 군은
사이버 작전을 수행하기 위해 장기적·지속적으로 제로데이 발굴에 투자한다.
이는 단발성 연구나 개인 역량에 의존하는 활동이 아니라,
국가 안보 전략의 일부로 편성된 체계적인 활동에 가깝다.

이들이 보유한 가장 큰 강점은
개별 해커가 따라가기 어려운 규모와 지속성이다.

국가 기관은

• 다수의 전담 연구 인력
• 대규모 퍼징(fuzzing) 인프라
• 수년 단위로 이어지는 장기 분석 프로젝트
• 실제 공격·방어 환경에서 축적된 운영 데이터

를 기반으로,
운영체제(OS), 웹 브라우저, 통신 프로토콜, 메신저 스택과 같은
현대 디지털 인프라의 핵심 구성 요소를 체계적으로 분석한다.

이 과정에서 목표는 단순한 취약점 발견이 아니다.

• 어떤 취약점이 실전 환경에서 안정적으로 악용 가능한지
• 탐지·추적 가능성을 얼마나 낮출 수 있는지
• 다른 취약점과 결합해 장기 침투가 가능한지

와 같은 작전 수준의 활용 가능성이 함께 평가된다.

국가 주도의 제로데이 발굴은
대개 다음과 같은 목적을 가진다.

• 적국 또는 특정 대상에 대한 정보 수집
• 사이버 첩보 및 감시 활동
• 분쟁 상황에서의 비대칭 전력 확보
• 자국 인프라 방어를 위한 공격 시나리오 사전 검증

이 때문에 국가가 보유한 제로데이는
무차별적으로 사용되지 않으며,
외부에 노출될 경우 외교·정치적 파장이 뒤따를 수 있다는 점까지
계산에 포함된다.

또한 국가 기관은
자신들이 발견한 취약점 중 일부를
의도적으로 공개하거나 벤더에 전달하기도 한다.
이는 공격 능력 확보와 방어 역량 강화 사이에서
전략적 판단에 따라 선택적으로 이루어진다.

결국 국가 단위의 제로데이 발굴은
“해킹 기술 과시”가 아니라,
사이버 공간에서의 정보 우위와 전략적 선택지를 확보하기 위한
장기적 투자 활동에 가깝다.

상업 익스플로잇 기업 역시 제로데이 생태계에서 중요한 축을 차지한다.
이들은 제로데이 취약점을 발굴한 뒤,
이를 정부 기관이나 법집행 기관에 합법적으로 판매하는 사업 모델을 가진다.

이들의 활동은 흔히 오해되지만,
무작위 해킹이나 범죄 행위와는 성격이 다르다.
상업 익스플로잇 기업은 명확한 계약 관계와 법적 틀 안에서
취약점과 익스플로잇을 제공하며,
주요 고객 역시 국가 기관에 한정되는 경우가 대부분이다.

이들이 집중적으로 연구하는 대상은 공통점이 있다.
바로 대중적으로 널리 사용되며,
단일 취약점이 미치는 영향 범위가 매우 큰 플랫폼들이다.

대표적으로는

• 모바일 메신저
• 운영체제(OS)
• 웹 브라우저
  와 같은 핵심 인프라가 주요 대상이 된다.

이러한 플랫폼은
사용자 수가 많고,
업데이트 주기가 상대적으로 느리거나,
하위 호환성·복잡한 구조로 인해
취약점이 장기간 유지될 가능성이 높다.

상업 익스플로잇 기업은
이론적인 취약점 제보에 그치지 않고,
실제 작전 환경에서 사용 가능한 수준의
안정적인 익스플로잇 체인을 구성하는 데 초점을 둔다.

즉,

• 특정 OS·기기 조합에서 재현 가능하고
• 반복 실행 시 성공률이 높으며
• 실패 시에도 탐지·노출 가능성이 낮은
  현실적인 공격 수단을 제공하는 것이 핵심이다.

이 때문에 이들이 발굴한 제로데이는
단순한 기술적 호기심의 산물이 아니라,
국가 차원의 정보 수집·수사·대테러·첩보 활동에 사용될 것을 전제로 설계된 자산에 가깝다.

다만 이 영역 역시 논란에서 자유롭지는 않다.
취약점이 공개되지 않은 채 장기간 보유될 경우,
해당 취약점이 제3자에게 먼저 악용될 위험이 존재하며,
“공공 안전”과 “보안 투명성” 사이의 균형 문제는
지속적으로 논쟁의 대상이 되고 있다.

그럼에도 분명한 점은,
상업 익스플로잇 기업이 다루는 제로데이는
무차별 공격이나 일반 범죄에 사용되기보다는,
고가치·고위험·고통제 환경에서 제한적으로 사용되는 자산이라는 것이다.

상급 블랙해커 또한 제로데이 취약점을 직접 발굴한다.
다만 이들 역시 개인 단독으로 활동하는 경우는 드물며,

대부분은 조직화된 사이버 범죄 그룹에 소속되거나
국가 단위의 직·간접적 후원을 받는 형태로 움직인다.

제로데이 발굴에는
고성능 퍼징 인프라, 장기간 분석 인력,
운영체제·브라우저·프로토콜 수준의 깊은 이해가 필요하다.

이러한 비용 구조 때문에,
무작위 범죄자나 소규모 개인 공격자가
지속적으로 제로데이를 발굴하는 것은 현실적으로 어렵다.

이들이 제로데이를 발굴하는 목적은 명확하다.
금전적 이익, 정보 탈취, 지속적인 침투 유지,
또는 특정 목표에 대한 고가치 공격 수행이다.

발굴된 제로데이는 다음과 같은 방식으로 활용된다.

첫째,
다크웹이나 암시장(Exploit Market)에서
고가의 자산으로 거래된다.

제로데이는 희소성이 높고,
노출되는 순간 가치가 급격히 하락하기 때문에
구매자는 제한적이며 가격은 매우 높게 형성된다.

둘째,
판매되지 않고 특정 공격 캠페인에 제한적으로 사용되기도 한다.
이 경우 공격자는

• 사용 횟수를 극도로 제한하고
• 특정 대상, 특정 환경에서만 사용하며
• 공격 성공 이후에도 즉각적인 흔적 제거와 은폐를 수행한다

이는 제로데이가 “강력해서”가 아니라,
노출되면 곧바로 패치·차단·수사로 이어진다는 사실을
공격자 스스로도 잘 알고 있기 때문이다.

따라서 상급 블랙해커에게 제로데이는
무차별적으로 뿌리는 공격 수단이 아니라,
한 번 쓰면 사라질 수 있는 고가의 소모성 자산에 가깝다.

상급 화이트 해커 역시 제로데이 취약점을 적극적으로 발굴한다.
다만 이들의 목적과 접근 방식은 블랙해커나 범죄 조직과는 본질적으로 다르다.

화이트 해커에게 제로데이는
무차별 공격을 위한 무기가 아니라,
실제 공격자가 사용할 수 있는 경로를 미리 드러내기 위한 검증 도구에 가깝다.

이들은 단순히 “이론적으로 취약해 보인다”는 수준에서 멈추지 않는다.
공격자가 실제로 어떤 조건에서, 어떤 단계를 거쳐,
어디까지 침투할 수 있는지를 공격자 관점에서 끝까지 시뮬레이션한다.

즉,

• 해당 취약점이 단독으로 악용 가능한지
• 다른 취약점과 체인으로 연결될 수 있는지
• 원격 코드 실행, 권한 상승, 정보 탈취로 이어질 수 있는지
• 특정 환경(OS 버전, 브라우저, 기기 설정)에서만 성립하는지

와 같은 현실적인 공격 성립 조건을 검증한다.

그리고 이 과정의 결과물은
“이 취약점이 존재한다”는 선언이 아니라,
**“이 취약점은 이런 방식으로 악용될 수 있으며,
이를 막기 위해서는 어떤 패치·완화 조치가 필요하다”**라는 형태로 정리된다.

이 때문에 상급 화이트 해커의 제로데이 발굴은
공격 코드 공개가 목적이 아니라,
패치 설계·보안 모델 개선·방어 체계 보강으로 이어지는 경우가 대부분이다.

실제로 많은 경우,

• 벤더에 비공개로 제보(responsible disclosure)되거나
• 일정 유예 기간 이후 기술적 맥락만 제한적으로 공개되며
• 악용 코드가 아닌 구조적 원인과 방어 포인트가 중심이 된다.

결국 화이트 해커가 제로데이를 발굴하는 이유는
“공격을 성공시키기 위해서”가 아니라,
공격이 성공할 수 있는 구조 자체를 사전에 제거하기 위해서다.

서드 파티 개발자나 관련 내부 개발자가 발견하는 제로데이 취약점은
의도적 ‘공격 연구’의 결과라기보다는,
구조 이해 과정에서 파생적으로 드러나는 경우가 많다.

이들은 다음과 같은 맥락에서 취약점을 발견한다.

• SDK, 라이브러리, 플러그인, 드라이버, 미들웨어 개발 과정
• API 연동, 프로토콜 구현, 성능 최적화, 리팩토링 작업
• 레거시 코드 유지보수, 신규 기능 추가

이 과정에서 개발자는:

• 정상 동작만 가정된 코드 경로
• 에러 처리가 누락된 분기
• 권한·입력 검증이 불완전한 인터페이스
  를 직접 마주하게 된다.

즉, 공격자가 의도적으로 찾는 “이상 경로”를
개발자는 정상 기능 구현 중 우연히 지나치게 되는 경우가 많다.

서드 파티 개발자는 다음과 같은 지점을 빠르게 알아차릴 수 있다.

• “이 입력은 외부에서 온다”
• “이 값은 항상 정상이라고 가정하고 있네”
• “이 권한은 호출 주체를 확인하지 않는다”
• “이 인터페이스는 샌드박스 밖과 직접 맞닿아 있다”

이는 공격자가 탐색해야 할 정보를
개발자는 이미 알고 있는 상태에서 작업하기 때문이다.

다만 이들은:

• 공격 체인 구성
• 익스플로잇 안정화
• 은폐·지속성 확보
  와 같은 공격자 관점 연구를 수행하지 않는 경우가 대부분이다.

그래서 많은 취약점이:

• 내부 보고
• 즉시 수정
• 릴리즈 노트에조차 남지 않은 채
  사라진다.

이 때문에 서드 파티·개발자 기여 제로데이는 실제 규모 대비 외부에 거의 드러나지 않는다.

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

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

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

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

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

[출처]
Google Project Zero의 다수 취약점 분석에 따르면, 현대 OS·브라우저 환경에서 실전적인 제로데이 공격은 단일 취약점보다는 원격 코드 실행, 샌드박스 탈출, 권한 상승 등을 연결한 다단계 익스플로잇 체인으로 구성되는 경우가 일반적이다. 이러한 체인은 개발·유지 비용이 높고 노출 시 빠르게 패치되기 때문에, 대규모·상시적 공격보다는 표적 공격에서 주로 관찰된다.

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

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

정상 애플리케이션/OS 의 취약점이나,
아직 알려지지 않은 새로운 기법을 사용하는 것을 말하는 것이다.

• 패치 없음
• 시그니처 없음
• 사전 정보 없음 (악성 URL, 악성코드 정보)

이 상태에서는

• 보안 담당자, 개발자, 사용자
• 룰 기반 백신
• AI 기반 백신

모두 사전 차단을 보장하기 어렵다.
그래서 현실적인 보안의 전제는 이렇다.

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

보안 솔루션의 역할에는 한계가 있는데

침입 자체를 완벽히 막는 것이 아니라,
침입을 최소화 하고, 침투했다 하더라도,
침투 이후의 행동을 빠르게 식별하고 제어하는 데 있다.

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

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

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

반대로 말하면,
완전히 알려지지 않은 제로데이 수법 앞에서는
이러한 탐지 체계조차 제한적으로만 작동할 수밖에 없다.

4-9. 이 논리를 피싱 메시지·URL 차단에 대입하면 무엇이 보이는가

피싱 공격에 사용되는 요소들은 구조적으로 생성 비용이 매우 낮다.

• 가상 전화번호·URL: 쉽게 생성 가능
• SSL 인증서: 자동 발급 가능
• URL 단축·변형·리다이렉션: 상시 가능
• 외형상 정상 URL과 구분 어려움

리다이렉션(Redirection),URL 단축이라는 기능은
일반 정상적인 웹페이지에서도
많이 사용하는 기술이다.

그리고, 공격자는 하나의 URL이
아닌 다수의 URL 자동 생성하고 변형하며 사용한다.

이 때문에 신규 URL에 대해서는
보안 솔루션이나 통신사 역시 즉시 악성으로 단정할 수 없다.

현실적인 차단 흐름은 다음과 같다.

1. 의심되는 URL·메시지 패턴 포착
2. 사용자 또는 패턴 이상 징후 인지
3. 신고·제보 접수
4. 수집·분석
5. 차단 패턴 반영

즉, 전 세계 공격자가 생성하는 모든 URL이
차단 패턴에 반영되기까지는 시간과 데이터 축적이 필요하다.

통신사에서 제공하는 무료 스팸,피싱 차단 부가서비스에도
기본적인 차단 기능은 제공되지만,
보조 수단에 가깝고 완전한 보호를 보장하지는 않는다.

통신사는 다음과 같은 망(Network) 단 정보를 활용할 수 있다.

• 개통 번호·가입자·디바이스 메타데이터
• SMS·음성 통화 메타데이터
• 데이터 패킷 헤더 분석
• 대규모 스팸·피싱 번호·URL 평판 데이터

통신사는 메시지 내용을 직접 확인하지는 못하지만,
발신 번호·가입자 정보·발신 패턴을 기반으로
신고된 번호가 정상 사용자 계정인지,

혹은 스팸 발신 패턴을 보이는
번호인지 빠르게 대조할 수 있다.

이 가시성 범위 때문에,
초기 식별 단계와 대량 차단에서는
통신사가 구조적으로 가시성 범위가 다르다

그러나 이는 만능을 의미하지 않는다.

• 100% 사전 차단은 구조적으로 불가능
• 오탐·오진 가능성 존재
• 대포폰·해킹 등으로 인해 발신자 정보가 실제 공격자와 다를 수 있음
• 사용자 신고 기반
• 정상 메시지 차단이라는 부작용 때문에
  ‘발신 자체 차단’과 같은 강수는 제한적으로만 사용 가능

[출처]

ENISA / GSMA 관련 내용

• **Fraud and Scams: Staying Safe in the Mobile World (GSMA 보고서)** — 보고서에서 온라인 사기·피싱 공격의 특성과 대응 필요성을 설명하며, 단순 차단만으로는 해결이 어렵고 보다 폭넓은 신고·분석·협력 대응이 중요함을 지적합니다.

피싱 URL, SMS·전화 사기 등에 대한 구조적 한계

참고 문서: GSMA의 사이버 보안/사기 방지 설명 자료는 다양한 피싱·사기 유형을 분석하면서, 모바일 생태계에서 공격 인프라가 쉽게 생성되고 이를 방지하기 위한 협력적 대응이 필요하다고 보고합니다.

4-10. 단말 보안 솔루션의 위치는 어디인가

AI 기반 단말 보안 솔루션은 통신사와는 다른 계층에서 동작하는 보완 수단이다.
사용자 기기에 설치되어 다음과 같은 역할을 수행한다.

• 수신된 메시지의 추가 필터링
• 웹·앱 기반 공격 탐지
• 실행 이전 단계에서의 차단
• 사용자 신고 및 행위 패턴 기반 학습

즉, 단말 보안 솔루션은 통신사를 스팸차단 기능을 대체하는 것이 아니라
이중 필터링 계층으로 기능한다.

그러나 이 역시 구조적인 한계를 공유한다.

• 신규 공격에 대한 초기 정보 부족
• 사용자 신고 및 AI 분류 결과에 대한 의존
• 사용자 입력·판단을 신뢰하는 구조

특히 이 구조는 앞서 설명한 CSRF·XSS 사례와 유사하게,
입력 주체(사용자)의 판단을 신뢰하는 설계라는 공통점을 가진다.

따라서 누군가가 고의적으로 정상 메시지를 반복 신고하거나,
집단적으로 신고가 누적되는 경우,

• 단말 보안 솔루션은 발신자의 실명·가입자 정보에 접근할 수 없기 때문에
  신고 대상자의 신원 확인이 어렵고,
• 오탐(False Positive)이 축적될 수 있으며
• 정상 발신자나 메시지에
  ‘피싱 의심’ 또는 ‘피싱 발신자’와 같은 꼬리표가 붙는 문제로 이어질 수 있다

결국 단말 보안 솔루션 역시
100% 정확한 사전 차단 수단이 될 수 없으며,
만약 피싱 발신자로 오인하는 경우에

기업일 경우 정상적인 "마케팅 활동을 방해했다",
일반 사용자일 경우, "보안 솔루션이 날 피싱범으로 만들었다"는
법적 분쟁으로 이어질 가능성도 존재한다.

때문에, 보안 솔루션 어플 역시, 통신사 차단과 마찬가지로
오탐과 미탐 사이의 균형을 고려한 제한적 운용이 불가피하다.

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

여기서 말하는 사용자 행위란,
공격자가 의도한 흐름을 사용자가 직접 완성하게 되는 경우를 의미하며,
다음과 같은 상황을 포함한다.

• 악성 프로그램 또는 파일을 설치·실행하는 행위
• 정품이 아닌 크랙·비공식 소프트웨어 사용
• 전송자가 불분명한 링크에 접속한 뒤 로그인하거나 개인정보를 입력하는 행위
• 보안 정보를 제3자에게 전달하거나, 외부에서 확인 가능한 형태로 보관하는 행위
• 악성 광고를 통해 노출된 출처 불명의 ‘백신·보안 프로그램’ 설치
• 사용자가 임의로 보안 설정을 완화·비활성화하는 행위
  (방화벽, 백신, 보안 솔루션 비활성화 등)
• 커스텀 펌웨어(CFW) 포팅 등 기본 신뢰 체계를 우회하는 행위

이러한 경우, 시스템의 기본 방어선은
기술적 한계가 아니라 사용자 동작에 의해 무력화되며,
이는 공격자가 설계한 침투 시나리오가 완성되는 지점에 해당한다.

따라서 이 영역은
보안 솔루션의 규모나 비용만으로 해결될 수 있는 문제가 아니며,
사용자 인식·행위 통제와 기술적 방어가 함께 작동해야만 위험을 실질적으로 낮출 수 있다.

따라서 문제 삼아야 할 대상은
특정 보안 솔루션의 존재 자체가 아니라,

“모든 위협을 사전에 막아준다”는
과장된 마케팅 메시지다.

전문가를 자처하거나
보안 솔루션을 설명·판매하는 입장이라면,

• 막연한 공포를 조장하기보다
• 무엇이 실제 문제인지
• 어느 단계까지 방어가 가능한지
• 어떤 부분은 구조적으로 방어가 어려운지
• 사용자에게 요구되는 기본 수칙은 무엇인지까지

정확히 구분해 전달하는 것이 바람직하다.

5. 그렇다면 왜 ‘링크 공포(Link Fear)’가 문제인가

“링크만 눌러도 해킹된다”는 설명은 직관적으로는 강한 경고처럼 보이지만,
실제 보안 관점에서는 다음과 같은 구조적 문제를 가진다.

• 공포는 증폭시키지만, 행동 변화를 유도하지 못한다
  • 사용자는 ‘링크 자체’를 위험 요소로 인식하게 되지만,
  • 실제로 가장 큰 피해를 유발하는
    비밀번호 재사용, 인증 수단 관리 부실, 계정 분리 실패에는 변화가 없다.
• 공격의 실제 원인을 가린다
  • 다수의 실제 사고는
    DB 유출 + 자격증명 재사용 + 자동화 공격 + 사회공학의 결합으로 발생한다.
  • 그러나 “링크 클릭”으로 원인을 단순화하면,
    • 서버·인증 설계 문제
    • 계정 관리 실패
    • 재사용된 비밀번호
      와 같은 핵심 요인이 논의에서 사라진다.
• 잘못된 경계 지점을 만든다
  • 사용자는 정상적인 서비스 링크, 알림, 인증 메일까지 과도하게 불신하게 되고,
  • 반대로
    • 비밀번호 재사용
    • MFA 미적용
    • 주요 계정 보호 실패
      와 같은 실질적 위험 요소에는 계속 노출된 상태가 유지된다.

그 결과, 보안 인식은 생기지만 보안 수준은 거의 변하지 않는 상태가 된다.

비유하자면,

강도 사건이 늘고 있다는 뉴스 속보를 보고

큰 비용을 들여, 방안마다
홍체, 얼굴 인식,지문 인식 기능이 있는 도어락은 달아두었지만,

건전지를 적절한 시점에 교체 하지않거나,
문이 제대로 잠기는지 확인하지 않고,
모든 도어락 비밀번호는
0000 혹은 1234 초기 비밀번호 그대로 쓰는데,

첨단기술이 접목된 도어락이 장착되어 있으니
“이제 안전하다”는 이야기만 반복하는 상황에 가깝다.

이는 고전적이지만,
열쇠식 잠금장치 달아두고 CCTV로만 감시 하는 방식보다도
못한 결과로 이어진다.

경계 대상은 분명 존재하지만,
정작 사용자가 바꿀 수 있고 바꿔야 할 행동은 그대로인 것이다.

이러한 설명 방식은
보안을 강화하기보다는 공포만 소비하게 만들고,
실제 피해를 줄이는 데에는 거의 기여하지 못한다.

그리고 일부 공격자는 계정 비밀번호를 즉시 변경하거나
자금을 인출하지 않은 채,
탐지를 피하기 위해 일정 기간 계정 활동을
관찰하는 전략을 사용하기도 한다.

즉, 이미 계정 권한이 침해된 상태라면,
사용자가 이를 인지하지 못한 채
공격자가 추가 정보를 수집하거나
적절한 시점을 기다리고 있을 가능성도 배제할 수 없다.

이 관점에서 볼 때,
사용자가 경계해야 할 실질적 위험은
URL 그 자체가 아니라,

이미 유출된 자격증명이 재사용되고,
계정 보호 수단(MFA, 분리 관리)이 미흡한 상태가
오랜 시간 방치되는 상황에 가깝다.

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

참고용으로

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

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

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

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️⃣ 검증된 기관의 보안 솔루션 병행 사용 (현실적 보완 수단)

• 백신 및 EDR / XDR 솔루션 사용
  • 침투 이후 행위 기반 탐지
  • 해킹툴 & 악성 프로그램 설치 사전 차단
  • 계정 탈취 이후 발생하는 이상 프로세스·권한 상승·횡적 이동 탐지
• 계정 보호 및 관리
  • 로그인 시도 행위 분석
  • 비정상 위치·속도·디바이스 변경 탐지
  • 위험 점수 기반 추가 인증 또는 차단
• Anti-Phishing / Anti-Spam 솔루션 사용
  • 스팸 메일 차단
  • 피싱 URL·첨부파일 탐지
  • 발신자 위조(Spoofing) 탐지
  • BEC(Business Email Compromise) 방어
  • 문자 내 URL·번호 패턴 분석
  • 악성 링크 사전/행위 기반 탐지
  • 메신저 기반 사기 탐지

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

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

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

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

다만 주의할 점이 있다.

1.보안 솔루션은 많다고 항상 좋은 것이 아니다.

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

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

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

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

보안은
“많이 깔아두는 것”이 아니라,
감시 동선을 과도하게 방해하지 않으면서도,
빈틈이 생기지 않도록
방어선을 어떻게 배치할지 결정하는 문제에 가깝다.

2.보안 솔루션은 항상 막아주는 것이 아니다.

사용자 스스로 보안을 낮추거나,
공격자가 공격하기 위해 유도한 행위를 하거나,

알려지지 않은 위협에서는
무력화 된다.

보안 솔루션은
내가 놓친 허점을 보완해 주는 보험에 가깝다.

공사장에 안전망이 있다고 해서
고층에서 일부러 뛰어내린 사고까지
보험사가 책임지지는 않는다.

[출처]
✔ ENISA (European Union Agency for Cybersecurity)

• “Do not re-use your passwords”, “Activate multifactor authentication whenever possible” 등 사용자 보안 기본 수칙을 권고합니다.

✔ NIST SP 800-63B (Authentication & Lifecycle Management)

• MFA를 포함한 인증 수준 향상을 공식 기술 표준으로 권장합니다.
• 강력한 인증자 설정, 비밀번호 정책 등이 계정 보호의 핵심 요소로 다루어집니다.

✔ Verizon DBIR (Data Breach Investigations Report)

• Verizon Data Breach Investigations Report (DBIR)는
  웹·계정 침해의 주요 원인으로
  
  stolen credentials(탈취된 자격증명)의 사용이
  가장 빈번하게 관측된다는 점을 반복적으로 보고한다
  
  (Initial Access / Actions 섹션, Figure 15·18).
  이는 단일 비밀번호 기반 인증 구조가
  현실의 공격 환경에서 구조적으로 취약함을
  
  통계적으로 보여주는 결과이며,
  MFA 적용 필요성은 이러한 분석 결과로부터

7. 정리

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

• 대부분의 해킹 피해는
  크레덴셜 스터핑과
  사회공학(Social Engineering) 기반 공격이 병행되는 구조이며,
  이미 유출된 패스워드를 여러 서비스에서 재사용한
  상태에서 속임수에 노출되어 발생한다.

• 크레덴셜 스터핑이든 CSRF,XSS든
  ‘접속만으로 해킹되는 수법’은 아니다 또한
  동시에 전적으로 사용자 책임으로 돌릴 수 있는 문제도 아니다.

• 제로데이는 분명 존재한다.
  그러나 현 시점에서 지속적·상시적 대중 피해의 주된 원인이라고
  보기는 어렵고, 실제로 사용되더라도 일반 사용자나 보안 솔루션이
  즉각적으로 탐지·차단하기는 구조적으로 쉽지 않다.
  
  그렇다고 보안 솔루션이 무의미하다는 뜻은 아니다.
  보안 솔루션은 도입과 관리가 병행될 때 의미를 갖는다.
  솔루션 하나만, 자신을 절대적으로 맹신하지 않는것이 좋다.

• 가장 중요한 보안 습관은:
  • 비밀번호 재사용 금지
  • 공개 와이파이, 인터넷망 사용 지양
  • 계정 분리
  • 최상위 계정 보호
  • 2차 인증 활성화
  • 출처가 불분명하거나, 특정 페이지로 이동하는 URL 링크 접속 최소화
  • 출처가 불분명한 애플리케이션 설치 금지
  • 검증된 기관의 보안 솔루션 사용
  • 보안 솔루션 과신금지
  • 보안 솔루션 사용 시 역할 중복 금지
  • 애플리케이션 및 OS 보안 업데이트 최신화

마무리 한 문장

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

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