FDE 12대 핵심 스킬: 문제이해에서 확산경영까지 왜 이렇게 구조화되어 있나

본 글은 에스비컨설팅 심재우 대표가 팔란티어 FDE 방법론과 온톨로지 기반 AI 전략 실행 5년간의 경험을 바탕으로 작성합니다. FDE(Forward Deployed Engineering)는 단순히 AI 도입 기술이 아니라, 조직이 현장의 암묵지를 구조화하고 이를 AI로 자동화·확산하는 전략적 프레임입니다. 이 글을 읽으면 왜 FDE 12대 스킬이 문제이해→구조설계→실행연결→확산경영의 순서로 배열되는지, 그 메커니즘과 학술적 배경을 이해할 수 있습니다.

액센추어, 마이크로소프트, 팔란티어, AWS 등 글로벌 기업들이 2026년 FDE를 엔터프라이즈 AI의 실행 표준으로 채택하면서, 한국 기업들도 "왜 이 순서인가"를 묻기 시작했습니다. 그 답은 인지과학, 조직심리학, 데이터 아키텍처의 세 영역이 만나는 지점에 있습니다. 각 스킬 그룹이 왜 그 순서로 배치되었는지, 그리고 어떻게 다음 단계로 자연스럽게 이어지는지를 이해하는 것이 FDE 실행의 성공률을 좌우합니다.

"정확한 문제 정의가 모든 실행의 출발점"이라는 원칙은 단순한 업계 관습이 아니라 인지과학과 시스템 이론의 결합입니다. 문제이해 3스킬(Problem Decomposition, Domain Design, Event Storming)이 먼저 배치되는 이유는 뇌가 불완전한 정보 상태에서 패턴을 만들기 때문입니다. 표면 문제("매출이 떨어진다")를 그대로 두면, 조직은 증상만 치료하고 근본 병목을 놓칩니다. 반면 Problem Decomposition으로 표면→중간→핵심 병목을 3단계로 파고들면, AI가 정말 자동화해야 할 지점을 찾습니다.

Domain Design(또는 DDD)은 이 병목을 도메인 언어로 재정의하는 과정입니다. 의료기관이라면 "환자 등록"이 아니라 "진료 이력 통합 및 위험도 분류"로 재정의되어야 AI 에이전트가 올바른 데이터를 수집합니다. Event Storming은 이 도메인 내 모든 사건(이벤트)을 시간 순서대로 시각화하므로, 어느 단계에서 데이터 손실이 일어나고 어디서 AI가 개입해야 하는지 투명하게 드러납니다. 이 세 스킬을 거치지 않으면, 다음 단계의 구조설계와 실행은 모래 위의 탑처럼 무너집니다.

* Problem Decomposition의 인지 메커니즘: 표면 문제를 5 Why 또는 피어슨 분석으로 분해하면, 조직의 무의식적 가정(mental model)이 드러나고, 그 가정이 틀렸을 때 진짜 병목을 발견할 수 있습니다.
* Domain Design이 AI 구현 성공률을 높이는 이유: 공통 언어(도메인 모델)가 없으면 비즈니스와 기술팀이 "환자"를 다르게 정의하므로, AI 학습 데이터가 일관성을 잃습니다.
* Event Storming이 온톨로지의 첫 스케치가 되는 구조: 모든 이벤트와 그 선후 관계를 그리면, 온톨로지의 액션·상태·권한 계층이 자동으로 보입니다.

문제를 정확히 정의했다면, 이제 그 문제를 "실행 가능한 구조"로 옮겨야 합니다. 구조설계 3스킬(Service Blueprint, Data Modeling, API Integration)은 조직의 병목을 데이터 흐름·서비스 경계·API 명세로 구체화하는 과정입니다. 이 단계가 필수인 이유는 "현장의 직관(암묵지)을 머신이 이해할 수 있는 형태로 변환해야" 하기 때문입니다.

Service Blueprint는 고객 여정 맵이 아니라 "조직이 어느 부분을 통제하고, 어느 부분이 자동화되어야 하며, 어디서 데이터가 흐르는가"를 시각화합니다. 예를 들어 금융 조직이 "대출 심사를 3일에서 1일로 단축하려면", 심사 프로세스의 15개 단계 중 병렬화할 수 있는 단계(API로 외부 신용평가사 호출), 자동화할 수 있는 단계(규칙 기반 조건 판단), 사람이 반드시 개입해야 하는 단계(예외 검토)를 분리합니다. 이것이 Service Blueprint입니다.

