반응형

전부터 GraphQL 이 어떤 것인지 궁금했었는데 이번에 읽은 책을 통해서 조금이나마 이해를 할 수 있었다.

이 책은 3개의 Part 와 10개의 Chapter 로 구성되어있다. 

Chapter 1 그래프QL 경험해보기 에서는 그래프QL 소개와 사용 방법에 대해서 소개를 해주고 있다. 그리고 그래프QL 로 기본적인 쿼리들을 실행해 볼수 있는 예제들을 담고 있다. 깃허브API 예제를 통해서 실행해 볼 수 있어서 깃허브 계정을 갖고 있다면 쉽게 실습을 따라가볼수 있다.

 

그리고 Chaper2 그래프QL API 작성법 을 통해 본격적으로 그래프QL 을 설계하고 스키마 리졸버를 구현해 본다. 그리고 데이터베이스와 연결하여 모델을 설계해보는 실습을 한다. 아마도 이 Chapter 가 이 책의 가장 핵심이지 않을까 생각이 된다. 이것 이외에도 최적화 방법도 소개를 해주고 있다. 

Chapter3 에서는 여러가지 형태로 그래프QL API 를 사용하는 방법을 소개해 준다. 

책을 읽으면서 느꼈던 점은 매번 Rest API 만 사용해왔던 나에게는 책이 약간 어렵게 느껴졌다. 아무래도 설계 및 구조가 생소하다 보니 그렇게 느꼈던 것 같다. 현재 1독을 하고 있는 중이지만 그정도로는 자세히 이해하기는 어려울것 같다. 따라서 1독 후에 중요 부분에 대한 것만 따로 읽어보는게 필요 할것 같다.

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

 

728x90
반응형
반응형

많은 시간 개발을 하면서 시스템 아키텍처에 대해서 생각을 안해왔던것은 아니었다. 하지만 그런 지식들은 공부를 해서 생기는게 아니라 실제 경험으로 해봐야만 알수 있다는 생각을 많이 했었다. 그런데 요즘드는 생각은 이론으로 알고 실제 경험을 하면 더 많은것을 할수 있고 더 잘 할수 있을거라는 생각이 많이 들었다. 그래서 최근 책을 고를때에 아키텍트 관련 서적을 많이 골랐던것 같다.

개발을 하다가 나이 먹으면 아키텍트를 해야 한다 라는 그런 의견(?) 들이 많긴 한데 개발자에서 아키텍트로 간다는 것은 생각처럼 당연하지도 않고 쉽지도 않다. 지금도 물론 개발도 하고 아키텍트 역할도 하고 있지만 솔직히 그게 아키텍트로서의 역할이 맞는지, 아니면 개발자인지 구분이 안간다. 

그리고 매번 같은 방법, 같은 형식으로만 생각하다 보니 우물 안에 개구리처럼 생각이 닫혀버린 느낌이 많이 들었다. 아마도 관련 지식과 경험의 부족이라고 생각이 든다. 그래서 "개발자에서 아키텍트로" 되기 위해서는 어떤 것들이 필요한지 책을 통해서 조금이나마 알아가보기로 했다. 

이 책은 총 3개의 챕터로 구성이 되어있다.

1부. 소프트웨어 아키텍처

소프트웨어 아키텍처가 어떤 일을 하는 사람인지 알아보는 챕터이다. 그리고 디자인 마인드셋 (이해하기, 평가하기, 탐색하기, 실현하기)은 무엇인 알려준다. 

2부. 아키텍처 설계의 기초

2부에서는 1부에서 말한 마인드셋 영역별로 아키텍처 설계를 어떻게 해야 하는지 기초 지식에 대해서 알아볼 수 있다. 요구사항 분석부터 설계, 패턴, 시각화, 문서화, 그리고 평가까지 기본적으로 알아야 할 내용들이 담겨있다. 그리고 요구사항 분석 이전에 이해관계자들과는 어떻게 대화를 해야 하는지도 알려준다. 

아래 그림은 아키텍처 패턴 부분에서 설명에 추가되어있는 그림과 표이다. 실체 패턴이 어떻게 구성되는지 알수있고 각 컴포넌트들이 어떤 역할을 하고 있는지 쉽게 알수 있다. 

 

3부. 아키텍처의 은빛 도구상자

