AI 시대 개발자의 자리 (3/5) — 개발자 앞에 놓인 두 갈래, 그리고 그 사이의 FDE
AI 시대 개발자의 자리 (3/5) — 개발자 앞에 놓인 두 갈래, 그리고 그 사이의 FDE
2편에서 세 직군의 성숙도가 전부 다르다고 썼다. FDE만 직무로 굳었고, AI Native Engineer는 개발자의 새 기본값이고, GTM Owner는 아직 역할 개념이라고.
그런데 이걸 "어느 게 더 뜨거운가"로만 보면 정작 중요한 걸 놓친다. AI Native Engineer와 GTM Owner는 경쟁 관계가 아니라 서로 반대 방향이다.
| 방향 | |
|---|---|
| AI Native Engineer | 기술 쪽으로 다시 깊게 들어간다 |
| GTM Owner | 개발 경험을 들고 사업 쪽으로 나간다 |
같은 자리를 놓고 고민하는 게 아니라, 갈림길에서 어느 쪽으로 걸을지를 고민하는 것이다. 이번 편은 그 두 방향과, 그 사이에 걸쳐 있는 FDE에 대한 이야기다.
1. 두 갈래를 그림으로
내가 이해한 대로 그리면 이렇게 된다.
개발자
│
├── AI Native Engineer ← 기술 심화 방향
│ ↓
│ AI Engineer
│ ↓
│ AI Architect
│ ↓
│ AI Tech Lead
│
└── PM / Technical PM ← 사업 확장 방향
↓
GTM Owner
↓
Product / Business Lead
↓
AI 사업 책임자
왼쪽은 깊어지는 길이다. 다루는 기술의 난이도가 올라가고, 결정의 범위가 시스템 전체로 넓어진다. 오른쪽은 넓어지는 길이다. 기술에서 시작해서 고객, 가격, 매출로 책임이 옮겨간다.
둘 중 하나가 상위 경로인 게 아니다. 정점에 있는 자리는 양쪽 다 있다. 왼쪽 끝도 조직의 기술 최고 의사결정자고, 오른쪽 끝도 사업 책임자다.
2. 같은 문제를 주면 둘이 전혀 다른 일을 한다
말로만 구분하면 애매하니까, 같은 과제를 던져보자.
"우리 고객센터 업무를 AI로 자동화하자."
AI Native Engineer가 하는 일
이 사람은 만든다.
- LLM과 API 연결
- RAG 구축
- Agent 설계
- MCP·Tool 연동
- 데이터 파이프라인
- 기존 시스템 API 연결
- AI 워크플로우 자동화
- 배포와 모니터링
그냥 "AI 개발자"와는 조금 다르다. 모델을 쓰는 게 아니라 모델이 들어간 시스템을 만든다. 위 목록에서 실제로 시간이 많이 드는 건 모델 호출이 아니라 기존 시스템과 붙이는 부분과 모니터링이다. 그래서 "AI를 이용해 문제를 해결하고 제품을 만드는 엔지니어"에 가깝다.
GTM Owner가 하는 일
같은 AI 고객센터 제품을 놓고, 이 사람은 판다.
- 금융권을 타깃으로 할지, 제조업인지, 중소기업인지
- 어떤 가격으로 팔지
- 어떤 기능을 먼저 출시할지
- 고객을 어떻게 확보할지
- 영업팀·마케팅팀과 어떻게 움직일지
- 실제 매출을 어떻게 만들지
제품이 완성됐는지와 별개로, 그게 돈이 되는지를 책임진다. 그래서 GTM Owner는 제품 관리자보다도 사업 쪽에 가까워질 수 있다.
3. 두 방향을 나란히 놓으면
| 구분 | AI Native Engineer | GTM Owner |
|---|---|---|
| 핵심 | AI를 활용해 제품·시스템을 만드는 사람 | 제품을 시장에 팔고 성장시키는 사람 |
| 중심 질문 | "AI로 어떻게 만들지?" | "누구에게 어떻게 팔고 확산시키지?" |
| 업무 | AI Agent, RAG, API, 자동화, 서비스 개발 | 고객 발굴, 시장전략, 가격, 영업, 파트너십, 출시 |
| 기술 비중 | ★★★★★ | ★★ ~ ★★★ |
| 비즈니스 비중 | ★★ | ★★★★★ |
| 코딩 | 상당히 필요 | 경우에 따라 필요 |
| 고객 접점 | 중간 ~ 낮음 | 매우 높음 |
| 성과 지표 | 제품 출시, 기술 성능, 자동화 | 매출, 고객 수, 전환율, 시장 점유 |
| 커리어 방향 | AI Engineer / Solutions Engineer / AI Architect | Product / Growth / Business / Revenue 리더 |
이 표에서 제일 중요한 줄은 성과 지표다.
왼쪽은 만든 것으로 평가받는다. 출시했는지, 성능이 나오는지, 자동화가 됐는지. 오른쪽은 팔린 것으로 평가받는다. 매출, 고객 수, 전환율.
이 차이가 일하는 감각을 완전히 바꾼다. 잘 만들었는데 안 팔리면 왼쪽은 억울하고 오른쪽은 실패다. 어느 쪽 억울함을 감당할 수 있는지가 실제 선택 기준이라고 생각한다.
그리고 고객 접점 줄도 봐야 한다. 오른쪽은 매우 높음이다. 사람을 계속 만나는 일이 싫으면 오른쪽은 힘들다. 반대로 하루 종일 혼자 코드만 보는 게 답답하면 왼쪽이 힘들다. 이건 능력 문제가 아니라 성향 문제다.
4. FDE는 그 사이에 걸쳐 있다
여기서 FDE가 왜 지금 그렇게 뜨거운지 설명이 된다. 두 길 사이에 걸쳐 있기 때문이다.
AI Native Engineer
↕
FDE
↕
Technical PM
↕
GTM Owner
FDE는 기술과 고객과 비즈니스를 동시에 다룬다. 고객사에 나가서 문제를 찾고, 직접 만들고, 쓰이게 만들고, 그게 성과로 이어지는지까지 본다. 왼쪽 일과 오른쪽 일을 한 사람이 한다.
그래서 이런 특징이 생긴다.
| 양쪽으로 다 열려 있다 | FDE를 하다가 기술로 더 들어갈 수도, 사업으로 나갈 수도 있다 |
| 어느 쪽도 완전히 깊지는 않다 | 순수 연구나 순수 영업을 원하면 답답할 수 있다 |
| 경계에 있는 사람이 유리하다 | 개발만 한 사람도, 관리만 한 사람도 절반씩 새로 배워야 한다 |
| 정의가 회사마다 흔들린다 | 어떤 회사는 구축 중심, 어떤 회사는 진단부터. 면접에서 꼭 확인할 부분 |
세 번째 줄이 내 경우에 해당한다. 개발을 하다가 팀을 맡아 관리를 했고, 다시 직접 만드는 쪽으로 돌아왔다. 한동안은 이 이력이 어느 쪽으로도 애매한 것처럼 느껴졌다. 개발만 한 사람보다 코드를 덜 썼고, 관리만 한 사람보다 조직을 덜 봤으니까.
그런데 FDE 같은 자리를 놓고 보면 그 애매함이 조건이 된다. 문제를 찾는 건 관리 경험에서 오고, 만드는 건 개발 경험에서 온다. 둘 다 필요한 자리에서는 한쪽만 깊은 사람이 오히려 절반을 새로 배워야 한다.
물론 이건 내 상황에 맞춰 읽은 해석이다. 다만 채용 공고를 보면 실제로 그 조합을 요구하고 있어서, 혼자만의 희망적 해석은 아닌 것 같다.
5. 그럼 뭘 먼저 정해야 하나
두 갈래를 알고 나서도 바로 고를 수 있는 건 아니다. 순서를 이렇게 생각하고 있다.
- AI Native 방식은 선택이 아니다. 2편에서 쓴 것처럼 개발자의 기본값이 됐다. 왼쪽으로 갈 사람도 오른쪽으로 갈 사람도 여기는 거쳐야 한다
- 성과 지표 중 어느 쪽이 견딜 만한지 본다. 안 팔리는 게 내 실패로 계산되는 걸 받아들일 수 있는지가 갈림길이다
- 고객 접점의 양을 본다. 능력이 아니라 성향이다. 억지로 맞추면 오래 못 간다
- 정하기 어려우면 경계에 선다. FDE처럼 양쪽을 다 하는 자리에서 한 바퀴 돌아보면, 어느 쪽이 맞는지 몸으로 알게 된다
4번이 지금 내 선택에 가깝다. 어느 쪽인지 확신이 없을 때는 양쪽을 다 하는 자리가 가장 정보를 많이 준다.
6. 정리
- AI Native Engineer와 GTM Owner는 경쟁이 아니라 반대 방향이다. 하나는 깊어지고 하나는 넓어진다
- 같은 과제를 줘도 한쪽은 만들고 한쪽은 판다. AI 고객센터를 예로 보면 할 일이 전혀 겹치지 않는다
- 결정적인 차이는 성과 지표다. 만든 것으로 평가받는지, 팔린 것으로 평가받는지
- 고객 접점의 양은 능력이 아니라 성향 문제다
- FDE는 두 길 사이에 걸쳐 있다. 그래서 양쪽으로 열려 있고, 어느 쪽도 완전히 깊지는 않다
- 경계에 있던 이력이 경계에 있는 자리에서는 조건이 된다
그런데 왜 요즘 회사들이 오른쪽, 즉 사업을 책임지는 사람을 점점 더 찾는 걸까. 조직 트렌드만으로는 설명이 부족하다.
4편에서는 그 경제적 이유를 쓴다. AI 제품에는 예전 소프트웨어에 없던 원가 구조가 있고, 그 때문에 기술 결정이 그대로 손익 결정이 되어버렸다.
backtodev
A 40-something PM returns to code. Learning, failing, and growing.