AI에게 디자인 능력을 심어보겠습니다

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

AI에게 디자인 능력을 심으려면 디자인 스킬뿐 아니라 참고 시안, 명확한 요구사항, 사람의 선택과 검토를 함께 제공해야 한다.

📌 핵심 요점

1. 다낭 3박 4일 여행 웹사이트로 Claude Design, Claude Code, Kimi Code, Impeccable 적용 작업을 비교했다. Claude Code는 빠르게 단순한 결과를 만들었고, Kimi는 일자별 이동과 호버 효과를 구현했지만 제작 시간이 길었다. 추가 질문과 스킬 적용 조건이 달라 엄밀한 동일 조건 비교로 보기는 어렵다.
2. Impeccable은 init으로 맥락을 설정하고 shape로 계획을 만든 뒤 craft로 구현한다. 시안을 보고 방향을 선택할 수 있으며, 기존 사이트에도 검토와 다듬기 기능만 적용할 수 있다. 다만 후속 보정의 시각적 효과는 즉시 구별하기 어려웠다.
3. 시각적으로 정돈된 화면도 기능과 접근성이 부족할 수 있다. Claude Design 초안에서는 일부 상호작용이 확인되지 않았고, 기존 사이트 감사에서는 탐색 랜드마크 부재, 문서 언어 미지정, 연결 대상 없는 레이블이 발견됐다.
4. 디자인 생성 이후의 연결 과정도 도구 선택에 영향을 준다. Open Design은 플러그인 설치만으로 실행되지 않았고, 전용 앱 설치 후에도 연결 규격 오류가 발생해 별도 앱에서 작업했다. HTML·ZIP 내보내기는 후속 개발의 출발점이 되지만, 공개 링크만으로 동적 기능과 데이터 영속성이 확보되는 것은 아니다.
5. 결과를 고르는 안목과 구체적인 참고 자료가 중요하다. Pinterest·Dribbble의 화면을 이미지로 전달하거나 템플릿과 디자인 시스템을 정하면 수정 방향을 명확히 할 수 있다. 화면이 많은 프로젝트는 대표 시안을 먼저 합의하고 나머지 화면으로 확장하는 접근이 제시됐다.

🧩 배경과 문제 정의

• AI가 만든 웹사이트의 디자인 품질을 높이기 위해 디자인 전용 도구, 기본 에이전트 기능, 외부 디자인 스킬의 차이를 비교한다.
• 공통 과제는 베트남 다낭 3박 4일 여행 일정과 가이드를 담은 웹사이트다. 간단한 요청으로 시작해 도구별 결과와 작업 과정을 비교하는 것이 목적이다.
• 시각적 완성도와 함께 실제 상호작용, 직접 수정, 코드 작업으로의 연결, 링크 공유 가능 여부도 확인해야 한다.
• 처리 구간에서는 일부 디자인과 공유 화면까지 확인됐지만, Kimi Code 결과와 Impeccable 적용 결과는 아직 완성되지 않아 최종 품질 비교가 남아 있다.

🕒 시간순 섹션별 상세정리

1. 디자인 스킬 Impeccable과 비교 과제

• Impeccable은 디자인 관련 오픈소스 스킬이며, 당시 확인한 GitHub 저장소의 별 수는 약 5만 9천 개다. 설치·사용 안내는 저장소에서 확인할 수 있다. [06:44]
• 비교 방식은 하나의 공통 주제로 여러 디자인 도구에 같은 작업을 맡기는 것이다. Claude Design도 비교 대상에 포함된다. [07:49]

2. Claude Design의 템플릿과 여행 웹사이트 요청

• Claude Design에는 HTML, 이메일, 슬라이드, 문서 등 여러 작업 유형과 디자인 시스템 선택지가 있다. 이번 작업에는 모더니스트 템플릿을 선택한다. [08:29]
• 입력 과제는 다낭 3박 4일 여행 일정과 여행 가이드를 웹사이트로 만드는 것이다. 세부 지시를 길게 작성하지 않고 간단한 프롬프트로 생성을 시작한다. [09:33]

3. Impeccable 설치와 적용 범위

