Google Cloud 잘 설계된 프레임워크의 이 핵심 요소에서는Google Cloud에서 워크로드의 성능을 최적화하기 위한 권장사항을 제공합니다.
이 문서는 Google Cloud에서 워크로드를 계획, 설계, 배포, 관리하는 설계자, 개발자, 관리자를 대상으로 합니다.
이 영역의 권장사항은 조직이 효율적으로 운영하고, 고객 만족도를 높이고, 수익을 늘리고, 비용을 절감하는 데 도움이 됩니다. 예를 들어 애플리케이션의 백엔드 처리 시간이 단축되면 사용자의 응답 시간이 빨라져 사용자 유지율과 수익이 증가할 수 있습니다.
성능 최적화 프로세스에는 성능과 비용 간의 절충이 포함될 수 있습니다. 하지만 성능을 최적화하면 비용을 절감할 수 있습니다. 예를 들어 부하가 증가할 때 자동 확장은 시스템 리소스가 과부하되지 않도록 하여 예측 가능한 성능을 제공하는 데 도움이 됩니다. 또한 자동 확장을 사용하면 부하가 낮은 기간에 사용되지 않는 리소스를 삭제하여 비용을 절감할 수 있습니다.
성능 최적화는 일회성 활동이 아닌 연속적인 프로세스입니다. 다음 다이어그램은 성능 최적화 프로세스의 단계를 보여줍니다.
성능 최적화 프로세스는 다음 단계를 포함하는 지속적인 사이클입니다.
- 요구사항 정의: 애플리케이션을 설계하고 개발하기 전에 애플리케이션 스택의 각 레이어에 대한 세부 성능 요구사항을 정의합니다. 리소스 할당을 계획하려면 주요 워크로드 특성과 성능 기대치를 고려하세요.
- 설계 및 배포: 성능 요구사항을 충족하는 데 도움이 될 수 있는 탄력적이고 확장 가능한 설계 패턴을 사용합니다.
- 모니터링 및 분석: 로그, 추적, 측정항목, 알림을 사용하여 성능을 지속적으로 모니터링합니다.
최적화: 애플리케이션이 발전함에 따라 잠재적인 재설계를 고려합니다. 클라우드 리소스의 크기를 적절하게 조정하고 새로운 기능을 사용하여 변화하는 성능 요구사항을 충족합니다.
위의 다이어그램에 표시된 것처럼 모니터링, 요구사항 재평가, 클라우드 리소스 조정 주기를 계속합니다.
AI 및 ML 워크로드와 관련된 성능 최적화 원칙 및 권장사항은 Well-Architected Framework의 AI 및 ML 관점: 성능 최적화를 참고하세요.
핵심 원칙
Well-Architected Framework의 성능 최적화 필라의 권장사항은 다음 핵심 원칙에 매핑됩니다.
참여자
저자:
기타 참여자:
- 필리페 그라시오, 박사 | 고객 엔지니어
- Jose Andrade | 엔터프라이즈 인프라 고객 엔지니어
- 저자: 쿠마르 다나고팔 | 크로스 프로덕트 솔루션 개발자
- 마르완 알 샤위 | 파트너 고객 엔지니어
- 니콜라스 핀토 | 고객 엔지니어, 애플리케이션 현대화 전문가
- 라이언 콕스 | 수석 설계자
- 라디카 카나캄 | 선임 프로그램 관리자, 클라우드 GTM
- 사만다 헤 | 테크니컬 라이터
- 웨이드 홈즈 | 글로벌 솔루션 디렉터
리소스 할당 계획
Google Cloud Well-Architected Framework의 성능 최적화 요소 원칙은Google Cloud에서 워크로드의 리소스를 계획하는 데 도움이 되는 권장사항을 제공합니다. 클라우드 배포 또는 마이그레이션을 위한 애플리케이션을 설계하고 개발하기 전에 세부 요구사항을 정의하는 것이 중요함을 강조합니다.
원칙 개요
비즈니스 요구사항을 충족하려면 설계 및 개발 전에 애플리케이션의 성능 요구사항을 정의하는 것이 중요합니다. 이러한 요구사항을 전체 애플리케이션과 애플리케이션 스택의 각 레이어에 대해 최대한 세부적으로 정의합니다. 예를 들어 스토리지 레이어에서는 애플리케이션에 필요한 처리량과 초당 I/O 작업 수 (IOPS)를 고려해야 합니다.
처음부터 성능과 확장성을 고려하여 애플리케이션 설계를 계획합니다. 사용자 수, 데이터 볼륨, 시간 경과에 따른 잠재적 성장과 같은 요소를 고려하세요.
각 워크로드의 성능 요구사항은 워크로드 유형에 따라 다릅니다. 각 워크로드에는 고유한 성능 특성 집합이 있는 구성요소 시스템과 서비스가 혼합되어 있을 수 있습니다. 예를 들어 대규모 데이터 세트의 주기적인 일괄 처리를 담당하는 시스템은 대화형 가상 데스크톱 솔루션과 다른 성능 요구사항을 갖습니다. 최적화 전략은 각 워크로드의 구체적인 요구사항을 충족해야 합니다.
각 워크로드의 성능 목표에 부합하는 서비스와 기능을 선택합니다. 성능 최적화에는 모든 경우에 적합한 솔루션이 없습니다. 각 워크로드를 최적화하면 전체 시스템이 최적의 성능과 효율성을 달성할 수 있습니다.
성능 요구사항에 영향을 줄 수 있는 다음 워크로드 특성을 고려하세요.
- 배포 원형: 애플리케이션에 선택한 배포 원형은 제품 및 기능 선택에 영향을 줄 수 있으며, 이는 애플리케이션에서 기대할 수 있는 성능을 결정합니다.
- 리소스 배치: 애플리케이션 리소스의 Google Cloud 리전을 선택할 때는 최종 사용자의 지연 시간을 최소화하고, 데이터 현지화 규정을 준수하며, 필요한 Google Cloud 제품 및 서비스의 가용성을 보장하는 것이 좋습니다.
- 네트워크 연결: 데이터 액세스 및 콘텐츠 전송을 최적화하는 네트워킹 서비스를 선택합니다. Google Cloud의 글로벌 네트워크, 고속 백본, 상호 연결 위치, 캐싱 서비스를 활용하세요.
- 애플리케이션 호스팅 옵션: 호스팅 플랫폼을 선택할 때는 각 옵션의 성능상의 장단점을 평가해야 합니다. 예를 들어 베어 메탈, 가상 머신, 컨테이너, 서버리스 플랫폼을 고려해 보세요.
- 스토리지 전략: 성능 요구사항에 따라 최적의 스토리지 전략을 선택합니다.
- 리소스 구성: 머신 유형, IOPS, 처리량은 성능에 큰 영향을 미칠 수 있습니다. 또한 설계 단계 초기에 적절한 보안 기능과 리소스에 미치는 영향을 고려해야 합니다. 보안 기능을 계획할 때는 예기치 않은 영향을 방지하기 위해 필요한 성능 절충을 수용할 준비를 해야 합니다.
권장사항
최적의 리소스 할당을 보장하려면 다음 섹션의 권장사항을 고려하세요.
할당량 구성 및 관리
애플리케이션이 메모리, 저장소, 처리 능력과 같은 필요한 리소스만 사용하는지 확인합니다. 과도한 할당은 불필요한 비용을 초래할 수 있고, 부족한 할당은 성능 저하를 초래할 수 있습니다.
탄력적 확장을 수용하고 충분한 리소스를 사용할 수 있도록 할당량의 용량을 정기적으로 모니터링하세요. 또한 할당량 사용량을 추적하여 잠재적인 확장 제약이나 과도한 할당 문제를 파악한 다음 리소스 할당에 대해 정보에 기반한 결정을 내립니다.
교육 및 인식 제고
사용자에게 성능 요구사항을 알리고 효과적인 성능 관리 기법에 관한 교육 리소스를 제공하세요.
진행 상황을 평가하고 개선이 필요한 부분을 파악하려면 목표 성능과 실제 성능을 정기적으로 문서화하세요. 애플리케이션을 부하 테스트하여 잠재적인 중단점을 찾고 애플리케이션을 확장하는 방법을 파악합니다.
성능 측정항목 모니터링
Cloud Monitoring을 사용하여 성능 측정항목의 추세를 분석하고, 실험의 효과를 분석하고, 중요한 측정항목에 대한 알림을 정의하고, 소급 분석을 수행할 수 있습니다.
Active Assist는 리소스 활용도를 최적화하는 데 도움이 되는 통계와 권장사항을 제공할 수 있는 도구 집합입니다. 이러한 추천은 리소스 할당을 조정하고 실적을 개선하는 데 도움이 됩니다.
탄력성 활용
Google Cloud Well-Architected Framework의 성능 최적화 부문에서 이 원칙을 따르면 워크로드 요구사항의 변화에 따라 리소스를 동적으로 조정하는 기능인 탄력성을 통합하는 데 도움이 되는 권장사항을 확인할 수 있습니다.
탄력성을 사용하면 시스템의 여러 구성요소를 독립적으로 확장할 수 있습니다. 이 타겟팅된 확장 기능을 사용하면 리소스를 과도하게 프로비저닝하거나 부족하게 프로비저닝하지 않고 필요한 곳에 정확하게 할당하여 성능과 비용 효율성을 개선할 수 있습니다.
원칙 개요
시스템의 성능 요구사항은 시스템이 언제 어떻게 수직으로 확장되거나 수평으로 확장되는지에 직접적인 영향을 미칩니다. 시스템의 용량을 평가하고 시스템이 기준에서 처리할 것으로 예상되는 부하를 결정해야 합니다. 그런 다음 시스템이 부하 증가 및 감소에 어떻게 대응해야 하는지 결정해야 합니다.
부하가 증가하면 시스템은 수평으로 확장하거나 수직으로 확장하거나 둘 다 실행해야 합니다. 수평 확장의 경우 복제본 노드를 추가하여 시스템에 증가한 수요를 충족할 수 있는 충분한 전체 용량이 있는지 확인합니다. 수직 확장의 경우 애플리케이션의 기존 구성요소를 용량, 메모리, 스토리지가 더 많은 구성요소로 대체합니다.
부하가 감소하면 시스템은 축소되어야 합니다 (가로, 세로 또는 둘 다).
시스템이 확장되거나 축소되는 상황을 정의합니다. 트래픽이 많은 것으로 알려진 기간에 시스템을 수동으로 확장할 계획을 세우세요. 부하의 증가 또는 감소에 대응하는 자동 확장과 같은 도구를 사용합니다.
권장사항
탄력성을 활용하려면 다음 섹션의 권장사항을 고려하세요.
최대 부하 기간 계획
예상되는 고객 수요 증가 기간과 같은 알려진 이벤트에 대해 효율적인 확장 경로를 계획해야 합니다.
트래픽이 많은 것으로 알려진 기간 전에 시스템을 확장하는 것이 좋습니다. 예를 들어 소매 조직의 경우 시즌별 할인 기간에 수요가 증가할 것으로 예상됩니다. 시스템이 증가된 부하를 즉시 처리하거나 기존 한도를 즉시 조정할 수 있도록 이러한 판매 전에 시스템을 수동으로 확장하는 것이 좋습니다. 그렇지 않으면 시스템에서 실시간 변경사항에 따라 리소스를 추가하는 데 몇 분 정도 걸릴 수 있습니다. 애플리케이션의 용량이 충분히 빠르게 증가하지 않아 일부 사용자에게 지연이 발생할 수 있습니다.
수요 또는 트래픽의 급증과 같은 알 수 없거나 예상치 못한 이벤트의 경우 자동 확장 기능을 사용하여 측정항목을 기반으로 탄력적 확장을 트리거할 수 있습니다. 이러한 측정항목에는 CPU 사용률, 부하 분산기 제공 용량, 지연 시간, Cloud Monitoring에서 정의한 커스텀 측정항목이 포함될 수 있습니다.
예를 들어 Compute Engine 관리형 인스턴스 그룹 (MIG)에서 실행되는 애플리케이션을 생각해 보세요. 이 애플리케이션에는 평균 CPU 사용률이 75%에 도달할 때까지 각 인스턴스가 최적으로 실행되어야 한다는 요구사항이 있습니다. 이 예에서는 CPU 사용률이 기준점에 도달하면 인스턴스를 더 많이 만드는 자동 확장 정책을 정의할 수 있습니다. 새로 생성된 인스턴스는 부하를 흡수하여 MIG에 구성된 최대 인스턴스 수에 도달할 때까지 평균 CPU 사용률이 최적의 비율로 유지되도록 지원합니다. 수요가 감소하면 자동 확장 정책에서 더 이상 필요하지 않은 인스턴스를 삭제합니다.
관리형 자동 스케일러를 사용하여 BigQuery의 리소스 슬롯 예약을 계획하거나 Spanner의 자동 확장 구성 제한을 조정합니다.
예측 확장 사용
시스템 구성요소에 Compute Engine이 포함된 경우 예측 자동 확장이 워크로드에 적합한지 평가해야 합니다. 예측 자동 확장은 측정항목의 과거 추세(예: CPU 사용률)를 기반으로 향후 부하를 예측합니다. 예측은 몇 분마다 다시 계산되므로 자동 확장 처리에서 최근의 부하 변동에 맞게 예측을 빠르게 조정할 수 있습니다. 예측 자동 확장을 사용하지 않으면 자동 확장 처리는 실시간으로 부하에서 관찰된 변경사항을 기준으로 대응적으로 그룹만 확장할 수 있습니다. 예측 자동 확장은 실시간 데이터와 이전 데이터를 모두 사용하여 현재 및 예상 부하에 대응합니다.
서버리스 아키텍처 구현
다음과 같이 본질적으로 탄력적인 서버리스 서비스를 사용하여 서버리스 아키텍처를 구현하는 것이 좋습니다.
규칙을 미세 조정해야 하는 다른 서비스 (예: Compute Engine)의 자동 확장과 달리 서버리스 자동 확장은 즉시 실행되며 리소스를 0으로 축소할 수 있습니다.
Kubernetes에 Autopilot 모드 사용
Kubernetes를 더 세부적으로 제어해야 하는 복잡한 애플리케이션의 경우 Google Kubernetes Engine (GKE)의 Autopilot 모드를 고려하세요. Autopilot 모드는 기본적으로 자동화와 확장성을 제공합니다. GKE는 트래픽에 따라 노드와 리소스를 자동으로 확장합니다. GKE는 노드를 관리하고, 애플리케이션에 새 노드를 만들고, 자동 업그레이드와 복구를 구성합니다.
모듈식 설계 촉진
Google Cloud Well-Architected Framework의 성능 최적화 요소 원칙은 모듈식 설계를 촉진하는 데 도움이 되는 권장사항을 제공합니다. 모듈식 구성요소와 명확한 인터페이스를 사용하면 유연한 확장, 독립적인 업데이트, 향후 구성요소 분리가 가능합니다.
원칙 개요
애플리케이션 구성요소와 시스템 구성요소 간의 종속 항목을 파악하여 확장 가능한 시스템을 설계합니다.
모듈식 설계를 사용하면 모놀리식 아키텍처가 처음 배포되었는지 마이크로서비스 아키텍처가 처음 배포되었는지에 관계없이 유연성과 복원력을 확보할 수 있습니다. 명확한 인터페이스가 있는 잘 정의된 독립 모듈로 시스템을 분해하면 특정 요구사항을 충족하도록 개별 구성요소를 확장할 수 있습니다.
타겟팅된 확장/축소는 다음과 같은 방식으로 리소스 사용률을 최적화하고 비용을 절감하는 데 도움이 됩니다.
- 각 구성요소에 필요한 리소스만 프로비저닝하고, 요구사항이 적은 구성요소에는 더 적은 리소스를 할당합니다.
- 트래픽이 많은 기간에 사용자 환경을 유지하기 위해 리소스를 추가합니다.
- 성능을 저하시키지 않고 사용률이 낮은 리소스를 삭제합니다.
모듈화는 유지보수성도 향상합니다. 작고 자체 포함된 단위는 이해하고 디버그하고 업데이트하기가 더 쉬우므로 개발 주기가 빨라지고 위험이 줄어들 수 있습니다.
모듈성은 상당한 이점을 제공하지만 잠재적인 성능 절충을 평가해야 합니다. 모듈 간 통신이 증가하면 지연 시간과 오버헤드가 발생할 수 있습니다. 모듈성과 성능 간의 균형을 유지하세요. 모듈성이 높은 디자인이 보편적으로 적합하지 않을 수 있습니다. 성능이 중요한 경우 더 긴밀하게 결합된 접근 방식이 적합할 수 있습니다. 시스템 설계는 모듈식 설계를 지속적으로 검토하고 개선하는 반복적인 프로세스입니다.
권장사항
모듈식 설계를 촉진하려면 다음 섹션의 권장사항을 고려하세요.
느슨한 결합을 위한 설계
느슨하게 결합된 아키텍처를 설계합니다. 종속 항목이 최소화된 독립 구성요소를 사용하면 확장 가능하고 복원력이 우수한 애플리케이션을 빌드할 수 있습니다. 서비스의 경계를 계획할 때는 가용성 및 확장성 요구사항을 고려해야 합니다. 예를 들어 한 구성요소의 요구사항이 다른 구성요소와 다른 경우 해당 구성요소를 독립형 서비스로 설계할 수 있습니다. 덜 중요한 하위 프로세스나 기본 서비스의 응답 시간에 영향을 미치지 않는 서비스에 대해 정상적인 실패 계획을 구현합니다.
동시 실행 및 동시 로드를 위한 설계
사용자가 시스템과 상호작용하는 동안 여러 사용자 요청을 처리하거나 백그라운드 작업을 실행하는 등 여러 작업을 동시에 지원하도록 애플리케이션을 설계하세요. 여러 서비스 인스턴스에서 동시에 처리할 수 있는 작은 단위로 큰 작업을 나눕니다. 태스크 동시 실행을 사용하면 자동 확장과 같은 기능을 사용하여 다음과 같은 제품에서 리소스 할당을 늘릴 수 있습니다.
유연한 리소스 할당을 위한 모듈성 균형
가능한 경우 각 구성요소가 특정 작업에 필요한 리소스(예: 메모리, 저장소, 처리 능력)만 사용하도록 합니다. 리소스 과할당은 불필요한 비용을 초래할 수 있고 리소스 부족 할당은 성능을 저하시킬 수 있습니다.
잘 정의된 인터페이스 사용
모듈식 구성요소가 명확하고 표준화된 인터페이스 (예: API 및 메시지 대기열)를 통해 효과적으로 통신하여 변환 레이어 또는 불필요한 트래픽으로 인한 오버헤드를 줄여야 합니다.
스테이트리스(Stateless) 모델 사용
스테이트리스(Stateless) 모델은 이전 요청과 관계없이 서비스에서 각 요청 또는 상호작용을 처리할 수 있게 해줍니다. 이 모델은 진행 중인 요청 또는 프로세스에 필요한 데이터가 손실되는 일 없이 서비스를 확장 또는 축소하거나 재시작할 수 있으므로, 확장성과 복구 성능에 도움을 줍니다.
상호 보완적인 기술 선택
모듈식 설계를 보완하는 기술을 선택합니다. 모듈성 지원을 위해 프로그래밍 언어, 프레임워크, 데이터베이스를 평가합니다.
자세한 내용은 다음 리소스를 참조하세요.
성능을 지속적으로 모니터링하고 개선
Google Cloud Well-Architected Framework의 성능 최적화 요소 원칙은 성능을 지속적으로 모니터링하고 개선하는 데 도움이 되는 권장사항을 제공합니다.
애플리케이션을 배포한 후 로그, 추적, 측정항목, 알림을 사용하여 성능을 지속적으로 모니터링합니다. 애플리케이션이 성장하고 발전함에 따라 이러한 데이터 포인트의 추세를 사용하여 성능 요구사항을 다시 평가할 수 있습니다. 성능을 유지하거나 개선하려면 애플리케이션의 일부를 다시 설계해야 할 수 있습니다.
원칙 개요
지속적인 성능 개선 프로세스에는 강력한 모니터링 도구와 전략이 필요합니다. 클라우드 관측 가능성 도구를 사용하면 지연 시간, 처리량, 오류율, 리소스 사용률과 같은 핵심성과지표 (KPI)를 수집할 수 있습니다. 클라우드 환경은 애플리케이션, 네트워크, 최종 사용자 환경 전반에서 세부적인 성능 평가를 수행할 수 있는 다양한 방법을 제공합니다.
성능 개선은 다각적인 접근 방식이 필요한 지속적인 노력입니다. 다음 주요 메커니즘과 프로세스를 통해 성능을 향상할 수 있습니다.
- 명확한 방향을 제시하고 진행 상황을 추적하려면 비즈니스 목표에 부합하는 실적 목표를 정의하세요. 구체적이고(Specific), 측정 가능하고(Measurable), 달성 가능하고(Achievable), 관련성이 있으며(Relevant), 기한이 정해진(Time-bound) SMART 목표를 설정하세요.
- 실적을 측정하고 개선이 필요한 영역을 파악하려면 KPI 측정항목을 수집하세요.
- 문제가 있는지 시스템을 지속적으로 모니터링하려면 모니터링 도구에서 시각화된 워크플로를 사용하세요. 아키텍처 프로세스 매핑 기법을 사용하여 중복과 비효율성을 식별합니다.
- 지속적인 개선 문화를 조성하려면 직원의 성장을 지원하는 교육과 프로그램을 제공하세요.
- 선제적이고 지속적인 개선을 장려하려면 직원과 고객이 애플리케이션 성능에 관한 지속적인 피드백을 제공하도록 인센티브를 제공하세요.
권장사항
모듈식 설계를 촉진하려면 다음 섹션의 권장사항을 고려하세요.
명확한 성능 목표 및 측정항목 정의
비즈니스 목표에 부합하는 명확한 성능 목표를 정의합니다. 이를 위해서는 애플리케이션 아키텍처와 각 애플리케이션 구성요소의 성능 요구사항을 깊이 이해해야 합니다.
우선순위에 따라 핵심 비즈니스 기능과 사용자 환경에 직접적인 영향을 미치는 가장 중요한 구성요소를 최적화하세요. 이러한 구성요소가 계속해서 효율적으로 실행되고 비즈니스 요구사항을 충족하도록 하려면 구체적이고 측정 가능한 실적 타겟을 설정하세요. 이러한 타겟에는 응답 시간, 오류율, 리소스 사용률 기준점이 포함될 수 있습니다.
이러한 사전 대응적 접근 방식을 통해 잠재적인 병목 현상을 식별하고 해결하며, 리소스 할당을 최적화하고, 궁극적으로 사용자에게 원활하고 고성능의 환경을 제공할 수 있습니다.
실적 모니터링
클라우드 시스템의 성능 문제를 지속적으로 모니터링하고 잠재적인 문제에 대한 알림을 설정합니다. 모니터링 및 알림을 사용하면 문제가 사용자에게 영향을 미치기 전에 문제를 포착하고 해결할 수 있습니다. 애플리케이션 프로파일링은 병목 현상을 식별하고 리소스 사용을 최적화하는 데 도움이 될 수 있습니다.
효과적인 문제 해결 및 네트워크 최적화를 지원하는 도구를 사용할 수 있습니다. Google Cloud Observability를 사용하여 CPU 소비, 메모리 소비 또는 네트워크 소비가 높은 영역을 식별합니다. 이러한 기능을 통해 개발자는 효율성을 개선하고, 비용을 절감하고, 사용자 환경을 개선할 수 있습니다. Network Intelligence Center는 네트워크 인프라의 토폴로지를 시각화하여 보여주며, 지연 시간이 긴 경로를 식별하는 데 도움이 됩니다.
지속적인 개선 장려
애플리케이션과 사용자 환경 모두에 도움이 되는 지속적인 개선 문화를 만드세요.
직원에게 클라우드 서비스 전반의 성능 기술에 대한 기술과 지식을 향상할 수 있는 교육 및 개발 기회를 제공하세요. 실무 커뮤니티 (CoP)를 구축하고 직원 성장을 지원하기 위한 멘토링 및 코칭 프로그램을 제공합니다.
사후 대응 성과 관리를 방지하고 사전 대응 성과 관리를 장려하려면 직원, 고객, 이해관계자로부터 지속적인 피드백을 받으세요. 실적에 대한 KPI를 추적하고 리그 테이블 형식으로 이러한 측정항목을 팀에 자주 표시하여 프로세스를 게임화하는 것을 고려해 볼 수 있습니다.
시간이 지남에 따라 실적과 사용자 만족도를 파악하려면 사용자 의견을 정량적 및 정성적으로 측정하는 것이 좋습니다. HEART 프레임워크는 다음 다섯 가지 카테고리에 걸쳐 사용자 의견을 수집하는 데 도움이 됩니다.
- 행복
- 참여
- 채택 현황
- 보관
- 작업 성공
이러한 프레임워크를 사용하면 데이터 기반 피드백, 사용자 중심 측정항목, 실행 가능한 통계, 명확한 목표 이해를 통해 엔지니어에게 인센티브를 제공할 수 있습니다.