웹에서 요청과 응답의 전반적인 과정
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
를 이용하여 에러로부터 어떻게 복구하는지를 보겠습니다.