솔직히 말해봅시다.
여러분 팀의 Datadog 청구서, 안녕하십니까?
매달 수천만 원, 아니 억 단위가 찍히는데 정작 장애가 터지면 어떤가요.
화려한 대시보드는 빨간불만 깜빡이고, 정작 원인을 찾느라 새벽 3시에 로그 뒤지느라 바쁘죠.
"우린 옵저버빌리티(Observability)가 갖춰져 있어"라고 자위하지만,
현실은 그저 비싼 쓰레기 데이터를 쌓아두고 있을 뿐입니다.
최근 실리콘밸리에서 화제가 된 Sherwood Callaway의 글, 'Observability의 과거, 현재, 그리고 미래'를 보며 무릎을 쳤습니다.
이 글은 2026년 시점에서 쓴 '가상의 회고' 형식을 띠고 있지만,
제가 넷플릭스에서 매일 겪는 이 '고통스러운 현실'을 너무나 정확하게 찌르고 있거든요.
도대체 우리는 어디서부터 잘못된 걸까요?
1. 과거: 우리가 '분산 추적'에 미쳤던 이유
2010년대 초반, 우리는 MSA(마이크로서비스)라는 판도라의 상자를 열었습니다.
모놀리식(Monolithic) 시절엔 으로 로그만 긁어도 범인을 잡았습니다.
하지만 서비스가 수백 개로 쪼개지니, 요청 하나가 어디서 죽었는지 아무도 모르는 지경이 됐죠.
그래서 등장한 구세주가 분산 추적(Distributed Tracing)이었습니다.
구글의 Dapper, 트위터의 Zipkin...
"야, 이거면 다 보인다!"라며 환호했습니다.
우리는 엔지니어링의 신뢰성을 지키기 위해 '3개의 기둥(Three Pillars)'을 세웠습니다.
Metrics, Logs, Traces.
이때까진 좋았습니다. 문제는 그 다음이었습니다.
수단이 목적이 되어버렸거든요.
2. 현재: 계측(Instrumentation)의 늪
지금 여러분의 상황을 볼까요?
모든 것에 태그를 붙입니다. 모든 에러를 수집합니다.
SLO(서비스 수준 목표)를 설정하고, Error Budget을 계산하고, 멋진 포스트모텀(Postmortem) 문서를 씁니다.
그런데 왜 여전히 On-call(대기 당직)은 지옥 같을까요?
저자는 뼈 때리는 말을 던집니다.
"우리는 신호(Signal)를 만드는 데만 능숙해졌지, 그걸 해석하는 능력은 제자리걸음이다."
대시보드는 배포 한 번 하면 낡은 정보가 되고,
알람(Alert)은 맥락 없이 울려대서 엔지니어들을 양치기 소년 취급하게 만듭니다.
신입 엔지니어나, 요즘 유행하는 'Vibe-coding(AI로 대충 코딩하는)' 개발자들은 시스템의 전체 그림을 전혀 그리지 못합니다.
데이터는 넘쳐나는데, 정작 '정신 모델(Mental Model)'은 빈약한 상태.
이게 바로 우리가 수억 원을 쓰고도 장애 해결에 몇 시간이 걸리는 이유입니다.
3. 미래: 무한 소프트웨어 위기 (Infinite Software Crisis)
그럼 이대로 망하는 걸까요?
아뇨, 상황은 더 심각해집니다. 바로 AI 때문입니다.
이제 코드를 짜는 비용(Cost of Code)은 '0'에 수렴하고 있습니다.
주니어 개발자도, 심지어 개발자가 아닌 사람도 AI를 통해 엄청난 양의 기능을 쏟아냅니다.
코드베이스는 폭발적으로 커지고, 배포 속도는 인간의 인지 능력을 넘어설 겁니다.
저자는 이것을 "무한 소프트웨어 위기"라고 부릅니다.
이 거대한 쓰레기... 아니, 소프트웨어의 산을 누가 운영할까요?
결국 다시 옵저버빌리티입니다.
하지만 지금처럼 사람이 일일이 대시보드 보고 앉아있는 방식은 아닙니다.
결론: 살고 싶다면 '해석'에 집중하세요
제가 후배들에게 항상 하는 말이 있습니다.
"대시보드 예쁘게 꾸밀 시간에, RCA(근본 원인 분석)를 자동화할 방법을 고민해라."
앞으로의 옵저버빌리티는 '수집'이 아니라 '이해'의 영역이 될 겁니다.
단순히 "CPU가 튀었습니다"라고 말해주는 도구는 이제 필요 없습니다.
"김대리가 어제 커밋한 코드 중 34번째 줄 때문에 결제 모듈 지연이 발생했습니다"라고 말해주는 도구가 살아남겠죠.
여러분의 인생 가용성(Availability)을 0%로 만들고 싶지 않다면,
지금 당장 무의미한 그래프 그리기를 멈추세요.
데이터를 쌓는 게 아니라, 데이터가 말을 하게 만들어야 합니다.
그게 우리가 다가올 'AI 코드 홍수'에서 익사하지 않고 살아남는 유일한 방법입니다.
