uyeon.dev
게시일

팔란티어는 어떻게 SI의 저주를 풀었나

2026년 여름, 이상한 장면이 연달아 펼쳐졌다.

6월 30일 AWS가 자사 엔지니어를 고객사에 상주시키는 사업에 10억 달러를 약속했다. 이틀 뒤 마이크로소프트가 25억 달러와 엔지니어 6,000명으로 판을 키웠고, 앞서 5월에는 OpenAI가 40억 달러 이상을 조달해 거의 동일한 사업을 세웠으며, Anthropic도 사모펀드들과 손잡고 15억 달러 규모의 합작 법인을 만들었다.

소프트웨어 업계가 수십 년간 “절대 하지 말라”고 배워온 인력 파견 사업에, 가장 잘나간 회사들이 앞다투어 돈을 붓기 시작한 것이다. 그리고 거의 모든 보도가 한 가지 사실을 빼놓지 않았다. 이 모델을 20년 가까이 전에 만들어낸 회사가 팔란티어라는 점.

무엇을 발명했길래 다들 베끼는 걸까. 결론부터 말하면, 팔란티어가 발명한 건 ‘파견’이 아니다. 파견으로 시작해도 소프트웨어 회사로 끝날 수 있게 만드는 구조다. 그리고 그 구조의 절반은 비즈니스 설계에, 나머지 절반은 생각보다 깊은 소프트웨어 아키텍처에 숨어 있다.

SI의 저주는 인건비가 아니다

SI 비즈니스에는 오래된 저주가 있다. 사람 수만큼만 큰다는 것.

흔히 인건비 마진의 문제로 설명하지만, 만드는 쪽에서 보면 진짜 원인은 따로 있다. 코드베이스 분기다. 고객마다 맞춤 개발을 하면 코드 사본(포크)이 하나씩 늘고, 포크가 10개를 넘어가는 순간 신기능 하나를 10번 이식해야 한다. 유지보수 부담은 고객 수에 비례가 아니라 그 이상으로 커진다.

사람이 비싸서가 아니라, 사람이 만든 결과물이 자산으로 적립되지 않고 부채로 쌓이기 때문에 확장이 안 되는 것이다.

그런데 팔란티어는 이 저주받은 방식을 일부러 골랐다. 보안 인가를 받은 자사 엔지니어가 포트 브래그나 랭리 같은 고객 현장에 6개월에서 12개월씩 앉아 도메인을 익히고 프로덕션 코드를 직접 짰다. 이 역할이 FDE(Forward Deployed Engineer)다. 겉모습만 보면 우리에게 익숙한 SI 파견과 다를 게 없다.

차이는 파견 나간 사람이 무엇을 남기느냐에 있다. SI 인력은 고객사 스택 위에 일회성 산출물을 남기고 떠난다. 팔란티어 FDE는 자사 플랫폼 위에 두 가지를 남긴다. 고객의 온톨로지, 그리고 본사 제품에 반영된 현장의 요구사항.

알려진 운영 방식에 따르면 FDE는 주 4일을 고객 현장에서 보내되 하루는 반드시 플랫폼 엔지니어링에 쓴다. 같은 파견이라도 한쪽은 비용을 태우고, 다른 쪽은 자산을 적립한다.

그런데 왜 코드베이스가 분기하지 않을까

여기서 엔지니어라면 당연히 물어야 할 질문이 나온다. FDE가 고객마다 맞춤 작업을 하는데 왜 포크가 생기지 않는가.

답은 커스터마이징이 일어나는 계층을 강제로 분리했기 때문이다. 팔란티어의 플랫폼은 세 층으로 읽힌다.

  • 맨 아래, 모든 고객이 공유하는 단일 플랫폼 코어. 데이터 통합 플랫폼 Foundry, 정부·국방 특화 Gotham, 그리고 AI를 업무에 연결하는 AIP(Artificial Intelligence Platform)가 여기 속한다
  • 그 위에, 고객별로 정의되는 온톨로지와 파이프라인 설정
  • 맨 위에, 그 설정을 소비하는 애플리케이션 계층
