안녕하세요, 오늘의집 프로덕트 디자이너 레이나(Lana)입니다.
디자인 작업에는 디자이너의 판단과 감각이 필요한 순간도 많지만, 실제 업무에서는 정해진 규칙 안에서 화면을 구성하는 일이 더 큰 비중을 차지하기도 합니다. 오늘의집 어드민 프로덕트가 바로 그런 영역이었어요. 사내 구성원이나 파트너사가 사용하는 어드민은 화면마다 목적은 달라도, 대부분 비슷한 구조와 패턴 위에서 만들어졌거든요.
오늘은 AI 툴로 사내 어드민 디자인 작업을 자동화하는 시스템을 만들며 겪은 시행착오를 공유하려고 합니다.
어드민 자동화를 시도했던 이유는
당시 오늘의집은 새로운 물류 서비스 론칭을 앞두고 있었고, 물류 어드민에 총 9개의 신규 페이지가 필요한 상황이었습니다. 막상 작업을 시작해 보니 어드민은 디자인 패턴이 명확해 PRD의 정책을 기존 패턴 위에 얹는 작업이 대부분이었습니다. 새롭게 디자인하기보다 정책을 매핑하는 작업에 가까웠죠. 이때 문득 이런 생각이 들었어요.
💡 "정책을 가장 잘 아는 PO가 직접 디자인까지 할 수 있다면 어떨까?"
디자인 규칙은 이미 정해져 있고, PRD*의 맥락과 정책은 누구보다 PO가 가장 잘 알고 있으니까요. 이 둘을 잘 연결해 주는 도구만 있다면 꼭 디자이너가 모든 화면을 직접 그리지 않아도 되지 않을까 싶었습니다.
*PRD(Product Requirements Document) : 제품 또는 기능에 대한 요구사항을 정의하고 규정하는 기획 문서
1차 시도 - ‘Figma Make로 어드민 템플릿 만들기’
가장 먼저 떠올린 연결 도구는 AI 기반의 Figma Make였습니다. 디자이너에게 가장 친숙한 도구이기도 하고, 프롬프트만으로 화면을 만들어주니 자연스러운 출발점이었죠. 물론 단순히 "어드민 페이지 만들어줘"라고 입력해서는 오늘의집 어드민과 똑같이 구현될 리 없었습니다. 그래서 어드민에 특화된 디자인 가이드를 먼저 구축하고, 이를 템플릿에 세팅하는 방식으로 접근했어요.
어드민 레이아웃과 유형 파악하기
디자인 가이드를 만들기 위해 먼저 물류 어드민이 어떤 구조로 되어 있는지 분해해봤어요. 페이지를 들여다 보니 유형은 크게 2가지였습니다. 데이터를 검색하고 확인하는 '조회'와 데이터를 입력하는 '등록'. 그리고 레이아웃은 3가지로 정리되더라고요.
- 유형: 조회, 등록
- 레이아웃: 사이드바, 헤더, 콘텐츠
이 패턴이 명확해진 순간, 자동화의 가능성이 보였습니다. 결국 모든 페이지가 2가지 유형 × 3가지 레이아웃의 조합 안에서 만들어지고 있다는 뜻이었으니까요.
가장 작은 단위까지 쪼개기
다음 단계는 페이지를 가장 작은 단위까지 분해하는 작업이었어요. AI가 화면을 안정적으로 생성하려면 단순히 예시 화면 몇 개를 보여주는 것만으로는 부족했거든요. 어떤 구조로 조립되어야 하는지, 위계를 명확하게 정의해줘야 했습니다.
Page → Section → Component → Foundation
예를 들어 조회 페이지는 [기본 레이아웃 + 검색 필터 + 검색 결과]라는 Section으로 나뉘고, 각 Section은 Input, Select, Button, Table 같은 Component로 구성되며, 그 컴포넌트들은 다시 Layout, Color, Typography, Spacing, Icon이라는 Foundation 위에 올라가는 식이죠.
AI가 이해할 수 있는 디자인 규칙 만들기
이렇게 잘게 나눈 구조를 바탕으로, 각 요소의 역할과 사용 기준을 하나씩 정의하기 시작했습니다.
1. 먼저, 화면의 근간이 되는 Foundation과 Component를 정리했어요. Foundation에서는 컬러, 타이포그래피, 간격, 레이아웃 같은 기본 규칙을 정의하고, Component에서는 Input, Select, Button, Table 같은 컴포넌트의 스펙과 Variant를 체계적으로 정리했습니다. 이 과정을 통해 어떤 화면이 생성되더라도 오늘의집 어드민 특유의 톤과 구조가 유지될 수 있도록 했습니다. 특히 각 요소의 용도를 구체적으로 명시해, AI가 화면의 맥락에 맞춰 디자인을 정확히 생성할 수 있도록 유도했어요.
2. 그다음으로 각 페이지 유형별 섹션 구성과 필수 컴포넌트 규칙을 정의했습니다. 예를 들어 [조회 페이지]라면 ‘검색 조건 영역’과 ‘결과 테이블’이 기본 구조로 들어가야 하고, [등록 페이지]라면 ‘입력 폼’과 ‘저장/취소 액션’이 필요합니다. 여기에 Input, Select, Radio 등 섹션별 컴포넌트 배치 기준도 함께 정립했습니다. 나아가 ‘검색 버튼을 누르면 하단에 결과 테이블이 노출’되거나, ‘Select 컴포넌트를 클릭하면 Dropdown이 열리는 것’처럼, 실제 업무 흐름에서 일어나는 기본적인 인터랙션(동작)까지 상세히 규칙화했어요.
컴포넌트를 단순히 나열하는 수준을 넘어, 구체적인 사용 기준과 조합 패턴, 사용자 행동에 따른 화면 흐름까지 명확하게 정의했어요. 그래야 AI가 화면을 막연히 ‘그리는’ 게 아니라 규칙에 맞춰 ‘조립’할 수 있다고 생각했거든요.
이렇게 정리한 가이드는 AI가 해석하기 쉬운 마크다운(Markdown) 형식으로 템플릿에 담아두었습니다. 그 결과, 프롬프트 창에 PRD 내용만 입력해도 오늘의집 어드민의 톤앤매너를 반영한 프로토타입이 자연스럽게 생성되기 시작했어요.
첫 번째 시도의 한계 - PRD만으로는 부족했던 디자인
어드민과 꽤 비슷한 화면이 생성되기는 했지만, 실제로 사용해 보니 또 다른 비효율이 보이기 시작했어요. 가장 큰 문제는 PRD를 그대로 입력하는 것만으로는 원하는 화면이 정확하게 나오지 않는다는 점이었습니다. 이 화면이 조회 유형인지 등록 유형인지 알려주는 것부터 시작해서, PRD에 있는 문장도 컴포넌트 단위로 다시 쪼개어 설명해야 했어요.
예를 들어 PRD에는 “사업자번호로 검색”이라고 적혀 있어도, AI가 알아듣게 하려면 “검색 영역에 Input 컴포넌트를 배치해 줘”처럼 디자인 언어로 한 번 더 번역해 입력해야 했습니다. 즉, PRD의 정책 언어를 디자인 패턴과 컴포넌트 언어로 다시 해석하는 과정이 필요했던 거예요.
결과의 일관성이 떨어지는 점도 아쉬웠습니다. 프롬프트 표현이 조금만 달라져도 기존 화면과 전혀 다른 디자인이 나오곤 했어요. 결국 “버튼은 Primary 컬러로 해줘”, “테이블엔 페이지네이션을 넣어줘” 같은 세부 조건을 매번 반복해서 입력해야 하는 번거로움이 있었습니다.
이 과정에서 PRD와 디자인 사이에는 생각보다 큰 간격이 있다는 걸 알게 됐습니다. 템플릿을 실제로 사용할 사람이 PO라면, 매번 PRD를 디자인 용어로 번역해 가며 프롬프트를 작성하는 방식은 현실적으로 지속하기 어렵다고 느꼈어요. 이제는 템플릿을 만드는 것에서 한 단계 더 나아가, PRD를 넣으면 일관된 디자인 결과물로 이어지는 과정 자체를 시스템화해야 한다는 레슨런을 얻었습니다. 그리고 이 과정을 구현하기 위해 새로운 AI 툴을 찾기 시작했고, 그때 선택한 도구가 바로 Claude Code였습니다.
두 번째 시도 - Claude Code 기반 디자인 생성 시스템 구축
Claude Code는 MCP를 연결할 수 있고, 반복되는 과정을 'Skill'로 정의할 수 있어서 작업 전반을 하나의 시스템으로 구축하기에 최적의 환경이었어요. 이에 따라 PRD에서 디자인까지 이어지는 파이프라인을 시스템화하는 것을 목표로 설계를 시작했습니다.
PRD를 디자인 가이드 언어로 변환하는 단계 설계하기
1차 시도에서 확인했듯, PRD 원문을 바로 프로토타입으로 변환하는 방식만으로는 원하는 결과를 안정적으로 얻기 어려웠어요. PRD에는 정책과 요구사항이 담겨 있지만, AI가 실제 화면을 생성하려면 이를 디자인 패턴과 컴포넌트 기준으로 다시 해석하는 과정이 필요했기 때문입니다.
이때 변환 기준은 크게 세 가지로 나누어 설계했어요.
1. 페이지 유형 및 레이아웃 매칭
가장 먼저 이 화면이 ‘조회’ 유형인지, ‘등록’ 유형인지 판단하도록 했습니다. 유형에 따라 기본 레이아웃과 필수 구성 요소가 달라지기 때문이에요.
2. 섹션 및 컴포넌트 매칭
PRD에 적힌 기획 용어를 어떤 디자인 컴포넌트로 변환할지에 대한 명확한 매핑 원칙도 세웠습니다. 예를 들어 PRD에 명시된 글자 수가 40자 이상이면 Input이 아닌 Textarea 컴포넌트로, 읽기만 가능하다면 Disabled 상태의 컴포넌트가 매칭되도록요.
이렇게 PRD의 정책 언어와 디자인 컴포넌트를 연결해 두어야, 프롬프트 창에 “이건 Input으로 만들어줘”, “이건 Select로 만들어줘” 같은 지시를 매번 반복하지 않아도 된다고 봤습니다.
3. 불명확한 부분은 디자인 전에 사용자에게 보고
PRD에 명시되지 않은 내용을 AI가 자의적으로 판단해 채워 넣지 않도록 제어하는 것도 중요했어요. 그래서 디자인을 생성하기 전에 확인이 필요한 내용을 먼저 사용자에게 보고하도록 설계했습니다.
페이지 유형별 케이스까지 함께 생성하기
마지막으로 기본 화면을 포함해 검토에 필요한 세부 케이스도 함께 생성되도록 했습니다. 실제 어드민은 기본 상태만으로는 충분히 검토하기 어렵기 때문인데요, 예를 들어 조회 페이지라면 검색 결과가 있는 상태뿐만 아니라 Filtered, Empty 상태가 필요하고, 등록 페이지라면 필수값 누락이나 형식 오류 같은 에러 케이스까지 검토할 수 있어야 했습니다.
그래서 Skill에 페이지 유형별로 필요한 케이스를 함께 생성하도록 정의했습니다. 생성된 디자인은 외부 URL로 바로 확인할 수 있어서, 피그마 파일을 열거나 별도 공유 과정을 거치지 않아도 모두가 간편하게 검토할 수 있었죠.
결과 - 정책을 만드는 사람이 디자인까지 할 수 있는 환경 구축
디자인 자동화 시스템으로 9개 신규 페이지의 디자인 작업 기간은 예상했던 20일에서 5일로 단축됐습니다. PRD만으로 동작하는 프로토타입을 빠르게 생성할 수 있었고, 화면 흐름까지 함께 확인할 수 있다 보니 개발자와의 커뮤니케이션 비용도 눈에 띄게 줄어들었어요.
무엇보다 가장 큰 변화는, 이 시스템이 실제로 PO의 작업 흐름 안에 자연스럽게 녹아들기 시작했다는 점이었습니다. 이제는 PO가 PRD URL만 입력하면 프로토타입이 생성되고, 간단한 수정도 프롬프트로 직접 반영할 수 있게 되었죠. 디자이너가 PRD를 해석해 화면으로 옮기기 전에, 정책을 가장 잘 아는 기획자가 직접 화면 초안을 만들 수 있는 환경이 생긴 거예요.
제가 만든 디자인 가이드도 물류 어드민에만 머물지 않았어요. 다른 PO분들도 각자 담당하는 어드민 화면을 만들 때 이 가이드를 활용하기 시작했고, 자신의 PRD를 기반으로 어드민 패턴에 맞는 화면을 직접 생성해 보기 시작했어요.
마치며
이번 프로젝트를 통해 가장 크게 느낀 건 반복되는 디자인 작업일수록 화면을 하나씩 잘 만드는 것만큼이나 화면이 만들어지는 방식을 설계하는 일이 중요하다는 점이었어요.
어드민 화면은 페이지마다 담기는 정책과 데이터는 달라도 그 안에서 반복되는 구조와 패턴은 꽤 명확했습니다. 그래서 매번 새로운 화면을 처음부터 그리는 대신 PRD를 어떻게 읽고 어떤 페이지 유형으로 나눌지, 또 어떤 컴포넌트와 패턴으로 조합할지에 대한 기준을 세우는 것이 훨씬 효과적이었어요.
결국 이번 시스템은 디자이너가 모든 화면을 직접 그리지 않아도 디자이너가 만든 기준 안에서 다른 직군도 화면을 만들 수 있는 가능성을 확인한 작업이었습니다.
앞으로는 이 시도를 물류 어드민에만 그치지 않고 사내의 다양한 어드민 영역으로 확장해 보려 해요. 각 어드민에 흩어져 있는 구조와 패턴을 하나의 기준으로 정리하고 통합해 오늘의집의 어떤 어드민이든 PRD만 있으면 디자인까지 자연스럽게 이어지는 환경을 만들어 가고자 합니다.
