---
title: "🧩 260530-스튜디오-UI매핑-프롬프트모드"
notion_id: "37022962086881a0950ceec321d68582"
notion_url: "https://app.notion.com/p/37022962086881a0950ceec321d68582"
category: "workreport"
parent: "Claude Code 작업보고"
updated: "2026-05-30"
priority: "High"
purpose: "스튜디오 확장(UI 구조 탐색기·시스템ID/별칭·위치좌표·AI 작업지시 생성기) 세션 — 155턴 대화 raw 정리본 + 157개 UI 요소 매핑"
read_when: ["디자인시스템","UI작업"]
---

> 📄 **무손실 정본(155턴 전문)은 레포에 보관됨** → [GitHub 정본 파일 열기](https://github.com/ccy-hansbridge/dallog/blob/main/docs/sessions/260530-%EC%8A%A4%ED%8A%9C%EB%94%94%EC%98%A4-UI%EB%A7%A4%ED%95%91-%ED%94%84%EB%A1%AC%ED%94%84%ED%8A%B8%EB%AA%A8%EB%93%9C_%EB%8C%80%ED%99%94raw.md)
> 노션 MCP는 파일을 직접 업로드하지 못해, 아래 본문은 가독성용으로 정리한 버전이다. **한 글자도 빠짐없는 100% 원문**이 필요하면 위 GitHub 파일을 받아 이 노션 페이지에 드래그&드롭하면 노션이 마크다운을 그대로 가져온다(기본 마크다운 import). 파일 경로: `docs/sessions/260530-스튜디오-UI매핑-프롬프트모드_대화raw.md`

> 🧩 본 페이지는 스튜디오 확장(UI 구조 탐색기·시스템ID/별칭·위치좌표·AI 작업지시 생성기) 작업 세션의 **전체 대화 raw**이다(사용자 프롬프트 + Claude 응답 전문). 툴 호출 JSON 원문(수 MB)은 가독성·크기 한계로 제외하고 사람이 읽는 대화만 추출했다(155턴 · 약 72KB). 100% 무손실 원본은 로컬 세션 트랜스크립트(.jsonl)다.

## 세션 개요

- **기간**: 2026.05.29~31 (단일 연속 세션)
- **흐름**: 직접 UI 편집 툴 브레인스토밍 → 스튜디오(토큰 편집) 신설 → 인라인 스타일 전면 마이그레이션(디자인 시스템 정립) → 스튜디오 UI 매핑·프롬프트모드
- **산출 PR**: #11(인라인→토큰 전면 마이그레이션) · #12(미리보기 고정 + 직접 적용·커밋·푸시) · #13(UI 구조 탐색기 + AI 작업지시 생성기) — 모두 main 머지

## 🛠 작업 요약 (구현 결과)

### UI 구조·작업지시 모드 신설 (PR #13)

- **범용 UI 정의 프레임워크** (`src/lib/uiCatalog.ts`): `UiElementDef`(시스템ID·사용자별칭·selector·토큰·파일·수정유형·레이아웃). 달록 전용 하드코딩이 아니라 (UI요소→트리→별칭→위치→AI지시) 공통 프레임워크 — **타 프로젝트는 CATALOG만 교체해 재사용**(팩토핀·한스브릿지 웹)
- **카탈로그**: 시드 28 + 멀티에이전트 워크플로우 추출 129 = **157개** UI 요소 매핑(사이드바·대시보드·기록·코치·SNS·설정·프로필)
- **UiExplorer**: 페이지 선택 + iframe 실제 프리뷰(**사이드바 포함**, 데스크탑 폭 렌더 후 축소) + 트리뷰(확장/선택/하이라이트) + 클릭 선택(오버레이로 쓰기 차단) + **라이브 측정**(색·폰트·간격·order·margin·padding·X/Y/W/H·부모) + **AI 작업지시 초안 생성기**
- 수정유형 배지(직접수정/CSS/TSX/백엔드), 토큰편집 ↔ UI구조 모드 스위치, 기존 기능(토큰편집·직접적용·다크라이트·데스크탑모바일) 전부 유지

### 후속 미세 보정

- **PR #15**: 프리뷰 우측 여백 제거(데스크탑, iframe 폭을 컨테이너에 맞춤) + 하이라이트 실제 요소 bounding box 기준 + **다크/라이트 토글 추가**(전환 시 측정값도 테마 기준 갱신)
- **PR #16**: 모바일 프리뷰 **가운데 정렬**(우측 빈 여백 제거) + 미발견 요소 하이라이트 잔상 제거

### 완료 기준 충족

`npm run build` 성공 · 사이드바 포함 프리뷰 · 주요 하위페이지 프리뷰 · 프롬프트(고급 수정) 모드 · 157개 요소 매핑 · AI 작업지시 초안(라이브 측정 포함) · 프리뷰에서 데이터 쓰기/삭제/저장 미실행 · 데스크탑 우선(모바일 보조)

### 변경/추가 파일

- 신규: `src/lib/uiCatalog.ts`, `src/lib/uiCatalog.generated.ts`, `src/components/studio/UiExplorer.tsx`
- 수정: `src/pages/Studio.tsx`, `src/pages/studio.css`
- **PR #13 · #15 · #16 모두 main 머지** (CF Pages 자동 배포)

### 정본(무손실 대화 전문)

이 페이지의 하위 페이지(사용자 업로드) + 레포 `docs/sessions/260530-스튜디오-UI매핑-프롬프트모드_대화raw.md`

자식 페이지:
- 📄 [260530-스튜디오-UI매핑-프롬프트모드_대화raw](#/doc/workreport-69a) → 로컬: `pages/02-workreport/69a_260530_스튜디오-UI매핑-대화raw.md`

---

## 전체 대화 (raw)

---

### 🧑 사용자  ·  2026-05-29T08:50:54.807Z

작업지시가 아니라 브레인스토밍인데
바이브코딩만으로 매번 UI바꿀때마다 프롬프트해서 결과 기다리는 방식에만 의존해서는
자잘한 UI변경에 너무 비효율적인데
직관적인 UI/UX변경 툴을 만들어서 버튼위치, 폰트변경, 톤앤매너 변경등은 직접 할수 있는 툴을 개발하고 싶다.
커밋하기 전에 AI에이전트에게 바로 적용되는 내용인지 UX-백엔드 동반 작업 필요한 내용인지 검수받으면 되잖아.

---

### 🤖 Claude  ·  2026-05-29T08:51:49.261Z

브레인스토밍 좋습니다. 코드 짜기 전에 같이 방향부터 정리해보죠. 그 전에 달록이 지금 토큰을 어떻게 들고 있는지 잠깐 확인하고 구체적으로 얘기하겠습니다.

---

### 🤖 Claude  ·  2026-05-29T08:52:38.366Z

좋은 그림이 그려졌습니다. 달록의 톤앤매너·폰트가 전부 src/index.css의 CSS 변수(--accent, --font-body, --radius 등) 하나로 모여 있어요. 이게 이 아이디어의 성패를 가르는 핵심 포인트라 거기서부터 풀어가겠습니다.

## 1. 먼저, 바꾸고 싶은 3가지는 난이도가 완전히 다릅니다

사장님이 든 예시를 뜯어보면 두 부류로 갈려요.

| 변경 종류 | 실제 정체 | 난이도 |
|---|---|---|
| 톤앤매너(색) | CSS 변수 값 하나 교체 | 🟢 매우 쉬움 |
| 폰트 | --font-body 값 교체 | 🟢 매우 쉬움 |
| 버튼 위치 | JSX 구조·레이아웃 변경 | 🔴 어려움 |

즉 3개 중 2개는 이미 "값 하나 바꾸기" 수준으로 정리돼 있어요(F-7 톤앤매너 작업 때 토큰화해둔 게 여기서 빛을 봅니다). 브라우저에서 --accent만 바꿔도 앱 전체가 즉시 라임→다른 색으로 바뀌어요. 재빌드도, AI 프롬프트도 필요 없습니다.

버튼 위치만 진짜 어려운 영역이에요. 이건 코드 구조를 건드려야 해서 "직접 편집 툴"의 비용 대부분이 여기서 발생합니다.

## 2. 사장님 아이디어는 사실 두 개의 문제입니다

분리해서 봐야 각각 싸게 풀려요.

- (A) 직접 편집 도구 — 내가 손으로 색·폰트·위치를 만진다
- (B) 커밋 전 AI 검수 게이트 — "이거 그냥 적용해도 되는 변경이야, 아니면 백엔드도 손봐야 해?"를 판별

(B)는 (A)와 독립적이고, 솔직히 (A) 없이도 가치가 있습니다.

## 3. (A) 직접 편집 — 스코프별 3가지 길

길 1 · 토큰 플레이그라운드 (강력 추천, 주말 스코프)

달록 안에 개발용 숨김 페이지를 하나 만들어요. 색상 피커·폰트 드롭다운·슬라이더(둥근 정도 --radius, 간격 등)를 띄우고, 만지는 즉시 [document.documentElement.style](http://document.documentElement.style).setProperty('--accent', 값)으로 실시간 미리보기가 됩니다. 마음에 들면 "내보내기" 버튼이 바뀐 변수만 모아서 보여주고, 그걸 index.css에 반영(혹은 제가 자동 반영)하면 끝이에요.

- 커버: 톤앤매너, 폰트, 모서리, 간격, 그림자 — 즉 사장님 욕구의 ~70%
- 못 함: 버튼 위치
- 장점: 기존 "목업 catalog 우선" 워크플로우의 자연스러운 확장이고, 새 의존성 0개, 달록 디자인 시스템과 100% 일치
- 이게 사실상 사장님이 reference_design_system에서 하던 일을 GUI로 만든 것

길 2 · 오픈소스 비주얼 에디터 (버튼 위치까지 원하면)

Onlook, [Builder.io](http://Builder.io) Visual Copilot 같은 도구가 React 화면을 클릭해서 위치·여백을 끌어 옮기고 코드로 되써줍니다. 버튼 위치 문제까지 커버돼요. 다만 달록의 CSS 변수 토큰 체계와 딱 맞지 않아 Tailwind 클래스를 덕지덕지 만들어낼 수 있고, 학습 곡선과 외부 의존성이 생깁니다. 먼저 길 1을 쓰고, 위치 변경 욕구가 정말 잦아지면 그때 Onlook을 시험 도입하는 순서를 권합니다.

길 3 · 풀 커스텀 에디터 자체 개발 (비추천)

클릭-편집 오버레이를 직접 만드는 건 그 자체가 별도 제품이에요. 1인 운영에서 달록 본체와 유지보수 경쟁이 붙습니다. 카파시 헤더의 "단순함이 먼저" 원칙에도 정면으로 어긋나요. 길 2 도구들이 이미 수년치 작업을 해뒀는데 바퀴를 다시 발명할 이유가 약합니다.

## 4. (B) AI 검수 게이트 — 대부분 AI 없이도 됩니다

"적용 가능 vs 백엔드 동반 필요"는 사실 변경된 파일·라인만 봐도 90%는 기계적으로 판별돼요.

- index.css 변수 값만 바뀜 → 🟢 순수 표현, 바로 적용
- className·스타일만 바뀜 → 🟢 표현 변경
- JSX 구조, props, 데이터 바인딩, supabase/API 호출, RLS 관련 변경 → 🔴 검수 필요

이건 커밋 전 훅 + 간단한 규칙 스크립트로 충분하고, AI는 애매한 회색지대만 한 번 더 봐주면 돼요. 굳이 매번 LLM을 부를 필요가 없어서 비용도 거의 안 듭니다.

## 5. 가장 큰 함정 하나

도구를 만드는 것 자체가 "기다림 없는 빠른 변경"을 노렸는데, 잘못 키우면 그 도구 유지보수가 새 기다림이 됩니다. 그래서 길 1(토큰 플레이그라운드)처럼 작고, 기존 시스템에 얹히고, 망가져도 본체에 영향 없는 형태로 시작하는 게 핵심이에요.

제 추천 경로는 토큰 플레이그라운드(길 1) → 검수 게이트(휴리스틱) 먼저, 버튼 위치는 빈도 보고 나중에 Onlook 검토입니다. 방향을 좁히게 하나만 여쭤볼게요.

---

### 🤖 Claude  ·  2026-05-29T08:54:51.157Z

좋습니다. 위치는 일단 접어두고 토큰 플레이그라운드 + 검수 게이트 두 개를 설계 수준으로 같이 파보죠. 아직 코드는 안 짜고, 그림만 확실히 잡겠습니다.

## A. 토큰 플레이그라운드 — 어떻게 생겼나

핵심 원리 (왜 싸고 안전한가): 달록의 모든 톤앤매너가 :root의 CSS 변수 하나로 흐르기 때문에, 편집기는 파일을 안 건드리고 브라우저에서 변수만 덮어쓰면 됩니다. (색상 피커에서 라임→청록 선택 → setProperty('--accent','#5fd9e6') → 앱 전체가 그 순간 청록으로, 재빌드 X 새로고침 X.)

화면 구성 3분할 제안 — 토큰 패널 / 라이브 미리보기 / 변경 요약. 설계 결정 3가지: ① 미리보기엔 대표 컴포넌트 갤러리(버튼·카드·사이드바 축소판·차트·코치 브리프)를 모은다(reference_design_system의 살아있는 버전). ② 라이트 모드도 같이 — 다크/라이트 양쪽 값을 한 쌍으로. ③ 저장은 수동(바뀐 변수만 출력→붙여넣기→반영) 시작, 익으면 자동 검토.

이 도구의 진짜 정체: 사장님이 직접 운전하는 목업 catalog(feedback_mockup_first). 기존 워크플로우의 운전대 이전.

## B. 검수 게이트 — 회색지대만 AI

3색 신호등: 🟢 index.css 변수 값만/className만 → 순수 표현, 바로 적용(AI 호출 X). 🔴 supabase 호출/RLS/props 시그니처/데이터 구조 변경 → 백엔드·UX 동반, 정지(AI 호출 X). 🟡 JSX 구조가 바뀌었는데 데이터는 안 건드림(애매) → 이때만 AI 질문. 🟢🔴은 규칙(파일 경로+키워드)으로 공짜 처리, AI는 🟡만. git pre-commit 훅 한 개로 충분, feedback_git_workflow 브랜치+PR 위에 얹힘.

미해결 의문: 플레이그라운드를 달록 안 숨김 페이지 vs 별도 앱. 달록 안 숨김 페이지 권장(미리보기 정확도가 생명). 다음 갈래: ① 노출 토큰 8~10개 선정 ② 게이트 🟡 자동 흐름 ③ 라이트/다크 쌍 UX.

---

### 🧑 사용자  ·  2026-05-29T17:56:42.878Z

달록 안에 두고
대신 마스터계정에서만 활성화되게
마스터계정 한정으로 버튼을 활성화 한다거나
실체는 달록이지만 별도 앱처럼 다른 클라이언트나 별도 앱처럼 접근하게 할수 있지 않나?

---

### 🤖 Claude  ·  2026-05-29T17:57:03.427Z

마스터 한정 + 별도 앱처럼 접근, 둘 다 가능하고 사실 잘 어울리는 조합이에요. 근거를 정확히 대려고 달록이 지금 마스터/역할을 어떻게 구분하는지 잠깐 확인하겠습니다.

---

### 🤖 Claude  ·  2026-05-29T17:58:05.322Z

확인됐습니다. 둘 다 됩니다. 게다가 달록엔 이미 필요한 부품이 다 있어요.

## 1. 마스터 한정 버튼 — 이미 한 줄이면 됩니다

useAuth.ts가 isMasterUser를 이미 내주고 있어요. auth.ts의 isMaster()가 마스터 이메일을 판별하고요. 그래서 버튼이든 라우트든 이렇게 감싸기만 하면 됩니다.

`const { isMasterUser } = useAuth()` / `{isMasterUser && <StudioButton />}` (마스터 아니면 존재 자체가 안 보임)

여기서 꼭 짚고 갈 게 하나 있어요. 이런 마스터 게이팅은 "보안"이 아니라 "숨김"입니다. 실제로 auth.ts를 보면 마스터 판별이 브라우저 localStorage 플래그 + 클라이언트에 박힌 비밀번호로 돼 있어요(MASTER_PASSWORD = 'qwer1234'가 코드에 그대로 노출). 즉 마음먹은 사람은 우회할 수 있어요.

그런데 이 도구에선 그게 전혀 문제가 안 됩니다. 플레이그라운드는 DB에 아무것도 안 써요. 자기 브라우저의 CSS 변수만 잠깐 바꾸고 텍스트를 뱉을 뿐이라, 비마스터가 어찌어찌 들어와도 자기 화면 색만 잠깐 바뀌었다가 새로고침하면 끝이에요. 데이터 접근이 0이라 project_master_rls_policy의 RLS 걱정과도 무관하고요. 그래서 "마스터 게이팅 = 보안"이 아니라 "마스터 게이팅 = UI 정리"로 보면 정확합니다. 설계가 본질적으로 무해해요.

> (곁가지 — 평문 마스터 비번이 클라이언트 번들에 노출돼 있는 건 이 도구와 별개로 feedback_git_workflow 원칙상 따로 손볼 거리예요. 지금 건드리진 않고 언급만 해둡니다.)

## 2. "실체는 달록인데 별도 앱처럼" — 3단계로 가능

이건 아주 표준적인 패턴이에요. 안쪽은 같은 코드, 바깥쪽은 별도 앱처럼 보이게 하는 거죠. 단계별로 "별도 앱 느낌"이 강해집니다.

- 1단계: 같은 앱 안 숨김 라우트 /studio + 마스터 가드 — 별도 앱 느낌 중(URL만 다름) — 비용 🟢 매우 낮음
- 2단계: 같은 코드베이스, 별도 빌드 → 서브도메인 [studio.dallog.app](http://studio.dallog.app) — 느낌 상(완전 별개 주소·아이콘) — 비용 🟡 중간
- 3단계: 모노레포로 패키지 분리 — 느낌 최상 — 비용 🔴 높음(과함)

1단계 (지금 추천): 달록 라우터에 /studio 경로를 추가하되, 사이드바 메뉴엔 안 띄우고 마스터에게만 보이는 버튼/주소로만 들어가요. 핵심 기술 포인트는 lazy-load(코드 분할)예요. `const Studio = lazy(() => import('./pages/Studio'))`. 이렇게 하면 플레이그라운드 코드가 일반 사용자 번들에 안 섞여요. 평소엔 다운로드도 안 되고, /studio에 들어갈 때만 그 조각이 로드됩니다.

2단계 (나중에 "진짜 별도 클라이언트" 느낌을 원하면): 같은 저장소·같은 컴포넌트를 쓰되 Vite 빌드 엔트리를 하나 더 만들어서 [studio.dallog.app](http://studio.dallog.app) 같은 별도 주소에 배포해요. 겉보기엔 완전히 다른 앱인데 미리보기에 쓰는 버튼·카드는 달록 본체와 같은 소스를 import해서 항상 일치해요. "실체는 하나, 출입구는 둘"의 정석.

차이를 한 줄로 — 1단계는 같은 문 안의 숨은 방, 2단계는 옆 건물인데 내부 배관은 공유.

그래서 권하는 그림: 1단계 + 마스터 가드 + lazy-load. (미리보기 정확도 100%, 일반 사용자 번들 격리, isMasterUser 한 줄 게이팅, 나중에 2단계 승격 가능 — 1단계가 2단계를 막지 않음.)

다음으로 좁힐 만한 건 ① /studio 첫 화면 구성 ② 노출 핵심 토큰 8~10개 선정 ③ 검수 게이트 흐름.

---

### 🧑 사용자  ·  2026-05-29T17:59:03.617Z

뭐 물어봤지만 이미 순서는 적절하게 이미 짜놨네.
그리고 모바일도 같이 다뤄야하는거 알지?

---

### 🤖 Claude  ·  2026-05-29T17:59:17.179Z

당연하죠. 사실 모바일이 이 도구의 난이도를 한 단계 올리는 지점이에요. 달록이 지금 모바일을 어떻게 다루는지 잠깐 확인하고 설계에 녹이겠습니다.

---

### 🤖 Claude  ·  2026-05-29T18:00:09.577Z

확인했습니다. 달록은 이미 반응형이에요. index.css:502에 @media (max-width: 880px) 브레이크포인트가 있고, isMobile/matchMedia 같은 JS 기반 모바일 감지가 Layout.tsx 포함 9개 파일에 퍼져 있어요. 즉 "CSS 미디어쿼리 + JS로 모바일 분기"를 둘 다 쓰는 구조.

모바일이 바꾸는 것 세 군데: ① 미리보기에 뷰포트 전환(데스크탑/모바일 토글) 필수 — iframe이나 고정폭 컨테이너로 375px 흉내, 880px 미디어쿼리 실제 발동. ② "쉬운 70%"도 모바일에선 한 번 더 봐야(폰트 크기·자간, 보조 텍스트 대비). ③ 버튼 위치는 모바일 때문에 두 배 어렵다(데스크탑+모바일 두 곳, JS isMobile 9개 파일).

도구 자체는 모바일에서 굴릴 필요 없다 — 조작 화면(3분할)은 데스크탑 전용, 미리보기로만 모바일 본다. 검수 게이트에도 모바일 항목 추가(🟢라도 모바일 레이아웃 깰 수 있어 "모바일 확인했나?"). 미해결: 브레이크포인트별 다른 토큰 값을 원하면 토큰 구조를 키우는 큰 결정 — 그때 reference_design_system 차원에서 논의.

---

### 🧑 사용자  ·  2026-05-29T18:02:30.815Z

바로 다음으로 넘어가자.
그리고 토큰구조 자체를 키우더라도 만들어둘때 한번에 하는게 좋아.
그래서 모바일 수정까지 완벽하게 대응할수 있었으면 좋겠어.

---

> ⚠️ **본문 절단 안내**: 본 노션 페이지 본문은 여기까지 노션 MCP에서 반환되었다(이후 턴 절단). 155턴 전체 무손실 대화는 자식 페이지([260530-스튜디오-UI매핑-프롬프트모드_대화raw](#/doc/workreport-69a), 로컬 `69a_260530_스튜디오-UI매핑-대화raw.md`) 및 레포 `docs/sessions/260530-스튜디오-UI매핑-프롬프트모드_대화raw.md`에 보존됨.