AI를 잘 아는 개발자보다, 고객의 현장에서 끝까지 배포하는 개발자를 찾는 이유

OpenAI가 서울에서 채용하는 **Forward Deployed Engineer(FDE)**의 업무 설명을 읽으면, 채용하려는 사람이 어떤 모델을 가장 많이 알고 있는지보다 그 모델로 고객의 실제 업무를 작동하게 할 수 있는지를 묻고 있다는 점이 먼저 눈에 들어온다. 기술 탐색에서 아키텍처, 개발, 프로덕션 배포까지 책임지고, 고객의 엔지니어와 현업 담당자 곁에서 일하며, 성공 여부를 실제 업무 영향과 사용률로 측정하도록 요구한다.[^1]

AI 모델이 코드까지 작성하는 시기에 왜 이런 역할이 중요해졌을까. 나는 모델 자체의 성능보다 연구 성과가 현장의 업무 성과로 전환되는 마지막 구간이 여전히 비싸기 때문이라고 본다. 고객마다 데이터 접근권한이 다르고, 실제 업무는 문서화되어 있지 않은 경우가 많으며, 시연에 성공한 시스템도 운영 중에는 예외와 장애를 만난다. 이 구간의 책임을 한 명 또는 작은 팀이 끝까지 가져가는 직무가 FDE다.

국내 개발자 채널 노마드코더가 FDE의 역할과 보수 수준을 소개한 영상은 이를 취업시장 변화로 읽었다.[^2] Nate B. Jones는 별도 영상에서 AI가 흔해질수록 취향, 주도성, 집중력, 임기응변, 끝까지 해내는 힘의 값이 커질 것이라고 주장한다.[^3] 전자는 실제 직무, 후자는 개인에게 필요한 판단과 행동을 말한다. 둘을 연결하면 어떤 엔지니어에게 일이 모일지에 관한 좀 더 구체적인 설명이 된다.

좋은 데모는 고객의 시스템을 건드리지 않아도 만들 수 있다

새로운 AI 도구를 평가할 때 첫 번째 시험은 대개 간단하다. 파일 몇 개를 읽히고 질문에 답하게 하거나, 고객 문의 예시를 넣어 응답을 생성한다. 그 결과가 충분히 그럴듯하면 다음 단계로 넘어가고 싶어진다. 개발환경에서는 이 정도만으로도 기술 가능성을 확인할 수 있다.

그러나 직원이 매일 쓰는 도구가 되려면 다른 질문이 시작된다. 고객 데이터는 어디에 있는가. 어떤 부서는 어떤 기록을 조회할 수 있는가. 응답이 틀리면 누가 바로잡는가. 거래를 승인하는 버튼을 누를 권한은 누구에게 있는가. 장애가 나면 서비스를 되돌릴 수 있는가. 신규 시스템이 기존 업무 시간을 실제로 줄였는가.

이 문제는 모델 하나를 바꿔서 해결되지 않는다. 인증·권한·데이터 흐름·도구 호출·관측성·운영 대응을 모두 요구하기 때문이다. 그래서 FDE의 역량은 프롬프트 작성과 별개로 백엔드, 프런트엔드, 데이터 통합, 보안, 품질 검증에 걸쳐 있다. OpenAI의 금융서비스 FDE 채용 공고는 정확성, 지연시간, 설명 가능성, 통제, 감사 가능성, 운영 탄력성을 명시하고 있으며, 실제 서비스 배포에서 데이터 흐름과 on-call 준비까지 다룬다고 적고 있다.[^4]

여기서 오해하기 쉬운 부분이 있다. FDE는 고객사의 IT 문제를 무엇이든 대신 처리하는 외주 개발자와 동의어가 아니다. 고객 현장에서 검증된 문제를 제품과 플랫폼이 반복적으로 해결할 수 있는 방식으로 환원하는 것도 역할에 포함된다. 한 번의 맞춤형 구축으로 끝난다면 회사는 프로젝트를 하나 완료했을 뿐이다. 그 구축 경험이 공통 패턴, 안전장치, 평가 데이터로 돌아가야 다음 고객에서 한계비용을 낮출 수 있다.

