How Forward Deployed Engineering is done at Ramp — Leo Mehr

URL: https://www.youtube.com/watch?v=ITMXwI6QL6A 날짜: 2026-07-29 채널: aiDotEngineer

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

Ramp에서 Forward Deployed Engineering(FDE) 조직을 2.5년간 이끌며 배운 것은 ==단 두 가지 원칙, "항상 스코핑하라(Always Be Scoping)"와 "토큰으로 스케일하라(Scale with Tokens)"만 지키면 된다==는 것이다.

• FDE는 흔히 밈으로 소비되는 "기술 영업의 최종 진화형/보스 몹" 같은 이미지와 달리, Ramp에서는 엔지니어링 조직 내부에 속해 엔터프라이즈 고객을 위해 코어 제품과 신규 에이전틱 기능을 잘 작동시키는 역할이다
• 고객의 모든 요청에 "예"라고 답하는 것은 FDE의 일이 아니며, 오히려 근본 원인과 맥락을 파고들어 "옳은 것을 만드는 것"이 FDE의 본질이다
• 스코핑을 아무리 잘해도 모델·에이전트로 업무 자체를 스케일하지 않으면 결국 뒤처지며, 반대로 스케일링만 잘하고 스코핑을 소홀히 하면 "토큰 맥싱 슬롭 캐논(token maxing slop cannon)"이 된다

발표자 리오 메르(Leo Mehr)는 Ramp의 Director of Engineering으로, 2.5년 전 FDE 엔지니어가 단 2명이던 시절 합류해 현재는 배포형 개발자 API, 신규 AI 서비스 사업을 포함해 약 30명 규모의 조직을 이끌고 있다. 이 발표는 그 기간 동안 얻은 교훈을 스코핑과 에이전트 스케일링이라는 두 축으로 압축해 전달한다.

---

1. FDE란 무엇인가 (Ramp의 맥락)

Ramp의 FDE는 흔히 알려진 "기술 영업의 최종 보스" 이미지와 다르며, 엔지니어링 조직에 속해 엔터프라이즈 시장 확대를 돕는 역할이다.

1.1. FDE에 대한 통념과 Ramp의 실제 정의

1. 밈으로 소비되는 FDE 이미지

   1. "최종 진화형" 밈: 발표자는 FDE를 기술 중심 고객대응(go-to-market) 역할의 "최종 진화형" 혹은 "보스 몹"으로 묘사하는 밈을 언급하며, 재미있지만 완전히 틀렸다고 지적한다
   2. 회사마다 다른 정의: 이런 이미지가 맞는 회사도 있을 수 있지만, 적어도 Ramp에서는 다르다고 명시한다

2. Ramp에서 FDE의 실제 위치와 목표

   1. 엔지니어링 조직 소속: Ramp의 FDE는 영업 조직이 아니라 엔지니어링 조직 내부에 존재한다
   2. 목표는 업마켓 승리: FDE의 목표는 Ramp가 업마켓(대형 엔터프라이즈 시장)에서 승리하도록 돕는 것이며, 이를 위해 코어 제품과 신규 에이전틱 기능을 가장 큰 엔터프라이즈 고객에게 잘 맞도록 만드는 작업을 한다

1.2. Ramp FDE 조직의 현황

1. 조직 성장
   1. 초기 2명에서 30명으로: 발표자가 2.5년 전 합류했을 당시 FDE는 단 2명의 엔지니어였으나, 현재는 약 30명 규모로 성장했다
   2. 사업 범위 확장: 현재 조직은 배포형(deployed) 개발자 API와 신규 AI 서비스 사업 등 네 개 영역을 아우른다

---

2. 원칙 1: Always Be Scoping (항상 스코핑하라)

FDE의 일은 고객 요청에 무조건 "예"라고 답하는 것이 아니라, 맥락을 파악해 실제로 만들어야 할 옳은 것을 찾아내는 것이다.

2.1. "예"라고만 답하는 것의 함정

