온톨로지·ERP 연동 FDE 프로젝트: 현업과 개발팀의 역할을 나누는 법

온톨로지·ERP 연동 FDE 프로젝트의 역할 분담은 현업이 업무 의미와 정답을, ERP 담당자가 원천 상태와 실행 권한을, 데이터 담당자가 식별자·수집 시점·매핑을 확인하고, FDE가 그 결정을 조회 도구와 평가에 반영하는 흐름으로 정합니다. 매일 남길 것은 미팅 참석자보다 승인한 정의, 보류 이유, 다음 확인자와 인수 증거입니다.

영업 담당자가 지연 주문을 물었는데 AI와 ERP 화면의 목록이 다릅니다. AI는 고객에게 처음 약속한 날짜를, ERP 화면은 수정된 확정 납기일을 기준으로 삼았다면 두 목록은 각자의 규칙대로 만들어졌을 수 있습니다. 이때 개발자가 문장이나 SQL만 바꾸면 다음 부서에서 같은 문제가 반복됩니다. 어떤 질문에 어느 날짜를 쓸지 현업이 판단하고, 그 날짜가 원천의 어느 상태와 연결되는지 ERP 담당자가 확인해야 작업을 닫을 수 있습니다.

FDE는 Forward Deployed Engineer 또는 Engineering을 줄인 표현으로, 여기서는 고객 업무 가까이에서 문제를 확인하고 시스템을 만들며 반복 평가하는 협업 문맥으로 씁니다. OpenAI의 공식 설명도 고객 전문가와 함께 업무를 이해하고 구현·평가·운영 적용을 진행하는 방식을 다룹니다. 다만 OpenAI의 Product·Research 팀 연결은 그 회사 조직의 설명입니다. 다른 업체가 FDE라는 이름을 쓴다는 이유로 같은 접근권이나 수행 능력을 갖는다고 볼 근거는 없습니다.

아래 내용은 여러 사업장을 가진 가상 제조사의 지연 주문 조회를 설계하는 예시입니다. 실제 고객의 구축 과정이나 성과가 아닙니다. 대상 업무는 사용자의 조회 권한 안에서 지연 주문과 판단 근거를 보여 주는 데 한정합니다. 납기일 변경, 출고 확정, 거래처 통지는 초기 범위에 넣지 않습니다. 회의 시각과 참여 주기는 설명을 위한 제안이며, FDE가 항상 상주하거나 모든 변경을 무제한 처리한다는 계약 조건을 뜻하지 않습니다.

공식 자료가 설명하는 협업과 제품의 범위#

2026년 10월 28일 확인한 OpenAI의 10월 22일 글은 고객과 문제를 이해하고 실제 업무 평가를 거쳐 신뢰할 수 있는 사용으로 연결하는 FDE 역할을 설명합니다. 사업 페이지는 고객의 도메인 전문가 참여와 출시 뒤 내부 팀의 역량 인수를 다룹니다. Palantir 문서는 자사 Ontology의 객체·속성·관계와 액션·함수를 설명합니다. 아래 결정 로그는 이 문서의 의무 양식이 아닌 이 글의 설계 제안이며, 특정 제품 도입이나 공급사 제휴를 전제하지 않습니다.

• OpenAI: What FDE means at OpenAI: 고객 업무와 실제 평가에 관한 OpenAI 조직 설명. 일반 업체의 역량 보장이나 계약 표준은 아님.
• OpenAI: Forward Deployed Engineering: 고객 전문가 참여·운영 적용·내부 인수 설명. Product·Research 접근과 파트너 역할은 OpenAI 고유 범위.
• Palantir: Ontology building overview: Palantir 제품의 의미 요소와 실행 요소 설명. 모든 온톨로지의 필수 기능이나 알파카 제공 기능을 뜻하지 않음.

오늘 닫을 일과 다음 반복으로 넘길 일을 구분한다#

가상 팀의 일일 협업은 각 부서가 새로 알게 된 사실을 다음 사람의 입력으로 바꾸는 순환입니다. 현업이 예외 주문을 제시하면 ERP 담당자가 원천 기록을 찾고, 데이터 담당자가 수집·매핑 차이를 설명한 뒤 FDE가 질의와 평가를 고칩니다. 수정 결과는 다시 현업이 판정합니다. 현업이 화면만 보고 승인하고 ERP 담당자는 뒤늦게 원천을 확인하는 순서라면 같은 쟁점이 다시 열립니다. 합의가 필요한 사람이 불참했을 때는 대체 승인자에게 넘기거나 해당 질문의 출고를 보류합니다. FDE에게 업무 의미의 최종 결정까지 맡기는 방식은 피해야 합니다.