현장 엔지니어가 만드는 것은 코드보다 ‘문제의 정확한 범위’일 때가 있다

예를 들어 한 영업팀이 “AI로 위험한 계약을 자동으로 찾아 달라”고 요청했다고 하자. 처음에는 CRM에서 14일간 활동이 없는 거래를 추출하면 될 것처럼 보인다. Nate B. Jones가 소개한 예시에서도 이런 첫 시도가 등장한다. 그런데 실제 현업이 보고 싶은 대상은 모든 비활성 거래가 아니라, 다음 단계가 정해지지 않은 채 법무 검토에 10일 이상 머문 계약이었다.[^3]

첫 프로토타입이 완벽하지 않았기 때문에 요구사항을 더 정확하게 설명할 수 있었다. 이 경우 개발자가 해야 할 일은 새로운 알림 규칙을 한 줄 만드는 것이 아니다. ‘위험’이라는 말을 현업이 실제로 취하는 행동과 연결해야 한다. 담당자가 어떤 계약에 개입할지, 알림이 너무 많아지면 무엇을 제외할지, 관측 지표가 바뀌어도 정책을 유지할지 함께 정해야 한다.

이 과정에서는 기획과 코딩의 경계가 약해진다. 개발자는 필요한 데이터를 확인하면서 업무를 배운다. 현업 담당자는 작동하는 화면을 보면서 자신이 정말 원하던 신호를 정의한다. 제품의 정확한 요구조건이 초기 요청서가 아니라 사용자가 반응한 첫 번째 배포물에서 드러나는 셈이다.

AI가 코드를 더 빨리 작성하게 되면 이런 탐색의 빈도는 높아질 수 있다. 코드 작성 시간이 줄었는데도 일이 끝나지 않는 이유가 분명해진다. 무엇을 구현할지, 무엇을 자동화하면 위험한지, 어떤 결과면 충분한지에 대한 합의가 뒤에 남기 때문이다.

기업이 돈을 내는 기준은 개발자의 시간보다 ‘사용 가능한 시스템’이다

FDE를 소개하는 영상에서 가장 눈에 띄는 부분은 연봉이다. 노마드코더는 미국 AI 기업의 일부 고액 연봉 공고를 소개한다.[^2] 다만 이 숫자를 FDE의 평균 연봉처럼 가져오는 것은 부정확하다. 같은 직무명이라도 지역, 기본급·성과급·지분 보상 포함 여부, 경력 수준, 기업별 역할이 다르다. 채용 공고에 나온 상단 금액은 전체 직종의 임금 분포를 보여주지 않는다.

직무의 경제적 가치를 이해하는 데는 채용 공고의 평가 기준이 더 유용하다. OpenAI의 서울 공고는 프로젝트의 성공을 production adoption, 측정 가능한 workflow impact, 평가를 통한 피드백으로 본다.[^1] 코드 몇 줄을 썼는지나 몇 개의 챗봇을 만들어 봤는지는 이 세 항목을 대신하지 못한다.

따라서 실제 계약에서도 가격을 매기는 단위가 달라질 수 있다. 가령 고객지원 문의 분류 시스템을 만든다면, 개발에 투입한 시간만큼 비용을 청구하는 방식도 가능하다. 하지만 고객이 장기적으로 확인하고 싶은 것은 정확한 분류 비율, 사람이 다시 읽어야 하는 건수, 응답 지연, 잘못 전달된 문의의 복구 비용이다. 프로토타입 제작비는 이 가치를 전달하기 위한 투자로 볼 수 있다.

기업이 외부 AI 구축 파트너를 고를 때도 같은 기준이 적용된다. 공급자가 1주일 안에 데모를 보여 줄 수 있다는 설명보다, 6주 뒤 장애가 발생했을 때 누가 로그를 보고 어느 범위까지 복구할 수 있는지 설명하는 편이 실질적인 신뢰를 만든다. '만들었습니다'라는 완료 선언을 운영 증거가 대체하는 구조다.

AI가 더 똑똑해져도 FDE 수요가 계속 증가한다고 단정할 수는 없다

