FDE가 만드는 결과물은 ChatAPI여야 한다

최근 FDE라는 직군이 급속도로 주목받고 있다.

FDE는 AI 도입 방침을 제안하는 컨설턴트가 아니다. 기성(既成) SaaS를 고객별로 설정하기 위한 상주 엔지니어도 아니다.

고객의 업무에 들어가서 풀어야 할 문제를 특정하고, 필요한 데이터와 시스템을 연결하며, 현장에서 작동하는 소프트웨어를 구현한다. 그리고 개별 현장에서 얻은 지견을 재사용 가능한 제품의 능력으로 되돌린다.

이것이 FDE이다.

FDE는 기반 모델 기업과 고객 기업 사이에서 현실(reality)과 제품(product)을 상호 변환하는 역할을 한다.

고객의 요구대로 애플리케이션만 만드는 것이라면 수주 개발(受託開発)에 불과하다. FDE는 고객 고유의 현실과 자사가 가진 범용적인 기술 기반 사이에 서서, 현장에서만 관측할 수 있는 문제를 소프트웨어로 변환한다.

FDE란 현실로부터 제품을 학습시키는 메커니즘이다.

그리고 FDE는 LLM(대규모 언어 모델)과 함께 탄생한 직업이 아니다.

FDE라는 업무 방식을 오랫동안 실천해 온 대표적인 기업이 Palantir이다.

Palantir는 2003년에 설립되었으며, 미국 정보기관의 테러 대책을 위한 소프트웨어 개발에서 시작되었다. 2008년에는 정보·방위 기관을 위한 최초의 플랫폼인 Gotham을 제공했다. 현재와 같은 거대 언어 모델이 등장하기 훨씬 이전의 일이다.[1]

FDE는 LLM 이전에 존재했으며, 데이터 통합과 업무 구현의 시대부터 연속되어 왔다.

Palantir의 FDE는 고객으로부터 요구사항을 듣고 가져가기만 한 것이 아니었다.

아프가니스탄 군사 기지나 미국 중서부 공장까지 가서, 실제로 소프트웨어가 사용되는 현장에 들어갔다. 그곳에서 사용자가 무엇을 보고, 어떻게 판단하며, 어디에서 기존 시스템에 막히는지를 관찰하면서 Gotham이나 Foundry를 구현했다.

현장에서 얻은 지견은 그 고객만의 커스터마이징에 가둘 수 없다. 여러 현장에서 이용할 수 있는 형태로 추상화되어 Palantir의 공통 제품으로 되돌아간다. Palantir는 현재 이 개발 방식을

이러한 방식으로, 기업에 존재하는 대상(entity), 그 속성(attribute), 대상 간의 관계(relationship), 그리고 실행 가능한 조작을 정의하는 것이 Ontology입니다.

Ontology는 분산된 업무 데이터를 현실의 대상과 관계로 재구성하는 것입니다.

Palantir는 2020년 상장 자료에서 이미 Ontology를 객체, 속성, 관계로부터 조직 고유의 세계를 기술하는 메커니즘으로 설명했습니다. 구축된 Ontology로부터는 조직 고유의 애플리케이션이나 워크플로우를 개발하기 위한 SDK도 생성할 수 있었습니다.[2]

현재 Palantir는 더욱 명확하게 Ontology를 기업의 데이터, 로직, 액션, 보안을 하나로 통합하는 오퍼레이션 레이어(operation layer)로 정의하고 있습니다.[4]

Ontology는 데이터를 정리하기 위한 분류표가 아닙니다.

그것은 기업에 무엇이 존재하며, 그것들이 어떻게 연결되어 있고, 어떤 판단을 내리고, 무엇을 실행할 수 있는지를 표현한, 기업의 조작 가능한 모델입니다.

즉, Palantir의 FDE가 만들고 있던 것은 개별적인 화면만이 아니었습니다.
개별 애플리케이션을 몇 번이고 만들어낼 수 있는, 기업 고유의 시스템이었습니다.

기반모델(Foundation Model) 기업들은 '세계 모델을 만든다'고 명시적으로 선언하는 것은 아닙니다.
하지만 기반모델 간의 경쟁은 세계 일반에 존재하는 언어, 지식, 절차, 인과관계, 추론 패턴을 더 넓고 높은 정확도로 파라미터 안에 압축하는 경쟁이 되고 있습니다.

그럼에도 불구하고, 아무리 성능이 뛰어난 모델이라도 어떤 회사의 '매출'이 무엇을 의미하는지는 모릅니다.
주문 접수 시점의 금액인지. 납품 완료된 금액인지. 청구된 금액인지?
어떤 테이블을 기준으로 삼아야 하는지. 주문, 계약, 납품, 청구가 어떻게 연결되어 있는지. 어떤 직원이 할인을 승인할 수 있는지. 현재 어느 공장에서 무엇이 일어나고 있는지.

이러한 정보는 기업마다 다르고 매일 변화합니다.

