Get in touch

개인정보보호정책

Frameout은 이용자의 개인정보를 소중히 여기며, 개인정보 보호법 등 관련 법령을 준수합니다. 수집된 개인정보는 서비스 제공 및 상담, 제안서 접수 등 정해진 목적 외에는 사용되지않습니다. 또한, 이용자의 동의 없이는 개인정보를 외부에 제공하지 않습니다.

개인정보 수집 및 이용 동의

Frameout은 입사지원 및 제안 요청/상담을 위해 이름, 연락처, 이메일 주소 등의 정보를 수집합니다. 수집된 정보는 입사지원 및 채용전형 진행, 입사지원정보 검증을 위한 제반 절차 수행과 제안서 작성, 상담 응대 등 업무 처리 목적에 한해 이용됩니다. 해당 정보는 제3자에게 제공하거나 입사 진행 절차 이외에는 사용하지 않습니다. 이용자는 개인정보 제공에 동의하지 않을 수 있으며, 미동의 시 일부 서비스 이용이 제한될 수 있습니다.

개인정보 보유 및 이용기간

수집된 개인정보는 수집 목적 달성 후 즉시 파기되며, 보관이 필요한 경우 관련 법령에 따라 일정 기간 보관됩니다. 기본 보유 기간은 1년이며, 이후에는 지체 없이 안전하게 삭제됩니다. 이용자는 언제든지 개인정보 삭제 요청이 가능합니다.
앞으로의 가능성을 함께 열어갑니다!
참고자료가 있다면 첨부해주세요
파일 업로드 중
fileuploaded.jpg
최대 10Mb까지 업로드 가능합니다.
문의 접수가 완료되었습니다.
Oops! Something went wrong while submitting the form.
디자인-투-코드 AI 도구의 진화
UX 팀과 개발팀의 협업 방식을 재정의하다
2026-03-04

디자인에서 코드까지: AI가 닫는 UX와 개발의 거리

지난 5년간 디자인 도구의 발전 속도는 놀라웠다. Figma의 등장으로 클라우드 기반 협업 디자인이 표준이 되었고, Penpot, Adobe XD 등 다양한 플랫폼들이 경쟁하며 기능을 확대해왔다. 하지만 여전히 남아있는 근본적인 문제가 있다. 바로 '디자인-개발 간의 손실'이다.

전통적으로 UX 디자이너가 만든 Figma 디자인 파일은 개발자에게 전달되고, 개발자는 이를 HTML, CSS, JavaScript로 직접 구현해야 한다. 이 과정에서 불가피하게 발생하는 것들이 있다. 디자인의 미세한 쉐도우 값이 누락되거나, 반응형 디자인의 세부 조정이 원본과 달라지거나, 인터랙션 세부사항이 개발자의 해석에 따라 다르게 구현되는 것이다. 이러한 '번역 오류'들이 반복되면서 전체 프로젝트 일정에 큰 영향을 미친다.

디자인-투-코드 AI 도구들은 이 문제를 근본에서 해결하려고 한다. Kombai, Locofy, Anima, Builder.io, Teleporthq 같은 도구들이 주목받는 이유는 단순히 '코드를 자동 생성한다'는 것 때문이 아니다. 이들이 UX 팀과 개발팀 간의 워크플로우 자체를 재구성하고 있기 때문이다.

디자인-투-코드 도구의 진화: 세대별 접근

현재 시장에 있는 디자인-투-코드 솔루션들을 크게 세 가지 세대로 나눌 수 있다.

1세대: 'CSS 자동 생성' 도구

처음 등장한 도구들은 스타일 속성만 추출하는 수준이었다. 예를 들어, Avocode(2013)나 초기 Zeplin은 디자인 파일을 분석해서 색상, 폰트, 마진, 패딩 값을 CSS로 변환했다. 개발자 입장에서는 '디자인 시안표'를 받는 것처럼 사용했다. 이 방식은 여전히 많은 레거시 팀에서 사용 중이지만, 구조적 HTML 마크업은 여전히 개발자가 손으로 작성해야 했다.

2세대: '구조 이해' 도구 (2020-2023)

Figma 플러그인 생태계가 발전하면서 진정한 의미의 코드 생성이 가능해졌다. Anima (2018), TLDR (2019) 같은 도구들은 디자인의 레이아웃 구조를 인식하기 시작했다. 예를 들어, Anima는 Figma의 컴포넌트 구조를 읽고, 자동 레이아웃 설정을 기반으로 React 컴포넌트로 변환할 수 있었다. 하지만 이 세대 도구들도 한계가 있었다. 복잡한 상호작용, 동적 상태 관리, API 연동 로직은 여전히 개발자가 수동으로 구현해야 했고, 생성된 코드의 품질이 일정하지 않았다.

