안녕하세요 이번에 데이터 생명주기 주제로 발표를 준비한 우디입니다 여러분 혹시 데이터 생명주기가 무엇인지 아시나요?

데이터 생명 주기는 데이터가 생성되는 시점에서 가공, 저장, 활용되고 최종적으로는 폐기까지의 일련의 과정을 의미합니다 API 요청이나 시스템 이벤트를 통해 데이터가 수집되는 생성 단계를 거쳐 처리 단계에서는 수집된 데이터를 정제하고 구조화하여 DB에 저장합니다 활용 단계에서는 저장된 데이터를 요청에 의해 내보내거나 분석을 통한 개인화 추천 등 실제 비즈니스 가치를 만들어냅니다 아마도 대부분의 팀들이 가장 공들이는 단계이기도 하죠 그리고 보관 단계에서는 이렇게 수집된 데이터들 중에서 자주 쓰지는 않지만 여전히 조회되거나 복구될 가능성이 있는 그런 데이터에 대해서 따로 분리하여 보관합니다 그리고 마지막으로 폐기는 분리한 데이터들 중에서 이렇게 사용 가능성이 없는 데이터들을 삭제하는 과정인 거죠 그런데 우리는 흔히 데이터를 어떻게 저장하고 그 다음에 어떻게 활용할지에 집중하지만 정작 우리가 저장한 데이터가 언제 폐기될 것인지에 대해 한번 고민해보신 적 있으신가요?

폐기를 설계하지 않으면 이와 같이 문제가 조용히 쌓입니다 저장된 데이터는 계속 쌓이면서 스토리지의 비용은 증가하고 쿼리 속도는 느려지면서 인덱싱 부하도 커집니다 또한 법적 리스크에 대해서도 취약해지죠 이번 발표에서는 이러한 내용에 대해서 한 번 얘기해 보려고 합니다 일반적으로 서비스에서는 사용자의 삭제 요청을 받게 되면 우리는 해당 데이터를 더 이상 사용자 화면에 보여주지 않은 상태로 변경해야 합니다 가장 확실한 방법은 데이터베이스에서 해당 데이터를 지워버리면 되지만, 현실에서는 그렇게 단순하게 처리할 수 없는 상황들이 빈번하게 발생합니다 예를 들어 사용자가 삭제 후 시간이 지난 뒤 다시 복구 요청을 하는 경우 삭제 요청을 했어도 일정 기간 동안 해당 데이터가 비즈니스 통계나 트렌드 분석에 포함되어야 하는 경우 또는 악의적인 사용자가 봇을 이용해 대량으로 데이터를 삭제하는 것을 방지하기 위해 관리자가 최종 검토가 필요한 경우 이외에도 여러 다양한 경우에서 단순히 삭제 요청된 데이터를 바로 지우는 것은 적절하지 않은 행위입니다 이를 위해 Soft Delete라는 기법을 사용합니다 Soft Delete는 실제로 데이터를 물리적으로 지우는 대신 데이터의 상태 값을 나타내는 컬럼을 별도로 두어 조회할 때 이 마스킹 된 데이터를 제외하고 전달합니다 그래서 결과적으로는 클라이언트 입장에서는 데이터가 완벽히 지워진 것처럼 보일 수 있는 거죠 하지만 데이터를 Soft Delete로 처리한다면 인프라 관점에서는 어떻게 될까요?

이게 괜찮을까요? 그렇지 않습니다 이 데이터는 화면에서만 사라졌을 뿐 여전히 데이터베이스 스토리지를 차지하고 있는 유령 데이터가 됩니다 지웠다고 생각한 데이터가 실제로는 서버 뒤편에서 고스란히 남아 차곡차곡 차고 쌓이고 있는 것이죠 결국 이 Soft Delete는 언제 숨길 것인가를 정의했지 언제 진짜로 지울 것인가 라는 숙제가 거의 남아있는 상태입니다 근데 이렇게 Soft Delete 된 누적된 유령 데이터들 뿐만 아니라, 삭제 요청이 없는 데이터들도 동일한 문제를 갖고 있습니다 사용자가 작성한 게시글, 댓글, 주문내역 등은 사용자가 직접 삭제 요청을 하거나 탈퇴하지 않는 이상 데이터베이스에 여전히 계속 남아 있습니다 또한 서비스 운영을 위한 에러 로그 비즈니스 분석을 위한 구매 패턴 개인화 추천을 위한 접속 기록이나 체류 시간과 같은 사용자의 행위 로그 데이터들도 끊임없이 쌓입니다 그렇다면 이 데이터들을 별도의 삭제 요청이 없다는 이유만으로 계속 저장하고 있는 것이 맞을까요?

