Seoul | Claude Code FDE Night 2026 세미나 후기

2026 Claude Code FDE Night

Seoul | Claude Code FDE Night · Luma 에 다녀오고 후기를 남깁니다.

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

---

1부. The FDE Playbook — 실리콘밸리의 FDE 운영법

최규환 (Cognition)

FDE (Forward Deployed Engineer): 본사에 앉아 제품을 만드는 엔지니어가 아니라, 고객사에 직접 파견되어 그 고객의 문제를 풀면서 제품을 커스터마이징·적용시키는 포지션. 컨설턴트(문제 정의) + 엔지니어(직접 구현) + 세일즈(계약 확장)가 한 몸에 섞인 직군으로, Palantir가 만들어 유명해진 개념. 최근 Cognition·Gecko Robotics 등 실리콘밸리 기업에서 가장 많이 뽑는 직군 중 하나.`

FDE 모션 (motion): "FDE라는 직군을 어떻게 배치하고, 어떻게 고객사와 일하고, 어떻게 딜을 따고 제품을 적용해 나가는지에 대한 운영 방식 전체"를 가리키는 업계 용어. "Sales Motion", "PLG Motion"처럼 영어권에서 널리 쓰이는 "~하는 방식·전개 형태"라는 뜻.`

• FDE 모션의 변화
  • 툴 발전에 따라 Delta가 Echo의 일까지 흡수
  • 실행 속도가 대폭 빨라지면서 FDE 모션 자체가 툴·회사·제품에 따라 갈라지는 중
  • Claude Code도 마찬가지로 이 변화의 축에 있음
• FDE 모션의 장점
  • 고객에게 Over-fit된 밸류 제공 가능
    Over-fit: 머신러닝의 "과적합"에서 빌려온 표현. 여기서는 "해당 고객에게만 과하게 최적화된, 그 고객에 딱 맞는" 정도의 뜻. 일반화된 SaaS로는 못 주는 수준의 밀착 가치를 고객 한 곳에 극단적으로 맞춰 제공한다는 의미.
  • 아주 빠르게 움직일 수 있음
  • 100명의 FDE를 고객사에 직접 보낼 수 있다면 계약 성공률이 크게 상승
  • 밸류 트래킹에 결정적으로 유리
• FDE 모션의 단점 (많이들 간과함)
  • 코스트가 매우 큼
    • Over-fit 하려면 그만큼 FDE를 채용해야 함
    • 한국처럼 채용/해고가 자유롭지 않은 환경에서는 리스크가 훨씬 큼
  • 업무량이 극단적으로 많음
    • 여러 지역 고객(벤츠 등)을 맡으면 주 15시간 이하로 일하는 주가 거의 없음
    • 주말 근무 일상, 번아웃이 빠르게 옴
  • 고객은 보통 자기가 뭘 원하는지 모름
    • 그것을 Clarify 하는 것이 FDE의 역할
    • 다수 고객을 동시에 상대하면 벡터가 사방으로 퍼짐
    • 이 고객은 이걸, 저 고객은 저걸, 심지어 제품 방향성과 어긋나는 것까지 요구
    • 모든 것을 고려해 완벽한 의사결정을 해야 하므로 효율성이 떨어짐
• FDE 모션은 "들어가면 빠져나오기 어려움"
  • 제품을 도메인·프로젝트에 커스터마이징해야 할 때만 활용 권장
  • 단, 제품과 회사 문화 모두가 준비되어 있어야 함
• 제품 측면 조건 — 반드시 커스터마이징 가능한 인프라여야 함
  • Palantir, Gecko, Cognition 모두 "커스터마이징 가능한 인프라"로 만들어진 제품
  • Palantir 출신들이 Gecko Robotics로 이동해 함께 일하는 배경
  • 그들의 공통점: 무조건 Generalize 함
    Generalize: 특정 고객을 위해 하드코딩하지 않고, 어떤 고객에도 통하도록 일반화된 형태로 짜는 것. FDE가 만든 코드가 "고객 A 전용" 이 되면 쓰레기 코드가 쌓이지만, "설정만 바꾸면 B 고객에도 쓰이는" 구조로 만들면 자산이 됨.
    • 로직을 하드코딩하지 않고 어떤 고객에도 쓰일 수 있도록 설정값 중심으로 구성
    • 대표 예시: JSON/YAML 플러그인 기반 아키텍처
  • 커스터마이징 불가 구조에서 FDE 모션을 하면 쓰레기 코드와 Tech Debt만 누적됨
• 조직 측면 조건 — 명확한 의사결정자(Division) 필요
  • 다양성이 늘수록 "이 제품이 무엇을 위한 것인지"를 잊기 쉬움
  • 제품의 비전과 추구 방향을 제시할 수 있는 한 명 또는 한 그룹이 있어야 함
  • 어떤 요구는 수용(희생)하고, 어떤 요구는 배제할지를 명확히 선언할 수 있어야 함
