FDE에 대한 고찰: 이름은 열 개인데 하는 일은 하나다

요즘 FDE라는 말이 부쩍 자주 보인다. Forward Deployed Engineer, 우리말로 옮기면 전방 배치 엔지니어쯤 된다. 팔란티어가 만든 직군인데 OpenAI, Anthropic, 구글이 다들 이 이름으로 사람을 뽑고 있다.

그런데 찾다 보니 이름이 하나가 아니었다. 솔루션 아키텍트도 있고, 솔루션 엔지니어도 있고, 레지던트 솔루션 아키텍트, 커스터머 석세스 엔지니어, 디플로이먼트 전략가, 응용 AI 엔지니어까지 나온다. 회사마다 다르게 부르는데 채용 공고를 읽어보면 요구하는 게 비슷비슷하다.

그래서 한동안 관련 강연이랑 글들을 찾아 읽었다. 정리해두면 나중에 쓸모가 있을 것 같아 적어둔다.

1. 이름부터 정리하면

일단 실제로 쓰이는 이름들을 모아봤다.

Forward Deployed Engineer (FDE) / Forward Deployed Software Engineer (FDSE): 팔란티어가 쓰는 이름이다. 고객사에 들어가 앉아서 프로덕션 코드를 쓴다.

Deployment Strategist: 팔란티어의 또 다른 직군이고, FDSE의 짝이다. 코드를 쓰기 전에 문제를 스코핑하고 이해관계자를 관리한다. 흔히 전략가가 “왜”와 “무엇을” 맡고 FDSE가 “어떻게”를 맡는다고 설명하는데, 실제로는 경계가 자주 흐려진다고 한다.

Applied AI Engineer: Anthropic이 쓰는 이름이다. FDE 기능을 응용 AI 팀 아래에 두고 있다.

Solutions Architect / Solutions Engineer: AWS, 데이터브릭스 등에서 널리 쓰인다. 설계를 맡고, 대개 구축은 넘긴다.

Resident Solutions Architect: 데이터브릭스의 프로페셔널 서비스 조직에 있다. 이름 그대로 고객사에 상주한다.

Customer Success Engineer: 역시 데이터브릭스에 있고, 운영 중인 고객의 기술 문의를 받는다.

Sales Engineer: 가장 오래된 이름이다. 첫 데모부터 계약까지를 맡는다.

2. 놓고 보면 축은 둘뿐이다

이름이 열 개쯤 되는데, 실제 업무 내용으로 정리해보니 구분하는 축은 두 개밖에 없었다.

이름은 많은데, 놓고 보면 축은 둘뿐이다

부르는 이름은 달라도 결국 조합의 정도 차이다.

첫 번째 축은 언제 들어가느냐다. 세일즈 엔지니어는 첫 데모부터 계약까지, 솔루션 아키텍트는 기술 검토부터 초기 설계까지, FDE는 킥오프부터 프로덕션과 갱신까지, 커스터머 석세스 엔지니어는 운영이 시작된 뒤에 들어온다.

두 번째 축은 코드를 얼마나 쓰느냐다. 자료마다 수치는 다르지만 대체로 솔루션 아키텍트는 IDE에 앉아 있는 시간이 20% 남짓이고, FDE는 70%까지 올라간다고 한다.

이 두 축에 올려놓고 보면 이름들이 서로 다른 자리를 차지할 뿐, 하는 일의 성격은 같다. 고객 옆에 붙어서, 코드를 쓰면서, 결과에 책임을 진다. 그 비율이 다를 뿐이다.

그럼 왜 이름이 이렇게 많은가

여러 자료를 보면서 든 생각인데, 업무 내용보다 어느 조직에 소속돼 있느냐가 이름을 결정하는 경우가 많아 보였다.

영업 조직에 있으면 세일즈 엔지니어나 솔루션 엔지니어가 되고, 프로페셔널 서비스에 있으면 레지던트 아키텍트가 되고, 엔지니어링 조직에 있으면 FDE가 된다. 실제로 데이터브릭스는 이런 직군들을 아예 “필드 엔지니어링”이라는 조직명 아래 묶어두고 있다.

같은 일인데 비용이 어느 계정에 잡히느냐에 따라 이름이 달라지는 셈이다. 조금 냉소적인 관찰이지만, 여러 회사의 조직도를 훑어보면 그렇게 읽힌다.

