AI 제품은 겉으로는 단순해 보인다. 프롬프트 입력창, 생성 버튼, 결과물. 그런데 모델이 두 개가 되고, 비동기 작업이 끼어들고, 비용 계산이 실시간으로 붙는 순간—상태 설계는 완전히 다른 문제가 된다. 지금 프론트엔드 개발자들이 직면한 진짜 과제는 '어떤 모델을 쓸 것인가'가 아니라 '모델이 바뀌어도 UX가 흔들리지 않는 구조를 어떻게 설계할 것인가'다.
모델을 교체해도 UI가 재작성되지 않으려면
dev.to에 공개된 Flux 3 AI 프론트엔드 아키텍처 글은 이 문제를 정면으로 다룬다. 핵심 통찰은 하나다. 모델별 폼을 만들지 말고, 모델의 '역량'을 데이터로 정의하라. 각 모델이 지원하는 해상도, 길이, 화면 비율, 레퍼런스 이미지 수를 선언적으로 명세하고, UI는 그 명세를 읽어 컨트롤을 렌더링한다. 사용자가 모델을 전환할 때 이전 모델에서 유효했던 설정값이 새 모델에서 유효하지 않으면, 자동으로 해당 모델의 기본값으로 정규화된다.
이 단 하나의 결정이 제거한 것이 인상적이다. 모델마다 분기되던 provider-specific 조건문 전체가 사라졌다. 제품 레벨의 모델 이름과 실제 프로바이더 라우팅을 분리한 것도 같은 맥락이다. UI는 역량과 정규화된 상태에만 의존하고, 라우팅 세부사항은 하위 레이어에 격리된다. 모델이 교체되거나 추가돼도 에디터, 히스토리 카드, 설정 컨트롤을 재작성할 필요가 없다.
에러는 예외가 아니라 설계의 일부다
Flux 3 AI가 두 번째로 강조하는 것은 실패 상태의 설계다. 업로드 파이프라인만 봐도 그렇다. 파일 타입 검증, 픽셀 한계 적용, 리사이즈·재인코딩, 직접 업로드 세션 요청, 스토리지 업로드, 메타데이터 확정, 폴백 멀티파트 업로드—각 단계가 uploading, uploaded, error 상태를 명시적으로 갖는다. 각 업로드 항목은 AbortController를 소유하며, 레퍼런스를 제거하면 진행 중인 요청이 즉시 취소된다. 임시 Object URL은 호스팅 에셋으로 교체된 뒤 해제된다.
비동기 생성 잡의 폴링도 마찬가지다. 적어도 하나의 잡이 진행 중일 때만 폴링하고, 모든 잡이 터미널 상태에 도달하면 멈춘다. 잡 생성·삭제 시 히스토리와 크레딧 잔액을 함께 무효화해 두 뷰가 어긋나지 않게 한다. 글의 표현을 빌리면 "AI 생성 워크플로우에서 프로바이더 실패, 업로드 제한, 장시간 실행 잡은 예외가 아니라 정상 상태다." 이것을 설계의 전제로 삼는 순간, 상태 모델은 오히려 단순해진다.
병렬 에이전트, 충돌보다 '인식 부재'가 진짜 문제
상태 설계 문제는 프론트엔드 UI 안에만 있지 않다. 개발 워크플로우 자체가 멀티 에이전트화되면서 동일한 구조적 긴장이 발생한다. dev.to의 병렬 에이전트 세션 아키텍처 글은 두 가지 장애 유형을 구분한다. corruption—두 세션이 같은 파일에 쓰는 충돌—과 collision—서로의 존재를 모른 채 같은 작업을 중복하는 문제. 그리고 이 둘은 구조적으로 다른 해법이 필요하다.
충돌은 구조로 해결한다. 각 세션은 자신의 session id를 키로 한 디렉터리에만 쓴다. 공유 파일이 존재하지 않으니 락이 필요 없다. 유일한 예외는 브랜치당 하나의 current-task.md—"이 브랜치가 지금 무엇을 하고 있는가"를 답하는 단 하나의 공유 지점이다. 설계 원칙은 명쾌하다. 기본적으로 아무것도 공유하지 말고, 공유할 때는 그 이유가 분명한 단 하나의 파일만 공유하라.
인식 부재는 presence layer로 해결한다. 세션 시작 시 살아있는 다른 세션들—각각이 어떤 파일을 건드리고 있는지—을 컨텍스트에 주입한다. 락이 아니라 인식이다. stale record를 걸러내기 위해 read time에 OS의 pid와 프로세스 시작 시각을 교차 검증한다. 신뢰할 수 없는 레지스트리는 없는 것보다 나쁘다—에이전트가 무시하는 법을 배우기 때문이다.
AI 에이전트, 개발자가 아닌 기획자의 손에도 닿고 있다
velog의 Claude Code + Xcode 연동 글은 다른 각도에서 같은 흐름을 보여준다. 서비스 기획자가 터미널을 처음 열고, npm이 없어서 막히고, Homebrew부터 Node.js, Claude Code까지 설치 체인을 따라가며 결국 자연어로 Swift 파일을 생성하는 과정이다. 기술적으로는 간단한 셋업 가이드지만, 시사하는 바는 크다. AI 코딩 에이전트의 진입장벽이 낮아지면서 '개발자가 AI 도구를 쓴다'는 프레임이 '비개발자도 프로토타입을 직접 검증한다'는 프레임으로 이동하고 있다.
이 변화는 프론트엔드 개발자에게 두 가지를 동시에 요구한다. 첫째, AI가 생성한 코드가 붙을 시스템의 상태 설계가 더 견고해야 한다. 검증 없이 붙는 코드가 늘어날수록 정규화와 에러 상태 설계의 부재가 더 크게 터진다. 둘째, 빠른 프로토타입→검증→고도화 루프의 시작점이 낮아진다. 기획자가 직접 UI를 생성하고 피드백할 수 있다면, 개발자는 그 결과물을 받아 프로덕션 수준으로 끌어올리는 역할에 더 집중하게 된다.
결국 상태 설계가 AI 제품의 신뢰도를 결정한다
세 사례를 겹쳐보면 하나의 방향이 보인다. AI 모델이 많아질수록, 에이전트 세션이 병렬화될수록, 비개발자가 AI 도구를 직접 쓸수록—상태를 어떻게 정의하고, 공유하고, 격리하고, 실패를 어떻게 표현하는가가 시스템 전체의 신뢰도를 결정한다.
역량을 데이터로 선언하고, 상태를 쓰는 주체를 격리하고, 인식을 락보다 먼저 설계하고, 에러를 예외가 아닌 first-class 상태로 다루는 것. 이것은 새로운 패턴이 아니다. 하지만 AI가 만드는 복잡도의 속도가 빨라지면서, 이 원칙들을 놓쳤을 때의 비용이 이전과 달라지고 있다. 모델이 바뀌면 폼을 재작성하던 시대는 끝났다. 이제 상태 설계가 AI 제품의 확장성을 결정한다.