FDE, 외주로 구할까우리 사람을 기를까?

01FDE, 외주로 구할까 우리 사람을 기를까?

우리 업무를 이미 아는 사람이 안에 있다면, 그 사람을 FDE로 기르는 편이 빠르고 회사에 남는 것도 많습니다. FDE는 고객의 실제 업무에 소프트웨어와 AI를 맞춰 넣고 결과가 날 때까지 책임지는 엔지니어입니다. 이름에 「엔지니어」가 붙어 있어 코딩이 전부인 것 같지만, 채용하는 쪽이 묻는 것은 다릅니다.

네 가지 중 코딩은 마지막 하나뿐입니다. 앞의 것들 — 업무가 실제로 어떻게 돌아가는지 이해하고, 기술자와 비기술자 모두와 이야기하는 일 — 은 밖에서 온 사람이 처음부터 쌓아야 하지만, 우리 사람은 그 상당 부분을 이미 갖고 출발합니다. 그리고 남은 하나, 만드는 일의 문턱은 AI 도구가 크게 낮췄습니다(4절).

FDE를 가장 많이 쓰는 회사들도 안에서 기르고 있다

세일즈포스는 6개월 만에 FDE 팀을 세 배로 키우면서 사람을 밖에서만 데려오지 않았습니다. 엔지니어링·프로페셔널 서비스·고객 성공, 세 사내 부서에서 사람을 모았고, FDE로 옮겨 오는 사람의 40~50%가 사내 이동입니다. 이를 위해 2025년 9월 기술 집중 교육 2주와 현장 실습 4주로 된 6주 과정을 만들었습니다 [2].

2026년 10월에는 Anthropic이 1억 달러를 들여 2027년 말까지 이런 엔지니어 1만 명을 기르겠다고 발표했습니다. 참가 기관이 추천한 엔지니어가 12주 동안 자기 회사의 실제 프로젝트 하나를 이끄는 방식이고, 첫 기수에는 컨설팅사뿐 아니라 호주 커먼웰스 은행·모건 스탠리·노보 노디스크 같은 일반 기업도 들어 있습니다 [3]. 이 과정은 이름을 Frontier Deployed Engineer로 조금 달리 부르지만, 실제 업무 안에서 AI를 돌아가게 만드는 사람을 기른다는 점은 같습니다.

02사내 FDE란 무엇인가?

사내 FDE는 고객사가 아니라 우리 회사 현업 부서 곁에서, 그 부서의 일에 AI를 맞춰 넣고 결과까지 책임지는 사람입니다. 원래의 FDE가 고객사 현장으로 「앞으로 나가」 배치되는 사람이라면, 사내 FDE에게는 우리 회사의 각 부서가 곧 고객입니다. 새 직함을 만들 필요는 없습니다. 기존 직원에게 맡기는 역할입니다.

외주 FDE의 장점도 분명합니다. 기술과 도구에 이미 익숙하고, 여러 회사를 거치며 쌓은 요령이 있습니다. 문제는 그 장점이 우리 회사에서 가장 먼저 막히는 자리와 겹치지 않는다는 데 있습니다. 외주로 오는 FDE가 이름만 FDE이고 실제로는 SI처럼 일하고 있지 않은지 알아보는 질문 넷은 「FDE는 SI 파견과 무엇이 다른가?」에 정리했습니다.

03외주 FDE는 우리 회사에서 무엇에 먼저 막히는가?

외주 FDE는 업무 설명이 사람마다 다르고, 판단 기준이 사람 머릿속에 있고, 어디에 붙여야 효과가 나는지 모르는 세 벽을 처음부터 넘어야 하며, 떠날 때 그 답도 함께 가져갑니다. 이 세 벽은 「FDE는 현장에서 무엇에 막히는가」에서 개발자 쪽 시선으로 자세히 다뤘습니다. 회사 쪽에서 보면 같은 벽이 이렇게 보입니다.

더 큰 문제는 계약이 끝난 뒤입니다. 외주 FDE가 인터뷰로 꺼낸 판단 기준과 업무의 연결이 그 사람의 노트와 머릿속에만 있다면, 계약이 끝나는 날 회사는 시스템은 넘겨받아도 그 시스템이 왜 그렇게 생겼는지는 넘겨받지 못합니다. 「그 사람 퇴사하면 그 일은 누가 하지?」라는 오래된 질문이 외주에서도 똑같이 생기는 것입니다. 이 질문은 「암묵지를 명시지로」에서 다뤘습니다.

