본문으로 바로가기
리옵트 핸드북
리옵트 핸드북
에이전틱 시대의 문서화 혁신

패러다임 전환

왜 문서화가 변해야 하는가AI-readable 문서 설계 원칙AI와 협업하는 문서 작성 프로세스

문서 유형별 실전

프로젝트 규칙 문서문서에서 스킬·플러그인·MCP로에이전트 문서 보안API 문서 & 스펙README & 온보딩 문서아키텍처 결정 기록 (ADR)런북 & 운영 문서사용자 가이드 & 튜토리얼지식기반 (KB) & 내부 위키

운영

문서 유지보수 전략팀 문서화 문화 만들기

부록

템플릿 모음검증 리포트업데이트 내역
핸드북›에이전틱 시대의 문서화 혁신›API 문서 & 스펙
한국어English

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 문서 원칙

  1. 스키마가 진실의 원천: OpenAPI/JSON Schema가 산문 설명보다 우선
  2. operationId 안정성: SDK, 테스트, 에이전트 tool mapping의 기준이 되므로 변경을 엄격히 관리
  3. 예제 우선: 모든 주요 엔드포인트에 요청/응답/에러 예시 제공
  4. 에러 계약 명시: HTTP status만이 아니라 code, message, recovery action 포함
  5. 부작용 표시: read/write/destructive/open-world 여부를 문서와 tool schema에 반영
  6. 검증 명령 포함: 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.mdlimit, retry-after, backoff
idempotency.md재시도 가능한 mutation 기준
examples/실제 테스트에 사용할 요청/응답 fixture
validation.mdlint, diff, contract test 명령

OpenAPI 3.2에서 주목할 항목

항목문서화 영향
streaming media typesSSE, JSON Lines, JSON Sequences, multipart/mixed 응답을 더 명확히 표현
query methodpayload가 있는 안전한 query 동작을 POST와 분리
querystringquery 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: string

Streaming API는 "응답이 스트리밍된다"만 적어두면 부족합니다. 에이전트와 SDK 생성 도구가 알아챌 수 있도록 이벤트 단위 schema, 종료 조건, 재연결 정책, backpressure 기준을 따로 설명하세요.

MCP Tool과 API 문서 연결

API를 MCP Tool로 노출할 때는 API 문서의 계약을 tool schema 수준으로 좁혀야 합니다.

API 문서 항목MCP Tool 문서 항목
path/query/body schemainputSchema
response schemaoutputSchema 또는 structured content
인증·scopeMCP server authorization/scope
read/write/destructivetool annotations + 승인 정책
rate limitretry/backoff 문서
error codetool 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 추가breakingmajor/minor 정책 확인, migration guide 작성
response field 삭제/타입 변경breakingdiff와 소비자 영향 분석
enum 값 제거breakingclient fallback 확인
optional field 추가대체로 non-breaking문서/예시 갱신
새 error code 추가조건부client error handling 확인
pnpm openapi:lint
pnpm openapi:diff --from main --to HEAD
pnpm test:contract

AI가 실패하는 패턴

실수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 명령이 문서화되어 있는가☐

참고 문서

  • OpenAPI Specification v3.2.0
  • OpenAPI Initiative: Announcing OpenAPI v3.2
  • Model Context Protocol Schema Reference

관련 문서

검증 리포트

에이전틱 시대의 문서화 혁신 핸드북의 출처·링크·정합성 검증 결과

업데이트 내역

에이전틱 시대의 문서화 혁신 핸드북 변경 로그

Ch7. Tools, Approval, Connections

엔터프라이즈 Eve 에이전트 개발 · Eve 도구 실행, 사람 승인, MCP/OpenAPI 연결, OAuth 흐름을 엔터프라이즈 보안 경계로 설계한다.

AI SDK 런타임

Vercel 엔터프라이즈 AI 플랫폼 · AI SDK 6를 애플리케이션 계층 표준으로 사용해 agent, tool, MCP, telemetry를 구성하는 방법을 정리합니다.

인터페이스 계약과 관측 포인트

에이전틱 테스트 환경 엔지니어링 · locator, test id, API schema, domain event, log field를 안정적 테스트 계약으로 다루는 방법

에이전트 문서 보안

Prompt injection, MCP tool poisoning, Plugin 공급망, excessive agency를 줄이는 문서 보안 기준

README & 온보딩 문서

README는 사람의 진입점, AGENTS.md는 에이전트 규칙, llms.txt는 LLM용 Markdown 색인으로 역할을 분리하고 링크 정확성을 CI로 검증하는 온보딩 문서 설계.

On this page

왜 API 문서가 AI 시대에 중요한가OpenAPI 버전 선택AI-readable API 문서 원칙Before/Afteragent contract packOpenAPI 3.2에서 주목할 항목Streaming API 예시MCP Tool과 API 문서 연결인증 흐름 문서화Breaking change 감지AI가 실패하는 패턴AI 프롬프트 예시체크리스트참고 문서