[TIL] 메테리얼 디자인 vs 쿠퍼티노 디자인, Log vs Metrics, Structure…
in TIL on Til Last modified at:
2025-05-22 TIL
📝 TIL (Today I Learned)
🔗 원본 이슈: #59
📅 작성일: 2025-05-22
🔄 최종 수정: 2025년 05월 27일
🍀 새롭게 배운 것
1️⃣ 메테리얼 디자인(Material Design) vs 쿠퍼티노 디자인(Cupertino Design)
🎨 메테리얼 디자인 (Material Design)
- Google에서 만든 디자인 시스템
- Android 앱에서 기본적으로 사용되는 UI 가이드라인
특징:
- 실제 종이처럼 동작하는 “표면” 개념 → 레이어, 그림자, 깊이감
- 굵은 색상, 명확한 애니메이션, 카드 UI
- 일관된 컴포넌트 구조 (Button, Dialog 등)
- 다양한 화면 크기 및 접근성 고려가 잘 되어 있음
🍏 쿠퍼티노 디자인 (Cupertino Design)
- Apple이 만든 iOS용 디자인 철학
- Flutter에서는
CupertinoWidget으로 구현 특징:
- 심플하고 정갈한 UI, 얇은 폰트, 미니멀한 구성
- iOS의 네이티브한 느낌을 충실히 재현
- 스크롤, 네비게이션, 토글 스위치 등에서 iOS 특유의 인터랙션 존재
비교 요약:
| 항목 | Material Design | Cupertino Design |
|---|---|---|
| 주요 플랫폼 | Android, Web, Desktop | iOS |
| 디자인 철학 | 종이+레이어+애니메이션 | 단순함+미려함+일관성 |
| 주요 사용 예 | Google 앱, Android 앱 | Apple 앱, iOS 앱 |
| Flutter 적용 | MaterialApp | CupertinoApp |
요약: Android 앱은 Material 위주, iOS는 Cupertino 스타일을 따르며, Flutter는 둘 다 지원해 플랫폼에 맞는 UI를 쉽게 만들 수 있다!
2️⃣ Log vs Metrics
백엔드/운영 환경에서 시스템 상태를 추적할 때 자주 쓰이는 두 가지 개념을 비교해 보았다.
📄 로그 (Log)
시간 순으로 발생한 이벤트 기록
보통 텍스트 기반이며, 문제가 발생했을 때 무슨 일이 있었는지 파악하는 데 유용
예:
- 사용자가 로그인에 실패했습니다.
- 서버에서 500 에러가 발생했습니다.
특징:
- 구조화가 느슨함 (JSON 또는 단순 텍스트)
- 디버깅, 감사 추적에 용이
- 사후 분석에 효과적
- 저장 공간 많이 차지할 수 있음
예시:
{ "timestamp": "2025-05-13T12:45:00", "level": "ERROR", "message": "Login failed for user ID 123" }
📊 메트릭 (Metrics)
수치로 측정 가능한 시스템의 상태
시간에 따라 변화하는 수치 → CPU 사용량, 요청 수, 응답 시간 등
예:
- 서버 응답 시간 평균 120ms
- 현재 접속 사용자 수 300명
특징:
- 구조화된 데이터
- 시각화 및 대시보드 구성에 유리
- 알림(경고) 설정에 적합
- 보통 Prometheus, Grafana와 같이 사용됨
예시:
http_requests_total{method="GET", status="200"} 3456
비교 요약:
| 항목 | 로그(Log) | 메트릭(Metrics) |
|---|---|---|
| 목적 | 이벤트 디버깅, 추적 | 상태 모니터링, 성능 추적 |
| 형식 | 텍스트 기반, 구조 유동적 | 수치 기반, 구조화됨 |
| 저장 | 로그 파일, ELK Stack | 시계열 DB (Prometheus 등) |
| 시각화 | Kibana, Logtail 등 | Grafana 등 |
| 실시간성 | 낮음 (분석 중심) | 높음 (모니터링, 알림에 적합) |
로그는 “무슨 일이 일어났는가”를 알려주고, 메트릭은 “현재 시스템이 어떤 상태인가”를 알려준다. 둘은 보완 관계로 함께 사용하는 것이 가장 효과적이다!
3️⃣ Structured Logging (구조화된 로그)
✅ 개념
- 일반 로그는 텍스트 형식으로 사람이 읽기 쉽게 쓰는 반면, Structured Logging은 로그를 JSON 같은 구조화된 형태로 기록하는 방식입니다.
🔍 예시 비교
❌ 일반 로그 (Unstructured):
User 1234 failed to login due to wrong password
✅ 구조화 로그 (Structured):
{
"timestamp": "2025-05-13T10:42:00Z",
"level": "WARN",
"event": "login_failed",
"user_id": 1234,
"reason": "wrong_password"
}
✨ 장점
- 기계가 파싱하기 쉽고, 검색/필터링/집계에 유리
- 로그 수집 도구(예: Elasticsearch, Datadog)와 연동할 때 편함
- 실시간 모니터링이나 경고 시스템과 연계 가능
구조화 로그는 결국 “로그도 데이터다”라는 관점에서 관리하는 것!
4️⃣ ELK vs EFK 스택
✅ 공통 목적
- 분산 로그 수집, 저장, 분석, 시각화를 위한 스택입니다.
- 대규모 시스템에서 수많은 서버 로그를 한 곳으로 모아서 검색·분석하기 위해 사용합니다.
🧩 ELK Stack
- Elasticsearch: 로그를 저장하고 검색 가능한 DB
- Logstash: 로그 수집기. 다양한 소스에서 로그를 받아 필터링/변환
- Kibana: 시각화 도구 (대시보드, 검색 UI 등)
장점
- 오래된 구성으로 안정적이고 성숙함
- 다양한 입력 소스를 지원 (DB, 파일, MQ 등)
단점
- Logstash가 무거움 → 리소스 많이 사용
- 설정 복잡함
🧩 EFK Stack
- Elasticsearch
- Fluentd: 경량 로그 수집기 (Logstash 대체)
- Kibana
장점
- Kubernetes 환경에 더 적합
- Fluentd는 가볍고 플러그인으로 유연하게 확장 가능
- 최근 클라우드 환경에서 더 많이 사용됨
단점
- 복잡한 변환/파이프라인 처리 시엔 Logstash보다 기능 제한 있음
비교 요약표:
| 항목 | ELK | EFK |
|---|---|---|
| 로그 수집기 | Logstash (무거움) | Fluentd (가볍고 유연함) |
| 시각화 | Kibana | Kibana |
| 주 사용 환경 | 온프레미스, 레거시 시스템 | 클라우드, Kubernetes |
| 구성 난이도 | 다소 복잡 | 상대적으로 단순 |
📌 결론
| 상황 | 추천 |
|---|---|
| Kubernetes 기반 마이크로서비스 | ✅ EFK Stack |
| 다양한 로그 소스와 복잡한 처리 필요 | ✅ ELK Stack |
| 단순한 파일 로그 수집 및 시각화 | ✅ 둘 다 가능, 구조화 로그 필수 |
실제로는 EFK + Structured Logging 조합이 요즘 가장 트렌디한 방식입니다. 로그를 JSON 형태로 남기고, Fluentd를 통해 Elasticsearch에 넣은 뒤 Kibana로 시각화하면 아주 강력한 로그 분석 시스템이 됩니다.
