[도서 리뷰]누구나 이해하는 클라우드 인프라 지식 사전

** 한빛미디어 서평단 <나는 리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다.

 

역사적으로 보면 요즘만 그런 것은 아니겠지만, 채용과 관련된 이야기 중 좀 더 강조되어 이야기 하는 부분이 있다.

바로 신입은 뽑으려 하지 않고, 경력만 뽑으려 한다는 것이다.

사실 채용하려는 입장에서는 당연한 부분으로 보이긴 한다.

대상 인재에 대해 제대로 알지 못한 상황에서, 비어있는 상태로 하나씩 채우려면 얼마나 많은 시행착오를 거쳐야 할지 막막하기 때문이다.

그래서 시간이라는 비용을 지불하고 다양한 경험을 누적한 인재를 선호하는 것은 자연스러운 현상일 것이다.

물론 대학이나 정규 학습과정을 통해 얻는 지식의 깊이도 무시할 수는 없지만, 어디까지나 학문적인 부분은 학문적인 요소들로 가득차있다. 그것이 옳고 그름을 떠나 그렇게 되어 있다는 것이다. 학문적인 분야가 너무 실무 중심으로만 되어 있어도 문제이기 때문에 학교나 시대에 따라 그 비율은 다를 수 있으나 실무만으로 채워진 경우는 찾기 어렵다.

많은 실무 지식은 실제로 일하면서 겪게되는 경험이 많기 때문에, 그 경험을 토대로 많은 것을 누적하게 된다.

그런 지식이 한번씩 휘발되고, 다시 누적되기를 반복하지만, 이따금 리마인드 하고 싶을 때, 나는 책을 통해 그 부분을 메우곤 한다.

 

책 정보

표지

표지는 상당히 스테디한 느낌을 준다.

그렇게 유행을 타거나 여러 키워드의 나열로 보이는 것이 아닌, 이 책의 모든 내용을 포괄하는 수식어와 함께 사전이라는 접미어를 붙여서 표현하였다.

이 책을 고르게 된 것도 인프라에 대한 지식을 어떤 것이든 다 전달하지 않을까 하는 생각에서 시작했는데, 이 책의 제목과 부제가 한 몫을 했다고 생각한다.

 

- 정가: 33,000원(전자책 27,600원)

- 분량: 576쪽

- 저자: 바바 도시아키

- 옮긴이: 김완섭

 

특징

(1) 용량과 부하 관리

12팩터

용량과 부하 관리 그 자체에는 어려운 부분도 많고, 사실 실제로 닥쳐야 와 닿는 부분이 많다고 생각되었다.

그래서 쉽게 읽히기는 어렵기도 하고, 읽혔다 하더라도 기억에 많이 남지 않을 것 같다.

하지만, 이 부분은 중요할 것 같아서 별도로 체크를 해 두었다.

The Twelve Factor이다.

1. 코드 기반: 버전 관리되는 하나의 코드 기반을 가지고 여러 환경에 배포한다.
2. 의존 관계: 의존 관계를 명시적으로 선언해서 분리한다.
3. 설정: 설정을 환경 변수에 저장한다.
4. 백엔드 서비스: 백엔드 서비스를 외부 리소스처럼 취급한다.
5. 빌드, 릴리스, 실행: 빌드, 릴리스, 실행 세 가지 단계를 엄격하게 분리한다.
6. 프로세스: 애플리케이션을 하나 또는 여러 스테이트리스 프로세스로 실행한다.
7. 포트 바인딩: 포트 바인딩을 통해 서비스를 외부에 공개한다.
8. 병렬성: 프로세스 모델을 기반으로 스케일 아웃한다.
9. 폐기 용이성: 빠른 실행과 그레이스풀 셧다운으로 안정성을 최대화한다.
10. 개발/프로덕션 환경 일치: 개발, 스테이징, 프로덕션 환경을 가능한 한 일치시킨 상태로 유지한다.
11. 로그: 로그를 이벤트 스트림으로 처리한다.
12. 관리 프로세스: 관리 태스크를 1회용 프로세스로 실행한다.

 

이 부분은 원칙에 관한 부분이기에 별도로 숙지해야, 문제를 예방하기에 좋다는 생각이 든다.

개발자로서 개발 원칙은 많이 알고 있지만, 이렇게 인프라 관리를 위한 원칙은 생소하여 인상적인 부분이었다.

 

(2) 인터넷

URL 구성요소

URL을 구성하기 위해 각 구문을 어떤 요소로 채워져 있는지 쉽게 지나치는 편이 많다.

