FDE가 뭐길래 — 보안 엔지니어가 0편 수집기로 FDE 공고를 다시 세 봤다
0편에서 나는 플랫폼·DevOps로 간다고 썼다. 공고 455건을 세서 갭 3개를 찾았고, 그걸 메우는 프로젝트를 시작했다.
그사이 바뀐 게 하나 있다. 지금 내가 가장 가고 싶은 자리는 FDE(Forward Deployed Engineer)다.
처음엔 FDE를 "플랫폼 다음 단계"쯤으로 생각했다. 그 생각이 맞는지 0편에서 쓴 수집기를 FDE 공고에 다시 돌려 봤고, 결과는 예상과 달랐다.
1. 왜 FDE인가
계기는 공고가 아니라 외주였다.
올해 4월부터 본업 밖에서 외주를 몇 건 맡았다. 고객도 문제도 제각각이었다. 요구사항 정리부터 운영자 인수인계까지 맡은 Cafe24 쇼핑몰 Townfolks, 같은 고객의 의뢰로 만든 카카오톡 AI 상담 챗봇, 석사 논문에 쓸 언어 데이터 수집, 구글 시트로 주문을 받던 농수산물 유통업체의 발주 시스템. 공통점은 하나도 없는데, 매번 같은 방식으로 풀었다. AI를 처음부터 끝까지 붙여서.
전부 잘된 건 아니다. 한 의류 쇼핑몰에서는 사용자가 얼굴 사진을 올리면 어울리는 옷을 쇼핑몰 상품에서 골라 입혀 보여 주는 기능을 MVP로 만들려다가, 비용이 맞지 않아 접었다.
요구사항을 정리하는 것도, 처음 보는 도메인을 파악하는 것도, 코드를 짜고 고객에게 보낼 설명을 쓰는 것도 AI와 같이 했다. 내 힘으로는 이해하기 어려웠을 도메인 내용도 AI에게 물어 가며 공부해서 진행할 수 있었고, 그 덕에 혼자서는 손대지 못했을 종류의 일까지 받을 수 있게 됐다. 개발은 코딩 에이전트로 짜고, 리뷰를 받고, 다시 고치는 걸 계속 반복했다. 문제의 폭만 넓어진 게 아니라 속도와 품질도 같이 올라갔다.
재미있었던 건 기술보다 그다음 장면이었다. 그 농수산물 발주 시스템이 대표적이다. 예전에는 거래처 주문을 구글 시트로 받았다. 지금은 그 업체의 거래처들이 시스템에 직접 주문을 넣는다. 납품하고 끝난 게 아니라, 지금도 매번 주문이 그 시스템을 지나간다.
AI를 안 쓰면 뒤처진다는 말은 이제 너무 자주 들어서 별 감흥이 없다. 내가 느낀 건 그보다 구체적이었다. AI를 들고 고객 문제 앞에 서는 일이 재미있었고, 그걸 본업으로 하는 직함을 찾아보니 FDE였다.
그런데 왜 보안 출신이
동기는 외주에서 왔지만, 내가 이 자리에서 남들과 다를 수 있는 이유는 본업에 있다.
보안 일을 하면서 자주 본 장면이 있다. 밖에서 들어온 솔루션이 방화벽, 계정 권한, 로그 반출 규정에 걸려서 멈추는 장면이다. 그때 막는 쪽에 서 있는 건 대체로 나였다.
FDE는 그 반대편에서 막힌 걸 풀어 내는 사람이다. 고객사 보안팀이 무엇을 왜 막는지 아는 FDE는 생각보다 많지 않을 거다. 외주에서 찾은 재미와 본업에서 쌓은 시선이 겹치는 자리가 FDE였다.
2. 이번 글의 데이터
0편은 "로드맵은 의견이고, 공고는 회사가 돈을 걸고 쓴 요구사항"이라는 전제로 시작했다. 이번에도 같은 수집기와 같은 판정 기준을 썼다. 다만 규모는 훨씬 작다.
- 수집: 2026년 10월 7일 10:40~10:46. 검색어는 "Forward Deployed"와 "FDE" 두 개.
- 걸러낸 과정:
| 단계 | Forward Deployed | FDE | 두 검색어 합친 뒤 |
|---|---|---|---|
| 수집 | 123 | 89 | — |
| URL 중복 제거 후 | 115 | 79 | 156 |
| 제목에 FDE가 들어간 공고 | 79 | 41 | 95 |
| 본문을 열어 확인 | 5 | 4 | 8 |
| 그중 판정 가능 | 7 |
"합친 뒤" 열은 두 검색어에 동시에 걸린 공고를 한 번만 센 숫자다. 이루비가 그런 경우라서 본문 확인은 9건이 아니라 8건이다. 8건 중 메이머스트는 공고 본문이 이미지로만 올라와 있어서 판정에서 뺐다.
95건 중 본문을 연 8건은 규칙으로 거른 게 아니라 내가 직접 골랐다. 무슨 기준으로 골랐는지는 남겨 두지 않았다. 본문까지 받아 놓고 점수도 판정도 매기지 않은 FDE 공고도 몇 건 더 있다.
한계도 분명하다. 포털마다 1페이지만 긁었고, 같은 공고가 다른 포털에 다른 URL로 올라온 경우는 지우지 않았다. 선별도 수동이었고, 본문까지 읽고 판정한 건 7건뿐이다. 0편의 455건과 견줄 수 있는 숫자가 아니라, 방향을 보는 정도의 데이터다.
3. FDE 한 줄 정의
내 식으로 쓰면 이렇다.
제품 회사 엔지니어가 고객 환경에 들어가서, 자기 회사 제품을 실제로 돌아가게 만들고, 거기서 새로 나오는 문제까지 직접 푸는 일.
판정한 공고들도 비슷한 말을 한다. 이루비는 "이루비의 AI를 제조 현장에 직접 배포하고, 고객의 문제가 실제로 해결될 때까지 책임지는 Forward Deployed Engineer(FDE)를 찾습니다"라고 썼고, 컨포트랩은 "FDE는 고객 제조 현장에 들어가 문제를 정의하고, PORTA와 AI 기술로 해결까지 책임지는 사람입니다"라고 썼다.
판정한 7건에서 요구사항을 세면 이렇다. 앞 숫자는 그 표현이 명시된 공고, 괄호 안은 비슷한 표현까지 넣은 공고다.
| 공고에 적힌 것 | 7건 중 |
|---|---|
| 고객 커뮤니케이션 | 5 (7) |
| 직접 코딩 | 5 (6) |
| 고객 환경에 배포 | 2 (5) |
| 출장·현장 근무 | 2 (4) |
7건 모두 어떤 식으로든 고객과의 소통을 적었다. 코딩은 6건까지 올라가는데, 컨포트랩은 노코드 환경이라 빠진다. 고객 환경 배포는 비슷한 표현까지 치면 5건이지만 "온프레미스"나 "고객 클라우드"라는 단어는 한 번도 안 나왔고, 현장 근무도 "상주"라는 단어는 없었다.
내가 FDE 하면 떠올리던 "고객사 폐쇄망에 들어가 설치하는 사람"은, 적어도 이번에 본 공고에서는 중심이 아니었다. 이건 6장에서 다시 쓴다. 나한테는 이게 오히려 좋은 소식이었다.
이 직함은 Palantir와 묶여서 이야기된다. Palantir 공고는 스스로 "We pioneered this unique position"이라고 쓰고, a16z 글은 "Any time you think of the FDE term, you think of Palantir"라고 썼다. (a16z, Forward-deployed Job Titles)
4. 비슷한 역할과 비교
처음 읽었을 때 든 생각은 "이거 SI 아닌가?"였다. 고객사에 들어가서 고객 환경에 맞춰 시스템을 붙인다는 문장을 들으면, 한국에서 일해 본 사람은 SI부터 떠올릴 것 같다. 나도 그랬다.
공고를 읽어 보니 상당 부분은 맞는 생각이었다.
두 일은 겹치는 게 많다. 둘 다 고객 쪽에 들어가고, 들어가 보면 문서에 없던 문제가 나오고, 그걸 그 자리에서 푸는 게 일이다. 채널톡 공고는 FDE가 "고객사 현장(데이터, 프로세스, 조직 구조 등)을 깊이 이해하고, 실제 문제를 정확히 진단한 뒤, 빠르게 해결 방안을 설계·구현·검증하여 즉각적인 비즈니스 임팩트를 만드는 역할"이라고 썼다. 이 문장에서 회사 이름만 지우면 SI 공고라고 해도 어색하지 않다.
그래서 하는 일로는 잘 안 나뉜다. 내가 보기에 차이는 회사가 뭘로 돈을 버느냐에서 갈린다. SI는 프로젝트로 벌고, 결과물은 그 고객 하나를 위한 시스템이다. FDE는 제품 회사에 있어서, 현장에서 푼 것 중 일부는 다른 고객에게도 쓸 수 있게 제품으로 돌아가고 일부는 그 고객만의 것으로 남는다. 이번에 본 공고들도 이루비의 AI, 컨포트랩의 PORTA처럼 자기 제품을 들고 들어간다. 비율과 기대치의 차이지, 어느 쪽이 더 낫다는 얘기는 아니다.
다른 역할까지 넣어서 한 번에 놓으면 이렇다. 공고와 글 몇 개를 읽고 정리한 내 기준표라서, 회사마다 다를 수 있다.
| 역할 | 누구를 위해 | 코드를 쓰나 | 제품 회사 소속인가 | 성과 기준 |
|---|---|---|---|---|
| FDE | 계약한 고객 | 많이 쓴다. 고객 시스템 안에서도 | 그렇다 | 고객이 실제로 쓰는가 |
| SI | 발주한 고객 | 많이 쓴다 | 아니다. 수행사 | 계약 범위 납품·검수 |
| Solutions Architect | 고객 | 적게. 설계 조언·PoC | 대체로 그렇다 | 고객이 맞는 구조를 고르는가 |
| Technical Consultant | 고객 | 거의 안 쓴다 | 컨설팅사인 경우가 많다 | 권고안·보고서 |
| Customer Success Engineer | 이미 쓰는 고객 | 가끔. 연동·스크립트 지원 | 그렇다 | 유지·갱신, 이슈 해결 |
| Platform Engineer | 사내 개발자 | 많이 쓴다 | 상관없다 | 사내 개발자가 혼자 배포할 수 있는가 |
Solutions Architect와 FDE의 차이는 OpenAI 사례를 다룬 글의 설명이 가장 구체적이었다. SA는 고객 인프라에서 코드를 쓰는 일이 드물고 PoC를 익명화한 데이터로 만드는 반면, FDE는 고객 인프라에서 직접 코드를 쓴다는 것이다. (Pragmatic Engineer, What are Forward Deployed Engineers) 같은 글에는 컨설턴트는 일회성 권고를 하고 FDE는 고객과 오래 일한다는 설명도 있다.
플랫폼 엔지니어와의 차이는 같은 글에 인용된 Palantir 설명이 잘 요약한다. 제품 개발자는 "one capability, many customers", FDE는 "one customer, many capabilities". 플랫폼 엔지니어는 앞쪽이고, FDE는 뒤쪽이다.
5. 0편의 자로 FDE 공고를 재 보면
갭 3개는 거의 나오지 않았다
0편의 갭 3개를 같은 7건에 대 봤다.
| 0편 갭 | 0편 (51건 중) | FDE 공고 (7건 중) |
|---|---|---|
| Kubernetes | 39 | 1 (2) |
| Terraform / IaC | 35 | 0 |
| 관측성 | 33 | 0 (2) |
Kubernetes를 적은 곳은 Superb 하나였고, 그것도 주요 업무와 우대사항에서였다. Terraform은 아예 없었고, 관측성은 비슷한 표현까지 쳐도 2건에 스택 이름은 하나도 없었다. 0편의 갭 3개는 본문 텍스트가 있는 FDE 공고 7건 중 어디에서도 필수요건이 아니었다.
예외가 하나 있다. 이미지로만 올라와 판정에서 뺀 메이머스트 공고를 나중에 글자로 옮겨 보니, 자격요건에 "Kubernetes 운영 및 DevOps, IaC 실무경험"이 적혀 있었다. 사람인 요약 항목에는 Kubernetes가 우대로 나오지만, 공고 원문대로라면 갭 3개 중 2개를 필수로 요구한 공고가 1건 있었던 셈이다.
모수도 다르고 직군도 다르니 그대로 비교하면 안 된다. 그래도 FDE 공고가 먼저 묻는 건 인프라 도구가 아니라 고객과 코드였다.
판정 게이트
0편에서 얻은 교훈은 하나였다. 내가 만든 점수는 "가고 싶은 정도"를 재고 있었고, "갈 수 있는 정도"는 안 재고 있었다. 그래서 PASS / STRETCH / BLOCKED 게이트를 붙였다.
| 판정 | 조건 (0편 그대로) |
|---|---|
| PASS | 연차 충족 + 필수요건 미보유 1개 이하 |
| STRETCH | 연차가 요구치의 절반 이상 또는 필수 미보유 2개 |
| BLOCKED | 요구 연차가 실경력의 2배 초과 또는 필수 미보유 3개 이상 |
여기에 이번 글에서 기준을 하나 더했다. 성향이나 태도를 묻는 항목은 미보유로 세지 않았다. 제르코닉스는 RAG·LangChain 항목이 필수인지 우대인지 공고에서 구분되지 않는다. 다만 RAG는 외주로 만든 카카오톡 상담 챗봇에서 써 봤으니, 필수든 우대든 미보유는 LangChain 하나뿐이라 어느 쪽이든 PASS다.
같은 자를 판정한 7건에 대 봤다.
| 판정 | 건수 | 공고 |
|---|---|---|
| PASS | 5 | 이루비, 컨포트랩, 채널톡, Superb, 제르코닉스 |
| STRETCH | 0 | |
| BLOCKED | 2 | VESSL, 링크알파(인턴, 참고용) |
솔직히 이건 예상과 달랐다. 처음엔 FDE가 플랫폼보다 한참 먼 자리라고 생각했는데, 이번 표본에서는 PASS가 BLOCKED보다 많았다.
점수와 판정이 또 어긋났다
0편과 같은 장면이 한 번 더 나왔다. 이번엔 어긋난 원인이 두 가지였다.
채점 점수는 이루비 70, 컨포트랩 67, 채널톡 66, VESSL·Superb 64, 메이머스트 64(본문 없이 제목과 연차만으로 매겨진 점수), 링크알파 58, 제르코닉스 52였다. 지원 후보로 뽑은 4건은 이루비, 컨포트랩, VESSL, Superb였다.
첫 번째는 0편과 같은 문제다. 점수 자체가 게이트와 맞지 않았다. 64점으로 후보에 든 VESSL은 게이트에서 BLOCKED였고, 52점으로 맨 아래였던 제르코닉스는 PASS였다. 점수는 이번에도 "가고 싶은 정도"를 재고 있었다.
두 번째는 이번에 새로 나온 문제다. 66점인 채널톡은 64점짜리 두 건보다 점수가 높았는데도 후보에서 빠졌다. 이루비·컨포트랩 같은 제조·비전 AI 쪽을 더 원해서 순위를 손으로 내렸고, 남은 근거는 그 메모 한 줄뿐이다. 그런데 채널톡은 게이트에서 PASS였다. 점수가 틀린 것도 문제지만, 그 점수마저 감으로 뒤집으면 갈 수 있는 자리를 내 손으로 지우게 된다. 0편에서 게이트를 따로 둔 이유가 이번에도 맞았다.
나를 막은 것
BLOCKED를 만든 건 Kubernetes도 Terraform도 관측성도 아니었다.
VESSL은 고객 대면 기술 업무 2년 이상을 요구했다. 0편 규칙대로 보안 경력을 개발 연차로 치지 않으면, 이 부분은 0년으로 잡힌다.
그런데 이 규칙은 DevOps 연차를 셀 때 쓰던 자다. 고객 대면 경력은 이야기가 다르다. 1장에서 쓴 외주가 바로 고객 대면 기술 업무였다. 요구사항을 받고, 범위와 견적을 잡고, 만들어서 납품했다. 특히 농수산물 발주 시스템은 한 번 넘기고 끝난 일이 아니다. 클라이언트의 거래처들이 지금도 그 시스템으로 직접 주문을 넣고 있다. 고객의 고객까지 실제로 쓰고 있는 시스템이다. Townfolks 건은 요구사항을 정리하는 단계부터 운영자에게 인수인계하는 단계까지 처음과 끝을 모두 맡았다. 사내에서도 보안 신고나 차단 요청을 처리하며 현업 부서를 상대한다.
다만 외주는 올해 4월에 시작해서 아직 1년이 안 된다. 사내 대응까지 쳐도 "2년 이상 고객 대면"으로 인정받을지는 회사 판단이다. 그래서 VESSL은 BLOCKED에서 STRETCH 사이 어딘가로 둔다. 확실한 건, 0편 규칙처럼 0년으로 칠 일은 아니라는 것이다.
링크알파는 인턴 공고라 내 경력과 직접 비교하기는 어렵지만, 요구한 내용은 참고할 만하다. LangGraph나 Claude Code SDK를 프로덕션에 배포해 본 경험, SSE·비동기 설계, 에이전트 E2E 운영이다. 인턴 공고가 이걸 요구한다는 것 자체가 신호다.
내 경우 프로덕션이라고 부를 수 있는 건 두 건이다. Townfolks 의뢰로 만들어 지금도 돌아가는 카카오톡 AI 상담 챗봇, 그리고 포트폴리오 사이트에 붙어 있는 이력서 챗봇. 이 시리즈의 공고 채점기를 19개 에이전트로 돌린 것이나 Claude Code와 MCP로 개발하는 건 내가 일하는 방식이지, 링크알파가 말한 프로덕션 에이전트 운영은 아니다.
정리하면 나를 막은 건 인프라가 아니라 고객 대면 경력의 증빙과 프로덕션 에이전트 스택이었다.
6. 그래서 순서를 어떻게 정했나
7건으로 0편을 뒤집을 수는 없다. 0편은 51건에서 같은 갭이 30건 넘게 반복된 결과였고, 이번은 포털 1페이지에서 건진 7건이다. 그래도 방향은 바꿀 만했다.
FDE를 지금 목표로 둔다. 이번 표본에서 PASS가 다수였고, 막은 것도 인프라가 아니었다. 기다린다고 열리는 문이 아니라, 들어가서 쌓는 경험이 더 많은 자리다.
플랫폼은 버리지 않고 병행한다. FDE 공고가 인프라를 적지 않았을 뿐, 고객 환경에 무언가를 배포하고 운영하려면 결국 그 바닥이 필요하다. Superb처럼 Kubernetes를 적은 곳도 있고, 메이머스트는 공고 원문 자격요건에 Kubernetes와 IaC를 적었다.
에이전트와 고객 쪽 역량을 앞으로 당긴다. 실제로 길을 막은 건 그쪽이었다. 외주에서 해 온 일을 "그냥 했다"가 아니라 증빙할 수 있는 형태로 남기고, 에이전트는 장난감이 아니라 운영하는 수준까지 끌어올리는 게 다음 일이다.
그리고 3장에서 미뤄 둔 얘기가 있다. 이번 공고에서 "폐쇄망에 들어가 설치하는 FDE"는 중심이 아니었다. 하지만 그런 고객은 분명히 있다. 금융, 공공, 그리고 보안 심사가 까다로운 대기업이다. 그 고객 앞에 서는 FDE에게는 고객사 보안팀이 무엇을 왜 막는지 아는 게 기술 스택만큼 중요하다. 이번 7건에는 그런 공고가 없었지만, 보안 성격이 강한 FDE 공고만 따로 모아서 다시 세 보는 게 다음 숙제다.
7. 앞으로 이 블로그에 쓸 것
비용 알럿 글보다 이 글을 먼저 끼워 넣은 건, 목표가 바뀐 걸 숨기고 프로젝트 글만 이어 쓰면 0편과 앞뒤가 안 맞기 때문이다. 바뀐 건 바뀌었다고 먼저 써 두는 게 맞다고 봤다.
시리즈 이름은 "보안에서 플랫폼으로"를 유지한다. 플랫폼은 여전히 메워야 하는 바닥이고, FDE는 그 위에서 서고 싶은 자리다. 앞으로 쓸 글은 세 갈래다.
- 에이전트로 일하는 방법. 0편 채점은 19개 에이전트에 나눠 돌렸고, 구글 채용 페이지 6건은 본문을 못 읽어서 미채점으로 남겼다. 이런 작업이 어디까지 믿을 만하고 어디서 틀리는지 쓴다. 링크알파가 요구한 프로덕션 에이전트 운영과도 닿아 있는 주제다.
- 배포 전 체크리스트. 외부 솔루션이 들어올 때 보안 담당자로서 내가 묻는 것들을, 들어가는 쪽 입장에서 다시 정리한다. 6장에서 말한 까다로운 고객 앞에 서기 위한 준비다.
- 깨진 것들. 0편에서 한 약속이다. 잘 된 것보다 망가진 걸 쓴다.
8. 다음 편 예고
다음 편은 0편에서 예고한 비용 알럿 얘기다. 멀티 에이전트로 공고 채점기를 만든 과정은 그다음 편이다.
FDE로 일하고 있거나 넘어가 본 사람이 있으면 댓글로 하나만 알려 주면 좋겠다. 고객 환경에서 처음 막혔던 게 뭐였는지. 고객사 보안팀 때문에 막혔던 얘기라면 더 반갑다. 아마 그 맞은편에 나 같은 사람이 앉아 있었을 거다.
이번 글에서 판정한 공고 (2026-10-07 저장본 기준)
- 이루비 — 사람인 공고
- 채널톡 — 원티드 공고
- 컨포트랩 — 원티드 공고
- Superb — 원티드 공고
- 제르코닉스 — 잡코리아 공고
- VESSL — 원티드 공고
- 링크알파 — 사람인 공고
- 메이머스트 (이미지 공고, 판정 불가) — 사람인 공고
참고한 글: a16z, Forward-deployed Job Titles · Pragmatic Engineer, What are Forward Deployed Engineers, and why are they so in demand? · Palantir, Forward Deployed Software Engineer 공고
시리즈: 보안에서 플랫폼으로
- [0편] 보안에서 DevOps로 전직 — 공고 455건 분석해보니 갭은 3개였다
- [1편] FDE가 뭐길래 — 보안 엔지니어가 0편 수집기로 FDE 공고를 다시 세 봤다 ← 현재 글
'Project > 보안에서 플랫폼으로' 카테고리의 다른 글
| 보안에서 DevOps로 전직 — 공고 455건 분석해보니 갭은 3개였다 (1) | 2026.07.27 |
|---|