시니어라면 그래프 하나를 책임지세요
(staysaasy.com)- 시니어 엔지니어·PM·디자이너일수록 자신이 책임지는 핵심 지표 그래프를 한 개 이상 가져야 하며, 이것이 일을 잘하는 가장 빠른 방법 중 하나임
- 시니어 레벨에서 다뤄야 할 중요 문제들은 대부분 그래프로 표현 가능하며, 페이지 수·성능·비용·매출·이탈률처럼 장기적으로 변화를 보여주는 지표를 직접 책임지는 것이 요구됨
- 그래프는 “15% 줄였다” 같은 문장보다 규모·추세·변동성·시점을 한 번에 드러내며, 임팩트를 설명하고 검증 가능한 신뢰를 얻는 가장 강력한 커뮤니케이션 도구임
- 목표 설정과 점검에 그래프를 결합하는 루프는 성과 추적과 피드백을 극단적으로 단순하게 만들어, 고성과와 실직을 가르는 수준의 차이로 이어질 수 있음
- 좋은 그래프는 다른 사람들이 자주 참고하는 소수의 중요한 것이어야 하고, 품질·지원·매출·리텐션 등에서 하나의 그래프를 끝까지 책임지고 움직이게 만드는 것이 시니어의 핵심 역할임
중요한 문제를 다루기
- 시니어 단계에서는 “크고 중요한 문제”를 책임지는 것이 필수이며, 이런 문제들은 대부분 시간에 따른 변화를 보여주는 그래프로 표현 가능함
- 예: 페이지 수 감소, 성능 개선, 비용 절감, 매출 증가, 이탈률 감소 등
- 분기 단위 이상의 기간 동안 자신이 하는 일의 결과가 눈에 보이는 곡선으로 드러나야 함
- 모든 일이 그래프와 직접 연결될 필요는 없지만, 그래프 하나도 책임지지 않는 상태라면 시니어로서 제대로 역할을 하지 못하는 것
임팩트를 명확하게 전달하기
- 시니어들이 자주 겪는 문제는 자신의 성과가 이해되지 않는다는 불만이며, 이는 대개 커뮤니케이션 실패로 봐야 함
- “페이지를 15% 줄였다” 같은 문장만 보내면, 출발점·기간·추세·우연 여부 등 수많은 추가 질문이 바로 생김
- 그래프는 이런 질문에 대해 규모(스케일), 과거 히스토리, 변동성, 변화 시점을 한눈에 보여줌
- 또한 데이터 소스 링크를 함께 제공할 수 있어, 상대가 그래프의 진실성을 직접 검증하기 쉬움
- 임팩트를 모호한 텍스트로만 표현하면, “지금 하는 일이 맞는 일인지, 투자 대비 효과가 충분한지”에 대한 날카로운 피드백을 받기 어려움
- 반대로 그래프로 표현하면, 공로를 인정받는 동시에 방향·우선순위에 대한 명확한 피드백을 얻을 수 있음
- 그래프는 업무의 가치와 시간 대비 효과를 명확하게 보여주는 수단임
모든 요소를 하나로 연결하기
- 이전 글인 On Achieving Goals 에서 다룬 것처럼, 일을 이루는 과정은 “목표 설정 → 점검”이라는 단순한 루프로 요약될 수 있음
- 좋은 목표를 세우고, 명확한 책임자를 두고, 정기적인 체크인을 통해 상태와 필요 조정 사항을 확인하는 단순한 구조가 목표 달성의 본질
- 목표가 실패하는 대부분의 원인은 가치 없는 목표·우선순위 오류·책임자 부재 같은 나쁜 목표 설정과, 체크인(점검) 부족·잘못된 체크인 운영 등 기본 프로세스의 붕괴에서 비롯됨
- 정확한 목표와 꾸준한 점검은 조직이 진짜 변화를 만들기 위한 기초 인프라이며, 이를 갖추지 않으면 어떤 목표도 지속적으로 달성될 수 없음
- 이번 글은 여기에 그래프를 결합하라는 추가 규칙을 더함
- 즉, 목표를 설정하고, 그 목표를 나타내는 단일 그래프를 정기적으로 확인하는 루프를 돌려야 함
- 이 조합은 고성과자와 실직 상태를 가르는 수준으로 강력한 도구가 될 수 있음
정리
- 그래프는 시니어들이 진행 상황을 추적하고, 결과를 보여주고, 피드백을 받는 핵심 단위임
- 하나의 그래프를 책임지고 끌고 가는 것이 소유권(ownership)의 실질적인 단위
- 현재 자신이 책임지는 그래프가 없다면, 즉시 하나를 찾아서 소유해야 함
Appendix: 그래프 소유 Tip & Trick
-
다른 사람들이 자주 인용하는 그래프를 갖게 되면 제대로 가고 있는 것임
- 사람들은 보통 게으르기 때문에, 도움이 되고 정확한 그래프가 있으면 그 그래프를 다시 만들지 않고 그대로 가져다 쓰려는 경향이 있음
- 이런 그래프는 자연스럽게 본인 커리어에도 플러스로 작용함
- 그래프는 처음부터 완벽할 필요는 없으며, 피드백을 통해 점진적으로 개선해 나가는 과정 자체가 진짜 소유
- 피해야 할 안티 패턴은 “너무 많은 그래프를 소유하는 것” 임
- 어떤 사람들은 자신의 이야기에 맞는 순간에만 쓰기 위해 수많은 그래프를 모아두고 “소유한다”고 주장하지만,
- 좋은 상태는 극히 소수의, 정말 중요한 그래프만 깊이 책임지는 것
- “You have too many metrics” 에서 얘기했듯이, 지표·그래프는 적고 치명적으로 유용해야 함
- 엔지니어가 그래프를 찾고자 할 때는 품질 이슈가 좋은 출발점임
- 페이지 수, 인시던트, 버그, 성능 등은 모두 그래프화하기 좋고, 누군가가 책임지기를 기다리는 영역
- PM·디자이너 관점에서는 지원 티켓, 매출, 경쟁 승률, 리텐션에 영향을 주는 부가 제품의 부착률(attach rate) 등이 좋은 후보
- 반드시 자신 혼자 힘으로만 지표를 움직일 수 있을 필요는 없으며,
- 중요한 지표를 꾸준히 모니터링하고 집요하게 사람들을 움직여 방향을 맞추는 것만으로도 커리어를 크게 전진시킬 수 있음
그렇다면 아마 그 그래프는 오염될 가능성이 높겠군요.
굿하트의 법칙: "측정 기준이 목표가 되는 순간, 그 측정 기준은 더 이상 좋은 측정 기준이 되지 못한다"
굿하트의 법칙를 번박하는 인용으로
피터 드러커가 한 말로 알려진 "측정할 수 없으면 관 리할 수 없다(If you Can't measure it, you Can't manage it)룰 생각했습니다.
더 찾아보니 Drucker Institute에서도 드러커는 그런 말을 한 적이 없다고 합니다.
오히려 반대의 말을 찾았네요.
측정할 수 없으면 관리할 수 없다고 생각하는 것은 잘못된 것이다. - 그것은 값비싼 신화다. (It is wrong to suppose that if you can't measure it, you cant manage it-a costly myth) - 에드워드 데밍(Edwards Deming)
그럼에도 불구하고 유의미한 측정기준은 있을거라 생각해요. 특히 상반되는 두 지표를 모두 책임질 누군가가 있어야 더욱 효과적일것 같습니다. SRE 관점에서 장애건수를 낮췄다고 좋아해도, 그만큼 돌다리 두드리느라 배포가 늦어져서 기능 개발이 더뎌질수 있고, Dev 관점에서 기능 개발 많이 했다고 좋아해도, 그만큼 장애 발생 건수도 많아질수도 있는거니까요.
p99 latency, 응답 성공율, 요청당 비용, MTTR, 장애 발생 건수 같은 지표도 어뷰징하기 어려운 좋은 지표라고 생각합니다. (물론 어뷰징 될수도 있긴하겠지만 추적하고 관리하는게 실보다 득이 더 많을것 같은...)
평소에, 퍼센티지로 성과를 내세우는게 무의미하다고 생각했는데 이 글이 제 생각을 완성시켜주는 것 같습니다.
매출 5퍼센트 상승에 기여, 가 아니라 어느 기간동안 얼마나 올렸고 그게 본인의 기여 전이랑 비교했을 때 얼마나 가파라진 것인지를 말해야된다고 생각합니다
성과나 목표를 숫자로 표현하는 능력이 중요하다고 생각했는데, 이 글에서는 그래프까지 표현해야 된다고 하네요. 상대방에게 이해 및 신뢰도 측면에서 공감이 가는 부분이네요