1. 문제의 발단

• 만드는 것만큼 배포도 중요하다.
• 내 불쌍한 컴퓨터로 서버를 돌리는 것은 너무하다.
• 그래서 우리는 돈을 주고 안 보이는 서버를 사서 사용할 수 있다!

2. AWS

• Amazon Web Services를 줄인 것이다.
• 개인의 온 프레미스 환경(직접 컴퓨터에 서버를 열어 관리함)의 서버는 많은 응답을 처리하기 위해 수많은 비용과 인력이 엄청나게 들어간다.
• 그것을 대신 클라우드 서비스를 이용해 대신 가상의 컴퓨터로 대신 서버를 관리해주는 서비스이다.

3. 클라우드 서비스의 종류

1. SaaS(Software as a Service): 네트워크, 하드웨어, 운영체제, 플랫폼/데이터베이스, 어플리케이션을 제공함
2. PaaS(Platform as a Service): 네트워크, 하드웨어, 운영체제, 플렛폼/데이터 베이스를 제공함
3. IaaS(Infrastructure as a Service): 네트워크, 하드웨어를 제공함

4. AWS가 하는 서비스

 EC2(Elastic Compute Cloud)

• 가상의 컴퓨터를 제공한다.
• 나처럼 우분투와 씨름하지 않고 클릭 몇 번으로 OS가 완벽하게 돌아가는 컴퓨터를 사용할 수 있게 된다.

 RDS(Relational Database Service)

• 데이터베이스를 내가 관리할 필요 없이 대신 만들고 관리해준다.
• 규모를 확장시키기도 편하고, 내구성도 완벽하며, 데이터도 안전하다. 백업도 쉽게 가능하다.

S3(Simple Storage Service)

• 우리가 자주 사용하는 네이버 클라우드, OneDrive같은 클라우드 서비스라고 생각하면 편하다.
• 역시나 데이터를 무한하게 저장할 수 있으며, 매우 안전하게 보관된다.
• AWS는 이러한 서비스를 제공하기 위해서 전 세계에 각국, 각 도시에 진짜 서버를 가지고 있다. 그 장소를 '리전(Region)'이라고 하고, 그렇기 때문에 이러한 서비스를 전 세계인에게 제공할 수 있게 된다.

5. 그래서 어떻게 배포할까요?

1. EC2를 이용해 인스턴스를 생성한다.
   • '프리티어 사용가능' 이라고 적힌 인스턴스는 돈이 들지 않는다. 연습용으로 사용하자.
   • 인스턴스 유형(CPU나 램 등)도 프리티어가 있는 것을 선택하자.
   • 원격으로 인스턴스에 접속해서 조작할 것이기 때문에 'Key'를 생성하게 된다. 'SSH 프로토콜'로 '.pem' 확장자인 파일을 이용해 조작 권한을 얻을 수 있다.
2. EC2로 생성한 인스턴스를 로컬에 연결한다.
   • 아까 만든 인스턴스를 클릭하고 우측 상단에 '연결'을 눌러 준비한다.
   • SSH접속을 하기 위해 pem키의 권한을 수정한다. 'chmod 400' 명령어(복사할 수 있게 되어 있다)로 소유자 만이 읽기 권한 만을 소유자에게 부여한다.
   • ssh 명령어(ssh -i"키 이름"사용자 이름(OS 이름이 될 것이다)@가상 PC 주소)로 가상 PC와 로컬 상황이 연결되어서 사용할 수 있게 되었다.
3. EC2로 생성하고 연결한 가상 PC를 세팅한다.
   • 가상 PC는 방금 포맷하고 나온 컴퓨터 마냥 깨끗하다. nvm과 node.js를 설치해 주자.
   • VS Code를 다운로드한다던지 하는 이상한 짓은 하지 말자. 그래픽은 지원해 주지 않는다. 깔리기는 한다. 하지만 볼 수 없을 것이다. 볼 수 있는 부분은 CLI상황인 '터미널' 뿐이다.
   • 서버도 실행시켜 보자. 물론, 접속은 아직 안된다.
4. EC2로 생성하고 연결한 가상 PC의 보안 그룹(Security Group)의 설정을 바꿔준다.
   • 들어오는 트래픽은 '인바운드', 나가는 트래픽은 '아웃바운드'라고 한다.
   • 아웃바운드 규칙은 상관없다. 나가는 트래픽을 막을 필요가 없다. 이미 모든 규칙이 허용되고 있을 것이다.
   • 인바운드 규칙이 중요하다. 그러므로 권한을 수정해서 우리의 요청을 받아 줄 수 있게 만들자.
   • 인스턴스에 설정되어 있는 보안 그룹으로 가서 인바운드 규칙을 추가한다. 설정한 포드 번호를 설정해 주고 어떤 프로토콜, 소스(IP)를 허용할 것인지를 설정한다.
   • 혼자서 연습할 때는 모든 접속을 허용하면 된다. 나 아니면 들어올 사람이 없다.
   • 원래 각각 클라이언트, 서버, 데이터 베이스가 사용하는 지정된 포트번호가 있다. 예를들어, http는 80번, https는 443번, 데이터 베이스는 3306번이다. 이러한 몇가지 지정된 포트번호가 있기 때문에 이러한 포트 번호를 설정해 주면 될 것이다.
