자원 및 비용 최적화

자원 최적화 및 비용 최적화는 회사에서 함께 작동하여 비용당 최대 가치를 달성합니다. Salesforce는 멀티테넌트 인프라를 관리하고 모든 테넌트에 대해 플랫폼을 공정하게 유지하는 총괄자 제한을 적용하며 라이센스 및 소비량 크레딧을 통해 액세스 가격을 책정합니다. 최적화하는 값은 비즈니스 결과의 각 달러별 지출 및 각 플랫폼 수용력 단위의 반환과 같은 값입니다. 자원 최적화는 이미 지불한 항목을 효율적으로 사용하는 메커니즘입니다. 비용 최적화는 결과이며, 의도적으로 비용을 경쟁 우위의 원인으로 이동시킵니다. 이 기둥은 동일한 목표의 두 가지 보기이므로 하나의 결정으로 취급됩니다.

이 비용별 가치 보기는 모든 아키텍처 결정을 결정합니다. 총 소유 비용을 이해하면 능력과 투자 간에 더 나은 제약을 만들 수 있습니다. 비즈니스 요구 사항에 맞게 적절한 규모의 솔루션을 구축하고 가치 제공을 가속화하는 기능에 미사용되거나 투자하지 않는 기능을 과도하게 프로비저닝합니다. 라이센스, 소비 배출권, API 호출, Sandbox 환경은 모두 동일한 방정식에 대한 입력입니다. 중요한 것은 각각 반환되는 값이지만 어떤 원장에 속하는 것이 아닙니다. 질문은 “이것이 비용인지 자원인지”는 아니며 “이 입력에 적절한 보상이 있는지”입니다.

이 기둥을 무시하면 예측 가능한 결과가 발생합니다. 회사는 예산을 소비하는 미사용 라이센스를 누적하지만 기타 기능은 자금이 부족한 상태로 남아 있습니다. 비효율적인 아키텍처는 설계 개선으로 인해 방지되는 문제에 대한 API 용량, 저장소, 개발 노력을 낭비합니다. 예측 가능한 방식으로 특정 복합물의 리소스 비효율성:

• 데이터 용량이 증가함에 따라 성능이 저하됩니다.
• 선택적이지 않은 쿼리가 전체 테이블을 스캔하면 쿼리 시간 초과가 수백만 개의 레코드에서 나타납니다.
• 솔루션이 불필요한 필드를 검색하면 힙 제한 예외가 나타납니다.
• 복잡한 계산이 동기식으로 실행되면 CPU 시간 초과가 표시됩니다.
• 팀이 각각의 새 제한에 대해 패치하면 해결 방법이 곱해집니다.

이러한 실패는 각각 신뢰성 문제와 비용 문제입니다. 낭비된 계산으로 인해 사용자가 지불하는 용량이 소비됩니다. 가장 중요한 점은 예산 및 엔지니어링 수용력이 전략적 이니셔티브가 아닌 폐기물로 소비되므로 팀이 혁신에 투자할 기회를 놓치지 않습니다.

비용 효율적인 솔루션은 다음을 수행하여 가치를 극대화합니다.

• 이미 구매한 플랫폼 기능 사용
• 실제 사용에 맞게 적절한 크기 라이센스 및 소비 조정
• 접근 방식을 적용하기 전에 전체 비용 모델링
• 비즈니스 결과 대비 지속적인 지출 모니터링

다음 관행이 복합됩니다. 설계에 비용 인식 및 자원 효율성을 구축하는 팀은 지출이 이미 증가한 후 최적화를 정리 연습으로 취급하는 팀보다 달러당 더 많은 기능을 제공합니다.

자원 및 비용 최적화는 다른 아키텍처 기둥에 직접 연결됩니다. Operational Excellence는 수작업 작업을 줄이는 자동화로 지속적인 비용을 절감합니다. 신뢰성과 Trust은 비즈니스 연속성 보증 및 규정 준수 가치를 통해 프리미엄 투자를 정당화합니다. 이러한 기초를 함께 사용하면 아키텍처가 최대 수익을 제공하므로 기업이 자신 있게 투자할 수 있습니다.

다음 원칙을 사용하여 플랫폼에서 자원 및 비용 최적화를 위한 아키텍처 결정을 안내합니다.

• 총 소유 비용을 최적화합니다. TCO(총 소유 비용)는 구독 수수료 이상으로 소비 배출권, 구현 비용, 운영 비용, 통합 비용, 변경 관리 노력으로 확장됩니다. TCO 분석을 사용하여 솔루션 수명에 걸친 전체적인 투자 상황을 파악할 수 있는 결정을 평가합니다. 경우에 따라 사전 투자가 높으면 진행 중인 운영 비용이 크게 줄어들고 TCO 분석 영역이 제한됩니다. 단기 비용 최소화가 아닌 장기 가치를 최적화합니다.

• 비즈니스 가치에 따른 지출 조정. 모든 Salesforce 투자를 측정 가능한 비즈니스 결과에 연결합니다. 라이센스 지출은 채택 및 과업 완료를 통해 측정되는 사용자 생산성을 지원합니다. Data 360 투자는 변환 및 고객 생애 가치를 통해 측정된 의사 결정을 강화합니다. Sandbox 비용은 배포 빈도 및 품질을 기준으로 측정된 기금 개발 속도입니다. 지출이 가치에 부합하면 성공을 촉진하는 요소에 자신 있게 투자하고 더 이상 수익을 얻지 못하는 지출을 식별합니다.

• 플랫폼 한도 내 설계. 총괄자 제한은 트랜잭션당 솔루션이 처리할 수 있는 내용을 정의합니다. 작업을 수행하는 장애물이 아닌 처음부터 설계 제약으로 취급하십시오. 최대 부하 및 최대 데이터 볼륨에서 제한 내에서 편안하게 작업하는 트랜잭션을 설계하고 향후 기능, 기타 설치된 패키지, 예기치 않은 데이터 패턴에 대한 여백을 구축합니다. 개념에서 제한 범위 내에 설계된 솔루션은 성능을 예측할 수 있으며 나중에 긴급 리팩터링을 방지합니다.

• 이미 지불한 자원을 최적화하십시오. 추가 용량을 구매하기 전에 이미 프로비저닝된 플랫폼 자산의 처리량, 효율성, 가치를 극대화하십시오. 효율적인 쿼리, 대량 처리(불량 처리), 캐싱, 규제된 데이터 수명 주기를 통해 솔루션에 필요한 계산, 저장소, API 사용량을 줄일 수 있습니다. 이 리소스 효율성은 지속 가능한 비용 최적화를 촉진하는 메커니즘입니다. 프로비저닝된 리소스에서 폐기물이 제거되면 성과와 장기 TCO가 모두 향상됩니다.

• 실제 사용에 맞는 크기의 라이센스 및 소비. 각 사용자를 작업에 필요한 라이센스 유형에 맞추고 계량된 서비스를 효율적으로 호출하도록 자동화 및 에이전트를 설계합니다. 라이센스 초과 및 모니터링되지 않은 소비 배출권은 가장 일반적이고 비용이 많이 드는 폐기물원입니다. 역할, 로그인 활동, 기능 사용에 대한 정기적인 감사를 통해 기회 크기가 올바르게 조정되고 대변 사용에 대한 명확한 가시성이 유지되어 소비 기반 비용을 예측할 수 있습니다.

• 재무 관리와 비용 인식 문화 구축. 활성 감독 및 공유 책임을 통해 Salesforce 지출을 전략적 투자로 관리합니다. 재무 관리는 배포 후 비용을 발견하는 대신 설계 결정을 위해 비용과 이점을 분석합니다. 비용 인식은 비즈니스 이해당사자, 설계자, 개발자가 기능 요구 사항과 함께 비용 영향을 고려하는 공유 책임이므로 중앙 집중화된 병목 지점 없이 모든 수준에서 현명한 투자 결정을 내릴 수 있습니다.

