보존 기간

보존 기간은 데이터를 언제까지 들고 있다가 버릴지 미리 정해 둡니다. 기간이 다 된 데이터는 사람이 그때그때 판단하지 않아도 정해진 절차를 따라 치워집니다. 저장소가 끝없이 불어나지 않습니다. 남겨야 하는 기록은 그 기간 동안 지워지지 않습니다.

상세

지하철역 분실물 보관소 벽에는 안내문이 한 장 붙어 있습니다. 우산은 한 달, 지갑은 여섯 달을 두었다가 처분한다고 적혀 있습니다. 물건이 들어오면 어느 줄에 해당하는지만 보고 그 줄에 적힌 달이 되었을 때 치웁니다.

보존 기간은 기록을 버리기 전까지 들고 있어야 하는 길이입니다. 업무에 계속 쓰이거나, 한 일을 증명해야 하거나, 법이 그렇게 정했기 때문에 들고 있습니다. 영어로는 retention period 라고 부릅니다.

한국의 전자상거래 사업자는 대금결제 기록을 5년 동안 보존해야 합니다. 그 5년이 대금결제 기록의 보존 기간입니다.

기간은 대개 데이터 한 건마다 정하지 않습니다. 대금결제 기록이나 광고 기록처럼 성격이 같은 데이터를 한 종류로 묶습니다. 그 종류에 기간을 하나 겁니다. 같은 종류에 든 기록은 모두 같은 길이를 받습니다. 저장소에 따라서는 기록 하나하나에 「이 날짜까지」를 따로 적을 수도 있습니다.

보존 기간은 지울지 말지의 판단을 미리 한 번 해 두는 장치입니다. 한 번 정해 두면 그 뒤의 판단은 그 규칙을 따릅니다. 지우는 일이 그날 누가 당직인지, 얼마나 바쁜지에 흔들리지 않게 하려는 것입니다.

아래로 거는 기간과 위로 거는 기간

보존 기간은 두 방향으로 걸립니다. 최소 길이만 정하기도 합니다. 최대 길이만 정하기도 합니다. 둘 다 정하기도 합니다.

두 방향이 한 데이터에 같이 걸리기도 합니다. 한국 개인정보 보호법은 보유기간이 지난 개인정보를 지체 없이 파기하라고 합니다. 다른 법령이 보존하라고 하면 그 데이터는 남깁니다. 남긴 것은 다른 개인정보와 분리해서 저장합니다.

두 방향은 낱말이 같아서 섞이기 쉽습니다. 「보존 기간 석 달」이 「석 달은 남겨라」인지 「석 달이 지나면 지워라」인지는 그 기간을 누가 왜 걸었는지를 보고 가립니다.

법령은 같은 길이를 「보유기간」이나 「보관기간」처럼 다른 낱말로 적기도 합니다. 낱말이 달라도 가리키는 것은 데이터를 들고 있는 길이입니다.

보존 기간을 세우는 세 가지 결정

기간의 길이 하나만으로는 기계가 움직이지 못합니다. 세 가지가 더 정해져야 지워도 되는 데이터를 골라낼 수 있습니다.

첫째는 무엇을 한 덩이로 볼 것인가입니다. 기록 한 줄마다 따로 셀 수도 있습니다. 기록을 일정한 간격으로 끊어 덩이로 묶을 수도 있습니다. 대개 회계연도나 달력의 한 해가 끝날 때 끊습니다. 묶은 덩이는 처분할 때 한 단위로 다룹니다. 그래서 덩이째 지우거나 덩이째 옮길 수 있습니다.

둘째는 언제부터 세느냐입니다. 같은 5년이라도 세기 시작하는 때가 다르면 데이터가 없어지는 때가 달라집니다.

마지막 줄은 언제 끝날지 모르는 기록에 씁니다. 사건이 일어나기 전까지는 기간이 흐르기 시작하지도 않습니다.

