How Forward Deployed Engineering is done at Factory — Eno Reyes

URL: https://www.youtube.com/watch?v=wpOA-UXynoM 날짜: 2026-07-29 채널: AI Engineer (aiDotEngineer) 발표자: Eno Reyes (Factory 공동창업자 겸 CTO, 전 Hugging Face / Microsoft)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

Factory는 왜 포워드 디플로이드 엔지니어(FDE)를 ==고객사를 위한 컨설팅 인력이 아니라 "제품의 창끝(tip of the spear)"으로 정의하는가==, 그리고 이 역할이 어떻게 조직을 "시그널 투 딥플로이(signal-to-deploy)"가 사람 개입 없이 흐르는 소프트웨어 팩토리로 바꾸는가.

• Factory는 팔란티어식 FDE 모델(고객 코드베이스에 파견돼 통합 작업을 대신 해주는 방식)을 명시적으로 거부하고, 고객사를 대신해 마이그레이션 같은 전문 서비스를 수행하지 않는다고 선언
• 대신 FDE는 최대 고객사의 엔지니어링 리더십·현장 엔지니어의 사고방식을 제품팀에 실시간으로 흘려보내는 정보 파이프라인 역할을 한다
• Factory의 제품 Droid는 신호(signal) → 우선순위화 → 코드 변경 → 검증 → 배포 → 새로운 신호라는 모든 조직에 내재된 "소프트웨어 팩토리" 파이프라인을 사람 개입 없이 관통시키는 것을 목표로 한다
• 이를 위해서는 코드베이스의 "에이전트 준비도(agent readiness)"—결정론적 검증 루프(린터, 타입체커, 테스트)의 밀도—가 핵심 선행 조건이며, FDE의 실무 대부분은 이 준비 작업에 들어간다

즉 이 영상은 "AI 에이전트를 기업에 파는 사람"이 아니라 "기업이 스스로 소프트웨어를 자동으로 생산하는 시스템(소프트웨어 팩토리)을 구축하도록 돕는 사람"으로 FDE 역할을 재정의하는 발표이며, 그 재정의의 배경에는 자율성(autonomy)을 얼마나 빨리, 그러나 무너지지 않게 밀어붙일 것인가라는 균형의 문제가 깔려 있다.

---

1. 포워드 디플로이드 엔지니어링(FDE)의 재정의

Factory는 팔란티어가 만든 원조 FDE 모델을 계승하지 않고, 전문 서비스가 아닌 제품 신호 파이프라인으로 역할을 재설계했다.

1.1. 팔란티어 시대의 원조 모델과 그 한계

1. 원조 FDE의 배경

   1. 기원: 포워드 디플로이드 엔지니어링은 팔란티어가 오래전에 개척한 개념으로, 강력한 소프트웨어 엔지니어를 고객사 조직에 직접 파견해 그들의 플랫폼을 현실의 뉘앙스에 맞게 구현·커스터마이즈하도록 했다
   2. 파견이 필요했던 이유: 과거에는 고객사 코드베이스에 직접 접근하거나 고객 내부의 데이터 스트림·제품에 직접 통합해야 하는 작업이 많았기 때문에, "커튼 뒤"에 있는 고객 환경에 들어가려면 인력을 파견(parachute in)할 수밖에 없었다
   3. 현재의 혼란: 지금은 이 역할이 "포워드 디플로이드 엔지니어", "디플로이드 엔지니어", "어플라이드 AI 엔지니어" 등으로 분화됐지만, 이들이 실제로 전문 서비스를 하는 건지, 특정 고객사에 맞춰 제품을 변형하는 건지, 고객 환경 위에 완전히 새로운 것을 만드는 건지 경계가 불명확하다