• 연속적인 최적화 실습. 최적화는 일회성 실습이 아닌 지속적인 작업입니다. 기술 및 비즈니스 이해당사자가 액세스할 수 있는 대시보드를 통해 지출 및 자원 소비를 모니터링합니다. 런어웨이 소비가 눈에 띄지 않기 전에 소비 지출이 임계값에 도달할 때 실행되는 경고를 구성합니다. 정기적인 검토는 점진적으로 누적되는 폐기물을 발견하고, 이전 최적화 투자에서 예상되는 수익을 달성했는지 확인하고, 비즈니스 우선 순위와 데이터 용량이 발전함에 따라 새로운 기회를 표시합니다.

Salesforce가 운영하는 항목을 이해하면 사용자가 제어하는 항목에 최적화 노력을 집중할 수 있습니다. 플랫폼은 기존의 IT 환경에서 전담 팀이 필요한 인프라 수준 자원 관리를 처리합니다.

• Multitenant 리소스 할당: Salesforce는 공유 인프라의 모든 고객에서 공정한 CPU, 메모리, 데이터베이스 연결 공유를 보장하고, 테넌트 소비를 모니터링하고, 단일 테넌트가 다른 테넌트의 성능을 저하하지 못하도록 방지하는 제한을 적용합니다.
• 구버너 제한 아키텍처: 플랫폼이 적용하는 경계(동기 트랜잭션당 SOQL 쿼리 100개, CPU 시간 10초, 힙 크기 6MB)는 모든 테넌트를 자원 소모로부터 보호합니다. Salesforce는 다음 제한을 멀티테넌트 인프라 용량에 맞춥니다. 이러한 제한은 임의 제한이 아닌 아키텍처 경계입니다.
• 쿼리 최적화 프로그램 및 실행 엔진: Salesforce 쿼리 최적화 프로그램은 실행 계획을 생성하고 데이터 배포에 대한 통계를 유지하며 최적의 쿼리 경로를 선택합니다. 표준 필드의 플랫폼 관리 색인은 일반 쿼리 패턴을 가속화하며, 최적화 프로그램은 데이터 용량 변경에 자동으로 적응합니다.
• 인프라 확장: Salesforce는 사용량 증가에 따라 하드웨어 용량을 프로비저닝하고, 데이터베이스 클러스터를 관리하고, 로드를 배포하고, 인프라를 확장합니다. 서버를 프로비저닝하거나, 데이터베이스 복제를 관리하거나, 로드 밸런서를 구성하지 마십시오.
• 플랫폼 성능 최적화: Salesforce는 핵심 플랫폼 코드, 쿼리 실행, API 응답 시간, UI 프레임워크 성능을 지속적으로 최적화하며, 고객 조치 없이 정기 릴리스를 통해 인프라를 개선합니다.

Salesforce는 플랫폼의 상업적 측면도 관리하므로 라이센스 및 소비는 계산 및 저장소와 동일한 기둥에 속합니다. 플랫폼은 수용력을 구매하는 Edition, 라이센스 유형, 추가 기능, 소비배출권 모델을 정의하고 해당 배출권을 획득하는 사용량을 계량합니다. 서버를 프로비저닝하는 것보다 해당 가격을 설정하지 않아도 각 사용자가 보유한 라이센스, 자동화에서 계량된 서비스를 얼마나 효율적으로 호출하는지, 활성 상태를 유지하는 Sandbox 수를 결정합니다.

다음 플랫폼 작업을 기반으로 구축합니다. Salesforce는 인프라와 가격 책정 모델을 모두 관리하므로 최적화 노력이 전적으로 해당 자원을 얼마나 효율적으로 사용하고 얼마나 의도적으로 자원을 할당하는 지출을 지향하는지와 같은 아키텍처적 결정을 내릴 수 있습니다.

공유 책임 모델은 Salesforce 내에서 생성하는 모든 항목에 대한 자원 효율성을 소유함을 의미합니다. 플랫폼 자원 관리는 작업을 지원하지만 최적화 필요를 대체하지는 않습니다. 효율적인 솔루션은 이미 지불한 계산, 저장소, API 용량으로부터 더 많은 비즈니스 가치를 반환하며, 이는 일회성 예산 절감이 아닌 비용 최적화를 지속적으로 유지하는 메커니즘입니다. 반대로, 낭비적인 계산은 비즈니스 가치와 비용 복합을 제공하지 않고 인프라 리소스를 소비합니다. 데이터 용량이 증가함에 따라 성능이 예측 가능한 방식으로 저하되고 팀이 제한 내에서 설계할 수 있는 제한에 대해 패치할 때 해결 방법이 증가합니다.

최적화 책임은 성능, 코드 구성, 패키징, 데이터와 같은 4가지 상호 연결된 영역에 걸쳐 있습니다. 각각은 기술적 결정보다 먼저 비용별 가치 결정입니다. 이 섹션에서는 해당 결정을 내리는 방법과 중요한 이유를 설명합니다. 이 섹션에서 참조되는 정확한 구현 레시피, 코드 수준 템플릿, 설정 탐색, 특정 조정 임계값은 자원 및 비용 최적화 패턴 라이브러리에 있습니다.

성능 최적화는 총괄자 제한을 고려하는 방식의 교대 근무로 시작됩니다. 작업을 방해하는 장애물이 아닙니다. 이는 초기 설계에서 받아들이면 예측 가능한 성능 특성이 있는 솔루션을 생성하는 아키텍처 제약입니다. 모든 트랜잭션은 고정된 경계 내에서 실행되며, 플랫폼의 모든 테넌트에 공정한 자원 공유를 적용하기 위해 이러한 경계가 있습니다. 허용된 SOQL 쿼리 100개 중 95개를 사용하는 Apex 트랜잭션은 향후 기능, 다른 팀이 추가한 트리거 또는 예기치 않은 데이터 패턴에 대한 여유 공간을 남기지 않습니다. 제한이 절반 미만인 트랜잭션을 유지하는 아키텍처는 제한이 소진될 때 긴급 재연산 없이 성장할 수 있는 솔루션을 구축합니다. 규칙은 최대 부하에서 최대 데이터 볼륨으로 제한 내에 적절하게 설계하는 것입니다. 그러면 기능 또는 다른 패키지의 자동화를 추가하면 트랜잭션이 가장자리를 넘지 않습니다. 비용이 많이 드는 일반적인 실패: 솔루션은 Developer Sandbox 10개 레코드에서 완벽하게 작동하지만 프로덕션에서 총괄자 제한에 도달합니다. Developer Sandbox는 구성만 복사하며 데이터를 포함하지 않습니다. 전체 사본 Sandbox에서 실제 볼륨을 테스트하면 고객이 먼저 확장성 문제를 발견할 수 있습니다.

쿼리 선택성은 솔루션이 수백만 개의 레코드로 확장되는지 아니면 수백만 개의 시간으로 확장되는지에 대한 단일 최대 레버입니다. 선택적 쿼리는 색인을 사용하여 효율적으로 레코드를 찾고, 비선택적 쿼리는 전체 테이블을 스캔하고 과도한 데이터베이스 자원을 소비하며, 결국에는 시간이 초과됩니다. 플랫폼은 정의된 필드 집합에 대한 표준 색인을 유지하며 개체가 첫 백만 개의 레코드를 초과할 때 좁아지는 선택성 임계값을 적용합니다. 선택성을 위한 아키텍처는 대량 개체에 대한 테이블 스캔을 표시하는 쿼리는 발생을 대기하는 프로덕션 사고이기 때문에 대량 개체에 대해 배포하기 전에 기본 기준으로 색인화된 필드를 필터링하고 쿼리 계획 도구를 사용하여 확인하는 것을 의미합니다. 선택성은 구매할 필요가 없는 용량입니다. 효율적인 쿼리는 밀리초 이내에 반환되며 자체 조직의 모든 다른 테넌트 및 모든 다른 트랜잭션에 사용할 수 있는 데이터베이스 자원을 유지합니다.

대량 처리는 규모에 맞춰 작동하는 Apex 제한에 도달하는 Apex 구분하는 기본 확장성 패턴입니다. 안티 패턴(루프 내에 배치된 쿼리 또는 DML 문)은 소규모 레코드 집합에서 올바르게 작동하지만 대량 작업이 실행되는 순간에 대한 총괄자 제한을 위반합니다. 해결 방법은 루프 외부의 단일 문에서 모든 필요한 데이터를 쿼리하고, 반복하는 동안 빠른 조회를 위해 ID로 키가 지정된 지도에 결과를 구성하고, 배치된 DML을 사용하여 전체 컬렉션을 처리하는 것입니다. 모든 자동화를 설계하여 제한에 근접하지 않고 표준 200개의 레코드 트리거 배치를 처리하고 프로덕션의 로드에 관계없이 동일한 코드 크기를 조정합니다.

