회고 및 후기🌿

​Claude Code Meetup Seoul FDE Night 2026 후기

귤랑귤랑 2026. 4. 22. 18:53

Worxphere

  • 날짜: 2026년 4월 17일 금요일
  • 시간: 18:30 – 21:00
  • 장소: 서울 교대역 인근
  • 주최: Claude Community Events (Anthropic 후원)
  • 공동 주최: Worxphere · SpaceY(DIO)
  • 진행: 최훈민 (Claude Community Ambassador, Seoul)

FDE, 아직 번역되지 않은 직무

지난 금요일 Claude Code FDE Night에 참석했다. Cognition 최규환 님, defytheodd 이선민 님, SpaceY 황현태 님, Worxphere 김요섭 CTO, 채널톡 최한길 님 — FDE라는 포지션을 각자의 자리에서 치열하게 정의해 온 분들의 이야기를 한자리에 모은 자리였다.

FDE(Forward Deployed Engineer)는 지금 한국에서 막 언어가 만들어지고 있는 직무다. 실리콘밸리에서조차 회사마다 역할 정의가 다르고, 한국에서는 더더욱 레퍼런스가 부족하다. 각자의 현장에서 쌓인 경험을 꺼내 놓고 공통 언어를 만드는 자리가 필요했고, 이번 행사가 그 시작점이 되었다고 느꼈다.

이 글은 그날 들은 이야기를 내 나름으로 정리하고, 내가 FDE 직무로 옮긴 뒤 쌓여 온 고민과 겹쳐 보는 기록이다.

1. FDE란 무엇인가 — "조직 내 줄기세포"

FDE 직무로 바뀐 후, 가장 먼저 고민한 건 "FDE의 정의"였다.

고객사에 직접 파견되어 그 고객의 문제를 풀며 제품을 커스터마이징하고 적용하는 포지션. 하지만 '문제를 해결하고 가치를 만드는 사람'은 내가 생각하는 개발자의 정의 그 자체이기도 하다. 그렇다면 FDE는 어떤 점에서 특별해야 할까?

행사장에서 나온 한 문장이 기준점이 됐다.

"FDE는 조직 내 줄기세포 같은 역할이다. PM, 비즈니스, 개발 사이 어디든 붙어서 고객의 문제를 푼다."

FDE는 Palantir에서 시작된, AI 등장 이전부터 존재해 온 직군이다. 단순히 개발하는 사람이 아니라, 의사결정자를 고객에게 가장 가까이 배치해 스코핑부터 의사결정까지 직접 수행하는 포지션이다. 컨설턴트(문제 정의) + 엔지니어(직접 구현) + 세일즈(계약 확장)가 한 몸에 섞인 직군 — 이 정의가 AI 시대에도 핵심을 관통한다.

2. FDE 모션이라는 단어 — 직군이 아니라 운영 방식

이번에 가장 먼저 머릿속에 박힌 단어는 "FDE 모션(motion)"이었다.

"FDE 모션이란, FDE라는 직군을 어떻게 배치하고, 어떻게 고객사와 일하고, 어떻게 딜을 따고 제품을 적용해 나가는지에 대한 운영 방식 전체를 가리킨다."

"Sales Motion", "PLG Motion"처럼 영어권에서 익숙한 표현인데, 우리에게는 아직 낯설다. 중요한 건 FDE를 "사람" 단위가 아니라 "모션" 단위로 보면 회사마다 왜 정의가 다른지가 자연스럽게 설명된다는 점이다. 이번 행사의 절반 이상이 사실은 이 "모션의 차이"에 대한 이야기였다.

3. 회사마다 다른 FDE — Palantir · Gecko · Cognition

같은 "FDE"라는 이름 아래 회사마다 모션을 다르게 설계하고 있었다.

Palantir — Echo(Deployment Strategist) + Delta(FDE) 페어링