2. Factory의 명시적 거부

   1. 전문 서비스 거부: 고객이 "코드베이스 현대화(modernization)를 컨설팅 회사에서 견적받았는데 너희가 이 작업을 해줄 수 있냐"고 물어도, Factory는 자사 제품을 사용하더라도 그 마이그레이션을 대신 수행하는 것을 목표로 삼지 않는다
   2. 이유: 전문 서비스 수행은 상당한 매출을 가져다줄 수는 있지만, 그 자체로는 제품을 더 좋게 만들지 않고, 비즈니스를 대규모로 확장(scale)시킬 수 있는 방식이 아니라고 판단하기 때문이다

1.2. "제품의 창끝(Tip of the Spear)"으로서의 FDE

1. 정보 파이프라인 역할
   1. 신호의 흐름: 디플로이드 엔지니어는 가장 크고 중요한 고객사의 엔지니어링 리더십, 그리고 현장의 전술적 엔지니어들이 소프트웨어 개발과 AI를 실제로 어떻게 경험하는지에 대한 사고 과정을 제품팀으로 흘려보내는 정보의 스트림이다
   2. 제품에의 반영: 이렇게 흘러들어온 정보를 바탕으로 제품(Factory/Droid)을 빠르게 조정해 고객 환경에 더 잘 맞도록 만든다
   3. 자가조립(self-assembly) 목표: Factory가 배포될 때는 고객 환경 안에서 사실상 스스로 조립되는(self-assembled) 형태를 지향하며, FDE는 그 고객 환경—흐름과 ROI 스토리—을 이해하는 데 많은 작업을 투입한다

---

2. 소프트웨어 팩토리 개념

Factory가 고객에게 제공하는 것은 도구가 아니라 "신호가 들어가서 결과물이 나오는" 조직 내재적 프로세스를 사람 개입 없이 자동화하는 빌딩 블록이다.

2.1. 신호(Signal)에서 배포(Deploy)까지의 암묵적 파이프라인

1. 모든 조직에 내재된 프로세스

   1. 신호의 종류: 고객 대화, 버그 리포트, 내부 Slack/Teams 대화, 경영진의 "이걸 만들자"는 지시 등 외부 세계로부터 들어오는 다양한 신호가 존재하며, 신호마다 가중치가 다르다
   2. 우선순위화와 계획: 사람이 암묵적 또는 명시적으로 이 신호들을 우선순위화(triage)하고 계획을 세운다
   3. 코드 변경: 그 계획은 일반적으로 소프트웨어 개발자에 의해 코드베이스(진실의 원천, source of truth)에 대한 변경으로 전환된다
   4. 검증 단계: 변경 사항은 코드 리뷰, QA, 보안 영향 평가, 그리고 SAST 도구·린터·타입체커 같은 자동 검증을 거친다
   5. 배포와 재신호화: 모든 것이 통과하면 배포되고, 배포되어 모니터링되는 소프트웨어는 다시 더 많은 신호를 생성한다

2. AI로 이 루프를 완전 자동화하기

   1. 현재의 문제: 이 암묵적 피드백 루프는 대부분 조직에서 계측(instrument)이 매우 부실하다
   2. 목표 상태: AI가 파이프라인의 각 단계를 변형시키고 각 단계 간 워크플로우를 이해할 수 있게 만들면, 신호에서 배포까지 사람의 개입이 없는(no human intervention) 흐름에 도달할 수 있다
   3. 중요한 단서: 사람이 이 시스템을 엔지니어링하는 데 참여하지 않는다는 뜻이 아니라, 신호에서 배포까지의 흐름 자체가 사람에 의해 끊기지 않는다(uninterrupted)는 의미다

2.2. Droid — 모델 독립적 에이전트 하네스를 소유해야 하는 이유

