# 소프트웨어가 헤드리스로 가는가? > Clean Markdown view of GeekNews topic #29750. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29750](https://news.hada.io/topic?id=29750) - GeekNews Markdown: [https://news.hada.io/topic/29750.md](https://news.hada.io/topic/29750.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-22T09:34:01+09:00 - Updated: 2026-05-22T09:34:01+09:00 - Original source: [a16z.news](https://www.a16z.news/p/is-software-losing-its-head) - Points: 6 - Comments: 0 ## Topic Body - Salesforce가 헤드리스 제품 출시를 통해 **UI가 아닌 데이터 계층이 가치의 중심**이라고 베팅하면서, 에이전트 시대 SaaS의 방어력이 어디에 남는지에 대한 질문이 제기됨 - SaaS 시대 기록 시스템(System of Record)의 해자는 **UI를 통해 형성된 사용자 습관**이었지만, 에이전트가 DB에 직접 읽고 쓰는 구조에서 이 우위가 약화됨 - 방어력은 아래로는 **데이터 모델, 권한, 워크플로 로직, 컴플라이언스**로, 위로는 **네트워크, 독점 데이터 생성, 실세계 실행 능력**으로 이동 중 - 차세대 AI 네이티브 기록 시스템에는 **에이전트 친화적 데이터 모델, 에이전트 단위 권한 관리, 실행 루프 폐쇄**라는 새로운 기준 필요 - 가장 유망한 차세대 사업은 **단순 데이터 저장을 넘어 실세계 실행과 다자간 조정**까지 확장되는 형태 --- ### Salesforce 헤드리스 발표가 던진 질문 - Salesforce가 지난달 API 개방과 헤드리스 제품 출시를 발표, 에이전트 시대 가치는 **UI가 아닌 데이터 계층**에 있다는 베팅 - 기술적으로 새로 바뀐 것은 거의 없음 — 헤드리스 제품으로 마케팅 중인 API들은 수년 전부터 존재했고, 전형적인 Salesforce식 마케팅 런칭 - 핵심 아이디어는 에이전트가 사람용 UI를 거치지 않고 기록 시스템의 데이터에 직접 접근한다는 구조 - UI를 걷어내고 DB만 남기면 **Postgres + 잘 설계된 스키마 + API**와 무엇이 다른지에 대한 본질적 질문이 제기됨 - 기존 기록 시스템을 지탱하던 요소들이 그대로 유효한지, 아니면 새로운 기준이 필요한지 검토 필요 ### UI가 곧 제품이었던 SaaS 시대 - 기록 시스템(System of Record)은 특정 도메인의 권위 있는 단일 진실 공급원(source of truth) - CRM은 매출의 기록 시스템, HRIS는 인사의 기록 시스템, ERP는 자금의 기록 시스템 - 단순한 저장소가 아니라 **조직 전체가 공유하는 현실**을 제공하는 것이 진짜 힘 - 지난 20년간 Salesforce가 판매한 것은 영업 리더가 팀을 운영하는 방식 - 대시보드, 파이프라인 뷰, 예측 도구, 활동 피드가 실제 판매 대상이었고, 비즈니스 모델은 **사용자 시트(seat) 판매** 기반 - 그 아래 DB는 핵심이지만 부수적 존재였음 - UI가 고착성(stickiness)을 만들었음 - 데이터 위생 강제, 공통 어휘(Lead, Opportunity, Account) 생성, 영업 담당자가 입력하지 않을 데이터를 입력하게 만듦 - 많은 영업 리더가 이직 시 Salesforce를 가져가는 이유는 UI가 좋아서가 아니라 **손에 익은 사용 습관(muscle memory)** 때문 - 에이전트가 이 모델을 뒤집기 시작 - UI를 거치지 않고 데이터에 직접 read/write 가능 - SAP 주변에도 AI 친화 생태계가 빠르게 확산 중 - 컴퓨터 사용 에이전트가 사람 기반 요인(선호, 훈련, 미문서화된 맥락)을 시간이 지나며 무력화시킴 ### 과거 기록 시스템의 고착성 평가 기준 - 사람이 소프트웨어와 상호작용하는 방식과 선호도에 기반한 요인들 - ## 얼마나 자주 사용되는가 - CRM은 GTM 팀이 매일 사용 → 핵심 인프라가 됨 - 그 위에 쌓인 **업무 루틴, 손에 익은 조작, 수년간 다져진 관리 케이던스**가 가장 옮기기 어려운 요소 - 마이그레이션해야 할 대상으로 인식조차 되지 않는 경우 많음 - ## Write-only인가, Read-write인가 - 고착성 있는 기록 시스템은 read-write 방식 - CRM은 끊임없이 읽힘 — 모든 통화 기록, 단계 업데이트, 작업 생성이 양방향 흐름 - 라이브 운영 데이터를 다뤄야 하므로 안전한 전환 시점이 없음 → 한번 도입하면 떠나기 어려움 - 반면 ATS(지원자 추적 시스템)는 write-only에 가까움 — 채용 종료 후 데이터를 다시 볼 일이 거의 없음 - ## 문서화되지 않은 SOP가 얼마나 많은가 - 비즈니스 핵심 맥락은 위키가 아닌 워크플로 규칙에 인코딩됨 - 영업 예시: **10만 달러 초과 엔터프라이즈 딜은 VP 승인 필요, EMEA 딜은 프라이버시 검토 필수, 전략적 로고 할인은 분기 말에만 재무 우회 가능** - 이런 맥락이 적시 처리 또는 누락의 차이를 만듦 - 마이그레이션은 모든 자동화를 역공학하거나 조직의 기억을 통째로 잃는 일 - ## 내부·외부 의존성 규모 - 하위 내부 시스템, 외부 감사인·회계사·규제기관의 직접 접근 필요성 - 양쪽 연결성이 높을수록 마이그레이션 시 풀어야 할 매듭이 많음 - ## 컴플라이언스 중요도 - 페이롤, ERP, HR 데이터는 **법적으로 방어 가능한 단일 진실 공급원, 엄격한 관리자 접근 통제, 감사인·규제기관의 직접 개입** 필수 - 매우 고착성 높음 - 영업 데이터, Zendesk 같은 고객지원 도구는 반대편 — 연속성·맥락은 중요하나 규제 노출은 없음 - ## 기록 시스템별 전환 비용 비교 - ATS는 채용이라는 경계가 명확한 워크플로 도구, 통합 좁고 사용자 적음 - ERP는 정반대 — 원장이 곧 감사 추적이며 회계사·감사인·규제기관이 직접 이해관계자 - ATS 교체는 고통스럽지만 견딜 만한 일, CRM 교체는 개심술(open-heart surgery), **ERP 교체는 마라톤 중인 환자에게 하는 개심술** - ## 전통적으로 약했던 해자 요소 - 독점 데이터 — CRM이 풍부한 데이터를 가졌으나 고객 간 인사이트 생성 시도 미미 (Salesforce Einstein 등 일부 시도만 존재) - 네트워크 효과 — 성배였지만 기록 시스템에서는 역사적으로 약했음 ### UI가 사라지고 에이전트가 도착하면 무엇이 남는가 - 에이전트는 브라우저가 필요 없음 — API, 맥락, 지시, 행동 능력만 있으면 됨 - 두 가지 변화가 이를 가능하게 함 - **LLM의 추론 능력 향상**: 에이전트가 맥락 읽기, 계획 수립, 도구 선택, 실행, 결과 검토까지 사람 개입 없이 수행 - **MCP의 도구 접근 표준화**: 에이전트가 외부 기능을 공통 인터페이스로 호출 - 컴퓨터 사용 에이전트는 적절한 맥락만 있으면 API 없이도 기존 SW 인터페이스 탐색 가능 - ## 소프트웨어 구매자의 세 가지 경로 - **기존 시스템 + 에이전트**: 기존 SaaS 강자의 CLI/API 사용, 네이티브 에이전트 제품(Salesforce Agentforce, SAP Joule) 또는 자체 에이전트 구축 — 단, API가 완전·사용 가능하고 헤드리스 전환이 운영적으로 단순하다는 가정 필요 - **자체 기록 시스템 구축(DIY)**: 자체 데이터 모델, 운영 로직, 권한·감사·통합, 자체 에이전트를 처음부터 구축 (서드파티 도구 활용 가능) - **AI 네이티브 대체재 구매**: 기계 가독성을 기반으로 처음부터 만들어진 신세대 SW, 에이전트 오케스트레이션이 일급 기능으로 내장, 헤드리스 가능 - ## 기존 평가 기준에서 살아남는 것 - 사람 행동 기반 요소(사용 빈도, read vs read-write) → 사용 습관과 함께 사라짐 - 에이전트가 사용 습관 해자는 죽이지만 **운영 로직과 맥락 해자는 죽이지 않음** - 오히려 에이전트가 안전하게 행동하려면 명시적 규칙·권한·프로세스 정의가 필요해 더 중요해짐 - ## 단기적으로 문서화되지 않은 SOP는 여전히 중요 - 워크플로 규칙에 인코딩된 조직 로직이 에이전트가 올바르게 작동하기 위한 핵심 - 깔끔하게 내보낼 수 없음 (사람이 일부 프로세스에 남아있을 때 특히) - 다만 맥락 캡처가 쉬워지고 에이전트가 노동을 대체할수록 점차 무관해짐 - ## 연결성(connectivity)은 여전히 어려우며 더 확장됨 - 사람을 따라가는 것보다 **분절된 기능과 SW 간 연결성 유지**가 중심 - CRM 에이전트는 영업·청구·고객성공 간 데이터·맥락을 봉합해야 함 - 외부 여러 조직의 에이전트가 거래하는 노드가 되면 의존성은 더욱 깊어짐 - 기존 강자 + 에이전트 조합이나 DIY DB + 에이전트 조합 모두 다양한 하위 SW 사이를 가로지르기 어려움 - ## 컴플라이언스 데이터는 여전히 중요 - 규제·법적 리스크 데이터는 단일 신뢰 데이터 소스 필요 - 페이롤·회계 데이터를 자체 구축·유지할 가능성 낮음 - 완전 에이전트 세계의 가장 어려운 미해결 문제: **어떤 에이전트가, 누구를 대신해, 무엇을, 어떤 감사 가능성으로 권한받는가** - 에이전트 간 상호작용의 신원·권한 계층이 되는 기록 시스템은 **신뢰 아키텍처**를 강제하므로 구조적으로 대체하기 어려움 ### AI 네이티브 스타트업의 새로운 방어력 요소 - ## 기록 시스템 재현 난이도 - 단기적으로는 기록 시스템 기반 데이터의 추출·재현 용이성이 핵심 - 기존 SaaS 강자는 API를 고통스럽게 만들거나, 게이트·불완전·경제성 없게 만들어 어렵게 함 - 추출 도구, 특히 컴퓨터 사용 에이전트가 발전하며 점점 쉬워짐 - 동시에 이메일·전화·음성 에이전트·내부 문서로부터 더 풍부한 데이터를 재구성하는 신규 기업 등장 중 - AI는 기록 시스템의 첫 80% 재현 비용을 낮추지만, 나머지 20%(예외 처리, 승인, 컴플라이언스, 엣지 케이스 워크플로)가 진짜 대체재와 wedge를 가르는 지점 - ## 의미 있는 독점 데이터 보유 여부 - 방어 가능한 데이터는 import한 데이터가 아니라 **제품이 고유하게 만들어낸 데이터** - 데이터의 walled garden — 독점적이거나 규제 대상이거나 지속적 업데이트가 필요한 데이터 - 권위 있고 완전한 데이터에 투자한 SW 제공자는 범용 제공자 대비 우위 확보 - 내부 생성 행동 기반 데이터: 관찰된 행동, 응답률, 타이밍 패턴, 프로세스 결과, 벤치마크, 예외 패턴, 에이전트 성능 추적 - **데이터가 곧 맥락(data is the context)** - ## 액션 계층 소유 여부 - 과거에는 기록 저장으로 충분했지만 새로운 시대에는 에이전트가 행동함 - 방어력은 **행동 → 결과 캡처 → 피드백 → 의사결정 개선**의 폐쇄 루프 제품으로 이동 - ERP 예시: 지출 승인, 페이롤 트리거, 인보이스 정산, 통지 발송 등 - 루프를 닫는 제품은 관찰이 아닌 실행 안에 위치 → 고유 데이터 생성, 사용할수록 개선, 워크플로를 깨지 않고는 제거 어려움 - ## 실세계 실행 요소 - 완전 자동화되지 않을 실세계 운영과의 연결성을 가진 비즈니스 모델 - DoorDash 같은 운영 네트워크 사례 — 역사적으로 기록 시스템은 아니지만 시사점 제공 - 서비스, 풀필먼트, 물류, 현장 운영, 결제로 루프를 닫는 SW는 순수 SaaS와 다른 종류의 방어력 보유 - 단순 기록 저장·추천이 아니라 **사람을 파견하고, 물건을 옮기고, 서비스를 완수** - 빌더에게는 SW가 점점 더 결정하고 에이전트가 조정하지만 **마지막 마일은 실세계 실행이 필요한 시장**에 기회 — 예: 현장 서비스 결합 버티컬 SW - ## 네트워크 효과 - 과거 기록 시스템에서는 SW가 주로 내부용이라 약했음 - 다자 워크플로에 임베드되면 네트워크 효과가 훨씬 중요해질 가능성 - **구매자-판매자, 고용주-피고용자, 회사-감사인, 벤더-고객, 페이어-프로바이더** 등 반복 상호작용 매개 시 참여자 증가가 네트워크 가치 증가로 이어짐 - 구현 방식 - 공유 워크플로 조정 — 양측이 거래·맥락 교환·예외 해결을 수행하는 장소가 됨 - 벤치마킹·인텔리전스 — 네트워크 패턴 기반 규범·이상·추천 제공 - 신뢰·표준화 — 승인·핸드오프·컴플라이언스·결제의 공통 레일이 되면 단순 DB가 아니라 **시장 조정 인프라**의 일부가 됨 - ## 구매자의 기술 역량 - 누구나 이론적으로 에이전트를 만들 수 있는 시대에도 실제 능력은 큰 편차 존재 - 버티컬 엔드 마켓, 내부 엔지니어링 자원이 약한 기능 구매자는 자체 DB·워크플로 로직·에이전트 스택·거버넌스 구축·유지·개선 가능성 낮음 - 비용도 핵심 — DIY는 라이선스 비용은 줄지만 구현·유지·내부 복잡도 비용으로 전가됨 - 운영은 복잡한데 기술적으로 underserved인 카테고리에 기회 — **제조, 건설 백오피스, 산업·현장 서비스 워크플로, 회계** ### 그 외 필수(table stakes) 요소 - ## 새로운 데이터 모델(온톨로지) - "DIY DB" 사고는 객체 모델 자체의 가치를 과소평가하는 경향 - 기존 SW는 대시보드·리포트·사람 워크플로 캡처용으로 만들어짐 → Opportunity, Ticket, Candidate 등 - 에이전트용 스키마는 **추론, 행동, 상태 추적, 예외 처리, 위임, 시스템 간 조정** 캡처 필요 - 네이티브 객체 모델이 task, intent, thread, policy, outcome 같은 형태로 변화 - ## 에이전트 권한 관리 - 사람만이 아닌 에이전트 관리용 권한 체계 필요 - **누가, 어떤 에이전트를 통해, 어떤 정책 하에, 어떤 승인·감사 추적·롤백·예외 처리로** 무엇을 할 수 있는지 정의 - ## 비용 맥락 - 에이전트·DB 구축·유지 비용, API 접근 비용 등 - 데이터 재현 난이도와 의존성 수와도 연결되는 문제 ### 결론 — 기록 시스템의 진화 방향 - 기존 SaaS 강자들이 헤드리스로 가는 것은 **데이터 계층이 가치의 원천으로 남는다**는 암묵적 베팅 - 금융 서비스처럼 깊이 컴플라이언스 결합된 카테고리에서는 한동안 이 베팅이 유효, 헤드리스 전환도 더 먼 미래 - 빌더 입장에서는 헤드리스로 전환하는 기존 강자들과 경쟁할 기회 구조가 변화 - 차세대 기록 시스템은 단순 기록 저장소가 아니라 **맥락을 캡처하고, 작업을 개시하며, 데이터 발자취(data exhaust)를 기록하는 에이전트 친화적 형태** - 가장 흥미로운 비즈니스는 **실세계 실행으로 확장 - 현장 인력, 물류 제공자, 서비스 팀, 물리적 자산을 조정**하거나 **다자 사이에 위치**하는 형태 - 구세계 비즈니스 모델과 전통 기록 시스템의 핵심(데이터)을 섞되, 데이터는 배경에 위치하는 구조 ## Comments _No public comments on this page._