1. 잘못된 통념

   1. "FDE = 고객에게 Yes"라는 오해: 많은 사람이 FDE의 역할을 그저 고객에게 "예"라고 말하는 것으로 오해한다고 지적한다
   2. 결과물의 품질 저하 비유: 이렇게 무조건 "예"만 하면, 샌프란시스코를 돌아다니는 아름다운 웨이모(Waymo) 자율주행차 대신 "다리에 로켓을 매단 말" 같은 조악한 결과물이 나온다는 비유로 설명한다

2. FDE의 실제 역할

   1. 성공을 돕되 좋은 소프트웨어를 전달: 고객이 성공하도록 "예"라고 말할 방법을 찾으려 노력하되, 동시에 실제로 좋은 소프트웨어를 만들어야 한다는 점을 강조한다
   2. 옳은 것을 만드는 것이 핵심: 요청을 무한정 수용하는 것이 아니라, "옳은 것을 만드는 것(build the right thing)"이 FDE의 본질이라고 정의한다

2.2. 사례: 금요일 밤의 긴급 SAP 통합 요청

1. 상황 설정

   1. 금요일 밤 긴급 요청: 엔터프라이즈 영업 담당자가 "이 중요한 전략 고객(logo)은 SAP S/4HANA 통합을 만들어야만 계약이 성사된다"며 긴급 요청을 가져온다
   2. 엔지니어의 기본 반사반응: 기본적인 엔지니어링 반사 반응은 "SAP API 문서가 어디 있지? 어떻게 이 통합을 만들지?"처럼 곧바로 구현에 뛰어드는 것이다

2. 훈련된 FDE의 대응

   1. 잠시 멈추고 긴급성의 원인 질문: 잘 훈련된 FDE는 잠시 멈추고 "이 긴급함을 실제로 유발하는 게 무엇인가?"를 먼저 묻는다
   2. 영업 담당자의 분기말 압박 사례: 실제로 고객이 아니라 분기 말 실적 압박 때문에 영업 담당자가 다급해하는 경우를 여러 번 목격했다고 밝힌다
   3. 맥락을 파악하는 질문들: "누가 이 통합을 쓰는가?", "다른 대안을 다 시도해봤는가?", "임시로 할 수 있는 수동 처리 방법이 있는가?", "고객사에 기술 리소스가 있어 우리 API를 직접 호출할 수 있는가?" 등을 질문한다
   4. 파이프라인 전체를 고려: FDE가 하는 가장 중요한 일은 이 한 건의 요청을 넘어, 파이프라인에 있는 다른 잠재고객이나 기존 고객도 같은 기능의 수혜를 받을지 살펴보는 것이라고 강조한다

2.3. 사례: 모바일 상환(Reimbursement) 기능 참사

1. 배경과 대응

   1. 모바일팀 여력 부족: 대형 엔터프라이즈 고객이 모바일에서 상환 기능을 요구했지만, 모바일팀이 이미 과부하 상태였다
   2. FDE가 iOS/Android 직접 학습: FDE 엔지니어 2명이 직접 iOS·Android 개발을 배워서 몇 주간 매달려 두 플랫폼 모두에서 기능을 완성했다

2. 뒤늦게 드러난 전제 오류

   1. 베타 사용자 요청 시점의 반전: 완성 후 고객에게 "Android 베타 사용자 목록을 보내달라"고 요청하자, 고객사는 전 직원에게 iOS 기기만 사용하도록 의무화하고 있다고 답한다
   2. 가장 기본적인 가정도 검증해야 한다는 교훈: 이 사례는 "어떤 모바일 플랫폼을 대상으로 만들 것인가" 같은 가장 기본적인 가정조차 사전에 검증하는 것이 얼마나 중요한지 보여주는 뼈아픈 교훈이었다고 밝힌다

---

3. 원칙 2: Scale with Tokens (토큰으로 스케일하라)

스코핑을 아무리 잘해도 그 자체만으로는 부족하며, FDE 업무 파이프라인의 각 단계를 모델과 에이전트로 대체해 나가야 한다.

3.1. 스코핑만으로는 충분하지 않은 이유

