이상값을 지웠더니 분석이 틀렸다

이상값

이상값을 버릴 것인가, 분석할 것인가

데이터 분석 프로젝트를 진행하다 보면 예상보다 훨씬 자주 이상값(Outlier)을 만나게 된다. 평균 구매 금액이 5만 원인 쇼핑몰에서 갑자기 500만 원 결제가 발생하거나, 평소보다 수십 배 많은 트래픽이 특정 시간대에 집중되는 경우가 대표적이다.

많은 사람들이 이상값을 발견하면 제거부터 고민한다. 하지만 최근 데이터 분석과 머신러닝 분야에서는 다른 질문을 먼저 던진다. 이 데이터는 오류인가, 아니면 중요한 신호인가?

실제로 가장 큰 비즈니스 기회와 가장 위험한 보안 위협은 대부분 평균적인 데이터가 아닌 예외적인 데이터에서 발견된다.

이상값은 생각보다 자주 발견된다

이상값은 특별한 상황에서만 나타나는 데이터가 아니다. 거의 모든 데이터셋에는 크고 작은 이상값이 존재한다.

사용자 입력 실수, 센서 오작동, API 수집 오류, 이벤트성 마케팅, 특정 고객 행동 등 다양한 원인으로 인해 평균 범위를 벗어난 데이터가 생성된다.

문제는 모든 이상값이 같은 의미를 가지지 않는다는 점이다.

이상값 유형 대표 사례
데이터 오류 입력 실수, 센서 오류
시스템 문제 API 장애, 로그 누락
비즈니스 신호 VIP 고객 구매
이상 징후 금융 사기, 보안 공격
희귀 이벤트 예상 밖 사용자 행동

따라서 이상값을 발견했다면 제거보다 먼저 원인을 확인해야 한다.

첫 번째 기준, 데이터 오류인지 먼저 확인해야 한다

실무에서 가장 먼저 확인하는 것은 데이터 자체의 신뢰성이다.

많은 이상값은 실제 현상이 아니라 데이터 수집 과정에서 발생한 문제인 경우가 많다.

예를 들어 센서가 고장 나면서 실제보다 100배 높은 수치를 기록하거나 API 연동 오류로 동일 데이터가 반복 저장될 수 있다.

사용자 입력 실수 역시 흔한 원인이다. 금액 입력 오류나 날짜 형식 오류는 거의 모든 서비스에서 발생한다.

만약 데이터 생성 과정 자체에 문제가 있었다면 해당 값은 분석 대상이 아니라 정제 대상이 된다.

두 번째 기준, 비즈니스적으로 의미가 있는가

오류가 아니라면 다음 단계는 비즈니스 관점에서 의미를 확인하는 것이다.

통계적으로는 이상값이지만 사업적으로는 가장 중요한 데이터인 경우가 많다.

대표적인 사례가 VIP 고객이다. 전체 고객 평균 구매 금액은 낮더라도 일부 고객은 일반 고객보다 수십 배 많은 금액을 사용한다.

마케팅에서도 비슷한 현상이 나타난다. 특정 광고 캠페인의 전환율이 평소보다 압도적으로 높다면 단순한 이상값이 아니라 성공 원인을 분석해야 할 대상이 된다.

실무에서는 다음 항목을 함께 검토한다.

  • 실제 고객 행동인가
  • 반복적으로 발생하는 패턴인가
  • 특정 이벤트와 연관성이 있는가
  • 추가 매출 또는 위험 신호와 연결되는가

세 번째 기준, 분석 목적이 무엇인가

동일한 이상값이라도 분석 목적에 따라 처리 방식은 달라진다.

경영 보고서를 작성하는 경우 일부 극단값이 전체 평균을 왜곡할 수 있다. 이때는 제거하거나 별도로 표시하는 것이 적절할 수 있다.

반면 머신러닝 모델 개발에서는 오히려 이상값이 핵심 데이터가 되는 경우가 많다.

예를 들어 사기 거래 탐지 모델은 정상 거래보다 이상 거래 패턴을 학습해야 한다.

설비 고장 예측 시스템 역시 정상 상태보다 비정상 상태 데이터가 더 높은 가치를 가진다.

