디자이너가 만든 화면은 멀쩡한데, 개발 큐에 들어가는 순간 맥락이 사라지는 일이 반복된다. 실제 컴포넌트와 데이터 상태, 권한, 예외 케이스를 만나면 "거의 다 됐다"던 시안은 다시 회의실로 돌아온다.
이 틈을 파고든 곳이 Dessn이다. Dessn은 기존 코드베이스를 클라우드에서 실행해 디자이너와 PM이 실제 제품 위에서 프로토타입을 만들게 하는 도구이고, 최근 Connect Ventures 주도로 600만 달러 투자를 유치했다1. 중요한 점은 "AI 디자인 툴이 하나 더 나왔다"가 아니라, 디자인을 제품 밖의 산출물이 아니라 제품 위의 안전한 실험 레이어로 보려는 시도라는 점이다.
문제는 디자인-투-코드가 아니라 '제약 없는 디자인'이다
많은 팀이 핸드오프 문제를 "디자인을 코드로 바꾸는 과정"의 비효율로 이해한다. 하지만 더 근본적인 문제는 디자인이 실제 제품의 제약 바깥에서 만들어진다는 데 있다.
Figma나 유사 툴에서 만든 화면은 빠르고 자유롭다. 대신 실제 서비스의 컴포넌트 구조, API 응답 지연, 빈 상태, 권한별 화면, 레거시 CSS 같은 불편한 현실을 늦게 만난다. 그래서 개발자는 "이건 우리 컴포넌트로 안 됩니다"라고 말하고, 디자이너는 "그럼 왜 처음부터 몰랐죠?"라고 묻게 된다.
Dessn의 접근은 반대다. 새 제품을 처음부터 생성하는 Lovable이나 v0류 도구와 달리, 이미 존재하는 코드베이스를 대상으로 한다. 회사 설명에 따르면 코드베이스를 클라우드에서 실행하고 로컬 개발 환경 설정에 필요한 의존성을 추상화한다1. 공식 사이트는 React 웹앱을 지원하며, 특정 CSS나 컴포넌트 라이브러리에 제한을 두지 않는다고 설명한다2.
해석하자면 Dessn은 "디자인 파일을 더 똑똑하게 만드는 도구"라기보다 "제품 자체를 디자인 가능한 표면으로 바꾸는 도구"에 가깝다. 이 방식이 맞아떨어지면 시안의 충실도가 높아지는 정도가 아니라, 논의의 기준점이 바뀐다. "이렇게 보일 것이다"가 아니라 "우리 제품에서 이렇게 동작한다"를 놓고 이야기하게 된다.
잘 맞는 일과 함부로 쓰면 위험한 일이 다르다
Dessn이 유용해 보이는 영역은 비교적 분명하다. 이미 제품이 있고, UI 반복이 많고, 엔지니어링 병목 때문에 실험 속도가 느린 팀이다.
예를 들면 온보딩 플로우, 대시보드, 관리자 도구, 가격 페이지, 빈 상태 개선, 성장 실험 같은 작업이다. 이런 일은 핵심 아키텍처보다 화면 구성과 사용 흐름의 품질이 중요하고, 실제 컴포넌트를 써볼수록 판단이 빨라진다.
반대로 모든 것을 Dessn에서 하려 하면 위험하다. 결제, 인증, 개인정보 동의, 권한 모델, 복잡한 상태 관리처럼 제품 로직과 보안 리스크가 큰 영역은 "디자이너가 만질 수 있게 됐다"는 이유만으로 가볍게 실험해서는 안 된다.
여기서 중요한 사실 하나가 있다. Dessn은 스스로를 "프로덕션에서 디자인"한다고 표현하지만, 저장소에 코드를 직접 쓰거나 푸시하지 않는 읽기 전용 구조를 강조한다. 각 프로젝트는 격리된 microVM에서 실행되고, 저장소 접근도 범위가 제한된 읽기 권한이라는 설명이 공개돼 있다3. 즉 실제 운영 배포를 자동으로 바꾸는 도구라기보다, 운영 코드에 가까운 환경 위에서 되돌릴 수 있는 프로토타입을 만드는 도구로 보는 편이 정확하다.
이 차이를 이해하지 못하면 두 가지 오해가 생긴다. 하나는 "비개발자가 프로덕션을 마음대로 수정한다"는 과도한 공포이고, 다른 하나는 "이제 개발 검토 없이 바로 배포 가능하다"는 과도한 기대다. 둘 다 틀렸다.
도입 전에는 팀의 '안전장치'를 먼저 점검해야 한다
Dessn 같은 도구를 평가할 때 기능보다 먼저 볼 것은 팀의 준비 상태다. 특히 아래 질문에 답할 수 있어야 한다.
컴포넌트와 디자인 시스템이 실제 제품에서 충분히 재사용 가능한가?
스테이징, 프리뷰, 리뷰 링크 문화가 이미 자리 잡았는가?
디자이너·PM·엔지니어가 변경 범위와 책임 경계를 합의할 수 있는가?
생성된 결과물을 누가, 어떤 기준으로 코드 리뷰할 것인가?
"빠른 실험"과 "제품 품질" 사이의 우선순위가 명확한가?
컴포넌트가 엉켜 있고, 디자인 시스템은 문서에만 있으며, 코드 리뷰가 병목이 아니라 방어전처럼 운영되는 팀이라면 Dessn은 속도를 높이기보다 갈등을 앞당길 수 있다. 반대로 컴포넌트 기반 제품을 운영하고 있고, 작은 UI 실험이 매출이나 전환율에 영향을 주는 팀이라면 효과가 클 수 있다.
TechCrunch 보도에 따르면 Dessn은 무료로 한 개 저장소와 주당 다섯 개 프롬프트를 제공하고, 이후 유료 요금은 사용자당 월 39달러부터 시작하는 구조를 계획하고 있다1. 이 가격보다 중요한 것은 전환 비용이다. Dessn은 Figma를 당장 대체하기보다 특정 프로젝트에서 병행 도입하기 쉬운 포지션을 취하고 있다.
디자이너는 운영자에, 엔지니어는 시스템 관리자에 가까워진다
장기적으로 흥미로운 변화는 역할의 이동이다. Dessn이 성공한다면 디자이너는 더 이상 정적인 화면을 넘기는 사람에 머물지 않는다. 실제 컴포넌트와 상태를 다루며 제품 경험을 운영하는 사람에 가까워진다.
엔지니어의 역할도 사라지지 않는다. 오히려 더 중요해질 수 있다. 좋은 컴포넌트, 안전한 샌드박스, 명확한 권한, 리뷰 가능한 변경 단위, 재사용 가능한 패턴을 만드는 일이 핵심 업무가 된다. 비개발자가 제품에 더 가까워질수록, 엔지니어는 개별 화면 구현자가 아니라 시스템의 가드레일을 설계하는 사람이 된다.
따라서 Dessn을 봐야 할 팀은 "AI가 디자이너를 대체할까?"를 묻는 팀이 아니다. "우리 팀의 디자인은 아직도 제품 밖에서 너무 오래 머무르고 있지 않은가?"를 묻는 팀이다. 이미 운영 중인 웹 제품이 있고, 반복 실험의 속도가 경쟁력인 조직이라면 지금 테스트해볼 만하다. 다만 복잡한 로직과 보안이 핵심인 제품이라면, 도구보다 먼저 안전한 리뷰 체계와 컴포넌트 품질을 점검해야 한다.
참고
1Dessn raises $6M for its production focused design tool
3London's Dessn raises €5 million to help product teams design and prototype inside real codebases
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.