이런 것을 잘 안다고 하는 나조차도 Fragment는 생소하다. 그리고 ssh 접속할때야 사용했지만, password도 이 구성 요소 중 하나라는 생각을 이어서 하지는 못했었다.

이걸 잘 알고 있으면 나중에 각 요소별로 따져서 분석하기에도 좋다. 애초에 주소를 구성할 때도 효율적으로 할 수 있다.

그리고 well known port도 조금 나와 있는데, 이 부분도 알아두면 좋다.

 

도메인명 구조

그리고, 도메인 명 구조도 대부분의 경우는 그냥 도메인 업체에서 검색해서 하나 부여받고 사용하면 그만이지 않나 싶지만, 나의 도메인을 좀 더 확장해서 쓴다거나, 긴 이름으로 사용하려고 할 때 어느정도까지 쓸 수 있는지도 모르면 낭패를 볼 수 있기 때문에 이런 규칙은 중요하다.

또한 Top level 도메인 뿐 아니라 보통 4차레벨까지 있다는 것은 간과하기 쉬운데, 우리가 사용하는 도메인에 별 생각없이 사용해도 3차나 4차까지는 그냥 사용하는 수준임을 알고 있어야 편하다. 그리고 이 구조는 트리구조를 갖고 있어서, 1차부터(엄밀히 말하면 dot 부터) 시작하여 내가 가진 주소를 탐색하는 것임을 알고 있다면 효과적인 라우팅을 고민할수도 있을 것이다.

 

OSI 7계층

OSI 7계층에 대한 부분은 실무도 중요하지만, 대학교에서 교과과정으로도 쉽게 다루었던 부분이다.

L2 스위치, L4 스위치 등의 단어도 실무에서는 쉽게 들을 수 있는데, 이것이 무슨 모델명인가 하고 생각할 수도 있다. 하지만 이 역시 OSI 7계층에 의한 레이어를 나타내는 부분이며, 어느 레이어에서 관리하여 이중화를 하고 있는지 알 수 있는 부분이다.

이것을 정확하게 알아야 장애든, 배포든 쉽게 핸들링 할 수 있기 때문에 용어도 개념도 모르면 실무가 어려워진다.

 

HTTP 상태코드

그리고 개발자로서 자주 맞닥뜨리는 부분이기도 한 HTTP 응답에 대한 상태코드도 중요하다.

쉽게 볼 수 있는 200 OK 뿐 아니라, 404에러는 에러로써 쉽게 볼 수 있는 부분이기도 하다.

그 외에도 다양한 오류코드가 있는데, 여기에서 언급한 코드만 미리 알아도 해당 부분에서 사용자에게 당혹감을 주지 않도록 할 수 있다.

이것을 간과하면 맞는 길 외에는 다른 오류의 상황에서 제대로 대응할 수 없게 되어 사용자의 경험을 매우 좋지 않도록 하게 된다.

 

(3) HTTPS

단순 도메인을 구입해서 사용하는 수준이라면 인증서에 대한 생각을 못할 수 있다.

하지만, 진짜 운영하는 서비스를 계획중이라면 SSL 인증서는 필수이다.

안그래도 피싱이나 해킹 등의 다양한 보안사고가 잇따르고 있는데, 그 대열에 동참할수는 없지 않은가.

애초에 사용자가 이런 것에 대응도 되지 않은 사이트에 접근도 꺼려하게 된다.

Let's encrypt가 유명해지기 전에는 인증서는 비용때문에 접근이 어려웠는데, 이제는 마음만 먹으면 쉽게 적용할 수 있다.

각종 클라우드를 사용하든, 개인 홈서버를 사용하든, 각 서비스에도 기본적으로 SSL 연동을 쉽게 할 수 있도록 되어 있기 때문에 기술적인 어려움은 없을 것이다.

하지만, 인증서의 개념 자체를 모르면 이야기는 다르다. 필요성도 모르고, 도입도 하지 않을 가능성이 높기 때문이다.

SSL은 무엇인지, 그리고 얼마나 자주 갱신해야 하는 것인지 그 이유와 함께 파악해 놓으면 도움이 된다.

(4) 운영

테넌시 모델

운영환경 구성시 나의 서비스를 다양한 고객에게 제공하는 경우들이 있다.

이 책의 비유를 빌자면, 백화점이나 쇼핑몰의 인프라라면, 그 안에 입점한 의류 매장이나 식품 매장 같은 각 점포가 테넌트에 해당한다는 것이다. 이 개념은 각 어카운트 개념으로도 볼 수 있다.

