Compare commits

..

2 Commits

Author SHA1 Message Date
dihwang 6a9544e8d7 Revert "에임에서의 기록 백업"
This reverts commit 4bafee36ee.
2026-04-09 09:54:39 +09:00
dihwang fcfad44d51 Reapply "간만의 공부.. 내용이 많은데 kui-veil 서버가 잘 처리해낼수 있을까?"
This reverts commit 7f3f250ed8.
2026-04-09 09:53:58 +09:00
10 changed files with 324 additions and 321 deletions
+16
View File
@@ -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 서버를 구성해보자
@@ -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 가입을 시도해 보시겠어요?** 가입 후 서버 생성 화면까지 가시면 다음 가이드를 드릴게요.
+60
View File
@@ -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 안탈거같다
+117
View File
@@ -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 네트워크 방화벽 규칙 추가로 해결.
+2
View File
@@ -0,0 +1,2 @@
이 서비스의 핵심 기능을 해줄 weaver 서비스를 구현해야 함.
( 실제 blur 처리를 진행해줄 서비스 )
-3
View File
@@ -13,7 +13,6 @@ tags:
GCE를 한대 빌려서 구축하였음 GCE를 한대 빌려서 구축하였음
![[Pasted image 20260401150036.png]] ![[Pasted image 20260401150036.png]]
원래는 퍼블릭하게 공개되면 안되는 자료들을 블러처리해주는 서버를 만들려고 (kui-veil) 확보한 서버였음 원래는 퍼블릭하게 공개되면 안되는 자료들을 블러처리해주는 서버를 만들려고 (kui-veil) 확보한 서버였음
<<<<<<< HEAD:content/01.Shelf/KUI/kui-vault.md
![[Pasted image 20260401163033.png]] ![[Pasted image 20260401163033.png]]
## 🖥️ Server Information: **kui-veil** ## 🖥️ Server Information: **kui-veil**
@@ -50,5 +49,3 @@ GCE를 한대 빌려서 구축하였음
- **상태 요약:** 펌웨어 날짜가 2026년 2월인 것으로 보아, 시스템이 최근에 업데이트되었거나 생성된 아주 따끈따끈한 환경입니다! - **상태 요약:** 펌웨어 날짜가 2026년 2월인 것으로 보아, 시스템이 최근에 업데이트되었거나 생성된 아주 따끈따끈한 환경입니다!
=======
>>>>>>> parent of 96e0100 (간만의 공부.. 내용이 많은데 kui-veil 서버가 잘 처리해낼수 있을까?):01.Shelf/KUI/kui-vault.md
@@ -1,74 +0,0 @@
---
id: "Gitea & Quartz 배포 자동화 트러블슈팅 20260401"
created: "2026-04-01 13:23"
tags:
---
## 🛠️ Gitea & Quartz 배포 자동화 트러블슈팅 기록
### 1. 문제의 발단: Gitea 경로 변경 (`/git/` 누락)
기존에 설정된 Gitea의 접속 주소가 `/git/` 경로를 포함하고 있었으나, 서버 재설정 과정에서 이 경로가 빠지게 되었습니다. 이로 인해 연쇄적인 문제가 발생했습니다.
- **현상:** Gitea 웹훅(Webhook)이 서버의 수신기(`webhook` 서비스)에 신호를 보내지 못함.
- **원인:** Gitea 내부 리포지토리 설정과 외부 호출 URL이 일치하지 않아 404 에러 또는 연결 거부 발생.
---
### 2. 주요 장애 요인 및 해결 과정
#### 📂 [Level 1] 서비스 실행 실패 (ConditionPathExists)
- **에러:** `webhook.service was skipped because of an unmet condition check`.
- **원인:** 기본 설치된 `webhook` 서비스가 `/etc/webhook.conf` 파일이 있어야만 작동하도록 설정됨.
- **해결:** 서비스 파일(`systemd`)을 수정하여 해당 조건을 삭제하고, 우리가 직접 만든 `hooks.json`을 바라보도록 설정함.
#### 🔑 [Level 2] 인증 에러 (no source for value retrieval)
- **에러:** `500 | error evaluating hook: no source for value retrieval`.
- **원인:** `hooks.json`에는 비밀번호(Secret) 검사 로직이 있는데, Gitea 웹훅 설정에는 비밀번호가 비어 있거나 헤더 이름이 일치하지 않음.
- **해결:** 보안을 위해 Gitea와 서버 양쪽에 동일한 비밀번호를 설정하거나, 테스트를 위해 `trigger-rule`을 삭제하여 문턱을 낮춤.
#### 🚀 [Level 3] 스크립트 실행 환경 문제 (npx & node)
- **에러:** `npx: command not found` 또는 `node: No such file or directory`.
- **원인:** `systemd` 서비스는 사용자 터미널 환경변수(`PATH`)를 읽지 못해 NVM에 설치된 Node.js를 찾지 못함.
- **해결:** `deploy.sh` 상단에 Node.js 실행 파일이 있는 **절대 경로**를 `export PATH`로 직접 주입함.
#### 📉 [Level 4] 자원 부족 및 서버 경직 (kswapd0)
- **현상:** 빌드 시작 시 서버가 급격히 느려지며 접속이 끊김.
- **원인:** Quartz 빌드는 CPU와 메모리를 많이 사용하는데, 512MB~1GB 수준의 낮은 메모리로 인해 스왑(Swap) 현상이 심화됨.
- **해결:** 1. **Swap 확장:** 기존 스왑 파일을 **2GB**로 대폭 확장하여 물리 메모리 부족에 대비함.
2. **우선순위 조정:** 빌드 명령어 앞에 **`nice -n 19`**를 붙여 다른 서비스(Nginx, Gitea)에 영향을 주지 않도록 최적화함.
---
### 3. 최종 자동화 아키텍처 (The "Tight" Setup)
|**구성 요소**|**역할**|**최적화 포인트**|
|---|---|---|
|**Gitea**|소스 관리 및 트리거|`/git/` 경로를 제외한 클린 URL 적용|
|**Webhook**|신호 수신기 (Port 29292)|전용 서비스 등록 및 자동 시작 설정|
|**deploy.sh**|배포 스크립트|**절대 경로 사용**, **로그 파일 기록**, **우선순위 최저 설정**|
|**Swap File**|가상 메모리 (2GB)|`/etc/fstab` 등록을 통한 영구 적용|
---
### 📝 교훈
> **경로(Path)와 환경(Environment)은 언제나 명시적이어야 한다.** > 공짜 서버일수록 수동으로 자원을 배분하고 우선순위를 관리하는 **빡빡한 최적화**가 시스템의 생명줄이 된다.
@@ -1,239 +0,0 @@
---
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 방식으로 안전하게 파일 관리 중.
# 🚀 Gitea & Quartz 도메인 통합 및 서버 설정 가이드
본 가이드는 단일 메인 도메인(`white-smith.duckdns.org`)에서 **Quartz(블로그)**와 **Gitea(Git 서비스)**를 충돌 없이 운영하기 위한 설정법을 다룹니다.
---
## 1. 서비스 주소 설계
동일 도메인 점유 문제를 해결하기 위해 **하위 경로(Path)** 방식으로 서비스를 분리했습니다.
- **Quartz (메인 블로그):** `https://white-smith.duckdns.org/`
- **Gitea (코드 저장소):** `https://white-smith.duckdns.org/git/`
---
## 2. Gitea 설정 수정 (`app.ini`)
Gitea가 `/git/` 경로를 인식하도록 내부 설정을 변경해야 합니다.
- **파일 위치:** `/var/lib/gitea/custom/conf/app.ini` (또는 설치 경로 내 `custom/conf/app.ini`)
- **수정 내용:**
Ini, TOML
```
[server]
ROOT_URL = https://white-smith.duckdns.org/git/
LOCAL_ROOT_URL = http://127.0.0.1:3000/
HTTP_ADDR = 127.0.0.1
HTTP_PORT = 3000
```
> **Tip:** `LOCAL_ROOT_URL`을 추가해야 내부 리다이렉션 시 404 오류를 방지할 수 있습니다.
---
## 3. Nginx 역방향 프록시 설정
`/etc/nginx/sites-available/gitea` 파일을 수정하여 두 서비스를 통합합니다.
Nginx
```
server {
listen 80;
server_name 34.19.79.94 white-smith.duckdns.org;
return 301 https://white-smith.duckdns.org$request_uri;
}
server {
listen 443 ssl;
server_name white-smith.duckdns.org;
ssl_certificate /etc/letsencrypt/live/white-smith.duckdns.org/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/white-smith.duckdns.org/privkey.pem;
# [우선순위 1] Gitea 설정
location /git/ {
proxy_pass http://127.0.0.1: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;
}
# [우선순위 2] Quartz 설정 (메인)
location / {
proxy_pass http://127.0.0.1:8080; # Quartz 실행 포트
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. 권한 관리 및 접근 (etc 경로)
시스템 설정 파일을 편리하게 수정하기 위해 권한을 조정하거나 도구를 활용합니다.
1. **권한 변경 (추천):**
Bash
```
sudo chown -R root:$(whoami) /etc/nginx
sudo chmod -R 775 /etc/nginx
```
2. **포트 확인 명령어:**
Bash
```
sudo ss -tulpn | grep node # Quartz 포트 확인
```
3. **서비스 재시작:**
Bash
```
sudo nginx -t && sudo systemctl restart nginx
sudo systemctl restart gitea
```
---
## 5. 핵심 주의사항
- **Nginx 경로 슬래시:** `proxy_pass http://127.0.0.1:3000/;` 처럼 끝에 `/`가 있어야 `/git/` 경로가 중복되지 않고 올바르게 전달됩니다.
- **Quartz 실행:** Quartz를 `npx quartz build --serve`로 띄운 경우 해당 포트(보통 8080)가 Nginx 설정과 일치해야 합니다.
- **보안:** `/etc` 전체 권한을 `777`로 바꾸지 마세요. 필요한 폴더만 그룹 권한을 부여하는 것이 안전합니다.
@@ -1,5 +1,74 @@
--- ---
id: "유닉스 철학 (The Unix Philosophy) 20260330" id: 유닉스 철학 (The Unix Philosophy) 20260330
created: "2026-03-30 15:20" created: 2026-03-30 15:20
tags: 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)** 나 **함수형 프로그래밍**의 뿌리도 이 유닉스 철학에 닿아 있습니다.
- **유지보수 용이:** 작고 단순한 코드는 고치기 쉽습니다.
- **재사용성:** 잘 만들어진 작은 도구는 여기저기서 다시 쓰일 수 있습니다.
- **확장성:** 새로운 기능을 추가할 때 기존 프로그램을 수정하는 대신, 새로운 도구를 만들어 연결하면 됩니다.
-3
View File
@@ -1,3 +0,0 @@
---
title: 2. 보관함
---