13. 역할 정의서

FDE라는 직무를 이해한 뒤에도 조직마다 내려야 할 결정은 남는다. 누구를 지원할 것인지, 어떤 프로젝트에 들어갈 것인지, 어디까지 개발하고 운영할 것인지다. 좋은 인재를 찾았다는 사실만으로 이 결정이 대신 이루어지지는 않는다.

채용 공고를 먼저 쓰면 필요한 역량을 계속 덧붙이기 쉽다. 개발을 잘하고, 고객을 이해하고, 영업을 돕고, 일정을 관리하고, 운영도 맡을 사람을 찾게 된다. 그 전에 조직이 맡길 일을 정리하면 어떤 역량이 꼭 필요한지와 다른 팀이 맡아야 할 일이 드러난다.

역할의 목적

“고객 성공을 위해 일한다”는 목적은 너무 넓다. 왜 기존 제품팀이나 구현 지원팀으로 해결하기 어려운지 설명할 수 있어야 한다. 예를 들어 다음처럼 쓸 수 있다.

우리 제품을 처음 적용하는 고객은 업무 규칙과 데이터 구조가 서로 달라 표준 도입 절차를 바로 사용할 수 없다. FDE는 초기 고객과 함께 적용 방법을 찾고 구현하며, 반복되는 개발을 공통 도구와 제품 개선으로 이어간다.

이 문장에는 고객, 해결할 어려움과 조직이 기대하는 결과가 들어 있다. 모든 고객의 문의를 처리하는 역할과도 차이가 드러난다. 실제 조직이 필요한 일이 표준 연동의 빠른 수행이라면 그에 맞게 목적을 바꾸면 된다.

역할 정의서 양식

앞선 장의 비교 기준을 실제 조직에 적용할 때 사용할 수 있는 양식이다. 빈칸을 채우다가 다른 팀과 의견이 갈리는 부분이 있다면 그 지점이 먼저 합의할 내용이다.

이 문서는 특정 직무의 표준을 만들기 위한 것이 아니다. 함께 일할 사람들이 같은 기대를 갖도록 조직의 선택을 적는 문서다.

작성 예시

다음은 앞의 문서 검토 사례를 바탕으로 구성한 가상 조직의 예시다.

목적과 대상

이 조직의 FDE는 표준 도입 절차가 아직 없는 고객을 지원한다. 고객의 문서 검토 과정을 조사하고, 제품으로 해결할 범위를 정하고, 필요한 연동과 화면을 개발한다. 여러 고객에게 반복되는 요구는 제품팀과 함께 검토한다.

모든 신규 고객에게 자동으로 배정하지는 않는다. 기존 기능과 안내서로 도입할 수 있는 고객은 구현 지원팀이 맡는다. 새로운 업무 규칙이나 연동 방식 때문에 적용 방법을 찾아야 하는 프로젝트에 FDE가 참여한다.

착수 조건

고객 측에 업무 범위와 결과를 판단할 책임자가 있어야 한다. 대표 문서에 접근할 수 있는 경로와 검토를 도와줄 사용자가 필요하다. 영업 담당자는 계약 전 검증한 내용과 아직 확인하지 않은 가정을 FDE에게 전달한다.

이 조건이 준비되지 않았다면 전체 개발 일정을 약속하기 어렵다. 먼저 접근 권한과 자료를 확보하는 일을 프로젝트의 초기 범위로 정한다.

개발과 결정권

FDE는 합의된 범위 안에서 구현 순서와 기술 대안을 제안하고 개발한다. 제품 본체의 변경은 제품팀의 리뷰와 배포 절차를 따른다. 고객별 연동은 지정된 저장소에서 관리하고 유지 담당자를 정한다.

업무 정책과 보안 예외는 해당 권한을 가진 담당자가 승인한다. 고객에게 약속한 일정이나 범위를 바꿔야 하면 프로젝트 책임자와 협의한다. FDE는 선택지와 영향을 설명하지만 혼자 모든 약속을 바꾸지는 않는다.

제품 개선과 운영 인수

프로젝트에서 반복될 가능성이 있는 요구는 사용자 상황, 실패 원인과 임시 해결을 묶어 제품팀에 전달한다. 제품팀은 공통 기능으로 개발할지, 도구로 유지할지, 고객별 구현으로 남길지 결정한다. 결정 전까지의 유지 책임도 함께 정한다.

배포 이후에는 고객 운영팀과 초기 안정화를 진행한다. 고객이 문서를 갱신하고 오류를 확인하며 지원을 요청할 수 있게 되면 운영을 넘긴다. 이후 요청은 지원 절차로 접수하고 새 개발이 필요하면 별도 우선순위로 다룬다.

정의서 검토

고객 성과를 책임지게 하면서 실제 사용자와 대화할 기회를 주지 않을 수 있다. 제품 기여를 기대하면서 공통화 작업에 시간을 배정하지 않을 수도 있다. 운영 인계를 요구하지만 받을 팀이 없는 경우도 있다. 이런 모순은 채용 요건을 높여서 해결하기 어렵다.

정의서를 검토할 때는 각 책임에 필요한 접근 권한, 시간과 협업 상대가 있는지 연결해 보면 된다. ‘다른 팀의 일’이라고 적은 항목 역시 실제로 받을 사람이 동의해야 한다. 문서에만 넘겨놓으면 프로젝트가 시작된 뒤 다시 FDE의 일이 된다.

역할 조정

처음 만든 역할 정의는 가설을 포함한다. 예상보다 고객 데이터 정리에 시간이 많이 들 수 있고, 제품팀과의 협의가 생각보다 자주 필요할 수 있다. 프로젝트가 끝나면 어떤 일을 했고 어디에서 결정이 늦어졌는지 돌아보며 범위를 조정한다.

이 과정에서 FDE가 맡을 일이 줄어들 수도 있다. 반복되는 도입은 다른 팀으로 옮기고, 더 불확실한 문제에 집중할 수 있다. 역할 정의서의 목적은 처음 정한 범위를 고정하는 데 있지 않다. 조직이 실제로 필요한 개발과 책임에 맞게 역할을 유지하는 데 있다.

핵심 요약

우리 조직의 FDE는 목적, 실제 업무, 결정권과 종료 조건을 함께 적을 때 구체화된다. 정의서는 채용뿐 아니라 다른 팀과의 협업에 쓰이며, 첫 프로젝트 이후의 경험으로 수정해야 한다. 어떤 이름을 붙이든 책임을 맡길 수 있는 조건이 갖추어져야 역할이 작동한다.