데일리 · 기사 03 · 5 분 읽기
- OpenAI
OpenAI가 설명한 FDE AI 시연을 실제 업무로 옮기는 일
10월 22일자 공식 발표 · 10월 23일 06시 취재 재확인
요약·개요
OpenAI가 10월 22일 FDE 팀의 일하는 방식을 공개했습니다. 고객과 함께 업무를 익히고, AI가 현장에서 일을 해낼 수 있는지 시험한 뒤, 다른 팀도 쓸 수 있는 형태로 만드는 엔지니어들입니다. 반품 처리 예시로 시연에서 실제 운영까지 필요한 연결을 풀어봅니다.
가게 사장님이 AI에게 반품 문의를 보여줬더니 답장을 꽤 잘 씁니다. 이제 직원 대신 맡겨도 될까요? 실제로 돈을 돌려주는 순간까지 가려면, 그 답장 밖에 있는 일도 이어야 합니다.
핵심 팩트
ChatGPT와 코딩 도구 Codex를 만드는 OpenAI가 10월 22일자 글에서 FDE 팀의 방식을 설명했습니다. FDE는 Forward Deployed Engineering의 약자로, 고객과 함께 어려운 업무를 풀고 그 경험을 제품·연구팀에 전달하는 현장 엔지니어링입니다. 새 모델 출시 소식이 아니라 기업의 AI 도입 과정에 관한 설명입니다.22일 공식 글
기업용 안내에는 업무 파악, 시제품 제작, 평가, 실제 운영 연결, 다른 팀으로 확대하는 과정이 나옵니다. 이미 기존 AI 기능으로 해결할 수 있는 일에는 보통 FDE가 필요하지 않다고 설명합니다.기업용 FDE 안내
1. 답장을 잘 쓰는데, 무엇이 더 필요할까?
AI 모델은 주어진 내용을 바탕으로 문장이나 판단을 만들어내는 부분입니다. 모델에 “친절하게 답해줘”라고 지시하는 문장이 프롬프트입니다. 그런데 가게 업무에는 주문 기록, 반품 규정, 돈을 돌려줄 권한도 필요합니다. 문장을 잘 만드는 능력만으로는 누가 산 물건인지, 이미 환불했는지를 알 수 없습니다.
아래부터는 가상의 온라인 가게 ‘소라상점’을 예로 듭니다. 고객이 “어제 산 옷을 반품하고 싶다”고 보냈습니다. AI는 “반품을 도와드리겠습니다”라는 답장을 쓸 수 있지만, 실제 처리는 다음 질문에 답해야 끝납니다.
| 가게에서 필요한 것 | 빠져 있을 때 생기는 문제 |
|---|---|
| 문의한 사람과 주문을 연결하기 | 다른 사람의 주문을 잘못 조회할 수 있음 |
| 구매 날짜와 반품 규정 확인하기 | 반품할 수 없는 물건도 가능하다고 안내할 수 있음 |
| 이전 환불 기록 보기 | 같은 주문에 돈을 두 번 돌려줄 수 있음 |
| 처리 책임자와 승인 방법 정하기 | 잘못 처리됐을 때 멈추거나 바로잡을 사람이 모호함 |
고양이와 풀어보기 Q&A
고양이 연구원그 내용을 전부 프롬프트에 길게 적어주면 되지 않아?
포켓 노트규정 설명은 넣을 수 있어. 하지만 방금 바뀐 주문 상태를 읽거나 환불을 실행하려면 실제 업무 시스템과 연결해야 해. 누가 어떤 정보와 기능을 쓸 수 있는지도 정해야 하고.
2. 주문 조회부터 실제 환불까지
소라상점은 처음에는 AI가 주문을 읽고 답장 초안만 쓰게 하기로 했습니다. 직원이 내용을 보고 환불을 승인하면, 결제 시스템이 실제 처리를 합니다. 여기서 ‘도구’는 AI가 요청할 수 있도록 연결해 둔 주문 조회 같은 기능입니다. AI가 도구 사용을 제안하더라도, 실행을 허용할지는 시스템이 정한 권한과 절차로 판단해야 합니다.
주문 시스템에 접속할 수 없거나 구매자를 구별하지 못하면, 이 예시에서는 처리 중이라고 꾸미지 않고 직원에게 넘깁니다. 환불 버튼을 누른 뒤 응답이 끊겨도 같은 주문을 다시 환불하지 않도록 처리 기록을 확인하는 절차가 필요합니다. 이런 실패 상황도 업무의 일부입니다.
고양이와 풀어보기 Q&A
- 고양이 연구원
승인을 직원이 하면 자동화 효과가 별로 없는 거 아냐?
포켓 노트조회와 초안 작성만 줄여도 직원이 판단에 집중할 수 있어. 처음부터 돈을 움직이는 권한까지 맡길 필요는 없어. 어디까지 맡길지는 실패했을 때의 피해와 점검 결과를 보고 넓히면 돼.
3. ‘잘되는 것 같다’를 어떻게 시험할까?
AI 평가, 즉 eval은 실제로 맡길 일을 정해 놓고 결과를 비교하는 시험입니다. OpenAI의 평가 안내도 업무에 맞는 사례와 사람의 판단을 함께 쓰고, 변경 뒤에 계속 시험하라고 권합니다.평가 설계 안내
소라상점의 연습용 자료를 가정해 보겠습니다. 일반 반품 20건과 주문 번호 누락·이미 환불된 주문 같은 예외 10건, 합계 30건입니다. 아래 결과는 계산을 설명하기 위한 가상 값이며 제품을 실행해 얻은 수치가 아닙니다.
| 같은 30건으로 비교 | 초안 A | 수정한 초안 B |
|---|---|---|
| 일반 20건 중 규정과 맞는 답 | 19건 | 18건 |
| 예외 10건 중 올바르게 처리·이관 | 4건 | 9건 |
| 합계 | 23/30건, 약 76.7% | 27/30건, 90% |
합계는 A가 (19 + 4) ÷ 30, B가 (18 + 9) ÷ 30입니다. B의 비율이 높아졌지만 일반 문의의 정답은 한 건 줄었습니다. 전체 점수와 함께 어떤 업무가 나빠졌는지도 봐야 합니다. 특히 다른 사람의 정보를 보여주거나 두 번 환불하는 오류는, 평균 점수가 높더라도 운영을 막는 조건으로 따로 정할 수 있습니다.
고양이와 풀어보기 Q&A
- 고양이 연구원
B가 90%면 이제 고객에게 바로 써도 돼?
포켓 노트이 30건에서 나온 결과만으로는 부족해. 어떤 세 건을 틀렸는지, 실제 문의에서도 같은 결과가 나오는지 봐야 해. 이 예시의 90%는 합격선이 아니라 두 초안을 비교하는 숫자야.
4. 다른 가게에 옮길 때 남길 것
첫 가게에서 처리 흐름을 만들었다면, 다음 가게에서는 어디까지 다시 만들어야 할까요? 주문을 읽는 연결, 권한 확인, 처리 기록은 함께 쓸 수 있어도 반품 기한과 예외 규정은 가게마다 다를 수 있습니다. 재사용할 부분과 현장에서 다시 확인할 부분을 나누면 두 번째 도입의 출발점이 달라집니다.
| 함께 쓸 수 있는 기반의 예 | 새 가게에서 다시 확인할 것 |
|---|---|
| 주문 조회 기능의 연결 방식 | 주문 데이터의 위치·항목·접근 권한 |
| 승인과 처리 기록을 남기는 틀 | 누가 얼마까지 승인할 수 있는지 |
| 문의 사례를 반복 시험하는 도구 | 그 가게의 규정과 실제 예외 사례 |
OpenAI가 든 실제 사례에는 반도체 팀의 테스트 생성과 오류 원인 분석이 있습니다. 칩 설계가 의도대로 작동하는지 시험할 코드 등을 만드는 일입니다. 회사는 이 업무의 개별 구현을 Codex 중심의 공통 기반으로 옮겼다고 설명합니다.현장 사례
그 사례의 성과를 다른 회사의 예상 절감률로 쓰기는 어렵습니다. 소라상점 같은 작은 팀이라면 우선 기존 도구로 한 가지 업무를 해결할 수 있는지부터 보는 편이 현실적입니다.
고양이와 풀어보기 Q&A
- 고양이 연구원
우리도 먼저 FDE를 계약해야 시작할 수 있는 거야?
포켓 노트아니, 기존 도구로 할 수 있는 작은 일부터 시작할 수 있어. 예를 들어 외부 발송 권한 없이 반품 답장 초안만 만들어 직원이 검토하게 하는 거야. 실제 고객 정보를 쓰기 전에는 회사의 데이터 이용 규칙과 도구의 계약 조건을 먼저 봐야 해.
마무리
답장 다음에 일어나는 일
소라상점에서 직원에게 필요한 것은 “친절한 답장이 나왔다”는 보고보다 “어느 주문을 어떤 규정으로 판단했고, 누가 승인했는가”라는 기록입니다. AI를 업무에 넣는 설계는 그 다음 장면까지 이어져야 합니다.
출처
- 현장 사례openai.com
- 기업용 FDE 안내openai.com
- 평가 설계 안내developers.openai.com