사용자 트랜잭션의 동기 제한 내에서 완료할 수 없거나 완료해서는 안 되는 작업에 대해 비동기 처리가 적용됩니다. 해당 작업을 비동기 컨텍스트로 이동하면 사용 가능한 총괄자 제한이 대략 두 배로 증가하고 장기 실행 작업이 사용자를 차단하지 않도록 방지합니다. 해당 헤드룸은 실제이지만 무료는 아니며 제한이 가까워질 때마다 비동기화에 도달하는 것은 실수입니다. 비동기화는 의도한 아키텍처 제약입니다. 결과적으로 일관성을 도입하므로 요청한 트랜잭션에 작업 결과가 표시되지 않으므로 즉각적인 확인에 의존하지 않는 사용자 환경 결정이 강제 적용됩니다. 오류가 트리거한 사용자가 아닌 작업 로그에 표시되므로 명시적으로 오류를 처리하고 모니터링해야 합니다. 단일 비즈니스 작업이 여러 거래에 걸쳐 있을 경우 시스템의 정신 모델이 복잡해질 수 있습니다. 비용별 가치 결정은 작업이 실제로 필요로 하는 수용력에 대해 추가된 복잡성을 가중시키고 편안하게 적합한 경우 작업을 동기화 상태로 유지하는 것입니다.

비동기식이 올바른 호출인 경우 메커니즘 중 선택은 제한의 크기가 아닌 작업의 형태를 따릅니다. 배치 Apex는 볼륨입니다. 각각 자체 독립 총괄자 제한이 있는 청크로 나누어 수백만 개의 레코드를 처리하므로 데이터 마이그레이션, 데이터 보관, 대량 보강이 여기에 포함됩니다. 대기 가능한 것은 순서입니다. 동기 제한을 초과하지만 배치 규모가 필요하지 않은 다단계 워크플로를 처리하고 순서대로 실행해야 하는 단계에 대해 하나의 작업을 다른 작업으로 연결할 수 있습니다. 플랫폼 이벤트는 분리를 위한 것입니다. 프로듀서가 소비자를 알거나 기다리지 않고 이벤트를 방송합니다. 이 패턴을 사용하여 교차 시스템 알림을 수행하고 동일한 트랜잭션에 속하지 않는 작업을 분리합니다. 최소한 한 번의 배달 시 동일한 구독자가 필요하다는 점을 고려하십시오. 미래 메서드는 기본 입력이 있는 간단한 비동기 작업의 좁은 사례(일반적으로 동기 트리거의 콜아웃)를 다룹니다. 복잡한 개체를 연결하거나 수용하지 못하는 이유는 다목적 비동기 작업을 위한 도구가 아닙니다. 작업 형태에 비동기 메커니즘을 일치시킵니다. 그렇지 않으면 수익을 초과하는 일관성 및 모니터링 비용에 대해 총괄자 제한 문제를 교환합니다.

캐싱은 반복 작업을 유지하는 수용력으로 변환합니다. 플랫폼 캐시는 트랜잭션 경계 전반에 걸쳐 직렬화 가능한 데이터를 저장하므로 캐시를 누르면 값을 생성한 쿼리 또는 재계산이 다시 실행되지 않으므로 SOQL 및 CPU 소비량이 직접 감소합니다. 캐시를 만들거나 해제하는 결정은 캐시에 넣을 항목 및 기간입니다. 사용자 정의 메타데이터, 구성, 선택 목록 값과 같이 훨씬 더 자주 읽는 데이터를 캐시하고 단일 기본값이 아닌 데이터의 변동성과 일치하도록 활성 시간을 설정합니다. 매월 변경되는 참조 데이터는 몇 시간 동안 안전하게 캐시할 수 있지만 하루 동안 이동하는 구성에는 짧은 기간이 필요하므로 캐시가 중요하지 않은 오래된 값을 제공하지 않습니다. 너무 공격적인 캐시는 성능 획득과 정확성 위험을 차단하며, 충돌률이 낮은 캐시는 수용력을 반환하지 않고 저장소를 소비합니다. 따라서 충돌률은 추정할 설정이 아니라 모니터링해야 하는 메트릭입니다. 파티션 선택은 보안 결정입니다. 사용자 간에 공유되는 데이터에 조직 파티션을 사용하고, 사용자 범위 데이터를 격리해야 하는 세션 파티션을 사용하며, 모든 사용자가 읽을 수 있는 조직 파티션에 개인 식별 정보를 배치하지 마십시오. Lightning Data Service는 동일한 아이디어를 클라이언트에도 확장합니다. 페이지의 모든 구성 요소에서 캐시된 레코드를 공유하고 중복된 서버 반복 이동을 방지합니다. 반환되는 값이 올바른 경우 모든 캐시를 누르면 계산 및 API 용량을 사용하지 않아도 됩니다.

데이터 왜곡은 불균형한 레코드 배포로 생성되는 성능 핫스팟입니다. 단일 상위 레코드에 10,000개가 넘는 하위 항목이 누적되면 쿼리 성능이 저하되고 동시 작업 중에 행 잠금 충돌이 발생합니다. 임계값은 하드 제한이 아닌 설계 신호입니다. 이를 통해 여러 상위 항목에서 로드를 배포하고, 상위 항목이 경계에 도달할 때 경고를 보이는 예약된 작업이 있는 대용량 개체를 모니터링하고, 동시 배치가 동일한 행에서 충돌하지 않도록 상위 ID별로 대량 로드를 정렬할 수 있습니다. 통합 사용자가 수천 개의 레코드를 소유하는 소유권 왜곡은 동일한 잠금 충돌을 일으키며 동일한 로드 분포가 필요합니다.

Salesforce는 솔루션이 발전함에 따라 성능 특성을 올바르게 유지하는 도구를 제공합니다. 확장 센터는 장기 실행 작업, 행 잠금 충돌, 제한에 근접한 트랜잭션에 대한 트랜잭션 수준 가시성을 제공한 다음, 관련된 특정 트리거 및 개체의 이름을 지정합니다. ApexGuru는 AI 분석을 프로덕션 런타임 Telemetry에 적용하여 규모에 도달하기 전에 안티 패턴을 표시하며 Salesforce Code Analyzer는 CI/CD 파이프라인에서 정적 분석을 수행하므로 쿼리가 루프 내부에 나타나거나 기타 성능 결함이 감지되면 빌드가 실패합니다. 이벤트 모니터링은 시간 경과에 따른 소비 추세를 표시하며 서명 성공 계획 기능인 Proactive Monitoring 조직의 성능 및 확장성 위험을 지속적으로 평가합니다.

코드 구성은 유지 관리 가능성으로 표시되는 비용 결정입니다. 서비스 점검은 일반적으로 성숙한 솔루션에 대한 대부분의 개발 수용력을 사용하므로 선택한 구조에 따라 향후 수용력이 재작업되지 않고 변경되는 수량이 결정됩니다. 세 가지 패턴은 대부분의 값을 가져옵니다. 트리거 처리기 패턴은 처리기 클래스에서 트리거 논리를 중앙 집중화하고 트리거 파일 자체를 최소 위임 지점으로 줄여 트리거 컨텍스트와 독립적으로 논리를 테스트할 수 있게 유지하고 반복 제어를 단일 홈으로 제공합니다. 서비스 레이어 패턴은 트리거, REST 끝점, 플로 호출 가능 또는 배치 작업에서 호출 가능한 작업을 노출하는 클래스에 비즈니스 논리를 캡슐화하므로 비즈니스 규칙은 모든 입력 지점에서 중복되고 동기화에서 벗어나는 대신 하나의 구현으로 유지됩니다. 선택기 패턴은 전용 클래스의 각 개체에 대한 SOQL을 중앙 집중화하여 쿼리 튜닝을 단일 지점으로 변경하고 모든 쿼리에 명시적이고 명명된 의도를 제공합니다.

