Chapter 18. UI 프로토타이핑
좋은 제품은 머리로만 설계되지 않는다. 눈으로 보고, 눌러 보고, 어색함을 느끼고, 다시 고치면서 선명해진다. 특히 Codex를 쓰는 시대에는 이 과정이 훨씬 빨라진다. 예전에는 "기획 → 디자이너 시안 → 개발 착수 → 첫 화면 확인"까지 며칠이 걸렸다면, 이제는 같은 날 안에 여러 화면을 동시에 만들어 보고 팀 피드백까지 받을 수 있다.
이 장의 핵심은 단순하다. UI는 빨리 보여줘야 한다. 그래야 팀이 의견을 내고, 사용자도 반응하고, 제품의 방향도 빨리 또렷해진다. Codex의 병렬 에이전트, 인앱 브라우저, 이미지 생성 기능은 바로 이 "보이는 속도"를 끌어올리는 도구다.12
PRD 다음에는 왜 바로 코드가 아니라 프로토타입인가
앞 장에서 PRD를 만들었다면, 이제 곧바로 완성형 구현으로 뛰어들고 싶어질 수 있다. 하지만 대부분의 제품은 이 지점에서 한 번 삐끗한다. 요구사항은 맞는데 화면이 별로이거나, 화면은 예쁜데 흐름이 불편하거나, 팀마다 같은 문장을 다르게 해석하는 일이 벌어진다.
프로토타입은 이 오해를 가장 싸게 줄여준다. 텍스트로는 모호했던 문장이 화면으로 바뀌는 순간, 문제는 놀랄 만큼 잘 보인다. "탭이 너무 많다", "결제 버튼이 안 보여서 불안하다", "신규 사용자는 여기서 막히겠다" 같은 말이 바로 나온다. 이 피드백은 코드가 완성된 뒤보다, 시안 단계에서 받을수록 값이 크다.
특히 Codex를 쓸 때는 프로토타입이 더 중요하다. 에이전트는 요구를 빠르게 구현하지만, 무엇을 구현해야 하는지까지 완벽히 알아서 판단해 주지는 않는다. 결국 먼저 선명해져야 하는 것은 화면이다. 화면이 선명해지면 이후 구현, 테스트, 배포까지 속도가 붙는다.
Codex식 UI 프로토타이핑의 기본 원리
Codex로 UI를 빠르게 만드는 핵심은 세 가지를 한 번에 굴리는 것이다.
병렬 에이전트로 여러 시안을 동시에 만든다.
인앱 브라우저로 결과를 바로 눈으로 확인한다.
이미지 생성으로 빈칸을 메우지 말고, 실제 같은 화면을 만든다.
이 세 가지가 연결되면 작업 방식이 바뀐다. 한 명이 한 시안을 오래 다듬는 방식이 아니라, 여러 개를 짧게 만들고 빨리 버리는 방식이 된다. 이게 중요하다. 프로토타이핑 단계에서는 "정답을 찾는 능력"보다 "틀린 방향을 빨리 버리는 능력"이 더 생산적이기 때문이다.
먼저 정할 것: 무엇을 병렬로 만들고, 무엇을 순차로 만들까
병렬 작업은 무조건 많을수록 좋은 게 아니다. 서로 의존성이 없는 화면이나 흐름을 나눌 때만 강력하다. Codex의 병렬 에이전트나 서브에이전트는 독립 작업을 동시에 실행하고 결과를 모으는 데 특히 유리하다.13
예를 들어 Next.js + Supabase로 "동네 모임 슈퍼앱"을 만든다고 해보자. 홈 피드, 모임 상세, 채팅 목록, 프로필 편집은 각각 다른 파일과 컴포넌트에 주로 닿는다. 이런 경우엔 병렬화가 잘 된다. 반대로 같은 레이아웃 파일이나 같은 디자인 토큰 파일을 여러 에이전트가 동시에 만지게 하면, 프로토타입 속도는 빨라지는 게 아니라 충돌 정리 시간으로 녹아버린다.3
실무에서는 이렇게 나누면 편하다.
탐색형 작업: 기존 디자인 시스템, 현재 컴포넌트 구조, 라우팅 구조를 파악하는 에이전트
시안 생성 작업: 같은 요구를 서로 다른 톤으로 구현하는 에이전트들
검증 작업: 반응형 깨짐, 접근성, 버튼 흐름, 텍스트 밀도를 확인하는 에이전트
이렇게 역할을 나누면 메인 스레드는 훨씬 깔끔해진다. 내가 해야 할 일은 코드를 다 쓰는 것이 아니라, 방향을 고르고 비교하고 합치는 일이 된다.
병렬 에이전트로 시안 3개를 한 번에 뽑는 법
가장 쉬운 시작은 "한 화면, 세 가지 방향"이다. 예를 들어 PRD에서 핵심 화면이 '홈 대시보드'라면, 에이전트마다 서로 다른 목표를 준다.
첫 번째 에이전트는 정보 밀도가 높은 운영형 대시보드를 맡긴다. 관리자나 파워 유저가 좋아할 만한 구조다. 두 번째 에이전트는 초보 사용자 친화형 화면을 맡긴다. 카드 수를 줄이고, 설명 문구를 늘리고, 첫 행동 버튼을 크게 둔다. 세 번째 에이전트는 모바일 우선 구조를 맡긴다. 한국 사용자는 모바일에서 먼저 보는 경우가 많기 때문에 의외로 이 안이 최종안이 되는 경우도 많다.
프롬프트는 길게 쓰는 것보다 경계를 분명히 주는 게 중요하다.
시안 A: 정보 밀도 높게, 데스크톱 우선, 관리 지표 중심
시안 B: 온보딩 친화적으로, 첫 행동 유도 중심, 카드 수 최소화
시안 C: 모바일 우선, 하단 탭 중심, 엄지 손가락 동선 고려
이때 세 에이전트가 같은 파일을 덮어쓰지 않도록 작업 범위를 분리해야 한다. 워크트리나 독립 스레드 단위로 나눠서 각자 다른 브랜치나 격리된 작업 공간에서 만들게 하면 충돌이 크게 줄어든다.34
여기서 중요한 팁이 하나 있다. 세 개 시안을 뽑을 때는 "최종안을 맞혀라"가 아니라 "차이를 극단적으로 벌려라"라고 지시하는 편이 낫다. 너무 비슷한 세 개를 받으면 비교가 안 된다. 프로토타입 단계에서는 약간 과장된 차이가 오히려 도움이 된다.
예제: Next.js + Supabase로 만드는 모임 앱 홈 화면
한국 개발자가 실제로 만들 법한 예제로 가보자. 가정은 이렇다. 사용자는 동네 러닝 모임, 독서 모임, 사이드 프로젝트 모임을 찾고 참여한다. 홈 화면의 목표는 세 가지다. 오늘의 추천 모임을 보여주고, 내가 참여 중인 모임을 빠르게 들어가게 하고, 새 모임을 쉽게 열 수 있게 하는 것이다.
이 요구를 Codex에 바로 던지면 그럴듯한 화면 하나는 금방 나온다. 하지만 그 하나만 보고 판단하면, 팀은 대체로 첫 안에 끌려가게 된다. 그래서 처음부터 비교 가능한 세 안을 만든다.
A안은 커뮤니티 앱 느낌으로 간다. 상단 검색, 카테고리 칩, 추천 카드, 참여 중인 모임 섹션이 순서대로 나온다. B안은 슈퍼앱 느낌으로 간다. 상단에는 오늘의 액션이 하나 크게 있고, 아래에는 모임, 채팅, 일정, 결제 같은 핵심 진입점이 타일 형태로 놓인다. C안은 콘텐츠 피드형으로 간다. 추천 모임과 친구 활동이 섞인 타임라인에 가깝다.
이 세 안을 병렬로 만든 뒤, 인앱 브라우저에서 바로 띄워 보면 말보다 빠르게 판단할 수 있다. "우리 서비스는 생각보다 피드형이 아니라 작업형이네", "채팅보다 모임 개설이 더 중요하네", "카드가 너무 많아서 정신없네" 같은 결론이 즉시 나온다. 바로 이 순간이 Codex UI 프로토타이핑의 맛이다.
인앱 브라우저가 중요한 이유
프론트엔드 작업은 코드보다 눈이 먼저 판단한다. JSX가 예뻐 보여도 실제 브라우저에서 보면 간격이 어색하고, 강조 색이 튀고, 버튼 위계가 뒤집혀 있는 일이 흔하다. 그래서 프로토타이핑에서는 "만들기"보다 "바로 보기"가 중요하다.
Codex 앱의 인앱 브라우저는 이 확인 루프를 짧게 만든다. 화면을 띄워 보고, 어색한 부분에 대해 바로 코멘트를 남기고, 다시 수정하게 하는 흐름이 한 공간 안에서 이어진다.2 브라우저와 채팅창과 코드 리뷰가 계속 왔다 갔다 하면 생각보다 피로가 크다. 반면 같은 앱 안에서 보고 말하고 고치는 루프가 이어지면, UI 작업 속도가 확실히 빨라진다.
실제 사용 팁은 간단하다. 처음부터 완성도를 보지 말고 아래 네 가지만 먼저 본다.
첫 화면 3초 인상: 무엇을 하는 서비스인지 바로 보이는가
첫 행동 유도: 사용자가 어디를 눌러야 할지 망설이지 않는가
시선 흐름: 제목, 설명, 버튼 순서가 자연스러운가
모바일 압축도: 좁은 화면에서 정보가 숨 막히지 않는가
이 네 가지만 체크해도 시안의 절반은 걸러진다. 디테일은 그다음이다.
인앱 브라우저에서 피드백하는 법
좋지 않은 피드백은 "좀 별로예요"다. 좋은 피드백은 "왜 별로인지"가 바로 수정 지시로 바뀌는 피드백이다.
예를 들어 이렇게 말하면 좋다.
상단 히어로 영역이 너무 커서 추천 모임이 첫 화면 아래로 밀린다. 높이를 줄이고 추천 카드 하나를 위로 올려라.
카드 안에 정보가 세 줄씩 들어가서 스캔이 어렵다. 제목, 날짜, 위치만 남기고 나머지는 상세로 보내라.
하단 탭 아이콘은 좋은데 활성 상태가 약하다. 색 대비를 높이고 라벨 굵기를 올려라.
이런 식의 피드백은 바로 반영 가능하다. 반면 "더 세련되게", "좀 트렌디하게" 같은 표현은 에이전트도 사람도 해석이 갈린다.
프로토타입 단계에서 중요한 것은 취향 표현이 아니라 관찰 가능한 문제를 말하는 습관이다. 인앱 브라우저는 이 관찰을 빠르게 축적하는 데 아주 유리하다.
이미지 생성은 왜 UI 프로토타이핑에서 중요한가
많은 개발자가 이미지 생성 기능을 "멋진 그림 만드는 옵션" 정도로 생각한다. 하지만 실무에서는 전혀 다르다. 이미지 생성은 프로토타입의 빈칸을 채워서, 화면을 훨씬 실제 서비스처럼 보이게 만드는 도구다. OpenAI는 Codex 안에서 gpt-image-1.5로 이미지 생성과 반복 수정을 지원하며, 이를 프런트엔드 디자인과 목업 제작에 바로 연결하고 있다.25
예를 들어 모임 앱의 홈 화면에 추천 배너가 있다고 하자. 여기에 회색 박스만 들어가 있으면 팀은 레이아웃만 본다. 하지만 실제 톤의 배너 이미지가 들어가면, 브랜드 느낌과 사용 맥락까지 함께 판단할 수 있다. 게임 앱이라면 아이콘과 배경 아트가, 쇼핑 앱이라면 상품 더미 이미지가, SaaS라면 일러스트와 빈 상태 화면이 제품 인상을 결정한다.
즉 이미지 생성은 장식이 아니라 맥락이다. 이 맥락이 있어야 팀 피드백도 훨씬 구체적이 된다.
어떤 이미지를 생성해야 프로토타입이 살아나는가
처음부터 모든 이미지를 만들 필요는 없다. 프로토타입을 빨리 선명하게 만드는 데 가장 효과적인 것부터 생성하면 된다.
히어로 배너나 대표 비주얼
빈 상태 화면에 들어갈 일러스트
카드 목록용 더미 썸네일
온보딩 화면 배경이나 브랜드 무드 이미지
간단한 게임 에셋이나 아이콘 스타일 샘플
예를 들어 "러닝 모임 추천" 카드가 많은 앱이라면, 실제 도시 공원에서 함께 뛰는 장면을 따뜻한 톤으로 생성해 넣을 수 있다. 또는 "스터디 모집" 서비스라면 노트북, 메모, 커피잔이 있는 한국형 카페 분위기 이미지를 넣어도 좋다. 이런 작은 차이가 팀에게 "이 서비스가 어떤 감정으로 보이길 원하는가"를 즉시 전달한다.
이미지 생성 프롬프트는 예쁘게보다 쓸모 있게 써라
이미지 생성에서 흔한 실수는 너무 추상적으로 요청하는 것이다. "감성적인 배너 만들어줘"라고 하면 결과가 멋있을 수는 있어도, 제품 화면에는 안 어울릴 확률이 높다.
대신 UI 맥락을 포함해서 요청해야 한다. 예를 들어 이렇게 구체화할 수 있다.
"동네 러닝 모임 앱 홈 화면 상단 배너용 이미지. 20~30대 한국 사용자 타깃. 이른 아침 한강 공원에서 4명이 가볍게 조깅하는 장면. 밝고 건강한 분위기, 과한 광고 느낌은 피하고, 상단 왼쪽에 텍스트를 올릴 여백 필요, 모바일 세로 비율에도 잘려도 자연스럽게."
이런 프롬프트는 단순히 예쁜 이미지가 아니라, 실제 UI에 넣을 수 있는 이미지를 만든다. Codex 안에서 이미지 생성과 반복 수정을 같은 흐름으로 돌릴 수 있기 때문에, 결과물을 보고 바로 "여백을 더 주세요", "사람 수를 줄여 주세요", "색을 더 차분하게"처럼 짧게 재지시하기도 쉽다.25
이미지와 코드, 둘 중 무엇을 먼저 고칠까
답은 상황에 따라 다르지만, 원칙은 하나다. 구조 문제는 코드로, 분위기 문제는 이미지로 먼저 해결한다.
버튼이 안 보이는 문제, 정보 위계가 이상한 문제, 카드가 너무 많은 문제는 레이아웃과 컴포넌트 구조를 고쳐야 한다. 반면 화면이 삭막하거나, 브랜드 톤이 안 느껴지거나, 사용 맥락이 잘 안 전달되는 문제는 이미지나 카피를 먼저 바꾸는 편이 빠르다.
이 둘을 구분하지 않으면 괜히 CSS만 계속 만지거나, 반대로 이미지에만 집착하게 된다. 프로토타이핑은 미학보다 의사결정 속도가 중요하다. 무엇을 바꿔야 판단이 빨라지는지를 먼저 보자.
스크린샷 기반 이터레이션 루프 만들기
Codex는 스크린샷을 문맥으로 함께 읽는 흐름이 강하다. CLI에서도 이미지 첨부로 디자인 목업이나 현재 화면 스크린샷을 함께 보내며 작업할 수 있고, 앱 쪽에서는 시각적 확인과 수정 루프가 더 자연스럽다.67
이 방식은 특히 "거의 맞는데 뭔가 이상한" 프런트엔드 작업에 강하다. 실전 루프는 보통 이렇다.
먼저 현재 화면을 캡처한다. 그다음 목표 시안이나 레퍼런스 이미지를 함께 붙인다. 그리고 두 장을 비교하게 한다. 예를 들어 "첫 번째는 원하는 디자인, 두 번째는 현재 구현이다. 차이를 설명하고 Tailwind 클래스 기준으로 수정해라"처럼 지시하면 된다.7
이 루프가 좋은 이유는 말로 설명하기 어려운 간격, 밀도, 정렬 문제를 이미지로 바로 전달할 수 있기 때문이다. 프런트엔드는 가끔 코드보다 스크린샷이 더 정확한 요구사항이다.
병렬 에이전트 + 인앱 브라우저 + 이미지 생성, 셋을 연결한 실전 흐름
이제 세 기능을 한 흐름으로 묶어 보자. 예시는 "중고 거래 + 동네 모임 + 채팅"이 섞인 슈퍼앱 클론이다.
먼저 메인 에이전트에게 목표를 설명한다. "신규 사용자가 홈에 들어왔을 때 5초 안에 서비스 성격을 이해하고, 중고 거래와 모임 중 하나를 바로 시작할 수 있어야 한다." 이 한 문장이 기준점이다.
그다음 세 개의 병렬 작업을 시작한다. 하나는 거래 중심 홈, 하나는 커뮤니티 중심 홈, 하나는 슈퍼앱 허브형 홈이다. 각 에이전트는 서로 다른 워크트리나 격리된 작업 스레드에서 작업하게 한다.14
동시에 이미지 생성 쪽에는 각 안에 맞는 대표 비주얼을 맡긴다. 거래 중심 홈에는 실사용 상품 사진 느낌의 카드 썸네일 세트, 커뮤니티 중심 홈에는 동네 사람들의 활동 장면, 슈퍼앱 허브형 홈에는 아이콘과 색상 톤에 맞는 간단한 배너를 만든다.25
세 안이 나오면 인앱 브라우저로 각각 띄운다. 여기서 팀원 둘만 붙어도 좋다. 한 명은 "무엇이 먼저 보이는가"를 말하고, 다른 한 명은 "무엇을 누르게 되는가"를 말한다. 이 두 피드백만 있어도 안이 빠르게 정리된다.
이후 가장 반응이 좋은 안 하나를 고르고, 나머지 두 안의 장점만 섞는다. 예를 들면 A안의 검색 구조, B안의 카드 밀도, C안의 하단 탭 구조를 합치는 식이다. 프로토타이핑의 목적은 승자를 뽑는 것이 아니라, 좋은 부분을 빠르게 모으는 것이다.
사용자 피드백은 완성본이 아니라 클릭 가능한 초안에서 받는다
실무에서 자주 나오는 실수는 "조금만 더 다듬고 보여주자"다. 그러다 보면 다듬는 시간이 피드백 시간보다 길어진다. 프로토타입은 완성도가 아니라 반응 속도로 평가해야 한다.
가장 좋은 시점은 클릭이 가능한 최소 흐름이 나왔을 때다. 홈 → 상세 → 행동 버튼 정도만 이어져도 충분하다. 이때 실제 사용자나 팀원에게 물어볼 질문도 구체적이어야 한다.
첫 화면에서 이 서비스가 무엇을 하는지 이해됐나요?
지금 가장 먼저 누르고 싶은 버튼은 무엇인가요?
뭔가 불안하거나 믿음이 안 가는 지점이 있나요?
정보가 너무 많거나 적다고 느껴지나요?
질문이 구체적이면 답도 쓸모 있어진다. "예쁘다"보다 "모임 개설 버튼이 안 보여서 헤맸다"가 훨씬 값지다.
한 번에 여러 시안을 만들 때 생기는 함정
병렬 에이전트는 강력하지만, 방심하면 바로 산만해진다. 대표적인 함정은 세 가지다.
첫째, 너무 많은 시안을 만든다. 다섯 개, 여섯 개를 한 번에 만들면 생산성보다 비교 피로가 더 커진다. 실제로는 세 개면 충분한 경우가 많다. 둘째, 각 시안의 차이가 너무 작다. 그러면 비교가 아니라 숨은그림찾기가 된다. 셋째, 같은 파일을 여러 에이전트가 동시에 고친다. 이건 병렬화가 아니라 충돌 예약이다.34
프로토타이핑 단계의 병렬화는 아이디어 다양성을 얻기 위한 것이지, 한 화면을 여러 명이 동시에 붙잡는 방식이 아니다. 파일 소유권과 목표 차이를 분명히 줄수록 결과가 좋아진다.
디자인 시스템이 없어도 시작할 수 있을까
물론 가능하다. 다만 원칙 몇 개는 먼저 정하는 편이 좋다. 예를 들어 버튼 모서리 반경, 기본 간격 단위, 제목 크기 체계, 주요 색상 두세 개 정도는 미리 정해 두자. 이 정도만 있어도 에이전트가 시안을 만들 때 훨씬 덜 흔들린다.
이미 디자인 시스템이 있다면 더 좋다. 기존 컴포넌트와 토큰을 읽게 하고, "새 UI를 만들되 현재 Button, Card, Badge 컴포넌트를 우선 사용하라"고 지시하면 된다. 반대로 시스템이 전혀 없을 때는 프로토타입 단계에서 작은 규칙부터 만드는 것이 좋다. 그래야 이후 구현으로 넘어갈 때 갈아엎는 비용이 줄어든다.
한국 팀에서 특히 잘 먹히는 프로토타이핑 습관
한국 실무에서는 회의가 빠르고, 의견도 빠르게 모인다. 이 장점은 프로토타입이 눈에 보일 때 극대화된다. 그래서 다음 습관이 잘 맞는다.
회의 30분 전까지 최소 2개 시안을 띄워둔다.
말로 설명하지 말고 먼저 1분 동안 화면을 보게 한다.
피드백은 "좋다/별로다" 대신 "먼저 보이는 것/막히는 것"으로 받는다.
회의 끝나기 전에 다음 수정 방향을 바로 Codex에 넘긴다.
이 방식은 디자이너가 없는 팀, 혹은 디자이너 리소스가 부족한 스타트업에서 특히 강하다. 중요한 것은 디자인 전문가인 척하는 것이 아니라, 제품 판단 속도를 높이는 것이다.
어디까지가 프로토타입이고, 어디서부터 구현인가
프로토타입은 완성된 코드가 아니라, 좋은 결정을 만드는 코드다. 그래서 다음 조건이 충족되면 프로토타입 단계는 거의 끝났다고 봐도 된다.
핵심 화면의 정보 위계가 안정되었다.
첫 행동 흐름이 자연스럽다.
모바일과 데스크톱에서 모두 큰 위화감이 없다.
팀 내부에서 방향성 합의가 끝났다.
사용자 반응에서 치명적 거부감이 없다.
이 상태가 되면 그다음부터는 미세 조정보다 구현 안정화로 넘어가야 한다. 다시 말해, 이제부터는 예쁜 시안 경쟁보다 실제 데이터 연결, 상태 관리, 접근성, 테스트가 중요해진다. 다음 장에서 다룰 인증과 데이터베이스 연동이 바로 그 단계다.
이 장의 워크플로를 한 문장으로 정리하면
PRD를 읽고 한 안을 정교하게 만드는 대신, 여러 안을 병렬로 만들고, 인앱 브라우저로 바로 비교하고, 이미지 생성으로 맥락을 채우고, 사용자 반응이 좋은 방향만 남겨라.
UI 프로토타이핑에서 가장 비싼 비용은 코드를 다시 쓰는 비용이 아니다. 잘못된 방향을 너무 늦게 발견하는 비용이다. Codex는 그 발견 시점을 앞당겨 준다. 그러니 완벽한 첫 화면을 만들려고 하지 말자. 빨리 보이는 화면을 만들고, 빨리 틀리고, 빨리 더 나은 방향으로 옮겨 가자.
참고
1Subagents - Codex | OpenAI Developers
2Codex for (almost) everything - OpenAI
3Running Multiple Codex Agent Instances: Parallel Orchestration Patterns
4Orchestrating Multiple Parallel Agents | Developer Toolkit
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.