• 개인적 전망
  • 지금 미국에서 가장 많이 뽑히고 있는 직군이 FDE
  • 단, 많은 회사가 앞으로 나아가다가 포기할 가능성 높다고 봄
  • 2년 이상 FDE를 운영한 회사는 Palantir, Gecko 뿐 — 단점들이 앞으로 드러날 것
  • Founding Engineer 개념으로의 FDE는 괜찮을 수 있음
    Founding Engineer: 창업 초기 단계에 합류해서 CEO·CTO와 거의 공동창업자처럼 움직이는 엔지니어. 제품·기술·비즈니스 전반에 관여. FDE를 이 개념으로 소수 운용하는 것은 스타트업에서 합리적이라는 맥락.
• 한국에서의 FDE 적용 — 개인 의견
  • SI 역할과의 차이
    • "자사 제품이 없다"는 차이라고 들었지만 실제로 꼭 그렇지도 않음
    • 이 부분은 더 생각해 볼 필요가 있음
  • 온프렘 요구성
    • 한국은 온프렘 배포 비중이 높아 속도가 훨씬 느림
    • SaaS 형태로 배포하지 못하고 백엔드를 가서 바꿔야 하는 구조
    • FDE의 장점은 속도인데, 그 속도를 받아줄 구조가 없으면 적용 난이도 급상승
  • 조직 문화
    • 경력 낮은 FDE가 전무급에게 "이건 이렇게 해야 합니다"라고 직접 말하기 어려움
    • 한국은 그 구조 자체가 안 됨
    • 홍콩에서는 최고위부터 말단까지 직접 만나 각 직급의 고충을 청취 후 제안 가능
    • 한국·중동에서 택한 방법: "나보다 높은 직급의 사람을 이미 설득해 놓고 미팅에 모셔오기"
    • 그렇게 조직의 다이나믹을 천천히 바꿔 나가는 우회 전략 필요
• 결론 및 권장
  • FDE = 커스터머 팀의 CTO 역할로 설명되는 직군 (Palantir/Gecko 공통)
  • 스타트업에서 Founding Engineer 개념으로 운영하는 것은 좋음
  • FDE 모션은 번아웃과 Run-way 단축을 야기 — 조심스럽게 접근 필요

Q&A

Q. Delta와 Echo의 페어링·협업 방식이 궁금합니다.

Delta / Echo: Palantir의 FDE 조직 내부 구분. 한 팀 안에서도 역할이 나뉘어 있음. Echo: 고객사 의사결정자와 관계 형성, 제품 정의, 딜 성사 등 "비즈니스·전략 쪽" 담당 Delta: 고객사 기술 담당자와 스펙 조율, 실제 컨피규레이션과 개발 수행 등 "엔지니어링 쪽" 담당 최근에는 툴이 발전하면서 Delta가 Echo의 일까지 흡수하는 방향으로 역할이 합쳐지고 있음.

최규환

• 어떤 Delta냐에 따라, 제품이 얼마나 도메인 특화되어 있느냐에 따라 달라짐
• 일반적으로 Palantir 관점 기준
  • Echo: 제품 정의, 의사결정자 탐색, 딜 메이킹, 고객사 조직 내 영향력 행사
  • Delta: 테크니컬 고객 미팅, 스펙 정의, 컨피규레이션, 제품 직접 개발
• 다만 최근 툴 발전으로 이 구분 자체가 빠르게 달라지고 있음

Q. 어떤 문제를 풀면 마무리되는지, 그 뒤에는 어떤 식으로 일이 이어지나요?

최규환

• 회사마다 다르지만 Cognition 기준으로 설명하면
  • 초반에 FDE를 많이 배치 (인터그레이션·컨피규레이션 수요 ↑, 고객 마음 얻기 필요)
  • 초반에 거의 90% 리소스를 소진
  • 그 이후에는 고객이 온보딩되어 찾는 횟수가 현저히 줄어듦
• 파이프라인을 5명 정도의 고객으로 균일하게 분산시키면 지속 가능한 구조가 됨
• 인프라 서포트는 후기에도 들어가지만, 전반적 소요 리소스는 "초기 90% → 후기 10%" 패턴

---

2부. Fireside Chat #1

이선민 (defytheodd CEO, 前 LF AI 수석) · 황현태 (SpaceY 대표)

AX (AI Transformation): DX(Digital Transformation)의 뒤를 잇는 개념으로, "기업의 업무·조직·프로세스 전체를 AI 기반으로 재설계하는 전환 작업". 단순히 AI 도구를 도입하는 것이 아니라, 일하는 방식 자체를 AI Native 구조로 바꾸는 것을 의미.

AI Native: 처음부터 AI를 전제로 설계된 조직·제품·사람. 기존 워크플로우에 AI를 "끼워 넣는" 게 아니라, AI가 있는 걸 기본값으로 두고 일·제품·의사결정을 구성하는 방식.

K-FDE: 세미나 중 이선민 님이 제안한 농담 섞인 개념. "한국형 FDE" — 야근·회식·음주가 가미된 한국 특유의 고객사 파견 엔지니어 형태를 가리키는 표현.

Q. 스페이스와이는 FDE 직군을 어떻게 정의하는가?

황현태 (SpaceY)

• 스페이스와이는 AX(AI Transformation) 기업
• AX를 수행하기 위해 고객사에 파견되는 엔지니어 = 스페이스와이의 FDE
• FDE가 푸는 문제: "레거시 조직을 AI Native 팀으로 전환하는 길"
• 즉, AX를 수행하는 FDE