• 설치에는 npx impeccable install을 사용하며, 설치 화면에서 사용 중인 AI 에이전트와 프로젝트 전용·전역 적용 범위를 선택한다. [10:48]
• 전역 설치와 디자인 훅 사용을 선택한 뒤 설치가 완료된다. 같은 스킬을 여러 에이전트에서 사용할 수 있는 상태가 된다. [11:21]

4. 네 가지 비교 경로와 기본 여행 조건

• 비교 대상은 Claude Design, Impeccable을 제외한 Claude Code, Kimi Code, Impeccable을 적용한 작업의 네 가지다. 외부 디자인 스킬 적용 여부에 따른 품질 차이를 확인하는 구도다. [11:46]
• Claude Design의 추가 질문에는 해변과 맛집을 우선하고 일정을 여유롭게 구성하는 조건을 넣는다. 페이지에 필요한 섹션도 함께 포함한다. [12:21]

5. 요구사항 질문과 단일 HTML 선택

• Impeccable 초기화 과정에서는 사이트의 성격과 디자인 형태를 먼저 묻는다. 디자인에 앞서 제품과 화면의 맥락을 구체화하는 절차가 필요하다. [15:07]
• Kimi Code 작업은 맛집과 현지 탐방을 균형 있게 담는 여행 스타일로 설정한다. 카카오톡이나 모바일로 옮겨 보기 쉽도록 React나 Next.js 대신 단일 HTML 파일을 선택한다. [15:57]

6. Claude Design 초안의 기능 범위와 편집

• Claude Design 초안에는 다낭 3박 4일 일정, 여행 기본 정보, 예산과 방문 장소가 들어간다. 날짜별 일정을 빠르게 훑어볼 수 있는 화면 구성이 만들어진다. [17:26]
• 확인한 초안에서는 교통 정보 등의 요소가 실제로 작동하지 않는다. 식당·숙소·상단 메뉴의 외형은 있지만 상호작용 구현은 확인되지 않는다. [18:01]

7. Impeccable의 시각적 후보 선택

• Impeccable 작업 중 여러 디자인 시안이 화면에 나타난다. 사용자는 실제 화면을 비교해 원하는 디자인 방향을 선택할 수 있다. [20:06]
• 원하는 후보는 ‘Build this’로 선택하고, 마음에 드는 후보가 없으면 ‘Reroll’로 새 선택지를 요청할 수 있다. 두 번째 시안을 선택해 후속 작업을 진행한다. [20:58]

8. 초기화와 구체적인 제작 계획의 분리

• Impeccable의 init 단계는 디자인 시스템 관련 문서를 만들고 제품·페이지의 맥락을 설정한다. 초기화가 끝난 뒤에는 다음 스킬을 호출해야 한다. [23:25]
• shape에 만들고 싶은 결과의 프롬프트를 전달하면 사이트 제작 계획을 구체화한다. 맥락 설정과 실제 제작 계획 수립이 서로 다른 단계다. [23:48]

9. Claude Code 기본 결과와 아티팩트 연결

• Claude Code 기본 결과는 필요한 정보를 중심으로 여행 일정을 압축한 형태다. 디자인의 시각적 완성도는 다소 평범하다는 주관적 평가지만, 핵심 정보를 빠르게 확인하는 구성에는 장점이 있다. [24:32]
• 간단한 웹사이트 제작 요청만으로 아티팩트 디자인 스킬이 작동하고 외부 미리보기가 열린다. Claude Design 쪽으로 작업이 연결된 듯한 인상은 있으나, 정확한 내부 처리 방식은 확인되지 않았다. [25:13]

10. 링크 공개와 호스팅 범위 확인

• 아티팩트 공유 화면에는 본인만 접근하는 설정과 링크를 가진 누구나 접근하는 설정이 있다. 공개 범위를 변경하면 링크 공유를 통한 접근이 가능할 것으로 예상된다. [25:45]
• 접근 권한을 누구나 볼 수 있도록 변경하고 링크를 전달해 접속 확인을 요청한다. 이 시점의 자막에는 다른 사용자의 접속 성공 여부가 확인되지 않는다. [26:52]

11. 미완성 비교 결과와 여행 정보의 검증 필요

