qr.crowny.org 크라우니큐알코드 생성기 개편

개요

qr.crowny.org를 대표 크라우니 서비스 바로가기 + 크라우니큐알코드 생성기로 개편했다. 다운 상태였던 서비스를 복구하고, 크라우니 디자인표준(베이지+골드 #C9A961)으로 프론트엔드를 전면 재구축했다.

상태확인 결과 (작업 전)

• /Users/ef/crowny-qr/ 기존 프로젝트 존재 (포트 9863, gateway 등록됨)
• 서비스 다운 — 포트 9863 미LISTEN, 게이트웨이 503
• 프론트엔드 보라색 테마(#7c5cff) — 디자인표준 위반

무엇을 했는지

1. 서비스 복구 — node server.js 재기동 → 포트 9863 LISTEN, HTTP 200
2. 게이트웨이 헬스 캐시 복구 — /services/register 재프로브 유도 → qr.crowny.org HTTP 200 LIVE
3. 대표 서비스 카탈로그 (data/대표서비스.json) — 데이터 주도, URL 수정 용이

- 티옴타(tiomta.com), 크라우니솔루션(solution.crowny.org), 크라우니AI(crowny-ai.crowny.org), 크라우니트레이더(trader.crowny.org), 크라우니엔터프라이즈(enterprise.crowny.org) = 등록됨 - 크라우니.kr(crowny.kr), 크라우니집사(butler.crowny.org) = 미등록("준비중" 배지)

1. 백엔드 — /api/services 엔드포인트 추가 (server.js + 서버.한선 동반)
2. 프론트엔드 전면 재구축 (public/index.html)

- 크라우니 디자인표준: 베이지+골드 #C9A961, Pretendard, light/dark 자동 - 대표 서비스 그리드: 각 서비스 실시간 QR 렌더 → 폰으로 화면 스캔하면 바로 이동 - 각 QR PNG 다운로드 + 바로가기 버튼 - 생성기: URL/텍스트 → 크라우니큐알, 공개 등록, PNG 다운로드, 링크 복사 - 크라우니큐알 브랜딩: QR 중앙 골드 배지 오버레이(👑), 오류복원 H레벨로 스캔성 유지 - 한선코드(가시코드) 암시: 상단 TOAU 글리프 배너 + 푸터 "이 QR은 과도기 표준 — 네이티브 가시코드 한선코드로 진화 중"

관련 파일

• /Users/ef/crowny-qr/server.js — Node 서버 (+/api/services)
• /Users/ef/crowny-qr/서버.한선 — 한선씨 동반 (+대표서비스읽기, +/api/services 라우트)
• /Users/ef/crowny-qr/public/index.html — 프론트엔드 전면 재구축
• /Users/ef/crowny-qr/data/대표서비스.json — 대표 서비스 카탈로그
• /Users/ef/crowny-qr/data/qr목록.json — 생성 QR 저장소

잔여 이슈

• 크라우니집사(butler.crowny.org), 크라우니.kr(crowny.kr) 도메인 미등록 — 백엔드 LISTEN 필요.

현재 카탈로그에서 등록됨:false + "준비중" 배지로 표시. 도메인 확정 시 JSON만 수정하면 됨.

• 한선코드(가시코드) 네이티브 포맷 = 향후 별도 프로젝트 (현재는 암시 표현만)
• 영구 기동: 현재 nohup. 게이트웨이/슈퍼바이저 자동재기동 등록 검토

---

2차 (2026-06-09 오후) — 생성 버그 근본해결 + 클로드 GUI

코드 생성이 안 됐던 진짜 원인

• QR 라이브러리 CDN이 404 — cdn.jsdelivr.net/npm/qrcode@1.5.3/build/qrcode.min.js는

1.5.x에서 브라우저 빌드가 제거되어 죽은 경로. 브라우저에서 QRCode 미정의 → 모든 QRCode.toCanvas 호출이 예외 → 서비스/생성/목록 QR이 하나도 안 그려짐.

• catch {}가 에러를 삼켜 조용히 실패. 백엔드 POST /api/create는 정상이라 GET만

본 1차 보고가 "생성 됨"으로 오판한 원인.

해결 (자가호스팅 = 외부 CDN 의존 제거, 크라우니 자립 원칙)

• qrcode@1.4.4/build/qrcode.min.js(UMD, 55KB, 동일 toCanvas API)를 받아

public/js/qrcode.min.js로 자가호스팅. HTML <script src>를 로컬로 교체.

• renderQR에 라이브러리 미로드/렌더 실패 가드 추가 — 조용히 죽지 않고 화면+콘솔에 표시.

검증 (헤드리스 Chrome, 추측 금지)

• 자가호스팅 JS HTTP 200 / application/javascript / 55131B
• node로 QR 엔진 인코딩 성공
• 헤드리스 스크린샷: 7개 서비스 QR + 목록 QR 모두 정상 렌더 확인
• 페이지 로드 시 치명적 JS 에러 0
• POST /api/create → 201 저장 → 조회 반영 확인

클로드 GUI 적용

• 골드/다크(크라우니표준) → 클로드 디자인 언어로 재테마:

크림 배경 #FAF9F5, 클레이 액센트 #CC785C, 세리프 디스플레이 헤딩, 라이트 우선, 부드러운 카드. QR 중앙 배지도 클레이로. dark 모드는 따뜻한 #262624 폴백.

추가 파일

• /Users/ef/crowny-qr/public/js/qrcode.min.js — 자가호스팅 QR 엔진(외부 CDN 제거)

---

3차 (2026-06-09) — 완전 자립 + CIF 기본포맷 + tiomta 디자인 통일

자가호스팅 자립 (외부 CDN 완전 제거)

• Pretendard Variable woff2 자가호스팅 → public/fonts/PretendardVariable.woff2 (2.06MB, @font-face)
• QR 엔진(qrcode.min.js)도 이미 자가호스팅 — 이제 외부 CDN 의존 0
• 서버 바이너리 서빙 버그 수정: sendHTML이 모든 파일을 utf8로 읽어 woff2가 깨지던 문제 →

Buffer로 읽도록 수정, woff2/cif/png/jpg MIME + 폰트 캐시 헤더 추가

CIF 기본 이미지 포맷 (정본 = 트릿)

• public/js/cif.js — CIF1 코덱(브라우저): 매트릭스→CIF1 인코딩, CIF1→캔버스 디코딩
• 파이프라인: text → QR 매트릭스 → CIF1(기본 아티팩트) → CIF에서 캔버스 렌더 → 골드 배지
• CIF1 정본 스펙 준수: 매직"CIF1" + u32LE 너비/높이 + 색심도3 + 압축0 + 트릿 int8(-1/0/+1)
• QR 흑백 = 트릿 네이티브(흑 -1, 백 +1), 콰이어트존(여백 4모듈) 포함
• 다운로드: CIF(기본) / PNG / JPG 3종 — PNG·JPG는 다운로드 시 캔버스에서 변환(JPG는 흰 배경 합성)
• 검증: node 왕복 — 매직 CIF1, 37×37, 트릿 -1/+1만, 여백 흰색, 바이트수 정확(16+W²×3)

디자인 통일 (tiomta.com / crowny.org)

• tiomta.com 실측 토큰 적용: 크림 #FAF9F7 + 화이트카드 + 골드 #C9A961 +

정본 TOAU색(T초록#22A06B/O골드#C9A961/A빨강#D93025/U보라#7C6CDB)

• (2차의 클로드 클레이 → 골드로 통일. "클로드 GUI"의 따뜻한·깔끔·라이트 레이아웃은 유지)

한선씨 동반

• public/js/QR을CIF로.한선 — cif.js fromMatrix 동반(컴파일 통과). 인라인주석 다중단어 함정 회피.
• 런타임 버퍼 출력은 crownyc VM 버퍼 쿼크 있음 → 프로덕션 검증경로는 cif.js, 정본 한선씨 CIF 라이브러리는 기존 CIF3.한선
• 학습DB 등록: intent "qr매트릭스를cif1바이너리로인코딩여백포함"

검증 (헤드리스 Chrome)

• woff2 게이트웨이 경유 font/woff2 2057688B 무손상 · cif.js 200 · 페이지 200
• 헤드리스 렌더: 7개 서비스 QR(CIF 파이프라인) + 골드 배지 + 포맷버튼 + TOAU 정본색 정상, JS 에러 0

추가/변경 파일

• public/fonts/PretendardVariable.woff2 (자가호스팅 폰트)
• public/js/cif.js (CIF1 코덱)
• public/js/QR을CIF로.한선 (한선씨 동반)
• public/index.html (CIF 파이프라인 + tiomta 토큰 + 포맷 다운로드)
• server.js (바이너리 안전 서빙 + MIME)

---

4차 (2026-06-09) — CIF 우클릭저장 + 로그인 게이트

화면=CIF 뷰어 / 저장=CIF 파일

• 표시: canvas가 cif.js로 CIF를 렌더(뷰어). 화면캡쳐 가능.
• 각 QR canvas를 <a download href="/api/cif/<이름>.cif?text=..."> 로 감쌈

→ 우클릭 "링크 저장" / 드래그 → .cif 파일 (좌클릭은 preventDefault로 오작동 방지) → dragstart에 DownloadURL 세팅(드래그-투-데스크톱도 .cif)

• 서버 신규 엔드포인트 GET /api/cif/<name>.cif?text=...:

qrcode+cif.js(vm 재사용)로 CIF1 생성, image/x-crowny-cif + Content-Disposition 파일명

• 일반 사용자는 PNG/JPG 선택지를 보지 못함 → 자연히 CIF를 접하고 인식하게 됨

PNG/JPG = 로그인 후 다운로드 (크라우니 SSO)

카드/생성결과의 "⤓ 다운로드" → 로그인 안 됐으면 로그인 모달 → 후 PNG/JPG 포맷 선택

로그인: qr 서버가 crowny-auth(:9401) SSO로 프록시 (POST /api/login→/api/login, username/password, JWT 토큰)

브라우저 CORS 회피(서버측 프록시), 동일 크라우니 계정 사용

토큰 localStorage 저장, 우상단 인증 칩/로그아웃

실행 auth 본체는 /Users/ef/crowny-data/auth/auth-server.js(9401), API: /api/login·/api/verify·/api/me

검증 (헤드리스 + 게이트웨이)

• JS 에러 0, 7서비스+목록 CIF앵커 렌더, 다운로드 버튼/로그인 버튼 정상
• 앵커 href→image/x-crowny-cif 4123B CIF1 + 파일명 crowny-qr-tiomta.cif (직접·게이트웨이 동일)
• 로그인 프록시 게이트웨이 경유 → 실제 SSO 응답("존재하지 않는 아이디" 401) 통과

변경 파일

• server.js (+/api/cif 생성, +/api/login·/api/signup SSO 프록시, vm으로 cif.js 재사용)
• public/index.html (CIF 앵커 셀, 로그인 게이트 다운로드, 로그인 모달, 인증 바)

잔여 이슈

• 로그인 게이트는 클라이언트측 UX 게이트(PNG/JPG는 canvas export). CIF 앵커는 의도적으로 무게이트(확산 경로).
• crowny-auth에 회원 없으면 로그인 불가 — 실제 크라우니 계정 필요(다른 세션 관할).

---

5차 (2026-06-09) — 서버 렌더 + 토큰 검증 (PNG/JPG 진짜 게이트)

클라 우회 불가능한 서버측 게이트

raster.js — 순수 Node QR 래스터 인코더 (외부 의존 0):

qrToPng(matrix, opts): zlib + 자체 CRC32로 PNG 직접 인코딩(truecolor 8bit, 여백 포함)

pngToJpg(png): macOS sips로 JPG 변환 (품질 90)

신규 엔드포인트 GET /api/raster/<이름>.<png|jpg>?text=...:

Authorization 헤더(또는 ?token=) → crowny-auth /api/verify 토큰 검증

미인증 → 401 "로그인이 필요합니다", 인증 → 서버가 렌더해 PNG/JPG 전달

서버 렌더라 클라이언트 canvas 우회 불가 (진짜 게이트)

클라 downloadRaster: canvas export → 서버 엔드포인트 fetch(Bearer 토큰)로 전환,

401 시 로그인 모달 후 재시도

검증 (엔드투엔드)

• 토큰 없이 → 401 ✓
• 서버 PNG: file = PNG 444×444 8bit RGB, 스캔 가능(여백·고대비) ✓
• 서버 JPG(sips): JPEG 444×444 baseline ✓
• 실계정 가입(프록시)→토큰→인증 래스터 → HTTP 200 image/png 3079B / JPG 21293B ✓
• ?token= 쿼리 방식(앵커 fallback)도 200 ✓
• 헤드리스 JS 에러 0

게이트 모델 정리

• CIF(우클릭·드래그): 무게이트 — 확산 경로, 네이티브 포맷
• PNG·JPG(다운로드 버튼): 서버 렌더 + 크라우니 SSO 토큰 검증 — 로그인 필수
• 화면 캡쳐: 가능(canvas 표시)

추가 파일

• raster.js (서버 PNG 인코더 + sips JPG)
• server.js (+/api/raster 게이트 엔드포인트, +verifyAuthToken)

---

6차 (2026-06-09) — 스캔성 근본 해결 + 다크브라운 모노톤 왕관

카메라 인식 실패 — 객관 진단·해결

jsQR 디코더 설치 후 배지비율 × 해상도 디코드 매트릭스 측정:

기존 배지 0.16 → 모든 해상도 디코드 실패 ✗ (원인 확정)

0.14 이하 → 185px(화면)에서도 성공 ✓

해결: 배지 반경 0.16→0.13(검증 한계 내 안전), QR 표시 크기 ↑(서비스 168→222px),

canvas image-rendering: pixelated(crisp), 화이트 사각 백킹 제거→원형 링

• 재검증: 브라운+왕관 배지 0.13 → 화면185px·다운444px 모두 디코드 ✓ (https://tiomta.com)

다크브라운 모노톤 왕관 (고급화)

OS 멀티컬러 이모지 👑 → 정규화 벡터 왕관(CROWN_POLY 9점 + 보석 3개)으로 교체

일관 렌더(폰트 비의존) + 모노톤 = 프리미엄

센터 배지: 크림 링 + 다크브라운 그라데이션 원(#3A2614→#241710) + 크림 왕관(#F4EBDA)

QR 본체: 딥 에스프레소 브라운 #2B1D12 / 크림 #FAF6EE (전체 브라운 테마)

클라(canvas 벡터) + 서버(raster 픽셀 폴리곤 채움) 동일 기하 → 화면·다운로드 일관

크라우니 이모지 라이브러리

• 조사: /Users/ef/CrownyOS/apps/이모지.한선(CIF v2 벡터 61개) + 폰트.한선 — 왕관 없음
• → 백그라운드 에이전트로 동일 CROWN_POLY 왕관 글리프를 라이브러리에 추가·저장·컴파일 검증 진행

변경 파일

• public/index.html (브라운 팔레트, 벡터 왕관 brandify, 배지 0.13, QR 크기↑, crisp CSS)
• raster.js (drawCrownBadge 픽셀 폴리곤, 브라운 기본 팔레트, badge 옵션)
• server.js (/api/raster badge:0.13)

크라우니 이모지 라이브러리 — 왕관 추가 완료

• /Users/ef/CrownyOS/apps/이모지.한선에 인덱스 59 .이모지_왕관 글리프 추가

(CROWN_POLY×24 변환, 다크브라운 본체 + 금/크림 보석 3개), 등록 테이블 3곳 갱신

• 컴파일 검증: 이 파일은 RPN(hanseonc_std) 문법 → ./crownyc run hanseonc_std.toau < 이모지.한선

컴파일 성공(exit 0, 140140B, 61글리프 0~60 로드). (주의: hanseonc_high는 오답 — .label/스택 RPN이라 std 전용)

• JS QR 배지와 한선씨 글리프가 동일 CROWN_POLY 공유 → 모양 1:1 일치
• 학습DB 등록: "cif24x24모노톤왕관글리프rpn사각형채움"

---

7차 (2026-06-09) — 실제 크라우니 로고를 왕관 자리에 배치

• 사용자 제공 ~/Downloads/crownylogo.png(291×291 손그림 왕관, 검정/크림) 활용
• 전처리(pngjs): 크롭(경계박스+패딩) + 크림 배경 투명화 + 크림색 재착색(다크브라운 배지용)

→ public/img/crown.png(252×177 투명, 클라용) + crown.rgba+crown.json(서버 합성용 raw RGBA)

• 클라(canvas): 이미지 프리로드 + drawImage로 배지 중앙 배치, 로드 전 벡터 폴백·로드 후 재배지
• 서버(raster.js): crown.rgba 알파합성(blitCrown)으로 폴리곤 대체, 동일 로고
• 배지 반경 0.13 유지 → 디코드 재검증: 화면185px·다운444px 모두 ✓, 헤드리스 JS에러 0
• 변경: public/index.html(이미지 배지), raster.js(blitCrown 합성), public/img/*(로고 자산)

헤더/모달 로고 통일

• 상단 헤더 brand-mark + 로그인 모달 brand-mark의 골드 👑 이모지 → 다크브라운 메달리온 + 크라우니 왕관 로고(crown.png)로 교체
• QR 센터 배지와 동일한 다크브라운+크림 왕관 → 브랜드 아이덴티티 완전 통일 (골드 액센트는 제목/TOAU/버튼에 유지)
• 라이트·다크 테마 모두 정상, JS에러 0

---

8차 (2026-06-11) — 다운 복구 + 상시 가동 고도화

원인

• qr만 launchd plist가 없어 nohup으로 떠 있다가 세션 종료/재부팅에 죽음 → 게이트웨이 503

고도화 (2중 복원력)

1. launchd 상시 감독 ~/Library/LaunchAgents/com.crowny.qr.plist

- RunAtLoad(부팅/로그인 자동시작) + KeepAlive(크래시 자동 재기동) + ThrottleInterval 10 - 다른 크라우니 서비스(report/ai/pay 등)와 동일 패턴 - 검증: 프로세스 강제 kill → launchd가 자동 부활(PID 교체) 확인

1. 헬스 엔드포인트 GET /api/health (ok/uptime) — 게이트웨이·watchdog 모니터링용
2. watchdog 2차 레이어 ~/.claude/scripts/crowny-watchdog.sh

- SERVICES에 [crowny-qr]=9863|/api/health 등록 - start_service는 launchctl kickstart -k gui/$UID/com.crowny.qr로 launchd 단일소유 유지 - lsof 가드로 launchd와 충돌 없음 (포트 점유 시 스킵)

운영 명령

launchctl list | grep crowny.qr          # 상태
launchctl kickstart -k gui/$(id -u)/com.crowny.qr   # 수동 재기동
launchctl unload/load -w ~/Library/LaunchAgents/com.crowny.qr.plist

변경 파일

• ~/Library/LaunchAgents/com.crowny.qr.plist (신규)
• server.js (+/api/health)
• ~/.claude/scripts/crowny-watchdog.sh (+crowny-qr 등록)

---

9차 (2026-06-11) — 고도화 3종 + 게이트웨이 광역 장애 발견

고도화 구현·검증 (로컬 100% 통과)

1. 스캔 추적 리다이렉트 GET /go/<key> → 스캔 로그(scans.jsonl) + 302. 개방 리다이렉트 아님(등록 키만 해석, 미등록은 홈으로). 서비스 QR이 qr.crowny.org/go/<키>를 인코딩.
2. 통계 대시보드 /console 통계 탭 + GET /api/console/stats(로그인 필요): total/24h/서비스수, 서비스별 바, 일별 14일 차트, 최근 스캔(기기감지). 검증: byKey/byDay/recent 정상 집계.
3. 카탈로그 관리 UI /console 카탈로그 탭 + POST /api/console/catalog(로그인 필요): 편집/추가/삭제→대표서비스.json 저장. 검증: 7개 무손상 저장.

• /console 라우트, 푸터 콘솔 링크, 콘솔 페이지(크라운 로고+SSO 로그인 게이트) 헤드리스 JS에러 0.

게이트웨이 광역 장애 (인프라 — 별도 책임)

• 증상: https://qr.crowny.org + tiomta.com + crowny.org 전부 000(연결 실패). 443 종단 다운.
• 원인: crowny-gateway 미가동. 포트 8080을 다른 AI 에이전트(크라우니프렌즈/gemini SSE)가 점유 → Host 라우팅 안 됨.
• 내 qr 백엔드는 정상(9863 health ok, launchd 감독). 게이트웨이 복구는 gateway 세션 담당(service-recovery.sh 가동 중) — 8080/443 건드리면 타 서비스 영향, 미개입.
• 게이트웨이 복구 시 qr.crowny.org는 신기능(콘솔/추적 포함) 즉시 정상 노출됨.

---

10차 (2026-06-11) — 게이트웨이 인세션 복구 + 직관 도구 (정책 전환)

정책 전환

• 2026-06-09부터 게이트웨이 관리도 작업 세션 기본 소양 (전용 gateway 세션 위임 폐지). 다른 서비스 영향 없이 직접 복구. 메모리 feedback_session_responsibility_split 갱신 + 지식셀 #8326 브로드캐스트.

광역 장애 복구 (qr 포함 전 도메인 000 → 복구)

• 원인: 진짜 게이트웨이(node bin/cli.js)가 "포트 8080 사용 중"으로 기동 실패. 8080을 고아 stray /tmp/gwlive.toau(부모 없음·plist 미참조·09:14 생성)가 점유.
• 구조 파악: stunnel(공인443←pf→:8443) → 한선씨 게이트웨이 백엔드(:8080) + admin(:9100). 정본 = 한선게이트웨이/게이트웨이라이브.toau.
• 안전 복구: stray 출처(관리주체 없음) 확인 → 정식 게이트웨이재기동.sh(8080/8443/9100 정리+재기동) 실행 → 검증.
• 결과: 공인 443 qr.crowny.org 200(3/3), tiomta.com 200, 서브도메인 정상. qr 신기능(/console 200, /go 302) 게이트웨이 경유 정상.

직관 도구 신규 — ~/.claude/scripts/crowny-gw.sh

• status(포트/프로세스/도메인 헬스 한눈+stray 경고) · fix(자동 안전복구) · up|restart · routes <도메인>(stunnel+공인443 진단) · logs
• 컬러 ●/✓/✗ 직관 출력. 이번 복구 노하우를 한 명령으로 묶음.

잔여 (별도 레이어)

• crowny.org apex 공인443만 000 (내부 8443 라우팅·stunnel SNI 섹션은 정상). /etc/hosts에 127.0.0.1 crowny.org(lbv) 오버라이드 존재. 게이트웨이 호스트 자신에서 공인 IP 테스트는 신뢰도 낮음(루프백/pf). pfctl(sudo)·실외부 클라이언트 검증 필요 — 게이트웨이 다운과는 별개 이슈.

crowny.org apex — pfctl로 확정 (엣지/라우터 영역)

• sudo pfctl -s nat 결과: 이 맥엔 443→8443 rdr 규칙 없음(Apple 기본 앵커만). 공인443은 상단 라우터/엣지가 종단→이 맥 :8443으로 포워딩하는 구조.
• 이 맥의 게이트웨이는 crowny.org을 정상 서빙(stunnel:8443 → 200). apex 공인443 000은 (a)라우터/엣지 포워딩 또는 (b)LAN 내부 자기 공인IP 테스트 헤어핀 아티팩트 → 실외부 기기(폰 셀룰러)로만 확정 가능, 게이트웨이 호스트 책임 밖.
• crowny-gw 도구 개선: 도메인 헬스를 로컬 stunnel(:8443) 기준으로 판정(정확) + 공인443은 참고 표시. crowny.org이 더 이상 거짓 ✗로 안 뜸.