Title:
내가 개발팀을 운영하는 원칙
|
edited by
Youngrok Pak
at
4 months, 1 week ago.
<p>블로그를 복구한 기념으로, 내가 그동안 개발팀을 운영해왔던 원칙들을 좀 정리해보기로 했다. 예전에는 이런 원칙들을 이미 내재화한 동료들과 많이 일했었기 때문에 이런 원칙들을 문서화해보지 않았는데, 최근 직장인 메디쿼터스에서는 처음부터 개발팀을 새로 빌드업해야 했기 때문에 원칙들에 대해 자주 반복적으로 설명해야 해서 자연스럽게 글로 적어보게 되었고, 이 원칙들을 내 스스로 돌이켜볼 계기가 되었다. 그 원칙들을 여기서 다시 한 번 정리하고 해설을 덧붙여보고자 한다. 이 내용들은 내가 리더로 일하기 시작한 10~15년 간 일관되게 지켜온 것들이지만, 최근의 경험에 좀더 맞춰서 이야기해본다.</p>
<h3><a href=https://agilemanifesto.org/>애자일 선언</a>과 <a href=https://wiki.c2.com/?ExtremeProgrammingRoadmap>eXtremeProgramming</a>의 가치를 이해하고 따르려고 노력한다.</h3>
<p>팀에서 공식적으로 애자일과 XP를 선언하고 시작했다. 애자일에 대해서는 수많은 논란이 있고, 또 애자일이라는 걸 너무 드러내지 말고 조금씩 도입해야 진짜 애자일이라는 둥 다양한 전략들이 거론되지만, 나는 직진을 택했다. 다만, 애자일이라는 용어가 이미 국내외를 막론하고 정반대의 의미로 많이 오염이 되어서, 애자일이라는 표현을 직접 쓰기보다는 애자일 선언을 거론하거나, 구체적인 방법론으로 XP를 들어 소통하는 방식을 취했다. </p>
<p>애자일 선언은 단어 하나하나가 정말 세심하게 선택되어 있어서 주의 깊게 읽는다면 잘못 해석할 여지도 적고, 추상적이면서도 모호하지 않다. 그러나, 쉬운 문장은 아니기 때문에 어느 정도 해설이 필요하다. 그래서 <a href="애자일 선언 다시보기">애자일 선언 다시보기</a> 같은 글을 쓰다 말기도 했었다. 하지만 여기서 애자일 선언 해설을 다 할 수는 없고, 애자일 선언의 세부원칙 12가지 중에 많은 팀이 어려워하는 거 몇 가지에 대해서만 내 관점을 적어본다.</p>
<h4>Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.</h4>
<p>경력이 적은 주니어들은 요구사항이 자주 바뀌는 것을 보고 팀이 체계 없이 일해서 그렇다고 생각하는 경우가 많다. 하지만, 요구사항이 바뀌는 것은 소프트웨어 개발에서 필연적인 것이며, 안 바뀌는 것이 훨씬 위험하다. 요구사항이 중간에 안 바뀐다는 것은 개발하는 과정에서 개발에 참여한 사람들이 아무 것도 배우지 못했다는 뜻이기 때문이다. 물론, 보통의 회사에서는 합리적인 이유로 요구사항이 바뀌기보다는 의사결정자의 갈대 같은 마음으로 바뀌기 때문에 요구사항 변화에 거부감을 갖기 쉽다. 하지만, 그런 의사결정자라면 더더욱 요구사항이 안 바뀔 때의 리스크가 더 클 것이다. 개발자는 언제든지 자기가 작업한 코드를 버릴 준비가 되어 있어야 한다. </p>
<h4>Business people and developers must work together daily throughout the project</h4>
<p>PO라는 포지션의 등장으로 이게 점점 더 어려워져 가고 있다. PO가 다리 역할을 한다는 명분으로 비즈니스 피플과 개발자 사이의 직접적인 소통을 끊고 중간에 정리해서 따로따로 소통하게 하고는 소통 시간을 절약해준다고 말한다. 도대체 누구의 시간을 절약하는 걸까? 아무리 뛰어난 PO라도 소통 과정에서 정보의 유실이 발생하지 않을 수는 없다. 담당자끼리 직접 소통하면 금방 될 일을 여러 단계로 핑퐁하면서 10분 만에 결정할 수 있는 일이 며칠 씩 걸리기도 한다. 그래서 나는 늘 비즈니스 피플과 개발자가 직접 소통하기를 권하고, 개발자가 자신이 맡은 작업의 비즈니스 가치에 대해 이해하기를 요구한다. 개발자에 따라 이걸 싫어하고 그냥 기획서만 쳐다보고 일하고 싶어하는 경우도 많다고 하는데, 적어도 내 팀에서는 대개 비즈니스랑 맞닿아 있는 것을 좋아하는 사람들이 대부분이었다. 자신의 일의 결과로 돈을 얼마 버는지, 혹은 비용을 얼마나 아끼는지 이해할 때 개발자는 더 보람을 느끼고 일에 매진할 수 있다. </p>
<h4>Working software is the primary measure of progress.</h4>
<p>애자일이 잘못 전파된 사례 중 하나가 스크럼 보드다. 스크럼 보드, 칸반, 또는 백로그 등의 시스템에서 ToDo 카드가 무슨 상태로 바뀌었냐를 가지고 프로젝트 관리를 하려는 조직들이 많다. 하지만, 이건 진짜 진척도가 아니다. 진짜 진척도를 알고 싶으면 소프트웨어를 돌려봐야 한다. 개발 진척 상황을 100% 작업관리 시스템과 싱크시키는 것은 생각보다 비용이 크다. JIRA를 열심히 쓰는 팀 중에는 JIRA를 쓰는 시간이 코드를 작성하는 시간 못지 않게 많은 팀도 흔하다. 리더 혼자 편하자고 팀원의 시간을 이렇게 써서는 안된다. 칸반의 목적도 이런 게 아니다.</p>
<p>현재까지 개발된 소프트웨어를 계속 실행해보고 여러 가지 관점에서 테스트하다보면 다음으로 해야 할 중요한 일이 무엇인지는 자연스럽게 나온다. 개발이 진척될수록 일정도 자연스럽게 예측 가능성이 높아져 간다. 카드들 늘어놓고 우선순위 열심히 토론한다고 잘 정리되는 게 아니다. </p>
<h4>Simplicity--the art of maximizing the amount of work not done--is essential.</h4>
<p>이건 개발자들이 심리적으로 잘 못하는 부분이다. 개발자는 요청 받은 일이 뭐든 다 빨리 해주는 게 능력이라고 생각하기 때문에 일을 거절하거나 더 쉬운 방법을 찾기보다 그냥 해달라는 대로 해주는 경우가 많다. 그런데 비즈니스 피플은 소프트웨어 전문가가 아니라서 어떤 대안들이 있는지 잘 모른다. 코드 한 줄 변경 없이 목적을 달성할 수 있는 방법이 있는데도 개발해 달라고 하는 경우가 많다. 매우 어려운 길로 개발하는 대신 손쉽게 조금만 고쳐서 원래 목적을 달성할 수 있는 경우도 많다. 이런 건 개발자가 이야기해줄 수 있어야 한다. </p>
<h3>모든 의사결정은 뒤집을 수 있다.</h3>
<p>애자일 선언 다음으로 중요하게 이야기한 원칙이 이것이다. 사실 이것도 embrace change를 내세우는 애자일의 연장선이기는 하지만, 좀더 구체적으로 선언해둘 필요가 있었다. 의사결정은 당연히 바뀔 수 있는데 굳이 선언해둘 필요가 있나 싶을 수 있지만 대부분의 조직은 한 번 의사결정한 것을 바꾸는데 대단한 거부감을 느낀다. 특히 가장 나쁜 것이 "우리 이거 전에 이야기해서 결정한 거잖아?" 같은 말이 나오는 것이다. 이런 말은 우리가 이전에 했던 나쁜 의사결정을 뒤집는 것도 가로막게 된다. 또 이런 말이 반복적으로 나오게 되면 그 팀은 중요한 의사결정을 내리기 어려워진다. 되돌릴 수 없는 결정이라는 걸 알고 결정한다면 사람들이 어떻게 행동할까? 절대 실패하지 않는 결정으로 만들기 위해 더 많은 검토를 해야 하고 반대 의견을 쉽게 수용하기 어려워진다. 그래서, 나는 팀에서 저런 말이 나오는 것을 극도로 경계한다.</p>
<p>법정에서도 증거나 진술 등에 허위가 있었을 때는 일사부재리의 원칙의 예외로 재심이 가능하지만, 회사는 그런 제약도 필요 없다. 이전에 의사결정했을 때보다 팀이 더 발전했고 그에 따라 생각이 바뀌었다면 의사결정을 뒤집지 못할 이유가 없다. 그래서, 실제로 다른 팀에서는 거의 바꾸지 않는 것들을 우리 팀에서는 많이 바꾸었다. js와 ts 사이를 왔다갔다 하기도 하고, 구현 상의 원칙도 여러 번 변경되었다.</p>
<p>나중에 더 좋은 결정을 내리는 게 가능해졌을 때 이전의 의사결정을 뒤집을 수 있다는 확신이 있으면 거꾸로 가벼운 의사결정이 가능해지기도 한다. 반대 의견을 주장했던 사람들도 일단 해보고 안 좋은 점이 발견되면 다시 바꾸자고 할 수 있기 때문이다. </p>
<h3>업무에 대한 의사소통은 가능하면 사적인 채널보다 공적인 채널을 우선한다.</h3>
<p>오래된 팀들에서 주로 일해오다가 신세대(?) 회사를 경험하면서 느끼는 것 중 하나는 개인적인 소통을 상당히 많이 한다는 것이다. 당연히 팀 차원에서 논의해야 할 일인데 DM으로 보낸다든지, 둘이서만 미팅 잡는다든지 하는 일이 많았다. 이건 팀 전체에 흘러야 할 정보가 흐르지 않게 만든다. 설령 나 혼자만 하면 되는 일이라 하더라도 그 정보가 팀에 흘러야 한다. 그래서, 대체로 다음과 같은 우선순위로 소통하기를 권장한다.</p>
<ul>
<li>오프라인 미팅은 되도록 모든 관련자들에게 참석을 요구하고, 온라인으로도 중계(허들 등)해서 원하는 사람이 참관할 수 있게 한다.</li>
<li>DM보다는 팀원들이 모두 소속된 채널에서 소통하는 것을 우선한다.</li>
<li>쓰레드보다는 탑 레벨 메시지를 우선한다.</li>
<li>채널은 되도록 비공개보다는 공개로 만든다.</li>
</ul>
<p>이것만으로도 의사소통의 투명성도 높아지고 정보가 좀더 잘 흐르게 된다.</p>
<h3>의사소통에서 메시지 전달의 책임은 받는 사람이 아니라 보내는 사람에게 있다.</h3>
<p>회사에서 또 분쟁이 많이 생기는 포인트 중 하나가, "전에 말씀드렸잖아요." 같은 것이다. 그런데, 직원들이 성과를 내려면 집중이 필요하고, 머리 속에 집중해야 할 일이 있을 때 들은 이야기는 놓치기 쉽다. 개발자만 그런 게 아니라 거의 모든 직군이 그럴 것이다. 그런 것들을 꼼꼼하게 챙기도록 요구할 수도 있겠고, 그게 프로페셔널의 자세라고 말할 수도 있겠지만, 나는 그렇게 생각하지 않는다. 꼼꼼하게 챙기는 것은 공짜가 아니다. 많은 비용이 들고, 때때로 집중하는데 써야 할 에너지를 소모시키는데, 이것은 회사에 더 큰 손해다. 하지만, 메시지를 보내는 사람은 보통 자신에게 필요해서 보내는 것이기 때문에 컨텍스트를 끊지 않아 전환 비용이 적게 발생한다. 그래서, 나는 메시지 전달의 책임을 송신자에게 부여한다. 이 문제에 관해 여러 가지 다양한 방법을 시도해봤지만, 효율성 측면에서도, 분쟁의 최소화 측면에서도 이게 가장 좋은 방법이었다.</p>
<p>이 원칙은 여러 가지로 파생된다. 이를테면 질문할 때 답변자가 놓치고 답을 안했다고 해서 답변자를 나무랄 수 없다. 그냥 질문자가 다시 한 번 질문해야 한다. 슬랙으로 공개 채널에서 질문했는데 답을 안 주면 멘션을 걸고, 그래도 안되면 DM을 보내고, 그래도 안되면 전화를 해야 한다. 물론 보통은 멘션 수준에서 끝나지만. 코드 리뷰를 받는 것도 리뷰어의 책임이 아니라 커미터의 책임이다. 리뷰가 지연되면 커미터가 계속 리뷰어들을 재촉해야 하는 의무를 진다. 대신 리뷰어는 재촉을 귀찮아해선 안되고.</p>
<p>다만 개발팀 바깥과의 소통에서는 튜닝이 좀 필요하다. 전사적으로 이런 원칙을 적용하는 것은 아니었기에, 외부의 요청에 대해서는 좀더 꼼꼼하게 대응하기를 요구하되, 개발팀이 타 부서나 다른 회사에 요청할 때는 응답이 안 오면 상대를 질책하지 않고 그냥 우리가 요청을 반복하도록 했다.</p>
<p>개발팀 내에서의 의사소통은 비동기가 원칙이었기 때문에 이 원칙과 더 시너지가 나는 부분도 있었다. 메시지 송신자는 언제든지 자기가 급할 때 메시지를 보내도 되고, 수신자도 자신이 가능할 때 답을 하면 된다. 일하는 시간대가 다른 사람도 많았기 때문에 더더욱 이 원칙이 잘 동작했던 것 같다.</p>
<p>이 원칙을 명시하고 여러 번 강조한 이후로는 이런 종류의 분쟁도 사라졌고, 그러면서 의사소통을 꼼꼼하게 챙기기 위한 부담도 줄어서, 상당히 유익한 정책이었다고 보고 있다.</p>
<h3>허락을 구하기보다 용서를 구하라.</h3>
<p>이건 아마도 설명이 필요 없는 원칙이지만, 이게 좋은 원칙이냐 아니냐는 아마 팀마다 다를 것이다. 내가 이 원칙을 세운 이유는 애자일 선언의 첫번째 가치, "Individuals and interactions over processes and tools"와도 연관이 있다. 개인이 프로세스보다 중요하다는 것은 팀에서 합의하는 과정을 생략하고 개인의 판단으로 움직일 수도 있다는 뜻이다. 상황에 따라 완전한 합의를 구해가면서 하기에는 발이 느린 경우도 많고, 의사결정자가 빨리 응답해줄 수 없는 경우도 많다. 그럴 때 개인의 판단으로 일단 밀고 나갈 수 있어야 좀더 기민하게 움직일 수 있고, 또 그런 개인의 판단을 존중할 때 개인의 능력과 창의성을 최대한 이끌어낼 수 있다. 그래서, 공식적으로 허락을 구하기보다 용서를 구하는 것을 권장한다.</p>
<p>단, 이게 가능하려면 위에서 언급한 의사결정과 의사소통의 원칙도 같이 맞물려야 한다. 개인이 잘못된 판단으로 추진한 일을 다시 되돌릴 수도 있다. 그래서 더더욱 부담 없이 용서를 구하는 모드로 일단 밀어붙여 볼 수 있는 것이다. 물론 이렇게 추진하는 개인도 자신이 작업한 내용이 한 순간에 다 날아갈 수 있다는 각오가 필요하다. </p>
<p>이 원칙이 잘 동작하기 위해서는 개인이 팀, 그리고 리더를 믿을 수 있어야 한다. 이 원칙을 믿고 자기 생각대로 했는데 왜 너는 허락도 안 받고 이랬냐고 질책을 받는다면 이 원칙은 동작할 수 없다. 설령 개인의 판단이 틀렸더라도 질책하지 않고 바꾸어야 한다. 또, 이런 신뢰를 얻기 위해서는 때때로 최선이 아닌 판단을 보더라도 그대로 끝까지 가도록 내버려 두어야 할 필요가 있다. 자신의 결정이 매번 뒤집어진다면 이 원칙이 진짜인지 믿기 어렵기 때문이다. 그래서 나는 팀원들이 다소 잘못된 길로 가더라도 바로 잡지 않고 놔둘 때가 종종 있다. 단, 이런 선택을 하려면 그 잘못된 선택의 결과를 감당할 수 있는 기술적 역량도 필요하다. </p>
<p>이 원칙은 코드 레벨에도 많이 스며든다. 파이썬에서는 EAFP 같은 원칙을 이야기하기도 하는데, 발생할 법한 에러를 미리 검사해서 방지하는 코드보다는 에러가 발생하면 끝까지 에러가 던져지게 하되, 잘 기록해서 추적할 수 있게 하고, 적절한 레벨의 알림으로 인지할 수 있게 하는 것을 중시한다. </p>
<h3>불완전한 코드와 생각, 업무 현황을 자주 팀에 공유하라.</h3>
<p>개발 과제를 받았을 때, 처음부터 좋은 설계를 떠올리고 좋은 코드를 작성해 갈 수 있는 사람은 없다. 누구나 시행착오를 거치게 마련인데, 이 시행착오 과정을 팀에 드러내지 않으면 여러 가지 문제가 발생한다. 가장 심각한 문제는 자기 능력 밖의 과제를 붙들어매고 끙끙대다가 필요한 시점에 개발이 완료되지 않는 것이다. 이런 걸 짚어내서 해결하는 것이 매니저의 역할이기는 하지만, 그 이전에 시행착오들이 좀더 자주 공유된다면 팀 단위로 일찍 해결할 수 있는 가능성이 높아진다. 또, 같은 시행착오가 팀 내에서 반복될 수도 있고, 더 좋은 방법이 있는데 그저그런 방법에서 머무르게 되기도 한다. 그래서, 과제의 완료 여부만으로 소통하기보다 해당 과제의 디테일에 대해 깊이 소통할수록 여러 가지로 이득을 볼 기회가 늘어난다.</p>
<p>하지만, 불완전한 모습을 내보이고 싶지 않은 사람 심리상 이게 잘 안된다. 시행착오를 거친다는 것이 능력 부족으로 비칠까 두려워하기도 한다. 특히 주니어들은 이런 두려움을 많이 가지는 것 같다. 그리고 실제로 그런 시행착오를 겪는 것을 능력부족으로 평가하는 매니저들도 있다.</p>
<p>그래서, 나는 이 문제를 개선하기 위해 여러 각도로 노력을 했다. 우선, 그런 시행착오를 자주 공유하는 사람들을 공개적으로 칭찬하고, 개인별 면담할 때도 그런 사람들의 사례를 긍정적으로 이야기하며, 그런 사람들처럼 하기를 요구했다. 그런 사람들은 대개 시니어였는데, 시니어로서는 모르면 안될 것 같은 내용에 대해 질문을 하기도 하고, 명백히 틀린 구현 방법을 제안하거나, 장애 분석시 가능성이 낮은 가설을 이야기하기도 했다. 그러나, 그렇게 계속 제안을 해준 덕분에 해당 이슈에 대해 제대로 된 이야기가 오갈 수 있었고, 거기에 대한 지식도 팀에 확산될 수 있었다. 이런 시니어들이 있었기 때문에 나도 좀더 강하게 이 원칙을 이야기할 수 있었다. 사실 어느 팀을 가든 공유의 빈도는 실력과 상당히 크게 비례한다. 잘하는 사람일수록 자주 공유하고 문제가 될 만한 것을 미리 끄집어내서 팀이 같이 해결할 수 있게 만든다. </p>
<p>하지만 주니어들은 그래도 쉽게 자신의 작업 상황을 투명하게 공유하는 것을 두려워했다. 그래서, 이번에는 다소 깊이 멘토링을 해보기로 했다. 30분 단위로 커밋을 하거나, 커밋을 하나도 못했으면 그 사이 고민한 내용을 공유하는 프랙티스를 제안해서 실행했다. 이것도 처음부터 다들 잘한 것은 아니었지만, 몇 명 앞서가는 사람들이 있었다. 근데 재미있었던 것은, 그렇게 앞서갔던 주니어들이 좀 다른 각도에서 도움이 되었다. 그들이 공유하는 내용을 지켜본 다른 주니어들이, "아, 다른 사람들도 이렇게 삽질을 많이 하는구나."를 깨닫고, 자신도 그렇게 투명하게 공유할 용기를 낼 수 있었다고 했다.</p>
<p>그리고, 조금 자극을 줄 수 있는 방법도 시도했다. 사실 우리 팀은 20명도 안되는 팀이어서 내가 맘만 먹으면 누가 무슨 일 하는지 디테일까지 다 파악할 수 있다. 이 정도 일을 맡겼고, 그러면 이 정도 기간이면 결과가 나오든 뭔가 중간 산출물이 나오든 해야 하는데, 안 나오고 있으면 뭔가 잘못하고 있다는 정도는 추측이 가능하다. 이 사실을 짚어주면서 공유 안한다고 삽질 중인 거 모르겠냐는 이야기를 했더니 다들 깜짝 놀라는 반응을 보였다. 그 뒤로는 어차피 자기 실력이 다 드러나 있다는 사실을 아니까 마음이 편해져서 더 쉽게 공유를 하게 되었다는 회고를 들을 수 있었다.</p>
<p>이 원칙이 정착되어 가면서 팀 전체의 리스크도 많이 낮출 수 있었고, 주니어들이 빠르게 시니어로 성장해갈 수 있었던 것 같다.</p>
<h3>문제가 있을 때 사람을 비난하기보다 문제 자체에 집중할 수 있는 방향으로 소통한다. 피치 못하게 사람을 비난할 때는 구체적이고 입증 가능한 근거를 제시해야 한다.</h3>
<p>위의 원칙들이 모두 가능하려면 팀에 심리적 안전감이 충분해야 한다. 내가 잘못된 코드를 작성하거나, 개발을 지연시키거나, 결함을 만들거나, 장애를 발생시키더라도 질책 받지 않고, 팀이 같이 문제를 해결한다는 믿음, 이게 있어야 위의 원칙들이 모두 가능하다. 이를 위해서는 문제가 생겼을 때 사람을 비난하지 말아야 한다. 개발에서의 문제는 대개 문제를 발생시킨 개인을 특정할 수 있고, 심지어 문제를 발생시킨 코드와 작성 시간까지 특정할 수 있지만, 그렇다고 해서 그 사람의 잘못이라는 식으로 소통해선 안된다. 그보다는 그 코드가 왜 문제인지, 그리고 그 문제를 어떻게 해결할 것인지에만 집중한다. 이것은 실용적인 원칙이기도 하다. 장애가 발생했는데 책임질 사람 찾는 게 무슨 소용인가, 일단 해결하고 봐야지. 이렇게 늘 문제 자체만 해결하려는 모습을 보이면 자연스럽게 안전하다는 느낌을 받게 되는 것 같다.</p>
<p>반대로 문제가 생겼을 때 책임자를 찾고 추궁하는 분위기가 되면 사람들이 어려운 문제에 나서지 않게 된다. 장애가 나면 자기 책임인지 아닌지만 빨리 확인하고 빠지고, 다른 사람을 돕지 않으며, 코드 리뷰에서도 논쟁적인 의견을 내지 않고 소심한 규칙 검사에 그친다. 이러면 팀이 죽어가기 시작하는 것이다.</p>
<p>내가 경험한 대부분의 팀에서는 그냥 문제에만 집중하는 분위기를 조성하는 것으로도 비난이 거의 안 나왔지만, 지난 번 팀에서는 좀 다른 상황이 있었다. 팀원들을 비난하는 발언임에도 불구하고 그게 비난이라고 생각하지 않고 하는 경우들이 많았다. 예의를 갖춰 조심스럽게 표현한다고 해서 비난이 아닌 건 아니다. 그래서, 어디까지가 비난이고 어디까지가 비난이 아닌지를 좀 정의할 필요가 있었다. 예를 몇 가지 들어보자. </p>
<p>만약에 누군가 JS에서 async의 동작을 잘 몰라서 잘못 작성한 코드가 있었다고 해보자. 이럴 때 async는 이러이러한 문법이고 이렇게 써야 한다고 말하고 넘어가면 좋은데, 그게 아니라 JS 기초가 부족하네요 같은 식으로 소통한다면 비난이 된다. 코드 품질에 대해서 이야기할 때도 이 코드는 너무 지저분해서 읽기 어려워요라고 말하면 비난인데, 이 코드의 이 부분은 shotgun surgery 냄새가 나고, 저 코드는 중복 조건문이 반복되는데 다형성으로 처리하면 좋다고 말하면 발전적인 방향이 된다. 대개 두리뭉실한 발언은 비난이 되기 쉽고, 또한 실용적인 가치도 없다.</p>
<p>이런 것보다 더 심각한 비난은 개인의 직업적 성실성이나 성인으로서의 판단력을 의심하는 발언이다. 예를 들어, 팀에서 토론을 하는데 분위기가 한쪽으로 너무 흐르고 있다면 어떤 점에서 편향되어 있는지를 지적하고 반대 방향의 이야기를 하면 건설적인 토론이 되지만, "너희들은 지금 객관적인 판단력을 잃었어"라고 말한다거나, "주니어라서 아직 이런 문제를 제대로 판단하긴 힘들다"라고 말하면 비난이 된다. 이런 발언이 튀어나올 때는 리더가 반드시 제지해야 한다.</p>
<p>근데, 그러면 사람을 향한 공격은 절대 하면 안되는가? 난 여기에 두 가지 명시적인 예외를 설정했다.</p>
<p>첫번째, 정말 꼭 해야 하는 비난이라면 근거를 정확하게 대야 한다. 예를 들어, 개인의 직업적 성실성을 의심하면 안된다고 했지만, 의심할 만한 사유가 발생핬다면 어떨까? 외주 계약을 실력이 없지만 친분이 있는 사람에게 주는 정황이 보인다면 그것도 공격하지 말아야 하나? 당연히 이런 건 잡아야 한다. 근데, 이런 비난은 중대한 비난이므로 근거가 필요하다. 아주 확정적이지는 않더라도 정황을 의심해보기에 충분한 근거가 있어야 한다. 새로 선정한 외주 업체가 일을 못하는데 알고 봤더니 친척이라든지.</p>
<p>두번째로 자신보다 직급이 높은 사람을 향한 비난은 근거가 다소 불충분하더라도 허용한다. 실무자가 매니저의 잘못을 정확하게 짚기는 어려울 수도 있다. 하지만, 그렇게 윗사람을 비난하고 싶은 일이 발생한다는 것은 뭔가 일이 잘못 굴러가고 있다는 것이고, 그게 그 윗사람의 잘못이 아니더라도 그 문제를 인식하고 해결하는 계기가 될 수 있다. 그래서, 윗사람은 아래로부터의 비난을 들을 수 있어야 한다. 물론 그게 꼭 수용해야 한다는 뜻은 아니다. 틀린 비난도 당연히 있을 수 있으니까. 적어도 그럴 때 비난 자체를 막기보다는 비난에 맞서 토론하는 자세를 보여줄 필요가 있다.</p>
<p>이렇게 비난에 대해서는 다각도로 신경을 썼지만, 막기 어려웠던 게 있다. 이 문화를 전사적으로 확신시킬 수는 없었기 때문에, 외부에서 개발팀을 향한 비난이 계속 발생하는 것은 막기 어려웠다. 그래도 우리는 다른 팀을 비난하지 말자고 했는데, 그렇게 생기는 그 감정의 골을 방치할 수는 없기 때문에 또 위의 두번째 원칙을 활용해서 그 비난을 나의 윗사람들에게 돌리고자 시도하는 정도가 한계였다.</p>
<h3>DISCLAIMER</h3>
<p>이 이야기들은 내가 팀을 운영할 때 이렇게 했다는 것이고, 내가 주관적으로 좋다고 생각하는 원칙들이지, 다른 팀에도 적용해도 될 원칙이라고 주장하진 않는다. 이 원칙들 중 상당수가 대부분의 기업에서 적용되기 어렵고, 정반대의 문화를 가진 기업이 훨씬 많다. 대부분 논쟁적이기도 하다. 이를테면, 나는 사람에 대한 비난이 조직에 해롭다고 보지만, 문제가 생기면 책임자를 찾아내서 처벌해야 조직이 굴러간다고 생각하는 사람이 세상에는 더 많다. 나는 개인의 주관을 중시하고 허락을 구하기보다 용서를 구하는 것이 실용적이라고 보지만, 합의되지 않은 개인의 판단으로 조직이 움직여서는 안된다고 생각하는 사람이 많다. 나는 요구사항은 당연히 바뀔 수 있는 거라고 생각하고, 프로세스대로 일하기보다 사람과 사람의 상호작용으로 일하는 것을 선호하지만, 이런 것을 체계 없이 일하는 거라고 보는 사람도 많다. 나 역시 이런 원칙들이 논쟁적인 원칙들임을 알기에 대부분의 회사에는 이 원칙들을 권하지 않고, 좀더 소심하게 제안하곤 한다.</p>
<p>그래도 한 가지 자신 있게 말할 수 있는 게 있다면, 이런 원칙들 하에서 일해온 우리 팀이, 우리보다 몇 배는 큰 팀들보다 비슷한 미션을 훨씬 짧은 기간에 해냈다는 것이다. 심지어 IT 업계에서 이름 있는 회사도 아니어서 채용 난이도가 훨씬 높았음에도 말이다.</p>
<p>그리고, 이 내용의 많은 부분은 <a href=https://agilemanifesto.org/>애자일 선언</a>의 다른 표현에 불과하다. 애자일 선언만 깊이 있게 이해해도 팀 운영과 프로젝트 관리에서 많은 개선점을 찾을 수 있을 것이다.</p>
<p> </p>
<p><a href=블로그>블로그</a> / <a href="소프트웨어 개발">소프트웨어 개발</a>
WikiNamu
영록이 홈페이지