How Forward Deployed Engineering is done at Kepler — Vinoo Ganesh

한 줄 핵심

Forward Deployed Engineering은 고객 대응용 역할이 아니라 실제 현장에서 문제를 정의하고, 빠르게 해결한 뒤 그 해법을 제품으로 일반화하는 제품 전략이어야 한다는 주장이다.

시간별 요약

1. 0:01
   이 영상은 FDE를 영업 지원 기능이 아니라 제품 전략으로 봐야 한다는 관점에서 시작한다. Palantir와 Kepler의 경험을 바탕으로, 현장에 들어가 문제를 직접 정의하고 해결하는 방식이 어떻게 제품을 만드는지 설명한다.
2. 3:02
   고객과 분리된 상태에서 만든 Phoenix는 실제 데이터의 복잡성을 반영하지 못해 실패했고, 이를 통해 현장과 함께 만들지 않으면 제품이 무너진다는 교훈을 얻는다. FDE의 핵심은 고객을 만나는 것이 아니라 고객 문제를 공동으로 발견하고 제품 기회로 바꾸는 데 있다.
3. 5:01
   겉으로 큰 요구사항처럼 보이는 문제도 현장에 가보면 Slack alert 하나로 끝나는 경우가 많다. 반복 작업, 도구 전환, 탭 이동, 불만 섞인 반응은 모두 실제 문제의 신호이며, 하루 안에 풀 수 있는 문제는 즉시 해결해 신뢰를 얻는 것이 중요하다.
4. 8:00
   현장에서 관찰한 행동은 문서보다 훨씬 강한 신호를 준다. CSV를 수동으로 열어보던 사용자를 위해 Parquet viewer를 만든 사례처럼, 사용자의 반복 동작과 불편함을 포착하면 큰 비용 절감과 성능 개선으로 이어질 수 있다.
5. 12:01
   조직에서 사용하는 명사와 동사를 정의하는 일이 곧 제품의 지배력을 만든다. customer, org ID, skills, MCP 같은 용어를 어떻게 표준화하느냐가 통합 품질과 확장성을 좌우하며, 임시 스크립트도 생산 환경에 들어가면 장기 부채가 되므로 처음부터 제품화 기준으로 판단해야 한다.

실무 인사이트

• 현장 FDE는 요구사항 수집보다 문제 재정의에 집중해야 하며, 하루 안에 끝나는 문제는 즉시 해결해 신뢰를 먼저 확보하는 것이 효과적이다.
• 사용자 행동 관찰에서 반복 작업, 도구 복사·붙여넣기, 탭 전환 같은 마찰 지점을 체크하면 문서에는 없는 실제 제품 기회를 찾을 수 있다.
• 임시 해법이라도 운영 환경에 들어가면 사실상 영구 자산이 되므로, ship fast보다 더 중요한 것은 나중에 제품 핵심으로 흡수 가능한지 판단하는 일이다.