하나의 서버를 구성하며 테넌트를 제공하는 것을 멀티 테넌트 모델이라고 하는데, 이 부분이 개발 관점에서는 잘만 설계한다면 유용해 보인다. 대형 서비스를 제공하는 곳이 아니라면 멀티서버 관리에 대한 이슈가 있진 않기 때문이다.

요즘 AI 서비스를 사용하면서, 나역시 작은 서비스를 하나 만들고 있는데, 이 부분에 테넌트 모델을 적용했다. 이것을 모르고 사용했었는데, 개념적으로 알고 사용해야 나중에 취약한 부분에서 큰 손해를 입지 않을 것이기 때문에 이 부분을 유의해야 한다.

이 외에도 싱글 테넌트 모델 및 하이브리드 테넌트 모델이 존재한다. 각 필요에 따라 사용하면 된다.

 

컴플라이언스 원칙

서비스가 어느정도 자리를 잡으면 반드시 신경써야 하는 부분이 컴플라이언스이다.

애초에 모바일 앱 서비스라면, 각 스토어에 배포시 기본적으로 챙겨야 할 이용약관들이 있다. 그런 부분으로 이미 참여를 하고 있는 부분이겠지만, 그 외에도 다양한 컴플라이언스에 대응해야 한다.

특히 국가별, 지역별, 연령별 대응이 다르게 존재할 수 있기 때문에 중요하다.

 

(5) 기타

서버 주문 일정

이 부분은 좀 특이해서 꼽아보았다. 서버 주문에 관한 일정까지 고려해야 한다는 사실이다.

사실 요즘은 클라우드를 사용하는 케이스가 매우 많기 때문에 이 부분을 고려할 경우가 얼마나 되겠냐 하겠지만, 그럼에도 클라우드를 도입하는 것이 좋은지, 서버를 신규 구성하거나 증설하는 것이 좋은지에 대한 효율성을 따져보는 측면에서는 고려해야만 하는 영역이다.

이 부분이 특히 인상적이었던 사실은, 이론적인 것보다 좀 더 실무적인 부분을 챙겨주는 느낌이 들어서이다.

물론 이 책이 번역서이고, 원서 그대로 차용한 부분으로 보이기 때문에, 아마 국내 사정으로 보면 다를 수 있겠지만, 어느정도는 참고할만하다고 생각한다. 각 단계별로 어떤 것들이 있는지는 알아야 하기 때문이다.

 

그 외에도 모든 내용의 끝에 나와있는, 함께 읽으면 좋은 장에 대한 부분이 마음에 들어서 가져왔다.

지금 보고 있는 내용이 단독으로 끝나는 것이 아니라, 다른 부분들과 연결되어 있음을 알 수 있다.

혹시나 내가 이해가 덜 가거나, 아니면 다른 부분으로 생각을 확장하고 싶다면, 이 부분을 참고해서 찾아가면 좋다.

 

이 책을 추천하고 싶은 독자

- 웹, 모바일 등의 서비스를 제공하고 있는 회사의 담당 직원 또는 대표

- 신규 서비스를 만들기 위해 계획 또는 작업 중인 개인(개발자)

- 인프라 전반에 관심있는 취업 준비생

- 나의 지식을 점검해보고자 하는 실무 관련 담당자

 

총평

AI를 이용한 개발이 발달하며 나의 지식이 좀 부족하더라도 이제는 쉽게 웹 서비스 및 모바일 서비스를 만들 수 있는 시대가 되었다.

나 역시도 커서AI를 구독중임과 동시에 코덱스를 간간히 구독하며 나의 생각을 코드화하는 것 뿐 아니라 서비스로 만드는 것에 관심을 갖게 되었고, 실제로 작게나마 서비스를 운영하기 시작했다.

이것까지는 어렵지 않았지만, 문제는 그 다음이었다. 각종 인프라에 대한 부분은 AI 개발로 쉽게 도움받기 어려웠고, 그래서 확장성 부분에서는 두려움이 올라갔다. 결국 이 책을 찾게 되었고, 어느정도는 해소가 되는 부분이 있었다.

사전적인 특성을 가진 책이기 때문에 모든 것을 상세히 다루지는 않고 있지만, 적어도 관련 키워드나 원리원칙들은 알 수 있었다.

최소한 내가 알고 있는 지식이 어떤 것인지, 부족한 부분은 어떤 영역인지 채워가는데에도 도움이 된다. 나와 비슷한 고민을 하고 있는 누군가에게 이 책을 추천한다.

AI 개발 너머에 있는 인프라의 장벽을 낮춰주는 도우미