삭제 요청이 없다는 건 계속 들고 있어야 된다는 뜻이 아닙니다 이러한 유령 데이터와 비대해지는 데이터베이스를 해결하기 위해 몇 가지 기술적인 방식들이 존재하는데요 저는 여기서 세 가지 방법에 대해서 아주 간단하게 소개하겠습니다 첫 번째로 배치입니다 배치 삭제는 특정 시점에 조건에 맞는 데이터를 한 번에 지우는 방식입니다 예를 들어 매일 사용량이 적은 시간인 새벽에 Soft Delete가 된 지 30일이 지난 데이터를 실제로 삭제하는 규칙을 세웁니다 이때 수십만 건의 데이터를 한 번에 지우려고 하면 데이터베이스에서 순간적으로 강한 부하가 걸릴 수 있습니다 이를 위해 보통 수천 건씩 나눠 지우는 이 청크 방식을 사용합니다 배치는 연관된 데이터를 함께 처리하거나 삭제 전 특정 비즈니스 조건을 검증해야 할 때 많이 사용합니다 두번째는 TTL 방식입니다 TTL은 데이터 자체의 기간을 설정해두고 해당 기간이 지나면 별도의 삭제 로직을 작성하지 않아도 데이터베이스가 자동으로 데이터를 일괄 삭제하도록 하는 방식입니다 배치는 정해진 주기마다 데이터를 일괄 처리하는 방식인 반면에 TTL은 데이터 개별 단위로 만료 시간을 추적합니다 주로 세션토큰, 인증코드, 캐시 데이터처럼 일정한 시간이 지나면 의미가 완전히 사라지는 휘발성 데이터를 관리할 때 사용됩니다 세 번째는 파티셔닝 방식입니다 앞서 배치 삭제와 TTL은 삭제를 어떻게 실행하느냐의 방식이라면 파티셔닝은 삭제가 빠르게 일어나도록 설계 단계에서부터 테이블 구조를 변경하는 방식입니다 데이터베이스 테이블을 날짜나 월 단위로 미리 분리하여 형성하고 오래된 테이블을 통째로 아예 날려버리는 방식이죠 수백만 건의 데이터를 레코드 단위로 하나씩 찾아가며 주는 것보다 훨씬 효율적으로 관리할 수 있습니다 이는 주로 접속 로그나 클릭 이벤트처럼 대용량이고 시간 기반으로 대량 녹취되는 데이터를 관리할 때 사용됩니다 그럼 이렇게 삭제 방식은 알겠는데 그럼 여기서 설정하는 유효 기간은 어떤 기준으로 설정을 해야 될까요?

