1.5 데이터 출처와 계측

개요 및 동기

메트릭은 그 아래에 있는 데이터만큼만 신뢰할 수 있으며, 대부분의 메트릭 프로그램은 그것을 공급하는 파이프라인을 검증하는 것보다 대시보드를 설계하는 데 훨씬 더 많은 노력을 쏟는다. 이것은 거꾸로 되어 있다. 일관성 없고, 자가 보고되거나, 조용히 고장 난 계측 위에 아름답게 설계된 차트는 아무 차트도 없는 것보다 더 나쁜데, 틀렸으면서도 권위 있어 보이기 때문이다. 이 주제는 이 책의 나머지가 전제하는 화려하지 않은 기초를 다룬다: 엔지니어링 데이터는 실제로 어디서 오는가, 언제 자가 보고보다 자동화된 계측을 신뢰해야 하는가, 그리고 아무도 알아채기 전에 메트릭을 조용히 무효화시키는 데이터 품질 실패는 무엇인가.

소프트웨어 공학 데이터는 소수의 출처 유형에서 나오며, 각각 서로 다른 신뢰성 특성을 지닌다. 버전 관리와 CI/CD 파이프라인은 실제로 일어난 일에 대한 객관적이고, 타임스탬프가 찍히며, 조작하기 어려운 기록을 생성한다. 이슈 트래커와 프로젝트 관리 도구는 사람이 상태를 정확하고 신속하게 갱신하는 데 의존하는 기록을 생성하며, 사람들은 흔히 이를 일관성 없이 한다. 설문 조사는 만족도처럼 어떤 시스템도 관측할 수 없는 것에 대해 매우 귀중한 자가 보고 데이터를 생성하지만, 회상 편향과 사회적 바람직성 효과의 대상이 된다. 관측 가능성 플랫폼은 객관적이지만 계측된 것만 다루는 시스템 수준의 텔레메트리를 생성한다. 주어진 메트릭의 데이터가 어느 범주에서 오는지 아는 것은 그것을 얼마나 신뢰해야 하는지와 어떤 실패 양상을 경계해야 하는지를 알려준다.

엔터프라이즈와 정부 규모에서는 데이터 품질 문제가 복합적으로 커지는데, 데이터의 근원과 대시보드에서의 최종 사용 사이의 거리가 여러 시스템, 통합, 변환을 거치며 자라기 때문이다. 원본 시스템에서 한 가지를 의미하는 필드가 보고 계층에 도달할 때쯤에는 미묘하게 다른 무언가를 의미할 수 있으며, 수치가 여전히 그럴듯해 보이기 때문에 하류의 아무도 알아채지 못한다. 계측을 올바르게 하는 것은 프레임워크를 올바르게 하는 것보다 덜 흥미롭지만, 이 책의 나머지 모든 것이 그 위에 서 있는 기초다.

핵심 원칙

시스템이 사건을 직접 관측할 수 있는 곳이라면 어디든 자가 보고보다 계측을 선호하라. 파이프라인에서 나온 배포 타임스탬프는 팀의 자가 보고된 배포 수보다 더 신뢰할 수 있다.
직접 관측할 수 없는 것에 대해서만 자가 보고를 사용하라. 만족도, 지각된 마찰, 그리고 웰빙에는 기록 시스템의 대체물이 없다. 직접 물어보고 설문을 잘 설계하라(주제 3.7). 자가 보고는 특히 그 범주만을 위해 남겨 두라.
모든 메트릭의 데이터에는 출처 시스템, 수집 방법, 그리고 알려진 실패 양상이 있다. 정의뿐 아니라 이 세 가지 모두를 문서화하라.
데이터 품질은 조용히 부패한다. 1년 전에 올바르게 작동했던 파이프라인이 오늘 조용히 고장 나 있을 수 있으며, 대시보드는 불평 없이 계속 잘못된 수치를 렌더링할 것이다.
변환의 하류가 아니라 진실의 지점에서 계측하라. 사건과 대시보드 사이의 모든 홉은 의미가 드리프트할 기회다.

권장 사항

신뢰하기 전에 모든 메트릭을 그 실제 출처 시스템에 매핑하라

