들어가며

어떤 제조업체가 거래처의 납기 문의에 답하는 AI를 도입했다고 해보겠습니다. 거래처가 오늘 출고할 수 있는지 물었고 AI는 재고 시스템을 확인했습니다. 재고는 100개. AI는 오늘 출고할 수 있다고 답합니다.

그런데 창고 담당자가 말합니다.

그 100개, 품질검사 끝날 때까지 못 나가는 물량인데요?

재고 숫자는 맞았습니다. 출고할 수 있다는 답이 틀렸습니다. 현업 담당자라면 당연히 확인했을 조건이 AI가 일하는 과정에서는 빠진 겁니다.

이 문제를 누구에게 맡겨야 할까요? 현업은 품질검사 대기 물량을 빼야 한다는 것을 압니다. 개발자는 재고를 조회하는 방법을 압니다. 이제 누군가 두 사람과 함께 출하 가능한 재고의 기준을 정하고, 시스템을 고치고, 다음 문의에서 제대로 답하는지 확인해야 합니다.

기업 AI 업계에서 자주 들리는 FDE, Forward Deployed Engineer가 이런 일을 맡습니다. 고객의 현업과 가까이 일하면서 데이터를 연결하고 소프트웨어를 만들며 실제로 쓰일 때까지 고쳐 나가는 엔지니어입니다.

앞선 암묵지 자산화 글 과 Context Graph 글 에서는 조직의 판단과 경험을 어떻게 AI가 쓸 수 있게 남길지 이야기했습니다. 이번에는 그 일을 맡는 사람과 일하는 방식을 살펴보려 합니다.

제 생각에는 FDE를 이해하려면 직함보다 책임의 범위를 먼저 봐야 합니다. 우리 회사의 업무를 이해하고 구현하고 현업의 반응을 보며 고치는 일을 누가 끝까지 맡고 있는가. 이 글을 읽고 나면 FDE가 실제로 무엇을 하는지, 우리 조직에는 어떤 역할이 필요한지, 외부의 도움을 받을 때 무엇을 남겨 달라고 해야 하는지 가늠할 수 있을 것입니다.

그래서 FDE가 뭔데?

FDE를 우리말로 직역하면 전방 배치 엔지니어 정도가 됩니다. 이름이 조금 거창한데, 기업에서는 고객의 실제 업무 가까이에서 문제를 푸는 엔지니어를 뜻합니다.

이 역할은 Palantir의 소프트웨어 개발 방식과 함께 알려졌습니다. Palantir는 2019년 공식 글 에서 제품 개발자와 FDSE, Forward Deployed Software Engineer의 차이를 설명합니다. 제품 개발자가 여러 고객이 쓸 기능을 만든다면 FDSE는 한 고객이 목표를 달성하도록 여러 기능을 조합하고 연결합니다.

예를 들어 재고 조회 기능 자체를 잘 만드는 일과, 그 기능을 품질검사·출고·고객 약속에 맞춰 작동하게 만드는 일은 범위가 다릅니다. FDE는 고객 환경에서 무엇이 필요한지 알아내고 빠진 부분을 직접 구현하고 실제 업무 결과까지 확인하는 쪽에 무게를 둡니다.

고객사에 매일 출근해야만 FDE인 것도 아닙니다. Palantir의 2020년 실무자 인터뷰 에는 원격으로 일하던 FDSE가 등장합니다. 이 엔지니어의 업무에는 데이터 연결, 접근권한, 업무 화면 개발, 운영 장애 해결까지 포함돼 있었습니다. 회의실이 어디 있는지보다 사용자가 겪는 문제를 직접 보고 고칠 수 있는지가 더 중요합니다.

그래서 FDE를 최근에 생긴 AI 전용 직업으로만 보면 놓치는 것이 있습니다. 생성형 AI가 나오기 전에도 기업의 복잡한 업무를 소프트웨어로 옮기는 일은 어려웠습니다. 지금은 그 소프트웨어 안에 AI의 판단과 행동이 들어가면서 다뤄야 할 문제가 더 늘었습니다.

