핵심 요약

  • 웹사이트의 성패는 시각적 인상만으로 판단할 수 없다. 제품의 용도와 사용자가 취할 행동이 분명한지, 실제 전환으로 이어지는지가 중요하다.
  • AI가 만든 화면에서 반복되는 효과와 구성은 사용자의 주의를 빼앗을 수 있다. 애니메이션과 데모는 제품의 가치를 이해시키는 데 기여해야 한다.
  • 민감한 데이터에 접근하는 AI 제품은 데이터 접근 범위와 사용 방식, 보관 정책을 구체적으로 설명해야 한다는 것이 대담의 주요 지적이다.
  • Magic Patterns는 고객 대화와 실제 사용을 바탕으로 방향을 찾았다. 사내 제품 사용과 고객 지원에서도 사용자가 막히는 지점을 직접 확인한다.

프런트엔드 엔지니어가 찾은 디자인 도구의 출발점

Y Combinator의 디자인 리뷰에서 Magic Patterns 공동창업자 겸 CEO 알렉스는 자사 도구를 시연하고 스타트업 웹사이트를 평가했다. Magic Patterns는 제품 관리자, 창업자, 디자이너가 아이디어를 상호작용 가능한 시제품이나 실제 제품에 사용할 코드로 표현하도록 돕는 AI 디자인 도구다.

공동창업자 두 사람은 디자이너가 아닌 프런트엔드 엔지니어였다. 처음 YC에 지원했을 때의 제품은 매출이 있던 문자 메시지 분석기였다. 그러나 YC 파트너는 자신들이 잘 아는 문제에 집중하라고 권했다. 두 사람이 익숙했던 일은 Figma 시안을 코드로 옮기는 작업이었다.

지금의 제품에 도달하기까지 약 9개월이 걸렸다. 컴포넌트 라이브러리 편집기와 로컬 개발 화면을 인터넷에 바로 공개하는 피드백 도구 등을 시도했다. 알렉스는 이전 시도에서는 돈을 내고 실제로 사용하는 열성 고객 10명을 확보하지 못했지만, Magic Patterns를 출시한 뒤에는 그런 사용자가 빠르게 모였다고 설명했다.

제품이 자리 잡은 뒤에도 작업 방식은 계속 바뀌었다. 사내 해커톤에서 만든 MCP 연동 기능은 당초 큰 기대를 하지 않았지만, 그의 설명에 따르면 이후 주요 이용 경로 중 하나가 됐다. 고객이 도구를 사용하는 방식에 맞춰 회사도 계속 변해야 한다는 것이다.

AI 디자인의 입력은 짧은 지시문보다 넓다

시연의 중심은 여러 시안과 자료를 함께 놓는 캔버스였다. 이미지를 비롯해 제품 요구사항 문서와 행사 메모를 올리고, 이를 바탕으로 여러 디자인을 동시에 만들었다. 도시별 행사 사진으로 엽서를 만든 뒤, 특정 도시의 설명을 반영해 수정하고 그 변경을 다른 도시에도 적용하는 방식이다.

MCP는 이 시연에서 Cursor 같은 다른 도구와 Magic Patterns를 연결하는 통로로 쓰였다. 알렉스는 기업들이 코딩 도구에 쌓인 요구사항 문서와 회의록을 활용해 아이디어를 시각화한다고 설명했다. 로컬 컴퓨터에서만 실행되던 시제품을 다른 사람과 공유하려는 수요도 있다고 했다.

다만 캔버스가 모든 사용자에게 맞는 것은 아니다. 그는 하나의 대화창으로 시작한 사용자에게 언제 캔버스를 보여줄지, 기능을 어떤 순서로 드러낼지가 온보딩의 과제라고 밝혔다.

더 나은 결과를 얻는 방법으로는 회사의 기존 디자인 체계와 재사용 가능한 화면 구성요소, 작업 지침을 먼저 제공하는 일을 꼽았다. 재미로 만든 3D 테마파크 시연에서도 놀이기구와 길 등을 구성요소로 정하고 이를 생성의 기준으로 활용했다. 그는 이 사례가 흔한 사용 방식은 아니라고 선을 그었다.

Ego: 개성 있는 화면에서도 목적은 보여야 한다

개인용 AI 에이전트를 만드는 연구소로 소개된 Ego의 사이트는 어두운 화면과 붉은색, 복고풍 게임을 연상시키는 시각 요소를 사용했다. 두 사람은 그 개성을 인정하면서도 제품과 방문 목적을 이해하기 어렵다고 지적했다.

상단 버튼에는 Ronin이라는 이름이 있었지만, 그것이 제품인지 모델인지 알기 어려웠다. 대기자 명단 등록이 핵심 행동이라는 점도 상당히 내려간 뒤에야 드러났다. 알렉스는 실제 전환 데이터를 모르므로 사이트의 성과를 단정할 수 없다고 전제했다.

진행자는 자신이 일했던 Creative Market의 실험을 사례로 들었다. 이메일 입력란을 페이지에 바로 펼쳐놓았을 때, 클릭하거나 창을 띄워야 입력할 수 있는 경우보다 전환율이 훨씬 높았다는 설명이다. 구체적인 수치는 제시하지 않았다.

입력창처럼 보이지만 실제로는 글자를 입력할 수 없는 요소도 문제였다. 방문자가 작동 여부를 확인하느라 사이트의 핵심 행동에서 멀어졌기 때문이다. 이 리뷰에서 AI가 만든 듯한 흔적이 문제가 된 이유는 취향보다 사용자의 주의를 어디로 보내는가에 있었다.

