FDE는 SI 파견과무엇이 다른가?

01FDE는 SI 파견과 무엇이 다른가?

둘 다 고객사에 상주하지만, SI 파견 인력은 확정된 명세를 정해진 기간에 납품하는 사람이고, FDE는 명세가 없는 곳에서 풀 문제를 찾아 고객의 업무 결과가 날 때까지 책임지는 사람입니다. 그리고 FDE가 현장에서 만든 것은 그 고객 한 곳에 남지 않고 본사 제품으로 돌아갑니다. 이 마지막 차이가 FDE라는 직무가 생긴 이유입니다.

아래 2절은 왜 둘이 닮아 보이는지를, 3~6절은 표의 아래 네 줄을 하나씩 다룹니다.

02왜 FDE를 파견으로 오해하나?

고객사에 상주하며 그 회사만을 위한 개발을 한다는 겉모습이 SI 파견과 똑같기 때문입니다. 한국에서 「고객사에 들어가 개발하는 사람」이라면 대개 SI 상주 인력을 떠올립니다. 그 경험에 비추면 FDE는 이름만 그럴듯한 파견으로 보이기 쉽습니다.

실제로 이름의 역사도 그 의심을 거듭니다. 투자사 a16z의 글에 따르면, 2011년 팔란티어는 솔루션 엔지니어와 통합 엔지니어에게 「포워드 디플로이드 엔지니어」라는 새 직함을 붙였고, 이들을 특수부대 이름을 따 「Delta」라고도 불렀습니다. 그 글은 이 일을 직함을 바꿔 값을 올린 「직함 차익」이라고 꼬집기도 합니다 [3].

그런데 팔란티어가 바꾼 것은 이름만이 아니었습니다. 누가 어디에서 근무하느냐는 그대로 두고, 무엇을 책임지느냐와 만든 것이 어디로 가느냐를 바꿨습니다. 차이는 근무하는 자리가 아니라 그 두 곳에 있습니다.

03명세서에서 출발하나, 문제에서 출발하나?

SI는 무엇을 만들지 정해진 뒤에 시작하고, FDE는 무엇을 만들지 정하는 일부터 시작합니다. SI 사업은 과업지시서와 요구사항 정의서가 확정되어야 견적과 일정이 나옵니다. 도중에 요구가 바뀌면 변경 요청을 거치고 추가 비용이 붙습니다. 명세 밖의 일은 원칙적으로 하지 않는 일입니다.

FDE에게는 그 명세 밖이 본업입니다. 고객은 실제로 돌아가는 소프트웨어를 보기 전까지 자신에게 무엇이 필요한지 모르는 경우가 많습니다. 팔란티어에서 이 모델을 일군 초기 임원 Bob McGrew는 FDE를 이렇게 설명합니다.

그 틈은 명세서에 적혀 있지 않습니다. 현업 사람들과 함께 일을 들여다보며 찾아야 합니다. 그래서 팔란티어는 엔지니어를 혼자 보내지 않았습니다. 고객의 업무 현장에 박혀 무엇이 문제인지 규명하는 분석가 Echo와, 코딩을 아주 잘하는 소프트웨어 엔지니어 Delta를 짝지어 보냈습니다 [2]. 문제를 정의하는 사람과 푸는 사람이 같은 현장에 있는 것 — 명세서가 하던 일을 사람의 짝이 대신하는 구조입니다.

04무엇으로 성공을 재나?

SI의 성공은 투입 공수와 납기, 검수 통과로 재고, FDE의 성공은 고객 업무가 실제로 나아졌는지로 잽니다. SI 계약은 대개 몇 명이 몇 달 일했는지(M/M)로 값을 매기고, 명세대로 동작하는지를 검수해 끝납니다. 시스템이 명세대로 돌아가기만 하면 현업이 그것을 쓰든 안 쓰든 계약은 끝납니다.

FDE에게 묻는 것은 다릅니다. 채용 플랫폼 Dice의 대표는 FDE에게 요구되는 역량을 이렇게 요약했습니다.

「명세대로 만들었는가」가 아니라 「결과가 났는가」입니다. 그래서 FDE는 명세에 없던 문제를 발견하면 그것을 피하지 않고 풀어야 할 대상으로 삼습니다. 성공 기준이 다르면 같은 문제 앞에서 하는 행동이 정반대가 됩니다.

05현장에서 만든 것은 어디로 가나?

SI가 만든 것은 그 고객 한 곳에 남고, FDE가 만든 것은 검증을 거쳐 본사 제품의 공통 기능이 되어 다음 고객에게 갑니다. 이것이 SI와 가장 크게 다른 점이며, FDE라는 직무가 생긴 이유입니다. McGrew는 이 흐름을 길에 빗댑니다 [2].

