FDE에게 필요한 것은 코딩보다「업무를 읽는 눈」이다

01FDE(포워드 디플로이드 엔지니어)란 무엇인가?

FDE는 본사가 아니라 고객 현장에 배치되어, 고객의 실제 업무에 소프트웨어와 AI를 맞춰 넣고 결과가 날 때까지 책임지는 엔지니어입니다. 「forward deployed」는 군대에서 병력을 본진이 아니라 최전선 가까이에 두는 것을 가리키는 말입니다. 엔지니어를 사무실이 아니라 고객 곁에 둔다는 뜻으로 옮겨 온 것입니다.

이 직무는 팔란티어(Palantir)에서 시작되었습니다. 팔란티어는 뛰어난 소프트웨어 엔지니어들을 팔로알토 사무실에서 내보내, 기술은 모르지만 자기 일에는 정통한 현장 실무자들 곁에서 일하게 했습니다. 제품을 만들어 넘기는 것이 아니라, 고객의 일 안으로 들어가 그 일이 돌아가게 만드는 것이 FDE의 일입니다.

02왜 지금 FDE가 주목받는가?

AI 모델의 성능이 더 이상 병목이 아니고, 그것을 고객의 업무에 실제로 붙이는 일이 병목이 되었기 때문입니다. 이제 AI는 누구나 쓸 수 있게 되었지만, 그 AI가 어느 부서의 어느 일을 어떻게 바꾸는지는 현장에 들어가 봐야 정해집니다.

출처: 채용 데이터 분석사 Lightcast 집계, Fortune 2026년 9월 3일 보도 [1]

숫자보다 눈여겨볼 것은 채용하는 쪽이 FDE에게 무엇을 묻는가입니다. 같은 보도에서 채용 플랫폼 Dice의 대표는 FDE에게 필요한 역량을 이렇게 요약했습니다.

네 가지 중 코딩은 마지막 하나뿐입니다. 앞의 셋은 업무를 읽고, 그것을 남과 같은 그림으로 공유하는 능력입니다.

03FDE는 현장에서 무엇에 막히는가?

FDE가 현장에서 처음 부딪히는 벽은 기술이 아니라, 고객이 자기 일을 설명하지 못한다는 사실입니다. 고객 실무자는 일을 잘하지만, 그 일을 남이 알아듣게 구조로 말해 본 적은 거의 없습니다. 그래서 같은 벽을 세 번 만납니다.

세 벽은 모두 같은 처방을 가리킵니다. 고객의 말을 그대로 받아 적는 것이 아니라, 일을 일정한 틀에 맞춰 구조로 다시 그리는 것입니다. 그 틀이 정해져 있으면, 누구를 인터뷰하든 같은 칸을 채우게 되고 빠진 칸이 바로 보입니다. 이 문제는 「무엇을 자동화할 것인가」에서 조직 쪽 시각으로 더 자세히 다뤘습니다.

04개발자의 눈으로 읽는 IDEF0

IDEF0는 업무를 「활동」 상자로 나누고, 각 활동에 드나드는 것을 입력·통제·산출·수단 네 가지로만 구분해 그리는 국제표준 모델링 언어입니다. 미 공군에서 출발해 1993년 미국 연방표준(FIPS PUB 183)이 되었고, 2012년 국제표준(ISO/IEC/IEEE 31320-1)이 되었습니다 [2][3].

개발자라면 이 상자를 이미 알고 있습니다. 활동 상자 하나는 함수 하나와 거의 같은 모양으로 읽힙니다.

함수와 다른 점 — 통제를 따로 떼어 낸다

IDEF0가 개발자에게 주는 가장 큰 선물은 「통제」를 입력과 분리해 그리게 한다는 점입니다. 코드에서는 설정값과 인자가 같은 괄호 안에 섞이기 쉽습니다. 업무에서는 이 둘을 섞는 순간 AI 도입이 틀어집니다. 입력은 데이터라서 AI에게 넘기면 되지만, 통제는 규칙이라서 먼저 사람에게서 꺼내 문서로 만들어야 합니다. 앞에서 본 WALL 02(규칙이 사람에게 있다)가 바로 통제 칸이 비어 있는 상태입니다.

하나 더 — 함수 호출 그래프처럼 쪼갠다

