[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 웹 접근성 및 포용적 설계 (a11y)
|
||||
category: Software Architecture
|
||||
tags: [Accessibility, a11y, Semantic HTML, Inclusivity]
|
||||
category: Software [[Architecture]]
|
||||
tags: [[[Accessibility]], a11y, Semantic HTML, Inclusivity]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -13,7 +13,7 @@ created: 2026-04-20
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Semantic HTML (의미론적 태그)**:
|
||||
- `<div>`로만 도배하지 마라. `<main>`, `<article>`, `<section>`, `<nav>` 등 의미가 담긴 태그를 써야 기계(스크린 리더)와 검색 엔진이 내 콘텐츠의 중요도를 파악한다.
|
||||
- **ARIA & States**:
|
||||
- **ARIA & [[State]]s**:
|
||||
- 표준 HTML로 설명이 불가능한 인터랙션(예: 커스텀 탭 메뉴)은 `aria-label`, `aria-hidden` 등을 통해 기계에게 보조 설명을 전한다.
|
||||
- **Keyboard Navigation**:
|
||||
- 마우스 없이 `Tab` 키와 `Enter` 키만으로 내 앱의 모든 핵심 기능을 수행할 수 있는지 검증하라. 포커스링을 숨기지 마라. 누군가에게는 유일한 가이드라인이다.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 협업 가이드라인 및 코드 거버넌스
|
||||
category: Software Architecture
|
||||
tags: [Collaboration, PR, Code Review, Documentation, Governance]
|
||||
category: Software [[Architecture]]
|
||||
tags: [Collaboration, PR, [[Code Review]], Documentation, Governance]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -11,7 +11,7 @@ created: 2026-04-20
|
||||
> 코드는 혼자 쓰는 일기장이 아니라 함께 짓는 건축물이다. 동료의 시간을 아껴주는 문서화와 소통 방식이 당신의 가치를 증명한다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Pull Request (PR) 에티켓**:
|
||||
- **[[Pull Request (PR)]] 에티켓**:
|
||||
- "이거 고쳤습니다"는 최악의 PR이다. 무엇을(What), 왜(Why), 어떻게(How) 했는지 명시하고 가능한 시각적 결과물(스크린샷, GIF)을 첨부하여 리뷰어의 인지 부하를 줄여라.
|
||||
- **Code Review Protocol**:
|
||||
- P1(필수 반영), P2(권장), P3(질문/의견) 식으로 중요도를 표시하라. 비판은 날카롭게 하되 표현은 따뜻하게 하여 팀의 심리적 안정성을 유지하라.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 애플리케이션 안정성 및 로깅 (Error Boundary)
|
||||
category: Software Architecture
|
||||
tags: [Reliability, Error Boundary, Sentry, Logging, Stability]
|
||||
category: Software [[Architecture]]
|
||||
tags: [[[Reliability]], Error Boundary, Sentry, Logging, [[Stability]]]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -24,5 +24,5 @@ created: 2026-04-20
|
||||
- 모든 곳에 에러 바운더리를 칠 필요는 없다. 데이터와 UI가 1:1로 매칭되는 구조라면 차라리 상위에서 에러를 처리하는 것이 논리적으로 명확할 수 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[System_Debugging_Protocol]] , [[React_Testing_Strategy]]
|
||||
- Related: [[System_Debugging_Protocol]] , [[React_[[Testing]]_Strategy]]
|
||||
- Foundation: [[System_Protocol_Standard]]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 스타일 거버넌스 및 디자인 시스템
|
||||
category: Software Architecture
|
||||
tags: [Styling, Tailwind, CSS-in-JS, Design System, Responsive]
|
||||
category: Software [[Architecture]]
|
||||
tags: [Styling, Tailwind, [[CSS-in-JS]], Design[[ system]], Responsive]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -11,11 +11,11 @@ created: 2026-04-20
|
||||
> 디자인은 '예쁜 픽셀'이 아니라 '일관된 약속'이다. 단 하나의 변수가 바뀌었을 때 전체 앱의 조화가 유지되는 구조가 진짜 디자인 시스템이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Design Tokens (디자인 토큰)**:
|
||||
- **[[Design Tokens]] (디자인 토큰)**:
|
||||
- 색상(#FF0000 -> `brand-primary`), 여백(16px -> `spacing-md`)을 추상화된 이름으로 정의하라. 그래야 브랜드 리뉴얼 시 코드 한 줄로 대응 가능하다.
|
||||
- **Utility-First vs Runtime Style**:
|
||||
- **Tailwind CSS**: 클래스명으로 스타일을 정의하여 런타임 오버헤드가 없고 개발 속도가 압도적이다.
|
||||
- **Styled-components**: 컴포넌트 중심의 의미론적 스타일링과 동적 Props 처리에 강점이 있다.
|
||||
- **[[Tailwind CSS]]**: 클래스명으로 스타일을 정의하여 런타임 오버헤드가 없고 개발 속도가 압도적이다.
|
||||
- **[[styled-components]]**: 컴포넌트 중심의 의미론적 스타일링과 동적 Props 처리에 강점이 있다.
|
||||
- **Mobile First Responsive**:
|
||||
- 작은 화면부터 디자인을 시작하여 넓은 화면으로 확장하라. 이것이 CSS 코드를 30% 이상 줄이는 지름길이다.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 단계별 시스템 디버깅 체크리스트 (L1~L3)
|
||||
category: Software Architecture
|
||||
category: Software [[Architecture]]
|
||||
tags: [Debugging, Troubleshooting, Checklist, Process]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 표준 시스템 통신 프로토콜 및 상태 제어
|
||||
category: Software Architecture
|
||||
tags: [Protocol, State Machine, Data Exchange, Lifecycle]
|
||||
category: Software [[Architecture]]
|
||||
tags: [Protocol, [[State]] Machine, Data Exchange, Lifecycle]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -16,7 +16,7 @@ created: 2026-04-20
|
||||
- `UPDATE`: 엔진 계산 결과의 브로드캐스트.
|
||||
|
||||
## 🔄 시스템 생명 주기 (Life Cycle)
|
||||
시스템은 [초기화 $\rightarrow$ 활성 루프 $\rightarrow$ 종료/정리]의 명확한 단계를 거쳐야 리소스 누수(Memory Leak)를 방지할 수 있습니다.
|
||||
시스템은 [초기화 $\rightarrow$ 활성 루프 $\rightarrow$ 종료/정리]의 명확한 단계를 거쳐야 리소스 누수([[memory]] Leak)를 방지할 수 있습니다.
|
||||
|
||||
## 🚨 상태 머신 (State Machine) 도입
|
||||
시스템 복잡도가 임계치를 넘을 경우, `READY`, `RUNNING`, `PAUSED` 등 상태를 명시적으로 제어하는 **State Machine** 적용을 원칙으로 삼습니다.
|
||||
|
||||
Reference in New Issue
Block a user