API 문서 & 스펙
OpenAPI 3.2, tool schema, MCP Resource까지 연결하는 agent-first API 문서
핵심 요약
- OpenAPI를 source of truth로 두고, Markdown은 의도·예외를, 에이전트 표면에는 tool schema와 검증 명령을 연결합니다.
- 에이전트에게 필요한 건 설명이 아니라 요청/응답/인증/부작용/안정성/검증을 담은 계약입니다.
- OpenAPI 최신 published 버전은 2025-09-19 공개된 3.2.0이며, 버전 선택은 validator·codegen·gateway 도구 지원까지 확인합니다.
operationId는 SDK·tool mapping의 기준이므로 변경을 breaking change로 관리합니다.- MCP
ToolAnnotations는 힌트일 뿐 보안 경계가 아니므로 승인 정책과 서버-side auth로 강제합니다.
API 문서는 AI 에이전트가 가장 자주 들여다보는 문서 유형입니다. 코드 생성, 테스트 작성, 디버깅, MCP Tool 설계, SDK 생성에서 API 스펙을 그대로 가져다 씁니다.
2026년 기준으로 API 문서는 사람이 읽는 레퍼런스만으로는 부족합니다. OpenAPI를 source of truth로 두고, Markdown은 의도와 예외를 설명하며, 에이전트용 표면에는 tool schema와 검증 명령을 연결해야 합니다.
왜 API 문서가 AI 시대에 중요한가
AI 에이전트가 API 호출 코드를 짤 때 필요한 건 "엔드포인트 설명"이 아니라 계약입니다.
| 필요한 계약 | 예시 |
|---|---|
| 요청 구조 | path/query/body/header schema |
| 응답 구조 | success/error schema |
| 인증·권한 | OAuth scope, API key 위치, role |
| 부작용 | read-only, write, destructive, external side effect |
| 안정성 | idempotency, retry, rate limit |
| 검증 | schema lint, contract test, breaking change diff |
산문형 설명만 있으면 에이전트는 추측에 기댑니다. 구조화된 스펙과 예시가 있으면 추측할 여지가 줄어듭니다.
OpenAPI 버전 선택
OpenAPI의 최신 published version은 2025년 9월 19일 공개된 3.2.0입니다. 새 프로젝트나 agent-first API 문서라면 3.2.0부터 검토하면 됩니다.
| 버전 | 권장 상황 |
|---|---|
| 3.2.0 | 신규 프로젝트, streaming API, query method, tag taxonomy, OAuth metadata를 활용할 때 |
| 3.1.x | 도구 생태계가 3.2를 아직 완전히 지원하지 않지만 JSON Schema 2020-12 호환성이 필요할 때 |
| 3.0.x | 기존 tooling 제약 때문에 유지해야 할 때. 신규 설계의 기본값으로 두지 않음 |
스펙과 도구 지원을 분리
최신 OpenAPI 버전이라고 현재 도구가 늘 완벽히 지원하지는 않습니다. 스펙 버전을 고를 때는 validator, codegen, gateway, docs renderer, contract test 도구 지원까지 함께 확인하세요.
AI-readable API 문서 원칙
- 스키마가 진실의 원천: OpenAPI/JSON Schema가 산문 설명보다 우선
- operationId 안정성: SDK, 테스트, 에이전트 tool mapping의 기준이 되므로 변경을 엄격히 관리
- 예제 우선: 모든 주요 엔드포인트에 요청/응답/에러 예시 제공
- 에러 계약 명시: HTTP status만이 아니라
code,message, recovery action 포함 - 부작용 표시: read/write/destructive/open-world 여부를 문서와 tool schema에 반영
- 검증 명령 포함: lint, diff, contract test, smoke test를 문서에 명시
Before/After
Before — 산문형 API 설명:
## 사용자 API
사용자를 생성하려면 POST 요청을 /api/users로 보내면 됩니다.
이름과 이메일이 필요하고, 이메일은 유효해야 합니다.
성공하면 201이 오고 실패하면 400이 옵니다.After — 계약 중심 API 문서:
openapi: 3.2.0
info:
title: Users API
version: 2.3.0
paths:
/api/users:
post:
operationId: createUser
summary: 사용자 생성
security:
- bearerAuth: []
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateUserRequest'
examples:
valid:
value: { "name": "Hong", "email": "hong@example.com" }
responses:
'201':
description: Created
content:
application/json:
schema:
$ref: '#/components/schemas/User'
'400':
description: Invalid input
content:
application/json:
schema:
$ref: '#/components/schemas/Error'agent contract pack
에이전트가 API를 정확히 쓰게 하려면 OpenAPI와 함께 작은 계약 묶음을 같이 줍니다.
api-contract/
├── openapi.yaml
├── errors.md
├── auth.md
├── rate-limits.md
├── idempotency.md
├── examples/
│ ├── create-user.request.json
│ └── create-user.response.json
└── validation.md| 파일 | 역할 |
|---|---|
openapi.yaml | 기계가 읽는 source of truth |
errors.md | 복구 가능한 에러와 사용자 메시지 정책 |
auth.md | 토큰 발급, scope, role, 갱신 |
rate-limits.md | limit, retry-after, backoff |
idempotency.md | 재시도 가능한 mutation 기준 |
examples/ | 실제 테스트에 사용할 요청/응답 fixture |
validation.md | lint, diff, contract test 명령 |
OpenAPI 3.2에서 주목할 항목
| 항목 | 문서화 영향 |
|---|---|
| streaming media types | SSE, JSON Lines, JSON Sequences, multipart/mixed 응답을 더 명확히 표현 |
query method | payload가 있는 안전한 query 동작을 POST와 분리 |
querystring | query parameter 전체를 schema로 설명 |
| tag 구조 확장 | navigation, codegen, badge 등 tag 용도 분리 |
| OAuth metadata URL | 인증 서버 metadata discovery를 API 문서에 연결 |
Streaming API 예시
paths:
/api/events:
get:
operationId: streamEvents
responses:
'200':
description: Server-sent event stream
content:
text/event-stream:
schema:
type: stringStreaming API는 "응답이 스트리밍된다"만 적어두면 부족합니다. 에이전트와 SDK 생성 도구가 알아챌 수 있도록 이벤트 단위 schema, 종료 조건, 재연결 정책, backpressure 기준을 따로 설명하세요.
MCP Tool과 API 문서 연결
API를 MCP Tool로 노출할 때는 API 문서의 계약을 tool schema 수준으로 좁혀야 합니다.
| API 문서 항목 | MCP Tool 문서 항목 |
|---|---|
| path/query/body schema | inputSchema |
| response schema | outputSchema 또는 structured content |
| 인증·scope | MCP server authorization/scope |
| read/write/destructive | tool annotations + 승인 정책 |
| rate limit | retry/backoff 문서 |
| error code | tool error result와 recovery action |
MCP ToolAnnotations의 readOnlyHint, destructiveHint, idempotentHint, openWorldHint는 클라이언트가 판단에 참고할 수 있는 힌트입니다.
하지만 공식 스키마 기준으로도 이 값은 힌트일 뿐 보안 경계가 아닙니다. 믿을 수 없는 서버의 annotation만 보고 자동 승인하면 안 됩니다.
{
"name": "create_user",
"description": "Create a user account.",
"inputSchema": {
"type": "object",
"properties": {
"name": { "type": "string", "minLength": 2 },
"email": { "type": "string", "format": "email" }
},
"required": ["name", "email"]
},
"annotations": {
"readOnlyHint": false,
"destructiveHint": false,
"idempotentHint": false,
"openWorldHint": true
}
}인증 흐름 문서화
AI가 인증이 필요한 API를 호출하려면 토큰 취득 과정을 단계별로 알아야 합니다.
## 인증
### 토큰 취득
- Endpoint: `POST /auth/token`
- Grant: `client_credentials`
- Scope: `users:write`
- Expiry: 3600 seconds
### 토큰 사용
모든 API 요청에 헤더 포함:
`Authorization: Bearer {accessToken}`
### 에러
| HTTP | code | 의미 | 복구 |
|---|---|---|---|
| 401 | TOKEN_EXPIRED | 토큰 만료 | 새 토큰 발급 |
| 403 | INSUFFICIENT_SCOPE | scope 부족 | `users:write` 요청 |
| 429 | RATE_LIMITED | 요청 제한 | `Retry-After` 이후 재시도 |Breaking change 감지
에이전트가 API 문서를 갱신할 때 가장 위험한 실패는 breaking change를 놓치는 경우입니다.
| 변경 | 위험도 | 조치 |
|---|---|---|
| 필수 request field 추가 | breaking | major/minor 정책 확인, migration guide 작성 |
| response field 삭제/타입 변경 | breaking | diff와 소비자 영향 분석 |
| enum 값 제거 | breaking | client fallback 확인 |
| optional field 추가 | 대체로 non-breaking | 문서/예시 갱신 |
| 새 error code 추가 | 조건부 | client error handling 확인 |
pnpm openapi:lint
pnpm openapi:diff --from main --to HEAD
pnpm test:contractAI가 실패하는 패턴
| 실수 | AI가 실패하는 이유 | 수정 방법 |
|---|---|---|
| "적절한 인증 필요" | 인증 방식을 추측함 | bearer/API key/OAuth scope 명시 |
| 에러 코드 없이 "실패 시 에러 반환" | 에러 처리 코드를 생략 | HTTP status + error code + recovery |
operationId가 불안정 | SDK/tool mapping이 깨짐 | operationId 변경을 breaking change로 관리 |
| streaming 응답을 산문으로만 설명 | client가 종료/재연결을 구현 못함 | 이벤트 schema, 종료 조건, retry 정책 명시 |
| tool annotation을 보안 경계로 믿음 | annotation은 서버 제공 힌트 | 승인 정책과 서버-side auth로 강제 |
AI 프롬프트 예시
다음 route handler와 OpenAPI 파일만 근거로 API 문서를 갱신해줘.
포함할 내용:
1. operationId, method, path, 인증, scope
2. request/response schema와 예시
3. error code와 recovery action
4. idempotency, rate limit, retry 정책
5. MCP Tool로 노출할 경우 inputSchema/outputSchema와 annotation 제안
6. breaking change 여부와 검증 명령
금지:
- 코드나 스펙에 없는 파라미터를 만들지 않는다.
- 최신 OpenAPI 버전을 추정하지 않는다.
- tool annotation을 보안 보장으로 표현하지 않는다.체크리스트
| 항목 | 확인 |
|---|---|
| OpenAPI 버전과 tooling 지원 범위를 명시했는가 | ☐ |
모든 public endpoint에 안정적인 operationId가 있는가 | ☐ |
| 요청/응답/에러 schema와 예시가 있는가 | ☐ |
| 인증, scope, role, token expiry가 명시되어 있는가 | ☐ |
| rate limit, retry, idempotency 정책이 있는가 | ☐ |
| streaming API의 event schema와 재연결 정책이 있는가 | ☐ |
| MCP Tool로 노출할 API의 input/output schema와 side effect가 정리되어 있는가 | ☐ |
| OpenAPI lint, diff, contract test 명령이 문서화되어 있는가 | ☐ |