IT 기술 따라잡기

https://youtu.be/U0L2oyE6Ph4

이름은 들어봤는데, 정확히 뭐 하는 사람인지는 모르겠다

Forward Deployed Engineer. 미국 AI 기업 채용 공고에서 부쩍 자주 보이는 직함이다. Anthropic은 $280K–$320K, OpenAI 시애틀은 $162K–$280K에 주식까지 걸고 뽑는다. 그런데 이 직무가 정확히 무엇을 하는 자리인지 설명한 한국어 자료가 거의 없다.

찾다 지쳐서 직접 정리했다. 채용 공고 10건을 1차 출처로 놓고, Palantir의 원형부터 2026년 8월 기준 채용 동향까지 42개 문서로 만든 뒤 28분짜리 영상으로 압축했다. 이 글은 그 과정에서 정리된 것 중 핵심만 뽑은 것이다.

한 문장 정의와, 뒤따르는 오해 세 가지

FDE는 고객 가까이에 배치되어, 자사 기술이 고객의 실제 업무 안에서 돌아가게 만드는 엔지니어다.

이 정의에서 자주 어긋나는 오해가 셋 있다.

첫째, "고객사에 파견 나간 개발자"가 아니다. 파견은 인력을 보내는 것이고, FDE는 결과(outcome)를 책임지는 것이다. Palantir가 만든 원형이 정확히 이 지점이었다.

둘째, "영업 지원 엔지니어"가 아니다. Sales Engineer는 계약 전까지가 책임 범위지만, FDE는 계약 후 운영에 올라갈 때까지가 범위다.

셋째, "컨설턴트"가 아니다. 문서를 남기고 나오는 게 아니라 코드를 짜고 배포한다.

왜 지금 다시 필요해졌나 — 데모와 운영 사이의 간극

LLM 데모는 하루면 만든다. 문제는 그걸 실제 기업 업무에 넣는 순간이다. 데이터 권한, 보안, 평가, 비용, 지연시간, 통합, 거버넌스가 한꺼번에 터진다.

이게 FDE가 다시 호출된 이유다. 범용 AI가 강력해질수록 "우리 회사 상황에서 이게 실제로 돌아가게 만드는 일"의 난이도는 오히려 올라간다. 모델이 좋아진다고 이 간극이 저절로 메워지지 않는다.

같은 이름, 여섯 가지 다른 직무

여기가 이 조사에서 가장 실용적인 부분이었다. FDE는 하나의 직무가 아니다. 채용 공고를 모아 보면 최소 여섯 가지 유형으로 갈린다.

• AI Lab형 (OpenAI, Anthropic) — 프론티어 모델을 고객 업무에 적용. 프로토타이핑 속도와 고객 접점 능력을 함께 본다
• Developer Workflow형 (Cursor) — 개발자가 고객이다. 제품 감각과 개발 생산성 이해가 핵심
• Infrastructure형 (Scale AI) — 데이터·평가 파이프라인 구축이 중심
• Vertical형 (Hebbia 등) — 금융·법률 등 특정 도메인 지식이 진입 장벽
• Government형 (OpenAI Gov, Palantir) — 보안 인가와 규제 대응이 전제
• Classic FDSE형 (Palantir) — 원형에 가장 가까운, 배포까지 전 과정 소유

같은 FDE 타이틀에 지원하면서 준비를 똑같이 하면 안 된다는 뜻이다. 유형별로 요구하는 것이 다르다.

공고 읽는 법 — 직함이 아니라 동사를 봐라

Applied AI Engineer라는 같은 직함이 회사에 따라 완전히 다른 일을 가리킨다. 직함으로는 구분이 안 된다.

대신 공고 본문의 동사를 보면 갈린다.

• deploy, integrate, onboard, own the outcome → FDE 성격
• scope, demo, pre-sales → Sales Engineer 성격
• train, fine-tune, benchmark → ML Engineer 성격
• design, ship, iterate on the product → Product Engineer 성격

한 줄만 읽어도 유형이 판별되는 경우가 많다.

기술 스택은 넓게, 깊이는 목표 유형에 맞춰

FDE 기술 스택은 8개 영역으로 정리된다. LLM/RAG/Agent, 평가(Evals), 관측(Observability), 보안·권한, 데이터 파이프라인, 통합(API·MCP), 배포·인프라, 제품 감각.

전 영역을 깊게 할 필요는 없다. 영역마다 Literacy(알고는 있다) / Working(직접 만든다) / Production(운영에 올린다) 세 단계로 나누고, 목표 유형에 필요한 것만 Production까지 끌어올리는 편이 현실적이다.

