오늘 아카이브하지 않는다면…

🌐 19개 언어로도 제공

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI로 생성한 이미지

AI로 번역했습니다. 아직 커뮤니티의 검토를 거치지 않았습니다. 영어로 읽기 이 섹션은 영어판이 바뀌었으며 아직 다시 번역되지 않았습니다. (42)

Data Architect 과정 7장인 규모를 위한 설계의 모듈 4/4. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 볼륨이 공유 모델을 만날 때 · 다음: 다음 장, 쿼리와 조회 아키텍처

이 모듈이 답하는 질문: 아카이브와 영구 삭제는 어떻게 계획할까요?

When somebody tells me “we’ll archive the old records later,” I ask one question: if you’re not archiving today, are you ever going to archive? “Later” often becomes after the next release, after the migration, after the reorganization, after we fix performance, after we run out of storage. Then five years on, someone finally asks why there are 80 million records in this object. I don’t want to discover archiving after large data volume has become the problem. If I know the data will grow, I decide its lifecycle when I design it. Salesforce’s own guide says the same: “if your volume of data is increasing, performance can degrade as time goes by. A policy of archiving or discarding data at the same rate at which it comes into the system can prevent this effect” (Best Practices for Deployments with Large Data Volumes (새 탭에서 열림), Winter ‘27). ⟲

모든 레코드에는 수명 주기가 있습니다

우리는 레코드가 어떻게 생기는지, 누가 소유하는지, 누가 바꿀 수 있는지, 무엇이 권한 원천인지 물었습니다. 이제 하나 더 묻습니다. 어떻게 나가는가? 레코드는 활성에서 비활성, 아카이브, 영구 삭제로 옮겨 갈 수 있습니다. 모든 레코드에 모든 단계가 필요한 것은 아니지만, 모든 대용량 객체에는 수명 주기가 필요합니다. Steve Trucking의 배송은 진행 중일 때 끊임없이 필요합니다. 배송팀, 조정 담당, 고객 서비스, 파트너, 자동화가 모두 씁니다. 끝나고 일주일 뒤에도 여전히 유용합니다. 6개월 뒤에는 대부분 서비스 이력입니다. 3년 뒤에는 대부분 분석, 감사, 가끔 있는 분쟁용입니다. 10년 뒤에는 아무도 그것을 보관할 정당한 이유가 없을지도 모릅니다. 데이터의 가치는 시간에 따라 바뀌고, 아키텍처도 그에 따라 바뀌어야 합니다.

삭제는 피할 수 없으니, 첫날 정하십시오

언젠가는 데이터를 삭제해야 합니다. 그래서 저는 보존 정책과 영구 삭제 정책을 저장 공간이 비싸질 때가 아니라 프로젝트 초기에 정해 두기를 원합니다. 보존은 비즈니스와 규제 요구사항이 결정합니다. 얼마나 오래 운영 상태로 있어야 하나요, 얼마나 오래 보관해야 하나요, 왜, 누가 필요로 할 수 있나요, 얼마나 빨리 받아야 하나요, 결국 지워도 되나요, 그리고 개인정보 보호 측면에서 더 일찍 지워야 하나요? 5장은 모든 것을 영원히 보관하는 것이 자동으로 더 안전하지 않다는 것을 보여 주었습니다. 때로는 데이터를 더 오래 보관하는 것이 위험입니다.

세 가지 결정을 구분해 두십시오. 보존: 얼마나 오래 보관하나요? 아카이브: 더 이상 활성 워크로드에 속하지 않는 것을 어디에, 어떻게 보관하나요? 영구 삭제: 언제, 어떻게 영구히 제거하나요? 7년치 데이터가 필요하다는 것이 7년 동안 활성이라는 뜻은 아닙니다. 18개월은 활성, 나머지 기간은 아카이브, 그다음 영구 삭제일 수 있습니다. 이제 수명 주기가 명시적이 됩니다.

