팔란티어와 OpenAI가 찾는 PM의 조건
복잡한 현장을 추상화해 문제를 재정의하는 사람들
이제 PM도 현장으로 간다
최근 팔란티어(Palantir), OpenAI와 같은 AI 서비스 기업들은 현장 중심의 PM이나 엔지니어를 적극적으로 채용하고 있습니다. 회사마다 명칭은 조금씩 다르지만, Field Deployment나 Forward Deployed로 불리는 이 직군은 실제 고객 환경에서 제품을 배포하고 작동시키는 역할을 맡습니다. 요즘 채용 공고를 보면 이러한 역할이 예전보다 훨씬 자주 등장하는 것을 확인할 수 있습니다.
이번 글에서는 AI 시대에 왜 이런 현장 중심 PM(FD PM)이 중요해졌는지, 그리고 현장 중심 PM에게 특히 핵심이 되는 ‘추상화’ 역량이 무엇인지에 대해 이야기를 해보려고 합니다.
왜 현장 중심의 PM이 주목받을까?
AI 기업들이 현장 중심 PM을 주목하는 가장 큰 이유는 AI 모델의 성능이 현장 맥락(Context)에 따라 극적으로 달라지기 때문입니다. 동일한 모델이라도 입력 데이터나 사용 환경이 조금만 변하면 전혀 다른 결과를 낼 수 있습니다. 특히 프롬프트 방식, 도메인 용어, 조직의 운영 규칙처럼 현장의 미세한 차이에도 모델이 민감하게 반응하기 때문에, 실제 업무 흐름과 맥락을 깊이 이해하는 PM이 필수적입니다.
최근 내부 분석용 AI 에이전트와 대고객용 AI 에이전트를 실제로 구축하는 업무를 진행했습니다. 이 과정에서 가장 많은 시간을 투입한 일은 사용자에게 어떤 Use Case를 제공할지 정의하고, 사용자의 의도를 어떤 방식으로 받아들이고 해석할지 구조화하는 작업이었습니다. 직접 만들어보니, 도메인 이해도가 낮다면 단순히 기술을 아는 것만으로는 좋은 AI 에이전트를 만들 수 없다는 점을 절실히 느꼈습니다. 책상 위에서의 기획만으로는 AI 도입의 난제를 해결할 수 없고, 어떤 문제를 자동화할 수 있으며 어떤 문제는 인간-모델 협업 구조로 재설계해야 하는지 판단하려면 도메인 내 맥락을 깊게 이해하는 과정이 필요합니다.
또한 AI 에이전트는 실제 업무를 AI가 흡수하면서 기존 작업 방식, 데이터 흐름, 의사결정 구조까지 바뀌기 때문에, 제품의 일부가 아니라 업무의 전체 생태계를 이해할 필요가 있습니다. 이 과정에서 필요한 것은 기능을 정의하는 PM이 아니라, 현장에 들어가 사용자와 함께 프로세스를 다시 설계하는 Deployment 중심 PM이다. 저도 주기적으로 다양한 유형의 마케터들을 만나는데, 같은 회사 내 '마케터'여도 업무 워크플로우가 사람마다, 역량마다 조금씩 다른 경우를 쉽게 찾아볼 수 있습니다.
현장중심의 PM은 추상화를 해야 한다.
이런 상황에서 현장 중심의 PM에게 필요한 역량은 '추상화'라고 볼 수 있습니다. 추상화란 복잡한 현실을 단순하게 만드는 작업일 뿐만 아니라, 본질을 선명하게 드러내는 구조화 과정이라고 표현할 수 있습니다. 현장에는 수많은 사건, 변칙, 예외, 사람마다 다른 의견이 떠다니지만, 제품은 이 모든 것을 담을 수 없습니다. 그래서 PM은 사용자 경험 속에 숨어 있는 공통 패턴을 찾아내고, 문제의 핵심 변수를 추려내며, 로컬한 사례를 글로벌한 구조로 끌어올려야 합니다. 즉, 단순한 요약이 아니라, 혼란 속에서 작동 원리를 발견하는 능력이라고 말할 수 있습니다.
예를 들어, 물류센터에서 “입·출고가 느리다”는 여러 현장의 불만을 듣는다고 하자. 어떤 팀은 스캐너 오류를, 어떤 팀은 인력 부족을, 어떤 팀은 재고 위치의 난잡함을 이야기할 수 있습니다. 하지만 추상화가 잘되는 PM은 이 의견을 그대로 나열하지 않습니다. 대신 '데이터 흐름의 단절”과 같은 공통 근본 문제를 발견하고, 이를 재해석해서 해결 방안을 검토합니다. 즉, 내러티브에서 패턴으로, 사례에서 모델로 전환하는 것이 추상화의 핵심입니다.
그렇다면 추상화를 잘하기 위해서는 무엇이 필요할까요?
첫째, 충분히 많은 현상을 관찰하는 것입니다. 추상화는 감각이 아니라 ‘재료’에서 출발하기 때문에, 다양한 현장의 데이터와 경험을 몸으로 겪어야 합니다. 사용자를 많이 만나고, 그들이 실제로 겪는 상황을 직접 관찰해 보는 과정이 필수적입니다. 이때 관찰은 단순한 정보 수집이 아니라, 반복되는 패턴을 포착하는 훈련의 시작점이 됩니다.
둘째, 관찰한 내용을 구조화하는 연습이 필요합니다. 프로세스 흐름도, 사용자 여정 지도, 엔티티 관계도, 문제 정의 프레임 등 어떤 형식이든 상관없습니다. 완벽하지 않더라도, 개발 아키텍처와 사용자 워크플로우를 스케치해보면 복잡한 문제 속에서 핵심 흐름이 보이기 시작합니다. 이 구조화 과정은 결국 팀 간 소통을 돕고, 해결책을 논의할 때 서로의 시야를 맞추는 기초가 됩니다.
마지막으로, 추상화의 목적을 잊지 않는 것이 중요합니다. 추상화는 멋진 모델을 만드는 데서 끝나지 않습니다. 수많은 요구사항의 배경에 숨겨진 본질을 정확히 정의하고, 이를 바탕으로 더 나은 실행 전략을 만드는 데 있습니다. 잘못된 추상화는 오히려 모두에게 필요하지 않은 제품을 만들어 낼 수 있기 때문에, 추상화된 해결방안을 사용자도 끊임없이 피드백하면서 개선해 가는 과정이 필요합니다.
