Writing Guide
출처: 문서
본문
작성 가이드
이 가이드는 OpenSearch Project 기여자를 위한 작성 표준을 제공하며, 문법, 구두점 및 언어 메커니즘을 다룹니다. 브랜드 아이덴티티, 명명 규칙, 음성 및 톤에 대해서는 스타일 가이드를 참조하세요. 콘텐츠 형식 규칙에 대해서는 텍스트 형식 가이드를 참조하세요. 마크다운 및 Jekyll 구문에 대해서는 마크다운 형식 가이드를 참조하세요.
문법
명확하고 문법적으로 올바른 콘텐츠를 작성하려면 다음 지침을 따르세요.
능동태와 수동태
대부분의 경우 능동태를 사용하세요. 능동태는 누가 무엇을 하는지 명확하게 하며 더 간결합니다.
수동태를 식별하려면 'to be'의 형태(is, was, are, were) 뒤에 과거 분사(보통 _-ed_로 끝나거나 written, created, _deleted_와 같은 불규칙 형태)가 오는 것을 찾으세요.
| 수동태 | 능동태 |
|---|---|
| ISM 정책을 사용하여 인덱스 작업을 자동화하는 것이 권장됩니다. | ISM 정책을 사용하여 인덱스 작업을 자동화하는 것을 권장합니다. |
| 설정을 변경하려면 구성 파일을 편집할 수 있습니다. | 설정을 변경하려면 구성 파일을 편집하세요. |
모든 문장에는 명시적인 주어가 있어야 합니다. 능동태는 행위자를 명명하도록 요구함으로써 이를 강화합니다. 특히 조건절 뒤에서는 주어를 생략하지 마세요.
| 올바름 | 올바르지 않음 |
|---|---|
| 경로가 존재하지 않으면 프로세서가 이를 생성하려고 시도합니다. | 경로가 존재하지 않으면 생성하려고 시도합니다. |
| 활성화되면 샤드 요청 캐시가 자주 액세스되는 결과를 저장합니다. | 활성화되면 자주 액세스되는 결과를 저장합니다. |
예외: 매개변수 테이블에서는 첫 번째 열의 매개변수 이름이 주어 역할을 하므로 부울 매개변수 설명에서 주어를 생략할 수 있습니다. 예: "If true, the response includes detailed information about shard recovery."
다음 경우에는 수동태를 사용하세요:
- 행위의 수신자가 행위자보다 더 중요한 경우: "사용자 데이터는 저장되기 전에 암호화되었습니다."
- 인간 행위자가 없는 시스템 동작을 설명하는 경우: "요청은 기본 샤드로 라우팅됩니다."
시제
시스템 동작, API 응답 및 기능 설명에는 현재 시제를 사용하세요.
| 올바름 | 올바르지 않음 |
|---|---|
| 이 매개변수를 설정하면 OpenSearch가 사용자 정의 분석기를 사용합니다. | 이 매개변수를 설정하면 OpenSearch가 사용자 정의 분석기를 사용할 것입니다. |
| 응답에는 일치하는 문서가 포함됩니다. | 응답에는 일치하는 문서가 포함될 것입니다. |
미래 시제는 현재 작업보다 나중에 발생하는 이벤트를 언급할 때만 사용하세요: "모델 ID를 기록하세요. 다음 단계에서 사용할 것입니다."
관사
관사를 사용하여 특정한 것(the)을 가리키는지 일반적인 것(a/an)을 가리키는지 지정하세요:
- 처음으로 무언가를 소개하거나 그룹 중 하나를 가리킬 때는 a 또는 an(부정 관사)을 사용하세요. 예: "send a query."
- 특정하거나 이전에 언급되었거나 일반적으로 이해되는 것을 가리킬 때는 the(정관사)를 사용하세요. 예: "the response contains the matching documents." 여기에는 다음이 포함됩니다:
- 테이블의 매개변수 및 필드 설명: "The request-level parameter takes precedence over..." ("Request-level parameter takes precedence over..."가 아님).
- 본문의 API 이름: "use the Create Channel Configuration API" ("use Create Channel Configuration API"가 아님).
- 추상적인 아이디어나 일반적으로 사용되는 복수 명사를 가리킬 때는 관사를 사용하지 마세요. 예: "users have access to logs."
명사 수식어
명사가 다른 명사를 수식할 때(명사 부가어)는 소유격 없이 단수 형태를 사용하세요. 간단한 명사 수식어로 충분할 때는 's를 사용하지 마세요.
| 올바름 | 올바르지 않음 |
|---|---|
| 스냅샷 파일 | 스냅샷들 파일, 스냅샷의 파일 |
| 샤드 할당 | 샤드의 할당 |
| 클러스터 상태 | 클러스터의 상태 |
That과 Which
필수(제한) 절에는 _that_을 사용하고, 비필수(비제한) 절에는 _which_를 사용하세요. 절을 제거해도 문장의 의미가 변하지 않으면 쉼표와 함께 _which_를 사용하세요. 절이 의미에 필수적이면 쉼표 없이 _that_을 사용하세요.
필수 절은 문장의 의미에 필요한 정보를 제공합니다. 쉼표로 분리하지 마세요:
각 문서에는 문서가 쿼리와 얼마나 잘 일치하는지 알려주는 관련성 점수 _that_이 할당됩니다.
"that tells you how well the document matched the query"를 제거하면 의미가 바뀝니다. 이 정보가 없으면 독자는 관련성 점수가 무엇을 하는지 알 수 없습니다.
OpenSearch는 텍스트가 용어로 분할되는 방식을 사용자 정의할 수 있는 다양한 분석기 _that_을 제공합니다.
"That let you customize..."는 필수적입니다. 이 분석기가 무엇을 하는지 정의합니다. 이 정보가 없으면 문장은 OpenSearch가 분석기를 제공한다는 것만 전달하여 너무 모호합니다. 여기서 ", which"를 사용하면 사용자 정의 기능이 주요 요점이 아닌 괄호 안의 부가 설명이라는 의미를 잘못 전달하게 됩니다.
비필수 절은 의미를 바꾸지 않고 제거할 수 있는 추가 정보를 제공합니다. 쉼표로 분리하세요:
각 클러스터에는 인덱스 생성과 같은 클러스터 수준 작업을 조정하는 선출된 클러스터 관리자 노드, _which_가 있습니다.
"which orchestrates cluster-level operations such as creating an index"를 제거해도 핵심 의미는 바뀌지 않습니다. 문장은 여전히 클러스터 관리자 노드를 식별합니다.
무언가가 하나만 있을 때는 "which"를 사용하세요: 명사가 고유한 경우(이름, 링크 또는 컨텍스트로 식별됨) 독자가 이미 식별할 수 있으므로 추가 정보는 항상 비필수적입니다. ", which"를 사용하세요:
IB유사도는 기호 분포에서 기본 요소의 반복적 사용을 분석하는 정보 기반 모델, _which_을 사용합니다.
참조되는 정보 기반 모델은 하나뿐입니다(링크됨). 절은 정보를 추가하지만 어떤 모델인지 식별하는 데 도움이 되지 않으므로 비필수적입니다.
이 분석기는 사용 전에 설치해야 하는
analysis-stempel플러그인, _which_의 일부입니다.
analysis-stempel 플러그인은 하나뿐입니다. "which must be installed before use" 절은 중요한 정보를 추가하지만 플러그인을 식별하는 데 도움이 되지 않으므로 비필수적입니다. 여기서 "that"을 사용하면 여러 analysis-stempel 플러그인이 있고 그중 하나를 지정한다는 의미를 잘못 전달하게 됩니다.
rating과num_reviews모두에 대한 값을 포함하는 문서 1과 2, _which_만 고려됩니다.
문서 1과 2는 이미 번호로 식별됩니다. 절은 왜 고려되는지 설명하지만 어떤 문서인지 식별하는 데 도움이 되지 않으므로 비필수적입니다.
"which X"보다 "the X that"을 선호하세요: 주어를 직접 식별할 수 있을 때는 모호한 참조로 "which"를 사용하지 마세요.
| 올바름 | 올바르지 않음 |
|---|---|
| 패턴과 일치하는 인덱스를 결정하세요. | 어떤 인덱스가 패턴과 일치하는지 결정하세요. |
절 목적어를 취하는 동사 뒤에는 "that"을 사용하세요: detect, ensure, verify, confirm, indicate, _specify_와 같은 동사는 모호함을 피하기 위해 절 앞에 "that"이 필요합니다.
| 올바름 | 올바르지 않음 |
|---|---|
| 클러스터 관리자가 노드가 연결 해제되었음을 that 감지하면... | 클러스터 관리자가 노드가 연결 해제되었음을 감지하면... |
| 시스템은 설정이 활성화되었음을 that 보장합니다. | 시스템은 설정이 활성화되었음을 보장합니다. |
예외: 명령문(독자에 대한 명령)에서는 모호함이 없으므로 "that"은 선택 사항입니다: "Ensure a majority of voting nodes remain available."
분사구문 오류
분사구문 오류는 문장 시작 부분에 있는 분사구로, 암시된 주어가 주절의 실제 주어와 일치하지 않는 경우입니다. 독자는 쉼표 바로 뒤에 오는 주어가 도입구에서 동작을 수행하는 주어일 것으로 기대합니다.
| 올바름 | 올바르지 않음 |
|---|---|
| 사용 사례를 선택하면 페이지가 나타납니다. | 사용 사례를 선택한 후 페이지가 나타납니다. |
| 클러스터를 구성하면 노드가 다시 시작됩니다. | 클러스터를 구성한 후 노드가 다시 시작됩니다. |
| 설정을 활성화하면 결과가 변경되는 것을 볼 수 있습니다. | 설정을 활성화한 후 결과가 변경됩니다. |
이는 사용자 작업 다음에 시스템 응답이 이어지는 경우 기술 문서에서 흔히 발생합니다. 분사구문 오류를 수정하려면 도입구에 명시적 주어를 추가하거나("After you select...") 주절의 주어를 암시된 행위자와 일치시키세요("After selecting..., you see...").
구두점
구두점에 관한 다음 지침을 따라요.
마침표
- 마침표 뒤에는 공백을 하나만 사용해요.
느낌표
- 문서에서는 느낌표를 사용하지 마세요. 기술 콘텐츠는 사실적이어야 하며, 열정적이지 않아야 해요.
줄임표
- 산문에서는 줄임표를 사용하지 마세요. 코드 블록과 출력 예제에서는 줄임표(
...)를 사용하여 생략되거나 잘린 내용을 나타낼 수 있어요.
쉼표
- 등위 접속사(but, or, yet, for, and, nor, so)로 연결된 독립절을 구분할 때 쉼표를 사용해요. 접속사 양쪽에 주어와 동사가 있어야 쉼표가 필요해요: "설정은 동적이므로 클러스터를 다시 시작하지 않고도 기본 동작을 변경할 수 있어요."
- 명사를 수식하는 두 형용사가 순서를 바꾸거나 "and"로 분리할 수 있을 때는 쉼표를 사용해요: "확장 가능한, 분산된 검색 엔진."
- 도입절, 구, 단어 뒤에는 쉼표를 사용해요: "클러스터가 비정상이면 노드 로그를 확인하세요."
- 세 개 이상의 항목을 나열할 때 옥스포드 쉼표를 사용해요: "OpenSearch는 스냅샷, 복제, 교차 클러스터 검색을 지원해요." 두 항목만 결합할 때는 "or"나 "and" 앞에 쉼표를 사용하지 마세요: "OpenSearch는 스냅샷과 복제를 지원해요."
- "such as" 앞에 쉼표를 사용해요. 예시가 비제한적(의미를 바꾸지 않고 제거 가능)일 때: "메모리 컨테이너의 속성(예: 이름, 설명, 액세스 권한)을 업데이트하세요." "such as"가 의미를 제한할 때는 쉼표를 생략해요: "
analysis-icu같은 플러그인은 별도 설치가 필요해요." - 복합 술어(하나의 주어에 두 동사)에서는 동사 사이에 쉼표를 사용하지 마세요: "OpenSearch는 쿼리를 평가한 다음 일치하는 문서를 반환해요."
- "but"이 두 독립절을 연결하지 않을 때는 앞에 쉼표를 사용하지 마세요: "
external과 유사하지만 소스 버전이 더 큰 경우에만 문서를 업데이트해요." - "so that"이 목적절을 이끌 때는 앞에 쉼표를 사용하지 마세요: "적은 수의 게시 목록만 방문하도록 상위 토큰만 유지해요."
- "because"가 필수적인 이유를 나타낼 때는 앞에 쉼표를 사용하지 마세요: "벡터 필드를 객체로 매핑하는 것을 권장해요. 파싱 없이 원시 벡터를 저장하기 때문이에요."
- 동작에 필수적인 분사 구문 앞에는 쉼표를 사용하지 마세요: "프로세서의 정렬된 목록을 지정하여 엔드포인트에 요청을 보내세요." (원문: "...endpoint, specifying..."이 아님)
- 쉼표만으로 두 독립절을 연결하지 마세요(쉼표 접합). 세미콜론을 사용하거나 두 문장으로 다시 작성하세요: "기존 필드의 매핑은 변경할 수 없어요; 매핑 매개변수만 수정할 수 있어요." (원문: "...existing field, you can only..."이 아님)
콜론
- 예제 블록(예: 코드 및 스크립트)과 대부분의 목록을 소개할 때 콜론을 사용해요. 표나 이미지를 소개할 때는 콜론을 사용하지 마세요.
- 콜론이 구문을 소개할 때는 콜론 다음 첫 단어를 소문자로 써요. 고유명사인 경우는 제외해요.
- 콜론이 하나 이상의 완전한 문장을 소개할 때는 콜론 다음 첫 단어를 대문자로 써요.
- 텍스트가 표나 이미지를 소개할 때는 완전한 문장이어야 하며 마침표로 끝내야 해요. 콜론으로 끝내지 마세요.
대시
- 엠 대시(—): 양쪽에 공백을 넣지 마세요. 문장 내에서 괄호 구문을 구분하거나 문장 끝에서 재진술이나 강조를 위해 사용해요. 마크다운에서는 세 개의 대시(
---)를 사용해요. - 엔 대시(–): 범위에서는 양쪽에 공백을 넣지 마세요. 값과 날짜 범위(예: "2–6")나 목록에서 글머리 기호 제목과 다음 텍스트를 구분할 때 사용해요(예: "전문 검색 – 전문 검색 수행"). 마크다운에서는 두 개의 대시(
--)를 사용해요.
하이픈 사용
하이픈을 사용하여 복합 형용사, 명사 또는 숫자를 구분해요. 복합 형용사는 수식하는 명사 앞에 올 때는 하이픈을 사용하고, 명사 뒤에 올 때는 사용하지 않아요.
| 명사 앞(하이픈 사용) | 명사 뒤(하이픈 없음) |
|---|---|
| 노드는 대소문자를 구분하는 이름을 가져요. | 노드 이름은 대소문자를 구분해요. |
| 이 주소는 클러스터 관리자 자격이 있는 노드를 지정해요. | 해당 주소의 노드는 클러스터 관리자 자격이 있어요. |
| 실시간 대시보드가 현재 데이터를 보여줘요. | 대시보드는 실시간으로 업데이트돼요. |
| 인덱스 수준 권한을 구성하세요. | 인덱스 수준에서 권한을 구성하세요. |
추가 하이픈 사용 규칙:
- 항상 하이픈 사용: 일부 복합어는 위치에 관계없이 항상 하이픈을 사용해요(cross-cluster, read-only, built-in, key-value, self-signed, end-to-end, lock-free, schema-free).
- -ly로 끝나는 부사: 하이픈을 사용하지 마세요("a highly available cluster," not "a highly-available cluster").
- 비교급 또는 최상급 수식어: more, most, less, _least_가 포함된 구문은 모호한 경우가 아니면 하이픈을 사용하지 마세요("more accurate result," "less useful method").
- 단일 문자 접두사: 항상 하이픈을 사용해요(n-gram, k-NN, e-commerce).
- 철자로 표기된 분수: 항상 하이픈을 사용해요(one-third of nodes).
- 접두사(pre-, post-, non-): 일반적으로 붙여 써요(pretrained, preconfigured, predefined). 기본 단어가 모음이나 대문자로 시작하거나 붙여 썼을 때 모호한 경우 하이픈을 사용해요(pre-filtering, post-processing, non-production, pre-migration, post-migration).
- Multi-: 알려진 단어나 확립된 기술 용어인 경우 붙여 써요(multidimensional, multithreaded, multivalued). 그 외에는 하이픈을 사용해요(multi-node, multi-match, multi-search).
- 업계 예외: 일부 업계 용어는 표준 하이픈 사용 규칙을 따르지 않아요. 예를 들어, _high performance computing_은 하이픈을 사용하지 않고, _machine learning_은 형용사로 사용될 때 하이픈을 사용하지 않아요.
확실하지 않으면 Merriam-Webster를 확인하거나 OpenSearch 특정 사용법은 Terms를 참조하세요.
따옴표와 아포스트로피
- 곧은 따옴표(")와 아포스트로피(')를 사용하고, 둥근 따옴표(”, ’)는 사용하지 마세요.
- 쉼표와 마침표는 닫는 따옴표 안에 넣어요. 인용된 텍스트가 정확한 값이나 구문을 나타내며 불필요한 구두점을 포함해서는 안 되는 경우 쉼표와 마침표를 밖에 넣어요.
- 사용자가 입력하거나 시스템이 반환하는 명령어, 매개변수, 값에는 따옴표 대신 코드 글꼴을 사용해요. 자리 표시자 규칙(꺾쇠괄호 vs. 중괄호)은 텍스트 서식 가이드의 코드 예제를 참조하세요.
- 좀 더 캐주얼한 톤을 위해 일반적인 축약형(don't, isn't, you're, it's)을 사용해요. 하지만 미래 시제(I'll), 고어('twas), 구어체(ain't), 복합 축약형(couldn't've)은 피하세요.
- "s"로 끝나는 명사의 복수형은 아포스트로피만 추가하여 소유격을 만들어요.
세미콜론
- 접속사 없이 밀접하게 관련된 두 독립절을 연결할 때 세미콜론을 사용해요: "기존 필드의 매핑은 변경할 수 없어요; 매핑 매개변수만 수정할 수 있어요."
- 두 독립절을 연결하는 접속 부사(however, therefore, consequently, otherwise) 앞에 세미콜론을 사용해요: "인덱스가 삭제되었어요; 따라서 데이터를 더 이상 사용할 수 없어요."
- 쉼표로 충분할 때는 세미콜론을 사용하지 마세요.
앰퍼샌드
- 문장이나 제목에서 "and"를 대체하기 위해 앰퍼샌드(&)를 사용하지 마세요.
슬래시
- 슬래시 양쪽에 공백을 넣지 마세요(_AI/ML_이 맞고, _AI / ML_은 틀려요).
- 동작이나 목록 항목을 구분하기 위해 슬래시를 사용하지 마세요. 대신 접속사와 함께 쉼표를 사용하세요("create, update, or manage"이지 "create/update/manage"가 아니에요).
괄호
- 처음 사용 시 약어나 두문자어를 소개하기 위해 괄호를 사용해요: "machine learning (ML)."
- 본문에 필수적이지는 않지만 도움이 되는 추가 정보를 위해 괄호를 사용해요. 괄호 안이 완전한 문장이면 마침표를 닫는 괄호 안에 넣어요. 그렇지 않으면 마침표를 밖에 넣어요.
- 더 강한 강조를 위해 엠 대시를, 가벼운 삽입을 위해 쉼표를 선호해요. 괄호는 흐름을 방해하지 않는 진정한 보충 내용을 위해 사용하세요.
대문자 사용
대문자 사용에 관한 다음 지침을 따라요:
- 제목, 표제, 표 머리글에는 문장형 대소문자를 사용해요. 독립 문서의 제목은 제목형 대소문자를 사용할 수 있어요.
- 고유명사가 아닌 명사와 명사구는 소문자를 사용해요. 예: big data.
- API 매개변수를 언급할 때는 _Boolean_을 대문자로 써요. 그 외에 기본 Java 데이터 타입(byte, short, int, long, float, double, char)은 소문자로 시작하고, 비기본 타입은 대문자로 시작해요.
단어 선택
단어 선택에 관한 다음 지침을 따라요:
- 명확하고 직접적인 언어를 사용해요. 자세한 내용은 Plain language guide series를 참조하세요.
- 전문 용어, 구동사, 구어체, 비즈니스 유행어를 피하세요.
- 미국 영어 철자를 사용해요(예: "organize"이지 "organise"가 아니에요).
단일 동사 사용
다중 단어 동사(구동사)를 정확한 단일 동사로 대체하세요.
| 올바른 표현 | 잘못된 표현 |
|---|---|
| configure or initialize | set up |
| provision or start | spin up |
| stop or terminate | shut down |
| deploy or release | roll out |
| determine or identify | figure out |
| import or retrieve | pull in |
번역에 친화적인 언어 사용
문화나 언어에 따라 번역되지 않을 수 있는 구어체와 관용구를 대체하세요.
| 올바른 표현 | 잘못된 표현 |
|---|---|
| by default, natively, or built-in | out of the box |
| internally | under the hood |
| manually or without a template | from scratch |
| configuration or infrastructure | plumbing |
평이한 언어 사용
비즈니스 유행어를 평이한 대안으로 대체하세요.
| 올바른 표현 | 잘못된 표현 |
|---|---|
| use | leverage |
| use | utilize |
| help or enable | facilitate |
| collaboration | synergy |
정확한 동사 사용
모호한 동사를 구체적인 대안으로 대체하세요.
| 올바른 표현 | 잘못된 표현 |
|---|---|
| receive, retrieve, or obtain | get |
| manage, process, or resolve | handle |
| view | see |
| specify or configure | tell |
| require or expect | want |
| detect or recognize | know about |
| communicate with or connect to | talk to |
소프트웨어에 중립적인 언어 사용
소프트웨어나 시스템에 인간의 특성이나 행동을 부여하지 마세요.
| 올바른 표현 | 잘못된 표현 |
|---|---|
| OpenSearch가 요청을 받아요 | OpenSearch가 요청을 봐요 |
| 파일이 이 디렉터리에 있어요 | 파일이 이 디렉터리에 살아요 |
| 클러스터가 노드 상태를 추적해요 | 클러스터가 어떤 노드가 정상인지 알아요 |
"where"는 위치에만 사용
"where"는 물리적 또는 논리적 위치에만 사용해요. 다른 맥락에서는 "in which"를 사용하세요: "the request in which the parameter is specified"("the request where the parameter is specified"가 아님).
정보를 직접 제공
문서 구조를 설명하는 것을 피하세요. 예를 들어, "이 섹션에서는 ...을 설명합니다." 대신 유용한 정보를 직접 제공하세요.
모든 기술 수준을 위해 작성
작업이 독자에게 쉽다고 가정하는 단어를 사용하지 마세요. "easily", "simply", "just"와 같은 단어를 피하세요. 한 독자에게 쉬운 것이 다른 독자에게는 쉽지 않을 수 있어요.
Acronyms
약어 및 축약어에 대해 다음 지침을 사용하세요:
- 페이지에서 약어를 처음 사용할 때는 풀어서 쓰고 괄호 안에 약어를 함께 표시하세요.
spelled-out term (acronym)형식을 사용하세요. 이후에는 약어만 사용하세요. - 약어의 풀어쓴 형태는 고유 명사나 커뮤니티에서 일반적으로 대문자로 쓰는 경우가 아니라면 대문자로 쓰지 마세요.
- 일반적으로 페이지에서 약어는 한 번 풀어서 쓰세요. 명확성을 위해 더 자주 풀어쓸 수 있습니다.
- 약어의 복수형은 끝에 _s_를 붙여서 만드세요. 아포스트로피는 추가하지 마세요.
- 약어의 발음에 따라 앞에 관사 an 또는 _a_를 사용합니다. 첫소리가 모음 소리로 발음되면 _an_을 사용하고, 그렇지 않으면 _a_를 사용하세요.
- 약어의 첫 사용이 제목에 있는 경우, 제목에는 약어를 유지하고, 다음 본문에서 용어를 풀어쓰고 괄호 안에 약어를 표시하세요.
- 일반적으로 -bit 또는 _-byte_로 끝나는 약어는 풀어서 쓰세요. 특정 측정값에서 숫자와 함께만 약어를 사용하세요(예: "100 GB"). 숫자와 단위 사이에는 항상 공백을 포함하세요(Numbers and measurement 참조). 잘 알려져서 풀어쓸 필요가 없는 약어는 KB, MB, GB, _TB_입니다.
다음 표는 풀어쓸 필요가 없는 약어를 나열합니다.
| Acronym | Spelled-out term |
|---|---|
| 3D | three-dimensional |
| AI | artificial intelligence |
| API | application programming interface |
| ASCII | American Standard Code for Information Interchange |
| BASIC | Beginner's All-Purpose Symbolic Instruction Code |
| BM25 | Best Match 25 |
| CLI | command-line interface |
| CPU | central processing unit |
| CRUD | create, read, update, and delete |
| CSV | comma-separated values |
| DNS | Domain Name System |
| DOS | disk operating system |
| Faiss | Facebook AI Similarity Search |
| FAQ | frequently asked questions |
| FTP | File Transfer Protocol |
| GIF | Graphics Interchange Format |
| HTML | hypertext markup language |
| HTTP | hypertext transfer protocol |
| HTTPS | hypertext transfer protocol secure |
| HTTP(S) | HTTP and HTTPS (use to refer to both protocols) |
| I/O | input/output |
| ID | identifier |
| IP | Internet protocol |
| JPEG | Joint Photographic Experts Group |
| JSON | JavaScript Object Notation |
| k-NN | k-nearest neighbors |
| MS MARCO | Microsoft Machine Reading Comprehension |
| NAT | network address translation |
| NGINX | engine x |
| NMSLIB | Non-Metric Space Library |
| Portable Document Format | |
| RAM | random access memory |
| REST | Representational State Transfer |
| RGB | red-green-blue |
| ROM | read-only memory |
| RPM | RPM Package Manager |
| SAML | Security Assertion Markup Language |
| SDK | software development kit |
| SSL | Secure Sockets Layer |
| TCP | Transmission Control Protocol |
| TIFF | Tagged Image File Format |
| TLS | Transport Layer Security |
| UI | user interface |
| URI | uniform resource identifier |
| URL | uniform resource locator |
| UTC | Coordinated Universal Time |
| UTF | Unicode Transformation Format |
| XML | Extensible Markup Language |
| YAML | YAML Ain't Markup Language |
| YUM | Yellowdog Updater Modified |
Numbers and measurement
- 1부터 9까지의 기수는 철자로 쓰세요(예: "one NAT instance"). 10 이상은 숫자를 사용하세요.
- 서수는 철자로 쓰세요: first, second 등.
- 10 이상의 숫자가 포함된 시리즈에서는 모두 숫자를 사용하세요.
- 네 자리 이상의 숫자에는 쉼표 구분자를 사용하세요(예: 1,000).
- 예외: 숫자가 매개변수 값을 직접 참조하거나 같은 문장에서 다른 숫자와 함께 나타나는 경우 숫자를 사용하세요(예: 쿼리에서
k=3일 때 "return the 3 hotels", 또는 "a rating between 8 and 10... the 3 hotels"). - 시간 범위의 경우 숫자를 en dash로 구분하세요. "between"이나 "from n to n"과 같은 추가 단어는 피하세요: "It can take 5–10 minutes before logs are available" ("between 5 and 10 minutes"가 아님).
- 시간을 포함한 모든 측정 기반 참조에는 숫자를 사용하세요. 숫자와 측정 단위 사이에 공백을 포함하세요: "100 GB", "1 TB", "3 minutes" ("One hundred GB" 또는 "1TB"가 아님).
Topic titles
주제 제목에 다음 스타일 중 하나를 사용하세요:
- Present participle phrase, used most often for concept or task topics: "Configuring security," "Visualizing your data," "Running queries in the console."
- Noun-based phrase, used most often for reference topics: "REST API reference," "OpenSearch CLI," "Field types."
예제 블록(예: 코드, 스크립트, API 요청 및 응답)을 소개하는 제목에는 _sample_이 아닌 _example_을 사용하세요.