숫자가 설명하지 못하는 개발자의 클래스: 지표가 가리는 진짜 실력

들어가며: 개발자를 숫자로 평가할 수 있을까?

연말 회고 모임에서 가장 큰 화두는 단연 "개발자를 정량적으로 평가할 수 있는가? 만약 평가를 해야 한다면 어떻게 정량적인 평가를 할 수 있을까?"였습니다. 팀 단위로 일하는 현대의 개발 환경에서 개인의 역량을 숫자로 발라내기란 매우 어려운 일입니다. 기능의 성패가 오롯이 개발자의 실력은 아니며, AI 시대에 단순히 코드 라인 수(LoC)를 따지는 것도 무의미하기 때문입니다.

"완벽한 지표는 없다"는 고민 끝에 문득 축구팀이 떠올랐습니다. 축구 스카우터들은 선수의 스탯만 보지 않습니다. 공을 가지지 않았을 때의 움직임, 위기 대처 능력 등 데이터에 잡히지 않는 '숫자 너머의 가치'를 보기 위해 직접 경기장을 찾습니다. 만약 스탯이 전부라면 비싼 스카우터를 고용할 이유가 없겠지요.

개발자에게도 이런 '숫자로 증명할 수 없는 가치'가 존재하지 않을까요? 축구 덕후의 시선으로 프로덕트 팀과 경기장 위 선수들을 매칭하며, 이 질문을 함께 고민해보려 합니다. 완벽한 비유는 아니지만, 평가의 본질을 생각해보는 계기가 되길 바랍니다.

 

 

외부의 관리자들: Managers.

모든 팀에는 방향을 정하고 자원을 배분하는 사람들이 있습니다. 축구팀의 단장과 감독처럼, 프로덕트 팀에도 PO와 PM이 있죠. 이들은 직접 경기를 뛰지는 않지만, 팀의 성패를 좌우하는 핵심 역할을 합니다.

단장 = PO (Product Owner)

⚽ 축구에서는:

팀의 방향성과 비전을 관리하며 중대한 결정을 내립니다. 감독으로부터 선수 영입 요청을 받으면 구단주와 담판을 지어 영입 자금을 확보하고, 팀이 리그에서 우승하기 위한 큰 그림을 그립니다.

 

🖥️ 회사에서는:

축구 단장과 마찬가지로 팀의 큰 그림을 그립니다. PM으로부터 요청을 받으면 경영진(CEO, CTO)과 협상해 예산과 인력을 확보하고, 프로덕트 로드맵의 우선순위를 결정합니다.

 

감독 = PM (Product Manager) 

⚽ 축구에서는:

선수들을 직접 관리하고 전술을 짭니다. 1년의 시즌을 계획하고 팀 순위(성과 지표)를 관리하며, '4-3-3' 이라는 포메이션을 채택해 공격/수비 전술로 팀을 지휘합니다. 선수와의 1on1을 통해 컨디션을 체크하고, 상대에 맞춰 적재적소에 선수를 배치합니다.

 

🖥️ 회사에서는:

팀원들을 직접 관리하고 실행 전략을 수립합니다. 프로덕트 로드맵에 맞춰 feature들을 계획하고, 애자일(Agile) 방법론으로 스프린트를 운영합니다. 1on1을 통해 팀원의 어려움을 파악하고, 역량을 끌어올려 성과를 낼 수 있도록 돕습니다.

 

 

내부의 실무자들: Players.

이제는 실제 서비스에 기여하는 실무자의 관점에서 살펴보겠습니다. 프로덕트 팀의 핵심 구성원인 기획자, 디자이너, 개발자를 각각 공격수, 미드필더, 수비수로 매칭해 보겠습니다. 현대 축구에서는 같은 포지션이라도 전술에 따라 역할이 천차만별이지만, 여기서는 가장 직관적이고 단순한 역할론을 따랐습니다.

 

중앙 공격수(스트라이커) = 프로덕트 기획자

⚽ 축구에서는:

