14. 장단점과 전망

FDE를 두면 고객의 문제를 이해하고 구현하는 과정이 가까워진다. 요구가 불분명해도 작은 개발을 통해 확인할 수 있고, 실제 사용에서 드러난 문제를 곧바로 수정할 수 있다. 제품의 설명만으로는 풀리지 않는 도입 문제에 유용한 방식이다.

대신 숙련된 사람이 고객별 상황을 오래 다뤄야 한다. 고객을 잘 이해한 엔지니어가 빠져나오기 어려워지고, 개별 개발이 늘면서 공통 제품의 개선이 뒤로 밀릴 수도 있다. FDE의 장점을 얻으려면 이 비용을 받아들이고 관리할 조건이 필요하다.

지금까지의 논의를 종합하면 현재의 AI FDE에는 기술과 제품이 성숙하기 전의 빈틈을 메우는 과도기적 성격이 있다. 다만 모든 FDE 직무가 일시적이거나 곧 사라진다고 단정할 근거는 없다. 제품이 흡수할 수 있는 업무와 새로운 고객 문제를 다루는 업무를 나누어 보아야 앞으로의 변화를 설명할 수 있다.

장점

가장 직접적인 장점은 문제를 설명하는 사람과 구현하는 사람 사이의 정보 손실을 줄일 수 있다는 점이다. 여러 단계를 거친 요구사항에서는 빠지기 쉬운 업무의 예외와 사용자의 불편을 개발자가 직접 알게 된다. 잘못 이해한 부분도 결과물을 함께 보며 수정할 수 있다.

FDE는 불확실한 요구를 검증하는 데에도 도움이 된다. 고객이 원하는 기능이 실제로 필요한지, 필요한 데이터가 있는지, 작은 범위로 시작해도 가치가 있는지를 구현과 함께 판단한다. 처음부터 큰 시스템을 약속하기보다 무엇이 가능한지 배우며 범위를 정할 수 있다. 고객이 실험에 참여하고 결과에 따라 계획을 바꿀 수 있을 때 이런 장점이 살아난다.

현장의 경험은 제품 개발에도 도움이 될 수 있다. 고객의 요구만 전달하는 것보다 실제로 실패한 조건과 해결 방법까지 전달하면 제품팀이 문제를 이해하기 쉽다. 다만 그 경험을 검토하고 공통 기능으로 개발할 팀이 있어야 고객 한 곳의 해결을 넘어선 효과가 생긴다.

이 조건이 갖춰지지 않으면 FDE는 고객 가까이에서 일하면서도 정해진 요청을 처리하는 데 머물 수 있다. 직무명을 바꾸는 것만으로 문제 발견이나 제품 학습이 생기지는 않는다.

단점

고객의 업무를 깊이 이해하는 데 시간이 들고, 그렇게 얻은 지식이 특정 사람에게 집중되기 쉽다. 다른 엔지니어가 코드를 읽을 수 있어도 고객이 왜 그 규칙을 요구했는지까지 바로 이해하기는 어렵다. 담당자 교체와 운영 인수에 별도의 노력이 필요한 이유다.

고객마다 일정과 우선순위가 다르다는 점도 부담이다. 새 프로젝트에 집중하던 중 이전 고객의 장애가 발생할 수 있고, 여러 고객의 긴급 요청이 겹칠 수 있다. 지원 책임을 정리하지 않으면 현재 진행 중인 개발의 속도와 품질이 함께 영향을 받는다.

개별 개발이 계속 쌓이면 제품과 고객별 코드의 관계도 복잡해진다. 공통 제품의 업데이트가 기존 연동에 영향을 줄 수 있고, 고객별 예외를 제품 본체에 넣다가 전체 구조가 복잡해질 수도 있다. 처음 개발하는 비용과 이후 유지하는 비용을 함께 보는 7장의 논의가 여기에서 중요해진다.

관리 방법을 마련해도 비용이 모두 없어지는 것은 아니다. 고객별 차이가 큰 업무를 깊게 지원하는 데에는 그만큼의 자원이 필요하다. 이 비용을 가격이나 조직 계획에 반영하지 않으면 좋은 프로젝트 경험이 지속 가능한 사업으로 이어지기 어렵다.

구조적 한계

