# architect 올바르게 설계됨 (well-architected) - Full Documentation ## 소개 Diagram showing Salesforce Well-Architected core capabilities are Trusted, Easy, Adaptable Salesforce Well-Architected Framework는 Salesforce Customer 360 플랫폼을 사용하여 로드맵을 작성하고 솔루션을 설계하는 데 필요한 시간과 상태를 보여줍니다. Salesforce 및 에코시스템 전반의 제품 팀 및 구현 전문가의 Knowledge 기반으로 환경에서 찾을 수 있는 패턴 및 안티 패턴의 처방 지침과 예를 공유합니다. Salesforce Well-Architected는 신뢰할 수 있고 쉽게 조정할 수 있는 솔루션을 구축할 수 있도록 구성되어 있습니다. **신뢰할 수 있는** 솔루션은 이해당사자를 보호합니다.
**쉬운** 솔루션은 빠르게 가치를 제공합니다.
**적응 가능한** 솔루션은 비즈니스와 함께 발전합니다.
Salesforce Well-Architected는 Customer 360 플랫폼에서 건전한 솔루션을 구축하는 데 필요한 아키텍처 사고를 수행할 수 있도록 설계되었습니다. Salesforce로 솔루션을 만드는 아키텍처의 고유한 과제는 플랫폼의 근본적인 유연성입니다. 하나의 솔루션은 Salesforce에서 제공하는 사전 빌드 솔루션(예: Sales Cloud, Service Cloud, 다른 Industries Cloud 수직)을 확장할 수 있습니다. 다른 솔루션은 완전히 사용자 정의된 응용 프로그램일 수 있습니다. Salesforce로 할 수 있는 작업은 광범위하고 심층적이며 구현에 가장 적합한 특정 기술 선택 항목은 비즈니스 요구에 따라 다릅니다. 가능한 모든 Salesforce 솔루션에 대해 장기간 건강을 유지할 수 있는 최상의 기회를 제공하는 항목을 파악하기가 매우 어려울 수 있습니다. Salesforce Well-Architected는 사용자에게 필요한 경험이 높은 설계자의 인사이트와 지침을 제공합니다. 의견에 따른 보기 및 권장 사항을 사용하여 생각을 검증하거나 제기하고 새로운 고려 영역이나 기술에 대한 인사이트를 얻을 수 있습니다. 구현 전반의 광범위한 다양성에 따라 모든 정상적인 솔루션에 공통된 아키텍처 벤치마크가 있는지 이해하기도 어렵습니다. Salesforce에서는 회사와 사람으로 하는 모든 작업이 핵심 가치에 따라 결정됩니다. 이는 아키텍처에도 적용될 수 있다고 생각합니다. 따라서 Salesforce Well-Architected는 신뢰할 수 있고 쉽게 조정할 수 있는 핵심을 중심으로 구축되어 있습니다. 복잡한 아키텍처 세부 사항 및 제약 사항을 평가할 때 이러한 핵심 성능으로 돌아가 의사 결정을 안내하는 컴퍼스 포인트로 사용할 수 있습니다. 아래에서 신뢰할 수 있고 쉽게 조정할 수 있는 프레임워크 전반에서 탐색할 개별 주제에 대한 세부 사항을 확인할 수 있습니다. ## 주제 정렬 방법 두 가지 수준을 사용하여 Salesforce Well-Architected 전반에서 정보를 구성합니다. 최상위 수준은 올바르게 설계된 솔루션입니다. 신뢰할 수 있는, 쉬운, 적응 가능. 두 번째 수준에서는 신뢰할 수 있는 간편한 조정 가능 솔루션의 특정 측면과 관련된 고려 사항, 구축할 패턴(또는 피할 수 있는 안티 패턴) 및 처방 지침에 대해 자세히 살펴봅니다. 이 프레임워크 전반에 걸쳐 제공되는 지침에 맞춰 설계를 조율하면 Salesforce Customer 360 응용 프로그램의 품질을 높이고 지속적인 상태를 유지할 수 있습니다. 패턴 및 안티 패턴을 빠르게 시작하고 싶으십니까? [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/patterns)를 방문하십시오. 아래에서 주제가 정렬되는 방법에 대한 개요를 확인할 수 있습니다.
신뢰할 수 있음
신뢰할 수 있는 솔루션은 비즈니스 및 이해당사자를 보호합니다.
보안 호환 신뢰할 수 있는
조직 보안
세션 보안
데이터 보안
법적 준수
윤리적 표준
접근성
가용성
성능
확장성
쉬운
간단한 솔루션은 비즈니스 가치를 빠르게 제공합니다.
의도 자동 참여
전략
유지 보수
가독성
효율성
데이터 무결성
간소화됨
유용
적합
비즈니스와 함께 적응 가능한 솔루션이 발전합니다.
항력 공합 가능
응용 프로그램 수명 주기 관리
사고 대응
연속성 계획
우려 사항 분리
상호 운용성
패키징 기능
## 소개 Salesforce Well-Architected는 Salesforce 및 에코시스템 전반에서 전문가의 지침 및 성공 사례를 나타냅니다. 잘 설계된 리소스 및 Knowledge 제공한 모든 사람들에게 감사 인사를 전합니다. 올바르게 설계된 문서는 1년에 두 번 업데이트됩니다. 다음 서비스 점검 기간 동안 Well-Architected에 기여하는 방법을 알릴 것입니다. 언제든지 Well-Architected에 대한 피드백을 [여기에](https://sfdc.co/bxNtvh) 제공할 수 있습니다. ## 의견을 알려주십시오. Salesforce Well-Architected의 관련성을 유지할 수 있도록 도와주십시오. 이 콘텐츠에 대한 사용자 의견을 제공하려면 [ 설문 조사](https://sfdc.co/bxNtvh)을 작성하고 다음에 표시할 내용을 알려주십시오. > [여기에](/docs/architect/ko-kr/well-architected/guide/contributors) 업데이트 일정에 대해 알아보십시오. ## 소개 구성 가능한 솔루션은 빠르고 안정적으로 조정됩니다. 구성 가능하도록 설계된 시스템은 서로 원활하게 작동할 수 있는 의미 있는 단위 또는 빌딩 블록으로 구축되며, 서비스 내부 및 외부에서 쉽게 교체할 수 있습니다. 시스템에 구성 기능을 구축하면 시스템의 개별 단위를 재구성하거나 재구성하여 새로운 기능을 도입하거나 기술 부채를 제거할 수 있습니다. 구성 가능성은 팀이 소량의 변경을 통해 의미 있는 기능을 구축하고 제공하는 데 집중할 수 있으므로 더 빠르고 예측 가능한 배달 주기와 릴리스를 제공합니다. 컴포지블 시스템을 사용하면 비즈니스에서 내부적인 자극이든 외부 요인으로 인한 자극이든 더욱 안정적으로 빠르게 적응할 수 있습니다. 복합성은 시스템의 [복원성](/docs/architect/ko-kr/well-architected/guide/resilient)을 높이고, 솔루션과 아키텍처 패턴을 더욱 [의도적인](/docs/architect/ko-kr/well-architected/guide/intentional) 방식으로 만드는 데 도움이 됩니다. 우려 사항 분리, 상호 운용성, 패키지 가능성의 세 가지 핵심 습관을 구축하여 Salesforce 솔루션의 구성 가능성을 높일 수 있습니다. 아래에서 구성 가능한 시스템의 단일 단위 또는 구성 가능한 시스템의 여러 단위에 대한 두 가지 방법으로 이러한 습관의 관계를 확인할 수 있습니다. 단일, 컴포지블 유닛: 이 다이어그램은 세 개의 중첩된 카드를 통해 구성 가능한 항목이 어떻게 연결되는지 보여줍니다. 가장 내부 카드는 기능 단위이고, 다음 층은 상호 운용성이며, 외부 층은 포장 가능성입니다. 구성 가능한 시스템: 이 다이어그램은 세 개의 중첩된 카드를 통해 구성 가능한 항목이 어떻게 연결되는지 보여줍니다. 가장 내부 카드는 기능 단위이고, 다음 층은 상호 운용성이며, 외부 층은 포장 가능성입니다. ## 우려 사항 분리 소프트웨어 엔지니어링 및 시스템 아키텍처의 기본 개념인 *걱정 분리*은 모듈식 단위로 분리할 수 있는 더 큰 시스템 내에서 다양한 관심사를 식별해야 합니다. 시스템 내에서 우려 사항을 강력하게 분리하려면 시스템 전체에서 응용 프로그램 논리 및 기능에 대한 의미 있는 단위를 만들어야 합니다. 소규모 단위를 사용하면 앱 배달 및 서비스 점검 팀이 더 큰 시스템의 중단을 최소화하면서 변경 방법과 위치를 쉽게 이해할 수 있습니다. 소규모 유닛은 또한 [기술 부채를](/docs/architect/ko-kr/well-architected/guide/intentional#기술-부채) 해결할 때 작업을 집중하는 방법과 위치를 명확하게 설명하고 시스템의 전체적인 [읽기](/docs/architect/ko-kr/well-architected/guide/intentional#가독성) 기능에 기여합니다. 비즈니스 역량 및 상태 관리를 지향하여 Salesforce 조직에서 우려 사항을 더 잘 구분할 수 있습니다. ### 기능 단위 Salesforce 시스템의 경우 문제 분리에 가장 적합한 접근 방식은 비즈니스 지향적 관점을 적용하여 시스템 내의 모듈 단위 또는 기능을 식별하고 구성합니다. 이는 엔지니어링 중심 보기와 달리 기술적 기능을 기반으로 단위를 식별합니다. 우려 사항을 구분하는 비즈니스 지향 관점에서는 비즈니스 및 비즈니스 사용자에게 제공하는 서비스를 기반으로 시스템에서 코드 및 사용자 정의를 구성해야 합니다. 이 접근 방식을 취하는 것은 시스템의 중복 또는 중복 기술 기능에 대한 잠재력을 무시하는 것을 의미하지는 않습니다. 대신 기술 서비스가 비즈니스에 대해 투명한 구성 원칙에 명확하게 매핑됨을 의미합니다. 비즈니스 역량을 기반으로 비즈니스 분석 및 검색 팀 간의 전달이 가능한 한 간단하게 처리되도록 지원합니다. 앱 빌더가 구성 가능한 아키텍처에 작업 단위가 매핑되는 위치를 모르는 경우 구성 가능한 앱 환경이 아닌 혼란스러운 상황이 있습니다. 비즈니스에서 요구하는 종료 상태와 조직 내의 모듈 단위 간의 매핑이 명확하지 않으면 개발 팀 또는 공급업체가 시스템에 중복 기능을 구축할 가능성이 높아집니다. 기능 단위를 비즈니스 역량에 맞추려면 다음을 고려하십시오. - **할 일을 시작하십시오**. 사용자 및 비즈니스 자체의 수행할 작업(JTBD)에 초점을 맞춥니다. Tony Ulwick가 선도한 JTBD 접근 방식은 사람들이 제품 또는 서비스를 사용하여 달성하려는 "작업" 또는 실제 목적을 이해하는 데 중점을 두고 있습니다. 이는 사용자의 역할 관련 과업 또는 비즈니스 프로세스의 개별 단계보다 더 높은 수준의 추상화입니다. 예를 들어 중복 확인 및 주소 확인과 같은 과업은 "고객 단일 보기 설정"이라는 상위 순서의 함수에 속할 수 있습니다. 이러한 상위 비즈니스 기능을 명확하게 이해하면 시스템의 일부를 해당 기능에 매핑할 수 있습니다. - 보고 구조가 아닌 **능력 지향** 사업부의 내부 계층은 수행할 의미 있는 기능 또는 작업을 프록시하는 것이 아닙니다. 비즈니스의 내부 계층은 프로세스 및 팀 구조(예산 제외)에 중대한 영향을 미칩니다. 이는 중요한 물류 고려 사항입니다. 그러나 비즈니스의 기능적 요구 사항은 물류보다 더 높은 추상 수준에서 작동합니다. 상위 기능 대신 보고 구조를 제공하는 모듈을 만드는 경우 해당 모듈이 비즈니스 기능과 연결되는 방식을 식별하기 위해 추가 단계를 수행해야 할 수 있다는 점에 유의하십시오. - **반복적이세요**. 먼저 비즈니스와 파트너 관계를 맺어 최소 수명 가능한 제품(MVP)에 적합한 기능을 식별합니다. 기능을 식별하면 해당 MVP 구축을 시작합니다. 구축할 때 생성하는 기능 유닛의 중심에 있는 프로세스, 메타데이터, [이벤트 또는 메시지를](/docs/architect/ko-kr/well-architected/guide/composable#messaging-및-이벤트) 식별합니다. 외부 종속성인 프로세스, 메타데이터, 이벤트 또는 메시지를 식별합니다. 더 많은 기능 유닛이 설계되면 [API 관리](/docs/architect/ko-kr/well-architected/guide/composable#api-관리) 및 [종속성 관리](/docs/architect/ko-kr/well-architected/guide/composable#종속성-관리)을 구현하여 서로 잘 작동하는 유닛을 구축합니다(실로 유닛을 구축하는 대신). 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/composable#우려-패턴-및-안티-패턴-구분) 목록은 Salesforce 솔루션 내에서 비즈니스 기능에 대한 올바른(그리고 나쁜) 지향성을 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별할 수 있습니다. Salesforce에서 비즈니스 기능을 효과적으로 활용할 수 있는 도구에 대해 자세히 알아보려면 컴포지블과 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/composable#구성-가능과-관련된-도구)를 참조하십시오. ### 시/도 관리 시/도 관리는 다양한 시점에서 시스템 전반에서 정보를 이동하는 데 중점을 둡니다. 효과적인 상태 관리를 통해 응용 프로그램이 계획되지 않은 결과 또는 불확실한 결과를 최소화하면서 복잡한 데이터 플로 또는 상호 작용을 처리할 수 있습니다. 모듈식 Salesforce 조직에서 상태를 관리하면 단위 내 및 간에 논리 플로에 대한 명확한 경로와 계획되지 않은 실행 동작에 대한 우수한 경로를 구축할 수 있습니다. 시/도 관리를 사용하면 모듈식 Salesforce 응용 프로그램 단위에서 일관된 논리 스트림을 만들 수 있습니다. 대부분의 경우 유닛 간의 정보 흐름을 구성하기 위해서는 [상호 운용성이](/docs/architect/ko-kr/well-architected/guide/composable#상호-운용성) 필요합니다. 결합된 단위 전반에서 상태를 관리하는 데 어려움을 겪는 경우 Salesforce에서 단독 응용 프로그램 개발이 발생하는 경우가 많습니다. 이는 단수 플로 내에서 복잡한 프로세스를 오케스트레이션하려는 시도로 구축된 대규모 "모노플로"에서 볼 수 있습니다. 또 다른 예는 *스파게티 코드*를 통해 복잡한 프로세스를 오케스트레이션하는 대규모 Apex 클래스 또는 긴 일련의 단일 사용 방법입니다. 이러한 유형의 응용 프로그램 아키텍처는 리팩터링 및 디버깅을 어렵게 만들고 새 팀 구성원 또는 공급업체의 온보딩 시간을 늘립니다. 또한 기능을 재사용할 수 없으므로 비즈니스에 전달되는 응용 프로그램의 가치를 줄일 수 있습니다. 모듈식 Salesforce 조직에서 상태를 관리하려면 다음을 고려하십시오. - **시/도 및 시/도 없는 패턴을 사용하는 시기를 결정합니다**. 시/도 패턴은 실행 경로 전반에 걸쳐 정보를 보존하며, 시/도 없는 패턴은 보존하지 않습니다. 분리된 시스템에서 상태가 없는 패턴을 사용하면 구성 요소가 더 빠르게 재구성되고 부작용이 줄어듭니다. 그러나 상태가 없는 패턴은 모든 사용 사례에 적합하지 않습니다. 데이터 작업을 위한 구성 요소를 구축하는 경우 상태 지정 패턴이 시스템 전체의 데이터 무결성 및 일관성에 도움이 됩니다. 구성 요소가 다음 기준을 충족하는 경우 상태가 있는 패턴을 사용합니다. - 더 큰 실행 경로 내의 배치 인식은 구성 요소의 동작에 필수적입니다. - 다운스트림 작업의 결과를 기반으로 구성 요소의 동작을 변경해야 합니다(예: 다운스트림 구성 요소의 롤백/오류/성공 메시지를 기반으로 실행을 변경해야 함). - 구성 요소가 작업을 완료하기 위해 외부 또는 다운스트림 시스템의 응답을 기다려야 합니다. - 주 정보에 대한 의미 있는 범주 **생성** *시/도*는 Salesforce 조직 내부(또는 그 외부)의 깊고 광범위한 정보에 적용할 수 있는 모호한 용어로서, 용어 자체가 거의 의미가 없습니다. 따라서 상태형 패턴을 구축하는 데 필요한 첫 번째 단계는 시스템 내에서 가장 중요한 상태형 실행 경로(또는 상태형 행동의 종류)에 대한 _의미한_ 범주를 만드는 것입니다. 고려해야 할 몇 가지 범주: - 탐색 및 양식 - 데이터베이스 작업 - 배치 및 대량 작업 - 오류 - ** [데이터베이스 트랜잭션](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#데이터베이스-조작) 측면에서 데이터 관련 상태를 정의합니다**. 플랫폼의 내장형 동작은 Salesforce에서 데이터에 대한 대부분의 시/도 고려 사항을 제한합니다. 이 동작에 대해 또는 이 동작에 대해 관리하지 마십시오. 설계하고 사용합니다. 배포된 트랜잭션 논리를 최소화하거나 제거하는 솔루션을 설계합니다. (자세한 내용은 [데이터 처리](/docs/architect/ko-kr/well-architected/guide/automated#데이터-처리)을 참조하십시오.) - 기능 단위 내부 및 전체에서 발생하는 상태를 **지정합니다**. 기능 단위를 더 큰 시스템에 어셈블할 때 상태가 없는 구성 요소와 상태 구성 요소 동작을 혼합하는 경우에 유의하고, 처리에 끝없는 루프나 공백을 일으킬 수 있는 조합을 방지합니다. - **수수료 정의** 구성 요소가 상태 관련 데이터를 시스템의 다른 부분으로 전송하는 데 사용할 [메시지 또는 이벤트 패턴](/docs/architect/ko-kr/well-architected/guide/composable#messaging-및-이벤트)을 고려하십시오. 거래 인식 및 구성 요소의 [처리](/docs/architect/ko-kr/well-architected/guide/automated#데이터-처리)를 구축하고 있는지 확인합니다. 핸드오프에 배포된 트랜잭션 논리를 포함하지 마십시오. - 프로세스 다이어그램과 상태 간의 **매핑 만들기** 프로세스 다이어그램은 다양한 시점에서 시스템을 통해 정보를 이동하는 단계를 자세히 설명합니다. 상태 다이어그램에 정보(상태)의 실제 변경 사항이 표시됩니다. [Salesforce 다이어그램](/docs/architect/ko-kr/reference-diagrams/guide/kit-of-parts) 형식의 메타데이터 바닥글 부분을 사용하여 프로세스의 각 단계 내에서 변경되는 정보 상태를 캡처합니다. 프로세스 다이어그램과 상태 다이어그램을 구분하는 경우 해당 다이어그램을 연결해야 합니다. 이 개념은 시스템을 통해 이동하는 정보가 아닌 설계 및 구현 시 프로세스 또는 시스템 환경의 현재 및 향후 상태를 수집하는 것과 혼동해서는 안 됩니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/composable#우려-패턴-및-안티-패턴-구분) 목록은 Salesforce 솔루션 내에서 올바르고 나쁜 상태 관리를 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템의 위치를 식별할 수 있습니다. 상태 관리용 Salesforce 도구에 대한 자세한 내용은 Composable과 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/composable#구성-가능과-관련된-도구)를 참조하십시오. ### 우려 패턴 및 안티 패턴 구분 다음 표는 조직에서 조회(또는 구축)할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/adaptable-separation-of-concerns)에서 관심 분리를 위한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
기능 단위 설계 기준:
- 명명 규칙은 기능 단위를 지정하는 방법을 설명합니다.
- 현재 정의된 모든 기능 단위(및 관련 명명 규칙) 목록이 있습니다.
- 기능 단위 추가 또는 변경 사항을 제안하기 위한 표준이 있습니다.
설계 기준:
- 설계 표준이 없거나 기능 단위 및 사용 사례를 처리하지 않습니다.
문서:
- 시스템 환경 다이어그램에 조직의 기능 단위가 명확하게 표시됩니다.
- 모든 문서 및 구현 다이어그램에 구성 요소의 기능 단위가 명확하게 표시됩니다.
- 개별 구성 요소에 대한 문서에 구성 요소의 기능 단위 매핑이 포함되어 있습니다.
- 기능 단위 내의 모든 구성 요소를 검색하고 쉽게 찾을 수 있습니다.
문서:
- 구성 요소 문서가 없음
- 구성 요소 문서는 구성 요소가 속한 기능 단위를 설명하지만, 해당 기능 단위의 정의가 표시되는 유일한 위치입니다.
- 특정 기능 단위를 검색할 수 없으며/또는 검색 시 기능 단위 내의 모든 구성 요소를 식별하는 데 도움이 되지 않습니다.
조직에서:
- 지정된 메타데이터(예: 플로, Apex 클래스 또는 Lightning 페이지)에 대한 기능 단위 정렬을 빠르게 파악할 수 있습니다.
- 기능 단위에 비즈니스에 친숙한 용어로 레이블이 지정됩니다.
조직에서:
- 메타데이터에 대한 기능 단위 정렬을 식별할 수 없습니다.
- 기능 단위 정보가 일관되지 않거나 부정확합니다.
- 기능 단위 정보는 비즈니스 사용자에게 의미가 없는 엔지니어링 중심 용어로 레이블이 지정됩니다.
국가관리 설계 기준:
- 상태가 있는 디자인과 상태가 없는 디자인의 사용 사례가 명확합니다.
- 시/도 없는 통신에 대한 승인된 패턴이 있는 경우
- 시/도 커뮤니케이션에 대한 승인된 패턴이 있는 경우
- 시/도에 대한 범주가 없음
설계 기준:
- 설계 표준이 없거나 시/도 없는 패턴 및 사용 사례를 처리하지 않습니다.
문서:
- 시/도 및/또는 상태가 없는 통신을 처리하는 모든 구성 요소는 구현된 패턴을 나타냅니다.
- 특정 stateful/stateless 패턴을 구현한 모든 구성 요소를 검색하고 찾을 수 있습니다.
- 프로세스 및 상호 작용 다이어그램에서 시/도 범주 및 핸드오프에 대한 세부 사항을 제공합니다.
문서:
- 구성 요소 문서가 없음
- 구성 요소 문서에 구현된 stateful/stateless 패턴이 설명되어 있지만 정의가 표시되는 유일한 위치입니다.
- 특정 패턴을 검색할 수 없으며/또는 검색 시 해당 패턴을 사용하는 모든 구성 요소를 식별하는 데 도움이 되지 않습니다.
Apex:
- 세이브포인트 및 롤백 동작이 모든 데이터 작업에 사용됩니다.
Apex:
- 세이브포인트 및 롤백 동작이 사용되지 않습니다.
지속:
- 오류 경로 및 레코드 롤백 요소가 사용됩니다.
지속:
- 레코드 롤백 요소가 사용되지 않음
## 상호 운용성 상호 운용성을 위해 설계된 시스템에서는 구성 요소가 정보를 교환하고 함께 효율적으로 작업할 수 있습니다. 상호 운용성은 모듈식 시스템을 사일로 시스템이 아닌 구성 가능한 시스템으로 만들기 위한 핵심입니다. 상호 운용성은 [연결하게 연결된](/docs/architect/ko-kr/well-architected/guide/composable#느슨한-커플링) 시스템에서 달성하기 어려울 수 있습니다. 시스템 전체에서 단위 간의 독립성과 전체적인 [관심 분리](/docs/architect/ko-kr/well-architected/guide/composable#우려-사항-분리)을 저해하지 않는 일관된 통합 방법에 대한 표준을 설정해야 합니다. 상호 운용성은 사용자 환경의 품질에도 영향을 미칩니다. 사용자는 하나의 영역(예: 주문 정보)에서 생성된 데이터를 다른 영역(예: 마케팅 캠페인)에서 사용할 수 있을 것으로 예상하며, 빌더는 플로 구축 또는 API 인증과 같은 작업 방법을 배우면 다음 문제를 해결할 때 익숙한 기법이 작동하는지 확인할 수 있습니다. 상호 운용성을 위해 설계하지 못하면 예비 아키텍처, 데이터 복제, 프로세스 비효율성, 개발 및 지원 비용이 증가합니다. 메시징 및 이벤트 매김 및 API 관리와 함께 모듈식 시스템에서 상호 운용성을 만들 수 있습니다. ### Messaging 및 이벤트 메시지 및 이벤트는 시스템 전반의 구성 요소를 활성화하여 정보를 보내고 받을 수 있는 두 가지 방법입니다. 전달할 수 있는 콘텐츠 측면에서 이벤트와 메시지는 유사합니다. 가장 큰 차이점은 보낸 사람의 동작입니다. _메시지를_ 보내는 구성 요소는 일반적으로 특정 대상에 데이터를 보내고 수신자의 반응을 기다립니다. 반대로, 구성 요소는 무언가가 발생했을 때 *이벤트*를 방출합니다. 특정 대상이나 응답에 대한 기대가 없습니다. 동작의 차이점은 다양한 커뮤니케이션 패턴을 지원합니다. 메시지는 시/도 커뮤니케이션 패턴을 지원하며, 이벤트는 시/도 없는 커뮤니케이션 패턴을 지원합니다. (이 차별에 대한 자세한 내용은 [국가 관리](/docs/architect/ko-kr/well-architected/guide/composable#시도-관리)를 참조하십시오.) 프로토콜에 맞춰 팀을 조율하고 Messaging 및 이벤트에 사례를 사용하는 것이 중요합니다. 표준이 명확하지 않으면 시스템 전체에서 패턴이 혼합될 수 있으므로 다음이 발생할 수 있습니다. - 특정 사용 사례에 잘못된 패턴이 적용되는 성능 및 확장성 문제 - 최종 사용자에게 시스템이 불안정해 보이도록 하는 불일치 처리 - 오래 걸리는 문제 해결 시간 및 더 복잡한 서비스 점검 프로세스 메시지 및 이벤트를 설계하여 Salesforce 조직 내에서 더 느슨하게 연결된 구조를 만들 때 다음 사항을 고려하십시오. - **동기화 및 비동기 사용 사례를 식별합니다**. 이벤트를 사용하면 시스템 전체에서 누락된 통신, 상태가 없는 통신, 비동기식 통신을 수행할 수 있습니다. Messaging을 사용하면 더욱 긴밀하게 제어되고 상태를 유지하며 동기식으로 통신할 수 있습니다. 메시지 또는 이벤트를 사용할 시기를 결정할 때 커뮤니케이션이 동기식(잠재적으로 차단 가능)이거나 비동기식 및 차단되지 않아야 하는지 결정해야 합니다. - **데이터 구조를 신중하게 정의하십시오**. 구성 요소가 서로 전달하는 정보의 구조는 자유롭게 연결된 시스템을 관리하고 일관되게 유지하는 데 중요한 부분입니다. (이에 대한 자세한 내용은 [API 관리](/docs/architect/ko-kr/well-architected/guide/composable#api-관리)를 참조하십시오.) 메시지 또는 이벤트를 설계할 때 중요한 고려 사항은 정보 구조를 변경해야 하는 빈도입니다. 시스템에 메시지 또는 이벤트 구조가 정의되고 구현되면 특히 이벤트 또는 메시지를 이미 외부 시스템에 정보를 보내는 데 사용 중인 경우 업데이트를 처리하기가 어려울 수 있습니다. - **맞은 크기의 메시지** 일반적으로 메시지 크기를 작게 유지하는 것이 가장 좋습니다. 그러나 메시지 *크기*와 메시지 _볼륨_ 사이에도 균형을 맞춥니다. 시스템에서 더 작은 양의 데이터를 더 빠르게 처리할 수 있습니다. 처리 작업에는 수신자가 수신한 정보를 압축 해제하고 해석하고 수행할 작업을 결정해야 하므로 추가적인 비용이 포함됩니다. 이러한 단계는 완료하는 데 상당한 시간이 걸릴 수 있지만 대규모로 시스템을 구축하고 부담을 야기할 수 있습니다. 작업을 완료하기 위해 시스템의 구성 요소가 많은 작은 메시지를 연속으로 처리해야 하는 설계를 피하십시오. 메시지 크기를 올바르게 조정하려면 모든 다운스트림 구성 요소가 수많은 후속 메시지를 요청하거나 처리할 수 있다고 가정하지 않아도 전송된 정보를 성공적으로 처리하고 조치를 취해야 하는 최소 데이터 다운스트림 구성 요소를 설계할 수 있습니다. - 확장성을 위한 **설계** 완전히 결합된 구성 요소를 사용하면 보다 쉽게 아키텍처를 확장할 수 있습니다. 교차 구성 요소 종속성을 제거하면 팀이 개별 구성 요소의 성능 또는 확장성을 개선하고 다른 구성 요소에 미치는 영향을 최소화할 수 있습니다. 그러나 느슨하게 연결된 구성 요소는 아키텍처의 규모에 상당한 복잡성을 부여합니다(특히 [상태 관리](/docs/architect/ko-kr/well-architected/guide/composable#시도-관리)의 경우). 유효한 사용자 환경 또는 데이터 무결성 이유로 더욱 긴밀하게 연결된 논리 또는 종속성이 필요한 프로세스를 식별하고 해당 프로세스에 비동기식/이벤트 기반 패턴을 도입하지 마십시오. 대신 동기화/메시지 기반 패턴 및 올바른 오류 처리를 사용하십시오. 아래의 [ 패턴 및 안티 패턴](/docs/architect/ko-kr/well-architected/guide/composable#상호-운용성-패턴-및-안티-패턴) 목록은 Salesforce 솔루션 내에서 올바른(그리고 나쁜) 메시지 및 이벤트가 어떻게 보이는지 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템의 위치를 식별할 수 있습니다. Salesforce 메시징 및 이벤트 설정 도구에 대해 자세히 알아보려면 Composable과 관련된 [도구를 참조하십시오](/docs/architect/ko-kr/well-architected/guide/composable#구성-가능과-관련된-도구). 주어진 사용 사례에 대한 이벤트 패턴 또는 도구를 선택하는 방법에 대한 자세한 내용은 [Salesforce를 사용하는 이벤트 중심 아키텍처의 아키텍처 가이드](/docs/architect/ko-kr/decision-guides/guide/event-driven#key-takeaways)를 참조하십시오. ### API 관리 Salesforce 솔루션 내에서 적절한 응용 프로그램 프로그래밍 인터페이스(API) 관리를 구축하면 시스템의 개별 구성 요소가 예측 가능한 커뮤니케이션 패턴을 따를 수 있습니다. Salesforce는 Salesforce 외부 시스템과 통신하는 데 사용할 내장된 보안 API를 제공합니다. (Salesforce Platform API에 대한 자세한 내용은 [아키텍처 기본 사항](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#플랫폼-api)을 참조하십시오.) Salesforce 솔루션 내에서 효과적인 API 관리를 통해 구성 가능한 아키텍처를 구축할 수 있습니다. 이를 통해 Salesforce 조직 내 구성 요소가 효율적으로 정보를 전송하고 받을 수 있습니다. 또한 솔루션 빌더가 구축한 구성 요소가 시스템의 다른 구성 요소와 통신하는 방법에 대한 명확한 프로토콜을 따를 수 있으며, 조기에 불량한 구현을 식별할 수 있습니다. 또한 솔루션 빌더가 구축하거나 리팩터링 중인 특정 구성 요소에 집중할 수 있어 생산성과 품질이 향상됩니다. 엔터프라이즈 수준의 API 관리는 별도의 주제이며 포괄적인 API 관리 도구를 사용하면 가장 효과적입니다. (이 주제에 대한 MuleSoft 관점에 대한 자세한 내용은 [API 관리란 무엇입니까?](https://www.mulesoft.com/resources/api/what-is-api-management#:~:text=API%20management%20is%20the%20process,create%20are%20consumable%20and%20secure.)를 참조하십시오.) Salesforce 솔루션 내에서 API 관리 기능을 구축하려면 다음을 고려하십시오. - **API를 _예측 가능한_ 패턴 또는 커뮤니케이션 계약으로 생각하십시오**. 입력 또는 출력 변수의 데이터 유형, 변수 이름, 지정된 패턴에 표시되어야(또는 표시하지 않아야 함)하는 정보의 일부 - 이들은 효과적인 API 관리를 위한 키입니다. 해당 정의는 설계 표준에 표시되어야 하며, 팀은 문서를 통해 해당 정의가 시스템의 특정 부분에 구현된 방식을 확인할 수 있어야 합니다. 새 개발에서 통합 환경으로 변경 사항을 병합하는 어려움을 확인하는 한 가지 방법은 API 커뮤니케이션을 잘못 구현했거나 어떠한 API 정의도 없었는지 확인하는 것입니다. - **API에 대한 생각을 코딩 전용으로 제한하지 마십시오**. 이 컨텍스트에서 API를 정의하는 요소는 해당 메시지 내의 메시지 구조 및 변수의 일관성입니다. 일관성을 유지하는 한, API는 모듈식 자동 실행(또는 플랫폼 이벤트 트리거형) 플로 또는 플로 템플릿과 같은 선언적 사용자 정의뿐만 아니라 코드에서 구현할 수 있습니다. API 구현이 아니라 [패키지화 가능성](/docs/architect/ko-kr/well-architected/guide/composable#패키징-기능) 및 [테스트 가능성](/docs/architect/ko-kr/well-architected/guide/resilient#응용-프로그램-수명-주기-관리)에 따라 코드 대신 플로에서 정의할 사항을 결정합니다. - **수명 주기와 버전을 간단하게 유지하십시오**. 응용 프로그램 개발의 모든 부분과 마찬가지로 API에는 수명 주기인 정의, 구축, 테스트, 배포, 유지 관리(사용 중지 포함)가 있습니다. Salesforce Platform API는 플랫폼의 빠른 릴리스 주기 때문에 달력 연도 내에 여러 버전을 릴리스합니다. (Salesforce [아키텍처 기본 사항](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#플랫폼-api)에서 이 동작에 대해 자세히 알아볼 수 있습니다.) 따라서 Salesforce 고객이 특정 API의 여러 버전을 유지 관리하고 사용할 수 있어 플랫폼 API의 수명 주기가 상당히 복잡합니다. 이 수준의 복잡성은 PaaS 사용 사례에 적합하지만 플랫폼 내 솔루션 아키텍처에 불필요한 복잡성일 가능성이 높습니다(다음 참조: [읽기 안티 패턴](/docs/architect/ko-kr/well-architected/guide/intentional#가독성-패턴-및-안티-패턴)). API에 대한 명확한 목적(예: 오류 처리)과 명확한 기준선 정의를 정의하는 데 중점을 두십시오. 각 API의 버전을 하나만 보유하도록 합니다. - **API를 검색 가능, 액세스 가능, 관리 가능으로 만들기** 잠재 고객이 사용 가능한 API를 쉽게 찾을 수 있도록 [API를 문서화하십시오](/docs/architect/ko-kr/well-architected/guide/intentional#설계-표준). API는 [기능](/docs/architect/ko-kr/well-architected/guide/composable#기능-단위) 조화의 일환으로 원활하게 작동해야 합니다. - **반복적이세요**. 한 번에 하나의 내부 API만 정의하고 구현하는 데 중점을 두십시오. 이를 통해 API 정의를 빠르게 반복하고 지원되는 버전에 적합한 양식을 찾고 구현 경험에서 모범 사례를 수립할 수 있습니다.\_\_ 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/composable#상호-운용성-패턴-및-안티-패턴) 목록은 Salesforce 솔루션 내에서 올바르고 나쁜 API 관리를 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별할 수 있습니다. 더 많은 정보는 더 많은 상호 운용성을 구축할 수 있도록 Salesforce에서 사용할 수 있는 도구에 대해 알아보려면 Composable과 관련된 [도구를 참조하십시오](/docs/architect/ko-kr/well-architected/guide/composable#구성-가능과-관련된-도구). ### 상호 운용성 패턴 및 안티 패턴 다음 표는 조직에서 조회(또는 구축)할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/adaptable-interoperability)에서 상호 운용성을 위한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
메시징 및 이벤트 설계 기준:
- 동기 패턴(Messaging) 및 비동기 패턴(이벤트)을 사용할 시기에 대한 명확한 표준이 있습니다.
- 이벤트 및 메시지 구조에 대한 명확한 표준이 있습니다.
설계 기준:
- 설계 표준이 없거나 동기화 및 비동기 패턴에 대한 명확한 표준과 메시지 또는 이벤트 구조에 대한 명확한 표준이 부족합니다.
조직에서:
- 내부 시스템 메시징에 사용되는 플랫폼 이벤트 레이블이 명확하게 표시됩니다.
- Salesforce 플로 도구가 시스템 전체 Messaging 또는 이벤트 서비스를 참조합니다.
- 일관적인 Messaging 및 이벤트 패턴이 플로 및 코드에 표시됩니다.
조직에서:
- 내부 시스템 메시징에 사용되는 플랫폼 이벤트 레이블이 명확하지 않거나 존재하지 않습니다.
- 플로 및 코드에서 다양한 메시지 및 이벤트 패턴 전략이 표시됩니다.
Apex 또는 LWC에서:
- 사용자 정의 이벤트 정의 범위가 제한됩니다(코드에 정의된 시스템 전체 이벤트 또는 메시지 없음)
- Apex 시스템 전체 Messaging 또는 이벤트 서비스에 Salesforce 플로 도구에서 사용할 수 있는 방식으로 주석이 지정됩니다.
Apex 또는 LWC에서:
- 시스템 전체 메시지 및 / 또는 이벤트 구조는 Apex 또는 JavaScript로 정의됩니다.
- Apex 정의된 시스템 전체 이벤트 또는 메시지 구조는 플로와 같은 도구에서 사용할 수 없습니다.
API 관리 설계 기준:
- 교차 구성 요소 통신(즉, API)에 대한 명확한 프로토콜이 있습니다.
- 프로토콜/API는 빌더가 검색하고 찾을 수 있는 논리 그룹에 간략하게 표시됩니다.
- 프로토콜/API는 변수 데이터 유형, 변수 이름, 필수 또는 선택 사항을 정의하고 사용 시기에 대한 명확한 설명을 제공합니다.
설계 기준:
- 설계 표준이 없거나 API 및 사용 사례를 정의하지 않습니다.
문서:
- 모든 구성 요소의 문서에 구현된 API/커뮤니케이션 프로토콜이 명확하게 나열됩니다.
- 특정 API 또는 프로토콜을 검색하고 구현되는 구성 요소를 식별할 수 있습니다.
문서:
- 구성 요소 문서가 없음
- 구성 요소 문서에 구성 요소 내에서 구현된 API가 설명되어 있지만 API 정의가 표시되는 유일한 위치입니다.
- 특정 API 또는 프로토콜을 검색할 수 없으며/또는 검색 시 API 또는 프로토콜이 구현된 구성 요소를 식별하는 데 도움이 되지 않습니다.
조직에서:
- 사용자 정의 메타데이터 유형으로 내부 커뮤니케이션을 위한 API 메시지 형식 및 변수가 정의됩니다.
- 내부 커뮤니케이션을 위한 API 메시지 형식 및 변수가 플랫폼 이벤트와 함께 정의됩니다.
- 코드 및 선언적 사용자 정의는 정보를 보내거나 받기 위해 적절한 사용자 정의 메타데이터 유형(또는 플랫폼 이벤트)을 참조합니다.
조직에서:
- 시스템 구성 요소 간의 통신(코드 및 선언적 사용자 정의)은 임시입니다.
- API는 Salesforce와 외부 시스템 간 커뮤니케이션에만 정의됩니다.
## 패키징 기능 Salesforce 조직에서 패키지 가능성을 만들면 조직의 기능은 패키지로 독립적으로 신뢰할 수 있게 개발하고 배포할 수 있는 유닛에서 가져옵니다. 이상적으로 이러한 유닛은 [2세대](https://developer.salesforce.com/docs/atlas.en-us.218.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_plan_pkg_types.htm) 패키지의 유형으로 정의됩니다(잠금 해제 패키지 또는 ISV용 관리 패키지). 참고: 잘 설계된 솔루션은 해당 패키지 유형을 독점적으로 사용하므로 1세대 관리 패키지는 여기에 포함되지 않습니다. Salesforce 조직에서 [걱정 구분](/docs/architect/ko-kr/well-architected/guide/composable#우려-사항-분리)을 정의하고 기능 단위를 만드는 것은 한 가지입니다. 이러한 유닛을 패키지 아티팩트로 버전이 지정되도록 종속성을 명확하게 해제하고 관리하는 것이 좋습니다. 안정성과 메타데이터 격리 수준을 달성하려면 상당한 수준의 DevOps 및 아키텍처 성숙도가 필요합니다. 또한 개발 시간을 가속화하고 앱 빌더 환경을 개선하며 릴리스 및 릴리스 관리에 예측 가능성과 제어 기능을 제공합니다. 일부 조직에서는 효과적인 패키지를 정의, 유지 관리, 개발하는 데 필요한 인프라를 지원할 수 없습니다. 그러나 거의 모든 Salesforce 조직의 최종 목표는 패키지화 가능성을 달성해야 합니다. 확산된 커플링 및 종속성 관리에 집중하여 Salesforce 솔루션에서 패키징 가능성을 구축할 수 있습니다. ### 느슨한 커플링 결합이 해제된 시스템에서는 개별 부품이 서로 강하게 연결되지 않습니다. 구성 가능한 시스템의 많은 장점은 느슨한 커플링으로 인해 발생합니다. 패키지 가능한 시스템에서 패키지(및 설치 조직) 간에 느슨한 커플링을 구현하면 패키지에 대해 작업하는 팀에 대해 명확하게 정의된 패키지와 생산적인 개발 주기를 확보할 수 있습니다. Salesforce Platform에서 특정 조직에 [밀도로 연결된 패키지를 구축할 수 있습니다](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_org_dependent.htm). 이 기능은 기능 단위 정의와 패키징 성숙도 진행에 따라 조직에서 적절한 [문제 분리](/docs/architect/ko-kr/well-architected/guide/composable#우려-사항-분리) 실험에 유용합니다. 그러나 이 접근 방식을 선택하면 소스 중심 개발, 버전 관리 사용 기능, 아티팩트 안정성 등 진정한 패키지 가능 메타데이터의 이점이 거의 실현되지 않습니다. 대신 다음과 같은 긴밀하게 연결된 시스템의 단점을 계속해서 경험할 수 있습니다. - 중단 및 성능 문제를 야기하는 단일 지점 오류 - 예측할 수 없는 느린 배포 - 복잡하고 어려운 디버깅 및 문제 해결 주기 - [규모](/docs/architect/ko-kr/well-architected/guide/reliable#확장성) 및 [성능](/docs/architect/ko-kr/well-architected/guide/reliable#성능) 관련 문제 패키지 가능한 Salesforce 시스템의 최종 목표는 패키지에 흩어져 있는 패키지입니다. Salesforce 메타데이터를 효과적인 패키지로 분리할 때 다음 사항을 고려하십시오. - **사용자 정의는 데이터 대 메타데이터**입니다. 패키지화 가능성과 관련하여 Salesforce Platform은 데이터와 메타데이터를 매우 다르게 처리합니다. 조직에서 어떤 기능이 [메타데이터 또는 데이터인지](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#메타데이터와-데이터-비교) 이해하는 것이 중요합니다. 패키지된 단위에는 데이터를 포함할 수 없습니다. 패키지된 단위로 기능을 추출하기 시작할 위치를 결정할 때 팀은 데이터로 저장된 사용자 정의를 패키지에서 모두 제외해야 하는지 또는 메타데이터 기반 구현으로 재구성해야 하는지 결정해야 합니다. - **패키징이 팀에 미치는 영향** Salesforce 패키징의 물류 현실은 패키지 버전을 생성하고 릴리스하는 작업의 대부분이 Salesforce CLI 및/또는 CI/CD 기술을 숙지해야 한다는 것입니다. 즉, 하위 코드 및 프로그래밍 방식의 사용자 정의는 패키지 관련 DevOps 기술을 사용하여 작업할 수 있는 사람의 시간과 주의가 필요합니다. 팀이 기능 전달을 관리하는 방법에 따라 패키지 채택이 조직 전반의 여러 팀에 상당한 지연 또는 차단을 야기할 수 있습니다. 팀이 패키징을 통해 기능 전달을 관리할 수 있는지 확인하고 기술 또는 인력 부족을 해결할 계획을 수립해야 합니다. 솔루션에는 페어링된 프로그래밍 채택 또는 개발 환경용 CI/CD 작업 구현이 포함될 수 있습니다. - **패키징이 환경 전략을 어떻게 바꿀 것인가**. 패키지 기반 개발 수명 주기에서는 초기 작업을 [스크래치 조직](https://developer.salesforce.com/docs/atlas.en-us.238.0.sfdx_setup.meta/sfdx_setup/sfdx_setup_next_steps.htm?q=scratch%20org)에서 수행해야 합니다. 해당 임시 소스 중심 개발 환경을 사용하면 더 빠르고 반복적인 주기를 수행할 수 있습니다. 또한 개발 팀에 대한 보다 세분화된 환경 액세스 제어와 프로덕션과의 더 큰 격리도 지원합니다. 패키지에 Sandbox 또는 프로덕션 환경에만 존재하는 비패키지 메타데이터 또는 데이터에 대한 종속성이 많을수록 팀이 스크래치 조직을 실제로 사용할 가능성이 떨어집니다. 비스크래치 조직 환경에서 소스 기반 개발 패턴을 허용하기 위해 [Sandbox에서 소스 추적을 활성화할 수](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_source_tracking_sandboxes.htm) 있지만, 개발 팀은 스크래치 조직의 속도와 반복 속도를 활용할 수 없습니다. - **패키지 버전이 릴리스와 관련된 방법** 개발 패키지 버전을 지정해야 하는 빈도 및 단계를 계획합니다. 패키지 버전 요청은 24시간 순차적으로 조직당 제한됩니다. 일반적인 모범 사례로 패키지 내용을 변경할 필요가 없는 경우에만 패키지 버전을 지정합니다. 이상적으로 품질 보증 프로세스가 완료된 후 패키지 버전을 프로비저닝할 수 있습니다. 개발 팀이 패키지 만들기 요청의 성공 또는 실패를 얼마나 잘 패키지 경계를 정의했는지에 대한 "테스트"로 사용할 수 없습니다. 패키지 아티팩트의 버전을 지정하지 않고 이를 수행할 수 있는 방법이 있습니다. - 이상적인 최종 상태가 지원해야 하는 **것** 이상적인 패키징 전략은 빠르게 개발하고 배달할 수 있는 제어되고 안정적인 Salesforce 릴리스를 허용합니다. 조직 전체에서 너무 많은 패키지를 정의하면 개발 팀에 새로운 종류의 복잡성과 지체 지점을 야기할 수 있습니다. 조직이 과도하게 모듈화되면 릴리스가 느리고 어려울 수도 있습니다. 먼저 의미 있는 단일 패키지의 몇 가지 버전을 구축하고 릴리스합니다. 후속 패키지를 증분적으로 파생합니다. 비즈니스에 적합한 릴리스 케이던스가 있는 경우 패키지 도입을 중지합니다. 비즈니스 요구 사항이 변경되거나 릴리스 품질이 저하될 경우 시간에 따른 리팩터 패키지 이상적인 패키지 끝점은 주관적입니다. 패키지를 정의하는 방법에 상관없이 효과적인 [종속성 관리](/docs/architect/ko-kr/well-architected/guide/composable#종속성-관리)를 통해 해방된 패키지를 성공적으로 버전화할 수 있습니다. 아래의 [모형 및 안티모형](/docs/architect/ko-kr/well-architected/guide/composable#패키지-가능성-패턴-및-안티-패턴) 목록은 Salesforce 패키징의 올바른 (그리고 나쁜) 느슨한 커플링을 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별할 수 있습니다. Salesforce 도구에 대해 자세히 알아보려면 Composable과 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/composable#구성-가능과-관련된-도구)를 참조하십시오. ### 종속성 관리 Salesforce 솔루션의 컨텍스트에서 종속성 관리는 패키지의 메타데이터와 해당 패키지가 설치될 조직의 메타데이터 간 관계를 식별하고 구조화함을 의미합니다. 종속성 관리는 안정적인 패키지 아티팩트 개발의 핵심 부분입니다. 종속성은 완벽하게 분리되고 [연결하게 연결된](/docs/architect/ko-kr/well-architected/guide/composable#느슨한-커플링) 기능 단위를 만드는 노력과 상충될 수 있습니다. 이상적인 엔지니어링 상태에서 부드럽게 연결된 시스템에는 단위 간의 종속성이 없습니다. 그러나 실제에서는 모든 종속성을 제거하는 것이 실용적이지 않습니다. 종종 시스템을 [읽을 수 있음](/docs/architect/ko-kr/well-architected/guide/intentional#가독성)과 비즈니스 친화적인 [기능 유닛](/docs/architect/ko-kr/well-architected/guide/composable#기능-단위)을 사용하는 것 사이의 균형을 유지하려면 시스템의 모든 유닛을 완벽하게 격리해야 합니다. 보다 실용적인 측면에서 Salesforce Platform의 [표준 기능](/docs/architect/ko-kr/well-architected/guide/intentional#표준-기능과-사용자-정의-기능-비교)을 통해 제공되는 핵심 서비스는 모든 Salesforce 솔루션에 대한 핵심, 순 양성 종속성을 만듭니다. 많은 내장 확장성, 성능 및 보안 이점은 플랫폼에 얼마나 심층적으로 통합되어 있는지에 달려 있습니다. 패키지 가능한 Salesforce 솔루션을 설계할 때 패키지 종속성이 본질적으로 나쁜 것은 아닙니다. 부족한 종속성 관리 _는_ 나쁜 것입니다. Salesforce 패키징을 통한 효과적인 종속성 관리를 통해 개발 및 서비스 점검 팀이 다음을 수행할 수 있습니다. - 신규 프로젝트에 더 빠르게 온보딩하고 제한된 환경 액세스 - 신속한 변경 개발 및 테스트 - 작고 구체적인 서약에서 복잡한 기능을 어떻게 전달해야 하는지 이해 - 릴리스 케이던스 제어 및 시스템 서비스 점검/릴리스 중단 기간 줄이기 - 모든 환경에서 예측 가능한 롤백 불량 변경 사항 Salesforce를 통한 종속성 관리에 대한 기술은 매우 간단합니다. - [메시징 및 이벤트 매김](/docs/architect/ko-kr/well-architected/guide/composable#messaging-및-이벤트)을 사용하여 구성 요소 간에 상태가 있는 정보 또는 상태가 없는 정보의 편리한 전달을 처리합니다. - 사용자 정의 메타데이터 유형을 사용하여 동적 런타임 정보를 제공하고 종속성 삽입 패턴을 지원합니다. - Apex 개발자가 [추상 또는 가상 클래스를](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_extending.htm) 사용하도록 합니다. 마지막으로 선언적 및 프로그램 방식 개발 전반에서 조직에서 허용되는 설계 패턴을 결정해야 합니다. 가장 중요한 고려 사항(아키텍처상)은 종속성을 줄이기 위해 더 많은 엔지니어링 복잡성을 추가할 위치와 앱 빌더 워크플로를 간소화하기 위해 더 많은 종속성을 허용해야 하는 위치를 정의하는 것입니다. 패키지에 종속성 관리 전략을 구축할 때 패키지 단위의 두 가지 기본 구성 원칙인 가로 및 세로를 고려하십시오. - **수평 경계** 가로 패러다임에서 둘 이상의 패키지에 필요한 기능은 가로 레이어로 추상화됩니다. 그러면 가로 레이어가 공통 기능의 소스가 되고 선언된 종속성을 통해 액세스됩니다. 패키지 전반의 중복 기능을 최소화하는 것이 종속성 최소화보다 더 좋습니다. - **수직 경계** 세로 패러다임은 시스템 부품 간의 격리 및 릴리스 커플링을 극대화합니다. 공유 기능은 제한되며 유사한 작업이 단위 전체에 표시될 수 있습니다. 패키지 단위 간의 격리를 극대화하기 위해 종속성이 엄격하게 제한됩니다. 이는 두 가지 중 하나의 결정이 아닙니다. 필요에 따라 세로 및 가로 패러다임을 혼합할 수 있습니다. 패키지를 시작하는 가장 빠른 방법은 가로 서비스 계층을 만드는 것입니다. 패키지 채택의 규모와 복잡성이 증가함에 따라 더 많은 세로 단위를 추상하면 복잡한 환경 설정 프로세스 또는 개발자 온보딩을 간소화하는 데 도움이 됩니다. 예를 들어 두 개의 기능 단위(A 및 B)가 있는 시스템은 세로, 가로, 세로 가로 하이브리드 패러다임으로 정렬된 패키지 종속성을 사용하여 구조화할 수 있습니다. 이것은 두 개의 패키지를 보여주는 다이어그램입니다. A 및 B는 공유 종속성(수직 조각)이 없도록 구축되었으며, 여러 가지 공통 서비스(수평)와 각각의 혼합(하이브리드)를 갖도록 구축되었습니다. 선택한 패키지 구성 패러다임과 상관없이 유의해야 할 몇 가지 절대어가 있습니다. - 패키지 간에 메타데이터를 **복제하지 마십시오**. 둘 이상의 패키지에 필요한 메타데이터는 종속으로 선언되는 하나 이상의 패키지로 추상화해야 합니다. - Salesforce Platform 메타데이터의 내장 종속성을 **사용합니다**. 앱 빌더의 경우 Salesforce Platform에서 제공하는 내장형 서비스는 빠르게 구성할 수 있는 광범위한 기능을 제공합니다. 많은 서비스에 내장 종속성이 있으므로 하위 수준 기능 단위로 추상화하기가 어렵습니다. 지정된 메타데이터 유형의 경우 [내장 종속성](https://developer.salesforce.com/blogs/2018/06/lets-talk-deployment-and-reasons-why-they-succeed-or-fail) 스펙트럼에 따라 해당 유형이 어디에 속하는지 이해하고 이 이해를 사용하여 패키지 종속성 체인을 [정의해야 합니다](https://developer.salesforce.com/blogs/2018/06/working-with-modular-development-and-unlocked-packages-part-2). 내장 종속성이 많은 표준 플랫폼 기능에 느슨한 커플링을 강제 적용하여 패키지 채택을 시작하지 마십시오. 더 높은 순위의 성능에 도달하면 값이 아닌 복잡성이 추가됩니다. 또한 [표준 vs. 사용자 정의](/docs/architect/ko-kr/well-architected/guide/intentional#표준-기능과-사용자-정의-기능-비교) [안티 패턴](/docs/architect/ko-kr/well-architected/guide/intentional#서비스-점검-패턴-및-안티-패턴)에 빠지는 또 다른 방법입니다. 하단(최소 종속성)에서 메타데이터를 위로 패키징하고 시간에 따라 반복합니다. - **자식 체인 조심해** 개발자가 한 번에 여러 가지 다른 패키지로 변경 사항을 분할해야 하는 패키지 종속성 체인을 만들지 마십시오. - **소스 제어에 대한 의미가 무엇인지 생각해보세요**. 소스 제어에서 패키지를 관리하는 두 가지 기본 방법이 있습니다. 첫 번째는 폴더 내에서 격리된 패키지와 함께 단일 *모노레포*입니다. 두 번째는 자체 리포지토리에 분리된 패키지가 있는 여러 리포지토리입니다. 각 유형의 소스 전략을 장기간 관리하는 데는 복잡성이 있습니다. 개발자 온보딩 측면에서 수직 경계는 여러 리포지토리 패러다임에서 더욱 효율적입니다. 모노레포에서는 가로 경계를 더 이해할 수 있습니다. 다시 말해 아키텍처가 성숙해질 때 전략을 혼합하고 일치시킬 수 있습니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/composable#패키지-가능성-패턴-및-안티-패턴) 목록은 Salesforce 패키지에서 올바른(그리고 나쁜) 종속성 관리가 어떻게 보이는지 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별할 수 있습니다. 종속성 관리용 Salesforce 도구에 대해 자세히 알아보려면 구성 가능과 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/composable#구성-가능과-관련된-도구)를 참조하십시오. ### 패키지 가능성 패턴 및 안티 패턴 다음 표는 조직에서 조회(또는 구축)할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/adaptable-packageability)에서 더 많은 패턴을 찾으세요.
패턴 안티 패턴
루즈 커플링 설계 기준:
- 패키지 단위를 지정하는 방법을 설명하는 명명 규칙
- 현재 정의된 모든 패키지 단위(및 관련 명명 규칙) 목록을 검색하고 찾을 수 있습니다.
- 패키지 단위 추가 또는 변경 사항을 제안하기 위한 표준이 있습니다.
- (옵션) 사용자 정의 설정에 대해 승인된 모든 사용 사례가 명확하게 나열됩니다(있는 경우).
설계 기준:
- 설계 표준이 없거나 패키지 단위 및 사용 사례를 처리하지 않습니다.
조직에서:
- 사용자 정의 메타데이터 유형은 코드 및 선언적 사용자 정의에 대한 동적 런타임 정보를 제공합니다.
- 사용자 정의 설정이 없거나 사용자 정의 설정이 거의 없으며, 패키지 기능과 관련된 설정이 없습니다.
- 코드 또는 선언적 사용자 정의에 대한 동적 런타임 정보를 제공하기 위해 사용자 정의 개체가 없는 경우
조직에서:
- 사용자 정의 설정이 사용됩니다.
- 코드 또는 선언적 사용자 정의에 대한 동적 런타임 정보를 제공하기 위해 사용자 정의 개체가 존재합니다.
- 코드 및 선언적 사용자 정의에 대한 동적 런타임 정보를 제공하기 위해 사용자 정의 메타데이터 유형이 사용되지 않거나 일관적으로 사용되지 않습니다.
Apex:
- 일반 서비스와 보일러플릿 코드는 추상적 또는 가상 Apex 클래스를 사용하여 정의됩니다.
- 동적 런타임 정보에 종속되는 메서드는 적절한 사용자 정의 메타데이터 유형을 참조합니다.
Apex:
- 일반 서비스 및 보일러플레이트 코드를 다른 클래스와 쉽게 구분할 수 없습니다.
- 클래스 및 메서드 전반의 내부 참조는 따르기 어려우며 코드베이스 전체에서 일관되지 않습니다.
- 메서드에서 동적, 런타임 정보에 액세스하는 일관된 접근 방식을 사용하지 않거나 런타임 동작 정보에 대한 사용자 정의 개체를 쿼리하거나 코드가 사용자 정의 설정을 참조하지 않습니다.
소스 제어 및 개발 환경에서:
- package.xml 파일은 조기 단계 또는 개념 증명 프로젝트 매니페스트에만 표시됩니다.
소스 제어 및 개발 환경에서:
- package.xml 파일은 메타데이터 배포 제어에 사용됩니다.
포장:
- 조직에 종속된 잠금 해제 패키지는 조기 단계 또는 개념 증명 실험에만 사용됩니다.
- 프로덕션 또는 Sandbox에 비관리 패키지가 정의되지 않았습니다.
포장:
- 모든 패키지는 조직에 종속된 잠금 해제 패키지입니다.
- 비관리 패키지가 프로덕션 또는 Sandbox에 정의되어 있습니다.
종속성 관리 설계 기준:
- 종속성 선언 표준이 있는 경우
- 종속성 도입 또는 수정 표준이 있는 경우
설계 기준:
- 설계 표준이 없거나 종속성 선언 방법을 다루지 않습니다.
소스 제어:
- 잠금 해제된 패키지의 패키지 버전은 별칭(최신)을 사용하여 sfdx-project.json 매니페스트에서 종속성을 선언합니다.
- 개발자는 스크래치 조직을 만들고 소스 제어에서 패키지 메타데이터를 성공적으로 배포할 수 있습니다.
소스 제어:
- 잠금 해제된 패키지의 패키지 버전은 sfdx-project.json 매니페스트에서 명시적으로 선언됩니다(최신 별칭 없음).
- 개발자가 소스 제어를 사용하여 스크래치 조직에서 성공적으로 작업할 수 없음
패키지에:
- 패키지 전체에서 메타데이터가 중복되지 않음
- 패키지 개발의 경우 모든 조기 개발 작업이 스크래치 조직에서 수행됩니다.
패키지에:
- 다른 패키지에서 메타데이터를 복제하여 종속성을 무시합니다.
- 개발자 Sandbox에서 조기 패키지 개발이 발생하거나 스크래치 조직에서 조기 패키지 개발이 발생할 수 없습니다.
참조: 루즈 커플링
## 구성 가능과 관련된 도구
도구설명우려 사항 분리상호 운용성패키징 기능
Apex REST 웹 서비스REST를 통해 외부 애플리케이션에 Apex 클래스 및 방법 노출X
Apex SOAP 웹 서비스SOAP를 통해 외부 애플리케이션에 Apex 클래스 및 방법 노출X
변경 데이터 수집Salesforce 레코드에 변경 사항 게시X
사용자 정의 메타데이터 유형재사용 가능, 사용자 정의 가능, 패키지 가능 기능 정의X
디코레이터API로 기능 또는 속성을 공개적으로 표시XX
Dev Hub스크래치 조직, 2세대 패키지 및 Einstein 기능을 관리합니다.XXX
일반 이벤트 (레거시)*Salesforce 데이터 변경 사항과 연결되지 않은 사용자 정의 이벤트 보내기X
Lightning 데이터 서비스구성 요소 간 데이터 캐시 및 공유XX
Metadata APISalesforce 환경 간에 사용자 정의 배포X
메타데이터 적용 범위 보고서여러 채널에서 지원되는 메타데이터 적용 범위 결정 X
MuleSoft 작성기코드 대신 클릭으로 데이터에 대한 프로세스 자동화 구축X
아웃바운드 메시지필드 값이 업데이트되면 외부 끝점에 메시지 보내기X
플랫폼 이벤트 실시간 이벤트 데이터를 포함하는 안전하고 확장 가능한 메시지 보내기X
Pub/Sub API플랫폼 이벤트 구독, 변경 데이터 수집 또는 실시간 이벤트 모니터링X
PushTopic 이벤트 (레거시)*사용자 정의 SOQL 쿼리에 일치하는 변경 사항 알림 보내기 및 수신X
Salesforce CLISalesforce 조직과 작업할 때 자동화 개발 및 구축X
Salesforce 다이어그램비즈니스 기능 및 기술 세부 사항을 표시하는 다이어그램 만들기X
Visual Studio 코드용 Salesforce 확장 프로그램(확장)Salesforce 개발을 위한 공식 VS 코드 확장X
스크래치 조직폐기 가능한 조직에 Salesforce 코드 및 메타데이터 배포X
2세대 관리형 패키지AppExchange 앱 개발 및 배포X
툴링 APILightning Platform 애플리케이션용 맞춤형 개발 도구 또는 앱 구축X
잠금 해제 패키지메타데이터 구성, 앱 패키징 또는 AppExchange 앱 확장X
*Salesforce는 현재 기능 기능 내에서 계속해서 PushTopic 및 일반 이벤트를 지원하지만 이 기술에 추가 투자를 계획하지는 않습니다.
## 구성 가능과 관련된 자원
자원설명우려 사항 분리상호 운용성패키징 기능
디지털 통합의 원시적 관점연결 개념에 대한 공통 언어 개발X
Salesforce로 도메인 기반 설계 적용비즈니스 역량에 맞춰 솔루션 지향X
2세대 패키지의 모범 사례2GP 패키징 패턴 및 사례 이해X
관리 패키지에서 사용 가능한 구성 요소관리 패키지 메타데이터 구성 요소 이해X
설계 표준 템플릿조직에 대한 설계 표준 만들기XXX
이벤트 중심 아키텍처 결정 가이드이벤트 중심 아키텍처 패턴 및 도구 비교X
이벤트 안티 패턴이벤트 사용 시 피할 안티 패턴 식별X
메시지 기반 및 이벤트 기반 API 설계 방법MuleSoft 개발 가이드의 차이점을 자세히 살펴봅니다.XX
실행할 작업 프레임워크에 대해 알아보기Trailhead JTBD 살펴보기X
B2C Commerce의 글로벌 상태 관리구성 요소 간에 데이터를 쉽게 전달하여 상태 유지X
Messaging 지침관련 정보를 전달하고 기쁨의 순간을 만듭니다.X
Messaging 유형사용자 상호 작용의 특성에 따라 다양한 Messaging 유형 이해X
메타데이터 유형Salesforce 조직의 다양한 유형의 메타데이터 이해XX
모바일 앱 알림 유형Salesforce 모바일 앱의 알림 유형 이해X
보기 상태 최적화Visualforce 페이지의 상태 유지X
Salesforce 개발자 경험(DX)Lightning Platform에서 앱 관리 및 개발XXX
지원되지 않는 메타데이터 유형메타데이터 API에서 사용할 수 없는 구성 요소 식별X
## 의견을 알려주십시오. Salesforce Well-Architected의 관련성을 유지할 수 있도록 도와주십시오. 이 콘텐츠에 대한 사용자 의견을 제공하려면 [ 설문 조사](https://sfdc.co/bxNtvh)을 작성하고 다음에 표시할 내용을 알려주십시오. > [여기에](/docs/architect/ko-kr/well-architected/guide/contributors) 업데이트 일정에 대해 알아보십시오. ## 소개 복원성 있는 솔루션은 오류가 발생한 경우에도 서비스 품질을 유지합니다. 성능이 저하되거나 서비스가 중단되면 솔루션이 빠르고 효과적으로 복구됩니다. 솔루션의 복원성은 다음의 두 가지 핵심 특성에 기반합니다. - **경도**: 문제가 발생하면 솔루션이 이를 견뎌내고 유지합니다. - **연성**: 문제를 해결하면 솔루션이 이상적인 상태 또는 모양으로 돌아갑니다. 복원성을 위한 솔루션을 설계하려면 견고함과 탄력을 모두 고려하여 계획된 변경 사항과 계획되지 않은 변경 사항에 맞춰 내구성과 신속한 복구를 보장해야 합니다. 기술 컨텍스트에서 시스템 또는 솔루션을 공유 목표를 수행하기 위해 조율하는 상호 종속적인 구성 요소의 모음으로 간주합니다. 모든 구성 요소는 실패할 수 있습니다. 코드 및 구성 결함에서 네트워크 및 하드웨어 문제에 이르기까지 해당 구성 요소 내의 문제로 인해 예기치 않은 원치 않는 동작이 발생할 수 있습니다. 하나 이상의 구성 요소가 실패할 경우 시스템이 복원적 동작을 보여주지만 전체 시스템이 계속 작동하거나 빠르게 안정된 상태로 돌아갑니다. Salesforce 솔루션의 복원 능력을 향상하려면 세 가지 핵심 습관에 집중하는 것이 좋습니다. - [**어플리케이션 수명 주기 관리(ALM)**](/docs/architect/ko-kr/well-architected/guide/resilient#응용-프로그램-수명-주기-관리) \- 팀이 소프트웨어 수명 주기 전반에 걸쳐 소프트웨어를 관리하는 방식 - [**사고 대응**](/docs/architect/ko-kr/well-architected/guide/resilient#사고-대응)—팀이 시스템의 가용성 또는 보안에 영향을 미치는 문제를 식별, 해결 및 방지하는 방법 - [**계속 계획**](/docs/architect/ko-kr/well-architected/guide/resilient#연속성-계획)—계획되지 않은 이벤트로 인해 문제가 발생할 경우 팀이 직원과 시스템을 계속 작동하도록 계획하는 방법 ## 응용 프로그램 수명 주기 관리 응용 프로그램 수명 주기 관리(ALM)는 생성에서 사용 중지까지 수명 주기 전반에 걸쳐 소프트웨어를 종합적으로 관리하는 방법입니다. ALM은 시스템 복원의 핵심이며 응용 프로그램 수명 주기와 관련된 사람, 프로세스, 도구, 분야를 포괄합니다. 해당 분야에는 DevOps 및 전달 방법론, 관찰 가능성, 테스트 전략, 거버넌스, CI/CD가 포함됩니다. 비즈니스에서 효과적인 ALM을 사용하면 팀이 변경 사항에 신속하게 대응하고 응용 프로그램이 안정성이나 품질을 저하하지 않고 변화하는 비즈니스 요구 사항을 준수합니다. 반면, 정상적인 ALM이 없으면 팀은 응용 프로그램 수명 주기의 모든 단계에서 어려움을 겪습니다. 낮은 ALM의 증상은 다음과 같습니다. - 느리고 오류가 발생하기 쉬운 개발 주기 - 집약적이고 어려운 배포 - 프로덕션 및 QA 후 환경에서 발견된 심각도가 높은 문제 또는 버그 - 환영하거나 일관되지 않게 동작하는 AI 에이전트 - 릴리스 안정화에 필요한 자주 롤백 또는 핫픽스 배포 ALM은 솔루션의 거의 모든 측면을 다루므로 솔루션에 대한 명확하고 효과적인 ALM 관행을 수립하는 것은 아키텍처 작업의 핵심 부분입니다. 세 가지 핵심 영역에 집중하여 더 나은 ALM 관행을 구축합니다. - [**릴리스 관리**](/docs/architect/ko-kr/well-architected/guide/resilient#릴리스-관리)—변경을 다른 환경으로 계획, 순서, 제어 및 마이그레이션 - [**환경 전략**](/docs/architect/ko-kr/well-architected/guide/resilient#환경-전략) — 개발 및 테스트 시 목표 환경에서 애플리케이션을 사용하고 관리하는 방법에 대한 전략 - [**신호화 전략**](/docs/architect/ko-kr/well-architected/guide/resilient#신호-전략) — 저하가 발생하기 전에 시스템 내 장애를 감지하고 해결하는 데 사용되는 중요 신호 및 응용 기기 정의 - [**테스트 전략**](/docs/architect/ko-kr/well-architected/guide/resilient#테스트-전략) \- ALM 프로세스 중 애플리케이션의 성공을 측정하기 위해 테스트를 계획하고 실행하는 방법을 안내하는 원칙과 기준 ### 릴리스 관리 릴리스 관리에는 변경 사항을 계획, 순서, 제어, 하나 이상의 환경으로 마이그레이션하는 작업이 수반됩니다. 단일 릴리스는 팀이 동시에 대상 환경으로 이동하는 계획된 변경 사항의 그룹입니다. 시스템에 대한 변경 사항을 릴리스하면 위험이 발생합니다. 변경 전에 시스템이 안정적인 상태인 경우 새 상태로 전환되며, 이후 변경으로 인한 위험에 더욱 취약해집니다. 향후 변경 사항이 시스템에서 비제어적이고 불안정한 상태를 트리거할 경우 심각한 사고가 발생할 수 있습니다. 솔루션 아키텍처에서 탄력적인 릴리스를 위해 설계하는 것은 단순히 [개별 변경 사항을 효과적으로 테스트하는 것](/docs/architect/ko-kr/well-architected/guide/resilient#테스트-전략) 이상입니다. 또한 시스템 및 사용자에게 안전하게 변경 사항을 도입하는 방법을 계획해야 합니다. 팀이 수행하는 작업은 예측 가능하고 정확한 릴리스 정보에 따라 다릅니다. 변경 관리 및 활성화 프로세스에서 시스템으로 이동할 수 있는 변경 사항을 명확하게 확인하십시오. 릴리스 관리 및 활성화 프로세스에서 변경 사항이 시스템에 릴리스되는 방법 및 빈도를 지정합니다. 비즈니스 이해당사자는 특히 릴리스 정보가 요청한 기능 또는 버그 수정과 관련이 있는 경우 릴리스 정보를 신경쓰기도 합니다. 솔루션에 대한 Trust 구축하고 이해당사자에게 가치를 표시하려면 일관되고 명확한 릴리스 일정을 설정하고 안정적인 릴리스 아티팩트를 배포합니다. Salesforce에 대한 효과적인 릴리스 관리 설정: - **건축 및 개발 거버넌스와 긴밀하게 일치**합니다. 모든 관련 거버넌스 포럼 및 제어에 부합하도록 미리 릴리스를 계획해야 합니다. 개발을 시작하기 전에 우선 순위가 지정된 Agentforce 사용 사례를 모두 검토하고 AI 위원회에 승인하십시오. 법적 및 윤리적 사용 팀에서 높은 위험이 있는 Agentforce 사용 사례를 검토합니다.배포 체크리스트 및 문서를 사용하여 Agentforce 에이전트 API 이름과 같은 배포 아티팩트를 관리 활동에 대해 추적합니다. - **[조직 기반 개발 또는 릴리스 프로세스를 사용하지 마십시오](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)**. 이 패러다임은 개발 및 릴리스를 위한 오래된 제한된 기술을 반영합니다. 이제 팀은 Salesforce CLI 사용하여 소스 중심 개발 및 릴리스 기능을 채택할 수 있습니다. - **가능한 가장 안정적인 릴리스 메커니즘을 선택하십시오**. 이 접근 방식은 다음 두 가지를 수행합니다. 먼저, 릴리스 기간 및 서비스 중단 기간을 최소화합니다. 두 번째로, 매우 제어적이고 예측 가능한 릴리스 동작을 허용합니다. 릴리스 메커니즘이 안정적일수록 릴리스에서 핫픽스 또는 롤백이 필요한 변경 사항을 도입할 가능성이 줄어듭니다. 예상치 못한 문제가 발생할 경우 안정적인 릴리스 메커니즘은 지원 담당자 또는 시스템 관리자가 롤백을 수행할 수 있는 간단한 방법도 제공합니다. 팀에 가장 적합한 릴리스 메커니즘은 팀에 필요한 기술이 있는 가장 안정적인 옵션입니다. 다음은 안정성 순서대로 나열된 권장 릴리스 메커니즘입니다. 모든 항목이 서로 호환되므로 회사에 가장 적합한 경우 여러 항목을 동시에 사용하십시오. - [**잠금 해제 패키지**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm)—잠금 해제 패키지는 가장 안정적인 릴리즈 아티팩트입니다. 패키지를 설치하여 변경 사항을 배포하는 것이 가장 빠르고 예측 가능한 방법입니다. 패키지는 버전 관리를 사용하므로 강력한 변경 관리와 시스템 관리자에게 친숙한 세분화된 롤백을 수행할 수 있습니다. 패키지에는 강력한 메타데이터 관리가 필요하므로 조기에 잘못 관리되는 종속성을 식별할 수 있습니다. 또한 감사 가능한 개발 파이프라인 및 아티팩트를 만듭니다. [패키지 가능성](/docs/architect/ko-kr/well-architected/guide/composable#패키징-기능)을 참조하십시오. - [**DevOps Center**](https://help.salesforce.com/s/articleView?id=sf.devops_center_overview.htm&type=5)—DevOps Center를 사용하면 소스 제어를 사용하고, 변경 사항에 대한 공동 작업을 수행하고, 공통 릴리스 경로를 정의할 수 있는 낮은 코드 또는 프로 코드 기술을 갖춘 전달 팀이 가능합니다. DevOps Center 소스 제어와 통합되며 변경 사항 및 배포를 포인트 앤 클릭으로 제어할 수 있습니다. - **소스 중심 개발 및 메타데이터 배포([Salesforce CLI](https://developer.salesforce.com/tools/sfdxcli)** 사용) - 패키지를 사용할 수 없는 경우 Salesforce CLI를 사용하여 소스 중심 개발 및 메타데이터 배포를 수행합니다. 권장되는 [소스 형식](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm)과 다른 구조를 따르는 오래된 package.xml 형식을 사용하여 메타데이터를 배포하지 마십시오. 소스 형식은 Sandbox에서 패키지 개발, 스크래치 조직 워크플로, 보다 세분화된 변경 추적을 지원하기 위해 진화되었습니다. 형식은 더욱 쉽게 읽을 수 있으며 복잡한 메타데이터 유형 및 종속성을 더 잘 분리할 수 있으며 배포 매니페스트를 훨씬 더 세밀하게 제어할 수 있습니다. - **릴리즈 이름을 지정하십시오**. 릴리스에 명확한 식별자를 제공하여 팀과 이해당사자가 조율을 유지할 수 있도록 지원합니다. Salesforce에서는 각 주요 릴리스의 이름이 "Spring", "Summer" 또는 "Winter"로 시작하고 그 뒤에 릴리스 연도(예: "Summer '25")가 표시됩니다. 아직 회사에서 릴리스를 정의하고 구성하기 위한 명명 규칙이 없는 경우 명명 규칙을 설정하고 사용합니다. 명확한 릴리스 이름을 사용하면 팀 시스템 전반에서 계획, 개발, 배달의 모든 단계에서 체계적으로 정리할 수 있습니다. [로드맵](/docs/architect/ko-kr/well-architected/guide/intentional#로드맵)에서 릴리스 이름을 사용하여 이해당사자에게 예정된 변경 사항 및 시기를 명확하게 전달합니다. 개발 아티팩트를 쉽게 추적하고 감사할 수 있도록 문서, 변경 로그, 작업 설명, 코드 댓글 및 소스 제어 분기에서 릴리스 이름을 사용합니다. - **릴리스 매니페스트 내에서 종속성을 제대로 관리하십시오**. Salesforce 메타데이터에는 내장 종속성이 있습니다. Salesforce 배포가 실패하는 일반적인 이유는 종속성이 제대로 관리되지 않기 때문입니다. 앞서 설명한 것처럼 안정적인 릴리스 메커니즘을 선택하면 개발 주기 초기에 잘못 관리되는 종속성을 노출하는 데 도움이 됩니다. 잠금 해제 패키지가 가장 안정적인 릴리스 차량인 이유 중 하나는 패키지 개발 및 생성에 필요한 강력한 메타데이터 관리입니다. 사용자 또는 릴리스 관리 팀에서 Salesforce 메타데이터 유형 간의 내장 종속성을 이해하지 못할 경우 배포 및 릴리스 매니페스트에서 문제 조합을 사전에 파악할 수 없습니다. [부양 관리](/docs/architect/ko-kr/well-architected/guide/composable#종속성-관리)를 참조하십시오. [ALM의 패턴과 안티 패턴](/docs/architect/ko-kr/well-architected/guide/resilient#alm-패턴-및-안티-패턴)은 Salesforce 조직의 올바른 릴리스 관리와 나쁜 릴리스 관리를 보여줍니다. 패턴을 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템의 위치를 식별합니다. 릴리스 관리용 Salesforce 도구에 대해 자세히 알아보려면 [Salesforce Resiliency 도구](/docs/architect/ko-kr/well-architected/guide/resilient#복구용-salesforce-도구)를 참조하십시오. ### 환경 전략 Salesforce는 애플리케이션 개발 및 테스트 주기 동안 사용할 수 있는 다양한 [환경](https://help.salesforce.com/s/articleView?id=sf.create_test_instance.htm&type=5)을 제공합니다. Salesforce의 효과적인 환경 전략을 수행하려면 환경을 사용하는 방법과 효과적인 관리 방식을 이해해야 합니다. ALM에서 개발 또는 테스트 환경의 유용성은 충성도와 프로덕션과의 분리에 따라 다릅니다. 좋은 환경 전략은 몇 가지 이점을 제공합니다. - 프로덕션에 대한 충성도 향상 - 더 빠른 환경 설정 및 테어다운 - 개발 및 테스트에 대한 민첩성 향상 - 파이프라인 전반의 보안 향상 - 배달 단계 전반에서 소음 및 충돌 감소 - 행복한 개발 팀 팀은 이러한 혜택을 실현하기 위해 어려움을 겪는 경우가 많습니다. 개발 환경 및 전략을 최대한 활용하기 위한 문제는 여러 소스에서 발생할 수 있습니다. 한 가지 가능한 소스는 팀이 따르는 개발 모델 유형입니다. 오래된 조직 기반 개발 접근 방식에서는 각 환경이 여러 기능을 제공해야 했습니다. 팀이 다양한 작업을 수행하는 곳 외에도 릴리스 아티팩트(릴리스에서 배포하려는 메타데이터)의 소스여야 했습니다. 환경을 쉽게 설정하거나 해제할 수 없었기 때문에 팀 간의 메타데이터 충돌이 지나치게 많았으며 전체적으로 ALM에 의미 있는 속도 또는 유연성을 제공하지 않습니다. 소스 기반 개발 모델을 사용하면 릴리스 및 릴리스 아티팩트에 대한 환경 관계가 근본적으로 변경됩니다. 이 모델에서 소스 제어는 릴리스할 메타데이터의 소스입니다. 환경은 팀이 작업을 수행하는 장소입니다. 그러나 소스 기반 개발 모델을 따르는 것은 좋은 환경 전략을 보장하는 것뿐만이 아닙니다. 소스 제어를 사용하더라도 팀은 외부 시스템과의 통합을 테스트하기 위해 조건을 설정하는 데 어려움을 겪을 수 있습니다. 관리 패키지 또는 [데이터](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#메타데이터와-데이터-비교)에 의존하는 사용자 정의 등 소스 제어에 속하지 않는 메타데이터에 의존하는 구성. 특정 상황에서 소스 기반 모델의 챌린지는 조직 기반 모델의 일반적인 챌린지와 유사합니다. 효과적인 환경 전략 개발: - **소스 중심 개발 및 릴리즈 모델 채택** [조직 기반 개발](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models) 모델 사용 중지 [릴리스 관리](/docs/architect/ko-kr/well-architected/guide/resilient#릴리스-관리)를 참조하십시오.) 건강한 환경 전략 및 더 건강한 릴리스를 만들려면 배포하는 환경의 문제를 해제해야 합니다. - 각 환경이 지원하는 작업 유형을 ** 이해합니다**. Salesforce에서 지원하는 환경 유형에는 기능 및 제한이 다릅니다. 환경 전략을 설계할 때 환경에서 수행할 수 있는 작업과 수행할 수 없는 작업을 고려하십시오. 팀이 필요한 기능이 있는 환경에서 작업을 수행해야 합니다. 지침은 Salesforce 개발 환경 및 해당 기능에 대한 이 개요를 참조하십시오.
스크래치 조직 Developer Sandbox Developer Pro Sandbox 부분 복사 Sandbox 전체 Sandbox
조직 형태 지원 예 아니요 아니요 아니요 아니요
소스 추적 지원 예 예 예 아니요 아니요
수명 1~30일 수동 제어 수동 제어 수동 제어 수동 제어
새로 고침 간격 사용할 수 없음 1일 1일 5일 29일
릴리스 미리 보기 지원 개발자 제어 Sandbox 인스턴스 기반 Sandbox 인스턴스 기반 Sandbox 인스턴스 기반 Sandbox 인스턴스 기반
프로비저닝 시간 >5분 시간 또는 일수 시간 또는 일수 시간 또는 일수 시간 또는 일수
Metadata Determined By 소스 제어 프로덕션 프로덕션 프로덕션 프로덕션
결정한 데이터 수동 데이터 로드 수동 데이터 로드 수동 데이터 로드 Sandbox 템플릿 프로덕션
데이터 한도 200MB 200MB 1GB 5GB 프로덕션과 동일
이 표를 참조하여 몇 가지 일반적인 개발 과업에 사용할 기능 및 환경을 알아보십시오.
과업 조직 형태 소스 추적 자주 새로 고침 릴리스 미리 보기 지원 프로덕션의 모든 메타데이터 프로덕션의 부분 메타데이터 프로덕션의 대규모 데이터 집합 프로덕션의 일부 데이터 집합 호환 가능한 환경
프로토타이핑 X X X X X X X 스크래치 조직, Developer 및 Developer Pro Sandbox
새 기능 조사 또는 개념 증명 개발 X X X X X X X 스크래치 조직, Developer 및 Developer Pro Sandbox
사용자 수용 테스트 X X X X X X Developer, Developer Pro 및 부분 복사 Sandbox
성능 및 규모 테스트 X X X 전체 Sandbox
사용자 교육 X X X X X* X Developer Pro, 부분 복사 및*Full Sandbox
*특정 유형의 작업을 완료해야 하는 경우 리소스 집약도가 적은 환경을 사용합니다.
또한 Einstein 데이터 라이브러리, Knowledge 기사 및 비정형 데이터와 같은 기능을 사용하는 Agentforce 에이전트의 경우 Data 360 Sandbox가 없으면 포괄적인 테스트가 제한됩니다. 정확한 테스트 조건을 보장하려면 Data 360 Sandbox도 필요합니다. - **릴리즈 아티팩트로부터 환경 분리.** [조직 기반 개발](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)을 사용하지 마십시오. 환경을 고정된 시간 동안 작업이 수행되는 장소로 취급합니다. 환경의 메타데이터 상태는 릴리스 아티팩트와 구분된 상태로 간주합니다. 환경에서 코드 또는 구성의 일부가 "해결"될 경우 소스 제어에 적용되어 릴리스 아티팩트가 되어야 합니다. - 환경은 간단합니다. 가능한 한 빨리 프로세스를 만들고 폐기할 수 있도록 프로세스를 구축합니다. - 아티팩트는 지속됩니다. 소스 제어에 속합니다. - **실패 경로에서 환경 분리** 특정 환경에 변경 사항을 배포해야 하는 필수 릴리스 경로가 일반적으로 표시됩니다. 이 접근 방식은 응용 프로그램 성숙도 또는 릴리스 안정성을 확인하기 위한 프록시를 설정하기 위해 구현되는 경우가 많습니다. 팀은 이를 사용하여 복잡한 테스트 인프라를 구성해야 하는 환경의 수를 최소화할 수도 있습니다. 소스 기반 패러다임에서 변경 사항을 확인하고 테스트할 수 있는 방법과 위치에 대한 유연성을 높일 수 있습니다. - 릴리스 단계는 환경이 아닌 릴리스 아티팩트에 적용됩니다. 특정 릴리스 스테이지에서 모든 변경 사항을 "모음"하기 위해서만 환경을 만들지 마십시오. 이는 소스 제어(특히 분기)의 목적입니다. 소스 제어에서 분기 전략을 사용하여 어떤 환경에 배포할 변경 사항을 구성합니다. 수행해야 하는 작업에 따라 릴리스의 모든 메타데이터를 환경에 배포해야 할 수 있습니다. 분기를 사용하면 이를 수행할 수 있습니다. 몇 가지 예외를 제외하고 모든 개발 환경은 관련 작업이 완료되면 즉시 새로 고치거나 폐기해야 합니다. 특정 환경 내에서 발생하고 유지할 메타데이터에 대한 변경 사항을 소스 제어에 동기화해야 합니다. - 환경은 프로덕션에 대한 충성도만큼 유용합니다. 환경을 최대한 빨리 끊거나 새로 고칠 수 있도록 환경 설정 워크플로 또는 자동화를 최적화합니다. 더 빠르고 빈번한 환경 새로 고침을 수행하지 못하도록 차단하는 구성을 ALM 프로세스의 전반적인 복원에 대한 심각한 위험으로 간주하십시오. 관련 수정 작업이 있는 경우 계획에 추가하고 우선 순위를 지정합니다. 시스템에 더 느슨하게 연결된 [모듈형 유닛](/docs/architect/ko-kr/well-architected/guide/composable)을 도입하는 방법을 알아보십시오. 이를 통해 팀이 스크래치 조직에서 더 많은 유형의 개발을 수행할 수 있으며, 다른 작업을 위해 Sandbox 할당을 확보할 수 있습니다. 라이센스를 구매하지 않았거나 활성화하지 않았으므로 스크래치 조직에서 프로덕션에 없는 기능을 테스트하기 위해 제공하는 기능을 잊지 마십시오. - 비즈니스 사용자 또는 최종 사용자가 액세스할 수 있는 환경에서는 해당 사용자가 자신에게 중요한 사항에 집중할 수 있도록 합니다. 다양한 최종 사용자 그룹 또는 비즈니스 이해당사자가 ALM 관련 작업을 수행하도록 시도하는 차별화되지 않은 일반 환경이 없습니다. 특정 작업을 수행할 특정 이해당사자를 특정 환경에 초대하고 활성화합니다. 부분 복사 Sandbox에서 지원하는 것보다 더 많은 데이터가 포함된 환경에 최종 사용자 또는 비즈니스 이해당사자를 배치하는 프로세스를 주의 깊게 평가합니다. 수행할 작업에 데이터 용량이 필요한지 확인합니다. 사용자 수용 테스트 및 조기 단계 개발 주기를 계획하여 가능한 한 긴밀하게 함께 수행합니다. 모든 테스트 단계를 최적화하여 개발 팀 및 최종 사용자에 대해 빠르고 빠른 사용자 의견 및 반복 주기를 활성화합니다. [테스트 전략](/docs/architect/ko-kr/well-architected/guide/resilient#테스트-전략)을 참조하십시오. - **다른 유형의 변경 사항에 대해 다른 릴리스 경로를 구축합니다**. 모든 변경 사항이 동일한 순서로 동일한 유형의 ALM 작업을 완료해야 하는 것은 아닙니다. 최종 사용자가 시스템의 백엔드 구성 요소에 대한 사소한 변경 사항에 대한 승인 테스트를 수행하도록 할 경우 시간이 적절하지 않을 수 있습니다. 사용자 수용 및 규모 테스트는 모바일 응용 프로그램 개발 초기 단계에서 매우 유용합니다. 높은 위험, 보통 위험, 낮은 위험 등 다양한 범주의 변경 사항에 대한 릴리스 경로를 식별합니다. - **고위험:** 변경 사항은 고객, 파트너 또는 모든 내부 사용자에게 영향을 미칩니다. 변경 사항은 보안 또는 통합에 영향을 미칩니다. 변경 사항이 복잡한 새 기능을 추가합니다. - **중간 위험:** 변경 사항은 내부 사용자의 정의된 임계값 이상에 영향을 미칩니다. 변경 사항은 데이터 모델, 데이터 작업을 수행하는 자동화 또는 통합에 영향을 미칩니다. - **저위험:** 내부 사용자의 정의된 임계값보다 적은 직접적인 영향을 미칩니다. 보안, 데이터 모델 또는 데이터 작업 또는 통합과 관련된 자동화에 대한 변경 사항은 포함되지 않습니다. - 과중한 환경이 존재하도록 **허용하지 마십시오**. 작업의 우선 순위 지정, 범위 지정, 순서 지정에 대한 규칙이 부족하면 불가피하게 과부하된 개발 환경으로 인해 작업량이 지나치게 많고 지나치게 많거나 지나치게 다양합니다. 과부족한 환경은 개발 팀 간에 높은 수준의 스트레스, 모호성, 충돌을 유발합니다. 또한 개발 파이프라인 내에서 소음을 유발하고 품질 관리 노력을 방해합니다. 부정적인 영향 외에도 밀집된 개발 환경은 환경 유지 관리 및 보안에 심각한 위협입니다. ALM 프로세스에서 잠재적인 문제의 증상으로 과부하를 고려하십시오. 근본 원인 문제를 조사하고 해결합니다. 아직도 과도한 인구가 많으면 [추가 샌드박스를 구입할 수 있습니다](https://help.salesforce.com/s/articleView?id=sf.data_sandbox_environments.htm&type=5). ALM의 [패턴 및 비패턴](/docs/architect/ko-kr/well-architected/guide/resilient#alm-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 적절한 환경 관리와 부적절한 환경 관리를 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별합니다. 환경 관리를 위한 Salesforce 도구에 대해 자세히 알아보려면 [Salesforce Resiliency 도구](/docs/architect/ko-kr/well-architected/guide/resilient#복구용-salesforce-도구)를 참조하십시오. ### 신호 전략 신호 전략은 시스템 전체 저하로 계단화되기 전에 오류를 감지, 진단, 수정하는 데 필요한 중요 신호 및 응용 프로그램 도구를 정의합니다. 효과적인 계측은 실패의 수동적인 피해자에서 문제를 감지하고, 행동을 조정하고, 필요한 경우 유익한 저하를 조율할 수 있는 활성 참가자로 응용 프로그램을 변환합니다. 응용 프로그램이 포괄적인 계측을 구현하면 스트레스를 겪고 자가 조절하고 운영자에게 건강 상태를 알리고 조율된 복구 작업에 참여할 수 있습니다. 이러한 기능을 사용하면 개별 구성 요소가 어려움을 겪어도 시스템에서 서비스 품질을 유지할 수 있습니다. 반면 적절한 도구가 없으면 응용 프로그램이 재해적인 증상이 나타날 때까지 자동으로 실패하는 블랙박스가 됩니다. 팀은 사용자가 보고한 후에만 문제에 대응하며 문제 해결은 관찰이 아닌 고고학의 연습이 됩니다. - **응용 프로그램 내 장애 감지** 응용 프로그램이 직접 도구를 사용하여 부하가 많은 상태에서 발생하는 일반적인 실패 패턴을 감지하고 대응해야 합니다. 대기열 채도를 고려하십시오. 메시지 대기열이 처리할 수 있는 것보다 더 빠르게 채워지면 계단식 메모리 소모 또는 시간 초과가 발생할 때까지 비관리 응용 프로그램이 작업을 계속 수락합니다. 적절하게 계측된 응용 프로그램은 대기열 깊이, 거부율, 처리 대기 시간을 모니터링하여 임계값을 초과할 경우 방어적 응답을 트리거합니다. - **어플리케이션 외부의 신호를 효과적으로 처리**: 운영 체제의 신호 처리는 또 다른 중요한 계측 지점을 나타냅니다. 응용 프로그램은 종료 신호(SIGTERM, SIGINT)에 대한 처리기를 등록하여 완벽한 종료를 활성화해야 합니다. 종료 시 적절하게 계측된 응용 프로그램은 새 작업을 수락하지 않으며, 비행 요청이 완료되도록 허용하고, 버퍼를 플러시하고, 연결을 정리하며, 서비스 검색에서 등록을 취소합니다. 이 오케스트레이션된 종료는 데이터 손실을 방지하고 로드 밸런서가 중단 없이 트래픽을 리디렉션할 수 있도록 합니다. - **복잡한 장애 시나리오에 대한 도구:** 이러한 기본 패턴 외에도 응용 프로그램이 더욱 세분화된 오류 모드를 도구화해야 합니다. 일부 관찰자에게는 구성 요소가 정상적으로 표시되고 다른 관찰자에게는 실패하는 회색 오류를 식별하려면 내부 및 외부 신호를 모두 연관시켜야 합니다. 응용 프로그램이 데이터베이스 연결 풀을 통해 성공적인 상태 확인을 보고하는 동시에 저하가 발생하는 트랜잭션 완료율을 추적할 수 있습니다. 효과적인 계측 전략은 여러 관찰 지점을 계층화합니다. - **비즈니스 메트릭**은 주문 완료율 또는 검색 결과 품질과 같은 응용 프로그램별 성공 지표를 추적합니다. - **시스템 메트릭**은 자원 활용도, 지연 분포, 오류 비율을 모니터링합니다. - **합성 탐지기**는 사용자가 발생하기 전에 중요한 경로를 지속적으로 실행하여 저하를 감지합니다. - **분산 추적**은 서비스 범위를 넘어 요청 수준의 가시성을 제공합니다. 해당 신호는 자동화된 시스템과 사용자가 모두 응용 프로그램 상태를 평가할 수 있는 표준화된 인터페이스를 통해 노출됩니다. 이 장비 자체는 응용 프로그램의 복원 전략의 일부가 되며, 오류 비율을 기준으로 회로 차단기, 대기열 깊이에 대응하는 자동 스케일러, 사고 시 [운영자가 정보에 근거한 결정을 내릴 수 있게 해줍니다](/docs/architect/ko-kr/well-architected/guide/resilient#사고-대응). [ALM의 패턴과 안티 패턴](/docs/architect/ko-kr/well-architected/guide/resilient#alm-패턴-및-안티-패턴)은 Salesforce 조직에서 올바르고 나쁜 신호 전략을 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별합니다. 신호 전략을 위한 Salesforce 도구에 대해 자세히 알아보려면 [Salesforce Resiliency 도구](/docs/architect/ko-kr/well-architected/guide/resilient#복구용-salesforce-도구)를 참조하십시오. ### 테스트 전략 테스트 전략은 ALM 프로세스 중 응용 프로그램의 성공 및 실패를 측정하는 테스트를 계획하고 실행하는 방법에 대한 안내 원칙 및 표준 집합입니다. 테스트 전략은 테스트에 관여하는 모든 이해당사자에게 주어진 테스트의 우선 순위, 목적 및 범위에 대한 정보를 제공하고 조율합니다. 프로젝트 팀이 효과적이고 신중한 테스트 계획을 수립할 수도 있습니다. 일반적으로 개발자 또는 품질 보증 및 테스트 전문가가 특정 테스트 만들기 및 실행에 참여합니다. 테스트 전략을 사용하면 해당 개인이 해당 프로젝트에 대해 수행해야 하는 테스트 유형 및 실행 순서를 파악할 수 있습니다. 테스트 전략을 사용하면 팀이 올바르게 구성된 테스트, 테스트 계획, 아티팩트(예: 테스트 데이터 집합, 장치, 트래픽 또는 네트워크 시뮬레이터)를 구축하는 데 필요한 내용을 확보할 수 있습니다. 효과적인 테스트 전략은 다양한 조합과 조건에서 단위 테스트, UI 테스트, 회귀 테스트를 비롯한 다양한 테스트 유형을 실행하는 방법, 시기, 위치, 이유에 대해 명확하게 파악하여 시스템의 동작과 비행 중 변경 사항을 파악합니다. 효과적인 테스트 전략은 단일 유형의 테스트를 통해 측정하기 어려울 수 있는 확장성, 신뢰성 및 유용성과 같은 기능이 아닌 요구 사항을 얼마나 잘 준수하는지 보여주는 테스트를 생성합니다. Salesforce에 대한 효과적인 테스트 전략 만들기: - **회복적으로, 자주, 최대한 자동화된 방법을 통해 테스트**합니다. 팀이 다양한 작업 부하에 대해 다양한 테스트 유형을 실행할 수 있는 테스트 자동화를 설계 및 구현합니다. 소스 제어에 변경 사항이 적용되면 다양한 테스트 실행을 오케스트레이션하여 자동으로 수행합니다. 이 접근 방식을 사용하면 팀이 조기에 회귀를 사전에 식별하고 해결할 수 있습니다. 가능한 경우 이 작업에 연속 통합/연속 전달(CI/CD)을 사용하십시오. 그렇지 않은 경우 팀이 셀프 서비스 방식으로 테스트 순서를 조기에 자주 실행할 수 있도록 명확한 테스트 계획을 수립합니다. Agentforce 에이전트 테스트의 경우 다양한 입력과 함께 AI 에이전트의 엄격한 배치 테스트를 테스트 센터에 의존하여 다양한 시나리오에서 올바르게 작동하는지 확인하십시오. - **모든 변화가 모든 종류의 테스트를 필요로 하는 것은 아닙니다**. 효과적인 릴리스 파이프라인이 고위험, 중간, 낮은 위험 응용 프로그램에 대한 경로를 수용하는 것처럼 효과적인 테스트 전략도 수용합니다. 다양한 유형의 위험, 사용 사례 또는 복잡성이 있는 응용 프로그램에 적절한 테스트 규칙을 선택하고 따르는 방법을 팀에 명확하게 설명합니다. [환경 전략](/docs/architect/ko-kr/well-architected/guide/resilient#환경-전략)을 참조하십시오. - 다양한 환경 유형에서 수행할 수 있는 테스트를 **정의합니다**. 프로덕션 충성도는 정확한 테스트의 핵심 구성 요소이지만, 다양한 유형의 테스트에 대해 서로 다른 의미를 가집니다. 예를 들어 회귀 테스트를 수행하려면 메타데이터 및 일부 데이터 측면에서 프로덕션에 대한 충성도가 필요합니다. 특정 테스트 집합에 필요한 프로덕션 충성도 유형을 정의하고 다양한 테스트에 적합한 조건을 지원할 수 있는 환경 유형을 명확하게 분류해야 합니다. 각 환경 유형에 맞는 작업 유형의 개요는 [환경 전략](/docs/architect/ko-kr/well-architected/guide/resilient#환경-전략)을 참조하십시오. - **내구성, 스트레스, 성능 및 규모 테스트를 사용하여 애플리케이션 성숙도를 지속적으로 측정합니다**. 해당 테스트는 응용 프로그램의 릴리스 준비 상태를 프로덕션 수준 요구 사항에 비례하여 보여줍니다. 주요 새로운 기능의 경우 응용 프로그램 개발 주기에서 여러 간격으로 해당 테스트를 실행합니다. 이러한 테스트를 진행 중인 과업의 일부가 아닌 단일 개발 단계 또는 스테이지의 일부로만 고려하는 것은 비 패턴입니다. 팀이 빠르고 자주 앱 성능에 대한 사용자 의견을 얻는 것이 가장 유용합니다. 그러면 프로덕션 수준의 준비 상태에서 앱이 얼마나 근접했는지 더 잘 이해할 수 있습니다. 변경 사항이 프로덕션으로 전달되기 전에 문제를 더 잘 식별하고 해결할 수 있는 능력은 더 정교한 테스트를 자주 실행하는 것의 복잡성에 가치가 있습니다. - 어떤 테스트가 중요한지 **알아요** 규모 또는 성능 테스트를 수행할 수 있는 시간은 고정되어 있으므로 시스템의 모든 패싯을 테스트하는 것이 비실용적일 수 있습니다. 모든 기능이 동일하게 사용되지는 않으며 모든 규모 지체 지점이 비즈니스에 동일하게 영향을 미치는 것은 아닙니다. 규모 테스트가 시스템에서 가장 많이 사용되고 가치가 높은 부분에 초점을 맞춥니다. 조직의 규모와 성능을 확인하고 개선하기 위해 가장 중요한 기회를 정의하고 이해합니다. - **"좋아"가 어떻게 보이는지 알아요.** 규모 및 성능 테스트에 대한 성공 기준을 정의하는 것이 중요합니다. 사용자 및 개발 팀에서 성공 기준을 테스트 벤치마크로 사용해야 합니다. 또한 개발 팀이 구축하는 기능 요구 사항을 알려야 합니다. 이러한 기준에는 일반적으로 동시 응답 시간이 합의된 값보다 적은 특정 수의 동시 사용자 지원 및 [서비스 수준 목표(SLO)](/docs/architect/ko-kr/well-architected/guide/resilient#복구-시간)가 포함됩니다. 주요 목표 기준을 정의한 다음, 기준이 충족되는지 확인하는 규모 및 성능 테스트를 설계합니다. - **적절한 환경이 있는지 확인하십시오.** 규모 및 성능 테스트를 수행하려면 프로덕션에 대한 특별한 충성도가 필요합니다. 비프로덕션 환경의 데이터 집합, 요청 인구 통계, 요청 비율 및 작업 부하 특성은 프로덕션에서 볼 수 있는 내용과 최대한 일치해야 합니다. 규모 테스트의 경우 전체 Sandbox 사용해야 합니다. 조직에 규모 테스트를 위한 전체 Sandbox 없는 경우 적절한 규모 테스트를 실행할 수 없습니다. - **테스트 워크로드가 기능이 아닌 요구 사항을 측정하는 데 도움이 되는지 확인하십시오**. 다음 사항을 고려하십시오. - **테스트 데이터** \- 모든 종류의 테스트는 생산에서 격리된 데이터에 대해 수행해야 합니다. Apex 단위 테스트에서 코드가 환경 데이터와 분리된 자체 테스트 데이터를 생성하도록 [데이터 공장 패턴을](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_utility_classes.htm) 구현합니다. 또한 다양한 형식으로 테스트 데이터 집합을 만들고 유지하여 데이터 로드 동작을 테스트하고 UI 기반 테스트를 위한 데이터를 개발 환경에 채우거나 통합 테스트를 지원할 수 있습니다. 외부화된 데이터 집합으로 유지되거나 데이터 공장 코드로 요청에 따라 생성되는 모든 테스트 데이터는 민감한 식별 데이터를 제거해야 합니다. 음수 및 경계 단위 테스트 동작을 지원하기 위해 손상, 불완전, 잘못된 데이터를 포함해야 합니다. - **모형 서비스** \- 통합 테스트를 위해 모형 서비스와 모형 서비스를 사용하여 API 응답을 시뮬레이션할 수 있습니다. Apex는 Apex 테스트에 사용할 수 있는 모의 프레임워크를 만들 수 있는 [Stub API를](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_stub_api.htm) 지원합니다. Apex 테스트에서 사용할 수 있는 모의 프레임워크를 만드는 모의 Mocks 및 stubs는 복잡한 데이터 공장 또는 외부 테스트 데이터 집합에 대한 의존도가 줄어들면서 시스템의 데이터 처리 동작을 확인하는 데 도움이 됩니다. 프로덕션과 유사한 트래픽 또는 데이터 용량이 관련이 없는 테스트에서 사용하는 것이 더 적합한 경우가 있습니다. - **장치 및 보조 기술** - [관련](/docs/architect/ko-kr/well-architected/guide/engaging)하고 [접근 가능한](/docs/architect/ko-kr/well-architected/guide/compliant#접근성) 애플리케이션을 구축하는 데 중요한 부분은 다양한 장치와 다양한 유형의 보조 기술을 통해 사용자의 기대치를 충족하는 것입니다. 유용한 유용성 테스트를 효과적으로 수행하려면 더 많은 투자와 다양한 종류의 전문 지식이 필요할 수 있지만, 릴리스 시 사용자 대면 응용 프로그램이 얼마나 잘 설계되었는지 파악하는 데 필수적인 부분입니다. - **시뮬레이터** \- 사용자 요청, API 트래픽 또는 네트워크 속도 변동을 프로덕션 방식으로 복제해야 하는 경우 이러한 조건을 시뮬레이션하는 도구가 필요할 수 있습니다. 모든 테스트에서 이 수준의 투자가 필요하지는 않습니다. 이러한 도구는 확장성 및 성능 테스트에 가장 유용합니다. - **AI 및 에이전트 테스트** \- 테스트의 주된 목표는 인공지능 환각을 줄이는 것입니다. 이는 설득력 있고 잘못된 반응입니다. AI 사용 사례가 테스트되어 고객의 불완전한 이해, 누락된 데이터, 불완전한 메타데이터가 있는 필드, 오래된 데이터로 인해 발생하는 일반적인 문제를 강조합니다. 테스트 센터를 사용하여 해당 테스트에 필요한 테스트 데이터를 만들 수 있습니다. ### ALM 패턴 및 안티 패턴 다음 표는 조직에서 찾거나 구축할 패턴을 선택하고, 방지하거나 수정할 항 패턴을 표시합니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/adaptable-application-lifecycle-management)에서 ALM에 대한 더 많은 패턴을 확인하십시오.
패턴 안티 패턴
릴리즈 관리 생산 중:
- 메타데이터는 다음과 같은 안정적인 릴리스 메커니즘 사용을 보여줍니다.
-- 잠금 해제된 패키지로 구성되는 메타데이터
-- 활성 상태 및 설치 중인 DevOps Center
-- 소스 형식을 사용하는 메타데이터 API를 통한 배포
- 배포 로그에 사용 가능한 내역 내에서 실패한 배포가 표시되지 않습니다.
- 배포 내역에 릴리스 케이던스와 릴리스 기간 내의 꽤 균일한 배포 클러스터가 명확하게 표시됩니다.
생산 중:
- 메타데이터는 다음과 같은 조직 기반 릴리스 메커니즘 사용을 나타냅니다.
-- 변경 집합의 활성 사용
-- 메타데이터 API를 통한 배포는 package.xml 형식을 사용합니다.
- 배포 로그에 사용 가능한 내역 내에서 실패한 배포의 반복 인스턴스가 표시됩니다.
- 배포에 인식할 수 있는 케이던스가 없거나 핫픽스 및 특별 롤백의 징후인 불규칙한 배포 클러스터가 표시됩니다.
- DevOps Center 활성화 및 설치되지 않았습니다.
로드맵 및 문서:
- 릴리스 이름은 명확합니다.
- 기능은 명명된 특정 릴리스와 명확하게 연결되어 있습니다.
- 릴리스 이름을 검색하고 검색할 수 있습니다.
- 팀은 올바른 릴리스 이름을 사용하여 아티팩트, 개발 항목 및 기타 작업에 태그를 지정하기 위한 명확한 지침을 찾고 따를 수 있습니다.
- 릴리스 이름으로 릴리스 매니페스트의 명확한 보기를 결합할 수 있습니다.
- 생성형 AI 앱의 품질 임계값은 다양한 개발 단계에 대해 정의되어 있습니다.
로드맵 및 문서:
- 릴리스 이름은 포함되지 않습니다.
- 기능이 특정 릴리스와 명확하게 연결되어 있지 않습니다.
- 릴리스 이름이 임시로 사용되거나 존재하지 않습니다.
- 팀은 다양한 방식으로 아티팩트, 개발 항목 및 기타 작업을 참조합니다.
- 릴리스 이름을 사용하여 릴리스 매니페스트의 명확한 보기를 결합할 수 없습니다.
- 생성형 AI 앱의 품질 임계값은 정의되지 않았거나 정의된 경우 다른 개발 단계에 대해 정의되지 않았습니다.
환경 전략 조직의 경우:
- 소스 중심 개발 및 릴리스 모델이 채택됩니다.
- Developer 및 Developer Pro Sandbox에 대해 소스 추적이 활성화되어 있습니다.
- 지정된 환경의 메타데이터는 릴리스 아티팩트와 무관합니다.
- 환경이 릴리스 경로에 직접적으로 해당하지 않습니다.
- 변경 사항에 대한 릴리스 경로는 변경 유형(높은 위험, 보통 위험 또는 낮은 위험)에 따라 다릅니다.
- 과다 채워진 환경은 존재하지 않습니다.
- 위험한 구성 변경은 프로덕션에서 직접 수행되지 않습니다.
- 최고 영업 시간에는 릴리스가 발생하지 않습니다.
- Data 360 Sandbox는 Einstein 데이터 라이브러리, Knowledge 기사 및 비정형 데이터가 필요한 에이전트 사용 사례를 올바르게 테스트하는 데 사용됩니다.
조직의 경우:
- 조직 기반 개발 및 릴리스 모델이 채택됩니다.
- Developer 및 Developer Pro Sandbox에서는 소스 추적이 활성화되지 않습니다.
- 지정된 환경의 메타데이터는 릴리스 아티팩트입니다.
- 환경은 릴리스 경로에 직접 해당합니다.
- 모든 변경 사항에 대한 릴리스 경로는 변경 유형에 관계없이 동일합니다.
- 과부하 환경이 있습니다. - 위험한 구성 변경은 프로덕션에서 직접 수행됩니다.
- 최대 업무 시간 동안 릴리스됩니다.
- Einstein 데이터 라이브러리, Knowledge 기사 및 비정형 데이터가 필요한 Agentforce 에이전트는 Data 360 Sandbox를 사용하여 테스트되지 않습니다.
신호 전략 조직의 경우:
- 팀이 건강 검사 API 및 SLO 정의 및 표준화에 대해 공동 작업을 진행합니다.
- 신호 전략을 정기적으로 검토하고 세분화하는 작업은 사후 검사 및 운영 준비 검토의 일부입니다.
생산 중:
- 모든 신청에 대해 상태 확인이 구현됩니다.
- 응용 프로그램은 부하 및 성능과 같은 상태에 대한 명시적 신호를 제공합니다.
- 종속성이 건강하지 않은 경우 응용 프로그램이 정상적으로 저하되도록 설계되었습니다.
- 로드 삭제는 계단식 실패를 방지하는 데 사용됩니다.
설계:
- 역압 및 로드 분산 메커니즘을 통해 서비스가 트래픽으로 인해 압도되지 않습니다.
- 종속성이 결국 실패한다고 가정합니다. 신호 처리기는 오류를 개선하기 위해 구축되었습니다.
조직의 경우:
- 팀이 일관되지 않고 운영되므로 일관되지 않고 호환되지 않는 건강 신호 메커니즘이 생성됩니다.
- 신호 전략은 사고가 발생한 경우에만 해결되는 사후 고려 사항입니다.
생산 중:
- 구성 요소가 상태를 신호 없이 자동으로 실패합니다.
- 응용 프로그램이 비정상적인 서비스에 대한 요청을 무기한으로 재시도합니다.
- 모든 요청은 중요도에 관계없이 동일한 우선 순위로 처리됩니다.
- 문제를 식별하기 위해 작업자는 사용자 컴플레인 또는 심각한 시스템 오류와 같은 반응형 조치에만 의존합니다.
설계:
- 모든 종속성을 항상 사용할 수 있으며 네트워크 파티션, 대기 시간 급증 또는 기타 일반적인 문제는 고려되지 않는다고 가정합니다.
- 과부하가 있는 경우에도 응용 프로그램이 모든 수신 요청을 수락하므로 대기 시간이 증가하고 실패 가능성이 높아집니다.
테스트 전략 당사에서:
- 유용성 테스트는 다양한 장치 및 보조 기술을 사용합니다.
- 시뮬레이터는 확장성 및 성능 테스트를 위해 프로덕션과 유사한 조건을 복제하는 데 사용됩니다.
- 변경 사항이 소스 제어에 도달하면 테스트가 자동으로 실행됩니다.
- 응용 프로그램 개발 주기의 여러 간격으로 내구성, 스트레스, 성능, 규모 테스트가 실행되고 진행 중인 과업으로 간주됩니다.
- B2C 규모 앱, 대량 사용자 또는 대량 데이터가 있는 경우 QA 프로세스의 일부로 규모 테스트를 포함합니다.
- 규모 테스트는 우선 순위가 높은 시스템 측면에 초점을 맞춥니다.
- 규모 테스트에 잘 정의된 기준이 있습니다.
- 전체 Sandbox 규모 테스트를 수행합니다.
- 프롬프트 엔지니어링에는 사람의 품질 검토가 포함됩니다.
- Agentforce 테스트 센터 강력한 에이전트 테스트에 사용됩니다.
당사에서:
- 유용성 테스트는 수행되지 않거나 수행되는 경우 제한된 장치 집합에서 수행됩니다.
- 프로덕션 유사한 사용자 요청, API 트래픽, 네트워크 속도 변형 볼륨은 테스트되지 않습니다.
- 테스트 자동화가 없습니다.
- 내구성, 스트레스, 성능, 규모 테스트는 개발 단계 또는 단계로 간주됩니다.
- QA 프로세스의 일부로 규모 테스트를 수행하지 않으며 B2C 규모 앱, 대량 사용자 또는 대용량 데이터가 있습니다.
- 규모 테스트에 우선 순위가 지정되지 않습니다.
- 규모 테스트에 잘 정의된 기준이 없습니다.
- 부분 복사 또는 Developer Sandbox 규모 테스트를 수행합니다.
- 프롬프트 엔지니어링에는 사람의 품질 검토가 포함되지 않습니다.
- Agentforce 에이전트는 테스트되지 않거나, 테스트된 경우 Agent Builder를 사용하여 임시로만 테스트됩니다.
조직에서:
- 모든 테스트 데이터는 민감한 식별 데이터를 제거합니다.
조직에서:
- 테스트 데이터는 프로덕션 데이터와 동일합니다.
Apex:
- 데이터 공장 패턴이 단위 테스트에 사용됩니다.
- Mocks 및 stubs는 API 응답을 시뮬레이션하는 데 사용됩니다.
Apex:
- 단위 테스트는 조직 데이터에 의존합니다.
- Mocks 및 stubs는 사용되지 않습니다.
설계 표준 및 문서:
- 환경은 지원할 수 있는 테스트 유형별로 분류됩니다.
- 위험, 사용 사례 또는 복잡성에 따라 적절한 테스트 규칙이 지정됩니다.
설계 표준 및 문서:
- 각 환경이 지원하는 테스트 유형은 명확하지 않습니다.
- 테스트 규칙은 위험, 사용 사례 또는 복잡성별로 범주화되지 않습니다.
## 사고 대응 보안 및 사이트 신뢰도 엔지니어링(SRE)에서 사고 대응은 팀이 시스템의 전체 가용성 또는 보안에 영향을 미치는 이벤트를 식별하고 해결하는 방법, 근본 원인을 해결하고 향후 문제를 방지하기 위해 팀이 작업하는 방법에 초점을 맞춥니다. 사고 대응에는 실시간 및 문제 발생 후 문제를 해결하는 데 필요한 프로세스, 도구, 조직적 동작이 포함됩니다. 설계자는 솔루션이 적용되면 일상적으로 솔루션의 작업을 모니터링하지 않을 수 있습니다. 복원에 대한 아키텍처의 일부는 지원 팀이 1차 진단을 수행하고 시스템을 안정화하고 개발 또는 서비스 점검 팀에 효과적으로 조사 및 근본 원인 완화 작업을 전달할 수 있는 복구 기능을 설계하는 것입니다. 일상적으로 사용자를 직접 지원하는 팀은 시스템 아키텍처에 대한 심층적 이해 또는 전문 지식을 갖지 못할 수 있습니다. 이러한 팀은 일상적인 작업을 모니터링하고, 잠재적인 사고를 진단할 때 시스템에서 정보에 액세스하고, 가용성에 영향을 미치는 문제에 대해 효과적인 최초 대응 담당자 역할을 수행하는 데 필요한 도구와 프로세스를 보유해야 합니다. Salesforce 솔루션에서 사고에 대한 팀의 대응 수준을 향상할 수 있으므로 [복구 시간](/docs/architect/ko-kr/well-architected/guide/resilient#복구-시간), [분류 능력](/docs/architect/ko-kr/well-architected/guide/resilient#분류-기능), [모니터링 및 경고](/docs/architect/ko-kr/well-architected/guide/resilient#모니터링-및-경고)에 집중할 수 있습니다. ### 복구 시간 사고가 발생하면 첫 번째 우선 순위가 시스템을 안정적인 운영 상태로 복원해야 합니다. 비즈니스는 사고 복구의 유일한 방법은 "문제를 해결하는 것"이라고 생각하는 경우가 많습니다. 정확한 근본 원인 분석 및 해결 방법이 시스템에서 최종적으로 중요한 문제를 해결하는 방법이라는 가정은 공정합니다. 그러나 위기 대응 초기 단계에서 "문제 해결"은 가장 실용적인 접근 방식이 아닙니다. 사고의 심각도에 따라 사고의 모든 초과와 영향으로 인해 비즈니스의 매출 또는 평판이 손실될 수 있습니다. 근본 원인을 진단하고 해결하려고 하면 시스템을 복원하는 작업이 지연되는 경우가 많습니다. 물류적으로 사고 대응 담당자에게 근본 원인을 해결하도록 요청하는 접근 방식을 채택하면 회사의 주제 전문가(SME) 및 지원 직원이 엄청난 부담을 받습니다. 사고 _도중_ 근본 원인을 찾고 해결하려면 중소기업이 모든 사고에 대해 통화해야 하며, 이는 고객 대면 지원 직원이 조치를 취하지 못하도록 차단할 수 있습니다. 또한 팀이 변경 사항을 릴리스하여 더 많은 사고를 야기할 수 있습니다. 최종적으로 이러한 접근 방식은 비용을 늘리고 팀 전체에서 대역폭을 소비하며 위기 상황에서 고객의 Trust 브랜드 평판을 손상시킬 수 있는 동작으로 이어집니다. 적절한 사고 관리 패러다임은 첫 번째 단계로 복구의 우선 순위를 지정하고 복구에 집중하는 것입니다. 시스템이 안정적으로 복원되면 무책임한 사후 요금, 사고 조사, 근본 원인 해결, 유사한 활동에 대한 팔로우업을 수행할 수 있습니다. 이 작업 순서로 사고 대응 직원이 복구 전술을 분류, 진단, 실행할 수 있게 되므로 필요한 경우에만 지원하도록 관련 SME에 알립니다. 또한 중소기업은 틱크 클럭의 압력을 줄여 사고의 근본 원인을 식별하고 해결할 수 있습니다. 사고 대응에 대한 복구 우선 고려 사항 채택: - **서비스 수준 목표 SLO를 설정하고 달성**합니다. SLO는 성능 또는 가동 시간과 같은 시스템의 특정 비기능 요구 사항(NFR)에 대해 이해당사자와 함께 개발하는 표준입니다. 이러한 목표는 기간에 걸친 서비스 수준 지표(SLI)로 측정됩니다. SLO를 사용하지 않으면 사고 대응 및 복잡한 문제 해결과 관련된 많은 작업이 비정형적이고 반응적일 수 있습니다. 예를 들어, "보고한 사용자 몇 명에 대해 이 특정 오류를 중지하도록 신속한 조치를 취하라는 메시지가 표시됩니다." 이러한 주기는 주로 팀이 사고 응답에 근접하게 근본 원인 분석을 푸시하므로 반응형 동작을 중지하는 데 도움이 됩니다. SLO 및 SLI를 설정하면 더욱 효과적으로 시작할 수 있습니다. SLO를 설정하려면 다음 질문을 고려하십시오. - **다음 1~3년 동안 시스템의 NFR는 무엇입니까?** 예를 들어, NFR에 시스템에서 지원해야 하는 응답 시간, 최대 요청 비율 및 동시 사용자가 포함될 수 있습니다. - **고객과 사용자가 무엇을 경험하길 원하십니까?** SLO는 "사용자가 Salesforce에서 보고서를 빠르게 실행할 수 있음"이라는 질문에 대한 답변을 기반으로 합니다. - **당신은 무엇을 측정할 수 있으며, 얼마 동안 측정해야합니까?** SLI는 이 질문의 답변을 기반으로 합니다. 이전 예제와 일치하는 SLI는 "보고서의 평균 _x_%가 30일 동안 평균 \_n_s 이내에 로드됩니다."입니다. - **복구 전술을 정의하고 표준화합니다.** 변경 롤백 및 해결 방법을 구현하면 시스템이 다시 작동하고 사고의 영향을 최소화할 수 있습니다. 지원 또는 운영 팀의 적절한 구성원이 실행할 수 있는 복구 전술 및 프로토콜을 문서화합니다. 복구 전술은 사고 유형에 따라 다릅니다. 다음 표는 사고 유형을 복구 전술에 매핑하는 일반적인 프레임워크를 보여줍니다. 장애 지점 식별 및 완화 전략 정의에 대한 자세한 내용은 [가용성](/docs/architect/ko-kr/well-architected/guide/reliable#가용성)을 참조하십시오.
사고 유형 표시 트리거 복구 전술
시스템 중단 손상된 로그인 또는 계정 액세스 관련 문제 계정 복구 정책
서비스를 사용할 수 없음 중복 백업 서비스 활성화, 수동 해결 방법
프로덕션 버그 최근 변경 사항 이전 버전의 배포 롤백 또는 배포 취소
발생하는 설명할 수 없는 버그 수동 해결 방법, 비필수 기능 비활성화, 중소기업에 에스컬레이션
- **확실한 탈퇴 기준 정의** SLO를 사용하여 시스템이 사고 또는 영향 상태가 아닌 시점을 확인합니다. - **사고 후 검토 및 근본 원인 해결을 위한 프로세스 정의.** 서비스가 복원된 후 사고를 검토하십시오. 검토 중에, _죄없는 사후_ 접근을 취하십시오. 이해당사자와 협력하여 개인에게 오류 또는 책임을 할당하지 않고 발생한 _상황_ 및 발생 _방법에_ 대한 명확한 사실을 파악하는 데 집중합니다. 다양한 검토 형식을 사용하여 장기간 문제를 해결할 수 있는 방법을 살펴봅니다. - *후 조치 검토*는 사고에 대한 대응에 중점을 둡니다. 적절한 응답 프로세스 및 전술이 있는지 평가하는 데 유용합니다. - * 근본 원인 분석*은 사고의 근본 원인에 초점을 맞춥니다. 사고를 유발한 시스템 설계 및 구현의 버그 또는 문제를 식별하는 데 도움이 됩니다. - **약속된 복구 프로토콜을 정기적으로 연습하십시오**. 모든 사람이 사고를 제대로 처리하는 방법을 알고 있도록 복구 프로토콜을 연습합니다. Sandbox 및 테스트 환경을 사용하여 팀에 사고 시뮬레이션 및 복구를 연습할 수 있는 장소를 제공합니다. 사고 후 검토도 연습하십시오. 이러한 모든 작업을 수행하면 복구가 엔지니어링 및 지원 문화의 일부가 됩니다. 사고 응답을 위한 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/resilient#사고-응답-패턴-및-안티-패턴)은 Salesforce 솔루션에서 복구 우선 순위를 지정하는 아키텍처를 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별합니다. 복구 시간에 도움이 되는 Salesforce 도구에 대해 자세히 알아보려면 [Salesforce Resiliency 도구](/docs/architect/ko-kr/well-architected/guide/resilient#복구용-salesforce-도구)를 참조하십시오. ### 분류 기능 기술 컨텍스트에서 정렬은 문제 및 지원 요청에 범주 및 심각도 수준을 할당하는 작업을 수행합니다. 솔루션이 얼마나 잘 계획되었든 사용자 지원 문제와 요청이 발생합니다. 이러한 문제는 충분한 교육이나 변경 관리 부족, UI/UX의 격차, 예기치 않은 최종 사용자 행동, [모니터링 또는 경고](/docs/architect/ko-kr/well-architected/guide/resilient#모니터링-및-경고)에서 파악되지 않는 긴급한 시스템 문제로 인해 발생할 수 있습니다. 지원 및 운영 팀은 사용자 지원 쿼리를 효율적으로 조사하고 빠르게 진단할 수 있어야 합니다. 문제를 정렬하여 덜 심각한 우려 사항을 필터링하고 중요한 시스템 사고를 신속하게 파악하는 것이 해당 팀의 핵심 역량입니다. 잘못된 분류는 모든 수준의 사용자 지원을 지연하고, 중요한 사고를 연장하며, 고객 및 비즈니스에 대한 추가 중단 위험을 높입니다. 일상적인 운영 및 지원에 관여하지 않을 수도 있지만, 설계자로서 지원 및 운영 팀이 Salesforce Platform에서 생성하는 모든 솔루션에서 문제를 효과적으로 정렬할 수 있도록 지원할 책임이 있습니다. 팀이 Salesforce 솔루션 내에서 문제를 효율적으로 분류할 수 있도록 지원: - **지원 팀이 유용한 정보에 액세스할 수 있도록 하십시오**. - **시스템 문서화 및 디자인 패턴** 솔루션의 [읽기](/docs/architect/ko-kr/well-architected/guide/intentional#가독성) 및 일관성을 보장하는 것은 지원 담당자가 지원하는 시스템을 이해할 수 있도록 하는 핵심 요소입니다. 문서에서 팀이 시스템의 다양한 부분에서 문제 또는 사고의 우선 순위를 지정하는 방법에 대한 정보를 찾는 방법을 고려합니다. 또한 팀이 영향 영역을 기반으로 복구 전술에 대한 기술 정보를 빠르게 확인할 수 있도록 합니다. 주제 분류 및 작업 선택과 같은 일반적인 Agentforce 문제에 대한 관련 문제 해결 가이드를 제공하여 팀이 권한 또는 구성과 관련된 문제를 신속하게 정렬할 수 있습니다. - 디버깅을 염두에 두고 **설계하십시오**. 지원 팀 및 조직 관리자가 다양한 환경에서 사용자 문제를 올바르게 정렬하려면 디버깅 및 진단을 활성화해야 합니다. _디버그 친화적_ 패턴의 예는 로깅 및 사용자 정의 오류 메시지를 시스템 전체의 실행 경로에 통합하는 패턴입니다. 이벤트 로그 및 Agent Builder의 추론 보기와 같은 도구를 사용하여 일반적인 Agentforce 디버깅 접근 방식을 지원하는 팀을 지원합니다. - **사고 중소기업 및 이해당사자 파악** 사고 복구를 지원할 수 있어야 하는 관련 중소기업 또는 이해당사자 목록을 만들고 사고 후 분석 동안 관여해야 하는 이해당사자를 만듭니다. - **Handoff를 신중하게 처리하십시오**. 적용 과정의 일부로 지원 팀 또는 운영 팀에 대한 각 솔루션의 품질을 확인합니다. 지원 담당자가 관련 시스템 아키텍처 및 모의 사고 대응 드릴을 살펴볼 수 있도록 교육을 제공합니다. 팀이 로그 또는 사례 노트에서 수집되지 않는 정보를 문서화해야 하는 방법과 사고 응답자가 근본 원인 조사에 기여하거나 해결 방법에 대한 사용자 수락 테스트를 수행할 수 있는 방법을 포함하여 사고 후 하던프에 대해 생각해 보십시오. - **상담을 받는 경우 모두가 복구에 집중하도록 하십시오**. - **빠르게 응답하십시오.** 수신한 모든 사용자 지원 요청, 모니터링 알림, 경고에 빠르게 응답합니다. - **증상과 문제를 구분하는 데 도움이 됩니다.** 해결해야 하는 실제 시스템 사고가 있는지 확인합니다. 실제 문제가 있는 구성 요소를 식별하십시오. 합의된 [복구 전술](/docs/architect/ko-kr/well-architected/guide/resilient#복구-시간)을 따라 시스템을 사고 상태에서 빠르게 제거하도록 지원합니다. - 중요한 사용 사례를 지원하는 Agentforce 에이전트의 경우 실행 가능한 적절한 해결 방법이 있는지 확인하고 예비 조치로 짧은 경고로 설정할 수 있습니다. 예를 들어 수동으로 전환하거나 수동 검토를 위해 관련 문서로 리디렉션됩니다. 사고 응답을 위한 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/resilient#사고-응답-패턴-및-안티-패턴)은 Salesforce 솔루션에서 효과적인 분류를 위한 아키텍처를 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별합니다. 분류에 도움이 되는 Salesforce 도구에 대해 자세히 알아보려면 [Salesforce Resiliency 도구](/docs/architect/ko-kr/well-architected/guide/resilient#복구용-salesforce-도구)를 참조하십시오. ### 모니터링 및 경고 _모니터링_ 및 *경고*은 현장 안정성 엔지니어링에서 널리 사용되는 용어입니다. 시스템 복원 능력의 맥락에서 모니터링은 시스템의 현재 상태를 지속적으로 평가하고 경고는 시스템 상태에 대한 잠재적인 우려 사항에 대해 이해당사자에게 자동으로 알립니다. 효과적인 모니터링 및 경고는 시스템의 규모와 성장과 지원 직원의 규모와 성장을 분리하는 데 중요한 부분입니다. Salesforce는 시스템의 동작을 모니터링할 수 있는 다양한 내장 기능을 제공합니다. Salesforce는 추가 기능 또는 [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/)의 일부로 [실시간 이벤트 모니터링](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/real_time_event_monitoring_overview.htm)도 제공합니다. Salesforce 솔루션에서 모니터링 및 경고를 위해 설계된 설계는 다음을 제공합니다. - 자동 사고 응답 기능 - 적시에 적절한 사용자에게 관련 정보 제공 - 내역 보기 및 추세 분석에 대한 명확한 정보 Salesforce 솔루션 내에서 효과적인 모니터링 및 경고를 위한 설계: - **자동화의 우선 순위 지정** 시스템을 안정적이고 운영하기 위해 중요한 상태 변경 사항에 대해 사용자에게 알리는 것이 중요하지만, 이상적인 아키텍처에서 시스템은 가능한 경우 문제를 자체 수정하고 긴급하고 복구할 수 없는 문제에 대해서만 경고를 보냅니다. 자동화는 자체 수정 기능이 없어도 경고 및 보고가 더욱 유용해질 수 있습니다. - **Salesforce에서 이미 제공하는 것부터 시작하십시오**. Salesforce Platform은 총괄자 제한과 관련하여 솔루션의 작업을 모니터링할 수 있는 관련 로그 및 API를 제공합니다. 또한 플랫폼은 총괄자 제한 위반 및 유사한 문제에 대한 경고를 보냅니다. 이러한 로그 및 경고를 기반으로 시스템 자가 복구, 사고 보고, 경고를 보다 완전히 자동화할 수 있는 방법을 살펴볼 수 있습니다. 예를 들어, 로그를 모니터링한 후 특정 유형의 이벤트가 기록될 때 복구 작업을 수행하는 자동화를 구현할 수 있습니다. - 예측 가능한 방식으로 시스템 상태의 변경 사항을 **분류합니다**. 모니터링하고 보고할 주요 상태에 대한 의미 있는 특정 범주를 만듭니다. 이러한 범주를 [응용 프로그램 구성 요소](/docs/architect/ko-kr/well-architected/guide/composable#시도-관리)에서 상태를 관리하기 위해 정의한 범주에 맞춥니다. 상태 변경 정보를 처리하는 방법에 대해 [API 지향적](/docs/architect/ko-kr/well-architected/guide/composable#api-관리) 사고 방식을 채택합니다. 일관된 메시지 형식 및 상태 범주를 사용하면 자동화, 보고, 경고를 간소화할 수 있습니다. - **자동화 논리를 시스템의 다른 부분과 일치시킵니다**. 올바른 자동화 [오류 처리를](/docs/architect/ko-kr/well-architected/guide/automated#오류-처리) 구축한 경우 해당 패턴을 상태 변경을 분류하고 자동화로 대응하는 방법으로 확장할 수 있습니다. 복구 가능한 상태로 간주되는 상태 변경의 경우 재시도 동작을 자동화할 수 있습니다. 중요하거나 치명적인 상태로 간주되는 상태 변경의 경우 사용자에게 경고를 자동화합니다. - **소리를 피하십시오**. 특히 조치를 취하지 않아도 되는 경고가 너무 많으면 사용자가 모든 경고를 비활성화하거나 무시하는 경향이 있습니다. 이 시나리오는 [유용한](/docs/architect/ko-kr/well-architected/guide/engaging#유용) 경고를 생성하기 위한 모든 노력을 저하합니다. 알림을 수신하는 사람, 트리거하는 요소 및 트리거 시기를 더 잘 파악하려면 다음 작업을 고려하십시오. - 이해당사자 맵 **구축** 시스템이 적시에 적절한 이해당사자에게 올바른 경고를 전달하도록 하려면 먼저 이해당사자 그룹을 식별하고 분류합니다. - **사용자 권한을 기반으로 메시지를 라우팅합니다**. 응답할 수 있는 능력 및 권한이 있는 수신자에게만 경고를 보냅니다. 비즈니스 사용자는 액세스 권한이 있는 레코드의 문제를 수정하여 해결할 수 있는 문제에 대한 경고의 혜택을 누릴 수 있습니다. 문제에 대해 더 적극적인 기술적 대응이 필요한 경우 지원 담당자에게 경고를 보냅니다. - **예상 응답을 명확히 하십시오**. 사람이 개입해야 하는 시나리오에서만 경고를 보냅니다. 수신자에게 예상되는 작업을 명확하게 표시하도록 메시지를 구조화합니다. 이해당사자에게 가시성을 위해 경고를 보내고 이해당사자에게 조치가 필요하지 않은 경우 수신하는 메시지 버전에 명확하게 명시합니다. - **일시적이고 적절한 경고를 만듭니다**. 발생했지만 수정해야 하는 실패에 대한 응답으로 전달되는 경고는 잠재적인 실패에 대한 경고만큼 유용하지 않습니다. 이상적으로 지원 직원은 시스템에서 문제가 발생하면 즉시 경고를 받으므로 문제가 비즈니스 운영에 부정적인 영향을 미치기 전에 문제를 [정렬할 수](/docs/architect/ko-kr/well-architected/guide/resilient#분류-기능) 있습니다. [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/resilient#사고-응답-패턴-및-안티-패턴) 목록은 Salesforce 솔루션에서 효과적인 모니터링 및 경고를 위한 아키텍처를 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별합니다. 모니터링 및 경고를 위한 Salesforce 도구에 대해 자세히 알아보려면 [Salesforce Resiliency 도구](/docs/architect/ko-kr/well-architected/guide/resilient#복구용-salesforce-도구)를 참조하십시오. ### 사고 응답 패턴 및 안티 패턴 이 표는 조직에서 찾거나 구축할 패턴을 선택한 다음, 방지하거나 수정할 항 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/adaptable-incident-response)에서 사고 응답에 대한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
복구 시간 당사에서:
- 복구 프로토콜은 정기적으로 실행됩니다.
- 팀은 자신이 소유하고 담당하는 프로덕션 서비스가 무엇인지 알고 있습니다.
- 팀은 문제 진단을 지원하는 관련 도구를 이해합니다.
당사에서:
- 복구 프로토콜이 없거나 정기적으로 실행되지 않습니다.
- 프로덕션에서 다양한 서비스를 소유하고 담당하는 팀은 명확하지 않습니다.
- 팀에 문제 진단을 지원하는 도구에 대한 지침 또는 표준이 없습니다.
문서:
- 복구 전술은 사고 유형 및 트리거별로 정의되고 분류됩니다.
- 사고 응답의 종료 기준은 SLO에 포함되어 있으며 명확합니다.
- 사고 시 증가된 권한에 대한 활성화 기준 및 할당 논리가 명확합니다.
- 사고 응답 권한 집합 및 권한 부여가 명확하게 나열됩니다.
- 일반적인 문제를 식별하고 진단하는 데 도움이 되는 문제 해결 가이드가 있습니다.
문서:
- 사고 대응은 임시로 수행됩니다.
- 사고 응답에 대한 종료 기준이 없습니다.
- 증가된 권한은 할당되지 않거나, 그럴 경우 임시로 할당됩니다.
- 사고 응답 권한 집합 및 권한 부여가 나열되지 않습니다.
조직에서:
- 사고 대응에 대한 세션 기반 권한 집합이 있으며 복구 동안 지원 직원을 할당할 수 있습니다.
- 설정 감사 내역은 지정된 복구 테스터가 합의된 시간에 테스트 환경에 로그인하고 복구 테스트 스크립트를 따랐음을 보여줍니다.
조직에서:
- 세션 기반 권한 집합이 사고 응답에 존재하지 않거나 해당하는 경우 지원 직원이 해당 권한을 사용할 권한이 없습니다.
- 설정 감사 내역은 지정된 복구 테스터가 테스트 환경에 로그인하지 않았거나 복구 테스트 스크립트를 따르지 않았음을 보여줍니다.
테스트 계획:
- 복구 테스트를 위한 테스트 스크립트가 있으며 반복할 수 있습니다.
- 사고 시뮬레이션을 위한 환경이 명확하게 나열됩니다.
테스트 계획:
- 복구 테스트를 위한 테스트 스크립트가 없습니다.
- 사고 시뮬레이션을 위한 환경이 설정되지 않았습니다.
정렬 능력 당사에서:
- 사고가 발생하기 전에 복잡한 문제를 지원하도록 경고해야 하는 중소기업 또는 이해당사자를 식별합니다.
- 배달 및 지원 팀 간의 핸드오프는 적용 과정의 일부입니다.
- 상담을 마치면 Salesforce 아키텍처가 신속하게 대응하고 팀이 복구에 집중할 수 있도록 지원합니다.
당사에서:
- 사고가 발생할 때까지 경고해야 하는 중소기업 또는 이해당사자를 식별할 수 없습니다.
- 배달 팀과 지원 팀 간의 핸드오프는 릴리스 프로세스의 일부가 아닙니다.
- Salesforce 아키텍처는 사고 대응이 작업 범위를 벗어나는 것으로 간주합니다.
문서:
- 주어진 솔루션에 사용된 시스템 및 설계 패턴은 지원 직원이 검색하고 읽을 수 있습니다.
문서:
- 주어진 솔루션에 사용된 시스템 및 설계 패턴은 지원 직원이 쉽게 사용할 수 없습니다.
조직에서:
- 로그 및 사용자 정의 오류 메시지가 시스템 전체의 실행 경로에 통합됩니다.
조직에서: - 로그 및 사용자 정의 오류 메시지는 사용되지 않습니다.
모니터링 및 경고 조직에서:
- 경고는 사용자에게 사람이 개입해야 하는 시나리오에 대해 알리는 데만 사용됩니다. 기타 실패는 기록되고 보고할 수 있습니다.
- 응답할 수 있는 사용자에게 경고가 전송됩니다.
- 가능한 경우 잠재적인 실패 전에 경고가 전달됩니다.
조직에서:
- 후속 조치가 필요한지 여부와 상관없이 모든 유형의 실패가 발생하면 경고가 전송됩니다.
- 기술적 솔루션이 필요한 문제에 대한 경고가 비즈니스 사용자에게 전달됩니다.
- 경고는 이미 발생한 실패에 대한 응답으로만 전달됩니다.
문서:
- 프롬프트 튜닝 경고에 대한 항목 기준은 직접 및 간접 생성형 AI 사용자 의견 메트릭을 기반으로 정의됩니다.
문서:
- 생성형 AI 앱에 대한 프롬프트 튜닝 경고를 트리거하기 위한 기준은 정의되지 않았습니다.
## 연속성 계획 비즈니스 복구의 핵심은 비계획 이벤트로 인해 발생한 문제를 통해 사람과 시스템이 작동하는 방법에 중점을 둔 연속성 계획입니다. 비즈니스 연속성 계획(BCP)은 위기를 통해 프로세스를 계속 진행하는 방법에 대한 사람 중심의 보기를 가져옵니다. 무중단 계획의 기술적 측면은 BCP의 재해 복구 부분에 포함되어 있습니다. [기술 연속성](/docs/architect/ko-kr/well-architected/guide/resilient#기술-연속성)을 참조하십시오. 적절한 연속성 계획이 없으면 이제 조직이 위기 또는 시스템 중단 시 조치를 취하는 방법을 알 수 있으므로 전혀 조치를 취하지 않을 수 있습니다. 비효율적인 연속성 계획은 고객, 이해당사자, 비즈니스에 재앙적인 영향을 미칠 수 있습니다. 부정적인 이벤트 후 중요한 프로세스를 유지하거나 복구하지 않고 지나가는 모든 순간은 재정적 손상, 평판 손상, 직원 안전, 규정 준수까지 위험합니다. [Salesforce의 비즈니스 연속성 정의](/docs/architect/ko-kr/well-architected/guide/resilient#비즈니스-연속성), [기술 연속성 계획](/docs/architect/ko-kr/well-architected/guide/resilient#기술-연속성), [백업 및 복원 기능 구축과](/docs/architect/ko-kr/well-architected/guide/resilient#백업-및-복원-기능-구축) 같은 세 가지 영역에 노력을 집중하여 시스템에 더 나은 연속성 계획을 수립할 수 있습니다. ### 비즈니스 연속성 회사에 이미 BCP가 있을 수 있습니다. 이 경우 Salesforce가 포함되어 있는지 확인합니다. 회사에 BCP가 없는 경우 이해당사자와 협력하여 Salesforce 조직에 적용되는 BCP를 만듭니다. Salesforce는 많은 비즈니스 디비전 전반에서 고객 데이터 및 필수 비즈니스 프로세스에 대한 신뢰할 수 있는 소스로 사용되는 경우가 많습니다. 따라서 Salesforce가 BCP에서 수행하는 역할은 다른 시스템에서 수행하는 역할과 다를 수 있습니다. Salesforce가 복구에 우선 순위가 높은 여러 영역에 참여할 가능성이 높습니다. Salesforce 시스템에 대한 관련 비즈니스 연속성 계획 만들기: - **복구의 우선 순위를 명확히 하십시오**. [사고 대응](/docs/architect/ko-kr/well-architected/guide/resilient#사고-대응)에 대한 일반적인 접근 방식과 마찬가지로 위기 시점에서 시스템의 최우선 순위가 복구여야 합니다. 많은 비즈니스에 중요한 서비스가 Salesforce에서 실행됩니다. 이해당사자가 다양한 비즈니스 기능 및 성능을 복구하기 위한 올바른 우선 순위를 식별하도록 지원해야 합니다. 일반 프레임워크는 다음과 같습니다. - 필수 비즈니스 인프라를 안정화합니다. - 고객 서비스를 안정화합니다. - 직원 및 파트너 서비스를 안정화합니다. - **BCP에서 생태계 계산** Salesforce는 해당 환경의 유일한 시스템이 아닙니다. Salesforce와 통합되는 시스템, AppExchange 공급업체에서 설치된 솔루션, Salesforce의 데이터 또는 프로세스에 연결되는 기타 시스템과 관련하여 BCP의 간격을 파악해야 합니다. 배달 능력이 공급업체에 따라 달라질 경우 해당 공급업체에 연속성 계획에 대해 문의하십시오. 해당 기능을 평가하고 시스템을 계속 사용할 수 있는 방법을 계획합니다. - **BCP 문제를 테스트 전략에 통합**합니다. BCP에 대한 테스트 계획을 만들고 실행합니다. 프로세스 또는 사람과 관련된 BCP 영역을 테스트하는 것이 특히 중요하며, 이를 잊어버리는 경우가 많습니다. BCP의 관련 항목을 전체 ALM [테스트 전략](/docs/architect/ko-kr/well-architected/guide/resilient#테스트-전략)에 통합합니다. 서비스 점검 일정을 만들고 따라 테스트를 검토하고 계획이 최신 상태로 유지되는지 확인합니다. 연속성 계획을 위한 [패턴과 안티패턴](/docs/architect/ko-kr/well-architected/guide/resilient#연속성-계획-패턴-및-안티-패턴)은 Salesforce 솔루션에서 올바른 연속성 계획과 나쁜 연속성 계획을 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템의 위치를 식별합니다. 비즈니스 연속성을 정의하기 위한 Salesforce 도구에 대해 자세히 알아보려면 [Salesforce Resiliency 도구](/docs/architect/ko-kr/well-architected/guide/resilient#복구용-salesforce-도구)를 참조하십시오. ### 기술 연속성 기술 연속성의 목표는 시스템의 구성 요소에 대한 문제로 인해 비즈니스가 필수 운영을 유지할 수 없도록 하는 것입니다. Salesforce는 서비스 가용성 수준을 최대로 유지하고 문제에 대한 투명한 정보를 제공하는 것이 중요합니다. [Trust.salesforce.com](https://trust.salesforce.com/)에서 Salesforce 시스템 성능 및 문제에 대한 실시간 정보를 볼 수 있습니다. Salesforce에 구축된 설계자로서, 솔루션은 Salesforce가 전체 플랫폼에서 제공하는 사이트 신뢰성, 보안, 성능 기능을 활용할 수 있습니다. 그러나 Salesforce 솔루션의 전반적인 연속성은 Salesforce에서 제공하는 내장형 서비스 이상으로 확장됩니다. 아키텍처 관점에서 Salesforce 기술 연속성 계획은 대규모 기업 환경에 Salesforce가 어떻게 적합한지에 대한 질문과 답변으로 시작해야 합니다. Salesforce와 통합되는 시스템은 무엇입니까? Salesforce의 프로세스 또는 정보에 외부 시스템이 어떻게 의존합니까? Salesforce 조직에서 AppExchange 솔루션에 의존하는 프로세스 또는 기능은 무엇입니까? 사용자가 타사 ID 서비스 또는 SSO를 통해 Salesforce에 액세스합니까? Salesforce 시스템에서 더 나은 기술 연속성 구축: - **인프라를 평가합니다.** 기술 중단 또는 문제에 대한 가장 일반적인 해결 전략은 사고 중에 다시 사용할 수 있는 중복 서비스 또는 시스템 구축입니다. Salesforce에는 의도적으로 중복된 아키텍처가 있습니다. 즉, 고객의 시스템 및 서비스 사본을 다른 물리적 위치에 유지합니다. 필요한 경우 하나의 데이터 센터에서 다른 데이터 센터로 사용자 트래픽을 이동시킬 수 있는 사이트 전환 등 몇 가지 재해 복구 기법을 사용합니다. 의도적 중복을 구축해야 할 위치를 식별하려면 다음 질문을 하십시오. - \[X] 서비스에 대한 서비스가 중단되는 동안 어떤 일이 발생합니까? 해당 서비스에서 다른 서비스로 전환할 수 있습니까? - \[X]를 복구하는 데 시간이 얼마나 걸립니까? 고객에게 미치는 영향은 무엇입니까? 파트너에게 미치는 영향은 무엇입니까? 내부 팀에 미치는 영향은 무엇입니까? - [백업](/docs/architect/ko-kr/well-architected/guide/resilient#백업-및-복원-기능-구축) 및 빈도는 어떻습니까? 백업에서 비즈니스를 지원하는 데 필요한 데이터를 제공할 수 있습니까? - 공급업체에 종속성이 있습니까? BCP 계획은 무엇입니까? - **운영 지원 제공.** 운영 지원은 가능한 한 빨리 팀을 복구하고 실행하는 것입니다. 시스템이 산업 전체, 지역 전체 또는 글로벌 변화 등 예기치 않은 변화로 인한 수용력 요구 사항 및 수요의 상당한 증가를 처리할 수 있는 방법을 생각해 보십시오. 사이트 신뢰도 엔지니어링(SRE) 또는 지원 팀이 사고에 효과적으로 대응하기 위해 필요한 추가 리소스나 구체적인 절차가 BCP에 포함되어 있는지 확인합니다. 운영 지원에 대한 질문에는 다음이 포함됩니다. - 중단 시 기술 팀에 작업을 계속하기 위해 필요한 도구가 있습니까? 계획을 확인하거나 공백을 식별하기 위해 중단을 시뮬레이션했습니까? - 특정 지역에 재해가 발생한 경우 해당 지역에 대한 보장 계획이 있습니까? - 고객은 전 세계 고객입니까? 연중무휴 운영 여부 - 장애가 발생할 경우 적절한 개인에게 알릴 수 있는 적절한 [모니터링 및 경고](/docs/architect/ko-kr/well-architected/guide/resilient#모니터링-및-경고)가 있습니까? - **복구 전술을 자동화하고 테스트합니다.** 문제를 해결한 후 발생한 위치와 해결 방법을 식별합니다. 가능한 경우 조치를 기반으로 복구 전술을 자동화하고 프로세스 문제를 조정합니다. 많은 회사가 서비스 하위 집합에 대한 사고 시뮬레이션을 예약하여 시스템 복원을 테스트합니다. 예를 들어 시스템 관리자 계정이 잠겨 있거나 손상되었거나 AppExchange 공급자의 중단 또는 문제를 시뮬레이션할 수 있습니다. [사고 대응](/docs/architect/ko-kr/well-architected/guide/resilient#사고-대응)을 참조하십시오.) 테스트 및 자동화가 서비스를 더 빠르게 복원하는 데 도움이 되는 방법에 대한 질문은 다음과 같습니다. - 사고 시뮬레이션을 얼마나 자주 예약하고 실행합니까? - 서비스를 안정적인 상태로 복원하는 데 걸리는 시간을 알고 있습니까? - 안정적인 배달 프로세스가 있습니까? - 페일오버 및 복구를 자동화할 수 있는 위치를 알고 있습니까? 사고 후 검토에서 나온 모든 항목을 다른 개발 항목과 마찬가지로 처리합니다. 우선 순위를 지정하고 작업할 수 있도록 계획 시스템에 추가합니다. 연속성 계획을 위한 [모형 및 비모형](/docs/architect/ko-kr/well-architected/guide/resilient#연속성-계획-패턴-및-안티-패턴)은 Salesforce 솔루션에서 올바른 기술 연속성 계획과 나쁜 기술 계획을 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템의 위치를 식별합니다. 기술 연속성 계획을 위한 Salesforce 도구에 대해 자세히 알아보려면 [Salesforce Resiliency 도구](/docs/architect/ko-kr/well-architected/guide/resilient#복구용-salesforce-도구)를 참조하십시오. ### 백업 및 복원 기능 구축 백업된 데이터 또는 메타데이터 사본을 복원하면 조직이 마지막으로 알려진 안정 상태로 되돌아갈 수 있습니다. 재해적인 시스템 오류 또는 서비스 중단 시 장애 복구 시스템을 제공할 수도 있습니다. 데이터 및 메타데이터를 정기적으로 백업하고 암호화된 백업 복사본을 보안 위치에 저장하면 아키텍처에 추가적인 복원 수준이 추가됩니다. 백업 및 복원 전략이 없으면 악의적으로 손상되거나 결함이 실수로 프로덕션으로 들어오거나 대용량 데이터 로드 중 실패로 인해 프로덕션 데이터가 손상된 경우 정리된 버전의 프로덕션 데이터 및 메타데이터를 복원할 수 없습니다. 이러한 시나리오 중 하나로 인해 비즈니스에 중요한 프로덕션 데이터가 손상되거나 영구적으로 손실될 수 있습니다. 백업 및 복원 기술을 설정하면 대용량 데이터를 완화하는 전략 및 규정 준수 관련 유지 정책을 준수하는 등 연속성 계획 외에도 다양한 장점을 제공합니다. Salesforce 솔루션의 백업 및 복원 전략에 대한 연속성 보장: - **시작해요.** 적절한 백업 및 복원 전략을 수립하기 위한 첫 단계는 먼저 전략을 수립하는 것입니다. 조직의 모든 데이터 및 메타데이터를 야간으로 백업하는 것처럼 간단한 작업을 수행해도 비즈니스가 재해 시 중요한 정보 또는 기능을 잃지 않도록 할 수 있습니다. - **백업에 대한 액세스를 제한합니다.** 시스템 관리자만 데이터의 백업 복사본에 액세스해야 하는 사용자입니다. 액세스 제한으로 인해 비즈니스 사용자가 조직에서 볼 권한이 없는 백업 사본의 레코드를 볼 수 없습니다. - **정기적으로 복원 프로세스를 테스트하십시오.** 어떤 백업 및 복원 전략을 구현하든 상관없이 전체 또는 부분 복제 sandbox에서 복원 프로세스를 정기적으로 [테스트하십시오](/docs/architect/ko-kr/well-architected/guide/resilient#테스트-전략). - **백업 및 복원 전략을 데이터 아카이빙 전략과 일치시킵니다.** 레코드가 보관되거나 시스템에서 제거될 때 백업 또는 보관에서 수행할 작업을 결정합니다. [데이터 볼륨](/docs/architect/ko-kr/well-architected/guide/reliable#데이터-용량) 참조). 데이터 용량이 너무 크므로 다음 백업을 실행하기 전에 전체 백업을 완료할 시간이 없을 경우 보다 세부적인 백업 전략이 필요할 수 있습니다. 또한 조직의 데이터가 너무 자주 변경되어 업데이트가 조직에 중요한 임무가 될 경우 보다 세부적인 백업 전략이 필요할 수 있습니다. 보다 세분화된 백업 전략 만들기: - **백업 범위를 특정 개체로 지정**합니다. 이 전략은 다른 시간 간격으로 다른 개체의 레코드를 백업하는 작업을 수행합니다. 하위 개체를 상위 개체와 동일한 간격으로 백업해야만 데이터 일관성을 유지할 수 있습니다. - **타임박스** **부분 백업** 이 전략은 전체 백업(모든 데이터 및 메타데이터)과 부분 백업(마지막 백업 이후에 추가되거나 변경된 메타데이터 및 레코드만)을 구분하는 작업을 포함합니다. **\* 전체 백업 수행을 중지하지 마십시오**. 데이터 용량으로 인해 실행 시간이 길어도 전체 백업을 완전히 제거해서는 안 됩니다. 대용량 데이터의 경우 정기적이지만 자주 사용하지 않는 전체 백업(예: 주간 백업)을 계획하십시오. 또한 부분 또는 개체별 백업(예: X 시간마다 야간 백업 또는 백업)을 더 자주 수행할 수 있습니다. 이 접근 방식을 통해 복원 프로세스에 사용할 가장 완전하고 정확한 데이터 집합을 유연하게 재구성할 수 있습니다.\* 연속성 계획을 위한 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/resilient#연속성-계획-패턴-및-안티-패턴)은 Salesforce 솔루션에서 올바른 백업 및 복원 기능과 나쁜 백업 및 복원 기능을 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템의 위치를 식별합니다. ### Salesforce 백업 및 복구 자체 획득에서 자체 복구를 포함하는 통합 Salesforce 솔루션인 Salesforce 백업 및 복구는 중요한 데이터를 손실 또는 손상으로부터 보호합니다. 고안정성과 설정이 간편하며 항상 사용할 수 있는 솔루션은 비즈니스 연속성과 데이터 복원성을 보장하고 규정을 준수하는 과정을 간소화합니다. Salesforce 백업 및 복구를 사용하여 데이터 손실을 방지하고, 데이터 사고로부터 신속하게 복구하고, 전반적인 데이터 관리 전략을 간소화합니다. 중요한 규제된 데이터에 대한 백업 정책을 만들고 클릭 몇 번으로 해당 데이터를 복원할 수 있습니다. #### 자동 백업 배포 일일 자동 백업은 메타데이터, Sandbox, 관리 패키지 데이터, 파일 첨부 파일 등을 포함하여 모든 중요한 조직 데이터를 보호합니다. 필요한 만큼 자주 백업을 실행하여 복구 지점 목표(RPO) 목표를 달성하고 배포를 보호합니다. 백업에 항상 액세스할 수 있으며 안전하고 규정을 준수하는 방식으로 저장됩니다. 더욱 민감한 데이터 또는 트랜잭션 데이터에도 연속 데이터 보호를 사용할 수 있으므로 빠르게 변화하는 중요 정보를 빠르게 복구할 수 있습니다. #### 데이터 사전 모니터링 이메일로 직접 전송되는 사전 경고를 사용하여 일반적이지 않은 데이터 활동, 데이터 손실, 손상을 감지합니다. 실시간 경고를 수신하여 통계 이상값을 식별하거나 일반적이지 않은 데이터 활동을 알리는 규칙을 만들어 사고를 그 어느 때보다 빠르게 감지할 수 있습니다. #### 정확하고 빠른 복원 Salesforce 백업 및 복구는 변경 사항에 대한 세부적인 가시성을 제공하여 신속하게 영향받는 데이터를 식별하고 복원할 수 있도록 복구 속도를 높입니다. 시각적 그래프와 같은 도구는 원치 않는 변경 사항을 강조 표시하고, 사용하기 쉬운 복구 기능은 영향받는 개체, 필드, 레코드를 정확하게 복원합니다. #### 백업 사용 연장 도구를 사용하면 분석, 감사, 규정 준수에 백업을 사용할 수 있으며, 검색 가능한 내역 데이터를 제공하고, 과거 데이터의 가시성을 위한 열려 있는 검색 기능을 사용하고, 외부 분석 또는 창고를 위한 내보내기 기능을 사용할 수 있습니다. 이렇게 하면 추가 Salesforce API가 필요하지 않은 백업 용도가 변경됩니다. #### 통합 백업 데이터 관리 백업 및 복구는 모든 백업, 관리, 운영, 규정 준수를 통합하기 위한 단일 콘솔을 제공합니다. 이 콘솔을 사용하면 모든 프로덕션 조직 및 Sandbox에 대한 백업에 액세스, 관리, 사용자 정의, 모니터링할 수 있습니다. 또한 데이터 주체 요청을 실행하여 백업 데이터 규정을 준수하고 백업 일정, 빈도, 보존 정책을 완벽하게 제어할 수 있습니다. #### Salesforce 백업 및 복구의 주요 사용 사례 - **데이터 사고의 영향 완화** Salesforce 백업 및 복구를 사용하면 사용자가 영향을 받는 레코드를 사고 전 상태로 되돌릴 수 있으므로 사이버 공격 또는 악의적인 내부 또는 외부 활동과 같은 데이터 사고를 완화할 수 있습니다. 백업 및 복구의 내보내기 기능은 사용자의 중요 데이터에 대한 지속적인 액세스 및 유용성을 보장합니다. - **지연 데이터 손실을 방지**합니다. 인간 오류는 여전히 데이터 손실의 주요 원인입니다. 백업 및 복구는 이러한 오류에 대한 정확하고 빠른 솔루션을 제공합니다. - 데이터 규정 준수 및 법적 요건을 더욱 **쉬워집니다**. Salesforce 백업 및 복구는 공유 책임 모델을 지원하므로 백업 데이터의 대량 분실 또는 데이터 정정을 위한 셀프 서비스 기능을 활성화합니다. 백업 및 복원용 Salesforce 도구에 대해 자세히 알아보려면 [Salesforce Resiliency 도구](/docs/architect/ko-kr/well-architected/guide/resilient#복구용-salesforce-도구)를 참조하십시오. ### 연속성 계획 패턴 및 안티 패턴 이 표는 조직에서 찾거나 구축할 패턴을 선택한 다음, 방지하거나 수정할 항 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/adaptable-continuity-planning)에서 연속성 계획을 위한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
비즈니스 연속성 당사에서:
- 우선 순위가 가장 높은 비즈니스 기능 및 기능을 가능한 한 빨리 영향을 미치지 않도록 초점을 맞춘 "복구 우선" 사고 방식을 채택합니다.
- BCP 테스트 계획 검토에 대한 서비스 점검 일정이 있습니다.
당사에서:
- 사고 관리를 위한 유일한 방법은 "문제 수정" 사상입니다.
- BCP 테스트 계획은 정기적으로 새로 고쳐지지 않습니다.
문서:
- Salesforce를 사용할 수 없게 될 경우 데이터를 계속 처리하거나 분류하는 단계, BCP 사용을 트리거하는 이벤트 목록, BCP 테스트 단계 및 간격이 포함된 BCP가 있습니다.
- BCP에는 업스트림 및 다운스트림 시스템과 종속성이 포함됩니다.
문서:
- BCP가 없거나 완료되지 않거나 Salesforce만 포함됩니다.
테스트 계획:
- 프로세스 및 사람과 관련된 BCP 영역이 고려됩니다.
테스트 계획:
- 프로세스 및 사람과 관련된 BCP 영역은 고려되지 않습니다.
기술 연속성 당사에서:
- 의도적 중복 또는 페일오버 시스템을 구축해야 하는지 평가했습니다.
- 사고 복구 전술은 가능한 경우 자동화됩니다.
당사에서:
- 의도적인 중복 또는 장애 복구 시스템의 필요성을 평가하지 않았습니다.
- 사고 복구 전술은 모두 수동입니다.
문서:
- BCP는 팀이 사고에 효과적으로 대응하기 위해 필요한 추가 리소스 또는 절차를 고려합니다.
문서:
- BCP에는 운영 지원 요구 사항이 포함되어 있지 않습니다.
백업 및 복원 문서:
- 데이터와 메타데이터 모두에 대한 백업 및 복원 전략이 있습니다.
문서:
- 백업 및 복원 전략이 없거나 해당하는 경우 데이터에만 또는 메타데이터에만 적용되며 둘 다 아닙니다.
회사에서:
- 백업은 권한이 있는 사용자만 액세스할 수 있는 안전한 위치에 보관됩니다.
- 테스트 계획 및 테스트 로그에 데이터 복원이 1년에 2회 이상 전체 또는 부분 복사 sandbox에서 테스트되는 것이 표시됩니다.
회사에서:
- 백업은 사람이 읽을 수 없습니다.
- 권한이 없는 비즈니스 사용자가 액세스할 수 있는 위치에 백업이 저장됩니다.
- 데이터 복원 프로세스가 없거나 데이터 복원 프로세스가 테스트되지 않았습니다.
## 복구용 Salesforce 도구
도구설명응용 프로그램 수명 주기 관리사고 대응연속성 계획
Apex 해머 테스트 현재 릴리스와 새 릴리스의 Salesforce Apex 테스트에 대해 알아봅니다. X
Apex Stub API 모의 프레임워크를 구축하여 테스트를 간소화합니다. X
백업 및 복구 데이터 손실을 방지하기 위해 백업을 자동으로 생성합니다. X
대형 객체 플랫폼에 대용량 데이터를 저장하고 관리합니다. X
필드 내역 추적 필드 내역을 추적하고 표시합니다. X
조직을 위한 채택 및 보안 인사이트 새 창에서 링크 열기 조직에서 Lightning Experience 채택 및 사용 현황을 모니터링합니다. X
대량 데이터 로드 작업 관리 대량 API를 사용하여 대량 레코드의 업데이트를 만들거나 삭제합니다. X
실시간 이벤트 모니터링 이벤트 관리 이벤트 모니터링 스트리밍 및 저장소 설정을 관리합니다. X
데이터 및 스토리지 리소스 Salesforce 조직의 저장소 제한 및 사용량을 확인합니다. X
모니터 디버그 로그 로그를 모니터링하고 플래그를 설정하여 로깅을 트리거합니다. X
로그인 포렌식으로 로그인 활동 모니터링 ID 사기를 나타낼 수 있는 동작을 식별합니다. X
설정 감사 내역을 사용하여 설정 변경 사항 모니터링 관리자가 적용한 최근 설정 변경 사항을 추적합니다. X
교육 내역 모니터링 사용자가 수강한 Salesforce 교육 강좌를 봅니다. X
모니터링 백그라운드 작업 조직의 배경 작업을 모니터링합니다. X
예약된 작업 모니터링 보고서 스냅샷, 예약된 Apex 작업 및 대시보드 새로 고침을 봅니다. X
확장형 테스트 시스템 성능을 테스트하고 결과를 해석합니다. X
사전 예방적 모니터링 Salesforce 모니터링 서비스를 사용하여 중단을 최소화합니다. X
Salesforce Data Mask Sandbox에서 데이터를 자동으로 마스킹합니다. X
시스템 개요 페이지 조직의 사용 데이터 및 제한을 봅니다. X
force:lightning:lint 사용 Salesforce CLI 통해 코드를 분석하고 유효성을 검사합니다. X
## 복원과 관련된 자원
자원설명응용 프로그램 수명 주기 관리사고 대응연속성 계획
7 성능 및 규모 테스트의 안티 패턴 성능 및 규모 테스트에서 일반적인 안티 패턴을 피하십시오. X
복잡한 Salesforce 앱에서 성능 및 확장 핫스팟 분석 조직에서 성능 및 확장성 문제를 해결하는 방법을 알아봅니다. X
재해 복구 계획 구축(Trailhead) 재해 복구 계획을 구축합니다. X
비즈니스 연속성은 백업 및 복원 이상 BCP를 포괄적으로 살펴봅니다. X
설계 표준 템플릿 조직에 대한 설계 표준을 만듭니다. X
Salesforce의 진단 및 모니터링 도구 구현 품질 및 성능을 향상하는 방법에 대해 알아봅니다. X
무중단 업무 운영 계획의 지침 효과적인 BCP를 기반으로 하는 기본 원칙을 검토합니다. X
Salesforce에서 확장형 테스트 방법 규모 테스트 수명 주기의 5단계를 살펴봅니다. X
성능 테스트 소개 성능 테스트 방법을 개발하는 방법을 알아봅니다. X
조직 모니터링 셀프 서비스 모니터링 옵션에 대해 알아봅니다. X
테스트 전략 템플릿 규모 및 성능 테스트 계획을 만들고 사용자 정의합니다. X
테스트 전략 템플릿 테스트 전략이 완료되었는지 확인합니다. X
소스 중심 개발 이해(Trailhead) 패키지 개발 및 스크래치 조직에 대해 알아봅니다. X
## 의견을 알려주십시오. Salesforce Well-Architected의 관련성을 유지할 수 있도록 도와주십시오. 이 콘텐츠에 대한 사용자 의견을 제공하려면 [ 설문 조사](https://sfdc.co/bxNtvh)를 수행하고 다음에 원하는 내용을 알려주십시오. > [여기에](/docs/architect/ko-kr/well-architected/guide/contributors) 업데이트 일정에 대해 알아보십시오. # 소개 **쉬운** Salesforce 솔루션은 빠르게 가치를 제공합니다. **쉬움**을 위해 잘 설계된 솔루션은 의도적이고 자동화되고 참여도가 뛰어납니다. **의도적** 솔루션은 즉시 시간에 따라 비즈니스 가치를 제공합니다.
**자동화된** 솔루션을 통해 비즈니스가 작업을 더 빠르고 규모에 맞게 수행할 수 있습니다.
**연락성 있는** 솔루션은 사용자를 만족시키고 채택을 촉진합니다.
**쉬운** 아키텍처를 만드는 것은 아키텍처에게 복잡한 문제를 야기할 수 있습니다. Salesforce Platform의 유연성과 다양한 [자동화 도구](/docs/architect/ko-kr/well-architected/guide/automated#자동화와-관련된-도구) 덕분에 구현 세부 사항은 각 Salesforce 조직에 따라 크게 다를 수 있습니다. **쉬운** 아키텍처는 보다 지능적인 (그리고 어려운) 협상 분석 및 이해당사자와의 대화가 필요할 수 있습니다. 솔루션 설계는 프로그래머에게 복원 가능하고 신뢰할 수 있지만 조직 관리자가 소유하거나 유지 관리하기 쉽지는 않습니다. 이러한 솔루션은 **쉬운** 일에 잘 설계되지 않을 것입니다. **쉬운** 솔루션을 얻으려면 비즈니스 우선 순위를 깊고 정확하게 이해해야 합니다. 기본 설정, 요구 사항, 일상적인 작업 현실 등 사용자를 이해해야 합니다. 또한 배달 및 서비스 점검 팀의 기술(및 기술 공백)을 이해해야 합니다. 다양한 툴링 옵션 및 설계 패턴을 반복하여 배달 및 서비스 점검 팀을 위해 관리할 수 있는 동시에 비즈니스에 가치를 제공하는 의도적인 솔루션을 도출하고 작업을 더 빠르고 대규모로 자동화하며 사용자에게 진정한 참여를 제공해야 합니다. 다음 섹션은 **Easy** 솔루션 아키텍처의 핵심 고려 사항에 대한 자세한 지침을 제공합니다. ## 간단한 개요
의도
의도적인 솔루션은 즉시 시간에 따라 비즈니스 가치를 제공합니다. 의도적인 아키텍처는 전략적으로 계획 및 전달되며, 효과적으로 유지 관리할 수 있으며, 사람이 쉽게 읽고 이해할 수 있습니다.
전략 기존성 읽기
우선 순위 지정
로드맵
거버넌스
표준 및 사용자 정의 비교
기술 부채
설계 표준
문서
자동
자동화된 솔루션을 사용하면 비즈니스에서 작업을 더 빠르고 대규모로 수행할 수 있습니다. 정상적인 자동화를 통해 반복적인 수동 작업 또는 복잡한 데이터 입력에 소요되는 시간을 줄입니다.
효율성 데이터 무결성
프로세스 설계
운영 논리
KPI
데이터 처리
오류 처리
참여
참여형 솔루션은 사용자의 만족도를 높이고 채택을 촉진합니다. 참여를 위한 아키텍처는 직관적이고 유용한 사용자 환경을 만드는 것을 의미합니다.
간소화 도움말
응용 프로그램 복잡성
양식
양식 요소
알림 및 Messaging
앱 내 지침
인정 및 보상
> [여기에](/docs/architect/ko-kr/well-architected/guide/contributors) 업데이트 일정에 대해 알아보십시오. ## 소개 신뢰할 수 있는 솔루션은 효율적이고 신뢰할 수 있도록 작동합니다. 사용 가능하며 일관적으로 수행할 수 있으며 성장하는 비즈니스를 지원하기 위해 확장할 수 있습니다. 신뢰할 수 있는 시스템은 오류가 발생하지 않으며 예상대로 동작하며 적시에 결과를 제공합니다. 반대로 신뢰할 수 없는 시스템은 느리거나 예상대로 동작하지 않거나 중요한 시기에 실패합니다. 신뢰할 수 없는 시스템은 부정확한 정보를 제공하므로 이해당사자가 비즈니스 결정을 위해 시스템을 Trust 수 없습니다. 시스템 신뢰도는 상수하지 않습니다. 성장에 맞게 설계되지 않은 경우 현재 신뢰할 수 있는 시스템이 신뢰할 수 없게 될 수 있습니다. 신뢰할 수 없는 시스템은 비용이 많이 드는 서비스 점검, 리팩터링 또는 재구현이 필요할 수 있으므로 전략적 프로젝트에서 자금을 방출할 수 있습니다. [가용성](/docs/architect/ko-kr/well-architected/guide/reliable#가용성), [성능](/docs/architect/ko-kr/well-architected/guide/reliable#성능) 및 [확장성](/docs/architect/ko-kr/well-architected/guide/reliable#확장성)과 같은 세 가지 원칙에 초점을 맞추어 Salesforce 솔루션의 신뢰성을 향상합니다. [Salesforce의 확장성 제품군](https://www.salesforce.com/platform/application-scaling-performance-testing/)은 설계자가 안정적인 구현을 실행할 수 있도록 지원하는 기본 기능을 제공합니다. ## 가용성 가용성은 시스템이 작동하는 시간의 비율을 측정합니다. Salesforce Platform은 대부분의 [인프라급](https://trust.salesforce.com/) 가용성 문제를 처리합니다. 그러나 플랫폼에서 구축하고 고객이 경험한 솔루션의 가용성은 공유 책임입니다. Salesforce의 [고가용성](https://trust.salesforce.com/en/#systemStatus)에도 불구하고 서비스 중단의 위험은 결코 0이 아닙니다. 설계자는 계획된 서비스 점검 또는 예상치 못한 상황과 같은 Salesforce 서비스 중단에 대비해야 합니다. 서비스 중단 외에도 고성능을 유지하고 비즈니스를 성장시키는 방법을 고려하십시오. 아키텍처 선택 항목의 범위를 좁히면 장기 가용성 문제가 발생할 수 있습니다. 솔루션이 구축되기 _전에_ 설계 단계에서 가용성에 대해 생각해 보십시오. 가용성에 대한 아키텍처를 지연하는 시간이 길수록 장기적으로 가용성 문제의 실제 비용이 더 높습니다. 잠재적인 위험을 완화하려면 테스트 환경에서 Salesforce 확장형 테스트 사용하십시오. 해당 환경에서는 프로덕션에서 코드를 배포하기 전에 프로덕션 규모에서 테스트할 수 있습니다. 설계자는 비즈니스 언어를 사용하여 비즈니스 이해당사자의 기술적 우려 사항을 구축하고 가용성 작업의 우선 순위를 지정합니다. 잠재적인 위험을 완화하려면 테스트 환경에서 Salesforce 확장형 테스트 사용하십시오. 해당 환경에서는 프로덕션에서 코드를 배포하기 전에 프로덕션 규모에서 테스트할 수 있습니다. [위험 관리](/docs/architect/ko-kr/well-architected/guide/reliable#위험-관리) 및 [실패 완화](/docs/architect/ko-kr/well-architected/guide/reliable#실패-완화)를 통해 Salesforce 솔루션의 가용성을 높일 수 있도록 설계할 수 있습니다. ### 위험 관리 Salesforce 아키텍처의 컨텍스트에서 위험을 관리하려면 시스템 운영, 직원, 파트너, 고객을 비롯한 사용자, 비즈니스 프로세스에 대한 잠재적인 위험을 식별해야 합니다. 종종 공식적인 위험 분석 프로세스는 프로젝트 관리자의 책임에 속합니다. 설계자는 위험 분석이 기술 및 비즈니스 이해당사자의 우려 사항을 적절하게 나타내는지 확인합니다. 또한 프로덕션 피크 핫스팟을 기반으로 확장 테스트해야 하는 비즈니스에 중요한 사용 사례를 식별할 책임이 있습니다. 위험 관리에서 가장 큰 장애물 중 일부는 충분한 시간을 할애하고 고려하지 않는 것 때문입니다. 팀은 종종 위험 평가를 건너뛰거나 데이터 무결성 위험을 완화하는 데 중요한 부분인 [백업 및 복원](/docs/architect/ko-kr/well-architected/guide/resilient#백업-및-복원-기능-구축) 솔루션을 포괄적인 위험 평가 및 완화와 결합합니다. Salesforce 솔루션에 대한 위험을 평가하려면 다음 방법을 사용합니다. - **위험 평가 프레임워크 사용** 일부 대기업에는 이미 관련 위험 행렬이 있을 수 있습니다. 위험을 분류하는 방법, 수집할 정보의 종류, 해결을 위해 필요한 사항 등을 결정하는 데 사용합니다. 위험 평가 프레임워크가 없는 경우 신뢰할 수 있는 소스에서 찾고 사용하십시오. - **고객의 관점에서 영향 심각도 및 위험 범주 평가** Proactive Monitoring 및 Scale Center는 구성 가능한 경고 및 대시보드를 제공합니다. 성능 및 확장성 위험을 지속적으로 평가하고 수동 체크리스트에 대한 의존도를 줄입니다. 고객 Trust 인식은 모든 비즈니스의 핵심입니다. 비즈니스 영향 측면에서 고객에게 도달하는 문제에 대한 위험은 일반적으로 그렇지 않은 문제에 대한 위험보다 높습니다. 고객은 내부 팀과 같은 방식으로 위험을 생각하거나 인식하지 못할 수 있습니다. 고객이 계정에 로그인할 수 없는 경우 문제의 근본 원인을 신경쓰지 않을 수 있습니다. 즉각적인 자신의 경험을 가장 신경쓰고 있습니다. - **위험 우선 순위 지정** 이상적으로 모든 위험은 견고한 경감 및 대응 계획과 연결됩니다. 실제로는 시간이 지나면서 해결해야 하는 격차가 있습니다. "이전에 가치 제공 및 반복" 접근 방식을 채택하는 것이 중요합니다. 귀하 및 배달 및 서비스 점검 팀은 지정된 시간에 충분한 작업량만 할 수 있습니다. Salesforce에서 일반적인 표현식은 "모든 것이 중요하다면 아무것도 중요하지 않습니다."입니다. V2MOM을 사용하여 회사 전체, 팀 전반, 개인별로 작업의 우선 순위를 지정하고 조율합니다. (Trailhead에서 V2MOM에 대해 [자세히 알아볼 수 있음](https://trailhead.salesforce.com/content/learn/modules/manage_the_sfdc_organizational_alignment_v2mom/msfw_oav2m_writing_a_v2mom).) 위험 평가를 사용하면 이해당사자와 협력하여 가장 중요한 위험 관리 작업의 우선 순위를 지정하고 참여할 수 있습니다. 확장형 테스트 - 테스트 계획 생성을 사용하여 확장형 테스트를 사용하여 위험을 파악하여 우선 순위를 지정하고 위험을 완화합니다. 사전 Proactive Monitoring 사용하여 조기 가용성 위험을 감지합니다. API 요청 제한 증가, 행 잠금 오류 또는 동시 Apex 실패와 같은 변칙을 표시하여 문제가 서비스 중단으로 에스컬레이션되기 전에 실행 가능한 인사이트를 제공합니다. 가용성 패턴 [및 안티 패턴](/docs/architect/ko-kr/well-architected/guide/reliable#가용성-패턴-및-안티-패턴)은 Salesforce 솔루션 내에서 적절한 리스크 관리와 부적절한 리스크 관리를 보여줍니다. 패턴을 사용하여 구축하기 전에 디자인을 확인하거나 시스템의 리팩터링 영역을 식별합니다. 위험 관리와 관련된 Salesforce 도구에 대해 자세히 알아보려면 [Salesforce 신뢰도 도구](/docs/architect/ko-kr/well-architected/guide/reliable#신뢰성을-위한-salesforce-도구)를 참조하십시오. ### 실패 완화 장애 지점은 시스템을 신뢰할 수 없게 만드는 취약점입니다. 성공적인 실패 완화는 잠재적인 모든 실패 지점을 찾는 것이 아닙니다. 대신 서비스 점검 및 지원 팀이 효율적으로 대응할 수 있도록 오류 지점을 빠르게 분류하고 우선 순위를 지정해야 합니다. [사고 대응](/docs/architect/ko-kr/well-architected/guide/resilient#사고-대응)을 참조하십시오. 더 나은 실패 완화 전략 개발: - 사람, 프로세스 및 기술 측면에서 장애 지점에 대한 트리거를 **분류합니다**. 사람, 프로세스 및 기술 측면에서 위험을 분류하는 것과 마찬가지로 우선 순위가 높은 실패 지점이 트리거되는 방법에 같은 생각을 적용합니다. 이 접근 방식을 사용하면 잠재적인 실패 트리거를 식별하고 해당 트리거에 대한 응답을 개발하고 구성할 수 있습니다. 트리거가 분류되는 방식을 기반으로 유사한 경감 접근 방식을 사용하여 가시적으로 서로 다른 실패 트리거를 완화할 수도 있습니다.
트리거 분류/유형 경감
사람 정책
프로세스 플레이북, 연속성 계획
기술 중복
- **기본, 중간 및 성숙한 완화가 어떻게 보이는지 확인하십시오.** 완화 전략을 구축하는 데 시간이 걸릴 것입니다. 완화 수준을 정의하여 사용자 및 팀이 즉시 제어할 수 있는 위치와 시간에 따른 노력을 집중하는 방법을 파악할 수 있습니다. 가능한 한 빨리 경감 접근 방식에서 자동화를 사용할 기회를 찾으십시오. 이 접근 방식을 실제로 보여주기 위해 이 예는 사람 중심 트리거와 기본, 중간, 성숙 수준의 정책 기반 경감 방식을 보여줍니다.
트리거 경감 기본 중간 성숙
신규 또는 탈퇴 직원에 대한 사용자 액세스 변경 사항 서비스 수준 계약(SLA) 및 사용자 프로비저닝 또는 프로비저닝 해제 요구 사항 수동 변경 시 SLA에 따라 사용자를 수동으로 프로비저닝 및 프로비저닝 해제합니다. 예약된 변경 사항에 대한 SLA에 따라 예약된 작업을 통해 사용자 변경 사항을 처리합니다. SSO/IDM 솔루션을 통해 사용자의 프로비저닝 및 프로비저닝 해제를 자동화합니다.
아키텍처 플레이북 및 연속성 계획을 사용하는 것 외에도 Proactive Monitoring 사용하십시오. 사전 Proactive Monitoring 사용하면 로그인 실패, CPU 시간 초과 예외 또는 동시 API 요청 오류와 같은 실패 트리거에 대한 실시간 경고를 설정할 수 있습니다. 이 경고 접근 방식은 기술적 이해당사자와 비즈니스 이해당사자가 실패의 영향을 줄이기 위해 적시에 정보를 받을 수 있도록 하여 장애 완화 효과를 높입니다. [가용성 패턴 및 안티 패턴](/docs/architect/ko-kr/well-architected/guide/reliable#가용성-패턴-및-안티-패턴)은 Salesforce 솔루션에서 올바른 장애 완화 및 저하를 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 시스템에서 리팩터할 위치를 식별합니다. 오류 완화용 Salesforce 도구에 대해 자세히 알아보려면 [신뢰할 수 있는 도구](/docs/architect/ko-kr/well-architected/guide/reliable#신뢰성을-위한-salesforce-도구)를 참조하십시오. ### 가용성 패턴 및 안티 패턴 이 표는 조직에서 찾거나 구축할 패턴을 선택한 다음, 방지하거나 수정할 항 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/trusted-availability)에서 추가 패턴의 가용성을 확인하십시오.
패턴 안티 패턴
위험 관리 당사에서:
- 기존의 위험 평가 프레임워크가 사용되고 있습니다.
- 위험은 사람, 프로세스 및 기술 영역으로 분류됩니다.
당사에서:
- Salesforce의 위험 평가 프레임워크는 임시입니다.
- 위험은 명확하게 식별되지 않습니다.
문서:
- 위험 심각도가 고객 영향을 기반으로 분류되고 평가됩니다.
- 위험 완화 및 대응 계획의 우선 순위가 지정됩니다.
문서:
- 위험 심각도 또는 범주를 평가할 때 고객 관점은 고려되지 않습니다.
- 위험 완화 및 대응 계획은 상상할 수 있는 모든 위험을 포착하도록 시도합니다.
실패 완화 조직에서:
- 실패 지점 트리거 및 해당 경감 계획은 사람, 프로세스 및 기술별로 분류됩니다.
- 완화 제어가 즉시 적용되고 시간이 지남에 따라 성숙하며 가능한 한 빨리 자동화를 통합합니다.
- 최적의 확장성을 보장하기 위해 프로덕션에 변경 사항이 릴리스되기 전에 포괄적인 테스트 및 최적화가 완료됩니다.
- 비즈니스에 중요한 이벤트 전에 SLA에 따라 규모 테스트 및 최적화가 수행됩니다.
조직에서:
- 실패 지점 트리거는 분류되지 않습니다. 경감 접근 방식은 존재하지 않거나 임시로만 사용됩니다.
- 완화 제어는 다시 검토하거나 개선되지 않습니다.
- 자동화는 완화에 사용되지 않습니다.
모니터링 및 관찰 가능성 조직에서:
- 검사 및 변칙 감지의 경우 Proactive Monitoring 활성화되어 있습니다.
- 지속적인 가시성을 위해 Proactive Monitoring 경고가 Scale Center와 통합되어 있습니다.
조직에서:
- 수동 건강 검사만 수행되며, 지속적인 모니터링이 적용되지 않습니다.
## 성능 시스템 아키텍처 성능은 시스템의 처리량(처리량) 및 응답 속도(대기 시간)를 측정합니다. 일반적으로 프로덕션 테스트 및 모니터링을 통해 시스템의 성능을 이해할 수 있습니다. 성능이 뛰어난 시스템은 예상되는 모든 수요 수준에서 프로세스를 적시에 완료합니다. 성능이 낮으면 대기 시간이 높고 처리량이 낮아 생산성이 저하되고 사용자 불만이 증가합니다. 고객의 Trust 잃고 재정적 손실을 야기할 수 있으므로 성능 문제를 해결해야 합니다. 처리량 및 대기 시간을 최적화하여 솔루션의 성능을 향상할 수 있습니다. > 참고: 처리량 및 대기 시간 최적화는 시스템 처리 및 응답성을 개선하는 데 필수적인 측면입니다. 그러나 전체 시스템 성능은 [규모](/docs/architect/ko-kr/well-architected/guide/reliable#확장성)에 맞게 얼마나 잘 설계하는지에 따라 달라집니다. 설계에서 두 치수를 모두 고려해야 합니다. ### 처리량 Salesforce 아키텍처의 컨텍스트에서 처리량은 시스템에서 지정된 시간 간격 내에 완료할 수 있는 동시 요청의 수입니다. 처리량에 맞게 설계 및 최적화된 고객의 Salesforce 솔루션은 Salesforce Platform의 내장된 [관리자 제한](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) 내에서 더 잘 작동합니다. Salesforce에서 처리량을 최적화하는 것은 시스템의 작업 부하를 정확하게 계산하고 증가를 계획하는 것부터 시작합니다. 시스템에 대한 요구 사항에 대한 정확한 예측이 없으면 시스템의 처리량 기능으로 잠재적인 문제를 파악할 수 없습니다. 작업 부하에 대해 생각할 때 다음 세 가지 차원을 고려하십시오. - 주어진 기간 동안 시스템에서 처리해야 하는 **트랜잭션 수** - 동시에 시스템에 액세스해야 하는 **사용자 수** - 시스템에서 트랜잭션 논리의 **전체적인 복잡성** 성능에 대해 생각할 때 팀이 플랫폼의 총괄자 제한 중 하나인 최대 CPU 시간에 대한 제약 및 계산에 너무 좁게 집중하는 경우가 있습니다. CPU 시간에 집중도가 좁은 팀은 처리량을 최적화하는 다른 방법을 무시합니다. 포커스를 확장하고 해당 메서드를 적용하면 Salesforce 아키텍처의 전반적인 처리량과 효율성이 향상됩니다. 이러한 개선 사항은 대기 시간을 줄이고 전체 시스템 성능을 향상하는 데 도움이 됩니다. ApexGuru는 루프의 SOQL, 루프의 DML, 비효율적인 GGD 호출, 비비용이 많은 메서드와 같은 처리량 제한 안티 패턴을 사전에 감지합니다. 이러한 인사이트를 통해 팀이 처리량을 제한하는 총괄자 제한 위험을 제거할 수 있습니다. 시스템의 처리량 최적화: - **비동기식 처리를 촉진합니다**. Salesforce Platform은 트랜잭션 컨텍스트를 사용하여 데이터 무결성을 제어하고 런어웨이 코드를 제한합니다. [아키텍처 기본 사항의 아키텍처 기본 사항에서 트랜잭션을](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#트랜잭션) 참조하십시오. 따라서 가능한 경우 비동기(비동기) 처리를 사용하면 동기 실행 컨텍스트에서 잠재적인 지체 지점을 최소화할 수 있습니다. [데이터 처리](/docs/architect/ko-kr/well-architected/guide/automated#데이터-처리)을 참조하십시오. 비동기 계산을 사용하면 모든 종류의 성능 문제를 해결할 수 없으며 비동기 프로세스를 통합할 때 대기 시간을 고려해야 합니다. 대기 가능한 Apex 같은 특정 플랫폼 기능은 메시지가 대기열에서 더 오래 대기하므로 트래픽이 급증하는 동안 대기 시간이 증가할 수 있습니다. 사용 사례에 따라 처리량을 유지하거나 향상하기 위해 응답성의 잠재적 저하를 허용할 수 있습니다. 그 외의 경우에는 대기 시간이 증가하면 허용되지 않을 수 있습니다. 확장형 테스트 사용하면 전체 Sandbox 트래픽 급증을 시뮬레이션하여 이러한 제약을 확인할 수 있습니다. 작업이 처리량 및 대기 시간에 미치는 영향을 측정할 수 있습니다. - **항상 대량 처리**을 사용하십시오. 높은 수준에서 대량 처리은 컬렉션에 대한 작업 수행을 의미합니다. Salesforce 솔루션에 대한 대량 처리를 논의하는 팀이 컬렉션에 대한 데이터 작업 간소화를 집중하는 경우가 많습니다. [작동 논리](/docs/architect/ko-kr/well-architected/guide/automated#운영-논리)를 참조하십시오. 그러나 시스템 수준에서 대량 처리하려면 데이터 작업 이상이 필요합니다. 또한 콜아웃 또는 복잡한 계산과 같은 특정 과업을 대량 처리 후보로 고려하십시오. 적절한 대량 처리로 오버헤드가 줄어듭니다. 작업당 하나의 요청 대신 하나의 요청으로 여러 작업을 실행합니다. ApexGuru는 프로덕션으로 확장하기 전에 수정할 수 있는 [DML 또는 SOQL 내부 루프](https://help.salesforce.com/s/articleView?language=en_US&id=xcloud.apexguru_antipatterns.htm&type=5)와 같은 안티 볼키핑 패턴을 표시합니다. [Bulk Operations](/docs/architect/ko-kr/fundamentals/guide/platform-multitenant-architecture#대량-작업)를 참조하십시오. - **검색에 SOSL을 사용하고 SOQL을 데이터 작업처럼 취급합니다**. 과도하게 복잡한 SOQL 문을 사용하면 시스템에서 레코드를 검색하는 데 걸리는 시간이 증가할 수 있습니다. SOQL은 [기본 관계형 데이터베이스](/docs/architect/ko-kr/fundamentals/guide/platform-multitenant-architecture#플랫폼-데이터-레이어)에 오버헤드를 추가하여 처리 속도를 느립니다. 텍스트 또는 와일드카드 기준을 사용할 경우 SOSL이 더 성능이 뛰어납니다. SOSL은 전체 텍스트 색인화 및 범용 검색에 최적화된 플랫폼의 검색 엔진을 사용합니다. 레코드 검색 패턴을 최적화하려면 설계 표준에서 SOSL을 사용하여 시스템에서 데이터를 찾는 시기를 지정해야 합니다. 또한 SOQL을 사용하여 효율적인 데이터 작업을 수행하는 방법을 지정해야 합니다. [운영 논리](/docs/architect/ko-kr/well-architected/guide/automated#운영-논리) 참조). - **플랫폼 캐시 및 ApexGuru를 사용**합니다. [Lightning Platform Cache](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cache_namespace_overview.htm) 레이어는 Salesforce 세션 및 조직 데이터 캐싱 시 더 빠른 성능과 더 나은 신뢰성을 제공합니다. 플랫폼 캐시는 캐시 공간을 배포하여 성능을 향상하므로 일부 응용 프로그램 또는 작업이 다른 응용 프로그램에서 용량을 훔치지 않습니다. ApexGuru는 반복 쿼리(예: SOQL 결과의 [Platform Cache](https://help.salesforce.com/s/articleView?id=xcloud.apexguru_antipattern_soql_without_platform_cache.htm&type=5))를 캐싱하기 위해 누락된 기회를 감지하여 대규모 환경에서 처리량을 개선합니다. 성능에 대한 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/reliable#성능-패턴-및-안티-패턴)은 Salesforce 조직에서 적절한 처리량과 적절한 처리량을 보여줍니다. 구축하기 전에 설계를 확인하거나 추가 최적화를 위한 기회를 식별하는 데 사용합니다. 처리량 최적화를 위한 Salesforce 도구에 대해 자세히 알아보려면 [Salesforce 신뢰도 도구](/docs/architect/ko-kr/well-architected/guide/reliable#신뢰성을-위한-salesforce-도구)를 참조하십시오. ### 대기 시간 대기 시간은 시스템이 실행 경로를 얼마나 빠르게 완료하는지 측정합니다. 시스템 처리량을 최적화하면 대기 시간이 향상됩니다. 대기 시간의 또 다른 측면은 인식 성능 또는 시스템이 사용자에게 얼마나 반응하는지입니다. 사람들이 페이지가 로드되거나 프로세스가 완료될 때까지 기다리지 않기를 원합니다. 목록 보기, 레코드 페이지, 보고서 등을 탐색하려는 경우 시스템 사용자가 자주 로드 시간이 오래 걸리면 실망할 수 있습니다. 이러한 경우 고객 또는 파트너가 성능이 좋지 않은 시스템을 다루는 대신 비즈니스를 다른 곳으로 옮길 수 있습니다. 내부적으로 직원은 시스템을 설계된 대로 사용하지 않도록 해결 방법을 만들 수 있으므로 다운스트림에서 보안 및 데이터 무결성에 문제가 발생할 수 있습니다. 감지된 성능은 진단하기 어려울 수 있습니다. 사용자가 성능 저하를 보고하면 지원 팀에서 문제를 재현할 수 없습니다. 대기 시간이 증가하는 것은 서로 구축되는 작은 문제의 조합으로 인해 발생하는 경우가 많으므로 인식되는 성능 문제의 정확한 원인을 진단하기가 어렵습니다. Salesforce 시스템에서 대기 시간 줄이기 및 응답성 향상: - **보고서를 최적화**합니다. 각 보고서가 하나의 특정 목적을 제공하는지 확인합니다. 시스템의 모든 보고서의 대상 그룹 및 목적을 명확하게 식별합니다. 보고서에 대상 그룹 구성원이 결정하는 데 필요한 최소 데이터 양만 포함합니다. 보고서의 목적과 일치하지 않는 열을 제거하면 검색하고 표시해야 하는 데이터의 양을 줄여 보고서 성능이 향상됩니다. - **필터 최적화** 효과적인 필터는 데이터베이스에서 검색되는 행 수의 범위를 정확하게 지정하여 보고서 및 목록 보기 성능 속도를 높입니다. 일반적으로 필터 논리를 구체화할수록 데이터에 대한 기본 쿼리가 더욱 효율적입니다. 필터를 최적화하는 방법은 다음과 같습니다. - “포함” 및 “포함 안 함” 대신 “같음” 및 “같지 않음” 사용 - 수식 필드별 필터링 방지 - **공유 모델 단순화** 공유 모델이 지나치게 복잡하면 시스템에서 공유 및 가시성 모델을 확인하여 사용자에게 표시 또는 처리할 데이터에 대한 액세스 권한이 있는지 확인해야 하므로 다양한 프로세스가 느려질 수 있습니다. 복잡한 공유 계산은 사용자 컨텍스트에서 실행되는 보고, 목록 보기 및 자동화의 대기 시간을 늘릴 수 있습니다. [공유 및 가시성](/docs/architect/ko-kr/well-architected/guide/secure#공유-및-가시성)을 참조하십시오. - **사용자 정의 UI 구성 요소 최적화** 사용자 정의 사용자 인터페이스(UI) 구성 요소는 대기 시간을 늘릴 수 있습니다. 사용자 정의 UI 구성 요소의 성능을 최적화하려면 다음 작업을 고려하십시오. - **Lightning 웹 구성 요소(LWC) 사용** LWC 프레임워크는 최신 웹 표준에 밀접하게 부합합니다. LWC에 작성된 사용자 정의 구성 요소는 웹 브라우저에서 더욱 효율적으로 렌더링되며 개발자가 더 성능이 뛰어난 JavaScript 메서드를 사용할 수 있습니다. 항상 Aura 또는 Visualforce 같은 이전 UI 기술 대신 LWC를 사용하십시오. - **Lightning 데이터 서비스 사용** Lightning 데이터 서비스는 구성 요소 간에 안전하고 성능이 뛰어난 공유 캐싱을 생성하고 유지 관리합니다. 이를 사용하여 데이터를 위해 불필요하게 서버로 이동하는 것을 방지하고 전체 응용 프로그램 응답을 향상합니다. - **목록 데이터에 클라이언트측 정렬 및 필터링을 사용**합니다. LWC(권장) 및 Aura(기본) 구성 요소 모두에서 개발자는 표준 JavaScript 배열 기능을 사용하여 클라이언트 측에서 값을 정렬, 필터링, 선택하여 서버에 필요한 이동 횟수를 줄일 수 있습니다. [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/reliable#성능-패턴-및-안티-패턴)은 Salesforce 조직에서 올바른 대기 시간과 낮은 대기 시간을 보여줍니다. 구축하기 전에 설계를 확인하거나 추가 최적화를 위한 기회를 식별하는 데 사용합니다. 대기 시간 최적화를 위한 Salesforce 도구에 대해 자세히 알아보려면 [Salesforce 신뢰도 도구](/docs/architect/ko-kr/well-architected/guide/reliable#신뢰성을-위한-salesforce-도구)를 참조하십시오. ### 성능 패턴 및 안티 패턴 이 표는 조직에서 찾거나 구축할 패턴을 선택한 다음, 방지하거나 수정할 항 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/trusted-performance)에서 성능을 위한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
지출량 설계 기준:
- 플랫폼 캐시 사용 방법에 대한 지침은 플랫폼 캐시 Best Practices를 준수합니다.
설계 기준:
- 플랫폼 캐시 사용 지침이 있는 경우 명확하지 않거나 모범 사례에 부합하지 않습니다.
조직에서:
- 대량 처리는 데이터 및 시스템 작업에 사용됩니다.
- DML 또는 데이터베이스 메서드는 항상 Apex 컬렉션에 대해 작동합니다.
- 데이터베이스의 elapsedTime이 짧을 때 DML 동안 사용되는 필드가 제한됩니다.
- 모든 와일드카드 기준이 SOSL에서 사용됩니다.
- SOQL 문은 선택적입니다.
-- LIKE 비교 또는 부분 텍스트 비교는 사용하지 않습니다.
-- 비교 연산자는 기본 논리 또는 전용 논리로 양수 논리(즉, INCLUDES 또는 IN)를 사용합니다.
-- = NULL 및 != NULL은 항상 양수 비교 연산자를 따르는 경우가 거의 없습니다.
– 데이터 로드를 최소화하고 성능을 극대화하기 위해 SOQL 쿼리에 필요한 필드만 검색합니다.
-- LIMIT 1 문이 사용되지 않습니다.
-- ALL ROWS 키워드가 사용되지 않습니다.
- 가능한 경우 비동기 처리를 선호합니다.
- 플랫폼 캐시 파티션이 구성되어 있습니다.
조직에서:
- DML 문은 대량 처리되지 않습니다.
- DML 또는 데이터베이스 메서드가 Apex 단일 레코드에 대해 작동합니다.
- SOSL은 와일드카드 선택 기준에 거의 사용되거나 일관되지 않습니다.
- SOQL 문은 선택적이지 않습니다.
-- LIKE 및 와일드카드 필터 기준이 포함됩니다.
-- !=, NOT 또는 NOT IN 기준을 사용하는 비교는 기본 또는 전용 비교 연산자로 사용됩니다.
-- = NULL 및 != NULL 기준을 기본 또는 유일한 비교 연산자로 사용합니다.
-- LIMIT 1 문이 사용됩니다.
-- ALL ROWS 키워드가 사용됩니다.
- SOQL이 루프 내에 표시됩니다.
- 동기 프로세스가 선호됩니다.
대기 시간 조직에서:
- 보고서는 단일 특정 목적을 제공하며 결정에 필요한 최소 행 및 열 수를 포함합니다.
- 필터는 "같음" 및 "같지 않음"을 사용합니다.
- 필터에 수식 필드가 포함되어 있지 않습니다.
- 공유 모델은 가능한 한 간소화됩니다.
- 사용자 지정 UI 구성 요소는 Lightning 웹 구성 요소(LWC)를 사용합니다.
- LWC는 데이터 작업에 Lightning Data Service를 사용합니다.
- 목록 데이터 정렬 및 필터링은 JavaScript에서 클라이언트 측에서 처리됩니다.
- Salesforce Edge가 활성화되어 있습니다.
조직에서:
- 보고서는 여러 목적으로 사용되거나 결정에 필요하지 않은 추가 행과 열을 포함합니다.
- 필터는 "포함" 및 "포함 안 함"을 사용합니다.
- 필터에 수식 필드가 포함됩니다.
- 공유 모델은 복잡합니다.
- 사용자 지정 UI 구성 요소는 LWC보다 렌더링 효율이 낮은 프레임워크를 사용합니다(예: Aura 또는 Visualforce).
- LWC는 데이터 작업에 Apex 사용합니다.
- 목록 데이터 정렬 및 필터링은 Apex 사용하여 서버 측에서 처리됩니다.
- Salesforce Edge가 활성화되어 있지 않습니다.
## 확장성 확장성은 시스템이 발전하고 성장하면서 일관적으로 수행할 수 있는 기능입니다. 확장 가능한 시스템은 기본적인 변경 사항 없이 트랜잭션 볼륨이 대규모로 증가하거나 동시 액세스를 처리합니다. Salesforce의 플랫폼 서비스는 응용 프로그램 확장성을 지원하도록 설계되었습니다. [내부 플랫폼 처리](/docs/architect/ko-kr/fundamentals/guide/platform-multitenant-architecture#내부-플랫폼-처리)을 참조하십시오. 따라서 조직이 성장하고 제품 및 서비스에 대한 수요가 증가함에 따라 효율적으로 예상대로 작동할 수 있는 시스템을 만드는 책임이 있습니다. 처음부터 확장성을 위해 아키텍션을 수립하면 사용자 트래픽이 증가함에 따라 신속하게 새로운 기능을 제공하고 서비스 중단이 줄어듭니다. 설계 단계 초반에서 새로운 기능을 생산에 배포하기 전에 **확장형 테스트를** 사용하여 예상 작업 부하를 시뮬레이션하고 아키텍처가 이를 지원하기 위해 확장할 수 있는지 검증합니다. 확장성에 맞게 설계되지 않은 시스템에는 지속적이고 비용이 많이 드는 문제 해결, 재설계, 재구성이 필요합니다. 확장성 문제는 시간이 지나면서 복잡해지고 시스템 전체의 성능이 저하됩니다. 경우에 따라 비즈니스는 가치를 창출하는 새로운 기능 대신 확장성 문제를 해결하기 위해 대부분의 개발 및 유지 관리 자원을 사용합니다. 때로는 비즈니스가 중요한 지점에 도달하는 경우가 있습니다. 시스템의 원래 설계는 비즈니스 성장을 지원하지 않으며 예기치 않은 이벤트로 인해 시스템이 불안정해집니다. **스케일 센터**의 인사이트를 사용하여 조기에 확장성 고급 지점을 파악할 수 있습니다. 스케일 센터는 시간에 따라 악화되는 예외 핫스팟, 장기 실행 트랜잭션, 대기열 지체 지점을 표시합니다. 데이터 모델 최적화 및 데이터 용량 관리를 집중하여 규모에 맞게 더 나은 설계를 수행할 수 있습니다. _참고: 여기에 설명되어 있지 않지만 확장성 테스트는 응용 프로그램 아키텍처의 유효성을 검사하는 데 중요한 부분입니다. 지침은 [테스트 전략](/docs/architect/ko-kr/well-architected/guide/resilient#테스트-전략)을 참조하십시오._ ### 데이터 모델링 데이터 모델링은 조직의 개체를 구조화하고 사용자 및 자동 프로세스가 필요한 데이터를 가능한 한 빨리 검색할 수 있는 방식으로 서로 연결합니다. 처리량을 [개선시키기 위한](/docs/architect/ko-kr/well-architected/guide/reliable#처리량) 조치를 취하면 많은 성능 문제를 해결할 수 있지만 최적화된 데이터 모델이 없으면 효과적으로 작업할 수 없습니다. 잘못 설계된 데이터 모델의 부정적인 영향은 즉시 눈에 띄지 않습니다. 데이터 용량, 프로세스, 사용자, 통합 측면에서 시스템이 성장함에 따라 약점이 노출됩니다. 잘 설계된 데이터 모델을 사용하면 요구 사항이 추가되고 확장될 때 응용 프로그램을 지속적으로 리팩터링할 수 있습니다. **ApexGuru는** 비선택적 SOQL, 사용되지 않는 필드 및 스키마 비효율성과 같은 데이터 액세스 방지 패턴을 표시하며, 이는 데이터 모델의 확장성에 직접적인 영향을 미칩니다. 데이터 모델 최적화: - Salesforce에서 미리 작성된 데이터 모델을 **사용합니다**. Salesforce는 세일즈, 서비스, 다양한 산업 분야에 사전 구축된 데이터 모델을 제공합니다. Salesforce에서 제공하는 데이터 모델을 사용하면 시스템의 기능이 한 번만 정의되므로 중복성과 사일로가 없어지고 전체 시스템에서 신뢰할 수 있는 단일 소스를 설정할 수 있습니다. 단일 소스에 대해 Salesforce 사전 빌드 데이터 모델을 사용했으므로 분석을 사용하여 응용 프로그램 데이터를 더 쉽게 이해하고 Salesforce의 사전 빌드 인공 지능 서비스를 사용할 수 있습니다. 또한 지원해야 하는 사용자 정의를 줄여 서비스 점검 비용을 절감하고 기술 부채를 줄입니다. - **적절한 데이터 유형 선택** Salesforce에서 지원하는 다양한 유형의 필드 및 제한 사항을 이해합니다. 향후 유형 간 데이터를 변환할 필요가 없도록 보고 및 암호화 요구 사항을 고려하십시오. - **적절한 관계를 선택하십시오**. Salesforce는 개체 간의 두 가지 관계, 즉 마스터-세부 사항 및 조회를 지원합니다. 마스터-세부 사항 관계는 두 가지 기본 혜택을 제공합니다. 하나는 하위 레코드의 세부 사항을 계산하고 집계하는 기본 롤업 요약 기능입니다. 다른 기능은 상위 레코드를 삭제하면 해당 하위 레코드도 삭제되는 내장 계단식 삭제 기능입니다. 그러나 사용하기 전에 마스터-세부 사항 관계의 [공유 및 데이터 왜곡 영향](/docs/architect/ko-kr/well-architected/guide/reliable#데이터-용량)을 이해해야 합니다. - **규모를 위한 비정규화.** 정규화는 데이터 중복을 줄이고 데이터 무결성을 향상하기 위해 데이터 모델을 구조화하는 프로세스입니다. 불행하게도 정규화로 인해 확장 문제가 발생하는 경우가 있습니다. 비정규화된 테이블은 대규모에서 더 나은 성능을 제공할 수 있지만 데이터 무결성 및 중복성을 고려하십시오. [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/reliable#확장성-패턴-및-안티-패턴)은 Salesforce 조직에서 올바른 데이터 모델 최적화와 나쁜 데이터 모델 최적화를 보여줍니다. 구축하기 전에 설계를 확인하거나 추가 최적화를 위한 기회를 식별하는 데 사용합니다. 데이터 모델 최적화를 위한 Salesforce 도구에 대해 자세히 알아보려면 [Salesforce 신뢰도 도구](/docs/architect/ko-kr/well-architected/guide/reliable#신뢰성을-위한-salesforce-도구)를 참조하십시오. ### 데이터 용량 데이터 용량은 레코드 개수 및 크기를 기반으로 시스템에 저장된 데이터의 양을 측정합니다. 조직에 수만 명의 사용자, 수천만 개의 레코드 또는 수백 개의 기가바이트의 총 레코드 저장소가 있는 경우 데이터 용량이 많습니다. 조직의 데이터 용량 및 개체 간 관계는 확장성에 영향을 미치며 단순히 레코드 수보다 확장성에 더 큰 영향을 미칠 수 있습니다. 데이터 용량이 큰 조직의 확장성 향상: - **하위 레코드를 배포**합니다. 상위 항목에 많은 하위 레코드가 없는지 확인하여 상위-하위 데이터 왜곡을 방지합니다. 일반 권장 사항은 상위 레코드가 10,000개를 초과하지 않아야 합니다. 예를 들어 연락처가 많지만 계정을 사용하지 않는 배포에서 여러 계정 레코드를 설정하고 관련 연락처 레코드를 해당 레코드 간에 배포하는 것이 좋습니다. - **레코드의 공유 소유권** 단일 사용자 또는 대기열이 소유하지 않거나 단일 역할 또는 공개 그룹의 모든 구성원이 같은 개체의 레코드를 10,000개 이상 소유하지 않도록 하여 소유권 왜곡을 방지합니다. "더미 사용자"와 함께 "주차" 데이터는 자주 소유권 왜곡으로 이어집니다. 이 문제가 발생하면 [계산 공유](/docs/architect/ko-kr/well-architected/guide/reliable#대기-시간)에 미치는 영향에 유의하십시오. 소유권 왜곡을 완화하기 위해 레코드를 재배포할 수 없는 경우 데이터 소유자 사용자를 역할에 할당하지 마십시오. 조직의 공유 모델에 역할 할당이 필요한 경우 데이터 소유자 사용자를 공유 계층 상단의 고유한 역할에 배치합니다. 공유 재계산으로 인해 모든 변경 사항이 상당한 성능에 영향을 미치므로 해당 사용자의 역할에 자주 또는 계획되지 않은 변경을 허용하지 마십시오. 공유 규칙에서 참조할 수 있는 공개 그룹에서 해당 사용자를 제외합니다. - Salesforce에서 레코드 데이터의 양을 **축소합니다**. Salesforce는 비즈니스에서 고객을 한눈에 파악할 수 있도록 설계되었습니다. Salesforce에서 데이터를 제한하는 것이 가장 좋은 방법인 것처럼 보일 수 있습니다. 그러나 단일 보기의 장점은 비즈니스 사용자가 고객 데이터를 이해하고 조치를 취할 수 있게 하는 정도입니다. 데이터 용량이 증가함에 따라 일상적인 프로세스 또는 분석과 관련이 없거나 최신 상태가 아닌 데이터로 인해 몇 가지 문제가 발생합니다. 이러한 문제에는 앱 성능 저하, 증가된 데이터 보안 위험, 검색, 보고, 분석에 미치는 부정적인 영향이 포함됩니다. 이러한 문제를 방지하려면 데이터 모델의 모든 개체에 대한 데이터 수명 주기를 정의하고 데이터가 오래되고 즉각적인 비즈니스 가치가 손실될 때 데이터에 대한 타임라인 및 분류를 정의합니다. 데이터 수명 주기에 따라 다음 절차를 구현하여 시간에 따른 데이터를 관리합니다. - **데이터 아카이빙 및 제거** \- 데이터 볼륨을 가능한 한 낮게 유지하려면 비즈니스에서 필요하지 않은 레코드를 제거하여 데이터 볼륨을 가능한 한 낮게 유지합니다. 대량 데이터 볼륨을 삭제하려면 대량 API 2.0의 영구 삭제 기능을 사용합니다. - **데이터 집계-** 주요 과거 추세 또는 요약 데이터를 보고와 호환되는 형식으로 요약하는 집계 사용자 정의 개체를 만듭니다. [배치 Apex](/docs/architect/ko-kr/well-architected/guide/reliable#처리량)를 사용하여 사용자 정의 개체를 채웁니다. 그러면 사용자가 집계된 개체 레코드를 기반으로 보고서를 실행할 수 있습니다. - **데이터 계층화** Salesforce 보고서 또는 일상적인 작업에 필요하지 않은 경우 다른 응용 프로그램에서 대규모 데이터 집합을 유지합니다. 매시업, 콜아웃 또는 외부 개체를 통해 필요에 따라 Salesforce에서 데이터를 사용할 수 있도록 합니다. 실제로 문제가 발생하면 확장성 문제의 근본 원인을 즉시 해결할 수 없습니다. 따라서 Salesforce는 즉각적인 불만 사항을 완화하는 옵션을 제공합니다. 조직에서 이러한 기능을 활성화해도 대용량 데이터를 처리하기 위한 실현 가능한 장기 아키텍처 전략이 아닙니다. 이러한 단기 중단 간격 해결 방법은 데이터 아키텍처가 좋지 않은 시스템에서 대기 시간을 줄이는 데 도움이 될 수 있지만 조직에 기술적 부채를 추가할 수도 있습니다. 규모 문제에 대한 단기 해결 방법은 다음과 같습니다. - **사용자 지정 색인** 색인은 플랫폼의 쿼리 최적화 프로그램이 데이터 액세스 작업을 가속화하기 위해 사용하는 특별한 내부 테이블에 저장됩니다. [Multitenant Indexes](/docs/architect/ko-kr/fundamentals/guide/platform-multitenant-architecture#색인) 참조). 플랫폼은 기본적으로 특정 유형의 필드를 자동으로 색인화합니다. 성과가 좋지 않은 쿼리 속도를 높이려면 Salesforce 고객 지원에 문의하여 추가 사용자 정의 색인을 요청할 수 있습니다. 쿼리 계획 도구를 사용하여 사용자 정의 색인이 쿼리 성능을 향상할지 여부를 결정합니다. - **스키니 테이블** 100만 개가 넘는 레코드가 있는 개체의 공통 필드 집합에 대한 쿼리를 추가로 최적화해야 하는 경우 스키니 테이블을 사용하면 도움이 됩니다. 스키니 테이블은 보고서 또는 자동화에서 동일한 개체의 사용자 정의 및 표준 필드를 사용할 때 발생하는 [백그라운드 조인](https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_skinny_tables.htm)을 제거합니다. 스키니 테이블을 사용하려면 Salesforce 고객 지원에서 조직에 대해 활성화해야 합니다. 확장성에 대한 [패턴과 안티패턴](/docs/architect/ko-kr/well-architected/guide/reliable#확장성-패턴-및-안티-패턴)은 Salesforce 조직에서 올바른 데이터 볼륨 관리와 나쁜 데이터 볼륨 관리를 보여줍니다. 구축하기 전에 설계를 확인하거나 추가 최적화를 위한 기회를 식별하는 데 사용합니다. 데이터 볼륨을 관리하는 Salesforce 도구에 대해 자세히 알아보려면 [Salesforce 신뢰도 도구](/docs/architect/ko-kr/well-architected/guide/reliable#신뢰성을-위한-salesforce-도구)를 참조하십시오. ### 확장성 패턴 및 안티 패턴 이는 조직에서 찾거나 구축할 패턴을 선택하고, 방지하거나 수정할 항 패턴을 표시합니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/trusted-scalability)에서 확장성을 위한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
데이터 모델링 설계 기준:
- 사용자 정의 개체가 존재하도록 비즈니스 근거가 있는 표준 및 지침입니다.
설계 기준:
- 사용자 정의 개체를 만드는 표준이 없습니다.
데이터 모델:
- 가능한 경우 표준 개체가 사용됩니다.
- ApexGuru에서 안티 패턴을 확인하여 SOQL 쿼리가 선택적이며 비효율적인 스키마 사용을 방지합니다.
- 테이블은 규모에 대해 비정규화됩니다.
데이터 모델:
- 복제된 표준 개체가 있습니다.
- 표가 중복되지 않도록 정규화됩니다.
기업 내에서:
- 하위 코드 빌더는 Salesforce에서 지원하는 다양한 필드 유형을 이해하고 필드 데이터 유형을 선택하기 전에 보고 및 암호화 요구 사항을 평가합니다.
- 개체 간 마스터-세부 사항 관계를 설정하기 전에 해당 관계의 공유 및 데이터 왜곡이 미치는 영향을 평가합니다.
기업 내에서:
- 하위 코드 빌더는 다운스트림 보고 및 암호화 요구 사항을 평가하지 않고 데이터 유형을 선택합니다.
- 개체 간 마스터-세부 사항 관계를 설정하기 전에 해당 관계의 공유 및 데이터 왜곡 영향을 평가하지 마십시오.
데이터 볼륨 데이터에서:
- 상위 레코드에 하위 레코드가 10,000개를 초과하지 않는 경우
- 동일한 개체 유형의 10,000개 이상의 레코드에 할당된 사용자는 없습니다.
- 동일한 레코드를 가리키는 조회 필드가 있는 인스턴스가 10,000개를 초과하는 레코드를 포함하지 않습니다.
- 대량 데이터 로드는 ParentId 필드 값에 따라 배치로 정렬됩니다.
- 배치 전략이 동시적으로 중단되지 않도록 확장형 테스트 프로덕션 규모에서 대량 로드 패턴을 확인하는 데 사용됩니다.
- 최대 업무 시간에는 프로덕션에 대량 데이터 로드가 발생하지 않습니다.
- 대량 데이터 로드에는 비즈니스 결정에 필요한 최소 데이터만 포함됩니다.
데이터에서:
- 하위 레코드가 10,000개를 초과하는 레코드가 있습니다.
- 동일한 유형의 10,000개가 넘는 레코드에 사용자가 할당됩니다.
- 10,000개가 넘는 레코드에 동일한 레코드를 가리키는 조회 필드가 있는 인스턴스가 있습니다.
- 대량 데이터 로드는 ParentId 필드 값에 따라 배치로 정렬되지 않습니다.
- 비즈니스 시간이 가장 긴 시간에 프로덕션에 대량 데이터 로드가 발생합니다.
- 대량 데이터 로드는 비즈니스 결정에 필요한 최소 데이터로 제한되지 않습니다.
플로 및 Apex :
- 데이터 왜곡이 우려되는 시나리오에서 여러 상위 레코드에 하위 레코드 수를 배포하는 논리가 있습니다.
- 통합을 통해 레코드를 가져오거나 복제할 경우 논리가 적절한 사용자에게 레코드를 할당합니다.
- 목록 및 집합과 같은 Apex 컬렉션의 경우 쿼리를 최소화하고 데이터 처리를 최적화하기 위해 여러 레코드를 처리하는 논리가 있습니다.
- 확장 가능한 코드에 대한 표준 및 모범 사례를 따르는 효율적인 Apex 코드가 작성되고 배포됩니다.
플로 및 Apex :
- 이미 할당된 하위 레코드 수에 관계없이 하위 레코드가 임의로 상위 레코드에 할당됩니다.
- 데이터 로드 또는 통합을 통해 생성된 레코드는 일반 "통합 사용자"에 할당됩니다.
- 동일한 개체의 여러 반복 SOQL 쿼리가 동기 트랜잭션에 포함되어 있어 힙 사용량이 높습니다.
- 개발자가 Apex 코드를 작성할 때, 그들은 비효율성과 성능 반 패턴을 도입합니다.
기업 내에서:
- 데이터 보관 및 제거 전략을 문서화하고 구현했습니다.
기업 내에서:
- 데이터 보관 및 제거 전략이 없거나 전략이 문서화되었지만 구현되지 않았습니다.
## 신뢰성을 위한 Salesforce 도구
도구설명가용성성능확장성
대형 객체 플랫폼에 대용량 데이터를 저장하고 관리합니다. X
코드 스캐너 성능 문제에 대해 Apex 코드를 스캔합니다. X
사용자 지정 색인 사용자 정의 색인을 사용하여 쿼리 성능을 향상합니다. X
데이터 삭제 불필요한 데이터를 제거하여 성능을 향상합니다. X X
분야 데이터를 분할하여 쿼리 및 보고서의 레코드 수를 제한합니다. X
확장형 테스트 시스템 성능을 테스트하고 결과를 해석합니다. 프로덕션에 배포하기 전에 Playwright 또는 JMeter 스크립트를 사용하여 대규모 UI 및 API 워크로드를 시뮬레이션하여 확장성 및 성능을 확인합니다. X X
스케일 센터 시스템 성능에 대한 셀프 서비스 및 실시간 인사이트를 확보합니다. 장기 실행 트랜잭션, 예외 핫스팟, 처리량 지체 지점을 찾습니다. 개발 주기의 초기에 규모 문제를 진단합니다. X X
ApexGuru Scale Center에서 이 GenAI 기반 기능을 사용하여 런타임 시 Apex, SOQL 및 테스트 클래스 안티 패턴을 감지합니다. Salesforce 코드 분석기와 ApexGuru의 통합을 통해 개발 워크플로에서 AI 기반 권장 사항 및 인라인 수정 사항을 가져옵니다. 해당 권장 사항 및 수정 사항을 사용하여 핫스팟을 해결하고 쿼리 선택성, 대량 처리, 캐시 사용, 테스트 품질을 개선합니다. X X
Salesforce 코드 분석기 IDE, CLI 또는 CI/CD로 코드를 스캔하여 모범 사례를 준수하는지 확인합니다. Salesforce Code Analyzer와 ApexGuru의 통합을 통해 개발자 워크플로에서 직접 성능 안티 패턴에 대한 인사이트를 확보할 수 있습니다. X
Salesforce Edge 네트워크 Salesforce Edge 네트워크를 통해 내 도메인을 라우팅하여 다운로드 시간과 사용자 환경을 향상합니다. X
스키니 테이블 자주 사용하는 필드가 있는 테이블의 조인을 피하십시오. X
사전 예방적 모니터링 레코드 증가, 소유권 왜곡, 성능 회귀의 변칙을 지속적으로 모니터링합니다. 중요해지기 전에 규모 문제에 대해 경고합니다. X X
## 신뢰성을 위한 Salesforce 리소스
자원설명가용성성능확장성
스케일링 과제가 수백만 달러에 달하는 비용 — 비즈니스의 미래 보증 방법 확장성을 구현하면 지속 가능한 성장과 장기적인 성공이 미치는 영향을 알아봅니다. X X
Scaling Center를 사용하여 확장 가능한 애플리케이션 구축 및 배포 Salesforce 구현에서 성능 문제를 사전에 평가하고 해결하는 방법을 이해합니다.
복잡한 Salesforce 앱에서 성능 및 확장 핫스팟 분석 조직의 성능 및 확장성 문제를 해결합니다. X X
귀하의 앱은 급류 시간 트래픽에서 패닉하지 않아야합니다 - 여기에 준비하는 방법 성공적인 규모 테스트를 위한 네 가지 핵심 단계를 알아봅니다.
ApexGuru AI 엔진 설명 ApexGuru가 사용자 정의 교육 모델, 실제 조직 텔레메트리, 지능형 필터링을 사용하여 정확하고 상황에 맞는 실행 가능한 인사이트를 제공하는 방법에 대해 알아봅니다. X X
ApexGuru를 사용하여 Apex for Apps 및 Agentforce 최적화 ApexGuru를 사용하여 개발자가 SOQL, DML, 디버깅 및 테스트 비효율성을 비롯한 성능 안티 패턴을 감지하고 수정하는 방법을 알아보십시오. 앱의 확장 가능한 개발 및 Agentforce 구현을 위한 AI 기반 코치로 ApexGuru를 사용하십시오. X X
ApexGuru Antipatterns 모든 주요 Salesforce 릴리스에 대해 업데이트되는 ApexGuru 감지 안티 패턴의 공식 라이브러리에서 알아보십시오. X X
대용량 데이터를 사용하는 배포를 위한 모범 사례 대용량 데이터의 프로세스 영향을 이해합니다. X
Salesforce Edge 네트워크에 대한 고려 사항 조직이 Salesforce Edge 네트워크를 사용할 수 있도록 준비하는 방법을 알아봅니다. X
설계 표준 템플릿 조직에 대한 설계 표준을 만듭니다. X X X
데이터 모델 설계 고려 사항 규모 및 서비스 점검을 위해 데이터 모델을 최적화합니다. X X
엔터프라이즈 규모의 레코드 액세스 설계 구성을 통해 액세스 제어 성능을 최적화합니다. X
대용량 데이터를 사용하는 시스템의 인프라 대용량 데이터를 사용하는 배포에 대한 시스템 성능을 지원하는 기능에 대해 알아봅니다. X
배치 관리용 학습 리소스 배치 관리에 대해 알아봅니다. X X
Lightning Experience 성능 최적화 사용자가 더 빠르게 작업할 수 있도록 조직의 Lightning Experience 개선합니다. X
Salesforce에서 조회 스키우를 관리하여 레코드 잠금 예외 방지 조회 왜곡의 영향을 최소화하는 방법을 이해합니다. X X
SOQL 및 SOSL Best Practices 대용량 데이터가 있는 배포의 경우 SOQL 및 SOSL 모범 사례를 따르십시오. X X
대규모 재정렬을 위한 도구 재정렬을 효과적으로 계획하고 실행합니다. X
Mashups 사용 다른 응용 프로그램에서 대용량 데이터 집합을 유지 관리합니다. X X
## 의견을 알려주십시오. Salesforce Well-Architected의 관련성을 유지할 수 있도록 도와주십시오. 이 콘텐츠에 대한 사용자 의견을 제공하려면 [ 설문 조사](https://sfdc.co/bxNtvh)을 작성하고 다음에 표시할 내용을 알려주십시오. > 업데이트 일정을 [여기](/docs/architect/ko-kr/well-architected/guide/contributors) 읽어보세요. ## 소개 **신뢰할 수 있는** Salesforce 솔루션은 비즈니스 및 이해당사자를 보호합니다. **신뢰할 수 있는** 솔루션은 안전하고 규정 준수하며 신뢰할 수 있습니다. **보안** 솔루션은 액세스를 제어하고 데이터를 보호합니다.
**규정 준수** 솔루션은 법적 및 윤리적 지침을 따릅니다.
**신뢰할 수 있는** 솔루션은 효율적이고 안정적으로 작동합니다.
**신뢰할 수 있는** 솔루션을 만들려면 신중한 계획이 필요합니다. 솔루션이 제공하는 비즈니스 및/또는 산업의 컨텍스트를 이해해야 합니다. 비즈니스의 전체적인 위험 허용은 어떻습니까? 시스템에서 또는 시스템 외부로 이동하는 데이터의 유형은 무엇입니까? Salesforce는 전문적인 보안, 규정 준수 또는 윤리적 고려 사항을 고려하여 데이터에 대한 레코드 또는 저장소 시스템으로 작동합니까? 관련 규정 및 규정 준수 표준은 무엇입니까? 회사별 추가 표준이 있습니까? Salesforce가 비즈니스에 중요한 시스템입니까? 고려해야 할 계절별 또는 상황별 트래픽 또는 시스템 사용량 급증이 있습니까? **신뢰할 수 있는** 솔루션을 얻으려면 비즈니스 전반의 이해당사자와 협력해야 합니다. 솔루션에 액세스해야 하는 사용자 및 시스템의 종류와 작업을 완료하는 데 필요한 데이터 및 권한을 명확하게 파악해야 합니다. 법적 및 산업 요구 사항과 내부 정책 및 표준을 이해해야 합니다. 개발 및 서비스 점검 팀과 협력하여 기능에 액세스하고 사용자에게 공평하게 서비스를 제공해야 합니다. 중단 또는 급증 상황에서도 솔루션 가용성 및 성능을 계획해야 합니다. 잘 설계된 솔루션에 **신뢰받는 것**보다 더 중요한 것은 없습니다. 다음 섹션은 **신뢰할 수 있는** 솔루션 아키텍처의 핵심 고려 사항에 대한 자세한 지침을 제공합니다. ## 신뢰할 수 있는 개요
보안
보안 시스템은 비즈니스, 이해당사자, 데이터를 보호합니다. 안전한 아키텍처는 승인받은 사용자만 액세스 권한을 얻고 작업을 완료하는 데 필요한 항목에 대한 사용자 액세스를 제한하며 시스템 내 데이터가 손상되지 않도록 보호합니다.
조직 보안 세션 보안 데이터 보안
인증
인증
세션 관리
장치 액세스
위협 감지 및 대응
공유 및 가시성
암호화 사용
호환
규정을 준수하는 솔루션은 법적 및 윤리적 지침을 따릅니다. 호환 아키텍처는 법적 규정 및 업계 표준을 준수하고 윤리적 정책을 유지하며 모든 사용자에게 공평하게 서비스를 제공합니다.
법적 준수 윤리적 기준 가용성
데이터 프라이버시
현지화
회사 정책
인공 지능
데이터 입력
탐색
신뢰할 수 있는
신뢰할 수 있는 솔루션은 다양한 조건에서 효율적이고 신뢰할 수 있게 작동합니다. 신뢰할 수 있는 아키텍처는 사용자가 예상하고 일관되게 수행하고 비즈니스와 함께 확장할 때 어디서나 사용할 수 있습니다.
가용성 성능 확장성
위험 관리
실패 완화
처리량
대기 시간
데이터 모델링
데이터 용량
> [여기에](/docs/architect/ko-kr/well-architected/guide/contributors) 업데이트 일정에 대해 알아보십시오. ## 소개 보안 시스템은 조직의 이해당사자 및 데이터를 보호합니다. 보안 아키텍처는 사용자 ID를 확인하고, 필수 정보로만 데이터 액세스를 제한하며, 데이터 손상을 방지합니다. Salesforce는 고객 Trust 및 데이터 보안에 우선 순위를 두고 있습니다. Salesforce Platform은 개인 정보 보호 및 보안을 보장합니다. 실시간 시스템 성능 및 보안 정보는 [Salesforce Trust](https://trust.salesforce.com/)에서 확인할 수 있습니다. 조직 및 고객 데이터를 보호하는 것이 보안 Salesforce 솔루션 구축의 기초입니다. Salesforce 아키텍처는 Salesforce의 내장형 보안 기능을 활용하여 조직 및 고객 데이터를 보호할 책임이 있습니다. 이러한 결정을 내릴 때 지리적 분포, 산업, 회사 운영 절차, 고객 데이터 유형을 고려하십시오. 조직 보안, 세션 보안, 데이터 보안과 같은 세 가지 영역에 집중하여 솔루션을 보다 안전하게 만들 수 있습니다. ## 조직 보안 조직 보안은 유효한 권한이 있는 사용자만 시스템에 액세스하고 필수 기능 및 데이터만 액세스할 수 있도록 하여 시스템을 무단 액세스로부터 보호합니다. 조직 보안 문제가 있다는 신호는 다음과 같습니다. - 사용자를 활성화 또는 비활성화하는 특별 프로세스 - 사용자 또는 시스템 역할 변경에 대한 인가를 업데이트하기 위한 명확하지 않은 단계 - 올바른 사용자 보안 할당을 위해 개인의 기관 Knowledge 의존 - 구축된 보안 프레임워크 또는 업계 모범 사례를 준수하지 못함 - 구조화된 데이터 거버넌스 프레임워크 및 지원 정책이 없음 인증 및 권한 부여에 집중하여 Salesforce 조직에 대한 더 나은 조직 보안 제어를 구축할 수 있습니다. ### 인증 인증은 시스템에 액세스하려는 사용자의 ID를 확인하는 보안 및 액세스 관리에 매우 중요합니다. 이는 인간 사용자(직원, 고객) 및 자동화된 사용자(외부 시스템, 통합) 모두에게 적용되며, 각 사용자 유형에 특정 인증 스키마가 필요합니다. 조직의 모든 Salesforce 입력 지점에서 안전하게 액세스하려면 다양한 인증 방법을 설정해야 합니다. Salesforce에서 보안 인증 플로 만들기: - 페르소나가 아닌 개인을 기반으로 **Salesforce 사용자를 만듭니다**. Salesforce의 내장 감사 기능은 각 사용자 계정이 플랫폼에 액세스하는 단일 개인에 해당하는 경우 가장 효과적입니다. 공유 사용자 계정을 사용하면 감사의 효율성이 저하되고 추가 보안 취약점이 발생하거나 계정 위반이 미치는 잠재적인 영향을 에스컬레이션하거나 효과적인 인가 스키마를 만들 수 있는 기능이 복잡해집니다. 여기에는 통합 사용자의 사용자 계정이 포함됩니다. - **보안 UI 기반 액세스 시나리오** 대부분의 사용자는 Salesforce 조직에 대해 일종의 UI 기반 액세스(일반적으로 로그인 액세스)가 필요합니다. Salesforce는 다음을 포함하여 이러한 로그인 시나리오에 대한 몇 가지 보호 계층을 제공합니다. - **암호 정책.** 사이버 범죄자는 사용자 이름 및 암호를 타겟팅하여 응용 프로그램에 대한 무단 액세스를 얻을 수 있습니다. [암호 정책](https://help.salesforce.com/s/articleView?id=sf.admin_password.htm&type=5)을 구성하는 것은 로그인 액세스를 보호하는 데 중요한 단계이지만, Salesforce에서 사용자별로 이러한 정책을 재정의할 수 있기 때문에 이것만으로는 충분하지 않습니다. - **다단계 인증(MFA)** Salesforce는 모든 UI 기반 사용자 로그인에 MFA를 [필요합니다](https://help.salesforce.com/s/articleView?id=000352937&type=1). MFA는 사용자가 사용자 이름과 암호를 입력한 후 추가 식별 형식 또는 요소를 제공하도록 요구하여 자격 증명 누출 및 대량 공격에 대한 필수 방어 기능을 제공합니다. 이 추가 요소는 일반적으로 모바일 장치, 보안 키 또는 생체 인식 마커와 같은 물리적 형태를 취합니다. - **Single-sign on (SSO)**. SSO 시나리오에서 사용자는 조직의 응용 프로그램에서 하나의 자격 증명 집합만 사용합니다. 시스템에 대한 액세스는 중앙 위치에서 프로비저닝 및 관리되므로 보안이 향상됩니다. Salesforce는 [SSO 시나리오](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5)에서 서비스 공급자 또는 ID 공급자 역할을 수행할 수 있습니다. SSO 구현 중단이나 문제를 해결할 수 있도록 일부 또는 모든 관리자가 Salesforce에 직접 로그인하도록 허용해야 합니다. - **로그인 후 단계.** 일부 사용 사례에서는 시스템에 액세스하기 전에 사용자에게 추가 단계를 완료해야 할 수 있습니다. 사용자 정의 로그인 플로를 구현하여 사용자에게 이러한 추가 프로세스 단계를 안내할 수 있습니다. 예: - 사용 약관 수락 - [로그인 검색 및 무암호 로그인 시나리오를 통해 작업](https://help.salesforce.com/s/articleView?id=sf.external_identity_passwordless_login_use_cases.htm&type=5) - 세션 기반 공격 가능성을 줄이기 위해 사용자당 동시 Salesforce 세션 수 제한([세션 보안](/docs/architect/ko-kr/well-architected/guide/secure#세션-보안) 참조). - 지오펜싱 서비스에 연결 - **보안 API 기반 액세스 시나리오** 모든 사용자가 Salesforce 조직에 대한 API 기반 액세스를 요청할 수 있습니다. Salesforce는 다음을 포함하여 API 기반 시나리오에 대한 몇 가지 보호 계층을 제공합니다. - **API 액세스 제어**. [API 액세스 제어](https://help.salesforce.com/s/articleView?id=sf.security_api_access_control_about.htm&type=5) 없이 유효한 자격 증명 집합을 보유한 모든 사용자는 연결된 앱이 조직에 배포되지 않은 경우에도 모든 앱을 활용하여 조직과 연결할 수 있습니다. 데이터 액세스 제어는 계속 적용되지만 사용자는 제어되지 않은 방식으로 정보에 액세스할 수 있습니다. 예를 들어, 시스템 관리자의 승인 없이 대용량 데이터를 다운로드하거나 손상된 정보를 업로드하는 데 앱을 사용할 수 있습니다. - **API 전용 권한**. Salesforce에서 API 전용 사용자 권한을 구성할 수 있습니다. 이 권한 집합의 일부로 자동화 또는 [통합 사용자 페르소나](https://help.salesforce.com/s/articleView?language=en_US&id=sf.integration_user.htm)에 할당하여 UI 기반 액세스를 완전히 차단합니다. - **인증서 및 키** [인증서 및 키를 사용하면](https://help.salesforce.com/s/articleView?id=sf.security_keys_about.htm&type=5) Salesforce에서 요청이 승인된 비즈니스 또는 회사에서 시작되었는지 확인할 수 있습니다. [SSO를 Salesforce와 함께](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5) 사용하려면 인증서와 키를 구성해야 합니다. - **연결된 앱** Salesforce에서 [연결된 앱](https://help.salesforce.com/s/articleView?id=sf.connected_app_overview.htm&type=5)을 구성하면 필요한 인증 프로토콜, 권한 부여 범위 및 세션 동작을 포함하여 Salesforce에 대한 외부 시스템 액세스를 단일 정의로 제어할 수 있습니다. - **명명된 자격 증명** [명명된 자격 증명](https://help.salesforce.com/s/articleView?id=sf.named_credentials_define.htm&type=5)을 사용하면 Salesforce 내에서 외부 액세스 지점 및 인증 프로토콜을 단일 정의로 제어할 수 있습니다. 이를 사용하여 Apex, 외부 서비스 및 Salesforce Connect 데이터 소스의 콜아웃에 대한 인증을 안전하게 정의하고 관리할 수 있습니다. - **Agentforce Agent 사용자 인증**. Salesforce에 구축된 Agentforce 에이전트는 실제 사용자와 마찬가지로 관리 가능한 권한이 있는 에이전트-사용자 개체를 사용합니다. 에이전트를 설정할 때 액세스를 에이전트가 수행하는 역할에 주의 깊게 조율하여 최종 사용자를 제공하는 데 필요한 항목으로만 데이터 액세스를 제한합니다. 또한 공개 및 비공개 작업을 모두 사용하여 에이전트를 구성할 수 있습니다. 비공개 작업의 경우 최종 사용자를 확인 및 인증하여 에이전트 컨텍스트에 매핑합니다. 이렇게 하면 에이전트가 최종 사용자의 액세스 제어 내에서 동작하고 보안과 Trust 유지할 수 있습니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/secure#조직-보안-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 올바르고 나쁜 인증 아키텍처를 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 향후 개선할 기회를 식별합니다. Salesforce에서 사용할 수 있는 인증 도구에 대한 자세한 내용은 보안과 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/secure#보안과-관련된-도구)를 참조하십시오. ### 인증 권한 부여는 사용자가 액세스할 수 있는 기능, 기능 및 데이터와 해당 자원으로 수행할 수 있는 작업([인증됨](/docs/architect/ko-kr/well-architected/guide/secure#인증))을 정의합니다. 인가 제어는 인증되지 않은 최종 사용자에게 서비스를 제공하는 Agentforce 에이전트 사용자에 맞게 조정되어야 합니다. 조직에 인증할 수 있는 사람을 제한하는 것이 중요한 첫 번째 단계이지만 강력한 인증과 강력한 인증을 연결하는 것이 중요합니다. 적절한 권한 부여 제어가 없으면 사용자가 잠재적으로 비즈니스 및 이해당사자에게 해로운 방식으로 레코드를 생성, 편집, 삭제하거나 시스템 기능에 액세스할 수 있습니다. 권한 부여 제어가 부적절하면 시스템 사용이 더 어려울 수도 있습니다. 사용자가 시스템 내에서 수행할 수 있는 작업을 제어하여 시스템과 사용자를 안전하게 보호하는 Trust 수준을 높일 수 있습니다. Salesforce에 대한 보안 권한 부여 스키마 구축: - **최소 권한의 원칙을 따르십시오**. 사용자에게 과업에 필요한 권한만 할당하여 최소 권한(PoLP) 원칙을 적용합니다. 이 원칙을 따르려면 세분화된 모듈식 권한 집합을 설계합니다. 이렇게 하면 권한 집합 그룹을 통해 정교한 액세스 제어 기능을 사용할 수 있으며, [무시](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_muting.htm&type=5) 기능, [만료 일자 설정](https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_permissions_assn_expiration.htm&type=5&release=238) 등을 비롯한 권한을 정확하게 관리할 수 있습니다. 시스템의 [기능 단위](/docs/architect/ko-kr/well-architected/guide/composable#기능-단위)를 비즈니스 기능에 맞춰 세분화된 권한 및 효과적인 권한 집합 그룹을 정의합니다. 권한은 Salesforce의 _메타데이터_ 액세스에 적용됩니다. Salesforce _데이터_ 액세스를 위한 PoLP 구성에 대한 자세한 내용은 [공유 및 가시성](/docs/architect/ko-kr/well-architected/guide/secure#공유-및-가시성)을 참조하십시오. - 개인이 아닌 개인의 관점에서 사용자 액세스를** 생각해보십시오**. 개별 사용자에 대한 인가(또는 일반적인 보안)를 고려해도 시스템의 규모를 조정하고 발전하지 않습니다. 대신 사용자 그룹을 나타내는 페르소나를 설계하고 관리합니다. 보안 Salesforce 솔루션은 인증에 개인을, 권한 부여에 페르소나를 사용합니다. 고유한 개인 정보에 대한 보안 구성을 정의하면 보안 모델의 액세스 및 권한을 세부적으로 제어할 수 있으므로 장기적으로 재단계화 필요가 최소화됩니다. [설계 표준 및 문서](/docs/architect/ko-kr/well-architected/guide/intentional#가독성)에 정의한 보안 개인 정보를 포함합니다. - **권한 집합 및 권한 집합 그룹을 사용하여 메타데이터에 대한 사용자 액세스를 제어**합니다. 권한 집합 및 권한 집합 그룹은 사용자가 액세스할 수 있는 메타데이터 및 해당 메타데이터로 수행할 수 있는 작업을 관리합니다. Salesforce 메타데이터에 대한 자세한 내용은 [메타데이터 대 데이터](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#메타데이터와-데이터-비교)를 참조하십시오. 권한 집합 및 권한 집합 그룹을 통해 앱 할당, 기능 라이센스 활성화, 관리 패키지 액세스, 시스템 권한, [CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm) 액세스, 필드 수준 액세스를 구성합니다. 이 액세스를 [설계 표준 및 문서](/docs/architect/ko-kr/well-architected/guide/intentional#가독성)에 포함하십시오. - **조직 전체 기본값(OWD) 및 공유를 사용하여 사용자의 데이터 액세스를 제어합니다**. Salesforce의 [데이터와 메타데이터](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#메타데이터와-데이터-비교)는 별도의 엔티티이므로 각각에 대해 별도의 액세스 제어가 필요합니다. OWD 및 내장된 공유 도구를 사용하여 Salesforce 데이터(개별 레코드, 파일 및 문서도구)에 대한 액세스를 구성합니다. 자세한 내용은 [데이터 보안](/docs/architect/ko-kr/well-architected/guide/secure#데이터-보안)을 참조하십시오. - **OAuth 범위를 사용하여 연결된 앱의 액세스를 제어합니다**. 연결된 앱을 구성할 때 앱 사용자가 Salesforce 리소스에 대해 보유할 [범위](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US) 또는 액세스 권한을 정의합니다. OAuth 토큰 관리에 대한 자세한 내용은 [세션 관리를 참조하십시오](/docs/architect/ko-kr/well-architected/guide/secure#세션-관리). - 모든 통합에 대해 **1개의 Salesforce 사용자를 만듭니다**. 최소 권한 원칙을 준수하려면 각 통합에 대해 고유한 Salesforce [통합 사용자](https://help.salesforce.com/s/articleView?id=sf.integration_user.htm)를 만듭니다. 이를 통해 특정 데이터 액세스를 할당하고 작업을 효과적으로 제어하고 트랜잭션 추적 가능성을 보장하며 잠재적인 보안 위반이 미치는 영향을 최소화할 수 있습니다. - **모든 Agent 사용자에 대해 PoLP를 사용하여 고유한 계정을 구현합니다**. 각 Agentforce 에이전트 사용자는 고유해야 하며 여러 에이전트 간에 재사용되지 않아야 합니다. 해당 계정에 대한 권한은 최소 권한 원칙을 엄격하게 준수해야 합니다. 에이전트 사용자가 실행한 작업은 Salesforce 내에서 또는 Salesforce 액세스 제어를 준수하지 않는 외부 시스템에 대해 강화된 보안 컨텍스트에서 작동할 수 있다는 점에 유의하십시오. 그러면 작업이 사용자에게 민감한 정보에 액세스하거나 사용자에게 정보를 공개할 수 있습니다. - **프로필 사용을 최소화하고 프로필에서 액세스 컨트롤을 마이그레이션합니다**. 프로필은 기존 Salesforce Classic 사용자 인터페이스(특히 기본 레코드 유형 및 페이지 레이아웃 할당)에 특정한 [로그인 IP 범위](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm&type=5), [로그인 시간](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5) 및 기능에 대한 액세스를 제한할 수 있는 기능을 제공합니다. 현재 프로필에 있는 다른 기능은 [권한 집합 및 권한 집합 그룹](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_create_with_perm_sets.htm)의 동등한 기능으로 마이그레이션해야 합니다. Salesforce Classic UI 기능과 관련된 프로필의 기능은 수정 대상으로 지정해야 합니다. 아래의 [패턴 및 비패턴](/docs/architect/ko-kr/well-architected/guide/secure#조직-보안-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 올바르고 나쁜 권한 부여 관행을 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 향후 개선할 기회를 식별합니다. Salesforce에서 사용할 수 있는 권한 부여 도구에 대한 자세한 내용은 보안과 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/secure#보안과-관련된-도구)를 참조하십시오. ### 조직 보안 패턴 및 안티 패턴 이 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/trusted-organizational-security)에서 조직 보안에 대한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
인증 설계 표준 및 문서:
- 승인된 보안 개인 정보가 명확하게 정의되고 나열됩니다.
- 보안 매트릭스에 보안 개인 정보 및 허용된 인증 스키마(UI, API) 간 매핑이 있습니다.
설계 표준 및 문서가 있는 경우:
- 보안 개인 정보 포함 안 함
- 보안 개인 정보 및 허용된 인증 스키마에 대한 명확한 매핑이 포함된 보안 매트릭스를 포함하지 마십시오.
조직에서:
- 로그인 구성은 Salesforce MFA 점검에 부합합니다.
- Salesforce에 로그인하는 사용자와 엔티티 간의 관계는 1:1(공유 사용자 없음)
- API 액세스 제어는 사용자가 무단 연결된 앱을 통해 인증하지 못하도록 방지합니다.
- SSO가 활성화된 경우 승인된 관리자 사용자에게 직접 로그인 액세스 권한이 부여됩니다.
조직에서:
- 로그인 구성이 Salesforce MFA 점검에 일치하지 않습니다.
- Salesforce에 로그인하는 사용자와 엔티티 간의 관계는 1:1가 아닙니다(공유 사용자 계정 있음)
- 사용자가 방화벽 뒤에서 Salesforce에 액세스하는 경우 방화벽에서 하드 코딩된 IP 주소를 사용하여 Salesforce로부터의 통신을 안전하게 보호합니다.
- API 액세스 제어가 활성화되지 않음
- SSO가 활성화된 경우 승인된 관리자 사용자에게 직접 로그인 액세스 권한이 없습니다.
In LWC, Apex, Aura:
- 인증을 실행하는 메서드는 명명된 자격 증명을 사용하여 사용자 이름/암호 플로를 처리합니다.
- 읽을 수 있는 형식의 코드에 사용자 이름 또는 암호가 표시되지 않습니다(하드 코딩된 값 또는 문자열 없음).
- 사용자 정의 로그인 플로가 있는 경우 모든 관련 사용자 정의 코드가 적절한 SessionManagement 메서드를 사용합니다.
In LWC, Apex, Aura:
- 인증이 임시로 처리됩니다.
- 코드에 사용자 이름 및 암호가 표시됩니다.
승인 설계 표준 및 문서:
- Salesforce에 대한 액세스 권한이 있는 모든 사용자 및 시스템이 보안 매트릭스에서 하나 이상의 페르소나에 매핑됩니다.
- 보안 매트릭스에 메타데이터 권한 및 할당된 사용자 페르소나가 명확하게 나열됩니다.
- 향상된 권한을 부여하기 위한 사용 사례가 명확하게 나열되어 있습니다.
-- 모든 데이터 수정 권한
-- 모든 데이터 보기 권한
설계 표준 및 문서가 있는 경우:
- 보안 매트릭스를 포함하지 마십시오.
- 명확하게 권한을 나열하지 않음
- 고급 권한을 부여하기 위한 사용 사례를 명확하게 나열하지 않음
조직에서:
- 권한 집합 및 권한 집합 그룹은 메타데이터에 대한 액세스를 제어하는 데 사용됩니다.
- 비즈니스 기능에 맞춰 권한 집합 및 권한 집합 그룹
- 사용자에게 할당된 권한은 보안 매트릭스 정의를 따릅니다.
- 프로필은 최소한으로 사용되며 로그인 IP 범위 및 로그인 시간 제어에만 사용됩니다.
- 모든 통합에 대해 고유한 API 전용 통합 사용자가 구성됩니다.
조직에서:
- 권한 집합 그룹이 비즈니스 기능을 기반으로 액세스를 허용하도록 구성되지 않았습니다.
- 권한 집합이 임시로 구성됩니다.
- 권한 집합이 중복되거나 중복되는 경우, 명확한 기능 논리와 집합 간의 차이점을 이해하기 어려움
- 사용자에게 할당된 권한은 보안 매트릭스 정의를 따르지 않습니다.
- 프로필에 메타데이터에 대한 액세스 제어가 포함되어 있습니다.
- API 전용 사용자가 구성되지 않거나 둘 이상의 통합에서 공유됩니다.
Apex:
- 데이터베이스 작업은 다음을 포함하여 필드 및 개체 수준 액세스 검사를 적절하게 수행합니다.
-- DML 및 데이터베이스 DML 문은 데이터 작업 및/OR의 사용자 또는 시스템 모드를 선언합니다.
-- DML 및 Database DML 문은 데이터 작업 전에 스트립 액세스 가능 메서드를 사용합니다.
-- SOQL 및 SOSL 문은 USER_MODE 및 SYSTEM_MODE 키워드 AND/OR와 함께 사용됩니다.
-- stripInaccessible 메서드를 사용하여 쿼리 및 하위 쿼리 결과를 필터링합니다.
-- sObject describe 결과 메서드(즉, isAccessible, isCreateable, isUpdateable, 및/또는 isDeletable)가 거의 사용되지 않습니다.
Apex:
- DML, 데이터베이스 클래스 메서드, SOQL 및 SOSL이 기본 시스템 모드로 실행됩니다.
- 데이터베이스 작업에서 다음을 포함한 액세스 검사를 적절하게 수행하지 않습니다.
-- DML 또는 데이터베이스 클래스 메서드에서는 sObject 및 필드 수준 액세스에 대해 독점적으로 isAccessible, isCreateable, isUpdateable 및/또는 isDeletable 확인을 사용합니다.
-- SOQL 쿼리는 액세스 제한에 SECURITY_ENFORCED 키워드만 사용합니다.
In Flows (플로 설계에 대한 보안 고려 사항):
- 플로는 가능한 한 제한적인 실행 컨텍스트를 사용합니다. 이상적으로 사용자 모드
- 실행 컨텍스트를 최소화하기 위해 보안에 민감하거나 특권 데이터 액세스가 하위 플로에서 수행됩니다.
- 레코드 트리거 플로에서 수행되는 논리 제한
- 허용된 페이로드만 입력으로 전달되도록 플로 입력의 유효성을 검사합니다.
플로:
- 플로가 수행하는 작업에 관계없이 플로가 공유 없이 시스템 모드 또는 시스템 모드로 실행됩니다.
- 모든 플로 논리가 단일 대규모 플로 내에서 수행됩니다.
- 플로 입력은 확인되지 않고 소비자에게 전달됩니다.
## 세션 보안 세션은 기간 동안 사용자와 연결된 일련의 요청 및 응답입니다. 사용자가 Salesforce에 성공적으로 인증하면 세션이 시작됩니다. [세션 보안](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.security_overview_sessions.htm)은 세션 간섭 또는 하이재킹을 방지하여 무단 액세스 및 데이터 침해를 방지하기 위해 시스템을 구성하는 방법입니다. 시스템의 모든 사용자 활동은 세션의 컨텍스트 내에서 발생하므로 세션이 시작되는 방식, 세션 중 발생할 수 있는 상황, 사용자가 사용해야 하는 장치, 의심스러운 또는 비정상적인 세션 동작을 감지하고 대응하는 방법을 고려하는 것이 중요합니다. 세션 관리, 장치 액세스, 위협 감지 및 응답과 같은 세 가지 키에 집중하여 Salesforce에서 세션 보안을 구축할 수 있습니다. ### 세션 관리 세션은 사용자가 성공적으로 인증하고 Salesforce에 대한 액세스 권한을 얻으면 시작됩니다. 이러한 세션을 통해 플랫폼이 특정 요청 및 응답을 해당 특정 사용자와 연결할 수 있습니다. HTTPS 프로토콜을 사용하면 프런트 엔드 클라이언트와 Salesforce Platform 간의 통신을 쉽게 수행할 수 있습니다. 클라이언트에는 브라우저, 모바일 응용 프로그램, 로컬 응용 프로그램 등이 포함될 수 있습니다. HTTPS는 모든 커뮤니케이션이 개별적이며 이전 또는 향후 커뮤니케이션과 관련이 없습니다. 이 무시 접근 방식은 네트워크 통신을 가속화하고 패키지 간 링크가 끊어질 경우 발생하는 오류를 제거합니다. 그러나 웹 앱은 여러 요청 및 응답 상호 작용 전반에서 각 사용자의 ID 및 기타 관련 정보를 추적할 수 있는 방법이 필요합니다. 대부분의 웹 응용 프로그램과 마찬가지로 Salesforce는 세션 및 [토큰](https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_tokens_scopes.htm&type=5)을 사용하여 이를 수행합니다. - **세션을 통해** Salesforce에서 요청 및 응답을 사용자와 연결할 수 있습니다. 사용자가 인증되면 플랫폼이 클라이언트 앱에 세션 ID를 다시 보냅니다. 이 ID는 사용자 요청(탐색, 검색, 데이터 제출 등)과 함께 포함됩니다. - **토큰을 사용하면** 사용자와 연결된 애플리케이션이 ID를 한 번 확인하고 그 이후에 고유한 액세스 토큰을 사용할 수 있습니다. 토큰의 수명은 제한되며 특정 리소스에만 액세스할 수 있습니다(액세스 수준 구성에 대한 자세한 내용은 [승인](/docs/architect/ko-kr/well-architected/guide/secure#인증-1)을 참조하십시오). 토큰을 사용하면 사용자가 로그인할 필요 없이 권한이 있는 리소스에 액세스할 수 있습니다. 세션 및 토큰이 올바르게 보호되지 않을 경우 악의적인 작업자가 세션과 토큰을 방해하고 사용자를 가리키거나 시스템에서 악성 코드를 실행할 수 있습니다. Salesforce의 보안 세션 관리 구축: - **Salesforce에서 세션 유형을 분류하는 방법 이해** 승인된 [세션 유형](https://help.salesforce.com/s/articleView?id=sf.security_session_types.htm&type=5)을 보안 사용자 페르소나에 식별하고 매핑하고 문서에 기록합니다. - 세션이 시작되는 방법 및 세션 트래픽이 이동할 수 있는 위치 **제어** 다양한 사용자 페르소나가 시작할 수 있는 세션 유형을 식별한 후 승인되지 않은 소스 또는 컨텍스트에서 생성된 세션을 차단하도록 제어를 구성합니다. Salesforce는 다음을 포함하여 세션 출처 및 트래픽을 제어하는 몇 가지 방법을 제공합니다. - **내장 세션 보호**. Salesforce는 크로스 사이트 스크립팅, 크로스 사이트 요청 위조, [콘텐츠 스니핑](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing), [클릭재킹](https://owasp.org/www-community/attacks/Clickjacking) 등의 세션 기반 악성 활동에 대한 조직 전체 보호 기능을 자동으로 활성화합니다. 이러한 보호 기능은 비활성화해서는 안 됩니다. 일부는 비활성화할 수 없습니다. - **도메인 및 IP 범위**. 모든 Salesforce 조직에 기본적으로 [내 도메인이](https://help.salesforce.com/s/articleView?id=sf.domain_name_overview.htm&type=5) 활성화되어 있어 Salesforce 액세스를 위한 회사별 하위 도메인이 생성됩니다. 내 도메인을 통해 조직과 연결된 이름을 사용자 정의하거나 변경할 수 있습니다. 또한 Salesforce는 Experience Cloud 사이트 및 기타 응용 프로그램 페이지에 대한 추가 [도메인 구성을](https://help.salesforce.com/s/articleView?id=sf.domain_mgmt_overview.htm&type=5) 지원합니다. 참고: 사용자가 회사 방화벽 뒤에서 Salesforce에 액세스해야 하는 경우 방화벽 허용 목록에 [필수 도메인을](https://help.salesforce.com/s/articleView?id=sf.setup_domains.htm&type=5) 추가합니다. [로그인 IP 범위](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/users_profiles_epui_login_ip_ranges_edit.htm) 및 [신뢰할 수 있는 IP 범위를](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm) 설정하여 Salesforce에 대한 인바운드 로그인 및 세션 요청을 제어할 수 있습니다. - **로그인 시간** 특정 사용자 개인 정보가 작업 시간을 설정한 경우 정의된 [로그인 시간](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5) 이외에 Salesforce에 액세스할 수 있는 권한을 제한할 수 있습니다. - 추가 세션 수준 보안이 필요한 **작업 제어** 기본적으로 세션에는 표준 및 높은 보증과 같은 두 가지 종류의 [보안 수준](https://help.salesforce.com/s/articleView?id=sf.security_overview_sessions.htm&type=5)이 있을 수 있습니다. 이러한 보안 수준을 사용하여 사용자가 보고서 및 대시보드 액세스 또는 Salesforce 조직의 보안 구성 관리와 같은 활동을 수행하거나 수행할 수 없는 방법을 제어합니다. 세션 수준 보안 정책은 사용자가 작업을 수행하기 위해 [고안정 세션](https://help.salesforce.com/s/articleView?id=sf.security_auth_require_ha_session.htm&type=5)을 설정하거나 사용자가 민감한 작업을 수행하지 못하도록 차단할 수 있습니다. - 세션 기반 권한을 추가해야 하는 **작업 제어** Salesforce는 사용자에게 특정 세션 동안 권한 부여 또는 액세스 권한을 일시적으로 허용하기 위해 [세션 기반 권한](https://help.salesforce.com/s/articleView?id=sf.perm_sets_session_use.htm&type=5) 활성화를 지원합니다. 플로 또는 Salesforce API를 통해 세션 기반 권한을 활성화 및 비활성화할 수 있습니다. - 시간 초과를 통해 **비활성 사용자 세션 관리** 비활성 세션 종료는 세션 보안 관리의 핵심 부분입니다. 이렇게 하면 예를 들어 사용자가 브라우저 탭에서 Salesforce 세션을 열어두지만 다른 응용 프로그램에서 활성 상태로 작업하는 경우 또는 사용자의 모바일 장치가 Salesforce에 로그인되어 있지만 비관중인 경우 시스템을 보호할 수 있습니다. Salesforce의 기본 세션 비활성 시간 제한은 2시간입니다. 세션 비활성 시간 초과 수준을 늘리거나 줄일 수 있지만, 시간 초과를 늘리려면 강력하고 잘 문서화된 근거가 있어야 합니다. - **토큰 구성을 통해 연결된 앱 세션 관리.** 연결된 앱을 구성할 때 연결된 앱을 통해 Salesforce에 액세스하는 사용자에게 부여되는 권한 부여 범위 또는 수준도 정의합니다. 이 범위는 연결된 앱의 사용자가 성공적으로 인증한 후 발행되는 [OAuth 토큰](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US)을 통해 세션 수준에서 적용됩니다. [토큰 새로 고침 정책](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US)을 통해 토큰의 지속 기간을 제어할 수 있습니다. 조직 관리자는 필요한 경우 사용자별 및 조직별로 토큰을 수동으로 취소할 수 있습니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/secure#세션-보안-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 올바르고 나쁜 세션 관리를 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 향후 개선할 기회를 식별합니다. Salesforce에서 사용할 수 있는 세션 관리 도구에 대한 자세한 내용은 보안과 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/secure#보안과-관련된-도구)를 참조하십시오. ### 장치 액세스 현재 컨텍스트에서, *장치*는 개인이 데스크탑 워크스테이션, 노트북, 태블릿 또는 휴대폰과 같이 Salesforce에 액세스하는 데 사용할 모든 전자 장치입니다. 휴대용 장치는 사용자에게 모든 위치에서 Salesforce에 액세스할 수 있는 유연성을 제공합니다. 그러나 이 편의성은 잠재적으로 악의적인 작업자에 대한 추가 공격 벡터를 도입합니다. 이러한 위협 벡터는 공개 장소에서 자격 증명을 훔치기 위해 어깨 서핑하는 것과 같은 간단한 전술에서 장치에 악성웨어 설치 또는 데이터 전송을 가짜 공개 Wi-Fi 네트워크 만들기와 같은 더 정교한 방법까지 다양합니다. 따라서 장치(특히 휴대용 장치)를 보호하는 것은 전반적인 시스템 보안에 필수적입니다. Salesforce의 장치 액세스 보호: - **Salesforce에서 제공하는 모바일 앱 솔루션 사용** Salesforce에 액세스해야 하는 모바일 장치의 사용자가 iOS 및 Android용으로 제공되는 공식 [Salesforce 앱](https://help.salesforce.com/s/articleView?id=sf.mobile_security.htm&type=5)을 사용하도록 합니다. 비즈니스 요구에 맞춤형 모바일 솔루션이 필요한 경우 안전한 인증 및 권한 부여 방법을 제공하는 [Salesforce Mobile SDK](https://developer.salesforce.com/docs/atlas.en-us.mobile_sdk.meta/mobile_sdk/intro.htm)를 사용해야 합니다. - 세션 관리에 모바일 장치 사용을 **설계합니다**. 세션 보안 수준, 세션 시간 제한, 기타 세션 컨텍스트 제어는 모바일 장치에서 사용자가 예상하는 액세스를 고려해야 합니다. Salesforce에 액세스할 수 있는 장치 및 액세스할 수 없는 장치 및 모바일 세션에 액세스해야 하는 사용자 유형을 고려합니다. 보안 개인 정보 문서에 모바일 액세스 표준을 포함합니다. 이 주제에 대한 자세한 내용은 [세션 관리를 참조하십시오](/docs/architect/ko-kr/well-architected/guide/secure#세션-관리). - **MDM(Mobile Device Management) 기술로 장치 수준 보안을 보완합니다.** iOS 및 Android용 Salesforce 앱은 [많은 인기 MDM 제품군과 호환됩니다](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mdm.htm&type=5). 선호하는 MDM 솔루션을 통해 사용자 장치에서 Salesforce 앱에 대한 추가 액세스 제어를 구성할 수 있습니다. - **MAM(Mobile Application Management) 기술을 사용하여 앱 수준의 보안을 보완합니다**. MAM 기술은 모바일 장치에서 앱 수준 컨트롤을 지원합니다. Salesforce는 Salesforce 모바일 앱용 유료 [MAM 추가 기능](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mam_overview.htm&type=5)을 제공합니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/secure#세션-보안-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 장치 관리가 제대로 진행되었는지 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 향후 개선할 기회를 식별합니다. Salesforce에서 사용할 수 있는 장치 관리 도구에 대한 자세한 내용은 보안과 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/secure#보안과-관련된-도구)를 참조하십시오. ### 위협 감지 및 대응 위협 감지는 악의적인 활동을 나타낼 수 있는 시스템의 동작 패턴을 식별하는 프로세스입니다. 평균보다 큰 데이터를 다운로드하거나 사용자가 평균보다 짧은 기간 내에 여러 레코드에서 중요한 데이터를 포함하는 필드를 수정하는 경우가 있습니다. 위협에 대한 대응에는 자동 세션 만료, 경고 및 기타 알림이 포함될 수 있습니다. 위협 감지는 잠재적인 문제를 가능한 한 빨리 식별하고 대응하는 것입니다. 실시간 위협 감지를 기반으로 조치를 취하면 추적 중인 악성 동작을 중지할 수 있습니다. Salesforce는 추가 기능 또는 [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/)의 일부로 [실시간 이벤트 모니터링](https://help.salesforce.com/s/articleView?id=sf.real_time_event_monitoring_overview.htm&type=5)을 제공합니다. 민감도가 높은 응용 프로그램이 있거나 강력한 실시간 위협 감지 및 대응 기능이 필요한 경우 다음 솔루션 중 하나를 사용하십시오. Salesforce 솔루션에 대한 효과적인 위협 감지 및 대응 전략 구축: - **내장된 감사 기능 사용** Salesforce는 조직의 변경 사항을 추적하고 감사할 수 있는 다양한 [내장 도구를](https://help.salesforce.com/s/articleView?id=sf.monitoring_admin.htm&type=5) 제공합니다. 예를 들어, [설정 감사 내역](https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5)을 통해 관리 작업의 감사 내역을 볼 수 있습니다. Salesforce는 기본적으로 제한된 기간 동안 필드 수준 변경 사항을 추적하지만, UI에서 최대 18개월, API를 통해 최대 24개월 동안 필드 변경 사항을 표시하도록 [필드 내역 추적](https://help.salesforce.com/s/articleView?id=sf.tracking_field_history.htm&type=5)을 활성화할 수 있습니다. 또한 [Field Audit Trail](https://help.salesforce.com/s/articleView?id=sf.field_audit_trail.htm&type=5)을 활성화하여 데이터를 수동으로 삭제할 때까지 필드 수준 변경 사항에 대한 감사 내역을 무기한으로 유지할 수 있습니다. - **정기적인 감사 검토 수립** 감사는 실시간 위협 감지가 놓칠 수 있는 비정상적인 변경 사항을 식별하는 데 매우 중요합니다. 합법적인 액세스 권한이 있는 사용자가 연장 기간 동안 매일 소수의 레코드를 지속적으로 삭제하는 시나리오를 고려하십시오. 이 사용자에게 유효한 로그인 자격 증명, 레코드를 삭제할 수 있는 적절한 권한 부여가 있고 한 번에 대량의 레코드를 삭제하지 않으므로 활동이 실시간 위협으로 감지될 가능성이 거의 없습니다. 그러나 사용자 활동 보고서를 검토하는 감사 팀은 시간 경과에 따라 단일 사용자가 과도하게 레코드를 삭제하는 추세를 명확하게 식별하여 쉽게 해결할 수 있습니다. [거버넌스 정책](/docs/architect/ko-kr/well-architected/guide/intentional#거버넌스)의 일환으로 로그인 내역, 사용자 세션 활동 및 연결된 앱 사용을 감사하기 위한 정기적인 간격을 설정합니다. - **위협 대응 전략을 개발하고 보안 정책에 포함합니다**. 다음을 포함하는 위협 대응 전략을 만듭니다. - 위협 대응 유형 정의(예: 경고 및 자동화) 및 이해당사자 [그룹 참여](/docs/architect/ko-kr/well-architected/guide/resilient#사고-대응) 메시지 또는 경고 설계에 대한 자세한 내용은 [오류 및 알림](/docs/architect/ko-kr/well-architected/guide/engaging#알림-및-메시지)을 참조하십시오. - 위협으로 간주될 수 있는 실시간 변경 사항 또는 활동에 대한 특정 범주 및 각각의 관련 응답 유형 - 모든 자동화된 위협 대응(예: 토큰 취소, 세션 종료, 사용자 계정 비활성화 또는 자원 액세스 차단) 및 자동화 트리거의 명확한 목록 이벤트 모니터링은 실시간 위협 감지 및 대응을 활성화하여 이 원칙을 적용하는 데 필요한 데이터를 제공합니다. 트랜잭션 보안은 회사의 정책 중심 작업을 적용하며, 이벤트 유형은 시간에 따른 사용자 및 응용 프로그램 액세스 모니터링을 지원합니다. Salesforce의 기본 위협 감지 서비스는 통계 및 기계 학습 모델을 사용하여 의심스러운 동작을 식별합니다. 이 서비스는 사이버 공격 및 의심스러운 데이터 액세스를 방지하는 특정 이벤트를 생성합니다. 트랜잭션 보안은 조직에서 발생하는 주요 이벤트를 가로채고 회사의 정책 중심 작업을 적용하는 프레임워크를 제공하므로 보안을 한 단계 더 발전시킵니다. 이렇게 하면 이벤트 모니터링이 로깅 도구에서 자동화된 보안 방어의 중요한 구성 요소로 전환됩니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/secure#세션-보안-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 위협 감지 및 대응이 제대로 진행되었는지 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 향후 개선할 기회를 식별합니다. Salesforce에서 제공하는 위협 감지, 경고 및 응답 자동화 도구에 대한 자세한 내용은 보안과 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/secure#보안과-관련된-도구)를 참조하십시오. ### 세션 보안 패턴 및 안티 패턴 이 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/trusted-session-security)에서 세션 보안에 대한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
세션 관리 설계 표준 및 문서:
- 보안 개인 정보가 각 개인 정보에 대해 승인된 세션 유형 및 시간 초과/기간 설정을 명확하게 나열합니다.
- 로그인 시간이 지정되었거나 필요하지 않은 것으로 식별됨
- 세션 수준 보안 또는 권한이 강화되어야 하는 작업을 명확하고 검색 가능
- 연결된 앱 범위 및 토큰 관리 정책이 명확하고 검색 가능
설계 표준 및 문서:
- 세션 유형 및 시간 제한/기간 설정에 대한 보안 개인 정보가 없거나 정보가 누락된 경우
- 보안 정책에 연결된 앱 범위 또는 토큰 관리에 대한 정보가 포함되어 있지 않습니다.
조직에서:
- 세션 감사 시 사용자가 예상 세션 유형을 통해 Salesforce에만 액세스하는 것이 표시됩니다.
- "API 전용 사용자" 액세스에 대한 명확하고 활성 권한 집합이 있으며("API 전용" 권한 집합이 TRUE로 설정됨) 모든 통합 및 자동화된 사용자가 할당됩니다.
- 사용자가 방화벽 뒤에서 Salesforce에 액세스하는 경우 방화벽은 IP 주소 대신 필수 도메인의 허용 목록을 사용하여 Salesforce로의 통신을 안전하게 보호합니다.
- 비활성 세션 시간 초과 간격이 기본값을 초과하지 않습니다(2시간).
- 다음 설정이 모두 활성화됩니다.
-- 설정 페이지의 클릭잭 방어
-- 비설정 Salesforce 페이지의 클릭잭 방어
-- 교차 사이트 요청 위조(CSRF) 보호
-- 교차 사이트 스크립팅(XSS) 보호
-- 콘텐츠 스니핑 방어 활성화
-- 참조 페이지 URL 보호
-- Salesforce 외부로 리디렉션되기 전에 사용자에게 경고
조직에서:
- 정기적인 세션 감사가 없습니다.
- 사용자가 보유해야 하는 세션 유형에 대한 정의가 없습니다.
- "API 전용" 권한이 명확하지 않거나 통합 및 자동화된 사용자에서 누락됨
- 사용자가 방화벽 뒤에서 Salesforce에 액세스하는 경우 방화벽에서 하드 코딩된 IP 주소를 사용하여 Salesforce로부터의 통신을 안전하게 보호합니다.
- 비활성 세션 시간 초과 간격이 기본값을 초과합니다(2시간).
- 다음 설정이 비활성화됩니다.
-- 설정 페이지의 클릭잭 방어
-- 비설정 Salesforce 페이지의 클릭잭 방어
-- 교차 사이트 요청 위조(CSRF) 보호
-- 교차 사이트 스크립팅(XSS) 보호
-- 콘텐츠 스니핑 방어 활성화
-- 참조 페이지 URL 보호
-- Salesforce 외부로 리디렉션되기 전에 사용자에게 경고
In LWC, Apex, Aura:
- 사용자 정의 로그인 플로가 있는 경우 모든 관련 사용자 정의 코드에서 적절한 SessionManagement 메서드를 사용하여 세션 수준 보안을 할당합니다.
In LWC, Apex, Aura:
- 사용자 정의 로그인 플로가 있는 경우 세션 수준 보안을 할당하는 논리가 없습니다.
장치 액세스 설계 표준 및 문서:
- 명확하고 검색 가능한 장치 정책
- 보안 개인 정보가 적절한 장치 사용 및 정책에 명확하게 매핑됩니다.
설계 표준 및 문서:
- 보안 정책이 없거나 장치 액세스에 대한 정보가 포함되어 있지 않습니다.
조직에서:
- 비활성 상태에서 PIN/암호 코드 잠금 해제가 필요한 Salesforce 모바일 연결된 앱 구성
- 비즈니스 요구에 따라 Salesforce 모바일에 액세스할 수 있는 사용자를 엄격하게 제어해야 하는 경우 API 액세스 제어가 활성화되고 Salesforce 모바일 앱의 모든 사용자에게 권한 집합이 할당됩니다.
조직에서:
- 비활성 상태에서 PIN/암호 잠금 해제를 요구하도록 Salesforce 모바일 연결된 앱이 구성되지 않았습니다.
– 비즈니스 요구에 따라 Salesforce 모바일에 액세스할 수 있는 사용자를 엄격하게 제어해야 하지만 API 액세스 제어가 활성화되어 있지 않거나 권한 집합이 Salesforce 모바일 앱에 대한 액세스를 제어하는 데 사용되지 않습니다.
위협 감지 및 대응 설계 표준 및 문서:
- 보안 정책에 적절한 응답 유형과 함께 응답을 트리거해야 하는 이벤트 목록이 포함되어 있습니다.
- 데이터 모델의 모든 개체에 대해 감사 수준이 지정되었습니다.
- Salesforce에서 사용 가능한 로그를 검토하는 단계가 문서화되어 있습니다.
- 모든 자동 응답이 명확하게 문서화됩니다.
설계 표준 및 문서:
- 보안 정책이 없거나 위협 감지 및 경고에 대한 정보가 포함되어 있지 않습니다.
- 자동 응답 문서가 없거나 명확하지 않음
회사 내부:
- 감사 데이터는 비즈니스 이해당사자가 이해하고 액세스할 수 있는 보고서에서 사용할 수 있습니다.
- 감사 내역 및 보고서가 정기적으로 검토됩니다.
회사 내부:
- 감사 데이터는 액세스 및 해석에 대한 주제 전문 지식이 필요한 로그 파일을 통해서만 사용할 수 있습니다.
- 감사 정보를 검토하는 프로세스가 없는 경우
조직에서:
- 비정상적인 사용이 감지된 경우 사용자 계정을 비활성화하거나 리소스에 대한 액세스를 실시간으로 차단하여 위협에 대응하는 자동화가 있습니다.
- 비정상적인 활동에 대해 적절한 사용자에게 알리도록 알림 및 경고가 구성됩니다.
- 비공개 또는 중요한 데이터가 포함된 모든 필드에 대해 필드 내역 추적이 활성화됩니다.
조직에서:
- 위협에 대처하기 위한 자동화 기능이 없습니다.
- 알림 및 경고가 적절한 사용자에게 비정상 활동에 대해 알리도록 구성되어 있지 않거나 비정상 활동과 관련된 일부 알림 및 경고가 있지만 임시로 제공됩니다.
- 비공개 또는 중요한 데이터가 포함된 필드에 대해 필드 내역 추적이 일관되게 활성화되지 않습니다.
## 데이터 보안 데이터 보안은 무단 액세스, 손상 또는 의도하지 않은 삭제로부터 데이터를 보호하는 방법입니다. 데이터 보안은 전송 중 및 유지 중에 모두 데이터를 보호하는 작업에 포함됩니다. 강력한 데이터 보안은 시스템에 대한 무단 액세스로 인한 위험 및 잠재적인 손상을 최소화합니다. 데이터 보안이 부적절하면 고객 및 회사에 심각한 영향을 미칠 수 있는 데이터 침해에 시스템이 취약해집니다. 따라서 데이터를 보호하는 것은 보안 아키텍처를 구축하는 데 매우 중요합니다. 데이터 보안을 향상하려면 Salesforce 내에서 분류와 함께 데이터로 간주되는 내용을 명확하게 이해해야 합니다. Salesforce 조직 내에 저장된 개별 레코드, 파일 및 문서는 해당 데이터입니다. 메타데이터와 데이터의 구분에 대한 자세한 내용은 [Salesforce 아키텍처 기본 사항](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#메타데이터와-데이터-비교)을 참조하십시오. 공유 및 가시성 및 암호화 사용에 중점을 두어 Salesforce 솔루션에서 더욱 강력한 데이터 보안을 구축할 수 있습니다. > 참고: 데이터 보안을 위해 설계할 때 두 개의 개념이 솔루션의 전체적인 데이터 보안에 영향을 미치므로 [데이터 보안](/docs/architect/ko-kr/well-architected/guide/compliant#데이터-프라이버시)뿐 아니라 [아카이빙 및 정리](/docs/architect/ko-kr/well-architected/guide/resilient#연속성-계획)도 고려하십시오. ### 데이터 분류 민감도(예: 공개, 내부, 기밀, 제한)를 기반으로 Salesforce Platform에 저장된 모든 데이터를 식별하고 분류합니다. 각 데이터 유형을 처리하고 보호하는 방법을 간략하게 설명하는 명확한 **데이터 분류 정책**을 정의합니다. 필드 수준 보안, 암호화, 데이터 마스킹과 같은 적절한 보안 제어를 구현하여 정책을 적용하고 무단 액세스 또는 노출으로부터 중요한 데이터를 보호합니다. 해당 분류 및 제어를 정기적으로 검토하고 감사하여 비즈니스 및 규정 준수 요구 사항에 부합하는지 확인합니다. ### 공유 및 가시성 공유 및 가시성은 사용자가 Salesforce 내에서 데이터에 액세스하는 방법을 제어할 수 있도록 시스템을 구성합니다. 공유 및 가시성은 사용자가 액세스할 수 있는 개별 레코드를 제어하지만 이러한 설정만으로는 특정 레코드로 사용자가 수행할 수 있는 작업이나 해당 레코드 내의 표시되는 특정 필드를 제어하지 않는다는 점에 유의해야 합니다. 데이터 작업 수행 권한(예: [CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm))은 개별 개체 및 필드 수준에서 사용자에 대해 구성할 수 있는 메타데이터 액세스 제어를 통해 사용자에게 할당됩니다. 이에 대한 자세한 내용은 [승인](/docs/architect/ko-kr/well-architected/guide/secure#인증-1)을 참조하십시오. Agentforce 작업은 일반적으로 직접 액세스 권한이 없는 인증된 사용자와 익명 사용자 모두에게 데이터를 노출할 수 있습니다. Agentforce 에이전트를 구축할 때 에이전트에 할당된 모든 작업을 주의 깊게 고려하고 문서화하십시오. 각 작업에 대해 다음을 이해해야 합니다. - 작업이 액세스할 수 있는 데이터입니다. - 작업이 실행되는 보안 컨텍스트입니다. - 작업에 에이전트 세션에 민감하거나 제한된 데이터를 통합할 수 있는 Knowledge 검색 또는 기타 기능이 있는지 여부 Salesforce에서 효과적인 공유 및 가시성 구성: - 의미 있는 작업 기능을 둘러싼 **액세스 설계** [사용자 페르소나](/docs/architect/ko-kr/well-architected/guide/secure#인증)를 수행할 비즈니스 기능에 매핑하는 보안 매트릭스를 만듭니다. 이 [템플릿을](/docs/architect/ko-kr/resources/guide/security-policy-template) 기본으로 사용하여 공유 및 가시성을 설계합니다. 의미 있는 비즈니스 기능을 식별하는 방법에 대한 자세한 내용은 [ 기능 단위](/docs/architect/ko-kr/well-architected/guide/composable#기능-단위)를 참조하십시오. - 최소 권한 원칙을 적용하는 가장 간단한 경로를 **선택하십시오**. 공유 및 가시성 계획을 설계할 때 최소 권한의 [원칙](/docs/architect/ko-kr/well-architected/guide/secure#인증-1)을 적용할 때 가장 간단한 방법으로 하십시오. 시스템 유지 관리, 확장성, 적응성에 다운스트림 문제가 발생할 수 있는 과도하게 설계된 데이터 제한 및 공유 스키마를 방지합니다. 대신 Salesforce의 [유연하고 계층화된 데이터 공유](https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/sharing_architecture.pdf)를 활용하여 데이터 수준에서 사용자 액세스를 위한 세분화된 규칙을 구성합니다. - **비즈니스에서 중요한 데이터를 처리하지 않는 한 _내부_ 조직 전체 기본값(OWD)을 공용 읽기 전용으로 설정한 후 비공개를 사용합니다**. OWD는 데이터 수준에서 사용자가 보유할 "최소" 권한 수준을 제어합니다. OWD 수준에서 액세스를 제한할 수 없습니다. 비공개 OWD는 모든 사용 사례에 이상적인 것처럼 보일 수 있지만 비즈니스 전반의 사용자는 종종 복잡한 공유 스키마를 통해 더 권한이 많은 OWD를 실수로 복제하는 경우가 있습니다. 또한 비공개 OWD로 인해 사용자가 중복 데이터를 만들 수 있습니다. 데이터 용량 및 상위-하위 또는 소유권 왜곡에 따라 공유 계산(및 재계산)을 완료하는 데 상당한 시간이 소요될 수 있습니다. 비공개 OWD는 이 상황을 악화합니다. OWD는 CRUD 권한 및 필드 수준 가시성을 제어하지 않는다는 점에 유의해야 합니다. 비즈니스 요구 사항에 따라 정당화되는 경우에만 OWD를 선택하십시오. 일반적으로 이러한 정당화는 [규정 준수](/docs/architect/ko-kr/well-architected/guide/compliant)와 관련이 있습니다. - ** _외부_ 조직 전체 기본값(OWD)을 강력한 비즈니스 이유가 있는 경우를 제외하고 비공개로 설정합니다**. Experience Cloud 사이트, 포털 등에서 Salesforce 데이터에 액세스하는 사용자에게는 [외부 OWD](https://help.salesforce.com/s/articleView?id=sf.security_owd_external.htm&type=5)가 적용됩니다. 이렇게 하면 내부 및 외부 사용자에 대해 별도의 OWD 기준선을 구성하여 다양한 유형의 "최소" 권한을 허용할 수 있습니다. 항상 외부 사용자의 OWD를 비공개로 설정합니다. 더 개방적인 수준의 예외는 비즈니스 요구에 따라 명확하게 근거가 있어야 합니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/secure#데이터-보안-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 올바른 공유 및 가시성을 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 향후 개선할 기회를 식별합니다. Salesforce의 공유 및 가시성 도구에 대한 자세한 내용은 보안과 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/secure#보안과-관련된-도구)를 참조하십시오. ### 암호화 사용 암호화는 읽을 수 있는 데이터를 암호화되지 않는 인코딩 형식으로 변환합니다. 암호화된 데이터는 키를 통해 해독하거나 원래 형태로 다시 번역할 수 있습니다. 따라서 암호화는 데이터를 보존하고 전송하는 동안 모두 보호하는 가장 효과적인 방법 중 하나이며, 무단 당사자가 데이터에 액세스하는 경우에도 데이터를 읽을 수 없습니다. Salesforce 솔루션에서 암호화를 적절하게 사용하도록 설계: - **항상 전송 중인 데이터를 적절하게 암호화하십시오**. Salesforce는 [Salesforce에서 지원하는 브라우저에서](https://help.salesforce.com/s/articleView?id=sf.getstart_browser_overview.htm&type=5) 발생하는 모든 세션에 [TLS(Transport Layer Security)를 적용하며](https://help.salesforce.com/s/articleView?id=sf.security_overview_infrastructure.htm&type=5), HTTPS를 사용하는 아웃바운드 호출이 특정 보안 표준을 충족하도록 요구합니다. 플랫폼 API는 기본적으로 HTTPS도 사용합니다. 또한 Salesforce Experience Cloud 사이트 또는 포털과 관련 Salesforce 조직 간에 전송되는 데이터는 [기본적으로](https://help.salesforce.com/s/articleView?id=xcloud.security_pe_platform_encryption_faq.htm&type=5) 암호화됩니다. Salesforce의 [내장형 이메일 서비스를](https://help.salesforce.com/s/articleView?id=sf.emailadmin_send_email_from_salesforce_overview.htm&type=5) 사용하는 경우 Salesforce에서 이메일을 [전송하고 수신 시도하기 위해](https://help.salesforce.com/s/articleView?id=sf.emailadmin_deliverability.htm&type=5) 사용하는 TLS(Transport Layer Security)의 기본 수준이 있습니다. 명확한 비즈니스 근거가 없으면 최소한 조직 설정이 기본 설정보다 낮지 않아야 합니다. 데이터 분류 및 민감도를 기반으로 AWS Direct Connect 또는 Salesforce Private Connect를 통해 Salesforce에 대한 비공개 네트워크 연결을 활용하는 것이 좋습니다. 이렇게 하면 데이터가 공개 인터넷을 이동하지 않고 사용자 액세스 및 통합을 위해 비공개 네트워크 연결을 통해 안전하게 흐릅니다. - **비즈니스에서 요구하는 경우 데이터를 암호화 상태로 유지합니다**. Salesforce는 데이터를 암호화하는 다양한 방법을 제공합니다. - **Hyperforce**. 데이터는 [Hyperforce](/docs/architect/ko-kr/fundamentals/guide/platform-multitenant-architecture#hyperforce)를 사용하는 조직에서 암호화된 상태로 유지됩니다. 암호화는 Salesforce에서 조직에 대해 관리합니다. 자체 암호화 키를 만들거나 폐기할 수 없습니다. - **Salesforce Shield**. [Salesforce Shield를 사용하면](https://www.salesforce.com/products/platform/products/shield/) 응용 프로그램 및 데이터베이스 계층을 비롯한 추가 계층에서 Salesforce 조직의 데이터를 암호화할 수 있습니다. Shield를 사용하면 강력한 BYOK(Bring Your Own Key) 옵션 등 테넌트의 암호화 키에 대한 전체 관리 기능을 사용할 수 있습니다. 또한 비정형 데이터(파일, 첨부 파일, 검색 색인, 이벤트 포함)를 암호화할 수 있습니다. Hyperforce 기반 인스턴스는 외부 키 관리자를 사용하여 자체 AWS KMS를 가져올 수 있는 옵션을 제공합니다. 이 기능을 사용하면 Salesforce에 저장된 데이터를 암호화 및 해독하는 데 사용되는 KMS 내의 암호화 키를 완벽하게 제어하여 보안을 강화하고 조직의 규정 준수 요구 사항에 부합할 수 있습니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/secure#데이터-보안-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 암호화의 올바르고 나쁜 사용을 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 향후 개선할 기회를 식별합니다. Salesforce에서 사용할 수 있는 암호화 도구에 대한 자세한 내용은 보안과 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/secure#보안과-관련된-도구)를 참조하십시오. ### 데이터 보안 패턴 및 안티 패턴 이 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/trusted-data-security)에서 데이터 보안에 대한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
공유 및 가시성 설계 표준 및 문서:
- 보안 매트릭스는 각 사용자 페르소나가 액세스 권한을 부여받은 데이터를 간략하게 보여줍니다.
- 해당되는 경우 외부 사용자 및 내부 사용자에 서로 다른 데이터 액세스 표준이 사용됩니다.
설계 표준 및 문서:
- 설계 표준 및 문서가 없거나 보안 매트릭스를 포함하지 않습니다.
- 보안 매트릭스가 있는 경우 사용자 페르소나에 대한 데이터 액세스를 간략하게 표시하지 않습니다.
조직에서:
- 내부 사용자의 조직 전체 기본값(OWD)은 공용 읽기 또는 내부 사용자의 OWD는 규정 준수 요구 사항으로 인해 비공개입니다.
- 외부 사용자의 OWD는 비공개입니다.
- 생성형 AI는 사용자 모드에서만 작동하거나 명확한 비즈니스 근거가 있는 시스템 액세스에 대한 일부 사용
조직에서:
- 내부 사용자의 OWD는 비즈니스 근거 없이 비공개로 설정되거나 내부 사용자의 OWD는 공용 읽기/쓰기로 설정됩니다.
- 비즈니스 근거 없이 외부 사용자의 OWD는 비공개 이외의 모든 항목으로 설정됩니다.
- 생성형 AI는 비즈니스 근거 없이 시스템 모드에서 작동
Apex:
- 모든 코드가 데이터 액세스(SOQL/SOSL) 또는 데이터 작업 수행(DML/데이터베이스 클래스 메서드) 공유 키워드 사용
Apex:
- 키워드가 일관되지 않게 사용되는 공유
암호화 사용 설계 표준 및 문서:
- 전송 중(필요한 경우) 데이터 암호화를 위한 사용 사례가 명확하고 검색 가능
- 승인된 암호화 프로토콜이 명확하게 나열됩니다.
- 코드 문서에 암호화가 사용되는 위치 및 사용되는 프로토콜이 명확하게 표시됩니다.
설계 표준 및 문서:
- 승인된 암호화 프로토콜이 명확하지 않거나 나열되지 않음
- 코드가 문서화되지 않았거나 코드에서 암호화가 사용되는 위치와 방법에 대한 문서가 명확하지 않습니다.
조직에서:
- 보안 위험이 파악되었으므로 데이터를 보호해야 하는 경우 Hyperforce 또는 Salesforce Shield 암호화를 제공합니다.
조직에서:
- 비즈니스 요구에 따라 데이터 보호 수준이 높아지지만 Hyperforce 및 Salesforce Shield 사용되지 않습니다.
Apex:
- 비즈니스 요구 사항이 전송 시 더 높은 데이터 보호를 요구하는 경우 통합과 관련된 모든 코드는 Crypto Class 방법을 사용하여 전송 전에 데이터를 암호화하거나 수신 시 데이터를 암호 해독합니다.
Apex:
- 비즈니스 요구에 따라 전송 시 더 높은 수준의 데이터 보호가 필요하지만 통합과 관련된 코드는 전송 전이나 수신 시 데이터를 암호화하지 않고 논리를 수행하거나 Crypto Class 메서드가 임시로 사용됩니다.
## 보안과 관련된 도구
도구설명조직 보안세션 보안데이터 보안
Apex Crypto 클래스Apex 데이터 암호화 및 해독X
API 액세스 제어Salesforce API 및 연결된 앱에 대한 액세스 관리X XX
API 변칙 이벤트사용자가 API를 호출하는 방식의 변칙 추적X
브라우저 보안 설정중요한 데이터 보호 및 SSL 인증서 모니터링X
인증서 기반 인증고유한 디지털 인증서를 사용하여 개인 인증XX
인증서 및 키Salesforce에서 외부 웹 사이트에 대한 요청 확인XX
코드 스캐너보안 취약점에 대한 Apex 코드 스캔XX
연결된 앱API 및 표준 프로토콜을 통한 통합XX
자격 증명 채우기 이벤트도난된 사용자 자격 증명을 사용하는 시도된 로그인 추적X
CSP Trusted Site코드 삽입 공격 방지(예: 교차 사이트 스크립팅)X
사용자 정의 로그인 플로사용자의 로그인 비즈니스 프로세스 제어X
고객 ID웹 사이트 및 앱 로그인 및 확인 제어X
Data MaskSandbox에서 중요한 데이터 자동 마스킹X
디버그 로그조직에서 발생하는 이벤트 추적X
위임 관리관리자가 아닌 사용자에게 제한된 관리자 권한 할당XX
장치 활성화신뢰할 수 없는 브라우저, 장치 또는 IP 범위에서 로그인 확인X
고급 트랜잭션 보안이벤트 가로채기, 사용자 활동 모니터링 및 제어X
필드 액세스필드 수준에서 데이터 액세스 제어X
현장 감사 내역보관된 필드 내역 데이터를 보존하는 정책 정의X
필드 내역 추적필드 내역 추적 및 표시X
Frontdoor.jsp기존 세션 ID 및 서버 URL을 사용하여 액세스 허용X
Heroku ConnectHeroku와 Salesforce 간의 양방향 동기화X
Herooku ShieldHIPAA 또는 PCI 호환 앱 구축X
높은 보증 세션 보안민감한 작업에 추가 보안 필요X
Identity Connect사용자 레코드를 Active Directory 계정에 매핑X
ID 확인 내역사용자 ID 확인 시도 감사X
통합 사용자 라이센스API를 통해서만 데이터 및 기능에 대한 액세스 권한을 부여합니다.XX
Lightning Login약하거나 잊혀진 암호 및 잠긴 계정 방지X
로그인 액세스지원 사용자가 다른 사용자로 로그인하도록 허용X
로그인 포렌식ID 사기를 나타낼 수 있는 동작 식별X
로그인 내역조직 및 Experience Cloud 사이트 로그인 시도 모니터링X
모바일 장치 추적조직에 대한 모바일 장치 액세스 추적 및 모니터링X
Mobile SDK독립형 모바일 앱 내에서 Salesforce Platform에 연결XXX
사용자 권한 모니터링(Shield)권한 집합 및 권한 집합 그룹 변경 사항XX
다단계 인증로그인을 위해 2개 이상의 확인 메서드 필요XX
상호 인증SSL 또는 TLS 상호 인증 적용
내 도메인로그인 페이지 및 정책, SSO, 소셜 로그인 구성X
명명된 자격 증명끝점 URL 및 인증 매개 변수 지정X
OAuth 인증토큰 교환을 통한 클라이언트 응용 프로그램 액세스 권한 부여 X
암호 정책암호 내역, 길이, 복잡성 설정X
권한 집합 할당 만료권한 집합 및 권한 집합 그룹 할당에 대한 만료 설정XX
권한 집합 이벤트권한 집합 및 권한 집합 그룹에 대한 변경 사항 모니터링XX
권한 집합 그룹복잡한 액세스 요구 사항을 지원하는 번들 권한 집합X
권한 집합사용자가 메타데이터, 기능 및 앱에 액세스하는 방법 제어X
개인 연결Salesforce와 Amazon 웹 서비스 간의 안전한 통합X
프로필로그인 IP 범위 및 로그인 시간 제어X
실시간 이벤트 모니터링Salesforce에서 표준 이벤트 모니터링 및 감지 X
원격 사이트 설정Apex 또는 JavaScript 호출에 대한 외부 사이트 등록X
보고 변칙 이벤트사용자가 보고서를 실행하거나 내보내는 방식의 변칙 추적X
제한 규칙사용자가 불필요한 레코드에 액세스하지 못하도록 방지X
Salesforce 코드 분석기IDE, CLI 또는 CI/CD를 통해 코드를 스캔하여 모범 사례를 준수하는지 확인합니다.XX
스코핑 규칙사용자가 볼 수 있는 기본 레코드 제어X
보안 센터모든 조직 전반의 보안 설정 보기 및 자세 변경에 대한 경고 구성XX
보안 상태 점검보안 설정에서 취약점 식별X
세션 하이재킹 이벤트도난 세션 식별자를 통한 무단 액세스 식별X
세션 관리 클래스활성 세션에 대한 보안 설정 사용자 정의X
세션 보안 설정세션을 구성하여 악성 공격으로부터 보호X
설정 감사 내역관리자가 적용한 최근 설정 변경 사항 추적X
공유 설정레코드 수준에서 데이터 액세스 제어X
Shield Platform Encryption유지 및 전송 중 중요한 데이터 암호화X
단일 등록단일 로그인을 통해 여러 응용 프로그램에 대한 액세스 제공XX
Cross-Domain Identity Management(SCIM) 시스템REST API를 통해 시스템 전반의 ID 관리X
위협 감지통계 및 기계 학습을 사용하여 위협 감지X
신뢰할 수 있는 IP 범위추가 확인이 필요하지 않은 IP 주소 정의X
사용자 액세스 보고서사용자의 개체, 레코드, 권한 액세스에 대한 통합 보기 가져오기XX
## 보안과 관련된 자원
자원설명조직 보안세션 보안데이터 보안
공유 아키텍처 가이드액세스 도구, 공유 모델, 사용 사례에 대해 자세히 알아보기X
설계 표준 템플릿조직에 대한 설계 표준 만들기XXX
사용자 보안 모델 구축 방법사용자 보안 모델을 더 잘 이해XX
Salesforce에서 최소 권한 원칙 구현 방법Salesforce에서 PoLP 데이터 액세스 제어 적용에 대해 알아보기XX
사용자 세션 모니터링활성 세션 검토 및 의심스러운 세션 종료X
다단계 인증Salesforce에서 공식 MFA 리소스에 액세스X
권한 집합 그룹(Trailhead)권한 집합 그룹 활용XX
REST API 아키텍처REST API 용어 및 개념 이해XXX
보안 및 SOAP APISOAP API 용어 및 개념 이해XXX
API 및 내부 시스템 사용자를 위한 보안 모범 사례API 사용자 및 보안 내부 시스템 사용자가 Salesforce에 안전하게 액세스X
보안 구현 가이드Salesforce 보안을 포괄적으로 살펴봅니다.XXX
보안 정책 템플릿조직에 대한 보안 정책 설정XXX
세션 유형조직에 액세스하는 데 사용되는 세션 유형 식별X
위협 모델링 기본 사항(Trailhead)보안 위협 및 방지 방법에 대해 알아봅니다.X
## 의견을 알려주십시오. Salesforce Well-Architected의 관련성을 유지할 수 있도록 도와주십시오. 이 콘텐츠에 대한 사용자 의견을 제공하려면 [ 설문 조사](https://sfdc.co/bxNtvh)을 작성하고 다음에 원하는 내용을 알려주십시오. > [여기에](/docs/architect/ko-kr/well-architected/guide/contributors) 업데이트 일정에 대해 알아보십시오. ## 소개 의도적인 솔루션은 즉시 시간에 따라 비즈니스 가치를 제공합니다. 의도적인 아키텍처는 전략적으로 계획 및 전달되며, 효과적으로 유지 관리할 수 있으며, 사람이 쉽게 읽고 이해할 수 있습니다. 기능 및 수정 사항은 비즈니스 및 기술 이해당사자 모두에게 투명한 방식으로 우선 순위가 지정되고 전달됩니다. 엔지니어링 선택 항목은 추가 기능이나 복잡성 없이 배달 및 서비스 점검 팀이 쉽게 작업할 수 있는 구현을 만듭니다. 명확하고 일관된 구현 패턴을 따르므로 비즈니스에서 의도된 아키텍처를 더욱 쉽게 소유, 유지, 발전할 수 있습니다. 빌더는 새 기능에 대한 설계를 해석하고 구현할 수 있으며, 서비스 점검 팀은 구현된 내용의 문서를 이해할 수 있습니다. 전략, 유지 관리, 가독성과 같은 세 가지 핵심 영역에 집중하여 더 의도적인 시스템을 만들 수 있습니다. ## 전략 아키텍처의 전략은 시스템이 신중하게 계획되고 전달되었음을 의미합니다. 즉, 배달 및 서비스 점검 팀이 오늘과 향후 수행할 작업을 명확하게 파악하고 모든 사람이 수행할 작업의 "왜"에 부합한다는 의미입니다. 즉, 긴급한 요청을 효율적이고 효율적으로 분류할 수 있으며 이해당사자가 요청의 영향 및 제약을 명확하게 이해할 수 있습니다. 우선 순위, 로드맵, 거버넌스에 집중하여 아키텍처에 명확한 전략을 구축할 수 있습니다. ### 우선 순위 지정 우선 순위 지정은 배달할 작업의 순서 및 범위를 계획하는 것을 의미합니다. 우선 순위 지정에는 비즈니스에 대한 배달의 실제 영향을 이해하고 다른 작업 요청 및 제품 또는 프로그램에 대한 전체 로드맵에 대한 영향을 평가하는 작업이 수반됩니다. 지정된 작업 항목의 영향을 평가하는 한 가지 방법은 비즈니스에 대한 실제 비용 또는 이점을 살펴보는 것입니다. 자동화에 대한 [KPI를](/docs/architect/ko-kr/well-architected/guide/automated#kpi) 파악한 후에는 [비즈니스 영향 계산 워크시트](/docs/architect/ko-kr/resources/guide/kpi-spreadsheet-template)를 사용하여 구현의 전체 비용 또는 이점을 평가할 수 있습니다. 해당 계산을 통해 구축할 자동화와 순서에 대한 이해당사자의 조정을 얻고 구매를 요청할 수 있습니다. 또한 자동화를 식별하여 연기하거나 피할 수 있습니다. 자동화는 효과적인 작업 식별에 대한 자세한 내용은 [프로세스 설계](/docs/architect/ko-kr/well-architected/guide/automated#프로세스-설계)을 참조하십시오. 또한 배달에 대한 우선 순위 지정 프레임워크를 설정하면 사용자 및 서비스 점검 팀이 사용자 기대치를 관리하고 로드맵을 유지하는 데 도움이 됩니다. 우선 순위 지정에 사용할 수 있는 몇 가지 고려 사항은 다음과 같습니다. - 배달의 비즈니스 영향(비용/익률) - 배달에 필요한 새 작업의 양 - 배달 서비스 점검에 필요한 작업량 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/intentional#전략-패턴-및-안티-패턴) 목록은 Salesforce 작업에 대한 올바른(그리고 부적절한) 우선 순위 지정을 보여줍니다. 이를 사용하여 구현 계획을 확인하거나 구축하기 전에 우선 순위를 더 잘 식별해야 하는 위치를 식별할 수 있습니다. Salesforce에서 사용할 수 있는 도구에 대해 자세히 알아보려면 우선 순위 지정에 대한 도움말을 받으려면 [도구의 의도적 관련](/docs/architect/ko-kr/well-architected/guide/intentional#의도와-관련된-도구)을 참조하십시오. ### 로드맵 로드맵은 수행할 작업에 대한 우선 순위가 지정되고 확인되었으며 명확하게 정의된 보기입니다. 효과적인 로드맵은 향후 작업의 비즈니스 영향 및 기술 영향을 명확하게 파악합니다. 로드맵의 핵심 부분은 비즈니스 및 기술 이해당사자를 참여시키는 것입니다. 로드맵을 사용하면 작업을 시작하기 전에 접근 방식 및 결과에 대한 사용자 의견을 얻고 구매할 수 있습니다. 최종적으로 로드맵은 모든 이해당사자에게 앞으로 수행할 작업의 " 이유"에 대한 조율을 제공합니다. 팀에서 백로그를 사용하는 경우 로드맵이 백로그의 요약 또는 항목 목록이 아닌지 이해해야 합니다. 관계는 반대입니다. 항목은 로드맵의 배달에 명확하고 신뢰할 수 있는 방식으로 연결할 수 있는 경우에만 백로그에 입력할 수 있습니다. 이해당사자의 참여로 생성된 고품질 로드맵은 배달 및 서비스 점검 팀이 집중해야 하는 사항 및 요청 우선 순위를 지정해야 하는 방법을 명확하게 파악하여 충돌하는 요청을 쉽게 정렬하고 이해당사자 기대치를 관리할 수 있도록 합니다. 로드맵이 없거나 없으면 다음이 발생합니다. - 새 기능 및 기능을 사용할 수 있는 시점에 대한 명확성 부족 - 이해당사자 간 우선 순위 충돌 - 제공되는 솔루션과 전체 조직 비전 간의 연결 끊김 - 진행 중인 작업을 이해하기 어려움 - 팀 간의 불규칙한 작업 부하 - 작업 항목 간 관계 및 종속성에 대한 가시성 부족 - 잘못 관리되는 종속성으로 인해 구현이 중단됨 이해당사자는 결정하기 위해 역할에 부합하는 정보를 필요로 하는 경우가 많습니다. 효과적인 로드맵을 만들려면 대상 그룹 및 대상 그룹이 필요한 정보 유형을 명확하게 이해해야 합니다. 로드맵은 비즈니스 및 기술 대상 그룹을 지원하기 위해 두 가지 스타일로 분류됩니다. 각 스타일에는 서로 다른 유형의 정보를 지원하는 두 가지 세분화 수준이 포함되어 있습니다. 비즈니스 로드맵은 이해당사자가 조직 변경을 계획하고, 성장 기회를 활용하고, 기업 목표를 유지하는 데 도움이 됩니다. 비즈니스 로드맵은 전체 비즈니스 비전에 맞춰 IT 지출을 보장하는 방법도 제공합니다. - 비즈니스 성능 로드맵을 만들어 경영진 이해당사자에게 활성화할 성능을 표시합니다. 이 유형의 로드맵에는 기능 자체와 운영 효율성 향상 또는 새 제품 라인 출시와 같은 비즈니스 목표에 부합하는 방법에 대한 상위 수준의 세부 사항이 포함되어 있습니다. - 비즈니스 기능 로드맵을 만들어 특정 기능을 자세히 살펴보고 비즈니스 이해당사자에게 자원 계획, 예산, 변경 관리에 도움이 필요한 경우 지원 기능 및 기능을 표시합니다. 기술 로드맵은 기술 이해당사자가 예산 및 자원 할당 계획에 도움이 됩니다. 또한 구현 팀이 더 큰 전체적인 이미지의 일부로 프로젝트가 부합하는 지점을 이해하고 팀 간 종속성을 식별할 수 있습니다. - 기술 시스템 로드맵을 만들어 구현할 특정 시스템과 시스템 수준 종속성을 표시합니다. 이 유형의 로드맵은 상위 수준 시스템 정보와 시스템과 비즈니스 기능 간의 정렬을 보여줍니다. - 기술 구성 요소 로드맵을 만들어 리소스 계획 및 활성화 요구 사항에 도움이 되도록 배포할 시스템의 특정 구성 요소를 자세히 살펴봅니다. 이 유형의 로드맵에는 구성 요소 수준 정보 및 구현 요구 사항(예: 선언적 개발, 프로 코드 등)이 표시됩니다. 로드맵에 실질적인 타임라인이 포함되어 있는지 확인합니다. 일반적인 실수는 관련 활동을 완료하는 데 걸리는 시간도 고려하지 않고 시스템 구현에 소요되는 시간만 포함하는 것입니다. 이를 통해 구현 팀 구성원이 과도하게 할당되고 예상보다 더 오래 지연될 수 있습니다. 로드맵을 만들 때 다음을 완료하는 데 걸리는 시간을 고려하십시오. - 모든 신규 및 업데이트된 기능 문서 - 새 기능을 지원하는 데 필요한 기존 기능의 서비스 점검 - 통합을 지원하기 위해 필요한 관련 시스템 업데이트 - 적용 직후 프로젝트 팀의 지원 강화 - 테스트, 교육, 변경 관리 올바르게 조율된 비즈니스 및 기술 로드맵은 기능이 적용되는 시기 및 이후의 기술에 대한 전체적인 관점을 전달합니다. 아래의 [패턴 및 반패턴](/docs/architect/ko-kr/well-architected/guide/intentional#전략-패턴-및-안티-패턴) 목록은 Salesforce 조직의 올바른(또는 나쁜) 로드맵을 보여줍니다. 이를 사용하여 로드맵 전략을 확인하거나 개선할 수 있습니다. 로드맵을 작성하는 데 도움이 되는 Salesforce 도구에 대해 자세히 알아보려면 [도구와 관련된 의도](/docs/architect/ko-kr/well-architected/guide/intentional#의도와-관련된-도구)을 참조하십시오. ### 거버넌스 거버넌스는 이해당사자와 우선 순위 지정, 의사 결정, 변경 관리를 처리하는 데 사용하는 구조입니다. 거버넌스는 결정을 내리고 커뮤니케이션하는 방식을 명확하게 보여줍니다. 이는 의사 결정 프로세스에 참여할 사용자 의견과 요청을 일관되게 제공하고 모든 이해당사자가 서비스 점검 및 개발 작업 상태를 이해할 수 있는 방법을 제공합니다. 거버넌스는 릴리스 관리 프로세스를 명확하고 일관되게 만들고 모든 팀 구성원이 역할 및 책임을 이해하는 데 도움이 됩니다. 적절한 거버넌스가 없으면 팀은 다음을 포함하여 다양한 문제를 겪게 됩니다. - 겹치는 기능 및 기능에 대한 요청이 임시로 도착합니다. - 구현 팀은 비즈니스 가치, 혜택 또는 전체 조직 목표를 적절하게 고려하지 않고 더 영향력 있는 이해당사자의 "쉬운" 노력 또는 요청에 우선 순위를 지정합니다. - 일관적인 승인 및 검토 프로세스가 없음 - 불일치하는 릴리스 케이던스 및 품질 - 개발 노력에서 고유율, 덮어쓰기, 충돌, 중복 작업 시스템에 효과적인 거버넌스가 없다는 가장 명확한 증거는 느리고 번거로운 릴리스일 수 있습니다. 거버넌스 시스템의 크기가 효율성을 측정하는 것은 아닙니다. 실제로, 많은 대기업에서 발견되는 것과 같은 정교한 거버넌스 시스템은 릴리스 속도와 빈도를 줄일 수 있습니다. 올바른 관리는 나쁜 사용자 정의가 개발 초기 단계를 지나가기 어렵게 만들고 좋은 사용자 정의를 예측 가능하고 일관적으로 프로덕션으로 가져오는 것입니다. 너무 자주, 거버넌스 노력이 반응적입니다. 과도한 기술 부채와 같은 문제가 비즈니스 문제가 되기 시작하거나 중복됩니다. 많은 경우 불행하게도 비즈니스는 효과적인 [설계 표준](/docs/architect/ko-kr/resources/guide/design-standards-template)과 빌딩 자동화를 만들어 개발자 도구 체인 및 소스 제어 시스템 내에서 해당 표준을 적용하는 대신 개발 노력과 릴리즈를 "차단"하는 것입니다. Salesforce 거버넌스 시스템에 대한 프레임워크를 구축할 때 다음 요소를 포함하고 다음의 주요 질문에 대한 답변을 고려하십시오. - **작업 요청.** 사용자가 기능 또는 기능을 어떻게 요청할 수 있습니까? 버그를 어떻게 보고합니까? - **우선 순위 지정 및 작업 계획.** 어떤 작업 요청이 중요한지 누가 결정합니까? 작업 범위 지정, 우선 순위 지정, 수락 또는 사인오프 - **환경 및 출시 계획.** 개발, 테스트, 릴리스를 위한 환경 파이프라인은 무엇입니까? 누가 프로비저닝, 새로 고침, 액세스 권한을 제공해야 합니까? 배포 및 유효성 검사를 처리하는 사람은 누구입니까? 변경 사항이 릴리스되는 방법 및 시기 Salesforce 릴리스 주기 동안 배포 또는 환경을 처리하는 방법은 무엇입니까? (자세한 내용은 [응용 프로그램 수명 주기 관리를 참조하십시오](/docs/architect/ko-kr/well-architected/guide/resilient#응용-프로그램-수명-주기-관리).) - **서비스 소유권 및 생산 지원.** 누가 무엇을 지원합니까? "핫픽스" 프로덕션 문제를 처리하는 사람은 누구입니까? 이러한 항목이 테스트 및 해제되는 방법은 무엇입니까? 조직의 전체 보안 표준을 담당하는 사람은 누구입니까? 아래의 [패턴 및 반패턴](/docs/architect/ko-kr/well-architected/guide/intentional#전략-패턴-및-안티-패턴) 목록은 Salesforce 조직의 올바른(그리고 나쁜) 거버넌스를 보여줍니다. 이를 사용하여 거버넌스 전략을 확인하거나 개선할 수 있습니다. 거버넌스에 사용할 수 있는 Salesforce 도구에 대해 자세히 알아보려면 [도구의 의도적 관련](/docs/architect/ko-kr/well-architected/guide/intentional#의도와-관련된-도구)을 참조하십시오. ### 전략 패턴 및 안티 패턴 다음 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/easy-strategy)에서 전략에 대한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
우선 순위 지정 문서 내에서:
- 모든 새 작업 항목에 명확한 비즈니스 가치 메트릭이 있습니다(예: 매출 증가, 프로세스 최적화로 인한 비용 절감 등).
- 로드맵에 비즈니스 가치를 기반으로 우선 순위가 지정된 작업이 표시됩니다.
문서 내에서:
- 작업과 관련된 비즈니스 가치가 명확하지 않거나 없음
- 로드맵이 없음
회사 내에서:
- 모든 작업 항목에 대한 구현 및 서비스 점검 비용이 식별되었습니다.
- 기능 요청은 비즈니스 영향, 배달에 필요한 새 작업의 양, 서비스 점검에 필요한 작업량에 따라 우선 순위가 지정됩니다.
회사 내에서:
- 기능 구현 및 유지 관리와 관련된 비용이 명확하지 않음
- 요청이 임시 또는 일차 인원/우선 인원 기반으로 전달됩니다.
도로 매핑 로드맵:
- 대상에 맞게 조정된 정보를 전달합니다(비즈니스 또는 기술).
- 정확한 세부 사항 수준으로 정보 전달
- 시작 및 종료 일자 표시
- 전제 조건 및 종속성 표시
로맵(있는 경우):
- 배달을 위한 아티팩트가 아닌 프로젝트 시작 자료로 사용됩니다.
- 이해당사자와 배달 팀의 조율에 도움이 되지 않음
- 세부 사항 수준 혼합(예: 같은 로드맵 내에 시스템 및 구성 요소 포함)
- 대상 그룹에 적합하지 않은 정보가 포함됩니다(예: 동일한 로드맵 내의 비즈니스 기능 및 시스템).
기업 내에서:
- 이해당사자가 작업 항목의 " 이유"를 이해합니다.
- 배달 팀은 장기 우선 순위에 대한 백로그 항목을 평가하는 방법을 알고 있습니다.
- 팀은 어떤 작업을 수행하고 종속성을 관리하는 방법을 알고 있습니다.
- 우선 순위가 빠르게 변경되어야 하는 경우에도 의도적인 작업 수행
기업 내에서:
- 백로그에 있는 내용에서 작업을 가져오고 명확한 "왜"가 없습니다.
- 팀이 상호 의존적인 작업을 조정하는 데 어려움을 겪고 있으며, 실현하지 않고 작업을 복제하는 경우가 많습니다.
- 작업이 반응형인 경우가 많습니다.
- 이해당사자는 수행 중인 작업에 대해 불만과 혼란을 느끼고 새 기능을 배포할 때 사용량이 떨어지는 경우가 많습니다.
거버넌스 기업 내에서:
- 사용자가 쉽게 버그 및 요청 기능을 보고할 수 있습니다.
- 작업 항목의 우선 순위 지정 프로세스가 문서화되고 모든 이해당사자에게 투명합니다.
- 환경 전략이 명확하게 문서화되고 개발 환경이 문서와 일치합니다.
- 릴리스 계획이 예측 가능하고 모든 배달 팀 구성원에게 투명합니다.
- 팀 구성원이 앱 수명 주기 전반에 걸쳐 책임이 있는 사람을 파악합니다.
- 사용자 및 배달/서비스 점검 팀에 릴리스가 명확합니다.
- 프로덕션 지원 프로세스가 명확하고 핫픽스에 프로덕션 경로가 명확합니다.
- 팀 및 프로젝트는 비즈니스용으로 승인된 AI 모델만 사용합니다.
기업 내에서:
- 버그 보고서 및 기능 요청은 임시입니다.
- 작업 항목에 명확한 우선 순위가 지정되지 않습니다.
- 환경은 임시로 프로비저닝되며 예측 가능한 방식으로 새로 고쳐지지 않을 수 있습니다. 개발자에게 필요한 환경 및 액세스 권한이 부족한 경우가 많습니다.
- 배달 팀 및 사용자가 릴리스를 예측할 수 없음
- 팀에서 책임이 있는 사람을 알지 못합니다.
- 핫픽스는 임시로 처리됩니다.
- 백로그가 오래되고 고정된 "아이디어 은행"이 되었습니다.
- 거버넌스 조직은 지원 요청 문제를 해결하는 도움말 센터 역할을 합니다.
- 문서에 쉽게 액세스할 수 없음
- 팀에서 임시로 AI 모델 선택
## 유지 보수 유지 보수성은 새로운 기능이 적용되고 기술 부채가 예측 가능한 기준으로 시스템에서 정기적으로 이동하는 상태로 시스템을 유지할 수 있음을 의미합니다. 서비스 점검 가능한 시스템을 사용하면 팀이 예측 가능한 속도와 품질으로 비즈니스에 가치를 전달할 수 있습니다. 시스템의 서비스 점검 가능성은 얼마나 가독성이 뛰어난지, 얼마나 느슨하게 연결되어 있는지, 테스트 전략의 철저성 등 여러 요소에 따라 다릅니다. 무엇보다 시스템의 서비스 점검 가능성은 설계의 간단성에 따라 다릅니다. 이 섹션에서는 보다 간단한 솔루션 설계를 만들고 유지 관리 기능을 향상하는 방법을 설명합니다. 사용자 정의 기능을 기준으로 표준을 사용하고 기술 부채를 처리하는 두 가지 키에 집중하여 유지 관리하기 쉬운 솔루션을 구축할 수 있습니다. ### 표준 기능과 사용자 정의 기능 비교 Salesforce는 Sales Cloud, Service Cloud 및 많은 Salesforce 산업 솔루션과 같은 사전 구축된 솔루션의 범위를 제공하며 자체 사용자 정의 솔루션을 만들 수 있는 유연성을 제공합니다. Salesforce의 자체 클라우드 솔루션을 구동하는 기본 서비스는 Salesforce Customer 360 플랫폼에 구축된 사용자 정의 솔루션에서도 사용할 수 있습니다. Salesforce의 사전 구축 서비스 및 솔루션을 최대한 많은 솔루션에 대한 신뢰할 수 있는 기반으로 사용합니다. 사전 구축 플랫폼 서비스를 사용하면 두 가지 고유한 이점이 있습니다. 먼저, 앱은 릴리스마다 최신 Salesforce 혁신을 자연스럽게 활용할 수 있습니다. 두 번째로, 개발 팀은 기본 아키텍처의 어려운 작업을 처리하는 대신 Salesforce 솔루션에서 제공하는 비즈니스 역량 확장 및 강화에 집중할 수 있습니다. 표준 기능을 사용할 시기와 사용자 정의 기능을 구축할 시기를 올바르게 선택하는 것은 아키텍처 측면에서 까다로운 것은 아닙니다. 키: - **플랫폼을 사용자 지정하는 것은 복제가 아니라 수정 및 확장을 의미합니다**. 아키텍처를 설계하거나 평가할 때 다음을 물어야 합니다. Salesforce Platform에 이미 이러한 항목이 있습니까? 답변이 “*예, 하지만...\[비즈니스 이해당사자가 여기에서 변경 사항을 삽입하려면...]”*인 경우 플랫폼에서 미리 작성된 기능을 사용합니다. 수행할 아키텍처 작업은 비즈니스 기대치를 충족하도록 사전 구축된 Salesforce 기능을 구성하는 가장 유용한 방법을 식별하는 것입니다. - **사용자 정의는 소소하지 않습니다**. 시간이 지남에 따라 모든 변경에 결과가 있습니다. 사용자 지정 솔루션을 구축해야 하는 경우 시스템이 발생하는 불가피한 [기술적 부채를](/docs/architect/ko-kr/well-architected/guide/intentional#기술-부채) 완화할 수 있습니다. 가능한 경우 낮은 코드 기술을 사용하고 구축에 [합성 유닛](/docs/architect/ko-kr/well-architected/guide/composable)을 생성합니다. - **구축-구매 스펙트럼을 고려하십시오**. [Salesforce AppExchange](https://appexchange.salesforce.com/)는 Salesforce를 확장할 수 있는 앱과 솔루션의 마켓플레이스입니다. AppExchange 앱은 맞춤형 솔루션 구축 및 유지 관리와 관련된 오버헤드 없이 기능을 제공할 수 있습니다. AppExchange 솔루션을 평가할 때 다음 사항을 고려하십시오. - 솔루션 기능 및 공백을 식별합니다. 모든 비즈니스 요구 사항을 충족하는 앱을 찾을 수 있습니다. 실제로는 완벽한 맞춤을 찾을 수 없습니다. 솔루션을 평가할 때 잠재적인 솔루션의 기능을 우선 순위가 지정된 비즈니스 요구 사항 목록에 매핑합니다. 이렇게 하면 가장 중요한 요구 사항을 가장 잘 충족하는 솔루션을 찾을 수 있습니다. - Sandbox 및 무료 평가판을 사용합니다. 무료 평가판을 사용하여 Sandbox 환경에서 앱을 평가하고 가장 적합한 앱을 식별합니다. 앱에서 기존 구성과 충돌하는 구성을 변경해야 하는지 확인합니다. - 단기 및 장기 비용을 고려합니다. 구독 기반 앱의 반복 비용과 비교하여 장기 앱 서비스 점검 할인을 평가합니다. 비즈니스 이해당사자가 사용하지 못하는 많은 기능에 대해 반복 비용을 지불해야 하는 시나리오를 피하십시오. - **Salesforce에서 미리 작성된 데이터 모델을 사용합니다.** Salesforce는 세일즈, 서비스, 다양한 산업 분야에 사전 구축된 데이터 모델을 제공합니다. Salesforce에서 제공하는 데이터 모델을 사용하면 시스템의 기능이 한 번만 정의되도록 합니다(중복 및 사일로 제거), 전체 시스템에 대한 신뢰할 수 있는 단일 소스를 설정하고, 분석을 통해 애플리케이션 데이터를 더 쉽게 이해하고, Salesforce의 사전 구축된 인공 지능 서비스를 더 쉽게 사용할 수 있도록 하고, 지원해야 하는 사용자 정의를 줄여 유지 관리 비용을 절감하며, 기술 부채를 줄일 수 있습니다. 매우 간단합니다. 아래의 [모형 및 안티모형](/docs/architect/ko-kr/well-architected/guide/intentional#서비스-점검-패턴-및-안티-패턴)에서 볼 수 있듯이, 안티모형은 사용자 정의 솔루션에서 표준 기능을 복제하거나 더 복잡한 기술을 사용하여 사용자 정의 작업을 수행합니다. 실제로 비즈니스 이해당사자가 사용자 정의 기능 안티 패턴을 최선 또는 유일하게 실행 가능한 방법으로 보는 시나리오가 발생할 수 있습니다. 이러한 경우 이해당사자에게 이 경로를 선택하는 데 관련된 제약 사항을 설명한 다음, 결정, 그 근거, 구현을 철저하게 문서화해야 합니다. 이 영역은 조기에 핵심 가치를 제공하고 시간에 따라 적절하게 조정하면 이해당사자가 앞으로 나아갈 수 있는 최상의 방법을 더 잘 이해하는 데 도움이 됩니다. 서비스 점검 가능성을 높이는 데 도움이 되는 Salesforce 도구에 대해 자세히 알아보려면 [도구와 관련된 의도](/docs/architect/ko-kr/well-architected/guide/intentional#의도와-관련된-도구)을 참조하십시오. ### 기술 부채 기술 부채는 모든 시스템의 자연적 부분입니다. 기술 또는 비즈니스 요구가 변경되면 어제의 사운드 디자인이 안티 패턴이 될 수 있습니다. 새로운 Salesforce 릴리스 또는 제품 출시로 Salesforce Platform 기능의 격차를 채우기 위해 구축된 기능이 갑자기 중복되었을 수 있습니다. 보다 성능이 뛰어난 또는 유연한 기술이 이미 구현한 기술을 대체할 수 있습니다. 기술 부채는 여러 가지 방법으로 생성할 수 있습니다. Salesforce Customer 360 플랫폼을 사용하여 애플리케이션을 구축하는 주요 장점은 플랫폼에 내장된 [뒤로 호환성](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#플랫폼-api)입니다. 다시 말해 새로운 플랫폼 혁신을 통해 솔루션이 진행되기 위해 사용해야 하는 패턴을 변경할 수 있지만 이전 Salesforce 기술을 기반으로 구축한 솔루션의 일상적인 기능은 계속 작동합니다. 시간이 지남에 따라 오래된 기술을 기반으로 하는 솔루션은 앱에 새로운 기능을 추가할 때 위험 또는 지체 지점을 야기하고 전반적인 솔루션 상태가 저하됩니다. 기술 부채를 해결하기 위해 정기적인 작업을 계획하고 수행하는 것은 Salesforce 솔루션에서 원활하고 간단한 디자인을 유지하기 위해 필요합니다. 기술 부채를 계획, 감사 및 조정하지 못하면 잘못된 구조의 시스템을 만들 수 있습니다. 기술 부채를 최소화하는 방법 중 하나는 바로 가기를 피하고 사용자 지정 기능보다 [표준 기능](/docs/architect/ko-kr/well-architected/guide/intentional#표준-기능과-사용자-정의-기능-비교)을 선호하는 방식으로 기술 부채를 가능한 한 많이 도입하지 않는 것입니다. 하드 코딩 값과 같은 바로 가기는 시간을 절약하는 유혹이 될 수 있지만 장기적으로는 환불해야 하는 부채를 야기합니다. 아키텍처 관점에서 기술 부채를 해결하기 위한 핵심은 다음과 같습니다. - 행동과 비행의 실제 [비용 또는 이점을](/docs/architect/ko-kr/resources/guide/kpi-spreadsheet-template) 파악 - 적절한 [로드맵](/docs/architect/ko-kr/well-architected/guide/intentional#로드맵) - 구축 가능한 [솔루션](/docs/architect/ko-kr/well-architected/guide/composable) 이해당사자를 조치에 부합시키는 것은 어려울 수 있습니다. 일부 이해당사자는 진행 중인 서비스 점검을 "내일의 실수"를 해결하거나 예산에서 지원하려는 기능을 제거하는 것으로 간주할 수 있습니다. 작업과 비작업이 미치는 실제 비즈니스 영향을 명확하게 정의된 납품 및 타임라인과 함께 표시하면 이해당사자가 기술 부채 해결의 가치와 상대적 우선 순위를 이해하는 데 도움이 됩니다. 기술 부채를 비즈니스 영향에 연결하는 작업을 일관되게 수행하면 이해당사자가 수행할 작업을 더 잘 이해하는 데 도움이 됩니다. 또한 기술 부채를 식별하고 사용자에게 도움이 되는 방식으로 해결할 수 있습니다. 아래의 [모형 및 비모형](/docs/architect/ko-kr/well-architected/guide/intentional#서비스-점검-패턴-및-안티-패턴) 목록은 Salesforce 조직의 적절한(그리고 부족한) 기술 부채 관리를 보여줍니다. 기술적 부채를 해결하는 데 도움이 되는 Salesforce 도구에 대해 자세히 알아보려면 [의도적 관련 도구](/docs/architect/ko-kr/well-architected/guide/intentional#의도와-관련된-도구)를 참조하십시오. ### 서비스 점검 패턴 및 안티 패턴 다음 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/easy-maintainability)에서 유지 관리 기능을 위한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
표준 vs. 사용자 정의 설계 기준:
- 불필요한 사용자 정의를 방지하기 위한 명확한 지침이 있습니다.
- 솔루션 지침 원칙은 다음 우선 순위를 사용합니다. 1. 내장형 플랫폼 서비스 사용, 2. 맞춤형 솔루션을 구축하기 전에 AppExchange 앱을 고려하십시오. 3. 코드를 작성하기 전에 하위 코드 사용자 정의 사용
설계 기준:
- 설계 표준이 없거나 불필요한 사용자 정의 및 코드를 피하기 위한 명확한 이유가 없습니다.
문서:
- 솔루션 구축 또는 구매를 선택할 때 결정 레코드에 단기 및 장기 비용 계산이 표시됩니다.
문서:
- 솔루션 구축 또는 구매를 선택할 때 결정 레코드는 단기 비용과 장기 비용을 모두 고려하지 않습니다.
데이터 모델:
- 표준 개체를 복제하는 이름 또는 기능이 있는 개체가 없습니다.
- 표준 개체는 의도한 범위를 벗어난 목적으로 사용되지 않습니다.
데이터 모델:
- 개체가 표준 개체의 이름 및/또는 기능을 복제합니다.
- 표준 개체는 의도한 범위를 벗어난 목적으로 사용됩니다.
LWC, Aura 또는 Visualforce에서:
- 표준 페이지 보기 메커니즘을 재정의하는 코드가 없습니다.
LWC, Aura 또는 Visualforce에서:
- 일반적으로 단일 페이지 앱 형태로 표준 페이지 보기 메커니즘을 재정의하기 위한 코드가 존재합니다.
LWC, Aura 또는 Apex에서:
- 코드에서 플랫폼 실행 순서를 무시하거나 무시하려고 시도하지 않습니다.
LWC, Aura 또는 Apex에서:
- 코드에서 플랫폼 실행 순서를 재정의하거나 우회하려고 시도합니다.
기술 부채 로드맵에서:
- 기술 부채 해결 작업이 계획되어 있습니다.
- 배달 및 시작/종료 일자가 명확합니다.
로드맵에서:
- 기술 부채 해결 작업이 계획되지 않음
- 배달이 모호하며 시작/종료 날짜가 명확하지 않음
결정 기록:
- 기술 전/후 부채 해결을 위한 KPI가 명확하게 문서화되어 있습니다.
- 비즈니스 비용 또는 이점에 중점을 둔 작업 및 비작업에 대한 제약 토론
결정 기록:
- 기술 부채 해결에는 측정 가능한 KPI가 없습니다.
- 기술 부채는 기술 또는 IT 중심의 측면에서 고려되며 비즈니스와 관련이 없습니다.
조직에서:
- 다음을 포함하여 지원되지 않거나 레거시 기술이 활성화되어 있지 않습니다.
-- 모든 사용자가 Lightning Experience 작업합니다.
-- Apex에서 @future의 사용이 없거나 거의 없습니다(대기 가능 사용)
-- 모든 타사 Apex AppExchange 패키지에 속함
-- 활성 워크플로 규칙 없음(플로가 사용됨)
-- 활성 프로세스 빌더 프로세스 없음(플로 사용)
-- PushTopic 이벤트(변경 데이터 수집 사용)
-- 일반 이벤트(플랫폼 이벤트 사용)
-- 30.0 이전의 API 버전
-- Salesforce 조직 연결에서 Salesforce Connect용 Cross-Org 어댑터를 사용합니다.
조직에서:
- 지원되지 않거나 레거시 기술이 활성 상태인 경우:
-- Salesforce Classic 작업하는 사용자
-- Apex의 @future 사용
-- AppExchange 아닌 소스의 타사 Apex
-- 워크플로 규칙
-- 프로세스 빌더 프로세스
-- PushTopic 이벤트
-- 일반 이벤트
-- 30.0 이전의 API 버전
-- Salesforce에서 Salesforce에 연결
## 가독성 *읽기*의 핵심은 일관성을 창출하는 것입니다. 이를 통해 사람들이 어떻게 작동하는지 쉽게 이해할 수 있습니다. 읽을 수 있는 시스템을 구축하면 배달 및 서비스 점검 팀이 조율되며 시스템에 익숙하지 않은 사람들은 부품이 함께 어울리는 방식을 빠르게 이해할 수 있습니다. 즉, 팀은 기관 또는 과거 Knowledge 있는 개인에 의존하지 않아 공급업체 또는 새 팀 구성원을 효율적으로 온보딩할 수 있습니다. 이는 시스템의 구성과 코드를 쉽게 읽고 이해할 수 있으므로 팀의 숙련된 개인이 선택한 품질 및 제약에 집중할 수 있음을 의미합니다. 가독성을 통해 거버넌스 및 품질 보증 프로세스의 속도를 높이고 팀이 중복 사용자 정의를 만들 때를 더 잘 식별할 수 있습니다. 또한 재사용 가능하고 테스트 가능한 방식으로 동작하는 시스템의 가능성을 높일 수 있습니다. 효과적인 설계 표준 및 문서를 통해 가독성을 향상할 수 있습니다. ### 설계 표준 [설계 표준](/docs/architect/ko-kr/resources/guide/design-standards-template)은 개발 초기 단계에서도 모든 맞춤 설정을 일관되게 유지하기 위한 지침을 제공합니다. 설계 표준은 가드 레일처럼 작동하므로 시스템에서 작업하는 모든 배달 팀 및 서비스 점검 팀이 사용자 정의 접근 및 구현 방법에 부합합니다. 설계 표준을 정의하면 배달 및 유지 보수 팀의 생산성을 높이고, 코드 및 아키텍처 검토를 쉽게 수행하고, 더 나은 [문서 작성](/docs/architect/ko-kr/well-architected/guide/intentional#문서)을 위한 기반을 제공할 수 있습니다. 설계 표준이 없으면 팀이 사일로에서 작업할 가능성이 높습니다. 설계 표준이 제공하는 일관성이 없으면 기업은 다음과 같은 어려움을 겪게 됩니다. - 공급업체 및 개발 팀은 솔루션 간에 특정 패턴 및 접근 방식을 사용하여 잠재적으로 안티 패턴을 도입하고 재사용 가능성을 줄일 수 있습니다([관심 분리](/docs/architect/ko-kr/well-architected/guide/composable#우려-사항-분리) 참조). - 프로덕션 문제를 해결할 시간을 늘리고 지원 팀이 새 팀 구성원을 온보딩하고 서로 다른 패턴 및 접근 방식을 이해할 수 있도록 지원합니다. - 부적절한 팀 간 공동 작업, 팀 간의 작업 중복, 충돌 해결에 소요된 시간, 통합 테스트 중 발견된 버그 - 불만족도 증가하고 매출률이 증가했습니다. 설계 표준의 주요 혜택은 이해당사자가 표준을 만드는 데 필요한 대화 및 결정을 통해 얻을 수 있습니다. 특히 프로세스를 통해 비즈니스 및 기술 리드가 비즈니스에 최적의 디자인을 조율할 수 있습니다. [설계 기준](/docs/architect/ko-kr/resources/guide/design-standards-template)에 다음을 포함하십시오. - Salesforce 메타데이터의 **명명 규칙** 시스템의 모든 사용자 정의 이름을 지정하는 방법에 대한 일련의 규칙을 정의합니다. 우수한 명명 규칙은 개체, 필드, 코드, 플로 및 시스템의 기타 요소 이름에 일관성을 적용하는 것뿐만 아니라 또한 좋은 명명 규칙을 통해 개발 팀이 구축 중인 내용의 목적 및 기능에 대한 정보를 전달하는 이름을 사용할 수 있습니다. 따라서 다른 이해당사자는 이름을 보면 특정 사용자 정의를 더 잘 이해할 수 있습니다. - **승인된 디자인 패턴 및 사용 사례** [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/patterns) 라이브러리를 구축하고 각 패턴을 사용할 시기(및 사용하지 않을 시기)에 대한 주요 정보를 제공합니다. 라이브러리에 필요한 Apex 트리거 패턴 또는 시스템에서 원하는 [구성 가능성](/docs/architect/ko-kr/well-architected/guide/composable)을 기반으로 하는 플로 오케스트레이션 패턴이 포함될 수 있습니다. - **개발 환경 및 도구 지침** 개발 팀이 작업에 사용할 도구의 명확한 목록을 유지합니다. 여기에는 코드를 작성하는 모든 사람의 승인된 도구 체인 및 언어 또는 하위 코드 개발에 승인되었거나 승인되지 않은 선언적 기능이 포함될 수 있습니다. 표준에는 사용자 정의 및 문서화용 소스 제어 시스템 목록, 필수 체크인/체크아웃 단계가 포함될 수 있습니다. 다양한 유형의 개발 작업에 사용할 환경 목록도 포함할 수 있습니다. 해당 표준을 정의하는 것과 함께 해당 표준을 유지 관리하고 저장할 방법과 위치를 결정해야 합니다. 회사 전체의 팀이 설계 표준을 찾을 수 없거나 존재를 인식하지 못할 경우에는 효과가 없습니다. 이상적으로 설계 표준은 문서와 동일한 시스템 내에 적용됩니다(자세한 내용은 다음 섹션을 참조하십시오). 아래의 [모형 및 비모형](/docs/architect/ko-kr/well-architected/guide/intentional#가독성-패턴-및-안티-패턴) 목록은 Salesforce 조직의 올바르고 나쁜 디자인 표준을 보여줍니다. 이를 사용하여 설계 표준을 확인하거나 개선할 수 있습니다. 설계 표준을 정의하는 데 도움이 되는 Salesforce 도구에 대해 자세히 알아보려면 [도구의 의도적 관련](/docs/architect/ko-kr/well-architected/guide/intentional#의도와-관련된-도구)을 참조하십시오. ### 문서 문서에서 시스템의 내용, 방법 및 이유를 설명합니다. 의미 있고 일관된 문서가 없으면 팀이 시스템을 그대로 이해하고 잠재적으로 기능 및 사용자 정의를 잘못 이해하는 데 많은 시간을 낭비합니다. 적절한 문서를 작성하는 데 시간이 걸립니다. 대부분의 팀은 문서가 대규모 프로젝트에 중요하다는 점에 동의하지만 구성 업데이트 또는 자동화에 대한 사소한 조정과 같은 빠른 변경 사항을 수행할 때 건너뛰기 어려운 단계일 수 있습니다. 시스템에 대한 변경 사항을 문서화하지 않는 것은 항상 반 패턴입니다. 문서를 건너뛰면 미리 약간의 시간을 절약할 수 있지만, 문서화되지 않은 조직의 문제를 해결하는 데 필요한 시간은 이러한 시간 절약을 취소하는 것 이상입니다. 항상 계획하는 업데이트에 필요한 노력 수준에 관계없이 모든 예상에 문서를 작성할 충분한 시간을 포함하십시오. 명확한 문서가 없으면 다음을 포함하여 다양한 문제를 야기할 수 있습니다. - 기존 구현 재작업에 사용된 개발 주기 - 이전 결정에 대해 재개하거나 혼동하는 반복 토론 - 신규 팀 구성원 또는 공급업체에 대한 긴 온보딩 - 조직 또는 과거 Knowledge 있는 개인에 대한 과도한 의존성 - 중복 아키텍처 - 비즈니스 전반에서 동일하거나 유사한 성능을 지원합니다. - 주요 이해당사자에게 솔루션의 목적 및 가치를 전달하는 어려움 Salesforce 솔루션의 경우 다음에 대한 문서를 유지합니다. - **솔루션 개요**. [다이어그램](/docs/architect/ko-kr/reference-diagrams/guide/introduction)을 사용하면 귀하와 귀하의 이해당사자가 다양한 수준의 세부 사항으로 솔루션을 시각화할 수 있습니다. Salesforce 다이어그램 프레임워크를 사용하면 솔루션의 비즈니스 기능과 기술 구현 세부 사항을 보여주는 다이어그램을 만들 수 있습니다. - **결정 기록** 모든 팀 구성원이 향후 참조를 위해 액세스할 수 있는 중앙 위치에 고려된 옵션, 협상, 최종 결정, 추론 레코드를 유지합니다. - **코드** 코드 형식 자체는 문서의 핵심 요소이며, 이는 귀하의 [설계 기준](/docs/architect/ko-kr/well-architected/guide/intentional#설계-표준)에 부합할 수 있습니다. 또한 키 정보 로그를 가지고 코드 조각의 모든 수정 사항으로 업데이트할 수 있습니다. 모든 클래스, 트리거 및 구성 요소의 경우 다음을 문서화합니다. - 코드를 작성한 사람 - 코드가 작성된 시점 - 코드가 수행할 작업 - 주요 종속성 - 모든 변경 사항 - **선언적 사용자 정의**. 조직의 메타데이터에 대해 수행할 수 있는 모든 사용자 정의에 대해 Salesforce는 팀에 메타데이터의 목적과 의도에 대한 유용한 정보를 제공하는 [내장된 속성을 제공합니다](/docs/architect/ko-kr/fundamentals/guide/platform-multitenant-architecture#브라우저-기반-코드-없음-로우-코드-응용-프로그램-개발). 설계 표준의 일부로 팀이 이러한 내장형 기능을 사용하는 방법 및 선언적 사용자 정의의 이름을 지정하는 방법을 포함합니다. 또한 코드에 사용하는 정보와 동일한 키 정보 로그를 유지합니다. 현재 및 미래의 모든 팀원이 동일한 방식으로 문서를 해석할 수 있도록 문서화 표준을 개발합니다. ([설계 표준](/docs/architect/ko-kr/resources/guide/design-standards-template)이 도움이 될 수 있습니다.) 또한 사용자가 문서를 검색하여 관련 섹션 또는 용어를 찾을 수 있는 방법을 고려해야 합니다. 시스템이 구식화되고 복잡해질수록 문서도 성장합니다. 문서의 정보의 유용성은 사용자가 관련 항목을 검색하고 찾을 수 있는 빈도, 속도 및 용이성과 직접적으로 관련이 있습니다. 아래의 [모형 및 비모형](/docs/architect/ko-kr/well-architected/guide/intentional#가독성-패턴-및-안티-패턴) 목록은 Salesforce 조직에 적합한(또는 나쁜) 문서를 보여줍니다. 이를 사용하여 문서화 전략을 확인하거나 개선할 수 있습니다. 문서용 Salesforce 도구에 대한 자세한 내용은 의도에 대한 [도구](/docs/architect/ko-kr/well-architected/guide/intentional#의도와-관련된-도구)를 참조하십시오. ### 가독성 패턴 및 안티 패턴 다음 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/easy-readability)에서 더 많은 패턴을 검색하여 읽을 수 있습니다.
패턴 안티 패턴
설계 표준 조직에서:
- 코드 및 선언적 사용자 정의에는 사람에게 읽을 수 있는 일관된 이름이 있습니다.
- 데이터 모델의 개체 및 필드 이름이 일관되고 균일합니다.
- 감사 시 필드가 일관되게 작성되고 보고서에서 참조되는 등
조직에서:
- 코드 및 선언적 사용자 정의에 일관된 이름이 없습니다.
- 데이터 모델의 이름이 일관되지 않으며 많은 개체와 필드가 중복되는 것처럼 보입니다.
- 감사 시 사용되지 않는 필드 또는 다양한 사용 수준이 많이 표시되며, 보고에 일관된 링크가 없습니다.
기업 내에서:
- 팀은 작업을 완료하기 위해 어떤 도구를 사용할지(사용하지 않음) 알고 있습니다.
- 승인된 디자인 패턴은 사용 사례별로 쉽게 찾고 식별할 수 있습니다.
- 승인된 AI 모델이 명확하게 식별되고 의도한 목적을 포함합니다.
기업 내에서:
- 팀에서 다양한 도구를 사용하여 유사한 작업을 수행합니다.
- 승인된 디자인 패턴이 없습니다.
- 공급업체 또는 신입 직원이 온보딩하는 데 많은 시간이 소요됩니다.
- 승인된 AI 모델이 명확하게 식별되지 않으며 의도한 목적이 명확하지 않음
문서 조직에서:
- 코드 및 선언적 사용자 정의에 명확한 설명이 있습니다.
조직에서:
- 코드 및 선언적 사용자 정의에는 설명이 없거나 이해하기 어려운 설명이 있거나 사용자 정의가 실제로 수행하는 작업과 일치하지 않는 설명이 있습니다.
기업 내에서:
- 모든 솔루션에 대한 비즈니스 기능 및 기술 구현 세부 사항에 대한 다이어그램이 있습니다.
- 코드 및 선언적 사용자 정의에 대한 정보 로그가 있는 사람/시간/대상 키
- 관련 문서를 검색하고 찾을 수 있습니다.
기업 내에서:
- 솔루션을 찾기 어려우며 대부분의 팀에서 사용할 수 없는 이유
- 작업 중인 솔루션 및 시스템을 이해하기 어려운 경우
- 공급업체 또는 신입 직원이 온보딩하는 데 많은 시간이 소요됩니다.
## 의도와 관련된 도구
도구설명전략유지 보수가독성
ApexDoc정적 HTML 페이지가 있는 문서 ApexXX
비활성 선택 목록 값 대량 삭제선택 목록에서 비활성 미사용 값 삭제X
Lightning Design System Validator마크업을 확인하고 코드를 개선하는 방법 확인XX
플로로 마이그레이션워크플로 규칙 및 프로세스 빌더 프로세스를 플로로 변환X
Salesforce Labs의 프로젝트 관리 도구Salesforce 조직 내 프로젝트 관리XX
Visual Studio 코드용 Salesforce 확장 프로그램(확장)Visual Studio 코드 확장으로 효율적으로 Salesforce 코드 분석XX
조직 확인신속한 조직 및 기술 부채 분석X
Salesforce 코드 분석기IDE, CLI 또는 CI/CD를 통해 코드를 스캔하여 모범 사례를 준수하는지 확인합니다.XX
Salesforce 로드맵 탐색기Salesforce 제품 혁신 살펴보기X
설정 감사 내역설정 변경 사항 및 감사 내역 추적XX
## 의도와 관련된 자원
자원설명전략유지 보수가독성
Salesforce 조직을 개선하기 위한 5가지 문서화 전략Salesforce 구현 문서 개선X
명명 규칙 선택(Trailhead)명명 규칙 적용 방법 알아보기X
기술 부채 정의, 식별 및 측정기술 부채 정의, 식별 및 측정XX
설계 표준 템플릿조직에 대한 설계 표준 만들기XXX
Salesforce 다이어그램 시작하기사용 사례에 적합한 다이어그램을 만드는 방법 알아보기X
코딩 규칙 시작하기(Trailhead)코딩 규칙 정의 및 준수X
기술적 부채 처리 방법(Trailhead)Salesforce 조직의 기술 부채 관리XX
Apex 코드 개선(Trailhead)테스트 중심 개발의 기본 원칙 적용X
Organizational Alignment (Trailhead)정렬을 위한 V2MOM 프로세스 알아보기X
기술적 부채에서 벗어나기 위한 우선 순위 지정 및 계획기술 부채 감소 및 제거 계획 수립XX
Salesforce 명명 규칙 템플릿명명 규칙 시작하기XX
기술 부채: 그것은 무엇이며 왜 당신이 걱정해야 하는가? 조직의 기술 부채 영향 이해X
엔터프라이즈 아키텍처에서 비즈니스 모델 캔버스 사용비즈니스 모델에서 가치 만들기, 전달, 확인X
## 의견을 알려주십시오. Salesforce Well-Architected의 관련성을 유지할 수 있도록 도와주십시오. 이 콘텐츠에 대한 사용자 의견을 제공하려면 [ 설문 조사](https://sfdc.co/bxNtvh)을 작성하고 다음에 원하는 내용을 알려주십시오. > 업데이트 일정을 [여기](/docs/architect/ko-kr/well-architected/guide/contributors) 읽어보세요. ## 소개 시스템은 비즈니스가 주요 목표와 목표를 더 빠르고 대규모로 달성할 수 있도록 하여 자동화된 동작을 시연합니다. 정상적인 자동화를 사용하면 사용자가 중요한 작업에 집중하고 반복적인 수동 작업 또는 복잡한 데이터 입력에 소요되는 시간을 줄일 수 있습니다. 일반적으로 자동화는 서류 기반 양식에서 디지털 양식으로, 기존 시스템에서 새 시스템으로 비즈니스 프로세스를 다른 양식으로 번역함을 의미합니다. 모든 비즈니스 프로세스 번역은 변환의 기회를 제공합니다. 변환은 새로운 기술을 사용하여 사용자에게 중단적이고 혼란스러운 변경 사항을 도입하는 것이 아닙니다. 변환은 작업을 수행하는 간단한 방법을 만들고 비즈니스가 마찰 없이 성장할 수 있도록 하고 비즈니스 사용자가 이해당사자에게 중요한 사항에 집중할 수 있도록 합니다. 아키텍처 관점에서는 모두 제거하거나 자동으로 처리할 수 있는 과업을 식별해야 합니다. 기술이 사용되는 방식과 비즈니스에 미치는 측정 가능한 영향 간에 명확한 연결이 필요합니다. Salesforce의 자동화에 대해 참고해야 할 중요한 사항은 프로그래밍 방식 및 선언적 기술 집합을 사용하여 다양한 도구를 사용하여 수행할 수 있다는 것입니다. 잘 설계된 자동화를 설계하는 것은 단일 자동화 도구로 구축하도록 선택하는 것이 아닙니다. 일관되고 예측 가능한 접근 방식을 사용하고 팀이 설계한 자동화를 개발, 테스트, 배포, 유지 관리할 수 있도록 합니다. 자동화는 가능한 한 가장 [관리 가능하고 읽을 수 있는](/docs/architect/ko-kr/well-architected/guide/intentional) 형태를 취해야 합니다. 이 섹션에서는 비즈니스가 주요 목표를 더 빠르고 대규모로 충족할 수 있도록 자동화를 설계하고 리팩터링하는 방법을 설명합니다. 효율성 및 데이터 무결성에 집중하여 Salesforce에서 자동화 아키텍처를 개선할 수 있습니다. ## 효율성 자동화의 효율성을 창출하는 것은 Salesforce 기술을 사용하여 평소처럼 비즈니스를 재생성하는 것이 아닙니다. 이 작업은 팀이 회의 또는 추적을 담당하는 핵심 메트릭 및 비즈니스 결과를 깊이 이해하고 자동화하는 작업 내부와 전체의 [기능 단위](/docs/architect/ko-kr/well-architected/guide/composable#기능-단위)를 확인하는 데 필요한 것입니다. 자동화를 통해 비즈니스가 대규모로 더욱 효율적이고 빠르게 운영할 수 있는 패턴을 만들 수 있는 방법을 식별하는 작업입니다. 효율적인 자동화 논리를 통해 시스템이 다음을 수행할 수 있습니다. - 확장성 향상 및 비즈니스에 대한 가치 - 사용자에게 더 유용 - 더욱 [적절하고](/docs/architect/ko-kr/well-architected/guide/adaptable-overview) 변화하는 비즈니스 요구를 충족할 수 있음 프로세스 설계 및 운영 논리를 통해 자동화의 효율성을 향상할 수 있습니다. ### 프로세스 설계 프로세스 설계는 작업을 수행하는 방법을 정의하는 데 포함됩니다. 실제로 효율적이고 효과적인 프로세스를 구축하면 설계가 현재 작업 방식만 복제하는 것이 아닙니다. 효율적이지 않거나 명확하지 않은 단계를 식별하고 제거하는 것이 중요합니다. 최적화된 프로세스는 불필요한 단계 없이 측정 가능한 비즈니스 가치를 창출해야 합니다([KPI](/docs/architect/ko-kr/well-architected/guide/automated#kpi) 참조). 명확하지 않거나 불필요한 단계를 수행하면 기술 부채가 발생하고 유지할 수 없는 자동화가 발생할 수 있습니다. 비즈니스 프로세스 발견 및 문서화에 대한 책임은 비즈니스 분석가 또는 시스템 관리자에 속하는 경우가 많습니다. 설계자는 팀의 해당 구성원과 파트너 관계를 맺어 프로세스 설계가 기술적으로 올바르고 구조화된지 확인할 책임이 있습니다. Salesforce Platform에 대한 Knowledge 가능한 한 빨리 적용하면 팀이 자동화를 통해 간소화할 프로세스 또는 비용이 많이 드는 사용자 정의를 피하기 위해 변경해야 하는 프로세스를 식별하는 데 도움이 됩니다. Salesforce에 최적화된 프로세스를 구축하려면 다음을 고려하십시오. - **프로세스를 철저하게 정의하십시오**. 목적이 명확하지 않거나 정의가 모호한 프로세스는 설계 시점에 잘못 해석될 가능성이 높습니다. 따라서 가정을 기반으로 하는 디자인이 결함이 있으므로 자동화가 잘못되거나 비효율적일 수 있습니다. 자동화할 비즈니스 프로세스가 다음 표준을 충족하는지 확인합니다. - 단일 특정 기능으로 범위 지정([기능 단위](/docs/architect/ko-kr/well-architected/guide/composable#기능-단위) 참조) - 명확하게 정의된 측정 가능한 출력([비즈니스 가치](/docs/architect/ko-kr/well-architected/guide/automated#비즈니스-가치) 참조) - 입력 및 출력을 명확하게 정의함 - **프로세스 단계를 명확하게 지정하십시오**.\* 때로는 "나중에 도움이 될 수 있습니다" 추가 단계를 추가하는 것이 유혹 될 수 있지만, 이것은 결코 좋은 접근 방식이 아닙니다. 자동화의 모든 단계는 전체 프로세스의 결과와 관련이 있습니다. 각 프로세스 단계에 다음과 같은 특성이 있는지 확인합니다. - 특정한 세분화된 작업 수행([컴포지블](/docs/architect/ko-kr/well-architected/guide/composable) 참조) - 프로세스에서 정의된 출력을 생성하는 데 필요합니다(모든 비핵심 단계 제거) - 최소한의 자원을 사용하여 완료할 수 있음 - 가능한 경우 사용자 입력 요청 대신 기존 시스템 데이터를 사용합니다([참여](/docs/architect/ko-kr/well-architected/guide/engaging) 참조) - 사용자가 기본 시스템이 작동하는 방식을 알 필요 없이 이해할 수 있는 입력 옵션을 제공합니다([도움말](/docs/architect/ko-kr/well-architected/guide/engaging#유용) 참조) 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/automated#효율성-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 올바르고 나쁜 최적화를 보여줍니다. 이를 사용하여 구축하기 전에 자동화 설계를 확인하거나 추가로 최적화해야 하는 자동화를 식별할 수 있습니다. Salesforce에서 제공하는 프로세스 자동화 도구에 대한 자세한 내용은 자동화와 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/automated#자동화와-관련된-도구)를 참조하십시오. ### 운영 논리 운영 논리는 프로세스가 설계에서 실제 구현으로 얼마나 효과적으로 전환되는지를 다룹니다. 강력한 운영 논리를 사용하는 자동화는 트랜잭션 볼륨이 급증하거나 실행 중인 동시 인스턴스 수에 관계없이 계속해서 잘 수행됩니다. 논리적으로 정상적인 자동화를 사용하면 비즈니스가 더 쉽게 규모를 조정하여 높은 수요 수준에서 운영할 수 있습니다. 자동화에 강력한 운영 논리를 구축하는 것은 시스템의 전체적인 [신뢰성](/docs/architect/ko-kr/well-architected/guide/reliable)과 직접적으로 관련이 있습니다. 효율적으로 작동하지 않는 자동화는 사용자 및 고객 경험이 부족하여 잠재적인 매출 손실과 고객 Trust 손실을 야기합니다. 또한 서비스 점검 비용이 높아 관련 프로세스를 지연시키고 전체 시스템 성능 문제에 영향을 미칠 수 있습니다. 자동화에서 효과적인 운영 논리를 만들려면 다음을 고려하십시오. - **자동화를 만드는 모든 사람이 올바른 방법을 알고 있는지 확인하십시오.** 모든 종류의 자동화 도구로 부정적인 설계 선택을 할 수 있습니다. 코드는 클릭 기반 도구보다 오류 또는 구현 선택 항목이 적을 가능성이 높습니다. 예를 들어 하드 코딩된 참조 ID를 사용하는 것은 플로와 코드 모두에 표시되는 안티 패턴입니다. 클릭 기반 도구는 모든 사용자가 자동화를 프로덕션으로 릴리스할 수 있도록 허용하는 라이센스로 볼 수 없습니다. 자동화를 만드는 모든 팀 구성원은 올바른 방법으로 구축하는 방법을 알아야 합니다. 시스템 전체에서 효과적인 표준을 정의하고 적용하는 방법에 대한 자세한 내용은 [읽기](/docs/architect/ko-kr/well-architected/guide/intentional#가독성) 및 [설계 표준](/docs/architect/ko-kr/well-architected/guide/intentional#설계-표준)을 참조하십시오. - **모든 실행 경로를 명확하게 문서화**합니다. 자동화 사용이 증가하면 잠재적인 데이터 용량이 증가할 뿐만 아니라 계획되지 않은 호출 컨텍스트도 증가합니다. 다양한 자동화를 호출할 수 있는 방법을 이해하고 여러 항목이 있는 모든 자동화에 적절한 트랜잭션 제어(데이터 처리를 참조)가 표시되는지 확인해야 합니다. 예를 들어, 화면 플로는 대량 데이터 로드에서 실행되지 않지만 Apex 트리거와 트리거(및 자동 실행) 플로가 실행됩니다. 자동화에 대해 계획된 실행 경로와 잠재적인 실행 경로를 명확하게 문서화하는 것은 구현 동안 적용해야 하는 논리적 조건을 이해하는 핵심적인 측면입니다. - **"Bulkify"는 모든 데이터 작업(SOQL 포함)**입니다. 컬렉션에 대해 모든 데이터 작업(삽입, 업데이트 등)을 수행해야 합니다. 항상. 예외가 없습니다. 이는 "불량 처리" 작업을 의미합니다. 플랫폼에서 singleton 데이터 작업을 지원할 수 있지만, singleton 패턴을 구현하는 것을 허용해서는 안 됩니다. - **검색 작업에 SOSL을 사용하십시오**. SOSL을 통해 반환된 레코드에 대해 데이터 작업을 수행할 수 없다는 오해가 있습니다. DML은 SOSL 결과에 대해 직접 호출할 수 없지만 코드는 SOSL 결과를 구문 분석하고 DML 또는 데이터베이스 클래스 메서드에서 참조할 수 있는 컬렉션을 만들 수 있습니다. SOSL과 SOQL 간의 주요 차이점은 각 반환 유형과 일반화 또는 와일드카드 검색에 반응하는 방식입니다. SOSL은 여러 sObject 유형(반환 유형이 다르기 때문에)에 대해 작동하며 SOQL보다 성능이 뛰어난 와일드카드 및 일반화된 문자열 검색을 처리할 수 있습니다. - **SOQL을 데이터 작업**처럼 처리합니다. SOQL을 사용하여 레코드를 찾지 말고 이를 사용하여 데이터 작업을 구체화합니다. SOQL 및 데이터 작업은 [기본 관계형 데이터베이스](/docs/architect/ko-kr/fundamentals/guide/platform-multitenant-architecture#플랫폼-데이터-레이어)의 성능에 매우 유사한 영향을 미칠 수 있습니다. SOQL은 데이터 작업을 예상할 때 데이터베이스 행을 잠그는 [분명한 DML 지표](https://developer.salesforce.com/docs/atlas.en-us.238.0.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_for_update.htm?q=for%20update)도 전달할 수 있습니다. 확장 가능한 자동화를 만들려면 SOQL을 매우 구체적이고 잘 구성된 선택 기준 없이 사용하지 말고, 외부 필드 참조를 허용하지 말고, 필드 간 데이터 유형 일치 및 `WHERE` 문 논리의 필터 입력에 주의를 기울여야 합니다. 또한 코드에 쿼리가 대량 처리되지 않은 컨텍스트 또는 null 또는 공백 필터 기준에 대해 실행되지 않도록 적절한 제어 기능이 있어야 합니다. - **동기 작업을 실시간으로 사용자에게 도움이 되는 작업에 집중하십시오.** [프로세스 최적화](/docs/architect/ko-kr/well-architected/guide/automated#프로세스-설계) 과정에서 사용자가 실시간 또는 거의 실시간으로 수행해야 하는 작업과 관련된 논리를 파악하고 비동기(비동기) 트랜잭션으로 연기할 수 있는 작업을 파악합니다. 동기화/비동기화 작업 설계에 대한 자세한 내용은 [데이터 처리](/docs/architect/ko-kr/well-architected/guide/automated#데이터-처리)을 참조하십시오. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/automated#효율성-패턴-및-안티-패턴) 목록은 Salesforce 자동화에서 올바르고 나쁜 운영 논리를 보여줍니다. 이를 사용하여 구축하기 전에 자동화 설계를 확인하거나 추가로 최적화해야 하는 자동화를 식별할 수 있습니다. 확장 계획에 도움이 되는 Salesforce에서 사용할 수 있는 도구에 대해 자세히 알아보려면 자동화와 관련된 [도구를 참조하십시오](/docs/architect/ko-kr/well-architected/guide/automated#자동화와-관련된-도구). ### KPI 자동화 KPI는 시간에 따른 자동화의 영향을 측정합니다. 자동화를 사용하지 않으면 자동화가 실제로 비즈니스 가치를 더하거나 사용자를 위해 의도하지 않은 복잡성을 만드는지 알 수 없습니다. 구축하는 모든 자동화는 명확하고 측정 가능한 KPI 집합에 연결되어 있어야 합니다. 좋은 KPI는 연관된 시간 범위와 함께 측정 가능한 값으로 정의됩니다. 예: - \[X 번호] 월별 작업 시간 저장 - 매주 수동 데이터 입력의 처리 실패가 \[Y%]로 감소했습니다. 명확하고 측정 가능한 KPI가 있으면 Salesforce의 자동화가 이러한 KPI에 대한 보고와 관련된 데이터를 생성하는지 여부와 방법을 이해해야 합니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/automated#효율성-패턴-및-안티-패턴) 목록은 Salesforce 자동화와 관련하여 올바르고 나쁜 KPI를 보여줍니다. 이를 사용하여 기존 KPI를 확인하거나 구축하기 전에 KPI를 더 잘 식별해야 하는 위치를 식별할 수 있습니다. KPI에 대한 도움을 받으려면 Salesforce에서 사용할 수 있는 도구에 대해 자세히 알아보려면 자동화된 [도구](/docs/architect/ko-kr/well-architected/guide/automated#자동화와-관련된-도구)를 참조하십시오. ### 효율성 패턴 및 안티 패턴 다음 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/easy-efficiency)에서 효율성을 위한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
프로세스 설계 조직에서:
- 각 플로는 단일 특정 목적을 제공합니다.
- 각 단계는 특정한 세분화된 과업을 수행합니다.
- 플로는 기본 플로 및 지원 하위 플로로 구성된 계층 구조로 구성됩니다.
- 플로 내에서 모든 사용자 입력에 명확한 목적이 있습니다.
- 기존 시스템 데이터를 사용할 수 없는 경우에만 사용자에게 데이터 제공을 요청합니다.
조직에서:
- 플로는 여러 목적으로 사용되며 추가 입력이 있어야만 컨텍스트를 제공할 수 있습니다.
- 플로에는 데이터가 사용되지 않는 입력이 필요합니다.
- 관련 단계 그룹에 다른 플로의 단계 그룹과 겹치는 기능이 포함됩니다.
- 플로에서 대신 저장된 데이터를 사용할 수 있는 경우 사용자 입력을 요청합니다.
Apex:
- 각 클래스는 단일 특정 목적을 제공합니다.
- 각 메서드가 특정한 세분화된 과업을 수행합니다.
- 모든 입력 변수는 클래스 내에서 명확한 목적이 있습니다.
- 코드를 실행하려면 최소한의 자원이 필요합니다.
Apex:
- 여러 목적으로 클래스 제공
- 메서드가 여러 과업을 수행하거나 메서드가 속한 클래스의 명시된 목적에 부합하지 않는 과업을 수행합니다.
- 입력 변수가 실제로 메서드에 사용되지 않음
- 데이터베이스 또는 외부 시스템에서 데이터를 불필요하게 검색하는 메서드
운영 논리 지속:
- 변수는 하드 코딩된 값을 참조하지 않습니다(레코드 유형, 사용자 등).
- 모든 자동 실행 플로 및 프로세스는 결정 및/또는 일시 중지 요소를 사용하여 항목 기준을 평가하고 대용량 데이터에 대한 무한 루프 또는 실행을 방지합니다.
- 플로(프로세스 포함)는 대용량 데이터 컨텍스트에서 Apex 논리를 전달합니다.
- 하위 플로는 비즈니스 전체에서 재사용해야 하는 프로세스 섹션에 사용됩니다.
지속:
- 변수에 하드 코딩된 값이 있습니다.
- 대량 데이터 로드 전에 플로(프로세스 포함)를 수동으로 비활성화해야 합니다.
- 플로(프로세스 포함)는 "처리되지 않은 예외" 알림을 트리거합니다.
- 간단한 플로에서도 정기적으로 총괄자 제한과 관련된 오류가 발생합니다.
- 하위 플로를 사용하는 대신 플로 전체에서 플로의 일부가 반복됩니다.
Apex:
- 변수는 하드 코딩된 값을 참조하지 않습니다(레코드 유형, 사용자 등).
- 모든 와일드카드 기준이 SOSL에 표시됩니다.
- SOQL은 시험 가져오기로 래핑됩니다.
- 루프 내에 SOQL이 표시되지 않음
- SOQL 문은 다음을 포함하여 선택적입니다.
-- LIKE 비교 또는 부분 텍스트 비교 사용 안 함
-- 비교 연산자는 양성 논리(즉, INCLUDES, IN)를 기본 또는 유일한 논리로 사용합니다.
-- = NULL, != NULL의 사용은 드물거나 항상 양성 비교 연산자를 따릅니다.
-- no LIMIT 1 문이 표시됩니다.
-- no use of ALL ROWS 키워드
Apex:
- 변수에 하드 코딩된 값이 있습니다.
- SOSL은 와일드카드 선택 기준에 거의 사용되거나 일관되지 않음
- SOQL은 테이프 캐치에 래핑되지 않음
- SOQL이 루프 내에 표시됩니다.
- SOQL 문은 다음을 포함하여 선택적이지 않습니다.
-- LIKE 및 와일드카드 필터 기준이 나타납니다.
-- NOT, NOT IN 기준을 사용하는 비교는 기본 또는 유일한 비교 연산자로 사용됩니다.
-- = NULL, != NULL 기준이 기본 또는 유일한 비교 연산자로 사용됩니다.
-- 표시되는 LIMIT 1 문
-- ALL ROWS 키워드가 사용됩니다.
설계 표준 및 문서:
- 자동화에 대해 계획된 실행 경로 및 잠재적인 실행 경로가 명확하게 요약되어 있습니다.
- 자동화 내 동기식 및 비동기식 작업에 대한 사용 사례가 설계 표준의 일부로 명확하게 요약되어 있습니다.
설계 표준 및 문서:
- 자동화 호출이 문서화되지 않음
- 동기 및 비동기 작업에 대한 사용 사례가 해결되지 않음
KPIs 문서 내에서:
- 모든 자동화에 대한 출력이 측정 가능하고 시간 바인딩
- 각 KPI에 대해 책임이 있는 이해당사자가 나열됩니다.
문서 내에서:
- 자동화에 대한 KPI가 없거나 측정 시간 범위가 명확하지 않음
- 책임 있는 이해당사자가 없는 KPI가 존재합니다.
보고서 및 대시보드 내:
- KPI와 관련된 모든 메트릭이 하나 이상의 보고서 또는 대시보드에 포함되어 있습니다.
보고서 및 대시보드 내:
- KPI 보고서가 없거나 일부 KPI와 관련된 메트릭이 누락된 보고서
## 데이터 무결성 데이터 무결성은 시스템에서 정확하고 완전한 데이터를 얼마나 잘 유지하는지에 관한 것입니다. Salesforce Platform은 개별 조직의 관계형 데이터베이스에 저장된 데이터의 무결성을 보호하도록 설계된 강력하고 [내장된 처리 논리를](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#데이터베이스-조작) 유지합니다. 정상적인 자동화를 구축하는 기본 사항 중 하나는 Salesforce의 내장 데이터 무결성 동작을 이해하고 모든 자동화 설계가 해당 동작에 부합하는지 확인하는 것입니다. 자동화 설계에서 가장 큰 방해는 강력한 [데이터 무결성 서비스(Salesforce](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#데이터베이스-조작))를 인식하지 못하고 이러한 서비스를 활용하는 [표준 기능](/docs/architect/ko-kr/well-architected/guide/intentional#표준-기능과-사용자-정의-기능-비교)을 사용하지 못함 때문입니다. 데이터 무결성을 보호하고 유지하는 자동화를 설계하려면 Salesforce의 기본 운영 행동 순서를 숙지해야 합니다. 데이터 무결성을 사용자 정의 자동화에 적절하게 확장하면 시스템에서 다음을 수행할 수 있습니다. - 수동으로 개입하지 않고 대량 및 대용량 데이터에 대해 작업 - 필요한 경우 사용자 보안 정책을 적용하고 필요한 경우 시스템 컨텍스트로 전환합니다. - 런타임 시 오류가 발생하고 예측 가능한 복구 또는 실패 경로를 따릅니다. 올바른 데이터 처리 및 오류 처리를 통해 Salesforce 자동화에 더 나은 데이터 무결성을 구축할 수 있습니다. ### 데이터 처리 Salesforce에서 데이터를 올바르게 처리하도록 설계하는 첫 단계는 멀티테넌트 플랫폼이 [트랜잭션을](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#트랜잭션) 처리하는 방식을 이해하는 것입니다. 여기에는 Salesforce Platform이 레코드 수준 데이터 작업 동안 데이터 무결성을 보장하기 위해 사용하는 내장된 [실행 순서](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)의 이해가 포함됩니다. 이 동작의 영향에 대한 자세한 내용은 Salesforce 아키텍처 기본 사항에서 [데이터베이스 조작](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#데이터베이스-조작)을 참조하십시오. 자동화에서 데이터를 처리하지 않으면 식별하고 완전히 해결하기가 가장 어려운 안티 패턴 중 일부가 될 수 있습니다. 플랫폼의 실행 순서가 반복되고 중복되므로 문제가 발생한 위치를 확인하기 어려울 수 있습니다. 치명적인 오류가 발생하거나 총괄자 제한을 초과하는 코드 또는 플로의 특정 섹션이 기본 데이터 처리 문제의 근본 원인일 수 없습니다. *트랜잭션 인식*은 Salesforce에서 신뢰할 수 있고 대규모로 수행할 수 있는 자동화를 구축하는 데 매우 중요합니다. 즉, 자동화의 각 단계가 플랫폼에서 제어하는 [실행 순서](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)와 관련하여 어디에 있는지에 대한 Knowledge로 설계되고, 기능을 올바르게 수행하고, 정보가 다음 단계로 올바르게 전달되는지 확인합니다. 사용 중인 자동화 도구와 상관없이 올바른 트랜잭션 인식은 유사한 패턴을 따르며 일반적인 고려 사항이 필요합니다. - 모든 자동화가 주어진 시간에 공지 없이 대용량 데이터에 대해 실행되도록 요청한다고 가정합니다. 자동화에는 배치 또는 대량 실행을 허용하는 경로가 있어야 합니다([확장성](/docs/architect/ko-kr/well-architected/guide/reliable#확장성) 참조). - 동일한 트랜잭션에서 시스템 및 사용자 컨텍스트 데이터 작업을 혼합하지 마십시오. - 동기화 데이터 작업을 [_이전_ 컨텍스트](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm)에 예약하고 모든 컨텍스트 작업 *후*에 비동기 작업을 사용합니다. - 사용자가 비동기 작업의 결과를 기반으로 데이터를 대기해야 하는 앱 내 환경을 생성하지 않도록 [메시징 및 알림](/docs/architect/ko-kr/well-architected/guide/engaging#알림-및-메시지)을 사용합니다. 트랜잭션 인식 이외에 데이터 처리에는 두 번째 차원이 있습니다. 다른 [실행 컨텍스트](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#실행-컨텍스트)에서 논리를 수행할 시점을 아는 것입니다. 자동화를 다른 실행 컨텍스트로 구분하는 일반적인 이유는 다음과 같습니다. - **대용량 및/또는 복잡한 데이터 작업** - 자동화가 대용량 데이터를 올바르게 처리하는 것을 보장하지는 않습니다[. 대량화 작업](/docs/architect/ko-kr/well-architected/guide/automated#데이터-처리) 자동화 내의 데이터 작업량이 트랜잭션당 제한을 초과할 경우 대용량 데이터에 고유한 기능(예: 배치 Apex 또는 [Bulk 2.0 API](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm))을 사용하여 데이터 작업을 수행해야 합니다. 대용량 데이터에 적합한 고유한 트랜잭션 제한이 있습니다. - 복잡한 관계 계층을 이동하거나 레코드 전체에서 복잡한 재계산(수식 필드 제외)을 수행해야 하는 데이터 작업은 대량으로 수행될 때 트랜잭션당 제한을 쉽게 초과할 수 있습니다. 관련 데이터 작업 또는 시스템에서 후속 작업을 완료하는 데 필요한 SOQL 측면에서 하나의 레코드에 대한 업데이트가 얼마나 "소음"적인지 고려하십시오. - 자동화의 전체 체인에 관여하는 sObjects 유형은 "[교체 DML](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm)" 오류를 방지하기 위해 데이터 작업을 별도의 트랜잭션으로 분할해야 할 수 있습니다. - **사용자 또는 시스템 컨텍스트에서 실행해야 하는 논리** - Salesforce Platform은 사용자 컨텍스트에서 [공유 및 가시성을 적용합니다](/docs/architect/ko-kr/well-architected/guide/secure#공유-및-가시성). 자동화 사용자의 권한 수준 이상으로 확장되는 작업을 수행해야 하는 경우 해당 작업이 시스템 컨텍스트에서 실행되는지 확인해야 합니다. - 다양한 도구가 다른 컨텍스트에서 실행되거나 실행되지 않습니다. - Apex 기본적으로 시스템 컨텍스트에서 실행됩니다. Apex 클래스 정의에서 [공유 키워드](https://developer.salesforce.com/docs/atlas.en-us.238.0.apexcode.meta/apexcode/apex_classes_keywords_sharing.htm?q=run%20as%20user)를 사용하여 Apex 동작이 사용자 수준 공유 규칙을 적용하는지 여부와 방법을 제어할 수 있습니다. - 플로에는 단일 기본 동작이 없습니다. 플로가 사용자 또는 시스템 컨텍스트에서 실행됩니다[. 플로가 시작되는 방법에 따라](https://help.salesforce.com/s/articleView?id=sf.flow_distribute_context.htm&type=5) 시스템 컨텍스트에서 공유를 적용할 수 있는 옵션이 있습니다. - 프로세스(즉, 프로세스 빌더로 구축된 자동화)는 공유 고려 사항 없이 시스템 컨텍스트에서 실행됩니다. (주: 플로를 사용하여 하위 코드 자동화를 구축하는 것이 좋습니다. - **비동기식으로 실행해야 하는 논리** - 외부 시스템 작업 - 외부 데이터에 액세스하는 동기식 콜아웃 또는 작업은 플랫폼 롤백 동작에 포함되지 않습니다. 이러한 동작을 활용하려면 외부 시스템을 포함하는 작업을 별도의 트랜잭션(비동기 [Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_async_overview.htm) 메서드, [비동기 경로](https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_builder_asynchronous_path.htm&type=5&release=234) 또는 [ 호출 가능한 작업](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_forcecom_flow_invocable_action_callout.htm) 사용)에 배치해야 합니다. - 이벤트 및 메시징 - 데이터 작업과 관련된 이벤트 또는 메시지의 흐름을 제어하고 플랫폼 롤백 동작을 활용하려면 비동기 Apex 메서드를 사용하여 메시징 또는 이벤트와 관련된 모든 작업을 컨텍스트 [_후에_](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm) 배치합니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/automated#데이터-무결성-패턴-및-안티-패턴) 목록은 Salesforce 자동화에서 올바르고 나쁜 데이터 처리를 보여줍니다. 이를 사용하여 구축하기 전에 자동화 설계의 유효성을 검사하거나 데이터 처리를 개선하기 위해 재구성해야 하는 자동화를 식별할 수 있습니다. 자동화에서 데이터 처리를 위해 Salesforce에서 사용할 수 있는 도구에 대해 자세히 알아보려면 자동화와 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/automated#자동화와-관련된-도구)를 참조하십시오. ### 오류 처리 오류 처리는 데이터 무결성에 중요합니다. 강력한 오류 처리 기능은 또한 시스템의 확장 및 오래된 상태를 더욱 [활성화할 수 있도록 돕습니다](/docs/architect/ko-kr/well-architected/guide/resilient). 자동화에서 오류를 부적절하게 처리하면 다음이 발생할 수 있습니다. - 레코드 불일치 및 기타 데이터 무결성 문제 - 사용자 및 다른 시스템에 부정확한 알림 보내기 - 수동 또는 반복적인 처리에 시간과 자원 낭비 - 시스템에 대한 전반적인 [Trust](/docs/architect/ko-kr/well-architected/guide/trusted-overview) 부족 자동화에서 오류를 처리하려면 실행 중인 프로세스에 오류를 구문 분석하고, 오류 정보를 기반으로 다음 단계에 대한 논리에 액세스하는 기능을 부여한 다음, 올바른 경로를 따르십시오. 이러한 기능은 모든 자동화에서 반복적으로 구축할 필요가 없습니다(그것은 [최적화 안티 패턴](/docs/architect/ko-kr/well-architected/guide/automated#프로세스-설계)입니다). 대신 시스템의 모든 자동화는 관련 오류 처리 [구성 요소](/docs/architect/ko-kr/well-architected/guide/composable#느슨한-커플링)에 연결할 수 있어야 합니다. 자동화에 적절한 오류 처리 제어를 구축하려면 다음 질문을 하십시오. - "정상" 오류란 무엇입니까? - "복구 가능" 오류란 무엇입니까? - 사용자 작업으로 트리거된 자동화의 경우 자동화가 변경을 커밋하기 전에 사용자에게 오류를 포착하고 알릴 수 있는 방법은 무엇입니까? 이러한 오류를 처리하는 방법을 결정하면 자동화에 효과적인 오류 처리를 구축할 수 있습니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/automated#데이터-무결성-패턴-및-안티-패턴) 목록은 Salesforce 자동화에서 올바르고 나쁜 오류 처리를 보여줍니다. 이를 사용하여 구축하기 전에 자동화 설계의 유효성을 검사하거나 오류 처리를 개선하기 위해 재구성해야 하는 자동화를 식별할 수 있습니다. 오류 처리에 대해 Salesforce에서 사용할 수 있는 도구에 대한 자세한 내용은 자동화에 대한 [도구](/docs/architect/ko-kr/well-architected/guide/automated#자동화와-관련된-도구)를 참조하십시오. ### 데이터 무결성 패턴 및 안티 패턴 다음 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/easy-data-integrity)에서 데이터 무결성에 대한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
데이터 처리 데이터 사전:
- 모든 데이터 소스 및 데이터 레이크 개체에 대한 필드 수준 데이터 및 우선 순위 지정 논리가 있습니다.
- 데이터 레이크 개체에서 데이터 모델 개체로 필드 매핑이 있는 경우
데이터 사전:
- 데이터 소스 및 데이터 레이크 개체에 대한 필드 수준 데이터 및 우선 순위 지정 논리가 포함되지 않습니다.
- 데이터 레이크 개체에서 데이터 모델 개체로의 필드 매핑은 포함되지 않습니다.
Apex에서:
- 모든 동기식 DML 문 또는 데이터베이스 클래스 메서드가 트리거 실행 컨텍스트 전에 수행됩니다.
- 비동기 Apex 호출은 트랜잭션 전반에 걸친 복잡한 DML에 대기 가능을 사용합니다.
- 배치 Apex 대용량 데이터에만 사용됩니다.
- @future Apex가 콜아웃 또는 시스템 객체 DML에 사용되거나 사용되지 않습니다.
Apex에서:
- DML 문은 정기적으로 트리거 컨텍스트 후에서 호출되는 코드에 표시됩니다.
- 비동기 Apex 거의 사용되지 않습니다.
- 비동기 Apex 기능은 다음을 포함하여 임의로 사용됩니다.
-- Future 메서드 및 대기 가능한 Apex 일관되지 않거나 상호 교환적으로 사용됩니다.
-- 데이터베이스 작업에 필요한 경우 배치 Apex 실행을 전달하기 위한 명확하고 일관된 논리가 없습니다.
지속:
- 사용자 컨텍스트에서 시작된 모든 플로는 모든 시스템 컨텍스트 트랜잭션을 일관되게 일시 중지 요소 뒤에 배치되는 하위 플로에 추상화하여 새 트랜잭션을 생성합니다.
- 오케스트레이터를 사용하여 관련 데이터 작업의 복잡한 시퀀스를 만듭니다(모노리틱 플로 내에서 여러 하위 플로를 호출하는 대신).
- 모든 레코드 트리거 플로에 트리거 순서 값이 채워집니다.
- 외부 시스템 콜아웃 또는 장기 실행 프로세스와 관련된 플로는 비동기 경로를 사용합니다.
지속:
- 대형 모노리틱 플로는 관련 데이터 작업의 복잡한 시퀀스를 조정하도록 시도합니다(하위 플로 포함 또는 제외).
- 레코드 트리거 플로는 트리거 순서 특성을 전혀 사용하지 않거나 트리거 순서 값을 일관적으로 사용하지 않습니다.
- 비동기 경로는 일관되게 사용되지 않거나 전혀 사용되지 않습니다.
조직에서:
- ID 확인 조정 규칙은 데이터 사전의 우선 순위 논리를 따릅니다.
조직에서:
- ID 확인 조정 규칙은 데이터 사전의 우선 순위 논리를 따르지 않습니다.
오류 처리 Apex:
- 코드는 모든 DML, SOQL, 콜아웃 및 기타 중요한 프로세스 단계를 테이프 캐치 블록으로 래핑합니다.
- 고급 오류 메시지 및 논리를 만드는 데 사용자 정의 예외가 사용됩니다.
- 비동기 및 대량 컨텍스트에서는 DML 대신 데이터베이스 클래스 메서드가 사용됩니다.
- 데이터베이스 클래스 메서드는 DML 대신 모든 데이터 작업에만 사용할 수 있습니다.
Apex:
- DML, SOQL, 콜아웃 또는 기타 중요한 프로세스 단계가 일관되게 테이프 캐치 블록에 래핑되지 않음
- System.debug 문은 프로덕션 코드에 표시되며 코멘트가 표시되지 않습니다.
- 데이터베이스 클래스 메서드가 사용되지 않음
- 데이터 작업은 DML에서만 수행됩니다.
Lightning 웹 구성 요소(LWC):
- JavaScript는 모든 데이터 작업 및 중요한 프로세스 단계를 블록 인 경우 () / 다른 경우 () 묶습니다.
- 모든 @wire 함수는 API에서 제공하는 데이터 및 오류 속성을 사용합니다.
- All if (error) / ele if (error) 문은 오류를 처리하고 정보 메시지를 제공하는 논리를 포함합니다.
LWC:
- JavaScript는 데이터 작업 또는 중요한 프로세스 단계를 차단하는 경우 일관되게 사용되지 않습니다. () / 다른 경우 ()
- @wire 함수는 API에서 제공하는 데이터 및 오류 속성을 사용하지 않습니다(또는 일관되게 사용하지 않습니다).
- 전혀 사용되는 경우, (오류) / 기타(오류) 문에 실제로 오류를 처리하고 유용한 오류 메시지를 제공하는 논리가 포함되지 않습니다.
Aura:
- JavaScript는 모든 데이터 작업 및 중요한 프로세스 단계를 시도 캐치 블록으로 래핑합니다.
- Try-catch 블록 내에서 throw 문에 네이티브 JavaScript 오류가 사용됩니다($A.error()의 사용 안 함)
- 모든 복구 가능한 오류 논리가 캐치 문 안에 나타나고 명확한 사용자 메시지를 제공합니다.
Aura:
- JavaScript는 데이터 작업 및 중요한 프로세스 단계를 일관되게 시도 캐치 블록으로 래핑하지 않습니다.
- 구성 요소는 $A.error()를 사용합니다.
- 복구 가능한 오류 논리가 캐치 명령 내에 일관되게 표시되지 않으며 사용자에게 오류 메시지가 명확하지 않습니다.
지속:
- 화면 플로에서 오류 커넥터를 사용하여 사용자에게 오류를 표시합니다.
- 화면에 표시되는 오류에 대해 사용자 정의 오류 메시지가 구성됩니다.
- 데이터 작업, 콜아웃 및 기타 중요 처리 논리가 있는 플로는 모든 주요 작업에 대한 오류 경로가 있습니다.
지속:
- 플로에서 오류 경로를 일관되게 또는 전혀 사용하지 않습니다.
- 사용자 정의 오류 메시지가 사용되지 않으므로 사용자에게 기본 "이 플로에서 처리되지 않은 오류가 발생했습니다" 메시지가 표시됩니다.
## 비즈니스 가치 자동화 컨텍스트에서 비즈니스 가치의 개념은 프로세스가 비즈니스 이해당사자에게 측정 가능한 긍정적인 영향을 미치는 정도에 관한 것입니다. 프로세스 자동화를 사용하면 사용자가 가치가 낮은 반복적인 과업에 소요되는 시간을 줄일 수 있습니다. 오류를 유발할 수 있는 수동 처리 활동을 제거하여 데이터 무결성을 높일 수도 있습니다. [프로세스 디자인](/docs/architect/ko-kr/well-architected/guide/automated#프로세스-설계)과 마찬가지로 실제 비즈니스 가치를 창출할 수 있는 자동화를 식별하고 제공하려면 기본적인 검색 및 비즈니스 분석 이상의 작업이 필요합니다. 비즈니스에 가치를 제공하는 가장 좋은 방법은 백로그(또는 티켓 대기열)에 표시되는 순서대로 또는 조직의 정치적 요소를 기반으로 비즈니스 사용자가 요청한 모든 프로세스를 자동화하기만 하면 됩니다. 이렇게 하면 두 가지 관련 문제가 발생할 수 있습니다. 자동화를 최적화되지 않은 순서로 구축하고 잘못된 자동화를 모두 구축합니다. 첫 번째 문제인 우선 순위 지정이 좋지 않으면 중요한 프로세스가 적시에 구현되지 않으므로 성장이 잠재적으로 느려집니다. 잘못된 자동화를 구축하는 두 번째 문제는 가치가 큰 자동화의 전달을 지연시킬 뿐만 아니라 시간 낭비, 불필요한 비용, 배달 팀의 불만족을 증가시킵니다. KPI 및 우선 순위 지정에 집중하여 비즈니스 가치를 높일 수 있습니다. ## 자동화와 관련된 도구
도구설명효율성데이터 무결성비즈니스 가치
Apex 배치레코드를 함께 배치하고 관리 가능한 청크로 처리XX
Apex Future Methods백그라운드에서 비동기식으로 Apex 메서드 실행XX
Apex 대기열 Apex 작업을 대기열에 추가하고 모니터링XX
Apex Scheduler지정된 시간에 비동기식으로 Apex 클래스 실행XX
승인레코드를 승인하는 데 필요한 단계 지정XX
비동기 ApexApex 코드를 비동기식으로 실행XX
자동화된 작업백그라운드에서 필드 업데이트, 이메일 보내기 및 기타 작업 수행XX
Einstein Next Best Action적시에 적절한 사람에게 적절한 권장 사항 표시XX
이메일 경고자동화된 이메일 만들기 및 보내기XX
에스컬레이션 작업사례 에스컬레이션에 수행할 자동화된 작업 지정XX
필드 업데이트자동화를 기반으로 필드 값 업데이트XX
플로우 빌더포인트 앤 클릭 인터페이스로 자동화 구축XX
플로 확장플로에서 구성 요소 입력으로 저장된 변수에 액세스X
플로 템플릿 라이브러리템플릿을 사용하여 산업별 플로 설계XX
플로 트리거복잡한 비즈니스 프로세스 자동화X
청구 가능한 조치플로에 Apex 기능 추가XX
오케스트레이터다단계 자동화 만들기 및 관리XX
아웃바운드 메시지영수증 및 재시도가 포함된 자동 프로세스에서 정보 보내기 X
플로를 사용하여 플랫폼 이벤트 게시사용자 상호 작용 및 자동화를 통한 이벤트 게시X
쿼리 최적화 프로그램선택성 및 색인을 사용하여 쿼리, 보고서, 목록 보기 성능 향상XX
Salesforce 플로Flow Builder로 선언적 프로세스 자동화 만들기XX
플로를 사용하여 알림 보내기SMS, WhatsApp 또는 Facebook Messenger를 통해 메시지 보내기XX
프로세스와 함께 알림 보내기SMS, WhatsApp 또는 Facebook Messenger를 통해 메시지 보내기XX
업데이트 수정자용 SOQL레코드를 잠가 레이스 조건 및 스레드 안전 문제 방지X
Strategy Builder 레코드 페이지에 표시할 권장 사항 식별XX
하위 흐름재사용을 통한 플로 복잡성 줄이기X
플랫폼 이벤트를 플로로 구독하기자동화를 통해 게시된 메시지 수신X
작업 작업자동화에서 사용자에게 제공되는 할당 세부 사항 결정X
## 자동화됨과 관련된 자원
자원설명효율성데이터 무결성비즈니스 가치
Apex 실행 총괄자 및 제한Apex 런타임 엔진이 제한을 적용하는 방법 알아보기XX
배치 관리 자원배치 작업 만들기, 관리, 예약 및 모니터링XX
SOQL 및 SOSL의 모범 사례 대용량 데이터를 사용하여 응용 프로그램의 쿼리 성능 향상X
설계 표준 템플릿조직에 대한 설계 표준 만들기XXX
트랜잭션의 플로 대량 처리컬렉션에 대해 작동하도록 플로 설계XX
플로 데이터 고려 사항배치 데이터에 대한 일정 트리거 플로에 대해 알아보기XX
플로 디버깅플로 테스트 및 문제 해결X
요청 처리 방법Salesforce가 작업을 빠르게 처리하고 실패를 최소화하는 방법 알아보기XX
KPI 스프레드시트 템플릿특정 메트릭의 비즈니스 가치 결정XX
호출 가능한 작업에서 외부 시스템에 콜아웃 만들기Apex 사용하여 플로에서 외부 시스템 호출X
혼합 DML 작업 동일한 트랜잭션에서 DML에 함께 사용할 수 있는 sObject 파악XX
실행 명령삽입, 업데이트, 업서트에 대한 이벤트 순서 이해XX
쿼리 계획 FAQ대용량 데이터와 관련된 쿼리 최적화XX
예약 트리거형 플로 고려 사항일정 트리거 플로의 특수 동작 이해X
트랜잭션 관리현재 데이터베이스 상태를 지정하는 세이브포인트 생성XX
플로가 실패하면 어떤 일이 발생합니까? 플로의 오류 처리 이해XX
워크플로 자동화 모범 사례 가이드Salesforce 자동화 시작하기XXX
대규모 SOQL 쿼리 작업더욱 효율적인 SOQL 쿼리 작성X
## 의견을 알려주십시오. Salesforce Well-Architected의 관련성을 유지할 수 있도록 도와주십시오. 이 콘텐츠에 대한 사용자 의견을 제공하려면 [ 설문 조사](https://sfdc.co/bxNtvh)을 작성하고 다음에 표시할 내용을 알려주십시오. > 업데이트 일정을 [여기](/docs/architect/ko-kr/well-architected/guide/contributors) 읽어보세요. ## 소개 **적응 가능한** Salesforce 솔루션은 비즈니스와 함께 발전합니다. **적응성**을 위해 잘 설계된 솔루션은 견고하고 복합성이 뛰어납니다. **복원성 있는** 솔루션은 변화를 잘 처리합니다.
**조립 가능한** 솔루션은 빠르고 안정적으로 조정됩니다. 비즈니스 변경의 필요성은 고객 요청, 시장 또는 산업 중단 또는 디지털 변환 기회와 같은 여러 소스에서 발생할 수 있습니다. 경우에 따라 변경 사항이 작습니다. 때로는 심각한 변화가 발생합니다. 가장 심층적인 수준에서 비즈니스는 변경을 통해 운영을 위한 핵심 이유를 다시 생각하고 변경하고 고객이 제공하는 내용, 방법, 위치를 다시 평가해야 할 수 있습니다. **적응성이 뛰어난** 아키텍처는 단지 기업이 중단으로부터 생존하고 회복하는 것을 돕는 것뿐만 아니라 심오한 변화의 시기에 기업이 혁신하고 번영할 수 있는 잠재력을 창출합니다. **적응 가능**한 시스템을 만들려면 창의적이고 정밀한 건축적 사고가 필요합니다. 비즈니스의 단기 및 장기 여정에 대한 정확한 이해로 시작해야 합니다. 개별 구현 세부 사항을 평가할 때 다양한 차원 및 세부 사항 수준에 따른 영향을 고려해야 합니다. 사람, 프로세스 및 기술 측면에서 생각해야 합니다. 또한 현재 상태 및 향후 상태에 대한 영향을 매크로 및 마이크로 수준에서 동시에 예측해야 합니다. 다음 섹션은 **Adaptable** 솔루션 아키텍처의 각 핵심 동작에 대한 자세한 지침을 제공합니다. ## 적응 가능한 개요
항력
복원형 솔루션은 변경 사항을 효과적으로 처리합니다. 복원형 아키텍처는 예측 가능한 방식으로 빠르게 예상되는 동작 및 작업으로 돌아갈 수 있습니다.
응용 프로그램 수명 주기 관리 사고 대응 계속성 계획
릴리스 관리
환경 전략
테스트 전략
복구 시간
분류 기능
모니터링 및 경고
비즈니스 연속성
기술 연속성
공합 가능
구성 가능한 솔루션은 빠르고 안정적으로 조정됩니다. 구성 가능한 아키텍처는 서로 원활하게 작동하는 단위로 구축되며, 서비스 내 및 외에 교체할 수 있습니다.
걱정 구분 상호 운용성 포장성
기능 단위
시/도 관리
Messaging 및 이벤트
API 관리
느슨한 커플링
종속성 관리
> [여기에](/docs/architect/ko-kr/well-architected/guide/contributors) 업데이트 일정에 대해 알아보십시오. ## 소개 시스템은 사용자가 쉽게 앱에 액세스하고 사용하도록 만들고, 사용자가 더 높은 품질의 작업을 수행한다고 느끼게 하고, 사용자가 시스템에서 앱을 사용하기를 원함으로써 참여하는 동작을 보여줍니다. 참여형 동작을 제공하는 것은 전반적인 작업자 및 고객 만족도뿐만 아니라 사용자 채택과 직접적으로 관련이 있으므로 비즈니스에 중요합니다. 참여 동작은 지원 요청을 줄이고 사용자의 기능 요청 품질을 향상하는 데도 도움이 됩니다. 참여형 동작을 만드는 데 발생하는 문제 중 하나는 목표 메트릭으로만 측정하기가 어렵다는 점입니다. 대신 사용자의 주관적 경험에 따라 측정됩니다. 사용자는 참여 앱이 실제 값을 제공한다고 생각합니다. 참여 앱은 [액세스 가능](/docs/architect/ko-kr/well-architected/guide/compliant#접근성)하며 침입하지 않으며 쉽게 이해할 수 있습니다. 최소한의 온보딩 및 교육이 필요합니다. 또한 명확한 방법을 사용하여 사용자 오류를 사전에 방지합니다. 또 다른 문제는 시스템의 다양한 유형의 사용자 상호 작용에 따라 참여 목표가 종종 달라지는 것입니다. 예를 들어 사례를 관리하는 내부 사용자에 대한 목표 집합과 웹 사이트의 양식을 통해 정보를 제출하는 외부 사용자에 대한 목표 집합이 있을 수 있습니다. 참여 시스템을 설계하려면 생성하려는 참여 유형과 사용자가 참여하고자 하는 이유를 주의 깊게 고려해야만 기능 및 페이지 구성을 시작할 수 있습니다. 사용자 환경(UX) 디자이너와 파트너 관계를 맺으면 참여 앱을 제공할 때 훨씬 효과적인 결정을 내릴 수 있습니다. 아키텍처 관점에서 사용자 채택 및 유지는 정상적인 시스템의 중요한 구성 요소입니다. 참여 아키텍처를 사용하면 사용자가 프로세스를 빠르게 진행하거나 단계를 건너뛰어 사용자가 원하지 않는 시스템에서 시간을 보내지 않아도 되는 데이터 품질 문제 발생할 가능성이 줄어듭니다. 외부 시스템의 경우 참여형 아키텍처를 사용하면 시스템을 쉽게 사용할 수 있는 시스템을 찾는 고객이 조직과 더 많은 비즈니스를 수행하기로 선택하여 매출 및 고객 유지율을 높일 수 있습니다. 간소화되고 유용한 환경을 제공하는 데 집중하여 더욱 참여도가 높은 앱을 만들 수 있습니다. ## 간소화됨 간소화된 앱은 쉽게 탐색하고, 정보 및 데이터 입력 과업을 명확하게 표시하고, 다양한 양식 요소에 맞게 조정할 수 있습니다. 간소화된 앱은 사용자가 다른 일반적으로 사용되는 응용 프로그램에서 익숙해진 환경 패턴도 제공합니다. 예를 들어 대부분의 웹 브라우저에서 사용자가 링크를 마우스 오른쪽 버튼으로 클릭하면 상단 옵션으로 "새 탭에서 열기"가 표시됩니다. 탭을 포함하는 간소화된 앱은 같은 패턴을 따릅니다. 비효율적인 앱 환경의 영향은 개별 앱을 넘을 수 있습니다. 앱 환경이 좋지 않으면 사용자의 Trust 저하됩니다. 더 많은 종류의 비즈니스에 중요한 앱과 고객 대면 앱이 디지털 채널로 이동하면 주요 이해당사자의 충성도를 회사에 부과할 수 있습니다. 앱 복잡성, 양식 설계, 양식 요소에 대해 의도적으로 접근하는 방식으로 앱을 더욱 간소화할 수 있습니다. ### 응용 프로그램 복잡성 응용 프로그램 복잡성을 최소화하면 사용자에게 관련 메뉴 항목, 탭 및 탐색 컨트롤만 표시됩니다. 사용자 그룹, 사용자 권한 및 올바른 앱 환경 간 매핑을 만들어야 합니다. 해당 매핑을 사용하여 주어진 사용자에게 제공할 앱 환경을 이해한 다음, 앱에 해당 환경을 제공하는 데 필요한 논리 제어 기능이 있는지 확인합니다. 사용자에게 너무 복잡한 앱을 제공하면 다음과 같은 다양한 불량 환경이 발생할 수 있습니다. - 사용자에게 불필요하거나 관련 없는 탭이 자주 표시되고 빈 화면으로 이동하거나 비활성화되거나 차단된 링크가 발생합니다. - "역할이 X인 경우 이 탭을 무시..."와 같은 불필요하거나 도움이 되지 않는 지침이 교육 및 활성화 자료에 나타납니다. - 복잡한 탐색 메뉴를 사용하면 사용자가 작업을 완료하기 위해 필요한 항목을 찾는 데 추가 시간을 할애해야 합니다. 불량한 환경으로 인해 채택률과 만족도가 낮아집니다. 적절한 수준의 앱 복잡성을 결정할 때 다음 사항을 고려하십시오. - 사용자가 수행해야 하는 작업의 우선 순위를 기반으로 메뉴, 탭 및 기타 탐색 컨트롤을 구성합니다. - 사용자가 앱을 사용할 수 있도록 학습해야 하는 새로운 동작을 도입하지 마십시오. - 사용자가 사용자 인터페이스의 측면을 사용자 정의할 수 있는 기능에 대한 액세스를 제거하지 마십시오. - 권한 집합을 사용하여 확장 또는 축소된 탐색 옵션을 제공합니다. - Lightning 페이지 [활성화 할당](https://help.salesforce.com/s/articleView?id=sf.lightning_page_getting_into_salesforce1.htm)을 단순화합니다. 앱당 활성 Lightning 페이지 수 최소화 동적 양식, 권한 집합 및 조건부 렌더링을 사용하여 앱의 Lightning 페이지에 항목을 추가합니다. 프로필별로 활성화되고 할당된 여러 Lightning 페이지를 유지하는 대신 이 작업을 수행합니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/engaging#간소화된-앱-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 올바르고 나쁜 앱 복잡성 관리를 보여줍니다. 이를 사용하여 응용 프로그램 디자인을 확인하거나 개선할 수 있습니다. 응용 프로그램 복잡성을 관리하는 데 도움이 되는 Salesforce 도구에 대해 자세히 알아보려면 참여와 관련된 [도구를 참조하십시오](/docs/architect/ko-kr/well-architected/guide/engaging#참여와-관련된-도구). ### 양식 간소화된 양식은 정보를 논리적인 순서로 구성하고, 빠른 데이터 입력을 지원하며, 필수 단계를 최소화합니다. 또한 [유용한](/docs/architect/ko-kr/well-architected/guide/engaging#유용) 클라이언트측 데이터 확인 메시지를 허용하고 반복적인 양식 제출 주기를 제거합니다. 양식을 설계할 때 다음 사항을 고려하십시오. - **관련 필드를 함께 그룹화**합니다. 프로세스 또는 데이터 입력 과업의 동일한 단계와 관련된 필드 그룹화 보유 중인 과업과 직접적으로 관련이 없는 필드를 제거합니다. - **데이터 입력 및 검증을 조기에 수행**합니다. 사용자가 데이터를 입력해야 하는 필드는 양식에 조기에 표시되어야 합니다. 필드 수준에서 가능한 한 빨리(즉, 사용자가 다음 단계로 이동하거나 양식을 제출하기 전에) 데이터 형식 또는 누락된 데이터 관련 문제를 표시하는 것이 가장 좋습니다. 또한 사용자가 필드에 데이터를 입력할 기회가 없기 전에 필드 수준 오류가 표시되지 않도록 합니다. - **데이터 입력 작업 최소화** 최대한 많은 필드를 미리 채우거나 자동 완성하여 데이터 입력 오류를 최소화하고 효율성을 향상합니다. 사용자에게 필수 또는 중요한 데이터만 입력하도록 요청합니다. 보유 중인 비즈니스 프로세스와 관련이 없는 데이터 입력을 제거합니다. 가능한 경우 자유 양식 텍스트 필드 대신 선택 목록을 사용하여 유효한 옵션 선택 항목을 적용하고 동일한 답변의 변형을 줄입니다. - 서버에 대한 **제출 최소화** 다단계 양식이 서버에 데이터를 여러 번 제출하지 않도록 합니다. 모든 사용자 정의 [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.apex_result_caching) 또는 [Aura](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_storable_actions.htm) 구성 요소에서 클라이언트측 캐싱을 사용하여 탐색 또는 페이지 매김 작업을 처리합니다. (Salesforce Lightning Experience 및 Salesforce 모바일 앱은 기본적으로 클라이언트측 캐싱을 사용합니다.) 사용자가 한 번만 서버에 데이터를 제출할 수 있도록 양식을 설계합니다. 양식을 제출하기 전에 클라이언트 측에서 사용자 입력을 확인합니다. 이렇게 하면 의도치 않은 사용자 제출을 최소화하고, 중복 또는 더러운 트랜잭션이 백엔드에서 대역폭을 소비하지 않도록 방지하며, 더 나은 [데이터 처리를 위해](/docs/architect/ko-kr/well-architected/guide/automated#데이터-처리) 설계할 수 있습니다. - **폼 상태 관리** 클라이언트측 캐싱은 탐색 및 페이지 매김과 같은 동작에 도움이 될 뿐만 아니라 간헐적인 연결 문제로 인해 데이터 손실을 최소화하는 데도 도움이 됩니다. 또한 상태를 효과적으로 관리하면 앱이 데이터 제출을 서버에 적절하게 오케스트레이션하고 중복 트랜잭션을 방지하고 서버측 작업 상태를 기반으로 사용자에게 적시에 관련 메시지를 표시할 수 있습니다. 간소화된 양식은 데이터 작업을 한 번만 제출하며 사용자가 서버에서 장기 실행 작업이 완료될 때까지 기다리지 않아도 됩니다. - **액세스 가능성 기준 준수** 앱의 대상 그룹을 극대화하고 모든 고객이 참여할 수 있도록 지원하려면 양식 디자인에 [가용성](/docs/architect/ko-kr/well-architected/guide/compliant#접근성) 표준을 적용합니다. 간소화된 양식은 앱의 [데이터 무결성을](/docs/architect/ko-kr/well-architected/guide/automated#데이터-무결성) 높이고 앱이 사용자에게 얼마나 [용이한지](/docs/architect/ko-kr/well-architected/guide/engaging#유용) 보여줍니다. 또한 사용자가 오류를 해결하고 양식 제출 상태를 명확하게 이해할 수 있으므로 지원 티켓 및 요청을 줄일 수 있습니다. 또한 간소화된 양식은 빠르고 효율적인 데이터 입력을 지원하며, 사용자가 추가 작업을 수행하기 위해 더 오래 걸리는 프로세스가 완료될 때까지 기다리지 않아도 됩니다. 아래의 [모형 및 안티모형](/docs/architect/ko-kr/well-architected/guide/engaging#간소화된-앱-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 올바르고 나쁜 양식 디자인을 보여줍니다. 이를 사용하여 양식 디자인을 확인하거나 개선할 수 있습니다. 더욱 간소화된 양식을 구축할 수 있는 Salesforce 도구에 대해 자세히 알아보려면 참여와 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/engaging#참여와-관련된-도구)를 참조하십시오. 사용 사례에 적합한 양식 도구를 선택하는 방법에 대한 자세한 지침은 [Salesforce를 사용하여 양식 구축을 위한 아키텍트의 결정 가이드](/docs/architect/ko-kr/decision-guides/guide/build-forms#주요-인테이크)를 참조하십시오. ### 양식 요소 참여 앱은 다양한 장치 및 상호 작용 유형 또는 양식 요소에 정상적으로 적응합니다. 장치 유형에 따라 다양한 유형의 사용자 상호 작용이 더 쉽거나 더 어려워지고 양식 및 필드의 가독성이 변경됩니다. 화면 차원 외에도 양식 요소는 사용자가 화면과 상호 작용하는 방식도 나타냅니다. 점점 더 많은 장치가 터치스크린을 갖추고 있으며 일부 사용자는 [접근성](/docs/architect/ko-kr/well-architected/guide/compliant#접근성)을 위해 특별한 장치를 사용할 수도 있습니다. 양식을 설계할 때 다음 요소를 고려하십시오. 양식 요소 변형을 고려하지 못하면 다음을 포함하여 다양한 문제를 야기할 수 있습니다. - 데이터 품질이 좋지 않음 - 사용할 수 없는 앱 인터페이스 - 지원 에이전트에 대한 추가 문제 해결 또는 "대신 주문" 세션 - 사용자 채택 부족, 활성 사용자 수가 적고 앱 "중단" 비율이 높은 경우 Salesforce 앱에서 양식 요소 전반의 상호 운용성을 설계하려면 다음을 고려하십시오. - 모든 앱에 대해 지원되는 양식 요소를 **지정합니다**. - **입력 방법 및 사용자의 접근성 요구 사항 파악** 자세한 내용은 [가용성](/docs/architect/ko-kr/well-architected/guide/compliant#접근성)을 참조하십시오. - **가능할 때마다 [표준 기능](/docs/architect/ko-kr/well-architected/guide/intentional#표준-기능과-사용자-정의-기능-비교)을 사용하여 장치 간에 적응형 환경을 제공합니다**. - Salesforce에서 제공하는 [Lightning 페이지 템플릿](https://help.salesforce.com/s/articleView?id=sf.lightning_page_templates.htm&type=5)은 기본적으로 다른 양식 요소를 지원합니다. Aura를 사용하여 사용자 지정 Lightning 페이지 템플릿을 개발하려는 경우 개발자가 구성 요소 설계 파일에 양식 요소 정보를 통합해야 합니다. - Salesforce에서 제공하는 [표준 페이지 구성 요소](https://help.salesforce.com/s/articleView?id=sf.lightning_page_components.htm&type=5)는 지원되는 양식 요소 간 렌더링을 처리합니다. LWC 또는 Aura로 사용자 정의 구성 요소를 만드는 경우 개발자는 너비 인지도([Aura](https://developer.salesforce.com/docs/atlas.en-us.238.0.lightning.meta/lightning/components_config_for_app_builder_width_aware.htm?q=width)와 [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_width_aware) 간 구현 차이점)를 처리하고 구성 요소의 설계 파일 내에서 양식 요소 지원을 선언해야 합니다. - ** [모든 장치에서 간소화된 양식을](/docs/architect/ko-kr/well-architected/guide/engaging#양식) 확인하려면 지침을 따르십시오**. - 주요 양식 요소에 대한 **테스트 계획(및 좋은 테스트) 만들기** 모든 장치 및 모든 앱의 양식 요소에 대해 테스트하는 것이 좋습니다. 그러나 폼 팩터 테스트를 위해 올바른 장치(또는 장치 시뮬레이터)를 설정하는 것은 상당한 투자가 될 수 있습니다. 특정 앱 또는 앱 집합에 모바일 또는 태블릿에서 상당한 사용자 집합이 있을 경우 모바일 및 태블릿 폼 팩터에서 해당 앱에 대한 정확한 테스트를 우선적으로 지정합니다. 아래의 [패턴 및 반패턴](/docs/architect/ko-kr/well-architected/guide/engaging#간소화된-앱-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 올바른(또는 나쁜) 폼 팩터 인식을 보여줍니다. 이를 사용하여 구축하기 전에 디자인의 유효성을 검사하거나 새로 고쳐야 하는 페이지를 식별할 수 있습니다. 효과적인 양식 요소 설계를 위한 Salesforce 도구에 대한 자세한 내용은 참여와 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/engaging#참여와-관련된-도구)를 참조하십시오. ### 간소화된 앱 패턴 및 안티 패턴 다음 표는 조직에서 조회(또는 구축)할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/easy-streamlined)에서 간소화된 앱에 대한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
앱 복잡성 조직에서:
- 앱의 관리자 제공 기본 구성 탭이 10개 미만임
- "이 앱에서 탐색 항목의 최종 사용자 개인 설정 비활성화"가 true로 설정된 앱이 없습니다.
조직에서:
- 앱의 관리자 제공 기본 구성에 정기적으로 10개가 넘는 탭이 있습니다.
- 많은 앱에 "이 앱에서 탐색 항목의 최종 사용자 개인 설정 비활성화"가 true로 설정되었거나 탐색 항목 사용자 정의 권한이 조직 전체에서 비활성화되어 있습니다.
형식 앱에서:
- 필드가 논리 그룹화를 따릅니다.
- 데이터 입력 필드가 5개 이하의 그룹으로 함께 표시됩니다.
- 사용자가 이동하거나 데이터를 제출하기 전에 데이터 입력 오류가 명확하고 필드 수준에 표시됩니다.
- 페이지 매김 제어를 통해 단계 간 이동 가능
- 데이터 제출은 한 번 수행됩니다.
- 작업 및 탐색에 대한 레이블이 명확합니다.
- 버튼 클릭과 같은 사용자 작업을 확인하기 위해 시각적으로 적시에 사용자 의견이 제공됩니다.
- 탐색 버튼(예: "이동", "다음" 및 "뒤로")이 UI 전체에 일관되게 배치됩니다.
앱에서:
- 데이터 입력 필드는 논리적으로 그룹화되지 않으므로 양식을 작성하는 사용자가 광범위한 컨텍스트 전환을 수행해야 합니다.
- 데이터 입력 오류에는 시스템의 내부 작동을 이해하는 사용자만 해석할 수 있는 암호화된 정보가 포함됩니다.
- 양식의 제출 버튼을 클릭하면 데이터 입력 오류만 나타납니다.
- 단계 및 그룹이 명확하게 정의되지 않으므로 탐색이 어렵습니다.
- 데이터 입력 프로세스 전반에 걸쳐 데이터 제출이 여러 번 발생합니다.
- 작업 및 탐색 레이블은 기본 시스템 기능에 익숙하지 않은 사용자에게 혼란스러울 수 있습니다.
- 사용자 작업에 대한 시각적 승인이 제공되지 않습니다.
- 탐색 버튼이 UI 전반에서 임의의 위치에 표시됩니다.
양식 논리:
- 필드가 최대한 미리 채워지거나 자동 완성됩니다.
- 사용자는 장기 실행 서버측 작업이 완료될 때까지 기다릴 필요가 없습니다.
- 사용자 정의 구성 요소는 데이터 작업을 포함하지 않는 서버 기반 작업에 cacheable=true를 사용합니다.
- 데이터 작업은 한 번 수행됩니다.
- LWC @wire 어댑터는 데이터 작업과 관련이 없는 모든 작업을 처리합니다.
양식 논리:
- 미리 채우거나 자동 완성할 수 있는 필드에는 수동 입력이 필요합니다.
- 사용자가 서버측 작업이 완료될 때까지 기다리려면 제출 프로세스 중에 작업을 중지해야 합니다.
- 사용자 정의 구성 요소 세트 cacheable=false
폼 팩터 조직에서:
- Salesforce에서 제공하는 Lightning 페이지 템플릿은 전체 또는 대부분의 페이지에 사용됩니다.
- 사용자 정의 Lightning 페이지 템플릿은 Aura 구성 요소 설계 파일에서 design:supportedFormFactors 및 design:supportedFormFactor를 사용합니다.
- 앱 빌더에서 사용 가능한 사용자 정의 LWC 또는 Aura 구성 요소는 각각의 디자인 파일에서 지원되는 양식 요소를 선언하고 너비 인식 스타일 지정 패턴을 구현합니다.
조직에서:
- Classic은 여전히 활성 상태입니다.
- 사용자 정의 Lightning 페이지 템플릿은 Aura 구성 요소 설계 파일에서 design:supportedFormFactors 및 design:supportedFormFactor를 균일하게 사용하지 않습니다.
- 앱 빌더에서 사용 가능한 사용자 정의 LWC 또는 Aura 구성 요소는 각 디자인 파일에서 지원되는 양식 요소를 일관되게 선언하지 않습니다.
- 사용자 정의 LWC 또는 Aura 구성 요소에서는 Salesforce 제공 인터페이스에서 너비 인식 스타일이 구현되지 않습니다.
- 사용자 지정 LWC 또는 Aura 구성 요소에서 다른 폼 팩터에 대한 스타일링은 CSS의 하드 코딩된 px 또는 % 값에 의해 순전히 구동됩니다.
데스크탑:
- 데이터 입력 필드 및 탐색 컨트롤이 화면에 맞춰 원하는 대로 상호 작용할 수 있습니다.
- 페이지 활성화 할당 규칙에 따라 레코드 및 앱 페이지가 올바르게 표시됩니다.
데스크탑:
- 데이터 입력 필드 및 탐색 컨트롤이 화면의 의도한 위치에 표시되지 않습니다.
- 데이터 입력 필드 및 탐색 컨트롤과의 상호 작용이 필수 동작과 일치하지 않습니다.
- 페이지 활성화 할당 규칙이 없으면 모든 사용자에게 동일한 레코드 및 앱 페이지가 표시됩니다.
모바일 및 태블릿:
- 데이터 입력 및 탐색 컨트롤이 올바르게 표시됩니다.
- 사용자가 쉽게 데이터를 입력할 수 있습니다.
- 소규모 양식 요소에 최적화된 모바일 탐색 메뉴가 나타납니다.
- 축소 레이아웃이 레코드 수준에 표시됩니다.
모바일 및 태블릿:
- 데이터 입력 및 탐색 컨트롤이 일관되거나 올바르게 렌더링되지 않습니다.
- 사용자가 쉽게 데이터를 입력할 수 없음
- 모바일 탐색 메뉴는 데스크톱 탐색과 구분할 수 없습니다.
- 축소 레이아웃이 레코드 수준에서 구성되지 않음
## 유용 유용한 응용 프로그램을 사용하면 사용자가 더 적은 주의를 기울이고 중단을 줄여 권한을 확보하고 효율적으로 작업을 수행할 수 있습니다. 유용한 애플리케이션은 수동 오류를 완화하고 사용자에게 필요한 시점과 장소에 피드백을 제공하여 [데이터 무결성을](/docs/architect/ko-kr/well-architected/guide/automated#데이터-무결성) 유지합니다. 이를 통해 사용자가 현재 및 다음에 집중해야 하는 작업을 이해하고 관련 정보를 제공하여 사용자가 자신의 문제를 더 빠르게 해결할 수 있습니다. 사용자의 작업과 의미 있는 영향 또는 성과 간의 명확한 연결을 제공합니다. 알림 및 메시지, 앱 내 지침, 인식 및 보상과 같은 세 가지 주요 습관을 사용하여 더 유용한 응용 프로그램을 구축할 수 있습니다. ### 알림 및 메시지 알림 및 메시지를 통해 사용자가 계속해서 정보를 파악할 수 있습니다. 올바르게 설계된 알림 및 메시징 시스템은 사용자에게 시기적절한 중요 결정을 내리는 데 필요한 정보를 제공하여 참여 및 생산성을 높일 수 있습니다. 관련성이 없거나 적시에 표시되지 않는 메시지를 표시하는 알림 및 메시징 시스템을 잘못 설계하면 반대의 영향을 미칠 수 있습니다. 내부 사용자는 알림을 빠르게 비활성화하거나 무시하여 필수 비즈니스 프로세스에 영향을 미칠 수 있는 합법적인 메시지를 놓칠 수 있습니다. 무의미한 알림에 지쳐가는 고객 또는 기타 외부 사용자는 시스템 사용을 모두 중지하기로 결정할 수 있습니다. 앱이 사용자에게 알림 및 메시지를 보내는 방법을 결정할 때 다음 사항을 고려하십시오. - **오류의 경우 알림 및 메시지를 마지막 수단으로 사용하십시오**. 백엔드 처리를 사용하여 시스템의 [오류 처리를](/docs/architect/ko-kr/well-architected/guide/automated#오류-처리) 설계하여 인간의 개입 없이 특정 유형의 오류를 수정할 수 있습니다. 사용자에게 과업을 완료하지 못하게 하는 중요 오류에 대한 메시지만 보냅니다. 마찬가지로 비즈니스 사용자가 직접 수행할 수 있거나 수행해야 하는 몇 가지 수정 조치가 있는 경우에만 오류 메시지를 보냅니다. 추가 오류 메시지 또는 세부 사항은 보고서를 통해 제공되거나 추가 팔로우업을 위해 비동기식 메서드를 사용하여 기술 지원 담당자에게 보낼 수 있습니다. - **관련도, 긴급성 및 시기성에 따라 메시지 유형을 선택합니다**. 메시지 유형에 따라 차단 또는 중단 동작의 수준이 다릅니다. 알림은 사용자가 작업을 계속하기 전에 알림을 확인해야 하므로 "차단" 메시지 유형입니다. 오류 메시지와 마찬가지로 알림은 적절하게 사용해야 합니다. 토스트 알림은 [차단되지 않음](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_toast)이며, 다른 지속성 동작을 가질 수 있으며, 다양한 메시지 사용 사례를 지원합니다. 가장 불쾌한 메시지는 [앱 내 알림](https://help.salesforce.com/s/articleView?id=sf.notif_builder.htm&type=5) 또는 이메일입니다. 이를 사용하면 사용자가 언제 어디서나 원하는 대로 처리할 수 있는 정보를 전달할 수 있습니다. - **다음에 무슨 일이 일어날지 생각해보세요**. 일부 알림은 성공 메시지와 같은 정보를 제공하지만, 다른 경우 사용자가 일부 유형의 조치를 취해야 할 수 있습니다. 알림을 설계할 때 알림 자체뿐만 아니라 사용자가 조치를 취해야 할 추가 정보를 고려해야 합니다. 사용자가 추가 정보를 찾거나 실천 가능한 모든 알림에서 팔로우업 단계를 완료할 수 있는 지침 또는 링크를 명확하게 포함합니다. - **읽기**에 초점을 맞춥니다. 각 알림의 목적과 사용자가 응답에 수행해야 하는 다음 단계를 명확하게 전달해야 합니다. 메시지는 기본 시스템의 내부 작업에 익숙하지 않은 비즈니스 사용자가 이해할 수 있어야 합니다. 메시지를 만들 때 해당 메시지가 나타날 수 있는 지역의 사용자를 지원하도록 [접근성 표준을](/docs/architect/ko-kr/well-architected/guide/compliant#접근성) 준수하고 현지화해야 합니다. [설계 표준](/docs/architect/ko-kr/well-architected/guide/intentional#설계-표준)에 알림 또는 다른 유형의 오류를 사용하는 시기에 대한 패턴을 포함하여 앱 빌더가 일관된 관행을 따르도록 돕습니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/engaging#유용한-앱-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 올바른 알림 및 메시징(그리고 나쁜 알림)을 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 사용량을 식별할 수 있습니다. 알림 및 메시징을 위한 Salesforce 도구에 대한 자세한 내용은 참여와 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/engaging#참여와-관련된-도구)를 참조하십시오. ### 앱 내 지침 앱 내 지침은 복잡한 워크플로를 해독하는 강력한 방법이 될 수 있습니다(그러나 먼저 작업 흐름을 [최적화해야 합니다](/docs/architect/ko-kr/well-architected/guide/automated#프로세스-설계)). 자동화되고 확장 가능한 방식으로 프로세스 변경 사항을 도입하고, 새로운 기능을 강조 표시하거나, 교육을 배포하는 것이 좋습니다. 그러나 주의를 기울이지 않으면 앱 내 지침이 과도하게 사용될 수 있습니다. 팝업 또는 경고가 자주 표시되면 사용자에게 엄청난 양의 소음과 중단이 발생하여 생산성이 손실될 수 있습니다. 앱 내 지침도 부족하게 사용될 수 있으므로 릴리스 및 변경 관리 프로세스(특히 간단한 기능)가 더 번거롭습니다. 최종적으로 앱 내 지침을 과도하게 사용하거나 부족하게 사용하면 다음을 포함하여 비즈니스에 위험을 야기하는 여러 문제를 야기합니다. - 데이터 무결성 저하 - 증가된 사용자 오류 - 높은 사용자 불만 수준 및 낮은 사용자 만족도 - 사용자 생산성 저하 사용자의 사고방식에 따라 "너무 많은" 및 "충분하지 않은" 지침의 양이 결정되므로 다양한 시나리오에서 앱 내 지침을 다르게 사용할 수 있습니다. 새 시스템에 처음 도입되는 사용자는 이미 익숙한 시스템의 새로운 기능에 대해 단순히 학습하는 사용자보다 더 자주 메시지를 요구할 수 있습니다. 다음은 효과적인 앱 내 지침을 만드는 몇 가지 키입니다. - **설계 표준 개발** 앱 내 지침에 과도하게 노출되면 사용자가 정기적으로 메시지를 해제하거나 무시할 수 있다는 점에 유의해야 합니다. 이때 앱 내 지침은 자원이 아닌 불만이 됩니다. 프롬프트, 연습, 필드 수준 도움말 텍스트, 유효성 검사 메시지, 경로, 화면 플로 등을 사용하는 시점을 명확하게 설명하기 위해 [설계 기준](/docs/architect/ko-kr/well-architected/guide/intentional#설계-표준)을 정의합니다. - 지침 구현을 위한 **우선 순위 지정 시스템 만들기** 앱 내 지침에 대한 모든 사용 사례를 구현해야 하는 것은 아닙니다. 대신 우선 순위를 지정할 다음 질문을 고려하십시오. 더 나은 필드 이름, 버튼에 더 명확한 레이블, 더 나은 [폼 디자인](/docs/architect/ko-kr/well-architected/guide/engaging#양식) 및 [프로세스 최적화](/docs/architect/ko-kr/well-architected/guide/automated#프로세스-설계)를 간단하게 사용하여 직관적인 워크플로를 만들 수 있는 방법은 무엇입니까? 경로에 더 유용한 텍스트 또는 링크를 추가할 수 있는 곳은 어디입니까? 앱 내 지침이 미치는 [비즈니스 비용 영향](/docs/architect/ko-kr/resources/guide/kpi-spreadsheet-template)은 무엇입니까? 사용자에게 메시지를 얼마나 자주 전달하시겠습니까? 또한 모든 이해당사자가 볼 수 있도록 모든 구현이 [로드맵](/docs/architect/ko-kr/well-architected/guide/intentional#로드맵)에 포함되어 있는지 확인하십시오. - **사용자를 활성(및 제안된) 앱 내 지침에 매핑합니다**. 앱 내 지침에 사용자를 매핑하면 사용자에게 너무 많은 앱 내 지침이 표시되어 "도움말 과부하"를 식별하고 방지할 수 있습니다. 팀이 특정 사용 사례에 대해 너무 좁게 생각하므로 사일로 개발의 결과가 자주 발생합니다. 특히 대규모 조직에서는 사용자가 노출될 항목을 전체적으로 파악하는 것이 매우 중요합니다. 로드맵에 지침 구현을 포함하는 것도 도움이 될 수 있습니다. - **개요를 수집하고 사용하여 개선**합니다. 앱 내 지침 사용에 대한 데이터를 검토하고 이를 사용하여 앱 내 지침 배포의 효율성을 판단합니다. 사용자가 안내 빌더를 돕기 위해 개방형 사용자 의견을 제공할 수 있는 방법도 제공해야 합니다. 아래의 [패턴 및 안 패턴](/docs/architect/ko-kr/well-architected/guide/engaging#유용한-앱-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 올바르고 나쁜 앱 내 지침을 보여줍니다. 이를 사용하여 구축하기 전에 설계를 확인하고 재구성해야 하는 구현을 식별할 수 있습니다. 앱 내 지침을 위한 Salesforce 도구에 대해 자세히 알아보려면 참여와 관련된 [도구를 참조하십시오](/docs/architect/ko-kr/well-architected/guide/engaging#참여와-관련된-도구). ### 인정 및 보상 앱에 인식 및 보상을 구축하면 해당 앱을 사용하는 개인이 작업의 영향에 더 잘 연결되고 기여도, 생산성, 성과의 가치를 더 잘 이해할 수 있습니다. 또한 충성도와 참여를 확보하는 강력한 방법입니다. 인식 또는 보상 앱 환경을 설계하지 않으면 다음을 포함하여 다양한 문제를 야기할 수 있습니다. - 진행 상황 또는 속도를 이해하기 어려운 사용자 - 목표 또는 완료되지 않은 작업에 대한 혼동 - 생산성이 낮은 사용자로서 과업과 "더 큰 상황" 간의 연결이 보이지 않습니다. - 수동, 낮은 수준 목표 보고에 손실된 관리 시간 보상 앱 환경은 회사 문화, 정책, 표준뿐만 아니라 개별 사용자의 컨텍스트 및 기본 설정에 따라 다르므로 설계 및 전달하기가 어렵습니다. 데스크톱 사용자가 즐거움이나 감사의 순간을 느끼도록 도울 수 있는 기능은 모바일 사용자 또는 소음이 많고 바쁜 홈 오피스에서 작업하려는 사용자에게 불쾌해질 수 있습니다. 비공개 또는 민감한 정보로 작업하기 위해 앱을 사용하는 사람은 색종이 축하 또는 배지 형태로 중대 사건에 대한 커뮤니케이션을 평가하지 않을 수 있습니다. 반대로 배포된 세일즈 팀은 이러한 게임화가 적절하게 보상적인 앱 환경으로 보일 수 있습니다. 최종적으로 선택하는 구현 패턴은 팀에서 사용자 환경(UX) 디자이너와 협력하여 결정할 수 있습니다. 아키텍처의 경우 사용자가 인식되고 보상을 받을 수 있도록 앱이 기능을 구현할 수 있는 방법과 위치를 식별하는 것이 중요합니다. 또한 이러한 기능이 어떻게 그리고 어디에서 앱을 더 적게 [재사용 가능하게](/docs/architect/ko-kr/well-architected/guide/composable) 만들거나 [실제 비즈니스 가치를](/docs/architect/ko-kr/well-architected/guide/automated#비즈니스-가치) 제공하지 못하게 할 수 있는지 이해하는 것이 중요합니다. 다음은 Salesforce 앱에서 인식 및 보상을 평가할 때 고려해야 할 몇 가지 질문입니다. - **사용자가 자신의 진행 상황과 전체 팀 통계를 어떻게 어디에서 볼 수 있습니까?** 보고서는 중요하지만 일상적인 작업의 컨텍스트를 놓칠 수 있는 요약 데이터가 포함되는 경우가 많습니다. Lightning 앱 빌더와 같은 도구를 사용하여 앱의 컨텍스트 내에서 레코드 화면에 차트 또는 대시보드를 내장하여 사용자가 일상적인 작업을 수행할 때 영향이나 진행 상황을 이해할 수 있습니다. - **사용자를 어떻게 인식해야 할까요?** 이는 팀 또는 개인 기본 설정에 따라 다를 수 있습니다. 경우에 따라 감독자가 사용자 진행 상황에 대한 메시지를 확인하여 더 큰 그룹과 공유할 수 있습니다. 인식은 직원 윤리에 도움이 되는 추가적인 장점이 될 수도 있습니다. 그리고 다른 경우에는 사용자가 특정 과업 또는 프로젝트의 진행 상황에 대해 알리는 유일한 사용자일 수도 있습니다. 아래의 [패턴 및 반패턴](/docs/architect/ko-kr/well-architected/guide/engaging#유용한-앱-패턴-및-안티-패턴) 목록은 Salesforce 조직에서 올바른 (그리고 부족한) 인식과 보상을 보여줍니다. 이를 사용하여 구축하기 전에 설계를 확인하고 재구성해야 하는 구현을 식별할 수 있습니다. 인정 및 보상을 위한 Salesforce 도구에 대해 자세히 알아보려면 참여와 관련된 [도구](/docs/architect/ko-kr/well-architected/guide/engaging#참여와-관련된-도구)를 참조하십시오. ### 유용한 앱 패턴 및 안티 패턴 다음 표는 조직에서 조회(또는 구축)할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/easy-helpful)에서 유용한 앱에 대한 더 많은 패턴을 확인하십시오.
패턴 안티 패턴
고지 및 메시지 설계 기준에는 다음이 포함됩니다.
- 알림, 토스트 및 알림에 대한 승인된 사용 사례
- 토스트 변형 및 알림에 대한 디자인 패턴
- 오류 메시징을 위한 디자인 패턴
설계 표준이 정의된 경우 오류 및 알림을 해결하지 않습니다.
조직에서:
- 알림이 주된 Messaging 형식입니다.
- 토스트 메시지에서 변형 사용
- 모드가 붙여넣기로 설정된 토스트 메시지가 존재하지 않습니다.
- 통지가 거의 사용되지 않는 경우
- 생성 응답은 항상 사용된 데이터 소스를 식별합니다.
- Bot이 사용자와 처음 상호 작용하기 전에 자신을 명확하게 식별합니다.
- 생성형 AI와 관련된 위험에 대한 고지 사항이 처음 상호 작용하기 전에 사용자에게 표시됩니다.
- 사용자에게 명확하고 이해하기 쉬운 언어로 작성된 AI 고지 사항
조직에서:
- 이메일이 주된 Messaging 형식입니다.
- 메시지 유형에 대한 일관된 접근 방식이 없습니다.
- 토스트 메시지가 변형을 지속적으로 사용하지 않습니다.
- 모드가 티스틱으로 설정된 토스트 메시지
- 경고가 임시로 사용됩니다.
- 생성 응답은 사용된 데이터 소스를 식별하지 않습니다.
- Bot이 사용자와 처음 상호 작용하기 전에 자신을 명확하게 식별하지 못합니다.
- 생성형 AI 위험에 대한 고지 사항이 사용자에게 표시되지 않음
- AI 고지 사항은 사용자에게 명확하고 이해하기 쉬운 언어로 작성되지 않습니다.
앱에서:
- 인적 참여 없이 최종 사용자에게 직접 생성 응답이 전송되지 않습니다.
앱에서:
- 생성 응답은 인적 참여 없이 최종 사용자에게 직접 전송됩니다.
참조: 오류 처리
앱 내 지침 설계 표준 및 문서에는 다음이 포함됩니다.
- 앱 내 지침에 대한 승인된 사용 사례
- 프롬프트 및 연습에 대한 디자인 패턴
- 사용자, 앱, 활성 앱 내 지침의 명확한 매트릭스
설계 표준 및 문서가 있는 경우 다음을 수행합니다.
- 앱 내 지침을 처리하지 마십시오.
- 사용자, 앱, 활성 앱 내 지침을 보여주는 명확한 매트릭스를 포함하지 마십시오.
조직에서:
- "앱 내 지침 간 지연" 설정은 기본값 또는 Salesforce에서 제공하는 기본 기간(24시간)보다 긴 사용자 정의 값을 사용합니다.
- 앱에 활성 연습이 두 개 이상 없는 경우
- 연습에 10보다 큰 "표시할 시간" 설정이 없는 경우
- "모든 페이지, 모든 앱" 또는 "이 페이지, 모든 앱"에 대한 프롬프트가 활성화되지 않습니다.
조직에서:
- "앱 내 지침 간 지연" 설정은 Salesforce에서 제공하는 기본 기간(24시간)보다 짧은 기간으로 설정됩니다.
- 앱에 활성 연습이 두 개 이상 있는 경우
- 많은 연습에는 10보다 큰 "표시할 시간" 설정이 있으며, 일부는 최대 값이 30입니다.
- 프롬프트가 임시로 활성화되며, 다수는 "모든 페이지, 모든 앱" 또는 "이 페이지, 모든 앱" 설정으로 활성화됩니다.
인식 및 보상 조직에서:
- 앱은 내장형 분석을 사용하여 사용자에게 관련 목표 진행 상황 및 생산성 통계를 표시합니다.
- 경로 축하는 사용자 동의가 있는 경우에만 활성화됩니다.
- 알림 및 메시징에는 사용자 인식이 포함되며, 알림을 받는 사람 및 알림 트리거의 설계에 사용자 기본 설정이 반영됩니다.
조직에서:
- 목표 진행률 및 생산성 통계와 관련된 분석은 보고서 또는 관리자 대시보드에서만 사용할 수 있습니다.
- 사용자 동의를 확인하지 않고 경로 축하가 활성화됩니다.
- 알림 및 메시징에는 사용자 인식이 포함되어 있지 않거나 사용자의 기본 설정을 반영하지 않으며 소음이나 웃음이 느껴지지 않습니다.
## 참여와 관련된 도구
도구설명간소화됨유용
Lightning 앱 페이지 활성화페이지 가용성, 명명, 가시성 및 위치 관리X
채택 대시보드로그인 내역, 기능 채택, 생산성 검토XX
경고세션에 대한 알림 유지 및 사용자 시작 없이 표시X
Apex 메서드 결과의 클라이언트측 캐싱캐시된 클라이언트측 데이터로 성능 평가X
동적 형태사용자에게 필수 필드 및 페이지 섹션만 표시X
참여 인사이트최근 사용자 활동 모니터링 및 필요에 따라 조치 수행XX
앱 내 지침 교육 및 온보딩에 프롬프트 및 연습 활용X
학습 경로사용자 학습 환경 개인 설정X
Lightning 앱 빌더코드 없이 사용자 지정 모바일 및 Lightning 페이지 만들기X
Lightning 데이터 서비스구성 요소 간 데이터 캐시 및 공유X
Lightning Design System Validator for VS CodeSLDS 지침에 대한 마크업 검증XX
Lightning 페이지 템플릿다양한 양식 요소에 대한 Lightning 페이지 구축X
검색 필터조회, 마스터-세부 사항, 계층 관계에 대한 필터 값X
다중 통화 관리트랜잭션에 복수 통화 사용X
메시징 SMS, Facebook Messenger 또는 WhatsApp 메시지 보내기X
Mobile PublisherLightning 앱 및 Experience Cloud 사이트의 모바일 버전 만들기X
모바일 구성 요소모바일 환경에서 제대로 작동하는 구성 요소 구축X
다국어 사이트사이트의 다른 언어 버전 만들기XX
알림 빌더정보를 표시할 사용자 정의 알림 만들기X
경로사용자에게 비즈니스 프로세스를 안내하고 성공을 축하XX
플랫폼 캐시데이터 캐싱 시 성능 및 신뢰도 향상X
Lightning 앱 빌더에서 모바일 앱 페이지 미리 보기모바일 장치에서 레코드 및 앱 페이지 미리 보기X
Prompt사용자에게 시스템 관련 문제 및 업데이트 알림X
인식 배지사용자 성과 확인 및 축하X
WDC 인식기술 추천 및 감사 인사X
레코드 유형비즈니스 프로세스, 선택 목록 값, 페이지 레이아웃 개인 설정XX
평판 개요참여 및 Knowledge 공유 인식X
제한 규칙사용자가 불필요한 데이터를 포함할 수 있는 레코드에 액세스하지 못하도록 방지X
표준 페이지 구성 요소표준 Salesforce Lightning 구성 요소 이해X
번역글로벌 사용자에 대한 번역 관리XX
확인 규칙저장하기 전에 데이터가 지정된 표준을 충족하는지 확인X
## 참여와 관련된 자원
자원설명간소화됨유용
건물 양식의 건축가 가이드양식 설계 고려 사항을 평가하고 최상의 도구를 선택합니다.X
다양한 폼 팩터에 맞게 구성 요소 구성데스크톱 및 휴대폰에서 렌더링할 구성 요소 구성X
사용자 정의 도움말 콘텐츠고유한 구현에 맞게 도움말 콘텐츠 조정 X
기본 필드 값기본, 동적 또는 정적 필드 값 정의X
설계 지침모범 사례에 따라 사용자 인터페이스 만들기XX
설계 표준 템플릿조직에 대한 설계 표준 만들기XX
설계 테스트 기술 (Trailhead)설계 유효성 검사 및 테스트 방법 계획XX
앱 내 피드백 지침시스템 내에서 사용자 의견 수집 지침 검토XX
Lightning Design System Android 정적 라이브러리Lightning 페이지의 모양과 느낌으로 네이티브 Android 앱 구축X
Lightning Design System iOS 정적 라이브러리Lightning 페이지의 모양과 느낌으로 네이티브 iOS 앱 구축X
Messaging 지침관련 정보를 전달하고 기쁨의 순간을 만듭니다.X
Messaging 유형사용자 상호 작용을 기반으로 다양한 Messaging 유형 이해X
탐색 지침사용자가 페이지 간에 이동하고 앱에서 자신을 찾을 수 있도록 지원X
웹 접근성 테스트(Trailhead)자동 및 수동 테스트를 활용하여 접근성 보장XX
사용자 참여 지침온보딩, 채택, 지원, 학습 지침 검토XX
## 의견을 알려주십시오. Salesforce Well-Architected의 관련성을 유지할 수 있도록 도와주십시오. 이 콘텐츠에 대한 사용자 의견을 제공하려면 [ 설문 조사](https://sfdc.co/bxNtvh)을 작성하고 다음에 원하는 내용을 알려주십시오. > [여기에](/docs/architect/ko-kr/well-architected/guide/contributors) 업데이트 일정에 대해 알아보십시오. 법적 고지 사항: 이 문서는 정보용으로만 배포되며 법적 조언이 아니며 이를 사용해서는 안 됩니다. ## 소개 규정 준수 시스템은 적용 가능한 법적 및 윤리적 지침을 준수하도록 설계되었으며, 규정 준수는 측정 가능하고 감사할 수 있습니다. 이는 의도한 목적을 위해 권한이 있는 개인에게 데이터 액세스를 제한하고 관련 법적 규정을 준수하며 모든 권한이 있는 사용자에게 공정한 액세스를 보장함으로써 증명됩니다. 사전 예방적 조치는 규정 준수 위반을 방지하고 감지하는 데 필요합니다. 규정 및 표준에 대한 반응형 접근 방식은 특히 고객 요청 또는 불만 사항에 대한 대응으로만 변경되는 경우 고객의 Trust 잃을 수 있습니다. 이러한 컴플레인은 조직의 브랜드 및 평판에 손상을 줄일 수 있으며 매출 손실을 야기할 수 있습니다. 법적 준수, 윤리적 표준, 접근성과 같은 세 가지 핵심 습관에 집중하여 Salesforce 솔루션에서 규정 준수를 구축할 수 있습니다. ## 법적 준수 법적 의무를 준수하려면 지역 법률 및 업계 규정을 준수해야 합니다. 설계자로서 조직의 법률 팀 또는 타사 감사자가 특정 규정 준수 요구 사항을 결정하면 해당 요구 사항을 이해하고 설계 프로세스 초기에 잠재적인 규정 준수 문제를 사전에 식별하고 플래그를 지정하여 벌금 및 소송 위험을 줄일 책임이 있습니다. 데이터 프라이버시 및 현지화를 통해 Salesforce 솔루션의 법적 준수를 향상할 수 있습니다. ### 데이터 프라이버시 데이터 프라이버시는 솔루션이 관련 규정 및 개인 데이터에 대한 액세스를 제어하는 개인의 능력과 함께 개인 식별 정보(PII)를 수집, 저장, 처리하는 방법을 다룹니다. 이러한 규정을 준수하려면 고객의 [공유 및 가시성 모델](/docs/architect/ko-kr/well-architected/guide/secure#공유-및-가시성)을 업데이트하고, 메타데이터 구성을 수정하여 액세스를 제한하고, 필드 수준 암호화를 구현하고, 로그 및 이벤트를 모니터링하고, 요청 시 고객의 데이터를 내보내거나 삭제하는 자동화를 생성하고, 자동화 및 AI에서 데이터 사용을 규제하는 정책을 개발해야 할 수 있습니다. 데이터 프라이버시 규정을 준수하지 않으면 상당한 벌금 및 소송이 발생할 수 있습니다. 또한 관리 수준이 낮거나 보안 위반으로 인해 이해당사자 데이터가 노출되면 매출이 손실되고 고객 Trust 손상될 수 있습니다. 데이터 프라이버시 요구 사항을 준수하기 위해 작업할 때 다음 사항을 고려하십시오. - **규제 전문가 상담** 법무팀 또는 타사 감사자와 협력하여 비즈니스에 적용되는 산업별 규정 준수 규정을 평가합니다. 예를 들어 헬스케어 회사는 HIPAA(Health Insurance Portability and Responsibility Act)를 준수해야 합니다. - **데이터 분류** 데이터 분류는 프로젝트 팀이 조직의 다양한 데이터 요소가 사용되거나 사용되지 않을 경우를 이해하는 데 도움이 됩니다. 또한 비즈니스에서 데이터 관리 정책 준수 여부를 [보고](https://help.salesforce.com/s/articleView?id=sf.data_classification_report.htm&type=5)할 수 있습니다. [필드 수준에서](https://help.salesforce.com/s/articleView?id=sf.data_classification_intro.htm&type=5) 해당 규정을 지정하여 담당자, 민감도 수준, 현재 사용 중인지 여부를 수집하여 조직의 데이터를 분류합니다. 분류 프로세스 동안 데이터 모델의 모든 필드가 처음부터 민감한 것으로 보이는 필드뿐만 아니라 어떻게 사용될지 생각하는 것이 중요합니다. 잘못된 컨텍스트 내에서 사용되는 경우 무관하게 보이는 필드가 민감해질 수 있습니다. 예를 들어 미국의 우편 번호는 인종을 프록시할 수 있으므로 예측 모드에서 사용할 경우 의도치 않게 편향을 추가하거나 해를 유발할 수 있습니다. 일반적인 이름은 세대마다 변경되는 경향이 있으므로 이름을 사용하여 성별, 출신 국가, 인종, 종교, 연령을 예측할 수 있습니다. 문서에 모든 필드의 분류와 관련 AI 기능이 사용하는 방법에 대한 명확한 설명을 포함합니다. [데이터 감지](https://help.salesforce.com/s/articleView?id=sf.einstein_data_detect.htm&type=5)와 같은 도구를 사용하여 조직 내에서 중요한 데이터를 식별합니다. 필드가 민감한 필드로 분류되거나 민감한 필드를 알고 있는 경우 Einstein Content Selection과 같은 도구는 [높은 상관 관계](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.mc_pb_manage_einstein_content_selection_attributes_and_bias.htm)가 있는 필드를 식별할 수 있으므로 민감한 필드에 대한 프록시가 될 수 있습니다. - **데이터 거버넌스에 대한 모범 사례 수립** 모든 이해당사자가 쉽게 사용할 수 있도록 모든 관련 문서가 완전하고 최신이며 중앙에 저장되어 있는지 확인하십시오. 이를 통해 법적 책임으로부터 조직을 보호하고 고객 및 파트너와의 Trust 유지할 수 있습니다. 예를 들어, 데이터 사전은 시스템에 저장될 모든 데이터 요소에 대한 개체 및 필드 수준 정의와 분류를 문서화하고, 설계 문서에 규정을 준수하기 위해 생성한 자동화에 대한 세부 사항이 포함되며, 보안 매트릭스는 사용자에게 액세스 권한이 있는 데이터를 간략하게 보여줍니다. 중요한 점은 이 포괄적인 문서가 검색 증강 생성(RAG)에 대한 권위 있는 소스로 만들어 Agentforce 같은 에이전트 시스템을 확인되고 규정을 준수하는 운영 컨텍스트에서 직접 기반으로 하여 불일치 또는 환각 출력을 방지합니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/compliant#법적-준수-패턴-및-안티-패턴) 목록은 Salesforce 솔루션 내에서 올바르고 나쁜 데이터 프라이버시 관리를 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 리팩터링해야 하는 시스템 영역을 식별할 수 있습니다. 데이터 프라이버시를 위한 Salesforce 도구에 대해 자세히 알아보려면 [규정 준수 관련 도구](/docs/architect/ko-kr/well-architected/guide/compliant#준수와-관련된-도구)를 참조하십시오. ### 현지화 현지화는 특정 언어, 문화, 원하는 현지 미학에 맞게 제품을 조정하는 것입니다. 또한 국가 및 시/군/구에 상당히 다를 수 있는 데이터 보존 법률 등 지역별 규정에 적응할 수도 있습니다. 따라서 고객의 위치 및 비즈니스에서 제품 및 서비스를 시장에 도입하는 방법에 따라 시스템이 여러 규제 프레임워크를 충족해야 할 수 있습니다. 많은 국가에서 데이터 보호법의 변형 외에도 데이터 보존법도 도입하고 있습니다. 최소한 데이터 보존 법에 따라 국가의 시민과 관련된 모든 데이터가 해당 국가의 경계 내에 물리적으로 저장되어야 합니다. 일부 법에서는 시민이 잠재적으로 액세스할 수 있는 모든 데이터(제품 및 서비스에 대한 데이터 포함)를 로컬로 저장해야 합니다. 특정 사례에서 규정에 따라 해당 국가 또는 지역의 다른 시민만 시민 데이터를 유지해야 합니다. 규정을 준수하지 않으면 큰 벌금과 소송이 발생할 수 있습니다. 예를 들어, EU의 데이터 보호 기관은 최대 2천만 유로 또는 전 세계 매출의 4%까지의 벌금을 부과할 수 있습니다. 미국에서는 캘리포니아 총검사에서 의도적 위반과 의도하지 않은 위반 모두에 대해 심각한 처벌을 요구할 수 있습니다. 현지화 및 데이터 보존 요구 사항을 효과적으로 관리하려면 다음을 고려하십시오. - **규제 전문가 상담** 법무팀 또는 타사 감사자와 협력하여 비즈니스가 운영되는 지역의 법률을 평가하여 해당하는 법률을 결정합니다. 예로는 EU의 GDPR(일반 데이터 보호 규정) 및 EU AI Act, 캘리포니아 소비자 정보보호법(California Consumer Privacy Act, CCPA)이 있습니다. - **데이터를 로컬로 저장**합니다. 지역에 고유한 데이터가 자체 별도의 조직에 남아 있는지 확인합니다. Salesforce의 공개 클라우드 기반인 [Hyperforce](https://help.salesforce.com/s/articleView?id=000356459&type=1)를 사용하여 특정 지역에서 조직을 호스팅합니다. - **데이터 복제를 피하십시오**. 로컬 데이터 저장소는 데이터가 국가에 저장된 _상태를_ 의미합니다. 물론 표준 인터페이스를 통해 데이터가 국가 외부로 전송될 때 규정 준수 문제가 발생할 수 있습니다. 예를 들어 로컬에서 레코드를 만들고 유지하지만 보고를 위해 다른 국가의 데이터 웨어하우스에 복제하면 데이터 보존 법을 위반합니다. 지역 간 보고 요구 사항이 있는 글로벌 비즈니스에서 작업하는 경우 먼저 데이터가 저장된 국가 내에서 데이터를 집계하고 잠재적으로 관련 시민을 식별할 수 있는 모든 정보를 제거한 다음, 집계된 정보만 복제합니다. 이 접근 방식을 통해 이해당사자에게 보다 세분화된 데이터를 국가 또는 지역 수준에서 사용할 수 있지만, 요약 데이터만 전 세계에서 사용할 수 있음을 알 수 있도록 보고 제한 사항을 전달해야 할 수 있습니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/compliant#법적-준수-패턴-및-안티-패턴) 목록은 Salesforce 솔루션 내에서 올바른(그리고 나쁜) 현지화 및 데이터 보존 프로세스가 어떻게 보이는지 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 구역을 식별합니다. 현지화를 위한 Salesforce 도구에 대해 자세히 알아보려면 [규정 준수 관련 도구](/docs/architect/ko-kr/well-architected/guide/compliant#준수와-관련된-도구)를 참조하십시오. ### 법적 준수 패턴 및 안티 패턴 다음 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/trusted-legal-adherence)에서 법적 준수에 대한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
데이터 개인 정보 보호 문서:
- 필드 수준 이름, 설명, 분류가 포함된 최신 데이터 사전이 있습니다.
- 특정 데이터에 액세스할 수 있는 사용자를 식별하는 최신 보안 매트릭스가 있습니다.
- 규제 요구 사항을 해결하기 위해 생성된 자동화에 대한 표준 및 다이어그램을 비롯한 최신 설계 문서가 있습니다.
문서:
- 데이터 사전이 없거나 최신 상태로 유지되지 않았습니다.
- 공유 및 가시성 문서가 없거나 최신 상태로 유지되지 않았습니다.
- 규제 요구 사항을 해결하는 자동화용 설계 표준, 다이어그램 및 문서가 없거나 최신 상태로 유지되지 않았습니다.
조직에서:
- 중요한 정보가 포함되어 있거나 데이터 프라이버시 규정에 적용되는 모든 개체 및 필드에 규정 준수 범주, 데이터 소유자, 데이터 민감도 수준, 필드 사용이 구성되어 있습니다.
조직에서:
- 중요한 정보가 포함되어 있거나 데이터 프라이버시 규정이 적용되는 개체 및 필드에 규정 준수 범주, 데이터 소유자, 데이터 민감도 수준 또는 필드 사용에 대한 구성이 누락됨
현지화 문서:
- 모든 해당 데이터 보존 요구 사항을 준수하기 위해 데이터가 저장 및 유지되는 위치를 간략하게 설명하는 조직 전략이 있습니다.
- 국경 전반에서 데이터 복제를 위한 허용 가능한 시나리오 및 프로세스를 간략하게 설명하는 통합 전략이 있습니다.
- 지역, 국가, 글로벌 수준에서 포함할 수 있는 보고서 및 대시보드의 세분화 수준을 간략하게 보여주는 분석 전략이 있습니다.
문서:
- 조직 전략이 없거나 조직 전략이 데이터 현지화 및 보존 요구 사항을 해결하지 않는 경우
- 통합 전략이 없거나 통합 전략이 데이터 현지화 및 보존 요구 사항을 해결하지 않는 경우
- 분석 전략이 없거나 분석 전략이 데이터 현지화 및 보존 요구 사항을 해결하지 않는 경우
## 윤리적 표준 비즈니스 컨텍스트에서 윤리적 표준은 기업과 개인이 가치 기반 또는 윤리적 관점에서 자신을 행동하는 방법에 대한 지침입니다. Salesforce에서는 회사와 직원으로서 하는 모든 일에 [우리의 핵심 가치](https://trailhead.salesforce.com/content/learn/modules/salesforce-culture-and-values/explore-salesforce-culture-and-values)이 주도됩니다. 또한 고객이 윤리적으로 소프트웨어를 사용하는 것을 보장하는 [ 윤리적 사용 정책](https://www.salesforce.com/company/intentional-innovation/ethical-use-policy/) 팀이 있습니다. 우리의 [수용 가능한 사용 정책(AUP)](https://sfdc.co/AUP) 및 [AI 수용 가능한 사용 정책(AI AUP)](http://sfdc.co/AI-Policy)은 우리의 핵심 가치의 연장이며, 사용과 관련된 질문이 발생할 경우 의사 결정을 안내하는 데 도움이 됩니다. 조직에 현지 규정을 준수하는 것 이상으로 확장되는 추가 정책 집합이 있을 수 있습니다. 이러한 정책은 다른 지역의 규정을 준수하거나 특정 조직 또는 시장과 비즈니스를 거부하거나 직원-고객 상호 작용을 모니터링하여 차별 또는 편향된 행동을 방지하는 등 다양한 형태를 취할 수 있습니다. 이러한 정책을 준수하려면 설계 표준 또는 시스템 구성과 마찬가지로 [법적 준수를 위해](/docs/architect/ko-kr/well-architected/guide/compliant#법적-준수) 업데이트해야 할 수 있습니다. Salesforce 솔루션에서 윤리 표준을 더 잘 준수하려면 회사 정책에 부합하고 인공 지능 사용을 평가합니다. ### 회사 정책 회사 정책은 사람, 프로세스, 기술 등 다양한 비즈니스 측면이 작동하는 방식을 정의하는 지침입니다. 고객은 Trust 조직과 비즈니스를 하는 것을 선호합니다. 대부분의 회사 정책은 이 원칙을 반영하도록 설계되었습니다. 시스템에서 명시된 정책과 일치하지 않는 사용자 환경을 만들면 고객 Trust 빠르게 손상됩니다. 효과적인 정책은 자연스럽게 [ 윤리 문화](https://www.salesforce.com/blog/new-research-ethical-leadership-business/)에서 유발됩니다. 엔지니어링 및 설계에서 데이터 과학, 마케팅, 세일즈에 이르기까지 모든 직원은 윤리적 사용에 대한 책임에 대해 교육을 받아야 합니다. 이러한 문화에서 직원은 윤리적 행동에 대한 보상을 제공하는 명확한 인센티브 구조와 비윤리적 행동에 대한 명확하고 일관된 결과를 볼 수 있습니다. 조직의 정책이 설계에 반영되도록 다음 사항을 고려하십시오. - **비정상적인 결과를 알고 있어요** 설계자는 솔루션의 잠재적인 영향 및 사용 방법을 예측할 책임이 있습니다. 행복한 경로만 고려하거나 테스트하는 것에 빠지지 마십시오. 대신 에지 사례 테스트 및 제약 평가에 대한 전문 지식을 적용하여 솔루션의 윤리적 영향을 철저하게 고려하십시오. 제품에 영향을 받을 모든 사람을 생각해 보십시오(특히 부재중, 소수점 또는 취약한 사람). 누군가 또는 누군가가 솔루션과 상호 작용하여 의도하지 않은 결과를 유발할 수 있는 다양한 방법을 평가합니다. [구축 의도 툴킷](http://sfdc.co/BuildwithIntention)을 사용하여 포괄성을 염두에 두고 디자인합니다. - **회사의 허용 가능한 사용 정책에 윤리를 포함시킵니다**. 법무팀 또는 타사와 협력하여 허용 가능한 사용 정책에 윤리를 포함하여 솔루션 사용이 회사의 가치와 일치하는지 확인합니다. 문서에 하위 코드 또는 프로 코드 도구로 개발되었는지 여부와 상관없이 솔루션에서 지원되는 조직의 값 및 정책에 대한 정보가 포함되어야 합니다. 허용 가능한 사용 정책을 게시하여 직원 및 고객과의 Trust 구축에 대한 약속을 표시합니다. - **포괄적인 언어를 사용하십시오**. 사용자가 솔루션을 경험하는 다양한 방법을 이해하고 사용자 인터페이스, 코드 및 문서의 [언어를 정밀하게 정의하여 포함성을 더욱 정확하게 반영합니다](https://www.salesforce.com/news/stories/salesforce-updates-technical-language-in-ongoing-effort-to-address-implicit-bias/). 먼저 고유 언어를 식별하고 제거한 다음, 제외로 이어질 수 있는 습관 또는 관행 유형을 이해하도록 노력합니다. 아래의 [모형 및 비모형](/docs/architect/ko-kr/well-architected/guide/compliant#윤리적-표준-패턴-및-안티-패턴) 목록은 Salesforce 솔루션 내에서 회사 정책에 대한 적절한 (그리고 부적절한) 준수가 어떻게 보이는지 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재연산해야 하는 시스템 영역을 식별합니다. 설계와 회사 정책을 조율하는 Salesforce 도구에 대해 자세히 알아보려면 규정 준수에 대한 [도구를 참조하십시오](/docs/architect/ko-kr/well-architected/guide/compliant#준수와-관련된-도구). ### 인공 지능 인공 지능은 계산 시스템을 사용하여 일반적으로 인공 지능이 필요한 과업(예: 추론, 인식, 의사 결정)을 수행합니다. Salesforce Platform AI 기능은 예측, 생성, 에이전트 기술을 포괄하여 고객 경험 및 비즈니스 운영을 향상할 수 있는 포괄적인 도구 모음을 제공합니다. - **예측 AI는** 과거 데이터를 분석하고 판매 추세 또는 고객 이탈과 같은 향후 결과를 예측합니다. Einstein AI는 데이터의 패턴을 분석하여 권장 사항을 제공하고 비즈니스 결과를 예측하여 이러한 인사이트를 제공합니다. - **Generative AI는** 대규모 언어 모델을 활용하여 새로운 콘텐츠를 만드는 데 초점을 맞춥니다. Einstein GPT는 CRM 데이터와 함께 작동하여 이메일, 채팅 응답 및 고객 커뮤니케이션과 같은 맞춤형 콘텐츠를 생성하는 핵심 구성 요소입니다. - **에이전트 AI는** 에이전트가 특정 목표를 달성하기 위해 자율적으로 추론하고 조치를 취할 수 있도록 지원함으로써 AI를 한 단계 더 발전시킵니다. Agentforce 고객 사례 해결 또는 마케팅 캠페인 최적화와 같은 복잡한 비즈니스 프로세스를 자동화할 수 있는 해당 지능형 에이전트를 구축하는 플랫폼입니다. 해당 에이전트는 Data 360을 통해 데이터와 실시간으로 상호 작용하고 기존 워크플로 및 API를 활용할 수 있습니다. 이러한 모든 AI 기능은 Einstein Trust Layer로 보호되며, 이는 윤리적인 사용을 보장합니다. 대부분의 Einstein AI의 핵심 알고리즘은 구성할 수 없지만, 일부 기능의 경우 문서에 명시된 바와 같이 고객이 자신의 데이터를 사용하여 모델을 미세 조정할 수 있습니다. 또한 RAG(Retrieval Augmented Grounding)를 통해 자체 CRM, Knowledge 자료 기사 및 기타 문서에 AI 모델을 기반으로 출력을 더욱 정확하게 만들 수 있습니다. 그러나 기본 데이터가 편향되거나 왜곡된 경우 출력이 편향되고 정확하지 않을 수도 있습니다. 편향의 예는 고객 기반이 다양하고 해당 그룹의 구성원이 포함되어 있어도 특정 인종, 성별 또는 민족의 구성원을 연락처 목록에 포함하지 않는 것입니다. 자세한 내용은 Salesforce [Responsible Creation of AI Trailhead 모듈](https://trailhead.salesforce.com/en/content/learn/modules/responsible-creation-of-artificial-intelligence), [Understanding Trusted Agentic AI Trailhead](https://trailhead.salesforce.com/content/learn/modules/trusted-agentic-ai), [AI Ethics Maturity Model](https://www.salesforceairesearch.com/static/ethics/EthicalAIMaturityModel.pdf), Salesforce의 [신뢰할 수 있는 AI 원칙](https://www.salesforceairesearch.com/trusted-ai), [Responsible Generative AI 가이드라인](https://www.salesforce.com/news/stories/generative-ai-guidelines/), [Responsible Agent AI 가이드라인](https://www.salesforce.com/news/stories/responsible-agentic-ai-guidelines/)을 참조하십시오. 해당 법적 규정 및 회사의 윤리적 기준을 고려하지 않으면 AI 내부의 편향으로 인해 소송, 수익 손실, 고객 Trust 문제 및 회사의 공공 이미지를 손상시킬 수 있습니다. 책임 있고 윤리적으로 AI를 사용하기 위해 고려해야 할 사항은 다음과 같습니다. - **데이터 세트 및 문서 검토** 데이터 집합이 AI 기능이 영향을 미치는 모든 사람을 나타내는지 확인합니다. 그러면 사용자가 누구인지 이해하고 데이터가 잠재적인 편향을 완화하기 위해 모두를 정확하게 나타내는지 확인하기 위해 사용자 연구가 필요할 수 있습니다. 또한 CRM 데이터, Knowledge 기사 및 모델을 기반으로 하는 다른 문서를 검토하여 최신, 정확하고 완전한지 확인하는 것이 중요합니다. 많은 데이터로 모델을 기초 교육하는 것은 도움이 되지 않으며, 해당 데이터가 오래되거나 상충되거나 불완전한 경우 환각이 발생할 수 있습니다. - **[사람을 지휘대에 두세요](https://www.salesforce.com/news/stories/human-at-the-helm/)**. 인간이 모든 개별 AI 상호 작용에 개입하지 않기를 원하지만 직원이 주의를 기울여야 하는 심사적인 항목에 집중할 수 있도록 지원합니다. AI 시스템이 더 많은 책임을 맡고 결과를 모니터링하여 계속 정확하고 효과적으로 작동하는지 확신할 때까지 AI 시스템을 테스트합니다. 또한 AI 시스템 또는 에이전트에게 고위험 사용 사례 및 AI의 신뢰 수준이 낮은 경우 사람에게 에스컬레이션하도록 지시해야 합니다. - 모델 출력 및 결과의 안전성을 **우선 순위로 지정하십시오**. 편향, 설명 가능성, 견고성 [평가](https://www.salesforce.com/news/stories/developing-ethical-ai/) 및 [ 윤리적 팀 구성](https://www.salesforce.com/blog/red-teaming-ai/) 수행 교육에 사용된 데이터에 있는 개인 식별 정보(PII)에 대한 에이전트 응답 및 조치를 통해 개인정보 보호에 우선 순위를 지정하고 추가적인 손상을 방지하기 위해 가드 레일을 만듭니다. 테스트 시 유해한 결과가 발견될 경우 시스템 프롬프트에 지침을 추가하고 다시 테스트합니다. 검색 증가 생성(RAG)에 사용하는 데이터의 품질 또는 대표성을 개선해야 할 수도 있습니다. - **규정에 대비하십시오**. AI에 대한 윤리적 우려 외에도 많은 정부가 관할 지역 내에서 운영되는 조직에서 AI 사용을 규제하기 위한 법을 통과했거나 통과하고 있습니다. 이 법에 AI 솔루션이 생성되고 작동하는 방식을 설명하는 모델 카드를 게시하는 요구 사항이 포함될 수 있습니다. 인공 지능 기반 솔루션을 구현하기 전에 시스템이 사용될 지역에서 허용되거나 허용되지 않는 AI 관련 기능 유형을 파악하고 전략에 필요한 조정을 수행하십시오. 일부 지역에서 현지 규정을 준수하기 위해 특정 기능을 비활성화해야 할 수 있습니다. 이러한 경우 시스템이 해당 기능 없이 계속 작동할 수 있는지 확인하십시오. 많은 관할 지역에서 고객 또는 최종 사용자가 AI 시스템과 상호 작용할 때 투명성이 필요합니다. - **조직의 AI 모델 모니터링** 영향을 받는 사용자는 AI가 사용된 시점을 알고 손상을 쉽게 보고하고 조치를 요청할 수 있는 기회를 확보해야 합니다. 보고만으로 인해 AI 기능이 사용자에게 손상을 미치는지 여부를 판단하는 데 충분하지 않을 수 있다는 점에 유의해야 합니다. 데이터 드리프트, 공정성/차이스 점수, 정확성, 견고도 변화에 대해 모델을 지속적으로 모니터링합니다. [품질 경고를 처리할 계획](https://help.salesforce.com/s/articleView?id=sf.bi_edd_quality_alert.htm&type=5)이 있고 부정적인 영향이 식별되면 신속하게 대처해야 합니다. 아래의 [모형 및 안티모형](/docs/architect/ko-kr/well-architected/guide/compliant#윤리적-표준-패턴-및-안티-패턴) 목록은 Salesforce 솔루션 내에서 올바르고 나쁜 AI 설계를 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 리팩터링해야 하는 시스템 영역을 식별할 수 있습니다. 보다 윤리적인 AI 정책을 구현하기 위한 Salesforce 도구에 대해 자세히 알아보려면 준수에 대한 [도구를 참조하십시오](/docs/architect/ko-kr/well-architected/guide/compliant#준수와-관련된-도구). ### 윤리적 표준 패턴 및 안티 패턴 다음 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/trusted-ethical-standards)에서 윤리 표준에 대한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
회사 정책 설계 기준:
- 표준에는 회사 정책에 영향을 받는 영역에 대한 명확한 지침이 포함되어 있습니다.
설계 기준:
- 설계 표준이 없거나 회사 정책이 적용되는 영역에 대한 명확한 지침을 제공하지 않습니다.
문서:
- 구성 및 사용자 정의 문서에 지원되는 회사 값에 대한 참조가 포함되어 있습니다.
문서:
- 구성 및 사용자 정의 문서는 회사 값 또는 정책을 참조하지 않습니다.
조직에서:
- 회사 정책 관련 규정 준수에 적용되는 모든 개체 및 필드에 규정 준수 분류, 데이터 소유자, 데이터 민감도 수준, 필드 사용이 구성되어 있습니다.
조직에서:
- 규정 준수 분류, 데이터 소유자, 데이터 민감도 수준 또는 필드 사용에 대한 구성이 누락된 개체 및 회사 정책 관련 규정 준수에 적용되는 개체
인공 지능 설계 기준:
- AI 응용 프로그램에 대한 정책 및 승인된 사용 사례를 명확하고 쉽게 찾을 수 있습니다.
- RAG에 사용되는 데이터 및 문서가 대표적이고 완전하며 정확하며 최신 상태인지 확인합니다. 데이터 집합 또는 문서에 존재할 수 있는 편향, 독성, 기타 유해 콘텐츠 찾기
- 생성 응답은 항상 AI 모델에서 사용되는 데이터 소스를 식별합니다.
- 프롬프트 엔지니어링에 사용할 수 있거나 사용할 수 없는 데이터 집합이 문서화되었습니다.
- Bot 및 생성형 AI 응답이 사용자에게 명확하게 식별됩니다.
- 생성형 AI에 대한 고지 사항을 사용하는 시기 및 방법에 대한 표준이 명확하게 정의되어 있습니다.
- AI 솔루션 설계에 대한 인적 참여 지점을 문서화하는 방법에 대한 명확한 요구 사항이 있습니다.
- AI 솔루션 설계에서 직접 및 간접 피드백 경로를 문서화하기 위한 표준이 있습니다.
- 사용자에 대해 AI를 식별해야 하는 지점이 명확하게 정의됩니다.
- 특히 규제 또는 높은 위험 사용 사례에서 사람을 대동으로 유지
설계 기준:
- 설계 표준이 없거나 AI 응용 프로그램에 대한 명확한 정책 및 승인된 사용 사례가 포함되어 있지 않습니다.
- 생성 응답은 AI 모델에 사용된 데이터 소스를 식별하지 않습니다.
- 프롬프트 엔지니어링에 사용되는 데이터 집합은 문서화되지 않습니다.
- Bot 및 생성형 AI 응답이 사용자에게 식별되지 않습니다.
- 생성 응답에 대한 고지 사항이 누락되었습니다.
- AI 솔루션 설계에 대한 인적 참여 지점을 문서화하기 위한 요구 사항이 없습니다.
- AI 솔루션 설계에 대한 직접 및 간접 피드백 경로를 문서화하기 위한 표준이 없습니다.
- 설계 표준이 사용자에게 AI를 식별해야 하는 지점을 나타내지 못함
문서:
- AI 기능과 관련된 구성 및 사용자 정의 문서에 모든 프로세스 논리에 대한 철저한 설명이 포함되어 있으며 법률 팀 또는 감사자가 액세스할 수 있는 중앙 위치에 저장됩니다.
- Salesforce에 구축하거나 가져온 모델은 해당하는 데이터 세그먼트를 포함하여 명확하게 문서화되어 있습니다.
- 대화 논리 및 에이전트 대화가 철저하게 문서화됩니다.
- 데이터 드리프트, 공정성 및 편향 점수, 정확도, 견고성 변화에 대해 조직의 AI 모델을 모니터링하는 프로세스가 있습니다.
- 모든 AI 프로세스에 사용되는 교육, 평가, 테스트 데이터에 대한 설명이 유지됩니다.
- 편향 테스트, 관련 결과, 성능/정확도 점수(예: F1 점수)와 함께 모든 AI 관련 데이터 정리에 대한 설명이 유지됩니다.
문서:
- AI 기능과 관련된 구성 및 사용자 정의 문서가 누락되었거나 완료되지 않았거나 액세스할 수 없는 위치에 저장되었습니다.
- 모델의 문서화 없이 조직에 AI 모델 또는 시스템이 구현됨
- 메시지 및 대화 플로 문서화 없이 조직에 에이전트가 구현됩니다.
- AI 모니터링 프로세스가 없거나 문서화되지 않은 경우
- 모든 AI 프로세스에 사용된 교육, 평가, 테스트 데이터에 대한 정보가 명확하지 않거나 사용할 수 없습니다.
- AI 관련 데이터 정리, 편차 테스트, 결과에 대한 정보가 명확하지 않거나 사용할 수 없음
## 접근성 기술의 *가용성*은 다양한 능력을 가진 사람들을 위한 시스템 또는 솔루션의 유용성을 말합니다. 기능에 상관없이 모든 사용자에게 작동하는 시스템을 설계하는 것은 일부 위치 및 산업에서 법적 의무입니다. 법적 요구 사항 외에도 액세스 가능한 시스템을 구축하면 조직이 이해당사자와의 Trust 촉진하고 강화할 수 있습니다. 고객 대면 응용 프로그램의 경우 고객이 액세스할 수 없는 대안 대신 시스템 사용을 선택할 수 있으므로 매출이 증가할 수도 있습니다. Salesforce는 액세스 가능성 표준을 준수하는 방법을 자세히 설명하는 업계 표준 문서인 [Accessibility Conformance Reports(ACR)](https://www.salesforce.com/company/legal/508_accessibility/)를 게시합니다. Lightning 웹 구성 요소 및 Experience Cloud 템플릿을 비롯한 대부분의 UI 기반 컨트롤은 이 표준을 준수하도록 설계되었습니다. 기준 접근성 기능은 많은 비즈니스에 충분할 수 있지만 프로젝트를 시작하기 전에 ACR 및 릴리스 노트를 검토하는 것이 중요합니다. 이를 통해 제품 또는 서비스의 출시 방식에 따라 표준을 넘어 확장되는 추가적인 접근성 요구 사항을 식별하고 문서화할 수 있습니다. 데이터 입력 및 탐색의 두 가지 핵심 영역에 집중하여 시스템에 액세스하는 방법을 개선할 수 있습니다. ### 데이터 입력 데이터 입력 활동은 사용자가 필드, 양식 또는 사용자 인터페이스의 다른 부분에 정보를 입력해야 할 때마다 발생합니다. 키보드 및 마우스는 가장 일반적인 입력 메서드이지만 일부 사용자는 Speech-to-Text 또는 유사한 장치에 의존할 수 있습니다. 또한 사용자가 다른 언어로 커뮤니케이션할 수 있습니다. 액세스 가능성을 염두에 두고 설계되지 않은 솔루션은 특정 장애가 있는 개인과 상호 작용하지 못하도록 제외할 수 있습니다. 접근성을 위해 설계할 때 다음 사항을 고려하십시오. - 사용자가 선호하는 **언어**입니다. 비즈니스 운영 위치에 따라 시스템에 단일 표준 언어를 설정하거나 다국어 기능을 제공할 수 있습니다. 다중 언어로 텍스트를 표시할 경우 설계 표준에 번역이 필요한 필드 레이블 및 기타 UI 요소(예: 알림 및 오류 메시지) 목록이 포함되어야 합니다. 네이티브 화자를 참여시켜 정확성 및 의미에 대한 번역을 검토합니다. 실시간 메타데이터 및 데이터 번역을 위해 Salesforce [번역 기능을](https://help.salesforce.com/s/articleView?id=sf.workbench_overview.htm&type=5) 사용하고 모든 다국어 기능을 철저하게 테스트합니다. - **사용할 입력 장치 유형** 설계 표준에서 표준 키보드 및 마우스 이상의 데이터 입력에 사용할 수 있는 도구를 나열합니다. 테스트 계획에 접근성 테스트를 포함하고 모든 입력이 여러 유형의 입력 장치로 테스트되었는지 확인합니다. - **양식의 유용성** 양식에 표시되는 레이블을 포함하고, 유용한 오류 메시지를 제공하고, 사용자에게 완료 방법을 안내하고, 사용자에게 진행 상황을 알리고, 입력을 검토, 확인, 편집할 수 있도록 합니다. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/compliant#액세스-가능성-패턴-및-안티-패턴) 목록은 Salesforce 솔루션 내에서 액세스 가능성을 위해 올바르게(또는 부적절하게) 설계된 데이터 입력을 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재연산해야 하는 시스템 영역을 식별합니다. 보다 액세스 가능한 데이터 입력 구축을 위한 Salesforce 도구에 대해 자세히 알아보려면 [규정 준수 관련 도구](/docs/architect/ko-kr/well-architected/guide/compliant#준수와-관련된-도구)를 참조하십시오. ### 탐색 탐색에는 사용자가 화면 간 및 화면 내 필드 간에 포커스를 이동하는 과정이 수반됩니다. 사용자는 시각, 청각 및 터치에 의존하면서 클릭 및 키 입력 등 다양한 방법으로 시스템의 다양한 UI 요소를 탐색해야 할 수 있습니다. 설계 표준에 지원할 탐색 장치 목록이 포함되어 있는지 확인하십시오. 구현 팀은 테스트 시 이 목록을 참조하여 모든 탐색 가능성을 고려해야 합니다. 액세스 가능한 탐색을 설계할 때 다음 질문과 답변을 고려하십시오. - **사용자가 솔루션을 어떻게 탐색할까요?** 설계 표준에서 표준 키보드 및 마우스 이상의 탐색에 사용할 수 있는 장치를 나열합니다. - **탐색이 일관되었습니까?** 전체 시스템에서 일관성을 보장하기 위해 탐색 제어에 대한 설계 표준을 설정합니다. 탐색 경로는 전체 시스템에서 유사해야 합니다. 한 화면의 오른쪽 하단에 파란색 "다음" 버튼과 다음 화면의 가운데에 녹색 "다음" 버튼과 같은 불일치가 있는 탐색은 일부 사용자에게 약간의 불만을 야기할 수 있지만, 장애가 있는 사용자가 응용 프로그램을 사용할 수 없게 만들 수 있습니다. - **검사 시 액세스 가능성을 고려합니까?** 테스트 계획에 접근성 테스트를 포함하고 모든 탐색 플로가 여러 유형의 입력 장치로 테스트되었는지 확인합니다. - **키보드 초점이 지속적으로 보이나요?** 키보드에 의존하는 사용자가 탐색할 수 있도록 항상 현재 키보드 초점 상태를 시각적으로 표시합니다. - **탐색은 색상에 의존합니까?** 색상만 사용하여 정보를 표시하거나 작업을 요청하지 마십시오. [웹 콘텐츠 접근성 지침(WCAG) 2.0](https://www.w3.org/TR/WCAG20/#visual-audio-contrast)을 준수하여 색상을 적절하게 사용하여 의미를 전달하고 적절한 명암비 수준을 적용합니다. - **당신의 디자인이 검토되었습니까?** 사용자 인터페이스가 일관되고 이해하기 쉬운지 정기적으로 검토하십시오. 아래의 [패턴 및 안티패턴](/docs/architect/ko-kr/well-architected/guide/compliant#액세스-가능성-패턴-및-안티-패턴) 목록은 Salesforce 솔루션 내에서 액세스 가능성을 위해 올바르게(또는 잘못) 설계된 경우의 탐색을 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 리팩터링해야 하는 시스템 영역을 식별할 수 있습니다. 더 쉽게 액세스할 수 있는 탐색을 구축할 수 있는 Salesforce 도구에 대해 자세히 알아보려면 [규정 준수 관련 도구](/docs/architect/ko-kr/well-architected/guide/compliant#준수와-관련된-도구)를 참조하십시오. ### 액세스 가능성 패턴 및 안티 패턴 다음 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다. ✨ [Pattern & Anti-Pattern Explorer](/docs/architect/ko-kr/well-architected-tools/guide/trusted-accessibility)에서 액세스 가능성을 위한 더 많은 패턴을 알아보십시오.
패턴 안티 패턴
데이터 입력 설계 기준:
- 표준 키보드 및 마우스 외 데이터 입력에 사용할 수 있는 모든 장치가 나열됩니다.
- 텍스트 값과 지원되는 모든 언어로 된 번역이 나열됩니다.
설계 기준:
- 표준 키보드 및 마우스 외 데이터 입력에 사용할 수 있는 장치 중 일부 또는 없음만 나열됩니다.
- 번역할 UI 요소와 함께 지원되는 언어가 나열됩니다.
테스트 계획:
- 테스트 단계에는 여러 유형의 입력 장치를 사용하여 데이터를 입력하는 것이 포함됩니다.
- 테스트 단계에는 다중 언어로 된 데이터 입력이 포함됩니다.
테스트 계획:
- 액세스 가능성 테스트가 포함되지 않거나 액세스 가능한 데이터 입력에 대한 테스트가 임시로 수행됩니다.
조직에서:
- 지원되는 언어에 대한 번역이 번역 워크벤치에 저장됩니다.
조직에서:
- 번역이 사용자 정의 레이블에 저장됩니다.
탐색 설계 기준:
- 탐색에 사용할 수 있는 모든 장치(표준 키보드 및 마우스뿐만 아니라)가 명확하게 나열됩니다.
- UI/UX 표준은 모든 탐색 컨트롤의 유형 및 스타일을 지정합니다.
- 의미 또는 상태를 전달하기 위해 승인된 시각적 표시 유형이 명확하게 나열되며 색상이 기본 표시등이 아닙니다.
설계 기준:
- 설계 표준이 없거나 탐색 제어에 대한 접근성 요구 사항을 고려하지 않습니다.
- 탐색에 대한 UI/UX 표준이 일치하지 않습니다.
- 의미 또는 상태에 대한 시각적 표시가 색상에 의존하거나 빌더에 대한 명확한 시각적 표시 목록이 없습니다.
테스트 계획:
- 테스트 단계에는 여러 유형의 입력 장치를 사용하여 탐색이 포함됩니다.
- 테스트 계획에는 UI/UX 테스트를 사용하여 일관된 탐색 경로를 보장합니다.
테스트 계획:
- 액세스 가능성 테스트가 포함되지 않거나 액세스 가능한 탐색에 대한 테스트가 임시로 수행됩니다.
## 준수와 관련된 도구
도구설명법적 준수윤리적 표준접근성
Agentforce Analytics에이전트의 성과에 대한 인사이트 확보X
Agentforce 테스트 센터테스트당 최대 1,000개의 테스트 사례가 있는 최대 10개의 테스트 작업을 실행하여 여러 시나리오를 빠르게 만들고 평가할 수 있습니다.X
인용따옴표를 사용하면 생성된 응답에서 잠재적인 부정확성 또는 환각을 식별하여 AI 도구를 사용하는 것에 대한 자신감을 높일 수 있습니다.X
Consent API동의에 대한 고객 기본 설정 추적X
Consent 이벤트 스트림동의 또는 연락처 정보 변경에 대한 알림 보내기X
동의 관리 개체고객 개인 정보 보호 및 동의 기본 설정 관리X
데이터 액세스 및 이동성요청 시 고객 관련 데이터 내보내기X
데이터 분류개체 필드에 대한 레코드 키 준수 및 감사 정보X
Data 360 보고서에이전트 명령 준수 모니터링X
데이터 삭제법적 규정을 준수하기 위해 데이터 삭제X
데이터 프라이버시 기본 설정고객 데이터 프라이버시 기본 설정 저장XX
데이터 번역사용자에게 제공되는 데이터 번역XX
데이터 감지범주 및 민감도 수준을 실제 데이터에 맞춥니다.X
Data 360 Explorer데이터 과학자의 프로젝트 및 개체 권한 관리XX
Einstein Data PrismSalesforce 내 생성형 AI 응용 프로그램을 위한 기초 교육 솔루션으로, 기초 교육 기능을 사용하는 AI 솔루션의 정확성을 향상합니다.X
Einstein Trust 레이어Salesforce 에코시스템 전반에서 데이터 프라이버시를 보호하고, AI 정확성을 향상하고, 책임 있는 AI 사용을 촉진하기 위해 고안된 기능, 프로세스 및 정책 모음X
고급 이벤트 로그이벤트 로그는 에이전트 세션의 이벤트 및 사용자 메시지를 수집하여 지침 준수를 검토하고, 테스트하고, 에이전트의 문제를 해결합니다.X
파일 연결Salesforce에서 외부 파일 찾아보기, 검색 및 공유X
Hyperforce로컬 데이터 저장소 요구 사항 준수X
메타데이터 번역언어를 번역하여 응용 프로그램 현지화XX
Portability API이식성 정책에서 식별된 고객 데이터 컴파일XX
Preference Center고객 커뮤니케이션 기본 설정 수집XX
개인 정보 보호 센터고객 요청 및 데이터 프라이버시 법 준수XX
데이터 처리 제한개인 데이터 처리 방법 제한XX
잊혀질 권리요청 시 개별 고객 데이터 삭제X
Salesforce 파일파일을 비공개로 공유 및 저장X
보안 센터여러 조직에서 보안 및 개인 정보 보호 설정 보기X
Shield Platform Encryption유지 중 및 전송 중 데이터 암호화X
번역 워크벤치메타데이터 및 데이터 레이블에 대해 번역된 값 유지XX
## 준수와 관련된 자원
자원설명법적 준수윤리적 표준접근성
5 Responsible AI 설계 원칙윤리적으로 인공 지능(AI) 기능 설계X
가용성 기본 사항(Trailhead)액세스가 중요한 이유 알아보기X
액세스 가능성 규정 준수 보고서(ACR)Salesforce가 액세스 가능성 표준을 충족하는 방법 이해X
가용성 개요Salesforce Lightning 내의 액세스 가능성 이해X
AI 윤리 성숙도 모델윤리 원칙을 실행하기 위한 로드맵 개발X
AI 레드 팀: Trust 테스트Salesforce의 ' 윤리적 해커'가 빨간색 팀을 통해 책임 있는 AI를 개발하는 방법을 알아봅니다.X
대항자 자동화: Red Teaming AI를 위한 확장 가능한 프레임워크 설계Salesforce가 반대 프롬프트 생성 및 응답 유효성 검사를 자동화하는 방법에 대해 알아보십시오. 퍼지는 AI 상호 작용을 보호하면서 사람들의 유해한 콘텐츠에 대한 노출을 줄이는 데 도움이 됩니다.X
대화 설계를 위한 모범 사례Chatbot 설계 시 모범 사례 따르기XX
지속적인 디자인의 모범 사례(Trailhead)설계에 지속 가능성 통합X
동의 관리동의 및 거부 요청 추적 및 준수X
Einstein 데이터 정책Einstein 기능 전반에서 데이터 사용 제어XX
설계 표준 템플릿조직에 대한 설계 표준 만들기XXX
윤리적 해킹 관행이 신뢰할 수 있는 AI 제품을 구축하는 데 성공했음을 증명합니다.Salesforce에서 악의적인 사용, 의도적인 무결성 공격, 양성 오용, 책임 있는 AI 문제 파악을 통해 AI 제품의 안전을 향상하기 위해 레드 팀을 사용하는 방법에 대해 알아보십시오.X
윤리적 리더십 및 비즈니스기술, 평등, 윤리에 대한 인사이트X
윤리적 사용 정책제품 및 서비스의 윤리적 사용에 대한 Salesforce 정책 살펴보기X
Ethics by Design (Trailhead)기술 개발에 윤리적 설계 통합X
Salesforce의 문화와 가치 탐색(Trailhead)Salesforce의 핵심 값 탐색XX
액세스 가능한 모바일 디자인 지침 준수모범 사례에 따라 디자인에 액세스할 수 있도록 합니다.XX
웹 접근성 시작하기(Trailhead)웹 사이트 및 앱에 액세스할 수 있는 방법의 기본 사항 알아보기X
Salesforce가 재생성 가능한 레드 팀 구성 인프라를 구축하는 방법반대 테스트를 설계, 구현, 실행할 때 권장하는 4가지 구성 요소X
결과 스캔 워크숍 실행 방법혁신하는 동안 가능한 모든 결과 고려X
데이터 보호 및 개인정보보호 구현데이터 보호 및 개인정보보호 요구 사항 평가X
포괄적인 디자인 (Trailhead)포괄적인 설계 원칙으로 혁신 촉진XX
KPI 스프레드시트 템플릿조직의 핵심 성과 지표(KPI) 설정X
법적 정보Salesforce의 법률 정보 센터 살펴보기X
LWC 쿠키 동의 모듈Experience Cloud 사이트에서 사용자 쿠키 액세스 제어XX
개인 정보 개요지역 및 산업별 데이터 프라이버시에 대해 알아보기X
책임 및 윤리적 요소 강화윤리적인 팀 구성 및 테스트 전략을 구현하고 조직에 대한 지침 원칙 및 표준을 개발하는 방법을 알아봅니다.X
책임 있는 에이전트 AI 지침X
AI Trailhead 모듈의 책임 있는 생성데이터 및 알고리즘에서 편향을 제거하여 회사에서 윤리적 AI 시스템을 만드는 방법을 알아봅니다.X
책임 있는 생성형 AI 지침신뢰할 수 있는 AI 원칙을 바탕으로 책임 있는 생성형 AI 개발 및 구현에 초점을 맞춘 새로운 지침을 마련했습니다.X
Salesforce 규정 준수 인증Salesforce의 규정 준수 인증 및 증명 검토X
지속적인 디자인 (Trailhead)비즈니스와 사회 간의 관계 강화X
웹 접근성 테스트(Trailhead)자동 및 수동 테스트를 활용하여 접근성 보장X
신뢰할 수 있는 에이전트 AIAgentforce 보안 및 책임 있는 AI 원칙을 사용하여 윤리적 AI를 만드는 방법에 대해 알아봅니다.x
## 의견을 알려주십시오. Salesforce Well-Architected의 관련성을 유지할 수 있도록 도와주십시오. 이 콘텐츠에 대한 사용자 의견을 제공하려면 [ 설문 조사](https://sfdc.co/bxNtvh)을 작성하고 다음에 표시할 내용을 알려주십시오.