obsidian: 정본 문서에서 히스토리/인시던트 분리 완료

15개 정본 문서에서 날짜별 변경이력, 인시던트 기록, 폐기된 구현 상세를
history/ 디렉토리로 분리. 정본은 현재 상태만 기술하는 백서 형태로 정리.
각 정본에 history 위키링크 추가.

분리된 history 파일 12건:
- apisix git push 500, k3s postgresql migration, apisix→traefik 전환
- netbis DDoS 공격, gitea 이전/분리, usb 2.5g hang + NFS hard mount
- supabase→patroni, apisix etcd 통합/분리, anomaly-detect 재설계
- patroni failover incident, zlambda nixos migration, ops-agents setup

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

history/2026-03-15-apisix-git-push-500.md

@@ -0,0 +1,36 @@
+---
+date: 2026-03-15
+topic: APISIX git push 500 에러 + http-logger 401 에러 해결
+areas:
+  - infra/apisix.md
+  - services/gitea.md
+tags: [history, incident, apisix, gitea, safeline, crowdsec]
+---
+
+## git push 500 에러
+
+### 증상
+`gitea.inouter.com`으로 git push 시 BunnyCDN에서 403 반환 (오리진 500)
+
+### 원인 1 — client_body_temp 퍼미션
+nginx가 큰 POST body(git pack ~20KB)를 `/usr/local/apisix/client_body_temp/`에 쓸 때 퍼미션 거부. 디렉토리 소유자 `nobody` vs APISIX `apisix` 사용자.
+
+수정: `chown apisix:apisix /usr/local/apisix/client_body_temp`
+
+### 원인 2 — chaitin-waf 글로벌 적용
+`chaitin-waf`가 global_rules에 있어서 git pack 바이너리를 SafeLine detector가 파싱 실패 → `mode: block`이면 500 반환.
+
+수정: global_rules에서 `chaitin-waf` 제거, 각 라우트에 개별 적용. gitea 라우트는 git 경로 WAF 제외.
+
+### 교훈
+- SafeLine WAF는 바이너리 프로토콜을 처리할 수 없음 → 해당 경로 WAF 제외 필요
+- global_rules WAF는 예외 처리가 어려움 → 라우트별 개별 적용이 유연함
+
+## http-logger 401 에러
+
+서울 APISIX http-logger가 CrowdSec으로 로그 전송 시 401. `headers.Authorization` → `auth_header` 필드로 수정.
+
+## 참조
+
+- `infra/apisix.md` — 현재 APISIX 설정
+- `infra/crowdsec-safeline.md` — CrowdSec 로그 연동

history/2026-03-24-k3s-postgresql-migration.md

