3. 역할과 업무 범위
두 가지 가상 프로젝트를 비교하면서 FDE의 문제 발견, 개발 범위, 운영 참여와 제품 기여가 조직에 따라 어떻게 달라지는지 설명한다.
글·검토 Eric Han · 리옵트 공동창업자·CTO
FDE 채용 공고에는 고객 소통, 빠른 구현, 문제 해결 같은 표현이 자주 등장한다. 이 단어들만 읽으면 회사가 달라도 비슷한 일을 하는 것처럼 보인다. 그러나 실제로는 새 시스템을 설계하는 일에 대부분의 시간을 쓰는 사람도 있고, 이미 만들어진 제품을 여러 고객에게 적용하는 사람이 있을 수 있다.
두 가지 가상 상황을 비교해 보자. 첫 번째 회사는 제조업 고객에게 분석 플랫폼을 제공한다. FDE는 공장 담당자와 함께 불량 원인을 조사하고, 데이터 수집 방식을 바꾸고, 분석 애플리케이션을 만든다. 초기 안정화가 끝나면 고객의 데이터팀이 운영을 맡는다.
두 번째 회사는 고객지원 제품을 판매한다. FDE는 여러 고객의 CRM을 연결하고, 기존 상담 절차에 맞춰 기능을 설정한다. 출시 이후에도 고객별 연동 오류와 변경 요청을 계속 맡는다. 새로운 문제를 발견하기보다는 정해진 제품을 다양한 환경에서 안정적으로 작동시키는 비중이 크다.
두 역할 모두 고객과 대화하고 코드를 작성한다. 그러나 첫 번째 역할에서 쌓이는 경험과 두 번째 역할에서 쌓이는 경험은 같지 않다.
프로젝트 참여 시점
첫 번째 차이는 엔지니어가 프로젝트에 참여하는 시점이다. 고객이 해결할 문제를 찾는 단계부터 들어가면 업무를 관찰하고 대안을 시험하는 일이 많다. 해결할 문제와 제품이 이미 정해져 있다면 연동 범위와 배포 조건을 구체화하는 일이 중심이 된다.
문제를 처음부터 다루는 역할에는 자유가 있지만 판단의 부담도 있다. 불량률을 낮추겠다는 목표가 있어도 데이터가 충분한지, 공정 변경이 가능한지, 소프트웨어로 해결할 수 있는지부터 알아봐야 한다. 반대로 범위가 정해진 도입 프로젝트에도 어려움은 있다. 여러 고객 환경의 차이를 흡수하면서 품질과 일정을 유지해야 하기 때문이다.
어느 쪽을 맡는지에 따라 필요한 도메인 지식, 실험 경험, 프로젝트 운영 능력의 비중이 달라진다.
개발 범위와 운영 기간
코드를 작성한다는 사실만으로 구현의 깊이를 알기는 어렵다. 설정 파일을 수정하는 작업과 여러 시스템의 장애를 고려해 새로운 서비스를 설계하는 작업은 요구하는 판단이 다르다. 고객별 코드가 어느 저장소에 남고, 누가 리뷰하며, 다음 변경을 누가 맡는지에 그 차이가 드러난다.
운영 기간도 중요하다. 초기 배포까지 맡는 엔지니어와 수개월 뒤의 장애까지 처리하는 엔지니어는 설계를 바라보는 관점이 달라질 수 있다. 인수할 운영팀이 명확하면 역할을 짧게 가져갈 수 있다. 운영팀이 없는데 프로젝트만 끝났다고 선언하면 고객은 다시 원래 개발자를 찾게 된다.
범위가 넓다는 이유만으로 더 좋은 역할인 것은 아니다. 긴 운영 책임은 시스템을 깊이 이해할 기회가 되지만, 수많은 고객의 작은 요청을 혼자 맡게 되면 새 개발을 할 시간이 사라질 수도 있다.
제품 기여
한 고객을 위해 만든 기능이 다른 고객에게도 필요하다면 제품팀에 제안할 수 있다. 여러 프로젝트에서 사용한 연동 코드를 공통 라이브러리로 만들 수도 있다. 이런 작업은 다음 고객을 더 쉽게 지원할 가능성을 만든다.
하지만 재사용을 기대하려면 유지할 조직이 있어야 한다. 공통 모듈이라는 이름으로 코드를 옮긴 뒤에도 작성자 한 명만 수정할 수 있다면 사람에 대한 의존은 그대로다. 제품팀과 협업한다는 말도 회의에 참여하는지, 공통 코드를 직접 수정하는지에 따라 의미가 다르다.
역할 비교 기준
앞의 차이를 정리하면 다음과 같다. 역할의 범위를 묘사하는 기준이며 점수를 합산해 순위를 매기는 표는 아니다.
| 기준 | 비교할 내용 |
|---|---|
| 문제 발견 | 정해진 요구를 받는가, 해결할 문제를 찾는 단계부터 참여하는가 |
| 개발 범위 | 기존 기능의 설정·연동이 중심인가, 새로운 시스템도 설계하는가 |
| 운영 참여 | 배포 이후 어느 시점까지 유지와 장애 대응을 맡는가 |
| 제품 기여 | 고객별 해결이 공통 기능이나 도구의 개선으로 이어지는가 |
| 영업 참여 | 계약 전 기술 검증이나 새로운 도입 기회 발굴에 얼마나 관여하는가 |
| 고객과의 협업 | 보고를 받는가, 실제 사용자와 함께 구현 결과를 시험하는가 |
프로젝트 경험
역할을 알아보려면 최근 프로젝트가 어떻게 진행됐는지 듣는 편이 도움이 된다. 최초 요청이 개발 과정에서 바뀌었는지, 담당자가 어떤 코드를 남겼는지, 배포 후 누가 운영했는지를 이어서 들으면 직무 설명의 추상적인 문구가 구체화된다.
‘처음부터 끝까지 책임진다’는 표현도 이 과정에서 의미가 드러난다. 한 조직의 끝은 첫 배포일 수 있고, 다른 조직의 끝은 고객이 스스로 운영하는 시점일 수 있다. 같은 말을 쓰면서 다른 기대를 갖는 일이 채용과 협업에서 생기는 혼란의 출발점이다.
핵심 요약
FDE 역할의 차이는 프로젝트에 들어가는 시점, 만드는 시스템의 범위, 운영 기간과 제품에 기여하는 방식에서 나타난다. 역할을 선택하거나 설계할 때는 직함의 인상보다 실제 프로젝트의 시작과 끝을 이해하는 것이 중요하다.