Purging at volume has its own mechanics, and Salesforce spells them out. Deleting a record doesn’t remove it at once: it goes to the Recycle Bin for 15 days, and while it’s there it “still affects database performance because the data is still resident, and deleted records have to be excluded from any queries.” For a purge of a million records or more, Salesforce’s advice is the hard delete option of Bulk API 2.0, which skips the Recycle Bin, and when records have many children, to delete the children first (Deleting Data (새 탭에서 열림); Best Practices: Deleting Data (새 탭에서 열림)). A purge is a data operation like any other at scale: plan it, run it in batches, and check it. ⟲

Test knowledge. Know how to purge at volume: soft-deleted records stay in the Recycle Bin for 15 days and still slow queries; for a million records or more, use Bulk API 2.0 hard delete; delete children before parents. ⟲

클릭하여 확대

Retain for seven years doesn’t mean keep active for seven years. ⟲

삭제하기 전에 백업하십시오

아카이브는 결국 활성 시스템에서 레코드를 제거한다는 뜻이니, 삭제를 설계하기 전에 복구 이야기가 필요합니다. 복구할 수 있나요, 얼마나 빨리, 무엇이 빠졌는지 정확히 아나요, 관계를 복원할 수 있나요, 테스트해 봤나요? 무엇이든 삭제하기 전에 백업이 갖춰져 있어야 합니다. 백업과 아카이브는 다른 기능입니다. 백업은 손실을 막고, 아카이브는 비즈니스에 아직 필요한 접근은 유지한 채 데이터를 의도적으로 활성 집단 밖으로 옮깁니다. 레코드 열 개를 실수로 지우면 짜증 나는 일입니다. 천만 개를 지우면 사고입니다. 0의 개수는 실수에도 적용됩니다.

이제 둘 다 Salesforce 자체에서 나옵니다. OwnBackup을 만든 회사 Own은 Salesforce Platform의 일부입니다. Own Recover는 이제 Salesforce Backup & Recover이고(데이터와 메타데이터의 일일 및 주문형 백업, 필드·레코드·객체 단위 복원, 특정 시점 복구), Archive는 거의 쓰지 않는 데이터를 저비용 저장소로 옮기면서도 아카이브 및 보존 정책에 따라 Salesforce 안에서 접근할 수 있게 유지합니다(Own From Salesforce Product Suite FAQ (새 탭에서 열림), Own’s tools, now part of Salesforce (새 탭에서 열림)).

아무도 찾을 수 없는 아카이브는 거의 삭제입니다

한 팀이 오래된 데이터를 더 싼 곳으로 옮깁니다. 아카이브 완료. 그러다 한 고객이 전화합니다. “4년 전에 배송을 받았는데, 배송 증빙이 필요해요.” 상담원이 Salesforce를 검색합니다. 아무것도 없습니다. 이제 다른 시스템, 올바른 테이블, 식별자, 관리자, 요청서, 이틀이 필요합니다. 그건 아카이브라고 하기 어렵습니다. 아카이브된 데이터가 활성 데이터처럼 동작할 필요는 없습니다. 더 느려도 되고, 읽기 전용이어도 되고, 다른 컴포넌트에 표시되어도 됩니다. 하지만 아카이브된 데이터는 비즈니스가 요구하는 만큼 찾을 수 있어야 합니다.

I’ve seen this done well at a service chain. At the very beginning of the project they told me, “We only do a hundred appointments a day at a store.” A hundred, no big deal. But they had a thousand stores, open six days a week. Do the quick math: that’s about 31 million appointments a year. Then they created two appointment records for every visit, one at the front office and one at the back, so 62 million. And they needed five years: over 300 million records. I could see large data volume coming before we’d even gone live. So right from the beginning we said: there has to be archiving before we collect a single appointment. We put the archive in big objects and built it in from the ground up. When a user searched a customer, the live appointments came first, and below them, the archived ones. The archive didn’t pretend to be active data, and nobody had to become a database administrator to find history. Active data where the operational system needs it; archived data somewhere suited to its volume; a path from the business context to both. Much better than either extreme: everything active forever, or moved somewhere nobody can find. ⟲

