본문으로 바로가기
리옵트 핸드북
리옵트 핸드북
FDE의 이해

정의와 확산

1. FDE의 정의2. 등장 배경과 확산3. 역할과 업무 범위4. 기업별 FDE

경계와 실제 업무

5. 인접 직무6. FDE와 SI7. 제품 기반과 운영 비용8. 프로젝트 수행9. AI 개발과 제품 개선

조직과 커리어

10. 책임과 권한11. 조직 운영과 성과12. 역량과 커리어13. 역할 정의서

마무리

14. 장단점과 전망

부록

검증 리포트업데이트 내역
핸드북›FDE의 이해›10. 책임과 권한

10. 책임과 권한

고객의 일정, 제품의 품질과 보안 요구가 충돌하는 상황을 통해 FDE의 책임과 결정권, 조직 안의 협의 구조를 설명한다.

글·검토 Eric Han · 리옵트 공동창업자·CTO

고객은 다음 주에 새 기능을 쓰겠다고 한다. 영업 담당자는 중요한 계약이 걸려 있다고 말한다. 제품팀은 공통 인증 기능의 결함을 먼저 고쳐야 한다고 판단한다. FDE는 고객의 요구를 알고 있고 구현도 맡고 있지만 어느 팀의 우선순위도 혼자 바꿀 수 없다.

이런 상황에서 “고객 성공을 끝까지 책임지라”는 말만으로는 무엇을 해야 할지 정하기 어렵다. 개발 순서를 바꿀 권한, 고객에게 범위 조정을 제안할 권한, 배포를 미룰 권한이 각각 누구에게 있는지에 따라 선택이 달라진다. 책임을 넓게 부여할수록 필요한 결정권과 협의 상대도 구체적이어야 한다.

고객 성과

고객이 기대하는 성공에는 여러 결과가 들어 있다. 기능이 정상 작동해야 하고, 현업 사용자가 실제로 써야 하며, 도입 목적에도 도움이 되어야 한다. 계약에 대한 만족과 이후의 구매 결정까지 연결될 수 있다.

FDE는 이 결과에 영향을 주지만 모두를 통제하지는 못한다. 고객이 교육에 참여할 직원을 배정하지 않으면 사용 정착이 늦어질 수 있다. 데이터 접근 승인이 나지 않으면 구현을 시작할 수 없다. 제품의 핵심 기능을 바꾸려면 다른 개발팀의 자원이 필요하다. 이런 의존 관계를 개인의 열정으로 해결할 수 있는 문제처럼 다루면 조직의 결정이 계속 미뤄진다.

그래서 프로젝트에서는 기술 구현의 완료, 고객 업무의 수용, 운영 인수를 나누어 설명할 필요가 있다. 각각을 판단하는 사람과 증거가 다르기 때문이다.

기술 판단과 업무 결정

가상의 환불 지원 시스템을 생각해 보자. 엔지니어는 특정 조건의 주문을 자동 환불하도록 구현할 수 있다. 하지만 자동 환불의 범위와 예외를 승인할 권한까지 자연스럽게 얻는 것은 아니다. 환불 정책에 책임을 지는 고객 담당자가 결정해야 한다.

반대로 고객이 원하는 정책을 설명했다고 기술적인 준비가 끝나는 것도 아니다. 중복 요청이 들어와도 환불이 한 번만 처리되는지, 실패했을 때 상태를 확인할 수 있는지, 수동 처리와 충돌하지 않는지 엔지니어가 검토해야 한다. 업무 책임자와 기술 책임자는 서로 다른 종류의 판단을 내리고 함께 배포 조건을 정한다.

FDE는 이 대화에서 중요한 역할을 한다. 업무의 선택이 시스템에 어떤 영향을 주는지 설명하고, 구현의 제약이 고객의 선택을 어떻게 제한하는지 알려준다. 필요한 결정이 무엇인지 드러내는 일이 구현만큼 중요해지는 순간이다.

의사결정과 조율

앞의 일정 충돌로 돌아가 보자. FDE는 모든 요구를 수용하겠다고 약속하는 대신 가능한 선택을 정리할 수 있다. 인증 결함을 먼저 수정하고 기능 출시를 미루거나, 위험한 경로를 제외한 좁은 범위로 시작하거나, 임시 운영 절차를 두는 방법이 있을 수 있다. 각 선택의 고객 영향과 개발 비용을 설명하면 책임자가 판단할 근거가 생긴다.

상위 책임자에게 결정을 요청하는 에스컬레이션은 이런 상황에서 필요하다. 현재 팀의 권한으로 풀 수 없는 문제를 올리되, 막혀 있다는 보고만 보내면 결정은 다시 늦어진다. 어떤 선택이 필요한지와 결정이 늦어질 때 무엇이 달라지는지를 함께 설명해야 한다.

결정할 일FDE가 제공하는 내용결정에 참여할 주체
업무 범위구현 가능성과 제외할 경우의 영향고객 업무 책임자
설계기술 대안과 유지·장애 비용지정된 기술 책임자
일정·약속 변경진행 상황과 범위 조정안고객·공급사의 프로젝트 책임자
보안 검토데이터 흐름과 접근·실행 범위보안 권한을 가진 담당자
운영 인수운영 절차와 남은 문제시스템을 이어받을 운영팀

이 분담은 프로젝트에 맞춰 정할 수 있다. 중요한 것은 역할 이름을 많이 적는 것보다 최종 결정을 누가 내리는지 참여자들이 같은 답을 하는가다.

조직 소속

FDE를 엔지니어링 조직에 둘지 사업 조직에 둘지는 자주 나오는 고민이다. 엔지니어링 조직에 있으면 공통 설계와 코드 리뷰에 접근하기 쉬울 수 있다. 사업 조직에 있으면 고객의 의사결정과 계약 상황을 빨리 알 수 있다. 어느 쪽이든 빠지는 연결을 보완해야 한다.

개발팀 소속이어도 고객에게 이미 약속된 기능을 뒤늦게 전달받는다면 범위를 통제하기 어렵다. 사업팀 소속이어도 기술 검토와 배포 기준이 잘 마련되어 있다면 품질을 유지할 수 있다. 조직도의 위치와 함께 실제로 누가 일을 배정하고 기술적 이견을 어떻게 처리하는지 살펴야 한다.

핵심 요약

고객 프로젝트의 결과를 책임지려면 필요한 결정을 내리거나 결정권자에게 접근할 수 있어야 한다. FDE가 모든 승인을 맡을 필요는 없지만 업무·기술·보안·운영의 판단이 어디에서 이루어지는지는 명확해야 한다. 이 구조가 없으면 조직이 내려야 할 결정을 개인의 노력으로 떠안게 된다.

관련 문서

7. 제품 기반과 운영 비용

공통 제품 없이 에이전트와 SaaS, 관리자 화면을 조합할 때 생기는 비용과 교육·운영 부담을 살펴보고 지속 가능한 구축 방식을 비교한다.

11. 조직 운영과 성과

FDE 인력을 배치할 기준과 공통 개발에 필요한 시간을 살펴보고 고객 가치, 품질, 운영 부담을 함께 평가하는 방법을 설명한다.

On this page

고객 성과기술 판단과 업무 결정의사결정과 조율조직 소속핵심 요약