결국 이상값 처리 방법은 데이터보다 목적이 먼저 결정한다.

금융과 보안 분야는 이상값을 버리지 않는다

금융 산업은 이상값의 중요성을 가장 잘 보여주는 분야다.

갑작스러운 해외 결제, 평소와 다른 위치에서 발생한 거래, 비정상적으로 큰 금액의 송금은 모두 이상값으로 분류될 수 있다.

보안 분야도 마찬가지다.

특정 서버에 갑자기 몰리는 트래픽, 수백 번 반복되는 로그인 시도, 예상하지 못한 접근 패턴은 사이버 공격의 신호일 수 있다.

이러한 데이터를 단순히 제거한다면 가장 중요한 위험 신호를 놓치게 된다.

그래서 금융과 보안 시스템은 이상값 제거보다 이상값 탐지와 분류에 더 많은 자원을 투자한다.

이상값 가치

AI 시대에는 이상값의 가치가 더 커지고 있다

생성형 AI와 머신러닝 기술이 발전하면서 이상값의 중요성은 더욱 커지고 있다.

과거에는 평균적인 패턴을 잘 학습하는 것이 중요했다면 최근에는 예외 상황을 얼마나 이해하는지가 경쟁력이 되고 있다.

자율주행 차량은 평범한 도로보다 돌발 상황을 학습해야 하고, 추천 시스템은 일반적인 행동보다 특이한 구매 패턴을 이해해야 한다.

AI 모델 역시 실제 서비스 환경에서는 예상하지 못한 입력을 끊임없이 만나게 된다.

결국 이상값은 모델을 혼란스럽게 만드는 데이터가 아니라 모델을 더 강하게 만드는 데이터가 될 수 있다.

실무에서는 제거보다 분류가 먼저다

최근 데이터 품질 관리 방식은 과거와 크게 달라졌다.

예전에는 이상값을 발견하면 제거하는 경우가 많았지만 현재는 먼저 분류하고 의미를 파악하는 방향으로 변화하고 있다.

실무에서 자주 사용하는 이상값 처리 순서는 다음과 같다.

  1. 데이터 오류 여부 확인
  2. 비즈니스 의미 분석
  3. 분석 목적 검토
  4. 제거 또는 유지 결정

중요한 것은 이상값을 없애는 것이 아니라 왜 발생했는지 이해하는 것이다.

이상값의 중요성은 특히 실시간 분석 환경에서 더욱 커진다. 이벤트가 지속적으로 발생하는 스트림 데이터 환경에서는 이상값이 단순한 노이즈가 아니라 중요한 비즈니스 신호나 위험 징후가 될 수 있기 때문이다. 관련 내용은 스트림 데이터 편에서 자세히 확인할 수 있다.

암호화 사각지대

암호화

암호화 실무 적용법과 해결 과제

암호화는 개인정보 보호와 정보 보안 강화에 필수적인 기술로 자리 잡았다. 실무에서 효과적으로 적용할 수 있는 세 가지 주요 방법은 대칭키 , 비대칭키 , 그리고 하이브리드 방식이다. 해외에서는 이들 방법을 다양한 산업에서 성공적으로 활용하는 반면, 국내에서는 특정 기술 도입의 제한과 법적 규제, 그리고 인프라 미비 등의 문제점이 존재한다. 따라서 국내 실무 환경에서는 기술적 장점뿐 아니라 제도적 개선과 보안 전문 인력 양성이 병행되어야 데이터 암호화의 효과적인 활용이 가능하다.

해외와 국내 암호화 활용 현황과 문제점

해외에서는 금융, 의료, 공공기관 등 다양한 분야에서 데이터 암호화를 법적 요구사항과 함께 적용하며, 클라우드 기반 솔루션 활용이 확산 중이다. 유럽연합의 GDPR과 미국의 HIPAA 같은 규제는 데이터 암호화 적용을 강력히 권고하며, 이로 인해 기업들은 기술 도입이 활발히 진행되고 있다. 반면, 국내는 개인정보 보호법과 정보통신망법 등 관련 법령이 있지만, 해외 수준의 강력한 규제와 기술 도입 활성화는 아직 미흡한 실정이다. 특히 중소기업 중심의 국내 환경에서 기술 도입 비용 부담과 전문 인력 부족이 큰 문제로 대두되고 있다.

