보스턴의 보안 기업인 VulnCheck가 금융 엔지니어(Finance Engineer)를 채용하고 있습니다. 채용 공고에 따르면, 채용된 인원은 GL(총계정원장), 빌링(billing), CRM 및 지출 관리 시스템을 "API/MCP를 통해" 연결해야 합니다. 또한 차이 분석 주석(variance commentary)을 작성하고 이상 징후를 식별하는 Claude 기반 워크플로우를 구축해야 합니다. 그리고 "버전 관리(version control) 및 예측 로직(forecast logic)을 포함하여" 재무 모델의 기술적 아키텍처(technical architecture)를 책임져야 합니다.

마지막 문장을 다시 읽어보십시오. 버전 관리(Version control). 재무 모델을 위한 버전 관리라니요. 심지어 소속 팀이 '재무(Finance)'로 기재된 사람의 책임입니다.

이것은 진정한 의미의 직무 기술서(job description)가 아닙니다. 이는 어떤 역량이 필요하지만 이를 제공하는 제품을 찾지 못한 기업이, 제품 대신 사람을 채용하며 작성한 시스템 요구사항(systems requirement)입니다.

우리는 이것이 특이한 채용 공고 하나인지, 아니면 하나의 패턴인지 확인하기 위해 조사했습니다. 이것은 패턴이며, 이 패턴은 그 밑단에 깔린 툴링(tooling)에 대해 불편한 사실을 말해줍니다.

채용 공고가 실제로 말하는 것

그래서 우리는 수치를 계산했습니다. 2026년 7월, 우리는 미국과 유럽 전역의 1,061개 후보 고용주들의 공개 채용 게시판 API를 조회하였고, 응답한 421개의 활성 게시판에 있는 27,278개의 모든 공개 채용 공고를 스캔했습니다. 각 고용주가 공고 자체에 할당한 부서를 기준으로 필터링한 후, 전체 텍스트에서 살아남은 모든 항목을 코딩했습니다. 그 결과 26개 고용주에 걸쳐 37개의 적격 채용 요구사항(requisitions)이 도출되었으며, 전체 방법론, 판정 규칙 및 코퍼스(corpus)는 The Finance Engineer Role: Job Posting Statistics에 공개되었습니다. 여기서 세 가지 발견 사항이 중요합니다.

그것을 무엇이라 부를지에 대해 아무도 동의하지 않습니다. 37개의 채용 공고에 37개의 서로 다른 직함이 있었습니다. 두 명의 고용주도 같은 방식으로 표현하지 않았으며, 정확히 단 한 곳만이 직무를 명확하게 "금융 엔지니어 (Finance Engineer)"라고 불렀습니다. 나머지는 에이전틱 금융 엔지니어 (Agentic Finance Engineer), 금융 및 공급망 엔지니어링 기술 리드 (Tech Lead for Finance & Supply Chain Engineering), 금융 시스템 엔지니어링 헤드 (Head of Engineering for Finance Systems), 금융 시스템 아키텍트 매니저 (Finance System Architect Manager), 금융 엔지니어링을 위한 주문-현금 전환 트랙 리드 (Order to Cash Track Lead for Finance Engineering) 등과 같았습니다. 37개 중 16개는 직함에 금융 관련 단어가 전혀 포함되어 있지 않았습니다. Brex의 "데이터 엔지니어 (Data Engineer)", OpenAI의 "Workday 엔지니어 (Workday Engineer)", Attentive의 "Anaplan 애플리케이션 개발자 (Anaplan Application Developer)", ElevenLabs의 "시스템 아키텍트 (Systems Architect)"가 각각 금융 또는 회계 부서 내에 소속되어 있었습니다. 직함 검색으로는 이 인력 집단을 찾아낼 수 없으며, 이는 이들을 집계하려는 사람이라면 가장 먼저 알아야 할 사실입니다.

또한 이는 매우 희귀합니다. 해당 421개 기업의 987개 금융 부서 공석 중 엔지니어링 역할은 26개였습니다. 이는 2.6%, 즉 38개 중 1개에 해당합니다. 이것은 아직 하나의 흐름(wave)이 아닙니다. 특정하고 비용이 많이 드는 도박을 하고 있는 소수의 기업들입니다.