• 별도 배포 명령 없이 Claude 사이트의 결과 화면이 열려 배포 방식과 기능 추가 시점을 확인 중이다. 같은 시점에 Kimi Code는 제작 중이고, Impeccable 적용 작업은 아직 계획 단계다. [28:46]
• 즉석에서 만든 여행 일정은 일반적인 구성에 머물며, 실제 활용에는 현지 조사와 정보 갱신이 필요하다. 방문 장소와 여행 관점에 따라 일정이 달라지므로 개인 경험과 선호를 반영한 보완도 남아 있다. [29:30]

12. 공개 공유 기능과 대화형 요구사항 설정

• 공개 링크 기능이 7월 13일부터 모든 요금제로 확대되면서, 초기 베타의 조직 내부 공유 제한을 넘어 외부 공개가 가능해졌다. 다만 동적 데이터까지 처리할 수 있는지는 별도 확인이 필요하다. [30:03]
• Impeccable은 여행 시기, 음식 중심 여부, 예산을 차례로 질문한다. 별도 질문 없이 곧바로 제작한 Claude 작업과 달리, 사용자 선택으로 사이트 요구사항을 구체화한다. [31:01]

13. 브라우저 데이터 저장과 호스팅 선택

• Vercel 같은 환경에서는 로컬 SQLite 파일의 변경 내용을 지속적으로 보존하기 어려워, 데이터 영속성을 확보하려면 Supabase 같은 외부 데이터베이스가 필요하다. [32:07]
• Wasm으로 컴파일한 SQLite를 이용하면 정적 호스팅에서도 브라우저 내부에 데이터를 저장할 수 있다. 다만 다른 브라우저로 옮기면 같은 데이터가 유지되지 않는 한계가 있다. [32:44]

14. 제작 속도와 기본 결과물의 차이

• Kimi Code는 요청하지 않은 단어를 반복하고 관련 검색까지 수행하며 작업이 지연된다. Impeccable은 계획과 템플릿 선택에 시간을 더 쓰므로 토큰 소비도 늘어날 가능성이 있다. [35:06]
• 같은 프롬프트로 작업한 Claude Code는 이미 제작과 배포를 마쳤다. 결과는 단순하고 깔끔하지만, 클릭 가능한 상세 정보와 사진이 부족해 추가 수정이 필요하다. [37:01]

15. 맥락 설정부터 구현·검토까지의 단계

• Impeccable은 init으로 맥락을 설정하고, shape로 계획을 만든 뒤, craft로 실제 코딩을 시작하는 순서로 작업한다. 구현 이후에는 검토 단계가 계속된다. [39:16]
• 단계별 작업의 목적은 AI 특유의 획일적인 디자인을 줄이는 데 있다. critique, audit, polish 같은 기능이 문제를 찾아 수정하는 과정을 보완한다. [40:03]

16. 기존 사이트에도 적용할 수 있는 디자인 검토

• 별도 스킬 없이 만든 Claude Code 사이트에도 Impeccable 검토 기능을 적용할 수 있다. 전체 제작 단계를 처음부터 반복하지 않고 필요한 기능만 중간에 호출하는 방식이다. [41:15]
• 처음부터 계획·구현하는 작업과 기존 결과물을 검토하는 작업이 별도로 진행된다. 기존 사이트 검토에는 두 개의 서브에이전트가 실행된다. [44:00]

17. 전역 설치와 프로젝트별 설치의 선택

• 전역 설치는 여러 프로젝트에서 스킬을 재사용하기 편하고, 프로젝트 내부 설치는 해당 폴더에 사용 범위가 한정된다. 스킬이 많다면 컨텍스트 부담을 고려해 프로젝트별로 나누는 선택도 가능하다. [45:18]
• 디자인 전용 로컬 프로젝트 폴더를 두고 그 안에서 작업하는 방식도 대안이 될 수 있다. 모든 프로젝트에 스킬을 설치하기보다 필요한 작업 공간에 모으는 접근이다. [45:54]

18. 150개 화면은 대표 시안과 디자인 시스템부터

• 화면 150개를 한 번에 제작하면 고객이 디자인을 거절했을 때 재작업 규모가 커진다. 대표 화면을 기준으로 약 세 가지 디자인 시안을 먼저 만들어 선택받는 편이 낫다. [46:24]
• 대표 시안을 확정한 뒤 Impeccable의 디자인 시스템 관련 마크다운 파일을 기준으로 나머지 화면을 확장할 수 있다. 초기 합의가 대량 화면 제작의 공통 기준이 된다. [47:38]

