2023.08.17.목.TIL

heeh·2023년 8월 17일

TIL

목록 보기

66/82

2023.08.17.목.TIL

못 썼던 TIL 챙기기
- TIL 작성하기! → 나는 평소처럼 하면 되겠다
숙제!!!!
- 1. http://data.seoul.go.kr/dataList/OA-2271/A/1/datasetView.do 여기에 접속해서 회원 가입 및 로그인 한 후 인증키 신청하기
CS : Computer Sience → 컴퓨터 공학
- 1강 듣기 : cpu와 메모리
- https://teamsparta.notion.site/CPU-dd95341c35a54308b119efe9b4dc0dce#d311d7e5266d49fcad8764e04d760117
기술 면접 top30 1번 문제 풀기
- https://teamsparta.notion.site/Backend-top30-708284ef94b24dc485664c91aca38f34

1 강 cpu와 메모리

CPU = 푸드 트럭을 운영하는 요리사
CPU(= 요리사?)의 구성
- 우뇌 - 연산력 : 산술논리 연산장치(ALU) : 비교, 판단, 연산을 담당
- 좌뇌 - 구성력 : 제어부(CU)와 내부 버스 : 명렁어의 해석과 올바른 실행을 위해 CPU를 내부적으로 제어
- 오른손 - 레지스터 : 처리할 명령어를 저장
- 왼손 - 캐시 메모리(L1) : 처리 속도를 높여주는 역할
명령어 인출
- CU(제어부)가 수행할 명령어 정보를 가지고 오기

명령어 해독
- 명령어 정보를 성공적으로 인출 했으면 명령어를 해독
- 보통 opcode 명령어 코드를 인출하고 opcode의 성격에 맞게 레지스터 준비
실행
- 해독된 명령어를 수행
  - ex) 이것이 산술/논리 관련된 연산이라고 하면 ALU(연산장치)가 주체가 되어서 실행
반영
- 이 명령어의 수행 결과를 반영함으로써 명령어 수행의 한 사이클이 끝

CPU 스펙(CPU에서 직접적인 성능)
- CPU 속도(코어)와 CPU 코어 개수
CPU 속도 = 클럭
- 1 헤르츠로 주파수를 가지면 1초에 연산이 수행됨
- = 1 헤르츠 한 번에 연산을 의미
- ex) 4.5GHz라는 것은 초당 45억 번의 명령어를 처리할 수 있다는 뜻
- 클럭 주파수가 빠를수록 제한된 시간에 더 많은 명령을 처리할 수 있기에 더 좋은 성능의 중앙 처리 장치라고 할 수 있다.
CPU 코어 = 코어
- 싱글 코어 = 요리사 1명(CPU 1개), 멀티 코어 = 요리사 여러 명(CPU 여러 개)
HDD - RAM - CPU
- 프로그램 저장 : 보조 기억 장치
  - 하드디스크(HDD)
- 프로그램 실행 : 주 기억 장치
  - RAM
- 연산 처리 장치가 있는 CPU!
SRAM - Static RAM
- 정적 메모리
DRAM - Dynamic RAM
- 동적 메모리
- 주로 RAM(주 기억 장치)
보조 기억 장치 : 컴퓨터 전원이 꺼져도 지워지지 않는 저장 공간
하버드 구조, 폰노이만 구조
병목 현상 = 버틀넥 현상
39분부터 다시 듣기 → 기한 이틀이었따!!!!!

어렸을 때… Why 책의 컴퓨터 장르에서 봤던 기억이 새록새록

기술 면접 top30 1번 문제 풀기

https://teamsparta.notion.site/Backend-top30-708284ef94b24dc485664c91aca38f34
NoSQL과 RDBMS의 특징과 차이점에 대해서 장, 단점을 들어 설명해주세요.
NoSQL 참고 https://www.oracle.com/kr/database/nosql/what-is-nosql/

NoSQL (비관계형 데이터베이스)

