추가 적립 안내

백엔드 개발자를 위한 러스트 온보딩 가이드

‘러스트는 API 개발을 위한 생산적인 언어가 될 수 있을까?’라는 질문에서 시작된 이 책은 가상의 엔지니어 팀이 러스트로 클라우드 네이티브 애플리케이션을 개발하고 배포하는 과정을 그린다. 총 11장에 걸쳐 러스트의 에코시스템 탐색 및 활용, 애플리케이션의 모듈화와 구조화, 단위/통합 테스트, 타입 시스템을 사용한 도메인 불변성 적용, API 사용자 인증 및 권한 부여, 강력한 오류 처리 전략, 구조화된 로그를 사용한 애플리케이션 관리, 광범위한 지속적 통합/배포 파이프라인 구축을 다룬다. 러스트 백엔드 개발자의 이상적인 출발점이자 최고의 가이드가 될 것이다.

전 세계에서 사랑받는 언어 러스트가 궁금하다면 반드시 읽어야 하는 책

러스트는 2023년에도 스택 오버플로에서 개발자가 가장 사랑하는 언어로 뽑혔다. 빠른 속도, 안정성, 편의성 등 많은 장점을 갖춘 러스트는 8년째 1위 자리를 지키고 있다. 새로운 언어를 선택한다면 러스트를 선택한다고 할 정도로 개발자들에게 유망한 프로그래밍 언어다.

이 책은 러스트로 API 백엔드 프로그래밍을 하는 방법을 자세히 다룬다. 서로 다른 경험과 숙련도를 가진 가상의 엔지니어 팀이 러스트를 통해 클라우드 네이티브 애플리케이션을 개발하고 배포하는 과정을 통해 소프트웨어를 안정적으로 생산해내는 러스트의 강점과 가치를 알 수 있을 것이다.

1장과 2장에서는 러스트의 유용한 도구와 유틸리티, 책에서 만들어볼 뉴스레터 API 개발에 필요한 개념과 기법을 살펴본다. 3장과 4장에서는 단위/통합 테스트, 에코 시스템 탐색 및 활용을 다루며, 5장에서는 광범위한 지속적 통합/배포 파이프라인 구축, 6장에서는 타입 시스템을 사용한 도메인 불변성 적용, 7장에서는 애플리케이션의 모듈화와 구조화, 8장에서는 강력한 오류 처리 전략을 설명한다. 이어서 9장에서는 뉴스레터 전달 로직의 프로토타입을 만들어보고, 10장과 11장에서는 API 사용자 인증 및 권한 부여뿐만 아니라 내장애성, 확장성, 비동기 처리 등의 개념까지 알려준다.

러스트 도입을 망설이고 있다면 바로 이 책을 선택하자. 원서의 제목처럼 제로에서 시작해 프로덕션까지, 여러분을 러스트 개발자의 세계로 안내해줄 것이다. 이보다 더 완벽하고, 더 유용하며, 더 친절한 백엔드 개발자를 위한 러스트 가이드는 없다.

주요 내용

● 러스트의 에코시스템 탐색 및 활용하기
● 애플리케이션을 모듈화 및 확장할 수 있도록 구조화하기
● 단위 테스트부터 통합 테스트까지 테스트 작성하기
● 타입 시스템을 활용해 도메인 불변성 적용하기
● API 사용자를 인증하고 권한 부여하기
● 강력한 오류 처리 전략 구현하기
● 구조화된 로그로 애플리케이션 상태 체크하기
● 지속적인 통합 및 배포 파이프라인 설정하기

마르쿠스 라델(Marcus Radell)(Deversify의 엔지니어링 책임자)
이 책은 우리가 작업을 잘 수행하는 데 필요한 러스트의 핵심을 짚어 친절하게 설명해준다.

휴고 레지보(Hugo Regibo)(소프트웨어 엔지니어)
러스트가 궁금하지만 어려울 것 같아 망설여지는가? 바로 이 책이 당신을 위한 책이다. 깔끔하고 명확하게 설명해주며, 러스트에 대한 궁금증을 해소하는 데 도움이 될 것이다.

제러미 힌들(Jeremy Hindle)(Custodian & Cloudline의 공동 설립자, CTO, CFO)
러스트 도입을 망설이고 있다면 이 책이 망설임에 종지부를 찍어줄 것이다.

플로리안 길허(Florian Gilcher) Ferrous Systems 매니지먼트 디렉터, 러스트 파운데이션 공동 설립자)
이 책은 러스트 외에도 다양한 곳에 적용할 수 있는 새로운 지식과 일상적인 소프트웨어 개발 맥락을 친절하게 설명한다. 부디 이 책을 읽고, 학습하고, 사색하며 즐거운 시간을 보내기 바란다.

