쿼츠 블로그를 위해 대공사
This commit is contained in:
@@ -0,0 +1,12 @@
|
||||
|
||||
As-Is
|
||||
![[Pasted image 20260227093328.png]]https://wk.wecmms.com
|
||||
https://innox.wecmms.com
|
||||
|
||||
### EC2기반의 아키텍처에는 다음의 한계들을 가짐
|
||||
![[EC2기반 아키텍처의 한계점]]
|
||||
|
||||
|
||||
### 한계를 극복하기 위해 나아가야 할 방향
|
||||
[[서버리스(Serverless)]] 구성
|
||||
: AWS가 제공해주는 [[파게이트(Fargate)]]로 구성한다.
|
||||
@@ -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)]]
|
||||
- [[테넌시 구성 가이드]]
|
||||
@@ -0,0 +1 @@
|
||||
VPC
|
||||
@@ -0,0 +1 @@
|
||||
## 1.
|
||||
@@ -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]]
|
||||
@@ -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 서비스 만들기]]
|
||||
@@ -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보다 설정이 좀 더 유연하고 복잡하게 느껴질 수 있습니다.
|
||||
@@ -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]]
|
||||
별도의 로그 수집 정책이 있을 경우 다른 것으로 지정 가능
|
||||
@@ -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/메모리** | **최소 필요량** | 설정한 수치에 비례해서 초 단위로 과금됨 |
|
||||
|
||||
---
|
||||
@@ -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)]] 형태로 구현됨.
|
||||
@@ -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 파드]]
|
||||
@@ -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)]]
|
||||
@@ -0,0 +1,22 @@
|
||||
### CMMS의 SaaS 플랫폼화를 해야합니다.
|
||||
|
||||
##### 플랫폼화를 할 경우 장점
|
||||
> [!check]
|
||||
> - **운영 효율 극대화 및 비용 최적화**
|
||||
>
|
||||
> : 기존 EC2 기반의 1:1 관리 방식에서 벗어나 하나의 클러스터에서 여러 테넌트(고객사)를 관리함으로써 운영 공수를 획기적으로 줄입니다.
|
||||
>
|
||||
> - **시장 대응 속도(Time-to-Market) 가속화**
|
||||
>
|
||||
> : 새로운 고객사가 추가될 때마다 서버를 새로 구축할 필요가 없습니다. 미리 구성된 멀티 테넌시 환경과 커스텀 라우팅을 통해 클릭 몇 번만으로 신규 고객 전용 환경을 즉시 제공(On-boarding)할 수 있어, 비즈니스 기회를 놓치지 않고 빠르게 시장을 확대할 수 있습니다.
|
||||
>
|
||||
> - **서비스 안정성 및 보안성 고도화**
|
||||
>
|
||||
> : 파드 자동 복구기능을 통해 장애 발생 상황 대응에 인력의 투입이 필요 없어지도록 해줍니다. (관리 포인트가 줄어듦)
|
||||
|
||||
> [!note]
|
||||
>
|
||||
> - CMMS의 경우 SaaS 플랫폼화가 이미 진행되어있는 상태
|
||||
> - Enterprize 요금제를 요구하는 고객을 위한 '설치형 구독형' 모델 구축을 위한 Cloud Architecture 화를 진행한 것임
|
||||
> - 기본형의 SaaS CMMS는 이미 존재함
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
## [[EC2(Elastic Compute Cloud)]]
|
||||
![[EC2(Elastic Compute Cloud)#📑 개념]]
|
||||
|
||||
## [[컨테이너(Container)]]
|
||||
![[컨테이너(Container)#📑 개념]]
|
||||
|
||||
## [[파게이트(Fargate)]]
|
||||
![[파게이트(Fargate)#📑 개념]]
|
||||
+33
@@ -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)#💡 왜 '용량 공급자 전략'을 써야 할까요? (핵심 이유)]]
|
||||
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
순서
|
||||
## 1. [[VPC(Virtual Private Cloud)]] 생성
|
||||
|
||||
## 2. VPC에 [[서브넷(Subnet)]] 생성
|
||||
: 필요에 따라 퍼블릭,프라이빗 서브넷을 생성하면 됨.
|
||||
[[Pod를 Private subnet에 두는 이유]]
|
||||
## 3. 라우팅 테이블 생성
|
||||
|
||||
## 4. 인터넷 게이트웨이 생성
|
||||
|
||||
## 5. EC2 생성
|
||||
@@ -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가 보안과 서버인프라 문제를 모두 책임져주기 때문에 생산성 향상이 될 수 있습니다.
|
||||
|
||||
@@ -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를 써야 할 일이 생길 때만 필요한 권한을 콕 집어서 추가해 주면 됩니다.
|
||||
@@ -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)]]
|
||||
@@ -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)이다. 전략 없는 기술은 개발자를 지치게 만든다."
|
||||
|
||||
- "단순함은 복잡함보다 어렵다. 생각을 명확히 해서 단순하게 만들려면 정말 열심히 노력해야 한다." - 스티브잡스
|
||||
@@ -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)'만 잘 만들어 두는 것"
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
id: 유닉스 철학 (The Unix Philosophy) 20260330
|
||||
created: 2026-03-30 15:20
|
||||
tags:
|
||||
---
|
||||
# 개념
|
||||
[[유닉스(Unix)]] 개발자들 사이에서 내려오는 유명한 원칙이 있습니다. 바로 **작고 단순한 것이 아름답다**는 점입니다.
|
||||
|
||||
1. **각 프로그램은 한 가지 일만 잘해야 한다.**
|
||||
|
||||
2. **여러 프로그램을 조합해서 복잡한 문제를 해결한다.** (이때 사용하는 것이 **파이프(|)** 기능입니다.)
|
||||
|
||||
3. **모든 것은 파일이다.** (텍스트 파일로 설정을 관리하고 데이터를 주고받습니다.)
|
||||
|
||||
> [!note] 단순히 운영체제를 만드는 기술적 규칙이 아니라, 소프트웨어를 설계하고 문제를 해결하는 일종의 **미니멀리즘 예술**에 가깝습니다.
|
||||
|
||||
: 1970년대 벨 연구소의 더글러스 매킬로이(Douglas McIlroy)가 정립한 이 철학의 핵심은 **작고 단순하며, 서로 협력하는 도구**를 만드는 것입니다.
|
||||
|
||||
|
||||
## 1. 핵심 3원칙
|
||||
|
||||
더글러스 매킬로이는 유닉스 철학을 다음 세 문장으로 요약했습니다.
|
||||
|
||||
- **한 가지만 하되, 아주 잘하라 (Do One Thing and Do It Well):** 하나의 프로그램은 오직 하나의 기능에만 집중해야 합니다. 기능이 많아지면 복잡해지고 버그가 생기기 쉽기 때문입니다.
|
||||
|
||||
- **함께 작동하도록 만들어라 (Expect the output of every program to become the input to another):** 프로그램은 서로 연결될 것을 예상하고 만들어야 합니다.
|
||||
|
||||
- **텍스트 스트림을 표준 인터페이스로 사용하라:** 데이터는 가공하기 가장 쉬운 **텍스트** 형태로 주고받아야 합니다. 그래야 서로 다른 프로그램끼리 쉽게 대화할 수 있습니다.
|
||||
|
||||
|
||||
## 2. 파이프(Pipe)와 필터
|
||||
|
||||
유닉스 철학을 시각적으로 가장 잘 보여주는 것이 바로 **파이프(|)** 기호입니다. 작은 도구들을 파이프로 연결하여 복잡한 일을 수행하는 방식이죠.
|
||||
|
||||
> **예시:** `ls | grep "test" | sort`
|
||||
>
|
||||
> 1. `ls`: 파일 목록을 출력한다. (한 가지 일)
|
||||
>
|
||||
> 2. `grep`: 그중 "test"가 포함된 것만 골라낸다. (한 가지 일)
|
||||
>
|
||||
> 3. `sort`: 결과를 알파벳 순으로 정렬한다. (한 가지 일)
|
||||
>
|
||||
|
||||
각각은 단순한 도구일 뿐이지만, 연결하면 강력한 기능을 수행합니다. 이는 마치 레고 블록을 조립하는 것과 비슷합니다.
|
||||
|
||||
## 3. 에릭 레이먼드의 룰 (Rule of...)
|
||||
|
||||
오픈소스 전도사인 에릭 레이먼드는 그의 저서에서 유닉스 철학을 더 구체적인 규칙으로 확장했습니다.
|
||||
|
||||
- **단순함의 법칙 (Rule of Simplicity):** 복잡해지기 전까지 최대한 단순하게 설계하라.
|
||||
|
||||
- **명확함의 법칙 (Rule of Clarity):** 코드는 컴퓨터가 읽기 쉬운 것보다 사람이 읽기 쉬운 것이 더 중요하다.
|
||||
|
||||
위의 두 법칙을 지킴으로써 코드가 [[KISS (Keep It Simple, Stupid)]]해진다.
|
||||
|
||||
- **조합의 법칙 (Rule of Composition):** 프로그램이 다른 프로그램과 쉽게 연결될 수 있도록 설계하라.
|
||||
|
||||
조합의 법칙을 지키다 보면 코드가 [[DRY (Don't Repeat Yourself)]]해진다.
|
||||
|
||||
- **침묵의 법칙 (Rule of Silence):** 프로그램이 정말로 할 말이 없을 때는 아무것도 출력하지 마라. (그래야 다른 프로그램이 출력을 가공하기 좋습니다.)
|
||||
|
||||
유닉스 철학을 구체화 한 규칙들을 지킴으로써 [[클린코드의 기술]]들을 지키게 된다.
|
||||
|
||||
---
|
||||
|
||||
## 4. 왜 유닉스 철학이 중요한가요?
|
||||
|
||||
오늘날 현대적인 소프트웨어 개발 방법론인 **마이크로서비스 아키텍처(MSA)** 나 **함수형 프로그래밍**의 뿌리도 이 유닉스 철학에 닿아 있습니다.
|
||||
|
||||
- **유지보수 용이:** 작고 단순한 코드는 고치기 쉽습니다.
|
||||
|
||||
- **재사용성:** 잘 만들어진 작은 도구는 여기저기서 다시 쓰일 수 있습니다.
|
||||
|
||||
- **확장성:** 새로운 기능을 추가할 때 기존 프로그램을 수정하는 대신, 새로운 도구를 만들어 연결하면 됩니다.
|
||||
@@ -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 범위에는 포함되지 않습니다. 다음 단계에 검토합시다"라고 선을 긋는 것이 중요합니다.
|
||||
|
||||
@@ -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:** 수정할 때 여러 곳을 고치다 실수하는 '버그 수정 비용'을 줄여서 **운영 비용**을 아낍니다.
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
id: "Functional Domain Modeling 20260407"
|
||||
created: "2026-04-07 15:40"
|
||||
tags:
|
||||
---
|
||||
함수형 프로그래밍(FP)과 도메인 주도 설계(DDD)를 상호 보완한 소프트웨어 공학 개념
|
||||
|
||||
[[유닉스 철학 (The Unix Philosophy)]]
|
||||
[[유닉스의 철학과 필터]]
|
||||
|
||||
유닉스 철학에 따라서 코드를 최대한 잘게 쪼개고 단순화한다.
|
||||
이것을 코드의 [[필터(Filter)]]화 라고 하자.
|
||||
|
||||
필요한 기능을 구현하기 위해 최소의 기능만 구현된 필터들을 만들어낼 때 결국 함수의 형태로 만들게 된다.
|
||||
[[함수형 프로그래밍(Functional Programming)]]은 이 필터를 구현하기 위한 방법론이다.
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
id: "리눅스의 역사 20260407"
|
||||
created: "2026-04-07 13:12"
|
||||
tags:
|
||||
---
|
||||
리눅스는 오늘날 **서버, 스마트폰(안드로이드), 임베디드 시스템 등 우리 생활 어디에나 존재**하지만, 그 시작은 한 대학생의 작고 겸손한 프로젝트였습니다. 리눅스의 역사를 주요 변곡점별로 정리해 드릴게요.
|
||||
|
||||
# 역사
|
||||
## 1. 리눅스의 뿌리: [[유닉스(Unix)]]와 GNU
|
||||
|
||||
리눅스를 이해하려면 먼저 그 조상 격인 [[유닉스(Unix)]]와 [[GNU]]**프로젝트**를 알아야 합니다.
|
||||
|
||||
- **[[유닉스(Unix)]]의 탄생:** 1969년 AT&T 벨 연구소에서 개발된 운영체제입니다. 강력했지만, 점차 유료화되고 소스 코드가 폐쇄적으로 변했습니다.
|
||||
|
||||
- **리처드 스톨먼과 [[GNU]]:** 1983년, 리처드 스톨먼은 누구나 자유롭게 소프트웨어를 사용하고 수정할 수 있어야 한다는 철학 아래 [[GNU]]프로젝트를 시작했습니다. 그는 유닉스와 호환되는 자유 운영체제를 만들고자 했으며, 컴파일러(GCC)와 에디터(Emacs) 등 많은 도구를 만들었지만 정작 운영체제의 핵심인 [[커널(Kernel)]] 이 완성되지 않은 상태였습니다.
|
||||
|
||||
## 2. 1991년: 리누스 토르발스의 등장
|
||||
|
||||
1991년, 핀란드 헬싱키 대학교의 학생이었던 **리누스 토르발스(Linus Torvalds)** 는 당시 교육용 유닉스였던 [[미닉스의 한계]]에 답답함을 느꼈습니다. 그는 취미 삼아 새로운 운영체제 [[커널(Kernel)]]을 직접 만들기 시작했습니다.
|
||||
|
||||
- **역사적인 메일:** 1991년 8월 25일, 그는 뉴스그룹에 다음과 같은 요지의 글을 올립니다.
|
||||
|
||||
> 그냥 취미일 뿐입니다. GNU처럼 거창하거나 전문적인 건 아니에요.
|
||||
|
||||
- **리눅스의 탄생:** 리누스가 만든 이 커널은 그의 이름과 [[유닉스(Unix)]]를 합쳐 **리눅스(Linux)** 라고 불리게 되었습니다.
|
||||
|
||||
|
||||
## 3. 리눅스와 GNU의 결합
|
||||
|
||||
리누스 토르발스가 만든 것은 **커널(컴퓨터 하드웨어를 제어하는 핵심 부위)** 뿐이었습니다. 운영체제가 제대로 작동하려면 셸, 컴파일러, 라이브러리 같은 도구들이 필요했는데, 이때 리처드 스톨먼의 **GNU 도구**들이 리눅스 커널과 결합하게 됩니다.
|
||||
|
||||
이 결합을 통해 완전한 형태의 운영체제가 탄생했으며, 엄밀하게는 **GNU/Linux**라고 부르는 것이 맞습니다.
|
||||
|
||||
## 4. 성장의 동력: 오픈소스와 GPL
|
||||
|
||||
리눅스가 폭발적으로 성장한 이유는 **GPL(General Public License)** 덕분입니다.
|
||||
|
||||
- 누구나 코드를 볼 수 있고, 수정할 수 있으며, 배포할 수 있다는 원칙 덕분에 전 세계의 천재 개발자들이 자발적으로 리눅스의 버그를 잡고 기능을 추가하기 시작했습니다.
|
||||
|
||||
|
||||
## 5. 리눅스의 진화 과정
|
||||
|
||||
- **1990년대 중반:** 슬랙웨어, 데비안, 레드햇 같은 **배포판**들이 등장하며 일반 사용자들도 설치하기 쉬워졌습니다.
|
||||
|
||||
- **2000년대:** 기업들이 리눅스의 안정성을 인정하며 서버 시장을 장악하기 시작했습니다. IBM, 인텔 등이 거액을 투자하며 생태계가 커졌습니다.
|
||||
|
||||
- **2008년~현재:** 구글이 리눅스 커널을 기반으로 **안드로이드**를 발표하면서, 리눅스는 전 세계에서 가장 많이 쓰이는 모바일 운영체제가 되었습니다. 또한 현재 전 세계 슈퍼컴퓨터의 100%가 리눅스로 작동합니다.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
id: 리눅스의 파일시스템 20260403
|
||||
created: 2026-04-03 10:43
|
||||
tags:
|
||||
---
|
||||
리눅스의 파일 시스템 구조는 [[FHS(Filesystem Hierarchy Standard)]]라는 표준을 따릅니다. 윈도우처럼 `C:\`, `D:\`로 나뉘는 게 아니라, 뿌리가 되는 **루트(`/`)** 아래에 모든 것이 가지처럼 뻗어 나가는 **역트리 구조**죠.
|
||||
![[Pasted image 20260403104845.png]]
|
||||
덕분에 사용자나 소프트웨어 개발자는 어떤 리눅스 배포판을 사용하더라도 특정 파일이 어디에 있을지 예측할 수 있습니다.
|
||||
|
||||
상세한 파일 시스템 구조는 [[FHS(Filesystem Hierarchy Standard)]] 참고
|
||||
|
||||
|
||||
> [!info] 우리가 자주 건드리는 중요 폴더
|
||||
- **etc:** 시스템의 모든 **설정 파일**이 들어있는 심장부입니다. (비밀번호, 네트워크, 서비스 설정 등)
|
||||
- **home:** 일반 사용자들의 개인 폴더가 있는 곳입니다. (`/home/dihwang`)
|
||||
- **root:** 일반 사용자가 접근할 수 없는 **최고 관리자(root) 전용 홈 디렉토리**입니다. (보시면 권한이 `drwx------`로 꽉 막혀 있죠?)
|
||||
- **var:** 내용이 수시로 변하는 파일들. 주로 **로그(log)**나 데이터베이스 파일, 웹 소스 등이 여기 위치합니다.
|
||||
- **tmp:** 임시 파일 저장소입니다. 누구나 쓸 수 있지만 재부팅하면 보통 사라집니다.
|
||||
|
||||
> [!warning] 서버 관리자가 아니면 잘 안건드리는 폴더
|
||||
- **dev:** 장치(Device) 파일들. 하드디스크, 키보드 등을 리눅스는 파일로 인식합니다.
|
||||
- **proc & sys:** 실제 하드디스크에 저장된 폴더가 아닙니다. **메모리(RAM)에 떠 있는 가상 폴더**로, 현재 실행 중인 프로세스 정보나 커널 설정을 보여줍니다. (용량이 `0`으로 표시되는 이유입니다.)
|
||||
- **run:** 시스템 부팅 이후의 실행 정보를 담고 있는 임시 메모리 폴더입니다.
|
||||
- **boot/:** 리눅스 커널과 부팅할 때 필요한 설정들이 들어있습니다. 여길 잘못 건드리면 부팅이 안 됩니다.
|
||||
- **opt/:** 패키지 관리자가 아닌, 외부에서 가져온 덩치 큰 소프트웨어를 설치할 때 주로 씁니다.
|
||||
- **snap/:** 우분투 전용 패키지 방식인 'Snap'으로 설치된 프로그램들이 머무는 곳입니다.
|
||||
- **srv/:** 서버(Service)를 위한 데이터가 들어가는 곳인데, 요즘은 `/var/www` 등을 더 많이 씁니다.
|
||||
- **lost+found/:** 시스템이 비정상 종료되어 파일 시스템이 깨졌을 때, 복구된 파일 파편들이 모이는 장소입니다.
|
||||
- **mnt/ & media/:** USB나 다른 하드디스크를 연결할 때 사용하는 통로입니다.
|
||||
|
||||
> [!question]
|
||||
> Q. **e**ditable **t**ext **c**onfiguration 이었던거같은데 **왜 여기에 nginx가 설치가 되는거야?** 내생각엔 text configuration이니까 nginx.conf 이런 파일들이 위치하는건 이해가 가는데 실행파일같은건 다른데로 가야하는거 아닌가해서
|
||||
>
|
||||
> A. 정확한 지적입니다! 대일님의 직관이 아주 훌륭해요. 사실 **`/etc` 폴더에 nginx 실행 파일(Binary)이 설치되는 것은 아닙니다.**
|
||||
>
|
||||
> 리눅스의 철저한 **역할 분담** 원칙에 따라 nginx는 여러 폴더에 쪼개져서 저장됩니다. 대일님이 생각하신 "실행 파일은 다른 데 있어야 하지 않나?"라는 의문이 리눅스 구조의 핵심이에요.
|
||||
|
||||
[[리눅스에 Nginx를 설치할 때 일어나는 일들]]
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
id: 유닉스의 철학과 필터 20260407
|
||||
created: 2026-04-07 15:02
|
||||
tags:
|
||||
---
|
||||
![[유닉스 철학 (The Unix Philosophy)#1. 핵심 3원칙]]
|
||||
|
||||
이중에서 함께 작동하도록 만들어라 가 이번 글의 핵심 논점이다.
|
||||
특히 이 원칙을 **유닉스 도구는 모두 필터다** 라고 하는 경우가 있는데 이에 대해 자세히 알아보자.
|
||||
|
||||
|
||||
> [!question]
|
||||
> Q. 유닉스철학중에 모든것은 필터다 라고 했던거때문에 의문이어서 필터는 들어오는 것들을 필터링하고 남은것들을 출력하잖아? 근데 프로그램에는 필터보다는... 함수..? 라고 하는게 더 맞지않아?
|
||||
>
|
||||
> A. 정말 예리하고 훌륭한 통찰입니다! 현대적인 프로그래밍 관점에서 보면 **함수(Function)**라는 표현이 훨씬 익숙하고 정확하게 느껴지실 거예요.
|
||||
>
|
||||
> 하지만 유닉스 철학에서 굳이 **필터(Filter)**라는 단어를 선택한 데에는, 데이터를 대하는 아주 독특한 철학적 이유가 있습니다. 함수와 필터의 차이를 통해 그 속뜻을 풀이해 드릴게요.
|
||||
>
|
||||
|
||||
### 1. 함수 vs [[필터(Filter)]]: 관점의 차이
|
||||
|
||||
두 개념은 수학적으로는 비슷하지만, **데이터를 바라보는 태도**가 다릅니다.
|
||||
|
||||
- **함수 (Function):** "입력을 받아서 계산을 수행하고 결과를 반환한다." (수학적, 논리적 실행에 집중)
|
||||
|
||||
- **필터 (Filter):** "끊임없이 흐르는 데이터의 강물(`Stream`) 속에서, 내가 원하는 것만 남기거나 형태를 바꾼다." (데이터의 흐름과 변형에 집중)
|
||||
|
||||
|
||||
유닉스 제작자들은 프로그램을 독립적인 섬(함수)으로 보지 않고, **데이터라는 액체가 통과하는 파이프라인의 한 구간**으로 보았습니다. 그래서 '[[필터(Filter)]]'라는 용어를 쓴 것이죠.
|
||||
|
||||
### 2. 필터의 진짜 의미 (단순한 제거 그 이상)
|
||||
|
||||
말씀하신 대로 필터는 '걸러내는 것'을 의미하지만, 유닉스 철학에서는 그 의미를 더 넓게 확장합니다.
|
||||
|
||||
- **선택 (Selection):** 조건에 맞는 데이터만 통과시킴 (`grep`)
|
||||
|
||||
- **변형 (Transformation):** 데이터의 형식을 바꿈 (소문자를 대문자로, CSV를 JSON으로 등)
|
||||
|
||||
- **정렬 (Sorting):** 순서를 바꿈 (`sort`)
|
||||
|
||||
- **축약 (Reduction):** 데이터를 합치거나 개수를 셈 (`wc`)
|
||||
|
||||
|
||||
이 모든 행위를 **입력 스트림을 가공하여 출력 스트림으로 내보내는 행위**로 보고 '필터'라고 부르는 것입니다.
|
||||
|
||||
### 3. 왜 '함수' 대신 '필터'라고 했을까? (유연성 때문)
|
||||
|
||||
함수는 호출하기 위해 **매개변수 타입, 반환 타입** 등을 엄격하게 맞춰야 합니다. 하지만 유닉스 필터는 오직 **텍스트(Text)** 라는 공통 인터페이스만 사용합니다.
|
||||
|
||||
-> Filter 2 -> Output
|
||||
|
||||
- **유닉스의 생각:** "네 내부 로직이 함수든 객체든 상관없다. 그냥 표준 입력(`stdin`)으로 들어오는 텍스트를 받아서 가공한 뒤 표준 출력(`stdout`)으로 던져라. 그러면 우리는 파이프(`|`)로 무한히 연결할 수 있다."
|
||||
|
||||
|
||||
이 **무한한 연결 가능성**이 바로 필터 철학의 핵심입니다.
|
||||
|
||||
## 💡 생각
|
||||
즉, 이런점들 때문에 필터라고 칭한다.
|
||||
1. input도 문자열이고 output도 문자열임.
|
||||
2. 필터링이 반드시 걸러낸다고 생각하지 말고 일종의 변환기 라고 확장해서 생각함.
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
id: 필터(Filter) 20260407
|
||||
created: 2026-04-07 15:32
|
||||
tags:
|
||||
---
|
||||
> [!note] 유닉스 철학에서 말하는 **필터(Filter)**는 단순히 무엇을 걸러내는 장치를 넘어, **데이터의 흐름을 가공하는 독립적인 작업 단위**를 의미합니다.
|
||||
[[유닉스의 철학과 필터]]
|
||||
### 1. 필터의 3대 구성 요소 (표준 스트림)
|
||||
|
||||
필터가 되기 위해서는 입구와 출구가 표준화되어야 합니다. 유닉스는 이를 **표준 스트림(Standard Streams)**으로 해결합니다.
|
||||
|
||||
- **표준 입력(stdin):** 데이터를 받아들이는 입구. 보통 키보드나 앞선 프로그램의 결과물입니다.
|
||||
|
||||
- **표준 출력(stdout):** 가공된 데이터를 내보내는 출구. 보통 화면(터미널)이나 다음 프로그램의 입구로 연결됩니다.
|
||||
|
||||
- **표준 에러(stderr):** 작업 중 발생한 문제를 알리는 별도의 통로입니다.
|
||||
|
||||
### 2. 필터의 주요 작업 유형
|
||||
|
||||
말씀하신 것처럼 단순히 제거만 하는 게 아니라, 데이터를 다음과 같이 주무르는 모든 행위가 필터링에 해당합니다.
|
||||
|
||||
- **선택(Selection):** 특정 조건에 맞는 행만 남기기 (예: `grep "S-OIL" log.txt`)
|
||||
|
||||
- **변형(Transformation):** 데이터의 형식을 바꾸기 (예: 소문자를 대문자로 바꾸는 `tr`, 특정 열만 추출하는 `cut`)
|
||||
|
||||
- **정렬(Ordering):** 순서대로 나열하기 (예: `sort`)
|
||||
|
||||
- **요약(Summarization):** 데이터의 통계를 내기 (예: 줄 수를 세는 `wc`)
|
||||
|
||||
|
||||
### 3. 필터 철학의 강력함: 조합(Composition)
|
||||
|
||||
필터 하나는 아주 단순한 일만 하지만, 이들을 **파이프(`|`)** 로 연결하면 복잡한 문제를 순식간에 해결할 수 있습니다.
|
||||
|
||||
> **예시:** 로그 파일에서 오늘 발생한 오류 개수 찾기 `cat server.log | grep "2026-04-07" | grep "ERROR" | wc -l`
|
||||
>
|
||||
> 1. 파일 읽기(cat) ➔ 2. 날짜 필터링(grep) ➔ 3. 오류 필터링(grep) ➔ 4. 개수 세기(wc)
|
||||
>
|
||||
|
||||
이 과정에서 각 프로그램은 서로의 내부 로직을 전혀 몰라도 됩니다. 오직 **텍스트**라는 공통의 언어로만 소통하기 때문입니다.
|
||||
|
||||
|
||||
> [!note] 결국 필터는 단순한 거름망이 아니라 데이터 변환기로 봐야한다.
|
||||
|
||||
### 1. Input/Output이 모두 문자열(Text)인 이유
|
||||
|
||||
유닉스 철학의 거장 더글라스 맥일로이는 **데이터는 텍스트여야 한다**고 강조했습니다.
|
||||
|
||||
- **범용성:** 텍스트는 사람이 읽을 수 있고, 거의 모든 프로그램이 해석할 수 있는 가장 단순한 인터페이스입니다.
|
||||
|
||||
- **결합의 자유:** A 프로그램의 출력이 텍스트고 B의 입력이 텍스트라면, 두 프로그램이 서로 무엇인지 몰라도 **파이프(|)**로 연결할 수 있습니다.
|
||||
|
||||
- **KISS 원칙의 실천:** 복잡한 바이너리 구조나 특정 객체 타입을 맞출 필요가 없으므로 설계가 극도로 단순해집니다.
|
||||
|
||||
|
||||
### 2. 필터는 곧 변환기(Transformer)
|
||||
|
||||
필터라는 단어에 매몰되지 않고 **변환기**로 확장해서 이해하신 것이 이 철학의 정수를 꿰뚫으신 겁니다.
|
||||
|
||||
- **데이터의 형태 변화:** `CSV`를 `JSON`으로 바꾸거나, `소문자`를 `대문자`로 바꾸는 것도 유닉스 입장에서는 필터링입니다.
|
||||
|
||||
- **데이터의 의미 추출:** 1,000줄의 로그에서 오직 에러 코드만 뽑아내는 것도 변환의 일종입니다.
|
||||
|
||||
- **연쇄 작용:** 변환기(필터)들을 여러 개 이어 붙이면, 마치 공장의 컨베이어 벨트처럼 데이터가 흐르면서 최종 결과물로 가공됩니다.
|
||||
@@ -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 사이에 직접 꽂은 것**처럼 속이는 기술이죠.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
---
|
||||
title: volume
|
||||
---
|
||||
Reference in New Issue
Block a user