Oct 26, 2026

AI가 현장을 이해하기까지: 네이버클라우드 FDE 이야기

Image for AI가 현장을 이해하기까지: 네이버클라우드 FDE 이야기

AI에게 업무 문서를 찾아달라고 하면 답을 해주고, 데이터를 분석해달라고 하면 결과를 내놓습니다. 그렇다면 AI를 실제 업무에 적용하는 일도 모델을 준비하는 것만으로 충분할까요?


실제 현장에서는 이야기가 조금 다릅니다. 필요한 자료가 여러 시스템에 흩어져 있거나, 같은 대상을 부서마다 다른 이름으로 부르기도 합니다. 외부와 분리된 폐쇄망 환경에서는 일반적인 AI 서비스를 그대로 쓰기 어렵고, 업무마다 무엇을 ‘정확한 답’으로 볼 것인지도 다릅니다.


그렇기 때문에 좋은 모델과 인프라가 갖춰졌다고 해도 AI가 곧바로 현장의 업무를 이해하고 수행할 수 있는 것은 아닙니다. 고객의 데이터와 업무 환경에 맞게 AI를 구현하고 조정하는 과정이 필요한데요. 네이버클라우드 FDE(Forward Deployed Engineer)는 바로 이 과정을 고객의 현장에서 직접 수행합니다. 고객의 업무와 데이터를 살펴 막연한 요구를 구체적인 기술 과제로 구조화하고, PoC와 파일럿을 거쳐 AI 시스템을 구축한 뒤 실제 운영에서 발견한 문제를 다시 개선으로 연결합니다.


이러한 작업은 이미 여러 고객 현장에서 진행되고 있습니다. 네이버클라우드는 한국수력원자력의 데이터센터 내부에 클라우드 인프라와 생성형 AI 플랫폼을 구축했고, 범정부 AI 공통기반에는 내부망용 AI 서비스를 제공하고 있습니다. 국방 분야에서도 서로 다른 형태의 정보를 연결해 지휘관의 판단을 지원하는 AI를 함께 만들어가고 있는데요. 네이버클라우드 FDE는 각 현장에서 고객의 업무와 데이터를 이해하고 이를 실제 AI 시스템으로 구현하는 역할을 맡고 있습니다.


서로 다른 현장에서 네이버클라우드 FDE는 어떤 문제를 만나고, 이를 어떻게 AI 시스템으로 풀어가고 있을까요? 그 과정을 지금부터 살펴보겠습니다.


네이버클라우드 FDE: 고객 현장에 직접 들어가는 엔지니어

네이버클라우드 FDE(이하 FDE)는 고객 현장에 직접 들어가 그 조직의 데이터와 업무 조건 위에서 AI 시스템을 설계·구축·운영하는 엔지니어입니다. 요구사항을 정의하는 것부터 검증과 배포, 운영 이후의 개선까지 고객 조직과 함께 수행합니다.


여기서 전방 배치(Forward Deployed)라는 말은 고객 가까이에 있다는 뜻만은 아닙니다. 고객이 어떤 업무를 하는지 이해하고, 고객의 언어로 요구를 파악해 이를 실제 AI 시스템에 반영할 수 있는 상태까지를 포함합니다.


FDE라는 직무는 여러 회사에 있지만, FDE가 고객 현장에서 실제로 어디까지 할 수 있는지는 그 회사가 어떤 기술을 직접 보유하고 있는지에 따라 달라집니다. 고객의 문제를 풀려면 모델을 고객의 인프라에 직접 배포해야 할 때도 있고, 모델의 답변이 실제 업무에 활용되도록 애플리케이션까지 구성해야 할 때도 있기 때문입니다.


