🚀 OpenAI는 이렇게 ChatGPT를 만듭니다

오늘도 창작의 경계를 실험하는 오리너, 구독자님 안녕하세요!

이번 레터는, AI 시대의 스카치테이프이자 3M, OpenAI가 어떻게 ChatGPT를 만들고 있는지 이야기하려고 합니다. 산업을 막론하고 어떻게든 AI를 제품에 붙이려고 하는 시대에, 가장 명확한 기준점이 ChatGPT 개발일테니까요.

OpenAI는 어떻게 그렇게 빠른 속도로 업데이트를 하는지 저는 늘 궁금했었는데요, 이 인터뷰를 보고 정리하면서 어느정도 선명해졌습니다. 제품과 기획에 대한 교과서적 원칙과 문화를 말만 하는게 아니라 정말 지키고 있기 때문이라는것을요.

OpenAI의 CPO 케빈 웨일(Kevin Weil)이 제품 개발 방식과 조직 운영 방식을 이야기한 인터뷰 내용을 바탕으로 시리즈로 구성해봤습니다. 

💡 끝부분에는 OpenAI의 개발 철학을 기반으로, AI 시대의 제품을 만드는 우리가 생각해야할 체크리스트까지 보너스로 마련해보았습니다

<OpenAI CPO가 말하는 AI 시대 프로덕트>

📌 1편 – OpenAI는 이렇게 ChatGPT를 만듭니다

📌 2편 – AI 시대의 PM의 역할은 예전과 다릅니다 (준비중)

🧭 이 글은 이런 분께 도움이 될 거예요

💎 이런 아싸이트를 드릴게요

성능이 기능보다 먼저

기획의 시작은 문제발굴에서 시작해서 기능으로 해결합니다. 프로덕트 기획의 정석인데요. 

OpenAI는 모델이 프로덕트인 회사이기 때문에, 모델과 작업의 핏을 먼저 생각합니다.

📌 OpenAI의 프로덕트 개발은 기존과 이렇게 다릅니다.

Eval → Launch → Iterate

1️⃣ Eval – 모델부터 테스트한다

OpenAI에서 프로덕트 기획을 할 때 시작하는 단위는 기능이 아니라 성능 측정(Evaluation = Eval)이라고 합니다. AI 기획 실무를 다루지 않는 분들에게는 조금 생소하죠.

이걸 "수치로 테스트"하는 게 Eval (Evaluation)입니다. 일종의 AI용 유닛 테스트죠. 기획서를 쓰기 전에 먼저, AI 모델이 이걸 ‘잘할 수 있는지’를 수치로 확인하는 겁니다.

📌 ChatGPT의 ‘Deep Research’ 기능을 만들 때는 이렇게 Eval을 구성했다고 해요.

📌 예를 들어, 게임 NPC에 AI를 붙였다고 한다면

NPC에게 "왜 이 마을에 혼자 살아?"라고 물었을 때

📌 정확도에 따라 기획 전략도 달라집니다.

GPT가 60% 맞출 때, 95% 맞출 때, 99.5% 맞출 때 기획 전략은 완전히 달라지게 됩니다. 정확도가 낮으면 보완 UX가 필요하고, 정확도가 높아질수록 기능 자체의 위치가 ‘보조’에서 ‘핵심’으로 올라갑니다.

📌 모델 중심 구조를 위한 기획서

모델 중심 구조 설계를 위해 기획서도 Eval을 기준으로 작성하게 됩니다.

2️⃣ Launch – 일단 내고 본다

Eval에서 일정 기준을 통과하면 바로 출시한다고 합니다. 완벽하지 않아도 괜찮습니다.

왜냐하면 OpenAI는 “출시 이후에 진짜 학습이 시작된다”고 믿기 때문입니다.

이건 내부 테스트로 절대 알 수 없습니다. 사회적 반응이야말로, 가장 중요한 데이터니까요.

3️⃣ Iterate – 사용자와 함께 학습한다

출시하고 나면, 이제 주인공은 사용자입니다.

신선한 건, 이 과정을 반복할수록 프로덕트는 진화하지만 기획서는 바뀌지 않아도 된다는 것인데요.

의도된 실패를 기획하는 실험 문화

앞서 OpenAI의 프로덕트 개발 방식이 “Eval → Launch → Iterate” 구조라는 이야기를 했습니다. 모델의 능력부터 확인하고, 빠르게 내고, 사용자 반응으로 학습한다는 구조죠.

그런데 “일단 작게 만들고 빨리 내보자”는 접근은 MVP, 린, 애자일 개발 방법론으로 우리에게도 익숙한 소립니다.