아카이브는 어디에 두어야 할까요?

Keeping data in core is like keeping it at the front of the office, where it’s in the way of today’s work. Somewhere in the future of any object with tens of millions of records there’s a move to the back: a box in an archive, the shed (big objects), or a hologram (virtualization, the data shown in Salesforce but living elsewhere). There’s no single answer; I choose the destination by constraint. When the customer doesn’t want an external store, I’ve used big objects: on-platform, built for very large volumes, but with no standard UI or reporting, Apex-only access and querying through the index, so plan the access path before you choose them (chapter 3’s “shed out back”). Plan the storage too: most editions are allocated storage for 1 million big object records per org, and more has to be arranged with Salesforce (Data and File Storage Allocations (새 탭에서 열림)). Two more facts matter for an archive. Big objects support only object and field permissions, not sharing rules, and triggers and flows don’t run on them. And inserting an identical record twice creates only one, so writes can be idempotent, which helps when an archive run has to restart (Big Objects (새 탭에서 열림)). ⟲

클릭하여 확대

A big object: the archive stays inside Salesforce, and you build the window users see it through. ⟲

When an external store is fine, I’ve used an off-platform database surfaced through Salesforce Connect, so archived records appear in Salesforce without being copied back. Precisely: Salesforce Connect reaches external data through OData services, other Salesforce orgs, a custom adapter built with the Apex Connector Framework, or specific adapters for Amazon DynamoDB, GraphQL and SQL (the SQL adapter supports Snowflake and Amazon Athena), so a general database usually needs an OData layer or a custom adapter in front of it (Choose Which Salesforce Connect Adapter to Use (새 탭에서 열림)). ⟲

클릭하여 확대

An external store: the archive leaves Salesforce, and Salesforce Connect brings it back into view. ⟲

The archive doesn’t have to be a database. It can be files in low-cost file storage, such as Amazon S3, and Salesforce Connect’s SQL adapter for Amazon Athena lets users “analyze data directly in Amazon Simple Storage Service (Amazon S3)” from Salesforce. One catch for an archive: that adapter is available “not for high-data-volume external objects,” so check what your volume needs before you choose it (Salesforce Connect SQL Adapter for Amazon Athena (새 탭에서 열림)). ⟲

클릭하여 확대

File storage: the same move, with files in place of a database. ⟲

And now Salesforce’s Archive is the built-in option, keeping archived records reachable from Salesforce. Third-party tools such as GRAX are in the market too. ⟲

Test knowledge. Know the archive destinations and what big objects are: built for very large volumes (consistent performance from a million records to a billion); reached through Apex, APIs and their index, not the standard UI; object and field permissions only, no sharing rules; no triggers or flows. Know the alternatives: an external store through Salesforce Connect, and Salesforce’s Archive. ⟲

제품이 교훈이 아닙니다. 특성이 교훈입니다. 데이터가 얼마나 많은지, 얼마나 자주 조회되는지, 얼마나 빨리 나타나야 하는지, 관계형 접근이 필요한지, 사용자가 Salesforce에서 찾아야 하는지, 읽기 전용이어도 되는지, 누가 볼 수 있는지, 얼마나 오래 보관하는지, 비용은 얼마인지, 결국 어떻게 영구 삭제할지. 이 답들이 기술을 고릅니다. 그리고 기억하십시오. 데이터가 물리적으로 어디에 있는지와 사용자가 어디서 그것을 발견할 수 있는지는 다른 질문입니다. 5년 된 배송은 활성 객체에 속하지 않습니다. 그렇다고 고객 서비스가 그것을 찾을 수 없어야 한다는 뜻은 아닙니다.

