1. 문제의 발단

• 혼자서 이것저것 연습해 보고, 씹고 뜯고 맛보고 즐긴 스플린트들이 많다.
• 이것을 다시 해보고 싶었다.
• 물론, 삭제하고 Git으로 다시 클론 하는 방법도, Ctrl + z를 연타하는 모습도 너무 없어 보인다.
• 더 멋있게 Git의 브런치들을 이용해 작업물을 넘나들면서 연습하고 더 초고수가 되어보자.

2. 브랜치

• 브랜치(Branch)는 '나무 가지'를 뜻 한다. Git의 브랜치도 나뭇가지가 뻗어 나오듯이, 각각의 줄기의 지점을 분기로 잡고 그 분기로 언제든지 돌아갈 수 있다.
• 간단하게 말하면 닥터 스트레인지의 '타임 스톤'이다. 위치만 저장을 해 놓은다면 어떤 지점의 코드로든 갈 수 있는 것이다.
• 닥터는 14,000,605개의 미래를 타임스톤으로 직접 돌아가 가속시켜 체험하고 결국 타노스와의 승리를 할 수 있는 브랜치를 찾아낸 것이다!
• 결국, 브랜치를 만든다는 것은 어떤 부분에서 문제가 생겼는지 알기 쉽고, 책임 소지가 확실하며 기존의 코드를 완전히 날려먹지 않고도 개인적으로 다른 작업을 하는 등의 장점이 있다.

3. 브랜치 명령어

• $ git branch 브랜치 이름: 새로운 브랜치를 만든다.
• $ git switch -c 혹은, $ git checkout -b 브랜치 이름: 브랜치를 생성한 후 그 해당 브랜치로 바꾼다.
• $ git branch: 브랜치들의 목록 확인
• $ git branch -d 삭재할 브랜치 이름: 브랜치를 삭제함
• $ git branch -D: 병합 되지 않은 브랜치를 강제로 삭제함.
• $ git log --branches --graph --decorate: 브랜치를 그래프로 본다.
• $ git stash: commit 하기 전의 작업들을 일단 스택에 넣어 둔다.
  • 이전에는 커밋 이후, git log로 목록을 본 후에, 그 log의 코드 6글자를 복사해서 git reset 코드 6글자 --hard로 바로 돌아가는 방법을 많이 사용했다.
  • 프로젝트를 진행 하게 되면 다양한 브랜치들을 만들어서 다양한 버전의 결과물들이 팀원들과 섞이게 된다면 사용하게 될 것이다!

4. rebase와 merge

• 둘 다 하는 일은 비슷하다. 두 개의 브랜치를 합쳐버린다.
• 하지만 merge는 말 그대로 합병이다. 이때까지 수정했던 이력들은 남기고 이후 남은 부분을 합친다.
• rebase는 그 브랜치가 있는 시점으로 아에 옮겨 버린다는 점이 다르다. 나머지 수정했던 이력은 남지 않는다.

1. 문제의 발단

• OSI 7 계층의 네트워크들을 더욱더 자세하게 알아본다.
• 기본적인 메커니즘은 이해를 한 상태에서 보아야 이해가 된다.
• 전반적인 HTTP/네트워크의 디테일한 부분에 대해 다루고 있다.

2. 인터넷 프로토콜

• 클라이언트가 요청을 보내고, 서버에서 응답을 줄 때, 어떻게 다양한 컴퓨터들을 거쳐서 정보를 주고받을 수 있을까?
• 먼저, IP주소를 통해 위치를 파악하고, 패킷(Packet)으로 전달하게 된다.
• 패킷(Packet)?
  • 통신의 단위이다.
  • IP주소에 따른 출발지와 도착지 등의 정보가 들어있다.
  • 말하자면, 택배를 보낼 때 송장이라고 생각하면 쉽다.
  • 그래서 이곳 저곳의 물류센터들을 돌아서 결국 택배를 구매한 사람에게 정확하게 갈 수 있게 된다.
• 물론, 서버도 패킷을 이용해 응답을 보내준다.
• 하지만 이런식으로 IP 프로토콜을 전계 할 때 한계점이 있다.
  • 비연결성 : 패킷을 받을 대상에 문제가 있더라도 일단 전송한다. 즉, 패킷을 보내기 전에 서버의 상태를 알 수 없다.
  • 비신뢰성 : 패킷이 중간에 손실될 수 있으며, 전달 순서가 섞일 수 있다. 즉, 패킷을 한번 보내고 나면 이후 상태도 알 수 없다.

3. TCP와 UDP