특히 Evals는 선택이 아니다. 데모와 운영을 가르는 것이 바로 평가 체계이고, FDE가 존재하는 이유의 절반이 여기 있다.

배경별로 준비 경로가 다르다

이 영상을 만든 진짜 이유다. "지금 내 위치에서 뭘 해야 하나"에 대한 답이 배경마다 완전히 다르다.

주니어 — 직함을 노리기 전에 증거를 만든다. 6개월 목표는 "FDE로 취업"이 아니라 "FDE 모양의 증거"다.

IT 시니어 — 새로 배우기 전에 다시 쓴다. 첫 질문은 "무엇을 배울까"가 아니라 "내 경력에서 이미 FDE 일이었던 것이 무엇인가"다. 고객 요구사항을 받아 시스템에 반영하고 운영까지 책임진 경험이 있다면, 그건 이미 FDE 업무다. 표현이 안 되어 있을 뿐이다.

비IT — 직행보다 우회가 확률이 높다. FDE로 바로 가는 것이 불가능하진 않지만 예외적이다. 인접 직무에서 증거를 쌓고 넘어가는 경로가 훨씬 자주 작동한다.

자료는 전부 공개했다

조사 문서 42개(한국어 + English)를 GitHub에 공개했다. 영상에 담기 어려운 실습 자료가 여기 있다.

• 내게 맞는 FDE 유형을 고르는 자가진단 질문지
• Production Readiness 체크리스트 (Evals / Security / Observability)
• 배경 10종별 이력서 Before → After
• 포트폴리오 프로젝트 3종 상세 설계서
• 면접 루프 단계별 예상 질문 25개

FDE 학습 자료 (GitHub)

영상 안에서도 각 파트가 시작될 때 해당 모듈로 연결되는 QR 코드가 뜬다.

영어 버전 영상도 있다. Forward Deployed Engineer — English version

마지막으로

채용 공고와 보상 범위는 수시로 바뀐다. 이 글과 영상의 수치는 2026년 8월 16일 기준 공개 페이지 스냅샷이다. 실제 지원 전에는 반드시 원문을 다시 확인하기 바란다. 이 자료는 학습·참고용이며 특정 회사의 채용을 보장하거나 대변하지 않는다.

Seattle Tech Week 2026이 이번 주(7/27~31) 시애틀에서 진행 중이다. 일주일 동안 열리는 행사가 242개, 그중 AI 태그가 붙은 것만 77개다.

전부 내 관심 분야라 오히려 고르기가 어려웠다. 갈 만한 게 없는 게 아니라, 관심 가는 게 한 주에 몰려 있는 게 문제였다. 행사 하나 확인하는 데 2분씩만 잡아도 8시간이 넘는다.

이걸 AI에게 맡기는 과정에서, 같은 문제를 두 에이전트가 어떻게 다르게 접근하는지 꽤 선명하게 볼 수 있었다. 결론부터 말하면 이번 건은 명확히 Codex Win이었다.

1. Claude Code가 막힌 지점

처음 요청은 단순했다. "이 페이지에 있는 행사들을 정리해줘."

Claude Code는 Luma 허브 페이지를 찾아냈다. 거기까지는 문제없었다. 그런데 각 행사의 날짜·시간·장소·신청 링크를 안정적으로 추출하지 못했다.

이유는 명확하다. Luma는 동적 웹앱이다. 사람 눈에 보이는 카드 목록은 정적 HTML에 들어 있는 게 아니라, 브라우저 안에서 API 호출로 렌더링된 결과다. 즉 "페이지를 찾았다"와 "그 페이지의 모든 이벤트 데이터를 구조화해서 가져왔다"는 전혀 다른 문제다.

게다가 이벤트가 200개가 넘으면 개별 링크를 하나씩 타고 들어가는 방식은 금방 병목이 된다. 결국 내가 화면 캡처를 제공하고, AI가 그걸 읽어 표로 만드는 우회로를 택했다. 하루치는 처리되지만 5일치를 하려면 같은 짓을 반복해야 한다. 확장성이 없는 방식이었다.

자동화하려다 반자동 수작업이 된 셈이다.

2. Codex가 문제를 다시 정의한 방식

같은 상황을 Codex에게 그대로 설명하고 방법을 물었다.