그리고 그들은 홀로 이 도박을 하고 있습니다. 명백한 대안은 벤더(vendor)가 대신 엔지니어를 배치하도록 하는 것이며, 이것이 바로 포워드 디플로이드 엔지니어 (Forward Deployed Engineer, FDE) 붐이 존재하는 이유입니다. 동일한 채용 게시판에는 66개 기업에 걸쳐 348개의 FDE 공고가 있습니다. 그중 정확히 하나의 채용 공고만이 금융 관련 직무였습니다. 솔루션 아키텍트 (Solutions Architect)와 구현 엔지니어 (Implementation Engineer)를 포함하여 배포 형태의 모든 역할로 범위를 넓히면 545개의 채용 공고가 나오는데, 그중 금융과 접점이 있는 것은 14개뿐이며 그마저도 거의 모두가 플랫폼 판매에 부수되는 프리세일즈 (Presales) 역할입니다. 아무도 당신을 위해 이것을 구축하러 오지 않을 것입니다.

이것은 미국만의 이야기가 아닙니다. 유럽 전역의 91개 이상의 고용 게시판을 조사한 결과 독일, 영국, 스페인, 스웨덴, 폴란드에서 이 직무를 발견했습니다: Helsing은 Munich에서 Finance Data Engineer를 채용하고, Zilch는 UK에서 finance analytics engineer를, Celonis는 Madrid에서 Finance Systems Engineer를, Lovable은 Stockholm에서 Financial Systems Engineer를 채용합니다. 유럽의 금융 부서 개설률은 1.9%로 미국(2.6%)보다 낮아 격차는 분명하지만 크지 않습니다. 다만 유럽에는 이 직무에 대한 명확한 용어(vocabulary)가 부족할 뿐입니다. 어떤 유럽 게시글도 이 직무를 'finance engineer'라고 부르지는 않습니다.

대부분, 하지만 항상은 아닙니다. 금융 부서에 속합니다. 37개 중 26개가 고용주에 의해 Finance, Accounting 또는 Finance Systems 부서에 배치됩니다: Anthropic, OpenAI, Coinbase, Databricks, Brex, Stripe, Twilio, Attentive, Cloudflare, SoFi, Mercor, Affirm, VulnCheck. 보고 체계가 명시된 경우, 금융 리더의 이름이 언급됩니다: VP of FP&A, Head of Finance Systems, Senior Manager of Finance Data and AI.

나머지 11개의 예외 사례들이 이 깔끔한 이야기 버전을 복잡하게 만듭니다. Klaviyo는 전체 'Finance Engineering' 기능을 IT & Security 부서에서 운영합니다. Block은 Senior Finance Systems Engineer를 Engineering에, CoreWeave와 Epirus는 IT에, Harvey는 Product에, Whoop은 Business Intelligence에 배치합니다. 따라서 변화의 방향성은 분명하며, 금융 부서는 티켓을 접수하는 대신 자체 시스템을 구축하고 있습니다. 하지만 여전히 세 개 중 약 하나의 역할이 금융 외부에 속해 있으며, 이 변화가 보편적이라고 주장하는 사람은 아직 계산하지 않은 것입니다.

한 사람에게 두 가지 경력을 요구합니다. Spring Health의 Senior Finance Engineer 채용 공고는

이러한 채용 공고가 무엇이 이미 존재한다고 가정하는지에 답이 있다

채용 공고에서 동사들을 걷어내고 나면 하나의 쇼핑 리스트가 나타납니다. 전체 데이터 집합을 살펴보면, 고용주들은 금융 팀이 다음과 같은 것들을 이미 사용할 수 있다고 당연하게 가정하고 있습니다:

• 금융 모델에 대한 버전 관리 (Version control). 단순한 파일에 대한 관리가 아닙니다. 모델에 대한 관리, 즉 무엇이, 언제, 누구에 의해 변경되었으며, 그것이 하류(downstream) 프로세스에 어떤 영향을 미쳤는지에 대한 관리입니다.
• 금융 데이터뿐만 아니라 금융 로직에 대한 API 표면 (API surface). 세 곳의 고용주가 올린 네 개의 공고에서 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)이 프로토콜 명칭 그대로 언급되었으며, 이들은 모두 금융 부서 내부의 역할입니다: VulnCheck, ElevenLabs, 그리고 OpenAI의 Enterprise AI Platform 역할 두 곳 모두 해당됩니다. 2024년 말에 출시된 에이전트 상호운용성 표준 (agent interoperability standard)이 기업 금융 채용의 항목이 된 것입니다.
• 세션과 사람 사이에서도 지속되는 관례 (Conventions). 채용 공고에서 "보고 패키지(reporting packages)를 구성한다"라고 말할 때, 이는 10월에 사용된 ARR(연간 반복 매출)의 정의가 3월에 사용된 정의와 동일할 것이라고 가정하는 것입니다.
• 출력된 숫자로부터 그 숫자를 변화시킨 가정(assumption)으로 거슬러 올라가는 감사 경로 (Audit path). 결산(close), 차이 분석(variance commentary) 또는 ASC 준수를 언급하는 모든 공고는 이를 암묵적으로 가정하고 있습니다.

이 네 가지 요소 모두 소프트웨어 엔지니어링(software engineering)에서는 지극히 평범한 것입니다. Git, API, 스키마(schemas), 커밋 히스토리(commit history)는 이미 수십 년 전에 해결된 문제입니다. 하지만 금융 분야에서는 이 네 가지 중 어느 것도 표준이 아닙니다. 그 이유는 금융 팀의 수준이 낮아서가 아닙니다. 바로 기질(substrate)의 문제입니다.

또한 이는 비용이 많이 드는 일이며, 그 비용의 형태가 핵심을 보여줍니다. 17개의 공고가 미국 기준 급여 범위를 공개했는데, $112,000에서 $385,000 사이였으며, 중앙값 범위의 중간값(median band midpoint)은 $231,500였습니다.

더욱 명확한 수치는 OpenAI에서 나옵니다. OpenAI는 모든 역할에 대해 구조화된 급여 범위를 공개하며, 동일한 조건으로 비교할 수 있을 만큼 충분한 채용 공고를 보유하고 있습니다. OpenAI의 금융 부서 엔지니어링 역할 5개는 중앙값 범위 중간값이 $307,500였습니다. 동일한 금융 부서 내의 다른 45개 역할은 $228,000였습니다. 반면, 297개의 제품 엔지니어링 (product engineering) 역할은 $309,000였습니다.

따라서 그곳의 재무 부서 엔지니어(finance-department engineer)는 재무 조직의 나머지 인원보다 35% 더 많은 급여를 받으며, 제품 엔지니어(product engineer)와는 0.5% 이내의 차이만을 보입니다. 이 프리미엄은 재무 전문성(finance expertise)에 대한 대가가 아니며, 비용 센터(cost-centre) 할인이 아닙니다. 이 기업들은 재무 부서에 위치한 엔지니어링 업무에 대해 완전한 엔지니어링 요율을 지불하고 있는 것입니다. 이는 특정 역량이 반드시 존재해야 한다고 결론 내렸으나, 이를 판매하는 벤더(vendor)가 없을 때 수행하게 되는 작업입니다.

스프레드시트는 훌륭한 계산기이지만, 형편없는 기질(substrate)이다

이 점은 명확하게 말할 가치가 있습니다. 왜냐하면 '엑셀 반대(anti-Excel)' 장르의 글들은 지루하며 대부분 틀렸기 때문입니다.

Excel은 본연의 기능에 있어 매우 탁월합니다. 이는 금융의 공용어(lingua franca)이며, 별도의 교육 없이도 사내 누구나 읽을 수 있고, 투자자, 감사인, 인수자가 모두 수용하는 형식이며, 숫자로 된 질문에 답하는 세계에서 가장 빠른 방법입니다. 여기서 결과물(deliverable)로서의 Excel을 대체해야 한다고 주장하는 것이 아닙니다. Excel은 사라지지 않을 것이며, 사라져서도 안 됩니다.

