지난 한 해 동안 이상한 일이 벌어졌습니다.
AI가 소프트웨어를 만드는 데 엄청나게 뛰어나졌습니다.
그런데 왠지 제품들은 점점 더 평범해지는 느낌이 들기 시작했습니다.
앞뒤가 안 맞는 이야기처럼 들리죠.
모델은 더 똑똑해졌고, 에이전트는 더 좋아졌습니다. 컨텍스트 윈도우는 폭발적으로 늘어났고, 개발자들은 엄청나게 생산적이 되었습니다.
하지만 최근 Product Hunt, 인디 해커 런칭, AI 스타트업 데모를 조금이라도 살펴봤다면, 아마 같은 패턴을 발견했을 겁니다.
다른 창업자들.
다른 제품들.
다른 산업.
하지만 인터페이스는 모두 이상하게 낯익어지기 시작합니다.
똑같은 카드들.
똑같은 대시보드들.
똑같은 레이아웃들.
똑같은 시각적 위계.
똑같은 "AI가 생성한 SaaS" 미학.
코드는 잘 작동합니다.
프론트엔드는 기억에 남지 않습니다.
그리고 저는 그 이유가 대부분의 개발자가 더 이상 존재하지 않는 문제에 집중하고 있기 때문이라고 생각합니다.
바로 코드 생성입니다.
오늘날 코드 생성은 쉽습니다.
의도성이 느껴지는 프론트엔드를 생성하는 것이 훨씬 더 어렵습니다.
현대적인 AI 워크플로우는 대부분 이미 이렇게 생겼습니다.
Claude Code로 계획을 세우고.
Cursor로 구현합니다.
출시합니다.
반복합니다.
그리고 솔직히 말해서, 그 자체로도 이전보다 훨씬 빠르게 제품을 만들기에 충분히 강력합니다.
Claude Code는 아키텍처를 추론하고, 시스템을 분석하며, 무엇을 구축해야 할지 파악하는 데 제가 가장 선호하는 도구가 되었습니다.
Cursor는 그러한 아이디어를 실제 작동하는 소프트웨어로 전환하는 최고의 환경 중 하나로 남아 있습니다.
어느 도구도 문제가 아닙니다.
사실, 소프트웨어 제작이 이렇게 엄청나게 빨라진 이유가 바로 그 도구들입니다.
문제는 코드가 생성된 후에 시작됩니다.
바로 그 지점에서 프론트엔드 품질은 완전히 다른 도전 과제가 됩니다.
더 많은 제품을 살펴볼수록, 작동하는 제품과 훌륭한 제품 사이의 격차는 더 이상 기능에 있는 경우가 드물다는 것을 깨달았습니다.
그것은 세부 조정입니다.
일관성입니다.
디자인 결정입니다.
컨텍스트입니다.
그리고 이것이 바로 제가 프론트엔드 네이티브 워크플로우에 관심을 가지게 된 이유입니다.
이 워크플로우를 처음 시각화된 모습으로 보았을 때, 그것은 제가 현대 AI 개발에 대해 생각하기 시작한 방식을 완벽하게 포착했습니다.
Claude는 제가 생각하는 것을 돕습니다.
Cursor는 제가 구축하는 것을 돕습니다.
하지만 "작동하는 소프트웨어"와 "프로덕션 준비가 된 제품" 사이에는 여전히 빠진 계층이 있습니다.
그것이 바로 Kombai가 해결하려고 하는 계층입니다.
어느 한 도구를 대체하는 것이 아닙니다.
두 도구 모두 해결하도록 설계되지 않은 격차를 메우는 것입니다.
이를 설명하는 가장 쉬운 방법은 간단한 질문 하나입니다.
왜 AI가 생성한 프론트엔드는 여전히 AI가 만든 것처럼 느껴질까요?
전부는 아닙니다.
하지만 대부분 몇 초 안에 알아볼 수 있을 정도입니다.
코드가 나쁘기 때문인 경우는 드뭅니다.
문제는 대개 훨씬 더 깊은 곳에 있습니다.
대부분의 AI 도구는 프롬프트를 이해합니다.
프론트엔드 엔지니어는 시스템을 이해합니다.
그 차이는 작아 보입니다.
하지만 그렇지 않습니다.
시니어 프론트엔드 엔지니어는 버튼을 보고 이렇게 생각하지 않습니다.
"저건 버튼이야."
그들은 이렇게 생각합니다.
이건 어떤 컴포넌트지?
어떤 디자인 토큰이 여기에 적용되지?
이미 다른 곳에 존재하지 않나?
타이포그래피 스케일을 따르고 있나?
디자인 시스템 안에 속하나?
이 패턴이 재사용 가능한가?
이러한 질문들이 일관성을 만들어냅니다.
그리고 일관성이 품질을 만들어냅니다.
최고의 프론트엔드는 컴포넌트의 집합이 아닙니다.
그것은 결정의 집합입니다.
그리고 그 결정들은 시간이 지남에 따라 누적됩니다.
이것이 오늘날 대부분의 AI 워크플로우가 무너지는 지점이라고 생각합니다.
생성된 버전은 종종 작동합니다.
프로덕션 준비 버전은 의도적이라는 느낌을 줍니다.
생성된 버전은 조건을 충족시킵니다.
프로덕션 준비 버전은 신뢰를 쌓습니다.
그리고 이 두 결과의 차이는 보통 더 많은 코드가 아닙니다.
더 많은 컨텍스트입니다.
- 디자인 모드: 구현부터 시작하지 않고, 인터페이스부터 시작하기
제가 AI 도구로 구축한 모든 프론트엔드 프로젝트는 같은 방식으로 시작했습니다. 프롬프트 → 코드 → 새로고침 → 반복.
Kombai의 디자인 모드는 이를 완전히 뒤집습니다.
구현부터 시작하는 대신, 인터페이스 자체부터 시작합니다. 무한 캔버스에서 작업하며 레이아웃을 스케치하고, 컴포넌트를 반복적으로 개선하고, 시각적 결정을 조정합니다. 여기에는 진정한 창의적 취향이 내장된 AI가 함께합니다.
결과물은 기본 Tailwind 스타터처럼 보이지 않습니다. shadcn 템플릿처럼 보이지도 않습니다. 디자인된 무언가처럼 보입니다.
이것이 중요한 이유: 디자인이 코드베이스와 분리되어 있지 않습니다. 디자인은 여러분의 리포지토리 안에 존재합니다.
그리고 이것이 진정으로 저를 놀라게 한 다음 것으로 이어집니다.
- 모든 것을 바꾸는 4방향 동기화
대부분의 AI 워크플로우는 디자인과 코드 사이에 단단한 벽이 있습니다.
어딘가에서 디자인하고(Figma, v0 등), 다른 곳에서 구현합니다(Cursor, Claude Code). 그리고 그 두 번째 계층 안에서 영원히 살면서 파일을 편집하고 브라우저를 새로고침하며 변경 사항을 적용합니다.
Kombai는 그 벽을 무너뜨립니다. 네 방향 모두에서 말이죠.
디자인, 코드, 렌더링된 UI가 모두 여러분의 리포지토리와 IDE 안에 함께 존재합니다. 그중 무엇이든 편집할 수 있습니다. 나머지는 클릭 한 번으로 업데이트됩니다.
실제로 이것이 의미하는 바는 다음과 같습니다.
캔버스의 디자인 → 리포지토리의 코드
캔버스와 디자인은 코드로 생성되어 리포지토리 안에 위치합니다. 따라서 @를 사용하여 프롬프트에서 직접 참조하고, 해당 컨텍스트를 어떤 작업에든 가져와서 바로 프로덕션 등급 코드를 생성할 수 있습니다. 디자인의 요소로 새 컴포넌트를 만들고 싶으신가요? 에이전트를 그쪽으로 안내하세요. 새 디자인에 맞게 토큰을 업데이트하고 싶으신가요? 프롬프트 하나면 됩니다.
리포지토리의 코드 → 캔버스의 디자인
Kombai의 디자인 모드는 항상 리포지토리의 전체 컨텍스트를 가지고 있습니다. 따라서 반대 방향으로도 작업할 수 있습니다. 기존 코드를 사용하여 새 디자인을 생성할 수 있습니다. 제품 캐러셀의 변형을 만들고 싶으신가요? 해당 컴포넌트를 캔버스에 복사하여 창의적인 버전을 생성하도록 요청하세요. 코드베이스에 이미 존재하는 모달의 최대화된 상태를 디자인하고 싶으신가요? 모달이 어떻게 생겼는지 이미 알고 있습니다.
브라우저에서 렌더링된 UI 편집 → 리포지토리의 코드
실행 중인 앱의 어떤 부분이든 Kombai 브라우저에서 엽니다. 텍스트, 스타일, 레이아웃을 디자인 도구에서 하듯 시각적으로 편집합니다. 그런 다음 클릭 한 번으로 해당 편집 내용을 에이전트에 보내면 실제 코드에 구현됩니다.
더 이상 브라우저, 검사기, 코드 편집기 사이를 전환할 필요가 없습니다. 보고, 수정하고, 끝입니다.
브라우저의 렌더링된 UI → 캔버스의 디자인
웹 캡처 기능을 사용하여 라이브 UI의 어떤 부분이든 디자인 캔버스로 직접 보냅니다. localhost에서 실행되는 페이지와 리포지토리 외부의 URL에서도 작동합니다. 그곳에서 반복적으로 개선하고, 변형을 생성하거나, 프롬프트에서 참조하여 영감으로 사용할 수 있습니다.
이것은 데모용 트릭이 아닙니다. 프론트엔드 작업에 대한 근본적으로 다른 사고 방식입니다.
"코드 → 새로고침 → 검사 → 반복" 대신, 동일한 진실의 세 가지 뷰를 넘나들며 작업하게 되며, 그중 어떤 것으로든 진입하고 빠져나올 수 있습니다.
피드백 루프는 극적으로 짧아집니다. 그리고 매일 수십 가지의 프론트엔드 결정을 내릴 때, 그 차이는 빠르게 누적됩니다.
- 기존 시스템을 실제로 재사용하는 프로덕션 등급 코드
Kombai 내부의 가장 흥미로운 아이디어 중 하나는 간단해 보이지만 깊이 있는 것입니다.
무엇이든 생성하기 전에 여러분의 스택을 이해합니다.
대부분의 AI 생성 프론트엔드가 잘못 이해하는 부분이 바로 여기입니다.
기존 컴포넌트가 이미 존재하는데도 새 컴포넌트를 생성합니다. 디자인 시스템에 이미 있는데도 새 토큰을 만듭니다. 천천히, 눈에 띄지 않게 불일치를 추가하여 코드베이스가 마치 다섯 개의 다른 팀이 만든 것처럼 느껴지게 만듭니다.
Kombai는 먼저 기존 컴포넌트, 훅, 토큰을 살펴봅니다. 그런 다음 이미 있는 것을 재사용합니다.
시니어 프론트엔드 엔지니어는 단순히 새 코드를 작성하지 않습니다. 그들은 묻습니다: 이게 이미 존재하나? 뭔가를 재사용해야 하지 않나? 우리가 확립한 패턴을 따르고 있나?
Kombai가 인코딩하려고 하는 생각이 바로 그것입니다.
그 시각 자료는 아마 어떤 마케팅 페이지보다도 더 잘 설명할 것입니다.
대부분의 AI 도구는 지침을 봅니다.
Kombai는 그 지침이 존재하는 환경을 이해하려고 합니다.
그리고 그 차이는 프로젝트가 커질수록 더욱 가치 있게 됩니다.
이제 아무도 하나의 컴포넌트를 생성하는 데 어려움을 겪지 않기 때문입니다.
도전 과제는 일관성을 깨뜨리지 않고 100번째 컴포넌트를 생성하는 것입니다.
도전 과제는 디자인 시스템을 서서히 저하시키지 않으면서 새 기능을 추가하는 것입니다.
도전 과제는 빠르게 움직이면서 프론트엔드 품질을 확장하는 것입니다.
바로 그 지점에서 컨텍스트가 경쟁 우위가 되기 시작합니다.
현재 제가 사용하고 있는 풀 스택
세 도구가 실제로 작업을 어떻게 나누는지 설명하겠습니다.
Claude Code → 아키텍처, 계획, 무엇을 왜 구축할지 추론.
Cursor → 구현, 계획을 실제 작동하는 소프트웨어로 전환.
Kombai → 디자인, 프론트엔드 세부 조정, 프로젝트가 확장됨에 따라 인터페이스 일관성 유지.
각 계층은 명확한 역할을 가지고 있습니다. 서로를 대체하려 하지 않습니다.
지난 1년 동안 제가 얻은 가장 큰 깨달음은 미래가 아마 단일 AI 도구에 속하지 않을 것이라는 점입니다.
그것은 AI 스택에 속합니다.
특화된 문제를 해결하는 특화된 도구들. 각 계층은 실제로 만들어진 목적을 수행합니다.
Claude Code는 Figma가 되려 하지 않습니다. Cursor는 디자인 시스템이 되려 하지 않습니다. 그리고 Kombai는 범용 코딩 어시스턴트가 되려 하지 않습니다.
가장 강력한 워크플로우는 각 계층이 명확한 책임을 가질 때 발생합니다.
하나의 도구는 추론을 돕습니다.
하나의 도구는 구현을 돕습니다.
하나의 도구는 세부 조정을 돕습니다.
그리고 함께, 결과물은 개별 도구가 단독으로 작업할 때보다 훨씬 더 좋아집니다.
이 이미지는 그 차이를 완벽하게 보여줍니다.
구축과 다듬기는 다른 기술입니다.
구축은 소프트웨어를 실행하게 만듭니다.
다듬기는 사용자가 그것을 신뢰하게 만듭니다.
구축은 기능을 만듭니다.
다듬기는 경험을 만듭니다.
구축은 사람들이 제품을 시도하게 만듭니다.
다듬기는 그들이 다시 돌아오게 만듭니다.
수년 동안 다듬기는 고도로 특화된 프론트엔드 인재가 필요했기 때문에 비용이 많이 들었습니다.
AI가 그것을 바꾸기 시작하고 있습니다.
프론트엔드 엔지니어를 대체함으로써가 아닙니다.
프론트엔드 컨텍스트를 더 쉽게 접근할 수 있게 만듦으로써 말이죠.
궁극적으로 이것이 Kombai가 제 관심을 끈 이유입니다.
코드를 생성하기 때문이 아닙니다.
이제 모든 AI 도구가 코드를 생성합니다.
Cursor를 대체하기 때문이 아닙니다.
그렇지 않습니다.
Claude Code를 대체하기 때문이 아닙니다.
그래서도 안 됩니다.
흥미로운 점은 대부분의 AI 도구가 대체로 무시하는 소프트웨어 개발의 한 계층에 집중하고 있다는 것입니다.
바로 프론트엔드 컨텍스트입니다.
그리고 AI 생성 소프트웨어가 기본이 됨에 따라, 컨텍스트는 전체 워크플로우에서 가장 가치 있는 자산 중 하나가 될 수 있습니다.
현재 제 워크플로우를 한 문장으로 요약하자면 이렇습니다.
Claude Code는 제가 생각하는 것을 돕습니다.
Cursor는 제가 구축하는 것을 돕습니다.
Kombai는 프론트엔드가 의도적이라는 느낌을 갖게 돕습니다.
그리고 지금 소프트웨어에서 일어나고 있는 가장 큰 변화는 AI가 코드를 더 잘 작성하게 되었다는 것이 아닙니다.
우리는 마침내 코드가 결코 전체 작업이 아니었다는 것을 깨닫고 있다는 것입니다.
제품은 시스템입니다.
인터페이스는 시스템입니다.
디자인은 시스템입니다.
프론트엔드 품질은 시스템입니다.
그리고 앞으로 몇 년 동안 승리할 도구는 아마 가장 많은 코드를 생성하는 도구가 아닐 것입니다.
그것들은 가장 많은 컨텍스트를 이해하는 도구일 것입니다.
그것이 제가 프론트엔드 네이티브 워크플로우에 점점 더 관심을 가지는 이유입니다.
스택의 나머지를 대체하기 때문이 아닙니다.
전체 스택이 더 잘 함께 작동하도록 만들기 때문입니다.
그리고 모두가 소프트웨어를 생성할 수 있는 세상에서, 그 차이는 그 어느 때보다 중요해질 수 있습니다.
지금 Kombai 사용해보기: https://kombai.com/
