생성형 AI 도입이 PoC(Proof of Concept) 단계에서 멈추는 이유는 모델의 정확도만으로는 설명할 수 없습니다.
실제 서비스 도입 단계에서 중요하게 다뤄지는 것은 '누구의 어떤 업무를 변화시킬 것인지', '어떤 정보를 참조해도 되는지', '오답이 나왔을 때 어떻게 막을 것인지', 그리고 '어떤 지표로 개선할 것인지'입니다. 이 모든 것을 현장에서 아우르며 진행하는 역할이 바로 FDE(Forward Deployed Engineer)입니다.
본 기사에서는 AI 챗봇이나 업무 지원 AI를 예시로, FDE 방식으로 '만들기 전', '만들기', 그리고 '운영하기' 단계를 어떻게 연결할 수 있는지 정리합니다.
FDE는 고객의 현장에서 과제를 발견하고, 관계자들과 합의하며, 구현하고, 실제 서비스에서 사용되는 상태까지 이끌어가는 역할입니다. 단순히 요구사항을 받아 납품하는 것을 넘어, 가설의 우선순위와 성공 조건 자체를 함께 정의합니다.
AI 도입에서는 특히 다음 과정들이 분리될 경우 속도를 잃기 쉽습니다.
- 과제 설정: 문의 감소, 상품 선택 지원, 사내 검색 등 첫 대상 하나로 범위를 좁히기
- 정보 설계: 참조할 수 있는 문서, 최신성 확보 방안, 답변 금지 영역 결정
- 구현: 검색, 프롬프트(Prompt), 권한, UI, 기존 시스템 연동을 구성하기
- 평가: 정답률뿐만 아니라 해결률, 사람에게 인계될 비율, 다음 행동으로의 연결률 확인
- 정착: 로그에서 부족한 정보를 찾아 FAQ나 업무 흐름도 개선하기
생성형 AI를 사용할 때 가장 먼저 만들어야 할 것은 화려한 화면이 아니라 '답변 경계'입니다. 최소한 다음 사항들을 문서화해야 합니다.
- 참조원: 공개 FAQ, 상품 데이터, 사내 규정 등
- 답변 가능한 질문: 예시로 배송 조건, 상품 사양, 사내 절차
- 답변하지 않을 질문: 개인 정보, 계약 판단, 법무·의료·금융상의 판단
- 에스컬레이션(Escalation) 조건: 근거가 없거나, 확신도가 낮거나, 권한을 벗어나거나, 긴급성이 있을 경우
- 로그 방침: 보관 기간, 열람자, 개인 정보 마스킹, 삭제/중단 절차
RAG(Retrieval-Augmented Generation)를 채택하더라도 참조 데이터가 오래되거나, 권한이 섞이거나, 근거를 제시하지 못하는 등의 문제는 남아 있습니다. 데이터 취득·분할·검색·답변 생성의 각 단계에서 어떤 정보가 통과해도 되는지 확인할 수 있는 설계로 만들어야 합니다.
PoC는 '작동'만으로는 충분하지 않습니다. 릴리스 전에는 실제 문의나 업무 사례를 바탕으로 테스트 세트를 만들고 합격/불합격 기준을 가져야 합니다.
| 관점 | 예시 |
|---|
| 정확성 | 근거에 따른 답변인지 |
| ... | |
| 테스트는 정상적인 경우만으로는 부족합니다. 모호한 질문, 지시를 덮어쓰려는 입력, 권한을 벗어난 정보 요청, 오래된 문서만 있는 케이스, 연속 전송, 외부 연동이 실패하는 케이스까지 확인해야 합니다. | |
릴리스 후에는 대화 수만을 추적해서는 개선점을 찾을 수 없습니다. FDE 방식의 운영에서는 다음과 같은 지표를 주기적으로 확인합니다.
- 답변 후 자가 해결 또는 다음 페이지로 이동한 비율
- 사람 대응으로 인계된 비율과 이유
- 답변할 수 없었던 질문의 분류
- 참조원별 이용 빈도와 업데이트 상황
- 에러율, 응답 시간, 이용 상한 도달 상황
여기에 더해, 설정·프롬프트·참조 데이터를 변경했을 때 이전 상태로 되돌릴 수 있도록 하는 것이 필수적입니다. 변경 이력, 테스트 세트, 릴리스 판단, 롤백(Rollback) 절차를 작더라도 남겨야 합니다.
AI가 구현 속도를 높여주더라도 '무엇을 만들 것인지', '안전하게 사용할 수 있는지', '현장에서 가치를 창출했는지'는 자동으로 결정되지 않습니다. FDE는 과제 설정, 구현, 평가, 운영을 분리하지 않고 다루기 위한 실질적인 역할입니다.
쿠마모토에서의 AI·FDE 도입 지원과 더 자세한 해설은 아래에 정리했습니다.
