개발자는 L3인데 비개발자는 L1 — Afinit이 FDE 조직을 만든 이유
![]()
AX(AI Transformation)를 하지 않는 회사는 드물어요. 근데 "지금 어느 정도 됐나요?"라고 물으면 명확히 답할 수 있는 회사는 얼마나 될까요? Afinit의 TFS(Tech Foundation) 팀에서 AI Native를 위해 고군분투하고 있는 Austin이 경험을 공유했는데, 읽다 보니 우리 회사 얘기 같더라고요.
테슬라 FSD에서 착안한 AI 전환 지표, 근데 결과가 좀 불편했다
Afinit 팀은 작년 하반기부터 AX의 근간을 다지기 시작했어요. 여러 AI 툴을 직접 써보고, 비개발팀의 목소리도 들어봤습니다. 이 경험을 바탕으로 ANTI(AI-Native Transformation Index)라는 AX 측정 방법을 만들었어요.
ANTI는 Tesla FSD 자율주행 레벨에서 착안했습니다. FSD가 운전자 개입 정도로 레벨을 나누듯, ANTI는 사람이 업무에 개입하는 방식으로 레벨을 나눠요.

그래서 이걸로 측정해봤더니요. 개발자분들은 대부분 L3까지 도달해 있었어요. Claude Code나 Cursor로 에이전트와 스킬을 적극 활용하며 팀 내 Agent 사용 문화를 정착시키고 있었습니다.
비개발자분들은 달랐어요. 아직 L1 작업이 남아 있었고, L2 수준으로 사용하시는 분들이 대부분이었습니다. 직접 이야기를 들어보니 공통적인 문제들이 보였어요.
개발자들은 전산 자원 안에서 자유롭게 문제를 해결해 왔지만, 비개발자분들은 플랫폼에 의존해 온 경우가 많았어요. 데이터는 쌓여 있어도 활용할 수 없거나, 그대로 버려지는 경우가 대부분이었고요. 사실 이건 대부분의 회사에서 벌어지는 일이에요. 개발자한테 "AI 써봐"라고 하면 바로 쓰지만, 기획자한테 같은 말을 하면 "어떻게요?"가 먼저 나오잖아요.
FDE는 코치다 — 소프트웨어를 전달하는 게 아니라 현장에 들어간다
이 갭을 메우기 위해 Afinit 팀은 FDE(Forward Deployed Engineer)라는 조직을 만들었어요. 팔란티어에서 시작된 직군 개념입니다. 팔란티어는 소프트웨어를 개발해 고객사에 전달하는 대신, "전방 배치(Forward Deployed)"라는 뜻 그대로 엔지니어를 현장에 파견해서 그 조직과 함께 문제를 풀었거든요.

Afinit은 이 개념을 사내에 적용했어요. 외부 고객사 대신, 사내 각 부서가 대상입니다. FDE는 각 팀을 찾아가 도메인을 공부하고, 문제를 파악하고, 충분한 대화를 통해 요구사항을 정제하고 솔루션을 기획합니다. 그리고 AI를 활용해 문제를 해결하는 서비스를 개발하고, 해당 팀과 함께 유지보수하고요.
근데 FDE 업무의 핵심은 개발이 아니에요. 비개발자분들의 역량 강화입니다. Claude Code를 비롯한 AI 기술을 알려드리고, AI 행사 등을 통해 실질적인 도움을 드리는 것. 프로젝트 스펙과 변경 이력을 참고하는 AI Agent를 초기에 함께 만들어서, 해당 팀이 직접 유지보수할 수 있도록 설계하는 것. 비개발자분들이 AI Champion으로 성장하도록 돕는 거예요. (Austin은 이걸 "운동부 코치와 유망주 운동선수" 관계에 비유하더라고요.)
목표는 각 팀에서 AI Champion을 양성해 자체적으로 AI를 레버리지할 수 있는 힘을 갖추고, 주변 팀원들에게도 좋은 영향을 줘서 궁극적으로 AI Native Company로 거듭나는 것입니다.
가장 많은 시간이 걸리는 건 코딩이 아니라 도메인 파악이다