3부는 지금까지 배운 내용에 대한 실습 과제를 해보는 부분이다. 총 38가지의 주제를 가지고 팀 활동을 해볼수 있다. 그리고 팀 활동도 위에서 말한 마인드셋 영역별로 4가지 주제를 가지고 나눠져 있다. "문제를 이해하고 싶을때", "해결책을 찾고 싶을때", "손에 잡히는 설계를 만들고 싶을때", "설계 대안을 평가하고 싶을때". 

활동의 목적이 무엇인지, 그리고 이 활동을 함으로써 얻을수 있는 장, 단점, 시간, 절차, 예시까지 아주 꼼꼼히 설명이 되어있다. 그리고 설계에 대한것 뿐만 아니라 앞에서 말한 4가지 주제에 해서도 활동이 있기 때문에 책에서 읽은 부분들을 충분히 경험해 볼수 있다. 

개발자가 아키텍트 역량을 키우기 위해 어떻게 해야 하는지 업주적인 내용부터 기술적인 내용까지 두루 살펴볼수 있는 책이다. 그리고 실습해볼수 있는 주제들을 통해 책의 이론을 경험해 불수 있다는 것이 무엇보다도 좋은 부분이었던 것 같다.

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

728x90
반응형
반응형

투자에 대해서 모르지만 그래도 기본은 알아야 겠다 싶어서 읽기 시작한 책. 
주식을 투자하면서 알아야 할 많은 것들이 있었는데 설명은 쉬웠지만 내가 이책을 한번 읽고 다 이해하기에는 역부족이었다. 
그래서 그 많은 내용들 중에 딱 한가지만 뽑았다.

정말 읽으면서 이것만은 꼭 기억하자 라고 하면서 적어놨다.

주식 매도해야할때 베스트6

  1. 처음 생각한 적정 주가 수준이면 분할매도(1/3 정도)
  2. 고점에서 대량의 거래가 이루어지고 장대음봉발생하면 매도
    • 고점일 가능성이 큼
    • 주가를 끌어 올렸던 주체의 보유주식을 대량 처분할때 나타나는 차트 모습
  3. 세번째 전고점 돌파 실패하면 매도
    • 그 가격대에 매물이 쌓이며 저항이 심하다는걸 의미한다.
  4. 기대하던 뉴스가 나오면 매도
    • 내가 주식을 살때 기대했던 일이 실제로 일어났을때 매도
  5. 테마주는 대장주가 꺾이면 매도
  6. 전체 장에 대한 판단이 서면 매도
    • 대세 상승국면, 박스횡보, 대세하락 국면인지 판단하고 매도 결정
    • 대세 상승 : 섣불리 팔지말고 보유후 천천히 매도
    • 박스 : 목표 수익률을 낮추고 짧게 끊어서 매도
    • 대세 하락 : 반등을 이용해서 매도

그냥 1독으로 끝내버리기에는 좀 내가 알아야 할게 너무 많아서 조만간 용어나 이론적인 부분만 빠르게 다시 한번 읽어봐야겠다.

 

728x90
반응형
반응형

이 책은 소프트웨어 아키텍처 설계에 대한 다양한 방법에 대해서 써놓은 책이다. 설계 뿐만 아니라 아키텍트가 알아야 하는 것들 또는 고려해야 하는 상황들도 다양한 관점에서 설명을 해준다. 책을 읽으면서 몇가지 내가 기억해두면 좋을것 같다는 부분들을 아래와 같이 작성해봤다.

아키텍처 대 설계

- 아키텍트와 개발자를 나누는 가상의 물리장벽을 통과하는 단방향 화살표는 많은 문제를 야기한다. 따라서 아키텍처, 설계 모두 소프트웨어 프로젝트 생명 주기의 일부로서 항상 서로 동기화되어야 성공할 수 있다.

아키텍처와 코딩 실무간 균형 맞추는 방법
1. POC를 자주 해본다. 가능한 한 프로덕션 수준의 고품질 코드로 작성하는 것이 좋다.
2. 기술 부채나 아키텍처 스토리에 전념한다. 또는 버그를 수정한다.
3. 코드리뷰를 자주한다.

아키텍처 특성 식별
1. 도메인 관심사에서 아키텍처 특성도출
  - 도메인의 핵심 목표와 현재상황 고려하여 아키텍처 결정
  - 모든 아키텍처 특성을 지원하는 제네릭 아키텍처 설게 --> 가장 흔한 안티패턴
  - 가급적 설계를 단순화 하는게 좋다
