포트원은 최근 몇 달 동안 고객사 프로젝트에 FDE(Forward Deployed Engineer) 방식을 적용하고 있습니다. 가장 크게 달라진 건 일의 속도입니다. 몇 주씩 논의하던 의사결정이 며칠 안에 정리되고, 고객사와 문제를 주고받는 속도도 눈에 띄게 빨라졌습니다. 그만큼 고객사와 포트원 모두 프로젝트에 대한 만족도가 높아지는 것도 체감할 수 있었습니다.
그렇다면 FDE는 실제로 어떻게 일하고 있을까요? 말로 설명하려면 생각보다 쉽지 않은 이 역할을, 이번 아티클에서는 포트원 크루의 일하는 모습을 통해 보여드리려고 합니다.
APR 프로젝트에서 FDE로 일하고 있는 정주영 FDE를 만났습니다. 개발을 취미로 시작해 독학으로 익혔고, 프로젝트가 막히던 시점에는 직접 "우리 일하는 방식을 바꿔보자"고 제안한 크루입니다. 지금은 APR로 출근해 고객과 함께 문제를 정의하고 우선순위를 정하고 직접 개발까지 맡아 하고 있습니다. 대체 어떻게 가능한 걸까요? 그 이야기를 직접 들어봤습니다.
.png)
PART 1. FDE가 되기까지
Q. 안녕하세요, 정주영 FDE님! 자기소개 부탁드려요.
포트원에서 FDE로 일하고 있는 정주영입니다. 현재 CO(Commerce Ops)팀에서 FDE로 일하고 있습니다.
Q. 포트원에는 PO로 입사하셨잖아요. 그런데 몇 달 만에 FDE가 되셨어요. 어떻게 된 일인가요?
어느 날 갑자기 직무가 바뀐 건 아니에요. 오히려 일하는 방식이 먼저 바뀌었고, 직무명이 나중에 따라온 것에 가깝습니다.
고객사 프로젝트를 하다 보면 현장에서 필요한 것이 빠르게 보이는데, 이를 요건으로 정리해 코어 팀에 전달하고 정규 제품 개발 프로세스를 거치기까지는 자연스럽게 시차가 생길 수밖에 없어요. 코어 팀은 수많은 고객을 위한 제품의 우선순위와 로드맵을 함께 책임지고 있으니까요.
그래서 저는 현장에서 발견한 문제를 직접 만들어 빠르게 검증하는 방식으로 풀어보기 시작했어요. 고객에게 바로 보여주고, 피드백을 받아 다시 고치는 짧은 사이클을 반복하는 것이 현장의 문제를 해결하는 데 훨씬 빠르고 효율적이라고 판단했죠. 그렇게 일하는 방식이 달라지면서 자연스럽게 FDE라는 역할로 이어지게 됐습니다.
Q. APR 프로젝트를 FDE 방식으로 해보자고 먼저 제안하셨다고 들었어요.
네, 제가 먼저 제안해서 시작했어요. 올해 5월쯤이었습니다.
마침 그때 회사에서도 팔란티어의 FDE 방식에 대한 이야기가 나오기 시작했어요. 그래서 APR 프로젝트도 직접 현장에 들어가 고객과 부딪혀보면서 문제를 풀어보자는 제안을 드렸습니다. 그렇게 FDE 방식으로 프로젝트를 시작하게 됐어요.
PART 2. FDE라는 직무
Q. 그렇다면 FDE는 구체적으로 어떤 역할을 하나요?
FDE를 가장 쉽게 설명하면 '미니 CTO'에 가까운 역할이라고 생각해요. 현장에서 어떤 문제를 풀어야 하는지 정의하고, 어떤 방식으로 해결할지 기술적인 의사결정까지 직접 내리니까요. 동시에 그 해결이 실제 비즈니스 임팩트로 이어져야 한다는 점에서는 '미니 CEO'의 역할도 겸하고 있다고 생각합니다.
결국 FDE의 핵심은 현장에서 문제를 해결하기 위한 의사결정을 직접 내릴 수 있다는 것이에요. 그래서 단순히 역량 있는 사람을 현장에 보내는 것만으로는 충분하지 않아요. FDE가 스스로 판단하고 실행할 수 있는 권한이 있어야 하고, 그 판단에 맞춰 조직도 함께 움직일 수 있어야 합니다.
제품을 만드는 방식도 기존 제품 조직과는 조금 달라요. 일반적인 제품 개발이 회사의 로드맵을 기준으로 고객의 요구사항을 해결해 나가는 방식이라면, FDE는 지금 이 고객의 문제를 가장 빠르고 효과적으로 해결하려면 무엇을 해야 하는지부터 판단합니다.
그리고 그 과정에서 필요한 것은 직접 만들고, 코어 팀의 도움이 필요한 부분은 협업하면서 해결해요. 그렇게 현장에서 얻은 경험과 인사이트가 다시 전체 제품과 로드맵에 반영되는 거죠.
그래서 저는 FDE를 현장에 작은 스타트업 하나를 만들고, 본인의 비즈니스를 하는 것과 같다고 생각해요. 고객의 문제를 가장 가까이에서 보고, 필요한 의사결정을 직접 내리면서, 문제를 해결하는 데 필요한 제품까지 함께 만들어가는 거죠.
Q. 일반적인 소프트웨어 엔지니어와 비교하면 FDE의 일하는 방식은 어떻게 다른가요?
가장 큰 차이는 문제를 해결하는 방향성에 있다고 생각해요.
일반적인 소프트웨어 엔지니어가 하나의 완성된 범용 제품을 만들어 수많은 고객을 커버하는 데 집중한다면, 말 그대로 1 to N의 방식이죠. 하나의 제품을 여러 고객에게 적용할 수 있도록 만드는 것이 중요합니다.
FDE는 그 반대에 가까워요. 여러 명의 핵심 탤런트가 모여 단 하나의 고객이 가진 가장 복잡하고 시급한 문제를 깊게 파고드는 N to 1의 방식이에요. 고객마다 상황과 문제가 다르기 때문에, 처음부터 완성된 요구사항을 전달받아 개발하는 것이 아니라 현장에서 고객의 문제를 정의하는 것부터 시작하고요.
그렇다고 현장에서 해결한 일이 그 고객만을 위한 일로 끝나는 것도 아닙니다. 고객과 직접 부딪히며 발견한 문제와 해결 방법이 코어 제품에 반영되고, 그 경험이 다시 회사 전체의 제품 역량으로 쌓이게 되죠.
그래서 FDE의 역할은 한 고객의 문제를 깊이 파고들어 해결하고, 그 과정에서 얻은 경험을 다시 N개의 고객이 사용할 수 있는 제품으로 확장하는 것이라고 생각해요. N to 1로 시작하지만, 결국 1 to N으로 다시 확장되는 구조인 거죠.
Q. 그럼 기존 외주나 SI 방식과는 근본적으로 어떤 점이 다른가요?
가장 큰 차이는 문제 해결에 대한 주도권(ownership), 그리고 현장에서 얻은 경험이 회사의 자산으로 남는 방식에 있다고 생각해요.
전통적인 외주나 SI 프로젝트에서는 고객의 요구사항을 기준으로 업무 범위를 정하고, 그에 맞는 결과물을 납품하면 프로젝트가 끝나는 경우가 많잖아요. 아무리 현장에서 좋은 해결책을 찾아내더라도 프로젝트가 끝나는 순간 그 경험까지 함께 끝나기 쉽고요.
FDE는 정반대예요. 고객의 비즈니스 목표가 얼라인된 상황에서 현장의 병목을 어떻게 해결할지부터 스스로 정의하고, 필요한 기술 전략과 실행 방법까지 주도합니다. 고객에게 어떤 일을 해달라는 요청을 받는 것이 아니라, 문제를 해결하기 위해 우리가 어떻게 움직여야 하는지를 직접 판단하는 거죠.
그렇다 보니 결과물의 본질도 다릅니다. FDE가 현장에서 만드는 것은 단순히 고객에게 넘겨주기 위한 산출물이 아니에요. 고객의 문제를 해결하는 소프트웨어를 만들면서 그 안에 포트원의 코어 제품과 기술을 함께 결합합니다. 그리고 실제 현장에서 부딪히며 얻은 기술적 노하우와 문제 해결 방식은 다시 코어 제품에 반영되고요.
결국 한 고객의 문제를 해결하는 과정이 그대로 포트원의 다음 제품과 기술을 만드는 과정으로 이어지는 것이죠. 프로젝트가 끝나면 경험도 함께 사라지는 게 아니라, 다음 고객을 더 잘 해결할 수 있는 회사의 역량으로 축적되는 겁니다.
그래서 저는 FDE를 기존 범용 SaaS의 한계를 현장 밀착형으로 풀어내는 '프로덕트 엔지니어링'이라고 생각해요. 고객의 문제를 가장 가까이에서 해결하면서도, 그 해결 과정과 결과를 다시 우리의 제품과 코어 역량으로 만들어가는 역할인 거죠.
.png)
PART 3. FDE의 일하는 방식
Q. 실제로는 어떻게 프로젝트를 이끌어가나요?
FDE는 정답이 정해져 있지 않은 상태에서 시작하는 역할이라고 생각해요.
고객사는 "월 마감을 효율화하고 싶다", "매출이 늘어나면서 더 이상 사람 손으로는 버티기 어렵다" 같은 비즈니스 문제를 가지고 있어요. 저희가 해야 할 일은 그 문제를 해결해서 실제 비즈니스 성과를 만드는 것이고요. 하지만 그 문제를 구체적으로 어떻게 풀 것인지는 처음부터 정해져 있지 않습니다. FDE는 바로 그 지점에서 프로젝트를 시작해요.
저만 해도 처음 APR 프로젝트를 맡았을 때 담당자에게 "어떤 기능이 필요하세요?"라고 물었는데, 명확한 답이 나오지는 않았어요. 고객도 해결하고 싶은 문제는 알고 있지만, 그것을 어떤 제품으로 만들어야 하는지까지 정해져 있는 건 아니니까요.
결국 다음 단계를 제가 직접 설계해야 했어요. 어떤 방식으로 POC를 만들어볼지, 무엇부터 개발할지, 언제 고객에게 보여주고 피드백을 받을지까지 하나씩 결정해야 했죠.
처음에는 쇼피파이부터 시작했습니다. 고객사에서도 익숙한 채널이었고, 데이터 규모도 너무 작지도 크지도 않아서 POC를 만들어 검증하기에 적합하다고 판단했어요. 그래서 쇼피파이에 필요한 최소한의 기능부터 구현하고, 고객사와 실제로 소통하면서 어떤 부분이 필요한지 하나씩 확인했습니다. 그렇게 피드백을 받아가면서 우리가 만들어야 할 제품의 모습도 조금씩 구체화해갔고요.
그다음은 틱톡이었습니다. 틱톡은 임팩트가 큰 채널인 대신 처리해야 하는 데이터 규모가 커서 기술적인 챌린지가 있었어요. 그래서 처음부터 모든 문제를 한 번에 해결하려고 하기보다, 어떤 문제를 먼저 풀고 어느 시점에 다음 단계로 넘어갈지를 나눠서 계획했습니다.
이런 식으로 FDE는 완성된 프로젝트 계획을 받아 실행하는 역할이 아니에요. 문제만 주어진 상태에서 중단기 목표를 세우고, 필요한 일을 정의하고, 제한된 리소스를 어디에 배치할지 판단하면서 프로젝트의 방향 자체를 만들어가는 역할에 가깝습니다.
그래서 FDE에게는 개발 역량이나 도메인 지식만큼이나 프로젝트를 스스로 설계하고 끝까지 끌고 갈 수 있는 역량이 중요하다고 생각해요. 모든 걸 혼자 결정해야 한다는 게 어렵다기보다, 내가 내린 판단에 따라 프로젝트가 실제로 움직인다는 것. 그게 FDE라는 역할의 가장 큰 특징인 것 같아요.
Q. 현장에서 어떤 방식으로 일하나요?
최근에는 APR 프로젝트를 전담하고 있고, 보통 주 단위로 다음 주 현장에서 해결해야 할 문제와 태스크를 정합니다. 프로젝트 범위가 쇼피파이에서 틱톡, 쇼피까지 계속 넓어지고 있어 그때그때 가장 중요한 과제를 판단해 우선순위를 조정하고 있어요.
현장에서는 불필요한 보고 체계나 긴 의사결정 과정을 거치기보다 고객사 실무진과 바로 소통하면서 문제를 해결합니다. 데이터를 검증하다가 문제가 발견되면 바로 수정하고, 담당자에게 확인받은 뒤 다시 검증하는 식으로 짧은 사이클을 반복하는 거죠.
그렇다고 FDE가 현장에 혼자 떨어져서 모든 걸 해결하는 구조는 아니에요. 현장에서는 빠르게 판단하고 실행하되, 기술적으로 더 깊은 도움이 필요하거나 코어 제품과 연결해야 하는 부분은 언제든 포트원 코어팀과 협업합니다. 현장과 코어팀이 긴밀하게 백업을 주고받으면서 문제를 해결하는 구조예요.
결국 FDE의 장점은 고객과 가까운 거리에서 빠르게 움직이면서도, 포트원의 기술과 제품 역량을 그대로 활용할 수 있다는 것이라고 생각합니다. 현장에서 이야기하고, 결정하고, 실행하는 속도와 코어팀의 전문성이 함께 작동하는 거죠.
Q. 그러면 코드는 언제 짜냐고 반문하실 분들도 계실 것 같아요.
맞아요. (웃음) 요즘은 코드를 작성하는 방식 자체가 완전히 달라진 것 같아요. 단순 반복 작업이나 대량의 초기 세팅 같은 작업은 AI가 훨씬 빠르게 해내거든요. 그렇다고 개발자의 역할이 줄어든 건 절대 아닙니다. 오히려 무엇을 만들어야 하는지 정의하고, 어떤 구조로 만들어야 하는지 판단하고, AI에게 정확한 방향을 제시하는 역할이 더 중요해졌어요.
AI는 굉장히 빠른 비행기와 같아요. 마차가 1도 틀어진 방향으로 하루를 간다면 목적지에서 조금 벗어나는 정도일 수 있지만, 비행기가 1도 틀어진 채 날아가면 전혀 다른 나라에 도착할 수도 있잖아요. 우주선이라면 아예 다른 행성으로 갈 수도 있고요.
그래서 중요한 건 AI를 얼마나 빠르게 움직이게 하느냐보다 어디로 가야 하는지를 정확하게 판단하는 일입니다. 그리고 그 판단을 하려면 FDE에게 충분한 엔지니어링 역량과 기술적 이해가 필요해요. 단순히 프론트엔드에서 무엇을 보여줄지만 아는 것으로는 부족합니다. 백엔드에서 데이터가 어떻게 처리되는지, 시스템이 어떤 구조로 동작하는지까지 이해해야 AI에게 제대로 된 방향을 제시할 수 있고, AI가 만든 결과물이 실제로 사용할 수 있는 수준인지도 판단할 수 있거든요.
APR만 해도 틱톡에서 한 달에 몇 백만 건 수준의 데이터가 들어와요. 이런 규모의 데이터를 가지고 정산과 마감 계산을 하다 보면 다양한 기술적인 문제가 생깁니다. 이 구조를 충분히 이해하지 못한 채 AI에게 단순히 "틱톡 채널 연동해줘"라고 요청하는 것과, 데이터의 흐름과 시스템 구조를 이해한 상태에서 필요한 것을 정확하게 정의하는 것은 결과가 크게 다를 수밖에 없어요.
결국 AI 시대의 개발은 코드를 얼마나 빨리 생성하느냐의 문제가 아니라, 무엇을 만들어야 하는지 정확히 이해하고, 어떤 구조로 풀어야 하는지 판단한 뒤 AI를 올바른 방향으로 활용하는 것이라고 생각합니다. 그리고 그만큼 개발자에게 필요한 엔지니어링 역량의 깊이도 여전히 중요하다고 생각하고요.
Q. FDE에게 특히 더 중요한 기술 역량이 있을까요?
앞서 말씀드린 선순환 구조를 기술적으로 만들어낼 수 있는 역량이 중요하다고 생각해요.
FDE는 코어 팀이 가진 기술과 제품을 현장에서 최대한 효율적으로 활용해서 개발 기간을 줄이고, 동시에 고객의 문제를 해결하면서 새롭게 발견한 것들을 다시 코어 제품으로 가져올 수 있어야 합니다.
결국 두 가지를 같이 봐야 해요. 코어에 있는 것을 현장에 어떻게 가져와서 효율적으로 활용할 것인가. 그리고 현장에서 새롭게 발견한 것을 어떻게 다시 코어 제품으로 만들 것인가.
그러려면 아키텍처에 대한 이해가 필요합니다. 지금 당장 고객 한 곳의 문제를 해결하는 데서 끝나는 게 아니라, 이걸 어떻게 하면 다른 고객에게도 재생산할 수 있을지, 규모가 커졌을 때도 유지할 수 있는 구조로 만들 수 있을지를 계속 생각해야 하거든요.
물론 그 과정에서 트레이드오프가 생겨요. 당장 코어 제품에 반영하기 어려운 방식이라도 현장에서는 그렇게 개발해야 고객의 문제를 더 빨리 해결할 수 있는 경우가 있습니다. 반대로 현장에서 급하게 만든 해결책을 그대로 코어에 가져가면 안 되는 경우도 있고요.
그래서 FDE는 이런 상황에서 속도와 확장성 사이의 트레이드오프를 이해하고, 어떤 기술적인 결정을 내릴지 스스로 판단할 수 있어야 합니다.
그렇다고 코딩 자체의 중요성이 없어졌다고 생각하지는 않아요. 저는 여전히 코딩의 즐거움을 아는 사람이 좋은 개발자라고 생각합니다. 다만 지금은 사람이 직접 타자를 쳐서 코드를 하나하나 입력하는 시대가 아닐 뿐이죠. AI를 활용해서 코드를 만들어내더라도, 무엇을 만들지 판단하고 결과물을 검증하고 개선하는 과정에는 여전히 개발자의 기술적인 역량이 필요합니다. 그런 의미에서 저는 지금도 소프트웨어 개발을 핸즈온으로 하고 있다고 생각해요.
PART 4. FDE의 권한
Q. FDE의 자율성이 가장 잘 드러났던 사례가 있을까요?
쇼피 프로젝트를 꼽고 싶어요. APR에서 새로운 쇼피 마케팅 캠페인을 앞두고 정산까지 익월 안에 준비해야 하는 상황이 생기면서 프로젝트 일정이 크게 앞당겨진 적이 있었어요.
당시 포트원의 코어 제품 로드맵에서는 쇼피가 그보다 뒤에 예정되어 있었습니다. 코어 팀의 정규 일정을 기다리면 고객사의 비즈니스 타임라인을 맞추기 어려운 상황이었죠.
그래서 코어 팀의 개발을 기다리는 대신, 현장에서 쇼피 연동을 직접 개발하는 투트랙 전략을 제안했습니다. 코어 팀은 기존 로드맵을 유지하고, FDE가 현장에서 고객 일정에 맞춰 먼저 개발하는 방식이었어요.
물론 같은 기능을 두 곳에서 개발하는 것이기 때문에 일반적인 SaaS 관점에서는 비효율적인 선택으로 보일 수도 있습니다. 하지만 FDE에게는 고객의 비즈니스 타임라인을 지키는 것이 최우선이니까요. 코어 팀의 일정을 무리하게 흔들지 않으면서도, 현장의 자율성으로 고객이 필요한 시점까지 문제를 해결할 수 있다고 판단했습니다.
그리고 현장에서 먼저 만든 결과물이 그대로 끝나는 것도 아니에요. 개발 과정에서 새롭게 알게 된 요구사항이나 기술적인 인사이트는 다시 코어 팀과 공유하고, 이후 코어 제품에 반영할 수 있도록 연결합니다.
결국 코어 팀의 로드맵은 지키면서도, 고객의 일정은 현장에서 맞추는 것. 그리고 그 과정에서 얻은 경험을 다시 코어 제품으로 가져오는 것. 쇼피 프로젝트가 FDE의 자율성이 어떤 방식으로 고객과 회사 모두에게 가치를 만드는지 가장 잘 보여준 사례였다고 생각해요.
Q. FDE가 자율적으로 일하려면 조직의 신뢰도 중요할 것 같아요. 포트원은 어떤 환경인가요?
포트원의 환경을 한마디로 정의하면 '완벽한 권한 위임과 투명한 신뢰'라고 생각해요.
FDE는 정해진 기획서를 구현하는 역할이 아니라, 현장의 불확실성 속에서 스스로 정답을 찾아야 하는 직무에 가까워요. 그렇기 때문에 조직이 FDE를 촘촘한 결재 라인으로 관리하기 시작하면 현장에서의 민첩함은 금방 사라질 수밖에 없다고 생각합니다.
그래서 포트원은 절차보다 임팩트에 집중해요. 예를 들어 고객사에 나가는 일정도 사전에 정해진 규칙에 맞추기보다 현장의 상황을 보고 제가 주도적으로 판단합니다. 대신 무엇을 하고 있는지, 왜 그렇게 판단했는지, 어떤 결과가 있었는지는 팀과 투명하게 싱크를 맞추고요.
결국 FDE의 판단을 신뢰하고 충분한 권한을 맡기되, 그 결과에 대해서는 조직이 함께 책임지고 지원하는 구조인 거죠. FDE가 현장의 문제 해결에 100% 몰입할 수 있도록 불필요한 방해 요소는 최대한 없애주고, 필요한 리소스가 있으면 조직에서 전폭적으로 지원해줍니다.
저는 이게 단순히 '자율적으로 일할 수 있다'는 것과는 조금 다르다고 생각해요. 내가 판단하고, 내가 움직이고, 그 결과에 대해서는 조직과 함께 책임지는 것에 가깝거든요. 개발자로서 제 판단으로 비즈니스의 문제를 직접 뚫어낼 수 있다는 점에서 굉장히 큰 동기부여가 됩니다.
그래서 제가 생각하는 좋은 FDE 조직은 FDE에게 모든 걸 알아서 하라고 맡겨두는 조직이 아니에요. 스스로 판단할 수 있도록 권한을 쥐여주고, 그 판단에 책임을 질 수 있게 하면서, 필요할 때는 조직이 든든하게 백업해주는 조직이라고 생각합니다.
포트원이 지금 그런 방향으로 가고 있다고 생각해요. 온전히 제 판단으로 비즈니스를 뚫어내면서도, 필요할 때는 코어팀이나 리더십의 전폭적인 지원을 받을 수 있는 환경이니까요. 좀 올드한 표현이지만, 정말 일할 맛이 나는 환경이라고 자부합니다. (웃음)
.png)
PART 5. FDE에게 필요한 역량
Q. 그렇다면 어떤 개발자가 FDE라는 역할에 잘 맞을까요?
세 가지를 꼽을 수 있을 것 같아요.
첫째는 스스로 계획을 세우고 일을 끌고 갈 수 있는 사람입니다. FDE는 요건이 완전히 정의된 상태에서 일을 시작하지 않아요. 그래서 주어진 일을 잘 실행하는 것만으로는 부족합니다. 지금 해결해야 할 문제가 무엇인지 정의하고, 중단기 목표를 세우고, 제한된 리소스를 어디에 배치할지 스스로 판단할 수 있어야 해요.
둘째는 새로운 도메인을 배우고 그 안에서 문제를 발견하는 걸 즐기는 사람입니다. FDE가 고객의 문제를 제대로 해결하려면 그 고객의 비즈니스부터 이해해야 합니다. 어떤 데이터를 다루는지, 실제 업무는 어떻게 돌아가는지, 어디에서 병목이 생기는지를 알아야 제대로 된 솔루션을 만들 수 있으니까요. 기술을 깊게 파고드는 것만큼 새로운 산업과 업무를 빠르게 이해하고, 그 안에서 문제를 발견하는 능력이 중요합니다.
셋째는 현장에서 고객과 편안하게 소통하면서 함께 답을 찾아가는 데 열려 있는 사람입니다. FDE는 고객사의 실무진과 가까이에서 일하면서 기술적인 신뢰를 쌓아가는 역할이에요. 고객이 말하는 요구사항만 받아 적는 게 아니라, 대화를 통해 고객이 미처 명확하게 정의하지 못한 페인포인트까지 먼저 발견해야 합니다.
그리고 거기서 한 단계 더 나아가 "이 문제라면 포트원의 기술로 이렇게 해결할 수 있습니다"라고 직접 제안할 수 있어야 해요. 그렇게 고객의 문제를 하나씩 해결하다 보면 자연스럽게 우리가 만들어낼 수 있는 비즈니스 임팩트의 범위도 넓어지고요.
실제로 고객사 입장에서는 포트원의 CEO나 CTO보다 FDE와 훨씬 자주 이야기하고, FDE의 판단에 따라 제품이 바뀌는 과정을 직접 경험하게 됩니다. 그러다 보면 FDE는 자연스럽게 고객에게 가장 가까운 포트원의 기술 전문가이자 믿을 수 있는 파트너가 되는 거죠.
그래서 FDE는 기술적인 역할에만 머물지 않아요. 고객의 문제를 가장 가까이에서 보고 있기 때문에, 새로운 문제를 발견하고 그에 맞는 제품이나 기능을 제안하면서 자연스럽게 비즈니스 기회까지 확장해갈 수 있는 역할이기도 합니다. 단순히 무언가를 더 판매하는 게 아니라, "이 문제를 이렇게 해결할 수 있다"는 구체적인 제안에서 시작하는 거죠.
PART 6. FDE로서의 경험
Q. FDE로 일하면서 가장 기억에 남는 순간은 언제인가요?
아무래도 고객의 와우 모먼트를 바로 눈앞에서 보는 순간인 것 같아요. 여러 레이어를 거쳐 결과를 전달하는 게 아니라, 현장에서 제가 만든 것을 바로 보여줄 수 있잖아요. 그때 고객이 "이런 게 필요했어요", "감사합니다"라고 반응해주시면 정말 짜릿해요. 그 맛으로 일하는 것 같아요. (웃음)
예전에는 PO로 일하면서 고객 만족도 조사나 유저 리서치를 통해 간접적으로 피드백을 받았어요. 고객이 어떤 점을 불편해하는지 듣고 제품에 반영한 뒤, 다시 결과를 확인하는 방식이었죠.
그런데 FDE는 달라요. 고객 앞에서 직접 만들고, 보여주고, 그 자리에서 반응을 확인할 수 있습니다. 개발자에게 가장 먼 거리는 내가 만든 것과 그것을 사용하는 사람 사이의 거리라고 생각하는데, FDE는 그 거리가 거의 0에 가까운 자리예요.
누군가의 말을 통해 전해 듣던 변화를 이제는 내 눈앞에서 직접 보게 되는 거죠. 그리고 그 반응을 바로 확인할 수 있으니까, 자연스럽게 한 번 더 고민하게 돼요.
"오늘은 고객에게 충분한 와우 모먼트를 드리지 못한 것 같은데."
그렇게 생각하면 누가 시키지 않아도 한 번 더 파고들게 됩니다. 내가 만든 것이 고객의 일이 되고, 그 변화가 바로 눈앞에 보이니까요. 조금 더 나은 결과를 만들어주고 싶다는 동기도 자연스럽게 생기는 것 같아요.
결국 FDE의 가장 큰 매력은 기술을 만드는 데서 끝나는 게 아니라, 그 기술이 실제 고객의 변화를 만들어내는 순간까지 직접 경험할 수 있다는 것이라고 생각합니다.
Q. 마지막으로, 생소한 직무라 커리어를 걱정하거나 지원을 망설이는 분들에게 한마디 부탁드려요!
FDE가 아직 생소한 직무이다 보니 "이 커리어로 어떻게 성장하지?"라고 걱정하실 수도 있을 것 같아요. 하지만 저는 오히려 테크리드나 CTO, 나아가 창업을 꿈꾸는 분들에게 FDE만큼 좋은 성장의 기회도 많지 않다고 생각합니다.
FDE는 기술과 비즈니스를 따로 경험하는 게 아니라, 기술을 기반으로 실제 비즈니스 문제를 정의하고 해결하는 경험을 아주 압축적으로 할 수 있는 역할이거든요. 고객의 문제를 직접 보고, 어떤 기술이 필요한지 판단하고, 제품으로 만들고, 그 결과가 실제 비즈니스에 어떤 변화를 만드는지까지 경험할 수 있습니다.
특히 지금이 FDE라는 직무가 가장 빛을 발할 수 있는 시기라고 생각해요. AI가 코딩 속도를 무섭게 끌어올려 주고 있기 때문입니다. 이제 개발자의 경쟁력은 단순히 코드를 얼마나 빠르게 작성하느냐에만 있지 않아요. 무엇을 만들어야 하는지 뼈대를 잡고, 어떤 방식으로 풀어야 하는지 판단하고, 그것을 실제 비즈니스 성과로 연결하는 능력이 더 중요해지고 있습니다.
FDE는 바로 그 본질에 맞닿아 있는 포지션이에요. AI라는 강력한 도구로 얻은 속도를 고객의 문제를 해결하는 데 바로 쏟아부을 수 있으니까요. 문제를 발견하면 빠르게 만들고, 고객에게 보여주고, 피드백을 받아 다시 개선하는 과정을 짧은 사이클로 반복할 수 있습니다.
그래서 저는 FDE가 단순히 새로운 개발 직무 하나가 생긴 것이라고 생각하지 않아요. 기술을 무기로 현실의 비즈니스 문제를 직접 해결하고, 그 결과까지 만들어내는 개발자의 역할이 더 선명해진 것에 가깝다고 생각합니다.
내가 만든 기술이 실제 고객의 비즈니스를 바꾸는 경험을 해보고 싶고, 기술과 비즈니스를 함께 이해하는 사람으로 빠르게 성장하고 싶다면, FDE는 정말 강력한 커리어 트랙이라고 생각해요. 그런 경험을 원하신다면 주저하지 말고 포트원에 합류해보셨으면 좋겠습니다.
인터뷰를 마치고
인터뷰를 마치고 나오며, 포트원이 찾고 있는 FDE의 모습을 한층 더 공고히 할 수 있었습니다.
코드를 깊게 파고들고 더 좋은 소프트웨어를 만드는 즐거움은 여전히 개발자에게 중요한 가치입니다. 하지만 거기서 한 걸음 더 나아가 내가 만든 기술이 실제 고객의 문제를 해결하고, 그 변화를 바로 눈앞에서 확인하는 데서 더 큰 즐거움을 느끼는 개발자라면 FDE는 그 어떤 역할에서도 쉽게 얻기 어려운 경험과 성장의 기회를 얻을 수 있겠다는 생각이 들었습니다.
주영님의 표현을 빌리면, 그 순간은 정말 짜릿합니다. 그리고 그 짜릿함을 한 번 경험하면 "조금 더 해볼까?"라는 마음이 자연스럽게 생기고, 누가 시키지 않아도 더 깊게 파고들게 됩니다.
내가 만든 기술이 실제 고객의 비즈니스를 바꾸는 과정을 가까이에서 경험하고, 그 과정에서 기술과 비즈니스를 함께 성장시키고 싶다면 FDE는 개발자로서 한 단계 더 도약할 수 있는 더없이 소중한 기회가 될 것입니다.
실제 비즈니스를 바꾸는 순간을 직접 만들어보고 싶다면. 포트원의 FDE에 도전해보세요.
포트원 채용 포지션 확인하기