Q. 사내 FDE로서 본인의 역할을 어떻게 정의하는가?

이선민 (defytheodd)

• 한국에서는 FDE 직종에 대한 공식적 정의 자체가 거의 없는 상태
• 본인이 일하는 방식이 FDE에 가까운지 돌아보며 K-FDE 개념으로 설명
• 코그니션 FDE 설명과 매우 흡사한 경험
  • 초반 온보딩·Implementation까지 90% 리소스 투입
  • 레거시 시스템에 통합된 이후부터는 점점 찾는 시간이 줄어듦
• 개인 사례 (LF)
  • Phase 1 6개월을 마친 뒤 주 5일 → 주 1일로 전환
  • 본인이 제안해 성사 (원래는 나가려다 주 1일이라도 가능하냐는 요청으로 이어짐)
• 현재 주 1일 근무 2개월 차
  • 멀티 에이전트 시스템을 기존 레거시에 모두 통합해 둠
  • 24시간 돌아가는 에이전트들이 룰과 패턴을 수집·준비
  • 미리 Ready 해두니 실제 출근일에는 주간회의 참여 + 컨펌 정도면 충분
  • 거의 재택이 가능한 수준까지 축소됨
• K-FDE 의 특징 (본인 관점)
  • 라포 쌓기 단계에 회식이 가미되면 K-FDE
  • 야근이 곁들여지면 더욱 K-FDE
  • 음주와 감정까지 더해지면 K-FDE 완성

황현태 (SpaceY)

• FDE = 컨설턴트 + 엔지니어
• 스타트업에게 컨설팅을 맡기는 엔터프라이즈는 없음 → 정면승부 대신 우회 전략 설계
• 스페이스와이의 FDE 상(像)
  • 창업 경험 있음
  • 엔지니어링 실력이 뛰어남
  • 비즈니스 토크 가능
  • 멀티태스킹이 빠른, 다소 젊은 인재
• "3개월짜리 계약을 1~10일 만에 끝내 버리는 전략"
  • 창의성을 발산시키면 2주 후 고객의 창의성이 고갈됨
  • 그때부터 디올(dio)타임 — 우리가 조직 컨설팅을 시작
  • 시킬 게 없을 때, 하나씩 짚으며 AX 관련 스텝을 밟아 나감
• 이것이 K-FDE의 Version 1.5 ~ 2 (말빨이 약하니 빨리 일 끝내고 컨설팅 단계로 진입)
• 채널톡 FDE와의 차이: 채널톡 FDE는 채널톡 관련 업무, 스페이스와이는 AX 관련 스텝을 밟음

Q. 최근 몇 달간 "하입"이라 시도했지만 결국 버리게 된 것, 반대로 남긴 것은?

이선민 (defytheodd)

• 노이즈 95%의 시대 — 노이즈를 Align해 주는 것이 FDE의 역할 중 하나
• 비즈니스 가성비·공수산정·ROI 관점에서 본질을 짚어주는 것이 핵심 역할
• 버린 것: Hermes Agent
  Hermes Agent: 자가개선(Self-improving)을 표방하는 오픈소스 에이전트 프레임워크 중 하나. OpenFlow 대비 낫다는 얘기로 한때 주목받았음.
  • "OpenFlow보다 낫다"는 얘기로 시도했지만 본인 레거시 환경에는 맞지 않음
  • Self-improving이라는 말과 달리 결국 노가다가 들어감
• 남긴 것: Karpathy가 올리는 한 장짜리/몇 개 파일짜리 도구들
  Karpathy (Andrej Karpathy): 前 OpenAI·Tesla AI 리드. 현재 개인 연구자·교육자로 활동하며 GitHub에 단일 파일짜리 미니멀한 AI 도구들을 종종 공개함. 업계에서 "복잡한 프레임워크보다 Karpathy가 올린 몇 줄짜리 코드가 더 실용적"이라는 평이 많음.
  • Karpathy Loop / Auto Research / LLM Wiki
  • 그 철학을 계승한 오픈소스 Graph Bit 등
  • 코드베이스에 적용 즉시 효과
    • 토큰 사용량이 눈에 띄게 감소
    • 목표 달성까지 걸리는 시간도 크게 단축
• 새로운 걸 빨리 시도 → 아닌 건 즉시 버리는 사이클이 중요

황현태 (SpaceY)

• 기술적 하입 자체에는 관심 없음
  • "안정적 기술만 써야 한다"는 꼰대 마인드가 아니라, 수없이 써봐서 관심이 식은 것
• 핵심은 문제 해결 — 그리고 문제 파악보다 어려운 게 엔터프라이즈의 이해관계자 지형
  • 상무님이 불러서 갔는데 팀장이 저지(?) 하는 상황
  • 팀장이 풀려는 문제와 상무 라인이 풀려는 문제가 다름
  • 대표 보고 다녀오면 모든 게 뒤집히는 현상
• 스페이스와이의 접근
  • 옛날에는 "문제 하나만 잘 풀면 된다"였지만 지금은 6명 모두의 문제를 풀어줘야 하는 시대
  • 실행 비용이 제로이기 때문에 우선순위 없이 다 풀되, 누구에게 제일 잘 보일지는 전략적으로 판단
  • 60년대생 부대표님(회사생활 40년)이 조직 상황 해석의 핵심 축
