Forward Deployed Engineering: 시범을 운영까지 끌고 가서 다음 팀이 하루에 쓰게 만드는 법

OpenAI의 FDE 팀은 AI 시범 사업을 운영까지 끌고 간 뒤, 그 결과물을 다음 팀이 하루 안에 가져다 쓸 수 있는 묶음으로 바꾸는 것을 일의 완성으로 봅니다. 우리 조직에 옮기려면 운영에서 믿고 쓸 수 있는지를 재는 eval(평가 세트)을 먼저 세우고, 사례마다 따로 만든 코드를 공통 harness(모델을 감싸 도구·데이터·평가를 붙이는 실행 틀) 위의 skill·plugin으로 묶어야 합니다.

요약

OpenAI에서 FDE(forward deployed engineer, 고객 현장에 들어가 가장 어려운 문제를 함께 풀고 운영까지 끌고 가는 엔지니어) 조직을 이끄는 Colin Jarvis가 2026년 10월 22일에 쓴 글입니다. 그는 2025년 초에 이 팀을 만들었고, 목적을 deployment gap(모델이 할 수 있어 보이는 일과 사람이 실제로 믿고 쓸 수 있는 일 사이의 거리)을 메우는 것이라고 정의합니다. 글은 그 일을 네 가지 원칙으로 정리합니다. 결과부터 시작해 되게 만든 뒤 넓히고, 성공을 반복 가능하게 만들고, 모델이 아직 못하는 빈틈은 Research와 함께 닫고, 그 뒤에는 더 어려운 문제를 찾아 나선다는 것입니다. Codex(OpenAI의 코딩 에이전트)가 몇 달 걸려 만든 것을 한 번에 해내면 FDE는 무엇을 하느냐는 팀원의 질문에, 저자는 두 달마다 스스로 쓸모없어지면 팀이 제 역할을 하는 것이라고 답합니다.

OpenAI FDE 팀은 deployment gap을 메우기 위해 만들어졌고, 글은 그 일을 네 가지 원칙으로 정리합니다.

결과는 숫자로 나옵니다. 대형 반도체 회사에서는 FDE 약 15명이 10개 이상의 사례를 3~6개월 안에 운영에 올렸고, AI 테스트 생성으로 시간을 약 48% 줄였습니다. 이어 사례별 맞춤 앱을 Codex 중심의 공통 harness로 옮겨 맞춤 코드를 약 90% 없앴고, 첫 팀에 두 달 걸린 배포가 두 번째 팀에는 하루에 끝났습니다. 통신사 음성 상담에서는 운영 기준 eval이 6개월 동안 약 60%에서 90% 이상으로 올랐고, 회계법인용 Tax AI는 시범에서 신고서 7,000건을 처리하며 처리량을 약 50% 높였습니다. 저자가 말하는 이유는 하나입니다. 모든 프로젝트가 다음 프로젝트를 쉽게 만들어야 하고, 그 길은 제품에 흡수하거나, 모델을 개선하거나, 맞춤 작업을 줄이는 세 갈래입니다. 아래에서는 이 원칙을 메커니즘으로 풀고 사례를 재구성한 뒤, 우리 시범 사업을 같은 구조로 돌리는 eval 설계와 12주 일정을 덧붙였습니다.

원문이 밝힌 결과 수치. 모두 OpenAI가 발표한 값입니다.

핵심 메커니즘

Deployment Gap: 벤치마크 점수와 현장 신뢰 사이의 거리

deployment gap은 모델이 벤치마크나 데모에서 보여 주는 능력과, 현장 담당자가 매일 믿고 쓸 수 있는 수준 사이의 거리입니다. 저자는 FDE 팀의 존재 이유를 이 거리를 좁히는 것으로 둡니다. 거리는 데모에서 보이지 않습니다. 실제 데이터와 용어, 지연 시간과 정확도 기준, 기존 시스템과의 연결이라는 현장 제약을 통과시킬 때 드러나고, 그 크기는 운영 기준 eval 점수로 잽니다. 통신사 사례에서 모델이 범위 설정 단계에 약 60%를 받은 것이 gap을 숫자로 본 순간입니다.

