프론트 개발자가 말합니다. "번들이 5MB라 모바일 초기 로딩이 느려요. 상태 관리가 꼬여서 장바구니 수량이 화면마다 달라요." 디자이너는 "버튼 스타일이 화면마다 제각각이라 디자인 시스템이 필요해요." QA는 "스크린리더로 탐색이 안 돼서 접근성 이슈예요"라고 합니다. PM·인프라인 당신은 프론트엔드·UX/UI 용어를 알아야 이 대화를 따라가고 우선순위를 정할 수 있습니다. 이 사전은 프론트엔드·UX/UI 용어를 빠르게 해독합니다. 렌더링·배포 형태는 프론트엔드·백엔드·렌더링에서 다룹니다.
- 1번들·코드분할·상태관리 등 프론트엔드 용어를 이해할 수 있다
- 2SPA/SSR/반응형·컴포넌트로 화면 구조를 읽을 수 있다
- 3와이어프레임·디자인시스템·UX/UI 용어로 디자인 협업을 따라갈 수 있다
- 4접근성·사용성 용어를 요구사항에 반영할 수 있다
프론트엔드 — 코드·성능
확대
위 그림처럼 모든 코드를 한 번에 받으면 4~5MB가 되어 모바일 로딩이 8초 걸리지만, 코드 분할·지연 로딩으로 초기 청크를 300KB 수준으로 줄이면 1초 이내 첫 화면이 가능합니다.
확대
위 그림처럼 CSR·SSR·SSG는 HTML이 만들어지는 시점과 장소가 다르며, 렌더링 방식이 SEO·배포 형태·초기 로딩 속도를 결정합니다.
화면을 만드는 코드의 용어
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Bundle / Code Splitting / Lazy Loading | 묶음 결과물 / 분할 / 지연 로딩 | 큰 번들=느린 로딩 → 프론트엔드·백엔드·렌더링 | ★★ |
| State Management | 공유 데이터 관리 | Redux/Zustand 등 | ★★ |
| Component / Props / Hook | 재사용 UI 조각 / 입력 / 상태로직 | React 등 | ★★ |
| SPA / CSR / SSR / SSG | 단일페이지앱 / 렌더링 방식 | → 프론트엔드·백엔드·렌더링 | ★★ |
| Responsive / Breakpoint | 반응형 / 화면크기 분기점 | 모바일 대응 | ★★ |
| Hydration | SSR HTML에 상호작용 붙이기 | SSR 성능 | ★ |
| Build / Transpile (Babel) / Minify | 빌드 / 변환 / 최소화 | → 컴파일·인터프리터·빌드·런타임 | ★★ |
핵심: 번들이 크면 초기 로딩(특히 모바일)이 느립니다 — 코드 분할·지연 로딩으로 줄입니다. 상태 관리가 꼬이면 "화면마다 값이 다른" 버그가 납니다. 렌더링 방식(CSR/SSR)은 SEO·배포 형태를 가릅니다(프론트엔드·백엔드·렌더링).
UX — 사용자 경험 설계
무엇을 어떻게 쓰게 할지
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Wireframe / Mockup / Prototype | 뼈대 / 시안 / 동작 시제품 | 초기 검증 → 요구사항 정의 | ★★ |
| User Flow / Journey | 사용자 동선 / 여정 | 흐름 설계 | ★★ |
| Usability / Information Architecture | 사용성 / 정보 구조 | 찾기 쉬움 | ★★ |
| Persona / Use Case | 가상 사용자 / 사용 사례 | 누구를 위해 | ★ |
| A/B Test | 두 안 비교 실험 | 데이터 기반 결정 → 릴리스 전략 | ★★ |
핵심: 와이어프레임·프로토타입으로 만들기 전에 흐름을 검증하면(SDLC의 shift-left) 재작업이 줄어듭니다. A/B 테스트는 기능 플래그와 결합해 '어느 안이 나은지'를 데이터로 결정합니다(릴리스 전략).
UI — 시각·컴포넌트
확대
위 그림처럼 디자인 시스템은 토큰(색·간격·반경) → 원자(버튼·입력) → 분자(카드·폼) → 유기체(헤더·섹션) → 페이지 순으로 계층화되며, 아래 계층을 표준화할수록 위 계층의 일관성이 자동으로 유지됩니다.
보이는 것의 표준화
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Design System / Component Library | 디자인 표준 / 컴포넌트 모음 | 일관성·협업속도 → 개발 조직의 역할 | ★★ |
| Design Token | 색·간격·타이포 표준값 | 테마·일관성 | ★★ |
| Typography / Spacing / Grid | 타이포 / 간격 / 격자 | 시각 정렬 | ★ |
| Accessibility (a11y) / WCAG | 접근성 / 접근성 표준 | 스크린리더·키보드 → 요구사항 정의 | ★★ |
| Semantic Markup / Alt Text | 의미적 마크업 / 대체텍스트 | 접근성·SEO | ★★ |
| i18n / l10n | 국제화 / 지역화 | 다국어·로케일 → 용어사전 | ★ |
핵심: 디자인 시스템·토큰으로 UI를 표준화하면 "화면마다 제각각"이 사라지고 디자이너↔프론트 협업이 빨라집니다(개발 조직의 역할). 접근성은 다양한 사용자를 위한 것이자 법적 의무이며 SEO에도 이롭습니다 — PM이 요구사항에 포함시켜야 합니다(요구사항 정의).
프론트 성능·사용성 점검 — 직접 확인
코드를 못 짜도 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 탭에서 전송량 확인(프론트엔드·백엔드·렌더링)
- 키보드(Tab)만으로 주요 흐름이 안 되거나 이미지 alt가 없으면 접근성 미흡 → 법적·사용성·SEO 리스크. Lighthouse 점수로 정량화
- 같은 데이터가 화면마다 다르면 상태 관리 문제 → 단일 출처(store)로 관리되는지 확인. 불필요한 리렌더링도 점검
- 디자인이 화면마다 제각각이면 디자인 시스템 부재 → 토큰·공통 컴포넌트 도입으로 일관성·협업속도 개선(개발 조직의 역할)
상황: 데스크톱에선 빠른데 모바일 사용자의 이탈률이 유독 높습니다. 측정해보니 첫 화면이 뜨기까지 모바일에서 5~8초가 걸립니다.
원인: 거대한 초기 번들입니다. 모든 코드·라이브러리를 한 번에 받느라(특히 모바일 네트워크) 첫 렌더가 늦어 사용자가 떠납니다(프론트엔드·백엔드·렌더링의 CSR 초기 로딩 약점).
진단:
□ 초기 JS 번들 크기는? (개발자도구 Network, 수 MB면 과대)
□ 한 번에 다 받나, 코드 분할(라우트별 지연 로딩)했나?
□ 큰 라이브러리를 첫 화면에서 다 불러오나?
해결: (1) 코드 분할(code splitting) — 라우트/기능별로 나눠 필요한 것만 먼저 로드. (2) 지연 로딩(lazy loading) — 당장 안 보이는 컴포넌트·이미지는 나중에. (3) 무거운 라이브러리 대체·트리쉐이킹. (4) SEO·초기 체감이 중요하면 SSR/SSG 검토(프론트엔드·백엔드·렌더링). 모바일 성능은 비즈니스 지표(이탈률·전환율)와 직결되므로, PM이 비기능 요구(요구사항 정의)에 "모바일 초기 로딩 N초 이내"를 명시할 가치가 있습니다.
심화 — '빨리 보인다'와 '빨리 쓸 수 있다'는 다른 약속이다
심화: SSR·hydration·캐시 — 렌더링 용어가 충돌하는 지점
렌더링 용어를 하나씩 아는 것보다, 서로 결합했을 때 생기는 긴장을 아는 것이 실전입니다. "SSR 도입했는데 왜 이상하죠"의 답은 대부분 이 결합 지점에 있습니다.
- SSR은 FCP를 당기지, 상호작용을 당기지 않습니다: 서버가 준 HTML은 즉시 보이지만, hydration이 끝나기 전엔 버튼이 눌리지 않습니다. 번들이 크면 '보이는데 안 되는' 구간이 길어져 사용자는 오히려 더 답답해합니다. 면접에서 "SSR이면 빠른가요?"에 "첫 그림(FCP)은 빨라지지만 조작 가능 시점(TTI)은 여전히 번들 크기가 결정한다"까지 답하면 한 단계 깊은 답입니다(프론트엔드·백엔드·렌더링).
- Hydration은 '서버와 클라이언트가 같은 그림을 그린다'는 약속입니다: 현재 시각·랜덤값·localStorage·로그인 상태처럼 양쪽에서 다르게 계산되는 값이 렌더에 섞이면 hydration 불일치가 나고, 프레임워크가 화면을 다시 그리며 깜빡이거나 이벤트 연결이 어긋납니다. "SSR 전환 후 이상한 깜빡임" 제보의 대부분이 이 지점입니다.
- SSG·CDN 캐시와 A/B 테스트는 구조적으로 충돌합니다: 빌드 시 한 장으로 고정된 HTML을 CDN이 모두에게 나눠 주면 A/B 변형을 나눌 수 없습니다. 엣지에서 분기하거나, 클라이언트에서 분기(첫 화면 깜빡임 감수)하거나, 그 페이지만 SSR로 빼야 합니다 — "정적으로 싸게"와 "사용자마다 다르게"는 공짜로 함께 오지 않습니다(릴리스 전략).
- 접근성 사고의 최단 경로는 div 버튼입니다:
div에 onClick만 얹은 버튼은 마우스로만 눌립니다 — Tab 포커스도, Enter 입력도, 스크린리더의 "버튼" 안내도 없습니다. semantic markup(button)이면 이 전부가 공짜인데, 스타일 편의로 div를 쓰는 순간 키보드 사용자에게 그 기능은 존재하지 않는 것이 됩니다.
상황: SEO를 위해 CSR에서 SSR로 전환해 배포했습니다. 비로그인 사용자는 멀쩡한데 로그인 사용자만 "첫 화면이 번쩍이고 장바구니 버튼이 한동안 안 눌린다"고 제보합니다. 콘솔에는 hydration mismatch 경고가 찍혀 있습니다.
원인: 토큰이 localStorage에만 있어 서버는 로그인 상태를 모른 채 비로그인 헤더를 렌더했고, 클라이언트는 localStorage를 읽어 로그인 헤더를 그렸습니다. 서버 HTML과 클라이언트 첫 렌더가 달라 hydration이 실패했고, 프레임워크가 트리를 다시 그리는 동안 화면이 번쩍이며 이벤트 연결이 늦어진 것입니다.
진단: 콘솔의 hydration mismatch 경고를 확인하고 → 서버 응답 HTML('페이지 소스 보기')과 실제 화면을 비교해 어느 컴포넌트가 다른지 특정한 뒤 → 그 컴포넌트가 의존하는 값(시각·랜덤·localStorage·로그인 상태)을 추적합니다.
해결: (1) 로그인 상태처럼 서버도 알아야 하는 값은 쿠키로 전달해 서버·클라이언트가 같은 상태로 렌더하게 합니다. (2) 클라이언트에서만 알 수 있는 값은 첫 렌더에서 빼고 마운트 후에 채웁니다(자리표시자 렌더). (3) 시각·랜덤값은 서버가 정한 값을 내려보내 양쪽이 공유합니다. hydration 불일치는 성능 문제처럼 보이지만 본질은 두 렌더의 결정성입니다(프론트엔드·백엔드·렌더링).
PM·인프라가 프론트·UX/UI 용어를 알면 협업의 사각이 사라집니다 — 디자이너의 "디자인 시스템", 프론트의 "번들·상태관리·SSR", QA의 "접근성"을 같은 언어로 이해하고 우선순위를 정합니다. 인프라 관점에선 렌더링 방식(CSR/SSR)이 배포 형태(CDN vs 런타임 서버)와 비용을 가르고(프론트엔드·백엔드·렌더링), 번들 최적화·이미지 CDN이 성능에 직결됩니다. PM은 모바일 성능·접근성을 비기능 요구로 명시하고, A/B 테스트(기능 플래그)로 UX 결정을 데이터화합니다(릴리스 전략).
이것으로 'PM·SRE를 위한 소프트웨어 엔지니어링' 트랙의 본론과 도메인 용어사전을 모두 마칩니다. 개발자의 언어부터 방법론·협업·배포·아키텍처·품질문화, 그리고 13개 도메인 용어사전까지 — 코드를 직접 짜지 않아도 개발 조직과 같은 언어로 일할 수 있는 리터러시를 갖추게 됩니다.
용어 식별 실습으로 굳히기: 용어 식별 — 프론트엔드 / UX·UI — 증상·요청을 보고 렌더링·프론트·UX 용어를 가려냅니다.