1. 벤더 락인의 위험

   1. 비용 문제: 소프트웨어 팩토리를 하나의 모델만 사용할 수 있는 벤더 락인 솔루션 위에 구축하면 비용이 비쌀 뿐 아니라, 모델 독립성과 모델 제공자가 무엇을 만들고 못 만들게 할지 결정하는 역할에 대한 열린 질문들이 생긴다
   2. 데이터 소유 문제: 소프트웨어 팩토리를 관통하는 트레이스와 데이터를 소유하지 않으면, 팩토리를 진화시키려 할 때 곤란해진다
   3. "빌드, 바이(buy)가 아니다": 소프트웨어 팩토리는 손가락을 튕긴다고 나타나는 게 아니라 조직의 투자를 요구하며, Factory는 이를 "구축하는 것이지 사는 것이 아니다(built, not bought)"라고 표현한다

2. Droid가 제공하는 것

   1. 모델 독립성 + 데이터 접근권: Droid 하네스를 쓰면 모델 독립성뿐 아니라 Droid를 드나드는 모든 데이터에 대한 접근권을 가지며, 엔터프라이즈 레이어에서 어떤 정보가 어디로 흐를지 지시하는 중앙집중식 거버넌스와 통제를 함께 갖는다
   2. 에어갭(air-gap) 지원: 금융·헬스케어·정부 등 가장 보안이 엄격한 환경의 일부 파트너는 Droid를 에어갭해 소프트웨어 팩토리를 완전히 격리된 상태로 운영한다 — Factory의 한 디플로이드 엔지니어는 농담 삼아 "잠수함 안에서도 Droid를 돌릴 수 있다"고 말할 정도

---

3. 에이전트 준비도(Agent Readiness)와 자율성 성숙도 모델

디플로이드 엔지니어의 실무 대부분은 "AI가 문제를 푸는 것"이 아니라 "문제 검증을 위한 환경을 준비하는 것"에 들어간다.

3.1. 디플로이드 엔지니어의 세 가지 실무 축

1. 자가조립되는 제품 만들기
   1. 규모의 문제: 고객사가 4만5000명 규모에 수만~수십만 명의 엔지니어, 수만 개의 코드베이스를 가지고 있다면 이 정도 복잡도를 수동으로 설치할 수 없으므로 반드시 자가조립(self-assemble)돼야 한다
2. ROI/성과 스토리 만들기
   1. 명확한 인과관계 필요: "AI 코드 리뷰·AI QA·AI 보안 분석을 거친 모든 코드 변경은 버그 발생 확률이 87% 낮다 → 버그율 감소 → 고객 만족도 상승 → 매출/성장/신사업"처럼, 소프트웨어 팩토리 프로세스에서 핵심 비즈니스 목표로 이어지는 서사가 처음부터 명확해야 한다
   2. 요구 역량: 이 서사는 엔지니어링 지식과 비즈니스 지식을 모두 요구하는 복잡한 이야기다
3. 자율성 모델을 가르치기(teach the model)
   1. 로드맵 부재: 대부분 조직은 자율성 성숙도 모델(autonomy maturity model)이나 로드맵, 즉 진정한 자율 소프트웨어 조직을 만든다는 게 무엇을 의미하는지에 대한 개념 자체가 없다
   2. 인간 역할의 재정의: 이 세계에서 사람이 할 일은 무엇인가라는 질문에 대해, 엔지니어는 소프트웨어를 직접 조작하는 존재에서 소프트웨어를 만드는 시스템을 직접 유지·관리하는 존재로 이동한다 — 이 추상화 레벨 상승은 실제로 매우 어렵고 숙련된 엔지니어도 학습 곡선을 겪는다
   3. 적합한 인재상: 다른 개발자의 인에이블먼트를 이미 고민해온 DevEx 담당자, 빠르게 기술화되고 싶은 프로덕트 매니저, 고품질 개발 환경을 우선시해온 팀 출신 인력이 이 역할에 잘 맞는다

3.2. 코드베이스를 에이전트 준비 상태로 만들기

