AI 채용 공고를 여러 차례에 걸쳐 수집해 비교해 보면, 대부분의 직무는 비슷한 기울기로 늘어난다. 그런데 한 직무만 곡선이 다르다.
**FDE(Forward Deployed Engineer, 포워드 디플로이드 엔지니어)**다. 사업부 안에 들어가 앉아서, 손으로 하던 업무를 자동화된 업무로 바꿔놓는 사람이다.
이 글은 그 직무가 실제로 무엇을 하는지, 그리고 그 일을 하려면 어떤 도구를 다룰 줄 알아야 하는지를 정리한 것이다. 계약과 상주 구조에 대해서는 FDE는 첫 4주가 전부다와 FDE 계약은 공수가 아니다에서 이미 다뤘다. 여기서는 그 자리에 앉는 사람의 관점으로 본다.
4.2배, 그리고 주니어 0명
수집 시점 사이의 변화는 이렇다.
| 항목 | 수치 |
|---|---|
| FDE 공고 수 | 28건 → 118건 |
| 증가율 | 4.2배 |
| 같은 기간 AI 직무 전체 증가율 | 2.3배 |
| 고객 대면 업무 명시 | 91% |
| 주니어 채용 | 0건 |
전체 시장이 2.3배 늘어나는 동안 이 직무만 4.2배로 늘었다. 그런데 신입이나 주니어를 뽑는 공고는 한 건도 없다.
공고에 적힌 요구 기술은 이렇게 나뉜다.
| 기술 | 언급 비율 |
|---|---|
| Python | 91% |
| 프롬프트 엔지니어링 | 55% |
| 검색 증강(RAG) | 52% |
| 에이전트 | 42% |
| MCP | 13.0% (직전 수집 8.0%) |
RAG가 절반 넘게 등장하지만, 실제 현장에서 요구되는 것은 2023년식 벡터 검색 파이프라인이 아니다. 에이전트가 필요할 때 스스로 검색 도구를 호출해 근거를 모으는 구조에 가깝다. 공고의 단어는 아직 옛것이고, 업무는 이미 옮겨갔다.
MCP는 8.0%에서 13.0%로 올라왔다. 아직 절대 수치는 작지만, 반년 사이에 언급 비율이 6할 이상 늘어난 항목은 이것뿐이다.
업무 도메인은 더 명확하다.
| 도메인 | 언급 비율 |
|---|---|
| 수작업 워크플로 자동화 | 72.9% |
| 사내 엔터프라이즈 운영 | 64.2% |
챗봇을 만드는 자리가 아니다. 사람이 손으로 하던 사내 업무를 자동화하는 자리다.
이 직무가 실제로 하는 일
구체적인 장면으로 옮겨보자.
보험사 보상팀이 하루에 문서 800건을 손으로 처리하고 있다. 청구서를 열고, 필드를 읽고, 사내 시스템에 옮겨 적는다.
FDE로 들어간 첫 주에 할 일은 코드를 쓰는 게 아니다. 이틀 동안 그 팀 옆에 앉아 있는 것이다. 노트북은 덮어둔다.
이유는 하나다. 위키에 적혀 있는 프로세스는 진짜 프로세스가 아니다. 실제 담당자는 특정 보험사 문서는 두 번째 페이지부터 읽고, 금액이 일정 기준을 넘으면 옆자리에 물어보고, 특정 코드가 찍힌 건은 아예 다른 화면으로 넘긴다. 이 중 어느 것도 문서화되어 있지 않다. 그리고 이것들이 자동화의 성패를 가른다.
이틀이 지나면 가장 많이 반복되는 한 단계를 고른다. 전체 프로세스가 아니라 한 단계다.
94%라는 숫자
필드 추출을 만들어 보니 정확도가 94%가 나왔다. 나쁘지 않아 보인다.
94%는 문서 16건당 한 번 틀린다는 뜻이다. 그리고 이 업무가 현업에서 허용하는 오류율은 500건당 한 건이다.
여기서 갈린다. 정확도를 99.8%까지 끌어올리려는 시도는 대개 실패한다. 6%에서 0.2%로 가는 것은 5.8%포인트 개선이 아니라 오류율을 30분의 1로 줄이는 일이다. 남은 6%는 대부분 희귀하고 지저분한 예외이고, 그게 바로 모델이 못 맞히는 이유다.
그래서 판단을 자동화하지 않는다. 타이핑을 자동화한다.
핵심은 신뢰도를 문서 단위가 아니라 필드 단위로 쪼개는 것이다. 문서 한 장에 필드가 12개 있으면, 그중 10개는 확신이 높고 2개만 애매한 경우가 대부분이다. 문서 단위로 판정하면 그 문서 전체가 사람에게 넘어간다. 필드 단위로 판정하면 사람은 두 칸만 확인한다.
만드는 것은 신탁(oracle)이 아니라 **큐(queue)**다. 답을 내려주는 시스템이 아니라, 사람이 확인해야 할 것만 골라 쌓아두는 시스템이다.
보고하는 숫자가 다르다
여기서 대부분의 엔지니어가 실수한다. 임원 보고에 정확도를 들고 간다.
정확도는 당신의 지표다. 예산을 승인하는 사람의 지표는 다르다.
| 무엇을 | 왜 |
|---|---|
| 건당 처리 시간 (전/후) | 예산이 갱신되는 근거는 이 숫자다 |
| 검토 큐 길이 | 큐가 길어지면 사람이 익사하고 있다는 뜻이다 |
| 사람 개입 비율의 추이 | 시스템이 배우고 있는지 보여준다 |
정확도가 94%에서 96%로 올라간 것은 회의실에서 아무 의미가 없다. 건당 11분이 4분이 됐다는 것은 의미가 있다.
전체 구조를 한 표로 정리하면 이렇다.
| 단계 | 하는 일 | 흔한 실수 |
|---|---|---|
| 착수 전 | 팀 옆에 이틀 앉기 · 진짜 프로세스 파악 · 가장 반복되는 한 단계 선택 | 위키 문서를 요구사항으로 받아 바로 설계 |
| 만드는 것 | 필드 추출 · 필드 단위 신뢰도 분기 · 사람 검토 큐 | 판단까지 자동화하고 정확도로 방어 |
| 보고하는 것 | 건당 처리 시간 · 큐 길이 · 개입 비율 추이 | 모델 정확도와 벤치마크 점수 보고 |
이 표의 첫 줄과 셋째 줄이 이 직무에 주니어 자리가 없는 이유다. 코드는 절반이다.
94%가 왜 나쁜 점수인가
한 번의 정확도와 스무 번의 신뢰도는 다른 숫자다.
Sierra는 τ-bench 벤치마크 글에서 이 구분을 pass^k라는 지표로 정리했다. 흔히 쓰는 pass@k는 "k번 시도해서 한 번이라도 성공하는가"를 본다. pass^k는 반대다. **"같은 작업을 k번 시켰을 때 k번 다 성공하는가"**를 본다.
고객 응대나 서류 처리처럼 같은 일이 매일 반복되는 업무에서는 후자가 유일하게 의미 있는 숫자다. 고객 여덟 명이 같은 문제로 문의했을 때, 여덟 번 다 제대로 처리해야 한다.
τ-bench 결과에서 GPT-4o는 pass^1 기준 평균 50%를 밑돌았고, τ-retail 도메인의 pass^8에서는 약 25%까지 떨어졌다. Sierra는 이를 pass^1 대비 60%에 가까운 하락으로 표현했다. 테스트한 12개 모델 전부에서 k가 커질수록 성능이 무너졌다.
(이 벤치마크는 2024년 것이고 모델은 그 사이 크게 좋아졌다. 하지만 바뀐 것은 곡선의 높이이지 모양이 아니다.)
계산은 단순하다. 회당 성공률이 p일 때 k번 연속 성공할 확률은 p의 k제곱이다.
| 반복 횟수 k | 회당 94% | 회당 99.8% |
|---|---|---|
| 1 | 94.0% | 99.8% |
| 5 | 73.4% | 99.0% |
| 10 | 53.9% | 98.0% |
| 16 | 37.2% | 96.8% |
| 20 | 29.0% | 96.1% |
회당 94%짜리 시스템은 스무 건 연속 처리에서 열에 세 번만 무사하다. 데모에서는 완벽해 보이고, 운영 2주차에 신뢰를 잃는 이유가 여기 있다.
결론은 하나다. 모델을 스무 번 연속 맞히게 만들 수 없다면, 스무 번 중 틀릴 지점을 사람에게 넘기는 구조를 만들어야 한다. 이게 FDE가 신탁 대신 큐를 만드는 이유다.
FDE의 도구 상자
여기서부터는 실제로 손에 쥐어야 하는 것들이다.
1. 스코핑 — 만들기 전에 거르는 다섯 질문
Ramp의 엔지니어링 디렉터 Leo Mehr는 FDE 조직을 두 문장으로 요약한다. "항상 스코핑하라(Always be scoping)", 그리고 "토큰으로 확장하라(Scale with tokens)".
첫 번째가 왜 필요한지 보여주는 사례가 있다. Ramp는 어느 고객사 요청으로 FDE 두 명을 붙여 모바일 경비 정산 기능을 iOS와 Android 양쪽에 새로 만들었다. 개발이 끝난 뒤에야 고객사가 전사적으로 iOS 기기만 지급한다는 사실이 드러났다. Android 작업 전체가 버려졌다.
FDE는 요청을 접수하는 창구가 아니다. 만들기 전에 다섯 가지를 묻는다.
- 이걸 정말 원하는 게 누구인가? 고객인가, 아니면 이번 분기 할당량을 채워야 하는 영업 담당자인가
- 실제로 쓸 사람은 누구인가? 요청한 사람과 쓸 사람이 같은가
- 이미 있는 우회 방법이나 API로 해결되지 않나?
- 다른 고객사도 같은 걸 필요로 하나? 아니면 이 한 곳만인가
- 고객사 개발팀이 우리 API로 직접 붙을 수는 없나?
두 번째 문장 — 토큰으로 확장하라 — 는 이 스코핑 자체를 에이전트에게 넘기라는 뜻이다. Ramp는 사내 Slack 채널에 올라오는 FDE 요청을 가로채는 Notion 기반 에이전트를 만들었다. 요청자에게 여러 차례 되물어가며 빈칸을 채우고, 충분히 구체화됐다고 판단되면 스펙 문서를 생성한다. 도입 몇 주 만에 수동 스코핑 시간의 약 20%를 줄였고, 응답 지연은 몇 시간~며칠에서 몇 초로 줄었다.
Mehr는 두 문장 중 하나만 하는 조직을 경고한다. 스코핑 없이 자동화만 하면 "토큰 맥싱 슬롭 캐넌(token maxing slop cannon)" — 토큰을 최대로 태워 쓰레기를 대량 생산하는 기계 — 가 된다. 반대로 스코핑만 잘하고 자동화를 안 하면 에이전트 네이티브 경쟁사에 밀린다.
바로 쓸 수 있는 스코핑 에이전트 프롬프트다. 사내 요청 채널에 붙여두면 된다.
너는 FDE 팀의 요청 스코핑 담당이다. 요청을 받으면 바로 스펙을 쓰지 말고,
아래 다섯 항목이 모두 채워질 때까지 한 번에 두 개씩만 질문해라.
1. 최종 사용자 — 실제로 이 기능을 매일 열어볼 사람의 직무와 인원수
2. 현재 방법 — 지금은 이 일을 어떻게 하고 있는지, 걸리는 시간
3. 기존 해결책 — 우리 제품의 기존 기능·API·설정으로 안 되는 이유
4. 일반성 — 다른 고객사·다른 팀도 같은 요청을 한 적이 있는지
5. 성공 조건 — 무엇이 달라지면 이 요청이 해결된 것으로 볼지 (숫자로)
규칙:
- 요청자가 "그냥 만들어달라"고 하면, 위 다섯 개 중 빠진 것을 다시 물어라
- 3번에서 기존 기능으로 해결 가능하면, 스펙 대신 그 방법을 안내하고 종료해라
- 다섯 개가 다 차면 한 장짜리 스펙(대상 업무 / 범위 밖 / 성공 조건 / 예외)을 써라
- 추측으로 빈칸을 채우지 마라. 모르면 모른다고 적어라
2. 툴 설계 — 에이전트가 쓸 도구를 쓰는 법
FDE가 만드는 것의 상당 부분은 에이전트가 호출할 도구다. 여기에 대해 Anthropic이 Writing tools for agents에 정리한 원칙이 현재로선 가장 실용적이다.
| 원칙 | 구체적으로 | 근거 수치 |
|---|---|---|
| 네임스페이싱 | 관련 도구를 공통 접두어로 묶는다 (asana_search, jira_search) |
접두어 방식과 접미어 방식만 바꿔도 평가 결과가 달라진다 |
| 의미 있는 식별자 | uuid·mime_type 대신 name·file_type을 반환한다 |
UUID를 의미 있는 문자열이나 0부터 시작하는 인덱스로 바꾸면 검색 정확도가 뚜렷이 올라간다 |
| 응답 상세도 제어 | response_format에 concise/detailed enum을 둔다 |
Slack 예시에서 concise가 72토큰, detailed가 206토큰 |
| 토큰 예산 | 페이지네이션·범위 선택·필터·잘라내기를 기본값으로 넣는다 | Claude Code는 도구 응답을 기본 25,000토큰으로 제한한다 |
| 잘렸을 때의 안내 | 에러 코드 대신 "무엇을 어떻게 좁혀서 다시 호출하라"를 문장으로 반환한다 | — |
| 도구 통합 | list_users+list_events+create_event 대신 schedule_event 하나 |
read_logs 대신 search_logs로 필요한 줄만 |
| 설명문을 프롬프트로 취급 | 새로 온 팀원에게 설명하듯 쓴다. 암묵적 맥락을 명시한다 | 설명문 정제만으로 SWE-bench Verified 성적이 크게 개선된 사례 |
| 평가 루프 | 도구 호출이 수십 번 필요한 현실적 과제로 평가셋을 만든다 | 총 실행시간·호출 횟수·토큰 소비를 함께 측정 |
가장 자주 어기는 것은 두 번째다. 내부 시스템의 기본 키를 그대로 반환하면 에이전트는 그 값으로 아무 판단도 못 한다. CLM-2026-0841이 a3f8...보다 낫고, 홍길동 청구 건이 그보다 낫다.
그리고 마지막 원칙 — 기존 API를 그대로 감싼 도구를 대량으로 만들지 말 것. 도구가 많으면 에이전트는 효율적인 경로를 잃는다.
3. MCP 서버 — 30분이면 하나 만든다
MCP는 공고 언급 비율이 8.0%에서 13.0%로 오른 유일한 항목이다. 직접 하나 만들어보는 게 이해가 빠르다. 공식 튜토리얼 기준이다.
# uv 설치 (macOS/Linux)
curl -LsSf https://astral.sh/uv/install.sh | sh
# 프로젝트 생성
uv init weather
cd weather
uv venv
source .venv/bin/activate
uv add "mcp[cli]"
touch weather.py
서버 본체는 이 정도다. 타입 힌트와 독스트링에서 도구 정의가 자동으로 만들어진다.
from typing import Any
import httpx2
from mcp.server import MCPServer
mcp = MCPServer("weather")
NWS_API_BASE = "https://api.weather.gov"
USER_AGENT = "weather-app/1.0"
@mcp.tool()
async def get_alerts(state: str) -> str:
"""Get weather alerts for a US state.
Args:
state: Two-letter US state code (e.g. CA, NY)
"""
url = f"{NWS_API_BASE}/alerts/active/area/{state}"
data = await make_nws_request(url)
if not data or "features" not in data:
return "Unable to fetch alerts or no alerts found."
if not data["features"]:
return "No active alerts for this state."
return "\n---\n".join(format_alert(f) for f in data["features"])
if __name__ == "__main__":
mcp.run(transport="stdio")
실행은 uv run weather.py. Claude Desktop에 붙이려면 ~/Library/Application Support/Claude/claude_desktop_config.json에 다음을 넣는다.
{
"mcpServers": {
"weather": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/PARENT/FOLDER/weather",
"run",
"weather.py"
]
}
}
}
command에는 which uv로 확인한 전체 경로를 넣어야 하는 경우가 많다.
앞 절의 원칙은 여기서 그대로 적용된다. 독스트링이 곧 도구 설명문이고, 반환하는 문자열이 곧 에이전트의 컨텍스트다. 이 두 개를 대충 쓰면 나머지를 아무리 잘 만들어도 성능이 나오지 않는다.
4. 코드 실행 — 컨텍스트 150,000토큰을 2,000토큰으로
MCP 서버를 여러 개 붙이기 시작하면 곧 벽에 부딪힌다. 대부분의 MCP 클라이언트는 모든 도구 정의를 미리 컨텍스트에 올린다. 요청을 읽기도 전에 수십만 토큰을 소비하는 상황이 생긴다. 게다가 중간 결과가 모델 컨텍스트를 몇 번씩 왕복한다. 회의록을 Drive에서 받아 Salesforce에 쓰면 같은 문서가 두 번 컨텍스트를 지나간다.
Anthropic이 Code execution with MCP에서 제안한 해법은 도구를 함수 호출로 노출하지 않고 파일 시스템 위의 TypeScript 모듈로 노출하는 것이다.
servers/
├── google-drive/
│ ├── getDocument.ts
│ └── index.ts
├── salesforce/
│ ├── updateRecord.ts
│ └── index.ts
에이전트는 필요한 모듈만 읽고 코드를 쓴다.
import * as gdrive from './servers/google-drive';
import * as salesforce from './servers/salesforce';
const transcript = (await gdrive.getDocument({
documentId: 'abc123'
})).content;
await salesforce.updateRecord({
objectType: 'SalesMeeting',
recordId: '00Q5f000001abcXYZ',
data: { Notes: transcript }
});
이 Drive → Salesforce 흐름에서 토큰 소비는 150,000에서 2,000으로, 98.7% 줄었다.
FDE에게 중요한 이유는 절감액이 아니라 네 가지 부수 효과다.
- 점진적 공개 — 도구 정의를 미리 다 올리지 않고 필요할 때 파일을 열어 읽는다
- 컨텍스트 효율적 필터링 — 1만 행짜리 스프레드시트를 통째로 컨텍스트에 넣지 않고, 코드에서 걸러 다섯 행만 본다
- 개인정보 보호 — 중간 결과가 기본적으로 실행 환경 안에 머문다. 클라이언트가 개인식별정보를 토큰화하면 원본이 모델에 닿지 않은 채로 시스템 사이를 흐른다
- 상태 지속과 스킬화 — 결과를 파일로 남겨 중단·재개가 가능하고, 잘 통하는 코드 패턴은 함수로 저장해 다음 작업에서 재사용한다
세 번째는 규제 산업 현장에서 특히 크다. 대가는 샌드박싱·리소스 제한·모니터링이라는 운영 부담이다. 붙이기 전에 그만한 값을 하는지 따져야 한다.
5. 온톨로지 — 업무를 객체와 액션으로
마지막은 이 직무의 원류인 Palantir의 개념이다. Ontology system 문서에 정리돼 있다.
온톨로지는 흩어진 데이터를 비즈니스 개념 단위의 객체와, 그 객체에 가하는 액션으로 모델링하는 층이다. 명사(데이터 객체)와 동사(액션)를 짝지어 업무를 실행 가능한 형태로 만든다. 문서는 이를 세 덩어리로 설명한다.
| 구성 | 역할 |
|---|---|
| Language | 객체·링크·속성, 그리고 액션과 자동화의 로직을 정의한다 |
| Engine | 읽기(SQL 질의·실시간 구독)와 쓰기(트랜잭션·배치·스트림·CDC)를 실제로 수행한다 |
| Toolchain | 온톨로지를 백엔드로 쓰게 해주는 SDK(OSDK)와 운영 거버넌스 도구 |
그리고 이 층은 네 가지를 한 번에 묶는다. 데이터(흩어진 소스를 객체·속성·링크로 통합), 로직(비즈니스 규칙부터 ML 모델과 LLM 함수까지), 액션(단순 트랜잭션부터 원 시스템으로 되돌려 쓰는 다단계 갱신까지), 보안(데이터 접근·로직 실행·액션 트리거에 걸리는 세분화된 권한).
FDE 관점에서 왜 중요한가. 앞서 만든 도구들이 안정적으로 동작하려면 "청구 건", "담당자", "승인"이 무엇인지 조직 안에서 하나로 합의돼 있어야 한다. 이 합의가 없으면 도구는 매 부서마다 다시 만들어야 하고, 에이전트는 부서마다 다른 뜻의 같은 단어를 받는다.
같은 문제를 다른 각도에서 다룬 글이 우리 회사는 같은 단어를 같은 뜻으로 쓰고 있는가다.
왜 주니어가 없나
이제 처음 숫자로 돌아간다. 공고 118건에 주니어 자리가 0건인 이유는 기술 난도가 아니다.
이 직무의 결정 대부분은 무엇을 만들지 않을 것인가에 관한 것이다.
- 이틀 앉아 있다가 자동화할 한 단계를 고르는 것
- 정확도를 99.8%까지 올리려는 시도를 포기하고 큐를 만들기로 하는 것
- 영업 담당자의 요청을 스펙 대신 기존 API 안내로 닫는 것
- 임원 보고에서 정확도 대신 건당 처리 시간을 꺼내는 것
전부 만들지 않기로 하는 결정이다. 그리고 이런 판단은 코드 리뷰로 가르치기 어렵다. 그래서 공고는 경력자만 찾는다.
들어가려는 사람에게 가장 확실한 증명 방법은 셋이다.
- 업무 하나를 끝까지 통과시킨 사례. 자신이 아는 반복 업무 하나를 골라 MCP 서버 + 신뢰도 분기 + 검토 큐까지 만들고, 도입 전후의 건당 처리 시간을 측정해 남긴다
- pass^k 리포트. 자기가 만든 에이전트를 같은 작업으로 20회 돌려 pass^1과 pass^20을 나란히 적는다. 이 숫자를 스스로 측정해 본 사람은 아직 드물다
- 스코핑 문서. 요청 하나를 앞의 다섯 질문으로 분해해 "만들지 않기로 한 이유"를 적은 한 장
세 번째가 가장 어렵고, 면접에서 가장 잘 먹힌다.
정리하며
FDE는 사업부 안에 들어가 손으로 하던 일을 자동화된 일로 바꾸는 사람이고, 그 일의 절반은 코드가 아니다.
94%짜리 모델을 운영에 올리는 방법은 정확도를 올리는 것이 아니라, 틀릴 6%를 사람에게 넘기는 구조를 설계하는 것이다. 신탁이 아니라 큐를 만드는 것. 그리고 그 결과를 정확도가 아니라 건당 처리 시간으로 보고하는 것.
이 두 가지를 할 줄 아는 사람이 시장에 부족해서 공고가 4.2배로 늘었다.
AX LABS는 국내 대기업을 대상으로 AX 컨설팅과 AI 에이전트 개발·실무 교육을 수행하고 있습니다. 현업 업무 하나를 골라 자동화 구조를 함께 설계하고 싶다면 문의하기 →, 이 직무로 일하고 싶다면 Forward Deployed Engineer 채용 공고 →
참고
- Kevin Bai(Anthropic, ex-Palantir), Forward Deployed Engineering 101: https://www.youtube.com/watch?v=KwhgfwOSToQ
- Leo Mehr(Ramp), How Forward Deployed Engineering is done at Ramp: https://www.youtube.com/watch?v=ITMXwI6QL6A
- Sierra, Benchmarking AI agents (pass^k · τ-bench): https://sierra.ai/blog/benchmarking-ai-agents
- Anthropic, Writing tools for agents: https://www.anthropic.com/engineering/writing-tools-for-agents
- Anthropic, Code execution with MCP: https://www.anthropic.com/engineering/code-execution-with-mcp
- Model Context Protocol, Build an MCP server: https://modelcontextprotocol.io/docs/develop/build-server
- Palantir, Ontology system architecture: https://www.palantir.com/docs/foundry/architecture-center/ontology-system