혼합 DML 오류는 명시적으로 대처해야 할 고유한 조직 위험입니다. 하나의 트랜잭션이 사용자 및 PermissionSet와 같은 설정 개체와 계정 및 사용자 정의 개체와 같은 비설정 개체 모두에서 DML을 수행하면 설정 변경 사항이 사용자의 액세스에 영향을 미치므로 별도의 트랜잭션에서 커밋해야 합니다. 통합 작업, 테스트 설정, 사용자 프로비저닝 자동화에서 실패가 대규모로 나타납니다. 아키텍처 해결 방법은 비동기 처리 또는 플랫폼 이벤트를 사용하여 트랜잭션 경계 전체에서 설정 및 비설정 DML을 분리하고, 단일 비즈니스 단계에서 두 작업을 결합하지 않는 데이터 모델을 설계하고, 테스트에서 설정 DML을 격리하는 것입니다.

패키징 선택 항목은 회사에서 달성할 수 있는 장기 개발 비용 및 재사용량을 결정합니다. 2세대 관리 패키지는 네임스페이스를 보호하는 소스 중심 모듈식 개발을 제공하며 AgentExchange를 통해 배포되는 독립 소프트웨어 공급업체(ISV) 제품에 적합한 선택입니다. 잠금 해제된 패키지는 내부 팀에게 네임스페이스 오버헤드 없이 동일한 모듈화 및 종속성 관리를 제공하며, 이는 독립적인 배포가 필요하지만 마켓플레이스 목록이 필요하지 않은 엔터프라이즈 응용 프로그램에 적합합니다. 1세대 관리 패키지는 기존 제품에 사용 중이지만 새 모듈식 개발을 유지 관리할 수 있는 소스 중심 워크플로가 없습니다.

모듈성은 구축하는 구성 요소로 확장됩니다. 명확한 속성 인터페이스를 사용하여 단일 책임 주위에 Lightning 웹 구성 요소를 설계하고 복잡한 UI가 작은 초점 구성 요소에서 조립되도록 상속 대신 구성을 선호하며, 상위에 직접 접속하지 않고 상위 커뮤니케이션을 위해 사용자 정의 이벤트를 사용합니다. 관리자가 개발자 구축 기능에서 Flow Builder에서 자동화를 구성할 수 있도록 재사용 가능한 Apex 호출 가능한 작업으로 표시하여 중복을 줄이고 선언적 및 프로그래밍 방식의 세상을 연결합니다. 올바르게 설계된 모듈성은 필요한 모든 장소에서 다시 구현하고 별도로 유지 관리하는 대신 한 번만 구축하고 재사용할 수 있는 기능입니다.

비관리 데이터 증가는 점진적인 성능 저하의 가장 일반적인 원천이며, 스토리지 비용과 Sandbox 새로 고침 시간을 동시에 늘립니다. 두 가지 결정이 데이터 효율을 관리합니다. 첫 번째는 데이터 모델 설계입니다. 마스터-세부 사항 관계는 더 긴밀한 연결 비용으로 계단식 삭제, 롤업 요약, 데이터 공유를 제공합니다. 조회를 통해 사용자 정의 롤업 논리 비용을 절감할 수 있으며 필터링하는 필드에 대해 의도한 색인 전략을 사용하면 개체가 성장함에 따라 쿼리가 선택적으로 유지됩니다. 두 번째는 데이터 수명 주기입니다. 보관 전략이 없으면 수백만 개의 개체가 증가하므로 최종적으로 쿼리 시간 초과, 선택적이지 않은 쿼리, 시간 초과 목록 보기가 생성되므로 개체가 레코드를 무기한으로 누적할 수 있도록 하지 않고 생성부터 보관까지의 전체 수명 주기를 정의합니다.

규정을 준수한 후에만 보관 메커니즘을 선택하십시오. 메커니즘을 선택하기 전에 데이터 보존, 삭제 권리 또는 보존 요구 사항이 옵션을 제한하는지 확인하십시오. 삽입 후에는 주요 개체를 수정할 수 없으므로 보관된 개인 데이터의 레코드 전용 삭제는 감사 내역에 영향을 미칠 수 있는 삭제 및 다시 만들기 작업이 됩니다. 주요 개체는 표준 제한과 별도로 저장소에 대량 내역 데이터 집합을 저장하며, 더 이상 일상적인 작업에 필요하지 않은 완료된 트랜잭션 및 감사 로그에 적합합니다. 외부 저장소는 조직의 용량을 줄이면서 Salesforce Connect 통해 데이터를 쿼리할 수 있게 유지하고 유연한 쿼리 패턴 또는 엔터프라이즈 데이터 웨어하우스와의 통합에 적합합니다. 문제가 생기기 전에 증가가 표시되도록 개체 수준에서 저장소 소비를 모니터링하고, 레거시 첨부 파일 대신 Salesforce Files를 사용하고, 스토리지를 낭비하는 일반 최대값을 적용하는 대신 규정 준수 요구 사항에 따라 필드당 필드별 필드 감사 내역 보존을 구성합니다.

비용 최적화는 비즈니스 가치와 솔루션 비용의 균형을 맞추며, 먼저 정확한 비용을 설정해야 합니다. 라이센스 비용과 같은 단일 구성 요소를 살펴보면 솔루션의 실제 비용을 잘못 이해할 수 있습니다. 적은 라이센스 수수료는 구현, 운영, 통합, 변경 비용을 숨길 수 있습니다. 표시 숫자에 대한 결정은 사진의 일부만 사용합니다. 총 소유 비용은 전체적인 정보를 수집하는 모델입니다. 솔루션의 평생에 걸쳐 Salesforce 솔루션과 관련된 모든 비용을 포괄하고 솔루션과 명확하게 연결된 직접 비용과 간접 비용을 구분하며, 간단하게 무시할 수 있는 실제 비용을 포함합니다. 모델링을 모두 수행하면 비용 견적을 정보에 근거한 아키텍처 결정으로 전환하여 초기 비용이 아닌 장기 가치를 가중시킵니다.

시스템 구현, 운영 및 서비스 점검에 따른 직접 비용:

• 라이센스 및 소비 비용은 버전, 사용자 유형 및 기능 집합에 따라 달라지는 지속적인 구독 비용과 소비 기반 크레딧입니다. 사용자별 차이점이 상당하므로 Edition 선택 항목은 기본 비용 결정입니다. 소비 비용은 조기에 모델링하기 어려우므로 설계 결정을 내릴 때 해당 예측을 다시 확인하십시오.
• 설치 비용은 솔루션 설계, 개발, 테스트, 데이터 마이그레이션, 교육을 포함합니다. 이는 주로 일회성이지만 복잡성에 비례하여 진행 중인 서비스 점검 의무를 만듭니다. 회사는 개발에 중점을 두고 테스트 및 교육의 가치를 낮추기 때문에 구현 노력을 체계적으로 과소평가합니다.
• 운영 비용은 관리, 사용자 지원, 모니터링, 사고 대응, 운영 도구를 포함합니다. 솔루션 복잡성과 함께 증가하며 외부 인보이스가 아닌 내부 노력으로 표시되므로 계획에 표시되지 않는 경우가 많습니다.
• 서비스 점검 비용은 향상, 기술적 부채 해결, 릴리즈 조정, 구성 변경을 포함합니다. 서비스 점검은 일반적으로 숙성된 솔루션에 대한 개발 수용력의 60~80%를 사용하므로 가장 큰 지속 비용 범주입니다.
• 통합 비용에는 통합 플랫폼 라이센스, API 소비, 동기화 개발 및 지속적인 유지 관리가 포함됩니다. 시스템 수가 증가함에 따라 지점 간 통합 서비스 점검 복합성이 증가하므로 생태계 복잡성과 함께 증가합니다.
• 변경 비용은 비즈니스 프로세스 재설계, 변경 관리, 채택, 이해당사자 협조를 포함합니다. 비즈니스 단위 및 지역 전반에 따라 도달 범위가 증가하며 비즈니스 팀 노력으로 표시되므로 자주 생략됩니다.