• 위의 IP프로토콜의 한계점을 보완하기 위해 중간에 단계를 하나 더 집어넣었다.
• IP 패킷을 생성하기 전에 '소켓(Socket)'을 이용해 정보들을 추가해서 보내준다.
• TCP
  • TCP 세그먼트 안에는 출발지와 도착지의 PORT, 전송의 순서 등이 들어가 있다.
  • 3 way handshake를 사용한다.
    • 3 way handshake?
      • 3번에 걸쳐서 서버와 클라이언트가 연결이 정상정으로 될 수 있는지를 확인하는 것이다.
      • 먼저, 클라이언트가 서버에 접속을 요청하는 SYN(synchronize) 패킷을 보낸다.
      • 서버는 요청을 수락하는 ACK(Acknowledgment)와 SYN패킷을 보내준다.
      • 클라이언트는 ACK로 다시 응답한다.
      • 위의 과정에 문제가 없다면 연결되었다는 것이다.
    • 위의 과정으로 서버의 상태를 확인할 수 있으므로, 연결성이 보장되고, 중간에 단계가 꼬이거나 문제가 생기면 그것을 토대로 다시 요청을 보낼 수 있게 되기 때문에 신뢰성도 보장될 수 있다.
• UDP
  • UDP 세그먼트 안에는 IP 프로토콜의 PORT, 간단한 중복이나 오류를 검사하는 '체크섬 필드' 정보 정도만 들어있다.
  • TCP보다 훨씬 단순하다.
  • 덕분에 빠르다!
  • 연결성과 전송 순서는 보장되지 않는다.

4. HTTP

• 우리가 사용하고 있는 그 HTTP 프로토콜을 뜻한다.
• 클라이언트와 서버의 구조로 나누어져 있다.
• 무상태 프로토콜이다.
  • 무상태 프로토콜?
    • 서버가 클라이언트의 상태를 가지고 있지 않다.
    • 즉, 클라이언트는 서버의 상태가 어떨지 모르므로 요청을 보낼 때 모든 사전 정보들을 계속해서 보내주어야 한다.
    • 대신에 서버는 무한대로 증설이 가능하다. 클라이언트가 모든 정보를 다 주고 있기 때문에 어떤 서버가 받더라도 상관없이 응답을 줄 수 있기 때문이다.
    • 한계: 로그인과 같이 상태를 가지고 있어야 하는 서비스의 경우 만들 수 없다.
  • 상태 유지 프로토콜?
    • 무상태 프로토콜과 반대로 서버는 클라이언트가 이전에 보내준 상태를 알고 있다.
    • 서버가 달라지면 달라진 서버는 그전의 클라이언트가 보내준 상태를 모르기 때문에 서버 증설이 불가능하다.
    • 아니면 서버가 달라질 때 서버들끼리 상태 정보를 주고받아야 한다.
• 서버와 연결을 유지하는 모델과 서버와 연결을 유지하지 않는 모델로 나눠진다.
  • 서버와 연결을 유지하는 모델(Connection Oriented)
    • TCP/IP는 연결을 유지한다. 비록, 서버와 클라이언트가 정보를 보내지 않더라도 연결은 계속 유지된다.
    • 서버의 자원이 계속 소모된다는 단점이 있다.
  • 서버와 연결을 유지하지 않는 모델(Connectionless)
    • 요청을 주고받고 나면 TCP/IP 연결을 끊어버린다.
    • 서버의 자원을 아낄 수 있다.
    • HTTP 1.0 이전에는 연결을 유지하지 않는 모델을 이용했다.
    • 1초 이하의 빠른 반응을 보여준다.
    • 클라이언트의 요청으로 서버에서 처리하는 요청의 개수는 그리 많지 않다는 것을 이용한 방법이 된다.
    • 한계
      • TCP/IP 연결을 계속 새롭게 맺어줘야 해서 3 way handshacke를 하는 시간이 계속 늘어난다.
      • 웹 브라우저에 한번 연결이 될 때 HTML이나 CSS 같은 자료를 한번 받아와서 계속 사용하면 되는데 연결을 끊어버리니 다시 다른 요청을 보낼 때 다시 받아와야 하므로 몹시 비 효율적이다.

5. HTTP의 헤더