네이버클라우드는 데이터센터와 인프라부터 AI 모델, 애플리케이션까지 모두 직접 보유하고 있습니다. 덕분에 FDE는 필요한 기술을 연결해 고객 현장에서 실제로 활용할 수 있는 하나의 AI 시스템으로 구현할 수 있는데요. 그 과정에서 FDE가 수행하는 일은 크게 세 가지입니다.


  1. 서로 다른 도메인의 문제를 기술로 풀어냅니다
    원전, 공공, 국방 등 각 도메인의 데이터와 용어, 업무 규칙을 현장에서 직접 경험하고, 그 요구를 AI 시스템에 반영합니다.
  2. 폐쇄망 안에서 구축합니다
    고객 데이터센터 내부에 설치한 인프라 위에서 모델을 배포하고, 고객 망 안에서 애플리케이션까지 구축합니다.
  3. 고객의 요구를 애플리케이션으로 구현합니다
    RAG·온톨로지·에이전트 등을 활용해 고객의 업무에 맞는 AI 파이프라인을 직접 구성합니다.

FDE의 역할은 좋은 모델을 고객에게 건네는 데서 끝나는 것이 아니라, 고객의 업무 환경을 이해하고 그 안에서 AI가 실제로 일할 수 있는 시스템을 만드는 데 있습니다.


현장에서 마주한 네 가지 문제

원전과 공공, 국방 현장은 모두 달랐지만, AI를 도입할 때 부딪히는 문제는 대부분 비슷했습니다.


첫째, 데이터가 흩어져 있습니다.
고객이 보유한 자료 가운데 AI가 바로 활용할 수 있는 형태로 정리된 자료는 일부에 그칩니다. 자료가 부서별 시스템이나 파일 서버에 나뉘어 있기 때문인데요. 그렇다고 보안 정책이나 비용 문제로 모든 데이터를 하나의 저장소로 옮기기도 쉽지 않아, 흩어진 데이터를 그대로 두고 연결하고 정리하는 방법이 필요합니다.


둘째, 같은 대상을 서로 다른 이름으로 부릅니다.
현업에서는 ‘설비’라고 부르는 대상을 다른 부서에서는 ‘장비’, 전산 시스템에서는 ‘자산’으로 관리하는 식입니다. 검색결과 자체가 정확하더라도 사용하는 명칭이 다르면 AI는 같은 대상을 서로 다른 대상으로 인식할 수 있습니다.


셋째, 폐쇄망이라는 제약이 있습니다.
폐쇄망에서는 학습과 추론, 운영을 모두 내부에서 수행해야 합니다. 외부 API를 호출할 수 없고 외부 환경에서 구성한 파이프라인을 그대로 가져오기도 어렵습니다. 그래서 AI 모델뿐 아니라 데이터를 연결하고 처리하는 과정까지 고객의 내부 환경에 맞춰 설계해야 합니다.


넷째, ‘정확한 답’의 기준이 다릅니다.
같은 질문이라도 이해관계자에 따라 원하는 답의 조건이 다릅니다. 현업은 최신성을, 감사 부서는 출처의 신뢰도를, 결재 권한자는 간결함을 더 중요하게 여길 수 있습니다. 업무와 사람에 따라 ‘좋은 답’의 기준 자체가 달라집니다.


이 문제들은 모델이나 인프라의 성능만 높여서는 해결하기 어렵습니다. 데이터의 위치와 용어, 운영 환경, 정답 기준까지 고객 현장 안에서 함께 살펴봐야 하는데요. 바로 이 지점에서 FDE의 역할이 시작됩니다.


실제 현장에서는 이 문제를 어떻게 풀어냈을까요?


현장의 문제를 AI가 일할 수 있는 시스템으로 만듭니다

같은 AI라도 고객의 업무와 데이터 환경에 따라 필요한 모습은 달라집니다. 어떤 현장에서는 필요한 문서를 정확하게 찾아주는 것부터 시작해야 하고, 어떤 곳에서는 서로 다른 데이터를 연결하고 그 관계를 이해할 수 있어야 합니다.