SI에는 이 두 번째 칸이 없습니다. 납품물은 그 고객의 것이고, 다음 고객에게서는 비슷한 일을 처음부터 다시 합니다. 그래서 SI는 인력을 더 넣어야 매출이 늘고, 고객마다 다른 시스템이 쌓입니다. FDE를 둔 회사는 반대로 현장에 나갈 때마다 제품이 넓어집니다. 한 고객에게서 여러 기능을 찾아내는 일(FDE)과, 한 기능을 여러 고객에게 통하게 하는 일(본사 제품팀)이 맞물려 돌아가는 구조입니다.

06떠날 때 무엇이 남나?

SI가 떠나면 시스템과 유지보수 계약이 남고, FDE가 떠나면 고객이 그 시스템을 스스로 고치고 넓혀 갈 힘이 남아야 합니다. FDE는 영구히 머무는 사람이 아닙니다. 만든 것을 고객 쪽 사람이 이어받아 유지하고 확장할 수 있도록 넘겨주는 데까지가 FDE의 일입니다.

SI에서는 반대가 자연스럽습니다. 시스템이 왜 그렇게 생겼는지를 아는 사람이 공급사에 있으면, 고치고 늘릴 때마다 다시 그 회사를 부르게 됩니다. 「그 사람 없으면 아무도 못 고친다」는 상태가 공급사에게는 다음 계약이 되는 구조입니다. FDE의 성공 기준이 고객의 업무 결과인 이상, 이 상태는 FDE에게는 실패에 가깝습니다.

그래서 FDE를 쓰는 회사는 처음부터 누가 이어받을지를 정해 두는 편이 좋습니다. 우리 직원을 그 이어받을 사람으로 기르는 법은 「FDE, 외주로 구할까 우리 사람을 기를까?」에 정리했습니다.

07우리 회사에 온 FDE, SI처럼 일하고 있지 않나?

명칭이 아니라 일하는 방식을 보면 압니다 — 문제에서 출발했는지, 업무 결과로 재는지, 만든 것이 제품으로 돌아가는지, 우리 사람이 이어받을 수 있는지 네 가지를 물어보십시오. 「FDE」라는 이름을 단 사람이 와도, 일하는 방식이 SI라면 결과도 SI와 같습니다.

넷 가운데 첫째와 넷째는 회사 쪽에서도 거들 수 있습니다. 명세서 대신 출발점이 될 업무 그림 — 활동마다 무엇을 받아(입력) 무엇을 내놓고(산출), 어떤 규칙을 따르고(통제), 누가·무엇으로 하는지(수단) — 를 함께 그려 두면, FDE는 그 위에서 문제를 찾고 우리 사람은 그 그림으로 일을 이어받습니다. 이 네 칸은 국제표준 업무 모델링 언어 IDEF0의 기본 틀입니다 [4]. FDE가 고객 업무를 처음 그리는 순서는 「FDE에게 필요한 「업무를 읽는 눈」」에 있습니다.

08자주 묻는 질문

FDE도 결국 이름만 바꾼 SI 아닌가?

돌아갈 제품이 없고 납품으로 계약이 끝난다면 이름만 바꾼 SI와 같습니다. FDE가 SI와 다른 것은 현장 작업이 본사 제품으로 흡수되는 구조(5절)와, 고객의 업무 결과로 성공을 재는 계약(4절)이 있을 때뿐입니다. 이름이 아니라 이 두 가지를 확인하십시오.

FDE는 고객사의 업무 지시를 받나?

아닙니다. FDE는 솔루션을 가진 회사 소속으로 고객 현장에 나가 있을 뿐, 지휘는 자기 회사에서 받습니다. 무엇을 만들지는 고객 담당자의 지시가 아니라, 고객과 함께 정의한 문제에서 나옵니다.

FDE와 솔루션 엔지니어(SE)는 무엇이 다른가?

솔루션 엔지니어는 계약 전에 데모와 개념 검증으로 판매를 돕고, FDE는 계약 뒤 고객 현장에서 실제로 돌아가는 프로그램을 만들어 결과를 냅니다. 자세한 비교는 「FDE에게 필요한 「업무를 읽는 눈」」의 자주 묻는 질문에 있습니다.

SI 경험은 FDE가 되는 데 도움이 되나?

고객 현장과 레거시 시스템을 겪어 본 경험은 큰 자산이지만, 명세를 받아 구현하던 습관에서 문제를 스스로 정의하는 습관으로 넘어가야 합니다. 그 넘어가는 자리에 필요한 것이 고객의 일을 읽는 눈입니다.