우리는 또다시 드림위버(Dreamweaver)의 실수를 반복하고 있습니다

AI가 디자인에 다시 코드의 주도권을 부여하고 있습니다.

지난 20년 동안 우리는 이 역할들을 분리하기 위해 노력해 왔습니다. 디자이너는 디자인을 하고, 개발자는 구축을 했습니다. 그 사이에서 사람이 가교 역할을 수행했습니다.

AI는 이를 변화시키고 있습니다. 디자인 파일에 모델을 적용하기만 하면 컴포넌트가 생성됩니다. 디자인이 다시 코드를 주도하게 된 것입니다.

효율적으로 들릴 수 있지만, 여기에는 위험이 따릅니다.

과거 드림위버 시절에는 사람이 중간에 있었습니다. 그 사람이 품질을 관리했습니다. 하지만 AI를 사용하면, 운전대를 잡은 사람 없이 디자인이 곧바로 코드로 직행합니다.

다음 두 가지를 반드시 이해해야 합니다:

• 디자인 파일은 디자인 시스템이 아닙니다. 파일은 어떻게 보이는가로 판단되지만, 시스템은 재사용성, 내구성, 그리고 상태(states)로 판단됩니다. AI는 이 경계를 모호하게 만듭니다.
• AI는 정적 사이트에는 훌륭합니다. 단순히 스냅샷이 필요한 것이라면 AI를 사용하십시오. 문제는 커스텀 CMS나 동적 UI와 같이 재사용 가능한 시스템을 구축할 때 시작됩니다.

진짜 실패는 디테일에서 발생합니다.

팀들은 종종 Figma 변수 이름을 기반으로 코드 파이프라인을 구축합니다. 네이밍은 디자인적 선택이지만, AI는 이를 경직된 계약(contract)으로 만들어 버립니다. 디자이너가 변수 하나만 이름을 바꿔도 전체 파이프라인이 깨져버립니다.

디자인은 정적인 스냅샷입니다. 하나의 상태에 있는 하나의 화면만을 보여줄 뿐입니다. 다음과 같은 것들은 보여주지 못합니다:

• 로딩 또는 에러 상태.
• 콘텐츠 중심 레이아웃 vs 고정 레이아웃.
• CMS가 데이터를 공급하는 방식.

그러한 맥락은 디자인 파일이 아니라 개발자의 머릿속에 존재합니다.

업계 리더들은 이를 해결하기 위해 노력하고 있습니다. Google은 AI에 더 많은 구조를 제공하기 위해 DESIGN.md를 출시했습니다. Fixel과 같은 도구는 코드를 Figma와 대조하여 검증함으로써 디자인 드리프트(design drift)를 잡아내는 데 도움을 줍니다.

하지만 최고의 도구라 할지라도 한계는 있습니다. 픽셀이나 토큰을 추출할 수는 있지만, 아키텍처 결정을 내릴 수는 없습니다. 기존 컴포넌트를 재사용할지, 아니면 새로운 것을 만들지 결정할 수 없습니다.

미래는 디자인이 코드를 주도하는 것이 아닙니다. 중간 지점을 찾는 것입니다.

저는 이 중간 지점에 다음과 같은 것들이 필요하다고 믿습니다:

• 빌드 타임의 타입 지정된(Typed) CSS 입력.
• 디자인이 기존 시스템에 어떻게 매핑되는지 제안하는 AI.
• 동작과 의미에 대해 최종 결정을 내리는 UX 엔지니어.

AI는 디자이너에게 코드 품질에 대한 더 큰 책임을 지웁니다. 디자인이 곧 코드가 되기 때문에, 변환 과정을 검증(gatekeep)할 사람이 남지 않게 됩니다.

우리는 UX 엔지니어를 프로세스에서 제외해서는 안 됩니다. 디자인과 시스템 사이의 매핑과 계약을 책임질 사람이 필요합니다.

AI가 제안하는 것과 여러분이 직접 결정해야 할 것을 어떻게 구분하시겠습니까?

Source: https://dev.to/slafleche/were-making-the-dreamweaver-mistake-again-on-purpose-this-time-ema