SaaS 방식으로 제공하기

학습 목표

이 유닛을 완료하면 다음을 수행할 수 있습니다.

• 제품의 단일 버전을 배포하고 유지 관리할 때의 이점에 대해 논의할 수 있습니다.
• 원활하게 업데이트를 배포하는 방법을 설명할 수 있습니다.

Salesforce 플랫폼의 약속

Salesforce 고객은 많은 혜택을 누린다는 사실을 잘 압니다. 서버를 유지 관리하거나 운영 체제에 손댈 필요가 없고, 관계형 데이터베이스를 설계, 실행 또는 최적화하는 방법을 알 필요도 없습니다. 심지어 데이터를 직접 백업할 필요도 없습니다.

Salesforce 고객은 새로운 기능과 성능 개선이 포함된 주요 소프트웨어 릴리스를 연간 3회 제공받습니다. 방대한 릴리스 노트와 교육 자료(예: 이 Trailhead 모듈)도 제공받습니다. 또한 Salesforce와 원활하게 연동되는 제품 마켓플레이스인 AppExchange를 이용할 수 있습니다. 비즈니스에 필요한 모든 것을 즉시 사용할 수 있습니다.

높은 기대치

보셨나요? 엔터프라이즈 소프트웨어는 사용이 어려울 필요가 없습니다. 누구나 '쉽게 활용'할 수도 있습니다. 이것이 바로 SaaS(Software as a Service)의 약속입니다. Salesforce는 20년 넘게 고객과의 그러한 약속을 지켜왔습니다. Salesforce Platform의 주 업그레이드도 매우 원활하고 조용히 이루어집니다.

여러분의 고객들은 여러분이 Salesforce 플랫폼에서 빌드하는 제품에 대한 높은 기대치를 가지고 있습니다. 성공한 제품이라는 인식을 갖습니다! 따라서 SaaS의 약속을 지키는 방식으로 고객에게 제품 업데이트를 제공하는 방법은 무엇일까요?

업데이트 전략 선택

업데이트는 다양한 형태로 제공됩니다. 패치는 가장 작은 형태의 업데이트로, 버그를 수정하고 제품을 약간 조정합니다. 새로운 주/부 패키지 버전 릴리스는 변경의 큐모가 더욱 큰 업데이트입니다.

제품을 업데이트할 때 고객이 새로운 버전을 받는 방식을 선택할 수 있습니다. 고객은 다음의 두 가지 방식으로 업데이트를 받을 수 있습니다.

• 수동 설치—고객이 새 버전을 원하는 시기를 결정하고, 여러분이 제공한 URL을 사용하여 설치합니다.
• 자동 설치—고객에게 항상 최신 버전의 제품을 제공하고 모두가 항상 동일한 버전을 사용하도록 업데이트를 푸시합니다. 이 방식을 푸시 업그레이드라고 합니다.

이 시점에서 Salesforce가 셀프 서비스 옵션을 제공하는 이유가 궁금할 것입니다. 셀프 서비스 옵션은 Salesforce가 자체 릴리스를 수행하는 방식이 아니고, 확실히 '원활'하지도 않습니다. Salesforce 방식으로 모두에게 업데이트를 제공하지 않는 이유는 무엇일까요?

사실, Salesforce는 로우 드라마(low-drama) 업그레이드로 오랜 기간 성공을 거두었습니다. 고객은 Salesforce가 릴리스를 올바르게 수행하고, 프로세스에서 발생하는 문제를 신속하게 수정할 수 있다고 믿습니다. 하지만 이러한 동일한 고객 중 일부는 Salesforce 파트너의 자동 업데이트에 익숙해질 때까지 좀 더 설득이 필요합니다.

좋은 소식이 널리 퍼질 수 있도록 푸시 업그레이드의 장점에 대해 이야기해 보겠습니다.

푸시 업그레이드로 간편하게 관리하기

가능하면 푸시 업그레이드를 사용하여 새로운 버전의 제품을 배포하고, 수동 설치를 주장하는 고객에 대해서만 셀프 서비스 업데이트를 사용하는 것이 좋습니다.

푸시 업그레이드는 모든 고객이 동일한 버전의 애플리케이션을 사용하도록 보장합니다. 이는 기업과 고객 모두에게 좋습니다. 그 이유는 무엇일까요? 애플리케이션의 여러 활성 버전 지원을 지원하는 경우를 생각해보세요. 여러 버전을 유지 관리하면 상황이 복잡해집니다.