19. 라이브 편집 가능성과 한글 표시 문제

• Impeccable의 라이브 서버는 페이지를 열어 둔 채 대화하며 수정하는 기능으로 보인다. 다만 현재 화면에는 의미 없는 텍스트와 깨진 한글이 보여 결과 확인이 필요하다. [49:46]
• 이후 확인한 로컬 버전에서는 한글이 정상적으로 표시된다. 이 버전은 앞서 Claude AI에 배포한 사이트와 동일한 내용을 담고 있다. [52:15]

20. 디자인 비평과 기술 감사의 역할

• critic은 현재 사이트가 디자인 관점에서 얼마나 AI가 만든 듯한 인상을 주는지 검토하는 데 사용된다. 기존 결과물의 외형과 사용 경험을 평가하는 단계다. [52:36]
• audit은 접근성, 성능, 반응형 동작을 기술적으로 점검한다. 디자인 검토와 함께 실행하면 시각적 문제와 기술적 결함을 함께 확인할 수 있다. [52:51]

21. 랜드마크·언어·레이블에서 드러난 결함

• 약 850줄 문서에 main이나 navigation 랜드마크가 없어 스크린리더가 내용을 선형으로 훑어야 하는 문제가 발견된다. 페이지의 시각적 정돈만으로는 탐색 접근성이 확보되지 않는다. [54:21]
• 문서 언어 미지정과 연결 대상이 없는 레이블 문제도 확인된다. 두 평가가 완료되면서 기술적 결함과 디자인 문제에 대한 수정 제안까지 확보된다. [54:39]

22. 항목별 점수로 확인한 개선 필요성

• 디자인 평가에서 시스템 상태 가시성은 2점, 현실 세계와의 일치는 4점, 사용자 통제와 자유는 1점, 일관성과 표준은 3점이다. 특히 사용자 통제 항목의 점수가 낮다. [56:01]
• 총점은 40점 만점에 약 20점으로 보이며, 평균적인 수준이라는 잠정 평가가 붙는다. 기술 문제 목록도 함께 있어 후속 수정 대상을 구체적으로 확인할 수 있다. [56:15]

23. 최종 다듬기와 처음부터 설계한 결과물

• 분석이 끝난 뒤 polish를 실행해 최종 다듬기에 들어간다. 기존 사이트 개선 작업과 Impeccable을 처음부터 적용한 작업 모두 마무리 수정 단계로 넘어간다. [57:52]
• Impeccable로 계획·설계·코딩한 사이트는 어두운 화면에 노란색과 굵은 글꼴을 사용해 강한 인상을 준다. 다만 대각선 요소의 의도는 명확하지 않다. [59:16]

24. 여행 사이트의 탐색 구조와 디자인 검토

• 여행 사이트는 상단에서 1~4일 차로 이동하거나 아래로 스크롤해 전체 일정을 볼 수 있다. 여러 텍스트에 대각선이 있지만 그 용도는 불분명하다. [1:00:03]
• 디자인 검토 후 보정 단계에서는 착시 표현의 정확도나 밝은 테마의 대비처럼 수정할 항목을 선택한다. 기존 Claude Code 결과물의 검토와 후속 수정에도 Impeccable을 적용한다. [1:01:00]

25. 기술·디자인 병렬 검토와 플러그인 설치

• 두 에이전트가 백그라운드에서 기술과 디자인 관점의 검토를 진행한다. 검토가 끝나면 후속 보정 작업으로 넘어갈 예정이다. [1:02:45]
• 데스크톱 앱의 플러그인 목록에서 Open Design을 검색해 설치할 수 있다. 재설치 과정은 간단하며, 설정에는 생성 기능을 켜는 항목 외에 별다른 선택지가 보이지 않는다. [1:04:31]

26. 명시적으로 선택한 플러그인의 인식 실패

• Open Design을 활성화한 상태에서 다낭 3박 4일 여행 일정과 안내를 담은 웹페이지를 요청한다. 기존 사용 경험에서도 플러그인을 명시적으로 선택했는데 도구를 찾지 못하는 문제가 있었다. [1:05:35]
• 설치 후에도 Open Design을 인식하지 못해 새 대화에서 다시 시도하라는 안내가 나온다. 재설치에 이어 대화를 새로 여는 절차까지 필요해진다. [1:07:12]