기업의 현재 상태나 권한 체계를 모델의 파라미터에 구워 넣어서는 안 됩니다. 필요한 것은 범용 모델을 회사별로 다시 만드는 것이 아니라, 범용 모델 외부에 회사 고유의 세계를 구축하는 것입니다.

LLM 프로바이더가 세계 일반에 대한 파라메트릭한 지능을 만듭니다.
FDE는 그 지능이 어떤 회사의 내부에서 성립하기 위한 비파라메트릭적인 시스템을 만듭니다.

LLM 프로바이더는 세계 일반을 만들고, FDE는 회사 고유의 시스템을 만듭니다.

그 시스템에는 단순한 사내 문서뿐만 아니라, 현재 업무 데이터, 기업 고유의 개념과 관계, 기준으로 삼는 데이터의 정의, 업무상의 계산이나 판단 로직, 실행 가능한 액션, 권한과 승인, 감사 이력(audit history), 그리고 답변이나 행동을 검증하는 평가 시스템이 포함됩니다.

FDE의 역할은 회사의 지식을 LLM에게 기억시키는 것이 아닙니다.
세계 일반을 다룰 수 있는 지능을 어떤 회사의 현실에 접지시키는 것입니다.

지금까지 FDE는 구축한 데이터 기반(data foundation)이나 Ontology 위에 대시보드, 검색 화면, 시뮬레이션, 승인 플로우, 알람 등의 애플리케이션을 만들어 왔습니다.
애플리케이션은 필요합니다.
매일 반복하는 작업, 입력 형식이 정해진 작업, 목록성이 중요한 작업, 오조작의 위험이 큰 작업은 챗봇보다 전용 화면이 더 빠르고 안전하기 때문입니다.

문제는 애플리케이션을 FDE의 최종 결과물이라고 생각하는 데 있습니다.
애플리케이션은 만들어지는 시점에 예상되었던 질문과 조작을, 화면으로 고정시킨 것입니다.

'납기가 지연될 것 같은 주문을 목록으로 표시하기'
'재고가 일정 수준 이하로 떨어지면 알림 보내기'
'신청을 확인하고 승인하기'

이러한 요구에는 강합니다.
하지만 현장에는 사전에 화면에 고정할 수 없는 질문이 항상 발생합니다.

'이번 주 지연 건 중 이익률이 높은 고객에게 영향을 주는 것만 보여줬으면 좋겠다.'
'이 부품을 다른 공장으로 옮겼을 경우, 다음 달 생산 계획에 어떤 영향이 있을까?'
'같은 원인으로 과거에 발생했던 장애와 그때 채택했던 대응책을 조사해 줬으면 한다.'

새로운 질문이 생길 때마다 FDE가 돌아와서 새로운 화면과 API를 만들어야 한다면, 기업의 시스템은 아직 소프트웨어화되지 않은 것입니다.
고정된 애플리케이션만 늘어난 것일 뿐입니다.

FDE가 만들어야 하는 것은 하나의 거대한 만능 챗봇이 아닙니다.
기업의 Ontology에 연결되어 특정 업무 영역에 대해 자연어로부터 읽기 및 조작을 할 수 있는, 최소 단위의 Chat API 모듈입니다.

이 Chat API는 단순히 질문 문장을 LLM에게 보내는 엔드포인트가 아닙니다.
사용자의 언어를 기업 고유의 개념으로 변환하고, 필요한 데이터를 가져오고, 관련된 업무 로직을 호출하며, 권한을 확인하고, 필요하다면 액션을 실행합니다.

그리고, 무엇을 근거로 답변했는지, 어떤 데이터를 읽었는지, 어떤 작업을 수행했는지를 추적할 수 있어야 한다.

따라서 Chat API는 최소한 LLM(대규모 언어 모델), Ontology(온톨로지), 현재 데이터, 업무 로직, Actions(실행 기능), 권한, 감사(Audit), Evals(평가)라는 요소들로 구성되어야 한다.

이러한 일련의 연결이 완성되었을 때 비로소 범용 모델은 해당 기업에서의 지능으로 성립한다.

Chat API는 채팅 화면 그 자체를 의미하지 않는다.

Slack에서 호출될 수도 있고, 음성 인터페이스에 연결될 수도 있으며, 기존 업무 애플리케이션에 내장될 수도 있다. 백그라운드에서 작동하는 에이전트로부터 이용될 수도 있다.

중요한 것은 UI가 아니라, 기업의 시스템(系)에 대해 언어를 공통 형식으로 읽고 쓸 수 있다는 것이다.

그러므로 결과물은 챗봇(chat bot)이 아니라 Chat API인 것이다.

Chat API는 채팅 화면이 아니라, 기업 시스템에 대한 공통 인터페이스이다.

Chat API와 애플리케이션은 대립하지 않는다.

오히려, Chat API를 사용하는 과정에서 빈번하게 반복되는 대화나 작업이 발견되면, 그것을 전용 UI로 고정하면 된다.

매일 아침 '어제부터 납기 리스크가 상승한 주문을 고객 중요도 순으로 표시해 줘'라고 입력한다면, 그 대화는 대시보드로 만들 수 있다.