• "클로드 뭐든 써도 됨" — 중요한 건 어떤 문제를 누구의 관점에서 푸느냐

Q. 최근 반년간 의사결정의 흐름, 지금 4월 시점의 경로는?

황현태 (SpaceY)

• Vibe Coding에 대한 판단 흐름
  Vibe Coding: Andrej Karpathy가 2025년 초 퍼뜨린 용어. 개발자가 코드 한 줄 한 줄을 직접 쓰지 않고, AI에게 자연어로 "이런 느낌의 것을 만들어줘"라고 지시하며 결과물을 받아 조정해 나가는 개발 방식. AI가 대부분의 실제 코드를 생성.
  • 10월 말 리즈닝 모델 등장까지: 그냥 멋부림
    리즈닝 모델 (Reasoning Model): 답을 바로 내놓지 않고 내부적으로 생각(reasoning) 과정을 거친 후 응답하는 AI 모델. OpenAI o1, Claude의 Extended Thinking 등이 대표. 복잡한 코딩·수학·논리 문제에서 성능이 크게 향상됨. 리즈닝 모델 등장 시점부터 Vibe Coding이 "장난감"에서 "실무 도구"로 넘어갔다는 맥락.
  • 12월 말부터는 본인도 손 떼기 시작, 자기 자신을 실험체로 사용
    • React 못하지만 React 개발자라 속이고 프리랜서로 실제 활동
    • "된다"는 확신을 얻음
• 12월부터 대기업이 스페이스와이를 호출하기 시작
  • 공통점: 사내 AX팀을 1년 정도 운영하다가 한계 느끼고 연락
• AX의 세대론 (스페이스와이 관점)
  • 1세대: 사내 AX팀(=사내 Palantir) 구축 — 평생 해야 하는 모델, 한계 확인됨
  • 2세대: 전 직원에게 Claude Code를 가르치자 — 실제로 다 따라오진 않음, 주니어 이탈
  • 3세대: "스타트업(15인 미만)에서는 성공사례가 있다. 너희가 부서 하나만 맡아 AX 해봐"
    • 스페이스와이가 매출 24억, 인력 4~5명일 때 불려간 세대
    • 자동화 80개씩 하지만 그래도 조직이 안 바뀜
  • 4세대(현재 시도): 꼭짓점 AX — 팀 리더를 AI Native Builder로 만들기
    꼭짓점 AX: 스페이스와이가 명명한 AX 접근법. 팀 전체를 한 번에 바꾸는 것이 아니라 "꼭짓점(팀 리더)"을 먼저 AI Native Builder로 전환하면, 그 리더의 감각이 팀 전체의 일하는 방식을 바꾼다는 관점.
    • 모 유니콘 사례: 15명 팀을 만들되 팀원 없이 팀장 2개월 → 이후 "대학생 뽑아달라"로 바뀜
    • 리더가 AI Native 감각을 가지면 팀이 바뀐다
• 현재 스페이스와이는 3세대와 4세대를 오가며 클라이언트와 실험 진행 중
  • 전사 프로젝트는 크게 실패 위험 → 부서 단위 성공 후 옆 부서로 확장
• 공감되는 부분 — 이선민

이선민 (defytheodd)

• 대학생 군단으로 팀 구성 중 — 재2의 FDE 양성
  • 이들이 주 5일 → 주 1일 → 주 0.5일로 전환
  • FDE 1명이 주 10개 기업을 보는 모델을 연구·시도
• 대학생의 높은 수율/효율
  • 신경가소성이 말랑말랑해야 쏟아지는 정보를 다 처리 가능
• A팀장 · B팀장의 요구가 달라 충돌하는 경우에 대한 경험
  • 결국 회장님 보고 단계에서 다른 게 중요하다는 경우가 빈번
  • 그래서 "팀장 노이즈 캔슬링"도 병행
  • 덜 중요한 건 "딸깍 1~2번"으로 빠르게 처리, 중요한 건 딸깍 여러 번으로 리소스 집중
  • 이렇게 내부적으로 리소스를 재분배하는 것이 FDE의 중요한 역할

Q. FDE의 젊음 · 조직 경험 부족 · AI Native 제품 운영

황현태 (SpaceY)

• FDE가 대체로 젊고 스타트업 출신 → 엔터프라이즈 조직문화 이해도 낮음이 이슈
• 보완책: 2인 1팀 파견
  • 조직 구조 파악 담당, 업셀링 담당, 멘탈 서포터 등 역할 분담
  • K-FDE는 1인 수행도 가능하지만 "도와주는 1명"은 반드시 필요