27. 실행 환경 혼선과 별도 서비스의 비용 조건

• Codex와 Work 사이에서 실행 위치를 바꾸며 재시도하지만 정상 실행에 도달하지 못한다. 앱의 기능 위치와 플러그인 호출 문제가 겹쳐 사용 경로가 혼란스럽다. [1:09:02]
• 플러그인이 연결하는 대상은 오픈소스 실행 환경과 구분되는 Open Design 전용 앱이다. 당시 확인한 서비스에는 별도 가입과 토큰이 필요하며, 20·100·200달러 등의 구독 선택지가 있다. [1:10:03]

28. Kimi 결과물의 상호작용과 생성 시간

• Kimi의 여행 사이트 생성에는 약 30분이 걸렸다. 일자별 이동과 마우스를 올렸을 때의 효과는 작동하지만, 화면 규모에 비해 제작 시간이 길다는 평가다. [1:12:26]
• 일정의 X 표시는 삭제 기능이 아니라 당일 컨디션에 따라 생략할 수 있는 선택 활동을 뜻한다. 다낭에서 호이안까지 택시비는 약 35만 동, 원화 약 1만 7천 원으로 적혀 있다. [1:13:27]

29. 후속 보정의 불분명한 효과와 생성 도구 연결 오류

• 기존 Claude Code 사이트에 Impeccable 검토와 최종 보정을 적용하고 배포까지 마쳤지만, 전후 화면에서 어떤 부분이 달라졌는지 즉시 식별하기 어렵다. 구체적인 변경 내역 확인이 필요하다. [1:14:40]
• Open Design은 설치된 상태인데도 현재 작업에 생성 도구가 연결되지 않았다는 오류가 발생한다. Codex에서 실행하라는 안내에 이어 앱 재시작을 시도한다. [1:15:54]

30. 반복된 실행 실패와 디자인 결과 비교

• Codex와 ChatGPT 등 여러 위치에서 시도해도 Open Design이 작동하지 않는다. 이후 등록 상태와 별개로 맥에 전용 앱이 없다는 점을 확인한다. [1:17:53]
• 비교 대상은 Kimi Code, Impeccable을 처음부터 적용한 사이트, Claude Code 결과를 Impeccable로 개선한 사이트, Claude Design 결과물이다. 디자인의 우열은 사용자 취향에 따라 달라질 수 있다. [1:19:57]

31. 전용 앱 설치와 인수설의 불확실성

• 플러그인과 연결할 Open Design 전용 앱을 직접 내려받아 설치한다. 다운로드 파일은 약 670MB이며, 플러그인 설치만으로는 해결되지 않았던 호출 문제를 다시 확인한다. [1:20:32]
• OpenAI 인수설에는 공식 발표가 확인되지 않은 상태다. 인수를 전제로 별도 구독 정책을 해석하기에는 근거가 부족하다. [1:21:29]

32. 로컬 에이전트 설정과 프로젝트 관리 기준

• 모델 실행 방식에는 호스팅 서비스, API 키 사용, 로컬 에이전트 선택지가 있다. 로컬 에이전트에서 Codex CLI를 선택하고 연결을 테스트해 설치된 에이전트를 활용하려 한다. [1:22:51]
• 디자인·마케팅·개발별 폴더 구분은 템플릿 관리에 적합할 수 있다. 실제 적용 결과물은 프로젝트별로 나누어 관리하는 편이 낫다는 판단이다. [1:23:25]

33. 로컬 선택 후에도 나타나는 업그레이드 요구

• 로컬 에이전트를 선택했는데도 요금제 업그레이드 화면이 나타난다. 이후 별도 앱에서 로컬 에이전트와 GPT 5.6을 설정해 다시 실행한다. [1:24:05]
• 생성한 디자인은 실제 프로젝트와 연결해야 한다. 여행 페이지 설정에서는 출발 시기, 미식 여행 같은 선호 유형, 랜드마크 사진을 선택하며, 실행 에이전트 표시에 Codex가 나타난다. [1:25:24]

34. 데스크톱 앱 설치 이후의 부분적인 연동 성공