이 직무가 최근 주목받는다고 해서 안정적인 성장 경로가 보장되는 것은 아니다. 고객이 스스로 인증·데이터·워크플로를 연결할 수 있게 하는 제품이 좋아지면 오늘 FDE가 수작업으로 처리하는 통합 업무 상당 부분이 제품 안으로 들어갈 수 있다. 더 정교한 에이전트가 자동으로 테스트·관측·배포까지 수행하면 현장 엔지니어 한 명이 담당할 수 있는 고객 수가 늘어날 가능성도 있다.

반대로 금융·의료·공공 부문처럼 책임소재와 데이터 통제가 중요한 환경에서는 고객별 정책이 쉽사리 표준화되지 않을 수 있다. 이 경우 현장의 기술적 판단을 제공하는 사람이 계속 필요할 것이다. 실제 수요는 모델 성능뿐 아니라 표준 제품이 고객별 예외를 얼마나 흡수하는지에 달려 있다.

여기에는 노동시장과 관련된 다른 위험도 있다. AI가 기존 개발자의 일 일부를 대체하면서 소수의 현장 엔지니어만 높은 보수를 받는 구조라면, FDE의 채용 확대가 일반 개발자의 처우 개선으로 이어지지 않을 수 있다. 한 직종의 고액 공고와 개발자 시장 전반의 변화는 분리해 봐야 한다.

Nate B. Jones가 제시한 다섯 역량 역시 예외가 아니다. 주도성이나 임기응변이 중요하다는 주장은 납득할 수 있지만, 이 능력을 갖추면 누구나 좋은 일자리를 얻는다는 뜻은 아니다. 산업별 채용 여건, 경험을 쌓을 기회, 기업의 교육 투자 같은 구조적 조건은 여전히 중요하다.[^3]

지금 준비할 수 있는 경력은 직함보다 ‘책임의 범위’에 가깝다

FDE라는 이름이 붙은 자리에 취업하지 않더라도 비슷한 역량은 검증할 수 있다. 내부 업무 하나를 선택해 기존 수작업의 양을 측정하고, 제한된 데이터와 권한으로 실행 가능한 첫 버전을 만든 다음, 실제 사용자가 어떤 예외를 겪는지 확인한다. 배포 후에는 로그와 실패 사례를 모아 수정하고, 변경 전후의 수치를 비교한다. 더 좋은 결과가 나오면 그 과정을 문서화해 다른 팀이 재사용할 수 있게 한다.

이 경력에서 중요한 산출물은 기술 스택 목록보다 사례의 연속성이다. 문제를 누가 제기했는지, 처음 가정이 무엇이었는지, 실제로 어떤 실패가 있었는지, 어떤 이유로 우선순위를 바꿨는지, 최종적으로 누가 무엇을 더 잘하게 됐는지가 이어져 있어야 한다. 모델 API 사용 경험만큼이나 시스템을 끝까지 맡아본 증거가 된다.

AI가 코드를 대신 작성하는 범위는 앞으로도 넓어질 가능성이 크다. 그럴수록 개발자가 시장에서 평가받는 한 단위는 코드 작성량이 아니라, 모호한 고객 문제를 실제로 운영되는 시스템으로 바꾼 기록이 될 것이다. FDE는 그 변화가 드러나는 한 직무다. 모두가 FDE가 될 필요는 없지만, AI를 제품으로 만든다는 말의 기준은 그쪽으로 움직이고 있다.

자료

[^1]: OpenAI, Forward Deployed Engineer – Seoul. 실제 서울 채용 공고. 확인일 2026-10-12. [^2]: 노마드코더, 「연봉 5억을 주고 뽑는 개발자는 뭘 할까?」. 2026-10-12 확보한 원문 요약을 검토. 연봉·채용 건수는 영상의 설명이며 직종 전체 통계로 사용하지 않음. [^3]: Nate B. Jones, The AI Paradox: 5 Human Skills That Are More Valuable. 2026-10-12 확인한 원문 요약을 검토. 2027년 전망은 발표자의 견해. [^4]: OpenAI, Forward Deployed Engineer (FDE), Financial Services – NYC. 실제 배포의 품질·보안·감사·업무 성과 관련 직무 명세. 확인일 2026-10-12.