• Knowledge Graph / Context Graph 논의
  Knowledge Graph (지식 그래프): 개념·엔티티 간의 관계를 노드와 엣지로 표현한 데이터 구조. 단순 문서 검색(RAG)이 아닌, "A 부서의 매출"과 "B 부서의 매출"처럼 같은 단어가 다른 의미로 쓰이는 맥락까지 구조적으로 표현 가능.``RAG (Retrieval-Augmented Generation): 사용자의 질문이 들어오면 관련 문서를 먼저 검색한 뒤, 그 문서를 참고해 LLM이 답변을 생성하는 방식. 사내 AI 챗봇의 표준 구조로 자리 잡았지만, 엔터프라이즈 환경에서는 암묵지·맥락 의존 지식에 취약해 한계가 드러남.
  • RAG 세팅 시대는 지났다 — 100%는 안 된다는 걸 이제 다 앎
  • 지식은 암묵지 기반, A팀의 "매출"과 B팀의 "매출"이 다른 의미일 수 있음
  • 해결해야 할 문제: "지식이 충돌할 때 화자·부서·조직 크기·상황에 따라 다르게 해석되는 상황"
• Context Graph: Knowledge Graph에 "누가 말했는지 / 어느 조직 / 어느 시점 / 어떤 상황"까지 태깅되어 있어, 질문이 들어왔을 때 그 맥락에 맞는 지식을 골라 꺼낼 수 있게 설계한 구조. 엔터프라이즈 AI의 핵심 난제 중 하나.
• 스페이스와이는 "도메인 엑스퍼트를 붙여달라" 요구 안 함
  • 도메인 엑스퍼트는 클라이언트의 도메인 엑스퍼트
  • 대신 젊은 엔지니어가 산업(가전, P&L 등)을 완벽히 이해할 때까지 "머리 박는다"

Q. 지식을 쌓았다는 것이 기술적으로 어떻게 구현되었는가?

황현태 (SpaceY)

• 지식의 성격에 맞춰 구조 선택
  • Graph DB에 어울리는 지식이면 Graph DB
  • Graph-DB-in-RDB 구조도 씀
  • pgvector도 씀
    pgvector: PostgreSQL에 벡터 임베딩을 저장·검색할 수 있게 해주는 확장. 별도 벡터 DB 없이 기존 RDB 하나로 의미 기반 검색까지 처리할 수 있어 최근 많이 채택됨.
• 옛날에는 벡터 DB에 강박적으로 매달렸지만, 지금은 그 지식에 어울리는 구조로 쌓음
• 부대표님의 조언이 큰 역할
• 핵심은 "쌓는 것"이 아니라 "지식 태깅"
  • 누가, 어느 조직에서, 어느 시점·상황에 필요한 지식인가
  • 태깅이 가장 중요
• 결과적으로 AI 프로젝트의 QA를 사원에게 맡기기 어려운 상황도 발생
  • 책임급 노하우가 Knowledge에 들어와 있어서 사원 수준에서 QA가 안 되는 역설

Q. 제품 자체가 커스터마이징되기 쉽게 만드는 것 — 두 분의 경험은?

이선민 (defytheodd)

• 고민 중인 주제
  • 상대 클라이언트가 본인에 대한 의존성(Dependency)을 갖게 됨
  • LF에서도 "주 1일이라도 나와 달라"는 역(逆) 제안을 받은 것이 그 증거
  • 의존성이 심해 암묵적 컨텍스트가 나 혼자에게 몰림 → 나가면 진전이 멈춤
• 끊어내기 위해 만드는 것: Harness Editor
  Harness: 원뜻은 "마구(馬具)" — AI 모델·에이전트를 특정 작업에 맞게 감싸고 제약·평가·도구 사용을 제어하는 래퍼 구조. 평가·튜닝·실행 흐름을 묶어놓은 일종의 "AI 작업 틀".
  • 영상 편집 시퀀스를 배치하듯이
  • Human-in-the-loop / Human-out-of-the-loop 구간을 GUI로 편집 가능하게
  • "LF를 나가기 위해 만들고 있다"
• Human-in-the-loop (HITL): AI 자동화 흐름 중간중간에 사람이 개입·검증·승인하는 단계를 두는 설계 방식. 반대로 Human-out-of-the-loop (HOTL) 은 특정 구간을 사람 개입 없이 AI에게 완전히 맡기는 방식.

황현태 (SpaceY)

• 개발자의 PR(Pull Request) 방식을 지식 그래프에도 그대로 적용
  • 지식 추가/삭제/수정 시 Conflict를 Knowledge Manager가 관리
  • PR이 아닌, Knowledge Manager용 보고서 형태의 표현이 새로운 문화
• 지식공학(Knowledge Engineering) 시대가 다시 도래
• 고객사 자체가 커스텀할 수 있는 것이 최종 목표지만, 솔직히 현 세대에서는 어렵다고 봄
  • AI Native한 세대(현 20대 중반)가 올라올 때 비로소 가능해질 것

Q. 제조업에서 AX가 특히 잘 적용되는 부분이 있는가?

황현태 (SpaceY)

• 재료/재고 예측/발주 영역 — 100% 도움됨
• 적용 방식
  • Vision 기반도 가능
  • MES 같은 시스템이 있다면 거기에 붙여서 운용 가능
    MES (Manufacturing Execution System): 제조 실행 시스템. 공장의 생산 현장에서 설비·작업·재고·품질 데이터를 실시간으로 수집·관리하는 시스템. ERP보다 더 현장에 밀착된 레이어.
• 뷰티·음료 제조는 원자재 관리 흐름이 유사하므로 서로 참고 가능

---

3부. Fireside Chat #2

김요섭 (Worxphere CTO) · 최한길 (채널톡 FDE Lead)
진행: 황현태 (SpaceY)

