[21기 고마워클코] 랜딩페이지 자동 생성기 만들기 ver1

시작: "랜딩페이지 하나 만드는데 왜 이렇게 많은 게 필요하지?"

랜딩페이지 하나를 제대로 만들려면 생각보다 많은 전문 영역이 필요하더라구요

• 경쟁사는 뭘 하고 있는지 조사해야 하고

• 타겟 고객이 어떤 심리로 구매하는지 알아야 하고

• 그에 맞는 설득력 있는 카피를 써야 하고

• 시각적으로 신뢰감 있는 디자인을 설계해야 하고

• 그걸 반응형 코드로 구현해야 하고

• SEO도 챙겨야 하고

한 사람이 다 하면 어딘가에서 품질이 떨어지고
전문가 여러 명에게 맡기면 비용이 큽니다.

그래서 각 전문 영역을 담당하는 AI 에이전트를 만들고, 이 에이전트들이 하나의 파이프라인 안에서 체계적으로 협업하게 하면 어떨까? 라는 생각을 하게 되었습니다.

결과물: 이렇게 만들어집니다

고객 정보를 YAML 파일 하나에 채우고
Claude Code에서 /make-landing-page → /run
두 명령만 실행하면 아래와 같이 동작을 하게 됩니다.

ALT

웹사이트를 만드는 과정을 보여주는 다이어그램

1. 경쟁사 분석 에이전트가 동종 업계 웹사이트를 벤치마크하고

2. UX 리서치 에이전트가 타겟 고객의 구매 심리를 분석하고

3. 사람이 리서치 결과를 검토한 뒤 (Human In The Loop)

4. 카피라이터 에이전트가 헤드라인부터 CTA까지 작성하고

5. 디자인 플래너 에이전트가 컬러, 타이포, 레이아웃을 설계하고

6. 이미지 소싱 에이전트가 실제 사용 가능한 스톡 이미지를 확보하고

7. 사람이 설계를 검토한 뒤 (Human In The Loop)

8. 코드 빌더 에이전트가 실제 코드로 구현하고

9. QA 에이전트가 Playwright로 스크린샷을 촬영하여 디자인 플랜과 비교하고

10. SEO 에이전트가 메타 태그, 구조화 데이터, 접근성을 최적화하고

11. 발견된 이슈를 수정한 뒤

12. 사람이 최종 검수 (Human In The Loop)

→ 배포 가능한 웹사이트가 나옵니다.

Human In The Loop: 사람이 직접 개입을 한다는 이야기입니다.

개발 과정에서의 시행착오

1. "한 에이전트에게 다 시키면 되지 않을까?"

처음에는 하나의 프롬프트로 "리서치부터 코드까지 다 해줘"를 시도했습니다.

결과: 처참했습니다. 리서치는 피상적이고, 카피는 밋밋하고, 디자인은 일관성이 없고, 코드는 기본 템플릿 수준이었습니다. AI 하나가 모든 전문 영역을 커버하는 건 사람 한 명이 다 하는 것과 같은 문제였습니다.

교훈: 전문 영역별로 에이전트를 분리하고, 각 에이전트에게 해당 도메인의 지식(디자인 시스템, 타이포그래피 규칙, 전환 심리학 등)을 주입해야 합니다. 결국 8개 에이전트로 분리했습니다.

2. "AI가 생성한 디자인은 다 비슷하게 생겼다"

에이전트를 분리한 후 품질은 올라갔지만, 프로젝트를 여러 개 만들다 보니 전부 비슷한 레이아웃이 나왔습니다. 히어로 섹션 → 특징 → 후기 → CTA → 푸터, 매번 같은 구조.

해결: 6종의 레이아웃 아키타입을 정의했습니다.

그리고 기존 프로젝트와 동일한 아키타입은 자동으로 회피하도록 했습니다. 베이커리 프로젝트에서 Product Showcase를 썼으면, 다음 식품 프로젝트에서는 다른 아키타입을 선택합니다.

3. "방충망 사이트에 3D 파티클이 필요할까?"

초기에는 모든 프로젝트에 같은 수준의 인터랙션을 적용했습니다. 럭셔리 화장품이든 동네 방충망 업체든 같은 기술 스택(Next.js + Framer Motion)으로 만들었는데, 방충망 업체 사이트에 파티클 효과와 3D 애니메이션이 들어간 건 과잉이었습니다.

해결: 3단계 Tier 시스템을 만들었습니다.

경쟁사 분석 단계에서 5개 항목(업종 비주얼 의존도, 경쟁사 인터랙션 수준, mood 키워드, 미디어 에셋, 타겟 감성)을 0~2점으로 채점하여 Tier를 자동 판정합니다. 방충망은 T3, 화장품은 T1이 자동으로 결정됩니다.

4. "이미지가 전부 placeholder였다"

코드는 잘 나오는데, 이미지가 전부 placeholder.jpg이거나 깨진 URL이었습니다. AI가 존재하지 않는 이미지 URL을 만들어내는 hallucination 문제였습니다.

해결: @asset-curator라는 전담 에이전트를 만들고, Pexels/Unsplash에서 실제로 접근 가능한 이미지 URL을 검색·확인하도록 했습니다. "placeholder 사용 금지"를 시스템 규칙으로 강제했습니다.

5. "에이전트가 단계를 건너뛰거나 대충 넘어갔다"

에이전트가 가끔 리서치를 건너뛰거나
빈 파일만 만들고 다음 단계로 넘어가는 문제가 있었습니다.

해결: 각 Phase 끝에 Human In The Loop 게이트를 넣었습니다. 사람이 직접 산출물을 확인하고 "진행" 또는 "재작업"을 결정합니다.

