디자이너가 Claude Code로 랜딩 페이지 직접 배포하기 #1
수학비서 랜딩의 AI 전환기: iframe을 걷어내고 SSR을 입히다
안녕하세요, 수학비서 프로덕트 디자이너 고유현입니다.
네이버 검색에 노출되지 않던 랜딩 페이지를 해결하기 위해, 개발 리소스 없이 Claude Code와 함께 2주 만에 새 랜딩 페이지를 구축하고 배포했습니다. 그 과정에서 AI가 디자이너의 작업 방식에 실제로 얼마나 도움이 되는지 직접 확인해봤습니다.
잘된 점과 어려웠던 점, 그 과정에서 얻은 협업 원칙을 3편에 걸쳐 정리했습니다.
배경
수학비서는 방대한 문제 데이터와 AI로 수학 선생님의 시간을 줄여주는 AI 기반 수학 교육 콘텐츠 플랫폼입니다.
문제는 랜딩 페이지가 네이버 검색에 노출되지 않는다는 점이었습니다. 기존 랜딩 페이지는 Figma Site를 iframe으로 띄우는 구조였고, 검색 엔진이 iframe 내부 콘텐츠를 본문으로 충분히 인식하지 못하고 있었습니다. 구글에서는 일부 노출됐지만, 네이버에서는 사실상 미노출 상태였습니다.
해결책은 명확했습니다. 랜딩 페이지를 Next.js 기반 SSR 구조로 다시 만드는 것.
하지만 그 일을 맡길 개발 리소스는 없었습니다.
그래서 제가 직접 Claude Code를 활용해 만들기로 했습니다.
수학비서 메인 랜딩페이지
AI가 다 해줄 거라는 착각
작업을 시작하기 전, 머릿속 그림은 단순했습니다.
“피그마 링크 던지면 알아서 코드 만들어주고, ‘여기 좀 다듬어줘’ 하면 알아서 다듬어주고, ‘반응형으로’ 하면 모바일·태블릿·데스크탑 다 맞춰주겠지?”
이미 디자인은 완성되어 있었기 때문에 그대로 옮기기만 하면 끝날 것이라 생각했습니다.
첫 프롬프트도 단순했습니다.
“이 피그마 시안대로 메인 랜딩페이지 만들어줘. 똑같이 만들어봐.”
결과물은 디자인 시안과 차이가 컸습니다.
- 색상이 피그마와 다름
- 간격 기준이 일정하지 않음
- 모바일 화면에서 요소가 튀어나감
- Pretendard가 적용되지 않고 기본 시스템 폰트로 표시됨
- 일부 일러스트가 누락됨
그래서 다시 요청했습니다.
“이거 피그마랑 다른데? 다시 똑같이 맞춰줘.”
처음 며칠은 AI를 사람처럼 대하기도 했습니다. (생각보다 잘 만들 때도 있었습니다)
이 시기를 지나며 한 가지를 배웠습니다.
AI는 자기가 만든 결과를 직접 보지 않습니다. 디자이너가 눈으로 확인하고 짚어주지 않으면, “맞게 만들었다”고 자신 있게 말합니다.
AI에게는 형용사가 아니라 숫자가 필요했습니다
초반엔 원하는 결과가 거의 나오지 않았습니다. 디자이너끼리는 자연스럽게 통하던 표현들이 AI 앞에서는 작동하지 않았습니다.
| 제가 시킨 말 | 클로드가 만든 결과물 |
|---|---|
| ”위계가 잘 안 보여, 다시 잡아줘” | 폰트 사이즈를 무작정 키워버림 |
| ”여백을 정리해줘” | 모든 padding을 0으로 |
| ”톤이 너무 무거워, 다운해줘” | 색을 다 그레이 톤으로 변경함 |
| ”리듬감이 없어, 자연스럽게” | 무작위로 사이즈 변주 |
| ”공간감 좀 줘” | 섀도우 값을 과하게 사용함 |
패턴은 명확했습니다.
‘위계’, ‘톤’, ‘리듬감’, ‘공간감’은 디자이너끼리는 통하지만, AI에게는 어디를 어떻게 수정해야 하는지 불명확한 표현이었습니다.
AI는 추상적인 표현보다 수치와 기준에 더 정확하게 반응했습니다.
예를 들어,
- 카드 간격 24px로 통일
- 타이틀 크기 32px → 40px 상향
- 모바일 390px 기준 좌우 패딩 20px 적용
- 본문 컬러 #111111로 변경
이렇게 말했을 때 결과가 안정적으로 좋아졌습니다.
10%의 디테일
결론부터 말하면, 기대한 자동화와 실제 작업 방식 사이에는 큰 차이가 있었습니다.
Claude Code는 빠르게 만들고, 반복 작업과 수정에도 능합니다.
하지만 무엇을 만들어야 할지, 결과가 맞는지 틀린지, 마지막 디테일을 어떻게 다듬어야 할지는 여전히 디자이너가 결정해야 했습니다.
같은 페이지의 데스크탑·태블릿·모바일 화면
피그마에서 ‘Ignore auto layout’으로 처리한 일러스트는 Claude가 아예 인식하지 못하는 이슈도 있었습니다.
제가 정확하게 요청한 만큼 정확한 결과가 나왔고, 놓친 부분은 그대로 남았습니다.
그래서 어떻게 사용했나
기대치를 조정한 뒤 정착한 작업 방식은 아래와 같았습니다.
디자이너의 5단계 작업 패턴
- 피그마에서 섹션 단위로 나누기전체 페이지를 한 번에 요청하지 않고, 히어로 → 기능 카드 → 상세처럼 잘게 나누기.
- Figma MCP로 디자인 값 추출색상, 간격, 폰트 값을 읽어와 코드에 반영.
- localhost에서 직접 검수피그마와 비교하며 모바일·태블릿·데스크탑 전부 확인.
- 문제를 숫자로 피드백’이상해요’ 대신 ‘상단 여백 16px 늘려줘’
- 다음 섹션으로 이동
이 과정을 모든 페이지에 반복했습니다.
2주 동안의 변화
처음에는 거의 모든 프롬프트가 실패했습니다.
며칠 뒤 첫 페이지가 완성됐고, 이후 작업 패턴이 잡히면서 수정 횟수가 빠르게 줄었습니다. 2주가 지나자 5개 페이지가 완성됐고, 다음 페이지는 반나절이면 만들 수 있겠다는 감각이 생겼습니다.
기존에는 디자인 → 핸드오프 → 구현 → QA → 수정 → 배포까지 3~4주가 걸리던 흐름이었는데, 이번 작업은 약 2주 안에 마무리할 수 있었습니다.
가장 큰 변화는 코딩 실력이 아니었습니다.
AI에게 정확히 지시하는 능력, 즉 디자이너의 감각을 언어와 숫자로 번역하는 능력이었습니다.
AI의 한계는 나의 한계
AI는 빠르게 결과를 만들고 반복 작업에 강했습니다. 하지만 무엇을 시킬지 모르면 헤매고, 마지막 완성도는 사람이 채워야 했습니다.
결과물이 90% 맞아 보여도, 디자이너 눈에는 어색한 10%가 남습니다. 그 차이를 다듬느냐 지나치느냐에 따라 결과물 완성도가 달라졌습니다.
2주 동안 써보며, 결국 중요한 건 기술보다 결과를 판단하는 눈이라는 생각이 들었습니다.
그런데 더 흥미로운 이야기는 그 안에 있었습니다. 실패한 프롬프트들을 정리하다 보니, 반복해서 통하는 패턴과 협업 원칙이 보이기 시작했습니다.
다음 글에서는 디자이너의 말을 AI가 이해하도록 바꾸는 프롬프트 원칙을 다뤄보겠습니다.
시리즈 전체 보기
01 디자이너가 Claude Code로 랜딩 페이지 직접 배포하기 #102 Figma → Code, 디자이너가 직접 옮길 때 알아야 할 것들 #2
03 Next.js 앱을 GCS에 올리기까지: 디자이너의 배포 회고 #3