3세대: 'AI 기반 의미 이해' 도구 (2023-현재)

생성형 AI의 발전과 함께 새로운 세대의 도구들이 등장했다. 이들의 특징은 '시각적 맥락만 이해하는 것이 아니라, 개발 패턴을 학습한다'는 것이다.

디자인-투-코드 도구들의 생성 품질 및 기능 비교

Kombai는 2023년 한국에서 만들어진 도구로, Figma 플러그인 형태로 작동한다. Kombai의 가장 큰 특징은 '컴포넌트 기반 아키텍처를 깊이 있게 이해한다'는 것이다. Kombai를 사용하는 한 스타트업의 경우, Figma의 컴포넌트 라이브러리를 구성한 후 플러그인을 실행하면, 자동으로 React 컴포넌트 구조와 TypeScript 타입 정의까지 생성된다고 보고했다. 특히 인상적인 점은 Figma의 '변수(Variables)' 기능과 통합되어, 다크모드나 테마 변경을 자동으로 코드에 반영한다는 것이다.

Locofy는 더 공격적인 접근을 한다. Figma뿐 아니라 Sketch, Adobe XD 파일도 지원하며, 생성된 코드를 Nextjs, React, Vue, Svelte 등 여러 프레임워크로 출력할 수 있다. Locofy의 특별한 기능은 '반응형 설계 자동 생성'이다. 모바일, 태블릿, 데스크톱 버전을 각각 디자인하지 않아도, 하나의 디자인 파일로부터 자동으로 breakpoint별 코드를 생성한다. 한 미디어 회사가 Locofy를 도입한 후 반응형 구현 시간을 70% 단축했다고 보고했다.

Builder.io는 다른 관점에서 접근한다. 이들은 시각적 빌더(Visual Builder)로 시작했고, 최근 AI Code Gen 기능을 추가했다. Builder.io의 강점은 '완성된 웹사이트를 생성한다'는 것이다. 단순 컴포넌트가 아니라, 실제 배포 가능한 웹페이지를 AI가 디자인 이미지로부터 생성할 수 있다. 여러 SaaS 회사들이 랜딩페이지 제작에 Builder.io를 활용해, 개발자 없이도 2-3일 만에 프로덕션 준비가 된 페이지를 만들고 있다.

Teleporthq는 'No-Code 플랫폼' 성격을 유지하면서, 최근 AI 기능을 강화했다. 디자인 이미지나 스크린샷으로부터 완전한 HTML/CSS/JS 코드를 생성하고, 생성된 코드는 GitHub에 직접 커밋할 수 있다. 이는 전통적인 노코드 도구와 프로 개발자 워크플로우 사이의 경계를 허물고 있다.

중요한 변화: 워크플로우 재편

이 도구들의 등장이 가져오는 가장 중요한 변화는 '어떤 사람이 코드를 작성하는가'라는 질문을 던지는 것이다.

디자인-개발 협업 모델의 변화

과거 모델: 디자이너 → 설계 문서 → 개발자 → 코드
현재 모델(AI 도구 도입 후): 디자이너 ↔ AI 도구 ↔ 개발자 ↔ 검토/최적화
미래 모델(완전 성숙): 디자이너 → AI 도구 → 자동 배포 (개발자는 복잡한 로직에만 집중)

선진 팀들에서 관찰되는 변화는 흥미롭다. Notion, Figma 같은 설계 중심의 대규모 기업들도 내부적으로 디자인-투-코드 도구를 활용하고 있다. Figma 공식 블로그에서 공개한 사례에 따르면, 자신들의 Config 웹사이트(연례 컨퍼런스 페이지)를 Figma 디자인에서 React 코드로 자동 생성했고, 전체 구현 시간을 60% 단축했다고 밝혔다.

개발자 역할의 변화

여기서 중요한 질문이 생긴다: 그러면 개발자는 뭘 하는가?

실제로 도구를 도입한 팀들의 피드백은 우리의 직관과 다르다. 개발자들이 실직되는 것이 아니라, 오히려 '더 창의적인 일'을 하게 된다는 것이다.