간접 비용은 초기 계획에 즉시 표시되지 않지만 솔루션의 수명에 걸쳐 상당히 누적되며, 성숙한 구현의 경우 직접 비용을 초과하는 경우가 많습니다. 간접 지출을 무시하면서 직접 비용만 최적화하는 회사는 총 투자의 대부분을 놓치지 않습니다. 몇 가지 범주에 명시적 주의가 필요합니다.

조직 비용은 Salesforce 성공을 촉진하지만 Salesforce 인보이스에 표시되지 않는 투자입니다. 관리자, 개발자, 아키텍처의 내부 팀 임금, 버전 관리 및 CI/CD 도구와 같은 개발 인프라, 교육 및 인증 서비스 점검, 기술 개발, 혁신이 아닌 서비스 점검에 할당된 개발 수용력의 기회 비용이 포함됩니다. 마지막 항목은 지출된 항목으로 표시되지 않으므로 감지하기 어렵습니다. 배송되지 않은 혁신으로 표시됩니다.

기술 부채 금액은 아키텍처 바로 가기의 구성 비용입니다. 출시 마감일을 충족하기 위해 취한 바로 가기는 나중에 해결하기 위해 원래의 노력의 여러 배가 필요할 수 있는 서비스 점검 부담을 야기하며, 모든 스프린트가 수리 부채를 소비하는 것은 새로운 비즈니스 가치를 제공하지 않는 스프린트입니다. 아키텍처 개선 사항을 충분히 연기하는 팀은 결국 대부분의 수용력이 새 기능이 아닌 서비스 점검에 사용됩니다.

거버넌스 오버헤드는 승인 프로세스, 조정 회의, 수동 검토를 통해 시간이 소요됩니다. 거버넌스는 위험 감소 및 일관성을 통해 실질적인 가치를 제공하지만 과도한 거버넌스는 지연된 결정과 중복 노력을 통해 숨겨진 비용을 발생시킵니다. 따라서 모든 변경 사항에 대해 중앙 집중식 승인 병목을 필요로 하는 대신 안전한 자율성을 촉진하는 시스템을 설계하는 것이 목표입니다.

기능이 구현되었지만 완전히 채택되지 않은 경우 사용되지 않는 기능이 누적됩니다. 부분적으로 배포된 솔루션은 비례 값을 제공하지 않고 지속적인 서비스 점검을 소비하며 라이센스 사용 및 기능 채택 모니터링은 수용력 리디렉션을 위해 추가로 투자하거나 사용 중지할 수 있는 기능을 보여줍니다.

포괄적인 비용 가시성을 위해서는 직접 행 항목과 간접 행 항목을 모두 귀속해야 합니다. 전체적인 이미지만 신뢰할 수 있는 투자 결정을 지원하므로

접근 방식을 적용하기 전에 기준선 및 최적화된 아키텍처 대안에 대한 TCO 모델을 구축합니다. 문서화된 가정을 사용하여 3~5년의 비용을 예상하는 모델을 사용하면 옵션을 체계적으로 비교할 수 있습니다. 가장 중요한 가정에 대한 민감도 분석을 실행하여 비용 견적의 편차 및 경계를 결정합니다. 조건이 변경되면 결정을 다시 확인할 계획을 세웁니다. 추후 재평가를 새 인수가 아닌 증거 기반 비교로 만들기 때문에 가정을 기록하는 규칙이 값의 일부입니다.

초기 비용이 아닌 포괄적인 TCO 비교를 사용하여 사용자 정의 개발 대비 상업적으로 사용 가능한 솔루션을 평가합니다. 구축 및 구매 결정을 통해 진행 중인 구독 수수료 또는 진행 중인 서비스 점검 의무를 통해 장기 투자가 결정되며, 두 경로의 투자 프로필은 근본적으로 다릅니다.

AgentExchange(이전의 AppExchange)는 Salesforce ISV 커뮤니티의 선도적인 준비된 솔루션 소스입니다. 투자 프로필은 속도 및 공유 서비스 점검을 선호합니다. 배포는 비교 가능한 사용자 정의 빌드에 필요한 달이 아닌 주 단위로 측정됩니다. 공급업체는 고객의 노력 없이 플랫폼 릴리스 호환성을 비롯한 기능을 유지합니다. 기능은 기존 고객 기반에서 입증되므로 구현 위험이 줄어듭니다. 전문화된 기능은 단일 회사가 자체 자금을 지원하는 것보다 많은 공급업체 도메인 전문 지식 및 연구 투자의 혜택을 누릴 수 있습니다. 지원 가용성은 ISV에 따라 다르며, 일반적으로 문제에 대해 정의된 에스컬레이션 경로가 적용되며, 모델에 대한 지속적인 구독 비용이 적용됩니다.

사용자 정의 개발은 맞춤 및 제어를 선호합니다. 일반 솔루션 패턴을 저하하지 않고 고유한 조직 요구 사항에 정확하게 부합하며 기능 및 로드맵 우선 순위를 완벽하게 제어하고 기본 플랫폼 라이센스 외에 지속적인 구독을 수행하지 않고 동일한 기본 솔루션을 사용하는 경쟁사에서 사용할 수 없는 기능을 통해 경쟁 우위를 조성할 수 있습니다. 제약 사항은 회사가 서비스 점검 및 솔루션을 각 Salesforce 릴리스와 호환된 상태로 유지할 책임이 있는 것입니다.

장기 TCO 비교는 해당 프로필을 결정으로 전환합니다. 준비된 솔루션은 복잡한 연간 구독 비용을 부과하지만 공급업체가 제공하는 서비스 점검, 향상, 호환성 업데이트가 포함됩니다. 사용자 정의 솔루션을 사용하려면 일회성 개발 투자가 필요하지만 지속적인 서비스 점검 비용과 릴리스 호환성에 대한 전체 책임이 있습니다. 3~5년 프로젝트는 둘 모두에 대해 합계되므로 비교에 초기 비용이 아닌 전체 투자가 반영되므로 일반적으로 첫날보다 저렴해 보이는 옵션이 우선 적용됩니다.

원시 비용 외에 네 가지 요소가 구축 및 구매 결정을 결정합니다.

• 전략적 차별화는 기능이 구축할 가치가 있는 경쟁 우위인지 또는 더 잘 구매한 상품인지 결정합니다.
• 상당한 사용자 정의 기능을 사용하려면 수개월이 걸리므로 시간을 초과하여 가치 가져오는 시간은 기회를 포착하거나 경쟁의 압박에 대응하기 위해 즉시 기능이 필요한 경우 구매를 선호합니다.
• 조직 기능은 시간에 따라 솔루션을 유지하고 발전할 수 있는 능숙한 내부 팀이 있는 경우에만 구축을 선호하며, 해당 기능이 부재된 경우 구매를 선호합니다.
• 독점 형식 또는 광범위한 사용자 정의를 통해 딥 로크를 생성하는 솔루션은 요구 사항이 변경될 경우 위험합니다.

임시 판단이 아닌 일관된 평가에 기반하도록 결정을 체계화합니다.

라이센스 및 소비는 계산 및 저장소와 마찬가지로 비용별 가치 방정식에 대한 입력이며, 가장 일반적인 폐기물 소스 중 하나입니다. 최적화는 단순한 축소가 아닙니다. 모든 사용자를 작업에 적합한 라이센스에 일치시키고 계량된 모든 서비스를 효율적으로 호출하는 작업입니다.

라이센스 최적화는 모든 사용자를 올바른 라이센스 유형에 일치시킵니다. 핵심은 회사의 각 사용자를 작업에 필요한 라이센스와 일치시키는 것입니다. 전체 플랫폼 라이센스를 제한된 기능(읽기 전용 액세스 또는 간단한 워크플로 승인)이 필요한 사용자에게 할당하는 등 허가 과잉은 회사에서 가장 일반적이고 비용이 많이 드는 실수 중 하나이며, 누군가가 조회할 때까지 표시되지 않습니다. 사용자 역할, 로그인 활동, 기능 사용량을 정기적으로 감사하면 사용자 기반 전반에 걸쳐 할당 크기를 올바르게 조정하여 상당한 비용을 절감할 수 있습니다. 갱신 시뿐만 아니라 케이던스에서 실행합니다. 역할이 변경되고 사람들이 회사에서 직위를 변경함에 따라 불일치가 조용하게 증가합니다.

