Agency / 2026.07
LP Factory — Financial Landing Pages as Data
금융 광고 LP를 디자인 토큰, 컴포넌트, 심의문구 슬롯으로 나눠 변형 제작을 데이터 치환으로 바꾼 생성 시스템입니다. Lighthouse 100/100을 게이트로 강제합니다.
기획·프론트엔드·품질 게이트
Metrics
- Lighthouse 성능/접근성 100/100 (빌드 게이트)
- 심의문구 fail-closed 린트 — 누락 시 빌드 실패
- 변형 LP = 데이터 치환만으로 생성 (실증)
- 레퍼런스 해부: heading/alt/label 0개 → 시맨틱 마크업 전면 적용
Stack
Problem
레퍼런스 LP들을 해부해 보니 대부분 정적 HTML + 이미지 슬라이스였습니다. heading/alt/label은 0개(접근성 부재), 거대 JPG로 인한 성능 문제, 이중 제출 방지 없음, 금융 심의문구의 이미지 하드코딩까지 있었습니다. 변형 하나를 만들려면 처음부터 다시 만드는 구조였습니다.
Idea
실제 금융 LP 레퍼런스의 반복 구조와 심의문구 누락 위험을 분석하면서, LP를 코드가 아니라 검증 가능한 데이터 조립 문제로 다시 정의했습니다.
Decision
LP를 코드가 아니라 데이터로 정의했습니다. 색·타이포·간격은 디자인 토큰, 섹션은 컴포넌트, 심의필 번호·유의사항은 데이터 슬롯으로 분리했습니다. 심의문구가 빠지면 빌드가 실패하는 fail-closed 린트도 걸었습니다. 성능·접근성은 Lighthouse 게이트로 강제해 '상위호환'을 주장이 아니라 측정치로 만들었습니다.
Outcome
같은 상품의 성별 타깃 변형을 코드 수정 없이 데이터 치환만으로 생성하는 것을 실증했습니다. 산출 LP는 Lighthouse 성능·접근성 100/100입니다. 레퍼런스 대비 구조적으로 더 안전한 방식입니다.
문제
금융 광고 LP는 규제 산업의 산출물입니다. 심의필 번호와 유의사항 고지가 필수인데, 레퍼런스들은 이걸 이미지 안에 하드코딩하고 있었습니다. 문구가 바뀌면 디자이너가 이미지를 다시 잘라야 하고, 누락돼도 아무것도 막아주지 않습니다. 실제로 개인정보처리방침 링크 누락 사고 이력도 있었습니다. 접근성은 heading/alt/label 0개였습니다. 스크린리더에게는 빈 화면에 가깝습니다.
결정
“LP를 잘 만드는 것”이 아니라 **“LP가 잘못 만들어질 수 없게 하는 것”**을 목표로 잡았습니다.
- 심의문구·필수 고지를 데이터 슬롯으로 분리하고, 누락 시 빌드 자체가 실패하는 린트를 걸었습니다. 사람의 주의력이 아니라 파이프라인이 규제를 지킵니다.
- 색·타이포·간격을 토큰화하고 섹션을 컴포넌트화했습니다. PC/모바일은 같은 토큰의 다른 조립입니다.
- 성능·접근성을 “노력하겠다”가 아니라 Lighthouse ≥90/≥95 게이트로 CI에 넣었습니다. 결과는 100/100입니다.
성과
같은 상품의 성별 타깃 변형 LP를 데이터 파일 치환만으로 생성하는 것을 실증했습니다. 레퍼런스 분석에서 실제 변형 LP가 원본과 동일 템플릿의 데이터 치환 관계라는 점을 확인했기 때문에, 이 방식이 실무 제작 패턴과 맞는다는 근거가 있습니다. 심의 문구 검토처럼 사람이 반드시 봐야 하는 지점은 체크리스트로 남기고, 나머지는 자동화했습니다.