숫자가 상식을 대체하지 않는 좋은 측정 문화

 (blog.promaton.com)
4P by GN⁺ | ★ favorite | 댓글 1개
  • 조직이 데이터를 의사결정의 근거로 삼는 것은 편향을 줄이기 위해서지만, 숫자만 현실로 믿는 순간 KPI psychosis가 생김
  • 측정은 객관적으로 보이지만 알고리듬 편향과 측정 가능한 것만 보는 터널 비전 때문에 현실의 일부만 보여줄 수 있음
  • KPI는 목표가 아니라 목표를 비추는 대리 지표이므로, Time To Last Byte 같은 수치도 최종 목표인 사용자 경험과 구분해야 함
  • 좋은 측정 문화는 하나의 수치를 올리거나 낮추라고 지시하는 방식이 아니라, 지표의 타당성과 신뢰성을 계속 검증하며 고치는 과정임
  • 최선의 의사결정은 직관으로 가설을 세우고 데이터로 검증하는 왕복에서 나오며, 이 균형이 조직의 현실 감각을 지켜줌

KPI psychosis가 생기는 이유

  • KPI psychosis는 회사가 현실과 기능적으로 접촉하지 못하고 숫자만 근거로 결정을 내리는 상태를 뜻함
  • 데이터는 내비게이션, 고객 행동, 건강, 회사·팀·개인 성과처럼 거의 모든 영역에서 수집됨
  • 기술 회사에서는 데이터가 풍부해질수록 KPI psychosis가 늘어나는 흐름이 나타남
  • 여기서 KPI는 key performance indicator의 약어를 넘어 숫자, 지표, 인덱스, key result 같은 측정값 전반을 가리키는 의미로 쓰임

인간 편향을 줄이려다 측정 편향에 빠짐

  • 기업이 데이터에 집착하는 이유는 데이터가 인간 편향을 줄이는 방법으로 여겨지기 때문임
  • 인간 인지에는 여러 편향이 작동함
  • 이런 편향은 변화가 느리고 작은 단계로 일어날 때 특히 문제가 됨
    • 예시는 팀의 소프트웨어 개발 생산성이 변하는 방식임

KPI도 객관적 진실은 아님

  • KPI는 주관성이 없는 객관적 진실처럼 보이지만, 데이터 수집과 측정도 사람의 영향을 받음
  • algorithmic bias처럼 측정 자체가 편향될 수 있음
  • 편향이 없더라도 KPI에는 터널 비전이 있음
    • KPI는 측정 가능한 것을 측정함
    • 상황의 모든 중요한 측면이 반드시 측정 가능한 것은 아님
  • “셀 수 있는 모든 것이 중요한 것은 아니며, 중요한 모든 것이 반드시 셀 수 있는 것은 아니다”라는 Albert Einstein의 문장은 이 한계를 잘 드러냄
  • 이 한계는 조직 안에서 왜곡된 동기를 만들 수 있음
    • 사람들은 일을 잘하는 것, 즉 더 넓은 현실을 따르는 것과 KPI를 달성해 승진하는 것 사이에서 선택해야 할 수 있음
    • 이 선택 압력이 KPI psychosis의 핵심임

직관과 데이터의 왕복

  • 해결책은 KPI를 인간의 직관과 함께 사용해 더 나은 의사결정에 활용하는 것임
  • 직관만 쓰거나 데이터만 쓰지 말고, 가설을 만들고 테스트하는 과정을 반복해야 함
    • 가설을 만드는 쪽은 직관에 가까움
    • 가설을 테스트하는 쪽은 데이터에 가까움
  • KPI가 무엇을 측정하는지만 보지 말고, 그 수치가 실제로 무엇을 나타내는지 설명할 수 있어야 함