2. 요구사항에서 아키텍처 특성 도출

컴포넌트 식별흐름

1. 초기 컴포넌트 식별
2. 요구사항을 컴포넌트에 할당
3. 역할 및 책임 분석
4. 아키텍처 특성 분석
5. 컴포넌트 재구성
위 그림처럼 컴포넌트 식별은 한번에 끝나는게 아니라 컨포넌트의 특성을 분석해 나가면서 계속해서 수정될 수 있다.

컴포넌트 설계
- 엔티티 함정
   각각의 엔티티를 바탕으로 컴포넌트를 만드는것. 이건 프레임워크를 데이터베이스에 컴포넌트 관계형으로 매핑한 것에 불과한것이다. (내가 항상 이렇게 설계를 하고 있지 않나 싶다... )

- 액터/액션 접근법
   애플리케이션에서 뭔가 일을 하는 액터와 그들을 수행하는 액션으로 식별
- 이벤트 스토밍
   다양한 컴포넌트가 메시지나 이벤트를 이용해 서로 통신한다고 가정.
   어떤 이벤트가 일어나는지 파악하고 컴포넌트를 이벤트와 핸들러 중심으로 구축.
- 워크플로 접근법
   이벤트 스토밍의 대안으로 DDD나 메시징을 사용하지 않고 더 일반화 한 방법.
   핵심 역할을 식별하고 이 역할이 관여하는 워크플로 유형을 결정하여 식별된 활동에 따라 컴포넌트 구축.

아키텍처 스타일 : 크게 모놀리식과 분산형으로 나누면 다음과 같은 아키텍처들이 존재한다.
- 모놀리식
   레이어드 아키텍처, 파이프라인 아키텍처, 마이크로커널 아키텍처
- 분산형
   서비스 기반 아키텍처, 이벤트 기반 아키텍처, 공간기반 아키텍처, 서비스 지향 아키텍처, 마이크로서비스 아키텍처 

아키텍처 결정의 안티패턴
- 네 패를 먼저 보여주지마

  아키텍트가 잘못된 선택을 하는 것을 두려워해서 아키텍처 결정을 회피하거나 미루는 현상
  개발팀과 지속적으로 협력하면서 결정한 내용을 의도한 대로 추진 가능함. --> 모든 이슈를 아키텍트가 혼자 다 알수 없기 때문에 개발팀과 협력은 절대적임.
- 무한반복 회의
  어떤 결정을 왜 했는지 모르고 주구장창 회의만 계속 하는것.
  무한반복 회의가 발생하는 이유는 아키텍트가 자신이 내린 결정을 정당화 하는데 실패했기 때문
  아키텍처 결정을 할때 비즈니스 가치를 제시하는 것이 중요함.
- 이메일 기반 아키텍처
  아키텍처 결정을 놓치거나 잊어버리고 심지어는 그렇게 결정됐다는 사실조차 알지 못해 아키텍처 결정을 구현하지 못하는 상태.
  즉, 아키텍처 결정을 효과적으로 전달하지 못해서 발생하는 문제.
  이메일 본문에 아키텍처 결정을 포함하지 않는다. 중요한 세부사항은 단일 기록시스템(위키페이지등)에 보관해서 링크만 제공한다.
  아키텍처 결정에 정말 관심이 있는 사람들에게만 통지한다.
 

협상과 조정 tips
- 상황을 더 잘 이해하기 위해 문법과 유행어를 사용한다.
- 협상에 돌입하기 전 가능한 한 많은 정보를 수집한다.
- 다른 모든것이 실패하면 비용과 시간으로 설명한다.
- '분할 및 정복' 규칙을 활용해서 요구사항 또는 필우 조건을 검증한다.
- 증명은 언제나 논쟁을 이긴다는 사실을 명심한다.
- 지나치게 논쟁을 벌이려고 하거나 협상 과정에서 개인정인 감정을 드러내지 않는다. 간결 명료한 추론에 차분한 리더십을 더하면 반드시 협상에 승리한다.
- 개발자가 아키텍처 결정을 수용해서 어떤 작업을 하도록 설득할 때에는 '고압적으로 지시' 하지 말고 왜 그 일을 해야 하는지 정당성을 제공한다.
- 개발자가 아키텍트의 결정에 동의하지 않을 경우 그들 스스로 해결책을 찾도록 유도한다.