1. 에이전트 준비도의 정의
   1. 결정론적 검증 루프의 밀도: 대부분 조직은 린터, 타입체커, 보안 스캔 등 어느 정도 일관된 결정론적 검증 루프를 갖추고 있다 — 이 검증 루프가 코드베이스 안에 얼마나 많이 존재하는지가 곧 에이전트 준비도다
   2. 자율성과의 상관관계: 이런 피드백 루프가 대량으로 존재할수록 에이전트는 사람 개입 없이 더 오랜 시간, 더 복잡한 작업을 처리할 수 있다 — 검증 가능성에 비례해 장시간 실행되는 고급 에이전트 하네스의 결과물 품질이 결정된다
2. 작업의 실제 난이도 분포
   1. 저난도 30~40%: "Droid, 이거 다 고쳐줘"라고 명령하면 처리되는 손쉬운(low-hanging fruit) 작업이 전체의 약 30~40%
   2. 고난도 60%: 나머지 60%는 워크플로우 변경이 필요하거나, 자동화 시스템의 지나친 세심함(nitpickiness)에 익숙하지 않은 사람들의 저항을 고려해야 하는 작업 — 현재 개발 방식을 파악하고 사람의 개발 흐름을 방해하지 않으면서 더 엄격한 검증 전략을 도입하는 방법을 고민해야 한다

3.3. 미션(Missions) — 검증 가능한 문제를 위한 장기 실행 하네스

1. 미션의 정의
   1. 개념: 계획 단계를 제외하면 사람의 개입이 거의 없는, 매우 어려운 지식노동 문제(검증 가능한 문제)를 오래 실행하는 하네스로, "이 문제를 풀고 싶고, 문제를 푼다는 것의 정의는 이것이다"라고 설정하면 과업이 끝날 때까지 추론(inference) 레버를 계속 당기는 방식으로 동작한다
   2. 핵심 원칙: 문제를 검증 시스템의 집합으로 표현(frame)할 수 있다면, 오늘날 AI로 그 문제를 풀 수 있다
2. 실제 적용 사례
   1. 초대형 코드 마이그레이션: 3000만~5000만 줄 이상 규모의 코드베이스 마이그레이션을 완전 자율로 수행 — 발표에서 언급된 구체적 사례는 은행의 3000만~5000만 줄 규모 주식(equities) 시스템 마이그레이션
   2. 바이오메드/헬스케어: 딥러닝 기반 첨단 전략 적용
   3. 금융기관 주식 리서치 최적화: 서로 다른 주식(equities)에 대한 모델을 만들고 분석·비교하며, 백프롭(back-prop)하거나 해당 종목 위에서 거래(trade)할 수 있는 시스템 구축
   4. 전제조건: 이런 성과는 다운로드해서 설치하고 바로 실행(hit play)한다고 얻어지는 게 아니라 에이전트 준비도를 반드시 요구한다 — 코드베이스가 준비되지 않으면 세계 최고 수준 AI 시스템의 성공을 전혀 볼 수 없다
   5. 모델 학습과의 연결: 이런 모델들이 실제로 학습되는 방식(포스트 트레이닝)을 알면 이 접근이 당연하다 — 모델은 조밀한 보상(dense reward)이 필요하고, 검증 신호들이 장기 목표지향적 문제에서 모델을 궤도에 유지시키는 보상의 기반을 형성한다

---

4. "미래 도시" 비유와 제한된 자율성 전략

너무 앞서간 모범 사례는 사람들이 "우리 일과 무관한 테마파크"로 치부해버리므로, 균형 잡힌 속도로 자율성을 밀어붙여야 한다.

4.1. 엡콧(Epcot) 비유 — 모범 사례와 테마파크 사이의 균형

1. 월트 디즈니의 원래 구상
   1. 의도: 디즈니는 원래 미래 도시가 될 마스터플랜 모범 도시를 만들어, 이를 모델 삼아 전 세계 다른 도시들이 완전히 새로운 형태의 교통과 번영을 발전시키게 하려 했다
   2. 결과: 그러나 그 구상은 테마파크가 됐다
   3. 긍정적 유산: 그럼에도 그 작은 예시에서 다른 도시들은 실제로 디즈니가 남긴 중앙집중식 도시 교통 아이디어 일부를 인용했고, 지난 50년간 지어진 일부 현대 도시는 그 장난감 같은 예시를 모델로 삼았다
