고객 현장에서 제품을 완성하는 FDE파트
Cultures
FDE파트는 제논 솔루션엔지니어링그룹에 속한 조직입니다. FDE(Forward Deployed Engineer)는 고객 현장에 나가 일하는 엔지니어라는 뜻으로, 해외에서도 최근에야 널리 알려지기 시작했고 국내에서도 조금은 생소할 수 있는 직군입니다. FDE의 역할을 한 문장으로 설명하자면, 제논이 만든 제품을 고객 현장에서 인증과 데이터, 업무 시스템에 연결해 실제로 쓰이는 서비스로 완성하는 일입니다. 제품이 만들어졌다고 해서 고객이 바로 쓸 수 있는 것은 아니기 때문인데요. 파트 구성원은 금융사의 폐쇄망(외부 인터넷과 분리된 사내 전용 네트워크) 안과 신규 구축 현장, 본사 등 다양한 현장에서 업무를 수행합니다. 제품이 실제 현장에서 잘 작동하기까지 엔지니어에게 어떤 노력이 필요한지, FDE파트 파트장에게 들어봤습니다!
제품이 만들어졌다는 것과 고객이 실제로 사용할 수 있다는 것은 전혀 다른 문제입니다. 제논의 FDE는 그 사이를 메워 제품을 고객의 업무로 완성하는 엔지니어입니다. AI 엔지니어가 에이전트의 판단 구조를 만들고 클라우드와 인프라 조직이 실행 기반을 구성한다면, FDE는 그 결과물을 고객의 인증, 데이터, 업무 시스템과 연결해 실제 서비스로 완성합니다.
제노스(GenOS)를 고객 환경에 설치하는 데서 끝나는 것이 아닙니다. 한 번 로그인으로 여러 시스템에 들어가게 하는 통합 인증(SSO)과 누가 어디까지 접근할 수 있는지 관리하는 계정 권한 체계(IAM), 내부 데이터와 고객이 오래 써 온 기존 업무 시스템(레거시 시스템), 보안 정책에 맞게 연결하고, 현장에 필요한 서버 쪽(백엔드)과 화면 쪽(프론트엔드) 기능을 개발하며, 테스트와 배포, 오픈 후 안정화와 장애 대응까지 책임집니다.
그렇다고 모든 분야의 일을 FDE 혼자 처리한다는 의미는 아닙니다. 현장에서 문제를 가장 먼저 받아 전체 구조와 영향을 파악하고, 필요한 제품개발, AI, 인프라와 데브옵스(개발한 것을 배포하고 운영하는 일을 맡는 조직) 담당자를 연결한 뒤, 고객이 실제로 사용할 수 있는 상태가 될 때까지 결과를 놓치지 않는 기술 오너에 가깝습니다.
한마디로 설명하면, 제논의 기술이 고객 환경에서 한 번 동작하는 것을 넘어 계속 운영될 수 있게 만드는 사람입니다.
저는 웹 백엔드 개발자, 그리고 서버와 화면 양쪽을 모두 다루는 풀스택 개발자로 시작했습니다. 보험과 자동차 분야에서 프로그램끼리 명령을 주고받는 통로(API) 개발, 문서 이미지에서 글자를 읽어내는 기술(OCR), 회계와 인사, 구매 같은 업무를 한 시스템에서 관리하는 전사 시스템(ERP), 데이터 수집 자동화 등 여러 프로젝트를 경험했습니다.
제논에서의 시작은 발전사 생성형 AI 구축 프로젝트 현장이었습니다. 제논 동료들과 고객 현장에서 함께 일하며 제논의 제품과 일하는 방식을 가까이에서 경험했습니다.
이전에는 주어진 기능을 잘 구현하는 데 집중했다면, 해당 현장에서는 데이터가 어디에서 들어와 어떤 과정을 거쳐 전처리(수집한 데이터를 검색에 쓸 수 있는 형태로 정리하는 작업)되고 검색과 운영까지 어떻게 이어지는지를 전체 흐름으로 봐야 했습니다. 고객의 환경과 제약을 직접 확인하고 여러 조직과 함께 실제로 운영되는 상태까지 만드는 일이 제 성향과 잘 맞았습니다. 이 경험을 한 프로젝트에 머무르게 하지 않고 조직의 역량으로 확장해 보고 싶다는 생각이 FDE라는 역할과 이후 FDE파트 운영으로 이어졌습니다.
근무 방식은 프로젝트와 단계에 따라 달라집니다. 특히 금융과 공공 고객의 폐쇄망에서는 외부에서 로그(시스템이 남기는 동작 기록)나 데이터를 확인할 수 없기 때문에 현장 상주나 정기 방문의 비중이 높습니다. 평상시에는 주간 실무회의와 진행 보고를 기본적인 소통 리듬으로 둡니다. 장애나 일정에 영향이 있는 이슈는 정기회의까지 기다리지 않고 바로 현상, 영향 범위, 현재 조치와 다음 회신 시점을 공유합니다.
요구사항을 받을 때도 "이 기능을 만들어 달라"는 문장만 그대로 받지 않습니다. 왜 필요한지, 누가 어떤 업무에서 사용하는지, 현재 방식의 문제가 무엇인지, 완료됐다고 판단할 기준이 무엇인지까지 확인한 뒤 표준 기능으로 해결할 부분과 연동이나 커스터마이징(고객 맞춤 개발)이 필요한 부분을 구분해 설명합니다.
현장에서 모든 질문에 즉시 답하는 것이 좋은 대응이라고 생각하지도 않습니다. 확인되지 않은 내용을 즉흥적으로 답하는 대신 "확인해서 O일까지 진행 상황을 회신드리겠습니다"라고 약속하고, 필요한 조직에 빠르게 연결한 뒤 약속한 시점 전에 답을 드리는 것이 더 중요합니다. 고객이 현재 상황과 다음 행동을 예측할 수 있게 만드는 것이 신뢰의 기본이라고 생각합니다.
FDE파트의 한 주는 모두가 같은 사무실에 모여 시작하지 않습니다. 누군가는 금융사 폐쇄망 안에서 일하고, 누군가는 신규 구축 현장에 있으며, 누군가는 본사에서 여러 사이트를 지원합니다. 그래서 지금 파트에서는 각자 무엇을 많이 했는가보다, 사이트에서 지금 무엇이 막혀 있고 고객에게 무엇을 언제까지 답해야 하는지를 먼저 맞추는 기준을 잡아가고 있습니다.
주간보고와 정기적인 FDE 공유 자리에서 완료한 일, 다음 계획, 이슈와 리스크, 고객 확인사항을 정리합니다. 주중에는 요구사항 협의부터 연동과 개발, 배포, 데이터 검증, 장애 분석까지 각 사이트 상황에 맞는 업무를 진행합니다. 현장에서 바로 답하기 어려운 문제는 혼자 오래 끌지 않고 제품개발, AI, 인프라와 데브옵스 등 필요한 조직에 연결하며, 확인한 내용과 결정 사항은 다시 고객과 내부 양쪽에 남깁니다.
현장 대응과 문서화가 별개의 일이 아니라, 대응한 내용을 다음 사람이 이어갈 수 있게 만드는 것까지가 FDE의 한 주라고 생각합니다.
앞서 말한 발전사 프로젝트에서 여러 내부 시스템의 문서를 수집해 AI 검색에 활용할 수 있도록 만드는 작업이 기억에 남습니다. 처음에는 기록물, 발전설비, 인사, 내규와 같은 시스템에서 데이터를 가져오는 수집기 개발로 보였지만, 현장에 들어가 보니 문제는 훨씬 넓었습니다.
개발용 환경(개발계)에서는 접속되던 대상이 실제 운영 환경에서는 보안 정책 때문에 열리지 않기도 했고, HWP와 PDF, 첨부문서의 형태가 제각각이어서 수집에 성공했다는 것만으로 실제 데이터 품질을 보장할 수 없었습니다. 대량의 데이터를 저장소에 넣는 적재 과정에서는 처리량 변화에 따라 일정이 크게 달라질 수 있었고, 추출된 문서와 청크(문서를 AI가 검색하기 좋은 크기로 잘라 놓은 조각)가 올바른지 사람이 확인하고 수정한 뒤 다시 적재할 수 있는 운영 도구도 필요했습니다.
그래서 팀과 함께 시스템별 수집과 스케줄 관리, 데이터 누락 검증, 전처리 결과를 확인하고 수정하는 청크와 벡터 편집 도구(Chunk/Vector Editor)와 관련 API, 재처리와 적재 흐름을 하나씩 연결했습니다. 동시에 장애 원인을 애플리케이션 하나로 단정하지 않고 데이터베이스와 벡터DB(문서를 AI가 검색할 수 있는 숫자 형태로 바꿔 저장하는 데이터베이스), 네트워크와 배포 환경까지 나누어 확인하고, 처리량과 남은 작업량을 근거로 고객에게 일정을 설명했습니다.
이 경험을 통해 FDE의 문제 해결은 기능 하나를 빨리 만드는 것이 아니라, 데이터가 들어오는 순간부터 고객이 결과를 검증하고 운영하는 순간까지 전체 흐름이 끊기지 않게 만드는 일이라는 것을 배웠습니다.
모든 기술을 매일 같은 비율로 사용하는 구조는 아닙니다. 프로젝트 초반에는 고객의 시스템과 데이터, 인증과 보안 규격을 분석하고 환경을 구성하는 일이 많습니다. 구축 단계에서는 파이썬과 FastAPI(파이썬으로 서버 프로그램을 만드는 프레임워크), 데이터베이스를 다루는 언어인 SQL을 활용한 API 개발, 데이터 수집과 전처리, 레거시 연동의 비중이 커집니다. 고객이나 운영자가 직접 확인하고 제어해야 하는 기능이 있으면 웹 화면을 만드는 프레임워크인 React나 Next.js로 관리 화면과 현장 도구를 만들기도 합니다.
오픈과 안정화 단계로 가면 리눅스, 도커(프로그램과 실행 환경을 하나로 묶어 어디서든 같은 방식으로 실행하게 해 주는 도구), 쿠버네티스(여러 서버에 프로그램을 나눠 띄우고 자동으로 관리해 주는 도구), 네트워크, 데이터베이스와 로그를 다루는 시간이 크게 늘어납니다. 어떤 주에는 개발보다 고객 협의, 데이터 검증, 배포와 장애 분석이 더 많은 경우도 있습니다.
그래서 FDE에게 중요한 것은 사용 가능한 언어와 프레임워크의 개수를 늘어놓는 것이 아니라, 문제가 발생했을 때 시스템의 경계를 넘어 전체 요청 흐름을 따라갈 수 있는 능력입니다. 백엔드나 인프라처럼 자신 있게 깊게 들어갈 수 있는 기술 축을 하나 가지고 있으면서, 인접 영역의 로그와 설정을 읽고 필요한 담당자와 같은 언어로 대화할 수 있어야 합니다.
FDE의 입장에서 가장 크게 체감하는 제논의 개발 문화는 문제를 직군의 경계로 먼저 자르지 않는다는 점입니다. 고객 현장에서 보이는 하나의 오류도 실제 원인은 애플리케이션, 데이터, 모델, 쿠버네티스, 네트워크나 데이터베이스 중 어디에 있을지 처음부터 알기 어렵습니다. 이럴 때 "우리 팀 일이 아니다"라고 넘기기보다 관련 조직이 메신저 스레드나 회의에 빠르게 모여 로그와 구조를 함께 확인하고 가장 적절한 해결 방법을 찾는 편입니다.
다만 빠르게 해결하는 것만으로 충분하지는 않습니다. 어떤 대안을 검토했고 왜 그 방식을 선택했는지, 배포와 운영 시 무엇을 주의해야 하는지까지 남겨야 다른 사이트가 같은 문제를 처음부터 다시 풀지 않을 수 있습니다. 현장에서 나온 문제를 일회성 대응으로 끝내지 않고 공통 결함이나 제품 개선 요구로 되돌리는 것, 그리고 개인의 경험을 조직의 자산으로 만드는 것이 제논의 개발 문화를 더 강하게 만드는 방향이라고 생각합니다.
가장 크게 성장했다고 느낀 시점은 FDE파트를 맡은 뒤였습니다. 중부발전 프로젝트에서는 눈앞에 있는 기술 문제를 제가 직접 해결하면 됐지만, 파트장이 되고 여러 사이트를 함께 살펴보니 더 큰 문제가 보였습니다. 한 현장에서 이미 해결한 문제가 다른 현장에서는 다시 처음부터 검토되고, 특정 담당자가 알고 있는 조치와 판단이 그 사람이 없으면 이어지지 않는 경우가 있었습니다.
그때부터 "내가 얼마나 많은 문제를 해결했는가"보다 "내가 없어도 팀이 같은 품질로 해결할 수 있는가"를 기준으로 보게 됐습니다. FDE의 성장 기준을 단순한 연차나 수행량이 아니라 수행, 자산화, 조직 기여로 나누고, 주간보고와 이슈 관리, 사이트별 구성 정보(형상)와 조치 이력, 온보딩과 인수인계 기준을 정리하기 시작한 이유도 여기에 있습니다.
개발자로서 한 사이트의 문제를 해결하는 사람에서, 여러 사이트가 같은 시행착오를 줄일 수 있는 구조를 만드는 사람으로 역할이 넓어진 것이 제논에서 가장 크게 성장한 부분입니다.
특정 프레임워크 하나보다 기술을 실제 서비스로 완결하는 법을 가장 많이 배우게 됩니다. 화면에서 오류 하나가 보였을 때 프론트엔드 코드만 보는 것이 아니라 인증과 게이트웨이(외부 요청이 내부 시스템으로 들어오는 관문), API, 데이터베이스, 데이터 파이프라인(데이터가 수집되어 가공과 저장을 거치는 처리 흐름), 벡터DB와 모델 서빙(학습된 AI 모델을 서비스에서 호출할 수 있게 띄워 두는 것)까지 요청이 지나가는 전체 경로를 따라가며 원인을 좁히게 됩니다.
동시에 고객이 요청한 기능의 배경과 목적을 확인하고, 제품의 표준 기능으로 가능한 부분과 추가 개발이 필요한 부분을 구분해 일정과 위험, 대안을 설명해야 합니다. 개발한 기능을 배포한 뒤 실제 데이터로 검증하고, 장애가 생겼을 때 복구하며, 운영 조직이 이어받을 수 있도록 정리하는 경험도 함께 하게 됩니다.
이런 과정을 반복하다 보면 단순히 구현을 잘하는 개발자를 넘어 하나의 단위 업무와 고객 사이트의 기술적 의사결정을 맡을 수 있는 엔지니어로 성장할 수 있습니다.
10. 마지막으로, FDE라는 커리어의 매력은 무엇이고 어떤 개발자가 FDE로 성장하기 좋을까요?
FDE의 가장 큰 매력은 결과가 코드 저장소 안에서 끝나지 않고 고객의 실제 업무에서 확인된다는 점입니다. 내가 만든 연동을 통해 고객 데이터가 들어오고, 사용자가 서비스를 사용하며, 장애가 발생했을 때 원인을 찾아 다시 정상화하는 전 과정을 경험할 수 있습니다. 자연스럽게 기술의 폭이 넓어질 뿐 아니라 요구사항, 범위와 일정, 품질과 리스크를 함께 보는 시야가 생기기 때문에 단위 업무 리드, 사이트 리드, 이후에는 프로젝트 리더(PL)와 프로젝트 매니저(PM)로 성장할 수 있는 경로도 열려 있습니다.
반대로 정해진 개발 환경에서 코드만 작성하고 싶거나, 배포 이후의 운영과 고객 커뮤니케이션을 자신의 일과 분리하고 싶은 분에게는 쉽지 않은 직무일 수 있습니다.
FDE는 모든 기술을 이미 알고 있는 사람이 아니라, 모르는 문제 앞에서 숨지 않는 사람에게 잘 맞습니다. 요청을 그대로 구현하기 전에 왜 필요한지 질문하고, 로그와 사실을 근거로 문제를 좁히며, 답을 모를 때는 필요한 도움과 회신 시점을 명확히 말할 수 있어야 합니다. 여기에 자신이 해결한 내용을 다른 사람이 다시 사용할 수 있도록 기록하고 공유하는 습관이 있다면 빠르게 성장할 수 있습니다.
한 영역의 깊이, 새로운 영역을 배우는 속도, 고객과 동료에게 현재 상황을 투명하게 공유하는 책임감이 좋은 FDE를 만드는 핵심이라고 생각합니다.
