FDE와 SI의 차이는 요구사항을 누가 쓰느냐

FDE란 무엇인가

FDE는 Forward Deployed Engineer의 줄임말입니다. 직역하면 전방에 배치된 엔지니어입니다. 전방이라는 말은 군대 용어에서 왔습니다. 본부 건물에서 제품을 만드는 사람이 아니라, 고객 회사 안으로 들어가 그 회사의 데이터와 회의와 막히는 자리에 앉아 코드를 짜는 사람입니다.

이 이름을 만든 곳은 팔란티어입니다. 팔란티어 안에서는 롤이 둘로 나뉩니다. Forward Deployed Software Engineer(FDSE)는 고객 환경에 제품을 붙이고 배포하는 개발을 맡습니다. Deployment Strategist는 그 앞에서 문제를 고르고 이해관계를 맞춥니다. 한국에서 요즘 FDE라고 부르는 자리는 이 둘을 한 사람에게 묶는 경우가 많습니다.

토스, AWS, 마이크로소프트, 구글, 오픈AI처럼 자사 솔루션을 고객 안에 심는 회사가 이 자리를 뽑습니다. 이름이 멋있어서가 아닙니다. 고객 밖으로 나가면 그 회사의 진짜 문제가 안 보이기 때문입니다. B2C는 설문과 사용 화면으로 문제를 볼 수 있습니다. B2B는 그 회사 안에 들어가지 않으면 의사결정이 어디서 멈추는지 볼 수 없습니다.

SI와 80%가 겹친다

SI는 System Integration, 시스템 통합입니다. 고객이 쓰는 여러 시스템을 이어 붙이거나, 고객이 원하는 시스템을 만들어 납품하는 일입니다. 한국에서 오래 커 온 산업이고, 고객 현장에 나가 요구사항을 받고 구축하고 검수받는 흐름이 이미 있습니다.

FDE도 고객 현장에 나갑니다. 요구를 듣고, 솔루션을 붙이고, 돌아가게 만듭니다. 하이프 체크 EP.3은 이 겹침을 80% 안팎으로 봤습니다. 측정값이 아니라, 일하는 요소를 하나씩 펼쳐 본 추정입니다. 해외에서도 솔루션 아키텍트, 컨설턴트, SI 엔지니어의 리브랜딩 아니냐는 말이 나옵니다. 틀린 말이 아닙니다. 현장에서 상주하며 구축하고 나오는 모양만 보면 같아 보입니다.

그래서 이름만 FDE로 바꿔 채용 공고를 내면 자동으로 다른 일이 되지 않습니다. 입사한 뒤에도 고객이 적어 준 화면 목록을 그대로 구현하면, 그 사람은 SI 엔지니어와 같습니다. 갈리는 지점은 직함이 아니라 요구사항 문서를 누가, 언제 쓰느냐입니다.

다른 20%는 요구사항을 누가 쓰느냐

RFP는 Request For Proposal입니다. 고객이 ‘이런 걸 만들어 달라’고 정리한 제안 요청서이자 요구사항 문서입니다. 전통 SI는 이 문서가 꽤 자세해진 뒤에 개발이 시작됩니다. 화면, 기능, 일정, 검수 기준이 이미 적혀 있습니다. 개발자의 일은 그 문서를 구현하고 배포하는 쪽에 가깝습니다.

그 문서를 쓰는 사람은 대개 고객 실무자가 아닙니다. 컨설팅 펌이 고객의 말을 받아 구체화하는 경우가 많습니다. 컨설팅 펌의 일은 고객이 원하는 비전을 문서에 담는 것입니다. 고객도 자기 문제를 다 모릅니다. 문제가 아닌 것을 과대 해석하거나, 진짜 병목을 빠뜨리기도 합니다. 그렇게 잠긴 문서가 개발로 넘어오면, 개발자는 요구를 다시 파악하러 갈 공수가 없습니다. 이미 기획된 구조를 맞추는 일이 됩니다.

