프론트엔드의 진짜 난제는 '코드는 맞는데 화면이 안 맞아'다. Codex가 비주얼 피드백 루프, Figma 구조 추출, 초고속 Codex-Spark, 목업·PoC·배포·브라우저 게임으로 디자이너·프론트엔드 작업을 어떻게 바꾸는지 실제 프롬프트와 사례로 풀어봅니다. Codex Use Cases 특집 3편.
1편에서 Codex의 탄생과 아키텍처를, 2편에서 엔지니어의 작업 흐름을 다뤘습니다. 이번엔 시각의 영역 — 디자이너와 프론트엔드 개발자의 세계입니다.
여기엔 백엔드와 결정적으로 다른 난제가 하나 있습니다.
백엔드 코드는 테스트가 "맞다/틀리다"를 알려줍니다. 하지만 프론트엔드는? "이 버튼이 레퍼런스보다 8px 위에 있다", "모바일에서 그리드가 안 무너진다" 같은 건 테스트가 안 잡습니다. 눈으로 봐야 합니다.
그래서 오랫동안 "AI가 만든 UI"는 미덥지 않았습니다. 그럴듯한 코드를 뱉어도 막상 브라우저에 띄우면 어딘가 어긋나 있었죠. 2026년의 Codex가 이 문제를 어떻게 정면돌파하는지 — 그 핵심 메커니즘부터 시작하겠습니다.
이 시리즈 (총 6편) · 1. Codex의 탄생 · 2. 엔지니어를 위한 Codex · 3. (현재 글) 디자이너·프론트엔드 · 4. iOS·macOS · 5. Knowledge Work · 6. Computer Use & 자동화
3편 전체를 관통하는 단 하나의 개념을 먼저 박아두겠습니다. 바로 비주얼 피드백 루프(visual feedback loop)입니다.
거의 모든 프론트엔드 use case가 이 루프로 끝납니다. Codex는 자기가 만든 UI가 "잘 됐겠지" 하고 넘어가지 않습니다. $playwright-interactive 스킬로 실제 브라우저에 앱을 띄우고, 해당 화면을 스크린샷으로 찍고, 레퍼런스와 대조한 뒤, 어긋난 곳을 고치고, 다시 확인합니다.
아래에서 이 루프를 직접 돌려보세요. 레퍼런스와의 일치도가 어떻게 올라가는지 보입니다.
이 "보고 고친다"는 능력은 1편에서 다룬 Codex의 이미지 입력(vision) 과 Computer Use 계보가 프론트엔드에 응용된 것입니다. 이제 이 루프가 각 use case에서 어떻게 쓰이는지 따라가 봅시다.
가장 흔한 작업부터. 디자이너가 준 스크린샷(혹은 다른 사이트의 레퍼런스)을 반응형 UI 코드로 옮기는 일입니다. Build Responsive Front-end Designs가 이걸 다룹니다.
핵심은 두 가지입니다. 첫째, 데스크톱뿐 아니라 모바일·hover·선택·로딩·빈 상태 스크린샷까지 함께 줍니다. 둘째, Codex에게 우리 저장소의 디자인 시스템을 재사용하라고 못 박습니다. 안 그러면 고립된 일회용 컴포넌트를 만들어내거든요.
$playwright-interactive로 레퍼런스와 일치하는지 확인하고, 맞을 때까지 반복할 것."그러면 Codex는 스크린샷을 코드로 옮기고, 여러 breakpoint(375px 모바일 / 768px 태블릿 / 데스크톱)에서 실제로 렌더해보며 간격·줄바꿈·정렬이 깨지지 않는지 검증합니다. 사람이 일일이 창 크기를 줄여가며 확인하던 일을 루프가 대신하는 거죠.
비유하면, 디자인 시안을 받은 신입 퍼블리셔가 "다 됐어요" 하기 전에 스스로 모든 기기에서 열어보고 어긋난 곳을 고쳐서 가져오는 셈입니다.
스크린샷은 결국 픽셀일 뿐입니다. Codex가 "이 회색은 무슨 색 토큰이지? 이 간격은 16px인가 18px인가?"를 추측해야 하죠. Turn Figma Designs into Code는 이 추측을 없앱니다.
비결은 Figma MCP 서버입니다. (MCP가 무엇인지는 1편에서 "에이전트의 USB 포트"로 설명했죠.) Figma 스킬을 통해 Codex는 디자인 파일에서 다음을 직접 호출합니다.
| MCP 호출 | 가져오는 것 |
|---|---|
get_design_context | 특정 노드/프레임의 *변수·디자인 토큰·컴포넌트·오토레이아웃·에셋 참조·variant* |
get_metadata | 파일 지도 — 응답이 잘리면 *필요한 노드만 다시* 가져오기 위함 |
get_screenshot | 정확히 구현할 *그 variant*의 이미지 |
차이가 결정적입니다.
color/primary 토큰, 이 간격은 space/4, 이건 Button/secondary variant"라고 *명시적으로* 안다. 추측이 아니라 사실.UI 작업의 상당수는 거창하지 않습니다. "버튼 살짝 오른쪽으로", "이 breakpoint 값 좀", "hover 색 바꿔줘". 이런 국소적이고 표면적인 반복에 가장 깊은 모델을 쓰는 건 낭비입니다 — 느리니까요. Make Granular UI Changes는 이걸 위한 특수 모드, Codex-Spark를 씁니다.
정식 이름은 GPT-5.3-Codex-Spark(2026년 2월 공개, 리서치 프리뷰). OpenAI의 가장 빠른 코딩 모델입니다.
이 속도는 Cerebras Wafer Scale Engine 3라는 특수 하드웨어에서 나옵니다. 영구 WebSocket 연결로 왕복 지연을 크게 줄였죠. 대신 트레이드오프가 있습니다 — OpenAI도 "범용 모델보다 덜 똑똑하지만, 실시간 코딩 반복을 위해 설계했다"고 명시합니다. 기본적으로 최소한의 국소 수정만 하고, 시키지 않으면 테스트도 자동으로 안 돌립니다.
작업 방식이 재밌습니다. 앱과 dev 서버를 켠 채, Codex를 브라우저 옆 작은 플로팅 창에 띄워두고 한 번에 하나씩 고칩니다.
그럼 언제 다시 깊은 모델로 돌아가야 할까요? 직접 골라보세요.
원칙은 단순합니다. 국소적·표면적 반복은 Spark로 즉각, 구조적·다파일·접근성 결정은 플래그십으로. "버튼 옮기는 데 가장 깊은 모델은 필요 없다"는 거죠. (Spark는 Pro 플랜 전용이며, 없으면 최신 범용 모델 — 현재 gpt-5.5 — 을 낮은 추론 강도로 대체합니다. 모델 이름은 빠르게 바뀌니 역할로 기억하세요.)
이제 코드 이전 단계, 디자이너의 영역으로 갑니다. Turn User Stories into UI Mocks는 흩어진 피드백을 모아 팀이 반응할 수 있는 목업으로 만듭니다.
문제는 피드백이 사방에 흩어져 있다는 것입니다 — Slack 스레드, Linear 티켓, 구글 드라이브 문서. Codex는 플러그인으로 이걸 한자리에 모읍니다.
@slack 스레드 · @linear 티켓 · @google-drive 문서에서 피드백 수집@slack [채널/스레드] · @linear [프로젝트] · @google-drive [문서]손으로 여러 도구를 오가며 정리하던 일이 사라지고, 목업이 실제 사용자 맥락에 근거해 나옵니다. 코드 한 줄 짜기 전에요.
목업이 좋으면 작동하는 시제품(PoC)으로 넘어갑니다. Idea to Proof of Concept는 명세서 대신 돌아가는 프로토타입으로 제품 질문에 답합니다.
gpt-image-2)으로 고품질 UI 목업을 생성해 *비주얼 방향*부터 잡는다그리고 마지막 한 걸음 — 배포해서 링크를 손에 쥐는 것. Deploy App or Website입니다.
@build-web-apps로 [저장소 / 스크린샷 / 디자인 / 러프한 아이디어]를 작동하는 웹사이트로 만들어줘."@vercel로 preview를 배포하고 라이브 URL을 줘."@build-web-apps가 앱을 만들고 로컬 빌드를 확인한 뒤, @vercel이 preview 배포 + 공유 가능한 라이브 URL을 만들어줍니다. 빌드가 실패하면? 로그를 읽고 스스로 고쳐서 다시 배포합니다. 콘셉트에서 공유 링크까지, 배포 설정 씨름 없이 도달하는 거죠. (현재 문서에 명시된 배포 제공자는 Vercel입니다.)
지금까지의 use case는 따로따로가 아니라 한 스레드에서 연결됩니다. 신규 "가격 페이지"를 만든다고 해봅시다.
@slack·@linear에서 "엔터프라이즈 요금제를 강조해달라"는 피드백을 모아 ImageGen으로 목업 3안 생성. 팀이 1안 선택.@figma MCP로 토큰·variant를 끌어와 코드로 구현. $playwright-interactive가 모바일·데스크톱에서 레퍼런스와 대조하며 반복.@vercel로 preview 배포. 라이브 URL을 Slack에 공유하고 "모바일 여백 비좁다"는 댓글에 맞춰 다시 한 번 고쳐 재배포.피드백 수집 → 목업 → Figma 변환 → 비주얼 검증 → 미세 수정 → 배포가 창을 옮겨 다니지 않고 하나의 대화로 흐릅니다. 이게 플러그인 생태계 + 비주얼 루프가 합쳐졌을 때의 실제 모습입니다.
마지막은 가장 재밌는 영역, Create Browser-Based Games입니다. 게임은 "재미있는가"를 코드만 봐서는 알 수 없으니, 비주얼 루프가 더더욱 중요해집니다.
작업은 계획서부터 시작합니다. /plan 슬래시 명령으로 PLAN.md를 작성하죠 — 플레이어 목표, 메인 루프, 조작, 승패 조건, 진행 단계, 비주얼 방향, 기술 스택, 마일스톤.
$playwright-interactive, $imagegen, $openai-docs를 써서 이 저장소에 브라우저 게임을 계획하고 만들어줘."PLAN.md를 구현하고, 작업 내용은 .logs/ 아래에 기록할 것."여기서 여러 도구가 맞물립니다.
$playwright-interactive — 만든 게임을 실제 브라우저에서 반복 플레이테스트$imagegen — 스프라이트·배경·UI 에셋 생성 (프롬프트를 .prompts/에 저장해 일관성 유지)AGENTS.md — 게임 타입, 빌드·테스트 명령, 로깅 규칙, 에셋 컨벤션, 쓸 스킬을 지정 → 이게 있어야 Codex가 오래 자율적으로 달릴 수 있다2편에서 배운 AGENTS.md가 여기선 "긴 자율 작업의 운영 매뉴얼" 역할을 합니다. 추천 스택으로는 Next.js + Phaser/PixiJS 같은 조합이 문서에 등장합니다.
7개 use case를 따라왔습니다. 다시 보면 두 부품이 계속 등장했습니다.
엔지니어 편(2편)이 "텍스트로 검증"(테스트·evals)했다면, 프론트엔드 편은 "눈으로 검증"합니다. 그리고 그 눈(비주얼 루프)에 Figma·Slack·Vercel 같은 도구를 MCP/플러그인으로 연결해, 디자인 → 피드백 → 구현 → 배포의 전 과정을 한 스레드에서 굴립니다.
여기서도 사람의 역할은 분명합니다. 무엇이 "맞는 화면"인지 정하는 것(레퍼런스·디자인 시스템·승인)은 여전히 사람의 몫입니다. Codex는 그 기준에 화면을 맞춰갈 뿐이죠. 디자이너는 픽셀을 미는 사람에서, 방향을 정하고 결과를 승인하는 사람으로 올라섭니다.
디자이너·프론트엔드의 하루 — 반응형 구현, Figma 변환, 초고속 미세 수정, 목업, PoC, 배포, 게임 — 를 Codex와 함께 따라가 봤습니다. 핵심은 "코드는 맞는데 화면이 안 맞아"를 비주얼 피드백 루프로 푼다는 것이었습니다.
**다음 편(4화) — 「iOS·macOS 네이티브 개발」**에서는 웹을 떠나 네이티브의 세계로 갑니다.
시리즈 인덱스
- Codex의 탄생 — 역사 · 벤치마크 · 아키텍처
- 엔지니어를 위한 Codex — 이해 · 검토 · 이전
- (현재 글) 디자이너·프론트엔드 — 비주얼 루프 · Figma · Spark
- iOS · macOS 네이티브 개발
- Knowledge Work — 파이낸스 · 오퍼레이션 · 세일즈
- Computer Use & 자동화
이 글은 코어닷투데이의 "Codex Use Cases 특집" 시리즈 3편입니다. 사실관계는 2026년 5월 기준이며, 모델 버전·기능은 빠르게 바뀔 수 있습니다. 예시 프롬프트는 OpenAI의 Codex use-cases 문서를 참고했습니다.
RELATED
