Polpid's Pensieve

PS C:\Users> wsl -l -v
  NAME                   STATE           VERSION
* docker-desktop-data    Stopped         2
  docker-desktop         Stopped         2
  Ubuntu-18.04           Running         2

위와 같이 배포버전이 여러개 일 경우 default 로 설정되는 배포버전으로 변경하기 위해서는 다음과 같이 설정하면 된다.

 C:\Users> wsl --setdefault Ubuntu-18.04

그럼 다음과 같이 변경이 된다.

 C:\Users> wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu-18.04           Running         2
  docker-desktop         Stopped         2
  docker-desktop-data    Stopped         2

이것을 찾아봤던 이유는 VS Code 에서 remote로 WSL 로 접속하려고 하니 계속해서 docker-desktop-data 로 연결을 시도하면서 실패를 했다. 연결하려는 타겟이 ubuntu 가 되어야 할것 같은데 docker-desktop-data 로 계속 시도를 했다. 그래서 위와같이 디폴트 배포버전을 변경하니 정상적으로 연결됐다.

코드로 인프라를 관리하기 위해서는 어떤 것들이 필요할까. 어쩌면 우리는 이미 어느 순간 자기도 모르게 코드를 인프라로 관리하고 있을지도 모른다. 가장 간단한 예로 설정파일을 Git에 push 하고 운영, 검증, 개발로 나누어서 관리하는 것도 코드로 인프라를 관리하는 것이다. 단지 그 범위가 좁을 뿐이다. 

코드리 인프라를 관리하기 위해서는 다음과 같은 것들이 필요하다.

1. 모든 것을 코드로 정의한다.

우리가 생각하는 것 보다 코드로 관리를 할수 있는 것들이 정말 많다. 간단한 설정파일 부터 시작해서 인프라를 구성하는 요소들 까지 말하기 시작하면 한도 끝도 없다. 그리고 최근에는 클라우드를 많이 사용하기 때문에 정의해야 할 요소들이 더 많아졌다. 퍼블릭 클라우드에서 화면에서 직접 마우스를 클릭하면서 리소스를 생성할 수도 있지만 그러한 모든 작업을 코드로 정의해서 한번에 실행해 버리면 우리가 마우스를 여러번 클릭하는 수고를 덜어줄수 있다. 그리고 정의한 내용이 파일로 남아있기 때문에 언제든지 반복작업이 가능하다. 

2. 코드를 지속적으로 테스트 하고 딜리버리 한다.

코드를 작성하기 전에 테스트 코드를 만들고 수십개의 테스트 코드들을 자동으로 실행시켜서 변경에 대한 영향이 없는지 확인하는 작업은 우리가 코드를 작성할 때 자주 하는 일들이다.  인프라를 정의한 파일들도 하나의 코드들과 유사하다. 실제 정상적으로 작업이 되는지 오류는 없는지 검증이 필요하고 테스트가 필요하다. 결국 그걸 확인하기 위해서는 테스트를 해봐야 하고 실제 생성해보기도 해야 한다. 우리가 모르는 순간 리소스의 명칭이 바뀔수도 있고 정의하는 문법들이 변경되어있을 수도 있다. 자주 확인하고 테스트 해보는 노력이 필요하고 자동화가 필요하다.

3. 시스템을 작고 간단하게 빌드한다. 

인프라의 리소스를 코드로 작성해 놓은것을 찾아보면 상당히 길다. 몇줄만 가지고 끝나지는 않는다. 최소 수십줄에서 수백줄에 이를수 있다. 어느 순간 무엇이 어디 정의되어있는지 한참 찾아야 될 수도 있다. 그런 것들을 피하려면 어떻게 해야 할까. 최대한 모듈로 나눠서 작성하는 것이다. 덩치가 커지만 연관관계가 늘어나고 시간도 오래 걸린다. 그리고 실패할 경우 다시 생성해야 되는 리소스들이 많아진다. 

