볼륨이 모든 것을 바꿀 때
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)
Data Architect 과정 7장인 규모를 위한 설계의 모듈 1/4이자 파트 2의 시작. 각 모듈은 독립적으로 읽을 수 있습니다. 다음: 핫스팟: 소유권, 부모, 조회 스큐
이 모듈이 답하는 질문: 데이터가 커지면 무엇이 언제 깨질까요?
A design can be perfectly reasonable at 70,000 records and completely wrong at 70 million. That’s one of the things that makes data architecture difficult. The object is the same. The fields are the same. The relationships are the same. The business requirement may even be the same. But add a few zeros and the architecture changes. ⟲
여기서 우리는 보기에서 설계하기로 넘어갑니다. 파트 1에서는 비즈니스, 데이터 모델, 엔터프라이즈 랜드스케이프, 거버넌스, 권한 원천을 보는 법을 배웠습니다. 이제 그 아키텍처에 무게를 싣습니다. 그리고 제가 던지는 첫 질문은 이것입니다. 이게 얼마나 커질까요?
Built for Transactions
섹션 제목: “Built for Transactions”Salesforce runs some of the largest CRM implementations in the world, and its core database handles “upwards of 1.1 trillion transactions per month.” Salesforce’s own architects describe that database as “optimized for high-performance transactional workloads on structured data” (The Salesforce Platform: Transformed for Tomorrow (새 탭에서 열림)). It’s built for that: transactional work on structured data. And every record comes with a lot of built-in capabilities and functionality that are part of the core Salesforce platform: the object model, sharing and security, pages, reports, automation, search. All of it runs on a multitenant database, where Salesforce writes the SQL, not you. ⟲
I once taught this class at Dreamforce to a room with a lot of database administrators from Oracle and SQL Server, and of course they were asking, “Why doesn’t Salesforce act this way? Why doesn’t Salesforce do this?” By the end they were smiling, because they’d understood why. Chapter 3 described Salesforce as a multitenant, metadata-driven platform: the apartment building. We’re not tuning our own dedicated database. Salesforce’s storage, indexing, sharing, locking, query optimization and resource protections are designed for many tenants at once. That’s not bad; it’s why we get so much capability without running database infrastructure. But it means the architect needs to understand the platform’s shape. ⟲
Salesforce says it plainly in its own guide: as data sets get larger, “the time required for certain operations grows,” and the architect’s choices change that time “by several orders of magnitude” (Best Practices for Deployments with Large Data Volumes (새 탭에서 열림)). That’s not a weakness. It’s the design. At small volumes you can sometimes ignore the platform’s shape. At large volumes, it reminds you it’s there, and we’ll see that very clearly with selectivity and indexes in the next chapter. That’s why the architect has to know how big this gets. ⟲
The same guide ends with the other half of the story. Salesforce is “a robust environment in which native and custom applications can scale to large volumes of data very quickly while continuing to perform well,” and it names the two ways you get there: make queries selective, and reduce the amount of active data. Millions of records can perform well on Salesforce. They perform well because somebody designed for them. That’s what this part of the course is about. ⟲
저의 대용량 데이터 눈금자
섹션 제목: “저의 대용량 데이터 눈금자 ”When I’m teaching large data volumes, I use a rough ruler. It’s not a Salesforce limit. The numbers are general figures discussed in the community, and Salesforce itself calls a large data volume “an imprecise, elastic term”: tens of thousands of users, tens of millions of records, or hundreds of gigabytes of storage (Best Practices for Deployments with Large Data Volumes (새 탭에서 열림)). And when I say records, I mean records in a single object, not across all your objects. ⟲
Like every number in this course, the ruler has a date on it. More on that in a moment. ⟲
At about 1 million records in an object, there’s just a little bit of drag as dashboards and reports show up. Not a lot, depending on how you filter. Around 10 million, there’s some effect, but it’s still performing. Heading toward 50 million, you start to notice it: list views taking two, three, four seconds, reports and dashboards taking time. Past 50 million, I like to say you’re driving a convertible with your head out the window, and your hair is blown back. Don’t stick your head out the window: past 50 million you’ve got to be streamlined, and you’ve got to know what you’re doing. And once we’re talking about 100 million records or more, I start asking a different question: should these records be here at all? I’ve heard of people running a hundred million or more in an object. But if you’re at 50 million today, you’re going to 100, 150, 200 million in the years ahead. If you’re not archiving today, when will you? If somebody tells me they have 150 million records in an object and almost nobody ever looks at the old ones, that’s not an operational object any more. That’s an audit log. ⟲
눈금자가 100만에서 시작하는 것은 우연이 아닙니다. 다음 장에서 보듯이, 플랫폼 자체의 쿼리 계산도 “처음 100만 개의 레코드”에서 바뀝니다. 하지만 정확한 숫자가 교훈은 아닙니다. 교훈은 이것입니다. 볼륨이 설계를 바꿉니다.
Every zero changes what you notice. A rule of thumb, not a limit. ⟲
The Platform Keeps Growing
섹션 제목: “The Platform Keeps Growing”Salesforce ships three releases a year. Over time the platform grows, some limits are raised, and systems get faster. So I don’t want you to treat any number in this course as if it were permanent, including mine. Salesforce keeps every release’s edition of its guides online, which means we can do something useful: put ten years side by side. Here’s Winter ‘16, from late 2015, next to Winter ‘27, from 2026. ⟲
| Winter ‘16 (2015) | Winter ‘27 (2026) | |
|---|---|---|
| Big objects | Didn’t exist yet | “Consistent performance, whether you have 1 million records, 100 million, or even 1 billion” |
| Skinny table columns | 100 | 200 |
| Index selectivity thresholds | Capped at 1 million records (standard) and 333,333 (custom) | No published cap, and the optimizer can add an index on its own |
| Minimum data storage | 1 GB per org, or 20 MB per user | 10 GB per org, plus storage per user |
| Bulk API batches a day | 5,000 | 15,000 |
| Parent-to-child levels in one SOQL query | 1 | 5 |
| Apex heap per transaction | 6 MB (12 MB asynchronous) | 10 MB (25 MB asynchronous) |
That’s the upward direction: limits raised, caps removed, new kinds of storage, and an optimizer that now “recognizes that an index can improve performance for frequently run queries” and adds one (Working with Very Large SOQL Queries (새 탭에서 열림)). ⟲
Now look at what didn’t move in those ten years. The definition of a large data volume is word for word the same: “tens of thousands of users, tens of millions of records, or hundreds of gigabytes.” The advice to avoid having any user own more than 10,000 records is the same. And an Apex transaction still gets 100 SOQL queries, 50,000 records and 10 seconds of CPU (Execution Governors and Limits (새 탭에서 열림)). Those are the house rules of the apartment building, the guardrails that keep one tenant from hurting the others, and they’ve barely moved. ⟲
Salesforce is open about the pace, too. It ships three releases a year, each with a new API version, and it commits to “supporting each API version for a minimum of 3 years from the date of first release,” with at least a year’s notice before support for a version ends (SOAP API End-of-Life Policy (새 탭에서 열림)). In practice versions live much longer: as I write this, version 41.0, from Winter ‘18, is still supported. If you’re new, you don’t need the history. But it does change decisions. The org you inherit was designed under older limits, and some of its workarounds may not be needed any more. The integration you build today is pinned to an API version with a clock on it. And study material written a few releases ago may still teach yesterday’s numbers. ⟲
So when you read a number in this course, read the date next to it. The specific limits will keep changing, mostly upward, and Salesforce will keep pivoting. The thinking won’t: know your Number of Zeros, keep the active data small, make your queries selective, and check the current edition of the guide before you commit to a number. That’s why I teach the ruler as a ruler, not a law. For now, it’s a good place to start. ⟲
The sources, both editions: Best Practices for Deployments with Large Data Volumes, Winter ‘16 (새 탭에서 열림) (archived copy (새 탭에서 열림)) and Winter ‘27 (새 탭에서 열림) (archived copy (새 탭에서 열림)); Salesforce Limits Quick Reference Guide, Winter ‘16 (새 탭에서 열림) (archived copy (새 탭에서 열림)), and Salesforce Developer Limits and Allocations Quick Reference, Winter ‘27 (새 탭에서 열림) (archived copy (새 탭에서 열림)); Data and File Storage Allocations (새 탭에서 열림) (10 GB “starting in late March 2019”); Execution Governors and Limits (새 탭에서 열림), Winter ‘27. ⟲
오늘 얼마나 큰지 묻지 마십시오
섹션 제목: “오늘 얼마나 큰지 묻지 마십시오 ”One of the easiest mistakes is sizing an architecture from today’s data. Steve Trucking has about 1 million deliveries a year. If I only ask “can Salesforce handle one million deliveries?”, I’m asking the wrong question. Steve Trucking expects about 30% annual growth: 1.0 million in year one, 1.3 in year two, 1.69 in year three, about 2.2 in year four, about 2.86 in year five. That’s annual volume. If we keep all five years, we’re not designing for 2.86 million deliveries; we’re designing for roughly 9.04 million. And that’s before we ask how much history already exists. ⟲
그래서 저는 스티브의 0의 개수(Steve’s Number of Zeros)를 가르칩니다. 처음부터 가짜 정밀도에 집착하지 마십시오. 올바른 자릿수를 찾으십시오. 만, 10만, 100만, 1,000만, 1억? 0을 하나 더할 때마다 아키텍처가 바뀔 수 있습니다.
이제 자식을 곱하십시오
섹션 제목: “이제 자식을 곱하십시오 ”The delivery isn’t the only record. Steve Trucking averages about 1.6 line items a delivery, so over five years that’s about 14.5 million work order line items. And there are around eight status changes a delivery: about 72.3 million status events. The requirement sounded like “track deliveries.” The architecture has to deal with tens of millions of related records. One million parents with eight children each is not a one-million-record problem. You have to follow the model. ⟲
그리고 코어에 넣지 않은 데이터
섹션 제목: “그리고 코어에 넣지 않은 데이터 ”Checkpoint 1 also gave us four to five million photos a year, and FleetLink produces about 200,000 GPS readings a day: roughly 73 million a year before growth. That’s why we decided not to put every GPS reading, every photo or every status change into the Salesforce operational model. We hadn’t even started this chapter, and the Number of Zeros was already telling us something. It’s like telling the doctor, “It hurts when I raise my arm,” and the doctor says, “Then don’t raise your arm.” Sometimes the best way to solve a large-data-volume problem is don’t create it in the first place. ⟲
느려지는 것은 쿼리만이 아닙니다
섹션 제목: “느려지는 것은 쿼리만이 아닙니다 ”When people hear large data volumes, they think “queries get slow.” Yes, and the next chapter is all about query and retrieval. But it’s bigger than that. As volume grows, I care about sharing calculations, ownership, record locking, parent-child relationships, list views, related lists, reports, search results, batch processing, integrations, data loads, deletes, archiving, backups and recovery. Even a harmless-looking decision gets expensive when it’s repeated millions of times. ⟲
That’s the lesson: what works today may fail tomorrow. Maybe nobody notices at 50,000 records, or at 500,000. Then growth pushes the object through several million, and an old design assumption becomes the bottleneck. The system didn’t randomly go bad. The architecture crossed the scale where that decision mattered. ⟲
깔끔한 모델이 비싼 모델이 될 수 있습니다
섹션 제목: “깔끔한 모델이 비싼 모델이 될 수 있습니다 ”My starting position is still: design clean first, then back off when necessary. Understand the entities and relationships; don’t duplicate data because it’s convenient. But normalization is a principle, not a rule. If a report or operational query constantly has to walk several relationships across tens of millions of records to get one value, at some scale I may copy that value closer to where it’s used. That’s denormalization. ⟲
파트너별 작업 주문 품목 보고서가 리테일 파트너(Retail Partner)를 계속 필요로 한다고 해 봅시다. 깔끔한 모델에서 파트너는 두 단계 떨어져 있습니다. 품목 → 작업 주문 → 파트너. 볼륨이 충분하면 파트너 식별자의 관리되는 사본을 품목에 직접 둘 이유가 생길 수 있습니다. 그러면 저는 중복 데이터를 만든 것이고, 거기에는 책임이 따릅니다. 어떻게 채우나요? 바뀔 수 있나요? 어떻게 정확하게 유지하나요? 어느 사본이 권한 원천인가요? 실제 비용이고, 저는 비즈니스에 필요한 성능을 얻으려고 통제된 중복을 받아들일 때가 있습니다. 정규화를 향해 설계한 다음, 볼륨이 이유를 줄 때 의도적으로 물러서십시오. 만들기 쉬워서 비정규화하지 말고, 얻는 이점과 받아들이는 비용을 설명할 수 있기 때문에 비정규화하십시오.
핵심 CRM을 데이터 웨어하우스로 만들지 마십시오
섹션 제목: “핵심 CRM을 데이터 웨어하우스로 만들지 마십시오 ”제가 보는 볼륨 실수가 하나 더 있습니다. 비즈니스가 보고서를 원하니 운영 CRM에 이력 데이터를 계속 넣고, 또 넣다가, 결국 정당화가 “보고서에 필요해요”가 됩니다. 그때 저는 우리가 운영 시스템을 분석 시스템으로 바꿔 버린 것은 아닌지 묻습니다. 둘은 다른 워크로드입니다. Steve Trucking은 오늘의 배송을 돌리기 위해 Salesforce가 필요합니다. 고객 서비스는 오늘의 상태가, 배차 담당은 오늘의 경로가, 파트너는 오늘의 진행 상황이 필요합니다. 지역, 파트너, 트럭, 날씨, 배송팀, 배송 시간대별로 5년간의 배송 성과를 재무와 결합해 비교하는 분석가는 분석 워크로드를 가진 것입니다. Salesforce는 운영 데이터로 보고서를 만들 수 있습니다. 그렇다고 모든 이력 분석 질문이 운영 저장소에 속한다는 뜻은 아닙니다. Steve Trucking에는 이미 Snowflake가 있습니다. 그러니 물으십시오. 운영 시스템이 답해야 할 질문은 무엇이고, 분석 플랫폼에 속하는 질문은 무엇인가요? 데이터 웨어하우스는 파트 3에서 깊이 다룹니다.
그리고 보고서 스냅샷은 데이터 웨어하우스 전략이 아닙니다. 평평하게 펼친 보고용 객체, 스냅샷 레코드, 보고를 쉽게 하려고 복사한 값은 때로는 정당합니다. 하지만 아키텍처 질문을 뒤로 미루는 방법이 될 수도 있습니다. 이미 가진 수백만 개를 보고하려고 수백만 개의 레코드를 더 만든다면, 그게 어디서 끝나는지 알고 싶습니다. 아무도 데이터 웨어하우스 이야기를 하고 싶어 하지 않는다는 이유로 운영 레코드를 계속 만들지 마십시오.
볼륨에는 모양이 있습니다
섹션 제목: “볼륨에는 모양이 있습니다 ”두 시스템이 각각 레코드 2,000만 개를 가지고 있어도 아주 다르게 동작할 수 있습니다. 하나는 이력 레코드 2,000만 개로, 거의 갱신되지 않고, 보통 알려진 ID로 하나씩 읽히며, 공유도 복잡하지 않습니다. 다른 하나는 활성 레코드 2,000만 개로, 끊임없이 갱신되고, 소유권이 복잡하고, 보고서도 사용자도 많고, 상위-하위 쏠림이 크고, 통합이 잦습니다. 같은 문제가 아닙니다. 레코드 수만으로는 부족합니다. 얼마나 빨리 커지나요? 얼마나 자주 바뀌나요? 어떻게 쿼리되고, 공유되고, 연결되나요? 얼마나 오래 활성 상태여야 하나요? 한 번에 얼마나 들어오거나 바뀌나요? 삭제하면 어떻게 되나요? “Salesforce는 레코드 2,000만 개를 감당할 수 있다”는 답이 아닙니다. 흥미로운 질문은 이것입니다. 무엇을 하는 레코드 2,000만 개인가요?
AI는 0을 더 붙일 것입니다
섹션 제목: “AI는 0을 더 붙일 것입니다 ”Agents can create data very quickly: interactions, tasks, summaries, recommendations, logs, intermediate results, events, audit information. Maybe that’s useful. But AI doesn’t make storage free, or sharing calculations, or indexing, and it certainly doesn’t make useless history valuable. If an agent creates ten records where a human process used to create one, our volume assumptions may be wrong before the business itself grows. I’m not yet seeing agents generate more records in the orgs I work with, but it’s the natural progression of more and more data being tracked. ⟲
시험 너머: AI가 바꾸는 것. AI는 시스템이 데이터를 만들고 조회하는 속도를 극적으로 높일 수 있습니다. 사람의 과거 트랜잭션 속도가 미래 볼륨을 예측해 줄 거라고 가정하지 말고, 에이전트가 만드는 볼륨을 명시적으로 모델링하십시오.
Steve Trucking: 아키텍처는 이미 바뀌고 있습니다
섹션 제목: “Steve Trucking: 아키텍처는 이미 바뀌고 있습니다 ”At the end of Part 1 we made several decisions that are now reinforcing each other. The work order is central. The current status lives in the org, and the history of every status change is published to the warehouse, Snowflake. Photos live outside the core. Raw GPS stays with FleetLink. At five years of 30% growth, we’re approaching 9 million work orders, 14.5 million line items and 72.3 million status events, and hundreds of millions of GPS readings if we’d copied them all. ⟲
Was keeping raw GPS out of the operational model just an integration decision? No; it was a scale decision too. Was putting photos off-core just a storage decision? No; scale again. And the status history? It has real business value, so we keep it. But at 72.3 million events, keeping it outside the operational database is the difference between an org that carries its history and an org that’s buried by it. The question that remains for what we do keep in core: how long should those records stay active? That’s module 4. ⟲
Follow the model, and the zeros multiply. ⟲
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”- 오늘의 볼륨이 되는지만이 아니라, 예상 성장과 보존 기간 전체를 반영한 오늘의 0의 개수가 어떤 모습인지.
- 어떤 깔끔한 구조를 정규화된 채로 두고, 어디서 볼륨이 통제된 비정규화를 정당화하는지.
- 어떤 데이터가 Salesforce 운영 코어에 남고, 어떤 데이터가 전문 저장소, 분석 플랫폼, 다른 시스템에 속하는지.
- 보고서 요구사항이 정말 운영용인지, 아니면 비즈니스에 분석 아키텍처가 필요하다는 신호인지.
- 에이전트 같은 새로운 생산자가, 그들의 레코드가 내일의 문제가 되기 전에 볼륨 가정을 어떻게 바꾸는지.
Large data volume architecture isn’t about being afraid of big numbers. Salesforce runs very large implementations. One million records isn’t automatically a problem; neither is ten million or a hundred million. But every zero should make me ask another question: how will we find them, who owns them, how are they shared, what are they related to, how often do they change, how long do we need them, and where should they live? In Part 1 we learned to recognize the right entities and relationships. Now we make sure those bones can carry the weight, because what works today may fail tomorrow. ⟲
더 알아보기
섹션 제목: “더 알아보기 ”- Salesforce Help, Data and File Storage Allocations (새 탭에서 열림): 10 GB of data storage since late March 2019, checked 2026-11-01. ⟲
- Salesforce, Best Practices for Deployments with Large Data Volumes, Winter ‘27 edition (새 탭에서 열림) (release 264, archived copy (새 탭에서 열림)), checked 2026-10-20. ⟲
- Salesforce Developers, Best Practices for Deployments with Large Data Volumes (새 탭에서 열림), Winter ‘27, checked 2026-11-01. ⟲
- Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (새 탭에서 열림), checked 2026-11-01. ⟲
- Salesforce, Best Practices for Deployments with Large Data Volumes, Winter ‘16 edition (새 탭에서 열림) (archived copy (새 탭에서 열림)) (release 198), checked 2026-10-20. ⟲
- Salesforce, Developer Limits and Allocations Quick Reference, Winter ‘16 edition (새 탭에서 열림) (archived copy (새 탭에서 열림)) and Winter ‘27 edition (새 탭에서 열림) (archived copy (새 탭에서 열림)), checked 2026-10-20. ⟲
- Salesforce Developers, SOAP API End-of-Life Policy (새 탭에서 열림), checked 2026-11-01. ⟲
- Salesforce Developers, Execution Governors and Limits (새 탭에서 열림), Apex Developer Guide, Winter ‘27, checked 2026-11-01. ⟲
- Salesforce Developers, Working with Very Large SOQL Queries (새 탭에서 열림), Apex Developer Guide, Winter ‘27, checked 2026-11-01. ⟲
- SteveTechArc, Salesforce Documents by Release: the guides cited here, once a year from Winter ‘16 to today, each with an archived copy. ⟲
- Steve Trucking 브리프, 4절(볼륨).