이 글은 계정 방어 시리즈의 3편입니다.

- **새 탭으로 열기:** [/files/Adaptive_Security_Strategy.pdf](/files/Adaptive_Security_Strategy.pdf) > PDF가 보이지 않으면 여기로 열어보세요: [/files/Adaptive_Security_Strategy.pdf](/files/Adaptive_Security_Strategy.pdf)

들어가며 — 1편·2편이 남긴 질문

1편에서는 CAPTCHA가 어떻게 0원에 뚫리는지 보여줬다. 2편에서는 ATO 공급망이 어떻게 스스로를 재생산하는지 분석했다.

두 글이 같은 방향을 가리킨다.

개별 통제는 점점 약해지고, 공격은 멈추지 않는다.

그렇다면 답은 무엇인가. 통제를 더 많이 만드는 것인가, 더 강하게 적용하는 것인가. 캡챠 글의 로드맵 중기 단계에 등장한 단어가 이 글의 출발점이다. 위험 기반 적응형 인증(Risk-Based Authentication).

이 글은 그 적응형 인증이 왜 단순한 기능 도입이 아니라 운영 체계의 문제인지, 그리고 그것이 왜 보안팀 혼자서는 풀 수 없는지를 다룬다.

1. 보안 통제는 부족한 것이 아니라 불편하다

2012년 SK플래닛이 분사하고 한창 상승기에 있던 시절, 회사는 DMP 기반의 데이터 플랫폼을 만들고 있었다. DMP(Data Management Platform)는 흩어져 있던 고객 데이터를 한곳에 모아 세그먼트로 가공해 광고와 서비스에 쓰도록 만드는 플랫폼이다. 당시의 원대한 목표는 Curation이었다. 방대한 고객 데이터를 바탕으로 고객을 이해하고, 고객별로 더 적절한 서비스를 제공하겠다는 구상이었다.

지금 돌이켜보면 그 흐름은 주로 타겟팅 광고나 군집 광고 서비스의 형태로 축소되어 보일 수 있다. 하지만 보안 관점에서 보면, 당시 DMP가 꿈꿨던 고객 이해 역량은 여전히 중요하다.

보안도 결국 고객별 맞춤 통제가 필요하기 때문이다.

CAPTCHA, SMS 본인확인, MFA, 거래 임계치, 봇 탐지 스크립트, 계정 제한 같은 보안 통제는 이미 존재한다. 문제는 통제 수단이 없다는 것이 아니다.

진짜 문제는 이 통제들이 불편하다는 것이다.

모든 고객에게, 모든 시점에, 동일한 강도로 보안 통제를 적용하면 보안성은 올라갈 수 있다. 하지만 서비스 경험은 급격히 나빠진다. 반대로 고객 불편을 이유로 통제를 느슨하게 적용하면 공격자는 가장 약한 지점을 반복해서 악용한다.

그래서 보안의 다음 과제는 새로운 통제를 더 많이 만드는 것이 아니다.

핵심은 이것이다.

언제, 누구에게, 어떤 시점에, 어떤 강도로 통제를 적용할 것인가.

누구에게 CAPTCHA를 띄울 것인가. 누구에게 SMS 인증을 요구할 것인가. 어떤 거래에 임계치를 적용할 것인가. 어떤 고객에게 MFA를 요구할 것인가. 어떤 시점에 봇 탐지를 강화할 것인가.

이 판단은 결국 고객 행동 데이터와 거래 맥락에 기반해야 한다.

보안 분야에서는 이런 접근을 보통 Risk-Based Authentication 또는 Adaptive Authentication이라고 부른다. 모든 사용자에게 항상 같은 인증 마찰을 주는 대신, 기기, 위치, 시간, 세션, 거래 패턴이 평소와 얼마나 다른지를 보고 추가 인증이나 차단 여부를 결정하는 방식이다.

중요한 점은 이것이 새로운 통제 기능을 뜻하는 것이 아니라는 점이다.

이미 존재하는 CAPTCHA, MFA, SMS 인증, 거래 제한, 계정 제한을 위험 맥락에 따라 다르게 배치하는 방식이다.

결국 문제는 마찰 자체가 아니다. 보안 마찰은 어떤 순간에는 필요하다. 사용자를 잠시 멈추게 하고, 공격자의 비용을 높이며, 위험한 행위를 다시 확인하게 만들기 때문이다.

문제는 그 마찰이 필요한 고객과 필요하지 않은 고객을 구분하지 못할 때 발생한다.

