회고 및 후기🌿

​Claude Code Meetup Seoul FDE Night 2026 후기

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

Worxphere

  • ​날짜: 2026년 4월 17일 금요일
  • 시간: 18:30 – 21:00
  • 장소: 서울 교대역 인근
  • 주최: Claude Community Events
  • 공동 주최: 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, 비즈니스, 개발 사이 어디든 붙어서 고객의 문제를 푼다."

이 용어는 AI가 등장하기 이전부터 존재했다. 단순히 개발하는 사람이 아니라, 의사결정자를 고객에게 가장 가까이 배치해 스코핑부터 의사결정까지 직접 수행하는 포지션이다. 이 정의가 지금의 AI 시대에도 핵심을 관통한다.

2. 회사마다 다른 FDE

흥미로웠던 건, 같은 "FDE"라는 이름 아래 회사마다 역할을 다르게 설계하고 있다는 점이다.

사례 1 — Deployment Strategist(에코) + FDE(델타) 팀

어떤 회사에서는 두 포지션이 팀으로 움직인다.

  • 에코(Deployment Strategist) — 비즈니스 전략과 고객 관계
  • 델타(FDE) — 기술 조율과 개발

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

사례 2 — 제로투원과 도메인 침투

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

사례 3 — AI가 FDE의 역할을 확장시켰다

가장 주목한 부분이다. 또 다른 회사에서는 AI 도구의 발전 덕분에 FDE가 에코(비즈니스 전략)의 역할까지 확장했다. 3000억 원 규모 프로젝트의 의사결정자들을 만나고 사내정치까지 파악하며, SCM·지라·온프렘 시스템 등 인테그레이션을 커스터마이징한다.

리소스 투입 패턴도 인상적이다. 초반 90% → 후기 10%로 감소. FDE는 "들어가서 자립시키고 나오는" 모델에 가깝다.

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

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

처음에는 AX팀이 모든 것을 떠안으려 했다. 하지만 실제로 더 많은 도메인 지식과 더 나은 그림을 그릴 수 있는 쪽은 니즈를 가진 현업이었다.

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

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

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

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

K-FDE 사례 A:

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

K-FDE 사례 B:

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

"기술이 전부가 아니다"라는 감각이 모든 사례에 깔려 있었다. 한국에서 FDE는 엔지니어 + 컨설턴트 + 조직 리더의 교집합에 가깝다.

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

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

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

우리 팀이 어디 세대에 있는지 돌아보게 됐다. 1세대에서 2~3세대로 가는 길목, 4세대를 준비해야 하는 시점이다.

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

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

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

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

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

이제 벡터 DB는 완전한 정답이 아니다. 지식에 어울리는 구조로 쌓아야 한다. RAG, CAG, 혹은 RDB까지 — 어떤 지식에서 어떤 방식이 적합한지는 앞으로 테스트하며 찾아가야 할 문제다.

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

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

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

Context Graph라는 거창한 개념이, 사실은 부서별 용어 통일에서 시작된다는 감각. 누가·어떤 조직·어느 시점·어떤 상황에서 발화한 지식인지를 태깅하는 것. 이건 기술 문제가 아니라 조직의 언어를 정렬하는 문제다.

측정도 쉽지 않다

어떤 회사는 Claude Code 도입 성과를 3레이어로 본다.

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

하지만 결국 강조한 건 "정교한 측정보다 명확한 아웃컴 기반 평가가 효율적"이라는 것. 개발 조직은 벨로시티, 비개발 조직은 실행력 향상. 이 선이 현실적이다.

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

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

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

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

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

암묵지를 다루는 일이 소프트웨어 엔지니어링의 언어로 재조립되고 있다는 신호다. FDE가 푸는 문제가 점점 "지식의 버전 관리"와 가까워진다는 뜻이기도 하다.

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

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

8. SDLC에서 Context-DLC로

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

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

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

CTO의 역할조차 "개발 조직 아키텍처를 설계하는 사람"에서 "사람과 AI가 협업할 구조를 설계하는 사람"으로 전환되고 있다는 한 세션의 언급은, 이 흐름을 가장 직접적으로 요약한다.

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

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

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

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

맺음 — 다음은 우리 차례

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

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

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

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