--- schema_version: "1" id: 0d26b955d8998e5086050bff516316261048b1aaca2eb624503b64f61da3da1a title: 비용 관리 및 의사 결정 - 패턴 collection: architect version: current locale: ko-kr portal_url: https://docs.salesforce.com/architect/current/ko-kr/well-architected/guides/resource-and-cost-optimization-governance-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/ko-kr/well-architected/guide/resource-and-cost-optimization-governance-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: c7aff824968d62d97a0bc81360e289dc9b3348fff2ab6725f7523e1577576eae products: - 잘 설계된 프레임워크 - Architect Site Content Repo --- # 비용 관리 및 의사 결정 - 패턴 잘 설계된 [자원 및 비용 최적화](/docs/architect/ko-kr/well-architected/guide/resource-and-cost-optimization.html)에 대해 자세히 알아보기 → [비용 모니터링 및 거버넌스](/docs/architect/ko-kr/well-architected/guide/resource-and-cost-optimization.html#cost-monitoring-and-governance) ## 비용 모니터링 및 가시성 **패턴** | 찾을 위치 | 유사성 | | --- | --- | | **설정** → 회사 설정 → 시스템 개요
**보고서 및 대시보드** → Cost Utilization 폴더 | ✅ **패턴**: 연간 1,200개의 라이센스(매주 68% 활성), 450GB 저장소(용량 72%), 15개의 Sandbox(활성 사용 중 11개)에 배포된 $2.1백만의 Salesforce 투자가 표시된 실행 대시보드 만들기
✅ 대시보드에 운영 메트릭을 통해 비활성 라이센스 및 미사용 Sandbox의 $400,000 최적화 기회 표시 | | **보고서 및 대시보드** → 투자 대시보드
**설정** → 회사 정보 | ✅ **패턴**: 투자 대시보드에 사업부 또는 비용 센터별 지출, 개발 팀별 Sandbox 및 환경 비용, 이용 메트릭 포함 추가 제품 비용이 표시됩니다.
✅ 현재 성장 추세를 기반으로 한 프로젝트 지출으로 예산 책임 및 할당 토론 지원 | **안티 패턴** | 찾을 위치 | 불만 사항 | | --- | --- | | **계산 시스템** → 청구서 기록만 해당 | ⚡️ **안티 패턴**: 재무 팀에 총 지출을 표시하는 인보이스 가시성이 있지만 이용 패턴 또는 최적화 기회를 표시하는 운영 메트릭이 없는 경우
⚡️ 운영 대시보드 없이 비활성 라이센스, 미사용 Sandbox 또는 수용력 손실을 식별할 수 없음 | ## 예산 제어 및 경고 **패턴** | 찾을 위치 | 유사성 | | --- | --- | | **보고서 및 대시보드** → 라이센스 예산 경고
**설정** → 라이센스 할당 | ✅ **패턴**: 수용력에 근접할 때 경고가 포함된 부서별 할당 목표를 설정하는 라이센스 예산
✅ Proactive Monitoring 통해 갱신 시간에만 발견되는 예산 초과 실행을 유발하는 제어되지 않은 프로비저닝 방지 | | **설정** → 저장소 사용 → 경고 규칙
**플로** → 스토리지 경고 자동화 | ✅ **패턴**: 제한에 도달하기 전에 4개월 리드 타임을 제공하는 70% 스토리지 활용도에서 자동화된 경고 트리거
✅ 적절한 응답 시간으로 사전 예방 알림을 통해 비상 데이터 삭제 또는 비용이 많이 드는 초과 근무를 방지합니다. | | **시스템 개요** → API 사용 경고
**이벤트 모니터링** → API 임계값 경고 | ✅ **패턴**: API 예산은 70% 및 85%와 같은 예제 사용 임계값에 경고를 사용하여 제한 대비 소비를 추적합니다.
✅ 제한으로 인해 통합 실패 또는 사용자 중단 후 반응형 긴급 대응 대신 사전 예방적 최적화를 활성화합니다. | | **설정** → Sandbox 관리 → 예산 제어
**플로** → Sandbox 요청 승인 | ✅ **패턴**: Sandbox 예산은 추가 환경에 대한 할당 제한 및 승인 프로세스를 통해 환경 확산을 제어합니다.
✅ 팀이 근거 없이 영구 상태로 전환하는 무제한 임시 환경을 만들지 않도록 방지 | **안티 패턴** | 찾을 위치 | 불만 사항 | | --- | --- | | **예산 제어 없음** → 무제한 지출 | ⚡️ **안티 패턴**: 지출 패턴에 대한 가시성 없이 부서 전체에서 무제한 프로비저닝을 허용하는 라이센스 예산 또는 승인 워크플로 없음
⚡️ 갱신 시 예산 초과가 감지되었으며, 비제어적인 성장으로 인해 총 지출이 계획된 투자를 30~40% 초과하는 경우 | | **스토리지 알림 없음** → 반응형 초과 | ⚡️ **안티 패턴**: 보관 평가 시간 없이 프리미엄 가격으로 즉시 구매해야 하는 갱신 협상을 수행하는 동안 발견된 저장소 초과 시간
⚡️ 초과가 발생하기 전에 보관 구현을 활성화하는 사전 경고가 누락되어 비용이 2~3배 더 높습니다. | ## 비용 할당 및 요금 청구 **패턴** | 찾을 위치 | 유사성 | | --- | --- | | **보고서 및 대시보드** → Showback Report
**보고서** → 비즈니스 단위별 비용 | ✅ **패턴**: 분기별 표시 보고서에 Sales Cloud가 라이센스 투자의 45%, Service Cloud 30%, 운영 25%를 소비하는 것으로 표시됩니다.
✅ 투자 분포가 비즈니스 가치 우선 순위 및 전략적 중점 영역과 일치하는지 여부에 대한 경영진 토론을 활성화합니다. | | **재무 시스템** → 청구 할당
**보고서** → 부서 비용 할당 | ✅ **패턴**: 할당 규칙은 사용자 부서 할당별 라이센스 비용, 소유 개발 팀별 Sandbox 비용을 적절하게 배포합니다.
✅ 통합 서비스를 사용하는 비즈니스 프로세스에 따라 할당되는 통합 비용, 프로젝트 펀딩 소스 요청에 따른 개발 비용 | | **보고서 및 대시보드** → Sandbox 비용 보고서
**설정** → 팀별 Sandbox 사용 | ✅ **패턴**: 소유 개발 팀이 할당한 Sandbox 및 환경 비용으로 환경 관리에 대한 직접적인 책임 부여
✅ 팀이 환경 요청 및 수명 주기 관리에 대해 정보에 근거한 결정을 내릴 수 있는 Sandbox 투자 확인 | **안티 패턴** | 찾을 위치 | 불만 사항 | | --- | --- | | **IT 예산만 해당** → 비즈니스 단위 가시성 없음 | ⚡️ **안티 패턴**: 사업부 가시성이 없는 IT 예산에 할당된 모든 Salesforce 비용
⚡️ 비즈니스 이해당사자는 플랫폼을 "무료"로 처리하고 비용 인식 또는 투자 우선 순위 토론 없이 요청을 합니다. | | **사용자 지정 없음** → 최적화할 수 없음 | ⚡️ **안티 패턴**: 총 지출이 표시되지만 최적화 결정을 불가능하게 만드는 사업부, 프로젝트 또는 팀에 대한 할당은 없습니다.
⚡️ 비례 배출이 없는 가치를 제공하는 투자와 예산을 소비하는 투자를 식별할 수 없음 | ## FinOps 및 비용 인식 문화 **패턴** | 찾을 위치 | 유사성 | | --- | --- | | **공동 작업** → FinOps 팀
**회의** → 월간 비용 검토 | ✅ **패턴**: 재무, 아키텍처, 비즈니스 이해당사자 간의 기능 간 공동 작업을 통해 비용 결정이 비즈니스 가치와 지출 영향을 고려함
✅ FinOps는 아키텍처 토론에 재무 전문 지식을 제공하고 균형 잡힌 결정을 내리는 예산 계획에 기술적 이해를 제공합니다. | | **캘린더** → 최적화 리뷰
**프로세스** → 정규 케이던스 | ✅ **패턴**: 월별 변칙 검토, 분기별 이용 감사, 연간 종합적인 TCO 평가가 포함된 연속 최적화 케이던스
✅ 정기적인 검토 주기를 통해 비용 드리프트를 방지하고 체계적인 분석을 통해 지출 증가가 비즈니스 가치 증가에 해당하는지 확인 | | **도구** → 라이센스 비용 계산기
**아키텍처** → TCO 모델 | ✅ **패턴**: FinOps 팀은 다양한 라이센스 유형 선택 항목의 TCO 영향을 보여주는 라이센스 비용 계산기를 아키텍처에게 제공합니다.
✅ 변경 비용이 많이 드는 경우 배포 후 비용을 파악하는 대신 아키텍처 단계에서 비용을 인식하는 설계 결정을 내릴 수 있습니다. | | **교육** → 비용 인식 프로그램
**문서** → Cost Impact Guidelines | ✅ **패턴**: 비용 인식 교육을 통해 팀이 아키텍처 결정이 총 소유 비용에 미치는 영향을 이해할 수 있습니다.
✅ 설계자는 능력과 투자의 균형을 맞추는 향상된 솔루션을 설계하고, 개발자는 총괄자 제한 및 API 소비를 준수하는 보다 효율적인 자동화를 작성합니다. | | **자동화** → 비용 모니터링 스크립트
**대시보드** → 자동 생성 보고서 | ✅ **패턴**: 사용량, 기회 최적화, 지출 보고서를 자동으로 모니터링하여 수작업 노력이 줄어듭니다.
✅ 직원이 선형적으로 증가하지 않고 조직의 복잡성에 맞춰 확장하여 성장하는 플랫폼 이력에 대한 비용 인식을 제공합니다. | **안티 패턴** | 찾을 위치 | 불만 사항 | | --- | --- | | **연간만** → 피드백 루프 없음 | ⚡️ **안티 패턴**: 사용자 의견 루프가 없는 연간 갱신 토론으로 제한된 비용 가시성
⚡️ 변경 비용이 가장 적을 경우 설계 단계에서 아키텍처 팀이 지출 패턴을 이해하거나 최적화할 수 없습니다. | | **실로 결정** → 교차 기능 입력 없음 | ⚡️ **안티 패턴**: 금융 입력이 없는 아키텍처 결정, 기술적 이해가 없는 예산 결정
비즈니스 근거 없이 예산을 초과하는 솔루션 또는 중요 가치를 제공하는 기능을 제거하는 예산을 줄이는 결과 | | **무료 교육** → 무지한 결정 | ⚡️ **안티 패턴**: 교육 또는 가시성이 없으므로 팀이 비용에 미치는 영향을 이해하지 않고 아키텍처 결정을 내릴 수 있습니다.
⚡️ 개별적으로 작은 것처럼 보이지만 상당한 비용으로 복합되는 수천 개의 마이크로 결정을 통해 폐기물이 누적됩니다. | ## 아키텍처 검토 비용 통합 **패턴** | 찾을 위치 | 유사성 | | --- | --- | | **문서** → 아키텍처 의사 결정 기록
**프로세스** → ADR 템플릿 | ✅ **패턴**: 고객 포털의 아키텍처 결정 레코드에는 라이센스 분석이 포함되어 있습니다. Customer Community Plus 라이센스가 있는 외부 사용자 10,000명(사용자당 월별 $6 = 연간 $720,000)
✅ API 통합을 사용하는 사용자 정의 웹 응용 프로그램과 비교(초기 $250,000 + 연간 서비스 점검 $50,000), 2년 환급이 포함된 사용자 정의 응용 프로그램 권장 | | **거버넌스** → 아키텍처 검토 위원회
**프로세스** → 비용 검토 기준 | ✅ **패턴**: 아키텍처 검토 위원회에 더 잘 조율된 투자 결정을 생성하는 기능 및 비 기능 요구 사항과 함께 비용 관점이 포함됨
✅ 비용은 조직이 낭비를 방지하면서 중요한 기능에 적절하게 투자할 수 있도록 아키텍처 결정에 대한 한 가지 입력입니다. | | **문서** → ADR 비용 섹션
**템플릿** → TCO 예상 | ✅ **패턴**: 주요 설계 선택 항목을 문서화하는 아키텍처 결정 레코드에 비용 영향 평가 포함
✅ 문서화된 가정을 사용하여 정의된 투자 임계값($100,000 또는 조직 정책)을 초과하는 솔루션에 TCO 예상 요구 | | **프로세스** → 라이센스 영향 검토
**아키텍처** → 프리미엄 기능 분석 | ✅ **패턴**: 솔루션 설계 시 라이센스 영향을 평가하여 설계에 프리미엄 라이센스 또는 추가 기능이 필요한지 여부 결정
✅ API 소비 또는 미들웨어 라이센스 요구 사항에 영향을 미치는 패턴을 적용하기 전에 통합 비용이 미치는 영향을 평가합니다. | **안티 패턴** | 찾을 위치 | 불만 사항 | | --- | --- | | **비용 고려** → 비상 재설계 | ⚡️ **안티 패턴**: 아키텍처는 비용을 고려하지 않고 설계되었으며 구현 계획 시 제안된 접근 방식에 연간 $720,000의 투자가 필요함을 발견했습니다.
⚡️ 처음부터 비용에 민감한 설계와 비교하여 결과가 낮은 시간에 긴급 재설계 발생 | | **설계 후 비용 검색** → 낭비된 노력 | ⚡️ **안티 패턴**: 예산을 3배 초과하는 방법을 보여주는 비용 분석 전에 아키텍처 완료
⚡️ 프로젝트 시작부터 알려진 예산 제약 내에서 팀이 재설계하는 동안 설계 노력이 낭비되고 배달이 지연됨 | ## 구축 및 구매 결정 프레임워크 비교 **패턴** | 찾을 위치 | 유사성 | | --- | --- | | **AppExchange** → 솔루션 평가
**분석** → TCO 비교 | ✅ **패턴**: 문서 생성 솔루션 평가: AppExchange 옵션(사용자당 월 15달러)(사용자 100명에 대해 연간 18,000달러) 대비 사용자 정의 개발(초기 빌드 80,000달러 + 연간 유지 관리 15,000달러)
✅ 5년 후에도 AppExchange 중단되고 배포 속도가 빨라지고 상품 기능에 대한 위험이 낮음 | | **AppExchange** → 전략적 대 상품
**아키텍처** → 기능 분류 | ✅ **패턴**: 솔루션이 강력한 검토를 받는 AppExchange 구매한 상품 기능(문서 생성, 전자 서명, 주소 보강)
✅ 로드맵 및 차별화에 대한 완벽한 제어를 통해 맞춤형으로 구축된 경쟁 우위를 제공하는 독점 가격 책정 알고리즘 | | **스프레드시트** → 3-5년 TCO 모델
**분석** → 비용 예상 | ✅ **패턴**: 초기 비용을 제외한 전체 투자 상황을 보여주는 3~5년의 총 비용을 예상하는 TCO 모델 구축
✅ AppExchange 복합 연간 구독을 수행하지만 서비스 점검이 포함됩니다. 사용자 정의에는 일회성 개발과 연간 서비스 점검 15-20%가 필요합니다. | | **통합 분석** → 맞춤형 vs 플랫폼
**TCO** → 통합 비교 | ✅ **패턴**: 사용자 정의 통합 개발: $150K 초기 빌드 + $30K 연간 서비스 점검 + 팀 학습 곡선 및 MuleSoft 라이센스 비교: 연간 75,000달러 + 더 빠른 통합 배달
✅ MuleSoft는 모든 통합에서 재사용 가능한 패턴을 제공하여 포트폴리오 성장에 따라 통합당 비용을 절감합니다. | | **문서** → 구축 대 구매 ADR
**프로세스** → 평가 프레임워크 | ✅ **패턴**: 점수 매트릭스 가중치 전략적 가치, TCO, 타임라인, 기능, 종료 비용을 사용하여 아키텍처 의사 결정 레코드 문서 구축 및 구매 평가 비교
✅ 요구 사항이 발전하거나 공급업체 환경이 변경되면 향후 재평가를 위해 감사 내역을 만듭니다. | **안티 패턴** | 찾을 위치 | 불만 사항 | | --- | --- | | **Always Build** → 낭비된 개발 | ⚡️ **안티 패턴**: 5년 TCO를 모델링하지 않고 사용 가능한 개발자가 있으므로 사용자 정의 문서 생성 솔루션 구축
⚡️ AppExchange 상품 기능에 더 나은 가치를 제공합니다. 사용자 정의 개발은 차별화되지 않은 기능에 대한 용량 낭비 | | **Always Buy** → 차이점 누락 | ⚡️ **안티 패턴**: "배포 속도 향상"으로 인해 전략적 차별화 요소를 포함하여 AppExchange 모든 기능 구매
⚡️ 동일한 AppExchange 솔루션을 사용하는 경쟁업체는 동일한 기능을 확보하고 플랫폼 투자로 인한 경쟁 우위를 제거합니다. | | **단일 회의 결정** → 분석 없음 | ⚡️ **안티 패턴**: 체계적인 평가 또는 문서화 없이 초기 비용 비교를 기반으로 한 단일 회의에서 결정된 구축 및 구매 비교
⚡️ 누락된 전략적 가치 평가, TCO 예상, 타임라인 요구 사항, 역량 평가, 종료 비용 분석 | | **비완전한 비용 모델** → 숨겨진 비용 | ⚡️ **안티 패턴**: 5년 서비스 점검 부담을 모델링하지 않고 사용자 정의 통합 구축
⚡️ 서비스 점검은 일반적으로 연간 초기 개발 비용의 15-20%, 초기 결정에 표시되지 않는 플랫폼 호환성 노력을 소비합니다. | ## 결정 프레임워크 체계적 평가 **패턴** | 찾을 위치 | 유사성 | | --- | --- | | **프로세스** → 전략적 가치 평가
**분석** → 차별화 매트릭스 | ✅ **패턴**: 불완전한 분석을 기반으로 특별 결정을 방지하는 일관된 평가를 통해 구축 및 구매 결정을 체계화
✅ 먼저 전략적 가치를 평가합니다. 핵심 경쟁 차별화 요소는 사용자 정의 투자를 보장하며, 원시 기능은 총 비용을 낮추고 입증된 솔루션을 구매하는 것이 좋습니다. | | **AppExchange** → 솔루션 성숙도 검토
**분석** → 공급업체 안정성 검사 | ✅ **패턴**: 솔루션 성숙도, 고객 등급, ISV 안정성, 기능 정렬, 가격 책정 모델을 검토하여 사용 가능한 AppExchange 옵션을 평가합니다.
✅ 고객이 적은 오래된 솔루션은 더 높은 위험을 야기하며 강력한 검토 및 안정적인 공급업체 재무 상태로 입증된 솔루션의 우선 순위를 지정합니다. | | **스프레드시트** → 민감도 분석
**TCO** → 가정 설명서 | ✅ **패턴**: 라이센스/구독, 구현 노력, 서비스 점검 부담, 개선 개발, 플랫폼 호환성과 같은 모든 비용 범주를 포함하는 실현 가능한 옵션에 대해 3-5년 동안 TCO 모델링
✅ 성장률 또는 사용량이 예상과 다른 경우 결과가 어떻게 변화하는지 보여주는 가정에 대한 민감도 분석을 활성화하는 스프레드시트 사용 | | **타임라인** → 시장 타이밍 분석
**전략** → Time-to-Value 평가 | ✅ **패턴**: AppExchange 몇 주 후에 배포되는 동안 복잡성에 따라 사용자 정의 개발에 수개월에서 수년이 소요되는 시간 표시 막대 요구 사항을 평가합니다.
✅ 경쟁상 압박 또는 비즈니스 기회로 인해 즉각적인 성능이 필요한 경우 시장 타이밍이 더 높은 장기 비용에도 불구하고 구매 결정을 촉진할 수 있음 | | **분석** → 종료 비용 평가
공급업체 잠금 평가 **리스크** | ✅ **패턴**: 선택한 옵션이 부적합한 경우 전환의 어려움을 묻는 종료 비용 및 공급업체 집중 위험 평가
✅ 요구 사항이 변경될 경우 공급업체 인수 또는 중단 위험 및 솔루션 이동성을 고려하여 전략적 유연성을 제공하는 낮은 종료 비용을 선호합니다. | | **능력** → 정직한 평가
**팀** → 유지 보수 용량 검토 | ✅ **패턴**: 사용자 정의 솔루션을 장기간 유지할 수 있는지 정직하게 평가하는 조직 기능 고려
✅ 사용자 정의 솔루션은 유지 관리 및 진화에 대한 지속적인 내부 전문 지식이 필요하며, 잠재적으로 더 높은 비용에도 불구하고 이 기능이 부족한 조직은 구매해야 합니다. | **안티 패턴** | 찾을 위치 | 불만 사항 | | --- | --- | | **No Framework** → 불일치하는 결정 | ⚡️ **안티 패턴**: 구축 및 구매 결정은 일관된 평가 기준 없이 프로젝트 팀 기본 설정에 따라 다릅니다.
⚡️ 일부 팀은 항상 구축하고 다른 팀은 항상 구매하므로 플랫폼 전반에서 아키텍처 불일치 및 최적화되지 않은 총 투자 수준이 발생합니다. | | **모든 것을 만들기** → 차별화되지 않는 노력 | ⚡️ **안티 패턴**: 상품 성능과 전략적 차별화 요소를 구분하지 않고 "제어를 원함"으로써 모든 사용자 정의 구축
⚡️ 적은 총 비용으로 성숙한 AppExchange 솔루션이 제공하는 차별화되지 않은 기능에 대한 개발 능력을 낭비합니다. | | **초기 비용만** → 불완전한 분석 | ⚡️ **안티 패턴**: 초기 비용 비교를 기반으로 한 결정: "AppExchange $20,000이고 사용자 정의 빌드는 $15,000이므로 구축할 것입니다."
⚡️ 사용자 정의 솔루션 비용이 표시되는 3-5년 TCO 누락 $15,000 초기 + $3,000 연간 유지 보수, AppExchange 구독에 모든 유지 보수 포함 | | **최적화 능력** → 실패한 유지 보수 | ⚡️ **안티 패턴**: 팀이 현재 용량 또는 전문 지식이 없어도 솔루션을 유지할 수 있다고 가정하는 사용자 정의 개발 선택
⚡️ 서비스 점검이 지연되면 기술 부채가 누적되며, 솔루션을 유지 관리할 수 없게 되므로 비용이 많이 드는 교체가 필요합니다. |