관찰 가능성(Observability)의 세 축은 무엇인가요?

관찰 가능성의 세 축은 로그, 메트릭, 트레이스입니다. 로그는 사건 맥락, 메트릭은 수치 추세, 트레이스는 분산 요청 경로를 보여줍니다.

핵심 개념

핵심 기준은 로그, 메트릭, 트레이스의 역할입니다.

Observability는 시스템 내부 상태를 외부 출력만으로 이해할 수 있는 능력입니다. 로그는 개별 사건의 상세 맥락, 메트릭은 시간에 따른 수치 추세, 트레이스는 여러 서비스에 걸친 한 요청의 경로와 병목을 보여줍니다. 세 가지를 trace id로 연결하면 장애 분석이 빨라집니다.

동작 흐름

1. 요구사항을 성능, 안정성, 보안, 복구 목표로 나눠 정의합니다.
2. 정상 흐름과 장애 흐름에서 각 구성 요소가 어떻게 동작하는지 확인합니다.
3. 자동화와 관찰 지표로 변경 결과를 검증합니다.
4. 롤백, 복구, 확장, 비용 관리까지 운영 절차로 문서화합니다.

실제 예시

{ "level": "error", "traceId": "abc-123", "message": "payment failed" }

metric: http_server_duration_seconds{route="/orders",status="500"}

예시는 핵심 구조를 단순화한 것입니다. 실무에서는 운영 환경, 장애 상황, 보안 요구사항에 맞게 세부 설정을 조정해야 합니다.

실무에서 주의할 점

• 자동화가 있어도 롤백과 복구 절차를 실제로 연습하지 않으면 장애 때 동작하지 않을 수 있습니다.
• 관찰 지표가 없으면 장애 원인을 추측에 의존하게 됩니다.
• 확장은 애플리케이션 코드, 데이터베이스, 네트워크, 외부 의존성 한계를 함께 봐야 합니다.

함께 연결해서 보면 좋은 키워드

Observability, Log, Metric, Trace

면접에서 짚으면 좋은 포인트

• 정상 동작뿐 아니라 장애, 롤백, 관찰 가능성까지 함께 설명하면 실무적인 답변이 됩니다.
• 설정 예시를 말할 때 보안, 비용, 운영 자동화의 trade-off도 함께 짚는 것이 좋습니다.

정리

한 줄로 정리하면, 관찰 가능성의 세 축은 로그, 메트릭, 트레이스입니다. 로그는 사건 맥락, 메트릭은 수치 추세, 트레이스는 분산 요청 경로를 보여줍니다. 개념의 정의뿐 아니라 장애 시 동작, 운영 지표, 자동화와 복구 전략까지 함께 이해하는 것이 중요합니다.