2. Factory가 얻으려는 교훈
   1. 작동하는 사례의 힘: 미래의 도시, 미래의 코드베이스에 대한 작동하는 예시가 있으면, 사람들은 영리하기 때문에 "저거 멋있네, 내 코드베이스 일부에도 가져오자"고 말한다
   2. 과도함의 위험: 그러나 너무 앞선 예시를 만들면 사람들은 "저건 테마파크다. 우리가 실제로 일하는 방식과 전혀 무관하다"며 그 정도 속도로 전환하는 비용을 두려워하게 된다
   3. 균형점: 미래가 달성 가능하다는 걸 충분히 보여주되, 전환 비용을 두려워하게 만들지 않는 섬세한 균형이 필요하다

4.2. "미래는 이미 와 있지만 고르게 분포되어 있지 않다" — 자율성의 불균등한 현실

1. Factory 자체의 자율성 지표
   1. 자율성 비율(autonomy ratio): Factory 코드베이스 자체는 대략 15~20%의 "자율성"을 갖고 있으며, 자율성 비율(중단되기 전까지 사람 대 AI 시스템이 수행한 액션의 비율)은 상위 80%대다
   2. 고객사가 더 자율적인 경우: 일부 고객사 코드베이스는 더 제한된(constrained) 방식으로 운영되기 때문에 Factory 자체보다도 더 자율적이다 — 누가 100% 자율성을 먼저 달성할지는 자명하지 않으며, 매우 제한된(contained) 내부 도구가 유력하다고 추정
2. Legal Droid — 100% 자율 사례
   1. 완전 자율 유지: Factory 내부의 법무 워크플로우인 "Legal Droid"는 사실상 100% 자율적으로 유지관리된다
   2. 반면 핵심 하네스는 아직 미달: 반면 Factory의 핵심 하네스(터미널 기반)는 아직 화면 깜빡임(flickering) 같은 시각적 문제를 검증 가능한 방식으로 잡아내는 검증기(validator)가 없어 루프를 닫지 못한다 — 이런 어려운 문제를 검증할 수 있는 시스템을 만드는 것 자체가 엔지니어링 과제다
   3. 인간의 비교우위: 이 지점이 미래의 이상한 그림을 보여준다 — 사람은 시각적 능력과 외부 세계에 대한 맥락 이해에서 우위를 가지므로, 이런 시스템을 구축하는 데는 여전히 많은 사람의 일이 남아 있다

---

5. 이 역할에 적합한 사람과 채용

5.1. 세 가지 적합 인재 유형

1. 전직 창업자(Former Founder)
   1. 속도의 이점: 창업 경험자라면 이 일을 하는 게 가장 빠른 방법이며, Droid가 다루는 SDLC의 각 단계(코드 리뷰, 인시던트 대응, QA, 테스트 등)는 각각 10억 달러 규모 비즈니스가 될 수 있다고 판단 — FDE로서 이런 각 제품의 본질적 방향을 정의하게 된다
2. 기술 커뮤니케이션에 능한 사람
   1. 요구 역량: AI에 능통하고 모든 레벨(현장 엔지니어부터 경영진까지)의 청중에게 말할 줄 알며, 비즈니스 감각과 임원급 프레즌스를 갖춘 사람
3. 시스템 사고자(Systems Thinker)
   1. 요구 역량: 시스템 설계, 루프 닫기(closing loops), 데이터 모델링을 좋아하고, 극도로 복잡한 조직 전체에 걸친 흐름이 어떤 모습이어야 하는지 이해하는 데 흥미를 느끼는 사람

5.2. 채용 정보

1. 연락처: 발표자 이메일 eno@factory.ai로 직접 연락 가능
2. 채용 페이지 직군명: "engineer, deployed"

---

주요 발언 모음

