기술 문서(API 문서) 설명 글자수 기준
REST API 문서의 엔드포인트 설명·파라미터·응답 예시별 권장 글자수와 개발자 친화적인 기술 문서 작성법을 설명합니다.
Q.API 문서에서 엔드포인트 설명은 몇 글자로 써야 하나요?
API 엔드포인트 설명은 50-150자(1-3문장)가 권장됩니다. 파라미터 설명은 30-80자로 간결하게 작성합니다. Stripe·Twilio 등 유명 API 문서를 분석하면 설명을 짧게 유지하고 코드 예시로 보완하는 패턴을 따릅니다.
Stripe의 API 문서는 개발자 커뮤니티에서 "최고의 기술 문서" 예로 자주 언급된다. Stripe 문서의 특징은 엔드포인트 설명이 짧고 명확하며, 코드 예시가 풍부하다는 점이다. 긴 설명 대신 바로 실행 가능한 코드 예시가 더 효과적인 경우가 많다.
API 문서 요소별 권장 글자수
| 요소 | 권장 글자수 | 예시 |
|---|---|---|
| 엔드포인트 한 줄 설명 | 50-100자 | "사용자를 생성합니다. 이메일과 비밀번호가 필요합니다." |
| 파라미터 설명 | 30-80자 | "사용자 고유 ID. 정수형." |
| 에러 코드 설명 | 50-120자 | - |
| 응답 필드 설명 | 30-80자 | - |
| 섹션 소개 | 100-300자 | - |
| 개요/시작하기 | 200-500자 | - |
좋은 API 문서의 특징
1. 설명보다 예시
http
POST /v1/users
Content-Type: application/json
{
"email": "user@example.com",
"password": "securepass123"
}
코드 예시 하나가 100자 설명보다 효과적이다.
2. 모든 파라미터 명시
필수(required)/선택(optional) 구분을 명확히 한다.
| 파라미터 | 타입 | 필수 | 설명 |
|---|---|---|---|
| string | required | 사용자 이메일 주소 | |
| name | string | optional | 표시 이름 (기본값: email 앞부분) |
3. 에러 응답 포함
성공 케이스만큼 에러 케이스가 중요하다.
json
{
"error": {
"code": "invalid_email",
"message": "이메일 형식이 올바르지 않습니다."
}
}
4. 버전 정보
API 버전(v1, v2)과 변경 이력(Changelog)을 문서에 포함한다.
기술 문서 도구
- OpenAPI/Swagger: REST API 명세 자동화
- Notion: 내부 문서화
- GitBook: 공개 기술 문서
- Docusaurus: 오픈소스 문서 사이트
OpenAPI 명세를 사용하면 코드에서 문서를 자동 생성할 수 있어 문서와 코드 불일치를 방지한다.
---
이 글은 AI가 공개 자료를 기반으로 작성했습니다. API 문서 작성 시 개발자 피드백을 반복적으로 수렴하는 것이 중요합니다.