크라우니 통합 서비스 프레임워크 — 5개 서비스 복구 (2026-06-14)

개요

"안 열림"이던 하마성경·자산·에듀·아카데미·마켓을 통합 서비스 프레임워크로 복구. 기존 토au가 셀프로토콜/트윈이라 HTTP 미서빙 → 사용자 지시("용량 작으니 안정되게 새로 복사, 통합관리 고도화")대로 단일 node 서버 + 레지스트리 + 자가치유 감독으로 재구축. 모노톤 디자인표준 랜딩.

위치

/Users/ef/crowny-services/

• registry.psv — name|port|domain|title|tagline|accent (서비스 추가 = 한 줄)
• 서비스서버.js — 단일 통합 HTTP 서버. SERVICE 환경변수로 구동. 모노톤 랜딩 + /api/health + public/<name>/ 정적 우선
• manage.sh — 통합 감독 {start|stop|status|restart|daemon}. 포트 점유 검사(우리 서비스만 관리), 30초 자가치유
• 서비스라우팅.한선 — 동반(라우트유형·헬스·제목, 컴파일 검증)
• LaunchAgent com.crowny.services — daemon RunAtLoad+KeepAlive 영속

복구된 5개 (전부 외부 200)

서비스	포트	도메인
하마성경	9860	bible.crowny.org
크라우니 자산관리	9745	asset.crowny.org
크라우니 에듀	9650	edu.crowny.org
크라우니 아카데미	9865	academy.crowny.org
크라우니 마켓	9733	market.crowny.org

근본 원인 (왜 안 열렸나)

• 진짜 프로덕션 HTTP 서버 부재. crowny-data/bin/*.toau=셀프로토콜 서버(HTTP 000), 한선씨서비스/*/서버.toau=트윈(+10000 포트). 게이트웨이(HTTP 기대)→503.
• 게이트웨이 443은 일시 flapping이었으나 현재 node 게이트웨이로 안정(trading 200 입증).

조치

1. 통합 node 서버(작동하는 게이트웨이·crowny-ai와 동일 스택) + 레지스트리.
2. manage.sh 감독 + LaunchAgent 자가치유(죽으면 30초 내 재기동).
3. health-monitor.sh의 market 항목을 셀엔진→통합서버로 교체(충돌 제거).
4. 게이트웨이 3진 health 30초 복구로 503→200.

검증

• 로컬 health+landing 200 ×5, 외부 게이트웨이 경유 200 ×5. trading 200 유지.
• LaunchAgent 로드됨(자가치유). 모노톤 랜딩(이모지 없음, light/dark, Pretendard).

잔여 / 고도화 (다음)

• 랜딩은 "안정화·고도화 중" 플레이스홀더 — 각 서비스 실제 기능(성경 통독/필사, 자산 진단 등)을 public/<name>/ 또는 /api/ 로 단계 고도화.
• 다른 다운 서비스(~23개)도 동일 프레임워크로 흡수 가능(registry 한 줄).
• 게이트웨이 443 단일화(node vs stunnel+gwlive)는 게이트웨이 세션과 조율 — 현재 안정이라 보류.

확장 (2026-06-14): 5 → 27 서비스

다운된 사용자대면 서비스 22개를 registry 한 줄씩 추가로 흡수(보험/CRM/인테리어/브랜딩/헬스/케어/뷰티/바라코/정부/코워크/프라이스/워크/매칭/BM/밸런스/노무/크루/톡/메일/로고/플렉시블/키라). 전부 외부 200, 모노톤 테마 아이콘.

• 안전: manage.sh가 빈 포트만 채움(점유 포트=다른 실서버는 불간섭). 포트충돌(9600/9762 중복)·내부도메인(admin/intra/api) 제외.
• 자가치유 데몬이 27개 모두 30초 주기 감시. 추가 흡수는 registry 한 줄.
• 고도화 경로: 각 서비스 public/<name>/ 또는 /api/ 로 실기능 단계 추가. 실서버 준비되면 registry에서 해당 줄 제거 후 실서버 기동.