FDE는 고객의 요구를 그대로 개발 과제로 옮기는 대신, 실제 업무 환경에서 필요한 기능과 기술을 구체화해 하나의 AI 시스템으로 구현합니다. 원전과 공공, 국방, 세 현장에서 FDE가 일해온 방식을 차례로 소개합니다.


한국수력원자력: 수십 년간 쌓인 문서를 AI가 이해하는 데이터로

한국수력원자력은 사내 데이터센터에 구축한 HyperCLOVA X 위에, 내부 업무 데이터를 기반으로 한 RAG 서비스를 완성했습니다. 이를 바탕으로 부서별 업무 지식을 반영한 전용 챗봇까지 포함하는 플랫폼 하이누리(Hy-NuRI)를 전사에 적용했는데요.


그림1. 한국수력원자력 하이누리(Hy-NuRI)


원전은 절차서와 기술기준을 정확히 지켜야 하는 현장입니다. 그래서 질문마다 관련 문서를 찾아 그 내용을 근거로 답하고, 근거 문서까지 함께 보여주는 RAG(검색 증강 생성)가 가장 먼저 필요했습니다.


그런데 실제 현장에서 RAG를 구축할 때 가장 먼저 해결해야 했던 문제는 검색 모델 자체가 아니었습니다. AI가 검색할 수 있는 형태로 문서를 만드는 일부터 필요했습니다.


원전 현장의 문서는 일반적인 텍스트 파일처럼 정리되어 있지 않습니다. 수십 년에 걸쳐 쌓인 문서에는 PDF와 HWP, 스캔본, 심지어 수기 문서까지 섞여 있고 문서마다 구조도 다른데요. 이 자료를 그대로 검색 시스템에 넣는 것만으로는 필요한 내용을 제대로 찾아내기 어렵습니다. FDE가 현장에서 직접 조정한 것은 크게 세 가지입니다.


  • 문서 수집·파싱: PDF·HWP·스캔·수기 문서를 표 구조가 유지된 형태로 텍스트화하고, 작성일과 문서 유형 같은 메타데이터도 함께 추출
  • 청킹: 절차서는 절 단위로, 기술기준은 조·항 단위로 나누는 등 문서 유형마다 다른 분할 규칙을 설정
  • 리랭킹: 검색 결과의 관련도에 최신성과 출처 등급을 함께 반영해, 어떤 문서를 우선적으로 보여줄지 조정

FDE가 현장에서 조정한 것은 RAG를 구성하는 세부 설정이었습니다. 어떤 문서를 어떻게 읽고 어떤 단위로 나누며, 검색 결과 가운데 무엇을 더 중요하게 볼지 고객의 업무 환경에 맞춰 결정했습니다. 같은 RAG라도 고객마다 다르게 동작하는 것은 이 설정이 다르기 때문입니다.


그림2. RAG 파이프라인의 여섯 단계


공공: 답을 찾는 AI에서 업무를 돕는 AI로

범정부 AI 공통기반은 인터넷망과 분리된 행정 내부망에서 공무원들이 AI를 활용할 수 있도록 마련된 기반입니다. 네이버클라우드는 이곳에 내부망용 AI 서비스를 제공하고 있습니다.


AI를 실제 업무에 활용하기 시작하면 새로운 요구가 생깁니다. 처음에는 필요한 정보를 검색하고 답변이나 초안을 만드는 것만으로도 도움이 되지만, 사용하다 보면 자연스럽게 다음 질문으로 이어집니다.


“답을 알려주는 것에서 끝나지 않고, 그다음 업무까지 할 수 없을까?”


그런데 AI에게 더 많은 일을 맡기려면 먼저 지금의 답을 믿을 수 있어야 합니다. 현장에서는 “답이 이상하다”는 의견이 나와도 정확히 어느 단계에서 문제가 생겼는지 바로 알기 어려운 경우가 많습니다.