@@ -0,0 +1,72 @@
+---
+date: 2026-03-24
+topic: K3s PostgreSQL 백엔드 이전 (외부 etcd → Supabase → Patroni)
+areas:
+  - infra/k3s-migration.md
+  - infra/infra-hosts.md
+  - infra/postgresql-ha.md
+  - infra/metallb.md
+  - infra/gateway-api.md
+tags: [history, k3s, migration, postgresql, supabase, metallb]
+---
+
+K3s 클러스터를 기존 외부 etcd 백엔드에서 Supabase PostgreSQL(kine)로 전환한 프로젝트. 2026-03-24~26 수행.
+
+## 배경
+
+기존 K3s 클러스터는 hp2(server), kr1(server), kr2(분리됨) 3노드에 외부 etcd(Incus 컨테이너 3개, `http://192.168.9.214:2379`, `http://192.168.9.135:2379`, `http://192.168.9.134:2379`)를 데이터스토어로 사용. 새 클러스터로 전환.
+
+## 변경 사항
+
+### Phase 0: 인프라 구성 (2026-03-24~25)
+- kr2 첫 server 구성, Supabase PostgreSQL 연결
+- cert-manager + 와일드카드 인증서 6개 + Reflector
+- Traefik DaemonSet (hostPort 80/443) + Gateway API
+- APISIX replica 1 (SafeLine WAF 테스트 라우트 1건, Ingress Controller 제거)
+- HAProxy 80/443 → Traefik hostPort 복원
+- Longhorn v1.8.2
+
+### Phase 1~2: kr1 합류 + 서비스 이전 (2026-03-24~25)
+- kr1 server로 합류 → 2-server HA 확보
+- 전 서비스 이전 완료 (NocoDB, Gitea, n8n, ArgoCD, Grafana, SearXNG, SafeLine 등)
+
+### Phase 3: hp2 합류 (2026-03-25)
+- hp2 **agent**로 합류 (server 3대 → server 2 + agent 1 구성)
+- Supabase 커넥션 절약 (agent는 DB 커넥션 불필요)
+
+### Vault jp1 이전 (2026-03-24)
+- jp1 Incus default 프로젝트, `vault` 컨테이너 (Debian 13)
+- Vault v1.21.4 (raft 스토리지, 스냅샷 복원)
+- vault-mcp-server v0.2.0 (Go 바이너리, systemd, port 8080)
+- K3s vault 네임스페이스 → ExternalName 서비스로 전환
+
+### Phase 4: 정리 (2026-03-25)
+- 기존 etcd Incus 컨테이너 폐기 완료
+- 기존 K3s server.bak 삭제 완료
+
+### Phase 5: MetalLB 도입 + 네임스페이스 정리 (2026-03-26)
+- MetalLB L2 도입 (192.168.9.50-59), K3s ServiceLB 비활성화
+- NodePort 전면 제거 → LoadBalancer 전환:
+  - traefik: hostPort 80/443 → LoadBalancer 192.168.9.53
+  - apisix-gateway: NodePort 30233/31137 → LoadBalancer 192.168.9.50
+  - sshpiper: NodePort 31840 → LoadBalancer 192.168.9.51
+  - teleport-cluster: ClusterIP → LoadBalancer 192.168.9.52
+  - argocd-server: NodePort 30080/30443 → ClusterIP (Traefik Ingress)
+  - ironclad/anvil NodePort → 삭제 (오사카에서 서빙)
+- HAProxy 백엔드: 3노드 roundrobin → MetalLB IP 단일 엔드포인트
+- k3s.inouter.com DNS: 3노드 A 레코드 → 192.168.9.53 단일
+- sshpiper 설치, Teleport 설치, api/mcp 네임스페이스 신설
+- ironclad/anvil 네임스페이스 삭제
+
+## 영향
+
+새 클러스터 end state:
+- 컨트롤 플레인: kr1 + kr2, 워커: hp2
+- 데이터스토어: Supabase PostgreSQL(kine), Session mode pooler 5432
+- 이후 2026-04-05에 Supabase → 로컬 Patroni PostgreSQL HA로 재이전
+
+## 참조
+
+- `infra/infra-hosts.md` — 현재 서버/클러스터 구성
+- `infra/postgresql-ha.md` — Patroni HA 구성 (Supabase 후속)
+- `infra/metallb.md` — MetalLB 설정

history/2026-03-25-apisix-to-traefik-routing.md