Q. 전사 비개발직군 250명을 Claude Code로 AX 전환하는 전략은?

김요섭 (Worxphere)

• 전사 약 550명, 그 중 비프로덕트 조직이 약 250명
• 본인의 역할: 전사 AX를 리드하는 "회사 내부 FDE"
  • 직속 FDE 팀이 비개발 조직의 AX 전환을 담당
  • 본인은 CTO로서 프로덕트 전체 조직의 AX를 같이 진행
• 고민의 출발점
  • 개인 생산성/팀 생산성 레퍼런스는 많은데, "전사의 생산성"을 높이는 케이스는 드물었음
  • 대표와 논의한 결론: 목표는 "전사의 실행력 향상 + 깊이 있는 의사결정"
• 실행 원칙: Top-down 우선
  • 임원 12명 중 개발자 출신은 본인 · 개발실장 · 대표 3명, 나머지는 비개발자
  • 지지난주에 임원 대상 AX 전환 교육 실시
  • 임원들이 Claude Code 기반으로 에이전트 20개씩 띄워 본인·조직 이득을 먼저 실현
• 왜 Top-down이 먼저인가
  • 작년부터 팀 단위로 AX 시도 → 개발자가 팀에 합류하는 수준으로는 생산성 향상 한계
  • 결국 조직이 일하는 방식, 직무 정의 자체가 바뀌어야 함
  • 임원이 AX 되지 않으면 이 변화가 워킹하지 않음
• 진행 순서
  • 임원 전환 → 주간 보고 등 업무 방식을 AI Agent 기반으로 Real-time 받게 함
  • 이후 FDE 팀이 비개발 직원 팀 단위로 투입해 전환·생산성 향상 수행

Q. 솔루션 아키텍트와 FDE의 차이는?

Solution Architect (SA): 고객사가 특정 제품·플랫폼(AWS, GCP, Palantir 등)을 도입·활용할 때, 기술 구조를 설계해 주고 프리세일즈 단계에서 기술 컨설팅을 해주는 엔지니어. 한국 SI 업계에서는 "솔루션 아키텍트"와 "세일즈 엔지니어"가 거의 같은 맥락으로 쓰임.

최한길 (채널톡)

• 팀 소속의 차이가 본질
  • 솔루션 아키텍트/세일즈 엔지니어 시절: 엔지니어 팀 소속
  • 현재 FDE: AX팀 소속
• 핵심 KPI가 다름
  • 세일즈 엔지니어는 프리세일즈 의사결정을 빠르게, 리드타임 축소가 목표
  • FDE는 회사 매출 증가가 목표 — 채널톡은 AI 상담 에이전트 ALF를 주력 판매
    ALF: 채널톡이 주력으로 판매 중인 AI 상담 에이전트 제품명.
  • "어떻게 더 빨리 팔고, 더 빨리 세팅할 수 있을까"를 고민
• 세일즈 단계 조인 여부는 시장별로 다름
  • B2B SaaS, 특히 엔터프라이즈는 딜 호흡이 2~3년
  • 엔터프라이즈에서는 엔지니어의 프리세일즈 참여가 병목 아님
  • 미드마켓에서는 좋은 데모 퀄리티가 매출에 직결
• 채널톡의 시장 정의
  • 엔터프라이즈: C레벨이 직접 꼽아준 고객
  • 미드마켓: C레벨이 안 꼽아주고 SMB도 아닌 것

Q. Claude Code 전환의 성과 평가는 어떻게 책정하는가?

김요섭 (Worxphere)

• 공식적으로는 3개 레이어로 측정 가능
  1. 토큰 사용량 리더보드 (많이 썼는지)
  2. 컨텍스트 인프라 기반의 활용도 지표 (Claude Code 내 다양한 지표)
  3. DORA Metrics 등 생산성 지표
     DORA Metrics: Google DORA 팀이 제시한 엔지니어링 조직 성과 지표 4종. 배포 빈도, 변경 리드타임, 변경 실패율, 복구 시간(MTTR). 개발 조직 생산성 평가의 표준 지표.
• 본인의 결론: 디테일한 측정은 의미 있을까?
  • 차라리 Outcome으로 얘기하는 편이 낫다
• 회사 관점의 Outcome
  • 조직 레벨: 개발 전체 Velocity가 얼마나 빨라졌는가
  • 비개발 조직: 실행력이 얼마나 빨라졌는가
  • 프로덕트 영역: 배포 속도, 가치 전달 속도 등
• 정교한 측정 인프라에 많은 에포트를 쏟기보다 명확한 Outcome 기반 평가가 효율적
• 250명 분량의 Claude Code 비용 부담
  • 당연히 크고, 단계별로 의사결정 중
  • 선행 작업: AI Governance 먼저 구축 (500~600명 직원, 천만 명 규모 사용자 대응)
    AI Governance: AI 사용에 대한 전사 가이드라인·보안·권한·감사 체계. 누가 어떤 데이터를 AI에 넣을 수 있고, 어떤 출력물을 외부에 내보낼 수 있는지 등을 정의하는 운영 기반.
  • 보안·POC를 통해 안전성과 리스크 없음을 증명해 가며 점진 확대
    POC (Proof of Concept): 본격 도입 전에 작은 범위에서 "이 기술/제품이 실제로 우리 상황에서 작동하는가"를 검증하는 파일럿 프로젝트.