셋째는 기간이 지난 다음에 무엇을 하느냐입니다. 대개는 파기, 곧 지우는 것입니다. 지우지 않고 다른 보관처로 넘기기도 합니다. 자세한 값을 버리고 요약만 남기는 방법도 있습니다. 넘기기와 요약 남기기는 아래 갈래 절의 「단계를 밟아 옮기기」가 다룹니다.

기간이 지나도 못 지우는 기록

보존 기간이 끝났어도 지우면 안 되는 때가 있습니다. 소송·수사·감사에 걸린 기록입니다. 이런 기록은 그 일이 끝나고 권한 있는 쪽이 알려 줄 때까지 붙들어 둡니다. 이렇게 정해진 기간 밖에서 기록을 붙들어 두는 일을 법적 보존(legal hold)이라고 부릅니다.

그래서 같은 「보존」이라는 낱말이 두 가지 일을 가리킵니다. 보안 로그 관리는 이 둘을 영어 이름으로 갈라 적습니다. 평소에 정해진 주기마다 쌓아 두는 쪽이 log retention 입니다. 원래 버렸을 기록을 남기는 쪽이 log preservation 입니다. 뒤쪽은 그 기록에 눈여겨볼 활동이 적혀 있을 때 합니다. 대개 사고 대응이나 조사를 뒷받침하려고 합니다.

TTL·축출과 갈리는 대목

셋 다 「때가 되면 데이터가 없어진다」는 이야기라 자주 섞여 쓰입니다. 무엇이 방아쇠를 당기는지가 다릅니다.

TTL(Time To Live, 살아 있을 시간)은 데이터 한 건에 붙여 두는 남은 수명입니다. 보존 기간은 대개 데이터 종류 전체에 거는 규칙입니다. 그 규칙을 한 건씩 집행하는 수단의 하나가 TTL 입니다.

축출은 담을 공간이 모자랄 때 이미 들어 있는 것을 골라 내보내는 일입니다. 시간이 아니라 남은 공간이 방아쇠입니다. 그래서 축출은 공간이 넉넉하면 영영 안 일어납니다. 보존 기간은 공간이 남아돌아도 때가 되면 일어납니다.

고를 때의 기준도 이 표에서 나옵니다. 데이터 종류 전체에 「언제까지」를 못 박아야 하면 보존 기간을 겁니다. 한 건씩 수명이 달라야 하면 TTL 을 붙입니다. 공간만 안 넘치면 언제 없어지든 상관없는 데이터라면 보존 기간을 정하지 않고 축출에 맡깁니다.

배경

시스템은 매일 기록을 남깁니다. 서버 한 대가 로그를 여러 개 쓰는 일도 흔합니다. 그래서 조직 전체가 하루에 쌓는 로그는 감당하기 버거운 양일 때가 많습니다. 이 양을 필요한 기간만큼 저장하는 데 자원이 듭니다. 기록을 만든 시스템이 버틸 수 있는 기간보다 더 오래 남겨야 할 수도 있습니다. 그러면 사본을 떠서 따로 보관하는 절차까지 세워야 합니다.

얼마나 오래 둘지는 반대쪽 두 요구가 당깁니다. 한쪽은 법과 규제입니다. 로그는 법이나 규제를 지키려고 남겨야 할 때가 많습니다.

다른 쪽은 개인정보입니다. 개인정보는 처리 목적에 필요한 기간을 넘겨 사람을 알아볼 수 있는 꼴로 두지 말아야 합니다. 유럽연합의 GDPR(General Data Protection Regulation, 일반 개인정보 보호 규정)은 이것을 저장 기간 제한(storage limitation)이라고 부릅니다. 공익 기록 보존·연구·통계에만 쓸 때는 보호 조치를 갖추는 조건으로 더 오래 둘 수 있습니다.

그래서 필요한 것은 데이터 종류마다 얼마나 오래 남길지, 필요 없어진 것을 어떻게 없앨지를 미리 정책으로 적어 두는 일입니다. 반드시 지킬 것과 되도록 지킬 것을 갈라 적습니다. 그 정책에 적히는 길이가 보존 기간입니다.

예시

