How Forward Deployed Engineering is done at Ramp — Leo Mehr

한 줄 핵심

Ramp의 FDE는 고객 요청에 무조건 응답하는 역할이 아니라, 먼저 정확히 범위를 잡고 그 다음에는 에이전트와 모델로 업무 전 과정을 자동화·확장하는 방식으로 진화해야 한다는 점을 강조한다.

시간별 요약

1. 0:01
   Ramp의 FDE는 엔지니어링 조직 안에서 대기업 고객의 수요에 맞게 핵심 제품과 AI 기능을 조정하며, 특히 업마켓 성장을 돕는 역할로 정의된다. 이 경험에서 가장 중요한 원칙은 "Always be scoping"과 "Scale with tokens" 두 가지다.
2. 2:01
   FDE는 고객 요청에 단순히 예스라고 답하는 사람이 아니라, 무엇이 정말 필요한지 묻고 검증해 올바른 소프트웨어를 만드는 사람이다. 긴급한 요청일수록 실제 긴급성의 출처, 우회 수단, 고객의 기술 역량, 다른 고객에게도 유용한지까지 함께 확인해야 한다.
3. 5:00
   범위를 검증하지 않으면 큰 낭비가 생긴다. 모바일 환급 기능을 만들면서 iOS와 Android를 모두 구현했지만, 실제로는 고객이 iOS만 사용해 한쪽 플랫폼 작업이 불필요했던 사례가 이를 보여준다.
4. 7:00
   오늘날에는 범위 설정만 잘해서는 부족하고, 모델 능력에 맞춰 업무를 확장해야 한다. FDE가 하는 일은 컨텍스트 수집, 범위 조정, 명세 작성, 구현으로 이어지는 파이프라인이며, 이 각 단계를 에이전트로 대체하거나 보조할 수 있다.
5. 8:01
   Ramp는 Notion 기반의 FDE requests 흐름에 Notion agents를 붙여, 요청을 받아 추가 질문을 반복하고 명세 작성 준비까지 자동화했다. 그 결과 응답 지연이 시간·일 단위에서 초 단위로 줄었고, scoping에 드는 시간이 약 20% 절감되었다.
6. 11:01
   앞으로의 FDE는 agent harness 운영, 출력 품질 평가, 적절한 컨텍스트 주입, 메모리·도구 설계 같은 적용형 AI 문제에 더 많이 집중하게 된다. 다만 최종 산출물에 대한 taste와 judgment는 여전히 사람이 책임져야 하며, scoping과 token scaling이 함께 있어야 미래 경쟁력을 유지할 수 있다.

실무 인사이트

• 고객 요청을 받으면 즉시 구현에 들어가기보다, 긴급성의 진짜 원인과 대체 수단을 먼저 확인하는 질문 템플릿을 고정해 두면 불필요한 개발을 크게 줄일 수 있다.
• 요청 접수→질문 반복→명세 생성→구현의 각 단계를 분리해 에이전트로 자동화하면, FDE나 PM의 시간을 반복 업무보다 판단 업무에 더 많이 배분할 수 있다.
• 에이전트를 도입해도 최종 품질을 보장하는 것은 평가, 컨텍스트 설계, 사람의 감수이므로 자동화와 함께 검증 체계를 같이 설계해야 한다.