04누구를 사내 FDE로 기를 것인가?

코딩을 잘하는 사람보다, 자기 부서 일을 잘 알면서 「이건 왜 이렇게 하지?」를 자주 묻는 사람이 먼저입니다. 일을 잘 아는 것만으로는 부족합니다. 익숙한 일일수록 이유를 묻지 않게 되기 때문입니다. 당연해 보이는 절차에 이유를 묻는 사람이, 숨어 있던 판단 기준을 꺼냅니다.

만드는 일의 문턱은 이미 낮아졌다

첫째 길이 열린 것은 최근의 일입니다. 이 글을 쓴 사람도 그 길로 왔습니다. 1978년 겨울 FORTRAN을 일주일쯤 배운 것이 프로그래밍 교육의 전부이고, 지금도 프로그램을 한 줄 직접 쓰지 못합니다. 그런데 2025년 여름부터 만들고 싶은 동작을 말로 설명해 AI가 코드를 짜게 하는 방식으로 업무 모델링 도구 AIMS를 만들어 왔습니다. 2026년 2월 말 AI가 직접 파일을 찾아 고치는 코딩 도구를 쓰기 시작한 뒤로는, 하루 종일 걸리던 작업이 10여 분 만에 끝나기도 했습니다 [4].

혼자만의 이야기가 아닙니다. 2026년 8월 유명소프트가 찾아간 한 중소기업에서는 직원 네 사람이 외주 하나 없이, 각자 잘 아는 영역을 하나씩 맡아 — 회계를 아는 사람은 회계를, 현장을 아는 사람은 현장을 — 회사 전체가 쓰는 시스템을 직접 만들었습니다. 남이 만든 프로그램 다섯 가지를 나눠 쓰던 것을 석 달 만에 모두 대체했습니다.

두 경우 모두 만드는 일 자체는 넘을 수 있는 벽이었습니다. 코딩은 AI가 대신하므로, 사내 FDE가 직접 코딩을 잘할 필요는 없습니다. 다만 프로그래밍의 원리 — 프로그램이 무엇을 받아 무엇을 내놓는지, 자료가 어디에 쌓이고 무엇이 무엇에 이어져 있는지 — 는 알아야 합니다. 그래야 AI가 만든 것을 확인할 수 있습니다.

남는 벽은 다른 데 있었습니다. 무엇을 만들지 정하는 일과 만든 것을 다른 사람이 읽을 수 있게 남기는 일입니다. 사내 FDE에게 가르칠 것은 바로 그 두 가지입니다.

05사내 FDE에게 무엇을 가르쳐야 하나?

세 가지면 됩니다 — 일하는 방법을 입력·통제·산출·수단 네 칸에 담아 소통하기, 사람 머릿속의 판단 기준을 꺼내 글로 적기, 그리고 수단 칸만 바꿔 AI를 붙이기. 셋 모두 국제표준 업무 모델링 언어 IDEF0의 기본기입니다 [5].

둘째가 가장 자주 빠진다

현장에서 가장 자주 건너뛰는 것이 둘째입니다. 만드는 일이 쉬워지면 적는 일이 귀찮아지기 때문입니다. 앞의 중소기업은 문서를 따로 만들지 않는다고 했습니다. AI에게 만들라고 준 지시문이 그 역할을 하고 있다는 것이었습니다. 그러면서 AI에게 수정을 맡길 때 자료가 쌓이는 곳이 딸려 오면 가급적 손대지 않는다고 했습니다. 현명한 판단이지만 해결은 아닙니다. 무엇이 어디로 이어져 있는지가 밖에 적혀 있지 않으면, 위험해 보이는 자리는 통째로 피하는 수밖에 없습니다.

이 글을 쓴 사람도 같은 일을 겪었습니다. 한두 시간이면 끝나던 수정이 그동안 쌓인 것들에 걸려 한 번에 7~8시간씩 걸리게 되었고, 빨리 가고 싶은 마음에 AI가 만든 것을 확인하지 않고 넘어간 자리도 나중에야 발견했습니다 [4]. 만드는 속도가 빨라질수록, 만든 것을 그림과 글로 남기는 일은 나중이 아니라 처음부터 가르쳐야 합니다.

06첫 석 달은 어떻게 짜면 되는가?