그림 1. FDE는 현업 담당자와 고객 IT팀이 함께 확인한 문제를 구현하고, 실제 사용 결과를 보며 다시 고칩니다.

그럼 컨설턴트나 SI와는 뭐가 다를까?

여기까지 읽으면 이런 생각이 들 수 있습니다.

그거 원래 컨설팅이나 SI에서 하던 일 아닌가요?

겹치는 부분이 많습니다. 좋은 컨설턴트도 현업을 이해하고 구현에 참여합니다. SI, 즉 시스템 통합·구축 조직도 여러 시스템을 연결하고 운영을 책임집니다. 직함만으로 일을 잘하는 방식과 못하는 방식을 나눌 수는 없습니다.

FDE라는 이름을 쓸 때 확인할 부분은 조금 더 구체적입니다. 현업의 반응에 따라 요구사항을 조정할 권한이 있는지부터 확인합니다. 실제 수정과 결과 확인을 누가 맡는지도 봅니다. 또 그 과정에서 얻은 지식을 고객과 제품에 남기는지도 봐야 합니다.

레스토랑의 주방을 만든다고 생각해 보면 이해하기 쉽습니다. 주문이 몰리는 점심시간에 주방에 들어가 보면 설계도만으로는 알기 어려운 것이 보입니다. 냉장고 문을 열면 조리사의 동선이 막히고 특정 메뉴가 들어올 때마다 두 사람이 같은 작업대를 기다립니다. 장비가 정상 작동한다는 사실과 주방이 잘 돌아간다는 사실은 다릅니다.

그림 2. 설계도와 실제 점심시간의 주방을 함께 보면, 장비만 점검해서는 찾기 어려운 문제가 드러납니다.

FDE는 이런 상황을 관찰하고 바꿀 수 있는 소프트웨어 엔지니어에 가깝습니다. 현장에서 들은 말을 기술팀에 전달하는 데서 끝내지 않고 데이터와 코드, 화면을 함께 손봅니다.

물론 이 방식이 FDE라는 직함을 가진 사람만의 전유물은 아닙니다. AWS의 FDE 파트너 프로그램 도 컨설팅 회사 안에 이런 수행 역량을 갖추는 구조입니다. 우리 회사가 계약할 때는 명함보다 실제로 누가 현업과 일하고 어떤 결과까지 책임지는지를 보는 편이 낫습니다.

AI 기업들이 이 역할을 키우는 이유

기업에서 AI를 도입하는 일은 모델을 고르는 것만으로 끝나지 않습니다. 고객 정보는 영업 시스템에 있고 계약은 문서함에 있으며 실제 예외 처리 방법은 담당자가 알고 있습니다. AI가 일을 하려면 이들을 함께 사용할 수 있어야 합니다.

여기에 행동이 붙으면 더 복잡해집니다. 계약서를 읽는 것과 계약 조건을 바꾸는 것은 필요한 권한이 다릅니다. 발주 초안을 만드는 것과 공급사에 실제로 보내는 것도 다릅니다. 중간에 오류가 났다고 다시 실행했다가 주문이 두 번 들어가면 안 됩니다.

이 조건들은 회사마다 다릅니다. 현업이 어떤 일을 하는지 알아야 AI에 맡길 범위를 정할 수 있고, 시스템을 이해해야 그 범위를 실제로 지키게 만들 수 있습니다.

OpenAI는 2026년 Deployment Company를 발표하면서 FDE가 고객의 우선 업무를 고르고 데이터·도구·통제 장치를 연결해 운영용 시스템을 만드는 역할을 한다고 설명했습니다. AWS도 FDE 조직 발표 에서 고객의 사업·개발·보안팀과 함께 구축하고 고객이 운영할 역량을 남기는 방향을 제시했습니다.

이 발표들이 FDE의 효과를 숫자로 증명해 주지는 않습니다. 다만 AI 공급사들은 이 발표에서 모델 제공과 함께 고객 현장의 구현을 중요한 업무로 내세웠습니다. 그렇다면 실제 현장에서는 어떤 일을 했을까요?

현장에서는 무엇을 바꿨을까?