Data Modeling은 그 프로세스에서 필요한 정보 단위(객체)와 그 속성, 관계를 정의합니다. "대출 신청"이라는 객체는 "신청자, 신청액, 신청 목적, 신청일시"라는 속성을 가지고, "신청자"라는 객체와 "소유"의 관계를 가집니다. 이 관계도를 ERD(Entity Relationship Diagram)로 그리면, AI 에이전트가 어떤 데이터를 쿼리할지, 온톨로지에서 어떤 속성을 정의해야 할지 자명해집니다. API Integration은 이 정보들이 시스템 간 어떻게 이동할지 표준화하는 단계입니다.

* Service Blueprint가 온톨로지의 "액션" 계층을 정의하는 방식: 고객이 "대출 심사 진행상황을 알려달라"고 요청하면, 시스템이 어느 API를 호출하고, 어떤 순서로 데이터를 변환하고, 어느 단계에서 AI 판단이 끼어들 지를 Blueprint로 보면 명확해집니다.
* Data Modeling의 정규화가 AI 학습 데이터 품질을 좌우하는 이유: 중복 데이터, 모호한 관계, 누락된 속성이 있으면 AI 모델이 과적합(overfitting)되거나 편향된 학습을 합니다.
* API Integration이 "권한"과 "출처 추적" 온톨로지 요소로 이어지는 구조: API 명세에 "어느 역할만 이 데이터에 접근할 수 있는가"를 정의하면, 온톨로지의 권한 계층이 자동으로 도출됩니다.

정확한 구조를 설계했다면, 이제 "그 구조를 AI 에이전트로 자동 실행하고, 동시에 조직이 신뢰할 수 있도록 거버넌스를 짜야" 합니다. 실행연결 3스킬(AI Agent Engineering, Governance, Evaluation)이 이 단계에서 핵심인 이유는 기술 구현과 조직 통제가 분리되면 AI는 "검은 상자"가 되고, 결국 현장이 거부하기 때문입니다.

AI Agent Engineering은 Service Blueprint와 Data Model을 바탕으로 자연어 명령을 받아 자동으로 액션을 수행하는 시스템을 설계합니다. 팔란티어 Foundry의 에이전트는 "대출 심사 자료를 모아줄래?"라는 사용자 질문에 응답해 필요한 데이터를 수집하고, 규칙을 적용하고, 리포트를 생성합니다. 이것이 가능한 이유는 온톨로지 7요소(객체·속성·관계·상태·액션·권한·KPI)가 명확하게 정의되어 있어서, 에이전트가 "이 명령이 어디서 실행되고, 누가 승인하고, 어떤 결과가 나와야 하는가"를 자동으로 판단할 수 있기 때문입니다.

Governance는 그 자동 실행을 조직이 통제할 수 있도록 정책화하는 단계입니다. "AI 에이전트가 고객 신용등급을 변경할 수 있는가?"라는 질문에 "아니오, 변경 권장만 하고 최종 승인은 심사팀장"이라고 명시합니다. 이 정책을 온톨로지의 권한 시스템으로 구현하면, 에이전트는 자동으로 그 경계를 지킵니다. Evaluation은 "그 정책이 정말 지켜지고 있는가, 그리고 예상한 성과가 나오는가"를 지표화(KPI)하고 추적합니다.

* AI Agent Engineering이 "상태" 전이를 자동화하는 원리: 대출 신청이 "검토 대기" → "자료 수집 중" → "심사 진행 중" → "승인 대기" → "결정 완료"로 상태 전이할 때, 각 상태에서 에이전트가 실행할 액션(예: 신용평가사 호출, 리포트 생성)을 온톨로지에 미리 정의해두면, 자동화됩니다.
* Governance가 "책임 소재"를 명확히 하는 법적·조직적 구조: AI가 잘못된 판정을 했을 때 "누가 책임지는가"를 미리 정책화하면, 기업 리스크가 줄어들고 규제 심사를 통과하기 쉬워집니다.
* Evaluation KPI가 "사람의 판단"과 "AI 판단"을 수치로 비교하는 메커니즘: 심사팀장이 승인한 건과 AI가 추천한 건의 성공률을 분기별로 비교하면, AI가 얼마나 신뢰할 만한지 객관적으로 증명됩니다.

AI 에이전트가 한 팀에서 성공했다고 해서 전사 확산으로 자동 이어지지 않습니다. 확산경영 3스킬(Change Management, Productized Consulting, Executive Communication)이 필수인 이유는 "기술 혁신과 조직 변화는 다른 속도로 일어나기" 때문입니다. 심리학에서는 이를 "기술 수용 곡선(Technology Adoption Curve)"이라고 부르는데, 초기 사용자(Early Adopters) 5~10%가 도입해도 대중(Early Majority) 34%까지 확산되려면 신뢰와 증명이 필요합니다.