추가로, 산출물 파일이 존재하는지 + 최소 크기(100바이트) 이상인지를 코드로 자동 검증하는 Anti-Skip Guard도 넣었습니다. AI의 "했습니다" 말만 믿지 않고, 실제 파일을 코드로 확인합니다.

6. "한국 사이트인데 영어권 디자인 감각이 나왔다"

AI는 기본적으로 영어권 웹사이트 데이터로 학습되어 있어서, 한국 시장에 맞지 않는 디자인이 나왔습니다. 여백이 너무 넓고, CTA 문구가 한국인에게 어색하고, 신뢰 요소(인증 마크, 고객 후기 배치)가 한국 소비자 기대와 달랐습니다.

해결: 한국 시장 특화 디자인 지식을 문서화하여 에이전트에게 주입했습니다.

• 한국어 타이포그래피: 한글 자간(-0.02em~-0.01em), 행간(1.8~2.0), word-break 규칙

• 한국 시장 전환 패턴: 4단계 신뢰 스택(인증→수치→후기→보증), 카카오톡 채널 연동, "무료 상담" vs "지금 구매" CTA 차이

• 폰트 페어링: Pretendard + 본명조 같은 한국어 웹폰트 조합

• 정보 밀도: 한국 소비자는 미니멀보다 정보 밀도가 높은 페이지를 선호하는 경향

이 지식들은 references/ 폴더에 8개 문서로 정리되어, 해당 에이전트에게 자동으로 주입됩니다.

7. "코드는 나왔는데 디자인 플랜과 다르게 구현됐다"

디자인 플래너가 "히어로 섹션에 그라디언트 오버레이 + 좌정렬 텍스트"를 설계했는데, 코드 빌더가 "센터 정렬 + 단색 배경"으로 구현하는 일이 있었습니다. 에이전트 간 산출물 전달 과정에서 정보가 유실된 것입니다.

해결: @design-reviewer가 Playwright로 실제 구현된 페이지의 스크린샷을 촬영하고, 디자인 플랜 문서와 항목별로 비교 검증하도록 했습니다. 불일치가 발견되면 QA 리포트에 구체적 이슈로 기록되고, 코드 빌더가 수정합니다.

기술적으로 어떻게 구현했는가

Claude Code의 Sub-agent 구조

• 에이전트 정의: .claude/agents/ 폴더에 각 에이전트의 역할, 도구 권한, 도메인 지식을 Markdown으로 정의

• Slash Command: /make-landing-page(프로젝트 초기화), /run(워크플로우 실행), /Human-in-the-loop(품질 게이트)

• Hook 스크립트: 위험 명령 차단, 시크릿 유출 탐지 등 안전장치를 Python Hook으로 자동화

• 도메인 지식 주입: references/ 폴더의 디자인 시스템 문서를 에이전트 실행 시 Context Injection

워크플로우 자동 생성

고객 정보(YAML)를 분석하여 Tier와 아키타입을 판정한 뒤, 12단계 workflow.md를 자동 생성합니다. 이 워크플로우가 어떤 에이전트를 어떤 순서로 호출하고, 각 단계에서 어떤 산출물을 만들어야 하는지를 정의합니다.

같은 시스템에서 만들어도:

• 베이커리 → T2 + Product Showcase

• 화장품 → T1 + Storytelling Flow

• 인테리어 → T3 + Authority Grid

업종마다 기술 스택, 레이아웃, 인터랙션 수준이 전부 달라집니다.

실제로 테스트한 프로젝트들

다양한 업종으로 테스트하며 시스템을 개선했습니다:

bonble-bakery가 v2까지 있는 이유는, 초기 버전에서 발견된 문제들(이미지 placeholder, 한국어 타이포그래피 미적용, 아키타입 단조로움 등)을 해결한 후 같은 고객 정보로 재생성하여 개선 효과를 검증했기 때문입니다.

배운 것들

AI 에이전트는 "전문가 팀"처럼 써야 한다

하나의 AI에게 모든 걸 시키는 것보다, 역할을 분리하고 각자의 전문 지식을 주입하는 게 훨씬 나은 결과를 냅니다. 인간 조직의 분업과 같은 원리입니다.

"AI가 했다"고 말하면 안 믿어야 한다

AI가 "완료했습니다"라고 말해도, 실제로 파일이 존재하는지, 내용이 있는지를 코드로 검증해야 합니다. 사람도 "했습니다" 하고 실제론 안 한 경우가 있듯이, AI도 마찬가지입니다.

도메인 지식을 문서화해서 주입하는 게 핵심이다

"좋은 랜딩페이지 만들어줘"보다 "한국어 자간은 -0.02em, 신뢰 스택은 인증→수치→후기→보증 순서, CTA는 '무료 상담 받기'"처럼 구체적인 도메인 지식을 문서로 정리해서 에이전트에게 읽히는 게 결과물의 품질을 결정합니다.

사람의 검수 포인트가 있어야 한다

완전 자동화는 매력적이지만 중간중간 사람이 확인하는 게이트가 없으면 잘못된 방향으로 쭉 달려갑니다. Research가 끝난 후, 설계가 끝난 후, 구현이 끝난 후 — 이 3번의 체크포인트가 전체 품질을 높여주는 것 같습니다.

아직 완성본도아니고 아쉬운 부분도 너무 많기 때문에 계속 추가 수정을 해볼 예정입니다.
또한, 제가 정답이 아니라고 생각하며 아직은 AI티가 조금씩은 나는 것 같습니다

https://www.youtube.com/watch?v=m25xU2qEbcg