사내 SI 관리자 화면 작업 기반

키위즈 UI STUDIO

고객사 관리자 화면을, 담당자나 도구가 바뀌어도 같은 방식으로 넘기고 고칠 수 있게 만드는 사내 UI 작업 기반을 갖춘다.

현장에서 화면 하나를 끝내려면 디자이너, 퍼블리셔, 프론트 개발자, PM이 번갈아 손을 댑니다. 지금은 시안·채팅·개인 습관에 기대는 부분이 커서, 같은 일을 해도 결과물과 인수인계 방식이 제각각이기 쉽습니다. 키위즈 UI STUDIO는 그 과정을 역할별로 나누고, 샘플과 문서로 고정해 둡니다.

대상 고객사 관리자(어드민) 화면 · 디자인 → 퍼블 → 개발
퍼블(퍼블리싱)
시안을 실제로 눌러 보고 스크롤해 볼 수 있는 화면으로 만드는 작업
토큰(디자인 토큰)
여러 화면에서 같이 쓰는 색, 버튼 높이 같은 공통 기준값. 고객사마다 달라지는 부분만 변수로 빼 두어 공통 컴포넌트에 반영합니다.
한눈에 보기

화면 하나가 완성되는 흐름

누가 무엇을 만들어 누구에게 넘기는지, 기존 방식과 나란히 놓았습니다.

기존 방식

사람·채팅에 기대는 인수인계
  1. 디자이너시안 전달PDF·Figma·채팅으로 넘김. 어디까지가 확정인지 되묻게 됨
  2. 퍼블리셔비슷하게 그려서 넘김사람마다 짜는 방식이 다름
  3. 프론트 개발자화면을 처음부터 다시 짬퍼블 결과는 참고용으로만 둠↺ "시안이랑 다르다" → 같은 구간을 또 고침
PM퍼블 최신이 무엇인지, 개발에 들어갔는지를 채팅·회의로 맞춥니다. 담당자가 바뀌면 인수인계는 사람 머릿속에만 남습니다.

키위즈 UI STUDIO

가이드·샘플에 정해진 순서
  1. 1 디자인디자이너공통 룰을 기준으로 시안고객사마다 다른 색·높이만 맞춤
  2. 2 공통 기준 반영퍼블·프론트달라지는 값을 토큰으로UI Studio에서 값을 바꿔 가며 확인
  3. 3 퍼블 시안퍼블리셔같은 뼈대로 시안 화면서버 없이 화면부터 맞춤
  4. 4 현황 기록퍼블리셔Workbench에 완료·시안 버전개발이 이어받을 시점이 분명해짐
  5. 5 개발프론트 개발자시안을 출발점으로 개발API 연동·업무 로직을 붙이고 적용한 퍼블 버전을 기록
PMWorkbench 현황으로 퍼블 최신과 프론트 반영 여부를 같은 줄에서 봅니다. 내부·외부 인력이 섞여도 같은 그림을 봅니다.

UI를 통째로 다시 만드는 비중은 줄지만, 개발 작업 자체가 없어지는 것은 아닙니다.

역할별로

누구의 수고가 어떻게 줄어드나

디자이너

공통 UI를 처음부터 따로 설계하지 않습니다.

개발·퍼블이 제공하는 공통 룰을 기준으로 시안을 잡고, 고객사마다 달라지는 색·높이 정도만 맞춥니다.

기대 효과 Figma에 공통 컴포넌트를 미리 두어 중복 디자인 줄이기

퍼블리셔

"대충 비슷하게" 그린 뒤 넘기지 않습니다.

개발이 그대로 이어받을 수 있는 시안 화면을 같은 뼈대로 만듭니다.

프론트 개발자

시안을 백지에서 다시 그리지 않습니다.

퍼블 결과물을 바탕으로 API 연동·업무 로직을 이어 갑니다. AI를 쓰기 어려운 고객사·내부 환경에서도 사람이 읽고 고칠 수 있는 구조를 전제로 둡니다.

PM

현황을 채팅에만 기대지 않습니다.

"퍼블이 어디까지 됐는지", "프론트가 어느 시안 버전을 반영했는지"를 Workbench 현황으로 같이 맞춰 봅니다.

특장점 6가지 · 실제 화면 샘플

무엇이 달라지나

샘플은 저장소의 현재 판을 실행해 그대로 캡처한 화면입니다. 화면을 누르면 크게 볼 수 있습니다.

①

