관측 가능성은 로그를 많이 남기는 일이 아니라 질문에 답할 수 있게 만드는 일입니다

좋은 관측 가능성은 로그, 메트릭, 트레이스가 같은 요청을 설명하도록 연결됩니다.

언제부터 느려졌는지, 어떤 사용자에게만 생기는지, 어느 API에서 막히는지, 배포와 관련이 있는지.
관측 가능성은 이 질문에 답하기 위한 준비입니다.
로그를 많이 찍는다고 자동으로 답이 나오지는 않습니다.

로그는 사건을, 메트릭은 추세를, 트레이스는 경로를 봅니다

로그는 한 요청에서 무슨 일이 있었는지 보여줍니다.
메트릭은 에러율, 지연 시간, 큐 길이처럼 시간에 따른 변화를 보여줍니다.
트레이스는 하나의 요청이 여러 서비스와 DB를 지나간 경로를 보여줍니다.
셋 중 하나만 있으면 질문이 반쯤만 닫힙니다.

요청 ID 하나가 조사를 짧게 만듭니다

모든 로그에 request_id나 trace_id가 남으면 검색이 달라집니다.
사용자가 보낸 오류 시각과 ID를 기준으로 관련 로그를 모을 수 있고, 그 요청이 어느 내부 호출에서 느려졌는지 따라갈 수 있습니다.
관측 가능성의 첫걸음은 거창한 플랫폼보다 같은 요청을 같은 이름으로 부르는 일입니다.

미리 질문을 써두면 로그가 줄어듭니다

아무 로그나 많이 남기면 비용만 늘고 찾기도 어렵습니다.
“결제가 실패했을 때 원인이 사용자 입력인지, 외부 API인지, 내부 저장 실패인지 구분할 수 있는가”처럼 질문을 먼저 쓰면 필요한 필드가 보입니다.
관측 가능성은 기록 욕심이 아니라 디버깅 시간을 줄이는 설계입니다.

마지막으로 확인할 것은 하나입니다.
이 개념을 외웠는지가 아니라, 실패했을 때 어떤 상태가 남는지 설명할 수 있는지입니다.