FDE가 잘 일해도 해결하지 못하는 문제가 있다. 고객이 데이터 접근을 허용하지 않으면 필요한 검증을 할 수 없다. 업무 책임자가 결정하지 않으면 승인 규칙을 확정할 수 없다. 기술적으로 작동하는 기능을 만들었어도 사용자가 기존 절차를 바꿀 권한이나 시간을 갖지 못하면 도입이 멈춘다.

모델이나 제품의 능력에도 한계가 있다. 업무에 필요한 정확도와 실행 조건을 현재 기술로 충족할 수 없다면 개발자를 더 투입한다고 반드시 해결되는 것은 아니다. 범위를 줄이거나 사람이 처리할 부분을 남기거나 프로젝트를 중단하는 판단이 필요할 수 있다.

경제성의 한계도 별개다. 자동화로 줄일 수 있는 업무보다 구축·운영 부담이 크다면 기술적인 성공과 사업적인 성공이 갈라진다. 제품 공급사는 그 프로젝트에서 얻은 학습을 다른 고객에게 활용할 수 있지만, 독립 구축업체가 같은 이익을 얻는다고 가정할 수는 없다.

따라서 FDE는 제품의 부족함, 고객 조직의 결정 부재, 낮은 사업 가치를 한꺼번에 해결하는 보편적인 수단이 되기 어렵다. 어느 문제가 개발로 풀리고 어느 문제는 고객이나 공급사의 결정이 필요한지 구분해야 역할의 범위를 현실적으로 잡을 수 있다.

과도기적 역할

‘과도기’라는 표현은 세 가지 수준에서 생각할 수 있다. 첫째는 고객 프로젝트의 단계다. 초기에는 FDE가 문제를 조사하고 구현하지만 적용 방법이 정해지면 고객 운영팀이나 구현 지원팀으로 넘길 수 있다. 프로젝트 안에서 FDE의 개입이 줄어드는 것은 자연스러운 결과다.

둘째는 특정 업무에 필요한 개발이다. 초기에 직접 만들었던 연결 기능, 실행 도구와 화면이 공통 제품에 들어가면 다음 고객에게 같은 개발을 할 필요가 줄어든다. 이때 줄어드는 것은 그 문제를 해결하기 위한 맞춤 작업이다.

OpenAI는 FDE의 목표를 다음 고객에게 더 나은 출발점을 제공하고, 같은 종류의 문제에 다시 FDE가 필요하지 않도록 만드는 방향으로 설명한다. 이는 제품화에 따라 개입을 줄이려는 공급사의 관점을 보여준다. 모든 회사의 프로젝트가 그렇게 진행된다는 증거는 아니지만, FDE를 영구적인 고객별 개발 인력으로만 이해하기 어려운 이유가 된다. OpenAI의 FDE 설명

셋째는 직무 전체의 존속이다. 특정 업무가 표준화되어도 새로운 기술과 고객 환경에서는 다시 불확실한 문제가 나타날 수 있다. 해결한 업무가 제품으로 넘어가고 FDE가 다음 문제로 옮겨갈 수 있는 것이다. 따라서 개별 프로젝트의 개입 감소를 직업 전체의 소멸과 동일하게 볼 수는 없다.

현재 AI FDE가 맡는 여러 일이 제품과 도구의 발전으로 바뀔 가능성은 있다. 그러나 고객의 업무를 이해하고 기술적 선택과 조직의 결정을 연결하는 일이 얼마나 남을지는 산업, 제품과 고객의 내부 역량에 따라 달라진다.

업무 변화

앞으로의 역할을 생각할 때는 특정 도구를 사용하는 능력과 그 도구로 어떤 문제를 풀지 판단하는 능력을 나눠 볼 수 있다. 정형적인 연결과 화면 작성은 공통 제품과 개발 도구가 맡을 여지가 있다. 반면 어떤 데이터가 업무상 맞는지, 자동화 결과를 어떻게 평가할지, 고객이 어떤 운영 책임을 받아들일지에는 현장의 판단이 필요할 수 있다.

아래는 2026년 11월 기준의 조건부 전망이다. 자동화의 시점이나 인원 감소를 예측한 표는 아니다.

OpenAI의 Deployment Lead와 Anthropic의 FDE 관리자 공고에는 구현 외에 일정·이해관계자 조율을 맡는 역할이 나타난다. 이처럼 분업은 이미 일부 조직에서 관찰된다. 앞으로 모든 회사가 같은 직무 체계를 채택할 것이라는 뜻은 아니다. OpenAI 공고, Anthropic 공고