3. 그럼 핵심은 무엇일까

이름 정리는 여기까지고, 여기서부터가 내가 정리하고 싶었던 부분이다. 강연과 글들을 훑어본 뒤에 내린 개인적인 결론은 세 가지다.

결론 하나. 이 직군의 본질은 번역이 아니라 책임이다

이 직군을 소개하는 글들은 대개 “기술과 비즈니스를 잇는 다리”라고 설명한다. 나는 이 설명이 부정확하다고 생각한다. 다리 역할이라면 컨설턴트도 다리고 PM도 다리다. 그걸로는 이 직군이 왜 따로 생겼는지가 설명되지 않는다.

자료들을 비교하면서 눈에 들어온 진짜 차이는 이거였다. 솔루션 아키텍트는 설계를 넘기고 떠나고, FDE는 돌아가는 것까지 책임진다. 한 자료의 표현을 빌리면, FDE는 프로덕션에서의 결과를 자기 것으로 지고 솔루션 아키텍트는 남이 운영할 설계를 소유한다.

이 순서를 뒤집어 보면 이해가 더 쉽다. 코드를 많이 써서 책임을 지는 게 아니라, 책임을 지려니 코드를 쓸 수밖에 없는 것이다. 프로덕션에서 돌아가는 것까지 내 몫이라면 남에게 넘기고 나올 수가 없다. 코드 비중 70%라는 숫자는 원인이 아니라 결과다.

결론 둘. 플랫폼이 없으면 이 직군은 성립하지 않는다

이게 가장 실용적인 판별 기준이라고 생각한다.

팔란티어 출신이 한 강연에서 이런 말을 했다. 각 FDE가 전부 맨바닥부터 만든다면 그건 FDE 조직이 아니라 외주 개발사라고. 그러면서 덧붙이기를, 외주사도 나쁘지 않고 수익성 좋은 사업이지만 다른 종류의 사업이라고 했다.

같은 일처럼 보이는데 결과가 갈린다

판별 질문은 하나다.

차이는 하나뿐이다. FDE는 맨바닥부터 코드를 쓰지 않는다. 이미 있는 조각들을 조립할 뿐이다. 이게 없으면 고객이 늘어날 때마다 저장소가 늘어나고, 유지보수 비용이 손익계산서를 잡아먹거나 그 전에 엔지니어들이 그만둔다.

그리고 이 대목에서 앞서 정리한 온톨로지 이야기와 정확히 만난다. 그 조립할 조각들의 층이 바로 온톨로지가 맡는 자리다. 객체와 액션이 타입으로 정의돼 있으면 고객마다 새로 만드는 게 아니라 그 위에 얹기만 하면 된다.

그래서 어떤 회사가 FDE 조직을 만들겠다고 할 때 물어볼 질문은 하나로 정리된다. “당신 회사의 FDE는 지금 무엇 위에 조립하고 있는가?” 여기에 답이 없으면 이름만 FDE다.

결론 셋. AI라서 뜨는 게 아니라, 제품이 커스터마이즈 가능해져서 뜬다

인과관계를 정확히 짚고 싶다. AI가 유행이라 이 직군이 뜨는 게 아니다.

앞서 말한 강연에서 이 직군이 필요한 조건을 사분면으로 정리한 게 있는데, 꽤 명쾌했다.

FDE가 필요한 칸은 딱 하나다

“하고 싶은가”가 아니라 “이 칸에 있는가”를 먼저 물어야 한다.

파는 것이 복잡하고 사는 사람이 기술을 알면, 구매자가 엔지니어라 복잡도를 알아서 흡수한다. 깃허브나 데이터독이 그렇다. 파는 것이 단순하면 애초에 문제가 안 된다. 슬랙이나 지라는 설정만 하면 되지 개발할 물건이 아니다.

복잡한 것을 기술을 모르는 사람에게 팔아야 하는 칸에서만 이 직군이 필요해진다. 팔란티어가 딱 그 칸에 있었다.

그리고 여기서부터가 핵심인데, 강연자의 가설은 이랬다. 세상이 갑자기 팔란티어 방식이 좋다는 걸 깨달은 게 아니라 소프트웨어 사업의 성격 자체가 바뀌었다는 것이다. 논리가 이렇게 이어진다.