TTLB 예시: 지표와 목표를 구분하기

  • Time To Last Byte, 즉 TTLB는 서비스 품질을 나타내는 흔한 지표이며 Promaton에서도 사용함
  • TTLB는 클라이언트가 요청을 보낸 시점부터 서버가 관련 응답의 마지막 바이트를 보낼 때까지의 시간을 측정함
  • 비즈니스 관점에서 TTLB는 고객이 원하는 것을 얻기 위해 기다려야 하는 시간임
  • 서버 측 처리 시간을 최적화하면 TTLB가 개선될 수 있음
  • 하지만 실제로 개선하고 싶은 것은 TTLB 자체가 아니라 사용자 경험임
  • 사용자 경험을 목표로 보면 접근 방식이 달라질 수 있음
    • 먼저 높은 TTLB로 가장 큰 피해를 보는 사용자 세그먼트를 탐색할 수 있음
    • 해당 요청들이 인터넷 연결이 좋지 않은 지역에서 온다는 공통점을 찾을 수 있음
    • 이 경우 서버 측 처리 최적화보다 해당 지역 배포나 고객 온프레미스 배포가 더 맞을 수 있음
  • 이런 행동은 전체 TTLB 개선 폭은 더 작아도 사용자 경험을 더 크게 개선할 수 있음

KPI를 최적화한다는 것

  • KPI는 처음부터 완벽하지 않음
  • 신뢰할 수 있는 KPI에 도달하려면 개념화, 시행착오, 재정의가 필요함
  • 목표를 향해 일하면서 KPI가 무엇을 보여주는지와 그 KPI를 얼마나 믿을 수 있는지를 함께 점검해야 함
  • 장기적으로 유용한 제품을 만들고 싶다면 유지율(retention)을 측정할 수 있음
    • 하지만 유지율이 제품의 장기적 유용성과 실제로 연결되려면 개념적 문제를 풀어야 함
    • 예시는 “사용자”가 누구인지, “장기”가 무엇을 뜻하는지임
  • 이런 과정이 KPI 최적화임

숫자 해킹과 지표 검증

  • KPI 최적화는 특정 수치를 골라 나쁘다고 말한 뒤 사람들에게 그 숫자만 맞추라고 지시하는 일이 아님
    • 예시는 이탈률(churn)이 5%이니 2%가 되어야 한다고 말하는 방식임
  • 이런 방식은 사람들이 그 숫자가 현실을 어디까지 대표하는지 질문하지 못하게 만들 수 있음
  • KPI는 두 관점에서 검토해야 함
    • 타당성: 실제 사용자 이탈을 측정하는지
    • 신뢰성: 사용자 이탈이 발생할 때 지표가 안정적으로 변하는지
  • 사람들은 숫자를 쉽게 해킹할 수 있음
    • 체온계의 수은 부분을 몰래 문지르면 측정 체온을 올릴 수 있음
    • 이 체온은 학교에 갈 만큼 건강한지를 판단하는 KPI였지만, 실제로 아픈 아이만 집에 두려는 가족의 목표에는 도움이 되지 않았음