도구를 이용하는 엔지니어가 늘어나는 것과 FDE라는 직함의 인력이 늘어나는 것도 다른 현상이다. 유사한 일을 제품 엔지니어, 산업별 솔루션팀이나 고객사의 내부 개발팀이 맡을 수 있다. 직무명만 세어서는 실제 업무의 변화를 모두 파악하기 어렵다.

세 가지 전망

제품화

반복되는 고객 문제가 공통 기능으로 해결되면 표준 도입에는 FDE가 덜 필요해질 수 있다. 담당자는 더 어려운 고객 문제로 이동하거나 제품팀에 합류할 수 있다. 다음 고객의 도입 시간이 줄고 별도 코드와 지원 요청이 감소한다면 이 방향의 변화로 볼 수 있다.

다만 개발 비용이 낮아져 이전에는 시도하지 못했던 업무까지 자동화한다면 전체 프로젝트 수는 늘어날 수 있다. 고객 한 곳에 필요한 인력이 줄더라도 전체 FDE 수요가 같은 비율로 감소한다고 결론 낼 수는 없다.

전문화와 분업

산업의 규칙과 업무 평가가 어려운 프로젝트에서는 도메인 지식을 가진 엔지니어의 역할이 남거나 커질 수 있다. 구현, 평가, 고객 협의와 운영을 나누는 팀도 생길 수 있다. 이 경우 FDE는 한 사람이 모든 일을 맡는 형태에서 여러 전문가가 함께 고객 문제를 해결하는 형태로 바뀔 가능성이 있다.

이 방향에서는 채용 조건과 성과 평가도 달라질 수 있다. 사용 가능한 도구의 수보다 특정 업무를 이해하고 결과를 검증한 경험이 더 중요해질 수 있다. 이는 역할이 성숙하는 한 가지 경로이며 모든 산업에서 같은 속도로 진행되지는 않을 것이다.

맞춤 구축·운영의 지속

고객별 시스템과 정책의 차이가 크고 그 차이를 해결할 경제적 가치가 충분하면 맞춤 개발은 계속 필요할 수 있다. 이런 조직은 구축과 유지보수에 맞는 계약, 가격과 인력을 갖춰야 한다. 고객 수가 늘 때 관리할 업무도 늘어나는 구조를 받아들이는 사업이다.

공통화가 어렵다는 이유만으로 실패라고 볼 수는 없다. 문제는 실제로는 고객별 구축·운영을 하고 있으면서 제품 사업처럼 적은 추가 비용으로 성장할 것이라고 기대하는 경우다. 지원 부담이 매출보다 빠르게 늘고 이를 조정할 수 없다면 사업 범위를 줄이거나 운영 방식을 바꿔야 한다.

이 세 방향은 한 조직 안에서도 함께 나타날 수 있다. 표준 도입은 자동화하고, 어려운 업무에는 전문가를 배치하며, 일부 고객에게는 별도 운영 계약을 제공할 수 있다. 어느 방향이 적합한지는 실제 고객별 차이와 비용 구조에 달려 있다.

핵심 요약

FDE는 고객의 요구가 불분명하고 제품만으로 해결하기 어려운 문제에 유용하다. 고객의 업무를 이해하면서 구현을 바꿀 수 있지만, 숙련 인력에 대한 의존과 고객별 유지 비용이 따른다. 기술의 한계나 고객 조직의 결정 부재까지 개발자가 해결할 수는 없다.

현재 AI FDE 업무의 일부는 제품이 성숙하면서 줄어들 수 있다. 반복 작업은 공통 기능으로 흡수되고, 남는 업무는 산업별 전문화나 구현·운영의 분업으로 이어질 가능성이 있다. 다만 새로운 적용 분야가 생길 수 있으므로 특정 업무의 감소를 직무 전체의 소멸로 보기는 어렵다.

FDE가 맡았던 일을 고객과 제품이 얼마나 이어받을 수 있는지가 중요하다. 고객이 일상적인 운영을 직접 처리하고, 반복되는 기능이 제품에 반영되면 개발팀은 다음 고객의 새로운 문제에 집중할 수 있다. 기존 고객의 작은 변경까지 계속 원래 개발자가 처리해야 한다면 고객이 늘수록 지원 업무도 늘어난다. FDE 조직을 확대할 때는 신규 프로젝트를 맡을 인력뿐 아니라, 완료한 프로젝트의 운영을 이어갈 체계도 함께 마련해야 한다.