하지만 스프레드시트는 위에서 언급한 네 가지 요구사항을 충족하기에는 부적합한 특성들을 가지고 있습니다:

• 파일 복사본은 버전(version)이 아니다. Model_v4_FINAL_rev2_JD.xlsx는 무언가가 변경되었다는 사실은 기록합니다. 하지만 무엇이, 왜, 그리고 무엇을 망가뜨렸는지는 기록하지 않습니다.
• API는 로직(logic)이 아닌 셀(cell) 위에 구축된다. D14를 읽을 수는 있습니다. 하지만 D14가 무엇을 의미하는지, 무엇이 그것에 데이터를 공급하는지, 혹은 그것이 입력값(input)인지 출력값(output)인지 물을 수는 없습니다. 파일 형식에는 그러한 구분이 존재하지 않습니다.
• 의도(Intent)가 지속되지 않는다. 성장률이 12%인 이유는 모델 설계자의 머릿속에 있거나, 주석(comment)에 있거나, 혹은 어디에도 없습니다.
• 타입(types)이 없다. 0.12는 세율(tax rate), 마진(margin), 이탈 가정(churn assumption) 또는 반올림 오차(rounding artifact)일 수 있습니다. 인간은 문맥(context)을 통해 이를 추론하지만, 에이전트(agent)는 추측할 뿐입니다.

따라서 기업이 "금융 모델을 위한 자체 버전 관리(version control) 및 예측 로직(forecast logic)을 구축할 것"이라고 명시할 때, 오늘날 금융 엔지니어(finance engineer)가 내놓을 수 있는 정직한 답변은 일련의 임시방편(workarounds)뿐입니다. 즉, 명명 규칙(naming convention), 의미 있는 차이(diff)를 확인할 수 없는 git 저장소 내의 .xlsx 파일 폴더, 그리고 한 분기 만에 쓸모없어지는 문서화된 규칙 페이지 같은 것들 말입니다. 이는 누군가 가정(assumption)을 변경하여 링크의 절반이 조용히 작동을 멈추기 전까지만 유효하게 작동합니다.

그것이 바로 채용 공고가 인력 채용이라는 방식으로 임시방편으로 가리고 있는 격차(gap)입니다.

"사례를 요구할 것입니다"

이러한 채용 공고에서는 두 번째 현상이 나타나고 있으며, 이 부분은 해당 역할이 채워지는 방식을 바꿀 가능성이 가장 높습니다.

금융권 채용은 오랫동안 자격 요건(credentials)을 중심으로 이루어져 왔으며, 여기에는 방어 가능한 이유가 있었습니다. 바로 업무가 보이지 않았기 때문입니다. 업무는 타인의 ERP 내부에 존재했고, 비밀 유지 계약(NDA) 하에 있었으며, 당신이 가지고 나갈 수 없는 파일 속에 있었습니다. 보여줄 수 있는 것이 없었기에, 사람들은 이력서에 CPA, MBA, 혹은 근무했던 은행을 기재했습니다.

하지만 이 말뭉치(corpus)에 포함된 공고들은 그것을 요구하지 않습니다. 그들은 당신이 무엇을 만들었는지를 묻고 있습니다. 당신이 출시한 자동화(automation), 결산(close) 기간을 7일에서 2일로 단축한 경험, 팀이 실제로 사용하는 에이전트 워크플로(agent workflow) 같은 것들 말입니다. 이러한 변화는 업무를 보여줄 수 있을 때에만 가능합니다.

여기에 문제가 있습니다. 대부분의 금융 업무는 여전히 보여줄 수 없습니다. 스프레드시트(spreadsheet)는 첨부하는 것이지 보여주는 것이 아닙니다. 그것은 고용주의 실제 수치를 담고 있고, 설명하는 데 40분이 걸리며, 구조가 데이터와 분리될 수 없기 때문에 기밀 입력값(confidential inputs)을 함께 공유하지 않고서는 그 사고 과정(thinking)만을 공유할 수 없습니다.

