팔란티어가 FDE라는 사람을 AI로도 만들었다 — AIP ‘AI FDE’ 완전 가이드

팔란티어의 사람 직군이던 FDE(Forward Deployed Engineer)가, 이제는 AIP 안에 있는 에이전트 이름이기도 하다

이름부터 헷갈린다

이 블로그에서 이미 FDE, PI 컨설턴트, 솔루션 아키텍트 글을 통해 FDE가 무엇을 하는 사람인지 정리한 적이 있다. 그런데 2025년 11월부터 팔란티어는 같은 이름을 AIP 안의 기능에도 붙였다. AIP를 쓰는 조직이라면 사이드바에서 “AI FDE”라는 항목을 보게 될 텐데, 이건 사람이 아니라 대화형 에이전트다.

이름을 그대로 가져온 건 우연이 아니다. FDE라는 직군이 하던 일 — 자연어로 요구사항을 듣고, 데이터를 연결하고, 온톨로지를 만들고, 화면까지 붙이는 것 — 을 이 에이전트가 대화로 대신하겠다는 선언이다. 이 글은 이 기능이 실제로 뭘 하는지, 8개월 동안 어떻게 성숙했는지, 개발 가능한 9개 영역을 실제로 어떤 순서와 방식으로 쓰는지, 그리고 어디까지 믿어도 되는지를 공식 자료·커뮤니티 노하우·실사용자 반응·외부 평가까지 근거로 정리한다.

먼저 이름부터 정확히 짚고 가면, 공식 문서는 이 기능을 다음과 같이 소개한다.[1]

“AI FDE, the AI-powered forward deployed engineer, is an interactive agent that operates Foundry for you through conversational commands.”

즉 “AI”와 “FDE”를 각각 별도 약어로 붙인 게 아니라, 사람 직군 이름 FDE(Forward Deployed Engineer) 앞에 “AI가 대신한다”는 뜻의 AI-powered를 붙인 것이다. 풀어 쓰면 “AI-powered Forward Deployed Engineer”가 정확한 표기다.

AI FDE가 하는 일

공식 문서에 따르면 AI FDE는 “대화형 명령으로 Foundry를 대신 운영해주는 상호작용형 에이전트”다.[1] 자연어 요청을 Foundry 내부 작업으로 번역해서, 매번 화면을 직접 조작하지 않아도 되게 만드는 것이 핵심이다. 이를 통해 데이터 변환(transform) 작업, 코드 리포지토리 관리, 온톨로지 구축·유지, 관련 문서 조회까지 수행할 수 있다고 공식 문서는 설명한다.[1]

동작 방식은 “의도와 맥락을 분석 → 적절한 작업 결정 → 네이티브 도구로 실행 → 결과 설명”의 폐루프(closed-loop) 구조다.[1] 모델이 작업을 실행하고, 결과를 관찰하고, 그 피드백으로 다음 작업을 결정하는 방식이라 여러 단계로 이어지는 작업도 처리할 수 있다. 모델은 Anthropic, OpenAI, Google, xAI를 모두 지원하며, 조직이 이미 쓰는 LLM 계정을 그대로 연결할 수 있다.[1]

눈에 띄는 설계 원칙 하나는 컨텍스트를 기본적으로 최소로 시작한다는 점이다. 공식 문서는 이를 “컨텍스트 오염(context pollution)”을 막기 위한 설계라고 밝힌다.[1] 필요한 정보는 사용자가 폴더·데이터셋·문서를 직접 드래그 앤 드롭으로 끌어와 컨텍스트를 넓히는 방식이다 — 처음부터 이것저것 다 붙여주는 게 아니라, 필요한 만큼만 열어주는 쪽으로 설계되어 있다는 뜻이다. 이 원칙은 뒤에서 다룰 “필요한 컨텍스트와 도구만 제공하라”는 베스트 프랙티스와 그대로 이어진다.

베타부터 지금까지 — 8개월의 타임라인

베타 출시 후 4개월 만에 GA로 전환됐고, 이후로는 매달 크지 않은 개선(탐색 편의, 시각화)이 이어지는 흐름이다.

개발 가능한 9가지 영역 — 모드 체계

AI FDE는 하나의 거대한 만능 에이전트가 아니라, 작업 성격에 따라 9가지 모드로 전환하며 동작한다. 각 모드는 필요한 도구와 접근 범위를 그때그때 좁혀서 활성화하도록 설계되어 있다.[6] 모드를 잘못 고르거나 전환을 놓치면 — 뒤에서 다룰 “도구 자동 해제” 문제처럼 — 엉뚱한 데서 막힌다.

이 모드 구분과 별개로, AI FDE는 에이전트 자체 기능(모드 전환, 명확화 질문, 계획 생성 후 검토, 문서 로딩, 컨텍스트 관리)과 도메인 기능(파일시스템 조작, Notepad 문서 관리, Solution Design 다이어그램, 온톨로지 객체 대상 액션 실행)을 구분해서 제공한다.[6]