Palantir에서는 두 포지션이 한 팀으로 움직인다.

  • Echo (Deployment Strategist) — 고객사 의사결정자와 관계 형성, 제품 정의, 딜 메이킹 등 비즈니스·전략 영역
  • Delta (FDE) — 고객사 기술 담당자와 스펙 조율, 컨피규레이션, 실제 개발 수행

Palantir FDE의 첫 번째 일은 온톨로지 구축이다. 가장 작은 단위부터 정의해 데이터플로우를 만들고, 고객의 불명확한 요구사항을 제품에 맞게 변환한다. "지식을 어떻게 구조화할 것인가" 가 FDE의 출발점이라는 점이 인상 깊었다.

Gecko Robotics — 제로투원과 도메인 침투

Gecko Robotics는 제품 자체를 제로투원으로 만든다. 로봇으로 수집한 데이터의 기술적 이점을 PMF(Product-Market Fit)로 전환하는 것이 FDE의 미션. 교과서, 가이드라인, 공정 설계를 직접 읽으며 도메인 지식을 습득하고, 그것을 제품으로 구현한다. UAE 오일·가스 산업에서 엔지니어링 프로세스를 2~5개월 단축시켰다는 사례가 나왔다.

Cognition — AI가 FDE의 역할을 확장시켰다

가장 주목한 부분이다. Cognition에서는 AI 도구의 발전 덕분에 Delta가 Echo의 일까지 흡수하기 시작했다. 3,000억 원 규모 프로젝트의 의사결정자들을 만나고 사내 정치까지 파악하며, SCM·Jira·온프렘 시스템 등 인테그레이션을 커스터마이징한다.

리소스 투입 패턴도 인상적이다. 프로젝트 초기에는 FDE 공수의 약 90%를 투입하고, 고객이 온보딩되어 자립한 뒤에는 10% 수준으로 감소한다. FDE는 "들어가서 자립시키고 나오는" 모델에 가깝다.

4. FDE 모션의 단점 — 많이들 간과하는 것

이번 세미나에서 가장 인상 깊었던 건, 연사들이 FDE의 매력만큼이나 단점을 솔직하게 펼쳐 두었다는 점이다.

  • 운영 코스트가 매우 크다. 고객에게 Over-fit된 가치를 주려면 그만큼 FDE를 채용해야 한다. 채용·해고가 자유롭지 않은 한국에서는 리스크가 더 크다.
  • 업무량이 극단적으로 많다. 여러 지역 고객을 맡으면 주 15시간 이하로 일하는 주가 거의 없고, 주말 근무가 일상이며 번아웃이 빠르게 온다.
  • 고객은 보통 자기가 뭘 원하는지 모른다. 그것을 Clarify 하는 일 자체가 FDE의 큰 부분이다.
  • 다수 고객을 동시에 상대하면 벡터가 사방으로 퍼진다. 어떤 요구는 제품 방향성과 정면으로 어긋나기까지 한다.
  • 한 번 들어가면 빠져나오기 어렵다. 이 부분은 뒤에서 다룰 "디펜던시" 문제와 곧장 연결된다.

이 단점 목록을 들으며, 우리 팀이 무리해서 FDE 모션을 흉내 내는 순간 가장 먼저 무너질 지점이 어디일지 떠올렸다.

5. FDE 모션 도입의 전제 조건

FDE 모션이 작동하려면 제품과 조직 양쪽이 함께 준비되어 있어야 한다.

제품 측면 — 커스터마이징 가능한 인프라
Palantir, Gecko, Cognition의 공통점은 제품을 "무조건 일반화(Generalize)"한다는 것이다. 로직을 하드코딩하지 않고, JSON/YAML 같은 설정값 중심으로 어느 고객에게도 통하도록 설계한다. 커스터마이징이 어려운 구조에서 FDE 모션을 굴리면, 결과물은 결국 쓰레기 코드와 Tech Debt로만 쌓인다.