데이터 암호화 실무 적용 세 가지 방법과 비교 분석

첫째, 대칭키 암호화는 하나의 키를 이용해 데이터를 암호화하고 복호화하는 방식이다. 해외에서는 AES(Advanced Encryption Standard)를 중심으로 빠르고 효율적인 데이터 보호에 널리 쓰이고 있다. 국내 역시 AES 활용도가 높지만, 키 관리 체계가 불안정한 결과로 일부 보안 사고가 발생하기도 한다.

둘째, 비대칭키 암호화는 공개키와 개인키를 사용하는 구조로 안전성이 뛰어나 이메일, 인증, 디지털 서명 등에 활용된다. 해외 기업은 RSA, ECC 암호화 알고리즘을 접목해 온라인 거래와 인증 시스템을 견고하게 구축하고 있다. 국내에서는 공인인증서 제도의 변화와 함께 비대칭키 기술 사용이 늘고 있으나, 인증서 발급 지연과 사용자 인식 부족으로 실무 활용에 한계가 있다.

셋째, 하이브리드 암호화는 대칭키와 비대칭키 방식을 결합하여 보안성과 효율성을 동시에 추구한다. 해외에서는 클라우드 기반 파일 암호화, VPN, 보안 메일 서비스에 적극 활용되고 있으며, 사용자 경험을 해치지 않는 암호화 구현이 특징이다. 국내에서는 일부 대기업 위주로 적용 중이며, 중소기업이나 공공기관에서는 인프라 구축과 기술 이해 부족으로 실행력이 떨어지는 경향이 있다.

이러한 암호화 기술 적용 시 공통적으로 직면하는 문제점은 복잡한 키 관리, 암호화 대상 데이터 선정의 어려움, 성능 저하 우려, 그리고 법적 규제의 불확실성이다. 해외는 클라우드 보안 표준과 법률이 지속적으로 업데이트되어 기업이 정책을 유연하게 조정할 수 있으나, 국내는 법정 규제 강화에도 불구하고 기술적 가이드라인과 인프라 지원이 부족한 편이다.

데이터 암호화

실무에서의 적용과 개선 방향

데이터 암호화는 국내외 정보보호 전략에서 핵심 요소임이 분명하다. 해외 사례는 다양한 기술을 융합하여 보안성과 효율성을 동시에 달성하는 데 성공했으며, 이는 국내 실무 적용 시 참고할 만한 모범 사례이다. 국내 환경에서는 기술 도입 확대와 함께 법적·제도적 지원 강화, 전문 인력 교육이 긴요하다. 대칭키, 비대칭키, 하이브리드 암호화 방식을 상황에 맞게 통합 활용하고, 키 관리 및 정책 수립에 주력해야 한다. 이를 통해 국내 기업과 기관도 안전한 데이터 보호를 실현할 수 있을 것이다.

데이터 흐름이 끊기는 3가지 구간

데이터 엔지니어라면 한 번쯤 이런 상황을 겪어봤을 것이다.

파이프라인은 돌아가고 있다. 로그도 정상이다. 그런데 분석가가 쓰는 대시보드의 숫자가 이상하다. 원인을 찾기 위해 소스부터 역추적한다. 변환 로직을 뜯어보고, 조인 조건을 다시 확인하고, 스케줄러 로그를 열어본다. 두 시간 뒤에야 원인을 찾는다. 업스트림 테이블 스키마가 조용히 바뀌어 있었다.

아무도 공지하지 않았다.

이건 특정 팀의 문제가 아니다. 데이터가 여러 시스템을 거쳐 흐르는 구조라면, 어디서나 일어나는 일이다.

DATA Analytics

흐름이 끊기는 지점은 세 곳이다

데이터가 의사결정에 닿기까지의 경로를 단순화하면 이렇다.

수집 → 저장 → 변환 → 서빙

각 단계마다 끊길 수 있는 지점이 있다. 경험상 문제가 집중되는 구간은 세 곳이다.