@@ -0,0 +1,36 @@
+---
+date: 2026-03-25
+topic: 메인 HTTP 라우팅 APISIX → Traefik 전환
+areas:
+  - infra/gateway-api.md
+  - infra/apisix.md
+tags: [history, traefik, apisix, gateway-api, routing]
+---
+
+메인 HTTP 라우팅을 APISIX에서 Traefik으로 전환한 과정.
+
+## 배경
+
+### 전환 이력
+- 2026-03-21: K3s Ingress → Gateway API 전환 (기존 클러스터, Traefik v3.6.9)
+- 2026-03-24: 새 클러스터(kr2)에서 APISIX + Ingress Controller 2.0으로 구성
+- 2026-03-25: 메인 HTTP 라우팅을 Traefik으로 교체
+
+### APISIX 이전 사유
+- Ingress Controller 2.0 초기 시도에서 GatewayProxy 모드 + ApisixRoute CRD 연동 실패 (helm values v1.x 형식 불일치)
+- Gateway API HTTPRoute에 플러그인 개별 적용 방법 없음 → ApisixRoute CRD 필요
+- global_rules를 Ingress Controller가 덮어쓰려는 충돌 발생
+
+## 변경 사항
+
+- Traefik DaemonSet + MetalLB LoadBalancer 192.168.9.53으로 메인 라우팅 담당
+- APISIX는 독립 LoadBalancer(192.168.9.50)로 유지, route 축소 (juiceshop 1건)
+
+### 2026-03-22 장애
+
+CoreDNS NodeHosts에 `gitea.inouter.com → 10.43.205.207`(stale ClusterIP)이 남아 ArgoCD 전체 Gitea 싱크 실패. CoreDNS rewrite 방식으로 교체하여 해결.
+
+## 참조
+
+- `infra/gateway-api.md` — Traefik Gateway API 현재 구성
+- `infra/apisix.md` — APISIX 구성

history/2026-03-31-netbis-ddos-attack.md

@@ -0,0 +1,29 @@
+---
+date: 2026-03-31
+topic: Netbis 도메인 대규모 봇 공격 및 대응
+areas:
+  - services/netbis.md
+tags: [history, incident, ddos, netbis, cloudflare]
+---
+
+## 인시던트
+
+2026-03-31 ~ 04-01 일본 IP에서 집중된 L7 DDoS 공격.
+
+| 도메인 | 3/31 요청 | 4/1 요청 |
+|--------|----------|---------|
+| rss-555.com | 3050만 (threats 1700만) | 3000만 (threats 2300만) |
+| fall-vip.com | 2560만 (threats 1160만) | 1540만 (threats 1000만) |
+| fall-mvp.com | 정상 | 738만 (threats 340만) |
+
+정상 트래픽 일 130~180만 대비 30배 이상 폭주. JP 99%.
+
+## 대응
+
+- Rate Limiting 600 → 120/분으로 강화 (2026-04-05)
+- Super Bot Fight Mode 설정 (2026-04-03, Pro zone 4개)
+- NPM-4 추가 커널/Nginx 튜닝 (2026-04-05)
+
+## 참조
+
+- `services/netbis.md` — 현재 Netbis 보안 설정

history/2026-03-various-gitea-changes.md

@@ -0,0 +1,29 @@
+---
+date: 2026-03
+topic: Gitea 관련 이전/분리/도메인 변경 (3월)
+areas:
+  - services/gitea.md
+tags: [history, gitea, migration, bunnycdn]
+---
+
+2026년 3월 중 Gitea 관련 주요 변경 사항 모음.
+
+## Synology → K3s 이전 (2026-03-15)
+
+Synology NAS(192.168.9.100, SQLite)에서 K3s(PostgreSQL)로 이전 완료. Synology 패키지 중지됨 (데이터 보존 중).
+
+## BunnyCDN Pull Zone 분리 (2026-03-27)
+
+Gitea를 iron-kr에서 **iron-git** (ID 5584382)으로 분리. iron-kr의 `BlockNoneReferrer: true`가 git 클라이언트(Referrer 없음)를 차단하여 git push/pull 403 에러 발생. iron-git은 `BlockNoneReferrer: false`로 설정.
+
+## 도메인 이전 (2026-03-28)
+
+기존 `gitea.anvil.it.com` → `gitea.inouter.com` 완전 교체. 변경 범위:
+- DNS, BunnyCDN Free SSL, K8s HTTPRoute, Helm values, CoreDNS 헤어핀 rewrite
+- ArgoCD 4개 앱 repoURL + 8개 repo secret
+- Gitea Runner, Mailgun credential, 4개 repo CI workflow
+- 컨테이너 이미지 경로 5개 Deployment, 로컬 git remote 6개, Obsidian 문서 7개 등
+
+## 참조
+
+- `services/gitea.md` — 현재 Gitea 구성