위 내용들 중에서도 특히 엔티티 함정 과 아키텍처 결정 안티패턴은 읽으면서 나 자신이 반성을 많이 하게 되었다. 아마도 내가 그런 안티패턴에 빠져서 설계를 하지 않았나라는 느낌이 많이 들었기 때문이다. 아키텍처에 대한 기초 지식을 얻고자 하는 분들에게 큰 도움이 될수 있는 책이라고 생각한다. 

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

 

728x90
반응형
반응형

2021.09.27 - [Enjoy Life/책을 읽자!!] - [2021-책읽기프로젝트]서울 자가에 대기업 다니는 김 부장 이야기 1 : 김부장편

서울 자가에 대기업 다니는 김부장 이야기의 2권이다. 1권을 읽을때에는 2권이 있는지 몰랐는데 1권을 읽고 나서보니 2권이 있어서 바로 읽게 되었다. 1권이 김부장 시점으로 이야기가 진행된거였다면 2권은 정대리와 권사원 시점에서 이야기가 진행된다.

정대리는 자타 공인 욜로족이다. 결혼을 앞두고 있으며 월급을 받으면 명품도 사고 뽐내고 싶어한다. 여자친구는 카페를 하기 위해서 취업준비는 안하지만 그렇다고 카페를 차리기 위한 준비를 하고 있지도 않다. 둘 다 SNS를 통해서 보여지는 모습들을 중요시한다. 그것 이외에는 별다른 관심은 없다. 정대리는 어렸을때부터 알아오던 금수저 친구들과 항상 비교를 한다. 여자친구와 결혼을 앞두고서 집을 구하러 다니면서 집값이 얼마인지 그제서야 깨닫게 된다. 결혼식을 하고 나서 공원에 산책중에 사고를 당해서 입원하는 동안 큰 수술을 받게 되고 수술비용과 그동안에 쌓았던 할부금들이 큰 부채로 다가오게된다. 그로인해 별거를 하게 된다. 

정대리는 전형적인 "인생 뭐있어~" 라는 생각에 벌면 쓰고 뒤는 생각하는 그런 유형이다. 하지만 두사람 이외에 나오는 송과장이라는 분이 했던 이야기 처럼  다른 사람의 부러움을 쫓아서 했던 행동들이 결국은 꿈을 멀어지게만 했다. 꿈을 위한 노력이 아닌 물질적 대리만족만 하고 끝이 났다. 우리가 매일매일 접하는  화려한 SNS의 사진들 사이에서 과연 내가 얻는건 무엇인지 정대리를 통해서 생각을 해볼 필요가 있다고 생각된다. 그리고 이야기 속에서 송과장이 정대리에게 이런 말을 한다. 죽는 순간이 한번이지 인생은 매일매일 이라고. 정말 공감되는 말이다. 내일 바로 죽는다면 "인생 뭐있어~" 라는 말이 맞다. 하지만 우리의 인생은 오늘이 마지막이 아니고 내일도 있고 모레도 있다. 그렇기에 하기 싫은 일도 해야하고 그 끝에 찾아오는 만족감을 통해 하루하루 발전해 나가는게 아닐까 생각이 된다. 

권사원은 입사하면 다 될줄 알았던 회사생활에 회의를 느끼는 중이다. 본인이 맡은 프로젝트의 결과 발표를 1편에 나온 김부장이 마음대로 수정해서 발표해서 좋은 결과를 받지 못햇다. 그리고 고과는 밀린 선배 때문에 하위로 깔아주고 있다. 그러던 중 1편에 나온 김부장이 다른 곳으로 발령이 난후 새로원 팀장의 요청으로 준비했던 프로젝트를 다시 발표할 기회가 생겨서 좋은 결과를 얻게된다. 그리고 결혼을 생각하고 있던 남자친구와는 의견이 맞지 않아 고민 끝에 헤어진다. 헤어진 후에 스스로 생각했던 집도 알아보고 다니고 고민 끝에 회사를 퇴사하고 대학원 진학을 하게된다. 