스키마 유연성: NoSQL 데이터베이스는 스키마가 유연하며, 데이터 모델을 동적으로 변경할 수 있습니다. 새로운 데이터 유형을 쉽게 추가하거나 수정할 수 있습니다.
1. 스키마(Schema)? 데이터베이스에서 저장되는 데이터의 구조와 형식을 정의하는 개념*1
확장성: NoSQL은 수평 확장에 용이하며, 대용량 데이터 처리 및 분산 시스템에서 높은 성능을 발휘합니다.
비정형 데이터 지원*2: 비구조적인 데이터 형식(문서, 그래프, 열 지향 등)을 처리하는 데 뛰어난 성능을 보이며, JSON, XML 등의 데이터 형식을 지원합니다.
1. 비정형 데이터? 식별 가능한 구조나 아키텍처가 없는 데이터
CAP 이론*3: NoSQL은 Consistency(일관성), Availability(가용성), Partition Tolerance(분할 내성) 중에 두 가지만 보장하는 경우가 많습니다.
1. 분산 컴퓨팅 환경에서 세 가지 핵심 속성인 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance)을 어떻게 균형있게 유지할지에 대한 이론
강력한 읽기 및 쓰기 성능: 대량의 데이터를 빠르게 처리할 수 있는 특징을 가지며, 분산 환경에서도 높은 성능을 제공할 수 있습니다.

NoSQL 자세히 알아보기

NoSQL 데이터베이스의 유연한 스키마는 비정형 데이터 모델에 적합합니다. 다양한 유형의 데이터를 저장하거나 변화하는 데이터 모델을 처리할 때 효과적입니다. 여기에 몇 가지 예제를 보여드리겠습니다:

문서 지향 데이터: 문서 지향 데이터베이스는 JSON이나 BSON과 같은 형식으로 데이터를 저장합니다. 이러한 데이터베이스는 스키마가 유연하며, 다양한 속성과 구조를 가진 문서들을 저장하기에 적합합니다. 예를 들어, 블로그 게시물, 사용자 프로필, 제품 정보 등의 다양한 형태의 문서를 저장할 수 있습니다.
그래프 데이터: 그래프 데이터베이스는 노드(node)와 엣지(edge)를 사용하여 데이터 간의 관계를 표현합니다. 이러한 데이터 모델은 소셜 네트워크, 지식 그래프, 네트워크 시스템 등에서 유용합니다. 노드와 엣지의 속성과 관계를 동적으로 변경할 수 있는 유연한 스키마가 필요한 경우가 많습니다.
열 지향 데이터: 열 지향 데이터베이스는 테이블의 각 열(column)마다 독립적인 스키마를 가질 수 있습니다. 이는 다양한 유형의 데이터를 한 테이블에 저장하고, 필요한 열만을 조회할 수 있는 유연성을 제공합니다. 이러한 데이터베이스는 로그 데이터, 센서 데이터 등에서 활용될 수 있습니다.
키-값 데이터: 키-값 데이터베이스는 간단한 구조로, 키와 값의 쌍으로 데이터를 저장합니다. 이러한 데이터베이스는 캐싱, 세션 관리, 임시 데이터 저장 등에 적합합니다. 유연한 스키마를 가지므로 언제든지 새로운 키-값 쌍을 추가하거나 기존 값을 변경할 수 있습니다.

예를 들어, 블로그 플랫폼에서는 사용자가 다양한 속성을 가진 게시물을 작성할 수 있습니다. 이러한 경우 NoSQL 데이터베이스를 사용하면 게시물의 구조가 유연하게 변화하더라도 스키마를 재정의하거나 데이터를 재구성할 필요 없이 데이터를 저장하고 조회할 수 있습니다.

RDBMS (관계형 데이터베이스 관리 시스템)

정형 데이터 저장: 데이터는 테이블 형태로 저장되며, 각 테이블은 미리 정의된 스키마에 따라 데이터가 구조화됩니다.
ACID 트랜잭션*4: RDBMS는 Atomicity(원자성), Consistency(일관성), Isolation(격리성), Durability(지속성) 등의 트랜잭션 속성을 보장하여 데이터 무결성을 유지합니다.
SQL 쿼리 언어: RDBMS는 SQL(Structured Query Language)을 사용하여 데이터 조작, 조회, 조인 등을 수행합니다.
데이터 중복 최소화: 정규화를 통해 데이터 중복을 최소화하고 일관된 데이터 모델을 유지합니다.
관계 유지: 여러 테이블 간의 관계를 설정하고, JOIN을 통해 데이터를 연결하여 복잡한 쿼리를 수행할 수 있습니다.
일관된 데이터 모델: 데이터의 구조가 미리 정의되어 있어 데이터 일관성을 유지하며, 데이터 무결성을 강조합니다.