2. 마케팅은 팔기 위해 고객을 나누고, 보안은 보호하기 위해 고객을 나눈다

여기서 마케팅 세그먼트와 보안 세그먼트의 차이가 드러난다.

타겟팅 광고를 위한 고객군 분석은 기본적으로 사업의 역할이다. 사업은 특정 상품이나 캠페인에 반응할 가능성이 높은 고객군을 찾는다. 그래서 전체 고객의 정상 행동 지형도를 만들기보다는, 필요한 타겟 고객군을 중심으로 분석한다.

하지만 보안은 다르다.

보안은 “누가 이 상품에 반응할 것인가"를 묻지 않는다.

보안은 이렇게 묻는다.

이 고객의 지금 행동이 평소와 다른가? 이 거래가 이 고객에게 자연스러운가? 이 계정이 정상적인 고객군의 행동에서 벗어났는가?

이를 판단하려면 특정 캠페인 타겟이 아니라, 전체 고객의 정상 행동 baseline이 필요하다.

즉,

마케팅은 팔기 위해 고객을 나누고, 보안은 보호하기 위해 고객을 나눈다.

둘 다 고객 데이터를 사용하고, 둘 다 세그먼트를 말한다. 하지만 목적과 범위는 다르다. 마케팅에 필요한 것은 반응 가능성이 높은 고객군이고, 보안에 필요한 것은 고객별·군집별 정상 행동 지형도다.

DMP나 CDP에서 쓰는 trait은 고객의 속성이나 행동을 모델 입력값으로 잘게 쪼갠 단위를 말한다. 예를 들어 “주말 결제 비율”, “주로 쓰는 기기 유형”, “최근 30일 평균 거래 금액” 같은 것들이다.

마케팅이 구매 가능성이 높은 고객군을 찾기 위해 trait을 조합한다면, 보안은 평소 행동에서 벗어난 고객군을 찾기 위해 고객 행동 trait과 위험 신호를 조합해야 한다.

하지만 여기서 중요한 현실적 차이가 있다.

고객 행동 trait을 조합해 보안 세그먼트를 만드는 일은 보안팀만의 일이 아니다. 보안은 위험을 정의하지만, 그 위험이 고객 데이터에서 어떻게 드러나는지는 데이터와 운영 조직이 더 잘 안다. 그래서 고객 맥락 기반 보안은 보안 기능이 아니라, 보안·Fraud/Risk·운영·데이터 플랫폼이 함께 설계해야 하는 통제 체계다.

최근 사기 탐지 연구도 비슷한 방향으로 이동하고 있다. 개별 거래 단위의 이상 여부만으로는 충분하지 않고, 고객 단위의 장기 행동 패턴, 세션 흐름, 거래 맥락을 함께 봐야 한다는 것이다.

결국 보안 세그먼트의 목적은 “위험한 고객군"을 낙인찍는 것이 아니다. 고객별·군집별 정상 행동 범위를 이해하고, 그 범위를 벗어나는 순간에만 적절한 통제를 배치하는 것이다.

3. 보안솔루션은 출발점이지 완성형 답은 아니다

물론 이런 방식이 전부 보안솔루션만으로 가능한 것은 아니다.

IAM, CIAM, Bot Management, FDS, Fraud Detection 솔루션은 새 기기, 의심 IP, 비정상 로그인, 자동화 요청, 고위험 거래 같은 신호를 탐지하고 MFA, CAPTCHA, 차단 같은 통제를 실행할 수 있다.

즉, 위험 신호를 계산하고 통제를 적용하는 기술적 기반은 이미 상당 부분 존재한다.

하지만 솔루션은 우리 서비스의 고객 맥락을 자동으로 이해하지 못한다.

어떤 포인트 사용이 정상인지, 어떤 이벤트 기간의 대량 거래가 자연스러운지, 어떤 고객군에게 추가 인증을 요구하면 이탈이 커지는지, 어떤 오탐이 고객센터 부담으로 이어지는지는 보안솔루션의 기본 룰만으로 알 수 없다.

보안솔루션은 이렇게 말할 수 있다.

“이 로그인은 위험해 보인다.” “이 요청은 봇일 가능성이 높다.” “이 계정 행동은 과거와 다르다.” “이 상황에서는 MFA를 요구할 수 있다.”

하지만 실제로 중요한 질문은 그 다음이다.

  • 그래서 차단할 것인가.
  • MFA를 요구할 것인가.
  • CAPTCHA만 띄울 것인가.
  • 고객센터 확인으로 넘길 것인가.
  • 거래를 보류할 것인가.
  • VIP 고객이면 다르게 처리할 것인가.
  • 이벤트 기간이면 기준을 완화할 것인가.