FDE는 실제로 접수된 고객 VOC를 바탕으로 골든셋(평가 기준이 되는 정답 데이터셋)을 만들었습니다. 그리고 응답과 로그, 시스템 현황을 한 화면에서 확인할 수 있는 분석 도구를 직접 제작해, 막연하게 “답변이 이상하다”고 판단하는 대신 어느 단계에서 품질이 떨어졌는지를 데이터로 확인할 수 있게 했습니다. 이 결과는 기획팀과 개발팀에도 공유되어 실제 개선에 반영되었습니다.


품질을 확인하고 개선하는 일과 함께, FDE는 부처가 실제로 필요로 하는 AI를 찾아 만드는 일에도 힘을 쏟고 있습니다. 부처마다 다루는 업무와 쌓인 데이터, 반복하는 작업이 모두 다르기 때문에 FDE는 먼저 현장으로 들어갑니다. 담당자 인터뷰와 설문으로 업무를 들여다보며 어디에서 시간이 가장 많이 들고, 어떤 일을 AI에게 맡기고 싶은지를 구체적으로 파악합니다.


이렇게 파악한 요구는 곧바로 결과물로 이어집니다. FDE는 보고서 초안 작성, 자료·법령 검색, 민원 답변처럼 자주 반복되는 업무를 대상으로 AI Studio에서 부처에 맞는 어시스턴트를 직접 만들고, 공무원과 함께 결과를 검토하며 실제 업무에 쓸 수 있는 수준인지 검증합니다. 여기에 AI Studio 사용법과 프롬프트 작성법, 배경지식 활용법, 업무별 적용 방법을 담은 가이드와 교육을 더해, 공무원이 스스로 쓰고 직접 만들 수 있도록 돕고 있습니다.


공공에서 FDE는 부처가 실제로 쓸 수 있는 AI를 함께 찾고, 직접 만들고, 스스로 활용할 수 있도록 돕습니다. 답을 찾아주던 AI가 공무원의 업무를 직접 돕는 AI로 넓어지는 과정에 FDE가 함께하고 있습니다.


사진1. 범정부 AI 심화교육 현장


국방: 현장에서 수집한 정보를 판단에 필요한 정보로

국방은 FDE의 역할이 가장 넓게 펼쳐지는 현장입니다. 드론 영상과 위성사진, 무전 음성, 작전 문서처럼 형태가 다른 정보가 흩어져 있고, 통신이 끊길 수 있으며, 실제 상황의 데이터는 확보하기 어렵다는 조건이 한꺼번에 겹치기 때문인데요. 네이버클라우드는 이러한 정보를 옴니모달 모델로 함께 분석해 지휘관이 이해할 수 있는 정보로 바꾸고, 이를 의사결정에 활용할 수 있는 구조를 만들어가고 있습니다.


이때 가장 먼저 정해야 하는 것은 현장의 데이터를 누가 수집하고 누가 분석하느냐입니다. 드론이나 전술차량 같은 엣지 환경에서는 현장에서 데이터를 빠르게 확보하고 분석해야 하기 때문인데요. FDE는 군집 AI 드론 기업과 협업하며 이 역할을 나누고 있습니다.


  • 군집 AI 드론 기업: 드론이 비행 중 수집한 영상과 센서 정보를 지상통제장치로 전달
  • 네이버클라우드 FDE: 이 데이터를 HyperCLOVA X 옴니모달 모델로 분석해 객체와 상황 정보로 바꾸고, 온톨로지 기반 지식체계와 에이전트로 연결

드론이 현장을 보고, 네이버클라우드 FDE가 그 정보를 판단에 활용할 수 있는 형태로 바꾸는 구조입니다.


사진2. 국방 현장 사진


그런데 영상을 분석하는 것만으로는 충분하지 않습니다. AI가 ‘무엇이 보였는지’를 알아내는 데서 나아가, 그 정보가 이미 알고 있는 상황과 어떤 관계가 있는지까지 이해할 수 있어야 실제 판단에 활용할 수 있기 때문입니다.


