LP Factory — 금융 랜딩페이지 생성 시스템

문제

금융(보험·은행) 광고 랜딩페이지는 정적 마크업 + 상담폼 + 심의 문구 + PC/MO 분리 빌드로 구성된다. 실무에서는 변형(예: 여성 특화 상품)마다 페이지를 수동 복제하고, 심의 문구는 이미지에 하드코딩되며, 접근성·성능·이중 제출 방지는 방치되기 쉽다. 실제로 레퍼런스 페이지에서 개인정보처리방침 링크 누락 같은 사고 유형이 발견됐다.

접근

실제 운영 중인 금융 LP 2종(손해보험사 A, 인터넷전문은행 B)을 해부 → 재현 → 개선하는 순서로 진행했다.

1. 디자인 토큰부터. 색·타이포·간격을 토큰으로 추출하고, 모든 컴포넌트(히어로/혜택/상담폼/정보 아코디언/FAQ/심의 푸터)가 토큰만 소비하게 했다.
2. 브리프 YAML → LP 생성 CLI. 변형은 overrides 1블록(성별 기본값·상품명)으로 자동 생성된다. 원본 변형 페이지가 사실상 데이터 치환 변형이라는 것을 해부로 실증한 뒤 구조화한 것.
3. 준법을 코드로. 심의필 번호·개인정보처리방침·유의사항은 데이터 슬롯이다. 누락되거나 만료되면 생성 자체가 차단된다(fail-closed). 사람이 잊어도 시스템이 막는다.

결과 (실측)

지표	재현판 PC	재현판 MO	원본 PC	원본 MO
Lighthouse 성능	100	100	97	73
접근성	100	100	68	80
SEO	100	100	82	82
LCP	0.2s	0.8s	1.0s	5.1s

원본 결함 10종(heading/alt/label 부재, 이중 제출 방지 없음, 심의 문구 이미지 하드코딩 등)을 전부 해소했다. 성능 ≥90 / 접근성 ≥95 게이트를 파이프라인에 내장해 회귀를 차단한다.

지금 보고 있는 이 사이트도 같은 원칙(토큰 → 컴포넌트 → 성능 게이트)으로 만들었다 — 방법론이 재사용된다는 증거다.

한계와 실패 모드

• 브랜드 디자인 원본과 심의 문구의 법적 적정성 판단은 도구 범위 밖이다 — 시스템은 표기 누락·만료를 막을 뿐, 문구가 법적으로 옳은지는 사람과 심의 기관의 몫.
• 상담폼의 실서비스 백엔드(개인정보 저장)는 회사 인프라 영역으로, 이 도구는 프런트 계약까지만 다룬다.
• 재현판 지표는 동일 콘텐츠·동일 조건의 로컬 실측이며, 운영 환경(서드파티 스크립트 등)에서는 수치가 달라질 수 있다.

배운 것

성능·접근성·준법은 “잘 챙기자”로 지켜지지 않는다. 게이트로 만들면 지켜진다. 사람의 주의력을 믿는 대신 실패를 빌드 실패로 바꾸는 것 — 이 프로젝트에서 가장 값진 패턴이었다.