역할이 바뀌어도, 누가 무엇을 넘기는지가 분명하다

지금
시안을 PDF·Figma·채팅으로만 넘기면, 개발 쪽에서 "어디까지가 확정인지"를 자꾸 되묻게 됩니다. 담당자가 바뀌면 인수인계도 사람 머릿속에만 남는 경우가 많습니다.
바꾸면
디자인 → 공통 기준 반영 → 퍼블 시안 → 현황 기록 → 개발 순서가 가이드와 샘플에 맞춰져 있습니다.
근거
업무 흐름·역할별 가이드·샘플 화면이 저장소에 정본으로 있습니다.
샘플

이 순서는 위의 화면 하나가 완성되는 흐름 그림 그대로입니다. 단계마다 맡는 사람과 넘기는 결과물이 정해져 있습니다.

②

공통은 룰로 두고, 고객사마다 다른 것만 맞춰 간다

지금
고객사가 바뀔 때마다 버튼·입력창 같은 공통 UI를 디자인·개발이 각각 다시 정의하거나, 색·높이만 달라도 화면을 찾아다니며 고칩니다.
바꾸면
개발·퍼블 쪽의 기본 공통 룰을 디자인에 넘기고, 디자이너는 그 룰을 토대로 시안을 작업합니다. 고객사마다 달라지는 색·높이는 토큰으로 빼 공통 컴포넌트에 반영하고, UI Studio에서 값을 바꿔 가며 확인합니다.
근거
공통 룰·토큰·UI Studio 확인 방법이 가이드에 정리되어 있습니다.
기대 효과
Figma에도 공통 컴포넌트를 미리 만들어 두면 같은 UI를 화면마다 다시 그리는 중복을 줄일 수 있습니다. 아직 하지 않았습니다.
샘플 · 같은 화면, 토큰 값만 다르게
기본 테마(키위즈) · 화면 코드는 그대로 두고 토큰 값(주색·모서리·입력칸 높이)만 바꿔 다시 그렸습니다. 고객사 B는 설명용 가상 값입니다.
지금의 UI Studio · 오른쪽에서 높이·간격 같은 공통 값을 바꾸면 가운데 공통 컴포넌트 46개에 바로 반영돼 보입니다. 디자이너·PM도 쓸 수 있게 새로 기획 중입니다(새 기획 초안).
③

퍼블이 끝난 화면을, 개발이 처음부터 다시 그리지 않는다

지금
퍼블이 끝나도 개발이 화면을 처음부터 다시 짜는 일이 흔합니다. 나중에 "시안이랑 다르다"는 피드백으로 같은 구간을 또 고칩니다.
바꾸면
퍼블은 서버 없이 시안 화면만 먼저 맞추고, 완료와 시안 버전을 Workbench에 남깁니다. 개발은 그 시안을 출발점으로 API 연동·업무 로직을 붙이고, 어느 퍼블 버전을 반영했는지 같이 적습니다. UI를 통째로 다시 만드는 비중은 줄되, 개발 작업 자체가 없어지는 것은 아닙니다.
근거
퍼블용·개발용 영역을 나누어 두었고, 이관 절차와 Workbench(퍼블·프론트·컴포넌트)가 실제로 돌아가고 있습니다.
샘플 · Workbench 퍼블리싱 현황
화면마다 작업 상태 · 시안 버전(pub-2026.10.26 등) · 최종 수정일 · 최신 변경 · 담당자를 한 줄로 남깁니다. 개발은 여기서 "완료"된 시안 버전을 가져갑니다.
④

실무자가 열어 보고 고칠 수 있는 코드를 기준으로 둔다

지금
AI로만 빠르게 짜인 화면은 불필요한 코드가 섞이거나, 사람마다 구조가 달라 다음에 손대는 사람이 읽기 어려운 경우가 있습니다. 보안상 AI를 쓰기 어려운 고객사·사내 현장에서는 결국 개발자가 직접 수정해야 합니다.
바꾸면
"한 번에 많이 생성"보다 샘플과 같은 패턴으로 짧게 짜인 화면을 기준으로 둡니다. 가이드도 초보·신규 인력이 따라 할 수 있게 풀어 두어, AI를 쓰지 못하는 환경에서도 같은 방식으로 이어 갑니다.
근거
화면 종류별 가이드와 샘플 코드가 정본입니다. AI를 쓰는 경우에도 같은 규칙을 따르도록 안내합니다.
샘플 · 가이드에 정해 둔 화면 패턴
목록상세등록수정그리드 선택·삭제공용 팝업화면 전용 팝업