예를 들어 적 전차의 이동이 포착됐다고 해보겠습니다. ‘전차가 이동했다’는 사실 너머로, 그 이동이 어떤 지역에서 발생했는지, 공격 징후와 어떤 관계가 있는지, 아군 방어선과 어떻게 연결되는지, 교리상 어떤 판단과 대응으로 이어질 수 있는지까지 함께 볼 수 있어야 합니다. FDE는 온톨로지를 통해 전장에서 쓰이는 개념과 용어, 개념 사이의 관계와 교리를 하나의 지식체계로 구조화합니다. 이를 통해 서로 다른 체계에서 관측한 정보도 같은 의미로 연결되는데요. 그림 3은 미상 항적을 예로, 흩어진 탐지 결과가 온톨로지를 거쳐 위협 평가와 대응 방책, 지휘관 승인까지 하나의 관계로 연결되는 과정을 보여줍니다.


그림 3. 온톨로지 적용안


여기에 한 가지 어려움이 더 있습니다. 국방에서는 실제 상황의 데이터를 충분히 확보하기 어렵습니다. 그래서 FDE는 드론 영상과 위성사진, 감시 영상 분석 업무에서 시뮬레이션 환경과 합성 데이터를 직접 구성하고, 그 위에서 모델을 검증한 뒤 현장으로 옮깁니다.


마지막으로, 국방 시스템에서는 AI가 최종 판단을 대신하지 않도록 사람이 검토하고 승인하는 지점을 시스템 안에 둡니다. 이를 휴먼 인 더 루프(HITL, Human-in-the-loop)라고 하는데, FDE는 이 방식을 설계 단계에서부터 반영합니다. AI가 탐지와 추적을 돕더라도 확정은 반드시 사람이 하고, 그 승인 기록도 시스템 안에 남기는 방식인데요. 에이전트가 도구를 호출해 실제 작업을 이어가는 하네스(Harness) 구조 안에도 FDE는 이 확인 지점을 설계해 둡니다.


그림 4. 하네스 에이전트: 답을 행동으로


AI의 역할은 결심을 대신하는 것이 아니라 지휘관이 더 빠르고 정확하게 판단할 수 있는 환경을 만드는 데 있습니다. 국방에서 FDE가 하는 일은 현장에서 데이터를 확보하는 단계부터 AI 분석과 지식 구조화, 의사결정 지원까지 서로 다른 기술과 시스템을 하나의 흐름으로 잇는 일에 가깝습니다.


세 개의 현장을 관통하는 FDE의 일하는 방식

원전과 공공, 국방은 서로 다른 현장이었고, 그 안에서 활용한 기술도 RAG와 온톨로지, 에이전트로 제각각이었습니다. 하지만 FDE가 일하는 방식에는 공통된 흐름이 있습니다. 고객의 요구를 구조화하고, 작은 범위에서 검증한 뒤 실제 운영 환경에서 평가하고, 그 결과를 다시 다음 요구사항으로 연결하는 순환입니다.


  • 요구사항 구조화: 고객의 요구를 구체적인 항목으로 나누고, 무엇을 먼저 할지 우선순위를 합의
  • 개념 검증(PoC): 핵심 요구를 작은 규모로 구현하고 정량 기준을 확인
  • 파일럿: 실제 데이터와 사용자 환경에서 운영하며 현업의 피드백을 수집
  • 제품화: 검증된 기능을 제품 조직으로 이관
  • 관찰·평가·개선: 운영 로그와 피드백을 살펴 개선점을 찾고, 이를 다시 새로운 요구사항으로 연결

이 흐름을 조금 더 자세히 들여다보면, FDE가 고객 현장에서 어떤 일을 하는지 더 분명해집니다.


그림 5. FDE의 일하는 방식


고객의 말을 시스템이 이해할 수 있는 요구사항으로 바꿉니다