• HTTP의 응답과 요청에는 '헤더'가 있다. 내용들은 body에 들어가지만 헤더에 정보들을 추가하여 자세한 설정을 해준다.
• 헤더의 종류
  • 표현 헤더(요청과 응답 둘 다 사용하는 헤더)
    • Content-Type: 형식
    • Content-Encoding: 압축방식
    • Content-Language: 언어
    • Content-Length: 길이
  • 요청에 사용되는 헤더
    • Referer: 이전의 웹 페이지 주소
    • User-Agent: 클라이언트의 프로그램에 대한 정보(PC인지, 모바일인지 등등)
    • Host: 도메인
    • Origin: POST 요청 시, 요청이 시작된 주소
    • Cookie: 서버로부터 받은 쿠키
    • Authorization: 인증 토큰을 서버로 보낼 때, text 형태의 토큰의 정보
  • 콘텐츠 협상에 사용되는 헤더 (당연히 요청 시에만 사용 가능)
    
    • Accept: 클라이언트가 선호하는 미디어 타입
    • Accept-Charset: 클라이언트가 선호하는 문자 인코딩
    • Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
    • Accept-Language: 클라이언트가 선호하는 언어
      • 협상 순위를 지정할 수 있다.
      • EX) Accept-Language: ko-KR;q=1, ko;q=0.9, en-US;q=0.8
      • 이처럼 선호하는 순서를 정해서 받아 올 수 없는 경우 대체할 것을 정해줄 수 있다. q=1은 생략이 가능하다.
  • 응답에 사용되는 헤더
    • Server: 요청을 처리하는 Origin 서버의 소프트웨어 정보
    • Data: 날짜
    • Location: 리디렉션에 사용될 주소
    • Allow: 허용 가능한 HTTP 메서드(GET, HEAD 같은 거)
    • Set-Cookie: 브라우저가 서버로 보낼 쿠키
    • Rety-After: 다음 요청을 보낼 수 있을 때까지 기다려야 할 대기시간.

6. 캐시

• 서버에서 데이터를 받아 가져올 때 자주 사용하는 데이터의 전달 비용을 줄이기 위해 사용하는 작고 중요한 저장공간.
• 브라우저에 캐시가 저장될 때 헤더에 'cache-control'로 캐시의 유효시간을 정할 수 있다.
• 유효시간이 지난 캐시는 버려지고, 다시 렌더링 하여 가져온다.
• 유효기간이 지난 캐시를 다시 받아 왔는데 이전의 캐시와 똑같은 정보일 경우
  • Last-Modified를 통한 구분 
    • 헤더의 Last-Modified에는 받아온 캐시의 수정된 날짜가 적혀있다.
    • 유효기간이 지난 캐시의 Last-Modified 가 다시 받아올 캐시의 유효기간과 변함이 없다면 작은 용량의 헤더 정보만을 받아와 확인하고 용량이 상대적으로 큰 body는 받아오지 않고, 이전에 있던 캐시를 그대로 사용하면 된다.
    • 이때 HTTP 304 Not Modified로 상태 코드를 준다.
    • 단점
      • 1초 미만의 단위 사용 불가능
      • 오직 날짜로만 구분 가능
  • ETag
    • 캐시 데이터에 태그를 달아서, 태그가 다르면 받아오고 똑같으면 이전의 캐시를 사용한다.
    • 캐시를 주는 과정을 모두 서버에서 관리하게 된다. 클라이언트는 그저 태그를 확인하기만 한다.
    • 서버에서 사용하는 캐시 지시어
      • Cache-Control: max-age: 캐시의 유효기간
      • Cache-Control: no-cache: 캐싱한 데이터를 Origin 서버에서 검증한 후 사용
      • Cache-Control: no-store: 캐시를 메모리에서만 사용한 후 바로 삭제
• 프락시 캐시(Proxy Cache)
  • 프락시 서버? : 클라이언트가 서버에 접속할 때, 중간에 프록시 서버를 거쳐서 우회를 돕는 서버
  • 다양한 클라이언트가 프락시 서버를 이용해 데이터를 요청, 응답 받으면 캐시도 프록시 서버에 저장된다. 그렇게 되면 다른 클라이언트들은 그 저장된 캐시를 이용해 더 좋은 경험을 얻게 되는 것이다.
  • 이것이 프록시 캐시가 된다.
  • 프록시 캐시의 지시어
    • Cache-Control: public: public 응답이 public으로 저장
    • Cache-Control: private: public에 저장하지 않고, private 캐시에 저장되어 본인만 사용
    • Cache-Control: s-maxage: 프록시 캐시 버전의 max-age
    • Age: 초(HTTP 헤더): Origin서버의 응답 이후, 프록시 캐시에서 대기한 시간
• 캐시 무효화
  • 웹 브라우저는 캐싱을 마음대로 할 수 있다. 하지만 이것을 막을 수 도 있다.
  • 캐시 지시어
    • Cache-Control: no-cache: 캐싱 한 데이터를 Origin 서버에서 검증한 후 사용
      • 원 서버에 접속할 수 없게 되면 이전의 데이터를 다시 보여주게 됨.
    • Cache-Control: no-store: 캐시를 메모리에서만 사용한 후 바로 삭제
    • Cache-Control: must-revalidate: 캐시의 유효기간이 끝나면 Origin 서버에서 검증한 후 캐시를 받아옴
      • 원 서버에 접속할 수 없게 되면 무조건 504 Gateway Timeout 에러를 보여주게 됨.
      • 그러므로, 정말 중요한 정보(은행 업무 등)에 관련한 정보를 보호할 때 사용하면 됨.
    • Pragma: no-cache: HTTP 1.0에서 사용했던 지시어. 말 그대로 캐싱을 하지 않게 함
  • 위의 모든 지시어를 다 사용하면 캐싱을 막을 수 있다. 보안에 민감한 정보가 있을 때 사용한다.

