엔터프라이즈 AX 구축
FDE(Forward Deployed Engineer)가 고객사에 상주하며,
문제 정의부터 구현과 운영 이관까지 맡습니다.
반면, 현업에서 실제로 쓰는 기업은 많지 않습니다.
같은 모델을 써도 결과가 갈립니다.
기술을 도입하는 일과 현업에 적용하는 일은
완전히 다르기 때문입니다.
현업이 실제로 쓰기 시작해야 AX 프로젝트가 끝납니다.
사내 데이터 연결과 보안 검토를 포함해
AX의 시작부터 끝까지 맡는 팀이 있어야합니다.
기업의 AX는 순서대로 진행되지 않습니다.
지금 멈춰 있는 지점에서 시작합니다.
기업의 AX가 계속 멈추는 이유
이미 다수의 대기업 AX 과제를 해결하며 확인했습니다.
요구 사항이 명확하지 않습니다.
'AI로 뭔가 할 수 있을 것' 수준에서 시작합니다.
요구사항을 글로 확정하는 데 시간이 가고,
확정된 뒤에는 이미 상황이 바뀌어 있습니다.
사내 환경 제약을 고려해야 합니다.
폐쇄망, 부서별 권한, 기존 시스템 연동.
동작하는 결과물이 있어도
실제 업무 환경에 들어가지 못합니다.
동작은 해도 확산이 어렵습니다.
동작은 하는데 잘 되고 있는지 모릅니다.
확산을 결정할 근거가 없어
처음 AX 과업을 맡은 한 팀에서 멈춥니다.
유지보수가 어렵습니다.
비개발자가 만든 산출물과 에이전트는 늘어나는데,
실제로 관리되는 것은 그중 일부입니다.
만든 사람이 손을 떼면 그대로 멈춥니다.
요구 사항이 명확하지 않습니다.
'AI로 뭔가 할 수 있을 것' 수준에서 시작합니다.
요구사항을 글로 확정하는 데 시간이 가고,
확정된 뒤에는 이미 상황이 바뀌어 있습니다.
사내 환경 제약을 고려해야 합니다.
폐쇄망, 부서별 권한, 기존 시스템 연동.
동작하는 결과물이 있어도
실제 업무 환경에 들어가지 못합니다.
동작은 해도 확산이 어렵습니다.
동작은 하는데 잘 되고 있는지 모릅니다.
확산을 결정할 근거가 없어
처음 AX 과업을 맡은 한 팀에서 멈춥니다.
유지보수가 어렵습니다.
비개발자가 만든 산출물과 에이전트는 늘어나는데,
실제로 관리되는 것은 그중 일부입니다.
만든 사람이 손을 떼면 그대로 멈춥니다.
그래서 이렇게 합니다.
요구가 바뀌는 것,
사내 환경 제약, 품질 판단. 이 3가지를 전제로 시작합니다.
진행 방식은 기업의 AX 과제마다 다르지만
끝나는 지점은 같습니다. 사내 팀이 직접 운영할 수 있는 상태입니다.
고정된 요구사항으로 진행된 AX는 단 한 건도 없습니다.
Case 1 - Project Notes.
· ERP 연동 : 전사 ERP에서 내려받은 데이터를 해석해 기존 업무용 시트를 자동으로 채움
· 폐쇄망 운영 : 사내망에서만 접근 가능한 벡터 데이터베이스를 연동해 운영
· 권한 체계 : 부문·부서별 접근 권한을 검색 단계까지 적용해 볼 수 있는 문서만 근거로 사용
· 레거시 시스템 개선 : 기존 챗봇 코드를 직접 수정해 검색 근거를 저장·평가할 수 있는 구조로 전환
· 전사 보안 정책 대응 : 파일 다운로드 제한 정책에 맞춰 별도 계정과 권한을 설계해 연동
· 결과 : 두 차례에 걸쳐 전사 배포 완료. 한 부문 검증 후 네 개 부문으로 확장 예정
Case 2 - Project Notes.
· 폐쇄망 운영 : 클라우드 PC 안에서 개발과 검증까지 끝내는 방식으로, 파일 반출 없이 프로젝트 시작부터 끝까지 완료
· 대용량 데이터 처리 : 수백여 테이블과 수천만 규모 데이터를 다루면서, 데이터 조회 속도까지 최적화
· 데이터 웨어하우스 연동 : 사내 고객 데이터베이스에 직접 붙는 분석 에이전트 구현
· 온톨로지 : 지식을 온톨로지(Ontology)로 구조화해 구축하고, 지식 베이스 운영 · 관리 프로세스까지 정립
· 전사 보안 정책 대응 : 권한 제한과 외부 접속 차단 환경에 맞는 대안 경로를 직접 설계하여 업무 진행
· 결과 : 전사 배포 완료. 고객이 먼저 범위 확대를 요청
Case 3 - Project Notes.
· 대규모 로그 분석 : 실제 고객이 검색하는 로그 19,400여 건을 분석하여 가장 먼저 풀어야 할 문제 정의부터 시작
· 의도 분류 라우팅 : 800개가 넘는 기능 중 고객 질문을 어디로 보낼지 가르는 구조 설계
· 미처리 질문 대응 : 기존 챗봇이 답하지 못하던 업무 상담 유형까지 처리 범위 확대
· 모델 선택과 튜닝 : 가용 모델을 직접 교체해 가며 정확도와 응답 속도를 함께 최적화
· 평가셋 기반 검증 : 평가셋을 23개에서 100개로 확장하여 성능을 정량화된 지표로 확인
· 결과 : 검증 두 차례 후 본구축 전환. 1차 배포 임박
Case 4 - Project Notes.
· 레거시 코드 진단 : 서비스 코드를 직접 진단해 AI가 다루기 좋은 형태로 전환
· 서버·인프라 이관 검토 : 기존 호스팅 환경을 파악하고, 운영자가 감당할 수 있는 시스템으로 정리
· 개인정보 처리 : 데이터에 섞인 개인정보를 마스킹한 뒤 작업
· 앱 스토어 배포 : iOS와 Android 양쪽 심사 대응과 출시
· 자립형 배포 환경 : 운영자가 직접 배포할 수 있는 환경 구성
· 결과 : 운영자가 직접 도구를 쓰기 시작. 함께 고친 기능을 실제 서비스에 배포
나가지 않습니다. 고객사가 제공한 가상 PC 안에서 개발과 검증을 끝낸 사례가 있습니다.
데이터에 개인정보가 섞여 있으면 마스킹한 뒤 작업합니다.
가능합니다. 수행한 과제 대부분이 폐쇄망이었습니다. 외부망 접속과 자료 업로드가 모두
막힌 환경에서는 로컬 파일 기반 구조로 다시 설계합니다.
연동합니다. 전사 ERP, 사내 문서 저장소, 고객 데이터베이스에 붙인 과제가 있습니다.
부문 팀별 접근 권한을 검색 단계까지 적용해, 볼 수 있는 문서만 근거로 쓰이게 하는
구성도 가능합니다.
평가 기준과 정답 데이터를 함께 만듭니다. 표준 지표에 과제별 지표를 더해 실패 원인을
특정합니다. 품질이 기준선 아래로 떨어지면 알림이 가는 구성까지 만듭니다.
과제 범위에 따라 다릅니다. 과제 한 건을 검증하는 단계와 본구축 단계를 나눠
진행합니다. 상담 단계에서 프로토타입을 먼저 확인하신 뒤 범위를 정합니다.
담당 팀이 운영합니다. 직접 유지보수하고 배포할 수 있는 상태까지 넘겨드립니다.
사내 유지 담당자를 양성한 과제도 있습니다.