매번 '이 재고 이동안에 대해 영향 범위를 확인하고, 문제가 없으면 승인자에게 보내줘'라고 요청한다면, 그 대화는 버튼과 승인 플로우로 만들 수 있다.

즉, 애플리케이션이란 빈번하게 발생하는 대화를 빠르고 안전하며 재현 가능하게 실행하기 위해 컴파일된 것이다.

Chat API는 미지의 질문, 예외, 탐색을 다룬다.

애플리케이션은 알려진 질문을 빠르게 처리한다.

자동 처리는 대화할 필요조차 없게 된 처리를 수행한다.

세 가지는 별개의 시스템이 아니다. 동일 기업의 시스템에 대한 서로 다른 인터페이스일 뿐이다.

애플리케이션은 빈번하게 발생하는 대화를 컴파일한 것이다.

이 주장은 Palantir의 사상에 Chat API를 억지로 붙인 것이 아니다.

Palantir의 Ontology SDK는 Ontology에 대한 읽기/쓰기를 TypeScript, Python, Java, OpenAPI 등에서 이용할 수 있게 하여, 기업 고유의 애플리케이션을 Ontology 위에 구축할 수 있게 한다.[5]

나아가 현재 AIP Chatbot Studio에서는 기업 고유의 Ontology 데이터와 도구를 제공한 대화형 시스템을 만들고, Ontology 편집, 업무 액션 자동화, 워크플로우 실행까지 할 수 있다. 구축된 챗봇은 Palantir 내부뿐만 아니라 API를 통해 외부 애플리케이션에도 내장할 수 있다.[6]

LLM 이전의 Palantir는 기업을 기계가 읽고 조작 가능한 형태로 만들었다.

현재의 Palantir는 그 기업에 자연어로부터 접근하는 인터페이스를 붙이기 시작했다.

FDE의 본질은 변하지 않았다.

Ontology 위에 새로운 입구가 추가된 것뿐이다.

OpenAI는 2026년 5월, 기업 도입을 담당할 OpenAI Deployment Company를 설립하고, 약 150명의 FDE와 Deployment Specialist를 보유한 Tomoro의 인수에 합의했다. 또한 같은 해 7월에는 Palantir의 최상위 파트너 네트워크 최초 기업이었던 Northslope 인수에도 합의했다. 모두 발표 시점에서는 필요한 승인 등을 조건으로 하는 계약 단계이다.[7]

이는 기반 모델의 성능이 향상된다고 해서 기업 도입이 자동으로 진행되는 것은 아님을 보여준다.

모델이 세계 일반에 대해 똑똑해져도, 기업 데이터가 분산된 채로 남아있다면 사용할 수 없다.

기업 고유의 개념이 정의되어 있지 않으면 질문을 올바르게 해석할 수 없다.

실행 가능한 액션이나 권한이 연결되어 있지 않으면 답변만 하고 끝난다.

평가 시스템(Evals)이 없으면 그 답변을 실제 업무에서 신뢰하기 어렵다.

OpenAI의 FDE 채용 정보에서도, FDE의 성공은 데모 완성도가 아니라, 현장 이용, 업무에 대한 실질적인 영향, 그리고 평가를 통해 얻은 피드백이 모델이나 제품의 로드맵을 바꿈으로써 측정된다.[8]

이는 Palantir의 FDE와 같은 구조이다.

현장에 들어가서 작동하는 것을 만들고, 현실에서 얻은 오차 신호를 제품으로 되돌리는 것이다.

다른 점은, Palantir가 데이터와 운영 플랫폼에서 시작한 것에 비해, OpenAI는 범용 모델에서 시작했다는 점뿐이다.

양자는 반대편에서 같은 장소를 향하고 있다.

Palantir와 OpenAI는 반대편에서, Ontology에 연결된 Chat API로 수렴한다.

FDE의 성과를 만든 애플리케이션의 개수로 측정해서는 안 된다.

10개의 업무 앱을 만들었더라도, 11번째 질문이 발생할 때마다 새로운 개발이 필요하다면, 기업의 이해도는 개별 구현에 가두어진 상태로 남게 된다.

FDE가 떠난 후에도 남아 있어야 하는 것은, 새로운 질문에 대해 동일한 기업 지식을 재사용할 수 있는 구조이다.

• 기업의 대상과 관계가 Ontology(온톨로지)로 정의되어 있다.
• 현재 상태에 접근할 수 있다.
• 업무 로직과 액션이 연결되어 있다.
• 권한 및 감사 기능이 내장되어 있다.

그리고, 그 능력을 자연어로부터 호출할 수 있다.

여기까지 구축되었을 때 비로소 FDE가 범용 지능(汎用知能)을 회사 시스템에 구현했다고 말할 수 있다.

FDE가 만들어야 하는 것은 애플리케이션이 아니다.

필요한 만큼의 애플리케이션을 생성할 수 있는 기업 고유의 시스템과, 그 시스템에 언어로 접근하기 위한 Chat API이다.