-->

머니볼이란 무엇인가

2002년 오클랜드 어슬레틱스(Oakland A’s)는 메이저리그에서 가장 가난한 팀 중 하나였습니다. 뉴욕 양키스가 쓰는 연봉 예산의 3분의 1도 안 됐습니다. 그해 A’s는 103승을 기록했습니다. 어떻게 가능했을까요.

단장 빌리 빈(Billy Beane)과 데이터 분석가 폴 디포데스타(Paul DePodesta)는 당시 야구계가 ‘좋은 선수’를 판단하는 기준이 틀렸다고 봤습니다. 스카우터들은 타율, 홈런, 눈에 보이는 체격을 봤습니다. 반면 A’s는 출루율(on-base percentage)이 훨씬 중요하다는 걸 통계로 밝혀냈습니다. 출루율이 높은 선수는 ‘눈에 띄지 않아서’ 저평가됐고, 덕분에 훨씬 낮은 연봉으로 영입할 수 있었습니다.

핵심은 두 가지입니다. 첫째, 기존에 당연하게 쓰던 평가 지표가 실제 성과를 제대로 설명하지 못할 수 있다. 둘째, 시장이 과소평가한 자원을 찾으면 자원 대비 최대 성과를 낼 수 있다.

이 논리는 야구에만 적용되지 않습니다.

머니볼 사고: 개발·PM·채용에서 전통 지표를 가치에 연결된 지표로 전환

개발팀에서 머니볼 사고 적용하기

잘못된 지표가 만드는 왜곡

많은 개발팀이 여전히 코드 라인 수, 커밋 횟수, 야근 빈도 같은 지표로 개발자를 평가합니다. 이것들은 측정하기 쉽습니다. 하지만 실제로 비즈니스 가치에 얼마나 연결되는지는 불분명합니다.

출루율에 해당하는 엔지니어링 지표는 따로 있습니다.

전통적으로 쓰던 지표 실제 비즈니스에 더 연결된 지표
커밋 횟수, 코드 라인 수 배포 사이클 타임, 변경 실패율
야근 빈도 MTTR(평균 복구 시간)
버그 수정 건수 동일 버그 재발률
PR 개수 고객 가치를 직접 변경한 티켓 수

배포 성공률이 1% 오를 때 실제로 매출에 어떤 영향이 있는지 추적하는 팀은 드뭅니다. 하지만 이런 연결고리를 만들어두면 개발 활동을 비즈니스 언어로 이야기할 수 있게 됩니다. 리더십이 엔지니어링에 투자를 늘리는 근거도 여기서 나옵니다.

고효율 작업을 찾아라

A’s가 홈런보다 출루율을 택했듯, 개발팀에도 눈에 안 띄지만 임팩트가 큰 작업이 있습니다.

빌드 자동화는 화려하지 않습니다. 하지만 빌드 시간이 20분에서 5분으로 줄면, 팀 전체가 하루에 되찾는 시간은 몇 시간이 됩니다. 장애를 사전에 막는 리팩터도 마찬가지입니다. 일어나지 않은 장애는 보이지 않습니다. 그렇다고 가치가 없는 게 아닙니다.

반면 ‘스타 프로젝트’처럼 보이는 신기능 개발이 실제로는 고객 행동 변화를 거의 만들지 못하는 경우도 많습니다.

머니볼 사고는 “지금 우리 팀에서 가장 주목받지 못하는 작업 중 비즈니스 임팩트가 가장 큰 것은 무엇인가”를 묻는 것입니다.

데이터 퍼스트 회고 문화

리뷰나 회고 자리에서 “왜 그렇게 느꼈나요?”보다 “숫자가 뭐라고 하나요?”를 먼저 물어보세요. 이것이 전부가 아닙니다. 숫자가 맥락 없이 해석되면 오히려 더 위험합니다.

데이터 퍼스트 문화의 실천은 이렇게 생겼습니다. 스프린트가 끝날 때 “이번에 잘한 것/못한 것” 목록을 쓰기 전에, 배포 건수, 버그 재발률, 평균 PR 리뷰 시간 같은 숫자를 먼저 꺼냅니다. 그 숫자를 보고 팀이 느끼는 것과 실제로 일어난 것을 대조합니다. 그 간극에서 진짜 대화가 시작됩니다.

PM에게 주는 시사점

화려한 기능보다 핵심 전환 지표

“새 기능을 넣으면 사용자가 더 좋아할 것”이라는 직관은 자주 틀립니다. 머니볼 식 PM은 활성화율(activation)과 리텐션(retention)처럼 실제 행동 변화를 측정하는 지표에 집착합니다.

신기능 기획이 들어오면 이 질문을 먼저 던져보세요. “이 기능이 없어서 지금 사용자가 겪는 구체적인 불편은 뭔가요? 그리고 그 불편을 어떻게 측정할 수 있나요?” 대답이 막히면, 그 기획은 한 번 더 검토할 필요가 있습니다.

제약이 있을 때 더 똑똑하게 선택하라

자원이 부족할 때는 더 많이 하려는 게 아니라 더 잘 선택해야 합니다. 예상 ROI와 구현 난이도를 두 축으로 놓고 “낮은 비용으로 높은 효과”가 예상되는 항목을 찾아내는 매트릭스는 단순하지만 실제로 효과적입니다.