RDBMS 자세히 알아보기

데이터 무결성 보장: RDBMS는 ACID 트랜잭션을 통해 데이터 무결성을 보장합니다. 데이터의 정확성과 일관성을 유지하며 중복 데이터를 방지할 수 있습니다.
강력한 쿼리 언어: RDBMS는 SQL을 사용하여 데이터 조작, 조회, 조인, 집계 등 다양한 작업을 수행할 수 있습니다. 복잡한 데이터 검색과 분석이 가능합니다.
복잡한 관계 모델링: RDBMS는 다양한 테이블 간의 관계를 설정하고 관리할 수 있습니다. 복잡한 데이터 구조를 표현하기에 적합합니다.
수평 및 수직 확장: 일부 RDBMS 시스템은 수평 및 수직 확장을 지원하여 성능을 향상시킬 수 있습니다.
ACID 트랜잭션 보장: RDBMS는 ACID 트랜잭션을 통해 데이터의 무결성과 일관성을 유지하며 데이터 조작의 안정성을 보장합니다.

예제
1. 온라인 상점: 고객 정보, 제품 정보, 주문 내역을 저장하고 관리하는데 RDBMS가 적합합니다. 각각의 테이블 간에 관계를 설정하여 고객이 제품을 주문하고 주문 내역을 조회할 수 있습니다.
2. 은행 시스템: 계정 정보, 거래 내역, 이체 기록 등을 관리하기 위해 RDBMS를 사용할 수 있습니다. 각 계정과 거래 사이의 관계를 설정하여 잔액 조회, 거래 내역 검색 등을 처리할 수 있습니다.
3. 학사 관리 시스템: 학생 정보, 교수 정보, 강의 정보를 저장하고 관리하는 시스템은 RDBMS를 사용하여 구축할 수 있습니다. 학생과 교수, 강의 간의 관계를 설정하여 수강 신청, 성적 조회 등을 처리할 수 있습니다.
4. 고객 관리 시스템: 고객 정보, 연락처, 구매 이력 등을 저장하고 관리하는데 RDBMS를 활용할 수 있습니다. 각 고객과 구매 이력 간의 관계를 설정하여 고객 정보 조회, 마케팅 분석 등을 수행할 수 있습니다.
  
  이러한 예제들은 RDBMS가 다양한 업무 영역에서 데이터를 효율적으로 관리하고 조회하는 데 어떻게 활용될 수 있는지를 보여줍니다.

NoSQL과 RDBMS의 주요 차이점

데이터 모델: NoSQL은 비정형 데이터 형식에 대한 처리에 적합하며, RDBMS는 정형 데이터에 더 적합합니다.
스키마 유연성: NoSQL은 유연한 스키마를 가지며, RDBMS는 정적인 스키마를 사용합니다.
트랜잭션 및 ACID: RDBMS는 ACID 특성을 강조하여 데이터 무결성을 보장하며, NoSQL은 이를 제한적으로 지원하는 경우가 많습니다.
읽기/쓰기 성능 및 확장성: NoSQL은 대용량 데이터 처리와 확장성에 뛰어나며, RDBMS는 복잡한 JOIN 작업 등에서 강점을 보입니다.
쿼리 언어: NoSQL은 다양한 데이터베이스 유형마다 쿼리 언어가 다를 수 있습니다. RDBMS는 주로 SQL을 사용합니다.

어떤 데이터베이스 시스템을 선택할지는 프로젝트의 요구사항과 목표에 따라 다를 수 있습니다. 데이터의 구조, 크기, 조회 및 조작 패턴, 확장성 등을 고려하여 적절한 데이터베이스 유형을 선택해야 합니다.

단점

NoSQL 단점

NoSQL 데이터베이스는 많은 이점을 가지고 있지만, 몇 가지 단점도 고려해야 합니다. 아래는 NoSQL 데이터베이스의 주요 단점 몇 가지입니다:

복잡성: NoSQL 데이터베이스는 다양한 종류와 모델이 있기 때문에 선택 및 운영이 복잡할 수 있습니다. 어떤 데이터베이스가 프로젝트에 가장 적합한지 결정하기 위해서는 이들 간의 비교와 성능 평가가 필요합니다.
제한된 쿼리 언어: RDBMS에 비해 NoSQL 데이터베이스의 쿼리 언어는 제한적일 수 있습니다. NoSQL 데이터베이스 간에도 쿼리 언어와 기능이 다르며, 데이터 조작 및 분석을 제한할 수 있습니다.
데이터 일관성의 부족: 일부 NoSQL 데이터베이스는 CAP 이론에 따라 일관성을 보장하지 않는 경우가 있습니다. 이로 인해 데이터의 일관성을 보장하기 위해서는 특정 제약 조건을 희생해야 할 수 있습니다.
커뮤니티 및 도구 부족: 일부 NoSQL 데이터베이스는 상대적으로 작은 커뮤니티를 가지고 있거나, 성숙한 개발 도구와 문서화가 부족할 수 있습니다. 이는 학습 및 개발 시 어려움을 초래할 수 있습니다.
성능과 확장성의 한계: NoSQL 데이터베이스는 일부 유형에서는 빠른 성능을 보이지만, 모든 유형에서 모든 작업에 최적화되지는 않습니다. 또한 몇몇 데이터베이스는 일부 확장성 제한을 가질 수 있습니다.
데이터 무결성의 부족: 몇몇 NoSQL 데이터베이스는 ACID 트랜잭션을 지원하지 않거나, 지원하는 경우에도 일관성과 격리성을 보장하지 않을 수 있습니다. 이로 인해 데이터의 무결성을 관리하는 데 어려움이 생길 수 있습니다.
데이터 마이그레이션 및 변환 어려움: NoSQL 데이터베이스 간의 데이터 마이그레이션이나 혹은 RDBMS에서 NoSQL로의 전환 시에 데이터의 변환 작업이 어려울 수 있습니다.

이러한 단점들은 프로젝트의 요구사항과 환경에 따라 다를 수 있습니다. NoSQL 데이터베이스를 선택하기 전에 이러한 단점들을 고려하여 장단점을 평가해야 합니다.

RDBMS 단점

관계형 데이터베이스 관리 시스템(RDBMS)도 여러 이점을 가지고 있지만, 일부 단점도 고려해야 합니다. 아래는 RDBMS의 주요 단점 몇 가지입니다:

고정된 스키마: RDBMS는 정적인 스키마를 가지며, 데이터 구조를 변경하거나 새로운 데이터 필드를 추가하기 어려울 수 있습니다. 이로 인해 유연한 데이터 모델링이 어려울 수 있습니다.
수평 확장의 어려움: 전통적인 RDBMS는 수직 확장(성능 향상을 위해 더 많은 리소스 추가)에 더 적합하며, 수평 확장(분산 환경에서 서버를 추가)에는 어려움을 겪을 수 있습니다.
복잡한 JOIN 작업: 복잡한 데이터베이스 설계에서 JOIN 연산이 필요한 경우 성능 문제를 야기할 수 있습니다. 특히 대규모 데이터베이스에서 JOIN은 비용이 많이 드는 연산입니다.
대량 데이터 처리 성능 제한: 대량의 데이터를 한 번에 처리해야 하는 경우 성능 문제가 발생할 수 있습니다. 일부 작업에서는 NoSQL 데이터베이스에 비해 성능이 떨어질 수 있습니다.
ACID 트랜잭션 오버헤드: RDBMS는 ACID 트랜잭션을 보장하기 위해 오버헤드가 발생할 수 있습니다. 이는 성능에 영향을 미칠 수 있습니다.
비정형 데이터 처리 어려움: 비정형 데이터 형식(예: JSON, XML)을 다루기 어려울 수 있으며, 비정형 데이터를 저장하고 조회하기 위해 추가 작업이 필요할 수 있습니다.
비용: 몇몇 상용 RDBMS 시스템은 라이선스 비용이 많이 들 수 있으며, 하드웨어 및 유지보수 비용도 고려해야 합니다.
복제 및 백업 복잡성: 데이터베이스의 복제 및 백업 관리가 복잡할 수 있으며, 시스템의 안정성과 복원력을 유지하기 위해 추가 노력이 필요할 수 있습니다.
분산 환경 지원의 한계: 기존의 RDBMS는 대부분 중앙집중식 아키텍처로 설계되었기 때문에 분산 환경에서의 확장성과 성능이 부족할 수 있습니다.

이러한 단점들은 프로젝트의 특정 요구사항과 환경에 따라 다를 수 있습니다. RDBMS를 선택할 때는 이러한 단점들을 고려하여 장단점을 평가해야 합니다.