법이 아래로 거는 기간 둘, 저장소가 위로 거는 기간 둘, 지우지 못하게 잠그는 기간 하나를 봅니다.

전자상거래 사업자의 거래기록

한국의 「전자상거래 등에서의 소비자보호에 관한 법률 시행령」 제6조는 사업자가 보존해야 할 거래기록과 그 기간을 이렇게 정합니다.

네 값은 모두 하한입니다. 이 기간이 끝나기 전에는 지우면 안 됩니다. 한 사업자 안에서도 기록 종류마다 길이가 다릅니다.

통신사실확인자료의 보관기간

「통신비밀보호법 시행령」 제41조는 전기통신사업자가 통신사실확인자료를 다음 기간 이상 보관하라고 정합니다. 통신사실확인자료는 통신한 일시, 상대방 번호, 인터넷 접속 기록, 기기의 위치처럼 통신이 있었다는 사실을 보여 주는 기록입니다.

표의 자료 이름은 조문에 적힌 낱말 그대로입니다. 「이상」이라는 낱말이 이 값이 하한임을 보입니다. 석 달이 지나면 지우라는 뜻이 아닙니다. 석 달 전에는 지우면 안 된다는 뜻입니다.

Apache Kafka 의 retention.ms

Kafka 4.3 은 브로커, 곧 Kafka 서버 전체에 이런 기본값을 둡니다.

log.retention.hours=168
log.cleanup.policy=delete

log.retention.hours 는 로그 파일을 지우기 전에 들고 있는 시간입니다. 기본 168시간(7일)입니다. 같은 시간을 더 작은 단위로도 걸 수 있습니다. 그래서 셋 사이에 순서가 있습니다. log.retention.ms 가 제일 앞섭니다. 그 값이 없으면 log.retention.minutes, 그것도 없으면 log.retention.hours 를 씁니다.

Kafka 는 로그를 세그먼트라는 파일 단위로 잘라 저장합니다. log.cleanup.policy 의 기본값 delete 는 보존 시간이나 크기 한도에 닿은 옛 세그먼트를 버립니다. 크기 한도는 log.retention.bytes 로 겁니다. 기본값 -1 은 크기로는 지우지 않는다는 뜻입니다.

메시지를 주제별로 모아 두는 토픽마다 retention.ms 로 따로 걸 수 있습니다. 기본값 604800000 밀리초도 7일입니다. 이 값은 컨슈머, 곧 메시지를 읽어 가는 쪽이 얼마나 빨리 읽어 가야 하는지에 대한 약속 노릇을 합니다. -1 로 두면 시간 한도가 없어집니다. 이 값들은 상한입니다. 시간이 지나면 지웁니다.

Prometheus 의 retention.time

Prometheus 는 --storage.tsdb.retention.time 으로 샘플을 얼마나 오래 둘지 정합니다. 샘플은 시간 순서로 쌓이는 측정값 하나입니다. 이 플래그도 --storage.tsdb.retention.size 도 안 주면 보존 시간은 15일(15d)입니다. 단위는 y · w · d · h · m · s · ms 를 받습니다.

크기 한도 --storage.tsdb.retention.size 의 기본값은 0 입니다. 꺼짐을 뜻합니다. 시간과 크기를 둘 다 주면 먼저 닿는 쪽을 따릅니다.

Amazon S3 Object Lock 의 보존 기간

Amazon S3(Simple Storage Service) Object Lock 은 정해 둔 기간 동안 객체가 지워지거나 덮어써지는 것을 막는 데 도움이 됩니다. 객체는 S3 에 올린 파일 하나입니다. WORM(Write Once Read Many, 한 번 쓰고 여러 번 읽기) 방식으로 저장합니다. 이 보존 기간은 앞의 Kafka · Prometheus 와 방향이 반대인 하한입니다.

기간은 객체 버전 하나마다 걸립니다. 객체 버전은 같은 이름으로 올린 객체의 한 판입니다. 보존 기간마다 보호가 풀리는 날짜(retain-until-date)가 하나 붙습니다. 그 날짜가 지나면 그 객체 버전을 덮어쓰거나 지울 수 있습니다.

