전방으로 배치된 엔지니어

요즘 누군가 무슨 일을 하느냐고 물으면 예전만큼 한마디로 답하기가 어렵습니다.

오랫동안 우리는 일을 잘게 나눠 왔습니다. 프론트엔드와 백엔드를 가르고, 기획과 디자인과 개발을 나눴습니다. 경계를 나눌수록 한 사람이 한 우물을 깊게 팔 수 있었기 때문입니다. 깊이는 분업의 보상이었습니다.

그런데 이제는 제가 깊게 파지 않은 우물의 물도 도구에게 길어오게 할 수 있습니다. 백엔드를 잘 모르는 사람이 서버 코드를 만들고, 디자인을 배우지 않은 사람이 제법 그럴듯한 화면을 그립니다. 한 사람이 감당할 수 있는 일의 폭이 빠르게 넓어지고 있습니다.

경계가 흐려지자 오히려 한 가지 질문이 또렷해졌습니다. 그렇다면 정말 값진 일은 어디에 있는가.

경계가 흐려진 뒤 남는 일

저부터가 그렇습니다. 프론트엔드를 본업으로 삼아 왔지만 요즘은 코틀린과 스프링 부트로 짜인 서버 코드를 고치고, 테이블 구조를 바꾸는 DDL을 쓰고, 쌓인 데이터를 메우는 백필(backfill) 전략을 고민합니다. 얼마 전까지만 해도 제 영역이라 여기지 않던 일들입니다.

도구 덕분에 낯선 코드도 고칠 수 있게 됐습니다. 하지만 DDL을 쓸 수 있다는 사실만으로 어느 테이블을 왜 바꿔야 하는지까지 알게 되지는 않습니다.

코드를 만드는 속도가 빨라진 뒤에도 어떤 문제를 고를지는 사람의 몫으로 남았습니다. 말끔한 요구사항을 구현하는 일보다 아직 엉켜 있는 문제를 요구사항으로 만드는 일이 더 오래 걸릴 때도 있습니다.

그 이동을 하나의 직무로 만든 자리가 전방 배치 엔지니어(Forward Deployed Engineer), FDE입니다.

문제가 있는 곳으로 먼저 간다

'전방 배치'라는 이름은 완성된 제품을 후방에서 보내는 대신, 일이 벌어지는 현장 가까이에 사람을 둔다는 뜻을 담고 있습니다. 이 역할을 소프트웨어 업계에 널리 알린 곳은 팔란티어(Palantir)입니다.

팔란티어는 엔지니어를 크게 두 갈래로 나눠 불렀습니다. 제품 자체를 만드는 쪽은 데브(Dev), 고객의 현장에 들어가 제품을 문제에 맞게 적용하는 쪽은 델타(Delta)였습니다. 팔란티어의 설명을 빌리면 데브가 '하나의 기능을 여러 고객에게' 제공한다면, 델타는 '한 고객을 위해 여러 기능을' 엮습니다. FDE는 후자에 가깝습니다.

FDE의 핵심은 고객이 말한 요구사항을 그대로 코드로 옮기는 데 있지 않습니다. 어려운 문제는 대개 말끔한 문서로 도착하지 않습니다. 현장에 들어가 사람들이 실제로 어떻게 일하는지 보고, 말로 정리되지 않은 제약과 목표를 함께 찾아야 합니다.

팔란티어에서 8년간 일한 Nabeel Qureshi는 고객사에 직접 들어가는 이유가 납작한 요구사항 목록만으로는 얻을 수 없는 암묵지를 포착하기 위해서였다고 회고합니다. 그는 첫 고객이었던 에어버스를 위해 툴루즈로 이주해 1년 동안 주 나흘을 공장 사람들 곁에서 일했습니다.

그렇다고 FDE가 기술을 곁들인 영업인 것은 아닙니다. 1,000여 개의 채용 공고를 분석한 자료에서는 고객과 직접 일하는 것이 가장 자주 등장하는 책임이었지만, 매출 할당량은 핵심 업무로 한 번도 언급되지 않았습니다. 이들은 데모를 보여주고 떠나는 대신 실제 시스템을 만들고 배포하며, 현장에서 얻은 지식을 다시 제품으로 가져갑니다.

코드는 그 일을 위한 중요한 수단이지만, 일의 출발점은 코드가 아닙니다.

AI 회사들이 다시 현장으로 가는 이유

FDE라는 역할은 AI 회사들에서 다시 빠르게 커지고 있습니다. 모델이 좋아지는 것만으로는 기업의 일이 바뀌지 않기 때문입니다. 모델을 고객의 데이터와 도구, 통제 장치, 업무 흐름에 연결하고 사람들이 실제로 쓰게 만드는 마지막 구간이 남아 있습니다.

2026년 OpenAI는 40억 달러 이상의 초기 투자로 OpenAI Deployment Company를 출범시켰습니다. 응용 AI 기업 Tomoro를 인수해 약 150명의 FDE와 배포 전문가도 확보하기로 했습니다. 같은 해 Anthropic도 투자사들과 기업용 AI 서비스 회사를 설립하고, 응용 AI 엔지니어가 고객의 업무를 이해해 맞춤 시스템을 만드는 방식을 내세웠습니다.

두 회사가 설명하는 일은 닮아 있습니다. 고객 가까이 들어가 가치가 생길 문제를 고르고, 현장의 지식을 시스템에 옮기고, 프로덕션에서 실제로 작동하게 만드는 것입니다. 뛰어난 모델과 현실의 업무 사이에는 여전히 사람이 건너야 할 거리가 있다는 뜻입니다.

물론 모든 회사가 FDE 조직을 만든다고 팔란티어가 되는 것은 아닙니다. a16z도 FDE 모델을 무작정 따라 하면 재사용 가능한 제품 없이 맞춤 프로젝트만 쌓이는 '서비스의 함정'에 빠질 수 있다고 지적합니다. 현장 대응이 연구개발이 되려면 한 고객에게서 배운 것을 제품의 공통 자산으로 되돌리는 구조가 함께 있어야 합니다.

FDE라는 이름보다 현장에서 배운 것이 제품으로 돌아오는 구조가 더 오래 남습니다.

기술 목록 다음에 남는 일

FDE 채용 공고에 등장하는 기술 목록은 의외로 평범합니다. 파이썬과 클라우드, LLM과 에이전트 경험이 자주 보입니다. 차이는 현장의 모호한 말을 요구사항으로 정리하고, 배포 뒤에 생긴 문제까지 자기 일로 받아들이는 데서 생깁니다.

도구의 도움으로 서버 코드를 고치고 DDL까지 쓸 수 있었지만, 테이블에 어떤 값을 추가해야 하는지는 코드만 보고 정할 수 없었습니다. 그 값이 사용자의 일을 어떻게 바꾸는지 알아야 했습니다. FDE가 흥미로운 이유도 기술 목록보다 이 판단을 일의 한가운데에 두기 때문입니다.

모두가 당장 FDE라는 직함을 달 필요는 없습니다. 다만 깔끔한 요구사항이 책상에 도착하기를 기다리기보다 문제가 아직 엉켜 있는 곳으로 먼저 걸어 들어가는 태도는 어느 팀에서든 필요합니다.

저도 아직 그 일을 잘한다고 말할 수는 없습니다. 요즘은 코드를 쓰기 전에 누구의 어떤 문제가 아직 정리되지 않았는지부터 조금 더 오래 보려고 합니다.