웹 개발의 발전 과정
웹에서 요청과 응답의 전반적인 과정
Intro
월드 와이드 웹(World Wide Web)은 인터넷에 연결된 사용자들이 서로의 정보를 공유할 수 있는 공간이라고 한다.
브라우저는 url로 해당 하는 서버에서 네트워크를 통해 html문서, 필요한 파일들을 받아와 내 화면에서 보여주는 역활을 한다.
그리고 프론트엔드 개발자의 역활은 어떤 기술을 사용하든 결국 서버에서 제공해줄 html
,css
,js
를 작성하는 것이다.
우리가 작성한 파일이 사용자에게 가기까지의 긴 여정을 정리해보자.
블로그 개선 - Algolia Doc Search
Intro
예전에 블로그를 처음 만들고, 기본 프로젝트 상태에서 포스트만 작성했었다.
그러다 한번 리뉴얼 해볼까 하는 마음으로 확인해보니 docusaurus 버전도 2에서 3로 올라 갔더라.
그래도 algolia Doc Search 기능은 붙여 놨었는데, 이번에 전반적으로 리뉴얼 해볼 겸 다시 붙이는 과정을 정리해보려고 한다.
web-ui 정리 및 사용 후기
[web-ui 정리 및 사용 후기]
최근에 sora AI라는 동영상 생성 AI 영상을 보았다. 놀랍고 무섭더라... ChatGPT(GPT-3.5) 처음 쓸때도 놀라웠고, Stable Diffusion때도 놀라웠고 sora도 놀랐다. AI 관련으로 엔디비아 주식도 놀랍다. 놀라움의 연속이다.
대부분 개발자들(연관 사무직)은 AI가 자신을 대체하지 않을까라는 생각을 다들 한번은 해봤을 것 같다.
그만큼 AI의 발전속도는 놀랍다.
피할 수 없으면 즐기라했던가, 늦었다고 생각했을 때가 가장 빠른때라던가, AI 관련 프로덕트를 뭐라도 사용 해봐야 할 것만 같다. 그래도 ChatGPT는 자주 사용하니까 이번에 Stable Diffusion으로 이미지 생성을 해보기로 했다.
Stable Diffusion: 텍스트 및 이미지 프롬프트에서 고유한 실사 이미지를 생성하는 생성형 인공 지능(생성형 AI) 모델 web-ui: 웹 기반 유저 인터페이스
가장 대중적인 방법인 web-ui로 이미지 생성을 해보자!! 본인의 기기는 M1 max이다.
튀르키예 2주 여행 후기
[튀르키예 2주 여행 후기]
나는 친한 동생과 함께 2024/01/06 ~ 2024/01/20 일정으로 튀르키예 여행을 다녀왔다.
동서양의 교차점이자 어릴때부터 막연히 가고 싶었던 튀르키예 여행을 행복하게, 무사히 다녀온 후 다음 여행자들을 위한 후기를 남긴다.
SEO 관련 포스팅
우리 회사 사이트는 flynt다.
신생사이트는 일단 대중에게 노출되는 것이 무엇보다 중요하다. 이는 마케팅의 영역일 것이다.
이 점에 대해 프론트엔드 개발자로 기여 할 수 있는 부분은 SEO
관련 부분일 것이다.
검색엔진은 SEO가 잘 된 사이트에 더 높은 점수를 부여하고 사용자에게 더 잘 노출될 수 있게 한다.
SEO는 사실 복잡한 개념은 아니라고 생각한다.
- 사이트가 HTML 문서라는 점을 이해
- 메타태그로 사이트에 대한 설명
- Semantic한 태그를 사용
- 반응형 페이지 제공(다양한 기기에 대응)
- 콘텐츠가 사용자에게 빠르게 도달하게 노력
이정도면 충분하다고 생각한다. 과거에는 백링크의 수가 검색 결과 순위를 결정하는 주요 요인이었지만, 최근에는 실제 트래픽이 더욱 중요해졌다.
프론트에서 할 수 있는 부분을 놓치지 말고 진행하자.
최근 2달 정도의 회고
한동안 포스트를 작성 하지 않았다.
여러가지 상황이 있었다.
- 회사일이 바빴다.
- 사이드 프로젝트를 시작했다.
- 연애도 하고 있지 😵
열심히 살고 있는 것 같은데, 왜 이렇게 할게 늘기만 하는지 ㅋㅋ... 효율성이 중요한 시점이다.
간만에 포스트를 쓰는 이유는 심란해서이다.
솔라나 프로그램을 작성할 목적으로, 러스트 언어를 두달 정도 학습했었다.
이제 프로그램 분석하고 작성해보는 단계를 진행하고 있는데, 갑자기 왠 FTX 벼락 ㅠㅠ 인지 솔라나가 망하게 생겼다...
Rust + 스마트 컨트랙트를 둘다 만족시켜주는 선택지는 이렇게 사라지고 말았다.
자산도 다 코인으로 바꿔놨는데 하 인생...
2022년 마지막까지 열심히 살고, KRW 채굴 역량이나 올려야겠다!
Chap.9 error-handling
러스트의 신뢰성에 대한 약속은 에러 처리에도 확장되어 있습니다.
에러는 소프트웨어에서 피할 수 없는 현실이며, 따라서 러스트는 무언가 잘못되었을 경우에 대한 처리를 위한 몇 가지 기능을 갖추고 있습니다.
러스트는 에러를 두 가지 범주로 묶습니다:
- 복구 가능한(recoverable) 에러
- 복구 가능한 에러는 사용자에게 문제를 보고하고 연산을 재시도하는 것이 보통 합리적인 경우인데, 이를테면 파일을 찾지 못하는 에러가 그렇습니다.
- 복구 불가능한(unrecoverable) 에러
- 복구 불가능한 에러는 언제나 버그의 증상이 나타나는데, 예를 들면 배열의 끝을 넘어선 위치의 값에 접근하려고 시도하는 경우가 그렇습니다.
대부분의 언어들은 이 두 종류의 에러를 분간하지 않으며 예외 처리(exception)
와 같은 메카니즘을 이용하여 같은 방식으로 둘 다 처리합니다.
러스트는 예외 처리 기능이 없습니다.
- 복구 가능한 에러를 위한
Result<T, E>
값과 - 복구 불가능한 에러가 발생했을 때 실행을 멈추는
panic!
매크로를 가지고 있습니다.
이번 장에서는 panic!
을 호출하는 것을 먼저 다룬 뒤, Result<T, E>
값을 반환하는 것에 대해 이야기 하겠습니다.
추가로, 에러로부터 복구을 시도할지 아니면 실행을 멈출지를 결정할 때 고려할 것에 대해 탐구해 보겠습니다.
panic!
과 함께하는 복구 불가능한 에러
- 러스트는
panic!
매크로를 가지고 있습니다. - 이 매크로가 실행되면, 여러분의 프로그램은 실패 메세지를 출력하고, 스택을 되감고 청소하고, 그 후 종료됩니다.
- 이런 일이 발생하는 가장 흔한 상황은 어떤 종류의 버그가 발견되었고 프로그래머가 이 에러를 어떻게 처리할지가 명확하지 않을 때 입니다.
panic!
에 응하여 스택을 되감거나 그만두기
기본적으로,
panic!
이 발생하면, 프로그램은 되감기(unwinding) 를 시작하는데, 이는 러스트가 패닉을 마주친 각 함수로부터 스택을 거꾸로 훑어가면서 데이터를 제거한다는 뜻이지만, 이 훑어가기 및 제거는 일이 많습니다.다른 대안으로는 즉시 그만두기(abort) 가 있는데, 이는 데이터 제거 없이 프로그램을 끝내는 것입니다. 프로그램이 사용하고 있던 메모리는 운영체제에 의해 청소될 필요가 있을 것입니다. 여러분의 프로젝트 내에서 결과 바이너리가 가능한 작아지기를 원한다면, 여러분의 Cargo.toml 내에서 적합한
[profile]
섹션에panic = 'abort'
를 추가함으로써 되감기를 그만두기로 바꿀 수 있습니다.예를 들면, 여러분이 릴리즈 모드 내에서는 패닉 상에서 그만두기를 쓰고 싶다면, 다음을 추가하세요:
[profile.release] panic = 'abort'
단순한 프로그램 내에서 panic!
호출을 시도해 봅시다:
panic!("crash and burn");
panic!
의 호출이 마지막 세 줄의 에러 메세지를 야기합니다.- 위 예제의 경우, 가리키고 있는 줄은 우리 코드 부분이고, 해당 줄로 가면
panic!
매크로 호출을 보게 됩니다. - 그 외의 경우들에서는,
panic!
호출이 우리가 호출한 코드 내에 있을 수도 있습니다. - 에러 메세지에 의해 보고되는 파일 이름과 라인 번호는
panic!
매크로가 호출된 다른 누군가의 코드일 것이며, 궁극적으로panic!
을 이끌어낸 것이 우리 코드 라인이 아닐 것입니다. - 문제를 일으킨 코드 부분을 발견하기 위해서
panic!
호출이 발생된 함수에 대한 백트레이스(backtrace)를 사용할 수 있습니다. - 백트레이스가 무엇인가에 대해서는 뒤에 더 자세히 다를 것입니다.
panic!
백트레이스 사용하기
다른 예를 통해서, 우리 코드가 직접 매크로를 호출하는 대신 우리 코드의 버그 때문에 panic!
호출이 라이브러리로부터 발생될 때는 어떻게 되는지 살펴봅시다.
이러한 상황에서 C와 같은 다른 언어들은 여러분이 원하는 것이 아닐지라도, 여러분이 요청한 것을 정확히 주려고 시도할 것입니다: 여러분은 벡터 내에 해당 요소와 상응하는 위치의 메모리에 들어 있는 무언가를 얻을 것입니다. 설령 그 메모리 영역이 벡터 소유가 아닐지라도 말이죠.
이러한 것을 버퍼 오버리드(buffer overread) 라고 부르며, 만일 어떤 공격자가 읽도록 허용되어선 안 되지만 배열 뒤에 저장된 데이터를 읽어낼 방법으로서 인덱스를 다룰 수 있게 된다면, 이는 보안 취약점을 발생시킬 수 있습니다.
여러분의 프로그램을 이러한 종류의 취약점으로부터 보호하기 위해서, 여러분이 존재하지 않는 인덱스 상의 요소를 읽으려 시도한다면, 러스트는 실행을 멈추고 계속하기를 거부할 것입니다. 한번 시도해 봅시다:
- 위 에러는 우리가 작성하지 않은 파일인
libcollections/vec.rs
를 가리키고 있습니다. - 이는 표준 라이브러리 내에 있는
Vec<T>
의 구현 부분입니다. - 우리가 벡터
v
에[]
를 사용할 때 실행되는 코드는libcollections/vec.rs
안에 있으며, 그곳이 바로panic!
이 실제 발생한 곳입니다. - 그 다음 노트는
RUST_BACKTRACE
환경 변수를 설정하여 에러의 원인이 된 것이 무엇인지 정확하게 백트레이스할 수 있다고 말해주고 있습니다. 백트레이스 (backtrace)
란 어떤 지점에 도달하기까지 호출해온 모든 함수의 리스트를 말합니다.- 러스트의 백트레이스는 다른 언어들에서와 마찬가지로 동작합니다: 백트레이스를 읽는 요령은 위에서부터 시작하여 여러분이 작성한 파일이 보일 때까지 읽는 것입니다. 그곳이 바로 문제를 일으킨 지점입니다.
- 여러분의 파일을 언급한 줄보다 위에 있는 줄들은 여러분의 코드가 호출한 코드입니다; 밑의 코드는 여러분의 코드를 호출한 코드입니다.
- 이 줄들은 핵심(core) 러스트 코드, 표준 라이브러리, 혹은 여러분이 이용하고 있는 크레이트를 포함하고 있을지도 모릅니다. 백트레이스를 얻어내는 시도를 해봅시다: Listing 9-2는 여러분이 보게 될 것과 유사한 출력을 보여줍니다:
환경 변수 RUST_BACKTRACE
가 설정되었을 때 panic!
의 호출에 의해 발생되는 백트레이스 출력
- 이러한 정보들과 함께 백트레이스를 얻기 위해서는 디버그 심볼이 활성화되어 있어야 합니다.
- 디버그 심볼은 여기서와 마찬가지로 여러분이
cargo build
나cargo run
을--release
플래그 없이 실행했을 때 기본적으로 활성화됩니다.
여러분의 코드가 추후 패닉에 빠졌을 때, 여러분의 특정한 경우에 대하여 어떤 코드가 패닉을 일으키는 값을 만드는지와 코드는 대신 어떻게 되어야 할지를 알아낼 필요가 있을 것입니다.
우리는 panic!
으로 다시 돌아올 것이며 언제 panic!
을 써야 하는지, 혹은 쓰지 말아야 하는지에 대해 이 장의 뒷부분에서 알아보겠습니다. 다음으로 Result
를 이용하여 에러로부터 어떻게 복구하는지를 보겠습니다.
Result
와 함께하는 복구 가능한 에러
대부분의 에러는 프로그램을 전부 멈추도록 요구될 정도로 심각하지는 않습니다. 종종 어떤 함수가 실패할 때는, 우리가 쉽게 해석하고 대응할 수 있는 이유에 대한 것입니다.
예를 들어, 만일 우리가 어떤 파일을 여는데 해당 파일이 존재하지 않아서 연산에 실패했다면, 프로세스를 멈추는 대신 파일을 새로 만드는 것을 원할지도 모릅니다
enum Result<T, E> {
Ok(T),
Err(E),
}
T
와E
는 제네릭 타입 파라미터입니다;- 지금으로서 여러분이 알아둘 필요가 있는 것은,
T
는 성공한 경우에Ok
variant 내에 반환될 값의 타입을 나타내고E
는 실패한 경우에Err
variant 내에 반환될 에러의 타입을 나타내는 것이라는 점입니다. Result
가 이러한 제네릭 타입 파라미터를 갖기 때문에, 우리가 반환하고자 하 는 성공적인 값과 에러 값이 다를 수 있는 다양한 상황 내에서 표준 라이브러리에 정의된Result
타입과 함수들을 사용할 수 있습니다.
실패할 수도 있기 때문에 Result
값을 반환하는 함수를 호출해 봅시다
use std::fs::File;
fn main() {
let f = File::open("hello.txt");
}
-
File::open
이Result
를 반환하는지 어떻게 알까요? -
표준 라이브러리 API 문서를 찾아보거나, 컴파일러에게 물어볼 수 있습니다!
-
File::open
함수의 반환 타입이Result<T, E>
-
여기서 제네릭 파라미터
T
는 성공값의 타입인std::fs::File
로 채워져 있는데, -
이것은 파일 핸들입니다.
-
에러에 사용되는
E
의 타입은std::io::Error
입니다. -
이 반환 타입은
File::open
을 호출하는 것이 성공하여 우리가 읽거나 쓸 수 있는 파일 핸들을 반환해 줄 수도 있다는 뜻입니다.- 함 수 호출은 또한 실패할 수도 있습니다:
- 예를 들면 파일이 존재하지 않거나 파일에 접근할 권한이 없을지도 모릅니다.
-
File::open
함수는 우리에게 성공했는지 혹은 실패했는지를 알려주면서 동시에 파일 핸들이나 에러 정보 둘 중 하나를 우리에게 제공할 방법을 가질 필요가 있습니다. -
바로 이러한 정보가
Result
열거형이 전달하는 것과 정확히 일치합니다. -
File::open
이 성공한 경우, 변수f
가 가지게 될 값은 파일 핸들을 담고 있는Ok
인스턴스가 될 것입니다. -
실패한 경우,
f
의 값은 발생한 에러의 종류에 대한 더 많은 정보를 가지고 있는Err
의 인스턴스가 될 것입니다.
use std::fs::File;
fn main() {
let f = File::open("hello.txt");
let f = match f {
Ok(file) => file,
Err(error) => {
panic!("There was a problem opening the file: {:?}", error)
},
};
}
Listing 9-4: match
표현식을 사용하여 발생 가능한 Result
variant들을 처리하기
Option
열거형과 같이Result
열거형과 variant들은 프렐루드(prelude)로부터 가져와진다는 점을 기억하세요. ??- 따라서
match
의 각 경우에 대해서Ok
와Err
앞에Result::
를 특정하지 않아도 됩니다.
여기서 우리는 러스트에게 결과가 Ok
일 때에는 Ok
variant로부터 내부의 file
값을 반환하고, 이 파일 핸들 값을 변수 f
에 대입한다고 말해주고 있습니다.
match
이후에는 읽거나 쓰기 위해 이 파일 핸들을 사용할 수 있습니다.
서로 다른 에러에 대해 매칭하기
- Listing 9-3의 코드는
File::open
이 실패한 이유가 무엇이든 간에panic!
을 일으킬 것입니다. - 대신 우리가 원하는 것은 실패 이유에 따라 다른 행동을 취하는 것입니다:
- 파일이 없어서
File::open
이 실패한 것이라면, 새로운 파일을 만들어서 핸들을 반환하고 싶습니다. - 만일 그 밖의 이유로
File::open
이 실패한 거라면, 예를 들어 파일을 열 권한이 없어서라면, Listing 9-4에서 했던 것과 마찬가지로panic!
을 일으키고 싶습니다.
use std::fs::File;
use std::io::ErrorKind;
fn main() {
let f = File::open("hello.txt");
let f = match f {
Ok(file) => file,
Err(ref error) if error.kind() == ErrorKind::NotFound => {
match File::create("hello.txt") {
Ok(fc) => fc,
Err(e) => {
panic!(
"Tried to create file but there was a problem: {:?}",
e
)
},
}
},
Err(error) => {
panic!(
"There was a problem opening the file: {:?}",
error
)
},
};
}
Err
variant 내에 있는File::open
이 반환하는 값의 타입은io::Error
인데, 이는 표준 라이브러리에서 제공하는 구조체입니다.- 이 구조체는
kind
메소드를 제공하는데 이를 호출하여io::ErrorKind
값을 얻을 수 있습니다. io::ErrorKind
는io
연산으로부터 발생할 수 있는 여러 종류의 에러를 표현하는 variant를 가진, 표준 라이브러 리에서 제공하는 열거형입니다.- 우리가 사용하고자 하는 variant는
ErrorKind::NotFound
인데, 이는 열고자 하는 파일이 아직 존재하지 않음을 나타냅니다. - 조건문
if error.kind() == ErrorKind::NotFound
는 매치 가드(match guard) 라고 부릅니다: - 패턴에는
ref
가 필요하며 그럼으로써error
가 가드 조건문으로 소유권 이동이 되지 않고 그저 참조만 됩니다.- 패턴 내에서 참조자를 얻기 위해
&
대신ref
이 사용되는 이유는 18장에서 자세히 다룰 것입니다. - 짧게 설명하면,
&
는 참조자를 매치하고 그 값을 제공하지만,ref
는 값을 매치하여 그 참조자를 제공합니다.
- 패턴 내에서 참조자를 얻기 위해
- 매치 가드 내에서 확인하고자 하는 조건문은
error.kind()
에 의해 반환된 값이ErrorKind
열거형의NotFound
variant인가 하는 것입니다. - 바깥쪽
match
의 마지막 갈래는 똑같이 남아서, 파일을 못 찾는 에러 외에 다른 어떤 에러에 대해서도 패닉을 일으킵니다.
에러가 났을 때 패닉을 위한 숏컷: unwrap
과 expect
match
의 사용은 충분히 잘 동작하지만, 살짝 장황하기도 하고 의도를 항상 잘 전달하는 것도 아닙니다.Result<T, E>
타입은 다양한 작업을 하기 위해 정의된 수많은 헬퍼 메소드를 가지고 있습니다.- 그 중 하나인
unwrap
이라 부르는 메소드는 Listing 9-4에서 작성한match
구문과 비슷한 구현을 한 숏컷 메소드입니다. - 만일
Result
값이Ok
variant라면,unwrap
은Ok
내의 값을 반환할 것입니다. - 만일
Result
가Err
variant라면,unwrap
은 우리를 위해panic!
매크로를 호출할 것입니다. 아래에unwrap
이 작동하는 예가 있습니다:
use std::fs::File;
fn main() {
let f = File::open("hello.txt").unwrap();
}
또 다른 메소드인 expect
는 unwrap
과 유사한데, 우리가 panic!
에러 메세지를 선택할 수 있게 해줍니다. unwrap
대신 expect
를 이용하고 좋은 에러 메세지를 제공하는 것은 여러분의 의도를 전달해주고 패닉의 근원을 추적하는 걸 쉽게 해 줄 수 있습니다. expect
의 문법은 아래와 같이 생겼습니다:
use std::fs::File;
fn main() {
let f = File::open("hello.txt").expect("Failed to open hello.txt");
}
expect
는unwrap
과 같은 식으로 사용됩니다:- 파일 핸들을 리턴하거나
panic!
매크로를 호출 하는 것이죠.
- 파일 핸들을 리턴하거나
expect
가panic!
호출에 사용하는 에러 메세지는unwrap
이 사용하는 기본panic!
메세지보다는expect
에 넘기는 파라미터로 설정될 것입니다.- 만일 우리가 여러 군데에
unwrap
을 사용하면, 정확히 어떤unwrap
이 패닉을 일으켰는지 찾기에 좀 더 많은 시간이 걸릴 수 있는데, 그 이유는 패닉을 호출하는 모든unwrap
이 동일한 메세지를 출력하기 때문입니다.
에러 전파하기
실패할지도 모르는 무언가를 호출하는 구현을 가진 함수를 작성할 때, 이 함수 내에서 에러를 처리하는 대신, 에러를 호출하는 코드 쪽으로 반환하여 그쪽에서 어떻게 할지 결정하도록 할 수 있습니다.
이는 에러 전파하기로 알려져 있으며, 에러가 어떻게 처리해야 좋을지 좌우해야 할 상황에서, 여러분의 코드 내용 내에서 이용 가능한 것들보다 더 많은 정보와 로직을 가지고 있을 수도 있는 호출하는 코드 쪽에 더 많은 제어권을 줍니다.
use std::io;
use std::io::Read;
use std::fs::File;
fn read_username_from_file() -> Result<String, io::Error> {
let f = File::open("hello.txt");
let mut f = match f {
Ok(file) => file,
Err(e) => return Err(e),
};
let mut s = String::new();
match f.read_to_string(&mut s) {
Ok(_) => Ok(s),
Err(e) => Err(e),
}
}
Listing 9-6: match
를 이용하여 호출 코드 쪽으로 에러를 반환하는 함수
함수의 반 환 타입부터 먼저 살펴봅시다:
Result<String, io::Error>
. 이는 함수가Result<T, E>
타입의 값을 반환하는데 제네릭 파라미터T
는 구체적 타입(concrete type)인String
로 채워져 있고, 제네릭 타입E
는 구체적 타입인io::Error
로 채워져 있습니다.- 만일 이 함수가 어떤 문제 없이 성공하면, 함수를 호출한 코드는
String
을 담은 값을 받을 것입니다- 이 함수가 파일로부터 읽어들인 사용자 이름이겠지요
- . 만일 어떤 문제가 발생한다면, 이 함수를 호출한 코드는 문제가 무엇이었는지에 대한 더 많은 정보를 담고 있는
io::Error
의 인스턴스를 담은Err
값을 받을 것입니다.- 이 함수의 반환 타입으로서
io::Error
를 선택했는데, - 그 이유는 우리가 이 함수 내부에서 호출하고 있는 실패 가능한 연산 두 가지가 모두 이 타입의 에러 값을 반환하기 때문입니다:
File::open
함수와read_to_string
메소드 말이죠.
- 이 함수의 반환 타입으로서
- 함수의 본체는
File::open
함수를 호출하면서 시작합니다. - 그다음에는 Listing 9-4에서 본
match
와 유사한 식으로match
을 이용해서Result
값을 처리하는데,Err
경우에panic!
을 호출하는 대신 이 함수를 일찍 끝내고File::open
으로부터의 에러 값을 마치 이 함수의 에러 값인 것처럼 호출하는 쪽의 코드에게 전달합니다. - 만일
File::open
이 성공하면, 파일 핸들을f
에 저장하고 계속합니다. - 그 뒤 변수
s
에 새로운String
을 생성 하고 파일의 콘텐츠를 읽어s
에 넣기 위해f
에 있는 파일 핸들의read_to_string
메소드를 호출합니다. File::open
가 성공하더라도read_to_string
메소드가 실패할 수 있기 때문에 이 함수 또한Result
를 반환합니다.- 따라서 이
Result
를 처리하기 위해서 또 다른match
가 필요합니다: - 만일
read_to_string
이 성공하면, 우리의 함수가 성공한 것이고, 이제s
안에 있는 파일로부터 읽어들인 사용자 이름을Ok
에 싸서 반환합니다. - 만일
read_to_string
이 실패하면,File::open
의 반환값을 처리했던match
에서 에러값을 반환하는 것과 같은 방식으로 에러 값을 반환합니다. - 하지만 여기서는 명시적으로
return
이라 말할 필요는 없는데, 그 이유는 이 함수의 마지막 표현식이기 때문입니다. - 그러면 이 코드를 호출하는 코드는 사용자 이름을 담은
Ok
값 혹은io::Error
를 담은Err
값을 얻는 처리를 하게 될 것입니다.
- 호출하는 코드가 이 값을 가지고 어떤 일을 할 것인지 우리는 알지 못합니다.
- 만일 그쪽에서
Err
값을 얻었다면, 예를 들면panic!
을 호출하여 프로그램을 종료시키는 선택을 할 수도 있고, 기본 사용자 이름을 사용할 수도 있으며, 혹은 파일이 아닌 다른 어딘가에서 사용자 이름을 찾을 수도 있습니다.
러스트에서 에러를 전파하는 패턴은 너무 흔하여 러스트에서는 이를 더 쉽게 해주는 물음표 연산자 ?
를 제공합니다.
에러를 전파하기 위한 숏컷: ?
Listing 9-7은 Listing 9-6과 같은 기능을 가진 read_username_from_file
의 구현을 보여주는데, 다만 이 구현은 물음표 연산자를 이용하고 있습니다:
use std::io;
use std::io::Read;
use std::fs::File;
fn read_username_from_file() -> Result<String, io::Error> {
let mut f = File::open("hello.txt")?;
let mut s = String::new();
f.read_to_string(&mut s)?;
Ok(s)
}
- 새로운
String
을 만들어s
에 넣는 부분을 함수의 시작 부분으로 옮겼습니다; - 이 부분은 달라진 것이 없습니다.
f
변수를 만드는 대신,File::open("hello.txt")?
의 결과 바로 뒤에read_to_string
의 호출을 연결시켰습니다. read_to_string
호출의 끝에는 여전히?
가 남아있고,File::open
과read_to_string
이 모두 에러를 반환하지 않고 성공할 때s
안의 사용자 이름을 담은Ok
를 여전히 반환합니다.- 함수의 기능 또한 Lsting 9-6과 Listing 9-7의 것과 동일
?
는 Result
를 반환하는 함수에서만 사용될 수 있습니다
?
는Result
타입을 반환하는 함수에서만 사용이 가능한데, 이것이 Listing 9-6에 정의된match
표현식과 동일한 방식으로 동작하도록 정의되어 있기 때문입니다.Result
반환 타입을 요구하는match
부분은return Err(e)
이며, 따라서 함수의 반환 타입은 반드시 이return
과 호환 가능한Result
가 되어야 합니다.- 여러분은
?
를 사용하여 호출하는 코드에게 잠재적으로 에러를 전파하는 대신match
나Result
에서 제공하는 메소드들 중 하나를 사용하여 이를 처리할 필요가 있을 것입니다.
panic!
이냐, panic!
이 아니냐, 그것이 문제로다
- 코드가 패닉을 일으킬 때는 복구할 방법이 없습니다
- 그렇다면 여러분은 여러분의 코드를 호출하는 코드를 대신하여 현 상황은 복구 불가능한 것이라고 결정을 내리는 겁니다.
- 여러분이
Result
값을 반환하는 선택을 한다면, 호출하는 코드에게 결단을 내려주기보다는 옵션을 제공하는 것입니다. - 그들은 그들의 상황에 적합한 방식으로 복구를 시도할 수도 있고, 혹은 현재 상황의
Err
은 복구 불가능하다고 사실상 결론을 내려서panic!
을 호출하여 여러분이 만든 복구 가능한 에러를 복구 불가능한 것으로 바꿔놓을 수도 있습니다. - 그러므로, 여러분이 실패할지도 모르는 함수를 정의할 때는
Result
을 반환하는 것이 기본적으로 좋은 선택입니다. - 몇 가지 상황에서는
Result
를 반환하는 대신 패닉을 일으키는 코드를 작성하는 것이 더 적합하지만, 덜 일반적입니다.
예제, 프로토타입 코드, 그리고 테스트는 전부 패닉을 일으켜도 완전 괜찮은 곳입니다
여러분이 어떤 개념을 그려내기 위한 예제를 작성 중이라면, 강건한 에러 처리 코드를 예제 안에 넣는 것은 또한 예제를 덜 깨끗하게 만들 수 있습니다.
컴파일러보다 여러분이 더 많은 정보를 가지고 있을 때
Result
가 Ok
값을 가지고 있을 거라 확신할 다른 논리를 가지고 있지만, 그 논리가 컴파일러에 의해 이해할 수 있는 것이 아닐 때라면, unwrap
을 호출하는 것이 또한 적절할 수 있습니다.
use std::net::IpAddr;
let home = "127.0.0.1".parse::<IpAddr>().unwrap();
- 여기서는 하드코딩된 스트링을 파싱하여
IpAddr
인스턴스를 만드는 중입니다. - 우리는
127.0.0.1
이 유효한 IP 주소임을 볼 수 있으므로, 여기서unwrap
을 사용하는 것은 허용됩니다. - 그러나, 하드코딩된 유효한 스트링을 갖고 있다는 것이
parse
메소드의 반환 타입을 변경해주지는 않습니다: - 우리는 여전히
Result
값을 갖게 되고, 컴파일러는 마치Err
variant가 나올 가능성이 여전히 있는 것처럼 우리가Result
를 처리하도록 할 것인데,- 그 이유는 이 스트링이 항상 유효한 IP 주소라는 것을 알 수 있을 만큼 컴파일러가 똑똑하지는 않기 때문입니다.
- 만일 IP 주소 스트링이 프로그램 내에 하드코딩된 것이 아니라 사용자로부터 입력되었다면,
- 그래서 실패할 가능성이 생겼다면, 우리는 대신 더 강건한 방식으로
Result
를 처리할 필요가 분명히 있습니다.
에러 처리를 위한 가이드라인
여러분의 코드가 결국 나쁜 상태에 처하게 될 가능성이 있을 때는 여러분의 코드에 panic!
을 넣는 것이 바람직합니다.
이 글에서 말하는 나쁜 상태란 어떤 가정, 보장, 계약, 혹은 불변성이 깨질 때를 뜻하는 것으로, 이를테면 유효하지 않은 값이나 모순되는 값, 혹은 찾을 수 없는 값이 여러분의 코드를 통과할 경우를 말합니다
만일 어떤 사람이 여러분의 코드를 호출하고 타당하지 않은 값을 집어넣었다면, panic!
을 써서 여러분의 라이브러리를 사용하고 있는 사람에게 그들의 코드 내의 버그를 알려서 개발하는 동안 이를 고칠 수 있게끔 하는 것이 최선책일 수도 있습니다.
비슷한 식으로, 만일 여러분의 제어권을 벗어난 외부 코드를 호출하고 있고, 이것이 여러분이 고칠 방법이 없는 유효하지 않은 상태를 반환한다면, panic!
이 종종 적합합니다.
나쁜 상태에 도달했지만, 여러분이 얼마나 코드를 잘 작성했든 간에 일어날 것으로 예상될 때라면 panic!
을 호출하는 것보다 Result
를 반환하는 것이 여전히 더 적합합니다.
이에 대한 예는 기형적인 데이터가 주어지는 파서나, 속도 제한에 달했음을 나타내는 상태를 반환하는 HTTP 요청 등을 포함합니다.
이러한 경우, 여러분은 이러한 나쁜 상태를 위로 전파하기 위해 호출자가 그 문제를 어떻게 처리할지를 결정할 수 있도록 하기 위해서 Result
를 반환하는 방식으로 실패가 예상 가능한 것임을 알려줘야 합니다. panic!
에 빠지는 것은 이러한 경우를 처리하는 최선의 방식이 아닐 것입니다.
- 여러분의 코드가 어떤 값에 대해 연산을 수행할 때, 여러분의 코드는 해당 값이 유효한지를 먼저 검사하고, 만일 그렇지 않다면
panic!
을 호출해야 합니다. - 이는 주로 안전상의 이유를 위한 것입니다:
- 유효하지 않은 데이터 상에서 어떤 연산을 시도하는 것은 여러분의 코드를 취약점에 노출시킬 수 있습니다.
- 이는 여러분이 범위를 벗어난 메모리 접근을 시도했을 경우 표준 라이브러리가
panic!
을 호출하는 주된 이유입니다:- 현재의 데이터 구조가 소유하지 않은 메모리를 접근 시도하는 것은 흔한 보안 문제입니다.
- 함수는 종종 계약을 갖고 있습니다: 입력이 특정 요구사항을 만족시킬 경우에만 함수의 행동이 보장됩니다.
- 이 계약을 위반했을 때 패닉에 빠지는 것은 사리에 맞는데, 그 이유는 계약 위반이 언제나 호출자 쪽의 버그임을 나타내고, 이는 호출하는 코드가 명시적으로 처리하도록 하는 종류의 버그가 아니기 때문입니다.
- 사실, 호출하는 쪽의 코드가 복구시킬 합리적인 방법은 없습니다:
- 호출하는 프로그래머는 그 코드를 고칠 필요가 있습니다. 함수에 대한 계약은, 특히 계약 위반이 패닉의 원인이 될 때는, 그 함수에 대한 API 문서에 설명되어야 합니다.
하지만 여러분의 모든 함수 내에서 수많은 에러 검사를 한다는 것은 장황하고 짜 증 날 것입니다. 다행스럽게도, 러스트의 타입 시스템이 (그리고 컴파일러가 하는 타입 검사 기능이) 여러분을 위해 수많은 검사를 해줄 수 있습니다. 여러분의 함수가 특정한 타입을 파라미터로 갖고 있다면, 여러분이 유효한 값을 갖는다는 것을 컴파일러가 이미 보장했음을 아는 상태로 여러분의 코드 로직을 진행할 수 있습니다.
- 예를 들면, 만약 여러분이
Option
이 아닌 어떤 타입을 갖고 있다면, - 여러분의 프로그램은 아무것도 아닌 것이 아닌 무언가를 갖고 있음을 예측합니다.
- 그러면 여러분의 코드는
Some
과None
variant에 대한 두 경우를 처리하지 않아도 됩니다: - 이는 분명히 값을 가지고 있는 하나의 경우만 있을 것입니다.
- 여러분의 함수에 아무것도 넘기지 않는 시도를 하는 코드는 컴파일조차 되지 않을 것이고, 따라서 여러분의 함수는 그러한 경우에 대해서 런타임에 검사하지 않아도 됩니다. 또 다른 예로는
u32
와 같은 부호 없는 정수를 이용하는 것이 있는데, 이는 파라미터가 절대 음수가 아님을 보장합니다.
유효성을 위한 커스텀 타입 생성하기
러스트의 타입 시스템을 이용하여 유효한 값을 보장하는 아이디어에서 한 발 더 나가서, 유효성을 위한 커스텀 타입을 생성하는 것을 살펴봅시다.
if
표현식은 우리의 값이 범위 밖에 있는지 혹은 그렇지 않은지 검사하고, 사용자에게 문제점을 말해주고, continue
를 호출하여 루프의 다음 반복을 시작하고 다른 추측값을 요청해줍니다. if
표현식 이후에는, guess
가 1과 100 사이의 값이라는 것을 아는 상태에서 guess
와 비밀 숫자의 비교를 진행할 수 있습니다.
- 하지만, 이는 이상적인 해결책이 아닙니다:
- 만일 프로그램이 오직 1과 100 사이의 값에서만 동작하는 것이 전적으로 중요하고, 많은 함수가 이러한 요구사항을 가지고 있다면, 모든 함수 내에서 이렇게 검사를 하는 것은 지루할 것입니다.
- 그리고 잠재적으로 성능에 영향을 줄 것입니다.
대신, 우리는 새로운 타입을 만들어서, 유효성 확인을 모든 곳에서 반복하는 것보다는 차라리 그 타입의 인스턴스를 생성하는 함수 내에 유효성 확인을 넣을 수 있습니다.
이 방식에서, 함수가 그 시그니처 내에서 새로운 타입을 이용하고 받은 값을 자신 있게 사용하는 것은 안전합니다. Listing 9-9는 new
함수가 1과 100 사이의 값을 받았을 때에만 인스턴스를 생성하는 Guess
타입을 정의하는 한 가지 방법을 보여줍니다:
pub struct Guess {
value: u32,
}
impl Guess {
pub fn new(value: u32) -> Guess {
if value < 1 || value > 100 {
panic!("Guess value must be between 1 and 100, got {}.", value);
}
Guess {
value
}
}
pub fn value(&self) -> u32 {
self.value
}
}
Listing 9-9: 1과 100 사이의 값일 때만 계속되는 Guess
타입
- 먼저
u32
를 갖는value
라는 이름의 항목을 가진Guess
라는 이름의 구조체를 선언하였습니다. - 그런 뒤
Guess
값의 인스턴스를 생성하는new
라는 이름의 연관 함수를 구현하였습니다.new
함수는u32
타입의 값인value
를 파라미터를 갖고Guess
를 반환하도록 정의 되었습니다.new
함수의 본체에 있는 코드는value
가 1부터 100 사이의 값인지 확인하는 테스트를 합니다.- 만일
value
가 이 테스트에 통과하지 못하면panic!
을 호출하며, 이는 이 코드를 호출하는 프로그래머에게 고쳐야 할 버그가 있음을 알려주는데, 범위 밖의value
를 가지고Guess
를 생성하는 것은Guess::new
가 필요로 하는 계약을 위반하기 때문입니다. Guess::new
가 패닉을 일으킬 수도 있는 조건은 공개된 API 문서 내에 다뤄져야 합니다;- 여러분이 만드는 API 문서 내에서
panic!
의 가능성을 가리키는 것에 대한 문서 관례는 14장에서 다룰 것입니다. - 만일
value
가 테스트를 통과한다면,value
항목을value
파라미터로 설정한 새로운Guess
를 생성하여 이Guess
를 반환합니다.
- 다음으로,
self
를 빌리고, 파라미터를 갖지 않으며,u32
를 반환하는value
라는 이름의 메소드를 구현했습니다.- 이러한 종류 메소드를 종종 게터(getter) 라고 부르는데, 그 이유는 이런 함수의 목적이 객체의 항목으로부터 어떤 데이터를 가져와서 이를 반환하는 것이기 때문입니다.
- 이 공개 메소드는
Guess
구조체의value
항목이 비공개이기 때문에 필요합니다. value
항목이 비공개라서Guess
구조체를 이용하는 코드가value
를 직접 설정하지 못하도록 하는 것은 중요합니다:- 모듈 밖의 코드는 반드시
Guess::new
함수를 이용하여 새로운Guess
의 인스턴스를 만들어야 하는데, - 이는
Guess
가Guess::new
함수의 조건들을 확인한 적이 없는value
를 갖는 방법이 없음을 보장합니다.
그러면 파라미터를 가지고 있거나 오직 1에서 100 사이의 숫자를 반환하는 함수는 u32
보다는 Guess
를 얻거나 반환하는 시그니처로 선언되고 더 이상의 확인이 필요치 않을 것입니다.
정리
- 러스트의 에러 처리 기능은 여러분이 더 강건한 코드를 작성하는 데 도움을 주도록 설계되었습니다.
panic!
매크로는 여러분의 프로그램이 처리 불가능한 상태에 놓여 있음에 대한 신호를 주고 여러분이 유효하지 않거나 잘못된 값으로 계속 진행하는 시도를 하는 대신 실행을 멈추게끔 해줍니다.Result
열거형은 러스트의 타입 시스템을 이용하여 여러분의 코드가 복구할 수 있는 방법으로 연산이 실패할 수도 있음을 알려줍니다.- 또한
Result
를 이용하면 여러분의 코드를 호출하는 코드에게 잠재적인 성공이나 실패를 처리해야 할 필요가 있음을 알려줄 수 있습니다. panic!
과Result
를 적합한 상황에서 사용하는 것은 여러분의 코드가 불가피한 문제에 직면했을 때도 더 신뢰할 수 있도록 해줄 것입니다.
이제 표준 라이브러리가 Option
과 Result
열거형을 가지고 제네릭을 사용하는 유용한 방식들을 보았으니, 제네릭이 어떤 식으로 동작하고 여러분의 코드에 어떻게 이용할 수 있는지에 대해 다음 장에서 이야기해 보겠습니다.
Chap.8 common-collections
러스트의 표준 라이브러리에는 컬렉션
이라 불리는 여러 개의 매우 유용한 데이터 구조들이 포함되어 있습니다.
대부분의 다른 데이터 타입들은 하나의 특정한 값을 나타내지만, 컬렉션은 다수의 값을 담을 수 있습니다.
내장된 배열(build-in array)와 튜플 타입과는 달리, 이 컬렉션들이 가리키고 있는 데이터들은 힙에 저장되는데, 이는 즉 데이터량이 컴파일 타임에 결정되지 않아도 되며 프로그램이 실행될 때 늘어나거나 줄어들 수 있다는 의미입니다.
각각의 컬렉션 종류는 서로 다른 용량과 비용을 가지고 있으며, 여러분의 현재 상황에 따라 적절한 컬렉션을 선택하는 것은 시간이 지남에 따라 발전시켜야 할 기술입니다.
이번 장에서는 러스트 프로그램에서 굉장히 자주 사용되는 세 가지 컬렉션에 대해 논의해 보겠습니다:
- 벡터(vector) 는 여러 개의 값을 서로 붙어 있게 저장할 수 있도록 해줍니다.
- 스트링(string) 은 문자(character)의 모음입니다.
String
타입은 이전에 다루었지만, 이번 장에서는 더 깊이 있게 이야기해 보겠습니다. - 해쉬맵(hash map 은 어떤 값을 특정한 키와 연관지어 주도록 해줍니다. 이는 맵(map) 이라 일컫는 좀더 일반적인 데이터 구조의 특정한 구현 형태입니다.
표준 라이브러리가 제공해주는 다른 종류의 컬렉션에 대해 알고 싶으시면, the documentation를 봐 주세요.
벡터
우리가 보게될 첫번째 콜렉션은 벡터
라고도 알려진 Vec<T>
입니다.
- 벡터는 메모리 상에 서로 이웃하도록 모든 값을 집어넣는 단일 데이터 구조 안에 하나 이상의 값을 저장하도록 해줍니다.
- 벡터는 같은 타입의 값만을 저장할 수 있습니다.
새 벡터 만들기
비어있는 새 벡터를 만들기 위해서는, 아래의 Listing 8-1과 같이 Vec::new
함수를 호출해 줍니다:
let v: Vec<i32> = Vec::new();
- 여기에 타입 명시(type annotation)를 추가한 것을 주목하세요.
- 이 벡터에 어떠한 값도 집어넣지 않았기 때문에, 러스트는 우리가 저장하고자 하는 요소의 종류가 어떤 것인지 알지 못합니다.
- 벡터는 제네릭(generic)을 이용하여 구현되었습니다;
- 표준 라이브러리가 제공하는
Vec
타입은 어떠한 종류의 값이라도 저장할 수 있다는 것, - 그리고 특정한 벡터는 특정한 타입의 값을 저장할 때, 이 타입은 꺾쇠 괄호
(<>)
안에 적는다는 것만 알아두세요.
- 표준 라이브러리가 제공하는
- 일단 우리가 값을 집어넣으면 러스트는 우리가 저장하고자 하는 값의 타입을 대부분 유추할 수 있으므로, 좀 더 현실적인 코드에서는 이러한 타입 명시를 할 필요가 거의 없습니다.
- 초기값들을 갖고 있는
Vec<T>
을 생성하는 것이 더 일반적이며, 러스트는 편의를 위해vec!
매크로를 제공합니다. - 이 매크로는 우리가 준 값들을 저장하고 있는 새로운
Vec
을 생성합니다. 1
,2
,3
을 저장하고 있는 새로운Vec<i32>
을 생성할 것입니다:
let v = vec![1, 2, 3];
Listing 8-2: 값을 저장하고 있는 새로운 벡터 생성하기
초기 i32
값들을 제공했기 때문에, 러스트는 v
가 Vec
타입이라는 것을 유추할 수 있으며, 그래서 타입 명시는 필요치 않습니다.
벡터 갱신하기
벡터를 만들고 여기에 요소들을 추가하기 위해서 push
메소드를 사용할 수 있습니다:
let mut v = Vec::new();
v.push(5);
v.push(6);
v.push(7);
v.push(8);
Listing 8-3: push
메소드를 사용하여 벡터에 값을 추가하기
어떤 변수에 대해 그 변수가 담고 있는 값이 변경될 수 있도록 하려면, mut
키워드를 사용하여 해당 변수를 가변으로 만들어 줄 필요가 있습니다.
우리가 집어넣는 숫자는 모두 i32
타입이며, 러스트는 데이터로부터 이 타입을 추론하므로, 우리는 Vec<i32>
명시를 붙일 필요가 없습니다.
벡터를 드롭하는 것은 벡터의 요소들을 드롭시킵니다
struct
와 마찬가지로, Listing 8-4에 달려있는 주석처럼 벡터도 스코프 밖으로 벗어났을 때 해제됩니다:
{
let v = vec![1, 2, 3, 4];
// v를 가지고 뭔가 합니다
}
// <- v가 스코프 밖으로 벗어났고, 여기서 해제됩니다
벡터의 요소들 읽기
지금까지 벡터를 만들고, 갱신하고, 없애는 방법에 대해 알아보았으니, 벡터의 내용물을 읽어들이는 방법을 알아보는 것이 다음 단계로 좋아보입니다. 벡터 내에 저장된 값을 참조하는 두 가지 방법이 있습니다.
{
let v = vec![1, 2, 3, 4, 5];
let third: &i32 = &v[2];
let third: Option<&i32> = v.get(2);
}
Listing 8-5: 인덱스 문법 혹은 get
메소드를 사용하여 벡터 내의 아이템에 접근하기
두가지 세부사항을 주목하세요.
- 첫번째로, 인덱스 값
2
를 사용하면 세번째 값이 얻어집니다:- 벡터는 0부터 시작하는 숫자로 인덱스됩니다.
- 두번째로, 세번째 요소를 얻기 위해 두 가지 다른 방법이 사용되었습니다:
&
와[]
를 이용하여 참조자를 얻은 것과,get
함수에 인덱스를 파라미터로 넘겨서Option<&T>
를 얻은 것입니다.
러스트가 벡터 요소를 참조하는 두가지 방법을 제공하는 이유는 여러분이 벡터가 가지고 있지 않은 인덱스값을 사용하고자 했을 때 프로그램이 어떻게 동작할 것인지 여러분이 선택할 수 있도록 하기 위해서입니다.
let v = vec![1, 2, 3, 4, 5];
let does_not_exist = &v[100];
let does_not_exist = v.get(100);
Listing 8-6: 5개의 요소를 가진 벡터에 100 인덱스에 있는 요소에 접근하기
-
이 프로그램을 실행하면, 첫번째의
[]
메소드는panic!
을 일으키는데, 이는 존재하지 않는 요소를 참조하기 때문입니다.이 방법은 여러분의 프로그램이 벡터의 끝을 넘어서는 요소에 접근하는 시도를 하면 프로그램이 죽게끔 하는 치명적 에러를 발생하도록 하기를 고려하는 경우 가장 좋습니다.
-
get
함수에 벡터 범위를 벗어난 인덱스가 주어졌을 때는 패닉 없이None
이 반환됩니다. 보통의 환경에서 벡터의 범위 밖에 있는 요소에 접근하는 것이 종종 발생한다면 이 방법을 사용할만 합니다. 여러분의 코드는 우리가 6장에서 본 것과 같이Some(&element)
혹은None
에 대해 다루는 로직을 갖추어야 합니다.
유효하지 않은 참조자
프로그램이 유효한 참조자를 얻을 때, 빌림 검사기(borrow checker)
가 소유권 및 빌림 규칙을 집행하여 이 참조자와 벡터의 내용물로부터 얻은 다른 참조자들이 계속 유효하게 남아있도록 확실히 해줍니다.
같은 스코프 내에서 가변 참조자와 불변 참조자를 가질 수 없다는 규칙을 상기하세요.
이 규칙은 아래 예제에서도 적용되는데, Listing 8-7에서는 벡터의 첫번째 요소에 대한 불변 참조자를 얻은 뒤 벡터의 끝에 요소를 추가하고자 했습니다:
let mut v = vec![1, 2, 3, 4, 5];
let first = &v[0];
v.push(6);
// error[E0502]: cannot borrow `v` as mutable because it is also borrowed as immutable
Listing 8-7의 코드는 동작을 해야만 할것처럼 보일 수도 있습니다:
- 왜 첫번째 요소에 대한 참조자가 벡터 끝에 대한 변경을 걱정해야 하죠?
- 이 에러에 대한 내막은 벡터가 동작하는 방법 때문입니다:
- 새로운 요소를 벡터의 끝에 추가하는 것은
- 새로 메모리를 할당하여 예전 요소를 새 공간에 복사하는 일을 필요로 할 수 있는데,
- 이는 벡터가 모든 요소들을 붙여서 저장할 공간이 충분치 않는 환경에서 일어날 수 있습니다.
- 이러한 경우, 첫번째 요소에 대한 참조자는 할당이 해제된 메모리를 가리키게 될 것입니다.
- 빌림 규칙은 프로그램이 이러한 상황에 빠지지 않도록 해줍니다.
노트:
Vec<T>
타입의 구현 세부사항에 대한 그밖의 것에 대해서는 https://doc.rust-lang.org/stable/nomicon/vec.html 에 있는 노미콘(The Nomicon)을 보세요:
벡터 내의 값들에 대한 반복처리
만일 벡 터 내의 각 요소들을 차례대로 접근하고 싶다면, 하나의 값에 접근하기 위해 인덱스를 사용하는것 보다는, 모든 요소들에 대해 반복처리를 할 수 있습니다.
let v = vec![100, 32, 57];
for i in &v {
println!("{}", i);
}
Listing 8-8: for
루프를 이용한 요소들에 대한 반복작업을 통해 각 요소들을 출력하기
만일 모든 요소들을 변형시키길 원한다면 가변 벡터 내의 각 요소에 대한 가변 참조자로 반복작업을 할 수도 있습니다.
let mut v = vec![100, 32, 57];
for i in &mut v {
*i += 50;
}
Listing 8-9: 벡터 내의 요소에 대한 가변 참조자로 반복하기
가변 참조자가 참고하고 있는 값을 바꾸기 위해서, i
에 +=
연산자를 이용하기 전에 역참조 연산자 (*
)를 사용하여 값을 얻어야 합니다.
열거형을 사용하여 여러 타입을 저장하기
이 장의 시작 부분에서, 벡터는 같은 타입을 가진 값들만 저장할 수 있다고 이야기했습니다. 이는 불편할 수 있습니다; 다른 타입의 값들에 대한 리스트를 저장할 필요가 있는 상황이 분명히 있지요. 다행히도, 열거형의 variant는 같은 열거형 타입 내에 정의가 되므로, 백터 내에 다른 타입의 값들을 저장할 필요가 있다면 열거형을 정의하여 사용할 수 있습니다!
예를 들어, 스프레드시트의 행으로부터 값들을 가져오고 싶은데, 여기서 어떤 열은 정수를, 어떤 열은 실수를, 어떤 열은 스트링을 갖고 있다고 해봅시다. 우리는 다른 타입의 값을 가지는 variant가 포함된 열거형을 정의할 수 있고, 모든 열거형 variant들은 해당 열거형 타입, 즉 같은 타입으로 취급될 것입니다. 따라서 우리는 궁극적으로 다른 타입을 담은 열거형 값에 대한 벡터를 생성할 수 있습니다. Listing 8-10에서 이를 보여주고 있습니다:
enum SpreadsheetCell {
Int(i32),
Float(f64),
Text(String),
}
let row = vec![
SpreadsheetCell::Int(3),
SpreadsheetCell::Text(String::from("blue")),
SpreadsheetCell::Float(10.12),
];
Listing 8-10: 열거형을 정의하여 벡터 내에 다른 타입의 데이터를 담을 수 있도록 하기
러스트가 컴파일 타임에 벡터 내에 저장될 타입이 어떤 것인지 알아야할 필요가 있는 이유는 각 요소를 저장하기 위해 얼만큼의 힙 메모리가 필요한지 알기 위함입니다.
- 부차적인 이점은 이 백터에 허용되는 타입에 대해 명시적일 수 있다는 점입니다.
- 만일 러스트가 어떠한 타입이든 담을수 있는 벡터를 허용한다면, 벡터 내의 각 요소마다 수행되는 연산에 대해 하나 혹은 그 이상의 타입이 에러를 야기할 수도 있습니다.
열거형과 match
표현식을 사용한다는 것은 6장에서 설명한 바와 같이 러스트가 컴파일 타임에 모든 가능한 경우에 대해 처리한다는 것을 보장해준다는 의미입니다.
만약 프로그램을 작성할 때 여러분의 프로그램이 런타임에 벡터에 저장하게 될 타입의 모든 경우를 알지 못한다면, 열거형을 이용한 방식은 사용할 수 없을 것입니다.
대신 트레잇 객체(trait object)를 이용할 수 있는데, 이건 17장에서 다루게 될 것입니다.
지금까지 벡터를 이용하는 가장 일반적인 방식 중 몇가지에 대해 논의했는데, 표준 라이브러리의 Vec
에 정의된 수많은 유용한 메소드들이 있으니 API 문서를 꼭 살펴봐 주시기 바랍니다. 예를 들면, push
에 더해서, pop
메소드는 제일 마지막 요소를 반환하고 지워줍니다. 다음 콜렉션 타입인 String
으로 넘어갑시다!
스트링
새로운 러스트인들은 흔히들 스트링 부분에서 막히는데 이는 세 가지 개념의 조합으로 인한 것입니다:
- 가능한 에러를 꼭 노출하도록 하는 러스트의 성향,
- 많은 프로그래머의 예상보다 더 복잡한 데이터 구조인 스트링,
- 그리고 UTF-8입니다. 다른 언어들을 사용하다 왔을 때 이 개념들의 조합이 러스트의 스트링을 어려운 것처럼 보이게 합니다.
스트링이 컬렉션 장에 있는 이유는 스트링이 바이트의 컬렉션 및 이 바이트들을 텍스트로 통역할때 유용한 기능을 제공하는 몇몇 메소드로 구현되어 있기 때문입니다.
이번 절에서는 생성, 갱신, 값 읽기와 같은 모든 컬렉션 타입이 가지고 있는, String
에서의 연산에 대해 이야기 해보겠습니다.
또한 String
을 다른 컬렉션들과 다르게 만드는 부분, 즉 사람과 컴퓨터가 String
데이터를 통역하는 방식 간의 차이로 인해 생기는 String
인덱싱의 복잡함을 논의해보겠습니다.
스트링이 뭔가요?
러스트는 핵심 언어 기능 내에서 딱 한가지 스트링 타입만 제공하는데, 이는 바로 스트링 슬라이스
인 str
이고, 이것의 참조자 형태인 &str
을 많이 봤죠.
- 이는 다른 어딘가에 저장된 UTF-8로 인코딩된 스트링 데이터의 참조자입니다.
- 예를 들어, 스트링 리터럴은 프로그램의 바이너리 출력물 내에 저장되어 있으며, 그러므로 스트링 슬라이스입니다.
String
타입은 핵심 언어 기능 내에 구현된 것이 아니고 러스트의 표준 라이브러리
를 통해 제공되며, 커질 수 있고, 가변적이며, 소유권을 갖고 있고, UTF-8로 인코딩된 스트링 타입입니다.
러스트인들이 스트링
에 대해 이야기할 때, 그들은 보통 String
과 스트링 슬라이스 &str
타입 둘 모두를 이야기한 것이지, 이들 중 하나를 뜻한 것은 아닙니다.
이번 절은 대부분 String
에 관한 것이지만, 두 타입 모두 러스트 표준 라이브러리에서 매우 많이 사용되며 String
과 스트링 슬라이스 모두 UTF-8로 인코딩되어 있습니다.
또한 러스트 표준 라이브러리는 OsString
, OsStr
, CString
, 그리고 CStr
과 같은 몇가지 다른 스트링 타입도 제공합니다. 심지어 어떤 라이브러리 크레이트들은 스트링 데이터를 저장하기 위해 더 많은 옵션을 제공할 수 있습니다. *String
/*Str
이라는 작명과 유사하게, 이들은 종종 소유권이 있는 타입과 이를 빌린 변형 타입을 제공하는데, 이는 String
/&str
과 비슷합니다. 이러한 스트링 타입들은, 예를 들면 다른 종류의 인코딩이 된 텍스트를 저장하거나 다른 방식으로 메모리에 저장될 수 있습니다. 여기서는 이러한 다른 스트링 타입은 다루지 않겠습니다; 이것들을 어떻게 쓰고 어떤 경우에 적합한지에 대해 알고 싶다면 각각의 API 문서를 확인하시기 바랍니다.
새로운 스트 링 생성하기
Vec
에서 쓸 수 있는 많은 연산들이 String
에서도 마찬가지로 똑같이 쓰일 수 있는데, new
함수를 이용하여 스트링을 생성하는 것으로 아래의 Listing 8-11과 같이 시작해봅시다:
let mut s = String::new();
Listing 8-11: 비어있는 새로운 String
생성하기
- 이 라인은 우리가 어떤 데이터를 담아둘 수 있는
s
라는 빈 스트링을 만들어 줍니다. - 종종 우리는 스트링에 담아두고 시작할 초기값을 가지고 있을 것입니다.
- 그런 경우,
to_string
메소드를 이용하는데, 이는Display
트레잇이 구현된 어떤 타입이든 사용 가능하며, 스트링 리터럴도 이 트레잇을 구현하고 있습니다.
let data = "initial contents";
let s = data.to_string();
// the method also works on a literal directly:
let s = "initial contents".to_string();
Listing 8-12: to_string
메소드를 사용하여 스트링 리터럴로부터 String
생성하기
이 코드는 initial contents
를 담고 있는 스트링을 생성합니다.
또한 스트링 리터럴로부터 String
을 생성하기 위해서 String::from
함수를 이용할 수도 있습니다. Listing 8-13의 코드는 to_string
을 사용하는 Listing 8-12의 코드와 동일합니다:
스트링이 UTF-8로 인코딩되었음을 기억하세요. 즉, 아래의 Listing 8-14에서 보는 것처럼 우리는 인코딩된 어떤 데이터라도 포함시킬 수 있습니다:
let hello = String::from("السلام عليكم");
let hello = String::from("Dobrý den");
let hello = String::from("Hello");
let hello = String::from("שָׁלוֹם");
let hello = String::from("नमस्ते");
let hello = String::from("こんにちは");
let hello = String::from("안녕하세요");
let hello = String::from("你好");
let hello = String::from("Olá");
let hello = String::from("Здравствуйте");
let hello = String::from("Hola");
위의 모두가 유효한 String
값입니다.
스트링 갱신하기
String
은 크기가 커질 수 있으며 이것이 담고 있는 내용물은 Vec
의 내용물과 마찬가지로 더 많은 데이터를 집어넣음으로써 변경될 수 있습니다.
추가적으로, +
연산자나 format!
매크로를 사용하여 편리하게 String
값들을 서로 접합(concatenation)할 수 있습니다.
push_str
과 push
를 이용하여 스트링 추가하기
스트링 슬라이스를 추가하기 위해 push_str
메소드를 이용하여 String
을 키울 수 있습니다:
let mut s1 = String::from("foo");
let s2 = "bar";
s1.push_str(&s2);
println!("s2 is {}", s2);
만일 push_str
함수가 s2
의 소유권을 가져갔다면, 마지막 줄에서 그 값을 출력할 수 없었을 것입니다. 하지만, 이 코드는 우리가 기대했던 대로 작동합니다!
+
연산자나 format!
매크로를 이용한 접합
종종 우리는 가지고 있는 두 개의 스트링을 조합하고 싶어합니다. 한 가지 방법은 아래 Listing 8-18와 같이 +
연산자를 사용하는 것입니다:
let s1 = String::from("Hello, ");
let s2 = String::from("world!");
let s3 = s1 + &s2; // s1은 여기서 이동되어 더이상 쓸 수 없음을 유의하세요
+
연산자를 사용하여 두 String
값을 하나의 새로운 String
값으로 조합하기
위의 코드 실행 결과로서, 스트링 s3
는 Hello, world!
를 담게 될 것입니다. s1
이 더하기 연산 이후에 더이상 유효하지 않은 이유와 s2
의 참조자가 사용되는 이유는 +
연산자를 사용했을 때 호출되는 함수의 시그니처와 맞춰야 하기 때문입니다 +
연산자는 add
메소드를 사용하는데, 이 메소드의 시그니처는 아래처럼 생겼습니다:
fn add(self, s: &str) -> String {
-
이는 표준 라이브러리에 있는 정확한 시그니처는 아닙니다.
-
첫번째로,
s2
는&
를 가지고 있는데, -
이는
add
함수의s
파라미터 때문에 첫번째 스트링에 두번째 스트링의참조자
를 더하고 있음을 뜻합니다: -
우리는
String
에&str
만 더할 수 있고, 두String
을 더하지는 못합니다.- 하지만, 잠깐만요 -
&s2
의 타입은&String
이지,add
의 두번째 파라미터에 명시한 것 처럼&str
은 아니죠. &s2
를add
호출에 사용할 수 있는 이유는&String
인자가&str
로 강제될 수 있기 때문입니다.add
함수가 호출되면, 러스트는 역참조 강제(deref coercion) 라 불리는 무언가를 사용하는데, 이는add
함수내에서 사용되는&s2
가&s2[..]
로 바뀌는 것으로 생각할 수 있도록 해줍니다.- 역참조 강제에 대한 것은 15장에서 다룰 것입니다.
add
가 파라미터의 소유권을 가져가지는 않으므로,s2
는 이 연산 이후에도 여전히 유효한String
일 것입니다.
- 하지만, 잠깐만요 -
-
두번째로, 시그니처에서
add
가self
의 소유권을 가져가는 것을 볼 수 있는데, 이는self
가&
를 안 가지고 있기 때문입니다. -
즉 Listing 8-18의 예제에서
s1
이add
호출로 이동되어 이후에는 더 이상 유효하지 않을 것이라는 의미입니다. -
따라서
let s3 = s1 + &s2;
가 마치 두 스트링을 복사하여 새로운 스트링을 만들 것처럼 보일지라도, 실제로 이 구문은s1
의 소유권을 가져다가s2
의 내용물의 복사본을 추가한 다음, 결과물의 소유권을 반환합니다. -
달리 말하면, 이 구문은 여러 복사본을 만드는 것처럼 보여도 그렇지 않습니다:
-
이러한 구현은 복사보다 더 효율적입니 다.
s
에 tic-tac-toe
을 설정합니다. format!
매크로는 println!
과 똑같은 방식으로 작동하지만, 스크린에 결과를 출력하는 대신 결과를 담은 String
을 반환해줍니다.
format!
을 이용한 버전이 훨씬 읽기 쉽고, 또한 어떠한 파라미터들의 소유권도 가져가지 않습니다.
let s1 = String::from("tic");
let s2 = String::from("tac");
let s3 = String::from("toe");
let s = s1 + "-" + &s2 + "-" + &s3;
let s = format!("{}-{}-{}", s1, s2, s3);