사인팟 · 병원 홈페이지 빌더
컴포넌트 설계코드
링크를 여는 순간 이미 완성된 홈페이지 — 기획부터 컴포넌트화까지 개인 작업 7일
- 문제
- 병원 앱 16곳에 같은 역할의 섹션이 따로 구현돼 약 187개 파일로 흩어져 있었습니다. 이름이 같아도 컨테이너 폭 39가지 · 세로 여백 9가지 · 제목 규칙 10가지로 서로 달랐습니다.
- 결정
- 병원별이 아니라 섹션별로 정리하고 배치가 같으면 하나로 합쳐 색과 문구는 변수로 뺐습니다. 편집 축이 여러 개인 메인 배너만 컴파운드 컴포넌트로 만들었습니다.
- 결과
- 섹션 12종 · 레이아웃 52개. 피그마 대조 52개 중 42개가 ±2px 안으로 일치(나머지 10개는 사유 기록). 메인 배너는 프리셋 4개에서 축 5개 조합 432가지. 기획부터 배포까지 개인 작업으로 7일.
녹화PC 폭(1440px)에서 실제 사이트를 녹화한 영상입니다.
실제 배포된 빌더 화면을 그대로 띄웠습니다. 데모 병원은 가상의 병원입니다.
조립도 · 컴포넌트화
문제 발견
원장님이 직접 고르는 빌더를 만들려면 고를 수 있는 단위부터 있어야 했습니다. 그런데 섹션은 병원 앱마다 따로 구현돼 있었습니다. 앱 16곳에 약 187개 파일이고 메인 배너만 23개 가까이 됐습니다.
같은 이름의 섹션끼리도 같은 디자인이 아니었습니다. 컨테이너 폭이 39가지 · 세로 여백이 9가지 · 제목 규칙이 10가지였습니다.
랜딩: 이미 만들어져 있다
원장님에게 '홈페이지를 만들어 드릴게요'는 할 일처럼 들립니다. 그래서 첫 문장을 '이미 만들어져 있어요'로 정하고 링크를 여는 순간 원장님 병원 이름이 들어간 사이트가 느낌 4종으로 넘어가게 기획하고 디자인했습니다. 병원 이름에서 진료과를 읽어 어울리는 느낌을 먼저 추천합니다.
이 문장이 거짓말이 되지 않으려면 화면에서 무언가를 불러오는 기색이 없어야 합니다. 이미지가 하나씩 채워지거나 회색 틀이 보이는 순간 '지금 만드는 중'으로 읽히기 때문입니다.
- 1차(10-30): 링크를 만들 때 느낌 4종 × 기기 3종을 서버에서 스크린샷으로 찍어 두고 첫 화면에서 바로 보여줬습니다.
- 2차(10-30): 이미지가 다 그려진 뒤에야 기기 전환 모션이 시작되게 기다렸습니다.
- 3차(10-31): 스크린샷과 iframe을 모두 걷어내고 느낌별 사이트 첫 화면을 서버에서 바로 그려(SSR) 기기 폭에 맞게 배치만 바꿨습니다. 섹션의 vw를 cqw로 바꿔 틀 안에서도 실제 사이트와 같게 그려지게 했습니다.
- 4차(11-02): 사진은 첫 화면에서 이미 받았고 배치는 CSS로만 바뀌는데도 기기를 바꿀 때마다 1초씩 스켈레톤이 화면을 가리고 있었습니다. 스켈레톤을 없애고 100ms만 흐려졌다가 바로 보이게 했습니다.
정리 원칙
- 정리 단위는 병원이 아니라 섹션입니다. 배치가 같은 디자인은 하나로 합치고 색과 문구 차이는 변수와 속성으로 뺐습니다.
- 레이아웃마다 메타(이름 · 입력칸 · 샘플 · 피그마 노드)를 한 파일에 정의하고 컴포넌트 등록부는 따로 둡니다. 편집기 옵션 · 입력칸 · QA · 갤러리가 모두 이 한 곳에서 나옵니다.
- 등록부는 메타 목록으로 타입 검사를 받아 하나라도 빠지면 컴파일 단계에서 막힙니다. 메타와 컴포넌트를 나눈 덕분에 편집기는 섹션 52개를 통째로 싣지 않습니다.
메인 배너만 컴파운드
메인 배너는 Root · Overlay · Content · Text · Button · Doctors · ScrollIndicator · BottomEdge로 나눈 컴파운드 컴포넌트입니다. 위치 · 정렬 · 오버레이 · 스크롤 표시 · 하단 모양 · 축 5개를 조합해 432가지가 나옵니다.
피그마의 배너 4종은 프리셋이 되고 원장님이 바꾼 축만 저장합니다. 원장님이 고르는 축과 시안이 정한 수치를 분리한 것입니다.
나머지 11종은 레이아웃이라는 축 하나뿐이라 컴파운드로 만들면 API만 넓어집니다. 그래서 메인 배너에만 썼습니다. 바꾸는 김에 필수 입력인 버튼 문구를 어느 배너도 그리지 않던 버그도 고쳤습니다.
피그마와 맞추기
- Figma MCP의 use_figma로 피그마 104프레임을 JSON과 참조 이미지로 덤프했습니다.
- 같은 레이아웃을 렌더링해 Playwright로 실측하고 ±2px 안이거나 설명 가능한 차이만 통과시켰습니다. 작업 전 0개였던 통과가 52개 중 42개가 됐고 나머지 10개는 사유를 기록했습니다.
- 레이아웃 하나에 에이전트 하나씩 붙여 6개를 각자의 워크트리에서 병렬로 돌렸습니다.
- 피그마 라이브러리 자체도 정리했습니다. 컴포넌트 세트 28개를 점검하고 variant 236곳을 실제로 바꿔 보며 대조했습니다.
- 크기는 clamp와 cqi로 두 앵커 사이를 보간해 공개 사이트 · 편집기 미리보기 · 갤러리 틀 세 곳에서 식 하나로 맞춥니다.
링크와 렌더링
- 원장님은 매직링크(60일)로 들어옵니다. 휴대폰 인증을 빼고 링크가 곧 열쇠가 되게 했고 링크를 열면 병원 이름으로 이미 만들어 둔 사이트가 느낌 4종으로 먼저 보입니다.
- 공개 페이지는 요청마다 저장소를 읽어 서버에서 그립니다(SSR). 공개를 승인하면 다시 빌드하지 않아도 바로 반영됩니다.
- 빌더는 /medical 아래에 따로 배포하고 회사 사이트가 이 경로를 넘겨주는 multi-zones 구조입니다. 공개 주소는 한글 병원명에서 영문 주소를 제안합니다.
- 편집기와 미리보기는 postMessage로 한 프레임에 한 번씩 바뀐 부분만 주고받습니다. 미리보기에서 섹션을 누르면 편집기의 해당 칸이 열립니다.
- 두 창에서 동시에 고치면 버전 검사로 충돌을 감지해 나중 저장을 409로 돌려보냅니다.
배운 점
- '이미 만들어져 있다'는 문장은 카피가 아니라 로딩 경험이 지킵니다. 스크린샷 → 서버 렌더로 바꾸고 기다릴 이유가 없는 스켈레톤까지 걷어낸 뒤에야 그 문장이 성립했습니다.
- 컴파운드는 축이 여러 개일 때만 씁니다. 모든 섹션에 같은 패턴을 쓰는 것보다 필요한 곳 하나에만 쓰는 쪽이 원장님 편집 화면도 단순했습니다.
다시 한다면 피그마 대조보다 데이터 모델을 먼저 맞추겠습니다. 끝까지 맞추지 못한 10개 중 8개가 데이터 모델 문제였습니다.