<div id="readability-page-1" class="page"><div>
  <h2>코드 품질을 측정한다고 한다. 리뷰 갯수로.</h2>
  <p><span>14 Mar 2021</span></p><p>공지를 받았다. 코드 품질을 개선시키기 위해 코드 리뷰 문화를 더 활성화 시키겠다고 한다. (의도는 항상 좋다. 정말.)
그런데 그 방법이라고 가지고 온 디테일이 너무 재밌었다. (아니 사실 재미 없다.) 개발자 한명당 수행한 리뷰 갯수의 중간값, 개발자 한명당 단 comment의 중간값 이런식이다.
항상 느끼는건 아무리 경영학과에서 HR을 연구해봤자 그런걸 배운 사람이 인사담당자가 되지 않고, 평생 교육이 연구되어봤자 회사의 교육 담당자가 그런 사람이 아니라는 것인데 또 새로운 버젼이 생겼다. 코드 리뷰에 대해 고민이 없는 사람이 코드 리뷰 담당자가 되어서 어떻게든 수치화를 시키겠다고 만든 제도의 결과물로밖에 보이지 않는다.</p>

<p>신호와 소음의 시대라고들 한다. 소음 사이에서 신호를 구분하는게 개인 능력에 달려있다면, 시스템은 개인에게 최대한 소음을 걸러내고 신호를 주기 위해 노력해야하지 않나 생각한다. 저런식의 보여주기 수치화는 소음만 늘릴 것이라고 확신한다. Gitlab을 쓰든 github를 쓰든 저런 관리 툴들은 대부분 Notification 시스템을 가지고 있다. 내가 올린 리퀘스트에 댓글이 달릴 때마다 알림일 갈 것이다. 그 알림이 유용하다면 난 알림을 켜놓을 것이다. 하지만 LGTM만 가득하다면? 아마 곧 수신거부를 하겠지? 그렇게 흘려보내다가 정말 중요한 댓글을 놓칠 수도 있다. 하나하나 확인하자면 저 알림 서비스의 의미는 사라진다. 결국 사람이 수동으로 하게된다는거니까.</p>

<p>친구네 팀(재작년까지 내가 있던 팀)에서는 작년부터 도입했다고 한다. 가장 먼저 한 일은 가능한 사람은 대상이 되지 않는 세부 직무로 변경했다고 한다. 심지어 가장 열심히 리뷰를 해주는 사람 조차도. 당연하다. 저런 수치화는 의미도 없으면서 개인을 괴롭힌다. 또 다른 친구네 팀에서는 한명이 복직을 했는데, 실제로 개발을 하지는 않는데 대상자로 되어있어서 친구가 하루 종일 그사람 붙잡고 개발환경 셋팅해주고 있었다. 본인이 할 의지는 없어서. 안봐도 미래의 친구는 그 사람에게 댓글 달아달라고 메신저 보내고 있을거다. 약속된 미래가 눈에 보인다.</p>

<p>SW개발자에게 크게 미래가 보이지 않는 회사인건 입사하고 진작 알고 있었지만, 개선될거라 생각했는데 오히려 회의감만 더 들고 있다. 뭐하자는건지 사실 잘 모르겠다. 사람들이 이직 준비를 귀찮아하는 이유가 하나는 다른 SW개발 회사들과 필요한 도메인 지식이 너무 다르다는거고, 하나는 단순히 채용 과정이 너무 귀찮다는건데 (이제와서 코딩테스트 다시 준비하기 넘 귀찮다.) 전자는 공부를 감수할만한 연봉차이가 나기 시작했고 후자는 이 회사에서도 갑자기 임직원 대상으로 시험을 보겠다고 난리를 쳐야해서 ‘어차피 해야하는’ 종류의 준비가 되어버렸다. 아무리 생각해도 난 파이썬으로 이제와서 graph구현하고 hash 구현하고 있는거보다 더 생산적인 공부가 있을거라 생각하는데 회사는 아닌가봐.</p>