조직 측면 — 명확한 의사결정자(Division)
다양성이 늘수록 "이 제품이 무엇을 위한 것인지"를 잊기 쉽다. 어떤 요구를 수용하고 어떤 요구를 배제할지 선언할 수 있는 한 명, 혹은 한 그룹이 반드시 필요하다.

이 두 조건은 사실 우리 팀 입장에서도 그대로 체크리스트가 된다. "우리는 일반화된 제품을 가진 팀인가?" "현업의 요청 중 무엇을 거절할 권한이 있는가?" — FDE 모션을 도입하기 전에 답해야 하는 질문이다.

6. 우리 팀에서 저절로 일어난 분화 — Delta와 Echo

이런 이야기들을 들으며 우리 팀을 돌아봤다.

처음에는 AX(AI Transformation)팀이 모든 것을 떠안으려 했다. AX팀이 도메인을 학습하고, 데이터를 정리하고, 자동화를 만들고, 조직 내 전파까지 담당하려 했다. 하지만 곧 한계가 드러났다. 더 많은 도메인 지식과 더 나은 그림을 그릴 수 있는 쪽은 결국 니즈를 가진 현업이었다. AX팀이 아무리 빠르게 학습해도, 현업의 암묵지에는 닿지 못하는 영역이 있었다.

결국 우리 팀은 AX에 필요한 데이터와 인터페이스를 발괴하고, 데이터 태깅을 제공하는 역할(= Delta)을 맡고, 해당 도메인의 전문가가 직접 사용법을 익혀 조직 안으로 전파하는 역할(= Echo)을 수행하게 됐다. 의도하지 않았는데 Delta와 Echo의 역할이 저절로 나뉘진 셉이다.

흥미로운 건, 채널톡에서도 같은 분화가 일어났다는 점이다. 채널톡은 미드마켓에 AX 컨설턴트(DS)가 직접 투입되고, FDE는 AX Ops로서 DS가 빠르게 세팅할 수 있도록 "공장"을 만든다. 결국 우리 팀의 분화는 우연이 아니라, 비슷한 문제를 푸는 조직에서 자연스럽게 도달하는 패턴에 가깜다.

행사에서 제시된 "AX FDE = 고객의 입장에서 일하는 방식을 AI Native로 바꾸는 역할"이라는 문장은, 우리 팀의 방향을 가장 또렷하게 요약해 주었다.

7. K-FDE — 한국형 운영 모델

한국 맥락에서 FDE는 또 다른 얼굴을 한다.

K-FDE 사례 A — defytheodd 이선민 님

  • 6개월 페이즈 1 후 주 5일 → 주 1일 전환에 성공
  • 멀티 에이전트 시스템을 레거시에 통합, 24시간 자동 룰 수집·패턴 분석
  • 초기 라포 형성 단계에서는 회식·야근·음주가 K-FDE의 정체성이라고 농담처럼 말했지만, 농담만은 아니다

K-FDE 사례 B — SpaceY 황현태 님

  • 3개월 계약을 1~2주 만에 완료하고, 남은 시간에 AX 컨설팅으로 전환
  • 2인 팀 구성 — 한 명은 FDE 기술, 한 명은 조직문화 파악과 멘탈 서포트
  • 폐쇄망, SAP-ERP 연동 등 선배 개발자들의 우려에 휴먼 리더블(human-readable) 코드로 대응
  • A팀장·B팀장·회장의 우선순위를 파악해 리소스 재분배

여기에 향로 님이 정리한 한국 FDE의 구조적 한계를 겹쳐 보면 K-FDE가 단순한 농담이 아닌 이유가 분명해진다.

  • 온프렘 비중이 높다. SaaS로 빠르게 배포하지 못하고 백엔드를 직접 가서 바꿔야 한다. FDE의 강점인 속도가 죽는 구조다.
  • 위계적 조직 문화. 경력 낮은 FDE가 전무급에게 "이건 이렇게 해야 합니다"라고 직접 말하기 어렵다. 그래서 한국·중동에서는 "나보다 높은 직급의 사람을 미리 설득해 미팅에 모셔오는" 우회 전략이 필요하다.
  • 엔터프라이즈 조직 경험 부족. 젊은 FDE가 대기업 의사결정 구조를 파악하기 어려워, 2인 팀이 거의 필수가 된다.

