FDE라는 방향을 생각하다

FDE를 설명한 글을 읽고 앞으로 어떤 개발자가 되어야 할지 생각해봤다. 고객 가까이에서 문제를 정의하고 직접 구현한다는 설명에는 내가 해온 일과 익숙한 부분이 많았다.

내 실무는 Salesforce 프로젝트가 중심이었고, 그다음으로 프론트엔드 프로젝트를 수행했다. 고객과 직접 요구사항을 논의하며 업무 시스템과 웹 서비스를 기획하고 개발했다. 최근에는 분석과 개발에 AI도 활용하면서, 개발자가 직접 수행할 수 있는 범위가 더 넓어질 수 있다고 느꼈다.

AI의 도움으로 더 많은 일을 할 수 있게 된다면, 개발자에게 요구되는 역할도 달라지지 않을까. 무엇을 만들지 판단하고, 구현한 기능이 고객의 문제를 해결하는지까지 확인하는 역할이 점점 중요해질 것이라고 생각했다. FDE는 그 방향을 구체적으로 보여주는 이름처럼 보였다.

FDE가 어떤 일을 하는지, 내가 경험한 SI와는 무엇이 다른지부터 살펴봤다. 이를 바탕으로 지금까지의 경험을 어떻게 발전시켜야 할지 정리해보고 싶었다.

---

FDE는 어떤 일을 하는가

고객 가까이에서 문제 정의부터 구현까지 맡는다

FDE는 Forward Deployed Engineer의 약자로, 전방 배치 엔지니어라고도 부른다. 핵심은 고객의 업무 맥락 안에서 직접 만든다는 점이다. 고객과 함께 해결할 문제를 구체화하고, 코드를 작성하고, 고객 환경에 배포한 뒤 피드백을 받아 개선한다. 참고한 잡코리아 글도 이처럼 문제 정의와 구현, 검증을 연결하는 역할로 설명한다.

최근 AI 기업의 FDE는 여기에 AI를 고객의 시스템에 연결해 실제 업무를 수행하거나 보조하게 만드는 역할을 맡는다. 어떤 업무를 AI에 맡길지 정하고, 필요한 데이터와 기능을 연결하며, 실제 사용에서 결과를 평가하고 개선한다. OpenAI의 FDE 직무 설명도 고객 업무의 범위를 정하는 일부터 구현·평가·운영 배포·사용 정착까지 포함한다. OpenAI FDE 직무 설명

FDE 전체를 AI 자동화 직군으로 정의할 수는 없지만, 최근 AI 분야에서 이 역할을 이해할 때는 고객의 업무 안에서 AI가 무엇을 하게 만드는지가 중요하다.

비슷한 직군과는 책임의 무게중심이 다르다

잡코리아의 FDE 직무 소개 글을 바탕으로 각 역할에서 주로 강조하는 일을 정리했다. 조직에 따라 역할의 범위가 달라지고 실제 업무도 겹친다.

직군	주로 강조하는 일
컨설턴트	문제를 진단하고 개선 방향과 실행 방안을 제시한다.
솔루션 아키텍트(SA)	요구와 제약에 맞는 시스템 구조와 기술 구성을 설계한다.
솔루션 엔지니어(SE)	도입 검토 과정에서 데모와 PoC로 기술적 적합성을 보여준다.
FDE	고객과 문제를 구체화하고 직접 구현해 운영 환경에서의 사용과 개선까지 이어간다.

FDE 설명에서 눈에 들어온 것은 고객 대화, 설계, 코딩, 배포가 하나의 책임 범위로 이어진다는 점이었다. Salesforce의 설명도 데이터·권한 설계부터 운영 배포 후 지원, 사용자 정착까지 포함한다. 현장에서 얻은 경험을 제품팀에 전달하는 연결도 강조한다. Salesforce의 FDE 운영 설명

가령 상담원이 주문 이력을 찾는 데 시간이 오래 걸린다면, 담당자가 어떤 화면을 오가는지부터 살펴볼 수 있다. 필요한 정보와 접근 권한, 데이터 연결의 제약을 확인하고 해결책을 구현한 뒤, 실제로 찾기 쉬워졌는지 확인하는 것이다. 조회 기능 하나를 구현하는 데에도 업무를 이해하는 과정과 사용 이후의 확인이 함께 들어간다.

다만 이런 설명만으로 FDE와 다른 개발 직군의 경계가 선명해지는 것은 아니었다. 고객과 소통하며 기획하고, 구현 이후에도 사용과 개선을 살피는 일은 내가 경험한 SI에서도 수행했기 때문이다.

---

SI와는 무엇이 다른가