날짜를 적는 길은 둘입니다. 고정 보존은 그 날짜를 바로 적습니다. 가변 보존은 날짜 대신 사건 보류(event hold)와 그 뒤로 셀 기간을 적습니다. 사건 보류는 언제 일어날지 모르는 일을 기다리는 표시입니다. 그 보류를 풀면 S3 가 그때부터 기간을 세어 날짜를 정합니다. 상세 절의 세기 시작하는 때 가운데 「정해 둔 사건이 일어난 때」와 같은 생각입니다.

법적 보존(legal hold)은 따로 겁니다. 법적 보존이 주는 보호는 보존 기간이 주는 보호와 같습니다. 다른 것은 만료일입니다. 법적 보존에는 만료일이 없어서 누가 풀 때까지 걸려 있습니다. 한 객체 버전에 보존 기간과 법적 보존을 같이 걸 수도 있습니다. 같이 걸려 있으면 둘 다 풀려야 덮어쓰거나 지울 수 있습니다. 날짜가 지나도 법적 보존이 남아 있으면 그 객체 버전은 아직 못 지웁니다.

stateDiagram-v2
    state "보존 기간만 걸렸다 · 날짜가 아직 안 정해졌다" as A
    state "보존 기간만 걸렸다 · 날짜가 정해져 있다" as B
    state "보존 기간과 법적 보존이 같이 걸렸다" as AB
    state "법적 보존만 걸렸다 · 만료일이 없다" as C
    state "덮어쓰거나 지울 수 있다" as D
    [*] --> A: 가변 보존 · 사건 보류를 적는다
    [*] --> B: 고정 보존 · 날짜를 바로 적는다
    [*] --> C: 법적 보존만 건다
    A --> B: 보류를 풀면 그때부터 기간을 센다
    B --> AB: 법적 보존을 더 건다
    AB --> B: 법적 보존을 풀었다
    AB --> C: 날짜가 지났다
    B --> D: 날짜가 지났다
    C --> D: 법적 보존을 풀었다

갈래

기간이 지난 데이터를 어떻게 치우느냐가 축입니다. 한 건씩 골라 지우기 · 덩이째 버리기 · 단계를 밟아 옮기기 셋으로 갈립니다. 셋은 훑는 비용, 지울 수 있는 단위, 끝에 남는 것이 다릅니다.

flowchart TD
    subgraph S1["한 건씩 골라 지우기"]
        A1["저장소 · 기간이 지난 기록과 안 지난 기록이 섞여 있다"]
        A1 --> A2["처음부터 끝까지 훑는다"]
        A2 --> A3["지난 것만 골라 지운다"]
    end
    subgraph S2["덩이째 버리기"]
        B1["옛 덩이 · 가장 늦은 기록까지 기간이 지났다"]
        B2["가운데 덩이 · 아직 기간 안의 기록이 있다"]
        B3["새 덩이 · 갓 쌓였다"]
        B1 --> B4["덩이째 떼어 낸다 · 안을 안 본다"]
        B2 --> B5["통째로 남긴다 · 시각이 이른 기록도 함께 남는다"]
    end
    subgraph S3["단계를 밟아 옮기기"]
        C1["갓 쌓인 데이터 · 첫 단계에 있다"]
        C1 --> C2["값싼 저장소로 옮기거나 요약본만 남긴다"]
        C2 --> C3["마지막 단계에서 지운다"]
    end

한 건씩 골라 지우기

저장소를 훑어 기간이 지난 것만 골라 지웁니다. 건마다 따로 판단하므로 기록마다 만료 시각이 달라도 됩니다. MongoDB 의 TTL 인덱스가 이 방식입니다. 백그라운드 스레드가 인덱스 값을 읽어 만료된 문서를 지웁니다. 한 번 돌 때 50000건을 지우거나, 1초를 쓰거나, 만료 문서가 바닥나면 그 인덱스에서 멈춥니다.

