Transcript
00:00:00이 채널을 꾸준히 보셨다면 저희가 수많은
00:00:03디자인 워크플로우와 도구를 다뤘다는 걸 아실 겁니다. 몇 달 동안 전부 테스트해 본 끝에 마침내 알아냈죠.
00:00:08왜 똑같은 모델인데도 완전히 맞춤 제작된 것 같은 결과물이 나오는가 하면, 반대로
00:00:13보자마자 AI 생성 티가 팍팍 나는 결과물이 나오는지 말입니다. 이는 세 가지 단계로 나뉩니다. 1단계는 단일 페이지 디자인으로,
00:00:19대부분의 사람들이 놓치는 한 가지가 바로 결과물이 싸구려처럼 보이는 근본적인 이유입니다.
00:00:232단계는 페이지 디자인을 멈추고 시스템을 디자인하기 시작하는 단계이며, 여기서의 워크플로우는
00:00:28완전히 다릅니다. 그리고 3단계는 실제 작동하는 버전을 찾기 위해 디자인들을 서로 비교 테스트하는 방법으로,
00:00:34현재 모든 실제 프로젝트에 적용하고 있는 방식입니다. 따라서 1단계는 단일 페이지에 대한 좋은 디자인을
00:00:39만드는 것입니다. 모든 좋은 디자인의 기초가 되기 때문에 대부분의 사람들이 이 단계를 가르칩니다.
00:00:44이전 영상에서 Opus 4.7의 디자인 역량이 얼마나 대단해졌는지, 그리고 우리가 흔히 보던 AI 슬롭이
00:00:50얼마나 사라졌는지 이야기했습니다. 예전에는 랜딩 페이지를 만들어달라는 간단한 프롬프트를 주면
00:00:55무조건 보라색과 흰색 테마를 가져와서 그에 맞춰 모든 걸 만들곤 했습니다.
00:00:59그런 특정한 패턴은 많이 개선되었습니다. 하지만 다른 AI 모델과 마찬가지로 이 모델 역시
00:01:04안전한 패턴으로 수렴하는 경향이 있습니다. 온갖 테스트와 실험을 거쳐 본 결과,
00:01:09매번 특정 스타일을 기본값으로 사용하는 것을 발견했습니다. 그래서 이제는 그런 스타일을 볼 때마다
00:01:15Opus 4.7로 만든 사이트라는 걸 확실히 알 수 있으며, 머지않아 다음 시대의 AI 슬롭이 될 것입니다.
00:01:21따라서 이 웹사이트를 더 멋지게 보이게 만들려면 다른 방법이 필요합니다. 이 단계는 주로
00:01:25프롬프트 엔지니어링과 앱을 구체화하는 방식에 따라 결과가 달라집니다.
00:01:30프롬프트를 제대로 구조화하면 단 한 번에 앱을 완성할 수 있습니다. 프롬프트는 제작하려는
00:01:35웹사이트의 의도로 시작해야 하며, 앱에 반드시 들어가야 하는 필수 요소와 UI 요소가
00:01:39어떻게 보여야 하는지 언급해야 합니다. 그후에 색상 시스템을 지정합니다.
00:01:44여기서는 기본적으로 명도, 채도, 색상을 측정하는 OKLCH를 사용합니다.
00:01:49일반적인 RGB나 HSL 대신 OKLCH를 사용하는 것이 좋은데, 인간의 눈이 색을 실제로
00:01:55지각하는 방식으로 색상을 표현하기 때문에 명도와 균형을 더 잘 잡아주기 때문입니다.
00:01:59또한 불균일해 보일 수 있는 헥스 코드와 달리 더 부드러운 그라데이션을 만들어 줍니다.
00:02:04색상표를 설정했다면 대비 흐름도 함께 언급해야 합니다.
00:02:08대비는 UI 디자인에서 매우 중요한 요소입니다. 실제로 중요한 부분으로 시선을 유도하는 위계를
00:02:13만들어주기 때문이죠. 명확한 대비가 없으면 모델은 모든 요소를 똑같이 중요한 것으로 취급하여
00:02:18시각적 위계를 형성하기 어렵게 만듭니다. 또한 웹사이트가 AI 슬롭처럼 보이지 않도록 하려면
00:02:22프롬프트에서 타이포그래피도 제어해야 합니다. AI 슬롭 때문에 금지해야 할 폰트와
00:02:27디자인의 각 영역에서 사용할 폰트를 정의해야 하죠. Inter나 Geist 같은 폰트는
00:02:33모든 에이전트가 기본값으로 사용하기 때문에 AI 슬롭의 주범이 되었습니다. 따라서 이를 명시적으로 지정하여
00:02:38모델이 다른 폰트를 찾도록 강제해야 합니다. 그런 다음 웹사이트의 레이아웃과 리듬을 정의하는데,
00:02:42그전에 먼저 대칭과 비대칭에 대해 알아야 합니다. 대칭 레이아웃은 컴포넌트가
00:02:47그리드에 균등하게 배치되어 균형 잡힌 모습을 보여주며, 전문적이고
00:02:51반듯한 디자인에 더 적합합니다. 하지만 좀 더 예술적인 느낌을 원한다면 실험할 수 있는 여유가 더 많은
00:02:56비대칭을 선택하세요. 디자인에 숨통을 틔워주는 여백을 활용해야 할 때 특히 좋습니다.
00:03:01만들고자 하는 제품의 종류에 따라 어떤 것이 더 잘 어울릴지가 결정됩니다. 그후 원하는 모든 섹션과
00:03:06사용할 소재, 그리고 반응형으로 웹사이트가 어떻게 동작해야 하는지 정의합니다. 그리고 가장 중요한
00:03:11부분은 안티 패턴을 언급하는 것입니다. 이는 단순한 중앙 정렬 CTA나 루시드 아이콘,
00:03:17글래스모피즘 디자인 같은 AI 슬롭의 전형적인 특징들입니다. Claude Code나
00:03:22사용 중인 에이전트에 이 프롬프트를 전달하면 앱을 분석하고 구현 세부 사항을 검토합니다. 그런 다음
00:03:27예술적 목표에 부합하는 비대칭성과 적절한 여백 활용을 프롬프트에 설명된 대로 앱을 빌드합니다.
00:03:34따라서 2단계는 사이트의 모든 페이지에서 동일한 디자인을 유지하는 것입니다. 대부분의 에이전트 생성 앱은
00:03:40랜딩 페이지를 벗어나는 순간 무너지기 때문입니다. 에이전트로 전체 앱을 생성할 때 흔히
00:03:45이런 경험을 하셨을 겁니다. 랜딩 페이지는 꽤 그럴듯하지만 다른 페이지로 이동하면
00:03:50UI 스타일이 일관되게 유지되지 않습니다. 대시보드의 버튼 스타일, 간격,
00:03:55타이포그래피가 제각각이 되며, 마치 에이전트가 똑같은 앱을 만들고 있다는 사실을 잊어버린 것 같습니다.
00:04:00다른 페이지들은 같은 사이트의 일부가 아닌 것처럼 보여서 에이전트가 생성한 사이트라는 티가 확 납니다.
00:04:05가끔 인증 페이지에서는 디자인이 유지되다가도 대시보드에 가면 스타일이 완전히 깨져버립니다.
00:04:10따라서 이를 위해 가장 중요한 두 가지 파일인
00:04:15Claude.md와 Design.md를 만들어야 합니다. 이 두 파일이 사이트 전체에서 디자인 일관성을 유지해 줍니다.
00:04:21여러 번 말씀드렸듯이 Claude.md에는 디자인이 아니라 프로젝트 정보만 넣어야 합니다.
00:04:27이 파일은 세션 내내 항상 로드되어 있기 때문에 여기에 디자인 내용이 들어가면 에이전트가 다른 작업을 할 때
00:04:32산만하게 만들기 때문입니다. 하지만 좋은 디자인을 알려주는 프로젝트 컨텍스트를 유지해 주므로
00:04:37여전히 핵심적인 파일입니다. 디자인 자체를 위해서는 별도의 파일이 필요합니다.
00:04:42시각적 시스템, 레이아웃, 색상, 타이포그래피 및 1단계에서 다룬 모든 세부 사항이 언급되어야 합니다.
00:04:47Design.md는 어떤 에이전트든 가져가서 시각적 시스템이 무엇인지 즉시 이해할 수 있는 파일이어야 합니다.
00:04:52그리고 이전 단계에서와 마찬가지로 여기에서도 색상 시스템을 OKLCH로 정의해야 합니다.
00:04:57이 두 파일을 만들기 위해 Claude Code에 각 파일에 필요한 내용을 다룬 상세한 프롬프트를 제공했고, 에이전트가 두 파일을 모두 생성했습니다.
00:05:03Claude.md는 프로젝트 세부 정보만 담고 있어 짧습니다. Design.md는 색상 코드,
00:05:09타이포그래피 선택 및 기타 모든 세부 사항이 포함되어 더 깁니다. 하지만 Design.md가 여기서 끝이 아닙니다.
00:05:15시간이 지남에 따라 계속 발전시켜야 합니다. 그래서 파일 시작 부분에 에이전트가 찾아낸
00:05:20새로운 디자인 값을 이 파일에 추가하도록 지시하는 한 줄을 넣습니다.
00:05:25그렇게 하면 모든 세션이 이전 세션보다 더 정제된 디자인 시스템에서 시작할 수 있습니다.
00:05:30하지만 Claude가 Design.md를 만들도록 내버려 두는 것만으로는 충분하지 않습니다.
00:05:35생성된 결과물이 모범 사례를 제대로 따르지 않기 때문입니다. 구글은 디자인 파일용
00:05:40템플릿을 오픈소스로 공개했습니다. 이 템플릿에는 Design.md를 상호 검증하고
00:05:46오류를 찾아내는 명령어들도 포함되어 있습니다. 따라서 에이전트에게 해당 명령어를 사용해 반복 작업하도록 프롬프트를 주어
00:05:51Design.md를 완벽하게 만들 수 있습니다. 그리고 이것이 2단계의 끝이 아닙니다. 이 수준에서 충분히 훌륭한 디자인을 생성하려면
00:05:56기존 디자인 원칙에 비추어 감사를 거쳐야 합니다. 이를 위해 정확히 이 역할을 수행하는
00:06:00많은 오픈소스 스킬이 있습니다. 어떤 것을 사용해도 상관없지만, 저희는 VersaLab의 스킬을 사용합니다.
00:06:06스킬 내부에 모든 원칙을 하드코딩하는 대신, 그들이 적극적으로 유지 관리하는
00:06:11외부 소스를 참조하기 때문입니다. 따라서 스킬이 처음 작성되었을 때의 최신 기술에 멈춰 있지 않고,
00:06:16현재 모범 사례에 맞춰 최신 상태로 유지됩니다. 이 스킬을 프로젝트에 설치하고 실행하면
00:06:21디자인이 이전보다 훨씬 더 나은 모습으로 완성됩니다. 하지만 계속 진행하기 전에, 스폰서의 메시지를 들어보겠습니다.
00:06:25최근에 ZillysCloud를 사용하기 시작했는데, 그 이유를 말씀드리겠습니다.
00:06:30대부분의 RAG 앱은 소수의 문서는 잘 처리하지만, 실제 데이터를 투입하는 순간
00:06:35구성이 그런 부하를 감당하도록 설계되지 않았기 때문에 무너지기 시작합니다.
00:06:40Milvus는 깃허브에서 4만 4천 개 이상의 스타를 받은 가장 인기 있는 오픈소스 벡터 데이터베이스이며,
00:06:46이러한 부하를 처리하도록 제작되었습니다. 하지만 자체 호스팅은 인프라를 직접 관리해야 함을 의미합니다.
00:06:51그래서 완전 관리형 버전인 ZillysCloud가 필요합니다. 동일한 API를 제공하면서 최대
00:06:5610배 더 빠르고, 단 한 줄의 코드도 변경하지 않고 몇 분 만에 설정할 수 있습니다.
00:07:00ZillysCloud에서 시맨틱 검색 쿼리를 실행해 본 결과, 키워드가 아니라 의미를
00:07:05이해하기 때문에 실제로 관련성 높은 결과가 나왔으며, 대규모 데이터셋에서도 응답 시간이 거의 즉각적이었습니다.
00:07:11또한 하나의 기사를 기준으로 추천 쿼리를 실행했습니다. 데이터셋 전체에서 가장 유사한 5개의 기사를 찾아내어
00:07:161초 만에 유사도 순으로 정렬해 주었습니다. 대시보드에서는 클러스터 성능, 스토리지 사용량,
00:07:21컬렉션 및 엔티티 개수를 포함한 데이터 지표를 실시간으로 추적합니다. 신용카드 필요 없이
00:07:27고정 댓글의 링크를 클릭하고 ZillysCloud를 무료로 체험해 보세요.
00:07:313단계는 엔지니어가 TDD로 코드를 검증하는 것과 같은 방식으로, 프로그래밍 방식으로 디자인을 테스트하는 것입니다.
00:07:36코드처럼 시각적으로 테스트를 작성할 수는 없다는 걸 압니다. 코드에는
00:07:41모든 것에 대한 명확한 입력과 출력이 존재합니다. 디자인은 더 주관적이고 코드처럼 수치화할 수 없기 때문에
00:07:46그러한 방식이 통하지 않습니다. 하지만 주관적이라고 해서 테스트를 작성할 수 없는 것은 아닙니다.
00:07:51코드에 TDD가 유용한 이유는 테스트가 동작 방식을 고정하고,
00:07:57구현부가 그 기준을 충족해야 하기 때문입니다. 디자인에도 방식만 다를 뿐 똑같은 아이디어가 적용됩니다.
00:08:01구축 중인 앱에서 첫 번째 단계는 이전과 마찬가지로 구현을 생각하기도 전에
00:08:05claude.md와 design.md 파일을 만드는 것이었습니다. 이제 테스트는 항상 코드보다 먼저 작성되어야 하며,
00:08:12그래야 구현부를 실제로 테스트할 수 있습니다. 구현 후에 테스트를 작성하면 에이전트가 나태해집니다.
00:08:17이미 컨텍스트에 코드가 존재하기 때문에 기존 코드에 최적화된 테스트 케이스만 대충 작성하게 됩니다.
00:08:22테스트를 먼저 작성하면 테스트가 구현에 맞춰지는 것이 아니라 구현이 테스트에 맞춰지도록 강제할 수 있습니다.
00:08:27따라서 디자인 파일을 테스트의 진실의 원천으로 사용합니다. 이 파일들에는 프로그래밍 방식으로
00:08:32검증할 수 있는 모든 안티 패턴이 포함되어 있기 때문입니다. design.md의 모든 안티 패턴이
00:08:37테스트 케이스가 됩니다. 모든 색상 규칙, 모든 간격 제약, 모든 타이포그래피 선택 사항에 대해
00:08:44프로그램 검증이 수행됩니다. Claude Code에 집중해야 할 각 섹션을 지정하는
00:08:49상세한 프롬프트를 주어 테스트 케이스를 작성하도록 했습니다. 또한 저희 콘텐츠가 마음에 드신다면
00:08:54좋아요 버튼을 눌러주세요. 이런 콘텐츠를 더 많이 만들고 더 많은 사람들에게 도달하는 데 큰 도움이 됩니다.
00:08:59프롬프트를 바탕으로 앱 디자인을 위한 모든 테스트 케이스를 작성해 줍니다.
00:09:04여러 종류의 테스트를 작성하는데, 먼저 프롬프트에서 언급한 안티 패턴을 직접 확인하는 정적 테스트가 있습니다.
00:09:09그런 다음 내부적으로 Playwright를 사용하여 사이트를 점진적으로 더 낫게 만드는
00:09:14회귀 테스트를 실행하는 시각적 테스트가 있습니다. 또한 scan 및 report 같은
00:09:19다른 컴포넌트와 헬퍼 함수를 위한 테스트 케이스도 작성합니다. 이러한 테스트는 정적 안티 패턴을
00:09:24확인하지만, 디자인 테스트에는 무언가 더 필요합니다.
00:09:28이를 위해 UI용 TDD를 수행하는 CLI인 Visly Test라는 또 다른 도구가 있습니다.
00:09:34작동 방식은 코드가 변경됨에 따라 디자인을 확인할 수 있는 로컬 TDD를 실행하는 것입니다.
00:09:39따라서 에이전트의 자체 모니터링에 의존하는 대신 직접 diff를 모니터링할 수 있습니다.
00:09:44메타데이터 및 기타 세부 정보가 포함된 더 나은 diff를 얻을 수 있어 검토가 빨라집니다.
00:09:49메타데이터가 없으면 두 스크린샷을 나란히 놓고 차이점을 찾기 바랄 뿐입니다. 반면 Visly는 정확히
00:09:54어떤 픽셀이 얼마나 변경되었는지 알려줍니다. 사용하려면 먼저 문서의 설치 명령어를 실행해 CLI를 설치하세요.
00:10:00설정 및 초기화가 완료되면 바로 사용할 수 있습니다. 이제 Claude Code를 열고
00:10:05Visly CLI를 테스트 매개체로 사용하여 TDD를 수행하고 원하는 UI 부분을 구현하라고 지시하면 됩니다.
00:10:10Visly TDD 명령을 실행하면 로컬 서버가 시작되어 스크린샷 변경 사항을 모니터링합니다.
00:10:16스크린샷을 전송하기 위해 Claude는 기본적으로 Visly라는 이름의 별도 테스트를 작성합니다.
00:10:21이 테스트들은 Playwright 스크린샷 메커니즘을 사용하여 서버의 뷰어로 이미지를 푸시합니다.
00:10:27거기서 디자인을 승인 또는 거부하고 이전 버전과 비교하는 diff를 볼 수 있습니다. 거부된 각 diff는
00:10:32에이전트가 다음 패스를 조정하는 데 사용하는 피드백이 됩니다. 몇 번의 반복을 거치면 디자인은 에이전트가 생각하는 방향이 아니라
00:10:37실제로 원하는 방향으로 수렴하게 됩니다. 여기서 사용된 프롬프트는 이 영상과
00:10:43모든 이전 영상에 대해 AI Labs Pro에서 찾을 수 있으며, 다운로드하여 자신의 프로젝트에 사용할 수 있습니다.
00:10:47저희 활동에서 가치를 느끼고 채널을 지원하고 싶으시다면 이것이 가장 좋은 방법입니다. 링크는 설명란에 있습니다.
00:10:52이것으로 이번 영상을 마칩니다. 채널을 지원하고 이와 같은 영상을 계속 만들 수 있도록 돕고 싶으시다면
00:10:57아래의 슈퍼 땡스 버튼을 통해 그렇게 하실 수 있습니다. 언제나 그렇듯
00:11:02시청해 주셔서 감사드리며 다음 영상에서 뵙겠습니다.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video