• Open Design 데스크톱 앱을 설치한 뒤 Codex와의 연동을 다시 시도한다. 별도 앱 안에서의 작업과 Codex에서의 호출이 모두 가능한지 확인하는 단계다. [1:26:12]
• 데스크톱 앱 설치 이후 연동 단계까지는 작동한다. 다만 이 시점에는 다음 디자인 작업까지 정상 진행되는지는 확인되지 않았다. [1:27:45]

35. 연결 규격 오류와 별도 앱 사용

• Open Design 0.17.0이 당시 최신 버전인데도 연결 규격을 지원하지 않는다는 오류가 발생한다. 연결 이후 실제 디자인 작업으로 넘어가지 못해 Codex 내부 연동의 안정성이 부족하다. [1:28:17]
• Codex에서 다음 디자인 작업으로 이어지지 않아, 별도로 설치한 Open Design 데스크톱 앱에서 작업을 진행한다. [1:28:45]

36. 기본 디자인 능력과 템플릿 활용의 구분

• 초기 Claude Code 작업에는 특정 디자인 시스템을 적용하지 않았다. 해당 결과물은 별도 스타일 체계 없이 생성한 기본 디자인 능력을 비교하는 기준이다. [1:29:28]
• Impeccable에서 제공하는 스타일을 내려받아 템플릿처럼 활용할 수 있다. 이를 이용하면 초기 디자인 기획 단계부터 여러 템플릿 가운데 원하는 방향을 선택할 수 있다. [1:29:41]

37. 사이트 목적에 따른 디자인 투자와 스킬 선택

• 외주·납품용 사이트는 디자인에 더 많은 시간을 투자필요가 있다. 개인용 사이트는 추가 스킬의 토큰 소비를 고려해 기본 프롬프트만으로 제작하는 선택도 합리적이다. [1:31:19]
• 모델과 실행 도구가 발전하면 별도 스킬 없이도 자연스러운 디자인을 얻을 가능성이 있다. 기존 보조 스킬과 작업 방식의 필요성도 계속 재평가해야 한다. [1:32:05]

38. Open Design의 에이전트 교체와 결과물 활용

• Open Design에서 기본 에이전트인 Codex CLI로 만든 결과를 확인한 뒤 Claude Code로 전환한다. 같은 사이트를 다시 생성해 에이전트에 따른 디자인 차이를 비교하는 단계다. [1:33:44]
• 결과물은 ZIP 또는 독립 실행형 HTML로 내보낼 수 있다. ZIP을 프로젝트에서 열면 생성한 디자인을 바탕으로 후속 개발을 진행할 수 있다. [1:34:28]

39. PRD 공유와 사람의 검증으로 설계·구현 차이 줄이기

• 디자인 단계와 코딩 단계에 동일한 PRD를 제공하면 기능과 화면의 불일치를 줄일 수 있다는 가설이다. 이번 작업에는 실제 PRD가 없어 그 효과를 검증하지는 못했다. [1:35:23]
• PRD의 구성 품질뿐 아니라 요구한 화면·메뉴·세부 UI가 결과물에 반영됐는지 확인하는 과정이 필요하다. AI에게 재검사를 맡길 수 있어도 최종 판단을 누가 책임질지는 남는 문제다. [1:36:33]

40. Stitch 목업을 먼저 만들고 코드 작업으로 연결하기

• 디자인 AI에서 시안을 충분히 다듬고 내려받은 뒤 Claude나 Codex로 개발을 이어가는 작업 흐름이 가능하다. 당시 Stitch 화면의 사용 한도는 하루 400크레딧이다. [1:39:21]
• Stitch에서는 프롬프트 수정뿐 아니라 텍스트와 여러 요소를 직접 편집할 수 있다. 목업을 HTML로 내려받아 프로젝트에 가져오면 후속 구현의 출발점으로 활용할 수 있다. [1:39:52]

41. Stitch의 화면 일관성과 이미지·언어의 영향

• Stitch의 내보내기 선택지에는 Figma, AI Studio, MCP, ZIP 등이 있다. 다만 과거 사용 경험에서는 여러 화면 사이의 디자인 일관성이 부족했으며, 현재 개선 여부는 확인되지 않았다. [101:17] [1:40:07]
• 이미지와 영문 표기가 디자인을 더 좋아 보이게 할 가능성이 있고, 한국어로 바꾸면 인상이 달라질 수 있다. 관련 이미지를 검색·보충하는 작업은 별도 스킬로 개선할 여지가 있다. [102:03] [1:40:22]

