6. FDE와 SI
FDE와 시스템 통합을 같은 범주로 비교할 때 생기는 혼란을 풀고 고객별 개발과 공통 제품의 관계가 실제로 어떻게 달라지는지 살펴본다.
글·검토 Eric Han · 리옵트 공동창업자·CTO
FDE를 처음 접하면 익숙한 일이 떠오를 수 있다. 고객을 만나 요구사항을 듣고, 기존 시스템을 연결하고, 기능을 개발한 뒤 운영팀에 넘긴다. 시스템 통합 프로젝트에서도 해온 일이다. 그렇다면 FDE는 SI에 새 이름을 붙인 것일까.
이 질문에는 비교 대상부터 살펴볼 필요가 있다. FDE는 사람의 역할이나 팀이 일하는 방식을 가리킨다. SI(System Integration)는 여러 시스템을 연결하는 활동과 이를 수행하는 사업을 가리킨다. FDE가 시스템 통합을 수행할 수 있고, SI 프로젝트에 참여한 엔지니어가 FDE와 비슷하게 일할 수도 있다. 둘의 범위는 겹친다.
프로젝트 조건
두 팀이 각각 고객의 주문 시스템과 재고 시스템을 연결한다고 가정하자. 둘 다 API를 개발하고 데이터 형식을 맞추며 장애에 대비한다. 작업 목록만 놓고 보면 큰 차이가 없을 수 있다.
그러나 한 팀은 합의된 명세를 구현하고 고객의 검수를 받으면 프로젝트가 끝난다. 다른 팀은 자사 플랫폼의 도입을 돕고 있으며, 고객별 연결 기능을 만든 경험을 다음 버전의 제품에 반영하려 한다. 같은 코드를 작성해도 완료를 판단하는 기준과 이후에 코드를 유지하는 이유가 다르다.
실제 계약은 이보다 다양하다. SI 프로젝트에도 장기 운영과 공통 자산 개발이 포함될 수 있고, 제품사 FDE도 고객별 납품에 집중할 수 있다. 따라서 회사의 업종을 아는 것만으로 두 팀을 위 예시에 배정할 수는 없다. 실제로 무엇을 약속했는지 알아야 한다.
제품 개선과 재사용
FDE를 설명할 때 자주 강조되는 특징은 현장의 경험을 제품에 반영한다는 것이다. 고객이 무엇을 어려워하는지 직접 본 엔지니어가 제품팀에 구체적인 개선안을 전달할 수 있다. 그 경험이 공통 기능으로 이어지면 다음 고객에게 같은 작업을 반복할 필요가 줄어든다.
하지만 이 연결은 직함이 보장하지 않는다. 제품팀에 제안할 통로가 없거나 고객 프로젝트 일정 때문에 공통화 작업을 할 수 없다면 결과물은 고객별 코드로만 남는다. 반대로 SI 회사가 커넥터와 배포 도구를 공통으로 관리하고 후속 프로젝트에 사용한다면 상당한 개발 경험이 조직 안에 축적될 수 있다.
재사용의 형태도 구분할 필요가 있다. 그대로 다시 배포할 수 있는 코드, 특정 산업의 데이터에 대한 이해, 장애를 해결하는 절차는 서로 다른 자산이다. 다음 프로젝트에서 도움이 된다는 공통점은 있지만 유지 비용과 사용 조건은 다르다.
요구 변경
고객은 처음부터 필요한 기능을 모두 알지 못한다. 개발 중에 발견한 사실이 요구를 바꾸는 일이 생긴다. 이때 팀이 어떻게 반응할 수 있는지는 계약과 권한의 영향을 받는다.
범위 변경을 승인받는 데 오랜 시간이 걸리면 엔지니어는 더 적합한 해결책을 알아도 원래 명세를 수행해야 할 수 있다. 반대로 목표와 예산 안에서 구현 범위를 조정할 수 있다면 고객과 실험하며 해법을 좁혀갈 수 있다. 후자의 방식이 불확실한 문제에 적합할 수 있지만 고객에게는 비용과 일정의 예측 가능성도 중요하다. 무엇을 고정하고 무엇을 조정할지 합의해야 한다.
이 문제를 FDE는 유연하고 SI는 경직되어 있다는 식으로 설명하면 실제 원인이 가려진다. 유연하게 일할 수 있는 범위는 계약, 고객과의 신뢰, 의사결정 구조에서 나온다.
비교 기준
| 살펴볼 부분 | 실제로 달라질 수 있는 조건 |
|---|---|
| 프로젝트의 목적 | 명세 이행, 제품 도입, 문제 탐색 중 무엇을 맡는가 |
| 변경 | 새로운 사실이 나오면 누가 범위와 일정을 바꾸는가 |
| 코드 | 고객별 코드와 공통 자산을 누가 소유하고 유지하는가 |
| 제품 연결 | 현장의 개선 제안을 받아 결정할 팀이 있는가 |
| 비용 | 개발 이후의 안정화·지원·공통화에 자원이 배정되는가 |
| 종료 | 고객이 무엇을 확인하고 어떤 팀이 운영을 넘겨받는가 |
이 질문들은 FDE와 SI 중 하나를 고르기 위한 분류표보다 프로젝트의 구조를 이해하는 데 유용하다. 법적인 권리와 의무는 실제 계약에서 정해지며 직무명으로 추정할 수 없다.
업무와 평가 방식
기존 고객 개발팀의 이름을 FDE팀으로 바꾼다고 제품 기여가 늘지는 않는다. 여전히 모든 시간이 고객별 납품에 배정되고 같은 방식으로 평가된다면 업무도 비슷하게 유지된다. 현장 경험을 제품 개선에 활용하려면 그 일을 맡을 사람, 함께 검토할 제품팀, 개발할 시간이 필요하다.
고객별 개발 자체를 실패로 볼 이유도 없다. 특정 고객의 요구를 해결하는 가치가 충분할 수 있다. 다만 고객별 사업을 하면서 공통 제품처럼 확장할 수 있다고 기대하면 비용과 인력 계획이 어긋난다. FDE 논의에서 중요한 것은 자신이 어떤 사업과 개발 방식을 운영하고 있는지 정확히 아는 일이다.
핵심 요약
FDE와 SI는 서로 배타적인 범주가 아니다. 같은 시스템 통합 작업도 목적, 계약, 제품과의 연결, 유지 책임에 따라 다른 경험과 결과를 만든다. 명칭보다 이 조건을 비교해야 조직이 기대하는 역할과 실제 업무의 차이를 이해할 수 있다.