FDE는 이 순서를 바꿉니다. 고객이 요구사항을 완성해 줄 때까지 기다리지 않습니다. 첫 일은 개발이 아니라 관찰입니다. 사람들이 어떤 데이터를 보고, 어떤 순서로 일하며, 어디에서 의사결정이 멈추는지를 먼저 봅니다. ‘대시보드를 만들어 주세요’가 오면 화면을 그리지 않습니다. 그 화면이 필요한 의도를 묻습니다. 현장에 들어가 보니 문제는 대시보드 부재가 아니라, 부서마다 같은 지표를 다르게 읽고 있는 것일 수 있습니다. 그러면 만들 것은 화면이 아니라 지표 정의입니다.

계약에 넣을 네 줄

이름을 FDE로 붙이는 것만으로는 부족합니다. 회사는 고객과 계약을 맺을 때 ‘우리는 이런 순서로 일한다’를 문서에 적어야 합니다. FDE 스스로도 ‘고객이 말한 것을 구현하는 사람’이라는 인식에서 벗어나야 합니다. 둘 중 하나만 바뀌면 현장은 다시 RFP 구현으로 돌아갑니다.

아래 네 줄은 제안서나 SOW(Statement of Work, 과업 명세서)에 그대로 넣을 수 있는 초안입니다. 법률 검토 전의 실무 문장입니다. 핵심은 하나입니다. 1주차 산출물을 화면에서 관찰 노트로 바꾸는 것입니다.

이 조항이 없으면 고객은 첫 주에 화면을 달라고 하고, 공급사는 공수가 잠긴 상태에서 거절할 근거가 없습니다. 조항이 있으면 ‘대시보드 만들어 주세요’는 수락이 아니라 질문의 시작이 됩니다.

제n조 (발견 주)
① 최초 5영업일의 산출물은 소프트웨어가 아니라 관찰 노트다.
② 발주자가 제시한 기능 목록은 가설이다. 발견 주 종료 시 양 당사자가 문제 정의를 다시 작성한다. 그 전까지 개발 공수와 화면 명세는 확정하지 않는다.
③ 수급인은 발주자가 요청한 화면이 현장 관찰과 어긋나면, 구현에 들어가기 전에 문제 정의를 수정할 권한과 의무를 갖는다.
④ 발견 주에서 확인한 데이터 구조·의사결정 패턴·지표 정의는 납품물과 별도로 발주자 내부 문서로 남긴다.

첫 주, 월부터 금까지

조항만 넣고 현장이 그대로면 소용이 없습니다. 발견 주 닷새를 이렇게 씁니다. 개발 환경이 없는 사람도 따라갈 수 있습니다. 필요한 것은 노트와, 한 업무를 하루 따라갈 허가입니다.

월요일에는 화면 목록을 받지 않습니다. 한 업무의 하루를 따라갑니다. 누가 어떤 화면을 열고, 어디에 숫자를 적고, 누구에게 물어보고, 어디서 멈추는지만 적습니다. 화요일에는 같은 숫자 하나를 고릅니다. 매출, 재고, 대기 시간처럼 회의에서 자주 나오는 지표 하나면 됩니다. 그 숫자를 부서 둘 이상에 물어 해석이 갈리는지 봅니다. 수요일에는 막히는 의사결정 하나를 고릅니다. 풀 가치가 있는지만 한 줄로 적습니다. 화면을 만들지 않습니다.

목요일에는 그 문제만으로 최소 가설을 적습니다. ‘부서 A와 B가 같은 이름을 다른 식으로 계산한다. 이름을 하나로 맞추면 회의가 줄어들 것이다.’ 정도는 가설입니다. 아직 개발 공수를 확정하지 않습니다. 금요일에는 고객과 문제 정의를 다시 씁니다. 이때부터 개발 범위가 열립니다. 고객이 처음 적은 기능 목록과 금요일의 문제 정의가 같으면, 그 목록은 가설이 아니라 확인된 문제입니다. 달라도 됩니다. 다른 쪽이 이 주의 성과입니다.

현장에서 쓴 문제가 숫자가 된 자리

팔란티어 공개 사례는 이 순서가 명세 납품과 어떻게 다른지를 보여 줍니다. 숫자는 영상 자막이 아니라 해당 기관과 팔란티어가 공개한 값을 씁니다.