1. 문제의 발단

• 요즘에는 컴퓨터를 구입할 때 자신에게 맞는 조건의 부품들을 구입하여 직접 조립하는 경우가 많다.
• 이미 견적이 나와있는 조립이 된 컴퓨터를 삼성이나 엘지에서 사는 것도 좋지만, 직접 하나하나 맞추는 경우가 더 저렴하고 원하는 경우 더 필요한 부품에 견적을 조금 더 두고 쓰임에 따라 만드는 데스크톱도 좋다.
• 그래서 어떤 하드웨어가 어떤 일을 하는지 알면 더욱 도움이 될 것이라고 생각하고 그것에 대해 정리하게 되었다.

2. SSD

• 무엇이 SSD이고, 무엇이 HDD와 다른가요?
  • Solid State Drive를 줄인 것이다.
  • Hard Disk Drive(HDD)보다 빠르게 동작하며 요즘 컴퓨터에는 HDD 대신 다 들어가 있다.
  • HDD는 뜯어보면 CD 디스크처럼 생긴 '플래터'에 정보를 기록했다가, 축음기 처럼 생긴 '헤드'의 핀이 직접 움직이면서 정보를 읽어 들인다. 이처럼 물리적으로 움직이기 때문에 정보를 읽는데 한계가 존제한다.
  • SSD는 내부에서 전자적인 방식으로 동작하기 때문에 정보를 읽는데 한계가 물리적일 때 보다 적다.
• SSD의 장단점
  • 장점 1: HDD보다 매우 빠르다.
  • 장점 2: 물리적 충격에 강하다. 물리적인 움직임이 없기 때문이다.
  • 장점 3: 병렬로 데이터를 처리하기 쉽다. HDD의 경우 헤드가 직접 움직이기 때문에 하나의 HDD가 하나의 데이터를 읽어야 하는 반면, 전자적 신호로 여러 개로 나누어 병렬적 처리가 가능하다.
  • 장점 4: 크기도 작고 매우 가볍다. 역시나 물리적인 부분이 없기 때문이다. 하지만 HDD의 대체품으로 SSD는 발전해 왔기 때문에 HDD가 사용하던 위치와 선등을 이용하려고 하다 보니 사이즈가 큰 차이가 없어 보이기도 한다. 하지만 사실은 더 작게 만들 수 있고, 지금은 HDD보다 더 많이 사용하기 때문에, SSD의 자리가 따로 있고 작은 사이즈로 만들어 더 많은 SSD를 달아서 사용한다.
  • 단점 1: SSD안에 보이는 검은색 칩을 'NAND Flash'라고 하는데, 이는 블록으로 구성되어 안에는 여러 개의 페이지로 이루어져 있다. 이때, 하나의 페이지라도 동작하지 않으면 이를 '배드 블록'이라고 한다. 데이터는 블록에 FTL(Flash Traslation Layer)을 통해서 SSD가 사용할 수 있는 형태로 만들어 저장된다. 이때, 한번 사용된 블록을 동일한 데이터는 다시 사용할 수 없기 때문에 데이터가 업데이트되면 새로운 블록에 저장하게 된다. 그래서 블록의 수명이 다 하게 되면, 배드 블록이 된다.
    • 만약, 수명이 다 되면 그 데이터는 어떻게 하죠? : SSD를 사용할 때, SSD의 용량보다 컴퓨터가 읽어 들이는 용량에는 차이가 조금 있는것을 알 수 있다. (예를들어 256GB SSD를 사용할때 컴퓨터가 진짜 인식하는 용량은 230GB 정도로 표시된다. 혹은 용량의 단위를 다르게 써놓는 경우도 있다) 이는 사기당한 것이 아니라, 만약 배드 블록이 발생했을 때 대체할 수 있는 블록을 남은 공간에 두는 것이다. 이를 OP영역(Over Provisioning)이라고 하고, 배드 블록을 관리한다.
  • 단점 2: 쓰기나 읽기의 방해를 받을 수 있다. 자주 사용되는 파일이 저장되어있는 블록이 자주 사용되므로 분명 다른 블록들 보다 전압이 많이 가해진다. 그렇다면 그 옆에 있는 다른 블록들에게는 전압이 가해지지 않았지만 영향을 받을 수 있기 때문이다. 그렇다면 당연히 영향을 받은 블록은 데이터에 손상이 있을 것이다.
  • 단점 3: 리텐션 에러가 일어난다. 자주 사용하지 않은 전자들은 사라지기도 한다. HHD 같은 경우 물리적 방식이기 때문에 부숴버리지 않는 이상 데이터에 손상이 갈 일이 없지만, SSD는 전자를 잃으면 그대로 데이터의 손상이 있게 된다. 이는 모든 반도체의 특성과 같다.