Q. Claude Code 전환 속도가 가장 빨랐던 직군은?

김요섭 (Worxphere)

• 프론트엔드, 앱 개발자
• 배경
  • 작년 8월부터 6개 프로덕트를 4개월 만에 동시 리빌드하는 대형 프로젝트 진행
  • 클라이언트·프론트·앱 엔지니어를 AI 기반 코딩 생산성 향상 타깃으로 지정
  • 당사자들 간증: 개인 생산성이 약 8배 상승
  • 그 인원들이 현재 회사의 FDE 팀 멤버가 됨
    • 본인 직속 FDE 2명도 원래 클라이언트 엔지니어 출신
• 그 경험이 FDE 조직과 AI Native 전환의 Key Moment

Q. 채널톡은 FDE를 어떤 구성으로 고객사에 투입하는가?

최한길 (채널톡)

• 전체 FDE 팀은 5명 한 팀
  • 팀을 애매하게 나누면 오히려 업무가 안 됨
  • 팀 간 교집합 영역에 대한 의사결정이 느려지기 때문
• 고객사 투입 방식은 시장에 따라 다름
  • 미드마켓: AX 컨설턴트(DS)가 직접 투입
    DS (Deployment Specialist): 채널톡 내부 명칭으로, 개발자가 아닌 AX 컨설턴트를 가리킴. 고객사에 직접 들어가 제품을 세팅·활용하도록 돕는 역할.
    • 개발자는 아니지만 Vibe Coding/AI 이해도 높음
    • 채널톡 ALF에 대한 이해도 높아 세팅·해결이 빠름
  • 엔터프라이즈: FDE가 AX Ops 역할 수행
    AX Ops: DevOps처럼 "AX 운영(Operations)"을 담당하는 조직 컨셉. AX가 현장에서 잘 굴러가도록 공정·도구·병목을 점검하고 개선하는 역할.
    • 베스트 프로덕트를 위한 "공장" 관점으로 접근
    • 어느 설비에서 시간이 얼마 걸리는지, 병목이 무엇인지 체크
    • DS분들이 빠르게 세팅할 수 있도록 하는 장치 제작 및 공정 체크
• 왜 솔루션 아키텍트 방식과 다른가
  • AWS/GCP/Palantir처럼 인프라 깊이 들어가야 하는 제품은 비개발자가 쓰기 어려움
  • 채널톡은 상담 팀장·상담사가 쓰는 툴 — 자유도는 높되 난이도는 낮음
  • 엔지니어가 직접 투입되기엔 ROI가 안 나옴, 대신 AX 컨설턴트의 속도를 끌어올리는 쪽이 최적

Q. 인하우스 FDE 팀을 만들려는 회사에 어떤 조언이 있는가?

김요섭 (Worxphere)

• FDE 팀만으로는 해결되지 않음
• 본인은 "회사 내부 FDE"로서 뒤에서 풀어주는 역할
  • 보안 문제 (폐쇄망, 앱 차단 등)
  • 데이터 분산·소트 구성 등 플랫폼 레벨 이슈
  • 조직 이슈 (현업에서 FDE가 마주치는 것들)
• FDE 팀 위에 CTO/CIO/CEO 레벨의 스폰서십이 반드시 필요
• 이것이 "에코 역할 / 리드 에코"에 해당

Q. 최근 힙한 기술 대응은 어떻게 하고 있는가?

최한길 (채널톡)

• "AX"라는 키워드는 수혜는 받고 있지만 본인은 별로 안 좋아함
• 도구가 많이 나오는 것과 별개로, 본질인 사람이 강해지지 않으면 의미 없음
• 매니저 입장에서 더 중요하게 보는 역량
  • 체력
    • 실행력, 굳센 마음가짐, 씩씩하게 세상을 살아갈 수 있는 체력
  • 유연한 사고력
    • 지금 로직이 맞다고 믿되, 틀렸다면 언제든 수정할 수 있는 태도
• 도구 전환 러닝 커브에 에너지를 다 태우는 것은 오히려 손해

김요섭 (Worxphere)

• 시니어 의사결정자 입장에서는 "큰 방향"을 본다
  • 하루에도 여러 번 업데이트되는 기술 트렌드는 계속 보지만, 큰 그림이 어디로 가는지가 핵심
  • 해야 할 것뿐 아니라 "하지 말아야 할 것"을 결정해야 하기 때문
• Claude Code 로드맵·릴리즈 노트를 깊이 읽으며 제품의 전략과 의도 파악
• 두 가지 다 병행: 업데이트 팔로우업 + 큰 방향 의사결정

Q. 폐쇄망 / SAP ERP 등 엔터프라이즈 기간계 연동 경험은?

김요섭 (Worxphere)

• 폐쇄망 관련은 본인만 해당 (개인정보 처리 부분)
• SAP ERP 연동 방식
  SAP ERP: 독일 SAP社의 전사적 자원관리(ERP) 시스템. 대기업의 재무·구매·생산·인사 데이터가 모이는 기간계 시스템. 한국 대기업 대부분이 SAP 사용.
  • SAP에 바로 붙이지 않음
  • 사내 Data Lake에 SAP 데이터를 먼저 소프트 추출·축적
  • 그 Data Lake에서 전사의 AI 에이전트가 접근 가능한 구조 구축
  • 데이터 Write는 SAP에 직접 넣고, 필요한 데이터를 다시 가져와 보관
