팔란티어 FDE 아카데미에서 배우는 현장 실무: 46개 모듈로 AI 엔지니어로 성장하는 과정
팔란티어 FDE 아카데미: 현장 문제를 솔루션으로 바꾸는 학습의 구조 '팔란티어 FDE 아카데미'라는 이름을 처음 접할 때, 단순한 온라인 교육 플랫폼으로 생각할 수 있습니다. 그러나 이 아카데미의 핵심은 표면적 문제에서 진정한 병목을 찾아내고, 그것을 구조화된 AI ...
팔란티어 FDE 아카데미: 현장 문제를 솔루션으로 바꾸는 학습의 구조
'팔란티어 FDE 아카데미'라는 이름을 처음 접할 때, 단순한 온라인 교육 플랫폼으로 생각할 수 있습니다. 그러나 이 아카데미의 핵심은 표면적 문제에서 진정한 병목을 찾아내고, 그것을 구조화된 AI 솔루션으로 변환하는 사고 체계를 가르치는 것입니다. 본 글은 에스비컨설팅 심재우 대표가 기획한 FDE Field Lab OS의 학습 철학과 46개 모듈이 어떤 순서로 학습자를 단계적으로 발전시키는지, 그 작동 원리를 깊이 있게 풀어냅니다. 이를 통해 AI 도입이 단순 기술 선택이 아니라 현장의 암묵지를 언어화하고, 그 언어를 실행 구조로 설계하는 프로세스임을 이해할 수 있습니다.
왜 표면 문제가 아닌 암묵지 추출이 첫 단계인가?
흔한 AI 교육은 머신러닝, 데이터 처리, 모델 선택 같은 '기술 주제'부터 시작합니다. 팔란티어 FDE 아카데미는 이와 정반대입니다. 문제 재정의와 암묵지 질문(Tacit Questions)에서 시작하는 이유는 현장의 진짜 어려움이 겉으로 드러나지 않기 때문입니다.
예를 들어, 한 제조업체가 "생산 효율을 높이려면 AI가 필요하다"고 말할 때, 표면적 문제는 '효율'입니다. 그러나 1일차 모듈(Problem Reframe, Tacit Questions, Concept Extraction)을 거치면 진정한 병목은 "특정 공정 담당자의 암묵적 노하우가 문서화되지 않아 신입이 3개월 걸리는 판단을 30분 만에 하지 못한다"는 것으로 드러날 수 있습니다. 이 '진짜 문제'를 찾는 과정 자체가 AI 솔루션의 설계를 결정합니다.
* 문제 재정의(Problem Reframe): 고객이 보고하는 증상에서 근본 원인을 역추적 — 5Why 기법이 아니라 도메인 전문가와의 대화로 은폐된 제약 조건 발견
* 암묵지 질문 20개+: 현장 담당자에게 던지는 구조화된 질문 세트 — "어떤 상황에서 판단이 어려운가?", "규칙으로 정할 수 없는 이유는?", "누가 최종 결정을 내리는가?" 등
* 개념 추출: 도메인 언어(예: 제조업의 "스케줄링", 의료의 "트리아주")를 AI가 이해할 수 있는 구조로 변환
핵심: 기술 선택은 문제를 정확히 정의한 후에만 의미를 가진다.
온톨로지 7요소가 AI 에이전트의 두뇌가 되는 이유
팔란티어의 Foundry 플랫폼은 데이터 통합 도구로 알려져 있지만, FDE 교육 맥락에서 온톨로지는 AI가 현장을 이해하고 자율적으로 행동할 수 있게 하는 의미 구조입니다. 1일차 마지막(Ontology Builder)에서 학습자들이 설계하는 온톨로지 7요소는 다음과 같습니다:
온톨로지는 "데이터 사전"이 아니라 "AI의 운영 지침"입니다. 예를 들어 병원의 환자 흐름 최적화 프로젝트라면: (1) 객체는 '환자', '의사', '병상', '검사실'이고, (2) 속성은 환자의 '우선순위', 의사의 '전문과', 병상의 '가용성'입니다. (3) 관계는 "환자→의사 진료" "검사→결과 대기", (4) 상태는 "진료중", "대기중", "퇴원", (5) 액션은 "스케줄 변경", "우선순위 재조정", (6) 권한은 "의사만 진료 순서 변경 가능", "간호사는 조회만 가능", (7) KPI는 "평균 대기 시간", "병상 회전율"입니다.
AI 에이전트는 이 7요소를 기반으로 "09:00 환자 C는 응급실 도착 시 우선순위 2인데, 현재 대기 환자 수와 의사 일정을 고려하면 10:30에 배정하는 것이 최적"이라는 판단을 자동으로 내릴 수 있습니다.
* 온톨로지 7요소의 상호작용: 객체와 관계로 '구조'를 정의하고, 상태와 액션으로 '흐름'을 정의하며, 권한으로 '책임'을 정의하고, KPI로 '성과'를 정의
* 왜 7개인가: 너무 적으면(3~4개) 현장의 복잡성을 담지 못하고, 너무 많으면(10+개) 유지보수 불가능 — 경험적으로 최적화된 범위
* 온톨로지 수정·보완 단계(2일차): 1일차에 설계한 온톨로지를 실제 데이터로 검증하며 반복 개선
핵심: 온톨로지는 AI와 인간의 소통 언어이자, 자동화의 경계를 정하는 정책 문서다.
12대 핵심 스킬이 4가지 실행 카테고리로 나뉘는 이유
FDE 아카데미의 교육 구조를 보면 무작위로 12개 스킬을 나열하지 않고, 문제를 푸는 순서에 따라 4개 카테고리로 분류합니다:
첫째, 문제 이해(3개 스킬): Problem Decomposition, Domain Design/DDD, Event Storming — 이 단계에서 학습자는 고객의 비즈니스 프로세스를 지도로 그립니다. 제조업 고객의 "주문 생성 → 원재료 구매 → 생산 스케줄링 → 품질 검사 → 배송"이라는 흐름 속에서 각 단계의 의사결정 규칙, 병목, 데이터 출처를 파악합니다.
둘째, 구조 설계(3개 스킬): Service Blueprint, Data Modeling, API Integration — 이미 파악한 현장 흐름을 기술 아키텍처로 변환합니다. "현장 의사결정"이 어느 시스템에서 일어나는지(ERP인지, 스프레드시트인지, 종이 기록인지), 데이터가 어떤 포맷으로 존재하는지, 어떻게 연결할 것인지를 설계합니다.
셋째, 실행 연결(3개 스킬): AI Agent Engineering, Governance, Evaluation — 설계를 실제 AI 에이전트로 구현하고, 그 에이전트가 지켜야 할 규칙(거버넌스)과 성과를 측정하는 방법을 정합니다. "이 에이전트가 주문을 자동 스케줄링할 때, 비용이 20% 초과되면 누가 승인하나?", "에러율 5% 이상이면 어떻게 하나?"를 미리 정합니다.
넷째, 확산 경영(3개 스킬): Change Management, Productized Consulting, Executive Communication — 한 팀이 성공한 AI 솔루션을 조직 전체로 확산하고, 그 경험을 재판매 가능한 서비스로 패키징합니다.
이 순서가 중요한 이유는 기술 선택(Agent 설계)이 아키텍처(Service Blueprint) 위에 얹혀야 하고, 아키텍처는 현장 이해(DDD) 위에 얹혀야 하기 때문입니다. 순서를 바꾸면(예: Agent 먼저 설계) 현장과 맞지 않는 자동화를 만들게 됩니다.
* 카테고리 간 데이터 흐름: 각 카테고리의 산출물이 다음 카테고리의 입력값 — 예를 들어 Event Storming의 결과("주문 → 검증 → 결제"라는 이벤트 흐름)가 Service Blueprint를 그리는 기초
* 반복적 피드백: 각 실행 단계에서 "이것이 정말 가능한가?"라는 질문이 구조 설계로 돌아가 수정하게 함
* 한 기업의 사례를 다룬 FDE 프로젝트는 12개 스킬을 모두 거침: 일부만 적용하면 "부분 최적화"로 끝나고 전체 가치 창출 못함
핵심: 12개 스킬은 순서가 없는 기술이 아니라, 현장 → 설계 → 실행 → 확산이라는 인과적 흐름을 따르는 체계다.
8대 플랫폼 원시 요소가 "재사용성"을 보장하는 구조
FDE 아카데미 2일차(현장 확장 모듈)에서 학습자들이 배우는 8대 원시 요소는 한 고객사에서 해결한 문제를 다른 고객사에서도 빠르게 적용할 수 있게 하는 재사용 가능한 자산입니다.
예를 들어, 첫 프로젝트에서 "병원의 응급실 환자 배분을 자동화한 온톨로지"를 설계했다면, 이를 그대로 재사용하지는 않습니다. 대신 그 온톨로지의 구조적 패턴(대기→선별→배정→모니터링이라는 상태 전이)을 "확장 템플릿"으로 추상화합니다. 그러면 다음 고객(예: 은행의 콜센터)도 "콜 대기→우선순위 판단→상담원 배정→모니터링"이라는 동일한 패턴으로 빠르게 온톨로지를 설계할 수 있습니다.
8대 원시 요소는 구체적으로:
이 8개 요소가 갖춰져야 "AI 에이전트가 자율적으로 작동 가능한 시스템"이 됩니다. 하나라도 빠지면(예: 권한 시스템 없음) AI가 주문할 수 있는 범위가 불명확해져 오류가 발생합니다.
* 재사용성의 수준: 온톨로지를 100% 재사용하지는 못하지만(도메인마다 고유 요소 있음), 객체 모델·워크플로우 엔진·출처 추적 같은 기술적 구조는 70~80% 재사용 가능
* 신규 프로젝트의 속도 차이: 8대 원시 요소를 갖춘 팀의 새 프로젝트는 온톨로지 설계가 2~3주 → 원시 요소 없는 팀은 2~3개월 소요
* 확장 템플릿의 역할: "이전 프로젝트와 이번 프로젝트의 차이점은 데이터 소스(A) 와 의사결정 주체(B)"라는 체크리스트로 변경 범위를 명확히 함
핵심: 원시 요소는 "바퀴를 다시 만들지 않기 위한" 표준화된 설계 자산이다.
FDE 성장 4단계 로드맵: 각 단계마다 책임과 역할이 변하는 이유
FDE 아카데미의 최종 산출물은 8장 피치덱을 넘어, 학습자가 조직 내에서 어떤 역할을 할 것인가에 따른 성장 경로를 제시합니다. 이를 이해하려면 먼저 각 단계가 왜 필요한지 알아야 합니다.
Level 1. Awareness (인식 단계): 새로운 팀원이나 경영진이 "FDE가 무엇인가"를 이해하는 단계. 이 단계의 학습자는 아직 주도적으로 문제를 분해하지 못하지만, 문제 재정의·온톨로지·AI 에이전트가 왜 필요한지 이해합니다. 보통 3개월간 2~3개 사례 학습과 1개의 관찰 프로젝트(다른 팀을 따라다니며 배움)로 구성됩니다.
Level 2. Analyst (분석 단계): 고객 현장에 들어가 문제를 구조화하고 온톨로지를 설계할 수 있는 단계. 이 단계 인력은 도메인 전문가와 대화할 때 올바른 질문을 던지고, 표면 증상에서 진정한 병목을 찾아냅니다. 보통 6개월~1년 경험으로 도달하며, 주도적으로 2~3개 고객사 진단을 수행합니다.
Level 3. Builder (구축 단계): 온톨로지를 AI 에이전트로 구현하고, 워크플로우·권한·KPI를 운영 가능한 형태로 만드는 단계. 이 단계 인력은 기술 선택(팔란티어 Foundry인지, 다른 LLM 플랫폼인지)에 대한 의견을 낼 수 있고, 규모 있는 프로젝트(6개월 이상)를 주도합니다. 보통 3~5개 프로젝트 구현 경험이 필요합니다.
Level 4. Leader (리더 단계): 한 조직의 AI 변환을 전략적으로 계획하고, 여러 팀을 조율하며, 성공 사례를 조직 문화로 확산시키는 단계. 이 단계 인력은 "우리 회사가 지금 FDE 방식으로 접근하면 어떤 ROI가 나올까?"라는 전략적 질문에 답할 수 있고, 신입 Analyst를 멘토링합니다.
왜 4단계일까? 이는 조직이 AI를 "일회성 프로젝트"에서 "지속 가능한 운영 체계"로 전환하는 과정을 반영하기 때문입니다. Level 1~2만 있으면 문제는 찾지만 실행 못하고, Level 3이 추가되면 구현은 하지만 확산 못하며, Level 4가 되어야 "조직 전체가 FDE 마인드로 움직이는" 상태에 도달합니다.
팔란티어의 목표는 이 4단계를 10,000명까지 양성하는 것이며, 에스비컨설팅 심재우 대표가 주도하는 FDE 아카데미는 이러한 체계적 성장을 한국 기업과 공공기관에 처음 체계적으로 소개하는 플랫폼입니다.
* 단계별 인력 수요: 조직 1,000명당 Awareness 100명, Analyst 30명, Builder 5명, Leader 1명이 이상적 구성
* 단계별 교육 기간: Level 1 → 3개월 / Level 2 → 6개월 / Level 3 → 1년 / Level 4 → 2년 이상
* 단계 상승의 조건: 실제 프로젝트 경험 필수 (강의만으로는 상승 불가)
핵심: 성장 4단계는 개인의 역량 발전이 아니라 조직의 AI 운영 능력 완성 과정을 따른다.
46개 모듈의 순차적 배치가 "실행 불가능한 학습"을 막는 방법
46개 모듈이 단순히 난이도 순서대로 배열된 것이 아니라는 점이 FDE 아카데미의 가장 강력한 설계 철학입니다. 예를 들어:
1단계: 문제 → 온톨로지 (6개 모듈)
이 6개 모듈을 거친 후 학습자는 "고객의 문제가 뭔지 안다"는 상태에 도달합니다. 이 때 다음 단계로 넘어갑니다.
2단계: 실행 → 발표 (9개 모듈)
2단계에서 중요한 점은 각 모듈이 이전 모듈의 산출물을 입력값으로 받는다는 것입니다. Ontology Builder에서 만든 온톨로지 7요소가 없다면, FDE 12 Skills Mapping을 할 수 없습니다. 또한 에이전트를 설계하지 않고 KPI를 정할 수 없습니다(KPI는 에이전트가 실행할 액션을 측정하는 지표이기 때문).
3단계: 현장 확장 (9개 모듈, 2일차 이후 심화)
이 3단계를 거친 1팀(5명)은 단순히 "1개 프로젝트를 끝낸 것"이 아니라, 다음 고객을 더 빠르게 처리할 수 있는 재사용 가능한 자산을 만들어낸 상태입니다.
모듈 배치의 핵심은 "너무 앞서 기술 결정을 강요하지 않되, 기술 선택 시점에 필요한 모든 정보가 준비되어 있어야 한다"는 원칙입니다. 예를 들어, Ontology Builder(1단계)에서는 "어떤 AI를 쓸 것인가"를 정하지 않습니다. 대신 "온톨로지 7요소를 정확히 정의해야 다음 단계에서 올바른 기술을 선택할 수 있다"는 것을 깨닫게 합니다.
* 모듈 간 데이터 흐름: localStorage를 활용해 각 팀이 입력한 온톨로지·스킬 매핑·에이전트 설계가 다음 모듈로 자동 전달 → "완성도 높은 산출물" 보장
* 5팀 독립 운영: 팀마다 다른 주제(금융, 의료, 제조, 유통, 공공)를 선택해 프로젝트 진행 → 다양한 도메인 경험 동시 축적
* 조기 중단 방지: 각 모듈 끝에 "체크포인트"가 있어 부실한 산출물로 다음 단계 진입 방지
핵심: 46개 모듈은 순차적 선택지가 아니라, 각 선택이 다음 단계를 결정하는 인과의 사슬이다.
---
FDE 아카데미 학습자들이 가장 많이 묻는 질문 3가지
Q1: 온톨로지 7요소를 어느 정도 세밀하게 정의해야 하나요? 너무 상세하면 시간이 오래 걸릴 것 같은데.
A: 온톨로지는 "완벽을 추구하는 문서"가 아니라 "의사결정을 가능하게 하는 최소 필요 구조"입니다. FDE 아카데미의 경험상, 온톨로지 정의에 1일차 절반(4시간)을 투자하는 것이 최적입니다. 그 이상 투자하면 수확 체감이 발생합니다. 왜냐하면 2일차에 실제 데이터를 보면서 "이 속성이 필요 없네", "이 액션이 빠졌네"라는 발견이 계속 나오기 때문입니다. 따라서 "70% 정도면 충분, 실제 데이터로 반복 개선"이라는 마인드가 중요합니다.
Q2: 12개 스킬을 모두 적용해야 하나요? 우리 회사는 규모가 작아서 일부만 필요한 것 같아요.
A: 12개 스킬이 카테고리로 나뉘는 이유를 다시 생각해보세요. 문제 이해(3개)만 하고 구조 설계(3개)를 스킵하면, 올바른 아키텍처 없이 기술을 선택하게 됩니다. 구조 설계까지만 하고 실행 연결(3개)을 스킵하면, 설계는 예쁘지만 실제 작동하지 않는 시스템이 됩니다. 규모가 작은 조직일수록 각 카테고리를 "간단하게" 처리할 수는 있지만, "스킵"하면 부분 최적화로 끝납니다. 예를 들어, Event Storming을 30분으로 끝낼 수는 있어도(시간 단축), 아예 스킵할 수는 없습니다(건너뛸 수 없음).
Q3: 2일 교육만으로 실제 프로젝트에 적용할 수 있나요?
A: 아니요. FDE 아카데미의 2일간은 "원리와 프레임워크"를 배우는 것이고, 실제 적용은 현장에서의 "반복 경험"입니다. 아카데미 수료 후 팀이 6개월~1년간 2~3개 실제 고객 프로젝트를