• 하지만 모든 단점을 다 씹어 버릴 만큼 SSD는 빠르고 좋고 각각의 단점들도 과학의 발전으로 잘 잡히고 있기 때문에 우리 모두 SSD를 쓰자!

3. 그래픽 카드

• 그래픽 카드?
  • 컴퓨터 하드의 꽃이다. 영상과 같은 모든 작업에 중요한 하드웨어다.
• 내장 그래픽 카드
  
  • CPU 자체에 달려있는 그래픽 카드로 대부분의 사무용 컴퓨터에서 사용하는 정도이다.
  • 정말 최소한의 작업들을 할 수 있으며 따로 떼어서 업그레이드는 불가능하다.
  • 요즘에는 이것조차도 좋아져서 할 수 있는 작업들이 늘어나고 있다.
• 외장 그래픽 카드
  • 우리가 사용하는 그 그래픽 카드이다.
  • 그림을 그리거나, 고사양 게임을 하는 데 사용한다.
  • 업그레이드도 가능하고 CPU보다 더 비싼 경우도 종종...? 요즘엔 자주 있다.
• CPU vs 그래픽 카드
  • CPU보다 더 수학적이고 논리적인 계산을 그래픽카드는 더 잘한다.
  • 그저 영상을 보여주는 장치라고 생각할 수 있지만 그것도 다 계산된 것이라고 생각하면 편하다.
  • 그래서 코어가 엄청나게 많이 달려있다. 논리적인 계산을 위한 코어이지만 CPU보다 1000배는 더 달려있다.
  • CPU가 해줘야 할 일들이지만, 단순한 작업은 그래픽 카드가 도와주는 것이다. CPU는 하는 일이 많기 때문이다.
  • 그래서 움직이는 선과 점을 읽고 계산하여 그 움직임을 표현하는데 더욱 뛰어나서 그래픽 작업에 유리한 것이다.
• 그래픽 카드와 대화하는 법
  • 우리가 게임할 때 사용하는 DirectX나 Nvidia의 CUDA 등이 그래픽카 등 와 대화는 소통수단이다.
  • 사용자에게 그래픽 카드를 이용해 다양한 작업을 할 수 있게 해 준다.
• 그렇다면 왜 이렇게 그래픽 카드가 비싸졌죠?
  • '가상화폐 채굴'이 엄청난 열풍을 몰고 오면서 그래픽 카드의 가격이 천정부지로 올랐다.
  • 가상화폐를 채굴할 때는  해쉬 연산을 하여서 블록체인의 연산을 하게 되는데, CPU보다 더 효과적으로 수많은 코어들을 이용해 그래픽 카드는 해쉬값을 찾을 수 있다. 이를 '마이닝'이라고 하고 코어만 있다면 다른 계산들과 독립적이기 때문에 돌릴 수 있는 코어가 있다면 바로 해쉬값을 찾을 수 있는 그래픽 카드가 많이 사용되었다.

4. RAM

• Random Access Memory를 줄인 것이다.
• 왜 사용하나요?
  
  • 메모리 내부에서 주소를 아무 곳이나 이동할 수 있다. 예를 들어, 옛날에 사용하던 CD 플레이어를 생각해 보자. 순서대로 다음 노래, 그 전 노래를 재생할 수는 있어도 갑자기 1번 트렉에서 5번 트렉을 재생시킬 수 없다. 램은 이것을 가능하게 한다.
• 휘발성 메모리?
  • 램은 컴퓨터가 꺼지면 메모리가 사라진다. 그래서 계속 전기적 신호를 주고받아서 계속 쓰는 정보는 저장하고 있다. 그래서 휘발성 메모리다.
