포워드 배포 엔지니어(FDE)의 두 가지 원칙: 끝까지 좁히는 스코핑과 토큰으로 확장하기

핵심 메시지

• 포워드 배포 엔지니어(FDE)의 일은 고객 요청에 무조건 예스를 하는 것이 아니라, 무엇을 만들어야 하는지 끝까지 좁히는 것이다.
• 요청이 급한 이유가 고객이 아니라 분기 실적을 쫓는 영업 쪽 사정일 수 있어, 배경을 묻는 질문이 먼저다.
• 가장 기본적인 가정도 검증하지 않으면 몇 주치 개발이 통째로 버려질 수 있다.
• 맥락 수집부터 스코핑, 스펙 작성, 구현까지 각 단계를 에이전트로 대체하는 것이 앞으로의 핵심 과제다.
• 스코핑 없이 에이전트 공장만 지으면 쓸모없는 결과물을 빠르게 쏟아내는 기계가 될 뿐이다.

쉽게 이해하기

미국 핀테크 기업 램프(Ramp)에서 엔지니어링 디렉터로 일하는 리오 메어가 AI 엔지니어 콘퍼런스에서 자사의 '포워드 배포 엔지니어(FDE)' 운영 경험을 공유했다. 그가 2년 반 전 합류했을 때 FDE는 두 명뿐이었지만, 지금은 배포와 개발자 API, 새로 시작한 AI 서비스 등 네 개 영역에 걸쳐 약 30명 규모의 조직이 됐다.

그는 FDE를 '기술 영업 직군의 최종 진화형'으로 보는 흔한 이미지가 적어도 램프에서는 맞지 않는다고 말한다. 램프의 FDE는 영업 조직이 아니라 엔지니어링 조직 안에 있고, 핵심 제품과 새로 만든 에이전트 기능이 최대 규모 기업 고객에게서 제대로 작동하도록 만드는 일을 맡는다. 목표는 회사가 대기업 시장에서 이기도록 돕는 것이다.

발표의 첫 번째 원칙은 '항상 범위를 좁혀라'다. 그는 고객에게 무조건 예스만 하면 결과물이 다리에 로켓을 묶은 말처럼 된다고 비유했다. 예를 들어 금요일 밤에 영업 담당자가 'SAP 연동을 만들어야만 중요한 계약이 성사된다'며 달려오면, 훈련된 FDE는 API 문서를 찾기 전에 왜 급한지부터 묻는다. 실제로 고객이 아니라 분기 마감을 앞두고 실적을 채우려는 영업 담당자 쪽이 급한 경우도 있었다고 한다.

그는 초기에 겪은 뼈아픈 사례도 소개했다. 대형 고객이 모바일에서 쓸 환급 기능을 요구했는데 모바일 팀에 여력이 없어, FDE 두 명이 직접 iOS와 안드로이드 개발을 배워 몇 주를 갈아 넣어 양쪽 플랫폼에 기능을 냈다. 그런데 막상 그 고객사는 전 직원에게 iOS 기기 사용을 의무화하고 있었다. 어떤 모바일 플랫폼을 쓰는지 같은 가장 기본적인 가정조차 미리 확인해야 한다는 교훈이었다.

두 번째 원칙은 '토큰으로 확장하라'다. 모델 성능이 좋아지는 속도에 맞춰 일하는 방식을 계속 다시 발명하지 않으면 뒤처진다는 것이다. 램프는 사내 슬랙의 'FDE 요청' 채널로 들어오는 요청의 품질 편차가 크다는 문제를 에이전트로 풀었다. 처음에는 요청을 받아 질문 몇 개를 되묻는 수준이었지만, 답변까지 걸리던 시간이 몇 시간에서 며칠이던 것이 몇 초로 줄자 사내 이용이 늘었고, 지금은 여러 차례 되묻고 나서 스펙 초안을 만드는 단계까지 왔다.

주요 인사이트

• FDE의 질문은 '어떻게 만들까'가 아니라 '누가 쓰는가, 우회책은 다 써봤는가, 임시로 수동 처리할 수 있는가, 고객이 직접 API를 호출할 수는 없는가'에서 시작한다.
• 한 고객의 요청을 볼 때 뒤따라오는 다른 잠재 고객까지 함께 살피면, 일회성 대응이 아니라 제품이 될 기능을 골라낼 수 있다.
• 스코핑 자동화의 효과는 품질보다 속도에서 먼저 나타났다. 응답 지연이 몇 초로 줄자 사내 구성원들이 자발적으로 에이전트와 대화하기 시작했고, 발표자는 스코핑에 쓰던 시간의 20% 정도가 절감된 것으로 추정한다.
• 잘 정리된 스펙을 실제 코드로 옮기는 마지막 단계는 프런티어 모델이 중간 규모 기능을 한 번에 처리할 만큼 쉬워졌고, 오히려 스코핑과 구현 사이의 중간 구간이 가장 다루기 까다롭다.
• 제품 담당자의 머릿속에 있는 지식을 에이전트에 넣는 일이 가장 큰 과제다. 사내 문서와 도움말 문서만으로는 그 지식의 일부밖에 전달되지 않는다.

자주 묻는 질문

관련 AI 소식