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

데이터 생명 주기는 데이터가 생성되는 시점에서 가공, 저장, 활용되고 최종적으로는 폐기까지의 일련의 과정을 의미합니다 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

우아한테크

데이터의 생성부터 폐기까지의 일련의 과정을 관리하는 데이터 생명주기 관리는 스토리지 비용 절감, 쿼리 성능 유지 및 법적 리스크를 최소화하기 위한 필수적인 엔지니어링 과정입니다.

Soft Delete 이후의 잔여 유령 데이터 문제를 해결하기 위해 데이터 특성에 따라 배치 삭제, TTL, 파티셔닝과 같은 기술적 전략을 적절히 선택하여 적용해야 합니다.

데이터 폐기 시점은 법적 보존 의무를 준수하는 것은 물론, 유저의 행동 패턴과 인지 시차, 그리고 데이터 유지 비용과 비즈니스 가치가 교차하는 ROI 지점을 기준으로 정교하게 설계해야 합니다.

폐기 설계 미비가 초래하는 문제점

데이터 폐기를 설계하지 않으면 스토리지 비용 증가, 쿼리 속도 저하, 인덱싱 부하 등 기술적 부채가 누적되며, 법적 리스크에 대해서도 취약해집니다. 현실적인 서비스 운영 환경에서는 삭제 요청을 받았을 때 즉시 데이터를 물리적으로 지우기 어려운 경우가 많습니다. 예를 들어, 사용자의 복구 요청, 비즈니스 통계 반영 필요성, 대량 삭제 봇 공격 방지를 위한 검토 과정 등 다양한 변수가 존재합니다. 따라서 실제 데이터베이스에서 삭제하는 대신 상태 값을 변경하여 조회 시 마스킹하는 **'Soft Delete' 기법을 흔히 사용하지만, 이는 유령 데이터를 생성하여 인프라 비용을 가중시키는 근본적인 숙제를 남깁니다.**

기술적 폐기 전략: 배치, TTL, 파티셔닝

사용자 삭제 요청 여부와 관계없이 시간이 지나면 가치를 상실하는 데이터들이 방치되는 문제를 해결하기 위해 세 가지 기술적 접근이 필요합니다. 첫째, **배치 삭제**는 새벽 등 유휴 시간에 특정 조건의 데이터를 청크 단위로 나누어 지우는 방식으로, 복잡한 비즈니스 로직 검증이 필요할 때 유용합니다.

둘째, **TTL(Time To Live) 방식**은 세션 토큰이나 캐시 데이터처럼 만료 시간을 데이터 개별 단위로 설정하여 데이터베이스가 자동으로 관리하도록 하는 기법입니다.

셋째, **파티셔닝**은 테이블 자체를 날짜나 월 단위로 분리 설계하여 오래된 파티션을 통째로 삭제하는 방식입니다. 이는 대용량 로그 데이터처럼 대규모 데이터를 효율적으로 관리할 때 매우 효과적입니다.

데이터 유효기간 설정을 위한 기준

데이터 폐기 시점을 결정할 때 가장 우선적으로 고려해야 할 것은 **법령상의 보존 의무와 파기 의무**입니다. 전자상거래법의 결제 기록 5년 보존이나 개인정보보호법의 목적 달성 후 즉시 파기 원칙은 우리가 지켜야 할 절대적인 가이드라인입니다.

두 번째는 사용자의 '인지 시차'를 고려한 복구 유예 기간입니다. 일상적인 업무 데이터는 7일 내에, 클라우드 아카이브 데이터는 월간 루틴이 적용되는 30일 내에 복구 요청이 발생할 확률이 높습니다. 반면, **회원 탈퇴 데이터는 14일을 넘어가면 사용자가 보안 불안감을 느끼기 시작하므로 이 기간을 기준으로 정책을 설계해야 합니다.**

