FDE Forward Deployed Engineer

This is the long-form blog cut of a note I originally posted on LinkedIn. The claims, numbers, and product names are the same; the formatting is for reading on the site.

Context

Original framing (translated in place for key technical posts; substance preserved):

FDE 가 되고 싶은 혹은 FDE 를 채용하고 싶은 분은 꼭 이 글을 저장해두고 읽어주세요.

Anthropic, OpenAI, Google 전부 FDE 를 뽑고 있습니다. 지금 테크 업계에서 가장 수요가 많은 직무예요. 사실 저 또한 10일 만에 특정 도메인 안에서도 몇 건의 AX 프로젝트 운영을 제안받을 정도로 해당 직무의 중요성을 체감하고 있습니다.

하지만 해당 역할이 정확히 무엇을 하는지 제대로 설명한 글은 거의 없었습니다. 그래서 제가 역할 정의부터 실제 업무 단계까지 9가지로 정리했습니다.

① FDE = 고객사 현장에서 AI 를 직접 구현하는 엔지니어

AI 가 범용화되면서 기술 자체는 더 이상 경쟁력이 아닙���다. 어디에 어떻게 쓰느냐가 경쟁력이에요.

FDE 는 고객 문제를 깊이 이해하고 처음 보는 코드베이스에 바로 코드를 쓸 수 있어야 합니다. 동시에 비기술 의사결정자에게 비즈니스 임팩트를 설명해서 계약까지 끌어내는 사람이에요. 그래서 기술과 비즈니

FDE 가 되고 싶은 혹은 FDE 를 채용하고 싶은 분은 꼭 이 글을 저장해두고 읽어주세요.

Anthropic, OpenAI, Google 전부 FDE 를 뽑고 있습니다. 지금 테크 업계에서 가장 수요가 많은 직무예요. 사실 저 또한 10일 만에 특정 도메인 안에서도 몇 건의 AX 프로젝트 운영을 제안받을 정도로 해당 직무의 중요성을 체감하고 있습니다.

하지만 해당 역할이 정확히 무엇을 하는지 제대로 설명한 글은 거의 없었습니다. 그래서 제가 역할 정의부터 실제 업무 단계까지 9가지로 정리했습니다.

① FDE = 고객사 현장에서 AI 를 직접 구현하는 엔지니어

AI 가 범용화되면서 기술 자체는 더 이상 경쟁력이 아닙���다. 어디에 어떻게 쓰느냐가 경쟁력이에요.

FDE 는 고객 문제를 깊이 이해하고 처음 보는 코드베이스에 바로 코드를 쓸 수 있어야 합니다. 동시에 비기술 의사결정자에게 비즈니스 임팩트를 설명해서 계약까지 끌어내는 사람이에요. 그래서 기술과 비즈니스 커뮤니케이션을 같이 해내야 하는 자리입니다.

② 반드시 현장에 있어야 합니다

FDE 라는 용어 자체가 Palantir 에서 나왔습니다. Palantir CTO 의 원칙은 명확해요. 해당 환경 안에 있지 않으면 그만을 위한 제품을 만들 수 없다는 겁니다.

AI 배포도 마찬가지입니다. 회사가 AI 중심으로 바뀌려면 고객사 안에 직접 들어가 회사 데이터와 맥락 위에 에이전트를 직접 만들어야 해요.

③ 업무는 세 단계로 나뉩니다

진단(Audit) → 검증(Evals) → 배포(Deployment) 이 세 단계를 이해하는 게 FDE 직무를 이해하는 것과 같습니다.

④ Audit = 고객사 프로세스를 직접 매핑하는 단계

여러 팀에 들어가서 업무 흐름을 직접 관찰합니다. 예를 들어 영업팀, 운영팀에 2주, 구매팀에 1주, 재무팀에 한 달. 각 팀의 병목이 어디인지 파악하고 에이전트가 가치를 줄 수 있는 지점을 찾아냅니다. 자동화하면 안 되는 것까지 구분하는 게 이 단계에서 제일 중요한 일이에요.

⑤ 자동화 대상을 고르는 기준이 있습니다