소비자 신용 최적화는 기업이 Agentforce, Data 360 및 기타 AI 기반 기능을 채택함에 따라 점점 더 중요해지고 있으며, 이 기능은 사용량이 아닌 위치별로 가격을 책정합니다. 팀이 프로세스를 비효율적으로 설계하거나 사용 패턴을 모니터링하지 않을 경우 대변 풀이 놀랍게 빠르게 소모될 수 있습니다. 고정 라이센스 수와 달리 프로비저닝 결정을 내리지 않아도 소비량이 급증할 수 있습니다. 신용 굽기 비율을 명확하게 파악하고, 검토를 트리거하는 소비 임계값을 설정하고, 계량된 서비스를 효율적으로 호출할 수 있도록 자동화 및 에이전트를 설계합니다. 거버 제한 내에서 트랜잭션을 유지하는 동일한 효율성 작업은 계량된 서비스를 크레딧 예산 내에 유지합니다. 이는 소비를 기준으로 표현된 비용별 가치 아이디어와 동일합니다.

환경 및 Sandbox 전략은 직접적인 비용에 영향을 미치는 리소스 결정이며, 성숙한 Salesforce 배달 모델은 잘 구조화된 환경 전략이 필요합니다. 개발, 테스트, 스테이징, 프로덕션 환경은 각각 고유한 목적을 제공하며, 적절한 Sandbox 유형 조합을 사용하면 팀이 프로덕션에 도달하기 전에 변경 사항을 안전하게 구축하고 확인할 수 있습니다. 의도적인 관리를 사용하지 않으면 활성 Sandbox 수가 특히 대규모 또는 장기 실행 프로그램에서 급격하게 증가하고 비용을 절감하는 방식으로 증가시킵니다. 해결 방법은 다른 자원과 동일한 의도에 따라 Sandbox 프로비저닝을 처리하는 것입니다. 더 이상 사용 중이 아닌 Sandbox를 유휴 상태로 두지 않고 새로 고치거나 프로비저닝을 해제하고 Sandbox 유형 선택을 편의 사항이 아닌 실제 데이터 충성도 요구에 따라 결정하고 소유권, 케이던스 새로 고침, 폐기에 대한 명확한 정책을 설정하여 부동산 크기를 작업에 맞게 유지합니다.

다중 조직 아키텍처는 비용을 곱한 값입니다. 단일 조직 아키텍처는 통합 라이센스, 공유 플랫폼 인프라, 관리 오버헤드 감소로 인해 혜택을 누릴 수 있습니다. 관리, 구성, 유지 관리 작업이 적기 때문입니다. 모든 사업부가 하나의 조직 내에서 운영되는 경우 통합은 교차 조직이 아닌 내부이며, 데이터 공유는 네이티브이며, Sandbox, 지원, 거버넌스 도구의 총 이력이 비례하여 작아집니다. 다중 조직 아키텍처는 지리적, 규제 준수 또는 조직적 분리에 필요할 수도 있지만 일부 비용 범주에 승수 효과가 있습니다. 각각의 추가 조직은 자체 라이센스 요구 사항, 자체 sandbox 상거래, 자체 통합 오버헤드, 자체 관리 노력을 제공하며, 교차 조직 배포, ID 연합, 데이터 동기화를 관리하기 위해 더 정교한 도구가 필요합니다. 취소하기 어려우며 비용이 많이 드는 아키텍처 결정을 내리기 전에 각 추가 조직의 실제 총 소유 비용을 이해합니다.

API 및 통합 비용은 Salesforce 에코시스템에서 가장 낮게 평가되는 비용 동인입니다. Salesforce를 외부 시스템에 연결하는 것은 간단하게 보일 수 있지만 복잡한 통합 요구 사항은 미들웨어 라이센스, 개발 노력, 지속적인 서비스 점검, 모든 데이터 교환에서 흐르는 API 소비에 대한 비용을 빠르게 누적합니다. 통합 시스템이 많거나 데이터 용량이 많거나 실시간 동기화 요구 사항이 거의 없는 기업은 특히 노출됩니다. 여기에는 아키텍처 접근 방식이 중요합니다. 소규모 API 호출을 자주 수행하는 채팅형 세분화된 통합은 원활한 이동을 최소화하는 잘 설계된 대량 또는 이벤트 중심 패턴보다 더 비싸고 취약하며 연결된 응용 프로그램으로 인해 차이 복합이 증가합니다. 통합 설계 표준을 관리하고, 가능한 경우 통합 플랫폼을 통합하고, 기존 통합이 원래 설계된 것처럼 계속해서 효율적으로 작동하는지 정기적으로 검토합니다.

지속 가능 아키텍처는 초기 설계 최적화 이상이 필요합니다. 지속적인 감독과 체계적인 책임이 필요합니다. 비용 모니터링 및 거버넌스는 일회성 실습에서 지속적인 운영 관행으로 최적화를 전환하는 프레임워크입니다. 일관된 추적 및 명확한 소유권을 통해 예기치 않은 비용 초과가 발생할 위험을 줄일 수 있으므로 지출된 모든 달러가 비즈니스 가치와 일치합니다.

기술 팀과 비즈니스 이해당사자가 모두 액세스할 수 있는 대시보드를 통해 지출 패턴에 대한 가시성을 확보하여 투자 대화를 인보이스가 아닌 데이터에 기반으로 합니다. 비용 가시성은 투자 우선 순위 및 최적화 기회에 대한 데이터 중심 대화를 시작하며, 세 가지 고유한 보기를 사용할 때 가장 적합합니다. 라이센스 이용 대시보드에 비활성 사용자, 초과 라이센스 사용자, 라이센스 유형 불일치가 표시되며, 이는 기본 인원 수 내에 숨겨진 최적화 기회입니다. 수용력 대시보드에 증가 추세와 함께 저장소, API, 처리 소비가 표시되므로 팀이 제한으로 인해 중단이 발생하기 전에 최적화할 수 있습니다. 투자 대시보드에는 사업부별 지출, 소유 팀별 환경 비용, 이용률 대비 추가 비용, 현재 성장을 기반으로 예상 지출이 표시되므로 예산 대화가 할당 대화로 전환됩니다.

이러한 대시보드는 Digital Wallet 및 메타데이터를 쿼리하는 사용자 정의 보고서를 비롯한 다양한 도구에서 사용할 수 있습니다. 도구는 결정을 내리는 데이터를 표시하는 규칙보다 중요하지 않습니다. 비즈니스 이해당사자 및 경영진과 대시보드를 공유하여 반응형 예산 토론이 아닌 정보에 근거한 투자 토론을 위한 투명성을 조성합니다. 이용 패턴을 확인하는 재무 팀은 지출을 최적화할 수 있습니다. 총 인보이스만 볼 수 있는 팀은 인보이스를 줄일 수만 있습니다.

제한을 초과하기 전에 최적화를 플래그하는 사전 경고를 포함하여 회사 전체에서 지출 인식을 구현합니다.

• 라이센스 예산은 용량에 접근할 때 경고와 함께 부서별 할당 목표를 설정하므로 갱신 시에만 제어되지 않는 프로비저닝이 발견되지 않습니다.
• 스토리지 예산은 다음 갱신 주기 전에 추세가 한도를 초과할 경우 경고를 통해 성장률을 모니터링합니다. 이러한 경고는 초과가 발생하기 전에 보관을 구현할 수 있도록 사전 경고를 제공합니다.
• API 예산은 사용량 임계값(예: 70% 및 85%)에 경고를 사용하여 제한 대비 소비량을 추적하므로 제한으로 인해 실패하는 경우 최적화는 긴급 대응이 아닌 사전 예방적입니다.
• 할당 제한 및 승인 프로세스를 통해 환경 확산을 제어하는 샌드박스 예산

예산 제어는 필요한 투자를 차단하지 않고도 비용 인식을 만들 수 있습니다. 경고 임계값은 반응형 스크러블링이 아닌 신중한 최적화를 활성화하는 조기 경고를 제공합니다.