작업 흐름별 모드 전환 순서

데이터 소스 연동부터 최종 애플리케이션까지 간다면, 대체로 이 순서로 모드를 넘나든다.

Exploration → Data Connection → Data Integration → Ontology Editing → Functions Editing → OSDK React
                                                     (전 단계에 걸쳐 Governance·Approval 확인)

1단계 — 조사와 소스 연동(Exploration → Data Connection) Exploration 모드로 먼저 기존 스키마·데이터셋 구조를 살핀다. 읽기 전용이라 플랫폼을 건드릴 위험 없이 “지금 뭐가 있는지”부터 파악할 수 있다. 조사가 끝나면 Data Connection 모드로 넘어가 외부 DB나 ERP(SAP ECC 등) 커넥터와 Egress 네트워크 정책을 정의한다.

2단계 — 파이프라인과 온톨로지 구축(Data Integration → Ontology Editing) Data Integration 모드에서 Python Transforms나 Pipeline Builder로 정제·중복 제거·결합 로직을 만든다. 그다음 Ontology Editing 모드에서 이 데이터셋을 Object·Link·Action으로 매핑한다.

3단계 — 비즈니스 로직과 앱 연동(Functions Editing → OSDK React) Functions Editing 모드로 온톨로지 위에서 동작할 규칙을 TypeScript나 Python으로 작성하고, OSDK React 모드로 넘어가 이 온톨로지·함수를 쓰는 앱이나 위젯을 만든다.

Governance 모드는 위 단계 전체에 걸쳐 병행한다 — 권한·마킹이 의도대로 걸려 있는지는 마지막에 몰아서 확인하는 것보다 단계마다 확인하는 편이 사고를 줄인다.

안전장치와 공식 베스트 프랙티스

에이전트가 온톨로지를 직접 편집하고 함수를 게시하는 수준까지 간다면, 가장 먼저 나올 질문은 “잘못 건드리면 어떻게 되나”다. 공식 문서가 명시한 안전장치는 세 가지다.[1]

• 권한 상속: 모든 작업은 “사용자의 기존 권한을 그대로 따른다” — AI FDE가 사용자보다 더 넓은 권한으로 동작하지 않는다.
• 도구·맥락 제어: 사용자가 에이전트에게 어떤 도구를 쓰게 할지, 어떤 정보를 보여줄지를 직접 통제할 수 있다.
• 검증 후 반영: 변경 사항은 Foundry의 브랜칭(Branching) 위에서 먼저 시험하고, 변환 미리보기(Transform Preview)·함수 미리보기(Function Preview)와 CI 체크를 돌린 뒤에 병합한다.

여기에 공식 베스트 프랙티스 문서가 덧붙이는 실무 원칙은 다음과 같다.[7]

• 프로덕션 반영 전 항상 생성된 리소스 검증(샘플 데이터로 변환 로직 테스트, 코드 리뷰)
• 작업에 꼭 필요한 컨텍스트와 도구만 제공 — 불필요한 접근은 성능 저하와 보안 리스크로 이어진다
• 복잡한 작업은 작은 단계로 분해, 기본 구조부터 검증 후 점진적으로 복잡도 추가
• AIP Evals로 함수 성능을 반복적으로 측정
• 도구 승인이 필요한 작업은 실행 전 반드시 확인

권한 상속과 브랜치 기반 검증이라는 설계 자체는 합리적이다. 다만 이건 “설계상 안전하게 만들었다”는 벤더의 설명이고, 실제 운영 환경에서 얼마나 신뢰할 수 있는지는 별개 문제라는 점은 뒤에서 다시 짚는다.

커뮤니티 노하우 — Operator Framing Convention

GitHub 커뮤니티 라이브러리 palantir-ai-fde-library는 AI FDE를 대화형 어시스턴트가 아니라 “배포 명령 실행기”로 다루라고 제안한다.[8] 모호한 요청은 출력의 불확실성을 높이므로, 구체적인 파라미터를 못박은 “오퍼레이터 명령” 스타일이 실행 결과를 안정적으로 만든다는 것이다. 이 라이브러리는 사람 FDE, 데이터 엔지니어, 온톨로지 오너, 앱 개발자, 플랫폼 관리자 다섯 페르소나를 대상으로 프롬프트 템플릿(최소 컨텍스트, 필요 도구, 예상 동작, 검증 체크리스트, 알려진 실패 모드)을 제공하며, 2026년 3월 12일 GA와 동시에 공개됐다.

나쁜 예 (대화형)

“SAP 테이블 연결해서 고객 데이터 파이프라인 좀 만들어줘.”

나은 예 (Operator Framing)