SI는 System Integration의 약자로, 고객에게 필요한 시스템을 구축하고 기존 시스템과 통합하는 일을 가리킨다. SI는 사업과 프로젝트 수행의 성격을, FDE는 엔지니어에게 부여하는 역할을 설명하는 말로 보면 두 개념의 관계를 이해하기 쉬웠다. SI 프로젝트 안에서도 FDE가 설명하는 역할을 수행할 수 있으므로, 서로 배타적인 직군으로 나누기는 어렵다.

내 경험에서도 고객 미팅과 요구사항 기반 기획·개발은 기본적인 업무였다. 반복되는 문제를 플랫폼 제품팀에 전달하고, 여러 고객이 사용할 공통 기능으로 만들고, 실제 사용과 효과를 확인하는 일도 계속 해왔다.

실제 조직에서도 두 영역이 겹친다. Salesforce의 FDE 파트너 네트워크에는 Accenture·Deloitte·IBM Consulting 같은 기업이 참여한다. 고객 시스템을 구축하고 통합하는 조직이 FDE 역할을 함께 운영하는 구조다. Salesforce FDE 파트너 네트워크 발표

차이를 이해하려면 특정 조직의 업무 범위를 구체적으로 살펴봐야 한다. 어떤 제품이나 플랫폼을 고객 업무에 적용하는지, 문제를 정하는 과정에서 엔지니어가 어떤 권한을 갖는지, 배포 이후에는 어디까지 책임지는지가 그 기준이 될 수 있다. FDE로 직접 일해본 것은 아니지만, 지금까지 살펴본 설명에서는 내가 경험한 SI와 공통점이 많았다.

---

왜 지금 FDE인가

AI가 동작하는 것과 업무가 달라지는 것 사이

AI가 질문에 답하는 모습을 보여주는 것과 그 기능을 업무에 넣는 것은 서로 다른 문제다. 상담을 돕는 AI를 생각해보면 답변을 생성하는 것 외에도 정해야 할 일이 많다. 어떤 고객의 주문과 자산을 조회할 수 있는지, 상담원이 볼 수 없는 정보가 답변에 섞이지 않는지, 잘못된 판단이 실제 데이터 변경으로 이어지지 않는지를 함께 다뤄야 한다.

기존 시스템과의 연결도 남는다. CRM과 ERP에서 같은 정보를 다르게 관리하고 있다면 어느 데이터를 사용할지 정해야 하고, 외부 연동이 실패했을 때 사용자가 이어서 일할 수 있어야 한다. 답변이 그럴듯하더라도 담당자가 매번 처음부터 다시 확인해야 한다면 업무가 줄었다고 말하기 어렵다.

예를 들어 상담 업무라면 AI가 문의를 분류하고, 주문·수리 이력과 문서를 조회해 답변을 작성하도록 구성할 수 있다. 이후 필요한 작업은 허용된 Action으로 실행하고, 담당자의 승인이 필요한 경우에는 확인을 요청하도록 설계할 수 있다. 어떤 단계는 AI가 처리하고 어떤 단계는 사람이 판단할지, 실패하면 어떻게 업무를 이어갈지까지 정해야 한다. FDE가 고객과 함께 구현하고 검증할 대상은 이런 전체 업무 흐름이다.

기술을 실제 업무에 붙이는 과정에는 모델 지식과 구현력에 더해 데이터와 권한, 업무 순서, 사용자의 판단을 함께 이해하는 사람이 필요하다. 이 지점에서 기업용 시스템 개발 경험이 AI 도입과도 연결된다고 봤다.

기업들도 실제 도입을 지원할 인력에 투자하고 있었다

관련 동향은 2026년 10월 16일 기준으로 공식 발표를 확인했다. 회사마다 FDE를 운영하는 방식은 달랐지만, 고객 환경에서 AI를 구현하고 실제 사용으로 연결한다는 방향이 반복됐다. 다음은 그중 세 가지다.

발표	확인한 내용
Salesforce · 2026년 4월	FDE 파트너 네트워크를 출범하고 Agentforce의 운영 배포와 제품팀 연결을 강조했다.
AWS · 2026년 6월	FDE 조직 신설과 10억 달러 투자를 발표했다. 고객 팀과 함께 구현하고, 이후 고객이 스스로 운영하는 것을 목표로 제시했다.
Anthropic · 2026년 10월	1억 달러를 투자하는 Claude Frontier Academy를 발표하고 2027년 말까지 1만 명의 엔지니어를 육성하겠다는 목표를 제시했다.

각 내용은 Salesforce, AWS, Anthropic의 공식 발표에서 확인했다. Anthropic은 해당 교육 프로그램에서 Frontier Deployed Engineer라는 명칭을 사용한다.