Airbus는 항공기 생산의 여러 판단을 연결했습니다

항공기를 만드는 일에는 부품과 작업지시, 일정과 품질 정보가 함께 필요합니다. 한 팀의 작업이 끝나야 다른 팀이 시작할 수 있고 부품 하나가 늦으면 이후 일정도 바뀝니다. 각 시스템의 데이터가 정확해도 현장에서 다음에 무엇을 해야 하는지 한 번에 보기 어려울 수 있습니다.

Palantir와 Airbus의 협업 자료 는 A350 생산 과정의 흩어진 정보와 업무를 연결한 과정을 설명합니다. Palantir의 공식 발표 자료 에서는 Airbus 업무를 초기부터 담당한 Bianca를 FDE로 소개하며 현장 사용자와 운영에 필요한 업무 흐름을 개발했다고 밝힙니다.

부품 하나가 늦는 상황을 생각해 보면 됩니다. 일정 담당자는 영향을 받는 작업을 확인하고, 현장 담당자는 먼저 할 수 있는 작업을 찾아야 합니다. 같은 정보를 보고도 각자 내려야 할 결정은 다릅니다. 그 판단에 쓸 수 있게 화면과 업무 흐름을 만들어야 합니다.

Airbus의 이 사례는 생성형 AI 이전의 데이터·소프트웨어 적용 사례입니다. FDE가 현장을 이해해야 한다는 원칙은 AI의 유행보다 오래됐습니다.

NFL은 데이터를 팬이 쓸 수 있는 서비스로 만들었습니다

FDE가 비용을 줄이는 업무에만 들어가는 것은 아닙니다. 미국 프로풋볼 리그 NFL은 선수와 경기 데이터를 팬이 활용할 수 있는 새로운 서비스를 만들었습니다.

AWS 발표에 실린 NFL의 CIO 발언 에 따르면 NFL은 AWS FDE와 함께 NFL Fantasy AI와 NFL IQ를 개발했고 수주 안에 운영 환경에 출시했습니다. 정확히 몇 주가 걸렸는지나 매출이 얼마나 늘었는지는 공개되지 않았습니다.

NFL IQ의 기술 설명 을 보면 대시보드와 AI 어시스턴트가 같은 데이터 모델과 맥락 정보를 사용합니다. 화면과 AI가 같은 데이터와 지표 정의를 참고하도록 제품 안에서 연결한 구조입니다.

기존 데이터로 어떤 고객 경험을 만들지 정하고 사용 화면과 AI를 연결해 실제로 출시한 사례입니다. 기업의 AX도 내부 보고서 작성에서 출발해 고객이 사용하는 제품과 서비스까지 넓어질 수 있습니다.

Jabil은 현장의 경험이 다음 진단에 남도록 했습니다

제조기업 Jabil의 기술자들은 제품 사양과 고객별 진단 절차, 과거 고장 기록을 여러 곳에서 찾아야 했습니다. 숙련자가 아는 내용도 흩어져 있었습니다. 이 회사는 AWS·Siemens Mendix와 함께 불량 원인 분석을 돕는 시스템을 만들면서 일선 기술자들을 개발 과정에 참여시켰습니다.

작업자가 제품의 시리얼 번호를 읽으면 시스템이 제품에 맞는 맥락을 찾습니다. 고객의 진단 절차와 기술 사양을 함께 조회하고 출처가 붙은 안내를 작업자가 쓰는 언어로 보여줍니다. 기술자가 알려준 경험 중 승인된 내용은 다시 지식 베이스에 들어갑니다.

공개된 공동개발 사례 에 따르면 작동하는 솔루션을 만드는 데 4주가 걸렸고 폐기·재작업은 15% 감소했습니다. 다만 측정 기간과 대상 공장, 표본은 공개되지 않아 모든 현장에서 같은 효과를 기대할 수는 없습니다.

이 프로젝트 자료에는 FDE라는 직함이 명시되어 있지 않습니다. 현업과 엔지니어가 함께 구현하는 방식이 무엇인지 보여주는 인접 사례로 볼 수 있습니다. 특히 숙련자가 아는 내용을 제품의 맥락에 맞춰 꺼내 쓰고 현장의 교정을 다시 남긴다는 점은 앞선 암묵지 글과 맞닿아 있습니다.

