왜 이 비교가 필요한가
팔란티어 관련 채용 공고나 기사를 보다 보면 “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 컨설턴트가, 전체 그림을 설계해야 할 땐 솔루션 아키텍트가 앞에 섭니다.
마무리
FDE, PI 컨설턴트, 솔루션 아키텍트는 이름만 다른 같은 역할이 아닙니다. FDE는 “만들면서 설계”하고, PI 컨설턴트는 “업무를 다시 그리고 합의”하고, 솔루션 아키텍트는 “구조를 그리고 위임”합니다. ERP 프로젝트 배경에서 팔란티어로 넘어오는 분들이라면, FDE를 “코드 짜는 PI 컨설턴트”보다는 “프로세스 재설계와 시스템 구현을 한 사람이 빠르게 반복하는 역할”로 이해하는 편이 실제 협업할 때 기대치를 맞추기 쉽습니다.