골을 넣느냐 못 넣느냐가 선수의 가치를 결정합니다. 과정이 얼마나 아름다웠든 골을 넣지 못하면 스트라이커의 임무를 다하지 못한 것입니다. 경기 승패를 가르는 득점 데이터가 가장 중요하며, 골 결정력이 높은 선수는 엄청난 이적료와 연봉을 받습니다. 하지만 결정적인 특징은 혼자서는 아무것도 할 수 없다는 점입니다. 미드필더와 윙어가 양질의 패스를 공급해줘야만 비로소 득점 기회를 잡을 수 있습니다.

 

🖥️ 회사에서는:

직접적인 성과 지표에 가장 민감하게 평가받습니다. 아무리 창의적인 기획이라도 실제 배포 후 사용자 지표가 저조하다면 인정받기 어렵습니다. 아이디어의 난이도보다는, 뚜렷한 비즈니스 임팩트를 만들어내는 기획자가 더 높은 가치를 인정받습니다. 기획자 역시 디자이너와 개발자 없이는 그 어떤 성과도 실체화할 수 없습니다. '기획안' 그 자체는 골이 아니기 때문입니다.

 

측면 공격수 (윙어/플레이메이커) = 프로덕트 디자이너

⚽ 축구에서는:

스트라이커에게 결정적인 패스를 공급하는 역할입니다. 어떻게 골이 만들어질지 머릿속에 그림을 그리고, 미드필더나 수비수로부터 볼을 받아 스트라이커가 원하는 위치로 정확히 전달합니다. 골에 직접 관여하므로 어시스트, 찬스 메이킹 횟수 등으로 가치를 평가받습니다. 스트라이커만큼은 아니지만, 득점 기여도로 가치를 인정받습니다.

 

🖥️ 회사에서는:

기획자가 원하는 '골'을 그릴 수 있도록 UI/UX를 디자인합니다. 어떤 화면이 사용자 경험을 극대화할지 구상하고, 개발자와 협업해 구현합니다. 기획의 성과 지표에 직접 영향을 주며, 수동적인 시안 제작을 넘어 "이런 UX가 지표를 높일 겁니다"라고 적극 제안하며 기획에도 관여합니다. 결국 성과가 좋을수록 그 가치를 크게 인정받습니다.

 

미드필더 = 프론트엔드 개발자

⚽ 축구에서는:

공격수에게 볼을 공급하고, 동시에 수비에도 참여하는 팀의 연결고리입니다. 공격과 수비 모두를 오가며 경기에서 가장 많이 뛰어다닙니다. 미드필더의 패스가 끊기면 공격이 막히고, 수비 공백으로 실점 위험이 커집니다. 간혹 직접 골을 넣거나 어시스트하기도 하지만, 주된 평가 지표는 패스 성공률, 볼 터치 횟수, 뛴 거리 등입니다. 하지만 오프더볼 움직임이나 전술적 포지셔닝 같은 데이터에 잡히지 않는 기여도가 상당합니다.

 

🖥️ 회사에서는:

기획자, 디자이너, 백엔드 개발자를 모두 연결하는 허브입니다. 비즈니스 로직과 UI를 모두 다루므로 코드 작성량이 가장 많고, 모든 포지션과 긴밀히 소통해야 합니다. 소통이 끊기면 일정을 못 지킬 뿐 아니라 프로젝트 전체가 위험해집니다. 간혹 단독으로 기능을 만들어 배포하기도 하지만, 주로 PR 수, 버그율, 코드 기여도 등으로 평가받습니다. 리팩토링이나 성능 개선 같은 보이지 않는 기여는 측정하기 어렵습니다.

 

수비수 = 백엔드 개발자

⚽ 축구에서는:

화려한 골 장면보다는 팀의 후방 빌드업과 수비 안정화를 책임집니다. 공격수나 윙어보다는 미드필더, 골키퍼와 긴밀하게 소통합니다. 패스 성공률, 인터셉트, 블로킹 등으로 평가받지만, 골을 넣는 공격수에 비해 과소평가되기 쉽습니다. 가장 큰 특징은 '잘해야 본전'이라는 점입니다. 아무리 수비를 잘해도 티가 잘 안 나지만, 실수 한 번은 곧바로 실점으로 이어져 비난의 대상이 되기 쉽습니다. 묵묵히 팀의 승리를 지탱하며 없어서는 안 될 핵심이지만 조명받기 어려운 포지션입니다.

 

