FDE를 시작하기 전에는 몰랐던 것
FDE를 처음 시작했을 때, 이 역할을 "기술 지원이 좀 더 고급스러운 버전" 정도로 이해했습니다.
고객이 제품을 도입하면, 기술적인 질문에 답하고, 막히는 부분을 뚫어주고, 잘 돌아가면 끝. 처음엔 그렇게 생각했는데, 완전히 잘못된 이해였습니다.
한국 엔터프라이즈 AI 현장에서 FDE는 딜이 시작되는 순간부터 프로덕션이 안정화되는 순간까지, 그 전 구간을 설계하는 사람에 가깝습니다. 기술만 아는 사람도, 영업만 아는 사람도 할 수 없는 자리입니다. 그 경계 어딘가에 서 있어야 합니다.
팔란티어 FDE와 무엇이 다른가
팔란티어의 FDSE(Forward Deployed Software Engineer) 모델은 유명합니다. 고객 현장에 직접 들어가, 데이터 파이프라인과 온톨로지를 설계하고, Foundry 위에서 문제를 해결합니다. 제품이 강력하기 때문에 FDSE는 본질적으로 "강한 제품의 통역사" 역할을 합니다. 세일즈는 따로 있고, 기술 딜리버리에 집중할 수 있습니다.
한국 엔터프라이즈 현장은 구조가 다릅니다.
팔란티어 FDSE | 한국 엔터프라이즈 FDE | |
역할 범위 | 기술 딜리버리 중심 | 딜 초기부터 프로덕션까지 전 구간 |
세일즈 관계 | 세일즈팀과 분리 | 기술 의사결정으로 계약에 직접 영향 |
고객 특수성 | 상대적으로 표준화 | 금융·제조의 온프레미스, 레거시, 복잡한 조직 구조 |
신뢰 형성 방식 | 제품 데모로 증명 | 사람이 직접 기술 신뢰를 쌓아야 함 |
고객사 내부에 레거시 시스템이 있고, 의사결정 구조가 복잡하며, 담당자가 바뀌어도 프로젝트는 계속됩니다. 이 환경에서는 "제품이 알아서 설득한다"는 전제가 통하지 않습니다. FDE가 직접 신뢰를 만들어야 합니다.
FDE의 두 가지 역할축
현장에서 FDE는 크게 두 가지 관점에서 동시에 일합니다.
1. 제품 관점 — 고객의 목소리를 제품으로 연결하기
고객과 깊이 일하다 보면 자연스럽게 제품의 한계에 부딪힙니다. 이때 FDE가 할 수 있는 가장 중요한 일 중 하나는, 고객의 페인포인트를 정확하게 언어화해서 제품팀에 제안하는 것입니다.
단순한 기능 요청이 아닙니다. "이 고객이 왜 이걸 원하는지", "이게 이 고객만의 문제인지 아니면 같은 산업군의 공통 문제인지"를 판단해서 제품 로드맵에 반영될 수 있도록 연결하는 역할입니다.
목표는 내재화(Productization)입니다. 고객마다 별도로 커스텀 개발하는 구조는 스케일이 안 됩니다. FDE는 항상 "이걸 제품 안으로 넣을 수 있는가"를 먼저 생각합니다.
2. 프로젝트 관점 — 내재화할 수 없는 요구사항을 현장에서 소화하기
하지만 모든 요구사항이 제품으로 들어갈 수 있는 건 아닙니다. 특정 고객의 특수한 환경, 규제, 레거시 시스템에서 비롯된 요구사항은 제품 범위 밖일 때가 많습니다.
이때 FDE는 두 가지 방향으로 움직입니다.
파트너사 협력: 요건의 규모가 크거나 전문 영역이 다를 때는 파트너사와 함께 소화합니다. 여기서 FDE의 역할은 파트너사를 관리하는 것이 아니라, 고객의 진짜 문제를 발굴하고 파트너사가 올바른 방향으로 움직일 수 있도록 기술적 판단을 제공하는 것입니다. FDE가 이 역할을 제대로 하지 않으면, 파트너사는 고객이 말한 것만 만듭니다. 고객이 원하는 것과 필요한 것은 다른 경우가 많습니다.
FDE 직접 해결: 요건이 소규모이거나 빠른 대응이 필요할 때는 FDE가 현장에서 직접 해결합니다. 이게 가능하려면 항상 솔루션 전체를 탑뷰로 보고 있어야 합니다. 어디서 어떤 결정이 이루어지는지, 지금 막힌 지점이 어느 레이어의 문제인지를 빠르게 판단할 수 있어야 합니다.
FDE 딜 사이클 — Pre-sales부터 프로덕션까지
FDE가 "전 구간을 설계한다"고 했을 때, 실제로 어떤 단계에서 무슨 일을 하는지 구체적으로 풀어봅니다.
Phase 1. Pre-sales — 고객의 진짜 문제를 먼저 이해하기
첫 미팅부터 FDE가 들어가는 이유는 하나입니다. 기술적으로 실현 가능한 딜인지, 우리가 실제로 가치를 만들 수 있는 문제인지를 초기에 판단해야 하기 때문입니다.
이 단계에서 FDE가 집중하는 것은 고객이 말하는 요구사항 이면에 있는 구조입니다. "AI 도입을 검토 중입니다"라는 말 뒤에는 수십 가지 맥락이 있습니다. 윗선의 지시인지, 현업의 실제 Pain인지, 경쟁사 때문인지. 그 맥락을 파악하지 못하면 POC 방향 자체가 틀어집니다.
동시에 고객 내부의 의사결정 지형을 파악합니다. 누가 실무 담당자이고, 누가 예산 결정권을 갖는지, IT 부서와 현업의 관계는 어떤지. 이 그림이 없으면 기술적으로 완벽한 제안서도 엉뚱한 사람 앞에서 발표되는 일이 생깁니다.
Phase 2. POC 설계 — 증명할 것을 명확히 정의하기
POC는 "제품을 보여주는 시간"이 아닙니다. 고객이 의사결정을 내리기 위해 필요한 증거를 만드는 시간입니다.
그래서 FDE는 POC 시작 전에 반드시 "이 POC가 끝났을 때, 고객이 YES라고 말할 수 있는 조건이 무엇인가"를 명시적으로 합의합니다. 이 합의 없이 시작하면 POC는 끝이 없어집니다. 고객은 계속 새로운 요구사항을 추가하고, FDE는 계속 대응하다가 지칩니다.
POC 범위를 정의할 때 FDE는 두 가지를 동시에 봅니다. 고객이 기대하는 성과 지표, 그리고 우리 제품이 실제로 증명할 수 있는 범위. 이 두 영역이 겹치는 지점에서 POC를 설계해야 합니다. 욕심을 부려서 범위를 넓히면 POC가 산으로 갑니다.
Phase 3. 기술 검증 및 아키텍처 설계 — FDE가 직접 코드를 짜는 이유
POC 과정에서 FDE는 단순히 제품을 시연하는 것에 그치지 않습니다. 고객 환경에서 실제로 작동하는지 직접 검증하고, 필요하면 스크립트를 짜거나 연동 모듈을 만듭니다.
이게 중요한 이유가 있습니다. 엔터프라이즈 환경에서 "데모에서 됐는데 실제 환경에서는 안 된다"는 상황은 신뢰를 한순간에 무너뜨립니다. FDE가 고객 환경의 데이터, 인프라, 보안 정책을 직접 손으로 건드려본 사람과 그렇지 않은 사람의 차이는 미팅 한 번이면 드러납니다.
아키텍처 설계도 이 단계에서 이루어집니다. 고객의 기존 시스템과 어떻게 연결할 것인지, 데이터 흐름은 어떻게 설계할 것인지, 파트너사가 담당할 영역은 어디까지인지. 이 설계가 이후 계약 범위와 직결됩니다.
Phase 4. 계약 전후 — 기술이 비즈니스 결정에 영향을 주는 순간
계약 단계에서 FDE의 역할이 끝난다고 생각하기 쉽습니다. 그렇지 않습니다.
기술적 판단이 계약 범위와 가격 구조에 직접 영향을 줍니다. "이 요구사항은 제품으로 커버되는가, 별도 개발이 필요한가", "파트너사 범위는 어디까지인가"라는 질문에 FDE가 명확한 답을 줄 수 없으면, 계약서에 모호한 문구가 들어가고 그 모호함은 나중에 분쟁이 됩니다.
또한 이 시점에서 FDE는 프로덕션 단계를 이미 염두에 두고 있어야 합니다. 계약이 체결된 후 "이건 사실 어렵습니다"라고 말하는 순간이 오지 않도록, 기술적 리스크를 미리 계약 범위 안에서 처리해두는 것이 FDE의 역할입니다.
Phase 5. 프로덕션 및 내재화 — 끝이 아니라 다음의 시작
배포가 완료된다고 FDE의 역할이 끝나지 않습니다. 프로덕션 환경에서 실제 사용자들이 쓰기 시작하면 새로운 문제가 나옵니다. 성능, UX, 예외 케이스, 고객 내부의 운영 역량 부족.
이 단계에서 FDE는 두 가지를 동시에 합니다. 고객의 문제를 빠르게 해결하면서, 그 문제가 제품에 내재화될 수 있는지를 판단합니다. 내재화할 수 있는 것은 제품팀에 전달하고, 그렇지 않은 것은 운영 가이드나 파트너사 지원으로 해결합니다.
이 과정이 잘 이루어지면 고객은 단순한 사용자에서 레퍼런스로 바뀝니다. 그리고 그 레퍼런스가 다음 딜의 시작점이 됩니다.
현역 FDE라면 키워야 할 것들
기술 스택을 나열하는 건 의미가 없습니다. 어차피 현장마다 다르고, 배우면 됩니다. 대신 FDE로 오래, 잘 일하려면 반드시 키워야 하는 역량이 있습니다.
문제 번역 능력
고객이 말하는 것을 그대로 받아적는 FDE는 오래 못 갑니다. 고객이 말한 것 뒤에 있는 진짜 문제를 찾아내고, 그것을 기술적으로 해결 가능한 언어로 번역하는 능력이 핵심입니다.
"검색이 잘 안 된다"는 말은 임베딩 모델의 문제일 수도 있고, 문서 파싱의 문제일 수도 있고, 고객 내부에 정답 데이터가 없는 문제일 수도 있습니다. 이 세 가지는 해결책이 완전히 다릅니다. 첫 미팅에서 이걸 구분하지 못하면 몇 주를 잘못된 방향으로 소비합니다.
레이어 구분 능력
문제가 어느 레이어에서 발생하는지 빠르게 파악하는 능력입니다. 인프라 레이어인지, 플랫폼 레이어인지, 애플리케이션 레이어인지, 아니면 조직과 프로세스의 문제인지.
많은 FDE 지망생들이 기술 스택을 넓히는 데 집중합니다. 물론 중요합니다. 하지만 더 중요한 건 지금 이 문제가 어느 레이어에서 발생하는지를 빠르게 판단하는 감각입니다. 이 감각이 없으면 넓은 기술 스택이 오히려 노이즈가 됩니다.
의사결정 시점을 읽는 능력
엔터프라이즈 고객은 의사결정이 느립니다. 하지만 의사결정이 이루어지는 순간은 분명히 있습니다. FDE는 그 순간을 읽고, 그 타이밍에 맞는 정보를 제공할 수 있어야 합니다.
너무 이른 타이밍에 너무 많은 정보를 주면 고객은 결정을 미룹니다. 반대로 타이밍을 놓치면 다른 변수가 끼어듭니다. 이건 기술 역량이 아니라 사람을 읽는 능력에 가깝습니다. 현장 경험이 쌓일수록 이 감각은 분명히 좋아집니다.
글쓰기와 구조화 능력
현장에서 FDE가 만들어내는 산출물은 코드만이 아닙니다. 제안서, 아키텍처 문서, POC 결과 보고서, 제품팀 피드백 메모. 이것들이 형편없으면, 기술적으로 아무리 잘해도 조직 안에서 FDE의 가치가 보이지 않습니다.
특히 제품팀에 전달하는 피드백은 정확하게 구조화되어야 합니다. "고객이 불편하다고 했습니다"는 피드백과 "I 은행 담당자가 HWP 파일 파싱 실패율이 12%를 넘으면 현업 신뢰도가 무너진다고 했고, 이는 같은 금융권 고객에서 공통으로 관찰되는 패턴입니다"는 피드백은 완전히 다른 무게를 가집니다.
현장 에피소드: I 은행 GenAI 플랫폼 도입 초기
(실제 사례를 바탕으로 한 재구성입니다)
I 은행과의 프로젝트 초기, 담당자는 "우리 직원들이 사내 문서를 AI로 검색할 수 있으면 좋겠다"는 요구사항을 가져왔습니다. 표면적으로는 RAG 파이프라인을 구성하면 되는 것처럼 들렸습니다.
그런데 현장에 들어가 보니 상황이 달랐습니다. 문서 포맷이 수십 가지였고, 오래된 HWP 파일부터 스캔 이미지 PDF까지 섞여 있었습니다. 검색 품질보다 먼저 해결해야 할 건 파싱이었습니다.
더 중요한 건 조직 구조였습니다. IT 부서, 현업 부서, 컴플라이언스 팀이 각각 다른 요구사항을 가지고 있었고, 실제로 설득해야 할 의사결정자는 따로 있었습니다.
이 상황에서 FDE로서 먼저 한 일은 기술 스택을 고르는 것이 아니었습니다. "진짜 문제가 무엇인지"를 정리해서 고객 내부에서 합의를 끌어내는 것이 먼저였습니다. 그게 선행되지 않으면 어떤 기술도 의미가 없었습니다.
파싱 요구사항 중 일부는 자사 제품이 소화했고, HWP 변환 파이프라인 일부는 파트너사와 협력해서 구성했습니다. FDE는 전체 아키텍처를 설계하고, 파트너사가 올바른 인터페이스로 연결될 수 있도록 스펙을 정의했습니다.
결과적으로 담당자가 처음 말한 것과 실제로 구현한 것은 달랐습니다. 하지만 고객이 원했던 것, 즉 "직원들이 실제로 쓰는 AI"는 훨씬 가까워졌습니다.
탑뷰가 중요한 이유
FDE가 솔루션 전체를 탑뷰로 봐야 한다는 말을 자주 합니다. 구체적으로는 이런 의미입니다.
•
고객의 요구사항이 어느 레이어(인프라, 플랫폼, 애플리케이션, 조직)의 문제인지 구분할 수 있어야 합니다
•
파트너사, 내부 제품팀, 고객 IT팀이 각각 어디서 결정권을 갖는지 알아야 합니다
•
지금 해결하는 것이 제품 개선으로 이어져야 하는지, 프로젝트로 소화해야 하는지를 판단해야 합니다
이 판단을 빠르게, 정확하게 할 수 있는 사람이 결국 고객의 신뢰를 얻습니다. 신뢰가 쌓이면 기술 의사결정에 영향을 줄 수 있고, 그게 다음 프로젝트로 이어집니다.
탑뷰는 도구가 아니라 습관입니다. 현장에 들어가는 순간부터 전체 그림을 그리는 훈련을 계속해야 합니다.
마치며
한국 엔터프라이즈 AI 현장에서 FDE는 아직 정의가 완성되지 않은 역할입니다. 회사마다 부르는 이름도 다르고, 기대하는 것도 다릅니다.
하지만 분명한 건, 기술만 잘해서는 부족하고 비즈니스만 알아서도 부족한 자리라는 것입니다. 전체를 볼 수 있어야 하고, 그 시야를 바탕으로 현장에서 결정을 내릴 수 있어야 합니다.
이 글이 FDE를 지망하거나, 지금 현장에서 비슷한 고민을 하고 있는 분들에게 작은 참고가 됐으면 합니다.
이 글은 Sionic AI에서 Forward Deployed Engineer / Solutions Architect로 일하며 쌓은 경험을 바탕으로 작성했습니다.