3단계 아카이브

When I’m moving large volumes out of an operational system, I don’t like copy, then delete in one step. There’s too much trust in it. And before the first real run, I rehearse it: a dry run that shows which records would move, ideally in a full copy sandbox, deleting nothing. Salesforce’s Archive app lets you preview an archive policy before you publish it (Archive App (새 탭에서 열림)), and other archiving tools offer a dry-run mode for the same reason. Then I use three steps: ⟲

1. Copy and flag. Copy the records to the archive and mark them in the source as pending archive. Don’t delete anything yet. Now both copies exist. On the service chain, this was a batch that ran on the weekend. ⟲
2. Verify. Re-query the source and the archive and prove the archive is right: counts, identifiers, relationships, totals or other reconciliation; can we retrieve them? For extra assurance, add checksums, or restore a sample back and compare it. Then flag them as validated. Trust but verify. Users still find the records in the source, because they aren’t archived yet. ⟲
3. Delete and flip. Only after verification, and only for records that aren’t under a legal hold, delete the active records and mark the archive complete, so the search screens now pull them from the archive. The deletion doesn’t have to follow at once; it could happen a week later. ⟲

What could go wrong with one pass, copy and delete? It didn’t copy, and you’ve deleted the records. The point is that you don’t cross the destructive boundary until you’ve proved the copy. And with the states, you can report on every archive run. ⟲

This isn’t just my habit; it’s how the serious archiving tools work. Oracle’s archive and purge, for example, validates the records, copies them to archive tables, and then purges from what it archived, with a restart program for when a run fails partway (Archive and Purge (새 탭에서 열림)). Tools that copy and delete in a single pass come with a warning to test with a dry run first (AWS Prescriptive Guidance: Archiving data from unpartitioned tables (새 탭에서 열림)). Salesforce’s Archive app respects legal holds: records under a legal hold can’t be deleted or removed (Archive App). ⟲

클릭하여 확대

Don’t cross the destructive boundary until you’ve proved the copy. ⟲

그리고 다시 시작할 수 있게 설계하십시오. 레코드 2,000만 개를 아카이브하다가 작업이 14,382,711번째 레코드에서 실패합니다. 답이 “처음부터 다시”라면 그 설계는 마음에 들지 않습니다. 큰 작업은 실패합니다. 연결이 끊기고, 작업이 시간 초과되고, 이상한 레코드 하나가 오류를 냅니다. 프로세스는 무엇이 이미 성공했는지 알아야 하고, 아카이브 상태(대기, 검증됨, 아카이브됨, 실패)가 바로 그것을 위한 것입니다. 그래야 데이터를 중복하거나 잃거나, 안전하게 아카이브되지 않은 것을 삭제하지 않고 다시 시작할 수 있습니다. 대규모에서는 재시작 가능성이 신뢰성의 일부입니다.

One more thing to know before you call a purge done: deleting the active records isn’t the same as erasing the data. Backups, caches, replicas and analytics copies may still hold it. That’s fine for an archive, and it’s exactly what chapter 5 asks you to account for when privacy law says the data must go. ⟲

Don’t Archive Everything Forever

아카이브는 삭제를 결정하지 않으려는 핑계가 될 수 있습니다. “언젠가 필요할지도 몰라요.” 아닐 수도 있습니다. 5장은 **우리가 그것을 보관해도 되는가?**를 묻습니다. 이 장은 **그것을 활성으로 유지할 가치가 있는가?**를 더합니다. 어떤 레코드는 아카이브로 가고, 어떤 것은 요약되고, 어떤 것은 익명화되고, 어떤 것은 삭제됩니다. 목표는 모든 바이트를 보존하는 것이 아닙니다. 비즈니스에 정당하게 필요한 것을, 정당하게 필요한 동안 보관하는 것입니다.

파일은 0의 개수를 바꿉니다