🖥️ 회사에서는: 

사용자 눈에 보이지 않는 서버와 데이터베이스를 책임집니다. 기획/디자인보다는 프론트엔드 및 인프라 엔지니어와 밀접하게 협업합니다. 백엔드의 성과는 UI로 드러나지 않기에 과소평가되기 쉽습니다. 잘 만들어도 눈에 띄지 않지만, 로직이 꼬이거나 서버가 500 에러를 뱉는 순간 바로 드러납니다. 프론트엔드 개발자와 비슷한 수치로 측정이 되는 경우가 많고, 역시 보이지 않는 기여는 측정이 어렵습니다. "아무 일도 일어나지 않음"이 최고의 성과일 때가 많으며, 보이지 않는 곳에서 서비스의 안정성을 묵묵히 지켜냅니다.

 

키퍼 = 인프라 엔지니어

⚽ 축구에서는:

공격 상황에서는 거의 보이지 않지만, 팀의 '최후의 보루'입니다. 골키퍼가 없으면 상대의 유효 슈팅 하나에도 바로 실점하게 되며 패배로 직결됩니다. 경우에 따라 수비수가 육탄방어를 하여 공격을 막을 수 있지만 한계가 분명하고 키퍼의 빈자리는 큽니다.

 

🖥️ 회사에서는: 

클라우드 서비스를 쓴다면 당장은 없어도 개발이 가능해 보입니다. 하지만 보안 설정이 제대로 안 되면 외부 공격에 취약하고, 권한 관리가 없으면 서비스가 불안정해지거나 장애가 발생합니다. 백엔드 개발자가 일부 처리할 수 있지만 한계가 있으며, 인프라 엔지니어의 빈자리는 생각보다 큽니다.

 

 

정리하며: 숫자로 증명할 수 없는 가치 '클래스(Class)'.

앞서 이야기한 것처럼 단순히 서비스의 성과 지표만으로 팀원 개개인의 역량을 측정하기는 어렵습니다. 특히 개발자의 경우, 사용자 지표(골)만으로는 그 가치가 온전히 대변되지 않기에 '과연 어떤 정량적 지표로 나를 증명해야 하는가?'라는 질문에 선뜻 답하기 어려운 것이 사실입니다.

 

그렇다면 이미 체계가 잡힌 해외 유수 기업들은 어떨까요? 해답을 찾기 위해 해외 빅테크의 평가 기준을 찾아보았습니다.

해외 빅테크와 표준 지표들

• Google (GRAD): 단순히 기능을 구현했느냐(What)가 아니라, 얼마나 어려운 문제를 해결했는지(Complexity), 그리고 비용 절감이나 속도 개선 같은 실질적 결과(Impact)를 냈는지를 봅니다.
• Meta (PSC): '베터 엔지니어링(Better Engineering)'을 강조합니다. 당장의 속도보다 미래의 부채를 줄이는 견고함, 그리고 동료를 돕는 행위(People)를 축구의 어시스트처럼 중요하게 평가합니다.
• DORA & SPACE: 배포 빈도나 리드 타임 같은 속도 지표(DORA)뿐만 아니라, 개발자의 만족도와 협업, 몰입 시간(SPACE)까지 측정하려 시도합니다.

 

이론적으로는 훌륭해 보입니다. 분명 단순한 코드 라인 수보다는 훨씬 정교한 접근입니다. 하지만 여전히 고개가 갸웃거려지는 건 어쩔 수 없습니다.

 

배포를 자주 한다고 무조건 잘하는 걸까요? 성과를 채우기 위해 일부러 일을 잘게 쪼개는 꼼수를 부린다면요?

"예를 들어 이런 경우를 생각해봅시다. 시니어 개발자는 3개월 동안 레거시 시스템을 뜯어고쳤습니다. 배포 횟수는 1-2번이지만, 향후 개발 속도를 2배 높일 기반을 만들었죠. 반면 주니어 개발자는 같은 기간 단순 기능 구현으로 매주 배포했습니다. 배포 빈도만 보면 주니어 개발자가 압도적인데, 이게 과연 공정한 평가일까요?"

 

