1. FDE의 정의

소프트웨어를 도입하기로 했다고 해서 무엇을 만들어야 하는지까지 정해지는 것은 아니다. 구매 담당자는 비용을 줄이고 싶어 하고, 현업 담당자는 반복 입력을 없애고 싶어 하며, IT 부서는 기존 시스템을 안정적으로 유지하고 싶어 한다. 모두 같은 제품의 도입을 지지하면서도 기대하는 결과는 다를 수 있다.

이때 엔지니어에게 전달되는 요구는 흔히 “우리 시스템과 연동해 달라”는 짧은 문장이다. 그러나 구현을 시작하면 질문이 늘어난다. 어느 시스템의 데이터를 믿어야 하는가. 서로 다른 부서가 같은 고객을 다른 번호로 관리한다면 어떻게 연결할 것인가. 자동 처리에 실패한 건은 누가 맡는가. 기술적으로 연결하는 일과 실제 업무에서 쓸 수 있게 만드는 일 사이에는 이런 결정들이 놓여 있다.

FDE(Forward Deployed Engineer)는 고객의 업무 현장에서 이 결정에 참여하고, 그 결과를 소프트웨어로 구현하는 엔지니어다. 고객과 함께 문제를 파악하는 일부터 개발, 배포, 초기 운영까지 이어서 맡는 경우가 많다. 회사에 따라 그중 일부를 다른 역할과 나누기도 한다.

요구사항 구체화

일반적인 개발 절차에서는 제품 담당자나 기획자가 요구사항을 정리한 뒤 엔지니어에게 전달한다. FDE는 그 요구사항이 만들어지는 과정에 깊이 들어간다. 무엇을 만들지 이미 정해진 상황보다, 고객이 원하는 결과는 있지만 해결 방법이 불분명한 상황에서 역할이 선명해진다.

다음과 같은 가상의 고객 요청을 생각해 보자. 물류 회사가 배송 지연을 예측하는 대시보드를 원한다. 담당자와 이야기를 나누니 예측값 자체보다 지연이 예상되는 주문을 어느 창고로 돌릴 수 있는지 판단하는 데 시간이 걸린다. 대시보드만 만들면 화면은 하나 늘지만 담당자는 여전히 여러 시스템을 오가야 한다. 재고와 출고 마감 시간을 함께 확인하고 주문을 변경하는 과정까지 살펴야 해결할 문제가 드러난다.

이 과정에서 FDE는 질문만 하는 사람이 아니다. 필요한 데이터를 직접 확인하고, 기존 API의 제약을 조사하고, 작은 구현을 통해 가설을 시험한다. 고객이 말한 요구와 시스템이 허용하는 범위를 동시에 이해하기 때문에 대화의 결과를 구체적인 설계로 바꿀 수 있다.

고객 현장

‘Forward deployed’는 엔지니어가 고객 가까이 배치된다는 뜻을 담고 있다. 실제 출장이나 상주가 포함되기도 하지만, 역할의 핵심은 고객이 일하는 모습을 보고 구현 결과에 대한 반응을 직접 받는 데 있다.

요구사항 문서는 업무를 압축한 기록이다. 문서에 “승인 후 처리”라고 적혀 있어도 승인자가 부재할 때의 관행, 긴급 건을 처리하는 예외, 화면 밖에서 주고받는 메시지까지 담기기는 어렵다. 이런 사정은 사용자가 실제로 일을 하는 동안 드러난다. FDE는 이를 발견해 시스템이 따라야 할 규칙으로 정리하거나, 고객과 함께 업무 방식을 바꿀 여지를 찾는다.

고객 곁에서 일한다고 해서 고객의 모든 요청을 그대로 받아들이는 것은 아니다. 현재 제품으로 해결할 수 없는 요구도 있고, 구현 비용에 비해 얻는 효과가 작은 요구도 있다. 이런 한계를 설명하고 범위를 합의하는 일 역시 개발의 일부다. 현장에 가까울수록 요청을 많이 듣게 되므로, 무엇을 만들지 않을지 결정하는 능력도 중요해진다.

직무와 용어

Palantir는 Forward Deployed Software Engineer, 줄여서 FDSE라는 명칭을 사용한다. OpenAI와 Anthropic은 FDE라는 이름으로 고객 환경의 AI 구현을 맡을 엔지니어를 채용한다. 각 기업이 강조하는 업무는 4장에서 비교한다.

직무명과 팀 이름은 구분할 필요가 있다. Forward Deployed Engineering 팀에는 코드를 작성하는 엔지니어뿐 아니라 일정과 고객 협의를 조율하는 담당자가 함께 일할 수 있다. 팀 전체가 담당하는 업무를 한 사람의 책임으로 읽으면 FDE가 개발, 영업, 운영을 모두 혼자 수행하는 직무처럼 보이게 된다.

고객 개발과 제품 개발

고객별 개발을 계속하다 보면 비슷한 문제가 반복된다. 처음에는 한 고객의 특수한 요구로 보였던 권한 설정이 다른 고객에게도 필요할 수 있다. FDE가 이 경험을 제품팀과 공유하면 개별 프로젝트의 해결책이 공통 기능으로 발전할 가능성이 생긴다.

여기에 FDE 역할의 중요한 긴장이 있다. 눈앞의 고객은 빠른 해결을 원하고, 제품팀은 여러 고객이 오래 쓸 수 있는 기능을 원한다. 급하게 만든 코드를 그대로 제품에 넣기 어렵고, 완성도 높은 공통 기능을 기다리기에는 고객의 일정이 촉박할 수 있다. FDE는 두 시간표 사이에서 일한다. 이 관계를 이해해야 고객별 개발과 제품 개발이 한 직무 안에서 만나는 이유를 설명할 수 있다.

핵심 요약

FDE는 고객의 업무를 이해하는 과정과 소프트웨어를 만드는 과정에 함께 참여한다. 고객과의 대화에서 요구가 달라지고, 구현을 통해 새로운 제약을 발견하며, 그 경험이 다시 제품 개선으로 이어진다. 어느 단계까지 맡는지에 따라 같은 FDE라는 이름 아래에서도 실제 업무는 달라진다.