대시보드의 각 메트릭에 대해, 근본적인 사건을 생성하는 특정 시스템의 이름을 대라: 배포 사건을 위한 CI/CD 파이프라인, 커밋과 병합 사건을 위한 버전 관리 호스트, 장애 기록을 위한 인시던트 트래커, 자가 보고된 만족도를 위한 설문 플랫폼. 정확한 시스템의 이름을 댈 수 없다면, 당신은 수치가 실제로 어디서 오는지 알지 못하는 것이며, 그 신뢰성을 평가할 수 없다. 이 매핑은 별도의 연습이 아니라 주제 1.4의 거버넌스 헌장을 위한 전제 조건이다.

보고 시점이 아니라 사건 시점에서 계측하라

가장 신뢰할 수 있는 데이터는 사건이 일어나는 순간 자동으로 그것을 포착한다: 파이프라인은 배포가 완료되는 순간 그것을 기록하고, 버전 관리 시스템은 병합이 이루어지는 순간 그것을 기록한다. 사람이 나중에 상태 필드를 갱신하는 것을 기억하는 데 의존하는 데이터, 티켓을 “완료”로 표시하거나 스프레드시트에 수동으로 배포를 기록하는 것은, 실제 사건으로부터 멀리 앉아 있을수록 그리고 책임자가 바빠질수록 정확도가 저하된다. 자동화된 사건이 존재하는 곳이라면 어디든 같은 사실에 대한 사람이 보고하는 대리 지표보다 그것을 선호하라.

사람만이 알려줄 수 있는 것에는 설문 조사를 남겨 두라

어떤 것들은 진정으로 시스템 텔레메트리로부터 관측될 수 없다: 엔지니어가 자신의 작업이 의미 있다고 느끼는지, 어떤 절차가 좌절스럽게 느껴지는지, 번아웃 위험이 높아지고 있는지. 이러한 것들은 직접 물어보는 것을 필요로 하며, 잘 설계된 설문 조사(주제 3.7이 그 메커니즘을 다룬다)가 올바른 도구다. 실수는 대신 시스템이 직접 관측할 수 있는 것에 자가 보고를 사용하는 것이다. 파이프라인에서 끌어오는 대신 엔지니어에게 자신의 배포 빈도를 추정하도록 묻는 것은 객관적일 수 있었던 데이터에 불필요한 잡음과 편향을 도입한다.

파이프라인 자체에 데이터 품질 검사를 내장하라

메트릭 파이프라인을 프로덕션 코드와 동일한 엄격함으로 다루라: 출처가 데이터 전송을 멈출 때, 필드의 분포가 예상치 못하게 변할 때, 혹은 개수가 예상치 못하게 0으로 떨어질 때 이를 알리는 자동화된 검사를 추가하라. 오래되거나 고장 난 데이터를 마치 최신인 것처럼 조용히 렌더링하는 대시보드는 “데이터 이용 불가”를 눈에 띄게 보여 주는 대시보드보다 더 나쁜데, 전자는 신뢰를 보이지 않게 침식시키는 반면 후자는 적어도 자신의 한계에 대해 진실을 말하기 때문이다.

정의와 함께 수집 방법을 문서화하라

메트릭의 정의(“변경에 대한 리드 타임”)는 그 수집 방법(버전 관리의 첫 커밋 타임스탬프부터 파이프라인의 프로덕션 배포 타임스탬프까지 측정하며, 핫픽스 브랜치는 제외) 없이는 완전하지 않다. 같은 정의를 가졌지만 다른 수집 방법을 가진 두 팀은 여전히 비교할 수 없는 수치를 만들어 낼 것이다. 주제 1.4의 메트릭 헌장에 둘 다 기록하고, 둘 중 하나에 대한 변경도 동일한 문서화된 검토를 요구하는 변경으로 취급하라.

트레이드오프: 장단점

출처 유형	장점	단점
자동화된 파이프라인 계측 (CI/CD, 버전 관리)	객관적이고, 타임스탬프가 찍히며, 조작하기 어렵고, 지속적인 노력이 적음	구축하고 유지하는 데 초기 엔지니어링 투자가 필요함
이슈 트래커와 프로젝트 관리 데이터	널리 이용 가능하고 팀에게 친숙함	사람의 성실함에 의존함; 흔히 팀 간에 일관성이 없음
설문 조사와 자가 보고	주관적 경험(만족도, 웰빙)에 대한 유일한 출처	회상 편향, 사회적 바람직성 편향, 응답 피로
관측 가능성 및 텔레메트리 플랫폼	풍부하고, 실시간이며, 시스템 수준의 신호	명시적으로 계측된 것만 다룸; 규모에서 비쌀 수 있음

