프론트 개발자가 말합니다. "번들이 5MB라 모바일 초기 로딩이 느려요. 상태 관리가 꼬여서 장바구니 수량이 화면마다 달라요." 디자이너는 "버튼 스타일이 화면마다 제각각이라 디자인 시스템이 필요해요." QA는 "스크린리더로 탐색이 안 돼서 접근성 이슈예요"라고 합니다. PM·인프라인 당신은 프론트엔드·UX/UI 용어를 알아야 이 대화를 따라가고 우선순위를 정할 수 있습니다. 이 사전은 프론트엔드·UX/UI 용어를 빠르게 해독합니다. 렌더링·배포 형태는 [[frontend-backend-rendering]]에서 다룹니다.
- 1번들·코드분할·상태관리 등 프론트엔드 용어를 이해할 수 있다
- 2SPA/SSR/반응형·컴포넌트로 화면 구조를 읽을 수 있다
- 3와이어프레임·디자인시스템·UX/UI 용어로 디자인 협업을 따라갈 수 있다
- 4접근성·사용성 용어를 요구사항에 반영할 수 있다
프론트엔드 — 코드·성능
화면을 만드는 코드의 용어
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Bundle / Code Splitting / Lazy Loading | 묶음 결과물 / 분할 / 지연 로딩 | 큰 번들=느린 로딩 → [[frontend-backend-rendering]] | ★★ |
| State Management | 공유 데이터 관리 | Redux/Zustand 등 | ★★ |
| Component / Props / Hook | 재사용 UI 조각 / 입력 / 상태로직 | React 등 | ★★ |
| SPA / CSR / SSR / SSG | 단일페이지앱 / 렌더링 방식 | → [[frontend-backend-rendering]] | ★★ |
| Responsive / Breakpoint | 반응형 / 화면크기 분기점 | 모바일 대응 | ★★ |
| Hydration | SSR HTML에 상호작용 붙이기 | SSR 성능 | ★ |
| Build / Transpile (Babel) / Minify | 빌드 / 변환 / 최소화 | → [[language-runtime-build]] | ★★ |
핵심: 번들이 크면 초기 로딩(특히 모바일)이 느립니다 — 코드 분할·지연 로딩으로 줄입니다. 상태 관리가 꼬이면 "화면마다 값이 다른" 버그가 납니다. 렌더링 방식(CSR/SSR)은 SEO·배포 형태를 가릅니다([[frontend-backend-rendering]]).
UX — 사용자 경험 설계
무엇을 어떻게 쓰게 할지
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Wireframe / Mockup / Prototype | 뼈대 / 시안 / 동작 시제품 | 초기 검증 → [[requirements-prd]] | ★★ |
| User Flow / Journey | 사용자 동선 / 여정 | 흐름 설계 | ★★ |
| Usability / Information Architecture | 사용성 / 정보 구조 | 찾기 쉬움 | ★★ |
| Persona / Use Case | 가상 사용자 / 사용 사례 | 누구를 위해 | ★ |
| A/B Test | 두 안 비교 실험 | 데이터 기반 결정 → [[release-strategy]] | ★★ |
핵심: 와이어프레임·프로토타입으로 만들기 전에 흐름을 검증하면([[sdlc-overview]]의 shift-left) 재작업이 줄어듭니다. A/B 테스트는 기능 플래그와 결합해 '어느 안이 나은지'를 데이터로 결정합니다([[release-strategy]]).
UI — 시각·컴포넌트
보이는 것의 표준화
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Design System / Component Library | 디자인 표준 / 컴포넌트 모음 | 일관성·협업속도 → [[dev-roles-collaboration]] | ★★ |
| Design Token | 색·간격·타이포 표준값 | 테마·일관성 | ★★ |
| Typography / Spacing / Grid | 타이포 / 간격 / 격자 | 시각 정렬 | ★ |
| Accessibility (a11y) / WCAG | 접근성 / 접근성 표준 | 스크린리더·키보드 → [[requirements-prd]] | ★★ |
| Semantic Markup / Alt Text | 의미적 마크업 / 대체텍스트 | 접근성·SEO | ★★ |
| i18n / l10n | 국제화 / 지역화 | 다국어·로케일 → [[glossary-config-env]] | ★ |
핵심: 디자인 시스템·토큰으로 UI를 표준화하면 "화면마다 제각각"이 사라지고 디자이너↔프론트 협업이 빨라집니다([[dev-roles-collaboration]]). 접근성은 다양한 사용자를 위한 것이자 법적 의무이며 SEO에도 이롭습니다 — PM이 요구사항에 포함시켜야 합니다([[requirements-prd]]).
프론트 성능·사용성 점검 — 직접 확인
코드를 못 짜도 PM·QA가 프론트 품질을 점검할 수 있는 항목들입니다.
1) 번들 크기: 초기 로딩이 느린가? (브라우저 개발자도구 Network 탭)
→ 번들 수 MB면 코드 분할·지연 로딩 검토([[frontend-backend-rendering]])
2) 접근성: 키보드(Tab)만으로 주요 흐름이 되나? 이미지에 alt가 있나?
→ 스크린리더·Lighthouse 접근성 점수
3) 반응형: 모바일 화면에서 깨지지 않나?
→ 개발자도구 모바일 뷰로 확인
4) 상태 일관성: 같은 데이터(장바구니)가 화면마다 같나?
번들: 초기 JS 4.8MB → 모바일 3G에서 8초 로딩, 코드분할 필요
접근성: Lighthouse a11y 62점, 이미지 alt 누락 다수, 키보드 탐색 끊김
반응형: 320px에서 버튼 겹침 → breakpoint 보강
→ 성능·접근성·반응형 모두 개선 백로그로
echo '번들 크기 + 접근성 + 모바일 점검'- 초기 번들이 수 MB면 모바일·저사양에서 로딩이 느림 → 코드 분할·지연 로딩·이미지 최적화. Network 탭에서 전송량 확인([[frontend-backend-rendering]])
- 키보드(Tab)만으로 주요 흐름이 안 되거나 이미지 alt가 없으면 접근성 미흡 → 법적·사용성·SEO 리스크. Lighthouse 점수로 정량화
- 같은 데이터가 화면마다 다르면 상태 관리 문제 → 단일 출처(store)로 관리되는지 확인. 불필요한 리렌더링도 점검
- 디자인이 화면마다 제각각이면 디자인 시스템 부재 → 토큰·공통 컴포넌트 도입으로 일관성·협업속도 개선([[dev-roles-collaboration]])
상황: 데스크톱에선 빠른데 모바일 사용자의 이탈률이 유독 높습니다. 측정해보니 첫 화면이 뜨기까지 모바일에서 5~8초가 걸립니다.
원인: 거대한 초기 번들입니다. 모든 코드·라이브러리를 한 번에 받느라(특히 모바일 네트워크) 첫 렌더가 늦어 사용자가 떠납니다([[frontend-backend-rendering]]의 CSR 초기 로딩 약점).
진단:
□ 초기 JS 번들 크기는? (개발자도구 Network, 수 MB면 과대)
□ 한 번에 다 받나, 코드 분할(라우트별 지연 로딩)했나?
□ 큰 라이브러리를 첫 화면에서 다 불러오나?
해결: (1) 코드 분할(code splitting) — 라우트/기능별로 나눠 필요한 것만 먼저 로드. (2) 지연 로딩(lazy loading) — 당장 안 보이는 컴포넌트·이미지는 나중에. (3) 무거운 라이브러리 대체·트리쉐이킹. (4) SEO·초기 체감이 중요하면 SSR/SSG 검토([[frontend-backend-rendering]]). 모바일 성능은 비즈니스 지표(이탈률·전환율)와 직결되므로, PM이 비기능 요구([[requirements-prd]])에 "모바일 초기 로딩 N초 이내"를 명시할 가치가 있습니다.
PM·인프라가 프론트·UX/UI 용어를 알면 협업의 사각이 사라집니다 — 디자이너의 "디자인 시스템", 프론트의 "번들·상태관리·SSR", QA의 "접근성"을 같은 언어로 이해하고 우선순위를 정합니다. 인프라 관점에선 렌더링 방식(CSR/SSR)이 배포 형태(CDN vs 런타임 서버)와 비용을 가르고([[frontend-backend-rendering]]), 번들 최적화·이미지 CDN이 성능에 직결됩니다. PM은 모바일 성능·접근성을 비기능 요구로 명시하고, A/B 테스트(기능 플래그)로 UX 결정을 데이터화합니다([[release-strategy]]).
이것으로 'PM·SRE를 위한 소프트웨어 엔지니어링' 트랙의 본론과 도메인 용어사전을 모두 마칩니다. 개발자의 언어부터 방법론·협업·배포·아키텍처·품질문화, 그리고 13개 도메인 용어사전까지 — 코드를 직접 짜지 않아도 개발 조직과 같은 언어로 일할 수 있는 리터러시를 갖추게 됩니다.