• Data Lake: 정형/비정형 데이터를 원본 그대로 대량 저장하는 저장소. 정제된 데이터만 넣는 Data Warehouse와 대비됨. SAP 등 원천 시스템의 데이터를 복제·적재해 전사 AI가 접근할 수 있는 허브로 활용.

Q. 채널톡의 AX 전환에 대해 — 엑스퍼트(파트너)와의 커뮤니케이션은?

최한길 (채널톡)

• AX 내에서 엑스퍼트를 밀착 담당하는 부문 존재
  • 예전 자유시장처럼 흘러가던 커뮤니티·리드 흐름을 최근엔 적극 관리 중
  • 리드 확보 후 어떻게 분배할지를 고민
• 채널톡 팀의 손이 한정적이므로 결국 시장에 맡겨야 하는 부분이 존재
• 엑스퍼트 전담 인력 계속 고용 중
• 오퍼레이션이 자주 바뀌고 외부 전달이 민감해 혼란이 있을 수 있음 — 커뮤니티 채널 통해 전달 가능

Q. 개인 생산성의 합이 조직의 속도를 대변하지 않는 문제 — 의사결정 품질을 높이는 AX 전략은?

김요섭 (Worxphere)

• 회사는 두 레이어로 나뉨
  • 의사결정 레이어 (임원)
  • 실행 레이어 (임직원)
• 전사 생산성 = 깊고 빠른 의사결정이 오해 없이 실행으로 전달될 때 발생
• 임원부터 AX 전환한 이유
  • 의사결정이 느린 이유는 결국 데이터·지표
  • 주간회의에서 "다음 주에 얘기하자"가 반복되는 이유도 데이터 대기
  • 그래서 임원 AX와 동시에 데이터 인프라 전환을 진행
• 데이터 측면 개선
  • 부서마다 달랐던 "매출" 정의를 Data Catalog로 정리 (주주사 보고, 임원 집계 등이 제각각이었음)
    Data Catalog: 회사에서 쓰는 데이터 항목들의 정의·출처·담당자를 정리해 놓은 목록. "매출"이 부서마다 다른 의미로 쓰이는 것을 단일 정의로 통일하는 기반.
  • 의사결정 빠르게 하기 위한 단일 소스 확보
  • 배치 중심이었던 데이터 흐름을 준실시간으로 전환 — FDE 팀과 데이터 분석가 협업
• 임원 AI Agent 구성
  • CTO/CEO/CFO용 AI 에이전트 각각 운영
  • 주요 보고 전에 해당 에이전트들과 여러 턴 돌려 의사결정 깊이 확보
• 의사결정 시간 자체를 만들어 주기
  • 임원들이 실제로 의사결정에 쓸 시간보다 면접·인터뷰·결재 등에 쓰는 시간이 과도함
  • 이런 부분을 자동화해 의사결정 집중 시간 확보
• 실행력 영역
  • 의사결정 결과가 중간 레이어를 거치지 않고 임직원 백그라운드에 즉시 커넥팅되도록 구성
  • "해야 할 일"과 "하지 말아야 할 일"을 빠르게 결정해 주는 것이 실행력을 올리는 또 다른 방법

Q. AX를 하다 보면 조직 구조 자체의 변화를 맞이하게 되는데, 워크스피어 내부에서도 그런 일이 있었는가?

김요섭 (Worxphere)

• 전사 AI Native 전환을 하면서 본인 CTO 역할부터 재정의
  • 전통 CTO: 개발 조직 아키텍처 + 비개발자에게 개발 용어 번역 + 프로젝트에 개발자 어사인
  • 현재: AI가 개발하는 시대이므로, 사람과 AI가 재협업할 수 있게 조직 문화·직무·일하는 방식을 다시 설계하는 사람이 CTO
• FDE의 역할도 재설계됨
  • 단순히 생산성을 올리러 들어가는 게 아니라, 일하는 방식과 직무의 역할 자체를 재설계
• 임원의 지원 필수 — FDE 혼자서 할 수 있는 일이 아님
• 프로덕트 조직도 재정의 중
  • 프론트엔드/백엔드의 전통 구분이 아닌, 자사만의 새 Arena와 직무 정의
  • 기존 SDLC를 AI-DLC / Context-DLC 등으로 재정의
    SDLC (Software Development Life Cycle): 요구사항·설계·구현·테스트·배포로 이어지는 전통적 소프트웨어 개발 생명주기.
  • AI-DLC / Context-DLC: 워크스피어가 내부적으로 재정의 중인 개념. AI가 개발의 중심이 된 시대에 맞춰 "Context 관리·AI 에이전트 운용"을 1급 시민으로 포함시킨 새로운 개발 생명주기 프레임.
  • 조직명·역할·배포 방식까지 동시에 재설계

---

참고 링크

• SI를 하겠다는 이상한(?) 스타트업 '스페이스와이' — 바이라인네트워크