내 입장에서는 정대리보다는 권사원의 이야기가 더 가깝게 느껴졌다. 회사생활을 하게되면 항상 부딪치게 되는 업무, 성과, 평가에 대한 이야기가 모두 녹아있다. 직장인이라면 대부분 내가 한 일에 대한 평가를 올바르게 받기를 바란다. 하지만 그렇기는 쉽지 않다. 회사라는 조직은 많은 사람이 있으며 모든 사람에게 좋은 평가를 내릴수는 없다. 그렇기에 인원을 정해놓고 그안에서 줄세우기를 한다. 그렇기 때문에 누가봐도 일을 열심히 하는데 좋은 평가를 받지 못할 수도 있고 권사원처럼 선배들때문에 못받는 경우도 많이 생긴다.

또 결혼 문제에 대해서도 권사원과 똑같은 고민을 하는 사람들이 많을거라 생각이 된다. 결혼은 다가오는데 상대방과 안맞는 것들이 너무 많다. 그냥 진행을 해야하는지 취소를 해야하는지. 답답한 마음에 할머니를 찾아간 권사원에게 할머니는 이렇게 말씀하셨다. "결혼해서 행복하지 않을것 같으면 안하면 되지. 누가 뭐라고 할거야. 인생 대신 살아줄거야?" 이 말에 마음이 정리된 권사원은 헤어지기로 한다. 결혼을 준비하다 보면 트러블이 많이 생긴다. 다른 환경, 다른 가정에서 자란 두 사람이 만나는데 모든 의견이 일치하기는 힘들다. 그것을 맞춰가며, 그리고 그걸 조금씩 양보하는게 결혼생활에서 가장 필요한 부분이라고 생각이 된다. 그런 부분들을 감당할수 있으면 결혼을 하는게 맞고 그게 아니라면 다른 사람을 찾아보는게 현명하다고 생각이 된다. 할머니가 권사원에게 했던 말처럼 말이다. 

그리고 마지막으로 꿈을 찾아 대학원 진학을 결심하는 권사원의 모습을 보고 큰 용기에 박수를 보내고 싶었다. 직장생활을 하면서 과연 이 일이 내가 꿈꾸던 일인가? 라는 생각을 안해본 사람이 있을까? 후배들에게 당당히 꿈을 쫓으라고 이야기 하고 싶지만 현실은 그렇게 만만치 않다. 그렇기에 꼭 직장을 나가서가 아닌 그 안에서 꿈에 한걸음 다가갈수 있는 노력을 해볼 뿐이다. 아마도 다들 비슷한 생각이지 않을까?

2권까지 읽고나니 마지막에 또 3권으로 이어진다고 한다. 3권에는 과연 어떤 이야기가 나올것인지 기대가 된다. 1,2 권 속의 이야기들이 우리가 매일매일 마주하는 현실과 너무나도 비슷했기 때문에 쉽게 읽을수 있었고 이야기들을 통해서 내 자신을 바라보게 되는 계기가 되었다. 

728x90
반응형
반응형

최근에 핫하다고 와이프가 권해주길래 읽게 되었다. 마침 회사 e-book 도서관에 책이 있어서 읽기 시작했는데 읽기가 쉬워서 주말 사이에 1,2권을 다 읽었다. 아무래도 우리가 살고 있는 현실과 많이 비슷해서 더 읽기 쉬웠던것 같다. 단 후기는 1권과 2권을 나눠서 쓰려고 한다.

이 책에서는 회사를 다니면서 볼수 있는 실존할것 같은 인물들이 나온다. 1권에서 나온 김부장이라는 사람은 전형적인 꼰대의 성향을 갖추고 있다. 일단 꼰대의 성향을 정확하게 정의할 수는 없지만 이책에 나온 그의 특징은 다음과 같다.

- 남자는 대학 졸업하면 대기업 취직하는게 당연하다.
- 김부장이 팀원들에게 뭔가를 배우거나 물어본다는 것은 있을 수 없는 일이다.
- 내가 그렌저 타는데 팀원이 외제차 타는 꼴은 못봐준다
- 회식은 물어보지만 언제나 답은 정해져있다.
- 대기업 다니는데 와이프가 부동산 중개업 하는건 있을수 없는 일이다. 아들이 장사를 한다는것도 있을 수 없는 일이다.
- 팀원보다는 내가 돋보여야 한다.
- 동기들보다 내가 무조건 잘났다. 

생각나는 대로 적긴 했는데 이것 이외에도 많은 행동들이 읽는 내내 나온다. 