• 그래서 어떻게 동작 하나요?
  • 하드디스크는 거대한 저장장치이다. 하지만 느리다. 그 하드디스크의 데이터를 시간적 지역성과 공간적 지역성을 통해 중요하고 자주 사용하는 정보를 가지고 있다가 CPU에게 전달하는 역할을 한다.
  • 만약 CPU를 렘 용량만큼 달아 버린다면? 정말 최고의 컴퓨터가 될 수 있겠지만 가격도 최고가 될 것이다. 일반적 사용자들은 램을 사용해 하드디스크와 CPU의 사이에서 적절한 가격으로 빠르게 데이터를 처리할 수 있게 해주는 것이다.
  • 즉, 램이 커질수록 CPU와 하드디스크 간의 소통을 도와주기 때문에 클수록 빨라지고, 두 개의 채널을 동시에 사용하는 '듀얼 채널' 램을 사용한다면, 독립적으로 한 번에 처리할 수 있는 데이터 양이 커지기 때문에, 큰 용량의 램을 하나 사용하는 것보다, 절반의 용량의 램을 두개 사용하는 것이 더 유리하기 때문에 더 빠른 처리속도를 가질 수 있을 것이다.

5. CPU

•  가장 중요한 컴퓨터의 '뇌'이다.
• Centeral Processing Unit을 줄인 것이다.
• 코어?
  • 쉽게 말하면 일꾼이다. 코어가 많으면? 그만큼 동시에 작업을 할 수 있는 일들이 많아지게 될 것이다.
  • 그렇다고 코어가 하나라면 작업을 못하는 것은 아니다. 동시에 일을 처리할 수는 없지만 빠른 속도만 있다면 빠르게 하나하나 명령의 순서에 따라 작업 시작하고 끝낸 후 다음 작업을 처리할 수 도 있다.
• 스레드?
  
  • 코어안에 분기를 나눠 놓은 것이다.
  • 코어가 하나지만, 데이터의 분기를 나누어 사용하기 때문에 더 유리하다. 예를 들어, 2차선 도로보다 4차선 도로가 통행량을 더 많이 받을 수 있는 것과 같다.
• 스레드의 역설
  • 분명, 코어에 스레드가 많으면 데이터 처리를 더 효율적으로 할 수 있다.
  • 하지만 만약 돌리려는 프로그램이 크면, 그것을 분기를 나눠 데이터를 처리하는 것보다 강력한 한 개의 코어의 스레드로 처리하는 것이 더 사용자에게는 더 빠르게 처리할 수 있게 될 것이다.
  • 예를 들어, 고속도로를 사용한다고 생각할 수 있겠다. 많은 차가 몰리면 차는 막힐 수 있겠지만, 최대 속도가 2차선 도로나 4차선 도로보다 높기 때문에 더 빠르게 처리할 수 있는 것이다.
  • 하지만 차가 클수록 높은 속도를 내기는 힘든 법. 프로그램도 마찬가지로 코어나 스레드에 맞게 어떠한 상황에서도 사용할 수 있는 적절한 코딩이 되어 있어야 다양한 환경에서도 똑바로 사용할 수 있을 것이다.

1. 문제의 발단

• 우리는 일어나서 컴퓨터를 켜고, 잠들기 5분 전까지 휴대폰을 본다. (그러지 마세요. 수면 건강에 나쁩니다)
• 그렇다면, 우리를 위해서 이렇게 열심히 일 해주는 기기들이 어떻게 일을 하는지 조금은 알고 이해해줄 필요가 있을 것이다.
• 사실, 그것보다는 확실히 알고 더 잘 부려먹기 위함이 아닐까...?

2. 프로그램, 프로세스 그리고 스레드

• 프로그램 : 평소에 많이 접하던. exe로 확장자명이 된 파일들이다. 파일들의 정보로 특정한 작업들을 할 수 있다.
• 프로세스 : 프로그램이 실행되어서 컴퓨터에서 작업 중인 그 상태. 이때 작업하는 방식에 따라 동시성, 병렬성으로 나눌 수 있다.
• 스레드 : 프로세스 안에서도 동시에 여러 가지 작업들이 동시에 진행되어야 할 때, 그 각각의 일들이 스레드로 진행되는 것이다.
  • 멀티 스레드?: 여러 가지 스레드가 동시에 진행된다. 이때는 전역 변수의 공간이나 동적으로 따로 할당된 Heap의 공간을 이용하여 작업을 진행하게 된다. 자연스럽게 프로세스 간의 통신보다 여러 스레드로 나눠 작업을 했을 때 처리량도 높고, 응답 시간도 줄어든다. 그래서 프로세스를 여러 개 만들어서 사용할 때 보다 스레드를 나눠 작업하는 것이 더 유리하다.
  • 물론 단점도 있다. Heap영역을 여러 스레드들이 공유하기 때문에, 동시에 스레드들이 같은 데이터에 접근을 하려고 하는 등의 상황이 있으면 결과에 영향을 미칠 수 있다. 그래서 작업의 순서를 정확히 해주는 '동기화' 작업이 필요하다.