이제 거의 모든 제품이 에이전틱하다 → 그래서 거의 모든 제품이 커스터마이즈 가능하다 → 그래서 고객이 이걸로 무엇을 할 수 있는지 모른다

즉 에이전틱 제품을 만드는 순간 자동으로 저 칸으로 들어간다. 예전에는 기능 목록이 곧 제품이었고 고객이 그걸 보고 판단할 수 있었는데, 지금은 “알아서 해준다”가 제품이라 무엇을 할 수 있는지가 고객 눈에 안 보인다.

그렇다면 요즘 AI 회사들이 이 직군을 뽑는 건 유행이 아니라 구조적인 결과라는 얘기가 된다. 나는 이 설명이 지금까지 본 것 중 가장 설득력 있었다.

4. 한 가지 역설

정리하면서 재미있다고 느낀 게 하나 있다.

이 직군의 강의 커리큘럼을 하나 봤는데, 마지막 챕터 제목이 “코드가 아닌 FDE의 일” 이었다. 그 안에 담긴 게 이해관계자 조율, 스코핑, 핸드오프였다. 앞에서 코드 비중이 70%라고 해놓고, 마지막에 가서는 코드가 아닌 일이 남는다고 말하는 셈이다.

모순처럼 보이지만 생각해보면 자연스럽다. AI가 코드 쓰는 비용을 계속 낮추고 있으니, 남는 가치는 코드가 아닌 쪽으로 밀려난다. 무엇을 만들지 정하는 일, 어디까지가 이 프로젝트인지 긋는 일, 떠난 뒤에도 고객이 굴릴 수 있게 넘기는 일. 이런 건 아직 싸지지 않았다.

그러니까 코드를 잘 쓰는 게 이 직군의 자격 요건인 건 맞는데, 그게 이 직군의 가치는 아니라는 것이다. 실제로 어떤 강연에서는 이 직군을 한 줄로 이렇게 정의했다. 고객을 대면하는 소프트웨어 엔지니어. 엔지니어로 뽑을 사람인데 동시에 고객 앞에 세울 수 있는 사람. 두 조건 중 뒤엣것이 희소해서 몸값이 높은 것이지, 앞엣것 때문은 아닐 것이다.

5. 개인적인 견해

데이터 과학자로 일하면서 느끼는 변화와 겹치는 부분이 많아서 관심 있게 봤다.

예전에는 잘 정의된 문제를 받아서 모델을 만드는 게 일의 대부분이었다. 요즘은 모델 만드는 시간이 줄고, 문제가 무엇인지 정하고 경계를 긋는 시간이 늘었다. 어디까지 자동화하고 어디부터 사람이 확인할지, 무엇을 하나의 개체로 볼지, 이 판단이 틀리면 뒤가 전부 어긋난다. FDE가 하는 일도 결국 이거라는 생각이 든다.

그래서 이 직군을 남의 이야기로만 읽지는 않게 됐다. 회사에서 AI 기능을 붙이는 일을 맡게 되는 사람이 늘어날 텐데, 그때 필요한 감각이 여기 정리된 것들과 크게 다르지 않을 것 같다.

한 가지 덧붙이면, 이 직군의 보상 수준이 상당히 높게 형성돼 있다는 이야기가 채용 시장 자료에서 자주 보인다. 다만 이런 수치는 채용 플랫폼이 만든 자료가 많아서 그대로 받아들이기는 어렵다고 본다. 숫자보다는 왜 이 조합이 희소한가를 보는 게 맞을 것 같다. 코드를 쓸 줄 아는 사람은 많고, 고객 앞에서 말할 줄 아는 사람도 많은데, 둘을 동시에 하면서 결과까지 책임지려는 사람은 확실히 드물다.

함께 보면 좋은 글:

참고 자료

본 글은 2026년 8월 2일 기준 공개된 강연과 자료를 바탕으로 정리했다. 나는 이 직군으로 일해본 적이 없고, 바깥에서 자료를 읽고 정리한 것이다. 직군 정의와 업무 범위는 회사마다 크게 다르므로 일반화에는 한계가 있다. 언급한 코드 비중이나 보상 수준 같은 수치는 채용 시장 자료 기준이라 참고용으로만 읽어주면 좋겠다.