context in code => 컨텍스트, context in the other places => 맥락

src/ch03-00-common-programming-concepts.md

@@ -3,8 +3,8 @@
 이 장은 거의 모든 프로그래밍 언어에서 나타나는 개념들과 그 개념들이
 러스트에서 어떻게 다루어지는지 소개합니다. 많은 프로그래밍 언어들은 
 핵심이 비슷합니다. 이 장에서는 러스트 고유의 특성은 소개하지 않겠지만,
-러스트의 문맥 속에서 특성들을 사용해가며
-관례 또한 설명할 것입니다.
+러스트의 맥락에서 논의하고 이러한 개념 사용과 관련된 관례들을
+설명하겠습니다.
 
 특히 당신은 변수, 기본 타입, 함수, 주석, 제어문에 대해서 배울 것입니다.
 이 기초는 모든 러스트 프로그램에 사용될 것이며, 이들을 일찍 익히는 것은

src/ch04-01-what-is-ownership.md

@@ -280,7 +280,7 @@ style="width: 50%;" />
 문자열 길이와 메모리 용량이 무슨 차이인가 궁금하실 분들을 위해 간단히 설명해드리자면,
 문자열 길이는 `String` 의 내용이 현재 사용하고 있는 메모리를 바이트 단위로 나타낸 것이고,
 메모리 용량은 메모리 할당자가 `String` 에 할당한 메모리의 양을 뜻합니다.
-이번 내용에서는 길이, 용량 사이의 차이는 중요한 내용이 아니니,
+지금의 맥락에서는 길이, 용량 사이의 차이는 중요한 내용이 아니니,
 이해가 잘 안 되면 용량 값은 무시하셔도 좋습니다.
 
 `s2` 에 `s` 을 대입하면 `String` 데이터가 복사됩니다.

src/ch04-03-slices.md

