2026 All-Day-Project (109/365)
만드는 사람들의 협업법 — 1편: 누구와 함께할 것인가
만드는 사람들의 협업법 — 3편: 매일 이기려 하면 지는 이유
만드는 사람들의 협업법 — 4편: 숫자로 보되 숫자에 갇히지 않기
만드는 사람들의 협업법 — 5편: 승리에 기여한 일
지난 편에서 제품의 숫자를 보는 눈을 이야기했습니다. 이번에는 더 민감한 영역으로 들어가 볼게요. 사람을 보는 눈. 팀에서 누군가의 기여를 어떻게 평가할 것인가의 문제입니다.
이건 꽤 불편한 주제예요. 평가라는 말만 나와도 긴장하는 사람이 많습니다. 평가받는 쪽도, 평가하는 쪽도요. 그런데 불편하다고 피할 수 있는 문제가 아닙니다. 평가의 기준이 사람의 행동을 바꾸거든요. 팀이 무엇을 보상하느냐가 팀원이 무엇에 에너지를 쏟느냐를 결정합니다. 기준이 잘못되면 아무리 좋은 사람들이 모여 있어도 엉뚱한 방향으로 달리게 돼요.
야구로 다시 잠깐 돌아가볼게요. 지난 편에서 타율과 출루율의 차이를 이야기했는데, 평가의 영역에서는 한 단계 더 깊은 질문이 있습니다. "이 선수가 팀의 승리에 얼마나 기여했는가."
세이버메트릭스에 WAR이라는 지표가 있어요. Wins Above Replacement, 직역하면 "대체 선수 대비 승리 기여도"입니다. 질문은 이래요. "이 선수 자리에 아무나 데려다 놓았을 때와 비교해서, 이 선수가 있음으로써 팀이 몇 승을 더 했는가." 흥미로운 건 이 지표가 안타, 홈런 같은 화려한 기록만 세지 않는다는 점이에요. 수비에서 실점을 막아준 것, 주루에서 한 베이스를 더 뺀 것, 상대 투수에게 공을 많이 던지게 해서 지치게 만든 것—눈에 잘 띄지 않지만 승리에 기여한 모든 것을 포함하려고 합니다.
여기서 핵심적인 전환이 일어납니다. "이 선수가 얼마나 잘했는가"에서 "이 선수가 팀이 이기는 데 얼마나 기여했는가"로. 비슷해 보이지만 완전히 다른 질문이에요.
이걸 제품팀으로 가져와볼게요. 우리가 보통 사람을 평가하는 방식을 떠올려보세요. 개발자는 얼마나 많은 코드를 짰는가, 몇 개의 기능을 출시했는가. PM은 얼마나 큰 프로젝트를 리드했는가, 기획서를 몇 개나 썼는가. 디자이너는 몇 개의 화면을 만들었는가. 이건 다 "타율"이에요. 개인의 산출물을 세는 거죠. 측정하기 쉽고, 비교하기 편하고, 보고하기 좋습니다.
그런데 이 기준으로 보면 잘 보이지 않는 사람들이 있어요.
동료의 풀 리퀘스트를 꼼꼼히 리뷰해서 버그가 프로덕션에 나가기 전에 잡아준 개발자. 이 사람 덕분에 팀 전체의 코드 품질이 올라갔지만, "코드 리뷰 30건"은 성과 보고서에서 빛나지 않습니다. 기획 초기 단계에서 "이거 사용자가 정말 원하는 게 맞아?"라고 물어서 방향을 바꾸게 만든 PM. 이 한마디가 팀의 석 달을 아꼈을 수 있지만, "프로젝트 방향 전환 기여"는 측정이 안 돼요. 부서 간 이해관계가 엉킬 때 중간에서 조율해서 일이 막히지 않게 해준 사람. 이 사람이 없었으면 프로젝트가 두 주는 늦어졌을 텐데, "부서 간 조율"은 KPI 어디에도 없습니다.
이 사람들의 공통점이 뭘까요? 직접 골을 넣지 않았다는 겁니다. 대신 팀이 골을 넣을 수 있는 조건을 만들었어요. 축구로 치면 어시스트, 야구로 치면 희생 번트나 수비 같은 역할. 화려하지 않지만 이 사람들이 빠지면 팀의 승률이 눈에 띄게 떨어집니다.
반대의 경우도 있어요. 개인 산출물은 화려한데 팀의 승리에는 기여하지 않는 경우. 혼자서 엄청난 속도로 기능을 만들어내지만, 코드가 너무 복잡해서 다른 사람이 손댈 수가 없는 개발자. 이 사람이 만든 기능에 버그가 나면 이 사람만 고칠 수 있어요. 본인의 타율은 높지만, 팀 전체로 보면 리스크를 만들어내고 있는 겁니다. 또는 매번 큰 프로젝트를 가져가지만, 같이 일하는 사람들이 지쳐 나가떨어지는 PM. 프로젝트는 성공했는데 팀은 망가져 있어요. 개인의 성적표는 빛나지만 팀의 승률은 떨어지는 선수.
이 간극을 인식하는 것이 평가를 재발명하는 첫걸음이라고 생각합니다. "이 사람이 얼마나 잘했는가" 대신 "이 사람이 있어서 우리 팀이 얼마나 더 잘하게 되었는가"를 묻는 것. 야구의 WAR처럼, "이 사람이 없었다면 어떻게 됐을까"를 상상해보는 거예요.
물론 이걸 정확한 숫자로 측정하기는 어렵습니다. 야구는 그래도 기록의 스포츠니까 WAR을 계산할 수 있지만, 제품팀에서 "코드 리뷰로 막은 버그의 잠재적 비용"이나 "방향 전환으로 절약한 개발 시간"을 정밀하게 측정하는 건 현실적이지 않아요. 하지만 정확한 측정이 불가능하다고 해서 이 관점 자체가 무의미한 건 아닙니다.
중요한 건 팀 안에서 이런 기여가 인식되고 이야기되는 것이에요. 회고 시간에 "이번 스프린트에서 팀이 잘 굴러간 이유가 뭘까?"를 물었을 때, "김 개발자가 리뷰를 꼼꼼히 해줘서 버그가 확 줄었다"는 이야기가 자연스럽게 나올 수 있는 팀. 1:1에서 "당신이 중간에서 조율해준 덕분에 프로젝트가 막히지 않았다"는 말을 건넬 수 있는 리더. 승리에 기여한 일을 보는 눈이 팀에 있느냐 없느냐가, 팀원들의 행동을 완전히 다르게 만듭니다.
왜냐하면 사람은 인정받는 방향으로 움직이거든요. 기능 출시 건수로만 평가하면 사람들은 기능을 많이 만들려 합니다. 남의 코드를 리뷰할 시간에 내 코드를 한 줄이라도 더 짜는 게 합리적인 선택이 되죠. 동료를 도와줄 시간에 내 프로젝트를 진행하는 게 성과 보고서에 유리합니다. 의도한 건 아니지만, 평가 기준이 이기적인 행동을 유인하는 거예요. 모두가 개인의 타율을 올리는 데 집중하고 팀의 승리는 뒷전이 됩니다.
반대로 팀의 승리에 기여한 일이 인정받는 문화에서는 풍경이 달라져요. 동료의 막힌 문제를 같이 풀어주는 게 "내 일을 못한 것"이 아니라 "팀에 기여한 것"이 됩니다. 코드 리뷰에 시간을 쓰는 게 "비생산적인 일"이 아니라 "팀의 품질을 올린 일"이 되고요. 기획 단계에서 "이거 방향이 맞아?"라고 솔직하게 물어보는 게 "분위기를 깨는 것"이 아니라 "팀을 올바른 방향으로 이끈 것"이 됩니다.
이건 곧 2편에서 이야기한 시니어 역할의 재정의와도 연결돼요. 시니어의 가치가 "직접 잘하는 것"에서 "팀을 잘하게 만드는 것"으로 이동하려면, 평가 기준이 먼저 그쪽으로 움직여야 합니다. 기준은 그대로인데 역할만 바꾸라고 하면, 아무도 움직이지 않아요. 사람은 선언이 아니라 기준에 반응하니까요.
정리하면 이렇습니다. 평가의 질문을 바꾸자는 거예요. "이 사람이 얼마나 잘했는가"에서 "이 사람이 있어서 팀이 얼마나 더 잘하게 되었는가"로. 타율이 아니라 승리 기여도로. 이 전환이 일어나면 팀에서 보이지 않던 기여가 보이기 시작하고, 보이기 시작하면 그런 기여를 하는 사람이 늘어나고, 그런 사람이 늘어나면 팀 전체의 승률이 올라갑니다. 선순환이에요.
잘하는 팀을 만들었고, 사람을 키우고 있고, 리듬을 잡았고, 숫자를 보는 눈과 사람을 보는 눈도 갖추었습니다. 그런데 만드는 사람에게는 또 하나의 어려운 과제가 남아 있어요. 무엇을 만들지를 결정하는 것만큼, 무엇을 그만둘지를 결정하는 것. 다음 편에서는 포기의 기술에 대해 이야기해보겠습니다.