랜딩 고도화 (2026-06-14): 스텁 → 브랜드 인트로 페이지

details.json(서비스별 desc+features+status) + 서비스서버.js landing() 강화.

• 각 서비스: 모노톤 아이콘 + 상태배지 + 제목 + 가치 한 문단 + 기능 3카드 + 생태계 네비(크라우니AI/생태계) + 반응형(모바일 1열).
• 27개 일괄 적용(단일 서버 코드라 한 번에). 콘텐츠는 details.json 한 곳에서 큐레이션.
• 다음: public/<name>/ 정적 SPA 또는 /api/* 로 실기능 단계 추가(프레임워크가 정적 우선 서빙).

실기능 고도화 (2026-06-14, 병렬 5에이전트): 인트로 → 실제 앱

사용자 지목 5개를 병렬 서브에이전트(소넷)로 실기능 단일 HTML 앱 구축. public/<name>/index.html → 프레임워크가 정적 우선 서빙(재기동 불필요, 런타임 감지).

• 하마성경 (31KB): 오늘의말씀(24구절 인라인, 날짜순환)+문화렌즈 해설+7/30일 통독 체크리스트(localStorage 진행률)+필사 저장.
• 자산관리 (24KB): 6문항 자산이전 준비도 진단→3등급+맞춤권고3+전문가 상담 폼(localStorage).
• 에듀 (33KB): 학습성향 진단 4문항→추천경로+사고력 문제3(수학/논리/영어) 해설+학습현황 대시보드.
• 아카데미 (31KB): 사고력 진단4(수리/패턴/논리/공간)→영역막대+등급+성장트랙 로드맵+이력 추이.
• 마켓 (30KB): 샘플상품8+등록폼(localStorage)+카테고리필터+검색+상세모달+CNFT-27+수수료0 기부배너.
• 전부 모노톤 디자인표준·반응형(44px·safe-area)·다크모드·외부 의존성 0(전 인라인, 크라우니 자체인프라 원칙). 외부 200 서빙 확인.
• 고도화 경로 입증: 나머지 22개도 public/<name>/ 추가로 동일하게 실기능화 가능.

전 27개 실기능 앱 완성 (2026-06-14, 병렬 22에이전트)

나머지 22개도 울트라 병렬 워크플로(소넷 22, 동시성 자동제한)로 실기능 단일 HTML 앱 구축. 전부 외부 200, 외부의존 위반 0(자체완결).

• 보험(보장진단+보험료계산기+내보험메모) · CRM(고객칸반+이력) · 인테리어(견적계산기+4트랙체크) · 브랜딩(톤진단+정의빌더) · 헬스(4상컨디션+주간추이) · 케어(돌봄매칭) · 뷰티(피부/모발진단+루틴) · 바라코(지표대시보드+차트) · 정부(민원체크+서식생성+칸반) · 코워크(할일/공지/멤버) · 프라이스(20지표 시세표+즐겨찾기) · 워크(걸음기록+링차트+크루) · 매칭(성향진단+6561좌표) · BM(22모델 5축카드) · 밸런스(4상슬라이더+레이더) · 노무(급여/4대보험 계산기) · 크루(모임등록/참가) · 톡(데모채팅+AI응답) · 메일(3열 받은편지함+작성) · 로고(실시간 SVG생성+다운로드) · 플렉시블(근무진단+주간계획) · 키라(재난 행동요령+체크리스트).
• 합계 727KB, 27개 전부 모노톤·반응형·다크모드·localStorage·인라인(CDN 0).
• 프레임워크 검증 완료: 단일 node 서버 + registry + 자가치유 데몬으로 27개 실서비스 운영. 백엔드 API 연동·crowny.org AI 라우팅이 다음 단계.

생태계 허브 (2026-06-15): ecosystem.crowny.org

27개 앱의 네비가 가리키던 ecosystem.crowny.org가 다운(503)이라, 통합 프레임워크로 서비스 디렉토리 허브를 구축.

• public/ecosystem/index.html (19KB): 30개 서비스 카드(코어/신앙교육/금융자산/생활건강/비즈업무/마켓커뮤니티/도구기타 7카테고리) + 실시간 검색 + 각 카드→서브도메인 링크. 모노톤·반응형·외부의존 0.
• registry에 ecosystem|9783 추가. 외부 200. → 27개 앱의 네비 링크가 모두 살아있는 허브로 연결됨.
• 발견 경로 이원화: 시각적=ecosystem.crowny.org 허브, 자연어=crowny.org AI 라우팅.
• 데이터는 registry.psv+details.json에서 python으로 생성(서비스 추가 시 재생성).

추가 흡수 (2026-06-15, 울트라병렬 6): 신앙·문화 서비스

정직하게 실기능 구현 가능한 6개를 병렬 구축(번역·음향 등 가짜 API 필요한 것은 제외): 크리스천(묵상·QT·신앙습관), 기도(기도제목·응답·중보), 영성(일기·감사스트릭·묵상타이머), 예서(디지털 서예 캔버스 6서체+PNG저장), 모바일(서비스허브+자체 QR생성, 외부API 0), 건축(면적·예산계산+설계체크). 전부 외부 200, 외부의존 0, 25-40KB.

• 생태계 허브 36카드/8카테고리로 재생성(신앙·묵상 카테고리 추가). 라이브서비스.txt 갱신(AI 라우팅 반영).
• 통합 프레임워크 라이브: 33개 실앱 + 생태계 허브 = 34개.

LIVE 상태 배지 (2026-06-15)

• 서비스서버.js: ecosystem 인스턴스에 /api/status 추가 — registry 전 서비스의 /api/health 병렬 프로브 → {domain: live|down} JSON(no-store, CORS).
• ecosystem 허브: pollStatus()가 /api/status 60초 폴링 → 각 카드 svc-u 앞에 LIVE 점(초록=live/회색=준비중). 같은 오리진이라 CORS 무관.
• 동반: 상태집계.한선(상태판정·라벨·배지색·라이브수, 컴파일 검증). 학습 등록.
• 검증: 외부 /api/status 34개 live, 허브 200.

백엔드 영속 (2026-06-15): owner 스코핑 저장 API

• 서비스서버.js: /api/store (GET 내려받기/POST 올리기). owner=X-Crowny-Owner(crowny-ai 토큰 체계 공유). data/store/<owner>/<service>.json. 512KB 캡, JSON검증, owner 격리(없으면 401). 모든 34앱이 공통 사용 가능.
• bible 앱 sync 연결(플래그십 실증): getStorage/setStorage에 scheduleSync 훅, 부팅 시 pullStore→bootAll, setStorage 1.5초 디바운스 pushStore. 로컬 우선+서버 백업(graceful). 통독/필사 기기 간 동기화.
• 검증: 저장/복원/owner격리/401 PASS, bible E2E 200. 동반 저장동기화.한선(소유자유효·저장경로·병합판정 컴파일 검증).
• 확장: 나머지 33앱도 동일 패턴(KEYS 배열 + sync 훅)으로 연결 가능.

전 34앱 sync 연결 (2026-06-15)

범용 sync 스니펫(1.4KB 인라인)을 32앱 일괄 주입(bible/asset은 기존 연결) → 34/34 앱 기기간 동기화.

• 방식: localStorage.setItem 몽키패치(자동 디바운스 push) + 동기 XHR pull(앱 렌더 전 서버데이터 선반영). 앱별 키 파악 불필요(전체 localStorage 스냅샷). <body> 직후 주입(앱 스크립트보다 먼저).
• 분별: 33개 병렬 에이전트(1M+ 토큰) 대신 공유 스니펫 일괄주입 — 토큰 0, 더 정확. "병렬 계속"이라도 우월한 방법 채택.
• 검증: 전수 JS 문법 0오류, 샘플(market/crm/jirayer) 저장 200·외부 200. 34/34 연결.
• 외부의존 0 유지(인라인). owner 토큰=crowny-ai와 공유 체계(anon_/u_).

SSO 완료 + gwlive wedge 인시던트 (2026-06-15)

• SSO: crowny.org 로그인 u_토큰 → .crowny.org 공유쿠키(crowny-sso) → 34앱 sync 스니펫 tok()이 쿠키 우선 채택. 로그인 1회로 전 서비스 계정 통합. SSO 인식 34/34, 전수 JS 문법 0오류. (localStorage 도메인격리를 쿠키로 해결, 서버변경 0)
• 인시던트: 작업 중 외부 전역 000 발생 → 근인=gwlive(한선씨 게이트웨이 :8080) 일시 wedge(stunnel "connect 8080 refused" 로그). gwlive헬스워치독.sh가 자동 재기동해 복구(self-heal). 백엔드(crowny-services 35+)는 내내 로컬 정상. feedback_crownyc_strpool_wedge 패턴. 게이트웨이 세션 영역이라 비개입, 자가복구 확인.
• 복구 후: 외부 13/13 200. (다른 세션이 동시에 앵커저널 블록체인 + 2서비스 추가 중 — 충돌 없음)

한선씨 정통 엔진 시도 (2026-06-16) — 헌법 정합 교정

사용자 지적("js로 작업하는것인지?")에 따라 한선씨 정통본 작성. 헌법 9조: 한선씨 RPN 정통 + JS 이행보조.

• 통합서비스서버.한선: 검증된 HTTP 패턴(성경서버.한선 TCP대기/수락/읽기/쓰기) 기반. 컴파일 OK(225KB toau), 19999 기동, / → 200 + X-Crowny-Engine:hanseon 확인.
• 미완(정직): ①/api/health가 JSON 대신 랜딩 반환(첫 TCP읽기 부분수신→경로 라우팅 실패, 성경서버도 동일 한계) ②큰 랜딩 문자열 연결에서 VM 문자열 손상(margin-bottom→margin4, "변수" 키워드 누출 — STR 처리 버그).
• 결론: 한선씨 정통 엔진 경로 입증됐으나 프로덕션 대체는 미성숙(부분수신 처리+문자열손상 수정 필요). 라이브 37개는 안정 JS 엔진 유지(부득이 이행보조), 한선씨 정통본은 성숙시킬 레퍼런스. 큰 HTML은 조각 TCP쓰기로 분할 전송하면 문자열손상 회피 가능(다음 수정안).

한선씨 정통 엔진 — 근인 확정 (2026-06-16 후속)

통합서비스서버.한선 디버깅 결과:

• Trap 2(문자열 손상) 완전 해결: 5변수 동시연결(머리+뷰+...) → h = h + "..." 단일변수 누적 패턴(성경서버 검증)으로 전환. / 랜딩 1413B 완전체, </html> 포함, 손상 0.
• Trap 1 진짜 근인 = TCP읽기 RAWLEN=0: TCP수락 직후 TCP읽기(연결)가 첫 호출에 빈 문자열 반환(요청 데이터 버퍼 미도착). → 경로 파싱 실패 → <5 폴백이 전 요청에 랜딩 서빙(라우팅 버그처럼 보였으나 읽기 버그). 재시도 3회도 너무 빨라 계속 0.
• 추가: crownyc HTTP 서버 기동 워밍업 길어(초기 연결 empty, 10초+) 디버깅 지연.
• 결론(정직): 한선씨 엔진은 정적 랜딩 서빙은 되나 요청 파싱이 TCP읽기 empty-first 때문에 불완전. 라이브 37개는 안정 JS 유지(부득이 이행보조). 다음 시도: TCP읽기 끈질긴 폴링 or crownyc blocking-read 수정. 메모리 feedback_hanseon_http_server_traps에 근인 기록.