Forward Deployed Engineer - AI native 최전선에 배치된 엔지니어
안녕하세요. TFS(Tech Foundation) 팀에서 AI Native를 위해 고군분투하고 있는 Austin입니다. 이번 글에서는 Forward Deployed Engineer로서 경험한 것들을 공유하려고 합니다.
AI Native 로 가는 길
Afinit 만의 AI Native 측정 방식
요즘 AX(AI Transformation)를 하지 않는 회사는 드뭅니다. 그런데 “지금 어느 정도 됐나요?”라는 질문에 명확히 답할 수 있는 회사는 많지 않을 것입니다. 저희 팀은 작년 하반기부터 AX의 근간을 다지기 시작했습니다. 여러 AI 툴을 직접 사용해 보고, 비개발팀의 목소리도 들어봤습니다. 이 경험을 바탕으로 ANTI (AI-Native Transformation Index)라는 AX 측정 방법을 만들었습니다.
ANTI는 Tesla FSD 자율주행 레벨에서 착안했습니다. FSD가 운전자 개입 정도로 레벨을 나누듯, ANTI는 사람이 업무에 개입하는 방식으로 레벨을 나눕니다.
자세한 내용은 https://blog.afinit.com/tech-working-with-ai-2 참고
개발자와 비개발자의 갭
작년 하반기부터 지금까지 Tech Talk을 비롯한 여러 활동을 진행한 결과, 개발자분들은 대부분 L3까지 도달했습니다. Claude Code나 Cursor로 에이전트와 스킬을 적극 활용하며 팀 내 Agent 사용 문화를 정착시키고 있습니다.
하지만 비개발자분들의 상황은 달랐습니다. 아직 L1 작업이 남아 있었고, L2 수준으로 사용하시는 분들이 대부분이었습니다.
직접 이야기를 들어보니 공통적인 문제들이 있었습니다.
본업을 하기도 바쁜데 AI Agent/Automation까지 공부하고 사용하기 어려움
폐쇄형 SaaS 플랫폼 구조 때문에 AI integration이 용이하지 않음
데이터가 잘 남아 있지 않고, 남아 있어도 사용 가능한 형태로 보존되어 있지 않음
개발자들은 전산 자원 안에서 자유롭게 문제를 해결해 왔지만, 비개발자분들은 플랫폼에 의존해 온 경우가 많았습니다. 데이터는 쌓여 있어도 활용할 수 없거나, 그대로 버려지는 경우가 대부분이었습니다.
Forward Deployed Engineer란
앞서 말씀드린 것처럼, 비개발자분들은 AX를 하기 어려운 환경에 놓여 있습니다. 저희 팀은 이 문제를 해결하기 위해 FDE(Forward Deployed Engineer)라는 조직을 만들었습니다.
FDE는 팔란티어에서 시작된 직군 개념입니다. 팔란티어는 소프트웨어를 개발해 고객사에 전달하는 대신, 전방 배치(Forward Deployed)라는 뜻 그대로 엔지니어를 현장에 파견해 그 조직과 함께 문제를 풀었습니다.
저희는 이 개념을 사내에 적용했습니다. 외부 고객사 대신, 사내 각 부서가 대상입니다.
FDE는 각 팀을 찾아가 도메인을 공부하고, 그들이 가진 문제를 파악합니다. 충분한 대화를 통해 요구사항을 정제하고 솔루션을 기획합니다. 그리고 AI라는 강력한 도구를 활용해 문제를 해결하는 서비스를 개발하고, 해당 팀과 함께 유지보수합니다.
사실 FDE 업무의 핵심은 비개발자분들의 역량 강화입니다. Claude Code를 비롯한 AI 기술을 알려드리고, AI 행사 등을 통해 실질적인 도움을 드리고 있습니다. 또한 프로젝트 스펙과 변경 이력을 참고하는 AI Agent를 초기에 함께 만들어, 해당 팀이 직접 유지보수할 수 있도록 설계합니다. 비개발자분들이 AI의 힘을 체감하고, 역량을 끌어올려 사내 AI Champion으로 성장하도록 돕는 것이 목표입니다. 각 팀에서 AI Champion을 양성해 자체적으로 AI를 레버리지할 수 있는 힘을 갖추고, 주변 팀원들에게도 좋은 영향을 주어 궁극적으로 AI Native Company로 거듭나는 것을 지향합니다.
FDE = 운동부 코치, 비개발팀원 = 유망주 운동선수 -> Champion
도메인 이해가 먼저다
FDE 업무에서 가장 많은 시간이 걸리는 건 개발이 아니라 도메인 파악입니다. 각 부서의 업무 언어, 판단 기준, 반복 작업의 패턴을 이해하지 못하면 요구사항을 정의할 수 없습니다. Legal 팀과 미팅할 때는 기존 문서 검토 프로세스와 NDA 계약서 구조, 주요 조항의 의미부터 배워야 했고, Risk Management 팀에서는 비즈니스 리스크 관리의 전반적인 업무를 먼저 파악해야 했습니다. 여러 팀의 도메인을 이해하기 위해 노력했던 경험을 공유합니다.
Slack 채널로 사전 조사
인터뷰 전에 먼저 해당 팀의 Slack 채널을 읽습니다. 어떤 용어를 쓰는지, 어떤 이슈가 반복되는지, 의사결정이 어떤 방식으로 이루어지는지가 채널 흐름에 그대로 드러납니다. 저는 각 부서의 Public Slack 채널에 접근해 해당 팀의 역할과 행동을 분석하는 에이전트를 만들고, 이를 통해 사전 조사를 진행했습니다.
결과는 놀라웠습니다. 반복되는 메시지 패턴, 내용 기반 중요도 분석, 시간대별 활동량 등을 통해 해당 팀을 충분히 이해할 수 있었습니다. AI로 풀 수 있는 문제가 무엇인지, 그 문제가 어떤 워크플로우에서 발생하는지, 해당 워크플로우의 중요도는 어느 정도인지를 사전에 파악할 수 있었습니다.
인도 팀원 및 C-level Office Hour 활용
FDE 업무의 핵심은 실제 사내 동료들의 이야기를 듣는 것입니다. 사전 조사한 내용을 바탕으로 인도 현지 팀원들과 대화하며 도메인 이해를 점검하고, 어떤 문제가 있는지, 생산성을 높이고 올해 목표를 달성하기 위해 어떤 도움이 필요한지 인터뷰합니다. 또한 Afinit의 각 C-level은 정기적으로 Office Hour를 운영하는데, 이 자리를 활용해 인터뷰에서 얻은 정보를 검증하고 추가 맥락을 파악합니다. 부서별 인터뷰가 실무 레벨의 맥락을 준다면, Office Hour는 조직 전체의 방향과 우선순위를 보여줍니다. 어떤 자동화가 실제로 의미 있는지 판단하려면 이 두 레이어를 함께 이해해야 합니다.
학습한 내용을 전사 문서로
각 부서를 파악하면서 배운 내용은 개인 메모로 끝내지 않고 전사 공유 문서로 정리했습니다. “Afinit Map”이라 부르는 이 문서는, 회사의 미션인 “Finance for All”에서 시작해 각 대출 상품과 그 상품을 개발·운영하는 부서들이 어떻게 상호작용하는지를 전체 지도로 그린 것입니다. 새로 합류하신 분들의 온보딩 자료가 되는 것은 물론, 더 나아가 Afinit의 온톨로지로서 비즈니스 상태와 부서별 상황을 한눈에 파악할 수 있는 기반으로 발전시킬 계획입니다.
AI 전환의 시작점 — 데이터 전산화
도메인을 이해하고 나면 AI 자동화의 대상을 정의할 수 있습니다. 회사에서 하루에 만들어지는 데이터는 상당합니다. 계약서 검토 의견, 리스크 판단 근거, 고객 상담 내용, 회의 기록 등. 그런데 이 데이터 대부분이 이메일 본문, 개인 메모, 비공개 채팅에 흩어져 있고, 일회성으로 소비된 뒤 사라집니다. JP Morgan 같은 금융사는 GPT 학습에 사용된 전체 데이터보다 더 많은 사내 데이터를 보유하고 있다고 합니다(Alexandr Wang, 2025). 이 데이터를 AI가 패턴을 찾을 수 있는 형태로 저장하는 것, 그 자체가 경쟁력입니다.
세 팀, 세 방식
Legal 팀 — NDA 리뷰 플랫폼
시작은 Legal 팀이 아니라 BD(Business Development) 팀이었습니다. 파트너사 온보딩 프로세스에서 초기 단계인 NDA 리뷰에 시간이 너무 많이 걸리고 있었습니다. NDA 자체는 계약서 중에서도 단순한 축에 속하지만, 회사가 빠르게 성장하면서 Legal 팀의 검토 건이 늘어나 NDA 리뷰가 밀리는 것이 문제였습니다. Legal 팀을 인터뷰하고 실제 리뷰 과정을 관찰한 끝에, 사내 Legal Review Platform을 만들기로 했습니다.
사용자가 리뷰할 문서 타입(NDA 등)을 선택하고 파일을 업로드하면, AI가 해당 타입에 맞는 분석 프롬프트와 참고 자료(회사 표준 템플릿, 과거 검토 이력)를 로드합니다. 이를 바탕으로 조항별 변경 추천을 생성하고, 변호사가 직접 수정과 코멘트를 달 수도 있습니다. AI review의 프롬프트와 참고 자료는 관리자가 직접 설정할 수 있어, Legal 팀이 자체적으로 분석 기준을 관리합니다.
이 프로젝트를 진행하며 많이 배웠습니다. 초기에는 BD 팀과 인터뷰를 진행하다 Legal 팀으로 Stakeholder가 변경되기도 했고, 플랫폼을 만드는 과정에서도 요구사항이 계속 변하고 추가되었습니다. 정기적인 미팅에서 요구사항을 체계적으로 정리해야 했고, 플랫폼도 변경에 유연하게 설계하려고 노력했습니다.
빠르게 만들고 빠르게 피드백받는 이런 환경에서, 약 한 달 안에 프로젝트를 완성하려면 주니어 개발자인 저 혼자로는 불가능했습니다. 그래서 AI Agent 팀을 구성해 개발했습니다.
인터뷰 영상 스크립트를 바로 PRD(Product Requirement Doc)로 뽑아내는 Agent를 활용하고, HTML로 프로토타이핑한 뒤 이해관계자에게 빠르게 피드백을 받아 스펙을 다듬었습니다. 스펙이 완성되면 Engineering Agent 팀에 전달해 개발을 진행했고, 모든 개발 과정을 문서화하며 로깅, 테스트, 배포 프레임워크에 맞춰 관리했습니다.
이런 방식으로 매주 이해관계자의 피드백과 추가 요청을 반영하며 빠르게 개발을 완료할 수 있었습니다.
Risk Management 팀 — MUW 가용율 모니터링
MUW(Manual Underwriting)는 수동 대출 심사이며, CPA들이 처리합니다. RM(Risk Management) 팀의 중요한 업무 중 하나는 CPA 가용률을 최적화해 대출 상환 능력이 있는 고객을 놓치지 않는 것입니다. 하지만 CPA 인원은 한정되어 있어, 큐가 너무 많으면 심사해야 할 건을 놓치고, 너무 적으면 CPA 가용률이 낮아집니다.
기존 모니터링 시스템에서 한 발 더 나아가, 과거 데이터 기반으로 cutoff를 추천하는 봇을 만들었습니다. 과거 데이터를 바탕으로 현재 상황에 맞는 Normal Range를 생성하고, 매시간 현재 상태가 정상 범위 안에 있는지 판단합니다. 비정상 범위가 감지되면, 아무 조치를 하지 않았을 때와 cutoff를 변경했을 때의 예측을 차트로 생성해 변경안과 함께 메시지로 전달합니다.
이를 통해 RM 팀은 MUW cutoff 계산을 AI에 위임하고, 사람은 최종 결정만 내리면 되는 수준에 도달했습니다. 앞으로 사람의 판단 데이터가 쌓이면 AI에게 완전히 위임할 수 있는 기반도 마련되었습니다.
Strategy 팀 – Agentic workflow 생성
이번 케이스는 시스템 개발보다, 한 부서에 AI 문화를 도입하고 AI Champion을 양성하는 데 초점을 맞춘 사례입니다. Strategy 팀은 여러 맥락에서 리포트를 작성해야 하는데, 특히 Afinit이 해외 사업 확장을 앞두고 있어 시장 조사 수요가 많았습니다. 해외 시장 조사는 현지 법·규제 이해, 로컬 언어 자료 검색 및 번역, 문화 차이 등의 허들이 있어 시간과 품이 특히 많이 드는 업무입니다.
Strategy 팀과 여러 세션을 잡아 Claude Code 사용법부터 Agentic하게 업무를 AI에 위임하는 방법까지 공유했고, 해외 시장 리서치 에이전트를 만들어 빠르게 정보를 수집할 수 있었습니다. 더 나아가 한국·해외 마켓 비교, 정보 출처 크로스체킹까지 에이전트에 룰을 추가하며 정확하고 인사이트가 담긴 자료를 수집하도록 발전시키셨습니다. 비개발자분도 AI 에이전트를 만들 수 있다는 선례가 되어, 다른 분들에게도 용기를 준 사례였습니다.
이 경험을 통해 AI Champion 발굴의 중요성과, 개발자가 아닌 분도 터미널에서 AI 에이전트를 생성하고 응용할 수 있다는 가능성을 확인했습니다. FDE로서 사내 AI 서비스를 만드는 것도 중요하지만, AI 사용 문화를 조성하는 것 역시 그만큼 중요하다는 것을 다시 한번 느꼈습니다.
마무리 하며
저희 팀에서는 한 달이 1년 같다는 말이 자주 나옵니다. AI 기술은 하루가 다르게 발전하고 있고, 아마 여러분도 이 거대한 흐름 속에서 방향을 찾으려 노력하고 계실 것입니다. 저도 마찬가지입니다. 한편으론 어차피 나중에 더 좋은 AI 솔루션이 나올 텐데 지금부터 이것저것 시도할 필요가 있느냐고 생각하실 수도 있습니다. 하지만 직접 부딪히며 얻는 경험의 가치는 무시할 수 없습니다. 이 글이 AX를 위해 힘쓰고 계신 분들께 조금이나마 도움이 되었으면 합니다. 읽어주셔서 감사합니다.