1. 모델 역량과 함께 스케일해야 한다
   1. 뒤처지는 리스크: 팀이 스코핑의 달인이 되었다 해도, 모델 역량과 함께 스케일하지 않으면 결국 뒤처지게 된다고 경고한다
   2. 지식노동의 재발명 필요성: 현재 하고 있는 일 대부분이 지식노동인 만큼, 이를 모델과 에이전트가 대신 수행하도록 끊임없이 업무 방식 자체를 재발명해야 한다고 말한다

3.2. FDE 파이프라인을 에이전트로 대체하기

1. 파이프라인 전 단계 분해
   1. 4단계 구조: FDE 업무를 맥락 수집(gathering context) → 요청 스코핑 → 스펙 작성 → 기능 구현의 파이프라인으로 나눈다
   2. 각 단계를 에이전트로 교체 가능: 처음에는 막막해 보이지만, 문제를 잘게 쪼개면 실제로는 충분히 다룰 수 있는(tractable) 문제라고 설명한다

3.3. 사례: FDE Requests Slack 채널과 Notion 에이전트

1. 기존 프로세스의 문제

   1. FDE Requests 채널: 어카운트 매니저, 솔루션 엔지니어, 영업 담당자가 대형 고객·잠재고객의 블로커를 올리는 내부 슬랙 채널이 있으며, Notion 워크플로우로 연결돼 있다
   2. 요청 품질의 높은 편차: 어떤 요청은 매우 상세하지만, 어떤 요청은 "SAP 통합이 필요하다" 같은 한 줄짜리인 경우도 있다
   3. 기존 수작업 프로세스: 과거에는 FDE가 요청 전문을 읽고 이해하고, 제품에 이미 존재하는 기능을 파악하고, 고객과 여러 차례 주고받으며 무엇이 실제로 꼭 필요한지 직접 검증했다

2. Notion 에이전트 V1과 개선

   1. V1: 단순 질문 자동화: 첫 버전은 요청을 받아 몇 가지 질문을 하는 정도로 단순했지만, 몇 주 만에 응답 지연 시간을 시간·일 단위에서 초 단위로 줄여 놀라운 시간 절감 효과를 보였다
   2. 어카운트 매니저들의 자발적 채택: 어카운트 매니저·영업 담당자들이 자연스럽게 이 에이전트와 상호작용하기 시작했다
   3. 최신 버전: 펭귄 캐릭터와 다회차 질의응답: 현재 버전은 친근함을 위해 귀여운 펭귄 캐릭터를 사용하며, 스펙을 작성할 준비가 됐다고 판단할 때까지 요청자와 여러 차례 왕복 질의응답을 수행한다
   4. 시간 절감 효과: 이 시스템이 요청 스코핑에 들이던 시간의 약 20%를 절감해준 것으로 추정한다

3.4. 앞으로 6~12개월: FDE의 미래

1. 남은 과제와 집중 영역

   1. 파이프라인의 어려운 중간 단계: 스펙 작성(첫 단계)과 완성된 스펙으로부터 기능을 구현하는 것(마지막 단계, 프런티어 모델이 중간 규모 기능을 원샷으로 처리 가능)은 상대적으로 쉬워졌지만, 그 중간 단계가 가장 다루기 어렵고 정형화되지 않은 부분이라고 짚는다
   2. 에이전트 하네스 안정성: 각 단계를 실행하는 에이전트 하네스가 매끄럽게 작동하는지 확인하는 것이 중요한 응용 AI 문제가 될 것이다
   3. 출력 품질 관리: 평가(evals), 루브릭, 사람의 피드백을 통해 파이프라인 각 단계 출력의 품질을 보장해야 한다

2. 가장 큰 도전: 에이전트에게 올바른 맥락 제공

   1. 암묵지 이전의 어려움: 프로덕트 매니저 머릿속에 있는 제품에 대한 방대한 지식을 어떻게 에이전트에게 전달할 것인가가 핵심 난제라고 말한다
   2. Notion 문서만으로는 부족: Notion 문서, 기존 지식베이스, 헬프 문서만으로는 그 지식의 일부만 전달할 수 있다고 지적하며, 스킬·메모리·툴 등을 언급한다
   3. FDE의 최종 책임: 안목과 판단: 이 모든 자동화에도 불구하고, 최종 결과물에 대한 안목과 판단(taste and judgment)에 대한 책임은 여전히 FDE에게 있다고 강조한다