핵심 긴장은 객관성 대 커버리지다. 자동화된 계측은 가장 신뢰할 수 있는 출처이지만 주관적 경험을 전혀 관측할 수 없고, 설문 조사는 자동화가 할 수 없는 바로 그것에 닿을 수 있지만 실제 편향 위험을 지닌다. 사건을 직접 관측할 수 있는 곳이라면 어디든 자동화된 계측을 사용하고, 시스템이 제공할 수 있었을 데이터를 위한 게으른 대체물이 아니라 진정으로 사람에게 물어봐야 하는 것에만 특별히 자가 보고를 남겨 둠으로써 이 긴장을 해결하라.

팀과 논의할 질문

우리의 가장 중요한 다섯 메트릭에 대해, 각각의 정확한 출처 시스템과 수집 방법의 이름을 댈 수 있는가, 아니면 데이터가 실제로 어디서 오는지 알지 못한 채 정의를 가정하고 있는가? 이것은 놀랍도록 흔한 간극이다: 메트릭이 프레임워크나 공급업체의 기본 대시보드에서 채택되고, 현재 팀의 아무도 어떤 시스템이 근본 데이터를 생성하는지 혹은 어떻게 그렇게 하는지 실제로 알지 못한다. 각각을 그룹 연습으로 그 근원까지 추적해 보라.
우리의 어떤 메트릭이 시스템이 직접 관측할 수 있는 것에 대해 자가 보고에 의존하고 있으며, 그 자가 보고를 실제 계측으로 대체하려면 무엇이 필요한가? 자가 보고된 배포 수, 자가 보고된 근무 시간, 그리고 자가 추정된 사이클 타임은 모두 자동화가 더 신뢰성 있게 포착할 수 있는 것에 잘못된 데이터 출처를 사용하는 흔한 사례다. 이를 식별하고 판돈이 가장 높은 것부터 대체를 우선순위화하라.
우리의 데이터 파이프라인 중 하나가 조용히 고장 났다면 우리는 어떻게 알 수 있을까? 대부분의 조직은 누군가 수치가 그럴듯하지 않아 보인다는 것을 알아챌 때에만 고장 난 메트릭 파이프라인을 발견하며, 이는 몇 달이 걸릴 수 있다. 오늘날 당신의 파이프라인 중 어느 것이라도 자동화된 건강 검사를 가지고 있는지, 그렇지 않다면 어느 것이 가장 먼저 필요한지 논의하라.
아무도 의도적으로 그렇게 결정하지 않았는데 시스템 간의 변환이 메트릭의 의미를 바꾼 곳은 어디인가? 출처 시스템에서 한 가지를 의미하는 필드는 통합이나 마이그레이션 후 미묘하게 다른 무언가를 의미할 수 있으며, 그 결과 수치는 틀렸으면서도 그럴듯해 보일 수 있다. 가장 중요한 메트릭의 전체 데이터 경로를 훑으며 변환 지점을 찾아보라.
우리는 메트릭 헌장에 정의뿐 아니라 수집 방법도 문서화하는가? 두 팀은 메트릭의 이름과 정의를 공유하면서도 다른 수집 방법으로 그것을 계산해 실제로는 비교할 수 없는 수치를 만들어 낼 수 있다. 이 특정 간극에 비추어 헌장 표본을 감사하라.
수치가 예상치 못하게 움직일 때 우리는 진짜 추세와 데이터 품질 산물을 어떻게 구별하는가? 메트릭의 갑작스러운 변화는 흔히 실제 변화나 고장 난 파이프라인 중 하나의 첫 신호이며, 둘을 구별하려면 신속하게 조사할 수 있을 만큼 데이터 출처를 잘 알아야 한다. 마지막으로 마주친 설명할 수 없는 메트릭 변화에 대한 팀의 실제 절차를 논의해 보라.

분야별 관점

스타트업. 작은 스택으로는, 대부분의 메트릭이 맞춤형 파이프라인을 구축하지 않고도 CI/CD 제공업체, 버전 관리 호스트, 그리고 경량 설문 도구에서 직접 올 수 있다. 위험은 팀이 빠르게 움직이고 있다는 이유로 기본적인 건강 검사조차 건너뛰는 것이다. 데이터 출처가 여전히 사건을 전송하고 있는지 확인하는 5분짜리 자동화된 검사는 조용히 눈을 감고 비행하는 것에 대한 저렴한 보험이다.