비용 할당은 사업부 전체에서 회계 및 정보에 근거한 의사 결정을 만듭니다. 회사는 두 가지 모델 중 하나를 통해 이를 구현하며, 이는 부과되는 회계의 양에 따라 다릅니다. 실제 재무 비용을 부과하지 않고 사업부별로 보고서 비용을 표시합니다. 내부 청구 문제 없이 투명성을 조성하고 비용을 인식하는 토론 및 최적화 우선 순위를 촉진합니다. 이는 재무 책임보다 공동 작업 비용 관리를 선호하는 회사에 적합합니다. 차지백은 실제 비용을 사업부에 할당하고 소비 결정에 대한 직접적인 재정 책임을 생성합니다. 비용이 부서 예산에 직접 영향을 미치므로 더 강력한 최적화 동작을 유도하지만, 무엇에 대한 지불자에 대한 분쟁을 방지하기 위해 정확한 할당 방법이 필요합니다. 두 방법 모두에서 할당 규칙은 사용자 부서별 라이센스 비용, 개발 팀 소유 환경 비용, 통합을 사용하는 비즈니스 프로세스별 통합 비용, 작업을 자금을 조성하는 이니셔티브별 개발 비용과 같은 동일한 논리를 따릅니다. 해당 규칙이 없으면 모든 비용이 중앙 IT 예산에 포함되며 비즈니스 이해당사자는 플랫폼을 무료로 처리하며, 이는 비용 인식 없이 요청을 생성하는 조건입니다.

Salesforce 플랫폼 경제에 클라우드 FinOps 관행을 조정하여 정기적인 정리 대신 지속적인 최적화 기능을 만듭니다. 5가지 방법이 중요합니다.

• 재무, 아키텍처, 비즈니스 이해당사자 간의 기능 간 공동 작업을 통해 비용 결정에 비즈니스 가치가 지출과 함께 가중치가 부여됩니다. 이는 아키텍처 토론에 재무 전문 지식을 제공하고 예산 계획에 대한 기술적 이해를 제공합니다.
• 지속적인 최적화 케이던스는 지출 급증을 파악하는 월간 변칙 검토, 라이센스 할당 및 수용력 사용을 확인하는 분기별 이용 감사, 지출을 전략적 우선 순위에 맞추는 연간 종합적인 TCO 평가 등 정기적인 검토 주기를 통해 비용 드리프트를 방지합니다.
• 데이터 중심 투자 결정은 추정 또는 과거의 습관 대신 이용 데이터 및 TCO 모델을 사용합니다. 이러한 결정은 현재 지출이 최적의 가치를 제공하는지 여부에 대한 분석으로 “항상 이러한 방식으로 작업했음”을 대체합니다.
• 비용 모니터링 자동화는 사용량 추적, 최적화 기회 식별, 보고서 생성에 대한 수작업 노력을 줄이므로 직원이 선형적으로 증가하지 않고도 조직 복잡성에 따라 확장됩니다.
• 비용을 이해하는 설계자가 더 나은 제약을 설계하고 플랫폼 경제를 이해하는 개발자가 더 효율적인 자동화를 작성하므로 비용 인식 교육을 통해 팀이 아키텍처 결정이 총 소유 비용에 미치는 영향을 이해할 수 있습니다.

비용 인식을 아키텍처 검토 프로세스에 통합하여 배포 후 발견되지 않고 기능 및 기술 고려 사항과 함께 투자 영향을 볼 수 있습니다. 주요 설계 선택 항목을 문서화하는 아키텍처 결정 레코드에 비용 영향 평가를 포함합니다. 정의된 투자 임계값을 초과하는 솔루션의 경우 TCO 예상이 필요합니다. 설계 시 라이센스 영향을 평가하여 접근 방식을 적용하기 전에 프리미엄 라이센스 또는 추가 기능이 필요한지 여부를 결정합니다. API 소비 또는 미들웨어 라이센스에 영향을 미치는 패턴을 채택하기 전에 통합 비용을 평가합니다. 기능 및 비 기능 요구 사항과 함께 비용량 관점을 적용하는 아키텍처 검토 위원회는 더 잘 조율된 투자 결정을 생성합니다. 비용은 아키텍처 결정에 대한 단일 동인이 아닌 한 가지 입력으로 취급되므로 회사가 중요한 사항에 적절하게 투자하고 그렇지 않은 사항에 대한 낭비를 피할 수 있습니다.

클라우드 컴퓨팅 지속 가능성은 자원을 효율적으로 사용하여 디지털 인프라의 환경 영향을 최소화하는 데 중점을 두며, 비용당 가치와 자연스럽게 일치합니다. 자원 소비를 낮추는 동일한 효율성은 비용도 낮춥니다. Salesforce와 설계자는 지속 가능성 결과에 대한 책임을 공유합니다. Salesforce는 다중 테넌트 자원 풀 및 플랫폼 수준 효율성 향상과 함께 전력 사용 효율 최적화, 냉각 효율, 하드웨어 수명 주기 관리 등 데이터 센터 인프라를 관리합니다. 해당 멀티테넌트 환경 내에서 솔루션의 리소스 소비 패턴에 영향을 미칩니다.

개별 솔루션과 데이터 센터 배출 사이의 관계는 간접적이며, 정확하게 설명하는 것이 중요합니다. 단일 테넌트 최적화는 데이터 센터 배출을 직접 줄이지 않습니다. 이는 집계 효과에 기여합니다. 모든 테넌트 전반의 효율성 향상을 통해 Salesforce가 활용도가 높고 수용력 확장을 지연하여 인프라를 운영할 수 있습니다. 따라서 SOQL 쿼리, CPU 시간, 힙 소비량, 저장소를 비롯한 리소스 효율성 메트릭은 지속 가능성을 위한 프록시 지표로 사용됩니다. 계산 폐기물을 제거하면 성능 및 비용이 향상되고 플랫폼 전체 효율성 목표에 기여합니다. 이 기둥의 대량 처리, 선택적 쿼리, 캐싱, 비동기 처리, 규제된 데이터 수명 주기 등 설계 원칙은 더 적은 리소스를 소비하는 솔루션을 만듭니다. 지속 가능성은 아키텍처에 대한 별도의 이니셔티브가 아닙니다. 이는 재무 비용이 아닌 환경 영향에 대해 측정할 경우 자원 효율성이 표시됩니다.

여러 개의 아키텍처 관행은 대부분의 지속 가능성 가치를 가져오며 각각 성능 또는 비용도 향상하므로 동일한 기둥에 속합니다.

비활성 자동화는 비즈니스 가치를 제공하지 않고 인프라 자원을 소비합니다. 관련 없는 레코드를 처리하는 트리거, 불필요하게 실행되는 워크플로, 작업이 없을 때 실행되는 예약된 작업은 모두 폐기물 계산, 저장소, 에너지입니다. 해결 방법은 지난 90일간 실행이 없음, 레코드가 0개로 일관되게 처리되는 배치 작업, 최신 구현으로 대체되었지만 비활성화되지 않은 자동화와 같은 사용되지 않은 항목에 대한 명시적인 기준이 포함된 분기별 자동화 감사입니다. 비즈니스 요구 사항이 다시 표시될 경우 각 비활성화를 문서화하여 롤백할 수 있습니다. 이전 구현에서 남아 있는 수십 개의 프로세스 빌더(이전 연도에 실행이 없는 대부분)를 가지고 있는 회사는 모든 관련 레코드 저장에 대해 각 프로세스 빌더를 평가하기 위해 지불합니다.

피크가 없는 시간에 자원 집약적인 작업을 예약하면 시간 범위 전체에서 부하가 배포됩니다. 다중 테넌트 환경에서 이 규격은 업무 시간 동안 플랫폼 응답성을 개선하고 테넌트 전체에서 집계하여 Salesforce가 평균 사용률이 더 높은 인프라를 운영할 수 있도록 합니다. 사용량이 적은 창에 대한 배치 아카이빙, 보강, 정리를 예약하고 자정에 20개를 실행하고 처리 급증을 유발하는 대신 작업을 스태거하고, 예약된 폴링보다 이벤트 중심 패턴을 선호하여 작업이 없는지 확인하는 데 주기가 소요되지 않습니다.