가장 우선적으로 고려해야 될 것은 당연히 이제 바로 법령입니다 법에는 크게 데이터를 특정 기간 동안 반드시 보존해야 하는 보존의 의무와 특정 시점이 지나면 반드시 지워야 하는 파기의 의무가 있습니다 대표적으로 전자상거래법에서 결제 및 거래기록은 5년간 보존해야 하는 보존의 의무가 있으며 개인정보보호법에서는 수집 목적이 달성된 개인정보는 바로 즉시 파기해야 하는 파기의 의무가 있습니다 이처럼 법은 우리가 데이터를 삭제할 수 있는 시점과 반드시 삭제해야 하는 시점에 양쪽 한계선을 규정해주는 절대적인 가이드 라인입니다 다음 두 번째로는 사람의 행동 심리를 분석한 인지 시차를 활용할 수 있습니다 인지 시차의 원래 정의는 어떤 변화나 현상이 발생한 그 시점에서 그것을 인지하는 그 시점 사이에 시간적 간격을 의미합니다 그런데 여기서 이 데이터 삭제에서는 이 인지 시차를 사용자가 삭제 요청을 잘못되었음을 깨닫고 복구를 시도하기까지 걸리는 시간으로 활용할 수 있죠 즉, Soft Delete의 유예기간을 얼마 동안 복구 가능한 상태로 들고 있는 것인가를 결정하는 유저 관점의 기준입니다 그런데 유저들의 복구 요청 패턴을 분석해보면 데이터 종류에 따라 곡선의 형태가 달라지는 것을 알 수 있습니다 메일이나 협업 툴처럼 매일 쓰는 일상적인 업무 데이터의 경우 일주일 단위의 주간 루틴 안에서 대부분의 실수를 알아차리고 복구를 마칩니다 시간이 지나면서 데이터를 다시 찾을 확률이 급격히 낮아지고 7일이 지나면 유저가 그 데이터를 다시 찾을 확률이 사실상 0에 수렴하게 되죠 반면 클라우드 사진이나 과거 게시글 같은 아카이브 데이터는 조금 다릅니다 삭제 직후에는 존재를 잊고 지내다가 한 달에 단위의 월말 정리라든지 아니면 디바이스 용량 확보 등과 같은 월간 루틴이 들어올 때 비로소 삭제 사실을 뒤늦게 인지하게 됩니다 자주 접근하지 않은 데이터일수록 삭제 사실이 기억 속에 희미해지고 이 인지 시점은 다음 접근 계기가 생길 때까지 자연스럽게 밀리게 됩니다 즉, 이 삭제 요청은 뒤늦은 복구 요청이 증가하는 이 두 번째 피크이자 마지노선이 바로 이 30일입니다 구글 드라이브, 인스타그램 스마트폰 사진 어플과 같이 이 30일의 유예 기간을 쓰는 배경이 바로 이 월간 생활 주기에 기반합니다 여기에 더해 계정 탈퇴와 같은 유저의 심리를 임계점으로 또 다르게 접근해야 합니다 유저가 탈퇴 후 마음이 바뀌어 복구를 요청하는 행위는 보통 초기 2주 이내에 집중됩니다 그런데 이 14일이라는 마지노선을 넘어가면 유저의 심리는 보안 불안감으로 전환됩니다 내 데이터가 아직도 서버에 남아있는 것이 아닌가 하는 불안감을 느끼기 시작하는 거죠 결론적으로 일반 데이터 복구는 일상 업무 데이터와 유저의 월간 루틴에 맞춰 7일과 30일로 설정하되 이 회원 탈퇴 시 데이터 보유는 보안 불안감을 해소하기 위해 14일에 유예 기간을 주는 등 유저의 심리와 행동 패턴에 맞춘 정교한 설계가 필요합니다 그리고 여기서 또 들 수 있는 것이 이제 ROI 즉, 투자 대비 효과입니다 인지 시차가 Soft Delete의 유효기간을 결정하는 유저 관점의 기준이라면 ROI는 데이터를 서비스에서 완전히 파기할 상한선을 정하는 인프라 관점의 기준입니다 대부분의 데이터는 시간이 흐를수록 비즈니스적 가치 곡선이 급격하게 우하향합니다 여기서 이 비즈니스적 가치란 이 데이터가 생성된 후 시간이 지남에 따라 실제로 조회될 확률과 조회 1회당 비즈니스에 기여하는 환산 금액을 곱해 산출합니다 반면 그 데이터를 유지하기 위한 지불해야 하는 스토리지 비용과 인덱싱 부하 등 비용 곡선은 우상향하게 되어있죠 바로 이 두 곡선이 교차하는 지점이 즉, 유지비용이 데이터의 가치를 추월하는 시점이 바로 우리가 데이터를 서버에서 완전히 지워야 하는 임계점이 됩니다 정리하면 우리는 매일 쌓이는 데이터를 해결하기 위해 어떻게 지울지 그리고 언제 지울 지를 자를 수 있습니다 배치 삭제, TTL 파티셔닝과 같은 기술적 방법을 활용할 수 있고 법적 의무, 유저의 인지 시착 그리고 비용과 가치의 교차점을 기준으로 이 기간을 정할 수도 있습니다 결국, 법이 허용하는 범위 안에서 유저의 행동 패턴과 인프라 비용을 기준으로 가장 적합한 기술로 지은 게 바로 데이터 생명주기 관리에서 폐기에 해당되는 내용입니다 기능을 구현 최적화하는 것도 물론 중요하지만 여기에 이 데이터를 언제 지울까라는 기준을 추가해보는 것도 좋을 것 같습니다 기능을 잘 만드는 것만큼 그 기능에 만든 데이터를 잘 마무리하는 것도 엔지니어링의 역할이 아닐까 생각합니다 이상으로 마무리하겠습니다

[10분 테코톡] 우디의 데이터에도 유효기간이 있다 - 데이터 생명주기 관리

우아한형제들의 기술조직 이야기를 전하는 우아한테크입니다.

우아한형제들 https://www.woowahan.com/
우아한테크 Facebook https://www.facebook.com/woowahanTech
우아한형제들 기술블로그 https://techblog.woowahan.com

[10분 테코톡] 우디의 데이터에도 유효기간이 있다 - 데이터 생명주기 관리

Scripts