중소기업. 유지할 역량이 없는 맞춤형 데이터 파이프라인을 구축하는 대신 기존 도구의 내장 보고에 기대라. 어떤 수치가 자동화된 시스템에서 오고 어떤 것이 누군가 스프레드시트에 입력한 추정치인지 명시하라. 둘이 같은 페이지에 있게 되더라도 매우 다른 신뢰성을 지니기 때문이다.

엔터프라이즈. 데이터 품질 문제는 통합, 마이그레이션, 사업부 경계를 거치며 복합적으로 커진다. 가장 중요한 메트릭을 위해 중앙화되고 잘 모니터링되는 데이터 파이프라인에 투자하고, 자동화된 데이터 품질 검사를 표준 관행으로 구축하며, 사업부 간 메트릭을 비교할 때마다 정의뿐 아니라 수집 방법도 감사하라.

정부. 데이터 출처는 법적, 감사적 무게를 지닐 수 있다: 발행된 성과 수치는 그 값뿐 아니라 전체 수집 사슬에 대한 외부 감사를 견뎌야 할 수 있다. 데이터 계보를 명시적으로 문서화하고, 방법론이 바뀐 후에도 과거 수집 방법 기록을 보존하며, 수치가 현재 무엇을 나타내는지뿐 아니라 그것이 정확히 어떻게 만들어졌는지도 증명할 준비를 하라.

사례

엔터프라이즈. 한 금융 서비스 회사의 엔지니어링 리더십은 18개월 전의 데이터 파이프라인 마이그레이션이 타임스탬프 출처를 첫 커밋에서 풀 리퀘스트 생성으로 조용히 전환하여, 아무도 알아채거나 승인하지 않은 채 모든 팀에 걸쳐 평균 몇 시간씩 겉보기 리드 타임을 단축시켰다는 것을 발견하기 전까지 2년 동안 “변경에 대한 리드 타임”을 추적해 왔다. 해결책은 각 메트릭의 분포를 주 단위로 비교하고 통계적으로 이례적인 변화를 사람의 검토를 위해 표시하는 데이터 품질 검사를 도입했고, 그 이후 1년 안에 두 건의 추가적인 조용한 파이프라인 문제를 잡아냈다.

정부. 한 교통 기관의 대외용 서비스 신뢰성 대시보드는 자동화된 센서 텔레메트리와 지역 사무소로부터의 수동 입력 인시던트 보고의 혼합에 의존했다. 감사 결과, 직원 역량이 적은 지역이 부정직해서가 아니라 단지 수동 입력이 더 긴급한 작업과 시간을 다투었기 때문에 사소한 인시던트를 체계적으로 과소 보고하고 있다는 것이 밝혀졌으며, 이는 게시된 신뢰성 수치가 자원이 부족한 유지 보수가 눈에 띄지 않게 넘어가는 것을 가장 감당할 수 없는 바로 그 지역에서 실제보다 더 좋아 보이게 만들었다. 그 기관의 해결책은 실현 가능한 곳마다 수동 인시던트 입력을 자동화된 센서 트리거 로깅으로 대체하고, 게시된 수치와 함께 수동 보고 커버리지에 대한 문서화된 추정치를 추가했다.

비즈니스 사례: 동기, ROI, TCO

견고한 계측의 수익은 신뢰다: 자신의 데이터를 신뢰하는 리더십 팀은 결정적으로 그것에 따라 행동할 수 있는 반면, 조용히 고장 난 파이프라인에 데인 팀은 모든 수치를 다시 의심하기 시작하고, 이는 메트릭에 의존하는 모든 결정을 늦춘다. 그 신뢰 상실은 비싸고 수리하기 어려우며, 흔히 원래의 계측 투자가 들었을 비용보다 재건하는 데 훨씬 더 오래 걸린다.

좋은 계측의 총 소유 비용은 신뢰할 수 있는 파이프라인을 구축하는 초기 엔지니어링 작업과 데이터 품질 모니터링의 지속적인 비용을 포함하며, 둘 다 눈에 보이는 대시보드 타일을 자체적으로 만들어 내지 않기 때문에 과소 투자하기 쉽다. 그 과소 투자는 거짓된 절약이다: 나쁜 데이터로 몇 달 동안 결정이 내려진 후 조용히 고장 난 파이프라인을 발견하는 비용은 첫날에 그것을 잡아냈을 건강 검사를 구축하는 비용보다 훨씬 더 높다.

안티패턴과 함정