*

1 스키마(Schema) 스키마(Schema)는 데이터베이스에서 저장되는 데이터의 구조와 형식을 정의하는 개념입니다. 다른 말로는 데이터의 논리적인 구조라고도 할 수 있습니다. 스키마는 데이터베이스 내에 있는 테이블, 열(칼럼), 데이터 타입 등의 정보를 포함하며, 데이터베이스가 어떻게 구성되어 있는지를 정의하는 역할을 합니다. 데이터베이스의 스키마는 다음과 같은 정보를 포함할 수 있습니다:
1. 테이블 정의: 어떤 테이블들이 데이터베이스에 존재하고, 각 테이블은 어떤 칼럼들로 구성되어 있는지를 정의합니다.
2. 칼럼 데이터 타입: 각 칼럼이 어떤 데이터 타입(문자열, 숫자, 날짜 등)을 가지는지를 명시합니다.
3. 제약 조건: 데이터 무결성을 보장하기 위해 각 칼럼이나 테이블에 적용되는 제약 조건(Primary Key, Foreign Key, NOT NULL 등)을 정의합니다.
4. 인덱스: 데이터 검색 속도를 향상시키기 위해 생성되는 인덱스를 정의할 수 있습니다.
5. 기본값 설정: 칼럼이 가질 수 있는 기본값을 설정할 수 있습니다.
  
  스키마는 데이터베이스 설계 단계에서 중요한 역할을 합니다. 정확하고 일관된 스키마를 갖는 데이터베이스는 데이터의 구조와 관계를 명확하게 정의하고, 데이터 무결성을 유지하는 데 도움을 줍니다.
  
  반면에 NoSQL 데이터베이스는 스키마가 더 유연하며, 데이터의 구조가 동적으로 변경될 수 있습니다. 이로 인해 NoSQL 데이터베이스는 비정형 데이터에 더 적합한 구조를 가지고 있습니다.
테이블, key 등 DB에서 사용되는 것들을 의미하는 듯!
2 비정형 데이터 지원
- 참고 : https://www.tibco.com/ko/reference-center/what-is-unstructured-data
- 비정형 데이터는 식별 가능한 구조나 아키텍처가 없는 데이터
- 사전 정의된 데이터 모델을 따르지 않으므로 주류 관계형 데이터베이스에 적합하지 않음
- 쉽게 식별할 수 있는 구조가 없기 때문에 컴퓨터 프로그램에서 읽기가 어려움
3 CAP 이론 CAP 이론은 분산 컴퓨팅 환경에서 세 가지 핵심 속성인 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance)을 어떻게 균형있게 유지할지에 대한 이론입니다. 이 이론은 2000년에 컴퓨터 과학자인 Eric Brewer가 제안했으며, 분산 시스템에서 발생할 수 있는 제약 사항을 설명하는데 사용됩니다.
1. 일관성 (Consistency): 모든 노드에서 같은 시간에 같은 데이터를 읽거나 쓰는 것입니다. 일관성을 유지하기 위해서는 한 노드에서 데이터를 변경하면 다른 노드들도 동일한 데이터를 즉시 업데이트해야 합니다.
2. 가용성 (Availability): 모든 요청은 정상적으로 처리되어야 하며, 어떤 노드가 실패하더라도 시스템은 계속해서 응답 가능해야 합니다. 즉, 가용성을 유지하려면 모든 요청은 항상 응답을 받아야 합니다.
3. 분할 내성 (Partition Tolerance): 네트워크 분할이 발생하거나 노드간의 통신이 실패할 경우에도 시스템이 정상적으로 작동해야 합니다. 즉, 시스템은 분할된 네트워크 상황에서도 데이터의 일관성과 가용성을 유지해야 합니다.
  
  CAP 이론은 이 세 가지 속성을 모두 동시에 보장하는 것은 불가능하다고 주장합니다. 어떤 시스템은 일관성과 가용성을 우선시하며 분할 내성을 희생할 수 있고, 다른 시스템은 가용성과 분할 내성을 보장하면서 일관성을 희생할 수 있습니다. 이를 간략하게 표현하면 다음과 같습니다:
- CA: 일관성과 가용성을 모두 보장하려고 하면 분할 내성을 희생합니다.
- CP: 일관성과 분할 내성을 모두 보장하려고 하면 가용성을 희생합니다.
- AP: 가용성과 분할 내성을 보장하려고 하면 일관성을 희생합니다.
  
  CAP 이론은 분산 시스템 설계자가 시스템의 요구사항에 따라 어떤 속성을 우선시할 것인지를 결정하는데 도움을 줍니다. 각 상황에서 어떤 속성을 희생하고 어떤 속성을 유지할지는 시스템의 목표와 사용 사례에 따라 다를 수 있습니다.
ACID 트랜잭션 ACID는 데이터베이스 관리 시스템에서 트랜잭션 처리의 속성을 나타내는 약어입니다. ACID는 Atomicity(원자성), Consistency(일관성), Isolation(격리성), Durability(지속성)의 네 가지 속성을 의미합니다. 이 속성들은 데이터의 무결성과 안정성을 보장하며, 데이터베이스 내의 트랜잭션이 제대로 처리되는 것을 보장하기 위한 원칙입니다.
1. Atomicity (원자성): 트랜잭션은 원자적(Atomic) 단위로 처리되어야 합니다. 이것은 트랜잭션의 모든 작업이 성공하거나 실패할 때까지 일어나지 않는 것을 의미합니다. 트랜잭션이 중간에 실패하면 이전의 상태로 롤백되어야 합니다.
2. Consistency (일관성): 트랜잭션이 완료된 후에도 데이터베이스는 일관된 상태를 유지해야 합니다. 트랜잭션이 데이터베이스의 무결성 규칙을 위반하지 않도록 보장해야 합니다.
3. Isolation (격리성): 동시에 여러 개의 트랜잭션이 실행되더라도, 각 트랜잭션은 다른 트랜잭션의 영향을 받지 않는 독립적인 작업 단위로 처리되어야 합니다. 격리성을 보장하려면 트랜잭션 간의 상호작용을 제어하여 데이터의 일관성을 유지해야 합니다.
4. Durability (지속성): 트랜잭션이 성공적으로 완료되면 그 결과가 영구적으로 저장되어야 합니다. 시스템 또는 서버의 문제가 발생하더라도 트랜잭션이 영구적으로 반영되지 않으면 안됩니다.
  
  ACID 속성은 데이터베이스 관리 시스템이 데이터 처리 과정에서 중요한 역할을 수행하며, 특히 데이터의 무결성을 보장하고 장애나 문제 발생 시에도 안정성을 유지하는 데 도움을 줍니다.
면접에서 답변할 수 있을 정도의 길이(3~4줄)로 답변
- NoSQL은 대용량 데이터 처리와 확장성에 뛰어나고 유연한 스키마를 갖고 있어서 다양한 속성과 구조를 가진 문서들을 저장하기에 적합합니다. 하지만 다양한 만큼 많은 종류와 모델이 있기 때문에 선택 및 운영이 복잡할 수 있습니다.
- RDBMS는 SQL을 사용하여 데이터 조작, 조회, 조인, 집계 등 다양한 작업을 수행할 수 있으며 복잡한 데이터 검색과 분석이 가능한 장점이 있습니다. 하지만 정적인 스키마를 갖고 있어서 데이터 구조를 변경하거나 새로운 데이터 필드를 추가하기 어렵고 유연한 데이터 모델링이 거의 불가능합니다.
3~4줄로 줄이면서 포인트를 잘 적어 주었고, 모르는 단어(스키마)를 따로 찾아보고 정리해서 잘했다고 칭찬을 받았따!
사용해본 경험도 적어보자! ex) mySQL은 RDBMS! RDBMS의 특징은~
DBMS의 개념이 먼저이다!
RDBMS는 스케일 업에 더 예민하다 (물리적 증가가 필요하다!) / noSQL은 스케일 업에 좀 더 유연?
팀 프로젝트 할 때 할 거!
- 빌더패턴? Builder pattern

각 엔티티 마다 빌더를 만들어 줄 수 있다!
- ex) Post.builder, User.builder, Memo.builder
- CI/CD는 AWS 배포 이후에 진행!!
- AWS…. 첨부파일 등
- 테스트코드
- 깃+깃허브
  - 콜라보레이터 : 레포지토리 주인장이 멤버 초대 방식
  - 포크 : 주인장 레포지토리를 포크 해와서 진행하는 방식 → 조금 더 확인 필요!
    - SYNC > MERGE