3. 동시성과 병렬성

• 동시성 : 하나의 프로세스의 코어에 스레드가 각각의 작업을 한 번에 하나씩 조금씩 하면서 각각의 작업을 넘어 다니면서 하게 된다. 이때, 각각의 작업들을 뛰어넘는 것을 'Context Switching'이라고 한다. 이는 몹시 빠르게 여러 작업들을 처리하기 때문에 여러 가지 작업들이 동시에 처리되는 것처럼 보인다.
• 병렬성 : 하나의 프로세스에 코어가 여러 개 있어서 그 각각의 코어들이 스레드가 되고, 그들이 한꺼번에 각각의 작업들을 하게 된다. 컴퓨터의 CPU가 물리적인 문제로(발열 등) 발전에 한계치가 있으니까 그것을 넘어서 더 빠르게 작업들을 처리하려고 하다 보니 여러 개의  코어를 달아 버린 것이다.

4. 자바스크립트(v8) 엔진의 특징

• v8 엔진? : 구글에서 개발한 오픈소스. 크롬이나 Node.js에서 사용하는 엔진이며, 자바스크립트 코드를 컴퓨터의 CPU가(정확히 말하면 마이크로 프로세서. 이들이 모여서 CPU가 된다) 알아들을 수 있도록 더 간단하게 만들어 주는 일을 하는 것이다.
• 어떤 원리로 작동하길래 v8엔진이 좋다고 하나요?
  
  • 인터프리터 : 코드를 한 줄 한 줄 바로바로 기계어로 변환한다.
    • 장점: 속도가 빠르다. 바로 바로 나오니까 사용자 경험이 좋다.
    • 단점: 코드가 복잡해지면 점점 느려진다.
  • 컴파일러 : 코드의 전체를 읽고 기계어로 변환한다.
    • 장점: 최적화로 인해서 코드가 복잡해도 괜찮다.
    • 단점: 바로바로 결과가 나오지 않기 때문에 초기에 속도가 느리다.
  • 이때, v8엔진은 JIT(Just In Time) 컴파일러로 이 둘을 같이 사용한다.
    • 처음 코드를 보면 인터프리터에 전달해 코드를 한 줄씩 읽는다.
    • 읽으면서 최적화가 가능한 부분이 있으면 컴파일러로 넘겨 바로 최적화하며 읽는다.
  • 이렇게 둘의 장점을 동시에 사용하여 효율적으로 작업하게 된다.

5. 유니코드

• 컴퓨터가 문자열을 읽는 원리
  1. 특정 문자를 누르면 전압의 차이로 0과 1로 표현된다. 즉, 2진수이다.
  2. 이때 하나의 0과 1이 1bit 씩 8개가 모여 8 bits가 되면 이를 1byte라고 한다.
  3. 이 1byte가 컴퓨터가 문자열을 받아들이는 최소 단위가 된다.
  4. 2의 8승인 255개 즉, 0부터 255이니까 총 256개의 데이터를 표현할 수 있게 된다.
• 아스키코드
  • American Standard Code for Information Interchange의 줄임말이다.
  • 말 그대로 영어를 위한 문자 인코딩이다.
  • 컴퓨터가 문자열을 읽는 원리를 생각해보면, 특정 문자가 눌러졌을 때, bit로 표현된 숫자를 컴퓨터가 읽어서 아스키코드 표에서 찾아서 우리에게 문자로 보여주게 된다. 물론, 숫자 그대로도 보여줄 수 있다.
  • 아스키코드표에는 영어권 사람들을 위한 언어만 들어 있다. 만약, 영어 말고 다른 문자를 컴퓨터가 읽게 하기 위해서는 어떻게 해야 할까?
• 그래서, 전 세계 모든 언어들을 다 표현할 수 있도록 만든 표를 '유니코드'라고 하는 것이다.
• 하지만 언제 어떤 상황에 몇 byte로 맞게 읽어야 할까? 를 약속해 놓는 것이 '인코딩'이다. 이 방법을 문자를 저장해 줄 때 같이 보내줘야 똑바로 컴퓨터가 헷갈리지 않고 읽을 수 있게 된다.
• UTF-8 vs UTF-16
  • UTF는 Universal Coded Character Srt + Transformation을 줄인 것으로 뒤에 오는 숫자는 bit를 말한다.
  • 이것도 역시나 문자 인코딩 방법 중 하나이다.
  • 웹에서는 대부분 UTF-8을 이용한다.

6. 비트맵과 백터