탬파 제너럴 병원(Tampa General Hospital)은 2021년부터 팔란티어 파운드리를 썼습니다. 병원 보도(2024-06-05)는 환자 배치에 걸리는 시간을 83% 줄였고, 마취 후 회복실(PACU) 대기를 28% 줄였다고 적습니다. 미리 완성된 ‘재난 대응 화면 명세’가 있었던 자리가 아닙니다. 환자 정보, 인력, 병상이 시스템에 흩어져 있어 배치 판단이 늦어지는 현장 병목이었습니다.

파나소닉 에너지 북미(Panasonic Energy of North America)는 숙련 기술자의 머릿속과 개인 메모, 과거 작업 기록에 있던 장애 대응을 Ask Atom이라는 현장 보조 도구로 모았습니다. 팔란티어 임팩트에 실린 정비 관리자 타라 마이징어의 말은 이렇습니다. 3개월에서 6개월이 걸리던 학습 곡선을 몇 주로 줄였다. 문서를 통째로 챗봇에 넣은 결과가 아닙니다. 센서, 수리 티켓, 비정형 문서를 연결한 뒤에야 신입도 같은 질문에 닿을 수 있었습니다.

에어버스는 2015년 파운드리로 A350 생산의 일정, 인력, 부품, 결함을 한 화면에 모았습니다. 팔란티어 임팩트는 A350 인도(delivery)가 33% 빨라졌다고 적습니다. 2017년 그 구조가 스카이와이즈(Skywise)라는 항공 산업 플랫폼으로 커졌습니다. 한 공장의 뾰족한 병목으로 들어가, 나중에 산업 전체로 확장한 형태입니다. FDE 방식의 해자는 납품 화면이 아니라, 현장에서 건져 올린 데이터 구조와 의사결정 패턴이 회사 안으로 돌아오는 데 있습니다.

구현이 싸질수록 잘못된 RFP가 더 빨리 쌓인다

생성형 AI 때문에 SI가 죽었다는 말은 과합니다. 달라진 것은 코드를 만들고 화면을 그리는 비용입니다. 요구사항이 이미 정확하게 정해져 있다면, 고객사 안의 AI 팀도 예전보다 적은 인원으로 같은 화면을 만들 수 있습니다. 그 일은 바깥 FDE의 값이 아닙니다.

값이 커지는 쪽은 문제를 정의하는 일입니다. 고객이 실제로 겪는 어려움은 화면 부재가 아니라, 무엇을 자동화해야 하는지 모르는 단계인 경우가 많습니다. 문제를 잘못 정의한 채 AI로 구현하면, 잘못된 화면이 더 빨리 늘어납니다. 슬롭입니다. 코드를 많이 만든 것이 성과가 아닙니다.

그래서 FDE를 운영하는 회사는 고객과의 계약에서 순서를 밝혀야 하고, FDE 개인은 고객이 요구하는 화면 아래의 의도를 물을 수 있어야 합니다. 기획부터 배포까지 한 사람이 책임지므로 부담은 큽니다. 그 부담이 연봉으로 보이는 자리이기도 합니다. 이름은 중요하지 않습니다. 앞으로 개발이라는 일이, 문제를 제안하고 만들고 설득하는 일에 더 가까워질 뿐입니다.

오늘 바로 할 것

지금 진행 중이거나 곧 열 프로젝트의 계약서나 과업 명세서를 엽니다. 1주차 산출물이 화면, 기능 목록, 프로토타입으로 적혀 있으면 그 줄을 관찰 노트로 바꿉니다. 위 네 줄 초안을 붙여 넣고, 법률 검토 전에 고객과 먼저 그 순서에 합의하는지가 핵심입니다.

이번 주 회의에서 자주 나오는 숫자 하나를 고릅니다. 매출, 재고, 대기, 불량률처럼 이름이 같은 지표면 됩니다. 부서 둘 이상에 그 숫자를 어떻게 계산하는지 묻습니다. 해석이 갈리면 그 차이를 이번 주 문제 정의로 씁니다. 갈리지 않으면 다음 숫자로 갑니다.

고객이 이미 RFP를 보내 온 상태여도 발견 주는 열 수 있습니다. 문서를 폐기하는 것이 아닙니다. 기능 목록 옆에 ‘가설’이라고 적고, 닷새 뒤에 같은 목록을 다시 씁니다. 남은 줄이 그 프로젝트의 진짜 범위입니다.