이 판단은 솔루션의 기본 룰만으로 해결하기 어렵다.

솔루션은 위험을 점수화하고 통제를 실행할 수 있다. 그러나 그 점수의 의미를 해석하고, 고객 경험과 피해 비용 사이에서 통제 강도를 결정하고, 오탐 결과를 다시 정책과 모델에 반영하는 일은 조직이 해야 한다.

따라서 보안솔루션은 고객 맥락 기반 보안의 출발점일 수는 있지만, 완성형 답은 아니다.

보안솔루션은 통제를 실행할 수는 있지만, 고객 맥락을 소유하지는 않는다.

고객 맥락은 데이터, 운영, Fraud/Risk, 고객센터, 보안이 함께 만들어야 한다.

4. 문제는 데이터가 아니라 폐루프다

현실적인 문제는 여기서 시작된다.

보안팀은 고객 데이터를 가장 잘 이해하는 조직이 아니다. 고객 데이터에 대한 권한도 제한적이고, 데이터 플랫폼에 대한 운영 권한도 일반적으로 보안팀에 있지 않다.

반대로 사업/운영 조직은 고객과 서비스 흐름을 잘 안다. 실제 서비스를 운영하는 조직은 DMP나 DIC(Data Insight Center — 운영자가 직접 데이터를 조회·시각화해 이상 징후를 탐색할 수 있는 사내 분석 도구) 같은 도구를 활용해 이상 징후를 찾고 대응 작업을 수행한다.

하지만 그것이 곧 보안적으로 충분한 대응을 의미하지는 않는다.

운영팀은 이상을 가장 먼저 발견할 수 있다. 그러나 그 이상을 보안 통제로 전환하려면 다른 역량이 필요하다.

  • 위험 모델링이 필요하다.
  • 정상 행동 baseline이 필요하다.
  • 차단 기준이 필요하다.
  • 오탐 관리가 필요하다.
  • 고객 불편 조정이 필요하다.
  • 대응 권한이 필요하다.
  • 그리고 결과를 다시 모델과 룰에 반영하는 피드백 루프가 필요하다.

따라서 이 문제는 단순히 운영팀의 보안 전문성 부족이라고 볼 수 없다.

더 정확히는 운영 현장의 감지 능력과 보안 통제 체계가 하나의 폐루프로 연결되지 않은 문제다.

운영은 이상을 본다. 보안은 위험을 정의한다. 데이터 플랫폼은 맥락을 가공한다. 사업은 고객 경험을 이해한다.

하지만 이 네 가지가 연결되지 않으면, 보안은 다시 단순 룰, 고정 임계치, 일괄 MFA, 일괄 차단으로 돌아간다.

고객 맥락 기반 보안은 단순한 탐지 모델 문제가 아니다. 차단하지 않았을 때의 피해, 차단했을 때의 고객 불편, 고객센터 대응 비용, 오탐으로 인한 이탈 가능성을 함께 고려해야 한다.

좋은 탐지는 위험을 많이 잡는 것이 아니다.

좋은 탐지는 필요한 순간에만 통제를 걸고, 그 결과를 다시 룰과 모델에 되돌려주는 것이다.

이 피드백이 없으면 보안 통제는 정교해지지 않는다. 오히려 통제는 더 많아지고, 고객 불편은 커지고, 운영자는 예외 처리에 지치게 된다.

5. 고객 데이터 기반 보안은 보안팀 단독 과제가 아니다

고객 데이터 기반 맞춤형 보안은 이상적인 방향이다. 고객별 정상 패턴을 이해하고, 위험한 순간에만 마찰을 주는 보안은 결국 가야 할 방향이다.

하지만 이것은 보안팀 혼자 할 수 있는 일이 아니다.

보안 조직은 위험 시나리오를 정의할 수 있다. 예를 들어 계정 탈취, 포인트 부정 사용, 비정상 충전, 선물하기 악용, 보이스피싱 의심 같은 위험을 모델링할 수 있다.

하지만 고객 행동 데이터를 어떤 기준으로 나눌 것인지, 어떤 feature로 만들 것인지, 어떤 군집을 정상으로 볼 것인지는 데이터와 서비스 맥락을 아는 조직의 도움이 필요하다.

  • 사업/운영 조직은 고객 맥락을 안다.
  • 데이터 플랫폼 조직은 데이터를 가공하고 운영할 수 있다.
  • Fraud/Risk 조직은 부정 사용과 고객 피해의 실제 패턴을 안다.
  • 보안 조직은 위험 시나리오와 통제 기준을 설계할 수 있다.

