AppExchange 제품 아키텍처: 아이디어에서 출시까지

상황

Salesforce ISV 파트너인 CrossTalent는 AppExchange를 위한 네이티브 HR 애플리케이션을 만들고 있었습니다. 고객의 Salesforce 조직 안에서 돌아가며 직원 라이프사이클, 성과 관리, HR 프로세스 자동화를 처리하는 종합 HR 관리 제품이었습니다. 이 프로젝트는 초기 콘셉트와 시장 검증에서 아키텍처, 개발, Salesforce 보안 심사, AppExchange 출시까지 제품 라이프사이클 전체를 아울렀습니다.

ISV 제품 개발과 표준 Salesforce 구현 작업의 차이는 근본적입니다. 제품은 한 고객의 조직을 위해 만들어지지 않았습니다. 각자의 설정, 보안 모델, 데이터 볼륨, 커스터마이징 계층을 가진 수천 개의 서로 다른 조직 안에서 돌아갈 것이었습니다. 모든 아키텍처 결정이 그 운영 현실을 염두에 두고 내려져야 했습니다. 데이터 모델은 고객 조직의 형태를 가정할 수 없었습니다. 연동 지점은 모든 고객의 기존 연결에 걸쳐 유연해야 했습니다. 업그레이드 경로는 첫 릴리스부터 계획되어야 했습니다. 고객은 버전이 올라갈 때마다 처음부터 다시 배포하지 않을 것이기 때문입니다.

과제

AppExchange 위에서 만드는 일은 모든 층위에서 구현과 다른 아키텍처 사고방식을 요구합니다.

플랫폼 제약은 더 까다롭고 더 무겁습니다. 단일 테넌트 구현에서 우회할 수 있는 governor limit은 managed package 안에서 넘을 수 없는 경계가 됩니다. 한 고객 조직에서 heap 한계에 근접하는 트리거가 다른 조직에서는 그것을 넘길 수 있습니다. 한 고객의 데이터 볼륨에서 받아들일 만한 성능을 내는 쿼리가 다른 고객의 볼륨에서는 실패할 수 있습니다. 아키텍처는 평균이 아니라 가장 까다로운 현실적 배포의 제약에 맞춰 설계되어야 했습니다.

보안 심사는 다른 종류의 검증을 부과했습니다. Salesforce는 출시 전에 종합 보안 체크리스트를 기준으로 AppExchange 패키지를 평가합니다. SOQL 인젝션, XSS, CRUD/FLS 적용, 공유 모델 준수, namespace 격리, 그리고 플랫폼 특화 보안 패턴 일체. 심사를 통과하는 패키지는 그저 검토된 게 아닙니다. 심사가 수월하도록 설계된 것입니다. 보안은 개발 이후에 덧붙일 수 없습니다. 첫 설계 결정에서부터 아키텍처로 잡아야 합니다.

namespace 격리 요건은 데이터 모델의 모든 측면을 좌우했습니다. managed package의 오브젝트, 필드, 코드는 고객 조직과 별개의 namespace에 자리합니다. 모든 참조는 namespace를 의식해야 했고, 모든 연동 지점은 managed 코드와 unmanaged 코드 사이의 경계를 위해 설계되어야 했으며, 모든 업그레이드 경로는 초기 릴리스부터 계획되어야 했습니다. namespace 규율을 사후에 추가하는 일은 리팩터링이 아닙니다. 재구축입니다.

아키텍처 킥오프에서 제품 팀에 한 말

이 제품은 다른 누군가의 조직 안에서 돌아갑니다. 그 제약은 우리가 협상할 대상이 아닙니다. 규율이란 모든 governor limit, 모든 공유 규칙, 모든 namespace 경계가 프로덕션에서 시험받으리라 여기고 설계하는 것입니다. 실제로 시험받을 것이기 때문입니다.

실행