[Target Component]: Data Integration (Python Transform)
[Source Dataset]: /Company/Raw/SAP_KNA1
[Primary Key]: KUNNR (Deduplication required)
[Destination]: /Company/Cleaned/Customer_Master
[Expected Output]: PySpark transformation script handling null values in 'NAME1'.

이 방식은 “작업에 꼭 필요한 컨텍스트만 준다”는 공식 베스트 프랙티스와도 맞아떨어진다. SAP ECC → S/4HANA 같은 복잡한 마이그레이션도 이 라이브러리에 패턴으로 문서화되어 있다.

실사용자가 실제로 겪은 문제와 대응

아래는 팔란티어 공식 파트너 채널 Ontologize의 “AI FDE 시작하기” 데모 영상(조회수 4.5천, Gena가 데이터 파이프라인 구축을 시연)[9] 댓글에서 실사용자들이 남긴 내용을 정리한 것이다. 공식 문서에는 안 나오는, 실제로 부딪힌 지점이다.

긍정적인 반응도 있다. 한 비전문가 사용자는 “이걸로 내 앱을 직접 만들고 업무에서 더 쓸모 있어졌다”며, 세션이 끝난 뒤 Notepad로 작업 맥락을 정리해두는 방식을 컨텍스트 관리 팁으로 공유했다 — 위 표의 “세션 로딩 지연” 대응과도 같은 방향이다. 또 다른 사용자는 임상시험 관련 시각화를 만들다 포맷 불일치 문제를 겪었는데, AI FDE가 원인을 짚고 수정을 제안해준 사례를 남겼다.

같은 채널에는 “FDE가 AI FDE를 활용하여 온톨로지 함수를 작성하는 방법”, “FDE가 AI FDE를 활용하는 방법: 음성 지원 OSDK 애플리케이션 구축하기” 데모도 이어서 올라와 있다 — 각각 Functions Editing과 OSDK React 모드를 실제로 쓰는 장면을 보여준다.

AI FDE는 사람보다 훨씬 빠르게 연속 작업을 처리한다 — 몇 분 안에 수십 건이 오갈 수 있다. 이 속도가 스토리지 I/O나 GPU 같은 인프라 자원에 예상 못 한 부하를 줄 수 있다는 게 공식 베스트 프랙티스의 경고다.[7] 고빈도 병렬 작업을 시킬 계획이라면, 플랫폼 쪽 용량도 미리 점검해두는 게 안전하다.

회의적인 시선도 함께 봐야 한다

포브스가 2026년 7월에 정리한 팔란티어 FDE 모델 비판 기사를 보면, AI FDE 기능이 아니라 FDE 방식 자체에 대한 두 가지 지적이 있다.[10]

Anaplan CEO 찰리 갓디너는 FDE 방식이 “영업 전술이나 빠른 PoC에는 효과적이지만 장기적으로는 문제”라고 평가한다. 고객 조직에 깊이 파고들어 커스터마이징하는 방식이 결국 “고객이 유지보수·변경 비용을 영구적으로 지불해야 하는” 락인을 만든다는 것이다.

팔란티어 출신인 Kinaxis의 마닉 샤르마는 실행 측면을 짚는다. “25살짜리 엔지니어를 고객사에 붙이는 데는 문제가 있다”는 것 — 도메인 지식(이 경우 서플라이체인)이 부족한 상태에서 현장에 투입되는 구조적 한계다.

같은 기사가 인용한 MIT Media Lab 2025년 연구는 생성형 AI 파일럿 프로젝트의 95%가 실질적인 비즈니스 가치를 내지 못했다고 보고한다.[10] AI FDE도 결국 이 통계가 말하는 “파일럿은 됐는데 실전은 안 되는” 함정을 피해가야 하는 입장이다.

이 비판은 사람 FDE 모델을 향한 것이지 AI FDE 기능 자체에 대한 평가는 아니다. 하지만 AI FDE가 노리는 것이 정확히 “사람 FDE가 하던 일을 대화로 대신하는 것”이므로, 같은 구조적 한계(락인, 도메인 지식 부족)를 에이전트 버전에서도 다시 물어볼 필요가 있다.

실무자 입장에서 보면

이 기능을 실제로 검토한다면 다음 순서로 판단하는 걸 권한다.

