1월 4주차 회고 (견본)

1월 4주차 회고 (견본)

docs/unchaptered/2024-01-23_회고_[1장] 네트워크 시작하기 읽기.md

@@ -0,0 +1,28 @@
+몇주 전, 회사에서 @playhuck이 네트워크 책을 추천해달라고 하셨다.
+
+나도 작년 9월에 IT 단톡방에서 **IT 엔지니어를 위한 네트워크 입문**를 추천받아서 읽었던 기억이 있었다.
+
+<image src="2024-01-23_회고_0.png" style="width: 200px;">
+<br>
+
+**네트워크 제대로 공부해보자**란 마음으로 책을 펼쳤고 실제로는 3~4일 정도만 열심히 읽었던 것 같다.
+
+<image src="2024-01-23_회고_1.png" style="width: 800px;">
+<br>
+
+사실상 공부라기 보다는 필기에 가가웠는데, 아래 같은 이유 떄문이었다.
+
+1. 대부분의 내용을 정리하고 기록하는 필기 방식
+
+    a. 어차피 난 이걸 다시 볼 인간이 아니다.
+
+2. 영어로 하는 필기
+
+    b. 영어에 대한 부담감을 줄이는 시간이었지만, 시간 대비 큰 효용은 없었다.
+
+<image src="2024-01-23_회고_2.png" style="width: 300px;">
+<br>
+
+그래서 이번에는 편하게 읽고 DIL을 남기는 방식으로만 하기로 했다.
+
+완독할 수 있으면 좋겠다.

docs/unchaptered/2024-01-24_회고_[2장] 네트워크 시작하기 읽기.md

@@ -0,0 +1,18 @@
+오늘까지 **[2장] 네트워크 연결과 구성 요소**를 읽었다.
+
+| playhuck이 강추한 스탠리텀블러 찰칵
+
+<image alt="스탠리 텀블러 찰칵"
+    src="./2024-01-24_회고_0.jpg"
+    style="width:300px;"/>
+
+[1장] 같은 경우는 AWS SAA Study Guide를 공부하면서 여러 모로 알고 있는 지식을 되새기는 좋은 시간이었다.
+
+다만, [2장]은 물리적인 네트워크 장비들이 많아서 전공 교양을 듣는 느낌으로 읽었던 같다.
+
+부담감을 줄이니까 그냥 재밌고 편하게 읽을 수 있었다.
+
+
+조만간 필요에 따라 사내 VPN을 설정해야 할 것 같다.
+
+그 때, 관련 장비나 IEEE 표준 등에 대해서 살펴보면 깔끔할 것 같다.

docs/unchaptered/2024-01-25_회고_[3장] 네트워크 통신하기.md