옮긴이 머리말 xi
베타리더 후기 xii
추천 서문 xiii
이 책에 대하여 xv

CHAPTER 1 시작하기 1
1.1 러스트 툴체인 설치하기 1
1.2 프로젝트 셋업 3
1.3 IDE 4
1.4 내부 개발 루프 6
1.5 지속적인 통합 9

CHAPTER 2 이메일 뉴스레터 만들기 15
2.1 구현 예시 15
2.2 뉴스레터의 기능에 관하여 16
2.3 반복적으로 작업하기 18
2.4 진척 확인하기 19

CHAPTER 3 신규 구독자로 등록하기 20
3.1 전략 20
3.2 웹 프레임워크 선택하기 21
3.3 첫 번째 엔드포인트: 기본 헬스 체크 22
3.4 첫 번째 통합 테스트 34
3.5 첫 번째 통합 테스트 구현하기 41
3.6 다시 집중하자 50
3.7 HTML 폼 다루기 51
3.8 데이터 저장하기: 데이터베이스 66
3.9 신규 구독자 저장하기 90
3.10 테스트 업데이트하기 101
3.11 정리 108

CHAPTER 4 텔레메트리 109
4.1 알려지지 않은, 알려지지 않은 것들 110
4.2 관측 가능성 111
4.3 로깅 112
4.4 POST /subscriptions 측정하기 118
4.5 구조화된 로깅 125
4.6 정리 158

CHAPTER 5 프로덕션에서 구동하기 159
5.1 배포의 중요성 159
5.2 도구 선택하기 160
5.3 애플리케이션용 도커 파일 162
5.4 디지털오션 앱 플랫폼으로의 배포 184

CHAPTER 6 유효하지 않은 구독자 거부하기 1 198
6.1 요구 사항 199
6.2 첫 번째 구현 201
6.3 검증은 구멍 난 가마솥이다 203
6.4 타입 주도 개발 205
6.5 오너십과 불변량 209
6.6 패닉 216
6.7 값으로서의 오류: Result 218
6.8 통찰력 있는 어서션 오류: claim 222
6.9 단위 테스트 223
6.10 Result 다루기 226
6.11 이메일 포맷 229
6.12 SubscriberEmail 타입 230
6.13 속성 기반 테스팅 235
6.14 페이로드 검증 241
6.15 정리 248

CHAPTER 7 유효하지 않은 구독자 거부하기 2 249
7.1 확인 이메일 249
7.2 이메일 전달 컴포넌트: EmailClient 251
7.3 유지 가능한 테스트 스위트의 스켈레톤과 원칙 298
7.4 돌아보기 320
7.5 제로 다운타임 배포 321
7.6 데이터베이스 마이그레이션 326
7.7 확인 이메일 전송하기 331
7.8 데이터베이스 트랜잭션 365
7.9 정리 371

CHAPTER 8 오류 핸들링 373
8.1 오류의 목적은 무엇인가? 373
8.2 운영자를 위한 오류 핸들링 380
8.3 제어 흐름에 대한 오류 394
8.4 ‘Ball Of Mud’ 오류 enum를 피하자 404
8.5 누가 오류를 기록해야 하는가? 412
8.6 정리 414

CHAPTER 9 단순한 뉴스레터 전달 416
9.1 사용자 스토리는 아직 확고하지 않다 416
9.2 확인되지 않은 구독자에게 스팸을 보내지 말자 417
9.3 확인된 모든 구독자는 새 이슈를 받는다 422
9.4 구현 전략 424
9.5 바디 스키마 425
9.6 확인된 구독자 리스트 꺼내기 428
9.7 뉴스레터 이메일 전송하기 431
9.8 저장된 데이터 검증 433
9.9 단순한 접근 방식의 한계 442
9.10 정리 444

CHAPTER 10 API 보호하기 445
10.1 인증 445
10.2 비밀번호 기반 인증 447
10.3 과연 안전한가? 490
10.4 인터루드: 다음 단계 494
10.5 로그인 폼 494
10.6 로그인 498
10.7 세션 548
10.8 최초 사용자 568
10.9 리팩터링 589
10.10 정리 597

CHAPTER 11 결함 감내 워크플로 599
11.1 POST /admin/newsletters: 리프레셔 599
11.2 우리의 목표 601
11.3 실패 모드 602
11.4 멱등성: 소개 604
11.5 테스트로서의 요구 사항 #1 608
11.6 구현 전략 609
11.7 멱등성 스토어 611
11.8 Save와 Replay 614
11.9 동시 요청 630
11.10 오류 처리하기 640

