UI 디자인
화면의 정보 배치·시각 표현·사용자 조작과 피드백을 결정할 때 참고할 판단과 원천을 모았다. 화면의 목적에서 출발해 역할별 표현과 문구를 정하고, 실제 내용과 상태에서 확인할 항목으로 이어진다. 특정 표현에 관심을 보인 이유는 아래 사례에서 읽을 수 있다.
시스템 구조·데이터 모델·API·배포 설계만 다루는 작업은 프로젝트의 해당 원천을 이용한다. 혼합 작업에서는 화면과 조작에 관한 부분에 이 Map을 적용한다. 컴포넌트의 의존성·상태 관리 구조와 화면에 드러나는 상태·피드백도 결정 대상으로 구분한다.
핵심 연결
| 지금 결정할 것 | 읽을 판단 |
|---|---|
| 어떤 사례를 가져올 것인가 | 디자인 레퍼런스는 화면의 목적과 함께 가져온다 |
| 색상·간격·글자·용어의 규칙을 어떻게 맞출 것인가 | UI의 일관성은 같은 역할에 같은 규칙을 적용하는 데서 나온다 |
| 행동·오류·빈 상태를 어떻게 설명할 것인가 | UI 문구는 사용자가 행동과 결과를 예측하게 한다 |
| 문구·README·팀용 글을 누구의 목소리와 어떤 어휘로 쓸 것인가 | 글은 화자를 연기하지 않고 독자 쪽에서 쓴다 |
| 여러 면을 담은 자기소개의 첫 읽기량을 어떻게 조절할 것인가 | 자기소개는 여러 단면을 한 번에 하나씩 보여줄 수 있다 |
| 모션을 넣거나 줄이는 이유는 무엇인가 | 모션은 전달할 정보와 사용 빈도에 맞춰 조절한다 |
| 실제 내용과 상태에서 무엇을 확인할 것인가 | UI 완성도는 실제 내용과 상태 변화 속에서 확인한다 |
| 판단을 에이전트가 재사용할 문장으로 어떻게 남길 것인가 | 에이전트 문서 작성 |
다이어그램과 정량 시각화
구조를 설계하는 판단은 프로젝트의 원천에서 확인하고, 그 구조나 데이터를 그림으로 전달할 때는 아래 질문으로 이어간다. 정보량을 조절하는 기준은 다이어그램의 읽기와 출력 조건에 적용한다.
| 지금 결정할 것 | 읽을 판단 |
|---|---|
| 어떤 관계를 어떤 유형으로 보여줄 것인가 | 다이어그램 유형은 보여줄 관계에 맞춰 고른다 |
| 얼마나 보여주고 어떤 용어로 설명할 것인가 | 다이어그램의 정보량과 독자의 어휘 수준은 따로 조절한다 |
| 무엇을 줄이고 생략한 내용을 어떻게 남길 것인가 | 다이어그램을 축약할 때는 핵심 관계를 보존하고 생략을 기록한다 |
| 정렬·라벨 배치 뒤에도 수치의 의미가 유지되는가 | 정량 다이어그램의 배치는 수치의 의미를 보존해야 한다 |
색상·상태의 역할은 일관성 Atomic으로, 정적·동적 전달은 모션 Atomic으로, 실제 그림과 설명의 대조는 완성도 Atomic으로 이어진다. 일반 유형·축약·배치의 실행 판단은 Front Worker 역할 지침이 연결한 다이어그램 참고자료를 이용한다. 특정 형식·도구 규격이나 자동 검사·수리의 현재 동작을 확인해야 하면 아래 Diagram Design·Archify Source의 관련 원문을 방문한다.
기술 설명과 조작 가능한 자료
독자의 배경지식을 점검하려면 기술 설명은 현상을 모델과 적용으로 연결한다 > 독자에게 익숙한 출발점인지 확인하기에서 시작하고, 기술 글은 이해에 필요한 맥락을 외부 읽기에 떠넘기지 않는다에서 본문 설명과 심화 링크의 역할로 이어간다. 도입부·문체에 관한 저자의 경험칙과 댓글의 보완은 개발 블로그의 독자와 읽기 흐름 - Michael Lynch에서 읽는다.
| 지금 결정할 것 | 읽을 판단 |
|---|---|
| 그림·차트·코드에서 무엇을 관찰하고 어떻게 해석하게 할 것인가 | 설명 자료는 관찰 질문과 해석을 함께 제공한다 |
| 같은 조건과 바뀌는 변수를 어떻게 비교하게 할 것인가 | 비교 데모는 공통 조건과 바뀌는 변수를 드러낸다 |
| 현상의 차이를 모델·사례·코드·판단으로 어떻게 이어 설명할 것인가 | 기술 설명은 현상을 모델과 적용으로 연결한다 |
기술 글의 설명 구조와 시각 자료 - Kciter는 정적 그림·시계열·움직임·코드를 함께 읽는 원천이다. 표지의 식별 역할은 레퍼런스 Atomic으로, 다른 화풍의 공통 틀은 일관성 Atomic으로, 작은 라벨과 길어진 데모의 실제 읽기는 완성도 Atomic으로 이어진다. 기술 설명의 효과나 기본 문체를 채택한 것으로 취급하지 않는다.
문서를 그대로 보여주는 화면
개인사이트에서는 원천 문서의 제목과 본문이 목록·그래프·본문 링크와 실제 읽기에 쓰인다. 현재의 링크 중심 탐색 선택과 후속 조작 기준은 개인사이트 설계와 운영의 의사결정 - Codex 대화 > 후속 선택과 실제 적용 — 2026-09-13~15에서 확인한다. 제목·도입·소제목·Map의 연결을 다듬을 때는 [비공개 문서]을 적용한다. 이 방향을 정한 맥락은 개인사이트 설계와 운영의 의사결정 - Codex 대화 > 원천 Markdown을 그대로 읽는 문서 작성에서 읽고, 같은 정본을 여러 인터페이스에서 이용하는 이유는 자기문서화와 공식 인터페이스로 이어진다.
문구 Atomic은 행동과 도착지를 예측하게 하는 기준을, 역할별 일관성 Atomic은 같은 역할에 같은 표현 규칙을 쓰는 기준을 제공한다. 이를 모든 글의 문체·목차를 통일하는 규칙으로 확대하지 않는다. 글자 크기·읽기 폭·여백·강조·중복 표시는 아래 타이포그래피·레이아웃 원문을 통해 화면에서 검토한다.
원문 방문 안내
| 원천 | 방문할 상황 |
|---|---|
| 인터페이스 판단과 검토 기준 - Jakub Krehel | 레이아웃·타이포그래피·색상·문구·접근성·실제 상태 검토. Source의 해당 세부 문서로 이동한다. |
| 제품 문구의 화자와 독자 어휘 - make-interfaces-feel-better | 문구·README에 친구·판매원·작가의 목소리나 내부 어휘가 섞였는지, 오류 문구가 원인과 다음 행동을 전하는지 판단할 때. 한국어 어체 규칙은 적용 경계 절과 함께 읽는다. |
| 디자인 엔지니어링과 모션 판단 - Emil Kowalski | 모션의 목적·빈도·속도, 조작 피드백, 선택 이유를 다루는 글·비교 데모가 필요할 때. |
| DESIGN.md 레퍼런스 활용 - VoltAgent | 화면 목적에 맞는 시각적 사례와 디자인 규칙을 비교할 때. 분석 대상과 미리보기를 확인한다. |
| 다이어그램의 의미·축약·검증 - Diagram Design | 다이어그램 유형 선택·축약·정량 표현·정적 내보내기·검증 범위를 판단할 때. 확인 버전과 원문별 역할을 Source에서 읽는다. |
| 다이어그램 배치 검증과 라벨을 지키는 수리 - Archify | 다이어그램 배치를 자동으로 검사하거나 고칠 때. 검증 단계별 증명 범위, 라벨을 지키는 수리 순서, 반복 수리를 멈출 조건과 확인 버전을 Source에서 읽는다. |
선택 이유를 회수할 사례
-
OptiChallenge의 대회 소개와 참가자 화면: 대회 소개와 참가자의 반복 작업을 잇는 표현, 주요 행동의 강조, 종료 안내·공지 재등장과 모바일 일정의 읽는 순서를 비교한 사례.
-
문서·제품·작업 화면의 설계 판단 - 개인사이트 비교 기록: 기술 블로그의 공통 화면과 전개, 기업 소개와 반복 작업 화면의 목적·연결·색 역할을 비교한 기록. 실제 목적지와 관찰 조건, 개인사이트에서 채택한 선택의 경계를 확인한다.
-
자기용 기록과 단편 자기소개 - cho.sh 대화: 기록·소개·도구의 서로 다른 목적과, 여러 단면이 있음을 알리며 한 단편씩 무작위로 보여주는 자기소개에 DanzzaN이 흥미를 느낀 이유. 관심의 근거와 구현 채택 범위는 Source에서 확인한다.
-
자기용 기록과 단편 자기소개 - cho.sh 대화 > 대시보드 형식의 홈: AWS 콘솔 홈에서 떠올린 요약·상세 진입 구조를 개인사이트 디자인에 참고하려는 맥락. 활동·기록·도구와 자기소개 위젯을 함께 놓는 홈의 역할을 살핀다.
작업에서 사용하는 순서
화면 판단의 실행 절차는 Mixdog Front Worker의 역할 지침과 필요한 조건부 참고자료를 따르고, 프로젝트의 목적·사용자·기존 디자인과 실제 내용을 확인한다. 과거 스킬 실행판을 자동 대체 본문으로 사용하지 않는다. 현재 근거에 없는 개인 선택 이유, 기준 충돌, 원천 갱신이나 실제 원문·데모 확인이 필요한 질문이면 이 Map에서 관련 Atomic·Source와 필요한 원문을 읽는다. 일반 UI 작업마다 같은 원문을 새로 방문하는 조건은 두지 않는다. 이미 유효하게 확인한 본문·판단은 재사용한다.
원문 접근에 실패하면 Source에 남은 마지막 확인일과 이번 조회 실패를 구분해 저장된 판단을 활용한다. 접근하지 못한 데모나 현재 원문을 보았다고 보고하지 않는다. 참고 자료의 변경은 사용자가 채택한 선택을 자동으로 바꾸는 근거가 아니다.
선호를 갱신하는 경로
실제 작업에서 선택·거절한 내용과 이유를 확인한다. 프로젝트의 구체적 선택은 그 프로젝트 문서에 두고, 개인 Vault 변경은 지식 승격은 사용자가 명시적으로 시작한다의 경계를 따른다.
사용자가 증류를 요청하면 대화·작업 원천과 기존 Atomic을 대조한다. 같은 주장에는 새 근거·조건·정정을 편입하고, 독립된 주장일 때 새 노트를 만든다. 저자의 조언과 에이전트의 해석을 사용자가 채택한 선호와 구분하며, 선호에는 실제 선택 이유와 적용 맥락의 원천을 연결한다. 일반 조회나 피드백만으로 확인일·선호를 자동 저장하지 않는다.
운영 근거와 연결
- UI 디자인 원천의 반복 조회와 증류 운영 - Codex 대화: 당시 원천 선택, UI와 아키텍처의 호출 경계, 두 에이전트 연결과 증류 방식.
- 업무별 Skill 확장과 Vault 선택 조회 적용 - Codex 대화: 2026-09-30 공통 실행 본문 이관과 원문 조회 조건의 후속 선택. 위 운영 기록의 당시 재조회 방식과 구분한다.
- Maps