history/2026-04-04-usb-25g-hang.md

@@ -0,0 +1,32 @@
+---
+date: 2026-04-04
+topic: USB 2.5GbE 어댑터 절전 hang + NFS hard mount D-state 장애
+areas:
+  - infra/infra-hosts.md
+  - infra/nas-storage.md
+tags: [history, incident, network, nfs, usb]
+---
+
+## 배경
+
+USB 2.5GbE 어댑터(r8152/cdc_ncm)가 Linux USB autosuspend에 의해 절전 모드 진입 후 드라이버 hang 발생.
+
+## 인시던트
+
+kr2에서 NFS hard mount가 죽은 2.5G IP로 D-state 누적되어 로드 2000+ 장애. 서버 먹통.
+
+## 복구
+
+- USB unbind/bind로 즉시 복구
+- kr2: GRUB `usbcore.autosuspend=-1`, udev rule `99-usb-ethernet.rules` (scatter-gather off)
+- NAS: `/usr/local/etc/rc.d/usb-no-suspend.sh` 스타트업 스크립트
+
+## 교훈
+
+- NFS hard mount는 NAS 끊기면 무한 대기 → 서버 먹통
+- 모든 NFS 마운트는 `soft,timeo=50,retrans=3` 필수
+
+## 참조
+
+- `infra/infra-hosts.md` — 2.5G LAN 구성
+- `infra/nas-storage.md` — NFS 마운트 옵션

history/2026-04-05-supabase-to-patroni.md

@@ -0,0 +1,32 @@
+---
+date: 2026-04-05
+topic: K3s 데이터스토어 Supabase → 로컬 Patroni PostgreSQL HA 이전
+areas:
+  - infra/postgresql-ha.md
+  - infra/infra-hosts.md
+tags: [history, k3s, postgresql, patroni, supabase, migration]
+---
+
+K3s kine 데이터스토어를 Supabase Free tier에서 로컬 Patroni PostgreSQL 3노드 HA 클러스터로 이전.
+
+## 배경
+
+Supabase Free tier max_connections=60 제한, 싱가포르 리전 ~70ms 레이턴시. 로컬 PostgreSQL HA로 전환하여 성능/안정성 개선.
+
+## 변경 사항
+
+- Patroni 3노드 구성: postgres-1(hp2), postgres-2(kr1), postgres-3(kr2)
+- etcd DCS 클러스터: etcd-nas(NAS Docker), etcd-hp2(hp2 Incus), etcd-jp1(jp1 Incus)
+- OpenWrt HAProxy에 PostgreSQL frontend/backend 추가 (Patroni REST API `/primary`로 Leader 자동 감지)
+- K3s config: `datastore-endpoint: "postgres://kine:kine@192.168.9.1:5432/kine"`
+- hp2가 control-plane에서 worker(k3s-agent)로 전환
+
+## 영향 / 검증
+
+- K3s API 정상 동작 확인
+- failover 시 HAProxy가 ~3초 내 새 Leader 감지
+
+## 참조
+
+- `infra/postgresql-ha.md` — 현재 Patroni HA 구성
+- `history/2026-03-24-k3s-postgresql-migration.md` — 이전 단계 (외부 etcd → Supabase)

history/2026-04-06-apisix-etcd-consolidation.md

