Initial Kui Vault

03.Note/DRY (Don't Repeat Yourself).md

@@ -0,0 +1,25 @@
+---
+id: "DRY (Don't Repeat Yourself) 20260330"
+created: "2026-03-30 15:05"
+tags:
+aliases:
+---
+## 💡 생각  
+코드의 반복을 줄여서 유지보수를 용이하게 하자.
+단, 코드의 반복을 무조건적으로 줄이는 것은 좋지 않은 결과를 낳을 수 있다.
+[[DRY (Don't Repeat Yourself)]] << [[KISS (Keep It Simple, Stupid)]]
+DRY한 코드보다 KISS한 코드를 만드는 게 더 중요하다.
+
+---
+## 📑 개념
+**똑같은 일을 반복하지 마라**라는 뜻입니다.
+동일한 코드의 중복을 피하라는 의미.
+
+## 📌 상세
+1. 코드의 정보나 로직은 시스템 내에서 **단 한 곳**에만 존재해야 합니다.
+2. 똑같은 로직이 여기저기 복사되어 있으면, 나중에 수정할 때 모든 곳을 다 찾아내서 고쳐야 합니다. 하나라도 놓치면 바로 버그로 이어집니다.
+3. 중복되는 코드가 보이면 함수나 클래스로 추출하여 공통화하세요.
+4. 3번 이상 반복되는 코드에 적용하는 것이 좋음.
+   ( 2번 이하로 반복되는 코드를 DRY하게 하다 보면 오히려 코드의 복잡성이 증가해서 [[KISS (Keep It Simple, Stupid)]] 원칙을 깨는 경우가 발생될 수 있음.)
+
+---

03.Note/EC2 기반 vs Fargate 기반 비교.md

@@ -0,0 +1,7 @@
+
+| **비교 항목**         | **EC2 기반 컨테이너 (ECS/EKS)**  | **Fargate 기반 컨테이너 (ECS/EKS)** |
+| ----------------- | -------------------------- | ----------------------------- |
+| **인프라 관리**        | 사용자가 EC2 인스턴스 관리 (OS 패치 등) | **AWS가 인프라 완전 관리**            |
+| **확장성 (Scaling)** | EC2 인벤토리와 컨테이너 개수 동시 고려    | **컨테이너(Task/Pod) 개수만 조절**     |
+| **격리 수준**         | 인스턴스 내 커널 공유 가능성 있음        | **Task/Pod 단위의 강력한 커널 격리**    |
+| **과금 방식**         | 인스턴스 크기 및 가동 시간 기준         | **할당된 CPU 및 메모리 리소스 사용량 기준**  |

03.Note/EC2(Elastic Compute Cloud).md

@@ -0,0 +1,27 @@
+- 작성 **날짜:** 2026-02-27
+
+## 📑 개념
+> [!abstract] 
+> 클라우드에서 제공하는 **가상 서버**, EC2는 AWS 클라우드에서 확장 가능한 컴퓨팅 용량을 제공합니다. 하드웨어를 직접 구매할 필요 없이 가상 서버를 구축하고, 보안 및 네트워킹을 구성하며 저장소를 관리할 수 있습니다.
+- **Elastic (탄력적인):** 수요에 따라 서버 대수를 자유롭게 늘리거나 줄일 수 있습니다.
+- **Compute (컴퓨팅):** CPU, 메모리 등 계산 능력을 제공합니다.
+- **Cloud (클라우드):** 인터넷을 통해 어디서든 접근 가능한 가상 환경입니다.
+## 📌 상세
+> [!check] 
+> |**요소**|**명칭**|**설명**|
+> |---|---|---|
+> |**운영체제**|**AMI** (Amazon Machine Image)|Windows, Linux 등 서버에 설치될 OS와 기본 설정이 담긴 이미지입니다.|
+> |**하드웨어 사양**|**인스턴스 유형**|CPU, RAM, 네트워크 성능에 따른 규격입니다. (예: t3.medium, c5.large)|
+> |**저장 장치**|**EBS** (Elastic Block Store)|서버의 하드디스크 역할을 하는 가상 디스크입니다.|
+> |**보안/네트워크**|**보안 그룹** (Security Group)|가상 방화벽으로, 어떤 포트(80, 443, 22 등)를 열어줄지 설정합니다.|
+> |**접속 인증**|**키 페어** (Key Pair)|서버 접속 시 사용하는 비밀번호 대신의 암호화 키 파일입니다.|
+
+## 📝 노트
+> [!note]
+> 
+> - AWS(혹은 클라우드 서비스 제공자)로부터 가상의 서버를 임대해서 사용하는 것
+> - 원하는 사양으로 요청하면 대여해서 사용할 수 있음
+>
+
+## 🔗 지식 연결
+- **태그:** #zettelkasten #knowledge

03.Note/EC2기반 아키텍처의 한계점.md

@@ -0,0 +1,8 @@
+| **구분**                  | **주요 한계점 및 단점**                 | **세부 설명**                                                                  |
+| ----------------------- | ------------------------------- | -------------------------------------------------------------------------- |
+| **운영 관리 부담 (Overhead)** | **OS 및 소프트웨어 관리**               | OS 패치, 보안 업데이트, 런타임 설치 및 관리를 사용자가 직접 수행해야 함 (Shared Responsibility Model). |
+| **확장성 (Scalability)**   | **느린 오토스케일링 속도**                | 새로운 인스턴스를 띄우고 OS 부팅, 애플리케이션 실행까지 수 분의 시간이 소요되어 급격한 트래픽 변화에 대응이 늦음.         |
+| **자원 효율성**              | **낮은 집적도 및 낭비**                 | 특정 프로세스가 CPU/RAM을 적게 쓰더라도 인스턴스 전체 비용이 발생함. 컨테이너 대비 자원 격리 및 배분 효율이 낮음.      |
+| **배포 및 일관성**            | **"It works on my machine" 문제** | 개발 환경과 운영 서버 OS 설정이 다를 경우 장애 발생 가능성이 높음 (컨테이너 대비 환경 일관성 부족).               |
+| **고가용성 (HA)**           | **복잡한 복구 프로세스**                 | 인스턴스 장애 시 단순히 프로세스를 재시작하는 것보다 교체 및 복구 과정이 더 무겁고 복잡함.                       |
+| **비용 (Cost)**           | **유휴 자원 비용 발생**                 | 트래픽이 없는 시간대에도 최소 유지 인스턴스 비용이 계속 발생하며, 세밀한 과금 단위 설정이 어려움.                   |

03.Note/ECR(Elastic Container Registry).md

@@ -0,0 +1,52 @@
+---
+id: "ECR 20260305"
+created: "2026-03-05 09:49"
+tags:
+---
+## 💡 생각  
+도커 이미지 허브 (유료)
+
+
+---
+## 📑 개념
+> [!abstract] 
+> AWS에서 제공하는 **완전관리형 컨테이너 이미지 레지스트리 서비스**
+
+## 📌 상세
+> [!check] 
+> 1. 개발자들이 만든 도커(Docker) 이미지를 안전하게 보관하고 필요할 때 꺼내 쓸 수 있는 **'클라우드 보관함'**이라고 생각하시면 됩니다.
+> 2. 가장 유명한 'Docker Hub'의 AWS 버전이라고 이해하면 쉽습니다.
+
+### 1. 주요 특징 및 기능
+
+- **완전관리형 서비스:** 서버를 직접 관리하거나 스토리지 용량을 걱정할 필요가 없습니다. AWS가 인프라 운영과 확장을 알아서 처리합니다.
+    
+- **보안 및 통합:** AWS [[IAM(Identity and Access Management)]]과 통합되어, 특정 사용자나 EC2 인스턴스만 이미지에 접근할 수 있도록 세밀하게 권한을 제어할 수 있습니다.
+    
+- **이미지 스캔:** 업로드한 이미지에 보안 취약점이 있는지 자동으로 스캔하여 알려주는 기능을 제공합니다.
+    
+- **수명 주기 정책(Lifecycle Policy):** 오래된 이미지나 태그가 없는 이미지를 자동으로 삭제하도록 설정하여 저장 비용을 절감할 수 있습니다.
+    
+- **고가용성:** 이미지가 S3에 저장되므로 데이터 내구성이 매우 높으며, 여러 가용 영역(AZ)에 걸쳐 안정적으로 배포됩니다.
+    
+
+### 2. 작동 방식 (워크플로우)
+
+1. **빌드(Build):** 로컬 PC나 CI/CD 환경에서 Docker 이미지를 생성합니다.
+    
+2. **인증(Authenticate):** AWS CLI를 통해 ECR에 로그인합니다.
+    
+3. **푸시(Push):** 생성된 이미지를 ECR 리포지토리(Repository)에 업로드합니다.
+    
+4. **풀(Pull):** Amazon ECS, EKS, 또는 Lambda 같은 서비스에서 실행 시점에 해당 이미지를 내려받아 컨테이너를 구동합니다.
+
+---
+
+
+#### ECR의 장점
+
+|**구분**|**설명**|
+|---|---|
+|**속도**|AWS 내부 네트워크를 사용하므로 ECS나 EKS로 이미지를 배포할 때 속도가 매우 빠릅니다.|
+|**비용**|사용한 스토리지 용량과 데이터 전송량에 대해서만 비용을 지불하며, AWS 내부 서비스 간의 데이터 전송은 무료인 경우가 많습니다.|
+|**신뢰성**|퍼블릭 레지스트리(Docker Hub 등)의 장애나 속도 저하로부터 독립된 안정적인 환경을 구축할 수 있습니다.|

03.Note/ECS와 EKS의 차이점.md

@@ -0,0 +1,9 @@
+| **구분**      | **Amazon ECS (Elastic Container Service)** | **Amazon EKS (Elastic Kubernetes Service)** |
+| ----------- | ------------------------------------------ | ------------------------------------------- |
+| **개념**      | AWS 전용 컨테이너 관리 서비스                         | AWS에서 제공하는 **관리형 쿠버네티스**                    |
+| **복잡도**     | **낮음** (설정과 관리가 매우 간결함)                    | **높음** (쿠버네티스 숙련도 필수)                       |
+| **유연성/제어권** | AWS 환경에 최적화, 제어권은 제한적                      | 매우 높음 (오픈 소스 기반의 무한한 커스텀)                   |
+| **이식성**     | AWS 전용 기술로 타 클라우드 이동이 어려움                  | **매우 높음** (어디서든 동일한 K8s 환경 구동)              |
+| **관리 단위**   | **Task** (태스크)                             | **Pod** (포드)                                |
+| **학습 곡선**   | 완만함 (비교적 빨리 배울 수 있음)                       | 매우 가파름 (개념과 리소스 종류가 방대함)                    |
+| **적합한 상황**  | AWS 서비스 위주의 빠르고 간결한 운영                     | 복잡한 마이크로서비스, 표준 기술 스택 지향                    |

03.Note/IAM(Identity and Access Management).md

@@ -0,0 +1,60 @@
+---
+id: "IAM(Identity and Access Management) 20260316"
+created: "2026-03-16 13:35"
+tags:
+---
+## 💡 생각  
+사용자(User)가 가지는 권한이 무엇인지를 나열하고 필요한 사용자 혹은 그룹에 필요한 권한들을 원하는대로 부여할 수 있도록 구성해놓은 웹 서비스
+
+AWS의 고유개념이 아니고 정보 보안 분야에서는 오랫동안 존재해온 표준적인 개념이자 기술 프레임워크.
+
+---
+## 📑 개념
+ "누가(인증)", "어떤 리소스에(권한)" 접근할 수 있는지를  중앙에서 관리를 해서 리소스에 대한 접근을 안전하게 제어할 수 있게 해주는 웹 서비스입니다.
+
+## 📌 IAM의 핵심 구성 요소
+- **사용자 (User):** 실제 사람이나 서비스(애플리케이션)를 나타냅니다. 고유한 보안 자격 증명(ID/PW 또는 Access Key)을 가집니다.
+    
+- **그룹 (Group):** 사용자들의 집합입니다. 그룹에 권한을 부여하면 그 그룹에 속한 모든 사용자가 동일한 권한을 상속받습니다. (예: `Developers` 그룹, `Admins` 그룹)
+    
+- **역할 (Role):** 특정 사용자에게 귀속되지 않고, **필요할 때만 잠시 빌려 쓰는 권한**입니다. 주로 EC2 서버나 Lambda 함수 같은 AWS 서비스가 다른 서비스에 접근할 때 사용합니다.
+    
+- **정책 (Policy):** "무엇을 할 수 있는지"를 정의한 **JSON 문서**입니다. 사용자, 그룹, 역할에 이 정책을 연결(Attach)하여 권한을 부여합니다.
+
+
+### 주요 기능과 특징
+
+| **기능**                    | **설명**                                                             |
+| ------------------------- | ------------------------------------------------------------------ |
+| **세분화된 권한 제어**            | 특정 S3 버킷의 파일만 읽게 하거나, 특정 시간대에만 접속을 허용하는 등 매우 정밀한 설정이 가능합니다.        |
+| **다요소 인증 (MFA)**          | 아이디/비번 외에 OTP(Google Authenticator 등)를 추가하여 보안을 한층 강화할 수 있습니다.     |
+| **자격 증명 연동 (Federation)** | 기업의 기존 계정(Active Directory 등)이나 구글/페이스북 계정으로 AWS에 로그인할 수 있게 지원합니다. |
+| **비용 무료**                 | IAM 서비스 자체 사용에 따른 추가 비용은 없습니다.                                     |
+
+## 📝 노트
+> [!note]
+> 
+> ## IAM 설계의 황금률: "최소 권한의 원칙"
+> 
+> 보안 사고를 막기 위해 IAM을 운영할 때 가장 중요한 원칙은 **최소 권한의 원칙 (Least Privilege)**입니다.
+> 
+> - 사용자에게 업무에 **꼭 필요한 권한만** 부여합니다.
+>     
+> - 루트(Root) 계정은 가급적 사용하지 않고, 일상 업무용 IAM 사용자를 따로 만들어 사용합니다.
+>
+
+---
+
+
+![[Pasted image 20260316134417.png]]
+사용자가 하나 있고 역할은 21개가 있고 정책은 1개가 생성되어있음.
+
+
+![[Pasted image 20260316134502.png]]
+![[Pasted image 20260316134525.png]]
+사용자는 dihwang 하나가 있는데 AdministratorAccess 라는 이름의 정책을 가지고있다.
+
+
+![[Pasted image 20260316134705.png]]
+이 AdministratorAccess 정책에는 총 464개의 권한이 있다.
+즉, dihwang 사용자는 464개의 기능을 사용할 권한이 있다는 뜻이 된다.

03.Note/KISS (Keep It Simple, Stupid).md

@@ -0,0 +1,36 @@
+---
+id: KISS (Keep It Simple, Stupid) 20260330
+created: 2026-03-30 14:53
+tags:
+aliases:
+---
+## 💡 생각  
+[[단순한 코드]]를 만들어야 한다. 가독성을 항상 최우선시 하자.
+단순한 형태로 쉽게쉽게 읽히는 코드를 만드는 게 중요하다.
+코드의 유연성 확보는 그 다음 문제다.
+
+---
+## 📑 개념
+ **단순하게 유지해, 이 바보야**라는 뜻입니다. (여기서 바보는 나 자신이나 동료를 뜻하는 애칭 섞인 농담입니다.)
+ 해결책은 항상 **가장 단순한 형태**여야 합니다.
+
+## 📌 상세
+코드가 똑똑해 보이고 화려할수록, 나중에 버그가 생겼을 때 고치기가 수십 배 더 힘들어집니다. 진짜 실력자는 어려운 문제를 어렵게 푸는 사람이 아니라, **어려운 문제를 누구나 이해할 수 있게 단순하게 푸는 사람**입니다.
+
+복잡한 디자인 패턴이나 최신 기술을 억지로 끼워 넣지 마세요. `if-else`로 충분하다면 그렇게 짜는 것이 가장 좋습니다.
+
+> [!question]
+> Q. kiss의 경우 나도 많이 궁금했고 어려웠던건데 디자인 패턴이나 MVC패턴같은 개발 패턴들을 굳이 쓰지말고 일단은 단순하게 if-else 로 만들어란 뜻으로 해석해야 하는거야?
+> A. 네, 정확하게 짚으셨습니다! **KISS** 원칙의 핵심은 **정답을 미리 정해놓고 끼워 맞추는 것이 아니라, 문제에 대한 가장 직관적인 해결책부터 시작하라**는 것입니다.
+
+단순 if-else 로 구성된 코드가 무조건 잘못된 게 아님.
+미래에 내가 다시 보거나 내가 아닌 다른사람이 내 코드를 읽었을 때 코드의 의도가 잘 이해되면 잘 만든 코드임.
+디자인 패턴은 패턴의 이해가 필요하고 곧장 읽히지는 않기 때문에 디자인 패턴을 적용한 코드가 항상 가독성이 좋은 코드일수는 없음.
+일단은  if-else 등의 단순한 형태로 작동되는 코드를 만드는 것이 중요함.
+## 📝 노트
+> [!note]
+> 
+> - 코드의 중복이 발생되고 코드의 유연성이 떨어진다고 판단될 때 디자인 패턴을 적용하면 됨
+>
+
+---

03.Note/MVP(Minimum Viable Product).md

@@ -0,0 +1,16 @@
+---
+id: "MVP(Minimum Viable Product) 20260320"
+created: "2026-03-20 14:00"
+tags:
+aliases:
+---
+## 💡 생각  
+당장 꼭 필요한 기능만 포함된 최소한의 제품을 최대한 빠르게 만들어내는 게 핵심 가치
+미완성본을 말하는 것이 아닌 최소한의 기능은 정상적으로 동작해야함.
+
+---
+## 📑 개념
+직역하면 **생존 가능한 최소한의 제품**을 의미합니다. 
+단순히 '대충 만든 제품'이나 '미완성본'이 아니라, **고객에게 가치를 제공할 수 있는 핵심 기능만 담은 가장 작은 단위의 결과물**입니다.
+
+---

03.Note/Pod를 Private subnet에 두는 이유.md

@@ -0,0 +1,34 @@
+### 1. 공격 표면(Attack Surface)의 최소화
+
+파드가 퍼블릭 서브넷에 있고 공인 IP(Public IP)를 직접 가지고 있다면, 전 세계 누구나 해당 파드에 직접 접속을 시도할 수 있습니다.
+
+- **위험성:** 애플리케이션 코드의 작은 취약점이나 설정 오류만으로도 서버 전체가 해킹당할 수 있습니다.
+    
+- **해결:** 프라이빗 서브넷에 두면 외부에서는 아예 길 자체가 없어서 직접 접근이 불가능해집니다.
+    
+
+### 2. 단일 진입점 강제 (로드 밸런서 활용)
+
+사용자는 파드에 직접 붙는 것이 아니라, **로드 밸런서(ALB/NLB)**라는 검증된 관문을 통해서만 들어와야 합니다.
+
+- 로드 밸런서는 퍼블릭 서브넷에서 외부 요청을 안전하게 걸러서 받고, 내부 네트워크를 통해 프라이빗 서브넷에 있는 파드에게 전달합니다.
+    
+- 이 구조를 통해 트래픽 제어, SSL 인증서 관리, WAF(웹 방화벽) 적용이 훨씬 쉬워집니다.
+    
+
+### 3. IP 주소 자원 관리
+
+퍼블릭 IP는 전 세계적으로 한정된 자원이며 비용이 발생합니다.
+
+- 쿠버네티스 특성상 파드는 수십, 수백 개가 생성되었다가 사라집니다. 이때마다 퍼블릭 IP를 할당하는 것은 매우 비효율적이고 비용 낭비가 심합니다.
+    
+- 내부망(Private IP)을 사용하면 주소 부족 걱정 없이 자유롭게 스케일링할 수 있습니다.
+    
+
+### 4. 아키텍처의 논리적 분리 (Tiering)
+
+현대적인 3-Tier 아키텍처 원칙을 따르기 위함입니다.
+
+- **Public Tier:** 로드 밸런서, 배스천 호스트 (외부 소통 창구)
+    
+- **Private Tier:** 애플리케이션 서버, 데이터베이스 (실제 핵심 데이터와 로직)

03.Note/VPC(Virtual Private Cloud).md

@@ -0,0 +1,27 @@
+- 작성 **날짜:** 2026-02-27
+
+## 📑 개념
+> [!abstract] 
+> "AWS 클라우드 안에서 완벽하게 격리된, 사용자가 직접 정의하는 **가상 네트워크 환경**"
+> AWS가 만든 개념인데 현재는 클라우드 표준처럼 사용됨
+
+## 📌 VPC의 핵심 구성 요소
+> [!check] 
+|**구성 요소**|**명칭**|**설명**|**비유**|
+|---|---|---|---|
+|**CIDR 블록**|**IP 주소 범위**|VPC에서 사용할 IP 주소의 범위를 정의 (예: `10.0.0.0/16`)|내 구역의 **전체 주소지**|
+|**서브넷 (Subnet)**|**망 분할**|VPC를 더 작은 단위로 쪼갠 네트워크. 퍼블릭과 프라이빗으로 나뉨|큰 건물을 **여러 개의 방**으로 나눔|
+|**라우팅 테이블**|**길잡이**|네트워크 트래픽이 어디로 가야 할지 알려주는 이정표|건물 내의 **복도와 안내판**|
+|**인터넷 게이트웨이**|**IGW**|VPC와 인터넷 사이의 통로. 이게 있어야 외부 통신 가능|건물의 **정문 (바깥 세상으로 나가는 문)**|
+|**NAT 게이트웨이**|**NAT**|프라이빗 서브넷의 서버가 보안을 유지하며 외부로만 나갈 때 사용|안에서는 밖을 보지만, **밖에서는 안을 못 보는 창문**|
+
+## 📝 노트
+> [!note]
+> 
+> - 관련 사례나 반대되는 개념이 있다면 여기에 기록하세요.
+>     
+> - 본인의 언어로 풀어서 쓰는 것이 제텔카스텔의 핵심입니다.
+>
+
+## 🔗 지식 연결
+- **태그:** #zettelkasten #knowledge

03.Note/VPN(Virtual Private Network).md

@@ -0,0 +1,33 @@
+---
+id: "VPN(Virtual Private Network) 20260305"
+created: "2026-03-05 15:00"
+tags:
+---
+## 💡 생각  
+또다른 네트워크 연결 통로라고 생각하면 됨. 실제로 VPN 연결 시 네트워크 연결에 새로운 네트워크 연결이 추가됨.
+![[Pasted image 20260305150408.png]]
+
+---
+## 📑 개념
+가상 사설망, **인터넷상에 나만의 안전한 비밀 통로를 만드는 기술**이라고 생각하면 됨.
+
+## 📌 상세
+
+VPN 사용 시 주요 장점
+
+| **장점**         | **설명**                                             |
+| -------------- | -------------------------------------------------- |
+| **보안 강화**      | 공공장소(카페, 공항)의 무료 와이파이를 쓸 때 해킹 위험으로부터 데이터를 보호합니다.   |
+| **IP 주소 우회**   | 나의 실제 위치(IP 주소)를 숨기고 VPN 서버가 있는 국가의 IP로 바꿀 수 있습니다. |
+| **검열 및 차단 해제** | 특정 국가에서 접속이 막힌 사이트나 콘텐츠(해외 넷플릭스 등)에 접근할 수 있습니다.    |
+| **익명성 보장**     | 방문하는 웹사이트나 서비스 제공자가 나의 실제 신원을 파악하기 어렵게 만듭니다.       |
+
+
+VPN 사용 시 주의할 점
+- **속도 저하:** 데이터를 암호화하고 먼 거리에 있는 서버를 거치기 때문에 인터넷 속도가 평소보다 느려질 수 있습니다.
+    
+- **무료 VPN의 위험성:** "공짜" VPN 중 일부는 사용자의 활동 로그를 수집해 광고주에게 팔거나 보안이 취약할 수 있습니다. 가급적 신뢰할 수 있는 유료 서비스를 권장합니다.
+    
+- **완벽한 익명성은 없음:** VPN 업체는 내가 어떤 데이터를 주고받는지 알 수 있습니다. 따라서 '노 로그(No-log, 활동 기록을 남기지 않음)' 정책을 가진 업체를 선택하는 것이 중요합니다.
+
+---

03.Note/Woodpecker.md

@@ -0,0 +1,45 @@
+---
+id: "Woodpecker 20260320"
+created: "2026-03-20 16:56"
+tags:
+aliases:
+---
+## 💡 생각  
+이거 아주 괜찮을거같음
+아주 경량화되어 사용하기 쉽고 빠릿빠릿한 젠킨스
+(물론 계속 써봐야겠지만..)
+
+---
+## 📑 개념
+Woodpecker CI는 오픈 소스 기반의 경량 CI/CD 엔진으로, 과거 유명했던 Drone CI에서 포크(Fork)되어 발전한 도구입니다. 복잡한 설정보다는 **간결함**과 **컨테이너 기반의 확장성**을 중시하는 팀에게 특히 매력적인 선택지입니다.
+
+## 📌 상세
+## 1. Woodpecker의 핵심 철학
+
+Woodpecker는 모든 파이프라인 단계를 **도커(Docker) 컨테이너** 내에서 실행합니다. 이로 인해 환경 격리가 확실하며, 필요한 도구를 설치하기 위해 에이전트를 더럽힐 필요가 없습니다.
+
+- **설정의 간소화:** `.woodpecker.yml`이라는 YAML 파일 하나로 전체 파이프라인을 정의합니다.
+    
+- **오픈 소스 정신:** 완전히 무료이며, 커뮤니티에 의해 유지보수됩니다. (Drone CI가 기업화되면서 라이선스 제약이 생긴 것에 반발하여 나온 프로젝트입니다.)
+    
+- **경량화:** 리소스 소모가 매우 적어 개인 서버나 사양이 낮은 VPS에서도 원활하게 돌아갑니다.
+    
+
+---
+
+## 2. 작동 방식 (Architecture)
+
+Woodpecker는 크게 두 가지 컴포넌트로 구성됩니다.
+
+- **Server:** 웹 UI를 제공하고, GitHub, GitLab, Gitea와 같은 소스 코드 관리 도구(Forge)와 연동하여 웹훅(Webhook)을 처리합니다.
+    
+- **Agent:** 실제로 파이프라인 작업을 수행하는 주체입니다. 서버로부터 할당받은 작업을 컨테이너를 띄워 실행합니다.
+
+
+## 주요 장점
+
+- **멀티 플랫폼 지원:** x86_64는 물론이고 ARM64(라즈베리 파이 등)에서도 완벽하게 작동합니다.
+    
+- **다양한 Backend:** 기본적으로 Docker를 사용하지만, 최근에는 로컬 프로세스 실행이나 [[쿠버네티스(Kubernetes)]] 기반의 실행도 지원하기 시작했습니다.
+    
+- **플러그인 생태계:** Docker 이미지를 플러그인처럼 사용할 수 있습니다. 예를 들어, 빌드가 끝나고 Slack 메시지를 보내고 싶다면 이미 만들어진 Slack 플러그인 이미지를 파이프라인에 추가하기만 하면 됩니다.

03.Note/YAGNI(You Ain't Gonna Need It).md

@@ -0,0 +1,41 @@
+---
+id: "YAGNI(You Ain't Gonna Need It) 20260317"
+created: "2026-03-17 16:54"
+tags:
+aliases:
+---
+## 💡 생각  
+지금 당장 꼭 필요한 것만 만들어라. 미리 먼저 만들지 마라
+
+---
+## 📑 개념
+소프트웨어 개발 원칙 중 하나로 직역하면 **그거 필요 없을걸요** 또는 **미리 만들지 마세요**라는 뜻을 담고 있습니다.
+개발자가 미래에 필요할 것으로 예상되는 기능을 미리 구현하지 말고, **실제로 그 기능이 필요한 시점이 되었을 때 구현하라**는 핵심 메시지를 전달합니다.
+## 📌 상세
+### 1. YAGNI가 필요한 이유
+
+많은 개발자가 나중에 이 기능이 추가될 때를 대비해 미리 구조를 잡거나 범용적인 코드를 작성하려는 유혹에 빠지곤 합니다. 하지만 이런 **추측에 기반한 개발(Speculative Development)**은 다음과 같은 부작용을 낳습니다.
+
+- **시간 낭비:** 결국 쓰이지 않게 될 기능을 만드느라 현재 꼭 필요한 작업에 집중하지 못하게 됩니다.
+    
+- **코드 복잡성 증가:** 당장 필요 없는 코드가 들어가면 전체적인 시스템 구조가 복잡해지고, 나중에 코드를 읽거나 수정하기 더 어려워집니다.
+    
+- **유지보수 비용 발생:** 사용되지 않는 기능이라도 버그가 생기면 수정해야 하고, 의존성 업데이트나 리팩토링 시 고려 대상이 되어 짐이 됩니다.
+    
+- **잘못된 예측:** 미래의 요구사항은 변하기 마련입니다. 미리 만들어둔 기능이 나중에 정작 필요한 형태와 달라서 결국 다시 만들어야 하는 경우가 많습니다.
+    
+
+### 2. YAGNI를 실천하는 방법
+
+- **현재의 요구사항에 집중:** 오늘 해결해야 할 문제와 기능에만 충실하게 코드를 작성합니다.
+    
+- **확장성보다는 단순성:** 나중에 확장될 것을 대비해 복잡한 추상화 계층을 미리 만들기보다는, 지금 당장 이해하기 쉽고 단순한 구조를 유지합니다.
+    
+- **리팩토링의 힘:** 나중에 정말로 기능 확장이 필요해졌을 때, 그때 가서 코드를 리팩토링하여 기능을 추가하는 것이 훨씬 효율적입니다.
+
+## 📝 노트
+> [!note]
+> 
+> - 작업의 가치는 그것이 실제로 사용될 때 발생합니다.
+
+---

03.Note/index.md

@@ -0,0 +1,3 @@
+---
+title: note
+---

03.Note/가상 머신(VM) vs 컨테이너.md

@@ -0,0 +1,6 @@
+| **비교 항목** | **가상 머신 (EC2 등 VM)**                   | **컨테이너 (Docker 등)**               |
+| --------- | -------------------------------------- | --------------------------------- |
+| **구조**    | OS 위에 가상 하이퍼바이저와 **별도의 Guest OS**가 필요함 | 호스트의 **OS 커널을 공유**하며 프로세스 단위로 격리됨 |
+| **무게**    | GB 단위 (매우 무겁고 부팅이 느림)                  | **MB 단위** (매우 가볍고 즉시 실행됨)         |
+| **효율성**   | 리소스 낭비가 큼 (OS마다 자원을 잡아먹음)              | 필요한 자원만 사용하므로 집적도가 높음             |
+| **이식성**   | 환경 설정에 따라 작동 여부가 달라짐                   | **"어디서든 동일하게 실행"**됨을 보장함          |

03.Note/가용성(Availability).md

@@ -0,0 +1,20 @@
+- 작성 **날짜:** 2026-02-27
+
+## 📑 개념
+> [!abstract] 
+> 시스템이 장애 없이 정상적으로 서비스를 제공할 수 있는 상태
+> 언제든지 이상없이 잘 사용할 수 있는것도 가용성으로 봄
+
+## 📝 상세 설명
+> [!note]
+> 
+> - 
+>
+
+
+$$가용성(\%) = \frac{업타임(정상 운영 시간)}{업타임 + 다운타임(장애 시간)} \times 100$$
+
+
+## 🔗 지식 연결
+- **태그:** #zettelkasten #knowledge
+

03.Note/단순한 코드.md

@@ -0,0 +1,42 @@
+---
+id: 단순한 코드 20260318
+created: 2026-03-18 09:55
+tags:
+aliases:
+---
+## 💡 생각  
+결국 단순한 코드는 
+가독성이 좋아야 하고: [[코드의 가독성]] 
+유연성이 좋아야 한다. [[유연한 단순함]] [[유연성(Flexibility)]]
+
+단순한 코드를 만들기 위해서는 이 두가지를 고민해야 하는데 이 자체가 고도의 작업이다.
+
+---
+
+> [!question]
+> Q. 단순한 코드라는게 가독성도 생각해야하고 스케일업도 고민해야해서 코드를 단순하게 만드는대에도 공수가 든다. 이렇게 이해하면 되는거야?
+> A. 네, 정확합니다! **단순함은 거저 얻어지는 것이 아니라, 치열한 고민과 비용(공수)이 들어가는 결과물**이라고 이해하시는 게 가장 올바른 접근입니다.
+> 
+> 많은 초보 개발자들이 "그냥 생각나는 대로 빨리 짜는 것"을 단순하다고 착각하지만, 숙련된 개발자에게 단순함은 **불필요한 것을 깎아내는 고도의 설계 작업**을 의미합니다.
+
+## 📌 상세
+### 단순함은 '방치'가 아니라 '정제'입니다
+
+코드를 단순하게 만들기 위해 공수가 드는 이유는 다음과 같은 **판단 과정**이 필요하기 때문입니다.
+
+- **가독성 고민:** "나중에 내가 이 코드를 다시 봤을 때, 10초 안에 로직을 파악할 수 있는가?"를 고민하며 변수명을 고치고 함수를 쪼개는 작업이 추가됩니다.
+    
+- **스케일업(유연성) 고민:** "지금은 간단히 짜지만, 나중에 로직이 추가될 때 코드 전체를 다 뜯어고쳐야 하나?"를 생각하며 최소한의 확장성(인터페이스 분리 등)을 확보하는 데 시간이 듭니다.
+
+## 그래서 [[파레토의 법칙]]을 여기서 적용해야합니다.
+모든 코드를 이렇게 정성 들여 단순하게 만들려면 시간이 너무 많이 걸립니다. 그래서 **20%에 집중**해야 합니다.
+- **핵심 20% (비즈니스 로직, 복잡한 쿼리):** 가독성과 유연성을 위해 **충분한 공수**를 들여서 단순화합니다. 여기가 복잡하면 나중에 감당이 안 되기 때문입니다.
+    
+- **나머지 80% (일회성 툴, 단순 UI 연결 등):** 여기에는 너무 많은 공수를 들이지 않습니다. 적당히 돌아가게만 짜는 것이 오히려 전체적인 효율(단순함)을 높이는 길입니다.
+- [[80대20 원칙(The Pareto Principle)]]
+
+## 📝 노트
+> [!note] 스티브 잡스의 유명한 말
+> "단순함은 복잡함보다 어렵다. 생각을 명확히 해서 단순하게 만들려면 정말 열심히 노력해야 한다."
+
+---

03.Note/멀티 테넌시(Multi-tenancy).md

@@ -0,0 +1,30 @@
+---
+id: 멀티 테넌시(Multi-tenancy) 20260305
+created: 2026-03-05 13:02
+tags:
+---
+## 💡 생각  
+하나의 인스턴스가 여러 테넌시에 서비스를 제공해준다. 보통의 클라우드형 서비스는 멀티 테넌시라고 보면 됨.
+
+---
+## 📑 개념
+하나의 소프트웨어 인스턴스가 **여러 명의 사용자(테넌트)**에게 서비스를 제공하는 구조**
+아파트 한 동에 여러 가구가 살면서 엘리베이터나 복도를 공유하는 것과 비슷합니다.
+## 📌 상세
+- **특징:** 데이터베이스나 애플리케이션 실행 환경을 공유하지만, 각 사용자의 데이터는 논리적으로 격리되어 서로 볼 수 없습니다.
+    
+- **장점:** * **비용 효율성:** 자원을 공유하므로 사용료가 저렴합니다.
+    
+    - **업데이트 용이:** 서비스 제공자가 한 번만 업데이트하면 모든 사용자가 최신 기능을 쓸 수 있습니다.
+        
+- **단점:** * **보안 우려:** 논리적으로는 격리되어 있지만, 물리적으로 같은 자원을 쓰기 때문에 보안 민감도가 높은 기업은 꺼릴 수 있습니다.
+    
+    - **성능 간섭:** 특정 테넌트가 자원을 과하게 쓰면 다른 테넌트의 속도가 느려질 수 있습니다 (Noisy Neighbor 현상).
+        
+- **예시:** 구글 드라이브, 네이버 MYBOX, **대부분의 SaaS**(Slack, Notion 등).
+
+---
+
+## 🔗 관련 노트
+- [[테넌시(Tenancy)]]
+- [[싱글 테넌시(Single-tenancy)]]

03.Note/배포 파이프라인(Deployment Pipeline).md

@@ -0,0 +1,27 @@
+- 작성 **날짜:** 2026-02-27
+
+## 📑 개념
+> [!abstract] 
+> 코드가 작성된 순간부터 실제 사용자에게 서비스되기까지의 모든 과정(빌드, 테스트, 배포)을 자동화한 일련의 단계
+흔히 **CI/CD 파이프라인**이라고도 부릅니다.
+## 📌 파이프라인의 주요 단계
+> [!check] 
+> |**단계**|**명칭**|**주요 작업**|
+> |---|---|---|
+> |**1. Source**|**코드 관리**|개발자가 코드를 수정하고 저장소(Git)에 푸시(Push)하는 단계.|
+> |**2. Build**|**컴파일/패키징**|코드를 실행 가능한 파일로 만들거나 컨테이너 이미지(Docker)로 빌드하는 단계.|
+> |**3. Test**|**검증**|단위 테스트, 통합 테스트 등을 통해 코드의 결함이나 성능을 체크하는 단계.|
+> |**4. Deploy**|**출시**|검증된 결과물을 실제 서버(EC2, Fargate 등)에 배포하여 서비스를 업데이트하는 단계.|
+
+"소스 코드의 변경 사항을 사용자에게 전달하는 과정을 **표준화하고 자동화한 워크플로우**"
+## 📝 노트
+> [!note]
+> 
+> - 주요 단계들을 표준화하고 자동화한 워크플로우를 배포 파이프라인이라고 함.
+> - Jenkins가 CI/CD 엔진, 즉 배포 파이프라인 엔진임
+> - git으로 코드를 푸시하면 푸시된 코드를 기준으로 Build, Test, Deploy 까지 자동으로 진행해주는걸 의미함
+> - CI/CD엔진으로 AWS의 CodePipeline 이 있고 Github의 Actions 가 있음
+>
+
+## 🔗 지식 연결
+- **태그:** #zettelkasten #knowledge

03.Note/보안 그룹(Security Group).md

@@ -0,0 +1,50 @@
+---
+id: 보안 그룹(Security Group) 20260305
+created: 2026-03-05 10:54
+tags:
+---
+## 💡 생각  
+방화벽이 허용(비허용)하는 범위를 그룹핑했다는 의미로 보안그룹이라고 이름붙인 것 같음.
+방화벽을 유연하고 쉽게 적용할 수 있도록 해놓은 형태
+하나 이상의 보안그룹을 동시에 설정 가능함. (합집합 형태로 적용됨)
+
+> [!example]
+> 보안그룹1: A,B 허용
+> 보안그룹2: B,C,D 허용
+> 보안그룹 1,2 모두 지정하면 A,B,C,D 모두 허용됨
+
+---
+## 📑 개념
+**"인스턴스(가상 서버)를 감싸고 있는 가상 방화벽"**입니다.**
+
+## 📌 상세
+### 1. 허용(Allow) 규칙만 설정 가능
+
+보안 그룹에는 "이 IP는 차단해!"라는 거부(Deny) 규칙을 만들 수 없습니다. 기본적으로 모든 통로를 막아두고, **"이 포트와 이 IP만 들어오게 해줘"**라는 허용 규칙만 추가하는 방식(화이트리스트)입니다.
+
+### 2. 상태 저장(Stateful) 방식
+
+가장 똑똑한 기능 중 하나입니다.
+
+- **인바운드(Inbound):** 밖에서 안으로 들어오는 요청이 허용되었다면,
+    
+- **아웃바운드(Outbound):** 안에서 나가는 응답은 별도의 설정 없이도 **자동으로 허용**됩니다. (반대도 마찬가지입니다.)
+    
+
+### 3. 인스턴스 단위의 보안
+
+네트워크 전체(서브넷)를 막는 ACL(Network ACL)과 달리, 보안 그룹은 **개별 인스턴스 단위**로 적용됩니다. 예를 들어, 웹 서버용 보안 그룹과 DB 서버용 보안 그룹을 따로 만들어 각각 채워줄 수 있습니다.
+
+### 4. 언제든지 변경 가능
+
+규칙을 수정하면 해당 보안 그룹을 사용하는 모든 인스턴스에 **즉시 적용**됩니다. 서버를 껐다 켤 필요가 없습니다.
+
+## 📝 노트
+> [!note]
+> 
+> - 관련 사례나 반대되는 개념이 있다면 여기에 기록하세요.
+>     
+> - 본인의 언어로 풀어서 쓰는 것이 제텔카스텔의 핵심입니다.
+>
+
+---

03.Note/보안성(Security).md

@@ -0,0 +1,23 @@
+- 작성 **날짜:** 2026-02-27
+
+## 📑 개념
+> [!abstract] 
+> 시스템, 데이터, 그리고 네트워크를 **비인가된 접근, 수정, 파괴**로부터 보호하는 능력
+
+## 📌 상세
+
+| **요소**                    | **설명**                              | **핵심 가치**     |
+| ------------------------- | ----------------------------------- | ------------- |
+| **기밀성 (Confidentiality)** | 허가된 사용자만이 정보에 접근할 수 있어야 함.          | 암호화, 접근 제어    |
+| **무결성 (Integrity)**       | 데이터가 전송되거나 저장될 때 임의로 수정되지 않아야 함.    | 디지털 서명, 해시 함수 |
+| **가용성 (Availability)**    | 인가된 사용자가 필요할 때 언제든 자원을 사용할 수 있어야 함. | DDoS 방어, 이중화  |
+
+
+## 📝 상세 설명
+> [!note]
+> 
+> - 말그대로 외부의 공격으로부터 보호가 잘 되어지는지를 말함
+>
+
+## 🔗 지식 연결
+- **태그:** #zettelkasten #knowledge

03.Note/생산성(Productivity).md

@@ -0,0 +1,34 @@
+- 작성 **날짜:** 2026-02-27
+
+## 📑 개념
+> [!abstract] 
+> 투입된 자원(시간, 인력, 비용) 대비 얻어낸 산출물(결과물, 가치)의 비율
+> 
+> IT 아키텍처 관점에서의 생산성은 단순히 코드를 빨리 짜는 것을 넘어, 얼마나 효율적으로 서비스를 운영하고 비즈니스 가치를 빠르게 시장에 전달할 수 있느냐(**Time-to-Market**)에 초점이 맞춰져 있습니다.
+
+### 1. 생산성의 정의
+
+경제학적 관점과 소프트웨어 공학적 관점에서의 생산성은 다음과 같이 정의됩니다.
+
+$$생산성 = \frac{Output (산출물)}{Input (투입 자원)}$$
+
+- **IT에서의 Input:** 개발 시간, 운영 인력, 인프라 비용, 기술 부채.
+    
+- **IT에서의 Output:** 배포된 기능의 수, 서비스 안정성, 고객 만족도, 매출 가치.
+
+### 2. 생산성을 결정짓는 3대 요소
+
+|**요소**|**세부 내용**|
+|---|---|
+|**도구 및 기술 (Tools)**|자동화 도구(CI/CD), 클라우드 서비스(Fargate 등), 효율적인 프레임워크 사용.|
+|**프로세스 (Process)**|애자일(Agile) 방법론, 코드 리뷰 체계, 명확한 문서화(PARA/제텔카스텐 등).|
+|**인적 자원 (People)**|개발자의 숙련도, 팀 간의 원활한 커뮤니케이션, 집중할 수 있는 환경.|
+
+## 📝노트
+> [!note]
+> 
+> - 즉 생산성이 좋다는건 투입되는 리소스 대비 산출물이 많은 경우를 의미함
+> - 생산성 측정에 가치도 포함되어있기 때문에 단순히 양이 많다고 생산성이 좋은건 아니다
+
+## 🔗 지식 연결
+- **태그:** #zettelkasten #knowledge

03.Note/서버리스(Serverless).md

@@ -0,0 +1,17 @@
+- 작성 **날짜:** 2026-02-27
+
+## 📑 개념
+> [!abstract] 
+> **서버리스(Serverless)**는 이름 그대로 "서버가 없다"는 뜻이 아니라, **"사용자가 서버를 관리할 필요가 없는 컴퓨팅 모델"**을 의미합니다. 인프라의 복잡한 추상화를 통해 개발자는 오직 **코드(비즈니스 로직)**에만 집중할 수 있는 환경을 말합니다.
+
+## 📌 상세
+> [!check] 
+|**특징**|**세부 설명**|
+|---|---|
+|**관리 서버 없음**|OS 설치, 패치, 하드웨어 관리에 신경 쓸 필요가 없음.|
+|**유연한 확장성**|트래픽에 따라 자원이 자동으로 늘어나거나 줄어듦 (Auto-scaling).|
+|**사용량 기반 과금**|서버를 켜둔 시간이 아니라, 실제 코드가 실행된 시간/횟수만큼만 비용 지불.|
+|**고가용성 내장**|클라우드 제공사가 여러 가용 영역에 걸쳐 리소스를 분산하여 안정성 보장.|
+
+## 🔗 지식 연결
+- **태그:** #zettelkasten #knowledge

03.Note/서브넷(Subnet).md

@@ -0,0 +1,33 @@
+- 작성 **날짜:** 2026-02-27
+
+## 📑 개념
+> [!abstract] 
+> 거대한 네트워크인 [[VPC(Virtual Private Cloud)]]를 더 효율적이고 안전하게 관리하기 위해 **더 작은 단위로 쪼갠 가상 네트워크**
+
+ **참고로 VPC도 서브넷도 모두 논리적인 개념, 물리적인 동작은 가용 영역에서 이루어짐**
+
+## 📌 서브넷을 나누는 이유
+> [!check] 
+> - **보안 (Security):** 인터넷에 연결될 공간과 외부로부터 완전히 격리될 공간을 분리하기 위해서입니다.
+>     
+> - **성능 (Performance):** 네트워크 트래픽이 한꺼번에 몰리는 것을 방지하고 관리 효율성을 높입니다.
+>     
+> - **조직화:** 용도별(웹 서버용, DB용, 관리용 등)로 자원을 그룹화하여 관리하기 위함입니다.
+
+## 📝 노트
+> [!note]
+> 
+> - VPC가 아파트 단지라면 서브넷은 아파트단지의 동이라고 생각하면 됨.
+> - AWS의 클라우드를 VPC 단위로 쪼개서 사용하고 그 VPC는 서브넷 단위로 쪼개서 사용함
+> - 서브넷 단위로 분할하지 않으면 VPC로 접근하는 요청들은 VPC내에있는 모든 서비스들에게 전달해주어야함. 이를 막기위해 존재하는 개념(한번에 모든 동을 다 찾아가지 않게끔)
+
+### 서브넷의 종류
+
+| **구분**    | **퍼블릭 서브넷 (Public)**          | **프라이빗 서브넷 (Private)**       |
+| --------- | ----------------------------- | ---------------------------- |
+| **특징**    | 외부 인터넷과 양방향 통신 가능             | 외부 인터넷에서 직접 접근 불가            |
+| **연결 방식** | **인터넷 게이트웨이(IGW)**와 연결됨       | 인터넷 게이트웨이와 연결되지 않음           |
+| **배치 자원** | 로드 밸런서(ALB), 배스천 호스트(Bastion) | **백엔드 서버(.NET)**, 데이터베이스(DB) |
+| **비유**    | 아파트 정문 안내소 (누구나 방문 가능)        | 아파트 내부의 안방 (가족만 접근 가능)       |
+## 🔗 지식 연결
+- **태그:** #zettelkasten #knowledge

03.Note/신호 대 소음비(Signal-to-Noise Ratio).md

@@ -0,0 +1,28 @@
+---
+id: 신호 대 소음비(Signal-to-Noise Ratio) 20260317
+created: 2026-03-17 17:24
+tags:
+aliases:
+---
+## 💡 생각  
+신호 대 소음비가 높다는건 아무리 생각해도 신호 대비 소음의 비율이 높다는걸로 보이는데..
+그냥 신호 대 소음비 라는거를 고유명사처럼 생각하는게 편할듯
+신호 대 소음비가 높다 -> 의미있는 정보의 비중이 높다
+
+---
+## 📑 개념
+**무엇이 신호고 무엇이 소음인가?**
+**신호 대 소음비를 높인다**는 말은 **불필요한 소음(노이즈)을 최대한 제거해서 순수한 정보(신호)만 남긴다** 는 뜻
+
+## 📌 상세
+신호중에 소음의 비율이 얼마인가? 라고 생각했는데...
+> [!question]
+> Q. 신호 대 소음비가 높단건 신호 : 소음 중 소음의 비율이 크다는거아냐?
+> A. 아, 그렇게 생각하실 수도 있겠네요! 수학적인 분수 구조를 떠올려보시면 바로 이해가 되실 거예요.
+> **신호 대 소음비($SNR$)**는 말 그대로 **신호($Signal$)를 소음($Noise$)으로 나눈 값**입니다.
+$$SNR = \frac{\text{Signal}}{\text{Noise}}$$
+
+- **신호 대 소음비가 높다:** 노래 소리(신호)는 쩌렁쩌렁한데 지지직거리는 잡음(소음)은 거의 안 들리는 상태입니다. 아주 깨끗하게 들리겠죠?
+- **신호 대 소음비가 낮다:** 노래 소리는 작은데 잡음이 너무 커서 노래가 묻히는 상태입니다. 짜증이 나고 듣기 힘듭니다.
+
+---

03.Note/싱글 테넌시(Single-tenancy).md

@@ -0,0 +1,41 @@
+---
+id: "싱글 테넌시(Single-tenancy) 20260305"
+created: "2026-03-05 13:06"
+tags:
+---
+## 💡 생각  
+이곳에 하나의 생각 또는 아이디어를 작성합니다.
+
+
+---
+## 📑 개념
+하나의 소프트웨어 인스턴스가 **단 한 명의 사용자**만을 위해 독립적으로 운영되는 구조
+단독 주택에 한 가족만 사는 것과 같습니다.
+
+## 📌 상세
+- **특징:** 사용자마다 전용 인프라와 데이터베이스가 할당됩니다.
+    
+- **장점:**
+    
+    - **높은 보안성:** 물리적/논리적으로 완전히 격리되어 있어 보안이 강력합니다.
+        
+    - **커스터마이징:** 해당 사용자만을 위한 맞춤 설정이 자유롭습니다.
+        
+- **단점:** * **비용 부담:** 인프라 구축 및 유지보수 비용이 높습니다.
+    
+    - **관리 복잡도:** 각 사용자별로 업데이트나 관리를 따로 해야 합니다.
+        
+- **예시:** 온프레미스 서버 구축, 특정 기업용 전용 클라우드 서비스.
+
+## 📝 노트
+> [!note]
+> 
+> - 관련 사례나 반대되는 개념이 있다면 여기에 기록하세요.
+>     
+> - 본인의 언어로 풀어서 쓰는 것이 제텔카스텔의 핵심입니다.
+>
+
+---
+
+## 🔗 관련 노트
+[[테넌시(Tenancy)]], [[멀티 테넌시(Multi-tenancy)]]

03.Note/용량 공급자 전략 (Capacity Provider Strategy).md

@@ -0,0 +1,62 @@
+---
+id: "용량 공급자 전략 (Capacity Provider Strategy) 20260305"
+created: "2026-03-05 10:32"
+tags:
+---
+## 💡 생각  
+이곳에 하나의 생각 또는 아이디어를 작성합니다.
+
+
+---
+## 📑 개념
+> [!abstract] 
+> 하나 이상의 인프라(용량 공급자)를 **어떤 비율로 섞어서 쓸지** 결정하는 고도화된 방식입니다.
+> "평소엔 **[[파게이트(Fargate)]]**를 쓰되, 비용 절감을 위해 일부는 **[[파게이트 스팟(Fargate Spot)]]**을 섞어서 써줘" 같은 전략을 짤 수 있습니다.
+
+## 📌 상세
+- **방식:** "평소엔 **[[파게이트(Fargate)]]**를 쓰되, 비용 절감을 위해 일부는 **[[파게이트 스팟(Fargate Spot)]]**을 섞어서 써줘" 같은 전략을 짤 수 있습니다.
+    
+- **핵심 요소:**
+    
+    - **Base (기본값):** 최소한 이만큼은 특정 공급자에서 실행해라 (예: 최소 2개는 안정적인 Fargate에서 실행).
+        
+    - **Weight (가중치):** 추가로 늘어나는 태스크는 어떤 비율로 나눌 것인가 (예: Fargate 1 : Fargate Spot 3 비율로 확장).
+        
+- **비유:** "기본 식사 2인분은 코스 요리로 주고, 그 이후 추가되는 음식은 뷔페식 3 : 단품 1 비율로 섞어와주세요"라고 정교하게 주문하는 것과 같습니다.
+
+### 기본 (Base)
+
+- **의미:** "무슨 일이 있어도 **최소 이만큼의 개수**는 이 공급자에서 실행해라."
+    
+- **작동 방식:** 서비스가 시작될 때 가장 먼저 채워지는 숫자입니다.
+    
+- **예시:** 만약 `기본`을 2로 설정하면, 전체 태스크가 10개든 100개든 상관없이 처음 2개는 무조건 지정된 공급자(Fargate)에서 실행됩니다.
+
+### 가중치 (Weight)
+
+- **의미:** "기본(Base) 개수를 채우고 남은 태스크들을 **어떤 비율**로 나눌 것인가?"
+    
+- **작동 방식:** 여러 공급자를 추가했을 때 상대적인 비율로 계산됩니다.
+    
+- **예시:** `FARGATE(가중치 1)`와 `FARGATE_SPOT(가중치 3)`으로 설정하면, 기본 개수를 채운 후 추가되는 4개의 태스크 중 1개는 Fargate, 3개는 Spot에 배치됩니다.
+
+### 💡 왜 '용량 공급자 전략'을 써야 할까요? (핵심 이유)
+가장 큰 장점은 **비용 절감과 자동 스케일링**입니다. 특히 **[[EC2(Elastic Compute Cloud)]]**를 사용하신다면, 시작 유형 방식은 서버(EC2)가 모자랄 때 태스크 실행이 실패하지만, 용량 공급자를 쓰면 ECS가 직접 **Auto Scaling Group(ASG)**에 명령을 내려서 서버를 새로 받아온 뒤 그 위에 [[태스크(Task)]]를 띄워줍니다.
+
+**[[파게이트(Fargate)]]**를 쓰실 때도 [[파게이트 스팟(Fargate Spot)]]을 적절히 섞으면 성능은 유지하면서 비용을 최대 70%까지 아낄 수 있기 때문에, ==요즘은 대부분 이 전략 방식을 사용합니다.==
+
+---
+
+
+### 추천 시나리오
+**시나리오: "안정성도 챙기고 돈도 아끼고 싶을 때"**
+
+|**용량 공급자**|**기본 (Base)**|**가중치 (Weight)**|**설명**|
+|---|---|---|---|
+|**FARGATE**|**2**|**1**|**최소 2개**는 절대 꺼지지 않는 일반 Fargate로 유지 (안정성)|
+|**FARGATE_SPOT**|**0**|**3**|그 이후 늘어나는 태스크는 **75% 비율**로 저렴한 Spot 사용 (비용 절감)|
+### 왜 이렇게 하나요?
+
+1. **안정성:** `FARGATE_SPOT`은 AWS에서 자원이 부족하면 예고 없이 꺼질 수 있습니다. 하지만 `Base`를 일반 `FARGATE`로 잡아두면, 서버가 아예 먹통이 되는 사태를 방지할 수 있습니다.
+    
+2. **비용:** 트래픽이 몰려 태스크가 10개, 20개로 늘어날 때, 늘어난 분량의 대부분(75%)을 훨씬 저렴한 Spot으로 돌려 비용을 대폭 아낄 수 있습니다.

03.Note/유연성(Flexibility).md

@@ -0,0 +1,22 @@
+- 작성 **날짜:** 2026-02-27
+
+## 📑 개념
+> [!abstract] 
+> "변화에 얼마나 쉽고 빠르게 대응할 수 있는가?"
+
+## 📌 상세
+> [!check] 
+> - **환경의 유연성:** 온프레미스에서 클라우드로, 또는 윈도우에서 리눅스로 실행 환경을 옮길 때의 용이성.
+>     
+> - **구조의 유연성:** 마이크로서비스 아키텍처(MSA)처럼 특정 기능을 수정할 때 전체 시스템에 영향을 주지 않고 독립적으로 변경할 수 있는 능력.
+>     
+> - **기술의 유연성:** 특정 벤더(Vendor Lock-in)에 종속되지 않고 필요에 따라 다양한 오픈 소스나 도구를 조합할 수 있는 상태.
+
+## 📝 노트
+> [!note]
+> 
+> - 어떠한 상황에 얼마나 유연하게 잘 대응할 수 있는지, 단어 뜻 그대로 이해하면 될듯
+>
+
+## 🔗 지식 연결
+- **태그:** #zettelkasten #knowledge

03.Note/유연한 단순함.md

@@ -0,0 +1,50 @@
+---
+id: "유연한 단순함 20260318"
+created: "2026-03-18 09:22"
+tags:
+aliases:
+---
+## 💡 생각  
+복잡하게 생각하지 말고 단순하게 개발하되 유연한 코드를 만들어야한다.
+
+---
+
+### 1. '미리 구현하는 것'과 '길을 열어두는 것'의 차이
+
+업스케일링을 염두에 둔다는 것이 처음부터 복잡한 분산 처리 시스템이나 거대한 프레임워크를 도입하라는 뜻이 아닙니다.
+
+- **나쁜 설계 (과잉 엔지니어링):** "나중에 사용자가 100만 명이 될지 모르니, 지금 당장 Redis 캐시를 붙이고 마이크로서비스로 쪼개자!" → **단순함 위반 (YAGNI)**
+    
+- **좋은 설계 (확장성 고려):** "지금은 로컬 DB를 쓰지만, 나중에 DB가 바뀌거나 서버가 늘어날 수 있으니 **로직과 데이터 접근 코드를 분리**해두자." → **유연한 단순함**
+    
+
+즉, **나중에 고치기 힘들게 코드를 꼬아놓지 않는 것** 자체가 업스케일링을 준비하는 가장 단순한 방법입니다.
+
+### 2. 파레토 법칙의 재해석
+
+데이터가 늘어날 때 문제가 생기는 지점은 대개 전체 코드의 20%도 안 됩니다.
+
+- **단순화:** 80%의 일반적인 로직은 최대한 읽기 쉽고 단순하게 짭니다.
+    
+- **업스케일링 대비:** 나머지 20%의 핵심 로직(예: 데이터 조회, 대량 처리)에서 **확장 가능한 패턴(Interface 사용, 비동기 처리 등)**을 적용하는 것입니다.
+    
+
+이것은 모든 곳에 힘을 주는 것이 아니라, **성능의 급소가 될 만한 곳에만 최소한의 설계적 장치**를 해두는 전략입니다.
+
+### 3. '버티는 코드'의 진짜 의미: 가독성
+
+역설적이게도 데이터가 늘어나서 문제가 생겼을 때, 그 문제를 가장 빨리 해결할 수 있는 코드는 **단순한 코드**입니다.
+
+- 코드가 단순하면 어디가 병목인지 금방 찾을 수 있습니다.
+    
+- 코드가 단순하면 최적화된 알고리즘으로 교체하기가 매우 쉽습니다.
+    
+- 반면, 미리 업스케일링을 한답시고 복잡하게 짜놓은 코드는 정작 문제가 터졌을 때 수정하기가 훨씬 어렵습니다.
+
+## 📝 노트
+> [!note]
+> 
+> - **"추측에 근거해서 미리 복잡한 기능을 만들지 말되(단순함), 나중에 그 기능을 개선해야 할 때 코드 전체를 갈아엎지 않아도 되게끔 '벽'을 잘 세워두라(확장성)"**
+>
+
+---

03.Note/최적화(Optimization).md

@@ -0,0 +1,46 @@
+---
+id: "최적화(Optimization) 20260317"
+created: "2026-03-17 16:59"
+tags:
+aliases:
+---
+## 💡 생각  
+이곳에 하나의 생각 또는 아이디어를 작성합니다.
+
+---
+## 📌 상세
+### 1. 설계의 최적화 = 구조의 단순화
+
+흔히 최적화라고 하면 '기교를 부려 속도를 높이는 것'을 생각하기 쉽지만, 가장 높은 수준의 최적화는 **불필요한 단계를 제거**하는 것입니다.
+
+- **복잡한 로직:** A를 거쳐 B를 확인하고 C를 실행한다.
+    
+- **최적화된 로직:** 바로 C를 실행해도 문제가 없음을 발견하고 중간 과정을 삭제한다.
+    
+- **결과:** 성능은 빨라지고(최적화), 코드는 짧아집니다(단순화).
+    
+
+### 2. 인지적 최적화 (Cognitive Optimization)
+
+코드는 컴퓨터만 읽는 게 아니라 사람도 읽습니다. 읽기 복잡한 코드는 디버깅과 유지보수 시간을 엄청나게 잡아먹죠.
+
+- **단순한 코드**는 개발자가 코드를 이해하는 데 드는 **뇌의 연산 비용(Cognitive Load)**을 최소화해 줍니다.
+    
+- 결과적으로 전체 개발 프로세스의 성능을 높이는 '사람을 위한 최적화'가 되는 셈입니다.
+    
+
+### 3. 알고리즘적 최적화
+
+예를 들어, 데이터를 찾을 때 전체를 다 뒤지는 `O(n)` 방식보다, 정렬된 데이터에서 이진 탐색을 하는 `O(log n)` 방식이 훨씬 빠릅니다.
+
+- 때로는 효율적인 알고리즘(최적화)을 선택하는 것이, 지저분한 예외 처리를 잔뜩 넣어둔 이전 코드보다 훨씬 **간결하고 명확(단순화)**할 수 있습니다.
+
+## 📝 노트
+> [!note]
+> 
+> - 관련 사례나 반대되는 개념이 있다면 여기에 기록하세요.
+>     
+> - 본인의 언어로 풀어서 쓰는 것이 제텔카스텔의 핵심입니다.
+>
+
+---

03.Note/컨테이너 오케스트레이션.md

@@ -0,0 +1,51 @@
+- 작성 **날짜:** 2026-02-27
+
+## 📑 개념
+> [!abstract] 
+> 수많은 [[컨테이너(Container)]]의 배포, 관리, 확장, 네트워킹을 자동화하는 **'통합 관리 시스템'**입니다.
+> 컨테이너를 기반으로 주요 기능들을 자동화해서 실제로 구동시켜주는 시스템
+
+## 📌 상세
+> [!check] 
+> |**핵심 기능**|**세부 설명**|**기대 효과**|
+> |---|---|---|
+> |**자동 배치 (Scheduling)**|컨테이너를 실행하기 가장 적절한 서버를 찾아 자동으로 할당|자원 효율성 극대화|
+> |**자가 치유 (Self-healing)**|죽은 컨테이너를 감지하고 자동으로 재시작 또는 교체|**고가용성(HA) 확보**|
+> |**오토 스케일링 (Scaling)**|트래픽 부하에 따라 컨테이너 개수를 유연하게 조절|성능 유지 및 비용 최적화|
+> |**로드 밸런싱 (LB)**|여러 컨테이너에 트래픽을 고르게 분산|서비스 안정성 향상|
+> |**무중단 배포 (Rolling Update)**|서비스 중단 없이 순차적으로 새 버전 업데이트|운영 연속성 보장|
+
+### 아키텍처 구조 (Conceptual View)
+
+컨테이너 오케스트레이션은 크게 **지휘부(Control Plane)**와 **실행부(Data Plane)**로 나뉩니다.
+
+> [!abstract] **지휘부 (Control Plane / Master)**
+> 
+> - 시스템의 상태를 결정하고 명령을 내리는 두뇌 역할.
+>     
+> - 어떤 컨테이너를 어디에 띄울지 결정(Scheduling)하고 상태를 감시함.
+>     
+
+> [!abstract] **실행부 (Data Plane / Worker Node)**
+> 
+> - 실제로 컨테이너가 돌아가는 작업 공간(서버).
+>     
+> - 지휘부의 명령을 받아 컨테이너를 실행하고 상태를 보고함.
+>
+
+|**구분**|**서비스 명칭**|**특징**|
+|---|---|---|
+|**오케스트레이터 (지휘자)**|**Amazon ECS / EKS**|컨테이너를 관리하는 룰과 정책을 설정함.|
+|**컴퓨팅 엔진 (연주자)**|**EC2 / Fargate**|실제 컨테이너가 실행되는 물리적/가상적 인프라.|
+
+## 📝 노트
+> [!note]
+> 
+> - 컨테이너를 사용해서 [[가용성(Availability)]]과 [[확장성(Scalability)]]문제를 해결해주는 엔진
+> - 컨테이너를 알아서 잘 사용할 수 있도록 도와주는 엔진
+> - 학습커브는 존재함. ([[쿠버네티스(Kubernetes)]] 학습 필요)
+>   (AWS의 경우 이 학습커브를 완화해주는 ECS 서비스를 제공함.)
+>
+
+## 🔗 지식 연결
+- **태그:** #zettelkasten #knowledge

03.Note/컨테이너(Container).md

@@ -0,0 +1,22 @@
+- 작성 **날짜:** 2026-02-27
+
+## 📑 개념
+> [!abstract] 
+> 컨테이너(Container)는 애플리케이션과 그 실행에 필요한 모든 것(코드, 런타임, 시스템 도구, 라이브러리, 설정 등)을 하나로 묶은 **표준화된 소프트웨어 패키지**입니다.
+
+## 📌 상세
+> [!check] 
+> ### 핵심 개념: "운송용 컨테이너와 같다"
+> 
+> 항구의 컨테이너가 안에 무엇이 들었든(전자제품이든 가구든) 규격화되어 배에 쉽게 실을 수 있듯이, 소프트웨어 컨테이너도 어떤 환경(개발자 PC, 테스트 서버, 클라우드)에서든 **동일하게 작동**하도록 규격화된 것입니다.
+
+## 📝 노트
+> [!note]
+> 
+> - 컨테이너 기술을 사용하기 쉽게 엔진화해놓은것이 도커입니다.
+
+
+![[가상 머신(VM) vs 컨테이너]]
+
+## 🔗 지식 연결
+- **태그:** #docker 

03.Note/코드의 가독성.md

@@ -0,0 +1,53 @@
+---
+id: 코드의 가독성 20260317
+created: 2026-03-17 17:19
+tags:
+aliases:
+---
+## 💡 생각  
+글로 읽을 땐 무슨 말인지 어렴풋이 짐작이 되지만 실제로 해보면 가독성이 좋은 코드를 만드는 건 어렵다.
+
+문장처럼 읽히는 코드와 인지 부하의 최소화는 함수형 프로그래밍이 좋은 대응책인 것 같고,
+
+
+---
+## 📑 개념
+**가독성이 높은 코드**는 단순히 "예쁜 코드"를 넘어 **코드를 읽는 사람의 뇌가 에너지를 최소한으로 쓰게 만드는 코드**를 의미합니다.
+
+## 📌 가독성이 좋은 코드의 기준
+### 1. 문장처럼 읽히는 코드 (의도 노출)
+
+코드를 봤을 때 "어떻게(How)" 작동하는지 분석하기 전에, "무엇을(What)" 하려는지 바로 이해되어야 합니다.
+
+- **나쁜 예:** `if (user.Status == 1 && user.Age > 19 && user.HasPaid)` (숫자 1이 무엇을 의미하는지 한참 생각해야 함)
+    
+- **좋은 예:** `if (user.IsActiveAdultMember())` (함수 이름만으로 의도가 명확함)
+    
+
+### 2. 인지 부하(Cognitive Load)의 최소화
+
+사람의 단기 기억력은 한계가 있습니다. 한 번에 머릿속에 담아야 할 정보가 많을수록 읽기 힘든 코드가 됩니다.
+
+- **낮은 중첩도:** `if` 문 안에 `if`, 그 안에 `for` 루프가 여러 번 겹쳐 있으면 뇌는 각 단계의 조건을 기억하느라 과부하가 걸립니다. (Early Return 패턴 등으로 중첩을 제거하는 것이 좋습니다.)
+    
+- **작은 함수:** 하나의 함수가 100줄이라면 흐름을 놓치기 쉽습니다. 5~10줄 내외의 작은 함수로 쪼개면 각각의 책임이 명확해집니다.
+    
+
+### 3. 일관성 (Consistency)
+
+사람은 패턴을 인식하는 데 능숙합니다. 코드 전체에서 동일한 규칙이 적용되어 있다면 다음에 올 내용을 예측할 수 있게 됩니다.
+
+- 변수 명명 규칙(CamelCase vs snake_case), 폴더 구조, 에러 처리 방식 등이 프로젝트 전체에서 일관되어야 합니다.
+    
+- **"놀람 최소화의 원칙(Principle of Least Astonishment)":** 코드를 읽었을 때 "어? 이게 왜 여기서 이렇게 동작하지?"라는 당혹감이 없어야 합니다.
+    
+
+### 4. [[신호 대 소음비(Signal-to-Noise Ratio)]]
+
+코드에서 진짜 중요한 로직(신호)은 강조하고, 형식적인 문법이나 군더더기(소음)는 줄이는 것입니다.
+
+- **불필요한 주석 제거:** 코드만으로 설명이 가능하다면 주석은 소음일 뿐입니다.
+    
+- **단순한 추상화:** 너무 복잡한 디자인 패턴을 남용하면 실제 비즈니스 로직을 찾기 힘들어집니다.
+
+---

03.Note/쿠버네티스(Kubernetes).md

@@ -0,0 +1,23 @@
+- 작성 **날짜:** 2026-02-27
+K8s (K뒤에 8글자가 있다고 이렇게 표기하기도 함)
+## 📑 개념
+> [!abstract] 
+"수많은 컨테이너를 지휘하여 **사용자가 원하는 상태(Desired State)**로 유지해 주는 거대한 자동화 관리 시스템"
+
+컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화해 주는 오픈 소스 [[컨테이너 오케스트레이션]] 플랫폼**입니다.
+구글이 내부에서 사용하던 시스템을 기반으로 탄생했으며, 현재 전 세계 컨테이너 관리 시스템의 표준으로 자리 잡고 있습니다.
+## 📌 핵심 기능
+> [!check] 
+> **① 선언적 구성 (Declarative Configuration)** "컨테이너 3개를 띄워줘"라고 명령서(YAML 파일)를 던지면, 쿠버네티스가 현재 상태를 확인하고 명령서와 일치하도록 스스로 자원을 조정합니다.
+> **② 자가 치유 (Self-healing)** 컨테이너가 죽으면 즉시 감지하여 새로운 컨테이너를 다시 띄웁니다. 노드 자체가 죽어도 해당 노드에 있던 컨테이너들을 다른 건강한 노드로 옮겨서 실행합니다.
+> **③ 무중단 배포 및 롤백** 서비스를 중단하지 않고 애플리케이션 버전을 업데이트할 수 있으며, 문제가 생기면 즉시 이전 버전으로 되돌리는(Rollback) 기능을 제공합니다.
+
+## 📝 노트
+> [!note]
+> 
+> - 컨테이너 오케스트레이션을 해주는 엔진, 사용방법을 정확히 알고 쓰기가 까다로움.
+>  (알아야 할 내용이 많다.)
+> - 하지만 온라인 서비스 운영에 반드시 필요한 기능들을 다 지원해준다.
+
+## 🔗 지식 연결
+- **태그:** #zettelkasten #knowledge

03.Note/클러스터(Cluster).md

@@ -0,0 +1,45 @@
+- 작성 **날짜:** 2026-02-27
+
+## 📑 개념
+> [!abstract] 
+> **"여러 개의 독립된 자원을 하나의 거대한 단일 시스템처럼 보이게 만드는 기술"**입니다.
+> "여러 대의 컴퓨터(Node)를 네트워크로 연결하여, 외부에서는 마치 한 대의 고성능 컴퓨터처럼 작동하게 만드는 집합체"
+
+## 📌 클러스터의 목적
+> [!check] 
+> |**구분**|**해결하려는 문제**|**클러스터의 역할**|
+> |---|---|---|
+> |**신뢰성 (Reliability)**|한 대가 고장 나면 서비스 중단|**장애 극복(Failover):** 다른 컴퓨터가 즉시 업무를 대신함|
+> |**성능 (Performance)**|한 대의 성능으로는 처리 불가|**병렬 처리:** 작업을 쪼개어 여러 대가 동시에 수행|
+> |**확장성 (Scalability)**|성능을 더 높여야 하는 상황|**수평 확장:** 컴퓨터를 옆으로 계속 이어 붙임|
+
+신뢰성과 확장성을 확보하고 고성능 처리를 하기 위함
+
+### 클러스터의 핵심 구성 요소
+**① 노드 (Node)** 클러스터에 참여하는 개별 컴퓨터입니다. 물리 서버일 수도 있고 가상 머신(VM)일 수도 있습니다.
+
+**② 전용 네트워크 (Cluster Interconnect)** 노드들끼리 데이터를 주고받고 서로의 생사를 확인(Heartbeat)하기 위한 초고속 통신망입니다.
+
+**③ 클러스터 웨어 (Clusterware/Middleware)** 여러 대의 노드를 하나로 묶어 관리하는 소프트웨어 층입니다. 누가 대장(Master)인지, 누가 죽었는지, 작업을 어디에 보낼지 결정합니다.
+
+
+### 💡 한눈에 보는 비유: "오케스트라"
+
+- **연주자 한 명:** 개별 컴퓨터 (Node)
+- **오케스트라 전체:** 클러스터 (Cluster)
+- **지휘자:** 클러스터 웨어 (관리 시스템)
+    
+- **관객(사용자):** 관객은 개별 연주자의 연습 상태가 아니라, 오케스트라가 만들어내는 **하나의 완성된 교향곡(서비스)**을 듣습니다. 연주자 한 명이 잠시 자리를 비워도(장애) 다른 연주자가 메워주어 곡은 계속 연주됩니다.
+
+[[컨테이너 오케스트레이션]]
+컨테이너 오케스트레이션은 즉 하나의 완성된 서비스 형태의 컨테이너 오케스트레이션을 의미
+
+## 📝 노트
+> [!note]
+> 
+> - 여러개의 컴퓨터를 하나의 추상적인 단위로 묶어서 하나의 컴퓨터처럼 쓸수있게 해주는 기술
+> - 즉, 여러 노드의 합으로 하나의 슈퍼컴퓨터를 구성하는 것
+>
+
+## 🔗 지식 연결
+- **태그:** #zettelkasten #knowledge

03.Note/태스크 실행 역할(Task Execution Role).md

@@ -0,0 +1,22 @@
+---
+id: "태스크 실행 역할(Task Execution Role) 20260305"
+created: "2026-03-05 09:35"
+tags:
+---
+## 💡 생각  
+태스크가 동작하기 위해 필요한 권한들을 정의해놓는다고 생각하면 됨.
+
+---
+## 📑 개념
+> [!abstract] 
+> "태스크를 실행하기 위해 ECS 서비스가 빌려 쓰는 권한"
+태스크가 실제로 구동되기 **전**과 구동되는 **과정**에서 필요한 권한
+## 📌 주요 용도
+> [!check] 
+> - **ECR 이미지 풀(Pull):** 프라이빗 저장소에서 도커 이미지를 다운로드할 권한.
+>     
+> - **CloudWatch Logs:** 로그를 기록하기 위해 로그 그룹에 접근할 권한.
+>     
+> - **Secrets Manager / Parameter Store:** 환경 변수에 담을 비밀번호나 설정값을 가져올 권한.
+
+---

03.Note/태스크 역할(Task Role).md

@@ -0,0 +1,32 @@
+---
+id: "태스크 역할(Task Role) 20260305"
+created: "2026-03-05 09:38"
+tags:
+---
+## 💡 생각  
+태스크의 컨테이너에서 구동되는 애플리케이션의 권한을 지정해줄 수 있음.
+애플리케이션이 AWS의 서비스에 직접 접근해서 사용하는 경우에 설정이 필요함
+
+---
+## 📑 개념
+> [!abstract] 
+> "내 애플리케이션(코드)이 실행 중에 직접 사용하는 권한"
+> 태스크가 **실행된 후**, 내 소스 코드(Java, Python, Node.js 등) 안에서 AWS SDK를 통해 다른 서비스를 호출할 때 필요한 권한입니다.
+
+## 📌 주요 용도
+> [!check] 
+> - **S3 버킷 접근:** 사용자가 업로드한 파일을 저장하거나 읽을 때.
+>     
+> - **DynamoDB/RDS:** 데이터베이스에 데이터를 쓰고 읽을 때.
+>     
+> - **SQS/SNS:** 메시지를 보내거나 받을 때.
+
+## 📝 노트
+> [!note]
+> 
+> - 관련 사례나 반대되는 개념이 있다면 여기에 기록하세요.
+>     
+> - 본인의 언어로 풀어서 쓰는 것이 제텔카스텔의 핵심입니다.
+>
+
+---

03.Note/태스크 정의 패밀리.md

@@ -0,0 +1,44 @@
+---
+id: 태스크 정의 패밀리 20260305
+created: 2026-03-05 09:04
+tags:
+---
+## 💡 생각  
+태스크는 인스턴스, 태스크 정의 패밀리는 객체와 같다고 보면 된다.
+즉, 붕어빵(태스크)과 붕어빵틀(태스크 정의 패밀리)의 사이와 같다.
+
+> [!question]
+> Q. 태스크 이름이라고 하면 되지 왜 태스크 정의 패밀리 이름 이라고 이상하게 이름붙여놓은거야?
+> A. 그 마음 100% 이해합니다! 처음에 AWS ECS를 접하면 **"그냥 태스크 이름(Task Name)이라고 하면 될걸, 왜 굳이 '패밀리(Family)'라는 거창한 단어를 붙여서 헷갈리게 할까?"**라는 생각이 들기 마련이죠.
+
+이게 단순히 이름을 어렵게 지은 게 아니라, **'버전 관리'**라는 개념 때문에 그렇습니다.
+
+## 1. 태스크 정의는 "한 번 쓰면 수정 불가능(Immutable)" 하기 때문입니다
+
+AWS ECS에서 **태스크 정의(Task Definition)**는 한 번 만들면 내용을 고칠 수 없습니다. 만약 이미지 태그를 `v1`에서 `v2`로 바꾸고 싶다면, 기존 것을 수정하는 게 아니라 **새로운 버전**을 구워내야 합니다.
+
+이때, **"이 설계도들은 다 같은 용도의 설계도들이야"**라고 묶어주는 그룹 이름이 바로 **패밀리(Family)**입니다.
+
+- **Family Name:** `my-web-app` (성씨)
+    
+- **Revision 1:** `my-web-app:1` (첫째)
+    
+- **Revision 2:** `my-web-app:2` (둘째)
+    
+- **Revision 3:** `my-web-app:3` (셋째)
+    
+
+## 2. '태스크 이름'과 구분하기 위해서입니다
+
+만약 이걸 그냥 '태스크 이름'이라고 불러버리면, **실제로 돌아가고 있는 실행 객체(Running Task)**와 구분이 안 됩니다.
+
+- **태스크 정의 패밀리 (Family):** "웹 서버를 띄우기 위한 **설계도 세트**" (붕어빵 틀의 종류)
+    
+- **태스크 (Task):** "지금 서버에서 **실제로 돌아가고 있는 프로세스**" (틀에서 찍어낸 실제 붕어빵)
+    
+
+만약 질문자님이 `my-web-app`이라는 패밀리 이름을 정했다면, 그 설계도로 10개의 **태스크**를 띄울 수 있습니다. 이때 "태스크 이름이 뭐야?"라고 물으면 "10개 중에 어떤 거?"라고 되묻게 되죠. 그래서 **설계도의 이름**은 '패밀리'라고 불러서 확실히 구분 짓는 것입니다.
+
+## 3. 서비스(Service)와의 연결 고리
+
+ECS **서비스**를 만들 때 "어떤 태스크를 돌릴래?"라고 물어보는데, 이때 특정 버전(`:1`)을 지정할 수도 있지만, 보통은 **패밀리 이름**을 지정합니다. 그러면 서비스는 **"아, 이 패밀리(가족) 중에서 가장 최신 버전(Latest Revision)을 가져다가 쓰면 되겠구나!"**라고 판단합니다.

03.Note/태스크(Task).md

@@ -0,0 +1,29 @@
+---
+id: 태스크(Task) 20260304
+created: 2026-03-04 17:12
+tags:
+---
+## 💡 생각  
+컴퓨터가 처리하는 작업 단위에 더해 어떻게 처리를 해야 하는지 에 대한 모든 정보들을 담아 놓은 실행 단위
+태스크 단위로 프로그램을 실행한다. 이런 느낌인 듯
+
+---
+## 📑 개념
+> [!abstract] 
+> 컴퓨터가 처리하는 **'작업 단위'**를 말합니다.
+
+
+## 📝 ECS에서의 태스크
+> [!note]
+> 태스크는 단순히 컨테이너 하나만을 의미하지 않습니다. 하나의 태스크 안에는 다음과 같은 요소들이 포함됩니다.
+- **하나 이상의 컨테이너:** 보통은 하나의 메인 애플리케이션 컨테이너가 들어가지만, 로그 수집이나 프록시 역할을 하는 '사이드카(Sidecar)' 컨테이너를 함께 묶어 실행할 수도 있습니다.
+    
+- **공유 자원:** 태스크 내의 컨테이너들은 **동일한 네트워크 네임스페이스(IP 주소)**와 **스토리지 볼륨**을 공유합니다. 즉, 태스크 안의 컨테이너끼리는 `localhost`로 통신이 가능합니다.
+    
+- **실행 환경 설정:** CPU, 메모리 제한, IAM 역할(권한), 네트워크 모드 등이 태스크 단위로 설정됩니다.
+---
+
+## 🔗 관련 노트
+- [[IAM(Identity and Access Management)]]
+
+**Tags:** #task

03.Note/테넌시(Tenancy).md

@@ -0,0 +1,40 @@
+---
+id: "테넌시(Tenancy) 20260305"
+created: "2026-03-05 13:01"
+tags:
+---
+## 💡 생각  
+테넌시가 차용, 임대차 뭐 그런 뜻이니까 결국 컴퓨팅 환경을 임대해서 쓴다 그런 느낌으로 이해하면 됨
+
+---
+## 📑 개념
+사전적 의미로 '임대차' 또는 '차용'을 뜻하지만, IT와 클라우드 컴퓨팅 환경에서는 **소프트웨어 인스턴스나 컴퓨팅 자원을 공유하는 방식**을 의미합니다.
+
+## 📌 상세
+1. [[멀티 테넌시(Multi-tenancy)]]
+2. [[싱글 테넌시(Single-tenancy)]]
+
+### 비교 요약
+
+| **구분**    | **멀티 테넌시 (Multi-tenancy)** | **싱글 테넌시 (Single-tenancy)** |
+| --------- | -------------------------- | --------------------------- |
+| **비유**    | 아파트, 호텔                    | 단독 주택                       |
+| **자원 공유** | 여러 테넌트가 공유                 | 단일 테넌트 전용                   |
+| **비용**    | 저렴함 (SaaS 모델)              | 비쌈 (전용 서버 모델)               |
+| **보안**    | 양호 (논리적 격리)                | 최고 (물리적 격리)                 |
+| **적합한 곳** | 일반 사용자, 중소기업               | 대기업, 금융권, 정부 기관             |
+
+## 📝 노트
+> [!note]
+> 
+> - 온프레미스와 싱글 테넌시는 서로 다른 개념
+
+|**구분**|**온프레미스 (On-premise)**|**싱글 테넌시 (Single-tenancy)**|
+|---|---|---|
+|**관점**|**어디에** 서버가 있는가?|**누가** 이 자원을 독점하는가?|
+|**위치**|우리 회사 내부 전산실|어디든 상관없음 (회사 내부 or 클라우드)|
+|**반대 개념**|퍼블릭 클라우드 (Public Cloud)|멀티 테넌시 (Multi-tenancy)|
+
+---
+
+모든 온프레미스는 대개 싱글 테넌시 구조를 가집니다 (자사 서비스만 돌리니까요). 하지만 모든 싱글 테넌시가 온프레미스인 것은 아닙니다. 요즘은 클라우드 환경에서도 보안이나 성능을 위해 싱글 테넌시 방식을 많이 사용합니다.

03.Note/파게이트 스팟(Fargate Spot).md

@@ -0,0 +1,55 @@
+---
+id: 파게이트 스팟(Fargate Spot) 20260305
+created: 2026-03-05 10:32
+tags:
+---
+## 💡 생각  
+공용 [[파게이트(Fargate)]]를 저렴하게 빌려서 쓸 수 있는데 언제 자리를 빼줘야할지 모른다.
+
+
+---
+## 📑 개념
+> [!abstract] 
+> AWS의 남는 컴퓨팅 용량을 활용하여 훨씬 저렴한 가격에 [[파게이트(Fargate)]]서비스를 이용하는 요금 모델을 의미합니다.
+
+쉽게 말해, **"쓰지 않고 노는 서버를 빌려 쓰는 대신, 아주 싼 값에 파게이트를 이용하는 방식"**이라고 이해하시면 됩니다.
+
+## 📌 특징
+> [!check] 
+> ### 1. 파격적인 비용 절감
+> 
+> - 기존 파게이트 가격 대비 **최대 70%까지 저렴**하게 이용할 수 있습니다.
+>     
+> - 예산이 한정된 프로젝트나 대규모 배치를 실행할 때 매우 경제적입니다.
+>     
+> 
+> ### 2. 서버리스의 편리함
+> 
+> - 인프라(EC2 인스턴스)를 직접 관리할 필요가 없습니다.
+>     
+> - 컨테이너 설정만 하면 AWS가 알아서 실행하고 관리해 줍니다.
+>     
+> 
+> ### 3. 중단 가능성 (중요!)
+> 
+> - AWS에 자원이 부족해지면 **실행 중인 작업이 예고 없이 중단**될 수 있습니다.
+>     
+> - 중단되기 약 2분 전에 알림을 주지만, 기본적으로 언제든 꺼질 수 있다는 점을 고려해야 합니다.
+
+## 📝 노트
+> [!note] 파게이트 스팟은 **"중간에 꺼져도 다시 실행하면 그만인 작업"**에 최적화되어 있습니다.
+> 
+> - **배치 작업:** 이미지 처리, 데이터 분석, 로그 수집 등.
+>     
+> - **테스트 환경:** 개발 단계에서 테스트용으로 띄우는 서버.
+>     
+> - **확장성 대응:** 메인 서버는 일반 파게이트로 띄우고, 갑자기 트래픽이 몰릴 때 추가되는 서버만 스팟으로 설정.
+>
+
+## ⚠️ 주의사항
+> [!warning]
+> - **상태 비저장(Stateless):** 서버가 언제든 꺼질 수 있으므로, 서버 내부에 데이터를 저장하면 안 됩니다. 데이터는 외부 DB나 S3에 저장해야 합니다.
+>     
+> - **가용성 전략:** 서비스가 완전히 멈추는 것을 방지하기 위해, 안정적인 **Fargate On-Demand**와 **Fargate Spot**을 적절한 비율(예: 4:6)로 섞어서 사용하는 것이 권장됩니다.
+
+---

03.Note/파게이트(Fargate).md

@@ -0,0 +1,14 @@
+- 작성 **날짜:** 2026-02-27
+
+## 📑 개념
+> [!abstract] 
+> **AWS Fargate**는 Amazon ECS(Elastic Container Service)나 EKS(Elastic Kubernetes Service)에서 작동하는 [[서버리스(Serverless)]] 컴퓨팅 엔진입니다. 컨테이너를 실행하기 위해 가상 머신(EC2)을 직접 관리할 필요 없이, 컨테이너 단위로 배포하고 운영할 수 있게 해줍니다.
+
+## 📌 주요 특징
+- **관리 부담 제로 (No Infrastructure Management):** 더 이상 "윈도우 7 지원 종료"나 "서버 라이브러리 충돌" 같은 인프라 문제로 고민할 필요가 없습니다. OS 수준의 관리는 AWS가 책임집니다.
+- **보안 및 격리 (Security by Design):** 각 컨테이너(Task)는 고유한 가상화 경계 내에서 실행되므로, 한 서비스의 장애나 보안 취약점이 다른 서비스로 전파되지 않습니다.
+- **유연한 스케일링:** 트래픽이 몰릴 때 서버(Node)를 추가로 띄우는 복잡한 과정 없이, 컨테이너 수만 늘리면 AWS가 알아서 가용자원을 할당합니다.
+
+## 🔗 지식 연결
+- **태그:** #fargate
+- 

03.Note/파게이트(Fargate)의 장점.md

@@ -0,0 +1,20 @@
+- 작성 **날짜:** 2026-02-27
+## 📝 장점
+> [!note]
+> - **[[가용성(Availability)]]**: 하드웨어 장애 시 AWS가 즉시 컨테이너를 다른 곳에 재배치하여 **Self-healing**을 구현합니다.
+>     
+> - **[[유연성(Flexibility)]] & [[확장성(Scalability)]]**: 트래픽 변화에 맞춰 컨테이너 개수만 조절하면 즉시 확장되는 **Serverless 스케일링**을 제공합니다.
+>     
+> - **[[보안성(Security)]]**: 태스크 단위의 **강력한 격리**와 자동화된 호스트 OS 패치로 보안 리스크를 최소화합니다.
+>     
+> - **[[생산성(Productivity)]]**: 서버 관리 업무(OS, 패치 등)가 사라져 개발자가 **비즈니스 로직에만 집중**할 수 있습니다.
+
+## 📝 노트
+> [!note]
+> 
+> - 결국 Aws가 안정성을 보장하는 컨테이너를 굴려주기 때문에 발생되는 장점들임
+> - 전문가가 인프라 문제를 책임져주는 컴퓨팅 환경이라고 생각하자
+>
+
+## 🔗 지식 연결
+- **태그:** #zettelkasten #knowledge

03.Note/파레토의 법칙.md

@@ -0,0 +1,50 @@
+---
+id: "파레토의 법칙 20260317"
+created: "2026-03-17 16:33"
+tags:
+aliases:
+---
+## 💡 생각  
+이걸 컴퓨터 프로그램에 대입해서 전체 프로그램 사용 시간의 80%가 20%의 코드에 의해 동작한다. 라고 할 수 있겠다.
+
+
+---
+## 📑 개념
+전체 결과의 **80%** 가 전체 원인의 **20%** 에서 일어나는 현상을 말합니다.
+**80 대 20 법칙**이라고도 불리며, 경영, 경제, 일상생활 등 다양한 분야에서 효율성을 강조할 때 자주 인용됩니다.
+
+## 📌 상세
+
+### 1. 유래
+
+이 법칙은 19세기 이탈리아의 경제학자 **빌프레도 파레토(Vilfredo Pareto)** 가 발견했습니다. 그는 이탈리아 인구의 20%가 전체 부의 80%를 소유하고 있다는 사실을 알아냈고, 이후 품질 관리 전문가인 조셉 주란(Joseph Juran)이 이 개념을 기업 경영과 품질 관리에 적용하면서 대중화되었습니다.
+
+### 2. 주요 사례
+
+우리 주변에서도 이 법칙이 적용되는 사례를 쉽게 찾아볼 수 있습니다.
+
+- **기업 경영:** 전체 매출의 80%는 상위 20%의 단골 고객에게서 발생합니다.
+    
+- **소프트웨어 개발:** 사용자들의 불만 사항 중 80%는 전체 버그의 20%에서 기인합니다.
+    
+- **자기 계발:** 성과의 80%는 우리가 집중하는 시간 중 핵심적인 20%에서 나옵니다.
+    
+- **언어:** 일상 대화에서 사용하는 단어의 80%는 전체 어휘의 약 20%에 불과합니다.
+
+### 3. 파레토 법칙의 핵심 메시지: 선택과 집중
+
+이 법칙이 주는 가장 큰 교훈은 **모든 노력이 동일한 가치를 가지지 않는다**는 점입니다.
+
+1. **우선순위 설정:** 10가지 일이 있다면 그중 가장 큰 성과를 낼 2가지 핵심 업무에 먼저 집중해야 합니다.
+    
+2. **효율성 극대화:** 적은 노력으로 최대의 효과를 내기 위해 불필요한 80%의 주변 업무를 덜어내는 과정이 필요합니다.
+    
+3. **자원 배분:** 한정된 시간과 비용을 가장 수익성이 높은 20%에 집중적으로 투자하는 전략이 유효합니다.
+
+## 📝 노트
+> [!note]
+> 
+> 파레토 법칙은 엄격한 수학적 공식이 아니라 하나의 **경향성**입니다. 실제 비율은 70:30이 될 수도 있고 90:10이 될 수도 있습니다. 중요한 것은 원인과 결과의 불균형을 이해하고 핵심에 집중하는 태도입니다.
+>
+
+---

03.Note/확장성(Scalability).md

@@ -0,0 +1,38 @@
+- 작성 **날짜:** 2026-02-27
+
+## 📑 개념
+> [!abstract] 
+> 단순히 "서버를 늘린다"는 개념을 넘어, **시스템의 규모가 커짐에 따라 성능과 비용의 효율성을 유지**하는것을 의미
+
+### 확장성의 두 가지 방향: Scale-up vs Scale-out
+확장성은 리소스를 추가하는 방식에 따라 크게 두 가지로 나뉩니다.
+
+## 📌 상세
+> [!check] 
+> #### ① 수직 확장 (Scale-up)
+> 
+> 하나의 서버 자체의 사양(CPU, RAM, Disk)을 더 높은 등급으로 교체하는 방식입니다.
+> 
+> - **장점:** 아키텍처 변경이 거의 필요 없고 설정이 단순함.
+>     
+> - **단점:** 하드웨어 한계(Physical Limit)가 존재하며, 사양이 높아질수록 비용이 기하급수적으로 상승함. 교체 시 다운타임이 발생할 수 있음.
+>     
+> 
+> #### ② 수평 확장 (Scale-out)
+> 
+> 비슷한 사양의 서버를 여러 대 추가하여 부하를 분산하는 방식입니다.
+> 
+> - **장점:** 이론상 **무한 확장**이 가능하며, 서버 한 대가 죽어도 서비스 유지가 가능한 **고가용성**을 제공함.
+>     
+> - **단점:** 트래픽을 분산해 줄 **로드 밸런서(ALB 등)**가 필수적이며, 데이터 동기화와 같은 분산 시스템 설계의 복잡도가 증가함.
+
+## 📝 노트
+> [!note]
+> 
+> - 관련 사례나 반대되는 개념이 있다면 여기에 기록하세요.
+>     
+> - 본인의 언어로 풀어서 쓰는 것이 제텔카스텔의 핵심입니다.
+>
+
+## 🔗 지식 연결
+- **태그:** #zettelkasten #knowledge