FDE 업무에서 가장 많은 시간이 걸리는 건 개발이 아니라 도메인 파악이에요. 각 부서의 업무 언어, 판단 기준, 반복 작업의 패턴을 이해하지 못하면 요구사항을 정의할 수 없거든요. Legal 팀과 미팅할 때는 기존 문서 검토 프로세스와 NDA 계약서 구조, 주요 조항의 의미부터 배워야 했고, Risk Management 팀에서는 비즈니스 리스크 관리의 전반적인 업무를 먼저 파악해야 했다고 합니다.
Slack 채널로 사전 조사를 했어요. 인터뷰 전에 해당 팀의 Slack 채널을 읽으면서 어떤 용어를 쓰는지, 어떤 이슈가 반복되는지, 의사결정이 어떤 방식으로 이루어지는지를 파악했습니다. Austin은 각 부서의 Public Slack 채널에 접근해 해당 팀의 역할과 행동을 분석하는 에이전트를 만들었어요.
결과가 놀라웠다고 해요. 반복되는 메시지 패턴, 내용 기반 중요도 분석, 시간대별 활동량 등을 통해 해당 팀을 충분히 이해할 수 있었거든요. AI로 풀 수 있는 문제가 무엇인지, 그 문제가 어떤 워크플로우에서 발생하는지, 해당 워크플로우의 중요도는 어느 정도인지를 사전에 파악할 수 있었다고요. 이건 솔직히 영리한 접근이에요.
인도 팀원 및 C-level Office Hour도 활용했습니다. 사전 조사한 내용을 바탕으로 인도 현지 팀원들과 대화하며 도메인 이해를 점검하고, 생산성을 높이고 올해 목표를 달성하기 위해 어떤 도움이 필요한지 인터뷰했어요. Afinit의 각 C-level은 정기적으로 Office Hour를 운영하는데, 부서별 인터뷰가 실무 레벨의 맥락을 준다면, Office Hour는 조직 전체의 방향과 우선순위를 보여줍니다. 어떤 자동화가 실제로 의미 있는지 판단하려면 이 두 레이어를 함께 이해해야 한다는 거죠.
학습한 내용을 전사 문서로 정리했어요. 각 부서를 파악하면서 배운 내용은 개인 메모로 끝내지 않았습니다. "Afinit Map"이라 부르는 전사 공유 문서로 정리했어요. 이 문서는 회사의 미션인 "Finance for All"에서 시작해 각 대출 상품과 그 상품을 개발/운영하는 부서들이 어떻게 상호작용하는지를 전체 지도로 그린 거예요.
새로 합류하신 분들의 온보딩 자료가 되는 것은 물론이고요. 더 나아가 Afinit의 온톨로지로서 비즈니스 상태와 부서별 상황을 한눈에 파악할 수 있는 기반으로 발전시킬 계획이라고 합니다. 도메인 이해를 위한 노력이 그냥 사라지지 않고, 조직 자산으로 남는 구조를 만든 거예요.
모든 건 데이터 전산화에서 시작된다
잠깐 딴 얘기인데, 도메인을 이해하고 나면 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가 변경되기도 했고, 플랫폼을 만드는 과정에서도 요구사항이 계속 변하고 추가되었거든요. 정기적인 미팅에서 요구사항을 체계적으로 정리해야 했고, 플랫폼도 변경에 유연하게 설계하려고 노력했다고 합니다.
빠르게 만들고 빠르게 피드백받는 이런 환경에서, 약 한 달 안에 프로젝트를 완성하려면 주니어 개발자인 Austin 혼자로는 불가능했어요. 그래서 AI Agent 팀을 구성해 개발했어요. 인터뷰 영상 스크립트를 바로 PRD(Product Requirement Doc)로 뽑아내는 Agent를 활용하고, HTML로 프로토타이핑한 뒤 이해관계자에게 빠르게 피드백을 받아 스펙을 다듬었습니다. 스펙이 완성되면 Engineering Agent 팀에 전달해 개발을 진행했고요. 매주 이해관계자의 피드백과 추가 요청을 반영하며 빠르게 개발을 완료할 수 있었다고 합니다.
Risk Management 팀 — MUW cutoff 추천 봇