@@ -0,0 +1,36 @@
+오늘까지 **[3장] 네트워크 통신하기**를 읽었다.
+
+| 어제 공용공간이 약간 소란스러워서, 이번에는 회의실에서 playhuck과 스터디 찰칵
+
+<image alt="회의실이 8층 M27? M25?"
+    src="./2024-01-25_회고_0.jpg"
+    style="width:200px;" />
+<image alt="서브네팅 좋아!"
+    src="./2024-01-25_회고_1.jpg"
+    style="width:200px;" />
+
+2년 전, 취업을 준비하면서 DNS 쿼리 질의 과정에 대해서 공부했던 기억이 있다.
+
+`https://naver.com`으로 쿼리 질의를 보내면 TLD 최상위 네임서버인 .com 부터 질의가 시작된다.
+
+이후, 할당된 네임서버 들을 통해서 Public IPv4 Address를 찾고 요청이 라우팅 될 것이다.
+
+<br>
+
+하지만 1년 전, 클라우드와 네트워크 공부를 하면서 2게층, **Data Link Layer에서 필요한 MAC Address는 어떻게 가지고 있는거지?**라는 궁금증이 생겼다.
+
+Pulbic IPv4 혹은 DNS Domain 쿼리 질의를 보내는 시점에는 MAC Address를 알 수 없을 테니 올바른 2계층에 전달될 수 없는 것이 아닌가?
+
+**애초에 2계층, 3계층 간의 관계성이 없어보이는데 착각인가?**라는 생각도 있었다.
+
+<br>
+
+이 궁금증은 **[3장] 네트워크 통신** 후반부에서 해결할 수 있었다.
+
+ARP(Address Resolution Protocol)라는 동작이 네트워크 게층에서 이루어지고 있고 ARP, GARP, RARP, 클러스터링-FHRP(VRRP, HSRP) 등의 기능이 작동하고 있구나... 라는 정도의 느낌이었다.
+
+<br>
+
+아쉬운 점은 TCP, UDP 트래픽을 **브로드캐스트 상태로 볼 수 있게 해주는** 와이어샤크로 이런 ARP 과정을 볼 수 있는 예제가 없다 정도였다.
+
+이번 책 스터디가 끝나면 [IT보안을 위한 와이어샤크 네트워크 패킷 분석 실전](https://www.inflearn.com/course/wireshark_boanproject#reviews)를 배운 다음, 다시 한 번 스스로 실습을 하면서 읽어보면 이해도가 높아지지 않을까 생각했다.

docs/unchaptered/2024-01-26_회고_[4장] 스위치 2계층 장비.md

@@ -0,0 +1,11 @@
+**[3장] 네트워크 통신하기**에서 남은 2페이지부터 **[4장] 스위치 L2장비**까지 읽었다.
+
+[2024-01-25_회고_[3장] 네트워크 통신하기](./2024-01-25_[3장]%20네트워크%20통신하기.md)에서 DNS 시스템과 MAC Address에 대해서 꺠달음을 얻은 것 처럼 써놨었다.
+
+그런데 **[4장] 4계층 L2장비**에서 L2 장비를 통해서 ASP 통신을 보내고 MAC Address를 매핑한다는 부분이 나왔었다.
+
+서로 관계없는 부분을 연관해서 생각했던 걸까?
+
+<br>
+
+잘 이해가 되지 않아서 별도로 알아봐야 할 것 같다.

docs/unchaptered/2024-01-29_회고_[5장] 라우터 L3 스위치 3계층 장비 copy.md

@@ -0,0 +1,74 @@
+**[5장] 라우터 L3 스위치 3계층 장비**에 대해서 배웠다.
+
+| playhuck님이랑 매일 점심에 조용한 회의실에서 읽고 있다. 하지만 오늘은 조금 이슈가 있어서 각자 집에가서 읽기로 하였다. 모르는 내용을 다 찾아보면 `절대로` 완독을 못할 거라고 생각해서 빠르게 1회독 하려는 전략이 나쁘지 않은 것 같다.
+
+<img alt="공부"
+    src="./2024-01-29_회고_0.jpg"
+    style="width: 330px;"/>
+<img alt="시작 시간"
+    src="./2024-01-29_회고_1.jpg"
+    style="width: 150px;"/>
+<img alt="종료 시간"
+    src="./2024-01-29_회고_2.jpg"
+    style="width: 150px;"/>
+
+4, 5장 모두 `스위치`라는 말이 나와서 처음에 조금 혼란스러웠다.
+
+이 부분은 `0계층 장비`에 집중해 곰곰히 생각해보니 이해가 편했다.
+
+2계층(Data Link Layer)에서 배운 점은 MAC Address와 관련된 네트워크 통신을 주체하는 장비인 `스위치`에 대해서 배웠다.
+
+그렇다면 3계층(Network Layer)는 IP Address와 관련된 네트워트 통신과 관련된 내용일 것입니다.
+
+| _최근에 서비스 전체를 Terraform으로 배포하면서 Route Table, Route, Route Table Association 등을 코드 레벨에서 정의한 경험이 있어서, 조금이나마 따라갈 수 있었습니다._
+
+<br>
+
+3계층에서 중요한 요소는 `라우터`이며, 다음과 같은 역할을 합니다.
+
+1. 경로 지정
+2. Broadcast Control, Multicast Control -> 이 내용은 [3장] 네트워크 통신하기 73~74p에 나왔습니다.
+3. 프로토콜 변환
+
+<br>
+
+그 중에서도 **104p 5.2.1. 라우팅 동작과 라우팅 테이블** 부분을 일곡 나니 기존에 Rout Table, Route, Route Table Association이 진짜 무식한 방식(비효율적인) 방식으로 작동하고 있을 것 같다는 느낌이 들었다.
+
+그냥 RTB 1개에 IGW 1개 딱, 다른 RTB 1개에 NAT 1개 딱 깔았기 떄문에 SPoF 상태가 된 것 같다.
+
+<br>
+
+그래도 유익한 부분은 기본적으로 Route는 Next Hob이라는 방식으로 연동이 되어 있다는 부분이었습니다.
+
+지금까지는 Public Subnet에 IGW와 나머지는 전부 암묵적으로 찾아가도록 설치해놓은 것 같습니다.
+
+아마 성능 상 개선을 하기 위해서라면 여러 개의 Router를 두고 직접적으로 Direct Connected 혹은 Static Routing 방식으로 변경하는 것이 좋아보였습니다.
+
+이 부분은 별도로 AWS 환경에서 실습하는 것이 좋아보입니다.
+
+<br>
+
+지금까지 말한 부분이 라우터의 `라우팅` 부분이었습니다.
+
+또 색다른 부분은 `스위칭`이라는 부분이었는데, 라우터가 경로를 지정하는 방법에 대해서 였습니다.
+
+다만 이 부분은 제대로 이해할 수 없었고 2회독이나 Network Traffic Trace 혹은 Wireshark로 패킷 뜯어보면서 보면 조금 더 이해가 잘 되지 않을까? 란 생각이었습니다.
+
+<br>
+
+남은 부분...
+
+1. 스위칭이 먼저 된다.
+2. 라우팅은 관리 거리(AD), 코스트(비용 계산은 또 수많은 알고리즘이...), 부하 분산(ECMP; 역시 수많은 알고리즘이...)
+
+<br>
+
+전체적으로 [4장] [5장]을 보면서 느낀 건데, 하위 계층으로 내려갈수록 생소한 것 같습니다.
+
+아마도 7계층에서 로드 밸런서를 위주로 실습 혹은 업무를 진행해서 그런 것 같습니다.
+
+| 하지만 2계층, 3계층 실습은 대체 어떻게...?
+
+| 그나마 4계층 NLB(Network Load Balancer)는 어떻게 해야 하는가...
+
+| 대부분의 지식들이 그물망처럼 연결될테니까,,, 이대로 킵 고잉 하다보면 괜찮을지도...

docs/unchaptered/2024-01-29_회고_[5장] 라우터 L3 스위치 3계층 장비.md

@@ -0,0 +1,68 @@
+**[5장] 라우터 L3 스위치 3계층 장비**에 대해서 배웠다.
+
+| playhuck님이랑 매일 점심에 조용한 회의실에서 읽고 있다. 하지만 오늘은 조금 이슈가 있어서 각자 집에가서 읽기로 하였다.
+
+![공부](20240129_220637.jpg)
+![시작 시간](<Screenshot_20240129_220835_One UI Home.jpg>)
+![종료 시간](<Screenshot_20240129_223845_One UI Home.jpg>)
+
+4, 5장 모두 `스위치`라는 말이 나와서 처음에 조금 혼란스러웠다.
+
+이 부분은 `0계층 장비`에 집중해 곰곰히 생각해보니 이해가 편했다.
+
+2계층(Data Link Layer)에서 배운 점은 MAC Address와 관련된 네트워크 통신을 주체하는 장비인 `스위치`에 대해서 배웠다.
+
+그렇다면 3계층(Network Layer)는 IP Address와 관련된 네트워트 통신과 관련된 내용일 것입니다.
+
+| _최근에 서비스 전체를 Terraform으로 배포하면서 Route Table, Route, Route Table Association 등을 코드 레벨에서 정의한 경험이 있어서, 조금이나마 따라갈 수 있었습니다._
+
+<br>
+
+3계층에서 중요한 요소는 `라우터`이며, 다음과 같은 역할을 합니다.
+
+1. 경로 지정
+2. Broadcast Control, Multicast Control -> 이 내용은 [3장] 네트워크 통신하기 73~74p에 나왔습니다.
+3. 프로토콜 변환
+
+<br>
+
+그 중에서도 **104p 5.2.1. 라우팅 동작과 라우팅 테이블** 부분을 일곡 나니 기존에 Rout Table, Route, Route Table Association이 진짜 무식한 방식(비효율적인) 방식으로 작동하고 있을 것 같다는 느낌이 들었다.
+
+그냥 RTB 1개에 IGW 1개 딱, 다른 RTB 1개에 NAT 1개 딱 깔았기 떄문에 SPoF 상태가 된 것 같다.
+
+<br>
+
+그래도 유익한 부분은 기본적으로 Route는 Next Hob이라는 방식으로 연동이 되어 있다는 부분이었습니다.
+
+지금까지는 Public Subnet에 IGW와 나머지는 전부 암묵적으로 찾아가도록 설치해놓은 것 같습니다.
+
+아마 성능 상 개선을 하기 위해서라면 여러 개의 Router를 두고 직접적으로 Direct Connected 혹은 Static Routing 방식으로 변경하는 것이 좋아보였습니다.
+
+이 부분은 별도로 AWS 환경에서 실습하는 것이 좋아보입니다.
+
+<br>
+
+지금까지 말한 부분이 라우터의 `라우팅` 부분이었습니다.
+
+또 색다른 부분은 `스위칭`이라는 부분이었는데, 라우터가 경로를 지정하는 방법에 대해서 였습니다.
+
+다만 이 부분은 제대로 이해할 수 없었고 2회독이나 Network Traffic Trace 혹은 Wireshark로 패킷 뜯어보면서 보면 조금 더 이해가 잘 되지 않을까? 란 생각이었습니다.
+
+<br>
+
+남은 부분...
+
+1. 스위칭이 먼저 된다.
+2. 라우팅은 관리 거리(AD), 코스트(비용 계산은 또 수많은 알고리즘이...), 부하 분산(ECMP; 역시 수많은 알고리즘이...)
+
+<br>
+
+전체적으로 [4장] [5장]을 보면서 느낀 건데, 하위 계층으로 내려갈수록 생소한 것 같습니다.
+
+아마도 7계층에서 로드 밸런서를 위주로 실습 혹은 업무를 진행해서 그런 것 같습니다.
+
+| 하지만 2계층, 3계층 실습은 대체 어떻게...?
+
+| 그나마 4계층 NLB(Network Load Balancer)는 어떻게 해야 하는가...
+
+| 대부분의 지식들이 그물망처럼 연결될테니까,,, 이대로 킵 고잉 하다보면 괜찮을지도...

scripts/auto-pr.py

@@ -79,7 +79,7 @@ def getPullRequestTemplate(
     print(out)
 
     pullRequestBody = f"""
-[제목] [가제] 변경 필요
+[제목] N월 N주차 회고
 [기여자] {','.join(commiterList)}
 [내용]
 
@@ -111,7 +111,7 @@ def getPullRequestTemplate(
     labelList = list(set(labelList))
 
     githubPrTemplate: GitHubPrTemplate = {
-        'title': '[가제] 변경 필요',
+        'title': 'N월 N주차 회고',
         'body': pullRequestBody,
         'labelList': labelList,
         'assigneeList': commiterList