1. Exploration·Platform Q&A부터 써본다. 온톨로지를 건드리지 않는 읽기 전용 영역이라 리스크가 낮다. 여기서 먼저 응답 품질을 확인한다.
2. 쓰기 작업(Data Integration 이후)은 반드시 브랜치 위에서. 공식 문서도 권장하는 방식이고, 실수의 비용을 되돌릴 수 있게 만드는 최소한의 안전장치다.
3. 모드 전환 직후 Tools 메뉴부터 확인한다. 위에서 정리한 실사용자 불만(도구 자동 해제) 그대로다 — “왜 안 되지”로 시간 쓰기 전에 먼저 체크할 항목.
4. Operator Framing 스타일로 요청을 구체화한다. “~해줘” 대신 대상 컴포넌트·소스·키·목적지를 명시하면, 같은 모드 안에서도 결과가 훨씬 안정적이다.
5. “대화로 되니까 온톨로지 설계를 안 해도 된다”는 기대는 하지 않는다. AI FDE는 실행을 대신해주는 도구이지, 무엇을 Object로 만들지 판단하는 주체가 아니다. 이 판단이 서 있지 않으면 에이전트도 잘못된 걸 빠르게 만들어줄 뿐이다.

정리하면

AI FDE는 팔란티어가 사람이 하던 배치형 커스터마이징 작업(FDE 모델)을 9가지 모드로 나눈 에이전트로 옮기려는 시도다. 권한 상속·브랜치 기반 검증 같은 설계는 합리적이고, 베타에서 GA까지 4개월이라는 속도도 빠른 편이다. 다만 이 기능이 겨냥하는 원본 모델(FDE) 자체가 락인·도메인 지식 부족이라는 비판을 받아온 만큼, “대화로 다 된다”는 마케팅 메시지보다는 모드 전환 규율·Operator Framing 같은 실전 요령과 브랜치·권한 통제 같은 안전장치를 실제로 어떻게 쓰는지가 판단의 핵심이 될 것이다.

자주 묻는 질문

Q. AI FDE를 쓰려면 별도 라이선스가 필요한가요? AIP가 활성화된 인롤먼트에서 관리자 승인을 받아 활성화하는 방식입니다. 별도 제품이 아니라 AIP의 기능입니다.

Q. 온톨로지를 직접 수정한다는데, 실수하면 되돌릴 수 있나요? 공식 문서는 브랜칭(Branching) 위에서 먼저 변경하고 병합 전에 변환 미리보기·CI 체크를 거치도록 권장합니다. 다만 이건 “권장 사용법”이지 강제되는 안전장치는 아니므로, 실제로 이 절차를 지키는지는 운영 조직의 책임입니다.

Q. 세션이 길어져서 컨텍스트가 꽉 찼을 때는 어떻게 하나요? 꼭 필요한 문서·데이터셋·함수만 컨텍스트로 추가하는 게 기본입니다. 작업이 길어지면 중간 요약을 Notepad에 남기고 새 세션을 열어, 그 Notepad를 컨텍스트로 다시 불러오는 방식이 실사용자들이 겪은 “세션 먹통” 문제도 함께 피해갑니다.

Q. Operator Framing Convention은 공식 권장 사항인가요? 아니요. GitHub 커뮤니티가 만든 비공식 라이브러리에서 나온 방법론입니다. 다만 “필요한 컨텍스트만 정확히 준다”는 공식 베스트 프랙티스의 방향과 일치하기 때문에 참고할 만합니다.

Q. 이 글에서 말하는 “FDE 방식에 대한 비판”이 AI FDE 기능에도 그대로 적용되나요? 직접적인 평가는 아닙니다. 인용한 비판은 사람 FDE 모델(고객사 상주형 커스터마이징)을 향한 것입니다. 다만 AI FDE가 같은 작업 방식을 에이전트로 옮긴 것이므로, 락인·도메인 판단력 부족이라는 같은 종류의 질문을 다시 던져볼 가치는 있습니다.

참고자료

[1] Palantir, AI FDE • Overview, Foundry 공식 문서.

[2] Palantir, November 2025 • Announcements, Foundry 공식 릴리스 노트.

[3] Palantir, March 2026 • Announcements, Foundry 공식 릴리스 노트.

[4] Palantir, May 2026 • Announcements, Foundry 공식 릴리스 노트.

[5] Palantir, July 2026 • Announcements, Foundry 공식 릴리스 노트.

[6] Palantir, AI FDE • Modes and skills, Foundry 공식 문서.

[7] Palantir, AI FDE • Best practices, Foundry 공식 문서.

[8] GitHub, palantir-ai-fde-library — Operator Framing Convention 커뮤니티 프롬프트 라이브러리.

[9] Ontologize, AI FDE 시작하기, YouTube — 데이터 파이프라인 구축 데모 및 실사용자 댓글.

[10] Steve Banker, Palantir And Forward Deployed Engineering: What Should We Believe?, Forbes, 2026-07-10.

다음으로 읽어볼 글

• FDE, PI 컨설턴트, 솔루션 아키텍트 — 팔란티어 현장에서 만나는 세 역할은 무엇이 다른가
• AI가 초안을 짜고, 사람이 서명한다 — AIP 에이전트 워크플로우 설계법
• 팔란티어는 비싸다 — 그런데도 쓰는 이유