K-FDE는 이런 구조적 제약 위에서 진화해 온 한국형 운영 모델이다. 한국에서 FDE는 엔지니어 + 컨설턴트 + 조직 리더의 교집합에 가깝다.

8. 엔터프라이즈 AX의 세대론

한 세션에서 정리된 AX 진화 단계가 깔끔했다.

세대 전략 한계
1세대 사내 AX팀이 모든 현업 문제를 해결 지속 불가능 (사실상 평생 운영해야 하는 모델)
2세대 전 직원에게 Claude Code 교육 주니어 이탈 발생
3세대 부서 단위 AX — 한 달에 80개 자동화 구현 조직 차원 확산 속도 이슈
4세대 (현재) 꼭지점 AX — 팀 리더를 AI Native Builder로 리더가 바뀌면 팀이 바뀐다

우리 팀이 어디 세대에 있는지 돌아보게 됐다. 1세대에서 2~3세대로 가는 길목, 4세대를 준비해야 하는 시점이다. "팀장만 AI Native가 되어도 팀이 바뀐다"는 명제는, 우리가 다음 분기 로드맵에서 누구를 가장 먼저 끌어와야 하는지를 명확히 가리키고 있었다.

9. 워크스피어 사례 — "임원 우선 AX"라는 다른 답

세대론과 별개로, 워크스피어 김요섭 CTO의 발표는 또 다른 답을 보여줬다. 임원부터 바꿈다는 Top-down 전략이다.

  • 전사 약 550명, 비프로덕트 조직 약 250명 규모
  • 임원 12명에게 Claude Code 기반 에이전트 20개씩 제공, 본인·조직 업무를 먼저 AX
  • 주간 보고를 AI 에이전트 기반으로 실시간 전환
  • 그다음에야 FDE 팀이 비개발 직원 팀 단위로 투입

핵심 논리는 단순했다. "개발 도구만 바꿔서는 생산성이 안 오른다. 일하는 방식과 직무 정의 자체를 다시 설계해야 하는데, 임원이 AX 되지 않으면 그 변화가 작동하지 않는다."

세대론의 4세대(꼭지점 AX)가 "팀 리더"를 꼭지점으로 본다면, 워크스피어는 그 꼭지점을 더 위로 올려 "임원"으로 잡았다. 우리 팀에 이 모델을 그대로 옮기긴 어렵지만, "현업 리더 한 명을 진짜로 AI Native로 바꾸는 것이 자동화 100개보다 가치 있다"는 메시지는 분명히 가져갈 수 있는 통찰이었다.

10. 전사 AX, 그리고 남은 숙제들

회사 전체를 AX한다는 목표 앞에는 풀어야 할 문제가 많다.

  1. 사내 전체 데이터를 어떻게 모으고 관리할지 — 거버넌스
  2. 방대하고 다양한 데이터를 빠르게 서빙할 인터페이스
  3. Knowledge Graph를 어떤 방식으로 구성할지
  4. 성과를 어떻게 측정할지

벡터DB는 더 이상 정답이 아니다

예전에는 "벡터DB는 반드시 써야 한다"는 강박이 있었다. 하지만 100% RAG 구성이 정말 효율적인지는 의문이고, 최근에는 Markdown 파일을 잘 쌓고 태깅하는 방식으로 관리하는 팀도 있다. Karpathy의 미니멀 도구들(LLM Wiki, Auto Research, Karpathy Loop)이 효과를 내고 있다는 발표도 같은 맥락이다.