• 갑자기 웬 이미지...?라고 생각할 수 있지만 이것도 컴퓨터가 이미지를 읽는 방식이므로 알아 두면 또 좋다.
• 비트맵 : 픽셀 기반 즉, 아주 작은 점들이 모여 만든 이미지이다. 파일 크기가 크며, jpg, gif, png 등의 형식을 가진다.
  • 장점: 사진처럼 다양한 색깔의 표현이 가능하다.
  • 단점: 확대나 축소에 매우 취약하다.
• 백터 : 점과 선으로 이루어진 이미지이다. 파일의 크기가 작고, 비트맵 형식으로 변환도 자유로운 편이다. 그래서 로고와 일러스트의 재작에 많이 쓰인다. svg 등의 형식을 가진다.
  • 장점: 확대 축소에 영향을 받지 않는다. 
  • 단점: 사진과 같은 정교한 색들의 표현은 한계가 있다.

7. 운영체제

• 컴퓨터 즉, 하드웨어들과 사용자 사이에 중계를 해주는 역할을 한다.
• 운영체제가 없는 상황, 가끔 컴퓨터에 고장 나서 운영체제 선택이 안 되는 경우가 있다. 그럴 경우를 생각해 보자. 운영체제 없이 컴퓨터를 사용하려고 할 수도 있기는 하지만(현실적으로는 거의 불가능) 직접 선을 갈아 끼우는 등 하드웨어를 조종하여 사용을 할 수는 있겠지만 너무 힘들 것이다.
• 이때, 직접 하드웨어를 조종하지 않아도 운영체제가 중간에서 둘의 대화를 물리적이지 않은 방법으로 도와줄 수 있다.
• 컴퓨터 시스템의 처리 구조
  1. 유저가 필요한 작업을 요청한다.
  2. 응용프로그램이 작동하여 유저의 작업을 받아들이고 처리하려고 한다.
  3. 운영체제를 거쳐서
  4. 하드웨어가 직접 작업을 실행한다.
  5. 나온 결과들을 반대로 전달하면서 상호작용한다.

8. 가비지 컬렉션

• 메모리에 필요 없는 자료들을 알아서 지워줘서 메모리 공간을 확보해 준다.
• C언어와 같이 옛날에 쓰던 언어들에서는 가비지 컬렉션이 없다. 그럴 때는 메모리 누수가 생긴다.
  • 메모리 누수(memory leak): 코드를 짤 때, 비워줘야 할 공간을 실수로 안 비워줬을 때, 계속 쌓이게 되는 상황. 이는 피할 수 없다. 아무리 완벽하게 짠다고 해도 인간이 짠 코드이기 때문에 누수가 생길 수밖에 없다.
• 하지만 상대적으로 최신의 언어들은 가비지 컬렉션이 이를 돕는다.

9. 가비지 컬렉션의 동작 원리

• Mark-and-sweep : root와 연결되어 있는 변수들을 체크하고 나머지 체크되지 않은 변수를 다 지운다.
• Reference counting: 각 변수들이 다른 변수들과 참조가 몇 번이 되는지를 계산해서 그 참조 횟수가 0이라면 지운다.
• 하지만 그래도 완벽하게 메모리를 관리하지는 못 한다. 계발 환경에 따라 작동하는 방식이나 필요 없는 데이터들이 달라지기 때문이다.
• 그래도 최대한 가비지 컬렉션이 잘 작동하게 하려면? 
  • 순환 참조 금지: 각각의 변수들이 서로를 참조하고 있다면 참조 횟수는 0이 될 수가 없게 된다.
  • 언어들 마다 각각의 누수 잡는 방법 알아 놓기: 언어들마다 누수를 잡는 방법이 존재한다. 이를 알고 알맞은 상황에 맞게 사용하여 누수를 막을 수 있다.

10. 캐시

• 가져오는데 비용이 많이드는 사용빈도가 높은 데이터를 비용을 줄이기 위해 사용하기 편한 저장공간을 '캐시'라고 한다.
• 웹 상황에서는 데이터 베이스에 저장된 정보를 매번 사용자가 요청할 때마다 가지고 올 때 비용이 발생하므로, 자주 방문하는 데이터들을 캐시에 저장해 놓으면 그 비용을 줄 일 수 있다.
• 로컬 상황에서는 하드디스크에 저장된 정보를 매번 사용자가 요청할 때마다 가지고 올 때 비용이 발생하므로, 자주 사용하는 데이터를 램에 저장해 놓으면 그 비용을 줄일 수 있다. 하지만 램은 용량은 적은데 비싸기도 하다. 그래서 더 비용을 줄이고 더 자주 사용하는 작은 데이터들은 캐시 메모리에 저장해 놓아서 그 비용을 줄 일 수 있다.
• 결론은 캐시에는 아주 작고, 자주 사용하는 중요한 데이터들을 저장하여 비용을 줄이기 위해 존제한다고 정리할 수 있겠다.