새 화면은 이 중 가장 가까운 패턴의 샘플을 따라 만듭니다. 사람이 하든 AI가 하든 같은 가이드를 봅니다.

⑤

내부·외부 작업 현황을, 채팅이 아니라 파일로 같이 본다

지금
내부와 외주·협력 인력이 섞이면 "퍼블 최신이 뭔지", "프론트에 그 버전이 들어갔는지"를 채팅·회의로 맞추느라 시간이 갑니다. 사람이 바뀔수록 PM의 현황 파악도 어려워집니다.
바꾸면
작업자는 Workbench에 화면별 퍼블 상태·시안 버전·프론트 진행·적용한 퍼블 버전·이슈를 남깁니다. 저장하면 현황 파일이 갱신되고, PM·퍼블·프론트가 그 파일을 기준으로 같은 그림을 봅니다.
근거
Workbench가 현황 파일을 바로 읽고 쓰는 전용 화면으로 동작합니다. 퍼블 최신과 프론트 반영 여부를 같은 줄에서 맞춰 볼 수 있습니다.
샘플 · Workbench 프론트 현황
적용 퍼블과 최신 퍼블이 같은 줄에 있습니다. 퍼블이 새로 바뀐 화면(샘플 목록·탭 URL)에는 "퍼블변경" 표시가 붙어, 채팅 없이도 다시 반영할 화면이 보입니다.
⑥

같은 종류의 화면은, 만들 때마다 크게 흔들리지 않는다

지금
목록·등록·수정만 해도 사람마다(또는 AI를 돌릴 때마다) 폴더와 짜는 방식이 달라집니다. AI는 당장 쓰지 않는 기능까지 넣거나 불필요한 코드를 붙이는 경우가 있어, 나중에 읽고 고치기가 더 어려워지기도 합니다.
바꾸면
실무에서 쓰는 동작을 샘플과 가이드에 맞춰 같은 방식으로 만듭니다. 예를 들면 검색 후 상세를 보고 목록으로 돌아와도 조건이 유지되는 것, 필수값을 비우면 저장 전에 알려 주는 것, 팝업을 닫을 때 내용이 먼저 사라져 높이가 줄어들지 않는 것입니다. 쓰지 않는 기능을 미리 잔뜩 넣지 않도록 막는 역할도 합니다.
근거
화면 만들기 가이드와 샘플이 있습니다.
샘플 · 검색 → 상세 → 목록으로
1 · "김"으로 검색
검색 조건이 주소에 남습니다.
2 · 상세 보기
오른쪽 위 [목록으로]를 누릅니다.
3 · 목록으로 돌아옴
검색어와 결과가 그대로입니다. 다시 검색하지 않아도 됩니다.
필수값을 비우고 [등록]
저장하기 전에 빠진 칸을 빨갛게 표시하고 무엇을 넣어야 하는지 알려 줍니다.

이 동작들은 화면마다 따로 만든 것이 아니라 공통 부품과 샘플에 들어 있습니다.

새 목록·등록 화면도 같은 샘플을 따라 만들기 때문에, 누가 만들어도 같은 동작이 나옵니다.

기존 AI 개발 방식과의 비교

AI로 바로 만드는 방식과 무엇이 다른가

비교 대상: 빈 프로젝트(또는 UI 부품만 깔아 둔 프로젝트)에서 Cursor·Claude 등으로 화면을 바로 만들어 내는 방식

같은 점

둘 다 프롬프트만으로 목록·폼·버튼이 있는 화면을 빠르게 띄울 수 있습니다. 숙련자가 AI를 잘 쓰면 첫 초안 속도도 크게 뒤지지 않을 수 있고, 요구가 바뀌면 결국 사람이 보고 고쳐야 하는 것도 같습니다.

그래서 "AI로 화면을 더 잘 만든다"보다, 만든 다음에도 누가 넘기고, 어디를 고치고, 현황을 어떻게 맞출지가 정해져 있느냐로 보는 편이 맞습니다.

