도구를 알라: 아홉 가지 질문
28개 언어로도 제공
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Data Architect 과정의 첫 번째 장인 데이터 아키텍트처럼 생각하기의 모듈 6/7. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 오늘을 위해 만들라. 내일을 계획하라. 실패를 계획하라. · 다음: AI 시대의 데이터 아키텍트
이 모듈이 답하는 질문: 처음 보는 도구까지 포함해, 어떤 도구든 어떻게 평가할까요?
아키텍트에게는 판단력이 필요합니다. 하지만 지식 없는 판단력은 그다지 쓸모가 없습니다. 도구는 여전히 알아야 합니다.
저는 오랫동안 아키텍트를 가르쳐 왔고, 제가 쓰는 틀 중 하나는 아키텍처의 모든 중요한 도구나 기능에 대해 답할 수 있어야 하는 질문들입니다. 원래는 여덟 가지 질문을 가르쳤습니다. 거기에 아홉 번째를 더했습니다. 기술은 바뀌고, Salesforce도 바뀌고, 새 제품이 나오고 옛 기능은 진화하며, AI가 그 모든 것을 가속하고 있습니다. 이 질문들은 계속 통합니다.
아홉 가지 질문
섹션 제목: “아홉 가지 질문 ”기술을 배우거나 평가할 때마다 물으십시오.
- 그것은 무엇인가?
- 어디에 쓰이는가?
- 어떻게 쓰는가?
- 대안은 무엇인가?
- 강점은 무엇인가?
- 약점은 무엇인가?
- 개발자, 비즈니스, 경영진에게 어떻게 설명하는가?
- 장기적으로 어떻게 유지보수하는가?
- 비용은 얼마이고, 어떤 라이선스가 필요하며, 한계는 무엇인가?
아홉 가지 모두에 답할 수 있다면 아키텍트처럼 그 도구를 이해하기 시작한 것입니다. 목록에 없는 것에 주목하십시오. “구성할 수 있는가?” 그것도 중요하지만, 도구를 아는 것의 일부일 뿐입니다.
1. 그것은 무엇인가?
섹션 제목: “1. 그것은 무엇인가? ”뻔한 질문부터 시작하십시오. 놀랄 만큼 자주 건너뛰니까요. 우리는 제품이나 기능 이름을 듣자마자 쓸지 말지를 논의하기 시작합니다. 속도를 늦추십시오. 실제로 무엇을 합니까? 어떤 문제를 풀려고 설계되었습니까? 아키텍처에서 어디에 위치하며, 무엇이 아닙니까? 아키텍트는 마케팅 문구를 되풀이하지 않고 기술을 설명할 수 있어야 합니다. 몇 문장으로 설명하지 못한다면 아마 아직 충분히 이해하지 못한 것입니다.
2. 어디에 쓰이는가?
섹션 제목: “2. 어디에 쓰이는가? ”무언가가 무엇을 하는지 아는 것은 그것이 언제 아키텍처에 들어가야 하는지 아는 것과 같지 않습니다. 어떤 종류의 문제에 강합니까? 어떤 조건에서 적합하고, 어떤 조건에서 의심해야 합니까? “이 기능을 안다”에서 “이 기능이 푸는 문제를 알아본다”로 가는 단계이고, 큰 단계입니다. 좋아하는 기술을 쓸 곳을 찾아다니고 싶지는 않을 겁니다. 문제를 알아보고 어떤 도구가 맞는지 알고 싶을 겁니다.
3. 어떻게 쓰는가?
섹션 제목: “3. 어떻게 쓰는가? ”네, 아키텍트는 구현을 이해해야 합니다. 모든 구성 요소를 직접 만들 필요는 없지만, 다른 사람들에게 무엇을 만들라고 요청하는지 알 만큼은 이해해야 합니다. 어떻게 구성하는지, 개발자는 어떻게 다루는지, 데이터는 어떻게 들어가고 나오는지, 어떻게 배포하고 보호하는지, 운영 중에는 어떤 모습인지 아십시오. 저는 아키텍트가 제품 슬라이드에서만 본 기술을 중심으로 설계하기를 원하지 않습니다. 직접 손을 대 보십시오. 무언가를 만들고, 무언가를 망가뜨리고, 실제로 어떻게 동작하는지 보십시오. 아키텍처는 현실에 발을 디딜 때 더 좋아집니다.
4. 대안은 무엇인가?
섹션 제목: “4. 대안은 무엇인가? ”목록에서 가장 중요한 질문일지도 모릅니다. 문제를 푸는 방법을 하나만 안다면, 그것은 아키텍처 결정이 아니라 기본값입니다. 누군가 기술을 제안할 때마다 저는 달리 무엇을 할 수 있는지 알고 싶습니다. 다른 Salesforce 기능? 선언적인 것, 아니면 코드? 그 기능이 Salesforce 밖에 있을 수 있는가? 데이터를 복사하지 않고 제자리에 둘 수 있는가, API 호출 대신 이벤트를 쓸 수 있는가, 아예 아무것도 만들지 않을 수 있는가? 대안이 트레이드오프를 만들고, 트레이드오프가 아키텍처의 핵심입니다.
5. 강점은 무엇인가?
섹션 제목: “5. 강점은 무엇인가? ”모든 도구는 이유가 있어서 존재합니다. 그것이 정말 잘하는 것을 이해하십시오. 무엇을 쉽게 만드는지, 어디서 잘 확장되는지, 어떤 복잡성을 없애는지, 어떤 문제를 우아하게 푸는지. 강점이 문제와 맞아떨어지는 곳에 기술을 쓰십시오. 당연하게 들리지만, 이미 갖고 있어서, 팀이 알아서, 새로워서, 누군가 데모를 봐서 도구를 고르기가 아주 쉽습니다. 그것도 요인일 수 있습니다. 하지만 아키텍처적 적합성과 같은 것은 아닙니다.
6. 약점은 무엇인가?
섹션 제목: “6. 약점은 무엇인가? ”이것도 똑같이 중요합니다. 모든 기술에는 약점이 있습니다. 하나도 빠짐없이. 누군가 기술의 강점만 말할 수 있다면 아직 아키텍처 논의를 하고 있는 게 아닙니다. 무엇을 잘 못합니까? 복잡성은 어디서 나타나고, 규모가 커지면 어떻게 됩니까? 어떤 운영 부담과 의존성을 가져옵니까? 어떤 요구사항이 그것을 최적 영역 밖으로 밀어냅니까? 약점이 있다고 늘 그 기술을 쓰지 말아야 한다는 뜻은 아닙니다. 무엇을 받아들이는지 알아야 한다는 뜻입니다. 이해한 트레이드오프는 아키텍처적 결정이 될 수 있습니다. 이해하지 못한 트레이드오프는 뜻밖의 사고가 될 수 있습니다.
7. 여러 청중에게 어떻게 설명하는가?
섹션 제목: “7. 여러 청중에게 어떻게 설명하는가? ”기술 지식과 아키텍처 역량을 가르는 질문 중 하나입니다. 같은 기술을 개발자에게, 비즈니스에, 경영진에게 설명할 수 있습니까? 같은 설명이어서는 안 됩니다. 개발자에게는 API, 트랜잭션 동작, 보안, 실패 처리, 구현 패턴이 필요합니다. 비즈니스는 그것이 무엇을 가능하게 하고 자기 프로세스가 어떻게 바뀌는지에 관심이 있습니다. 경영진은 비용, 위험, 시간, 조직에 미치는 영향, 그리고 그 결정이 어떤 선택지를 열어 두거나 닫는지에 관심이 있습니다. 사실을 바꾸는 것이 아닙니다. 추상화 수준을 바꾸는 것입니다. 기술을 설명하는 유일한 방법이 그 문서의 어휘뿐이라면, 이해를 더 다듬으십시오.
8. 장기적으로 어떻게 유지보수하는가?
섹션 제목: “8. 장기적으로 어떻게 유지보수하는가? ”프로젝트는 끝납니다. 시스템은 끝나지 않습니다. 적어도 그러기를 바랍니다. 프로젝트 팀이 떠난 뒤에도 누군가는 우리가 만든 것을 맡아야 합니다. 그것은 어떻게 모니터링하고, 업그레이드하고, 문제를 해결하는지, 누가 그것을 지원할 기술을 갖춰야 하는지, 변경은 어떻게 배포하고 테스트하는지, 기술이 진화하거나 Salesforce가 발밑에서 무언가를 바꾸면 어떻게 되는지 안다는 뜻입니다. 3년 뒤를 그려 보십시오. 저는 출시일에는 아주 영리했지만 그 뒤로 운영하기 괴로운 아키텍처를 봐 왔습니다. 그것은 성공이 아닙니다. 유지보수성은 아키텍처의 일부입니다.
9. 비용은 얼마이고, 어떤 라이선스가 필요하며, 한계는 무엇인가?
섹션 제목: “9. 비용은 얼마이고, 어떤 라이선스가 필요하며, 한계는 무엇인가? ”원래의 여덟 가지에 제가 더한 질문이고, 오늘날에는 빼놓을 수 없다고 생각합니다. 기술이 완벽한 기술적 해법이어도 경제성이 맞지 않으면 아키텍처적으로는 틀린 해법일 수 있습니다. 가진 라이선스에 포함되어 있습니까, 아니면 추가 기능입니까? 사용자, 사용량, 소비량, 스토리지, 트랜잭션 중 무엇 기준으로 라이선스가 매겨집니까? 규모가 커지면 비용은 어떻게 됩니까?
그리고 한계가 있습니다. 모든 플랫폼에 있습니다. API, 스토리지, 쿼리, 트랜잭션, 동시성, 처리량, 라이선스 한계. 어떤 것은 엄격하고 어떤 것은 유연합니다. 어떤 것은 올릴 수 있고 어떤 것은 못 올립니다. 어떤 것은 0이 하나 더 붙기 전까지는 우리 규모에서 문제가 되지 않습니다. Salesforce의 모든 한계를 외울 필요는 없고, 그건 시간을 아주 나쁘게 쓰는 일입니다. 알아야 할 것은 한계가 존재한다는 것, 어떤 한계가 당신의 아키텍처에 중요한지, 그리고 언제 현재 숫자를 확인하러 가야 하는지입니다. 숫자는 바뀝니다. 아키텍처의 질문은 남습니다.
풀이 예시: Apex 공유
섹션 제목: “풀이 예시: Apex 공유 ”질문들이 실제로 작동하는 제 단골 예시입니다. 복잡한 공유 요구사항을 받습니다. 소유자 기반이나 조건 기반 공유 규칙 어느 것으로도 충족할 수 없는 공유입니다. 그래서 Apex 공유(Apex sharing), 즉 공유 레코드를 직접 쓰는 코드로 가게 됩니다. 이제 Apex 공유가 무엇이고, 어디에 쓰이고, 어떻게 쓰는지 등을 알아야 합니다. 이것은 한 단계 올라가는 선택입니다. Apex 공유는 필요한 규칙이 소유자 기반과 조건 기반 공유로 표현할 수 있는 범위를 넘어설 때의 대안(질문 4)입니다.
이제 약점(질문 6)입니다. 회원이 1,000만이나 2,000만 명인 고객 커뮤니티가 있고, Customer Community Plus가 아니라 Customer Community 라이선스를 쓴다고 합시다. 이들은 대량 사용자입니다. 역할이 없고, 공유 모델을 전혀 쓰지 않습니다. 이들의 접근은 계정과 연락처를 통해 매칭되는 공유 세트와 공유 그룹에서 옵니다. Apex가 그들을 위해 쓸 공유 레코드가 없으니, 그들에게는 Apex 공유가 통하지 않습니다. 그리고 우리를 그 상황에 데려다 놓은 것은 비용과 라이선스 질문(질문 9)입니다. 라이선스 선택이 어떤 공유 도구가 존재하는지 자체를 결정했습니다.
그러니 Apex 공유가 소유자 기반·조건 기반 규칙의 대안이었던 것처럼, Apex 공유의 대안이 필요한 경우를 만날 수도 있습니다. 그 지점에서는 복잡한 공유 규칙을 위한 구성 기반 선택지가 사실상 없습니다. 결국 개체를 읽기 전용으로 만들고 Apex로 접근을 통제하게 됩니다. 그래서 아홉 가지 질문은 고른 뒤가 아니라 고르기 전에 던지는 것입니다.
플랫폼을 외우지 마라
섹션 제목: “플랫폼을 외우지 마라 ”Salesforce 아키텍처를 배울 때 이것이 가장 중요합니다. Salesforce를 외우려 하지 마십시오. 불가능합니다. 플랫폼은 너무 크고 너무 빨리 바뀝니다. 저는 오랫동안 Salesforce로 일해 왔는데도 여전히 배우고 있습니다. 정상입니다.
제가 여러분이 기르기를 바라는 것은 배우는 틀입니다. 내일 Salesforce가 새 기능을 출시해도 제가 미리 봤을 필요는 없습니다. 무엇을 물어야 하는지 압니다. 그것은 무엇인가, 어디에 맞는가, 어떻게 쓰는가, 달리 무엇을 쓸 수 있는가, 무엇을 잘하는가, 어디서 힘들어하는가, 어떻게 설명하는가, 어떻게 운영하는가, 비용은 얼마이고 한계는 어디인가? 이제 평가를 시작할 수 있습니다. 기능 비교표를 하나 더 외우는 것보다 훨씬 가치 있습니다.
시험 너머: AI는 아홉 가지 질문에 더 빨리 답하게 해 주고, 더 쉽게 틀리게도 한다. 모르는 기술을 만나면 AI에게 설명해 달라고, 세 가지 접근을 비교해 달라고, 한계와 흔한 실패 유형을 나열해 달라고, 쓰지 말아야 할 이유를 대 달라고 할 수 있습니다. 놀라운 연구 조수입니다. 하지만 틀릴 수도, 오래된 정보일 수도, 이름이 비슷한 두 제품이나 에디션을 자신 있게 뒤섞을 수도 있습니다. 결정에 영향을 주는 것은 무엇이든 검증하십시오. 출처를 따라가고 현재 문서, 한계, 라이선스를 확인하십시오. 신뢰하되 검증하라(모듈 7).
답만이 아니라 질문을 배워라
섹션 제목: “답만이 아니라 질문을 배워라 ”이 과정에서 많은 기술을 만날 것입니다. 저는 여러분이 답을 수집하기보다 질문을 연습하기를 바랍니다. 빅 개체, 외부 데이터, Data 360, 연동 패턴, 혹은 이 장을 쓰고 6개월 뒤에 Salesforce가 출시할 AI 기능을 다룰 때도 같은 아홉 가지 질문을 던지십시오.
답은 바뀝니다. 질문은 오래갑니다. 그것이 이것을 학습 가이드가 아니라 아키텍처 틀로 만듭니다.
도구를 아십시오. 무엇을 잘하고, 무엇을 못하고, 달리 무엇을 쓸 수 있고, 비용이 얼마이고, 어디서 부러지는지. 그리고 그 결정과 함께 살아야 할 사람들에게 설명할 만큼 아십시오. 그것이 아키텍트가 기술을 배우는 방식입니다.
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”- 구성할 수 있는지만이 아니라 아홉 가지 질문 전부로 판단해, 도구가 문제에 맞는지.
- 대안은 무엇이며, 그 도구의 비용, 라이선스, 한계가 당신의 규모에서 무엇을 의미하는지.
- 3년 뒤에 누가 어떻게 그것을 유지보수할지.
- 그 도구에 대한 어떤 사실을 의존하기 전에 검증할지.
더 알아보기
섹션 제목: “더 알아보기 ”- About High-Volume Community or Site Users (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-10-09, 재확인일 2026-10-12): 대량 사용자(External Apps, Customer Community, High Volume Customer Portal, Authenticated Website 라이선스)에게는 역할이 없고, 접근은 공유 세트와 공유 그룹에서 오며, 소유자 기반 공유 규칙에 포함될 수 없고, 이들이 소유한 레코드는 수동으로 공유할 수 없다.
- Platform Sharing Architecture (opens in a new tab), Salesforce Architects(영어, 확인일 2026-10-09, 재확인일 2026-10-12): 대량 사용자(Customer Community, High Volume Customer Portal, Authenticated Website)는 라이선스가 역할을 지원하지 않으므로 공유 모델을 쓰지 않으며, 접근은 공유 세트나 공유 그룹을 통해 사용자를 계정 및 연락처 조회 필드에 매칭하는 방식으로 작동한다. 같은 페이지에 Apex 관리 공유가 적합한 경우도 나와 있다.
- Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), Trailblazer Community 질문, 2024년 11월(영어, 확인일 2026-10-09, 재확인일 2026-10-12): 한 실무자가 대량 사용자를 위한 공유 레코드 삽입이 오류로 실패했다고 보고한다. 공식 문서가 아니라 현장 보고다. (온라인 Trailblazer Community는 2026년 10월 30일에 읽기 전용이 되며, 링크가 바뀔 수 있다.)
- Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-10-09): 공유 세트는 사용자의 계정이나 연락처와 관련된 레코드에 대한 접근을 부여한다.