현직 디자이너들이 만든 디자인 하네스 분석하기

한 줄 핵심

디자이너가 만든 AI 디자인 하네스 사례를 해부하며, 좋은 디자인 하네스는 질문 설계·검증 게이트·도구 연동·병렬 처리까지 포함한 실행 체계여야 한다는 점을 보여준다.

시간별 요약

2:09
행사와 분석의 배경 한스톤 행사에서 디자이너와 개발자가 함께 AI 디자인 하네스를 만들었고, 그 결과물과 얻은 인사이트를 뜯어보는 흐름으로 진행된다. 핵심은 디자인 결과물이 아니라, 비전문가도 고퀄리티 결과를 낼 수 있는 하네스 자체를 만드는 데 있었다.
4:01
문제 정의와 주제 선정 AI 디자인 결과가 사람 수준의 품질에 아직 못 미친다는 문제의식에서 출발해, 이를 보완할 하네스를 설계하려 했다. 주제로는 누구나 공감하기 쉬우면서도 정형화되지 않은 청첩장 모임 관리 앱을 골라, 과적합 없이 일반화된 하네스를 만들고자 했다.
7:07
하네스가 지켜야 할 원칙 PRD를 정답처럼 따르지 않고 질문과 반박을 통해 숨은 의도를 파악하도록 만드는 것이 중요하다. 사용자 입력을 그대로 믿지 말고, 더 나은 UI/UX를 위해 질문을 고도화하고 판단을 보정하는 구조가 핵심이다.
11:00
평가 기준: 좋은 질문과 완충 장치 비전문가도 답하기 쉬운 질문을 던지되, 답변에서 유의미한 인사이트를 얻을 수 있어야 한다. 폰트처럼 전문 영역을 직접 묻기보다 화면 비교나 선택형 피드백처럼 한 단계 추상화된 질문이 더 좋은 인터뷰를 만든다.
13:03
스킬 구조와 가드레일 설계 대상, 모바일 앱 범위, 프레임 사이즈, 데스크톱 개념 배제 같은 제약을 명시해 불필요한 출력과 오버엔지니어링을 막았다. 질문 대신 결과물을 먼저 보여주고 피드백을 받게 하며, 와이어프레임보다 실제 체험 중심으로 유도하는 설계가 돋보였다.
15:01
템플릿·복사 기반의 빠른 스캐폴딩 디자인 폴더를 만들고 템플릿을 복사해 채우는 방식으로 시작 비용을 줄였다. 사용자가 선택한 내용뿐 아니라 에이전트가 임의로 결정한 내용까지 폴더 안에 저장하게 해, 실행 중 산출물이 흩어지지 않도록 구성했다.
27:03
프로그램 검증과 병렬 처리 LLM이 잘했는지 다시 스크립트로 검증하는 게이트가 들어가 있어, 문서 갱신이나 선택 항목 누락 같은 오류를 빠르게 잡았다. 사람이나 다른 에이전트에게 검증을 맡기기보다 프로그램적으로 확인하면 속도와 신뢰성이 함께 올라간다.
37:04
실제 사용 흐름과 피드백 루프 화면을 순차적으로 따라가며 홈, 일정 편집, 부모님 보기 같은 시나리오를 직접 검토하는 구조가 잘 작동했다. 각 화면에서 어색한 부분을 바로 지적하고 수정할 수 있어, 결과물의 품질이 피드백 루프를 통해 점진적으로 올라갔다.
55:01
구조 이해 후 최적화 제안 작업 전에 구조를 먼저 파악하게 한 뒤 프롬프트를 더 뾰족하게 조정하는 접근이 효과적이었다. HTML 전체를 생성하는 대신 Markdown/JSON과 스크립트 렌더링으로 바꾸거나, React 컴포넌트로 옮겨 분량과 렌더링 비용을 줄일 수 있다는 개선 아이디어도 제시된다.
1:08:09
하네스의 가치와 한계 혼자 바이브 코딩할 때는 하네스의 유지보수 비용이 이익보다 클 수 있지만, 팀 단위로는 일관성과 재사용성을 크게 높인다. 다만 디자인 시스템처럼 상태와 변형이 많아질수록 유지보수 난도가 커지며, 엔지니어링 기반의 관리가 함께 필요하다.
2:07:01
AI 시대에 더 중요한 역량 코딩 자체보다 의사결정, 소프트웨어 엔지니어링, 컨텍스트 파악, 인터뷰 능력이 더 중요하다는 관점이 강조된다. AI는 프로그래밍은 잘해도 현실 맥락과 미세한 사용자 반응까지 읽는 인터뷰는 약하기 때문에, 사람의 판단력이 여전히 핵심 경쟁력이다.

실무 인사이트

디자인 하네스는 결과물 생성기가 아니라, 질문·검증·피드백을 통해 품질을 안정화하는 실행 체계로 설계해야 한다.
LLM에게 모든 검증을 맡기기보다 스크립트와 규칙 기반 게이트로 오류를 먼저 걸러야 속도와 신뢰성을 동시에 확보할 수 있다.
혼자 쓰는 도구는 유연성이 중요하지만, 팀에서 쓰는 하네스는 템플릿·제약·병렬 처리·공유 규칙이 성과를 크게 좌우한다.