클라우드 사용이 늘어나면서 수많은 리소스들을 컨트롤 해야 하는 일들이 많아졌다. 그런 리소스들을 관리하기 위한 방법이 필요하고 그게 바로 코드로 인프라를 관리하는 것이다. 특정 툴을 이용한 방법을 알아본건 아니지만 이 책을 통해서  어떤 방법이 있는지, 어떤 패턴들이 있는지 공부할 수 있다. 

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

책 표지에 보면 "비유와 이야기로 풀어낸 비전공자를 위한 필수 IT 교양서" 라고 써있다. 책 내용의 대부분이 IT 관련 용어들, 상황들에 대한 이해를 돕기위한 이야기들로 구성되어있다. 

IT 교양서인만큼 읽는데 어려움은 없었다. 물론 전공자의 입장에서 책을 읽었기 때문에 더 쉽게 느껴졌을 수는 있다. 책에 나오는 내용들에 대해서 이미 알고 있거나 최소한 한번정도는 들어봤던 용어들이었기 때문이다. 하지만 비전공자라고 해서 이해하지 못할 내용은 없어보였다. IT 용어들 중에서도 일상생활에서 충분히 들어봤을 정도의 용어들이 나오기 때문이다. 수학적 지식이나 프로그래밍 관련 전문 지식들이 많이 섞여서 내용이 구성되었다면 읽다가 어려움을 느꼈을 분들이 많을지 모르겠지만 이책은 그런 부분은 거의 없어서 일반 교양서처럼 쉽게 읽을 수 있다.

책 구성을 보면 여러개의 주제들이 있는데 그중에서도 내가 맘에 들었던 부분은 지식 전달 전에 짧막하게 이야기를 써준 부분이었다. 용어 설명에 앞서서 이런 이야기들이 그림과 함께 담겨있어서 재미있었다. 그리고 그 이야기들이 앞으로 나오는 설명에 대한 이해를 돕기 위한 내용이기 때문에 실제 본문을 읽을때 도움이 됐다. 

이 책의 가장 큰 장점은  IT 서적임에도 불구하고 알기쉽게 설명해서 다양한 독자들이 읽을수 있게 한 부분인것 같다. 성인 뿐만 아니라 중고등학생이 읽어도 교양지식을 쌓을수 있는 재미있는 책이다.

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

최근에는 마이크로 서비스라는 단어가 굉장히 빈번하게 사용되고 있다. 클라우드환경이 당연히 여겨지고 거기에 배포하여 운영하는 소프트웨어들이 많아지면서 어플리케이션의 구조를 마이크로서비스로 해야 한다는 이야기는 쉽지않게 찾아볼 수 있다. 

하지만 생각했던것보다 기존 모놀리스 오플리케이션을 마이크로서비스로 전환을 한다는 것은 쉽지않은 일이다. 그리고 온프라미스에서 운영되었던 환경들을 클라우드로 이전하는 것도 많은 것들의 대한 검토가 필수적이다. 그만큼 마이크로서비스는 알아야 되는것도 많고 많은 영역의 지식을 필요로 한다. 어디서부터 공부해야 할지도 막막해진다. 

그림으로 공부하는 마이크로서비스 구조, 이 책은 마이크로서비스에 대한 지식을 습득하기에 좋은 책이다. 마이크로서비스에 대한 배경부터 시작해서 구조, 패턴, 사용되는 기술들이 무엇무엇이 있는지 알수 있다.

특히 이 책의 제목에 있는 "그림으로 공부하는" 에 걸맞게 책에는 각각의 개념을 설명하기 위한 그림들이 많이 있다. 각각의 주제를 설명할 때 마다 기본적으로 구조도는 반드시 포함되어있다고 생각해도 무방할 정도로 그림이 많이 있다. 그래서 내요을 파악하는데 머릿속으로 생각하는 것보다 쉽게 이해할 수 있다. 

물론 이 책을 읽는다고 해서 마이크로서비스에 대해서 다 알수는 없다. 이책에서 설명하는 각 장 하나하나가 자세히 살펴보면 훨씬 더 많은 내용들을 공부해야 하는 경우들이 많다. 그만큼 마이크로 서비스는 복잡하고 광범위한 지식을 필요로 하는 구조이다. 

