Frameout은 이용자의 개인정보를 소중히 여기며, 개인정보 보호법 등 관련 법령을 준수합니다. 수집된 개인정보는 서비스 제공 및 상담, 제안서 접수 등 정해진 목적 외에는 사용되지않습니다. 또한, 이용자의 동의 없이는 개인정보를 외부에 제공하지 않습니다.
Frameout은 입사지원 및 제안 요청/상담을 위해 이름, 연락처, 이메일 주소 등의 정보를 수집합니다. 수집된 정보는 입사지원 및 채용전형 진행, 입사지원정보 검증을 위한 제반 절차 수행과 제안서 작성, 상담 응대 등 업무 처리 목적에 한해 이용됩니다. 해당 정보는 제3자에게 제공하거나 입사 진행 절차 이외에는 사용하지 않습니다. 이용자는 개인정보 제공에 동의하지 않을 수 있으며, 미동의 시 일부 서비스 이용이 제한될 수 있습니다.
수집된 개인정보는 수집 목적 달성 후 즉시 파기되며, 보관이 필요한 경우 관련 법령에 따라 일정 기간 보관됩니다. 기본 보유 기간은 1년이며, 이후에는 지체 없이 안전하게 삭제됩니다. 이용자는 언제든지 개인정보 삭제 요청이 가능합니다.
지난 5년간 디자인 도구의 발전 속도는 놀라웠다. Figma의 등장으로 클라우드 기반 협업 디자인이 표준이 되었고, Penpot, Adobe XD 등 다양한 플랫폼들이 경쟁하며 기능을 확대해왔다. 하지만 여전히 남아있는 근본적인 문제가 있다. 바로 '디자인-개발 간의 손실'이다.
전통적으로 UX 디자이너가 만든 Figma 디자인 파일은 개발자에게 전달되고, 개발자는 이를 HTML, CSS, JavaScript로 직접 구현해야 한다. 이 과정에서 불가피하게 발생하는 것들이 있다. 디자인의 미세한 쉐도우 값이 누락되거나, 반응형 디자인의 세부 조정이 원본과 달라지거나, 인터랙션 세부사항이 개발자의 해석에 따라 다르게 구현되는 것이다. 이러한 '번역 오류'들이 반복되면서 전체 프로젝트 일정에 큰 영향을 미친다.
디자인-투-코드 AI 도구들은 이 문제를 근본에서 해결하려고 한다. Kombai, Locofy, Anima, Builder.io, Teleporthq 같은 도구들이 주목받는 이유는 단순히 '코드를 자동 생성한다'는 것 때문이 아니다. 이들이 UX 팀과 개발팀 간의 워크플로우 자체를 재구성하고 있기 때문이다.
현재 시장에 있는 디자인-투-코드 솔루션들을 크게 세 가지 세대로 나눌 수 있다.
처음 등장한 도구들은 스타일 속성만 추출하는 수준이었다. 예를 들어, Avocode(2013)나 초기 Zeplin은 디자인 파일을 분석해서 색상, 폰트, 마진, 패딩 값을 CSS로 변환했다. 개발자 입장에서는 '디자인 시안표'를 받는 것처럼 사용했다. 이 방식은 여전히 많은 레거시 팀에서 사용 중이지만, 구조적 HTML 마크업은 여전히 개발자가 손으로 작성해야 했다.
Figma 플러그인 생태계가 발전하면서 진정한 의미의 코드 생성이 가능해졌다. Anima (2018), TLDR (2019) 같은 도구들은 디자인의 레이아웃 구조를 인식하기 시작했다. 예를 들어, Anima는 Figma의 컴포넌트 구조를 읽고, 자동 레이아웃 설정을 기반으로 React 컴포넌트로 변환할 수 있었다. 하지만 이 세대 도구들도 한계가 있었다. 복잡한 상호작용, 동적 상태 관리, API 연동 로직은 여전히 개발자가 수동으로 구현해야 했고, 생성된 코드의 품질이 일정하지 않았다.
생성형 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 워크플로우를 도입한 후 다음과 같은 변화를 보고했다:

흥미로운 현상은 디자인-투-코드 도구가 좋을수록, 디자인 규율이 더 엄격해져야 한다는 것이다. Kombai나 Locofy 같은 도구들이 좋은 코드를 생성하려면, Figma의 컴포넌트 구조, 자동 레이아웃, 제약 조건이 제대로 설정되어야 한다. 이는 다음을 의미한다:
모든 것이 장점만은 아니다. 현실의 도전 과제들이 있다:
코드 품질의 불균일성: 3개월 전 생성된 코드와 지금 생성된 코드의 패턴이 다를 수 있다. AI 모델이 자주 업데이트되기 때문이다. 한 개발팀이 보고한 바에 따르면, Locofy 업데이트 후 생성 코드의 상태 관리 패턴이 Class Component 기반에서 Hooks 기반으로 변경되었고, 기존 프로젝트와의 일관성을 맞추는 데 며칠이 걸렸다고 했다.
엣지 케이스 처리 미흡: AI는 일반적인 패턴은 잘 생성하지만, 복잡한 상호작용이나 조건부 렌더링이 필요한 경우는 여전히 약하다. 예를 들어, '사용자가 버튼을 3번 클릭했을 때만 특정 모달을 표시' 같은 세부 로직은 AI가 생성하기 어렵다.
유지보수 난제: 자동 생성된 코드를 나중에 수정해야 할 때, 디자인을 다시 수정하고 코드를 재생성해야 할까? 아니면 생성된 코드를 직접 손으로 수정해야 할까? 이 질문에 대한 표준화된 답이 아직 없다.
한 글로벌 핀테크 회사(약 200명 규모)는 2024년 초 모든 신규 프로젝트에 Locofy를 의무화했다. 6개월 후 그들의 보고:
하지만 도전 과제도 있었다. 처음 3개월간 디자인 품질이 하락했다. 이유는 디자이너들이 '자동 생성될 코드'를 먼저 생각하면서 창의성을 제약하기 시작했기 때문이다. 이를 해결하기 위해 이 회사는 다음과 같은 정책을 도입했다:
한국의 한 B2B SaaS 회사(약 15명)는 초기부터 Kombai를 도입했다. 이들의 경우, 개발자 3명과 디자이너 1명 구성에서 시작했는데, Kombai로 자동화된 UI 코딩 덕분에 개발자들이 '백엔드와 인프라'에만 집중할 수 있었다고 한다. 결과적으로:
흥미로운 점은, 이 회사의 개발자들이 '코딩을 덜 하게 되는 것'을 우려하지 않았다는 것이다. 오히려 '반복적 작업에서 해방되어 실제 문제 해결에 집중할 수 있다'고 표현했다.
디자인-투-코드 AI 도구의 등장은 UX와 개발의 관계를 근본적으로 재정의하고 있다. 과거 UX의 역할이 '아름다운 화면을 만드는 것'이었다면, 미래의 UX는 '개발 가능한 시스템을 설계하는 것'으로 진화하고 있다.
이는 다음을 의미한다:
결론적으로, 디자인-투-코드 AI 도구는 '개발자를 없애는 도구'가 아니라, '팀의 창의적 역량을 더 높은 수준으로 끌어올리는 도구'이다. UI 코딩이 자동화되면서, 오히려 UX 전략, 사용자 조사, 기술 아키텍처 같은 고차원적 사고가 더욱 중요해진다는 역설이 우리 업계의 다음 장을 만들어갈 것이다.
Where AI Drives UX, FRAMEOUT