42. 도구 선택의 기준이 되는 디자인 안목

• 선호하는 디자인 원칙과 스타일을 정하고 좋은 결과를 알아보는 능력이 중요하다. Canva의 웹사이트 템플릿은 다양한 구성을 비교하며 취향과 판단 기준을 구체화할 참고 자료가 된다. [103:01] [1:40:37]
• Canva에서는 웹사이트를 꾸미고 영상도 만들 수 있지만, 템플릿이라고 모두 만족스러운 디자인은 아니다. 결과물의 품질을 직접 구별하는 안목이 도구 활용의 핵심 조건이다. [104:26] [1:40:52]

43. Pinterest 참고 자료와 상호작용을 활용한 스타일 개선

• Pinterest에서 원하는 분위기의 사이트를 찾아 Claude Code에 참고 자료로 전달할 수 있다. 검색 결과 중 적합한 디자인을 선별하는 능력이 있어야 참고 자료도 효과를 낸다. [105:45] [1:41:03]
• 다섯 개의 카드가 가로로 놓였다가 마우스를 올리면 기울어지는 사례처럼, 배치뿐 아니라 상호작용도 참고 대상이다. 이런 동작을 적절히 적용하면 정형적인 AI 디자인에서 벗어날 가능성이 있다. [106:34] [1:42:15]

44. Dribbble의 구체적인 사례를 이미지로 전달하기

• Dribbble에서 대시보드나 여행 관련 디자인을 검색하면 목적에 맞는 참고 사례를 찾을 수 있다. 여행 사례에는 장소 사진을 배경으로 카드가 옆으로 이동하고 선택한 카드가 위로 올라가는 동작이 있다. [107:39] [1:43:28]
• 참고 화면을 캡처해 원하는 스타일과 함께 전달하면 말만으로 설명할 때보다 시각적 의도를 명확하게 전달할 수 있다. 이미지가 디자인 수정의 구체적인 기준이 된다. [108:30] [1:44:40]

45. Claude 결과의 단조로움과 개인 템플릿 스킬

• Open Design에 Claude를 연결한 결과는 단순하고 색채가 적으며 초기 Claude Design 결과와 형태가 비슷하다. 참고 이미지를 추가하면 기존 정보를 유지하면서 외형을 바꾸는 방향으로 보완할 수 있다. [108:56] [1:45:52]
• 좋은 참고 디자인을 개인 템플릿으로 만들고 스킬로 구성하는 방법도 가능하다. 여러 템플릿을 적절히 조합하면 반복적인 AI 스타일을 줄일 수 있다는 기대다. [109:47] [1:47:04]

46. 제작 방식 비교와 사용자 지정 디자인 시스템

• 비교 대상에는 Kimi Code가 30~40분 이상 작업한 화면, Claude Code에서 Impeccable 스킬을 활용한 화면, 기본 생성 후 마지막에만 스킬로 다듬은 화면이 있다. 제작 과정과 스킬 적용 시점이 서로 다르다. [110:20] [1:49:06]
• Claude Design의 결과도 디자인 시스템 적용과 사용자 경험에 따라 개선될 여지가 있다. 당시 기본 디자인 시스템은 6개이며, 원하는 느낌을 지정하고 폰트·로고·자산을 추가해 직접 구성할 수 있다. [110:50] [1:49:21]

47. 웹사이트를 넘어선 Claude Design 활용과 영상 길이 제약

• Claude Design의 작업 유형에는 모바일 앱, 슬라이드, 와이어프레임, 짧은 애니메이션 영상이 포함된다. 이메일·3D·이력서·UI 목업·다이어그램으로도 활용 범위가 넓어진다. [111:54] [1:52:09]
• 애니메이션 결과의 품질에 대한 평가는 긍정적이지만 생성 영상의 길이가 짧다는 제약이 있다. 슬라이드는 미니멀한 디자인이 장점으로 평가되며, 결과의 선호도에는 주관이 개입한다. [112:51] [1:52:24]

48. 사용 자료 공유와 다음 작업 주제 수렴