하지만 이 책으로 기본적인 지식을 습득한후 각각의 내용들에 대해서 좀더 깊게 공부해 본다면 그냥 처음부터 시작하는 것 보다는 나을것이다. 

React 에서 Key 가 필요한 이유

• Map 사용시 고유한 Key 가 필요하다.
• React 는 상태를 메모리에 저장하고 있다가 변경된 부분만 렌더링 한다.
• Key 값이 없으면 모든 데이터를 비교해야 하지만 Key 가 있으면 Key만 비교하면 된다.

• <ul>
    {props.users.map((user) => (
      <li key={user.id}>
        {user.username} ({user.age} years old)
      </li>
    ))}
  </ul>

Map 에서 index 를 Key로 하면 안되는 이유

• 0번의 index 가 삭제되면 React 가 변경을 감지하여 리렌더링 되고 0번 부터 다시 매핑한다.
• 1번 인덱스가 0번으로 매핑이 된다.
• 결론적으로 인덱스가 추가되거나 삭제되면 값이 바뀌기 때문에 index 를 key 로 사용하는것은 안좋다.

• 값과 함수를 반환한다.
• 함수는 값을 변화시킨후 컴포넌트를 리렌더링한다
• 여러개의 state 를 정의할 수도 있고 object로 관리할수도 있다.

  const [enteredTitle, setEnteredTitle] = useState('');
  const [enteredAmount, setEnteredAmount] = useState(0);
  const [enteredDate, setEnteredDate] = useState();

  const [userInput, setUserInput] = useState({
    enteredTitle: '',
    enteredAmount: 0,
    enteredDate: ''
  })

  • 주의 할 점은 update 시 object에 있는 일부 키만 업데이트 한다면 다른 키들이 사라진다.
  • 아래와 같이 enteredTitle 키만 정의할 경우 나머지 키는 사라진다. (merge 하지 않는다)

    const titleChangeHandlerNew = (event) => {
      setUserInput.enteredTitle = event.target.value
    };

  • 수동으로 복사가 필요하다. 기본값을 복사한후 오버라이드 한다.

    const titleChangeHandlerNew = (event) => {
      ...userInput,
      setUserInput.enteredTitle = event.target.value
    };

    • 위 방법에서는 문제가 발생할 수 있다.
    • 리액트가 상태업데이트 바로 실행하지 않는다.
    • 따라서 동시에 많은 상태를 업데이트 할 경우 최신값을 잘못 가져올수 있다.
    • 따라서 다음과 같이 사용하는게 더 낫다. (스냅샷을 이용한다)

      const titleChangeHandlerNew2 = (event) => {
      setUserInput((prevState) => {
        return {
          ...prevState,
          enteredTitle: event.target.value
        }
      });
      };

• useState 를 사용해서 set을 했는데 화면에서 안바뀔 경우
  • 사실 변경이 안된것이 아니라 화면만 전환이 안된것이다. (input 같은 경우)
  • 이럴때에는 value 에 입력 값을 바인딩 해준다.

우리가 책을 읽다 보면 어떤 책은 잘 읽힌다(?) 라는 느낌을 받는 책이 있다. 그런데 어떤 책은 아무리 집중을 하고 읽어도 내용에 집중을 할수가 없고 이해가 되지 않는 책들도 있다. 개발자로서 코드를 읽다보면 비슷한 느낌을 경험하게 된다. 어떤 코드들은 따라 읽기만 해도 이해가 되는가 하면 어떤 코드들은 아무리 디버거를 걸어봐도 이해가 안되는 코드들이 있다.

수많은 개발자들이 각자의 개성과 경험을 바탕으로 코드를 작성한다. 그렇다 보니 똑같은 기능을 하는 코드이지만 정말 다양한 모습의 코드들을 찾아 볼 수 있다. 그렇다 보니 우리는 자연스럽게 어떤 코드들이 좋은 코드인지, 좋은 코드를 작성하기 위해서는 어떻게 해야되는지 관심을 갖을 수 밖에 없다. 