그림 3. 현장 기술자의 설명을 소프트웨어에 반영하는 공동개발 장면을 그린 개념 일러스트입니다. 실제 Jabil 시설이나 제품 화면을 재현한 그림은 아닙니다.

현업의 말이 코드가 되는 과정

처음의 납기 문의 예시로 돌아가 보겠습니다. 품질검사 대기 물량을 빼면 된다는 이야기를 들었다고 바로 문제가 해결되는 것은 아닙니다.

그 상태는 어느 시스템에 기록될까요? 검사 결과가 바뀌면 언제 반영될까요? 이미 다른 주문에 배정한 물량도 가용 재고에서 빼야 할까요? 이 질문에 답하려면 창고와 품질 담당자, 영업팀, 시스템 담당자가 함께 확인해야 합니다.

FDE는 이렇게 확인한 회의 내용을 기술로 구현합니다.

이런 기능을 에이전트가 사용할 수 있도록 묶은 것이 Tool입니다. 어떤 자료를 어떤 순서로 확인할지 정리한 업무 지침과 참고자료는 Skill로 만들 수 있습니다. 승인을 기다리는 주문과 아직 확인하지 못한 내용은 다음 작업에서도 기억할 수 있게 남깁니다. 앞선 에이전트 엔지니어링 글 에서 다룬 요소들이 현업의 요구에 맞춰 들어가는 셈입니다.

그림 4. 제안·승인·실행·결과 확인을 나누어 연결합니다. 승인 대기와 미확인 정보도 남겨야 다음 작업을 이어갈 수 있습니다.

만들고 나서는 실제 업무 사례로 시험해야 합니다. 재고가 있는 경우만 확인하면 부족합니다. 검사 대기, 품절, 조회 오류, 승인 거절이 있을 때도 제대로 처리하는지 봅니다. AI가 처리했다고 답한 뒤 실제 주문 상태도 확인합니다.

현업의 역할은 여기서도 중요합니다. 과거에 문제가 됐던 주문을 가져와 시험해 보고 틀린 답을 보면서 빠져 있던 조건을 알려줄 수 있습니다. 평소에는 당연해서 설명하지 않았던 기준이 이 과정에서 드러나기도 합니다.

저는 이런 교정이 AX에서 특히 중요하다고 생각합니다. 처음 인터뷰에서 모든 노하우를 꺼내 달라고 요청하기는 어렵습니다. 실제 결과를 보고 잘못된 부분을 짚을 때 비로소 설명할 수 있는 것도 있습니다. 그 설명을 다음 실행에 반영하고 다시 확인하는 일이 필요합니다.

엔지니어가 떠난 뒤 무엇이 남아야 할까?

FDE가 고객의 일을 잘 알게 됐다는 사실만으로는 충분하지 않습니다. 프로젝트가 끝난 뒤에도 그 엔지니어에게 전화해야만 업무를 바꿀 수 있다면 회사의 지식이 또 한 사람에게 모인 셈입니다.

적어도 어떤 업무 규칙을 적용했는지, 데이터는 어디서 가져오는지, 무엇을 시험해야 하는지, 문제가 나면 어떻게 복구하는지는 고객팀이 확인할 수 있어야 합니다. AI가 틀렸을 때 고칠 수 있는 담당자와 절차도 필요합니다.

AWS의 FDE 파트너 모델 도 구축 과정의 설계 결정과 평가 기준을 Context Graph에 기록해 다음 프로젝트에 활용하는 방식을 설명합니다. 여기서 고객이 어떤 근거로 납기 예외를 승인했는지는 고객의 업무 기록이고, 승인 기능을 어떻게 구현하고 시험했는지는 구축팀의 지식입니다. AWS의 설명은 후자에 무게가 있습니다.

고객 고유 정보와 공통 구현 방법의 경계, 코드와 자료의 소유·접근 범위는 분명하게 정해야 합니다. 구현 방법을 재사용할 수 있다고 고객의 계약이나 영업 데이터를 다른 회사로 옮겨도 되는 것은 아닙니다.