이제 벡터DB는 완전한 정답이 아니다. 지식에 어울리는 구조로 쌓아야 한다. RAG, CAG, Graph DB, pgvector, 혹은 RDB까지 — 어떤 지식에서 어떤 방식이 적합한지는 앞으로 테스트하며 찾아갈 문제다. 우리 팀도 사실 작년에 "일단 벡터DB부터"라는 결정으로 시작했었는데, 1년이 지난 지금은 어떤 데이터는 그냥 RDB가 더 낫고, 어떤 데이터는 Markdown이 더 낫다는 감각이 쌓이고 있다.

Context Graph의 첫 단추는 "정의 통일"

한 세션에서 가장 현실적인 문장이 나왔다.

"A팀의 '매출'과 B팀의 '매출'이 다르게 해석된다. 그래서 Data Catalog로 정의부터 통일한다."

Context Graph라는 거창한 개념이, 사실은 부서별 용어 통일에서 시작된다는 감각. 누가·어떤 조직·어느 시점·어떤 상황에서 발화한 지식인지를 태깅하는 것. 이건 기술 문제가 아니라 조직의 언어를 정렬하는 문제다. 워크스피어가 SAP에 직접 붙지 않고 Data Lake를 중간 허브로 두는 방식도, 결국 "전사가 같은 데이터를 같은 정의로 본다"는 같은 방향의 해법이다.

측정도 쉽지 않다

워크스피어는 Claude Code 도입 성과를 3레이어로 본다.

  1. 토큰 사용량 리더보드 — 사용했는가
  2. 컨텍스트 인프라 사용 품질 — 잘 쓰고 있는가
  3. DORA 메트릭 — 결과적으로 생산성이 올랐는가

하지만 결국 강조한 건 "정교한 측정보다 명확한 아웃컴 기반 평가가 효율적"이라는 것. 개발 조직은 벨로시티, 비개발 조직은 실행력 향상. 이 선이 현실적이다. 우리 팀도 한동안 측정 인프라를 만드는 데 공수를 너무 많이 썼는데, "측정을 측정하는" 함정에 빠지지 않으려면 이 감각이 필요하다.

11. 노이즈 95%의 시대 — 무엇을 버리고 무엇을 남길 것인가

이선민 님이 던진 한 문장이 오래 남았다.

"노이즈가 95%인 시대다. 그 노이즈를 Align해 주는 것이 FDE의 역할 중 하나다."

같은 세션에서 본인이 직접 정리한 "버린 것 / 남긴 것" 리스트가 인상적이었다.

  • 버린 것: Hermes Agent. "OpenFlow보다 낫다"는 말로 시도했지만, 본인 레거시 환경에는 맞지 않았다. Self-improving이라는 말과 달리 결국 노가다가 들어갔다.
  • 남긴 것: Karpathy의 한 장짜리 도구들과 그 철학을 계승한 오픈소스. 코드베이스에 적용 즉시 토큰 사용량과 목표 달성 시간이 모두 줄었다.

황현태 님의 발언도 같은 맥락이었다. "기술적 하입에는 관심 없다. 핵심은 문제 해결이고, 문제 파악보다 더 어려운 것이 엔터프라이즈의 이해관계자 지형 파악이다."

FDE의 진짜 일은 새로운 도구를 빠르게 시도하고, 아닌 건 즉시 버리는 사이클을 본인 안에 갖는 것에 가깝다. 이 감각은 우리 팀에도 그대로 적용된다. 신기술의 90%는 결국 우리 팀 데이터·조직·고객에 맞지 않는다. 그것을 솔직하게 인정하고 빠르게 흘려보내는 능력이, 1년이 지난 뒤 팀의 자산을 결정한다.

12. 기술 너머, 진짜 벽은 암묵지다

여기까지는 기술이 해결할 수 있는 영역이다.