이 역할들이 연결되어야 한다.

그래서 필요한 것은 단순한 알고리즘 도입이 아니다. 필요한 것은 보안·Fraud/Risk·사업·운영·데이터 플랫폼 조직 간의 R&R 재정의다.

  • 누가 이상 징후를 발견할 것인가.
  • 누가 위험으로 판정할 것인가.
  • 누가 고객군을 정의할 것인가.
  • 누가 통제 강도를 결정할 것인가.
  • 누가 고객 불편을 감수할 것인가.
  • 누가 결과를 다시 룰과 모델에 반영할 것인가.

이 질문에 대한 답이 없으면, 고객 데이터 기반 보안은 구호에 머문다.

위험 점수는 정책이 아니다. 모델 결과는 의사결정이 아니다. 데이터 분석은 통제 실행이 아니다.

데이터에서 위험 신호를 찾는 것과, 그 신호를 고객 경험을 해치지 않는 방식으로 보안 통제에 연결하는 것은 전혀 다른 문제다.

그래서 고객 맥락 기반 보안은 기술 프로젝트이면서 동시에 운영 설계 문제다.

6. 기본 통제가 먼저다

물론 고객 데이터 기반 맞춤형 보안이 항상 당장의 1순위 과제는 아닐 수 있다.

현실에서는 고도화된 AI 군집화보다 기본 통제가 먼저 필요할 때가 많다.

예를 들면 FDS 기본 룰 정비, 거래 횟수 제한, CAPTCHA/MFA 배치, 로그 수집 표준화, JIRA 기반 대응 프로세스, 고객센터 VOC 연계 같은 것들이다.

개인화 보안은 이런 기반 위에서 작동한다.

기본 통제가 없으면 개인화는 정교함이 아니라 복잡도만 늘릴 수 있다. 데이터 기반 맥락 없이 고도화를 시도하면 통제 기준은 불명확해지고, 오탐과 고객 불편은 늘어나며, 운영 부담만 커질 수 있다.

따라서 현실적인 순서는 이렇다.

개인화 보안은 목표지만, 기본 통제가 먼저다. 다만 기본 통제도 결국 데이터 기반 맥락 위에서 고도화되어야 한다.

처음부터 모든 고객 행동을 모델링하고, 모든 거래를 실시간 스코어링하고, 모든 통제를 개인화하려고 하면 실패할 가능성이 높다.

먼저 해야 할 일은 단순하다.

  • 어떤 행위를 위험 행위로 볼 것인지 정리해야 한다.
  • 어떤 로그가 필요한지 표준화해야 한다.
  • 어떤 상황에서 CAPTCHA, MFA, SMS 인증, 거래 제한을 적용할지 기준을 세워야 한다.
  • 오탐이 발생했을 때 고객센터와 운영팀이 어떻게 복구할지 정의해야 한다.
  • 그리고 그 결과를 다시 보안팀과 데이터팀이 볼 수 있어야 한다.

이 기본이 없으면 고도화는 쌓이지 않는다.

7. 고객 맥락도 만능은 아니다

물론 고객 맥락 기반 보안이 만능은 아니다.

기기 지문, 위치, 행동 패턴 같은 신호는 공격자에게 모방되거나 우회될 수 있다. 공격자는 정상 고객처럼 보이기 위해 기기를 바꾸고, 세션을 탈취하고, 행동 패턴을 흉내 낼 수 있다. 1편의 CAPTCHA 우회 PoC가 보여줬듯, 단일 신호는 결국 모방된다.

데이터가 많아질수록 프라이버시와 공정성 문제도 커진다. 고객을 더 잘 이해하려는 시도는 자칫 고객을 더 많이 추적하고, 더 오래 보관하고, 더 넓게 프로파일링하는 구조로 흘러갈 수 있다.

따라서 고객 맥락은 단독 판단 근거가 아니라 여러 신호 중 하나로 다뤄야 한다.

그리고 그 데이터가 왜 필요하고, 누가 접근하며, 얼마나 보관되는지도 함께 설계되어야 한다.

고객 맥락 기반 보안은 “고객 데이터를 더 많이 모으자"는 주장이 아니다.

오히려 반대에 가깝다.

필요한 목적에 맞는 데이터를, 필요한 기간 동안, 필요한 조직이, 필요한 통제에만 사용하도록 설계하자는 주장이다.