"if a customer says, 'I want to do a modernization of a codebase... could you do this consulting work for us?' Our goal is not to go and actually do that migration on their behalf, even if we happen to be using our product."

"deployed engineers are basically the stream of information from our largest and most critical customers... flowing all of that information back into our product to then rapidly adjust our product."

"if you build too much of an advanced example, then people will say, 'That's a theme park. That is not at all how the rest of the world works.'"

"the quality of the output of these very long-running harnesses of advanced agents is directly proportional to the degree to which you can validate their work."

"if you can frame any problem as the set of verification systems that need to validate it, then you can solve that problem with AI today."

"one of our deployed engineers jokes that you could run Droid in a submarine if you wanted to. And that's honestly true."

"our own code base is fairly agent-ready, pretty autonomous, but the code bases of some of our customers are actually even more autonomous because they operate in more constrained ways."

핵심 데이터 & 수치

• 저난도 자동 수정 비율: 코드베이스 개선 작업 중 약 30~40%는 "Droid, 다 고쳐줘" 명령만으로 해결되는 손쉬운 작업
• AI 검증 통과 코드의 버그 감소율: AI 코드 리뷰·QA·보안 분석을 거친 코드 변경은 버그를 유발할 확률이 약 87% 낮다는 ROI 스토리 예시
• 초대형 마이그레이션 규모: 은행의 주식(equities) 시스템 등에서 3000만~5000만 줄 이상 코드베이스를 완전 자율로 마이그레이션한 사례
• Factory 자체 자율성 지표: 자율성(autonomy) 약 15~20%, 자율성 비율(autonomy ratio, 중단 전까지 사람 대 AI 액션 비율) 상위 80%대
• Legal Droid: Factory 내부 법무 워크플로우로 사실상 100% 자율 유지관리

결론 및 시사점

1. FDE를 "고객사 대신 통합·마이그레이션을 해주는 파견 인력"으로 정의하면 매출은 나올 수 있어도 제품과 비즈니스가 확장되지 않는다 — Factory는 이를 명시적으로 거부하고, FDE를 고객 신호를 제품에 흘려보내는 "창끝"으로 재정의했다.
2. 진짜 병목은 AI 모델의 능력이 아니라 코드베이스의 "에이전트 준비도"다 — 결정론적 검증 루프(린터, 타입체커, 테스트)를 얼마나 촘촘히 깔아뒀는지가 에이전트가 얼마나 오래, 얼마나 복잡한 작업을 사람 개입 없이 처리할 수 있는지를 결정한다.
3. 3000만~5000만 줄 규모 마이그레이션 같은 극단적 사례가 가능한 이유는 "문제를 검증 시스템의 집합으로 정의할 수 있으면 AI로 풀 수 있다"는 원칙 때문이며, 이는 모델이 포스트 트레이닝에서 조밀한 보상(dense reward)으로 학습되는 방식과 직결된다.
4. 자율성 전환을 밀어붙일 때는 엡콧처럼 "너무 앞선 모범 사례"가 오히려 "우리와 무관한 테마파크"로 받아들여져 역효과를 낼 수 있다는 점을 유의해야 한다 — 달성 가능성을 보여주되 전환 비용에 대한 공포를 자극하지 않는 균형이 필요하다.
5. 100% 자율성은 핵심 시스템보다 오히려 매우 제한되고 범위가 좁은 내부 도구(예: Legal Droid)에서 먼저 달성될 가능성이 높다 — 화면 깜빡임 같은 시각적 문제처럼 검증기 자체를 만드는 것이 엔지니어링 과제로 남아있는 영역에서는 사람의 역할이 당분간 지속된다.
6. 이 역할에는 창업 경험자, 기술과 비즈니스를 넘나드는 커뮤니케이터, 시스템 사고자가 특히 적합하며, Factory는 SDLC의 각 단계(코드 리뷰, 인시던트 대응, QA, 테스트)를 각각 10억 달러급 잠재 비즈니스로 본다.