대가는 지우는 일이 지울 양을 따라 커진다는 것입니다. MongoDB 의 TTL 삭제는 스레드 하나로 돕니다. 부하가 크거나 만료 문서가 많으면 더 오래 걸릴 수 있습니다. PostgreSQL 에서는 대량 DELETE 가 뒷정리 작업인 VACUUM 의 부담을 남깁니다.

덩이째 버리기

저장할 때부터 데이터를 시간 순서로 덩이에 나눠 담습니다. 기간이 지난 덩이는 안을 들여다보지 않고 한꺼번에 떼어 냅니다. PostgreSQL 에서는 파티션, 곧 테이블을 미리 정한 기준으로 쪼갠 조각이 그 덩이입니다. 옛 파티션을 DROP TABLE 로 버리면 기록을 하나씩 지우지 않아서 수백만 건도 아주 빨리 지워집니다. 대량 DELETE 와 달리 VACUUM 부담도 남기지 않습니다.

대가는 덩이 단위로만 지울 수 있다는 것입니다. Kafka 는 세그먼트 안에서 가장 늦은 타임스탬프로 세그먼트 전체의 보존 시각을 정합니다. 들어온 순서는 보지 않습니다. 그래서 타임스탬프가 그 세그먼트의 가장 늦은 값보다 이른 기록은 정해진 기간보다 오래 남습니다.

Prometheus 는 샘플을 두 시간짜리 블록에 모았다가 뒤에서 차차 더 긴 블록으로 합칩니다. 합친 블록은 보존 기간의 10% 와 31일 가운데 짧은 쪽까지 길어집니다. 샘플 하나라도 기간 안에 있으면 블록 전체를 남깁니다. 블록이 길수록 기간을 넘겨 남는 몫도 커집니다.

단계를 밟아 옮기기

지우기 전에 단계를 둡니다. 단계는 두 가지입니다. 값싼 저장소로 옮기거나, 해상도를 낮춘 요약본을 남깁니다. 지우는 일은 마지막 단계에서만 합니다. 저장 클래스를 옮기는 Amazon S3 Lifecycle 과 요약본을 만드는 Thanos 로 봅니다.

Amazon S3 Lifecycle 은 값이 더 싼 저장 클래스로 옮기는 동작과 만료 동작을 따로 적습니다.

Thanos 는 시계열 샘플을 블록 단위로 쌓아 두는 시스템입니다. 그 블록을 다루는 부품이 컴팩터(Compactor)입니다. 컴팩션은 작은 덩이를 큰 덩이로 합쳐 다시 쓰는 뒷작업입니다. 컴팩터는 그 일 말고 해상도를 낮춘 요약본도 만듭니다. 이 작업을 다운샘플링이라고 부릅니다. 샘플을 다시 써서 전체 해상도를 낮추는 일입니다. 해상도를 낮춰도 긴 구간에서 보는 정확도는 잃지 않습니다. 짧은 구간을 확대해 보려면 원본이 남아 있어야 합니다. 해상도마다 보존 기간을 따로 겁니다.

flowchart TD
    N1["갓 들어온 블록 · 원본만 있다"]
    N1 --> N2["40시간이 지났다 · 원본 · 5분 요약"]
    N2 --> N3["10일이 지났다 · 원본 · 5분 요약 · 1시간 요약"]
    N3 --> N4["원본 보존 기간이 지났다 · 5분 요약 · 1시간 요약만 남는다"]
    N4 --> N5["요약 보존 기간이 지났다 · 지운다"]

원본 기간을 요약 기간보다 짧게 잡으면 오래된 구간에는 요약본만 남습니다. 그 구간은 확대해 보지 못할 수 있습니다. 요약본을 만드는 것만으로는 공간이 줄지 않습니다. 원본 블록 하나마다 조금 작거나 비슷한 크기의 블록이 둘 더 생깁니다.

운영

굴릴 때는 세 곳에서 걸립니다. 기본값이 무기한인 저장소, 기간이 지나도 바로 안 사라지는 데이터, 삭제가 닿지 않는 사본입니다. 아래 표에는 갈래 절에서 푼 컴팩션과 컴팩터가 자주 나옵니다.