구조가 데이터와 분리 가능한(structure is separable from its data) 모델은 전혀 다른 결과물입니다. 로직(logic), 의존성 그래프(dependency graph), 규칙(conventions), 타임라인(timeline) 등이 포함되어 공유 가능하고, 포크(fork) 가능하며, 검토(review) 가능하고, 누구의 실제 수치도 포함하지 않은 채 당신의 것임을 증명할 수 있는 것입니다. 그것이 바로 포트폴리오(portfolio)가 됩니다. 또한 우연하게도, 이는 애초에 버전 관리(version control)와 API 접근을 가능하게 만드는 것과 동일한 속성입니다.

이 역할을 위한 기질(substrate)에 필요한 것

만약 당신이 이러한 역할 중 하나를 맡게 되거나, 이러한 직무 기술서(job description)를 작성하고 있다면, 근본적인 질문은 '당신이 무엇 위에 구축할 것인가'입니다. 요구 사항은 이제 다음과 같이 명명할 수 있을 정도로 충분히 일관적입니다:

1. 데이터와 분리된 구조 (Structure separated from data): 숫자를 함께 끌고 가지 않고도 로직을 버전 관리(versioning)하고, 검토하며, 재사용할 수 있어야 합니다.
2. 명시적인 의존성 그래프 (A dependency graph that is explicit): 가정이 변경되었을 때, 예상치 못한 결과가 발생하는 대신 파악 가능한 하류 효과(downstream effects) 세트가 생성되어야 합니다.
3. 도구가 읽을 수 있는 형태로 기록된 컨벤션 (Conventions written down in a form the tooling reads): 인간뿐만 아니라 도구도 읽을 수 있어야 합니다. 이것이 바로 FINANCE.md가 존재하는 이유입니다. 통화, 단위, 부호 규약(sign convention), 조직이 ARR을 의미하는 바 등을 누군가의 기억 속이 아닌 모델과 함께 운반합니다.
4. 에이전트가 접근 가능한 인터페이스 (An agent-addressable interface): 채용 공고들은 이미 LLM이 루프 안에 있음을 가정하고 있기 때문입니다. 만약 당신의 에이전트가 숫자 하나를 바꾸기 위해 모델 전체를 다시 읽어야 한다면, 토큰 비용과 드리프트(drift)로 그 대가를 치르게 될 것입니다.
5. 엑셀(Excel)은 언제나 퇴장하는 길에 있습니다: 최종 결과물은 여전히 .xlsx입니다. 당신을 가두는 기질(substrate)은 그것이 대체한 스프레드시트보다 더 나쁩니다.

Layerz는 정확히 이러한 형태를 위해 구축되었습니다. 즉, 구조는 데이터와 별도로 버전 관리되며, 에이전트가 MCP를 통해 구동하는 구조화된 모델이자, 결코 유료 결제 장벽(paywall)에 막히지 않는 깔끔한 엑셀 내보내기를 제공합니다. Layerz가 하지 않는 일에 대해서도 명확히 할 가치가 있습니다. 이것은 ERP가 아니며 결산(close) 업무를 수행하지 않습니다. NetSuite, Workday 또는 대부분의 채용 공고가 통합하는 데 시간을 소비하는 빌링 시스템(billing system)을 대체하지도 않습니다. 그리고 만약 당신의 업무가 진정으로 일회성 분석(one-shot analysis)이라면, 스프레드시트와 좋은 프롬프트가 언제나 속도 면에서 이를 앞설 것입니다.

Layerz가 제 자리를 찾는 곳은 채용 공고들이 계속해서 설명하지만 스프레드시트는 담아낼 수 없는 부분입니다. 즉, 지속 가능하며, 에이전트가 망가뜨리지 않고 변경할 수 있고, 추론 과정(reasoning)이 온전하게 유지된 채 다른 사람에게 전달할 수 있는 모델입니다.

결론 (The bottom line)