다만, OpenAI는 “기능을 작게 쪼개는 것”이 아니라, “애초에 실패를 전제로 한 학습 구조”를 먼저 설계한다는 측면에서 차이를 만듭니다.

즉, 실패는 계획된 것이며, 관측을 통해 업데이트하는거죠.

OpenAI의 제품 철학: Iterative Deployment – 실패를 설계에 포함시키는 문화입니다.

-를 확인하기 위해 일단 출시하고, 사용 패턴과 반응을 참고해서 개선합니다.

📌 실패가 아니라 실험

2025년 3월 25일 GPT-4o 이미지 생성 모델 출시 전, OpenAI 내부에선 “밈이 터질 것 같다”는 확신이 있었다고 합니다.

하지만 어떤 스타일이 밈이 될지, 사람들이 어떤 용도로 쓸 지 아무도 몰랐습니다.

이건 내부 테스트에선 절대 발견할 수 없는 플로우였다고 합니다.

📌 OpenAI는 어떤 지표로 성공을 판단할까?

OpenAI는 사용자 행동보다 모델의 학습 지표, 사용자 반응 다양성, Prompt 적응력, 실패 복구율 같은 비정형 지표를 봅니다. ‘모델을 얼마나 잘 훈련시켰나’가 성과가 된다는 이야기예요.

PM 20명으로 8억 유저 서비스를 만드는 문화

OpenAI 전체 인원은 약 500명이고, 이 중 PM은 20명 남짓이라 합니다. 다른 테크 기업과 비교하면 터무니없이 적은 숫자죠. 그래도 문제없이 매주 새로운 기능을 출시하고, 유저 피드백을 반영해 빠르게 프로덕트를 고도화합니다.

PM이 없이도 빠른 AI 흐름을 선도하기 위한 OpenAI의 의도적인 조직 설계 때문입니다.

📌 PM이 많을수록 속도가 느려질 수 있다?

일반적으로 PM은 ‘조율하는 사람’이라고 여겨집니다.

OpenAI는 이 조율 자체가 “속도를 늦추는 병목”이 될 수 있다고 봅니다. PM이 다 챙기면, 나머지는 기다리게 되고, 판단하지도 않게 되며, 실행 속도를 느리게 만든다는거죠. PM의 역할이 분산되는 이유는 정답이 없는 AI 제품의 본질 때문이기도 합니다. PM 혼자서는 모든 흐름을 통제할 수 없다는거죠.

PM은 최소한만 두되, 모든 팀원이 직접 판단하고 실행할 수 있도록 설계합니다.

1️⃣ 느린 결정보다 빠른 실행

OpenAI 내부에는 이런 말이 있습니다:

완벽한 정답보다 빠른 실행이 중요하다.

모델 성능이 매일 바뀌는 환경에선 기다리다 놓치는 기회가 더 크다는 거죠. 그렇기 때문에 “불확실한 상태에서 일단 실행”을 전제로 움직입니다.

일단 내보고 반응을 보는 구조가 기본입니다.

2️⃣ 책임자는 꼭 정해진다

빠르게 움직이려면, 그만큼 책임도 명확해야 하겠죠.

그래서 OpenAI는 아무리 작은 일이라도 ‘오너’를 지정합니다. PO처럼 특정 직무나 직급이 있는게 아니라, 역할의 문제입니다. 기획자라는 타이틀보다, 기획자처럼 사고하고 책임지는 태도가 중요하다는 거죠.

3️⃣ 모두가 기획하는 조직 문화

PM이 적다고 해서 기획이 딸리는 것은 아닙니다. OpenAI는 ‘기획’을 직무가 아닌 태도로 보기 때문입니다. OpenAI는 Product-Minded 문화라고 부릅니다.

직무를 막론하고 누구나 제품을 중심으로 사고할 수 있어야 한다는 것이죠. 문제를 찾고, 사용자와 모델을 연결하는 구조를 만들 수 있다면 ‘기획자’가 됩니다.

4️⃣ 채용 기준도 다르다 – Product Sense + High Agency

OpenAI는 채용할 때 직무와 상관없이 프로덕트를 기반으로 사고하는 감각과, 누가 시키지 않아도 알아서 움직일 줄 아는 성향을 가장 중요하게 봅니다. 개발자라도 기획적 역량이 있어야 하고, 때로는 사업적으로 밀어붙일 수도 있어야 하는거죠.

📌 Product Sense

📌 High Agency

“누가 시키지 않아도 판단하고 움직이는 힘”입니다.

이런 능력을 갖춘 사람들이 모이면 PM 없이도 팀이 스스로 굴러갈 수 있게 됩니다.

📌 실제 사례: Deep Research 기능

