RCW V5 — 제품 홈페이지
Rhino Curtainwall Plugin(RCW V5) 소개 사이트. 빌드 도구 없는 정적 HTML.
구조
| 파일 | 내용 |
|---|
index.html | 랜딩 — 히어로 / 문제 제기 / 워크플로우 / 버전 비교(Core·Standard·Professional) / 구매 CTA |
modeling.html | 1단계 — Wire Frame → Section → UMD → 구성요소(GS·VT·GR·BP) |
output.html | 2단계 — FabNo → Molist·Cuttinglist → FDwg·FDDS → U2D·UF2D → FDstyle |
contact.html | 문의 폼 |
admin.html | (비공개) 관리자 — 고객·갱신·트라이얼·배포 현황. Supabase 로그인 |
todo.html | (비공개) 내 할 일. 같은 Supabase 계정으로 로그인. 3단계 저장 — todo_state(지금, 브라우저가 씀) · todo_day(하루치 30일) · todo_archive(그 이전 전부, 한 줄). 뒤 둘은 DB 트리거가 만든다 — 브라우저가 꺼져 있어도 남는다. 표·트리거 = docs/supabase-todo.sql |
img/ | 이미지 (사이트 사용분 20개만 git 추적, .gitignore 화이트리스트 참조) |
docs/ | 기획 문서 · 구버전 시안 (사이트에 배포되지 않음) |
원본: C:\std\C#_Utils\RCW_V4_13.3\promo\
다국어
빌드 없이 KO/EN 전환. 각 요소에 data-en 속성을 달면 토글 시 교체되고, 선택은 localStorage['rcw-lang']에 저장된다. 입력 필드는 data-en-placeholder를 사용한다.
<h3 data-en="Easy modeling">쉬운 모델링</h3>
기본 표시는 한국어(HTML에 직접 작성), data-en이 영어. 문구를 고칠 때 양쪽을 모두 수정해야 한다.
로컬 확인
python -m http.server 8000
# http://localhost:8000
file://로 직접 열어도 동작하지만, 배포 환경과 맞추려면 위 방식을 권장한다.
배포
Vercel + GitHub 연동. 프레임워크 프리셋 Other, 빌드 명령 없음, 출력 디렉터리 루트.
vercel.json의 rewrite(/(.*) → /$1.html)로 /modeling.html 대신 /modeling 주소도 열린다.
⚠ 예전에는 cleanUrls: true 였다. 그것은 /a/b.html 을 /a/b 로 리다이렉트하기 때문에
도움말의 폴더 index 페이지(.../1.Elements/index.html)가 /.../1.Elements 로 열리고,
그 안의 상대링크·이미지가 한 단계 위로 풀려 전부 깨진다. 그래서 리다이렉트가 없는
rewrite 로 바꿨다 — 주소는 그대로 두고 파일만 찾아준다(정적 파일이 먼저, 없을 때만 .html 을 붙인다).
도움말 (/help)
플러그인에 들어가는 도움말(C:\std\RCW_V4_13.3\help)을 그대로 복사해 웹에 올린다.
주소는 https://www.beimptech.com/rcw/help 이고 로그인 없이 누구나 볼 수 있다.
새 버전을 발행하면 자동으로 따라간다. 설치본에는 도움말이 함께 들어가므로,
publish-trial.ps1 과 publish-customer.ps1 이 릴리스를 올린 뒤 이어서 사이트 도움말을
같은 판으로 맞추고 커밋·푸시한다(_site-help.ps1 의 Sync-SiteHelp).
-WhatIf 로 돌리면 도움말도 건드리지 않는다.
도움말만 따로 고쳤을 때는 손으로 올린다:
pwsh -File .\publish-help.ps1 # 복사만(확인용)
pwsh -File .\publish-help.ps1 -Commit # 복사 + 커밋 + 푸시(배포)
help\ 안을 손으로 고치지 말 것. 원본은 플러그인 저장소 한 곳뿐이고,
이 스크립트가 robocopy /MIR 로 미러링하므로 손으로 고친 것은 다음 실행 때 사라진다.
도움말을 고칠 때는 도움말 편집기로 원본을 고치고 스크립트를 다시 돌린다.- 편집기·임베디드 파이썬·집필 지침(
*.md)·편집기 백업(*.bak)은 복사에서 빠진다.
help\index.html 은 /help 로 들어온 사람을 프레임으로 보내는 스크립트 생성물이다
(원본에는 없다). 매 실행마다 다시 만들어진다.- 검색 인덱스(
search_index.js)는 생성물이다. 동기화할 때 인덱스보다 새 문서가 몇 개인지 세어
알려 준다 — 숫자가 0 이 아니면 python help/build_search_index.py 를 돌리라는 뜻이다
(편집기로 저장하면 자동으로 만들어진다). 낡으면 사이트에서도 설치본에서도 그 문서가 검색되지 않는다.
남은 작업
3단계 페이지 (미구현)
기획서(docs/홈페이지 계획.txt)는 세 단계를 상정한다.
| 단계 | 주제 | 상태 |
|---|
| 1단계 | 3D 모델링이 얼마나 쉬운가 | modeling.html ✅ |
| 2단계 | 이것으로 무엇을 만들 수 있는가 | output.html ✅ |
| 3단계 | 그래서 어떤 효과가 있는가 | 미작성 |
1·2단계가 "무엇을·어떻게"라면 3단계는 **"그래서 얼마를 아끼는가"**를 다룬다.
기획서에서 뽑은 논지는 다음과 같다.
핵심 주장 — 실수의 비용은 도면 작업 비용보다 훨씬 크다
부품 하나를 잘못 만들어 현장에 배달되면 현장은 즉시 멈춘다.
대기 인력의 인건비는 그대로 지출되고, 장비는 비용만 남기고 철수한다.
일정 지연도 비용이다. 부품 하나가 현장에서 수천 달러의 손실이 된다.
구성안
- 히어로 — 손실은 도면에서 발생하지만, 청구서는 현장에서 날아온다
- 비용 구조 — 수작업 방식의 3대 비용
- 시간: 신중할수록 느려지는 구조 (실수 비용이 크니 천천히 할 수밖에 없음)
- 실수: 사람이 머릿속으로 3차원을 계산하는 데서 오는 누락
- 책임: 실수하면 모든 것이 담당자 책임이 되는 부담
- RCW 적용 후 — 모델이 기준이 되면 무엇이 달라지는가
- 컴퓨터가 분석 → 누락 없음
- 눈으로 확인 가능 → 발행 전에 발견
- 기획서 표현 기준 "90% 정도 해결 가능"
- 조립 단위의 가치 — 단위가 명확할수록 시공이 쉬워지고, 시간·위험도·비용이 함께 줄어든다
- CTA — 트라이얼 / 문의
작성 시 주의
- 구체적 절감률(%)이나 금액은 실제 근거가 있을 때만 쓴다. 근거 없는 수치는 실무자 대상 신뢰를 떨어뜨린다
- "수천 달러" 같은 표현은 기획서의 서술이므로, 사례로 제시하되 보장으로 읽히지 않게 쓴다
- 1·2단계와 동일한 CSS 변수·nav·언어 토글 구조를 재사용한다 (
output.html을 복사해 시작하는 것이 빠름)
