이전 글에서는 FDE와 SI를 가르는 것이 명함의 직무명이 아니라 학습곡선이라고 썼다. 고객 현장에서 한 맞춤 작업이 다음 고객에게 쓰일 커넥터, 거버넌스 계층, 배포 구성 요소로 남는다면 서비스는 소프트웨어 레버리지를 만들 수 있다.
그러면 꽤 자연스러운 반론이 생긴다.
AWS가 FDE를 수천 명 뽑으면 되는 것 아닌가?
표면적으로는 hyperscaler가 훨씬 유리하다. AWS, Google, Microsoft는 이미 수많은 기업고객, 글로벌 영업 조직, 컴퓨팅 자원, 기반 모델, 데이터 플랫폼, 보안, 규정 준수, 기업의 신뢰와 수천 명의 엔지니어를 가지고 있다. FDE가 좋은 제공 방식이라면 이들이 스타트업보다 더 빨리 복제할 것처럼 보인다.
그런데 실제 hyperscaler와 일하면서 내 질문은 조금 달라졌다. 고객 옆에 뛰어난 엔지니어를 보내는 것만으로 FDE가 만들어질까?
FDE의 단위는 사람이 아니라 Loop다
이 글의 가설은 단순히 “대기업은 관료적이라 안 된다”가 아니다. FDE는 직무이기 전에 조직 구조이고, 그 단위는 사람보다 순환에 가깝다. 문제를 발견하고, 만들고, 실패하고, 제품의 빈틈을 발견하고, 제품을 바꾸고, 다음 고객에게 재사용하는 순환 말이다. 그리고 좋은 순환은 빠르게 돌기만 해서는 부족하다. 돌 때마다 회사에 무언가가 남아야 한다.
이 글은 2026년 10월 3일까지 공개된 자료를 사용한다. 회사의 공식 설명은 실제 성과와 다를 수 있고, 아래 Google·AWS 경험은 특정 계정과 상호작용에 국한된 개인적 관찰이다. 사실, 경험, 가설을 구분해 읽어야 한다.
Google에서 경험한 2주보다 긴 거리
회사에서 Gemini Enterprise의 Custom Agent를 실제 기업 환경에 배포하려던 적이 있다. SSO 인증이 반복해서 실패했다. 처음에는 설정 하나의 문제라고 생각했다. 하지만 해결 과정에는 내 기억상 고객 담당 엔지니어, 계정 지원 인력, 네트워크와 AI 전문가, 여러 지역의 기술 인력이 차례로 참여했고, 결국 본사 제품팀이 있는 상위 조직으로 이관되었다.
제품 쪽 수정이 이루어지기까지 2주가 넘게 걸렸다. 수정 뒤에도 내가 운영 환경에서 신뢰할 만큼 안정적으로 동작하지 않았고, 결국 그 기능을 더 쓰지 않게 됐다. 회사명, 내부 네트워크 구조, 계정 정보와 담당자는 의도적으로 생략한다. 참여한 사람들의 정확한 직무명보다 중요한 것도 따로 있다.
상당히 많은 기술 인력이 문제를 풀기 위해 움직였다. 내가 흥미롭게 본 것은 사람들의 능력이 아니라, 고객의 문제가 실제 제품을 바꿀 수 있는 조직까지 도달하는 데 지나야 했던 거리였다.
Customer-to-Product Latency
이 사례의 latency: 2주 이상
물론 하나의 고객, 하나의 제품, 하나의 지역에서 겪은 사례만으로 Google Cloud 전체 고객 조직을 평가할 수는 없다. 인증 문제에는 보안 검토와 재현, 회귀 테스트가 필요하고 글로벌 제품은 한 고객을 위해 즉시 바뀌어서는 안 된다. 이 경험은 결론이 아니라 질문의 출발점이다.
고객-제품 지연시간
나는 그 거리를 고객-제품 지연시간이라고 부르려 한다.
고객 현장에서 발견된 문제와 학습이 실제 핵심 제품의 변화로 돌아오기까지 걸리는 시간.
정식 업계 KPI가 아니라 이 글을 위한 개념이다. 고객 문제가 현장 엔지니어의 진단을 거쳐 전문가, 지역 조직, 제품 책임자, 엔지니어링 조직으로 이동하고 다시 고객에게 돌아오는 모든 화살표에는 시간이 든다.
그 시간이 길어지는 이유를 조직 임피던스라는 비유로 생각할 수도 있다. 고객 신호가 조직 경계를 지날 때 생기는 인계, 대기열, 정보 손실, 소유권의 모호함과 우선순위 충돌이다. 전기공학의 임피던스를 엄밀히 옮긴 모형은 아니다.
Organizational Impedance
AI-native
대규모 조직 · 예시
여기에는 불필요한 절차만 있는 것이 아니다. 보안 검토, 신뢰성, 하위 호환성, 규제 요건과 글로벌 로드맵은 수많은 고객이 쓰는 제품을 운영하기 위한 필수 통제다. 그래서 질문은 “관료주의를 없앨 수 있는가?”가 아니라 필요한 통제와 FDE가 요구하는 학습 속도를 동시에 달성할 수 있는가?다.
AWS에서 느낀 또 다른 거리
Google 경험이 제품 피드백의 거리였다면, AWS 고객 담당 조직과의 제한된 경험은 문제 발견의 거리를 생각하게 했다.
일부 솔루션 아키텍트와의 대화는 “AWS의 어떤 기술로 무엇을 만들어볼 것인가?”에서 시작했다. 때로는 클라우드 크레딧으로 시도할 활용 사례를 찾는 대화가 실제 기업 업무 흐름의 문제를 정의하는 대화보다 앞섰다. 한 번은 주식 자동매매 같은 아이디어까지 흘러갔다. 아이디어 자체가 나쁘다는 뜻도, 특정 SA를 비판하려는 뜻도 아니다. 이미 가진 도구를 출발점으로 삼으면 문제를 보는 방식도 자연스럽게 그 도구 쪽으로 기울 수 있다는 관찰이다.
Account Manager는 사업 맥락을 상대적으로 더 이해하려 했지만, 클라우드 사용량이라는 상업적 목표와 고객의 잠재 문제 발견이 언제나 같은 목표인지에는 의문이 남았다. 이것 역시 특정 계정, 지역, 상호작용에 기반한 제한된 경험이다.
좋은 FDE는 고객의 요구사항을 구현하는 사람에서 끝나지 않는다. 고객이 요구사항을 잘못 정의하고 있다는 사실부터 발견하는 사람일 수 있다. FDE의 첫 번째 산출물은 코드가 아니라 문제 정의일지도 모른다.
FDE에는 두 개의 순환이 필요하다
이 두 경험을 나란히 놓으면 FDE의 피드백 구조가 두 부분으로 보인다.
FDE에 필요한 두 개의 Loop
Problem Discovery
Product Learning
첫 번째는 문제 발견 순환이다. 고객이 말한 요청을 그대로 클라우드 서비스에 대응시키는 대신 실제 업무 흐름을 관찰하고, 숨은 문제를 찾고, 문제를 다시 정의한 뒤 만든다. 이 순환의 위험은 Sales / Consumption / Adoption Bias다. 고객의 문제를 찾기보다 이미 있는 제품이 쓰일 자리를 찾게 된다.
두 번째는 제품 학습 순환이다. 구축 과정에서 제품의 빈틈을 발견하고, 그것을 핵심 제품과 재사용 가능한 구성 요소로 바꿔 다음 고객을 더 빠르게 만든다. 이 순환의 위험은 학습이 Escalation + Workaround로 대체되는 것이다.
직무명이 아니라 feedback architecture
SA, 전문 서비스, FDE를 하나의 고정된 선 위에 놓기는 어렵다. 훌륭한 SA가 문제 발견을 수행할 수 있고, ProServe가 제품에 강한 피드백을 줄 수도 있다. 반대로 FDE라는 직함이 있어도 고객별 구현만 반복할 수 있다. 차이는 직무 설명보다 제품을 바꿀 수 있는 권한, 인센티브, 피드백 경로에 있다.
FDE의 단위는 사람이 아니라 순환이다.
AWS가 100명, 1,000명, 수천 명을 뽑는다는 숫자보다 고객의 문제를 발견하고 → 만들고 → 실패하고 → 제품의 빈틈을 찾고 → 제품을 바꾸고 → 다음 고객에게 재사용하는 순환이 얼마나 빨리 도는지가 중요하다.
AWS는 이 이론을 이미 알고 있다
AWS를 이 논리의 허수아비로 만들 수는 없다. AWS는 2026년 6월 전담 FDE 조직에 초기 10억 달러를 투자하고 수천 명의 전문가를 고객팀에 배치하겠다고 발표했다. 공개 설명에는 사업 성과, 운영 배포, 재사용 가능한 패턴, 체계화된 전문성, 고객의 자립과 한 프로젝트의 학습이 다음 프로젝트에 누적된다는 언어가 들어 있다. AWS 공식 발표
공개 미리보기 약관은 협업을 45일 단기 개발 주기로 설명하며, 고객이 계정·권한·파이프라인과 이후 운영 준비를 맡는다고 적는다. 즉 AWS도 영구적인 의존 관계보다 빠른 공동 구축과 이관을 설계하고 있다. AWS FDE 약관
채용공고는 더 직접적이다. 수석 FDE에게 여러 고객에 적용할 참조 아키텍처, 재사용 가능한 패턴과 엔지니어링 체계를 만들고 반복되는 고객 패턴을 AWS 제품 로드맵에 반영하라고 요구한다. 정부 부문 FDE 공고 역시 운영 수명주기를 책임지고 재사용 가능한 가속 도구를 AWS 서비스로 환류시키는 일을 명시한다. 수석 FDE, FDE — 미국 정부
AWS가 FDE의 정의를 잘못 이해한다고 생각하지 않는다. 공개된 설명만 보면 놀랄 만큼 정확하게 이해하고 있다. 내가 궁금한 것은 AWS라는 거대한 조직이 그 정의를 실제로 실행할 수 있느냐는 점이다.
따라서 비판의 대상은 이론이 아니라 실행 구조다.
Google과 Microsoft도 같은 방향의 여러 공동 구축 활동을 확대하고 있다. 2026년 9월 Google Cloud와 Accenture는 Gemini Enterprise 조직을 발표하며 Accenture 측 1,000명 규모 FDE 인력과 Google Cloud 전문 엔지니어링의 결합을 설명했다. 이것을 Google의 기존 고객 엔지니어나 TAM이 모두 FDE가 되었다는 뜻으로 읽어서는 안 된다. Google Cloud 발표 Microsoft의 AI Co-Innovation Labs도 고객과 시제품을 함께 만드는 인접한 모델이지만, 동일한 FDE 조직이라고 단정할 근거는 없다. Microsoft AI Co-Innovation Labs
Hyperscaler에서 순환이 느려질 수 있는 이유
Hyperscaler가 FDE를 실행할 때 최소 다섯 가지 경계를 통과해야 할 수 있다.
- 조직/직무 KPI 간 괴리. 영업, Account Manager, SA, ProServe, 지원, 제품 엔지니어링은 성공을 측정하는 단위가 다를 수 있다. 고객 성과와 클라우드 사용량이 충돌하면 누가 우선권을 갖는가?
- 제품 소유권과의 거리. FDE가 핵심 서비스의 한계를 발견했을 때 직접 로드맵에 영향을 주는가, 기능 요청 대기열에 들어가는가, 아니면 우회책을 만드는가?
- 글로벌 제품 제약. SLA, 보안, 하위 호환성, 규제 요건과 기존 고객 때문에 한 현장의 학습을 바로 글로벌 제품에 넣기 어렵다. 이는 규모가 만든 합리적인 제약이기도 하다.
- 조직 경계. FDE는 영업, ProServe, 지원, 제품 중 어디에 속하고 누가 예산·우선순위·성공을 결정하는가?
- 수익 모형. 협업의 북극성이 고객 성과인지 클라우드 사용량인지, 두 지표가 어긋날 때 무엇이 남는가?
공개자료만으로 AWS 내부 답을 알 수는 없다. 그래서 위 항목은 회사에 대한 사실 판정이 아니라 실행을 평가할 질문이다.
가장 위험한 실패 방식: 우회책 공장
Productization인가, Workaround Factory인가
이상적인 FDE는 제품의 빈틈을 핵심 제품의 변화와 재사용 가능한 구성 요소로 만든다. 하지만 핵심 제품을 바꿀 수 없다면 현장팀은 맞춤형 통합과 고객별 코드로 문제를 우회한다. 고객은 당장 도움을 받지만 다음 고객의 한계 배포비용은 줄지 않고 유지보수 대상만 늘어난다.
FDE에게 고객 문제를 해결할 권한만 주고 제품을 바꿀 영향력을 주지 않으면, FDE 조직은 매우 비싼 우회책 공장이 될 위험이 있다.
그 상태의 FDE는 SA보다 구현을 많이 하고 전문 서비스보다 제품 지향적인 중간 조직으로 수렴할 수 있다. 좋은 사업과 고객 결과를 만들 수는 있어도, 이전 글에서 다룬 Productization → Software Leverage 대신 Workaround → Services Labor가 남는다.
규모는 약점인 동시에 압도적인 장점이다
공정하게 보면 hyperscaler는 세계에서 가장 많은 기업 문제를 관찰할 수 있다. 고객 기반이 크면 고객 신호는 훨씬 더 크게 늘어난다. 컴퓨팅 자원, 모델, 보안, 유통과 신뢰까지 같은 조직 안에 있다. 스타트업이 얻기 어려운 학습의 원재료다.
동시에 조직 규모가 커질수록 경계, 인계, 제품과의 거리와 에스컬레이션 지연도 커질 수 있다.
Scale Advantage vs Organizational Disadvantage
Scale advantage
더 많은 고객더 많은 signalCompute·modelsDistributionSecurity·trustOrganizational disadvantage
더 많은 handoffProduct distanceKPI conflictGlobal roadmapEscalation latency학습의 이점이 조직의 지연보다 클 수 있는가?
이 글의 질문은 “큰 회사라서 실패하는가?”가 아니다.
고객이 많아서 얻는 학습의 이점이, 조직이 커서 생기는 지연보다 클 수 있는가?
이를 정식 실증 모형이 아닌 사고용 경험칙으로 쓰면 다음과 같다.
숫자 점수를 만들자는 뜻이 아니다. 현장 인원수보다 순환의 구성 요소를 따로 보자는 제안이다.
그런데 Palantir는 이미 20년 넘게 이걸 해왔다
여기서 강력한 반례가 등장한다. 조직이 커질수록 FDE가 어려워진다면 Palantir는 어떻게 설명할 것인가?
Palantir는 더 이상 작은 스타트업이 아니다. 2025년 10-K에 따르면 매출은 44.75억 달러, 고객은 954곳, 정규직은 4,429명이었다. GAAP 매출총이익률은 82%였다. 2026년 2분기에는 매출 19.35억 달러와 매출총이익 16.39억 달러를 보고했다. 단순 계산한 분기 GAAP 매출총이익률은 약 84.7%다. 2025 10-K, 2026년 2분기 실적 발표
이 숫자는 FDE 비중이 큰 모델이 소프트웨어와 같은 매출총이익률과 규모에 도달할 수 있다는 중요한 경험적 사례다. 다만 Wonderful 같은 비상장 스타트업과 동일 조건으로 비교할 수는 없다. 회사의 성숙도, 제품 구성, 회계 분류가 다르고, Palantir는 클라우드와 자체 구축 구독, 운영·유지보수, 전문 서비스를 함께 판매하면서 그 구성을 별도 매출로 공개하지 않는다. 또한 정부 매출은 2025년 전체의 54%였고, 긴 판매주기와 고숙련 배포 인력, 복잡한 제품이라는 위험도 남는다.
그럼에도 Palantir는 “큰 조직은 FDE를 못한다”는 단순한 가설을 무너뜨린다. 더 정확한 차이는 크기가 아니라 역사적으로 형성된 조직의 DNA일 수 있다.
Why Palantir May Be Different
Hyperscaler
AI-native startup
Palantir
Hyperscaler는 대체로 제품과 거대한 시장 진입 조직을 먼저 가진 뒤 FDE를 추가한다. AI 네이티브 FDE 스타트업은 FDE에서 시작해 제품화를 시도한다. Palantir는 고객의 현실을 이해하지 않으면 제품 자체를 만들기 어려운 문제에서 출발했다.
FDE를 기존 조직 위에 추가하는 것과, FDE 피드백 순환을 중심으로 제품과 조직이 진화해온 것은 다르다.
Palantir에서 FDE는 제품 요구사항이었을지도 모른다
Palantir가 해온 일을 극도로 단순화하면 흩어진 데이터를 서로 연결하고, 그 데이터를 현실 세계의 객체와 운영에 연결하는 일이라고 볼 수 있다. 그러나 이것을 단순 데이터 통합으로 축소하면 핵심을 놓친다.
Palantir의 공식 문서에서 Ontology는 데이터를 실제 세계의 객체, 속성과 연결로 표현하고, 논리와 동작을 연결해 운영 결과로 이어지게 한다. 공급망이라면 공급업체 ↔ 부품 ↔ 공장 ↔ 재고 ↔ 주문이 단순 표가 아니라 관계와 권한, 사업 논리, 되쓰기 동작을 가진 운영 모형이 된다. Ontology 소개 개념, Ontology를 만드는 이유
항공사의 항공기·승무원·정비와 병원의 환자·병상·진료 절차, 제조사의 공급업체·부품·공장은 서로 다르다. 이 구조는 고객에게 “스키마를 보내달라”고 해서 충분히 이해하기 어렵다. 누군가는 현장에서 데이터가 실제로 무엇을 의미하는지, 어떤 관계가 중요한지, 누가 결정을 내리고 숫자가 바뀌면 어떤 동작이 일어나는지 알아야 한다.
Palantir에서 FDE는 유통 전략이기 전에 제품 요구사항이었을지도 모른다.
Palantir의 10-K는 고객에게 직접 배치되어 복잡한 문제를 풀면서 플랫폼 역량을 계속 강화한다고 설명한다. 공식 아키텍처 문서 역시 FDE를 고객 현장과 플랫폼 진화를 연결하는 제품 개발 방식으로 규정한다. 이는 회사가 설명하는 자기 모델이라는 점을 감안해야 하지만, 적어도 FDE가 나중에 붙인 영업 직무만은 아니라는 근거다. Palantir 아키텍처
순환이 돌 때마다 무엇이 남았는가
Palantir의 현장 학습이 모든 제품을 직접 만들었다고 단정할 수는 없다. 다만 공개자료는 그 학습이 Foundry의 데이터 운영과 Ontology, Apollo의 다양한 환경에 대한 지속적 제공, AIP의 LLM·에이전트·평가·거버넌스 계층 같은 재사용 가능한 역량과 반복적으로 연결되어 왔음을 보여준다. 10-K도 Foundry, Gotham, Apollo, AIP를 네 개의 주요 플랫폼으로 설명한다.
여기서 축적된 학습이라는 개념을 꺼낼 수 있다.
그 Loop가 1,000번 돌고 나면 무엇이 남는가?
이 역시 정식 업계 지표는 아니다. 한 번의 순환이 재사용 가능한 구성 요소를 남기고, 반복된 배포가 유형과 거버넌스를 남기며, 그것이 플랫폼 역량과 신뢰로 쌓이는지를 묻는 분석 틀이다.
그 순환이 1,000번 돌고 나면 회사에 무엇이 남는가?
Palantir에는 무엇이 남았는가? Wonderful에는 무엇이 남고 있는가? AWS에는 무엇이 남을 것인가? 같은 FDE 인원수라도 이 질문의 답이 다르면 사업 경제성도 달라진다.
LLM은 이 모델을 만든 것이 아니라 증폭했을 수 있다
LLM 때문에 Palantir의 사업 모형이 생긴 것은 아니다. 회사는 2003년에 설립되었고 오랫동안 데이터, 운영, 논리와 동작을 연결해왔다. AIP는 그 위에 외부 LLM 연결, 에이전트·자동화 도구 체계, 응용 프로그램과 평가 틀을 얹는다. AIP Logic은 Ontology 객체를 읽고 함수를 호출하며, 권한 안에서 동작을 제안하거나 실행할 수 있다. AIP Logic
2026년에는 Palantir가 자연어로 데이터 통합, Ontology 개발과 함수 생성을 돕는 AI FDE까지 공개했다. 이것은 적어도 회사의 방향이 FDE를 없애는 것보다 FDE 작업을 플랫폼과 AI로 압축하는 쪽임을 보여준다. AI FDE 개요
AI는 FDE를 없애기보다 output을 키울 수 있다
AI 이전
AI와 함께
AI가 Palantir에게 FDE를 필요 없게 만든 것이 아니라, FDE 한 명이 만들어낼 수 있는 산출물을 키웠을 수 있다.
이 문장은 공시된 인과적 사실이 아니라 나의 해석이다. 실제 생산성 개선 폭과 인간 배포 인력 의존도는 공개자료만으로 측정할 수 없다.
Palantir를 신화화해서는 안 되는 이유
Palantir가 확장한 이유를 FDE 순환 하나로 환원할 수 없다. 오랜 정부 관계, 보안 자격, 높은 전환 비용, Ontology 아키텍처, Apollo, 기업 영업, 배포 인프라, 브랜드와 20년의 신뢰가 함께 작동했을 가능성이 크다.
2025년 매출원가에는 현장 서비스 담당자와 하도급 비용이 포함되고, 전문 서비스에는 UI 설정, 교육, 지속적인 Ontology와 데이터 모형화 지원이 포함된다. 높은 매출총이익률이 모든 배포에 적은 인력이 든다는 뜻은 아니다. 회사 스스로도 더 크고 복잡한 배포를 관리하는 데 운영 부담이 생길 수 있다고 10-K에 적었다.
그래서 Palantir의 결과는 FDE → 성공이라는 공식보다 다음의 복합물에 가깝다.
이 또한 가치평가 방정식이 아니라 다음 글을 위한 가설이다. Palantir의 진짜 해자가 FDE인지, Ontology인지, 신뢰인지, 아니면 20년간 이 요소들이 함께 축적된 경로 의존성인지는 별도로 파고들 가치가 있다.
세 가지 모델, 세 가지 위험
| 모델 | 출발점 | 강점 | 핵심 위험 |
|---|---|---|---|
| Hyperscaler | 제품 우선 → 이후 FDE 추가 | 고객, 유통, 컴퓨팅 자원, 모델, 보안 | 기존 조직 사이에 갇힌 FDE, 긴 제품 거리 |
| AI 네이티브 FDE 스타트업 | FDE 우선 → 제품화 | 짧은 고객-제품 거리, 빠른 반복 | 과도한 맞춤화, 서비스 경제성, 확장 시 순환 저하 |
| Palantir | FDE 기반 → 축적된 플랫폼 → AI 가속 | 현장 학습, Ontology, 배포 인프라, 신뢰 | 인력 집약적 복잡성, 긴 영업 주기, 경로 의존성 |
스타트업이라고 자동으로 유리한 것도 아니다. 모든 고객 요청을 제품에 넣으면 일관성이 무너지고, 보안·거버넌스가 미성숙할 수 있으며, 핵심 인력 의존도와 지원 부담이 커질 수 있다. 반대로 hyperscaler는 이미 존재하는 SA와 ProServe의 지식, 기업의 신뢰와 유통망을 FDE 순환에 연결하면 누구보다 빨리 학습할 잠재력이 있다.
그래서 Wonderful 같은 회사의 잠재적 해자는 “좋은 FDE를 보유했다”보다 FDE가 작동하도록 설계한 조직 구조일 수 있다. AWS는 FDE 100명을 채용할 수 있다. 제품 소유권, 영업 인센티브, 로드맵 절차, 에스컬레이션 구조, 지원 조직과 고객 피드백 체계 전체를 같은 방향으로 정렬하는 것은 더 어렵다.
FDE는 사람을 채용한다고 복제되는 조직 역량이 아니다.
AWS가 내 가설을 틀렸다고 증명하려면
나는 AWS가 실패할 것이라고 예측하지 않는다. 오히려 공개된 설계가 명확하기 때문에 이 가설은 검증 가능해야 한다. 외부에서 보고 싶은 증거는 다음과 같다.
무엇이 내 생각을 바꿀까?
- 현장에서 발견된 빈틈이 핵심 AWS 서비스나 로드맵에 들어간 구체적 사례
- 여러 고객 협업에서 같은 구성 요소가 재사용된 사례
- 비슷한 배포에 필요한 시간과 인력이 줄어드는 신호
- 클라우드 사용량만이 아니라 고객 성과와 자립도를 평가하는 방식
- 맞춤형 우회책보다 제품화된 구성 요소가 빠르게 누적된다는 증거
대부분 내부 KPI일 가능성이 높다. 공개되지 않는다고 실패를 뜻하지 않는다. 반대로 수천 명이라는 인원수만으로 순환이 작동한다고 결론낼 수도 없다.
채용 인원에서 남는 자산으로
처음 질문은 “AWS가 FDE를 몇 명 뽑을 것인가?”였다. 이제 질문을 세 개로 바꿀 수 있다.
- 그 FDE들이 고객의 진짜 문제를 발견할 수 있는가?
- 그 학습은 우회책으로 끝나는가, 재사용 가능한 제품으로 돌아오는가?
- 그 순환이 1,000번 돌고 나면 회사에 무엇이 남는가?
Palantir의 20년이 흥미로운 이유는 FDE를 오래 했기 때문만은 아니다. 그 과정에서 데이터 통합, Ontology, 배포 인프라, 거버넌스, 기업의 신뢰와 플랫폼 역량 같은 자산이 누적되었을 수 있기 때문이다. 그렇다고 그 경로를 AWS나 스타트업이 그대로 복제할 수 있다는 뜻도 아니다.
FDE의 단위는 사람이 아니라 순환이다. 그리고 좋은 순환은 돌 때마다 회사에 무언가를 남긴다.
Hyperscaler가 FDE를 복제할 수 있는지는 얼마나 많은 엔지니어를 고객에게 보내느냐가 아니라, 그들이 발견한 문제를 얼마나 빠르게 제품으로 되돌리고 그 학습을 다음 고객을 위한 자산으로 얼마나 오래 축적할 수 있느냐에 달려 있을지도 모른다.
Discussion
토론
질문, 정정, 반례, 다른 해석이 있다면 남겨 주세요.