@@ -66,12 +66,12 @@ fn first_word(s: &String) -> ?
 {{#rustdoc_include ../listings/ch04-understanding-ownership/listing-04-07/src/main.rs:inside_for}}
 ```
 
-문자열 첫 단어의 끝부분을 찾아 해당 인덱스를 반환하는 함수를 완성했습니다.
-하지만 함수에서 반환하는 `usize` 값이
-`&String` 의 내용에 의존적임에도 불구하고,
-`String` 과 분리되어 있다는 점이 아쉽군요.
-이대로라면, 앞으로도 이 값이 의미 있는 값일 거란 보장을 할 수가 없습니다.
-어떤 뜻인지 Listing 4-8 을 보고 생각해봅시다:
+이제 문자열에서 첫 번째 단어 끝의 인덱스를 찾는 방법이
+생겼지만, 문제가 있습니다. `usize`를 반환하고 있는데, 이는
+`&String`의 컨텍스트에서만 의미 있는 숫자일 뿐입니다. 바꿔
+말하면, `String`과는 별개의 값이기 때문에 향후에도 유효하다는
+보장이 없습니다. Listing 4-7의 `first_word` 함수를 사용하는
+Listing 4-8의 프로그램을 살펴봅시다.
 
 <span class="filename">Filename: src/main.rs</span>
 
@@ -80,7 +80,7 @@ fn first_word(s: &String) -> ?
 ```
 
 <span class="caption">Listing 4-8: `first_word` 함수의 결과를 저장했으나,
-이후에 `String` 의 내용이 변경된 상황</span>
+이후에 `String`의 내용물이 변경된 상황</span>
 
 이 코드는 문법적으로 전혀 문제없고, 정상적으로 컴파일됩니다.
 `s.clear()` 을 호출한 후에 `word` 를 사용하는 코드를 작성하더라도,

src/ch05-03-method-syntax.md

@@ -3,7 +3,7 @@
 *메서드(method)* 는 함수와 유사합니다.
 `fn` 키워드와 함수명으로 선언하고, 매개변수와 반환 값을 가지며,
 다른 어딘가로부터 호출될 때 실행됩니다.
-하지만 메서드는 함수와 달리 구조체 문맥상에 정의되고 (열거형이나
+하지만 메서드는 함수와 달리 구조체 컨텍스트 상에 정의되고 (열거형이나
 트레잇 객체 안에 정의되기도 하며, 이는 각각 [6장][enums]<!-- ignore -->,
 [17장][trait-objects]<!-- ignore -->에서 알아보겠습니다),
 첫 번째 매개변수가 항상 `self` 라는 차이점이 있습니다.
@@ -24,7 +24,7 @@ Listing 5-13 처럼 `Rectangle` 구조체에 정의된
 <span class="caption">Listing 5-13: `Rectangle` 구조체에
 `area` 메서드 정의</span>
 
-`Rectangle` 내에 함수를 정의하기 위해서, `Rectangle`에 대한 `impl`
+`Rectangle`의 컨텍스트 내에 함수를 정의하기 위해서, `Rectangle`에 대한 `impl`
 (구현, implementation) 블록을 만드는 것으로 시작합니다. 이 `impl` 블록 내의
 모든 것은 `Rectangle` 타입에 관련되게 됩니다. 그런 다음 `area` 함수를 `impl`의
 중괄호 안으로 옮기고 함수 시그니처의 첫번째 매개변수를 (이번 경우는 유일한

src/ch06-01-defining-an-enum.md

@@ -94,7 +94,7 @@ v4, v6 는 근본적으로 IP 주소이기 때문에, 이 둘은 코드에서
 
 구조체 대신 열거형을 사용할 때의 또 다른 장점이 있습니다.
 각 배리언트는 다른 타입과 다른 양의 연관된 데이터를 가질 수 있습니다.
-v4 IP 주소는 항상 0 ~ 255 사이의 숫자 4개로 된 구성요소를 갖게 될 것입니다.
+v4 IP 주소는 항상 0 ~ 255 사이의 숫자 4개로 된 구성 요소를 갖게 될 것입니다.
 `V4` 주소에 4개의 `u8` 값을 저장하길 원하지만, v6 주소는 하나의 String 값으로 표현되길 원한다면,
 구조체로는 이렇게 할 수 없습니다.
 열거형은 이런 경우를 쉽게 처리합니다:

src/ch07-02-defining-modules-to-control-scope-and-privacy.md

@@ -3,7 +3,7 @@
 이번에는 모듈, 아이템의 이름을 지정하는 *경로 (path)*,
 스코프에 경로를 가져오는 `use` 키워드,
 아이템을 공개하는 데 사용하는 `pub` 키워드를 알아보겠습니다.
-`as` 키워드, 외부 패키지, 글롭 연산자 등도 다룰 예정입니다.
+`as` 키워드, 외부 패키지, 글롭 (glob) 연산자 등도 다룰 예정입니다.
 
 우선은 여러분이 미래에 코드를 구조화할 때 쉽게 참조할 수 있는 규칙을
 나열하는 것으로 시작해 보겠습니다. 그 다음 각각의 규칙에 대한 세부 사항을

src/ch09-02-recoverable-errors-with-result.md

@@ -222,7 +222,7 @@ src/main.rs:5:10
 ```
 
 출시 가능한 품질의 코드에서 대부분의 러스트인들은 `unwrap` 보다 `expect`를
-선택하고 왜 해당 연산이 언제나 성공하기를 기대하는지에 대한 더 많은 내용을
+선택하고 왜 해당 연산이 언제나 성공하기를 기대하는지에 대한 더 많은 맥락을
 제공합니다. 이렇게 함으로써 여러분의 가정이 틀린것으로 판명났다면, 여러분은
 디버깅에 사용할 정보를 더 얻게 됩니다.
 
@@ -232,7 +232,7 @@ src/main.rs:5:10
 내에서 에러를 처리하는 대신, 에러를 호출하는 코드 쪽으로 반환하여
 그쪽에서 어떻게 할지 결정하도록 할 수 있습니다. 이는 에러 *전파하기 (propagating)* 로
 알려져 있으며, 에러가 어떻게 처리해야 좋을지 좌우해야 할 상황에서, 여러분의 코드
-내용 내에서 이용 가능한 것들보다 더 많은 정보와 로직을 가지고 있을 수도 있는
+컨텍스트 내에서 이용 가능한 것들보다 더 많은 정보와 로직을 가지고 있을 수도 있는
 호출하는 코드 쪽에 더 많은 제어권을 줍니다.
 
 예를 들면, Listing 9-6는 파일로부터 사용자 이름을 읽는 함수를 작성한 것입니다.
@@ -347,7 +347,7 @@ Listing 9-6의 `match` 표현식과 `?` 연산자의 차이점은,
 `?` 연산자 호출은 다른 코드를 추가할 필요없이 `from`을 호출하여 에러 타입을
 변환할 것입니다.
 
-Listing 9-7의 내용에서, `File::open` 호출 부분의 끝에 있는 `?`는
+Listing 9-7의 컨텍스트에서, `File::open` 호출 부분의 끝에 있는 `?`는
 `Ok`내의 값을 변수 `username_file`에게 반환해줄 것입니다. 만일 에러가
 발생하면 `?`는 전체 함수로부터 일찍 빠져나와 호출하는 코드에게 어떤
 `Err` 값을 줄 것입니다. `read_to_string` 호출의 끝부분에 있는 `?`도

src/ch09-03-to-panic-or-not-to-panic.md

@@ -67,7 +67,7 @@
 
 여러분의 코드가 결국 나쁜 상태에 처하게 될 가능성이 있을 때는
 여러분의 코드에 `panic!`을 넣는 것이 바람직합니다.
-이 글에서 말하는 나쁜 상태란 어떤 가정, 보장, 계약, 혹은 불변성이 깨질 때를 뜻하는 것으로,
+이 글에서 말하는 *나쁜 상태*란 어떤 가정, 보장, 계약, 혹은 불변성이 깨질 때를 뜻하는 것으로,
 이를테면 유효하지 않은 값이나 모순되는 값, 혹은 찾을 수 없는 값이 여러분의 코드를 통과할
 경우를 말합니다 - 아래에 쓰인 상황중 하나 혹은 그 이상일 경우라면 말이죠:
 

src/ch10-02-traits.md

@@ -304,8 +304,8 @@ fn some_function<T: Display + Clone, U: Clone + Debug>(t: &T, u: &U) -> i32 {
 이 경우 `returns_summarizable` 는 `Tweet` 을 반환하지만,
 이 함수를 호출하는 쪽의 코드에서는 구체적인 타입을 알 필요가 없습니다.
 
-구현되는 트레잇으로 반환 타입을 명시하는 기능은 13장에서
-다룰 클로저 및 반복자 문법에서 굉장히 유용합니다. 클로저와
+구현되는 트레잇으로 반환 타입을 명시하는 기능은 13장에서 다룰
+클로저 및 반복자의 컨텍스트에서 굉장히 유용합니다. 클로저와
 반복자는 컴파일만 아는 타입이나, 직접 명시하기에는 굉장히
 긴 타입을 생성합니다. `impl Trait` 문법을 사용하면 굉장히
 긴 타입을 직접 작성할 필요 없이 `Iterator` 트레잇을 구현하는

src/ch10-03-lifetime-syntax.md

@@ -182,7 +182,7 @@ borrow 검사기가 분석할 수 있도록 해야 합니다.
 
 자신의 라이프타임 명시 하나만 있는 것은 딱히 의미가 없습니다. 라이프타임
 명시는 러스트에게 여러 참조자의 제네릭 라이프타임 매개변수가 서로 어떻게
-연관되어있는지 알려주는 용도이기 때문입니다. `longest` 함수의 문맥에서
+연관되어있는지 알려주는 용도이기 때문입니다. `longest` 함수의 컨텍스트에서
 라이프타임 명시가 서로에게 어떤 식으로 연관짓는지 실험해 봅시다.
 
 ### 함수 시그니처에서 라이프타임 명시하기

src/ch13-01-closures.md

@@ -4,7 +4,7 @@
 ## 클로저: 자신의 환경을 캡처하는 익명 함수
 
 러스트의 *클로저*는 변수에 저장하거나 다른 함수에 인자로 넘길 수 
-있는 익명 함수입니다. 한 곳에서 클로저를 만들고 다른 문맥 내의 다른
+있는 익명 함수입니다. 한 곳에서 클로저를 만들고 다른 컨텍스트 내의 다른
 곳에서 그것을 평가하기 위해 호출할 수 있습니다. 함수와 다르게 클로저는 
 정의된 스코프에서 값을 캡처할 수 있습니다. 앞으로 클로저의 이러한 
 기능이 코드 재사용과 동작 사용자 정의를 어떻게 가능케 하는지 살펴볼 
@@ -92,8 +92,8 @@
 노출된 인터페이스로 사용되지 않습니다: 클로저는 이름이 지어지거나 우리
 라이브러리의 사용자들에게 노출되지 않은 채로 변수에 저장되고 사용됩니다.
 
-클로저는 통상적으로 짧고 임의의 시나리오보다는 짧은 맥락 내에서만
-관련됩니다. 이러한 한정된 맥락 내에서, 컴파일러는 대부분의 변수에
+클로저는 통상적으로 짧고 임의의 시나리오보다는 짧은 컨텍스트 내에서만
+관련됩니다. 이러한 한정된 컨텍스트 내에서, 컴파일러는 대부분의 변수에
 대한 타입을 추론할 수 있는 방법과 유사한 식으로 클로저의 매개변수와
 반환 타입을 추론합니다 (컴파일러가 클로저 타입을 명시하도록 요구하는
 곳 또한 드물게 있습니다).

src/ch13-04-performance.md

@@ -39,7 +39,7 @@ test bench_search_iter ... bench:  19,234,900 ns/iter (+/- 657,200)
 사용해서 스코프에 있는 세 개의 변수로 수학 연산을 합니다: 데이터의
 `buffer` 슬라이스, 12개의 `coefficients` 배열, 그리고 데이터를
 쉬프트 하기 위한 `qlp_shift` 값으로 말이죠. 이 예제에서는 변수를
-선언했지만 값을 주지는 않았습니다; 비록 이 코드가 문맥 밖에서는
+선언했지만 값을 주지는 않았습니다; 비록 이 코드가 컨텍스트 밖에서는
 큰 의미 없지만, 러스트가 어떻게 고수준의 개념을 저수준의 코드로
 변환하는지에 대한 간결하고 실질적인 예제입니다.
 

src/ch15-01-box.md

@@ -9,7 +9,7 @@
 없습니다. 하지만 여러 추가 기능도 없습니다. 박스는 아래와 같은 상황에서
 가장 자주 쓰이게 됩니다:
 
-* 컴파일 타임에는 크기를 알 수 없는 타입이 있는데, 정확한 크기를 요구하는 맥락
+* 컴파일 타임에는 크기를 알 수 없는 타입이 있는데, 정확한 크기를 요구하는 컨텍스트
   내에서 그 타입의 값을 사용하고 싶을 때
 * 커다란 데이터를 가지고 있고 소유권을 옮기고 싶지만 그렇게 했을 때 데이터가
   복사되지 않을 것이라고 보장하고 싶을 때

src/ch15-03-drop.md

@@ -5,9 +5,9 @@
 타입이든 `Drop` 트레잇을 구현할 수 있고, 이 코드가 파일이나 네트워크 연결 같은
 자원 해제에 사용되게 할 수 있습니다.
 
-스마트 포인터에 대한 내용을 다루는 중에 `Drop`을 소개하는 이유는 `Drop`
-트레잇의 기능이 스마트 포인터를 구현할 때 거의 항상 이용되기 때문입니다.
-예를 들어 `Box<T>`가 버려질 때는 이 박스가 가리키고 있는 힙 공간의 할당을
+스마트 포인터에 대한 맥락에서 `Drop`을 소개하는 이유는 `Drop` 트레잇의
+기능이 스마트 포인터를 구현할 때 거의 항상 이용되기 때문입니다. 예를
+들어 `Box<T>`가 버려질 때는 이 박스가 가리키고 있는 힙 공간의 할당을
 해제할 것입니다.
 
 몇몇 언어들에서는 어떤 타입의 인스턴스 사용을 끝낼 때마다 프로그래머가

src/ch15-05-interior-mutability.md

@@ -54,7 +54,7 @@
 여러분이 확신하는 경우 유용합니다.
 
 `Rc<T>`와 유사하게, `RefCell<T>`은 싱글스레드 시나리오 내에서만 사용
-가능하고, 멀티스레드에서 사용을 시도할 경우에는 컴파일 타임 에러를
+가능하고, 멀티스레드 컨텍스트에서 사용을 시도할 경우에는 컴파일 타임 에러를
 낼 것입니다. `RefCell<T>`의 기능을 멀티스레드 프로그램에서 사용하는
 방법에 대해서는 16장에서 이야기하겠습니다.
 
@@ -277,7 +277,7 @@ Listing 15-20는 라이브러리 코드를 보여줍니다:
 의미합니다: 여러분의 코드가 프로덕션으로 배포될 때까지 발견되지 않을
 수도 있습니다. 또한, 여러분의 코드는 컴파일 타임이 아닌 런타임에 빌림을
 추적하는 결과로 약간의 런타임 성능 페널티를 초래할 것입니다.
-하지만 `RefCell<T>`를 이용하는 것은 오직 불변 값만 허용된 맥락 안에서
+하지만 `RefCell<T>`를 이용하는 것은 오직 불변 값만 허용된 컨텍스트 안에서
 사용하는 중에 본 메세지를 추적하기 위해서 스스로를 변경할 수 있는 목 객체
 작성을 가능하게 해줍니다. 트레이드 오프가 있더라도 `RefCell<T>`를
 사용하여 일반적인 참조자가 제공하는 것보다 더 많은 기능을 얻을 수

src/ch16-01-threads.md

@@ -21,7 +21,7 @@
   버그들
 
 러스트는 스레드 사용의 부정적인 효과를 완화하는 시도를 하지만,
-멀티스레드 콘텍스트에서의 프로그래밍은 여전히 신중하게 생각해야
+멀티스레드 컨텍스트에서의 프로그래밍은 여전히 신중하게 생각해야
 하고 싱글스레드로 실행되는 프로그램의 것과는 다른 코드 구조가
 필요합니다.
 
@@ -174,7 +174,7 @@ hi number 4 from the main thread!
 그렇게하면 클로저가 환경으로부터 사용하는 값의 소유권을 갖게 되어 한
 스레드에서 다른 스레드로 소유권이 이전될 것이기 때문입니다. 13장의
 [“참조자를 캡처하거나 소유권 이전하기”][capture]<!-- ignore -->절에서
-클로저의 콘텍스트에서의 `move`에 대해 다루었습니다. 지금은
+클로저의 컨텍스트에서의 `move`에 대해 다루었습니다. 지금은
 `move`와 `thread::spawn` 사이의 상호작용에 더 집중해 보겠습니다.
 
 Listing 16-1에서 'thread::spawn'에 넘겨진 클로저는 아무런 인자도 갖지

src/ch16-03-shared-state.md

@@ -49,7 +49,7 @@
 
 #### `Mutex<T>`의 API
 
-뮤텍스 사용 방법에 대한 예제로서 Listing 16-12처럼 싱글스레드 맥락에서
+뮤텍스 사용 방법에 대한 예제로서 Listing 16-12처럼 싱글스레드 컨텍스트에서
 뮤텍스를 사용하는 것으로 시작해봅시다:
 
 <span class="filename">Filename: src/main.rs</span>
@@ -58,7 +58,7 @@
 {{#rustdoc_include ../listings/ch16-fearless-concurrency/listing-16-12/src/main.rs}}
 ```
 
-<span class="caption">Listing 16-12: 간소화를 위해 싱글스레드 맥락에서
+<span class="caption">Listing 16-12: 간소화를 위해 싱글스레드 컨텍스트에서
 `Mutex<T>`의 API 탐색하기</span>
 
 많은 타입들이 그렇듯 `Mutex<T>`는 연관함수 `new`를 사용하여 만들어집니다.

src/ch16-04-extensible-concurrency-sync-and-send.md

@@ -73,7 +73,7 @@
 보세요.
 
 러스트 표준 라이브러리는 메세지 패싱을 위해 채널을 제공하고, 동시적
-맥락에서 사용하기 안전한 `Mutex<T>`와 `Arc<T>` 같은 스마트 포인터
+컨텍스트에서 사용하기 안전한 `Mutex<T>`와 `Arc<T>` 같은 스마트 포인터
 타입들을 제공합니다. 타입 시스템과 빌림 검사기는 이 솔루션을 이용하는
 코드가 데이터 경쟁 혹은 유효하지 않은 참조자로 끝나지 않을 것을 보장합니다.
 일단 코드가 컴파일된다면, 다른 언어에서는 흔한 추적하기 어려운 버그 없이

src/ch18-00-patterns.md

@@ -12,7 +12,7 @@
 * 자리표시자 (placeholder)
 
 몇 가지 예제 패턴에는 `x`, `(a, 3)`, `Some(Color::Red)` 같은 것들이 있습니다.
-패턴이 유효한 맥락 내에서 이러한 구성 요소들은 데이터의 형태를 설명합니다.
+패턴이 유효한 컨텍스트 내에서 이러한 구성 요소들은 데이터의 형태를 설명합니다.
 그러면 프로그램은 값들을 패턴에 매칭해보고 특정 코드 조각을 계속 실행하기에
 데이터가 올바른 형태인지 확인합니다.
 

src/ch19-01-unsafe-rust.md

@@ -73,7 +73,7 @@
 두 가지 새로운 타입이 있습니다. 참조자와 마찬가지로 원시 포인터는
 불변 또는 가변이며 각각 `*const T`와 `*mut T`로 작성됩니다.
 별표는 역참조 연산자가 아니라 타입 이름의 일부입니다. 원시 포인터의
-맥락에서 *불변*은 포인터가 역참조된 후에 직접 할당할 수 없음을
+컨텍스트에서 *불변*은 포인터가 역참조된 후에 직접 할당할 수 없음을
 의미합니다.
 
 참조자와 스맡 포인터와는 다르게 원시 포인터는 다음과 같은 특징이 있습니다:
@@ -158,7 +158,7 @@ Listing 19-1은 참조자로부터 불변과 가변 원시 포인터를 만드
 안전하지 않은 블록에서 수행할 수 있는 두 번째 유형의 작업은
 안전하지 않은 함수를 호출하는 것입니다. 안전하지 않은 함수와
 메서드는 일반 함수나 메서드와 똑같아 보이지만, 정의 앞부분에
-`unsafe`가 추가됩니다. 이 문맥에서 `unsafe` 키워드는 이 함수를
+`unsafe`가 추가됩니다. 이 컨텍스트에서 `unsafe` 키워드는 이 함수를
 호출할 때 지켜야 할 요구사항이 있음을 나타내는데, 이는 러스트가
 이러한 요구사항을 충족했다고 보장할 수 없기 때문입니다. 안전하지
 않은 함수를 `unsafe` 블록 내에서 호출한다는 것은 이 함수의 문서를