Change Management는 조직의 무의식적 저항("이건 우리 문화가 아니다", "이전처럼 하면 안 되나?")을 예상하고, 각 계층(경영진·팀장·실무자)에게 다른 메시지를 전달합니다. 경영진에게는 "ROI와 리스크"를, 팀장에게는 "팀 역할의 변화와 성과"를, 실무자에게는 "업무 난도 감소와 숙련도 향상"을 보여줍니다. Productized Consulting은 한 팀의 성공을 "재사용 가능한 패키지"로 만드는 단계입니다. 금융 조직의 대출 심사 AI 에이전트가 잘 작동했다면, 그 설계·코드·가이드를 "다른 팀도 적용할 수 있는 템플릿"으로 문서화합니다. Executive Communication은 그 성과를 경영진에게 "스토리텔링"으로 전달해, 다음 단계 투자 결정을 유도합니다.

* Change Management의 "저항의 심리"를 다루는 3단 구조: 먼저 "현 상태의 불편함 인식" → "변화의 이점 이해" → "새로운 역할에서의 성공 경험" 순으로 심리적 장벽을 낮춥니다.
* Productized Consulting이 "암묵지를 명시지로 변환"하는 이유: 한 팀장의 머릿속에만 있는 "성공 노하우"를 가이드·체크리스트·모듈 형태로 만들어야, 다른 팀이 복제 가능합니다.
* Executive Communication이 "ROI 스토리"로 예산을 끌어당기는 메커니즘: "처리 시간 40% 단축, 에러율 60% 감소, 연간 300억 원 비용 절감"이라는 숫자가 없으면, 경영진은 2차 투자를 승인하지 않습니다.

FDE 12스킬이 문제이해→구조설계→실행연결→확산경영 순서로 배치된 핵심 이유는 "각 단계의 산출물이 다음 단계의 입력이 되도록 설계"되었기 때문입니다. 이를 "데이터 누적 흐름(Data Accumulation Pipeline)"이라고 합니다. Problem Decomposition의 산출물(표면 문제, 병목 정의, 이해관계자 맵)은 Domain Design의 입력값이 됩니다. Domain Design의 산출물(도메인 모델, 통용 언어)은 Event Storming의 입력값이 되고, Event Storming의 산출물(이벤트 시퀀스, 상태 다이어그램)은 Service Blueprint의 입력값이 됩니다.

이 누적 구조를 따르지 않으면 어떻게 될까요? 만약 Service Blueprint부터 시작한다면, "어느 서비스 단계가 정말 중요한 병목인지" 알 수 없으므로, 구조가 사용자 니즈와 맞지 않을 가능성이 높습니다. 만약 AI Agent Engineering부터 시작한다면, "어떤 데이터를 수집해야 하고 어떤 권한으로 접근할 수 있는가"가 불명확하므로, 에이전트가 틀린 결정을 내리게 됩니다. 팔란티어 FDE 방법론이 이 순서를 고집하는 이유는 "누적 없는 실행은 재현 불가능"이기 때문입니다. 한 프로젝트에서 성공했어도, 문서화가 없으면 다음 프로젝트에서는 밑바닥부터 다시 시작합니다.

* 온톨로지 7요소가 12스킬의 누적 자산이 되는 구조: 문제이해 3스킬이 객체·속성·관계를 정의하고, 구조설계 3스킬이 액션·상태·권한을 정의하고, 실행연결 3스킬이 KPI를 정의함으로써, 온톨로지가 점진적으로 완성됩니다.
* 플랫폼 원시 요소 8가지가 재사용 가능한 블록이 되는 이유: 한 조직의 대출 심사 온톨로지, 워크플로우, 거버넌스 정책이 명확하게 정의되면, 다른 도메인(신용카드 발급, 투자 상담)에서도 같은 구조를 복제할 수 있습니다.
* FDE 성장 4단계(Awareness→Analyst→Builder→Leader)가 누적 스킬 기반으로 움직이는 까닭: 각 단계는 이전 단계의 스킬을 모두 습득했다는 전제 하에 다음 복잡도의 문제를 다룹니다.

이제 실제로 12스킬을 조직에 적용할 때의 흐름을 이해해봅시다. 다음 4단계는 팔란티어 FDE 교육 과정과 현장 실행 경험에서 도출된 증명된 프로세스입니다.

