안녕하세요 트레슬입니다.
지난 2월 23일 전체 사용자 운영 환경에 적용된 Salesforce Spring ’26은 새 기능이 얼마나 추가되었나보다, 운영팀 관점에서 봄맞이 운영 대청소가 필요한가를 먼저 고민하게 만드는 릴리즈에 가깝다고 생각합니다.
이번 릴리즈의 핵심 흐름을 운영 관점에서 정리해 보자면,
그래서 이번 포스팅은 기능 목록을 나열하기 보다, 관리자·운영팀·CRM 오너 등 실무자가 무엇을 먼저 결정하고, 무엇을 우선 점검해야 하는지를 트레슬의 관점에서 핵심만 정리했습니다.
1. 실무자가 체감할 Spring '26 변화 방향 5가지
① Agentforce 중심 전환 : 기능이 아닌 일하는 방식의 변화
Spring ’26을 관통하는 키워드는 단연 Agentforce입니다.
Release 페이지와 하이라이트 자료에서도, Sales·Service 등 주요 제품군이 Agentforce 브랜드 아래에서 AI 에이전트 기반으로 재편되는 흐름이 전면에 드러납니다.
트레슬은 이 변화를 CRM 기능이 조금 늘어난 것이 아니라, 업무 단위가 에이전트 실행 단위로 재구성되는 전환으로 해석합니다.
실무자의 관점에서 중요한 질문은 다음 두 가지인데요, Agentforce에게 업무를 어디까지 맡기고 어떻게 감시할지에 대한 운영 원칙이 먼저 정리되어야 합니다.
② 연동(Integration) 기본값 보수화 : 연동이 된다 → 연동을 표준화·통제할 수 있을까?
Spring ’26 이후 통합(Integration)은 개발 산출물의 영역을 넘어, 운영팀이 직접 관리해야 하는 핵심 자산으로 더 강하게 이동하는 분위기입니다.
대표적으로,
즉, 이번 릴리즈는 연동을 추가하는 시기라기보다, 연동 인벤토리와 표준을 다시 쓰는 시점으로 접근하는 것이 안전합니다.
③ Flow 운영의 중심 이동 : 제작하는 능력 → 품질관리(검증·승인·관찰)
Spring ’26에서는 Agentforce와 Flow가 긴밀하게 연결되면서, Flow를 만드는 것은 점점 쉬워집니다.
이제 운영팀의 핵심 역량은 Flow 제작이 아니라, Flow 운영 품질 관리로 이동합니다.
배포 기준 설정
리뷰·승인 프로세스
Fault Path 설계
롤백 전략
모니터링 기준
AI가 Flow를 빨리 만들어 줄수록, 사람이 관리해야 할 운영 거버넌스의 중요도는 더 올라갑니다.
④ 운영 가시성(Observability) 강화 : 다운보다 조용한 누락이 더 위험합니다.
Agentforce·Flow·자동화가 늘어날수록, 실무자가 가장 두려워해야 하는 것은 시스템 전체 다운보다 모르는 사이에 조금씩 누락되는 품질 저하입니다.
Spring ’26 하이라이트에서는 문제가 생기면 찾는다가 아닌, 문제가 커지기 전에 오류 흔적을 먼저 잡는 운영 체계로 전환하라는 메시지를 전달하고 있습니다.
⑤ 되돌릴 수 없음/깨짐 가능성의 명확화 : 설정은 버튼이 아니라 의사결정(CAB/승인)
운영에서 가장 비용이 크게 발생하는 순간은 한번 설정을 켰는데 다시 되돌릴 수 없는 경우입니다.
Spring ‘26에서도 다음과 같은 유형에 대해 주의를 강조하고 있습니다.
레거시 도메인/URL 지원 종료에 따른 연동 영향
보안·인증 구조 강화로 인한 기존 통합의 간헐적인 실패
UI/데이터 구조 변경으로 인한 기존 사용자/프로세스의 혼란
이런 유형의 변경은 단순한 설정 변경이 아니라 CAB(변경 승인) 대상으로 격상하고, 반드시 샌드박스에서 영향도를 먼저 검증하고 승인 루트를 거친 후에 실제 운영 환경에 적용하는 루틴이 필요합니다.
2. 지금 당장 청소해야 할 필수 체크리스트 5가지
이번 릴리즈 적용 시 연동 장애·운영 사고로 이어질 수 있는 항목만 운영 대청소 체크리스트로 정리해 보았습니다.
아래 지금 할 일 컬럼을 실제 체크리스트로 복사해 실무에 적용해 보세요.
| 항목 | 변경 내용 (실무 요약) | 지금 할인 |
|---|
외부 연동 앱 신규 생성 방식 변화
| 새 표준인 External Client Apps(ECA) 중심으로 신규 연동을 설계하는 흐름이 강화되고, 기존 Connected App은 유지되지만 신규 생성·확장에는 제약이 늘어날 수 있습니다.
| ① 현재 사용 중인 모든 연동을 인벤토리로 정리하고
② “신규 연동 표준(ECA 중심 설계)”을 내부 문서로 확정합니다.
|
레거시 도메인·URL 점검
| 레거시 호스트명/URL 기반 접근은 Spring ’26 이후 지원 종료·제한에 따라 연동 장애로 이어질 수 있습니다.
| 현재 사용 중인 URL·호스트명을 목록화하고, 릴리즈 노트의 레거시 호스트/도메인 관련 항목과 교차 확인합니다.
|
통화·영상 분석(ECI) 데이터 저장 구조 변경
| Einstein Conversation Insights 등 일부 통화/영상 분석 데이터의 저장·활용 방식이 Native 저장으로 이동하는 흐름이 있어, 일정·전환 전략이 필요합니다.
| 조직 내에서 “전환 목표 일정”을 먼저 확정하고, 보안·콜센터·CRM 오너 등 이해관계자와 합의를 만듭니다.
|
Microsoft 365 인증 방식 전환
| Microsoft 측 EWS(Exchange Web Services) 종료 일정(2026년 10월 예정)에 따라, Outlook/Exchange 연동을 Graph 기반으로 전환해야 합니다.
| “메일/캘린더/활동” 연동이 걸려 있는 업무부터 리스트업하고, 각 업무별로 영향도와 전환 계획을 수립합니다.
|
보안 인증서 운영 자동화
| 인증서 만료·갱신을 사람에 의존하면, 보안 강화·통합 구조 변화와 맞물려 운영 리스크가 크게 증가합니다.
| 인증서 갱신 주기·알림 체계를 점검하고, 가능한 범위에서 자동화·모니터링을 도입해 “사람 의존”을 줄입니다.
|
3. 운영 리스크 레지스터
실무자는 기능 설명보다 리스크/징후/대응이 있어야 움직일 수 있습니다.
조직 규모와 무관하게 반복 발생하는 이슈를 중심으로 정리한 운영 리스크 레지스터를 확인해보세요.
구분
| 리스크 징후
| 권장
| 대응
|
|---|
연동/보안
| 신규 연동 표준(ECA) 정착 지연 → 새 연동 프로젝트 일정 지연
| 연동 설계 단계에서 승인 기준·표준 부재로 논의가 계속 막힘
| 신규 연동 표준(ECA 기반 설계 원칙)을 문서화하고, 기존 연동 인벤토리를 먼저 작성한 뒤 전환 우선순위를 설정합니다.
|
연동/보안
| Outbound/Legacy 인증 구조 변경으로 레거시 연동에서 간헐적 실패 발생
| 특정 외부 시스템으로의 호출이 간헐적으로 실패·지연, 로그에서 인증 관련 오류 증가
| 가능한 범위에서 OAuth 기반으로 전환하는 로드맵을 만들고, 영향 시스템(매출·고객 서비스 핵심 시스템)을 우선순위로 전환합니다.
|
| 서비스 운영 | 되돌릴 수 없는 설정/플랫폼 변경으로 운영 부채 발생
| 특정 시점 이후부터만 동작이 달라지거나 되돌리기 불가능해짐
| 영향도 분석 없이 켜는 설정을 없애고, CAB 승인 + 샌드박스 영향도 분석을 “전환 전 필수”로 명문화합니다.
|
| 이메일 운영 | OWA 검증·발신 정책 미정비로 메일 발송 실패·스팸 처리
| 케이스 이메일이 간헐적으로 실패하거나 고객에게 도달하지 않음
| OWA·발신 도메인·SPF/DKIM/DMARC 등을 점검하고, “이메일 운영 체크리스트”에 포함해 정기적으로 검토합니다.
|
| 운영/권한 | 공유(Sharing) 재계산 타이밍과 자동화가 충돌해 간헐 오류
| 권한 변경 직후 특정 사용자 접근 실패, Flow/에이펙스에서 예외 발생
| 샌드박스에서 동일 상황을 재현 테스트하고, 공유 타이밍에 의존하는 로직은 재설계합니다. 필요한 경우 Queue·비동기 처리로 분리합니다.
|
4. 이번 주에 실행해 보아야할, 7일 운영 대청소 루틴
5. 트레슬이 Salesforce Spring ‘26을 바라보는 관점
Spring ’26을 잘 적용한 조직은 새 기능을 가장 빨리 활성화한 조직이 아니라, 다음 네 가지를 먼저 내부적으로 정리·합의한 조직이라고 봅니다.
정리해보면, Spring ’26은 새 기능을 조금 더 추가한 릴리즈가 아니라 Agentforce 시대를 대비한 운영 체계 업그레이드 기회가 될 수 있습니다
6. 추가적으로 더 학습하고 싶으시다면?
Spring ‘26에 대한 자세한 기능 및 상세 스펙은 아래 자료를 함께 참고해 보시는 것을 권장드립니다.
안녕하세요 트레슬입니다.
지난 2월 23일 전체 사용자 운영 환경에 적용된 Salesforce Spring ’26은 새 기능이 얼마나 추가되었나보다, 운영팀 관점에서 봄맞이 운영 대청소가 필요한가를 먼저 고민하게 만드는 릴리즈에 가깝다고 생각합니다.
이번 릴리즈의 핵심 흐름을 운영 관점에서 정리해 보자면,
연동·보안 기본값이 더 보수적으로 설계되고,
Agentforce와 Flow를 중심으로 자동화가 훨씬 빠르게 확산될 수 있으며,
일부 설정·플랫폼 변경은 되돌리기 어렵거나 레거시에 영향을 줄 수 있어, 설치/활성화보다 결정·검증이 먼저 필요한 릴리즈입니다.
그래서 이번 포스팅은 기능 목록을 나열하기 보다, 관리자·운영팀·CRM 오너 등 실무자가 무엇을 먼저 결정하고, 무엇을 우선 점검해야 하는지를 트레슬의 관점에서 핵심만 정리했습니다.
1. 실무자가 체감할 Spring '26 변화 방향 5가지
① Agentforce 중심 전환 : 기능이 아닌 일하는 방식의 변화
Spring ’26을 관통하는 키워드는 단연 Agentforce입니다.
Release 페이지와 하이라이트 자료에서도, Sales·Service 등 주요 제품군이 Agentforce 브랜드 아래에서 AI 에이전트 기반으로 재편되는 흐름이 전면에 드러납니다.
트레슬은 이 변화를 CRM 기능이 조금 늘어난 것이 아니라, 업무 단위가 에이전트 실행 단위로 재구성되는 전환으로 해석합니다.
실무자의 관점에서 중요한 질문은 다음 두 가지인데요, Agentforce에게 업무를 어디까지 맡기고 어떻게 감시할지에 대한 운영 원칙이 먼저 정리되어야 합니다.
어떤 업무까지 에이전트에게 위임할 것인가? (업무 위임 범위)
에이전트가 처리한 결과를 어떻게 통제·감시할 것인가? (권한·감사·승인, Agent Health 모니터링 등)
② 연동(Integration) 기본값 보수화 : 연동이 된다 → 연동을 표준화·통제할 수 있을까?
Spring ’26 이후 통합(Integration)은 개발 산출물의 영역을 넘어, 운영팀이 직접 관리해야 하는 핵심 자산으로 더 강하게 이동하는 분위기입니다.
대표적으로,
신규 통합은 External Client Apps(ECA)라는 새로운 표준으로 설계하는 흐름이 강화되고,
기존 Connected App 기반 연동은 당장 꺼지지는 않지만, 새로 만들기는 점점 제한되고, 향후 ECA로의 전환이 권장되는 방향입니다.
레거시 호스트명/도메인, 오래된 인증 구조를 사용하는 연동은 Spring ’26 이후 점진적으로 지원 종료·제한 리스크가 커집니다.
즉, 이번 릴리즈는 연동을 추가하는 시기라기보다, 연동 인벤토리와 표준을 다시 쓰는 시점으로 접근하는 것이 안전합니다.
③ Flow 운영의 중심 이동 : 제작하는 능력 → 품질관리(검증·승인·관찰)
Spring ’26에서는 Agentforce와 Flow가 긴밀하게 연결되면서, Flow를 만드는 것은 점점 쉬워집니다.
자연어로 Flow를 설계·개선하고,
파일, 화면 컴포넌트, 에러 메시지 표현 등 Flow 경험이 강화됩니다.
이제 운영팀의 핵심 역량은 Flow 제작이 아니라, Flow 운영 품질 관리로 이동합니다.
배포 기준 설정
리뷰·승인 프로세스
Fault Path 설계
롤백 전략
모니터링 기준
AI가 Flow를 빨리 만들어 줄수록, 사람이 관리해야 할 운영 거버넌스의 중요도는 더 올라갑니다.
④ 운영 가시성(Observability) 강화 : 다운보다 조용한 누락이 더 위험합니다.
Agentforce·Flow·자동화가 늘어날수록, 실무자가 가장 두려워해야 하는 것은 시스템 전체 다운보다 모르는 사이에 조금씩 누락되는 품질 저하입니다.
Spring ’26 하이라이트에서는 문제가 생기면 찾는다가 아닌, 문제가 커지기 전에 오류 흔적을 먼저 잡는 운영 체계로 전환하라는 메시지를 전달하고 있습니다.
에이전트 오류율·지연·에스컬레이션을 추적하는 Agent Health Monitoring
데이터가 어디서 와서 어디에 쓰이는지 파악하는 Data 360 Unified Lineage
⑤ 되돌릴 수 없음/깨짐 가능성의 명확화 : 설정은 버튼이 아니라 의사결정(CAB/승인)
운영에서 가장 비용이 크게 발생하는 순간은 한번 설정을 켰는데 다시 되돌릴 수 없는 경우입니다.
Spring ‘26에서도 다음과 같은 유형에 대해 주의를 강조하고 있습니다.
레거시 도메인/URL 지원 종료에 따른 연동 영향
보안·인증 구조 강화로 인한 기존 통합의 간헐적인 실패
UI/데이터 구조 변경으로 인한 기존 사용자/프로세스의 혼란
이런 유형의 변경은 단순한 설정 변경이 아니라 CAB(변경 승인) 대상으로 격상하고, 반드시 샌드박스에서 영향도를 먼저 검증하고 승인 루트를 거친 후에 실제 운영 환경에 적용하는 루틴이 필요합니다.
2. 지금 당장 청소해야 할 필수 체크리스트 5가지
이번 릴리즈 적용 시 연동 장애·운영 사고로 이어질 수 있는 항목만 운영 대청소 체크리스트로 정리해 보았습니다.
아래 지금 할 일 컬럼을 실제 체크리스트로 복사해 실무에 적용해 보세요.
② “신규 연동 표준(ECA 중심 설계)”을 내부 문서로 확정합니다.
3. 운영 리스크 레지스터
실무자는 기능 설명보다 리스크/징후/대응이 있어야 움직일 수 있습니다.
조직 규모와 무관하게 반복 발생하는 이슈를 중심으로 정리한 운영 리스크 레지스터를 확인해보세요.
4. 이번 주에 실행해 보아야할, 7일 운영 대청소 루틴
Day 1–2 : 배관 지도 그리기 (연동 인벤토리 만들기)
Connected App / External Client Apps(ECA), Outbound Message, 주요 외부 시스템 연동 경로를 전부 나열해 연동 지도를 만듭니다.
연동 인벤토리가 없으면, 어떤 전환도 안전하게 실행하기 어렵습니다.
Day 3–4 : 곰팡이 찾기(샌드박스에서 깨질 수 있는 지점 재현 테스트)
되돌릴 수 없는 설정 후보, 공유·권한 변경 직후 발생할 수 있는 오류, 핵심 Flow의 Fault Path를 샌드박스에서 실제로 재현·테스트합니다.
이론상 위험이 아닌, 구체적으로 어디서 깨지는지를 확인해 둡니다.
Day 5 : 정리함 라벨 붙이기 (운영 정책을 1장으로 문서화)
신규 연동 표준(ECA 기준), 자동화 배포 기준(Flow 승인 프로세스), CAB/승인 루트를 A4 1장 안에 정리합니다.
운영팀·개발팀·비즈니스 오너가 이 문서를 기준으로 합의할 수 있도록 만듭니다.
Day 6–7 : 유지관리 루틴 만들기 (Flow 품질관리 룰 3개 도입)
다음 세 가지만 도입해도, 운영 사고를 체감적으로 줄일 수 있습니다.
Flow 리뷰·승인 필수화 (중요 객체/프로세스용 Flow는 반드시 2인 이상 검토)
Fault Path 설계 의무화 (에러 메시지·알림·로그 남기기)
핵심 자동화 월간 점검 (오류 건수·성능 지표를 월 1회 정기 검토)
5. 트레슬이 Salesforce Spring ‘26을 바라보는 관점
Spring ’26을 잘 적용한 조직은 새 기능을 가장 빨리 활성화한 조직이 아니라, 다음 네 가지를 먼저 내부적으로 정리·합의한 조직이라고 봅니다.
신규 연동 표준
새 연동은 ECA 기준으로 설계·전환할 것인가?
기존 Connected App 연동은 어느 구간까지 유지하고, 언제부터 전환을 고려할 것인가?
자동화 배포 기준(Flow 거버넌스)
Flow를 누가 승인할 것인가?
어떤 체크리스트(테스트, Fault Path, 성능, 권한)를 기준으로 운영할 것인가?
되돌릴 수 없는 설정의 승인 체계
되돌리기 어려운 설정·플랫폼 변경을 어떻게 식별할 것인가?
CAB/승인 루트를 어떤 수준의 변경부터 의무화할 것인가?
운영 가시성(모니터링·리니지)
에이전트/자동화의 오류·지연·원인 추적을 어느 수준까지 운영 항목으로 포함할 것인가?
어떤 지표를 정기적으로 보고하고, 어디까지를 ‘운영 팀의 책임 범위’로 둘 것인가?
정리해보면, Spring ’26은 새 기능을 조금 더 추가한 릴리즈가 아니라 Agentforce 시대를 대비한 운영 체계 업그레이드 기회가 될 수 있습니다
6. 추가적으로 더 학습하고 싶으시다면?
Spring ‘26에 대한 자세한 기능 및 상세 스펙은 아래 자료를 함께 참고해 보시는 것을 권장드립니다.
Salesforce Admin 블로그 확인하기
Salesforce Developer 블로그 확인하기
Salesforce Realease 페이지 확인하기
✨ 세일즈포스 도입 운영에 고민이 있으시다면? 지금 트레슬에 문의해 주세요! ✨