Codex는 "화면을 더 잘 읽는 방법"을 찾지 않았다. 대신 "이 화면이 데이터를 어디서 가져오는가"를 추적했다. JavaScript 번들과 네트워크 호출 구조를 확인해, 허브가 내부적으로 쓰는 공개 API 엔드포인트를 찾아냈다.

확인된 정보는 이랬다.

• Calendar ID: cal-7YGhWSN0o5k0LsQ
• Endpoint: https://api.luma.com/calendar/get-items?calendar_api_id=...&period=future
• 페이지네이션: pagination_limit, pagination_cursor, has_more, next_cursor

이 API를 호출하니 각 이벤트의 제목, 시작·종료 시간, 장소, 태그, 등록 상태, URL이 구조화된 JSON으로 떨어졌다. 페이지네이션을 따라가며 전체를 수집해 242개 전량을 확보했다.

구분 Claude Code 초기 방식 Codex 해결 방식

중요한 건 어느 모델이 더 똑똑하냐가 아니다. 문제를 어떤 레벨로 정의했는가가 결과를 갈랐다. "이 페이지의 행사들을 정리해줘"는 사람에게는 자연스러운 요청이지만, 에이전트에게는 동적 렌더링·숨겨진 API·페이지네이션·링크 매칭·상태 변경이 뒤섞인 복합 요청이다.

3. 수집 다음이 진짜 일이다

데이터가 모였다고 끝이 아니다. AI 태그만 77개인데 다 갈 수는 없다.

AI에게 내 기준을 줬다. 지금 진행 중인 프로젝트와의 관련성, 시간 충돌 여부, 시애틀-벨뷰 이동 부담(편도 약 30분). 결과물은 추천 목록이 아니라 내가 Yes/No만 판단하면 되는 후보표였다.

여기서 한 가지 짚어둘 게 있다. AI가 내 기준을 알 수 있었던 건 평소에 작업 기록을 로컬 마크다운으로 남겨뒀기 때문이다. WorkLog, Daily Roundup, Topic 문서가 쌓여 있으니 AI는 "이 사람이 무엇에 관심 있는지"를 추론할 근거를 갖고 시작했다. 그래서 인기 있어 보이는 행사가 아니라, 내가 하던 일과 연결되는 행사를 우선 보고했다.

최종적으로 참가 확정 12개, 승인 대기 12개. Google Calendar에 반영하고 승인 메일이 올 때마다 상태를 갱신했다.

4. 한 번의 통찰을 재사용 가능하게 만들기

여기서 끝났으면 그냥 잘 풀린 사례 하나였을 것이다.

일주일 뒤, 전혀 다른 사이트(Wix 기반 페이지)에서 똑같은 벽을 만났다. WebFetch가 "JS로 동적 렌더링돼서 내용을 다 못 가져온다"고 보고했다. 그때 이 원칙을 다시 적용했다 — 화면 말고 데이터 원천을 찾는다. 원본 HTML을 직접 받아보니 페이지 안에 임베드된 JSON 객체에 전체 콘텐츠가 들어 있었다.

같은 접근이 두 번 통했으면 그건 우연이 아니라 패턴이다. 그래서 이 방법 자체를 web-data-extraction이라는 재사용 가능한 스킬로 정리했다. 다음에 같은 상황이 오면 AI가 이 원칙을 잊지 않도록.

재사용 가능한 절차는 대략 이렇다.

1. 사용자가 보는 화면과 AI가 접근 가능한 데이터가 같은지 먼저 확인한다
2. 동적 페이지라면 HTML 텍스트만 읽지 말고 JS 번들과 네트워크 호출을 본다
3. 임베디드 JSON이나 공개 API가 있으면 화면 캡처 대신 거기서 구조화된 데이터를 가져온다
4. 페이지네이션(cursor, limit, has_more) 구조를 확인한다
5. 원천 데이터 저장과 선별·추천을 별도 단계로 분리한다
6. 상태가 바뀌는 정보(등록 승인 등)는 최종 결정 직전에 다시 확인한다

5. 한계도 분명하다

과장하지 않기 위해 적어둔다. AI가 Luma에 로그인해서 Register나 Request to Join을 대신 눌러주지는 못했다. 신청·승인 흐름을 에이전트가 안정적으로 처리하는 건 아직 일반 사용자가 안심하고 맡길 수준이 아니다.

그러니까 이 실험의 결론은 "AI가 다 해줬다"가 아니다. 정보 과부하를 줄이고, 내가 결정할 수 있는 형태로 정리해주는 데까지가 현재 지점이다. 그것만으로도 8시간짜리 일이 며칠 저녁 잠깐씩으로 줄었다.