• 단체 채팅방의 공유 예정 자료에는 Kimi Code로 만든 사용 매뉴얼, 이번에 다루지 않은 Taste 계열 스킬 3종, Holland 프롬프트가 포함된다. 실습에 사용한 스킬도 공유 대상이다. [113:38] [1:53:05]
• 다음 주 작업 주제는 채팅방에 모인 의견을 반영할 예정이다. 이번 실습은 사용 자료의 후속 공유와 다음 주제에 대한 의견 수렴을 남기고 종료된다. [114:05] [1:54:17]

🧾 결론

• 이번 실습은 특정 도구의 압도적 우위보다 제작 속도, 시각적 취향, 기능 완성도, 연동 편의성 사이의 차이를 보여준다. 후반에는 Kimi와 Impeccable 결과도 확인했지만, 객관적인 최종 순위는 확정하지 않았다.
• 기본 생성 결과에 필요한 검토만 추가하는 방식과 처음부터 디자인 스킬로 설계하는 방식 모두 선택지가 된다. 적용 시점에 따른 개선 효과와 추가 비용을 함께 확인해야 한다.
• 좋은 디자인을 얻으려면 원하는 스타일을 구체화하고, 화면·메뉴·상호작용이 요구사항에 맞는지 사람이 확인해야 한다. AI의 자체 검토만으로 최종 판단 책임이 해결되지는 않는다.

📈 투자·시사 포인트

• 도구 도입 비용은 구독료뿐 아니라 생성 시간, 토큰 소비, 연동 문제 해결, 후속 수정까지 포함해 판단필요가 있다. 이번 실습에서는 긴 생성 시간과 반복된 연결 실패가 실제 작업 부담으로 드러났다.
• 개인용 단순 사이트는 기본 생성과 자체 호스팅으로 충분할 수 있지만, 외주·납품용 사이트는 디자인 합의와 기능 검증에 더 많은 시간을 배정할 이유가 있다. 목적에 따라 디자인 투자 수준을 달리하는 접근이다.
• 대량 화면 제작에서는 대표 시안과 디자인 시스템을 먼저 확정하는 것이 재작업 규모를 줄이는 방법으로 제시됐다. 생성량보다 초기 합의의 품질이 제작 효율에 영향을 줄 수 있다.
• 모델과 실행 도구의 기본 디자인 능력이 발전하면 보조 스킬의 필요성도 달라질 수 있다. 특정 도구를 고정적으로 채택하기보다 추가 품질과 비용을 주기적으로 재평가할 필요가 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 디자인 평가는 주관적이며, 도구별 추가 질문·템플릿·스킬 적용 조건도 달랐다. Kimi의 작업 시간은 약 30분과 30~40분 이상으로 표현돼 정확한 성능 비교 수치로 사용하기 어렵다.
• Impeccable 보정 이후 어떤 요소가 실제로 개선됐는지 변경 내역과 재검증 결과가 충분히 제시되지 않았다. 약 40점 만점에 20점이라는 평가도 잠정적인 관찰이다.
• 공개 링크의 다른 사용자 접속 성공 여부와 동적 데이터 지원 범위는 확인되지 않았다. 요금제, 공개 공유 정책, 사용 한도와 버전 정보는 시연 당시 조건으로 구분해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 여행 조건, 필수 화면, 메뉴와 클릭 동작을 하나의 요구사항 문서로 정리하고 비교 도구에 동일하게 제공한다.
• 선호하는 참고 화면과 대표 시안 약 세 가지를 비교해 디자인 방향을 확정한 뒤 전체 화면으로 확장한다.
• 기본 생성, 처음부터 Impeccable 적용, 마지막 검토만 적용한 결과의 작업 시간·토큰 소비·변경 내역을 기록한다.
• 메뉴와 일정 이동, 모바일 화면, 문서 언어, 랜드마크, 레이블 연결을 점검하고 보정 후 같은 항목을 다시 확인한다.

❓ 열린 질문

• 동일한 요구사항과 참고 이미지를 제공했을 때 외부 디자인 스킬은 기본 에이전트보다 얼마나 일관되게 좋은 결과를 만드는가?
• 처음부터 설계하는 방식과 마지막에만 검토하는 방식 중 어느 쪽이 추가 시간과 토큰 대비 개선 효과가 큰가?
• 동일한 PRD를 공유하면 디자인 시안과 실제 구현 사이의 기능 누락이 얼마나 줄어드는가?