글이 읽기 어렵고 AI가 도운 듯한 느낌이 있었음. 그래도 메시지는 가치 있었고, 좀 더 간결했으면 좋았을 것 같음
최근 생각한 점은 다음과 같음.
스택 전반에 인증이 있으므로 모든 로그 라인에 user id를 포함하기 시작했음. 덕분에 사용자가 겪은 경험을 전체적으로 보기 쉬워졌음
에러를 요청 로그와 별도 라인으로 기록하는 건 번거로움. trace로 필터링할 수는 있지만 “5xx 요청과 관련된 에러만 보여줘” 같은 쿼리를 만들기 어려움
이런 컨텍스트를 추가하는 것만으로는 부족하고, 동료들에게도 새 필드가 생겼음을 교육해야 함. 몰라서 스스로 고생하는 경우를 많이 봤음
더 나은 tracing 도구에 투자하면 단순 로그로는 불가능한 수준의 디버깅이 가능해짐. user id를 trace로 쓰는 개념을 확장한 셈임
코드베이스에 request ID 개념이 있다면, 그걸로도 사용자의 행동을 더 구체적으로 추적할 수 있음
TID를 서비스 전반에 강제 적용하면, 어떤 팀이든 TID 하나로 전체 트랜잭션을 추적할 수 있음
이런 “AI 냄새 난다”는 식의 댓글은 곧 비판받는 문화가 될 것 같음
이 주제라면 Charity Majors를 언급하지 않을 수 없음. 그녀는 “wide events”와 “observability” 개념을 10년 넘게 전파했고, Honeycomb.io를 그 철학 위에 세웠음.
요즘은 다양한 도구로 이 방식을 구현할 수 있음. structured logs나 traces를 활용해 wide event를 캡처하고, 시계열·히스토그램 등 시각화가 풍부한 툴을 쓰는 게 중요함
다만 “observability”라는 용어 자체를 그녀가 만든 건 아님. 이미 여러 분야에서 수십 년 전부터 쓰이던 개념임. 그녀는 영향력 있는 실무자이지만, 용어의 창시자는 아님
그녀의 블로그와 Honeycomb의 배경 이야기는 업계 종사자라면 꼭 읽어볼 만함. 이 접근법의 가치를 처음 인식한 팀이었음
글이 그녀의 스타일과 너무 닮아서, 마지막에 Honeycomb 광고가 나올 줄 알았는데 아니어서 놀랐음
.NET 생태계에서는 Nick Blumhardt가 “structured logging”을 오래전부터 다뤘고, Seq와 Serilog가 이를 지원했음
그녀의 콘텐츠는 좋지만, “observability”를 브랜드화한 사람은 없음. 존중은 하되 과장된 주장은 피해야 함
글의 주장에 일부 동의하지만, 단일 wide event만 남기는 방식에는 함정이 있음. 요청 중간에 예외나 타임아웃이 발생하면 아무것도 남지 않음.
언어의 기본 로깅 프레임워크나 의존성 로그도 놓치게 됨.
그래서 이건 기존 로그 위에 덧씌우는 추가 레이어로 쓰는 게 좋음. request/session 단위 ID를 두고 ClickHouse 같은 곳에서 집계하면 됨
중간 계층의 가시성이 문제라면, 이벤트가 충분히 wide하지 않은 것임. log.error(data)나 wide_event.attach(error, data) 모두 본질은 같음
“connection X:Y accepted at Z ns”와 “closed at Z ns” 같은 로그는 느린 시스템 디버깅에 매우 유용함
나는 PHP 프레임워크에서 LoggerInterface를 만들어 해결했음. 예외를 전역 핸들러로 잡아 DB에 wide 형태로 저장함. 약간의 보일러플레이트가 있지만 너무 잘 작동해서 이제는 없으면 불편함
프레젠테이션과 인터랙티브 예시가 훌륭했음. 하지만 결국 “로그에 구조화된 태그를 추가하라”는 이야기로 요약됨.
wide log는 복잡성과 가독성 저하에 비해 얻는 이득이 크지 않다고 느낌.
단순히 grep "uid=user-123" application.log로 충분한데, 굳이 사용자 배송 방법까지 붙일 필요가 있을까 싶음.
(참고로 Android Brave 브라우저에서는 체크박스가 작동하지 않았음)
JSON 로그라면 여전히 grep '"uid": "user-123"'로 검색 가능함. --context 옵션으로 주변 라인도 볼 수 있음
반도체 제조 환경에서 수천 개의 메시지 버스 참가자가 있는 시스템을 다뤘음. 시간당 300~400MB 로그가 나왔지만, grep과 CLI 도구만으로도 충분히 관리했음.
로그는 단순히 이벤트의 시계열일 뿐, 세부 분석은 Oracle 쿼리로 처리했음. 로그는 사건의 인과관계를 파악하는 데 쓰는 도구임
로그는 타임라인 파악용이지, 요청·응답의 모든 데이터를 담는 용도가 아님. 너무 많은 정보를 넣으면 오히려 이해가 어려워짐.
로그는 “언제, 무엇이 일어났는가”를 말하고, “왜”는 코드와 데이터, 이벤트의 조합에서 찾는 것임
개인적으로 ELK 스택 같은 인터페이스는 직관적 탐색에 불편함. 로그는 직감적으로 따라가며 읽는 게 중요함
시간당 400MB 로그는 사실 많지 않음. 그래서 단순 grep으로도 충분히 처리 가능함
글 마지막의 “모든 에러·예외·느린 요청을 로그하라”는 조언은 위험한 발상임.
예를 들어 의존성이 느려지면 로그량이 100배로 폭증할 수 있음.
장애 상황에서는 서비스가 더 적은 일을 해야 복구가 쉬운데, 로그 폭증은 오히려 연쇄 장애를 유발함
Cloudflare에서는 적응형 샘플링을 씀. 로그 배치를 필드별로 버킷화하고, 각 버킷에서 입력 로그 수의 제곱근 혹은 로그값만 남김.
로그량이 많을수록 샘플링 비율이 자동으로 조정되어 시스템이 과부하되지 않음
이런 매직 임계값은 위험함. P(99) 같은 수치는 동적으로 갱신되어야 함. OTEL provider에서 주기적으로 실제 값을 가져오면 안전함
프로덕션 서비스는 로그 수집이 수요에 맞게 확장되도록 설계해야 함. 로컬 디스크 버퍼링만으로도 큰 도움이 됨
고트래픽 서비스라면 trace_id mod 100 == 0 같은 방식으로 건강한 요청만 샘플링하면 됨
로그가 병목이 된다면 시스템 설계가 잘못된 것임. 효율적인 로깅은 초당 수억 건도 처리 가능함
현대 소프트웨어에서는 단일 로그로 “무슨 일이 일어났는가”를 완전히 설명하기 어려움.
그래서 수직적 상관관계(Vertical correlation) 와 수평적 상관관계(Horizontal correlation) 가 필요함.
스택 내 상하 계층 간에는 동일한 correlation 값을 공유해야 하고, 시스템 간 통신 시에는 피어 간 correlation이 필요함.
이런 값을 API나 프로토콜에 추가하는 건 어렵지만, 트랜잭션 ID를 미리 설계해두면 전체 추적이 가능함
단일 글을 위해 도메인을 따로 등록하는 건 지속성이 낮다고 생각함.
매년 갱신비를 내야 하므로, 개인 블로그나 서브도메인을 쓰는 게 낫다고 봄.
예를 들어 logging-sucks.boristane.com 같은 형태가 좋음
사실 이 도메인과 글은 저자의 observability SaaS 홍보용임. Cloudflare 계정이 필요하지만 무료라서 장기적인 마케팅 전략 같음. 그래도 유익했고, 나도 CF 계정이 있어 써볼 생각임
이건 블로그 글이라기보다 디지털 마케팅용 리드 생성 페이지에 가까움. 서비스 홍보가 명확함
“로그는 모놀리식 시대의 유물”이라는 주장에 대해, 나는 로컬 로그는 여전히 유효하다고 생각함.
로컬 프로세스의 대화를 기록하는 게 본래 역할이며, 다른 서버의 상황을 파악하려면 트랜잭션 트레이싱이 필요함.
적절한 위치의 로그만 봐도 근본 원인에 도달할 수 있음
다만 로그는 단순한 원인 분석용이 아니라, 누가 영향을 받았는지, 성능과 입력 간의 상관관계, 보안 취약점의 영향 등 비즈니스 인사이트를 주기도 함.
풍부한 컨텍스트가 있는 로그는 분석 엔진과 결합해 제품 개선에도 활용 가능함
“요청이 15개 서비스와 3개 DB를 거친다”는 말에, 그런 복잡성을 지양해야 한다는 반응도 있었음
나는 APN/Kibana만으로도 로그 분석에 충분하다고 느낌
“코드가 하는 일 대신, 요청에 무슨 일이 일어났는지를 로그하라”는 말에는 동의하지만, 저자가 경험이 부족해 보였음.
나는 이를 “bug parts logging” 이라 부르며, 처리 경로·횟수·시간 같은 전조 신호를 포함해야 한다고 생각함.
로깅은 메트릭이나 감사(audit)와 다름. 로깅이 실패해도 처리는 계속되어야 하지만, 감사 실패는 치명적임.
SCADA 시스템의 “historian” 개념처럼, 관찰(observables) 과 평가(evaluatives) 를 구분해야 함.
예를 들어 연료 센서의 세밀한 이벤트는 진단에는 유용하지만, “목적지까지 갈 수 있는가”라는 질문에는 불필요함.
결국 중요한 건 무엇을 관찰하고, 무엇을 평가할 것인가를 명확히 하는 것임
나는 “관측성의 통합 이론”을 지지함. 로그·메트릭·감사는 모두 비트 스트림일 뿐이며, 손실 없이 변환 가능함.
저장·변환·조회 방식은 달라도, 소비 지점과 메커니즘은 동일하게 설계할 수 있음.
이렇게 하면 시스템 설계가 단순해지고, 장기 보관된 로그를 나중에 재처리할 수도 있음
Hacker News 의견들
글이 읽기 어렵고 AI가 도운 듯한 느낌이 있었음. 그래도 메시지는 가치 있었고, 좀 더 간결했으면 좋았을 것 같음
최근 생각한 점은 다음과 같음.
이 주제라면 Charity Majors를 언급하지 않을 수 없음. 그녀는 “wide events”와 “observability” 개념을 10년 넘게 전파했고, Honeycomb.io를 그 철학 위에 세웠음.
요즘은 다양한 도구로 이 방식을 구현할 수 있음. structured logs나 traces를 활용해 wide event를 캡처하고, 시계열·히스토그램 등 시각화가 풍부한 툴을 쓰는 게 중요함
글의 주장에 일부 동의하지만, 단일 wide event만 남기는 방식에는 함정이 있음. 요청 중간에 예외나 타임아웃이 발생하면 아무것도 남지 않음.
언어의 기본 로깅 프레임워크나 의존성 로그도 놓치게 됨.
그래서 이건 기존 로그 위에 덧씌우는 추가 레이어로 쓰는 게 좋음. request/session 단위 ID를 두고 ClickHouse 같은 곳에서 집계하면 됨
프레젠테이션과 인터랙티브 예시가 훌륭했음. 하지만 결국 “로그에 구조화된 태그를 추가하라”는 이야기로 요약됨.
wide log는 복잡성과 가독성 저하에 비해 얻는 이득이 크지 않다고 느낌.
단순히
grep "uid=user-123" application.log로 충분한데, 굳이 사용자 배송 방법까지 붙일 필요가 있을까 싶음.(참고로 Android Brave 브라우저에서는 체크박스가 작동하지 않았음)
grep '"uid": "user-123"'로 검색 가능함.--context옵션으로 주변 라인도 볼 수 있음반도체 제조 환경에서 수천 개의 메시지 버스 참가자가 있는 시스템을 다뤘음. 시간당 300~400MB 로그가 나왔지만, grep과 CLI 도구만으로도 충분히 관리했음.
로그는 단순히 이벤트의 시계열일 뿐, 세부 분석은 Oracle 쿼리로 처리했음. 로그는 사건의 인과관계를 파악하는 데 쓰는 도구임
로그는 “언제, 무엇이 일어났는가”를 말하고, “왜”는 코드와 데이터, 이벤트의 조합에서 찾는 것임
개인적으로 ELK 스택 같은 인터페이스는 직관적 탐색에 불편함. 로그는 직감적으로 따라가며 읽는 게 중요함
글 마지막의 “모든 에러·예외·느린 요청을 로그하라”는 조언은 위험한 발상임.
예를 들어 의존성이 느려지면 로그량이 100배로 폭증할 수 있음.
장애 상황에서는 서비스가 더 적은 일을 해야 복구가 쉬운데, 로그 폭증은 오히려 연쇄 장애를 유발함
로그량이 많을수록 샘플링 비율이 자동으로 조정되어 시스템이 과부하되지 않음
현대 소프트웨어에서는 단일 로그로 “무슨 일이 일어났는가”를 완전히 설명하기 어려움.
그래서 수직적 상관관계(Vertical correlation) 와 수평적 상관관계(Horizontal correlation) 가 필요함.
스택 내 상하 계층 간에는 동일한 correlation 값을 공유해야 하고, 시스템 간 통신 시에는 피어 간 correlation이 필요함.
이런 값을 API나 프로토콜에 추가하는 건 어렵지만, 트랜잭션 ID를 미리 설계해두면 전체 추적이 가능함
단일 글을 위해 도메인을 따로 등록하는 건 지속성이 낮다고 생각함.
매년 갱신비를 내야 하므로, 개인 블로그나 서브도메인을 쓰는 게 낫다고 봄.
예를 들어 logging-sucks.boristane.com 같은 형태가 좋음
“로그는 모놀리식 시대의 유물”이라는 주장에 대해, 나는 로컬 로그는 여전히 유효하다고 생각함.
로컬 프로세스의 대화를 기록하는 게 본래 역할이며, 다른 서버의 상황을 파악하려면 트랜잭션 트레이싱이 필요함.
적절한 위치의 로그만 봐도 근본 원인에 도달할 수 있음
풍부한 컨텍스트가 있는 로그는 분석 엔진과 결합해 제품 개선에도 활용 가능함
“코드가 하는 일 대신, 요청에 무슨 일이 일어났는지를 로그하라”는 말에는 동의하지만, 저자가 경험이 부족해 보였음.
나는 이를 “bug parts logging” 이라 부르며, 처리 경로·횟수·시간 같은 전조 신호를 포함해야 한다고 생각함.
로깅은 메트릭이나 감사(audit)와 다름. 로깅이 실패해도 처리는 계속되어야 하지만, 감사 실패는 치명적임.
SCADA 시스템의 “historian” 개념처럼, 관찰(observables) 과 평가(evaluatives) 를 구분해야 함.
예를 들어 연료 센서의 세밀한 이벤트는 진단에는 유용하지만, “목적지까지 갈 수 있는가”라는 질문에는 불필요함.
결국 중요한 건 무엇을 관찰하고, 무엇을 평가할 것인가를 명확히 하는 것임
저장·변환·조회 방식은 달라도, 소비 지점과 메커니즘은 동일하게 설계할 수 있음.
이렇게 하면 시스템 설계가 단순해지고, 장기 보관된 로그를 나중에 재처리할 수도 있음