질문빈 프로젝트 + AI키위즈 UI STUDIO
같은 화면을 두 사람이, 또는 AI가 두 번 만들면?폴더·버튼 위치·짜는 방식이 어긋나기 쉽습니다.샘플·가이드를 기준으로 뼈대를 맞춥니다.
결과물을 현장에서 사람이 고쳐야 하면?AI 특유의 긴 코드·중복이 섞이면 수정이 부담됩니다.실무자가 따라 할 수 있는 짧은 패턴을 전제로 둡니다. 고객사 등 AI 사용이 어려운 경우를 염두에 둡니다.
고객사 시안(색·높이)이 바뀌면?화면 파일을 찾아다니며 고치기 쉽습니다.공통은 토큰·공통 UI에서, 화면만의 배치는 해당 시안에서만 고칩니다.
퍼블이 끝나면 개발은?참고용으로만 두고 화면을 다시 구현하는 경우가 많습니다.시안을 출발점으로 API·로직 개발을 이어 가며, 적용 버전을 남깁니다.
규칙에 어긋난 코드는 언제 아나?리뷰·장애·인수인계 때 늦게 나오는 경우가 많습니다.작업할 때 가이드와 영역 규칙으로 맞추고, 현황은 Workbench에 남깁니다. 일부 기대 효과 자동으로 막는 범위는 아직 보강 중입니다.
내부·외부 진행은 어떻게 맞추나?채팅·회의·개인 메모에 흩어지기 쉽습니다.Workbench 현황으로 퍼블 최신과 프론트 반영 여부를 같이 봅니다.
갈리는 지점 1넘기는 손길이 정해져 있는가
갈리는 지점 2고칠 곳이 나뉘어 있는가
갈리는 지점 3AI 없이도 사람이 이어서 손댈 수 있는가
현재 한계와 다음

아직 안 된 것

아래 "다음"은 모두 기대 효과이며 아직 하지 않은 일입니다.

지금Figma 공통 컴포넌트는 아직 없습니다. 개발·퍼블 공통 룰을 디자인에 제공해 맞추는 단계입니다.

다음 기대 효과Figma에 공통 컴포넌트를 미리 두어 중복 디자인을 줄입니다.

지금Figma 값을 토큰에 넣는 일이 아직 손작업입니다.

다음 기대 효과넣는 과정을 더 줄입니다.

지금규칙을 어긴 코드를 막는 장치가 가이드·리뷰에 많이 기대고 있습니다.

다음 기대 효과더 일찍 걸러 주는 쪽을 보강합니다.

다음 기획 · UI Studio 초안 · 확정 전

UI Studio, 고객사 테마를 정하는 곳으로

지금 UI Studio는 개발자가 공통 값을 하나씩 바꿔 보는 도구입니다. 새 기획은 디자이너·PM이 고객사 테마를 정하고, 표준 화면으로 확인받고, 파일 하나로 넘기는 흐름을 목표로 합니다.

지금

값 하나씩 · 개발자 중심
  1. 디자이너Figma 시안 전달고객사 색·높이가 시안 안에 흩어져 있음
  2. 퍼블·프론트값을 손으로 옮김수십 개 공통 값(영문 변수 이름)에 하나씩 입력
  3. 퍼블·프론트부품 낱개로 확인버튼·입력칸을 따로따로 봄. 실제 화면 모양은 퍼블 뒤에 보임
  4. 디자이너·PM화면이 나온 뒤 확인늦게 보고 다시 고침↺ 색·높이 수정이 퍼블 뒤에 돌아옴

새 기획

손잡이 몇 개 · 표준 화면으로 확인
  1. 1 시안 받기디자이너고객사 대표 색·시안공통 룰을 기준으로 잡은 시안
  2. 2 테마 정하기디자이너·퍼블손잡이 몇 개만 고름대표 색·회색 톤·모서리·촘촘함. 세부 값은 자동으로 계산
  3. 3 표준 화면 미리보기디자이너·PM목록·등록 화면에 바로 입혀 봄글씨가 잘 읽히는지 자동 점검
  4. 4 확인받기PM·고객사기본 테마와 나란히 비교퍼블 전에 모양을 확정
  5. 5 넘기기퍼블·프론트테마 파일 하나로 반영Workbench 컴포넌트 이력에 기록
컨셉 화면 · 직접 눌러 보세요설명용 모형 · 실제 기능 아님
UI Studio
  1. 1 테마 정하기
  2. 2 표준 화면 미리보기
  3. 3 확인·넘기기
고객사 OO은행 · 새 테마
캡처로 공유테마 파일 내보내기

손잡이를 바꾸면 오른쪽 표준 화면이 바로 바뀝니다. 아래 점검은 주색 버튼의 흰 글씨 대비를 실제로 계산합니다(웹 접근성 기준 4.5:1). 주황을 고르면 경고가 뜹니다.