팔란티어 플랫폼의 3계층 구조: 애플리케이션 계층, 고객별 온톨로지·파이프라인 설정, 단일 플랫폼 코어, 그리고 배포를 담당하는 Apollo
팔란티어 플랫폼의 3계층 구조: 애플리케이션 계층, 고객별 온톨로지·파이프라인 설정, 단일 플랫폼 코어, 그리고 배포를 담당하는 Apollo

FDE의 산출물은 원칙적으로 가운데 층에만 쌓인다. 코드 수정이 아니라 설정과 스키마 정의로 고객 특수성을 흡수하는, 말하자면 config over code 원칙이다.

이 원칙이 SI의 저주를 끊는 지점이다. 고객이 100이 되어도 유지보수해야 할 코어는 하나이고, 코어에 신기능이 들어가면 100개 고객이 동시에 받는다. 반대로 이 원칙이 무너지는 순간, 즉 납기에 밀린 FDE가 고객 전용 코드를 코어에 밀어 넣기 시작하는 순간 팔란티어는 비싼 SI 회사로 퇴화한다.

FDE에게 최상위급 엔지니어를 요구하는 이유도 여기 있다고 본다. 이 직무의 실질은 현장의 특수 요구를 받아 “설정으로 풀 문제”와 “코어에 범용 기능으로 넣을 문제”를 판별하는 일이고, 그 판별에는 시니어급 추상화 능력이 필요하다.

온톨로지: 데이터와 사용자 사이의 번역 계층

두 번째 질문. 비개발자 실무자가 노코드 도구로 직접 워크플로를 만드는 셀프서브가 어떻게 안전하게 가능한가.

온톨로지는 보통 “비즈니스 개체와 프로세스의 의미 지도”라는 은유로 소개되지만, 실체는 더 구체적이다. 복잡한 원천 데이터와 사용자 사이에 끼워 넣는 일종의 번역 계층이다. 원천 시스템의 테이블과 컬럼을 그대로 드러내는 대신 ‘주문’, ‘설비’, ‘환자’ 같은 도메인 객체와 그들 사이의 관계, 각 객체에 허용된 액션(재고 이동, 승인, 배차 변경)을 정의해 둔다. 실무자와 상위 애플리케이션은 원천 데이터가 아니라 이 계층만 바라본다.

손에 잡히는 그림으로 내려보자. 물류 회사의 배차 담당자가 노코드 빌더로 ‘지연 주문 재배차’ 워크플로를 만든다고 하자. 이 사람이 화면에서 다루는 것은 TMS와 ERP에 흩어진 수십 개의 테이블이 아니라 ‘배송 주문’, ‘차량’, ‘기사’라는 세 개의 객체, 그리고 ‘배차 변경’이라는 액션 하나다. 누가 어떤 주문을 바꿀 수 있는지, 변경이 어디에 기록되는지는 온톨로지 계층이 이미 정의하고 있으므로, 실무자가 실수로 원장 데이터를 깨뜨리거나 권한 밖의 조작을 만들어낼 경로 자체가 존재하지 않는다.

이 계층 분리가 셀프서브의 기술적 전제 조건이다. 노코드 빌더가 위험하지 않은 이유는 실무자가 만질 수 있는 것이 온톨로지에 정의된 객체와 액션뿐이고, 접근 권한과 데이터 이력(어디서 와서 어떻게 가공됐는지)이 그 계층에서 일괄 통제되기 때문이다.

AI를 업무에 붙이는 AIP도 같은 원리 위에 있다. 모델에게 원천 DB를 열어주는 게 아니라 온톨로지의 객체와 허용된 액션만 도구로 열어주니, AI가 엉뚱한 답(환각)을 내놓아도 그게 실제 시스템 오작동으로 번지는 경로가 구조적으로 차단된다. 2023년 이후 AIP가 빠르게 팔린 것은 우연이 아니다. 10년 넘게 깔아온 계층이 LLM 시대에 정확히 AI 에이전트의 안전장치 역할을 하게 된 것이다.

