Observability의 과거, 현재, 그리고 미래
Source: Hacker News
05 Jan, 2026
지난 글인 Round Two에서 저는 제 경력, 개발 도구에 대한 열정, 그리고 관측성(observability)에 초점을 맞춘 새로운 회사를 시작하기로 한 결정을 이야기했습니다.
또한 현재 존재하는 관측성에 대한 좌절감도 언급했죠. 왜 도구와 워크플로우가 이렇게 형편없을까요? 왜 이렇게 많은 작업이 필요한 것처럼 느껴질까요?
오늘 포스트에서는 그 좌절감을 역사적 맥락에서 풀어보고자 합니다. 관측성을 간단한 세 가지 관점—과거, 현재, 그리고 미래—으로 살펴보겠습니다.
제가 목표로 하는 바는 다음을 이해하고 설명하는 것입니다:
- 관측성이 처음 등장한 이유
- 관측성이 오늘날의 혼란스러운 상태로 진화한 과정
- 우리가 얼마나 많은 진전을 이루었음에도 불구하고 2026년 현재에도 신뢰할 수 있는 시스템을 유지하는 것이 왜 이렇게 어려운지
그럼 시작해볼까요!
Source: …
PART 1: OBSERVABILITY’S PAST
관측성을 이해하려면, 그것을 탄생시킨 환경을 살펴보는 것이 도움이 된다.
2010년대 초반, 소프트웨어 엔지니어들은 위기에 직면했다. 클라우드 컴퓨팅, 컨테이너, 마이크로서비스가 급증하면서 애플리케이션은 점점 복잡해졌고, 어느 한 개인도 전체를 완전히 이해하기 어려울 정도가 되었다.
동시에 CI/CD가 보편화되면서 프로덕션에 배포되는 변경 빈도가 증가했다. 그 결과, 버그와 장애가 더 자주 발생했다.
갑자기, 기존의 신뢰성 매뉴얼은 통하지 않게 되었다. 모든 엣지 케이스를 예측하거나 테스트를 작성하는 것이 불가능했다. 장애 모드는 서비스 간 복잡한 상호작용에서 점점 더 많이 나타났다. 근본 원인 분석을 할 때, 로그와 기본 메트릭만으로는 충분하지 않았다.
다행히 업계는 해결책을 찾았다. 두 가지 요소—도구와 철학—로 구성된 접근법이었다.
도구: Distributed tracing
2010년에 조용히 시작된 Distributed tracing은 이후 10년 동안 꾸준히 성장해 사실상 어디서든 사용되는 수준이 되었다:
- 2010 – Google이 Dapper를 발표, Distributed tracing에 관한 최초의 주요 논문.
- 2012 – Twitter가 Dapper에 영감을 받아 Zipkin을 도입.
- 2015 – Honeycomb이 설립, 최초의 관리형 tracing 플랫폼 중 하나.
- 2016 – OpenTracing이 CNCF에 채택.
- 2016 – Uber가 Zipkin에 영감을 받아 Jaeger를 도입.
- 2017 – Datadog이 관리형 tracing 솔루션인 APM을 출시.
- 2018 – O’Reilly가 Distributed Systems Observability를 출판.
철학: Observability
1960년대 로켓 과학자가 처음 만든 용어인 “observability”는 2010년대 초 Twitter 엔지니어링 팀에 의해 소프트웨어 커뮤니티에 널리 알려졌다. 이후 빠르게 완전한 제품 카테고리와 엔지니어링 분야로 성장했다:
- 2013 – Twitter가 “Observability at Twitter”를 발표.
- 2015 – Honeycomb 창립자 Charity Majors가 관측성에 관한 글을 쓰기 시작하며 핵심 개념을 정립.
- 2017 – Prometheus에 기여한 SoundCloud 엔지니어 Peter Bourgon이 “Three Pillars”를 제시.
- 2022 – O’Reilly가 Observability Engineering를 출판.
요약하면, Distributed tracing은 엔지니어에게 현대 클라우드‑네이티브 애플리케이션을 디버깅할 방법을 제공했고, Observability는 새로운 운영 환경에서 신뢰성을 생각하는 프레임워크를 제공했다.
내가 강조하고 싶은 점은 관측성이 진공 속에서 탄생한 것이 아니라, 실제 엔지니어링 문제에 대한 대응으로 등장했고, 대부분 효과가 있었기 때문에 지속되었다는 것이다.
하지만 상황은 악화되기 시작했다. 초기 성공에 고무된 엔지니어링 팀들은 관측성 도구와 프로세스에 과도하게 투자하기 시작했다:
- 더 많은 계측
- 더 많은 대시보드
- 더 많은 모니터, SLO, 에러 예산
- 런북, 포스트모템
2020년대 초가 되자, 관측성은 목적을 위한 수단이 아니라 그 자체가 목적이 되어 버렸다.
PART 2: 관측성의 현재
오늘날 대부분의 엔지니어는 동의합니다: 관측성은 기본 조건입니다. 거의 모든 규모의 프로덕션 시스템을 운영한다면, 문제가 발생했을 때 이를 감지하고, 완화하며, 해결할 수 있는 방법이 필요합니다.
이것이 Datadog, Grafana, Sentry와 같은 현대 관측성 플랫폼의 역할입니다.
그런데 현재 관측성 상태를 생각해볼 때, 한 가지 질문이 눈에 띕니다: 10년 넘게 더 나은 도구와 프로세스에 투자했음에도 불구하고, 왜 관측성은 여전히 형편없을까? 진심입니다!
증상
- 계측에 시간이 너무 오래 걸립니다.
- 대시보드가 계속해서 최신 상태가 아닙니다.
- 모니터가 오작동합니다.
- 알림에 컨텍스트가 부족합니다.
- 온콜은 엔지니어링 생산성에 지속적인 세금과 같습니다.
- 사고 해결에 몇 시간, 때로는 며칠이 걸립니다.
우리는 그 어느 때보다 많은 텔레메트리를 가지고 있지만, 프로덕션에서 애플리케이션의 정확한 정신 모델을 만드는 것은 여전히 큰 도전입니다. 이는 신입 개발자와 “바이브 코딩” 줌 세대뿐 아니라 경험 많은 엔지니어에게도 해당됩니다.
노력이 부족해서가 아닙니다. 모든 규모의 기업이 관측성을 진지하게 여기며, 관측성 시스템을 구현하고 유지하는 데 막대한 시간과 에너지를 투자합니다:
- Datadog에 비용을 지불합니다.
- 모든 것을 계측합니다.
- 구조화된 로깅을 채택하고 표준화된 명명/라벨링 규칙을 강제합니다.
- “골든” 대시보드를 만듭니다.
- 모니터를 꼼꼼히 튜닝합니다.
합리적인 정의에 따르면, 이 팀들은 모든 것을 제대로 하고 있습니다.
격차
우리가 관측성에 투입한 노력은 목표 달성—더 나은 감지, 더 빠른 근본 원인 분석, 더 신뢰할 수 있는 애플리케이션—과 일치하지 않습니다.
왜일까요? 실제 문제는 데이터, 도구, 프로세스가 아니라, 우리가 이미 가지고 있는 데이터를 이해하고 추론하는 능력—또는 그 부족—에 있습니다.
관측성은 우리를 신호를 생성하는 데 매우 능숙하게 만들었지만, 그 다음 단계인 신호 해석, 인사이트 도출, 그리고 그 인사이트를 신뢰성으로 전환하는 데는 그다지 개선되지 못했습니다.
PART 3: 관측성의 미래
관측성이 기대에 미치지 못하고 있다는 것은 사실입니다. 하지만 그렇다고 해서 그것이 유용하거나 중요하지 않다는 뜻은 아닙니다. 사실 저는 관측성이 다가오는 10년 동안 가장 중요한 기술 분야 중 하나가 될 것이라고 믿습니다.
… (미래 섹션의 나머지 부분이 계속됩니다)
정리된 마크다운 세그먼트의 끝.
이유
2010년대에 가시성(observability) 은 복잡성에 대한 해독제로 등장했습니다. 2026년, 소프트웨어 엔지니어들은 이제까지 겪어본 가장 큰 복잡성 위기인 AI에 직면하고 있습니다.
AI는 코드를 작성하는 비용을 제로로 낮추고 있습니다. 그 결과, 엔지니어링 팀은 눈부신 속도로 방대한 양의 기능을 배포하고 있으며, 코드베이스는 점점 커지고 있습니다.
한편, vibe‑coding 플랫폼은 소프트웨어 개발을 대중에게 확산시켰습니다. 올해만 해도 이전 모든 연도를 합친 것보다 더 많은 앱이 구축되고 배포될 것입니다.
우리는 무한 소프트웨어 위기의 직전에 있습니다.
이는 불편한 질문을 제기합니다: 이렇게 끊임없이 커져가는 소프트웨어 산을 어떻게 지원하고, 유지하며, 운영할 것인가? 저는 답이 가시성일 것이라고 확신합니다—하지만 오늘날 우리가 가지고 있는 버전은 아닐 겁니다…