개발자를 고객사에 보내서 시스템 구축해주는 건 똑같은데, 하나는 연봉 5천만원이고 하나는 7억입니다. 이름만 바꿔 붙인 건지, 진짜 다른 건지, 그 '20%의 차이'가 뭔지 뜯어봤습니다.

(우리에게 익숙한 SI와 전략 컨설팅을 잘 섞고 포장을 잘하면 FDE가 되는 게 아니냐는 얘기가 있는데 상당 부분 일리가 있습니다. 제가 보기엔 FDE가 이 둘을 포함하는 개념같아요. 그리고 요구 사항을 받는 입장보다는 먼저 제안을 하는 입장, 그리고 프로젝트 수행 시 표준화된 자사 시스템이 있느냐, 이걸 바탕으로 작업 후 그 노하우와 자산이 그 시스템에 계속 축적되며 고도화되느냐의 차이. 아, 그리고 미국엔 한국같은 중소형 로컬 SI가 많지 않고 있어도 비싸죠. 한국 SI들은 사실 상당한 경쟁력과 가성비가 있다고 생각합니다만...)


1. FDE, 이름값은 하고 있는가

- 요즘 채용시장에서 FDE(Forward Deployed Engineer)를 안 뽑는 회사를 찾는 게 더 어려운 지경이죠. AWS, MS, 구글, 심지어 OpenAI까지 FDE를 뽑고 있거든요
- 해외 기준 보상 리포트(Paraform, 2026년 6월)를 보면 mid-level FDE 총보상이 약 5억원, 시니어는 7억원 수준이라고 합니다
- 그런데 FDE가 뭘 하느냐고 물어보면... 고객사에 들어가서 솔루션 구축해주는 엔지니어예요. 이거 어디서 많이 들어본 얘기 아닌가요?
- "그거 SI잖아"라는 반응, 해외에서도 똑같이 나옵니다. 해커뉴스에서도 "이거 리브랜딩 아니냐"는 댓글이 줄을 잇고요

2. SI랑 80%는 같다, 솔직히

- 원 영상의 발표자도 인정하는 부분인데, FDE와 SI는 구조적으로 한 80% 정도 겹친다고 합니다. 고객 현장에 가서, 요구사항 파악하고, 솔루션 만들고, 납품하는 프로세스 자체가 동일하니까요
- 솔루션 아키텍트, 컨설턴트, SI 엔지니어... 이 모든 직무의 경계를 흐리고 있는 게 FDE라는 이름이라는 거죠
- 팔란티어에서 10년 전에 만든 이 직무명이 왜 이제야 이렇게 뜨거워졌느냐가 진짜 질문입니다

3. 나머지 20%가 연봉 10배를 만든다

- 전통 SI의 순서: 고객이 RFP(요구사항 문서)를 줌 - 컨설팅펌이 기획을 구체화함 - 개발팀이 받아서 구현함 - 납품. 이 순서가 수십 년간 굳어져 있었죠
- 문제는 이 과정에서 컨설팅사가 고객 말을 너무 충실히 옮기다 보면, 정작 진짜 문제가 아닌 걸 과대 해석하거나 핵심 문제를 놓치는 일이 생긴다는 겁니다. 개발자한테 넘어온 시점엔 이미 엎을 수가 없어요
- FDE는 이 순서를 뒤집는 겁니다. 코딩부터 하는 게 아니라 관찰부터 해요. 고객이 "대시보드 만들어달라"고 하면 바로 만드는 게 아니라, 왜 대시보드가 필요한지부터 캐묻는 거죠
- 가 보니까 진짜 문제는 예쁜 대시보드가 아니라, 부서마다 같은 지표를 다르게 해석하고 있는 것이었더라 - 이런 이야기가 나오는 게 FDE 방식의 핵심이에요

4. 팔란티어가 병원에서 보여준 것

- 허리케인 이안이 다가왔을 때, 미국 Tampa General Hospital이 FDE 사례의 교과서가 됩니다. 평시와 완전히 다른 방식으로 병원을 운영해야 하는 상황이었거든요
- 요구사항 문서 같은 건 존재할 수가 없었죠. 방금 정한 요구사항이 한 시간 뒤면 이미 안 맞는 상황이니까요
- 팔란티어 FDE가 한 건 어떤 기술로 해결할지 고민한 게 아니라, 흩어진 환자 정보-인력 배치-수술 일정-병상 현황을 하나로 묶어서 '지금 뭘 결정해야 하는지'를 볼 수 있게 만든 겁니다
- 24시간 내 배포가 가능했던 건 개발 속도가 빨라서가 아니에요. 현장 담당자와 개발자 사이에 전달 단계가 여러 겹 없었기 때문이죠
- 허리케인 지나간 뒤에도 그 시스템은 살아남았습니다. PACU(마취후 회복실) 대기시간 28% 감소, 환자 배치 관리 시간 83% 감소라는 숫자가 공식 사례로 남아있고요