진급누락 없이 부장까지 온 김부장. 그는 그야말로 그만의 세계에 빠져있는 인물이다. 읽다보면 어떻게 부장까지 올라갔는지는 모르겠는데 어쨌거나 현재는 부장이다. 하지만 누구에게나 찾아오는 퇴직의 시기. 그는 피해가려고 발버둥 쳐보지만 결국은 사직서를 쓰게 된다. 그러면서 오랫동안 직장생활을 해왔지만 나이 50을 넘어서 그제서야 자기 자신에 대해서 바라보기 시작한다. 

책을 읽으면서 과연 어떤 시점부터 김부장에게 변화가 시작되었을까라는 생각을 한다. 그건 아마도 정신과 치료를 받으면서 자기 자신에 대해서 생각해보는 계기가 변화의 시작이 아니었나 생각이 된다. 그전에는 내가 하는 행동들이 모두 옳다고 생각하고 의심을 하지 않았기 때문에 변화의 필요성을 못느꼈던것 같다. 

그래서 난 꼰대라는 기준의 척도가 "변화" 가 아닐까 생각을 한다. 모든 변화가 옳다는 것은 아니다. 모든 것이 다 변해야 한다는 것도 아니다. 하지만 변화가 필요할때 변하지 않는다면 그게 바로 꼰대로 가는 길이 아닐까. 변화가 필요할때 변하는 사람들은 아마도 귀를 열어놓은 사람들, 다른 사람의 말을 경청하는 사람들일 것이다. 그리고 다른 사람 말을 경청하는 사람들은 남을 존중할줄 아는 사람들이다. 이렇게 모든것이 이어져있다. 

나도 어느새 회사에서 10년 차가 되었다. 그래서 요즘은 "난 꼰대인가?" 라는 생각을 자주 해본다. 아닐꺼야라는 생각을 하면서도 마음 한구석에는 불안한 마음이 든다. 전에 인터넷에서 읽었던 짧은 글이 있다.

" 모든 프로젝트에는 돌+I 가 반드시 있다. 없다고 생각한다면 바로 당신이 돌+I 이다."

우스갯 소리 같지만 아닐꺼라는 장담은 못하겠다. 최근에 읽은 책중에 가장 빠른 시간에 읽은 책이었는데 여운이 많이 남는다. 아마도 많은 독자들이 공감하겠지만 내 주변의 일 같기 때문일것이다. 처음에 읽을때에는 김부장의 설정이 너무 비약이 많지 않나 싶었는데 읽으면서 더한 사람도 있을것 같다는 생각을 했다. 그리고 읽으면서 나는 이렇게 되지 말아야지라는 다짐을 참 많이 했다. 

 

728x90
반응형
반응형

이 책은 마이크로서비스에 대한 이론적 지식과 실습 프로젝트를 통해서 실제 마이크로서비스를 구현해볼수 있는 내용을 담고 있다. 두가지의 서비스를 각각의 다른 언어로 설계부터 개발, 릴리즈, 배포까지 프로젝트의 한 사이클을 담아놨다. 저자가 말했듯이 실제 production 에 반영을 하기에는 부족하긴 하지만 마이크로서비스를 경험해 보기에는 충분한 예제이다. 

마이크로 서비스는 굉장히 주목받고 있는 아키텍쳐이긴 하지만 실제 구현하기는 쉽지 않다. 우선 무엇보다도 뭐부터 시작해야할지가 가늠이 안간다. 모놀리스 아키텍쳐에 익숙한 개발자에게는 어느정도를 기능단위로 나눠야 되는지 구분하는게 가장 어렵게 느껴진다. 

이 책에서도 서비스 경계 설정에 대해서 다음과 같은 고려사항들을 언급해 놓았다. 

- 느슨한 결합
  - 서비스를 변경해도 다른 서비스에 영향을 주지 않는다.
  - 독립적인 배포가 가능해진다.
- 높은 응집력
  - 하나의 기능만 담당하기 때문에 응집력이 높아진다. 
- 비즈니스 기능과 연결
- 도메인 주도 설계
  - 테이블 기준이 아닌 업무 도메인 기준으로 설계가 되어야 한다.

또 한가지 중요한 요소중 하나는 데이터 이다. 

마이크로서비스의 데이터 공유
- 물리적인 데이터베이스 클러스터 공유는 가능하다
- 여러개의 마이크로서비스가 동일한 논리적인 테이블 공간과 데이터를 수정하지 않아야 한다.


여기에서 물리적인 데이터베이스 클러스터 공유가 가능하다는 말은 예를들어 같은 데이터베이스를 사용하되 스키마는 달라야 한다정도로 이해를 했다. 