gap은 둘로 나뉩니다. 제품이나 구현으로 메울 수 있는 gap은 FDE가 harness와 연결을 고쳐 닫고, 모델 자체가 아직 못해서 생기는 gap은 Research에 넘깁니다. 가상 예시로, 구매 부서가 계약서에서 지급 조건을 뽑는 시범이 데모에서는 잘 되다가 실제 계약서 300건에서 72%만 맞았다면, 이 28%p가 gap이고 실패 유형을 나눠 봐야 어느 쪽 gap인지와 다음 행동이 정해집니다.

deployment gap은 데모가 아니라 현장 제약을 통과한 뒤 운영 기준 eval 점수로 드러납니다.

Outcome First, Then Scale: 되게 만든 뒤에 넓힌다

팀의 핵심 가치는 결과에서 시작해, 되게 만드는 데 필요한 일을 다 하고, 그다음에 확장하는 순서입니다. 인상적인 데모는 운영에서 된다는 증거가 아니며, 기준은 OpenAI가 책임질 수 있는 수준으로 고객 문제를 푸는 것입니다. 반도체 사례에서 입사 며칠째인 FDE들이 검증팀에 들어가 칩 설계를 따로 공부하고, 고객 엔지니어와 함께 eval을 만들고, 사례마다 harness를 직접 지은 것이 되게 만드는 데 필요한 일이었습니다.

여기서 두 가지가 따라옵니다. FDE는 첫날부터 업계 전문가일 필요가 없지만 업계를 배우는 것은 FDE의 책임이며, 소프트웨어 만들기가 빨라질수록 고객 사업 이해가 더 중요해지므로 팀은 generalist와 도메인 전문가를 섞습니다. 그리고 확장은 운영에서 가치가 증명된 것에만 합니다.

순서가 핵심입니다. 데모가 아니라 운영에서 되는 것이 확인된 뒤에만 넓힙니다.

Common Harness: 맞춤 앱을 skill·plugin으로 바꿔 다음 팀에 하루에 넘기기

반도체 사례의 워크플로는 가치를 냈지만, 사례마다 통합 코드가 많아 다른 팀으로 옮기기 어려웠습니다. Codex가 좋아지자 FDE 한 명이 앱 하나를 Codex 중심으로 다시 지어 봤고, 팀은 모든 사례를 Codex를 핵심에 둔 공통 harness로 옮겼습니다. 사례별 맞춤 앱은 plugin(도구 호출과 출력 형식을 담은 확장)과 skill(업무 절차·프롬프트·판정 규칙을 담은 묶음)이 됐고, 사례마다 따로 있던 터미널 UI와 CLI는 Codex 하나로 대체됐습니다. 결과는 프로젝트마다 맞춤 코드 약 90% 제거입니다.

구조가 바뀌면 확장의 뜻도 바뀝니다. 새 팀에 넘기는 일은 그 팀에 맞는 connector나 MCP server(모델이 외부 도구·데이터에 접근하는 표준 연결)를 꽂고, 기존 skill로 그 팀의 eval을 새로 만들고, 돌리는 것으로 줄어듭니다. 핵심 기능은 공유 skill·plugin으로 묶여 AI CoE(AI Center of Excellence, 전사 AI 추진 조직)가 중앙에서 관리합니다. 2026년 8월의 한 사례에서 첫 배포에 두 달, 두 번째 팀 확장에 하루가 걸린 것이 이 구조의 효과입니다. 가상 예시로, 품질 부서의 불량 원인 보고서 초안 skill을 생산기술 부서로 넘길 때 바꾸는 것이 MES 연결과 그 부서의 eval 50건뿐이라면 이 구조가 작동하는 것입니다.

사례별 맞춤 앱을 공통 harness 위의 skill·plugin으로 바꾸면 다음 팀으로 옮기는 일이 연결과 평가만 남습니다.

Eval-Driven Gap Closing: 운영 기준 평가로 모델 빈틈을 정의하고 Research와 닫기

