• • General

핸들리(Handly) 웹사이트 해부: 노코드 빌더로 만든 B2B SaaS 랜딩의 한계와 가능성

#웹디자인 #프론트엔드 #UX 분석 #핸들리 #imweb #노코드

참고 안내 — 이 글은 외부에서 관찰 가능한 정보(DOM 구조, HTTP 응답, 공개 에셋 등)를 기반으로 작성된 개인적인 기술 분석이며, 학습과 참고 목적으로 제공됩니다. 내부 소스 코드에 직접 접근한 것이 아니므로 실제 구현 구조와 다를 수 있습니다. 분석 대상 사이트의 공식 입장과는 무관합니다.

📌 3줄 요약
  • 핸들리는 imweb(아임웹) 노코드 빌더 위에 커스텀 코드 위젯을 적극 활용해 B2B SaaS 랜딩 페이지를 구현했다.
  • 퍼플 계열 브랜드 컬러(#8d64f8, #7D4CFC)와 Pretendard 폰트로 깔끔한 시각 정체성을 구축했지만, 노코드 플랫폼의 구조적 한계로 HTML 1,106KB, 렌더 블로킹 리소스 26개 등 성능 부채가 존재한다.
  • GTM, Hotjar, Datadog RUM, Mixpanel, Channel.io까지 5겹 분석 스택을 탑재해 데이터 중심 의사결정에 투자하고 있다.

첫인상: 핸들리를 처음 열었을 때

핸들리 메인 페이지

핸들리 메인 페이지 — 데스크톱 1440×900

상단에 연보라색 프로모션 배너 “일정을 보기 좋게, 찾기 쉽게. 지금 확인해 보세요 👉“가 눈에 들어온다. 히어로 영역은 “공간을 다루는 새로운 방식”이라는 72px 대형 헤드라인과 함께 “문의하기”, “무료체험” 두 개의 CTA 버튼이 중앙 정렬로 배치되어 있다.

히어로 아래로는 실제 대시보드 목업 이미지가 놓여 있고, 그 주변에 Slack, Google Calendar, Microsoft 등 연동 서비스 아이콘이 떠 있어 “기존 업무 도구와 자연스럽게 연결된다”는 메시지를 시각적으로 전달한다. 전형적인 B2B SaaS 랜딩의 구성이지만, 배경 그라데이션이 부드러운 라벤더-화이트 톤으로 처리되어 있어 차갑지 않은 인상을 준다.

다만, TTFB(Time to First Byte)가 700ms ~ 1,117ms로 체감 로딩이 느리다. 88개의 블로킹 스크립트가 초기 렌더를 지연시키고 있어, 퍼스트 페인트까지 체감 대기가 길다.

기술 스택 해부

플랫폼: imweb(아임웹) 노코드 빌더

핸들리 랜딩 페이지의 가장 큰 특징은 자체 개발이 아닌 imweb(아임웹) 플랫폼 위에 구축되었다는 점이다. DOM 구조 전체가 doz_sys, doz_row, doz_type, section_wrap 등 imweb 고유 클래스명으로 이루어져 있고, CSS/JS 에셋은 vendor-cdn.imweb.me에서 로드된다.

imweb은 한국형 노코드 웹 빌더로 Wix나 Squarespace와 유사한 포지션이다. 드래그 앤 드롭 UI로 페이지를 구성하고, “코드” 위젯을 통해 커스텀 HTML/CSS/JS를 삽입할 수 있다. 핸들리는 이 코드 위젯을 적극적으로 활용해 CTA 버튼, 로고 캐러셀, 애니메이션 등을 직접 구현했다.

이 선택의 배경을 추측해보면, 핸들리의 핵심 제품은 공간 관리 SaaS(handly.team)이고, 랜딩 페이지(about.handly.team)는 마케팅 도구다. 프론트엔드 엔지니어링 리소스를 제품에 집중하고, 마케팅 사이트는 비개발자도 빠르게 수정할 수 있는 노코드 플랫폼을 선택한 것으로 보인다.

프론트엔드 기술 구성

레이어기술비고
플랫폼imweb (아임웹)한국형 노코드 빌더
CSS 프레임워크Tailwind CSS + imweb 자체 CSS두 시스템이 혼재
캐러셀Owl CarouseljQuery 의존 슬라이더
에디터Froala Editorfr-view 클래스 기반 콘텐츠
아이콘Font Awesome 5 + Phosphor Icons이중 아이콘 시스템
애니메이션animate.cssfadeInUp, fadeIn 등
폰트Pretendard Variable로컬 호스팅

분석 & 모니터링 스택

핸들리가 가장 공을 들인 부분은 분석 인프라다. 랜딩 페이지 하나에 5개 이상의 트래킹 도구가 탑재되어 있다.

도구용도특이사항
Google Tag Manager태그 관리GTM-5VL6ZZZ5
Google Analytics 4트래픽 분석G-9CXLND1LVZ
Google Ads전환 추적AW-10999336641
Hotjar히트맵 & 세션 리코딩hjid: 6601556
Datadog RUM실시간 성능 모니터링세션 리플레이 100%
Mixpanel제품 분석autocapture + 세션 리코딩 100%
Sentry에러 트래킹init_sentry.js
Channel.io고객 채팅플러그인 SDK

Datadog RUM의 sessionReplaySampleRate: 100과 Mixpanel의 record_sessions_percent: 100이 눈에 띈다. 모든 사용자 세션을 리플레이 녹화하고 있다는 뜻으로, B2B SaaS답게 방문자 행동 데이터를 꼼꼼히 수집하고 있다. allowedTracingUrls에 m.api.handly.team과 handly.team이 설정되어 있어 실제 제품 API와 연결된 트레이싱도 활용 중이다.

대신 이 스택의 대가로 자바스크립트 로딩 부담이 상당하다. 초기 로드 시 외부 스크립트만 8개 이상이 <head>에 삽입된다.

프로젝트 구조 예측

추정 구조 — 외부 관찰 기반 역설계
graph TD
    ROOT["about.handly.team<br/>(imweb 호스팅)"] --> PAGES["페이지 구조"]
    ROOT --> WIDGETS["커스텀 코드 위젯"]
    ROOT --> ANALYTICS["분석 & 모니터링"]
    ROOT --> CDN["에셋 CDN"]

    PAGES --> HOME["/ (Home)"]
    PAGES --> ROOMS["/rooms — 공간관리"]
    PAGES --> DESK["/desk — 좌석관리"]
    PAGES --> PRICE["/price — 가격정책"]

    WIDGETS --> CTA["CTA 버튼<br/>smc_handly-cta-*"]
    WIDGETS --> LOGO_CAROUSEL["로고 캐러셀<br/>logo-carousel-section"]
    WIDGETS --> ANIM["진입 애니메이션<br/>animate.css"]

    ANALYTICS --> GTM["GTM"]
    ANALYTICS --> GA["GA4 + Google Ads"]
    ANALYTICS --> HOTJAR["Hotjar"]
    ANALYTICS --> DD["Datadog RUM"]
    ANALYTICS --> MP["Mixpanel"]
    ANALYTICS --> SENTRY["Sentry"]
    ANALYTICS --> CH["Channel.io"]

    CDN --> IMWEB_CDN["vendor-cdn.imweb.me<br/>(CSS/JS 프레임워크)"]
    CDN --> IMG_CDN["cdn.imweb.me<br/>(이미지/썸네일)"]
    CDN --> DROPLR["cdn-std.droplr.net<br/>(아이콘 에셋)"]

    style ROOT fill:#7D4CFC,stroke:#6545B7,color:#fff
    style PAGES fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style WIDGETS fill:#06b6d4,stroke:#0891b2,color:#fff
    style ANALYTICS fill:#f59e0b,stroke:#d97706,color:#fff
    style CDN fill:#10b981,stroke:#059669,color:#fff

imweb 기반이므로 전통적인 프로젝트 디렉토리 구조가 아닌 플랫폼 내 섹션-위젯 트리로 사이트가 구성된다. 각 페이지는 section_wrap → doz_row → col-dz → widget 계층으로 이루어져 있고, 커스텀 로직은 “코드” 위젯(data-widget-type="code")에 인라인으로 삽입된다.

에셋은 세 곳에 분산 호스팅된다:

  • vendor-cdn.imweb.me — 플랫폼 프레임워크 CSS/JS (Tailwind, Bootstrap, animate.css 등)
  • cdn.imweb.me — 업로드된 이미지, 썸네일
  • cdn-std.droplr.net — CTA 아이콘 등 외부 에셋

디자인 시스템 분석

컬러 팔레트

#8d64f8테마 컬러 / 네비 활성
#7D4CFCCTA 무료체험 버튼
#6545B7Primary-50 / 강조 텍스트
#46434B본문 텍스트
#89888DNeutral-60 / 서브텍스트
#150C2FCTA 텍스트 / 딥 다크
#F8F9FA문의하기 버튼 배경

퍼플 계열을 중심으로 3단계 명도 차이(#8d64f8 → #7D4CFC → #6545B7)를 두고 있다. CSS 변수명에서 --Primary-50, --Neutral-60 같은 디자인 토큰 네이밍이 발견되어, Figma 등 디자인 툴에서 체계적으로 관리한 흔적이 보인다. 다만 이 변수들이 :root에 전역 선언된 것이 아니라 인라인 스타일 내 var() 참조로만 사용되고 있어, 실질적인 CSS 변수 시스템으로 작동하지는 않는다.

다크모드는 지원하지 않는다. B2B 랜딩 특성상 불필요한 선택이다.

타이포그래피

font-family: Pretendard, -apple-system, BlinkMacSystemFont, system-ui, Roboto;

Pretendard를 주 서체로 사용하고 시스템 폰트 폴백 스택을 구성했다. imweb 플랫폼이 Pretendard Variable을 로컬 호스팅(vendor-cdn.imweb.me/fonts/pretendard/)하고 있어 외부 CDN 의존 없이 로드된다.

타이포 스케일은 다음과 같다:

  • 히어로 헤드라인: 72px / bold
  • 서브 헤드라인: 24px / 600 / line-height 1.4
  • 본문: 18px / regular
  • 내비게이션: 16px / inherit
  • CTA 버튼: 18px / 700

히어로에서 72px를 쓴 것은 B2B SaaS 랜딩에서는 과감한 편이다. 가독성보다는 임팩트에 무게를 둔 선택으로 보인다.

레이아웃 & 반응형

핸들리 Rooms 페이지 풀페이지

Rooms(공간관리) 페이지 — 풀페이지 캡처

핸들리 모바일 뷰

모바일 뷰 — 390×844 above-the-fold

데스크톱 기준 max-width: 1440px로 콘텐츠 영역을 제한하고 있다. imweb의 12그리드 시스템(doz_grid="12", col-dz-12)을 기반으로 각 섹션이 풀 와이드로 배치된다.

반응형 브레이크포인트는 imweb 기본 체계를 따른다:

  • 데스크톱: 992px 이상
  • 태블릿: 768px ~ 991px
  • 모바일: 767px 이하

주목할 점은 PC 전용 섹션과 모바일 전용 섹션을 완전히 분리해서 운영한다는 것이다. DOM에서 pc_section과 mobile_section 클래스가 각각 존재하며, mobile_hide="Y" 속성으로 디바이스별 표시/숨김을 처리한다. CSS display: none으로 토글하는 방식이라 두 버전의 DOM이 모두 로드되어 HTML 용량이 2배 가까이 불어나는 단점이 있다.

모바일에서는 CTA가 “문의하기” 단일 버튼으로 단순화되고, 히어로 이미지 대신 텍스트 중심으로 재구성된다.

UX 패턴 깊이 파기

네비게이션

데스크톱 네비게이션은 홈 / 서비스 / 가격 정책의 3개 메뉴와 우측 로그인 / 무료 체험 버튼으로 구성된다. 모바일에서는 홈 / 공간관리 / 좌석관리 / 가격정책으로 메뉴가 세분화된다. 데스크톱의 “서비스” 하위에 공간관리와 좌석관리가 묶여 있는 구조다.

헤더는 스크롤 시 상단 고정(scroll-to-fixed)되며, 배경이 투명에서 #fff로 전환된다. 현재 활성 메뉴는 #8d64f8 퍼플 컬러로 하이라이트된다.

인터랙션 & 애니메이션

animate.css를 활용해 섹션 진입 시 fadeInUp, fadeIn 애니메이션을 적용했다. 과하지 않은 수준으로, 스크롤 시 콘텐츠가 자연스럽게 등장하는 정도다.

CTA 버튼에는 세심한 마이크로인터랙션이 적용되어 있다:

/* 호버 시 살짝 떠오르는 효과 */
.smc_handly-cta-btn-trial:hover {
  transform: translateY(-2px) scale(1.02);
  box-shadow: 0 6px 20px rgba(125, 76, 252, .35),
              0 16px 40px rgba(125, 76, 252, .4);
  filter: saturate(1.1) brightness(1.05);
}

/* 마우스 위치 추적 광원 효과 */
.smc_handly-cta-btn-trial::before {
  background: radial-gradient(120px 120px
    at var(--smc_handly-cta-mx, 50%) var(--smc_handly-cta-my, 50%),
    rgba(255,255,255,.4), transparent 60%);
}

--smc_handly-cta-mx, --smc_handly-cta-my CSS 변수를 JavaScript로 마우스 좌표에 바인딩해서 버튼 위에 광원이 따라다니는 효과를 구현했다. 아이콘에는 scale(1.18) 펄스 애니메이션이 반복된다. 노코드 플랫폼 위에서 이 수준의 인터랙션을 코드 위젯으로 구현한 것은 공이 든 부분이다.

정보 구조

페이지 전체 흐름은 전형적인 B2B SaaS 랜딩 패턴을 따른다:

  1. 히어로 — 핵심 가치 제안 + CTA
  2. 기능 하이라이트 — 4가지 핵심 기능 (아이콘 + 설명)
  3. 고객사 로고 — NHK, 웰컴저축은행, 현대자동차, LUSH, 토요타 등
  4. 고객 후기 — 슬라이드 갤러리
  5. 제품 상세 — Rooms(공간관리), Desk(좌석관리) 소개
  6. CTA 반복 — “Get Started” 전환 유도
  7. 푸터 — 앱 다운로드 링크

고객사 로고 섹션에 NHK, 현대자동차, 토요타, LUSH 등 인지도 높은 브랜드가 배치되어 있어 신뢰 시그널(Social Proof)로 기능한다. 다만 로고 캐러셀이 무한 루프로 자동 스크롤되는데, 접근성 관점에서 일시정지 컨트롤이 없는 점은 아쉽다.

SEO & 웹 표준

squirrel audit 결과 전체 점수는 41/100 (F등급)이다.

카테고리점수상태
Crawlability94양호
URL Structure97양호
Core SEO81보통
Social Media83양호
Structured Data100양호
Accessibility73주의
Performance64미흡
Images64미흡
Content61미흡
E-E-A-T57미흡
Mobile46미흡
Security45미흡

주요 이슈를 정리하면:

성능
  • HTML 용량 1,106KB — Googlebot 2MB 제한에 근접
  • 렌더 블로킹 CSS 26개
  • 블로킹 스크립트 88개
  • TTFB 700ms ~ 1,117ms (느림)
  • 총 리소스 3,591KB (무거운 페이지)
보안
  • Canonical URL이 HTTP로 설정됨 (http://about.handly.team/)
  • HTTPS/HTTP 혼합 콘텐츠
  • Content-Security-Policy 헤더 없음
  • X-Frame-Options 미설정
콘텐츠
  • 빈 <h4> 태그 23개 (imweb 갤러리 위젯이 빈 캡션을 생성)
  • 헤딩 계층 건너뜀 (H1 → H4, H2 → H4)
  • 49개 이미지에 alt 텍스트 누락

Structured Data 100점은 imweb이 이미지 위젯마다 ImageObject JSON-LD를 자동 삽입해주기 때문이다. 플랫폼 레벨의 기본 지원이 점수를 끌어올린 케이스다.

배울 점 & 아쉬운 점

참조할 만한 기술

1. 노코드 위에서 커스텀 CTA 구현

imweb의 “코드” 위젯으로 삽입한 CTA 버튼 컴포넌트가 인상적이다. CSS 변수 기반 마우스 추적 광원, box-shadow 레이어링, saturate() 필터까지 적용해 노코드 플랫폼의 한계를 뛰어넘었다. smc_handly-cta-* 접두어로 네임스페이스를 분리한 것도 imweb 기본 스타일과 충돌을 방지하는 실용적인 패턴이다.

2. 분석 스택 설계

GTM으로 태그를 통합 관리하면서, Hotjar(정성 데이터) + Mixpanel(정량 데이터) + Datadog RUM(성능 데이터)을 조합한 구성은 B2B SaaS 랜딩의 교과서적 분석 아키텍처다. 특히 Datadog의 allowedTracingUrls에 제품 API 도메인을 연결해 랜딩 → 제품 전환까지 End-to-End 트레이싱을 구현한 점은 참고할 만하다.

3. PC/모바일 독립 섹션 전략

반응형 CSS만으로 처리하기 어려운 레이아웃 차이를 PC 전용/모바일 전용 섹션으로 분리해 해결했다. 노코드 환경에서 디바이스별 완전히 다른 UX를 제공할 수 있는 실용적인 우회 전략이다.

개선 여지

1. HTML 용량 최적화

1,106KB HTML은 과도하다. PC/모바일 이중 섹션 구조가 주원인이다. imweb 플랫폼 한계이지만, 불필요한 빈 위젯(<h4></h4><p></p> 23세트)이나 사용하지 않는 CSS 인라인 블록을 정리하면 상당 부분 줄일 수 있다.

2. Canonical URL HTTP 문제

<link rel="canonical" href="http://about.handly.team/">에서 HTTPS가 아닌 HTTP로 설정되어 있다. OG URL도 마찬가지다. 검색엔진이 HTTP 버전을 정규 URL로 인식할 수 있어 SEO에 부정적이다.

3. 렌더 블로킹 리소스

vendor-cdn.imweb.me에서 로드되는 CSS 파일 26개가 전부 렌더 블로킹이다. 이 중 상당수(chosen.css, chosenImage.css, owl.carousel1.css 등)는 해당 페이지에서 사용하지 않는 스타일이다. 플랫폼 레벨 이슈이므로 핸들리 팀이 직접 제어하기 어렵지만, imweb 측에 불필요 CSS lazy loading을 요청하거나, 커스텀 도메인에서 Critical CSS만 인라인하는 방식을 고려할 수 있다.

4. 이미지 최적화

이미지가 width/height 속성 없이 삽입되어 CLS(Cumulative Layout Shift) 위험이 있고, below-fold 이미지에 loading="lazy" 속성이 누락되어 있다. WebP/AVIF 변환도 적용되지 않았다.

배울 점: 개발자가 가져갈 기술적 인사이트

1. 노코드 플랫폼의 전략적 활용 — 제품과 마케팅 사이트를 분리하고, 마케팅 사이트에 노코드를 선택하는 것은 초기 B2B SaaS에서 유효한 전략이다. 다만 성능과 SEO 측면의 트레이드오프를 인지하고, 코드 위젯으로 보완 가능한 영역(CTA, 분석 스크립트)과 플랫폼 한계로 제어 불가능한 영역(렌더 블로킹 CSS, HTML 구조)을 구분해야 한다.

2. 분석 스택 레이어링 — “모든 것을 다 넣자”보다는 각 도구의 역할을 명확히 분리하는 것이 중요하다. 핸들리처럼 GTM(통합 관리) → GA4(트래픽) → Mixpanel(행동) → Hotjar(정성) → Datadog(성능) → Sentry(에러)로 책임을 나누면, 데이터 중복 없이 풀 퍼널 인사이트를 얻을 수 있다.

3. CSS 네임스페이스로 충돌 방지 — 노코드/CMS 환경에서 커스텀 코드를 삽입할 때, smc_handly-cta-* 처럼 고유 접두어를 붙이는 습관은 스타일 충돌을 예방하는 기본기다. BEM이나 CSS Modules를 쓸 수 없는 환경에서 가장 실용적인 격리 방법이다.

자주 묻는 질문 (FAQ)

Q. 핸들리는 왜 React/Next.js 같은 프레임워크 대신 imweb을 선택했을까?

핸들리의 핵심 제품(handly.team)은 별도 도메인에서 자체 프론트엔드로 운영된다. 랜딩 페이지(about.handly.team)는 마케팅 목적이므로, 비개발자(마케터, PM)가 직접 수정할 수 있고 배포 사이클이 제품과 독립적인 노코드 플랫폼을 선택한 것으로 보인다. 실제로 imweb의 위젯 ID 타임스탬프(w20251120*)를 보면 콘텐츠가 수시로 업데이트되고 있어, 빠른 반복이 가능한 환경의 이점을 활용하고 있다.

Q. 분석 도구를 이렇게 많이 넣으면 성능에 문제가 없나?

있다. 88개 블로킹 스크립트 중 상당 부분이 분석 SDK다. 다만 B2B SaaS 랜딩에서는 전환율 최적화를 위한 데이터 확보가 성능보다 우선순위가 높을 수 있다. 이상적으로는 GTM에서 스크립트 로딩을 지연(trigger: DOM Ready 또는 Window Loaded)시키고, 분석 SDK를 async/defer로 처리하면 초기 렌더 영향을 줄일 수 있다.

Q. imweb으로 만든 사이트의 SEO 한계를 극복할 수 있나?

Canonical URL HTTP 문제, 빈 헤딩, alt 텍스트 누락 같은 이슈는 imweb 관리자 패널에서 수정 가능하다. 하지만 HTML 용량(1,106KB), 렌더 블로킹 리소스(26개 CSS), DOM 사이즈(1,999 노드) 같은 구조적 이슈는 플랫폼 레벨이라 개별 사이트에서 해결하기 어렵다. SEO가 핵심 채널이라면 장기적으로 Headless CMS + Next.js/Astro 같은 SSG 스택으로 마이그레이션을 검토할 필요가 있다.

참고 안내 — 이 글은 외부에서 관찰 가능한 정보(DOM 구조, HTTP 응답, 공개 에셋 등)를 기반으로 작성된 개인적인 기술 분석이며, 학습과 참고 목적으로 제공됩니다. 내부 소스 코드에 직접 접근한 것이 아니므로 실제 구현 구조와 다를 수 있습니다. 분석 대상 사이트의 공식 입장과는 무관합니다.

📚 관련 글 더 읽어보기

한컴AI 웹사이트 해부: GSAP과 Swiper로 만든 기업형 풀스크린 인터랙션

한컴AI(ai.hancom.com)의 디자인 시스템, 기술 스택, UX 패턴을 심층 분석합니다. Vanilla JS + GSAP + Swiper 조합의 풀스크린 스크롤 전략부터 다국어 대응, 다크 테마 브랜딩까지.

읽어보기 →
한컴AI 웹사이트 해부: GSAP과 Swiper로 만든 기업형 풀스크린 인터랙션

DRAFT.X 웹사이트 해부: Framer 기반 하이엔드 에이전시 웹 패턴 분석

DRAFT.X(드래프트엑스)의 디자인 시스템, 기술 스택, UX 패턴을 심층 분석합니다. 프레이머 기반의 No-code 아키텍처와 시각적 퍼포먼스의 트레이드오프를 확인하세요.

읽어보기 →
DRAFT.X 웹사이트 해부: Framer 기반 하이엔드 에이전시 웹 패턴 분석

RightBrain(라이트브레인) 웹사이트 해부: WordPress + Slider Revolution으로 완성한 UX 에이전시의 자기표현

대한민국 대표 UX 컨설팅 에이전시 라이트브레인(rightbrain.co.kr)의 디자인 시스템, 기술 스택, UX 패턴을 심층 분석합니다. BeTheme + Slider Revolution 6의 풀스크린 시네마틱 히어로, 커스텀 폰트 시스템, 포트폴리오 중심 정보 설계까지.

읽어보기 →
RightBrain(라이트브레인) 웹사이트 해부: WordPress + Slider Revolution으로 완성한 UX 에이전시의 자기표현

카카오뱅크 answer 블로그 해부: Next.js App Router + GSAP으로 만든 금융 콘텐츠 플랫폼

카카오뱅크 공식 블로그 answer(blog.kakaobank.com)의 디자인 시스템, 기술 스택, UX 패턴을 심층 분석합니다. Next.js App Router 기반 SSR, Pretendard Variable 폰트, GSAP 텍스트 애니메이션, 다크모드까지.

읽어보기 →
카카오뱅크 answer 블로그 해부: Next.js App Router + GSAP으로 만든 금융 콘텐츠 플랫폼