5. 인접 직무
한 고객 프로젝트에 참여하는 개발, 기술 영업, 아키텍처와 고객 성공 담당자의 일을 따라 FDE와 인접 직무의 경계를 설명한다.
글·검토 Eric Han · 리옵트 공동창업자·CTO
고객과 대화하는 개발자는 많다. 소프트웨어 엔지니어도 사용자 인터뷰에 참여하고, 기술 영업 담당자도 검증용 코드를 작성한다. 그래서 고객을 만나는지, 코드를 쓰는지만으로 FDE를 구별하기는 어렵다. 한 프로젝트에서 어떤 결과를 맡고 누구에게 일을 넘기는지를 보면 차이가 더 잘 드러난다.
기술 검증과 구축
가상의 고객지원 제품 도입을 생각해 보자. 고객은 기존 CRM에 있는 상담 이력을 새 제품에서 조회하고 싶어 한다. 구매 검토 단계에서 기술 영업 담당자는 제품이 요구를 충족할 수 있는지 보여준다. 솔루션 아키텍트는 CRM과의 연결 구조, 인증 방식, 데이터 흐름을 설계한다. 작은 샘플로 조회가 가능하다는 사실을 확인하면 구매 결정에 필요한 불확실성이 줄어든다.
도입이 시작되면 질문의 성격이 달라진다. 전체 상담 이력을 옮기는 데 얼마나 걸리는가. 이전 데이터의 형식이 맞지 않으면 어떻게 처리하는가. 상담원이 퇴사하거나 부서를 옮기면 접근 권한은 언제 갱신되는가. 검증용 연결이 작동했다는 사실만으로는 이런 질문에 답할 수 없다.
FDE가 참여하는 조직에서는 이 구간의 개발을 맡을 수 있다. 초기 설계를 고객의 실제 환경에서 구현하고, 드러나는 제약에 맞춰 수정한다. 기술 영업이나 아키텍트도 같은 과정에 참여할 수 있으므로 경계를 날짜 하나로 나눌 수는 없다. 다만 구매 결정을 돕는 검증과 지속적으로 운영할 시스템을 완성하는 책임은 구분할 수 있다.
제품팀과의 협업
고객의 환경을 조사하던 중 제품의 인증 기능에 문제가 발견됐다고 하자. 모든 고객에게 영향을 주는 결함이라면 제품팀에서 수정하는 편이 타당하다. 반면 고객이 자체적으로 운영하는 오래된 CRM의 응답 형식을 변환하는 코드는 해당 프로젝트에서 관리할 수 있다.
실제 경계는 이렇게 깔끔하지 않을 때가 많다. 첫 고객의 요구만 보면 특수한 연동처럼 보이지만, 비슷한 요구가 이어지면 제품 기능으로 다룰 이유가 생긴다. FDE는 현장의 문제와 임시 해결책을 알고 있고, 제품 엔지니어는 공통 구조와 유지 비용을 알고 있다. 둘이 함께 설계해야 고객의 시급한 요구와 제품의 장기적인 품질을 조정할 수 있다.
FDE가 만든 코드를 제품팀이 무조건 받아야 하는 것도, 제품의 로드맵이 정해질 때까지 고객이 기다려야 하는 것도 아니다. 임시 구현의 범위와 나중에 없앨 조건을 합의하면 두 팀이 서로 다른 시간표로 일할 수 있다.
도입 후 지원
배포가 끝나면 고객 성공 담당자는 사용자가 기능을 활용하는지, 도입 목적을 달성하는지 살펴볼 수 있다. 기술 계정 담당자는 지속적인 기술 문의와 지원을 조율할 수 있다. 여기서 FDE가 빠질 수 있는지는 코드와 운영을 이어받을 주체가 있는지에 달려 있다.
고객이 “작동하지 않는다”고 연락했을 때 문의를 접수할 사람과 오류를 수정할 사람은 다를 수 있다. 운영 안내서와 담당자가 정해져 있지 않으면 가장 잘 아는 원래 개발자에게 모든 문의가 돌아간다. FDE의 역할을 구체화하려면 개발 범위뿐 아니라 이런 종료 이후의 관계도 설명해야 한다.
직무 비교
아래 표는 각 역할이 중심적으로 맡을 수 있는 일을 정리한 것이다. 실제 조직에서는 한 사람이 여러 역할을 겸하거나 같은 일을 다른 이름으로 부를 수 있다.
| 역할 | 주로 설명하는 책임 | FDE와 함께 일하는 지점 |
|---|---|---|
| 소프트웨어 엔지니어 | 제품과 시스템의 개발·유지 | 공통 기능, 설계와 코드 리뷰 |
| 솔루션 아키텍트 | 고객 환경에 맞는 기술 구조 설계 | 제약 분석과 구현 대안 |
| 기술 영업 담당자 | 구매 전 기술 검증과 설명 | 가능성 검증, 고객에게 한 약속의 인계 |
| 구현 엔지니어 | 제품의 도입·설정·통합 | 연동과 배포, 고객별 변경 |
| 기술 계정 담당자 | 지속적인 기술 관계와 지원 조율 | 장애·변경 요청의 처리 경로 |
| 고객 성공 담당자 | 사용 정착과 고객의 도입 목적 달성 | 실제 사용의 문제와 추가 개선 |
| Deployment Lead | 일정·의존 관계·고객 협의 조율 | 구현 계획과 프로젝트 전체의 진행 |
구현 엔지니어와 FDE의 업무는 특히 많이 겹칠 수 있다. 요구를 얼마나 새로 정의하는지, 어느 정도의 새 개발을 수행하는지, 제품팀과 어떻게 연결되는지에 따라 차이가 생긴다. 직무명만으로 어느 역할의 기술 수준이 더 높다고 말하기는 어렵다.
인수인계
문제는 여러 역할이 참여한다는 사실보다 그 사이에서 정보가 사라질 때 생긴다. 영업 단계에서 제한된 표본으로 검증한 기능을 고객이 모든 데이터에 대한 보증으로 이해할 수 있다. 제품팀이 고객별 임시 코드를 알고 있다고 생각했지만 실제 유지 책임은 정해지지 않았을 수 있다.
이런 혼선을 줄이는 데 필요한 것은 긴 문서보다 분명한 설명이다. 무엇을 확인했고 무엇은 아직 가정인지, 고객에게 어떤 약속을 했는지, 남은 문제를 누가 맡을지가 이어져야 한다. FDE는 이 연결의 여러 지점에 참여하지만 조직 전체의 빈틈을 혼자 메울 수는 없다.
핵심 요약
인접 직무와 FDE는 활동이 상당 부분 겹친다. 차이를 이해하려면 각 역할이 내리는 결정, 남기는 코드와 문서, 다음 담당자에게 넘기는 조건을 함께 봐야 한다. 고객을 만나는 빈도나 코딩 시간만으로는 이 관계를 충분히 설명할 수 없다.