
요즘 핫한 리액트 프레임워크 `next.js`!!  
처음 `next.js`를 알게 된 건 next.js로 만든 멋진 웹사이트를 보고 나서부터였다. 
그이후로 점점 next.js의 이름을 많이 들었더니, 관심이 안 생길 수가 없었다 👀  
documentation을 좀 읽어보는데 쉽게 따라할 수 있는 튜토리얼이 있다고 해서 한번 따라해봤다.  
그리고 배운 것들을 정리해 보겠음 📂

## Next.js

![nextjs](https://nextjs.org/static/images/learn/foundations/next-app.png)

Next.js는 리액트 프레임워크 중 하나다. 위 사진 속에 보이듯 routing, data fetching, SSR 등을 할 수 있게 해준다.  
리액트를 쓸 때 라우팅을 하려면 `react-router-dom`을 따로 쓰고 설정을 해줘야했는데, next.js를 쓰면 얘가 알아서 해준다.  
여러모로 개발자가 리액트로 개발하는데 아주 큰 도움을 준다! (잠깐 써보고 벌써 체감했다.)

또 개발 단계의 앱을 프로덕션 단계로 만들고 싶을 때 Rust로 만들어진 Next.js 컴파일러가 프로덕션 최적화를 한다.
이 때 앱을 **컴파일**(브라우저가 이해하는 언어로 변환),
**번들**(웹 페이지에서 필요한 파일 수를 줄이기 위해 의존성 모듈이나 파일을 합치는 것),
**minify**(불필요한 코드, 여백을 줄여 파일 사이즈 줄임),
**코드 스플릿**(페이지에서 필요한 코드만 로딩해 앱의 초기 로드 시간을 줄이고자 앱 코드들을 작은 번들로 나누는 것)을 해
프로덕션 단계로 만든다. 

프로덕션 준비가 완료된 빌드 단계에서 Next.js 앱은 아래 네가지 파일을 갖게 된다. 
빌드가 완료되면 유저들이 사용할 수 있는 런타임 단계가 된다.

1. 정적 생성(SSG)된 HTML 파일들
2. 서버에서 렌더링할 JS 코드
3. 클라이언트에서 인터랙티브한 페이지를 만들 JS 코드
4. CSS 파일

## 렌더링

Next.js에서 가능한 렌더링 방법은 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), 클라이언트 사이드 렌더링(CSR)이 있다. 
이 중 SSR과 SSG는 

### Pre-rendering