다음은 개발자 워크스페이스에 대한 내용과 가이드 라인이다. 가이드 라인 같은 경우는 책에서 제시하는 환경에 의존적인 부분이 있긴 하지만 알아두면 좋을것 같다.

표준을 수립할 때에는 기술적인 '방법' 과 '무엇'을 제시하기 전에 사람들이 프로세스의 '이유'에 대해 공감할 수 있어야 한다.

  • 짧은 시간 내에 코드 설정이 가능해야 한다.
  • 새로운 마이크로 서비스는 빠르고, 쉽고, 예측 가능하게 만들어야 한다.
  • 품질 관리는 자동화되어야 한다.

개발자 경험을 위한 10가지 워크스페이스 가이드라인

  1. 도커를 유일한 종속성으로 만든다.
  2. 실행환경이 원격인지 로컬환경인지는 중요하지 않다. -> 환경에 관계 없이 실행 가능 해야한다.
  3. 서로 다른 기술 스택의 워크스페이스를 준비한다.
  4. 단일 마이크로 서비스를 실행하는 것과 여러개의 하위 시스템으로 구성된 마이크로 서비스를 실행하는것은 간단해야 한다.
  5. 가능하면 데이터베이스는 로컬에서 실행한다. (도커 사용)
  6. 컨테이너화 가이드라인을 구현한다.
  7. 데이터베이스 마이그레이션을 위한 간단한 규칙을 정한다.
    • 데이터베이스에 대한 변경사항은 마이그레이션 스크립트에 코드화 되어있어야 한다.
  8. 실용적인 테스트 자동화 방법을 정한다.
  9. 분기 및 병합 규칙을 정한다. -> 브랜치 관리
  10. 공통사항은 makefile 에 코드화 한다.

 그리고 이 책에서는 프로젝트코드들이 있다. 환경설정부터 시작해서 필요한 리소스나 툴들의 사용법들이 차례차레 나온다. 사용되는 툴의 종류도 다양하다. 우선 클라우드는 AWS 를 사용하고 Docker, Terraform, Github, kubernetes, Node.js, Argo CD 등이 있다. 

책에 그림이나 코드들이 다 나와있긴 하지만 처음부터 끝까지 따라하기는 쉽지는 않을것 같다. 그래서 책에 나온 툴들에 대해서 자세히 알 필요는 없지만 기본적인 기능을 조금이라도 알고 있다면 프로젝트를 진행하는데 더 수월할 것이다. 

여러번 말했지만 마이크로서비스로 가는 길은 쉽지 않은 길이다. 하지만 이론부터 차근차근, 작은것부터 점진적으로 변화를 시켜나간다면 실패를 줄여 나갈수 있을 것이다. 그리고 이책을 통해서 전체적인 시스템이 어떻게 구성되는지, 그리고 무엇이 필요한지 기본적인 지식을 습득한다면 큰도움이 될것이다.

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

728x90
반응형
반응형

이 책을 읽기전에 저자의 알고리즘 동영상 강의를 몇번 본적이 있었다. 그래서 이 책이 나왔을때 어떤 내용으로 구성이 되어있을지 궁금했다. 그런데 마침 이렇게 한빛미디어 나는 리뷰어다를 통해서 리뷰를 작성하게 되었다.

- PART 01

처음에는 코딩 테스트, 또는 알고리즘 문제 풀이를 어떻게 준비를 해야 하는지 사전 지식을 알려준다. 코딩을 위한 준비라든지 최근 몇년간 코딩테스트 유형들을 설명해준다. 그리고 취업관련 프로세스나 준비 방법들도 간단히 소개해 주고 있다.

- PART 02 ~ PART 03

PART02 와 PART03 에서는 본격적으로 코딩테스트를 위한 이론과 기출을 풀어볼수 있다. PART02 에서는 주요 알고리즘에 대한 설명과 연관된 문제를 풀어볼 수 있다. 알고리즘 관련된 책들이 비슷한 구성을 가지고 있다고 생각이 되는데 각각의 특징은 설명을 어떻게 해주냐인것 같다. 이 책은 그런점에서 이해하기 쉽게 설명을 해주고 있다. 그리고 그림이나 음영을 적절하게 써줘서 읽어보는데 지루하지 않았다.

- PART 04