<p>아무래도 올해 이직하는 사람 많지 않을까. 그렇게 생각하고 있다.</p>

</div></div>

Annular Eclipse

Gayuna

공지를 받았다. 코드 품질을 개선시키기 위해 코드 리뷰 문화를 더 활성화 시키겠다고 한다. (의도는 항상 좋다. 정말.)
그런데 그 방법이라고 가지고 온 디테일이 너무 재밌었다. (아니 사실 재미 없다.) 개발자 한명당 수행한 리뷰 갯수의 중간값, 개발자 한명당 단 comment의 중간값 이런식이다.
항상 느끼는건 아무리 경영학과에서 HR을 연구해봤자 그런걸 배운 사람이 인사담당자가 되지 않고, 평생 교육이 연구되어봤자 회사의 교육 담당자가 그런 사람이 아니라는 것인데 또 새로운 버젼이 생겼다. 코드 리뷰에 대해 고민이 없는 사람이 코드 리뷰 담당자가 되어서 어떻게든 수치화를 시키겠다고 만든 제도의 결과물로밖에 보이지 않는다.
신호와 소음의 시대라고들 한다. 소음 사이에서 신호를 구분하는게 개인 능력에 달려있다면, 시스템은 개인에게 최대한 소음을 걸러내고 신호를 주기 위해 노력해야하지 않나 생각한다. 저런식의 보여주기 수치화는 소음만 늘릴 것이라고 확신한다. Gitlab을 쓰든 github를 쓰든 저런 관리 툴들은 대부분 Notification 시스템을 가지고 있다. 내가 올린 리퀘스트에 댓글이 달릴 때마다 알림일 갈 것이다. 그 알림이 유용하다면 난 알림을 켜놓을 것이다. 하지만 LGTM만 가득하다면? 아마 곧 수신거부를 하겠지? 그렇게 흘려보내다가 정말 중요한 댓글을 놓칠 수도 있다. 하나하나 확인하자면 저 알림 서비스의 의미는 사라진다. 결국 사람이 수동으로 하게된다는거니까.
친구네 팀(재작년까지 내가 있던 팀)에서는 작년부터 도입했다고 한다. 가장 먼저 한 일은 가능한 사람은 대상이 되지 않는 세부 직무로 변경했다고 한다. 심지어 가장 열심히 리뷰를 해주는 사람 조차도. 당연하다. 저런 수치화는 의미도 없으면서 개인을 괴롭힌다. 또 다른 친구네 팀에서는 한명이 복직을 했는데, 실제로 개발을 하지는 않는데 대상자로 되어있어서 친구가 하루 종일 그사람 붙잡고 개발환경 셋팅해주고 있었다. 본인이 할 의지는 없어서. 안봐도 미래의 친구는 그 사람에게 댓글 달아달라고 메신저 보내고 있을거다. 약속된 미래가 눈에 보인다.
SW개발자에게 크게 미래가 보이지 않는 회사인건 입사하고 진작 알고 있었지만, 개선될거라 생각했는데 오히려 회의감만 더 들고 있다. 뭐하자는건지 사실 잘 모르겠다. 사람들이 이직 준비를 귀찮아하는 이유가 하나는 다른 SW개발 회사들과 필요한 도메인 지식이 너무 다르다는거고, 하나는 단순히 채용 과정이 너무 귀찮다는건데 (이제와서 코딩테스트 다시 준비하기 넘 귀찮다.) 전자는 공부를 감수할만한 연봉차이가 나기 시작했고 후자는 이 회사에서도 갑자기 임직원 대상으로 시험을 보겠다고 난리를 쳐야해서 ‘어차피 해야하는’ 종류의 준비가 되어버렸다. 아무리 생각해도 난 파이썬으로 이제와서 graph구현하고 hash 구현하고 있는거보다 더 생산적인 공부가 있을거라 생각하는데 회사는 아닌가봐.
아무래도 올해 이직하는 사람 많지 않을까. 그렇게 생각하고 있다.