Garbage-In, Garbage-Out, True?

GIGO는 항상 참인 명제일까? 아니면 매우 상대적인 개념일까?

데이터 관리 영역에서 전문가이든, 비전문가이든 모두가 쉽게 인용하는 어구가 Garbage-In, Garbage-Out입니다. 매우 의미 있는 경구이지만 항상 참인 것은 아닙니다. 왜냐하면 인용하는 사람들의 Garbage에 대한 정의가 부정확하거나 심지어는 Garbage에 대해 깊이 생각한 적이 없기 때문입니다.
유용한 데이터만 챙기기에도 힘에 부치는데 왜, 굳이 Garbage에 대해 생각해야 하느냐고 반문할 수 있습니다. 그러나, 옛이야기에서 소중한 고문서를 알아보지 못하고 묵은 짐을 정리하면서 버려버린 무지한 후손들의 경우를 가끔 마주하게 되는데, 데이터에 있어서도 Garbage인 줄 알았던 것이 나중에 매우 중요한 데이터 분석에서 필수적인 것임을 깨닫게 되는 경우도 그다지 드물지 않습니다. 즉, Garbage를 구별할 능력이나 경험이 없는 분들이 Garbage를 제거해야 한다고 주장하는 것은 얼핏 맞지만 곰곰이 생각하면 헛된 주장일 경우가 많습니다. 우리나라 5대 대기업군 중의 한 곳도 이러한 악한 영향력을 피하기 어려웠던 경험이 있습니다.

기업의 IT 시스템이 만들어내는 Garbage란 무엇일까요? 공장 운영에 필요한 데이터는 빅데이터레이크에는 Garbage일까요? 빅데이터 분석을 할 때 대부분의 시간을 데이터 준비에 할애하게 되는데 대개 그 첫걸음 중의 하나가 분석에 필요한 데이터만 남기기 위해서 운영용 데이터를 구별하는 것입니다. 그러나 또 다른 분석 업무에서는 그 운영 데이터도 분석 목적으로 필요한 경우도 있고요...

데이터 정제의 중요성은 언제나 높습니다. 데이터의 품질은 분석의 품질을 좌우합니다. 그러나 단순히 데이터 양이나 종류를 가지고 걸러내야 할 Garbage로 정의하는 것은 극도로 주의해야 합니다. Garbage는 상대적인 개념입니다. 절대적 쓰레기 데이터란 없습니다. 그렇다고 무턱대고 모든 데이터를 저장하고 정제하고 통합할 일도 아닙니다. 빅데이터레이크를 구축하는 단계나 시점별로 Garbage의 정의와 구별 방법이 달라질 필요도 있습니다.

그래서 Data Vault Modeling이 필요하고 Data Mesh Architecture가 나오고, Data LakeHouse라는 신조어 및 개념이 주장되고 있습니다. 대개는 이론적일 뿐 실제적인 사례가 드문 경우가 많지만, 또 한편으로는 기업들은 이와 유사한 아키텍처를 적용해서 이미 데이터 관리를 진행하고 있습니다. 이와 같이 미래의 혁신을 준비하면서도 현실적인 접근을 허용하는 지혜로운 접근들을 집중해서 살피고 있습니다. 그 내용들을 조만간 여러분과 나눌 수 있기를 소망합니다.