-
Notifications
You must be signed in to change notification settings - Fork 1
로그 시스템 제작기
Sangwon edited this page Dec 4, 2024
·
1 revision
앞선 5주간 디버깅 시 print()
와 Breakpoint를 주로 사용했습니다. 이 방법은 즉각적인 출력과 디버깅이 가능하다는 장점이 있지만, 단점도 존재합니다.
-
로그와 혼동 가능:
print()
로 출력된 메시지는 시스템 로그와 섞여 있어 중요한 정보를 놓칠 가능성이 큽니다. -
배포 시 위험성: 디버깅 후
print()
를 제거하지 않으면 배포된 앱에 잔존해 성능 저하 및 민감한 정보 노출 위험이 있습니다. - 구조화된 로그 부족: 출력 메시지가 일관성이 없고, 분류 및 분석이 어렵습니다.
마지막 주에 도입한 Logger는 이러한 문제를 해결하면서도 더 구조적이고 효율적인 디버깅 환경을 제공합니다.
- 구조화된 로그 관리: 로그 수준(Level)을 통해 메시지를 분류하고, 분석 가능성을 높입니다.
-
배포 안전성:
#if DEBUG
로 디버깅 환경에서만 활성화되므로 배포 버전에 영향을 미치지 않습니다. -
os.Logger
활용: 시스템 통합 로깅을 지원하며, Xcode 및 콘솔 앱에서 분석이 가능합니다.
Logger
는 다섯 가지 로그 수준을 제공합니다:
-
debug
: 개발 중 디버깅용 메시지 -
info
: 일반 정보 로그 -
warning
: 경고 메시지 -
error
: 심각한 오류 -
critical
: 치명적인 문제
Logger.debug("Debug message")
Logger.info("App started")
Logger.warning("Cache miss")
Logger.error("Failed to fetch data")
Logger.critical("Unrecoverable crash")
os.Logger
는 Apple의 고성능 로깅 시스템입니다. 각 메시지는 privacy
옵션을 통해 민감한 데이터를 보호하며, subsystem
과 category
로 로그를 구분합니다.
Logger
는 전달된 데이터를 문자열로 변환하여 읽기 쉬운 메시지를 생성합니다:
- 배열 →
[item1, item2]
- 딕셔너리 →
{key1: value1, key2: value2}
let data = ["name": "John", "age": 30]
Logger.debug("User data:", data)
출력:
[DEBUG] User data: {name: John, age: 30}
LogLevel
열거형을 통해 로그의 심각도를 분류하여 필요 시 특정 수준 이상의 메시지만 필터링할 수 있습니다.
enum LogLevel: String {
case debug = "DEBUG"
case info = "INFO"
case warning = "WARNING"
case error = "ERROR"
case critical = "CRITICAL"
}
print("Fetching data: \(data)")
- 시스템 로그와 섞여 확인이 어렵습니다.
- 민감한 데이터를 배포 환경에 노출할 위험이 있습니다.
Logger.debug("Fetching data:", data)
- 디버깅 환경에서만 활성화됩니다.
- 메시지 수준과 구분이 명확해졌습니다.
다음과 같이 사용하고 있습니다.
- 📒 기획의 과정과 의도
- 📒 swift6 도입기 ‐ @unchecked Sendable을 사용해야만 했던 이유
- 📒 WaveForm(파형) 제작기
- 📒 프로젝트 구조와 이유
- 📒 화면 전환(Game NavigationController)
- 📒 DIContainer를 사용한 계기
- 📒 AudioHelper 제작기
- 📒 음악 플레이어의 compact 버전 제작기
- 📒 Combine을 이용한 데이터 전달
- 📒 파이어베이스를 쓰며 있었던 일
- 📒 캐싱 모듈 구현과 문제점
- 📒 로그 시스템 제작기
- ❗ Data 끼리의 비교
- ❗ 프레임워크 Reference 안잡히는 문제
- ❗ actor 안에서 timer가 실행되지 않는 문제
- ❗ NSLayoutConstraint 옵셔널 문제
- ❗ 테이블 뷰가 보고 있는 배열과 bind하고 있는 배열 간의 race condition 문제
- ❗ 테스트끼리의 독립성
- ❗ 네트워크 테스팅 시 Error 핸들링
- ❗ 여러 클라이언트가 서버에 동시 요청시, 데이터가 반영이 안되는 이슈 해결
- ❗ 의존성 framework 추가시 불러오지 못하는 문제
- ❗ Timer를 6초 설정해도 더 실행되는 문제
- ❗ Music Kit Data Request 에러
- ❗ DI Container 에서 생성한 인스턴스가 동시에 존재 하는 이슈