하지만 Context Graph를 제대로 구축하려면 결국 각 부서의 암묵지를 어떻게 형식화할 것인가로 귀결된다. 기술자는 이 암묵지를 어떻게 공통화하고 부여할지 고민하며, 그에 맞는 적당한 인터페이스를 설계해야 한다.

한 연사의 말이 인상 깊었다.

"지식 매니저 역할이 다시 부활하고 있다. 코드 PR처럼, 지식 변경사항도 리뷰 가능한 단위로 관리해야 한다."

암묵지를 다루는 일이 소프트웨어 엔지니어링의 언어로 재조립되고 있다는 신호다. FDE가 푸는 문제가 점점 "지식의 버전 관리"와 가까워진다는 뜻이기도 하다. 우리 팀에서도 최근 "이 자동화는 누구의 어떤 판단 기준 위에 서 있는가"를 함께 기록하기 시작했는데, 이게 곧 우리 식의 Context Graph 0.1버전이 되어 가고 있다.

그리고 실제로 그 방향의 도구들이 움직이고 있었다. 시퀀스 배치와 Human-in-the-loop 설정을 GUI로 편집할 수 있는 Harness Editor, 프로세스를 시각화·표준화해서 FDE 의존성을 낮추는 장치들. 이런 도구가 성숙해질수록 "FDE가 나가면 프로젝트가 멈춘다"는 만성적 문제도 줄어들 것이다.

FDE의 진짜 일은, 어쩌면 여기서부터 시작되는 것 같다.

13. SDLC에서 Context-DLC로

가장 큰 프레임을 건드린 문장도 있었다.

"SDLC(Software Development Life Cycle)는 이제 AI-DLC, 혹은 Context-DLC로 재정의된다."

코드를 짜는 라이프사이클이 아니라, 컨텍스트를 설계·관리·전달하는 라이프사이클이 새로운 기본값이 된다는 말이다. 프론트엔드·백엔드의 직무 구분을 넘어 자사만의 새로운 "Arena"와 직무 정의가 필요하다는 논의도 같은 맥락이었다.

CTO의 역할조차 "개발 조직 아키텍처를 설계하는 사람"에서 "사람과 AI가 협업할 구조를 설계하는 사람"으로 전환되고 있다는 워크스피어의 언급은, 이 흐름을 가장 직접적으로 요약한다. 우리 팀의 그림도 결국 같은 방향이다. "어떤 코드를 짤 것인가"보다 "어떤 컨텍스트를 어떤 형식으로 쌓을 것인가"가 다음 분기의 진짜 질문이 된다.

14. 왜 이런 자리가 필요한가

행사장에서 가장 자주 들린 질문은 "그래서 FDE가 정확히 뭐 하는 사람이에요?"였다.

정답이 아직 정해지지 않은 직무이기에, 각자의 답을 들고 모이는 것 말고는 방법이 없다. 실리콘밸리의 FDE, 한국의 K-FDE, 엔터프라이즈의 FDE, 스타트업의 FDE — 모양은 조금씩 달라도 결국 고객 현장에서 AI Native 방식으로 가치를 만드는 사람이라는 공통점은 또렷했다.

이 공통점을 한 번 더 확인할 수 있었다는 것만으로도 좋은 자리였다. 이런 모임이 계속 이어지면 좋겠다.

맺음 — 다음은 우리 차례

돌아오는 길에 정리한 내 답은 이렇다.

FDE는 고객의 문제를 푸는 엔지니어다. 하지만 이 시대의 FDE는 "고객이 일하는 방식을 AI Native로 바꾸는 사람"이다. 컨텍스트를 설계하는 사람이다.

다음 FDE Night에서도 또 배우고 싶다. 그때까지 우리 팀은 우리만의 Context Graph를 한 걸음씩 쌓아 두려 한다.

자리를 만들어주신 분들, 그리고 귀한 인사이트를 나눠주신 연사분들께 깊이 감사드린다.

참고