Unstructured data is a different scale problem. Steve Trucking expects four to five million photos a year. Purely for magnitude, at about 4 MB a photo, five million is about 20 TB in one year, before growth. The real size will vary; the zeros tell you the binary content needs its own architecture. That’s why Checkpoint 1 separated the business record about a photo from the photo itself. Salesforce may need the photo’s type, its delivery, when and by whom it was taken, where it’s stored and its retention state, or even just a count and a “required photos complete” flag. The image belongs in storage built for millions of large objects. It’s the same principle as FleetLink’s GPS: keep in core what the operational process needs, and don’t copy every high-volume artifact into core because Salesforce takes part in the process. ⟲

아카이브도 여전히 안전해야 합니다

Data leaving the active object doesn’t leave its security requirements behind. Redrock saw only Redrock’s deliveries while they were active; archive them, and Redrock still doesn’t get Keystone’s history. The archive needs an authorization model too, for Recipient personal data, photos, financial data, service history and agent access. A big-object archive doesn’t help on its own here: big objects don’t support sharing rules, so the access path you build has to carry the partner boundary. One design question for every archive: how do the original security requirements survive the move? The implementation may change; the requirement doesn’t. ⟲

에이전트와 아카이브된 데이터

수령인이 에이전트에게 묻습니다. “4년 전에 제 냉장고가 어디로 배송됐나요?” 답은 존재하지만 아카이브되어 있습니다. 에이전트가 거기에 닿을 수 있어야 할까요? 제 입장은 이렇습니다. 중요한 결정이고, 비즈니스가 내릴 결정입니다. 아키텍트는 선택지와 각각의 비용을 펼쳐 보입니다. 어떤 아카이브인지, 에이전트가 어떻게 거기에 닿는지, 지연 시간, 사용량, 오래된 데이터에 대해 에이전트가 무엇을 말해도 되는지, 보존과 개인정보 보호의 한계. 그다음 비즈니스가 결정합니다. 아카이브된 데이터에 계속 닿을 수 있어야 한다면, 인가된 조회 경로를 만드십시오. 그렇지 않다면, 아카이브 경계가 그것을 강제하게 하십시오. 제가 원하지 않는 것은 기술이 우연히 그 결정을 내리는 것입니다.

시험 너머: AI가 바꾸는 것. 이제 아카이브에는 맥락 결정이 포함됩니다. 이력이 에이전트에게 계속 닿을 수 있는가. 데이터가 아직 존재한다는 이유만으로 아카이브가 자동으로 에이전트의 맥락이 되지는 않습니다. 결정을 비즈니스에 맡긴 다음, 사람의 접근과 같은 인가 및 보존 규칙을 적용하십시오.

Steve Trucking: 필요해지기 전에 수명 주기를 정하십시오

5년 시점: 약 작업 주문 900만 건, 품목 1,450만 개, 사진 수백만 장, 그리고 의도적으로 코어 밖에 둔 상태 이력과 GPS. 저는 Steve Trucking이 5년 차가 되어서야 “오래됐다”의 뜻을 정하기를 원하지 않습니다. 정확한 기간은 아직 정해지지 않았을 수 있고, 그건 괜찮습니다. 하지만 아키텍처는 이미 묻고 있어야 합니다. 완료된 배송은 얼마나 오래 운영 상태로 남나요? 고객 서비스가 즉시 봐야 할 세부 사항은 무엇인가요? 작업 주문과 그 품목은 언제, 어디로 아카이브되나요? 어떤 이력이 Snowflake에 속하나요? 오래된 사진은 어디에 있고, 언제 삭제되나요? 리테일 파트너는 어떤 아카이브 레코드를 여전히 보나요? 에이전트가 아카이브된 배송에 닿을 수 있나요? 이것은 정리 질문이 아닙니다. 아키텍처 질문입니다.

