AX를 위한 FDE 양성: SI와 Citizen Developer와 무엇이 다른가
FDE는 현장 업무를 AI 워크플로와 권한·로그·예외 처리 구조로 번역하는 역할입니다. SI, Citizen Developer와의 차이와 양성 방법을 정리합니다.
FDE는 현장 업무를 AI가 실행할 수 있는 단위로 나누고, 도구·권한·로그·사람 승인 경계를 함께 설계하는 역할입니다.
왜 지금 FDE인가
교육도 했고, 파일럿도 돌렸다. 프롬프트 교육과 노코드 도구 교육까지 마쳤는데, 다음 날 돌아보면 AI 에이전트는 여전히 “답변 초안” 단계에 머물러 있다. 문제는 보통 사람도 모델도 아니다. 업무가 AI가 안전하게 실행할 수 있는 단위로 쪼개져 있지 않다는 것이다.
AX는 “AI를 붙이는 프로젝트”가 아니라 “업무를 AI가 실행할 수 있는 단위로 다시 설계하는 일”에 가깝다. 그래서 필요한 사람도 달라진다. 기존 SI 인력, 현업 Citizen Developer, 데이터/AI 전문가만으로는 빈틈이 생긴다. 그 빈틈을 메우는 역할이 FDE다.
왜 지금 FDE인가
기업의 디지털 전환은 오랫동안 시스템 구축 중심이었다. ERP, 그룹웨어, CRM, MES, 물류·품질 시스템을 만들고, 화면과 메뉴를 제공하고, 사용자가 정해진 절차대로 입력하도록 교육했다. 자동화도 있었다. RPA, 매크로, 노코드 도구, 현업 개발자 운동도 있었다.
그런데 AX, 즉 AI Transformation은 조금 다르다. AI 에이전트가 단순히 답변을 생성하는 수준을 넘어, 도구를 호출하고, 데이터를 읽고, 중간 산출물을 만들고, 승인 요청을 올리고, 예외를 감지하는 방향으로 확장되고 있기 때문이다.
IBM은 AI 에이전트를 “가용한 도구로 워크플로를 설계하며 자율적으로 업무를 수행하는 시스템”으로 설명한다.[1] 이 정의를 기업 업무에 적용하면 핵심 질문은 모델 성능이 아니라 다음으로 이동한다.
마이크로소프트 WorkLab도 같은 방향을 짚는다. 기업의 CRM, ERP, 프로젝트 관리 도구, 생산성 도구는 모두 “주요 사용자가 사람”이라는 가정 위에 만들어졌는데, 그 가정이 더는 성립하지 않는다는 것이다. 에이전트는 이미 메뉴나 교육 없이 기계 속도로 기업 소프트웨어 스택 안에서 작동하고 있으며, 사람이 몇 시간·며칠 걸리던 일을 몇 초·몇 분 만에 처리한다는 설명이다.[4]
우리 회사의 업무는 AI가 안전하게 실행할 수 있을 만큼 잘게 정의되어 있는가?
이 질문에 답하려면 기존 역할 구분만으로는 부족하다. SI는 시스템을 구축하고 통합하는 데 강하다. Citizen Developer는 자기 업무의 작은 병목을 빠르게 자동화하는 데 강하다.
하지만 AX는 둘 사이의 회색지대가 크다. 업무 맥락을 이해하면서도, AI가 호출할 수 있는 작업 단위와 권한, 로그, 승인 경계, 예외 처리까지 설계해야 한다.
기존 역할이 각각 잘하는 것과 AX 맥락에서 혼자서는 맡기 어려운 영역을 표로 정리하면 다음과 같다.
| 역할 | 잘하는 것 | AX에서 혼자 맡기 어려운 것 |
|---|---|---|
| SI / 통합 파트너 | 대규모 시스템 구축·연계·운영 이관 | 업무 흐름에서 출발한 작업 단위 정의, 에이전트 실행 조건 설계 |
| Citizen Developer | 자기 부서의 작은 병목을 노코드·로코드로 빠르게 해결 | 여러 시스템을 가로지르는 권한·로그·승인 거버넌스 |
| 데이터 / AI 전문가 | 모델 선정, 데이터 파이프라인, 평가 | 현장 업무 맥락, 운영 조건, 변화관리 |
FDE는 이 표의 빈틈을 채우는 역할이다. 어느 하나를 대체하는 것이 아니라, 현장의 문제 정의와 시스템 구축 사이를 연결한다.
기존 SI와 무엇이 다른가
SI 업체는 기업 IT에서 여전히 중요하다. 대규모 시스템 구축, 패키지 도입, 데이터 연계, 운영 이관, 유지보수는 전문성과 규모가 필요한 일이다. AX에서도 SI의 역할은 사라지지 않는다. 오히려 ERP, CRM, 그룹웨어, 제조 시스템, 데이터 플랫폼과 AI 에이전트를 연결하려면 시스템 통합 역량이 더 중요해질 수 있다.
다만 FDE가 SI와 다른 지점은 “무엇을 납품하느냐”보다 “어디서 문제를 정의하느냐”에 있다.
| 구분 | 전통적 SI 중심 접근 | FDE 접근 |
|---|---|---|
| 출발점 | 요구사항 정의서, 기능 목록, 화면/배치/인터페이스 | 현장 업무 흐름, 반복 판단, 예외, 승인 지점 |
| 주요 산출물 | 시스템, 화면, 연계, 리포트, 운영 문서 | AI가 호출할 수 있는 업무 단위, 도구 명세, 권한 경계, 실행 로그 설계 |
| 성공 기준 | 기한·범위·예산 내 구축, 장애 없는 운영 | 사람이 하던 반복 실행이 안전하게 줄고, 예외와 책임 소재가 명확해짐 |
| 사용자 가정 | 사람 사용자가 화면을 보고 입력한다 | 사람과 AI 에이전트가 함께 업무를 수행한다 |
| 변경 방식 | 프로젝트 단위 변경, CR, 릴리즈 | 업무 실험 → 파일럿 → 권한 확장 → 운영화 |
SI는 “시스템을 만드는 힘”이다. FDE는 “업무를 AI가 실행 가능한 구조로 번역하는 힘”이다. 둘은 대체 관계가 아니라 연결 관계에 가깝다. FDE가 현장에서 문제를 쪼개고, 어떤 작업을 AI 도구화할지 정의하고, 검증 기준을 만든 뒤, SI나 내부 플랫폼팀이 이를 안정적인 시스템으로 확장하는 구조가 현실적이다.
Citizen Developer와 무엇이 다른가
Citizen Developer는 현업 사용자가 노코드·로코드 도구로 직접 앱이나 자동화를 만드는 흐름을 말한다. 이 접근의 장점은 분명하다. 중앙 IT가 모든 요청을 처리하기 어렵기 때문에, 현업이 자기 문제를 빠르게 해결할 수 있다. 작은 승인 앱, 엑셀 취합 자동화, 알림 봇, 간단한 조회 화면은 Citizen Developer 방식으로 효과를 낼 수 있다.
하지만 AX에서 Citizen Developer 방식만으로는 한계가 있다.
첫째, AI 에이전트는 단순 자동화보다 실패 양상이 복잡하다. 엑셀 값을 옮기는 자동화는 규칙이 틀리면 오류가 비교적 명확하다. 반면 AI 에이전트는 잘못된 문맥을 읽거나, 부정확한 근거로 초안을 만들거나, 권한 밖 데이터를 참고하거나, 사람이 승인해야 할 일을 과도하게 진행할 수 있다.
둘째, 부서별 자동화가 많아질수록 거버넌스 문제가 커진다. 누가 어떤 데이터를 읽었는지, 어떤 근거로 판단했는지, 어느 시점에 사람이 승인했는지, 실패하면 어떻게 되돌릴지 기록되어야 한다. NIST AI Risk Management Framework가 강조하는 것처럼 AI 리스크 관리는 기술 성능만이 아니라 거버넌스와 측정, 관리의 문제이기도 하다.[2]
조금 더 구체적으로, NIST AI RMF 1.0은 리스크 관리 체계를 GOVERN(거버넌스), MAP(리스크 맥락 파악), MEASURE(측정), MANAGE(관리) 네 기능으로 구성한다.[3] 이 구조는 RMF 1.0 기준이며, NIST는 현재 RMF 1.0 개정을 진행 중이다.[2] 이를 부서별 AI 자동화에 적용하면, FDE의 일은 자동화가 시작된 뒤에 문제를 수습하는 것이 아니라 자동화 전에 거버넌스 항목(누가 승인하고, 무엇을 기록하고, 실패 시 어떻게 되돌리는지)을 설계서로 만들어 두는 데 가깝다.
셋째, Citizen Developer는 자기 업무에 강하지만, 여러 시스템을 가로지르는 운영 설계에는 부담이 크다. AX는 종종 그룹웨어, 메일, 문서, ERP, 데이터베이스, 사내 포털, 제조/품질 시스템을 함께 건드린다. 이때 필요한 것은 “앱 하나 만들기”가 아니라 “AI가 어떤 순서로 무엇을 확인하고, 어디서 멈추며, 누구에게 넘길 것인가”를 설계하는 능력이다.
제가 저희 공장 품질 부서에서 실제로 본 장면을 들겠다. MES 알람을 처리하는 방식이다. Citizen Developer 방식이라면 알람이 올 때 담당자에게 알림을 보내는 봇을 만드는 데서 끝날 수 있다. FDE는 다르게 쪼갠다. 에이전트가 알람의 원인이 되는 공정 파라미터를 조회하고, 과거 동일 패턴의 조치 이력을 대조해 오탐 가능성을 분류하고, 초동 조치 초안을 작성하되, 품질 등급 하향이 걸린 알람은 반드시 담당자 확인을 받도록 멈추는 지점을 설계한다. 같은 알람이라도 “알림 보내기”와 “실행 가능한 업무 단위 설계”는 다른 층의 일이다.
따라서 Citizen Developer는 AX의 출발점이 될 수 있지만, FDE는 더 넓은 책임을 진다. 현업 문제를 찾는 데서 끝나지 않고, 그 문제를 기업 운영 구조 안에서 안전하게 실행 가능한 AI 워크플로로 바꾸는 역할이다.
FDE의 핵심 역량
FDE를 “AI를 잘 쓰는 현업” 정도로 보면 부족하다. 반대로 “개발도 하고 컨설팅도 하는 만능 인력”으로 보면 양성이 불가능해진다. 현실적인 정의는 다음에 가깝다.
FDE는 현장 업무와 AI/데이터/시스템 사이에 서서, 반복 업무를 AI가 실행 가능한 단위로 재구성하고 운영 조건을 설계하는 사람이다.
이를 위해 필요한 역량은 네 묶음이다.
1. 업무 해부 능력
FDE는 먼저 업무를 기능이 아니라 흐름으로 본다.
- 이 업무의 시작 이벤트는 무엇인가?
- 사람이 반복적으로 확인하는 정보는 무엇인가?
- 판단 기준은 규칙인가, 경험인가, 예외 대응인가?
- 실패했을 때 비용이 큰 단계는 어디인가?
- 최종 책임자는 누구인가?
AX에서 좋은 대상은 “사람이 싫어하는 일”이 아니라 “반복되지만 예외 기준이 설명 가능하고, 사람이 승인할 경계가 명확한 일”이다.
2. AI 워크플로 설계 능력
AI 에이전트는 프롬프트만으로 운영되지 않는다. 어떤 도구를 호출할지, 어떤 입력을 받을지, 어떤 결과 형식을 낼지, 어떤 상황에서 멈출지 정해야 한다.
앤스로픽의 에이전트 가이드도 이 구분을 명확히 한다. 워크플로는 LLM과 도구가 사전에 정의된 코드 경로(code path)로 오케스트레이션되는 구조이고, 에이전트는 자신의 처리 과정과 도구 사용을 스스로 동적으로 지시하는 구조다.[7] 즉 “AI 워크플로를 설계한다”는 말은 프롬프트 문장을 다듬는 일이 아니라, 실행 경로와 도구 호출, 사람에게 넘기는 지점을 미리 결정하는 일이다.
예를 들어 구매 요청 검토 에이전트를 만든다고 하자. 단순히 “이 구매 요청을 검토해줘”라고 시키면 위험하다. FDE는 이를 다음 단위로 쪼갠다.
- 요청 품목과 금액 추출
- 예산 코드와 잔액 확인
- 계약 또는 기존 공급사 여부 확인
- 보안·법무 검토 필요 조건 확인
- 승인권자 후보 산정
- 근거와 함께 승인 요청 초안 작성
- 기준 밖이면 사람에게 중단·에스컬레이션
이런 구조가 있어야 AI가 “말”이 아니라 “업무 실행”에 가까워진다.
3. 권한·로그·승인 경계 설계 능력
기업 AX의 병목은 모델보다 권한일 가능성이 높다. 사람이 로그인해서 화면을 보는 방식으로 설계된 시스템은 AI 에이전트에게 그대로 열어주기 어렵다. 사람의 계정을 빌려 쓰게 하면 책임 소재가 흐려지고, 과도한 권한이 부여될 수 있다.
오픈AI의 에이전트 실무 가이드도 같은 방향이다. 에이전트가 호출하는 도구·기능별로 위험도를 평가하고, 고위험 기능은 실행 전에 가드레일 점검을 거치거나 사람에게 에스컬레이션하도록 자동 동작을 걸라고 권한다.[8] 에스컬레이션 조건은 실패 순간에 판단하는 것이 아니라 설계 단계에서 박아두는 것이라는 뜻이다.
따라서 FDE는 업무별 위임 권한을 설계해야 한다.
- AI가 읽을 수 있는 데이터 범위
- AI가 작성할 수 있는 초안과 실제 실행의 구분
- 사람 승인 없이 가능한 작업과 반드시 승인해야 하는 작업
- 실행 로그에 남길 입력, 도구 호출, 근거, 결과
- 실패 시 중단·롤백·재처리 조건
이 부분이 없으면 AX는 파일럿 데모에서 멈춘다. 실제 운영으로 가려면 “누가 무엇을 했는지”가 아니라 “어떤 AI 실행이 어떤 근거와 승인으로 진행됐는지”를 남겨야 한다.
4. 현장 변화관리 능력
AX는 기술 프로젝트이면서 동시에 업무 방식 변화다. 현업은 AI가 일을 빼앗는다고 느낄 수 있고, IT는 통제되지 않는 자동화를 걱정할 수 있으며, 보안 조직은 데이터 접근을 우려할 수 있다. FDE는 이 사이를 조정해야 한다.
좋은 메시지는 “AI가 사람을 대체한다”가 아니다. 더 현실적인 설명은 다음이다.
- 사람은 목표, 판단, 승인, 예외 처리, 책임을 맡는다.
- AI는 반복 실행, 자료 수집, 초안 작성, 사전 검토를 맡는다.
- 시스템은 권한, 로그, 승인, 롤백을 보장한다.
이렇게 역할을 나눠야 AX가 조직 안에서 받아들여진다.
그러면 어떻게 양성해야 하는가
FDE는 강의만으로 만들어지기 어렵다. 업무, 데이터, 시스템, AI 도구, 보안·권한, 변화관리가 함께 엮이기 때문이다. 따라서 양성 방식도 “교육 과정”보다 “현장 문제 해결형 트랙”이어야 한다.
1단계: 후보를 직무가 아니라 문제 감각으로 선발한다
좋은 FDE 후보는 반드시 개발자일 필요는 없다. 그러나 다음 감각은 필요하다.
- 현업 프로세스의 병목을 설명할 수 있다.
- 반복 업무와 예외 업무를 구분할 수 있다.
- 데이터의 출처와 품질을 의심할 수 있다.
- IT·보안·현업 사이의 언어를 번역할 수 있다.
- 작은 자동화를 끝까지 운영해 본 경험이 있다.
개발 능력은 있으면 좋지만, 처음부터 풀스택 개발자를 요구하면 풀이 좁아진다. 대신 기본 데이터 리터러시, API·워크플로 개념, 프롬프트/평가 기초, 보안 감각을 단계적으로 훈련하는 편이 현실적이다.
2단계: 교육 주제를 도구가 아니라 산출물 중심으로 짠다
“생성형 AI 사용법”, “프롬프트 엔지니어링”, “노코드 툴 교육”만으로는 부족하다. FDE 교육은 산출물을 기준으로 설계해야 한다.
| 교육 모듈 | 최종 산출물 |
|---|---|
| 업무 해부 | 업무 흐름도, 반복/예외/승인 지점 목록 |
| 데이터·시스템 맵 | 필요한 데이터 원천, 접근 권한, API/화면/파일 경로 |
| 에이전트 워크플로 | 도구 호출 순서, 입력·출력 스키마, 중단 조건 |
| 프롬프트·평가 | 정답 예시, 실패 예시, 평가 체크리스트 |
| 권한·로그 설계 | 위임 권한 범위, 승인 단계, 감사 로그 항목 |
| 파일럿 운영 | 전후 시간 절감, 오류 유형, 사용자 피드백, 확장 조건 |
핵심은 교육생이 “AI를 써봤다”가 아니라 “하나의 업무를 운영 가능한 AI 워크플로로 바꿔봤다”를 경험하게 하는 것이다.
3단계: 작은 업무를 끝까지 운영해보게 한다
FDE 양성에서 가장 중요한 것은 파일럿의 크기다. 너무 큰 과제를 주면 시스템 연계와 이해관계자 조정에 막혀 학습이 느려진다. 너무 작은 과제는 데모로 끝난다.
좋은 첫 과제는 다음 조건을 만족한다.
- 월 단위가 아니라 주 단위로 반복된다.
- 입력과 출력이 비교적 명확하다.
- 사람이 최종 승인할 수 있다.
- 실패해도 치명적 손실이 작다.
- 자동화 전후 효과를 측정할 수 있다.
예를 들어 회의록 요약만으로는 부족하다. 대신 “회의록에서 액션아이템을 추출하고, 담당자·기한 누락을 감지해 확인 요청 초안을 만들고, 담당자가 승인하면 업무관리 도구에 등록한다” 정도가 AX형 과제에 가깝다.
운영 원칙 체크포인트: 파일럿을 운영하기 전에 확인할 5가지
AI 워크플로를 실제로 운영하는 조직의 운영 원칙을 일반화하면, 파일럿 운영 전에 확인할 점검 항목은 다음 다섯 가지다.
- 초안과 근거의 분리 — AI가 만든 결과물(초안·판단 제안)과 판단의 근거(입력, 도구 호출, 참고 데이터)는 분리해서 기록한다.
- 실행과 검증의 분리 — 워크플로를 설계·실행한 주체가 결과를 직접 평가하게 두지 않고, 검증 주체를 따로 둔다.
- 운영화 전 3단계 게이트 — 권한 검토, 예외 시나리오(중단·롤백), 측정 기준(전후 비교)을 운영화 전에 확인한다.
- 변경 이력 공개 — 워크플로가 바뀌면 무엇이 왜 바뀌었는지 기록하고 이해관계자에게 남긴다.
- 사람 승인 경계 유지 — 환불 승인, 결제, 외부 발송처럼 영향도가 큰 작업은 에이전트의 신뢰가 쌓일 때까지 사람 승인을 유지한다.[8]
이 다섯 가지는 “준수 문서”가 아니라, 파일럿의 결과를 다음 과제에 재사용할 수 있는 경험으로 만드는 최소 장치다.
4단계: 내부 플랫폼팀·SI와의 역할 분담을 정한다
FDE가 모든 것을 직접 개발하게 만들면 지속 가능하지 않다. FDE는 현장 문제를 정의하고, 워크플로를 설계하고, 파일럿을 검증하는 데 집중해야 한다. 플랫폼팀은 공통 도구, 인증, 로그, API 게이트웨이, 평가 환경을 제공한다. SI나 외부 파트너는 검증된 패턴을 시스템화하고 확장하는 역할을 맡을 수 있다.
역할 분담은 다음처럼 잡을 수 있다.
| 역할 | 책임 |
|---|---|
| 현업 FDE | 문제 발굴, 업무 해부, 파일럿 설계, 사용자 피드백 |
| AI/데이터 플랫폼팀 | 모델·RAG·도구 호출·평가·모니터링 기반 제공 |
| 보안/거버넌스 | 데이터 접근, 위임 권한, 로그, 승인 정책 검토 |
| SI/외부 파트너 | 검증된 워크플로의 시스템 통합, 운영 안정화, 확장 구축 |
| 업무 책임자 | 최종 승인 경계, KPI, 예외 처리 기준 결정 |
이렇게 해야 FDE가 “혼자 다 하는 사람”이 아니라 “현장 AX를 운영 가능한 구조로 만드는 연결자”가 된다.
FDE 양성의 실패 패턴
FDE를 만들 때 흔한 실패는 세 가지다.
첫째, 프롬프트 교육으로 끝나는 경우다. 프롬프트는 필요하지만, 기업 AX의 본질은 프롬프트보다 권한과 워크플로다. 좋은 문장을 쓰는 능력보다 어떤 정보를 읽고, 어떤 도구를 부르며, 어디서 사람에게 넘길지 설계하는 능력이 더 중요하다.
둘째, 현업 자동화를 방치하는 경우다. 부서별로 작은 AI 자동화가 늘어나면 초기에는 속도가 빨라 보인다. 그러나 데이터 접근, 로그, 보안, 유지보수 기준이 없으면 나중에 중앙에서 통제하기 더 어려운 그림자 자동화가 된다.
셋째, 중앙 AI 조직이 모든 과제를 직접 수행하려는 경우다. 중앙 조직은 표준과 플랫폼을 만들 수 있지만, 모든 업무 맥락을 알 수는 없다. AX는 현장의 세부 맥락 없이는 깊어지지 않는다. 그래서 중앙 플랫폼과 현장 FDE의 조합이 필요하다.
결론: AX의 병목은 모델이 아니라 운영 설계다
AX 시대에 기업이 키워야 할 사람은 단순한 AI 파워유저가 아니다. 기존 SI를 대체할 내부 개발자도 아니고, 노코드 도구를 잘 쓰는 Citizen Developer만도 아니다.
FDE는 현장의 업무 언어를 AI 실행 언어로 번역하는 사람이다. 업무를 쪼개고, 데이터와 도구를 연결하고, 권한과 로그를 설계하고, 사람이 승인해야 할 경계를 정한다. 이 역할이 있어야 AI 에이전트는 데모 챗봇을 넘어 실제 업무 프로세스 안으로 들어갈 수 있다.
따라서 FDE 양성의 목표는 “AI를 잘 쓰는 사람을 늘리는 것”이 아니라 “AI가 안전하게 일할 수 있는 업무 구조를 설계하는 사람을 만드는 것”이어야 한다. SI, Citizen Developer, 중앙 AI 조직은 모두 필요하다. 다만 AX의 성패는 이들을 연결해 현장 문제를 운영 가능한 AI 워크플로로 바꾸는 FDE 층을 얼마나 빨리 만들 수 있느냐에 달려 있다.
다음 질문은 자연스럽게 이어진다. 그렇다면 첫 해부 대상 업무는 무엇을 기준으로 고르고, 파일럿의 성공은 어떤 지표로 재는가. 이것은 이 글의 범위를 벗어나므로 별도의 글에서 다룰 주제다.
확인한 출처 / 근거
- IBM, What Are AI Agents? — AI 에이전트의 도구 활용과 자율적 업무 수행 정의.
- NIST, AI Risk Management Framework — AI 리스크 관리와 거버넌스의 공식 개요.
- NIST, AI Risk Management Framework 1.0 (NIST AI 100-1 PDF) — GOVERN·MAP·MEASURE·MANAGE 네 기능의 직접 근거.
- Microsoft WorkLab, AI@Work: When software’s biggest users aren’t human — 에이전트가 기업 소프트웨어의 사용자로 확장되는 변화.
- Anthropic Engineering, Building effective agents — 사전 정의된 워크플로와 동적으로 도구를 사용하는 에이전트의 구분.
- OpenAI, A practical guide to building agents (PDF) — 도구 위험도 평가, 가드레일, 고위험 작업의 사람 에스컬레이션 원칙.
이 글은 공개 자료를 바탕으로 AX의 운영 조건을 설명한 기술 해설입니다. 비교표는 역할의 우열이나 단일한 정답을 제시하기 위한 것이 아니며, 조직과 업무 조건에 따라 달라질 수 있습니다.