데이터 늪
IT 위키
더 많은 작업
데이터 늪(Data Swamp, 데이터 스웜프)은 데이터 레이크에 메타데이터·품질 관리·거버넌스 없이 데이터만 계속 쌓여, 무엇이 어디에 있고 믿을 만한지 알 수 없게 되어 분석에 쓸 수 없는 상태가 된 저장소이다.
데이터 레이크는 정형·반정형·비정형 데이터를 원본 형태 그대로 모아 두고, 쓰는 시점에 구조를 해석하는(스키마 온 리드) 저장소이다. 적재 전에 모양을 맞출 필요가 없다는 유연성이 장점이지만, 같은 이유로 "일단 다 넣어 두자"는 운영이 쉽게 일어난다.
출처·의미·갱신 시점·소유자가 기록되지 않은 데이터가 쌓이면 사용자는 필요한 데이터를 찾지 못하고, 찾더라도 최신인지·정확한지 판단할 수 없다. 중복본과 쓰레기 데이터가 저장 비용만 늘리고, 개인정보가 어디 섞여 있는지도 모르게 된다. 이렇게 저장은 되지만 활용은 안 되는 상태를 고인 물에 빗대 데이터 늪이라 부른다.
| 구분 | 관리되는 데이터 레이크 | 데이터 늪 |
|---|---|---|
| 메타데이터 | 데이터 카탈로그에 출처·의미·스키마·소유자 등록 | 없거나 부정확해 검색·이해 불가 |
| 품질 | 영역별 정제·검증 규칙 적용 | 오류·중복·누락 데이터가 그대로 섞임 |
| 계보(Lineage) | 원천부터 가공 결과까지 추적 가능 | 어떤 데이터에서 만들어졌는지 모름 |
| 접근 통제 | 역할별 권한, 민감정보 식별·마스킹 | 권한·민감정보 관리 부재로 유출 위험 |
| 수명주기 | 보존·폐기 정책 적용 | 쓰지 않는 데이터가 무한정 쌓임 |
| 결과 | 셀프서비스 분석, AI 학습 데이터 공급 | 신뢰 상실, 비용만 증가, 사용자 이탈 |
데이터 웨어하우스는 적재 전에 스키마를 정하고(스키마 온 라이트) 정제한 데이터만 넣기 때문에 늪이 될 위험은 작지만, 비정형 데이터와 탐색적 분석에는 덜 유연하다.
| 영역 | 원인 |
|---|---|
| 메타데이터 | 적재할 때 업무 의미·출처·수집 주기·스키마를 기록하지 않는다. 데이터 카탈로그가 없다 |
| 거버넌스 | 데이터 소유자·관리자(스튜어드)가 정해져 있지 않고, 적재 기준·명명 규칙·표준이 없다 |
| 적재 방식 | 활용 목적 없이 원천 데이터를 모두 쌓는다("나중에 쓰겠지"). 원천·정제·가공 데이터를 한곳에 섞어 둔다 |
| 품질 관리 | 적재 시 검증을 하지 않아 오류·중복·형식 불일치가 누적된다 |
| 계보·버전 | 가공 이력과 버전을 남기지 않아 어떤 데이터가 최신·정본인지 알 수 없다 |
| 보안·수명주기 | 접근 권한과 민감정보 분류가 없고, 보존 기간·폐기 정책이 없다 |
| 조직 | 데이터 레이크를 IT 인프라 사업으로만 보고 현업의 활용 시나리오와 운영 인력을 마련하지 않는다 |
- 데이터 거버넌스: 데이터 소유자·스튜어드·관리자 역할을 정하고 적재 승인 절차, 명명 규칙, 데이터 표준을 둔다
- 목적 기반 적재: 활용 시나리오와 책임자가 있는 데이터부터 넣고, 적재 요청 시 메타데이터 등록을 필수로 한다
- 수명주기 관리: 보존 기간과 활용 실적을 기준으로 저활용·만료 데이터를 저비용 계층으로 옮기거나 폐기한다
- 데이터 카탈로그와 메타데이터 자동 수집: 스키마·프로파일·업무 용어·태그를 자동 수집하고 검색할 수 있게 한다
- 영역(Zone) 분리: 원천(Raw/Landing) → 정제(Cleansed/Standardized) → 활용(Curated) 영역으로 나눠 단계마다 품질 기준을 적용한다. 메달리온 구조(Bronze·Silver·Gold)도 같은 생각이다
- 데이터 품질 관리: 적재 파이프라인에 스키마 검증·중복 제거·규칙 검사를 넣고 품질 지표를 모니터링한다 → 데이터 품질 관리
- 계보 추적: 원천에서 가공 결과까지 변환 이력을 자동 기록한다
- 보안: 역할 기반 접근 통제, 민감정보 자동 식별·마스킹, 접근 감사 로그
- 레이크하우스: 오픈 테이블 포맷(Delta Lake, Apache Iceberg, Apache Hudi)으로 레이크 위에 트랜잭션·스키마 관리·버전(시간 여행) 기능을 더해 웨어하우스 수준의 관리성을 확보한다