모델이 지금 할 수 있는 것만 만들면 Research가 다음에 닫아야 할 빈틈을 놓칩니다. 그래서 중요한 프로젝트는 종종 모델의 한계에서 시작하고, 고객·FDE·Research 셋이 함께 일합니다. 고객은 모델이 아직 못 푸는 문제에 매달리기로 약속하고, FDE는 플랫폼을 짓고 모델이 무엇을 해야 하는지를 요구 사항과 eval로 정의하며, Research는 그 능력을 개선합니다. 새 snapshot마다 고객 기준으로 다시 평가해 진행을 확인합니다.

통신사 음성 사례가 이 방식입니다. 함수 호출과 지시 이행이 약했고 운영 기준 eval은 약 60%였습니다. 6개월 동안 60%에서 80%로, 다시 90% 이상으로 올라 운영 기준에 닿았고, 그 음성 모델은 다른 상담 배포와 Presence(OpenAI의 기업용 음성·채팅 에이전트 제품)에도 쓰입니다. 우리 조직에 옮길 때 핵심은 eval이 모델의 한계를 벤더나 연구 조직에 전달하는 공용 언어가 된다는 점입니다.

모델 snapshot마다 같은 운영 기준 eval을 돌려 빈틈이 닫히는 것을 확인했습니다(6개월).

Self-Obsolescence: 두 달마다 스스로 쓸모없어지는 팀

저자는 FDE 팀이 두 달마다 스스로 쓸모없어지면 제 역할을 하는 것이라고 말합니다. 한 프로젝트의 결과물은 세 갈래로 돌아갑니다. 재사용 가능한 블록은 제품에 흡수되고(고객 배포에서 Swarm, Agents API를 거쳐 Presence가 된 경로), 모델이 못하던 것은 Research가 닫고, 남는 맞춤 작업은 skill·plugin으로 줄어듭니다. 그래서 다음 고객은 더 나은 출발점에서 시작하고, FDE는 더 어려운 문제로 옮겨 갑니다. 저자는 LLM 개발에서 대개 Occam’s Razor가 통한다고, 가장 단순한 해법이 최선이라고 덧붙입니다. 우리 조직에서는 이 원칙이 시범 사업의 완료 조건이 됩니다. 시범이 끝났다는 것은 운영에 올라갔다는 뜻이 아니라, 다음 팀이 가져다 쓸 skill·eval·연결 명세가 남았다는 뜻이어야 합니다.

한 프로젝트의 결과물이 제품·모델·skill 세 갈래로 돌아가 다음 고객의 출발점이 됩니다.

통념과 다른 주장

흔히 이렇게 봅니다현장 배치 엔지니어는 그 업계를 잘 아는 사람이어야 하고, 고객 맞춤 통합을 많이 해줄수록 가치가 크다.

저자는 이렇게 봅니다FDE는 첫날에 업계를 몰라도 되지만 배우는 것은 본인 책임이고, 팀의 성공은 두 달마다 스스로 쓸모없어지는 것, 즉 맞춤 작업을 없애는 데 있습니다.

근거반도체 사례에서 입사 며칠째인 FDE들이 검증팀에 들어가 칩 설계를 공부하며 10개 이상 사례를 운영에 올렸고, 그 뒤 공통 harness로 옮겨 프로젝트마다 맞춤 코드를 약 90% 없앴습니다.

흔히 이렇게 봅니다모델이 아직 못하는 일은 프로젝트를 미루고, 지금 되는 일부터 골라 도입한다.

저자는 이렇게 봅니다중요한 프로젝트는 종종 모델의 한계에서 시작합니다. 지금 되는 것만 만들면 다음에 닫아야 할 빈틈을 놓치기 때문입니다.

근거통신사 음성 사례에서 범위 설정 때 eval이 약 60%였지만, 고객·FDE·Research가 6개월 동안 snapshot마다 재평가해 90% 이상으로 끌어올렸습니다.

FDE의 가치는 맞춤 작업의 양이 아니라, 다음 팀이 더 쉽게 시작하도록 자기 일을 없애는 데 있습니다.

저자가 든 사례

대형 반도체 회사: 칩 검증을 AI 중심으로