예를 들어, 한국의 한 핀테크 스타트업(약 50명 규모)은 Figma → Locofy 워크플로우를 도입한 후 다음과 같은 변화를 보고했다:

  1. 화면 개발 시간 70% 단축: 반응형 UI 구현이 자동화되면서, 개발자들이 보내던 반복적인 스타일링 시간이 크게 줄었다.
  2. API 통합에 집중: 시간이 절약되면서, 개발자들은 백엔드 로직, 데이터 관리, API 설계에 더 깊이 있게 몰입할 수 있었다.
  3. 성능 최적화에 자원 배분: 자동 생성된 코드의 성능을 개선하는 작업이 새로운 과제가 되었다. AI가 만든 코드는 종종 함수형 패턴이나 불필요한 리렌더링을 야기하기도 한다.
  4. 디자인과의 협업 심화: 개발자가 '설계 문서 따라하기'에서 벗어나면서, 디자인 검증, 상호작용 개선 제안 등 더 창의적인 협업이 가능해졌다.
디자인-투-코드 도구 도입 전후 팀의 업무 시간 재배분 예시




컴포넌트 기반 설계의 중요성 증가

흥미로운 현상은 디자인-투-코드 도구가 좋을수록, 디자인 규율이 더 엄격해져야 한다는 것이다. Kombai나 Locofy 같은 도구들이 좋은 코드를 생성하려면, Figma의 컴포넌트 구조, 자동 레이아웃, 제약 조건이 제대로 설정되어야 한다. 이는 다음을 의미한다:

  1. Design System 필수화: 과거에는 '좋은 디자인 시스템'이 업계 베스트 프랙티스였다면, 지금은 AI 도구를 쓰려면 '필수'가 되었다.
  2. 디자인 문서화 강화: Figma 자체가 살아있는 문서가 되어야 한다. 주석, 가이드라인, 변수 정의가 명확해야 AI가 제대로 해석할 수 있다.
  3. 디자이너의 기술 리터러시 향상: 과거에는 디자이너가 마진/패딩 값 정도만 알면 됐다면, 이제는 flex layout, grid, 반응형 단위, 타입스크립트 타입 개념까지 이해하는 것이 유리해진다.

생성된 코드의 품질 문제

모든 것이 장점만은 아니다. 현실의 도전 과제들이 있다:

코드 품질의 불균일성: 3개월 전 생성된 코드와 지금 생성된 코드의 패턴이 다를 수 있다. AI 모델이 자주 업데이트되기 때문이다. 한 개발팀이 보고한 바에 따르면, Locofy 업데이트 후 생성 코드의 상태 관리 패턴이 Class Component 기반에서 Hooks 기반으로 변경되었고, 기존 프로젝트와의 일관성을 맞추는 데 며칠이 걸렸다고 했다.

엣지 케이스 처리 미흡: AI는 일반적인 패턴은 잘 생성하지만, 복잡한 상호작용이나 조건부 렌더링이 필요한 경우는 여전히 약하다. 예를 들어, '사용자가 버튼을 3번 클릭했을 때만 특정 모달을 표시' 같은 세부 로직은 AI가 생성하기 어렵다.

유지보수 난제: 자동 생성된 코드를 나중에 수정해야 할 때, 디자인을 다시 수정하고 코드를 재생성해야 할까? 아니면 생성된 코드를 직접 손으로 수정해야 할까? 이 질문에 대한 표준화된 답이 아직 없다.

실제 도입 사례 분석

사례 1: 글로벌 핀테크 회사의 도입

한 글로벌 핀테크 회사(약 200명 규모)는 2024년 초 모든 신규 프로젝트에 Locofy를 의무화했다. 6개월 후 그들의 보고:

  1. 총 개발 시간 43% 감소
  2. UI 버그 발생률 55% 감소 (디자인 해석 오류 제거)
  3. 디자이너-개발자 간 커뮤니케이션 시간 31% 증가 (음의 지표처럼 보이지만, 이는 '세부사항 논쟁'이 아닌 '전략적 논의'로 변화했다는 뜻)
  4. 신규 입사자의 온보딩 시간 38% 단축

하지만 도전 과제도 있었다. 처음 3개월간 디자인 품질이 하락했다. 이유는 디자이너들이 '자동 생성될 코드'를 먼저 생각하면서 창의성을 제약하기 시작했기 때문이다. 이를 해결하기 위해 이 회사는 다음과 같은 정책을 도입했다:

  1. 월 1회 '자유 디자인 세션': 자동화를 무시하고 자유롭게 디자인하는 시간
  2. 디자이너-개발자 '페어 디자인' 세션: 기술 제약을 명확히 한 후 창의적 솔루션을 함께 찾는 시간
  3. 코드 생성 후 리뷰 프로세스 정립: 항상 AI 생성 코드를 한 번 개발자가 검토하는 단계

