AI 시대 개발자의 자리 (2/5) — FDE, AI Native Engineer, GTM Owner는 같은 층에 없다
AI 시대 개발자의 자리 (2/5) — FDE, AI Native Engineer, GTM Owner는 같은 층에 없다
1편에서 대체되는 건 지시받은 것을 구현하는 일이고, 남는 건 무엇을 구현해야 하는지 정하는 일이라고 썼다.
그 남는 일을 회사는 여러 이름으로 부른다. FDE, AI Native Engineer, GTM Owner. 이 세 개를 나란히 놓고 "요즘 뜨는 직군"이라고 소개하는 글이 많은데, 실제 채용시장에서 보면 세 개는 같은 층에 없다.
하나는 이미 직무로 굳었고, 하나는 여러 이름으로 흩어져 있고, 하나는 아직 직무명이 아니라 역할 개념이다. 이걸 구분하지 않으면 준비하는 방향이 틀린다.
1. 한 장으로 보는 위치
2026년 기준으로 내가 보는 세 직군의 위치는 이렇다.
| 직군 | 트렌드 강도 | 직무명 표준화 | AI 연관성 | 핵심 |
|---|---|---|---|---|
| FDE | 🔥🔥🔥 매우 강함 | 높아지는 중 | 매우 높음 | AI를 고객 현장에 실제 적용 |
| AI Native Engineer | 🔥🔥🔥 강함 | 아직 낮음 | 매우 높음 | AI로 개발·자동화 |
| GTM Owner | 🔥🔥 강함 | 낮음 | 높음 | AI 제품의 시장 진입·매출 책임 |
셋 다 AI 시대에 부상한 직무군인 건 맞다. 다만 같은 정도로 트렌드라고 보기는 어렵다. 표준화 칸이 전부 다르다는 게 핵심이다.
2. FDE — 유일하게 직무로 굳은 이름
세 개 중에서 이것만 "직업"이라고 부를 수 있다.
로이터가 2026년 2월 26일에 지금 AI에서 가장 뜨거운 직무가 무엇인가를 다뤘고, 그 대상이 FDE였다. 기사 하나로 판단할 일은 아니지만, 채용 데이터가 같은 방향을 가리킨다.
| 지표 | 수치 |
|---|---|
| Indeed 기준 FDE 공고 (2025년 4월) | 643건 |
| Indeed 기준 FDE 공고 (2026년 4월) | 5,330건 |
| 전년 대비 증가율 | 약 729% |
| Lightcast 집계 증가율 | 1,000% 이상 |
수백 건에서 수천 건으로 한 해 만에 올라갔다. 이 정도 곡선은 유행이라는 말로 설명이 안 된다.
그리고 더 중요한 신호가 있다. OpenAI, Anthropic, Databricks, Palantir 같은 회사들이 별도의 조직과 직무군으로 FDE를 뽑고 있다. 기존 직군에 요구사항을 끼워 넣는 게 아니라 조직을 따로 만들었다는 뜻이다. 이게 직무 표준화의 실질적인 증거다.
표준화의 또 다른 증거는 공고를 여러 개 놓고 봤을 때 요구사항이 서로 비슷하다는 점이다. 회사가 달라도 원하는 게 거의 같으면, 시장이 그 역할을 이미 이해한 것이다.
FDE 자체가 AI 쪽으로 진화하고 있다
이게 제일 흥미로운 부분이다. FDE는 원래 AI 직군이 아니었다. 고객사에 나가서 시스템을 만드는 엔지니어였다. 그 내용물이 바뀌었다.
예전 FDE
고객사 → 요구사항 수집 → 시스템 구축 → 배포
현재 FDE
고객 문제 → AI Agent / RAG / LLM → 기존 시스템 연동
→ 실제 업무 자동화 → 고객에게 정착
차이가 두 군데다. 앞쪽은 "요구사항"이 "문제"로 바뀌었고, 뒤쪽은 "배포"가 "정착"으로 바뀌었다.
요구사항을 받는 게 아니라 문제를 찾는다. 배포하고 끝이 아니라 실제로 쓰이는 상태까지 만든다. FDE 직군을 따로 정리한 글에서 쓴 것처럼, 만든 걸 안 쓰면 실패로 계산되는 자리다.
실제 공고를 보면 확인된다. Databricks의 AI FDE 공고는 고객과 직접 협업하면서 프로덕션 환경에 GenAI 애플리케이션을 구축하는 역할로 설명하고, 요구 경험으로 RAG, 멀티 에이전트, Text2SQL, 파인튜닝을 명시한다.
고객 대면과 LLM 운영이 한 사람에게 붙었다. 예전에는 이 둘이 다른 직무였다.
3. AI Native Engineer — 직업이 뜨는 게 아니라 개발자가 바뀌는 것
여기서 관점을 바꿔야 한다. 나도 처음에는 이걸 새 직군으로 이해했는데, 공고를 실제로 찾아보니 그게 아니었다.
AI Native Engineer라는 명칭 자체가 FDE만큼 표준화되지 않았다. 회사마다 다르게 부른다.
| 회사가 쓰는 이름 |
|---|
| AI Engineer |
| Applied AI Engineer |
| AI Software Engineer |
| AI Engineer, FDE |
| AI Solutions Engineer |
| AI Architect |
이름이 여섯 개로 흩어져 있으면 그건 아직 직무가 아니다. 그래서 이렇게 읽는 게 정확하다.
"AI Native Engineer라는 직업이 뜬다"가 아니라, 개발자 자체가 AI Native 방식으로 바뀌고 있다.
근거는 공고의 요구사항 쪽에 있다. 2026년 채용공고에서 AI 관련 능력을 요구하는 비중이 빠르게 늘었고, 특히 기술직에서는 AI 활용 능력이 특수 역량이 아니라 일반 요구사항이 되어가고 있다.
이게 무슨 뜻인지가 중요하다.
| 새 직군이라면 | 새 기본값이라면 |
|---|---|
| 그 직군으로 지원하면 된다 | 모든 개발자 공고에 섞여 들어온다 |
| 안 맞으면 다른 직군을 보면 된다 | 피할 곳이 없다 |
| 경쟁자가 그 직군 지원자다 | 경쟁자가 전체 개발자다 |
| 준비 = 그 직군 공부 | 준비 = 일하는 방식 자체를 바꾸기 |
오른쪽이 지금 상황에 가깝다. 그래서 AINE는 **"준비해서 되는 자리"가 아니라 "개발자의 범위가 옮겨간 것"**으로 보는 게 맞다. 개발 자동화, AI를 붙인 설계, 출력 검증 같은 것들은 별도 직군의 특기가 아니라 개발자의 기본 업무로 내려오고 있다.
한 가지 덧붙이면, 위 목록의 네 번째 이름을 보자. AI Engineer, FDE. AINE와 FDE가 한 직무명 안에 같이 들어가 있다. 경계가 이미 섞이고 있다는 증거다.
4. GTM Owner — 직무가 아니라 조직 구조의 변화
이건 더 조심해서 봐야 한다. GTM Owner라는 명칭은 FDE처럼 표준화된 하나의 직업이 아니다. 이 이름으로 올라온 공고를 찾기가 어렵다.
그럼 왜 이 개념이 계속 나오나. 조직이 움직이는 방식이 바뀌고 있기 때문이다.
예전 구조 — 네 조직이 따로 움직인다
Product → Engineering → Sales → Customer Success
지금 흐름 — 하나로 본다
AI 제품을 만들고 → 고객에게 적용하고 → 시장에서 확산시킨다
AI 회사들이 커지면서, 이 세 단계를 끊어서 넘기면 제품이 안 팔린다는 걸 알게 됐다. 만든 사람이 적용을 모르고, 적용한 사람이 매출을 모르면 중간에서 계속 새기 때문이다.
그래서 GTM 쪽에 여러 직무가 생기고 있다. 이름이 통일되지 않은 채로 늘어난다.
| GTM 쪽에 생기는 직무 이름 |
|---|
| GTM Lead |
| GTM Engineer |
| Technical GTM |
| Product Marketing |
| Solutions Architect |
| Solutions Engineer |
| AI Transformation Lead |
| Business Development |
| Product / Business Owner |
아홉 개 이름이 있는데 하는 일은 겹친다. 이름이 아직 정해지지 않았다는 게 이 영역의 현재 상태다.
그런데 공고 이름과 별개로, 면접에서 받는 질문은 이미 이쪽을 향하고 있었다. 내가 실제로 받은 것 중에 이런 게 있었다.
- 이 기능을 만들면 유지비가 얼마나 드나
- 고객이 그 비용을 낼 만하다고 느낄까
- 우리가 이걸 직접 하는 게 맞나, 사는 게 맞나
전부 기술 질문이 아니고, 전부 기술을 알아야 답할 수 있는 질문이다. 이 교집합에 있는 사람을 부를 이름이 아직 없다.
그리고 재미있는 게, 채용 공고보다 면접 질문이 먼저 움직인다. 공고는 기존 직군 이름을 써야 하니까 늦고, 면접관은 실제로 필요한 걸 묻으니까 빠르다. 이름이 정해지기 전에 요구가 먼저 오는 셈이다.
5. 세 개를 한 문장씩으로
| FDE | 직무다. 이름으로 지원할 수 있고, 조직이 따로 있다 |
| AI Native Engineer | 개발자의 새 기본값이다. 별도 직군이 아니라 요구사항으로 내려온다 |
| GTM Owner | 조직이 합쳐지는 방향이다. 아직 이름이 아니라 역할 개념이다 |
이렇게 놓으면 질문이 달라진다. "어느 직군을 준비할까"는 잘못된 질문이다. 층이 다르니까 고르는 게 아니다.
현실적인 순서는 이렇다.
- AI Native 방식은 선택이 아니다. 어느 자리로 가든 기본값이 됐다
- 지금 자리가 가장 많은 건 FDE다. 이름으로 지원할 수 있는 유일한 쪽이고, 정의도 또렷하다
- GTM 쪽은 이름이 굳기 전에 경험을 쌓는 영역이다. 공고를 기다리면 늦는다
FDE가 곧 레거시가 된다는 말은 과장이다. 지금 가장 뜨거운 자리다. 다만 FDE만 하는 사람으로 머물면 한 겹 아래가 된다는 건 맞다고 본다. 지금 뜨거운 자리에 있으면서 다음 층의 질문에 답할 준비를 해두는 게 현실적인 전략이다.
6. 정리
- 세 직군의 성숙도가 전혀 다르다. 나란히 놓고 비교하면 판단이 틀린다
- FDE만 직무로 굳었다. 공고가 한 해에 643건에서 5,330건으로 늘고, 큰 회사들이 별도 조직으로 뽑는다
- FDE의 내용물이 AI로 바뀌었다. 요구사항 수집이 문제 발견으로, 배포가 정착으로 옮겨갔다
- AI Native Engineer는 직업이 아니라 개발자의 기본값이다. 이름이 여섯 갈래로 흩어져 있다
- GTM Owner는 직무명이 아니라 조직 구조의 변화다. 아홉 개 이름이 같은 일을 가리킨다
- 공고보다 면접 질문이 먼저 움직인다. 이름을 기다리면 늦는다
그런데 이 세 개를 "어느 게 더 뜨거운가"로만 보면 정작 중요한 걸 놓친다. AI Native Engineer와 GTM Owner는 경쟁 관계가 아니라 서로 반대 방향이다. 하나는 기술로 더 깊게 들어가는 길이고, 하나는 개발 경험을 들고 사업으로 나가는 길이다.
3편에서는 그 두 갈래를 그림으로 그리고, FDE가 왜 정확히 그 사이에 걸쳐 있는지 쓴다.
backtodev
A 40-something PM returns to code. Learning, failing, and growing.