상황: 반도체 업계에서 검증은 프로젝트 노력의 약 70%를 차지합니다. 2025년 중반, 고객은 검증 과정을 AI 중심으로 바꾸고자 했습니다.
한 일: FDE 약 15명이 directed test generation(목표를 정해 테스트를 생성), 근본 원인 분석과 디버깅, 아키텍처 어시스턴트 등 10개 이상 사례를 맡았습니다. 검증팀에 들어가 칩 설계를 공부하고, 고객 엔지니어와 함께 AI가 쓸모 있는 테스트를 만들고 고장을 바르게 진단하는지 재는 eval을 만들고, 사례마다 harness를 지었습니다.
결과: 3~6개월 안에 모든 사례가 운영과 초기 도입에 이르렀습니다. AI 테스트 생성으로 시간 약 48% 절감, 커널 최적화로 성능 중앙값 22% 향상, 수 주 걸리던 디버깅이 수 시간으로 줄었습니다(OpenAI 발표).
연결: Outcome First와 Deployment Gap의 사례이며, 이후 Common Harness 전환의 출발점입니다.

반도체 검증 사례. 수치는 OpenAI가 밝힌 것입니다.

대형 통신사: 음성 상담 모델의 빈틈 닫기

상황: 고객은 상담 플랫폼을 음성으로 넓히려 했습니다. 음성은 상담량의 약 90%였고 채팅보다 처리 비용이 높았으며, 억양·어조·지연·정확도를 운영 수준으로 맞춰야 했습니다. 범위 설정 때 모델은 운영 기준 eval에서 약 60%를 받았고, 약한 곳은 함수 호출과 지시 이행이었습니다.
한 일: FDE가 한계를 고객에게 설명하고 Research를 불렀습니다. FDE는 플랫폼을 짓고 모델 요구를 정의했고, Research는 능력 빈틈을 개선했으며, 새 snapshot마다 고객 기준으로 평가했습니다.
결과: 6개월 동안 약 60% → 80% → 90% 이상으로 올라 운영 기준에 닿았습니다. 원문의 Audio Big Bench 차트는 2024년 12월 65.6%에서 2026년 5월 92.29%까지 오른 다섯 snapshot을 보여 줍니다. 이 음성 모델은 다른 상담 배포와 Presence에도 쓰이며, Presence를 쓰는 한 고객은 전화의 절반 이상을 AI로 처리합니다.
연결: Eval-Driven Gap Closing과 Self-Obsolescence(제품 흡수)의 사례입니다.

통신사 음성 사례. 고객·FDE·Research 셋이 함께 모델 빈틈을 닫았습니다.

Thrive Holdings: 회계법인용 Tax AI

상황: Thrive Holdings와 함께 회계법인들의 세무 신고 처리를 맡았습니다. OpenAI의 FDE와 연구자가 엔지니어·회계사와 함께 일했습니다.
한 일: Tax AI를 만들었습니다. 임대 소득 신고 자동화는 엔지니어링과 실무자 검토를 거쳐 6주 만에 정밀도·재현율 90%에 이르렀습니다.
결과: 시범에서 신고서 7,000건을 처리하고 처리량을 약 50% 높였습니다(OpenAI 발표). 한 서식의 패턴이 다른 세무 서식에 재사용되고, 같은 접근이 부기·감사·IT 지원으로 넓어지고 있습니다.
연결: Outcome First(한 서식부터 운영 수준으로)와 Common Harness(재사용 패턴)의 사례입니다.

Tax AI 사례. 한 서식에서 만든 패턴이 다른 서식과 부기·감사·IT 지원으로 넘어갑니다.

John Deere: 농가 지원의 개인화

상황: John Deere의 See & Spray(카메라와 머신러닝으로 잡초에만 약을 치는 기술)는 약품 사용을 최대 70% 줄이지만, 농가가 장비를 설정하고 시즌을 계획하는 지원이 있어야 효과가 납니다.
한 일: OpenAI API로 농가가 자연어로 질문하고, 맞춤 설정 안내를 받고, 장비가 제대로 작동하지 않을 때를 알 수 있게 했습니다.
결과: 개인화 조언을 규모 있게 제공합니다. 수치는 원문에서 밝히지 않았습니다.
연결: Deployment Gap의 사례입니다. 기술은 있었고, 사람이 믿고 쓰게 만드는 지원이 과제였습니다.

