조용한 개발 노트

보안 사고는 조용히 시작된다많은 보안 사고는 이렇게 발견된다.데이터가 이미 유출된 뒤권한이 오랫동안 오남용된 뒤외부 제보가 들어온 뒤이는 보안 장치가 없어서가 아니라, 보안 상태를 관측하지 못했기 때문이다.보안에서 가장 중요한 질문보안에서 가장 중요한 질문은 이것이다.지금 무슨 일이 벌어지고 있는가차단 규칙이나 암호화는 이 질문에 답하지 못한다.Observability는 보안 사고를 인지 가능하게 만드는 전제다.왜 보안 사고는 감지되지 않는가보안 사고가 감지되지 않는 이유는 단순하다.정상 트래픽과 구분되지 않는다부분적으로만 발생한다오랜 시간에 걸쳐 누적된다즉, 보안 사고는 시스템 장애처럼 보이지 않는다.보안 관점의 Observability는 무엇이 다른가일반적인 Observability는 성능과 안정성에..

10편에서 샘플링이 Observability의 성패를 좌우한다고 이야기했다. 그런데 샘플링까지 잘 설정했는데도, 여전히 이런 말을 듣게 되는 경우가 있다.“Trace는 보이는데, 그래서 뭐가 문제인지는 모르겠다.”이 단계에서의 문제는 도구가 아니다. 대부분 표현 방식과 해석 방식에 있다.문제 1. 이름이 의미를 전달하지 못한다Trace를 열었을 때 가장 먼저 보이는 것은 Span의 이름이다.그런데 이런 이름을 자주 보게 된다.method.invokeservice.callprocess기술적으로는 맞을 수 있다. 하지만 이 이름들만으로는 무슨 일이 일어났는지 설명할 수 없다.OpenTelemetry 공식 문서는 Span 이름이 “무엇을 했는지”를 한 문장으로 설명해야 한다고 강조한다.예를 들어:GET /or..

22편에서는 ApplicationContextInitializer를 통해 Bean 이전 단계에 개입하는 책임 경계를 정리했다.이번 글에서는 애플리케이션이 실행된 이후, 가장 오래 남고 가장 많이 참조되는 산출물, 바로 로그(logging)를 다룬다.로그는 단순한 출력이 아니다. 잘 설계되면 시스템을 설명하고, 잘못 설계되면 문제를 숨긴다.1) Spring Boot Logging의 기본 철학Spring Boot는 로깅을 “라이브러리 선택의 문제”로 보지 않는다.대신 다음 질문에 답하려고 한다. “애플리케이션은 어떤 형태로 자신의 상태를 외부에 설명해야 하는가?” 그래서 Spring Boot는 별도 설정 없이도 즉시 사용 가능한 로깅 기본값을 제공한다.이 기본값의 목적은 “최적화”가 아니라 일관성 있는 출발..

[gRPC 공식 문서 정리] Observability: Metrics, Logging, Tracing으로 무엇을 봐야 할까?이 글은 gRPC 공식 문서(Observability)와 OpenTelemetry 가이드를 기준으로, gRPC 서비스를 운영할 때 무엇을 관측해야 하는지, 그리고 어떤 신호가 실제 장애로 이어지는지를 실무 관점에서 정리한 글입니다. 기준 문서: https://grpc.io/docs/guides/observability/ https://opentelemetry.io/docs/instrumentation/java/ 📌 이 글은 gRPC 공식 문서 정리 시리즈의 일부입니다.(카테고리: Dev > gRPC)1. Observability는 선택이 아니라 전제다gRPC는 고성능 RPC 프..