규칙은 정해져 있는데 이메일, PDF, 스캔 이미지 등 입력이 다양한 지점에 에이전트를 도입합니다. 규칙과 입력 모두 예측 가능하면 에이전트보다 코드가 더 빠르고 저렴합니다. 그리고 패턴 인식과 도메인 전문성이 필요하면 사람에게 맡겨야 해요.

그리고 사용량도 따져야 합니다. 한 달에 고작 몇 번 동작하는 에이전트로는 ROI 가 안 나옵니다. AI 를 과도하게 쓰는 것도 경계해야 할 대상이에요. 대부분의 자동화는 tool call 몇 번과 LLM 호출 한 번이면 충분합니다. 사실 작업의 내용 대비 AI 를 많이 쓸수록 토큰 비용 지출만 커지고 오히려 출력 품질은 떨어집니다.

⑥ Evals = 에이전트가 제대로 작동하는지 검증하는 단계

먼저 소규모 golden dataset 으로 “최고 품질”을 먼저 정의하는 것이 좋습니다. 즉, 사람이 직접 정답을 만들고 그 기준으로 에이전트를 측정하는 거예요.

하지만 최종 결과물에만 집중하는 것이 아닙니다. 사람이 문제를 풀 때 거치는 중간 단계를 추적해서 AI 가 같은 체크포인트를 거치는지도 확인해야 해요. 그 때 결과물의 품질이 올라가기 때문입니다.

이 평가는 경영진이 AI 투자를 결정할 근거를 확실하게 만들어주는 단계이기도 합니다. 그래서 중요합니다.

⑦ Deployment = 기존 시스템을 뜯지 않고 AI 를 올리는 단계

대규모 데이터 마이그레이션은 하지 않습니다. 사내 그룹웨어나 데이터베이스 같은 기존 시스템 위에 API 를 만들고 모델을 orchestrator 로 올립니다.

고객사가 이미 수억원을 들여 이전한 ERP 를 또 교체할 필요가 없어요. 시간과 비용 모두 아끼는 방식입니다.

⑧ 최소 범위의 자율성만 주는 것부터 시작합니다

프로덕션 전에 회사 인프라 안에 sandbox 를 만들어서 테스트합니다. 에이전트에게 처음부터 큰 권한을 주지 않는 것이 원칙이에요.

개발 작업을 예로 들면, 버그를 확인 후 원인을 분석하는 것부터 시작하고 그것이 잘 동작하면 그때 코드를 쓰고 PR 을 올리는 권한을 줍니다.

⑨ 커뮤니케이션이 안 되면 FDE 가 될 수 없습니다

AI 가 뭘 할 수 있고 뭘 못 하는지를 경영진에게 설명할 수 있어야 합니다. 그리고 제일 중요한 것. AI 가 정답이 아닌 상황을 솔직하게 말할 수 있어야 해요. 그게 고객 신뢰를 만들고 실제 에이전트 도입의 ROI 를 높입니다.

결국 기업이라는 큰 조직에 AI 를 도입하려면 ‘챔피언’ 이라고 부를 수 있는 사람이 필요합니다.

일단 무엇을 할 수 있는지 알아야 합니다. 그래서 OpenAI 는 수십 가지 사용 사례를 공유하는 사이트를 올렸습니다. Codex use case: https://lnkd.in/gBrX-Fw4

다음으로 어떻게 사용할 수 있는지 알아야 합니다. 그래서 OpenAI 는 이번에 Developer Experience Engineer 를 채용합니다. DevRel 보다 한 단계 더 나아간 역할입니다. OpenAI career: https://lnkd.in/gctGvmPi

불행하게도 대부분의 기업에 ‘챔피언’ 이 없기 때문에 수요/공급 기업의 목표 달성을 위해 현장에서 구현까지 해줄 수 있는 사람, FDE 가 필요한 것입니다.

제가 링크드인을 통해 지속적으로 콘텐츠를 공유하는 이유가 이것입니다. 1인 빌더로서 모든 기업을 상대할 수는 없기에 저의 콘텐츠에서 누군가 영감을 받아 각자가 소속된 곳에서 ‘챔피언’ 이 되셨으면 좋겠습니다.

Links

• https://lnkd.in/gBrX-Fw4
• https://lnkd.in/gctGvmPi