• 지원팀은 고객 문제에 적절하게 대응할 수 있도록 각 버전의 기능과 수정 사항을 추적해야 합니다.
• 여러분은 여러 버전의 문서 및 교육 자료를 유지 관리해야 합니다.
• 버그를 수정할 경우 여러 버전으로 백포팅해야 할 수 있습니다.

이와 반대로, 푸시 업그레이드로 고객을 최신 상태로 유지하면 이러한 추가 작업을 모두 피할 수 있습니다.

약속 지키기

식상한 얘기처럼 들릴 수도 있겠지만, 앱이나 고객 조직을 망쳐서는 안 됩니다. 물론 고객의 일과를 방해하지 않고 제품을 업데이트하는 것은 어려울 수 있습니다. Salesforce는 원활한 업데이트 제공을 위해 여러 가지 편리한 도구와 지침을 제공합니다.

프로세스 자동화

새 제품 버전이 설치될 때 업데이트로 인해 여러분이 고객 조직에서 일부 작업을 수행해야 하는 경우가 있습니다. 일부 데이터를 검증하거나, 설치 후 조직에서 일부 정리 작업을 수행해야 할 수 있습니다.

앱에 이러한 작업을 수행하는 버튼을 포함할 수 있지만, 고객이 누르지 않으면 아무 효과도 없습니다. 고객을 참여시키는 것보다는 설치하는 동안 작업을 자동으로 수행하는 것이 좋습니다. 패키지를 개발할 때 이를 위한 스크립트를 포함하세요. 스크립트는 데이터와 특정 메타데이터를 업데이트할 수 있습니다.

예를 들어 필드에 저장된 값을 계산하는 일부 Apex 코드에서 버그를 발견했다고 가정해보겠습니다. 업데이트의 일부로, 버그를 수정할 뿐만 아니라 버그 수정 전에 생성된 모든 잘못된 값도 수정하는 스크립트를 실행할 수 있습니다.

철저한 사전 테스트

앞서 로우 드라마(low-drama) 릴리스 및 업데이트에 대한 Salesforce의 인상적인 성과에 대해 언급했습니다. 그 비결은 무엇일까요? 비결은 철저한 테스트입니다. 아주 흥미롭지는 않지만, 효과는 확실합니다. 테스트가 많을수록 드라마, 즉 극적인 상황이 줄어듭니다.

때때로 파트너는 멋진 새 기능에 너무 집중한 나머지, 업데이트를 테스트하는 동안 몇 가지 세부 사항을 건너뜁니다. 불완전한 테스트 절차의 예를 들어보겠습니다. 여러분은 새로 생성된 빈 테스트 조직에 업그레이드된 앱을 설치합니다. 잘 동작한다면 출시해도 괜찮습니다. 모든 고객이 새로운 조직으로 시작하는 경우에는 그렇습니다.

하지만 대부분의 실제 고객들은 언제 바쁜 업무를 처리하고 있으며, 이미 수많은 요소가 포함된 조직에 업그레이드를 설치할 것입니다. 따라서 혼잡한 조직과 말끔한 조직 모두에서 업그레이드를 테스트하세요.

원활하고 조용한 업데이트 배포

고객은 소프트웨어가 스스로 업데이트되는 동안 업무를 '일시 중단'할 수 없습니다. 이는 SaaS 약속에 포함된 사항이 아닙니다. 모든 것이 실패하지 않도록 보장할 수는 없지만, 업데이트가 고객에게 미치는 영향을 잘 생각하면 혼란을 최소화할 수 있습니다.

• 업데이트의 영향을 고려하세요. 고객이 제품을 사용하는 방식을 바꾸려고 하나요?
• 먼저 내부적으로 변경 사항을 테스트하세요. 비어 있는 새로운 조직뿐만 아니라, 이미 채워져 있는 다양한 테스트 조직을 사용해야 합니다.
• 배포 시 계층을 사용하는 것을 고려하세요. 예를 들어 파워 유저가 나머지 사용자보다 업데이트를 먼저 받도록 할 수 있습니다. Salesforce는 이 프로세스를 사용하여 실제 고객에 대한 영향을 파악합니다.

이제 업데이트를 제공하는 다양한 방법을 살펴보겠습니다.

리소스

• 2세대 관리 패키징 개발자 가이드: 2세대 관리 패키지 버전 만들기 및 업데이트
• 2세대 관리 패키징 개발자 가이드:  패키지 설치/업그레이드 시 Apex 실행