마치며 663
찾아보기 665

트렁크 기반 개발에서는 메인 브랜치를 언제든지 배포할 수 있어야 한다. 모든 구성원은 메인에서 브랜치를 분기할 수 있으며, 작은 기능을 개발하거나 버그를 수정하고 메인 브랜치로 병합한 후 사용자에게 릴리스한다. / 지속적인 통합은 오래된 브랜치들 때문에 일어나는 병합 충돌(merge conflict)을 줄이며, 피드백 루프를 강화한다. 선택한 접근 방식이 다른 팀의 지지를 받지 못하거나 프로젝트의 다른 부분과 잘 통합되지 않는다는 것을 아는 데 걸리는 시간을 줄인다. 또한 팀원과 협업하도록 하며 필요하다면 아무도 기분이 상하지 않게끔 경로를 수정한다. (9쪽)

애플리케이션에서 사용하는 모든 것은 통합 테스트에 반영되어야 한다. 특히 구조화된 로깅은 통합 테스트가 실패했을 때 디버깅의 속도를 상당히 높여준다. 디버거를 연결할 필요가 없을 수도 있고, 로그가 우리에게 무엇이 잘못되었는지 알려줄 수 있는 경우가 더 많다. 좋은 벤치마크이기도 하다. 로그를 통해 디버그할 수 없다면, 프로덕션에서 디버그를 하는 것이 얼마나 어려울지 상상해보자. (142쪽)

수신자 이메일 주소, 제목, 이메일 내용은 반드시 필요하다. HTML과 일반 텍스트 버전의 이메일 콘텐트를 요청할 것이다. 일부 이메일 클라이언트들은 HTML을 렌더링하지 못하며 또 어떤 사용자들은 명시적으로 HTML 이메일을 비활성화하기까지 한다. 두 개의 버전을 함께 보냄으로써 안전한 사이트에 설 수 있다. 보내는 사람의 이메일 주소는 어떻게 해야 하는가? 클라이언트 인스턴스에 의해 전송되는 모든 메일은 동일한 메일 주소로부터 전송된다고 가정한다. 따라서 발신자 이메일 주소를 send_email의 인수로 넣을 필요는 없다. 발신자 주소는 클라이언트 생성자의 인수 중 하나가 될 것이다. (254쪽)

좋은 테스트 스위트는 무엇보다 리스크 완화에 도움이 된다. 자동화된 테스트는 기존 코드베이스에 대한 변경과 관련된 리스크를 줄인다. 대부분의 재귀와 버그들은 지속적인 통합 파이프라인에서 잡히며 사용자에게 도달하지 않는다. 따라서 팀은 빠르게 반복하고 더 자주 릴리스할 수 있게 된다. / 테스트는 문서의 역할도 한다. 테스트 스위트는 알지 못하는 코드베이스에 뛰어들기 위해 좋은 시작점이다. 테스트 스위트는 코드가 어떻게 동작하기로 가정되어 있는지, 어떤 시나리오들이 전담 테스트를 가질 만큼 관련이 있는지 알려준다. (299쪽)

제어 흐름은 스크립트로 작성된다. 다음에 할 일이 무엇인지 결정하기 위해 필요한 모든 정보는 머신에 접근할 수 있어야 한다. 내부 오류를 위해서는 타입(즉, enum 변형), 메서드, 필드를 사용한다. 경계에서의 오류는 상태 코드에 의존한다. / 대신 오류 보고서는 주로 사람이 참조한다. 콘텐츠는 소비 대상에 따라 조정되어야 한다. 운영자는 시스템 내부에 접근할 수 있다. 운영자는 실패 모드에 관해 가능한 한 많은 정보를 얻을 수 있어야 한다. 사용자는 애플리케이션 경계 바깥에 앉아 있다. 사용자들은 필요한 경우 그들의 행동을 조정하는 데 있어 필요한 정도의 정보만 받아야 한다(예: 잘못된 입력을 수정한다). (379~380쪽)

세션 기반 인증은 모든 페이지마다 사용자에게 비밀번호를 요청하는 것을 피하기 위한 전략이다. 사용자는 로그인 폼을 통해 한 번만 인증을 요청받는다. 인증이 성공하면 서버는 일회성 시크릿, 즉 인증된 세션 토큰을 생성한다. 백엔드 API는 사용자 이름/비밀번호 조합 대신 세션 토큰을 받고 제한된 기능에 대한 접근을 허가한다. 이 세션 토큰은 모든 요청마다 제공되어야 한다. 그러므로 세션 토큰은 쿠키로 저장된다. 브라우저는 API로 전송되는 모든 요청에 쿠키를 붙여야 한다. (549쪽)