6. 여담 — 월요일 현장에서

이렇게 정한 일정으로 어제 월요일 첫 행사에 갔다. 벨뷰 시청에서 열린 Startup425 행사였는데, 거기서 한국에서 온 42 Network 학생들을 만났다.

42는 강의와 시험 대신 프로젝트와 동료 학습(peer-to-peer)으로 개발자를 키우는 소프트웨어 교육기관이다. 프랑스 파리에서 시작해 지금은 30여 개 나라에 캠퍼스가 있고, 한국에는 42 서울이 있다. 공식 소개에 따르면 세계 최대 규모의 무료 IT 교육 네트워크다.

먼 길 왔으니 많이 배우고 가면 좋겠다.

영상

전체 과정을 7분짜리 영상으로 정리했다.

https://youtu.be/EQ1I0YSfMvM

영어 버전: https://youtu.be/OjSXw0_4ihY

7월 초 일주일간 무료로 제공되던 Anthropic의 신모델 "Fable 5"가 유료 전환됐다. $20 구독료(Claude Pro)에는 포함되지 않고, Usage Credits를 별도로 결제해야 쓸 수 있는 구조다. 마침 $100짜리 무료 크레딧(9/19 만료)과 이전 크레딧 약 $18(8월 만료)이 남아 있어서, 어차피 쓸 거 제대로 실측해보기로 했다. 시작 잔액은 $25.08, Monthly Spend Limit은 $20으로 걸어뒀다. "설마 이걸 넘기겠어" 싶었다.

첫날 저녁, 한도 118% 초과

착각이었다. 첫날 저녁, 슬라이드 컴포넌트 몇 개를 고치는 사이 Monthly Spend Limit을 118% 초과했다는 메시지가 떴다. 작업이 그대로 멈췄다.

하루 반나절 만에 한도를 4번 올리다

그때부터 이상한 행진이 시작됐다. $25 → $40(다음 날 새벽 또 초과) → $70(문서 두 개에 92%) → $100. 하루 반나절 사이 네 번의 한도 인상. 학습 로드맵 문서 하나, 구글 폼 설계 문서 하나 — 이 두 개를 마무리하는 데만 $17.93이 들었다. "이건 계속 못 쓰겠다"는 생각이 처음 든 순간이었다.

같은 날 두 작업의 영수증: $0 vs $8.16

그래서 작업을 두 종류로 나눴다. 절차가 정해진 기계적 작업(구글 폼 실제 제작)은 Sonnet으로, 창의적 판단이 필요한 작업(안내 슬라이드 1장 설계)만 Fable로. 같은 날 두 작업의 영수증을 비교하니 $0 대 $8.16으로 극명하게 갈렸다. 참고로 이 영상 자체를 기획하는 동안에도 크레딧 게이지가 74%에서 85%로 늘었고, 슬라이드 코드를 작성하던 제작 중반에는 남은 $16이 순식간에 사라지며 $100 한도마저 넘겨 결국 Opus로 갈아타 마무리했다.

지금 쓰고 있는 AI 스택

결론은 "성능은 최고, 하지만 일상적으로는 못 쓴다"였다. 지금은 이렇게 나눠 쓴다.

• Fable 5: 당분간 보류 — 일상 사용은 너무 비쌈
• Opus: 주요 작업 — 계획·분석·중요한 판단
• Sonnet: 간단한 작업 — 정해진 절차·기계적 처리

실제 매달 지불하는 AI 구독료는 Claude Pro $20 + ChatGPT Plus(Codex) $20 + Google AI Plus(Gemini) $4.99 — 총 $44.99에 세금 별도, 여기에 Usage Credits 같은 종량제 비용이 쓴 만큼 추가된다.

이 영상은 어떻게 만들었나

영상 슬라이드 기획부터 컴포넌트 코딩, 렌더링까지 Claude Code와 Remotion AI로 만들었다. 나레이션은 Qwen3-TTS로 생성했는데, 내 목소리를 복제한 Voice Clone과 AI 프리셋 보이스(Cherry·Serena·Sohee)를 슬라이드 성격에 맞게 섞어 썼다. 영어 버전은 슬라이드 텍스트와 나레이션을 전부 영어로 다시 작업해 별도로 올렸다.

영상으로 보기

한국어 영상 전체 챕터는 아래에서 확인할 수 있다.

https://youtu.be/3z4iwrpF0p8

English version (full English narration & subtitles):

https://youtu.be/VWg-1u9eEW8