![pre-rendering](https://nextjs.org/static/images/learn/data-fetching/pre-rendering.png)

Next.js는 모든 페이지를 pre-render한다. 클라이언트 쪽의 JS가 아니라 
Next.js가 모든 HTML 페이지를 미리 만들어놓는다. 성능과 SEO 결과가 더 좋아진다.
만들어진 각각의 HTML은 그 페이지에서 필요한 최소한의 JS 코드를 포함한다. 
브라우저에서 페이지가 load되면 그때 그 JS 코드가 실행되어 페이지를 더 인터랙티브하게 한다. (이 과정을 **hydration**이라고 한다.)  
`<Link/>`같은 인터랙티브 컴포넌트는 js가 로드된 후 사용가능하다.

브라우저에서 자바스크립트를 꺼두고 Next.js로 만든 페이지에 들어가보면 더 확실히 알 수 있다.  
Next.js가 우리의 웹앱을 정적 HTML로 만들어놓았다는 것을!
만약 그냥 리액트 웹앱이면 자바스크립트 없이 동작하지 않았을 것이다.  

### Pre-rendering의 2가지 방법 (정적 생성 & 서버사이드 렌더링)

Next.js에선 이 두 방법 중 뭐를 쓸지 내가 직접 고를 수 있고, 섞어서도 개발할 수 있다.
Static generation과 server-side rendering의 차이는 **언제 페이지의 HTML을 생성하느냐**다.  
(개발 모드에서는 무조건 매 요청마다 pre-render된다.)

#### Static Generation: 빌드 시에 HTML 생성

![빌드 시 HTML 생성](https://nextjs.org/static/images/learn/data-fetching/static-generation.png)

- 왠만하면 이게 좋다. 왜냐면 한번 빌드된 페이지를 쓰면 되니까 서버가 매 요청마다 페이지를 렌더링하는 것보다 훨 속도가 빠르다.

#### Server-side Rendering: 매 요청 시에 HTML 생성

![매 요청시 HTML 생성](https://nextjs.org/static/images/learn/data-fetching/server-side-rendering.png)

- 만약 자주 업데이트되는 데이터가 있거나 매 요청마다 페이지의 내용이 달라져야한다면 서버 사이드 렌더링을 쓰는게 좋다.
- 정적 생성 방식보다는 느릴지 몰라도 항상 up-to-date!

## getStaticProps로 데이터가 들어간 Static Generation하기

Next.js에선 페이지 컴포넌트를 export할 때 getStaticProps라는 비동기 함수를 같이 export할 수 있다.

### getStaticProps

- 프로덕션 시 빌드 타임에 실행됨
- 파일 시스템, API, DB 등의 외부 데이터를 fetch해와 페이지의 props로 return할 수 있다.

#### 사용법

lib 디렉토리를 만들고 `gray-matter`를 사용해서 데이터를 내보낸다.  
참고로 그냥 `await.fetch()`를 해서 API로 가져온 데이터도 사용할 수 있다.  
`getStaticProps`는 **page에서 export된 파일만 가능하다.**

```js
// lib/posts.js

import fs, { readdirSync } from 'fs'
import path from 'path'
import matter from 'gray-matter'

const postsDirectory = path.join(process.cwd(), 'posts') // current directory/posts

export function getSortedPostsData() {
    const fileNames = fs/readdirSync(postsDirectory)
    const allPostsData = fileNames.map(fileName => {
        const id = fileName.replace(/\.md&/, '') // .md 지우고 id로 설정

        const fullPath = path.join(postsDirectory, fileName)
        const fileContents = fs.readFileSync(fullPath, 'utf8') // path에 있는 파일 내용 읽어오기

        const matterResult = matter(fileContents) // post의 metadata(frontmatter)
        
        return {
            id,
            ...matterResult.data
        }
    })
    
    // 날짜별로 sort
    return allPostsData.sort(({ data: a}, {data: b}) => {
        if (a < b) {
            return 1
        } else if (a > b) {
            return -1
        } else {
            return 0
        }
    })
}
```

```js
// pages/index.js  
import { getSortedPostsData } from '../lib/posts'

export async function getStaticProps() {
  const allPostsData = getSortedPostsData()
  return {
    props: {
      allPostsData  // prop으로 모든 블로그 포스트 넘겨주기
    }
  }
}

export default function Home({ allPostsData }) {
// ...
}
```

## 짱편한 라우팅

바로 위에서 언급한 next.js의 라우팅에 대해 이야기해보겠다. Next.js에서 한 페이지는 'pages' 폴더 안에 있는 한 파일 속 리액트 컴포넌트다.  
그래서 그 파일 이름으로 라우팅이 된다.

예를 들어 `pages/posts/first-post.js` 파일이 있으면 저절로 `posts/first-post` 로 경로가 설정된다.
다른 라우팅 라이브러리가 필요하지 않아서 진짜... 너무너무너무너무너무 편하다!!!

## Link

Next.js에서 다른 컴포넌트로 이동할땐 `<a/>` 태그 대신 `<Link/>` 태그를 사용한다.  
이때 중요한 점은 **클라이언트 사이드** navigation을 한다는 것이다.

### Client-side navigation

![client side nav](https://nextjs.org/static/images/learn/navigate-between-pages/client-side.gif)

위 이미지를 보면 페이지 전환이 일어나도 노란 CSS 설정이 계속 남아있다.
브라우저가 페이지 전체를 다시 로드하지 않고, client-side에서 navigation을 하기 때문에 일어나는 현상이다.
next.js의 `<Link/>`가 아니라 기본 html tag인 `<a/>`를 쓰면 브라우저가 전체 페이지를 새로고침하기 때문에 노란 CSS가 사라질 것이다.

그 외에도, client-side navigation은 자바스크립트를 이용해 페이지를 전환하기 때문에 브라우저의 기본 navigation보다 더 빠르다.

```javascript
export default function FirstPost() {
    return (
        <>
            <h1>First Post</h1>
            <h2>
                <Link href="/">
                   <a> Back to home</a>
                </Link>
            </h2>
        </>
    )
}
```

간단히 코드를 짜보면 이런식으로 `<Link>` 안에 `<a>`를 넣으면 된다. (링크 태그만 쓰는거 아님!)

## Code splitting and prefetching

**Next.js does code splitting automatically, so each page only loads what’s necessary for that page.**

Next.js는 자동으로 코드를 분리해줘서 페이지별로 로드된다.
처음에 홈페이지가 렌더될 때 다른 코드들은 같이 로드되지 않는다.
그렇기에 한 페이지에서 에러가 나도 다른 페이지들은 작동한다.

또 Link 태그가 브라우저의 viewport 안에 나타날 경우, Next.js가 자동으로 그 목적지 페이지의 코드를 미리 가져와둔다(prefetch).  
그래서 그 페이지로 좀 더 빠르게 이동할 수 있다.

## Static asset

- public 디렉토리 아래에 저장
- ```import Image from 'next/image'``` 컴포넌트를 쓰자.

### Nextjs의 ```<Image/>``` 를 쓰면 좋은 점

- 이미지 최적화해줌. WebP 지원되는 브라우저면 저절로 이미지 resizing을 도와준다.
- 심지어 외부 이미지 링크에서 가져오더라도 최적화가 가능하다. 그저 빛 ⭐️

### on-demand 최적화

- 빌드 시가 아니라 사용자 요청이 들어올때 이미지를 최적화한다. 이미지가 많아도 빌드 성능에 영향을 끼치지 않는다.
- lazy loaded! viewport에 들어올 때 이미지를 load한다.

## Third-Party JavaScript

```js
<Script
    src="https://connect.facebook.net/en_US/sdk.js"
    strategy="lazyOnload"
    onLoad={() =>
        console.log(`script loaded correctly, window.FB has been populated`)
    }
/>
``` 
앱에 부가적인 기능(analytics, ads, widgets)을 위한 스크립트들을 추가할 땐 `next/script`를 사용하자.
`strategy` 속성으로 언제 그 script가 로드될지를 지정할 수 있다.

## CSS Styling

Next.js에는 CSS-in-JS의 한 종류인 `styled-jsx`가 빌트인 내장되어있다.
리액트 컴포넌트 안에서 CSS를 쓸 수 있고, 또 CSS 스타일의 범위가 제한된다.**(=scoped)**  
styled-components나 emotion을 써본 사람에게는 더 쉬울 것이다.

### Layout Component

Next.js에서는 CSS 설정을 할 때도 도움을 준다. `className`을 설정하면 뒤에 랜덤한 문자열(해시)을 붙여 자동적으로 고유한 클래스 이름을 만들어준다.  
CSS 이름이 겹칠 걱정은 하지 않아도 된다!

`components/layout.js`에 `components/layout.module.css`를 적용하면 된다.  
[module.css](https://nextjs.org/docs/basic-features/built-in-css-support#adding-component-level-css)는 unique한 클래스 이름을 만들어 충돌을 방지해준다.

### API 등 서버와 소통하는 함수는 루트 디렉토리에

블로그 메인에서 recent posts (최근 글 목록)을 보여주고 싶었다. 
이럴 경우, 내 블로그는 SSR이라 **최근 글 목록을 가져오는 함수**를 컴포넌트에 넣으면 안 된다. 
그래서 루트 디렉토리에 Api 폴더를 만들고 거기다가 API 역할을 해줄 함수들을 작성해주는 게 좋다.

## Next.js 튜토리얼을 따라하며 느낀 점

튜토리얼이 친절하고 너~~~무 유용한 프레임워크라 그런가 배우면서 즐거웠다. 
리액트로 프로젝트를 할 때 추가로 불러와 쓰는 라이브러리가 많았다. 
그에 따라 설정할 것도 많아서 헷갈리곤 했는데 Next.js가 내게 도움을 주니 정말 마음에 든다. 
앞으로 많은 프로젝트를 Next.js로 하게 되지 않을까?


SSR 첫걸음, 더 쉬워진 라우팅, 클라이언트사이드 네비게이션...

Next.js 튜토리얼 직접 따라해보기


지난 주에 조합논리를 배웠고 이번 주는 순차논리와 순차 논리 회로들에 대해 이야기했다.

## 조합논리

`출력 = f(입력)`

## 순차논리

`출력 = f(입력 + 저장돼있던 어떤 값)`
이 때 **입력은 현재 상태**, **저장되어있던 값은 과거 상태**를 의미한다.

## **메모리**

: 집이 늘어선 거리(street). 이 집에는 정해진 개수만큼 비트를 저장할 수 있는 방이 있다.  
이 데이터는 데이터 버스에 실어 나른다. (버스: 1개 이상의 장치가 공동으로 사용하는 회선, 회선의 집합)

## RAM (Random Access Memory)

- Random access란? **어느 위치에든 똑같은 속도로 접근하여 읽고 쓸 수 있다**  
- 메모리 배열에 저장된 **행, 열 각각의 주소를 조합해** 읽는다.
- RAM이 8기가라면 8기가 만큼의 공간이 있음. (추상적인 의미가 아님) 
램이 클 수록 공간이 그만큼 넓으니 여러 프로그램을 사용할 수 있는 것.

### SRAM, DRAM (둘 다 휘발성)

|   | SRAM | DRAM |
|---|------|------|
| 구성요소  | 트랜지스터+래치 | 커패시터+소수의 트랜지스터 |
| 속도   | 더 빠름(D램의 100배 이상)| 느리지만 구조가 간단(=> 집적도 향상 쉬움) |
| 가격  | 비쌈 | SRAM 대비 저렴 (cuz 집적도 향상이 쉬움) |
| 용도  | L2, L3 CPU | 컴퓨터 메인 메모리 |
| 데이터 휘발 | 전원 차단시 바로 데이터 지워짐 | 내부에 전류를 일시적으로 저장하는 커패시터가 있어 1주 정도는 보관 가능 |
| 특징   |  | 커패시터와 연결된 스위치가 off되더라도 전류가 새서 메모리 갱신 (재충전) 필요 |

## 블록 장치

블록 장치란 블록 단위로 IO 작업을 수행하는 장치를 말한다. 
디스크 드라이브, SSD, 플래시 메모리가 블록 장치에 속한다.

### 디스크 드라이브

우리가 아는 것처럼 동그란 디스크 판이 회전하면 디스크 헤드가 데이터를 읽는다.

- 디스크 영역을 **자화(자성을 띄도록)** 시켜서 데이터를 저장한다. (비휘발성) 
데이터 알갱이가 자성에 따라 `0` 또는 `1`을 의미하고, 비트를 전류로 변환한다.
- 속도는 **느리지만** 기록의 **밀도가 높고** 주소 공간 필요 없다.
- 블록 단위로만 입출력이 가능해 1바이트만 바꾸고 싶어도 전체 블록을 다 읽고 그 바이트를 바꾼 다음 전체 블록을 다시 써야한다.
- **비트 밀도가 안쪽이 더 높다.** 그래서 최신의 디스크는 외부에 더 많은 섹터를 넣어 낭비를 줄인다.

그러나 디스크 드라이브는 **점점 SSD(Solid State Drive)로 교체**되는 중임

### SSD

: 디스크 드라이브 모양의 패키지에 넣은 플래시 메모리

### 플래시 메모리

- `EEPROM` (전기적으로 프로그래머블, 데이터 삭제 후 재기록 가능)
- 원하는 위치를 맘대로 읽을 수 있음(LIKE RAM)
- 블록 단위로 지우고 씀
- 읽을 때는 임의 접근, 쓸 때는 블록 접근

## I/O 장치 (입출력 장치, 주변장치, peripheral)

: 키보드, 마우스 등 사용자의 입력을 받는 장치와 프린터처럼 출력을 하는 컴퓨터 주변 장치

## 과거: I/O Street과 Memory Street을 분리했다

![과거의 IO 연결](/images/os/io2.jpg)

- 이유 1. 작은 패키지에 우겨넣기엔 컴퓨터가 너무 컸음
- 이유 2. 메모리 Street에 집이 많지 않았어서 IO까지 담기엔 무리였음

## 현재: 메모리 Street의 일부를 I/O 장치에 할당

![현재의 io 연결](/images/os/io1.jpg)

- 이유: 운영체제의 **기본 데이터 처리 단위가 커져서**(32, 64비트) **메모리 거리의 주소 수가 많아짐** ⇒ 빈 집 늘어남

## 입출력 슬롯

컴퓨터에는 표준 입출력 슬롯이 있어 **일관된 방식**으로 IO 장치를 연결할 수 있다.

![io slot](https://t1.daumcdn.net/cfile/blog/0277363D51C2BBE23B)

### 입출력 장치에 메모리를 할당하는 방법 (like 서부시대의 땅 분배)

1. (메모리가?) 빈 집들 중 IO 장치에게 할당할 수 있는 영역(주소들)을 고른다.
2. 각 슬롯의 장치는 자신에게 할당된 주소를 모두 사용 가능하다.
3. 각 슬롯은 CPU가 슬롯-장치 매핑을 할 수 있는 특별 주소를 가진다.

## 입출력 장치 컨트롤러

![IO Controller의 내부 구성도](/images/os/io4.png)

- 프로세서는 이 입출력 컨트롤러의 레지스터에 비트들을 쓰거나 읽음으로써 입출력을 수행

## Memory Mapped IO (메모리 영역에 있는 IO)

![memory mapped io](/images/os/io5.png)

- 오늘날의 대부분
- 메모리, IO가 나란히, 연속된 주소 영역에 할당됨
- IO가 차지하는 만큼 메모리 용량은 감소
- CPU는 메모리, IO를 동일한 외부기기로 간주해 액세스할때 표준 데이터 전송 명령 (**read, write)** 사용
    - Read: IO 장치에서 읽어 오는 것
    - Write: IO 장치를 제어 / 출력
- 소프트웨어적으로도 메모리 액세스 & 데이터 입출력이 동일한 것으로 간주되어 load나 store 명령으로 수행 가능

### 장점

포트 입출력 구현할 때 메모리, io 차이 없어서 CPU 로직이 **간단함** ⇒ 더 저렴하고 빠르고 쉬운 CPU ⇒ **RISC가** 추구하는 바(**‘하드웨어와 기계어 명령어의 단순화 원칙’)**와 일치!

### 단점

주소와 데이터 버스를 더 많이 사용

## IO Mapped IO (IO 영역에 있는 IO)

![io mapped io](/images/os/io6.png)

- Isolated IO라고도 한다. (분리된 IO)
- 메모리, IO가 별개의 주소 영역에 할당됨
- CPU는 이 둘을 구분해야하므로 read/write 외에도 IO에 접근하는 신호(in/out)가 필요함
- 메모리 액세스: load, store
- io 입출력: input, output 명령에 의해 수행됨

### 장점

어드레싱 능력이 제한된 CPU 사용할 때 유리 (메모리 용으로 주소영역 전체를 사용 가능)

### 단점

Memory mapped io 방식 대비 하드웨어 구조가 복잡

## 명령어 비교

![memory-mapped io 의 예시](/images/os/io7.png)

- 데이터 레지스터 주소: 412번지
- 상태/제어 레지스터 주소: 413번지
- 상태 레지스터 최하위비트 = RDY 비트로 사용 (3번째 줄)
- 제어 레지스터 최상위비트 = 프린트 동작 start 비트로 사용 (2번째 줄에서 clear, LOAD 80H에서 load)

---

![io-mapped io의 예시](/images/os/io3.png)

이미지 출처: [https://itstory07.tistory.com/881](https://itstory07.tistory.com/881)


메모리를 알아보고 입출력 장치에 메모리 할당하는 방법을 알아본다.

순차논리와 RAM, 디스크 드라이브와 SSD의 특징


## Deadlock (교착 상태)

- 프로세스들이 서로가 가진 자원을 기다리며 block된 상태

## 자원

- 하드웨어, 소프트웨어 등을 포함 (io device, cpu cycle, memory space, semaphore(공유데이터도 자원임) 등)

### 프로세스가 자원을 사용하는 절차

request (요청) - allocate (할당받음, 획득) - use (사용) - release (배출)

## 데드락 발생 조건 4개

1. mutual exclusion 상호배제: 매순간 **하나의 프로세스만이** 자원을 독점적으로 사용
2. no preemption 비선점: 자원을 **빼앗기지 않음**
3. hold and wait 보유대기: 내가 가진 자원을 **가지고 있는 채로** 다른 자원을 대기
4. circular wait 순환대기: 자원을 기다리는 프로세스간에 **사이클이 형성됨**

<img width="300" alt="circular wait"
     src="https://user-images.githubusercontent.com/50111853/156170865-8b21e26d-0560-4dcf-b1dc-9480802a9d23.png"/>

## 자원 할당 그래프로 데드락이 걸렸는지 알아보자

<img width="597" alt="자원할당그래프"
     src="https://user-images.githubusercontent.com/50111853/156171575-f644ca2f-ead9-493a-81c9-4b7d5a151dc6.png"/>

Process -> Resource: 프로세스가 자원 요청 (!= 획득)
Resource -> Process: 프로세스에게 자원 할당
사각형 안에 동그라미: 자원의 갯수

<img width="348" alt="데드락 상태인 자원할당그래프"
     src="https://user-images.githubusercontent.com/50111853/156172148-fb037163-e934-4c2d-aa7e-23fce691bc04.png"/>

위 그림을 보면 싸이클이 있음. 이때 만약 **동그라미(자원의 인스턴스)가 한개면 데드락**임.
**이땐 R2의 자원이 2개지만 싸이클도 2개라 데드락임.**

<img width="335" alt="사이클 1개인 자원할당그래프"
     src="https://user-images.githubusercontent.com/50111853/156172324-e304cf8d-192c-40c2-9230-91954b4de48b.png"/>

이 그림은 싸이클이 1개, 자원이 2개라 데드락이 아님.

## 데드락 처리 방법

1. 데드락 예방: 자원 할당 시 데드락의 4조건 중 어느 하나가 만족되지 않도록 하는 방법
2. 데드락 회피: 자원 요청에 관련된 추가 정보를 모아 데드락의 가능성이 없는 경우에만 자원을 할당 / 시스템 상태가 원래 상태로 돌아올 수 있을 때만 자원 할당
3. 데드락 탐지 및 recovery: 데드락 발생은 허용하되 탐지 루틴을 두어 탐지 시 recover
4. 데드락 무시: 데드락을 시스템이 책임 안 짐.

유닉스를 포함한 현대의 운영체제는 **대부분 데드락을 Ignorance(무시)** 함. 이유는 **데드락은 빈번하게 일어나지 않기 때문에 괜히 방지했다가 오버헤드 일어날까봐.** 사용자가 알아서 프로세스를 죽이거나 대처하도록 함.

### Deadlock prevention

<img width="552" alt="Deadlock prevention"
     src="https://user-images.githubusercontent.com/50111853/156172754-68636cf3-2b3b-4a3e-9b71-1dcf2182226f.png"/>

- hold and wait: 프로세스 시작할 때 필요한 모든 자원을 받아놓고 시작함. 자원을 **비효율적으로 사용함.**
- no preemption: cpu, memory는 상태를 쉽게 save, restore할 수 있어서 빼앗음으로써 자원을 사용 가능.
- circular wait: 자원에 순서를 정해 '1번 자원을 획득해야지만 2번을 획득할 수 있다'라는 식으로 제한.

### Deadlock avoidance

<img width="539" alt="데드락 회피"
     src="https://user-images.githubusercontent.com/50111853/156175031-4050c5d0-58f8-4960-ab01-ce35e68eee21.png"/>

- 가장 단순한 데드락 회피 방법: 프로세스가 시작될때 그 프로세스가 쓸 **모든 자원의 수(최대사용량)를 선언하고 시작** 함으로써 데드락 회피
- 시스템이 safe state에 있으면 데드락 X
- 시스템이 unsafe state에 있으면 데드락 가능성 있음.
- 데드락 회피 방식은 2개의 회피 알고리즘을 통해 시스템이 **unsafe state** 에 들어가지 않는 것을 보장한다.

1. Resource Allocation Graph 알고리즘: 자원당 1인스턴스인 경우
2. Banker's 알고리즘: 자원당 여러 인스턴스인 경우

#### 자원 할당 그래프 알고리즘 (자원당 인스턴스가 1개인 경우)

<img width="558" alt="스크린샷 2022-03-01 오후 10 14 23"
     src="https://user-images.githubusercontent.com/50111853/156175465-75f2fa10-6e57-4a81-a94a-3ca015612abd.png"/>

- 위 그림에서 **점선: 이 프로세스가 이 자원을 한번이라도 요청할 가능성**이 있다.
- 데드락 회피 방식은 최악의 상황을 가정하고, 안전한 경우에만 자원을 할당함.

#### Banker's algorithm (자원당 인스턴스가 여러개인 경우)

<img width="582" alt="스크린샷 2022-03-01 오후 10 24 45"
     src="https://user-images.githubusercontent.com/50111853/156177114-66e22ae5-d894-4e1f-850e-f0ba39da5b85.png"/>

#### 상황 : 5개의 프로세스, 3개의 자원타입(각각 10개,5개,7개)

- 자원 B는 프로세스 A를 최대 9개 요청한다. Max(최대 요청할 양) - Allocation(할당된 양) = Need(추가 요청할 수 있는 양)
- 이 때 P1처럼 **Available로 Need를 충족할 수 있다면 OK**
- 다만 P0처럼 Available(가용 자원)의 수로 Need를 충족할 수 없다면 자원을 빌려줄 수 없다. (데드락 우려)

### Deadlock Detection & Recovery

<img width="537" alt="wait for graph"
     src="https://user-images.githubusercontent.com/50111853/156322003-126f093c-e635-4733-9952-326366b0df1f.png"/>

- 프로세스가 요청하면 자원을 일단 준다.
- 위에서 배운 자원할당그래프와 뱅커스 알고리즘, wait-for graph을 사용해 detection

#### Recovery

1. 프로세스 종료: 데드락 걸린 프로세스 다 죽임 or 데드락 사이클이 사라질때까지 하나씩 죽임
2. 프로세스 뺏기: 데드락 걸린 프로세스들 중 비용이 가장 작은 victim을 골라 safe state로 롤백한 후 해당 프로세스를 재시작.

- 프로세스 뺏기 시 starvation 우려: 동일한 프로세스가 계속해서 victim으로 선정되는 경우가 있음. 이를 방지하고자 cost factor에 rollback 횟수도 같이 고려해야함

### Deadlock Ignorance

- 만약 시스템에 데드락이 발생한 경우 사용자가 직접 프로세스르 죽여야함


프로세스들이 서로의 자원을 무한대로 기다린다면?

데드락, 발생 조건과 처리 방법 4가지 (예방, 회피, 탐지, 무시)


`position:fixed` 인 nav 바의 3단 햄버거(한자 '석 삼')를 클릭하면 블로그 카테고리 리스트가 뜨되, 스크롤 시 그 아래로 지나가지 않게 하기

## 방법

JS의 ```toggle()```을 사용하면 된다.

## Toggle

![toggle](/images/blog/2203/toggle.png)

MDN 문서를 읽어보면 toggle()은 DOMTokenList(HTML Element의 classList 등)의 메소드다. 
그 리스트에 파라미터(토큰)가 있는지 확인하고, 없으면 추가한 뒤 true를 리턴한다.

예를 들어 ```HTMLElement.classList.toggle('show')``` 을 하면 HTMLElement 의 클래스 목록에 'show'가 있는지를 확인하고, 있으면 true, 없으면 추가하고 true를 리턴한다.

## HTML

```html
<div id="threeBarNav" class="container" hidden onclick="clickNav(this)">
    <div class="bar1"></div>
    <div class="bar2"></div>
    <div class="bar3"></div>
</div>
```

## JS

```js
function clickNav(x) {
    x.classList.toggle("open");
    const nav = x.parentNode
    nav.classList.toggle("open")
}
```

그래서 햄버거 바를 만들때도 js onclick에 toggle()를 넣어서 `classList.toggle` 하게 하면 된다.  
그리고 open이면 그에 맞는 css를 적용해주면 끝이다!


JS toggle로 고정된 네비게이션 햄버거 바 만들기


블로그의 디자인을 대폭 수정했다. 수정하기 전엔 이렇게 생겼었다.

![blog 수정전 ](/images/blog/2202/toomanywords.gif)

디자인에 뭔가 부족한 게 있는 것같고, 애매해서 생각해보니 블로그 대문(첫 화면)에 글씨가 너무 많았다.   
문제는 최근 작성한 글 목록 부분이었다.  

![recent posts](/images/blog/2202/rp.png)

어떻게 수정하지 고민을 많이 했고 awwward 수상작들과 여러 사이트들을 보면서 영감을 (ㅋㅋㅋ) 느끼려고 애썼다. 

그러고보니 내가 원하는 페이지는 노션으로 만든 듯한 깔끔한 페이지였다. 그래서 뚝딱뚝딱 수정을 해보았고.. 바뀐 모습은 이렇다.

![메인 윗부분](/images/blog/2202/redes5.PNG)

## 디자인하며 중점적으로 생각한 부분

### 데스크탑과 모바일로 접속했을 때 느낌이 너무 다르지 않게 하기

나는 웹에서 좌우 여백을 많이 주는 페이지를 좋아한다. 그렇게 하려면 웹-앱의 생김새를 비슷하게 해야했다. 둘의 간격이 커지면 미디어쿼리로 처리하는 부분, 신경써야하는 부분이 늘어나 개발할 때 힘들다.

이러려면 웹에서 봤을 때도 좌우 패딩을 안 주고, 세로로 봤을 때 좌우 여백이 없이 일자로 깔끔하게 내려가는 것이 중요했다.
또 모바일에서 볼 때 폰트가 너무 작으면 이 느낌이 덜 했다. 그래서 max-width로 데스크탑에서 봤을 때에도 모바일과 봤을때 차이가 없도록 하고, 앱에서는 거슬릴 지 않는 정도의 좌우 마진만 주었다.

### 간결하고 깔끔하게

그래서 메인 배경 색을 하얀색으로 잡았다. 원래는 메인의 ```Recent Posts``` 섹션에서 카테고리 별 최근글을 보여주었다. 근데 그렇게 하다보니 카테고리명도 나와야하고 또 내가 한동안 쓰지 않은 카테고리의 글이 나오길래 과감하게 카테고리를 지우고 모든 카테고리의 최근글을 표시하도록 했다.

블로그를 직접 디자인해 만들면서 최근 글 영역의 디자인을 가장 많이 고민했다. 카드 형식으로 할지, 글의 도입부를 살짝 보여줄지, 가벼운 요약(description)을 보여줄지 등.. 근데 첫 화면에 글이 너무 많으면 처음 내 블로그에 들어온 사람이 부담을 느낄 것 같아 제목만 띄우기로 했다.

### 테마는 거미 / 남색

사용자가 보게 될 첫 화면에 책 저지대의 구절을 넣고 싶었다. 빼고 기술적인 내용을 적을까 생각도 했지만, '지금까지는' 내가 추구하는 삶을 잘 보여주는 글귀라 남겨두었다.


저는 디자인이 너무너무 어렵습니다

내 블로그 겸 포트폴리오를 직접 디자인하며 주의한 것, 알게된 것


세마포어: 프로그래머 관점에서 프로세스를 잘 동기화하는 방법을 보여주는 추상적 접근법.  
고전적인 프로세스 동기화 관련 문제에 대해 알아본다.

## Concurrency Control (병행 제어)

- 프로세스 동기화와 같은 얘기임. 병행 작업할때 잘 제어 하자^^

## Bounded-Buffer Problem (Producer-consumer Problem)

- Bounded Buffer = 유한하다.

<img width="564" alt="스크린샷 2022-02-25 오후 2 06 16"
     src="https://user-images.githubusercontent.com/50111853/155657222-846c743e-a75c-4253-bbd9-e1f148998db1.png"/>

- 주황색이 데이터가 들어있는 버퍼들 / 회색이 비어있는 버퍼들. 생산자가 버퍼에 데이터를 집어넣는다.
- producer, consumer 프로세스로 총 2 종류의 프로세스가 있음. 이때 프로듀서 프로세스 여러개, 컨수머 프로세스 여러개 가능
- 생산자: Empty buffer에 데이터를 만들어 집어넣는 역할
- 소비자: Full buffer에 데이터를 꺼내감

### 동기화 관련해 일어날 수 있는 문제

1. 공유버퍼이므로 생산자 둘이 한 버퍼에 데이터를 넣으려고 할 수도 있음
2. 소비자 둘이 동시에 데이터를 꺼내가려할 수도 있음
-> 데이터를 넣고 꺼내기 전에 Lock을 걸음으로써 해결가능

### 이 문제에서 semaphore 용도

1. shared data의 mutual exclusion을 위해 binary semaphore 필요
2. 가용 자원(empty buffer)의 개수를 센다 (counting semaphore)

### Bounded-buffer 코드로 해결하기

![바운디드 버퍼 문제 코드](https://user-images.githubusercontent.com/50111853/155870391-2ba9b914-bc80-4b99-b532-2db360b4b13b.png)

- mutex: 락을 걸기 위한 변수 (세마포어)
- P(mutex), V(mutex)가 락을 걸고 푸는 연산임.

## Readers-Writers Problem

![reader-writer problem](https://user-images.githubusercontent.com/50111853/155870504-e706a0ac-4497-4804-b246-db9e4025e43b.png)

- 공유 데이터인 DB의 데이터를 읽고 쓸 때 문제
- **write는 동시에 하면 안 되지만 read는 동시에 가능**

![읽고 쓸 때 문제 해결](https://user-images.githubusercontent.com/50111853/155870566-2f8f3018-ff33-4ecd-91d1-74527f4a74ff.png)

- reader도 writer처럼 배타적으로 해도 되지만 비효율적임
- Reader에선 readcount++함으로서 읽고 있는 자원의 수를 카운트할 수 있음.
- 다만 readcount도 공유 변수라 이거 값 바꿀 때 락 걸고 변경해야함!!!
- 내가 마지막으로 읽고 나가는 프로세스면(if readcount==0) DB에 걸어둔 락을 풀어야함
- reader가 계속 올 경우 writer starvation 될 수도.

## Dining-Philosophers 문제

<img width="412" alt="식사하는 철학자 문제"
     src="https://user-images.githubusercontent.com/50111853/155872584-47cf73f4-e7a9-423c-995d-6c34f20c7bc0.png"/>

- 철학자들은 밥을 먹거나 생각하거나 둘 중에 하나를 한다.
- 젓가락이 각각 공유자원이고, initially all values are 1 (하나씩 있다)
- 위 코드는 데드락 가능성이 있다.(=모든 철학자가 동시에 젓가락을 든 경우)

### 위 문제 해결 방안 3가지

1. 4명의 철학자만 테이블에 동시에 앉도록 한다
2. 젓가락을 두개 잡을 수 있을 때에만 젓가락을 집게 한다
3. 비대칭 (짝수-왼쪽 젓가락, 홀수-오른쪽 젓가락부터 잡을 수 있도록 제한)

<img width="570" alt="식사하는 철학자 문제"
     src="https://user-images.githubusercontent.com/50111853/155874415-c1390407-f806-4d66-8b22-a7c6939c9515.png"/>

#### pickup(int i): 젓가락을 잡는 함수

#### test(): 젓가락 들 수 있는 환경인지 확인하는 함수

- 왼쪽, 오른쪽 철학자가 밥 먹고 있으면 if문 만족하지 않아 락 풀지 못함

## 세마포어의 문제점과 그를 보완해주는 모니터

<img width="705" alt="세마포어의 문제점"
     src="https://user-images.githubusercontent.com/50111853/155872690-5a04d48a-ea2f-4efa-ae5d-04003b0af62d.png"/>

- 세마포어는 동기화하는 법을 알려주고 프로그래머가 제어할 수 있도록 함.
- 모니터: 프로그래밍 언어 차원에서 공유 자원에 접근하는 일을 모니터가 직접 하게 해 프로그래머의 부담을 줄여줌.
- 세마포어는 정확도를 검증하기 어려움/ 프로그래머의 실수가 영향을 끼칠 수 있다. (= 안정성 낮음)
- monitor: 자바의 인스턴스 각각이 lock을 가진다. 자바 내부적으로 모니터를 가지고 있어 synchronized를 쓰면 각 인스턴스의 모니터를 사용할 수 있다.

<img width="501" alt="모니터"
     src="https://user-images.githubusercontent.com/50111853/155874579-7c3a92a3-f2ce-4af4-8c28-ef16f9b8d7de.png"/>

- 공유데이터에 접근하려면 내부의 프로시저인 모니터를 통해야만함
- 공유 데이터에 접근하는 프로시저를 함수로 구현해두었음
- 모니터 내부 프로시저는 동시에 여러개가 실행이 불가능하도록 모니터가 막고 있음 => **락을 걸 (P,V연산 할) 필요 없음**
- 모니터 안에선 한 프로세스만 활성화된다. 액티브 프로세스가 1개만 있도록 모니터 자체에서 제어한다!!

<img width="509" alt="condition variable"
     src="https://user-images.githubusercontent.com/50111853/155874631-c2f1adf3-33ea-41d9-a063-304b4d983c26.png"/>

### condition variable

<img width="500" alt="바운디드 버퍼 문제와 조건 변수"
     src="https://user-images.githubusercontent.com/50111853/155874643-18666c98-a0e3-481a-a93c-e032686834d6.png"/>

- 특정 조건을 만족하지 않은 프로세스를 잠들게 하는데 그 때 그 조건: 컨디션 var
- 위 bonded buffer 문제를 condition var로 해결하자면 공유버퍼가 모니터 안에 있음
- 그래서 생산자든 소비자든 모니터 안에서 활성화되므로 락 걸 필요 X
- 만약 다른 놈이 있을 경우 **빈 버퍼를 기다리는 큐(생산자) 또는 내용이 들어있는 버퍼를 기다리는 큐(소비자)**에 줄을 서고 producer->produce, consumer-> consume 함수 앞에서 기다리며 잠든다.

x.wait(): 프로세스 재워라
x.signal(): 깨워라

## 느낀 점

지난 차시에 내가 binary semaphore = mutex라고 했었다. 바이너리 세마포는 값이 0과 1 중 하나만 가능하기 때문에 '사용 가능한 자원이 있다 또는 없다'를 나타낸다. 뮤텍스 락과 유사하게 상호 배제의 기능을 가진다. 몇몇 시스템에선 아예 뮤텍스 락 없이 이진 세마포가 대신 상호 배제를 보장한다. 이 둘의 차이는 바로 락을 해제할 수 있는 프로세스이다. 뮤텍스의 경우 락을 건 프로세스 자신만이 락을 해제할 수 있는 반면 이진 세마포어의 경우 다른 프로세스가 락을 해제할 수 있다. 누군가에게 세마포어를 설명할 때, '여러 프로세스가 동시에 한 자원에 접근하는 걸 막고자 락을 걸 때, 프로세스가 사용 가능한 자원의 토탈 개수를 나타내는 변수'라고 설명하면 되는 걸까?!

## 복습 문제

1. bounded-buffer problem에서 소비자 프로세스가 데이터를 꺼내갈 때 데이터를 꺼낼 Full 버퍼에만 락을 건다. (O,X)
정답: X, 공유 버퍼 전체에 락을 건다.

2. dining philosophers 문제에서 데드락이 발생하는 경우는?
정답: 모든 철학자가 동시에 젓가락을 잡으려고 하는 경우

3. monitor에서 프로세스가 wait()할 때, 생산자 프로세스는 (꽉 찬/빈) 버퍼를 기다리는 큐에 줄을 서고 소비자 프로세스는 (꽉 찬/빈) 버퍼를 기다리는 큐에 줄을 선다.
정답: 빈, 꽉 찬


프로세스 동기화 관련 문제를 풀어보자


## 데이터의 접근

Storage Box: Memory 주소 공간  
Execution Box: CPU 프로세스

![컴퓨터 시스템 내 데이터의 접근](https://user-images.githubusercontent.com/50111853/154946794-c1e3a6c1-358d-4b1b-9432-3283ff4300d1.png)

- `저장소(스토리지) <-> 연산(실행)하는 곳` / 어디서든 컴퓨터 시스템에서 이런 경로를 거침
- 데이터가 왔다갔다하고 **여러 execution box가 한 스토리지를 공유하기도** 함. 이때 동기화는 어떻게?

![race condition](https://user-images.githubusercontent.com/50111853/154947007-68147f7c-589d-48d1-a10e-e50a6e4aa0eb.png)

## race condition

- 달리기 레이스처럼 경쟁상태/ 다른 execution box에서 하나의 데이터를 동시에 접근하는 상황
- 공유메모리를 사용하는 프로세스들간 / 커널 내부 데이터를 접근하는 루틴들 간 (e.g. 커널모드 수행 중에 인터럽트로 커널모드의 다른 루틴 수행)

### 운영체제에서 레이스 컨디션(동시접근)이 발생하는 순간

1. 커널모드 실행중인데 인터럽트가 발생해서 인터럽트 처리루틴 수행될때

- 둘 다 커널 코드라 커널 주소 공간을 공유

2. 프로그램이 실행될때 유저모드였다가 커널모드였다가 한다.

- 커널모드에 있는 프로그램은 CPU를 빼앗는지 않는다.
- time quantum system은 real system이 아니라 좀 늦게 뺏어도 상관없음.

### Critical Section (임계 구역)

- **다수의 프로세스가 공유 데이터를 동시에** 사용하기 원하는 경우, 각 프로세스의 code segment에는 공유 데이터에 접근하는 코드인 critical section이 존재.
- 한 프로세스가 이미 **critical section**에 있으면 다른 모든 프로세스는 그 안에 들어갈 수 없음.

### critical section 를 소프트웨어 적에서 해결하기 위한 알고리즘

```c
do {
  entry section
  critical section
  exit section
  remainder section
} while(1);
```

### 위 알고리즘의 충족 조건

1. Mutual exclusion(상호 배제) : 한 놈이 이미 안에 있으면 다른 애들은 못 들어감
2. Progress: 아무도 critical section에 없는데 들어가고자하는 프로세스가 있으면 들어가게 해줘야함
3. Bounded waiting(유한 대기): 프로세스가 들어가려고 요청한 후로 언젠간 들어가야한다.

## 알고리즘 1

![고급언어로 짠 알고리즘](https://user-images.githubusercontent.com/50111853/154952318-6d2ac8c4-9604-4719-8b5d-797cd5dda2d0.png)

- 본인의 차례가 아닌 동안 while 돌다가 상대가 critical section에서 나올 때 (=자기 차례가 되면) turn이 1이 됨
- 이 경우 본인이 크리티컬 섹션에 들어갔다가 나와야 상대 차례고 vice versa
- --> p1은 크리티컬 섹션에 여러번, P1는 한번만 들어가고 싶으면 어떡함?
- -> **progress를 잘 충족하지 못한** 알고리즘임.

## 알고리즘 2

![스크린샷 2022-02-21 오후 9 09 35](https://user-images.githubusercontent.com/50111853/154952631-2ead4d13-0160-45bb-955d-6ac696055f77.png)

- 내가 크리티컬 섹션 들어갈 때 플래그를 1로 바꿈.
- 문제: 둘다 깃발만 들고 끊임없이 양보할 수도 있음.

## 알고리즘 3 (피터슨의 알고리즘)

![스크린샷 2022-02-21 오후 9 12 25](https://user-images.githubusercontent.com/50111853/154953064-5932358f-95d3-4cf6-ac52-ac2fce97a769.png)

- 둘다 들어가고싶을때만 니턴 내턴을 따지고, 한 프로세스만 관심 있으면 걔가 들어가는 식
- 문제: busy waiting(=spin lock): 계속 while 문을 돌면서 / CPU와 메모리를 쓰면서 대기함.

하지만 **하드웨어적으로 test&modify를 atomic 수행**하면 간단히 해결 가능
![test and set을 통한 상호 배제](https://user-images.githubusercontent.com/50111853/154954226-8547f53d-fed3-4188-b0f9-67b62b463468.png)

## 세마포어(Semaphores)

- 프로그래머 입장에선 추상적으로 락을 걸고 풀고, 공유자원의 수를 셀 수 있으면 편하다. -> 그래서 나온 것이 세마포어!
- Semaphore S: 정수 값을 갖는 변수 / 앞의 방식들을 추상화
- S = 자원의 개수 (5면 자원이 5개 있는거)
- 추상 자료형(논리적 자료형): object, operation
- 공유 자원을 획득, 반납할때 이 처리를 담당

![세마포어](https://user-images.githubusercontent.com/50111853/154954534-b1138b44-d7c4-4e23-bcce-d4198e4c0d84.png)

**p 연산: 공유 데이터를 획득하는 과정** p연산해서 자원 가져가면 S가 1 줄어듦
**v 연산: 반납하는 과정**

### P(S): 락을 거는 과정

- while 돌다가 S가 양수가 되면(=누군가 자원을 내어놓으면) S의 값을 감소시키며(S--) 자원을 냉큼 획득.
- 계속 돌면 busy waiting과 다를 바 없다

### V(S): 자원 반납

P, V 두 연산은 atomic 연산을 통해서만 접근 가능

## Critical Section of n Processes

![p, v 연산이 있는 임계구역 알고리즘](https://user-images.githubusercontent.com/50111853/155309323-a8a0dee5-7ae2-437c-839c-d4deaa05625c.png)

### busy-wait 방식

- 프로그래머는 세마포어 지원이 되면 P, S 연산만 구현하면 된다. (추상적으로 지원)
- Sleep Lock: Block and wake up 방식 (락 없는 프로세스는 CPU를 쓰는게 아니라 아예 blocked 상태다)

![block/ wakeup implementation](https://user-images.githubusercontent.com/50111853/155310277-c83b8c1e-1f51-4a75-b95c-8f8de3ebc806.png)

L: 프로세스를 담고 있는 리스트

![스크린샷 2022-02-23 오후 8 25 11](https://user-images.githubusercontent.com/50111853/155310450-0925d238-74dd-40ce-ab1d-e30d50911e27.png)

#### P연산

- if문 안으로 못 들어가면(= 남은 자원이 없으면) S.L 리스트에 프로세스를 넣고 block 해둔다.
- 그 후 V연산을 통해 **자원이 반납되면** 리스트 중 한 프로세스를 깨워서 변수값 1 빼고 시작.

#### V연산

- 여기서 S는 자원의 개수를 세는거랑은 좀 다름. 음수면 누가 자원을 기다리고 있다. 양수면 자원을 쓰고 있다. busy-wait의 경우랑 좀 다르다.
- 자원을 내놨는데도 S의 값이 0이라는건 P연산에서 누가 -를 했다는 것
- V연산에는 자고 있는 걸 깨워주는 wakeup 함수를 포함하고 있음.

## Busy wait vs. Block/wakeup

- 보통은 block/wakeup이 더 효율적 but 프로세스의 상태를 block/wake할 때도 오버헤드 든다.
- critical section의 길이가 긴 경우 block / wakeup이 적당
- critical section의 길이가 매우 짧은 경우 busy-wait이 나을 수도 있음

## 2 Types of Semaphores

### Counting semaphore

- 세마포어 변수 값(자원의 개수)이 1 이상으로 갈 수 있을 때
- 여분의 자원 개수를 셀 때

### Binary semaphore

- 0 또는 1값만 가질 수 있는 semaphore

#### 데드락

: 둘 이상의 프로세스가 서로 상대방이 충족할 수 있는 이벤트를 무한히 기다리는 현상
![데드락](https://user-images.githubusercontent.com/50111853/155311534-bf48d4b9-dab6-4039-8db0-d9048fe4a556.png)

해결법: 자원 획득 순서를 똑같이 맞추면 됨. P0, P1 부분을 이렇게 수정하면 된다!

![데드락 해결법](https://user-images.githubusercontent.com/50111853/155312017-70fa1eff-98fe-46a2-b2d9-9f7e6e7d6127.png)


레이스 컨디션, 임계 구역, 세마포어

프로세스 동기화 알고리즘


미디엄의 ['how to be a 10x engineer'](https://medium.com/@_michaellin/how-to-be-a-10x-engineer-fdac2a5a1bd5)라는 글을 짧게 요약하고 내 생각을 적어본다. 

*(글에서 시니어 개발자가 10배 더 나은 개발자고 주니어 개발자는 평범한 개발자라는 느낌을 살짝 주지만, 
저자가 의도한 'junior'는 오로지 연차만을 말하는게 아닌 것 같습니다. 'junior developer'라는 단어는 '평범한 개발자'로 의역을 했습니다.)*

## 최고의 개발자?
'최고의 개발자'란 보통의 엔지니어보다 약 10배 나은 사람을 말한다.  
그들은 더 느린 속도로, 더 적은 양의 일을 할지도 모른다. 어쩌면 **코드를 치는 것보다 삭제하는데 더 많은** 시간을 쓸지도!  

### 최고의 개발자 vs. 평범한 개발자
는 바로 **소프트 스킬(non-technical skills)** 이다.  
They use the right tools, ask the right questions, and know how to prioritize.  
**그들은 적시적소에 맞는 툴을 쓰고 적절한 질문을 하며 우선순위를 매길 줄 안다.**

### 뛰어난 개발자는 적절한 도구를 찾아낸다.
“내가 8시간 안에 나무를 베어야한다면 내 도끼날을 가는데 7시간을 쓰겠다.” / 링컨

평범한 개발자는 무딘 도끼로 8시간 동안 나무를 벨지도 모른다. 뛰어난 개발자는 한 시간만에 잘 드는 전기톱을 고를 것이다. 그리고 5분 후 나무를 다 벨 것이다.  
평범한 개발자들이 자주 하는 실수는 무작정 코드부터 친다는 것이다. 그들은 자기가 아는 기술 하나로 모든 상황을 처리하려한다.

저자가 한 개발자에게 개인 웹사이트를 만들어보라고 했을 때 그는 그렇게 말했다.
"학교에서 리액트 앱 만드는 법을 배웠어서 그걸로 기초를 만들었어. 근데 이미지랑 CSS를 제대로 배치하는게 어려웠고, 
나는 배포하는 법도 몰랐어. 그래서 AWS에서 커스텀 배포를 하려고 했는데 콘솔 쓰는게 또 좀 헷갈리더라. micro 인스턴스는 뭐고 large 인스턴스는 또 뭐야?"

이때 이 개발자가 놓친 것은 이런 게 있다.  
- 요구사항 정의: 검색엔진 최적화, 댓글달기, 템플릿 등에 대한 이야기가 없음
- 대안: 그는 리액트와 AWS만 알았고 그것밖에 생각하지 못했음.

### 뛰어난 개발자는 도움을 요청한다.
몇몇은 뛰어난 개발자가 고독한 천재라는 오해를 하곤 한다. 문제를 안고 속으로 끙끙대면 해결책이 나타날 거라고 생각한다. 

팀 동료에게 질문하면 5분만에 해결될 문제를, 코드가 사골국이 될 정도로 고민하는 이들이 많다. 
그러나 **도움을 요청할 줄 아는 적은 경력의 엔지니어가 절대 도움을 요청하지 않는 능력있는 엔지니어보다 낫다.** 
도움을 요청할 땐 문제 해결에 도움이 되는 추가 맥락을 설명해주면 좋다. 예를 들어 '코드를 왜 이런 구조로 짰는지', '어디서 불러오는 API인지', '배포는 어떻게 이루어지는지' 등이 있다.

### 뛰어난 개발자는 비즈니스 가치를 이해한다.
뛰어난 개발자는 일이 일종의 투자라는 것을 안다. 그리고 그 투자로 얻는 수익은 그들이 공들인 시간보다 더 큰 가치를 가져야한다. 
기회비용을 이해하고, 구현할 수 있는 기능을 전부 구현하는게 아니라 가장 효율적이고 효과적인 기능을 추려낸다.

## 결론은 소프트 스킬이다.

**"유능하지만 재수 없는 놈(jerk)을 그냥 냅두지 마세요. 팀워크는 너무나 중요합니다."** / Netflix CEO

이외에도 결국 최강의 개발자를 결정하는 것은 바로 소프트 스킬이다. 
개발을 잘 하는 것보다 재수 없는 놈(jerk)이 되지 않는게 더 쉽다. 쓸데 없는 자존심때문에 우리의 노력이 물거품이 되지 않도록 하자. 

엔지니어는 무엇보다도 가치를 우선적으로 전달해야한다.


## 느낀 점

첫번째로 저자가 언급한 '적절한 도구 찾기'는 내가 최근 들어 가장 절실히 느끼고 있는 것이었다.  
개인 블로그를 만들면서 지킬로 했다가 리액트로 했다가 다시 지킬로 돌아왔다가... 배포를 AWS로 할까 했다가 다시 깃허브 페이지로 돌아오고... 
적절한 기술을 찾아보고 선택해서 개발을 시작하는게 무작정 시작하는 것보다 더 시간을 절약할 수 있었을 텐데 말이다. 
이제 슬슬 삽질을 줄이려고 노력해야겠다. 

그 방법은 더 많이 찾아보는 것과 기술, 배경 지식을 더 깊게 이해하는 것. 
구독하고 있는 위클리 뉴스레터들을 대충 훑을 게 아니라 흥미로운 게 있으면 들어가서 공식문서도 좀 자세히 볼 것.

또 내 블로그에도 개선하고 추가해야할 기능이 많은데, 이것들도 좀 리스트업을 해봐야겠다.
내 시간과 에너지의 기회비용을 생각하며 꼭 필요한 기능을 추가해나가자.


미디엄의 한 글을 읽고 밑줄 치고 싶었던 문장들을 적어본다.

'최고의 개발자가 되는 법'을 읽고 


## CPU Scheduling

- CPU를 어떤 프로세스에게 줄 지 결정
- CPU Job이 io bound와 cpu bound 잡이 섞여있기 때문에 필요함!
- 특히 사용자와 인터랙션 하는 IO Bound Job이 cpu 필요할 때 빨리빨리 가져야 사용자가 불편하지 않음.

## CPU Scheduling이 필요한 경우

1. running -> blocked ('나 cpu 필요없어...' io 요청하는 시스템 콜)
2. running -> ready (할당된 시간 다씀. 타이머 인터럽트)
3. blocked -> ready (io 완료 후 인터럽트. 얘한테 바로 cpu 가는거 아님)
4. terminate (프로세스가 종료됐을 때)

1,4는 자진 반납(nonpre-emtive) / 2,3은 preemtive(강제로 빼앗음)

## CPU scheduler (독립적X, 운영체제 안의 CPU 스케줄링 담당 코드)

- ready인 프로세스 중 이번에 CPU를 받을 프로세스를 고른다.

## Dispatcher

- 실제로 CPU를 주는 놈.
- context switching을 하는 놈

## 스케줄링 성능 척도

### 시스템 입장

1. CPU Utilization: CPU에 일 많이 시켜야 꿀임

- cpu를 사용한 시간 대비 일한 시간의 비율 (최대한 일 많이 해야 좋음)

2. Throughput (처리량)

- CPU Burst의 갯수. 처리 완료한 갯수

### 프로세스 입장

1. Turnaround Time (소요시간, 반환시간)

- cpu를 받아서 다 쓸 때까지 걸린 시간 (CPU burst 시작~끝)

2. Waiting Time (대기 시간)

- 프로세스가 기다린 시간
- pre emtive의 경우 waiting 타임이 여러차례 쌓여서 길어짐

3. Response Time (응답 시간)

- 첫번째 응답이 오는데 걸린 시간 (타임 쉐어링 환경을 위한 기준)

#### 식당 예시

cpu utilization: 요리사가 요리한 양
throughput: 처리한 손님의 개수
turnaround time: 고객이 들어와 주문하고 식사하고 나가는데 걸린 시간
waiting time: 코스요리에서 다음 메뉴 나오는 거 기다린 시간의 총합
response time: 첫번째 음식이 나올때까지 기다린 시간

## CPU 스케줄링 알고리즘

### FCFS (선착순/ First come, First Served)

- 별로 효율적이진 않다. CPU를 많이 쓰는 프로세스가 cpu를 가지면 CPU를 적게 쓰는 프로그램이더라도 기다려야 한다.
- 관여한 **프로세스의 평균 웨이팅 타임**이 길어진다.
- convoy effect: 앞에 거대한 놈이 기다리고 있어서 기다리고 있어야하는 경우를 말함.

### SJF (Shortest Job First)

- 프로세스를 사용하려는 시간 즉 CPU burst가 가장 짧은 놈에게 프로세스를 줌
- preemtive: 일단 cpu 잡으면 해당 cpu burst가 완료될 때까진 cpu를 선점하지 않음
- nonpreemtive: 현재 수행중인 프로세스의 남은 burst time보다 더 짧은 cpu burst time을 가지는 프로세스가 도착하면 cpu 빼앗아서 줌
- nonpreemtive: **shortest average waiting time**

#### SJF의 문제점

1. starvation: 어떤 프로세스에겐 CPU가 계속 안 올 수도 있다.
2. 예측이 쉽지 않음: 얼마나 CPU burst time이 필요한지 프로세스 자신도 모름

- Exponential averaging:

### Priority scheduling (우선순위)

- 우선순위가 **가장 높은** 프로세스에게 CPU를 준다
- preemtive는 더 우선순위가 높은 프로세스가 나타나면 cpu를 넘겨주고, nonpre는 넘겨주지 않음
- 작은 숫자가 우선순위가 높음.
- SJF도 일종의 priority scheduling
- Starvation의 해결법: 에이징(aging) 기법. 우선순위가 낮은 프로세스라도 오래 기다리게 되면 우선순위를 높여주자.

## 라운드 로빈

![round robin scheduling](https://user-images.githubusercontent.com/50111853/154834115-4b900873-d810-4c8b-bff2-173cbb397a53.png)

- **각 프로세스가 동일한 크기의 할당 시간(Time Quantum)**을 가짐.
- Large Q: FCFS / Small Q: 매우 빈번한 Context Switch, 시스템 성능 저하 우려
- 응답 시간이 빨라짐.
- 굳이 예측할 필요 없이 CPU를 짧게 쓰는 프로세스가 짧게 쓰고 나갈 수 있음
- **CPU를 대기하는 시간과 쓰는 시간이 비례**
- 일반적으로 SJF보다 average turnaround time이 길지만 response time은 더 짧다.

## Multilevel Queue

- ready queue를 우선순위별로 여러개로 분할, 모두 cpu 쓰려고 기다림
- 차별적임. 그래서 multilevel feedback queue를 도입

### multilevel feedback queue

![multilevel feedback queue](https://user-images.githubusercontent.com/50111853/154834381-cc5b1e4b-79d5-4a24-bbec-9f2cbfa6b1f2.png)

- foreground(interactive): 라운드로빈
- background(batch, no human interaction): 선착순
- Queue에 대한 스케줄링이 필요
- Fixed priority scheduling: fore 부터 -> background / starvation 우려 있음
- **처음 들어온 프로세스는 우선순위 우선으로** 해줬다가 여러번 필요할 수록 우선순위가 뒤로 밀린다.

## multiple processor scheduling

![다수의 프로세서 스케쥴링](https://user-images.githubusercontent.com/50111853/154839986-bc4d10c5-9745-4d89-8aa7-803fd6b825da.png)

- cpu가 여러개면 스케줄링은 더 복잡해짐
- **load sharing**: 일부 프로세서에 Job이 몰리지 않게 부하를 공유

## real time scheduling

- real time: 정해진 데드라인 내에 끝나야함
- 미리 스케줄링을 해서 적재적소에 배치 / 주로 주기적으로 작업하는 프로세스가 많음
- hard real time systems: 반드시 데드라인 안에 끝내야
- soft real time systems: 일반 프로세스에 비해 높은 우선순위를 갖도록

## Thread scheduling

- Local 스케줄링: (user level thread가) 운영체제는 그냥 그 프로세스한테 cpu 줄지 안 줄지 결정. 어떤 쓰레드한테 줄지는 쓰레드 내부가 선택
- 글로벌 스케줄링: 커널 레벨 쓰레드의 경우, 커널의 단기 스케줄러가 어떤 쓰레드를 스케줄할지 결정

## 알고리즘 평가하는 법

![알고리즘 성능 평가](https://user-images.githubusercontent.com/50111853/154840176-a16412ec-636c-4366-8531-7feb11dcfc8b.png)

- Queueing models: 도착률과 처리율(service rate) 등으로 성능을 계산
- 구현 & 성능 측정: 실제 시스템에 알고리즘을 구현해 실제 작업의 성능 측정


CPU 스케쥴링 알고리즘의 종류와 방법


해가 바뀌고 올해엔 어떻게 공부해야하나 하는 고민을 많이 했다. 그래서 개발자 커뮤니티에서 사이드 프로젝트 팀을 찾아 들어갔고, 운영체제, 컴퓨터 구조 스터디도 매주 하고 있다.  
그럼에도 약간의 막막함은 사라지지 않던 차에, 오픈소스 강의로 유명한 Udemy에서 지속적인 성장을 하고자 하는 개발자를 위한 웨비나가 있다고 하길래 냉큼 신청했다. 듣고 느낀 점을 휘리릭 적어본다.

[Udemy 지속 성장하기 위한 개발자의 학습법](https://okky.kr/article/1154436)

## TDD의 철학으로 이해하는 피드백 주도 학습 방법 by Maker Jun 멘토

TDD란 '테스트를 먼저 만들고, 실제 코드를 작성하고, 원하는 대로 동작하는지 빠르게 피드백을 받는 것'을 말한다. 한국어로는 테스트 주도 개발이라고 한다.  
이러한 개발을 하기 위해선 **결정과 피드백 사이의 갭**을 인식하고, 그 **갭을 조절하기 위한 테크닉**이 필요하다.  
해야하는 것(결정)과 테스트 결과(피드백)의 차이를 줄여 최종적으로 해야하는 것=결과 가 되도록 만드는 것이다.  

## TDD가 필요한 이유

TDD가 필요한 이유는 딱 한 문장이 설명해준다. **"만약 내가 던진 농구공이 들어갔는지 1달 뒤에 알 수 있다면?"**  
아마도 기다리다 지칠 것이다. 어쩌면 내가 농구공을 던졌다는 사실 자체를 잊어버릴 수도 있다.  
TDD를 한다는 것은 농구골대에 공을 던져 그 공이 들어갔는지, 안 들어갔는지 바로 확인하며 코드를 짜는 것과 같다.  
Maker Jun 님은 계산기를 예로 드셨다. 

### TDD 방식대로 계산기 구현

<img src='/images/blog/2202/ds2.jpg' />

일단은 특별한 UI 없이, 계산기의 주 목적인 사칙연산이 되는 코드만 짠다.  
그리고 그 코드가 테스트를 통과한다면 다음 단계로 넘어간다.  

<img src='/images/blog/2202/ds3.jpg' />

두번째로는 최소한의 UI를 만들고 사용자 입력을 받아 이벤트 처리하는 부분을 구현한다.  
그리고 또 피드백을 하고, 덧붙이고, UI 전체 레이아웃을 잡고, 스타일을 입히고...  

테스트 개발의 핵심은 **분할 개발**이다!!!  
이런 식으로 결정과 피드백 사이의 괴리를 줄여가면 MVP(Minimal Viable Product)를 만들 수 있게 된다.

### 우리는 피드백 주도 학습을 하자!

Maker Jun 멘토님은 테스트를 먼저 만들고 개발하는 TDD처럼 우리가 피드백 주도 학습을 해야한다고 말하셨다.  
TDD처럼 나의 부족한 점을 정의하고 피드백을 해 그 약점을 고칠 수 있는 것부터 하나하나 공부를 하자는 거다!  
이 때 중요한 것은 **내가 지금 가지고 있는 지식으로 가장 작은 영역부터 해결해나가는 것**이다.

### 내가 적용할 것

가장 먼저 나는 프론트 엔드 개발을 할 때 UI부터 다뤘는데, 그러면 안된다는 것을 깨달았다.  
UI 먼저 할 게 아니라 내가 구현해야하는 것을 확실히 결정하고 테스트 코드를 기반으로 개발을 해야하는 것이었다.  
JS면 콘솔에서 가볍게 테스트를 하는 건 어떨까?  
리액트가 어떻게 돌아가는 지와 어느정도의 구현법은 잘 알지만, Redux를 자유롭게 쓰지는 못한다.  
그러면 일단 Redux의 다큐먼트를 보고 내가 모르는 부분을 찾아서 그부분부터 시작하면 되는 거다.  
중요한 건 내가 해야하는 걸 내가 해결할 수 있는 범위 내에서 최대한 잘게 쪼개는 것이었다.  
개발자로서 배워야하는 어마어마한 양의 기술과 라이브러리에 압도되곤 하는 나같은 주니어 개발자에게 꼭 필요한 조언이었다.  

--------------------------------------

## 개발자 : 지식의 저주 by Poco Jang 멘토

<img src='/images/blog/2202/ds4.jpg' />

대부분의 사람들은 본인이 알고 있다면 상대방도 알고 있을 것이라 생각한다.(Chip Heath의 '스틱' 중에서)  
그래서 그 지식을 공유할 필요가 없다고 생각해 기술 블로그를 잘 쓰지 않는다.   
또 "개발자로서 배워야할 것은 많은데 기술은 계속 변하잖아요. 이게 의미가 있는 건가요?"라고 묻는다.  
많이 알게 되면 내가 모르는 게 계속 보여 압도당하기도 한다.  

### 아는 만큼 보인다 

<img src='/images/blog/2202/ds6.jpg'/>

여기서 또 나오는 **메타 인지**! 내가 아는 것, 모르는 것을 잘 구분할 줄 아는게 중요하다.  
채용 공고에서 겹치는 게 **트렌드 기술**이다.

### 마음가짐의 중요성

<img src='/images/blog/2202/ds7.jpg' />

왼쪽 사진의 물컵을 보고 '반밖에 못 채웠네'라고 하는 사람이 있고 '반이나 찼네!!'라고 하는 사람이 있다.   
회사의 구인공고를 볼 때도 '난 반밖에 못 채웠네... 지원하지 말자'라고 생각하지말고, '난 반이나 할 줄 아네!'라고 생각하자.

### Poco Jang 멘토님이 말하는 것

<img src='/images/blog/2202/ds5.jpg' />

1. 컴퓨터 공학은 일종의 학문이다. 더 이상 개발을 얕보지 말자. **어려운 학문임을 인정하자.**  
2. '1시간 만에 00앱 만들기', '3개월 만에 XXX 개발자로'... 등 **인스턴트 학습의 유혹에 빠지지 말자**. 쉬워보이는 교육 컨텐츠에 익숙해져 평생 따라만 하지 말자.
3. "언젠가는 이해하겠지" 대충 넘어가지 말고 러닝 커브를 극복하자. 고통스럽지만 완벽하게 이해하도록 노력하자.
4. 지름길은 없다. 나만의 학습 로드맵을 그리자. 어차피 선택에 대한 책임은 내가 진다.
5. 모범 사례만 찾지 말고 **모범 사례가 되자.**
6. **포기할 이유를 찾지 말자.**

### 내가 적용할 것

내가 원하는 직무의 자격요건과 우대 사항 등을 보고 필요한 기술 스택, 경험의 교집합을 수집하자.  
그리고 그에 맞는 지식과 경험을 쌓자.  

### 웨비나가 끝나고

거의 2시간 진행됐는데 멘토님들이 즐겁게 진행해주시고 질문에 잘 대답해주셔서 좋았다.
들으면서 계속 나한테 하는 말 같았다. 나만의 로드맵을 그려보자!!!


더 나은 개발자가 되기 위해 나는 어떻게 공부해야할까?