AI Forward Deployed Engineer Course: 채용공고 22개로 짠 35주 FDE 역량 지도
Substack 'Becoming Forward Deployed Engineer'가 실제 채용공고 22개에서 요건을 뽑아 AI FDE 강좌 35개 포스트를 9단계 35주로 배열한 커리큘럼 지도를 공개했습니다. 역량이 쌓이는 일곱 층으로 묶어 풀고 사내 14주 압축 트랙과 채용·역량 평가 루브릭으로 바꾸는 방법을 붙였습니다.
AI FDE(forward deployed engineer, 고객 현장에 들어가 AI 시스템을 운영까지 만들어 내는 엔지니어)에게 필요한 역량은 프로덕션 코드 위에 LLM·RAG·에이전트, 평가, 엔터프라이즈 통합, 고객 발견, 규제 도메인이 차례로 쌓이는 구조입니다. 이 지도는 그 순서를 채용공고 22개에서 뽑아 35주로 짰습니다. 사내 FDE를 키우려면 층 순서는 지키고 기간은 12~16주로 줄이되, 단계마다 산출물로 통과를 판정해야 합니다.
요약
Substack 뉴스레터 ‘Becoming Forward Deployed Engineer’가 2026년 9월 26일 올린(10월 23일 수정) 이 글은 강의 본문이 아니라 강좌 전체의 목차입니다. 저자는 실명을 밝히지 않았습니다. AI FDE가 되는 데 필요한 기술을 35개 포스트로 나누고 포스트마다 무엇을 만들고 어떤 기술을 쓰는지 한두 줄씩 적었습니다. 포스트를 고른 기준은 실제 채용공고 22개입니다. Palantir, OpenAI, Anthropic, Databricks, Harvey, Cohere, Mistral, Salesforce, ElevenLabs, Smartsheet, Traversal, Cresta의 공고에 나온 요건을 9개 Phase로 묶었고 Phase마다 3~5주를 배정해 35주 일정을 만들었습니다. 개념 설명은 각 포스트에 맡기고 이 글은 스킬 이름과 만들 결과물만 담습니다. 저자는 이 지도를 진도 추적과 채용 요건 대응에 쓰는 중앙 색인으로 둡니다.
지도에서 읽히는 것은 FDE 역량이 쌓이는 순서입니다. 프로덕션 Python으로 기반을 다진 다음 LLM 이해에서 RAG를 거쳐 에이전트로 올라가고, 그 결과를 재는 평가·관측을 붙입니다. 그다음 SSO와 사내 시스템 연결, 클라우드 인프라로 고객 환경에 넣는 법을 배웁니다. 고객 발견·문제 분해·기술 문서화는 따로 한 단계로 둡니다. 마지막으로 법률·의료·금융·정부 도메인의 규제를 익히고 capstone 네 개로 포트폴리오를 만듭니다. 저자는 순서를 지키라고 강조합니다. ‘Later phases import code from earlier ones.‘라는 설명처럼 앞에서 만든 코드를 뒤에서 그대로 가져다 쓰기 때문입니다. 아래에서는 35개 포스트를 하나씩 옮기지 않고 일곱 층으로 묶어 설명한 뒤, 사내 14주 압축 트랙과 평가 루브릭으로 바꾸는 방법을 붙였습니다.
핵심 메커니즘
Job-Posting-Driven Curriculum: 채용공고에서 거꾸로 짠 누적형 커리큘럼
커리큘럼의 주제를 유행하는 도구가 아니라 채용공고의 요건에서 거꾸로 뽑은 설계입니다. 입력은 12개 회사의 공고 22개입니다. 공고마다 되풀이되는 요건(강한 Python, RAG 설계, 에이전트·MCP, 평가, 엔터프라이즈 통합, 고객 대면, 규제 산업 경험)을 Phase로 묶고 Phase마다 그 요건을 낸 회사 이름을 붙입니다. 출력은 진도표이자 요건 대응표 역할을 하는 지도입니다. 저자는 인기 때문에 넣은 주제는 없고 모두 공고에 나왔기 때문에 넣었다고 밝힙니다.
두 번째 특징은 누적입니다. 앞 포스트의 산출물이 뒤 포스트의 부품이 됩니다. Phase 1에서 만든 retry decorator(실패한 호출을 정해진 규칙으로 다시 시도하는 함수 감싸개)를 Phase 4 에이전트가 쓰고 Phase 1의 Pydantic 모델(데이터 형식을 코드로 정의하고 검증하는 클래스)을 Phase 3 RAG 파이프라인이 씁니다. 직무 정의가 아직 흐릿한 역할을 교육으로 만들 때 잘 맞는 방식입니다. 공고가 거의 없는 사내 고유 역할이라면 공고 대신 직무 기술서와 프로젝트 회고에서 요건을 뽑아야 합니다. 가상 예시로 AX 추진 조직이 국내외 FDE 공고 15개와 사내 프로젝트 회고 5건을 같은 표에 넣어 보면 이 지도의 9개 Phase 가운데 우리 조직에 없는 요건(예: 미국 연방 규제)과 새로 필요한 요건(예: 망분리 배포)이 바로 드러납니다.
Production Foundation: 장애에 버티는 코드부터 (Phase 1, 1~3주)
FDE의 첫 층은 모델이 아니라 실패해도 원인을 추적할 수 있는 코드입니다. 원문 P1은 타입이 정해진 파이프라인, retry decorator, 구조화 로거를 만들며 테스트 36개와 커버리지 92%를 결과물로 둡니다. 도구는 Pydantic v2, pytest, correlation ID(한 요청이 여러 단계를 거쳐도 같은 번호로 묶어 추적하는 식별자)가 붙은 JSON 로깅, jitter(재시도 간격에 넣는 무작위 흔들림)를 넣은 exponential backoff입니다. P2는 여러 외부 API를 비동기로 동시에 부르되 semaphore와 rate limit으로 상대 서버에 부담을 주지 않게 합니다. P3은 SQL의 window function·CTE와 Parquet으로 AI가 읽을 데이터 파이프라인을 만듭니다.
이 층이 맨 아래에 있는 이유는 Phase 2부터의 모든 시스템이 외부 모델 API를 부르기 때문입니다. 호출은 실패하거나 느려집니다. 형식이 틀린 답이 돌아오기도 합니다. 타입 검증과 재시도와 로그가 없으면 RAG나 에이전트에서 생긴 오류가 모델 탓인지 코드 탓인지 가를 수 없습니다. 이미 백엔드 경력이 있는 개발자라면 이 층은 사전 테스트로 확인만 하고 넘어가도 됩니다.
Model Stack: LLM에서 RAG, 에이전트로 (Phase 24, 416주)
13주를 차지하는 가장 두꺼운 층입니다. Phase 2는 모델 작동 원리(BPE tokenizer, attention, RLHF)와 GPT-4o·Claude 3.7·Mistral·Llama 3 비교에서 출발합니다. 이어 스트리밍과 tool use, 공급자가 실패하면 다른 공급자로 넘기는 fallback을 갖춘 멀티 공급자 client를 만들고, CoT 템플릿과 prompt injection 탐지, QLoRA 파인튜닝까지 다룹니다.
Phase 3 RAG는 저자가 가장 수요가 큰 AI 엔지니어링 스킬로 꼽은 단계입니다. chunking 4종과 임베딩 3종을 비교하고 벡터 DB 어댑터로 지연과 recall을 잰 뒤, BM25와 dense 검색을 섞는 하이브리드 검색과 reranker, multi-hop을 얹고 RAGAS 평가를 CI/CD 품질 게이트로 묶습니다. Phase 4는 ReAct 에이전트에서 LangGraph 상태 그래프(human-in-the-loop checkpoint 포함), CrewAI 멀티에이전트 팀, MCP server로 넓힌 다음 circuit breaker·DLQ·감사 로그 같은 장치로 운영에 버티게 굳힙니다. 검색이 붙지 않은 에이전트도, 평가가 붙지 않은 검색도 운영에 올리지 않게 짠 순서입니다.
Evaluation & Observability: 만든 것을 재고 지켜보는 층 (Phase 5, 17~19주)
평가를 RAG 안의 한 포스트로 끝내지 않고 독립된 Phase로 세운 것이 이 지도의 특징입니다. P17은 5개 지표로 평가하고 CI/CD 게이트에 연결합니다. offline eval(배포 전 고정된 데이터셋으로 재는 평가)과 online eval(운영 중 실제 트래픽으로 재는 평가)을 나누고 golden dataset(기대 답이 정해진 사례 묶음)으로 회귀 테스트를 돌립니다. P18 LLM-as-Judge는 모델이 다른 모델의 답을 채점하게 하되 judge calibration(사람 판정과 맞는지 보정)과 편향 완화를 함께 다루고 pairwise(두 답 비교)와 pointwise(하나씩 채점)를 구분합니다.
P19는 운영 관측입니다. LangSmith로 요청마다 trace span을 남기고 Guardrails AI와 NeMo Guardrails로 답이 정해진 주제를 벗어나지 않게 막으며, Grafana로 지표를 보며 drift(입력이나 답의 분포가 서서히 바뀌는 현상)가 생기면 알림을 겁니다. FDE가 고객과 품질 기준을 숫자로 합의할 때 쓰는 도구가 이 층에서 나옵니다.
Enterprise Integration: 고객사 시스템 안으로 들어가는 층 (Phase 6, 20~24주)
모델과 평가가 갖춰져도 고객사 환경에 들어가지 못하면 배포가 아닙니다. Phase 6은 그 입구를 다섯 갈래로 다룹니다. P20은 SAML 2.0·OIDC 로그인과 RBAC(역할별 접근 권한)를 붙이고, P21은 Salesforce·SharePoint·iManage 어댑터를 만들며 idempotency(같은 요청을 두 번 보내도 결과가 한 번만 반영되는 성질)를 지킵니다. P22는 Snowflake·dbt·Airflow로 데이터 스택을 잇습니다. P23·P24는 Docker·Kubernetes와 Terraform으로 배포와 인프라를 코드로 만듭니다.
이 층의 도구 이름은 미국 기업 환경을 기준으로 합니다. 한국 기업에서는 갈래는 그대로 두고 도구만 바꿔 끼우면 됩니다. 로그인은 그룹 SSO, 업무 시스템은 ERP와 그룹웨어, 데이터는 사내 데이터 레이크가 그 자리에 들어갑니다(아래 기술 디테일의 대응표 참고).
Customer Discovery & Problem Decomposition: 무엇을 만들지 정하는 층 (Phase 7, 25~27주)
저자가 기술 강의가 가르치지 않는 스킬이라고 따로 표시한 단계입니다. 요건을 낸 회사는 Palantir, Anthropic, Harvey, Cresta이며 공고의 표현은 고객 대면, 문제 분해, radical ownership(결과까지 끝까지 책임지는 태도)입니다. P25는 discovery 세션 템플릿과 stakeholder mapping 도구를 만듭니다. SPIN(상황·문제·영향·필요 순으로 묻는 질문법)과 5-Whys로 요건을 뽑고 실무자부터 CTO까지 이해관계자 지도를 그립니다.
P26 FDE Problem Decomposition Framework는 분해 워크시트, KPI 정의 프레임워크, workstream planner를 만들고 ambiguity mapping(모호한 부분을 따로 표시해 쪼개기)과 MVP scoping을 연습하고 FDE 채용 면접의 decomposition interview에 대비합니다. P27은 ADR 생성기, runbook scaffold, handoff playbook 템플릿을 만듭니다. FDE는 고객 현장을 떠나는 사람이므로, 남이 운영할 수 있게 넘기는 문서가 결과물의 일부가 됩니다.
Regulated Domain & Capstone Arc: 규제 안에서 끝까지 만들어 보는 층 (Phase 89, 2835주)
Phase 8은 Anthropic Federal과 Cohere Sovereign 공고에 나온 HIPAA, FedRAMP, 규제 산업 경험 요건에서 왔습니다. P28은 SOC 2 Type II, HIPAA 기술적 보호조치, FedRAMP ATO, GDPR, EU AI Act를 묶어 감사 로그와 컴플라이언스 체크리스트 생성기를 만듭니다. P29~P31은 도메인별입니다. 법률에서는 ethical wall(이해 충돌이 있는 사건 정보를 막는 벽)과 matter 단위 RBAC가 있는 RAG를, 의료에서는 Presidio로 PHI를 비식별하고 FHIR R4를 다룹니다. 금융·정부에서는 SR 11-7 모델 리스크 문서, NIST 800-53 체크리스트, air-gapped 배포 설정을 만듭니다.
Phase 9의 capstone 네 개는 모두 같은 흐름을 따릅니다. discovery → architecture → implementation → compliance package → handoff playbook입니다. 도메인은 법률(AmLaw 100), HIPAA 의료, 금융 멀티에이전트, air-gapped 정부 LLM으로 바뀌지만 다섯 단계는 같습니다. 앞의 여덟 Phase가 이 흐름의 각 칸에 하나씩 들어간다고 보면 지도 전체가 한눈에 들어옵니다. discovery는 Phase 7, architecture와 implementation은 Phase 1~6, compliance package는 Phase 8, handoff playbook은 다시 Phase 7의 문서화에서 옵니다.
통념과 다른 주장
흔히 이렇게 봅니다AI 엔지니어 교육은 지금 많이 쓰는 도구와 프레임워크를 따라가면 된다.
저자는 이렇게 봅니다인기 있어서 넣은 주제는 없다. 실제 채용공고에 요건으로 나온 것만 넣었다.
근거35개 포스트를 12개 회사의 공고 22개에서 설계했고 Phase마다 그 요건을 낸 회사를 적어 두었습니다.
흔히 이렇게 봅니다FDE 역량은 기술 스택의 폭과 깊이로 정해진다.
저자는 이렇게 봅니다고객 발견, 문제 분해, 기술 문서화는 기술 강의가 가르치지 않지만 공고가 요구하는 별도 역량이다.
근거Palantir, Anthropic, Harvey, Cresta 공고의 고객 대면·문제 분해 요건으로 Phase 7을 따로 세웠습니다. capstone 네 개는 모두 discovery로 시작해 handoff playbook으로 끝납니다.
흔히 이렇게 봅니다강좌는 필요한 주제만 골라 들어도 된다.
저자는 이렇게 봅니다순서대로 만들어야 한다. 뒤 단계가 앞 단계의 코드를 가져다 쓴다.
근거Phase 1의 retry decorator가 Phase 4 에이전트에, Phase 1의 Pydantic 모델이 Phase 3 RAG에 다시 쓰입니다.
저자가 든 사례
이 글은 커리큘럼 지도라 기업 사례 대신 커리큘럼 안의 예를 듭니다. 두 가지를 사례 틀로 다시 짰습니다.
앞 코드를 뒤에서 재사용하는 두 예
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 포스트 35개를 따로 배우면 같은 기능을 매번 새로 만든다 | Phase 1의 retry decorator를 Phase 4 에이전트에, Pydantic 모델을 Phase 3 RAG에 그대로 씀 | 뒤 단계가 앞 코드를 import하도록 설계. 효과 수치는 원문에서 밝히지 않음 | Job-Posting-Driven Curriculum의 누적, Production Foundation |
capstone 네 개: 같은 다섯 단계, 다른 규제
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 앞 31개 포스트의 기술을 실제 배포 형태로 묶어 보여 줄 포트폴리오가 필요 | 법률(AmLaw 100), HIPAA 의료, 금융 멀티에이전트(SR 11-7, SOC 2 증빙, PrivateLink), air-gapped 정부 LLM(Ollama, FedRAMP, 정부 RAG, CIO 브리핑 시뮬레이션) 네 과제를 같은 흐름으로 수행 | 과제마다 compliance package와 handoff playbook까지 남김. 수강 결과 수치는 원문에서 밝히지 않음 | Regulated Domain & Capstone Arc, Customer Discovery & Problem Decomposition |
기술 디테일: 사내 트랙을 실제로 돌리려면
누적형 커리큘럼을 그대로 살리려면 starter repo 하나를 1주차에 만들고 모든 과제를 그 위에서 하게 합니다(Job-Posting-Driven Curriculum, Production Foundation). 뒤 단계 과제는 앞 폴더를 import해야 통과로 칩니다. 같은 기능을 새로 짜면 리뷰에서 돌려보냅니다. 가상 설정으로 core/retry는 최대 5회, 시작 간격 0.5초, 최대 30초, full jitter를 기본값으로 둡니다. core/logger는 모든 로그에 ts, level, correlation_id, step, model, latency_ms, tokens_in, tokens_out, cost_usd를 남깁니다. 이 아홉 필드가 있으면 Phase 5의 trace와 비용 집계를 따로 만들 필요가 없습니다.
fde-track/
core/ retry · logger · schemas(Pydantic v2) ← P1
ingest/ async 수집(semaphore, rate limit) · SQL → Parquet ← P2~3
llm/ 멀티 공급자 client · fallback · 구조화 출력 ← P5
rag/ chunker · retriever · reranker ← P8~11
agents/ tool schema · graph · MCP server · breaker ← P12~16
evals/ golden set · judge · CI 게이트 ← P17~19
docs/ ADR · runbook · handoff playbook ← P27
RAG를 숫자로 비교할 수 있는 기준선으로 돌리려면 설정을 처음부터 고정해 둡니다(Model Stack). 가상 설정으로 chunking 4종은 고정 길이(512 token, 겹침 64), 문단 단위, 제목 계층 단위, 의미 단위로 두고 임베딩 3종과 곱해 12개 조합을 같은 질문 100개로 잽니다. 하이브리드 검색은 BM25 top-50과 dense top-50을 RRF로 합친 뒤 cross-encoder로 다시 순위를 매겨 top-5만 모델에 넣습니다. 한국어 사내 문서에서 자주 깨지는 곳은 표와 스캔 PDF 파싱, 그리고 사내 약어입니다. 파싱 실패율이 5%를 넘으면 파서를 바꾸고 약어는 동의어 사전을 BM25 쪽에 넣어 해결합니다.
평가 게이트를 CI에 넣으려면 golden dataset을 사람이 먼저 만듭니다(Evaluation & Observability). 가상 예시로 150건을 실제 질문 100건, 경계 사례 30건, prompt injection 시도 20건으로 나눕니다. 원문 P17처럼 지표는 5개로 묶습니다. 예를 들면 정답 일치, faithfulness, recall@5, 지연 p95, 건당 비용입니다. LLM-as-Judge는 사람이 판정한 50건과 일치율이 80%를 넘을 때만 씁니다. temperature 0으로 같은 사례를 3회 채점해 점수 편차가 1점을 넘는 사례는 사람에게 돌립니다. pairwise 비교는 두 답의 순서를 바꿔 두 번 돌려 위치 편향을 걷어 냅니다. judge 출력은 아래처럼 JSON으로 받습니다.
{
"case_id": "HR-0412",
"verdict": "fail",
"score": 2,
"criteria": { "faithfulness": 1, "completeness": 3 },
"evidence_chunk_ids": ["doc17#c3"],
"judge_model": "<사내 표준 모델>",
"run": 2
}
에이전트를 운영에 버티게 하려면 원문 P16의 다섯 장치를 설정값까지 정합니다(Model Stack). 가상 설정으로 circuit breaker(실패가 몰리면 한동안 호출을 끊어 장애가 번지지 않게 하는 장치)는 60초 안에 5회 실패하면 30초간 열고 그 뒤 시험 호출 1건이 성공하면 닫습니다. 막힌 동안의 작업은 DLQ(처리에 실패한 작업을 따로 쌓아 두는 대기열)에 넣고 원인을 고친 뒤 다시 돌립니다. 쓰기 동작(메일 발송, ERP 전표 생성) 앞에는 LangGraph checkpoint로 사람 승인을 받습니다. 감사 로그에는 actor, tool, args_hash, result_status, approved_by를 남깁니다. 6~7주차 과제의 마지막 점검은 장애 주입입니다. 외부 API를 일부러 끊었을 때 에이전트가 멈추고 DLQ에 쌓이는지 봅니다.
원문의 미국 도구와 규제를 국내 환경으로 옮기려면 갈래는 남기고 도구만 바꿉니다(Enterprise Integration, Regulated Domain). SAML·OIDC 연결은 그룹 SSO(사내 IdP)에, Salesforce·SharePoint 어댑터는 ERP·그룹웨어·사내 문서관리 시스템에, HIPAA·FedRAMP·SR 11-7 체크리스트는 개인정보보호법과 업권별 규정, 사내 모델 리스크 관리 기준에 대응시킵니다. air-gapped 정부 LLM capstone은 망분리 환경에서 사내 GPU에 오픈 모델을 올리는 과제로 바꾸기 좋습니다. 어느 규정을 넣을지는 법무·보안 조직이 정하고 트랙은 체크리스트를 만드는 방법을 가르칩니다.
현업 실행 디테일: 누가, 언제, 무엇을
한국 기업의 AX 추진 조직이 사내 개발자를 FDE형 인력으로 키우거나 협력사 FDE를 평가하는 상황을 가정했습니다. 아래 역할, 일정, 숫자는 모두 예시입니다.
| 역할 | 담당 | 하는 일 |
|---|---|---|
| 트랙 오너 | AX 추진 조직 리드 1명 | 35주를 14주로 압축, 단계 게이트 판정 회의 주재 |
| 기술 멘토 | 시니어 엔지니어 2명(수강생 6~8명당) | starter repo 관리, 주 2회 코드 리뷰 |
| 현업 스폰서 | 과제를 낼 부서장 2~3명 | 실제 문제와 데이터 제공, discovery 인터뷰 대상, capstone 인수 판정 |
| 보안·법무 리뷰어 | 정보보안·법무 각 1명 | 9~11주 통합·규제 산출물 검토 |
| 인재개발 파트너 | HR 담당 1명 | 선발, 루브릭 운영, 수료 뒤 배치 |
| 수강생 | 사내 개발자 6~8명(1기) | 주 3일 트랙, 주 2일 원래 업무 |
시작 전 준비물: 사내 LLM API 접근과 1인당 월 사용 한도, 샌드박스 클라우드 계정, 익명화한 사내 문서 500건 이상(RAG 과제용), 현업 과제 후보 3~5개와 스폰서 확약, starter repo 골격, 선발용 사전 테스트(Phase 1 수준 코딩 과제 1개).
35주를 14주로 줄이는 법. 층 순서는 그대로 두고 세 가지를 줄입니다. 첫째, 이미 갖춘 역량은 사전 테스트로 면제합니다(Phase 1~3). 둘째, 같은 개념의 대안 도구는 하나만 고릅니다. 벡터 DB는 사내 표준 하나, 멀티에이전트 프레임워크는 LangGraph 하나, 인프라는 플랫폼팀 템플릿을 씁니다. 셋째, 규제 도메인은 우리 업종 하나만 깊게 봅니다. 대신 discovery는 뒤로 미루지 않고 3주차부터 현업 과제와 함께 매주 반나절씩 돌립니다. 사내 트랙은 capstone에 실제 사내 문제를 써야 하므로, 과제를 일찍 정해 두어야 12주차에 바로 착수할 수 있습니다.
| 주차 | 원문 Phase(포스트) | 압축 방식 | 산출물 | 게이트 |
|---|---|---|---|---|
| 1~2 | 1 (P1~3) | 사전 테스트 통과자는 면제 | starter repo의 core·ingest, 커버리지 80% 이상 | 멘토 코드 리뷰 |
| 3~5 | 2 | 파인튜닝(P7)은 선택 과제 | 사내 문서 RAG 기준선, 12개 조합 비교표 | recall@5 기준선 기록 |
| 6~7 | 4 (P12~16) | 프레임워크 하나, MCP·hardening은 필수 | 도구 3개 MCP server, 에이전트 | 장애 주입 테스트 통과 |
| 8 | 5 (P17~19) | 그대로 | golden 150건, judge 보정표, CI 게이트 | judge-사람 일치율 80% |
| 9~10 | 6 (P20~24) | Terraform·K8s는 플랫폼팀 템플릿 | 그룹 SSO와 사내 시스템 1개 연결 | 보안 리뷰 |
| 3~10 병행 | 7 (P25~27) | 매주 반나절 | stakeholder map, 분해 워크시트, ADR 3건 | 스폰서 승인 |
| 11 | 8 (P28~31) | 우리 업종 규정 하나 | 컴플라이언스 체크리스트, 감사 로그 설계 | 법무·보안 확인 |
| 12~14 | 9 (P32~35) | 사내 실제 과제 1개, 다섯 단계 그대로 | compliance package, handoff playbook, 시연 | 현업 인수 판정 |
12주로 더 줄일 때는 12주차를 입과 전 사전 과제로 빼고 910주차 통합을 1주로 줄입니다. 16주로 늘릴 여유가 있으면 늘어난 2주를 capstone에 붙입니다.
채용·역량 평가 루브릭(예시). 지도의 층을 그대로 평가 항목으로 씁니다. 사내 수료 판정, 경력 채용 면접, 협력사 FDE 검증에 같은 표를 씁니다.
| 역량(원문 층) | 0점 | 3점 | 5점 |
|---|---|---|---|
| 프로덕션 코드 (P1~3) | 테스트 없는 스크립트 | 타입·테스트·재시도가 있음 | 장애를 넣어도 로그로 원인을 찾음 |
| 모델 스택 (P4~16) | API 호출만 | RAG·에이전트를 만들어 돌림 | chunking·검색·도구 설계의 선택을 수치로 설명 |
| 평가·관측 (P17~19) | 눈으로 확인 | golden set으로 점수를 냄 | CI 게이트, judge 보정, drift 알림까지 |
| 엔터프라이즈 통합 (P20~24) | 로컬 데모 | 사내 SSO·시스템 하나 연결 | 권한·idempotency·배포 자동화를 설명 |
| 고객 발견·분해 (P25~26) | 요구를 그대로 받음 | 이해관계자 지도와 KPI 정의 | 모호한 요구를 나눠 MVP 범위를 스스로 자름 |
| 문서화·handoff (P27) | 코드만 남김 | README와 runbook | ADR과 handoff playbook으로 다른 팀이 운영 |
| 규제·보안 (P28~31) | 고려하지 않음 | 체크리스트 작성 | 감사 로그와 데이터 경계를 설계에 반영 |
면접·검증 질문. decomposition interview(원문 P26이 대비하는 면접)는 45분 동안 모호한 과제 하나를 줍니다. 가상 예시로 ‘영업 부서가 견적 작성이 느리다고 합니다’를 주고 다음을 봅니다. 누구에게 무엇을 먼저 묻습니까? 성공을 어떤 KPI 하나로 재겠습니까? 4주 안에 낼 MVP는 어디까지입니까? 어떤 데이터가 없으면 시작하지 않겠습니까? 운영을 넘겨받을 팀에 무엇을 남기겠습니까? 협력사 FDE에는 제안 단계에서 이전 프로젝트의 ADR, runbook, handoff playbook, eval 리포트 샘플을 요구합니다. 이 네 가지가 없는 업체는 데모까지는 해도 운영 인계에서 막힐 가능성이 큽니다.
진행 판정 기준(예시). 루브릭 35점 중 25점 이상이고 고객 발견·분해가 3점 이상이며 0점 항목이 없으면 FDE로 배치합니다. 18~24점이면 4주 보완 과제를 줍니다. 0점 항목이 있거나 현업이 capstone을 인수하지 않으면 재수강입니다. 트랙 자체는 1기 capstone 가운데 절반 이상을 현업이 인수하면 2기를 늘립니다. 그 아래면 discovery 병행 방식과 과제 선정부터 다시 봅니다.
AX 적용 제언. 이 지도가 가장 쓸모 있는 곳은 AI 시범 사업은 많은데 운영까지 끌고 갈 사람이 부족한 조직입니다. 그룹 IT 자회사, 금융사 디지털 조직, 제조 대기업의 AX 추진 조직이 그렇습니다. 사내 트랙을 처음 세울 때는 이 지도를 그대로 가르치기보다 루브릭부터 만들어 지금 인력의 빈 층을 재고 빈 층만 압축 트랙으로 채우는 순서가 빠릅니다. 대부분의 사내 개발자는 Phase 1~4는 일부 갖췄고 Phase 5, 7, 8이 비어 있을 가능성이 큽니다. 협력사 FDE를 쓸 때는 같은 루브릭을 계약 전 검증표로 쓰고 compliance package와 handoff playbook을 납품물에 넣습니다. FDE 조직이 실제로 어떻게 일하는지는 OpenAI의 FDE 운영 노트, 외부 배포 전문 회사와 계약할 때 정할 것은 DeployCo 노트를 함께 보면 됩니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 발표처 | Substack ‘Becoming Forward Deployed Engineer’, 2026.9.26 게시(10.23 수정), 저자 실명 없음 |
| 글의 성격 | 35개 포스트의 커리큘럼 지도(중앙 색인). 개별 강의 본문 아님. 기간은 주 단위만 표기 |
| 설계 근거 | 채용공고 22개: Palantir, OpenAI, Anthropic, Databricks, Harvey, Cohere, Mistral, Salesforce, ElevenLabs, Smartsheet, Traversal, Cresta |
| Phase 1 (1~3주) | Production Python, Async, Data Engineering. 테스트 36개·커버리지 92% |
| Phase 2 (4~7주) | LLM 작동 원리, LLM API, 고급 프롬프트, LoRA·QLoRA 파인튜닝 |
| Phase 3 (8~11주) | RAG 구조, 벡터 DB, 고급 RAG(하이브리드·reranker·multi-hop), RAG 평가 |
| Phase 4 (12~16주) | ReAct, LangGraph, 멀티에이전트(CrewAI·AutoGen), MCP, 운영 hardening |
| Phase 5 (17~19주) | 평가 엔지니어링(5개 지표), LLM-as-Judge, 관측성 |
| Phase 6 (20~24주) | SSO, 시스템 통합, Modern Data Stack, Docker·Kubernetes, Terraform |
| Phase 7 (25~27주) | Customer Discovery, FDE Problem Decomposition Framework, 기술 문서화 |
| Phase 8 (28~31주) | 컴플라이언스, Legal AI, Healthcare AI, 금융·정부 AI |
| Phase 9 (32~35주) | capstone 4개, 공통 흐름 discovery → architecture → implementation → compliance package → handoff playbook |
| 재사용 예 | P1 retry decorator → P4 에이전트, P1 Pydantic 모델 → P3 RAG |
핵심 개념
- RRF (Reciprocal Rank Fusion)
- 여러 검색 결과를 점수가 아니라 순위로 합치는 방법. 문서마다 1/(k+순위)를 더해 다시 줄 세운다. 일반 지식으로 덧붙인 설명.
- cross-encoder reranking
- 질문과 문서를 한 번에 모델에 넣어 관련도를 다시 매기는 방식. 1차 검색보다 느리지만 정확해 상위 몇십 건에만 쓴다.
- QLoRA
- 모델 가중치를 4비트로 줄여 둔 채 작은 어댑터만 학습하는 파인튜닝. 소비자용 GPU에서도 돌릴 수 있다.
- RAGAS
- RAG 답의 faithfulness, 검색 정밀도·재현율 같은 지표를 자동으로 재는 오픈소스 평가 도구.
- MCP (Model Context Protocol)
- 모델이 외부 도구·데이터·프롬프트를 표준 방식으로 불러 쓰게 하는 연결 규약. stdio·SSE로 통신한다.
- ADR (Architecture Decision Record)
- 설계 결정 하나를 배경, 선택지, 결정, 결과로 짧게 남기는 문서. 나중에 온 사람이 왜 이렇게 만들었는지 알게 한다.
- runbook
- 장애나 정기 작업 때 운영자가 따라 할 절차서.
- SR 11-7
- 미국 연준의 모델 리스크 관리 감독 지침. 금융사 모델의 개발·검증·문서화 기준이 된다.
- FedRAMP ATO
- 미국 연방정부 클라우드 보안 인증 제도에서 운영 허가를 받는 절차.
- PrivateLink
- 클라우드 서비스를 공용 인터넷을 거치지 않고 사설 네트워크로 연결하는 기능.
내 메모
TODO: 내 생각 추가
원문: ‘Becoming Forward Deployed Engineer’(Substack)의 커리큘럼 포스트 ‘The AI Forward Deployed Engineer Course’(2026.9.26 게시, 10.23 수정). 원문은 35개 포스트의 커리큘럼 지도이며 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 원문에 적힌 Phase, 포스트, 도구, 채용 요건을 AX Review가 일곱 층으로 다시 정리했습니다. RRF, circuit breaker, DLQ, ADR 같은 개념 풀이는 일반 지식으로 덧붙였습니다. 기술·현업 디테일, starter repo 구조, 설정값, JSON 예시, 14주 압축 트랙, 평가 루브릭, 판정 기준, 국내 대응표, 인포그래픽, 표는 새로 작성했으며 숫자와 필드명은 가상 예시입니다. 각 포스트의 본문은 원문 Substack에서 볼 수 있습니다.