크라우니 게이트웨이 독립 도구화 + 한선씨 현황 + nginx 비교 + 사용법 선언

개요

게이트웨이를 "모든 세션이 입력·트리거만 주면 작동하는 독립 도구"로 정착시켰다. 한선씨 구현 현황을 정밀 감사하고, nginx와 실측 비교하고, 단일 정본 CLI(gw)와 사용법 선언서를 만들었다.

무엇을 했는지

1. 현황 그라운딩(병렬 2 에이전트, 가드레일 주입)

- 한선씨 인벤토리: 라이브 임계경로 = org.crowny.gateway→start.sh→게이트웨이통합.한선→crownyc run gwlive.toau(:8080), stunnel TLS 종단(:443/:8443). node bin/cli.js 휴면 확인. - nginx 실벤치 + 기능 매트릭스.

1. 한선씨 구현 현황(감사)

- ✅ 한선씨: HTTP 라우팅/리버스프록시/정적(파일소켓전송 fork0)/SPA/WS/보안헤더/ACME/301/stunnel conf생성(SNI생성기.한선)/4상헬스. - ⚠️ 외부: TLS 종단(stunnel — crownyc에 TLS 핸드셰이크 네이티브 없음), gzip. - 🔶 미배선: CORS/RateLimit/응답캐시/Shield(WAF)/접근로그 — lib/에 한선씨 구현 존재하나 라이브 통합.한선이 import 안 함. 배선만 하면 회복 = 최고 가성비 갭.

1. nginx 비교(실측, ab -n 500 -c 5 localhost)

- 한선씨 게이트웨이: 84.65 RPS, 0 실패, ~9–12ms/req (단일 accept 루프, Connection:close). - nginx 단일워커: 14,100 RPS, 0.07ms/req. → 실측 격차 ≈ 167배. - 해석: 인터프리터 VM vs C + 단일스레드 vs 멀티워커. 단, 트래픽 규모상 정상상태 병목 아님(체감병목=콜드스타트). 실위험=단일스레드 동시버스트 큐잉. - 우위: gateway.yaml 단일 SSOT + gw add 무설정 자동결선, 4상 자가치유 워치독, ACME/SPA 내장.

1. 단일 정본 CLI gw (/Users/ef/crowny-gateway/gw)

- 검증된 정본 작업만 래핑(새 로직 없음): 재기동=launchctl kickstart, 라우트추가=crowny-ports.sh set, 규칙동기화/연계현황/그림자검증=게이트웨이고도화.sh. - 명령: status / restart / reload / doctor / stop / add / validate / sync / wire / verify / bench / logs / help. - 한선씨 동반 게이트웨이도구.한선(4상 헬스 판정 — 티/옴/타/음)을 gw status·doctor가 실제 호출(장식 아님). 4케이스 검증 완료.

1. 사용법 선언서 한선게이트웨이/게이트웨이도구-사용법.md — 모든 세션 단일 참조점(토폴로지·현황·nginx실측·독립화 로드맵).

1. CLAUDE.md 갱신 — gw를 정본 진입점으로 등록, 레거시 node 경로 휴면 표기.

독립화 로드맵 (우선순위)

1. lib 고급기능 라이브 배선(CORS/RateLimit/Shield/캐시) — 낮은 난도, 최고 가성비 ⭐
2. 동시성(SO_REUSEPORT N 프로세스) + keep-alive — RPS·버스트 근본 해소
3. start.sh 한선씨화
4. python 인라인 제거(cert-manager 등), gateway-watchdog.sh 퇴역
5. TLS 종단 한선씨화 — 최상 난도(다년), 차선=stunnel 수용
6. gzip 한선씨

관련 파일

• 정본 CLI: /Users/ef/crowny-gateway/gw
• 한선씨 동반: /Users/ef/crowny-gateway/한선게이트웨이/게이트웨이도구.한선 (→ /tmp/gwtool.toau)
• 사용법 선언: /Users/ef/crowny-gateway/한선게이트웨이/게이트웨이도구-사용법.md
• 정본 규칙: 한선게이트웨이/게이트웨이운영표준.md · SSOT gateway.yaml
• 라이브 소스: 한선게이트웨이/게이트웨이통합.한선

잔여 이슈

• 죽은코드 정리(루트 레거시 .toau, gateway.yaml.bak ×7, stunnel conf 백업, python+__pycache__, monitor-server.js.disabled) — 승인 후 일괄.
• 로드맵 1(lib 배선)·2(동시성)는 라이브 영향 → gateway 세션 그림자(8081) 검증 후 승인 컷오버.
• gw stop/restart는 공유 인프라(84+도메인) → 승인 가드 내장.

---

추가 작업: 로드맵① Shield(WAF) 라이브 배선 + JS회귀 복원 (2026-06-22)

Shield(WAF) 한선씨 배선

• 신규 한선게이트웨이/게이트웨이방어코어.한선 — 악성요청인가(요청,경로)/차단응답(). 스캐너/봇/traversal/SQLi/비정상메서드를 백엔드 전에 403 차단. IP 불필요(stunnel 종단 우회), 경로/메서드 시그니처 기반.
• 게이트웨이통합.한선 _요청처리 (0.5)에 배선(ACME 다음, 라우팅 전). ACME 챌린지는 화이트리스트.
• 검증: 격리 11/11 + 그림자8081 통합 + 라이브 HTTPS 공개경로(wp-login/.git/.env/xmlrpc/phpunit/TRACE → 403, 정상 200).

JS 회귀 복원 (예상 못 한 발견)