고객은 업무의 언어로 말합니다. 그 한 문장 안에는 데이터의 위치와 필요한 정확도, 보안 제약이 한꺼번에 섞여 있는데요. FDE는 현업과 전산, 결재 부서 등을 직접 인터뷰해 이 요구를 여섯 가지 항목으로 나눕니다.


  1. 도메인: 업무 영역의 용어와 규칙, 문서 유형
  2. 데이터 위치: 데이터가 어느 시스템에 어떤 형태로 있는지
  3. 용어 차이: 부서와 시스템마다 다르게 쓰는 명칭
  4. 제약: 폐쇄망의 형태, 장비 자원, 규제와 감사 조건
  5. 정확도 기준: ‘맞는 답’을 누가, 어떤 조건으로 판단하는지
  6. 우선순위: 요구가 서로 충돌할 때 무엇을 먼저 따를지

이렇게 나눈 항목은 실제 AI 시스템을 설계하고 조정하는 기준이 됩니다. 앞서 한국수력원자력에서 최신성과 출처를 고려해 검색 결과의 우선순위를 조정한 것도, 국방에서 서로 다른 체계의 개념과 용어를 온톨로지로 연결한 것도 이 과정에서 나온 결과입니다. 같은 기술이라도 현장마다 설정이 달라지는 이유가 여기에 있습니다.


숫자와 사람, 두 가지 기준으로 평가합니다

시연 환경에서 잘 동작하는 것과 현업에서 매일 사용하는 것은 다른 이야기입니다. 그래서 FDE는 시스템을 구축하는 것과 별도로, 무엇을 기준으로 ‘잘 동작한다’고 판단할 것인지 평가 방법부터 설계합니다.


1. 정량 평가

정량 평가는 지표로 품질을 측정하는 일입니다. 앞서 공공 사례에서 VOC로 골든셋을 만든 것처럼 실제 질문을 바탕으로 평가 데이터셋을 구성하는데요. RAG는 RAGAS 지표로 답변이 근거 문서에 충실한지, 질문에 맞게 답했는지, 필요한 문서를 얼마나 잘 찾아냈는지를 측정합니다.



이렇게 측정하면 “답변이 좋지 않다”에서 그치지 않고, 파싱이나 청킹, 리랭킹, 용어 연결 중 어느 부분을 먼저 살펴봐야 하는지까지 확인할 수 있습니다. 예를 들어 온톨로지를 적용한 뒤 같은 데이터셋으로 다시 측정하면, 용어 차이 때문에 낮았던 Context Recall이 얼마나 회복됐는지로 온톨로지의 효과를 수치로 보여줄 수 있죠.


에이전트는 답변이 아니라 행동을 만들어내기 때문에 RAG와는 다른 기준으로 평가합니다. 작업을 얼마나 완료했는지, 필요한 도구를 정확하게 호출했는지, 각 단계가 효율적으로 진행됐는지를 지표로 확인합니다. 그중 눈여겨볼 지표는 확인 지점 개입률인데요. 사람이 검토하는 지점에서 담당자가 에이전트의 제안을 거부하거나 수정한 비율로, 이 값이 높으면 에이전트가 고객의 업무 규칙과 맞지 않는 행동을 제안하고 있다는 뜻입니다. 반대로 지나치게 낮으면 확인 지점이 꼭 필요한 위치에 놓여 있는지를 다시 점검합니다.


2. 정성 평가

하지만 지표만으로 모든 문제를 확인할 수는 없습니다. 답변이 지나치게 길거나, 출처의 신뢰도가 낮거나, 특정 부서의 용어로만 쓰여 다른 부서가 읽기 어려운 경우가 그렇습니다. 그래서 FDE는 고객 현업과 함께 답변을 직접 읽고 판정하는 정성 평가를 진행하고, 지표로는 잡히지 않았던 문제 유형을 다음 평가 데이터셋에 새로운 항목으로 추가합니다.