코드가 배포되기까지 오래 걸린 게 내 탓이 아니라, 동료의 리뷰가 늦어져서라면 이 수치는 어떻게 해석해야 할까요? 누군가는 화려한 성능 개선 업무를 맡아 돋보이지만, 누군가는 티도 안 나는 유지보수만 해야 하는 일종의 '운'에 따른 기여도의 차이는 또 어떻게 보정해야 할까요?

 

결국 이러한 의문들은 "완벽한 정량적 지표란 존재하지 않는다"는 결론에 다다르게 합니다.

 

축구에서도 그렇습니다. 실제로는 스탯은 화려하지 않아도 주요 경기에서는 선발로 나서 활약하는 선수가 있습니다. 과거 맨체스터 유나이티드의 박지성 선수처럼 말이죠. 그의 동료들은 늘 그를 '저평가된 선수', '언성 히어로(Unsung Hero, 조명받지 못하는 영웅)'라고 불렀습니다. 보이지 않는 지표들이 그를 한 차원 높은 '클래스'를 지닌 선수로 인정해준 것입니다.

• 어려운 순간에 패스를 줘도 뺏기지 않을 거라는 믿음 (안정성)
• 내가 놓쳐도 뒤에서 커버해 줄 거라는 믿음 (팀워크)
• 말하지 않아도 빈 공간을 찾아 들어가는 적극성과 센스 (오너십)

물론 현실을 부정할 수는 없습니다. 이직 시장이나 서류 평가에서 정량적 지표가 많으면 평가가 쉬워지는 것은 사실이니까요. "트래픽 50% 절감", "응답 속도 200ms 단축" 같은 숫자는 이력서 위에서 언제나 매력적입니다.

 

하지만 요즘은 마치 이런 숫자만이 개발자를 증명하는 유일한 잣대가 된 것 같아 마음 한구석이 씁쓸하기도 합니다. 모든 가치를 수치로 환산해야만 대단한 성과로 인정받는 분위기가, 개발자의 진짜 실력과 헌신을 오히려 가리고 있는 건 아닐까 하는 안타까움도 듭니다.

 

 

마치며.

사용자 지표(골)는 결국 팀이 함께 만드는 결과물입니다. 그 화려한 골 장면 뒤에는 개발자의 묵묵한 '빌드업'과 '오프더볼' 움직임이 반드시 존재합니다. 단순히 스탯(Stats) 몇 줄로 선수를 평가하고 끝내는 것이 아니라, 경기장 전체를 보는 눈, 동료와의 호흡, 위기 대처 능력까지. 인재를 다차원적이고 종합적으로 바라보려는 노력이 필요합니다. 완벽한 정답은 없겠지만, 몇 가지 시도해볼 만한 방법들이 떠오릅니다.

 

우선 조직 차원에서는 동료 평가(Peer Review)의 비중을 높이거나, 코드 리뷰, 온보딩 지원, 기술 문서 작성 등을 평가 항목에 포함하여 보이지 않는 기여를 인정하는 문화를 만들어갈 수 있을 것입니다.

 

동시에 개발자 개인 차원에서는 자신의 '클래스'를 증명하는 스토리를 만들어 보면 좋을 것 같습니다. 숫자 뒤에 숨은 맥락과 의사결정 과정을 기록하고 공유한다면 성과를 입체적으로 증명할 수 있을 것 같습니다.

 

또한, 보이지 않는 기여를 명시적으로 가시화하는 것도 도움이 될 것입니다. 개발자에게 PR 리뷰나 레거시 개선은 너무나 당연한 일상이기에 굳이 내세우지 않는 경우가 많습니다. 하지만 "이번 주 3건의 PR 리뷰를 했고, 신입의 온보딩을 도왔습니다"처럼 자신의 기여를 기록으로 남기는 습관은, 정량적 지표의 빈틈을 메우는 좋은 시도가 되지 않을까 싶습니다.

 

숫자와 신뢰, 정량과 정성을 함께 보려는 노력. 이러한 고민들이 모여 개발자의 진짜 가치를 제대로 평가하는 길로 나아갈 수 있지 않을까 생각하며 글을 마무리합니다.