| Developed by | OpenAI |
|---|---|
| Type | Tool |
| Aliases | OpenAI API, OpenAI Platform API |
| Related | GPT-5.5, Codex (OpenAI), AI 에이전트, GitHub Copilot, Claude Code |
무엇인가
API는 한 프로그램이 다른 프로그램의 기능을 빌려 쓰기 위해 미리 약속해 둔 출입구다. 식당으로 비유하면 메뉴판과 비슷하다. 손님은 주방의 구조나 조리법을 몰라도 메뉴판에 적힌 이름과 가격만 보고 원하는 음식을 주문할 수 있다. 마찬가지로 개발자는 [[gpt-5-5]] 같은 거대 모델의 내부 구조를 몰라도, OpenAI가 정해 둔 API 규격에 맞춰 요청을 보내기만 하면 모델의 답을 받아 쓸 수 있다.
왜 필요한가
오늘날 대부분의 거대 AI 모델은 너무 커서 개인 PC에서 직접 돌릴 수 없다. 수백 GB짜리 가중치와 고성능 GPU가 필요한 모델을 OpenAI나 Anthropic 같은 회사가 자기 데이터센터에서 운영하고, 사용자는 인터넷을 통해 그 모델에 질문을 던지는 식으로 쓰는 게 보통이다. 이때 "어떤 형식으로 질문을 보내야 하고, 어떤 형식으로 답이 돌아오는가"를 정해 둔 약속이 바로 API다.
어떻게 쓰는가
개발자가 모델을 호출하려면 보통 세 가지가 필요하다.
- API 키: 누가 요청하는지 식별하기 위한 비밀번호 같은 문자열
- 엔드포인트: 어디로 요청을 보낼지 알려주는 인터넷 주소
- 요청 본문: 어떤 모델에게(
gpt-5.5), 어떤 메시지를("안녕"), 어떤 옵션으로(온도·길이 등) 물어볼지 적은 데이터
이 셋을 갖춰 HTTP 요청을 보내면 잠시 후 모델이 생성한 답이 텍스트로 돌아온다. ChatGPT 화면 대신 자기 앱 안에서 똑같은 모델을 쓸 수 있게 되는 셈이다.
챗봇과 무엇이 다른가
ChatGPT는 사람이 브라우저에서 직접 대화하는 완성된 제품이다. API는 그 안에 있는 모델을 다른 프로그램에 끼워 넣는 통로다. 메모 앱에 자동 요약 기능을 붙이거나, [[cursor]]·[[github-copilot]] 같은 코딩 도구가 편집기 안에서 모델을 부르는 일이 모두 API 덕분에 가능하다. 화면 없이 백그라운드에서 모델을 부르는 [[ai-agent]] 류의 자동화 역시 거의 모두 API 위에서 동작한다.
OpenAI API의 위치
OpenAI API는 [[gpt-5-5]] 같은 모델을 자체 서비스나 사내 도구에 통합할 때 가장 먼저 만나는 인터페이스다. ChatGPT가 일반 사용자용 제품이라면, API는 같은 모델 풀을 개발자가 직접 호출할 수 있도록 노출한 진입점이다. 최근에는 새 모델 출시일에 ChatGPT뿐 아니라 API에서도 같은 식별자가 곧바로 활성화되고, [[codex]]·[[github-copilot]]·[[cursor]] 같은 외부 코딩 앱이 같은 날 그 모델을 함께 쓸 수 있게 되는 것이 일반적인 패턴이 되었다.
핵심 호출 형태
실무에서 가장 많이 쓰는 것은 채팅 컴플리션 계열 엔드포인트다. 요청 본문에 model, messages, 그리고 옵션으로 temperature, max_output_tokens, tools, response_format 등을 함께 넣어 호출한다. 응답은 모델이 생성한 텍스트, 토큰 사용량, 종료 사유 등을 담은 JSON으로 돌아온다.
자주 쓰는 기능
- Function calling / tool use: 모델이 미리 등록된 함수를 호출하도록 유도하는 방식. [[ai-agent]]나 외부 시스템 연동의 출발점이다.
- Structured output: JSON 스키마를 강제해 자유 텍스트 대신 깨끗한 구조화 데이터를 받는 모드. 파이프라인 안정성에 유리하다.
- Batch API: 시간이 급하지 않은 대량 작업을 비동기로 처리해 비용을 절반 수준으로 낮춘다. 평가·전처리에 자주 쓴다.
- Streaming: 토큰을 실시간으로 받아 UX를 개선한다.
- Prompt caching: 반복되는 시스템 프롬프트나 긴 문서를 캐싱해 비용과 지연을 함께 줄인다.
운영상 고려할 점
API 키는 절대 클라이언트(브라우저·앱)에 노출하지 말고 서버 또는 [[claude-code]] 같은 신뢰 환경에서만 다뤄야 한다. 모델 식별자는 시간이 지나면 새 스냅샷으로 자동 라우팅되거나 폐기될 수 있으므로, 프로덕션에서는 별칭 대신 날짜가 박힌 정확한 스냅샷을 고정하는 편이 안전하다. 비용은 입력·출력 토큰 단가, 캐시 적중률, 도구 호출 횟수에 따라 크게 달라지므로 호출 단위로 사용량을 로깅해 두는 습관이 필요하다.
다른 API와의 호환성
OpenAI API의 형식은 사실상 업계 표준에 가까워, Anthropic·xAI·로컬 LLM 서버 등 상당수가 OpenAI 호환 모드를 함께 제공한다. 모델 공급자만 바꿔도 코드 변경을 최소화한 채 다른 모델로 갈아탈 수 있다는 뜻이다. 다만 [[mixture-of-experts]] 라우팅 동작이나 Anthropic만의 캐시 제어처럼 공급자 고유 옵션은 호환 모드에서 제대로 노출되지 않는 경우가 많아, 정밀한 튜닝이 필요할 때는 각 공급자의 네이티브 SDK를 쓰는 편이 좋다.
연구 접근 채널로서의 API
연구자에게 OpenAI Platform API는 비공개 모델을 평가·분석할 수 있는 거의 유일한 공식 창구다. 가중치는 닫혀 있지만, API를 통해 임의 입력에 대한 출력 분포의 일부와 사용량 메타데이터를 관측할 수 있다. 따라서 능력 평가, 안전성 분석, 프롬프트 민감도 측정 등 외부 평가의 표준 채널 역할을 한다.
노출되는 인터페이스
- 모델 식별자(
model): 정확한 스냅샷을 가리키는 문자열. 재현성을 확보하려면 별칭(gpt-5.5)이 아니라 날짜 기반 스냅샷을 고정해야 한다. - 샘플링 매개변수:
temperature,top_p,max_output_tokens,seed등.seed는 결정적 출력을 약속하지만 인프라 변동으로 완전한 재현은 보장되지 않는다. - Function calling / tool use: 모델의 도구 사용 능력을 표준화된 입출력 형식으로 측정할 수 있는 면. [[reinforcement-learning-from-verifiable-rewards]] 류의 후처리 학습 결과가 외부에서 가장 직접 드러나는 인터페이스이기도 하다.
- Structured output / JSON schema: 출력을 형식적으로 검증 가능한 형태로 받아 자동 채점 파이프라인에 그대로 연결할 수 있다.
- Logprobs: 일부 엔드포인트에서 상위 토큰 로그 확률을 노출한다. 정밀한 분포 분석에는 부족하지만 신뢰도(calibration) 측정에는 충분히 쓸 만하다.
한계와 주의점
API는 모델 내부를 직접 들여다보는 채널이 아니라, 사업자가 허용한 만큼만 보여주는 창이다. 다음과 같은 구조적 제약이 따른다.
- 블랙박스성: 가중치·활성·어텐션은 보이지 않는다. 안전 필터, 시스템 프롬프트, 라우팅 로직이 응답을 사후에 변형할 수도 있다.
- 모델 변경: 같은 별칭이라도 시간이 지나면서 미세 조정·안전 패치가 누적된다. 평가 결과를 비교할 때는 호출 시점과 정확한 스냅샷 이름을 함께 기록해야 한다.
- 레이트 리밋과 비용: 대규모 평가는 Batch API와 [[retrieval-augmented-generation]] 식의 캐시·재사용 전략을 적극 활용해 비용·시간을 분할 정복해야 현실적이다.
- 표본 편향: API에 도달하는 사용자·프롬프트 분포 자체가 편향돼 있어, API 기반 측정 결과를 일반 사용자 행태로 곧장 일반화하기 어렵다.
평가·연구에서의 실용 패턴
실전 평가 파이프라인은 보통 (1) 고정된 스냅샷 식별자, (2) 결정론적 샘플링 옵션, (3) 구조화 출력 강제, (4) 배치 처리, (5) 호출 메타데이터 로깅으로 구성된다. 다중 시드로 다중 샘플을 뽑아 분산을 함께 측정하는 것도 일반적이다. [[jagged-frontier]] 가설처럼 능력 분포가 들쭉날쭉할 때, API 기반의 다중 도메인 평가는 그 모양새를 외부에서 관찰할 수 있는 사실상 유일한 방법이다.
다른 인터페이스와의 비교
OpenAI API의 인터페이스 설계는 이후 대부분의 LLM 사업자가 모방하면서 사실상의 표준이 됐다. Anthropic Messages API, xAI, vLLM 등 로컬 추론 서버는 OpenAI 호환 모드를 함께 제공하는 경우가 많다. 그러나 캐시 제어, 사고(thinking) 토큰 노출, 도구 결과 형식 등에서 공급자별 차이가 있어, 엄밀한 비교 연구에서는 호환 모드 대신 각 공급자의 네이티브 SDK를 쓰고, 동일한 능력에 대한 측정값이라도 인터페이스가 달라 직접 비교가 불공정할 수 있다는 점을 명시해야 한다.