세 번째 기준은 경제적 효율성(ROI)입니다. 데이터의 비즈니스 가치 곡선은 시간이 지날수록 하락하지만, 유지 비용 곡선은 상승합니다. **두 곡선이 교차하여 유지비용이 데이터 가치를 추월하는 지점이 데이터를 완전히 파기해야 하는 임계점입니다.**

결론: 엔지니어링의 완성은 폐기 설계

결국 데이터 생명주기 관리는 법적 허용 범위 안에서 사용자의 행동 패턴과 인프라 비용을 통합적으로 고려하여 가장 적합한 삭제 방식을 선택하는 것입니다. 기능을 단순히 구현하는 것을 넘어 **'언제 지울 것인가'를 설계하는 것은 만든 데이터를 끝까지 책임지는 엔지니어링의 핵심 역할**입니다.

데이터 생명주기의 개념 및 중요성

데이터 생명주기는 생성부터 폐기까지의 일련의 과정(생성, 처리, 활용, 보관, 폐기)을 의미하며, 대부분의 팀은 활용 단계에 집중합니다.

폐기를 설계하지 않으면 스토리지 비용 증가, 쿼리 속도 저하, 인덱싱 부하 증가, 법적 리스크 등 문제가 발생합니다.

데이터 삭제의 복잡성과 Soft Delete

사용자의 삭제 요청 시 즉시 물리적으로 삭제하기 어려운 경우가 많습니다 (복구 요청, 비즈니스 분석 필요, 악의적 삭제 방지 등).

Soft Delete는 데이터를 물리적으로 지우지 않고 상태 값으로 마스킹하여 클라이언트에게는 삭제된 것처럼 보이게 하는 기법입니다.

Soft Delete의 문제점 및 삭제되지 않는 데이터

Soft Delete는 화면에서만 사라질 뿐 실제 스토리지 공간을 차지하는 '유령 데이터'를 발생시켜 결국 물리적 삭제 문제가 남습니다.

사용자가 직접 삭제하지 않거나 탈퇴하지 않은 게시글, 댓글, 주문 내역, 그리고 서비스 운영 및 분석을 위한 로그 데이터 등도 끊임없이 쌓여 문제가 됩니다.

데이터 삭제를 위한 기술적 방식

배치 삭제는 특정 시점에 조건에 맞는 데이터를 일괄 삭제하는 방식(예: Soft Delete 후 30일 경과 데이터 새벽에 삭제), 대량 처리 시 청크 방식을 사용합니다.

TTL(Time To Live)은 데이터 자체에 만료 기간을 설정하여 기간이 지나면 데이터베이스가 자동으로 삭제하는 방식(예: 세션 토큰, 인증 코드).

파티셔닝은 테이블 구조를 날짜/월 단위로 미리 분리하여 오래된 테이블을 통째로 삭제하는 방식(예: 접속 로그, 클릭 이벤트).

법령 준수가 최우선으로, 데이터 보존 의무(전자상거래법)와 파기 의무(개인정보보호법)를 준수해야 합니다.

사용자의 인지 시차(삭제 후 복구를 시도하기까지 걸리는 시간)를 활용하여 Soft Delete 유예 기간을 결정할 수 있습니다.

일상 업무 데이터는 7일, 아카이브 데이터는 30일, 회원 탈퇴 데이터는 보안 불안감 해소를 위해 14일 등으로 유저 심리에 맞춰 기간을 설정합니다.

ROI(투자 대비 효과)는 데이터의 비즈니스 가치 곡선과 유지 비용 곡선이 교차하는 지점을 기준으로 완전 파기 시점을 결정하는 인프라 관점의 기준입니다.

결론: 데이터 생명주기 관리의 중요성

법적 허용 범위 내에서 유저 행동 패턴과 인프라 비용을 고려하여 가장 적합한 기술로 데이터를 폐기하는 것이 데이터 생명주기 관리의 핵심입니다.

기능 구현 및 최적화만큼이나 생성된 데이터를 잘 마무리하는 것이 엔지니어링의 중요한 역할입니다.

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

스크립트