ChatGPT의 Deep Research 기능을 만들 때 특히 모든 과정을 연구 인력, 개발자, PM이 함께 Eval을 만들고, 모델을 개선하고, UX 흐름을 실험했습니다. 전원이 기획자로 움직인 셈이죠. 전형적인 스펙 문서 없이 시작됐다고 하네요.

📌 그럼 PM은 뭘 하나요?

OpenAI CPO 케빈웨일은 PM의 역할을 "결정의 흐름을 만드는 사람"으로 정의합니다.

채팅 인터페이스를 선택한 이유

AI UX에 대해 이야기할 때, 채팅 인터페이스가 적절한 것인지에 대해서는 의견이 다양합니다. 슬래시 명령어나, 버튼과 같이 약간의 제약을 둬야 한다는 이야기들도 있구요. 

일리있는 말입니다. 그리고 OpenAI도 그걸 잘 알고 있습니다. 그럼에도 불구하고 OpenAI가 여전히 채팅 인터페이스를 핵심 구조로 유지하는 이유는, 그게 가장 인간적인 인터페이스이기 때문입니다.

📌 채팅은 기술이 아니라, 인간의 방식입니다

OpenAI는 채팅을 AI와 협업하는 가장 원초적이고도 직관적인 방법으로 보고 있어요. 그래서 기능을 더해도, 버튼을 붙여도, 기본 인터페이스는 여전히 ‘대화’를 베이스로 잡고 있습니다.

OpenAI는 그래서 채팅을 단순한 입력창이 아니라, 모델과 사용자, 행동이 연결되는 시작점으로 보고, 사용자의 행동을 유도하는 설계를 합니다.

프롬프트는 모두가 다뤄야할 UX 디자인

OpenAI에는 ‘프롬프트 엔지니어’라는 직무가 따로 없습니다. 대신 모든 팀원이 프롬프트를 다룹니다. 기획자도, 디자이너도, 개발자도, ML 엔지니어 할 것 없이 전부 다요. 프롬프트는 특정 역할이 아니라 조직 전체가 다루는 설계 언어입니다.

📌 프롬프트가 곧 UX입니다

우리가 UX에 대해 생각할 때, 일반적으로 버튼 위치, 플로우, 디자인 요소와 같은 것으로 생각합니다. 그런데 AI와 대화하는 서비스의 흐름을 생각하면 문장의 중요도는 매우 올라갑니다. 말투, 길이, 구조, 뉘앙스 하나가 결과를 좌우하기 때문이죠.

때문에 OpenAI는 프롬프트를 UX 디자인의 일부로 간주합니다.

전부 말은 비슷해도, 결과는 다 다릅니다. 사용자가 느끼는 경험도 달라질겁니다. AI에서는 입력된 문장의 사소한 뉘앙스 하나에도 반응이 완전히 달라지기 때문입니다. 

그래서 프롬프트를 생각할 때 고민을 해야 합니다.

📌 팀마다 다른 프롬프트는, 모델을 헷갈리게 합니다

기능 하나에도 수많은 프롬프트가 쓰입니다.

그런데 팀마다 따로 짜면 모델은 일관된 응답을 주지 못합니다. 결국 유저는 어떤 부분에서 틀어졌는지 파악하지 못하고, 피드백도 흐려집니다.

그래서 OpenAI는 프롬프트를 팀 전체가 공유하는 협업 언어로 다룹니다. 

📌 GPT-4V의 이미지 인터프리터

GPT-4V는 이미지를 읽고 설명하는 기능입니다.

이 기능을 만들면서 어떻게 질문을 해야 가장 유용한 답이 나오는지 직군에 상관없이 실험을 반복했다고 합니다.

이런 사소한 차이 하나하나가 모델의 반응을 크게 바꿨기 때문입니다. 그래서 직무 구분 없이, 모두가 프롬프트를 반복해서 실험하고 조정했습니다.

실패를 수용하는 인터페이스 설계

OpenAI는 실패를 전제로 프로덕트를 설계한다고 언급했는데요. UX에도 역시 마찬가지입니다.

틀릴 걸 알고, 드러내고, 인정하고, UX에 녹여서 대화로 설계한다는 점이 기존 프로덕트와 확실히 다른 점입니다.

📌 실패를 피할 수 없다면, 보여줘라

기존 UX는 정확한 작동을 가정하고 설계합니다. 버튼을 누르면 결과가 나와야 하고, 입력하면 정확히 처리되어야 하죠. 하지만 GPT는 정확하게 작동하지 않습니다.

👉 그렇다면 “틀릴 수 있다”는 걸 사용자에게 알려야 합니다.

📌 OpenAI가 택한 방식: Fail-soft UI

1️⃣ 모델이 자신 없어 할 때, 직접 말하게 한다