그렇지 않으면 보안은 고객을 보호하는 이름으로 또 다른 감시 체계를 만들 수 있다.

결론 — 시리즈가 도착한 곳

DMP가 꿈꿨던 큐레이션은 광고 타겟팅만의 개념이 아니다.

고객을 이해하고, 고객의 상태와 행동 맥락을 해석하고, 필요한 순간에 적절히 개입하는 능력은 보안에서도 필요하다.

다만 보안에서 필요한 것은 특정 캠페인 타겟이 아니다. 보안에 필요한 것은 전체 고객의 정상 행동 baseline이다.

이미 보안 통제는 있다. 하지만 통제는 불편하다.

그리고 그 고객 맥락은 보안솔루션을 구매한다고 자동으로 생기지 않는다.

그래서 보안의 성숙도는 통제 기능을 얼마나 많이 보유했느냐가 아니라, 그 통제를 고객 맥락에 맞게 언제 적용할 수 있느냐에서 결정된다.

고객 맥락 기반 보안은 더 강한 통제를 항상 적용하는 것이 아니다.

필요한 순간에만 정확한 마찰을 배치하는 능력이다.

가장 압축하면 이 문장이다.

보안 통제는 부족한 것이 아니라 불편하다. 그래서 보안은 고객 맥락을 알아야 한다. 그리고 성숙한 보안은 더 많은 통제가 아니라, 더 정확한 마찰을 설계하는 일이다.

조금 더 강하게 말하면 이렇게 정리할 수 있다.

보안솔루션은 통제를 실행할 수 있다. 하지만 어떤 고객에게, 어떤 순간에, 어느 정도의 마찰을 줄 것인지는 조직이 결정해야 한다. 고객 맥락 기반 보안은 제품이 아니라 운영 체계다.

그리고 마지막으로 이렇게 말할 수 있다.

고객을 모르는 보안은 개인화될 수 없고, 보안 목적을 모르는 데이터는 보호로 이어지기 어렵다.

참고할 만한 연구

  • Stephan Wiefling et al., “Pump Up Password Security! Evaluating and Enhancing Risk-Based Authentication on a Real-World Large-Scale Online Service” → 실제 대규모 온라인 서비스에서 RBA가 어떻게 작동하는지 측정한 가장 직접적인 실증 연구. 1섹션 “이미 존재하는 통제를 위험 맥락에 따라 다르게 배치한다"는 주장의 핵심 근거.

  • Stephan Wiefling et al., “More Than Just Good Passwords? A Study on Usability and Security Perceptions of Risk-based Authentication” → 사용자가 RBA의 추가 인증을 어떻게 받아들이는지 측정한 사용성·인식 연구. 1섹션 “마찰이 필요한 고객과 필요하지 않은 고객"의 구분이 실제 사용자 경험에 어떻게 보이는지 알려준다.

  • Philipp Markert et al., “As soon as it’s a risk, I want to require MFA: How Administrators Configure Risk-based Authentication” → 관리자(운영자)가 실제로 어떤 기준으로 MFA를 트리거하는지 인터뷰·관찰한 연구. 5섹션 “누가 통제 강도를 결정할 것인가” 질문에 대한 현장 데이터.

  • Verena Distler et al., “The Framework of Security-Enhancing Friction” → 마찰을 단순한 비용이 아니라 보안 강화 도구로 다루는 이론 프레임. 본문 핵심 명제 “더 정확한 마찰 설계"의 학술적 뿌리.

  • Phoebe Jing et al., “A Customer Level Fraudulent Activity Detection Benchmark for Enhancing Machine Learning Model Research and Evaluation” → 거래 단위가 아니라 고객 단위로 부정 사용을 평가하는 벤치마크와 데이터셋. 2섹션 “고객 단위 장기 행동 패턴이 필요하다"는 주장이 실제 모델링에서 어떻게 다뤄지는지 보여준다.

  • Paolo Vanini et al., “Online payment fraud: from anomaly detection to risk management” → 이상 탐지에서 리스크 관리까지 어떻게 이어지는지 정리한 종합 논문. 4섹션 “탐지가 통제·복구로 폐루프를 이루어야 한다"는 주장의 학술 정리.

  • Xu Lin et al., “Phish in Sheep’s Clothing: Exploring the Authentication Pitfalls of Browser Fingerprinting” → 브라우저 핑거프린팅이 어떻게 모방·우회되는지 분석한 연구. 7섹션 “단일 신호는 결국 흉내 낼 수 있다"는 가드레일의 직접 근거.