동일한 값을 반복적으로 계산하면 CPU 주기 및 인프라 용량이 낭비됩니다. 한 번 계산하고 결과를 캐시한 후 트랜잭션 및 사용자 전체에서 재사용합니다. 플랫폼 캐시는 반복적으로 쿼리되는 참조 데이터를 제공하며 캐시된 롤업 값은 거의 실시간 정확도가 충분한 실시간 집계 쿼리를 방지하며, 수식 필드는 레코드 액세스 시 동적으로 재계산되며, 값을 저장하지 않고 자동화하여 유지해야 하며, Lightning Data Service는 클라이언트에 대한 중복 서버 요청을 제거합니다. 방지된 각 계산은 플랫폼에 반환되는 수용력입니다.

데이터 저장소는 인프라 자원을 소비하고 증가함에 따라 쿼리 성능이 저하됩니다. 활성 작업에 더 이상 필요하지 않은 데이터를 보관하거나 삭제하는 보존 정책은 활성 테이블을 작고 쿼리를 빠르게 유지합니다. 오래된 레코드를 예약된 작업의 주요 개체 또는 외부 저장소에 보관하고, 계속 저장소를 소비하는 일시 삭제에 의존하지 않고 준수 시 영구 삭제하고, 규정 준수에 필요한 것보다 훨씬 더 많은 내역을 저장하는 최대값을 적용하지 않고 필드당 필드 감사 내역 보존을 구성합니다. 예약된 처리의 경우와 마찬가지로 개별 아카이빙 결정은 데이터 센터 에너지 사용을 직접 감소시키지 않지만 모든 테넌트 전반에 걸친 데이터 수명 주기 규칙을 집계하면 플랫폼 효율성이 향상되고 스토리지 인프라 확장이 지연됩니다.

외부 통합은 Salesforce 및 연결된 시스템 모두에서 리소스를 사용합니다. 변경 데이터 수집 및 기타 이벤트 기반 패턴은 변경 사항을 반복적으로 확인하고 아무것도 찾지 않는 폴링 호출을 제거하므로 API 소비량을 줄이고, 관리자 제한을 활용하고, 낭비적인 계산을 제거합니다. 복합 API 패턴은 여러 작업을 단일 호출로 집계하고, 대량 API v2는 수천 개의 개별 REST 호출보다 훨씬 더 효율적으로 대량 볼륨을 처리하며, 기하율 백오프를 사용하는 재시도 논리를 통해 어려운 외부 시스템을 방지합니다. 5분마다 폴링하고 대부분의 시간을 할 일을 찾지 않는 단일 통합은 순수한 낭비이지만, 변경 이벤트로 구동되는 동일한 통합은 실제 변경 사항만 처리합니다.

에이전트 아키텍처는 대규모 언어 모델 추론을 통해 계산 자원을 사용하며, 같은 효율성 멘티셋이 적용됩니다. 프롬프트 길이를 최소화하고, 경계 없이 성장하는 전체 문장 기록을 포함하지 않고 대화 내역을 요약하고, 가장 능숙한 모델을 기본적으로 지정하지 않고 과업에 충분한 최소 모델을 사용하고, 참조 데이터 및 결정적 응답을 캐시합니다. 5개만 평가된 경우 50개의 벡터 검색 결과를 검색하면 가치가 추가되지 않은 추론 및 검색 자원을 사용하므로 실제 사용량에 맞게 검색 제한을 구성합니다.

지속 가능성은 솔루션이 발전하고 데이터 용량이 증가하며 사용자 모집단이 확대될수록 자원 소비 패턴이 변경되므로 이 기둥의 나머지 부분과 마찬가지로 일회성 통과 대신 지속적인 모니터링이 필요합니다. 모니터링은 작업을 트리거하는 경우에만 중요합니다. 각 메트릭에 대해 실천 가능한 임계값(트랜잭션당 대상 수를 초과하는 SOQL 쿼리 수, 월별 백분율 이상의 스토리지 증가 또는 대상보다 낮은 캐시 일치률 등)을 정의하고 먼저 수행할 최적화를 문서화합니다. 효율성 향상이 집계적으로 가장 큰 영향을 미치는 대용량 트랜잭션 및 자주 실행되는 자동화에 노력을 기울입니다. 프로세스 빌더는 2025년 12월 31일에 지원 종료에 도달했습니다. 나머지 프로세스 빌더를 플로로 마이그레이션하십시오. 단순히 비활성화하지 마십시오.

이 체크리스트를 사용하여 솔루션이 비용당 최대값을 반환하는지 여부를 평가합니다. 이 필드의 리소스 효율성 및 비용 discipline 관행을 하나의 검토로 결합하므로 둘 다 단일 결정이기 때문입니다.

가치 및 비용 모델링

• 모든 중요 Salesforce 투자를 측정 가능한 비즈니스 결과에 연결합니다.
• 접근 방식을 적용하기 전에 직접, 간접, 일회성, 진행 범주의 총 소유 비용을 모델링합니다.
• 3~5년 간의 기준선 및 최적화된 아키텍처 대안에 대한 TCO를 비교합니다.
• 임시 판단에 의존하지 않고 전략적 차별화, 가치 실현 시간, 종료 비용을 고려하는 일관된 build- vs-buy 평가를 적용합니다.

자원 효율성

• 최대 부하 및 최대 데이터 용량 아래 총괄자 제한 내에서 트랜잭션을 편안하게 작동하도록 설계합니다.
• 쿼리를 색인화된 필드에 대해 선택적으로 지정하고 대형 개체에 대해 배포하기 전에 쿼리 계획 도구를 사용하여 확인합니다.
• 모든 데이터 작업을 대량 처리하고 동기 제한에 따라 의도적으로 비동기 처리를 선택합니다.
• 플랫폼 캐시 및 Lightning 데이터 서비스를 통해 참조 데이터를 캐시하여 반복 쿼리 및 재계산을 방지합니다.
• 대용량 개체를 배포하고 모니터링하여 데이터 왜곡을 방지합니다.
• 트리거, 서비스, 선택기 논리를 중앙 집중화하여 비즈니스 논리를 테스트 가능하고 변경하기 쉬운 상태로 유지합니다.
• 생성에서 보관까지 전체 데이터 수명 주기를 정의하고 개체 수준에서 저장소 소비를 모니터링합니다.

라이센싱 및 소비

• 각 사용자를 작업에 필요한 라이센스 유형에 맞추고 역할, 로그인 활동 및 기능 사용을 정기적으로 감사합니다.
• 소비 배출권 굽기율을 파악하고 계량된 서비스를 효율적으로 호출할 수 있도록 자동화 및 에이전트를 설계합니다.
• 명확한 소유권, 새로 고침 케이던스, 폐기 정책을 사용하여 Sandbox 프로비저닝을 관리합니다.
• 조직을 추가하기 전에 전체 멀티 조직 비용 승수를 이해하고 채팅형 패턴보다 대량 또는 이벤트 중심 통합을 선호합니다.

모니터링 및 거버넌스

• 기술 팀과 비즈니스 이해당사자가 액세스할 수 있는 비용 및 수용력 대시보드를 제공합니다.
• 라이센스, 저장소, API 소비, Sandbox에 대한 예산 경고를 설정하여 최적화가 반응성이 아닌 사전 예방적입니다.
• 비용 할당을 통해 사업부 전체에 대한 책임이 생성되도록 표시 또는 지불을 설정합니다.
• 월별 변칙 검토, 분기별 이용 감사, 연간 종합적인 TCO 평가와 같은 FinOps 케이던스를 채택합니다.
• 비용 영향 평가를 아키텍처 검토 및 아키텍처 결정 레코드에 통합합니다.

지속적인 최적화 및 지속 가능성

• 최적화를 지속적인 관행으로 취급하고 이전 최적화 투자에서 예상되는 수익을 달성했는지 확인합니다.
• 정기적인 감사를 통해 사용되지 않는 자동화 및 중복 계산을 제거합니다.
• 시간 경과에 따른 리소스 소비를 추적하고 메트릭이 중복될 때 최적화를 트리거하는 실행 가능한 임계값을 정의합니다.

좋게 설계된 프레임워크에 대한 사용자 의견을 공유하십시오.