
Facing with many errors while setting up a Jekyll github page, I'm logging it for the people like me.  
The problom was, I wanted to run the local server with the instruction  

```shell
bundle exec jekyll serve
```

but the terminal showed me **Permission errors**.  
Some said I should **change the system preference to give iTerm the full disk access** but I don't think it was the reason.  
Thanks to Vidyut, I **solved the error** and the helpful link is 
[here](https://luther.io/macos/how-to-install-latest-ruby-on-a-mac/)

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

## To do list 

- [ ] Delete previous Gemfile.lock
- [ ] Install Command Line Tools for Xcode
- [ ] Install Homebrew.
- [ ] Install rbenv and helpers.
- [ ] Modify your shell startup script.
- [ ] Install Ruby.
- [ ] Install Bundle
- [ ] Bundle add webrick


For me, it was the problem **I didn't install 'Command Line Tools for Xcode'.**  
Also, you need to remove the **Gemfile.lock** in your github page directory before you install bundle.  
I followed his track and reinstalled homebrew, ruby, and jekyll.  
And after 'bundle exec jekyll serve', 

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

```shell 
 ~/H/pullingoff.github.io  on master !4  bundle exec jekyll serve
Configuration file: /Users/blah/blah/pullingoff.github.io/_config.yml
            Source: /Users/blah/blah/pullingoff.github.io
       Destination: /Users/blah/blah/pullingoff.github.io/_site
 Incremental build: disabled. Enable with --incremental
      Generating... 
                    done in 2.645 seconds.
 Auto-regeneration: enabled for '/Users/blah/blah/pullingoff.github.io'
                    ------------------------------------------------
      Jekyll 4.2.1   Please append `--trace` to the `serve` command 
                     for any additional information or backtrace. 
                    ------------------------------------------------
/Users/blah/.gem/ruby/3.1.0/gems/jekyll-4.2.1/lib/jekyll/commands/serve/servlet.rb:3:in `require': cannot load such file -- webrick (LoadError)
```

-------------------------
Another error 😂   
It's just because **webrick got out of the default gem lists.**  
All you need to do is type

```shell
bundle add webrick
```

then the terminal will install webrick.


And it works!


지킬로 깃허브 페이지 만들다 만난 에러

맥 os montery에서 jekyll serve 시 Permission Error


리액트나 Node.js를 쓸때 `yarn`을 설치하고 시작하는 튜토리얼들이 많았다.  
그래서 자연스럽게 yarn을 썼었는데 문득 yarn이 npm이랑 똑같은 역할을 같아 둘의 차이가 궁금해졌다.  
`package-lock.json`이랑 `yarn.lock` 둘다 있는게 번거롭기도 했고.. 
요즘엔 npm만 쓰는데 많은 사람들이 yarn을 쓰는 이유가 있을 테니까! 싶어서 둘의 차이점을 찾아봤다.

## npm과 yarn의 공통점

1. 둘 다 Node.js package manager다.
2. 둘 다 **package.json에 저장된 프로젝트 메타데이터를 사용**한다.

## Yarn

- npm을 보완하기 위해 페이스북에서 개발한 Node.js 패키지 매니저다.

### Yarn의 장점

1. 속도가 빠르다  
npm은 패키지를 설치할때 순서대로 하나씩 설치하는 반면, yarn은 동시에 (병렬로) 여러 패키지를 설치한다.

2. plug n play  
yarn은 node_modules 폴더 대신 `_pnp.cjs` 파일에 **최적화된 디펜던시 맵**을 만들어둔다. 
그래서 빠르게 프로젝트를 구동하거나 install할 수 있다. -> 
그걸 바탕으로 인스톨하기때문에 오프라인일때도 딜레이가 매우 적다!

3. 보안이 더 잘 되어있다.  
npm은 dependency(의존성)이 있는 모든 패키지를 바로 설치하는 반면, 
yarn은 **`yarn.lock`이나 `package.json`에 있는 파일만** 설치한다. 
(npm, yarn 둘다 시큐리티 체크는 한다.)

npm vs. yarn 비교해보기


## 리덕스란

리덕스는 **상태를 관리해주는 리액트 전역 상태관리 라이브러리**다. 지금은 Redux toolkit으로 표준화됐다.  
상태를 연쇄적으로 변화시키며, 리액트하고 사용할땐 react-redux를 깔아서 함께 쓴다.  
컴포넌트의 상태 변경 로직을 다른 파일로 분리해 효율적으로 관리할 수 있다.

**상태관리가 왜 필요할까?**  
리액트의 경우 컴포넌트에서 원래는 useState 등을 사용했는데, 각 컴포넌트가 아니라 **앱 전체에서 상태를 관리해야하는 경우**가 많다.

그럴 때 **앱 전역에서 사용되는 상태를 관리**하는게 리덕스!

```js
// 만약 todolist를 만드는데 투두와 완료, 삭제리스트를 이렇게 관리하면 한 js에서 관리할 게 너무나 많음
const state = {
      todolist:[],
      donelist:[]
}
```

그럴 때 리덕스를 사용하면 **상태를 앱 최상위에서 관리하기 때문에 그 하위 컴포넌트 어디서든 상태값을 가져와** 사용할 수 있다.

## 작동 순서

![리덕스 작동순서](https://images.velog.io/images/hailey99/post/1c7d4cad-f918-429c-b039-d65573c0a4af/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202022-02-11%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%204.41.49.png)

리덕스는 사용자 Action이 발생했을때, Store로 가기까지 무조건 한 방향으로 움직인다.

1. dispatch 함수를 실행하면
2. action이 발생한다.
3. 이를 리듀서(reducer)가 전달하면
4. 최종적으로 상태(state)를 바꾼다.

### 구성 요소

- Action: 무조건 타입을 전달한다
```javascript
{type:'some text'}
```

- Reducer: param으로 상태와 액션을 받고 상태를 변화시키는 함수

```javascript
function reducer(state, action) {
    return changeState;
```

- Store: 앱 전체에서 사용되는 상태 저장소  
- Dispatch: 액션을 발생시키는 함수 (`e.g. dispatch(action)`)

참고: Fastcampus '한 번에 끝내는 Node.js 웹 프로그래밍 초격차 패키지 Online' 강의

## 장단점

**장점**

1. 데이터 관리하는 부분이 분리되어있어 테스트가 쉬움
2. 모든 구성요소는 Store의 모든 양식 상태에 액세스 가능

**단점**

1. Action type, selector, action 생성자, reducer 등 중복 코드가 많음


리덕스란 무엇인가, 리액트의 작동 순서


## 이노베이션이 아니라 리노베이션이다

- 경영을 위한 체질 개선: 쓸데없는 회의를 하지 말자, 보고서는 한 페이지로 하자, 구두로 보고할 수 있으면 구두로 하자,
우르르 모여서 하는 워크숍도 필요없다. => 정해진 시간에 열심히 일하고 퇴근하자.
- simplification: 보고서도 조직도 단순하게
- 회의는 모두가 반드시 알아야할 것을 공유하는 정도로 최소화. 나머지는 당사자끼리 직접 접촉해 해결
- 스마트 스테이션: 영업직의 사무공간을 줄이고 집, 거래처와 가까운 스마트 스테이션으로 출근해 업무
- simplicity = Core + Compact. 꼭 필요한 것(core)+ 나머지는 과감하게 없앤다(compact)
- 임직원의 빠른 피드백 => 직원들의 '불필요한 기다림'이 사라짐

## 솔직한 문화

- 실무자 선에서 대책 마련하거나 문제를 축소하는 방법을 찾아서 보고하지 말 것
- 문제가 발생했다고 즉시 공유하면, 문제를 오픈한 순간 해결은 CEO의 책임이 되고, 구체적인 대안을 함께 고민할 수 있다
- 소비자들만큼이나 내부 구성원들도 기업에 대해 점점 많은 것을 알고 싶어한다. 
- 사실 대부분의 이슈는 이미 리더의 머릿속에는 정리되어 있지만, 적시에 커뮤니케이션이 되지 않으니 구성원들 입장에서는 서로서로 아는 사실을 짜맞추어 추측한다. 이런 추측이 사실인 양 조직 내에 퍼진다. 그러므로 리더가 알게된 회사의 정보는 대외비가 아닌 한 가급적 빠른 시기에 직원들에게 정확하게 공유하고 공감을 일으켜 한 몸처럼 움직이는 조직을 만들어가야한다.
- 모를 때 모른다고 할 수 있다는 것은 그에게 자신감이 있다는 뜻이다. 다른 것은 알지만 이것은 아직 모른다는 의미다. 

## 업의 본질에 따른 포트폴리오 전략

- 세발자전거론: 생활용품, 화장품, 음료 3가지 사업을 함으로써 내진설계
- 고정된 부분은 최소화한다, 구조물의 무게를 경량화해 외부 충격에도 유연하고 빠른 대응이 가능하도록
- 사업의 흥망과 상관없이 고정비를 최대한 줄인다, 위-아래 간 커뮤니케이션을 간소화해 경영의 스피드를 높인다, 리스크와 성장을 고려해 사업분야를 다각화한다.
- 고정비에는 '조직문화적인 고정비'도 포함됨. (회의 자리 미리 세팅하지 않고 들어오는 순서대로 앉기, 이메일에 인사말 쓰지않기) -> 실용주의 

## 선택과 집중의 럭셔리 추구

- 엘지생건의 발효 컨셉 화장품 '숨'을 런칭할 때 "sk-2가 발효화장품인거 아시죠?" 말함으로써 사람들에게 익숙한 카테고리 리더와 비교해 유니크함을 더함. 
- e.g. 서울: 도쿄같은 곳인데 훨씬 다이나믹하다. 도쿄에서는 사람들이 밤 11시면 귀가하지만 서울에서는 그 시간부터 신난다. 

## 리더십과 레거시

- 패스트 팔로워일 땐 가야할 방향이 확실하므로 관리형 인재가 필요. 시장을 선도하는 리더로서 방향설정 능력이 필요할 땐 사업가형 인재들이 필요.
- 각자가 '사업가처럼 일하는 사람'이 

## 정도경영

- 부하직원에게 경어체 (김대리님, 이 파트장님)
- 외부 사람들에게 무리한 부탁을 하지 말자. 나중에 나에게 어려운 부탁을 할 수도 있다.
- 차 부회장은 직원들과 점심을 먹지 않는다. 밥 먹으면서 개인적인 이야기, 회사 돌아가는 이야기 -> 그들에게 정보가 편중됨. 진급 시에도 그 풀에 있는 사람에게 정이 감 -> 결국 파벌이 되고, 객관적이지 못해짐. 

## 결론

- 회사는 결국 직원, 주주, 소비자들에게 잘하면 된다. 그 외에는 예산과 리소스의 낭비가 크다.
- 많이 팔고 던 버는게 마케팅. 제품이 팔려야 백점짜리 마케팅이다
- 스티브 잡스의 'Stay hungry' 아직도 모른다, 여전히 배고프다고 생각해야함. '우리가 경쟁사보다 낫다'고 생각하면 배고픈 사람에게 진다. 
- '마케팅을 화려하게 구사하는' 경영자 말고 '일이 되게끔 하는' 경영자. 수치적 외적 성장보다 경영시스템을 개선하여 내부 성장의 토대를 만들다.
- 엘지생건은 '더하기'보다 덜어내기와 빼기에 주목해 성장했다.


Simplicity = Core + Compact, 리노베이션이 필요하다.

그로잉 업, 고위 경영진의 이야기와 경영 노하우를 배우다


깃에서 여러 브랜치를 만들어서 버전관리를 할 경우, A 브랜치에서 작업한 파일(커밋)을 다른 브랜치로 가져오고 싶을 때가 있다.  
그럴 땐 `cherry-pick` 명령어를 쓰면 아주 쉽게 가능하다.

## 다른 저장소의 커밋 가져오는 방법

1. 원래 브랜치에서 파일을 커밋한다.
2. 커밋 id를 알아둔다. (e.g. `50bd621`)
3. 커밋을 가져갈 브랜치로 간다. (`git checkout 목적지브랜치`)
4. 아까 그 커밋의 id를 사용해 cherrypick 한다. (`git cherry-pick 50bd621`)


깃 다른 저장소 커밋 가져오기


## 주요 보안 취약점

### 입력데이터 검증 및 표현

: 입력값 검증 누락 또는 부적절한 검증, 데이터의 잘못된 형식 지정으로 인해 발생.

- **크로스 사이트 스크립트 공격(XSS)**: 검증되지 않은 외부입력데이터나 부적절한 스크립트가 포함된 동적 웹페이지가 생성,전송되고 웹페이지에 포함된 부적절한 스크립트가 실행됨
- 사용자 정보유출, 세션도용, 악성코드 유포, 브라우저 무한반복 등의 공격
- request.getParameter("name")하는 코드에서 `<script>alert(document.cookies)</script>`가 입력되면 공격자에게 피해자의 쿠키정보가 전송될 수 있음. => 
`replaceAll()`을 사용해 `<`,`>`,`&`,`"`와 같이 스크립트 생성에 사용되는 모든 문자열을 &lt, &gt 등으로 변경해야 실행하지 못하도록 해야함

### sql injection

: 입력 데이터 유효성 점검하지 않아서 db 쿼리 로직이 변경되어 발생.

- 입력 값이 바로 sql 함수의 파라미터로 전달되지 않게 해야함. 파라미터화된 쿼리를 사용해야함. 
자바의 경우 `preparedStatement` 클래스를 사용해 `setString()`해서 외부의 입력이 쿼리의 구조를 바꾸는 것을 방지해야함

### HTTP 응답 분할

: http 요청 파라미터에 `\r\n`같은 걸 넣어서 http 응답이 분리된다. 첫번째 응답은 개행문자(\r, \n)로 종료시키고 두번째 응답페이지는 공격자가 맘대로 수정 가능하다. replaceAll을 넣어 개행문자를 제거해 응답헤더가 나눠지는 것을 방지해야함

- 버퍼 오버플로우: 프로그램이 버퍼에 저장할 수 있는 것보다 큰 데이터가 들어오지 않도록 입력값과 버퍼의 크기를 비교할 것
- 디렉터리 경로 조작: 파일명을 입력받을 때 상대경로(`\`,`\\` )등을 입력하지 못하도록 `replaceAll()`로 특수문자 제거할 것
- os 명령어 injection: `cmd.exe` 명령어와 다른 명령어 삽입하지 못하도록 입력값에 따른 선택지(white list)를 미리 만들어둘것.
- 자원 injection: service입력값을 소켓번호로 그대로 사용하는 경우 "-2920"과 같은 값이 들어오면 기존에 80 포트에서 구동되는 서비스와 충돌되어 에러 발생. 검사를 하고, 정해진 선택지 중 정해진 값을 할당하여 포트를 부여할 것.
- 동적으로 생성되어 수행되는 명령어 injection: eval 사용할때도 입력값 그대로 쓸 것이 아니라 `&amp;`, `&quot;` 등으로 `replaceAll()`하고 써야함
- 프로세스 제어: 외부 라이브러리 사용시 절대경로 사용할 것.
- 무제한 파일 업로드: 업로드하는 파일 타입과 크기 제한. 업로드 디렉터리를 웹서버의 다큐먼트 외부에 설정. 화이트리스트 방식으로 허용된 확장자만 업로드, 확장자도 대소문자 구분없이 처리.
- URL Redirection 시 url과 도메인의 화이트리스트를 이용하고, 사용자로부터 입력받은 url을 그대로 사용하지 말 것
- 시스템의 상태 정보나 중요한 정보는 서버에만 저장한다. 평문으로 사용자의 유저네임, authenticated값 등을 쿠키에 저장하지 말것.대신 세션에 저장해라. 중요한 정보를 쿠키에 저장할 땐 암호화한다. 외부입력 검사가 js를 통해 브라우저에서 이루어져도 서버 측에서 재검사를 한다.

### API 악용

- 필요한 파라미터가 null인지 검사할 것
- Java에서 동일 객체는 동일한 해시코드를 가져야한다. 따라서 한 클래스내에서 `equals()`와 `hashcode()`는 둘다 구현하거나 둘다 구현하지 않아야한다. ?????????????

### 보안특성

- 하드코드된 패스워드
- 사이트간 요청 위조: CSRF(Cross-site Request Forgery) / 교차접속 요청 위조: 공격자가 웹서버에 CSRF 공격 코드를 등록, 사용자가 웹 서버에 CSRF script 포함된 페이지를 요청, 웹 서버는 CSRF script를 포함하여 사용자에게 응답, 사용자는 CSRF에 사용자 권한으로 사용가능한 서비스를 요청. get을 쓰면 form 전달값이 노출되므로 CSRF 공격에 쉽게 노출될 수 있다. 인풋 폼 작성시 post 사용할 것. 또는 폼과 입력을 처리하는 프로그램 사이에 토큰을 사용해 공격자의 직접적인 url 사용을 막을 것
- 부적절한 세션 만료: 세션이 영원히 끝나지않거나 다른 사용자가 세션을 가로챌 수도 있음. 
일정시간이 흐르면 세션이 종료되도록 `session.setMaxInactivaInterval(12000)`등 양의 정수값 설정.
- 취약한 암호화 알고리즘 사용
- 예측 가능한 난수 사용. Java에서 `Math.random()`은 seed를 재설정할 수 없어 위험하다.
 `java.util.Random` 의 `setSeed(new Date().getTime())`을 사용해 r을 예측 불가능한 long타입으로 설정해라.
- 기밀정보의 단순한 텍스트 전송
- https로만 서비스하는 경우 브라우저 쿠키에 데이터를 저장할때 
반드시 Cookie 객체의 `setSecure(true)` 메서드를 호출해야함. 
보안 속성 설정하지 않으면 단순한 텍스트의 형태로 노출될 수 있다.

### 시간 및 상태

: 프로그램 동작과정에서 시간적 개념을 포함한 개념(프로세스 등)이나 시스템 상태에 대한 정보와 관련된 취약점

- 파일 등의 공유 자원을 여러 스레드가 접근해 사용할 경우, 동기화를 사용해 한번에 하나의 스레드만 접근가능하도록 할 것. 다중 스레드와 공유 변수 사용시 thread safe 함수만 사용, java의 경우 synchronized 사용
- 재귀 종료 잘 되도록 할 것

### 에러 처리

- 패스워드는 강하게 요구할 것. 패스워드 복잡도를 검증할 것
- 오류 메시지를 통한 정보 노출. `e.printStackStrace()`를 출력하지 말것. 
에러 메시지는 정해진 사용자에게 유용한 최소한의 정보만 포함하도록 할 것.

### 코드 품질: 코드가 복잡하면 안전성을 위협할 취약점들이 있을 수도 있다

- signed int를 unsigned int로 변환하면 음수가 큰 양수가 되는데 
이 값이 배열의 인덱스로 사용되면 정수 오버플로우가 일어나 프로그램이 오동작할 수도 있음. 
e.g) C의 `len()` 함수에서 문자열이 null일 경우 -1를 반환하는데 이걸 unsigned int로 변환하면 10억단위가 된다. 
버퍼 오버플로우 취약점을 가질수도 있다. null이면 -1대신 0을 반환하게 한다.
- int를 char로 변환할 때 4바이트->1바이트니 크기 확인하고 변환
- database connection 중 예외가 발생되어도 `finally`를 사용해 할당받은 자원(Jdbc 커넥션)을 반환(close)할 것

### 캡슐화

- 제거되지 않고 남은 디버거 코드. `System.err.print("디버그코드")`
- 민감한 데이터를 가진 내부클래스 사용: 내부 클래스는 컴파일 과정에서 패키지 수준의 접근성으로 바뀐다. 내부클래스를 static 선언해 외부클래스의 private 필드에 접근하지 못하게 한다.
- 변경하면 안되는 public 멤버 변수는 반드시 final 키워드로 선언한다.
- private으로 선언된 배열을 public 메서드로 반환하면 외부에서 배열의 reference를 알 수 있다. 
public 메서드 안에서 private 배열의 카피를 만들어서 그것을 반환하도록 작성하면 private 배열의 수정을 막을 수 있음
- 시스템 데이터 정보 누출: 예외 발생시 `e.getMessage()`같은 것 출력하지말고 IOE exception occured 와 같은 대략적인 정보만 제공.

### 그 외 사용 가능한 방법들

- 동적 SQL: 조건에 따라 쿼리가 다를 경우 프로그램 실행시 전체 쿼리가 만들여서 db에 요청하는 sql
- 상호배제(mutex): 동시 프로그래밍에서 공유 불가능한 자원의 동시 사용을 막기위해 사용되는 알고리즘
- DAP(Lightweight Directory Access Protocol): TCP/IP 위에서 디렉터리 서비스를 조회하고 수정하는 응용 프로토콜


주요 보안 취약점과 이를 막기 위한 코딩 방법

시큐어 코딩 : 보안을 고려해 개발하기


## 내 생각

중학생 때 스마트폰을 사용하기 시작해서 줄곧 안드로이드를 사용했다. 고등학교를 졸업한 이후에야 아이폰을 쓰면서 애플 생태계에 들어갔다. 
신기하게도 아이폰을 쓴 이후로는 내 휴대폰에 대한 불만, 새 휴대폰을 향한 열망이 사라졌는데 그 이유는 '갤럭시는 사용할 수록 잔렉이 잦아진다'는 거였다. 
휴대폰을 사용한 기간이 길어질 수록 속도가 느려지고, 버벅거리는 듯 했는데 마이크로인터랙션의 부재때문에 그렇게 느껴졌었다는 걸 이 책 덕분에 알게 되었다.
아이폰이 상대적으로 마이크로인터랙션이 풍부하게 적용되어있어 기기의 처리 속도가 느려지더라도 사용자(나)가 덜 느꼈다. 
애플은 철저하게 마이크로인터랙션을 배치해 휴대폰을 조작하는 것을 사용자로 하여금 디지털의 무언가를 조작하는 게 아니라
철저히 아날로그적인, 부드러운 무언가를 만지는 듯한 느낌을 느끼도록 했다.
실제로 사용자가 화면을 슬라이드하다가 맨 끝에 다다랐을 때에나 언제든 절도 있게 딱딱 끊어지지않고 부드럽게 (자연스럽게) 만들었다고 한다. 
마이크로 인터랙션은 사용자에게 절대 작지 않게 작용한다.

## 1장: 마이크로인터랙션 디자인

- 휴대폰이 매너모드일 때 알람도 음소거돼야하는가? iOS 휴먼 인터페이스 가이드라인 왈 
"음소거 스위치를 켜 놓아도, **사용자가 분명한 의도를 가지고 직접 설정한 소리**는 그대로 재생됩니다."
- **마이크로인터랙션: 제품에서 1가지 사용 사례에 해당하는 짧은 순간, 혹은 한가지만 수행하는 작은 기능
(e.g. 설정변경, 데이터 동기화, 비번 설정, 로그인 등)**
- "디테일은 그저 디테일이 아니라 디자인 그 자체다" / Charles Eames

### 마이크로인터랙션을 적용하면 좋은 때

1. 하나의 작업을 수행할 때
2. 기기들을 서로 연결할 때
3. 단순한 정보를 주고 받을 때(주가, 날씨 등)
4. 진행중인 기능을 조정할 때(TV 채널)
5. 설정 변경할 때
6. 간단한 내용을 작성하거나 확인할 때 (상태바)
7. 어떤 기능을 끄고 켤 때

- 발전 단계 초기 기술과 같이 물건을 쓰는 방법보다 무슨 기능을 수행할 수 있는지가 의미있을 때에는 마이크로인터랙션의 중요성이 상대적으로 적다. 
이후 시장 내 경쟁이 강해질 수록 마이크로인터랙션은 중요해진다.

### 마이크로인터랙션의 숨겨진 역사

- 크롬에서는 검색 시 검색어가 위치한 부분을 노랗게 표시
- 원래 스크롤 바는 행 단위로 움직였고, 스티브 잡스 이후 픽셀 단위로 움직이게 됨. + 스크롤하지 않고도 문서의 끝으로 바로 갈 수 있는 화살표 버튼 추가.
- 터치스크린에서 문서를 아래로 스크롤할 때 손가락을 위로 움직여야할까, 아래로 움직여야할까? 
애플이 아이폰 발표 이후 natural scrolling(자연스러운 스크롤 방식)을 위해 아래 스크롤 명령의 방향을 위로 올리는 방식으로 바꿈
- **"버튼의 등장으로 인간의 동작은 그로 인해 생기는 움직임과 처음으로 완전히 분리될 수 있게 됐다." / 드루시, '버튼의 역사'** => 동작이 추상적인 의미를 갖게 됨

### 마이크로인터랙션의 구조

아름다운 마이크로인터랙션은 4요소를 포함: `트리거(trigger)`, `동작규칙(rule)`, `피드백(feedback)`, `순환모드(loops and modes)`

1. 트리거: 모든 마이크로인터랙션의 1요소.  
⁃ 아이폰에서 벨소리 끌 때는 사용자가 직접 행동해야함.(수동 트리거) and 이것은 수시로&빠르게 수행해야함 => 
언제나 쉽게 접근할 수 있어야하고 무슨 기능을 수행하는 중이든 간에 바로 켜고 끌 수 있어야함 => 음소거 용 물리적 조작 장치 부착

2. 동작규칙  
⁃ e.g. 전등은 스위치가 다시 꺼질때까지 계속 켜져서 밝은 상태를 유지해야한다.
3. 피드백: 우리가 **보고 듣고 느낌**으로써 시스템의 동작규칙을 이해하게 하는 모든 것  
⁃ '문서'를 실제로 '폴더'에 집어넣지 않고, '이메일'이 '수신함'에 실제로 오는 게 아닌 것처럼 모든 것은 
그안에서 벌어지는 상호작용을 우리가 이해하기 쉽게 해주는 은유(metaphor)임.  
⁃ e.g. 스위치 올리면 전구에 불이 들어오는 것, 이메일 앱에 읽지 않은 메시지 개수, 네비게이션의 음성, 알림음, 주문 진행표시 막대 등
4. 순환과 모드

### 디자인 철학으로서의 마이크로인터액션

제품에 마이크로인터랙션을 부여하는 방법

1. 마이크로인터랙션을 그때그때 상황에 따라 고려. 하나하나 어떻게 개선할 수 있을지 등 생각해본다. but 범위 제한이 어려움
2. 복잡한 서비스를 쪼개서 각 하나의 마이크로인터랙션을 중심으로 하는 개별적인 제품의 집합으로 만든다.
**대신 1기능만 제대로 제공해야한다. 다른 기능은 다른 제품으로 만든다.** (MVP: Minimum Viable Product, 최소 요건 제품)
4. 기능 전체를 서로 연결된 마이크로인터랙션들의 조합으로 다룬다.

## 2장: 트리거

⁃ 1990년 대 뉴욕 지하철의 회수권 대신 플라스틱 메트로카드를 도입할 때 당시엔 터치 스크린을 사용해본 사람이 적었음. 
그래서 그들은 **자판기의 모든 화면이 한번에 1기능만 수행하도록** 함.(대화처럼 1화면 1질문하도록 디자인 => 모든 화면이 각 1마이크로인터랙션)

⁃ 전체 터치 스크린을 하나의 커다란 트리거로 만듦. 대기화면을 '이곳을 터치하세요'로 해둠. but 사실 화면 아무데나 터치하면 거래 시작. 이 때의 **트리거는 시작 버튼**.
사람들이 거래 시작할 때 그 버튼을 누르는 것을 유도하는 시각적 힌트이자 가짜 어포던스(affordance)

### 트리거의 조작부

⁃ 1동작(빨리 감기 등): 그냥 버튼, 탭, 밀기 등  
⁃ 2동작(켜기, 끄기): 토글 스위치(but 현재 상태가 뭔지 알기 힘듦), 그냥 버튼
⁃ 여러동작: 다이얼  

⁃ 정해진 범위 내 연속적인 값 조절(음량 조절): 슬라이드 바나 다이얼  
⁃ 폼(form): 빈 양식보다 이전에 입력된 내용이나 사려깊게 준비된 기본값으로 미리 채워져있어야함  
⁃ 트리거는 언제나 같은 행동을 해야함.

## 3장: 동작규칙

- **"단지 차별화하기 위해서 다르게 만들어진 물건이 더 나은 경우는 거의 없다. 하지만 더 좋은 물건을 만들려고 하면 거의 언제나 차별화되는 물건이 나오기 마련이다." / 디터 람스**
- 동작규칙 디자인 전에 마이크로인터랙션의 '목표'를 가장 단순명료한 형태로 정의해야함. 이때 목표는 과정이 아니라 사용자가 원하는 최종 상태여야함

### 동작규칙이 결정하는 것들

1. 트리거 활성화 시 마이크로인터랙션의 반응. 백지에서 시작하지 말 것. 사용자와 그 맥락에 대한 정보를 활용하면 마이크로인터랙션 개선 가능(e.g. 사용중인 플랫폼,기기, 시간, 주변공간의 소음 수준, 배터리 수명, 사용자의 위치와 방향, 화면 밝기 등)
2. 마이크로인터랙션 진행중 사용자가 중간에 조작할 수 있는 항목. (E.g. 다운로드 취소, 음량 조정 등)
3. 동작 순서와 타이밍 (e.g. 사용자가 검색창에 문자를 입력했을 때만 검색 버튼 활성화)
4. 사용되는 정보와 그 목적
5. 관련된 알고리듬의 구성과 변수
6. 피드백 종류와 제공 시기
7. 마이크로인터랙션의 모드 (e.g.날씨 앱의 날씨 확인 도시 입력 모드- 날씨 확인 모드) 모드는 가능하면 피해라.
8. 마이크로인터랙션의 반복 여부와 빈도
9. 마이크로인터랙션이 종료될 때 생기는 일
 ⁃ 동작규칙 정할 땐 마이크로인터랙션을 위해 수행해야하는 것들을 떠오르는 대로 적는다. (요구사항 정의 비슷한 느낌) -> 미묘한 디테일 추가. 논리 흐름도를 적어보는 것도 좋음  
 ⁃ 사용자가 취하는 행동을 동사로, 그런 행동이 가능하게 하는 물건을 명사로 적어보라.   
 (e.g. '슬라이드 바'로 사용자가 '음량을 높이거나 낮춘다') 이때 마이크로인터랙션에 포함되는 명사는 모두 유일해야함. 같은 명사를 2개의 마이크로인터랙션에서 쓰면 그 둘을 하나로 합치는 것을 고려하라. 서로 다르게 동작하는 항목(버튼 등)은 서로 다르게 생겨야함.

### 마이크로인터랙션의 3상태

1. 기본 상태
2. 활성화 상태(사용자와 상호작용중)
3. 갱신된 상태(사용자와 상호작용 끝)

- 기본 선택값을 잘 준비하고 사용자가 선택할수있는 '동작규칙을 바꾸는' 항목을 무자비하다 싶을 정도로 줄여야함. (e.g. 생일 입력칸이 직접 문자 입력 방식이면 유효하지 않은 날짜를 입력할 수 있다. 방식을 드롭다운 메뉴로 바꾸면 예외 상황 방지 가능)
- 이용할 조작 장치, 장치를 제시하는 방법을 잘 결정해야함. 특히 문자 입력칸의 경우 '불가피한 다양성'이라고 불리는, 다양한 조건에서 제대로 동작할 수 있는 능력 필요 (e.g.구글 문서에서 표 삽입할 때 표의 크기를 시각적으로 선택할 수 있는 창)
- 동작규칙의 주요 역할 중 하나는 사용자의 오류를 원천적으로 방지하는 것.(e.g. 애플의 라이트닝 케이블. 앞뒷면이 같아 사용자가 플러그가 뒤집어진 것을 모르고 꽂으려는 애쓰는 상황을 원천 방지) 사용자가 잘못 조작하는 여지를 남기지 않고 디자인하여 오직 시스템이 제대로 반응할 수 없을 때만 오류 메시지를 표시하도록 해라. (e.g. 댓글 입력창에 욕설을 입력하면 '고양이'로 바꾸어 결과 표시)
- microcopy. 레이블이나 안내문 같은 문구. 동작규칙을 이해하도록 함. (E.g. 페이스북의 '좋아요' 마이크로인터랙션) 레이블만으로 충분한 경우에는 절대로 안내문을 사용하면 안된다.
- 안내문에 사용된 표현은 조작부의 명칭과 정확히 일치해야함

## 4장: 피드백

- 슬롯머신의 시각 효과와 음향이 사용자의 몰입을 불러일으키는 것처럼 피드백이 마이크로인터랙션에 개성을 부여함.
- 목적: 사용자가 그 마이크로인터랙션의 동작규칙을 이해하도록 돕는 것. 사용자가 버튼을 누르면 2가지를 표시하는 반응이 있어야함(1. 버튼이 눌렸다는 것, 2. 버튼이 눌림으로 인해 생긴 일)
- 원칙 1: 피드백을 통해 사용자에게 지나친 부담을 주지 않는 것(e.g. 워드에서 이탤릭 글꼴 입력할 땐 커서 자체를 기울여서 표시)
- 원칙 2: 뚜렷한 이유없이 제공하면 안됨. 언제나 사용자를 도와주기위한 메시지를 전달해야하고 피드백을 야기한 사용자의 동작과 그 피드백 사이에 밀접한 관계가 있어야함
- 원칙 3: 최소한의 피드백으로 최대 정보 전달
- 원칙 4: 디자인 과정에서 간과하기 쉬운 부분을 메시지 전달 방법으로 활용(스크롤 바, 커서, 프로그레스 바, 툴팁, 마우스 오버 효과 등)
- 피드백은 마이크로인터랙션에 성격,유머를 주입할 수 있게 된다. 사용자는 사람같은 반응을 좀 더 받아들인다. 불쾌한 골짜기(uncanny valley) 현상처럼 지나치게 개성을 드러내는 것보단 약간만.

### 피드백이 일어나야하는 경우

- 수동 트리거가 작동한 직후, 트리거 조작중, 조작 완료시
- 마이크로인터랙션이나 주변 조건에 중대한 변화를 일으킨 시스템 트리거가 작동했을 때. '중대한' 정도의 판단은 맥락마다 다름.
- 사용자가 정의된 동작규칙의 범위를 벗어나려고할 때 (e.g. 목록을 끝까지 스크롤해서 더이상 표시할 항목이 없는 상황)
- 시스템이 명령을 수행할 수 없는 경우
- 시간이 오래 걸리고 중대한 작업의 진행상황을 보여주는 경우(e.g. 다운로드 수행에 필요한 시간을 어림잡아 표시)
- 애니메이션이 가져야하는 특성: 빠름, 부드러움, 자연스러움(중력, 관성 같은 자연의 법칙을 따를것), 간결함, 목적(단지 보기 좋다는 이유는 안됨)
- 피드백 시 직설적이지 않게, 불안감을 줄이는 문구로, 무엇이 잘못 되었는지와 해결 방법을 함께 제시해야한다.
- 음향 피드백은 사용자가 이전에 들었던 소리와 연관시킬 수 있는 음향이 좋다. (e.g. 휙 -맨위로 올라가는 소리)

## 5장: 순환과 모드

- 모드: 앱이 평소와 다르게 동작하는 특별한 부분. 특정 모드동안은 평소와 다른 기능이 수행된다.
- 순환 loop: 하나 이상의 명령이 반복. (앞으로 loop)
- 횟수 기준 루프: 정해진 횟수만큼 반복
- 조건 기준 루프: 조건이 충족되면 계속 반복(e.g. 인터넷 접속돼있으면 1분마다 새로운 트윗 확인)
- 수집 기준 루프: 주어진 집합에 포함된 모든 항목을 대상으로 실행 후 종료(e.g. 안 읽은 이메일마다 새 메일 개수 표시를 늘려가는 것)
- 무한 루프. 가급적 피해야함
- 개방형 루프: 피드백에 반응하지 않고 그냥 실행되고 종료됨(e.g. 매일밤 10시에 조명 켠다)
- 폐쇄형 루프: 자체적인 피드백 기제가 있어 스스로 행동 조정(e.g. 자동차 엔진 소음의 크기를 확인, 카 스테레오의 음량을 그때그때 조정)
- 가장 강력한 루프는 오랜 기간에 걸쳐 일어나며 시간이 지남에 따라 행동에 대한 피드백을 받아들이는 폐쇄형 루프 = 장기적 루프
- 사용자가 점차 마이크로인터랙션에 익숙해지면 단순하게 한다. (e.g. 트윗 올릴때 처음엔 'post'라는 문구가 있다가 이후엔 체크 표시만 남는다)

### 장기적 순환 loop

- Long wow(오래 가는 감탄). 시간이 지남에 따라 마이크로인터랙션을 조정함으로써 점차 사용자에 맞춰 변화하는 듯 보이거나 
심지어 완전히 새로운 경험으로 여겨지도록 하는 것 (e.g. spotify에서는 플레이리스트에 곡이 추가된 날짜를 시간이 오래됐을 수록 옅게 표시,
 구입 희망 목록에 든 상품을 매주 알려줌, 내 정보 기억하기 체크 박스)

## 6장: 마이크로인터랙션 프로젝트의 사례

### 이미 만들어진 제품에 마이크로인터랙션을 개선 또는 추가하는 법

- 이 경험을 특징적인 순간으로 만들 필요가 있는가? 기억에 남아야하는가?
- 백지에서 시작하려면 어떻게 해야하는가? 사용자나 맥락에 대해 알고 있는 정보를 사용해 마이크로인터랙션을 개선할 수 있는가?
- 해당 ML에 든 정보 중 가장 중요한 부분은 무엇인가? 사용자가 첫눈에 확인해야하는 정보가 있는가?
- 사용자의 실수를 예방하고 있는가?
- 익숙해진 사용자를 위해 보이지 않는 트리거를 사용할 수 있는가?
- 문자와 아이콘을 사용자가 이해할 수 있는가? 마이크로카피는 큰 소리로 알려줄 정도로 중요한 내용인가? 유머 감각을 더할 수 있는가?
- 애니메이션을 추가해 좀 더 동적으로 만들 수 있는가? 화면이나 상태를 전환할 때 사용자를 방해하지 않으면서 다음 단계를 표시할 수 있는 방법은 없는가?
- 피드백을 제공할 때 음향이나 촉감 등 다른 방식을 추가할 수 있는가?

### 마이크로인터랙션의 검증

완료율, 마이크로인터랙션의 전체 수행 시간, 특정 단계에 걸린 수행 시간, 단계의 개수, 클릭/탭/선택의 개수, 
시스템 오류(ML 스스로)의 횟수, 사용자 오류의 횟수

## 읽으며 인상적이었던 마이크로인터랙션들

1. MailChimp에선 메일의 가로 크기를 침팬지의 팔로 표현함. 메일침프에서 제공하는 600px를 넘어가면 침팬지의 팔이 끊기는 그림을 보여줌
2. 이메일 배경에 웃는 얼굴의 해가 있다. 꼭 기분 좋은 메시지가 아니어도 임의로 웃는 얼굴을 표시하는 것은 좋지 않은 피드백 사례임


버튼의 등장으로 인간의 동작은 그로 인해 생기는 움직임과 처음으로 완전히 분리될 수 있게 됐다.

마이크로인터랙션


## Create React App

브라우저 접근 -> CDN이 스크립트와 스타일을 포함하는 HTML 페이지를 반환 -> 
js를 실행한 후 클라이언트 사이드에서 HTML 컨텐츠가 렌더링 -> 데이터까지 받으면 동적 컨텐츠가 렌더링됨

### 장점

- 리액트 팀에서 생성 및 유지 관리

### 단점

- 서버 사이드 렌더링 없음. 라우팅 라이브러리 필요
- Code splitting과 같은 기능을 직접 구현해야함
- eject 시 복잡성 증가

## Next.js

렌더링된 HTML 페이지를 클라이언트가 받음 -> JS 앱이 시작되고 hydration 단계에 들어섬 -> 데이터를 받아 동적 컨텐츠 로딩

### 장점

- 페이지마다 data-fetch, pre-rendering 전략을 다르게 할 수 있음
- 다양한 상태관리, 스타일링 라이브러리 지원
- 파일 시스템 라우팅
- API route

### 단점

- 프레임워크 지식이 필요(`_app.js`, `_document.js`, `getServerSideProps` 등)
- 플러그인 시스템 없음
- 이미지 최적화

### Next.js로 인증 없이는 접근조차 못하게 막기

Next.js는 로그인/인증이 없으면 페이지에 접근조차 못하게 막을 수 있다. (핵심적인 스크립트 파일 유출을 막을 수 있음)

```js  
Page.getInitialProps = async (context: ServicePageContext) => {
    if (!validate(context)) redirect('/login')
    return {}
}
```

## Gatsby

### 장점

- GraphQL(단점이자 장점)
- 플러그인 생태계
- 이미지 최적화
- 정적 페이지 성능이 Next.js보다 약간 더 좋음

### 단점

- 빌드시간이 오래걸림 (이미지 최적화, 정적 페이지)

## 프레임워크 별 응답값

|    | CRA | Gatsby | Next.js |
|----|-----|--------|---------|
| 응답값| - 빈 HTML  - JS | - 그려진 HTML  - JS | - 그려진 HTML   - JS   - JSON (페이지 데이터) |

**이 때 Next.js가 렌더링에 필요한 데이터도 브라우저로 같이 보내므로 브라우저에서 최초에 데이터를 요청하지 않음**


Categories