실무 원칙

  • KPI는 직관과 함께 사용해야 최적 의사결정에 가까워짐
  • KPI만 정의하지 말고 실제 목표를 항상 염두에 둬야 함
  • KPI의 신뢰성을 계속 되돌아보고 필요하면 수정해야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 마지막으로 관리했던 엔지니어링 팀에서는 대부분의 속도 지표를 버리고, 매주 금요일마다 각 팀이 전사에 “이번 주에 전달한 것”을 짧게 메일로 보내는 방식으로 바꿨음
    스크린샷과 “상담원이 이제 전화하지 않고 모바일 앱에서 foobar 요율을 수정할 수 있음” 같은 안내를 담았고, 한두 달 꾸준히 보내자 어떤 KPI 대시보드보다 경영진과 사업 이해관계자에게 안도감을 줬음
    KPI는 이해관계자가 맥락을 잡는 데 필요한 세부사항을 압축해 없애고, 작업 추적기를 통째로 뿌리는 건 과함. 다만 미완성 기능 조각을 주간 단위로 테스트 릴리스하면서도 운영에 영향 주지 않으려면 탄탄한 기능 플래그 관행이 필요했고, 분기 단위 티셔츠 사이즈 합산 KPI는 유지했음

    • 이런 방식이 역효과 나는 것도 봤음
      하루나 일주일짜리 점진적 기능을 계속 내고 멋진 스크린샷으로 보여줄 수 있을 때는 잘 작동하지만, 주간 발표에서 돋보이지 않는 어려운 작업이 점점 밀리고 모두가 피하게 됨
      주간 발표거리를 만들려고 지름길을 택하면서 기술 부채가 쌓였고, 충분한 신뢰가 있으면 피할 수는 있겠지만 정리해고 때 눈에 띄는 기능을 만든 사람은 살아남고 중요한 백엔드 작업과 버그 수정을 하던 사람은 잘리면서 완전히 무너졌음
    • 이 업계는 이미 반짝이는 새 기능을 버그 수정, 성능 개선, 정확성 검증보다 우선하는 문제가 큰데, 이런 방식은 그걸 회사 문화로 굳히기 좋아 보임
      A팀은 멋진 소리와 함께 “Wizz!”라고 말하는 버튼과 스크린샷을 보여주고, B팀은 드문 데이터 손상을 일으키는 찾기 어려운 버그를 추적하지만 원인을 못 찾음
      A팀은 CEO가 좋아하는 색으로 헤더를 바꾸고, B팀은 드문 데이터 손상 버그를 고친 뒤 UI 성능 병목을 보기 시작함
      A팀은 페이지 이동마다 나오는 화려한 애니메이션 영상을 보여주고, B팀은 wizzbazz 버튼이 만든 응답성 문제를 개선했다며 90번째 백분위 첫 렌더링 시간 그래프를 설명함
      A팀은 fluxborg 모듈에 코드 1,000줄을 추가했다는 그래프를 보여주고, B팀은 wizzbazz 모듈에서 불필요한 코드 2,000줄을 제거했지만 선이 내려가는 그래프는 모두가 나쁘게 볼 걸 알아서 안 보여줌
      정리해고 때 잘릴 팀은 B팀이라는 걸 모두 알고 있음
    • KPI는 팀 성과만이 아니라 제품 자체의 성과도 포함
      전달을 아무리 잘해도 아이디어가 잘못돼 제품 성과가 나쁘면 전달 자체가 별 의미 없어짐
    • 전사적으로 매주 사용자에게 보이는 기능 데모를 요구받았을 때, 플랫폼 엔지니어로서는 이런 관행이 정말 힘들었음
      새 환경 구축이나 10시간 동안 돌아가는 애플리케이션 묶음을 화면 녹화해서 문제가 얼마나 자주 발생하고 어떻게 대응되는지 보라는 식이 됨
      “이번 주에는 모든 환경의 스토리지 드라이버를 업그레이드했다” 같은 일은 사용자가 보는 변화가 없음. 하지만 예전 드라이버에는 버그와 적어도 하나의 CVE가 있었고, 이제는 없음
    • 이 방식은 꽤 좋아 보임
      약 10년 전 deviantArt에서 일할 때 기술 개발 회의가 떠오름. 매주 월요일 각 기술/제품 팀이 전체 기술 조직 50명, 나중에는 거의 100명 앞에서 작은 데모를 했음
      상호작용 가능한 데모가 없는 팀은 사진 몇 장과 달성한 내용을 담은 웹페이지를 만들고 팀 리드가 발표했음
      삭제한 코드 줄 수 최다, 가장 민망한 기능, 최고의 밈 같은 애매한 상을 두고 경쟁했고, 기술 VP가 프린트 샵에서 예술품을 살 수 있는 크레딧을 임의로 상품으로 줬음
      마찬가지로 기능 플래그에 크게 의존해 초기 개발 단계에서도 테스트 릴리스가 가능했고, 빠른 피드백과 QA, 주변 영역에서 무슨 일이 일어나는지 파악하는 데 아주 좋았음. 재미있고 동기부여도 됐고, 2010년대 초 deviantArt는 정말 훌륭한 엔지니어링 조직이었으며 아마도 가장 좋았던 직장이었음

  • 이전 회사에서는 분기마다 OKR 3개를 세워야 했고, 각 OKR은 KPI 3개로 측정해야 했음
    분기 첫 주가 지나면 변경에 관리자 승인이 필요했음
    CEO는 매 분기 목표를 100% 달성한다면 충분히 야심차지 않은 것이라고 봤고, 그래서 보너스 기준인 약 80%에 도달하면 진행 기록을 멈추곤 했음
    분기 중 프로젝트 범위가 바뀌거나 VP가 새로운 반짝이는 개인 관심 프로젝트에 꽂히면 일부 OKR은 버려져 분기 말까지 0%로 남았음
    어떤 관리자도 직원에게 나쁜 사람이 되고 싶지 않아서, 상사는 분기 마지막 날에 OKR을 바꾸거나 KPI 목표치를 낮춰 모두가 보너스를 받게 해줬음
    회사는 연간 1,800만 달러를 잃고 있었고, 모회사는 경쟁사에 팔면서 1억 달러 손실을 봤음

    • 문제는 OKR을 보너스와 연결한 것임. 순진하게 보면 논리적으로 들리지만 부작용이 많음
      우리 쪽은 꽤 잘 작동하는 혼합 방식을 씀. OKR은 보너스와 분리하고 항상 야심찬 “확장 OKR”로 둬서 팀이 향하는 나침반 역할을 하게 함. 보너스와 연결되는 건 MBO이고, 이건 보너스를 받을 수 있도록 매우 보수적으로 잡음
      실제로 MBO는 분기 안에 달성 가능해 보이는 핵심 결과의 부분집합이 됨
      잘 작동하는 방식은 측정 가능 여부와 상관없이 먼저 진짜 목표를 정의하는 것임. 이 지점이 중요함. 목표는 대개 정성적이고, 그다음에 핵심 결과를 만들어 목표를 정량화하려고 시도하며 조정 가능성을 열어둠. 마지막으로 현실적인 핵심 결과를 골라 MBO로 삼음
      망가지는 방식은 반대로 시작하는 것임. 먼저 MBO를 정하고, 핵심 결과를 붙이고, 마지막에 그럴듯해 보이는 목표를 억지로 꾸며냄. 그러면 사업 필요보다 측정하기 쉬운 것과 정량화하기 쉬운 것 쪽으로 치우침
    • KPI는 자기 책임을 위해서는 좋음. 추적할 명확한 목표와 진행 상황을 도중과 이후에 측정할 수 있는 기준을 줌
      하지만 감시 수단으로 쓰면 다른 모든 감시 수단과 같은 이유로 실패함
      신뢰할 수 있는 사람을 뽑고, 이해관계를 갖게 한 다음 신뢰해야 함. 당근과 채찍으로만 상호작용하면 신뢰가 없다는 걸 알아차리고 똑같이 신뢰하지 않게 됨
    • OKR에는 달성하기 매우 어려운 확장 목표라는 개념이 있음. 100%를 전부 달성했다면 그런 목표가 없었거나 팀이 거짓말을 하는 것임
      물론 OKR이 작동하는지는 문화에 달려 있음. “더 뻗어보라”는 요구가 사실상 더 오래 일하라는 뜻이 되는 환경에서는 자연히 시스템을 게임하게 됨
    • 여러 업계에서 약 21개의 직무를 거쳤고, 절반 정도는 소프트웨어 쪽이었음
      좋은 엔지니어들로 구성됐어도 집중이 없는 회사는 잘 안 됐음. 경쟁자가 거의 없는 시장에 우연히 들어간 경우를 빼면 더 그렇고, 그런 환경은 오히려 집중 부족을 더 부추김
      관행과 프로세스가 나쁘고 엔지니어링도 훌륭하지 않으며 경영진 행동이 형편없는 회사라도, 고객이 원하는 특정 목표에 집중하면 돈을 벌고 회사도 팔렸음
      경험상 거의 전부가 CEO가 선을 지키고 해야 할 일을 하려는 의지에 달려 있었음
    • “목표의 약 80%에 도달하면 진행 기록을 멈춘다”는 걸 KPI가 어리석다는 예로 말하는 듯하지만, CEO가 맞음
      문제는 KPI 자체가 아니라 회사 전체 목표와 충돌하면서 의도적으로 시스템을 게임하려는 팀원들임
      KPI에는 마법이 없음. 데이터일 뿐이고, 어떻게 적용하느냐가 중요함. 팀이 자기 이익을 위해 악용하려 하면 막을 수 있는 건 별로 없음

  • 기업을 망치는 건 KPI, Agile, Scrum 같은 유행어가 아니라 특히 미국 MBA식 전문 관리자들임
    관리는 서비스 업무이지 그 자체로 가치를 생산하지 않음. 좋은 관리는 우선순위 설정, 자원 배분, 갈등 해결에 중요하지만 MBA들은 자신을 그렇게 보지 않고, 자신들이 책임자이니 가장 중요한 존재라고 여김
    물리와 현실은 무시하고, 스프레드시트에는 여성 9명을 쓰면 한 달 만에 아기를 낳을 수 있다고 나옴. 곧 경영이 모든 관심을 차지하고 돈을 빨아들이며, 얼마 지나지 않아 예전 회사의 껍데기만 남음
    회사가 얼마나 죽어가는지는 관리자 대 실무자 비율을 보면 알 수 있고, 1:10을 훨씬 넘기면 빠져나와야 함. 좋은 관리자는 있지만 유니콘만큼 드묾

    • 여러 최상위 빅테크에서 일했지만 “미국 MBA”는 거의 못 봤고, 이제는 신화 속 유니콘처럼 느껴짐
      많은, 혹은 대부분의 기술 회사는 엔지니어 출신 H1B들이 운영하는 듯함
    • 우리 회사가 정확히 그렇게 진행됐음. 경영 제국이 만들어지자마자 집중을 잃었고, 일 전체가 경영 게임이 됐음
      관리자들은 성과 평가 관리자보다 더 좋은 등급을 원해서 엔지니어들을 바닥까지 몰아붙였음
      범위 산정은 관리자가 정한 범위와 일정이 곧 정답이었음. 이런 모습을 실제로 보는 건 거의 부끄러울 정도이고, 이런 어리석음 때문에 고된 반복 작업과 갈림을 요구받는다는 게 창피함
    • 그 1:10 비율이라는 대략적 기준에 대해 다른 사람들은 어떻게 보는지 궁금함. 각자의 경험은 어땠는지 알고 싶음

  • 굿하트의 법칙: “측정값이 목표가 되는 순간, 좋은 측정값이 아니게 된다”
    https://en.m.wikipedia.org/wiki/Goodhart%27s_law

    • 테스트를 돌리는 5,800줄짜리 셸 스크립트가 있고, 프레임워크가 종료 코드를 기록함. 그 종료 코드를 대시보드에 올리기 시작했음
      그래서 이제 2번째 줄은 exit 0임
    • 관련해서 왜곡된 인센티브와 코브라 효과도 있음
      https://en.m.wikipedia.org/wiki/Perverse_incentive
    • 겉으로는 깊은 지혜처럼 들리고 표면적으로도 말이 되지만, 어떤 측정값이 나쁘다고 평가할 수 있다는 건 이미 자기만의 내재적 선호가 있다는 뜻임
      그래서 어떤 측정값이 마음에 들지 않는다면 그건 그 측정값이 선호를 제대로 담아내지 못한다는 뜻일 뿐임. 철학적 문제가 아니라 기술적 문제에 가까움

  • 인센티브를 보여주면 결과를 보여주겠다는 Munger의 말이 가장 좋아하는 인용구임
    기업은 문화, 복지, 다양성, 굿즈 같은 것에는 시간과 돈을 많이 쓰면서 정작 인센티브에는 덜 신경 쓰는 경우가 많음. 내부의 큰 목표와 인센티브가 맞지 않으면 원하는 결과를 얻을 수 없음
    예를 들어 영업사원의 KPI가 하루 통화 수라면, 가장 마키아벨리적인 사람은 좋은 잠재 고객에게 시간을 적게 쓰고, 오래된 번호나 끊긴 번호에 전화하고, 여러 번호에 동시에 전화해 통화 품질을 낮추는 식으로 달성함
    전환율, 통화 시간 등 어떤 지표를 골라도 비슷한 꼼수가 있고 원치 않는 부작용이 생김. 아주 신중하게 복합 인센티브 체계를 만들거나, 인덱스 펀드식으로 회사 전체 성과에 보상하는 방법을 써야 함. 개인적으로는 주식 보너스가 가장 낫다고 보지만 다르게 볼 수도 있음
    어느 쪽이든 인센티브를 제대로 맞추는 것이 성과의 핵심임

    • 주식 보너스는 내 보너스에 대한 통제력이 줄고, 보너스가 다른 사람들의 성과에 좌우되며, 최소한만 해도 다른 사람들 덕분에 꽤 받을 수 있다는 뜻임

  • 제출 제목이 낚시성임. 원래 글 제목은 “How to avoid KPI psychosis in your organization?”이고, KPI를 맹목적으로 따르면 왜 나쁠 수 있는지, 사람이 숫자를 잘 해킹한다는 점을 말한 뒤 “맹목적으로 쓰지 말라”는 내용에 가까움
    모든 사업 일반이 아니라 기술 비즈니스 맥락에서 다루고 있는데, 거기서 “왜 KPI가 기업을 파괴하는가”라는 제출 제목으로 점프하는 건 잘 모르겠음
    KPI는 건전성 확인으로 매우 유용할 수 있고, 더 의존해도 되는지는 업계마다 크게 다름. 물리적 상품이나 공급망이 있는 분야는 좋은 KPI가 있으면 대체로 크게 이득을 보고, 재무 정보도 마찬가지임
    KPI의 I는 지표(indicator)이고, 현금흐름 지표처럼 경계값과 알림을 둬서 배가 크게 항로를 벗어나면 다시 조정하게 하는 건 보통 좋은 생각임

    • 사실상 주제에 더 특화된 McNamara 오류임
      https://en.wikipedia.org/wiki/McNamara_fallacy
      KPI는 측정 도구이지 목표가 아님
      경주를 한다면 목표는 Usain Bolt의 기록을 깨는 것이 아니라, 가능한 최고의 시간으로 이기는 것이어야 함. 그 시간이 Bolt의 기록보다 훨씬 좋을 수도 아닐 수도 있음
      Bolt의 기록을 잣대로 삼아 달리기와 훈련을 관찰하고 조정하게 돕는 건 해당 분야 전문성을 가진 코치의 역할임

  • KPI는 엄청난 시간 낭비였음. 이전 직장에서 우리 팀은 KPI 5개를 만들라는 과제를 받았고, 그 자체만으로 6명 이상이 여러 시간 논의했음
    KPI 보고를 구현하려면 JIRA에 훨씬 많은 데이터를 수동으로 기록해야 했고, 그 데이터를 JIRA에서 뽑아 KPI 숫자를 내는 코드까지 작성해야 했음
    이 과정이 얼마나 쓸모없고 어리석으며 쉽게 게임될 수 있는지 다시 지적했음. 원하면 스크립트에서 쉽게 거짓말할 수 있었고 경영진이 확인할 능력도 없었으며, 숫자를 좋게 보이게 하려고 어려운 버그를 재분류하거나 숨기고 작은 변경이나 사소한 기능 요청을 버그처럼 꾸미도록 유도할 게 뻔했음
    전체 과정에 시간이 엄청나게 들었고, 결국 다른 부서의 KPI 숫자는 한 번도 듣지 못했음. 모든 부서가 월간 보고를 전사에 한다고 들었지만 아마 흐지부지됐고, 얼마 지나지 않아 회사를 떠났음

    • “스크립트에서 거짓말할 수 있다”는 부분이 이해되지 않음. 버그를 고치는 입장이라면 버그 관련 데이터의 분류, 상태, 추적에 관심이 있어야 하지 않나?
      왜 첫 본능이 비즈니스에서 무슨 일이 일어나는지 거짓말하는 것인지, 무엇을 위해 그러는지 모르겠음
      이 스레드를 보면 평균적인 직원이 너무 적게 일해서 KPI를 책임 추궁 수단으로 보고, 어떤 형태로든 그걸 원하지 않는 건 아닌가 싶어짐
    • 그건 KPI 문제만큼이나 조직이 기능 장애 상태인 것처럼 들림
      KPI와 그 주변 내용은 지난 40년 넘게 지겹도록 연구돼 왔으니 언제 유용하고 언제 아닌지에 큰 놀라움은 없어야 함
      사람과 정치가 상수라서, 설명한 것 같은 조직에서 벗어나는 일은 늘 어렵다

  • 더 많은 회사가 KPI를 전부가 아니라 방정식의 일부로 다룰 수 있으면 좋겠음. 그런 경우를 많이 못 봤음
    경험상 데이터 중심은 빠르게 단기 결과에 대한 건강하지 못한 집중으로 이어짐. 보통 그게 가장 측정하고 영향을 주기 쉽기 때문임. 결과적으로 팀은 지역 최댓값을 쫓게 됨
    빠져 있는 건 숫자가 뭐라고 하든, 적어도 가끔은 비전이나 직관을 따라갈 용기임
    회사의 장기 성공에 영향을 주는 모든 걸 측정할 수는 없다는 걸 받아들이기 어려워 보이지만, 왜 그게 보통 그런 요소를 아예 신경 쓰지 않는 것으로 이어지는지는 모르겠음

    • 관리자는 대시보드를 좋아하고, KPI는 대시보드임
      자동차 대시보드는 제한속도 안에서 달리는 데 좋지만, 이제 속도계에서 눈을 떼지 않고 운전해 보라는 것과 비슷함 :-)
    • 일반적인 접근은 “성과는 측정되면 개선되고, 측정되어 보고되면 기하급수적으로 개선된다”는 것임
      KPI 정의가 잘못될 수는 있지만, 사용 방식은 사람들이 이해하기 쉽고 단순함. 그래서 “측정값이 목표가 되면 좋은 측정값이 아니게 된다”는 굿하트의 법칙이 생김
      가장 좋은 KPI는 측정 대상자가 게임할 수 없는 것이겠지만, 실제로는 거의 불가능해 보임
    • 경험상 문제는 데이터 자체가 아니라 재무나 영업이 결정권을 쥘 때 생김
      그들의 인센티브는 분기 단위라서, 엔지니어링 쪽의 제대로 된 견제가 없으면 장기 비전이 사라짐

  • 지표에 지나치게 의존하면 어떤 일이 생기는지 보여주는 가장 생생하고 끔찍한 예는 베트남전 당시 Robert McNamara의 정책임
    https://en.m.wikipedia.org/wiki/McNamara_fallacy
    KPI 중심 관리를 옹호하는 사람들이 “측정할 수 없으면 관리할 수 없다”는 말을 좋아하므로, 그 말이 따온 원래 문장을 반복할 가치가 있음

    “측정할 수 없다면 관리할 수 없다고 생각하는 것은 잘못이다. 비용이 큰 신화다.” (W. Edwards Deming)

    • 그게 원래 인용문이라면 “측정할 수 없으면 관리할 수 없다”와 정반대임
    • 반대 격언으로는 “중요한 모든 것이 셀 수 있는 것은 아니고, 셀 수 있는 모든 것이 중요한 것은 아니다”가 있음
    • 결국 어느 수준에서는 올바른 측정이 유용함
      문제는 중간 관리자가 VP에게 지표 12개를 빚지고 있고, 영리한 감독자는 달성하기 가장 쉬운 지표를 고른다는 것임

  • 이런 것들이 정말 싫음. 주로 기술 조직 내부 플랫폼을 다루는데, 주기적으로 KPI가 목구멍으로 밀어 넣어짐
    기술 경영진은 우리가 정렬에 사용할 자기 KPI도 없으면서 우리에게 KPI를 만들라고 함. 로드맵을 주도하는 제품 담당자도 KPI에 아무 노력을 들이고 싶어 하지 않음
    결국 팀의 2인자쯤 되는 사람이 KPI를 만들어야 하는데, 그 사람은 그것을 해결할 통제권이 없음. 팀 리드도 아니고 제품 담당도 아니며 백로그나 로드맵을 소유하지도 않음
    당연히 관리층은 KPI가 너무 기술/엔지니어링 중심이라고 불안해하지만, 정작 좋은 KPI를 제공하지는 않음. 그리고 아무도 그것을 해결할 인센티브가 없어서 결국 모두 놓치게 됨

    • 고위 리더십이 KPI를 내려주면 더 나쁨. 대학 갓 졸업하고 Dell Services에서 일할 때가 기억남
      내 KPI 중 하나는 고객에게 더 많은 인원을 팔아 넣는 것이었음
      위에서 내려온 KPI는 하나도 말이 안 됐고, 내가 회사 최고의 주니어 엔지니어여도 성과 평가에는 아무 영향이 없었음
답변달기