John Deere 사례. 기술 자체(약품 최대 70% 절감)의 효과가 농가 지원에 달려 있다는 점에서 출발했습니다.

기술 디테일: 시범을 운영 기준으로 재고 다음 팀에 넘기려면

아래는 글의 메커니즘을 우리 조직에서 돌릴 때 필요한 설계로, AX Review가 새로 작성했습니다. 숫자와 필드명은 가상 예시입니다.

Deployment Gap을 숫자로 재려면(운영 기준 eval) 시범 범위를 정하는 첫 2주 안에 현업 담당자와 함께 eval 세트를 만듭니다. 케이스는 실제 입력(익명화)·기대 출력·판정 방식으로 구성하고, 사례당 최소 50건, 운영 전에는 200건 이상으로 늘립니다. 판정 방식은 정답 비교(exact), 항목 포함 여부(rubric), 다른 모델이 채점(llm_judge) 가운데 케이스마다 하나를 정하고, llm_judge의 채점 모델은 생성 모델과 다른 것으로 둡니다. temperature 0으로 같은 세트를 3회 돌려 결과가 갈리는 케이스를 따로 표시합니다. 운영 기준은 통신사 사례처럼 90% 이상으로 두되, 오류 비용이 큰 업무(지급·계약)는 severity별로 기준을 달리 둡니다.

{
  "case_id": "PROC-CT-0147",
  "use_case": "contract_payment_terms",
  "input_ref": "s3://evals/contracts/0147.pdf",
  "expected": {"net_days": 60, "early_discount_pct": 2.0},
  "grader": "exact | rubric | llm_judge",
  "severity": "high | medium | low",
  "runs": 3,
  "pass_rate": 0.67,
  "fail_type": "model | harness | data | none",
  "model_snapshot": "2026-10-15",
  "checked_at": "2026-10-20"
}

운영 기준 eval을 먼저 세우면 "모델 문제"와 "우리 구현 문제"를 점수로 가를 수 있습니다(가상 예시).

Common Harness로 다음 팀에 넘기려면 사례별 코드를 네 층으로 가릅니다. skill(업무 절차·프롬프트·판정 규칙), plugin(도구 호출·출력 형식), connector 또는 MCP server(팀별 데이터·시스템 연결), eval 세트(팀별 실제 입력)입니다. 앞의 둘은 AI CoE가 버전을 매겨 중앙 저장소에서 관리하고, 뒤의 둘만 팀마다 바꿉니다. 코딩 에이전트(Codex, Claude Code 등)를 공통 인터페이스로 삼으면 사례별 UI를 따로 만들 필요가 없습니다. skill마다 아래 manifest를 두고, 다른 팀으로 넘길 때 connectors와 eval_set만 바뀌는지 확인합니다. 두 번째 팀 확장에 걸린 날 수(second_team_days)와 팀별 맞춤 코드 비중(custom_code_ratio)을 분기마다 기록합니다.

{
  "skill": "defect-root-cause-draft",
  "version": "1.3.0",
  "owner": "ai-coe",
  "plugins": ["mes-query", "report-format-v2"],
  "connectors": ["mcp://mes.plant-a", "mcp://qms"],
  "eval_set": "evals/plant-a/defect-rca-v3",
  "pass_threshold": 0.9,
  "custom_code_ratio": 0.12,
  "second_team_days": 1
}

다음 팀에 넘길 때 바꾸는 것은 connector와 eval 두 가지뿐이어야 합니다.