기본값이 무기한인 저장소

보존 기간을 안 정하면 지우는 일이 아예 일어나지 않는 저장소가 있습니다. 처음 볼 것은 기본값입니다.

기간이 지나도 바로 사라지지 않는 데이터

만료는 대개 뒤에서 주기로 도는 작업이 처리합니다. 기간이 끝난 때와 데이터가 없어지는 때 사이에 틈이 있습니다.

Cassandra 는 지우기를 쓰기로 다룹니다. 지우면 시각이 찍힌 지움 표시를 하나 써 넣습니다. 이 표시를 툼스톤이라고 부릅니다. TTL 이 끝난 데이터에도 툼스톤이 붙습니다.

툼스톤은 유예 기간 gc_grace_seconds 가 지나야 없앨 수 있습니다. 기본값은 864000초(10일)입니다. 그 기간이 지나도 컴팩션이 돌기 전에는 남아 있습니다.

그래서 「보존 기간 7일」은 「7일째에 사라진다」가 아닙니다. 「7일이 지나면 지울 수 있는 대상이 된다」입니다.

삭제가 닿지 않는 사본

보존 기간이 끝나 지울 때는 원본만 지워서 끝나지 않습니다. 시스템에 남은 것, 정기 백업에 든 것, 장기 보관 매체에 옮긴 것까지 없애야 합니다.

백업은 바로 덮어쓰지 못할 수 있습니다. 영국 개인정보 감독기관은 삭제 요청을 다룰 때 이렇게 요구합니다. 운영 시스템에서는 바로 지우더라도 백업 속 데이터는 덮어써질 때까지 남을 수 있습니다. 그동안 그 데이터를 다른 목적에 쓰지 않는 상태(beyond use)로 둡니다. 백업이 정해진 일정에 따라 새것으로 바뀔 때 함께 사라지게 합니다.

관련 항목

보존 기간을 따로 정해 두는 데이터 종류

로그 · 감사 로그 · 메트릭 · 트레이스 · 시계열 데이터 · 백업 · 스냅샷 · 개인정보 · 거래기록 · 통신사실확인자료

기간이 끝난 데이터를 줄이거나 옮기는 수단

아카이빙 · 다운샘플링 · 롤업 · 압축 · 로그 회전 · 콜드 스토리지 · 계층형 저장소 · 스토리지 클래스 · 파기

만료를 기계가 집행하게 하는 장치

TTL · TTL 인덱스 · 축출 · 수명 주기 정책 · 툼스톤 · 컴팩션 · 가비지 컬렉션 · 파티셔닝 · 파티션 · 로그 세그먼트

기간 동안 지우지 못하게 붙드는 장치

법적 보존 · WORM · S3 Object Lock · 불변 스토리지

보존 기간이 걸리는 데이터를 담는 저장소

객체 스토리지 · 시계열 데이터베이스 · 데이터 레이크 · 데이터 웨어하우스 · 로그 수집 · 검색 색인

보존 기간을 설정으로 거는 제품

Apache Kafka · Prometheus · Thanos · Amazon S3 · CloudWatch · Grafana Loki · MongoDB · Amazon DynamoDB · Cassandra · PostgreSQL

보존 기간 길이를 밀고 당기는 요구

저장 비용 · 규제 준수 · 전자 증거 개시 · 잊힐 권리 · 데이터 최소화 · 저장 기간 제한 · 용량 계획

보존 기간을 정하는 법령과 기록 관리 규정

GDPR · 개인정보 보호법 · 통신비밀보호법 · 전자상거래법 · 보존 일정 · 기록 관리

보존 기간과 함께 정하는 복구 목표

백업과 복구 · 복구 시점 목표 · 복구 시간 목표 · 증분 백업 · 세대 관리

보존 기간과 헷갈리는 이웃 개념

신선도 · 낡은 데이터 · 무효화 · 만료 · 유예 기간