AI 시대의 새로운 프로덕트-엔지니어링 워크플로에 대한 프런트엔드 엔지니어의 시각
말이 안 되어 보이는 숫자 하나
12일. 두 사람: 프로덕트 디자이너 한 명과 프런트엔드 엔지니어 한 명. 플랫폼 전체 재구축 한 건.
프로토타입이 아닙니다. MVP도 아닙니다. 프로덕션 애플리케이션의 완전한 교체였고, 결국 레거시 코드 26,000줄을 삭제한 단 하나의 PR로 정점을 찍었습니다. 모든 페이지, 모든 라우트, 모든 인터랙션을 처음부터 다시 만들어 실제 사용자에게 배포했습니다.
전통적인 어떤 제품 개발 워크플로에서도 이 일정은 터무니없습니다. 이 정도 범위의 프로젝트는 보통 몇 달이 걸립니다. Figma에서 몇 주간의 디자인 탐색, 여러 차례의 이해관계자 리뷰, 핸드오프 의식, 스프린트 계획, 그리고 픽셀 단위까지 완벽하게 구현하는 더딘 작업이 이어집니다. 여기서 일어난 일은 근본적으로 달랐습니다. 우리가 더 열심히 일했기 때문이 아니라, 함께 일하는 방식이 바뀌었기 때문입니다.
이것은 우리가 VM0에서 Zero 플랫폼을 어떻게 출시했는지, 그리고 그것이 프로덕트-엔지니어링 협업의 미래에 대해 제게 무엇을 가르쳐 주었는지에 대한 이야기입니다.
과거의 병목
모든 프런트엔드 엔지니어는 전통적인 파이프라인을 알고 있습니다.
- 디자이너가 Figma에서 목업을 만든다
- 디자인 리뷰, 반복, 최종 승인
- 간격, 색상, 브레이크포인트가 주석으로 달린 스펙
- 엔지니어가 시각적 스펙을 코드로 옮긴다
- 주고받기: "이거 왼쪽으로 4px만 옮겨 줄 수 있어요?"
- 마침내 API 레이어를 연결한다
- 통합 테스트, 또 한 번의 주고받기
병목은 결코 어느 한 단계에 있지 않았습니다. 그것은 단계와 단계 사이의 틈에 있었습니다. 기다림, 번역 과정에서의 손실, 컨텍스트 전환. 인터랙션에 대한 디자이너의 머릿속 모델은 일단 정적인 Figma 프레임으로 평면화되고 레드라인으로 주석이 달리면, 엔지니어의 책상에 도착할 때 이미 품질이 떨어진 상태입니다. 엔지니어는 디자이너가 상상한 것의 한 버전을 다시 만들지만, 그것은 필연적으로 손실이 있는 복사본입니다.
우리는 이 마찰에 너무 익숙해진 나머지 그것을 더 이상 보지 못하게 되었습니다. 그저 "일이 돌아가는 방식"일 뿐이었습니다.
실험: 만약 디자이너가 코드를 배포한다면?
2026년 3월 5일, 우리 프로덕트 디자이너인 Ming이 PR #3685를 열었습니다: feat(platform): add zero app with shell, pages and polish. 그것은 4,146줄의 동작하는 React 코드를 추가했습니다.
Figma 파일이 아닙니다. 디자인 토큰 내보내기 파일도 아닙니다. 실제로 실행되는 애플리케이션이었습니다.
그 PR에는 완전한 앱 셸이 담겨 있었습니다. 사이드바 내비게이션, 라우팅 구조, 채팅·스케줄·액티비티·팀 관리·설정의 페이지 골격까지, 모두 우리 디자인 시스템으로 스타일링되었고 모두 브라우저에서 렌더링되었습니다. 데이터는 목 데이터였지만, UI는 진짜였습니다. npm run dev로 모든 페이지를 클릭하며 둘러볼 수 있었습니다.
Ming은 전통적인 의미에서 이 코드를 처음부터 직접 작성한 것이 아닙니다. 그녀는 AI 코딩 도구(처음에는 Cursor, 이후에는 Claude Code)를 사용해 자신의 디자인 비전을 곧바로 React 컴포넌트로 옮겼습니다. AI가 기계적인 번역(JSX 구조, CSS 속성, 컴포넌트 조합)을 처리하는 동안, Ming은 어떤 AI도 내릴 수 없는 시각적·인터랙션적 결정을 이끌었습니다. 레이아웃의 리듬, 정보의 위계, 트랜지션의 느낌 같은 것들 말입니다.
이후 나흘에 걸쳐 세 개의 PR이 더 추가되었습니다.
| 날짜 | PR | Ming이 배포한 내용 |
|---|---|---|
| 3월 5일 | #3685 | 앱 셸, 사이드바, 모든 페이지 골격 (+4,146줄) |
| 3월 6일 | #3825 | 스케줄 페이지, UI 다듬기 (+2,650줄) |
| 3월 9일 | #3993 | 온보딩 플로, Slack 설정 다이얼로그 (+1,146줄) |
| 3월 9일 | #4050 | About 페이지, 플로팅 내비게이션 카드 |
3월 9일에 이르러, 우리 새 플랫폼의 전체 프런트엔드 표면이 실행 가능한 코드로 존재하게 되었습니다. 결국 프로덕션에서 보게 될 모든 페이지가 이미 개발 환경에서 클릭 가능했습니다. 다만 아직 실제로 동작하는 것은 아무것도 없었을 뿐입니다.
바로 거기서 제 역할이 시작되었습니다.
나의 새로운 일: 영혼을 불어넣기
3월 9일에 코드베이스를 열었을 때, 저는 평면 디자인을 코드로 옮기는 흔한 과제를 마주하지 않았습니다. 코드는 이미 거기 있었습니다. 제 일은 모든 목 데이터를 현실로 바꾸고, 아름답게 디자인된 각 표면을 그 아래에서 살아 숨 쉬는 백엔드에 연결하는 것이었습니다.
이것은 제 작업 방식을 근본적으로 바꿔 놓았습니다. 픽셀을 고민하는 대신, 저는 데이터 흐름을 생각하고 있었습니다. "이게 목업과 일치하나?"라고 묻는 대신, "이 페이지에는 어떤 API 호출이 필요하고, 실패하면 어떻게 되지?"라고 묻고 있었습니다.
제 첫 한 주는 다음과 같았습니다.
1일차 (3월 9일): 인증과 조직 전환. 저는 Ming의 셸을 Clerk 인증에 연결하고, 크로스 도메인 리다이렉트를 추가하고, 조직 전환기가 실제로 조직을 전환하도록 만들었습니다. PR 두 개, 둘 다 같은 날 머지되었습니다.
2일차 (3월 10일): 커넥터와 스케줄. 저는 목 커넥터 그리드를 실제 API 데이터로 교체하고, 스케줄 탭을 실제 cron 작업에 연결하고, 인스트럭션 에디터를 백엔드에 연결했습니다. PR 네 개.
3일차 (3월 11일): 대대적인 연결의 날. 팀 페이지는 실제 서브에이전트 데이터를 얻었습니다(+3,271줄). 액티비티 페이지는 실제 로그를 얻었습니다. 그리고 백미: 채팅 페이지가 실제 에이전트 실행 파이프라인에 연결되어, 약 1,200줄의 데모 코드를 동작하는 AI 대화 인터페이스로 교체했습니다. 같은 날, 저는 FeatureSwitchKey.Zero를 도입했습니다. 이는 구 플랫폼과 신 플랫폼을 나란히 실행할 수 있게 해 주는 기능 플래그였습니다.
45일차 (3월 1213일): 파일 첨부, 세션 관리, 멀티 에이전트 채팅, 설정 영속화. Ming이 만든 모든 페이지가 이제 실제 일을 하고 있었습니다.
그 리듬은 거의 음악적이었습니다. 매일 아침 저는 Ming의 스캐폴드에서 페이지 하나를 골라, 그 컴포넌트 구조를 살펴보고, 어떤 데이터가 필요한지 파악하고, API 연동을 구축하고, 에러 상태를 처리한 뒤 푸시했습니다. 오후가 되면 또 다른 페이지가 살아났습니다.
기능 스위치: 평행 세계
FeatureSwitchKey.Zero 기능 플래그는 따로 언급할 가치가 있습니다. 이 마이그레이션을 무모한 것이 아니라 안전한 것으로 만든 것이 바로 이것이기 때문입니다.
3월 11일부터 우리 프로덕션 앱은 두 개의 완전한 UI를 병렬로 실행했습니다. 구 시스템의 사용자는 구 라우트를 보았습니다. 신 시스템의 내부 테스터는 Zero를 보았습니다. 제가 연결한 모든 페이지는 단 한 명의 사용자 워크플로도 위험에 빠뜨리지 않으면서 프로덕션 맥락에서 테스트될 수 있었습니다.
이건 혁명적인 게 아닙니다. 기능 플래그는 표준적인 관행입니다. 하지만 기능 플래그와 디자인-애즈-코드 워크플로의 결합은 특별한 무언가를 만들어 냈습니다. 우리는 새 플랫폼의 전체 UX를 검증할 수 있었고(Ming이 완전하고 둘러볼 수 있는 UI를 만들어 두었기 때문에), 동시에 각 페이지를 점진적으로 기능하게 만들 수 있었습니다(제가 하나씩 연결하고 있었기 때문에). 어느 시점에서든 무언가 잘못되면 스위치를 다시 되돌릴 수 있었습니다.
아무것도 잘못되지 않았습니다.
12일차: 대전환
3월 17일, 저는 PR #5095를 열었습니다: refactor: remove all non-zero platform pages and feature flag.
그 diff: +456줄, -26,041줄.
Before: 옛 VM0 Platform. 테이블, 실행 ID, 그리고 가공되지 않은 세션 데이터.
After: 새로운 Zero. 고정된 에이전트와 유스케이스 카드가 있는 대화형 AI 워크스페이스.
단 한 번의 머지로, 모든 레거시 라우트가 삭제되었습니다. 기능 플래그도 제거되었습니다. Zero는 더 이상 하나의 선택지가 아니었습니다. 그것이 유일한 모드였습니다. 후속 PR(#5155)은 /zero URL 접두사를 통째로 없앴습니다. /zero/chat이었던 것이 그냥 /chat이 되었습니다.
제가 이 절단을 자신 있게 단행할 수 있었던 이유는 무엇일까요? 그것은:
- 모든 페이지가 최소 5일 동안 기능 플래그 아래에서 실행되고 있었습니다
- 모든 API 연동이 프로덕션 데이터를 대상으로 테스트되었습니다
- 구 시스템과 신 시스템은 같은 백엔드를 공유했습니다. 이것은 데이터 마이그레이션이 아니라 프런트엔드 교체였습니다
- 우리는 그 과정 내내 새 시스템에서 피드백을 주는 실제 사용자를 두고 있었습니다
26,000줄은 불안 속에서 삭제된 것이 아닙니다. 그것은 안도 속에서 삭제되었습니다.
패턴은 반복된다
저를 가장 놀라게 한 것은 마이그레이션 그 자체가 아니었습니다. 우리가 발견한 워크플로가 이후 모든 기능 개발의 기본 모드가 되었다는 점이었습니다. Ming은 AI의 도움을 받아 UI 셸을 만들고, 저는 로직을 연결하고 아키텍처를 확장합니다. 동일한 디자인-애즈-코드 패턴이, 이번에는 기능 단위에서 펼쳐졌습니다.
권한 시스템 (3월 19일 → 4월 7일)
Ming은 PR #5467을 배포했습니다. Sheet 컴포넌트와 토글 컨트롤이 있는 권한 드로어 UI였습니다. 커밋 세 개, 깔끔한 UI.
저는 같은 PR에 커밋 13개를 추가했습니다. firewall_access_requests를 위한 데이터베이스 마이그레이션, API 엔드포인트, 통합 테스트, 린트 수정. 그런 다음 이후 두 주에 걸쳐 10개 이상의 후속 PR이 전체 권한 레이어를 구축했습니다. 승인 카드 재설계, 접근 요청에 대한 Slack 알림, 권한 문제를 진단하는 CLI doctor 명령어, 그리고 결국 코드베이스 전반에서 개념 전체의 이름을 "firewall"에서 "permission"으로 바꾸는 작업까지요.
Ming의 드로어는 씨앗이었습니다. 권한 시스템은 그 나무였습니다.
스케줄 시스템 (3월 23일 → 4월 13일)
Ming은 스케줄 상세 라우트와 캘린더 UX를 디자인했습니다(#6155). 깔끔한 UI 작업의 커밋 세 개.
저는 커밋 14개를 추가했습니다. 자동 생성을 포함한 설명 편집, 알림용 Slack 채널 선택, 저장되지 않은 변경 사항 확인 다이얼로그, 캘린더/리스트 뷰 통합, 그리고 포괄적인 테스트. 그런 다음 15개 이상의 후속 PR이 이를 실행 이력, 시간대 처리, cron 표현식 지원을 갖춘 완전한 반복 작업 시스템으로 확장했습니다.
Telegram 연동 (4월 27일 → 4월 28일)
이 시점에 이르러 패턴이 매우 잘 다듬어져 있어서, 우리는 플랫폼 연동 하나를 통째로 48시간 만에 배포했습니다. Ming은 설정 UI(#11196)와 온보딩 플로(#11399)를 만들었습니다. 저는 멀티 봇 API, 메시지 송수신, 파일 업로드/다운로드, 리치 메시지 컨텍스트, Ably 실시간 업데이트, 그리고 E2E 테스트를 구축했습니다. 다음 날, 그것은 모든 사용자에게 활성화되었습니다.
AI는 어디에 들어맞는가
저는 여기서 AI의 역할에 대해 정확히 말하고 싶습니다. 그것을 과장하거나 과소평가하기 쉽기 때문입니다.
AI는 디자이너가 코드를 작성하도록 해 주었습니다. Ming은 프로덕트 디자이너이지 소프트웨어 엔지니어가 아닙니다. 그녀는 React 훅이나 TypeScript 제네릭이 아니라 레이아웃, 위계, 인터랙션으로 사고합니다. AI 도구(Cursor, 그다음 Claude Code)는 디자인 의도를 동작하는 코드로 옮기는 기계적인 번역을 처리함으로써 그 간극을 메웠습니다. Ming이 지휘하고, AI가 타이핑했습니다. 그 결과는 디자이너가 작성했지만 엔지니어가 그 위에 쌓아 올릴 수 있는 코드였습니다.
AI는 리뷰 루프를 가속했습니다. 협업 PR에서 제 AI 에이전트는 Ming의 코드를 리뷰하고, 이슈를 우선순위(P0/P1/P2)별로 분류하고, 수정 커밋을 직접 푸시하곤 했습니다. PR #5060은 38분 만에 다섯 차례의 리뷰 라운드를 거쳤습니다. PR #5467은 20분 만에 세 차례의 라운드를 마쳤습니다. 이것은 "AI가 코드 리뷰를 대체하는 것"이 아닙니다. 저는 여전히 모든 변경 사항을 읽습니다. 하지만 린트 이슈, 누락된 타입, 테스트 공백을 찾아내는 기계적인 작업은 자동화되어 사라졌습니다.
AI는 디자인 결정을 내리지 않았습니다. 각 페이지의 정보 구조, 인터랙션 패턴, 시각적 위계, 이것들은 사용자 리서치와 도메인 전문성에 기반한 Ming의 제품 감각에서 나왔습니다. AI는 설정 페이지를 생성할 수는 있지만, 무엇이 토글이고 무엇이 드롭다운이어야 하는지, 혹은 언제 확인 다이얼로그가 정당하고 언제 그것이 마찰인지는 결정할 수 없습니다.
AI는 아키텍처 결정을 내리지 않았습니다. 병렬 배포를 위해 기능 플래그를 사용하기로 한 선택, API 레이어 분리 전략, 페이지를 한꺼번에가 아니라 점진적으로 연결하기로 한 결정, 이것들은 엔지니어링적 판단이었습니다. AI는 제가 코드를 더 빨리 작성하도록 도왔지만, 순서 결정과 리스크 관리는 사람의 몫이었습니다.
솔직한 요약은 이렇습니다: AI는 디자인과 엔지니어링 사이의 번역 레이어를 없앴습니다. 그것은 두 분야 중 어느 쪽도 대체하지 않았습니다. 그것은 둘 사이의 간극을 없앴습니다.
내 역할에 대해 바뀐 것
이 워크플로 속에서 석 달을 살아 본 뒤, 저는 프런트엔드 엔지니어로서의 제 역할을 다르게 봅니다.
저는 더 이상 시각적 번역가가 아닙니다. Figma 파일을 받아 간격 값을 맞추느라 몇 시간을 보내던 날들은 끝났습니다. 제가 그 일을 더 빨리 하게 되어서가 아니라, 그것이 더 이상 제 일이 아니기 때문입니다. 디자이너의 의도는 코드의 그림이 아니라 코드 그 자체로 도착합니다.
저는 아키텍처 확장자입니다. 제 핵심 가치는 동작하는 UI 표면을 가져다가 그 아래의 보이지 않는 인프라를 구축하는 것입니다. API 연동, 데이터 검증, 에러 처리, 권한 확인, 실시간 업데이트, 테스트. 대부분의 협업 PR에서의 비율이 이를 말해 줍니다. Ming은 UI 커밋 3개를 기여하고, 저는 그 외 모든 것의 커밋 13개를 기여합니다.
저는 품질 게이트키퍼입니다. AI 보조 리뷰 루프 덕분에, 저는 이전보다 훨씬 넓은 표면적에 걸쳐 코드 품질을 유지할 수 있습니다. 자동화된 리뷰가 기계적인 이슈를 잡아내고, 저는 아키텍처적 고려 사항, 엣지 케이스, 그리고 기능이 실제로 처음부터 끝까지 동작하는지에 집중합니다.
저는 배포 전략가입니다. 기능 플래그, 점진적 연결, 병렬 배포, 기능이 코드에서 프로덕션으로 가는 순서를 정하는 일은 이제 뒷전의 고려 사항이 아니라 제 일의 핵심적인 부분입니다.
숫자들
석 달. 두 사람. 처음부터 끝까지 AI 보조.
- 머지된 PR 914개 (제 것 679개, Ming의 것 235개)
- 첫 스캐폴드부터 전체 플랫폼 교체까지 12일
- 완전한 Telegram 연동에 48시간 (우리의 가장 빠른 기능)
- 단 한 번의 자신 있는 머지로 삭제된 26,000줄
- 제 PR의 **88%**와 Ming의 PR의 **66%**가 AI 공동 작성 기록을 담고 있음
이것들은 무리해서 갈아 넣은 지표가 아닙니다. 우리 둘 중 누구도 주말에 일하거나 밤을 새우지 않았습니다. 그 속도는 죽은 시간을 없앤 데서 나옵니다. 핸드오프 회의, 스펙 오해, "이거 4px만 옮겨 줄 수 있어요" 같은 주고받기 말입니다. 디자인 의도가 곧바로 코드로 흘러들고, 엔지니어링이 그 코드를 제자리에서 확장할 때, 낭비는 그저 줄어듭니다.
이것이 팀에 의미하는 것
저는 모든 팀이 이런 방식으로 일해야 한다고 주장하는 것이 아닙니다. 이 워크플로는 우리의 특정한 맥락에서 나왔습니다. 작은 팀, 처음부터 다시 만들 수 있는 그린필드 기회, 그리고 유능한 AI 코딩 도구에 대한 초기 접근. 여러분의 경우는 다를 것입니다.
하지만 저는 그 밑바탕의 변화가 보편적이라고 믿습니다: 디자인과 엔지니어링 사이의 경계는 녹아내리고 있으며, AI가 그 용매입니다. AI 도구가 의도를 코드로 옮기는 데 더 능숙해질수록, 더 많은 디자이너가 코드를 직접 배포할 것입니다. 그렇게 되면 엔지니어는 번역에 쓰는 시간을 줄이고 아키텍처, 품질, 배포에 더 많은 시간을 쓰게 될 것입니다.
프런트엔드 엔지니어의 일은 사라지지 않습니다. 그 형태가 바뀌고 있을 뿐입니다. 그리고 솔직히 말하면? 새로운 형태가 더 흥미롭습니다.
Yuma는 VM0의 프런트엔드 엔지니어로, AI 에이전트 운영체제인 Zero를 구동하는 플랫폼을 만듭니다. 그는 인정하고 싶은 것보다 더 많은 레거시 코드를 대량으로 삭제해 왔습니다.