1. 소스와 수집 사이

API 스펙이 바뀐다. 필드명이 달라지거나 타입이 바뀐다. 소스 시스템이 예고 없이 응답 구조를 변경한다. 수집 레이어에 방어 로직이 없으면 이건 그대로 다운스트림으로 흘러간다. 나쁜 데이터는 오류보다 무섭다. 오류는 파이프라인을 멈추지만, 나쁜 데이터는 조용히 통과한다.

2. 변환 로직 내부

SQL이든 dbt든 Spark든, 변환 로직은 시간이 지날수록 복잡해진다. 처음엔 단순했던 쿼리가 조건이 쌓이고 조인이 늘어나면서 누구도 전체를 파악하지 못하는 상태가 된다. 이 상태에서 요구사항이 바뀌면, 수정의 영향 범위를 추적하기 어려워진다. 테스트가 없으면 더 그렇다.

3. 서빙과 소비 사이

분석가가 보는 테이블이 언제 갱신됐는지 명확하지 않다. freshness가 보장되지 않는다. 메트릭 정의가 팀마다 다르다. 같은 “전환율”인데 마케팅 팀과 프로덕트 팀의 숫자가 다르다. 이건 기술 문제가 아니라 정의 문제다. 하지만 결국 데이터 팀이 해결해야 한다.

DATA FLOW

왜 이 문제가 반복되는가

도구가 없어서가 아니다. 지금은 도구가 넘친다. 오케스트레이션, 카탈로그, 품질 모니터링, 계보 추적. 스택은 갖춰져 있는데 문제는 계속된다.

이유는 하나다. 흐름 전체를 보는 시각이 없다.

파이프라인을 만드는 사람과, 데이터를 쓰는 사람과, 소스를 관리하는 사람이 각자의 구간만 본다. 연결 지점에서 발생하는 문제는 누구의 책임도 아닌 상태로 방치된다. 모니터링을 해도 알람이 울리는 건 이미 문제가 터진 이후다.

흐름을 설계한다는 건 각 단계를 잘 만드는 것만이 아니다. 연결 지점을 명시적으로 정의하고, 문제가 생겼을 때 어디서 왜 생겼는지 추적할 수 있게 만드는 것이다.

실무에서 바로 적용할 수 있는 세 가지

복잡한 이야기를 했지만, 지금 당장 할 수 있는 것부터 시작하는 게 낫다.

스키마 변경 감지를 자동화한다

소스 테이블의 스키마를 주기적으로 스냅샷 찍어 비교하는 로직을 넣는다. dbt의 source freshness와 schema tests를 조합하면 기본적인 감지는 된다. Great Expectations나 Soda를 쓴다면 컬럼 타입, null 비율, 값의 범위를 임계값 기반으로 모니터링할 수 있다. 완벽하지 않아도 된다. 아무것도 없는 것보다 낫다.

변환 로직에 lineage를 남긴다

어떤 테이블이 어떤 소스에서 어떻게 만들어졌는지 추적 가능하게 만든다. dbt를 쓴다면 이미 lineage graph가 있다. 없다면 최소한 주요 테이블의 upstream을 문서화한다. 변경이 생겼을 때 영향 범위를 파악하는 데 걸리는 시간이 줄어든다.

메트릭 정의를 한 곳에서 관리한다

팀마다 다른 정의를 쓰는 문제는 semantic layer로 해결한다. dbt Semantic Layer, Looker의 LookML, MetricFlow 등을 쓰면 메트릭을 코드로 정의하고 단일 소스로 관리할 수 있다. 도구 도입이 어렵다면, 최소한 메트릭 정의서를 공유 문서로 만들고 팀 간 합의를 거치는 것부터 시작한다.

DATA PIPELINE

글을 마치며

데이터 플로우는 파이프라인을 잘 만드는 것만이 아니다. 데이터가 생성되는 시점부터 누군가의 결정에 영향을 미치는 시점까지, 그 전체 흐름이 끊기지 않게 설계하는 것이다.

끊기는 지점을 알면, 고칠 수 있다.

Grojkon Apex · Data Flow #DataEngineering #DataPipeline #dbt #DataQuality #Analytics