개발자 세 명으로 이뤄진 팀이 아키텍처 명세에 맞춰 개념 증명을 수행한 뒤 패키지 전체 개발을 진행했습니다. 패키지가 Salesforce 보안 심사에 도달했을 때 지적 사항은 사소했습니다. 아키텍처는 보완 이후가 아니라 처음부터 통과하도록 설계되어 있었습니다. managed package는 문서, 구현 가이드, 지원 자료를 포함한 등록 정보와 함께 AppExchange에 출시되었습니다. 가능한 한 고객 셀프서비스를 가능하게 하고 판매 후 구현 부담을 줄이도록 설계된 자료였습니다.

성과

네이티브 HR 애플리케이션은 Salesforce AppExchange에 출시되었습니다. 아이디어에서 시장까지 이르는 제품 라이프사이클 전체에 14개월이 걸렸습니다. Salesforce 보안 심사는 큰 보완 없이 통과했습니다. 표준화된 애자일 개발 프로세스는 비구조적 개발의 기준선 추정 대비 시장 진입 속도 3배 가속을 이뤄 냈습니다.

아키텍처는 개발 팀의 누구도 본 적 없는 고객 조직 안에서 버텼습니다. governor limit은 가장 무거운 현실적 데이터 볼륨에서도 걸리지 않았습니다. 공유 모델은 모든 고객의 기존 보안 설정에서 살아남았습니다. namespace 격리는 초기 출시 이후 뒤따른 업그레이드 릴리스에 걸쳐 버텼습니다.

AppExchange 제품 아키텍처는 구현 작업이 좀처럼 요구하지 않는 수준의 플랫폼 지식을 강제합니다. governor limit, 보안 모델, namespace 격리, 멀티 테넌트 배포 제약. 이것들은 구현 아키텍트가 이론으로 알고 ISV 아키텍트가 실전으로 아는 플랫폼의 기초입니다.

돌아보며

이 패턴은 제품 팀이 아키텍처가 개발과 병렬이 아니라 그 상류에 있다는 것을 받아들일 때 작동합니다. 개념 증명이 2주 앞으로 다가왔을 때, 코드 한 줄이 출시되기 전에 namespace, 공유, governor 전략을 정의하는 비용은 과해 보입니다. 그것은 제품이 사들일 가장 값싼 설계 규율입니다. 보안 심사 피드백 이후에 그것을 덧붙이는 비용은 단지 더 느린 데서 그치지 않습니다. 이미 출시된 코드를 둘러싸고 재설계해야 하는 경우가 잦습니다.

ISV가 AppExchange를 표준 배포 채널처럼 굴기를 기대할 때는 덜 작동합니다. AppExchange는 마켓플레이스가 아닙니다. 플랫폼 계약입니다. 등록을 따내는 규율이, 제품이 규모에서 살아남을지를 결정하는 규율입니다.

더 일찍 했어야 할 것은 프로세스 변형에 대한 고객 디스커버리입니다. ISV 제품의 출시 후 재작업을 일으키는 가장 큰 원천은, 팀이 하드코딩할 수 있다고 가정했지만 고객 기반이 실제로는 설정 가능하기를 원했던 프로세스 변형입니다. 아키텍처 단계의 디스커버리는 2년 차의 메이저 릴리스 한 사이클을 아낍니다.

이 플랫폼 수준의 지식은 Agentforce 아키텍처로 그대로 이어집니다. 에이전트는 동일한 플랫폼 제약 안에서 작동합니다. governor limit은 에이전트가 호출하는 Apex에 적용되고, 보안 모델은 에이전트가 누구를 대신해 어떤 데이터에 접근하는지를 다스리며, 플랫폼의 신뢰 아키텍처는 에이전트가 어떤 맥락에서 어떤 행동을 할 수 있는지를 정합니다. 샌드박스에서 작동하는 에이전트가 데이터 볼륨이 governor limit에 닿으면 프로덕션에서 실패할 수 있습니다. 보안 모델 밖의 데이터에 접근하는 prompt 템플릿은 감사 전까지 드러나지 않을 수 있는 컴플라이언스 위반을 만듭니다. AppExchange 위에서 만드는 일은, 플랫폼 제약이 적용되지 않으리라 가정하는 게 아니라 그 제약 안에서 설계하는 법을 가르칩니다. 그것이 프로덕션에서 안정적으로 작동하는 Agentforce 에이전트와 데모에서만 작동하는 에이전트의 차이입니다.