이 발표들에서는 AI를 고객 업무에 적용할 구현 역량을 확보하려는 움직임을 읽을 수 있었다. 내가 주로 사용해온 Salesforce에서도 같은 방향의 조직과 파트너 체계를 확대하고 있다는 점이 눈에 들어왔다.

AI는 개발자가 맡을 수 있는 범위도 넓힌다

AI를 도입하는 고객이 늘어나는 것과 함께, 개발자가 일하는 방식에도 변화가 생긴다고 생각한다. 분석과 코드 작성에 AI의 도움을 받으면 구현 부담을 줄이고, 요구사항을 구체화하거나 결과를 검증하는 데 더 많은 시간을 쓸 여지가 생긴다. 개발자가 문제 정의부터 구현 이후의 확인까지 직접 참여할 수 있는 범위가 넓어지는 것이다.

나는 이런 변화가 개발자에게 기대하는 역할에도 영향을 줄 것이라고 본다. 개발 과정에서는 AI의 도움으로 더 넓은 일을 수행하고, 고객의 시스템에서는 AI가 맡을 수 있는 업무를 설계하게 되는 것이다. 두 경우 모두 업무를 이해하고 결과를 판단하는 능력이 중요하다. 이 관점에서 내가 해온 일을 다시 살펴봤다.

---

내가 해온 일과 겹치는 부분

내가 참여한 모든 실무 프로젝트에서는 고객과 직접 미팅하며 요구사항을 듣고 기획과 개발을 진행했다. 그중 업무 흐름을 함께 정하고, 이를 시스템으로 구현한 사례들을 돌아봤다.

검수 업무를 웹 시스템으로 기획하고 구현했다

글로벌 CI 검수 웹 시스템에서는 국가와 검수 라운드별 진행 상황을 파악하고, 개별 항목을 검토하며 메일 발송 상태까지 관리할 수 있어야 했다. 나는 고객과 직접 요구사항을 논의하면서 기획부터 화면 디자인, 개발까지 전 과정에 참여했다. 검수 단계에 따라 어떤 정보를 보여주고 어떤 작업을 할 수 있게 구성할지 구체화하는 일이었다.

단계별 목록과 상세 화면을 만들고, 국가·라운드별 현황을 볼 수 있는 대시보드와 지역·국가 필터를 구현했다. 담당자는 전체 진행 상황을 살핀 뒤 필요한 범위의 검수 항목을 찾아볼 수 있게 됐다. 10만 건 이상의 데이터에는 페이지네이션을 적용해 나눠 조회하도록 했다.

메일은 생성과 다중 발송뿐 아니라 서버가 반환한 처리 결과를 상태와 이력 화면에 반영하도록 연결했다. 담당자가 발송 결과를 확인할 수 있는 흐름까지 구현했고, 필요한 기능의 서버 코드도 작성했다.

서로 다른 주문 업무를 시스템의 규칙으로 정리했다

AS 관리 시스템에서는 사용자의 소속과 역할, 주문 유형에 따라 필요한 정보와 처리 방식이 달랐다. 서비스·영업·대리점 등 각 사용자의 요구를 반영하면서도, 지사와 영업 정보가 업무 기준에 맞게 연결돼야 했다. 그래서 고객과의 미팅에서 들은 요구를 내부·외부 사용자, 지사, 영업구분 등의 조건으로 정리하고 PM·영업 담당자와 확인했다.

이 기준을 바탕으로 주문 유형에 따라 입력 항목이 달라지는 화면을 만들고, 설치지사를 선택하면 관련 영업 정보가 자동으로 반영되도록 했다. 반복해서 쓰는 제품·사은품 조합은 패키지로 관리하고, 조합할 수 없는 품목은 등록 단계에서 막았다. 그 결과 업무에 맞는 입력 항목을 보여주고 잘못된 조합을 차단하는 일을 시스템이 처리하게 됐다.

기존 ERP 업무를 옮길 때는 화면과 함께 데이터 연결도 맞춰야 했다. SAP·OMS 개발사와 인터페이스를 협의하고 주문·재고·자산 단위로 로직과 데이터를 검증했다. 고객의 요구를 기획으로 정리하는 일부터 다른 시스템과의 연결을 확인하는 일까지 하나의 구축 과정으로 이어졌다.

PC에서 처리하던 사진 등록을 모바일에서도 가능하게 했다