모델 gap과 구현 gap을 가르려면 eval 실패를 세 가지로 분류합니다. 모델 gap(지시 이행, 함수 호출, 긴 문맥 처리처럼 모델 능력의 문제), 구현 gap(데이터 품질, 연결 오류, 프롬프트·harness 설계), 제품 gap(이미 있는 제품 기능으로 대체 가능). 실패 케이스 20건을 사람 둘이 독립적으로 분류해 일치율이 80% 이상이면 LLM 분류로 넘기고, 아니면 기준을 다시 씁니다. 모델 gap이 전체 실패의 절반을 넘으면 벤더·연구 접점에 eval 세트와 함께 전달하고 새 snapshot마다 재평가합니다. 구현 gap이 절반을 넘으면 harness를 고치고, 제품 gap이 늘면 맞춤 코드를 걷어 냅니다. 통신사 사례처럼 60%에서 시작한 모델 gap은 6개월 단위로 보되, 분기마다 10%p 이상 오르지 않으면 범위를 다시 정합니다.

실패를 모델·구현·제품 세 gap으로 나누면 누가 고칠지가 정해집니다(가상 예시).

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	12주 동안 하는 일
스폰서	현업 임원(사례를 쓰는 부서장)	운영 기준 승인, 두 번째 팀 지정
AI CoE 리드	AX 추진 조직 1명	skill·plugin 중앙 관리, 확장 판정
현장 팀 리드	첫 사례 부서 팀장 1명	eval 케이스 제공, 주 1회 결과 검토
FDE 역할	사내 엔지니어 2~3명 또는 파트너	harness·connector 구축, gap 분류
데이터·보안	IT·보안 담당 1명	connector 권한, 익명화 기준
벤더·연구 접점	모델 벤더 담당 1명	모델 gap 전달, snapshot 재평가

시작 전 준비물: 첫 사례의 실제 입력 50건 이상(익명화 완료), 현업의 판정 기준(무엇이 맞은 답인지), 연결할 시스템 목록과 접근 권한, 두 번째 팀 후보와 데이터 차이 메모, 코딩 에이전트와 MCP server를 쓸 수 있는 환경.

주차	할 일	산출물
1~2주	범위 정의, eval 50건 작성, 기준선 측정	eval 세트 v1, 기준선 점수
3~8주	harness 구축, 주 1회 eval, gap 분류·대응	운영 배포, eval 200건
9~10주	skill·plugin·connector·eval로 분리, manifest 작성	재사용 묶음 v1
11~12주	두 번째 팀에 확장, 걸린 날 수와 맞춤 코드 비중 기록	확장 보고서, 판정

12주 일정(예시). 두 번째 팀 확장에 걸린 날 수가 이 프로그램의 성적표입니다.

현장 인터뷰 질문(현장 팀 리드와 FDE용): 이 업무에서 맞은 답은 누가 어떻게 판정합니까? 지금 사람이 하면 시간과 오류율은 얼마입니까? 데모가 실패하는 입력은 어떤 유형이고, 모델 탓입니까, 데이터나 연결 탓입니까? 이 결과물을 가져다 쓸 두 번째 팀은 어디이고, 그 팀의 데이터는 무엇이 다릅니까? 운영에 올린 뒤 결과를 누가 매주 봅니까?

진행 판정 기준(예시): 운영 기준 eval이 90% 이상으로 2주 연속 유지되고, 두 번째 팀 확장이 5영업일 안에 끝나고, 팀별 맞춤 코드 비중이 30% 미만이면 세 번째 팀으로 넓힙니다. eval이 60% 미만에 8주 넘게 머물면 모델 gap으로 보고 벤더·연구 접점과 범위를 다시 정합니다. 두 번째 팀 확장에 3주 이상 걸리거나 사례마다 harness를 새로 만들고 있으면 확장을 멈추고 skill·plugin 분리를 먼저 끝냅니다.

판정 기준(예시). 숫자는 조직 상황에 맞게 정합니다.