MUW(Manual Underwriting)는 수동 대출 심사이며, CPA들이 처리해요. RM(Risk Management) 팀의 중요한 업무 중 하나는 CPA 가용률을 최적화해 대출 상환 능력이 있는 고객을 놓치지 않는 것입니다. 하지만 CPA 인원은 한정되어 있어서, 큐가 너무 많으면 심사해야 할 건을 놓치고, 너무 적으면 CPA 가용률이 낮아져요.
기존 모니터링 시스템에서 한 발 더 나아가, 과거 데이터 기반으로 cutoff를 추천하는 봇을 만들었어요. 과거 데이터를 바탕으로 현재 상황에 맞는 Normal Range를 생성하고, 매시간 현재 상태가 정상 범위 안에 있는지 판단합니다. 비정상 범위가 감지되면, 아무 조치를 하지 않았을 때와 cutoff를 변경했을 때의 예측을 차트로 생성해 변경안과 함께 메시지로 전달해요.
이걸 통해 RM 팀은 MUW cutoff 계산을 AI에 위임하고, 사람은 최종 결정만 내리면 되는 수준에 도달했다고 합니다. ANTI 기준으로 보면 L3에서 L4로 가는 길목에 있는 거예요. 앞으로 사람의 판단 데이터가 쌓이면 AI에게 완전히 위임할 수 있는 기반도 마련된 셈이고요. 금융 도메인에서 AI에 판단을 위임한다는 건 상당히 의미 있는 진전이에요.
Strategy 팀 — 비개발자가 AI 에이전트를 만들었다
이건 시스템 개발보다 AI 문화 도입에 초점을 맞춘 사례예요. Strategy 팀은 여러 맥락에서 리포트를 작성해야 하는데, 특히 Afinit이 해외 사업 확장을 앞두고 있어 시장 조사 수요가 많았습니다. 해외 시장 조사는 현지 법/규제 이해, 로컬 언어 자료 검색 및 번역, 문화 차이 등의 허들이 있어서 시간과 품이 특히 많이 드는 업무거든요.
Strategy 팀과 여러 세션을 잡아 Claude Code 사용법부터 Agentic하게 업무를 AI에 위임하는 방법까지 공유했고, 해외 시장 리서치 에이전트를 만들어 빠르게 정보를 수집할 수 있었어요. 더 나아가 한국/해외 마켓 비교, 정보 출처 크로스체킹까지 에이전트에 룰을 추가하며 정확하고 인사이트가 담긴 자료를 수집하도록 발전시켰다고 합니다.
비개발자분도 AI 에이전트를 만들 수 있다는 선례가 된 거예요. Strategy 팀원분이 직접 한국/해외 마켓 비교 기능을 추가하고, 정보 출처 크로스체킹까지 에이전트에 룰을 추가하며 발전시키셨다고요. 비개발자가 터미널에서 AI 에이전트를 생성하고 응용한다는 건, 불과 1년 전만 해도 상상하기 어려웠던 일이에요.
이 경험을 통해 Austin은 두 가지를 확인했다고 합니다. AI Champion 발굴이 얼마나 중요한지, 그리고 FDE로서 사내 AI 서비스를 만드는 것도 중요하지만 AI 사용 문화를 조성하는 것 역시 그만큼 중요하다는 것.
"한 달이 1년 같다"는 말의 무게
Austin은 팀에서 한 달이 1년 같다는 말이 자주 나온다고 했어요. AI 기술은 하루가 다르게 발전하고, "어차피 나중에 더 좋은 AI 솔루션이 나올 텐데 지금부터 이것저것 시도할 필요가 있느냐"고 생각할 수도 있다고요.
근데 직접 부딪히며 얻는 경험의 가치는 무시할 수 없잖아요. 솔직히 이게 더 어려운 일이에요. 코드는 짜면 돌아가는데, 문화는 뿌리내리는 데 시간이 걸리니까요.
정리하면, Afinit의 FDE 모델이 보여주는 건 세 가지예요. 첫째, AX의 진짜 병목은 기술이 아니라 비개발자와 개발자 사이의 갭이다. 둘째, 그 갭을 메우려면 소프트웨어를 전달하는 게 아니라 현장에 들어가야 한다. 셋째, 도메인을 먼저 이해하지 않으면 아무리 좋은 AI 도구도 쓸모없다. 이 세 번째가 FDE의 존재 이유이자, 가장 시간이 많이 드는 부분이기도 합니다.