팔란티어가 금융 부문 고객들과 수행한 대출 심사 FDE 프로젝트는 이 12스킬의 누적 가치를 명확히 보여줍니다. 한 금융기관의 표면 문제는 "대출 심사 시간이 5-7일 소요된다"였지만, Problem Decomposition을 통해 진짜 병목 3개를 발견했습니다: ① 신청자 제출 서류 검증(2일 낭비) ② 신용평가사 결과 대기(1-2일 외부 대기) ③ 심사팀장의 예외 케이스 검토(불규칙한 시간). Event Storming으로 이 단계들을 시각화하니, 서류 검증은 자동화 가능하고, 신용평가 대기는 병렬화 가능하고, 예외 검토는 AI가 "리스크 등급과 추천 심의"를 미리 준비해주면 팀장의 의사결정 시간을 40% 단축할 수 있음이 명확해졌습니다.

Data Modeling 단계에서는 "신청자", "신청 서류", "신청 항목(대출액, 목적, 기간)", "심사 결과", "심의 결정"이라는 5개 핵심 객체와 그들의 속성(신청자의 신용등급·소득·보유자산, 심사 결과의 위험도·점수·의견, 결정의 승인자·일시·이유)을 정의했습니다. 이 구조를 기반으로 API Integration에서는 ① 신청자 정보 조회 API ② 신용평가사 연동 API ③ 내부 규칙 엔진 API ④ 결정 저장 API를 설계했습니다. 온톨로지에서는 "심사 결과" 상태가 "신청 접수 → 자료 검증 → 신용평가 진행 → AI 점수 산출 → 심사팀장 검토 → 최종 결정"으로 전이되며, 각 단계에서 자동화할 액션(서류 검증, 평가 호출, 점수 계산)과 수동으로 남길 액션(팀장의 예외 판정)을 명시했습니다.

AI Agent Engineering 단계에서는 팔란티어 Foundry 내 에이전트가 사용자의 "신청 건을 심사해줄래?"라는 자연어 질문을 받으면, 자동으로 ① 신청 건 정보 로드 ② 서류 검증 규칙 적용 ③ 신용평가사 호출 ④ 내부 규칙 엔진으로 위험도·점수 산출 ⑤ 심사팀장을 위한 "추천 심의 의견" 리포트 생성 ⑥ 리포트를 팀장 메일로 발송까지를 수행합니다. Governance는 "에이전트가 최종 승인은 할 수 없고 추천만 한다", "특정 위험도 이상의 건은 팀장의 수동 검토 필수" 등의 정책으로 에이전트의 행동 범위를 제한했고, Evaluation에서는 "에이전트 추천과 팀장 최종 결정의 일치율", "처리 시간", "에러율"을 매주 측정했습니다.

결과적으로 이 금융기관은 대출 심사 시간을 5-7일에서 1.5-2일로 단축했고, 에러율은 3.2%에서 0.8%로 감소했으며, 심사팀 인원을 줄이지 않으면서도 월간 처리 건수를 35% 증가시켰습니다. 이 성공이 재현 가능했던 이유는 12스킬의 누적 산출물(온톨로지, API 명세, 거버넌스 정책, KPI 대시보드)이 모두 명시적으로 문서화되어 있었기 때문입니다. 그 다음 금융기관(신용카드 발급 부문)은 이 템플릿을 기반으로 4주 만에 유사한 에이전트를 구축할 수 있었습니다.

Q1: 우리 조직이 모든 12스킬을 다 배워야 할까요, 아니면 필요한 것만 선택해서 학습할 수 있나요?

A: 개별적으로는 각 스킬을 독립적으로 배울 수 있지만, "조직의 AI 성공"을 목표로 한다면 12스킬을 누적 순서대로 배워야 합니다. 왜냐하면 이전 단계의 산출물이 다음 단계의 입력이 되기 때문입니다. 예를 들어 Data Modeling(구조설계 2번)을 먼저 배우고 Domain Design(문제이해 2번)을 건너뛰면, "어떤 데이터를 모델링할 것인가"가 불명확해집니다. 다만 조직 상황에 따라 "3개월 짧은 과정"으로 핵심 4스킬(문제이해·구조설계·실행·확산의 대표 각 1개)만 먼저 배우고, 그 후 심화 과정으로 나머지를 학습하는 방식도 있습니다. 에스비컨설팅에서는 조직별 성숙도를 진단한 후, 맞춤형 러닝 로드맵을 제안해드립니다.

Q2: Problem Decomposition과 Event Storming은 어떻게 다르며, 둘 다 해야 하나요?

A: Problem Decomposition은 "표면 문제를 왜-왜-왜로 파고들어 진짜 병목을 찾는" 세로 분석입니다. 반면 Event Storming은 "현장에서 어떤 일들이 일어나고, 그 순서가 무엇인가"를 시간 흐름으로 그리는 가로 분석입니다. Decomposition으로 "대출