두 평가가 같은 방향을 가리킬 때 FDE는 시스템을 배포하고, 결과가 어긋나면 그 차이를 다음 개선의 단서로 삼습니다. 평가 데이터셋은 폐쇄망 안에서 고객 현업과 함께 만들고 외부로 반출하지 않습니다. 국방처럼 실제 데이터를 확보하기 어려운 현장에서는 시뮬레이션 데이터로 다양한 상황을 평가에 담기도 합니다.


그림 6. 정량·정성 평가와 개선 경로


문제가 어디에 있든, 해결 경로는 네이버클라우드 안에

배포 이후에도 현장은 계속 바뀝니다. 새로운 절차서와 법령이 등록되고, 조직이 바뀌면 사용하는 용어나 업무 방식도 달라질 수 있는데요. FDE는 운영 로그와 현업의 피드백을 계속 확인하면서 발견한 문제를 성격에 따라 나누어 개선합니다.

  • 파이프라인 설정으로 해결할 수 있는 문제: FDE가 현장에서 직접 조정
  • 모델 자체의 개선이 필요한 문제: 평가 데이터와 실패 사례를 정리해 모델 조직에 전달
  • 여러 고객에게서 반복되는 요구: 제품 요구사항으로 정리해 제품 조직에 전달

예를 들어 모델이 특정 도메인의 용어나 규정 체계를 충분히 반영하지 못해 평가 결과가 낮게 나온다면, FDE는 실패한 질문과 평가 데이터를 바탕으로 문제의 원인을 구분합니다. 현장에서 설정을 조정해 해결할 수 있다면 직접 수정하고, 모델 자체의 개선이 필요하다면 실패 사례와 도메인 자료를 정리해 모델 조직에 전달합니다. 이후 새로운 모델이 적용되면 같은 평가 데이터셋으로 다시 측정해 개선 여부를 확인할 수 있습니다.


앞서 FDE가 현장에서 어디까지 할 수 있는지는 회사가 어떤 기술을 직접 보유하고 있는지에 따라 달라진다고 말씀드렸는데요. 그 의미가 바로 여기에 있습니다. 네이버클라우드는 데이터센터와 인프라부터 AI 모델, 애플리케이션까지 직접 보유하고 있어, 현장에서 발견한 문제가 어느 계층에 있든 필요한 조직과 기술로 연결해 개선을 이어갈 수 있습니다. FDE는 해당 조직에 개선을 요청하고, 반영된 결과를 다시 고객 환경에서 확인합니다.


그림 7. FDE 라이프사이클과 내부 조직 연계


AI가 현장에서 일하려면, 현장을 이해하는 일이 먼저입니다

AI를 실제 업무에 적용하는 과정은 좋은 모델을 선택하고 시스템을 구축하는 것만으로 끝나지 않습니다. 원전과 공공, 국방처럼 고객마다 해결해야 할 문제와 필요한 기술은 달랐지만, 그 중심에는 고객의 업무를 이해하고 이를 실제 AI 시스템으로 구현하는 FDE가 있었습니다. 결국 FDE가 만드는 것은 단순한 AI 기능이 아니라 AI가 고객의 데이터와 업무 환경 안에서 실제로 일할 수 있는 구조입니다.


앞으로 AI가 더 많은 업무에 들어갈수록 기술 자체의 성능만큼이나 그 기술을 각자의 현장에 맞게 구현하고 계속 발전시켜 나가는 과정이 중요해질 것입니다. 네이버클라우드 FDE는 고객의 언어로 현장의 문제를 이해하고 실제 업무에서 검증하며, 그 과정을 고객과 함께 만들어가고 있습니다. 현장에서 AI가 일하는 방법을 고객과 함께 만들어가는 네이버클라우드 FDE의 행보에 앞으로도 많은 관심과 응원 부탁드립니다.