지난 몇 주 사이, 프론트엔드 개발자의 일상을 조용히 재편할 두 가지 사건이 잇달아 터졌다. Figma는 실제 코드 레포지터리를 디자인 캔버스에 직접 연결하는 Figma Make를 공개했고, Apple은 WWDC26에서 Gemini 모델을 기반으로 한 새 AI 아키텍처와 함께 시스템 오케스트레이터라는 개념을 iOS·macOS 전반에 이식했다. 두 사건은 서로 다른 레이어에서 일어났지만, 같은 방향을 가리키고 있다. 디자인과 코드 사이의 경계, 그리고 앱과 플랫폼 AI 사이의 경계가 동시에 녹아내리고 있다는 것.
Figma Make: 디자인 툴이 IDE를 집어삼키다
Figma Make의 핵심은 단순한 '디자인-핸드오프 자동화'가 아니다. 실제 운영 레포를 피그마 안으로 끌어들여, 로컬 개발 서버를 자동 실행하고 실제 데이터 환경 위에서 앱을 확인하게 한다. 개발자는 코드 파일을 IDE에서 열지 않고도 캔버스에서 레이아웃·색상·타이포그래피를 시각적으로 수정하고, AI 에이전트가 관련 코드 파일을 찾아 반영한다. 애니메이션이나 인터랙션 변경이 필요하면 렌더링된 화면 위에 직접 주석을 달고 텍스트·음성·이미지·피그마 프레임으로 에이전트에게 의도를 전달할 수 있다.
더 주목할 부분은 Git 워크플로우가 내부에 통합됐다는 점이다. 브랜치 생성, 커밋, PR 제출까지 피그마 안에서 처리된다. 디자이너가 캔버스에서 수정한 내용이 코드에 반영되고, 개발자가 코드에서 바꾼 내용이 다시 캔버스 레이어로 돌아온다. 단방향 핸드오프였던 디자인-개발 협업이 양방향 실시간 루프로 바뀌는 구조다. ZDNet 보도에 따르면 피그마는 "AI 에이전트가 더 많은 코드를 생성할수록 디자인 판단의 중요성이 커지는 환경"에 맞춰 이 워크플로우를 강화하겠다고 명시했다.
Apple Intelligence: 플랫폼이 앱의 새 진입점이 된다
Apple의 움직임은 다른 층위에서 비슷한 충격을 준다. WWDC26에서 공개된 새 Apple Intelligence 아키텍처는 Gemini 계열 기술을 기반으로 Google과 공동 개발한 Apple Foundation Models(AFM)를 중심으로 재편됐다. 온디바이스의 AFM Core·AFM Core Advanced부터 Private Cloud Compute의 AFM Cloud·AFM Cloud Pro까지 5개 모델이 계층화된다. 그 위에 시스템 오케스트레이터가 얹혀, 활성 앱과 사용자의 현재 작업 맥락에 따라 AI 응답을 조율한다.
dev.to의 TokenMixAI 분석이 핵심을 정확히 짚었다. "Siri AI는 공개 LLM API가 아니다." 개발자에게 열린 경로는 chat-completions 엔드포인트가 아니라 App Intents, App Schemas, Spotlight 시맨틱 인덱스, View Annotations, Foundation Models 프레임워크다. 쉽게 말하면, 앱이 운영체제에게 '나는 이런 행동을 할 수 있고 이런 콘텐츠를 갖고 있다'고 스스로를 읽힐 수 있게 만드는 작업이다. 기존 LLM 백엔드를 교체하는 게 아니라, Siri가 앱의 새로운 진입점이 될 수 있도록 앱의 '의미 구조'를 재설계하는 일이다.
두 흐름이 가리키는 같은 질문
Figma Make와 Apple Intelligence는 표면적으로 다른 도구지만, 프론트엔드 개발자에게 던지는 질문은 동일하다. "당신은 도구를 조작하는 사람인가, 경험을 설계하는 사람인가?"
Figma Make가 확산되면 디자이너가 PR을 열고 개발자가 캔버스를 수정하는 장면이 일상화될 것이다. 이때 프론트엔드 개발자의 차별점은 코드를 빠르게 짜는 능력이 아니다. 컴포넌트 구조가 디자인 시스템의 의도를 얼마나 정확히 반영하는지, AI가 생성한 코드가 접근성(a11y) 기준을 충족하는지, 성능 예산 안에서 인터랙션이 설계됐는지를 판단하고 결정하는 능력이다.
Apple Intelligence 통합도 마찬가지다. App Intents를 단순히 '등록'하는 것과, 사용자가 Siri를 통해 앱에 진입할 때 어떤 컨텍스트를 갖고 오는지를 고려해 진입점별 경험을 설계하는 것은 전혀 다른 작업이다. EU·중국 지역 미지원으로 인한 기능 분기, 온디바이스 모델과 클라우드 모델 간의 응답 품질 차이를 어떻게 앱 UX에서 처리할 것인지—이 결정들은 AI 에이전트가 대신할 수 없다.
시사점: 세 가지 실천 전환
첫째, 컴포넌트를 'AI-readable'하게 설계하라. Figma Make에서 AI 에이전트가 정확히 코드를 찾아 수정하려면, 컴포넌트 구조와 네이밍이 일관된 의미 체계를 가져야 한다. 디자인 토큰과 컴포넌트 API를 정리하는 일이 이제 AI 워크플로우 효율과 직결된다.
둘째, App Intents를 '기능 등록'이 아닌 '경험 진입점 설계'로 접근하라. Siri를 통해 들어오는 사용자는 앱을 직접 열고 들어오는 사용자와 다른 맥락을 갖는다. 이 차이를 인식하고 각 진입점에 맞는 플로우를 설계하는 것이 Apple Intelligence 시대의 프론트엔드 과제다.
셋째, AI가 생성한 결과물의 '심판'이 되는 능력을 키워라. Figma Make든 Cursor든, AI가 코드를 쏟아낼수록 그것이 올바른지 판단하는 사람의 가치는 올라간다. Core Web Vitals, 접근성 감사, 디자인 시스템 일관성 검토—이 리뷰 능력이 AI 시대 프론트엔드 개발자의 핵심 경쟁력이 된다.
전망: 경계가 사라진 자리에 남는 것
Figma Make의 베타는 아직 Mac 전용이고, Apple Intelligence의 Siri AI는 EU와 중국에서 미출시 상태다. 기술은 아직 완성되지 않았다. 하지만 방향은 명확하다. 디자인 툴은 코드 환경을 흡수하고, 플랫폼 AI는 앱의 새 진입점을 만들며, 두 흐름 모두 '경계 위에 서 있던 전문가'의 역할을 재정의하고 있다.
흥미롭게도 Hacker News의 한 댓글이 Apple의 전략을 가장 잘 요약했다. "외부 도구를 개인정보 보호 아키텍처로 감싸고, 운영체제에 넣은 뒤, 오케스트레이션 계층을 제품화하는 것—이게 Apple의 방식이다." 프론트엔드 개발자에게도 비슷한 전략이 필요하다. AI 도구를 감싸고, 판단 구조 안에 넣고, 그 위에서 경험을 조율하는 사람. 경계가 사라진 자리에 남는 것은 결국 설계 판단력을 가진 사람이다.