• 컷오버 시도 중 라이브 :8080이 한선씨가 아니라 레거시 node bin/cli.js start(좀비) 점유 발견. 한선씨 org.crowny.gateway는 바인딩 실패로 not running. 2026-06-15 컷오버가 회귀해 있었음.
• crowny-infra watchdog 복구 SSOT(crowny-stack.yaml)는 이미 한선씨(게이트웨이재기동.sh) — node를 살린 게 아니라 옛 좀비가 점유. stale 참조(watchdog.한선:164, cli.js:133) 한선씨 kickstart로 정정.
• 스왑: node kill → kickstart → 한선씨+shield 바인드(~3s).
• 함정: 빠른 반복 kickstart가 gwhealth 워치독+KeepAlive와 경합 → 다중 crownyc 인스턴스 → 전역503 wedge(LISTEN하나 전프록시 503, 백엔드 200). 클린복구=pkill -f '[g]wlive.toau'+단일 kickstart+settle. 복구 후 60s 단일 인스턴스·200 안정 확인.

결과

• ✅ 라이브 :8080 = 한선씨 단일 인스턴스 + Shield 발효. 4상 티. https crowny.org/docs 200.
• ⚠️ 별개 발견: https://cowork.crowny.org → 000 (stunnel :8443 SNI 핸드셰이크 실패, :8080 백엔드는 200). 이번 스왑과 무관한 기존 stunnel cert/SNI 갭 → cert-manager 별도 처리.

메모리

• feedback_gateway_js_reclaim_and_swap(신규), reference_gateway_gw_cli(Shield 라이브 갱신).

---

추가 작업: cowork.crowny.org HTTPS 000 수정 (2026-06-23)

근본 원인

• https://cowork.crowny.org → 000. stunnel이 제시한 cert(crownybus.com 슬레이브, CN=abti)의 SAN에 cowork 미포함 → curl 호스트명 검증 실패(openssl은 체인만 검증해 통과). 블록명 [s49-abti-cowork]이나 cert는 abti만 커버.
• 원인: certbot 전체세트 재발급 시 cowork가 ACME 실패로 SAN에서 드롭됐는데 stunnel 블록은 옛 cert 유지.

수정 (전용 cert, 슬레이브 97-SAN 무접촉)

1. certbot dry-run → 실발급: cowork.crowny.org 전용 cert(--cert-name cowork.crowny.org, webroot ACME). SAN=cowork, 만료 2026-09-21, renewal conf 자동갱신.
2. stunnel-live-443.conf + stunnel-live.conf 의 cowork 블록 cert/key를 전용 cert로 awk 재배선(블록 한정).
3. stunnel SIGHUP(443=PID, 8443=PID 각각, 프로세스 무중단). 백업 .bak-cowork-.
4. 검증: https cowork→200(000→200), 제시 CN=cowork.crowny.org, 회귀 없음(crowny.org/docs/abti 200), cowork shield wp-login→403.

⚠️ 발견: SNI생성기.한선 불완전

• 생성기는 /tmp/*.gen2.conf에만 쓰고 라이브 무접촉(수동 승인)이나, 현재 195 FQDN→94 블록만 생성(라이브 171블록). 슬레이브 cert 축소로 77 도메인이 master폴백. gen2 라이브 승격 시 77 도메인 HTTPS 깨짐 → 생성기는 현 상태로 재생성 도구 부적합, 라이브 stunnel conf가 hand-maintained SSOT.
• 전용 cert 도메인(value, cowork)을 SNI생성기.한선 우선순위/lineage경로/SAN초기화/lineage_san에 등록(생성기 수리 시 유효). 생성기 195→94 breakage 자체는 별도 미해결 백로그.

메모리

• feedback_stunnel_dedicated_cert_fix(신규).

---

추가: 한선씨 최적성 + 4상균형3진 적용 검토 (2026-06-24, 병렬 3에이전트)

검토 결론

• 한선씨 최적성: 정적 200요청당 fork 4~5회(본문 cat 후 폐기, A1) / 프록시응답 전체치환 왕복2회(A2) / opcode297(stat) 키워드 미배선=최고ROI 무fork화 / WS터널 소켓받기 타임아웃 없음(C3) / 포함 >=0 누락(C1).
• 4상균형3진: 라이브 파이프라인 4상 0건, 진짜3진은 미배선 lib/트라이던트에만. 최우선=업스트림 프록시 4상(Ti/Om/Ta+빠른실패/Um). 과설계 경고: 캐시/피어/재시도 4상화 금지.
• SNI생성기: 그룹루프 cowork/value 분기 누락(전용cert 증발)+san_value 미초기화. 94 vs 171은 cert 일시축소+stale 블록 15개.

적용 완료 (저위험)

• C1: 게이트웨이통합.한선 포함(경로,"..")>=0 하드닝. 컴파일 OK, 자동재기동 시 발효.
• 건강.한선 4상 통일(도구.한선 기준: 음death/타wedge/옴부분/티정상, 음·타 재기동).
• gw doctor clean_recover()(pkill 전체+단일 kickstart+settle) — 다중인스턴스 wedge 자동회피.

백로그 (그림자 검증+컷오버 승인 필요, 우선순위)

1. opcode297 키워드 배선(crownyc/hanseonc_high 재빌드) — 정적 fork 0
2. A1 정적경로 cat 제거 — fork 4~5→1~2
3. 4상 프록시 B-1 — 죽은백엔드 빠른실패(단일스레드 큐잉 해소)+철학 쇼케이스. 상태맵은 메모리마커 경계 밖 필수
4. C3 WS 소켓 타임아웃(WS 46도메인)
5. A2 단일패스 / RateLimit 라이브배선 / 헬스게이트 Om붕괴 / 매직넘버
6. SNI생성기 디렉토리스캔 재작성(별개, /tmp 전용)

상세: 메모리 project_gateway_optimization_backlog.