포지션 상세
■ 데모는 많고, 현장에서 일하는 Agent는 적습니다
AI Agent 데모는 이제 어디서나 볼 수 있습니다.
그런데 고객사에 들어가면 이야기가 달라집니다.
문서는 스캔한 PDF와 엑셀에 흩어져 있고, 연동할 시스템은 명세와 다르게 움직이고,
금융권 사내망에서는 외부 API를 부르는 것조차 막혀 있습니다.
라이브데이터는 이 간극을 메우는 일을 하고 있습니다.
교육·금융·공공 고객사에 Agent를 직접 구축하고, 실제 사용자가 쓰는 서비스로 운영합니다.
■ 고객이 늘수록, 같은 문제를 다시 풉니다
고객사마다 문서를 다시 쪼개고, API를 다시 붙이고, 품질 기준을 다시 세웁니다.
이 반복을 줄이려고 만든 것이 자사 Agent 개발 플랫폼 LAIV NEXUS입니다.
• DataMart — 고객 문서를 Agent가 쓸 수 있는 지식 구조로 (구조 추출, 청킹, 인덱싱, 검색)
• LaivStudio — 캔버스에서 Agent를 설계하고 재배포 없이 바로 테스트
• MFlux — 고객 시스템의 REST API를 MCP Tool로 자동 변환
• LangBridge — LangGraph 기반 멀티 에이전트 흐름 제어, 중단된 지점부터 이어가는 세션
• Veris — 시나리오 기반 대화 수집과 LLM-as-a-Judge 평가로 변경 전후 품질 비교
FDE는 이 플랫폼을 들고 고객 현장에 들어가는 사람입니다.
그리고 플랫폼이 현장에서 어디가 부족한지 가장 먼저 발견하는 사람입니다.
■ 라이브데이터의 FDE
Forward Deployed Engineer(FDE)는 고객사 현장에서 업무를 직접 보고,
LAIV NEXUS로 Agent를 만들어 운영까지 책임지는 엔지니어입니다.
• 요구사항 문서를 받아 그대로 납품하는 SI 개발자가 아닙니다.
무엇을 만들지는 현업 담당자 옆에서 업무를 보며 함께 정합니다.
• 방향만 제시하고 빠지는 컨설턴트도 아닙니다.
코드를 직접 쓰고, 배포하고, 운영 중 문제가 생기면 직접 고칩니다.
• 한 고객을 위한 결과물로 끝내지 않습니다.
다른 고객에게도 필요한 커넥터, 검색 설정, 평가 시나리오는 LAIV NEXUS 기능으로 되돌려
다음 프로젝트를 더 빠르게 만듭니다.
프로젝트는 고객과 합의한 지표가 실제로 움직이고,
고객 운영팀이 우리 없이도 Agent를 돌릴 수 있게 인계했을 때 끝납니다.
■ 포지션이 나와 맞는지 지원 전에 생각해 보세요
1) 외부 API를 쓸 수 없는 고객사
증권사 사내망에서는 데이터가 밖으로 나갈 수 없습니다.
외부 LLM API 대신 사내에 올린 모델로 돌려야 하고, 라이브러리 하나를 들이는 데도 반입 절차가 필요합니다.
이 환경에서 Agent의 답변 품질과 속도를 어디까지 끌어올릴 수 있을까요?
2) 명세와 다르게 움직이는 고객 시스템
고객 시스템을 MCP Tool로 연결하면 Agent가 그 시스템을 직접 씁니다.
그런데 명세에 없는 오류 코드가 오고, 응답이 수십 초씩 걸리고, 권한은 사용자마다 다릅니다.
Agent가 실패했을 때 무엇을 다시 시도하고, 언제 사람에게 넘겨야 할까요?
3) "답이 좀 이상해요"라는 피드백
고객은 무엇이 이상한지 정확히 말해 주지 않습니다.
검색이 틀렸는지, 문서가 잘못 잘렸는지, 판단이 틀렸는지를 가려내야 합니다.
고객이 생각하는 '맞는 답'을 평가 시나리오로 옮기고, 고치기 전과 후를 숫자로 비교할 수 있을까요?
4) 이번 고객만을 위한 코드
일정에 쫓기면 고객별 예외 처리가 쌓입니다.
그중 무엇이 다음 고객에게도 필요한 기능이고, 무엇이 이 고객에게만 맞춘 설정일까요?
그 구분을 프로젝트 도중에 해내야 다음 프로젝트가 빨라집니다.
[얻게되는 경험]
• 공공망부터 대용량 교육 서비스까지, 서로 다른 고객 환경에 Agent를 올리고 운영하는 경험
• 현장에서 만든 것이 플랫폼 기능이 되어 다음 고객에게 쓰이는 경험
• 문제 정의부터 인계까지 한 프로젝트를 끝까지 책임지는 경험
• 프로젝트 PM과 함께 고객사에 들어가 현업의 실제 업무를 관찰하고 담당자를 인터뷰합니다.
• 들은 요구를 기술 범위로 옮깁니다. 무엇을 Agent에게 맡기고 무엇을 사람의 확인·승인으로 남길지,
성공을 어떤 지표로 볼지 고객과 합의합니다.
• LaivStudio로 동작하는 프로토타입을 빠르게 만들어 보여 주고, 본 개발 전에 방향을 맞춥니다.
• 필요하면 제안·PoC 단계부터 기술 검토와 제안서 기술 파트 작성에 참여합니다.
[2] 고객 데이터와 시스템 연결하기
• 고객 문서(PDF·스캔본·표·엑셀)를 DataMart로 구조화합니다.
청킹 규칙, 메타데이터, 하이브리드 검색과 Rerank를 고객 문서에 맞게 조정합니다.
• 고객 사내 시스템과 레거시 API를 MFlux로 MCP Tool화하고, 인증·권한·타임아웃·재시도를 처리합니다.
• DB와 기간계 시스템에서 Agent가 읽고 쓸 데이터의 범위와 권한을 정합니다.
[3] Agent 구축하기
• LangBridge(LangGraph)로 멀티 에이전트 흐름, 세션 재개, 사람 승인 단계를 구성합니다.
• 플랫폼에 없는 기능은 Python(FastAPI) 또는 TypeScript(NestJS·React)로 화면부터 서버까지 직접 개발합니다.
• 권한 밖 데이터 접근, 개인정보 노출, 업무 범위 밖 답변을 막는 안전장치를 둡니다.
[4] 품질을 숫자로 끌어올리기
• 고객이 '맞는 답'이라고 보는 기준을 Veris 평가 시나리오와 루브릭으로 만듭니다.
• 운영 로그에서 실패 사례를 모아 검색 실패·판단 실패·도구 실패로 나누고 원인을 고칩니다.
• 수정 전후를 같은 시나리오로 비교해 개선을 수치로 보고합니다.
[5] 배포·운영·인계
• 클라우드, 사내 설치형, 외부 인터넷이 막힌 사내망 등 고객 환경에 맞춰 Docker·Kubernetes로 배포합니다.
• 개통 뒤 모니터링과 장애 대응을 맡습니다.
• 고객 운영팀이 스스로 운영할 수 있도록 운영 매뉴얼과 진단 방법을 남겨 인계합니다.
[6] 현장에서 배운 것을 플랫폼으로 되돌리기
• 프로젝트를 마치면 회고하고, 다른 고객에게도 쓸 수 있는 커넥터·프롬프트·평가 시나리오·배포 스크립트를
골라 LAIV NEXUS에 반영합니다.
• 플랫폼이 부족했던 지점을 Agent Foundry 플랫폼 개발자에게 재현 가능한 사례로 전달합니다.
• 웹 서비스 또는 AI 제품 개발 경력 3년 이상, 만든 것을 실제 사용자에게 배포하고 운영해 본 분
• Python 또는 TypeScript로 백엔드 API와 데이터 처리 코드를 직접 작성하고,
필요하면 프론트엔드까지 손댈 수 있는 분
• LLM API로 tool calling이나 RAG 기능을 직접 구현해 본 분 (개인 프로젝트도 인정합니다)
• 외부 시스템·API를 연동하면서 인증, 실패, 재시도, 타임아웃을 처리해 본 분
• 고객이나 현업 담당자와 직접 대화하며 요구사항을 정리하고, 이번에 할 것과 미룰 것을 합의해 본 분
• Claude Code, Cursor 같은 AI 코딩 도구를 일상적으로 쓰되, 생성된 코드를 직접 읽고 검증해 책임질 수 있는 분
• 프로젝트에 따라 고객사 현장 상주와 출장이 가능한 분
AI Agent 데모는 이제 어디서나 볼 수 있습니다.
그런데 고객사에 들어가면 이야기가 달라집니다.
문서는 스캔한 PDF와 엑셀에 흩어져 있고, 연동할 시스템은 명세와 다르게 움직이고,
금융권 사내망에서는 외부 API를 부르는 것조차 막혀 있습니다.
라이브데이터는 이 간극을 메우는 일을 하고 있습니다.
교육·금융·공공 고객사에 Agent를 직접 구축하고, 실제 사용자가 쓰는 서비스로 운영합니다.
■ 고객이 늘수록, 같은 문제를 다시 풉니다
고객사마다 문서를 다시 쪼개고, API를 다시 붙이고, 품질 기준을 다시 세웁니다.
이 반복을 줄이려고 만든 것이 자사 Agent 개발 플랫폼 LAIV NEXUS입니다.
• DataMart — 고객 문서를 Agent가 쓸 수 있는 지식 구조로 (구조 추출, 청킹, 인덱싱, 검색)
• LaivStudio — 캔버스에서 Agent를 설계하고 재배포 없이 바로 테스트
• MFlux — 고객 시스템의 REST API를 MCP Tool로 자동 변환
• LangBridge — LangGraph 기반 멀티 에이전트 흐름 제어, 중단된 지점부터 이어가는 세션
• Veris — 시나리오 기반 대화 수집과 LLM-as-a-Judge 평가로 변경 전후 품질 비교
FDE는 이 플랫폼을 들고 고객 현장에 들어가는 사람입니다.
그리고 플랫폼이 현장에서 어디가 부족한지 가장 먼저 발견하는 사람입니다.
■ 라이브데이터의 FDE
Forward Deployed Engineer(FDE)는 고객사 현장에서 업무를 직접 보고,
LAIV NEXUS로 Agent를 만들어 운영까지 책임지는 엔지니어입니다.
• 요구사항 문서를 받아 그대로 납품하는 SI 개발자가 아닙니다.
무엇을 만들지는 현업 담당자 옆에서 업무를 보며 함께 정합니다.
• 방향만 제시하고 빠지는 컨설턴트도 아닙니다.
코드를 직접 쓰고, 배포하고, 운영 중 문제가 생기면 직접 고칩니다.
• 한 고객을 위한 결과물로 끝내지 않습니다.
다른 고객에게도 필요한 커넥터, 검색 설정, 평가 시나리오는 LAIV NEXUS 기능으로 되돌려
다음 프로젝트를 더 빠르게 만듭니다.
프로젝트는 고객과 합의한 지표가 실제로 움직이고,
고객 운영팀이 우리 없이도 Agent를 돌릴 수 있게 인계했을 때 끝납니다.
■ 포지션이 나와 맞는지 지원 전에 생각해 보세요
1) 외부 API를 쓸 수 없는 고객사
증권사 사내망에서는 데이터가 밖으로 나갈 수 없습니다.
외부 LLM API 대신 사내에 올린 모델로 돌려야 하고, 라이브러리 하나를 들이는 데도 반입 절차가 필요합니다.
이 환경에서 Agent의 답변 품질과 속도를 어디까지 끌어올릴 수 있을까요?
2) 명세와 다르게 움직이는 고객 시스템
고객 시스템을 MCP Tool로 연결하면 Agent가 그 시스템을 직접 씁니다.
그런데 명세에 없는 오류 코드가 오고, 응답이 수십 초씩 걸리고, 권한은 사용자마다 다릅니다.
Agent가 실패했을 때 무엇을 다시 시도하고, 언제 사람에게 넘겨야 할까요?
3) "답이 좀 이상해요"라는 피드백
고객은 무엇이 이상한지 정확히 말해 주지 않습니다.
검색이 틀렸는지, 문서가 잘못 잘렸는지, 판단이 틀렸는지를 가려내야 합니다.
고객이 생각하는 '맞는 답'을 평가 시나리오로 옮기고, 고치기 전과 후를 숫자로 비교할 수 있을까요?
4) 이번 고객만을 위한 코드
일정에 쫓기면 고객별 예외 처리가 쌓입니다.
그중 무엇이 다음 고객에게도 필요한 기능이고, 무엇이 이 고객에게만 맞춘 설정일까요?
그 구분을 프로젝트 도중에 해내야 다음 프로젝트가 빨라집니다.
[얻게되는 경험]
• 공공망부터 대용량 교육 서비스까지, 서로 다른 고객 환경에 Agent를 올리고 운영하는 경험
• 현장에서 만든 것이 플랫폼 기능이 되어 다음 고객에게 쓰이는 경험
• 문제 정의부터 인계까지 한 프로젝트를 끝까지 책임지는 경험
주요업무
[1] 현장에서 문제 정의하기• 프로젝트 PM과 함께 고객사에 들어가 현업의 실제 업무를 관찰하고 담당자를 인터뷰합니다.
• 들은 요구를 기술 범위로 옮깁니다. 무엇을 Agent에게 맡기고 무엇을 사람의 확인·승인으로 남길지,
성공을 어떤 지표로 볼지 고객과 합의합니다.
• LaivStudio로 동작하는 프로토타입을 빠르게 만들어 보여 주고, 본 개발 전에 방향을 맞춥니다.
• 필요하면 제안·PoC 단계부터 기술 검토와 제안서 기술 파트 작성에 참여합니다.
[2] 고객 데이터와 시스템 연결하기
• 고객 문서(PDF·스캔본·표·엑셀)를 DataMart로 구조화합니다.
청킹 규칙, 메타데이터, 하이브리드 검색과 Rerank를 고객 문서에 맞게 조정합니다.
• 고객 사내 시스템과 레거시 API를 MFlux로 MCP Tool화하고, 인증·권한·타임아웃·재시도를 처리합니다.
• DB와 기간계 시스템에서 Agent가 읽고 쓸 데이터의 범위와 권한을 정합니다.
[3] Agent 구축하기
• LangBridge(LangGraph)로 멀티 에이전트 흐름, 세션 재개, 사람 승인 단계를 구성합니다.
• 플랫폼에 없는 기능은 Python(FastAPI) 또는 TypeScript(NestJS·React)로 화면부터 서버까지 직접 개발합니다.
• 권한 밖 데이터 접근, 개인정보 노출, 업무 범위 밖 답변을 막는 안전장치를 둡니다.
[4] 품질을 숫자로 끌어올리기
• 고객이 '맞는 답'이라고 보는 기준을 Veris 평가 시나리오와 루브릭으로 만듭니다.
• 운영 로그에서 실패 사례를 모아 검색 실패·판단 실패·도구 실패로 나누고 원인을 고칩니다.
• 수정 전후를 같은 시나리오로 비교해 개선을 수치로 보고합니다.
[5] 배포·운영·인계
• 클라우드, 사내 설치형, 외부 인터넷이 막힌 사내망 등 고객 환경에 맞춰 Docker·Kubernetes로 배포합니다.
• 개통 뒤 모니터링과 장애 대응을 맡습니다.
• 고객 운영팀이 스스로 운영할 수 있도록 운영 매뉴얼과 진단 방법을 남겨 인계합니다.
[6] 현장에서 배운 것을 플랫폼으로 되돌리기
• 프로젝트를 마치면 회고하고, 다른 고객에게도 쓸 수 있는 커넥터·프롬프트·평가 시나리오·배포 스크립트를
골라 LAIV NEXUS에 반영합니다.
• 플랫폼이 부족했던 지점을 Agent Foundry 플랫폼 개발자에게 재현 가능한 사례로 전달합니다.
자격요건
연차보다 고객 앞에서 무엇을 직접 만들어 냈는지를 봅니다. 기준은 다음과 같습니다.• 웹 서비스 또는 AI 제품 개발 경력 3년 이상, 만든 것을 실제 사용자에게 배포하고 운영해 본 분
• Python 또는 TypeScript로 백엔드 API와 데이터 처리 코드를 직접 작성하고,
필요하면 프론트엔드까지 손댈 수 있는 분
• LLM API로 tool calling이나 RAG 기능을 직접 구현해 본 분 (개인 프로젝트도 인정합니다)
• 외부 시스템·API를 연동하면서 인증, 실패, 재시도, 타임아웃을 처리해 본 분
• 고객이나 현업 담당자와 직접 대화하며 요구사항을 정리하고, 이번에 할 것과 미룰 것을 합의해 본 분
• Claude Code, Cursor 같은 AI 코딩 도구를 일상적으로 쓰되, 생성된 코드를 직접 읽고 검증해 책임질 수 있는 분
• 프로젝트에 따라 고객사 현장 상주와 출장이 가능한 분