"좋은 코드, 나쁜 코드" 이 책은 우리가 좋은 코드를 작성하는데 참고할 만한 다양한 내용을 담고 있다. 각각의 기술이나 기법들이 많이 설명되어 있지만 그중에서도 중요한 키워드는 아래 4가지가 아닌가 싶다.

코드의 가독성
코드의 모듈화
코드의 재사용성 및 일반화
테스트 용이성 및 적절한 테스트

표현은 다르지만 비슷하게 책 표지에도 나와있다. "읽기 쉽고, 기억하기 쉽고, 적용하기 쉬운 코드".  결국 코드의 가독성을 위해서는 모듈화가 필요하고, 모듈화를 하면 재사용성이 높아지고, 일반화를 해야 한다. 그리고 이렇게 모듈화된 코드들은 단위 테스트를 하기도 쉬워진다. 꼬리에 꼬리를 무는것처럼 선순환 구조인 것이다. 반대로 말하면 하나가 잘못되기 시작하면 모든것이 꼬이게 된다. 

이 책은 크게 3가지 파트로 나뉜다. 이론, 실전, 테스트.

이론 부분에서는 좋은 코드를 만들기 위해서 필요한 사전 지식들을 알려준다.

두번째 파트는 이 책의 핵심인 실전파트이다. 실전 파트이다 보니 코드로 설명해주는 양이 점점 많아진다. 그렇기 때문에 코드에 대한 지식이, 특히 자바 기반 지식이 있으면 이해하는데 도움이 될 것이다. 

그리고 이 책을 읽으면서 좋았던 점은 여러가지 문제들을 제시하고 해결책에 대해서 제시해주는 설명 방법이있다. 여러가지 케이스들이 있다보니 실제 코드를 작성할때 알아 두면 좋은 기법들이 많이 있었다. 읽으면서도 이런것 까지 생각을 해야 하는 구나 라는 것들이 많이 있었다. 

마지막으로는 테스트이다. 여러가지 종류의 단위 테스트에 대해서 설명을 해준다. 테스트 부분에서는 기법도 기법이지만 테스트에 대한 철학이 어떻해야 한다라는 내용들이 더 많았던것 같다. 테스트를 해야 되는 부분이 무엇이고 테스트 코드를 작성할 때에는 어떤것에 더 집중을 해야 하는지에 대한 설명이 많았다. 

코드를 작성하는 개발자들은 코드로 대화를 한다. 그렇기 때문에 작성된 코드를 잘 읽을 수 있어야 하고, 또 잘 읽을 수 있도록 작성을 해야 한다. 말은 쉽지만 결코 쉽지 않다. 하지만 이 책에 나와 있는 내용들을 이해하고 기억하고 있다면 충분히 도움이 될 것이다. 

 클라우드를 이용한 개발 및 운영이 지금은 당연한 것으로 생각되고 있다. 그만큼 클라우드는 어느 순간 개발에 대한 영역에서 중요한 포지션을 차지하고 있다. 프로젝트를 시작하게 되면 코드관리, 배포, 운영에 대한 모든 인프라 환경이 클라우드로 변경되어가고 있다. 하지만 우리의 어플리케이션은 그런 환경에 맞게 개발되고 있는가라고 질물을 한다면 대답하기가 쉽지 않다.

이러한 어려움들을 해결하기 위해서 우리는 패턴이라는 것을 사용한다. 각각의 요건과 환경에 맞게 이미 시도해본 사람들의 경험을 바탕으로 만들어진  형식들이 바로 패턴이다. 이 책에서는 우리가 클라우드 환경에서 어플리케이션을 개발하고 운영하고 배포하기 위해서 적합한 패턴들이 어떤것들이 있는지 알려준다. 이 책을 통해 알게 되었는데 패턴이 생각보다 정말 많다.

많은 패턴들을 총 6가지의 큰 주제로 묶어서 설명을 해주고 있다.

통신패턴
연결성 및 조합 패턴
데이터 관리 패턴
이벤트 주도 아키텍처 패턴
스트림 프로세싱 패턴
API 관리 및 사용 패턴

