brunch

You can make anything
by writing

C.S.Lewis

by 김의선 Feb 13. 2023

승인과 책임

IT업계에서는 본인이 짠 코드를 운영 환경에 배포하기 전에 '코드 리뷰'라고 하는 단계를 거치는 문화를 가지고 있다. 코드리뷰란 한 명 또는 여러 명의 개발자가 본인이 만들지 않은 코드의 내용을 점검하고 피드백하는 과정을 말한다.

하지만 대기업 또는 관료주의 회사에서는 관리자에게 보다 많은 부담이 주어지게 되고, 코드 리뷰에 ‘승인’이라는 행위를 강제함으로써 ‘책임’을 함께 갖도록 유도한다.

물론 의미가 아주 없는 것은 아니지만 이러한 방식에는 몇 가지 문제점이 존재한다.

책임자(승인자)가 그 업무에 대해 잘 알지 못하므로 승인이라는 절차가 요식행위에 그친다. 책임자는 그 업무의 전문가가 아니며 자세히 코드리뷰를 할 시간도 없기 때문이다.

따라서 실제 승인자라 하더라도 책임의식을 잘 느끼지 못한다. (내가 이걸 어떻게 다 알고 승인을 해? 와 같은 반응이다)

만약 큰 문제라도 발생한다면 책임자(승인자)는 소극적으로 변한다. 개발자들에게 새로운 기술의 도입과 같은 위험한 시도는 절대 시키지 않는다.

현대 사회는 다양한 업무의 전문가를 필요로 한다. 따라서 승인자는 그 분야의 전문가가 하는 것이 올바른 길이다.

일이 제대로 돌아가는 조직에서는 별도의 책임자가 존재하더라도 모든 승인을 혼자서 하지 않는다. 이를테면 이런 식이다.

"리팩토링에 관해서라면 에릭이 가장 잘 알아. 이 분야의 전문가인 에릭에게 코드 리뷰를 부탁해야겠다."

"이런 프로그램은 처음 짜봐서 제대로 했는지 잘 모르겠네. 이 업무는 ㅇㅇ에게 부탁해야지. 그가 운영을 가장 오래했으니"

잘 단결된 팀이 일하는 모습을 살펴보면 동료 코칭이라는 기본적인 일상 활동이 항상 자연스럽게 일어난다. 팀원들은 쌍쌍이 앉아 지식을 전달한다. 이 과정에서 한 사람은 가르치고 한 사람은 배운다. 역할은 때에 따라 바뀐다. TCP/IP는 A가 B를, 큐 구현은 B가 A를 가르친다. 동료 코칭이 잘 돌아가면 참가자들은 이를 의식하지 못한다. 코칭이라 여기지도 않는다. 그냥 같이 일하는 것일 뿐이다.
-피플웨어, 톰 드마르코-

따라서 이 글을 보는 관리자는 더 이상 코칭이 관리자 본연의 역할이라는 생각을 버리기를 바란다. 과거에는 그것이 가능했을지도 모르겠지만 전문성이 다양화된 현대 사회는 더 이상 보고를 받는 관리자가 코치가 될 수 없다(정확히는 일부 기술에만 코칭이 가능하다.)는 사실을 받아들일 필요가 있으며 더 이상 부끄러워할 필요도 없다.

관리자는 부하직원들만큼 전문성을 쌓기를 고민하기보다, 차라리 동료 코칭과 코드 리뷰를 통해 어떻게 잘 조직되고 단결된 팀을 만들 것인가에 몰두하는 것이 훌륭한 관리자로 가는 훨씬 더 올바른 길이다.

keyword