commit 5b65a8e8c29d0d4f509b0459421c112927b6e2d5 Author: dihwang Date: Tue Mar 31 10:55:30 2026 +0900 Initial Kui Vault diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..e4013b5 --- /dev/null +++ b/.gitignore @@ -0,0 +1,8 @@ +# Created by https://www.toptal.com/developers/gitignore/api/obsidian +# Edit at https://www.toptal.com/developers/gitignore?templates=obsidian + +### Obsidian ### +# config dir +.obsidian/ + +# End of https://www.toptal.com/developers/gitignore/api/obsidian \ No newline at end of file diff --git a/01.Shelf/CLEAN CODE/클린코드의 기술.md b/01.Shelf/CLEAN CODE/클린코드의 기술.md new file mode 100644 index 0000000..5579a21 --- /dev/null +++ b/01.Shelf/CLEAN CODE/클린코드의 기술.md @@ -0,0 +1,15 @@ +1. [[단순함의 노하우(Introduction)]] + +2. [[80대20 원칙(The Pareto Principle)]] + +3. [[최소 기능 제품 (MVP)]] + +4. [[코딩 원칙 (YAGNI, KISS, DRY)]] + +5. [[유닉스 철학 (The Unix Philosophy)]] + +6. [[설계와 추상화]] + +7. [[디버깅과 테스트]] + +8. [[협업과 지속 가능한 개발]] \ No newline at end of file diff --git a/01.Shelf/CMMS/AWS Architecture로 전환.md b/01.Shelf/CMMS/AWS Architecture로 전환.md new file mode 100644 index 0000000..0b85e6b --- /dev/null +++ b/01.Shelf/CMMS/AWS Architecture로 전환.md @@ -0,0 +1,13 @@ +[[꼭 알아둬야 할 것들]] + +[[AWS Architecture로의 전환이 필요한 이유]] (As-Is) + +[[온프레미스에서 EC2 기반으로]] + +[[컨테이너 기반의 아키텍처]] (To-Be) + +[[ECS와 EKS]] + +[[EKS Cluster]] + +[[AWS ECS 구성하기]] \ No newline at end of file diff --git a/01.Shelf/CMMS/CMMS 마이그레이션.md b/01.Shelf/CMMS/CMMS 마이그레이션.md new file mode 100644 index 0000000..3824f0c --- /dev/null +++ b/01.Shelf/CMMS/CMMS 마이그레이션.md @@ -0,0 +1,27 @@ +--- +id: "CMMS 마이그레이션 20260319" +created: "2026-03-19 12:58" +tags: +aliases: +--- +마이그레이션: 신규 고객의 셋업작업 진행 시 필요한 데이터를 DB로 밀어넣는 과정 + + +엑셀파일로 된 마이그레이션 필요 문서 작성 (담당자가 따로있나봄) +(원본엑셀 -> 마이그레이션 할 데이터 엑셀 ) + +/auth/fullmigration +( CMMS 엔터프라이즈형은 /auth/mig ) +마이그레이션 페이지가 따로 만들어져있음. + +여기서 엑셀파일들을 전부 다 execute migration 진행해줘야 함 +너무 많은 데이터를 한번에 시도하면 문제가 될 수 있어서 +분리해서 진행해야함. + + +파일 마이그레이션은 암호화(확장자없는) 파일을 먼저 만들고 (엑셀파일부터 작성) +...? 그다음에 뭘 또 해야한다는데 이건 이해 못함 + + +shared-service: 마이그레이션, open API (우리는 일단 신경x) 등등의 기능들을 처리해주는 서비스 + diff --git a/01.Shelf/EIOM/펀치리스트.md b/01.Shelf/EIOM/펀치리스트.md new file mode 100644 index 0000000..26e040e --- /dev/null +++ b/01.Shelf/EIOM/펀치리스트.md @@ -0,0 +1,2 @@ +[[VPN으로 외부 DB에 접근]] + diff --git a/01.Shelf/KUI/01. 아키텍처 흐름.md b/01.Shelf/KUI/01. 아키텍처 흐름.md new file mode 100644 index 0000000..7c9133a --- /dev/null +++ b/01.Shelf/KUI/01. 아키텍처 흐름.md @@ -0,0 +1,16 @@ +- **Obsidian Vault (Private Repo):** 개인용 비공개 저장소에 마스킹되지 않은 원본 노트를 push합니다. + +- **Jenkins Trigger:** 젠킨스가 Webhook을 통해 push 이벤트를 감지하거나 주기적으로 폴링(Polling)합니다. + +- **Validation & Masking (Build Step):** 젠킨스 서버 내에서 Python 스크립트 등을 실행해 변경된 파일의 민감 정보를 검증하고 수정합니다. + +- **Push to Quartz (Post-build):** 정제된 파일을 쿼츠 저장소로 복사한 뒤, 해당 저장소에 커밋 및 push를 수행합니다. + +> [!todo] **필요한것** 📋 +> +> - [x] kui vault repository +> - [x] kui repository +> - [ ] Jenkins 서버 ( 구글에서 제공해주는 클라우드 서버 확보하면 될 듯 ) +> - [ ] blur 처리 용 서버 ( kui veil, veil 이라고 이름 지으면 될 듯 ) + +jenkins 서버를 구성해보자 \ No newline at end of file diff --git a/01.Shelf/KUI/02. Jenkins 서버 구축 계획.md b/01.Shelf/KUI/02. Jenkins 서버 구축 계획.md new file mode 100644 index 0000000..04508a9 --- /dev/null +++ b/01.Shelf/KUI/02. Jenkins 서버 구축 계획.md @@ -0,0 +1,58 @@ +확보중인 개인용 서버가 없기 때문에 서버부터 확보해야 함. + +> [!question] +> Q. 클라우드 서버를 확보해야해. 무료여야하고 지금 내가 하려는 블러처리작업용으로 적당한정도면 돼 +> A. 무료이면서 **젠킨스**와 **마스킹 스크립트(Python)**를 돌리기에 가장 적합한 클라우드 서비스 3가지를 추천해 드릴게요. 2026년 현재 기준으로도 가장 안정적인 옵션들입니다. + +|**비교 항목**|**Oracle Cloud**|**Google Cloud**|**AWS**| +|---|---|---|---| +|**성능 (RAM)**|⭐⭐⭐⭐⭐ (24GB)|⭐ (1GB)|⭐⭐ (2GB)| +|**안정성**|⭐⭐⭐|⭐⭐⭐⭐⭐|⭐⭐⭐⭐⭐| +|**추천 이유**|젠킨스 구동에 여유로움|설정이 매우 간편함|글로벌 표준 학습 가능| +이 중 AWS는 일정기간만 무료임 +오라클은 아직 마이너해서 쓰고싶지 않음 +GCP로 가기로 함. +Google Cloud Platform + +--- +구글 클라우드(GCP)에서 **평생 무료**로 쓸 수 있는 사양은 딱 하나 정해져 있습니다. 바로 **e2-micro** 인스턴스입니다. 실시간 응답이 중요하지 않은 **`kui-ink`** 서버용으로는 아주 적절한 선택이에요. + +GCP에서 무료로 구동하기 위한 '필수 조건'을 정리해 드릴게요. 이대로만 설정하면 돈이 나가지 않습니다. + +--- + +### 🖥️ GCP 평생 무료 서버 설정값 (2026 기준) +|**항목**|**설정해야 할 값**|**비고**| +|---|---|---| +|**리전 (Region)**|**us-west1** (오리건)|한국에서 가장 지연시간이 적은 무료 리전| +|**머신 유형**|**e2-micro**|2 vCPU, 1GB RAM (공유 코어)| +|**부팅 디스크**|**Standard** Persistent Disk|'Balanced'나 'SSD'는 유료입니다!| +|**디스크 용량**|**30GB** 이하|무료 한도가 딱 30GB까지입니다.| +### ⚠️ 주의할 점 (젠킨스 구동 관련) + +**e2-micro**는 램이 **1GB**뿐입니다. 젠킨스는 Java 기반이라 기본적으로 메모리를 많이 먹어서, 그냥 실행하면 서버가 멈출 수도 있어요. 이를 해결하기 위한 팁입니다. + +1. **Swap 메모리 설정:** 부족한 램을 보충하기 위해 하드디스크의 일부(약 2GB)를 가상 메모리로 사용하는 설정을 반드시 해줘야 합니다. + +2. **경량화 설정:** 젠킨스 실행 옵션에서 사용할 메모리 최대치(`-Xmx`)를 제한하면 1GB 환경에서도 꾸역꾸역 돌아갑니다. + +3. **오리건 리전:** 앞서 말씀드린 것처럼 한국 리전은 무료가 아니므로 꼭 **us-west1**을 선택하세요. + +### 🚀 다음 단계: 서버 생성하기 + +GCP 콘솔에 접속해서 아래 순서대로 진행해 보세요. + +1. [GCP 콘솔](https://console.cloud.google.com/) 접속 및 프로젝트 생성 + +2. **Compute Engine > VM 인스턴스** 메뉴로 이동 + +3. **인스턴스 만들기** 클릭 + +4. 위에 표에 적힌 **리전, 머신 유형, 디스크**를 정확히 선택 + +5. 하단 **만들기** 버튼 클릭 + + +혹시 가입이나 인스턴스 생성 중에 막히는 부분이 생기면 바로 말씀해 주세요. 서버가 만들어지면 바로 **`kui-ink`**라는 이름을 붙여주고 젠킨스 설치로 넘어가겠습니다! + +**지금 바로 GCP 가입을 시도해 보시겠어요?** 가입 후 서버 생성 화면까지 가시면 다음 가이드를 드릴게요. \ No newline at end of file diff --git a/01.Shelf/KUI/03. Jenkins 설치.md b/01.Shelf/KUI/03. Jenkins 설치.md new file mode 100644 index 0000000..a140f85 --- /dev/null +++ b/01.Shelf/KUI/03. Jenkins 설치.md @@ -0,0 +1,60 @@ +를 시도했지만 실패함. +아마 우분투 최신버전 (25. 몇이었는데..)과 젠킨스가 잘 안맞는거 같음. + +젠킨스말고 다른 우회방법을 찾아봄 + +> [!question] +> Q. 젠킨스를 대체할만한 프로그램없어? +> A. 젠킨스의 그 복잡한 설정과 인증 오류 때문에 정말 정이 뚝 떨어지셨을 것 같습니다. 180°C의 열정으로 시작했는데 도구 설치부터 막히면 누구라도 다른 길을 찾고 싶어지죠. +> +> **HDI**님이 원하시는 건 **내 서버(GCP) 내에서 직접 돌아가면서**, 젠킨스처럼 UI도 있고, 내 Obsidian 노트를 Quartz로 빌드해 배포해줄 **'설치가 쉽고 가벼운'** 대체 프로그램이겠죠? +> +> 젠킨스의 무거운 Java 기반 엔진 대신, 요즘 개발자들 사이에서 **젠킨스 킬러**로 불리는 가벼운 도구 2가지를 추천해 드립니다. + +### 🛠️ 젠킨스를 대체할 가벼운 CI/CD 도구 TOP 2 + +#### 1. [[Woodpecker]] CI (강력 추천) + +젠킨스가 대형 버스라면, [[Woodpecker]]는 날렵한 전기차 같습니다. **Go 언어**로 만들어져서 메모리를 아주 적게 먹고, 설정이 매우 직관적입니다. + +- **장점:** 젠킨스보다 훨씬 가볍습니다(1GB 램인 `e2-micro`에 최적). 모든 설정을 `.woodpecker.yml` 파일 하나로 끝낼 수 있습니다. + +- **UI:** 젠킨스처럼 깔끔한 웹 대시보드를 제공합니다. + +- **설치:** 도커(Docker)를 이용하면 명령어 한두 줄로 끝납니다. 아까 같은 `GPG` 오류와 싸울 필요가 없습니다. + + +#### 2. Gitea Actions (Gitea를 쓰신다면 최고) + +만약 내 서버에 소스코드를 직접 관리하고 싶다면 **Gitea**를 설치하는 방법이 있습니다. Gitea 안에는 GitHub Actions와 거의 똑같은 방식의 **Actions** 기능이 내장되어 있습니다. + +- **장점:** 소스코드 관리(Git)와 자동 배포(CI/CD)를 한 곳에서 끝낼 수 있습니다. + +- **특징:** GitHub Actions 문법을 그대로 쓸 수 있어 학습 곡선이 낮습니다. + +### 💡 왜 이 도구들이 젠킨스보다 나을까요? + +젠킨스는 20년 전 기술이라 설치 과정부터 수많은 의존성(Java 버전, GPG 키 등)과 싸워야 합니다. 반면 **Woodpecker** 같은 최신 도구들은 **도커(Docker)** 기반으로 돌아가는 것을 기본으로 합니다. + +**도커를 사용하면:** + +1. 내 서버의 우분투 버전이 무엇이든 상관없습니다. + +2. `GPG` 키 에러, `NO_PUBKEY` 에러 같은 지긋지긋한 문제에서 완전히 해방됩니다. + +3. 삭제하고 싶을 때도 명령어 한 줄이면 찌꺼기 없이 사라집니다. + + +--- + +### 🚀 HDI님을 위한 새로운 제안 + +**"도커(Docker)를 먼저 깔고, 그 위에 Woodpecker CI를 올려보는 건 어떠신가요?"** + +도커는 설치가 아주 쉽고, 한 번 깔아두면 나중에 다른 프로그램을 올릴 때도 지금 같은 고생을 안 하게 해주는 마법 같은 도구입니다. 180°C의 집념을 젠킨스와의 싸움이 아닌, **진짜 자동화 시스템 구축**에 쏟으실 수 있게 도와드릴게요. + + +# 그래서 [[Woodpecker]] CI를 사용해보기로 함 +docker 기반으로 구동되는 CI/CD tool +도커 기반이니까 당연히 os 안탈거같다 + diff --git a/01.Shelf/KUI/04. Woodpecker 설치.md b/01.Shelf/KUI/04. Woodpecker 설치.md new file mode 100644 index 0000000..78f8c54 --- /dev/null +++ b/01.Shelf/KUI/04. Woodpecker 설치.md @@ -0,0 +1,117 @@ +## 1. 개요 + +기존 젠킨스(Jenkins)는 자바 기반으로 메모리 점유율이 높아 저사양 서버에서 구동이 힘들었음. 이를 해결하기 위해 Go 언어 기반의 초경량 CI 도구인 **Woodpecker**를 도입하고, 도커(Docker) 기반으로 환경을 재구축함. + +--- + +## 2. 환경 정화 및 도커 설치 + +무거운 자바를 삭제하고 현대적인 컨테이너 환경을 준비함. + +```bash +# OpenJDK 삭제 및 정리 +sudo apt purge -y openjdk-17-jre openjdk-17-jre-headless +sudo apt autoremove -y + +# 도커(Docker) 설치 +curl -fsSL https://get.docker.com -o get-docker.sh +sudo sh get-docker.sh + +# 현재 사용자에게 도커 권한 부여 +sudo usermod -aG docker $USER +newgrp docker # 로그아웃 없이 권한 즉시 적용 +``` + +## 3. GitHub OAuth 앱 등록 + +우드패커가 GitHub 저장소에 접근할 수 있도록 통행증을 발급함. + +1. **GitHub Settings > Developer settings > OAuth Apps** 이동 + +2. **New OAuth App** 생성 + + - Homepage URL: `http://34.19.79.94:8000` + + - Authorization callback URL: `http://34.19.79.94:8000/authorize` + +3. **Client ID**와 **Client Secret** 발급 및 보관 + + +--- + +## 4. 우드패커 서버 및 에이전트 배포 + +`docker-compose`를 사용하여 서버(두뇌)와 에이전트(일꾼)를 동시에 띄움. + +**파일 위치:** `~/woodpecker/docker-compose.yaml` + +```bash +services: + woodpecker-server: + image: woodpeckerci/woodpecker-server:latest + ports: + - 8000:8000 + volumes: + - ./woodpecker-server:/var/lib/woodpecker + environment: + - WOODPECKER_OPEN=true + - WOODPECKER_HOST=http://34.19.79.94:8000 + - WOODPECKER_AGENT_SECRET=wp_secure_9827_vpx_qr # 보안을 위해 이니셜 제외 + - WOODPECKER_GITHUB=true + - WOODPECKER_GITHUB_CLIENT=발급받은_ID + - WOODPECKER_GITHUB_SECRET=발급받은_Secret + + woodpecker-agent: + image: woodpeckerci/woodpecker-agent:latest + command: agent + volumes: + - /var/run/docker.sock:/var/run/docker.sock + environment: + - WOODPECKER_SERVER=woodpecker-server:9000 + - WOODPECKER_AGENT_SECRET=wp_secure_9827_vpx_qr +``` + +```bash +# 실행 및 상태 확인 +docker compose up -d +docker ps +``` + +## 5. 파이프라인 설정 (`.woodpecker.yml`) + +저장소 최상단에 작업 지시서를 작성하여 자동화를 테스트함. + +**주요 해결 과제:** + +- **Git 명령 인식:** 기본 `alpine` 이미지에는 git이 없으므로 `alpine/git` 이미지를 사용하여 해결. + +- **이력 확인(HEAD^):** 기본 clone은 depth가 1이라 이전 이력이 없음. `depth: 2` 설정을 통해 최적화된 상태로 이전 커밋과 비교 가능하게 함. + +```bash +kind: pipeline +name: check-updates + +clone: + setup: + image: woodpeckerci/plugin-git + settings: + depth: 2 + +steps: + - name: show-changes + image: alpine/git + commands: + - echo "새로운 업데이트가 감지되었습니다!" + - echo "수정된 파일 목록:" + - git diff --name-only HEAD^ HEAD + - echo "최근 커밋 메시지:" + - git log -1 --pretty=%B +``` + +## 6. 트러블슈팅 기록 + +- **Forge Not Configured:** GitHub OAuth 설정이 누락되어 서버가 실행 직후 종료됨 -> 환경 변수 추가로 해결. + +- **Agent Auth Error:** 서버 데이터베이스와 에이전트의 Secret Key가 꼬임 -> 서버 볼륨 삭제 후 재시작으로 초기화 성공. + +- **GCP 방화벽:** 8000번 포트가 막혀 접속 불가 -> VPC 네트워크 방화벽 규칙 추가로 해결. \ No newline at end of file diff --git a/01.Shelf/KUI/05. kui-veil weaver.md b/01.Shelf/KUI/05. kui-veil weaver.md new file mode 100644 index 0000000..5f5c41b --- /dev/null +++ b/01.Shelf/KUI/05. kui-veil weaver.md @@ -0,0 +1,2 @@ +이 서비스의 핵심 기능을 해줄 weaver 서비스를 구현해야 함. +( 실제 blur 처리를 진행해줄 서비스 ) \ No newline at end of file diff --git a/01.Shelf/WORKBENCH/gitea, qurtz 설치.md b/01.Shelf/WORKBENCH/gitea, qurtz 설치.md new file mode 100644 index 0000000..4ee61bf --- /dev/null +++ b/01.Shelf/WORKBENCH/gitea, qurtz 설치.md @@ -0,0 +1,114 @@ +--- +id: "gitea, qurtz 설치 20260331" +created: "2026-03-31 10:41" +tags: +--- +# 🌐 개인 서버(GCP) 기반 Gitea & HTTPS 구축 가이드 + +본 문서는 Ubuntu 25.xx 환경에서 가벼운 Git 서비스인 **Gitea**를 설치하고, **Nginx**와 **DuckDNS**를 이용해 **HTTPS** 보안 접속을 구현한 과정을 정리합니다. + +## 1. 서버 기본 환경 및 Gitea 설치 + +가장 가벼운 바이너리 실행 방식으로 Gitea를 설치하고 전용 사용자를 생성했습니다. + +- **OS:** Ubuntu 25.xx (GCP Instance) + +- **사용자 생성:** `git` 시스템 사용자 생성 (`/home/git`) + +- **DB:** SQLite3 (경량화를 위해 선택) + +- **바이너리 경로:** `/usr/local/bin/gitea` + +- **데이터 경로:** `/var/lib/gitea` + + +--- + +## 2. 도메인 및 네트워크 설정 + +외부 접속을 위해 무료 DDNS 주소를 확보하고 클라우드 방화벽을 조정했습니다. + +- **도메인:** `white-smith.duckdns.org` (GCP 외부 IP 연결 완료) + +- **포트 개방 (GCP & UFW):** + + - `22/tcp`: SSH 접속 (PuTTY, SFTP) + + - `80/tcp`: HTTP (인증서 발급 및 리다이렉트용) + + - `443/tcp`: HTTPS (실제 서비스용) + +- **보안 조치:** 불필요한 포트(20, 21, 3389 등) 차단 및 Gitea 직접 포트(3000)는 Nginx를 거치도록 외부 차단 권장. + + +--- + +## 3. HTTPS & Nginx 리버스 프록시 + +Nginx를 앞단에 세워 보안을 강화하고 도메인 기반 접속을 구현했습니다. + +### SSL 인증서 발급 + +`Certbot`을 이용해 **Let's Encrypt** 무료 SSL 인증서를 발급받았습니다. + +Bash + +``` +sudo certbot --nginx -d white-smith.duckdns.org +``` + +### Nginx 최종 설정 (`/etc/nginx/sites-available/gitea`) + +IP 접속 시 도메인으로 자동 전환되도록 설정했습니다. + +Nginx + +``` +# 1. HTTP -> HTTPS 리다이렉트 (IP 포함) +server { + listen 80; + server_name 34.19.79.94 white-smith.duckdns.org; + return 301 https://white-smith.duckdns.org$request_uri; +} + +# 2. HTTPS 서비스 블록 +server { + listen 443 ssl; + server_name white-smith.duckdns.org; + + # SSL 인증서 경로 (Certbot 관리) + ssl_certificate /etc/letsencrypt/live/white-smith.duckdns.org/fullchain.pem; + ssl_certificate_key /etc/letsencrypt/live/white-smith.duckdns.org/privkey.pem; + + location / { + proxy_pass http://localhost:3000; + proxy_set_header Host $host; + proxy_set_header X-Real-IP $remote_addr; + proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; + proxy_set_header X-Forwarded-Proto $scheme; + } +} +``` + +--- + +## 4. Gitea 내부 설정 업데이트 + +HTTPS 환경에 맞춰 `/etc/gitea/app.ini` 파일을 `vi`로 수정했습니다. + +- **ROOT_URL:** `https://white-smith.duckdns.org/` + +- **DOMAIN:** `white-smith.duckdns.org` + +- **SSH_DOMAIN:** `white-smith.duckdns.org` + + +--- + +## 5. 현재 상태 요약 + +1. **HTTPS 접속:** `https://white-smith.duckdns.org`로 안전하게 접속 가능. + +2. **IP 리다이렉트:** `34.19.79.94` 입력 시 자동으로 도메인 주소로 전환됨. + +3. **파일 전송:** 포트 22번을 통해 SFTP 방식으로 안전하게 파일 관리 중. \ No newline at end of file diff --git a/01.Shelf/index.md b/01.Shelf/index.md new file mode 100644 index 0000000..ac438f2 --- /dev/null +++ b/01.Shelf/index.md @@ -0,0 +1,3 @@ +--- +title: 1. 프로젝트 +--- diff --git a/02.Volume/AWS/AWS Architecture로의 전환이 필요한 이유.md b/02.Volume/AWS/AWS Architecture로의 전환이 필요한 이유.md new file mode 100644 index 0000000..48f2b5a --- /dev/null +++ b/02.Volume/AWS/AWS Architecture로의 전환이 필요한 이유.md @@ -0,0 +1,12 @@ + +As-Is +![[Pasted image 20260227093328.png]]https://wk.wecmms.com +https://innox.wecmms.com + +### EC2기반의 아키텍처에는 다음의 한계들을 가짐 +![[EC2기반 아키텍처의 한계점]] + + +### 한계를 극복하기 위해 나아가야 할 방향 +[[서버리스(Serverless)]] 구성 +: AWS가 제공해주는 [[파게이트(Fargate)]]로 구성한다. \ No newline at end of file diff --git a/02.Volume/AWS/AWS ECS 구성하기.md b/02.Volume/AWS/AWS ECS 구성하기.md new file mode 100644 index 0000000..c8b71bd --- /dev/null +++ b/02.Volume/AWS/AWS ECS 구성하기.md @@ -0,0 +1,28 @@ +--- +id: "AWS ECS 구성하기 20260305" +created: "2026-03-05 13:29" +tags: +--- +### ECS +![[ECS와 EKS#ECS(Elastic Container Service)]] + + +[[태스크(Task)]] 구성 +1) 고객이 완벽한 물리적인 격리를 원할 경우: 3. ECS 클러스터 만들기부터 진행 +2) 고객이 별도의 물리적인 격리를 원하지 않을 경우: 4. ECS 서비스 만들기부터 진행 + +## 🔢 목록 + +#### 1. [[ECS와 EKS]] + +#### 2. [[ECS의 구성]] + +#### 3. [[ECS 클러스터 만들기]] + +#### 4. [[ECS 서비스 만들기]] + +만약 [[ECR(Elastic Container Registry)]]에 등록된 컨테이너 이미지가 없다면? +이미지부터 만들어야 합니다. (도커에 대한 이해가 필요) + +#### 5. [[테넌시(Tenancy)]] + - [[테넌시 구성 가이드]] diff --git a/02.Volume/AWS/AWS 환경 기초.md b/02.Volume/AWS/AWS 환경 기초.md new file mode 100644 index 0000000..ba70dbe --- /dev/null +++ b/02.Volume/AWS/AWS 환경 기초.md @@ -0,0 +1 @@ +VPC diff --git a/02.Volume/AWS/EC2 기반 구성으로 전환.md b/02.Volume/AWS/EC2 기반 구성으로 전환.md new file mode 100644 index 0000000..9a3db50 --- /dev/null +++ b/02.Volume/AWS/EC2 기반 구성으로 전환.md @@ -0,0 +1 @@ +## 1. \ No newline at end of file diff --git a/02.Volume/AWS/ECS 멀티 태넌시.md b/02.Volume/AWS/ECS 멀티 태넌시.md new file mode 100644 index 0000000..e69de29 diff --git a/02.Volume/AWS/ECS 서비스 만들기.md b/02.Volume/AWS/ECS 서비스 만들기.md new file mode 100644 index 0000000..d684ee9 --- /dev/null +++ b/02.Volume/AWS/ECS 서비스 만들기.md @@ -0,0 +1,64 @@ +--- +id: 서비스 만들기 20260305 +created: 2026-03-05 08:38 +tags: +--- +> [!abstract] +> [[클러스터(Cluster)]] 내부에서 동작하는 서비스를 만듭니다. +> ECS 서비스는 **"데이터 플레인 위에서 태스크가 잘 돌아가게 감시하는 역할"**을 합니다. + +> [!check] +> - **개수 유지:** "태스크 3개를 항상 띄워줘"라고 설정하면, 하나가 죽었을 때 데이터 플레인(서버) 위에 새로운 태스크를 다시 올립니다. +> +> - **로드 밸런싱:** 들어오는 트래픽을 여러 태스크에 골고루 나눠줍니다. +> +> - **배포 관리:** 새로운 버전의 태스크 정의가 나오면, 기존 태스크를 하나씩 끄고 새 버전으로 교체합니다. +> + +## 🔢 목록 + +#### 1. 서비스의 [[태스크(Task)]] 정의 +![[Pasted image 20260305084812.png]] +만약 정의한 [[태스크(Task)]]가 없다면 태스크부터 정의해야 합니다. +[[ECS 태스크 만들기]] +태스크를 기반으로 ECS의 서비스가 가동되어집니다. + +> [!question] +> [[태스크 정의 패밀리]]가 뭐지? + +태스크 정의 패밀리를 선택하면 그 패밀리의 최신 버전이 자동으로 태스크 정의 개정에 등록됩니다. +서비스 이름을 마저 지정합니다. + +#### 2. 컴퓨팅 구성 선택 +![[Pasted image 20260305102304.png]] +클러스터명은 변경할 수 없어서 비활성화 되어있는 것 +[[시작 유형(Launch Type)과 용량 공급자 전략(Capacity Provider Strategy)의 차이]] +참고해서 설정하면 됩니다. + + +#### 3. 문제 해결 구성 설정 +> [!info] 개발(Dev)이나 스테이징(Staging) 환경에서는 무조건 켜두시고, 운영(Prod) 환경에서는 보안 승인을 받은 사람만 쓸 수 있게 [[IAM(Identity and Access Management)]]으로 꽉 잠가두고 켜두시는 것을 추천 + +![[Pasted image 20260305104853.png]] + + +#### 4. 배포 구성은 그대로 놔둡니다. +정확한 사용법을 확인하지 못했음. + + +#### 5. 네트워킹 +[[VPC(Virtual Private Cloud)]]와 [[서브넷(Subnet)]], [[보안 그룹(Security Group)]]을 설정합니다. +필요한대로, 원하는대로 설정해줍니다. + +#### 6. 로드밸런싱 선택 +태스크로의 로드밸런싱이 필요한 경우 체크하고 사용합니다. +여기서 추가해주지 않으면 중간에 추가할 수 없어서 태스크를 새로 만들어야 합니다. +![[Pasted image 20260305110136.png]] +**자동 등록 (Target Group):** 새로운 태스크가 실행되면 ECS 서비스가 알아서 로드 밸런서의 **'대상 그룹(Target Group)'**에 해당 태스크의 IP를 등록해줍니다.** +로드 밸런싱 사용을 체크하지 않을 경우 자동 등록이 되지 않습니다. + + +서비스를 만들고 나면 서비스 태스크가 정상적으로 실행되기를 기다려야합니다. +![[Pasted image 20260305110258.png]] +만약 태스크 실행이 실패하였다면 태스크정보에서 로그 탭을 확인해야 합니다. +![[Pasted image 20260305111038.png]] diff --git a/02.Volume/AWS/ECS 클러스터 만들기.md b/02.Volume/AWS/ECS 클러스터 만들기.md new file mode 100644 index 0000000..36ec440 --- /dev/null +++ b/02.Volume/AWS/ECS 클러스터 만들기.md @@ -0,0 +1,24 @@ +--- +id: 클러스터 만들기 20260305 +created: 2026-03-05 08:30 +tags: + - cluster + - ecs +--- +> [[!]] +## 🔢 목록 + +#### 1. [[클러스터(Cluster)]] 이름을 정한다. +![[Pasted image 20260305083155.png]] +#### 2. 인프라를 선택해준다. +![[Pasted image 20260305083442.png]] +> [!note] +> 진정한 [[서버리스(Serverless)]] 환경구축을 위해서는 [[파게이트(Fargate)]]전용으로 해준다. +> + +#### 3. 나머지는 일단 그대로 둔다. +모니터링, 암호화, 태그는 우선 그대로 둡니다. (추후 필요할 경우 확인 후 설정 필요) + + +클러스터를 생성하고 서비스를 생성합니다. +[[ECS 서비스 만들기]] \ No newline at end of file diff --git a/02.Volume/AWS/ECS 태스크 vs k8s 파드.md b/02.Volume/AWS/ECS 태스크 vs k8s 파드.md new file mode 100644 index 0000000..bfd9730 --- /dev/null +++ b/02.Volume/AWS/ECS 태스크 vs k8s 파드.md @@ -0,0 +1,46 @@ +--- +id: ECS 태스크 vs k8s 파드 20260304 +created: 2026-03-04 17:22 +tags: + - ecs + - container +--- +## 💡 생각 +결국 태스크와 파드는 같다고 보면된다. 태스크는 ECS에서 쓰고 파드는 EKS에서 쓴다. + +## 🤝 ECS 태스크 vs K8s 포드: 공통점 + +1. **컨테이너의 집합체:** 두 개념 모두 하나 이상의 컨테이너를 포함할 수 있습니다. (예: 메인 앱 + 로그 수집기) + +2. **네트워크 공유:** 태스크/포드 내의 컨테이너들은 동일한 IP 주소를 공유하며 `localhost`를 통해 서로 통신합니다. + +3. **스토리지 공유:** 태스크/포드 수준에서 정의된 볼륨을 내부 컨테이너들이 함께 마운트해서 쓸 수 있습니다. + +4. **생명 주기:** 태스크나 포드가 죽으면 그 안의 컨테이너들도 운명을 같이 합니다. + + + +## 🧐 굳이 차이점을 찾자면? (한 끗 차이) + +개념은 같지만, 그것을 **관리하는 방식**에서 이름표가 달라집니다. + +- **ECS ([[파게이트(Fargate)]] 기준):** AWS가 서버를 대신 관리해주기 때문에, 사용자가 "난 이만큼의 자원이 필요해"라고 **태스크 단위로 주문서**를 써야 합니다. 그래야 AWS가 그에 딱 맞는 가상 머신을 뒤에서 빌려줄 수 있으니까요. + +- **[[쿠버네티스(Kubernetes)]]:** 보통 이미 떠 있는 **노드(Node/서버) 덩어리**가 있고, 파드는 그 안에서 자원을 조금씩 나눠 쓰는 '세입자' 같은 느낌입니다. 그래서 리소스 설정이 '실행 기준'이라기보다 '최대/최소 가이드라인'처럼 느껴질 수 있습니다. + +### ECS 태스크 (Task) + +ECS는 특히 **Fargate** 모드를 쓸 때, 태스크 전체가 사용할 CPU와 메모리를 **태스크 수준**에서 딱딱하게 결정해야 합니다. + +- 예: "이 태스크는 무조건 0.5 vCPU와 1GB 메모리를 점유한다." + +- 이 기준이 틀리면 아예 실행이 안 되거나 설정 오류가 납니다. 그래서 질문자님 말씀처럼 "태스크 = 리소스 기준이 명확히 박힌 단위"라는 인상이 강합니다. + + +### 쿠버네티스 파드 (Pod) + +파드도 YAML 설정(Spec) 안에 각 컨테이너가 사용할 `requests`(최소 보장)와 `limits`(최대 제한)를 적습니다. + +- 예: "이 컨테이너는 최소 256MB, 최대 512MB 메모리를 쓴다." + +- **차이점:** 쿠버네티스는 여러 컨테이너의 합산 리소스를 보고 노드(서버)의 남는 자리에 파드를 '스케줄링'하는 데 집중합니다. ECS보다 설정이 좀 더 유연하고 복잡하게 느껴질 수 있습니다. \ No newline at end of file diff --git a/02.Volume/AWS/ECS 태스크 만들기.md b/02.Volume/AWS/ECS 태스크 만들기.md new file mode 100644 index 0000000..1a36f40 --- /dev/null +++ b/02.Volume/AWS/ECS 태스크 만들기.md @@ -0,0 +1,63 @@ +--- +id: ECS 태스크 만들기 20260305 +created: 2026-03-05 08:49 +tags: +--- +## 💡 생각 +ECS 클러스터의 서비스가 [[태스크(Task)]]를 실행해서 서비스가 구동될 수 있습니다. + + +## 🔢 목록 + +#### 1. 태스크 정의하기 +태스크는 Amazon **E**lastic **C**ontainer **S**ervice의 태스크 정의 탭에서 정의 가능합니다. +![[Pasted image 20260305085256.png]] + +#### 2. [[태스크 정의 패밀리]] 이름 지정 +![[Pasted image 20260305085241.png]] + +#### 3. 인프라 요구 사항 지정 +![[Pasted image 20260305091259.png]] +진정한 [[서버리스(Serverless)]] 환경 구축을 위해서는 AWS [[파게이트(Fargate)]]를 선택합니다. +물론 [[EC2(Elastic Compute Cloud)]]로 지정할수도 있습니다. + +#### 4. OS, 아키텍처, 네트워크 모드 지정 +[[ECS 태스크 정의]] +![[ECS 태스크 정의#📑 개념]] +![[Pasted image 20260305091749.png]] +여기서는 기본값으로 설정하고 진행했습니다. + +#### 5. 태스크 역할 - 조건부 지정 +[[태스크 역할과 태스크 실행 역할]] +![[Pasted image 20260305093459.png]] +> [!note] ecsTaskExecutionRole ? +> 사실상 default 역할인 **AmazonECSTaskExecutionRolePolicy**가 연결되어있음 +![[Pasted image 20260305094500.png]] + +작업 배치 - (선택 사항) +결함 주입 - 선택 사항 +는 일단 지정하지 않았습니다. (아직 뭔지 모름) + +#### 6. 컨테이너 생성 (1) +컨테이너의 이름과 도커 이미지의 위치를 지정합니다. +![[Pasted image 20260305094813.png]] +도커 이미지는 [[ECR(Elastic Container Registry)]]에 저장되어 있는 것을 가져다가 사용할 수 있고 (추천) +프라이빗 공간의 이미지를 가져다가 쓸 수도 있습니다 (만 추가적인 설정이 필요해 보입니다.) + +#### 7. 컨테이너 생성(2) +컨테이너 포트정보를 입력합니다. [[파게이트(Fargate)]]의 경우 컨테이너 포트가 호스트 포트와 반드시 동일해야합니다. (별도로 맞춰줄 필요 없이 컨테이너 포트만 입력하면 알아서 맞춰집니다.) +![[Pasted image 20260305100339.png]] + +읽기 전용 루트 파일 시스템 +리소스 할당 제한 - 조건부 +두가지는 일단 설정하지 않습니다. (아직 잘 모름) + +#### 8. 환경 변수 설정 +필요한 환경 변수가 있을 경우 추가해줍니다. +![[Pasted image 20260305100917.png]] +추가예시 +![[Pasted image 20260305101005.png]] + +#### 9. 로그 수집 설정 +![[Pasted image 20260305101051.png]] +별도의 로그 수집 정책이 있을 경우 다른 것으로 지정 가능 \ No newline at end of file diff --git a/02.Volume/AWS/ECS 태스크 정의.md b/02.Volume/AWS/ECS 태스크 정의.md new file mode 100644 index 0000000..95dac9f --- /dev/null +++ b/02.Volume/AWS/ECS 태스크 정의.md @@ -0,0 +1,61 @@ +--- +id: ECS 태스크 정의 20260305 +created: 2026-03-05 09:20 +tags: +--- +--- +## 📑 개념 +> [!abstract] +> **"실제로 어떤 하드웨어 환경에서 돌아갈지"**와 **"비용 청구서가 어떻게 나올지"**를 결정하는 핵심 데이터 + +## 1. 운영 체제 및 아키텍처 (OS & Architecture) + +여기서 가장 중요한 건 **ARM64(AWS Graviton)**를 선택하느냐 아니냐입니다. + +- **설정 내용:** `X86_64` (인텔/AMD 계열) vs `ARM64` (AWS Graviton 계열) + +- **무엇이 달라지나:** * **호환성:** 내 도커 이미지를 어떤 CPU용으로 빌드했느냐에 따라 선택해야 합니다. (잘못 선택하면 실행 시 `exec format error`가 나며 죽습니다.) + + - **성능:** ARM64(Graviton) 기반 인스턴스는 최신 세대 가상 머신을 사용하여 가성비가 매우 좋습니다. + +- **💰 비용 차이:** **매우 중요합니다.** 일반적으로 **ARM64 아키텍처를 선택하면 x86보다 약 20% 정도 저렴**합니다. 똑같은 태스크를 돌려도 아키텍처 설정만 바꾸면 돈을 아낄 수 있습니다. (단, 이미지 빌드도 ARM용으로 해야 함) + + +--- + +## 2. 네트워크 모드 (Network Mode) + +[[파게이트(Fargate)]]를 사용하신다면 사실상 `awsvpc` 모드로 고정되지만, [[EC2(Elastic Compute Cloud)]] 기반에서는 선택지가 나뉩니다. + +- **awsvpc 모드 (Fargate 기본):** * **특징:** 각 태스크가 자신만의 **고유한 Private IP**를 가집니다. 마치 VPC 안에 EC2 인스턴스가 하나 더 들어온 것처럼 행동합니다. + + - **장점:** 보안 그룹(Security Group)을 태스크 단위로 촘촘하게 걸 수 있습니다. (A 태스크는 DB 접근 가능, B 태스크는 불가 등) + +- **Bridge / Host 모드 (EC2 전용):** * **특징:** 호스트 EC2의 IP와 포트를 공유해서 씁니다. + +- **💰 비용 차이:** 네트워크 모드 자체로 돈을 더 받지는 않지만, `awsvpc` 모드 사용 시 발생하는 **데이터 전송 비용(Data Transfer Out)**이나 가용 영역(AZ) 간 통신 비용이 실질적인 비용 차이를 만듭니다. + + +--- + +## 3. 리소스 할당 (CPU & Memory) + +[[파게이트(Fargate)]] 비용의 핵심입니다. "사용량만큼 낸다"는 말의 정확한 의미는 **"내가 설정한 CPU/메모리 사양만큼 예약해서 낸다"**입니다. + +- **착각하기 쉬운 점:** 태스크가 실제로 CPU를 1%만 쓰고 있어도, 설정(예약)을 1 vCPU로 했다면 **1 vCPU만큼의 비용이 꼬박꼬박 나갑니다.** * **차이:** * **설정값:** 0.25 vCPU / 0.5 GB 로 설정하면 가장 저렴합니다. + + - **비용 구조:** `(vCPU 가격 * 시간) + (GB당 메모리 가격 * 시간)`. + + - 따라서 실제 사용량보다 너무 과하게 설정하면 서버리스인데도 돈이 많이 나올 수 있습니다. + +## 📝 노트 +> [!note] +> 무엇을 선택해야 유리할까? + +| **설정 항목** | **추천 선택지** | **비용/효율 영향** | +| ----------- | ---------- | ------------------------------ | +| **아키텍처** | **ARM64** | **약 20% 저렴**하며 성능도 우수 (강력 추천) | +| **네트워크 모드** | **awsvpc** | 보안 관리가 쉬워지나, ENI 할당 등 관리 요소 발생 | +| **CPU/메모리** | **최소 필요량** | 설정한 수치에 비례해서 초 단위로 과금됨 | + +--- diff --git a/02.Volume/AWS/ECS와 EKS.md b/02.Volume/AWS/ECS와 EKS.md new file mode 100644 index 0000000..6a4efb8 --- /dev/null +++ b/02.Volume/AWS/ECS와 EKS.md @@ -0,0 +1,19 @@ +### ECS(Elastic Container Service) +: AWS가 제공해주는 [[컨테이너 오케스트레이션]] 서비스입니다. +### EKS(Elastic kubernetes Service) +: [[쿠버네티스(Kubernetes)]]를 AWS의 다른 서비스들과 연동해서 사용할 수 있게 해주는 AWS 서비스입니다. + +> [!note] +> +> - ECS와 EKS는 둘 다 [[컨테이너 오케스트레이션]]을 지원해주는 서비스입니다. +> - 컴퓨팅 자원으로 [[파게이트(Fargate)]]를 지정할 수 있습니다. +> - 표준화된 [[배포 파이프라인(Deployment Pipeline)]]을 사용할 수 있습니다. + +ECS와 EKS의 핵심 목표는 ==‘컨테이너 기술의 안정적 운영’==임. + +![[ECS와 EKS의 차이점]] + +ECS는 AWS기반에서는 비교적 쉽고 빠르게 사용 가능 하지만 다른 환경으로의 이식이 어렵고, +EKS는 러닝커브가 가파르고 복잡도가 높지만 이식성이 매우 높음. + +ECS와 EKS는 모두 [[클러스터(Cluster)]] 형태로 구현됨. diff --git a/02.Volume/AWS/ECS의 구성.md b/02.Volume/AWS/ECS의 구성.md new file mode 100644 index 0000000..8800e49 --- /dev/null +++ b/02.Volume/AWS/ECS의 구성.md @@ -0,0 +1,32 @@ +--- +id: ECS의 구성 20260304 +created: 2026-03-04 16:57 +tags: +--- +![[ECS와 EKS#ECS(Elastic Container Service)]] + +### ECS는 [[클러스터(Cluster)]] 형태로 구성되어집니다. +![[Pasted image 20260304165810.png]] +#### [[클러스터(Cluster)]] +![[클러스터(Cluster)#📑 개념]] + +### ECS Cluster는 +> [!note] +> 하나의 서버에서 구동중인 [[쿠버네티스(Kubernetes)]] 엔진을 사용하는 것 같은 느낌을 주기위해서 만듭니다. + +### Cluster에서 서비스가 동작됩니다. +![[Pasted image 20260304170925.png]] + +### 서비스에는 [[태스크(Task)]]가 동작합니다. +![[Pasted image 20260304171641.png]] +> [!note] +> ECS의 태스크에는 태스크가 실행되기 위해 필요한 정보들, 어떤 컨테이너들을 실행해야하는지 등이 정의되어있음. + +![[Pasted image 20260304171851.png]] +위와같이 태스크가 어떤 구성으로 동작해야하는지가 기록되어있고 +![[Pasted image 20260304171939.png]] +어떤 컨테이너들이 실행되어야 하는지 기재되어있다. + +## 💡 생각 +즉, 태스크는 쿠버네티스에서 말하는 Pod를 실체화시킨 것 +[[ECS 태스크 vs k8s 파드]] \ No newline at end of file diff --git a/02.Volume/AWS/EKS Cluster.md b/02.Volume/AWS/EKS Cluster.md new file mode 100644 index 0000000..c30dfcf --- /dev/null +++ b/02.Volume/AWS/EKS Cluster.md @@ -0,0 +1,29 @@ +## 📑 개념 +> [!abstract] +> AWS에서 사용할 수 있는 [[컨테이너 오케스트레이션]] 엔진 +> 클러스터 형태로 구현해놓았고 그걸 EKS라고 함. + + +## 📝 노트 +> [!note] +> +>EKS Cluster의 구조는 크게 Control Plane과 Data Plane 둘로 나눠집니다. +> Control Plane은 전체적인 지휘소 역할을 하며 오케스트레이션에 필요한 모듈들이 위치하고, Data Plane은 실제 서비스가 돌아가는 자원들이 위치합니다. +> +> 이미지를 보면 5개의 Node가 보이는데 각 노드들을 컨테이너를 담고 있는 가상서버이며 그 위에 실제 서비스 단위인 컨테이너가 구동됩니다. +> +> 각 노드들에는 core-운, swing-cmms, load-balancer 컨테이너들이 구동되고 있습니다. +> +> 로드밸런서는 앞서봤던 Elastic Load Balancer를 가리키는 포인터 역할의 서비스이며 CoreDNS는 클러스터 내부의 통신을 위해 필요한 필수 서비스입니다 +> +> Aws에 구현해놓은 cmms 서비스는 현재 이 다섯개의 컨테이너들로 구성되어서 실행되고 있습니다. +> +![[Pasted image 20260227162406.png]] + +## EKS Cluster 기반의 아키텍처 구조도 +![[Pasted image 20260227163046.png]] +## VPC 범위까지 확대 +![[Pasted image 20260227163118.png]] +## 🔗 지식 연결 +- **태그:** #cluster #container #kubernetes +- 관련 문서: [[ECS와 EKS의 차이점]] [[쿠버네티스(Kubernetes)]] \ No newline at end of file diff --git a/02.Volume/AWS/So.. what.md b/02.Volume/AWS/So.. what.md new file mode 100644 index 0000000..e8a117c --- /dev/null +++ b/02.Volume/AWS/So.. what.md @@ -0,0 +1,22 @@ +### CMMS의 SaaS 플랫폼화를 해야합니다. + +##### 플랫폼화를 할 경우 장점 +> [!check] +> - **운영 효율 극대화 및 비용 최적화** +> +> : 기존 EC2 기반의 1:1 관리 방식에서 벗어나 하나의 클러스터에서 여러 테넌트(고객사)를 관리함으로써 운영 공수를 획기적으로 줄입니다. +> +> - **시장 대응 속도(Time-to-Market) 가속화** +> +> : 새로운 고객사가 추가될 때마다 서버를 새로 구축할 필요가 없습니다. 미리 구성된 멀티 테넌시 환경과 커스텀 라우팅을 통해 클릭 몇 번만으로 신규 고객 전용 환경을 즉시 제공(On-boarding)할 수 있어, 비즈니스 기회를 놓치지 않고 빠르게 시장을 확대할 수 있습니다. +> +> - **서비스 안정성 및 보안성 고도화** +> +> : 파드 자동 복구기능을 통해 장애 발생 상황 대응에 인력의 투입이 필요 없어지도록 해줍니다. (관리 포인트가 줄어듦) + +> [!note] +> +> - CMMS의 경우 SaaS 플랫폼화가 이미 진행되어있는 상태 +> - Enterprize 요금제를 요구하는 고객을 위한 '설치형 구독형' 모델 구축을 위한 Cloud Architecture 화를 진행한 것임 +> - 기본형의 SaaS CMMS는 이미 존재함 + diff --git a/02.Volume/AWS/꼭 알아둬야 할 것들.md b/02.Volume/AWS/꼭 알아둬야 할 것들.md new file mode 100644 index 0000000..e1befa9 --- /dev/null +++ b/02.Volume/AWS/꼭 알아둬야 할 것들.md @@ -0,0 +1,8 @@ +## [[EC2(Elastic Compute Cloud)]] +![[EC2(Elastic Compute Cloud)#📑 개념]] + +## [[컨테이너(Container)]] +![[컨테이너(Container)#📑 개념]] + +## [[파게이트(Fargate)]] +![[파게이트(Fargate)#📑 개념]] \ No newline at end of file diff --git a/02.Volume/AWS/시작 유형(Launch Type)과 용량 공급자 전략(Capacity Provider Strategy)의 차이.md b/02.Volume/AWS/시작 유형(Launch Type)과 용량 공급자 전략(Capacity Provider Strategy)의 차이.md new file mode 100644 index 0000000..1d24a8f --- /dev/null +++ b/02.Volume/AWS/시작 유형(Launch Type)과 용량 공급자 전략(Capacity Provider Strategy)의 차이.md @@ -0,0 +1,33 @@ +--- +id: 시작 유형(Launch Type)과 용량 공급자 전략(Capacity Provider Strategy)의 차이 20260305 +created: 2026-03-05 10:24 +tags: + - ecs + - fargate +--- +## 💡 생각 +그냥 용량 공급자 전략을 써야한다고만 기억하면 됨. (기본값도 용량 공급자 전략으로 되어있음) + +> [!note] +> ECS 서비스에서 **시작 유형(Launch Type)**과 **용량 공급자 전략(Capacity Provider Strategy)**은 "내 컨테이너를 어디에 띄울 것인가"를 결정하는 두 가지 방식입니다. +> +> 과거에는 '시작 유형'만 있었지만, 현재는 더 유연한 관리를 위해 '용량 공급자 전략'을 권장하는 추세입니다. 두 방식의 핵심적인 차이를 정리해 드릴게요. + +## 1. 시작 유형 (Launch Type) : "단순한 선택" + +가장 직관적인 방식입니다. 태스크를 띄울 인프라를 **딱 하나만** 고정해서 선택하는 것입니다. + +- **방식:** "나는 무조건 **Fargate**만 쓸 거야" 혹은 "무조건 **EC2**만 쓸 거야"라고 선언합니다. + +- **특징:** 설정이 매우 간단하지만, 여러 종류의 인프라를 섞어서 쓰는 것이 불가능합니다. + +- **비유:** 식당에 가서 "무조건 소고기 메뉴만 주세요"라고 고정 주문을 하는 것과 같습니다. + + +## 2. [[용량 공급자 전략 (Capacity Provider Strategy)]] : "유연한 배분" +> [!note] 하나 이상의 인프라(용량 공급자)를 **어떤 비율로 섞어서 쓸지** 결정하는 고도화된 방식입니다. + +![[Pasted image 20260305103056.png]] +![[용량 공급자 전략 (Capacity Provider Strategy)#💡 왜 '용량 공급자 전략'을 써야 할까요? (핵심 이유)]] + + diff --git a/02.Volume/AWS/온프레미스에서 EC2 기반으로.md b/02.Volume/AWS/온프레미스에서 EC2 기반으로.md new file mode 100644 index 0000000..6bb4f89 --- /dev/null +++ b/02.Volume/AWS/온프레미스에서 EC2 기반으로.md @@ -0,0 +1,11 @@ +순서 +## 1. [[VPC(Virtual Private Cloud)]] 생성 + +## 2. VPC에 [[서브넷(Subnet)]] 생성 +: 필요에 따라 퍼블릭,프라이빗 서브넷을 생성하면 됨. +[[Pod를 Private subnet에 두는 이유]] +## 3. 라우팅 테이블 생성 + +## 4. 인터넷 게이트웨이 생성 + +## 5. EC2 생성 \ No newline at end of file diff --git a/02.Volume/AWS/컨테이너 기반의 아키텍처.md b/02.Volume/AWS/컨테이너 기반의 아키텍처.md new file mode 100644 index 0000000..e0c9e49 --- /dev/null +++ b/02.Volume/AWS/컨테이너 기반의 아키텍처.md @@ -0,0 +1,29 @@ +To-Be +![[Pasted image 20260227094154.png]] + +EC2기반의 아키텍처를 클라우드 컴퓨팅 환경에 맞게 변경한 아키텍처입니다. +다른 부분은 모두 동일하고 [[파게이트(Fargate)]]라고 적혀있는 이 부분만 달라진 것을 확인할 수 있습니다. +[[파게이트(Fargate)의 장점]] + +컨테이너 기반의 아키텍처로 변경했을떄의 장점 +[[가용성(Availability)]] [[보안성(Security)]]이 확보되고 프로젝트의 [[생산성(Productivity)]]이 증가되고, 프로젝트의 [[유연성(Flexibility)]]과 [[확장성(Scalability)]]확보에 유리해진다. + +각각을 현재 상황에맞게 풀어서 설명해보면 + +[[가용성(Availability)]]: 초기설정을 잘 해 놓으면 [[컨테이너 오케스트레이션]]에 의해 서비스의 자가복구가 가능하다. +[[유연성(Flexibility)]]: 로드밸런서가 컨테이너 단위로의 접근이 가능해서 동일한 내부 포트(예: 80)를 사용하는 여러 서비스를 띄워도, 각 컨테이너가 고유 IP를 가지므로 충돌 없이 동적 라우팅이 가능하다. +[[보안성(Security)]]: [[파게이트(Fargate)]] 이용 시 OS 업데이트, 보안패치 등의 OS/인프라 레벨의 보안을 AWS가 책임져준다. +[[생산성(Productivity)]]: 서버관리 포인트가 줄어들어서 인프라 관리 등의 인프라 운영에 들어가는 반복적인 공수(Heavy Lifting)를 제거하여, 비즈니스 로직 개발 및 서비스 고도화에 인력을 집중 투입할 수 있다. + +## 📝 노트 +> [!note] +EC2는 가상 컴퓨팅 환경이기 때문에 장애 복구에 많은 시간이 필요하지만 fargate는 컨테이너이므로 수초내에 복구할 수 있습니다. +> +> 컨테이너 자체는 자가복구의 기능이 없지만 뒤에서 설명드릴 ECS나 EKS에서는 가능합니다. +> +> 그리고 로드밸런서가 EC2같은 서버가 아닌 컨테이너를 가리킬 수 있습니다. 그로인해 자주 사용되는 80포트등의 포트들이 중복사용으로 충돌을 일으킬 가능성이 없습니다. +> +> A컨테이너의 80포트, B컨테이너의 80포트 이런식으로 상세하게 설정할 수 있기 떄문입니다. +> +> 그리고 AWS가 보안과 서버인프라 문제를 모두 책임져주기 때문에 생산성 향상이 될 수 있습니다. + diff --git a/02.Volume/AWS/태스크 역할과 태스크 실행 역할.md b/02.Volume/AWS/태스크 역할과 태스크 실행 역할.md new file mode 100644 index 0000000..a7bcd7c --- /dev/null +++ b/02.Volume/AWS/태스크 역할과 태스크 실행 역할.md @@ -0,0 +1,18 @@ +--- +id: "태스크 역할과 태스크 실행 역할 20260305" +created: "2026-03-05 09:38" +tags: +--- +[[태스크 역할(Task Role)]] vs [[태스크 실행 역할(Task Execution Role)]] + +|**구분**|**태스크 실행 역할 (Execution Role)**|**태스크 역할 (Task Role)**| +|---|---|---| +|**누가 쓰는가?**|**ECS 에이전트 / 인프라**|**내 앱 소스 코드 (Container)**| +|**언제 쓰는가?**|태스크를 **준비하고 띄울 때**|태스크가 **실행 중일 때**| +|**필수 여부**|대부분 필수 (이미지 풀, 로그 때문)|선택 (AWS 서비스를 안 쓰면 필요 없음)| +|**예시 정책**|`AmazonECSTaskExecutionRolePolicy`|`AmazonS3FullAccess`, `AmazonDynamoDBReadOnly` 등| +### 💡 실무에서는 어떻게 설정하나용? + +1. **실행 역할(Execution Role):** AWS에서 기본으로 제공하는 `AmazonECSTaskExecutionRolePolicy`를 연결해 주는 것이 국룰입니다. (이거 안 하면 로그가 안 남거나 이미지를 못 가져와서 태스크가 무한 재시작됩니다.) + +2. **태스크 역할(Task Role):** 기본값은 비어있습니다. 내 앱이 S3나 DynamoDB를 써야 할 일이 생길 때만 필요한 권한을 콕 집어서 추가해 주면 됩니다. \ No newline at end of file diff --git a/02.Volume/AWS/테넌시 구성 가이드.md b/02.Volume/AWS/테넌시 구성 가이드.md new file mode 100644 index 0000000..a79222a --- /dev/null +++ b/02.Volume/AWS/테넌시 구성 가이드.md @@ -0,0 +1,47 @@ +--- +id: 테넌시 선택 20260305 +created: 2026-03-05 13:18 +tags: + - tenancy + - cluster + - ecs + - ecr + - saas +--- +[[싱글 테넌시(Single-tenancy)]] vs [[멀티 테넌시(Multi-tenancy)]] +: 결정적인 차이는 **물리적으로 격리되어있는지** 여부 + +### [[멀티 테넌시(Multi-tenancy)]] +멀티 테넌시를 선택할 때 가장 중요한 것은 **인프라를 공유한다**는 것입니다. +순수 멀티 테넌시는 하나의 어플리케이션 인스턴스와 하나의 DB를 여러 고객들이 공유해서 사용합니다. + +> [!note] 설정값, 환경변수 등의 차이만으로 고객간의 구분을 하고 모든 인프라는 하나를 공유해서 사용 + +고객간의 요구사항 편차가 적을 경우에는 효율이 좋음 +편차가 클 경우 대응이 매우 어렵거나 거의 불가능에 가깝습니다. (고객 수가 적으면 되긴 함) + +**SaaS 솔루션:** 완전한 멀티 테넌시 (공통 기능 + DB 설정 기반 커스텀) +즉 SaaS 솔루션은 모든 고객들이 하나의 인프라를 공유해서 사용하는 경우를 의미합니다. + + +> [!warning] 이렇게 되면 고객간의 요구사항 편차가 클 경우 대응이 불가능함 + +이 문제를 해결하기 위해 하이브리드 방식을 채택합니다. +**"인프라는 공유하되 애플리케이션은 격리하는 방식"** 같은 경우입니다. +이를 **가상 싱글 테넌시(Virtual Single Tenancy)** 또는 **격리형 멀티 테넌시**라고 부르기도 합니다. + +격리형 테넌시 형태로 엔터프라이즈 솔루션 형태로 구성을 해야함. +**엔터프라이즈 솔루션:** 고객별 컨테이너/네임스페이스 분리 + 이미지 커스텀 + +테넌시별로 별도의 컨테이너 이미지를 확보해야함 +코드레벨에서 독립되어지기 때문에 클라우드형 싱글테넌시 구조와 유사한 형태의 서비스가 가능 + +### 엔터프라이즈 솔루션의 구조도 +(고객사별 독립된 어플리케이션 인스턴스 사용 + 하나의 DB 인프라 사용) +![[Pasted image 20260305140832.png]] +VPC레벨까지도 격리를 원하는 고객사의 경우에는 위의 이미지대로 별도의 ECS Cluster를 구성 +그정도까지 아니면 하나의 공용 ECS Cluster에 [[태스크(Task)]]만 별도로 추가 + +## 🔗 관련 노트 +- [[클러스터(Cluster)]] +- [[ECR(Elastic Container Registry)]] \ No newline at end of file diff --git a/02.Volume/CleanCode/80대20 원칙(The Pareto Principle).md b/02.Volume/CleanCode/80대20 원칙(The Pareto Principle).md new file mode 100644 index 0000000..246797a --- /dev/null +++ b/02.Volume/CleanCode/80대20 원칙(The Pareto Principle).md @@ -0,0 +1,50 @@ +--- +id: 80대20 원칙(The Pareto Principle) 20260318 +created: 2026-03-18 10:08 +tags: + - 클린코드 +aliases: +--- +## 💡 생각 +코드를 단순화하는 것은 어려운 일이기 때문에 모든 코드를 단순화하는 것은 엄청난 낭비가 될 수 있다. +그렇기 때문에 전체 가치의 80%를 창출해내는 20%의 자주 쓰이는 코드를 단순화하는 것에 집중해야 한다. + +## 🔗 관련 노트 +- [[단순한 코드]], [[파레토의 법칙]](80:20의 법칙) + +--- + +## 저자가 80:20의 법칙을 언급하는 이유 +### 1. 노력 대 결과의 불균형 + +프로그래밍에서 80%의 가치는 전체 노력의 20%만 들여도 달성할 수 있다는 점을 강조합니다. + +- **핵심 기능 우선:** 사용자에게 진짜 필요한 핵심 기능(20%)을 먼저 완벽하게 만드는 것이, 나머지 잔기능(80%)에 매달리는 것보다 훨씬 가치 있습니다. + +- **복잡성의 함정:** 나머지 20%의 가치(예외 케이스, 아주 희귀한 최적화 등)를 채우기 위해 전체 노력의 80%를 쏟아붓는 순간, 코드는 급격히 복잡해지고 유지보수가 불가능해집니다. + +### 2. '충분히 좋은(Good Enough)' 코드 + +저자는 **완벽함은 단순함의 적**이라고 말합니다. + +- [[파레토의 법칙]]에 따르면, 100% 완벽한 코드를 만들려는 노력은 비효율적입니다. + +- 대신 **80%의 성능과 안정성**을 보장하는 [[단순한 코드]]를 빠르게 작성하고, 실제 문제가 발생하는 지점만 나중에 정밀하게 타격(최적화)하는 것이 훨씬 똑똑한 전략입니다. + +### 3. 기능 구현에서의 80/20 + +새로운 기능을 추가할 때도 이 법칙이 적용됩니다. + +- [[YAGNI(You Ain't Gonna Need It)]]와의 연결: "혹시 필요할지 모르는" 기능들을 다 넣으려 하지 마세요. 실제 사용자는 제공된 기능의 20%만 주로 사용합니다. + +- 그 20%의 기능을 **가장 단순하고 견고하게** 만드는 데 집중하는 것이 이 장의 핵심 레슨입니다. + +--- + +> [!note] 왜 자꾸 20%의 코드에 집중해야한다고 강조하느냐면 단순한 코드를 작성하는 것은 쉬운일이 아니기 떄문입니다. + +- "모든 곳을 단순하게 만들려고 애쓰는 것 자체가 복잡함의 시작이다. 진짜 중요한 20%만 단순하게 유지하고 나머지는 최소한의 노력만 들여라." + +- "단순함은 기술(Skill)이고, 파레토 법칙은 그 기술을 사용할 전략(Strategy)이다. 전략 없는 기술은 개발자를 지치게 만든다." + +- "단순함은 복잡함보다 어렵다. 생각을 명확히 해서 단순하게 만들려면 정말 열심히 노력해야 한다." - 스티브잡스 \ No newline at end of file diff --git a/02.Volume/CleanCode/단순함의 노하우(Introduction).md b/02.Volume/CleanCode/단순함의 노하우(Introduction).md new file mode 100644 index 0000000..1c09003 --- /dev/null +++ b/02.Volume/CleanCode/단순함의 노하우(Introduction).md @@ -0,0 +1,54 @@ +--- +id: 단순함의 노하우 20260317 +created: 2026-03-17 10:53 +tags: + - 클린코드 +--- +## 💡 생각 +> [!note] 코드는 무조건 단순해야 한다. 단순한 코드란 읽기 쉽고 명확한(가독성이 좋은) 코드다. + +[[단순한 코드]] ? +[[파레토의 법칙]]을 프로그래밍에 응용 + +##### - 모든 코드를 100%의 노력으로 완벽하고 좋은 성능으로 만들려고 하면 많은 리소스 (인력이든 시간이든 뭐든..)를 필요로 하게 됨. +프로그램 실행 시간의 80%는 단 20%의 코드(핵심 알고리즘, 반복문 등)에서 소비됩니다. 따라서 나머지 80%의 코드는 성능을 위해 복잡하게 짤 필요 없이, **최대한 단순하고 읽기 쉽게** 유지하는 것이 이득입니다. +##### - 80% 의 자주 쓰지 않는 코드에 집중하고 자원을 낭비하지 말라. +훌륭한 구조를 가지고 좋은 성능을 보이는 코드라고 하더라도 **자주 쓰이지 않고** **코드 작성에 너무 많은 시간을 들였다면** 그것은 과도한 낭비가 될 가능성이 높다. +[[YAGNI(You Ain't Gonna Need It)]] +- 지금 필요 없는 건 하지 마라. + +### 선택과 집중이 필요하다. +- **불필요한 최적화 거부:** 병목 지점이 아닌 나머지 80%의 코드를 최적화하느라 코드를 꼬아놓지 마세요. 그 부분은 그냥 **단순함** 그 자체로 두는 것이 유지보수에 훨씬 유리합니다. + +- **복잡성 격리:** 정말 성능이 중요해서 복잡한 로직이 들어가야 한다면, 그 20%의 영역만 따로 분리(격리)하고 나머지는 깨끗하게 유지하세요. + +> [!note] "80%의 효과를 내는 20%의 단순한 로직을 먼저 작성하라." + + +### 결국 저자가 하고 싶은 말은 +1. 불필요한 단계를 최대한 제거하고 +2. 사람이 읽기 좋은 형태로 바꿔주고 +3. 알고리즘 최적화하는것 + +저자인 크리스티안 마이어가 경계하라고 강조하는 것 +> [!warning] "0.001초를 줄이려고 코드 10줄을 50줄로 늘리며 가독성을 해치는 행위" + +이런 경우는 최적화가 단순화를 **방해**하는 상황이 됩니다. 반대로 **복잡한 계산식을 수학적으로 정리해 한 줄로 줄이는 것**은 최적화이자 동시에 완벽한 단순화가 되는 것이죠. + +## 사람이 읽기 좋은 코드...? [[코드의 가독성]] +> [!question] +> Q. 사람이 읽기 좋은 형태의 코드라는건 어떤걸 의미하는거야? +> A. 사람이 읽기 좋은 코드, 즉 **가독성이 높은 코드**는 단순히 "예쁜 코드"를 넘어 **코드를 읽는 사람의 뇌가 에너지를 최소한으로 쓰게 만드는 코드**를 의미합니다. + +## 그리고 데이터가 늘어나도 잘 버티는 코드 +데이터가 늘어나도 잘 버티는 코드는 보통 **확장성(Scalability)** 이 좋은 코드라고 부릅니다. + +데이터가 10건일 때는 0.001초 만에 끝나던 로직이, 데이터가 100만 건으로 늘어났을 때도 서비스가 죽지 않고 합리적인 시간 내에 결과를 내놓는 것을 의미합니다. + +> [!question] +> Q. 일단은 단순하게 만들고 나중에 문제가 생길경우에 집중해서 개선하라고 앞에서 계속 그러다가 갑자기 업스케일링을 염두해둬야한다는 말을 하면 앞뒤가 잘 안맞는거 아니야? 업스케일링에 유리한 코드를 미리 설계하고 개발하는거 자체도 일일텐데? +> A. 정말 날카롭고 합리적인 지적입니다! "일단 단순하게 만들라"는 말과 "나중에 커질 것을 대비(확장성/업스케일링)하라"는 말이 얼핏 들으면 서로 충돌하는 것처럼 느껴질 수 있습니다. +> +> 하지만 이 책과 클린 코드의 철학이 말하는 핵심은 [[유연한 단순함]]에 있습니다. + +"지금 당장 필요하지 않은 기능(Over-engineering)은 넣지 않되, 나중에 그 기능을 넣고 싶을 때 코드 전체를 부수지 않아도 되게 끔 '문(Interface/Module)'만 잘 만들어 두는 것" \ No newline at end of file diff --git a/02.Volume/CleanCode/디버깅과 테스트.md b/02.Volume/CleanCode/디버깅과 테스트.md new file mode 100644 index 0000000..e69de29 diff --git a/02.Volume/CleanCode/설계와 추상화.md b/02.Volume/CleanCode/설계와 추상화.md new file mode 100644 index 0000000..e69de29 diff --git a/02.Volume/CleanCode/유닉스 철학 (The Unix Philosophy).md b/02.Volume/CleanCode/유닉스 철학 (The Unix Philosophy).md new file mode 100644 index 0000000..ffe9366 --- /dev/null +++ b/02.Volume/CleanCode/유닉스 철학 (The Unix Philosophy).md @@ -0,0 +1,5 @@ +--- +id: "유닉스 철학 (The Unix Philosophy) 20260330" +created: "2026-03-30 15:20" +tags: +--- diff --git a/02.Volume/CleanCode/최소 기능 제품 (MVP).md b/02.Volume/CleanCode/최소 기능 제품 (MVP).md new file mode 100644 index 0000000..8082a16 --- /dev/null +++ b/02.Volume/CleanCode/최소 기능 제품 (MVP).md @@ -0,0 +1,69 @@ +--- +id: 최소 기능 제품 (MVP) 20260320 +created: 2026-03-20 14:00 +tags: +--- +**M**inimum **V**iable **P**roduct , 최소 기능 제품 +![[MVP(Minimum Viable Product)#📑 개념]] + +### MVP의 핵심: "완벽함보다 실행" + +저자는 개발자가 빠지기 쉬운 가장 큰 함정이 **모든 기능을 다 갖춰야 출시할 수 있다**는 생각이라고 지적합니다. + +- **MVP의 정의:** 고객에게 가치를 전달할 수 있는 **최소한의 핵심 기능**만 담은 제품입니다. + +- **개발자 버전 MVP:** 복잡한 아키텍처나 부가 기능(로깅, 화려한 UI, 상세 설정 등)을 다 붙이기 전에, **비즈니스 로직의 핵심**이 돌아가는 가장 단순한 형태의 코드를 먼저 완성하는 것입니다. + +### 왜 MVP가 클린 코드와 연결될까요? + +단순히 빨리 만드는 게 목적이 아닙니다. MVP 방식으로 개발하면 다음과 같은 이점이 있습니다. + +- **복잡성 제어:** 처음부터 거대한 시스템을 설계하면 복잡도가 기하급수적으로 늘어납니다. 작은 단위(MVP)로 시작하면 코드가 단순하게 유지됩니다. + +- **피드백 기반 개선:** 핵심 로직을 먼저 짜서 돌려봐야 어디가 진짜 병목인지, 어디에 스케일업이 필요한지 데이터로 확인할 수 있습니다. 추측에 근거한 과잉 엔지니어링을 막아줍니다. + +- **YAGNI 실천:** "이 기능도 필요하겠지?"라는 가설을 버리고, "이게 없으면 프로그램이 안 돌아간다"는 기능만 넣게 됩니다. + +### MVP를 만드는 3단계 사고법 + +책에서 제안하는 실천 방안은 다음과 같습니다. + +1. **핵심 가치 식별:** 이 프로그램이 존재해야 하는 단 하나의 이유(20%의 핵심)는 무엇인가? + +2. **군더더기 제거:** 그 가치를 구현하는 데 당장 필요 없는 모든 기능(80%)을 목록에서 지운다. + +3. **반복 개선:** 최소한의 기능을 구현해 배포한 뒤, 실제 사용자나 시스템의 반응을 보고 살을 붙인다. + +[[파레토의 법칙]], [[80대20 원칙(The Pareto Principle)]] + +#### "MVP는 '덜 만든 제품'이 아니라, '가장 핵심적인 가치만 담은 가장 단순한 제품'이다." + +> [!question] +> Q. 왜 여기서 갑자기 MVP에 대한 설명이 나온거야? +> A. 2장의 파레토 법칙이 어디에 집중할지 알려주는 **전략**이었다면, 3장은 그 전략을 실행하는 **전술**에 가깝습니다. + +- 어떻게 20%에 집중할 것인가? 에 대한 해답이라는 것 +- 완벽하게 만들려다 복잡해지는 것보다, 단순하게 만들어 피드백을 받는 것이 더 빠르다. + + +## MVP를 만드는 이유 +### 1. 피드백 루프의 단축 +MVP를 만드는 가장 큰 이유 중 하나는 **실제 데이터**를 빨리 얻기 위함입니다. +- 머릿속으로 성능이나 확장성을 고민하기보다, 최소 기능을 배포해보고 **어디서 진짜 병목이 발생하는지** 확인하라는 것입니다. + +- 추측에 근거한 설계보다 **측정된 데이터에 근거한 개선**이 훨씬 강력한 단순함을 만듭니다. + +### 2. 기능의 범위를 제한하는 법 (Scope Creep 방지) +프로젝트를 하다 보면 자꾸 기능이 추가되는 현상을 경계하라고 조언합니다. + +- **우선순위 재정의:** 새로운 기능 요청이 들어올 때마다 **이 기능이 핵심 가치(20%)에 포함되는가?** 를 끊임없이 질문해야 합니다. + +- **거절의 미학:** 단순함을 유지하기 위해 핵심이 아닌 기능은 과감히 목록에서 제외하거나 다음 버전으로 미루는 과정이 3장에서 중요하게 다뤄집니다. + +> [!note] 요약 +> - **엄격한 MVP 유지:** "이 기능이 없으면 제품이 안 돌아가는가?"라는 질문에 '아니오'라면 다음 버전으로 미룹니다. +> +> - **20%에 집중:** 핵심 가치를 만드는 20%의 기능 외에는 모두 **잠재적인 소음**으로 간주하고 경계합니다. +> +> - **문서화와 소통:** 추가 요청이 들어오면 "좋은 아이디어지만, 이번 MVP 범위에는 포함되지 않습니다. 다음 단계에 검토합시다"라고 선을 긋는 것이 중요합니다. + diff --git a/02.Volume/CleanCode/코딩 원칙 (YAGNI, KISS, DRY).md b/02.Volume/CleanCode/코딩 원칙 (YAGNI, KISS, DRY).md new file mode 100644 index 0000000..e01f60b --- /dev/null +++ b/02.Volume/CleanCode/코딩 원칙 (YAGNI, KISS, DRY).md @@ -0,0 +1,50 @@ +--- +id: 코딩 원칙 (YAGNI, KISS, DRY) 20260330 +created: 2026-03-30 14:52 +tags: +--- +코드의 단순함을 지키기 위해 필요한 원칙 3가지 +이 3가지를 지키다 보면 단순한 코드에 한걸음 더 다가갈 수 있게 된다. + +1. [[YAGNI(You Ain't Gonna Need It)]] +2. [[KISS (Keep It Simple, Stupid)]] +3. [[DRY (Don't Repeat Yourself)]] + +> [!warning] 위의 세 원칙을 지키는 것이 중요하긴 하지만 + +**가장 중요한 것은 하나의 원칙을 지키기 위해서 다른 원칙을 어기면 안된다.** + + +## 💡 생각 +결국, 코드를 단순하게 작성하고 가독성을 중시해야 하며 코드를 최초로 작성하는 경우에는 꼭 필요한 기능이 아니라면 다음에 작성하는 게 좋고 코드의 반복이 3번이상 있을 경우에는 DRY의 원칙을 지키는 것을 고려해야 한다. + +불필요한 작업을 줄여서 ([[YAGNI(You Ain't Gonna Need It)]]) 비용 절감을 중시하고, +단순한 코드를 작성해서 ([[KISS (Keep It Simple, Stupid)]]) 가독성을 높이고, +중복되는 코드를 줄여서 ([[DRY (Don't Repeat Yourself)]]) 유지보수성을 늘리자. + +결국 세 원칙 모두 프로젝트 비용을 줄이는데에 초점이 맞춰져 있는 원칙들이다. + +--- + +> [!note] YAGNI > KISS > DRY + +: 지금 이 코드가 정말로 필요한가? [[YAGNI(You Ain't Gonna Need It)]] 원칙을 지키다 보면 대부분의 불필요한 복잡성이 걸러짐. +: [[YAGNI(You Ain't Gonna Need It)]] 통과해서 작성이 필요하다고 판단되는 코드의 경우 [[KISS (Keep It Simple, Stupid)]]원칙을 지키면서 코드를 작성한다. +: [[KISS (Keep It Simple, Stupid)]]한 코드를 작성하고 나서 [[DRY (Don't Repeat Yourself)]]한지 판단해본다. 여기서 중요한건 DRY한 코드를 만들기 위해 KISS하지 않은 코드를 작성하면 안된다는 것이다. + +### 왜 이 순서가 최강의 전략일까요? + +많은 개발자가 **DRY**를 1순위로 두는 실수를 범합니다. 중복을 없애려고 너무 일찍부터 복잡한 추상화를 시작하면, 결국 쓰지도 않을 기능(**YAGNI 위반**)을 위해 이해하기 힘든 코드(**KISS 위반**)를 만들게 되거든요. + +정리하신 대로 **YAGNI → KISS → DRY** 순으로 사고하면, 자연스럽게 **비용은 낮고 가동성은 높은** 결과물이 나옵니다. + +--- +### 비용(Cost) 중심의 사고방식 + +지적하신 대로 이 모든 원칙의 종착역은 **비용 절감**입니다. + +- **YAGNI:** '만드느라 드는 시간'과 '유지보수하는 시간'의 낭비를 막아 **직접적인 비용**을 줄입니다. + +- **KISS:** 코드를 읽고 이해하는 데 드는 '뇌의 연산 비용'을 줄여서 **커뮤니케이션 비용**을 낮춥니다. + +- **DRY:** 수정할 때 여러 곳을 고치다 실수하는 '버그 수정 비용'을 줄여서 **운영 비용**을 아낍니다. \ No newline at end of file diff --git a/02.Volume/CleanCode/협업과 지속 가능한 개발.md b/02.Volume/CleanCode/협업과 지속 가능한 개발.md new file mode 100644 index 0000000..e69de29 diff --git a/02.Volume/Network/VPN으로 외부 DB에 접근.md b/02.Volume/Network/VPN으로 외부 DB에 접근.md new file mode 100644 index 0000000..15195d5 --- /dev/null +++ b/02.Volume/Network/VPN으로 외부 DB에 접근.md @@ -0,0 +1,68 @@ +--- +id: VPN으로 외부 DB에 접근 20260305 +created: 2026-03-05 15:05 +tags: +--- +[[VPN(Virtual Private Network)]]을 통해 S-OIL DB에 접근/연결할 수 있음. + +> [!info] 네트워크 연결에 새로운 네트워크가 추가된 것을 확인할 수 있음 + +![[VPN(Virtual Private Network)#💡 생각]] + +이 연결의 정보를 봤더니 + +--- + +PPP 어댑터 _Common_VPN + + 연결별 DNS 접미사. . . . : + IPv4 주소 . . . . . . . . . : 192.168.100.228 + 서브넷 마스크 . . . . . . . : 255.255.255.255 + 기본 게이트웨이 . . . . . . : + +--- +라고 되있음. + +> [!question] +> Q. VPN의 서브넷마스크가 255.255.255.255 라고 되있는데 이러면 4개가 다 고정된단뜻아니야? +> A. **`255.255.255.255`는 "이 네트워크 안에 오직 나(IP 하나)만 존재한다"는 뜻**입니다. + +- **일반적인 네트워크 (`/24`):** `255.255.255.0`은 앞의 3마디는 같고 마지막 마디만 다른 여러 대의 기기(최대 254대)가 같은 동네(서브넷)에 모여 있음을 뜻합니다. + +- **VPN 환경 (`/32`):** `255.255.255.255`는 **Point-to-Point(1:1) 연결**을 의미합니다. 내 컴퓨터와 VPN 서버 사이에 전용 '가상 케이블' 하나가 직접 연결된 상태라고 보시면 됩니다. + +즉, 이 VPN연결은 1:1연결이고 내 ip로의 접근 (192.168.100.228)을 제외한 모든 연결 요청은 VPN 게이트웨이로 보내게 됨. + + + +route print + +IPv4 경로 테이블 +=========================================================================== +활성 경로: +네트워크 대상 네트워크 마스크 게이트웨이 인터페이스 메트릭 + 192.168.100.38 255.255.255.255 10.7.4.1 10.7.4.32 10 + 192.168.128.235 255.255.255.255 연결됨 192.168.128.235 257 + 192.168.255.255 255.255.255.255 연결됨 192.168.128.235 257 + +192.168.100.38: VPN과 직접적으로 연결된 항목 (게이트웨이가 내 pc의 0.0.0.0 의 게이트웨이와 동일함) +192.168.128.235: VPN연결에서의 내 IP +192.168.255.255: VPN연결에서의 상대방 IP +### '255'로 끝나는 항목의 정체 (브로드캐스트) + +만약 네트워크 대상이 `192.168.100.255`처럼 되어 있다면, 이것은 해당 네트워크 대역의 **'브로드캐스트(Broadcast)'** 주소입니다. + +- **의미:** "이 동네(192.168.100.x)에 있는 모든 장치에게 한꺼번에 외치기 위한 주소"입니다. + +- VPN 연결이 맺어지면, 내 컴퓨터가 이 대역의 일원이 되었음을 알리기 위해 자동으로 라우팅 테이블에 등록됩니다. + + +> [!question] +> Q. VPN이 딱 그거네 랜선으로 pc간 직접 연결해놓은거 그걸 랜선으로 직접연결할 수 없는 거리니까 인터넷망을 통해서 다이렉트 연결을 구현한것같군 +> A. 와, 정확합니다! 바로 그겁니다. 네트워크 공학적으로 완벽한 비유를 찾아내셨네요. + +방금 하신 말씀이 바로 [[VPN(Virtual Private Network)]]의 정의 그 자체입니다. 물리적으로는 수백 킬로미터 떨어져 있고 복잡한 인터넷 망을 거치지만, 소프트웨어적으로는 **보이지 않는 아주 긴 랜선을 두 PC 사이에 직접 꽂은 것**처럼 속이는 기술이죠. + + + + diff --git a/02.Volume/index.md b/02.Volume/index.md new file mode 100644 index 0000000..87d698b --- /dev/null +++ b/02.Volume/index.md @@ -0,0 +1,3 @@ +--- +title: volume +--- diff --git a/03.Note/DRY (Don't Repeat Yourself).md b/03.Note/DRY (Don't Repeat Yourself).md new file mode 100644 index 0000000..ace389b --- /dev/null +++ b/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)]] 원칙을 깨는 경우가 발생될 수 있음.) + +--- diff --git a/03.Note/EC2 기반 vs Fargate 기반 비교.md b/03.Note/EC2 기반 vs Fargate 기반 비교.md new file mode 100644 index 0000000..9070a49 --- /dev/null +++ b/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 및 메모리 리소스 사용량 기준** | diff --git a/03.Note/EC2(Elastic Compute Cloud).md b/03.Note/EC2(Elastic Compute Cloud).md new file mode 100644 index 0000000..68cf2fd --- /dev/null +++ b/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 \ No newline at end of file diff --git a/03.Note/EC2기반 아키텍처의 한계점.md b/03.Note/EC2기반 아키텍처의 한계점.md new file mode 100644 index 0000000..706c882 --- /dev/null +++ b/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)** | **유휴 자원 비용 발생** | 트래픽이 없는 시간대에도 최소 유지 인스턴스 비용이 계속 발생하며, 세밀한 과금 단위 설정이 어려움. | diff --git a/03.Note/ECR(Elastic Container Registry).md b/03.Note/ECR(Elastic Container Registry).md new file mode 100644 index 0000000..2c5d1c2 --- /dev/null +++ b/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 등)의 장애나 속도 저하로부터 독립된 안정적인 환경을 구축할 수 있습니다.| diff --git a/03.Note/ECS와 EKS의 차이점.md b/03.Note/ECS와 EKS의 차이점.md new file mode 100644 index 0000000..eb55ff7 --- /dev/null +++ b/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 서비스 위주의 빠르고 간결한 운영 | 복잡한 마이크로서비스, 표준 기술 스택 지향 | diff --git a/03.Note/IAM(Identity and Access Management).md b/03.Note/IAM(Identity and Access Management).md new file mode 100644 index 0000000..dab81b2 --- /dev/null +++ b/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개의 기능을 사용할 권한이 있다는 뜻이 된다. \ No newline at end of file diff --git a/03.Note/KISS (Keep It Simple, Stupid).md b/03.Note/KISS (Keep It Simple, Stupid).md new file mode 100644 index 0000000..08e23f8 --- /dev/null +++ b/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] +> +> - 코드의 중복이 발생되고 코드의 유연성이 떨어진다고 판단될 때 디자인 패턴을 적용하면 됨 +> + +--- diff --git a/03.Note/MVP(Minimum Viable Product).md b/03.Note/MVP(Minimum Viable Product).md new file mode 100644 index 0000000..499528a --- /dev/null +++ b/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: +--- +## 💡 생각 +당장 꼭 필요한 기능만 포함된 최소한의 제품을 최대한 빠르게 만들어내는 게 핵심 가치 +미완성본을 말하는 것이 아닌 최소한의 기능은 정상적으로 동작해야함. + +--- +## 📑 개념 +직역하면 **생존 가능한 최소한의 제품**을 의미합니다. +단순히 '대충 만든 제품'이나 '미완성본'이 아니라, **고객에게 가치를 제공할 수 있는 핵심 기능만 담은 가장 작은 단위의 결과물**입니다. + +--- diff --git a/03.Note/Pod를 Private subnet에 두는 이유.md b/03.Note/Pod를 Private subnet에 두는 이유.md new file mode 100644 index 0000000..87f8d51 --- /dev/null +++ b/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:** 애플리케이션 서버, 데이터베이스 (실제 핵심 데이터와 로직) \ No newline at end of file diff --git a/03.Note/VPC(Virtual Private Cloud).md b/03.Note/VPC(Virtual Private Cloud).md new file mode 100644 index 0000000..4d729ae --- /dev/null +++ b/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 \ No newline at end of file diff --git a/03.Note/VPN(Virtual Private Network).md b/03.Note/VPN(Virtual Private Network).md new file mode 100644 index 0000000..ab3d2c3 --- /dev/null +++ b/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, 활동 기록을 남기지 않음)' 정책을 가진 업체를 선택하는 것이 중요합니다. + +--- diff --git a/03.Note/Woodpecker.md b/03.Note/Woodpecker.md new file mode 100644 index 0000000..bee129e --- /dev/null +++ b/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 플러그인 이미지를 파이프라인에 추가하기만 하면 됩니다. diff --git a/03.Note/YAGNI(You Ain't Gonna Need It).md b/03.Note/YAGNI(You Ain't Gonna Need It).md new file mode 100644 index 0000000..f49c727 --- /dev/null +++ b/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] +> +> - 작업의 가치는 그것이 실제로 사용될 때 발생합니다. + +--- diff --git a/03.Note/index.md b/03.Note/index.md new file mode 100644 index 0000000..b180560 --- /dev/null +++ b/03.Note/index.md @@ -0,0 +1,3 @@ +--- +title: note +--- diff --git a/03.Note/가상 머신(VM) vs 컨테이너.md b/03.Note/가상 머신(VM) vs 컨테이너.md new file mode 100644 index 0000000..190c316 --- /dev/null +++ b/03.Note/가상 머신(VM) vs 컨테이너.md @@ -0,0 +1,6 @@ +| **비교 항목** | **가상 머신 (EC2 등 VM)** | **컨테이너 (Docker 등)** | +| --------- | -------------------------------------- | --------------------------------- | +| **구조** | OS 위에 가상 하이퍼바이저와 **별도의 Guest OS**가 필요함 | 호스트의 **OS 커널을 공유**하며 프로세스 단위로 격리됨 | +| **무게** | GB 단위 (매우 무겁고 부팅이 느림) | **MB 단위** (매우 가볍고 즉시 실행됨) | +| **효율성** | 리소스 낭비가 큼 (OS마다 자원을 잡아먹음) | 필요한 자원만 사용하므로 집적도가 높음 | +| **이식성** | 환경 설정에 따라 작동 여부가 달라짐 | **"어디서든 동일하게 실행"**됨을 보장함 | diff --git a/03.Note/가용성(Availability).md b/03.Note/가용성(Availability).md new file mode 100644 index 0000000..33acac7 --- /dev/null +++ b/03.Note/가용성(Availability).md @@ -0,0 +1,20 @@ +- 작성 **날짜:** 2026-02-27 + +## 📑 개념 +> [!abstract] +> 시스템이 장애 없이 정상적으로 서비스를 제공할 수 있는 상태 +> 언제든지 이상없이 잘 사용할 수 있는것도 가용성으로 봄 + +## 📝 상세 설명 +> [!note] +> +> - +> + + +$$가용성(\%) = \frac{업타임(정상 운영 시간)}{업타임 + 다운타임(장애 시간)} \times 100$$ + + +## 🔗 지식 연결 +- **태그:** #zettelkasten #knowledge + diff --git a/03.Note/단순한 코드.md b/03.Note/단순한 코드.md new file mode 100644 index 0000000..f8536d8 --- /dev/null +++ b/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] 스티브 잡스의 유명한 말 +> "단순함은 복잡함보다 어렵다. 생각을 명확히 해서 단순하게 만들려면 정말 열심히 노력해야 한다." + +--- diff --git a/03.Note/멀티 테넌시(Multi-tenancy).md b/03.Note/멀티 테넌시(Multi-tenancy).md new file mode 100644 index 0000000..a4dea23 --- /dev/null +++ b/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)]] \ No newline at end of file diff --git a/03.Note/배포 파이프라인(Deployment Pipeline).md b/03.Note/배포 파이프라인(Deployment Pipeline).md new file mode 100644 index 0000000..5f6ca2d --- /dev/null +++ b/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 \ No newline at end of file diff --git a/03.Note/보안 그룹(Security Group).md b/03.Note/보안 그룹(Security Group).md new file mode 100644 index 0000000..1730ffb --- /dev/null +++ b/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] +> +> - 관련 사례나 반대되는 개념이 있다면 여기에 기록하세요. +> +> - 본인의 언어로 풀어서 쓰는 것이 제텔카스텔의 핵심입니다. +> + +--- diff --git a/03.Note/보안성(Security).md b/03.Note/보안성(Security).md new file mode 100644 index 0000000..a3136c5 --- /dev/null +++ b/03.Note/보안성(Security).md @@ -0,0 +1,23 @@ +- 작성 **날짜:** 2026-02-27 + +## 📑 개념 +> [!abstract] +> 시스템, 데이터, 그리고 네트워크를 **비인가된 접근, 수정, 파괴**로부터 보호하는 능력 + +## 📌 상세 + +| **요소** | **설명** | **핵심 가치** | +| ------------------------- | ----------------------------------- | ------------- | +| **기밀성 (Confidentiality)** | 허가된 사용자만이 정보에 접근할 수 있어야 함. | 암호화, 접근 제어 | +| **무결성 (Integrity)** | 데이터가 전송되거나 저장될 때 임의로 수정되지 않아야 함. | 디지털 서명, 해시 함수 | +| **가용성 (Availability)** | 인가된 사용자가 필요할 때 언제든 자원을 사용할 수 있어야 함. | DDoS 방어, 이중화 | + + +## 📝 상세 설명 +> [!note] +> +> - 말그대로 외부의 공격으로부터 보호가 잘 되어지는지를 말함 +> + +## 🔗 지식 연결 +- **태그:** #zettelkasten #knowledge \ No newline at end of file diff --git a/03.Note/생산성(Productivity).md b/03.Note/생산성(Productivity).md new file mode 100644 index 0000000..b8f42a0 --- /dev/null +++ b/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 \ No newline at end of file diff --git a/03.Note/서버리스(Serverless).md b/03.Note/서버리스(Serverless).md new file mode 100644 index 0000000..c82bc47 --- /dev/null +++ b/03.Note/서버리스(Serverless).md @@ -0,0 +1,17 @@ +- 작성 **날짜:** 2026-02-27 + +## 📑 개념 +> [!abstract] +> **서버리스(Serverless)**는 이름 그대로 "서버가 없다"는 뜻이 아니라, **"사용자가 서버를 관리할 필요가 없는 컴퓨팅 모델"**을 의미합니다. 인프라의 복잡한 추상화를 통해 개발자는 오직 **코드(비즈니스 로직)**에만 집중할 수 있는 환경을 말합니다. + +## 📌 상세 +> [!check] +|**특징**|**세부 설명**| +|---|---| +|**관리 서버 없음**|OS 설치, 패치, 하드웨어 관리에 신경 쓸 필요가 없음.| +|**유연한 확장성**|트래픽에 따라 자원이 자동으로 늘어나거나 줄어듦 (Auto-scaling).| +|**사용량 기반 과금**|서버를 켜둔 시간이 아니라, 실제 코드가 실행된 시간/횟수만큼만 비용 지불.| +|**고가용성 내장**|클라우드 제공사가 여러 가용 영역에 걸쳐 리소스를 분산하여 안정성 보장.| + +## 🔗 지식 연결 +- **태그:** #zettelkasten #knowledge diff --git a/03.Note/서브넷(Subnet).md b/03.Note/서브넷(Subnet).md new file mode 100644 index 0000000..eccafc6 --- /dev/null +++ b/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 \ No newline at end of file diff --git a/03.Note/신호 대 소음비(Signal-to-Noise Ratio).md b/03.Note/신호 대 소음비(Signal-to-Noise Ratio).md new file mode 100644 index 0000000..f7527ee --- /dev/null +++ b/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}}$$ + +- **신호 대 소음비가 높다:** 노래 소리(신호)는 쩌렁쩌렁한데 지지직거리는 잡음(소음)은 거의 안 들리는 상태입니다. 아주 깨끗하게 들리겠죠? +- **신호 대 소음비가 낮다:** 노래 소리는 작은데 잡음이 너무 커서 노래가 묻히는 상태입니다. 짜증이 나고 듣기 힘듭니다. + +--- diff --git a/03.Note/싱글 테넌시(Single-tenancy).md b/03.Note/싱글 테넌시(Single-tenancy).md new file mode 100644 index 0000000..a84b19f --- /dev/null +++ b/03.Note/싱글 테넌시(Single-tenancy).md @@ -0,0 +1,41 @@ +--- +id: "싱글 테넌시(Single-tenancy) 20260305" +created: "2026-03-05 13:06" +tags: +--- +## 💡 생각 +이곳에 하나의 생각 또는 아이디어를 작성합니다. + + +--- +## 📑 개념 +하나의 소프트웨어 인스턴스가 **단 한 명의 사용자**만을 위해 독립적으로 운영되는 구조 +단독 주택에 한 가족만 사는 것과 같습니다. + +## 📌 상세 +- **특징:** 사용자마다 전용 인프라와 데이터베이스가 할당됩니다. + +- **장점:** + + - **높은 보안성:** 물리적/논리적으로 완전히 격리되어 있어 보안이 강력합니다. + + - **커스터마이징:** 해당 사용자만을 위한 맞춤 설정이 자유롭습니다. + +- **단점:** * **비용 부담:** 인프라 구축 및 유지보수 비용이 높습니다. + + - **관리 복잡도:** 각 사용자별로 업데이트나 관리를 따로 해야 합니다. + +- **예시:** 온프레미스 서버 구축, 특정 기업용 전용 클라우드 서비스. + +## 📝 노트 +> [!note] +> +> - 관련 사례나 반대되는 개념이 있다면 여기에 기록하세요. +> +> - 본인의 언어로 풀어서 쓰는 것이 제텔카스텔의 핵심입니다. +> + +--- + +## 🔗 관련 노트 +[[테넌시(Tenancy)]], [[멀티 테넌시(Multi-tenancy)]] \ No newline at end of file diff --git a/03.Note/용량 공급자 전략 (Capacity Provider Strategy).md b/03.Note/용량 공급자 전략 (Capacity Provider Strategy).md new file mode 100644 index 0000000..59cded9 --- /dev/null +++ b/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으로 돌려 비용을 대폭 아낄 수 있습니다. \ No newline at end of file diff --git a/03.Note/유연성(Flexibility).md b/03.Note/유연성(Flexibility).md new file mode 100644 index 0000000..546012b --- /dev/null +++ b/03.Note/유연성(Flexibility).md @@ -0,0 +1,22 @@ +- 작성 **날짜:** 2026-02-27 + +## 📑 개념 +> [!abstract] +> "변화에 얼마나 쉽고 빠르게 대응할 수 있는가?" + +## 📌 상세 +> [!check] +> - **환경의 유연성:** 온프레미스에서 클라우드로, 또는 윈도우에서 리눅스로 실행 환경을 옮길 때의 용이성. +> +> - **구조의 유연성:** 마이크로서비스 아키텍처(MSA)처럼 특정 기능을 수정할 때 전체 시스템에 영향을 주지 않고 독립적으로 변경할 수 있는 능력. +> +> - **기술의 유연성:** 특정 벤더(Vendor Lock-in)에 종속되지 않고 필요에 따라 다양한 오픈 소스나 도구를 조합할 수 있는 상태. + +## 📝 노트 +> [!note] +> +> - 어떠한 상황에 얼마나 유연하게 잘 대응할 수 있는지, 단어 뜻 그대로 이해하면 될듯 +> + +## 🔗 지식 연결 +- **태그:** #zettelkasten #knowledge \ No newline at end of file diff --git a/03.Note/유연한 단순함.md b/03.Note/유연한 단순함.md new file mode 100644 index 0000000..18898a8 --- /dev/null +++ b/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] +> +> - **"추측에 근거해서 미리 복잡한 기능을 만들지 말되(단순함), 나중에 그 기능을 개선해야 할 때 코드 전체를 갈아엎지 않아도 되게끔 '벽'을 잘 세워두라(확장성)"** +> + +--- diff --git a/03.Note/최적화(Optimization).md b/03.Note/최적화(Optimization).md new file mode 100644 index 0000000..7a1893a --- /dev/null +++ b/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] +> +> - 관련 사례나 반대되는 개념이 있다면 여기에 기록하세요. +> +> - 본인의 언어로 풀어서 쓰는 것이 제텔카스텔의 핵심입니다. +> + +--- diff --git a/03.Note/컨테이너 오케스트레이션.md b/03.Note/컨테이너 오케스트레이션.md new file mode 100644 index 0000000..0bbd217 --- /dev/null +++ b/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 \ No newline at end of file diff --git a/03.Note/컨테이너(Container).md b/03.Note/컨테이너(Container).md new file mode 100644 index 0000000..66b7ccd --- /dev/null +++ b/03.Note/컨테이너(Container).md @@ -0,0 +1,22 @@ +- 작성 **날짜:** 2026-02-27 + +## 📑 개념 +> [!abstract] +> 컨테이너(Container)는 애플리케이션과 그 실행에 필요한 모든 것(코드, 런타임, 시스템 도구, 라이브러리, 설정 등)을 하나로 묶은 **표준화된 소프트웨어 패키지**입니다. + +## 📌 상세 +> [!check] +> ### 핵심 개념: "운송용 컨테이너와 같다" +> +> 항구의 컨테이너가 안에 무엇이 들었든(전자제품이든 가구든) 규격화되어 배에 쉽게 실을 수 있듯이, 소프트웨어 컨테이너도 어떤 환경(개발자 PC, 테스트 서버, 클라우드)에서든 **동일하게 작동**하도록 규격화된 것입니다. + +## 📝 노트 +> [!note] +> +> - 컨테이너 기술을 사용하기 쉽게 엔진화해놓은것이 도커입니다. + + +![[가상 머신(VM) vs 컨테이너]] + +## 🔗 지식 연결 +- **태그:** #docker \ No newline at end of file diff --git a/03.Note/코드의 가독성.md b/03.Note/코드의 가독성.md new file mode 100644 index 0000000..1a18096 --- /dev/null +++ b/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)]] + +코드에서 진짜 중요한 로직(신호)은 강조하고, 형식적인 문법이나 군더더기(소음)는 줄이는 것입니다. + +- **불필요한 주석 제거:** 코드만으로 설명이 가능하다면 주석은 소음일 뿐입니다. + +- **단순한 추상화:** 너무 복잡한 디자인 패턴을 남용하면 실제 비즈니스 로직을 찾기 힘들어집니다. + +--- diff --git a/03.Note/쿠버네티스(Kubernetes).md b/03.Note/쿠버네티스(Kubernetes).md new file mode 100644 index 0000000..9eec193 --- /dev/null +++ b/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 \ No newline at end of file diff --git a/03.Note/클러스터(Cluster).md b/03.Note/클러스터(Cluster).md new file mode 100644 index 0000000..9d116f5 --- /dev/null +++ b/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 \ No newline at end of file diff --git a/03.Note/태스크 실행 역할(Task Execution Role).md b/03.Note/태스크 실행 역할(Task Execution Role).md new file mode 100644 index 0000000..fe86458 --- /dev/null +++ b/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:** 환경 변수에 담을 비밀번호나 설정값을 가져올 권한. + +--- diff --git a/03.Note/태스크 역할(Task Role).md b/03.Note/태스크 역할(Task Role).md new file mode 100644 index 0000000..99c5fed --- /dev/null +++ b/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] +> +> - 관련 사례나 반대되는 개념이 있다면 여기에 기록하세요. +> +> - 본인의 언어로 풀어서 쓰는 것이 제텔카스텔의 핵심입니다. +> + +--- diff --git a/03.Note/태스크 정의 패밀리.md b/03.Note/태스크 정의 패밀리.md new file mode 100644 index 0000000..6893bdb --- /dev/null +++ b/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)을 가져다가 쓰면 되겠구나!"**라고 판단합니다. \ No newline at end of file diff --git a/03.Note/태스크(Task).md b/03.Note/태스크(Task).md new file mode 100644 index 0000000..7c263a9 --- /dev/null +++ b/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 \ No newline at end of file diff --git a/03.Note/테넌시(Tenancy).md b/03.Note/테넌시(Tenancy).md new file mode 100644 index 0000000..772847e --- /dev/null +++ b/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)| + +--- + +모든 온프레미스는 대개 싱글 테넌시 구조를 가집니다 (자사 서비스만 돌리니까요). 하지만 모든 싱글 테넌시가 온프레미스인 것은 아닙니다. 요즘은 클라우드 환경에서도 보안이나 성능을 위해 싱글 테넌시 방식을 많이 사용합니다. \ No newline at end of file diff --git a/03.Note/파게이트 스팟(Fargate Spot).md b/03.Note/파게이트 스팟(Fargate Spot).md new file mode 100644 index 0000000..9e526b6 --- /dev/null +++ b/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)로 섞어서 사용하는 것이 권장됩니다. + +--- diff --git a/03.Note/파게이트(Fargate).md b/03.Note/파게이트(Fargate).md new file mode 100644 index 0000000..781d013 --- /dev/null +++ b/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 +- \ No newline at end of file diff --git a/03.Note/파게이트(Fargate)의 장점.md b/03.Note/파게이트(Fargate)의 장점.md new file mode 100644 index 0000000..291be93 --- /dev/null +++ b/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 \ No newline at end of file diff --git a/03.Note/파레토의 법칙.md b/03.Note/파레토의 법칙.md new file mode 100644 index 0000000..510b4c8 --- /dev/null +++ b/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이 될 수도 있습니다. 중요한 것은 원인과 결과의 불균형을 이해하고 핵심에 집중하는 태도입니다. +> + +--- diff --git a/03.Note/확장성(Scalability).md b/03.Note/확장성(Scalability).md new file mode 100644 index 0000000..278d7b5 --- /dev/null +++ b/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 \ No newline at end of file diff --git a/04.Extra/Pasted image 20260227093328.png b/04.Extra/Pasted image 20260227093328.png new file mode 100644 index 0000000..389e5f1 Binary files /dev/null and b/04.Extra/Pasted image 20260227093328.png differ diff --git a/04.Extra/Pasted image 20260227094154.png b/04.Extra/Pasted image 20260227094154.png new file mode 100644 index 0000000..1fe32d5 Binary files /dev/null and b/04.Extra/Pasted image 20260227094154.png differ diff --git a/04.Extra/Pasted image 20260227162406.png b/04.Extra/Pasted image 20260227162406.png new file mode 100644 index 0000000..305c025 Binary files /dev/null and b/04.Extra/Pasted image 20260227162406.png differ diff --git a/04.Extra/Pasted image 20260227163046.png b/04.Extra/Pasted image 20260227163046.png new file mode 100644 index 0000000..91e26c4 Binary files /dev/null and b/04.Extra/Pasted image 20260227163046.png differ diff --git a/04.Extra/Pasted image 20260227163118.png b/04.Extra/Pasted image 20260227163118.png new file mode 100644 index 0000000..0fff432 Binary files /dev/null and b/04.Extra/Pasted image 20260227163118.png differ diff --git a/04.Extra/Pasted image 20260304165810.png b/04.Extra/Pasted image 20260304165810.png new file mode 100644 index 0000000..bf5571e Binary files /dev/null and b/04.Extra/Pasted image 20260304165810.png differ diff --git a/04.Extra/Pasted image 20260304170925.png b/04.Extra/Pasted image 20260304170925.png new file mode 100644 index 0000000..796f3ce Binary files /dev/null and b/04.Extra/Pasted image 20260304170925.png differ diff --git a/04.Extra/Pasted image 20260304171641.png b/04.Extra/Pasted image 20260304171641.png new file mode 100644 index 0000000..0c6dbda Binary files /dev/null and b/04.Extra/Pasted image 20260304171641.png differ diff --git a/04.Extra/Pasted image 20260304171846.png b/04.Extra/Pasted image 20260304171846.png new file mode 100644 index 0000000..0c6dbda Binary files /dev/null and b/04.Extra/Pasted image 20260304171846.png differ diff --git a/04.Extra/Pasted image 20260304171851.png b/04.Extra/Pasted image 20260304171851.png new file mode 100644 index 0000000..bf73eb8 Binary files /dev/null and b/04.Extra/Pasted image 20260304171851.png differ diff --git a/04.Extra/Pasted image 20260304171939.png b/04.Extra/Pasted image 20260304171939.png new file mode 100644 index 0000000..99e736a Binary files /dev/null and b/04.Extra/Pasted image 20260304171939.png differ diff --git a/04.Extra/Pasted image 20260305083155.png b/04.Extra/Pasted image 20260305083155.png new file mode 100644 index 0000000..dbabdf8 Binary files /dev/null and b/04.Extra/Pasted image 20260305083155.png differ diff --git a/04.Extra/Pasted image 20260305083442.png b/04.Extra/Pasted image 20260305083442.png new file mode 100644 index 0000000..104774e Binary files /dev/null and b/04.Extra/Pasted image 20260305083442.png differ diff --git a/04.Extra/Pasted image 20260305084812.png b/04.Extra/Pasted image 20260305084812.png new file mode 100644 index 0000000..100c18e Binary files /dev/null and b/04.Extra/Pasted image 20260305084812.png differ diff --git a/04.Extra/Pasted image 20260305085241.png b/04.Extra/Pasted image 20260305085241.png new file mode 100644 index 0000000..9628d51 Binary files /dev/null and b/04.Extra/Pasted image 20260305085241.png differ diff --git a/04.Extra/Pasted image 20260305085256.png b/04.Extra/Pasted image 20260305085256.png new file mode 100644 index 0000000..d3f7771 Binary files /dev/null and b/04.Extra/Pasted image 20260305085256.png differ diff --git a/04.Extra/Pasted image 20260305091259.png b/04.Extra/Pasted image 20260305091259.png new file mode 100644 index 0000000..15930f9 Binary files /dev/null and b/04.Extra/Pasted image 20260305091259.png differ diff --git a/04.Extra/Pasted image 20260305091749.png b/04.Extra/Pasted image 20260305091749.png new file mode 100644 index 0000000..dd24da2 Binary files /dev/null and b/04.Extra/Pasted image 20260305091749.png differ diff --git a/04.Extra/Pasted image 20260305093459.png b/04.Extra/Pasted image 20260305093459.png new file mode 100644 index 0000000..a464d9b Binary files /dev/null and b/04.Extra/Pasted image 20260305093459.png differ diff --git a/04.Extra/Pasted image 20260305094500.png b/04.Extra/Pasted image 20260305094500.png new file mode 100644 index 0000000..c06dea7 Binary files /dev/null and b/04.Extra/Pasted image 20260305094500.png differ diff --git a/04.Extra/Pasted image 20260305094813.png b/04.Extra/Pasted image 20260305094813.png new file mode 100644 index 0000000..08943ca Binary files /dev/null and b/04.Extra/Pasted image 20260305094813.png differ diff --git a/04.Extra/Pasted image 20260305100339.png b/04.Extra/Pasted image 20260305100339.png new file mode 100644 index 0000000..c91ec78 Binary files /dev/null and b/04.Extra/Pasted image 20260305100339.png differ diff --git a/04.Extra/Pasted image 20260305100917.png b/04.Extra/Pasted image 20260305100917.png new file mode 100644 index 0000000..0554c7f Binary files /dev/null and b/04.Extra/Pasted image 20260305100917.png differ diff --git a/04.Extra/Pasted image 20260305101005.png b/04.Extra/Pasted image 20260305101005.png new file mode 100644 index 0000000..2bae7a6 Binary files /dev/null and b/04.Extra/Pasted image 20260305101005.png differ diff --git a/04.Extra/Pasted image 20260305101051.png b/04.Extra/Pasted image 20260305101051.png new file mode 100644 index 0000000..ef87483 Binary files /dev/null and b/04.Extra/Pasted image 20260305101051.png differ diff --git a/04.Extra/Pasted image 20260305102304.png b/04.Extra/Pasted image 20260305102304.png new file mode 100644 index 0000000..77e3c0c Binary files /dev/null and b/04.Extra/Pasted image 20260305102304.png differ diff --git a/04.Extra/Pasted image 20260305103056.png b/04.Extra/Pasted image 20260305103056.png new file mode 100644 index 0000000..fcb38d4 Binary files /dev/null and b/04.Extra/Pasted image 20260305103056.png differ diff --git a/04.Extra/Pasted image 20260305104853.png b/04.Extra/Pasted image 20260305104853.png new file mode 100644 index 0000000..c31fe3f Binary files /dev/null and b/04.Extra/Pasted image 20260305104853.png differ diff --git a/04.Extra/Pasted image 20260305110136.png b/04.Extra/Pasted image 20260305110136.png new file mode 100644 index 0000000..683ce33 Binary files /dev/null and b/04.Extra/Pasted image 20260305110136.png differ diff --git a/04.Extra/Pasted image 20260305110258.png b/04.Extra/Pasted image 20260305110258.png new file mode 100644 index 0000000..b15338d Binary files /dev/null and b/04.Extra/Pasted image 20260305110258.png differ diff --git a/04.Extra/Pasted image 20260305111038.png b/04.Extra/Pasted image 20260305111038.png new file mode 100644 index 0000000..399aee8 Binary files /dev/null and b/04.Extra/Pasted image 20260305111038.png differ diff --git a/04.Extra/Pasted image 20260305140832.png b/04.Extra/Pasted image 20260305140832.png new file mode 100644 index 0000000..ac11501 Binary files /dev/null and b/04.Extra/Pasted image 20260305140832.png differ diff --git a/04.Extra/Pasted image 20260305150408.png b/04.Extra/Pasted image 20260305150408.png new file mode 100644 index 0000000..f2e95cb Binary files /dev/null and b/04.Extra/Pasted image 20260305150408.png differ diff --git a/04.Extra/Pasted image 20260316134417.png b/04.Extra/Pasted image 20260316134417.png new file mode 100644 index 0000000..25f4e2b Binary files /dev/null and b/04.Extra/Pasted image 20260316134417.png differ diff --git a/04.Extra/Pasted image 20260316134502.png b/04.Extra/Pasted image 20260316134502.png new file mode 100644 index 0000000..e4d67ee Binary files /dev/null and b/04.Extra/Pasted image 20260316134502.png differ diff --git a/04.Extra/Pasted image 20260316134525.png b/04.Extra/Pasted image 20260316134525.png new file mode 100644 index 0000000..26d7be8 Binary files /dev/null and b/04.Extra/Pasted image 20260316134525.png differ diff --git a/04.Extra/Pasted image 20260316134705.png b/04.Extra/Pasted image 20260316134705.png new file mode 100644 index 0000000..d783c8d Binary files /dev/null and b/04.Extra/Pasted image 20260316134705.png differ diff --git a/04.Extra/index.md b/04.Extra/index.md new file mode 100644 index 0000000..827eb45 --- /dev/null +++ b/04.Extra/index.md @@ -0,0 +1,3 @@ +--- +title: extra +--- diff --git a/05.Template/Todo 템플릿 1.md b/05.Template/Todo 템플릿 1.md new file mode 100644 index 0000000..06f9d1a --- /dev/null +++ b/05.Template/Todo 템플릿 1.md @@ -0,0 +1,6 @@ +> [!todo] **오늘의 할 일** 📋 +> +> - [ ] 🚀 **핵심 프로젝트 집중** (오전) +> - [ ] 📧 **이메일 및 메신저 확인 +> - [ ] ✍️ **데일리 회고 작성** #journal +> diff --git a/05.Template/Todo 템플릿 2.md b/05.Template/Todo 템플릿 2.md new file mode 100644 index 0000000..4089ef4 --- /dev/null +++ b/05.Template/Todo 템플릿 2.md @@ -0,0 +1,5 @@ + +> [!check] **완료된 항목** ✅ +> +> - [x] ☕️ 아침 커피 한 잔 +> - [x] 🧘 스트레칭 5분 diff --git a/05.Template/Todo 템플릿 3.md b/05.Template/Todo 템플릿 3.md new file mode 100644 index 0000000..d8a8ca4 --- /dev/null +++ b/05.Template/Todo 템플릿 3.md @@ -0,0 +1,5 @@ +> [!abstract] **아이디어 & 메모** 💡 +> +> - [ ] 새 보드게임 규칙 찾아보기 +> - [ ] 다음 주 식단 계획하기 + diff --git a/05.Template/index.md b/05.Template/index.md new file mode 100644 index 0000000..9259caa --- /dev/null +++ b/05.Template/index.md @@ -0,0 +1,5 @@ +--- +title: template +exclude: "true" +publish: "false" +--- diff --git a/05.Template/경고 템플릿.md b/05.Template/경고 템플릿.md new file mode 100644 index 0000000..a76c514 --- /dev/null +++ b/05.Template/경고 템플릿.md @@ -0,0 +1,2 @@ +> [!warning] + diff --git a/05.Template/관련 템플릿.md b/05.Template/관련 템플릿.md new file mode 100644 index 0000000..e24af02 --- /dev/null +++ b/05.Template/관련 템플릿.md @@ -0,0 +1,2 @@ +## 🔗 관련 메모 +- 메모 \ No newline at end of file diff --git a/05.Template/노트 템플릿.md b/05.Template/노트 템플릿.md new file mode 100644 index 0000000..28a7289 --- /dev/null +++ b/05.Template/노트 템플릿.md @@ -0,0 +1,2 @@ +> [!note] + diff --git a/05.Template/리스트 템플릿.md b/05.Template/리스트 템플릿.md new file mode 100644 index 0000000..06cbd5b --- /dev/null +++ b/05.Template/리스트 템플릿.md @@ -0,0 +1,19 @@ +## 🔢 목록 + +#### 1. 목록 + +#### 2. 목록 + +#### 3. 목록 + +#### 4. 목록 + +#### 5. 목록 + +#### 6. 목록 + +#### 7. 목록 + +#### 8. 목록 + +#### 9. 목록 \ No newline at end of file diff --git a/05.Template/메모 템플릿.md b/05.Template/메모 템플릿.md new file mode 100644 index 0000000..c2fb098 --- /dev/null +++ b/05.Template/메모 템플릿.md @@ -0,0 +1,27 @@ +--- +id: "{{title}} {{date:YYYYMMDD}}" +created: "{{date}} {{time}}" +tags: +aliases: +--- +## 💡 생각 +이곳에 하나의 생각 또는 아이디어를 작성합니다. + +--- +## 📑 개념 + 여기에 이 메모가 다루는 개념을 한 문장으로 정의하세요. (예: 제텔카스텔의 원자성이란 지식의 최소 단위를 의미한다.) + +## 📌 상세 +1. **특징 1**: 내용을 입력하세요. +2. **특징 2**: 내용을 입력하세요. +3. **특징 3**: 내용을 입력하세요. + +## 📝 노트 +> [!note] +> +> - 관련 사례나 반대되는 개념이 있다면 여기에 기록하세요. +> +> - 본인의 언어로 풀어서 쓰는 것이 제텔카스텔의 핵심입니다. +> + +--- diff --git a/05.Template/볼륨 템플릿.md b/05.Template/볼륨 템플릿.md new file mode 100644 index 0000000..30a33a8 --- /dev/null +++ b/05.Template/볼륨 템플릿.md @@ -0,0 +1,5 @@ +--- +id: "{{title}} {{date:YYYYMMDD}}" +created: "{{date}} {{time}}" +tags: +--- diff --git a/05.Template/생각.md b/05.Template/생각.md new file mode 100644 index 0000000..e57ed55 --- /dev/null +++ b/05.Template/생각.md @@ -0,0 +1,2 @@ +## 💡 생각 +이곳에 하나의 생각 또는 아이디어를 작성합니다. \ No newline at end of file diff --git a/05.Template/쉘프 템플릿.md b/05.Template/쉘프 템플릿.md new file mode 100644 index 0000000..8daf2f0 --- /dev/null +++ b/05.Template/쉘프 템플릿.md @@ -0,0 +1,5 @@ +## 🔢 목록 + +#### 1. 초기 설정 및 환경 구축** + +#### 2. 데이터 처리 및 구성 (노트 최적화)** \ No newline at end of file diff --git a/05.Template/예시 템플릿.md b/05.Template/예시 템플릿.md new file mode 100644 index 0000000..1450c19 --- /dev/null +++ b/05.Template/예시 템플릿.md @@ -0,0 +1,2 @@ +> [!example] + diff --git a/05.Template/정보 템플릿.md b/05.Template/정보 템플릿.md new file mode 100644 index 0000000..0b3abc8 --- /dev/null +++ b/05.Template/정보 템플릿.md @@ -0,0 +1,2 @@ +> [!info] + diff --git a/05.Template/질문과 답변 템플릿.md b/05.Template/질문과 답변 템플릿.md new file mode 100644 index 0000000..b19ac26 --- /dev/null +++ b/05.Template/질문과 답변 템플릿.md @@ -0,0 +1,9 @@ +> [!question] +> Q. 질문 +> A. 답변 + + + + + + diff --git a/05.Template/체크 템플릿.md b/05.Template/체크 템플릿.md new file mode 100644 index 0000000..aa9504f --- /dev/null +++ b/05.Template/체크 템플릿.md @@ -0,0 +1,2 @@ +> [!check] + diff --git a/05.Template/추상 템플릿.md b/05.Template/추상 템플릿.md new file mode 100644 index 0000000..e18ad1a --- /dev/null +++ b/05.Template/추상 템플릿.md @@ -0,0 +1 @@ +> [!abstract] diff --git a/05.Template/태그 템플릿.md b/05.Template/태그 템플릿.md new file mode 100644 index 0000000..0b81cf6 --- /dev/null +++ b/05.Template/태그 템플릿.md @@ -0,0 +1 @@ +**Tags:** #태그1 #태그2 \ No newline at end of file diff --git a/06.Archive/index.md b/06.Archive/index.md new file mode 100644 index 0000000..8d634dd --- /dev/null +++ b/06.Archive/index.md @@ -0,0 +1,3 @@ +--- +title: 2. 보관함 +--- diff --git a/index.md b/index.md new file mode 100644 index 0000000..a0eaceb --- /dev/null +++ b/index.md @@ -0,0 +1,14 @@ +--- +title: "🍀 나의 지식 보관소" +--- +--- + +## 📂 카테고리 바로가기 + +--- +[[AWS Architecture로 전환]] + + +> [!abstract] 알림 +> **Explorer**를 사용하면 더 많은 글들을 찾아볼 수 있습니다. +> 궁금한 점이 있다면 언제든 둘러보세요! \ No newline at end of file