AI 도입 프로젝트가 멈추는 지점은 모델 선정이나 화면 개발이 아닐 때가 많습니다. 현업은 “업무에 맞게 만들어 달라”고 말하지만, 개발팀은 어떤 데이터를 어떤 기준으로 처리해야 하는지 확정하지 못합니다. 외부 업체는 데모를 빠르게 만들 수 있어도, 운영 중 발생할 예외와 책임 경계까지 결정하기는 어렵습니다.
이때 검토하는 역할이 FDE(Forward Deployed Engineer)입니다. FDE는 고객 조직 가까이에서 업무 문제를 파악하고, 데이터를 연결하며, 특정 현장에서 작동하는 제품·시스템을 구현하는 엔지니어를 가리킵니다. 팔란티어의 FDE 채용 설명도 고객 환경에 깊이 들어가 문제를 맡고, 첫 논의부터 운영 환경에 제품을 배포할 때까지 프로젝트를 책임지는 역할을 제시합니다.
다만 FDE는 구매 가능한 직함이 아닙니다. 어떤 업체는 자사 플랫폼을 배포하는 기술 인력을 FDE라고 부르고, 어떤 업체는 고객별 애플리케이션과 데이터 흐름까지 만드는 역할로 사용합니다. 따라서 “FDE 투입”이라는 제안만으로는 부족합니다. CTO와 개발 리드는 이 역할이 우리 프로젝트에서 문제를 정의할 권한, 시스템을 바꿀 권한, 배포 후 운영을 맡을 책임을 어디까지 갖는지 확인해야 합니다.
FDE가 필요한 프로젝트와 그렇지 않은 프로젝트
FDE가 적합한 경우는 요구사항 문서가 부족해서가 아닙니다. 현업과 기술팀이 함께 확인해야 할 미지의 영역이 크고, 그 확인 결과에 따라 제품 형태가 바뀔 수 있을 때입니다.
예를 들어 다음 상황에서는 FDE 방식이 검토 대상이 될 수 있습니다.
- 여러 시스템에 데이터가 흩어져 있어, 어떤 데이터가 업무 판단에 쓸 만한지부터 확인해야 한다.
- 업무 담당자가 예외를 많이 처리하지만, 그 예외 기준이 문서나 규칙으로 정리되어 있지 않다.
- AI 기능을 붙이려 하지만, 모델의 응답을 누가 검토하고 어떤 결과를 실행할지 정해지지 않았다.
- 파일럿 화면은 만들 수 있으나, 운영 환경의 권한·데이터 연결·사용자 절차까지 정해야 한다.
- 현업 부서와 개발팀이 각각 다른 문제를 우선순위로 보고 있어, 한쪽의 요구사항만 받아 개발하면 재작업 위험이 크다.
반대로 기능, 입력값, 처리 규칙, 책임 부서가 이미 안정되어 있다면 일반적인 제품 개발이나 SI 구축 방식이 더 맞을 수 있습니다. 이 경우 FDE를 투입해 현장 탐색을 길게 하는 것보다, 명세와 인터페이스를 확정하고 구현·테스트·인수를 관리하는 편이 낫습니다.
판단 기준은 기술 난도가 아닙니다. 무엇을 만들어야 하는지 현장에서 발견해야 하는가가 기준입니다.
업체 제안서에서 분리해 볼 세 가지 책임
FDE를 포함한 외부 제안은 종종 “컨설팅부터 구축, 운영까지 지원”처럼 넓게 표현됩니다. 발주사 입장에서는 이 문장을 세 가지 책임으로 나눠야 합니다. 하나로 묶으면 계약 뒤에 기대가 엇갈립니다.
1. 문제 정의 책임
문제 정의는 인터뷰를 많이 하는 일이 아닙니다. 업무 흐름에서 누가 어떤 판단을 내리고, 어떤 데이터가 부족하며, 어느 단계의 오류가 비용이나 지연으로 이어지는지 확인하는 일입니다.
업체에 다음을 물어볼 수 있습니다.
- 첫 단계에서 어떤 업무 흐름을 관찰하고, 어떤 산출물로 문제를 확정하는가?
- 현업의 요구와 시스템 제약이 충돌할 때, 우선순위를 누가 결정하는가?
- 발견한 문제를 기능 목록으로 바꾸는 기준은 무엇인가?
- 해결하지 않기로 한 문제와 이유도 기록하는가?
- 고객사 제품 책임자나 현업 책임자가 참여해야 하는 의사결정 회의는 무엇인가?
이 단계의 인수 기준은 “인터뷰 완료”가 아니라, 우선순위가 있는 문제 목록과 업무 시나리오, 데이터 출처, 결정권자가 합의한 범위여야 합니다.
2. 구현 권한과 변경 범위
FDE의 강점은 현장 문제를 구현으로 연결하는 데 있습니다. 그러나 외부 인력이 고객사의 데이터 모델, 권한 체계, 배포 환경을 임의로 바꿀 수 있다는 뜻은 아닙니다.
계약 전에는 FDE가 만들 수 있는 것과 제안만 할 수 있는 것을 구분해야 합니다.
| 구분 | 계약서에서 정할 내용 |
|---|---|
| 애플리케이션 | 신규 화면·업무 도구·자동화 워크플로를 어디까지 개발하는가 |
| 데이터 | 조회, 정제, 적재, 원본 수정 중 허용 범위는 어디까지인가 |
| AI 기능 | 답변·분류·추천 결과를 표시만 하는지, 후속 업무를 실행하는지 |
| 시스템 연동 | API 연결, 파일 교환, 계정 생성, 권한 변경의 승인 주체는 누구인지 |
| 배포 | 개발·검증·운영 환경별 배포 권한과 승인 절차는 무엇인지 |
| 코드와 설정 | 소스코드, 프롬프트, 워크플로 설정, 운영 문서의 소유·인계 방식은 무엇인지 |
특히 AI 기능이 포함되면 “작동하는 데모”와 “운영 가능한 기능”을 구분해야 합니다. 운영 환경에서는 입력 데이터가 바뀌고, 예상하지 못한 출력이 생기며, 사용자 행동도 시험 환경과 달라질 수 있습니다. NIST도 배포 전 평가는 통제된 환경에서 이뤄지는 경우가 많으므로, 실제 환경에서 신뢰성·예상 밖 출력·의도하지 않은 결과를 확인하는 배포 후 모니터링이 중요하다고 설명합니다.
따라서 AI FDE 계약에는 모델 선택만 넣지 말고, 운영 중 무엇을 기록하고 누가 검토하며 어떤 조건에서 기능을 중단하거나 되돌릴지까지 넣는 편이 안전합니다.
3. 운영 책임
외부 FDE가 운영까지 맡는다고 해도, 고객사가 책임을 넘길 수 있는 것은 아닙니다. 현업 규칙의 변경, 데이터 접근 승인, 결과를 업무에 반영할지 여부는 고객 조직의 의사결정입니다.
업체가 맡을 운영 범위는 다음처럼 행동 단위로 적는 편이 좋습니다.
- 오류·실패·예외 입력을 어떤 방식으로 기록하는가
- 성능 저하나 비정상 결과를 누가 먼저 탐지하는가
- 현업 사용자가 수정·반려한 결과를 개선에 어떻게 반영하는가
- 데이터 구조나 업무 규칙이 바뀌었을 때 변경 요청을 누가 승인하는가
- 장애 시 임시 중단, 수동 처리, 이전 버전 복구를 누가 결정하는가
- 계약 종료 후 운영 담당자가 어떤 문서와 접근 권한을 인수하는가
운영 책임이 없는 FDE 투입은 파일럿 제작에 가까울 수 있습니다. 반대로 운영 책임까지 포함하면, 발주 범위는 개발 인력 공급이 아니라 제품 운영 체계 설계에 가까워집니다. 두 계약은 비용과 일정뿐 아니라 고객사의 내부 참여 방식도 달라집니다.
내부 FDE와 외부 FDE를 나누는 기준
내부 인력과 외부 업체 중 한쪽만 선택해야 하는 것은 아닙니다. 다만 역할을 섞어 두면 외부 인력이 떠난 뒤 문제 정의 능력과 운영 지식도 함께 빠져나갈 수 있습니다.
내부 인력이 맡기 적합한 영역은 다음과 같습니다.
- 업무 우선순위와 성공 기준 결정
- 데이터 제공 및 접근 권한 승인
- 현업 예외 규칙의 최종 판단
- 운영 중 기능 사용 여부와 변경 승인
- 장기 제품 로드맵과 조직 간 조정
외부 FDE에게 맡기기 적합한 영역은 프로젝트 조건에 따라 달라집니다.
- 제한된 기간 안에 현장 탐색과 기술 구현을 함께 진행해야 하는 경우
- 특정 플랫폼, 데이터 엔지니어링, AI 배포 경험이 내부에 부족한 경우
- 내부 팀이 제품 책임은 맡되, 초기 설계와 구현 속도를 보완해야 하는 경우
- 운영 조직에 넘기기 전까지 재현 가능한 시스템·문서·검증 절차를 만들어야 하는 경우
외부 업체가 현업 인터뷰와 프로토타입을 주도하더라도, 고객사에는 최소한 한 명의 제품 책임자와 한 명의 기술 책임자가 필요합니다. 이 두 사람이 없으면 FDE는 문제를 발견해도 우선순위를 확정할 수 없고, 구현해도 운영 조직에 넘길 기준을 만들기 어렵습니다.
제안 요청서에 넣을 검증 질문
업체의 FDE 역량은 보유 인원 수나 소개 자료보다, 불확실한 문제를 어떻게 좁히고 운영 가능한 결과물로 넘기는지에서 드러납니다. 제안 발표에서는 아래 질문에 구체적으로 답하도록 요청해 볼 수 있습니다.
- 요구사항이 불완전한 프로젝트에서, 첫 4~8주에 무엇을 확인하고 어떤 산출물로 범위를 고정합니까?
- 현업 요청이 계속 늘어날 때, 기능 우선순위를 정하는 회의체와 결정권자는 어떻게 설계합니까?
- 고객별 기능 개발과 자사 플랫폼 설정 변경을 어떻게 구분합니까?
- 데이터 품질이 낮거나 접근 권한이 지연될 때, 일정·범위·대안을 어떻게 재협의합니까?
- AI 결과가 부정확하거나 업무상 부적절할 때, 탐지·검토·중단·복구 절차는 무엇입니까?
- 계약 종료 시 고객사가 받아야 할 코드, 설정, 데이터 사전, 운영 문서, 교육 범위는 어디까지입니까?
- 운영 지표가 기대에 못 미칠 때, 개선 작업이 초기 계약 범위인지 별도 과업인지 어떻게 판단합니까?
좋은 답변은 “전문가가 해결한다”는 약속이 아니라, 발견 단계의 산출물, 고객사 승인 지점, 변경 요청의 처리 방식, 인수 절차를 구체적으로 제시합니다.
인수 기준은 배포 완료가 아니라 운영 가능한 상태여야 한다
FDE 프로젝트의 인수 기준을 화면 수, 모델 연결 여부, 데모 성공으로만 잡으면 현업 사용 직전에 문제가 드러날 수 있습니다. 인수 기준에는 최소한 아래 항목을 검토할 여지가 있습니다.
- 합의한 업무 시나리오에서 입력, 처리, 결과 확인, 예외 처리까지 수행할 수 있는가
- 데이터 출처와 갱신 주기, 오류 시 처리 방법이 문서화되어 있는가
- 사용자별 권한과 승인 절차가 적용되었는가
- 운영자가 결과를 확인하고 수정하거나 기능을 중단할 수 있는가
- 변경·장애·오류 발생 시 담당자와 대응 순서가 정해져 있는가
- 고객사 담당자가 외부 인력 없이 기본 운영과 인수인계를 수행할 수 있는가
FDE 도입을 검토하는 첫 회의에서는 “누가 FDE를 제공할 수 있는가”보다 “우리 조직이 아직 결정하지 못한 문제는 무엇인가”를 먼저 적어보는 편이 낫습니다. 그 목록에서 현업이 답할 문제, 내부 개발팀이 결정할 문제, 외부 인력이 검증하고 구현할 문제를 나누면, FDE가 필요한지와 필요한 범위가 함께 드러납니다.