Sentient OS: 움직임은 설명을 돕고, 조작은 예측 가능해야 한다

Sentient OS는 기기 안에서 실행되는 대규모 언어모델이 사용자의 맥 환경을 이해하고 작업을 돕는 제품으로 소개됐다. 사이트에서는 자료가 노트북으로 들어가고, 덮개가 닫혔다가 다시 열리며 완료된 작업이 나타났다.

진행자는 이 애니메이션이 사용자가 자는 동안 작업이 진행된다는 제품의 메시지를 전달한다고 평가했다. 정적인 화면보다 개념을 잘 설명하는 움직임이라는 것이다.

반면 스크롤 동작을 사이트가 별도로 제어하는 방식은 비판했다. 원하는 위치에 화면을 맞추기 어렵고, 평소 예상하는 스크롤 감각과 달라 불편하다는 이유였다. 알렉스는 다운로드 버튼과 무료라는 정보도 너무 작아 읽기 어렵다고 지적했다. 설명을 위한 효과가 좋아도 핵심 정보와 행동이 묻히면 문제가 된다는 평가다.

이 제품은 신뢰 문제도 드러냈다. 진행자는 컴퓨터의 많은 정보에 접근하는 AI 도구라면 어떤 데이터를 읽고 어떻게 사용하며 얼마나 보관하는지 적극적으로 설명해야 한다고 주장했다. 그런 설명이 다운로드와 사용을 유도하는 데 도움이 될 것이라는 전망이었다.

알렉스는 과거 문자 분석기에서 오픈소스이며 모든 처리가 기기 안에서 이뤄진다는 점을 첫 화면에 강조했다고 밝혔다. 사용자들이 특히 중요하게 여긴 정보였다는 것이다.

추상적인 회사 소개와 복잡한 데모의 한계

다른 기업용 AI 사이트는 회사 기록을 읽고 운영상의 비효율을 찾아 문제가 커지기 전에 경고한다고 설명했다. 하지만 두 사람은 추상적인 표현이 많아 구체적으로 무엇을 해결하는지 알기 어렵다고 평가했다. 설치가 필요 없다는 설명이나 고객군 분류도 제품의 용도를 이해하기 전에는 도움이 제한적이었다.

진행자는 이런 구성이 사용자를 위한 제품 설명보다 투자자에게 회사를 소개하는 발표 자료에 가까워질 수 있다고 지적했다. 사용자가 확인하려는 것은 자신의 문제를 해결하는 방식, 사용 대상, 비슷한 고객이 얻은 효과라는 설명이다. 두 사람은 시각적으로 깔끔하다는 점과 상단에 신뢰·보안 안내를 배치한 점은 긍정적으로 봤다.

이메일 제품 Slashy는 상대적으로 용도가 분명했다. 사용자 문체에 맞는 답장 작성, 일정 조율, 후속 연락이라는 설명으로 무엇을 하는 제품인지 바로 이해할 수 있었다. 그러나 큰 데모 영상은 글과 움직임이 많아 핵심을 따라가기 어려웠다. 반대로 사용자 문체에 맞춰 문장을 수정하는 모습을 집중해서 보여주는 애니메이션은 좋은 평가를 받았다.

자동 전환되는 탭도 한계로 꼽혔다. 방문자는 다른 탭에 숨은 내용을 보지 못할 수 있고, 잠깐 스크롤하는 동안 타이머가 시작되면 중요한 첫 설명을 놓칠 수 있다. 두 사람은 Slashy의 타이머가 해당 구역을 볼 때 시작되는 것으로 관찰하면서도, 화면을 오가는 과정에서 중간 항목부터 보게 되는 상황을 짚었다.

고객 추천에도 해석이 따른다. 투자자와 창업자의 후기는 신뢰를 줄 수 있지만, 방문자에게 그들만을 위한 이메일 제품이라는 인상을 줄 수도 있다고 알렉스는 설명했다.

디자인 기준을 고객의 실제 경험에 연결하는 법

두 사람은 AI 도구가 반복해서 내놓는 글꼴과 강조 방식, 효과를 그대로 쓰는 대신 회사가 전달하려는 인상을 정해야 한다고 봤다. 알렉스는 브랜드와 글꼴, 디자인 체계를 더 일찍 정하지 않은 것을 아쉬운 점으로 꼽았다.

Magic Patterns에서는 전 직원이 고객 지원을 맡는다. 알렉스는 같은 색의 주요 버튼 두 개 때문에 사용자가 공유 버튼을 찾지 못하는 상황을 예로 들었다. 엔지니어가 지원 과정에서 문제를 직접 경험하면 수정으로 이어질 수 있다는 설명이다. 사내에서 자사 제품을 사용할 때도 사용을 강제하지 않고, 선택하지 않은 순간을 살핀다고 했다.

완성도를 높이면 출시가 늦어진다는 우려에 대해서는 절충이 필요하다고 인정했다. 다만 이해하지 못한 사용자가 떠나거나 작업이 막히는 비용도 고려해야 하며, 코드 작성 속도가 빨라진 만큼 디자인에 시간을 쓰면서도 빠르게 움직일 수 있다고 주장했다.

대담의 마지막 판단 기준은 실제 사용자의 반응이었다. 두 사람은 자신들의 리뷰만으로 성과를 확정할 수 없다고 밝혔다. 제품이 무엇을 하는지 이해되는지, 신뢰할 수 있는지, 원하는 행동으로 이어지는지는 결국 사용자의 경험에서 확인해야 한다는 결론이다.