이 책의 코드들은 파이썬으로 되어있다. 그렇기 때문에 파이썬에 대해서 알 필요가 있는데 모른다고 해서 책을 못읽는 것은 아니다. 이렇게 부록에 파이썬 문법들을 넣어줬다. 물론 파이썬에 대한 모든 내용들이 들어간것은 아니지만 코딩테스트 문제를 풀기 위해서 이정도 알고 있으면 충분히 문제 푸는데에는 문제가 없을것이다. 그리고 코딩테스트 코드 작성시 유용하게 사용되는 패턴들도 있어서 참고하면 문제 푸는데 많은 도움이 될것같다.

그리고 앞에서 설명했던 알고리즘들 이외에도 코딩테스트에 유용한 알고리즘들이 부록에 많이 담겨져 있다. 우리가 수학으로 배웠던 내용들이 주로 포함되어 있다. 나같은 경우에도 실제로 코딩테스트 문제에서 알고 있으면 쉽게 풀었지만 막상 모르고 풀면 코드 작성하기가 힘들었던 문제 유형들이다. 

- 온라인 강의

마지막으로 이 책의 온라인 강의를 볼수 있다.  요즘 책들은 거의 온라인 강의를 포함하는 경우가 많은데 이 책도 이렇게 저자의 온라인 강의를 볼 수 있다. 책은 책대로 읽고 온라인 강의도 본다면 이해하는데 도움이 될것이다. 이 책 보기전에도 몇번 동영상 강의를 봤었는데 저자분이 목소리가 낮고 차분하고 과장되지 않아서 귀에 더 잘 들렸다. 

- 마무리

코딩 테스트라는게 아무래도 이론만 가지고는 결과를 보는건 거의 불가능한 시험이다. 얼마나 많이 풀어보고 다양한 유형의 문제를 경험해봤는지가 가장 중요하다고 생각한다. 그렇다는건 결과적으로 내가 많이 문제를 풀어봐야 한다.어떤 알고리즘책을 읽든 그것은 변하지 않는다. 하지만 처음 코딩테스트를 준비하거다 기본부터 파이썬으로 준비를 하고 싶은 분들에게는 한번쯤 읽어보면 꼭 도움이 될거라 생각이 든다.

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

728x90
반응형
반응형

우리는 매일 매일 핸드폰을 통해서, 컴퓨터를 통해서, 그리고 기타 다른 도구들을 통해서 쏟아지는 데이터의 홍수 시대에 살고 있다. 그리고 우리는 그 데이터들을 다듬어서 많은 곳에 사용을 하고 있다. 

여기에서 중요한 점은 데이터를 누구에게, 어떤 형태로 보여줘야 하는지 결정하는 일이다. 쌓아 놓은 데이터들을 그냥 보여줄수는 없는 일이다. 이 책에서는 바로 데이터를 어떻게 보여줘야 하는 지에 대한 내용을 담고 있다.

우리는 데이터를 누군가를 설득하기위한 근거 자료로 많이 사용을 한다. 결국 누군가를 설득하고 어떤 결과를 유도하기 위해 데이터를 보여주지만 그것만으로는 만족한 결과를 얻을수가 없다. 그래서 우리가 읽는 소설이나 드라마에 기승전결이 있듯이 데이터에도 이러한 이야기가 필요하다. 우리가 가지고 있는 데이터들이 좀더 극적으로 보여주기 위해서, 또는 설득하려는 사람의 마음에 조금이라도 각인 시키기 위해서는 기억에 남을 만한 이야기 구상이 필수적이다. 

또한, 데이터 하나를 보여줌에 있어서 어떤 형태, 또는 어떤 그래프로 표현을 할지, 그리고 어떤 단어나 문장을 선택할지에 대해서도 꼼꼼히 생각을 해야 한다. 

하나의 차트를 설명하는 데에도 이렇게나 많은 표현들이 존재한다. 내가 사용하는 단어들 또는 문장들이 표현에 맞는지 그리고 좀더 나은 표현들은 없는지 참고해 볼 수 있다. 

이렇게 이 책에는 데이터를 구성하는 방법, 표현하는 방법, 설명하는 방법들이 잘 정리 되어있다. 데이터에 대한 내용 뿐만아니라 발표하는 방법 또는 프리젠테이션 구방 벙법에 대해서도 설명되어 있으니 필요시 참고하면 될것 같다.

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

 

728x90
반응형

+ Recent posts