IDEF0의 상자는 안으로 들어가면 다시 3~6개의 하위 활동으로 나뉩니다. 큰 함수를 작은 함수 몇 개로 쪼개는 것과 같습니다. 다만 규칙이 하나 있습니다. 바깥 상자에 드나들던 화살표는 안쪽 그림에서도 빠짐없이 다시 나타나야 합니다. 인터페이스가 깨지지 않는지 검사하는 것과 같은 원리이고, 덕분에 인터뷰에서 빠뜨린 것이 그림 위에서 드러납니다.

05고객 업무를 처음 파악할 때 무엇부터 그리나?

업무 전체를 상자 하나로 놓은 최상위 그림(A-0)부터 그리고, 그다음에 세부 활동 3~6개로 나눕니다. 처음부터 세부로 들어가면 인터뷰가 한 사람의 시야에 갇힙니다. FDE가 고객사에 들어간 첫 주에 할 일을 순서대로 적으면 이렇습니다.

참고할 절차서가 하나도 없는 조직에서 인터뷰만으로 이 순서를 밟은 실제 예는 모델링 사례 페이지에서 볼 수 있습니다.

06업무를 읽는 눈은 어떻게 기르나?

업무를 읽는 눈은 타고나는 감각이 아니라, 같은 틀로 여러 업무를 그려 보면서 길러지는 훈련의 결과입니다. 코드 리뷰를 많이 할수록 구조가 빨리 보이는 것과 같습니다. 고객사에 가기 전, 지금 자리에서 시작할 수 있는 연습 세 가지입니다.

회사 쪽에서 우리 직원을 FDE로 기르려는 분을 위해서는 「FDE, 외주로 구할까 우리 사람을 기를까?」를 따로 정리했습니다.

07자주 묻는 질문

FDE와 솔루션 엔지니어는 무엇이 다른가?

솔루션 엔지니어가 주로 판매 전 단계에서 제품을 시연하고 기술 질문에 답한다면, FDE는 계약 뒤 고객 현장에서 직접 코드를 쓰고 실제 업무에 돌아가게 만든 뒤 그 결과까지 책임집니다. 그래서 FDE에게는 고객의 업무 흐름을 읽는 능력이 핵심 역량이 됩니다. 「고객사에 상주하니 SI 파견과 같은 것 아니냐」는 질문은 「FDE는 SI 파견과 무엇이 다른가?」에서 따로 다뤘습니다.

FDE에게 비즈니스 프로세스 이해가 왜 필요한가?

AI를 업무의 어느 자리에 붙이느냐가 성과를 결정하는데, 그 자리는 고객의 업무 흐름을 알아야만 보이기 때문입니다. 고객은 자기 일을 체계적으로 설명하지 못하는 경우가 많아, 엔지니어가 스스로 업무를 구조로 읽어 내야 합니다.

IDEF0는 개발자가 배우기 어려운가?

어렵지 않습니다. 활동 상자는 함수처럼 읽힙니다 — 입력은 인자, 산출은 반환값, 통제는 설정·규칙, 수단은 실행 주체입니다. 표기 규칙이 적어 하루면 읽는 법을 익히고, 자기 팀 업무 하나를 그려 보는 것으로 연습을 시작할 수 있습니다. 계보와 표기 원칙은 「IDEF0란 무엇인가」에 정리했습니다.

IDEF0와 BPMN은 무엇이 다른가?

BPMN이 일이 일어나는 순서와 분기(언제 무엇을 하는가)를 그린다면, IDEF0는 활동 사이의 관계(무엇이 무엇을 만들고, 무엇이 그 일을 통제하는가)를 그립니다. AI를 어디에 붙일지 고르는 단계에서는 관계를 먼저 보는 IDEF0가 유리하고, 붙인 뒤 실행 흐름을 설계할 때는 BPMN이 쓸모 있습니다. 둘은 경쟁 관계가 아니라 순서 관계입니다.

오래된 방법론이 AI 시대에도 쓸모가 있나?

오히려 AI 시대에 더 쓸모가 커졌습니다. IDEF0는 업무를 정해진 문법으로 적기 때문에 사람뿐 아니라 언어모델도 그대로 읽을 수 있습니다. 고객 업무를 이 형식으로 적어 두면, 그 모델 자체를 AI에게 맥락으로 넘겨 줄 수 있습니다. 팔란티어가 말하는 「온톨로지」와의 관계는 「IDEF0는 기업 온톨로지의 설계도가 될 수 있는가」에 정리했습니다.