대용량 객체마다 저는 다섯 가지 답을 원합니다. 언제 활성 상태를 멈추나요? 어디로 가나요? 거기 도착했다는 것을 어떻게 증명하나요? 그 뒤에 누군가 어떻게 찾나요? 언제 최종 삭제되나요? 이 질문에 답할 수 없다면 아카이브 전략이 있는 것이 아닙니다. 희망이 있을 뿐입니다.

클릭하여 확대

Five answers, or you have a hope. ⟲

아키텍트가 여기서 결정하는 것

• 대용량 객체마다의 활성, 아카이브, 보존, 영구 삭제 수명 주기를, 저장 공간이나 성능이 강요하기 전에 정하는 것.
• 파괴적인 아카이브나 영구 삭제 전에 어떤 백업과 복구가 갖춰져 있어야 하는지.
• 아카이브된 데이터를 어디에 둘지(빅 오브젝트, Salesforce Connect를 통한 외부 저장소, Salesforce의 Archive), 볼륨, 조회, 지연 시간, 보안, 비용, 삭제를 기준으로.
• 레코드가 삭제 경계를 넘기 전에 아카이브 실행을 어떻게 검증하고 재시작 가능하게 만드는지.
• 어떤 비정형 콘텐츠가 코어 밖에 있고 그 비즈니스 레코드는 Salesforce에 남는지, 그리고 아카이브된 데이터가 에이전트에게 계속 닿을 수 있는지.

우리는 데이터가 시스템에 어떻게 들어오는지에 많은 시간을 씁니다. API, 가져오기, 통합, 마이그레이션, 사용자, 에이전트. 데이터가 어떻게 나가는지에도 그만큼 시간을 쓰십시오. 오늘 우리가 만드는 데이터가 내일의 대용량 데이터 문제이기 때문입니다. 아카이브는 3년 뒤에야 시작될지 모릅니다. 수명 주기는 지금 있어야 합니다. 입구를 설계할 때 출구를 설계하십시오.

더 알아보기

• Trailhead, Explore Archival Versus Purge in Data Cleanup (새 탭에서 열림): back up before cleaning or moving data; archive versus purge, checked 2026-11-01. ⟲
• Salesforce Help, Archive App (새 탭에서 열림): archive policies and preview, job sessions, Log Failures and Continue, purge policies, legal holds, Archive Search and the Archive component, checked 2026-11-01. ⟲
• ISO, ISO 15489-1:2016, Records management: Concepts and principles (새 탭에서 열림) (current; confirmed 2021), checked 2026-11-01. ⟲
• Industry examples of the same pattern: Oracle, Archive and Purge (새 탭에서 열림) (Oracle Receivables: validate, archive, then purge from the archive tables, with a restart program), and AWS Prescriptive Guidance, Archiving data from unpartitioned tables (새 탭에서 열림) (a one-pass archiver; test with a dry run first), checked 2026-11-01. ⟲
• Salesforce Developers, Best Practices for Deployments with Large Data Volumes (Winter ‘27): Best Practices (새 탭에서 열림), Deleting Data (새 탭에서 열림) and Best Practices: Deleting Data (새 탭에서 열림), checked 2026-11-01. ⟲
• Salesforce Help, Data and File Storage Allocations (새 탭에서 열림), checked 2026-11-01. ⟲
• Salesforce Help, Own From Salesforce Product Suite FAQ (새 탭에서 열림), and Salesforce, Own’s tools, now part of Salesforce (새 탭에서 열림), checked 2026-11-01. ⟲
• Salesforce Help, Salesforce Connect SQL Adapter for Amazon Athena (새 탭에서 열림), checked 2026-11-01. ⟲
• Salesforce Help, Choose Which Salesforce Connect Adapter to Use (새 탭에서 열림), checked 2026-11-01. ⟲
• Salesforce Developers, Big Objects Implementation Guide (새 탭에서 열림), checked 2026-11-01. ⟲
• SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