@@ -0,0 +1,33 @@
+---
+date: 2026-04-06
+topic: APISIX etcd 통합/분리 과정 (K3s 내부 → 외부 통합 → K3s 내부 복귀)
+areas:
+  - infra/apisix.md
+  - infra/postgresql-ha.md
+tags: [history, apisix, etcd, k3s]
+---
+
+서울 K3s APISIX의 etcd 백엔드를 K3s 내부 StatefulSet에서 외부 통합 etcd로 이전했다가, 다시 K3s 내부로 복귀한 과정.
+
+## 변경 사항
+
+### 2026-04-06: K3s 내부 → 외부 통합 etcd
+- K3s 내부 apisix-etcd StatefulSet 삭제
+- 외부 통합 etcd(192.168.9.100, 10.100.2.214, 10.253.101.233)로 이전, prefix `/apisix/seoul`
+- 의도: 통합 운영 + 컴포넌트 수 절감
+
+### 2026-04-08: 외부 통합 → K3s 내부 복귀
+- Patroni DCS와 같은 etcd 클러스터 공유 시 장애 전파 위험(Patroni 이슈 → APISIX 라우팅 영향)
+- K3s 내부 `apisix-etcd` StatefulSet 3 replicas 복구 (Bitnami etcd, Longhorn PVC 5Gi x 3)
+- 외부 통합 etcd의 `/apisix/seoul/*` 20개 키 삭제
+- ApisixRoute CRD 사용을 위해 ingress controller도 복구
+
+## 교훈
+
+- Patroni DCS와 APISIX etcd는 장애 격리를 위해 분리하는 것이 안전
+- helm 한 곳에서 etcd + apisix + ingress controller 관리가 운영 일관성 확보
+
+## 참조
+
+- `infra/apisix.md` — 현재 APISIX 구성
+- `infra/postgresql-ha.md` — etcd 사용 현황

history/2026-04-08-anomaly-detect-iterations.md

@@ -0,0 +1,63 @@
+---
+date: 2026-04-08
+topic: anomaly-detect 3차 재설계 과정 (gemma → cohort → agentic Grok-4)
+areas:
+  - infra/anomaly-detect.md
+  - infra/crowdsec-safeline.md
+tags: [history, anomaly-detect, crowdsec, ai, grok]
+---
+
+anomaly-detect 시스템의 3번의 설계 반복과 최종 agentic 구조 확정 과정.
+
+## 1차 구현 (2026-04-08 초반) — gemma4:e4b + stats 파이프라인
+
+per-IP 통계 게이트(count/4xx/5xx/499/distinct paths) → 후보 N개 → ollama gemma4:e4b(Q4_K_M, 8.0B) yes/no 분류. Python이 축을 정의하고 LLM은 판정만 수행하는 구조.
+
+## 2차 구현 (같은 날) — cohort 탐지 추가
+
+`_cohort_path_candidates`, `_cohort_ua_candidates` 등 집단 축 탐지 로직 추가. 여전히 "Python이 탐지, LLM이 분류"라는 본질적 한계 동일.
+
+## 코드 리뷰 수정 2회
+
+### 초기 리뷰 (커밋 d5310f0)
+- LAPI POST 실패 시 dedup 선기록 버그 수정
+- XFF CSV 파싱 버그 수정 (`extract_client_ip()` 헬퍼)
+- 사설망/Tailscale 필터 개선 (`ipaddress.ip_address().is_private`)
+- dedup.json 원자적 쓰기 (`tempfile` + `os.replace`)
+
+### 2차 리뷰 (커밋 b0e3c68) — High 5건 / Medium 4건
+- H1: `events_count` 프로토콜 오용 → sample 10건을 events에 풀어서 넣기
+- H2: `limit=20000` raw 로그 pull → `| stats by (remote_addr)` 서버측 집계
+- H4: prompt injection via path → `json.dumps` + 경고 삽입
+- H5: `num_predict=80` 한국어 truncation → 256
+- M1~M4, M7: start_at/stop_at, 파일 핸들 누수, ratio에 499 포함, set cap, housekeeping
+
+### 남은 설계 이슈
+- H3: 분산 봇넷 대비 게이트 사각지대 (per-IP 게이트의 한계)
+
+## 3차 재설계 — agentic 구조 (최종)
+
+사용자 원래 의도 "시계열 DB를 AI에 연결하면 AI가 알아서 찾는다"에 부합하도록 전면 재설계. OpenRouter `x-ai/grok-4-fast`에 tool 2개(logsql_query, ban_ips)만 노출하는 agentic 구조.
+
+### 모델 벤치마크 결과
+
+| 모델 | 턴 | 비용 | 결과 |
+|------|-----|------|------|
+| x-ai/grok-4-fast | 4 | $0.0036 | 정답 |
+| qwen/qwen3-235b-a22b-2507 | 7 | $0.0012 | 정답 |
+| google/gemini-2.0-flash-001 | 10(max) | $0.0026 | 결론 없음 |
+| deepseek/deepseek-chat-v3.1 | 10(max) | $0.0127 | 결론 없음 |
+
+### E2E 검증
+- VictoriaLogs에 270 rows 주입, Grok-4-fast 5턴에 31개 공격 IP 정확 식별, 정상 IP 0건 ban
+- DRY_RUN=0 활성화, 실운영 개시
+
+## 전임자 폐기
+
+- `ddos-detect` (Go, jp1 crowdsec 컨테이너, 60s 폴링, Claude CLI sonnet 호출) — 60s 폴링 + 동기 Claude CLI 구조 한계로 폐기
+- 제거 항목: `ddos-detect.service`, Go 바이너리+소스, `ddos-detect.sh`, `extract_behavior.py`, `ddos-logs/`
+
+## 참조
+
+- `infra/anomaly-detect.md` — 현재 agentic 구조
+- Gitea: `kaffa/anomaly-detect`, `kaffa/ddos-detect`(보존)