예: “이건 제 추정이긴 하지만요…” → 불확실성을 디자인이 아닌 언어로 노출

2️⃣ 출처를 명시한다

예: “이 정보는 [링크]를 기반으로 요약했습니다.” → 신뢰 판단을 사용자가 하도록 돕는 구조

3️⃣ 되묻기 UX를 활용한다

예: “이 질문이 맞나요?” “다시 요약해드릴까요?” → 모델의 불확실성을 인터랙션으로 보완

4️⃣ 선택지를 제시한다

예: “이런 답변도 있어요” “다른 버전 보기” → 하나의 답이 아닌, 탐색 가능한 응답을 제공

📌 ChatGPT의 ‘다시 시도하기(Regenerate response)’ 버튼

ChatGPT를 쓸 때, 많은 사람들이 “다시 시도하기(Regenerate response)” 버튼을 자주 누릅니다.

사실 우리는 이미 알고 있습니다. AI는 항상 정답을 주지 않습니다. 그래서 이 버튼은 단순한 리셋 기능이 아니라, AI의 불완전함을 받아들일 수 있게 도와주는 설계입니다.

실수했을 수도 있다는 가능성을 남기고, 그 실수를 다시 시도해볼 수 있는 선택지를 주는 것이죠.

📌 실패를 수용하는 인터페이스가 가져다주는 것

모델 선택도 전략적으로

하나의 모델이 모든 걸 해결해주면 좋겠지만, 현실은 모델마다 장단이 존재합니다. 모델을 하나만 쓸 경우, 오답도, 비용도 통제하기 어렵습니다.

👉 그래서 OpenAI는 작업의 특성에 따라 모델을 나눠 배치합니다.

모델 선택은 프로덕트 전략에 중요한 요소입니다. 작업과 모델의 Fit을 맞춰야, 사용자 경험은 매끄럽고, 성능은 안정되며, 운영비용이 싸집니다.

📌 OpenAI 고객 지원 시스템

OpenAI의 CS 시스템의 경우도, 작업 유형에 따라서 담당하는 모델이 다르고, 분류해서 사람에게 넘기기도 합니다.

📌 PM이 해야 할 질문은 달라졌습니다:

PM은 작업 특성에 따라 모델을 분배하는 사람이 되어야 하기도 합니다.

모델 선택은 단순한 기술 스펙이 아니라, UX·운영비용·오류 복구 흐름까지 포함한 제품 전략입니다.

OpenAI는 왜 소셜미디어를 만들고 있을까요?

메타가 별도의 AI 앱을 준비한다는 보도 직후, 샘 올트먼은 우리도 소셜미디어 하나 만들거라고 X에 올렸습니다. 농담 같았지만, 실제로 OpenAI 내부에선 소셜미디어 프로토타입이 개발되고 있었습니다.

지금까지 살펴본 OpenAI의 원칙에 입각해서 추론해보면, SNS를 만드는 궁극적인 이유는 그저 ‘플랫폼 확장’이 아닙니다. 모델 중심 조직답게, 결국 목적은 학습 구조를 확보하는 일입니다.

1️⃣ 목적은 데이터와 UGC입니다

이 구조는 세 가지 이유로 설득력이 있습니다.

2️⃣ 기능보다 실험, 완성보다 관측

이 소셜 미디어를 지금까지 살펴본 OpenAI의 개발 철학과 겹쳐 생각해 보겠습니다.

🦝 AI 시대에 창조하는 사람들을 위한 아싸이트

OpenAI의 개발 방식을 살펴보다 보니 MBTI로 치면, NTP 스타일로 일하고 있다는 생각이 들었습니다.

한마디로, “계획보다는 시스템이 더 중요하다”는 타입. 정리보단 관측을, 검토보단 반복 실험을 택하는 기획 방식을 도입하고 있습니다.

그런데 말입니다. 대부분의 회사는 OpenAI처럼 모델 자체를 소유하거나 직접 학습시키는 구조가 아니기 때문에, ‘모델 중심’이라는 개념이 조금 안맞을 수도 있습니다. OpenAI는 모델을 설계하지만, 일부의 케이스를 제외하고는 보통은 남이 만든 모델 위에서 프로덕트를 설계할테니까요.

그런 의미에서, OpenAI 프로덕트 개발 방법을 토대로, 창조하는 우리들에게 필요한 고려사항을 뽑아봤습니다.

💡 AI 붙인다고 주목되는 시대는 지났습니다

💡 이 역할에 꼭 AI가 최선일까요?

💡 모델은 통제 못해도, 맥락과 입력은 통제하세요.

💡 안될 가능성까지 생각해야 합니다.