FDE — 난제를 푸는 직군과 우리 맥락
공공과 기업의 AX 노드 끝에 「FDE가 우리 맥락에서 어떤 자리인지 정리한다」를 남겨 뒀다. 그 숙제를 갚는다. 마침 우리 쪽으로 들어오는 일 가운데 FDE형 의뢰 — 요구사항이 아니라 문제부터 들고 오는 건 — 이 눈에 띄게 늘고 있어 기준을 먼저 세워 둔다.
앞부분은 영상 요지, 뒷부분은 협동조합·사회연대경제 현장에서 일을 받는 우리 쪽에서 본 시사점이다.
화자는 엔터프라이즈 AX 스타트업 대표 황현태. 국내에서 이른 축에 속하게 FDE 방식을 실험해 왔고 현재 여러 대기업 AX 프로젝트를 수행 중이라고 밝힌다. 영상 자체는 패스트캠퍼스 강의 홍보물이라 후반부가 커리큘럼 소개다. 자동자막이 FDE를 내내 「FDA」로 찍고 회사명도 뭉개서, 용어는 맥락으로 바로잡았고 사명 표기는 확정하지 않았다.
1. 영상 요지
FDE는 난제를 푸는 사람이다
AI 프로젝트 엔지니어도, SI 개발자도, 컨설턴트도, PM도 아니다. 목표를 하나만 꼽으라면 어려운 문제를 푸는 것이다. 고객 발굴 → 문제 발견 → 문제 정의 → 솔루션 고안 → 구현 → 배포와 전사 확산까지 전 구간을 한 사람이 통과한다. 뒤쪽만 보면 SI 같고 앞쪽만 보면 컨설턴트 같지만, 다 하기 때문에 별개 직군이라는 설명이다.
기존 소프트웨어 엔지니어링은 문제가 이미 정의된 상태에서 좋은 해법을 내는 일이었다. FDE를 부르는 회사는 못 풀 수도 있겠다 싶을 만큼 위험한 것을 준다.
제목의 논지 — 클로드로 풀리면 부를 이유가 없다
모델이 좋아질수록 쉬운 문제는 다 풀린다. 요즘 유행하는 업무 자동화 AX도 결국 누구나 직접 하게 될 영역이라고 본다. 그래서 FDE는 「그냥 GPT나 클로드로 하면 될 걸 왜 우리를 부르나」를 스스로에게 계속 물어야 한다. 고객사 수준도 모델 수준도 같이 올라가는 중이라 더 그렇다.
본인 규정은 이렇다. 실력 좋은 고객사의 실력 좋은 팀원들이 고민해도 못 푸는 문제를, 밖에서 들어온 문제 풀기 전용 인력으로 푸는 사람. 엔터프라이즈 리더들은 그런 난제를 속에 품고만 있고, 그걸 하나씩 꺼내는 것이 FDE의 일이라고 말한다.
사례 — 대기업 인사팀
처음 받은 요청은 「인사 지표를 쉽게 추출해서 보고하기 편하게」였다. HR 업무 자동화로 문제를 인식하고 팀에 들어갔는데, 현장에서 보니 그 자동화를 아무도 원하지 않았다. 현업은 AX 프로젝트를 띄우라니까 자기 업무 하나를 올린 것이고, 보고받는 쪽은 자기 일이 아니라 자동화가 되든 말든 효능을 못 느꼈다.
실무자 옆에서 일을 같이 배워 보고 보고 자리까지 따라가 보니 진짜 문제는 따로 있었다. 보고 도중 나온 질문의 답이 하루나 이틀 뒤에 돌아온다. 담당자는 답을 알면서도 인사 정보라 즉답이 부담스러워, 팀에 돌아가 정리한 뒤 다시 보고하는 절차를 밟고 있었다. 과제는 「요구를 효율로 바꾸는 일」로 다시 정의됐다.
요구사항 정의를 받아 그대로 구현했다면 절대 알 수 없었을 일이라고 그는 말한다.
SI 개발자와 갈리는 두 지점
- 엔지니어링을 안 해도 된다. 적정 기술을 쓴다. 코딩이 필요 없으면 안 한다. 개발하러 들어간 사람이 개발을 안 해도 되는 것을 「문제 푸는 사람의 기세」라고 표현했다.
- 문제를 안 준다. 「뭐 해 볼까요」나 「네가 문제를 한번 찾아봐」 식으로 온다. 문제를 찾아 역으로 제안해야 하고, 그 문제의 난도가 충분히 높아야 한다.
자질 세 가지
- 앙트프러너십 — 이 회사는 FDE를 창업 경험자 중에서만 뽑는다고 한다. 「내가 풀 수 있다」는 과한 자신감을 가진 사람이 창업해 본 사람 말고는 드물다는 이유다. 문제 해결 능력에 대해 낙관적이어야 한다는 것.
- 비즈니스 마인드셋 — 고객 니즈를 엔지니어링의 눈이 아니라 사업의 눈으로 보고 이해관계까지 해석해야 한다. 솔루션에는 반드시 놀라는 지점이 있어야 한다고 말한다. 개발자 출신 중에서는 프로젝트·프로그램 매니저가 아니라 프로덕트 매니저로 간 유형이 맞다고 본다.
- 엔지니어링 스킬(가장 중요) — 유창한 코딩과 소프트웨어에 대한 이해. 여기서 한 말이 눈에 띈다. AI를 활용한 개발 기술보다, 기존 소프트웨어 엔지니어의 본래 역량이 탁월한 사람이 훨씬 낫다.
훈련 방식
커리큘럼은 마인드셋을 먼저 세우고, 실제 엔터프라이즈 사례를 놓고 15~20분 안에 해법을 고안하는 훈련을 반복하는 구조라고 소개한다. 강의보다 훈련에 가깝다는 설명이다. 여기서 나온 경고가 쓸 만하다. AI를 써서 낸 평범한 해법이라는 평가를 받을 수 있다 — 엔터프라이즈는 그 정도 고민은 이미 다 해 보고 안 되는 것을 들고 오기 때문이다.
혼자 준비하기 어려운 이유로는 참고할 자료가 사실상 팔란티어 것밖에 없다는 점을 든다. 기업은 자기가 받은 문제를 밖에서 말하지 못한다.
2. 우리 맥락에서 갈라 둘 것
여기부터는 영상의 주장이 아니라 우리 쪽 판단이다.
FDE·현장 챔피언·하네스 엔지니어는 다른 자리다
앞 노드에서 「FDE 몇백 명을 만들어야 한다」 같은 선언이 업계에서 소비되는 방식을 적어 뒀다. 세 자리를 갈라 두지 않으면 말만 따라 쓰게 된다.
| 어디 서 있나 | 무엇으로 값을 하나 | 성공하면 | |
|---|---|---|---|
| FDE | 밖에서 들어간다 | 그 조직이 못 푼 난제를 푼다 | 문제를 풀고 나온다 |
| 현장 챔피언 | 그 조직 사람이다 | 자기 업무의 최종 판단권을 쥔 채 먼저 바꾼다 | 옆자리로 퍼진다 |
| 하네스 엔지니어 | 안이든 밖이든 | 사람과 AI가 일할 판을 깐다 | 다음 사람이 그 위에서 일한다 |
우리가 실제로 맡는 일은 이 셋이 섞여 있다. 민들레 건은 챔피언 두 사람의 손을 살리는 일이고, 품에·품아이는 하네스를 까는 일이며, 요즘 늘고 있는 의뢰가 FDE 쪽이다. 섞여 있다는 것 자체는 문제가 아니지만, 견적과 기간을 뽑을 때는 셋 중 무엇으로 받는지 정해 놓고 받아야 한다. 난제 풀이로 받아 놓고 구축 일정으로 관리하면 양쪽 다 어긋난다.
「용병」이라는 말은 그대로 못 쓴다
영상의 자기 규정은 문제 풀기 전용 인력으로 들어갔다 나온다는 것이다. 그 태도에서 가져올 것은 분명하다. 난도에 대한 자신감, 그리고 쉬운 문제를 비싸게 팔지 않겠다는 선.
가져오면 안 되는 것도 분명하다. 우리가 들어가는 곳은 대부분 계속 관계를 맺을 조합과 현장이다. 풀고 나오면 끝이 아니라, 그 조직 사람이 이어서 굴릴 수 있는 상태로 두고 나와야 한다. 남의 조직 사이에 끼지 않는다는 원칙, 최종 판단권을 그 조직 챔피언에게 남긴다는 원칙이 여기서도 그대로다. 우리 쪽 번역은 **「밖에서 온 난제 해결자」이되 「나가면서 손잡이를 넘기는 사람」**이다.
수임 기준 — 클로드로 풀리는 일은 클로드로 풀게 하고 빠진다
영상의 질문은 우리에게 그대로 수임 기준이 된다. 의뢰가 들어왔을 때 먼저 묻는다.
- 이 일이 요즘 모델에 몇 번 물어보면 풀리는 일인가. 그렇다면 우리가 할 일은 수임이 아니라 그렇게 풀 수 있다고 알려 주고 쓰는 법을 남겨 주는 것이다.
- 요구사항이 온 것인가 문제가 온 것인가. 요구사항이 왔으면 그대로 짓기 전에 현장을 먼저 본다. 인사팀 사례가 그 값어치다.
- 우리가 아니면 안 되는 지점이 어디인가. 현장 도메인인지, 결사체 구조에 대한 이해인지, 데이터인지. 그게 안 짚이면 난제가 아니다.
의뢰가 늘 때 제일 위험한 것은 쉬운 것까지 받아 일정이 막히는 일이다. 거르는 기준을 먼저 세워 두는 이유다.
창업 경험 요건은 우리에게 다르게 온다
창업 경험자만 뽑는다는 채용 기준은 「낙관과 기세」를 사는 방법이지 유일한 방법은 아니다. 우리 쪽에서 같은 성질을 가진 사람은 조직 활동가다. 없는 것을 만들어 본 사람, 예산도 권한도 없이 판을 벌여 본 사람. 판별 질문은 학력이나 이력이 아니라 이것이다 — 안 되는 것을 맡겼을 때 물러서는가, 방법을 찾는가.
다만 영상에서 가장 중요하다고 한 대목은 우리에게도 그대로다. 마인드셋보다 엔지니어링 기본기가 먼저다. 그리고 AI 활용 기술보다 소프트웨어 자체에 대한 이해가 먼저라는 말은, 요즘 우리가 사람을 붙일 때 자주 착각하는 지점을 정확히 찌른다.
적정 기술론 — 코딩을 안 하는 것도 답이다
개발하러 들어가서 개발을 안 해도 된다는 대목은 우리 현장에서 자주 확인된다. 엑셀 한 장과 절차 한 줄로 끝나는 일에 시스템을 짓는 것이 가장 흔한 낭비다. 문제를 풀면 되는 것이지 무언가를 지어야 하는 것이 아니다.
3. 의뢰가 늘 때 지킬 것
- 문제부터 다시 본다. 요구사항 그대로 구현하는 건은 수임 전에 현장 관찰 한 번을 넣는다. 인사팀 사례가 없었으면 아무도 원하지 않는 자동화를 납품할 뻔했다.
- 셋 중 무엇으로 받는지 정한다. 난제 해결인지, 챔피언 세우기인지, 하네스 구축인지. 섞어 받되 계약서와 일정표에는 한 줄로 적는다.
- 쉬운 건 돌려보낸다. 모델로 풀리는 일은 푸는 법을 남겨 주고 빠진다. 그게 장기적으로 관계를 키운다.
- 손잡이를 넘기고 나온다. 끝난 자리에 그 조직 사람이 이어서 굴릴 수 있는 것이 남아야 한다.
- 남의 사례 숫자를 우리 실적처럼 쓰지 않는다. 앞 노드에 적은 원칙 그대로다.
4. 남은 일
- 우리가 받은 FDE형 의뢰를 유형별로 정리해 수임 기준을 실제 사례에 대 본다. 지금은 원칙만 있고 대조군이 없다.
- 「문제를 찾아서 역으로 제안하는」 단계를 우리 제안서 양식에 어떻게 넣을지 정한다. 현재 양식은 요구사항을 받아 적는 구조다.
- 훈련 방식 — 실제 사례를 놓고 짧은 시간 안에 해법을 내는 반복 — 을 활동가 배움터와 사교원 커리큘럼에 옮길 수 있는지 본다.
출처: 패스트캠퍼스, 「클로드, GPT로 풀리는 문제라면 FDE가 필요한 이유가 없습니다」, 2026-09-18, 11분 51초. https://youtu.be/q_A0piiiYtY 자막은 유튜브 자동자막이라 용어와 고유명사 표기는 영상 맥락 기준으로 바로잡았고, 확정할 수 없는 사명은 적지 않았다. 영상 후반부는 해당 사의 유료 강의 소개다.