# 내가 아는 최악의 프로그래머 (2023)

> Clean Markdown view of GeekNews topic #19914. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=19914](https://news.hada.io/topic?id=19914)
- GeekNews Markdown: [https://news.hada.io/topic/19914.md](https://news.hada.io/topic/19914.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-03-24T09:44:32+09:00
- Updated: 2025-03-24T09:44:32+09:00
- Original source: [dannorth.net](https://dannorth.net/the-worst-programmer/)
- Points: 16
- Comments: 5

## Summary

이 글은 팀의 생산성을 측정하려는 시도가 실패한 사례를 통해 개인 성과 지표의 한계를 설명합니다. 생산성 측정도구상 성과가 0으로 나타는 Tim Mackinnon은 스토리 포인트를 기록하지 않았지만, 페어 프로그래밍을 통해 팀의 전반적인 성과와 코드 품질을 향상시켰습니다. 결국, 팀은 개인 성과가 아닌 팀 성과와 비즈니스 영향을 기준으로 평가 방식을 전환하였습니다.

## Topic Body

- 이 글은 **팀의 생산성**을 측정하려는 시도가 어떻게 실패했는지 설명함  
- 개인 평가 및 개발 목적으로 **개인 성과 지표** 도입을 결정  
  - 코드 라인 수나 버그 수는 조작 가능성이 높아 배제하고, 대신 **스토리 포인트** 또는 **전달된 스토리 수**로 성과를 측정하기로 함  
### Tim Mackinnon의 성과는 ‘0’  
- 팀의 생산성 측정 도구(Jira 등)를 통해 모든 팀원의 성과를 측정  
- Tim의 성과 점수는 **0** → 스토리 포인트를 하나도 기록하지 않았기 때문  
- 매니저는 Tim의 성과가 0이므로 Tim을 교체할 것을 요구  
  
### Tim Mackinnon이 성과를 내지 못한 이유  
- Tim은 스토리를 직접 담당하지 않았음  
- 대신 팀원들과 **페어 프로그래밍**에 집중  
  - **경험이 적은 개발자**와 함께 작업하며 문제 해결을 유도  
  - 직접 해결하지 않고 질문을 통해 해결책 도출을 도와줌  
  - **시니어 개발자**와는 문제를 함께 고민하고 해결책 개선  
- Tim은 직접 코드를 작성하지 않았지만 팀의 전반적인 성과를 향상시킴  
  
### Tim Mackinnon의 진정한 기여  
- Tim의 기여는 개인 성과 점수로 측정할 수 없음  
- Tim 덕분에 팀 전체의 생산성 및 코드 품질이 향상됨  
- Tim이 함께 작업하면 **더 빠르고, 더 좋은 결과**를 얻을 수 있었음  
  
### 팀 생산성으로 평가 방식 변경  
- 매니저에게 Tim의 기여도를 설명하고 관찰 기회를 제공  
- 팀 전체의 성과가 향상됨을 확인한 후 개별 성과 측정 방식을 포기  
- 개인 성과가 아닌 **팀 성과 및 비즈니스 영향**으로 평가 방식 전환  
  
### 요약 (tl;dr)  
- 생산성을 **비즈니스 성과(예: 비용 절감, 수익 창출 등)로 측정해야 함**  
- 복잡한 시스템에서 **개별 성과 측정은 의미 없음**  
- DORA Metrics 등은 시스템 성과를 측정하는 도구이지 개별 기여도 측정 도구가 아님  
- Tim Mackinnon과 함께 일할 기회가 있다면 놓치지 말 것

## Comments



### Comment 36346

- Author: bus710
- Created: 2025-03-26T02:23:32+09:00
- Points: 1

사실 시니어를 넘어서 스태프 엔지니어 쯤 가면, 점점 필드에 배포 되는 코드와는 점점 멀어지고.... 대신 시니어/주니어 대상으로 코칭을 더 많이 하게 되는 것 같습니다. 매니저들 하소연도 들어줘야 되고.... 문제 터지면 여기저기 불려가서 솔루션 제시해야 하고....   
  
하는 일이 이런 식인데 지라 티겟과 점수도 정량화하는게 불가능하죠.

### Comment 36281

- Author: castedice
- Created: 2025-03-24T12:47:28+09:00
- Points: 2

테크 리드로 이러한 작업을 꽤 많이하고 있습니다. 스토리 포인트 기반 정량화를 시도하는 것도 비슷한데, 다행히 회사가 크지 않아서 임원을 비롯한 구성원들이 제가 어떤 역할을 하는지 인지를 해주고 계셔서 당장은 문제가 발생하지 않는 것 같네요.  
조직이 커지면 정량화 방법도 고민을 해봐야겠네요.

### Comment 36279

- Author: kallare
- Created: 2025-03-24T12:40:00+09:00
- Points: 2

어디서 본 이야기다 싶었는데..2023년 글이군요  
2년전에 동일한 글이 올라왔었네요 https://news.hada.io/topic?id=10680

### Comment 36273

- Author: crawler
- Created: 2025-03-24T11:43:02+09:00
- Points: 1

깃허브 코파일럿 같은 분이시군요....

### Comment 36257

- Author: neo
- Created: 2025-03-24T09:44:32+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43452649) 
- 개인 개발자의 생산성을 측정하는 것은 터무니없음. 코드 라인이나 스토리 포인트 측정은 생산성의 반대임. 개발자가 더 적은 코드로 더 많은 가치를 창출하는 것이 중요함
  - 비즈니스 결과를 측정하는 것이 중요하지만 특정 개발자에게 귀속시키기 어려움
  - 결국 주관적인 판단에 의존할 수밖에 없음을 인정하는 것이 더 나음

- Tim의 이름을 티켓에 붙여 문제를 해결하는 방법을 발견함. 팀원들이 기꺼이 도와줄 것임
  - 생산성 지표가 완전히 무가치한 것은 아님. 팀 내에서 PR과 Jira 티켓의 비율을 보면 팀 리더를 추측할 수 있음

- Tim이 팀에 남아있고 프로세스를 올바른 방향으로 이끌어 기쁨. 경청하는 관리자가 필요함
  - OKR로 인해 개발자들이 고립됨. 팀 기반이 아닌 개인 기반의 OKR은 문제를 초래함
  - 문제 해결에 시간이 오래 걸림. OKR 때문에 도움을 받을 수 없었음

- 한 프로그래머가 개인 작업 없이 모든 도움을 주는 모델은 이상함
  - Tim이 다른 사람들과 같이 스토리를 수행하고, 도움이 필요할 때 그룹에 요청하는 것이 더 건강한 상황임
  - 팀이 매우 불균형하다면 Tim은 멘토 역할을 해야 함

- Tim이 개인 작업을 하지 않는 것이 이상함. 팀 생산성을 극대화하려면 개인 기여와 팀 협업의 균형이 필요함
  - Tim이 너무 인내심이 많아 시간을 낭비했을 수 있음

- Tim이 팀에 기여하지 않으면 일을 시작하고 스토리를 전달하라고 할 것임. Tim이 다른 사람을 도와주는 것은 좋지만, 자신의 작업도 해야 함

- 모든 것이 그룹 활동이 될 필요는 없음. 평균적인 개발자가 Tim의 지속적인 도움 없이 기능을 제공할 수 없다면 팀에 문제가 있음
  - 소프트웨어 개발은 개인 작업과 그룹 작업 모두에 시간이 필요함

- 최고의 팀은 항상 Tim과 같은 사람이 있음. Tim의 도움은 다른 사람들에게 전파되어 팀 전체가 성장함
  - 개발자가 막히면 스스로 해결하려고 노력하고, 필요한 경우 도움을 요청함

- 스토리 포인트로 개발자 생산성을 측정하는 것은 좋지 않음. Zero라는 개발자는 스토리를 할당받지 않고 팀을 도왔음
  - 관리자는 Zero의 중요성을 이해하고 있었음. Zero가 없을 때 중요한 릴리스를 미루기도 했음

- 지원의 가치를 정량화하는 것은 어려움. 하지만 지원은 필수적임. 리더들이 올바르게 판단할 수 있도록 신뢰해야 함