5. 파나소닉과 에어버스에서 반복된 패턴

- 파나소닉 에너지 북미 지사: 장비 고장 나면 숙련 기술자 머릿속에만 있던 해결법을 어떻게 신입한테 전수하느냐가 과제였는데, 팔란티어가 장비 이력-센서 데이터-과거 작업 기록을 연결한 챗봇 인터페이스를 구축했습니다
- "그거 RAG 챗봇이네"라고 할 수 있는데, 실제로 회사에서 쓰이는 RAG 챗봇 만들어본 분들은 아시겠지만, 동일 주제 문서가 열 개 버전으로 존재할 때 AI한테 어떻게 넘겨줄 것이냐의 문제가 만만치 않거든요
- 에어버스 A350 사례는 더 극적이에요. 생산일정-부품-결함 데이터가 공장과 팀별로 다 흩어져 있었는데, 팔란티어가 이걸 연결해서 보여주는 온톨로지를 만들었고, 결과적으로 A350 생산량이 33% 향상됐다고 합니다. 항공기 한 대가 아니라, 항공기 생산 라인 전체의 33%예요

6. SI와 FDE의 진짜 분기점: 지식이 어디로 가느냐

- SI 프로젝트가 끝나면 보통 뭐가 남느냐? 고객한테는 시스템이 남고, SI 회사한테는 매출이 남습니다. 현장에서 새로 알게 된 도메인 지식은? 그냥 날아가는 경우가 태반이에요
- FDE 구조에서는 프로젝트가 끝날 때마다 회사가 조금씩 똑똑해지는 루프가 돌아야 합니다. 현장에서 발견한 문제 패턴, 데이터 구조, 의사결정 방식이 회사의 제품으로 다시 돌아오는 거죠
- 팔란티어 사례를 보면 작은 문제 하나를 뾰족하게 해결하고, 거기서 얻은 자산을 확장해서 플랫폼화하는 패턴이 반복됩니다. 에어버스의 스카이와이즈 플랫폼이 그렇게 탄생한 거고요
- 스타트업 세계에서 하는 "모든 걸 다 하지 말고, 뾰족하게 하나 잡아라"는 조언과 정확히 같은 논리예요

7. AI 시대, SI는 죽고 FDE는 사는가

- "생성형 AI 때문에 SI는 끝났다"는 말이 돌아다니는데, 정확히는 코드 만들고 화면 구현하는 비용이 급격히 내려가면서 차별화 포인트가 사라지고 있다는 뜻이에요
- 요구사항이 이미 정확하다면 고객사가 AI 써서 직접 하면 되거든요. 내부에 AI 팀도 있고요
- 그런데 개발 속도가 빨라진다고 문제가 해결되는 건 아닙니다. 문제를 잘못 정의하면 잘못된 결과물(slop)만 더 빠르게 쌓이는 거예요
- 문제를 정확하게 정의하고, 현장에서 검증하고, 필요하면 방향을 틀 수 있는 능력 - 이게 FDE의 가치가 올라가는 진짜 이유라는 거죠

8. FDE라는 이름은 과도기일 뿐이다

- 발표자의 마지막 메시지가 꽤 묵직합니다. "SI냐 FDE냐, 이런 구분은 앞으로 없어질 것이다"
- 모든 개발자가 결국 이렇게 일해야 한다는 거예요. 고객의 문제가 뭔지 파악하고, 어떻게 풀지 제안하고, 직접 만들고, 설득까지 할 수 있어야 한다는 것
- FDE라는 이름을 붙인다고 자동으로 되는 게 아니라, "나는 고객이 말하는 걸 구현하는 사람"이라는 인식에서 벗어나는 것부터 시작이라고 합니다
- 기획부터 개발, 배포까지 전부 책임지는 롤이라 잘하는 사람 찾기가 어렵고, 그래서 높은 몸값을 받는 거겠죠


(FDE라는 이름이 요즘 한국에서도 꽤 유행처럼 번지고 있는데, 정작 FDE를 운영하는 회사가 이 구조를 제대로 이해하고 계약 단계부터 고객에게 "우리는 이렇게 일합니다"라고 세팅하는 곳이 얼마나 될지 모르겠거든요. 이름만 FDE고 실제로는 요구사항 받아서 개발하는 구조라면 그건 그냥 SI인 거잖아요. 결국 SI든 FDE든, '현장에서 뭘 배워왔고 그게 회사에 뭘 남겼느냐'가 유일한 차이인 것 같습니다. 그래서 그걸 저희-AXMOS/ Popup Studio가 하고 있습니다 ^^)

출처: 모두의AI, "FDE는 SI 잡부 맞습니다. 근데 왜 그렇게 비쌀까요? | 하이프 체크 EP.3"