history/2026-04-08-patroni-failover-incident.md

@@ -0,0 +1,39 @@
+---
+date: 2026-04-08
+topic: Patroni failover 사고 — pgcat/nocodb/outline read-only 에러
+areas:
+  - infra/postgresql-ha.md
+  - infra/outline.md
+tags: [history, incident, patroni, postgresql, pgcat, nocodb, outline]
+---
+
+Patroni failover 발생 후 pgcat, NocoDB, Outline이 구 primary IP를 hardcoded 참조하여 read-only 에러 발생.
+
+## 배경
+
+pgcat의 각 pool `shards.0.servers`에 Patroni 노드 IP(10.100.2.5 등)가 직접 박혀 있었음. Outline의 `DATABASE_URL` Secret도 노드 IP 직결.
+
+## 인시던트
+
+Patroni failover 발생 → postgres-1(10.100.2.5)이 replica로 강등 → pgcat와 Outline이 옛 primary를 계속 가리킴:
+- NocoDB: 마이그레이션 시 `cannot execute UPDATE in a read-only transaction` → CrashLoopBackOff ~4시간
+- n8n: 마이그레이션 없어 표면화되지 않았으나 동일 잠재 문제
+- Outline: API 500 반환 (`apiKeys.lastActiveAt` UPDATE 실패 → 인증 자체 깨짐)
+
+## 복구
+
+### pgcat
+`db/pgcat-config` ConfigMap의 모든 pool servers를 HAProxy 단일 백엔드(`192.168.9.1:5432`)로 변경.
+
+### Outline
+`outline-secrets` Secret의 `DATABASE_URL`을 `postgresql://outline:outline@192.168.9.1:5432/outline`로 변경 + rollout restart.
+
+## 교훈
+
+- Patroni 사용 애플리케이션의 DB endpoint는 항상 OpenWrt HAProxy(`192.168.9.1:5432`) 또는 pgcat 경유. 노드 IP 직접 박지 말 것.
+- 변경 시 `kubectl get secret -A -o json | jq` 검수로 나머지 Patroni 사용자도 일괄 확인
+
+## 참조
+
+- `infra/postgresql-ha.md` — pgcat 단일 백엔드 구조
+- `infra/outline.md` — Outline 구성

history/2026-04-08-zlambda-nixos-migration.md