비즈니스 쪽에서 말하는 락인도 이 실체에서 나온다. 온톨로지는 데이터 사본이 아니라 그 조직의 업무 규칙과 권한 체계가 코드화된 산출물이다. 이탈하려면 데이터 마이그레이션이 아니라 조직 지식의 재구축이 필요하다.

인력 비례에서 사용량 비례로 갈아타는 순간

이제 한 고객의 생애주기를 따라가 보면, 인력 기반 사업이 셀프서브로 넘어가는 지점이 선명해진다.

진입은 AIP 부트캠프다. 긴 제안서와 PoC 협상 대신 고객의 실제 데이터로 며칠 안에 작동하는 결과물을 보여준다. 이게 가능한 이유도 앞의 아키텍처다. 코어는 이미 있고 온톨로지의 골격만 잡으면 되니, 데모까지의 시간이 주 단위가 아니라 일 단위로 줄어든다. 팔란티어 내부에서 FDE를 영업 비용이 아니라 파이프라인 그 자체로 취급하는 배경이다.

계약 후 FDE가 온톨로지를 완성하는 기간이 SI 구간이다. 이 구간이 끝나면 실무자들이 온톨로지 위에서 직접 워크플로를 만들기 시작하고, FDE는 다음 고객으로 이동하며, 매출은 투입 인력이 아니라 사용량을 따라 자란다. AI 사용량에 비례해 과금하는 토큰 기반 방식이 표준이 된 지금은, 고객당 매출 상한이 좌석 수가 아니라 AI가 수행하는 업무의 경제적 가치로 결정되므로 셀프서브 구간의 천장은 사실상 열려 있다.

정리하면 이렇다. 초기 인건비는 온톨로지라는 자산을 만드는 투자이고, 그 자산이 완성되는 순간 계정의 경제 구조가 인력 비례에서 사용량 비례로 갈아탄다. 팔란티어는 SI 구간을 피한 게 아니라, 의도적으로 통과한 뒤 빠져나올 출구를 아키텍처로 미리 파 둔 것이다.

남들이 못 베낀 나머지: 환류 조직과 Apollo

“현장에서 배운 것이 플랫폼에 흡수된다”는 플라이휠은 말은 쉽지만 조직 설계 없이는 작동하지 않는다.

팔란티어는 이를 FDE의 업무 구조 자체에 박아 넣었다. 주 1일의 플랫폼 데이 동안 FDE는 고객 특수 요구를 범용 기능 제안으로 일반화해 제품 팀에 밀어 넣고, 다른 FDE의 코드를 리뷰한다. 현장 조직과 제품 조직이 분리된 회사에서 흔히 죽어버리는 피드백 루프를 한 사람의 주간 루틴 안에 강제로 접합한 설계다. 이 루프가 돌수록 다음 고객의 도입 기간이 짧아지고, 같은 FDE 인원으로 더 많은 고객을 셀프서브 구간까지 밀어 넣을 수 있다. 인력 병목이 시간이 갈수록 헐거워지는 이유다.

마지막 퍼즐은 배포다. 팔란티어의 주력 고객은 외부 인터넷과 완전히 분리된 폐쇄망 환경의 정부·군 조직이다. 이런 환경에 흩어진 수백 개 배포 지점에 단일 코어의 업데이트를 계속 흘려보내려면 전용 배포 플랫폼이 필요하고, 그게 Apollo다. 각 환경의 제약(보안 등급, 가용 버전, 승인 상태)을 미리 정의해 두면, Apollo가 조건을 충족하는 환경부터 알아서 업데이트를 배포한다.

