시리즈: ChatGPT 기술 제품 조직 (총 12편) | 9회
흩어진 퍼즐 조각 맞추기 — API·안전·바이럴의 교차점
OpenAI가 어떻게 개발자 플랫폼을 바꾸고, 안전 정책을 다져왔으며, ChatGPT가 왜 그렇게 빠르게 퍼졌는지 — 세 가지 큰 흐름을 한 편에서 정리해봤어.
Summary
- Completions → Chat Completions → Responses API로 이어지는 진화는 “대화”를 넘어 툴 통합·상태 유지·에이전트형 워크플로우를 기본값으로 만드는 방향으로 수렴했어
- OpenAI의 안전 전략은 기술 문제가 아니라 배포 방식과 정책 설계 문제로 점점 무게가 옮겨갔어
- ChatGPT의 폭발적 확산은 모델 성능 하나가 아니라 UX·RLHF 체감 품질·소셜 바이럴·파트너십이 동시에 맞물린 결과야
이 글의 대상
- OpenAI 개발자 플랫폼의 흐름을 한눈에 이해하고 싶은 개발자
- AI 제품의 안전·규제 거버넌스가 어떻게 발전해왔는지 궁금한 사람
- “왜 ChatGPT가 갑자기 터졌나”에 대한 구조적 설명이 필요한 기획자·PM
목차
1. 개발자 플랫폼: 대화 API에서 에이전트 아키텍처로
시작은 “프롬프트 완성”이었어
초기 /v1/completions는 말 그대로 프롬프트를 완성해주는 엔드포인트였어. 그 다음 대화형 수요가 커지면서 /v1/chat/completions가 생겼는데, OpenAI는 개발자 블로그 회고에서 이걸 “단 한 주말에 만들었다”고 했거든. 그만큼 급박하게 시장 니즈에 대응한 거야.
Chat Completions는 role 기반 메시지 구조로 대화형 UI 구현을 엄청나게 단순화했어. 근데 시간이 지나면서 툴 호출, 멀티모달 입력, 상태 유지, 멀티스텝 워크플로우를 동시에 다루려니까 구조적 한계가 드러나기 시작했어.
Responses API: “에이전트적 루프”를 기본값으로
그래서 나온 게 Responses API야. OpenAI는 이걸 “agentic loop(에이전트적 루프)” 로 정의하면서, 핵심 목적을 툴 통합·상태 유지·멀티모달을 네이티브로 지원하는 아키텍처 재설계로 제시했어.
Responses 탄생 배경에는 Assistants API 실험의 실패 경험이 크게 작용했어. Assistants는 기능적으로 강력했는데 채택이 널리 퍼지지 못했거든. “Chat Completions의 접근성”과 “Assistants의 기능성”을 통합하려는 요구가 Responses를 촉발했다고 OpenAI는 설명해.
Responses가 Chat Completions와 다른 점
| 특징 | Chat Completions | Responses API |
|---|---|---|
| 상태 관리 | 매 요청 독립적 | stateful-by-default (이전 응답 ID로 연결) |
| 반환값 형태 | 단일 메시지 | polymorphic Items (메시지, 함수 호출, 메타 등) |
| 추론 상태 | 외부 노출 | 암호화 보관 (CoT 노출 억제) |
| 멀티모달 | 부분 지원 | 네이티브 통합 |
| 호스티드 툴 | 별도 구성 필요 | 내장 (웹검색, 코드 실행, MCP 등) |
stateful-by-default 설계가 핵심이야. 이전 응답 ID로 추론 상태를 이어 붙여 멀티턴/멀티스텝 작업이 쉬워졌어. 반대로 저장이 필요 없으면 store:false로 비저장 패턴도 설계할 수 있고.
툴 호출은 call_id로 출력과 연계해서 “영수증처럼” 추적 가능하게 만든 것도 실무적으로 중요한 변화야.
호스티드 툴: ChatGPT 기능 실험의 API화
Responses는 OpenAI가 직접 호스팅하는 도구를 API에 내장했어.
- Code Interpreter: 서버 측 파이썬 실행·파일 처리·시각화 지원
- web_search / file_search: RAG 파이프라인 일부를 OpenAI 쪽에서 관리
- MCP: 원격 MCP 서버 호출로 외부 자원 통합
엔터프라이즈 입장에서는 “직접 RAG/코드 실행 인프라를 만들지 않고” 고급 기능을 빠르게 붙일 수 있다는 게 매력이야. 근데 동시에 툴 출력 신뢰성·보안·프라이버시 책임 경계가 재설정된다는 점도 같이 봐야 해.
function calling(2023-06-13): “모델이 행동한다”의 시작
2023년 6월 13일은 function calling이 등장한 날이야. 개발자가 함수 시그니처(JSON Schema)를 전달하면, 모델이 필요 시 함수 인자를 JSON으로 반환해 외부 함수를 호출하는 방식이야.
이게 왜 중요하냐면 — 모델 출력이 단순 텍스트에서 구조화 데이터로 바뀌면서 시스템 연동이 현실화됐거든. 자연어→API 호출, 데이터 추출, 작업 자동화가 실제로 가능해진 전환점이었어.
OpenAI는 이때부터 “툴 출력 신뢰성”과 “악용 가능성”을 경고하며 신뢰된 툴 연결·사용자 확인 절차를 권고했어.
개발자가 실제로 주의할 것들
- 마이그레이션 비용: 요청/응답 포맷이 달라.
choices.message→response.output아이템 구조로 바뀌거든. 마이그레이션 가이드는 공식 문서에 있어. - 행동 차이 관측: 동일 모델명이라도 Chat Completions와 Responses에서 출력 스타일/정확성이 달라졌다는 커뮤니티 보고가 있어.
- 성능/비용 주장: 내부 벤치마크 기준 40–80% 개선을 주장하는데, 실제 비용은 툴 호출 빈도·멀티모달 입력 등 사용 패턴에 따라 다르니까 사전 검증이 필요해.
- 플랫폼 락인: Responses는 호스티드 툴·MCP 등 OpenAI 플랫폼 서비스와 결합도가 높아. 생산성은 올라가지만 구조/정책 변화 시 마이그레이션 비용도 커질 수 있어.
2. 안전·정책·거버넌스: 배포 방식이 안전 전략이 된 과정
GPT-2(2019): 책임 있는 공개 논쟁의 시작
OpenAI는 GPT-2(1.5B) 전체 모델을 처음엔 오남용 위험을 이유로 보류했다가, 2019년 11월에야 단계적 공개를 종결하며 모델·코드·가중치를 내놓았어.
당시 반응은 갈렸어. “과도한 비공개”라는 비판이 있었던 반면, “책임 있는 공개”라고 평가하는 쪽도 있었지. 이 논쟁이 사실 지금까지도 AI 공개 정책 논쟁의 원형이야.
GPT-3(2020): API 통제로 안전·상업화 동시에
GPT-3(175B)에서 OpenAI는 가중치 완전 공개 대신 API 제공을 선택했어. 이 결정이 안전 전략과 맞물린 게 중요해 — API 운용은 접근 통제·모니터링·사용 사례 심사·이상행위 차단을 가능하게 하거든.
동시에 “접근 민주성 vs 위험 집중” 논쟁도 생겼어. 중앙 통제가 강화될수록 누가 접근권을 갖느냐는 권력 문제가 됐지.
InstructGPT(2022): RLHF로 ‘정렬’이 표준화된 순간
2022년 InstructGPT에서 RLHF(인간 피드백 기반 강화학습)를 통해 “지시를 더 잘 따르고 덜 유해하도록” 훈련했어. 이게 기술적 정렬의 표준화된 방법론이 됐어.
근데 RLHF가 제품화되면서 새로운 거버넌스 과제가 생겼어 — “어떤 인간의 가치로 정렬하나”는 질문이야. 라벨러 선정·지침·평가를 문서화했지만 대표성/편향 문제는 구조적으로 남아.
GPT-4(2023): 시스템 카드가 ‘규제 대응 인프라’가 된 것
GPT-4 공개와 함께 OpenAI는 GPT-4 시스템 카드를 내놨어. 능력/한계, 위험, 평가 설계, 완화 조치 등을 다루는 이 문서가 이후 AI 공개의 표준 양식이 됐어.
OpenAI는 GPT-4 훈련에서 safety reward(안전 보상) 신호를 RLHF에 추가해 특정 유해 카테고리 거부 학습을 시도했다고도 밝혔어. 이후 GPT-4o 시스템 카드 등으로 확장되면서 “문서 기반 투명성”이 제품 출시의 일부가 됐지.
안전 정책의 역사: 타임라인으로 보면
| 시점 | 사건 | 의미 |
|---|---|---|
| 2019-11 | GPT-2 1.5B 단계적 공개 완료 | 책임 있는 공개 논쟁 시작 |
| 2020 | GPT-3 API 제공 선택 | 접근 통제·모니터링 가능 구조 |
| 2022-01 | InstructGPT·RLHF 실무화 | 정렬의 기술적 표준화 |
| 2022-11 | ChatGPT 상용화 | 대규모 사후 안전 운영 시작 |
| 2023 | GPT-4 시스템 카드 | 투명성 문서의 규제 대응 인프라화 |
| 2023-02-15 | Usage Policies 통합 공개 | 단일 가드레일 체계 도입 |
| 2024-01-10 | Usage Policies 업데이트 | 고위험 영역 통제 강화 |
| 2025-10-29 | Usage Policies 업데이트 | 지속적 정책 강화 |
Red teaming의 제도화: 출시 전후 검증 체계
OpenAI는 외부 red teaming 접근과 운영 원칙을 백서로 정리하고, 2024년에는 사람과 AI를 결합한 red teaming 고도화를 공개했어.
핵심 운영 포인트는:
- 외부 전문가 참여 설계, 접근 레벨 통제
- 정보관리(정보유출/정보해악 리스크)
- 결과를 평가 파이프라인에 반영
논쟁 지점도 있어 — 결과 공개 범위와 타이밍, 이해상충 가능성, “공개 자체가 위험을 키울 수 있다”는 우려.
저작권 소송(2023~): 데이터 거버넌스의 새 전선
Authors Guild 등 저자 그룹이 2023년 “훈련 데이터의 저작권 침해 여부”를 핵심으로 소송을 제기했어. 아직 진행 중이고 공정이용 여부는 관할/사안마다 다를 수 있어서 확정하기 어려워.
이 소송 과정은 데이터셋 관리(삭제·기록 보존·문서화)와 관련한 압박을 키우는 중이야.
3. 왜 ChatGPT가 대중적 전환점이 됐나
“개발자 도구”에서 “소비자 제품”으로의 전환
GPT-3 이후 LLM의 잠재력은 입증됐는데, API 중심 접근은 일반 사용자가 직접 체감하기 어려웠어. OpenAI는 GPT-3.5 계열을 대화형 웹 UI로 묶으면서 기술을 소비자 제품으로 전환했어.
당시 사용자 니즈는 “링크 나열” 중심 검색과 달리 요약·작성·코드 보완 같은 즉시 결과에 가까웠어. ChatGPT는 “검색과 창작의 중간” 역할로 공백을 메웠다는 해석이 있어.
UX가 만든 진입장벽 붕괴
채팅 UI는 사용자가 이미 익숙한 상호작용 방식이야. 별도 튜토리얼 없이 바로 질문-응답을 반복하며 학습할 수 있었어. 이게 얼마나 강력한지 과소평가하면 안 돼.
- 대화의 컨텍스트 유지: 후속 질문으로 점진적 정교화가 가능해 “키워드→링크” 흐름보다 작업형 상호작용에 적합했어
- 응답 스트리밍: 타이핑 효과는 ‘대화성’과 몰입도를 높였어
- “Regenerate response”: 오류 허용/반복 개선 UI는 확률적 모델의 불확실성을 제품 기능으로 흡수한 사례야
RLHF 기반 체감 품질: 비전문가도 “바로 유용”했던 이유
InstructGPT의 RLHF 파이프라인이 ChatGPT에도 적용됐어. 이 정렬 과정은 단순 언어능력보다 “지시를 잘 따르고, 정중하며, 사용자가 원하는 형식으로 답하는” 체감 품질을 크게 올렸어.
다만 환각/사실성 문제를 완전히 제거하지 못했다는 한계도 함께 명시돼 있어.
확산 속도: 숫자로 보면 얼마나 빨랐나
| 지표 | 수치 | 출처 |
|---|---|---|
| 출시 후 100만 사용자 | 5일 | Greg Brockman 게시 |
| 출시 후 1억 사용자 | 2개월 | 언론 보도 |
단, 지표 산정 방식은 매체/분석기관마다 다르다는 점은 감안해야 해.
소셜 바이럴이 확산을 가속한 구조
대화 스크린샷 공유, ShareGPT 같은 커뮤니티는 “놀라운 답변”의 확산을 가속했어. “이거 봐봐” 하고 보내기 딱 좋은 포맷이었던 거야.
교육 분야에서는 처음엔 부정행위 우려로 차단/금지 움직임이 있었다가, 빠르게 과제 설계·피드백 도구로의 통합 논의가 진행됐어. 개발자 커뮤니티에서는 코드 작성·디버깅에 유용하다는 반응이 있었던 반면, Stack Overflow가 부정확한 답변 문제로 일시적 금지 조치를 내리기도 했어.
경쟁사 반응이 보여주는 파급력
Microsoft는 2023년 2월 Bing/Edge를 “AI 코파일럿”으로 재정의하며 대화형 검색을 공개했어. ChatGPT 계열 기술이 검색 시장(특히 Google 중심)에 구조적 압박을 준 사건으로 해석돼. 이후 Bard 등 경쟁사 대응이 본격화됐어.
핵심 정리
1. API 진화는 "대화 완성" → "에이전트형 루프"로 수렴 중
Chat Completions의 접근성 + Assistants의 기능성 = Responses API
2. function calling(2023-06-13)은 "모델이 행동하는" 시대의 실용적 시작점
자연어→구조화 JSON→외부 시스템 연동이 현실화됐어
3. OpenAI 안전 전략의 핵심 전환: 기술 문제 → 배포 방식·정책 설계
GPT-2 보류 → API 통제 → RLHF → 시스템 카드 → 사용 정책 통합
4. ChatGPT 폭발은 단일 요인이 아니야
UX + RLHF 체감 품질 + 소셜 바이럴 + 소비자 제품 전환의 동시 맞물림
5. 플랫폼 락인은 생산성과 트레이드오프
Responses의 호스티드 툴은 편리하지만 OpenAI 의존도도 같이 올라가
FAQ
Q. Chat Completions는 이제 쓰면 안 돼?
A. 완전 폐기되는 건 아니야. OpenAI는 Responses를 추천하면서 전환 정책·가이드를 제시하고 있어. 기존 서비스에서 당장 바꿀 필요는 없고, 새로 시작하거나 에이전트형 워크플로우가 필요하다면 Responses가 나은 선택이야.
Q. Responses API로 마이그레이션하면 출력이 달라질 수 있어?
A. 그래, 달라질 수 있어. 동일 모델명이라도 Chat Completions와 Responses에서 출력 스타일/정확성이 달라졌다는 커뮤니티 보고가 있어. 마이그레이션 전에 A/B 테스트를 해보는 게 좋아.
Q. Responses API는 무조건 비용이 낮아?
A. OpenAI는 내부 벤치마크 기준 40–80% 개선을 주장하는데, 실제 비용은 툴 호출 빈도·멀티모달 입력 등 사용 패턴에 따라 달라. 사전 검증이 반드시 필요해.
Q. function calling과 Responses API의 tools 설정은 뭐가 달라?
A. function calling은 Chat Completions에서 함수 시그니처를 정의하고 모델이 JSON 인자를 반환하는 방식이야. Responses의 tools는 여기에 더해 OpenAI 호스티드 툴(웹검색, 코드 실행, MCP 등)을 직접 내장할 수 있어서 인프라 구성 부담이 줄어.
Q. RLHF로 정렬했는데 왜 환각은 여전히 생겨?
A. RLHF는 “지시를 잘 따르고 사용자가 선호하는 형태로 답하는” 능력을 키우는 거야. 사실 정확성 자체를 보장하는 메커니즘이 아니거든. 사실성 검증은 별도 메커니즘(검색 연동, 사실 확인 파이프라인 등)이 필요해.
Q. OpenAI가 GPT-3 가중치를 공개 안 한 이유가 뭐야?
A. 안전·통제·상업화가 얽혀 있어. API 운용은 접근 통제·모니터링·이상행위 차단이 가능하고, 동시에 수익 모델이기도 해. “접근 민주성 vs 위험 집중” 논쟁은 지금도 오픈소스 모델과의 비교로 이어지고 있어.
Q. Authors Guild 소송 결과는 어떻게 됐어?
A. 아직 진행 중이야(2026년 3월 기준). 공정이용 여부는 관할과 사안에 따라 다를 수 있어서 확정하기 어려운 상황이야.
Q. ChatGPT “5일 100만, 2개월 1억” 수치는 신뢰할 수 있어?
A. 널리 인용되는 수치인데, 지표 산정 방식은 매체/분석기관마다 달라. Greg Brockman의 100만 수치는 X 게시물 기반이고, 1억은 언론 분석 보도 기반이야. 정확한 집계보다는 “폭발적 확산의 상징적 수치”로 이해하는 게 맞아.
Q. 시스템 카드를 공개하면 보안 취약점도 노출되지 않아?
A. 이게 바로 red teaming 결과 공개 논쟁의 핵심이야. “공개 자체가 위험을 키울 수 있다”는 우려와 “투명성이 신뢰를 만든다”는 입장이 충돌해. OpenAI는 지금도 상세 평가 방법론보다는 요약 형태로 공개하는 방식을 취하고 있어.
Q. 플랫폼 락인이 문제라면 대안은 뭐야?
A. 완전한 대안은 없지만 전략은 있어. 툴 추상화 레이어를 두거나, 핵심 비즈니스 로직을 API 인터페이스에서 분리하거나, 오픈소스 모델 병행 테스트를 유지하는 식이야. “편리함 vs 이식성” 트레이드오프를 명확히 인식하고 설계하는 게 핵심이야.
참고 자료 (References)
데이터 출처
| 출처 | 설명 | 링크 |
|---|---|---|
| OpenAI Responses API Blog | Responses API 설계 배경 및 특징 | Responses API 설계 배경 |
| OpenAI Function Calling 공지 | function calling 도입 발표 (2023-06-13) | Function calling 도입 발표 |
| GPT-4 System Card | GPT-4 안전 평가 및 완화 조치 문서 | GPT-4 시스템 카드 |
| InstructGPT 논문 (arXiv) | RLHF 파이프라인 설명 | InstructGPT 논문 |
| Greg Brockman X 게시 | 출시 5일 100만 사용자 언급 | Greg Brockman X 게시물 |
| The Guardian 보도 | 2개월 1억 사용자 분석 보도 | Guardian 기사 |
| Authors Guild 소송 | 저작권 집단소송 원문 | Authors Guild 소송 원문 |
| OpenAI Usage Policies | 사용 정책 통합 및 업데이트 이력 | OpenAI 사용 정책 |
핵심 인용
“Chat Completions was built in a single weekend.”
— OpenAI 개발자 블로그, Responses API 회고“We evaluate that Responses API offers 40–80% improvements in our internal benchmarks.”
— OpenAI 개발자 블로그, Responses API 발표“ChatGPT reached one million users in 5 days.”
— Greg Brockman, X(트위터) 게시 (2022-12-05)
다음 편 예고
[10편] AI 시장이 말하는 것과 실제 벌어지는 일이 다른 이유
- OpenAI가 만들어낸 시장 구조의 역설 — “안전을 위해 상업화가 필요하다”는 논리의 내면
- 기술 스타트업에서 거대 플랫폼으로의 전환이 만드는 경쟁 구도
- Responses API 논쟁·GPT-2 비공개 평가·저작권 소송을 관통하는 세 가지 모순, 그리고 제품→플랫폼→거버넌스 순환 구조 분석
'AI' 카테고리의 다른 글
| ChatGPT 역사를 바꾼 결정적 순간 5가지 — ChatGPT 기술 제품 조직 11/12 (0) | 2026.02.09 |
|---|---|
| AI 시장이 말하는 것과 실제 벌어지는 일이 다른 이유 — ChatGPT 기술 제품 조직 10/12 (0) | 2026.02.09 |
| ChatGPT 플랫폼 이후, 아직 답 없는 5가지 핵심 질문 — ChatGPT 기술 제품 조직 8/12 (0) | 2026.02.09 |
| 3년이 만든 놀라운 변화: 기술·제품·조직이 맞물린 방식 — ChatGPT 기술 제품 조직 7/12 (0) | 2026.02.09 |
| ChatGPT를 둘러싼 세 가지 큰 논쟁: API 전쟁, 안전 딜레마, 대중화의 이면 — ChatGPT 기술 제품 조직 6/12 (0) | 2026.02.09 |