프로젝트의 성과도 작동하는 기능 수만으로 볼 수는 없습니다. 실제 처리시간이 줄었는지, 검토와 재작업을 합쳐도 이득인지, 업무가 바뀌었을 때 고객팀이 수정할 수 있는지를 함께 봐야 합니다. 돌아가는 시스템과 그 시스템을 이해하고 고칠 수 있는 역량이 회사에 함께 남아야 합니다.

그림 5. 고객의 업무 기록과 구축팀의 구현 노하우는 구분해서 관리합니다. 운영 인계에는 문서뿐 아니라 고객팀이 직접 수정하고 복구할 수 있는 역량도 포함됩니다.

우리 조직에도 FDE가 필요할까?

모든 AI 도입에 FDE 팀부터 꾸릴 필요는 없습니다. 이미 있는 제품의 설정과 교육으로 충분히 해결되는 일도 있습니다. 업무 규칙이 분명하고 시스템 연결이 간단하다면 작은 자동화부터 적용할 수 있습니다.

반면 여러 시스템을 오가고 숙련자에게 물어야 하는 예외가 많고 실제 사용 결과를 보며 계속 고쳐야 한다면 현업과 개발을 가까이 묶는 방식이 도움이 될 수 있습니다. 전사 전체보다 그런 업무 하나에서 시작하는 편이 범위와 성과를 확인하기 쉽습니다.

외부 엔지니어를 데려온다고 고객 쪽의 책임까지 사라지지는 않습니다. 업무 기준을 정하고 결과를 받아들일 현업 책임자, 데이터와 운영 환경을 맡을 IT 담당자가 함께 있어야 합니다. FDE 한 명에게 영업·현업 판단·보안·개발·운영을 모두 맡기는 구조도 현실적이지 않습니다.

Anthropic의 Technical Deployment Lead 직무 설명 을 보면 기술을 구현하는 FDE와 범위·일정·고객 관계·성과 지표를 조율하는 역할을 나눕니다. 회사마다 조직도는 다르겠지만, 기술 구현과 조직 안에서 실제로 쓰게 만드는 일 모두에 담당자가 필요하다는 점은 참고할 만합니다.

파트너를 고를 때도 어떤 모델을 쓰는지와 함께 물어보면 좋겠습니다. 우리 담당자와 실제 업무를 함께 볼 사람은 누구인지, 어떤 사례로 검증할 것인지, 도입 뒤 누가 고치고 운영할 것인지 말입니다.

나가며

처음의 재고 100개를 다시 떠올려 보겠습니다. AI가 오늘 출하할 수 있는 수량을 답하려면 품질검사와 예약 물량, 고객에게 약속할 수 있는 조건이 시스템 안에 들어가야 합니다. 현업이 아는 기준을 구현하고 시험하는 일을 누군가 맡아야 합니다.

저는 FDE를 이런 책임을 이어주는 역할로 봅니다. 실제 사용 결과를 함께 보고 고쳐 나가면서, 담당자가 바뀌어도 회사가 그 지식을 계속 쓸 수 있게 만드는 일입니다. 암묵지를 자산화하려는 조직에도 이 과정이 필요합니다.

엡실론델타는 이 과정을 함께하겠습니다. 현업의 업무와 예외를 살펴보고 작게 검증할 과제를 고른 뒤 필요한 데이터와 에이전트 도구를 연결합니다. 실제 사례로 결과를 확인하면서 권한과 승인, 운영 방식을 다듬고 현업의 교정이 조직의 지식으로 남도록 돕겠습니다.

이미 AI를 도입했는데 실제 업무에서는 잘 쓰이지 않거나 숙련자의 노하우를 어떻게 시스템에 담아야 할지 고민이라면 contact@epsilondelta.ai 로 연락해 주세요. 지금 가장 자주 막히는 업무 하나부터 이야기해 주셔도 좋습니다. 우리 조직에 필요한 역할과 첫 적용 범위부터 함께 찾아보겠습니다.