Merge pull request Azure#122 from Cor5in/cor5in

'repobranching.md, compatibility.md' translation in korea

docs/general/compatibility.md

@@ -6,46 +6,44 @@ folder: general
 sidebar: general_sidebar
 ---
 
-This section describes guidelines related to compatibility. In particular, it describes high-level compatibility principles, and detailed rules for reasoning about API and behavioral changes introduced as we evolve our libraries.
+이 섹션은 호환성과 관련된 가이드라인을 설명합니다. 특히, 라이브러리를 발전시키면서 도입되는 API와 동작 변경에 대한 높은 수준의 호환성 원칙과 상세한 규칙에 대해 다룹니다.
 
-## Compatibility Principles
-One of the main general principles of the Azure SDK is that it is **Dependable**, and one of the main aspects of dependability is a high level of compatibility. 
+## 호환성 원칙
+Azure SDK의 주요 일반 원칙 중 하나는 **의존성**이며, 의존성의 주요 측면 중 하나는 높은 수준의 호환성입니다.
 
-In the context of these guideline, compatibility means that software written using one version of our libraries should function correctly when upgraded to a newer version of the same library, as long as it calls the same version of the service REST API as it was calling before the upgrade.
-This is to ensure that developers using the Azure SDK can upgrade to new versions of our libraries without immediately being subjected to a large cost of fixing resulting breaks. 
-This is good for our customers, as it lowers their costs, and it's good for us, as it helps in the adoption of new Azure features, i.e. a win-win.
+이러한 지침에서 호환성이란, 한 버전의 라이브러리를 사용하여 작성된 소프트웨어가 더 높은 버전의 같은 라이브러리로 업그레이드되더라도 이전 업그레이드 전과 동일한 서비스 REST API 버전을 호출한다면 올바르게 동작해야 함을 의미합니다.
+이를 통해 Azure SDK를 사용하는 개발자들은 새로운 라이브러리 버전으로 업그레이드할 때 큰 비용을 들여 오류를 수정할 필요 없이 업그레이드할 수 있습니다.
+또한 이것은 고객에게 비용을 절감해주는 것이며, 새로운 Azure 기능의 채택에 도움이 되므로 상호 이익적인 관계입니다.
 
-Having said that, you can always imagine code, even if contrived, that will break when upgraded to a new version of a library that simply adds functionality, fixes bugs, or runs faster. 
-Also, there are some incompatible changes that are worth doing, e.g. changes required to fix security bugs. 
-And so given that absolute compatibility is not possible in practice, we want to be best-in-class, which as a rule of thumb means being on par with base libraries of the corresponding language.
+물론, 앞서 언급한 내용에 따르면, 라이브러리의 새 버전으로 업그레이드하더라도 기능을 추가하거나 버그를 수정하거나 실행 속도를 개선하는 등의 변경사항으로 인해 단순히 업그레이드만으로는 항상 호환성이 보장되지는 않을 수 있습니다. 또한 보안 버그를 수정하는 데에는 일부 호환성을 깨는 변경이 필요할 수도 있습니다. 그렇기 때문에 절대적인 호환성을 보장하는 것은 실제로 불가능하며, 대신 우리는 최고 수준의 호환성을 목표로 하고 있습니다. 대략적인 기준으로는 해당 언어의 기본 라이브러리와 동등한 수준의 호환성을 유지하는 것을 지향합니다.
 
-Principle #1: Azure SDK libraries must be as compatible or better than the base libraries of their language. For example, Azure SDK for .NET libraries must be as compatible as the .NET Base Class Libraries.
+원칙 #1:  Azure SDK 라이브러리는 해당 언어의 기본 라이브러리와 호환성이 동등하거나 더 좋아야 합니다. 예를 들어, .NET용 Azure SDK 라이브러리는 .NET 기본 클래스 라이브러리와 호환성이 동등해야 합니다.
 
-### Azure SDK Compatibility Reviews
-Azure SDK guidelines define details of what's considered a compatible change in each language ecosystem. All changes that are not explicitly designated as compatible, need to be reviewed and approved by the Azure SDK Architecture Board. 
+### Azure SDK 호환성 검토
+Azure SDK 가이드라인은 각 언어 생태계에서 호환성을 보장하는 변경 사항에 대한 세부 정보를 정의합니다. 명시적으로 호환성이 지정되지 않은 모든 변경 사항은 Azure SDK 아키텍처 위원회의 검토와 승인을 거쳐야 합니다.
 