---

4. 두 원칙의 결합이 만드는 성공

스코핑과 에이전트 스케일링, 둘 중 하나만으로는 충분하지 않으며 반드시 함께 가야 한다.

4.1. 스코핑 없는 스케일링의 위험: "토큰 맥싱 슬롭 캐논"

1. 한쪽만 잘하면 실패한다

   1. 스케일링만 잘하고 스코핑을 소홀히 한 경우: 요청 스코핑을 제대로 하지 않은 채 에이전트 팩토리만 구축하면, "토큰 맥싱 슬롭 캐논(token maxing slop cannon)", 즉 토큰만 잔뜩 소모하며 품질 낮은 결과물을 쏟아내는 상태가 된다고 경고한다
   2. 스코핑만 잘하고 스케일링을 소홀히 한 경우: 반대로 스코핑은 뛰어나지만 에이전트 팩토리 구축에 투자하지 않으면, 에이전트 네이티브 경쟁사에게 추월당하고 만다고 말한다

2. 결론: 두 원칙 모두 필요

   1. 상호 보완적 관계: 두 원칙(항상 스코핑하라 + 토큰으로 스케일하라)을 모두 갖춰야 미래에 성공할 수 있는 기반이 마련된다고 마무리한다

---

주요 발언 모음

"I don't see it as like the final evolution or like boss mode of technical go-to-market roles... FDE at Ramp, uh we live within the engineering organization. And our goal is to help Ramp win upmarket."

"People think that as an FDE, your job is to just say yes to the customer. But that's wrong... You want to try to figure out a way to say yes. But you actually want to deliver good software. You need to build the right thing."

"Unless you are scaling with model capabilities, you are going to fall behind."

"If you don't do a good job of scoping out requests... you're going to get a token maxing slop cannon."

"Always be scoping and scaling with tokens. The future of FDE needs both."

핵심 데이터 & 수치

• 조직 규모 성장: FDE 엔지니어 2명(2.5년 전) → 약 30명(현재), 배포형 개발자 API + 신규 AI 서비스 사업 등 4개 영역 담당
• 응답 지연 시간 단축: Notion 에이전트 V1 도입 후, 어카운트 매니저 요청에 대한 응답 지연이 시간·일 단위에서 초 단위로 단축
• 스코핑 시간 절감: 최신 Notion 에이전트가 요청 스코핑에 드는 시간의 약 20%를 절감한 것으로 추정

결론 및 시사점

1. FDE(혹은 이와 유사한 기술 중심 go-to-market 역할)는 무조건적인 "예스맨"이 아니라, 근본 원인과 진짜 우선순위를 파고들어 옳은 것을 만드는 역할로 재정의돼야 한다.
2. 긴급해 보이는 요청일수록 "누가, 왜 이 긴급함을 만들었는가"를 먼저 검증하고, 파이프라인에 있는 다른 고객에게도 같은 니즈가 있는지 살펴보는 습관이 자원 낭비를 막는다.
3. 가장 기본적인 전제(예: 어떤 플랫폼을 대상으로 만들 것인가)조차 사전에 검증하지 않으면, 완성 후에 뒤늦게 헛수고였음을 깨닫는 참사가 벌어질 수 있다.
4. 모델·에이전트 역량이 발전하는 시대에는 자신의 업무 파이프라인을 단계별로 분해하고, 각 단계를 에이전트로 대체할 수 있는지 끊임없이 재발명해야 한다.
5. 에이전트 자동화의 가장 어려운 지점은 구현이 아니라 "올바른 맥락을 에이전트에게 전달하는 것"이며, 이는 조직의 암묵지를 어떻게 명시화하느냐의 문제다.
6. 스코핑 역량과 에이전트 스케일링 역량은 상호 보완적이며, 어느 한쪽만 갖추면 각각 "슬롭 생산 기계"가 되거나 "경쟁사에 추월당하는 조직"이 된다.