├── AI
├── Basic
│ ├── .gitkeep
│ └── batch-epoch.md
├── Computer Vision
│ └── .gitkeep
└── Natural Language Programming
│ ├── .gitkeep
│ ├── embedding.md
│ └── korean-nlp.md
├── Backend
├── Django
│ └── .gitkeep
├── Go
│ └── .gitkeep
├── Node.js
│ └── .gitkeep
└── Spring
│ └── .gitkeep
├── Cloud Computing
├── AWS
│ └── .gitkeep
├── Basic
│ ├── .gitkeep
│ ├── images
│ │ └── monolithic-vs-msa-01.png
│ └── monolithic-vs-msa.md
├── Docker
│ └── .gitkeep
└── Kubernetes
│ └── .gitkeep
├── Computer Science
├── Algorithm
│ └── .gitkeep
├── Computer Architecture
│ └── .gitkeep
├── Data Structure
│ └── .gitkeep
├── Database
│ ├── .gitkeep
│ ├── acid.md
│ ├── commit-rollback.md
│ ├── images
│ │ └── why-nosql-1.png
│ ├── transaction-isolation.md
│ └── why-nosql.md
├── Network
│ ├── .gitkeep
│ ├── connectionless-stateless.md
│ ├── cookie-session.md
│ ├── http-1-vs-2.md
│ ├── https-ssl-tls.md
│ ├── images
│ │ ├── http-1.png
│ │ ├── http-2.jpeg
│ │ ├── http-3.png
│ │ ├── when-we-1.png
│ │ ├── when-we-2.png
│ │ ├── when-we-3.png
│ │ └── when-we-4.png
│ └── when-we-enter-the-website.md
└── Operating System
│ └── .gitkeep
├── Frontend
├── Android
│ ├── .gitkeep
│ ├── images
│ │ ├── mvvm-design-pattern-01.png
│ │ ├── mvvm-design-pattern-02.png
│ │ ├── mvvm-design-pattern-03.png
│ │ ├── mvvm-design-pattern-04.png
│ │ ├── mvvm-design-pattern-05.png
│ │ └── mvvm-design-pattern-06.png
│ └── mvvm-design-pattern.md
├── Flutter
│ └── .gitkeep
├── React.js
│ └── .gitkeep
└── iOS
│ └── .gitkeep
├── Language
├── Go
│ └── .gitkeep
├── Java
│ ├── .gitkeep
│ ├── images
│ │ ├── solid-pattern-01.jpeg
│ │ ├── solid-pattern-02.png
│ │ ├── solid-pattern-03.jpeg
│ │ ├── solid-pattern-04.png
│ │ ├── solid-pattern-05.png
│ │ └── solid-pattern-06.png
│ ├── jvm.md
│ └── solid.md
├── JavaScript
│ └── .gitkeep
├── Kotlin
│ └── .gitkeep
└── Python
│ └── .gitkeep
└── README.md
/AI/Basic/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/AI/Basic/.gitkeep
--------------------------------------------------------------------------------
/AI/Basic/batch-epoch.md:
--------------------------------------------------------------------------------
1 | ## Batch Size VS Epoch
2 | 배치 사이즈와 에폭은 딥러닝 학습에서 자주 등장하는 개념입니다. 하지만 막상 설명하려면 헷갈리기 십상입니다. 한번 정리해보도록 합시다.
3 |
4 |
5 | ### Batch Size
6 | **연산 한번에 들어가는 데이터의 크기**
7 | 한번에 너무 큰 크기의 데이터 셋을 학습시키려면 메모리도 부족하고, 계산 시간도 오래 걸리는 등 여러 문제가 발생합니다.
8 | 따라서 전체 데이터셋을 Batch로 나눠 학습을 진행합니다. 이때 연산 한번에 들어가는 데이터의 크기를 Batch Size라고 합니다.
9 | 참고로, 1 batch size를 다른 말로 mini batch라고도 표현합니다.
10 |
11 | ### Epoch
12 | **전체 데이터 셋이 모델의 순전파(forward)와 역전파(backward)를 통과한 횟수**
13 | 예를 들어, 10 Epoch는 전체 데이터 셋이 모델의 순전파와 역전파를 10번 통과했다는 것을 의미합니다.
14 |
15 | Epoch이 너무 크면 Overfitting, 작으면 Underfitting이 발생하니 적당한 Epoch을 찾는 것이 중요합니다.
16 |
17 | ### Iteration
18 | **전체 데이터 셋을 모델에 학습시키기 위해 필요한 배치의 수**
19 | 예를 들어, 전체 데이터 셋의 크기가 1000이고, mini batch의 크기가 100이라면 필요한 Iteration은 10입니다.
20 | 이때, 10 Iteraion은 1 Epoch에 파라미터 업데이트가 10번 진행된다고도 이해할 수 있습니다.
21 |
22 |
23 |
24 | 
25 |
26 | ## Reference
27 | - [https://m.blog.naver.com/qbxlvnf11/221449297033](https://m.blog.naver.com/qbxlvnf11/221449297033)
28 | - [https://losskatsu.github.io/machine-learning/epoch-batch/#1-%EC%82%AC%EC%A0%84%EC%A0%81-%EC%9D%98%EB%AF%B8](https://losskatsu.github.io/machine-learning/epoch-batch/#1-%EC%82%AC%EC%A0%84%EC%A0%81-%EC%9D%98%EB%AF%B8)
29 | - [https://jerryan.medium.com/batch-size-a15958708a6](https://jerryan.medium.com/batch-size-a15958708a6)
30 |
--------------------------------------------------------------------------------
/AI/Computer Vision/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/AI/Computer Vision/.gitkeep
--------------------------------------------------------------------------------
/AI/Natural Language Programming/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/AI/Natural Language Programming/.gitkeep
--------------------------------------------------------------------------------
/AI/Natural Language Programming/embedding.md:
--------------------------------------------------------------------------------
1 | ## 임베딩(Embedding)
2 | **사람이 쓰는 자연어를 기계가 이해할 수 있는 숫자의 나열인 벡터로 바꾼 결과 혹은 그 일련의 과정 전체**
3 |
4 |
5 | 컴퓨터는 기본적으로 숫자로 된 데이터만 처리할 수 있습니다.
6 | **그렇다면 NLP에서 어떻게 컴퓨터가 자연어를 처리하게 할 수 있을까요?**
7 | 이를 위해서는 **사람이 쓰는 자연어를 컴퓨터가 이해할 수 있도록 적절하게 숫자로 변환**을 해주어야 합니다.
8 | 이 일련의 과정 혹은 결과가 바로 **임베딩**입니다.
9 |
10 | **품질 좋은 임베딩은 AI의 성능을 끌어올리는데 매우 지대한 영향을 미칩니다.** 따라서 지금도 품질 좋은 임베딩을 만들기 위한 연구가 활발히 진행되고 있습니다.
11 |
12 | ### 임베딩의 역할
13 | - 단어/문장 간 관련도 계산
14 | - 의미적/문법적 정보 함축
15 | - 전이 학습
16 |
17 | ### 임베딩의 종류
18 | #### 1. 행렬 분해 기반 방법
19 | 말뭉치 정보가 들어 있는 행렬을 두 개 이상의 작은 행렬로 쪼개는 방법입니다.
20 | 대표적인 방법으로 Globe와 Swivel이 있습니다.
21 | 
22 | [이미지 [출처](https://hyeonukdev.github.io/2020/03/30/KoreanEmbedding/%EC%9E%84%EB%B2%A0%EB%94%A9%EA%B8%B0%EB%B2%95%EC%9D%98%EC%97%AD%EC%82%AC%EC%99%80%EC%A2%85%EB%A5%98/)]
23 |
24 | #### 2. 예측 기반 방법
25 | 어떤 단어 주변에 특정 단어가 나타날지 예측하거나, 이전 단어들이 주어졌을 때 다음 단어가 무엇일지 예측하는 등의 과정으로 학습하는 방법입니다.
26 | 대표적인 방법으로 **Word2Vec, FastText, BERT, ELMo, GPT** 등이 있습니다.
27 |
28 | #### 3. 토픽 기반 방법
29 | 주어진 문서에 잠재된 주제를 추론하는 방식으로 임베딩을 수행하는 방법입니다.
30 | 대표적인 방법으로 LDA(Latent Dirichlet Allocation)가 있습니다.
31 |
32 |
33 | ## Reference (참고 및 함께보면 좋은 자료)
34 | - 한국어 임베딩 (이기창)
35 |
--------------------------------------------------------------------------------
/AI/Natural Language Programming/korean-nlp.md:
--------------------------------------------------------------------------------
1 | ## 한국어 NLP는 왜 어려울까?
2 | 컴퓨터에게 사람의 말을 알아듣게 하는 것은 매우 어려운 일입니다.
3 | 그중에서도 한국어 NLP는 다른 언어들(Ex. 영어, 중국어)보다 훨씬 어려운 편에 속합니다. 그 이유에 대해서 알아봅니다.
4 |
5 | ### 1. 교착어
6 | 한국어는 교착어에 속합니다. **교착어**란 어간에 접사가 붙어 단어를 이루고 의미와 문법적 기능이 정해지는 언어입니다.
7 |
8 | 예를 들어 **나는 밥을 먹다.** 라는 문장이 있습니다.
9 | 해당 문장에서 과거의 의미를 부여하고 싶을 때, **먹다**라는 동사에 **-었-** 이라는 어미를 붙여 **먹었다** 라는 단어를 사용합니다.
10 | 즉 **나는 밥을 먹었다.** 라는 문장으로 과거 시제를 표현합니다.
11 |
12 | 이러한 특징은 **하나의 어근에서 비슷한 의미의 수많은 단어가 매우 많이 생성** 된다는 점이 있습니다.
13 |
14 | 아래 표는 **좋아하다** 라는 동사의 활용을 정리한 것입니다. 언뜻 보기에도 하나의 단어에서 수많은 단어가 파생된 것을 볼 수 있습니다. 이러한 점은 한국어 NLP에서 파싱, 전처리, 모델 학습 등을 어렵게 만듭니다.
15 |
16 | 
17 |
18 | [이미지 출처](https://exagen.tistory.com/13)
19 |
20 |
21 | ### 2. 띄어쓰기
22 | 사실 한국어에서 띄어쓰기는 근대에서 도입된 개념입니다. 따라서 서구권 언어에 비해 **한국어는 띄어쓰기의 표준이 계속 바뀌고, 비교적 자유분방하다는 특징이 있습니다.** 또한 띄어쓰기에 따라 문장의 뜻이 달라지기도 합니다.
23 | 대표적인 예시로 아버지가방에들어가신다를 들 수 있습니다.
24 |
25 | 따라서 단어와 단어 사이 반드시 띄어쓰기를 하는 서구권 언어와 달리 **한국어는 추가적으로 띄어쓰기를 정제해주는 과정이 필요합니다.**
26 |
27 | ### 3. 평서문과 의문문
28 | 한국어는 평서문과 의문문의 구분이 모호한 경우가 많이 있습니다.
29 | 예를 들어 **밥 먹었어?** 와 **밥 먹었어.** 의 경우가 있습니다.
30 | 문장 부호가 붙지 않는다면 두 문장 의미의 차이를 알 수 없습니다.
31 |
32 | 사람이라면 주변 상황이나 말의 억양으로 판별할 수 있겠지만, AI의 경우에는 이를 처리하기가 쉽지 않습니다.
33 |
34 | ### 4. 주어 생략
35 | 한국어는 동사를 중요시하고 주어가 자주 생략된다는 특징이 있습니다.
36 | 위와 같은 예로 **밥 먹었어** 라는 문장의 경우 주어가 명시되어 있지 않습니다.
37 | 주어가 생략된 문장을 AI가 정확히 이해하기란 쉽지 않은 일입니다.
38 |
39 | ### 5. 한자 기반의 언어
40 | 한국어에는 한자의 조합으로 이루어지는 단어들이 많이 있습니다.
41 | 예를 들어 **집중**이라는 단어의 경우 모을 집(集)과 가운데 중(中)이라는 단어가 합쳐져 만들어집니다.
42 | 영어의 concentrate의 경우에도 서브워드들이 합쳐져 하나의 단어를 이루게 됩니다.
43 |
44 | - Concentrate: con(=together) + centr(=center) + ate(= make)
45 | - 집중(集中): 集(모을 집) + 中(가운데 중)
46 |
47 | 하지만 한글이 한자를 대체하면서 문제가 발생합니다. 표어 문자인 한자가 표음 문자인 한글로 대체되면서, 읽는 소리는 같을 지라도 형태와 그 뜻은 다른 단어들이 여럿 생겨났습니다.
48 | **집** 의 경우에도 모을 집(集), 낳을 집(緝), 잡을 집(執) 등의 수 많은 한자 단어가 집이라는 한 글자로 대체되었습니다. 이는 **정보의 손실** 을 야기하게 됩니다.
49 | 사람이라면 문맥을 통해 정보의 손실을 해소할 수 있겠지만, AI의 경우에는 그렇지 못합니다.
50 |
51 | ### 6. 부족한 학습 데이터
52 | 안그래도 학습도 어려운 한국어인데, 다른 언어에 비해 한국어 데이터도 턱없이 부족합니다.
53 |
54 | [사이트](https://commoncrawl.github.io/cc-crawl-statistics/plots/languages)에서 각 언어별 웹 데이터의 양을 비교한 자료를 살펴보면, 한국어가 다른 언어에 비해 데이터가 확실히 적은 것을 볼 수 있습니다.
55 | 
56 |
57 | 또한 데이터의 개수가 적은 것과 동시에 한국어 데이터셋에 대한 연구와 개발도 부족한 실정입니다.
58 | 영어의 경우 SQuAD, GLUE 등 TASK에 따른 다양한 데이터셋에 대한 연구와 개발이 활발합니다.
59 | 최근 한국어도 정부나 기업 차원에서 **모두의 말뭉치, KorQuAD** 처럼 한국어 데이터셋을 개발 및 공개하고 있습니다. 지금부터라도 한국어도 좋은 데이터셋을 확보되었으면 하는 작은 바람이 있습니다 :)
60 |
61 | ### 7. 자유분방한 신조어
62 | **한국어 NLP ㄹㅇ 어케하는건데 ㅋㅋ**
63 |
64 | 한국어는 다른 언어에 비해 신조어의 생성이 활발하고 자유로운 편입니다.
65 | 그만 알아보도록 합시다... 😥
66 |
67 |
68 |
69 | ## Reference
70 | - 김기현의 자연어 처리 딥러닝 캠프 (김기현)
71 | - https://tech.kakaoenterprise.com/117
72 |
--------------------------------------------------------------------------------
/Backend/Django/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Backend/Django/.gitkeep
--------------------------------------------------------------------------------
/Backend/Go/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Backend/Go/.gitkeep
--------------------------------------------------------------------------------
/Backend/Node.js/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Backend/Node.js/.gitkeep
--------------------------------------------------------------------------------
/Backend/Spring/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Backend/Spring/.gitkeep
--------------------------------------------------------------------------------
/Cloud Computing/AWS/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Cloud Computing/AWS/.gitkeep
--------------------------------------------------------------------------------
/Cloud Computing/Basic/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Cloud Computing/Basic/.gitkeep
--------------------------------------------------------------------------------
/Cloud Computing/Basic/images/monolithic-vs-msa-01.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Cloud Computing/Basic/images/monolithic-vs-msa-01.png
--------------------------------------------------------------------------------
/Cloud Computing/Basic/monolithic-vs-msa.md:
--------------------------------------------------------------------------------
1 | ## Monolithic vs MSA
2 |
3 | ### Monolithic
4 | **Monolithic**은 예전부터 사용하던 방식으로, **하나의 서비스를 하나의 어플리케이션**으로 만드는 것을 의미 합니다.
5 |
6 | #### 장점
7 | - **작은 규모의 프로젝트 환경**에서 개발이 편리 합니다.
8 | - **통합 테스트**가 **MSA**에 비해 편리합니다.
9 | - 배포가 **간편** 합니다.
10 |
11 | #### 단점
12 | - 서비스가 커질수록, **코드의 수정 및 추가가 힘듭니다.**
13 | - **효율적인 자원 관리**가 어렵습니다.
14 | - 서비스 내 특정 부분이 잘못되면 **서비스 전체가 마비 됩니다.**
15 | - 여러 개의 노드를 만들어 성능을 올리는 **Scale Out** 이 불가능 합니다.
16 |
17 | ### MSA (Micro Service Architecture)
18 |
19 | 그와 반대로 **MSA** (Micro Service Architecture)은 **하나의 서비스를 여러 개의 작은 어플리케이션**으로 만드는 것을 의미합니다. 대부분의 경우 **Kubernetes** 같은 **Container Orchestration** 툴을 이용 하여 운영합니다.
20 |
21 | #### 장점
22 | - **Scale Out**이 가능 합니다.
23 | - **개별 서비스 단위의 배포**가 가능 합니다.
24 | - 코드 **수정 및 배포**가 쉬워, 요구사항의 **잦은 변경에 대처**가 용이 합니다.
25 | - 작은 기능에 대해 독립적으로 서비스를 운영 할 수 있어, **신규 기술을 도입 하는데 용이** 합니다.
26 |
27 | #### 단점
28 | - 로그 추적 등 **Trouble Shooting**이 쉽지 않습니다.
29 | - **통합 환경 테스트**가 어렵습니다.
30 | - 다른 컨테이너 간 통신을 하는 API일 경우 **트렌젝션 처리**가 어렵습니다.
31 | - 서버가 분리 됨에 따라, **배포가 어려워** 집니다.
32 |
33 |
34 | 
35 |
36 |
--------------------------------------------------------------------------------
/Cloud Computing/Docker/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Cloud Computing/Docker/.gitkeep
--------------------------------------------------------------------------------
/Cloud Computing/Kubernetes/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Cloud Computing/Kubernetes/.gitkeep
--------------------------------------------------------------------------------
/Computer Science/Algorithm/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Computer Science/Algorithm/.gitkeep
--------------------------------------------------------------------------------
/Computer Science/Computer Architecture/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Computer Science/Computer Architecture/.gitkeep
--------------------------------------------------------------------------------
/Computer Science/Data Structure/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Computer Science/Data Structure/.gitkeep
--------------------------------------------------------------------------------
/Computer Science/Database/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Computer Science/Database/.gitkeep
--------------------------------------------------------------------------------
/Computer Science/Database/acid.md:
--------------------------------------------------------------------------------
1 | ## ACID란 무엇인가?
2 | **ACID**는 **Database Transaction**에서 지켜야 할 4원칙을 의미 합니다.
3 |
4 | ### Transaction이란?
5 | 데이터베이스의 상태를 변화시키기 위해 **수행하는 작업단위** 입니다.
6 |
7 | ### ACID 4원칙
8 |
9 | #### Atomicity (원자성)
10 | **트랜잭션**은 DB에 모두 반영되거나, 반영 되지 않아야 합니다. 그렇지 않으면 오작동 시, 원인을 찾기 힘들어 지기 때문입니다.
11 |
12 | #### Consistency (일관성)
13 | **트랜잭션**의 작업 처리 결과는 항상 **일관성** 있어야 합니다. 처음에 트랜잭션을 진행 하기 위해 참조한 데이터베이스로 진행 되어야 합니다. 이렇게 해야 각 사용자는 일관성 있는 데이터를 볼 수 있습니다.
14 |
15 | #### Isolation (독립성)
16 | 둘 이상의 트랜잭션이 **동시에 병행하여 실행** 될 때, 어떤 트랙잭션도 다른 트랜잭션 연산에 **끼어들 수 없습니다.**
17 |
18 | #### Durability (지속성)
19 | 트랜잭션이 성공적으로 완료되었으면, 결과는 **영구 반영** 되어야 합니다.
20 |
--------------------------------------------------------------------------------
/Computer Science/Database/commit-rollback.md:
--------------------------------------------------------------------------------
1 | ### Transaction에서 Commit과 Rollback은 무엇인가?
2 | 이는 **트랜잭션의 특징**에 대해서 먼저 조금 생각 해 볼 필요가 있습니다.
3 |
4 | 트랜잭션은, 데이터베이스의 상태를 변화시키기 위해 **수행하는 작업단위** 입니다. 이렇게 작업단위가 정해진 이유는, **병행제어 및 회복 작업이 수행되어야 하는 논리적 작업 단위**어야 하기 때문입니다. 그렇기 때문에 **트랜잭션** 단위로 **성공** 신호를 보내는 연산과, **실패 후 복구** 하는 연산이 있어야 합니다.
5 |
6 | #### Commit
7 | **Commit**은 하나의 트랜잭션이 성공적으로 끝났으며, DB가 **일관성있는 상태**가 되었을 때, 이를 알려주기 위한 연산 입니다.
8 |
9 | #### Rollback
10 | 하나의 **트랜잭션** 처리가 비정상적으로 종료되어, **트랜잭션 원자성**이 깨진 경우를 **Abort** 상태 라고 합니다. 이때, **last consistent state** (예를 들어, Transaction의 시작 상태)로 **Rollback** 연산을 수행하여 복구 시킬 수 있습니다.
--------------------------------------------------------------------------------
/Computer Science/Database/images/why-nosql-1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Computer Science/Database/images/why-nosql-1.png
--------------------------------------------------------------------------------
/Computer Science/Database/transaction-isolation.md:
--------------------------------------------------------------------------------
1 | ## 트렌젝션 고립레벨은 뭐고, 이걸 왜 나눠 놓은거죠?
2 | 일단 **고립레벨 (Isolation level)** 에 대해서 설명 드리겠습니다. **고립레벨**은 트랜젝션에서 일관성 없는 데이터를 허용하도록 하는 수준을 의미합니다. 윗 글에서 **ACID**에 대해서 이야기 했습니다. 그래서 우리는 각 트랜젝션이 독립적인 수행이 가능하도록, 특정 수준의 **Locking** 이 필요 한 것 입니다.
3 |
4 | 하지만, 모든 요청에 대해서 **Locking**을 걸게 되면, 많이 난감해 지겠죠? 각 요청이 다른 요청이 끝날 때 까지 기다리도록, 순서대로 실행 되게 하면 데이터베이스의 성능은... 뭐 당연히 좋아지지 않을 것 입니다.
5 |
6 | 그래서 효율적인 **Locking**을 걸기 위해서, **트렌젝션 고립레벨**을 나눠 놓은 것 이지요.
7 |
8 | ### Isolation level 종류
9 | #### 1. Read Uncommitted (레벨 0)
10 | 해당 격리수준에서는 어떤 트랜잭션의 변경내용이 **Commit**이나 **Rollback**과 상관없이 다른 트랜잭션에서 보여집니다. 사실상 **트랜잭션 고립이 이루어지지 않은 상태**로, **Dirty Read**가 일어날 가능성이 높습니다! 당연히 이 단계에서는 데이터베이스의 일관성을 유지하는 것이 불가능합니다.
11 |
12 | **Dirty Read**는 다음을 말합니다. 커밋되지 않은 **수정중인 데이터**를 다른 트랜잭션에서 읽을 수 있도록 허용할 때 발생하는 현상입니다. 예를 들어보면 다음과 같습니다.
13 |
14 | - A 트랜잭션에서 ID 1을 가진 유저의 별명을 **AAA**에서 **BBB**로 바꾸었습니다.
15 | - B 트랜잭션에서 ID 1을 가진 유저의 별명을 조회 했습니다.
16 | - 여기서 A 트랜잭션에서 **Rollback**을 했다면? B 트랜잭션은 유저의 별명을 **BBB로 알고 있기 때문에**, 그래도 로직을 계속 수행합니다. 그러면 데이터가 서로 모순 없이 일관되게 일치해야 함을 의미하는, **데이터 정합성에 문제**가 생기는 것 이지요.
17 |
18 | #### 2. Read Committed (레벨 1)
19 | 트랜잭션이 수행되는 동안 해당 데이터에 **Shared Lock**이 걸려, 다른 트랜잭션이 접근 할 수 없어 **대기**하게 됩니다. SQL 서버가 기본적으로 사용 합니다. **Commit이 이루어진 트랜잭션만 조회 할 수 있게**되는 것이지요. 단, 이도 **Non-Repeatable Read** 문제를 초래 합니다. 예를 들어 보죠.
20 |
21 | - B 트랜잭션이 실행 되고, 값 10을 읽었습니다.
22 | - A 트랜잭션이 실행 되고, 값 10을 11로 바꾼 후, **Commit** 되었습니다.
23 | - 아직 끝나지 않은 트랜잭션 B가 또 값을 읽었는데 값이 11이 되어 있었습니다.
24 |
25 | 이는 **하나의 트랜잭션내에서 똑같은 SELECT 쿼리를 실행했을 때 항상 같은 결과**를 가져와야 하는 **Repeatable Read**의 정합성에서 어긋나게 됩니다.
26 |
27 | #### 3. Repeatable Read (레벨 2)
28 | 트랜잭션이 완료될 때까지 **SELECT 문장이 사용하는 모든 데이터에 Shared Lock**이 걸립니다. 트랜잭션이 범위 내에서 조회한 데이터 내용이 항상 **동일함**을 보장하며, 다른 사용자는 **트랜잭션 영역에 해당되는 데이터에 대한 수정이 불가능**합니다. 단, 이 마저도 **Phantom Read** 현상이 일어 나는데, 수정을 막았지, **추가를 막지는 않았습니다.** 그래서, 또 다른 레코드가 읽히는 거죠.
29 |
30 | #### 4. Serializable (레벨 3)
31 | 이건 그냥 "수정, 추가 모두 막는 것" 입니다. 가장 단순하고, 가장 엄격하고, 가장 느립니다.
--------------------------------------------------------------------------------
/Computer Science/Database/why-nosql.md:
--------------------------------------------------------------------------------
1 | ## NoSQL은 왜 쓰는 건가요?
2 | 굳이 **MySQL** 같은 **RDBMS**가 있는 상황에서, **NoSQL**을 사용 하는 이유가 무엇일까요? 그 이유는 여러 가지를 꼽을 수 있습니다.
3 |
4 | ### Scale Out 가능
5 | **RDBMS**는 **관계형 데이터**이기 때문에, **Scale Out**이 불가능 합니다. 성능을 올리기 위해선, 무조건 해당 컴퓨터의 성능을 높이는 **Scale Up**을 실시해야 합니다. 하지만, **NoSQL**은, 테이블 간의 관계를 정의 하지 않기 때문에, 여러 노드에 데이터를 분산하여 저장하는 **Sharding**이 가능하여 **Scale Out**이 가능합니다.
6 |
7 | ### Sharding
8 | **Sharding**은 대량의 데이터베이스를 분할 하는 기술입니다. 하나의 DB에 데이터가 늘어나면 **용량 이슈**도 생기고, 느려지는 쿼리는 서비스 성능에 영향을 미칩니다. 그렇기 때문에 **DB 트래픽을 여러 개의 노드로 분산**하는 목적으로 샤딩을 사용 합니다.
9 |
10 | 샤딩을 하는 방법은 대표적으로 **PK값을 모듈러 연산**한 결과로 저장하는 **Modular Sharding**과 **PK의 범위를 기준으로 연산**한 **Range Sharding**이 있습니다.
11 |
12 | 혹은, 데이터의 지역성을 유지하기 위해서, 같이 조회 될 만한 데이터들 끼리 묶일 수 있도록 샤딩 정책을 세워도 됩니다.
13 |
14 |
15 | 
16 |
출처 : https://techblog.woowahan.com/2687/
17 |
18 |
19 | ### NoSQL을 쓰면 안되는 경우?
20 | 엔티티간 관계가 있고, 해당 데이터의 **무결성**이 중요한 경우에는 **RDBMS**를 사용 합니다. 이를 보완하기 위해, **무결성**이 중요한 로직에는 **RDBMS**를, **속도**가 중요한 로직은 **NoSQL**을, 병행해서 사용하는 경우도 있습니다.
--------------------------------------------------------------------------------
/Computer Science/Network/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Computer Science/Network/.gitkeep
--------------------------------------------------------------------------------
/Computer Science/Network/connectionless-stateless.md:
--------------------------------------------------------------------------------
1 | # Connectionless와 Stateless
2 |
3 | **HTTP**는 여러 가지 특징을 갖고 있는데, 그 중 Connectionless와 Stateless에 대해 알아보자.
4 |
5 | ## Connectionless (비연결성)
6 |
7 | ### HTTP와 TCP/IP
8 |
9 | **HTTP**는 **7계층**의 프로토콜로, **TCP/IP**를 기반으로 한다. **TCP/IP**의 경우 기본적으로 연결을 종료하지 않으면 그 연결은 종료되지 않고 유지된다. 만약 하나의 서버에 여러 클라이언트가 접속해 있다고 하자.
10 |
11 | 
12 |
13 |
14 | 모든 연결이 동시에 유의미한 통신을 하고 있을 확률은 적다. 즉, 놀고 있는 연결이 많을 가능성이 크고 이는 서버의 자원 낭비로 이어진다. 따라서 **HTTP**의 초기 모델은 각 클라이언트가 서버에 요청을 하고 응답을 받으면 바로 **TCP/IP** 연결을 끊도록 하는 방식이었는데, 이러한 **HTTP**의 특징을 **Connectionless**하다고 한다.
15 |
16 | 
17 |
18 | ### HTTP 1.0 - 비지속 연결 (Non-Persistent Connection)
19 |
20 | 하지만 웹 페이지에는 HTML 문서뿐만 아니라 script나 이미지 파일 등 수많은 Request와 Response가 존재한다. HTTP 1.0 버전에서는 이러한 각 요청과 응답마다 TCP 연결을 새로 생성하는 과정에서 **매번** **3-way handshake**를 진행하여 연결을 establish해야 했으므로, 오버헤드에 의한 자원 낭비와 성능 저하가 심했다.
21 |
22 | 
23 |
24 | ### HTTP 1.1 - 지속 연결 (Persistent Connection)
25 |
26 | HTTP 1.1부터는 비지속 연결의 단점을 보완하고자 **TCP 연결을 재사용**하도록 했는데, 이를 **지속 연결**이라고 하며 default로 지원한다. Request Header의 `Connection`에 `keep-alive`를 지정하면 지속 연결로, `close`를 지정하면 비지속 연결로 동작한다.
27 |
28 | 
29 |
30 | 지속 연결을 구현하는 방법은 두 가지가 있다.
31 |
32 | - 첫 번째 방법은 단일 TCP 연결을 이용한 **Pipelining**이다. 연결 생성-종료 사이에 response를 기다리지 않고 여러 request를 보내는 방식인데, response를 받는 통로인 TCP 연결이 딱 하나이므로 앞서 가는 Response가 모종의 이유로 지연된다면 뒤따르는 다른 Response들 또한 지연되는 **Head of Line Blocking (HoL Blocking)** 문제가 발생할 수 있다.
33 | - 두 번째 방법은 여러 개의 TCP 연결(**Multiple Connections**)을 뚫어 놓고 병렬로 Request와 Response를 처리하는 것이다. 하지만 TCP 연결을 여러 개 유지하기 위한 **자원 소모**가 상당하다는 단점이 존재한다.
34 |
35 | **HTTP 2.0**은 이러한 단점들을 보완하여 하나의 TCP 연결로 더 최적화된 통신을 지원한다.
36 |
37 | ## Stateless (무상태)
38 |
39 | **Stateless**와 반대되는 표현은 Stateful인데, 서버가 이전 요청에서의 클라이언트의 상태를 보존한다는 것이다. **Stateless**는 통신이 끝나면 더 이상 상태를 유지하지 않는다는 **HTTP**의 또다른 특징이다.
40 |
41 | 하지만 상태를 유지하지 않으면 다음과 같은 문제점이 있다.
42 |
43 | - 사이트에 로그인을 했는데, 페이지를 이동할 때마다 이전의 로그인이 유지되지 않아 매번 로그인을 해야 한다.
44 | - 분명 사이트에 들어가서 팝업을 하루동안 보지 않기로 체크를 했는데, 페이지를 유지할 때마다 매번 팝업창이 떠서 팝업을 닫아야 한다.
45 |
46 | ## 쿠키와 세션
47 |
48 | Connectionless와 Stateless를 보완하기 위해 우리는 **쿠키(Cookie)**와 **세션(Session)**을 이용한다.
49 |
50 | [쿠키와 세션](https://velog.io/@bambookim/%EC%BF%A0%ED%82%A4%EC%99%80-%EC%84%B8%EC%85%98)
51 |
52 | ## 참고 자료
53 |
54 | - [https://hirlawldo.tistory.com/106](https://hirlawldo.tistory.com/106)
55 | - [https://velog.io/@duarufp06/HTTP-Stateless-Connectionless-HTTP-메시지-개념](https://velog.io/@duarufp06/HTTP-Stateless-Connectionless-HTTP-%EB%A9%94%EC%8B%9C%EC%A7%80-%EA%B0%9C%EB%85%90)
56 |
--------------------------------------------------------------------------------
/Computer Science/Network/cookie-session.md:
--------------------------------------------------------------------------------
1 | # 쿠키와 세션
2 |
3 |
4 | ## HTTP에서 쿠키와 세션을 사용하는 이유
5 |
6 | **HTTP**는 connectionless하고 stateless하다는 특징을 가진다.
7 |
8 | [Connectionless와 Stateless](https://velog.io/@bambookim/Connectionless%EC%99%80-Stateless)
9 |
10 | 사용자 인증과 같이 서버에서 지속적으로 클라이언트의 상태나 정보 등을 알아야 할때, 단점이 될 수 있는 connectionless하고 stateless한 특징을 보완하기 위해 우리는 **쿠키**와 **세션**을 이용한다.
11 |
12 | ## 쿠키(Cookie)
13 |
14 | 우리가 사이트에 접속하면, 사이트(서버)는 접속한 클라이언트의 정보가 지속적으로 필요하다고 판단되면 해당 정보를 클라이언트의 로컬(브라우저)에 파일의 형태로 저장하도록 하는데, 이 파일을 **쿠키(Cookie)**라고 한다.
15 |
16 | ### 쿠키의 특징
17 |
18 | 쿠키는 다음과 같은 특징을 가진다.
19 |
20 | - 만료일이 지정되어 있는 경우, 브라우저가 종료되어도 유지된다. (세션 쿠키가 아닌 경우)
21 | - 클라이언트에 최대 300개의 쿠키를, 이 중 하나의 도메인 당 최대 20개의 쿠키를 저장할 수 있다.
22 | - 하나의 쿠키는 최대 4KB의 용량을 가질 수 있다.
23 |
24 | 서버가 클라이언트에 Response를 할 때, 응답 헤더에 `set-cookie`를 설정하면 클라이언트(브라우저)는 설정된 쿠키를 생성하여 로컬에 저장한다.
25 |
26 | 
27 |
28 |
29 | [https://www.khu.ac.kr/](https://www.khu.ac.kr/)에 접속했을 때의 응답 헤더를 보면, `Set-Cookie`로 쿠키를 생성하도록 하는 것을 볼 수 있다.
30 |
31 | ### 쿠키의 구성
32 | 
33 | - **Name**
34 | - 쿠키의 이름
35 | - **Value**
36 | - 저장된 쿠키의 값
37 | - **Domain**
38 | - 쿠키를 사용하는 도메인 정보. 쿠키를 전송할 도메인의 정보이기도 하다.
39 | - **Path**
40 | - 쿠키가 전송될 경로 정보
41 | - **Expires / Max-Age**
42 | - 쿠키의 만료일 또는 만료 시간
43 | - 만료일이 지정되어 있는 쿠키는 **영구 쿠키(Persistent Cookie)**이므로, 브라우저가 종료되어도 삭제되지 않는다.
44 | - 만료일이 지정되어 있지 않고 **Session**으로 표기되어 있는 쿠키는 **세션 쿠키(Session Cookie)**이며, 브라우저가 종료되면 세션 쿠키는 삭제된다.
45 | - 만료일이 지난 쿠키는 로컬에서 삭제된다.
46 |
47 | ### 쿠키의 종류
48 |
49 | - **세션 쿠키(Session Cookie)** - 만료시간을 지정하지 않은 경우에 해당하며, 후술할 세션을 구현하기 위해 사용한다. 브라우저 종료 시 세션 쿠키는 삭제된다.
50 | - **영구 쿠키(Persistent Cookie)** - 만료일이 지정된 경우, 해당 만료일까지 로컬에 파일로 남아 존재한다. 브라우저를 종료해도 영구 쿠키는 유지된다.
51 |
52 | ### 쿠키의 동작 예시
53 |
54 | *(주의 : 아래의 로그인을 통한 예시는 쿠키가 어떻게 쓰이는지 보여주는 것으로, 실제 적용 시 보안 위험이 존재합니다.)*
55 |
56 | 
57 |
58 |
59 | 1. **클라이언트**가 인증 정보를 담아 서버에 로그인 요청을 한다.
60 | 2. **서버**는 인증 정보를 확인한 뒤, 응답 헤더에 `set-cookie: user=chrisjune`을 추가하여 응답한다.
61 | 3. **클라이언트**는 헤더의 `set-cookie`에 따라 로컬에 `name`이 `user`이고 `value`가 `chrisjune`인 쿠키를 저장한다.
62 | 4. 이후 **서버**에 요청을 보낼 때마다 응답 헤더에 쿠키를 담아 보낸다.
63 | 5. **서버**는 쿠키를 통해 누구의 요청인지, 적절한 권한이 있는지 등 인증과 인가를 진행한 뒤 적절한 응답을 보낸다.
64 |
65 | ---
66 |
67 | ## 세션(Session)
68 |
69 | 사용자가 서버에 접속한 후 브라우저를 종료하거나, 연결을 끊을 때까지를 **하나의 상태**로 보고 이를 **유지**시키는 것을 **세션**이라고 한다.
70 |
71 | ### 세션의 특징
72 |
73 | - 세션은 쿠키와 다르게, 정보를 로컬이 아닌 **서버에 저장하고 관리**한다.
74 | - 쿠키를 기반으로, 고유한 **세션 ID**를 통해 클라이언트를 구분한다.
75 | - 세션을 서버의 어디에 저장할지는 **서버마다 다르다.** MySQL 등의 독립적인 DB에 저장할 수도 있고, Redis같은 인메모리 DB에 저장할 수도 있으며, 톰캣과 같은 WAS의 메모리에 저장할 수도 있다. 따라서 세션의 저장 데이터 제한 또한 서버마다 다르다. → ***각각의 장단점은?***
76 | - 접속한 사용자가 많아질수록 서버가 관리해야 하는 세션의 양은 늘어난다.
77 |
78 | ### 세션의 동작 예시
79 |
80 | (세션 저장소는 구현에 따라 서버 내부 또는 외부에 위치해 있을 수 있다.)
81 |
82 | - 로그인
83 |
84 | 
85 |
86 |
87 | - 로그인 이후 Request
88 |
89 | 
90 |
91 |
92 | ## 쿠키와 세션의 비교
93 |
94 | ### 저장 위치
95 |
96 | - 쿠키는 로컬(브라우저)에, 세션은 서버에 저장된다.
97 |
98 | ### 보안성
99 |
100 | - 쿠키는 유지할 정보를 모두 로컬에 저장하고, Request마다 이 정보들을 header에 넣어 전달한다.
101 | - 따라서 **변조** 또는 **감청(스니핑)**의 위험이 존재한다. *쿠키에 ID와 비밀번호를 담아 보내는 경우…*
102 | - 하지만 세션의 경우, 유지할 사용자의 정보는 **서버**가 갖고 있고,
103 | - 그 사용자가 누구인지는 **session ID**로 구분하므로 비교적 안전하다. → ***세션ID가 탈취당한다면?***
104 |
105 | ### 라이프 사이클
106 |
107 | - 쿠키(영구 쿠키)와 세션 모두 **만료기간**을 설정할 수 있다.
108 | - 영구 쿠키는 브라우저를 닫아도 삭제되지 않고 유지된다. 만료기간이 지나면 로컬에서 삭제된다.
109 | - 세션의 경우, 브라우저를 닫으면 세션 쿠키가 삭제되어 로컬에서의 세션은 삭제된다.
110 | - 만료 기간이 지나면 세션 정보는 서버에서 삭제된다.
111 |
112 | ### 병행 사용
113 |
114 | - 쿠키는 로컬에서 관리하며 정보를 서버에 바로 전달하므로 세션에 비해 속도가 빠르다는 장점이 있지만, 보안성이 떨어진다는 단점이 있다.
115 | - 세션은 보안성이라는 장점이 있지만, 세션 ID를 통해 서버에 있는 정보를 가져와야 해서 비교적 느리다는 점과, 사용자가 늘어날수록 서버가 관리해야 할 세션의 부담이 증가한다는 단점이 있다.
116 | - 따라서 용도에 따라 쿠키와 세션을 병행하여 사용한다.
117 |
118 | ## 참고자료
119 |
120 | - [https://chrisjune-13837.medium.com/web-쿠키-세션이란-aa6bcb327582](https://chrisjune-13837.medium.com/web-%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98%EC%9D%B4%EB%9E%80-aa6bcb327582)
121 | - [https://co-de.tistory.com/m/20](https://co-de.tistory.com/m/20)
122 | - [https://doooyeon.github.io/2018/09/10/cookie-and-session.html](https://doooyeon.github.io/2018/09/10/cookie-and-session.html)
123 | - [https://interconnection.tistory.com/74](https://interconnection.tistory.com/74)
124 | - [https://dev-coco.tistory.com/61](https://dev-coco.tistory.com/61)
125 |
--------------------------------------------------------------------------------
/Computer Science/Network/http-1-vs-2.md:
--------------------------------------------------------------------------------
1 | ## HTTP 1.1
2 | **HTTP 1.1**은 기본적으로 하나의 **Connection**당 하나의 **요청**을 처리 하도록 설계 되었습니다.
3 |
4 | 그렇기 때문에 **동시 전송이 불가능**하고 요청과 응답이 순차적으로 이뤄집니다. 그래서 다수의 리소스 (Image, CSS, Javascript 등)를 처리 하기 위해서는, 그 리소스 갯수 만큼 계속 기다려야 하는 것이지요.
5 |
6 | ### 단점 1. HOL(Head Of Line) Blocking
7 | **HOL(Head Of Line) Blocking**은 네트워크에서 같은 큐에 있는 패킷이 첫 번째 패킷에 의해 지연 될 때 발생하는 성능 저하 현상을 말합니다.
8 |
9 | 만약 TCP 단위에서 패킷이 소실 되더라도, 해당 패킷이 재전송 되어 다시 받아질 때 까지, 나머지 패킷들을 계속 이를 기다려야 하는 것이지요.
10 |
11 | 또한, 이는 HTTP 단위에서도 문제를 발생 시킵니다. **HTTP 1.1** 기반으로 통신하는 `https://ce.khu.ac.kr/`에 접속 하면, 다음과 같은 일이 일어 납니다. 한 가지 요청이 끝날 때 까지, 다른 자원들은 로딩이 다 될 때 까지 기다려야 해요.
12 |
13 |
14 | 
15 |
16 |
17 | ### 단점 2. RTT(Round Trip Time)
18 | 요청당 한 가지만 처리 하다 보니, 매번 요청 별로 **Connection**을 만들어 **TCP** 상에서 동작하는 **HTTP**의 특성상 **3-way Handshake**가 반복적으로 일어 납니다. 그렇게 되면 성능 저하가 발생 하겠지요.
19 |
20 | ### 단점 3. 무거운 Header
21 | 매 요청마다 중복된 헤더 값을 전송하게 되고, 쿠키 또한 계속해서 헤더에 포함되어 전송 하게 됩니다. 그러다 보니 **Overhead**가 커지게 되는 것이지요.
22 |
23 | ## HTTP 2.0
24 | 그래서 **HTTP 2.0**이 등장 하게 되었습니다. 프로토콜의 성능에 초점을 맞춰 수정한 버전 으로, 실사용 유저가 느끼는 Latency, 네트워크, 서버 리소스 사용량 등을 중점으로 수정 하였습니다.
25 |
26 | ### Multiplexed Streams
27 | **HTTP 2.0**은 **Multiplexed Streams**를 이용, **Connection 한 개**로 **동시에 여러 개의 메시지**를 주고 받을 수 있습니다.
28 |
29 |
30 | 
31 |
32 |
33 | ### Stream Prioritization
34 | 만약 **CSS**와 **Image**가 두 개 존재하는 상황에서, **이미지 파일**보다 **CSS 파일**의 수신이 늦어진다면 어떤 문제가 발생 할까요? 레이아웃이 깨져 보여서 별로 좋아 보이지는 않을 것 입니다. 그럴 때는 리소스에 **우선 순위**를 붙여, 더 높은 우선순위를 가진 리소스를 먼저 가져 오는 것이 좋을 것 입니다.
35 |
36 | ### Server Push
37 | 서버는 클라이언트가 요청하지 않아도, 사전에 리소스를 클라이언트에 푸쉬하여, 리소스를 클라이언트에서 다운로드 가능 캐 할 수 있습니다. 이렇게 하면 클라이언트의 요청을 최소화 할 수 있습니다.
38 |
39 | ### Header Compression
40 | 헤더 정보를 압축하기 위해 `Header Table`과 `Huffman Encoding`을 사용하여 처리 할 수 있습니다. 헤더 중복이 있는 경우, 중복을 검출하고, 해당 테이블의 `index`와 중복 되지 않은 `Header` 정보를 `Huffman Encoding` 방식으로 인코딩 할 수 있습니다.
41 |
42 |
43 | 
44 |
--------------------------------------------------------------------------------
/Computer Science/Network/https-ssl-tls.md:
--------------------------------------------------------------------------------
1 | # HTTPS와 SSL/TLS
2 |
3 | 
4 |
5 |
6 | 요즘 웬만한 사이트들은 접속할 때 HTTP가 아닌 HTTPS를 사용하고 있다.
7 |
8 | HTTP와 HTTPS에는 어떤 차이점이 있는지, HTTPS 통신 연결에는 어떤 방법들이 쓰이는지 알아보도록 하자.
9 |
10 | ## HTTP와 HTTPS
11 |
12 | **HTTP**(HyperText Transfer Protocol)는 어플리케이션 계층(7계층)에서 작동하는 프로토콜로, **TCP/IP**를 기반으로 한다. Well-Known Port로 80번을 사용한다. HTTP는 암호화되지 않은 평문을 전송하는 프로토콜이므로, 패킷 감청을 통해 송신자/수신자가 아닌 제3자가 정보를 들여다볼 수 있는 위험성이 존재한다. 이러한 문제를 해결하기 위해 등장한 것이 **HTTPS**이다.
13 |
14 | **HTTPS**(HTTP Secure)는 **HTTP**에 데이터 암호화가 추가된 프로토콜이다. Well-Known Port로 443번을 사용한다. 암호화를 사용하기 때문에 제3자가 패킷을 감청해도 어떤 정보인지 알 수 없다. 또한 정보를 주고받는 서버가 신뢰할 수 있는 서버인지 판별할 수 있도록 도와준다.
15 |
16 | > HTTPS = HTTP + SSL/TLS
17 | >
18 |
19 | ## SSL/TLS
20 |
21 | - SSL : Secure Sockets Layer
22 | - TLS : Transport Layer Security
23 |
24 | **SSL/TLS**는 **HTTPS**를 사용하기 위해 안전한 보안 채널을 생성해주는 프로토콜이다. **SSL**은 1990년대 후반 등장한 프로토콜로, 여러 알려진 취약점으로 인해 현재는 사용되지 않는 프로토콜이다. **SSL**의 대안으로 등장한 것이 **TLS**로, **SSL**과 **TLS**를 흔히 혼용하여 부르고 있지만 실제 사용되는 프로토콜은 **TLS**이다.
25 |
26 | 
27 |
28 | **SSL/TLS**는 7계층의 **HTTP**와 4계층의 **TCP** 사이에 위치한다.
29 |
30 | ## CA(Certificate Authority)와 SSL 인증서
31 |
32 | SSL **인증서**는 SSL 프로토콜에서 사용되는 인증서로, 공인된 **CA** 기관에서 발급한다. SSL **인증서**는 다음과 같은 역할을 하며, 아래의 정보를 담고 있다.
33 |
34 | ### 인증서의 역할
35 |
36 | - Client가 접속한 사이트(Server)가 신뢰할 수 있는 Server임을 **보증**한다.
37 | - 통신 과정에서 사용할 **Server의 공개 키**를 Client에 전달한다.
38 |
39 | ### 인증서에 담겨있는 정보
40 |
41 | - CA 정보와 사이트의 도메인 등
42 | - **Server의 공개 키**
43 |
44 | 대개 브라우저들은 신뢰할 수 있는 공인 CA들의 리스트와, **각 CA들의 공개 키**를 알고 있다. SSL 인증서가 구체적으로 어떻게 이용되는지는 아래의 SSL Handshake를 통해 알 수 있다.
45 |
46 | ## SSL/TLS에서의 암호화 방식
47 |
48 | ### 대칭키 방식
49 |
50 | - 동일한 하나의 키, 즉 대칭키로 암호화와 복호화를 하는 방식이다.
51 | - 공개키 방식에 비해 속도가 빠르지만, 암호 통신을 하기 위해 대칭키를 주고받는 문제에서 키가 유출되는 등의 **키 교환 문제**가 발생할 수 있다.
52 |
53 | ### 공개키(비대칭키) 방식
54 |
55 | - 한 쌍의 {**공개키, 비밀키**}를 통해 암호화와 복호화를 하는 방식이다. 즉, 공개키로 암호화하면 비밀키로 복호화, 비밀키로 암호화하면 공개키로 복호화할 수 있다.
56 | - 대칭키 방식에 비해 보안이 뛰어나지만, 상대적으로 속도가 느리다.
57 |
58 | 두 방식의 장단점을 고려하여, SSL/TLS에서는 실제 데이터를 주고받기 위해 **대칭키**를 사용하고, 이 대칭키를 주고받기 위해 **공개키** 방식을 이용한다.
59 |
60 | ## SSL Handshake (TLS 1.2 버전에서)
61 |
62 | TLS Handshake는 TCP Handshake를 통해 연결을 생성한 뒤 실시한다.
63 |
64 | 
65 |
66 | ### 0. Server는 CA를 통해 SSL 인증서를 생성한다.
67 |
68 | 1) 사이트(Server)는 CA에 사이트 정보와 사이트 공개 키를 보낸다.
69 |
70 | 
71 |
72 | 2) CA는 CA의 비밀 키를 이용해 사이트 정보와 사이트 공개 키를 암호화하여 인증서를 생성해 사이트에 전달한다.
73 |
74 | 
75 |
76 | ### 1. ClientHello (Client → Server)
77 |
78 | Client가 Server에 TLS 연결을 시도하며 패킷을 보낸다. 보내는 패킷에는 아래의 정보 등이 담겨있다.
79 |
80 | - 사용 가능한 Cipher Suite 목록
81 | - Session ID
82 | - TLS Protocol Version
83 | - Client Random Byte (무작위 키)
84 |
85 | 아래는 Cipher Suite의 한 예이다. (이미지 출처 [https://steady-coding.tistory.com/512](https://steady-coding.tistory.com/512))
86 |
87 | 
88 |
89 | ### 2. ServerHello (Server → Client)
90 |
91 | Server는 Client로부터 ClientHello 패킷을 받고, CipherSuite 목록에서 하나를 선택한다.
92 |
93 | 아래의 정보 등을 담아 ServerHello 패킷을 Client로 보낸다.
94 |
95 | - 선택한 Cipher Suite
96 | - TLS Protocol Version
97 | - Server Random Byte (무작위 키)
98 |
99 | ### 3. Certificate (Server → Client)
100 |
101 | Server의 TLS 인증서를 Client에 전달한다. 이때 TLS 인증서는 CA의 비밀 키로 암호화된 상태이며, CA의 공개 키는 누구에게나 공개되어 있다.
102 |
103 | 
104 |
105 | Client는 CA의 공개 키를 이용해 TLS 인증서를 복호화한다. 복호화에 성공하면 해당 인증서는 CA가 서명한 진짜 인증서임을 검증한 것으로 볼 수 있다. (Authentication)
106 |
107 | 
108 |
109 | ### 4. Client Key Exchange (Client → Server)
110 |
111 | Client는 Random한 Pre-master key를 생성한 뒤, 3)에서 TLS 인증서 복호화를 통해 얻어낸 Server의 공개 키로 암호화하여 서버로 전송한다.
112 |
113 | 
114 |
115 | Server는 자신의 비밀 키로 이것을 복호화하여 Pre-master key를 얻어낸다.
116 |
117 | 
118 |
119 | Server와 Client는 주고받은 Client Random Byte, Server Random Byte, Pre-master key를 이용해 각자 독립적으로 master key를 만들어내고, 일련의 과정을 통해 이를 session key로 만들어낸다. Client와 Server가 만든 세션 키는 동일하고, 이를 앞으로 데이터를 주고받을 때 암호화할 대칭 키로 사용한다.
120 |
121 | 
122 |
123 | > 자료마다 해당 단계에서 대칭 키를 생성하는 방식이 조금씩 상이하나, Client가 Server로 보낸 어떤 ‘무엇인가'를 이용해 결과적으로 대칭 키를 얻는다는 점은 같다.
124 | >
125 |
126 | ### 5. ChangeCipherSpec / Finished (Client ↔ Server)
127 |
128 | 교환할 정보를 모두 교환하여 통신할 준비가 다 되었음을 알린 뒤(ChangeCipherSpec), SSL Handshake를 종료한다. (Finished)
129 |
130 | SSL Handshake가 끝나면 Client와 Server는 각자 갖고 있는 대칭키를 이용해 데이터를 암호화하여 주고받는다.
131 |
132 | 
133 |
--------------------------------------------------------------------------------
/Computer Science/Network/images/http-1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Computer Science/Network/images/http-1.png
--------------------------------------------------------------------------------
/Computer Science/Network/images/http-2.jpeg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Computer Science/Network/images/http-2.jpeg
--------------------------------------------------------------------------------
/Computer Science/Network/images/http-3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Computer Science/Network/images/http-3.png
--------------------------------------------------------------------------------
/Computer Science/Network/images/when-we-1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Computer Science/Network/images/when-we-1.png
--------------------------------------------------------------------------------
/Computer Science/Network/images/when-we-2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Computer Science/Network/images/when-we-2.png
--------------------------------------------------------------------------------
/Computer Science/Network/images/when-we-3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Computer Science/Network/images/when-we-3.png
--------------------------------------------------------------------------------
/Computer Science/Network/images/when-we-4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Computer Science/Network/images/when-we-4.png
--------------------------------------------------------------------------------
/Computer Science/Network/when-we-enter-the-website.md:
--------------------------------------------------------------------------------
1 | ## 우리가 웹 사이트를 접속 할 때 일어나는 일
2 | 우리가 **Google Chrome** 같은 웹 브라우저를 통해서 웹 사이트를 접속 한다고 가정 합니다.
3 |
4 | 예를 들어 `ce.khu.ac.kr`에 접속 한다고 가정 하겠습니다.
5 |
6 | - 제일 먼저 **OSI 7 계층**에 대해서 알아 보겠습니다.
7 | - **OSI 7 계층**은 네트워크를 구성하는 표준 계층 중 하나 입니다.
8 | - 이렇게 7계층으로 나눈 이유는, 이렇게 분리 함으로써 **독립적으로 문제를 해결 할 수 있기 때문입니다.**
9 |
10 | 1. 물리(Physical) 계층
11 | - 데이터를 전기적인 신호로 변환하여, **물리적으로 주고 받는 계층**입니다.
12 | - 케이블, 허브 등이 해당 됩니다.
13 | 2. 데이터 링크(Data Link) 계층
14 | - 물리 계층으로 송수신 하는 정보를 관리하여, **안전하게 전달**되도록 하는 역할을 합니다.
15 | - 각 기기마다 **고유한 Mac 주소를 이용**하여 통신 합니다.
16 | - 전송 단위는 **Frame**이며, 사용 장비로는 브릿지, 스위치 등이 해당 됩니다.
17 | 3. 네트워크(Network) 계층
18 | - 데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능을 담당 합니다. 우리가 흔히 아는 IP주소를 제공하며, 해당 IP 주소를 이용하여, 데이터를 전송 합니다.
19 | - 전송 단위는 **Packet**이며, 장비로는 **라우터, L3** 스위치가 있습니다.
20 | 4. 전송(Transport) 계층
21 | - 우리가 흔히 아는 **TCP, UDP**가 여기에 속합니다.
22 | - **Endpoint** 사이의 신뢰성 있는 정확한 데이터 전송을 담당합니다. 오류 검출 및 복구, 흐름제어와 중복검사 등을 수행 합니다.
23 | - **Port** 번호를 사용 합니다.
24 | - 전송 단위는 **Segment** 입니다.
25 | 5. 세션(Session) 계층
26 | - 데이터가 통신하기 위한 논리적 연결을 담당합니다. TCP/IP 세션을 만들고 없애는 책임을 가지고 있습니다.
27 | - 대표적으로 **RPC, Socket** 등이 있습니다.
28 | 6. 표현(Presentation) 계층
29 | - 데이터 표현에 대한 독립성을 제공하고 암호화하는 역할을 담당합니다.
30 | - 파일 인코딩, 명령어 포장, 압축, 암호화를 담당 합니다.
31 | 7. 응용(Application) 계층
32 | - 응용 프로세스와 직접 관계하여, 일반적인 응용 서비스를 수행 합니다.
33 | - 대표적으로 우리가 알고 있는 **HTTP, FTP** 등의 프로토콜이 해당 됩니다.
34 |
35 | - 웹 브라우저는 URL에 적힌 값에 따라, 적절히 **HTTP Request Message**를 만듭니다.
36 | - 일단 유저가 어디서 접속하는지, 주로 쓰는 언어가 무엇인지, 어떤 기계를 사용하고 있는지에 따라서 **HTTP Header**를 적절하게 설정 합니다.
37 | - 다른 **메서드**의 사용 없이, 웹 브라우저를 통해 **조회** 하는 것이기 때문에 method 에는 **GET**이 사용 됩니다.
38 | - accept-language는 사용 하는 언어, user-agent에는 사용 하는 기기, accept에는 받을 데이터 타입, accept-encoding에는 사용 가능한 인코딩, cookie에는 사용자가 저장하고 있는 쿠키가 될 것입니다.
39 | - 일단 `ce.khu.ac.kr` 이라는 **DNS**를 통해서 접근 하였을 테니, 도메인에 매칭되는 IP를 찾기 위한 **DNS Lookup**이 시작 될 것 입니다. 첫 번째는 **브라우저에 저장 된 값**, 두 번째는 **각 컴퓨터의 hosts 파일** (운영체제에 따라 다름, 맥은 /etc/hosts), 세 번째는 **DNS Server**를 뒤질 것 입니다.
40 | - **DNS Server**를 뒤질 때는 다음과 같은 과정으로 **Recursive Query**를 이용하여 파일을 뒤집니다.
41 |
42 |
43 | 
44 |
45 | - IP를 찾았다면 이제 요청을 하자고 할 시간 입니다. **TCP/IP**를 이용한, **Socket** (5계층) 기반의 **HTTP/1.1** (7계층) 프로토콜을 이용하여 통신을 시작 합니다.
46 | - **TCP/IP**의 연결은 다음과 같은 과정을 가집니다. 연결을 위해 **3 way handshake**를, 연결 해제를 위해 **4 way handshake**를 실시 합니다.
47 |
48 | 
49 |
50 |
51 | 
52 |
53 |
54 | - **Socket** 단위에서는 통신을 하기 위해서 다음과 같은 과정이 발생 합니다. **Socket**을 이용 하지만, 양방향 통신을 하지는 않습니다.
55 |
56 | 
57 |
58 |
59 | - **HTTP/1.1** 에서는 아까 만든 **HTTP Request Header**를 전송 합니다. **OSI 7 계층을 통해서** 통신을 시작 합니다.
60 | - 이제 구글 서버에서는 **HTTP Request Header**에 있는 값을 받아, 서버 어플리케이션이 만들어 놓은 로직에 따라서 적당한 응답을 만들어 냅니다.
61 | - 구글 로그인이 되어 있다면, 유저가 누구냐에 따라서 **Dynamic**한 응답을 만들어 냅니다.
62 | - 공통적으로 필요한 파일 같은 경우 (로고, 레이아웃 css, js)등은 **Static**하게 응답을 보냅니다.
63 | - 어떤 데이터를 보냈는지 알려주기 위해, **Content-type, Content-Length, Date**를 **HTTP Response Header**에 말아 보냅니다.
64 | - 캐시, 쿠키를 관리 하기 위해, **cache-control, set-cookie** 등의 헤더를 보냅니다.
65 |
66 | - 이 응답을 유저가 받아, 웹 브라우저는 적절하게 랜더링 합니다.
67 | - 여기서 HTTP/1.1 이라서 발생 하는 문제가 있습니다. 그 다음 내용은, **HTTP/1.1과 HTTP/2.0의 차이점**을 참고하세요.
68 |
--------------------------------------------------------------------------------
/Computer Science/Operating System/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Computer Science/Operating System/.gitkeep
--------------------------------------------------------------------------------
/Frontend/Android/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Frontend/Android/.gitkeep
--------------------------------------------------------------------------------
/Frontend/Android/images/mvvm-design-pattern-01.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Frontend/Android/images/mvvm-design-pattern-01.png
--------------------------------------------------------------------------------
/Frontend/Android/images/mvvm-design-pattern-02.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Frontend/Android/images/mvvm-design-pattern-02.png
--------------------------------------------------------------------------------
/Frontend/Android/images/mvvm-design-pattern-03.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Frontend/Android/images/mvvm-design-pattern-03.png
--------------------------------------------------------------------------------
/Frontend/Android/images/mvvm-design-pattern-04.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Frontend/Android/images/mvvm-design-pattern-04.png
--------------------------------------------------------------------------------
/Frontend/Android/images/mvvm-design-pattern-05.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Frontend/Android/images/mvvm-design-pattern-05.png
--------------------------------------------------------------------------------
/Frontend/Android/images/mvvm-design-pattern-06.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Frontend/Android/images/mvvm-design-pattern-06.png
--------------------------------------------------------------------------------
/Frontend/Android/mvvm-design-pattern.md:
--------------------------------------------------------------------------------
1 | # Android에서 MVVM 패턴이 중요한 이유
2 | ___
3 |
4 | ## → Architecture Pattern이란
5 | >
6 | > An **architectural pattern** is a general, reusable solution
7 | > to a commonly occurring problem in software architecture
8 | > within a given context.
9 | >
10 | 위키피디아에서는 아키텍처 패턴을 "주어진 컨텍스트 내에서, 소프트웨어 아키텍처에서 주로 발생하는 문제에 대한 일반적이고, 재사용 가능한 솔루션"이라고 정의합니다.
11 | 여기서 **소프트웨어 아키텍처에서 주로 발생하는 문제**라 함은, 서비스를 구현하고 유지-보수의 단계에 이르기까지 개발자가 직면하는 모든 상황을 일컫는 말입니다.
12 | 필자는 그러한 케이스들을 '특정한 형식을 취하여' 쉽게 풀어나갈 수 있도록 하는 **약속의 소프트웨어적 구현 방식**을 '아키텍처 패턴'이라고 생각합니다.
13 | ___
14 |
15 | ## 🗂️ Architecture Pattern의 종류
16 | 이 단락에서는 순서대로 **MVC, MVP, MVVM** 패턴으로 구현된 애플리케이션의 기본적인 Data Flow에 대해 다룹니다.
17 |
18 | ### 0️⃣ 기본 용어 정리 (Frontend 기준)
19 | | 용어 | 의미 |
20 | |:---|:---|
21 | |**View**|사용자가 **화면에서 보는 것들**에 대한 구조, 배치, 그리고 외관.|
22 | |**Model**|**Data와 Data를 가져오는 Logic**을 통틀어 이르는 말.|
23 | |**Controller**|Model에 명령을 보내 그 상태를 변경 & View에 명령을 보내 Model의 표시 방법 변경.|
24 | |**Presenter**|View가 요청하는 Data를 Model로부터 가져와, 이를 가공하여 View에 전달.|
25 | |**ViewModel**|View의 **추상화된 형태**(Abstraction). View에 보여지는 데이터와 명령들을 가지고 있음. |
26 |
27 | ___
28 | ### 1️⃣ Model-View-Controller
29 |
30 | 
31 |
32 |
33 | **특징: Model과 View 사이의 의존성이 강함**
34 |
35 | 1. Controller로 사용자의 입력이 들어옵니다.
36 | 2. Controller는 Model의 데이터를 업데이트하거나, 사용자가 요청한 데이터를 불러오고,
37 | 3. Model은 해당 데이터를 보여줄 View를 선택해서 화면에 보여주게 됩니다.
38 |
39 | ___
40 | ### 2️⃣ Model-View-Presenter
41 |
42 | 
43 |
44 |
45 | **특징: Presenter와 View 사이의 의존성이 강함 (1:1로 대응.)**
46 |
47 | 1. View를 통해 사용자의 특정한 입력이 들어옵니다.
48 | 2. View는 Presenter에 작업(데이터 업데이트 및 필요한 데이터 가져오기) 요청을 합니다.
49 | 3. Presenter가 필요한 데이터를 Model에 요청합니다.
50 | 4. Model은 Presenter가 요청한 데이터를 응답으로 내보냅니다.
51 | 5. Presenter는 View에 데이터를 내보냅니다.
52 | 6. View는 Presenter로부터 받은 데이터로 각각의 View Component들이 구성됩니다.
53 |
54 | ___
55 | ### 3️⃣ Model-View-ViewModel
56 |
57 | 
58 |
59 |
60 | **특징: View와 ViewModel이 n:1로 대응 → ViewModel Class의 재활용성 ⬆️**
61 |
62 | 1. View를 통해 사용자의 입력이 들어오면, Command Pattern으로 ViewModel에 특정 Action을 전달합니다.
63 | 2. ViewModel은 필요한 데이터를 Model에 요청합니다.
64 | 3. Model은 ViewModel에 요청한 데이터를 넘겨줍니다.
65 | 4. ViewModel은 응답 받은 데이터를 가공해서 **View의 상태(State)를 Hold**합니다.
66 | 5. View는 ViewModel과의 **Data Binding**을 통해 자동으로 갱신됩니다.
67 | (이를 View가 ViewModel이 가진 Data를 **Observe**, 즉 관찰한다고 표현합니다.)
68 |
69 | ___
70 | ## 🏁 MVVM Pattern을 권장하는 이유
71 |
72 | ### 1️⃣ Seperation of Concerns: 관심사 분리
73 |
74 |
75 | 
76 |
77 |
78 | - Android에서는(다른 Frontend 개발과 비슷하게) 애플리케이션의 시스템을 크게 세 가지 계층(layer)으로 구분하여 설계합니다.
79 | **UI Layer**, **Domain Layer**(선택사항), **Data Layer**가 바로 그것입니다.
80 | - 어떤 아키텍처 패턴을 사용하든지 간에, 세 Layer에 각각의 역할을 적절하게 부여하여,
81 | 다른 모든 SW 개발과 마찬가지로 [관심사 분리 원칙](https://en.wikipedia.org/wiki/Separation_of_concerns)을 충실히 이행해야 합니다.
82 | - 주로, Android Native 개발에서 위 원칙을 위반하는 경우는 **`Activity`나 `Fragment`에 모든 코드를 작성하는 실수**로 인해 발생합니다.
83 | - `Activity`나 `Fragment`와 같은 UI-Based Class는 User Interface,
84 | 그리고 User와의 상호작용(ex. 버튼 클릭 등)을 처리하는 로직만을 포함해야 합니다.
85 | - 이러한 Class를 최대한 가볍게 유지하는 것이 Component Lifecycle와 관련된 문제를 피하고,
86 | 테스트 유용성 및 유지/보수의 용이성을 높이는 데 도움이 됩니다.
87 |
88 | ### ☑️ Why not MVC : 비대해지는 UI Controller
89 |
90 | 
91 |
92 |
93 | - 안드로이드에 MVC 아키텍처 패턴을 적용하는 것이 어려운 이유는, 위에서 언급한 **관심사 분리 원칙을 정면으로 위배**하는 행위이기 때문입니다.
94 | - Android Native에서 Controller에 해당하는 역할을 수행하는 Class가 바로 `Activity`와 `Fragment`인데,
95 | 이 둘은 UI-based Class로서의 기능도 해야 합니다. `.xml` 파일은 그저 UI Component를 보여주는 역할만 수행할 뿐 입니다.
96 | - MVC로 프로젝트를 구성하게 되면, `Activity`와 `Fragment`가 User와의 상호작용은 물론,
97 | Model과의 상호작용(데이터 요청 및 수정)도 동시에 담당하게 되므로, 관심사 분리 원칙에서 언급한 **실수**가 일어나게 됩니다.
98 | - 여러 기능을 구현할수록, Controller에 해당하는 코드의 양이 비대해지며, 이는 유지/보수를 어렵게 합니다.
99 |
100 | ___
101 | ### 2️⃣ Unidirectional Data Flow: 단방향 데이터 흐름
102 |
103 | 
104 |
105 |
106 | - Android Native에서, 단방향 데이터 흐름 패턴(이하 **UDF 패턴**)을 충족한다는 것은,
107 | 1️⃣ **상태(State or Data)는 Data Layer에서 UI Layer로 흐른다는 것**,
108 | 2️⃣ **데이터 흐름을 수정하게 되는 이벤트(User Action)는 UI Layer에서 Data Layer 방향으로 흐른다는 것을** 의미합니다.
109 | - 이는 데이터 관리의 안정성을 강화하며, 오류가 발생할 가능성을 크게 낮춥니다.
110 | - Android에서는 이러한 흐름을 다음과 같은 구성으로 구현합니다. (Event 흐름 기준)
111 | - UI Layer : **UI Elements (View or Jetpack Compose)** -> **State Holder(ViewModel Class)** ->
112 | - Data Layer : -> **Repositories** ->**Data Source(A Network Source, a File, or a local DB)**
113 | - 위에서 State Holder의 역할은 MVP 패턴에서는 Presenter가, MVVM 패턴에서는 ViewModel이 담당합니다.
114 |
115 | ### ☑️ State Holder : ViewModel vs. Presenter
116 |
117 | ##### 공통점
118 | - Android Native에서 **MVP와 MVVM 패턴의 공통점은 `Activity`와 `Fragment`가 User와의 상호작용만을 담당한다는 것**입니다.
119 | - 두 아키텍처 패턴은 관심사 분리 원칙에 온전히 부합하며, 단방향 데이터 흐름 패턴을 가집니다.
120 | - 위에서 언급하지 않은 내용이지만, MVC에서는 View가 사실상 Controller와 결합된 형태라, 유닛 테스트 구성이 번거롭습니다.
121 | 하지만 MVP의 경우, State Holder가 특정 View와 결합되지 않기 때문에, 가상 뷰를 구현하는 방식으로 유닛 테스트을 진행할 수 있습니다.
122 |
123 | ##### 차이점
124 | - 그러나 **MVVM의 ViewModel은 MVP의 Presenter와 달리, View에 대한 의존성을 전혀 가지고 있지 않습니다.**
125 | - **Data Binding과 (ViewModel에 존재하는) Observable(관찰 가능한) 변수**는 보다 애플리케이션의 반응 속도를 높여줍니다.
126 | - MVP에서처럼 가상 뷰를 만드는 방식이 아니라, 그저 Observable 변수가 제대로 설정되었는지 확인하는 것 만으로 유닛 테스트가 가능해집니다.
127 | - Android의 AAC(Android Architecture Component, Jetpack에 포함된 라이브러리) ViewModel은
128 | 여러 Fragment가 **공통된 데이터를 각자가 담당한 View에 Binding할 수 있도록 구현**되어 있으므로 (데이터 공유 역할),
129 | Presenter에 비해 재활용성이 높다는 점도 큰 장점입니다.
130 |
131 |
132 |
133 | ___
134 | ## 🧭 References
135 | - [영문판 위키피디아 - Architectural Pattern](https://en.wikipedia.org/wiki/Architectural_pattern)
136 | - [Guide to App Architecture - Android Developer (4,6번 이미지 출처)](https://developer.android.com/jetpack/guide?hl=en)
137 | - [안드로이드의 MVC, MVP, MVVM 종합 안내서](https://academy.realm.io/kr/posts/eric-maxwell-mvc-mvp-and-mvvm-on-android/)
--------------------------------------------------------------------------------
/Frontend/Flutter/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Frontend/Flutter/.gitkeep
--------------------------------------------------------------------------------
/Frontend/React.js/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Frontend/React.js/.gitkeep
--------------------------------------------------------------------------------
/Frontend/iOS/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Frontend/iOS/.gitkeep
--------------------------------------------------------------------------------
/Language/Go/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Language/Go/.gitkeep
--------------------------------------------------------------------------------
/Language/Java/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Language/Java/.gitkeep
--------------------------------------------------------------------------------
/Language/Java/images/solid-pattern-01.jpeg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Language/Java/images/solid-pattern-01.jpeg
--------------------------------------------------------------------------------
/Language/Java/images/solid-pattern-02.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Language/Java/images/solid-pattern-02.png
--------------------------------------------------------------------------------
/Language/Java/images/solid-pattern-03.jpeg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Language/Java/images/solid-pattern-03.jpeg
--------------------------------------------------------------------------------
/Language/Java/images/solid-pattern-04.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Language/Java/images/solid-pattern-04.png
--------------------------------------------------------------------------------
/Language/Java/images/solid-pattern-05.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Language/Java/images/solid-pattern-05.png
--------------------------------------------------------------------------------
/Language/Java/images/solid-pattern-06.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Language/Java/images/solid-pattern-06.png
--------------------------------------------------------------------------------
/Language/Java/jvm.md:
--------------------------------------------------------------------------------
1 | # JVM의 메모리 구조
2 |
3 | ## **JVM (Java Virtual Machine; 자바 가상 머신)**
4 |
5 | 자바가 아닌 C나 C++등으로 작성한 코드를 컴파일하면, 각기 다른 운영체제에서 실행할 수 있는 어셈블리어로 번역된 결과물을 얻을 수 있다. 즉, 컴파일 과정이 운영체제에 종속적이다, 그러나 자바에서는 컴파일 과정이나 컴파일 결과물이 아닌, 이러한 결과물을 실행하는 JVM(Java Virtual Machine)이 운영체제에 종속적이다.
6 |
7 | 자바 언어로 프로그램 코드를 작성한 뒤 (`java` 파일), JAVAC 컴파일러를 이용해 컴파일하면 바이트 코드 파일(class 파일)을 생성할 수 있다. 맥이든 윈도우든 `class` 파일만 있다면 각기 다른 운영체제의 JVM이 이를 기계어로 번역해 실행시켜준다. 따라서 프로그래머가 프로그램을 실행하는 운영체제를 신경 쓰지 않고 프로그래밍할수 있다는 장점이 있다.
8 |
9 | ---
10 |
11 | ## **JVM의 메모리 구조 (Runtime Data Area)**
12 |
13 | JVM이 시작되면 운영체제로부터 메모리 영역을 할당받는데, 아래와 같이 5개의 영역으로 나눌 수 있다.
14 |
15 | 
16 |
17 | ### 스레드가 공유하는 영역
18 |
19 | - **메소드 영역 (Method Area)**
20 |
21 | 클래스별로 런타임 상수풀(runtime constant pool), 필드 데이터, 메소드 데이터, 메소드 코드, 생성자 코드 등을 저장한다. `static` 변수에 관한 정보도 메소드 영역에 저장된다.
22 | 한마디로, 클래스의 바이트 코드들이 저장된다.
23 |
24 |
25 | - **힙 영역 (Heap Area)**
26 |
27 | 힙 영역은 객체와 배열이 생성되는 영역이다. (참고로 C/C++과는 다르게, 자바에서는 배열 또한 객체로 존재한다.) `new` 연산자를 통해 객체 또는 배열을 생성하면 이 영역에 저장된다. JVM 스택 영역의 변수나 다른 객체의 필드에서 객체를 참조한다면, 바로 이 Heap 영역에 존재하는 객체를 참조하는 것이다.
28 |
29 | C에서는 `malloc`과 `free`, C++에서는 `new`와 `delete`를 이용해 객체를 동적 할당하고 필요 없는 객체는 동적 할당을 해제한다. 그러나 Java에서는 프로그래머가 직접 메모리 영역에 손을 댈 수 없기 때문에 할당을 해제할 수 없다. 대신 JVM의 Garbage Collector가 자동으로 필요 없는 객체를 메모리에서 대신 제거해 준다. 참조되지 않는 객체를 쓰레기로 간주하고 힙 영역에서 제거한다.
30 |
31 |
32 | ### 스레드마다 존재하는 영역
33 |
34 | - **JVM 스택 영역 (Stack Area)**
35 |
36 | 각 스레드마다 하나씩 존재한다. 각 스레드에서 메소드를 호출할 때마다 프레임(Frame)을 추가하고, 메소드 실행이 종료되면 해당 프레임을 제거한다. 프레임 내부에는 로컬 변수 스택이 있다. 로컬 변수 스택에는 기본 타입(primitive type) 변수와 참조 타입(reference type) 변수가 존재한다. 기본 타입 변수는 스택 영역에 직접 값을 가지고 있다(`char`, `int`형 등등). 반면에 참조 타입 변수는 힙 영역에 존재하는 객체의 주소값을 이용해 객체를 참조한다(`String`, `Integer` 등등).
37 |
38 |
39 | - **PC (Program Counter) Register**
자바 스레드마다 존재하는 프로그램 카운터 값을 저장한다. 현재 실행 중인 JVM 명령어의 주소를 저장한다.
40 |
41 |
42 | - **Native Method Stack**
43 |
44 | 자바가 아닌, C/C++ 등 다른 언어로 작성된 코드를 실행하기 위한 영역이다.
45 |
46 |
47 | ---
48 |
49 | ## 참고자료
50 |
51 | - 이것이 자바다, 신용권 저, 한빛미디어
52 | - [JVM 구조와 자바 런타임 메모리 구조 (자바 애플리케이션이 실행될 때 JVM에서 일어나는 일, 과정을 설명해줄 수 있나요?)](https://jeong-pro.tistory.com/148)
53 | - [JAVA :: 자바의 메모리 구조 - 1. 메소드 영역(Method Area)](https://blog.wanzargen.me/16)
54 |
--------------------------------------------------------------------------------
/Language/Java/solid.md:
--------------------------------------------------------------------------------
1 | ### SOLID 원칙
2 | **SOLID 원칙**은 **객체지향 설계**에서 지켜줘야 하는 5가지 원칙을 의미 합니다.
3 |
4 | 우리는 협업을 하면서, 많은 어려움을 봉착 합니다. 분명 기능 1개만 수정 한다고 특정 컴포넌트의 코드를 몇 가지 수정했는데, **이와 연관된 여러 개의 컴포넌트에서 오류**를 뱉어 버리는 경우는 개발을 해보신 분들이라면 많이 경험해 봤을 것이라고 생각해요.
5 |
6 |
7 | 
8 |
9 | 테스트 서버에 불이 났습니다.
10 |
11 |
12 |
13 |
14 | ### SRP(Single Responsibility Principle), 단일 책임 원칙
15 | 이는 간단한 원칙입니다. **한 가지 객체는, 한 가지 기능만 해야 한다**는 것입니다. 원래 이 원칙을 제안한 로버트의 말은 다음과 같습니다. **"어떤 클래스를 변경해야 하는 이유는, 오직 하나뿐이어야 합니다."**
16 |
17 | 객체지향적으로 클래스를 설계시에는 **결합도를 낮게, 응집도를 높게** 설계 하여야 합니다.
18 |
19 | - **결합도**: 프로그램의 **서로 다른 모듈들**이 **서로 얼마나 의존적**인지를 의미 합니다.
20 | - **응집도**: **같은 모듈 내부의 요소**들이 **서로 얼마나 관련되어 있는지**를 의미 합니다.
21 |
22 | 우리는 **SRP** 원칙을 지켜 이를 해결 하고자 합니다.
23 |
24 | 우리가 프로그램을 짤때, **한 가지 역할**을 하는 코드를 수정을 해야 하는 경우가 있습니다. 이를 위해서 코드 내의 **클래스**를 변경 하게 되는데, 여기서 **해당 클래스가 여러 개의 역할에 걸쳐 있는 경우** 클래스 수정 시, 다른 역할에서는 제대로 동작 하지 않을 수 있습니다.
25 |
26 | 대충 역할이 어떤 느낌인지는 알겠는데, 정확히 어떤 의미를 갖는지는 아직 아리까리 합니다. 한 객체 마다 여러 가지 메서드가 있고, 다중 상속을 할 수도 있고, 클라이언트가 여럿 일 수도 있기 때문입니다. 그래서 이 의문을 해결하기 위해, 우리는 **역할**을 **액터**라는 개념으로 치환 하려고 합니다. 여기서 **액터**는, **시스템 내에서 동일한 방식으로 변경되기를 원하는 사용자 집단**을 의미 합니다.
27 |
28 | 만약 **TCP**를 처리 하는 객체가 있다고 가정 하겠습니다. 요구 사항이 **"TCP 통신을 하기 위한 액터"** 라는 것으로 이해 하고, 여러 개의 API를 TCP 객체로 만들었다고 가정 하겠습니다. 그러면 우리는 수정 하려고 하는 객체가 **TCP 통신을 하기 위한 엑터**라고 알고 있기 때문에, 원래 하던 역할을 벗어나지 않는 선에서 변경이 가능 한 것입니다. 누가 이 객체를 **다른 용도**로 사용 하지 않는다면요. 해당 엑터가 역할을 수행 할 수 없게 되지 않는 이상, 또한, 이를 사용하는 다른 코드가 모두 해당 변경에 대해서 수용 할 수 있다면, 그러면 문제가 되지 않는 것 입니다.
29 |
30 | `Desktop` 이라는 클래스가 있고, `A`와 `B`라는 클래스가 있다고 가정 하겠습니다. 만약 `A`와 `B`가 멤버변수로 `Desktop`을 참조 하는데, `A`의 용도에 맞게 `Desktop`의 성능을 줄이고 휴대가 가능하게 끔 하고 싶습니다. 그래서 `A`가 `Desktop`의 성능을 줄이고, 휴대가 가능하게 기능을 수정 했습니다. 하지만, `B`가 애초에 성능이 좋은 컴퓨터를 요구 한 것이라면요? 사실 이건 `A`가 `Desktop`을 참조 할 것이 아닌, 새롭게 `Notebook`이라는 친구를 만들어서 `A`에 맞게 만드는 게 맞습니다. **`Desktop`의 역할은 이를 사용 하는 같은 엑터들 끼리 약속이 된 사항이거든요.**
31 |
32 |
33 | 
34 |
35 | 차라리 나누어 관리 할 것.
36 |
37 |
38 |
39 | ### OCP(Open-Closed Principle), 개방 폐쇄 원칙
40 | **개방 폐쇄 원칙**은 **"확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다."**를 의미 합니다. 더 정확한 표현으로는 **"기능의 변경 및 확장은 필요 하지만, 그 기능을 사용 하는 코드를 수정 하지 않는 것 입니다."**
41 |
42 | 예를 들어 보겠습니다. 우리가 어떤 **API**를 사용 하고 있었습니다. 그런데 어느날 **API**가 업데이트가 됐고, 기존 코드가 사용 불가능 하게 되었습니다. 이를 다른 방법으로 사용해야 하기 때문이에요. 이는 **OCP**를 위반 한 대표적인 사례 입니다. 하나의 변화가 연쇄적으로 변화를 일으키기 때문이에요.
43 |
44 | 우리는 이를 해결하는 방법으로, **추상화**를 선택 할 수 있습니다. 내가 아무리 객체 내의 코드를 수정 하고, 확장 한다고 해도, **추상화**된 메서드를 목적에 맞게 구현 하는 것이 강제 되고, 또 코드에선 **추상화**된 부분에 대해서만 사용 한다면, 하나의 변화로 인해, 연쇄적인 변화가 이루어지는 것을 방지 할 수 있습니다. 그리고 외부에서는 코드가 바뀐 것을 모르게 작성 해야 합니다. 그것도 중요한 포인트에요. 다른 사람들이 이 코드의 변경 사항을 모른다면,
45 |
46 | 예를 들어 아래 처럼, 사용 하는 데이터베이스가 다르더라도, **Driver Manager**라는 부모 클래스로 묶어서 관리 할 수 있는 것이죠. **Driver Manager**에 대한 코드만 사용 한다면, 우리가 데이터베이스가 바뀌더라도, 문제 없이 사용 할 수 있을 것입니다.
47 |
48 |
49 | 
50 |
51 | JDBC Driver Manager
52 |
53 |
54 |
55 |
56 | ### LSP(Liskov Substitution Principle), 리스코프 치환 법칙
57 | 이는 생각보다 간단한 원칙 입니다. **"상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다."**를 지키면 됩니다. 예를 들어, `Computer`를 상속 받은 `Keyboard` 라는 친구가 있다고 가정 하겠습니다. `Computer` 라는 참조 변수 자리에 `Keyboard`라는 친구가 들어가면... 여러분도 이름에서 알 수 있다 싶이 의도와 다르게 작동 하여, 정상 작동을 할 것 같진 않을 것이다 라고 생각 할 것 입니다. 딱 봐도 **부모의 행동 규약**을 위반 할 것으로 예상되기 때문이에요.
58 |
59 |
60 | 
61 |
62 | Keyboard는... 딱 봐도 Computer의 역할을 수행 할 것 같지 않다.
63 |
64 |
65 |
66 | **부모 클래스가 ~~기 때문에 기대되는 역할, 행동 규약**이 있습니다. 그것을 벗어 나면 안됩니다. 그렇다면 행동 규약을 어기는 경우가 어디서 발생 할까요? 바로 **오버라이딩**을 할 때 입니다.
67 |
68 | 첫 번째 경우는 **부모 클래스의 메서드의 파라미터와 리턴 타입 등을 바꾸는 경우**입니다. 우리가 부모 클래스 변수에 자식 클래스 객체를 캐스팅 했을 때, 부모 클래스로써 호출 한 함수가 원래대로 작동 하지 않는 다면 에러가 발생 할 것입니다.
69 |
70 | 두 번째 경우는 **자식 클래스가 부모 클래스의 의도와 다르게 오버라이딩 하는 경우**입니다. 똑같은 타입의 파라미터와 리턴 값이라도, 우리가 의도 하지 않는 작업이 발생하여, 프로그램을 실행 하는 데에 장애가 생긴다면, 그것 또한 문제일 것입니다. `Computer`의 `doSomeThing()`을 호출 해서, 어떠한 컴퓨터의 프로그램이 실행 될 것이라고 생각 했는데 `Computer` 변수로 참조 받던 `Keyboard` 객체의 `doSomeThing()`이 호출 되어, 그냥 타이핑만 하고 끝난다면... 뭐 이런 식의 문제가 있을 것 입니다.
71 |
72 | ### ISP (Interface Segregation Principle), 인터페이스 분리 원칙
73 | **자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다**는 설계 원칙으로, 인터페이스를 하나로 묶는 것보단, 여러 개로 나누는 것이 더 좋다는 것을 의미 합니다.
74 | 비유하자면 이런 이야기 입니다. 사람은 이름을 가지고, 심박수, 산소농도, 배고픔 등을 가지고, 심장 박동을 합니다. 만약, 이러한 정보들을 한 곳에 몰아 붙이면 어떤 일이 일어 날까요?
75 |
76 | 음.. 만약 심장 이식 수술을 한다고 가정 한다면, 폐와, 위까지 같이 이식해야 하는 것과 다를 게 없을 것입니다. **사람**이라는 인터페이스에 다 몰아 붙였기 때문이죠, 그래서 우리는 **역할이 분리 될 수 있을 것이라고 생각되면, 인터페이스를 분리하는 것이 좋을 거에요!**
77 |
78 |
79 | 
80 |
81 | 심장 수술하면, 폐랑 위도 건들어야 하나요..?
82 |
83 |
84 |
85 | 이렇게 분리를 해야, 필요한 **역할**들에 대해서 변경 혹은 교체가 필요 할 때 원활하게 이를 수행 할 수 있습니다. 분리를 하지 않으면, 필요하지 않은 인터페이스들에 대해서도 모두를 가져와서 구현해야 하는 불상사가 발생할 수도 있어요.
86 |
87 | ### DIP (Dependency Inversion Principle), 의존 역전 원칙
88 | 의존 역전 원칙은 **고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 된다. 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 한다.** 혹은 **자신보다 변하기 쉬운 것에 의존하지 마라.** 를 의미합니다.
89 |
90 | 좀 쉽게 이야기 하면 이런 것 입니다. 우리가 `목장갑`이라는 클래스를 만들었다고 가정 하겠습니다. 그 다음, `사람`은 `목장갑` 클래스를 사용 할 수 있다고 가정 하겠습니다. 만약 `사람`이 이제 `목장갑`을 끼다가, 다른 `패션장갑`을 사용 하려고 한다면, 문제가 발생 할 것 입니다. `사람`은 `목장갑`을 낄 수 있다곤 했지만, `패션장갑`을 낄 수 있다고 하지 않았거든요.
91 |
92 | 이렇게 `사람`이 `장갑`이 아닌 `목장갑`에 의존을 하다 보니 발생한 문제였습니다. **너무 구체적인 저수준 클래스에 의존을 하도록 설계**를 하다 보니, 나중에 장갑을 교체 할 때 문제가 발생 한 것이죠. 그냥 `목장갑`이 아닌 `장갑` 인터페이스를 구현 하고, 해당 `장갑` 인터페이스를 구현한, `목장갑`, `패션장갑` 클래스가 있고 해당 객체를 가르키게 만들었다면, 조금 더 괜찮았을 것 같아요. 다음과 같이 말입니다.
93 |
94 |
95 | 
96 |
97 | 심장 수술하면, 폐랑 위도 건들어야 하나요..?
98 |
99 |
100 |
101 | 이렇게 하면, `목장갑`의 구현에 구애 받지 않고, `장갑` 이라는 인터페이스에 의존 하도록, 프로그램을 유연하게 짤 수 있는 것이죠. 이는 특히 **Spring** 프레임워크에서 자주 사용 하게 되는 원칙인데, 우리가 서버 개발을 하면서 **가격 정책, 서비스 정책, 사용 DB**는 언제든 바뀔 수 있습니다. 이를 객체 지향적으로 개발해야, 변경이 있을 때, 객체만 갈아 끼우면, 개발이 끝나게 끔 만들 수 있는 것이죠.
102 |
103 | ### 출처
104 | https://justkode.kr/java/solid-pattern
--------------------------------------------------------------------------------
/Language/JavaScript/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Language/JavaScript/.gitkeep
--------------------------------------------------------------------------------
/Language/Kotlin/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Language/Kotlin/.gitkeep
--------------------------------------------------------------------------------
/Language/Python/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Dcom-KHU/dcom-tech-interview/47c69606e2c3ad4b3f0eea93aa894f6d4d0fbde2/Language/Python/.gitkeep
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | ## D.Com Tech Interview
2 | 취업을 준비하는 **D.Com** 학우들을 위한, 기술 면접 대비 **질문 백과사전**.
3 |
4 | 사실 기본적인 내용은 **tech-interview-for-developer**를 참고 하는 것이 제일 좋습니다. [링크](https://github.com/gyoogle/tech-interview-for-developer)
5 |
6 | ### 그럼 해당 레포지토리는 왜 만든 거에요?
7 | 일단 기존에 있는 인터뷰 백과사전이 **지식**을 중점으로 정리 해 놨다면, 여기에 있는 내용들은 **실제로 회사 면접에서 던질 만 한 질문**들을 모아 놓고, 이에 대해서 **깊게 답변**하여 작성자의 **메타 인지**를 키우고, 열람 하는 사람들의 **지식을 넓히기** 위한 목적으로 만들었습니다.
8 |
9 | ### 기여를 하려면 어떻게 해야 할까요?
10 | 일단 `fork` 하여, 본인의 레포지토리에서 작업 하신 후에 **Pull Requests**를 날려 주세요.
11 |
12 | #### 문서 추가시
13 | 일단 해당하는 폴더에 `.md` 형식으로 제목과 일치하는 **마크다운 문서**를 **주제에 해당하는 폴더**에 추가 해 주신 후, 해당 게시글의 링크를 최상단 폴더의 `README.md`에 추가 해 주세요. 그 다음
14 |
15 | #### 문서 수정시
16 | 해당 **마크다운 문서**를 수정 후 커밋, 푸쉬 해 주세요.
17 |
18 | ### Commit convention rule: 상태) 날짜-[주제]-내용
19 |
20 | #### 상태 정리
21 | - `add`: 추가
22 | - `update`: 업데이트
23 | - `delete`: 삭제
24 |
25 | `ex) add: 2022-04-15 [글 제목] 추가`
26 |
27 | `ex) update: 2022-04-15 [글 제목] ~~ 수정`
28 |
29 | ### Trouble Shooting
30 | 잘못된 내용은 [이슈](https://github.com/Dcom-KHU/dcom-tech-interview/issues)나 [Pull Requests](https://github.com/Dcom-KHU/dcom-tech-interview/pulls)를 통해 전달 해 주세요!
31 |
32 | ## 👥 Contributors
33 | - 17 박민재 - [Github](https://github.com/JustKode) / [Homepage](https://justkode.kr/)
34 | - 19 송용우 - [Github](https://github.com/FacerAin) / [Homepage](https://facerain.club/)
35 | - 18 김범구 - [Github](https://github.com/BambooKim) / [Homepage](https://velog.io/@bambookim)
36 | - 21 임승현 - [Github](https://github.com/kevinlim17) / [Homepage](https://velog.io/@kevinlsh17)
37 |
38 | ## 💻 Computer Science
39 | - ### Computer Architecture
40 |
41 | - ### Operating System
42 |
43 | - ### Data Structure
44 |
45 | - ### Algorithm
46 |
47 | - ### Database
48 | - [ACID란 무엇인가?](https://github.com/Dcom-KHU/dcom-tech-interview/blob/master/Computer%20Science/Database/acid.md)
49 | - [Transaction에서 Commit과 Rollback은 무엇인가?](https://github.com/Dcom-KHU/dcom-tech-interview/blob/master/Computer%20Science/Database/commit-rollback.md)
50 | - [트렌젝션 고립레벨은 뭐고, 이걸 왜 나눠 놓은거죠?](https://github.com/Dcom-KHU/dcom-tech-interview/blob/master/Computer%20Science/Database/transaction-isolation.md)
51 | - [NoSQL은 왜 쓰는 건가요?](https://github.com/Dcom-KHU/dcom-tech-interview/blob/master/Computer%20Science/Database/transaction-isolation.md)
52 | - ### Network
53 | - [우리가 웹 사이트를 접속할 때 일어나는 일](https://github.com/Dcom-KHU/dcom-tech-interview/blob/master/Computer%20Science/Network/when-we-enter-the-website.md)
54 | - [HTTP 1.1 vs HTTP 2.0](https://github.com/Dcom-KHU/dcom-tech-interview/blob/master/Computer%20Science/Network/http-1-vs-2.md)
55 | - [HTTPS와 SSL/TLS](https://github.com/BambooKim/dcom-tech-interview/blob/master/Computer%20Science/Network/https-ssl-tls.md)
56 | - [Connectionless와 Stateless](https://github.com/BambooKim/dcom-tech-interview/blob/master/Computer%20Science/Network/connectionless-stateless.md)
57 | - [쿠키와 세션](https://github.com/BambooKim/dcom-tech-interview/blob/master/Computer%20Science/Network/cookie-session.md)
58 |
59 |
60 | ## 💡 AI
61 | - ### Basic
62 | - [Batch Size VS Epoch](https://github.com/Dcom-KHU/dcom-tech-interview/blob/master/AI/Basic/batch-epoch.md)
63 |
64 | - ### Computer Vision
65 |
66 | - ### Natural Language Programming
67 | - [임베딩이란?](https://github.com/Dcom-KHU/dcom-tech-interview/blob/master/AI/Natural%20Language%20Programming/embedding.md)
68 | - [한국어 NLP가 어려운 이유](https://github.com/Dcom-KHU/dcom-tech-interview/blob/master/AI/Natural%20Language%20Programming/korean-nlp.md)
69 |
70 | ## 💾 Backend
71 | - ### Spring
72 |
73 | - ### Go
74 |
75 | - ### Node.js
76 |
77 | - ### Django
78 |
79 |
80 | ## 📱 Frontend
81 | - ### React.js
82 |
83 | - ### Android
84 | - [Android에서 MVVM 패턴이 중요한 이유](https://github.com/Dcom-KHU/dcom-tech-interview/blob/master/Frontend/Android/mvvm-design-pattern.md)
85 | - ### iOS
86 |
87 | - ### Flutter
88 |
89 | ## ☁️ Cloud Computing
90 | - ### Basic
91 | - [Monolithic vs MSA](https://github.com/Dcom-KHU/dcom-tech-interview/blob/master/Cloud%20Computing/Basic/monolithic-vs-msa.md)
92 | - ### Docker
93 |
94 | - ### Kubernetes
95 |
96 | - ### AWS
97 |
98 | ## 💬 Language
99 | - ### Go
100 |
101 | - ### Java
102 | - [SOLID 법칙이란?](https://github.com/Dcom-KHU/dcom-tech-interview/blob/master/Language/Java/solid.md)
103 | - [JVM의 메모리 구조](https://github.com/BambooKim/dcom-tech-interview/blob/master/Language/Java/jvm.md)
104 | - ### Kotlin
105 |
106 | - ### JavaScript
107 |
108 | - ### Python
109 |
110 | ## References
111 | - https://github.com/gyoogle/tech-interview-for-developer
112 | - https://github.com/ksundong/backend-interview-question
113 |
--------------------------------------------------------------------------------