왜 이 비교가 필요한가
팔란티어 관련 채용 공고나 기사를 보다 보면 “FDE(Forward Deployed Engineer)”라는 낯선 직군이 자주 등장합니다. ERP/컨설팅 프로젝트를 오래 해온 분들이라면 이 역할을 보고 “PI(Process Innovation) 컨설턴트랑 비슷한 건가”, “솔루션 아키텍트 아닌가” 하는 생각이 들 수 있습니다. 실제로 세 역할 모두 “현업과 기술 사이에서 일한다”는 공통점은 있지만, 무엇을 산출물로 내고 어디까지 책임지는지는 꽤 다릅니다.
이 글은 팔란티어 운영조직을 맡으면서 FDE와 실제로 협업해본 경험을 바탕으로, ERP 프로젝트에서 익숙한 PI 컨설턴트·솔루션 아키텍트와 FDE를 나란히 놓고 정리한 글입니다.
세 역할, 각각 무엇을 하는가
FDE (Forward Deployed Engineer) 팔란티어가 만든 직군으로, 고객사에 파견되어 Foundry/Gotham/AIP 위에 실제로 동작하는 애플리케이션을 직접 코딩해서 만듭니다. 모호한 현업 요구사항을 스스로 분해해서 프로토타입을 빠르게 만들고, 고객 피드백을 받아 계속 고쳐나가는 방식으로 일합니다. 설계만 하고 넘기는 게 아니라 배포 이후 운영 단계까지 관여하는 경우가 많습니다.
PI 컨설턴트 (Process Innovation Consultant) 현업의 As-Is 업무 프로세스를 분석하고, To-Be 프로세스를 새로 설계하는 역할입니다. ERP 도입 프로젝트에서는 보통 시스템 구축에 앞서(또는 병행해서) 워크숍을 통해 현업 프로세스를 재정의하고, Fit-Gap 분석을 거쳐 “업무가 앞으로 어떻게 돌아가야 하는가”를 문서로 정리합니다. 코드를 직접 짜기보다는 프로세스 설계와 현업 합의를 이끌어내는 데 집중하는, 비즈니스와 더 가까운 역할입니다.
솔루션 아키텍트 (Solution Architect) 특정 구현 기술보다는 전체 시스템 구조를 설계하는 역할입니다. 여러 시스템·팀에 걸친 아키텍처를 그리고, 기술적 의사결정의 방향을 잡고, 다른 엔지니어/컨설턴트들이 그 설계를 따라 구현하도록 가이드합니다. 직접 코드를 짜는 비중은 조직마다 다르지만, 본질은 “구조 설계와 의사결정”에 있습니다.
비교표
| 구분 | FDE | PI 컨설턴트 | 솔루션 아키텍트 |
|---|---|---|---|
| 핵심 산출물 | 실제 동작하는 애플리케이션(코드) | To-Be 프로세스 설계, Fit-Gap 분석 문서 | 아키텍처 설계 문서, 기술 의사결정 |
| 코드 작성 | 직접, 상시 | 거의 없음 (프로세스/문서 중심) | 조직에 따라 다름, 설계 중심 |
| 관심 대상 | “무엇을 만들 것인가” (기술 구현) | “업무가 어떻게 돌아가야 하는가” (프로세스) | “어떻게 구조화할 것인가” (시스템 설계) |
| 고객 접점 | 매우 높음 — 현업과 상시 협업하며 요구사항을 직접 구체화 | 매우 높음 — 워크숍/인터뷰로 현업 합의를 이끌어냄 | 중간~높음 — 의사결정권자·여러 팀과 협업 |
| 책임 범위 | 문제 정의부터 배포·초기 운영까지 엔드투엔드 | 프로세스 정의까지 (구현은 별도 팀이 담당) | 전체 구조 설계, 구현은 위임 |
| 성공 기준 | 고객이 실제로 쓰는 작동하는 결과물 | 현업이 동의하고 실행 가능한 To-Be 프로세스 | 설계가 요구사항을 충족하고 확장 가능한가 |
실무에서 느낀 것
팔란티어 운영을 맡으면서 FDE와 함께 일해보면 가장 먼저 체감하는 차이는 “합의의 매개체”입니다. PI 컨설턴트가 이끄는 프로세스 재설계 워크숍에서는 화이트보드에 그린 To-Be 프로세스 다이어그램과 문서가 현업과의 합의 기준이 됩니다 — 문서에 먼저 합의하고, 그다음 시스템이 그 문서를 따라 구축됩니다. FDE는 이 순서를 뒤집습니다. 문서보다 “일단 동작하는 화면”을 먼저 보여주고, 그 자리에서 피드백을 받아 즉시 고치는 방식으로 합의를 만들어갑니다.
이 방식이 항상 유리한 것은 아닙니다. 전사 차원의 업무 프로세스를 재정의해야 하거나, 여러 부서의 이해관계를 조율해야 하는 상황에서는 PI 컨설턴트 방식의 워크숍·문서 기반 합의가 여전히 더 안전합니다. 결국 세 역할은 경쟁 관계가 아니라, 문제의 성격에 따라 필요한 역할이 다른 것에 가깝습니다 — 모호한 요구사항을 빠르게 형태로 만들어야 할 땐 FDE적 접근이, 조직 전체의 업무 방식을 재정의해야 할 땐 PI 컨설턴트가, 전체 그림을 설계해야 할 땐 솔루션 아키텍트가 앞에 섭니다.
실전 시나리오 — 같은 요구사항, 세 역할이 접근하는 방식
“고객사가 재고 부족 알림 화면이 필요하다”는 요구가 들어왔다고 가정해봅니다.
- PI 컨설턴트라면: 먼저 현재 재고 관리 프로세스를 현업과 함께 워크숍으로 분석합니다. “알림이 왜 필요한가”, “누가 받아야 하는가”, “알림 이후 업무가 어떻게 바뀌는가”를 정리한 To-Be 프로세스 문서를 만들고, 여러 부서의 합의를 받은 뒤 시스템 요구사항으로 넘깁니다.
- 솔루션 아키텍트라면: 재고 데이터가 어느 시스템에 있고, 알림을 어떤 채널(이메일/Slack/대시보드)로 보낼지, 기존 아키텍처에서 이 기능이 어느 레이어에 들어가야 하는지 설계도를 그립니다. 구현은 별도 개발팀에 위임합니다.
- FDE라면: 바로 Foundry에서 재고 Object Type과 임계값 조건을 가진 Action Type을 만들고, Workshop으로 알림 화면 프로토타입을 그 자리에서 띄웁니다. 현업 담당자가 화면을 보고 “이 숫자 말고 저 숫자가 더 중요해요”라고 하면 그 자리에서 바로 고쳐서 다시 보여줍니다.
세 접근 모두 “틀린” 방법은 아닙니다. 다만 결과물이 나오는 속도와 중간 산출물의 형태(문서 vs 설계도 vs 동작하는 화면)가 다르다는 점이, 실제로 같이 일할 때 기대치가 어긋나는 가장 흔한 지점입니다.
커리어 전환을 고려한다면
ERP·BI 배경에서 팔란티어 생태계로 넘어오려는 분들이 가장 많이 묻는 질문은 “PI 컨설턴트 경력이 FDE로 전환하는 데 도움이 되는가”입니다. 현업 프로세스를 읽는 역량과 이해관계자를 조율하는 경험은 분명 FDE에게도 자산입니다. 다만 FDE는 그 위에 실제 코딩·배포 역량이 추가로 요구되므로, 전환을 준비한다면 프로세스 분석 역량과 별개로 Foundry 플랫폼 자체(Ontology Manager, Workshop, AIP Logic)를 직접 다뤄보는 경험을 먼저 쌓는 것이 현실적입니다.
우리 프로젝트에 어떤 역할이 필요한지 판단하는 6가지 질문
- 지금 가장 부족한 것이 업무 합의(프로세스) 인가, 전체 구조(아키텍처) 인가, 동작하는 앱(구현) 인가
- 요구사항이 모호해서 프로토타입을 빠르게 만들어 보며 정해야 하는 단계인가, 문서로 합의 가능한 단계인가
- 산출물의 주된 형태가 문서(To-Be, Fit-Gap) 인지 배포된 애플리케이션인지
- 배포 이후 운영 단계까지 같은 사람이 책임져야 하는가
- 여러 시스템·팀에 걸친 기술 의사결정이 필요한가
- 세 역할의 책임 경계(누가 요구를 확정하고, 누가 구조를 승인하고, 누가 구현하는가)가 문서로 정해져 있는가
자주 묻는 질문
Q. FDE가 있으면 PI 컨설턴트나 솔루션 아키텍트는 필요 없나요? 역할이 겹치는 부분은 있지만 대체 관계는 아닙니다. 프로세스 재설계와 현업 합의, 전체 구조 설계는 여전히 별도의 책임이며, 조직 규모와 프로젝트 성격에 따라 한 사람이 일부를 겸할 뿐입니다.
Q. ERP 프로젝트 경험자가 FDE로 전환하려면 무엇이 가장 다른가요? 산출물이 문서에서 동작하는 코드와 앱으로 바뀐다는 점입니다. 프로세스를 이해하는 힘은 그대로 자산이지만, 직접 만들고 빠르게 고치는 개발 역량이 필요합니다.
Q. 세 역할 중 하나만 고르라면요? 프로젝트 단계에 따라 다릅니다. 방향이 불명확하면 PI, 구조 충돌이 크면 아키텍트, 빨리 동작하는 것을 보여야 하면 FDE의 비중이 커집니다.
마무리
FDE, PI 컨설턴트, 솔루션 아키텍트는 이름만 다른 같은 역할이 아닙니다. FDE는 “만들면서 설계”하고, PI 컨설턴트는 “업무를 다시 그리고 합의”하고, 솔루션 아키텍트는 “구조를 그리고 위임”합니다. ERP 프로젝트 배경에서 팔란티어로 넘어오는 분들이라면, FDE를 “코드 짜는 PI 컨설턴트”보다는 “프로세스 재설계와 시스템 구현을 한 사람이 빠르게 반복하는 역할”로 이해하는 편이 실제 협업할 때 기대치를 맞추기 쉽습니다.