“디자이너와 개발자가 매번 싸우는 이유” Figma 디자인과 실제 코드가 어긋나는 구조적 원인과 해결책

원문 작성자는 Figma와 코드가 각기 다른 패러다임을 가지고 있어 디자인과 구현의 괴리는 운영 노력으로 해결될 문제가 아니라고 봄. 이를 해결하려면 둘 중 하나를 기준으로 삼는 대신, '컴포넌트 명세서(Component Spec)'를 독립적인 원본으로 두고 나머지를 파생물로 취급하는 구조적 접근이 필요하다고 주장함.

이런 구조적 괴리에 공감하는 의견이 있었음. 한 이용자는 Storybook을 활용한 사례를 언급하며 Figma를 절대적인 기준으로 삼는 현 방식에 한계가 명확하다고 지적함. 또한, 디자인 명세서를 별도로 유지하는 것은 좋으나 그 유지 비용이 생각보다 클 것이라는 현실적인 우려도 나옴.

반면, Figma와 구현 코드 사이의 괴리 자체가 문제의 본질이 아니라는 반론도 있었음. 상세 설계가 부재한 상황에서 설계 근거가 모호한 것이 근본 원인이라는 의견임. 또한 애초에 Figma와 구현물을 분리해서 관리할 필요가 있는지 의문을 제기하거나, Figma가 HTML/CSS의 표현력을 충분히 담아내지 못하는 점을 지적하며 스마트폰 앱 개발 등에서는 Figma의 필요성 자체가 줄어들고 있다고 보는 댓글도 있었음.

LLM을 활용한 대안에 대한 논의도 이어짐. 초기 탐색 단계에서는 Figma의 유연함이 필요하지만, 현재의 LLM은 시각 정보보다 텍스트 기반의 사고에 능해 Figma를 거치는 과정이 오히려 노이즈가 될 수 있다는 분석이 나옴. 다만 기획 단계와 실제 구축 단계 사이의 간극을 LLM이 명세화해 주는 방식은 흥미로운 시도라는 평도 있었음.