이 매트릭스의 함정은 사람마다 ROI 추정치가 다르다는 점입니다. 그래서 추정 근거를 함께 명시하는 것이 중요합니다. “이 기능이 리텐션에 5% 기여할 것 같다”라면 왜 그렇게 생각하는지 데이터와 가정을 함께 써두세요.

반직관을 설득하는 법

팀이 “경쟁사도 안 하는데 우리가 왜 하냐”고 물으면, A’s 사례처럼 숫자로 답해야 합니다. 단순히 “직감상 이게 맞다”고 말하면 설득이 안 됩니다. 하지만 “출루율 0.1 차이가 시즌 득점에 X점 차이를 만든다”처럼 논리 체인을 만들어두면 훨씬 설득력 있습니다.

실험-측정-배움의 속도 자체가 경쟁력

A/B 테스트를 하나 돌리는 데 3주 걸리는 팀과 3일 걸리는 팀은 1년 후 학습량이 10배 차이 납니다. 실험 속도를 높이는 인프라와 프로세스에 투자하는 것 자체가 Product 역량입니다.

실패 로그도 스프레드시트에 묻히면 아무도 안 봅니다. 실험 결과가 자동으로 대시보드에 올라오면, 과거 실패에서 배우는 게 추가 작업이 아니라 자연스러운 일상이 됩니다.

채용·면접에 적용하기

이력서가 출루율이 아닐 수 있다

학벌, 전 회사 이름, 커리어 연차는 오랫동안 채용에서 가장 큰 기준이었습니다. 이것들이 완전히 의미 없지는 않습니다. 다만 실제 업무 성과를 얼마나 잘 예측하느냐를 따져보면, 이 지표들의 예측력은 생각보다 약합니다.

실무 코딩 과제나 제품 설계 시뮬레이션은 더 직접적인 정보를 줍니다. 이 사람이 실제로 어떻게 문제를 분해하고 접근하는지가 보이기 때문입니다.

기존 채용 기준 머니볼 식 접근 실무 적용
학벌, 전 회사 명성 실제 문제 해결 방식 실무 과제 + 사고 과정 설명
“우리 문화에 맞나” 팀 시너지 예측 지표 행동 기반 인터뷰 점수화
연봉 협상력 성장 속도와 잠재력 사이드 프로젝트, 오픈소스 기여

편견을 코드로 줄여라

면접관 개인의 인상에 의존하면 학벌, 말투, 외모 같은 요소가 무의식적으로 평가에 들어옵니다. 이걸 없애는 데 완벽한 방법은 없지만, 블라인드 과제와 다면 평가 점수를 통계 기반으로 집계하는 방식이 어느 정도 편향을 낮춰줍니다.

중요한 건 이 과정을 기록해두는 것입니다. 채용 후 6개월, 1년 시점에 실제 성과와 면접 점수를 대조해보면, 어떤 면접 질문이 실제로 예측력이 있었는지 알 수 있습니다.

지표를 입사 후까지 연결하라

지원부터 합류 후 6개월까지의 데이터를 추적해야 채용 기준을 계속 개선할 수 있습니다. Time-to-productivity(업무 적응 속도), 온보딩 후 초기 PR 품질 같은 지표가 면접 스코어와 얼마나 연관되는지를 보면, 다음 채용에서 무엇을 다르게 물어야 할지 보이기 시작합니다.

대기업 연봉을 이길 수 없을 때

연봉 총액 경쟁에서 지면, 당신이 가진 다른 무기를 찾아야 합니다. 미션의 구체성, 빠른 성장 기회, 기술적 도전의 밀도가 그 무기가 될 수 있습니다. 단 이것을 막연한 언어로 말하면 안 됩니다.

“우리 팀에 들어오면 X 기술 스택을 실제로 프로덕션에서 운영하게 됩니다. 처음 3개월 안에 이런 실제 문제를 다루게 됩니다”처럼 구체적으로 말할 수 있어야 합니다. A’s가 방출된 선수의 숨겨진 출루율을 보고 영입했듯, 아직 빛나지 않는 잠재력을 알아보는 것이 스타트업 채용의 핵심입니다.

결론: 머니볼 사고의 세 가지 실천 원칙

첫째, 기존 지표를 의심하라. 개발에서 쓰는 지표, PM이 보는 지표, 채용에서 쓰는 기준 중에 실제 성과와 연결고리가 약한 것이 반드시 있습니다. 그걸 찾아내는 것이 머니볼의 시작입니다.

둘째, 제약을 핑계로 쓰지 마라. 예산이 적을 때 “우리는 자원이 없어서”라고 말하면 거기서 끝입니다. 머니볼 팀은 같은 제약을 다른 방식으로 프레이밍합니다. “우리가 더 똑똑하게 선택해야 한다”고요.

셋째, 전 과정의 데이터를 연결하라. 채용 기준이 실제 성과 데이터와 연결되지 않으면 기준이 개선되지 않습니다. 제품 실험이 비즈니스 지표와 연결되지 않으면 무엇을 더 해야 할지 모릅니다. 데이터 파이프라인은 기술 문제가 아니라 조직이 어떻게 학습하는지의 문제입니다.

‘돈보다 데이터, 직감보다 검증’이라는 원칙은 말하기는 쉽습니다. 실제로 실천하려면 기존에 익숙한 평가 기준과 충돌하는 순간이 반드시 옵니다. 그 순간에 데이터 쪽을 선택하는 습관이 쌓이면, 그게 조직 문화가 됩니다.

참고 자료

참고