5. PM2를 설치해 백그라운드에서 서버가 실행된 상태로 존재하게 만든다.
   •  관리자 권한으로 실행시켜야 한다. 그러기 위해서 'authbind'를 설치해야 한다.
   • 만약, 그전에 서버를 켜서 프로세스가 이미 존 제한 다면 'pm2 ls'로 확인하고 있다면 지워라. authbind가 설치되고 난 후에 다시 authbind를 이용해 서버를 실행시켜야 관리자 권한이 있는 프로세스가 생긴다.
6. S3를 이용해 호스팅 한다.
   • 정적 웹 페이지를 빌드(build)한다.
   • 내 로컬 상황에서 .env파일을 열어서 환경변수를 수정한다. 꼭 http://나 https://를 포함한 주소 'ec2로 생성한 퍼블릭 IPv4 DNS 주소'를 적어줘야 하고, 마지막에 '/'는 넣어서는 안 된다.
   • 이후 npm run build 명령어로 build폴더를 만들어 놓는다.
   • S3에서 버킷을 만들어 정적 웹 사이트의 호스팅을 활성화한다. 이때, '인덱스 문서'와 '오류 문서'에 index.html을 입력해 준다. 안 하면 접속 안된다.
   • 만든 버킷에 객체를 업로드한다. 아까 만들어 놓은 build 폴더 안에 있는 내용물들을 업로드하면 된다. build 폴더 자체를 업로드 하면 안 된다. 안의 내용물만 업로드한다.
   • 권한 탭에서 퍼블릭 액세스 차단을 전부 푼다. 권한도 생성기로 만들어서 알맞게 넣어준다.
7. RDS로 DB 생성해서 서버와 연결한다.
   • RDS로 가서 데이터베이스를 생성한다.
   • 제발 마스터 암호 좀 쉬운 걸로 해라. 계속 틀리지 말고. 아직은 연습 단계이다.
   • 이후, 로컬 상황에서 알맞은 클라이언트(나는 mySql을 이용했다)로 DB 인스턴스에 접속한다.
   • 만약, 명령어를 입력하고 한참 아무런 반응이 없는 상황이 나온다면, 보안 그룹을 확인하자. 이것도 마찬가지 아까 인바운드 설정을 바꿔준 보안 그룹의 설정으로 바꿔줘야 한다. 아니면 한참 이후 오류 메시지를 볼 수 있다.
   • 이것도 위의 정해진 포트 번호라면 3306을 열어 놔야 할 것이다.
   • 데이터베이스에 연결된 후 만든 database를 확인한다.
8. EC2로 만든 가상 컴퓨터에 환경변수 설정을 한다.
   • 먼저 서버 끄고 시작한다.
   • nano나 vim으로 직접 수정한다.
   • 좀 전에 RDS로 만든 데이터 베이스를 보면서 HOST에 데이터 베이스의 엔드포인트, USER, PASSWORD, PORT까지 알 맞게 설정한다.

6. HTTPS 설정 하기

1. 도메인을 만든다. 잘 찾아보면 무료로 도메인을 만들어 주는 곳도 있다! 아니면 과금해 보는 것도 좋은 경험이 되지 않을까?
2. S3부분(작은 번호 6번)을 보고 다시 버킷을 만들어 준다. 이 부분은 거의 똑같다.
   • 빌드할 때 굳이 build 폴더를 삭제하고 하지 않아도 된다. npm run build 하면 매번 build 폴더는 삭제되고 다시 만들어진다.
   • 빌드를 새롭게 했다면 당연히 서버도 다시 껐다 켜줘야 한다.
3. Route53으로 DNS를 설정한다.
   • 네임 서버 리스트를 도메인을 받은 사이트에 등록한다.
   • 라우팅 설정할 때 꼭 리전을 '미국 동부(버지니아 북부)'로 해야 한다.
   • CloudFront의 도메인 주소를 확인해서 잘 넣고, 사용할 주소 개수만큼 레코드를 정의한다.
4. AWS Certificatuon을 이용해 인증서를 받아 적용한다.
   • AWS Certificatuon에 접속하자마자 리전을 '미국 동부(버지니아 북부)'로 바꿔준다. 그 이후 인증서를 요청해야 한다.
   • 인증은 꽤 걸린다. 가끔 새로고침을 누르면서 차분하게 기다린다. 다 발급이 완료된 후에 다음 단계를 할 수 있다.
5. 이제 S3에서 지원하지 않는 https 형식의 배포를 위해 CloudFront를 이용한다.
   • S3에서 받아온 URL로 스택을 생성하고 '원본 도메인 이름'에 방금 만든 버킷의 정적 웹사이트 주소를 넣어준다.
   • CNAME에 받아온 도메인 주소들을 넣어준다.
   • 위에서 발급한 SSL 인증서를 선택해 준다.
   • React로 프로젝트를 만들었다면 에러 페이지 설정도 해준다. 404, 403 두 번 에러 페이지를 설정해 준다.

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차선 도로보다 높기 때문에 더 빠르게 처리할 수 있는 것이다.
  • 하지만 차가 클수록 높은 속도를 내기는 힘든 법. 프로그램도 마찬가지로 코어나 스레드에 맞게 어떠한 상황에서도 사용할 수 있는 적절한 코딩이 되어 있어야 다양한 환경에서도 똑바로 사용할 수 있을 것이다.