What FDE means at OpenAI

OpenAI 블로그 글의 앞부분부터 반도체 고객 사례와 Codex 전환까지 읽고 옮겼어요. 글의 마지막 부분은 읽지 못했어요.

FDE는 스스로를 쓸모없게 만드는 팀

Codex가 나왔을 때 팀원 한 명이 물었대요. "몇 달 동안 만든 유스케이스를 Codex가 한 번에 해내면 우린 뭘 하죠?" Colin Jarvis는 이 질문이 OpenAI FDE의 핵심을 짚는다고 말해요. FDE는 고객 곁에서 가장 어려운 문제를 이해하고 믿고 쓸 수 있는 솔루션을 만들며, 그 과정에서 배운 것이 제품을 다듬고 Research에 구체적인 문제를 줘요. 몇 달마다 스스로를 쓸모없게 만든다면 일을 잘하고 있는 것이라는 거예요.

그는 2025년 초 "배포 격차(deployment gap)", 즉 모델이 할 수 있어 보이는 것과 사람들이 업무에 안정적으로 쓸 수 있는 것 사이의 거리를 좁히려고 팀을 만들었어요. 모델 능력이 그걸 쓰는 시스템과 절차보다 빨리 발전했고, 빠진 조각은 때로 제품이고 때로는 현실의 변수와 제약이에요.

사례: John Deere

200년 된 농업 기업 John Deere의 과제는 농민에게 맞춤 조언을 대규모로 주는 것이었어요. 카메라와 머신러닝으로 잡초만 골라 뿌려 약제 사용을 최대 70% 줄이는 See & Spray 같은 기술도, 농민이 설정하고 시즌을 계획하고 조건에 맞춰 조정할 줄 알아야 효과가 나요. John Deere는 OpenAI API로 자연어 질문 응답, 맞춤 설정 안내, 장비가 제 성능을 못 낼 때 알려 주기 등을 구현했어요.

원칙: 결과 먼저, 확장은 나중

매 FDE 세션 첫 슬라이드에는 이 가치가 있대요. "결과에서 시작하고, 성공에 필요한 걸 하고, 그다음에 확장한다." 인상적인 데모는 실제로 작동하느냐는 질문 전까지 꽤 멀리 가지만, FDE의 일은 프로덕션에서 책임질 수 있는 수준으로 고객 문제를 푸는 거예요.

사례: 대형 반도체 고객

2025년 중반 FDE 약 15명이 대형 반도체 고객과 10개 이상의 유스케이스로 검증(verification) 과정을 AI 네이티브로 바꾸는 일을 했어요. 이 업계에서 검증은 프로젝트 노력의 약 70%를 차지할 수 있대요. 입사 며칠 된, 반도체 경험이 없는 FDE도 고객 검증 팀에 들어가 칩 설계를 공부하고 엔지니어와 함께 평가(eval)를 만들었어요. 처음 3~6개월 안에 모든 유스케이스가 프로덕션에 올라갔고 결과는 이랬어요.

• AI 기반 지향 테스트 생성으로 약 48% 시간 절약
• 커널 최적화로 성능 중앙값 22% 향상
• 몇 주 걸리던 디버깅을 몇 시간으로 단축

최고 하드웨어 책임자가 "여기 오기 전에 칩 설계자였냐"고 물었대요.

Codex 중심으로 다시 짓기

문제는 유스케이스마다 맞춤 통합이 너무 많아 다른 팀으로 넓히기 어렵다는 점이었어요. 그사이 Codex가 강해졌고, 한 FDE가 애플리케이션을 Codex 중심으로 다시 짓는 실험을 했어요. 맞춤 앱은 공통 Codex 프리미티브 위의 플러그인과 스킬이 됐고, Codex가 인터페이스가 되면서 유스케이스별 터미널 UI와 CLI를 없앴어요.

• 프로젝트마다 맞춤 코드의 약 90%를 제거했어요.
• 2026년 8월 사례에서는 첫 배포에 두 달이 걸렸지만 두 번째 팀으로 넓히는 데는 하루가 걸렸어요.

글쓴이는 이것이 스스로를 쓸모없게 만드는 한 방식이라며, LLM으로 빠르게 만들고 그 속도로 사용자에게 가치를 전한 뒤 현실에서 버티는 걸 배워 확장하는 순서가 중요하다고 강조해요.