config over code가 “코어는 하나”를 보장한다면, Apollo는 “그 하나가 실제로 모든 현장에 도달한다”를 보장한다. 소프트웨어 회사에는 파견 조직이 없었고 컨설팅사에는 플랫폼이 없었다는 통상의 설명에 하나를 더하자면, 둘 다 있더라도 이 배포 인프라 없이는 규제 산업과 폐쇄망 시장에서 이 모델이 성립하지 않는다.

이 결과가 숫자로도 나타나고 있다. 정부 사업 회사라는 오랜 인식과 달리 2026년 중반 포브스 집계 기준 상업 부문이 매출의 46%까지 커졌고, 이 글을 쓰는 주에 발표된 2026년 2분기 실적에서는 미국 상업 부문 매출이 전년 대비 149% 성장하며 전체 매출 성장률 93%를 끌어올렸다.

물론 공짜는 아니다

이 모델의 아름다움은 전환이 실제로 일어난다는 전제 위에 서 있고, 그 전제는 여러 방향에서 흔들릴 수 있다.

진입 구간의 인력 병목은 구조적으로 남는다. 설정과 코드의 경계를 판별할 수 있는 시니어급 인재는 희소하고, 신규 고객 확보 속도는 이들의 채용 속도에 묶인다. 초기 배치 비용 때문에 중소기업 시장은 사실상 닫혀 있다.

config over code는 원칙이지 물리 법칙이 아니다. 앞서 말한 ‘코어 오염’ 시나리오, 즉 납기 압박 속에서 고객 전용 로직이 회색 지대로 스며드는 것을 막는 일은 끝나지 않는 거버넌스 싸움이다. 온톨로지 자체도 양날의 검이다. 깊어질수록 이탈 비용이 커지는 것이 해자인 동시에, 계약 테이블에서 신규 고객이 주저하는 이유가 된다.

반론도 있다. FDE 방식은 실시간 조정이 필요한 역동적 환경에서는 유효하지만 거버넌스와 릴리스 프로세스가 엄격한 안정적 시스템에서는 오히려 리스크를 키울 수 있다는 분석이 나온다. 같은 방식을 쓰는 Kinaxis는 도메인 전문성 없는 FDE는 의미가 없다고 주장하고, Anaplan은 이 개념 자체가 과대포장이라고 본다.

그리고 가장 큰 위협은 서두의 장면, 즉 성공 그 자체다. OpenAI는 2026년 5월 TPG가 주도한 19개사 컨소시엄에서 40억 달러 이상을 조달한 자회사 ‘OpenAI Deployment Company’를 출범시켰고, EY와 Salesforce까지 FDE 조직을 공식화했다. 다만 엔지니어링 관점에서 보면 모방자들이 복제한 것은 아직 인력 운용 방식이지, 20년간 적립된 온톨로지 자산과 config over code를 지탱하는 플랫폼, 폐쇄망 배포 인프라가 아니다. 프론티어 랩의 최신 모델이 이 축적을 우회할 수 있는가가 다음 관전 포인트다.

만드는 사람에게 남는 질문

팔란티어 규모의 이야기지만, 구조 자체는 제품을 만드는 누구에게나 적용해볼 만하다. 세 가지 질문으로 압축해 본다.

  1. 지금 고객별 대응으로 하고 있는 작업 중, 설정으로 내려갈 수 있는 것과 코어에 들어가야 할 것을 구분하고 있는가. 그 경계를 판별하는 사람은 누구인가.
  2. 고객 현장의 발견이 제품으로 되돌아오는 루프가 조직도 상에 존재하는가, 아니면 선의에 기대고 있는가.
  3. 우리가 고객에게 남기는 것은 산출물인가, 자산인가.

팔란티어가 특별한 건 FDE라는 직무를 만들어서가 아니다. 이 세 질문에 20년 전부터 아키텍처와 조직 구조로 답을 박아놓았기 때문이다.

참고 자료

GitHub에서 보기

댓글