AX 적용 제언. 이 글이 가장 쓸모 있는 곳은 시범 사업이 여러 개 돌아가는데 운영에 올라간 것은 적고, 올라간 것도 다른 부서로 퍼지지 않는 조직입니다. 제조 대기업의 품질·생산기술, 금융사의 심사·상담, 그룹사 공통의 구매·법무가 그렇습니다. 순서는 운영 기준 eval → 한 사례를 운영까지 → skill·plugin 분리 → 두 번째 팀 확장이 무난하고, 시범 사업의 완료 조건에 다음 팀이 쓸 수 있는 묶음을 넣는 것이 첫 변화입니다. 외부 FDE나 파트너에는 harness 구축과 gap 분류를 맡기고, eval 작성과 skill 관리(AI CoE)는 사내에 남기면 파트너가 빠진 뒤에도 구조가 남습니다. 모델 gap은 요구 사항 문서가 아니라 eval 세트로 벤더에 전달해야 snapshot마다 같은 잣대로 진행을 확인할 수 있습니다.

원문 사례

항목	내용
발표처	OpenAI 블로그, 2026.10.22, Colin Jarvis(Head of Forward Deployed Engineering)
팀	FDE 팀은 2025년 초 설립. 목적은 deployment gap 메우기
네 원칙	결과부터 시작 · 성공을 반복 가능하게 · 모델 빈틈을 Research와 닫기 · 더 어려운 문제 찾기
반도체	2025년 중반, FDE 약 15명, 10개 이상 사례, 3~6개월 안에 운영. 시간 약 48% 절감, 성능 중앙값 22% 향상, 디버깅 수 주 → 수 시간
공통 harness	Codex 중심으로 재구성, 맞춤 코드 약 90% 제거, 첫 배포 두 달 → 두 번째 팀 하루(2026년 8월 사례)
통신사	음성이 상담의 약 90%. eval 약 60% → 80% → 90%+(6개월). Audio Big Bench 65.6%(2024.12) → 92.29%(2026.5)
Presence	Swarm → Agents API → Presence. 한 고객은 전화 절반 이상을 AI로 처리
Thrive Holdings	Tax AI, 시범에서 7,000건 처리, 처리량 약 50%↑, 임대 소득 서식 6주에 정밀도·재현율 90%
John Deere	See & Spray(약품 최대 70% 절감) 사용 농가에 API 기반 개인화 지원
함께 본 자료	OpenAI 고객 사례 “Uber uses OpenAI to help people earn smarter and book faster”(2026.5.6): 운전자용 Uber Assistant, 작은 모델과 추론 모델을 나눠 쓰는 multi-agent 구조, 안전·환각을 거르는 AI Guard, Realtime API 음성 예약. AI 역량이 중앙 조직이 아니라 엔지니어링·제품·법무·운영 팀에 퍼져 있다고 밝힘

핵심 개념

harness: 모델을 감싸 도구·데이터·평가를 붙이고 실제 업무 흐름 안에서 돌리는 실행 틀.
eval: 실제 입력과 기대 출력으로 모델·시스템이 운영 기준을 넘는지 재는 평가 세트.
skill / plugin: skill은 업무 절차·프롬프트·판정 규칙 묶음, plugin은 도구 호출·출력 형식 확장. 코딩 에이전트 위에서 공유된다.
MCP server / connector: 모델이 외부 도구·데이터에 접근하는 표준 연결. 팀을 바꿀 때 교체하는 부분.
model snapshot: 특정 시점에 고정된 모델 버전. 같은 eval로 snapshot마다 비교한다.
Presence: OpenAI의 기업용 음성·채팅 에이전트 제품. 고객 배포에서 나온 블록을 흡수해 만들어졌다.

내 메모

TODO: 내 생각 추가

원문: Colin Jarvis, “What FDE means at OpenAI”(OpenAI 블로그, 2026.10.22). 요약·메커니즘·통념과 다른 주장·사례는 원문에 실린 내용을 AX Review가 다시 정리했고, 수치는 모두 OpenAI가 발표한 값입니다. 함께 본 자료로 OpenAI 고객 사례 “Uber uses OpenAI to help people earn smarter and book faster”(2026.5.6)를 읽었으며, 그 내용은 원문 사례 표에만 적었습니다. 기술·현업 디테일, JSON 예시, eval·gap 분류 기준, 12주 일정, 판정 기준, 인포그래픽, 표는 새로 작성한 것이며 숫자와 필드명은 가상 예시입니다. 원문 전체는 OpenAI 블로그에서 볼 수 있습니다.