업무 한 갈래를 골라 한 장으로 그리고, 판단 기준을 글로 꺼내고, 한 활동의 수단 칸만 AI로 바꿔 결과를 재는 순서로 갑니다. 아래는 실적이 아니라 권하는 순서입니다. 앞에서 본 Anthropic의 과정도 12주 동안 자기 회사의 실제 프로젝트 하나를 이끄는 방식이니, 석 달은 첫 갈래 하나를 끝까지 가 보는 단위로 삼을 만합니다.

석 달이 끝났을 때 남아야 할 것은 AI가 붙은 활동 하나만이 아닙니다. 그 갈래의 그림, 판단 기준 문서, 그리고 그것을 그려 본 사람 한 명이 남아야 다음 갈래가 빨라집니다.

07그래도 외부 도움이 필요한 때는 언제인가?

안에 시간을 낼 사람이 없거나, 여러 부서에 걸친 일의 첫 그림을 빨리 봐야 할 때는 외부와 함께 시작하되, 대신 해 주는 방식이 아니라 같이 그리며 넘겨받는 방식이어야 합니다. 규정과 기준이 복잡하거나, 그림을 근거로 조직의 큰 결정을 내려야 할 때도 경험 있는 사람과 함께 그리는 편이 안전합니다. 혼자 그릴지 함께 할지의 갈림길은 FAQ Q12에 정리했습니다.

외부 도움을 받는다면 계약서에 끝날 때 무엇을 넘겨받는지를 적어 두십시오. 만들어진 시스템만이 아니라 업무 그림, 판단 기준 문서, 낱말의 뜻을 정한 용어집까지입니다. 그리고 외부 사람 곁에 우리 사람을 한 명 붙여 그림을 같이 그리게 하십시오. 외부 도움이 끝나는 날이 사내 FDE가 일을 이어받는 날이 되어야 합니다.

유명소프트가 일하는 네 단계 — 프로세스 정형화, AI 전환 진단, 로드맵·PoC, 구축·내재화 — 의 마지막이 「직원이 스스로 이어가도록 정착시키는 일」인 것도 같은 이유입니다(일하는 방식).

08자주 묻는 질문

사내 FDE는 개발자여야 하나?

아닙니다. 자기 부서 업무를 잘 아는 현업 실무자도 사내 FDE가 될 수 있습니다. AI 도구로 만드는 일의 문턱이 낮아졌기 때문에, 일하는 방법에 대해 소통하는 법과 AI로 프로그래밍하는 법을 먼저 익히면 됩니다. 직접 코딩하는 실력은 낮아도 되지만, 프로그램이 무엇을 받아 무엇을 내놓고 자료가 어디에 쌓이는지 같은 프로그래밍의 원리는 알아야 AI가 만든 것을 확인할 수 있습니다. 개발자라면 반대로 업무를 읽는 법부터 익힙니다.

현업 실무자가 IDEF0를 배울 수 있나?

배울 수 있습니다. 활동마다 입력·통제·산출·수단 네 칸을 채우는 틀이라, 읽는 법은 하루면 익힙니다. 표준 문법에 맞게 그리는 일이 부담스럽다면, 대화로 설명하면 AI가 받아 적어 모델을 세워 주는 도구 AIMS(idef0.ai)를 쓸 수 있습니다. 계보와 표기 원칙은 「IDEF0란 무엇인가」에 정리했습니다.

사내 FDE는 전담이어야 하나, 겸직이어도 되나?

첫 갈래를 그리는 동안만큼은 업무 시간을 따로 떼어 주는 편이 좋습니다. 남는 시간에 맡기면 급한 일에 밀리기 쉽습니다. 첫 갈래에서 그린 그림과 기준은 다음 갈래의 출발점이 됩니다.

외주 FDE와 사내 FDE를 함께 쓸 수는 없나?

함께 쓸 수 있고, 처음에는 그 편이 나을 수 있습니다. 다만 외부 사람 곁에 우리 사람을 붙여, 업무 그림과 판단 기준이 우리 사람에게 넘어오게 해야 합니다.

사내 FDE의 성과는 무엇으로 재나?

그 부서의 업무에서 측정 가능한 결과가 났는지, 그리고 그 결과를 다른 사람이 이어받을 수 있게 그림과 기준이 남았는지, 두 가지로 잽니다. 앞의 것만 재면 한 번의 성공으로 끝나고, 뒤의 것까지 재야 다음 갈래로 이어집니다.