출처 시스템을 알지 못한 채 수치를 신뢰하기: 프레임워크나 공급업체 기본값에서 채택된 메트릭인데 아무도 데이터가 실제로 어디서 오는지 추적하지 않는다.
시스템이 직접 관측할 수 있는 것을 자가 보고하기: 객관적일 수 있었던 데이터에 불필요한 잡음과 편향을 도입한다.
메트릭 파이프라인에 자동화된 데이터 품질 검사가 없음: 조용히 고장 난 파이프라인이 몇 달 동안 발견되지 않은 채 잘못된 수치를 렌더링할 수 있다.
정의만 문서화하고 수집 방법은 문서화하지 않기: 같은 메트릭 이름을 가진 두 팀이 여전히 비교할 수 없는 수치를 계산하고 있을 수 있다.
출처 실패에 대한 아무런 표시 없이 “0” 또는 오래된 데이터를 마치 최신인 것처럼 렌더링하는 대시보드: 눈에 띄는 “데이터 이용 불가” 메시지보다 더 나쁘다.
자원이 부족한 지역이나 팀이 수동 입력 부담으로 인해 체계적으로 과소 보고하기: 가장 많은 관심이 필요한 바로 그 영역과 상관관계를 이루는 데이터 품질 간극.

성숙도 모델

1단계, 시작: 아무도 메트릭을 그 출처 시스템까지 신뢰성 있게 추적할 수 없다. 파이프라인에는 건강 검사가 없고 실패는 알아채지 못한 채 지나간다.
2단계, 개발: 일부 메트릭은 문서화된 출처를 가지고 있지만, 수집 방법은 일관성이 없고 데이터 품질 검사는 기껏해야 즉흥적이다.
3단계, 표준화: 거버넌스되는 모든 메트릭이 그 출처 시스템과 수집 방법을 문서화한다. 사건을 직접 관측할 수 있는 곳이라면 어디든 자동화된 파이프라인이 자가 보고보다 선호된다.
4단계, 관리: 자동화된 데이터 품질 검사가 모든 중요한 파이프라인을 모니터링하고, 이상을 검토를 위해 표시하며, 데이터 계보가 문서화되고 감사 가능하다.
5단계, 조율: 조직은 데이터 품질을 그 자체의 모니터링과 인시던트 대응을 갖춘 일급 엔지니어링 규율로 취급하며, 요청 시 발행된 어떤 메트릭에 대해서도 완전한 출처를 증명할 수 있다.

논의를 위한 아이디어

지금, 이 회의에서 실시간으로 우리의 상위 세 메트릭을 그 정확한 출처 시스템까지 추적할 수 있을까?
우리의 현재 메트릭 중 어느 것이 시스템이 직접 측정할 수 있는 것에 자가 보고에 의존하는가?
오늘날 우리의 메트릭 파이프라인 중 어느 것이라도 자동화된 건강 검사를 가지고 있는가?
우리는 마지막으로 언제 조용히 고장 난 데이터 파이프라인을 발견했으며, 그것은 얼마나 오랫동안 틀려 있었는가?
수동 데이터 입력이 보고된 현실과 실제 현실 사이에 간극을 만드는 곳은 어디인가?

핵심 요약

시스템이 사건을 직접 관측할 수 있는 곳이라면 어디든 자가 보고보다 자동화된 계측을 선호하라. 자가 보고는 진정으로 주관적인 경험을 위해 남겨 두라.
모든 메트릭에는 정의뿐 아니라 문서화된 출처 시스템과 수집 방법이 필요하다.
데이터 품질은 조용히 부패한다. 고장을 우연히 발견하는 대신 파이프라인 자체에 자동화된 검사를 내장하라.
일어난 일과 대시보드가 보여 주는 것 사이의 드리프트를 최소화하기 위해 변환의 하류가 아니라 사건에서 계측하라.
조용히 고장 난 파이프라인, 나쁜 데이터로 몇 달간 내려진 결정의 비용은 그것을 잡아냈을 건강 검사의 비용을 훨씬 뛰어넘는다.

참고 문헌 및 추가 자료

Majors, Charity, Liz Fong-Jones, and George Miranda. Observability Engineering. O’Reilly Media, 2022.
Forsgren, Nicole, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
Olson, Jack E. Data Quality: The Accuracy Dimension. Morgan Kaufmann, 2003.
Hubbard, Douglas W. How to Measure Anything: Finding the Value of Intangibles in Business. Wiley, 2014.