사례 2: 한국 스타트업의 빠른 성장

한국의 한 B2B SaaS 회사(약 15명)는 초기부터 Kombai를 도입했다. 이들의 경우, 개발자 3명과 디자이너 1명 구성에서 시작했는데, Kombai로 자동화된 UI 코딩 덕분에 개발자들이 '백엔드와 인프라'에만 집중할 수 있었다고 한다. 결과적으로:

  1. 개발 속도가 경쟁사 대비 3배 이상 (개발자 수는 비슷함)
  2. 기술 부채가 적음 (일관된 아키텍처로 생성되기 때문)
  3. 스케일링이 용이 (새로운 기능 추가 시 디자인-코드 생성이 표준 프로세스)

흥미로운 점은, 이 회사의 개발자들이 '코딩을 덜 하게 되는 것'을 우려하지 않았다는 것이다. 오히려 '반복적 작업에서 해방되어 실제 문제 해결에 집중할 수 있다'고 표현했다.

실무 관점: 언제 도입할 것인가?

도입에 적합한 팀

  • 스타트업: 속도가 생명. UI 코딩 자동화로 시장 진입 시간을 줄이는 것이 핵심.
  • 대규모 조직의 내부 도구 팀: 수백 개의 유사한 UI가 필요한 경우, AI 도구로 일관성을 유지하면서 빠르게 확장.
  • 디자인 시스템이 잘 구축된 팀: 컴포넌트 기반 설계가 이미 있으면 도입 장벽이 낮음.

도입이 어려운 팀

  • 매우 복잡한 상호작용이 많은 경우: 금융 대시보드, 게임, 실시간 협업 도구 등. AI가 생성한 코드 + 수동 코딩의 혼합이 오히려 복잡할 수 있음.
  • 레거시 기술 스택: jQuery, AngularJS 같은 구형 프레임워크를 사용 중이면, 최신 도구들과 호환성 문제 발생.
  • design-to-code 자동화의 '잘못된 기대'가 있는 경우: '개발자 전혀 필요 없음'이라고 생각한다면 실망할 것.

에디터 노트: 이 변화가 의미하는 것

디자인-투-코드 AI 도구의 등장은 UX와 개발의 관계를 근본적으로 재정의하고 있다. 과거 UX의 역할이 '아름다운 화면을 만드는 것'이었다면, 미래의 UX는 '개발 가능한 시스템을 설계하는 것'으로 진화하고 있다.

이는 다음을 의미한다:

  1. UX 리서치의 중요성 증대: 화면 디자인 자동화가 가능해지면서, 오히려 '왜 이 기능이 필요한가', '사용자가 정말 원하는 것이 무엇인가'라는 본질적 질문이 더 중요해진다.
  2. 정보 구조의 전략적 가치 상승: 와이어프레임과 정보 아키텍처의 중요성이 높아진다. 이는 자동화하기 어려운, 진정한 전략적 역량이다.
  3. 접근성과 포용성 설계의 필수화: AI는 인기 있는 패턴을 따라 생성하므로, 특수한 사용자 요구사항을 먼저 설계에 내장해야 한다.
  4. 데이터 기반 설계의 가능성: 자동화 덕분에 A/B 테스트 기반의 빠른 반복이 가능해진다. 한 번에 '완벽한 디자인'을 추구하기보다, 검증과 개선의 사이클을 빠르게 돌릴 수 있게 된다.

결론적으로, 디자인-투-코드 AI 도구는 '개발자를 없애는 도구'가 아니라, '팀의 창의적 역량을 더 높은 수준으로 끌어올리는 도구'이다. UI 코딩이 자동화되면서, 오히려 UX 전략, 사용자 조사, 기술 아키텍처 같은 고차원적 사고가 더욱 중요해진다는 역설이 우리 업계의 다음 장을 만들어갈 것이다.

 

Where AI Drives UX, FRAMEOUT

참고자료

  1. Figma Official Blog - AI Code Generation in Design
  2. Locofy - Design to Code Workflow Guide
  3. Kombai - Case Studies
  4. Builder.io - AI Code Generation Overview
  5. Teleporthq - Design to Code Solutions
  6. Nielsen Norman Group - Component-Based Design
  7. UXPA - Design Systems and Automation
  8. Smashing Magazine - Design to Code Automation