제목: 장애를 막은 사람보다 야근한 사람을 높게 평가하면 조직이 망가진다


소프트웨어 조직의 평가 체계가 잘못되면 개발자의 행동도 왜곡될 수 있다.

문제를 애초에 막은 사람은 조용하다. 장애가 발생하지 않았기 때문이다.

반면 큰 사고가 난 뒤 밤새 복구한 사람은 눈에 띈다. 회의에서 설명하기도 쉽고, 고생한 흔적도 분명하다.

그래서 예방보다 복구가 더 높은 평가를 받는 조직이 생길 수 있다.

하지만 여기서 “한국 프로그래머들이 저능해졌다”는 결론은 나오지 않는다.

그건 조직의 평가 문제를 사람 전체의 지능 문제로 바꾼 것이다.

문제의 핵심은 지능이 아니라 대리 지표다.

기술을 직접 평가하기 어려운 관리자는 다음처럼 눈에 잘 보이는 것을 성과로 착각할 수 있다.

  • 오래 일한 시간
  • 작성한 코드량
  • 커밋과 티켓 수
  • 장애 때 보여준 희생
  • 어려운 용어와 복잡한 구조
  • 고객과 상사를 만족시킨 정도

이런 항목이 완전히 무의미한 것은 아니다.

하지만 이것을 품질, 생산성, 전문성과 동일시하면 문제가 생긴다.

적은 코드로 문제를 없앤 사람보다 코드를 많이 만든 사람이 유능해 보이고, 자동화로 야근을 없앤 사람보다 매번 밤새 복구한 사람이 헌신적으로 보인다.

누구나 이해할 수 있는 코드는 쉬워 보이고, 약어와 불필요한 추상화로 가득한 코드는 깊어 보일 수 있다.

그렇다고 복잡한 코드가 전문적인 것은 아니다.

전문성은 난해함이 아니라 결과로 평가해야 한다.


  • 변경하기 쉬운가
  • 결함이 적은가
  • 장애를 예방하는가
  • 다른 사람이 이해할 수 있는가
  • 운영과 복구가 가능한가
  • 장기 비용을 줄이는가


장애 복구 능력도 중요한 역량이다.

다만 사고 뒤의 희생만 보상하고 예방, 자동화, 테스트, 관측성과 재발 방지를 평가하지 않으면 조직은 같은 장애를 반복한다.

영웅을 만드는 조직보다 영웅이 필요 없는 시스템을 만드는 조직이 더 성숙하다.

개발자와 관리자가 생산성을 다르게 이해할 수도 있다.

관리자는 일정과 가시적인 산출물을 보고, 개발자는 구조와 기술 부채를 볼 수 있다. 이 차이를 줄이려면 막연한 인상 대신 여러 지표를 함께 봐야 한다.

장애 빈도, 복구 시간, 재발률, 변경 실패율, 재작업, 유지보수 시간, 코드 검토, 사용자 가치와 팀의 지속 가능성을 같이 평가해야 한다.

그리고 몇몇 회사나 개인 경험만으로 “한국 프로그래머 전체”를 평가할 수도 없다.

국가 전체의 개발 역량을 주장하려면 산업, 기업 규모, 직무, 경력과 평가 제도를 비교한 자료가 필요하다. 자신이 본 사례만으로 전체 집단의 지능을 결론 내리는 것은 분석이 아니라 성급한 일반화다.

마지막으로 서비스 업무가 포함된다는 사실도 기술적 무능을 뜻하지 않는다.

소프트웨어는 사람과 조직의 문제를 해결하는 활동이므로 요구사항 조정, 설명, 협상과 고객 대응도 실제 업무다. 기술과 서비스는 서로 배타적이지 않다.

조직 평가가 왜곡됐다는 비판은 충분히 할 수 있다.

하지만 그 비판을 특정 국가의 개발자와 장애인에 대한 모욕으로 바꾸는 순간, 구조적 문제에 대한 설득력도 함께 사라진다.

사람의 지능을 욕하기 전에 조직이 무엇을 측정하고 무엇을 보상하는지부터 보라.

대개 사람은 평가받는 방향으로 움직인다.