Claude가 코드를 뱉어낸다. 에이전트가 실행된다. 고객이 항공편 지연에 대해 불만을 토로한다. 그리고… 아무런 응답이 없다. 예약 데이터도, 재예약 옵션도 없다. 그저 공허한 말뿐이다.
이것이 바로 Salesforce가 Agentforce로 해결하려는 ‘바이브 코딩’의 함정이다. 자연어 프롬프트를 입력하면, 당신의 조직 데이터, 시스템, 로직에 접근하는 에이전트가 뚝딱 만들어진다. 더 이상 장난감 같은 프로토타입은 없다. 적어도 그들의 주장대로라면 말이다. 우리는 항공사 데모를 뜯어보며 실제 현실을 파헤쳐 볼 참이다.
Salesforce 조직부터 시작하세요 - 바퀴를 다시 발명할 필요는 없으니까
Agentforce는 모든 것을 처음부터 다시 만들게 하지 않는다. 이미 당신의 Salesforce 조직에는 Apex 클래스, 플로우, 서드파티 통합 기능이 가득하다. Claude는 이들을 감지하고 에이전트 액션으로 전환시킨다. 가드레일도 상속받는다. Salesforce에 올인했다면 현명한 접근이다.
하지만 문제가 있다. Salesforce를 쓰지 않는 조직은? 딱하다. 이것은 범용 에이전트 빌더가 아니다. Salesforce 가속기다. CRM 본체에서 만든 스테로이드를 맞은 ‘바이브 코딩’인 셈이다.
Datasite의 Grant Roberson은 워크플로우 분담을 명확히 지적했다.
“지시문을 작성할 때는 항상 캔버스(Canvas)에 머물 겁니다. 무언가를 조정할 때는 에이전트 스크립트(Agent Script)가 조금 더 잘 작동한다고 생각해요. 세밀한 조정을 하기가 더 쉽기 때문이죠.”
캔버스는 큰 그림을 위한 프롬프트에, 스크립트는 미세 조정을 위해 사용된다. 라우터, 서브에이전트, 액션을 검토할 수 있다. Claude는 자신의 선택을 설명해 준다. 처음부터 다시 시작할 필요 없이 파인튜닝이 가능하다. 깔끔하다. 물론, 당신의 프롬프트가 할루시네이션을 일으켜 AI 생성 로직을 디버깅해야 하는 상황이 오기 전까지는 말이다.
실전 투입용 에이전트는 실시간 데이터를 갈망한다. 항공편 재예약 데모를 보자. API가 예약 세부 정보를 가져와 환불 정책 프롬프트에 전달하고, 가능 여부를 확인한다. 매끄럽게 시퀀싱된다. 개인화된 응답. 인간은 필요 없다.
왜 모든 에이전트는 이걸처럼 고객 데이터를 가져올 수 없을까?
컨텍스트가 왕이다. 모델에 고객 이력, 정책, 재고를 정확한 순간에 제공하라. 정확도가 치솟는다. Agentforce는 이러한 데이터 추출을 자동으로 시퀀싱한다. ‘바이브 코드’ 프롬프트 하나로 데이터 흐름을 연결하는 것이다.
하지만 Salesforce는 지저분한 부분은 슬쩍 넘긴다. 당신의 데이터가 사일로화되어 있다면? 혹은 오래되었다면? ‘바이브 코딩’은 CRM을 마법처럼 깨끗하게 만들지 못한다. 조직이 엉망진창이라면 립스틱 바른 돼지일 뿐이다. 그리고 그 데모는? 잘 닦인 Salesforce 설정이었다. 실제 조직은 레거시 잡동사니 때문에 피를 흘린다.
시스템 연결은 거래를 성사시키거나 망친다. Agentforce는 당신의 일상 도구와 연결된다. 항공편을 재예약하고, 레코드를 업데이트한다. 핸드오프(handoff)는 없다. 라우터가 작업을 서브에이전트에 분배한다. 여기서는 항공편 관리, 저기서는 좌석 선택. 모듈식이다. 확장 가능하다.
전문 서브에이전트와 함께하는 단일 에이전트 라우터. 복잡성이 증가해도 체계적으로 유지된다. 항공사 고객이 좌석에 대해 묻는가? 좌석 서브에이전트를 핑(ping)한다. 깔끔한 핸드오프, 컨텍스트 손실 없다.
서류상으로는 인상적이다. 하지만 스케일은 빠르게 벽에 부딪힌다. 고용량 쿼리? 서브에이전트 병목 현상이 발생한다. Salesforce의 장애 이력 — CRM 다운타임을 기억하는가? — 이 크게 다가온다. ‘바이브 코딩’된 에이전트는 그 위험을 증폭시킨다.
Lightning Web Components: 지루한 응답에 활기를 불어넣다
평범한 텍스트 채팅은 고객을 지루하게 만든다. LWC와 Lightning Types를 소개한다. 에이전트는 대화 중에 상호작용 가능한 UI를 렌더링한다. 항공편 선택기, 확인, 버튼 등이 가능하다. 앱 전환 없이 말이다.
LWC 역시 ‘바이브 코드’로 작성한다. 브랜드 가이드라인을 AI 도구에 프롬프트로 제공한다. 구조, 스타일링 초안을 작성한다. 검토는 필수다. 머리를 쓰는 과정이지, 공짜 점심은 아니다.
Salesforce는 이를 미래라고 홍보한다. 동적 출력. 실행 가능. 하지만 LWC는 당신을 그들의 생태계에 더 묶어둔다. 다른 플랫폼으로 옮기고 싶은가? 도시를 다시 써야 할 것이다. 편의라는 이름으로 포장된 종속성이다.
안정성을 위한 아키텍처링은 모놀리식 프롬프트를 버리는 것을 의미한다. Agentforce는 모듈성을 추진한다 — 라우터, 서브에이전트, 시퀀싱된 액션. 프로토타입에서 실전으로? 검토하고, 조정하고, 배포하라.
원래의 발표는 ‘모놀리식, 명령어-‘에서 끊긴다. 아마도 ‘명령어-따르기’일 것이다. 타당하다. 하지만 Salesforce의 진정한 강점은 조직 기반이라는 점이다. 처음부터 로직을 만들 필요가 없다. 하지만 이는 2010년대 노코드(no-code) 열풍을 메아리친다. 화려한 도구 뒤에 숨겨진 벤더 의존성이다.
독점적인 통찰: Siebel의 CRM 오버히트(Overreach)의 메아리. 2000년대 초, Siebel Systems는 통합 기능과 내장된 맞춤 로직으로 올인원 CRM 지배를 약속했다. 고객들이 방대한 기능에 등을 돌린 후 오라클은 헐값에 인수했다. Agentforce도 같은 위험을 안고 있다. ‘바이브 코딩’은 당신을 유혹하지만, 확장하려면 완전한 Salesforce 충성도가 필요하다. 대담한 예측? 2026년까지 Agentforce 사용자의 40%가 비용 폭등으로 인해 다중 벤더 스택으로 이탈할 것이다.
기업의 홍보는 ‘실전 준비 완료’를 외친다. 데모는 눈부시다. 하지만 과장 광고는 기본을 무시한다. 깨끗한 데이터, 안정적인 통합, 탈출구. ‘바이브 코드’를 마음껏 쓰라 — 그것들 없이는, 더 멋진 챗봇에 불과하다.
Salesforce는 이곳에 크게 베팅하고 있다. Agentforce는 서비스 운영을 간소화하고 핸드오프를 줄일 수 있다. 항공사, 콜센터 — 주요 타겟이다. 만약 성공한다면, 고객 경험은 비약적으로 향상될 것이다. 만약 실패한다면? 먼지 쌓이는 또 다른 AI 도구가 될 것이다.
회의론은 타당하다. ‘바이브 코딩’은 재미있다. 실전은 잔혹하다. Agentforce는 많은 것을 연결하지만 — 당신을 본체에 묶어둔다.
Agentforce, Salesforce 종속성을 감수할 가치가 있을까?
Salesforce를 깊이 사용하고 있는 조직이라면? 그렇다. ‘바이브 코딩’을 안정적인 에이전트로 빠르게 전환시켜 준다. 데이터 접근, 액션, UI — 모두 해결된다.
외부 사용자라면? 다른 곳을 찾아보라. LangChain이나 CrewAI와 같은 오픈소스 대안은 CRM 세금 없이 유연성을 제공한다.
데모는 가능성을 보여준다. 일상적인 사용은? 먼저 당신의 조직을 테스트하라.
왜 ‘바이브 코딩’은 Salesforce 밖에서 여전히 실패하는가?
조직 기반의 부재. 약한 데이터 흐름. 핸드오프 지옥. Agentforce는 이것들을 해결하지만 — 오직 내부에서만 가능하다.
**
🧬 관련 통찰
자주 묻는 질문**
Agentforce의 ‘바이브 코딩’이란 무엇인가요?
자연어 프롬프트를 사용하여 항공편 재예약과 같은 실전 작업을 위해 Salesforce 데이터, 시스템 및 UI에 연결되는 AI 에이전트를 구축하는 것입니다.
Agentforce는 Salesforce 없이 작동하나요?
아니요 — 기존 로직과 통합 기능을 활용하여 Salesforce 조직을 위해 구축되었습니다.
Agentforce 에이전트는 처음부터 끝까지 실제 고객 문제를 처리할 수 있나요?
예, 데이터 추출, 액션, 서브에이전트 라우터를 통해 가능합니다. 하지만 안정성은 조직의 데이터 품질에 달려 있습니다.
