How Forward Deployed Engineering is done at Ramp — Leo Mehr
📺 원본 영상: How Forward Deployed Engineering is done at Ramp — Leo Mehr
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-29
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 강연에서 Ramp의 Director of Engineering인 Leo Mehr는 Forward Deployed Engineering(FDE)을 단순한 고객 대응 조직이 아니라, 엔터프라이즈 고객의 요구를 제품과 AI 워크플로로 번역하는 엔지니어링 기능으로 설명한다. 그는 Ramp에서 FDE 조직이 두 명의 엔지니어로 시작해 약 30명 규모의 조직으로 성장했으며, 그 과정에서 가장 중요했던 원칙을 “Always be scoping”과 “Scale with tokens”라는 두 문장으로 압축한다.
강연의 핵심은 FDE가 고객 요청을 그대로 받아 적는 역할이 아니라는 데 있다. FDE는 고객이 말한 기능을 곧장 구현하기보다, 그 요청이 왜 필요한지, 어떤 고객군에 반복될 수 있는지, 임시 우회책은 없는지, 그리고 AI 에이전트가 어느 단계까지 대체할 수 있는지를 판단해야 한다. 이 관점에서 FDE는 전통적인 솔루션 엔지니어링과 제품 엔지니어링의 중간에 있는 조직이 아니라, AI 시대에 제품 개발 프로세스 자체를 재설계하는 실험장이 된다.
Ramp가 정의하는 FDE는 무엇인가
Leo Mehr는 먼저 FDE라는 개념이 업계에서 여전히 명확히 정의되지 않았다는 점을 짚는다. 많은 사람이 FDE를 기술 영업(technical go-to-market) 역할의 최종 진화형처럼 이해하지만, 그는 Ramp의 FDE가 그런 방식으로 작동하지 않는다고 설명한다.
01:12 - 강연자가 FDE를 기술 go-to-market 역할의 최종 진화형처럼 보는 밈을 언급하며, Ramp의 FDE 정의와 다르다고 설명하는 장면
Ramp에서 FDE는 영업 조직 바깥에 별도로 존재하는 고객 대응팀이 아니라, 엔지니어링 조직 내부에 속해 있으며, 핵심 목표는 Ramp가 더 큰 엔터프라이즈 고객을 확보하고 유지할 수 있도록 제품을 발전시키는 것이다.
이 정의는 중요하다. FDE가 엔지니어링 조직 안에 있다는 것은 고객의 요구를 단기 커스터마이징으로 처리하는 대신, 제품의 핵심 기능과 연결해 판단한다는 뜻이기 때문이다. 강연자에 따르면 Ramp의 FDE는 코어 제품, 새로운 agentic features, API, AI services business와 맞물려 움직인다. 따라서 이들이 다루는 문제는 단순히 “고객이 원하는 기능을 만들어주는 일”이 아니라, 대형 고객에게 필요한 기능을 제품화 가능한 형태로 재구성하는 일에 가깝다.
여기서 “upmarket”이라는 표현도 핵심적이다. Ramp가 더 큰 기업 고객을 상대할수록, 고객 요구는 더 복잡해지고 기존 제품의 경계 밖으로 밀려나기 쉽다. 이때 FDE는 고객의 특수성을 이해하면서도, 그 특수성이 다른 대형 고객에게도 반복될 수 있는지 판단해야 한다. 결국 Ramp식 FDE는 고객 현장에서 나온 압력을 제품 로드맵과 엔지니어링 판단으로 전환하는 역할을 맡는다.
첫 번째 원칙: Always Be Scoping
강연자가 제시한 첫 번째 원칙은 “Always be scoping”이다. 표면적으로 보면 FDE는 고객 요청에 빠르게 대응해야 하는 조직처럼 보이지만, Leo Mehr는 오히려 FDE가 가장 먼저 해야 할 일은 “예”라고 말하는 것이 아니라 요청의 범위를 정확히 파악하는 것이라고 강조한다. 고객 성공을 돕는 것과 고객이 말한 대로 무조건 구현하는 것은 다르며, 후자는 좋은 소프트웨어를 만드는 방식이 아니라는 것이다.
그는 이를 설명하기 위해 극단적인 비유를 사용한다. 고객 요청을 무비판적으로 받아들이면 Waymo 같은 잘 설계된 자율주행차가 아니라, 말 다리에 로켓을 묶은 기괴한 결과물이 나올 수 있다는 취지다. 이 비유의 핵심은 고객이 표현한 요구가 실제 문제의 좋은 해법이라고 보장할 수 없다는 데 있다. 고객은 자신의 업무 맥락에서 불편을 말하지만, 그 불편을 제품적으로 어떻게 해결할지는 엔지니어링 조직이 별도로 판단해야 한다.
FDE의 스코핑은 단순한 요구사항 정리가 아니다. 고객이 왜 지금 이 기능을 요구하는지, 긴급성이 고객에게서 나온 것인지 아니면 분기 말 할당량을 맞추려는 영업 압박에서 나온 것인지, 이미 존재하는 제품 기능이나 수동 처리로 당분간 우회할 수 있는지까지 확인하는 과정이다. 이 질문들이 없으면 FDE는 중요한 엔터프라이즈 고객이라는 이유만으로 과도한 기능 개발을 떠안게 되고, 결국 제품의 방향성과 엔지니어링 리소스 모두를 훼손할 수 있다.
SAP S/4HANA 요청 사례가 보여주는 스코핑의 실제 의미
강연자는 Ramp에서 실제로 자주 발생하는 상황의 한 형태로 SAP S/4HANA 통합 요청을 예로 든다. 금요일 밤, 엔터프라이즈 영업 담당자가 매우 중요한 전략 고객이 SAP S/4HANA integration을 만들어야만 계약을 체결할 것이라고 말하는 상황이다. 일반적인 엔지니어링 반응은 SAP API 문서를 찾고, 통합을 어떻게 구현할지 바로 고민하는 방향으로 흐르기 쉽다.
그러나 Leo Mehr가 말하는 “잘 훈련된 FDE”는 여기서 바로 구현으로 뛰어들지 않는다. 먼저 긴급성의 출처를 묻고, 실제 고객이 계약을 막고 있는 것인지, 아니면 영업팀 내부의 분기 말 압박이 기능 요청을 과장하고 있는지 확인한다. 또한 누가 이 통합을 사용할 것인지, 다른 우회 방법을 모두 검토했는지, 임시로 수동 처리할 수 있는지, 고객 측에 기술 리소스가 있어 Ramp의 API를 직접 호출할 수 있는지 등을 질문한다.
03:50 - SAP S/4HANA integration 요청 사례에서 긴급성의 출처와 고객의 실제 필요를 질문해야 한다고 설명하는 장면
이 과정의 더 중요한 지점은 단일 고객 요청을 다른 고객과 잠재 고객의 맥락 안에서 다시 보는 것이다. 만약 동일한 SAP S/4HANA 통합이 파이프라인에 있는 여러 대형 고객에게도 필요하다면, 이는 단순한 커스터마이징이 아니라 제품적으로 투자할 만한 기능이 된다. 반대로 한 고객의 일회성 요구에 가깝다면, FDE는 완전한 제품 개발 대신 API 활용, 임시 운영 처리, 단계적 제공 같은 다른 해법을 검토해야 한다. 스코핑은 그래서 “얼마나 빨리 만들 것인가”의 문제가 아니라 “무엇을 제품으로 만들 가치가 있는가”를 판단하는 과정이다.
iOS와 Android 사례: 기본 가정도 검증하지 않으면 낭비가 된다
강연에서 가장 인상적인 사례는 모바일 reimbursement feature 개발 이야기다. Ramp의 한 대형 엔터프라이즈 고객이 모바일에서 환급 기능을 필요로 했고, 당시 모바일 팀은 이미 업무가 과중한 상태였다. FDE 팀은 문제를 해결하기 위해 직접 팔을 걷어붙였고, 두 명의 엔지니어가 iOS와 Android 개발을 학습해 몇 주 동안 양쪽 플랫폼 기능을 모두 구현했다.
겉으로 보면 이는 FDE의 실행력을 보여주는 성공 사례처럼 보인다. 고객 요구를 해결하기 위해 필요한 기술을 빠르게 익히고, 팀 경계를 넘어 기능을 출시하려 했기 때문이다. 그러나 고객에게 Android 베타 사용자 명단을 요청했을 때, 팀은 예상치 못한 사실을 알게 된다. 해당 고객사는 모든 직원에게 iOS 기기 사용을 의무화하고 있었고, Android 구현은 애초에 필요하지 않았던 것이다.
05:45 - 모바일 reimbursement feature 사례에서 Android까지 구현한 뒤 고객사가 iOS만 사용한다는 사실을 알게 되는 장면
이 에피소드는 스코핑이 거창한 전략 질문에만 필요한 것이 아니라는 점을 드러낸다. “어느 플랫폼을 지원해야 하는가”처럼 너무 기본적이어서 당연해 보이는 가정도 확인하지 않으면, 몇 주의 엔지니어링 시간이 그대로 낭비될 수 있다. Leo Mehr는 이 경험이 Ramp FDE 팀에게 매우 고통스러운 교훈이었다고 말한다. FDE의 속도는 중요하지만, 검증되지 않은 속도는 고객 성공이 아니라 잘못된 방향으로 빠르게 달리는 위험이 된다.
두 번째 원칙: Scale with Tokens
첫 번째 원칙이 고객 요청을 올바르게 좁히는 일이라면, 두 번째 원칙은 그 과정을 AI 시대에 맞게 확장하는 일이다. Leo Mehr는 오늘날의 지식 노동 대부분이 모델과 에이전트에 의해 재구성될 수밖에 없으며, FDE 역시 예외가 아니라고 말한다. 그는 이를 “scale with tokens”라고 표현한다. 이는 단순히 AI 도구를 업무 보조로 쓰자는 뜻이 아니라, FDE의 전체 생애주기를 에이전트가 처리할 수 있는 단계들로 분해하자는 주장에 가깝다.
강연자에 따르면 FDE의 업무 흐름은 대략 고객 맥락 수집, 요청 스코핑, 스펙 작성, 기능 구현으로 이어진다. 과거에는 이 모든 단계가 FDE의 판단과 수작업에 크게 의존했지만, 이제는 각 단계를 에이전트로 대체하거나 보조할 수 있다. 처음에는 이 과제가 막막해 보일 수 있지만, 그는 문제를 작은 파이프라인으로 나누면 충분히 다룰 수 있다고 설명한다.
07:22 - FDE의 전체 생애주기를 context gathering, scoping, spec writing, implementation 단계로 나누고 에이전트가 각 단계를 대체할 수 있다고 설명하는 장면
이 관점에서 “tokens”는 단순한 LLM 사용량의 단위가 아니다. 토큰으로 확장한다는 것은 조직의 지식 노동을 모델 호출, 컨텍스트 주입, 평가, 피드백 루프로 재구성한다는 의미다. FDE는 고객과 제품 사이의 불확실한 언어를 다루는 조직이기 때문에, 오히려 AI 에이전트가 들어갈 수 있는 여지가 크다. 다만 그 전제는 앞서 말한 스코핑 원칙이 제대로 작동해야 한다는 것이다.
Slack과 Notion Agent로 시작한 FDE 요청 자동화
Ramp의 구체적 사례는 내부 Slack 채널인 “FDE requests”에서 시작된다. 이 채널에는 account managers, solutions 팀, sales reps가 대형 고객이나 잠재 고객의 blocker를 올린다. 요청은 때로 매우 상세하지만, 어떤 경우에는 “SAP integration이 필요하다”는 한 줄에 그치기도 한다. 이처럼 입력 품질의 분산이 크기 때문에, 과거에는 FDE들이 직접 요청을 읽고 제품에 이미 존재하는 기능을 확인하며 고객과 여러 차례 왕복 커뮤니케이션을 해야 했다.
Ramp는 이 문제를 해결하기 위해 Notion Agent를 활용한 첫 번째 버전을 만들었다. 초기 버전은 요청을 받아 몇 가지 질문을 던지는 단순한 방식이었지만, 몇 주 뒤 팀은 이것만으로도 상당한 시간이 절약된다는 사실을 확인했다. 특히 응답 지연 시간이 몇 시간 또는 며칠에서 몇 초로 줄어들면서, account reps와 account managers가 에이전트와 즉시 상호작용하기 시작했다는 점이 중요하다. 사람 FDE가 요청을 읽기 전에도, 에이전트가 기본적인 공백을 메우고 필요한 정보를 끌어낼 수 있게 된 것이다.
09:19 - Ramp의 Notion Agent 초기 버전이 요청을 읽고 질문을 던지는 방식으로 FDE 요청 스코핑을 보조했다고 설명하는 장면
이후 Ramp는 더 발전된 버전을 만들었다. 강연자는 최근 iteration에서 작은 펭귄 캐릭터가 에이전트를 더 친근하게 보이게 만든다고 언급한다. 그러나 진짜 변화는 외형이 아니라 동작 방식에 있다. 이 에이전트는 제출자와 여러 차례 질문을 주고받으며, 스펙을 만들 준비가 되었다고 판단할 때까지 요청을 구체화한다. Leo Mehr는 이 시스템이 요청 스코핑에 쓰던 시간의 큰 비율, 대략 20% 정도를 절약한 것으로 보인다고 말한다. 다만 이 수치는 강연자의 추정에 가까우며, 정확한 측정값으로 확정하기보다는 내부 체감 효과를 설명하는 표현으로 이해하는 편이 적절하다.
FDE 파이프라인에서 가장 어려운 중간 영역
Leo Mehr는 Ramp가 요청 수집과 초기 스코핑에서 어느 정도 진전을 만들었고, 마지막 구현 단계도 frontier models 덕분에 쉬워지고 있다고 설명한다. 그는 최신 모델들이 medium-sized features를 한 번에 구현할 수 있을 정도로 강력해졌다고 말한다. 그러나 그 사이에 있는 중간 단계, 즉 잘 정리된 요청을 제품적으로 의미 있는 스펙과 실행 가능한 설계로 바꾸는 과정은 여전히 “gnarly”하고 덜 형성된 영역이라고 표현한다.
10:44 - 잘 정리된 스펙에서 작동하는 제품으로 가는 단계와, 그 사이의 어려운 중간 영역을 FDE 자동화의 핵심 과제로 설명하는 장면
이 중간 영역이 어려운 이유는 단순히 텍스트를 정리하는 문제가 아니기 때문이다. 고객의 요청이 제품에 어떤 영향을 주는지, 기존 기능과 충돌하지 않는지, 다른 고객에게도 필요한지, 어떤 순서로 구현해야 하는지, 어느 정도의 품질 기준을 만족해야 하는지 판단해야 한다. 이는 제품 매니저, 엔지니어, 고객 담당자가 암묵적으로 공유해온 맥락이 결합되는 영역이다. 문서화된 Notion docs나 help articles만으로는 충분하지 않은 이유도 여기에 있다.
강연자는 앞으로 6개월에서 12개월 동안 Ramp의 FDE가 바로 이런 applied AI problems에 많은 시간을 쓰게 될 것이라고 전망한다. 각 단계의 agent harness가 안정적으로 동작하도록 만들고, 산출물의 품질을 evals, rubrics, human feedback으로 검증하며, LLM 호출 시 올바른 컨텍스트가 들어가도록 설계하는 일이 핵심 과제가 된다. 특히 제품 매니저가 머릿속에 가진 지식, 과거 고객 사례, 제품의 세부 동작, 내부 정책 같은 정보를 어떻게 에이전트에게 제공할지가 중요한 문제로 떠오른다.
AI 에이전트 시대에도 남는 FDE의 책임: Taste and Judgment
강연의 후반부에서 Leo Mehr는 AI 에이전트가 FDE 업무의 많은 부분을 대체하더라도, FDE의 책임이 사라지는 것은 아니라고 선을 긋는다. 그는 최종 산출물에 대한 taste and judgment, 즉 취향과 판단의 책임은 여전히 FDE에게 있다고 말한다. 여기서 taste는 단순한 미적 감각이 아니라, 무엇이 좋은 제품인지, 어떤 해결책이 고객에게 실제로 유용한지, 어떤 기능이 장기적으로 제품을 망가뜨리지 않는지 판별하는 감각에 가깝다.
이는 AI 자동화 담론에서 자주 놓치는 지점이다. 에이전트는 질문을 던지고, 스펙을 만들고, 구현까지 도울 수 있지만, 잘못 정의된 문제를 훌륭하게 자동화하면 더 빠르게 잘못된 결과를 만들 뿐이다. 강연자가 뒤에서 말하는 “token-maxing slop cannon”이라는 표현은 바로 이런 위험을 가리킨다. 스코핑이 부실한 상태에서 토큰만 많이 쓰는 에이전트 공장을 만들면, 조직은 고품질 자동화가 아니라 대량의 저품질 산출물을 얻게 된다.
따라서 Ramp식 FDE의 미래는 사람을 에이전트로 완전히 대체하는 방향이 아니다. 더 정확히는 사람이 판단해야 할 지점과 에이전트가 반복적으로 처리할 지점을 분리하고, 그 사이를 평가 체계와 컨텍스트 관리로 연결하는 방향이다. FDE는 고객과 직접 맞닿아 있는 엔지니어링 조직이기 때문에, 자동화의 결과가 실제 고객 문제를 해결하는지 가장 가까운 곳에서 확인할 수 있다.
두 원칙은 따로 작동하지 않는다
강연의 결론은 “Always be scoping”과 “Scale with tokens”가 서로 독립된 조언이 아니라는 데 있다. 스코핑 없이 에이전트 공장을 만들면, 조직은 잘못 정의된 요청을 대량으로 처리하는 시스템을 만들게 된다. 반대로 스코핑은 뛰어나지만 AI 에이전트로 확장하지 못하면, agent-native competitors가 더 빠른 속도와 더 낮은 비용 구조로 앞서갈 수 있다.
12:53 - 스코핑 없이 에이전트 공장을 만들면 token maxing slop cannon이 될 수 있다고 경고하며 두 원칙의 균형을 강조하는 장면
이 균형은 FDE 조직뿐 아니라 AI 시대의 제품 조직 전체에 적용될 수 있다. 고객 요구를 깊이 이해하는 능력은 여전히 중요하지만, 그것만으로는 충분하지 않다. 동시에 AI를 도입하는 속도도 중요하지만, 무엇을 자동화할지 판단하는 능력 없이는 오히려 제품과 조직의 복잡성을 키울 수 있다. Ramp의 사례는 FDE가 고객 요구와 AI 자동화가 만나는 전선에서 어떤 역할을 해야 하는지 보여준다.
결국 Leo Mehr가 말하는 FDE의 미래는 “고객 요청을 빠르게 처리하는 엔지니어”의 모습보다 훨씬 넓다. FDE는 고객 맥락을 수집하고, 요청의 본질을 파악하며, 이를 제품화 가능한 스펙으로 바꾸고, 그 과정을 에이전트 기반 파이프라인으로 확장하는 역할을 맡는다. 이때 좋은 FDE는 단순히 더 많은 기능을 만드는 사람이 아니라, 무엇을 만들지 판단하고 그 판단을 AI 시스템이 반복 가능하게 수행하도록 설계하는 사람이다.
마무리 / 핵심 정리
이 강연의 핵심 takeaway는 FDE가 “고객이 요구한 것을 만들어주는 팀”이 아니라는 점이다. Ramp에서 FDE는 엔지니어링 조직 안에서 대형 엔터프라이즈 고객의 복잡한 요구를 제품적 판단으로 번역하고, 그 과정에서 스코핑을 통해 불필요한 구현을 줄인다. SAP S/4HANA integration 사례와 모바일 reimbursement feature 사례는 모두 고객 요청을 곧바로 구현하기 전에, 긴급성, 사용 범위, 플랫폼, 우회책, 반복 가능성을 검증해야 한다는 사실을 보여준다.
동시에 Leo Mehr는 FDE가 사람의 수작업에만 의존해서는 미래 경쟁력을 유지하기 어렵다고 본다. 고객 맥락 수집부터 스펙 작성과 구현까지 이어지는 FDE 파이프라인은 AI 에이전트로 점진적으로 대체되거나 증강될 수 있으며, Ramp는 Slack과 Notion Agent를 활용해 이미 초기 스코핑 자동화에서 의미 있는 효과를 얻고 있다. 그러나 이 자동화가 제대로 작동하려면 최종 산출물의 품질을 평가하는 evals, rubrics, human feedback이 필요하고, 무엇보다 올바른 컨텍스트를 모델에 전달하는 시스템이 필요하다.
따라서 강연의 결론은 단순하지만 강하다. FDE의 미래에는 좋은 스코핑과 토큰 기반 확장이 모두 필요하다. 하나만 있으면 부족하고, 둘 중 하나가 없으면 조직은 느려지거나 저품질 자동화에 빠질 수 있다. Ramp의 경험은 AI 시대의 엔지니어링 조직이 고객 요구를 다루는 방식이 어떻게 바뀌고 있는지 보여주는 실용적인 사례다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | How Forward Deployed Engineering is done at Ramp — Leo Mehr |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-07-29 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.