"FDE는 ‘AI 코딩 잘 하는 개발자’가 아니다"
경기도청 AI국과 첫 미팅을 진행했다. 지난 서울대 컴공 GenAI 강연 이후 이어진 팔로우업 미팅이었다. 국장님을 비롯해 AI 정책과 실행을 담당하는 여러 과장님, 팀장님들과 FDE 정책을 포함한 경기도청 AX 로드맵에 대해 꽤 깊은 이야기를 나눴다.
내가 가장 강조한 것은 FDE를 ‘AI 코딩 잘하는 개발자’로 정의하면 안 된다는 것이었다. FDE는 현업 부서에 들어가 요구사항을 받아 코딩해주는 SI 개발자가 아니다. 특정 도메인의 고객 현실 속에 깊숙이 임베딩되어 현업의 문제를 이해하고, 그것을 기술적으로 다시 정의하고, 해결책을 설계하고, 직접 아키텍처를 세우고 코드를 작성해 production까지 책임지는 end-to-end ownership을 가진 엔지니어다.
미국에서 시작된 FDE의 원형을 가장 압축해서 설명한다면 Software Engineer + Solution Architect + Product Manager + Domain Consultant의 일부 역할을 한 사람이 동시에 수행하는 직군이다. 하지만 중심 정체성은 어디까지나 Engineer다.
Palantir에서는 FDE를 내부적으로 Delta라고 부른다. Core Dev가 하나의 capability를 만들어 여러 고객에게 제공한다면, Delta는 한 고객의 mission을 해결하기 위해 여러 capability를 조합하고 필요한 것은 직접 새로 만든다. Δ가 변화량(change)을 의미한다는 점도, 고객의 현재 상태를 실제로 변화시키는 이들의 역할과 묘하게 잘 맞는다.
그래서 FDE를 단순히 고객사에 물리적으로 파견된 개발자로 이해하면 핵심을 놓친다. 이들은 고객 현장에서 문제정의부터 production deployment까지 책임지고, 그 과정에서 얻은 학습을 다시 본사의 플랫폼과 제품으로 돌려보낸다. 코딩 능력은 당연히 핵심 스킬이지만, 도메인 현실을 이해하지 못한 채 주어진 기능만 잘 만드는 코더는 FDE라고 보기 어렵다.
미국 Palantir의 현재 공개 채용 기준으로 FDE의 base salary는 대략 $135K~$200K 수준이고, 여기에 주식보상 등이 더해진다. 도메인과 고객 문제에 대한 경험이 축적되어 Senior와 Lead로 올라갈수록 보상도 커진다.
그런데 정부에서 FDE를 도입할 때 더 중요한 것은 연봉보다 이들에게 무엇을 맡길 것인가이다. 어떤 도메인이든 조직의 AI 업무를 실행 복잡도로 나눠보면 대략 세 층위가 있다.
Layer 1은 함수호출 수준의 Tool Agent다. 정해진 API나 시스템을 호출해 하나의 작업을 수행한다. Layer 2는 Workflow다. 여러 에이전트와 사람이 하나의 도메인 업무 프로세스 안에서 상태와 순서를 공유하며 협업한다. Layer 3는 World다. 여러 워크플로우가 다시 조직의 권한, 규칙, 데이터, 상태, 제약을 공유하며 하나의 실행세계 안에서 움직인다.
FDE가 단순히 Layer 1 에이전트를 많이 만드는 사람으로 끝난다면 또 다른 개발조직에 그칠 가능성이 높다. 현실의 업무·데이터·제약·의사결정을 AI가 실행 가능한 구조로 변환하여 Layer 1에서 Layer 2, 그리고 궁극적으로 Layer 3로 올라가게 만드는 것이 더 중요한 역할이다.
그래서 나는 현업 공무원 + FDE + 공통 AI 플랫폼팀을 작은 Mission Team으로 묶고, 처음부터 전 도청의 거대한 AI 전환을 설계하기보다 3~5개의 구체적인 업무를 선정해 90일 안에 실제 결과를 만들어보는 방식을 제안했다. 그리고 결과를 “AI 서비스를 몇 개 만들었는가”로 평가하는 것 대신, Delta를 측정하는 평가기준을 제시했다.
보고서 작성시간은 얼마나 줄었는가.
결재와 협업의 리드타임은 얼마나 짧아졌는가.
사람이 반복하던 업무 단계가 몇 개나 사라졌는가.
부서 간 정보탐색과 의사결정 속도는 얼마나 빨라졌는가.
동일한 인력이 얼마나 더 많은 행정업무를 처리할 수 있게 되었는가.
즉, 무엇을 만들었는지가 아니라, 업무의 상태를 얼마나 변화시켰는지를 평가해야 한다. 내부 생성형 AI 플랫폼에 대해서도 비슷한 이야기를 했다.
직원들이 이미 ChatGPT, Claude, Gemini 같은 글로벌 frontier model에 익숙해진 상황에서 국내 모델 5개를 올려놓고 “우리 모델도 답변을 잘합니다”라는 방식으로 경쟁하는 것은 굉장히 어려운 게임이다. 공공 AI 플랫폼은 ChatGPT보다 더 좋은 챗봇이 될 필요가 없다. 대신 ChatGPT가 할 수 없는 내부 행정업무를 해야 한다.
“이 정책과 관련된 지난 5년간의 내부 검토자료를 찾아줘.”
“이 사업과 연관된 조례, 예산, 기존 보고서를 한 번에 정리해줘.”
“이 안건의 현재 결재상태와 남은 절차를 알려줘.”
“이 회의 결과를 바탕으로 후속 업무를 생성하고 담당부서에 연결해줘.”
“이 보고서 초안을 만들고 내부 양식과 결재 프로세스에 맞춰 다음 단계로 넘겨줘.”
이런 일은 글로벌 모델의 파라미터 수가 아무리 커져도 스스로 할 수 없다. 왜냐하면 이것은 지능(Intelligence)의 문제가 아니라 World의 문제이기 때문이다.
그래서 공공 AI 플랫폼도 이제 User → Model → Prompt → Answer 구조에서 User → "Mission → Government Context → Agent" → Tool/API → Action 구조로 넘어가야 한다. 즉, Model-centric Platform에서 Context & Execution-centric Platform으로 전환해야 한다.
마침 행안부에서 자문하고 있는 여러 AX 프로젝트에서도 계속 같은 이야기를 하고 있다.
정부 업무는 단순한 문서의 집합이 아니다. 하나의 내부 행정업무에도 담당부서, 관련 규정, 예산, 결재권자, 처리기한, 현재 상태, 권한, 예외조건, 그리고 다음 행동이 존재한다. AI가 실제로 일을 하게 만들려면 이 세계가 먼저 기계가 이해하고 실행할 수 있는 형태로 정의되어야 한다.
경기도의 업무세계를 공무원과 FDE가 함께 모델링하고, 그 위에서 에이전트를 만들고, 내부 플랫폼을 통해 실제 행정에 투입하고, 그 결과를 측정하면서 계속 세계를 개정해나가는 로드맵이 만들어지면 좋겠다.
순서도 현실적으로 가져갈 수 있다. 먼저 Quick Win으로 함수호출 수준의 개별 에이전트와 실행 외피의 통제 구조를 구현하고, 이후 여러 에이전트가 협업하는 Workflow, 마지막으로 여러 워크플로우가 공통의 상태·권한·제약을 공유하는 World로 확장하는 것이다.
결국 필요한 것은 "AI를 도입하는 경기도"가 아니다. "AI가 일할 수 있는 행정조직으로서의 경기도"를 다시 설계하는 일이다. 경기도청이 Agentic Twin을 잘 만들어가도록 저도 힘써 돕고 응원할게요~!