모바일 영업 관리 프로젝트에서 고객의 주요 요구사항 중 하나는 사진 업로드와 관리 시스템이었다. 영업 증빙자료와 실제 배치 상태를 촬영한 사진을 시스템에 등록해야 했는데, 기존에는 사진을 한 장씩 별도로 올려야 했다. 특히 모바일에서는 업로드할 때마다 파일 목록을 뒤져 사진을 하나씩 찾아야 해서 PC보다 작업이 훨씬 번거로웠다. 결국 사용자들은 사진 등록을 PC에서 한 장씩 처리하고 있었다.

필요한 것은 PC와 모바일 어디서든 여러 사진을 쉽게 등록하고 관리할 수 있는 흐름이었다. 두 환경에서 모두 사용할 수 있는 다중 업로드를 구현하고, 여러 이미지를 선택하거나 선택을 해제할 수 있도록 했다. 등록한 이미지를 삭제하고 관리할 수 있는 별도 페이지도 만들었다. 큰 파일은 모바일의 메모리 제약을 고려해 나눠 전송하도록 구현했다.

이렇게 사진 선택부터 업로드, 등록 후 관리까지 연결하면서 모바일에서도 여러 사진을 한 번에 등록하고 정리할 수 있게 됐다. 고객이 주요 과제로 꼽았던 사진 관련 요구를 해결했다. 이후 2주간의 안정화 기간 동안 오류 0건을 기록했고, 고객 만족도 조사에서는 5점 만점에 5점을 받았다. 사용자가 왜 PC에서만 등록하고 있었는지 파악하고, 실제 작업 환경에 맞춰 사진 업무 전반을 개선한 경험이었다.

AI 기능 구현과 서비스 운영으로 경험을 넓혔다

AS 관리 시스템과 유럽 콜센터 프로젝트에서는 AI를 분석과 개발에 활용했다. Agentforce 대회 PoC에서는 AI를 서비스 기능으로 구현해봤다. 문서 검색과 업무 Action을 연결하고, 고객이 필요한 정보를 직접 찾고 지원받는 기능을 만들었다. 개발 과정에서 AI의 도움을 받는 경험에 더해, AI가 정보를 찾고 업무 기능을 호출하도록 구성해본 경험이었다. 앞으로는 이런 기능이 실제 업무에서 어떤 결과를 내는지, 예외 상황에서도 의도한 대로 동작하는지까지 다뤄보고 싶다.

직접 만든 기능을 유지하고 운영하는 경험은 개인 프로젝트인 Mublog에서도 쌓았다. 글 작성과 발행 기능을 개발한 뒤 데이터 이관과 운영을 이어갔다. 이관한 글이 기존과 동일하게 렌더링되는지 대조하고, 서비스 제약에 맞춰 통계 수집 방식을 설계했다. 기능을 만든 이후에도 데이터와 운영 조건을 살피며 서비스를 유지해야 했다.

---

왜 FDE를 목표로 하는가

고객과 업무를 논의하고, 필요한 기능을 기획하고 구현하는 일은 지금까지 내 실무의 중심이었다. Salesforce와 프론트엔드 프로젝트를 거치며 업무 규칙, 데이터 연결, 사용자가 일하는 화면을 함께 다뤘다. 이 경험은 고객의 업무 중 어떤 부분을 AI에 맡길 수 있는지, 이를 위해 어떤 정보와 기능을 연결해야 하는지 판단하는 기반이 될 수 있다고 생각한다.

내가 FDE를 목표로 생각하는 이유는 개발자에게도 점차 이런 수준의 역할이 요구될 것이라고 보기 때문이다. AI가 분석과 구현을 도우면 개발자는 문제 정의부터 검증까지 더 넓은 범위를 직접 수행할 수 있다. 동시에 고객의 시스템에도 AI를 적용해, 사람이 처리하던 업무의 일부를 맡기거나 판단을 돕게 할 수 있다. 개발자가 수행할 수 있는 범위와 만들어낼 수 있는 해결책이 함께 넓어지는 것이다.

앞으로는 AI를 활용해 고객의 요구를 구체화하고 구현하는 능력과, 고객 업무에 AI를 적용해 평가하고 운영하는 능력을 함께 쌓고 싶다. AI가 조회할 수 있는 정보와 실행할 수 있는 작업을 정하고, 사람이 확인해야 할 단계를 설계하며, 실제로 업무가 개선됐는지까지 확인하는 경험이 필요하다. Agentforce PoC에서 시도한 문서 검색과 업무 Action 연결도 그 방향으로 발전시켜보고 싶다.

내가 현재 하고 있는 일의 종착점으로 생각하는 역할이 FDE다. 지금까지 해온 고객 중심의 기획과 개발을 바탕으로, AI와 함께 더 넓은 일을 수행하고 고객의 업무에도 AI를 적용해 그 결과까지 책임지는 개발자를 목표로 삼으려 한다.