@@ -0,0 +1,42 @@
+---
+date: 2026-04-08
+topic: zlambda (구 sandbox-tokyo) Debian → NixOS 전환
+areas:
+  - infra/zlambda.md
+  - services/netbis.md
+tags: [history, zlambda, nixos, linode, migration]
+---
+
+Linode Tokyo VM `sandbox-tokyo`를 Debian 12에서 NixOS 25.05로 교체하고 호스트명을 `zlambda`로 통일.
+
+## 배경
+
+누군가 nixos-anywhere를 시도하다가 14시간째 nixos-installer에 멈춰 있었음. 이전 Debian 디스크는 wipe되어 원본 데이터 모두 손실.
+
+## 설치 과정
+
+1. 첫 시도 실패: sda(512MB)/sdb(50GB) 순서 뒤바뀜 + 1.9GB RAM에 swap 없이 nixos-install → OOM-lock
+2. 회복: Linode `POST /linode/instances/{id}/rebuild`로 Debian 12 클린 설치 → 디스크 순서 정상화
+3. nixos-anywhere 실행: disko + grub `mirroredBoots` 중복 오류 → `boot.loader.grub.devices`를 빼고 disko 자동 설정 사용
+4. 부팅 안 됨: Linode kernel `linode/grub2`가 NixOS grub.cfg 인식 못함 → LISH 콘솔에서 확인
+5. 해결: Configuration profile kernel을 `linode/direct-disk`로 변경 → 정상 부팅
+6. Tailscale: 옛 device(100.79.87.48) 삭제, 새 device 가입, 이름 회수
+
+## 후속 변경 (같은 날)
+
+- Gitea 리포지토리 `kaffa/nixos-infra` (private) 생성, deploy key 등록
+- 호스트명 `sandbox-tokyo` → `zlambda` 통일 (NixOS, kernel, Tailscale)
+- macbookair ed25519 키 영구 등록
+- 커널/sysctl 튜닝 (BBR, conntrack, inotify 등)
+- APISIX + etcd를 NixOS oci-containers로 재선언하여 기동
+
+## 제거된 서비스
+
+sandbox-tokyo에서 기존 운영하던 서비스들이 NixOS 전환으로 제거:
+- vault-prod, wg-easy, nginx-tcp-proxy, microsocks(socks5-v4), tlsproxy, Caddy
+- APISIX/etcd는 NixOS oci-containers로 재가동
+
+## 참조
+
+- `infra/zlambda.md` — 현재 구성
+- `services/netbis.md` — Netbis DR APISIX

history/2026-04-09-ops-agents-setup.md

@@ -0,0 +1,32 @@
+---
+date: 2026-04-09
+topic: Ops Agents (Heimdall/Syn) 구축 및 heimdall tofu 재생성
+areas:
+  - ops-agents/overview.md
+  - infra/infra-hosts.md
+tags: [history, ops-agents, heimdall, syn, tofu]
+---
+
+내부 운영 에이전트 시스템 구축 과정.
+
+## Heimdall 재생성 (2026-04-09)
+
+- 이전: 2026-03 수동 생성 (root 유저, kr1 default project, IP 10.100.3.92)
+- 이후: 2026-04-09 tofu 재생성 (kaffa 유저, kr1 ops project, IP 10.100.3.108)
+- OpenTofu 관리: `kaffa/ops-agents-tofu/heimdall` 모듈
+- 메모리/CPU limit: 8GiB/4core
+- 재생성 시 `~/.claude` 전체 백업/복원
+
+## Syn 신규 생성 (2026-04-09)
+
+- hp2 ops 프로젝트, IP 10.100.2.173
+- OpenTofu 관리: `kaffa/ops-agents-tofu/syn` 모듈
+- 엣지 레이어 전담 (BunnyCDN, SafeLine, APISIX, Cloudflare)
+
+## Vault 접근 게이트웨이 프로토콜 도입 (2026-04-09)
+
+에이전트가 Vault에 직접 접근할 수 없도록 kappa 게이트웨이 ASK 프로토콜 도입. `.mcp.json`에서 vault 항목 완전 제거.
+
+## 참조
+
+- `ops-agents/overview.md` — 현재 에이전트 구성