마감이라는 말도 나눠 써야 합니다. 개발 마감은 승인된 조회와 거절이 재현되고 내부 운영자가 처리할 수 있는 상태입니다. 영업의 당일 업무 마감은 고객 응대에 필요한 목록이 충분한 시점일 수 있고, ERP의 기간 마감은 별도 업무 규정에 따릅니다. 가상 예시에서 추출본에 당일 출고가 누락됐다면 조회를 잠정 제공하더라도 출고 지연이 확정됐다고 표시해서는 안 됩니다. 현업은 잠정 목록을 어떤 용도로 쓸지 결정하고 ERP 담당자는 원천 확정 시점을 확인합니다. FDE는 두 판단을 답변에 반영하며 재조회 조건을 기록합니다. 이 글은 회계 마감의 법적·회계적 판단 기준을 제시하지 않습니다.

반복 주기를 정할 때는 고객 내부 시간도 확보하세요. ERP 담당자가 권한과 표본을 확인할 수 있는 시간, 현업이 오답을 판정할 시간, 데이터 담당자가 갱신 실패를 확인할 시간이 필요합니다. 미확인 주문을 전부 FDE 대기열에 넣으면 개발 시간이 늘어도 승인 속도는 바뀌지 않습니다. 결정 로그에서 지연 사유를 의미 미승인·원천 접근 대기·구현 대기·검수 대기로 나누면 다음 반복에 누가 참여해야 할지 보입니다. 회의 길이를 일률적으로 고정하기보다 남은 결정과 영향에 맞춰 참여자를 부르고, 계약한 투입 한도를 넘기는 추가 업무는 별도 변경 기록으로 다룹니다.

인수 미팅에서는 담당자가 바뀐 뒤의 하루를 재현한다#

최종 시연은 작성자가 정답을 아는 질문만으로 마치지 않습니다. 내부 동료가 승인된 질문을 고르고 자신의 사업장 권한으로 접속해 목록과 원천을 대조합니다. 같은 사람이 모호한 지연 기준을 물었을 때 추가 확인을 받는지, 권한 밖 주문번호를 넣었을 때 존재 여부까지 새지 않는지 점검합니다. 다른 법인의 같은 번호, 부분출고, 취소와 재개, 갱신 지연을 표본에 포함하되 기대 답은 현업과 ERP 담당자가 앞서 확인한 버전으로 고정하세요. 평가 중 새 업무 규칙을 발견했다면 틀린 답의 개수만 고치지 말고 정의 변경 여부부터 결정합니다.

운영 인수 자료에는 질문과 정의 버전, 식별자 매핑, 원천 소유자, 접근 승인 경로, 갱신 확인 위치, 평가 표본의 보관 장소, 중단과 복구 창구를 연결합니다. 문서 묶음이 존재하는 것만으로는 충분하지 않습니다. FDE가 자리를 비운 상태에서 내부 담당자가 갱신 실패를 발견하고 잠정 표시로 전환한 뒤 담당자에게 확인을 요청해 보게 하세요. 계정을 회수하면 어떤 조회가 멈추는지까지 알아야 외부 참여가 끝난 뒤에도 권한을 방치하지 않습니다. 인수 이후 지원 시간과 재참여 조건은 계약한 범위로 남기며 영구 운영 대행을 가정하지 않습니다.

발주자는 역할표 옆에 실제 결정 기록을 요청할 수 있습니다. 승인한 의미가 구현과 평가에 반영됐는지, 보류가 해제될 때 원래 표본도 다시 확인했는지, 읽기 인수 후 쓰기 권한이 여전히 닫혀 있는지 추적하면 참여자 명단만으로 보이지 않던 협업 품질을 확인할 수 있습니다. 미결 항목마다 다음 확인자와 재판정 조건을 남기고 최종 승인자가 수용한 제한을 인수 문서에 적습니다. 데이터가 없는 질문을 답할 수 없다고 표시하는 상태도 승인할 수 있습니다. 답을 늘리려고 근거 없는 추정을 허용하면 애초에 합의한 조회 경계가 사라집니다.

협업 개념은 FDE 뜻과 역할에서 확인할 수 있습니다. 제안 증거를 비교할 때는 FDE 방식 업체 선정을 참고하세요. 기술 범위의 출발점은 ERP 데이터 온톨로지·AI 검증 범위에서 구분합니다. 전사 의사결정 책임은 AI 거버넌스 RACI와 연결해 정하세요. 값 교정과 보류 처리의 상세 기준은 온톨로지 사람 검수 흐름에서 확인합니다.