각각의 패턴 하위에 관련된 수많은 패턴들이 있는데 다음과 같은 형식으로 설명을 해주고 있다.

패턴 정의 ---> 동작방법 ---> 사용방법 ---> 고려사항 ---> 관련 패턴

동작 방법에 대한 설명은 아래와 같이 그림들을 통해서 이해를 도와주고 있다. 아무래도 패턴이 어떻게 동작되는지 이해하기 위해서는 글보다는 전체적인 그림을 보는게 더 나은데 각 패턴마다 이렇게 동작에 대한 그림들이 있어서 이해하는데 도움이 된다.

위에서도 말했듯이 각 주제별로 정말로 많은 패턴들이 있다. 그래서 읽다보면 각 패턴에 대한 내용이 헷갈릴 때도 있다. 그래서 이책에서는 각 패턴에 대한 주제 안에서도 또 묶어서 설명을 한 후에 그 내용이 끝날때마다 비교를 해준다. 간략하게 정리가 되어있어서 앞에서 봤던 내용들을 정리도 할수 있고 차이점을 한눈에 볼 수 있다. 

그리고 제일 마지막 8장에서는 "클라우드 네이티브 패턴 적용하기" 라는 주제로 "온라인 쇼핑몰" 를 설계를 할때 어떤 패턴들을 적용하는지 나와있다. 쇼핑몰에 필요한 기능들과 그 기능들을 연결하기 위해서 어떠한 아키텍처들이 필요하고 어떤 패턴들이 알수 있다. 이부분을 통해서 직접 코드로 구현을 해보면 쇼핑몰이라는 주제를 통해 다양한 패턴들을 경험할 수 있어서 좋을것 같다. 

계속해서 말하지만 정말 많은 패턴들을 다루고 있기 때문에 각각의 패턴들에 대한 상세한 내용들이나 유즈케이스를 원한다면 다시 찾아보는 수고로움이 필요하다. 하지만 이런 패턴들이 존재한다는 것을 알고 찾는것과 모르고 찾는것은 시작점부터가 다르다고 생각한다. 그래서 클라우드 네이티브 아키텍처에 관심이 있는 분들이라면 각각의 패턴을 이해하는데 도움이 될거라 생각된다. 

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

책을 읽어보기 전까지는 단어의 의미조차 알지 못했던 Developer Relations 에 대한 책을 읽게 되었다. 단어 자체가 길다보니 보통은 축약해서 DevRel(데브렐) 이라고 표현을 하는것 같다. 

처음에는 데브렐의 역할이 기업의 마케팅이나 영업과 비슷하다고 생각을 했으나 알고 보니 전혀 다른 역할이었다. 내가 책을 읽으면서 간략하게 파악한 그들의 역할은 다음과 같았다.

개발자들을 위한 문화를 만드는데 고민한다. 커뮤니티를 만들고 활성화 될수 있도록 돕는다. 하지만 이런 행동들이 기업의 홍보를 위한것이 아니어야 한다. 

마지막 문장이 정말 의미심장하다. 기업의 홍보를 위한것이 아니어야 한다. 정말 쉽지 않은 일이고 단시간이 이루어 질수 없는 일이다. 분명 꾸준한 노력과 인내, 그리고 속한 조직의 지지가 있지 않고서는 달성하기 힘든 목표이다. 

그럼에도 불구하고 이런 역할을 필요로 한다는 것은 그만큼 개발자라는 역할이 중요해졌다는 의미이다. 책 뒷쪽에 있는 국내 회사에서 데브렐 역할을 하고 있는 분들의 인터뷰를 읽으면서 정말 부러웠다. 우리 회사도 저렇게 생각을 하고 문화를 키워 나가면 좋을 텐데, 아직은 많이 부족하구나 라는 생각을 했다. 

그렇기에 이 책은 조직을 이끌어 가는 리더들이 한번쯤은 읽어봐야 한다고 생각한다. 개발자들을 위한 문화는 어떻게 만들어 가야 하는지 그리고 어떤 부분들이 필요한지 많은 도움을 받을 수 있을 것이다.

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