FDE Loop (FDE 배치 루프)

FDE Loop 는 FDE가 현장에서 일하는 순서를 여덟 단계로 정리한 것입니다. Discover → Frame → Prioritize → Build → Deploy → Adopt → Measure → Generalize. 그리고 마지막이 다시 처음으로 이어집니다. 이 루프를 알면 AX 과제가 왜 "끝나지 않는지", 그리고 대부분의 AI 프로젝트가 왜 중간에 멈추는지가 보입니다.

여덟 단계에서 각각 하는 일

Palantir 모델의 핵심 구조도 같은 흐름입니다. 현장의 실제 문제가 들어오면 FDE가 업무와 데이터를 직접 이해하고, 빠르게 해결책을 구현하고, 실제 성과를 검증하고, 무엇이 작동했는지 학습하고, 공통 패턴을 발견해 제품·도구로 반영합니다. 그러면 다음 과제는 더 빠르고 적은 비용으로 풀리고, FDE는 더 어려운 문제로 이동합니다. 마지막 단계에서 재사용할 패턴을 남기는 이유입니다.

SI 프로젝트와 무엇이 다른가

일반적인 SI는 요구사항이 어느 정도 정의된 상태에서 시작합니다. "이 시스템을 만들어달라"는 요청이 있고, 그래서 프로젝트의 시작과 끝을 비교적 명확하게 정의할 수 있습니다. AX는 무엇을 만들어야 하는지부터 모르는 경우가 많습니다. 현장에 들어가서 왜 이 일을 이렇게 하고 있는지부터 물어야 합니다. 그리고 첫 번째 자동화를 만들면 업무 방식이 바뀌고, 바뀐 업무를 보면서 두 번째 문제가 발견됩니다.

그래서 AX는 프로젝트라기보다 지속적인 업무 개선 활동에 가깝습니다. 때로는 3개월짜리 프로젝트 하나보다 이틀짜리 자동화 20개를 계속 만드는 편이 회사에 훨씬 이롭습니다. 루프가 돌지 않으면 FDE가 아니라 SI, AI 컨설팅, 프로페셔널 서비스에 가까워지고, 계약 단위가 프로젝트인 외주 구조에서는 이 루프가 계약 범위에서 잘립니다. 루프를 회사 안에서 계속 돌리는 사람이 Internal FDE입니다.

대부분이 멈추는 자리: Build와 Deploy 사이, 그리고 Adopt

PoC까지 만드는 사람은 상당히 많습니다. FDE는 프로토타입 → 파일럿 → 프로덕션 → 운영까지 갑니다. OpenAI도 FDE를 "프로토타입에서 안정적인 프로덕션까지"의 역할로 정의합니다. 현업 AI 과제의 대부분은 LLM 문제가 아니라 LLM + ERP + DB + 메신저 + SSO + 권한 + API + 레거시 문제이고, 여기가 실제 FDE 교육에서 가장 자주 빠지는 부분입니다.

Deploy를 넘어도 Adopt가 남습니다. AI 시스템을 만들었는데 아무도 쓰지 않으면 실패입니다. 그래서 교육, 사용자 저항, 워크플로 변경, 챔피언 확보, 온보딩, 피드백, KPI 모니터링까지 FDE의 일에 들어갑니다. Palantir의 Deployment Strategist가 직접 사용자 교육을 수행하는 이유입니다. 여기서 다시 일반 개발자와 갈립니다.

Generalize — 루프를 루프로 만드는 단계

마지막 단계가 어쩌면 가장 중요합니다. 과제가 끝났을 때 "우리는 무엇을 배웠는가, 이 부서만의 문제인가, 다른 부서도 반복할 문제인가, 템플릿이나 재사용 자산으로 만들 수 있는가"를 정리합니다. OpenAI는 이를 "작동하는 패턴을 도구·플레이북·빌딩 블록으로 성문화한다"고 표현합니다.

한 사람이 HR 채용 스크리닝, 제조 품질 보고서, 영업 CRM, 재무 정산을 차례로 배치해 보면 처음에는 전부 다른 문제로 보입니다. 그런데 네 번쯤 돌면 "이것도 결국 문서 → 분류 → 승인 흐름이네", "이것도 검색 → 판단 → 실행 패턴이네"가 보이기 시작합니다. 이것이 패턴 인식이고 FDE의 핵심 전문성입니다. 과제가 쌓이면 문서 → 추출 → 검증 → 승인, 검색 → 분석 → 추천, 모니터링 → 탐지 → 에스컬레이션, 요청 → 분류 → 실행 같은 패턴이 나타나고, 그때부터 새 과제와 새 FDE가 훨씬 빠르게 움직입니다. 이 단계에서 남기는 것이 AI 자산입니다.

단계별 숙련도를 가르는 기준

같은 단계를 밟아도 깊이가 다릅니다. 내부 FDE를 키울 때 "8주 교육"이 아니라 "지금 어느 수준의 인재를 어느 수준으로 만드는가"로 말하려면 단계별 기준이 필요합니다. 아래 Level 1~3은 이 글의 설계 예시이며 공인 역량 등급이나 검증된 평가 척도가 아닙니다.

우리 과제는 어느 단계에 있는가

• 문제가 요청받은 문장이 아니라 현장 관찰에서 나왔다 (Discover)
• 업무가 트리거·행위자·입력·처리·판단·출력·예외로 구조화돼 있다 (Frame)
• 시작 전에 기준선과 KPI를 정했고, 풀지 않기로 한 문제가 있다 (Prioritize)
• 데모가 아니라 실제 업무 시스템에 연결돼 돌아간다 (Deploy)
• 만든 사람 외에 실제로 쓰는 사람이 있다 (Adopt)
• 산출물이 아니라 KPI 변화로 결과를 말할 수 있다 (Measure)
• 다음 과제에서 재사용할 자산이 문서나 코드로 남았다 (Generalize)

"예"가 앞쪽에만 몰려 있다면 과제는 Build에서 멈춰 있는 것입니다.

루프는 도구가 아니라 권한의 문제다

방법론을 이야기하는 입장에서도 솔직히 말하면, 여덟 단계를 안다고 루프가 도는 것은 아닙니다. 루프가 멈추는 진짜 이유는 대개 기술이 아니라 권한과 시간입니다. 현장에 들어가 문제를 정의할 권한이 없거나, 데이터와 시스템에 접근할 수 없거나, 기존 KPI 위에 이 일을 얹어야 해서 시간이 없으면 Discover에서 이미 막힙니다. 그래서 루프를 돌리려면 방법론과 함께 문제 정의 권한, 접근 권한, 확보된 시간, 그리고 위에서 보호해 주는 스폰서가 있어야 합니다. 개인 차원에서 이 루프의 축소판이 맡·당·쪼입니다. 맡겨보고, 안 되는 게 당연하다고 받아들이고, 쪼개서 다시 맡기는 반복이 Frame과 Build 사이를 돌리는 가장 작은 단위입니다.

단계 수보다 다음 과제에 남는 것을 확인한다

이 여덟 단계는 실행 흐름을 설명하는 구분입니다. 온톨로지의 구조화 수준이나 조직 성숙도 등급과는 다릅니다. 업무가 어떤 수준으로 표현돼 있는지와 개선을 어떤 순서로 수행하는지를 섞으면 현재 위치를 잘못 판단할 수 있습니다.

다음 과제에서 재사용할 기준·연결·결정 기록이 남았는지 확인합니다. 아직 제안만 한 내용은 실제 실행 이력과 구분하고, 중단된 실험은 성공 사례로 집계하지 않습니다.