-### API Changes
-It might seem that additions to the APIs would be non-breaking, and removals would be breaking. Unfortunately, it's not as simple. Languages differ quite significantly in terms of what API changes would result in breaks in the caller. In particular, there are very significant differences between dynamic and static languages. Therefore, you should refer to language specific guidelines for details of what constitutes an acceptable API change.
+### API 변경
+API에 새로운 기능이 추가되는 경우, 일반적으로 호환성을 깨지 않지만, 기존 기능이 삭제되는 경우에는 호환성을 깨는 요소로 보일 수 있습니다. 그러나 이 문제는 간단하지 않습니다. 언어에 따라 호출자에서 브레이크가 발생하는 API 변경이 상당히 다를 수 있습니다. 특히 동적 언어와 정적 언어 사이에는 매우 큰 차이가 있습니다. 따라서 호환성이 허용되는 API 변경에 대한 자세한 내용은 해당 언어별 가이드라인을 참조해야 합니다. 
 
-Behavioral compatibility is more language independent, and so it's described below. 
+동작 호환성은 언어에 상대적으로 덜 종속적이므로 이에 대한 설명은 아래에서 확인할 수 있습니다.
 
 ### Behavioral Changes
 
-TBD
+미정
 
-#### Logging Changes
-Changes to the output of logs generated by a library are treated separately from other behavioral change, and they are described in this section.
+#### Logging 변경
+로그 라이브러리에서 생성되는 로그 출력에 대한 변경은 다른 동작 변경과는 별도로 처리됩니다. 아래의 글은 이에 대한 설명입니다.
 
-Many customers build scripts and tools that automatically analyze logs. Just like we don't want software calling our APIs to break when the software is upgraded to new versions of our libraries, we don't want log analysis tools and scripts to break.
+많은 고객들이 로그를 자동으로 분석하는 스크립트와 도구를 사용합니다. 따라서 소프트웨어가 우리의 API를 호출할 때 새로운 라이브러리 버전으로 업그레이드되어도 소프트웨어 호출이 깨지지 않도록 주의해야 합니다. 마찬가지로 로그 분석 도구와 스크립트 역시 깨지지 않기를 바랍니다.
 
-Logs can be seen as a sequence of entries, and entries can be seen as a sequence of tokens that can be parsed by tools. Entry tokens can be further divided into schema related tokens (i.e. tokens that don't vary between instances of entries), and data tokens (tokens that can, and often do, vary between instances of entries, e.g. the time when an entry was logged).
+로그는 항목들의 시퀀스로 간주될 수 있으며, 각 항목은 도구에 의해 구문 분석될 수 있는 토큰들의 시퀀스로 해석됩니다. 항목 토큰들은 스키마 관련 토큰과 데이터 토큰으로 나뉠 수 있습니다. 스키마 관련 토큰은 항목들의 인스턴스 간에 변하지 않는 토큰들이며, 데이터 토큰은 항목들의 인스턴스 간에 변할 수 있는 토큰들입니다. 예를 들어, 항목에는 로그가 기록된 시간과 같은 정보를 포함할 수 있습니다.
 
-Changes allowed in a new major or minor version of a package (not a patch version):
+새로운 주요 또는 부 버전의 패키지에서 허용되는 변경 사항은 다음과 같습니다:
 
-- Additional log entries, e.g. new version logs request details on every retry, while the old version logged only once per retry.
-- Additional entry types (entries with a new schema).
+-  추가적인 로그 항목들을 포함시키는 것입니다. 예를 들어, 새로운 버전은 각 재시도마다 요청에 대한 세부 정보를 기록할 수 있지만, 이전 버전은 재시도당 한 번만 기록할 수 있습니다.
+- 새로운 스키마를 가진 항목 유형을 추가합니다.
 
-All other changes allowed only when:
+그러나 다른 모든 변경 사항들은 다음의 경우에만 허용됩니다:
 
-- Approved by the Azure SDK Architecture Board, and 
-- User must opt into the new behavior by specifying a new API version or a client option.
+- Azure SDK 아키텍처 위원회의 승인을 받아야 합니다.
+- 사용자는 새로운 동작을 선택하기 위해 새로운 API 버전 또는 클라이언트 옵션을 지정해야 합니다.